नीति की पुष्टि वाला ऐप: कर्मचारियों के लिए इसकी संरचना कैसे बनाएं

नीति की पुष्टि को ट्रैक करना मुश्किल क्यों हो जाता है

12 कर्मचारियों वाली कंपनी में नीति का ईमेल काम कर सकता है। HR एक PDF जोड़कर सभी से जवाब मांगता है और प्रतिक्रियाएं मेलबॉक्स में सहेज देता है। नीतियां बदलने, टीम बढ़ने या किसी मैनेजर को यह प्रमाण चाहिए होने पर यह तरीका विफल हो जाता है कि किसी खास कर्मचारी ने किसी खास दस्तावेज़ को स्वीकार किया था।

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

नीति की पुष्टि वाला ऐप तीन बातों को अलग रखता है: नीति का पाठ, उसका संस्करण और हर कर्मचारी की प्रतिक्रिया। जब HR रिमोट वर्क नियम, खर्च की सीमा या सुरक्षा आवश्यकता में बदलाव करता है, तो कंपनी पुराना संस्करण सुरक्षित रख सकती है, नया संस्करण प्रकाशित कर सकती है और दिखा सकती है कि किस कर्मचारी ने कौन-सा संस्करण स्वीकार किया।

रिकॉर्ड को इन व्यावहारिक सवालों का जवाब देना चाहिए:

• नीति किन कर्मचारियों को और कब भेजी गई?
• हर व्यक्ति ने कौन-सा संस्करण स्वीकार किया?
• उन्होंने प्रतिक्रिया कब जमा की?
• समय सीमा किसने पार की?
• क्या अपडेट के बाद नई पुष्टि जरूरी थी?

पढ़ना और पुष्टि करना अलग-अलग काम हैं। रीड रिसीट से पता चलता है कि किसी ने ईमेल देखा, लेकिन इससे यह दर्ज नहीं होता कि उसने «मैंने यह नीति पढ़ और समझ ली है» कहा था। औपचारिक पुष्टि में कर्मचारी की पहचान, नीति का सटीक संस्करण, टाइमस्टैम्प और प्रतिक्रिया दर्ज होनी चाहिए।

इस संरचना के बिना HR ईमेल थ्रेड, स्प्रेडशीट की पंक्तियां और «Code of Conduct final» तथा «Code of Conduct final 2» नाम वाली फ़ाइलों की तुलना करने में घंटों लगा सकता है। रिकॉर्ड पूरा लग सकता है, जब तक कोई छह महीने पुराना प्रमाण न मांग ले।

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

वर्कफ़्लो बनाने से पहले भूमिकाएं तय करें

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

अधिकांश टीमों को पांच भूमिकाओं की जरूरत होती है। छोटी कंपनी में एक व्यक्ति एक से अधिक भूमिका निभा सकता है, लेकिन अनुमतियां अलग रहनी चाहिए।

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

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

कर्मचारियों की प्रतिक्रियाओं तक पहुंच नीति के पाठ से भी अधिक सीमित होनी चाहिए। मैनेजरों को अपनी टीम की पूर्णता स्थिति देखनी पड़ सकती है। HR या अनुपालन टीम को नाम, तारीख, टिप्पणियां और एक्सपोर्ट चाहिए हो सकते हैं। अधिकांश कर्मचारियों को केवल अपनी प्रतिक्रियाएं दिखनी चाहिए।

उदाहरण के लिए, रिमोट वर्क नीति का मालिक होम ऑफिस उपकरण भत्ते को अपडेट करता है। HR भाषा की समीक्षा करता है, People Operations मैनेजर संस्करण 3 प्रकाशित करता है और कर्मचारी इसे पढ़ने की पुष्टि करते हैं। ऑडिट होने पर एडमिन पूर्णता रिकॉर्ड एक्सपोर्ट कर सकता है।

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

नीति और संस्करण का स्पष्ट रिकॉर्ड बनाएं

हर नीति का एक भरोसेमंद रिकॉर्ड होना चाहिए। «Handbook_final_v3» जैसे फ़ाइल नामों से बचें। जब किसी कर्मचारी, मैनेजर या ऑडिटर को यह पता करना हो कि किसी तारीख को कौन-सा दस्तावेज़ लागू था, तो ऐसे नाम भ्रम पैदा करते हैं।

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

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

