ज़िम्मेदारी की प्रभावशीलता

सबसे बड़ा जोखिम ज़िम्मेदारियों का न होना नहीं है।
बल्कि यह मान लेना है कि वे मौजूद हैं।

आपके कैटलॉग में हर महत्वपूर्ण एसेट का एक स्वामी, एक स्टीवर्ड और एक अनुमोदक होता है। नाम भरे हुए हैं। वर्कफ़्लो अब भी उन्हीं तक रूट होते हैं। यह पृष्ठ उस सवाल के बारे में है जिसका जवाब कैटलॉग नहीं दे सकता: अगर उस एसेट को आज किसी निर्णय की ज़रूरत हो, तो क्या उस पर दर्ज व्यक्ति वाक़ई कार्रवाई कर सकता है?

प्रभावी होने का मतलब

किसी ज़िम्मेदारी का मूल्य तभी तक है जब तक उसका निर्वहन किया जा रहा हो।

नियुक्ति एक रिकॉर्ड है। प्रभावशीलता एक अवस्था है, और इसकी तीन शर्तें हैं — जो आज, एक ही समय पर, सभी सच होनी चाहिए:

01

सक्रिय

व्यक्ति अभी भी संगठन में है, और उपलब्ध है। यह वह नाम नहीं है जो संगठन छोड़ने की प्रक्रिया से इसलिए बच गया क्योंकि किसी को पता ही नहीं था कि वह किन चीज़ों का स्वामी था — और न ही यह कोई ऐसा व्यक्ति है जो लंबी छुट्टी पर है और जिसकी ज़िम्मेदारियाँ किसी ने संभाली ही नहीं।

02

अधिकृत

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

03

कार्रवाई करने में सक्षम

वे उस चीज़ तक पहुँच सकते हैं जिसके लिए वे ज़िम्मेदार हैं, और वे जानते हैं कि यह भूमिका उनसे क्या अपेक्षा रखती है। एक्सेस को आइडेंटिटी सिस्टम अपने ही शेड्यूल पर रद्द करते हैं, और एक्सेस रद्द होने से कोई ज़िम्मेदारी हट नहीं जाती।

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

इसीलिए, हमारे मॉडल में, कोई ज़िम्मेदारी कभी भी सिर्फ़ मौजूद या अनुपस्थित नहीं होती:

प्रस्तावित नियुक्त सूचित प्रशिक्षित

नियुक्त होना इन चार में से दूसरा चरण है, आख़िरी नहीं। कैटलॉग की एक फ़ील्ड दूसरा चरण दर्ज करती है और चौथे को मान लेती है।

आज · अदृश्य

चार भूमिकाएँ नियुक्त हैं। आज इनमें से एक भी जवाब नहीं दे सकती।

AdventureWorks2025 — HumanResources डेटा उत्पाद, जिसका उपयोग HR ऑपरेशंस, पेरोल और वर्कफ़ोर्स प्लानिंग में होता है। चार भूमिकाएँ इसके लिए जवाबदेह हैं। इनमें से हर एक भरी हुई है, और कैटलॉग को कोई समस्या नज़र नहीं आती।

स्वामी · और अनुमोदक

Hedda M Halvorsen

जा चुकी हैं · दोनों भूमिकाएँ उनके साथ चली गईं

स्टीवर्ड

Mindy C Martin

मई 2024 से अधिदेश दोबारा मान्य नहीं किया गया

विषय विशेषज्ञ

Lakshmi A Venkatesan

छुट्टी पर · कोई बैकअप नहीं

विषय विशेषज्ञ

Ashok X Joshi

नियुक्त · कभी सूचित नहीं किया गया

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

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

दूसरे विशेषज्ञ पर रुककर सोचना ज़रूरी है। Ashok कार्यरत हैं, अधिकृत हैं, और उनके पास एक्सेस भी है। किसी भी सिस्टम में कुछ भी पुराना नहीं पड़ा है। बस उन्हें कभी यह बताया ही नहीं गया कि जब दूसरे विशेषज्ञ उपलब्ध नहीं होते, तो यह एसेट उन तक रूट होता है — और कहीं भी कोई रिपोर्ट यह दिखाने में सक्षम नहीं है।

अंदर से देखने पर अभिशासन का क्षरण ऐसा ही दिखता है: कोई ख़ाली फ़ील्ड नहीं, बल्कि एक भरी हुई फ़ील्ड जो सच होना बंद कर चुकी है।

कैटलॉग यह क्यों नहीं देख पाता

स्वामी की फ़ील्ड एक नाम रखती है। वह कोई दायित्व नहीं रखती।

कैटलॉग में · एक एट्रिब्यूट

किसी एसेट पर लिखा पाठ, जो एक ऐसे व्यक्ति की ओर इशारा करता है जिसके बारे में एसेट कुछ नहीं जानता। उनका रोज़गार, उनका क्षेत्र, उनके एंटाइटलमेंट तीन दूसरे सिस्टम में रहते हैं, और फ़ील्ड के पास उनसे कुछ भी पूछने का कोई तरीक़ा नहीं है।

