एक सिस्टम में HR और पेरोल: लोगों का डेटा ऑपरेशंस से अलग रखने की छिपी लागत

महीने की 29 तारीख़ है और कल सुबह तक सैलरी बैंक पहुँचनी है। नौ outlet और 140 कर्मचारियों वाले एक रिटेल कारोबार की फ़ाइनेंस मैनेजर के सामने पाँच फ़ाइलें खुली हैं: पंच मशीनों का अटेंडेंस एक्सपोर्ट, HR की रखी छुट्टियों की शीट, कमीशन के लिए सेल्स report, सैलरी की स्प्रेडशीट, और अकाउंटिंग software, जिसमें सैलरी journal अभी हाथ से टाइप करना बाक़ी है। दो outlet मैनेजरों ने बताया है कि उनका ओवरटाइम छूट गया है। और बिना वेतन की छुट्टी पर गया एक कर्मचारी पूरी सैलरी पर दिख रहा है।

इनमें से कोई फ़ाइल अकेले में ग़लत नहीं है। दिक़्क़त फ़ाइलों के जोड़ में है, क्योंकि हर जोड़ पर कोई न कोई डेडलाइन के दबाव में हाथ से आँकड़े उतार रहा है।

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

जब लोगों का data ऑपरेशंस से अलग रहता है तो क्या बिगड़ता है

अलग-अलग टूल आम तौर पर शोर करके नहीं टूटते। वे छोटी-छोटी, सही-सी दिखने वाली गड़बड़ियों के रूप में सामने आते हैं, जिन्हें हर महीने किसी को ढूँढना पड़ता है।

• बार-बार टाइप होते आँकड़े। घंटे एक system से CSV बनकर निकलते हैं और स्प्रेडशीट से होकर दूसरे में जाते हैं। हर पड़ाव पर कॉलम खिसक सकता है या पुरानी फ़ाइल आ सकती है।
• पुराने नियम। 10 तारीख़ को मंज़ूर हुई वेतन-बढ़ोतरी payroll शीट तक 28 को पहुँचती है। कर्मचारी को कम पैसे मिलते हैं और सुधार अगले महीने जाता है।
• स्क्रीनशॉट पर बहस करता कमीशन। बिक्री order और POS data में है, पर कमीशन कहीं और से निकलता है, ऐसे एक्सपोर्ट से जिसे कोई दोबारा बना नहीं सकता।
• बिना ठिकाने की लागत। सैलरी का कुल आँकड़ा एक ही गुच्छे में बुक होता है, इसलिए कोई नहीं बता पाता कि किस outlet या विभाग का स्टाफ़ असल में कितने का पड़ रहा है।
• हाथ से टाइप किया journal। अकाउंटेंट payroll का नतीजा ledger में दोबारा बनाता है, और दो अंकों की अदला-बदली हफ़्तों बाद रिकंसिलिएशन में पकड़ी जाती है।
• कई इनबॉक्स में सैलरी। हर एक्सपोर्ट और स्प्रेडशीट की कॉपी सैलरी data के लीक होने की एक और जगह है।

payroll की ग़लतियों की दरें अलग-अलग स्रोतों और तरीक़ों के हिसाब से काफ़ी बदलती हैं, इसलिए इस लेख में कोई दर उद्धृत नहीं की गई। प्रतिशत से ज़्यादा अहम पैटर्न है: ग़लतियाँ हैंड-ऑफ़ वाली जगहों पर जमा होती हैं।

ऐसा क्यों होता है: एक ही तथ्य चार जगह रखा जाता है

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

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

जुड़ा हुआ फ़्लो कैसा दिखता है

जुड़े हुए system में कर्मचारी का रिकॉर्ड रीढ़ की हड्डी है। बाक़ी सारे module उसी से पढ़ते हैं और उसी में लिखते हैं, कुछ भी कॉपी नहीं होता।