ड्राफ्ट को प्रकाशित नीतियों से अलग रखें

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

मालिक जब अपडेट प्रकाशित करे, तो नया संस्करण रिकॉर्ड बनाएं और पुराना रिकॉर्ड सुरक्षित रखें। पिछला संस्करण रिटायर किया जा सकता है, लेकिन वह इतिहास का हिस्सा बना रहे। इससे कंपनी दिखा सकती है कि कर्मचारी ने पुष्टि करते समय वास्तव में क्या पढ़ा था।

हर नए संस्करण के लिए बदलाव का छोटा नोट जोड़ें। उदाहरण के लिए: «संस्करण 2.0 में रिमोट वर्क की स्वीकृति प्रक्रिया बदली गई है। घर के राज्य से बाहर काम करने से पहले कर्मचारियों को स्वीकृति लेनी होगी।» इससे कर्मचारी समझते हैं कि उन्हें नया अनुरोध क्यों मिला और मैनेजर तय कर सकते हैं कि किसे इसे पूरा करना है।

हर पुष्टि को केवल नीति के शीर्षक से नहीं, बल्कि एक नीति संस्करण से जोड़ें। नीति कई बार बदलने पर यही जानकारी इतिहास को स्पष्ट रखती है।

सरल स्वीकृति और प्रकाशन प्रक्रिया अपनाएं

नीति का मालिक शीर्षक, सरल भाषा वाला पाठ, संस्करण संख्या और प्रस्तावित लागू होने की तारीख के साथ ड्राफ्ट बनाता है। समीक्षा के दौरान वह इसमें बदलाव कर सकता है।

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

निश्चित संस्करण प्रकाशित करें

स्वीकृति के बाद नीति को तय कर्मचारी समूह के लिए प्रकाशित करें। लागू होने की तारीख सोच-समझकर चुनें। आने वाली यात्राओं से पहले कर्मचारियों को नई यात्रा नीति पढ़ने का समय चाहिए, जबकि जरूरी सुरक्षा अपडेट उसी दिन लागू करना पड़ सकता है।

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

प्रकाशित रिकॉर्ड में नीति का शीर्षक और संस्करण, मालिक, स्वीकर्ता, प्रकाशन और लागू होने की तारीखें, असाइन किया गया कर्मचारी समूह तथा निश्चित नीति पाठ या संलग्न दस्तावेज़ शामिल होना चाहिए।

नीतियों को मिटाए बिना रिटायर करें

नया संस्करण पुराने का स्थान ले तो पुराने को रिटायर मार्क करें। उसे वर्तमान असाइनमेंट स्क्रीन से हटाएं, लेकिन दस्तावेज़, स्वीकृतियां, लागू होने की तारीखें और पूरी की गई पुष्टियां सुरक्षित रखें।

अगर HR रिमोट वर्क नीति 2.0 की जगह संस्करण 2.1 लाता है, तो 2.1 को असाइन किए गए कर्मचारियों को नए पाठ की पुष्टि करनी होगी। टीम को फिर भी 2.0 खोलकर यह देख पाने में सक्षम होना चाहिए कि किसने और कब उसे स्वीकार किया था। पुराना रिकॉर्ड मिटाने से बाद की अनुपालन जांच अनावश्यक रूप से कठिन हो जाती है।

कर्मचारियों के लिए पुष्टि आसान बनाएं

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

कार्रवाई सीधी रखें। दस्तावेज़ पढ़ने के बाद कर्मचारी «मैं पुष्टि करता/करती हूं कि मैंने यह नीति पढ़ और समझ ली है» जैसा कथन चुन सके। जब तक पुष्टि का उद्देश्य वास्तव में हर विवरण से सहमत होना न हो, ऐसी भाषा न लिखें।

ऐप को कंपनी के पास पहले से मौजूद जानकारी का उपयोग करना चाहिए। वह कर्मचारी का नाम उसके खाते से जोड़कर तारीख, समय, नीति संस्करण और स्टेटस सहेज सकता है। «पुष्टि की गई», «लंबित» और «देर से» जैसे सरल स्टेटस मैनेजरों को उपयोगी दृश्य देते हैं।