कोई फ़ील्ड ग़लत नहीं हो सकती, क्योंकि किसी फ़ील्ड की जाँच ही नहीं की जा सकती।

Nodwise में · एक टाइप-आधारित संबंध

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

वह मैट्रिक्स हर भूमिका के लिए घोषित करती है कि उसे धारण करने वाले से क्या अपेक्षित है और किसी को उसे धारण करने के योग्य क्या बनाता है। इसलिए “डेटा स्वामी” किसी नीति दस्तावेज़ से उधार लिया गया पदनाम नहीं है — यह अपेक्षाओं का एक परिभाषित समूह और एक परिभाषित मानदंड है, जो एक बार लिखा जाता है और उस प्रकार का हर नोड उसे विरासत में पाता है।

यानी तीनों शर्तें ऑडिट की कवायद नहीं रह जातीं, बल्कि एक ट्रैवर्सल बन जाती हैं:

विभाग

Human Resources

का अंग है
का अंग है
का अंग है

व्यक्ति

Hedda M Halvorsen

व्यक्ति

Mindy C Martin

व्यक्ति

Ashok X Joshi

के रूप में कार्य करता है
के रूप में कार्य करता है
के रूप में कार्य करता है

उद्यम भूमिका

Human Resources Manager

उद्यम भूमिका

Benefits Specialist

उद्यम भूमिका

Recruiter

स्वामीअनुमोदक
स्टीवर्ड
विषय विशेषज्ञ

डेटा उत्पाद

HumanResources data product

तीन सवाल जो कैटलॉग केवल किसी इंसान से पूछ सकता है, मॉडल का भ्रमण करके उत्तरित।

लूप

पहचाना गया, अधिदेश रखने वाले तक रूट किया गया, तय किया गया, दर्ज किया गया।

जैसे ही ज़िम्मेदारी एक संबंध बन जाती है, कोई अप्रभावी ज़िम्मेदारी एक ऐसी स्थिति बन जाती है जिस पर कोई एजेंट नज़र रख सकता है। आगे जो होता है, वह कोई ऐसी रिपोर्ट नहीं है जिसे आपको पढ़ना पड़े।

01

पहचाना गया

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

02

उस व्यक्ति तक रूट किया गया जो निर्णय ले सकता है

किसी गवर्नेंस मेलबॉक्स तक नहीं। मॉडल को पहले से पता है कि उस व्यक्ति का मैनेजर कौन है, और उसे यह भी पता है कि कौन-से एसेट्स और भूमिकाएँ प्रभावित हैं — इसलिए एक लीडर को अपने क्षेत्र में अब क्या बिना कवरेज के है, इसका एक समेकित दृश्य मिलता है।

03

किसी व्यक्ति द्वारा तय किया गया

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

04

दर्ज किया गया

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

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

इसी से उस सवाल का ईमानदार रूप भी मिलता है जिससे यह पृष्ठ शुरू होता है। “क्या कोई स्वामी है” नहीं, बल्कि आख़िरी बार कब इसकी पुष्टि हुई कि यह सच है — हर ज़िम्मेदारी के लिए एक तारीख़, जो या तो मौजूद है या नहीं।

एजेंट नज़र रखता है और एस्केलेट करता है। यह कभी निर्णय नहीं लेता। ध्यान की स्वायत्तता, अधिकार की नहीं।

इसकी सामान्य लागत क्या होती है

यह आमतौर पर एक पूरा प्रोग्राम होता है।

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

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

इनमें से हर चरण एक ऐसे मॉडल पर चलाई गई क्वेरी या वर्कफ़्लो है जिसके पास जवाब पहले से मौजूद है। इसलिए नहीं कि यह काम मामूली है, बल्कि इसलिए कि जिस मिलान में यह प्रोग्राम अपना ज़्यादातर समय लगाता है, वही असल में यह मॉडल है।

आठवें चरण — वे फ़्लो जिन्हें एक व्यक्ति ने बंधक बना रखा है — का अपना अलग पृष्ठ है: व्यवसाय निरंतरता →

कठिन सवाल पूछिए

आपका कैटलॉग आपको बता सकता है कि किसे नियुक्त किया गया है। उससे यह पूछिए कि कौन कार्रवाई कर सकता है।

डेमो टेनेंट में वह एसेट, चारों भूमिकाएँ, टूटी हुई शर्तें और उन्हें फ़्लैग करने वाली क्वेरी मौजूद हैं — एक ऐसे मॉडल में जिसे आप अभी खोल सकते हैं।

इसे चलते हुए देखिए

डेमो खोलें

आपके कार्य खाते से एक क्लिक। न कोई फ़ॉर्म, न कोई कॉल।

डेमो खोलें

या मॉडल पढ़िए

मॉडल कैसे सत्य बना रहता है

हर नोड और हर ज़िम्मेदारी पर जीवनचक्र — क्यों एक भरी हुई फ़ील्ड को भी अब सच न रहने के लिए फ़्लैग किया जा सकता है।

मॉडल कैसे सत्य बना रहता है →