BPMN प्रक्रिया आरेख काम को Business Process Model and Notation से दिखाता है। यह गतिविधियों, घटनाओं, निर्णयों और संचार की एक मानक भाषा है। टीम समीक्षा में इसका लाभ सटीकता है। साझा मॉडल से लोग “अनुमोदन धीमे हैं” जैसे अस्पष्ट कथनों पर बहस करने के बजाय किसी खास बदलाव पर सवाल उठा सकते हैं।
यह लेख चर्चा के लिए छोटे, वर्णनात्मक उदाहरण देता है। ये चलाए जा सकने वाले प्रक्रिया मॉडल नहीं हैं। वास्तविक आरेख बनाने और सत्यापित करने के लिए BPMN-सक्षम मॉडलिंग टूल का उपयोग करें। NextRetro रेट्रोस्पेक्टिव चर्चा और अनुवर्ती कार्रवाई में मदद करता है; यह BPMN संपादक या प्रक्रिया इंजन नहीं है।
चित्र समझने से पहले संकेत-प्रणाली जानें
OMG BPMN 2.0.2 विनिर्देश आधिकारिक संदर्भ है। नीचे दिया गया परिचय जानबूझकर हमारे उदाहरण के लिए आवश्यक अवधारणाओं तक सीमित है; BPMN में इससे अधिक विवरण होते हैं।
| तत्व | इस उदाहरण में अर्थ |
|---|---|
| पूल | सहयोग में भाग लेने वाला पक्ष |
| लेन | प्रक्रिया के भीतर एक विभाजन, यहां जिम्मेदारी दिखाने के लिए |
| कार्य | अनुरोध जांचने जैसी गतिविधि |
| आरंभ या समाप्ति इवेंट | मॉडल किए गए प्रक्रिया-पथ का आरंभ या अंत |
| गेटवे | पथों को अलग करने या जोड़ने का नियंत्रण-बिंदु |
| क्रम प्रवाह | प्रक्रिया के भीतर काम का क्रम; यह पूल की सीमा पार नहीं करता |
| संदेश प्रवाह | अलग-अलग पूलों से दिखाए गए स्वतंत्र प्रतिभागियों के बीच संचार |
क्रम प्रवाह उसी पूल की लेनों के बीच जा सकता है। केवल इसलिए उसी पूल की दो लेनों के बीच संदेश प्रवाह न बनाएं कि काम अलग-अलग टीमें करती हैं। लेन और स्वतंत्र प्रतिभागी एक-दूसरे के विकल्प नहीं हैं।
विस्तृत प्रतीकों और व्यवहार के लिए मानक विनिर्देश देखें। स्वचालन चलाने वाले मॉडल को कार्यशाला के रेखाचित्र से अधिक कड़ाई से सत्यापित करना चाहिए।
उदाहरण 1: आंतरिक पहुंच अनुरोध
एक काल्पनिक संगठन पर विचार करें जो देख रहा है कि कर्मचारी रिपोर्टिंग प्रणाली तक पहुंच कैसे मांगते हैं। संगठन को एक पूल के रूप में मॉडल करें, जिसमें सेवा डेस्क और पहुंच प्रशासन की लेन हों। यदि चुना हुआ सहयोग-दृश्य अनुरोधकर्ता को अलग प्रतिभागी मानता है, तो कर्मचारी को अलग दिखाया जा सकता है; सीमा को लगातार चुनें और दर्ज करें।
संगठन की प्रक्रिया का सरल पथ यह है:
- अनुरोध आता है और प्रक्रिया शुरू होती है।
- सेवा डेस्क जांचती है कि आवश्यक जानकारी मौजूद है या नहीं।
- एक विशिष्ट निर्णय पूरा और अधूरा अनुरोध अलग करता है।
- अधूरे अनुरोध तय किए गए अनुरोधकर्ता-संवाद के अनुसार स्पष्टीकरण के लिए लौटाए जाते हैं।
- पूरे अनुरोध अधिकृत पहुंच-जांच तक जाते हैं।
- स्वीकृत अनुरोधों को पहुंच मिलती है; अस्वीकृत अनुरोधों को कारण बताया जाता है।
- प्रक्रिया उचित दर्ज परिणाम के साथ समाप्त होती है।
निर्णय-पथों पर “आवश्यक जानकारी पूरी” और “जानकारी गायब” जैसी शर्तें लिखें। मूल प्रश्न के बिना आरेख साझा होने पर “हां” और “नहीं” समझना कठिन हो जाता है।
यह मॉडल बनाने के लिए विवरण है, यह दावा नहीं कि ये कदम किसी खास संगठन की सुरक्षा नीति पूरी करते हैं। पहुंच-अनुमोदन और प्रमाण की आवश्यकताएं उस संगठन के स्वीकृत नियंत्रणों से आनी चाहिए।
उदाहरण 2: आपूर्तिकर्ता प्रक्रिया में योगदान देता है
अब मान लें कि संगठन द्वारा अनुमति देने के बाद अलग आपूर्तिकर्ता को लाइसेंस वाला खाता सक्रिय करना है। आपूर्तिकर्ता को अलग पूल के रूप में दिखाएं। संगठन का सक्रियण अनुरोध और आपूर्तिकर्ता की पुष्टि प्रतिभागियों के बीच संचार हैं, इसलिए इन्हें संदेश प्रवाह से दिखाएं।
किसी आंतरिक कार्य से सीधे आपूर्तिकर्ता के कार्य तक क्रम का तीर न बनाएं। इससे एक प्रतिभागी की प्रक्रिया के भीतर काम का क्रम सीमा पार संचार के साथ भ्रमित होगा।
अगर आपूर्तिकर्ता की आंतरिक प्रक्रिया समीक्षा के दायरे से बाहर है, तो उसे छिपा सकते हैं। टीम को यह जानना पड़ सकता है कि कौन-सा संदेश आपूर्तिकर्ता के साथ बातचीत शुरू करता है और कौन-सा जवाब अपेक्षित है, बिना यह दिखावा किए कि उसे आपूर्तिकर्ता के अंदरूनी काम का ज्ञान है।
अब समीक्षा का एक उपयोगी सवाल दिखता है: अगर पुष्टि नहीं आती तो क्या होगा? औपचारिक मॉडल में टाइमर या अन्य इवेंट जोड़ने से पहले अपेक्षित अपवाद-प्रक्रिया तय करें। केवल टाइमआउट का लेबल यह नहीं बताता कि कौन अनुवर्ती कार्रवाई करेगा या वह कौन-सा निर्णय ले सकता है।
बदलाव से पहले मॉडल में मामलों के पथ देखें
तीन वास्तविक और उचित रूप से पहचान-मुक्त मामले चुनें: एक सामान्य रूप से पूरा हुआ अनुरोध, एक ऐसा अनुरोध जिसमें स्पष्टीकरण चाहिए, और एक अपवाद। व्यक्तिगत और गोपनीय विवरण स्वीकृत केस प्रणाली में रखें; कार्यशाला में संदर्भ या सारांश का उपयोग करें।
हर मामले में काम करने वाले लोगों से उसका पथ दिखाने को कहें। काम वास्तव में कहां रुका? कौन-सी जानकारी गायब थी? किस प्रतिभागी को लगा कि अगले कदम की जिम्मेदारी किसी और की है? दस्तावेजीकृत प्रक्रिया और देखे गए व्यवहार के अंतर दर्ज करें।
मॉडल को चुपचाप भविष्य की आदर्श प्रक्रिया में न बदलें। मौजूदा पथ और प्रस्तावित बदलाव अलग-अलग चिह्नित करें। अन्यथा टीम एक सुंदर आरेख लेकर जा सकती है जो उन मामलों को अब समझाता ही नहीं जिन्हें वह जांचने के लिए बनाया गया था।
प्रक्रिया मॉडल इस बात की परिकल्पना है कि काम कैसे आगे बढ़ता है। समय-मुद्राएं और केस इतिहास उस परिकल्पना को परखने में मदद करते हैं। न तो आरेख और न ही किसी प्रतिभागी की याददाश्त अपने आप में पूरा प्रमाण है।
सुधार निर्णय का उदाहरण
इस काल्पनिक उदाहरण में टीम बारह अनुरोध देखती है। यह संख्या सिर्फ समझाने के लिए है; यह मानक या NextRetro ग्राहक का परिणाम नहीं है। कई अनुरोध जानकारी की जांच और पहुंच-अनुमोदन के बीच इसलिए रुके क्योंकि हैंडऑफ़ में निर्णय लेने वाले व्यक्ति का नाम नहीं था।
पहला प्रस्ताव हर अनुमोदन को स्वचालित करने का है। मॉडल दिखाता है कि यह जल्दबाजी क्यों होगी: टीम अभी इस बात पर सहमत नहीं हुई कि किन अनुरोधों को कौन-सा अनुमोदन चाहिए। अस्पष्ट निर्णय को स्वचालित करने से जिम्मेदारी स्पष्ट किए बिना अधूरा काम तेजी से आगे जा सकता है।
टीम छोटा प्रयोग चुनती है। अगले दस पात्र अनुरोधों में सेवा डेस्क हैंडऑफ़ भेजने से पहले अनुमोदन के जिम्मेदार व्यक्ति की पहचान करेगी। जिम्मेदारी स्पष्ट होने की प्रतीक्षा का समय, अनुमोदन करने में लगे समय से अलग दर्ज होगा।
सुरक्षा नियंत्रण वही रहता है: पहुंच नियंत्रण। तेजी से काम करने के लिए अनुमोदन छोड़ना उचित नहीं है। अगली समीक्षा में टीम जांचेगी कि जिम्मेदार व्यक्ति न होने से हुई देरी घटी या नहीं और अतिरिक्त तैयारी से नया अवरोध बना या नहीं।
इस तरह प्रक्रिया आरेख को दिखने वाले बदलाव से जोड़ा जाता है, न कि आरेख पूरा करने को ही सुधार मान लिया जाता है।
आरेख के साथ समीक्षा कार्यपत्रक रखें
हर संभावित समस्या के लिए ये फ़ील्ड दर्ज करें:
स्थान: कौन-सा कार्य, निर्णय या हैंडऑफ़ प्रभावित है?
देखा गया मामला: कौन-सा उदाहरण कठिनाई दिखाता है?
अपेक्षित ट्रिगर: अगले कदम को क्या शुरू करना चाहिए?
वास्तविक बाधा: इसे किसने रोका?
प्रस्तावित बदलाव: अगले पात्र मामलों में क्या अलग होगा?
सीमा: कौन-सा नियंत्रण या गुणवत्ता आवश्यकता बनी रहनी चाहिए?
समीक्षा प्रमाण: टीम क्या और कब देखेगी?
बदलावों को प्राथमिकता देने से पहले लोगों को मॉडल पर सवाल उठाने का समय देने वाला रेट्रोस्पेक्टिव प्रारूप चुनें। फिर बैठक के बाद प्रयोग को दिखते रहने देने के लिए कार्रवाई मदों की मार्गदर्शिका का उपयोग करें।
अक्सर पूछे जाने वाले प्रश्न
क्या BPMN में पूल और लेन एक ही चीज हैं?
नहीं। पूल सहयोग में एक प्रतिभागी दिखाता है। लेन प्रक्रिया को विभाजित करती है। एक पूल में क्रम प्रवाह लेनों को पार कर सकता है, जबकि अलग प्रतिभागी पूलों के बीच संचार संदेश प्रवाह से दिखता है।
क्या हर प्रक्रिया फ्लोचार्ट BPMN आरेख है?
नहीं। सामान्य फ्लोचार्ट अनौपचारिक प्रतीक और नियम अपना सकता है। किसी मॉडल को BPMN तभी कहें जब वह नोटेशन के संबंधित नियमों का पालन करे; स्वचालन में इस्तेमाल होने पर उसे उचित रूप से सत्यापित करें।
क्या NextRetro चलाए जा सकने वाले BPMN मॉडल बना सकता है?
NextRetro BPMN मॉडलिंग टूल या प्रक्रिया इंजन नहीं है। आधिकारिक मॉडल उपयुक्त संपादक में रखें और देखी गई समस्याओं, अलग-अलग व्याख्याओं और सहमत सुधार प्रयोगों पर चर्चा के लिए रेट्रोस्पेक्टिव बोर्ड का उपयोग करें।