विषय 5.4 — एंटरप्राइज़ रिसोर्स प्लानिंग (ERP)

एक वाक्य में: Enterprise Resource Planning एकीकृत बैक-ऑफ़िस सिस्टम है — वित्त, मानव संसाधन, पेरोल, खरीद, और आपूर्ति श्रृंखला — जो पैसे, लोगों, और स्टॉक के लिए संगठन के सिस्टम ऑफ रिकॉर्ड के रूप में कार्य करता है, और चुपचाप इस किताब में लगभग हर काम करने के तरीके को आधार देता है।

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

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

पैमाना विशाल है। NHS Shared Business Services (NHS SBS), 2004 में बनाया गया एक संयुक्त उद्यम, एक राष्ट्रीय Oracle-आधारित वित्त और खरीद प्लेटफ़ॉर्म चलाता है जो लाखों चालान संसाधित करता है और सौ से अधिक NHS संगठनों के लिए कुल NHS खर्च का एक बहुत बड़ा हिस्सा संभालता है (मुख्य स्रोत देखें)। इसलिए ERP निर्णय एक विशिष्ट वित्त चिंता नहीं हैं — वे कार्यबल प्रबंधन, सार्वजनिक धन के नियंत्रण, और हर डाउनस्ट्रीम विश्लेषण जिस पर निर्भर करता है उस डेटा गुणवत्ता को आकार देते हैं। एक निदेशक के लिए, ERP एक मूलभूत सक्षमकर्ता और उन सबसे उच्च-जोखिम कार्यक्रमों में से एक दोनों है जिन्हें एक संगठन कभी प्रयास करेगा।

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

ERP क्या है। मॉड्यूलों का एक एकल, एकीकृत enterprise resource planning सूट जो एक डेटाबेस और एक मास्टर डेटा सेट साझा करता है, एंटरप्राइज़ की मुख्य प्रशासनिक प्रक्रियाओं को कवर करते हुए: सामान्य लेजर और वित्तीय लेखांकन, देय और प्राप्य खाते, HR और कार्यबल प्रशासन, पेरोल, खरीद (खरीद-से-भुगतान), इन्वेंट्री और आपूर्ति श्रृंखला, और तेज़ी से योजना और विश्लेषिकी (FP&A — वित्तीय योजना और विश्लेषण)। "एकीकरण" का बिंदु यह है कि एक खरीद ऑर्डर, एक माल प्राप्ति, और एक चालान स्वचालित रूप से समेटते हैं क्योंकि वे वही डेटा हैं, तीन प्रतियां नहीं।

सिस्टम ऑफ रिकॉर्ड। ERP वित्तीय और संसाधन डेटा के लिए आधिकारिक स्रोत है — वह लेजर जिस पर ऑडिटर भरोसा करते हैं और वह पेरोल जिससे स्टाफ को भुगतान किया जाता है। अन्य सिस्टम परिचालन प्रतियां रख सकते हैं, लेकिन ERP पैसे के लिए और, अक्सर, मूल HR रिकॉर्ड के लिए सत्य का संस्करण है।

मास्टर डेटा। साझा संदर्भ डेटा जिस पर बाकी सब कुछ निर्भर करता है: chart of accounts, लागत केंद्र, आपूर्तिकर्ता रिकॉर्ड, आइटम सूची, और कर्मचारी रिकॉर्ड। मास्टर डेटा ERP सफलता का मौन निर्धारक है — गंदा, दोहराया, या असंगत मास्टर डेटा रिपोर्टिंग को भ्रष्ट करता है, सामंजस्य तोड़ता है, और ऊपर बनी हर प्रक्रिया को कमज़ोर करता है।

स्वास्थ्य और सार्वजनिक क्षेत्र में सामान्य प्लेटफ़ॉर्म। NHS और व्यापक UK सार्वजनिक क्षेत्र में मुख्य ERP प्लेटफ़ॉर्म हैं Oracle (प्रभावी, काफी हद तक NHS SBS और NEP जैसे संघों के माध्यम से), SAP, Unit4 (ट्रस्टों, विश्वविद्यालयों, और स्थानीय अधिकारियों द्वारा व्यापक रूप से चुना गया), और Microsoft Dynamics 365। वयस्क सामाजिक देखभाल देने वाले स्थानीय अधिकारी अपने वित्त और खरीद के लिए उसी श्रेणी के सिस्टम चलाते हैं। यात्रा की आधुनिक दिशा ऑन-प्रिमाइस इंस्टॉलेशन के बजाय क्लाउड ERP (software-as-a-service) है।

