Slack अनुरोधों को बिना अराजकता के एक आंतरिक उत्पाद बनाएं

क्यों बार-बार आने वाले Slack अनुरोध समस्या बन जाते हैं

कुछ Slack अनुरोध बड़े नहीं लगते। फिर वही सवाल हर दिन आने लगते हैं: "क्या आप एक्सेस जोड़ सकते हैं?" "क्या आप यह रिपोर्ट ठीक कर सकते हैं?" "क्या आप एक नया वर्कस्पेस बना सकते हैं?" जो मदद छोटी दिखती थी, वह बिना संरचना के एक अनौपचारिक सिस्टम बन जाता है।

पहली समस्या है बिखराव। अनुरोध डायरेक्ट मैसेज, टीम चैनल, प्राइवेट ग्रुप और साइड थ्रेड्स में आते हैं। कुछ में संदर्भ होता है। कुछ में नहीं। लोग याद तो करते हैं कि उन्होंने अनुरोध देखा था, लेकिन यह नहीं कि कहाँ आया था या किसी ने उसे उठाया भी या नहीं। काम तब खो जाता है जब वह किसी स्पष्ट कतार में नहीं आता।

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

urgency इसे और बुरा बनाती है। सबसे तेज़ आवाज़ वाला संदेश आगे आ जाता है, भले ही वह सबसे महत्वपूर्ण न हो। शांत लेकिन महत्वपूर्ण अनुरोध बैकग्राउंड में रह जाते हैं। समय के साथ टीम प्राथमिकता के अनुसार काम करना बंद कर देती है और आख़िरकार जो आख़िरी में जोर से पोस्ट करता है उसी पर प्रतिक्रिया करने लगती है।

फिर स्थिति की बात है। साझा कतार न होने पर सरल सवालों का जवाब देना मुश्किल हो जाता है:

• इस अनुरोध का मालिक कौन है?
• क्या यह प्रतीक्षारत है, प्रगति में है, या पूरा हो गया है?
• क्या यह कहीं और पहले से निपटा हुआ था?
• इस सप्ताह कितने समान अनुरोध आए?

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

उन अनुरोधों को खोजें जो बार-बार आते हैं

शुरू करें उनके अनुरोधों से जो बार-बार दिखाई देते हैं। अनुमान न लगाएँ। पिछले दो से चार हफ्तों के असली संदेशों की समीक्षा करें और देखें लोगों ने वास्तव में क्या माँगा।

एक छोटा समीक्षा विंडो आमतौर पर काफी होता है। यह उन अनुरोधों को दिखाता है जो हर हफ्ते होते हैं बिना पुराने अपवादों को शामिल किए जो अब मायने नहीं रखते।

मैसेज स्कैन करते समय अनुरोधों को प्रकार के अनुसार समूहित करें। आपको परफ़ेक्ट कैटेगरी की ज़रूरत नहीं है। आपको बस यह व्यावहारिक नज़र चाहिए कि क्या दोहराता है: एक्सेस अनुरोध, रिपोर्ट पुल, अनुमोदन जाँच, छोटे डेटा अपडेट, नए वर्कस्पेस सेटअप और इसी तरह के कार्य।

एक साधारण शीट पर्याप्त है। हर अनुरोध के लिए नोट करें:

• क्या माँगा गया था
• उस प्रकार की कितनी बार उपस्थिति हुई
• आमतौर पर कौन पूछता है
• आमतौर पर कौन संभालता है

अंतिम बिंदु कई टीमों की अपेक्षा से अधिक मायने रखता है। अगर वही कुछ लोग बार-बार वही अनुरोध पूरा करते रहे हैं, तो आपके पास पहले से ही एक आंतरिक उत्पाद का रूपरेखा हो सकती है। आप देख सकते हैं ज्ञान कहाँ रहता है, कहाँ देरी होती है, और प्रक्रिया कितनी किसी एक व्यक्ति पर निर्भर है।

