تبدیل مدل‌های فرآیند به مدلهای قابل اجرا در نرم افزار BPMS- بخش دوم

در مطلب قبلی در این خصوص صحبت کردیم که تبدیل مدل‌های فرآیند به مدل­های قابل اجرا در نرم افزار BPMS چگونه باید انجام شود و مرحله اول این تبدیل را مرور کردیم.

در این مطلب در نظر داریم گام دوم و سوم در تبدیل مدل‌های فرآیند به مدل­های قابل اجرا در نرم افزار BPMS را توضیح خواهیم داد.

گفتنی است مطالبی که بیان می­شود تنها چکیده ای از فصل نهم کتاب Fundamentals of Business Process Management است که توسط مدرسه مدیریت فرایند چاپ و در اختیار علاقه مندان قرار گرفته است.

گام دوم: مرور وظایف دستی

پس از تعیین نوع هر وظیفه، باید بررسی کنیم آیا می­توانیم وظایف دستی را به BPMS متصل کنیم و منافع حاصل از اجرای BPMS را به حداکثر برسانیم. به همین ترتیب باید این وظایف را جدا کنیم تا بتوانیم بقیه فرآیند را خودکار کنیم. دو راه برای اتصال یک وظیفه دستی به BPMS وجود دارد: از طریق وظیفه کاربر یا با استفاده از وظیفه خودکار.

اگر مسئول انجام وظیفه دستی بتواند تکمیل کار خود را به BPMS اطلاع دهد، وظیفه دستی می­تواند به یک وظیفه کاربر تبدیل شود. به عنوان مثال کارمند انبار که انجام وظیفه “بازیابی محصول از انبار” را به انجام می­رساند، می­تواند آغاز به کار خود را در نمایشگر کارها تأیید کند تا نشان دهد که این کار در حال انجام است، سپس بصورت دستی محصول را از قفسه بازیابی کند و با ثبت پایان کار، اتمام کار را به موتور BPMS ارسال نماید. شروع به کار و پایان کار را می‌توان در یک مرحله با هم ترکیب کرد تا در آن کارگر به سادگی بتواند سیستم را از تکمیل کار مطلع نماید.

علاوه بر وظایف دستی که در یک سطح مفهومی‌ مورد استفاده قرار می­گیرند، عناصر مدل­سازی دیگری نیز وجود دارند اما نمی­توانند توسط BPMS ترجمه شوند. این عناصر data objectها، data storeها و messagesهایی هستند که نشان دهنده اشیاء فیزیکی و متن­های توضیحی هستند. Poolها و Laneها نیز فقط در سطح مفهومی‌ استفاده می­شوند. در حقیقت همانطور که مشاهده کردیم، Poolها و Laneها اغلب برای ترسیم تخصیص منابع بصورت کلی استفاده می­شوند.

گام سوم: تکمیل مدل فرآیند

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

مثلاً ممکن است که مدل فرآیندی بر اساس سناریوی “همه چیز خوب است” تهیه شده باشد و تمام شرایط منفی محتمل در طی اجرای فرآیند نادیده گرفته شود و اینطور فرض شود که همه چیز به خوبی کار خواهد کرد.

همانطورکه در فصل ۴ دیدیم، در فرایند تحقق سفارش چند استثناء وجود دارد. برای مثال مواد مورد نیاز برای تولید محصول ممکن است در انبار تأمین­ کننده موجود نباشد و یا مشتری سفارش خود را لغو کند. بنابراین باید مطمئن شویم که تمام استثنائات با کمک راه­های مقتضی مدیریت می­شوند. به عنوان مثال اگر لغو سفارش پس از ارسال محصول یا بعد از دریافت هزینه صورت پذیرد، باید فعالیت­های جبرانی نظیر برگشت محصول و برگشت هزینه به مشتری صورت پذیرد.

استثنائی دیگر که معمولاً نادیده گرفته می­شود، این است که شاید یک فعالیت هیچوقت انجام نشود. چه اتفاقی می­ افتد اگر آدرس مشتری هرگز دریافت نشود؟ یا اگر ماژول ERP که وجود موجودی را چک می­کند، پاسخ ندهد؟ نمی­توانیم فرض کنیم که طرف دیگر همیشه پاسخ دهد یا این‌که یک سیستم همیشه عملکردی درست خواهد داشت.

به همین ترتیب نمی­توانیم فرض کنیم که فعالیت‌ها همیشه منجر به نتیجه مثبت می­شوند. به عنوان مثال ممکن است سفارش هیچ وقت تأیید نشود.

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

همچنین در این مرحله باید تمام electronic data objectهایی که وظایف فرایند ما آن‌ها را به عنوان ورودی و خروجی نیاز دارند مشخص کنیم.

اگر تاکنون به کمبود این Data object‌ها پی نبرده باشید احتمالاً به این دلیل است که شما فکر کرده ­اید که وجود دارند. این خوب است که در یک مدل کسب‌وکار گرا با توجه به هدف مدل­سازی، فقط موارد مربوط به هدف مستند شوند اما در مدل اجرایی اینطور نیست چرا که موتور باید مدل را اجرا کند. بنابراین اطمینان حاصل کنید که هر فعالیت electronic data objectهای ورودی و خروجی دارد. قاعده این است که هر data object که موتور BPMS برای کنترل بین فعالیت­ها و انجام تصمیم­ گیری­ها به آن نیاز دارد، باید مدل شود.

ادامه دارد