স্পষ্ট নীতি ও অনুমোদনের জন্য ছুটি অনুরোধ সিস্টেম ডিজাইন

বেশিরভাগ ছুটি প্রক্রিয়ায় কী ভেঙে যায়

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

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

টাইম-অফ অনুরোধ সিস্টেম ডিজাইন-এর মূল লক্ষ্য বিরক্তিকর কিন্তু গুরুত্বপূর্ণ: সঠিক ব্যালেন্স, স্পষ্ট অনুমোদন, এবং একক সত্যের উৎস। যদি আপনার ব্যালান্স ঠিক থাকে কিন্তু অনুমোদন অস্পষ্ট হয়, ম্যানেজাররা বারবার জিজ্ঞেস করবেন “আমি কি ইতিমধ্যে এটি অনুমোদন করেছি?” যদি অনুমোদন পারফেক্ট হয় কিন্তু ক্যালেন্ডার ভুল থাকে, দলগুলো তারপরও ডাবল-বুক করবে।

চারটি গ্রুপ একই ওয়ার্কফ্লোর উপর নির্ভর করে, কিন্তু ভিন্ন কারণে:

• কর্মীরা: দ্রুত অনুরোধ, তাত্ক্ষণিক স্থিতি, এবং নিশ্চিততা যে এটি রেকর্ড হয়েছে
• ম্যানেজাররা: সঠিক অনুরোধ তাদের কাছে পৌঁছানো, সিদ্ধান্ত নেওয়া জন্য পর্যাপ্ত প্রেক্ষাপট সহ
• HR/পে-রোল: নীতিগুলো ধারাবাহিকভাবে প্রয়োগ করা এবং পে-রুলের সাথে মেলে এমন ব্যালেন্স
• ব্যবসা: দলীয় দৃশ্যমানতা প্রাইভেসি উন্মুক্ত না করে

একটি “পাঠযোগ্য ওয়ার্কফ্লো” মানে আপনি ধাপগুলো দেখেও সেগুলো সাধারণ ভাষায় ব্যাখ্যা করতে পারবেন: কী অনুরোধ ট্রিগার করে, কে অনুমোদন করে, প্রত্যাখ্যান হলে কী হয়, এবং কী লেখা হয় (ব্যালান্স, স্ট্যাটাস, ক্যালেন্ডার)। যদি আপনি দ্রুত এটি ব্যাখ্যা করতে না পারেন, লোকেরা এটি বর্ডার করবে।

AppMaster মত টুলগুলো সাহায্য করতে পারে লজিক ভিজ্যুয়াল এবং কেন্দ্রীকৃত রাখে, যাতে নীতি বদলিং ইমেইল ও এক্সেপশন-এর জঞ্জালে পরিণত না হয়।

প্রয়োজনীয় মৌলিক ডেটা (অতিরিক্ত নির্মাণ ছাড়াই)

একটি ভালো টাইম-অফ টুল মূলত পরিষ্কার রেকর্ড সেট এবং কয়েকটি স্পষ্ট সম্পর্ক। আপনি যদি বেসিকগুলো ঠিক রাখেন, আপনার বাকি টাইম-অফ অনুরোধ সিস্টেম ডিজাইন পড়তে সহজ থাকে, এমনকি নীতি ও অনুমোদন পরে বাড়লেও।

এক মিনিটে ব্যাখ্যা করা যায় এমন একটি ছোট সেট কোর অবজেক্ট দিয়ে শুরু করুন:

• Employee: কে ছুটি অনুরোধ করছে (এবং কে তাদের অনুমোদন করে)।
• TimeOffRequest: বাস্তব অনুরোধ (তারিখ, ধরন, স্ট্যাটাস)।
• Policy: একটি ছুটির ধরনের নিয়ম (PTO, অসুস্থ, আনপেইড)।
• Balance: কর্মী ও নীতির জন্য বর্তমান উপলব্ধ পরিমাণ।
• Approval: অনুরোধের সাথে সংযুক্ত সিদ্ধান্ত এবং মন্তব্য।

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

স্ট্যাটাসগুলো少ই এবং পূর্বানুমেয় হওয়া উচিত: draft (সংরক্ষিত কিন্তু পাঠানো হয়নি), submitted, approved, rejected, এবং canceled। অতিরিক্ত স্ট্যাটাস যেমন “pending HR” এড়িয়ে চলুন যতক্ষণ না সত্যিই দরকার।

অডিট ট্রেল বাদ দেবেন না। এমনকি একটি ন্যূনতম “কে কী বদল করেছে এবং কখন” দ্বন্দ্বে আপনাকে বাঁচিয়ে দেয়। ন্যূনতমভাবে সাবমিট, অনুমোদন, প্রত্যাখ্যান, বাতিল, এবং যেকোনো তারিখ সম্পাদনা লগ করুন।