पैटर्न जल्दी दिखते हैं। सेल्स बार-बार फ़ाइनेंस से वही प्राइसिंग एक्सेप्शन माँगता है। नए कर्मचारी IT को बार-बार वही ऐप अनुमतियाँ पूछते हैं। मैनेजर ओप्स से हर हफ्ते थोड़ा अलग शब्दों में वही स्टेटस अपडेट मांग सकते हैं।

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

एक छोटा पहला उपयोग मामला चुनें

छोटा शुरू करें जितना कि प्रभावशाली लगे। सबसे अच्छा पहला उपयोग मामला कंपनी की सबसे ज़ोरदार समस्या नहीं है। वह वही है जो अक्सर होता है, कुछ स्पष्ट स्टेप्स का पालन करता है, और एक ऐसा परिणाम देता है जिस पर लोग सहमत हो सकें।

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

एक वाक्य में परिणाम का वर्णन करने की कोशिश करें। अगर वाक्य अस्पष्ट लगे, तो अनुरोध शायद बहुत व्यापक है।

"एक टीम के लिए नया साझा इनबॉक्स मंजूर और बनाया जाए" एक अच्छा प्रारम्भिक लक्ष्य है। "हम ग्राहक संचार सुधारना चाहते हैं" नहीं है। पहला वाला स्पष्ट समाप्ति बताता है। दूसरा दस अलग चीज़ों का अर्थ हो सकता है।

एक अनुरोध प्रकार आमतौर पर छोटा तब होता है जब:

• इसकी एक स्पष्ट शुरू और खत्म हो
• लगभग हर बार वही विवरण चाहिए होते हैं
• अनुमोदन सीमित और अनुमानित हों
• सफलता को एक वाक्य में बताया जा सके

एक बार जब आप उपयोग मामला चुन लें, तो एक मीट्रिक चुनकर देखें। सरल रखें। वेट टाइम एक मजबूत शुरुआती मीट्रिक है क्योंकि हर कोई उसे समझता है। अगर बड़ी समस्या गलतियों की है, तो फिर रिवर्क (फिर से काम) ट्रैक करें—जैसे कि टीम को कितनी बार मिसिंग डिटेल के लिए वापस जाना पड़ा।

यह पहला उपयोग मामला सब कुछ साबित करने की ज़रूरत नहीं रखता। इसे सिर्फ दिखाना है कि एक संरचित intake प्रक्रिया बिखरे हुए Slack संदेशों से बेहतर काम करती है। अगर छोटा वर्शन काम करता है, तो आपके पास असली डेटा, कम रायें, और बाद में ऑटोमेशन के लिए आसान रास्ता होगा।

एक स्पष्ट कतार बनाएं

पहला सुधार सरल है: लोगों को एक सामने का दरवाज़ा दें। उन्हें यह अनुमान नहीं लगाना चाहिए कि DM भेजें, टीम चैनल में पोस्ट करें, या जो फ्री दिख रहा है उसे टैग करें। एक फॉर्म, एक intake चैनल, या एक अनुरोध इनबॉक्स पर्याप्त है। टूल की तुलना में सामंजस्य ज्यादा मायने रखता है।

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

स्थिति लेबल भी मदद करते हैं, पर केवल अगर वे सादे और स्पष्ट हों। अधिकांश टीमों को जटिल सिस्टम की ज़रूरत नहीं है। उन्हें बस यह जानना चाहिए कि क्या हो रहा है:

• नया
• जानकारी चाहिए
• प्रगति में
• अनुमोदन की प्रतीक्षा
• पूरा

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

इतना ही ज़रूरी है कि कतार को ट्रायाज करने के लिए एक व्यक्ति या एक टीम जिम्मेदार ठहराई जाए। इसका मतलब यह नहीं कि वे सारा काम करें। बल्कि इसका मतलब है कि वे पहली प्रतिक्रिया के मालिक हों, देखें कि अनुरोध पूरा है या नहीं, और उसे सही जगह रूट करें। एक स्पष्ट मालिक के बिना, साझा कतार जल्दी ही किसी के द्वारा जिम्मेदार महसूस न किए जाने वाला ढेर बन जाएगा।

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

