प्रक्रिया दस्तावेज़ीकरण टेम्पलेट: प्रक्रिया को ऐसे दस्तावेज़ करें कि उसका पालन हो (2026)

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

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

प्रक्रिया दस्तावेज़ क्या है, और क्या नहीं

प्रक्रिया के स्तर पर तीन दस्तावेज़ बताते हैं कि काम कैसे होता है। इन्हें अक्सर आपस में और इनके नीचे की प्रक्रियाओं (procedures) से मिला दिया जाता है:

मैप तस्वीर है; प्रक्रिया दस्तावेज़ वह पाठ है जो तस्वीर को उपयोगी बनाता है; SOP हर बॉक्स के नीचे का ब्योरा हैं। यही फ़र्क लंबाई तय करता है: जो प्रक्रिया दस्तावेज़ बताए कि हर क़दम पर कहाँ क्लिक करना है, वह ऐसा मैनुअल है जिसे कोई नहीं पढ़ता, और पाठ के बिना प्रोसेस मैप ऐसी तस्वीर है जिसे हर कोई अलग ढंग से समझता है। SOP, उसका टेम्पलेट और उसकी समीक्षा का चक्र SOP टेम्पलेट और SOP कैसे लिखें में हैं; यह गाइड उनसे ऊपर के स्तर की है, जो बताता है कि SOP कहाँ चाहिए और कौन किसे क्या सौंपता है।

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

क्या शामिल करें: मानक प्रारूप

उपयोगी प्रक्रिया दस्तावेज़ में एक हेडर और आठ खंड होते हैं। ऑनलाइन ज़्यादातर टेम्पलेट उद्देश्य, चरण और एक डायग्राम देकर रुक जाते हैं, इसीलिए ज़्यादातर प्रक्रिया दस्तावेज़ एक बार पढ़े जाते हैं, दोबारा नहीं:

हेडर: दस्तावेज़ की पहचान, एक पंक्ति में पाँच फ़ील्ड: एक ID जिसका लोग हवाला दे सकें ("PR-HR-02"), एक संस्करण ("v1.3"), मालिक, यानी पूरी प्रक्रिया के लिए जवाबदेह एक नामित व्यक्ति, कोई विभाग नहीं, प्रभावी तिथि और अगली समीक्षा की तिथि। जिस प्रक्रिया की समीक्षा-तिथि नहीं होती, उसकी समीक्षा तब होती है जब कुछ गड़बड़ हो जाए।

