مدل های فرآیند عملیاتی (جلسه ۱۴)
زمان تقریبی مطالعه: 5 دقیقه
اکنون ما در سطح سوم از چهارچوب کاموندا قرار داریم. در این مرحله باید به مهندس فرایند مراجعه کنیم و به او توضیح دهیم که چطور فرایند باید در موتور فرایند به کار گرفته شود….
فرایندهای ضروری موتور فرایند
ما الآن در مرز سطح ۳ قرار داریم. به عنوان آنالیزور فرایند از اینجا دیگر با مشارکت کنندگان فرایند صحبت نمیکنیم، بلکه به جای آن به مهندس فرایند مراجعه میکنیم. برای او توضیح خواهیم داد که چطور فرایند در موتور فرایند باید به کار گرفته شود تا پشتیبانی مشخص شده را تضمین نماید. برای این منظور در دیاگرام همکاری، مجموعه مشارکت کنندگان انسانی را قابل روئیت میگذاریم و مجموعه موتور فرایند را به عنوان دیگر شرکت کنندگان باز میکنیم.
این کار را در سه مسیر تقسیم مینماییم:
■ هر مسیر برای مدیریت بخش فنی و کارشناس واحد منابع انسانی. تمامی فعالیت هایی که در این مسیرها قرارداده میشوند، فعالیتهای کاربران هستند و لذا نشان دهنده وظایف کاری افراد.
■ یک مسیر دیگر برای قدمهای کامل خودکار شده. اینجا در مورد فعالیت هایی مانند کارهای خدمت رسانی یا کارهای مربوط به برنامه های داخلی است و تمامی زیر فرایندها ۲۱۳ مدل های فرآیند عملیاتی میتوانند قرارداده شوند.
مراحل فرایندهایی که در موتور میبایست بکار گرفته شوند از رفتار کاربران یعنی فالکو و کریستین به وجود میآید:
فرایند آغاز میشود، زیرا فالکو فرم مربوطه را جهت یک موقعیت شغلی در پرتال تکمیل کرده و فرستاده است. این مورد توسط رخداد آغازین از نوع «خبر» نشان داده میشود. موتور فرایند فعالیت «شرح موقعیت شغلی» را به کرستین میسپارد. بعد از اتمام این فعالیت موتور میتواند فعالیت «بررسی شرح شغلی» را به فالکو بسپارد. نتیجه این فعالیت این است که شرح شغلی یا تا اید یا برای اصلاحات فرستاده میشود. موتور فرایند نیز بسته به نتیجه کار یا «شرح شغلی» را برای اعلان میفرستد یا آن را برای «اصلاح» تخصیص میدهد. در صورت اصلاح، شرح مربوطه دوباره به فالکو برای بررسی فرستاده میشود. این حلقه آنقدر تکرار میشود تا شرح مربوطه تایید گردد.
فعالیت اعلان آگهی که کرستین بعد از تایید آگهی بدست میآورد، یک کانالی را در خود دارد که از طریق این کانال موقعیت شغلی میبایست اعلام گردد. سپس زیر فرایند «اعلان موقعیت شغلی» انجام میگیرد. این کار را به عنوان زیر فرایند انجام میدهیم تا دیاگرام خیلی بزرگ نشود. در آخرین مرحله هم موتور یک نامه تاییدیه برای هر دو شرکت کننده ارسال میکند تا آنها را در جریان اجرای موفقیت آمیز اعلان آگهی قرار دهد.
دیاگرام همکاری در شکل زیر دربردارنده یک فرایند است که میتوان آن را در موتور فرایند به کار گرفت. این کار البته اضافی است، زیرا از یک طرف کاربر به عنوان مجموعه های شخصی نمایش دادهشده است و به طور همزمان به عنوان مسیرهایی درمجموع موتور فرایند.
در این مورد به یک اختلاف مهم در مسئولیتها میرسیم: تمامی تصمیمات در مورد مسیر در طول یک مجموعه و یا به عبارتی سوال در مورد اینکه کدام مسیر دروازه XORانتخاب میشود، توسط هرکدام از شرکت کننده ها برآورده میشــود. برای مثال کرستین تصمیم میگیرد که آیا او میتواند موقعیت شغلی را مستقیماً شرح دهد یا باید به علت نکات نامفهوم از فالکو سوال کند. این تصمیم را موتور فرایند نمیتواند بگیرد زیرا آن را درک نخواهد کرد
از طرف دیگر موتور فرایند تصمیم می گیرد که آیا کرستین باید در ادامه فعالیت اصلاح شرح شغل یا اعلان آن را انجام دهد. دروازه XOR مرتبط با آن در مجموعه خودش قرار دارد. طبیعتاً موتور فرایند این تصمیم را به علت نظری که پیشتر فالکو اعلام کرده می گیرد. اما تصمیم آخر را که چه چیز در ادامه اتفاق می افتد را موتور می گیرد.
در اینجا یکی از مشکلات رایجی که هنگام حرکت از مدل فرایند فنی به تکنیکی رخ می داد بر طرف گردید. فرایند در موارد کمی به صورت پایان به پایان کامل می گردد و با جزئیات توسط یک موتور فرایند هدایت می شود. این کار منجر به بخش هایی می شود که در آن ها یک فرد کنترل را در دست و تصمیم وقتی ما بخواهیم این کنترل ها را (موتور فرایند از یک طرف و مشارکت کنندگان انسانی فرایند از طرف دیگر) در یک مجموعه با یکدیگر ترکیب نماییم، سادگی در مدل فرایند تکنیکی و قابل اجرا غیر ممکن است.
علاوه بر این مثل قبل محدوده گروه های هدف را داریم:
- آنالیزور فرایند کل دیاگرام همکاری را مشاهده می کند.
- مهندس فرایند تنها مجموعه موتور فرایند را مشاهده می کند.
- مشارکت کنندگان فرایند تنها مجموعه خودشان را می بینند. این ها نه تنها نسبت به کل دیاگرام همکاری پیچیدگی کمتری دارند، بلکه اطلاعات اضافی فرایند را در بر می گیرند که در مجموعه موتور فرایند قرار ندارند (مانند اینکه موقعی که چیزی نامشخص است در موردش سوال می شود).
خلاصه اینکه این رویکرد از نظر ما نه تنها کاربردی است بلکه تنها راهی است که تا بر پایه BPMN یک ارتباط بین کسب و کار و IT توسط مدل فرایند بدست آورد.
?? چهاردهمین جلسه از دوره “نحوه مدلسازی فرآیندها” به پایان رسید. از اینکه تا به اینجای کار با ما همراه بودید، سپاسگزاریم.
برای راحتی دسترسی شما به مطالب آموزشی این کانال، سعی میکنیم هر جلسه را در قالب یک فایل pdf در انتهای آن ارائه کنیم تا اگر دوستانی در زمان آموزش نتوانستند مطالب را دنبال کنند، به صورت مجتمع و یکجا مطالب را مطالعه کنند.
سری مقالات آموزش مدلسازی فرآیند براساس چهارچوب کاموندا caBPMN (سطح ۲ – عملیاتی):
- جلسه ۹: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۰: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۱: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۲: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۳: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۴: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۵: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۶: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۷: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۸: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۱۹: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۲۰: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۲۱: مدلهای فرایند سطح ۲ عملیاتی
- جلسه ۲۲: مدلهای فرایند سطح ۲ عملیاتی
———————————————————————————————————————————————————————————————————–
آن دسته از دوستانی که علاقه مند به دریافت این آموزش ها از طریق گوشی موبایل خود هستند میتوانند از طریق کانال تلگرام آکادمی BPM این آموزش ها را دنبال کنند.