1. कर्मचारी रिकॉर्ड। वेतन की शर्तें, outlet, मैनेजर, बैंक खाता और ओवरटाइम के नियम एक जगह, बदलावों के इतिहास के साथ।
2. अटेंडेंस और शिफ़्ट। पंच या टाइमशीट को रोस्टर की शिफ़्ट से मिलाया जाता है, और अंतर नियमित घंटे, ओवरटाइम या ग़ैरहाज़िरी बन जाता है।
3. छुट्टी। मैनेजर आवेदन मंज़ूर करता है, उसमें प्रकार (वेतन सहित या बिना वेतन) दर्ज होता है और बैलेंस अपडेट होता है। मंज़ूर बिना-वेतन वाले दिन अपने आप रन में आ जाते हैं।
4. बिक्री। order और काउंटर की बिक्री पहले से किसी व्यक्ति या outlet के नाम दर्ज है, इसलिए कमीशन असली लेन-देन पर चलाई गई एक query भर है।
5. payroll रन। लॉक किए इनपुट पर नियम लागू होते हैं, और हर व्यक्ति की कमाई, कटौतियाँ और नेट सैलरी निकल आती है।
6. मंज़ूरी, सैलरी स्लिप, journal, बैंक फ़ाइल। एक ही मंज़ूरी से तीनों आउटपुट एक साथ जारी होते हैं।

मुख्य नियम यह है कि रन लॉक data पढ़ता है। अटेंडेंस और छुट्टी की एक कट-ऑफ़ तारीख़ होती है। उसके बाद बदलाव के लिए कारण देना पड़ता है और निशान रह जाता है। सिर्फ़ इसी एक नियम से "कौन-सी फ़ाइल ताज़ा है" वाली ज़्यादातर बहसें ख़त्म हो जाती हैं।

एक महीने का हिसाब: एक कर्मचारी, एक journal एंट्री

नीचे के आँकड़े एक काल्पनिक उदाहरण हैं। दरें और प्रतिशत गढ़े हुए हैं, और असली दरें आपके देश के टैक्स और सामाजिक सुरक्षा के नियम तय करते हैं।

एक outlet सेल्स एसोसिएट की मासिक बेसिक सैलरी 3,000.00 है। कंपनी महीने में 160 अनुबंधित घंटे और 25 कार्यदिवस गिनती है। जुलाई में उसने 10 घंटे ओवरटाइम किया, 2 दिन बिना वेतन की छुट्टी ली और काउंटर पर 40,000.00 का सामान बेचा, जिस पर 2% कमीशन है।

मद	हिसाब	रक़म
बेसिक सैलरी	अनुबंध	3,000.00
ओवरटाइम	10 h × (3,000 ÷ 160 = 18.75) × 1.5	+281.25
कमीशन	2% × 40,000.00 की बिक्री	+800.00
बिना वेतन की छुट्टी	2 दिन × (3,000 ÷ 25 = 120.00)	-240.00
ग्रॉस सैलरी	3,000.00 + 281.25 + 800.00 - 240.00	3,841.25
कटा आयकर	ग्रॉस का उदाहरण के तौर पर 10%	-384.13
कर्मचारी का अंशदान	ग्रॉस का उदाहरण के तौर पर 5%	-192.06
नेट सैलरी	3,841.25 - 384.13 - 192.06	3,265.06
नियोक्ता का अंशदान	ग्रॉस का उदाहरण के तौर पर 8%	307.30

इस कर्मचारी पर कंपनी की कुल लागत 3,841.25 और 307.30 मिलाकर 4,148.55 बैठती है। रन मंज़ूर होते ही system एक journal एंट्री लिखता है। ख़र्च कई account में बँटता है, और कॉस्ट सेंटर के तौर पर उस कर्मचारी का outlet लगता है:

account	डेबिट	क्रेडिट
सैलरी ख़र्च, बेसिक (3,000.00 - 240.00)	2,760.00
सैलरी ख़र्च, ओवरटाइम	281.25
सैलरी ख़र्च, कमीशन	800.00
नियोक्ता अंशदान का ख़र्च	307.30
देय सैलरी (नेट)		3,265.06
देय कटा आयकर		384.13
देय कर्मचारी अंशदान		192.06
देय नियोक्ता अंशदान		307.30
कुल	4,148.55	4,148.55

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

फ़्लोचार्ट में payroll रन

अच्छा रन ऐसा बटन नहीं है जो हमेशा कोई नतीजा थमा दे। वह जाँचों की एक कड़ी है, जो इनपुट तैयार न होने पर आगे नहीं बढ़ती।

