द डक्ट-टेप POS: जब कामचलाऊ समाधान ही सिस्टम बन जाते हैं

एक डक्ट-टेप POS एक ऐसा पॉइंट-ऑफ-सेल सिस्टम है जो केवल इसलिए काम करता है क्योंकि उस पर बहुत सी चीजें टेप से चिपकाई गई हैं। POS के कामचलाऊ समाधान एक बार के सुधार के रूप में शुरू होते हैं: रजिस्टर जिस इन्वेंट्री को ट्रैक नहीं कर सकता उसे ट्रैक करने वाली स्प्रेडशीट, मंगलवार के स्पेशल को कैसे दर्ज करना है यह समझाने वाला स्टिकी नोट, गिफ्ट कार्ड चलाने वाला दूसरा टैबलेट। अकेले छोड़ दिए जाने पर वे कई गुना बढ़ जाते हैं, और अंततः वे कामचलाऊ समाधान ही सिस्टम बन जाते हैं। POS तो बस वह हिस्सा रह जाता है जो पैसे लेता है।

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

एक डक्ट-टेप POS वास्तव में कैसा दिखता है?

यह शायद ही कभी टूटा हुआ दिखता है। यह आदतों जैसा दिखता है।

• इन्वेंट्री एक स्प्रेडशीट में रहती है क्योंकि POS इस बात को नहीं संभाल सकता कि आप वास्तव में कैसे खरीदते और बेचते हैं (केस द्वारा, वजन द्वारा, बंडल द्वारा)।

• रजिस्टर पर लगा एक स्टिकी नोट समझाता है कि उस आइटम को कैसे दर्ज किया जाए जिसकी अनुमति मेनू सेटअप नहीं देगा। नया स्टाफ नोट को याद रखता है, प्रोडक्ट को नहीं।

• दिन के अंत का मतलब है एक रिपोर्ट एक्सपोर्ट करना, उसे स्प्रेडशीट में ठीक करना, और अकाउंटिंग सॉफ़्टवेयर में टोटल को दोबारा टाइप करना।

• एक प्रोडक्ट को दूसरे के रूप में दर्ज कर दिया जाता है क्योंकि वह काफी मिलता-जुलता होता है, जो चुपचाप उसके बाद आने वाली हर रिपोर्ट को दूषित कर देता है।

• काउंटर पर एक दूसरा टैबलेट रखा होता है जो बुकिंग, लॉयल्टी या गिफ्ट कार्ड के लिए एक अलग ऐप चला रहा होता है।

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

POS के कामचलाऊ समाधान क्यों जमा हो जाते हैं?

क्योंकि सॉफ़्टवेयर कठोर होता है और व्यवसाय नहीं। अधिकांश POS सिस्टम फ़्लो का एक निश्चित सेट शिप करते हैं, और उनके बाहर की कोई भी चीज़ एक फ़ीचर-रिक्वेस्ट कतार में चली जाती है जिसे आप नियंत्रित नहीं करते हैं। वेंडर ने जो बनाया है और आपके काउंटर को जिसकी ज़रूरत है, उसके बीच के अंतर को काउंटर पर खड़ा व्यक्ति भरता है।

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

POS कामचलाऊ समाधानों की वास्तव में क्या कीमत चुकानी पड़ती है?

यहाँ जानबूझकर कोई डॉलर के आंकड़े नहीं दिए गए हैं, क्योंकि वास्तविक लागतें संरचनात्मक हैं।

• ट्रेनिंग: हर कामचलाऊ समाधान एक और अलिखित नियम है जिसे नए कर्मचारियों को सीखना होता है। अपवादों को सिखाने में सिस्टम से ज़्यादा समय लगता है।

• गलतियाँ: मैन्युअल री-एंट्री और लगभग-सही एंट्री ऐसी गलतियाँ पैदा करती हैं जिन्हें सिस्टम पकड़ नहीं पाता, क्योंकि जहाँ तक सिस्टम को पता है, वे कभी हुई ही नहीं थीं।

• रिपोर्टिंग: रिपोर्ट केवल वही बताती हैं जो POS के अंदर होता है। आपका जितना अधिक व्यवसाय इसके बाहर चलता है, आपकी रिपोर्ट का महत्व उतना ही कम हो जाता है।

• मिलान (आपकी बिक्री के रिकॉर्ड को वास्तव में प्राप्त धन से मिलाना): बिक्री और बहीखाता के बीच का हर मैन्युअल कदम अंतर पैदा करता है, और यह अंतर बढ़ता जाता है।

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

आपको कैसे पता चलेगा कि कामचलाऊ समाधान ही सिस्टम बन गए हैं?

यह त्वरित परीक्षण करें:

• नए कर्मचारी POS के बजाय अपवादों को सीखने में अधिक समय बिताते हैं।

• जब स्प्रेडशीट और POS रिपोर्ट असहमत होते हैं, तो आप स्प्रेडशीट पर भरोसा करते हैं।

• आपकी टीम के किसी व्यक्ति ने कभी कहा है "इसे सामान्य तरीके से दर्ज मत करो।"

• आपने फ़ीचर रिक्वेस्ट भेजना बंद कर दिया है क्योंकि कामचलाऊ समाधान पहले से मौजूद है।

• किसी विशिष्ट कर्मचारी द्वारा नौकरी छोड़ने का नोटिस देने की कल्पना करके आपको थोड़ा डर लगता है।

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

आप डक्ट टेप को कैसे हटाते हैं?

खरीदारी से शुरुआत न करें। टेप का ऑडिट करने से शुरुआत करें।

1. हर कामचलाऊ समाधान की सूची बनाएं। काउंटर, बैक ऑफिस और दिन के अंत की दिनचर्या का जायजा लें। कर्मचारियों से पूछें कि वे ऐसा क्या करते हैं जो मैनुअल में नहीं है; वे जानते हैं कि टेप कहाँ है।

2. प्रत्येक को उस आवश्यकता में बदलें जिसे वह छुपाता है। स्प्रेडशीट केवल एक स्प्रेडशीट नहीं है। यह है "POS केस और यूनिट द्वारा इन्वेंट्री को ट्रैक नहीं कर सकता।" स्टिकी नोट है "चेकआउट फ़्लो इस प्रोडक्ट को नहीं संभाल सकता।"

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

यह वह जगह है जहाँ लचीलापन केवल एक ब्रोशर का शब्द नहीं रह जाता। एक लचीला POS वह होता है जहाँ "सिस्टम ऐसा नहीं कर सकता" का उत्तर टेप के अलावा कुछ और हो, और कस्टम चेकआउट फ़्लो अब टेबल स्टेक्स बन गए हैं न कि कोई एंटरप्राइज़ लक्ज़री। प्रॉम्प्ट-आधारित बिल्डरों ने बदल दिया है कि क्या वास्तविक है: Final पर, आप उस फ़्लो का वर्णन करते हैं जिसकी आपको आवश्यकता है और Build उसे सिस्टम में ही जोड़ देता है, बजाय इसके कि कामचलाऊ समाधान स्प्रेडशीट में सिस्टम के बाहर रहे। AI कोड टूल्स भी कुछ ऐसा ही वादा करते हैं, लेकिन एक चेकआउट स्क्रीन जनरेट करने और उसे चलाने के बीच एक वास्तविक अंतर है, जिसे UI के बाद क्या कमी रह जाती है में कवर किया गया है।

तो, क्या डक्ट-टेप POS वास्तव में एक समस्या है?

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

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