چطور یک اپ مدیریت مرخصی منابع انسانی بسازیم: درخواست‌ها، تأییدها و موجودی

یک اپ مدیریت مرخصی جای صفحه‌گسترده و زنجیره ایمیل‌هایی را می‌گیرد که پشت پرسش «می‌توانم جمعه مرخصی بگیرم؟» هستند. کارمندان مرخصی درخواست می‌دهند و موجودی باقی‌مانده خود را می‌بینند؛ مدیران با دیدن تقویم تیم تأیید یا رد می‌کنند؛ منابع انسانی انواع مرخصی، سهمیه‌ها و تعطیلات رسمی را تنظیم می‌کند و یک سابقه مرتب برای حقوق و دستمزد دارد. برای ساخت آن به یک مدل داده نیاز دارید که در آن موجودی‌ها از روی تاریخچه درخواست‌ها و تعدیل‌ها محاسبه می‌شوند، یک زنجیره تأیید روشن، و قواعدی برای روزهای نیمه، آخر هفته و تعطیلات. یک ابزار ساخت اپ با AI می‌تواند سریع نسخه کاری تولید کند. دقت لازم در محاسبه موجودی، دسترسی‌ها برای انواع مرخصی حساس، و تطبیق با سیاست واقعی شماست.

اپ به چه چیزهایی نیاز دارد

داده‌ها

قاعده کلیدی: هرگز موجودی‌ای را که دستی ویرایش می‌کنید ذخیره نکنید. موجودی برابر است با سهمیه + انتقال از سال قبل + تعدیل‌ها − روزهای تأییدشده. هر تغییر یک رکورد با دلیل دارد، تا وقتی کسی می‌پرسد «چرا ۳٫۵ روز باقی دارم؟» بتوانید نشانش دهید.

صفحه‌ها

• کارمند: موجودی من برای هر نوع مرخصی، فرم درخواست، درخواست‌های من با وضعیت، تقویم تیم.
• مدیر: درخواست‌های در انتظار با تقویم تیم در کنار آن، تأیید یا رد با توضیح، موجودی تیم.
• منابع انسانی/مدیر سیستم: کارمندان، انواع مرخصی، سهمیه‌ها، تعطیلات رسمی، تعدیل‌ها، و گزارش‌ها و خروجی‌ها.

دسترسی‌ها

این داده شخصی است و بخشی از آن حساس است. کارمندان درخواست‌های خودشان را می‌بینند و در تقویم تیم فقط می‌بینند که یک همکار «در مرخصی» است — نه چرا. مدیران زیردستان مستقیم خود را می‌بینند. منابع انسانی همه را می‌بیند. مرخصی استعلاجی و سایر انواع حساس باید برای هر کسی جز خود کارمند، مدیرش و منابع انسانی فقط به‌صورت «در مرخصی» نمایش داده شوند. این را روی سرور اعمال کنید؛ کنترل دسترسی بر اساس نقش را ببینید. قوانین حفاظت از داده‌های کارمندان بین کشورها متفاوت است، پس قانون کشور خودتان را بررسی کنید.

تصمیم‌ها و مصالحه‌ها

روز یا ساعت

شمارش بر حسب روز (با نیم‌روز) ساده‌ترین است و با بیشتر تیم‌های اداری سازگار است. شمارش بر حسب ساعت برای کارمندان پاره‌وقت و شیفتی مناسب است، اما هر محاسبه را پیچیده‌تر می‌کند. برای نسخه اول بر اساس شیوه بیان سهمیه‌ها در قراردادهایتان یکی را انتخاب کنید.

سهمیه کامل از ابتدا یا تعلق تدریجی

دادن کل سهمیه سالانه در روز اول سال مرخصی ساده‌ترین روش است. تعلق تدریجی — کسب کسری از روز هر ماه — در برخی کشورها و برای کارمندان جدید رایج است و به محاسبه ماهانه نیاز دارد. تناسب‌سازی برای افرادی که وسط سال استخدام یا جدا می‌شوند در هر حال لازم است.

