مدل های فرآیند عملیاتی (جلسه ۱۸)

زمان تقریبی مطالعه: 10 دقیقه

در ادامه جلسه قبل به بررسی سطح سوم از چهارچوب کاموندا میپردازیم. با ما همراه باشید…..

پیشنهادات کاربردی برای سطح ۲

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

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

بنابراین بسیار بهتر است که رویکرد FPY در دنیای مدرن BPM و به همراه آن در BPMN یکپارچه گردد که در آنها این کدها میتوانند توسط موتور فرایند بصورت ساده، دقیق و در زمان درست اندازه‌گیری شوند. در اینجا ابتدا باید دریابیم که چطور رویکرد FPY در جریان سیستم نشانه‌گذاری «سنتی» مورد استفاده قرار میگیرد. از اینرو در شکل زیر یک مدل فرایند را مشاهده میکنیم که برای آنالیز  FPY مناسب است .

فرایند ترتیبی با اصلاح

در فرایند پیشرو یک «مسیر اصلی» وجود دارد که از چپ بالا به پایین منجر به فرستادن نتیجه میشود. زمانیکه نتیجه میبایست اصلاح شود، یک «مسیر اصلاحی» جریان مییابد. از آنجاییکه مسیر اصلی راهی را نشان میدهد که برای ما بعنوان مدیر پروژه مطلوب است، آن را بعنوان «مسیر شاد» مینامیم. احتمال اینکه این نتیجه درست نباشد و نیاز به اصلاح داشته باشد، بنا به مدل  %۳۰ است. و بطور بالعکس در %۷۰ مواقع لایه‌های فرایند میتوانند بدون نیاز به اصلاح با استفاده از روشهای آنالیز مختلف کدهای فعالیتها مانند زمان سیکل میتوانند ارزیابی شوند تا بعنوان یک معیار برای شاخص عملکرد کلیدی KPI مورد استفاده قرار گیرند.

در این مثال ساده میتوان در مورد زمان سیکل فرایند سه حالت را در نظر گرفت:

■ بازده اولین مسیر:  ۸۰دقیقه

■ بدترین حالت:  ۱۱۰دقیقه

■ متوسط:  ۸۹دقیقه

متوسط زمان در این مثال از روش زیر بدست می‌آید

  ۰٫۷*FYP +بدترین حالت * ۰٫۳= ۵۶+۳۳=۸۹ دقیقه. این نوع محاسبه را «محاسبه ترکیبی» مینامیم که در آن برای سادگی کار محاسبات بصورت مرحله به مرحله انجام نمیگیرد. در اینجا فرض میکنیم که اصلاح نتیجه به ازای هر سطح اگر لازم باشد تنها یکبار صورت میگیرد. اگر مایل هستید در مورد این روش بیشتر اطلاعات کسب کنید روش استاندارد فیشرمانس را پیشنهاد میدهیم. حال این سوال مطرح میشود که

آیا میتوان رویکرد FPY را در BPMN بکار برد؟

در اصل این کار امکانپذیر است و ما نشان دادیم که چطور میتوان کدها و زمانهای سیکل را در BPDها قرارداد و آن را برای محاسبات منظور کرد. در مثال موردی «اعلان موقعیت شغلی» دو حلقه اصلاحی وجود دارد که تحت شرایطی اجرا خواهند شد:

1. خبر موقعیت شغلی هنوز برای کرستین به صورت کامل بیان نشده و او باید برای اطمینان با فالکو تماس بگیرد. در اینجا فرض میکنیم که در مدل این کار تنها برای یکبار لازم و ضروری است.
2. شرح شغل نوشته شده فالکو را راضی نمیکند و لذا از کرستین درخواست میکند که آن را اصلاح نماید. این حلقه با توجه به مدل فرایند و از لحاظ تئوری میتواند تا ابد ادامه داشته باشد. اما ما میخواهیم که در ارزیابی کدها از رویکرد مرحله ای استفاده نکنیم.

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

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

این اطلاعات از فرایندی منتج میشود که درمجموع خودشان مدلسازی شده است:

1. موتور فرایند میتواند زمان سیکل فعالیتهای «شرح موقعیت شغلی،» «بررسی شرح شغل،» «اصلاح شرح شغل،» « تایید شرح شغلی» و زیر فرایندهای «اعلان موقعیت شغلی» را اندازه گیری نماید.
2. هم چنین میتواند اندازه گیری نماید که چند بار شرح شغلی باید اصلاح شود. کدها را میتوانید با استفاده از موتور گزارش دهی و هم چنین مایکروسافت اکسل با توجه به لایه های فرایند ارزیابی کنید، مقدار متوسط آنها را بدست آورید و دیاگرام مربوطه را ایجاد و به مدیریت ارشد ارائه نمایید.

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

اما سه امکان وجود دارد که با این اشتباهات برخورد کرد:

1. از این اشتباهات بصورت دانسته چشم‌پوشی میکنید، زیرا میدانید که این اشتباه میتواند زمان سیکل «شرح موقعیت شغلی» را محدود کند.
2. به صورت دستی مقدار این موارد ضروری و میانگین زمان را محاسبه میکنید و آنها را در داده ها به صورت دستی وارد میکنید. اما در اینجا معایبی که در مدیریت فرایند سازمان به صورت سنتی هستند نیز وجود دارد.
3. شما تعیین میکنید که تقاضای خبر موقعیت شغلی که ناواضح است مانند جریان کار نیروی انسانی در موتور فرایند تصویر گردد. سپس میتوانید زمان ها و مقادیر را به صورت مختلف اندازه گیری و بررسی نمایید. خطر این کار این است که فالکو و کرستین از این ایده کمتر استقبال خواهند کرد و احتمال اینکه توضیح در مورد کار در آینده از طریق موتور فرایند انجام نشود زیاد است. زیرا تماس تلفنی در این چنین مواقعی موثرتر خواهد بود. همانطور که مشاهده میکنید، خودکارسازی فرایند نیز برای کنترل فرایند یک ابزار بسیار قوی محسوب میشود. علاوه بر این مشخص است که BPMN به ما کمک میکند که دقیقاً این مرزها را به موقع شناسایی کنیم و خود را با آن وفق دهیم.

از طرف دیگر باید این مسئله را مشخص سازیم که BPMN در اصل پشتیبانی کافی برای آنالیز فرایند بر پایه کدها را ارائه نمیدهد. این کار ابتدا از طریق یک ابزار BPMN قدرتمند امکان پذیر میباشد که کدها را در حالت ایده آل از موتور فرایند دریافت کند و بتواند با استفاده از مدل های فرایند پایدار برای آنالیزهای فنی ترکیب نماید.

مدلسازی کامل خطاها

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

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

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

تایید سفارش در «مسیر شاد»

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

1. اطلاعات سفارش ناقص هستند.
2. اطلاعات سفارش ناخوانا هستند.
3. شماره مشتری در سفارش اشتباه است.
4. مشتری اعتبار کافی را ندارد.

 .۵٫ کالای سفارش داده شده قابل تحویل نیست.

6. هنگام فکس درخواست در انتها یک کسی تلفن را بر میدارد و میگوید دستگاه فکس کار نمیکند.

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

نمایش احتمالی مشکلات در فرایند

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

نمایش گزینه های احتمالی برای «مسیر شاد»

■  اطلاعات سفارش ناقص هستند.

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

■ اطلاعات سفارش ناخوانا هستند.

چطور کامل بودن اطلاعات سفارش میتواند بررسی گردد درحالیکه ناخوانا هستند؟ مانند سناریو اول کاملا واضح نیست اما ما گزینه «بله» را انتخاب میکنیم. اگر نمیتوانیم اطلاعات را بخوانیم، مشخص نیز نمیباشد که چرا اطلاعات ناقص هستند. ضمن اینکه نباید فراموش کنیم که به مشتری در حالت های مختلفی خبر میدهیم اگر سفارش را رد کنیم.

■ شماره مشتری در سفارش اشتباه است.