1. उद्देश्य और परिणाम। एक या दो वाक्य: यह प्रक्रिया क्या देती है, किसे, और अच्छा परिणाम कैसा दिखता है, संख्या के साथ, अगर आपके पास हो। "नए कर्मचारी के पास पहले दिन अकाउंट, उपकरण, योजना और एक नामित बडी हों, और 30वें दिन तक 30-दिन की समीक्षा हो चुकी हो।"
2. ट्रिगर और अंतिम स्थिति। वह घटना जो प्रक्रिया शुरू करती है और वह परिणाम जो उसे समाप्त करता है। "तब शुरू होती है जब हस्ताक्षरित अनुबंध HR फ़ोल्डर में आता है; तब समाप्त होती है जब 30-दिन की समीक्षा दर्ज हो जाती है।" इन दोनों वाक्यों के बीच जो है वही प्रक्रिया है; इनके बाहर जो है वह किसी और दस्तावेज़ का विषय है। अगर प्रक्रिया का कोई साफ़ अंत नहीं है, तो वह दो प्रक्रियाएँ हैं।
3. दायरा। यह प्रक्रिया कब लागू होती है और कब नहीं, पड़ोसी प्रक्रियाओं को ID से नाम देते हुए। "हमारे साथ अनुबंध पर कर्मचारी, किसी भी देश में। नहीं: ठेकेदार (PR-HR-04); नहीं: आंतरिक स्थानांतरण (PR-HR-06)।"
4. भूमिकाएँ। चरणों में आने वाली हर भूमिका, इस बात के साथ कि वह किसकी मालिक है। भूमिकाएँ, नाम नहीं, ताकि नई नियुक्ति के बाद भी दस्तावेज़ टिका रहे। इनमें से एक प्रक्रिया स्वामी है, जो पूरे प्रवाह के लिए जवाबदेह है, उन हैंड-ऑफ़ सहित जिनका डिफ़ॉल्ट रूप से कोई मालिक नहीं होता।
5. चरण और हैंड-ऑफ़। दस्तावेज़ का केंद्र: क्रम से चरण, हर एक के साथ वह भूमिका जो उसे करती है, क्या आता है (इनपुट), क्या जाता है और कहाँ दर्ज होता है (आउटपुट), किसके पास जाता है, और समय-सीमा। हैंड-ऑफ़ साफ़ लिखा जाता है, "को: IT, दिन −5 तक", क्योंकि प्रक्रियाएँ हैंड-ऑफ़ पर ही विफल होती हैं: दोनों पक्ष मान लेते हैं कि दूसरे ने संभाल लिया है।
6. अपवाद और एस्केलेशन। सामान्य रास्ते से हटती शाखाएँ: परमिट देर से आए, क्रेडिट जाँच विफल हो, मालिक अनुपस्थित हो तो क्या होता है। हर अपवाद उस भूमिका या व्यक्ति का नाम बताता है जो निर्णय लेता है, "किसी से पूछ लें" कभी नहीं। आख़िरी पंक्ति उसके लिए है जो छूट गया: "जो यहाँ शामिल नहीं है: प्रक्रिया स्वामी निर्णय लेता है, और मामला अगली समीक्षा में उठाया जाता है।"
7. माप। दो-तीन संख्याएँ जिन पर मालिक नज़र रखता है: ट्रिगर से अंतिम स्थिति तक का चक्र-समय, प्रति माह मामले, अपवाद में गए मामलों का हिस्सा। डैशबोर्ड नहीं; वे संख्याएँ जो किसी के शिकायत करने से पहले मालिक को बता दें कि प्रक्रिया भटक रही है।
8. संबंधित दस्तावेज़ और संशोधन इतिहास। हर चरण के नीचे के SOP, वह नीति जिसे प्रक्रिया लागू करती है, मैप का लिंक; फिर हर संस्करण की एक पंक्ति: तिथि, क्या बदला, किसने मंज़ूर किया। यही इतिहास एक ही ग़लती को नए संस्करण संख्या के साथ दोबारा आने से रोकता है।

जो बाहर रहता है: हर नियम का औचित्य (यह नीति का काम है), किसी चरण का क्लिक-दर-क्लिक ब्योरा (यह SOP का काम है), और ऐसा कुछ भी जिस पर कोई व्यक्ति अमल न कर सके। "हम सहज ऑनबोर्डिंग को महत्व देते हैं" एक भावना है, चरण नहीं।

प्रक्रिया को ऐसे दस्तावेज़ करें कि उसका पालन हो

तीन कारण लगभग हर उस प्रक्रिया दस्तावेज़ को समझाते हैं जिसका पालन नहीं होता, और हर एक का समाधान लेखन में है, किसी बाद की सख़्ती में नहीं।

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

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

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

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

प्रक्रिया दस्तावेज़ीकरण टेम्पलेट

[प्रक्रिया ID] — [प्रक्रिया का नाम]
संस्करण: [n.n] · मालिक: [नाम, भूमिका] · प्रभावी: [तिथि] · अगली समीक्षा: [तिथि]

1. उद्देश्य और परिणाम
[एक या दो वाक्य — यह प्रक्रिया क्या देती है, किसे, और अच्छा परिणाम कैसा दिखता है, संख्या के साथ अगर आपके पास हो।]

2. ट्रिगर और अंतिम स्थिति
तब शुरू होती है जब: [घटना] · तब समाप्त होती है जब: [वह परिणाम जो अब मौजूद है]

3. दायरा
शामिल: [मामले, साइट, ग्राहक, देश] · शामिल नहीं: [जिसे कोई दूसरी प्रक्रिया सँभालती है, उसकी ID के साथ]

4. भूमिकाएँ
प्रक्रिया स्वामी: [पूरे प्रवाह के लिए जवाबदेह एक व्यक्ति]
[भूमिका] — [इस प्रक्रिया में वह किसकी मालिक है]
[भूमिका] — [इस प्रक्रिया में वह किसकी मालिक है]

