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

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

काम खिसका है; ग़ायब नहीं हुआ

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

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

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

भरोसेमंद पहचान के बिना यह विचार क्यों विफल होता है

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

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

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

Tawassul: यह स्वीकार करना कि ऑटोमेशन हर मामले को नहीं ढकेगा

इस पैकेज का ज़्यादा समझदार आधा हिस्सा Absher Safar नहीं, बल्कि Tawassul है। इसकी आधार-धारणा यह है कि कुछ पासपोर्ट लेन-देन किसी न किसी कारण से इलेक्ट्रॉनिक रूप से अटक जाते हैं, और दफ़्तर जाने को एकमात्र उपाय छोड़ने के बजाय, अटके हुए मामले के पास अब एक तय डिजिटल रास्ता है जहाँ अनुरोध दर्ज होता है और उस पर फ़ॉलो-अप होता है।

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

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

पहले एक ही स्थान

क्रम पर ध्यान दीजिए: सेवा पहले चरण के रूप में किंग फ़हद कॉज़वे पर शुरू हुई, फिर सलवा स्थल सीमा चौकी तक बढ़ाई गई। यह एक ही दिन हर चौकी पर लाइव नहीं हुई।

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

Origami का दृष्टिकोण

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

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

एक व्यावहारिक सीख

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

स्रोत