स्वीकृति के लिए WeChat समूह: स्वीकृति प्रवाह, दस्तावेज़ और संगठन के अधिकारों को कैसे सिस्टम में बदला जाए

शुरुआत: व्यापारिक यात्रा की मंजूरी के लिए समूह संदेश पर निर्भर, मंजूरी देने वाले को ढूंढने के लिए पूछना ही एकमात्र रास्ता

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

यह कोई अनोखी स्थिति नहीं है। देश की बड़ी संख्या में कंपनियों में मंजूरी का यही प्रोसेस चलता है:

• लोगों को ढूंढने के लिए पूछना ही एकमात्र रास्ता : नए कर्मचारी के नौकरी में आने के पहले हफ्ते में सबसे अक्सर पूछा जाने वाला सवाल होता है, "मुझे छुट्टी के लिए किसे मंजूरी लेनी है? मेरे भत्ते का भुगतान कौन करेगा?"
• समूह संदेश को दस्तावेज़ के रूप में इस्तेमाल करना : वीचैट या डिंगडिंग समूह में "@बॉस ने मंजूरी दे दी" को मंजूरी मिलने का प्रमाण मान लिया जाता है, जिसके बाद बाद में ऑडिट करना असंभव हो जाता है।
• विभागों के बीच डेटा संगत नहीं होना : बिक्री विभाग का मानना है कि ग्राहक के दौरे की मंजूरी मिल गई है, जबकि मार्केटिंग विभाग का मानना है कि मंजूरी नहीं मिली है; वित्तीय विभाग ने बिक्री विभाग के स्क्रीनशॉट के आधार पर भुगतान कर दिया।
• अधिकारों का निर्धारण मौखिक रूप से होना : एक प्रबंधक के नौकरी छोड़ने के बाद उसके अधिकारों को वापस नहीं लिया गया, और नए कर्मचारी को यह जानकारी नहीं थी कि पूर्व प्रबंधक द्वारा मंजूर किए गए अनुबंध किसके पास हैं।

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

01 व्यवसाय को कैसे विभाजित करें: मंजूरी प्रवाह का त्रिस्तरीय संरचना

मंजूरी की प्रक्रिया को तीन स्तरों में विभाजित करना वास्तव में तीन स्तरों में है:

1. मामले का स्तर : कर्मचारी "व्यापारिक यात्रा, छुट्टी, भत्ते, अनुबंध, मुद्रा लगाना, खरीदारी" जैसे विशिष्ट मामलों का आवेदन करता है; हर मामले में राशि, दिनों की संख्या, अनुलग्नक और संबंधित व्यवसाय वस्तुएं होती हैं (व्यापारिक यात्रा के आवेदन का संबंध बिक्री ऑर्डर से होता है, भत्ते का संबंध चालान से होता है)।
2. प्रक्रिया का स्तर : मामला एक नोड से दूसरे नोड की ओर बढ़ता है; नोड के मंजूरी देने वाले का निर्धारण गतिशील रूप से होता है (विभाग, स्तर, राशि, श्रेणी के आधार पर), न कि स्थायी रूप से तय।
3. डेटा का स्तर : मंजूरी मिलने या अस्वीकृति के बाद, डेटा को व्यवसाय सिस्टम (HR, वित्तीय विभाग, बिक्री, अनुबंध डेटाबेस) में वापस लिख दिया जाना चाहिए, न कि केवल मंजूरी प्रवाह में ही रहना चाहिए।

तीनों स्तरों का रिश्ता इस प्रकार है: मामला प्रवेश बिंदु है, प्रक्रिया मुख्य धमनी है, और डेटा निकास है। यदि OA सिस्टम में केवल प्रक्रिया बनाई गई है और डेटा का निकास नहीं किया गया है, तो मंजूरी प्रवाह एक अलग द्वीप बन जाएगा; यदि केवल मामले का निर्माण किया गया है और प्रक्रिया नहीं बनाई गई है, तो यह "फॉर्म भरने की प्रणाली" में बदल जाएगा।

02 कैसे डिजाइन करें: गतिशील नोड्स, अधिकार मैट्रिक्स और ट्रेसेबल तीन तत्वों का संयोजन

नोड्स का डिजाइन: मंजूरी देने वाले का निर्धारण स्थायी रूप से तय नहीं होता है।

