बिक्री, ऑपरेशंस और फ़ाइनेंस के बारह KPI, हर एक का फ़ॉर्मूला, ज़िम्मेदार और देखने की लय के साथ। एक पूरे महीने का हिसाब, डैशबोर्ड डिज़ाइन के नियम, और आँकड़ा लाल होने पर क्या करें।
Author
Anichur Rahaman
सोमवार, सुबह 8:40। एक ऑनलाइन स्टोर और एक शोरूम वाले छोटे रिटेल कारोबार की मालकिन तीन स्प्रेडशीट और बैंक का app खोलकर बैठी हैं। शोरूम का एक्सपोर्ट कहता है कि सितंबर की बिक्री 52,000 रही। अकाउंटेंट कहते हैं 51,300। courier पोर्टल के हिसाब से कितने parcel देर से पहुँचे, यह अलग ही आँकड़ा है। हफ़्ते का पहला घंटा आँकड़े मिलाने में निकल जाता है, फ़ैसला लेने की बारी आती ही नहीं।
9:45 तक उनके हाथ में एक ऐसा आँकड़ा है जिस पर वे आधा ही भरोसा करती हैं, और यह भी साफ़ नहीं कि बदलना क्या है। यह दृश्य काल्पनिक है, पर तस्वीर जानी-पहचानी है: कारोबार के पास data की कमी नहीं, कमी इस बात की है कि आँकड़ों का मतलब सबके लिए एक ही हो।
इस लेख की बात सीधी है: बारह KPI काफ़ी हैं, बशर्ते हर एक का एक फ़ॉर्मूला, एक ज़िम्मेदार और एक स्रोत हो, और सब एक ही पन्ने पर दिखें। आगे परिभाषाएँ हैं, एक पूरे महीने का हिसाब, dashboard को रोज़ खुलता रखने वाले डिज़ाइन नियम, और यह कि कोई आँकड़ा लाल हो जाए तो क्या करना है।
ज़्यादातर dashboard एक ही तरह से दम तोड़ते हैं। जोश में कोई चालीस चार्ट बना डालता है। महीने भर बाद दो चार्ट अलग-अलग बिक्री दिखाते हैं, क्योंकि एक order मिलने के दिन गिनता है और दूसरा payment के दिन। कौन सही है, कोई नहीं बता पाता, और सब अपनी-अपनी स्प्रेडशीट पर लौट जाते हैं।
कसूर चार्ट बनाने वाले टूल का नहीं है। KPI को कभी कोड या query के रूप में परिभाषित ही नहीं किया गया: क्या गिना जाएगा, किस अवधि का, किस टेबल से, और क्या बाहर रहेगा। परिभाषा जब किसी के दिमाग़ में रहती है, तो हर एक्सपोर्ट थोड़ा अलग आँकड़ा देता है।
इलाज सादा है और असरदार भी। हर KPI एक नाम वाली query से निकलता है, जो उस system पर चलती है जहाँ घटनाएँ दर्ज होती हैं: order, stock मूवमेंट, डिलीवरी और journal एंट्री। रात में (या हर घंटे) एक जॉब नतीजा स्नैपशॉट टेबल में लिखती है, हर KPI और हर अवधि के लिए एक पंक्ति, जैसे kpi_id = fill_rate, period = 2026-09, value = 94.0, definition_version = 2। dashboard सिर्फ़ यही टेबल पढ़ता है।
definition_version कॉलम दिखने में जितना छोटा है, काम में उससे कहीं बड़ा है। return रेट गिनने का तरीक़ा बदलने पर पुराने महीने अपने पुराने वर्ज़न पर ही रहते हैं और चार्ट में टूटन साफ़ दिखती है। यह न हो तो परिभाषा बदलना चुपचाप इतिहास दोबारा लिख देता है, और ट्रेंड पर किसी का भरोसा नहीं रहता। order, stock मूवमेंट और अकाउंटिंग journal एक ही database में लिखे जाएँ तो यह काफ़ी आसान हो जाता है, क्योंकि KPI की query फ़ाइलें मिलाने के बजाय टेबल जोड़ती है; StoreConsole का inventory हिस्सा इसी तरह बना है।
लैगिंग इंडिकेटर बताता है कि क्या हो चुका: बिक्री, ग्रॉस margin, कैश। लीडिंग इंडिकेटर पहले हिलता है और इनका अंदाज़ा देता है: कन्वर्ज़न, stock एक्यूरेसी, फ़िल रेट। सिर्फ़ लैगिंग आँकड़ों का dashboard रियर-व्यू मिरर में देखकर गाड़ी चलाने जैसा है। सिर्फ़ लीडिंग आँकड़े अंदाज़ेबाज़ी हैं। दोनों चाहिए, और जुड़े हुए चाहिए।
यह जोड़ एक पेड़ जैसा है। सबसे ऊपर मुनाफ़ा। वह ग्रॉस margin और बिक्री की मात्रा में बँटता है, और हर एक आगे बँटता जाता है, जब तक हम उन चीज़ों तक न पहुँच जाएँ जिन्हें कोई इसी हफ़्ते बदल सकता है: एक लैंडिंग पेज का कन्वर्ज़न, पूरे भेजे गए order का अनुपात, या कितने दिन से माल बिना बिके पड़ा है।
यह पेड़ एक आम ग़लती भी रोकता है: ऐसे आँकड़े को ट्रैक करना जिस पर किसी का बस नहीं। पेड़ पर जिस KPI का मुनाफ़े या कैश तक कोई रास्ता नहीं, वह सजावट है।
बारह एक सीमा है, लक्ष्य नहीं। ये बिक्री, ऑपरेशंस और फ़ाइनेंस तीनों को ढकते हैं, और एक से लेकर कुछ दर्जन outlet वाले कारोबार के लिए इतना काफ़ी है।
| KPI | फ़ॉर्मूला | कितनी बार | ज़िम्मेदार |
|---|---|---|---|
| नेट रेवेन्यू | बिक्री घटा discount और return | रोज़ | सेल्स हेड |
| कन्वर्ज़न रेट | order ÷ सेशन | रोज़ | ई-कॉमर्स लीड |
| औसत order वैल्यू | नेट रेवेन्यू ÷ order | रोज़ | ई-कॉमर्स लीड |
| रिपीट रेट | पहले ख़रीद चुके ग्राहक ÷ उस अवधि के सभी ख़रीदार | हफ़्ते में | मार्केटिंग |
| stock एक्यूरेसी | system से मेल खाते गिने गए आइटम ÷ कुल गिने गए आइटम | हफ़्ते में | inventory मैनेजर |
| फ़िल रेट | पहली ही बार में पूरे भेजे गए order ÷ मिले order | रोज़ | ऑपरेशंस लीड |
| समय पर डिलीवरी | वादे की तारीख़ तक पहुँचे order ÷ डिलीवर हुए order | रोज़ | ऑपरेशंस लीड |
| return रेट | लौटी यूनिट ÷ बिकी यूनिट | हफ़्ते में | ऑपरेशंस लीड |
| ग्रॉस margin | (नेट रेवेन्यू − बिके माल की लागत) ÷ नेट रेवेन्यू | हफ़्ते में | फ़ाइनेंस |
| कैश कन्वर्ज़न साइकिल | DIO + DSO − DPO | महीने में | फ़ाइनेंस |
| डेज़ सेल्स आउटस्टैंडिंग | बकाया रक़म ÷ उधार बिक्री × अवधि के दिन | महीने में | फ़ाइनेंस |
| कैश रनवे | हाथ में नक़द ÷ हर महीने का नेट कैश ख़र्च | महीने में | मालिक |
फ़िल रेट और stock एक्यूरेसी सबसे ज़्यादा छूटते हैं, जबकि आगे की ज़्यादातर परेशानियों की वजह यही दोनों होते हैं। जो दुकान बेचा हुआ माल भेज नहीं पाती, उसे कस्टमर सर्विस की दिक़्क़त से बहुत पहले stock एक्यूरेसी की दिक़्क़त होती है।
एक काल्पनिक उदाहरण: एक छोटे रिटेलर का सितंबर, अमेरिकी डॉलर में। आँकड़े गढ़े हुए हैं, पर आपस में मेल खाते हैं, इसलिए नीचे की हर संख्या हाथ से जाँची जा सकती है।
| KPI | हिसाब | नतीजा | लक्ष्य |
|---|---|---|---|
| कन्वर्ज़न | 1,000 ÷ 40,000 | 2.5% | 2.4% |
| औसत order वैल्यू | 52,000 ÷ 1,000 | 52.00 | 52.00 |
| रिपीट रेट | 312 ÷ 780 | 40.0% | 38% |
| stock एक्यूरेसी | 368 ÷ 400 | 92.0% | 97% |
| फ़िल रेट | 940 ÷ 1,000 | 94.0% | 96% |
| समय पर डिलीवरी | 864 ÷ 960 | 90.0% | 92% |
| return रेट | 168 ÷ 2,400 | 7.0% | 6% |
| ग्रॉस margin | (52,000 − 33,800) ÷ 52,000 = 18,200 ÷ 52,000 | 35.0% | 36% |
| inventory के दिन (DIO) | 67,600 ÷ 33,800 × 30 | 60 दिन | 55 दिन |
| डेज़ सेल्स आउटस्टैंडिंग (DSO) | 6,000 ÷ 12,000 × 30 | 15 दिन | 15 दिन |
| भुगतान के दिन (DPO) | 25,350 ÷ 33,800 × 30 | 22.5 दिन | 25 दिन |
| कैश कन्वर्ज़न साइकिल | 60 + 15 − 22.5 | 52.5 दिन | 45 दिन |
| कैश रनवे | 54,000 ÷ 6,000 | 9.0 महीने | 9 महीने |
इस टेबल को मालिक की नज़र से पढ़िए। कन्वर्ज़न और रिपीट रेट लक्ष्य से आगे हैं, यानी माँग ठीक है। छह आँकड़े लक्ष्य से चूकते हैं, और उनमें से चार एक ही ज़ंजीर की कड़ियाँ हैं: stock एक्यूरेसी, फ़िल रेट, return रेट और कैश साइकिल। stock की गिनती 8% ग़लत हो तो कुछ order ऐसे माल के लिए ले लिए जाते हैं जो शेल्फ़ पर है ही नहीं, और फ़िल रेट गिरकर 94% पर आ जाता है। वह माल देर से, अधूरा या बिल्कुल नहीं पहुँचता, और पीछे-पीछे return आते हैं। उधर 67,600 की inventory 60 दिन पड़ी रहती है, इसलिए कैश कन्वर्ज़न साइकिल 45 के बजाय 52.5 दिन पर ठहरती है। एक इनपुट सुधारने से कई आउटपुट हिलते हैं, और पेड़ बताता है कि पहले किसे पकड़ना है।
कैश साइकिल पर एक बात: DIO और DPO का आधार बिके माल की लागत है, DSO का आधार उधार बिक्री है, और तीनों में अवधि वही 30 दिन है। अवधि या आधार गड्डमड्ड कर देना ग़लत मगर भरोसेमंद लगने वाला जवाब पाने का सबसे आम तरीक़ा है।
बारह आँकड़े एक screen में आ जाते हैं। बाक़ी अनुशासन इस बात का है कि हर टाइल में क्या दिखे।
dashboard तभी काम का है जब लाल का कोई मतलब हो। कोई कुछ करे, उससे पहले सवाल यह है: आँकड़ा ग़लत है या कारोबार?
पहले पाइपलाइन जाँचिए। रात की जॉब चली थी? कोई चैनल feed से छूट गया? कोई परिभाषा बदली? फ़िल रेट एक रात में 94% से 61% पर आ जाए तो अक्सर feed टूटी होती है, गोदाम में आफ़त नहीं आई होती। data सही निकले तो बदलाव असली है, और चार बातें लिखनी होंगी: ज़िम्मेदार, वजह, कदम और रिव्यू की तारीख़। रिव्यू की तारीख़ के बिना लाल टाइल, दो हफ़्ते कोई न देखे तो, अपने आप पीली पड़ जाती है।
सुबह 8:40 पर उसी मालकिन के पास लौटते हैं। स्नैपशॉट टेबल चालू है, तो वे एक पन्ना खोलती हैं। बिक्री 52,000, वही आँकड़ा जो अकाउंटेंट देख रहे हैं, क्योंकि दोनों एक ही order पढ़ रहे हैं। छह टाइल लाल हैं। फ़िल रेट 96% की जगह 94%, ड्रिल-डाउन में 60 अधूरे order, और उनमें से 41 में वही छह SKU।
वजह stock एक्यूरेसी है, इसलिए कदम की ज़िम्मेदारी inventory मैनेजर की: इन छह SKU की दोबारा गिनती, और शुक्रवार को रिव्यू। मीटिंग पंद्रह मिनट में निपट जाती है। जो घंटा आँकड़े मिलाने में जाता था, वह अब इन छह SKU पर लगता है।
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
