مدیریت فرم و فرآیندها

مکانیزاسیون فرآیند ثبت حواله فروش

توضیحات فرآیند

مدل BPMN در ProcessMaker برای فرم «ثبت حواله فروش» به شکل ذیل عمل می‌کند:

مدل BPMN فرآیند «مدیریت سفارش فروش» با Start Event از شخص کارمند فروش با عنوان «فرم تهیه پیش فاکتور اولیه» آغاز می‌شود. پس از تکمیل فرم درخواست جهت بررسی اولیه به مدیرواحد ارسال و پس از بررسی مجدد به کارمند فروش جهت تهیه قرار حواله و فروش ارسال می گردد، پس از Task قرارداد و حواله فروش، یک Exclusive Gateway (XOR) جهت بررسی تائید و یا عدم تائید درخواست و توزیع مسیرهای مختلف قرار گرفته است. سپس درخواست مذکور به صورت سری به کارشناس مالی جهت تنظیم اطلاعات مالی قرارداد، مدیر مالی جهت تائید اطلاعات مالی و مدیرعامل جهت تائید نهایی ارسال می شود، مدیرعامل در این مسیر یک Exclusive Gateway (XOR) را که امکان تعیین آن به کارخانه های مختلف جهت بررسی مدیر کارخانه و انباردار را به کاربر می دهد، نهایتاً درخواست مذکور پس بررسی انباردار، به End Event ختم می شود.

مدل فرآیند ثبت سفارش حواله فروش

قوانین کسب و کار فرآیند

Exclusive Gateway (XOR):

بلافاصله پس از ثبت پیش فاکتور قرار دارد و تنظیم آن، مسیر «نیاز به تأیید مدیر فروش» فعال می‌شود.

Exclusive Gateway (XOR):

در مرحله نهایی تصمیم‌گیری، شرط «نظر مدیر عامل و تعیین کارخانه مذکور)» را مدیرعامل بررسی می‌کند. اگر شرط برقرار باشد، فرآیند به سمت «بررسی مدیرکارخانه» می‌رود.

طراحی فرم ثبت سفارش حواله فروش

فرم «پیش فاکتور فروش کالا» در Process Maker به صورت یک فرم چندبخشی (Multi-section) طراحی شده است. بخش اول شامل فیلدهای «شماره پیش فاکتور» (خودکار یا دستی)، «تاریخ صدور» (DatePicker شمسی با مقدار پیش‌فرض تاریخ روز) و مشخصات فروشنده (شماره ثبت/ملی، تلفن، نام شرکت، کد پستی) است. بخش مشخصات خریدار دارای فیلدهای «نام مشتری»، «کد مشتری» (که با جستجو در پایگاه داده تکمیل می‌شود)، «شماره ملی/ثبت»، «تلفن» و «آدرس» می‌باشد. بخش «مشخصات کالا» از یک Repeating Grid با ستون‌های «کد کالا»، «شرح کالا»، «تعداد»، «قیمت واحد»، «قیمت واحد با مالیات»، «جمع کل»، «جمع مالیات» و «جمع کل با مالیات» تشکیل شده که محاسبات خودکار (قیمت کل = تعداد * قیمت واحد، مالیات = ۹% یا مقدار تعریف شده) با جاوااسکریپت در سمت کاربر انجام می‌شود. بخش «شرایط و نحوه فروش» شامل چک‌باکس‌های گروهی (۵۰% نقدی، غیرنقدی، رسمی، غیررسمی) با قابلیت انتخاب چندگانه است. بخش «صادر کننده پیش فاکتور» یک فیلد متنی یا Dropdown برای نام شخص صادرکننده می‌باشد. بخش «شرایط بسته بندی» شامل گزینه‌های «کارتن»، «یونولیت»، «نایلون» و «توضیحات شرایط فروش» به صورت TextArea است. همچنین اعدادی مانند ۱ تا ۵ در انتها احتمالاً مربوط به اولویت بسته‌بندی یا گزینه‌های از پیش تعریف شده می‌باشد. تمام فیلدها دارای اعتبارسنجی سمت کلاینت (مانند اجباری بودن کد مشتری، مثبت بودن تعداد) و ذخیره‌سازی نهایی به صورت JSON در دیتابیس هستند.