बहुत सारे OA सिस्टम शुरू में ही मंजूरी देने वाले को तय कर देते हैं: "व्यापारिक यात्रा का आवेदन → विभागीय प्रबंधक → HR → मुख्य प्रबंधक"। इसके परिणामस्वरूप विभागीय प्रबंधक का तबादला हो जाता है, HR को विभागीय प्रशासन में शामिल कर दिया जाता है, और मुख्य प्रबंधक बाहर जाता है; इससे सिस्टम पूरी तरह से अव्यवस्थित हो जाता है।

सही तरीका: मंजूरी देने वाले का निर्धारण नियमों के आधार पर गतिशील रूप से होता है। नियमों के आधार पर आमतौर पर चार आयाम होते हैं:

• विभाग का आयाम : आवेदक का विभाग उस विभाग के वर्तमान प्रभारी से मिलान किया जाता है (संगठन के पेड़ के आधार पर रीयल-टाइम चेक)।
• स्तर का आयाम : राशि, दिनों की संख्या और अनुबंध की राशि के आधार पर अलग-अलग रेंज और अलग-अलग मंजूरी स्तर होते हैं।
• भूमिका का आयाम : अनुबंध की राशि 500,000 से अधिक हो, तो कानूनी विभाग को जरूरी रूप से शामिल करना होगा; कर्मचारी विदेश में यात्रा कर रहा है, तो सुरक्षा और अनुपालन के लिए जरूरी है कि अनुबंध पर हस्ताक्षर किया जाए।
• एजेंट का आयाम : जब मंजूरी देने वाला छुट्टी पर जाता है या यात्रा पर जाता है, तो उसका एजेंट स्वचालित रूप से नियुक्त हो जाता है; एजेंट का निर्धारण संगठन के संबंधों या HR द्वारा किया जाता है।

इन चार आयामों को मिलाकर "नियम एक्सप्रेशन" बनाया जाता है; प्रक्रिया इंजन नियमों के आधार पर नोड्स का गणना रीयल-टाइम में करता है, और मंजूरी देने वाले का नाम स्थायी रूप से तय नहीं किया जाता है। विभागीय तबादले या संगठनात्मक संशोधन के बाद भी प्रक्रिया टेम्पलेट में कोई बदलाव नहीं किया जाता है।

अधिकार का डिजाइन: मेनू, डेटा और फील्ड के तीन स्तर होते हैं।

अधिकार यह नहीं है कि "क्या सिस्टम में जा सकता है", बल्कि यह तीन स्तरों में है:

• मेनू का स्तर : क्या इस मॉड्यूल को देखा जा सकता है (सामान्य कर्मचारी "संगठन संरचना प्रबंधन" को नहीं देख सकता है)।
• डेटा का स्तर : क्या इस डेटा को देखा जा सकता है (बिक्री विभाग केवल अपने विभाग के कर्मचारियों के भत्ते को देख सकता है, बिक्री दूसरे विभाग के कर्मचारियों के भत्ते को नहीं देख सकता है)।
• फील्ड का स्तर : क्या इस डेटा के कुछ फील्ड को देखा जा सकता है (सामान्य मंजूरी देने वाला आवेदक की वेतन राशि के फील्ड को नहीं देख सकता है, लेकिन HR इसे देख सकता है)।

तीन स्तरों के अधिकारों को अलग-अलग बनाने के बाद, OA सिस्टम जटिल संगठनात्मक संरचना का समर्थन कर सकता है: समूह-शाखा-विभाग-समूह, विभागों के बीच डेटा का नियंत्रण "मैं अपनी लाइन को देख सकता हूं + मैं इस लाइन का प्रभारी हूं" इस दोहरे नियम के आधार पर किया जाता है।

ट्रेसेबल डिजाइन: मंजूरी लॉग के सात तत्व

हर मंजूरी के ऑपरेशन के लिए सात तत्व जरूरी होते हैं:

1. ऑपरेशन करने वाला : कौन ने क्लिक किया।
2. ऑपरेशन का समय : सेकंड के आधार पर सटीक।
3. ऑपरेशन का एक्शन : सहमति, अस्वीकृति, ट्रांसफर, साइन जोड़ना, वापस लेना।
4. ऑपरेशन का राय : अस्वीकृति का राय जरूरी है, सहमति खाली छोड़ी जा सकती है।
5. नोड का स्थान : वर्तमान प्रक्रिया का कौन सा नोड है।
6. संबंधित डेटा का स्नैपशॉट : मंजूरी के समय व्यवसाय वस्तुओं के फील्ड के मूल्यों को उसी रूप में सुरक्षित रखा जाता है; व्यवसाय वस्तुओं के बाद में बदलाव करने की अनुमति नहीं होती है, जबकि मंजूरी रिकॉर्ड अपरिवर्तित रहता है।
7. उपकरण और IP ट्रेस : किस उपकरण और किस IP से ऑपरेशन किया गया (अनुपालन ऑडिट के लिए)।