5. चरण और हैंड-ऑफ़
5.1 [चरण] — [भूमिका] — इन: [क्या आता है] — आउट: [क्या जाता है, कहाँ दर्ज होता है] — को: [अगली भूमिका] — तक: [समय-सीमा]
5.2 [चरण] — [भूमिका] — इन: … — आउट: … — को: … — तक: …
5.3 [चरण] — [भूमिका] — इन: … — आउट: … — को: … — तक: …

6. अपवाद और एस्केलेशन
अगर [स्थिति]: [क्या होता है, कौन निर्णय लेता है]
अगर [स्थिति]: [क्या होता है, कौन निर्णय लेता है]
जो यहाँ शामिल नहीं है: [भूमिका] निर्णय लेती है; मामला अगली समीक्षा में उठाया जाता है।

7. माप
[दो-तीन संख्याएँ जिन पर मालिक नज़र रखता है — चक्र-समय, प्रति माह मामले, अपवाद में गए मामलों का हिस्सा — और वे कहाँ पढ़ी जाती हैं।]

8. संबंधित दस्तावेज़ और संशोधन इतिहास
SOP: [ID, जहाँ ज़रूरी हो वहाँ हर चरण के लिए एक] · लागू करती है: [नीति] · मैप: [डायग्राम का लिंक]
v[n.n] — [तिथि] — [क्या बदला] — मंज़ूरी: [नाम]
v[n.n] — [तिथि] — [क्या बदला] — मंज़ूरी: [नाम]

टेम्पलेट बोल्ड लेबल वाला सादा पाठ है, इसलिए वह बिना दोबारा फ़ॉर्मैट किए Word फ़ाइल, Google Doc, विकी पेज, Slack canvas या चैट नोट में पेस्ट हो जाता है। सबसे अक्सर खाली छूटने वाले दो खंड हैं हैंड-ऑफ़, यानी "किसे, कब तक", और समीक्षा-तिथि; इन्हीं दो से तय होता है कि एक साल बाद भी प्रक्रिया वैसे ही चल रही है या नहीं जैसा दस्तावेज़ कहता है।

एक पूरा उदाहरण: नए कर्मचारी की ऑनबोर्डिंग, हस्ताक्षरित अनुबंध से दिन 30 तक

तीन देशों में कर्मचारियों वाली साठ लोगों की एक कंपनी; प्रक्रिया चार भूमिकाओं से गुज़रती है और 30-दिन की समीक्षा दर्ज होने पर समाप्त होती है।

PR-HR-02 — नए कर्मचारी की ऑनबोर्डिंग
संस्करण: 1.3 · मालिक: ऑपरेशंस प्रमुख, Inés M. · प्रभावी: 1 अक्टूबर 2026 · अगली समीक्षा: 1 अप्रैल 2027

1. उद्देश्य और परिणाम — नए कर्मचारी के पास पहले दिन काम करने वाले अकाउंट, उपकरण, पहले महीने की योजना और एक नामित बडी हों, और 30वें दिन तक दर्ज की गई 30-दिन की समीक्षा हो, चाहे वह किसी भी देश में शुरू करे।
2. ट्रिगर और अंतिम स्थिति — तब शुरू होती है जब: हस्ताक्षरित अनुबंध HR फ़ोल्डर में आता है। तब समाप्त होती है जब: 30-दिन की समीक्षा कर्मचारी की फ़ाइल में दर्ज हो जाती है।
3. दायरा — हमारे साथ अनुबंध पर कर्मचारी, किसी भी देश में, ऑफ़िस या रिमोट। नहीं: ठेकेदार (PR-HR-04); आंतरिक स्थानांतरण (PR-HR-06)।
4. भूमिकाएँ — प्रक्रिया स्वामी: ऑपरेशंस प्रमुख। HR: फ़ाइल, दस्तावेज़, पेरोल, वेलकम पैक। IT: अकाउंट, उपकरण, एक्सेस। भर्ती करने वाला मैनेजर: योजना, बडी, चेक-इन। फ़ाइनेंस: पेरोल सेटअप।