۲۹ فروردین, ۱۴۰۵

مکانیزاسیون فرآیند درخواست فارغ التحصیلی

نمایشگاه فرآیندها

توضیحات فرآیند

مدل BPMN در ProcessMaker برای فرم «درخواست فارغ التحصیلی» به شکل ذیل عمل می‌کند:

مدل BPMN این فرآیند با Start Event «ثبت درخواست فارغ‌التحصیلی» توسط دانشجو آغاز می‌شود. سپس یک User Task «بررسی پرونده توسط کارشناس» قرار دارد که پس از آن یک Exclusive Gateway (XOR) بر اساس کامل بودن مدارک، دو مسیر «اعلام نقص از کارشناس» و «پذیرش» را جدا می‌کند. در مسیر نقص، یک Task «ناقصی مدارک و انجام پذیرش» (احتمالاً به معنی رفع نقص توسط دانشجو) و سپس «تایید تکمیل مدارک» توسط کارشناس تعریف شده است که پس از آن به همان Gateway بازمی‌گردد (حلقه بازخورد). در مسیر پذیرش، فرآیند به صورت موازی یا ترتیبی وارد Task «صدور کارنامه توسط واحد آموزشی» و سپس «بررسی کارنامه توسط کارشناس خدمات آموزش» می‌شود. در ادامه یک Task «فرم بررسی سرپرست آموزش» قرار دارد که تصمیم نهایی را اتخاذ می‌کند. پس از تأیید سرپرست، End Event «پذیرش نهایی و صدور مدرک» فعال می‌شود. تمام مسیرها با Condition Expression روی Sequence Flow‌ها و متغیرهایی مانند {documents_complete}, {advisor_approved} مدیریت می‌شوند. نهایتا اعلان تائید تکمیل مدارک، به دانشجو ارسال می شود.

مدل فرآیند فارغ التحصیلی

قوانین کسب و کار فرآیند

Exclusive Gateway (XOR) گره تصمیم انحصاری پس از Task صدور کارنامه توسط واحد آموزشی» قرار دارد. شرط خروجی:

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

Exclusive Gateway (XOR) گره تصمیم انحصاری پس از Task «بررسی پرونده توسط کارشناس پذیرش» قرار دارد. شرط خروجی:

اگر documents_ok == true، مسیر «پذیرش» فعال می‌شود. در غیر این صورت، مسیر «اعلام نقص از کارشناس پذیرش» فعال می‌گردد. فقط یک خروجی اجرا می‌شود.

Exclusive Gateway (XOR) گره تصمیم انحصاری پس از Task «بررسی پرونده توسط کارشناس خدمات آموزش» قرار دارد. شرط خروجی:

اگر documents_ok == true، مسیر «بررسی سرپرست آموزش» فعال می‌شود. در غیر این صورت، مسیر «اعلام نقص از کارشناس خدمات» فعال می‌گردد. فقط یک خروجی اجرا می‌شود.

Exclusive Gateway (XOR) گره تصمیم انحصاری پس از Task «بررسی پرونده توسط سرپرست آموزش» قرار دارد. شرط خروجی:

اگر documents_ok == true، مسیر «اعلام تائید تکمیل مدارک» فعال می‌شود. در غیر این صورت، مسیر «اعلام ناقصی مدارک و انجام مجدد امور فعال» فعال می‌گردد. فقط یک خروجی اجرا می‌شود.

طراحی فرم فارغ التحصیلی