টিম, লোকেশন, এবং ডিপার্টমেন্টগুলিকে পৃথক রেফারেন্স ডেটা হিসাবে বিবেচনা করুন। কর্মীদের এই গ্রুপগুলোর সাথে লিংক করুন, এবং নীতিগুলোকে সেই গ্রুপগুলোর সাথে লিংক করুন যেগুলোর উপর সেগুলো প্রযোজ্য। এতে কেউ অফিস বদলালে আপনি একটি কর্মী রেকর্ড আপডেট করবেন, প্রতিটি নীতি নয়।

AppMaster-এ এটি নির্মাণ করলে, প্রথমে প্রতিটি অবজেক্ট সহজ রাখুন, তারপর ডেটা স্থিতিশীল হলে ভ্যালিডেশন এবং ওয়ার্কফ্লো ধাপ যোগ করুন।

নীতি নিয়ম: স্পষ্ট এবং টেস্টযোগ্য রাখুন

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

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

যোগ্যতা নিয়মগুলি চেকলিস্টের মতো পড়া উচিত, কোনো আইনগত নথির মতো নয়। স্পষ্ট রাখুন: কে ব্যবহার করতে পারে (ফুল-টাইম, পার্ট-টাইম, কন্ট্রাক্টর), কখন শুরু হয় (প্রোবেশন পর, X দিনের পর), এবং এটি টেনিউরের উপর নির্ভর করে কিনা। যদি কোনো নিয়মের ব্যতিক্রম থাকে, সেটা আলাদা নিয়ম হিসেবে লিখুন, ফুটনোট হিসেবে নয়।

অনুরোধ নিয়মগুলোই সাধারণত বিভ্রান্তির শুরু। নোটিশ পিরিয়ড, ব্ল্যাকআউট ডেট, এবং সর্বনিম্ন অনুমোদিত সময় সম্পর্কে নির্দিষ্ট থাকুন। উদাহরণ: “Vacation requests must be submitted 5 business days in advance, except emergencies approved by HR” — এটি টেস্টযোগ্য। কেবল “প্রারম্ভে জমা দিন” বললে নয়।

ক্যারি-ওভার এবং মেয়াদ উত্তীর্ণের নিয়ম এক বাক্যে ফিট করা উচিত। উদাহরণ: “Up to 40 hours carry over to next year and expire on March 31.” যদি দ্বিতীয় বাক্য প্রয়োজন হয়, তা নির্দেশ করে নীতি খুব বেশি জটিল হচ্ছে।

নীতির টেক্সট এবং নিয়ম লজিক সিংক্রোনাইজ রাখার সহজ উপায়:

• প্রতিটি নিয়মকে একটি সংক্ষিপ্ত আইডি দিন (যেমন PTO-NOTICE-5D)
• কনফিগারেশনের পাশে সরাসরি প্লেইন-ল্যাঙ্গুয়েজ টেক্সট স্টোর করুন
• প্রতিটি নিয়মের জন্য 2-3 স্যাম্পল কেস যোগ করুন (অনুমোদিত বা প্রত্যাখ্যাত হিসেবে) যা টেস্ট হিসেবে কাজ করবে
• নীতি টেক্সট কেবল তখনই পরিবর্তন করুন যখন নিয়ম কনফিগারেশন বদলায় (এবং বিপরীতও)

উদাহরণ: probation-এ থাকা একজন কর্মী আগামীকাল 2 ঘণ্টা PTO অনুরোধ করে। সিস্টেমটি দুটি কারণ দেখিয়ে ব্লক করা উচিত যা পড়তে সহজ: “PTO starts after 60 days” এবং “PTO needs 5 business days notice.” AppMaster-এ এই মেসেজগুলো নিয়ম নোডের কাছাকাছি রাখুন যাতে আপডেটগুলি সময়ের সাথে বিচ্ছিন্ন না হয়।

অ্যাক্রুয়াল গণিত: বিভ্রান্তির কারণ হওয়া প্যাটার্নগুলো

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

একটি সাধারণ বিভ্রান্তি হলো বিভিন্ন এক্রুয়াল স্টাইল মিশিয়ে ফেলা। কিছু কোম্পানি প্রতি পে পিরিয়ডে ঘন্টা যোগ করে, অন্যরা মাসিক যোগ করে, কেউ কেউ কাজকরা প্রতি ঘন্টায় অ্যাক্রু করে, এবং কেউ সম্পূর্ণ বার্ষিক পরিমাণ একটি নির্দিষ্ট তারিখে দেয়। সমস্যা শুরু হয় যখন আপনি কেবল “ব্যালান্স” স্টোর করেন এবং “কিভাবে অর্জিত” তা ভুলে যান। ইভেন্টগুলোর স্পষ্ট রেকর্ড রাখুন: grant, accrue, adjustment, এবং usage।

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

