এক সিস্টেমে HR আর পেরোল: কর্মীর তথ্য অপারেশন থেকে আলাদা রাখার লুকোনো খরচ

মাসের ২৯ তারিখ। নয়টি outlet আর ১৪০ কর্মীর এক রিটেইল ব্যবসার ফাইনান্স ম্যানেজারের সামনে পাঁচটা ফাইল খোলা, কারণ কাল সকালেই বেতন ব্যাংকে যেতে হবে: পাঞ্চ মেশিনের অ্যাটেনডেন্স এক্সপোর্ট, এইচআরের হাতে রাখা ছুটির খাতা, কমিশনের জন্য সেলস report, বেতনের স্প্রেডশিট, আর অ্যাকাউন্টিং software, যেখানে স্যালারি journal এখনো হাতে টাইপ করা বাকি। দুই outlet ম্যানেজার জানিয়েছেন তাঁদের ওভারটাইম বাদ পড়েছে। আর বিনা বেতনের ছুটিতে থাকা একজন কর্মী দেখা যাচ্ছে পুরো বেতনেই আছেন।

এর কোনো ফাইলই আলাদাভাবে ভুল নয়। সমস্যা ফাইলগুলোর জোড়ার মুখে, কারণ প্রতিটা জোড়ায় কেউ একজন ডেডলাইনের চাপে হাতে হাতে সংখ্যা তুলছেন।

এই লেখার বক্তব্য: অ্যাটেনডেন্স, ছুটি, payroll আর অ্যাকাউন্টিং একটাই কর্মী-রেকর্ড থেকে চলা উচিত। আলাদা রাখার দাম দিতে হয় ভুল, রাত জাগা আর ফাঁস হওয়ার ঝুঁকিতে পড়া বেতনের তথ্য হয়ে। নিচে দেখা যাবে খরচটা কোথা থেকে আসে, জোড়া লাগানো একটা প্রবাহ কেমন দেখায়, এক মাসের হিসাব সংখ্যাসহ, আর এক ধাক্কায় সব বদলে না ফেলে কীভাবে সেখানে পৌঁছানো যায়।

অপারেশন থেকে আলাদা রাখলে কী ভুল হয়

আলাদা টুল সাধারণত জোরে আওয়াজ করে ভাঙে না। ভাঙে ছোট ছোট বিশ্বাসযোগ্য গরমিল হয়ে, যেগুলো প্রতি মাসে কাউকে না কাউকে খুঁজে বের করতে হয়।

• বারবার টাইপ করা সংখ্যা। ঘণ্টার হিসাব এক system থেকে CSV হয়ে বেরোয়, স্প্রেডশিট ঘুরে আরেক system-এ ঢোকে। প্রতিটা ধাপে কলাম সরে যেতে পারে, পুরনো ফাইল চলে আসতে পারে।
• পুরনো নিয়ম। ১০ তারিখে অনুমোদিত বেতন বৃদ্ধি payroll শিটে পৌঁছায় ২৮ তারিখে। কর্মী কম বেতন পান, সংশোধন যায় পরের মাসে।
• স্ক্রিনশট নিয়ে কমিশনের তর্ক। বিক্রির তথ্য থাকে order আর POS data-য়, অথচ কমিশন হিসাব হয় অন্য কোথাও, এমন এক এক্সপোর্ট থেকে যা আর কেউ হুবহু বানাতে পারে না।
• ঠিকানাহীন খরচ। বেতনের মোট অঙ্ক এক দলায় বুক হয়, তাই কোন outlet বা বিভাগের কর্মী রাখতে আসলে কত লাগছে, কেউ বলতে পারে না।
• হাতে টাইপ করা journal। অ্যাকাউন্ট্যান্ট payroll-এর ফল ledger-এ আবার গড়েন, আর দুটো অঙ্কের জায়গা বদল ধরা পড়ে কয়েক সপ্তাহ পরে রিকনসিলিয়েশনের সময়।
• অনেক ইনবক্সে বেতনের তথ্য। প্রতিটা এক্সপোর্ট আর স্প্রেডশিটের কপি মানে বেতনের তথ্য ফাঁস হওয়ার আরেকটা জায়গা।