فرم «درخواست ثبت مدارک فارغ‌التحصیلی» به صورت چندبخشی (Multi-step) در Process Maker طراحی شده است. بخش اول (تکمیل توسط دانشجو) شامل فیلدهای «نام»، «نام خانوادگی»، «رشته تحصیلی»، «مقطع تحصیلی» (Dropdown با مقاطع مختلف)، «شماره دانشجویی» (اعتبارسنجی عددی)، «شماره تماس» (الگوی ۱۱ رقمی) و دو فیلد آپلود فایل: «بارگزاری فایل مربوط به امضای واحدهای مختلف» و «بارگزار فرم تسویه حساب» – هر دو با Allowed extensions: * (همه فرمت‌ها) و محدودیت حجم. بخش دوم (تکمیل توسط واحد صدور کارنامه) شامل فیلد «تعیین وضعیت بررسی» (متن یا انتخاب)، یک چک‌باکس یا رادیو «نیاز به بررسی کارشناس پذیرش دارد» و «توضیحات در صورت لزوم» (TextArea). بخش سوم (تکمیل توسط سرپرست آموزش) شامل فیلد «انتخاب کنید» (تأیید/رد)، «توضیحات» و دکمه «ثبت و ارسال». همچنین یک بخش تکراری «بررسی سرپرست آموزش» در پایین فرم دیده می‌شود که نمایش وضعیت است. تاریخ درخواست به صورت خودکار از سرور دریافت و در فیلد «تاریخ درخواست» (بالای فرم) نمایش داده می‌شود. تمام فیلدهای اجباری با اعتبارسنجی سمت کلاینت و سرور کنترل می‌شوند و داده‌های آپلودی در دیتابیس ذخیره می‌گردند.

۳ فروردین, ۱۴۰۵/0 دیدگاه

مکانیزاسیون فرآیند درخواست ساخت ابزار و تجهیزات

نمایشگاه فرآیندها

توضیحات فرآیند

مدل BPMN در ProcessMaker برای فرم «درخواست ابزار و تجهیزات» به شکل ذیل عمل می‌کند:

مدل BPMN این فرآیند از یک Start Event با عنوان «فرم درخواست ساخت ابزار» آغاز می‌شود که داده‌های اولیه (نقشه، شماره نقشه، واحد درخواست‌کننده، شرح و …) را دریافت می‌کند. پس از تکمیل، جریان وارد یک مسیر سری می‌شود تا سه Task انسانی «فرم بررسی بخش ابزار سازی»، «فرم بررسی فنی مهندسی» و «فرم بررسی واحد تولید» را به صورت مستقل از یکدیگر راه‌اندازی کند. هر یک از این سه Task مسئول تأیید تخصصی در حوزه خود هستند و ممکن است دارای فرم‌های جداگانه با فیلدهای اختصاصی باشند. پس از اتمام هر سه Task و در نهایت پس از تأیید نهایی واحد تولید،End Event داده‌ها را در دیتابیس ثبت کرده و خروجی نهایی (مانند مجوز ساخت) صادر می‌شود.

مدل فرآیند ساخت ابزار و تجهیزات

قوانین کسب و کار فرآیند

در این فرآیند از دو نوع Gateway کلیدی استفاده شده است:

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

طراحی فرم ساخت ابزار و تجهیزات

فرم «درخواست ساخت ابزار تجهیزات» از دو بخش مجزا تشکیل شده است: بخش درخواست‌کننده و بخش ابزارسازی. در بخش اول، فیلد «فایل نقشه» از نوع File Attachment با پشتیبانی از تمام فرمت‌های فایل (Allow all extensions) و حداکثر حجم مشخص است. فیلد «شماره نقشه» یک فیلد متنی با اعتبارسنجی فرمت (مثلاً الگوی عددی-حرفی) می‌باشد. «واحد درخواست‌کننده» از نوع Read Only که و با استفاده از تریگر بر مبنای لاگین کننده، نمایش داده می شود. «شرح درخواست» یک TextArea با قابلیت Rich Text یا ساده است. بخش دوم (ابزارسازی) شامل یک فیلد خدمات واحد مهندسی و ابزارسازی از نوع CheckGroup، و یک جدول (Repeating Grid) با ستون‌های: «خدمات ارائه شده به ابزار سازی» (متن)، «تاریخ تعیین شده جهت ارائه» (DatePicker شمسی)، «تایید مهندسی» (DropDown یا Suggest)، «تایید ابزار سازی» (DropDown یا Suggest) و توضیحات، به عنوان مقدار پیش‌فرض یا نمونه در تصویر نمایش داده شده است. همچنین یک توضیح متنی: «در صورت درخواست اصلاح، قابل به محض دریافت از ابزار سازی نتیجه تست قابل اعلام گردد» به عنوان یک فیلد یادداشت یا قانون تجاری در فرم لحاظ شده است.