पहले हाँथ से चलाएँ

ऑटोमेशन से पहले, एक-दो हफ्ते के लिए प्रक्रिया को मैन्युअल तरीके से चलाएँ। इससे पता चलता है कि असली अनुरोध कैसे दिखते हैं, लोग कहाँ फंसते हैं, और कौन से हिस्से वास्तव में सिस्टम बनने लायक हैं।

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

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

हर बार वही रास्ता उपयोग करें:

• अनुरोध पढ़ें और पुष्टि करें कि आवश्यक विवरण मौजूद हैं
• सबमिट में कमी हो तो एक ही जवाब में बाकी जानकारी माँगें, पाँच नहीं
• काम पूरा करें या उसे सही मालिक को भेजें
• उसे पूरा चिह्नित करें और नोट करें कि कितना समय लगा

काम करते हुए, वे कदम लिखें जो आप वास्तव में लेते हैं। सरल रखें। अगर आप हमेशा मैनेजर अनुमोदन जाँचते हैं, किसी टूल से डेटा कॉपी करते हैं, या वही फॉलो-अप प्रश्न पूछते हैं, तो उसे रिकॉर्ड करें। ये दोहराए जाने वाले कार्य बाद में बेहतर वर्कफ़्लो का कच्चा माल होते हैं।

सरल भाषा में रगड़ (friction) भी ट्रैक करें। मिसिंग डिटेल, अनुमोदन देरी, अस्पष्ट मालिकाना, और बार-बार आने वाले प्रश्न नोट करें। एक छोटे बैच के बाद, पैटर्न जल्दी दिखने लगते हैं।

आपके लिए ऑटोमेशन का संकेत यह है कि जब स्टेप्स बदलना बंद कर दें। अगर अधिकांश अनुरोध एक ही रास्ते का पालन करते हैं, तो आपके पास ऐसा कुछ स्थिर है जिस पर आप निर्माण कर सकते हैं। तब तक मैन्युअल काम बर्बाद नहीं होता—यह सीखने का तरीका है कि सिस्टम को वास्तव में क्या चाहिए।

बार-बार किए जाने वाले निर्णयों को सरल नियमों में बदलें

यदि वही अनुरोध बार-बार आता है, तो उसके पीछे का निर्णय सिर्फ एक व्यक्ति के दिमाग में नहीं रहना चाहिए। हर बार आप जो जाँच करते हैं उन्हें उसी क्रम में लिख दें जैसे आप वास्तव में करते हैं। यह आदत को एक प्रक्रिया में बदल देता है जिसे और लोग फ़ॉलो कर सकें।

उन प्रश्नों से शुरू करें जो परिणाम बदलते हैं। क्या अनुरोध पूरा है? क्या व्यक्ति के पास अनुमोदन है? क्या डेडलाइन ऑनबोर्डिंग, पेरोल, या ग्राहक काम से जुड़ी है? अगर ये जाँच अधिकांश अनुरोधों पर होती हैं, तो वे नियमों के सेट में होने चाहिए।

नियमों को व्यवस्थित करने का एक सरल तरीका है उन्हें अलग करना:

• काम शुरू करने से पहले ज़रूरी विवरण
• बढ़िया होने वाले विवरण जो मदद करते हैं पर प्रगति को ब्लॉक नहीं करते
• निर्णय जाँच जैसे अनुमोदन, प्राथमिकता, मालिक, और अंतिम तारीख
• जोखिम संकेत जैसे एक्सेस स्तर, लागत, सुरक्षा, या ग्राहक प्रभाव