payroll-এর ভুলের হার নিয়ে নানা প্রকাশিত সংখ্যা আছে, কিন্তু উৎস আর পদ্ধতি ভেদে তা অনেক বদলায়, তাই এই লেখায় কোনোটাই উদ্ধৃত করা হয়নি। শতাংশের চেয়ে ধরনটা জরুরি: ভুল জমে হ্যান্ড-অফের জায়গায়।

কেন হয়: একই তথ্য চার জায়গায় রাখা হয়

একজন কর্মীর বেতন নির্ভর করে এমন সব তথ্যের ওপর, যেগুলোর উৎস আলাদা আলাদা বিভাগ। ঘণ্টার হিসাব আসে ফ্লোর থেকে। ছুটি আসে ম্যানেজারের অনুমোদন থেকে। বিক্রি আসে কাউন্টার থেকে। বেতনের শর্ত ঠিক করে এইচআর। আর ledger-এর দরকার মোট অঙ্ক, account আর কস্ট সেন্টার ধরে ভাগ করা।

প্রতিটা তথ্য নিজের টুলে থাকলে payroll রান-কে সেগুলো জোগাড় করতে হয়, আর জোগাড় মানেই এক্সপোর্ট। তাই বেশির ভাগ payroll ভুলের পেছনের কারণ অঙ্ক নয়। কারণ পুরনো বা নকল ইনপুট: রানে যে সংখ্যা ব্যবহার হলো সেটা একটা কপি, আর আসলটা তার পরে বদলে গেছে।

জোড়া লাগানো প্রবাহ দেখতে কেমন

জোড়া লাগানো system-এ কর্মীর রেকর্ডই মেরুদণ্ড। বাকি সব module সেখান থেকে পড়ে, সেখানেই ফিরে লেখে, কিছুই কপি হয় না।

1. কর্মীর রেকর্ড। বেতনের শর্ত, outlet, ম্যানেজার, ব্যাংক account আর ওভারটাইমের নিয়ম এক জায়গায়, পরিবর্তনের ইতিহাসসহ।
2. অ্যাটেনডেন্স ও শিফট। পাঞ্চ বা টাইমশিট রোস্টারের শিফটের সঙ্গে মেলানো হয়, আর ফারাকটা হয় নিয়মিত ঘণ্টা, ওভারটাইম বা অনুপস্থিতি।
3. ছুটি। আবেদন ম্যানেজার অনুমোদন করেন, তাতে ধরন (বেতনসহ বা বিনা বেতনে) থাকে, ব্যালান্স আপডেট হয়। অনুমোদিত বিনা বেতনের দিন আপনা থেকেই রানে চলে আসে।
4. বিক্রি। order আর কাউন্টারের বিক্রি আগে থেকেই একজন কর্মী বা outlet-এর নামে লেখা, তাই কমিশন মানে আসল লেনদেনের ওপর একটা query।
5. payroll রান। লক করা ইনপুটে নিয়ম প্রয়োগ হয়, আর প্রত্যেকের আয়, কর্তন ও নিট বেতন বেরিয়ে আসে।
6. অনুমোদন, পেস্লিপ, journal, ব্যাংক ফাইল। একটাই অনুমোদনে তিনটা আউটপুট একসঙ্গে ছাড়া হয়।

মূল নিয়ম হলো, রান পড়ে লক করা data। অ্যাটেনডেন্স আর ছুটির একটা কাট-অফ তারিখ থাকে। তার পর বদলাতে হলে কারণ লিখতে হয় আর ইতিহাসে দাগ থাকে। শুধু এই একটা নিয়মেই "কোন ফাইলটা সর্বশেষ" নিয়ে বেশির ভাগ তর্ক শেষ হয়ে যায়।