ক্যাপ এবং নেগেটিভ ব্যালান্স “ভুল মনে হচ্ছে” টিকিট তৈরি করে। আপনি যদি ক্যারি-ওভারকে ক্যাপ দেওয়ার অনুমতি দেন, ক্যাপটি একটি নির্দিষ্ট মুহূর্তে প্রয়োগ করুন (বছর শেষ, অ্যাক্রুয়াল পিরিয়ডের শেষ, বা প্রতিটি অ্যাক্রুয়াল পর)। যদি নেগেটিভ ব্যালান্স অনুমোদিত হয়, সীমা এবং টার্মিনেশনের সময় কী হয় তা নির্ধারণ করুন।

রাউন্ডিং নিয়ম গোপন ঘুর্ণি তৈরি করে। একটি রাউন্ডিং লেভেল নির্ধারণ করুন (মিনিট, কোয়ার্টার-আওয়ার্স, কিংবা অর্ধ-দিন) এবং একইভাবে অ্যাক্রুয়াল ও ব্যবহার উভয় ক্ষেত্রেই প্রয়োগ করুন। আপনি যদি মিনিটে অ্যাক্রু করেন কিন্তু অনুরোধ অর্ধ-দিনে নেন, কর্মীরা সবসময় সিস্টেম কে অফ মনে করবে।

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

একটি সহজ চেকলিস্ট যা বেশিরভাগ দ্বন্দ্ব প্রতিরোধ করে:

• ব্যালান্স পরিবর্তনগুলো দৈগত ট্রানজ্যাকশনেরূপে সংরক্ষণ করুন, কেবল একটি সংখ্যা নয়
• নীতি ইনপুট বদলালে কার্যকর তারিখ থেকে পুনরায় গণনা করুন
• ক্যাপ এবং রাউন্ডিং একটি শেয়ার্ড ফাংশনে প্রয়োগ করুন
• ম্যানুয়াল সমন্বয়গুলো এক্সক্লুসিভ রাখুন অ্যাক্রুয়াল লজিক থেকে
• প্রদর্শিত ব্যালান্সের জন্য সর্বদা “as of date” দেখান

AppMaster-এ এটি সাধারণত Transactions টেবিল এবং একটি ছোট বিজনেস প্রসেস হিসেবে মানচিত্রীভূত হয় যা অনুরোধ অনুমোদিত বা সংশোধিত হলে ব্যালান্স পুনঃগণনা করে।

ম্যানেজার অনুমোদন: সরল রুটিং যা এজ কেসও কভার করে

ম্যানেজার অনুমোদন ওয়ার্কফ্লো এক প্রশ্নের উত্তর দেয়: কে আত্মবিশ্বাসের সঙ্গে “হ্যাঁ” বলতে পারে? আপনি যদি প্রতিটি অর্গ চার্ট ডিটেল মডেল করার চেষ্টা করেন, আপনার টাইম-অফ অনুরোধ সিস্টেম ডিজাইন পড়তে কঠিন হয়ে যাবে এবং ঠিক করা আরও কঠিন।

একটি ডিফল্ট নিয়ম দিয়ে শুরু করুন: কর্মীর সরাসরি ম্যানেজার অনুমোদন করে। তারপর কেবল সেই এক্সেপশনগুলো যোগ করুন যেগুলো ঝুঁকি বা জবাবদিহিতাকে পরিবর্তন করে। নিয়মগুলোর ক্রম স্পষ্ট রাখুন, যাতে আপনি ফলাফল সহজে ব্যাখ্যা করতে পারেন সেটিংস খুঁটিয়ে না দেখে।

এক-ধাপ বনাম বহু-ধাপ অনুমোদন

অধিকাংশ দল স্ট্যান্ডার্ড PTO-এর জন্য একটি একক অনুমোদন ধাপ ব্যবহার করতে পারে। শুধুমাত্র তখনই ধাপ বাড়ান যখন অনুরোধ পে-রোল, কমপ্লায়েন্স, বা কভারেজকে প্রভাবিত করে।

পাঠযোগ্য থাকার সাধারণ প্যাটার্ন:

