एक अच्छा इन्वेंट्री लॉग क्या दर्ज करता है (और ज़्यादातर क्या छोड़ देते हैं)

हर इन्वेंट्री सिस्टम आपको एक संख्या दिखाता है। कम ही सिस्टम दिखाते हैं कि वह संख्या वहाँ तक पहुँची कैसे। वह दूसरा हिस्सा, यानी लॉग, वही है जिसकी ओर आप उसी पल हाथ बढ़ाते हैं जब संख्या ग़लत लगती है, और वह उतना ही काम का है जितना उसने लिखने की ज़हमत उठाई। जिस लॉग में बस “स्टॉक बदला” लिखा हो, न नाम, न वजह, न पहले-बाद का मान, वह लॉग न होने से मुश्किल से ही बेहतर है।

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

छह चीज़ें जो हर पंक्ति में होनी चाहिए

लॉग की हर पंक्ति को एक छोटी-सी घटना रिपोर्ट समझें। इनमें से कोई भी चीज़ ग़ायब हो, तो कोई न कोई सवाल अनुत्तरित रह जाता है।

1. कौन-सा आइटम। ज़ाहिर है, पर इसे नाम बदलने और डिलीट होने के बाद भी टिके रहना चाहिए। “आइटम 214” की ओर इशारा करने वाली पंक्ति आइटम 214 के हटते ही बेकार हो जाती है।
2. क्या बदला। कौन-सा हिस्सा (शेल्फ़ पर, ऑर्डर पर, डिलीवरी के लिए बाहर, क्षतिग्रस्त) या आइटम का कौन-सा विवरण।
3. कितना, या किससे किसमें। आवाजाही के लिए मात्रा उसकी इकाई के साथ चाहिए (“−2.5 kg”, न कि “−2.5”)। संपादन के लिए पुराना मान और नया मान चाहिए।
4. किसने। नाम वाला व्यक्ति, न कि “एडमिन” या किसी साझा टैबलेट का लॉगिन। अगर हर कोई “गोदाम” के नाम से साइन इन करता है, तो लॉग कभी इतना ही कह पाएगा कि गोदाम ने किया।
5. कब। सटीक टाइमस्टैम्प, जो सिस्टम ने दर्ज किया हो, न कि शिफ़्ट के आख़िर में किसी व्यक्ति ने टाइप किया हो।
6. क्यों, और किस रास्ते से। एक वैकल्पिक कारण (“रास्ते में ख़राब हुआ”, “साइकिल काउंट”) और रास्ता: हाथ से, स्कैन के बाद, प्राप्त ऑर्डर से, असेंबली बनाने से, या किसी AI असिस्टेंट द्वारा।

ज़्यादातर सिस्टम स्टॉक की आवाजाही के लिए पहली पाँच चीज़ें दर्ज कर लेते हैं। छठी वह जगह है जहाँ लॉग चुपचाप चूक जाते हैं: बिना कारण का −12 एक जैसा दिखता है चाहे वह बिक्री हो, गिरकर बर्बाद हुआ माल हो या चोरी, और ठीक यही फ़र्क़ आपको जानना था।

पहली चीज़ जो ज़्यादातर लॉग छोड़ देते हैं: संपादन

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

• थ्रेशोल्ड बदल दिया गया। कोई एक परेशान करने वाला अलर्ट बंद करने के लिए चेतावनी स्तर 18 से घटाकर 2 कर देता है। तीन हफ़्ते बाद स्टॉक ख़त्म हो जाता है और किसी को चेतावनी नहीं मिलती। संपादन लॉग के बिना, अलर्ट बस “काम करना बंद कर गया”।
• इकाई का लेबल बदल दिया गया। “डिब्बा” बन जाता है “पेटी”, और उसके बाद की हर गिनती का मतलब बारह गुना बड़ी मात्रा हो जाता है। यह कब हुआ, यह पकड़ पाना ही पाँच मिनट के सुधार और दोबारा गिनती के बीच का फ़र्क़ है।
• लागत बदल गई। आपका स्टॉक मूल्यांकन रातोंरात उछल जाता है। क्या यह असली था, या किसी ने यूनिट लागत में एक शून्य ज़्यादा टाइप कर दिया?
• सप्लायर बदल दिया गया। रीऑर्डर ग़लत विक्रेता के पास जाने लगते हैं और किसी को याद नहीं कि इसे बदला किसने।

संपादन की पंक्ति को भी आवाजाही की तरह कौन और कब चाहिए, साथ में पहले और बाद के मान। “चेतावनी स्तर: 18 → 2, समीर द्वारा, मंगलवार 8:57” एक ही पंक्ति में रहस्य ख़त्म कर देता है।

दूसरी चीज़: डिलीट

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

एक अच्छा लॉग डिलीट को भी एक और घटना मानता है: एक पंक्ति जिसमें व्यक्ति और आइटम का नाम हो, और आइटम का अतीत जस का तस बना रहे। इससे भी बेहतर, डिलीट को पलटा जा सके, क्योंकि चीज़ें डिलीट होने की सबसे आम वजह “अरे, ग़लती से” ही होती है।

नियम जो लॉग को भरोसेमंद रखते हैं

पंक्तियाँ कभी संपादित नहीं होतीं, सिर्फ़ जोड़ी जाती हैं

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

पंक्ति सिस्टम लिखता है, व्यक्ति नहीं

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

हर रास्ता उसी एक लॉग में लिखता है

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

नियम जो लॉग को पढ़ने लायक़ रखते हैं

जिस लॉग को पढ़ा न जा सके, उसे कोई नहीं पढ़ता। दो आदतें बहुत मदद करती हैं:

• शोर को समेटें, मतलब को कभी नहीं। अगर कोई एक मिनट में पाँच बार +1 दबाता है, तो एक +5 पंक्ति वही कहानी कम स्क्रॉल में बता देती है। पर कारण वाले बदलाव या संपादन को हर बार अपनी अलग पंक्ति मिलनी चाहिए।
• मिले-जुले कामों को शब्दों में बताएँ। आटे की पंक्ति पर “2 × सावरडो ब्रेड बनाने में इस्तेमाल” उस कटौती को समझा देता है जो वरना सिकुड़न जैसी दिखती।

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

अपने मौजूदा सेटअप की एक त्वरित जाँच

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

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

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

---

सीमित समय के लिए मुफ़्त आज़माएँ