کدام روزها شمارش شوند

درخواستی از پنجشنبه تا سه‌شنبه باید فقط روزهای کاری را بشمارد، با حذف آخر هفته و تعطیلات رسمی محل کار همان کارمند، و با رعایت الگوی پاره‌وقت. این محاسبه‌ای است که بیشتر از همه احتمال اشتباه دارد، پس آن را با مثال‌های واقعی آزمایش کنید.

زنجیره تأیید

یک تأییدکننده (مدیر مستقیم) برای بیشتر شرکت‌های کوچک کافی است. یک تأییدکننده جایگزین برای وقتی مدیر در مرخصی است و در صورت نیاز یک مرحله دوم برای غیبت‌های طولانی اضافه کنید. تصمیم بگیرید اگر مدیری شرکت را ترک کند با درخواست‌های در انتظار چه می‌شود.

انتقال به سال بعد و پایان سال

سال مرخصی خود را مشخص کنید، تعیین کنید چند روز استفاده‌نشده منتقل شود و آیا روزهای منتقل‌شده منقضی می‌شوند. از AI بخواهید انتقال را به‌عنوان یک سطر جداگانه نشان دهد تا موجودی قابل توضیح بماند.

یک پرامپت اولیه که کار می‌کند

یک اپ داخلی مدیریت مرخصی برای یک شرکت ۴۵ نفره با دفاتر در منچستر (بریتانیا) و دوبلین (ایرلند) بسازید. انواع مرخصی: سالانه (۲۵ روز، کل سال از ابتدا، تا ۵ روز انتقال به سال بعد که در ۳۱ مارس منقضی می‌شود)، استعلاجی (نامحدود، بدون تأیید، فقط برای دیگران به‌صورت «در مرخصی» دیده شود)، بدون حقوق، و سایر. سال مرخصی از ژانویه تا دسامبر است. کارمندان درخواست مرخصی را با تاریخ شروع، تاریخ پایان و نیم‌روزهای اختیاری ثبت می‌کنند و می‌بینند چند روز کاری استفاده خواهد شد — با حذف آخر هفته، روزهای مرخصی پاره‌وقت و تعطیلات رسمی دفتر خودشان. موجودی‌ها از روی سهمیه، انتقال، تعدیل‌ها و درخواست‌های تأییدشده محاسبه می‌شوند و هرگز مستقیم ویرایش نمی‌شوند. مدیران درخواست‌های زیردستان مستقیم خود را با توضیح تأیید یا رد می‌کنند و همزمان تقویم تیم را می‌بینند. منابع انسانی کارمندان، انواع مرخصی، سهمیه‌ها، تعطیلات رسمی و تعدیل‌ها را با دلیل مدیریت می‌کند و مرخصی‌های تأییدشده را به تفکیک ماه به‌صورت CSV برای حقوق و دستمزد خروجی می‌گیرد. نقش‌ها: کارمند، مدیر، منابع انسانی. همه‌چیز در یک پایگاه داده ذخیره شود. رابط ساده و سریع.

مراحل ساخت

1. از سیاست نوشته‌شده خود شروع کنید. اگر نوشته نشده، اول آن را بنویسید — اپ فقط می‌تواند قواعدی را اعمال کند که بتوانید بیان کنید.
2. کارمندان را وارد کنید با مدیر، محل کار و الگوی کاری، معمولاً از یک صفحه‌گسترده. تبدیل صفحه‌گسترده به اپ را ببینید.
3. انواع مرخصی، سهمیه‌ها و تعطیلات رسمی.
4. فرم درخواست با محاسبه روزهای کاری، آزموده‌شده با حداقل ده مورد واقعی: مرخصی که آخر هفته را دربر می‌گیرد، تعطیلات عمومی، کارمند پاره‌وقت، نیم‌روز، مرز سال.
5. جریان تأیید و تقویم تیم.
6. ورود و نقش‌ها، با پنهان کردن انواع مرخصی حساس از همکاران.
7. اعلان‌ها: ایمیل به مدیر هنگام درخواست جدید و به کارمند هنگام تصمیم، از طریق ارائه‌دهنده ایمیل خودتان. ارسال ایمیل از اپ را ببینید.
8. گزارش‌ها و خروجی‌ها برای حقوق و دستمزد.
9. اجرای موازی با صفحه‌گسترده به مدت یک ماه، مقایسه موجودی‌ها، سپس جابه‌جایی.

