विषय 6.6 — आपूर्तिकर्ता और सेवा एकीकरण प्रबंधन (SIAM)

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

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

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

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

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

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

सेवा एकीकरण और प्रबंधन (SIAM) व्यवसाय को एक एकल, अंत-से-अंत सेवा देने के लिए कई सेवा प्रदाताओं का समन्वय करने और उन्हें एकीकृत करने का एक प्रबंधन दृष्टिकोण है। यह एक अनुशासन के रूप में ठीक-ठीक इसलिए उभरा क्योंकि संगठन एक एकल प्रमुख अनुबंधक से एक बहु-स्रोत परिचालन मॉडल की ओर चले गए, और फिर खोजा कि किसी को अभी भी हिस्सों को एक संपूर्ण के रूप में व्यवहार करवाना है। SIAM कोई उत्पाद नहीं है जिसे आप खरीदते हैं; यह परिभाषित भूमिकाओं, प्रक्रियाओं, और प्रशासन के साथ एक परिचालन मॉडल है। आधिकारिक संदर्भ Scopism SIAM Body of Knowledge है, जो ITIL और IT सेवा प्रबंधन (ITSM) की व्यापक प्रथा के साथ बैठता है बजाय उन्हें बदलने के।

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

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

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

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

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

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

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

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

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

6. अनुबंध और प्रदर्शन प्रबंधन को एक सक्रिय, साक्ष्य वाला अनुशासन बनाएं। हस्ताक्षर के बाद एक दराज में छोड़ा गया अनुबंध छोड़ा गया पैसा और लाभ है। SLAs के विरुद्ध संरचित प्रदर्शन समीक्षाएं करें, जहां वे बकाया हैं वहां सेवा क्रेडिट को ट्रैक और वास्तव में दावा करें, एक साझा जोखिम-और-मुद्दा रजिस्टर बनाए रखें, और प्रदर्शन का एक ऑडिट योग्य रिकॉर्ड रखें जो नवीनीकरण या विवाद पर मायने रखेगा। सेवा क्रेडिट बिंदु नहीं हैं — वे एक संकेत और एक लीवर हैं; एक परिपक्व संबंध लगातार कम-प्रदर्शन का उपयोग सुधार योजनाओं को ट्रिगर करने और, अंततः, निकास को ट्रिगर करने के लिए करता है, केवल एक छोटी छूट बैंक करने के लिए नहीं (विषय 6.4 — प्रशासन और आश्वासन देखें)।

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

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

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

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

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

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

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

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

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

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

Northmoor Integrated Care System अपने पैमाने की एक विशिष्ट डिजिटल संपत्ति चलाता है: एक प्रमुख विक्रेता से एक होस्ट किया गया इलेक्ट्रॉनिक रोगी रिकॉर्ड, दूसरे से एक साझा देखभाल रिकॉर्ड प्लेटफ़ॉर्म, एक विशेषज्ञ से एक एकीकरण इंजन और इंटरफ़ेस परत, NHS England से राष्ट्रीय सेवाएं, एक नेटवर्क प्रदाता से कनेक्टिविटी, और एक सिस्टम इंटीग्रेटर द्वारा संचालित एक प्रबंधित सेवा डेस्क जिसका पहली-पंक्ति समर्थन स्वयं विदेश में उप-अनुबंधित है। हर अनुबंध एक दशक में अलग से खरीदा गया था, हर एक का अपना SLA है, और — हाल तक — हर एक एक अलग निदेशालय में एक अलग प्रबंधक द्वारा शासित था।

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

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

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

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

स्टार्टअप#

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

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

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

बड़ा संगठन#

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

सरकार#