۲۶ بهمن, ۱۴۰۴/0 دیدگاه

مکانیزاسیون فرآیند ثبت و امتیاز دهی عملکرد

نمایشگاه فرآیندها

توضیحات فرآیند

مدل BPMN در ProcessMaker برای فرم «ثبت و امتیاز دهی عملکرد» به شکل ذیل عمل می‌کند:

مدل فرآیند «درخواست امتیازدهی کارمندان» با استاندارد BPMN 2.0 در نرم‌افزار Process Maker پیاده‌سازی شده است. المان شروع (Start Event) از نوع «فرم شروع» بوده و داده‌های اولیه شامل پست سازمانی و کد ملی را دریافت می‌کند. سپس یک Task انسانی (User Task) با عنوان «ثبت اطلاعات عملکرد» ظاهر می‌شود که فرم مخصوص به آن متصل است. پس از تکمیل، جریان وارد یک Exclusive Gateway می‌شود که بر اساس مقدار امتیاز مکتسبه (بیشتر از ۸۰ یا کمتر) مسیرهای متفاوتی ایجاد می‌کند. در ادامه یک Parallel Gateway وظیفه ارسال همزمان درخواست به دو نقش «مدیر مستقیم» و «کارشناس منابع انسانی» را بر عهده دارد. هر مسیر دارای یک Task تأیید با ضرب الاجل (Deadline) و رویداد پیگیری (Timer Event) است. پس از جمع‌آوری نتایج، یک Inclusive Gateway شرط «حداقل یک تأیید» را بررسی کرده و در صورت موفقیت، به Task «امتیازدهی نهایی» می‌رود. در نهایت End Event داده‌های نهایی را در پایگاه داده ثبت کرده و گردش کار خاتمه می‌یابد. تمامی مسیرها با Sequence Flow دارای اکسپرشن‌های شرطی (Condition Expression) و متغیرهای فرآیند (Process Variables) مدیریت می‌شوند.

مدل فرآیند ثبت و امتیاز دهی عملکرد

قوانین کسب و کار فرآیند

Exclusive Gateway (XOR) – گره تصمیم انحصاری

این Gateway بلافاصله پس از Task «ثبت اطلاعات عملکرد» قرار دارد و دقیقاً یک خروجی بر اساس شرط زیر فعال می‌شود: اگر متغیر self_assessment_score > 80 باشد، مسیر «بررسی ویژه» به سمت Task «بررسی مدیر ارشد» می‌رود. در غیر این صورت، مسیر «بررسی عادی» به سمت Task «بررسی مدیر مستقیم» فعال می‌شود. شرط‌ها روی Sequence Flow‌ها با عبارت‌هایی مانند {self_assessment_score > 80} تعریف شده و هیچ مسیر پیش‌فرضی (Default Flow) تعریف نشده تا از خطاهای زمان اجرا جلوگیری شود.

Parallel Gateway (AND) – گره موازی

بعد از تأیید مدیر (در هر دو مسیر)، این Gateway به کار گرفته می‌شود تا دو Task «تأیید مدیر واحد» و «تأیید کارشناس منابع انسانی» را به صورت کاملاً همزمان و مستقل از هم شروع کند. هیچ شرطی برای ورود به آن وجود ندارد و خروجی‌ها همگی فعال می‌شوند. فرآیند تنها زمانی از Gateway جمع‌کننده (Joining) عبور می‌کند که هر دو مسیر کامل شده باشند (همگام‌سازی کامل).

Inclusive Gateway (OR) – گره شامل

پس از اتمام دو Task موازی، این Gateway شرط «حداقل یک تأیید» را ارزیابی می‌کند. اگر متغیر manager_approved == true یا hr_approved == true (یا هر دو) باشد، جریان به Task «امتیازدهی نهایی» می‌رود. در غیر این صورت (هر دو رد شده باشند)، جریان به Task «اصلاحیه توسط کارمند» بازگردانده می‌شود.
برخلاف Exclusive Gateway، این Gateway می‌تواند بیش از یک خروجی داشته باشد، اما در این طراحی فقط دو خروجی شرطی با همپوشانی ممکن تعریف شده است.