5. चरण और हैंड-ऑफ़
5.1 फ़ाइल खोलना — HR — इन: हस्ताक्षरित अनुबंध — आउट: ऑनबोर्डिंग रिकॉर्ड, जिसमें शुरू होने की तिथि, देश, मैनेजर, भाषा हो; कर्मचारी की भाषा में भेजा गया वेलकम पैक — को: IT और भर्ती करने वाला मैनेजर — तक: हस्ताक्षर के दो कार्यदिवस बाद
5.2 अकाउंट और उपकरण — IT — इन: रिकॉर्ड — आउट: बनाए गए अकाउंट, कर्मचारी के पते पर भेजा गया लैपटॉप, भूमिका प्रोफ़ाइल के अनुसार एक्सेस; रिकॉर्ड में पुष्टि — को: HR — तक: शुरू होने की तिथि से पाँच कार्यदिवस पहले
5.3 दस्तावेज़ और पेरोल — HR, फिर फ़ाइनेंस — इन: रिकॉर्ड, कर्मचारी के दस्तावेज़ (परमिट या पंजीकरण, जहाँ देश को ज़रूरत हो) — आउट: पेरोल में कर्मचारी, फ़ाइल में दस्तावेज़ — को: भर्ती करने वाला मैनेजर — तक: शुरू होने की तिथि
5.4 पहला महीना, योजना सहित — भर्ती करने वाला मैनेजर — इन: रिकॉर्ड — आउट: फ़ाइल में 30-दिन की योजना, एक नामित बडी, कर्मचारी के कैलेंडर में पहला सप्ताह, टीम के साथ बुक की गई वेलकम कॉल — को: कर्मचारी, पहले दिन — तक: शुरू होने से एक दिन पहले
5.5 पहला दिन — भर्ती करने वाला मैनेजर और बडी — इन: योजना — आउट: हो चुकी वेलकम कॉल, योजना का वॉकथ्रू, टीम के चैनल में दर्ज किए गए कर्मचारी के खुले सवाल — को: कर्मचारी — तक: पहले दिन का अंत
5.6 चेक-इन — भर्ती करने वाला मैनेजर — इन: योजना, दर्ज किए गए सवाल — आउट: दिन-7 और दिन-30 का चेक-इन, फ़ाइल में दर्ज 30-दिन की समीक्षा — को: HR, रिकॉर्ड बंद करने के लिए — तक: दिन 30

6. अपवाद — शुरू होने की तिथि तक परमिट या पंजीकरण नहीं मिला: कर्मचारी उन कामों से शुरू करता है जिन्हें मैनेजर उसके बिना मान्य ठहराता है; फ़ॉलो-अप HR का है और तिथि रिकॉर्ड में जाती है। लैपटॉप दिन −2 तक नहीं पहुँचा: IT ऑफ़िस के स्टॉक से एक अस्थायी लैपटॉप भेजता है; ऑपरेशंस प्रमुख को उसी दिन बताया जाता है। ऐसे देश में कर्मचारी जहाँ हमने पहले भर्ती नहीं की: चरण 5.3 रुक जाता है; ऑपरेशंस प्रमुख तीन कार्यदिवसों के भीतर employer-of-record का रास्ता तय करता है (PR-HR-05)।
7. माप — हस्ताक्षर से अकाउंट तैयार होने तक के कार्यदिवस (लक्ष्य ≤ 7); उन कर्मचारियों का हिस्सा जिनकी 30-दिन की समीक्षा दिन 30 तक दर्ज हुई (लक्ष्य 100 %); पहले सप्ताह में दर्ज सवाल, जो तिमाही समीक्षा में यह देखने के लिए पढ़े जाते हैं कि कौन-सा चरण बार-बार उन्हें पैदा करता है।
8. संबंधित — SOP-IT-03 "नए अकाउंट और एक्सेस"; SOP-HR-08 "देश के अनुसार पेरोल सेटअप"; ऑनबोर्डिंग नीति §2; मैप: HR फ़ोल्डर में स्विमलेन डायग्राम।
v1.3 — 1 अक्टूबर 2026 — वेलकम पैक अब कर्मचारी की भाषा में भेजा जाता है; दिन-7 का चेक-इन जोड़ा गया — मंज़ूरी: Inés M.
v1.2 — 3 जून 2026 — दो देरी से हुई डिलीवरी के बाद लैपटॉप की शिपिंग शुरू होने से पाँच दिन पहले कर दी गई — मंज़ूरी: Inés M.

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