इन सात तत्वों में से एक भी नहीं होने पर, ऑडिट के समय झगड़े होते हैं। आम तौर पर यह समस्या होती है कि "ऑपरेशन का राय खाली छोड़ा जा सकता है", जिसके परिणामस्वरूप अस्वीकृति का कोई कारण नहीं होता है, कर्मचारी बार-बार इसे दोहराते हैं, और मंजूरी प्रवाह लंबा हो जाता है।

03 कैसे विकसित करें: प्रक्रिया इंजन, फॉर्म इंजन और मैसेज बस का संयोजन

OA का विकास करने के लिए मुख्य तीन इंजन हैं, न कि N सेल फ़ाइलें:

प्रक्रिया इंजन

प्रक्रिया इंजन कोड लिखने की जरूरत नहीं है; कॉन्फ़िगरेशन के आधार पर ही प्रक्रिया चलाई जा सकती है। समर्थन करने वाली विशेषताएं:

• सीरियल, पैरालेल, साइन जोड़ना, ऑर साइन जोड़ना : चार प्राथमिक प्रक्रियाएं, जैसे कि नियमित आवेदन के लिए सीरियल (HR → प्रबंधक → CEO), खरीदारी के लिए साइन जोड़ना पैरालेल (वित्तीय विभाग और खरीदारी प्रबंधक एक साथ मंजूरी देते हैं)।
• शर्तों के आधार पर ब्रांचिंग : राशि, श्रेणी और आवेदक के स्तर के आधार पर बांटना, 5,000 युआन से कम के लिए सरल प्रक्रिया, 5,000 से 50,000 युआन तक विभाग और वित्तीय विभाग के दोहरे मंजूरी के लिए, और 50,000 युआन से ऊपर CEO के साथ।
• पीछे लौटाना और अस्वीकार करना: आवेदक को पीछे लौटाना, किसी भी नोड पर पीछे लौटाना, या पिछले नोड पर पीछे लौटाना, इन तीनों प्रकार के अस्वीकार का समर्थन किया जाना चाहिए।
• अतिरिक्त हस्ताक्षर और हस्तांतरण: अनुमोदन करने वाला अपने सहयोगी को कार्य स्थानांतरित कर सकता है (हस्तांतरण), और एक सहयोगी को अनुमोदन में शामिल कर सकता है (अतिरिक्त हस्ताक्षर)।
• वापस लेना और रद्द करना: आवेदक अनुमोदन पूरा न होने वाले मामलों को वापस ले सकता है; प्रशासक असामान्य मामलों को रद्द कर सकता है।

जब प्रक्रिया इंजन तैयार हो जाता है, तो एक नई प्रकार की अनुमोदन प्रक्रिया जोड़ी जाती है जिसके लिए कोड लिखने की आवश्यकता नहीं होती, बस एक आरेख बनाकर और एक फॉर्म तैयार करके इसे ऑनलाइन किया जा सकता है। यह OA का "अनुमोदन आउटसोर्सिंग डेवलपमेंट" से अलग होने का मुख्य कारण है।

फॉर्म इंजन

फॉर्म को "शून्य कोड डिजाइन" के अनुरूप होना चाहिए: फ़ील्ड प्रकार (पाठ, संख्या, तारीख, अनुलग्नक, संबद्ध व्यावसायिक वस्तु), सत्यापन नियम, अनिवार्य या वैकल्पिक, दृश्यता और अदृश्यता की शर्तें, सभी को विज़ुअल ड्रैग-एंड-ड्रॉप तरीके से कॉन्फ़िगर किया जा सकता है। इस तरह HR रिम्बर्समेंट फ़ील्ड को समायोजित कर सकता है, बिक्री विभाग अनुबंध फ़ील्ड जोड़ सकता है, और IT की शेड्यूलिंग की आवश्यकता नहीं होती।

फॉर्म इंजन को निम्नलिखित का समर्थन करना चाहिए:

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

संदेश बस