• One-step: স্ট্যান্ডার্ড PTO এবং আনপেইড ছুটির জন্য ম্যানেজার অনুমোদন করে।
• Two-step: ম্যানেজার তারপর HR, যখন ছুটির ধরন ডকুমেন্ট বা নীতি চেক দাবি করে।
• Second approver: ডিপার্টমেন্ট হেড যোগ করুন কেবল তখনই যখন অনুপস্থিতি শেয়ার্ড কভারেজ প্রভাবিত করে।
• Auto-approve: কম ঝুঁকির অনুরোধ, যেমন 1-2 ঘন্টার অ্যাপয়েন্টমেন্ট।
• No manager: কন্ট্রাক্টর বা এমন ভূমিকার জন্য যেখানে স্পষ্ট ম্যানেজার নেই, HR-ই অনুমোদন করে।

ডেলিগেশন, প্রত্যাখ্যান, এবং পুনরায় সাবমিট

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

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

একটি বাস্তব উদাহরণ: আলেক্স 3 দিনের অসুস্থ ছুটি অনুরোধ করে। সিস্টেম এটি ম্যানেজারের কাছে পাঠায়, কিন্তু এটি একটি নীতি-নিয়ন্ত্রিত ছুটির ধরন হওয়ায় ম্যানেজারের অনুমোদনের পরে HR-কে দ্বিতীয় ধাপ হিসেবে পাঠানো হয়। যদি ম্যানেজার অনুপস্থিত থাকেন, ডেলিগেট অনুমোদন করে, এবং অডিট ট্রেইল দেখায় কেন।

AppMaster-এ তৈরি করলে, রাউটিং লজিক একটি ভিজ্যুয়াল প্রসেসে রাখুন এবং একটি সীমিত নিয়ম সেট স্পষ্ট ক্রমে রাখুন, যাতে পরে কেউ পড়ে এবং বজায় রাখতে পারে।

অনুরোধ ছাড়তে দেওয়ার আগে ভ্যালিডেশন নিয়ম

ভাল ভ্যালিডেশন টাইম-অফ অনুরোধ সিস্টেম ডিজাইনকে পাঠযোগ্য রাখে কারণ এটি বিশেষ কেসগুলোকে অনুমোদনে ভেসে উঠতে বাধা দেয়। সহজে বোঝার এবং টেস্ট করার মতো নিয়ম লক্ষ্য করুন।

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

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

এখানে কিছু পরিষ্কার ভ্যালিডেশন যা বেশিরভাগ কেস কভার করে:

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

টিম কভারেজ চেক সহায়ক হতে পারে, কিন্তু হার্ড ব্লক এড়িয়ে চলুন যতক্ষণ না অবশ্যই দরকার। একটি ভালো ডিফল্ট হলো একটি সতর্কবার্তা যা ম্যানেজারকে সিদ্ধান্ত নিতে দেয়। উদাহরণ: “আপনার টিমে ইতিমধ্যেই দুইজন সেই দিন ছুটিতে আছেন। তবু সাবমিট করবেন?”

এরর মেসেজগুলো ন্যায্য এবং ঠিক করার উপায় যোগ করা উচিত। ব্যবহারকারীকে বলুন কী ব্যর্থ হয়েছে, কোথায়, এবং কীভাবে ঠিক করতে হবে। উদাহরণ: “আপনার অনুরোধ Mar 12 (PM)-এ অনুমোদিত PTO-র সাথে ওভারল্যাপ করছে। ভিন্ন সময় নির্বাচন করুন বা বিদ্যমান অনুরোধ সম্পাদনা করুন।”

AppMaster-এ নির্মাণ করলে, ভ্যালিডেশনগুলো অনুরোধ ফর্মের কাছে রাখুন এবং একই চেকগুলো অনুমোদন ধাপেও পুনরায় ব্যবহার করুন, যাতে নিয়মগুলো সময়ের সাথে বিচ্ছিন্ন না হয়।

ধাপে ধাপে: একটি পাঠযোগ্য ওয়ার্কফ্লো যা আপনি তৈরি ও বজায় রাখতে পারবেন

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

এখানে একটি সিকোয়েন্স যা নতুন ছুটি ধরন পরে যোগ করলেও সহজ থাকে:

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

ওয়ার্কফ্লো পাঠযোগ্য রাখতে প্রতিটি সিদ্ধান্ত সহজ ভাষায় লগ করুন (উদাহরণ: “Rejected: overlaps existing approved leave”)। আপনি যদি ভিজ্যুয়াল ওয়ার্কফ্লো টুল যেমন AppMaster-এর Business Process Editor ব্যবহার করেন, ধাপগুলো এমনভাবে লেবেল করুন যেভাবে মানুষ পড়বে।

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

ক্যালেন্ডার ইন্টিগ্রেশন যা সময়ের সাথে সঠিক থাকে

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

