प्रक्रिया मैपिंग की मूल बातें: BPMN के बिना शुरू करें

पहले "as-is", फिर "to-be"

प्रक्रिया मैपिंग के बारे में सबसे आम भ्रांति: मानचित्र बनाने से पहले "कैसा होना चाहिए" जानना ज़रूरी है। नहीं। पहले "अभी क्या हो रहा है" जानना होगा।

"as-is" मानचित्र दिखाता है कि प्रक्रिया आज वास्तव में कैसे काम करती है — दस्तावेज़ों में लिखी बात नहीं। कई छोटे-मझोले उद्यमों (SME) में ऑर्डर लेना, बिलिंग, या ग्राहक ऑनबोर्डिंग की प्रक्रियाएँ वर्षों से नहीं बदली हैं लेकिन कहीं लिखी नहीं हैं। यही खाई ऑटोमेशन में जाने का सबसे बड़ा जोखिम है: बिना दस्तावेज़ की प्रक्रिया को स्वचालित करें तो उसकी गलतियाँ भी स्वचालित हो जाती हैं।

उपकरण जटिल नहीं चाहिए: स्टिकी नोट्स, Miro बोर्ड, या Excel की चार-कॉलम तालिका काफी है। BPMN सीखने या Visio ख़रीदने की ज़रूरत नहीं।

as-is मानचित्र बनने के बाद "to-be" डिज़ाइन बहुत आसान हो जाता है। दिखता है कि क्या बदलेगा नहीं — क्या बना रहेगा। इससे अनुकूलन के फ़ैसले वास्तविक डेटा पर आधारित होते हैं, अनुमान पर नहीं।

1 घंटे में प्रक्रिया मैप करें: 4-कॉलम दृष्टिकोण

जटिल उपकरण के बिना प्रक्रिया मैप करने के लिए चार-कॉलम की Excel तालिका या Miro स्ट्रिप पर्याप्त है। प्रत्येक पंक्ति एक चरण को दर्शाती है; कॉलम हैं:

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

ये चार कॉलम एक सरल स्विमलेन डायग्राम जैसे हैं और किसी सॉफ़्टवेयर ज्ञान की ज़रूरत नहीं। प्रक्रिया जानने वाले दो-तीन लोगों के साथ एक घंटे की कार्यशाला में स्टिकी नोट्स से पूरी तालिका भरी जा सकती है।

मानचित्र पूरा होने के बाद हर चरण पर पूछें: "क्या यह चरण स्वचालित हो सकता है? हटाया जा सकता है? मिलाया जा सकता है?" ये तीन सवाल अनावश्यक जटिलता को हटाते हैं।

मैप की गई प्रक्रिया कब ऑटोमेशन के लिए तैयार है

हर मैप की गई प्रक्रिया ऑटोमेशन के लिए तैयार नहीं होती। ऑटोमेशन पर जाने से पहले चार मानदंड पूरे होने चाहिए:

1. पुनरावृत्ति दर: यदि प्रक्रिया प्रति सप्ताह कम से कम दो से तीन बार दोहराती है, तो ऑटोमेशन की लागत उचित हो जाती है। महीने में एक बार होने वाले असाधारण कार्य के लिए ऑटोमेशन आमतौर पर अनावश्यक है।

2. मानकीकृत इनपुट: यदि प्रक्रिया शुरू करने वाले इनपुट मानकीकृत हैं — एक विशेष ईमेल प्रारूप, फ़ॉर्म प्रतिक्रिया, या सिस्टम सूचना — तो ऑटोमेशन बहुत अधिक विश्वसनीय रूप से काम करता है। यदि इनपुट हर बार अलग हों तो पहले डेटा मानकीकरण चरण की आवश्यकता है।

3. मानवीय निर्णय की मात्रा: यदि प्रक्रिया के महत्वपूर्ण चरणों में कई व्यक्तिपरक निर्णय लिए जाते हैं, तो उन चरणों को पहले सरल बनाना या नियम-आधारित बनाना होगा। ऑटोमेशन नियम-आधारित चरणों को स्वचालित कर सकता है, अस्पष्ट निर्णयों को नहीं।

4. त्रुटि सहनशीलता: यदि प्रक्रिया में त्रुटि सीधे ग्राहक हानि, कानूनी उल्लंघन, या आर्थिक नुकसान की ओर ले जाती है, तो ऑटोमेशन से पहले व्यापक परीक्षण अनिवार्य है।

चारों मानदंड पूरे करने वाली प्रक्रियाएँ ऑटोमेशन के लिए सबसे तैयार हैं। Setviva का दृष्टिकोण: योग्य प्रक्रिया की पहचान के बाद पहले छोटे डेटा सेट पर पायलट परीक्षण करते हैं, फिर धीरे-धीरे पूरी मात्रा तक विस्तार करते हैं। मानचित्र के बिना पायलट नहीं; पायलट के बिना स्केल नहीं।

प्रक्रिया मैपिंग पहला कदम है: मैपिंग के बाद, डिजिटल परिवर्तन कहाँ से शुरू करें पढ़ें और हमारे क्षेत्र-विशिष्ट ऑटोमेशन दृष्टिकोण देखें।

वह क़दम जिसे ज़्यादातर टीमें छोड़ देती हैं: काम करने वाले लोगों से बात करें

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

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

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

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