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

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

समस्या कभी एक साथ क्यों नहीं आती

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

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

पाँच संकेत

पाँच संकेत बताते हैं कि फ़ाइल अपनी सीमा पार कर चुकी है। ये सभी बराबर गंभीर नहीं हैं, लेकिन इनमें से कोई भी तीन एक साथ काफ़ी हैं:

  • लगभग एक जैसे नामों से कॉपियाँ बढ़ती जाती हैं। फ़ाइनल, फिर फ़ाइनल-संशोधित, फिर फ़ाइनल-2-स्वीकृत, फिर उस व्यक्ति के नाम वाली कॉपी जिसने उसे ईमेल किया था। एक फ़ाइल फ़ाइलों का परिवार बन गई है, और अब हर निर्णय एक अनुमान पर टिका है: क्या यह नवीनतम संस्करण है, या किसी ने समानांतर में कोई दूसरा संस्करण बदल दिया?
  • इसे अपडेट करना केवल एक व्यक्ति जानता है। इसमें उसके दो साल पहले लिखे फ़ॉर्मूले हैं, उसकी मशीन पर मौजूद दूसरी फ़ाइलों के लिंक हैं, और छिपे हुए कॉलम हैं जो ऐसी वजह से मौजूद हैं जिसे केवल वही जानता है। वह कुछ छिपा नहीं रहा, लेकिन ज्ञान उसके दिमाग़ में रहता है, किसी ऐसी जगह नहीं जहाँ कोई भी देख सके। यह ठीक-ठीक विफलता का एकल बिंदु है, अपने तकनीकी नहीं बल्कि संगठनात्मक रूप में।
  • आँकड़ा इस पर निर्भर करता है कि आप किससे पूछते हैं। सेल्स से महीने की आमदनी पूछिए तो एक आँकड़ा मिलता है; फ़ाइनेंस से पूछिए तो दूसरा। दोनों ईमानदार हैं और दोनों के पास अपनी बात के समर्थन में एक फ़ाइल है। अंतर ईमानदारी का नहीं है — बात यह है कि हर विभाग अलग स्रोत से डेटा लेता है और अलग नियम से गणना करता है, और कोई एकल संदर्भ नहीं है जो इसे सुलझा दे।
  • कोई नहीं जानता कि किसने क्या और कब बदला। आपको पता चलता है कि कोई सेल बदल गया है, या कोई पंक्ति हटा दी गई है, या सूची में कोई कीमत अब पहले जैसी नहीं रही। कोई लॉग नहीं है जो बताए कि यह किसने, कब या क्यों किया, इसलिए कोशिश या तो बिना सबूत के दोषारोपण में ख़त्म होती है या चुपचाप हाथ से आँकड़ा ठीक करने में। ज़्यादा ख़तरनाक संभावना यह है कि बदलाव पर कभी किसी का ध्यान ही न जाए।
  • फ़ाइल का मालिक यात्रा पर जाए तो काम रुक जाता है। छुट्टी, यात्रा या बीमारी, और इनवॉइस, रिपोर्ट या ऑर्डर सूची में देरी हो जाती है क्योंकि फ़ाइल उसकी मशीन पर है या तरीका उसके दिमाग़ में है। जब किसी प्रक्रिया की निरंतरता एक व्यक्ति की मौजूदगी पर निर्भर हो, तो आप एक संगठनात्मक समस्या देख रहे हैं, व्यक्तिगत नहीं।

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

इन संकेतों की असली कीमत

यह लागत आय विवरण में कभी अलग पंक्ति के रूप में नहीं दिखती, इसलिए यह मुफ़्त लगती है। इसका भुगतान तीन जगहों पर होता है:

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

सिस्टम पर जाने से असल में क्या बदलता है

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

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

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

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

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

पाँच मिनट का अभ्यास जो आप आज कर सकते हैं

अपनी स्थिति जानने के लिए आपको न किसी टूल की ज़रूरत है न किसी सलाहकार की। वह आख़िरी फ़ाइल खोलिए जिसके आधार पर आपने कोई निर्णय लिया था, और चार सवाल पूछिए:

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

इस अभ्यास के बाद कुछ भी ठीक करने की कोशिश न करें। अपने जवाब लिख लें और संभालकर रखें, क्योंकि अगला भाग सीधे इन्हीं पर आधारित है।

आगे के भागों में

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

स्रोत