مدل های فرآیند در سطح استراتژیک (جلسه ۲)
در جلسه اول از این دوره به معرفی سطح اول چهارچوب کاموندا-BPMN و نکاتی پیرامون آن پرداختیم. در این جلسه قصد داریم طی یک مثال کاربردی، جزئیات بیشتر این سطح را مورد بررسی قرار دهیم.
رابرت به عنوان رییس بخش منابع انسانی به دنبال بهبود روند استخدام در اداره هست. او فرایند استخدام را این طور توصیف میکند:
وقتی که واحد فنی یک موقعیت شغلی میخواهد، این را از طریق ایمیل به ما اطلاع میدهد. اما به جای این کار باید یک فایل اکسل درست کند و در آن توصیف این موقعیت شغلی را وارد کند و همچنین توقعات و …»
در اینجا ما صحبتهای رابرت را قطع میکنیم. زیرا ما میخواهیم جریان کار را بدانیم.
«بله، او اینطور از طریق ایمیل درخواست خود را اعلام میکند و باید سپس نگاه کنم که این نامه را به چه کسی ارجاع دهم. البته این بستگی دارد که چه کسی در حال حاضر بیکار است. اغلب این کار را به کسی که بغل دست من نشسته ارجاع میدهم».
در اینجا نیز باید دوباره صحبت رابرت را قطع کنیم و به او توضیح دهیم که مهمترین قدمهای فرایند را توضیح دهد و از جزئیات چشمپوشی نماید.
«بله خوب این کار ساده است، در واقع ما یک اعلان موقعیت شغلی میکنیم و منتظر درخواست های مرتبط میمانیم. سپس آنها را بررسی و کاندیدای مطلوب را انتخاب و استخدام میکنیم. در اصل کار ما زمانی تمام میشود که کاندیدای موردنظر قرارداد را امضا کند.
اما آیا این روند برای شما جزئیاتی را روشن ساخت؟
با توجه به مثال فوق اطلاعات موجود برای فرآیند زیر کافی هستند:
- به علت نیاز واحد فنی یک موقعیت شغلی اعلام میگردد.
- این موقعیت اعلام و افراد درخواست خودشان را میفرستند، سپس بررسی و استخدام صورت میگیرد.
- فرایند هدف این است که یک شخصی استخدام شود و زمانی که قرارداد منعقد میشود به هدف رسیدهایم.
بر این اساس مدل زیر را که در آن رابرت نیز سریعاً متوجه فرایند شود را میسازیم. فقط در مورد رخداد شرطی که باعث ایجاد فرایند میشود کمی توضیح میدهیم. رخداد پایانی را نیز مخصوصاً در مسیر مربوط به واحد فنی قرار دادهایم تا بر اساس قاعده BPM به صورت بصری نیز نشان دهیم که فرایند از مشتری شروع و اتمام مییابد.
فرآیند استخدام در سطح ۱
به عنوان کسی که BPMN را میشناسد باید یک ناپایداری معنایی در این مدل به نظرتان بیاید. اگر فرض کنیم که یک نشانه توسط فرایند در جریان است، یک مشکل بزرگ با فعالیت «دریافت درخواستها» (مفرد) از یک طرف و «بررسی درخواستها» (جمع) از طرف دیگر خواهیم داشت. اگر تنها یک درخواست دریافت شده باشد، دیگر نمیتوانیم چندین درخواست را بررسی کنیم. این مورد هم از لحاظ محتوایی و هم از لحاظ معنایی ناپایدار است.
اگر «دریافت درخواست» را تغییر بدهیم و آن را جمع ببندیم باز هم مشکل حل نمیشود. زیرا این طور به نظر خواهد رسید که انگار یک درخواست کننده داریم که چندین بار درخواست خود را برای ما میفرستد که این هم طبیعتاً معنادار نخواهد بود.
حال باید چه کار کرد؟
یک مدل و فرم درست از لحاظ ساختاری برای این مدل وجود ندارد یا حداقل برای اینکه مدل را به صورت ساده و قابل فهم نشان دهیم این کار شدنی نیست.
رابرت نسبت به مشکل ما چه چیزی خواهد گفت؟ احتمالاً هیچ چیز، زیرا او اصلا مشکل را تشخیص نداده است. برای او ارتباط بین فعالیتها روشن است و منطق و اصل جریان کار فرایند را در یک نگاه متوجه میشود. در اینجا هدف از سطح ۱ برآورده شده است و لذا از ناپایداری معنایی چشم پوشی میکنیم.
این نحوه نمایش یک ایراد دیگر نیز دارد. در این مدل مشخص نیست که بررسی درخواست ها توسط کارمند بخش فنی نیز صورت میگیرد و تنها توسط بخش منابع انسانی انجام نمیشود. و این نکته ای است که رابرت نیز به عنوان نقطه ضعف در فرایند ما آن را حدس زد. اما از این نقص نیز در سطح ۱چشم پوشی میکنیم، زیرا قرار نیست که فرایند را با جزئیات تمام بررسی کنیم. زمانی که یک فعالیت یا زیر فرایندی را مدلسازی میکنیم که در آن بیش از یک مشارکت کننده حضور دارد، این فعالیت را به مسیری تخصیص میدهیم که برای انجام آن مسئول است.
دومین جلسه از دوره “نحوه مدلسازی فرآیندها” به پایان رسید، در این جلسه در قالب مثالی عملی با مفاهیم سطح ۱ در چهارچوب کاموندا آشنا شدید. از اینکه تا به اینجای کار با ما همراه بودید، سپاسگزاریم.