طراحی فرم ثبت و امتیاز دهی عملکرد

فرم تکمیل عملکرد کارمندان به صورت یک فرم داینامیک HTML/JS در Process Maker طراحی شده و از قابلیت Data Binding برای اتصال مستقیم به فیلدهای دیتابیس استفاده می‌کند. فیلد «پست سازمانی» از نوع Dropdown با منبع داده‌ای (Data Source) متصل به جدول سازمانی (Positions) است. فیلد «کد ملی» از نوع Text با الگوی Regular Expression (^[0-9]{10}$) و پیام اعتبارسنجی سمت کلاینت و سرور است. فیلد «نام و نام خانوادگی» به صورت خودکار پس از وارد کردن کد ملی، از طریق Web Service به LDAP سازمان کوئری زده و مقدار آن پر می‌شود (Auto-complete). جدول ارزشیابی کارکنان یک کنترل Repeating Grid است که هر ردیف شامل هفت ستون متنی («امتیاز مکتسبه»، «تحلیل عملکرد»، «سقف انتظار»، «هدف مورد انتظار» و …) می‌باشد. داده‌های این جدول به صورت آرایه‌ای از اشیاء JSON در متغیر فرآیند ذخیره می‌شود. تاریخ ایجاد درخواست به صورت فقط خواندنی (Readonly) با فرمت jalali (Shamsi) از تابع Server-Side Date دریافت می‌گردد. تمام فیلدها دارای Event Listener (مانند onBlur، onChange) برای محاسبه خودکار مجموع امتیازها و فعال/غیرفعال کردن دکمه ارسال هستند.

۲۳ آذر, ۱۴۰۴/0 دیدگاه

مکانیزاسیون فرآیند درخواست اضافه کار

نمایشگاه فرآیندها

توضیحات فرآیند

مدل BPMN در ProcessMaker برای فرم «درخواست اضافه کاری» به شکل ذیل عمل می‌کند:

مدل BPMN این فرآیند از یک Start Event از نوع «فرم شروع» با عنوان «فرم ثبت درخواست اضافه کاری» آغاز می‌شود که داده‌های اولیه (نام، ساعت شروع و پایان، علت) را دریافت می‌کند. سپس یک User Task به نام «بررسی درخواست توسط مدیر واحد» قرار دارد که نقش انسانی مدیر را مدل می‌کند. پس از این Task، یک Exclusive Gateway (XOR) تعبیه شده است که بر اساس تصمیم مدیر (تأیید یا عدم تأیید) جریان را به دو مسیر مجزا هدایت می‌کند. مسیر «اعلام عدم تایید درخواست» به یک End Event ناموفق منتهی می‌شود. همچنین یک مسیر موازی برای «مشاهده وضعیت درخواست» در نظر گرفته شده است. تمامی Sequence Flow‌ها دارای Condition Expression بر اساس متغیر فرآیند مانند {approved == true} هستند. فرآیند فاقد حلقه بازگشت (Loop) بوده و به صورت خطی با یک گره تصمیم طراحی شده است. از Timer Event یا پیام‌رسانی در این مدل استفاده نشده و ساده‌ترین شکل گردش کار درخواست‌محور پیاده‌سازی شده است.

مدل فرآیند اضافه کاری

قوانین کسب و کار فرآیند

در این فرآیند تنها از یک Exclusive Gateway (XOR) استفاده شده است که پس از Task «بررسی درخواست توسط مدیر واحد» قرار گرفته است. این Gateway دقیقاً یک خروجی را بر اساس مقدار متغیر فرآیند decision فعال می‌کند. قوانین تعریف شده روی Sequence Flow خروجی به شرح زیر است:

اگر decision == "approved" یا approved == true، مسیر «اعلام تایید درخواست» انتخاب شده و فرآیند با موفقیت پایان می‌یابد.
اگر decision == "rejected" یا approved == false، مسیر «اعلام عدم تایید درخواست» فعال شده و فرآیند به پایان ناموفق می‌رسد.

هیچ مسیر پیش‌فرض (Default Flow) تعریف نشده است تا در صورت عدم تطابق شرط‌ها، خطای زمان اجرا رخ دهد و فرآیند متوقف شود. این Gateway از نوع انحصاری بوده و امکان همزمانی وجود ندارد. همچنین گره جمع‌کننده (Joining Gateway) نداریم زیرا پس از آن دو End Event مجزا قرار گرفته‌اند.
برای مشاهده وضعیت درخواست یک Parallel Gateway جهت ارسال موازی به کارتابل درخواست کننده و اداری استفاده شده است.

طراحی فرم اضافه کاری

فرم «ثبت درخواست اضافه کاری» به صورت یک فرم داینامیک در Process Maker با قابلیت اعتبارسنجی سمت کاربر و سرور طراحی شده است. فیلد «نام و نام خانوادگی» از نوع Text با ویژگی Readonly یا Auto-fill است که به طور خودکار از داده‌های کاربر وارد شده در سامانه (Session Variables) مقداردهی می‌شود. دو فیلد «ساعت شروع» و «ساعت پایان» از نوع DateTime با فرمت زمان (مثلاً HH:MM) و کنترل تقویم شمسی هستند. یک قانون تجاری (Business Rule) در رویداد onBlur این فیلدها تعریف شده که مدت زمان اضافه کاری را محاسبه کرده و در صورتی که کمتر از ۳۰ دقیقه یا بیشتر از ۴ ساعت باشد، خطای اعتبارسنجی نمایش می‌دهد. فیلد «علت درخواست» از نوع TextArea با حداکثر ۵۰۰ کاراکتر و امکان اعتبارسنجی محتوا (عدم وجود کاراکترهای غیرمجاز) است. دکمه «ثبت و ارسال به مدیر واحد» پس از تکمیل همه فیلدها فعال می‌شود و با کلیک، داده‌ها را به صورت یک شیء JSON به متغیر فرآیند ارسال کرده و فرم را می‌بندد. همچنین یک فیلد پنهان (Hidden) به نام request_time وجود دارد که زمان ثبت درخواست را از سرور دریافت و در پایگاه داده ذخیره می‌کند.

۶ تیر, ۱۴۰۴

مهارت‌های لازم برای طراحی فرآیند در نرم‌افزار BPMS فراگستر

برای طراحی فرآیندهای سازمانی در نرم افزار مدیریت فرآیند فراگستر (BPMS) به چه مهارت هایی نیاز داریم؟

اتوماسیون اداری, مدیریت فرم و فرآیندها

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

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

ادامه مطلب

۴ تیر, ۱۴۰۴/0 دیدگاه

مکانیزاسیون فرآیند درخواست مرخصی

نمایشگاه فرآیندها

توضیحات فرآیند

مدل BPMN در ProcessMaker برای فرم «درخواست درخواست مرخصی» به شکل ذیل عمل می‌کند:

مدل BPMN فرآیند «درخواست مرخصی» با یک Start Event از نوع «فرم شروع» شامل فیلدهای نام، جانشین، تاریخ شروع/پایان، نوع مرخصی (ساعتی/روزانه) و ساعت زمانی آغاز می‌شود. سپس یک User Task به نام «بررسی توسط مدیر واحد» قرار دارد که درخواست را تأیید یا رد می‌کند. پس از آن یک Exclusive Gateway (XOR) بر اساس تصمیم مدیر، مسیر «تأیید» یا «رد» را فعال می‌کند. مشابه همین مسیر برای مدیرعامل نیز جهت تائید وجود دارد، که نهایتاً در صورت تائید درخواست به شخص درخواست کننده، اعلامیه تائید مرخصی ارسال می شود و در صورت عدم تائید درخواست، مسیر فرآیند وارد یک Parallel Gateway شده که اقدام به اطلاع عدم تائید درخواست به مدیر واحد و شخص درخواست کننده می کند. در نهایت End Event موفق، داده‌ها را در جدول مرخصی ذخیره کرده و وضعیت را به روز می‌کند. تمام مسیرها دارای Condition Expression بر اساس متغیرهایی مانند {manager_approved}, {balance_ok} هستند.

