विषय 10.3 — ज्ञान प्रबंधन और दस्तावेज़ीकरण

एक वाक्य में: एक सुरक्षा-महत्वपूर्ण सेवा में, आपकी टीमें जो जानती हैं लेकिन कभी नहीं लिखा, वह एक क्लिनिकल जोखिम है, केवल एक असुविधा नहीं — इसलिए दस्तावेज़ीकरण को एक प्रथम श्रेणी की डिलीवरी और ज्ञान निरंतरता को एक कर्तव्य मानें, एक अच्छाई नहीं।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

डिजिटल स्वास्थ्य टीमें छोटी, विशिष्ट हैं, और अक्सर स्थायी स्टाफ, ठेकेदारों, और आपूर्तिकर्ता इंजीनियरों से एक साथ सिली हुई हैं। वह व्यक्ति जो समझता है कि विफल होने से पहले पैथोलॉजी इंटरफ़ेस तीन बार क्यों पुनः प्रयास करता है, या इलेक्ट्रॉनिक रोगी रिकॉर्ड में कौन सा फ्लैग एक दोहरी-एलर्जी अलर्ट को दबाता है, वह अक्सर एक व्यक्ति होता है — और वह व्यक्ति आगे बढ़ता है, सेवानिवृत्त होता है, या ठीक उसी हफ्ते बीमार होता है जब सुबह 2 बजे एकीकरण टूटता है। जब ज्ञान उनके साथ चला जाता है, तो सिस्टम केवल बनाए रखना कठिन नहीं बनता; इसे सुरक्षित रूप से संचालित करना कठिन हो जाता है। एक अदस्तावेज़ीकृत वर्कअराउंड जिस पर एक चिकित्सक निर्भर था चुपचाप गायब हो सकता है, और कोई भी नहीं बचा जो जानता है कि यह लोड-बेयरिंग था।

दांव क्षेत्र के लिए विशिष्ट हैं। एक गलत समझा गया कॉन्फ़िगरेशन एक गलत-रोगी रिकॉर्ड, एक चूका हुआ अलर्ट, या एक टूटा हुआ रेफ़रल उत्पन्न कर सकता है — नुकसान रोगी परिणामों में मापा गया, डाउनटाइम टिकट में नहीं। सार्वजनिक निकाय वैधानिक दायित्व भी वहन करते हैं: स्वास्थ्य रिकॉर्ड को परिभाषित अवधियों के लिए बनाए रखा जाना चाहिए, और देखभाल और सार्वजनिक धन के बारे में निर्णय वर्षों बाद ऑडिट योग्य और खोजने योग्य होने चाहिए जब एक कोरोनर, एक नियामक, या एक Freedom of Information अनुरोध आता है। अच्छा ज्ञान प्रबंधन इसलिए आंशिक रूप से क्लिनिकल सुरक्षा है, आंशिक रूप से प्रशासन, और आंशिक रूप से अगले व्यक्ति के प्रति सम्मान जिसे सेवा चलती रखनी है। यह इससे अविभाज्य है कि आप लाइव संचालन कैसे चलाते हैं (विषय 3.8 — सेवा प्रबंधन और लाइव संचालन देखें) और आप टीमों को कैसे डिज़ाइन करते हैं (विषय 7.0 — टीम संरचनाएं, भूमिकाएं, और जिम्मेदारियां देखें)।

मुख्य अवधारणाएं#

एक अनुशासन के रूप में ज्ञान प्रबंधन। ज्ञान प्रबंधन उन प्रथाओं का समूह है जिनसे एक संगठन वह बनाता है, कैप्चर करता है, साझा करता है, और पुन: उपयोग करता है जो वह जानता है। यह तीन घटकों को संतुलित करता है — लोग और संस्कृति, प्रक्रियाएं और संरचना, और तकनीक — और तब विफल होता है जब नेता इसे एक आदत के बजाय एक उपकरण-खरीद के रूप में मानते हैं। "ज्ञान" एक क्लिनिकल मार्ग वास्तव में एक दिए गए ट्रस्ट में कैसे काम करता है से लेकर एक विशिष्ट एकीकरण इंजन कैसे कॉन्फ़िगर किया गया है तक फैलता है।

अंतर्निहित बनाम स्पष्ट ज्ञान। अंतर्निहित ज्ञान वह है जो लोगों के सिर और हाथों में रहता है — निर्णय, अंतर्ज्ञान, और कठिनाई से अर्जित "आपको यह जानना होगा कि यह ट्रस्ट डिस्चार्ज को अलग तरीके से कोड करता है" जो लिखना कठिन है। स्पष्ट ज्ञान वह है जो व्यक्त किया गया है और दस्तावेज़ों, आरेखों, और रनबुक में संहिताबद्ध किया गया है। अधिकांश ज्ञान जो एक सेवा को सुरक्षित रखता है वह अंतर्निहित से शुरू होता है; ज्ञान प्रबंधन का काम इसका पर्याप्त हिस्सा स्पष्ट रूप में बदलना है ताकि सेवा किसी एक सिर पर निर्भर न रहे।

SECI ज्ञान-रूपांतरण मॉडल। Nonaka और Takeuchi का SECI मॉडल (Socialization, Externalization, Combination, Internalization), वर्णन करता है कि ज्ञान अंतर्निहित और स्पष्ट रूपों के बीच कैसे चलता है: एक-दूसरे के साथ काम करके साझा करना (सामाजीकरण), अंतर्निहित ज्ञान को लिखना (बाह्यीकरण), स्पष्ट टुकड़ों को बड़े दस्तावेज़ों में जोड़ना (संयोजन), और दस्तावेज़ीकृत ज्ञान को वापस धाराप्रवाह अभ्यास में अवशोषित करना (आंतरिकीकरण)। यह उपयोगी है क्योंकि यह आपको याद दिलाता है कि केवल दस्तावेज़ीकरण पर्याप्त नहीं है — पेयरिंग, शैडोइंग, और समुदाय उतने ही मायने रखते हैं जितना विकी।