এক মাসের হিসাব: একজন কর্মী, একটা journal এন্ট্রি

নিচের সংখ্যাগুলো একটা উদাহরণ মাত্র। হার আর শতাংশ কাল্পনিক। আসল হার ঠিক হয় আপনার দেশের কর ও সামাজিক নিরাপত্তার নিয়মে।

একজন outlet সেলস অ্যাসোসিয়েটের মাসিক মূল বেতন ৩,০০০.০০। কোম্পানির হিসাবে মাসে চুক্তিভিত্তিক ১৬০ ঘণ্টা আর ২৫টি কার্যদিবস। জুলাইয়ে তিনি ১০ ঘণ্টা ওভারটাইম করেছেন, ২ দিন বিনা বেতনে ছুটি নিয়েছেন আর কাউন্টারে ৪০,০০০.০০ মূল্যের পণ্য বিক্রি করেছেন, যার ওপর ২% কমিশন।

খাত	হিসাব	অঙ্ক
মূল বেতন	চুক্তি	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

এই কর্মীর পেছনে কোম্পানির মোট খরচ ৩,৮৪১.২৫ আর ৩০৭.৩০ মিলিয়ে ৪,১৪৮.৫৫। রান অনুমোদন হলে 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

ডেবিট আর ক্রেডিট মিলে গেছে, আর কেউ টাইপ করেনি। পরে ব্যাংক ফাইল payment হলে লাগে আরেকটা ছোট এন্ট্রি: প্রদেয় বেতন ডেবিট, ব্যাংক ক্রেডিট, এই কর্মীর জন্য ৩,২৬৫.০৬। কর আর চাঁদার দায় খোলা থাকে যতক্ষণ না তা জমা দেওয়া হচ্ছে, তাই ledger সব সময় দেখায় কোম্পানির কাছে এখনো কত পাওনা।

ফ্লোচার্টে payroll রান

ভালো রান এমন বোতাম নয় যা সব সময় একটা ফল দেয়। এটা একসারি যাচাই, ইনপুট তৈরি না থাকলে যা এগোতে দেয় না।

দুটো কথা মনে রাখার মতো। এক, ব্যতিক্রমের তালিকাটাই রিভিউ। রিভিউয়ার ১৪০টা পেস্লিপ পড়বেন না। পড়বেন সেই ডজনখানেক, যেগুলো নির্ধারিত শতাংশের বেশি বদলেছে, যেগুলোতে নতুন যোগ দেওয়া বা ছেড়ে যাওয়া কর্মী আছে, অথবা হাতে সমন্বয় করা হয়েছে। দুই, release একটাই কাজ। journal পোস্ট হওয়ার আগে পেস্লিপ চলে গেলে প্রথম দিন থেকেই খাতা আর মানুষের হিসাব আলাদা।

অনুমোদন, সময়সূচি আর কে সই করবেন

payroll-এর সবচেয়ে পুরনো নিয়ন্ত্রণ হলো দায়িত্ব আলাদা রাখা: যিনি বেতনের শর্ত বদলান তিনি রান অনুমোদন করবেন না, আর দুজনের কেউই payment ছাড়বেন না। জোড়া লাগানো system-এ এটা নীতিমালার কাগজ নয়, একটা permission সেটিং।

অনুমোদনের পর ভুল ধরা পড়লে রান আর খোলা যাবে না। সেগুলো পরের মাসে কারণ ও অনুমোদনকারীসহ সমন্বয়ের লাইন হয়ে যায়। এতে প্রতিটা ছাড়া রান আবার হুবহু বানানো যায়, আর প্রতিটা পেস্লিপ চূড়ান্ত থাকে।

বেতনের তথ্য রক্ষা হয় অ্যাক্সেস কন্ট্রোলে, ভরসায় নয়