यह intake प्रक्रिया को छोटे गैप्स पर फंसने से रोकता है। अगर मैनेजर एक सहायक विवरण भूल गया पर कर्मचारी, टीम और एक्सेस स्तर शामिल है, तो अनुरोध अभी भी आगे बढ़ने के लिए तैयार हो सकता है।

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

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

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

एक वास्तविक उदाहरण: नए कर्मचारी की एक्सेस

नए कर्मचारी की एक्सेस अक्सर सबसे अच्छा पहला आंतरिक उत्पाद होती है। लगभग हर कंपनी इससे निपटती है, कदम दोहराते हैं, और ग़लतियाँ पहले दिन पर स्पष्ट झलकती हैं।

पुराने तरीके का चित्र करें। एक मैनेजर Slack में लिखता है, "Sam सोमवार से शुरू कर रहा है। क्या आप उसे सेट कर देंगे?" फिर तीन अलग टीमें फॉलो-अप प्रश्न पूछती हैं, कोई एक सिस्टम भूल जाता है, और Sam अपना पहला सुबह एक्सेस के इंतजार में बिताता है।

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

यह छोटा बदलाव दो उपयोगी चीज़ें करता है। यह वह बैक-एंड-फोर्थ हटाता है जो सभी को धीमा करता है, और यह क्या मांगा गया और कब इसके बारे में साफ रिकॉर्ड बनाता है।

मानक रोल्स के लिए पथ अच्छा-सा बोरींग होना चाहिए। अगर अनुरोध सेल्स रिप के लिए है, डिजाइनर के लिए है, या सपोर्ट एजेंट के लिए है, तो वही अनुमोदन और एक्सेस पैकेज हर बार उसी स्टेप्स का पालन कर सकते हैं। उदाहरण के लिए:

• सेल्स को CRM, ईमेल, कैलेंडर, और कॉल टूल मिलते हैं
• डिजाइन को डिजाइन सॉफ़्टवेयर, साझा ड्राइव और प्रोजेक्ट टूल मिलते हैं
• सपोर्ट को हेल्पडेस्क एक्सेस, आंतरिक डॉक और टीम चैट चैनल मिलते हैं

यह वही समय है जब प्रक्रिया फ़ेवरेबल तरीके से एक उत्पाद जैसा महसूस करने लगती है बजाय किसी उपकार के। लोग जानते हैं कहाँ अनुरोध सबमिट करना है, कौन सी जानकारी जरूरी है, और सामान्य रास्ता कितना समय लेता है।

हर अनुरोध ऑटोमेटिक नहीं होना चाहिए। टेम्परेरी कॉन्ट्रैक्टर्स, क्रॉस-टीम रोल्स, और संवेदनशील सिस्टम की एक्सेस को अभी भी मानव मालिक के पास रहना चाहिए। अगर अधिकांश अनुरोध एक रास्ता फॉलो करते हैं और केवल अपवाद विशेष हैं, तो आप आगे बढ़ने के लिए तैयार हैं।

वर्कफ़्लो स्थिर होने के बाद ही ऑटोमेशन जोड़ें

ऑटोमेशन तब सबसे ज़्यादा मदद करता है जब काम पहले से ही स्पष्ट पैटर्न का पालन करता हो। अगर टीम अभी भी स्टेप्स बदल रही है, मालिकाना पर बहस कर रही है, या हर अनुरोध को अलग तरह से हैंडल कर रही है, तो ऑटोमेशन केवल उलझन को लॉक कर देगा।

एक अच्छा नियम सरल है: प्रक्रिया को हाँथ से चलाएँ जब तक लोग उसे हर बार एक ही तरह से समझा न सकें। जब फ्लो नीरस, अनुमानित, और सिखाने में आसान लगे, तब यह आम तौर पर ऑटोमेशन के लिए तैयार होता है।

सबसे सुरक्षित हिस्सों से शुरू करें

पहली चीज़ें जो ऑटोमेट करनी चाहिए वो हैं कम-जोखिम वाले काम जो समय बरबाद करते हैं पर निर्णय नहीं मांगते। अनुरोध वर्कफ़्लो में आम तौर पर इसका मतलब है रिमाइंडर, कन्फर्मेशन, और स्थिति अपडेट।

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