एक छोटा दूसरा उदाहरण, डिस्ट्रीब्यूटरों वाले एक निर्यातक की बिक्री प्रक्रिया का ढाँचा:

PR-SA-01 — ऑर्डर से डिलीवरी तक · मालिक: एक्सपोर्ट मैनेजर · तब शुरू होती है जब: किसी डिस्ट्रीब्यूटर का ऑर्डर आता है · तब समाप्त होती है जब: डिलीवरी की पुष्टि हो जाती है और इनवॉइस भेज दिया जाता है
1. ऑर्डर जाँच — अकाउंट मालिक — इन: ऑर्डर — आउट: सिस्टम में पुष्ट ऑर्डर, या डिस्ट्रीब्यूटर को वापस भेजा गया सवाल — को: फ़ाइनेंस — तक: एक कार्यदिवस
2. क्रेडिट जाँच — फ़ाइनेंस — इन: पुष्ट ऑर्डर — आउट: रिलीज़, या कारण के साथ रोका गया — को: गोदाम — तक: एक कार्यदिवस
3. पिक और पैक — गोदाम — इन: रिलीज़ किया गया ऑर्डर — आउट: पैकिंग लिस्ट के साथ पैक — को: लॉजिस्टिक्स — तक: तीन कार्यदिवस
4. दस्तावेज़ और शिपिंग — लॉजिस्टिक्स — इन: पैक किया गया ऑर्डर — आउट: बुक की गई शिपमेंट, गंतव्य के दस्तावेज़ संलग्न, सिस्टम में ट्रैकिंग — को: फ़ाइनेंस और अकाउंट मालिक — तक: एक कार्यदिवस
5. इनवॉइस और पुष्टि — फ़ाइनेंस, फिर अकाउंट मालिक — इन: शिपमेंट — आउट: भेजा गया इनवॉइस; डिस्ट्रीब्यूटर के साथ डिलीवरी की पुष्टि और रिकॉर्डिंग — अगर क्रेडिट रोका गया: अकाउंट मालिक एक कार्यदिवस के भीतर डिस्ट्रीब्यूटर को फ़ोन करता है; एक्सपोर्ट मैनेजर रिलीज़ या अग्रिम भुगतान तय करता है।

बारह पंक्तियाँ, और डिस्ट्रीब्यूटर का नया क्लर्क और गोदाम का नया व्यक्ति, दोनों जानते हैं कि वे किसका इंतज़ार कर रहे हैं।

प्रक्रिया दस्तावेज़ और उसका वॉकथ्रू आपके रोज़ के टूल्स में कहाँ रहते हैं

दस्तावेज़ वहीं रहता है जहाँ टीम के दस्तावेज़ रहते हैं: साझा लाइब्रेरी में Word फ़ाइल, Google Doc, विकी का पेज, किसी चैनल में canvas। वॉकथ्रू एक मीटिंग है, और हर प्लेटफ़ॉर्म में वॉकथ्रू के पीछे छूटने वाली चीज़ के लिए एक जगह है; हर एक अलग बिंदु पर रुक जाता है। केवल प्रलेखित व्यवहार, विक्रेताओं के अपने पन्नों से, उस महीने के साथ जब हर पन्ना जाँचा गया:

दो बातें हर जगह एक जैसी हैं। प्रक्रिया दस्तावेज़ उस एक भाषा की फ़ाइल है जिसमें वह लिखा गया, और दूसरी भाषा पढ़ने वाला सहकर्मी वही फ़ाइल पढ़ता है या किसी की बनाई कॉपी; और वॉकथ्रू ने जो बदला वह दस्तावेज़ तक तभी पहुँचता है जब कोई बाद में उसे उसी भाषा में टाइप करे। इन सुइट्स का प्रलेखित अनुवाद कॉल का है, दस्तावेज़ का नहीं: Microsoft Teams मीटिंग में अनुवादित लाइव कैप्शन तब प्रलेखित करता है जब आयोजक के पास Teams Premium या Microsoft 365 Copilot लाइसेंस हो, और Google पात्र Workspace प्लान पर Meet में अनुवादित कैप्शन प्रलेखित करता है (दोनों अगस्त 2026 में जाँचे गए)। हर एक क्या कवर करता है और कहाँ रुकता है, यह Microsoft Teams लाइव अनुवाद और Google Meet लाइव अनुवाद में है। जो प्रक्रिया नया क्लर्क मंगलवार को खोलता है, और जिस वॉकथ्रू ने उसे बदला, वे उन कैप्शन से अलग वस्तुएँ हैं, और वे उसी भाषा में पढ़ी जाती हैं जिसमें टाइप की गईं।