सबमिट करने से पहले पुष्टि स्क्रीन गलतियों को रोक सकती है। इसमें यह दिखाया जा सकता है:

• Remote Work Policy, संस्करण 3.0
• लागू होने की तारीख: 1 जून 2025
• प्रतिक्रिया की अंतिम तारीख: 15 जून 2025
• स्टेटस: सुबह 10:42 बजे पुष्टि की गई

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

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

AppMaster में यह प्रक्रिया नीति रिकॉर्ड, कर्मचारी खाते की जानकारी, पुष्टि फ़ॉर्म और ऐसे बिज़नेस नियमों से बनाई जा सकती है जो हर प्रतिक्रिया को सही नीति संस्करण के साथ सहेजें।

नीतियां सही कर्मचारियों तक भेजें

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

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

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

समूहों का उपयोग करें और अपवाद की अनुमति दें

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

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

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

डिलीवरी और पुष्टि को अलग-अलग ट्रैक करें

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

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

AppMaster में निर्देशिका, नीति और असाइनमेंट रिकॉर्ड जुड़े हुए डेटा मॉडल में रखे जा सकते हैं। विज़ुअल बिज़नेस प्रोसेस HR द्वारा संस्करण प्रकाशित करने या कर्मचारी की टीम बदलने पर असाइनमेंट बना सकता है।

सभी को परेशान किए बिना जवाब न देने वालों को रिमाइंड करें

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

कुछ भी भेजने से पहले हर व्यक्ति का स्टेटस जांचें। वर्तमान संस्करण स्वीकार कर चुके कर्मचारियों को फॉलो-अप नहीं मिलना चाहिए और पुष्टि जमा होते ही सभी लंबित रिमाइंडर रुक जाने चाहिए।

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

संतुलित एस्केलेशन प्रक्रिया तय करें

अंतिम तारीख के बाद लंबित कार्य कर्मचारी को भेजें और फॉलो-अप के जिम्मेदार व्यक्ति को सूचित करें। कई कंपनियों में यह कर्मचारी का मैनेजर या HR संपर्क होता है। उन्हें नीति, अंतिम तारीख और वर्तमान स्टेटस का सरल दृश्य दें।

छोटा कार्यक्रम अक्सर प्रभावी होता है:

• अंतिम तारीख से 5 से 7 दिन पहले पहला रिमाइंडर भेजें।
• अंतिम तारीख वाले दिन एक अंतिम रिमाइंडर भेजें।
• अंतिम तारीख के बाद मैनेजर या HR संपर्क को सूचित करें।
• काम लंबित रहने पर ही एक और फॉलो-अप भेजें।

हर नीति के लिए एक ही कार्यक्रम न अपनाएं। जरूरी सुरक्षा नियम में मामूली हैंडबुक अपडेट की तुलना में तेज़ एस्केलेशन चाहिए हो सकता है। रिमाइंडर का समय और एस्केलेशन संपर्क हर नीति रिकॉर्ड पर तय करें।

AppMaster में विज़ुअल बिज़नेस प्रोसेस प्राप्तकर्ताओं को पुष्टि स्टेटस से फ़िल्टर कर सकता है, संदेश शेड्यूल कर सकता है और जवाब मिलने पर कार्य अपडेट कर सकता है।

ऑडिट इतिहास को पढ़ने योग्य रखें

ऑडिट व्यू को दर्जनों कर्मचारी रिकॉर्ड खोले बिना चार सवालों का जवाब देना चाहिए: नीति किसे मिली, किसने पुष्टि की, किसे अभी कार्रवाई करनी है और किसने अंतिम तारीख पार की। हर नीति संस्करण के ऊपर असाइन किए गए, पुष्टि किए गए, लंबित और देर से हुए कुल रिकॉर्ड दिखाएं।

कुल संख्या मूल असाइनमेंट सूची पर आधारित रखें। अगर संस्करण 3.0 80 लोगों को मिला था, तो बाद में पांच लोग दूसरी टीम में चले जाएं तब भी 80 असाइन किए गए दिखाएं। इससे प्रकाशन की तारीख का सटीक रिकॉर्ड बना रहता है।