मुख्य-व्यक्ति निर्भरता और बस फ़ैक्टर। बस फ़ैक्टर उन लोगों की संख्या है जिन्हें खोया जाना होगा इससे पहले कि एक सेवा किसी के इसे समझने की कमी के लिए रुक जाए। एक की बस फ़ैक्टर अधिकांश छोटी डिजिटल टीमों की डिफ़ॉल्ट स्थिति है और एक ऐसी सेवा में एक गंभीर परिचालन जोखिम है जिस पर लोगों का स्वास्थ्य निर्भर करता है। उच्च स्टाफ टर्नओवर, भारी ठेकेदार उपयोग, और एकल-आपूर्तिकर्ता लॉक-इन सभी संख्या को नीचे धकेलते हैं; जानबूझकर दस्तावेज़ीकरण, क्रॉस-प्रशिक्षण, और पेयरिंग इसे वापस ऊपर धकेलते हैं।

प्रथम श्रेणी की डिलीवरी के रूप में दस्तावेज़ीकरण। दस्तावेज़ों को उप-उत्पाद के रूप में नहीं, उत्पादों के रूप में मानें। एक सेवा मैनुअल बताता है कि सेवा क्या है और यह कैसा व्यवहार करती है; एक रनबुक (या प्लेबुक) इसे शुरू करने, रोकने, और पुनर्प्राप्त करने के लिए चरण-दर-चरण प्रक्रियाएं देता है; एक आर्किटेक्चर निर्णय रिकॉर्ड (ADR) क्यों एक महत्वपूर्ण विकल्प बनाया गया था इसे कैप्चर करता है, ताकि भविष्य के मेंटेनर बिना कारणों को जाने इसे उलट न दें। एक एकल सत्य स्रोत का अर्थ है कि हर तथ्य ठीक-ठीक एक जगह पर मास्टर किया गया है, ताकि लोग "वर्तमान आर्किटेक्चर" की विरोधाभासी प्रतियों का पीछा न कर रहे हों।

Docs-as-code। दस्तावेज़ीकरण को काम के समान संस्करण-नियंत्रित रिपॉज़िटरी में रखना — सादे पाठ या Markdown में लिखा गया, कोड की तरह समीक्षित, स्वचालित रूप से प्रकाशित — दस्तावेज़ों को उस चीज़ के करीब रखता है जिसका वे वर्णन करते हैं और वर्तमान बने रहने की कहीं अधिक संभावना रखता है। जब आरेख कोड के बगल में रहता है और उसी पुल अनुरोध में बदलता है, तो यह अधिक धीरे-धीरे सड़ता है।

अभ्यास समुदाय। एक अभ्यास समुदाय (कभी-कभी एक गिल्ड कहा जाता है) एक क्रॉस-टीम समूह है जो एक शिल्प साझा करता है — क्लिनिकल सुरक्षा अधिकारी, फ्रंट-एंड इंजीनियर, सूचना प्रशासन नेता — और इसे एक साथ सुधारता है। समुदाय एक संगठन में अंतर्निहित ज्ञान को क्षैतिज रूप से फैलाते हैं जिसे लंबवत टीम सीमाएं अन्यथा फंसा देंगी।

रिकॉर्ड प्रबंधन और प्रतिधारण। रिकॉर्ड प्रबंधन जानकारी को उसके जीवनचक्र में शासित करता है, इसे कितने समय तक रखा जाना चाहिए और इसे कब नष्ट किया जा सकता है। स्वास्थ्य में यह आंशिक रूप से वैधानिक है: क्लिनिकल रिकॉर्ड NHS Records Management Code of Practice के तहत परिभाषित प्रतिधारण अवधि वहन करते हैं। यह टीम दस्तावेज़ीकरण से अलग है, और दोनों को गड्डमड्ड करना वास्तविक त्रुटियां पैदा करता है — एक बिंदु जिसकी ओर हम नीचे लौटते हैं।

सूचना वास्तुकला और खोजने योग्यता। सूचना वास्तुकला एक सूचना स्थान का संरचनात्मक डिज़ाइन है ताकि लोग जो उन्हें चाहिए वह पा सकें। बिना संरचना वाले दस हज़ार पृष्ठों वाला एक विकी दस्तावेज़ीकरण नहीं है; यह एक लैंडफिल है। खोजने योग्यता उस ज्ञान के बीच का अंतर है जो मौजूद है और उस ज्ञान का जिसका उपयोग किया जाता है।

सर्वोत्तम प्रथाएं#

1. दस्तावेज़ीकरण को एक बाद की सोच नहीं बल्कि एक परिभाषा-का-पूर्ण बनाएं। एक फ़ीचर, एकीकरण, या कॉन्फ़िगरेशन परिवर्तन तब तक "पूर्ण" नहीं है जब तक इसकी रनबुक प्रविष्टि, इसका ADR (यदि एक महत्वपूर्ण निर्णय लिया गया था), और इसका सेवा-मैनुअल अपडेट मौजूद न हो। इसे अपने काम करने के तरीकों में बेक करें ताकि यह तब लिखा जाए जब ज्ञान ताज़ा है, उस व्यक्ति द्वारा जिसके पास यह है। छह महीने बाद, स्मृति से, एक सिस्टम को पुनः-दस्तावेज़ीकृत करना वह जगह है जहां अशुद्धियां और खतरनाक अंतराल पैदा होते हैं।

2. एक एकल सत्य स्रोत रखें और इससे बाहर की ओर लिंक करें। प्रति डोमेन तय करें, हर तथ्य का आधिकारिक संस्करण कहां रहता है — आर्किटेक्चर, ऑन-कॉल रोटा, डेटा-प्रवाह आरेख — और बाकी सब कुछ इसकी नकल करने के बजाय इसकी ओर इशारा करे। डुप्लिकेट दस्तावेज़ीकरण बहता है, और एक क्लिनिकल संदर्भ में एक बासी प्रति जो कहती है "एलर्जी जांच चालू है" जब यह बंद है वह किसी दस्तावेज़ के न होने से बदतर है। आपके पास पहले से मौजूद बासी डुप्लिकेट को निर्दयता से हटाएं या पुनर्निर्देशित करें।

3. Docs-as-code अपनाएं और दस्तावेज़ीकरण को काम के बगल में रखें। रनबुक, ADR, और सेवा मैनुअल को उन प्रणालियों के साथ संस्करण नियंत्रण में स्टोर करें जिनका वे वर्णन करते हैं, कोड परिवर्तन के समान पुल अनुरोध में दस्तावेज़ीकरण परिवर्तनों की समीक्षा करें, और स्वचालित रूप से प्रकाशित करें। यह अपडेट को सस्ता, परिवर्तनों को समीक्षा योग्य, और इतिहास को ऑडिट योग्य बनाता है — और इसका अर्थ है कि सिस्टम बदलने वाले व्यक्ति को उसी सांस में दस्तावेज़ बदलने के लिए प्रेरित किया जाता है।