दो बातें ध्यान देने लायक़ हैं। पहली, अपवादों की सूची ही रिव्यू है। रिव्यूअर को 140 सैलरी स्लिप नहीं पढ़नी चाहिए। उसे वे दर्जन भर पढ़नी चाहिए जो तय प्रतिशत से ज़्यादा बदली हैं, जिनमें कोई नया जुड़ा या नौकरी छोड़कर गया कर्मचारी है, या जिन पर हाथ से एडजस्टमेंट लगा है। दूसरी, release एक ही कार्रवाई है। journal पोस्ट होने से पहले सैलरी स्लिप निकल गई तो पहले दिन से बही-खाता और लोगों का हिसाब अलग-अलग हो जाते हैं।

मंज़ूरी, समय-सारणी और दस्तख़त किसके

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

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

सैलरी data की हिफ़ाज़त एक्सेस कंट्रोल से होती है, भरोसे से नहीं

सैलरी data किसी भी कारोबार के सबसे संवेदनशील रिकॉर्ड में गिना जाता है। जुड़े हुए system में उसे बचाना आसान है, क्योंकि कॉपियाँ कम हैं, पर तभी जब एक्सेस भूमिका के हिसाब से चले।

• कर्मचारी सिर्फ़ अपनी सैलरी स्लिप, अटेंडेंस और छुट्टी देखे, और कुछ नहीं। सेल्फ़-सर्विस पेज पर फ़िल्टर server पर चले, साइन-इन किए व्यक्ति के हिसाब से, browser से भेजी गई किसी आईडी के हिसाब से नहीं।
• मैनेजर अपनी टीम के घंटे और छुट्टी के आवेदन देखे। भूमिका को ज़रूरत न हो तो सैलरी नहीं।
• फ़ाइनेंस रन के कुल आँकड़े और journal देखे। हर व्यक्ति की सैलरी की लाइनें सिर्फ़ एक छोटी payroll भूमिका देखे।
• एक्सपोर्ट पर permission लगे और लॉग रहे, और बैंक फ़ाइल ज़रूरत पड़ने पर बने, साझा फ़ोल्डर में पड़ी न रहे।

इसे जान-बूझकर जाँचिए। एक आम कर्मचारी के तौर पर साइन-इन करें, एड्रेस बार में आईडी बदलकर किसी सहकर्मी की डालें, और देखें कि system रोकता है या नहीं। जो सेल्फ़-सर्विस screen किसी और की सैलरी स्लिप दिखा दे, वह data लीक है, चाहे उसे कितनी भी भली नीयत से बनाया गया हो।

हर module को क्या देना चाहिए

module	payroll रन को देता है	वापस पाता है
कर्मचारी रिकॉर्ड	वेतन की शर्तें, outlet, बैंक विवरण, ओवरटाइम के नियम	वेतन का इतिहास
अटेंडेंस और शिफ़्ट	नियमित, ओवरटाइम और ग़ैरहाज़िरी के घंटे	लॉक की स्थिति
छुट्टी	वेतन सहित और बिना वेतन के दिन, बैलेंस	ली गई छुट्टी और बैलेंस
सेल्स और POS	कमीशन के लिए व्यक्ति या outlet के हिसाब से बिक्री	चुकाया गया कमीशन
अकाउंटिंग	account मैपिंग और कॉस्ट सेंटर	पोस्ट हुआ journal, जमा होने की स्थिति
बैंकिंग	payment फ़ाइल का फ़ॉर्मैट	हर व्यक्ति का भुगतान सफल या असफल

एक झटके में बदले बिना वहाँ तक कैसे पहुँचें

सब कुछ एक ही महीने में नए system पर लाना ज़रूरी नहीं। ज़्यादातर बढ़ते कारोबारों में यह क्रम चल जाता है:

1. कर्मचारी मास्टर साफ़ करें। हर व्यक्ति का एक ही रिकॉर्ड, outlet, मैनेजर और सही सैलरी स्ट्रक्चर के साथ।
2. पहले अटेंडेंस और छुट्टी नए system में लाएँ। इनमें रोज़ का data सबसे ज़्यादा है और कट-ऑफ़ तारीख़ें सबसे साफ़।
3. पहले रन से पहले payroll के घटकों को ledger account और कॉस्ट सेंटर से जोड़ दें।
4. एक महीना दोनों साथ चलाएँ। हर व्यक्ति की नेट सैलरी पुराने तरीक़े से मिलाएँ और हर अंतर का कारण लिखें।
5. मंज़ूरी और भूमिकाएँ चालू करें, फिर स्प्रेडशीट बंद करें।
6. बेस रन टिक जाए तो बिक्री के data से कमीशन जोड़ें।

ऐसा software चुनते समय देखिए कि अटेंडेंस, छुट्टी और payroll journal एक ही product में, एक ही कर्मचारी रिकॉर्ड पर हैं या नहीं। StoreConsole का payroll module इसी मॉडल पर चलता है, और नीचे का छोटा टूर एक रन को शुरू से सैलरी स्लिप तक दिखाता है।

क्या मापें

metric	कैसे निकालें	दिशा
सैलरी स्लिप सुधार	अगले महीने के एडजस्टमेंट ÷ जारी सैलरी स्लिप	शून्य की ओर घटता
क्लोज़ टाइम	कट-ऑफ़ से भुगतान तक कार्यदिवस	कम और अनुमान-योग्य
हाथ से बनी journal लाइनें	हर महीने हाथ से टाइप की गई payroll लाइनें	शून्य
देर से आई टाइमशीट	लॉक के बाद बदले रिकॉर्ड ÷ कुल रिकॉर्ड	घटता
outlet के हिसाब से लागत	कॉस्ट सेंटर के अनुसार payroll लागत ÷ outlet की बिक्री	हर outlet के लिए दिखे

अपना बेसलाइन पहले समानांतर महीने में तय कर लीजिए। असल बात यह है कि हर आँकड़ा system से निकले, किसी के जोड़-तोड़ से बने हिसाब से नहीं।

वापस 29 तारीख़ पर

फ़ाइनेंस मैनेजर के पास लौटते हैं। जुड़े हुए system में अटेंडेंस 24 को लॉक हो चुकी है और छुट्टियाँ 25 को बंद। 26 तारीख़ की गणना ने ग्यारह अपवाद सामने रखे, जिनमें ओवरटाइम वाले दो outlet भी थे, और HR ने उन्हें 27 को निपटा दिया। बिना वेतन की छुट्टी वाला कर्मचारी कभी पूरी सैलरी पर था ही नहीं, क्योंकि मंज़ूर छुट्टी सीधे रन में आ गई।

29 तारीख़ को वह एक रन मंज़ूर करती है। सैलरी स्लिप निकल जाती हैं, outlet के कॉस्ट सेंटर के साथ journal पोस्ट हो जाता है और बैंक फ़ाइल तैयार है। उसकी शाम उन अपवादों को पढ़ने में जाती है जो पिछले महीने के बाद बदले हैं, यानी काम के उस हिस्से में जहाँ समझ-बूझ चाहिए।

मुख्य बातें

• payroll की ग़लतियाँ हैंड-ऑफ़ पर जमा होती हैं, जहाँ घंटे, छुट्टी और बिक्री का data एक टूल से दूसरे में कॉपी होता है।
• कर्मचारी का एक ही रिकॉर्ड रखें, और अटेंडेंस, छुट्टी, सेल्स और अकाउंटिंग उसी से पढ़ें।
• रन से पहले अटेंडेंस और छुट्टी लॉक करें, और बाद में मिले सुधार अगले महीने के एडजस्टमेंट के रूप में लें।
• सैलरी स्लिप, journal और बैंक फ़ाइल एक ही मंज़ूर कार्रवाई में जारी करें, और शर्तें बदलने, मंज़ूर करने और भुगतान करने का काम अलग-अलग लोगों के पास रखें।
• सैलरी data को भूमिका के हिसाब से server पर फ़िल्टर करें, और सेल्फ़-सर्विस पेज को किसी सहकर्मी की सैलरी स्लिप पढ़ने की कोशिश करके परखें।
• स्प्रेडशीट छोड़ने से पहले एक महीना दोनों तरीक़े साथ चलाएँ।

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।