مدل فرآیند مرخصی

قوانین کسب و کار فرآیند

Exclusive Gateway (XOR) – گره تصمیم انحصاری: پس از Task «بررسی مدیر مستقیم» و «بررسی مدیرعامل» قرار دارد. اگر متغیر manager_approved == true، مسیر «تأیید» فعال شده و در غیر این صورت مسیر «رد» فعال می‌گردد. فقط یکی از دو خروجی اجرا می‌شود. هیچ مسیر پیش‌فرضی تعریف نشده تا در صورت عدم تطابق، خطای زمان اجرا رخ دهد.

Parallel Gateway (AND) – گره موازی: در صورت عدم تائید مدیرعامل در مدل مذکور، درخواست به صورت موازی بین درخواست کننده و مدیر واحد توزیع می شود.

طراحی فرم مرخصی

فرم «ثبت درخواست مرخصی» به صورت داینامیک در Process Maker با قابلیت اتصال به دیتابیس کارکنان طراحی شده است. فیلد «نام و نام خانوادگی» به طور خودکار از متغیر جلسه (Session) مقداردهی شده و فقط خواندنی است. فیلد «نام جانشین» از نوع Dropdown با منبع داده‌ای از جدول کاربران سازمان (به جز خود شخص) و با قابلیت جستجو (Searchable) می‌باشد. دو فیلد «تاریخ شروع» و «تاریخ اتمام» از نوع DatePicker شمسی با مقدار پیش‌فرض (امروز) و اعتبارسنجی «تاریخ پایان نباید از تاریخ شروع کوچک‌تر باشد». فیلد «ساعت زمانی» فقط در صورت انتخاب نوع مرخصی «ساعتی» فعال می‌شود (کنترل شرطی با جاوااسکریپت) و نوع آن Time Picker با گام ۳۰ دقیقه است. فیلد «نوع مرخصی» از نوع Radio Button با دو گزینه «ساعتی» و «روزانه» که با تغییر آن، محاسبه خودکار تعداد روز/ساعت انجام می‌شود. دکمه «ثبت درخواست» پس از اعتبارسنجی کامل (تکمیل جانشین، تاریخ‌ها، و ساعت در صورت نیاز) فعال می‌شود. یک فیلد پنهان به نام request_date زمان ثبت درخواست را از سرور دریافت می‌کند. همچنین یک قانون تجاری (Business Rule) برای بررسی عدم تداخل مرخصی با مرخصی‌های دیگر (با کوئری به دیتابیس) در سمت سرور پیاده‌سازی شده است.

۲۰ خرداد, ۱۴۰۴

مکانیزاسیون فرآیند درخواست جذب و استخدام

نمایشگاه فرآیندها

توضیحات فرآیند

مدل فرآیند «درخواست جذب و استخدام» با استاندارد BPMN 2.0 در نرم‌افزار Process Maker پیاده‌سازی شده و به شکل ذیل عمل می‌کند:

فرآیند بر اساس Laneها و Poolها طراحی شده تا هر واحد سازمانی (مثل مسئول دفتر، مدیر بخش، مدیرعامل، واحد منابع انسانی و مالی) نقش و وظایف مشخصی داشته باشد.
جریان کار با یک Start Event آغاز می‌شود و داده‌های اولیه از طریق «فرم استخدام» وارد Data Model فرآیند می‌گردد.
در هر مرحله، یک User Task برای بررسی یا تأیید ایجاد می‌شود؛ در صورت نیاز به اصلاح، با استفاده از Gatewayها (Exclusive Gateway) مسیر به سمت فعالیت اصلاح فرم برمی‌گردد.
در گام‌ مدیرعامل، در صورت عدم تائید درخواست، با استفاده از Parallel Gateway، درخواست به صورت موازی به مدیربخش و شخص مسئول دفتر، اطلاع رسانی می گردد.
پس از تأیید نهایی، داده‌ها به واحد منابع انسانی منتقل می‌شود، قرارداد ثبت می‌شود و جریان به سمت تعیین کد پرسنلی پیش می‌رود.
فرآیند در پایان با End Event بسته می‌شود و همه مسیرها چه موفق، چه رد یا عدم تأیید به این نقطه ختم می‌شوند.

