این ویدیو امکانات مربوط به فعالیت کاربری را در Camunda BPMS بررسی کردم. در همه BPMS ها از User Task برای انتصاب کار به یک نیروی انسانی استفاده می شود این موضوع در خصوص کاموندا هم صادق می باشد.
در این ویدیوانتصاب یک User Task را به کاربران سیستم، مفهوم گروه کاندید و کاربر کانید را بررسی کرده ام. این ابزار دارای نگرشی متفاوت نسبت به سایر ابزار های می باشد سعی کرده ام این تفاوت ها را مورد بررسی قرار دهم. ادامه آن نیز اتصال فرم های Camunda form، Embedded or external form , Generated task form به آن را بررسی نموده ام.
همچنین یک Camunda form را تعریف و چگونگی ارتباط متغییر های فرآیند و فعالیت در آن را ارزیابی کرده ام. مفهوم متغییر داخلی و سراسری را با ادبیات فرآیندی تست کردم.
در نهایتم هم چالش های طراحی و مدل فرآیندی و خطا های مرسوم در طراحی یک BPMN را بررسی کرده ام.
به صورت کلی سعی کردم تمام مواردی که مربوط به یک User Task می باشد را بررسی کنم و چیزی از قلم نیفتد.
اما اگر بنظر شما بهتر است موضوعی بیشتر توضیح داده شود و یا گفته نشده است حتما در قسمت کامنت آن را مطرح بفرمایید.
این ویدیو ها هم در آپارات انتشار داده می شود و هم در یو تیوب.
با دنبال کردن من در این کانال ها می توانید از جدیدترین ویدیو ها با خبر شوید.
فرآیند حال حاضر در مورد مدیریت تغییرات بوده که بر حسب Change Management مبتنی بر استاندارد ITIL ایجاد گردیده است.
شرح فرآیند
Submit
این فرآیند می تواند از سوی هر واحدی آغاز شود، که اصطلاحا نام آنرا واحد “درخواست کننده” می نامیم. با باز کردن فرم تغییرات و انتخاب از روی الگوهای پیش فرض و یا انتخاب گزینه سایر و تکمیل فرم مربوطه (با توجه به اطلاعات مورد نیاز) فرآیند آغاز می گردد. در مرحله بعد در صورت انتخاب تمپلیت، مقادیر پیش فرض در فرم اطلاعاتی مربوطه قرار می گیرد. پس از آن درخواست کننده نسبت به تکمیل اطلاعات فرم تغییر اقدام می نماید. پس از ثبت، درخواست برای واحد مدیریت تغییرات ارسال و این واحد نسبت به بررسی آن اقدام می نماید. در صورت عدم تائید درخواست، توسط واحد مدیریت تغییرات، این موضوع به درخواست کننده اطلاع رسانی شده و فرآیند خاتمه می یابد.
Approval
در صورتیکه درخواست مورد تائید این واحد باشد به صورت سیستمی تعداد گروه هایی که می بایست تغییر را تائید نمایند (“تائید کنندگان”) تعیین می شوند. در مرحله بعد و پس از مشخص شدن تعداد گروه های “تایید کنندگان” افراد هر یک از گروه ها به صورت سیستمی جهت تایید مشخص می گردند. درخواست تغییر مورد نظر توسط تائید کنندگان بررسی و در صورتیکه نیاز به اطلاعات بیشتر برای بررسی داشته باشند فرم تغییر به درخواست کننده ارجاع داده می شود تا نسبت به ثبت اطلاعات تکمیلی مورد نیاز اقدام نماید. پس از آن مجددا برای اخذ تائیدات لازم برای واحدهای تائید کننده ارسال می گردد.
در حالتی که اطلاعات کافی بوده و تمامی گروه های تائید کننده درخواست تغییر را تائید نمایند. این تغییر به کلیه افراد سازمان اطلاع رسانی خواهد شد. (در فرآیند Change Management این موضوع به کلیه واحدها اعلام می گردد تا اگر واحد دیگری فعالیت همزمانی با درخواست مربوطه داشته باشد، آن درخواست نیز قابل اجرا بوده و در وقت و هزینه صرفه جویی گردد).
Assign
در مرحله بعد درخواست تغییر برای “اقدام کننده” (واحدی که تغییر مورد نظر را می بایست انجام دهد.) و همچنین “تحویل گیرنده” (واحدی که پس از تغییر موارد را بررسی و تحویل خواهد گرفت.) به صورت موازی اطلاع رسانی می گردد.
In Progress
پس از هماهنگی این دو واحد واحد اقدام کننده شروع به اعمال تغییرات مورد نیاز می نماید. شروع به تغییرات مجددا برای تمامی واحدهای ذینفع اطلاع رسانی می گردد.
Update Tools
پس از اعمال تغییرات تیم تحویل گیرنده اقدام به بررسی و تست تغییرات رخ داده کرده. در صورت عدم وجود مشکل، اصطلاحا اقدام به تحویل گرفتن تغییرات مورد نظر می نماید و اطلاع رسانی آن به تمامی واحدهای ذینفع انجام می گردد. واحدهای ذینفع نیز دارای تسک های خاص خود بوده که نیاز به بررسی و انجام آن ها می باشد. پس از اتمام آن ها فرآیند تغییر خواسته شده به اتمام می رسد. حالتی نیز در برخی موارد رخ می دهد که در آن واحد تحولی گیرنده نسبت به تغییر اعمال شده نظر منفی دارد.
در این حالت اگر زمان برای انجام تغییرات باقی مانده باشد که مجددا به تیم اقدام کننده ارجاع تا نسبت به رفع مشکلات اقدام نماید و اگر زمانی برای تغییرات باقی نمانده باشد اطلاع رسانی به ذینفعان انجام شده و درخواست تغییر بسته می شود.
pending close
واحدمدیریت تغییرات نتیجه کارهای انجام شده در هر واحد را بررسی می نماید. زمانی که از صحت اطلاعات اطمینان بدست آورد درخواست را پایان میدهد.
Release
زمانی که درخواست می خواهد بسته شود، به تمام ذینفعان فرآیند اطلاع رسانی صورت خواهد گرفت
Resubmit
در فرآیند ذکر شده حالتی وجود دارد که تغییرات به صورت فورس می بایست انجام شده و فرصت گرفتن تائیدات مورد نیاز نمی باشد. در این حالت درخواست تغییر بدون تائید واحد مدیریت تغییرات و واحدهای دیگر وارد فاز اجرایی شده و اطلاع رسانی جهت ارسال تغییر به واحد اقدام کننده و تحویل گیرنده و دیگر واحدهای ذینفع انجام می پذیرد.
یکی از اهداف فرآیند Change Management که سعی شده است در این فرآیند درنظر گرفته شود حفظ اصول و استنداردهای ITIL می باشد.
طی تجربیات اخیری که در پیاده سازی فرآیندها دارم مثال BPMN که در اینجا مطرح می کنم به نظرم یکی از بهترین نمونه های فرآیندی در خصوص Call Activity یا فعالیت فراخوان می باشد.
در سازمان ها معمولا یک فرآیند به نام درخواست خرید کالا وجود دارد. به صورت تقریبی شبیه فرآیند زیر می باشد.
فرایند درخواست کالا
درخواست کننده فرم مربوطه را تکمیل کرده و برای مدیر خود ارسال می نمایید. ایشان بعد از بررسی و در صورت تایید درخواست را برای مدیر برنامه ریزی ارسال می نمایند. ایشان هم در صورت تایید برای مدیر عامل ارسال می نماید. در هر مرحله با عدم تایید فرم جهت اصلاح برای درخواست کننده ارسال می شود. در صورت تایید، مدیر عامل جهت استعلام درخواست برای بازرگانی ارسال شده و نتیجه را برای درخواست کننده ارسال می نمایند. در صورت عدم تایید درخواست برای استعلام مجدد برگردانده می شود. ولی اگر تایید گردد درخواست برای مدیر عامل ارسال شده و بعد از بررسی ایشان در صورت نیاز به برگزاری کمیسیون درخواست به بازرگانی فرستاده می شود. در غیر این صورت نسبت به خرید اگر نیاز به صدور چک داشته باشد فرآیند صدور چک اجرا به صورت Call Activity فراخوانی می شود. در غیر این صورت جهت خرید فرم در اختیار مسئول خرید قرار خواهد گرفت و به ازای هر ردیف در فرم خرید یک بار فرآیند رسید دائم کالا فراخوانی می گردد.
قابل ذکر است در طول فرآیند اطلاعات درخواست نیاز است در بانک اطلاعاتی ذخیره سازی گردد.
فرآیند رسید دائم کالا
بازرگانی صورت وضعیت را برای انبار ارسال می کند. بعد از تکمیل اطلاعات فرم برای QA ارسال می گردد. ایشان کارشناس مربوطه در QC را انتخاب کرده و فرم را جهت تکمیل برای ایشان ارسال می نمایند. بعد از تکمیل فرم مدیر QC اطلاعات را بررسی کرده. در صورت نیاز جهت اصلاح به کارشناس QC باز می گرداند. در غیر این صورت نتیجه برای QA ارسال می گردد. ایشان اطلاعات را تکمیل کرده و دستور صدور رسید دائم را به مسئول انبار می دهید. ایشان بعد از صدور رسید اطلاعات را جهت بایگانی در اختیار بازرگانی قرار داده و سیستم بررسی می درخواست صدور چک را خواهد نمود.
فرآیند صدور چک
کارشناس بازرگانی اطلاعات درخواست صدور چک را تکمیل کرده. برای مدیر بازرگانی ارسال می نماند. مدیر درخواست و سوابق را بررسی کرده و در اختیار مدیر برنامه ریزی قرار میدهد. با تایید ایشان برای مدیر مالی ارسال و اگر ایشان هم تایید نمایند برای مدیر عامل ارسال می گردد. در غیر این صورت با رد درخواست فرم به یک مرحله قبل باز میگردد. با تایید مدیر عامل دستور صدور چک در اختیار کارشناس حسابداری قرار گرفته و ایشان چک را برای واحد بازرگانی ارسال می نمایند.
در مثال فرآیند اتوماسیون تغذیه ۴ نوع فرآیند وجود دارد که در زیر به آنها اشاره خواهد گردید.
فرآیند تعریف غذا دراتوماسیون تغذیه
در آغاز به کار مثال فرآیند نیاز است فرم شماره ۱ در سامانه ورود اطلاعات شود، به نحوی که مواد تشکیل دهنده آن هم به صورت صحیح وارد شود. این کار توسط کارشناس تغذیه یک بار انجام می شود و یا غذای جدید به لیست اضافه میگردد اطلاعات درج شده در بانک اطلاعات غذا ذخیره میگردد. این بانک در قسمت های متعددی از فرایند استفاده می شود. فرایند مربوط به این مرحله به شرح زیر است:
بانک اطلاعاتی :
فرم ها:
فرایند ویرایش غذاها:
جهت ویرایش لیست غذای ثبت شده در مثال فرآیند از فرم شماره ۲ استفاده میشود. این فرم به نحوی کار میکند که در ابتدا غذاها را از از بانک اطلاعاتی دریافت مینماید و سپس اقدام به ویرایش غذا نموده. جهت ویرایش غذا لازم است نام هر غذا انتخاب تا پنجره ویرایش آن باز شود(فرم شماره ۱) در نهایت مجددا غذاها در بانک اطلاعاتی ذخیره میگردد. همانند فرایند زیر:
بانک اطلاعاتی :
فرم ها:
فرایند برنامه ریزی ماهیانه
جهت برنامه ریزی ماهیانه دراتوماسیون تغذیه از فرم شماره ۳ استفاده می شود. این فرم به نحوی کار می کند که کارشناس تغذیه اقدام به تکمیل فرم شماره ۳ نموده و جهت اعمال تغییرات لازم برای سرپرست خود ارسال نموده و ایشان پس از اعمال تغییرات در صورت تایید برای کارشناس تغذیه فرم را می فرستند در صورت تایید کارشناس بهداشت، فرم برای آشپزخانه ارسال می گردد و در صورت عدم تایید توسط سرپرست مجددا درخواست برای کارشناس تغذیه ارسال می گردد تا بر روی روی درخواست بازنگری نماید و همچنین در صورتی که کارشناس بهداشت درخواست را مورد تایید قرار ندهد فرم برای سرپرست ارسال می شود تا ایشان موارد را بررسی نمایید.
بانک اطلاعاتی:
فرم ها:
فرم دوم برنامه ریزی ماهیانه غذا در اتوماسیون تغذیه توسط متقاضی تکمیل می گردد
در هر سازمانی قرارداد بسته شده با پرسنل، دارای یک زمان مشخصی می باشد و نیاز است که قرار داد آن ها مجددا تمدید شود. به همین منظور فرآیند تمدید قرار داد در سازمان ها با معیارهای مختلفی شکل می گیرد. ولی در اکثر مشتریان ما سامانه ارزشیابی عملکرد برای تمدید قرارداد یک پرسنل تاثیر چندانی ندارد لذا در این مثال بدون ارزیابی به این فرآیند پرداخته ام.
شرح فرآیند
همان طور که در گراف فرآیندی زیر مشخص است هر مدیر تنها به پرسنل زیر مجموعه خود امتیاز می دهد. لذا نیاز است در ابتدای امر، یک تراکنش با سامانه منابع انسانی ایجاد شود، تا لیست پرسنل زیر مجموعه تولید گردد و بتوان آن را در اختیار مسئول مربوطه قرار داد. در مرحله بعدی مدیر، به تمام افراد موجود در لیست یک امتیاز می دهد و آن را برای معاونت خود ارسال می کند.
چرا از درگاه شرطی استفاده نشده است؟
بایستی توجه داشت چون مدیر در یک لیست مقدار دهی می کند نمی توان برای آن یک درگاه شرطی در نظر گرفت
لذا جهت حذف افرادی که دارای امتیاز مناسب نیستند از ابزار کد نویسی استفاده می کنیم . به این ترتیب لیست را پالایش کرده و یک لیست جدید تولید می کنیم و آن را در اختیار معاونت قرار می دهیم. معاونت هم مانند مدیر در لیست پایش کرده و به افراد امتیاز می دهد. مجددا با استفاده از ابزار کد نویسی لیست معاونت هم پایش می شود و در اختیار منابع انسانی قرار می گیرد.
منابع انسانی لیست را بررسی کرده و آن را جهت درج در سامانه منابع انسانی جهت تمدید قرارداد در اختیار سیستم می گذارد. با استفاده ازابزار سرویس اطلاعات داده ها را در نرم افزار منابع انسانی درج می کنیم.در مرحله ای که اطلاعات بایستی از طریق وب سرویس انتقال یابد این سرویس انقدر باید کار کند تا تمام لیست پرسنل از طریق این وب سرویس در سامانه درج شوند.
مسیر جریان قرمز رنگ چیست؟
در این فرآیند سعی کردیم به این موضوع توجه شود که مسیر های جریان صرفا برای بیان بهتر جریان فرآیند استفاده می شوند و در سامانه هایی که قرار است این فرآیند را اجرا نمایند نقش ایفا نمی کنند.
فایل دانلود:
باکلیک بر روی لینک زیر می توانید فایل فرآیند تمدید قرار داد را دانلود نمایید.
همانطور که در مثال BPMN زیر نمایش داده شده است در فرآیند دریافت وام از یک زیر فرآیند استفاده شده است و برای مدیریت زیر فرآیند از یک رویداد میانی در مرز فرآیند استفاده گردیده است.
در شروع فرآیند از یک درگاه رویداد استفاده شده است با کمک آم بررسی می شود مبلغ اقساط دریافت شده است یا خیر در صورت عدم دریافت مبلغ به مدت یک هفته از سر رسید فرآیند وارد زیر فرآیند گردیده و در آنجا بعد از اطلاع رسانی ۳۰ روز منتظر پرداخت قسط می ماند در صورت پرداخت رویداد مرزی پیام فعال می شود و سبب متوقف شدن زیر فرآیند می گردد.
نقشه فرآیند
دریافت فایل:
جهت دریافت فایل BPMN مربوطه بر روی لینک زیر کلیک بفرمایید