4. ऐसे रनबुक लिखें जिन्हें सुबह 3 बजे एक तनावग्रस्त अजनबी पालन कर सके। एक रनबुक को मान लेना चाहिए कि पाठक थका हुआ, सिस्टम से अपरिचित, और दबाव में है — क्योंकि एक प्रमुख घटना के दौरान वे होंगे। संख्याबद्ध, शाब्दिक कदमों का उपयोग करें, सटीक स्क्रीन और कमांड नाम दें, और हर कदम का अपेक्षित परिणाम बताएं और यदि यह विफल होता है तो क्या करना है। उन्हें ऐसे किसी व्यक्ति से परीक्षण करवाएं जिसने उन्हें एक ड्रिल में एक पुनर्प्राप्ति निष्पादित करके नहीं लिखा।

5. आर्किटेक्चर निर्णय रिकॉर्ड के साथ केवल "क्या" नहीं बल्कि "क्यों" कैप्चर करें। एक छोटा ADR — संदर्भ, निर्णय, परिणाम — महत्वपूर्ण विकल्पों के पीछे तर्क को संरक्षित करता है ताकि भविष्य के मेंटेनर उस बाधा को समझे बिना एक निर्णय को उलट न दें जिसने इसे प्रेरित किया। स्वास्थ्य में यह तीव्रता से मायने रखता है: एक कॉन्फ़िगरेशन जो अजीब लगता है वह एक क्लिनिकल-सुरक्षा खतरा विश्लेषण या एक सूचना-प्रशासन निर्णय के कारण मौजूद हो सकता है। कारण को रिकॉर्ड करना एक अच्छे इरादे वाले "सफाई" को एक ज्ञात जोखिम को फिर से पेश करने से रोकता है।

6. हर महत्वपूर्ण प्रणाली पर जानबूझकर बस फ़ैक्टर बढ़ाएं। एक की बस फ़ैक्टर वाली प्रणालियों की पहचान करें और इसे एक नामित स्वामी और एक योजना के साथ अपने रजिस्टर पर एक जोखिम के रूप में मानें। लोगों को जोड़ें, ऑन-कॉल ज्ञान घुमाएं, "टीच-बैक" सत्र चलाएं जहां विशेषज्ञ दस्तावेज़ीकरण करता है जबकि एक सहकर्मी साथ चलता है, और किसी भी एक व्यक्ति को एकमात्र ऐसा होने से मना करें जो एक सुरक्षा-महत्वपूर्ण सेवा को तैनात या पुनर्प्राप्त कर सकता है। यह एक आउटेज के दौरान अंतराल खोजने से सस्ता है।

7. ऐसी घटना-पश्चात समीक्षाएं चलाएं जो अभ्यास बदलें, लोगों को दोष न दें। किसी भी महत्वपूर्ण घटना के बाद, एक दोष-मुक्त घटना-पश्चात समीक्षा चलाएं जो दस्तावेज़ीकृत, स्वामित्व वाली, समय-सीमित कार्रवाइयां उत्पन्न करती है — और फिर वास्तव में उन्हें बंद करें। सीखे गए सबक जो दायर किए जाते हैं और कभी फिर से नहीं देखे जाते वे थिएटर हैं; प्रक्रिया का परीक्षण यह है कि क्या समान आकार की बाद की घटना रोकी जाती है। निष्कर्षों को सीधे रनबुक और क्लिनिकल-सुरक्षा मामले में वापस फ़ीड करें (विषय 3.8 — सेवा प्रबंधन और लाइव संचालन देखें)।

8. सूचना वास्तुकला और खोजने योग्यता में निवेश करें। अपने ज्ञान आधार को संरचित करें ताकि एक नया शामिल होने वाला एक मिनट से कम में ऑन-कॉल रनबुक ढूंढ सके, और आक्रामक रूप से छांटें — एक पुरानी पृष्ठ एक संपत्ति नहीं, एक देनदारी है। नामकरण परंपराओं, एक स्पष्ट पदानुक्रम, और हर क्षेत्र के लिए एक स्वामी पर सहमत हों, और महत्वपूर्ण पृष्ठों पर एक "आखिरी बार समीक्षित" तारीख रखें ताकि पाठक ताज़गी का न्याय कर सकें। खोज संरचना का विकल्प नहीं है; यह इसका पूरक है।

9. अंतर्निहित ज्ञान फैलाने के लिए अभ्यास समुदाय बढ़ाएं। उन शिल्पों के लिए क्रॉस-टीम गिल्ड खड़े करें जो मायने रखते हैं — क्लिनिकल सुरक्षा, सुरक्षा, फ्रंट-एंड, डेटा इंजीनियरिंग — एक हल्के जनादेश के साथ: आप जो सीख रहे हैं उसे साझा करें, सामान्य पैटर्न पर सहमत हों, नवागंतुकों को मेंटर करें। ये मंच उस अंतर्निहित ज्ञान को चलाते हैं जिसे कोई दस्तावेज़ कैप्चर नहीं करता, और वे टीमों में दोहराई गई गलतियों को कम करते हैं (विषय 7.5 — लोग और संगठनात्मक विकास देखें)। उन्हें कार्य सप्ताह में समय दें, या वे मुरझा जाएंगे।

10. टीम दस्तावेज़ीकरण को वैधानिक रिकॉर्ड से अलग करें — और दोनों को प्रबंधित करें। इस बारे में स्पष्ट रहें कि टीम ज्ञान (रनबुक, ADR, विकी) क्या है बनाम कानूनी प्रतिधारण के अधीन एक रिकॉर्ड (क्लिनिकल रिकॉर्ड, देखभाल निर्णय, वित्तीय अनुमोदन, सूचना-प्रशासन निर्णय) क्या है। बाद वाले पर NHS Records Management Code of Practice प्रतिधारण अनुसूचियां लागू करें, और आकस्मिक विकी विलोपन को कुछ ऐसा नष्ट न करने दें जिसे रखना आप कानूनी रूप से बाध्य थे। समान रूप से, "सुरक्षित रहने के लिए" हर चीज़ को हमेशा के लिए जमा न करें — अति-प्रतिधारण अपने आप में एक प्रशासन और डेटा-सुरक्षा जोखिम है।

