কীভাবে একটি HR Leave Management App বানাবেন: অনুরোধ, অনুমোদন ও ব্যালেন্স

একটি leave management app স্প্রেডশিট ও ইমেইলের সেই চেইনের জায়গা নেয় যা “আমি কি শুক্রবার ছুটি নিতে পারি?” প্রশ্নের পেছনে থাকে। কর্মীরা ছুটির অনুরোধ করে এবং বাকি ব্যালেন্স দেখে; ম্যানেজার দলের ক্যালেন্ডার সামনে রেখে অনুমোদন বা প্রত্যাখ্যান করেন; HR ছুটির ধরন, বরাদ্দ ও সরকারি ছুটি ঠিক করে এবং payroll-এর জন্য একটি পরিষ্কার রেকর্ড পায়। এটি বানাতে দরকার এমন ডেটা মডেল যেখানে ব্যালেন্স অনুরোধ ও সমন্বয়ের ইতিহাস থেকে হিসাব হয়, একটি স্পষ্ট অনুমোদন-শৃঙ্খল, এবং আংশিক দিন, সপ্তাহান্ত ও ছুটির নিয়ম। একটি AI app builder দ্রুত একটি কাজের সংস্করণ বানাতে পারে। যত্ন যায় ব্যালেন্সের হিসাব, সংবেদনশীল ছুটির ধরনের চারপাশের অনুমতি, এবং আপনার আসল নীতির সঙ্গে মিল রাখায়।

App-টিতে কী লাগে

ডেটা

মূল নিয়মটি: কখনও হাতে সম্পাদনা করা ব্যালেন্স সংরক্ষণ করবেন না। ব্যালেন্স হলো বরাদ্দ + পরবর্তী বছরে নেওয়া দিন + সমন্বয় − অনুমোদিত দিন। প্রতিটি পরিবর্তনের একটি কারণসহ রেকর্ড থাকে, তাই কেউ যখন জিজ্ঞেস করে “আমার কেন ৩.৫ দিন বাকি?”, আপনি দেখাতে পারবেন।

পেজ

• কর্মী: প্রতি ছুটির ধরনে আমার ব্যালেন্স, অনুরোধের ফর্ম, স্ট্যাটাসসহ আমার অনুরোধগুলো, আমার দলের একটি ক্যালেন্ডার।
• ম্যানেজার: অপেক্ষমাণ অনুরোধ, পাশে দলের ক্যালেন্ডার, মন্তব্যসহ অনুমোদন বা প্রত্যাখ্যান, দলের ব্যালেন্স।
• HR/admin: কর্মী, ছুটির ধরন, বরাদ্দ, সরকারি ছুটি, সমন্বয়, এবং রিপোর্ট ও export।

অনুমতি

এটি ব্যক্তিগত ডেটা, এবং এর কিছু অংশ সংবেদনশীল। কর্মীরা নিজের অনুরোধ দেখে এবং দলের ক্যালেন্ডারে শুধু দেখে যে একজন সহকর্মী “অনুপস্থিত” — কেন নয়। ম্যানেজার তাঁর সরাসরি অধীনস্থদের দেখে। HR সবাইকে দেখে। অসুস্থতা ও অন্যান্য সংবেদনশীল ধরন কর্মী, তাঁর ম্যানেজার ও HR ছাড়া বাকিদের কাছে শুধু “অনুপস্থিত” হিসেবে দেখানো উচিত। এটি সার্ভারে প্রয়োগ করুন; দেখুন role-based access control। কর্মী-রেকর্ডের ডেটা সুরক্ষার নিয়ম দেশভেদে ভিন্ন, তাই আপনার দেশের নিয়ম যাচাই করুন।

সিদ্ধান্ত ও আপস

দিন নাকি ঘণ্টা

দিন (আধা দিনসহ) গণনা করা সবচেয়ে সহজ এবং বেশিরভাগ অফিস দলের জন্য উপযুক্ত। ঘণ্টায় গণনা খণ্ডকালীন ও শিফট কর্মীদের জন্য ভালো, কিন্তু প্রতিটি হিসাব জটিল করে তোলে। প্রথম সংস্করণে একটি বেছে নিন, আপনার চুক্তিতে বরাদ্দ কীভাবে লেখা আছে তার ভিত্তিতে।

