कागज़ी फ़ॉर्म को मोबाइल ऐप में बदलें: एक व्यावहारिक योजना

ऐप से नहीं, प्रक्रिया से शुरुआत करें

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

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

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

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

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

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

फ़ॉर्म इकट्ठा करें और मौजूदा वर्कफ़्लो मैप करें

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

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

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

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

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

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

लोग वास्तव में क्या करते हैं, उस पर ध्यान दें, न कि केवल आधिकारिक प्रक्रिया पर। यह ईमानदार तस्वीर आपको कागज़ी फ़ॉर्म को मोबाइल ऐप में बदलने की व्यावहारिक शुरुआत देती है।

दोबारा बनाने से पहले हर फ़ील्ड की समीक्षा करें

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

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

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

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

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

ऑडिट के दौरान सरल स्थिति इस्तेमाल करें:

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

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

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

कागज़ी सवालों को मोबाइल इनपुट में बदलें

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

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

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

उत्तर के अनुसार नियंत्रण चुनें:

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

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

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

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

वास्तविक परिस्थितियों में ऑफ़लाइन काम की योजना बनाएँ

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

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

तय करें कि डिवाइस पर क्या सेव रहेगा

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

अस्पष्ट स्थिति संदेशों से बचें। «सिंक होने की प्रतीक्षा में 3 फ़ॉर्म» फ़ील्ड कर्मचारी और सुपरवाइज़र दोनों को स्थिति समझाता है। कर्मचारियों को यह भी पता होना चाहिए कि अपलोड की प्रतीक्षा कर रहे फ़ॉर्म में बदलाव किया जा सकता है या नहीं।

पहली टीम जिन फ़ोन और स्थानों का इस्तेमाल करेगी, उन्हीं पर परीक्षण करें:

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

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

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

डिवाइस की समस्याओं के लिए तैयार रहें

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

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

पहली टीम के साथ पायलट चलाएँ

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

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

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

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

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

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

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

प्रक्रिया नई हो, तभी लोगों को प्रशिक्षण दें

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

सत्र को उन कामों तक सीमित रखें जो लोग वास्तव में करेंगे। नई ऐप पर लंबी प्रस्तुति से ज़्यादा 20 मिनट का प्रदर्शन और उसके बाद अभ्यास उपयोगी होता है।

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

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

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

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

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

वे गलतियाँ जो अतिरिक्त काम पैदा करती हैं

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

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

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

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

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

लॉन्च से पहले यह जाँच करें

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

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

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

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

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

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

उदाहरण: रोज़ाना के निरीक्षण फ़ॉर्म को मोबाइल पर लाना

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

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

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

«लोडिंग क्षेत्र के पास रेलिंग ठीक करें» जैसे अस्पष्ट हस्तलिखित नोट के बजाय निरीक्षक फ़ोटो ले सकता है, सूची से क्षेत्र चुन सकता है और लिख सकता है: «बे 3 पर रेलिंग मुड़ी हुई है और फोर्कलिफ़्ट लेन को रोक रही है।» रिकॉर्ड में समय और रिपोर्ट करने वाले व्यक्ति का नाम भी शामिल होता है।

टीम कमजोर सिग्नल वाले क्षेत्रों में फ़ॉर्म का परीक्षण करती है। निरीक्षक ऑफ़लाइन जाँच पूरी करते और फ़ोटो जोड़ते हैं। डिवाइस दोबारा कनेक्ट होने पर ऐप सेव की गई रिपोर्ट भेज देता है और उन्हें जानकारी फिर से दर्ज नहीं करनी पड़ती।

पायलट का फ़ीडबैक पहला संस्करण बेहतर बनाता है। निरीक्षक बताते हैं कि दस्ताने पहनकर नोट्स फ़ील्ड इस्तेमाल करना कठिन है, इसलिए टीम पहले से तय समस्या श्रेणियाँ जोड़ती है और बड़ा वैकल्पिक टेक्स्ट फ़ील्ड रखती है। वे आम जाँच को फ़ॉर्म के ऊपर भी ले आते हैं। ऐसे छोटे बदलाव टैप कम करते हैं और रोज़ का काम कम परेशान करने वाला बनाते हैं।

पायलट के बाद अगला फ़ॉर्म चुनें

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

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

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

AppMaster पायलट के बाद आगे बढ़ने वाली टीमों के लिए नो-कोड मोबाइल ऐप का तरीका देता है। इसका मोबाइल UI बिल्डर, Data Designer और विज़ुअल Business Process Editor हाथ से प्रोग्रामिंग शुरू किए बिना फ़ॉर्म फ़ील्ड, रूटिंग, अनुमोदन और अलर्ट संभाल सकते हैं। किसी दूसरी टीम को देने से पहले हर वर्कफ़्लो को वास्तविक iOS और Android डिवाइस पर आज़माएँ।

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