11. ऑनबोर्डिंग को अपने दस्तावेज़ीकरण का परीक्षण बनाएं। हर ऑनबोर्डिंग को एक लाइव ऑडिट के रूप में मानें: यदि एक सक्षम नया इंजीनियर या चिकित्सक आपकी लिखित सामग्री और थोड़ी पेयरिंग से उत्पादक नहीं हो सकता, तो आपका दस्तावेज़ीकरण विफल हो गया है, और जो अंतराल वे मारते हैं वे आपका बैकलॉग हैं। नए शामिल होने वालों से पहली चीज़ ठीक करने के लिए कहें जिसने उन्हें उनके पहले योगदान के रूप में भ्रमित किया। यह ऑनबोर्डिंग को एक तरफ़ा लागत से ज्ञान निरंतरता के लिए एक निरंतर सुधार लूप में बदल देता है।

आपकी टीम के साथ चर्चा करने के लिए प्रश्न#

1. यदि हमारे सबसे महत्वपूर्ण एकीकरण को समझने वाला एकमात्र व्यक्ति कल चला जाए, तो हम कितने समय तक उजागर रहेंगे — और विशेष रूप से हम क्या नहीं जानेंगे? यह बस फ़ैक्टर के अमूर्त विचार को आपकी सबसे महत्वपूर्ण प्रणालियों के एक ठोस तनाव परीक्षण में बदल देता है। एक वास्तविक उदाहरण के माध्यम से काम करें — पैथोलॉजी फ़ीड, सिंगल-साइन-ऑन कॉन्फ़िगरेशन, साझा देखभाल रिकॉर्ड का मिलान तर्क — और ईमानदारी से पूछें कि उस व्यक्ति के बिना और कौन इसे संचालित, बदल, और पुनर्प्राप्त कर सकता है। सतह पर लाने के लिए तनाव यह है कि सबसे गहरा ज्ञान आमतौर पर आपके सबसे व्यस्त, सबसे भरोसेमंद व्यक्ति के पास बैठता है, और डिलीवरी के दबाव उनके लिए यह तर्कसंगत बनाते हैं कि वे कभी न रुकें और इसे लिखें। उस ज्ञान को अलग करें जो वास्तव में अंतर्निहित और संहिताबद्ध करना कठिन है उस ज्ञान से जिसे बस किसी ने कभी कैप्चर नहीं किया क्योंकि किसी ने समय नहीं निकाला। एक अच्छा, ईमानदार उत्तर आपकी बस-फ़ैक्टर-एक प्रणालियों को ज़ोर से नाम देता है, स्वीकार करता है कि कौन से अंतराल वास्तविक हैं, और एक लागत वाली योजना — पेयरिंग, दस्तावेज़ीकरण स्प्रिंट, क्रॉस-प्रशिक्षण — उत्पन्न करता है बजाय एक अस्पष्ट आश्वासन के कि "यह सब लोगों के सिर में है और यह ठीक है"। यदि बातचीत आरामदायक है, तो आप पर्याप्त विशिष्ट नहीं रहे हैं।

2. जब हम कुछ लिखते हैं, तो हमें कैसे पता चलेगा कि कोई इसे कभी ढूंढेगा, इस पर भरोसा करेगा, और इसे वर्तमान रखेगा — और हमारा दस्तावेज़ीकरण कहां पहले से हमसे झूठ बोल रहा है? दस्तावेज़ीकरण जो पुराना है वह तटस्थ नहीं है; एक सुरक्षा-महत्वपूर्ण सेटिंग में यह सक्रिय रूप से एक तनावग्रस्त संचालक को गलत कार्रवाई की ओर गुमराह करता है। चर्चा को दस्तावेज़ होने और ऐसे दस्तावेज़ होने के बीच अंतर का सामना करना चाहिए जिन्हें लोग ढूंढ सकते हैं, भरोसा कर सकते हैं, और उन पर कार्य कर सकते हैं — सूचना वास्तुकला, स्वामित्व, और ताज़गी का प्रश्न, वॉल्यूम नहीं। बहस करें कि क्या आपके ज्ञान आधार की एक वास्तविक संरचना है या यह एक प्रसार बन गया है जिसे कोई नेविगेट नहीं करता, और क्या दस्तावेज़ काम के इतने करीब रहते हैं (docs-as-code) कि वर्तमान बने रहें या एक अलग उपकरण में बहते हैं जिसे कोई अपडेट नहीं करता। हर व्यक्ति से पूछें कि उन्होंने आखिरी बार कब एक आंतरिक दस्तावेज़ पर भरोसा किया और इसे गलत पाया, और इसकी क्या कीमत चुकाई। एक मज़बूत उत्तर विशिष्ट पृष्ठों की पहचान करता है जिन्हें आप बासी जानते हैं, स्वामी और समीक्षा तारीखें सौंपता है, और उन तथ्यों के लिए एक एकल सत्य स्रोत पर सहमत होता है जो सबसे अधिक मायने रखते हैं — और यह जोड़ने से अधिक हटाने के इच्छुक है।

3. हमारी आखिरी गंभीर घटना के बाद, हम कैसे काम करते हैं इसमें वास्तव में क्या बदला — और यदि उत्तर "बहुत कुछ नहीं" है, तो हम समीक्षाएं चलाना क्यों जारी रखते हैं? घटना-पश्चात समीक्षाएं आम हैं; समीक्षाएं जो अभ्यास बदलती हैं वे दुर्लभ हैं, और दोनों के बीच का अंतर वह जगह है जहां वही विफलताएं फिर से होती हैं। यह परीक्षण करता है कि क्या आपकी सीखे-गए-सबक प्रक्रिया एक वास्तविक फीडबैक लूप है या एक अनुष्ठान जो एक दस्तावेज़ उत्पन्न करता है और कोई परिवर्तन नहीं। सांस्कृतिक शर्तों का ईमानदारी से अन्वेषण करें: समीक्षाएं केवल तभी सत्य को सतह पर लाती हैं जब वे दोष-मुक्त हों, और लोग वास्तविक कारण छुपाएंगे यदि प्रक्रिया उन्हें दंडित करती है, इसलिए मनोवैज्ञानिक सुरक्षा एक पूर्वापेक्षा है, एक अच्छाई नहीं (विषय 8.1 — परिवर्तन प्रबंधन देखें)। अपनी पिछली कुछ घटनाओं को देखें और हर कार्रवाई को ट्रेस करें कि क्या यह पूरी हुई और क्या इसने पुनरावृत्ति को रोका। एक अच्छा उत्तर एक ठोस परिवर्तन की ओर इशारा कर सकता है — एक फिर से लिखा गया रनबुक, एक नया अलर्ट, एक डिज़ाइन फिक्स — जो एक पिछली समीक्षा ने उत्पन्न किया, और उन कार्रवाइयों के बारे में स्पष्ट है जो लॉग की गईं और चुपचाप छोड़ दी गईं, उस लूप को बंद करने की एक योजना के साथ।