अच्छा शुरुआती ऑटोमेशन अक्सर शामिल करता है:

• पुष्टि कि अनुरोध प्राप्त हुआ
• जब ड्यू डेट पास आ रहा हो तो मालिक को रिमाइंडर
• एक साझा जगह में अनुरोध स्थिति अपडेट करना
• जब और विवरण चाहिए हों तो संदेश भेजना

रूटिंग बाद में आए। अगर अनुरोध लोगों के बीच टकराते रहते हैं, या टीम लगातार यह बदलती रहती है कि किसे क्या अनुमोदन देना है, तो ऑटोमैटिक रूटिंग और ज्यादा सफ़ाई का काम बनाएगी। तब तक मैन्युअल पथ स्थिर होने और अधिकांश अनुरोधों के समान हस्तांतरण का पालन करने का इंतजार करें।

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

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

बचने योग्य सामान्य गलतियाँ

अधिकांश टीमें इस वजह से फँसती नहीं कि अनुरोध बहुत जटिल हैं। वे फँसते हैं क्योंकि वे सब कुछ एक साथ ठीक करने की कोशिश करते हैं।

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

एक और गलती है हर जगह से अनुरोध स्वीकार करना। अगर लोग DMs, रैंडम चैनल्स, और ग्रुप चैट्स में पूछ सकें, तो किसी को बाद में विवरण ढूँढना ही होगा।

बहुत जल्दी ऑटोमेशन करना भी एक जाल है। अगर अनुमोदन अभी भी केस-टू-केस निर्णय पर निर्भर हैं, तो ऑटोमेशन केवल बुरे निर्णयों को तेज करेगा। और जब स्थिति दिखाई नहीं देती, लोग फिर से पूछते हैं क्योंकि वे नहीं बता पा रहे कि अनुरोध देखा गया, मंजूर हुआ, या रोका हुआ है।

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

फिक्स सामान्यतः बोरिंग होता है, और यह अच्छा संकेत है। एक अनुरोध प्रकार से शुरू करें। एक intake पाथ उपयोग करें। हर बार वही मुख्य विवरण माँगें। अनुमोदन नियम इतने सरल रखें कि नया टीम सदस्य बिना अनुमान लगाए उनका पालन कर सके।

इतना ही ज़रूरी है प्रगति साफ दिखाना। भले ही बुनियादी स्थिति जैसे प्राप्त, समीक्षित, या पूरा ही क्यों न हो, इससे फॉलो-अप संदेश घटते हैं और भरोसा बनता है।

अगर किसी प्रक्रिया में बार-बार अपवाद चाहिए, तो वह भारी ऑटोमेशन के लिए तैयार नहीं है। पहले नियम साफ करें। फिर उन्हीं हिस्सों को ऑटोमेट करें जो हर बार एक ही तरह काम करते हैं।

स्केल करने से पहले एक त्वरित चेकलिस्ट

अधिक टीमें, अधिक अनुरोध प्रकार, या गहरे ऑटोमेशन जोड़ने से पहले, रुकें और मूल बातों का परीक्षण करें। जो प्रक्रिया उन लोगों के लिए काम करती है जिन्होंने इसे बनाया, वह बाकी सबको भ्रमित कर सकती है।

कुछ सरल चीज़ें चेक करें:

• क्या एक बिल्कुल नया अनुरोधकर्ता बिना पूछे ही अनुरोध सबमिट कर सकता है?
• क्या आवश्यक फील्ड संक्षिप्त, सादे और केवल वही हैं जो वास्तव में देने जरूरी हैं?
• क्या हर स्थिति का एक स्पष्ट मालिक है?
• जब अनुरोध सामान्य पथ में नहीं आए, तो क्या एक सरल बैकअप रास्ता है?
• क्या आप जानते हैं कौन सा चरण मैन्युअल रहना चाहिए क्योंकि वह अभी भी निर्णय माँगता है?