مدل فرآیند جذب و استخدام

قوانین کسب و کار فرآیند

Gateway بررسی رزومه توسط مدیر بخش (XOR)

در این Gateway تصمیم گرفته می‌شود که رزومه از نظر مدیر بخش قابل قبول است یا خیر.

قواعد کسب‌وکار:

Gateway بررسی اولیه توسط مدیرعامل (XOR)

این گیت‌وی وضعیت تأیید یا رد درخواست را مدیریت می‌کند.

قواعد کسب‌وکار:

اگر مدیرعامل تأیید کند → مسیر «تأیید» فعال شده و پرونده برای بررسی مدارک به منابع انسانی ارسال می‌گردد.
اگر مدیرعامل عدم تأیید بدهد → مسیر «عدم تأیید» فعال می‌شود و اطلاع‌رسانی به مدیر بخش و مسئول فنی انجام می‌شود و فرآیند به پایان می‌رسد.

Gateway بررسی مدارک توسط منابع انسانی (XOR)

قواعد کسب‌وکار:

اگر مدارک کامل باشد → مسیر «قبول» فعال می‌شود و کار به واحد مالی جهت بررسی نهایی منتقل می‌شود.
اگر مدارک ناقص باشد → مسیر «رد» یا «نیاز به اصلاح» فعال شده و پیام اصلاح به متقاضی یا بخش مربوطه ارسال می‌گردد.

Gateway بررسی مدارک توسط مالی (XOR)

قواعد کسب‌وکار:

اگر مدارک و شرایط مالی مطابق ضوابط باشد → مسیر «تأیید» فعال می‌شود و قرارداد صادر و امضا می‌گردد.
اگر مغایرت وجود داشته باشد → مسیر «عدم تأیید» فعال می‌شود و فرآیند با اعلام نتیجه به واحد منابع انسانی بسته می‌شود.

Gateway پس از امضای قرارداد (XOR)

در این مرحله تعیین می‌شود که آیا مجوز تعیین کد پرسنلی صادر شده است یا خیر.

قواعد کسب‌وکار:

طراحی فرم جذب و استخدام

در این فرم «فرآیند درخواست جذب و استخدام» در Process Maker از مجموعه کامپوننت‌ها مثل PersianDatePicker (برای فیلدهای تاریخ)، Textbox (برای فیلدهای متنی مثل نام/نام خانوادگی)، Dropdown (انتخاب‌های کنترل‌شده مثل وضعیت‌ها/گزینه‌ها)، و TextArea (برای توضیحات و متن‌های طولانی) استفاده شده است. برای جلوگیری از ثبت اطلاعات ناقص، روی فیلدها Validation‌هایی مانند اجباری بودن، محدودیت طول/فرمت و اعتبارسنجی عددی/متنی تعریف شده و همچنین برای برخی فیلدها Default Value تعیین شده تا رفتار فرم استاندارد و قابل‌پیش‌بینی باشد. علاوه بر آن، Placeholder برای راهنمایی کاربر در زمان ورود داده‌ها ست شده و باعث کاهش خطای کاربر در تکمیل فرم می‌شود. در بخش UI، استایل‌دهی به کمک CSS و با هدف بازسازی ظاهر فرم، با کدهای jQuery (برای کنترل کلاس‌ها، همسان‌سازی استایل کامپوننت‌ها، و اعمال رفتارهای ظاهری/تعاملات) انجام شده است. همچنین ساختار فرم به شکل قابل‌گسترش طراحی شده تا فیلدها و لیبل‌ها به‌صورت منظم و هم‌راستا نمایش داده شوند و کاربر تجربه یکپارچه‌تری داشته باشد.

۱۵ اردیبهشت, ۱۴۰۴