4. हमारे पास मौजूद चीज़ों में से कौन सी वैधानिक रिकॉर्ड हैं जिन्हें रखना हम कानूनी रूप से बाध्य हैं, कौन सी काम करने के नोट्स हैं जिन्हें हम ताज़गी के लिए प्रबंधित करते हैं — और क्या हमें विश्वास है कि हम पहले को नहीं हटा रहे हैं या दूसरे को जमा नहीं कर रहे हैं? स्वास्थ्य और देखभाल संगठन प्रतिधारण कर्तव्य वहन करते हैं जिन्हें अधिकांश डिजिटल टीमें नियम के बजाय प्रवृत्ति से संभालती हैं, और त्रुटि की दोनों दिशाएं वास्तविक हैं: एक विकी पृष्ठ को आकस्मिक रूप से हटाना जो एक देखभाल निर्णय का दस्तावेज़ीकरण निकला, या "सुरक्षित रहने के लिए" हर चीज़ को हमेशा के लिए जमा करना और एक डेटा-सुरक्षा और खोजने-योग्यता देनदारी बनाना। चर्चा को NHS Records Management Code of Practice के अधीन एक रिकॉर्ड — क्लिनिकल रिकॉर्ड, देखभाल और वित्तपोषण निर्णय, सूचना-प्रशासन निर्णय — और टीम ज्ञान जैसे रनबुक और ADR के बीच एक स्पष्ट रेखा को मजबूर करना चाहिए जिसे आप कानूनी प्रतिधारण के लिए नहीं, ताज़गी के लिए प्रबंधित करते हैं। असुविधाजनक मध्य मामलों को सतह पर लाएं, जैसे एक ADR जो दस्तावेज़ीकृत करता है कि एक क्लिनिकल-सुरक्षा खतरा क्यों स्वीकार किया गया, जो दोनों हो सकता है। तनाव यह है कि इंजीनियर साफ़, वर्तमान दस्तावेज़ीकरण के लिए अनुकूलित करते हैं जबकि प्रशासन रक्षणीय प्रतिधारण के लिए अनुकूलित करता है, और दोनों प्रवृत्तियां विपरीत दिशाओं में खींचती हैं। एक ईमानदार उत्तर कह सकता है कि प्रतिधारण अनुसूची का स्वामी कौन है, सीमा कहां खींची गई है, और यदि एक विशिष्ट रिकॉर्ड को वर्षों से एक कोरोनर, एक नियामक, या एक Freedom of Information अनुरोध द्वारा मांगा जाए तो क्या होगा।

5. हमारे काम करने के तरीकों में वास्तव में क्या दस्तावेज़ीकरण को तब लिखे जाने का कारण बनता है जब ज्ञान ताज़ा है — और हम अभी भी कहां सद्भावना और अच्छे इरादों पर निर्भर हैं? हर टीम सहमत होती है कि दस्तावेज़ीकरण मायने रखता है; बहुत कम के पास एक तंत्र है जो इसे वीरता के बजाय डिफ़ॉल्ट रूप से होने देता है। यह प्रश्न जांचता है कि क्या चीज़ें लिखना काम के प्रवाह में इंजीनियर किया गया है — एक परिभाषा-का-पूर्ण जो बिना रनबुक प्रविष्टि या ADR के "पूर्ण" को ब्लॉक करती है, परिवर्तन के समान पुल अनुरोध में समीक्षित दस्तावेज़ीकरण, docs-as-code ताकि आरेख उस चीज़ के बगल में रहे जिसका यह वर्णन करता है — या क्या यह व्यक्तियों पर निर्भर करता है जो रुकने और लिखने का चुनाव करते हैं जब डिलीवरी दबाव शिप करने के लिए कहता है। ईमानदारी से प्रोत्साहनों की जांच करें: छह महीने बाद स्मृति से एक सिस्टम को पुनः-दस्तावेज़ीकृत करना वह जगह है जहां खतरनाक अशुद्धियां पैदा होती हैं, इसलिए मूल्य लगभग पूरी तरह से इसे उस क्षण में कैप्चर करने में है। अपनी पिछली कुछ परिवर्तनों को देखें और पूछें कि क्या दस्तावेज़ीकरण उस व्यक्ति द्वारा लिखा गया था जिसके पास तब ज्ञान था, या बाद में किसी ऐसे व्यक्ति द्वारा जोड़ा गया जो इसे फिर से बना रहा था। एक मज़बूत उत्तर पहले से मौजूद ठोस तंत्रों की ओर इशारा करता है और उन अंतरालों को नाम देता है जहां प्रक्रिया अभी भी स्मृति और इच्छाशक्ति पर निर्भर करती है, उन्हें बंद करने की एक योजना के साथ।

6. हम उस ज्ञान को कैसे स्थानांतरित करते हैं जिसे कोई दस्तावेज़ कभी कैप्चर नहीं करेगा — निर्णय और "आपको यह जानना होगा कि यह ट्रस्ट डिस्चार्ज को अलग तरीके से कोड करता है" — और क्या यह हर बार एक ठेकेदार का अनुबंध समाप्त होने पर कठिन हो जाता है? एक सेवा को सुरक्षित रखने वाली बहुत सी चीज़ें अंतर्निहित हैं: अंतर्ज्ञान, पैटर्न पहचान, और कठिनाई से अर्जित संदर्भ जो लिखे जाने का विरोध करता है, और SECI मॉडल एक अनुस्मारक है कि केवल दस्तावेज़ीकरण इसे कभी पूरी तरह बाह्यीकृत नहीं करता। यह प्रश्न पूछता है कि आप उस ज्ञान को पेयरिंग, शैडोइंग, टीच-बैक सत्रों, और अभ्यास समुदायों के माध्यम से कितनी जानबूझकर फैलाते हैं, बजाय यह मानने के कि विकी काम करता है। तनाव सबसे तीव्र है जहां आप ठेकेदारों और कई आपूर्तिकर्ताओं पर निर्भर हैं, क्योंकि उनका सबसे गहरा ज्ञान हर सगाई के अंत में दरवाज़े से बाहर चला जाता है जब तक कि कैप्चर एक अनुबंधात्मक और सांस्कृतिक अपेक्षा न हो, अंतिम सप्ताह में मांगा गया एक एहसान न हो। चर्चा करें कि क्या आपके शिल्पों — क्लिनिकल सुरक्षा, एकीकरण, डेटा इंजीनियरिंग — के पास संरक्षित समय के साथ जीवित गिल्ड हैं, या क्या क्रॉस-टीम सीखना केवल संयोग से होता है। एक ईमानदार उत्तर उस ज्ञान को अलग करता है जो वास्तव में अंतर्निहित है और व्यक्ति-से-व्यक्ति स्थानांतरण की आवश्यकता रखता है उस ज्ञान से जो केवल अकैप्चर्ड है, और वास्तविक प्रथाओं की ओर इशारा कर सकता है — एक पेयरिंग रोटा, जाने वाले ठेकेदारों के लिए एक ज्ञान-निरंतरता योजना, एक सक्रिय अभ्यास समुदाय — एक आकांक्षा के बजाय।

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

एक integrated care system (ICS) एक साझा देखभाल रिकॉर्ड चलाता है जो तीन तीव्र ट्रस्टों, सामुदायिक सेवाओं, और एक सामाजिक-देखभाल केस-प्रबंधन प्रणाली से डेटा खींचता है। एकीकरण दो साल पहले काफी हद तक एक अनुबंध इंजीनियर, "Dev" द्वारा बनाया गया था, जो मिलान तर्क की हर विचित्रता समझता था जो तय करती है कि कब दो रिकॉर्ड एक ही व्यक्ति को संदर्भित करते हैं। Dev का अनुबंध छह हफ्तों में समाप्त होता है। एक विकी है, लेकिन इसे आखिरी बार निर्माण के दौरान सार्थक रूप से अपडेट किया गया था।

डिलीवरी नेता इसे एक बस-फ़ैक्टर-एक जोखिम मानती है और इसे अपने नाम के साथ प्रोग्राम जोखिम रजिस्टर पर डालती है। छह हफ्तों में, वह एक छोटा "ज्ञान निरंतरता" प्रयास वित्तपोषित करती है: Dev हर सुबह दो स्थायी इंजीनियरों के साथ जोड़ी बनाता है, और एक विदाई ब्रेन-डंप के बजाय वे जाते-जाते बाह्यीकृत करते हैं — Dev जिन विफलता मोड को दिल से जानता है उनके लिए रनबुक लिखना, और ADR यह समझाते हुए कि क्यों मिलान तर्क कुछ बेमेल सहन करता है (यह निकलता है कि एक स्पष्ट रूप से लापरवाह नियम मूल क्लिनिकल-सुरक्षा मामले में फ्लैग किए गए एक ज्ञात रोगी-सुरक्षा खतरे से बचने के लिए मौजूद है)। दस्तावेज़ एकीकरण कोड के समान Git रिपॉज़िटरी में जाते हैं, पुल अनुरोधों में समीक्षित, इसलिए वे संस्करणित और वर्तमान हैं।

Dev के जाने के दो महीने बाद, एक तीव्र ट्रस्ट से फ़ीड रातों-रात दोहरे रोगी रिकॉर्ड उत्पन्न करना शुरू करती है। ऑन-कॉल इंजीनियर — जो कभी Dev से नहीं मिला — रनबुक खोलता है, संख्याबद्ध कदमों का पालन करता है, हर चरण में अपेक्षित परिणाम की पुष्टि करता है, और एक घंटे के भीतर सही मिलान बहाल करता है। दोष-मुक्त घटना-पश्चात समीक्षा में टीम ट्रिगर पाती है (ट्रस्ट NHS नंबरों को कैसे कोड करता है इसमें एक अपस्ट्रीम परिवर्तन) और इसे एक मॉनिटरिंग अलर्ट और एक रनबुक अपडेट में बदल देती है। जो एक बहु-दिवसीय, उच्च-जोखिम संघर्ष होता — और एक वास्तविक रोगी-सुरक्षा घटना — वह एक दस्तावेज़ीकृत, एक घंटे की पुनर्प्राप्ति बन गई, क्योंकि अंतर्निहित ज्ञान को स्पष्ट बनाया गया था जबकि इसे रखने वाला व्यक्ति अभी भी वहां था।

क्षेत्र दृष्टिकोण#

स्टार्टअप#

एक डिजिटल-स्वास्थ्य स्टार्टअप सबसे उच्च बस-फ़ैक्टर जोखिम और इसे संबोधित करने के लिए सबसे कम ढील के साथ रहता है: मुट्ठी भर इंजीनियर, हर सिर में गहरा ज्ञान, और एक संस्कृति जो लिखने पर शिपिंग को महत्व देती है। व्यावहारिक कदम वर्कफ़्लो में एम्बेडेड हल्का, सस्ता दस्तावेज़ीकरण है — रिपॉज़िटरी में छोटी Markdown फ़ाइलों के रूप में ADR, पहली बार कुछ टूटने पर लिखे गए रनबुक, पहले दिन से docs-as-code ताकि आदत पैमाने से पहले बने जो इसे कठिन बना देता है। संस्थापकों को "उत्पाद-बाज़ार फिट के बाद" तक सभी दस्तावेज़ीकरण को टालने के प्रलोभन का विरोध करना चाहिए, क्योंकि एक क्लिनिकल उत्पाद में एक आउटेज, या साक्ष्य की कमी के लिए एक विफल क्लिनिकल-सुरक्षा या DTAC (Digital Technology Assessment Criteria) मूल्यांकन, अस्तित्वगत हो सकता है। लक्ष्य एक पॉलिश ज्ञान आधार नहीं बल्कि यह सुनिश्चित करना है कि कोई एकल प्रस्थान कंपनी को डुबो नहीं सकता।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, या एक एकल-साइट क्लिनिक — एक बड़े ट्रस्ट के समान क्लिनिकल-सुरक्षा और रिकॉर्ड-प्रतिधारण कर्तव्य वहन करता है लेकिन बिना किसी समर्पित IT या ज्ञान-प्रबंधन फ़ंक्शन के और एक बनाने के लिए थोड़ी ढील के साथ। यहां अभ्यास को मौलिक रूप से आनुपातिक होना चाहिए: मुट्ठी भर रनबुक के लिए एक खोजने योग्य स्थान जो मायने रखते हैं (क्लिनिकल सिस्टम को कैसे पुनर्प्राप्त करें, साझा देखभाल रिकॉर्ड विफल होने पर किसे कॉल करें), एक सरल नामित-स्वामी व्यवस्था ताकि महत्वपूर्ण ज्ञान केवल प्रैक्टिस मैनेजर या एक लंबे समय से सेवारत नर्स के साथ न बैठे, और वैधानिक रिकॉर्ड जिन्हें वे कानूनी रूप से रखने के लिए बाध्य हैं और काम करने वाले नोट्स के बीच एक स्पष्ट रेखा जो वे नहीं हैं। तीव्र जोखिम निरंतरता के रूप में सजी एक की बस फ़ैक्टर है: वह व्यक्ति जो जानता है कि सब कुछ कैसे कॉन्फ़िगर किया गया है वह भी दिन-प्रतिदिन चला रहा है, और एक सेवानिवृत्ति या एक लंबी बीमारी एक सुरक्षा-महत्वपूर्ण प्रणाली को संचालित करने में सक्षम किसी को नहीं छोड़ सकती। जहां प्रणालियां एक विक्रेता द्वारा आपूर्ति और होस्ट की जाती हैं, छोटे प्रदाता को अभी भी अपना स्वयं का स्थानीय कॉन्फ़िगरेशन और वर्कअराउंड लिखना चाहिए, क्योंकि आपूर्तिकर्ता यह दस्तावेज़ीकृत नहीं करेगा कि यह संगठन वास्तव में उत्पाद का उपयोग कैसे करता है।

बड़ा संगठन#

एक बड़े NHS ट्रस्ट, ICS, या स्वास्थ्य-तकनीक आपूर्तिकर्ता विपरीत विफलता का सामना करता है: बहुत अधिक दस्तावेज़ीकरण, SharePoint, Confluence, नेटवर्क ड्राइव, और ईमेल में बिखरा हुआ, बिना किसी एकल सत्य स्रोत और खराब खोजने-योग्यता के साथ। उद्यम चुनौती सूचना वास्तुकला, स्वामित्व, और छंटाई है — यह तय करना कि हर तथ्य कहां मास्टर किया गया है, स्वामी सौंपना, डुप्लिकेट सेवानिवृत्त करना, और ज्ञान प्रबंधन को सेवा प्रबंधन और परिवर्तन नियंत्रण से जोड़ना। अभ्यास समुदाय यहां अपनी कीमत अर्जित करते हैं, दर्जनों टीमों में पैटर्न फैलाते हैं जो अन्यथा प्रत्येक दर्द से एक ही सबक सीखेंगी। प्रबंधित करने के लिए जोखिम भारी ठेकेदार और बहु-आपूर्तिकर्ता उपयोग है, जहां ज्ञान हर अनुबंध के अंत में दरवाज़े से बाहर चला जाता है जब तक कि कैप्चर एक अनुबंधात्मक और सांस्कृतिक अपेक्षा न हो।

सरकार#

एक राष्ट्रीय या स्थानीय सार्वजनिक निकाय — NHS England, DHSC, UKHSA, या एक स्थानीय अधिकारी — वैधानिक रिकॉर्ड-प्रबंधन कर्तव्यों, Freedom of Information दायित्वों, और सार्वजनिक-ऑडिट जांच के तहत संचालित होता है, इसलिए ज्ञान प्रबंधन आंशिक रूप से कानून और सार्वजनिक जवाबदेही का मामला है। सेवाओं, पैसे, और नीति के बारे में निर्णयों को दस्तावेज़ीकृत, परिभाषित अवधियों के लिए बनाए रखा, और चयन समितियों, National Audit Office समीक्षाओं, और सार्वजनिक जांचों के लिए वर्षों बाद खोजने योग्य होना चाहिए; प्रमुख जांचों का हालिया इतिहास दिखाता है कि खराब रिकॉर्ड-रखरखाव कैसे अपने आप में एक घोटाला बन जाता है। सरकार को वैधानिक रिकॉर्ड (अनुसूची द्वारा रखे और निपटाए गए) और काम करने वाले ज्ञान (ताज़गी के लिए प्रबंधित) के बीच रेखा पकड़नी चाहिए, अनुशासन के साथ NHS Records Management Code of Practice लागू करते हुए। पारदर्शिता वॉचवर्ड है: कार्यशील धारणा यह होनी चाहिए कि दस्तावेज़ीकरण किसी दिन जनता द्वारा पढ़ा जा सकता है।

सामान्य विफलता मोड#