पहला पॉइंट कई टीमों की अपेक्षा से ज़्यादा मायने रखता है। अगर नया कर्मचारी या व्यस्त मैनेजर प्रक्रिया अकेले नहीं समझ पा रहा, तो सिस्टम बढ़ाने के लिए तैयार नहीं है। वर्कफ़्लो ऐसा होना चाहिए कि पहली बार देखने वाले के लिए भी यह स्पष्ट लगे।

इंटेक को संक्षिप्त रखें। लोग उस अनुरोध प्रक्रिया का इस्तेमाल करने की संभावना बहुत ज्यादा रखते हैं जब फ़ॉर्म केवल स्पष्ट, उपयोगी विवरण माँगे न कि पाँच अतिरिक्त सवाल जो शायद कभी मायने नहीं रखते।

मालिकाना वह जगह है जहाँ कई सिस्टम टूटते हैं। "समीक्षा में" का अर्थ तब तक बहुत कम है जब तक एक व्यक्ति या एक टीम उसे आगे बढ़ाने के लिए ज़िम्मेदार न हो। अगर कोई स्थिति किसी की जिम्मेदारी न हो तो अनुरोध वहीं बैठे रह जाते हैं।

अपवादों का भी ध्यान रखें। हमेशा कोई न कोई अजीब मामला, तात्कालिक अनुरोध, या वह व्यक्ति होगा जिसके पास सही संदर्भ नहीं है। उन मामलों के लिए बैकअप पथ दें ताकि वे पूरी Slack बातचीत को फिर से शुरू न कर दें।

और उन स्टेप्स की रक्षा करें जिन्हें अभी भी मानव निर्णय चाहिए। बहुत जल्दी ऑटोमेशन थोपना आम तौर पर फिर से काम बनाता है, गति नहीं।

प्रोसेस को असली उत्पाद में बदलने के अगले कदम

एक बार वर्कफ़्लो हाथ से काम करने लगे, सीधे बड़े सिस्टम पर न कूदें। एक कतार और एक दोहराए जाने वाला अनुरोध रखें, और पहले उस पथ को चिकना बनाएं। यही सबसे सुरक्षित तरीका है बार-बार आने वाले Slack काम को कुछ भरोसेमंद में बदलने का।

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

अगली अच्छी वर्ज़न आम तौर पर केवल कुछ चीज़ें जोड़ती है:

• एक साफ़ अनुरोध फ़ॉर्म
• स्थिति अपडेट जो लोग बिना Slack में पूछे देख सकें
• सामान्य मामलों के लिए बुनियादी अनुमोदन नियम
• जब किसी और टीम को कार्रवाई करनी हो तो सरल हैंडऑफ़
• क्या माँगा गया और कब, इसका रिकॉर्ड

ऑटोमेशन को छोटे-छोटे हिस्सों में जोड़ें। अगर एक्सेस अनुरोध हमेशा पहले मैनेजर अनुमोदन मांगते हैं, तो उस स्टेप को ऑटोमेट करें। अगर कुछ अनुरोध अभी भी निर्णय माँगते हैं, तो उन्हें मैन्युअल छोड़ दें। लक्ष्य सब कुछ ऑटोमेट करना नहीं है—लक्ष्य दोहराए जाने वाले स्टेप्स हटाना और अपवादों को दिखाई रखना है।

अगर वर्कफ़्लो बढ़ता रहता है, तो उसे अपना एक आंतरिक ऐप मिलना चाहिए। Koder.ai जैसे टूल यहाँ मदद कर सकते हैं। टीमें चैट से एक साधारण वेब, सर्वर, या मोबाइल ऐप बना सकती हैं, और जैसे-जैसे नए अनुरोध पैटर्न दिखें, उसे परिष्कृत कर सकती हैं बजाय कि Slack पर और काम जोड़ने के।

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