प्रक्रिया, उसका वॉकथ्रू और उसका इतिहास हर सदस्य के लिए कैसे पठनीय रहते हैं

InterMIND रोज़मर्रा के संवाद की वह जगह है जहाँ टीम का काम एक चैनल में रहता है, इसलिए तैयार प्रक्रिया दस्तावेज़ का एक स्पष्ट घर है: उस टीम का चैनल जो प्रक्रिया चलाती है, यानी HR, IT, फ़ाइनेंस और भर्ती करने वाले मैनेजरों का एक चैनल, जिनमें से हर एक किसी चरण का मालिक है। नोट के रूप में पोस्ट किया जाए, यानी शीर्षकों और क्रमांकित सूचियों वाला रिच-टेक्स्ट संदेश, जिसे बाद में उसी के अपने मेनू से एडिट किया जा सकता है, तो हर सदस्य उसे अपनी भाषा में पढ़ता है और मूल एक टॉगल की दूरी पर रहता है, और वह पिन किया जाता है ताकि नए सहकर्मी को सबसे पहले मौजूदा संस्करण मिले; एडिट इतिहास चालू होने पर, बदले गए चरण का पुराना पाठ मौजूदा पाठ के ऊपर शब्द-स्तर के diff के रूप में, टाइमस्टैम्प के साथ, दिखता है। फ़ाइल के रूप में अपलोड किया जाए, यानी PDF या Word दस्तावेज़, तो हर प्लान पर उसके साथ पाठक की भाषा में AI सारांश आता है, जिसका हर बिंदु उस अनुच्छेद से जुड़ा होता है जहाँ से वह आया, इसलिए एक-पन्ने का पाठ किसी के लिखने से पहले ही मौजूद होता है; सशुल्क प्लान पर फ़ाइल ख़ुद पाठक की भाषा में अनूदित खुलती है (दस्तावेज़ों के लिए 30 भाषाएँ)। अगर मास्टर कॉपी किसी दस्तावेज़ टूल में रहती है, तो उसके अपडेट ईमेल से चैनल में पहुँचते हैं: चैनल का होस्ट उसे उसका अपना पता देता है, और वहाँ भेजा गया संदेश सामान्य संदेश के रूप में दिखता है, भेजने वाले के नाम और संलग्नकों के साथ।

वॉकथ्रू उसी चैनल से शुरू होता है। कॉल के दौरान, मौजूदा संस्करण Share to conference से सबकी स्क्रीन पर वीडियो टाइल्स के बगल में आ जाता है, चाहे नोट हो या चैट में जुड़ा Google Docs या OneDrive दस्तावेज़, और हर प्रतिभागी उसे स्वतंत्र रूप से स्क्रॉल करता है और अपनी भाषा में पढ़ता है; साझा किया गया नोट साझा करने वाला लाइव एडिट करता है, जबकि कमरा बदले हुए हैंड-ऑफ़ को आकार लेते देखता है। कॉल ख़त्म होने पर रीकैप मीटिंग से ही लिखा जाता है: एक सारांश, सहमत, खुले या विवादित के रूप में चिह्नित बिंदु, मालिकों के साथ एक्शन आइटम, हर पंक्ति अपना टाइमस्टैम्प रखती है, और सत्र के दौरान साझा किए गए दस्तावेज़ जो कहा गया उसके साथ अपने सारांश जोड़ते हैं। वह ईमेल से, चैनल में एक संदेश के रूप में और कैलेंडर इवेंट में एक लिंक के रूप में आता है, और हर साइन-इन सदस्य उसे अपनी भाषा में पढ़ता है: रिकॉर्ड हर पाठक के लिए अनूदित होता है, उस भाषा में एक बार नहीं लिखा जाता जो कमरे ने संयोग से इस्तेमाल की। कोई भी सदस्य उसे एडिट कर सकता है, हर एडिट लेखक और संशोधन इतिहास रखता है, और चैनल हर पिछले सत्र का रीकैप रखता है, इसलिए जिस वॉकथ्रू से v1.3 बना वह उस नोट से एक क्लिक की दूरी पर है जो v1.3 है। किसी सदस्य का अपना असिस्टेंट, Claude, ChatGPT, Copilot या Gemini, जो MCP कनेक्टर से जुड़ा है, रीकैप, ट्रांसक्रिप्ट, चैट और साझा फ़ाइलों के पाठ में एक ही सवाल से खोजता है, "लैपटॉप शुरू होने से पाँच दिन पहले क्यों भेजा जाता है?", और दस्तावेज़ ख़ुद पढ़ता है; यह उन संगठनों के लिए काम करता है जिनमें AI फ़ीचर चालू हैं। ऊपर की तालिका के बगल में रखें तो फ़र्क एक सादा तथ्य है: जिन कैप्शन का ये सुइट्स प्रलेखन करते हैं वे कॉल चलते समय उसका अनुवाद करते हैं; यहाँ प्रक्रिया, उसका वॉकथ्रू और उसका इतिहास एक ही रिकॉर्ड हैं, जिसे हर सदस्य अपनी भाषा में पढ़ता है।

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