শুরুতেই পূর্ণ বরাদ্দ নাকি ধীরে ধীরে জমা

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

কোন দিনগুলো গণনায় আসে

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

অনুমোদনের শৃঙ্খল

একজন অনুমোদনকারী (লাইন ম্যানেজার) বেশিরভাগ ছোট কোম্পানির জন্য যথেষ্ট। ম্যানেজার ছুটিতে থাকলে একজন বিকল্প অনুমোদনকারী যোগ করুন, এবং দীর্ঘ অনুপস্থিতির জন্য ঐচ্ছিকভাবে দ্বিতীয় ধাপ। ম্যানেজার চলে গেলে অপেক্ষমাণ অনুরোধের কী হবে তা ঠিক করুন।

পরবর্তী বছরে নেওয়া ও বছর শেষ

আপনার ছুটির বছর কখন শুরু হবে, কতদিন অব্যবহৃত ছুটি পরের বছরে যাবে, এবং সেই দিনগুলোর মেয়াদ আছে কি না ঠিক করুন। ব্যালেন্স ব্যাখ্যাযোগ্য রাখতে AI-কে পরবর্তী বছরে নেওয়া দিনগুলো আলাদা লাইন হিসেবে দেখাতে বলুন।

একটি কার্যকর প্রথম প্রম্পট

ম্যানচেস্টার (যুক্তরাজ্য) ও ডাবলিন (আয়ারল্যান্ড) অফিসসহ ৪৫ জনের একটি কোম্পানির জন্য একটি অভ্যন্তরীণ leave management app বানান। ছুটির ধরন: বার্ষিক (২৫ দিন, বছরের শুরুতে পূর্ণ, সর্বোচ্চ ৫ দিন পরের বছরে যাবে, ৩১ মার্চে শেষ), অসুস্থতা (সীমাহীন, অনুমোদন লাগে না, অন্যদের কাছে শুধু “অনুপস্থিত” হিসেবে দেখা যায়), বিনা বেতনের, এবং অন্যান্য। ছুটির বছর জানুয়ারি থেকে ডিসেম্বর। কর্মীরা শুরুর তারিখ, শেষের তারিখ ও ঐচ্ছিক আধা দিন দিয়ে ছুটির অনুরোধ করে, এবং দেখে তাদের অফিসের সপ্তাহান্ত, খণ্ডকালীন ছুটির দিন ও সরকারি ছুটি বাদ দিয়ে কতদিন কর্মদিবস লাগবে। ব্যালেন্স বরাদ্দ, পরবর্তী বছরে নেওয়া দিন, সমন্বয় ও অনুমোদিত অনুরোধ থেকে হিসাব হবে, কখনও সরাসরি সম্পাদনা না করে। ম্যানেজাররা মন্তব্যসহ তাঁর সরাসরি অধীনস্থদের অনুরোধ অনুমোদন বা প্রত্যাখ্যান করবেন, একই সময়ে দলের ক্যালেন্ডার দেখে। HR কারণসহ কর্মী, ছুটির ধরন, বরাদ্দ, সরকারি ছুটি ও সমন্বয় পরিচালনা করবে, এবং মাসভিত্তিক অনুমোদিত ছুটি payroll-এর জন্য CSV-তে export করবে। ভূমিকা: কর্মী, ম্যানেজার, HR। সবকিছু একটি database-এ সংরক্ষণ করুন। সরল, দ্রুত ইন্টারফেস।

বানানোর ধাপ

1. আপনার লিখিত নীতি দিয়ে শুরু করুন। যদি সেটি লিখিত না থাকে, আগে লিখুন — app শুধু সেই নিয়ম প্রয়োগ করতে পারে যা আপনি বলতে পারেন।
2. কর্মী আমদানি করুন ম্যানেজার, অবস্থান ও কাজের ধরনসহ, সাধারণত স্প্রেডশিট থেকে। দেখুন স্প্রেডশিটকে app-এ রূপান্তর।
3. ছুটির ধরন, বরাদ্দ ও সরকারি ছুটি।
4. কাজের দিন গণনাসহ অনুরোধ ফর্ম, অন্তত দশটি বাস্তব ক্ষেত্রে পরীক্ষিত: সপ্তাহান্ত পেরিয়ে, একটি সরকারি ছুটি, একজন খণ্ডকালীন কর্মী, একটি আধা দিন, একটি বছরের সীমানা।
5. অনুমোদনের প্রবাহ ও দলের ক্যালেন্ডার।
6. Login ও ভূমিকা, সংবেদনশীল ছুটির ধরন সহকর্মীদের কাছে লুকানো রেখে।
7. বিজ্ঞপ্তি: নতুন অনুরোধে ম্যানেজারকে এবং সিদ্ধান্তে কর্মীকে ইমেইল, আপনার নিজের ইমেইল provider-এর মাধ্যমে। দেখুন আপনার app থেকে ইমেইল পাঠানো।
8. payroll-এর জন্য রিপোর্ট ও export।
9. এক মাস স্প্রেডশিটের পাশাপাশি চালান, ব্যালেন্স মেলান, তারপর পুরোপুরি সরে আসুন।

সাধারণ ভুল

• একটি ব্যালেন্স সংখ্যা সংরক্ষণ করে সেটি সম্পাদনা করা। ইতিহাস হারায় এবং প্রতিটি বিরোধ অনুমানের ব্যাপারে পরিণত হয়।
• কর্মদিবসের বদলে ক্যালেন্ডার দিন গণনা করা, বা কর্মীর অফিস অনুযায়ী সরকারি ছুটি উপেক্ষা করা।
• সবাইকে দেখানো কেন একজন সহকর্মী ছুটিতে। শেয়ার্ড ক্যালেন্ডারে “অনুপস্থিত” যথেষ্ট।
• কোনো বিকল্প অনুমোদনকারী না থাকা। ম্যানেজার ছুটিতে থাকলে অনুরোধ দুই সপ্তাহ পড়ে থাকে।
• অনুমোদিত ছুটি বাতিল করা ম্যানেজারকে না জানিয়ে। বাতিলকরণের খবর অনুমোদনকারীকে জানানো উচিত।
• এই বছরের নিয়ম কোডে বেঁধে রাখা। বরাদ্দ ও ছুটির দিন এমন ডেটা হিসেবে রাখুন যা HR পরের বছর সম্পাদনা করতে পারে।

কখন তৈরি পণ্য ভালো পছন্দ

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

সরল নীতিসহ ছোট ও মাঝারি কোম্পানির জন্য, যারা শুধু স্প্রেডশিট ছাড়তে চায়, অথবা অস্বাভাবিক ব্যবস্থার জন্য (শিফট দল, ঘূর্ণায়মান রোস্টার, on-call কভারের সঙ্গে যুক্ত ছুটি), কাস্টম app যুক্তিসঙ্গত। অথবা এটি onboarding ও অন্যান্য অনুরোধের পাশাপাশি বড় একটি internal tool-এর অংশ হতে পারে। বৃহত্তর পদ্ধতির জন্য দেখুন কীভাবে একটি internal tool বানাবেন।

Mythex দিয়ে বানানো

Mythex-এ আপনি চ্যাটে নীতি ও কাজের প্রবাহ বর্ণনা করেন, এবং agent live preview-এ app বানায়; অনুরোধ সংরক্ষণ করতে হলে একটি Postgres database যোগ হয়। সহকর্মীদের আপনার Mythex workspace-এ আমন্ত্রণ জানিয়ে তাদের বানাতে ও পর্যালোচনা করতে সাহায্য করাতে পারেন, এবং publish করার আগে দুই-তিনজন আসল ব্যবহারকারীর সঙ্গে preview শেয়ার করতে পারেন — docs-এর internal tool use case ঠিক এটিই প্রস্তাব করে। কর্মীদের login ও বিজ্ঞপ্তি ইমেইল আপনার নিজের provider ব্যবহার করে; Mythex-এ end-user login বা ইমেইল পাঠানোর কোনো বিল্ট-ইন ব্যবস্থা নেই। কোনো কোড লেখার আগে ব্যালেন্সের হিসাব নিশ্চিত করতে Plan mode ব্যবহার করুন, এবং অনুরোধ ও অনুমোদন ক্লিক করে দেখতে /test ব্যবহার করুন।

শুরুর প্রম্পটের জন্য approval tracker বা team directory টেমপ্লেট দেখতে পারেন।

প্রশ্নোত্তর