व्यापार प्रक्रिया मॉडल और नोटेशन (BPMN) प्रवाह को दृश्य रूप से दर्शाने के लिए मानक है। हालांकि, इन आरेखों के निर्माण तत्वों के बीच अक्सर भ्रम पैदा होता है। विशेष रूप से, कार्यों और घटनाओं सही मॉडलिंग के लिए महत्वपूर्ण है। यदि आप इन्हें गलत कर देते हैं, तो परिणामस्वरूप प्रक्रिया नक्शा वास्तविकता का गलत प्रतिनिधित्व कर सकता है। यह मार्गदर्शिका तकनीकी अंतरों, व्यावहारिक अनुप्रयोगों और गलती के परिणामों को समझाती है। हम आकृतियों, अर्थशास्त्र और क्रियान्वयन व्यवहार का अध्ययन करेंगे।
🎯 अंतर क्यों महत्वपूर्ण है
BPMN में, प्रत्येक प्रतीक का एक विशिष्ट अर्थ होता है। कार्य और घटना के बीच अंतर केवल दृश्य नहीं है; यह कार्यात्मक है। एक कार्य कार्य करने का प्रतिनिधित्व करता है। एक घटना कुछ होने का प्रतिनिधित्व करती है। यह अंतर निर्णय लेने वाले इंजन द्वारा प्रवाह के अर्थ को निर्धारित करता है। यह समय के ट्रैकिंग, त्रुटियों के प्रबंधन और मानव संसाधनों के निर्धारण को प्रभावित करता है।
- कार्यों संसाधनों का उपयोग करते हैं और पूरा करने में समय लेते हैं।
- घटनाओं राज्य परिवर्तन को ट्रिगर करती हैं या सीमाओं को चिह्नित करती हैं बिना सीधे संसाधनों के उपयोग के।
जब ऑटोमेशन के लिए प्रक्रिया का मॉडलिंग करते हैं, तो यह अंतर यह निर्धारित करता है कि क्या एक प्रणाली इनपुट के लिए प्रतीक्षा करती है या कोई क्रिया करती है। इसे सही तरीके से करने से आपके KPIs सही होते हैं। यदि आप इंतजार के समय को एक कार्य के रूप में मॉडल करते हैं, तो आप प्रक्रिया समय को गलत कार्यकर्ता के लिए जिम्मेदार ठहरा सकते हैं। यदि आप क्रिया को एक घटना के रूप में मॉडल करते हैं, तो इंजन निष्पादन तर्क को छोड़ सकता है। यहाँ निपुणता से बेहतर संचालन दृष्टि मिलती है।
🏗️ गहन अध्ययन: BPMN कार्य
एक कार्य प्रक्रिया में सबसे आम गतिविधि है। यह कार्य की परमाणु इकाई का प्रतिनिधित्व करता है। तकनीकी शब्दों में, एक कार्य एक गतिविधि है जिसमें उप-संरचना नहीं होती है। यह एक ही चरण है। दृश्य प्रतिनिधित्व एक गोल आयत है। आइए विशिष्ट प्रकार के कार्यों और उनके प्रक्रिया के लिए अर्थ को देखें।
1. उपयोगकर्ता कार्य 👤
एक उपयोगकर्ता कार्य इंगित करता है कि मानव कार्यकर्ता कार्य करना होगा। यह प्रणाली स्वचालन और मानव हस्तक्षेप के बीच सेतु है। जब प्रक्रिया एक उपयोगकर्ता कार्य तक पहुँचती है, तो इंजन आमतौर पर निष्पादन को रोक देता है और मानव के कार्य पूरा करने का इंतजार करता है। उपयोगकर्ता “पूरा” क्लिक करे या फॉर्म जमा करे तक कार्य प्रतीक्षा अवस्था में रहता है।
- इनपुट: कार्य करने के लिए आवश्यक डेटा।
- आउटपुट: मानव क्रिया का परिणाम (उदाहरण के लिए, मंजूरी, अस्वीकृति, डेटा प्रविष्टि)।
- अवधि: चर। पूरी तरह मानव गति और उपलब्धता पर निर्भर करता है।
2. सेवा कार्य ⚙️
एक सेवा कार्य सिस्टम-टू-सिस्टम इंटरैक्शन का प्रतिनिधित्व करता है। कोई मानव शामिल नहीं है। यहीं ऑटोमेशन का जादू होता है। प्रक्रिया इंजन एक बाहरी सेवा को बुलाता है, जैसे कि API कॉल, डेटाबेस लेखन या वेब सेवा। इंजन अगले चरण पर जाने से पहले सेवा के उत्तर का इंतजार करता है।
- इनपुट: API को पारित किया गया संरचित डेटा।
- आउटपुट: बाहरी प्रणाली से प्राप्त प्रतिक्रिया पेलोड।
- अवधि: नेटवर्क लेटेंसी और सिस्टम प्रदर्शन द्वारा निर्धारित।
3. हाथ से कार्य 📝
एक हाथ से कार्य एक उपयोगकर्ता कार्य के समान है, लेकिन यह इस बात की ओर इशारा करता है कि कार्य प्रक्रिया प्रणाली के बाहर होता है। प्रक्रिया इंजन पूर्णता का ट्रैक नहीं करता है। यह मानता है कि कार्य अंततः किया जाएगा, लेकिन यह सूचना नहीं भेजता है या कार्य आइटम नहीं बनाता है। इसका उपयोग पुराने कार्यों या ऑफलाइन प्रक्रियाओं के लिए किया जाता है।
- क्रियान्वयन: कोई सिस्टम ट्रिगर नहीं।
- ट्रैकिंग: कोई नहीं। इंजन तुरंत अगले चरण पर जाता है।
- उपयोग के मामले: एक भौतिक दस्तावेज या मौखिक समझौता दर्ज करना।
4. स्क्रिप्ट कार्य 💻
जब कोई सेवा कार्य बहुत सामान्य होता है, तो एक स्क्रिप्ट कार्य इंलाइन कोड निष्पादन की अनुमति देता है। यह डेटा परिवर्तनों या गणनाओं के लिए उपयोगी है जिन्हें बाहरी सेवा की आवश्यकता नहीं होती है। कोड इंजन के भीतर ही चलता है।
- तर्क: समर्थित स्क्रिप्टिंग भाषा में लिखा गया कस्टम तर्क।
- निर्भरता: कोई नहीं। यह प्रक्रिया उदाहरण के भीतर स्थानीय रूप से चलता है।
5. भेजना और प्राप्त करना कार्य 📬
ये कार्य संदेश प्रेषण पर विशेष रूप से होते हैं। एक भेजने वाला कार्य डेटा किसी अन्य सिस्टम या प्रक्रिया में स्थानांतरित करता है। एक प्राप्त करने वाला कार्य आने वाले संदेश का इंतजार करता है। यद्यपि इनमें संचार शामिल होता है, लेकिन इन्हें अभी भी कार्य के रूप में माना जाता है, केवल ट्रिगर स्थिति परिवर्तन नहीं।
- भेजने वाला कार्य: इंजन डेटा को भेजता है और तुरंत आगे बढ़ जाता है।
- प्राप्त करने वाला कार्य: इंजन रुक जाता है जब तक कोई संदेश नहीं आ जाता है।
🎲 गहन अध्ययन: BPMN घटनाएँ
घटनाएँ गोलाकार होती हैं। वे प्रक्रिया प्रवाह के शुरुआत, मध्य या अंत को चिह्नित करती हैं। कार्यों के विपरीत, घटनाएँ कार्य का प्रतिनिधित्व नहीं करती हैं। वे घटित होनाकुछ के घटित होने का प्रतिनिधित्व करती हैं। वे प्रक्रियाओं को शुरू करने वाले ट्रिगर हैं या निष्पादन के मार्ग को बदलने वाले संकेत हैं। नियंत्रण प्रवाह के लिए घटनाओं के तीन श्रेणियों को समझना आवश्यक है।
1. शुरुआती घटनाएँ ▶️
एक शुरुआती घटना उस बिंदु को चिह्नित करती है जहाँ प्रक्रिया शुरू होती है। कोई आगमन प्रवाह नहीं है। जब इस घटना को ट्रिगर किया जाता है, तो प्रक्रिया उदाहरण बनता है। आप प्रक्रिया के मध्य में एक शुरुआती घटना नहीं रख सकते। यह हमेशा पहला तत्व होता है।
- टाइमर शुरुआती घटना: प्रक्रिया एक विशिष्ट समय या अंतराल पर शुरू होती है।
- संदेश शुरुआती घटना: प्रक्रिया तब शुरू होती है जब एक विशिष्ट संदेश प्राप्त होता है।
- सिग्नल स्टार्ट इवेंट: प्रक्रिया तब शुरू होती है जब एक सिग्नल को सार्वजनिक रूप से प्रसारित किया जाता है।
2. मध्यवर्ती घटनाएँ ⏸️
मध्यवर्ती घटनाएँ प्रक्रिया के शुरू होने और समाप्त होने के बीच होती हैं। वे प्रक्रिया को कुछ के लिए प्रतीक्षा करने या धारा में कुछ होने पर प्रतिक्रिया करने की अनुमति देती हैं। इन्हें एक चक्कर के रूप में बनाया जाता है जिसके अंदर एक प्रतीक होता है (जैसे घड़ी या एक लिफाफा)।
- टाइमर मध्यवर्ती घटना: प्रक्रिया एक निर्धारित अवधि के लिए रुक जाती है। याद दिलाने या देरी के लिए उपयोगी।
- संदेश मध्यवर्ती घटना: प्रक्रिया आगे बढ़ने से पहले एक विशिष्ट संदेश का इंतजार करती है।
- त्रुटि मध्यवर्ती घटना: प्रक्रिया पिछले कार्य में हुई त्रुटि को पकड़ती है।
3. समाप्ति घटनाएँ ⏹️
एक समाप्ति घटना प्रक्रिया के समाप्त होने को चिह्नित करती है। एक बार पहुँचने के बाद, प्रक्रिया उदाहरण को नष्ट कर दिया जाता है, और इससे संबंधित सभी डेटा को आर्काइव कर दिया जाता है या इतिहास में स्थानांतरित कर दिया जाता है। एक आरेख में एक से अधिक समाप्ति घटनाएँ हो सकती हैं, जो विभिन्न परिणामों (सफलता, विफलता, समय सीमा समाप्त) का प्रतिनिधित्व करती हैं।
- संदेश समाप्ति घटना: समाप्ति पर एक सूचना भेजता है।
- सिग्नल समाप्ति घटना: अन्य प्रक्रियाओं के लिए सुनने के लिए एक सिग्नल उत्पन्न करता है।
- त्रुटि समाप्ति घटना: एक गंभीर त्रुटि को चिह्नित करता है जो कार्यप्रवाह को रोक देती है।
📊 तुलना: कार्य बनाम घटनाएँ
अंतरों को स्पष्ट रूप से देखने के लिए, हम दोनों तत्वों की कई दिशाओं के आधार पर तुलना कर सकते हैं। यह तालिका संरचनात्मक और अर्थपूर्ण अंतरों को उजागर करती है।
| विशेषता | कार्य | घटना |
|---|---|---|
| आकृति | गोल आयत | वृत्त |
| कार्य | कार्य करता है | घटना की सूचना देता है |
| अवधि | सक्रिय रूप से समय का उपभोग करता है | तत्काल (आमतौर पर) |
| इंजन क्रिया | तर्क को निष्पादित करता है या इनपुट का इंतजार करता है | प्रवाह को ट्रिगर करता है या पकड़ता है |
| संसाधन | संसाधन की आवश्यकता होती है (मानव या प्रणाली) | संसाधन की आवश्यकता नहीं होती है |
| स्थिति | कहीं भी हो सकता है | शुरुआत (पहले होना चाहिए), अंत (आखिर में होना चाहिए), या मध्यवर्ती |
🤔 व्यापार के लिए अंतर क्यों महत्वपूर्ण है
इन्हें सिर्फ आकृतियाँ बनाने के रूप में सोचना आसान है। हालांकि, व्यापार तर्क अर्थशास्त्र पर निर्भर करता है। यदि आप एक सूचना को एक कार्य के रूप में मॉडल करते हैं, तो प्रणाली प्रोसेसिंग शुल्क ले सकती है। यदि आप भुगतान को एक घटना के रूप में मॉडल करते हैं, तो प्रणाली बैलेंस की पुष्टि नहीं कर सकती है। यही कारण है कि सटीकता अनिवार्य है।
1. सटीक KPI मापन 📈
प्रदर्शन मापदंड मॉडल पर निर्भर करते हैं। यदि आप ग्राहक के अनुमोदन के लिए कितना समय इंतजार करता है, उसे मापना चाहते हैं, तो यह एक कार्य है। यदि आप फॉर्म जमा करने और प्रतिक्रिया प्राप्त करने के बीच के समय को मापना चाहते हैं, तो इसमें घटनाएँ शामिल होती हैं। दोनों को गलती से मिलाने से आपके डेटा विकृत हो जाते हैं। आप एक प्रक्रिया को तेज मान सकते हैं क्योंकि आपने इंतजार समय को घटना (तत्काल) के रूप में गिना बजाय कार्य (अवधि) के रूप में गिना।
2. स्वचालन तर्क ⚡
प्रक्रिया इंजन तत्व के प्रकार के आधार पर कोड निष्पादित करते हैं। एक सेवा कार्य एक कार्यक्रम को ट्रिगर करता है। एक संदेश घटना कॉलबैक का इंतजार करती है। यदि आप इन्हें बदल देते हैं, तो कोड नहीं चलेगा, या इंजन लटक जाएगा। उदाहरण के लिए, एक सेवा कार्य एक अनुरोध भेजता है। एक संदेश घटना उत्तर का इंतजार करती है। यदि आप एक सेवा कार्य की आवश्यकता होने पर संदेश घटना का उपयोग करते हैं, तो प्रक्रिया कभी डेटा नहीं भेजेगी।
3. त्रुटि प्रबंधन 🛡️
घटनाओं का अक्सर त्रुटियों को पकड़ने के लिए उपयोग किया जाता है। एक त्रुटि मध्यवर्ती घटना एक कार्य द्वारा फेंकी गई त्रुटि को पकड़ सकती है। यदि कार्य सही तरीके से परिभाषित नहीं है, तो त्रुटि घटना सही तरीके से जुड़ नहीं पाएगी। अंतर त्रुटि सीमा निर्धारित करता है। एक कार्य वह स्थान है जहाँ त्रुटि होती है। एक घटना वह स्थान है जहाँ त्रुटि पकड़ी जाती है।
4. मानव कार्यप्रवाह प्रबंधन 👥
उपयोगकर्ता कार्यों के लिए कार्य सूचियाँ बनाई जाती हैं। प्रणाली को पता है कि एक मानव को कार्रवाई करनी है। मध्यवर्ती घटनाएँ कार्य आइटम नहीं बनाती हैं। यदि आप समीक्षा चरण को मध्यवर्ती घटना के रूप में मॉडल करते हैं, तो मानव को कार्य करने के लिए सूचना कभी नहीं दिखेगी। वे पूरी तरह से बाहर छोड़ दिए जाएंगे। इससे वास्तविकता में टूटी हुई प्रक्रियाएँ बनती हैं।
🛠️ सामान्य मॉडलिंग गलतियाँ
यहाँ तक कि अनुभवी मॉडलर भी गलतियाँ करते हैं। इन पैटर्नों को पहचानने से आप अपने काम में उनसे बचने में मदद मिलेगी।
- क्रियाओं के लिए घटनाओं का उपयोग करना: कृपया एक वृत्त का उपयोग “आदेश मंजूर करें” को दर्शाने के लिए न करें। यह कार्य है। उपयोगकर्ता कार्य का उपयोग करें। एक घटना केवल “आदेश प्राप्त” को दर्शानी चाहिए।
- सुधार: शुरुआत घटना = आदेश प्राप्त। कार्य = आदेश मंजूर करें।
- टाइमर शुरुआत और मध्यवर्ती को गलती से मिलाना: एक टाइमर शुरुआत घटना एक नए प्रक्रिया उदाहरण को ट्रिगर करती है। एक टाइमर मध्यवर्ती घटना एक मौजूदा प्रक्रिया को रोकती है। केवल इंतजार करने के लिए एक नया प्रक्रिया शुरू न करें।
- डेटा फ्लो को नजरअंदाज करना: कार्य अक्सर डेटा को बदलते हैं। घटनाएँ आमतौर पर बस उसे पास करती हैं। यदि आपको किसी मान की गणना करनी है, तो कार्य (स्क्रिप्ट या सेवा) का उपयोग करें। यदि आप बस मान को आगे बढ़ाना चाहते हैं, तो क्रमिक प्रवाह का उपयोग करें।
- बहुत सारे बाहरी प्रवाह: कार्य आमतौर पर एक बाहरी प्रवाह रखते हैं, जब तक कि उनके बाद गेटवे नहीं आता है। घटनाओं के विशिष्ट नियम होते हैं। एक मध्यवर्ती ग्रहण घटना में एक आगमन और एक बाहरी प्रवाह होता है। एक मध्यवर्ती उत्सर्जन घटना में एक आगमन और एक बाहरी प्रवाह होता है। प्रवाह को समझना महत्वपूर्ण है।
🔧 उन्नत परिदृश्य: बातचीत और जटिलता
जैसे-जैसे प्रक्रियाएँ बढ़ती हैं, कार्यों और घटनाओं के बीच बातचीत अधिक जटिल हो जाती है। उप-प्रक्रियाएँ नए स्तर जोड़ती हैं। आइए देखें कि इन तत्वों का व्यवहार उन्नत संदर्भों में कैसा होता है।
1. घटना उप-प्रक्रियाएँ
ये विशेष ब्लॉक हैं जिनमें घटना शुरुआत के रूप में होती है। वे मुख्य प्रक्रिया के साथ समानांतर चलती हैं। इनका उपयोग आमतौर पर त्रुटि प्रबंधन के लिए किया जाता है। उदाहरण के लिए, यदि कोई कार्य विफल होता है, तो घटना उप-प्रक्रिया त्रुटि को पकड़ लेती है। मुख्य प्रक्रिया जारी रहती है, लेकिन उप-प्रक्रिया पुनर्स्थापना का ध्यान रखती है। इसके लिए अंतर पर निर्भरता है: कार्य विफल हुआ, घटना ने इसे पकड़ लिया।
2. समानांतर गेटवे और कार्य
जब समानांतर गेटवे का उपयोग करते हैं, तो एक साथ कई कार्य चल सकते हैं। प्रत्येक कार्य स्वतंत्र होता है। यदि आप एक को घटना से बदलते हैं, तो समन्वय परिवर्तित हो जाता है। इंजन आगे बढ़ने से पहले घटना के घटित होने का इंतजार कर सकता है, जिससे समानांतरता का मॉडल बदल जाता है। सुनिश्चित करें कि आप समझते हैं कि समानांतरता कार्य (कार्य) के लिए है या अवस्था (घटनाएँ) के लिए।
3. डेटा स्थायित्व
कार्य अक्सर पूरा होने से पहले डेटा को डेटाबेस में लिखने की आवश्यकता महसूस करते हैं। घटनाएँ आमतौर पर डेटा लिखती नहीं हैं; वे उसे पढ़ती हैं या संकेत देती हैं। यदि आपकी प्रक्रिया में लॉग एंट्री स्टोर करने की आवश्यकता है, तो सेवा कार्य का उपयोग करें। यदि आप प्रक्रिया शुरू हुई के बारे में लॉग करना चाहते हैं, तो संदेश अंत घटना का उपयोग करें। अंतर आपके डेटाबेस स्कीमा डिज़ाइन पर प्रभाव डालता है।
📝 मॉडेलर्स के लिए सर्वोत्तम प्रथाएँ
स्पष्टता और सटीकता बनाए रखने के लिए, अपने आरेख बनाते समय इन दिशानिर्देशों का पालन करें।
- “कौन” प्रश्न पूछें: कौन काम करता है? यदि कोई मानव या प्रणाली कोई क्रिया करता है, तो यह एक कार्य है। यदि कोई चीज प्रक्रिया पर होती है, तो यह एक घटना है।
- उदाहरण: “ईमेल भेजें” एक कार्य है। “ईमेल भेजा गया” एक घटना है।
- इसे परमाणु रखें: कार्य को बहुत जटिल मत बनाएं। यदि इसमें कई चरण शामिल हैं, तो इसे उप-प्रक्रिया में बांट दें। इससे आरेख पढ़ने योग्य बना रहता है।
- स्पष्ट रूप से लेबल करें: स्पष्ट लेबल का उपयोग करें। “इन्वेंटरी जांचें” “क्रिया 1” से बेहतर है। इससे स्टेकहोल्डर्स को कार्य प्रकार को समझने में मदद मिलती है।
- दृश्य सुसंगतता: आकृतियों का पालन करें। कार्य के लिए आयत। घटनाओं के लिए वृत्त। स्थान बचाने के लिए इन्हें मिलाने मत दें।
- विकासकर्ताओं के साथ समीक्षा करें: विकासकर्ताओं को यह जानने की आवश्यकता होती है कि तर्क कहाँ रहता है। कार्य को कोड फंक्शन से मैप किया जाता है। घटनाओं को ट्रिगर से मैप किया जाता है। सुनिश्चित करें कि वे मैपिंग पर सहमत हैं।
🚀 प्रदर्शन निगरानी पर प्रभाव
अंत में, निगरानी पहलू को ध्यान में रखें। जब कोई प्रक्रिया चलती है, तो आपको यह जानने की आवश्यकता होती है कि बफलेट जगह कहाँ होते हैं। कार्य बफलेट के मुख्य स्रोत हैं क्योंकि वे समय लेते हैं। घटनाएँ तुरंत होती हैं। यदि आपकी प्रक्रिया धीमी है, तो कार्यों को देखें। यदि आपकी प्रक्रिया इंतजार कर रही है, तो मध्यवर्ती घटनाओं को देखें। 24 घंटे के लिए इंतजार कर रही टाइमर मध्यवर्ती घटना इवेंट लॉग में लंबे समय के रूप में दिखाई देगी, लेकिन तकनीकी रूप से यह एक इंतजार अवस्था है, कार्य अवस्था नहीं। इनके बीच अंतर करना आपको संसाधन आवंटन को अनुकूलित करने में मदद करता है।
यदि आप इंतजार को कार्य के रूप में मॉडल करते हैं, तो आप तेजी से बढ़ाने के लिए अधिक लोगों को नियुक्त कर सकते हैं। यदि आप इसे घटना के रूप में मॉडल करते हैं, तो आप टाइमर कॉन्फ़िगरेशन को समायोजित कर सकते हैं। इस निर्णय का बजट और दक्षता पर प्रभाव पड़ता है। इसलिए, चयन केवल तकनीकी नहीं है; यह वित्तीय भी है।
🔚 मॉडेलर्स के लिए अंतिम विचार
BPMN को समझने के लिए आकृतियों के बारे में जानने से अधिक चाहिए। इसमें प्रक्रिया उदाहरण के जीवनचक्र को समझना आवश्यक है। कार्य प्रक्रिया को आगे बढ़ाते हैं। घटनाएँ प्रवाह को नियंत्रित करती हैं। इन्हें गलत करने से टूटी हुई स्वचालन, गलत रिपोर्टिंग और भ्रमित स्टेकहोल्डर्स की स्थिति बनती है। यहाँ वर्णित परिभाषाओं का पालन करके, आप सुनिश्चित कर सकते हैं कि आपके आरेख केवल सुंदर चित्र नहीं हैं, बल्कि कार्यात्मक नक्शे हैं।
हर प्रतीक की जाँच करने के लिए समय लें। पूछें कि यह कार्य का प्रतिनिधित्व करता है या एक संकेत। इंजन की आवश्यकताओं की जाँच करें। डेटा प्रवाह की पुष्टि करें। इस सावधानी का लाभ आपकी व्यापार प्रक्रियाओं की विश्वसनीयता में दिखाई देता है। सही आधार पर, आपके मॉडल डिजिटल रूपांतरण और संचालन उत्कृष्टता के लिए एक मजबूत मार्गदर्शिका के रूप में कार्य करेंगे।
याद रखें, स्पष्टता राजा है। संदेह होने पर, उस प्रतीक का चयन करें जो संचालन की वास्तविकता का सबसे अच्छा प्रतिनिधित्व करता है। कार्य के लिए कार्य। घटना के लिए घटना। यह सरल नियम आपके मॉडल को व्यवसाय के साथ संरेखित रखता है।
