lantu3D

3D प्रिंटिंग में विभागों के बीच सहयोग के लिए जिम्मेदारी और निर्णय-अधिकार डिजाइन: RACI मैट्रिक्स, इंटरफेस सूची और एस्केलेशन नियमों की इंजीनियरिंग पद्धति

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

3D प्रिंटिंग में विभागों के बीच सहयोग के लिए जिम्मेदारी और निर्णय-अधिकार डिजाइन: RACI मैट्रिक्स, इंटरफेस सूची और एस्केलेशन नियमों की इंजीनियरिंग पद्धति

परिचय: सहयोग की विफलता अक्सर रवैये की नहीं, बल्कि अपरिभाषित निर्णय-अधिकार की समस्या है

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

I. सहयोग को संचार की समस्या नहीं, निर्णय-अधिकार की समस्या के रूप में पुनः स्थापित करना

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

इंजीनियरीकृत तरीका यह है कि प्रत्येक निर्णय बिंदु के लिए एकमात्र जवाबदेह व्यक्ति (Accountable) निर्धारित किया जाए—ध्यान दें, एकमात्र; “संयुक्त जिम्मेदारी” नहीं। रजिस्टर में दो लोगों की संयुक्त जिम्मेदारी का अर्थ वस्तुतः किसी की जिम्मेदारी न होना है। जवाबदेह व्यक्ति के पास अंतिम निर्णय का अधिकार होता है; अन्य संबंधित पक्ष परामर्शित पक्षों (Consulted, जिन्हें निर्णय से पहले आवश्यक इनपुट देना होता है) और सूचित पक्षों (Informed, जिन्हें निर्णय के बाद परिणाम बताया जाता है) में विभाजित होते हैं। यही RACI मैट्रिक्स का मूल है: Responsible (निष्पादन), Accountable (जवाबदेही/अंतिम निर्णय), Consulted (परामर्शित), Informed (सूचित)।

II. RACI मैट्रिक्स भरने के नियम और सामान्य त्रुटियां

RACI मैट्रिक्स भरते समय कुछ कठोर नियम हैं। पहला, प्रत्येक निर्णय इकाई के A कॉलम में केवल एक ही चिह्न होना चाहिए; दो A दिखाई देना डिजाइन दोष है। ऐसे में निर्णय इकाई को और विभाजित करना होगा—उदाहरण के लिए, “गैर-अनुरूप उत्पाद का निपटान” को “दोष-स्तर निर्धारण” (गुणवत्ता A) और “निपटान विधि का चयन” (प्रक्रिया A, गुणवत्ता C) में बांटें। दूसरा, R एक से अधिक हो सकते हैं, लेकिन मुख्य निष्पादक को स्पष्ट रूप से दर्शाना होगा, आमतौर पर कोष्ठक में। तीसरा, C की संख्या बहुत अधिक नहीं होनी चाहिए; किसी निर्णय इकाई में तीन से अधिक C होने का अर्थ है कि विषय को जरूरत से ज्यादा फैला दिया गया है और इसे निर्णय को वास्तविक रूप से प्रभावित करने वाले दो या तीन पक्षों तक सीमित करना चाहिए। चौथा, I का अर्थ भागीदारी न करना नहीं है। डिलीवरी रिलीज़ जैसे बिंदु पर, I के रूप में बिक्री टीम को परिणाम जारी होने के एक घंटे के भीतर ग्राहक पक्ष को सूचित करना अनिवार्य है।

सबसे सामान्य त्रुटि मैट्रिक्स में भूमिकाओं के बजाय विभागों के नाम लिखना है। विभाग संगठनात्मक इकाइयां हैं, जबकि भूमिकाएं जिम्मेदारी के वाहक हैं; एक ही विभाग की भूमिका अलग-अलग निर्णय बिंदुओं पर पूरी तरह भिन्न हो सकती है—उदाहरण के लिए, गुणवत्ता विभाग “दोष वर्गीकरण” में A है, लेकिन “प्रक्रिया मार्ग चयन” में केवल C है। मैट्रिक्स में पंक्तियों में भूमिकाएं (जैसे प्रक्रिया अभियंता, परियोजना ओनर, गुणवत्ता अभियंता) और स्तंभों में निर्णय बिंदु होने चाहिए।

III. इंटरफेस सूची: विभागों के बीच डिलिवरेबल्स को स्वीकार्यता-योग्य मदों में लिखना

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

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

IV. एस्केलेशन नियम: मतभेदों का समाधान बार-बार बैठकें करके नहीं होना चाहिए

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

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

V. सहयोग तंत्र को जांचे जा सकने वाले रिकॉर्ड में उतारना

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

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

निष्कर्ष

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

अगला चरण क्या यह आपकी आवश्यकता के अनुरूप है?

मॉडल, रेखाचित्र, चित्र या लिखित नोट प्रस्तुत करें। इंजीनियर वास्तविक उपयोग के आधार पर सामग्री, प्रक्रिया, समापन और वितरण की समीक्षा करेंगे।

अनुरोध जमा करें पहले पूछें