ইভেন্ট সামগ্রীর জন্য, ধারাবাহিক রাখুন। একটি ভালো ডিফল্ট হলো সংক্ষিপ্ত শিরোনাম যেমন “Out of office - Alex Kim” এবং যদি দরকার হয় ছুটির ধরন যোগ করা (“PTO”, “Sick”)। গোপনীয়তার জন্য বিস্তারিত কম রাখুন। অনেক দল ইভেন্টকে “Busy” হিসেবে দেখানো পছন্দ করে এবং কারণ, ব্যালান্স, এবং নোটগুলো শুধু অনুরোধেই রাখে।

ক্যালেন্ডার ইভেন্টকে সোর্স না মেনে একটি মিরর হিসেবে আচরণ করুন

প্রতি অনুরোধের একটি স্থায়ী অভ্যন্তরীণ ID থাকা উচিত, এবং প্রতিটি ক্যালেন্ডার ইভেন্ট সেই ID সংরক্ষণ করা উচিত (উদাহরণ: কাস্টম ফিল্ড বা বিবরণে)। এতে আপনি নিরাপদে সঠিক ইভেন্ট তৈরি, আপডেট, বা মুছতে পারবেন অনুরোধ পরিবর্তিত হলে।

স্ট্যাটাস পরিচালনা করাই যেখানে সিস্টেমগুলো ভাঁজ খায়। সিদ্ধান্ত নিন প্রাথমিকভাবে কি টেন্টেটিভ অনুরোধগুলো দেখাবেন। যদি দেখান, পার্থক্য স্পষ্ট করুন (উদাহরণ: শিরোনামে “Pending” প্রিফিক্স এবং ভিন্ন উপলব্ধতা সেটিং)। অনুমোদনের পরে একই ইভেন্ট আপডেট করুন নতুন ইভেন্ট তৈরি না করে। যদি অনুরোধ বাতিল বা প্রত্যাখ্যাত হয় পরে, ইভেন্টটি মুছে দিন যাতে ক্যালেন্ডার মিথ্যা না দেখায়।

টাইমজোন এবং “অদ্ভুত” দিনগুলো

টাইমজোনসমূহ সর্বাধিক সমস্যা তৈরি করে অ্যান-ডে এবং আংশিক-ডে ছুটির সঙ্গে। শুরু এবং শেষটিকে নির্দিষ্ট টাইমস্ট্যাম্প হিসেবে কর্মীর লোকাল টাইমজোনে স্টোর করুন, এবং অনুরোধেও সেই টাইমজোন সংরক্ষণ করুন।

সত্যিকারের ফুল-ডে ছুটির জন্য শুধু অল-ডে ইভেন্ট ব্যবহার করুন। আংশিক দিনের জন্য টাইমড ইভেন্ট তৈরি করুন (উদাহরণ 13:00-17:00) যাতে অন্যান্য জোনের সহকর্মীরাও সঠিক ওভারল্যাপ দেখতে পারে।

• ফুল ডে: কর্মীর টাইমজোনে অল-ডে ইভেন্ট
• আংশিক দিন: শুরু এবং শেষ টাইমস্ট্যাম্প সহ টাইমড ইভেন্ট
• বহু-দিন: অল-ডে ইভেন্ট ঠিক আছে, কিন্তু এন্ড-ডেট নিয়ম (ইনক্লুসিভ বনাম এক্সক্লুসিভ) যাচাই করুন

যদি ক্যালেন্ডার সিঙ্ক ব্যর্থ হয়, তা লুকাবেন না। জবটিকে কিউ করুন, ব্যাকঅফ দিয়ে রিট্রাই করুন, এবং একটি পরিষ্কার “Calendar not updated” স্ট্যাটাস দেখান যার সাথে ম্যানুয়াল “retry sync” অ্যাকশন আছে। AppMaster-এর মতো টুলে এটি সাধারণত একটি ব্যাকগ্রাউন্ড প্রসেস এবং একটি অ্যাডমিন স্ক্রীন যেখানে ব্যর্থ সিঙ্ক প্রচেষ্টাগুলি তালিকাভুক্ত থাকে যাতে HR অনুরোধ এডিট না করেই সমস্যা ঠিক করতে পারে।

সাধারণ ভুল এবং কিভাবে এড়ানো যায়

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

ভুল 1: অ্যাক্রুয়াল লজিক এক্সেপশনগুলোর মধ্যে ছড়িয়ে থাকা

যদি অ্যাক্রুয়াল বহু বিশেষ কেসে বিভক্ত হয় (নিউ হায়ার, ক্যারি-ওভার, আনপেইড, পার্ট-টাইম), মানুষ তাদের ব্যালান্স পূর্বানুমান করতে পারে না।

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