اشتباهات رایج

• ذخیره عدد موجودی و ویرایش آن. تاریخچه را از دست می‌دهید و هر اختلافی به حدس تبدیل می‌شود.
• شمارش روزهای تقویمی به جای روزهای کاری، یا نادیده گرفتن محل کار کارمند برای تعطیلات رسمی.
• نشان دادن دلیل غیبت همکار به همه. «در مرخصی» در تقویم مشترک کافی است.
• نبود تأییدکننده جایگزین. درخواست‌ها دو هفته معلق می‌مانند چون مدیر در تعطیلات است.
• اجازه دادن به افراد برای لغو مرخصی تأییدشده بدون اطلاع مدیر. لغوها باید به تأییدکننده اعلان بدهند.
• ثابت کردن قوانین امسال در کد. سهمیه‌ها و تعطیلات را به‌صورت داده نگه دارید تا منابع انسانی سال بعد بتواند آن‌ها را ویرایش کند.

وقتی یک محصول آماده بهتر است

اگر می‌خواهید مرخصی به حقوق و دستمزد، قراردادها، ارزیابی عملکرد و گزارش‌های انطباق وصل باشد — یا در چند کشور نیرو دارید — نرم‌افزار منابع انسانی که مدیریت زمان‌های غیبت را دارد معمولاً ارزشش را دارد. این محصولات تقویم تعطیلات و قواعد قانونی هر کشور را نگه می‌دارند، کاری مداوم که در غیر این صورت خودتان باید انجام دهید.

یک اپ سفارشی برای شرکت‌های کوچک و متوسط با سیاستی ساده که فقط می‌خواهند صفحه‌گسترده را کنار بگذارند، برای راه‌اندازی‌های غیرمعمول (تیم‌های شیفتی، فهرست‌های چرخشی، مرخصی مرتبط با پوشش آنکال)، یا به‌عنوان بخشی از یک ابزار داخلی گسترده‌تر در کنار آنبوردینگ و درخواست‌های دیگر منطقی است. برای رویکرد کلی‌تر نحوه ساخت یک ابزار داخلی را ببینید.

ساختن با Mythex

در Mythex سیاست و جریان کار را در چت توصیف می‌کنید و عامل اپ را در پیش‌نمایش زنده می‌سازد، با افزودن یک پایگاه داده Postgres وقتی درخواست‌ها نیاز به ذخیره دارند. می‌توانید همکاران را به فضای کاری Mythex خود دعوت کنید تا در ساخت و بازبینی کمک کنند، و پیش از انتشار پیش‌نمایش را با دو یا سه کاربر واقعی به اشتراک بگذارید — مورد استفاده ابزار داخلی در مستندات دقیقاً همین را پیشنهاد می‌کند. ورود کارمندان و ایمیل‌های اعلان از ارائه‌دهندگان خودتان استفاده می‌کنند؛ Mythex ورود کاربر نهایی یا ارسال ایمیل داخلی ندارد. از حالت برنامه‌ریزی (Plan) استفاده کنید تا محاسبه موجودی پیش از نوشتن هر کدی توافق شود، و از /test برای امتحان درخواست و تأیید.

برای یک پرامپت شروع، قالب‌های ردیاب تأیید یا دایرکتوری تیم را امتحان کنید.

پرسش‌ها