अनुमोदन स्वीकृत या अस्वीकृत होने पर, आवेदक और संबंधित व्यावसायिक प्रणालियों (HR, वित्त, बिक्री) को तुरंत सूचना मिलती है। संदेश बस एक ही स्थान से भेजती है:

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

संदेश बस "सजावट" नहीं है, बल्कि अनुमोदन प्रवाह का "मुख्य चक्र" है—अगर सूचना नहीं मिलती है, तो आवेदक को नहीं पता होता कि अगले कदम के लिए किससे संपर्क करना है, और पूरी प्रक्रिया रुक जाती है।

समाप्ति: लागू होने का क्रम, जोखिम और संकेतक

OA प्रणाली के लॉन्च को तीन चरणों में विभाजित किया गया है:

1. प्रथम चरण (1 महीना) : छुट्टी, विदेश यात्रा और भुगतान के तीन अत्यधिक आवृत्ति वाले मामलों को लागू करना, सभी को कवर करना। सबसे पहले व्हाट्सएप ग्रुप में चल रहे अनुमोदन को प्रणाली में लाना , भले ही केवल ये तीन मामले ही लाए जाएं, लेकिन विभागों के बीच डेटा तुरंत समान हो जाता है।
2. दूसरा चरण (2-3 महीने) : अनुबंध, मुहर लगाना, खरीद, भुगतान जैसे मध्यम आवृत्ति वाले चार मामलों को लागू करना, वित्तीय प्रणाली से जोड़ना। इस चरण में डेटा बैकफ़्लो को सक्रिय करना है (अनुबंध अनुमोदन के बाद स्वचालित रूप से अनुबंध भंडार में संग्रहीत हो जाना)।
3. तीसरा चरण (आवश्यकता के अनुसार) : प्रदर्शन, पदोन्नति, नियमित करना, भर्ती, निकास जैसे मानव संसाधन के पूरे प्रवाह को लागू करना। इस चरण में HR का नेतृत्व होता है, और HR के मुख्य डेटा को जोड़ना होता है।

आम जोखिम:

• नियम बहुत लचीले हैं : अनुमोदन प्रवाह का निर्धारण बहुत स्वतंत्र है, जिसके परिणामस्वरूप कोई भी नहीं जानता कि अगला कदम किसका है। सिद्धांत: प्रक्रिया टेम्प्लेट 30 से अधिक नहीं होने चाहिए , अधिक होने पर नियंत्रण खो जाता है।
• एजेंट की अनदेखी : अनुमोदन करने वाला व्यक्ति विदेश यात्रा पर है और एजेंट नहीं नियुक्त किया गया है, जिससे प्रक्रिया 3 दिन तक अनुमोदन के बिना रुक जाती है। प्रणाली "प्रक्रिया 24 घंटे से अधिक समय तक रुकी हुई है" का स्वचालित रूप से अलार्म लगाती है।
• डेटा बैकफ़्लो नहीं होना : अनुमोदन हो गया है, लेकिन HR प्रणाली में उपस्थिति अपडेट नहीं हुई है, वित्तीय प्रणाली में प्रमाणपत्र नहीं बना है। बैकफ़्लो के लिए "डबल लिखने और सत्यापन" की आवश्यकता होती है; OA के बाद व्यावसायिक प्रणाली के इंटरफ़ेस को सक्रिय रूप से बुलाकर प्राप्ति की पुष्टि की जाती है।

जांच के लिए आवश्यक संकेतक:

• अनुमोदन का औसत पूरा होने का समय : लॉन्च से पहले ग्रुप में 3 दिन लगते थे, लॉन्च के बाद प्रणाली में 1 दिन के भीतर समाप्त हो जाता है।
• विभागों के बीच डेटा की संगतता : HR, वित्त और बिक्री के तीन अलग-अलग मानदंडों के बीच गड़बड़ी की दर 80% से अधिक गिर गई है।
• ऑडिट की ट्रेसेबिलिटी दर : ऐतिहासिक अनुमोदन के 20 रैंडम नमूने लेकर, सात तत्वों की पूर्णता की दर 100% है।

अनुमोदन को व्हाट्सएप ग्रुप से प्रणाली में लाना, "प्रणाली में लाने" के लिए नहीं है, बल्कि "किससे संपर्क करना है" के विषय को व्यक्ति पर निर्भरता से नियम पर निर्भरता में बदलना है । एक बार नियम लिख दिए जाने के बाद, चाहे कोई भी नौकरी छोड़ दे या संगठन कैसे बदले, अनुमोदन अव्यवस्थित नहीं होगा।