साझा सेवाएं। हर संगठन के अपना खुद का ERP चलाने के बजाय, कई एक सामान्य प्लेटफ़ॉर्म और एक सामान्य बैक-ऑफ़िस संचालन साझा करते हैं — NHS SBS मॉडल, और टेम्पलेट किए गए Oracle Cloud इंस्टेंस चलाने वाले NHS संघ। साझा सेवाएं मानकीकरण, पैमाने की अर्थव्यवस्थाओं, और एक छोटे सामूहिक कार्यान्वयन और समर्थन बोझ के लिए कुछ स्थानीय लचीलेपन का व्यापार करती हैं।

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

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

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

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

4. ERP प्रतिस्थापन को एक प्रमुख कार्यक्रम के रूप में चलाएं, इसके मूल में परिवर्तन प्रबंधन के साथ। एक ERP कार्यान्वयन एक व्यावसायिक-परिवर्तन कार्यक्रम है जिसमें सॉफ़्टवेयर शामिल होता है, एक IT परियोजना नहीं। इसे कार्यक्रम अनुशासन (विषय 5.2 — कार्यक्रम प्रबंधन देखें) और एक वास्तविक परिवर्तन-प्रबंधन प्रयास (विषय 8.1 — परिवर्तन प्रबंधन देखें) के साथ संसाधित करें, क्योंकि अधिकांश ERP पीड़ा लोग और प्रक्रिया है, तकनीक नहीं।

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

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

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

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

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

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

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

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

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

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

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

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

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

वित्त निदेशक इसे एक IT अदला-बदली के रूप में मानने के प्रलोभन का विरोध करता है। एक कार्यकारी प्रायोजक, एक पूर्णकालिक कार्यक्रम प्रबंधक, और — महत्वपूर्ण रूप से — एक डेटा-गुणवत्ता कार्यधारा के साथ एक कार्यक्रम खड़ा किया जाता है जो chart of accounts को साफ़ करने, बारह हज़ार आपूर्तिकर्ता रिकॉर्ड को डी-डुप्लिकेट करने, और किसी भी माइग्रेशन से पहले कर्मचारी मास्टर को ESR (NHS इलेक्ट्रॉनिक स्टाफ रिकॉर्ड) के विरुद्ध समेटने में महीने बिताती है। वित्त, खरीद, और HR में प्रक्रिया स्वामियों को पुराने सिस्टम को दोहराने के बजाय संघ टेम्पलेट के लिए अपने वर्कफ़्लो को फिर से डिज़ाइन करने के लिए प्रतिनियुक्त किया जाता है।

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

एक साल बाद, ट्रस्ट हफ़्तों के बजाय दिनों में अपनी किताबें बंद करता है, खरीद अनुमोदन सिस्टम में लागू होते हैं, और स्थापना अंततः पेरोल के साथ समेटती है। साझा संघ प्लेटफ़ॉर्म का यह भी अर्थ है कि अगला अपग्रेड एक और बहु-वर्षीय परियोजना के बजाय एक नियमित क्लाउड रिलीज़ के रूप में आता है।

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

स्टार्टअप#

एक डिजिटल-स्वास्थ्य स्टार्टअप शायद ही कभी एक पूर्ण ERP चलाता है; यह क्लाउड SaaS उपकरणों को एक साथ सिलता है — एक हल्का लेखांकन पैकेज, एक HR-और-पेरोल ऐप, कुछ स्प्रेडशीट — क्योंकि एक भारी एकीकृत सूट तीस लोगों की एक टीम के लिए अनुपातहीन है। सिस्टम-ऑफ़-रिकॉर्ड अनुशासन फिर भी मायने रखता है, हालांकि: बीज चरण में भी, एक साफ़ chart of accounts और एक एकल आधिकारिक पेरोल स्रोत उस सामंजस्य अराजकता को रोकते हैं जो देय परिश्रम के दौरान निवेशकों को डरा देती है। सही कदम स्टैक को सरल, एकीकरण योग्य, और अच्छी तरह से शासित रखना है, और एक "वास्तविक" ERP को तब तक टालना जब तक पैमाना वास्तव में इसकी मांग नहीं करता। स्टार्टअप का जोखिम एंटरप्राइज़ का दर्पण छवि है — अति-अनुकूलन नहीं, बल्कि फैलाव: बिना किसी मास्टर-डेटा स्वामी और संख्याओं के लिए किसी भी जवाबदेह के एक दर्जन असंबद्ध ऐप।

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

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