• एक पूरा रीकैप खोलें — एक असली रिकॉर्ड, उसी कोड से तैयार जो आपका लिखता है।
• लाइव डेमो आज़माएँ — साइन-अप नहीं; बोलिए, और कमरे को हर श्रोता के लिए अनूदित सुनिए।

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

अक्सर पूछे जाने वाले प्रश्न

प्रक्रिया दस्तावेज़ीकरण क्या है?

प्रक्रिया दस्तावेज़ीकरण इस बात का लिखित विवरण है कि काम का कोई हिस्सा किसी संगठन में उस घटना से, जो उसे शुरू करती है, उस परिणाम तक, जो उसे समाप्त करता है, कैसे आगे बढ़ता है: क्रम से चरण, हर एक की मालिक भूमिका, एक भूमिका से अगली को क्या जाता है, हर चरण क्या पीछे छोड़ता है, सामान्य रास्ते से हटते अपवाद और उन्हें कौन तय करता है, और वे कुछ संख्याएँ जिन पर मालिक नज़र रखता है। वह प्रोसेस मैप, यानी डायग्राम, और उन SOP के बीच बैठता है जो बताते हैं कि हर चरण क़दम-दर-क़दम कैसे किया जाता है।

प्रक्रिया दस्तावेज़ीकरण में क्या शामिल होना चाहिए?

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

प्रक्रिया को क़दम-दर-क़दम कैसे दस्तावेज़ करें?

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

प्रक्रिया दस्तावेज़ीकरण और SOP में क्या अंतर है?

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

प्रक्रिया दस्तावेज़ीकरण के उदाहरण क्या हैं?

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

क्या Word या Google Docs में प्रक्रिया दस्तावेज़ीकरण टेम्पलेट है?

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

प्रक्रिया दस्तावेज़ीकरण किसे लिखना चाहिए?

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

प्रक्रिया दस्तावेज़ीकरण कितनी बार अपडेट करना चाहिए?

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

स्रोत: Microsoft — Microsoft Teams में मीटिंग नोट्स लें; Microsoft — Microsoft Teams मीटिंग में लाइव कैप्शन का उपयोग करें; Zoom — AI Companion के साथ मीटिंग सारांश का उपयोग; Google — "Take notes for me" के लिए Calendar और Meet सेटिंग; Google Meet — Google Meet में "Take notes for me"; Google Meet — अनुवादित कैप्शन का उपयोग करें; Slack — मीटिंग एजेंडा टेम्पलेट (canvas)। Microsoft, Google और Slack के मीटिंग-नोट्स और टेम्पलेट पन्ने अक्टूबर 2026 में जाँचे गए; Zoom का मीटिंग-सारांश पन्ना और Teams और Meet के कैप्शन पन्ने अगस्त 2026 में जाँचे गए। विक्रेता समय के साथ प्लान, फ़ीचर और भाषा सूचियाँ बदलते रहते हैं; मौजूदा स्थिति के लिए उनके पन्ने देखें।