रिकॉर्ड आसानी से खोजने योग्य बनाएं

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

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

संशोधन प्रकाशित करते समय पुरानी पुष्टि को कभी ओवरराइट न करें। संस्करण 2.0 नया असाइनमेंट और अंतिम तारीख बनाता है। संस्करण 1.0 अपने मूल पाठ, प्राप्तकर्ताओं और पुष्टियों के साथ इतिहास में बना रहता है। कर्मचारी दोनों संस्करण स्वीकार कर सकता है और यह सामान्य है।

संदर्भ सहित रिकॉर्ड एक्सपोर्ट करें

आंतरिक समीक्षा के लिए केवल नामों की सूची नहीं, बल्कि तारीख वाला रिपोर्ट एक्सपोर्ट करें। इसमें नीति शीर्षक, संस्करण, प्रकाशन तारीख, अंतिम तारीख, कर्मचारी विवरण, स्टेटस, पुष्टि का टाइमस्टैम्प और रिपोर्ट बनने की तारीख शामिल करें।

AppMaster में बने ऐप में नीति रिकॉर्ड, असाइनमेंट, रिमाइंडर और पुष्टियां जुड़े हुए डेटा टेबल में रखी जा सकती हैं। एडमिन किसी एक कर्मचारी का इतिहास देख सकते हैं या स्प्रेडशीट को हाथ से मिलाए बिना किसी नीति संस्करण का पूरा रिकॉर्ड एक्सपोर्ट कर सकते हैं।

उदाहरण: रिमोट वर्क नीति अपडेट करना

HR होम ऑफिस उपकरण के खर्च की शर्तें बदलता है। मौजूदा रिमोट वर्क नीति में पहले से 146 पुष्टियां हैं, इसलिए उसे सीधे संपादित करने से रिकॉर्ड अस्पष्ट हो जाएगा। अपनी लागू होने की तारीख, स्वीकृति स्थिति और प्रकाशन तारीख के साथ संस्करण 2 बनाएं।

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

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

संस्करण 1 अपने मूल प्राप्तकर्ताओं और पुष्टियों के साथ सुरक्षित रहेगा। संस्करण 2 नया चक्र शुरू करेगा। संस्करण 1 स्वीकार कर चुके कर्मचारी को भी संस्करण 2 की पुष्टि करनी होगी क्योंकि खर्च की शर्तें बदल गई हैं।

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

वे गलतियां जो रिकॉर्ड को कमजोर करती हैं

प्रकाशित नीति के पीछे वाली फ़ाइल को बदलें नहीं। खर्च की सीमा या संपर्क व्यक्ति जैसे छोटे बदलाव के लिए भी नया संस्करण बनाएं। संस्करण 1.2 स्वीकार करने वाले व्यक्ति ने अपने-आप संस्करण 1.3 स्वीकार नहीं किया।

ईमेल खुलना डिलीवरी की उपयोगी जानकारी है, लेकिन पुष्टि नहीं। लोग गलती से संदेश खोल सकते हैं या नीति पढ़े बिना उसका प्रीव्यू देख सकते हैं। कर्मचारियों से «मैं पुष्टि करता/करती हूं» चुनने जैसी स्पष्ट कार्रवाई करवाएं और प्रतिक्रिया का समय नीति संस्करण के साथ सहेजें।

हर रिमाइंडर से पहले वर्तमान स्टेटस जांचें। कर्मचारी के पुष्टि पूरी करते ही उसे रिमाइंडर समूह से हटा दें। अतिरिक्त संदेश कर्मचारियों को परेशान करते हैं और प्रक्रिया को खराब तरीके से संचालित दिखाते हैं।

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

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

छोटे वर्कफ़्लो से शुरुआत करें

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

टीम को जिन जानकारियों को सुरक्षित रखना है, उन्हें दर्ज करें: नीति शीर्षक, संस्करण, प्रकाशन तारीख, लागू होने की तारीख, कर्मचारी असाइनमेंट, अंतिम तारीख, प्रतिक्रिया तारीख और पुष्टि स्टेटस। Draft, Approved, Sent, Acknowledged, Overdue और Archived जैसे सरल स्टेटस इस्तेमाल करें।

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

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

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

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