एक राष्ट्रीय निकाय — NHS England, एक विकेंद्रीकृत स्वास्थ्य विभाग, या Crown Commercial Service जैसा एक फ्रेमवर्क ऑपरेटर — उस वातावरण को आकार देता है जिसमें हर ट्रस्ट अपने आपूर्तिकर्ताओं का प्रबंधन करता है। इसका लाभ Government Commercial Function के Sourcing Playbook और मानक शर्तों के माध्यम से अपेक्षाएं निर्धारित करना है, सहयोग, पोर्टेबिलिटी, और आपूर्ति-श्रृंखला आश्वासन को बाज़ार डिफ़ॉल्ट बनाना बजाय इसके कि हर खरीदार कमज़ोरी से अकेले बातचीत करे। सरकार व्यवस्थित दृश्य भी रखती है: यह देख सकती है, जैसे एक व्यक्तिगत ट्रस्ट नहीं कर सकता, जब एक एकल आपूर्तिकर्ता या प्लेटफ़ॉर्म पूरे सिस्टम के लिए एक महत्वपूर्ण तीसरा पक्ष बन गया है, और इसे उस एकाग्रता को एक राष्ट्रीय लचीलापन मामले के रूप में प्रबंधित करना चाहिए। इसका कर्तव्य यह सुनिश्चित करना है कि फ्रेमवर्क डिज़ाइन, आश्वासन व्यवस्थाएं, और राष्ट्रीय सेवाएं लॉक-इन और विफलता के एकल बिंदुओं को गहरा करने के बजाय कम करें (विषय 9.1 — स्थानीय और राष्ट्रीय सरकारों के साथ काम करना देखें)।

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

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

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

जांच-सूची#

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

मुख्य स्रोत#

• Scopism — SIAM Body of Knowledge और SIAM Professional Body of Knowledge — सेवा एकीकरण और प्रबंधन भूमिकाओं, संरचनाओं, और प्रक्रियाओं के लिए निश्चायक खुला संदर्भ।
• AXELOS — ITIL 4 — घटना, समस्या, परिवर्तन, और आपूर्तिकर्ता प्रबंधन के लिए IT सेवा प्रबंधन प्रथाएं जिन्हें SIAM आपूर्तिकर्ताओं में विस्तारित करता है।
• UK Government Commercial Function — The Sourcing Playbook और Outsourcing Playbook — सोर्सिंग, अनुबंध प्रबंधन, और निकास पर सार्वजनिक-क्षेत्र मार्गदर्शन।
• Crown Commercial Service — सार्वजनिक-क्षेत्र तकनीक और प्रबंधित-सेवा खरीद के लिए फ्रेमवर्क समझौते और मानक शर्तें।
• National Cyber Security Centre (NCSC) — Supply chain security guidance — आपूर्तिकर्ताओं और उप-अनुबंधकों में साइबर जोखिम का आकलन और प्रबंधन।
• HM Government / Cabinet Office — सार्वजनिक सेवाओं में महत्वपूर्ण तीसरे पक्षों और एकाग्रता जोखिम प्रबंधित करने पर मार्गदर्शन।
• NHS England — क्लिनिकल सुरक्षा मानक DCB0129/DCB0160 और आपूर्तिकर्ताओं को प्रवाहित की जाने वाली डेटा-प्रसंस्करण आवश्यकताएं।

संदर्भ#

1. Service integration and management — Wikipedia — https://en.wikipedia.org/wiki/Service_integration_and_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
4. Outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Outsourcing
5. Business process outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Business_process_outsourcing
6. Managed services — Wikipedia — https://en.wikipedia.org/wiki/Managed_services
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Third-party management — Wikipedia — https://en.wikipedia.org/wiki/Third-party_management
9. Supply chain — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain
10. Supply chain risk management — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_risk_management
11. Concentration risk — Wikipedia — https://en.wikipedia.org/wiki/Concentration_risk
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Continual improvement process — Wikipedia — https://en.wikipedia.org/wiki/Continual_improvement_process
14. Kraljic matrix — Wikipedia — https://en.wikipedia.org/wiki/Kraljic_matrix
15. Scopism — SIAM Body of Knowledge — https://www.scopism.com/
16. AXELOS — ITIL 4 — https://www.axelos.com/certifications/itil-service-management
17. UK Government Commercial Function — The Sourcing Playbook — GOV.UK — https://www.gov.uk/government/publications/the-sourcing-playbook
18. National Cyber Security Centre — Supply chain security guidance — NCSC — https://www.ncsc.gov.uk/collection/supply-chain-security
19. Crown Commercial Service — GOV.UK — https://www.gov.uk/government/organisations/crown-commercial-service