مدل های فرآیند عملیاتی (جلسه ۱۱) | آموزش مدلسازی فرایند با BPMN

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

از سطح ۱ به سطح ۲

قبل از اینکه وارد مدلسازی در سطح ۲ با جزئیات شویم، مدلمان را در سطح ۱ ایجاد نمودیم. در مثال موردی فرایند استخدام میخواهیم مدل را در سطح عملیاتی مدلسازی نماییم.

✔ در قدم اول جریان را کاملا سازمانی بررسی میکنیم.

✔ در قدم دوم بررسی میکنیم که چه چیز موتور فرایند میتواند به بهبود فرایند کمک نماید.

در بخش قبل به این نکته اشاره کردیم که مدلهای فرایند در سطح ۱اغلب از لحاظ معنایی دارای تضادهایی هستند که همین امر ساده سازی مستقیم مدل را غیر ممکن میساخت. کاملا عادی است که این «استراتژی محدوده» فرایند را از دید عملیاتی متمایز نماید.

همچنین میتوانیم فرض کنیم که یک مدل فرایند در سطح ۱ تنها در موارد کمی تغییر میکند. برخلاف آن در سطح ۲ میبایست بروی تغییرات حساب کنیم.

یکی از بحثهای موافق در مورد این موضوع این است که مدلها در این سطح در ساختار پایهای خود نباید از لحاظ اجرای فنی تفاوت داشته باشند.

فرایند استخدام در سطح ۱

در عمل اغلب گزینه بهتری وجود ندارد و بهتر است که مدل را از سطح ۱ به سطح ۲ گسترش دهیم.

✔ این کار شاید خیلی مطلوب به نظر نرسد اما کار اشتباهی نیز نیست و نباید این طور قلمداد شود که دوباره کاری دارد انجام میشود.

✔ همان طور که قبلا اشاره شد، مدل فرایند در سطح ۱ موارد خیلی کمی تغییر پیدا میکند، لذا نباید این طور فکر کرد که حرکت از سطح ۱ به سطح ۲ یک کار اضافی است.

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

در انتها فقط یک نفر انتخاب میشود و موقعیت شغلی را بدست خواهد آورد. مشکل دیگر این است که ما درخواست کننده ها را اصلا نمیشناسیم.

✔ این دو علت این مسئله هستند که چرا درخواست کننده نمیتواند برای یک سطح عملیاتی به عنوان یک مسیر در طول همان مجموعه مانند دیگر شرکت کنندگان نشان داده شود.

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

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

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

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

با این وسیله نشان میدهیم که بخش منابع انسانی نه تنها منتظر درخواست میماند بلکه هر درخواستی که وارد میشود موردبررسی قرار میگیرد. یک دروازه AND را مدلسازی کردیم. با این وسیله نشان میدهیم که بخش منابع انسانی نه تنها منتظر درخواست میماند بلکه هر درخواستی که وارد میشود موردبررسی قرار میگیرد.

شروع به سمت سطح ۲

بررسی کامل سطح ۲ به دلیل مطالب هم از نظر محتوایی و هم از نظر دیاگرامهای فرایند بسیار زیاد و از حوصله این دوره آموزشی خارج است، لذا توضیحات کامل آن را در لینک زیر مشاهده خواهید کرد.