ভুল 2: এমন অনুমোদন ফ্লো যা অনির্দিষ্টভাবে বিভক্ত হয়

অবিরাম শাখাযুক্ত অনুমোদন পরীক্ষা করা অসম্ভব হয়ে ওঠে, এবং ম্যানেজাররা জানে না কেন অনুরোধ অন্য কারও কাছে গেছে।

একটি নিরাপদ প্যাটার্ন:

• এক ডিফল্ট অনুমোদনকারী (সাধারণত সরাসরি ম্যানেজার)
• এক ঐচ্ছিক দ্বিতীয় অনুমোদনকারী (নিয়ম অনুসারে HR বা বিভাগ প্রধান)
• অনুমোদনকারী আউটলে একটি পরিষ্কার ফলব্যাক (ডেলিগেট বা পরের ম্যানেজার)
• প্রতিটি অনুরোধের জন্য এক চূড়ান্ত অবস্থা (approved, rejected, canceled)

ভুল 3: নীতি টেক্সট এবং গণিত মিশিয়ে রাখা

নীতি টেক্সট মানুষের জন্য (কি গণ্য, কে যোগ্য), গণিতের নিয়ম সিস্টেমের জন্য (রেট, ক্যাপ, রাউন্ডিং, ক্যারি-ওভার)। আলাদাভাবে সংরক্ষণ করুন যাতে আপনি ওয়ার্ডিং বদলে গণনা পরিবর্তন না করে পারেন, এবং গণনা টেস্ট করতে টেক্সট পুনঃলিখতে না হয়।

ভুল 4: সম্পাদনা ও বাতিল রেকর্ড করা হয় না

যদি আপনি অনুরোধ ওভাররাইট করেন, আপনি ব্যালান্স পরিবর্তনের পেছনের “কেন” হারিয়ে ফেলেন।

সবসময় অডিট ট্রেইল রাখুন: কে কী বদলায়, কখন, এবং আগের মানগুলো কী ছিল। AppMaster-এ এটি অনুরোধ ইতিহাস টেবিল এবং Business Process-এ স্ট্যাটাস ট্রানজিশন হিসেবে সহজেই মডেল করা যায়।

ভুল 5: টাইমজোন এবং ছুটিগুলো ভাবা হয় না

টাইম-অফ তারিখ পাড়ি দেয়, কিন্তু অনুমোদন এবং ক্যালেন্ডার এন্ট্রি টাইমস্ট্যাম্প ব্যবহার করে। একটি “নীতি টাইমজোন”-এ নর্মালাইজ করুন এবং কর্মীর লোকাল টাইমজোনও স্টোর করুন। এছাড়া দ্রুত সিদ্ধান্ত নিন পাবলিক হলিডে কি অনুরোধিত দিন কমাবে, এবং সেই নিয়ম ধারাবাহিকভাবে প্রয়োগ করুন।

দ্রুত চেকলিস্ট লঞ্চের আগে

প্রতিটি জন্ୟ ঘোষণার আগে একটি সাধারণ চেক চালান একটি বাস্তব কর্মী, একটি ম্যানেজার, এবং HR থেকে কাউকে নিয়ে। আপনি চান সিস্টেমটি কেবল কাজ করে না, বরং স্বচ্ছ ও সহজবোধ্য লাগে।

এই চেকলিস্টটি আপনার টাইম-অফ অনুরোধ সিস্টেম ডিজাইনের জন্য গেট হিসেবে ব্যবহার করুন:

• ব্যালান্স দৃশ্যমানতা: কর্মী আজকের ব্যালান্স এবং কিভাবে আসন্ন অনুমোদিত অনুপস্থিতি সেটি পরিবর্তন করবে তা দেখতে পারে (তাতে পরে নেতিবাচক ব্যালান্স আবিষ্কার না হয়)।
• নীতি স্পষ্টতা: প্রতিটি নিয়ম প্লেইন ভাষায় লেখা আছে (ক্যারি-ওভার, ব্ল্যাকআউট ডেট, ন্যূনতম নোটিস, অর্ধ-দিন) এবং লজিক সেসব কথার সাথে মেলে।
• সহায়ক ভ্যালিডেশন: যখন অনুরোধ ব্লক হয়, মেসেজ বলছে কী পরিবর্তন করতে হবে (তারিখ, ছুটি ধরন, ঘণ্টা, অনুপস্থিত অ্যাটাচমেন্ট), কেবল “error” বা “not allowed” নয়।
• ম্যানেজার-রেডি অনুমোদন: এক স্ক্রিন থেকে ম্যানেজার অনুমোদন দেয় যথেষ্ট প্রেক্ষাপট (অবশিষ্ট ব্যালান্স, ওভারল্যাপিং টিম অনুপস্থিতি, হ্যান্ডঅফ নোট) এবং পরিবর্তন অনুরোধ করার জন্য দীর্ঘ ব্যাক-এন্ড-ফোরথ দরকার নেই।
• ক্যালেন্ডার ও অডিট: অনুমোদনের সময় ক্যালেন্ডার ইভেন্ট তৈরি ও সিঙ্ক করা হয়, পরিবর্তন ও বাতিলের সময় আপডেট করা হয়, এবং প্রতিটি স্ট্যাটাস পরিবর্তন লগ করা হয় কে এবং কখন করেছে সহ।

