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

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

 

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

در مدیریت فرایند سازمانی یک اصطلاح وجود دارد به نام «بازده اولین مسیر 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. مشتری اعتبار کافی را ندارد.

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0 پاسخ

دیدگاه خود را ثبت کنید

Want to join the discussion?
Feel free to contribute!

Got Something To Say: