विषय 2.0 — कार्य इनटेक

एक वाक्य में: काम आपके संगठन में कैसे प्रवेश करता है — एक दृश्यमान फ्रंट डोर के माध्यम से, लगातार कैप्चर किया गया, और तुरंत स्वीकृत — यह निर्धारित करता है कि क्या आप कभी यह चुनने में सक्षम होंगे कि आप क्या करते हैं, या केवल जो भी सबसे ज़ोर से चिल्लाता है उस पर प्रतिक्रिया करते हैं।

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

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

सार्वजनिक धन दांव को बढ़ाता है। अनमूल्यांकित, अरिकॉर्डेड मांग पर आप जो भी डिजिटल क्षमता की इकाई खर्च करते हैं वह वेटिंग लिस्ट, साझा देखभाल रिकॉर्ड, या अंतरसंचालनीयता कार्य पर खर्च नहीं की गई क्षमता है जिस पर एक प्रणाली निर्भर करती है। नियामक, ऑडिटर, और Integrated Care Boards (ICB) तेज़ी से "यह कैसे प्राथमिकता में आया?" का एक बचाव योग्य उत्तर अपेक्षा करते हैं — और आप इसका उत्तर नहीं दे सकते अगर आप यह भी नहीं दिखा सकते कि यह कैसे आया। अच्छा इनटेक एक प्रशासित, न्यायसंगत, साक्ष्य-आधारित संचालन मॉडल में पहला नियंत्रण बिंदु है (देखें विषय 1.1 — संचालन मॉडल, और विषय 1.3 — साक्ष्य-आधारित निर्णय)।

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

इनटेक हर इकाई मांग को प्राप्त करने, रिकॉर्ड करने, वर्गीकृत करने, और स्वीकार करने की अनुशासित प्रक्रिया है इससे पहले कि क्या और कैसे करना है इसके बारे में कोई निर्णय लिया जाए। यह जानबूझकर त्रिआज (आकलन और रूटिंग — विषय 2.1) और प्राथमिकता-निर्धारण (क्रम देना — विषय 2.2) से अलग है। इनटेक का एकमात्र काम मांग को दृश्यमान और तुलनीय बनाना है।

मांग प्रबंधन, ITIL (IT Infrastructure Library) सेवा-प्रबंधन परंपरा में, मांग का अनुमान लगाने और उसे इस तरह चैनल करने का अभ्यास है ताकि इसे "अनियोजित लागत लगाए बिना" पूरा किया जा सके। इसका केंद्रीय उपकरण एकल फ्रंट डोर है: एक मार्ग जिसके माध्यम से सभी अनुरोध एकत्र किए जाते हैं, ताकि कुछ भी खोया न जाए या अनौपचारिक चैनलों के माध्यम से प्रोसेस न किया जाए। ITIL 4 इसे एक सेवा कैटलॉग (फ्रंट डोर स्वयं) प्लस सेवा अनुरोध प्रबंधन (जब कोई इसके माध्यम से चलता है तो क्या होता है) के रूप में तैयार करता है।

मांग के प्रकार आपस में बदले जाने योग्य नहीं हैं, और उन्हें मिलाना डिसफ़ंक्शन का एक सामान्य स्रोत है। एक उपयोगी कामकाजी वर्गीकरण:

• विचार / अवसर — "क्या यह अच्छा नहीं होगा अगर…"; अप्रमाणित, डिस्कवरी की आवश्यकता।
• अनुरोध / संवर्धन — एक मौजूदा सेवा में एक परिभाषित परिवर्तन।
• घटनाएं / समस्याएं — कुछ अभी टूटा या असुरक्षित है; आमतौर पर एक अलग, तेज़ परिचालन मार्ग।
• अधिदेश — वैधानिक, नियामक, या राष्ट्रीय रूप से निर्देशित कार्य (जैसे एक NHS England राष्ट्रीय कार्यक्रम आवश्यकता) सीमित विवेकाधिकार के साथ।

हर प्रकार एक अलग डाउनस्ट्रीम मार्ग का हकदार है, लेकिन सभी को एक ही फ्रंट डोर से आना चाहिए और मांग के उसी बैकलॉग में दर्ज किया जाना चाहिए।

शैडो इनटेक — शैडो IT का मांग-पक्ष चचेरा भाई — विरोधी-पैटर्न है: मांग जो फ्रंट डोर को दरकिनार करती है — गलियारा बातचीत, एक दोस्ताना डेवलपर को सीधा ईमेल, "त्वरित उपकार"। शैडो इनटेक अदृश्य, अप्रशासित है, और एक निष्पक्ष, सुरक्षित प्रणाली के लिए सबसे बड़ा एकल खतरा है।

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

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

2. एक हल्के, संरचित फ़ॉर्म के साथ मांग कैप्चर करें। केवल वही पूछें जिसकी आपको त्रिआज करने के लिए आवश्यकता है: अनुरोधकर्ता और सेवा, समस्या या मांगा गया परिणाम (समाधान नहीं), प्रभावित उपयोगकर्ता और मात्रा, कोई सुरक्षा या वैधानिक चालक, और तात्कालिकता की एक मोटी समझ। फ़ॉर्म को एक पूर्ण व्यावसायिक मामले में फुलाने का विरोध करें — अत्यधिक भारी इनटेक लोगों को शैडो चैनलों में वापस धकेलता है।

3. द्वार पर वर्गीकृत करें। हर वस्तु को मांग प्रकार (विचार / अनुरोध / घटना / अधिदेश), मूल सेवा, और क्या यह क्लिनिकल सुरक्षा या व्यक्तिगत डेटा को छूती है इसके द्वारा टैग करें। वर्गीकरण ही है जो आपको अनुरोधकर्ताओं को अपने आंतरिक तंत्र को समझाए बिना घटनाओं को एक तेज़ परिचालन मार्ग नीचे भेजने देता है जबकि विचार डिस्कवरी में जाते हैं।

4. घटना मार्ग को अलग करें — लेकिन इसे फिर भी रिकॉर्ड करें। कुछ असुरक्षित या अभी टूटा हुआ परिवर्तन अनुरोधों के पीछे कतार में नहीं लगना चाहिए। घटनाओं को तुरंत अपनी परिचालन/सेवा-डेस्क प्रक्रिया में रूट करें, लेकिन सुनिश्चित करें कि घटनाओं की मात्रा और पैटर्न इनटेक के लिए दृश्यमान रहे, क्योंकि आवर्ती घटनाएं अक्सर सबसे मज़बूत संकेत हैं कि परिवर्तन निवेश कहां जाना चाहिए।

5. पर्याप्त व्यावसायिक मामले के लिए पूछें — आकार के अनुपात में। छोटे अनुरोधों के लिए, अपेक्षित लाभ का एक वाक्य पर्याप्त है। बड़ी बोलियों के लिए, एक हल्का एक-पृष्ठ का मामला उपयोग करें: समस्या, इच्छित परिणाम और किसे लाभ होता है, मोटा आकार, मुख्य जोखिम, और इसे न करने की लागत। पूर्ण व्यावसायिक-मामला कठोरता (Green Book / Treasury पांच-मामला मॉडल) को वास्तविक निवेश निर्णयों के लिए आरक्षित रखें, हर विचार के लिए नहीं।

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

7. इनटेक कतार को सभी के लिए दृश्यमान बनाएं। मांग के बैकलॉग को प्रकाशित करें — कम से कम आंतरिक रूप से — ताकि अनुरोधकर्ता अपनी वस्तु, उसकी स्थिति, और दूसरों के सापेक्ष उसकी जगह देख सकें। पारदर्शिता "मेरी चीज़ से किसी ने निपटा क्यों नहीं?" को एक स्व-सेवा उत्तर में बदल देती है और प्रक्रिया की निष्पक्षता में विश्वास बनाती है।

8. एक इनटेक स्वामी और गति नाम दें। किसी को फ्रंट डोर का स्वामी होना चाहिए: यह सुनिश्चित करते हुए कि वस्तुएं पूर्ण, सही ढंग से वर्गीकृत, डी-डुप्लिकेटेड, और एक अनुमानित लय पर त्रिआज को सौंपी गई हैं (देखें विषय 2.1)। बिना स्वामी के इनटेक हफ्तों के भीतर गाद जाता है।

9. इनटेक मार्गों को सुलभ और न्यायसंगत बनाएं। सबसे तीव्र आवश्यकताओं वाले लोग — फ्रंटलाइन स्टाफ, सामाजिक-देखभाल प्रदाता, और शायद ही कभी सुने जाने वाले समुदाय — अक्सर एक पॉलिश किया गया अनुरोध प्रस्तुत करने में सबसे कम सक्षम होते हैं। प्रवेश के एक से अधिक तरीके प्रदान करें, भाषा को सादा रखें, और अनुरोधकर्ताओं को एक समाधान को पूर्व-निर्दिष्ट करने के बजाय अंतर्निहित समस्या को स्पष्ट करने में मदद करें। एक इनटेक प्रक्रिया जिसे केवल अच्छी तरह से संसाधित लोग ही नेविगेट कर सकते हैं चुपचाप पूरे पोर्टफोलियो को तिरछा कर देती है।

10. अनुरोधकर्ताओं के साथ लूप बंद करें। लोगों को बताएं कि उनके अनुरोध का क्या हुआ — स्वीकृत, मर्ज किया गया, पार्क किया गया, या अस्वीकृत — और क्यों, एक अनुमानित समय-सीमा पर। मौन इनटेक विश्वास नष्ट करती है और शैडो मांग और वर्कअराउंड को बढ़ावा देती है, जबकि ईमानदार, समय पर फीडबैक (यहां तक कि एक "नहीं") फ्रंट डोर को विश्वसनीय रखता है और पीछा करना कम करता है।

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

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

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

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

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

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

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

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

एक Integrated Care System (ICS) के पास डिजिटल मांग प्राप्त करने का कोई साझा तरीका नहीं था। ट्रस्ट प्रोग्राम निदेशक को ईमेल करते थे; आपूर्तिकर्ता क्लिनिकल निदेशकों की पैरवी करते थे; एक राष्ट्रीय अंतरसंचालनीयता अधिदेश पत्र द्वारा आया था; वार्ड स्टाफ ने कागज़ पर सुरक्षा चिंताएं उठाईं जो कभी डिजिटल टीम तक नहीं पहुंचीं। कोई नहीं बता सकता था कि कितनी मांग मौजूद है या कोई भी काम क्यों चल रहा है।

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

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

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

स्टार्टअप#

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

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

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

बड़ा संगठन#

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

सरकार#

NHS England, DHSC, एक विकेंद्रीकृत सरकार, या एक स्थानीय प्राधिकरण के स्तर पर, इनटेक पैमाने पर राष्ट्रीय मांग और सार्वजनिक धन को आकार देता है, और इसमें से बहुत कुछ अनुरोध के बजाय अधिदेश के रूप में आता है — वैधानिक कर्तव्य, मंत्री प्रतिबद्धताएं, व्यय-समीक्षा शर्तें। फ्रंट डोर अक्सर Treasury पांच-मामला मॉडल और Green Book द्वारा प्रशासित एक औपचारिक पोर्टफोलियो या निवेश पाइपलाइन है, इसलिए शुरू से ही शुरुआती विचारों को भी रणनीतिक फिट और मूल्य-के-लिए-धन के विरुद्ध कैप्चर किया जाता है। जोखिम भूख कम है और जांच अधिक है: National Audit Office और Public Accounts Committee की रुचि का अर्थ है कि हर स्वीकृत वस्तु में एक ट्रेस करने योग्य उद्गम और तर्क होना चाहिए। चुनौती आनुपातिकता है — बिना एक द्वार इतना भारी हो कि फ्रंटलाइन और स्थानीय-प्राधिकरण आवाज़ें, जिनके पास बोली-लेखन टीमें नहीं हैं, प्रभावी रूप से बाहर हो जाएं, खर्च का बचाव करने के लिए पर्याप्त कठोरता लागू करना। मांग पाइपलाइन की पारदर्शिता इसलिए एक दक्षता उपाय और एक समानता कर्तव्य दोनों है।

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

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

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

जांच-सूची#

• सभी नई डिजिटल मांग के लिए एक प्रचारित फ्रंट डोर है।
• इनटेक फ़ॉर्म समस्या/परिणाम कैप्चर करता है, केवल एक अनुरोधित समाधान नहीं।
• हर वस्तु मांग प्रकार (विचार / अनुरोध / घटना / अधिदेश) द्वारा वर्गीकृत है।
• इनटेक पर एक क्लिनिकल-सुरक्षा और व्यक्तिगत-डेटा फ्लैग अनिवार्य है।
• घटनाओं का एक अलग तेज़ मार्ग है लेकिन इनटेक के लिए दृश्यमान रहता है।
• एक प्रकाशित स्वीकृति SLA मौजूद है और मापा जाता है।
• मांग कतार अनुरोधकर्ताओं और हितधारकों के लिए दृश्यमान है।
• एक नामित स्वामी एक निश्चित गति पर इनटेक क्यूरेट करता है।
• व्यावसायिक-मामला प्रयास अनुरोध के आकार के अनुपात में है।
• वरिष्ठ नेता बाकी सभी की तरह फ्रंट डोर का उपयोग करते हैं।

मुख्य स्रोत#

• ITIL 4 (AXELOS / PeopleCert) — मांग प्रबंधन और सेवा अनुरोध प्रबंधन प्रथाएं; "एकल फ्रंट डोर" अवधारणा।
• NHS England — DCB0129 Clinical Risk Management: its Application in the Manufacture of Health IT Systems (परिवर्तन की सुरक्षा-फ्लैगिंग)।
• GOV.UK Service Manual (Government Digital Service) — समाधानों से पहले उपयोगकर्ता आवश्यकताओं और समस्याओं को समझना।
• NHS Digital Service Standard — उपयोगकर्ता आवश्यकताओं के लिए डिज़ाइन करना; काम को दृश्यमान बनाना।
• HM Treasury — The Green Book और पांच-मामला मॉडल (आनुपातिक व्यावसायिक मामले)।
• Reinertsen, D. — The Principles of Product Development Flow (कतारों और मांग का प्रबंधन)।

संदर्भ#

1. Demand management — Wikipedia — https://en.wikipedia.org/wiki/Demand_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
4. Service catalog — Wikipedia — https://en.wikipedia.org/wiki/Service_catalog
5. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
6. Shadow IT — Wikipedia — https://en.wikipedia.org/wiki/Shadow_IT
7. Business case — Wikipedia — https://en.wikipedia.org/wiki/Business_case
8. ITIL 4: Demand Management and Service Request Management practices — AXELOS / PeopleCert — https://www.peoplecert.org/itil
9. DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation
10. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
11. NHS Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. The Green Book: appraisal and evaluation in central government (five-case model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government
13. Reinertsen, D. — The Principles of Product Development Flow — Celeritas Publishing — https://www.celeritas.com/