একটি দ্রুত, ব্যবহারিক টেস্ট: একটি অনুরোধ তৈরি করুন, অনুমোদন করুন, তারিখ সম্পাদনা করুন, তারপর বাতিল করুন। যদি কোনো ধাপ ভুল ব্যালান্স, স্থির ক্যালেন্ডার ইভেন্ট, বা অজ্ঞাত স্ট্যাটাস রেখে যায়, লঞ্চের আগে তা ঠিক করুন।

AppMaster-এ নির্মাণ করলে, প্রতিটি ধাপকে ব্যবহারকারীর কর্মের নামে লেবেল করুন (Submit, Validate, Route to Manager, Update Balance, Create/Update Calendar, Log Event) যাতে নীতি যেমন বাড়ে আচরণ স্পষ্ট থাকে।

উদাহরণ দৃশ্য: অনুরোধ থেকে ক্যালেন্ডার ইনভাইট পর্যন্ত

নতুন কর্মী মায়া 10ই মার্চ শুরু করে। আপনার সিস্টেম মাসিক অ্যাক্রুয়াল সমর্থন করে, তাই মায়া প্রতি মাসের প্রথমে PTO অর্জন করে। 12ই এপ্রিল তিনি পরের শুক্রবারের জন্য 3 ঘণ্টার আংশিক দিন মেডিকেল অ্যাপয়েন্টমেন্টের জন্য অনুরোধ করেন।

কে কি দেখে তা আলাদা:

• কর্মী (মায়া): বর্তমান ব্যালান্স, এই অনুরোধ কত ঘন্টা ব্যবহার করবে, এবং যদি এটি নেতিবাচক করে তাহলে স্পষ্ট সতর্কতা।
• ম্যানেজার: সংক্ষিপ্ত সারাংশ (তারিখ, ঘণ্টা, কভার নোট) এবং অনুমোদন, প্রত্যাখ্যান, বা ডেলিগেট করার অপশন।
• HR: গণনায় ব্যবহৃত নীতি, অডিট ট্রেইল, এবং নীতি বদলে গেলে রিক্যালক করার উপায়।

মায়া অনুরোধ জমা দেয়। তার ম্যানেজার ছুটিতে আছে, তাই সিস্টেম ডেলিগেশন সেটিং পরীক্ষা করে একটিভ ম্যানেজারের কাছে রুট করে। অ্যাক্টিং ম্যানেজার অনুমোদন দেয়।

অনুমোদনের সময় দুইটি জিনিস ঘটে: অনুরোধটি ব্যবহৃত নীতি ভার্শনের সাথে লক হয়ে যায়, এবং ক্যালেন্ডারে “Maya - PTO (3h)” নামে একটি ইভেন্ট তৈরি হয় সঠিক তারিখ ও সময়ে। মায়া সঙ্গে সঙ্গেই “Approved” এবং ক্যালেন্ডার স্থিতি “Added” দেখে।

জুনে HR বছরের মাঝামাঝি নীতি আপডেট করে (উদাহরণ: 90 দিনের পরে অ্যাক্রুয়াল বাড়ে)। ব্যালান্সগুলো পুনরায় গণনা করা দরকার, কিন্তু পূর্বে অনুমোদিত অনুরোধগুলো নিঃশব্দে পরিবর্তন করা উচিত নয়। সিস্টেম কার্যকর তারিখ থেকে পুনরায় মায়ার বর্তমান ব্যালান্স গণনা করে এবং আগে/পরে মানের অডিট রেকর্ড রাখে।

এক সপ্তাহ পরে মায়া অনুরোধের তারিখ পরিবর্তন করে (অ্যাপয়েন্টমেন্ট সরে গেছে)। যেহেতু ছুটি ইতিমধ্যেই অনুমোদিত ছিল, পরিবর্তন একটি নতুন “Change request” হয়ে যায় যা পুনরায় ডেলিগেটেড অনুমোদকের কাছে যায়। একবার আবার অনুমোদন হলে, বিদ্যমান ক্যালেন্ডার ইভেন্ট আপডেট হয় (সেই একই ইভেন্ট ID), ডুপ্লিকেট হয় না।