বেতনের তথ্য একটা ব্যবসার সবচেয়ে স্পর্শকাতর রেকর্ডগুলোর একটা। জোড়া লাগানো system-এ তা রক্ষা করা সহজ, কারণ কপি কম। তবে সেটা তখনই, যখন অ্যাক্সেস ভূমিকা মেনে চলে।

• কর্মী শুধু নিজের পেস্লিপ, অ্যাটেনডেন্স আর ছুটি দেখবেন, আর কিছু নয়। সেলফ-সার্ভিস পেজে ফিল্টার চলবে server-এ, সাইন-ইন করা ব্যক্তি ধরে, browser থেকে পাঠানো কোনো আইডি ধরে নয়।
• ম্যানেজার নিজের টিমের ঘণ্টা আর ছুটির আবেদন দেখবেন। ভূমিকার দরকার না থাকলে বেতন নয়।
• ফাইনান্স দেখবে রানের মোট অঙ্ক আর journal। ব্যক্তিগত বেতনের লাইন দেখবে ছোট একটা payroll ভূমিকা।
• এক্সপোর্টে permission লাগে ও লগ থাকে, আর ব্যাংক ফাইল দরকারের সময় বানানো হয়, শেয়ার্ড ফোল্ডারে জমানো থাকে না।

এটা ইচ্ছে করে পরীক্ষা করুন। সাধারণ একজন কর্মী হিসেবে সাইন ইন করে অ্যাড্রেস বারে আইডি বদলে সহকর্মীরটা দিন, আর দেখুন system আটকায় কি না। সেলফ-সার্ভিস screen যদি অন্যের পেস্লিপ দেখিয়ে দেয়, সেটা data ফাঁস, যত ভালো উদ্দেশ্যেই বানানো হোক।

প্রতিটা module কী জোগাবে

module	payroll রানকে জোগায়	ফেরত পায়
কর্মীর রেকর্ড	বেতনের শর্ত, outlet, ব্যাংক তথ্য, ওভারটাইমের নিয়ম	বেতনের ইতিহাস
অ্যাটেনডেন্স ও শিফট	নিয়মিত, ওভারটাইম ও অনুপস্থিত ঘণ্টা	লক স্ট্যাটাস
ছুটি	বেতনসহ ও বিনা বেতনের দিন, ব্যালান্স	নেওয়া ছুটি ও ব্যালান্স
সেলস ও POS	কমিশনের জন্য ব্যক্তি বা outlet ধরে বিক্রি	দেওয়া কমিশন
অ্যাকাউন্টিং	account ম্যাপিং ও কস্ট সেন্টার	পোস্ট করা journal, জমা দেওয়ার অবস্থা
ব্যাংকিং	payment ফাইলের ফরম্যাট	প্রতি জনের payment সফল না ব্যর্থ

এক ধাক্কায় না বদলে সেখানে পৌঁছানো

এক মাসে সব সরাতে হবে না। বেড়ে ওঠা বেশির ভাগ ব্যবসায় যে ক্রমটা কাজ করে:

1. কর্মীর মাস্টার তালিকা গুছিয়ে নিন। প্রত্যেকের একটাই রেকর্ড, outlet, ম্যানেজার আর ঠিক বেতন কাঠামোসহ।
2. আগে অ্যাটেনডেন্স আর ছুটি সরান। এ দুটোয় দৈনিক data সবচেয়ে বেশি, কাট-অফ তারিখও সবচেয়ে স্পষ্ট।
3. প্রথম রানের আগেই payroll-এর খাতগুলো ledger account আর কস্ট সেন্টারের সঙ্গে মিলিয়ে নিন।
4. এক মাস পাশাপাশি চালান। প্রতি জনের নিট বেতন পুরনো পদ্ধতির সঙ্গে মেলান, আর প্রতিটা ফারাকের কারণ লিখুন।
5. অনুমোদন আর ভূমিকা চালু করুন, তারপর স্প্রেডশিট বন্ধ করুন।
6. বেস রান স্থির হলে বিক্রির data থেকে কমিশন যোগ করুন।

এমন software বাছাইয়ের সময় দেখে নিন অ্যাটেনডেন্স, ছুটি আর payroll journal একটাই product-এ, একটাই কর্মী-রেকর্ডে আছে কি না। StoreConsole-এর payroll module এই মডেলেই চলে, আর নিচের ছোট ট্যুরে একটা রান শুরু থেকে পেস্লিপ পর্যন্ত দেখা যাবে।

কী মাপবেন

metric	কীভাবে হিসাব করবেন	দিক
পেস্লিপ সংশোধন	পরের মাসের সমন্বয় ÷ ইস্যু করা পেস্লিপ	শূন্যের দিকে কমছে
ক্লোজ টাইম	কাট-অফ থেকে payment পর্যন্ত কার্যদিবস	কম ও অনুমানযোগ্য
হাতে করা journal লাইন	প্রতি মাসে হাতে টাইপ করা payroll লাইন	শূন্য
দেরির টাইমশিট	লকের পরে বদলানো রেকর্ড ÷ মোট রেকর্ড	কমছে
আউটলেটভিত্তিক খরচ	কস্ট সেন্টার অনুযায়ী payroll খরচ ÷ outlet-এর বিক্রি	প্রতিটা outlet-এর জন্য দৃশ্যমান

প্রথম সমান্তরাল মাসেই নিজের বেসলাইন ঠিক করে নিন। আসল কথা হলো, প্রতিটা সংখ্যা system থেকে আসবে, কারও গড়ে তোলা হিসাব থেকে নয়।

আবার ২৯ তারিখে

এবার ফাইনান্স ম্যানেজারের কাছে ফেরা যাক। জোড়া লাগানো ব্যবস্থায় অ্যাটেনডেন্স লক হয়েছে ২৪ তারিখে, ছুটি বন্ধ হয়েছে ২৫-এ। ২৬ তারিখের হিসাবে এগারোটা ব্যতিক্রম উঠে এসেছে, ওভারটাইমের দুই আউটলেটসহ, আর এইচআর ২৭ তারিখে সেগুলো মিটিয়েছে। বিনা বেতনের ছুটির কর্মী কখনো পুরো বেতনে ছিলেন না, কারণ অনুমোদিত ছুটি সরাসরি রানে ঢুকেছে।

২৯ তারিখে তিনি একটা রান অনুমোদন করেন। পেস্লিপ চলে যায়, outlet-এর কস্ট সেন্টারসহ journal পোস্ট হয়, ব্যাংক ফাইল তৈরি। সন্ধ্যাটা যায় গত মাসের পর বদলে যাওয়া ব্যতিক্রমগুলো পড়তে, কাজের যে অংশে সত্যিই বিচারবুদ্ধি লাগে।

মূল কথা

• payroll-এর ভুল জমে হ্যান্ড-অফে, যেখানে ঘণ্টা, ছুটি আর বিক্রির তথ্য এক টুল থেকে আরেক টুলে কপি হয়।
• কর্মীর একটাই রেকর্ড রাখুন, আর অ্যাটেনডেন্স, ছুটি, সেলস ও অ্যাকাউন্টিং সেখান থেকেই পড়ুক।
• রানের আগে অ্যাটেনডেন্স আর ছুটি লক করুন, আর পরে ধরা পড়া সংশোধন নিন পরের মাসের সমন্বয় হিসেবে।
• পেস্লিপ, journal আর ব্যাংক ফাইল ছাড়ুন একটাই অনুমোদিত কাজে, আর শর্ত বদলানো, অনুমোদন ও payment-এ আলাদা মানুষ রাখুন।
• বেতনের তথ্য ভূমিকা অনুযায়ী server-এ ফিল্টার করুন, আর সেলফ-সার্ভিস পেজ পরীক্ষা করুন সহকর্মীর পেস্লিপ পড়ার চেষ্টা করে।
• স্প্রেডশিট বন্ধ করার আগে এক মাস পাশাপাশি চালান।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।