बड़ा संगठन#

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

सरकार#

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

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

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

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

जांच-सूची#

• माइग्रेशन से पहले chart of accounts, आपूर्तिकर्ता, आइटम, और कर्मचारी मास्टर डेटा साफ़ और डी-डुप्लिकेट किया गया है।
• चालू मास्टर-डेटा स्वामित्व और प्रशासन असाइन और वित्तपोषित है।
• कार्यान्वयन को एक IT परियोजना के रूप में नहीं बल्कि एक व्यावसायिक-परिवर्तन कार्यक्रम के रूप में दायरा और संसाधित किया गया है।
• अनुकूलन न्यूनतम है; सामान्य प्रक्रियाओं के लिए मानक आपूर्तिकर्ता या संघ टेम्पलेट अपनाया गया है।
• हर एकीकरण (रोस्टरिंग, पेरोल/ESR, क्लिनिकल/फार्मेसी, बैंकिंग, विश्लेषिकी) मैप, स्वामित्व, और अंत-से-अंत परीक्षित है।
• गो-लाइव दृष्टिकोण (चरणबद्ध बनाम बिग-बैंग) तत्परता पर चुना गया है, एक लगाई गई तारीख पर नहीं।
• डेटा कटओवर, समानांतर रन, सामंजस्य, और एक हाइपरकेयर अवधि योजनाबद्ध और स्टाफ की गई है।
• परिवर्तन प्रबंधन, प्रशिक्षण, और प्रक्रिया पुनर्डिज़ाइन स्पष्ट रूप से संसाधित हैं (विषय 8.1 देखें)।
• साझा-सेवाओं और क्लाउड-ERP विकल्पों का उनके वास्तविक मानकीकरण-बनाम-लचीलापन व्यापार पर मूल्यांकन किया गया है।
• ERP एकल सिस्टम ऑफ रिकॉर्ड के रूप में स्थापित है, और छाया स्प्रेडशीट रिटायर की गई हैं।

मुख्य स्रोत#

• NHS Shared Business Services (NHS SBS) — NHS संगठनों के लिए राष्ट्रीय Oracle-आधारित वित्त और खरीद साझा सेवा। https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — राष्ट्रीय NHS वित्त प्लेटफ़ॉर्म का पैमाना। https://www.oracle.com/uk/
• NHS North of England Commissioning / NEP संघ — NHS सदस्यों के लिए टेम्पलेट किया गया Oracle Cloud ERP। https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — NHS ट्रस्टों, स्थानीय अधिकारियों, और विश्वविद्यालयों के लिए ERP। https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — वित्त प्रक्रियाएं जिन्हें ERP आधार देता है। https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — NHS कार्यबल और पेरोल सिस्टम जिसके साथ ERP को एकीकृत होना चाहिए। https://www.electronicstaffrecord.nhs.uk/
• विषय 5.2 — कार्यक्रम प्रबंधन, विषय 5.3 — एंटरप्राइज़ प्रोजेक्ट पोर्टफोलियो प्रबंधन, और विषय 8.1 — परिवर्तन प्रबंधन भी देखें।

संदर्भ#

1. Enterprise resource planning — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. System of record — Wikipedia — https://en.wikipedia.org/wiki/System_of_record
3. Master data management — Wikipedia — https://en.wikipedia.org/wiki/Master_data_management
4. Chart of accounts — Wikipedia — https://en.wikipedia.org/wiki/Chart_of_accounts
5. Payroll — Wikipedia — https://en.wikipedia.org/wiki/Payroll
6. Procure-to-pay — Wikipedia — https://en.wikipedia.org/wiki/Procure-to-pay
7. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
8. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Change management — Wikipedia — https://en.wikipedia.org/wiki/Change_management
11. Business process re-engineering — Wikipedia — https://en.wikipedia.org/wiki/Business_process_re-engineering
12. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
13. NHS Shared Business Services — Wikipedia — https://en.wikipedia.org/wiki/NHS_Shared_Business_Services
14. NHS Shared Business Services — the national Oracle-based finance and procurement shared service for NHS organisations — https://www.sbs.nhs.uk/
15. NHS Shared Business Services with Oracle Fusion Cloud Applications — Oracle — https://www.oracle.com/uk/
16. Public sector and healthcare ERP — Unit4 — https://www.unit4.com/industries/public-sector-software
17. Introductory Guide to NHS Finance — HFMA — https://www.hfma.org.uk/
18. NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with — https://www.electronicstaffrecord.nhs.uk/