آیا این مورد برای تایید سفارش یک مشکل محسوب میشود؟ احتمالاً، به خصوص زمانی که بخواهیم اعتبار را بررسی نماییم و اطلاعات مشتری را از سیستم  CRMفرا بخوانیم. در این حالت اطلاعات اشتباه وارد سیستم میکنیم و خبری که دریافت میکنیم این است که مشتری در سیستم یافت نشد. شاید هم اطلاعات مشتری دریافت شود اما این اطلاعات با فرم سفارش مطابقت نکند. سپس پی میبریم که شماره مشتری اشتباه است و فعالیت «بررسی اعتبار» نمیتواند با موفقیت انجام شود. یک موقعیت واضح برای یک رخداد خطا متصل شده.

■ مشتری اعتبار کافی ندارد.

بررسی اعتبار موفق آمیز بوده است اما نتیجه آن در پس تایید درخواست است. لذا از دروازه  XORدر پشت فعالیت استفاده میکنیم.

■ کالای سفارش داده شده قابل تحویل نیست.

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

■ هنگام فکس درخواست در انتها یک کسی تلفن را بر میدارد و میگوید دستگاه فکس کار نمیکند.

نوع نمایش این مورد را احتمالاً خودتان میتوانید حدس بزنید. شاید از خودتان سوال کنید که چرا باید بین رخدادهای خطا و دروازههای  XORتفاوت قائل شد. به جای آن تمام موقعیت های خطا را مانند دیگر روشهای نشانه گذاری فرایند با دروازه XORنمایش داد. در اصل میتوانید این کار را انجام دهید و  BPMNمحدودیتی را قائل نمیشود. اما این تفاوت را بنا به دلایل ذیل پیشنهاد میکنیم:

■ زمانی که فرایند در حالت  SOLL نمایش داده میشود.

اکثر افراد تنها به قسمتی از مسائل احتمالی فکر میکنند، و این دقیقاً همان قسمتی است که آنها در «فعالیت بررسی» و دروازه های  XORمدلسازی میکنند. سپس زمانی که فرایند بایستی به صورت تکنیکی اجرا شود، سوالات در مورد مشکلات احتمالی از  ITبه وجود میآیند، درحالی که قبل از آن بروی این مشکلات احتمالی حسابی باز نشده است. این سوالات تقریبا همیشه این موقعیت را شامل میشوند که فعالیتهای مشخص و هم چنین«فعالیت بررسی» نمیتوانستند به صورت موفقیت آمیز اجرا شوند. در چهارچوب این پاس کاری اجباری بین کسب و کار و  IT این سوالات را با رخدادهای خطای متصل شده مستندسازی میکنیم. آن وقت میتوانیم به این سوالات به صورت هدفمند پاسخ دهیم که اغلب یک فعالیت بررسی در پس یک دروازه  XORنیز قرار میگیرد. برای مثال میتوان قبل فعالیت «تعیین زمان تحویل» فعالیت «بررسی موجود بودن کالا» را قرارداد که باعث میشود رخداد خطا هنگام تعیین زمان تحویل کم شود.

■ با استفاده از رخدادهای خطا میتوانیم فرایندها را بیمه نماییم.

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

■ دروازه‌های XOR یک حالت کلی هستند تا تفاوتهای موردی را نشان دهند.

اینها میتوانند با خطاها در ارتباط باشند اما میتوانند تفاوت های مثبتی را نیز داشته باشند، برای مثال مراحل مشخصی که وابسته به نوع کالای سفارش داده شده هستند. این بدان معنا است که یک «مسیر شاد» نیز همیشه بدون دروازه های  XOR نیست. اما اینچنین دروازه های  XOR مثبتی را نمیتوان از دروازه های XOR تا برطرف کردن خطا از لحاظ ساختاری تمیز داد. بنابراین رخدادهای خطا از لحاظ بصری واضح تر هستند و با ابزار مناسب میتوانیم آن را حتی از دید «مسیر شاد» ساده شده و از دید یک فرایند کامل تغییر وضعیت داد. خلاصه اینکه رخدادهای خطا میتوانند ابزار بسیار مفیدی برای مدلسازی فرایند باشند و باید از آنها استفاده نمود.

هجدهمین جلسه از دوره “نحوه مدلسازی فرآیندها” به پایان رسید. از اینکه تا به اینجای کار با ما همراه بودید، سپاسگزاریم.

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

———————————————————————————————————————————————————————————————————–

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