এটি AppMaster-এর মত টুলে সহজে মডেল করা যায়: এক অনুমোদন পথ, এক ডেলিগেশন চেক, এক ক্যালেন্ডার create/update ধাপ, এবং একটি আলাদা রিক্যালক অ্যাকশন যা HR চালাতে পারে নীতি বদলালে।

পরবর্তী ধাপ: প্রথম সংস্করণ পাঠান এবং নিরাপদে ইটারেট করুন

টাইম-অফ অনুরোধ সিস্টেম ডিজাইন শেষ করার সবচেয়ে নিরাপদ উপায় হলো একটি ছোট সংস্করণ পাঠানো যা মানুষ বিশ্বাস করতে পারে, তারপর বাড়ানো। একটি নীতি (উদাহরণ: PTO) এবং এক অনুমোদন পথ (কর্মী -> ম্যানেজার) দিয়ে শুরু করুন। যখন সেটি বিরক্তিকরভাবে নির্ভরযোগ্য মনে হবে, তখন পরবর্তী নীতি ধরন, অঞ্চল, বা এজ কেস যোগ করুন।

আরও নিয়ম তৈরি করার আগে, সিদ্ধান্ত নিন কোথায় সত্যের উৎস থাকবে। যদি আপনার HR সিস্টেম মাস্টার রেকর্ড হয়, আপনার অ্যাপটি মূলত যাচাই করবে, অনুমোদন রুট করবে, এবং ফলাফলগুলো সিঙ্ক করবে। যদি আপনার অ্যাপ মাস্টার হয়, তাহলে স্পষ্ট অডিট লগ এবং একটি পরিকল্পনা প্রয়োজন যখন HR ডেটা বদলে (নতুন ম্যানেজার, ডিপার্টমেন্ট স্থানান্তর, টার্মিনেশন তারিখ) কী হবে।

একটি বাস্তবসম্মত প্রথম রিলিজ পরিকল্পনা:

• একটি ছুটি ধরন বাস্তবায়ন করুন একটি পরিষ্কার ব্যালান্স এবং একক অ্যাক্রুয়াল নিয়ম সহ।
• একটি ম্যানেজার অনুমোদন ধাপ এবং একটি HR ওভাররাইড পথ যোগ করুন।
• শুধুমাত্র অনুমোদিত ছুটির জন্য একটি সহজ ক্যালেন্ডার সিঙ্ক তৈরি করুন।
• একটি адমিন স্ক্রিন রাখুন যেখানে নীতি সেটিংগুলো অ-প্রযুক্তিগত মালিকরা পড়তে পারে।
• মৌলিক রিপোর্টিং যোগ করুন: কে বাইরে, এবং আসন্ন অনুপস্থিতি।

প্রতি পরিবর্তনের পরে 5-10টি বাস্তব টেস্ট কেস লিখে পুনরায় চালান। আপনার নিজের দলের ব্যবহার কেসগুলো নিন, বানানো উদাহরণ নয়। উদাহরণ: কেউ বৃহস্পতিবারে শুক্রবার ছুটির অনুরোধ দেয়, কেউ অনুমোদনের পরে তারিখ বদলে, বা ম্যানেজার অনুমোদন দেয় যখন কর্মী ভিন্ন টাইমজোনে আছে।

নো-কোড দিয়ে নির্মাণ করলে, ভিজিবিলিটি বৈশিষ্ট্যগুলো ফিচারের মতই গুরুত্বপূর্ণ। AppMaster-এ আপনি ডেটা মডেল (ছুটি ধরন, ব্যালান্স, অনুমোদন) এবং অনুমোদন ওয়ার্কফ্লো ভিজ্যুয়াল সম্পাদকগুলিতে রাখতে পারবেন, যাতে HR এবং অপস প্রকৃতপক্ষে সিস্টেমে কি হচ্ছে তা পর্যালোচনা করতে পারে। আপনি API-ও প্রকাশ করতে পারেন ক্যালেন্ডার সিঙ্কের জন্য এবং নীতিগুলো বাড়ার সঙ্গে সঙ্গে ক্লিন সোর্স কোড পুনরায় জেনারেট করতে পারেন, যাতে ঝামেলাযুক্ত ফিক্সগুলো ক্রয় না হয়।

প্রথম সংস্করণ স্থিতিশীল হলে, একসময় এক মাত্রা বাড়ান: বেশি নীতি, বেশি রাউটিং নিয়ম, তারপর বেশি ইন্টিগ্রেশন।