• नायक और एक की बस फ़ैक्टर। उस व्यक्ति का जश्न मनाना जो "बस जानता है" जबकि उस ज्ञान को फैलाने के काम को कभी वित्तपोषित नहीं करना। यह तब तक कुशल महसूस होता है जब तक वह उपलब्ध नहीं होता और एक सुरक्षा-महत्वपूर्ण सेवा के पास इसे संचालित करने वाला कोई नहीं होता।
• एक-बार लिखे गए दस्तावेज़। एक निर्माण के दौरान बनाए गए दस्तावेज़ और फिर कभी नहीं छुए गए, आत्मविश्वासी झूठ में बहते हुए। बासी दस्तावेज़ किसी न होने से अधिक खतरनाक हैं, क्योंकि लोग उन पर कार्य करते हैं।
• विकी लैंडफिल। हज़ारों पृष्ठ, कोई संरचना नहीं, कोई स्वामी नहीं, कोई समीक्षा तारीख नहीं — ज्ञान जो तकनीकी रूप से मौजूद है लेकिन ढूंढा या भरोसा नहीं किया जा सकता। वॉल्यूम को मूल्य समझ लिया गया।
• काम से दूर दस्तावेज़। कोडिंग करते समय कोई न खोलने वाले एक अलग उपकरण में दस्तावेज़ीकरण, इसकी वास्तविकता से भिन्न होने की गारंटी देते हुए। Docs-as-code इसका मारक है।
• सीखे-गए-सबक थिएटर। घटना-पश्चात समीक्षाएं जो एक दस्तावेज़ और कार्रवाइयों की एक सूची उत्पन्न करती हैं जो कभी बंद नहीं होतीं, ताकि वही घटना फिर से हो। प्रक्रिया अनुष्ठान बन जाती है, सुधार नहीं।
• रिकॉर्ड को नोट्स के साथ भ्रमित करना। या तो कुछ ऐसा हटाना जिसे रखना आप कानूनी रूप से बाध्य थे, या हर चीज़ को हमेशा के लिए जमा करना और एक डेटा-सुरक्षा और खोजने-योग्यता देनदारी बनाना। दोनों वैधानिक रिकॉर्ड को टीम दस्तावेज़ीकरण से अलग न करने से उत्पन्न होते हैं।
• समीक्षा कक्ष में दोष। समीक्षाएं जो विफलता के निकटतम व्यक्ति को दंडित करती हैं, जो सभी को वास्तविक कारण छुपाना सिखाती हैं और उस ईमानदारी को नष्ट करती हैं जिस पर प्रक्रिया निर्भर करती है।

परिपक्वता मॉडल#

जांच-सूची#

• हर महत्वपूर्ण प्रणाली में एक सेवा मैनुअल, एक अद्यतन रनबुक, और इसके महत्वपूर्ण निर्णयों के लिए ADR हैं।
• दस्तावेज़ीकरण आपकी परिभाषा-का-पूर्ण का हिस्सा है और परिवर्तन के समान पुल अनुरोध में समीक्षित है।
• हर डोमेन में एक नामित एकल सत्य स्रोत है; ज्ञात डुप्लिकेट हटाए या पुनर्निर्देशित किए गए हैं।
• बस-फ़ैक्टर-एक प्रणालियां स्वामियों और एक सक्रिय क्रॉस-प्रशिक्षण योजना के साथ जोखिम रजिस्टर पर हैं।
• रनबुक का परीक्षण किसी ऐसे व्यक्ति द्वारा किया गया है जिसने उन्हें एक ड्रिल या एक वास्तविक घटना में नहीं लिखा।
• घटना-पश्चात समीक्षाएं दोष-मुक्त हैं और स्वामित्व, समय-सीमित कार्रवाइयां उत्पन्न करती हैं जो बंद होती हैं।
• ज्ञान आधार में एक स्पष्ट संरचना, पृष्ठ स्वामी, और समीक्षा तारीखें हैं; बासी पृष्ठ छांटे गए हैं।
• टीमों में फैले एक शिल्प के लिए कम से कम एक सक्रिय अभ्यास समुदाय मौजूद है, इसके लिए समय संरक्षित है।
• वैधानिक रिकॉर्ड को टीम दस्तावेज़ीकरण से अलग किया गया है और सही प्रतिधारण अनुसूची में प्रबंधित किया गया है।
• नए शामिल होने वालों से एक प्रारंभिक योगदान के रूप में उनके द्वारा मारे गए पहले दस्तावेज़ीकरण अंतराल को ठीक करने के लिए कहा जाता है।

मुख्य स्रोत#

• NHS England / NHSX, Records Management Code of Practice 2021 — स्वास्थ्य और देखभाल रिकॉर्ड के लिए वैधानिक प्रतिधारण अनुसूचियां और जीवनचक्र कर्तव्य।
• GOV.UK Service Manual (Government Digital Service) — डिजिटल सेवाओं के लिए लिखने और उन्हें चलाने पर मार्गदर्शन, दस्तावेज़ीकरण और एक सेवा संचालित करना सहित।
• NHS Digital Service Standard — टिकाऊ, अच्छी तरह से दस्तावेज़ीकृत डिजिटल सेवाओं के निर्माण और रखरखाव के लिए अपेक्षाएं।
• Michael Nygard, "Documenting Architecture Decisions" (2011) — आर्किटेक्चर निर्णय रिकॉर्ड (ADR) के लिए मूल पैटर्न।
• Google, Site Reliability Engineering — दोष-मुक्त घटना-पश्चात समीक्षाएं (पोस्टमॉर्टम), रनबुक, और परिचालन मुख्य-व्यक्ति जोखिम को कम करना।
• Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity (1998) — अभ्यास समुदायों पर मूलभूत पाठ।
• Nonaka & Takeuchi, The Knowledge-Creating Company (1995) — अंतर्निहित-से-स्पष्ट ज्ञान रूपांतरण का SECI मॉडल।
• The Write the Docs समुदाय — docs-as-code और दस्तावेज़ीकरण को एक उत्पाद के रूप में मानने पर व्यवसायी मार्गदर्शन।

संदर्भ#

1. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
2. Tacit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Tacit_knowledge
3. Explicit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Explicit_knowledge
4. SECI model of knowledge dimensions — Wikipedia — https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions
5. Bus factor — Wikipedia — https://en.wikipedia.org/wiki/Bus_factor
6. Runbook — Wikipedia — https://en.wikipedia.org/wiki/Runbook
7. Architectural decision — Wikipedia — https://en.wikipedia.org/wiki/Architectural_decision
8. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
9. Community of practice — Wikipedia — https://en.wikipedia.org/wiki/Community_of_practice
10. Records management — Wikipedia — https://en.wikipedia.org/wiki/Records_management
11. Information architecture — Wikipedia — https://en.wikipedia.org/wiki/Information_architecture
12. Postmortem documentation — Wikipedia — https://en.wikipedia.org/wiki/Postmortem_documentation
13. Onboarding — Wikipedia — https://en.wikipedia.org/wiki/Onboarding
14. Records Management Code of Practice 2021 — NHS England / NHSX — https://www.nhsx.nhs.uk/information-governance/guidance/records-management-code/
15. Service manual — Government Digital Service (GOV.UK) — https://www.gov.uk/service-manual
16. Documenting Architecture Decisions — Michael Nygard — https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
17. Site Reliability Engineering — Google — https://sre.google/books/
18. Write the Docs — docs-as-code guidance — https://www.writethedocs.org/guide/docs-as-code/