این مقاله از جهت جامعیت و تعداد بازدید یکی از ۵ مقاله برتر سایت مدرسه مدیریت فرایند به شمار می رود و بیش از 30 هزار نفر تاکنون آنرا مطالعه کرده اند.
همانطورکه در شکل پایین مشاهده میکنید جایگاه فاز مدلسازی فرایندها در چرخه مدیریت فرایند مشخص شده است.
اولین نکته مهم در مورد مدلسازی فرایند که باید در نظر داشته باشیم این است که مدلسازی فرایندهای وضع موجود یا به عبارت دیگر کشف فرایندها، باید پس از استخراج معماری فرایندها اتفاق بیفتد. پس اگر هنوز معماری فرایندها سازمان خود را استخارج نکرده اید، پیشنهاد می کنم نسبت به اینکار اقدام نموده و در ادامه به سراغ مدلسازی فرایندها بیایید.
فاز اول بسیاری از پروژه ها از قبیل: مهندسی مجدد و بهبود فرایندها، معماری سازمانی، EFQM، ایزو و… با مدلسازی فرایندهای وضعیت موجود سازمان آغاز میگردد. علاوه بر موارد مذکور در ادامه به ذکر دلایلی میپردازیم که اهمیت پروژه مدلسازی فرایندهای سازمانی را تبیین مینماید.
برخی اهداف و کاربردهای مدلسازی فرایندها عبارتند از:
- ایجاد شفافیت و تفاهم بین ذینفعان
- یک ابزار کمک آموزشی
- مقایسه وضعیت موجود با وضعیت مطلوب و رفرنس مدلها
- شبیهسازی و ابزار پایه جهت شناسایی فرصتهای اساسی برای بهبود فرآیند
- و…
همچنین یکی از پیش نیازهای اساسی جهت عارضه یابی در سازمان، شناسایی وضعیت موجود و انطباق آن با وضعیت مطلوب است که در پروژه مدلسازی فرایندهای سازمان، مورد اول محقق خواهد شد.
مستندسازی روالها و فرایندها منجر به تبدیل دانش ضمنی به دانش صریح و مستند شده و چرخه مدیریت دانش را در سطح سازمان تسهیل خواهد نمود.
مطالب ارائه شده در این مقاله از چند منظر به آموزش مدلسازی فرایندها خواهد پرداخت.
در گام اول چند نکته بسیار کلیدی و مهم در مورد مدلسازی فرایندها مورد اشاره قرار خواهد گرفت.
در ادامه روش های مختلف مدلسازی فرایندها را ارائه خواهیم کرد.
سپس به آموزش مهم ترین نمادها در استاندارد BPMN2 خواهیم پرداخت.
فیلم ۹۰ دقیقه ای آموزش مدلسازی فرایند و استاندارد BPMN2
نکات بسیار مهم در مدلسازی فرایندها
نکته اول: مدلسازی فرایند فقط ترسیم نمودار BPMN2 نیست.
باید بدانید که مدلسازی فرایند صرفاً ترسیم نمودارهای فرایندی مثل BPMN2 نیست بلکه بجز نمودار فرایندی باید اطلاعات دیگری نیز در مورد فرایند مستند کنید. این اطلاعات در قالب شناسنامه فرایندی گنجانده خواهد شد. در این شناسنامه کلیه اطلاعاتی که در طول چرخه مدیریت فرایند اعم از تحلیل، پیاده سازی، پایش و کنترل به آن نیاز است، باید گنجانده شود.
نکته بسیار مهم دیگر اینکه پس از طراحی شناسنامه فرایند در مراحل ابتدایی و پیش از آغاز جلسات مصاحبه بابت مدلسازی فرایند، آنرا به تک تک اعضاء تیم مدلسازی به بهترین و کامل ترین وجه ممکن آموزش داد. همه اعضاء تیم مدلسازی باید به زبان مشترک در مورد شناسنامه برسند.
شناسنامه فرایند باید حاوی اقلام اطلاعاتی زیر باشد:
- هدف فرایند
- صاحب فرایند
- متولیان و مجریان فرایند
- شرح فرایند
- گام های اصلی اجرای فرایند
- سرفصل های اطلاعاتی مورد استفاده در فرایند
- مشکلات فرایند
- ایده های بهبود
- ورودی و خروجی های فرایند
- ضریب مکانیزاسیون فرایند
- نمودار IDEF0
- شاخص های کلیدی ارزیابی فرایند (KPI)
به زودی در همین قسمت توضیحات تکمیلی ارائه خواهد شد.
نکته دوم: مدلسازی با رویکرد پیاده سازی
یکی از مهم ترین ریسک های پروژه های مدیریت فرایند و سایر پروژه های مشابه مدلسازی فرایندها به گونه های که است که در هنگام پیاده سازی نیاز به بازنگری، اصلاح و تکمیل آنها وجود دارد و این موضوع باعث ایجاد یک دوباره کاری اساسی در مدلسازی فرایندها خواهد شد.
پیش از بیان توضیح در مورد این نکته یعنی چگونگی مدلسازی فرایندها با رویکرد پیاده سازی، باید این فرض را مطرح کنیم که منظور از پیاده سازی فرایندها، مکانیزه کردن آنها خصوصاً با ابزارهایی مثل BPMS است. مکانیزاسیون سرعت انجام فرایندها را نیز افزایش داده و خطای انسانی را به حداقل ممکن کاهش خواهد داد. در نتیجه باعث میشود سازمان فرایندهای خود را با کیفیت بیشتر و زمان و هزینه کمتری انجام دهد.
حال یکی از ورودی ها و خوراک های اصلی فاز پیاده سازی یعنی مکانیزاسیون فرایندها با نرم افزار BPMS ، مدل های فرایندی ترسیم شده است. در واقع خروجی فاز مدلسازی ورودی فاز پیاده سازی را تشکیل خواهد داد منتها در بسیاری از موارد اتفاقی که می افتد به اینصورت است که مدل های فرایندی ترسیم شده و حتی بهبود یافته، پاسخگوی نیاز پیاده سازی نخواهد بود.
این اشکال باعث بروز یک دوباره کاری اساسی خواهد شد. حتی بارها مشاهده کرده ایم که بعد از صرف کلی زمان و هزینه برای مدلسازی فرایندها و بهبود آنها، وقتی می خواستند نسبت به وارد کردن آنها به نرم افزارهای BPMS اقدام نمایند، مجبور بودند مدل های را بازنگری اساسی کنند.
یکی از مهم ترین دلایل این اتفاق این است که در فاز پیاده سازی نیاز به مدل های فرایندی داریم که در پایین ترین سطح ممکن ترسیم شده باشند. اجازه دهید کمی بیشتر توضیح دهم.
معمولاً فرایندها را میتوان در سطوح مختلفی مدل کرد. به شکل پایین توجه نمایید:
همانطورکه در تصویر مشخص است، میتوان فرایندها را در سطوح مختلفی مدل کرد. ما به عناوین هر سطح کاری نداریم یعنی اینکه هر کدام از این تصاویر برای هر سطح از چه عناوینی استفاده میکنند. بجای آن از ۴ عبارت پایین استفاده میکنیم:
- سطح اول
- سطح دوم
- سطح سوم
- سطح چهارم
بالاترین سطح ممکن یعنی سطح یک چیزی است که یک دید کلان از فرایند به ما میدهد و تا آنجایی که ممکن است فرایند را فشرده نشان میدهد. هدف نمایش فرایند از ابتدا تا به انتها میباشد و ناظر میتواند با یک نگاه تشخیص دهد که فرایند برای چه کسی است و چه خدمتی را ارائه میدهد و به چه صورت اتفاق میافتد.
این سطح معمولاً سطحی است که متخصصین مدیریت فرایند از نموداری تحت عنوان SIPOC یا IDEF0 برای مدلسازی آن استفاده میکنند. در این سطح علاوه بر تعیین مرز فرایند، ورودی های، خروجی ها، منابع مورد استفاده در اجرای فرایند و سایر موارد مورد نیاز را تعیین خواهیم کرد.
سطح دو به ارائه گام های اصلی فرایند بدون در نظر گرفتن جزئیات و تصمیم گیری ها (Gateway) میپردازد. به همین ترتیب که از بالا به پایین حرکت می کنیم، جزئیات بیشتری به مدل فرایند اضافه خواهد شد.
لطفا توجه کنید. سطح ۴ دارای جزئیات کامل است و آن چیزی است که ما برای فاز پیاده سازی به آن نیاز داریم.
در این خصوص که آیا برای مدلسازی فرایند طی کردن هر ۴ سطح لازم است نمیخواهیم بحث کنیم فقط ذکر این نکته کافی است که در اینجا دو رویکرد وجود دارد:
- برای رسیدن به سطح ۴ باید از سطح ۱ شروع کنیم و به ترتیب سطوح ۲ و ۳ و ۴ را باید طراحی کنیم.
- میتوان مستقیماً به سطح ۴ رسید.
در هر صورت سئوال اصلی اینجاست که چطور میتوان فرایندها را در سطح ۴ مدل کرد یا به عبارتی طوری مدل کرد که در هنگام پیاده سازی نیاز به بازنگری و دوباره کاری وجود نداشته باشد.
پاسخ این سئوال اصلاً پیچیده نیست. تنها کافی است سعی کنید فرایندها را با رویکرد گردش اطلاعات مدل کنید. در واقع باید سعی کنید در هر Task یک رویداد اطلاعاتی به وقوع بپیوندد. منظور از اتفاق اطلاعاتی این است که باید یک فرمت اطلاعاتی ایجاد، خوانده، آپدیت و یا حذف (CRUD) شود. منظور از فرمت اطلاعاتی فرم، نامه، چک لیست، گزارش و سایر موارد مشابه است.
اگر اینگونه فرایندها را مدل کنید به اصطلاح آنها را اتمیک مدل کرده اید و تا درصد بسیار بالایی در هنگام پیاده سازی نیاز به انجام اصلاحات اساسی و بازنگری نخواهید داشت.
یکی از مهم ترین ویژگی های تیم ما در پروژه های مدلسازی فرایندها، همین مورد است. یعنی ما فرایندها را در سطح چهارم مدلسازی می کنیم.
گفتنی است در دوره های مدیریت فرایند برگزار شده توسط مدرسه مدیریت فرایند تکنیک های فوق العاده ای برای این منظور با تدریس مهندس رمضانی آموزش داده خواهد شد.
نکته سوم: مدلسازی همه فرایندها لازم نیست.
این نکته مانند نکته قبلی بسیار حائز اهمیت است. مدلسازی همه فرایندها لازم نیست. مدلسازی فرایندها کاری بسیار سخت و زمان بر است و بنا به گفته بسیاری از بزرگان این حوزه، سخت ترین گام در مدیریت فرایند، مدلسازی فرایندهای وضعیت موجود است. قضیه جایی پیچیده تر می شود که می فهمیم فرایندها موجودات زنده ای هستند که دائم در حال تغییر هستند. حالا اگر بیاییم زمان زیادی را برای مدلسازی صرف کنیم، تا بخواهیم وارد مرحله پیاده سازی شویم یا فرایندها تغییر کرده است یا با مقاومت شدید سازمانی مواجه می شویم. زیرا مزایای مدیریت فرایند صرفاً با مدلسازی فرایندها نمایان نخواهد شد و باید چرخه مدیریت فرایند را کامل طی نمود.
در واقع دو نوع رویکر برای انجام پروژه های مدیریت فرایند مثل بسیاری پروژه های دیگر وجود دارد:
- رویکرد آبشاری
- رویکرد توسعه تدریجی
رویکرد آبشاری به این معنی است که هر فاز باید بطور کامل انجام شود، سپس به سراغ فاز بعدی می رویم. در حالیکه این رویکرد بسیار زمانبر بوده و تا بخواهیم به خروجی ملموس برسیم زمان زیادی را از دست داده ایم.
رویکرد دیگر در انجام پروژه های مدیریت فرایند رویکرد توسعه تدریجی است. یعنی لازم نیست همه فرایندها را مدل کنیم بلکه مدل کردن تعدادی از آنها و پیش بردن همین تعداد تا سطح پیاده سازی بسیار بهتر از مدلسازی همه آنها است.
نکته چهارم: استفاده از زبان مدلسازی BPMN2 بجای سایر زبان ها مثل فلوچارت
استانداردهای مختلفی برای مدلسازی فرایند وجود دارد که برخی از آنها عبارتند از:
- Business Process Model and Notation
- Flow Charting
- Swim Lanes
- Event Process Chain :EPC
- Value Chain
- UML
- IDEF
- Process Chart
- SIPOC
منتها از بین تمام موارد اشاره شده، استاندارد BPMN2 از بقیه کاملتر و جذاب تر است. BPMN مخفف کلمه Business Process Modeling Notification است و بهترین زبان برای مدل سازی فرآیند های کسب و کار به شمار میرود. BPMN ابزار اصلی در تکنولوژی مدیریت فرآیندهای کسب و کار (BPMS) میباشد. به عبارت دیگر اکثر BPMS خوب دنیا فرایندهای خود را با BPMN مدلسازی میکنند.
استاندارد IDEF
IDEF مخفف Integrated Definition Methods است که شامل مجموعه ای از روش های ساخت یافته به منظور تحلیل و مدلسازی فرایندهای سازمانی و تجزیه و تحلیل و طراحی سیستم های نرم افزاری است. این استاندارد توسط وزارت دفاع ایالت متحده پشتیبانی میشود.
استاندارد IDEF خود از ۱۷ نمودار تشکیل شده است. البته مهم ترین نمودارهای موجود در استاندارد IDEF عبارتند از:
- IDEF-0
- ۱IDEF
- ۳IDEF
روش IDEF0 از نمودار DFD که در روش تحلیل و طراحی ساختیافته وجود دارد، مشتق شده است. IDEF0 مدل گرافیکی برای نمایش عملکرد سیستم های پیچیده است و بر روابط کارکردی تمرکز میکند تا نشان دهد که “چه” چیزهایی در یک فرایند بر اساس نمودار مدلسازی ICOM اجرا میشود.
جزء اصلي مدل IDEF0 فعاليتها هستند و هر فعاليت با چهار جزء مشخص ميشود: ورودي، كنترل، خروجي و مكانيسم كه به اختصار ICOM خوانده ميشوند. نمودار IDEF0 از دو علامت مستطیل و فلش تشکیل شده است.
هر کدام از فعالیت های اصلی را می توان Decomposition کرد و با جزئیات بیشتر نشان داد.
IDEF0 محبوبیت زیادی در کاربرد پیدا کرده است. وجود قانون های جدی و کنترل و توصیف دقیق روی وردی ها و خروجی ها، خصوصاً این روش را برای استفاده در پروژه های تحلیل و طراحی سیستم های اطلاعاتی و نرم افزار مناسب کرده است. اما این استاندارد دارای محدویت هایی نیز می باشد که برخی از آنها عبارتند از:
- نمايش ايستاي سيستم اما جنبههاي پوياي درون آن را نشان نميدهد.
- تشخيص دادن چگونگي جريان اطلاعات ميان نمودارها كار مشكلي است.
- وضعيت آني و توالي فعاليتها را به طور واضح نمایش نمــيدهد.
- همچنين منبع اطلاعاتي دادههاي ورودي، خروجي و دادههاي كنترلي مشخص نيست.
IDEF1 برای مدلسازی اطلاعات بکار میرود و از نظر مفهومی به ساختار اطلاعات در سازمان مینگرد. هدف اصلي در روش IDEF1 جمعآوري اطلاعات موجود در مورد كليه اشياي درون سازمان است.
IDEF-3 روشی برای مدل کردن جنبه رفتاری فرایندهاست و نشان میدهد اتفاقات در سازمان چگونه رخ میدهد.
بر خلاف IDEF0، IDEF3برای این است که چگونگی انجام فرایندها را به وضوح تشریح کند. در واقع IDEF0 نشان میدهد که چه کارهایی در سازمان انجام میشود و IDEF3 نشان میدهد که این کارها چگونه انجام میشود.
فلوچارت
فلوچارت یک نمودار عمومی و بسیار ساده جهت تعیین فعالیتها، تصمیمگیری و سایر اجزای اصلی فرآیندهای سازمان است. انواع علائم زیر ممکن است که در یک نمودار گردش کار موجود باشد:
- علائم شروع و اختتام: به اشکال مختلف مانند لوزی، بیضی، مستطیل با گوشههای مدور
- بردارها یا خطوط ارتباط فعالیتها که از یک علامت شروع و به علامت بعدی ختم میگردند.
- قدمهای فرآیند که به صورت مستطیل نمایش داده میشوند.
- ورودیها و خروجیها که به صورت متوازیالاضلاع نمایش داده میشوند.
- تصمیمگیریها یا تعیین شرایط که به صورت لوزی نمایش داده میشوند.
معمولاً همه شما با این زبان مدلسازی فرایند آشنا هستید.
استاندارد Swim Lane
نماد Swim Lane برای اولین بار در کتاب راملر و براچ معرفی گردید. Swim Lanes یک نماد افزوده شده به نمودار گردش فرآیند (فلوچارت) میباشد که بیان میکند کدام واحد سازمانی در حال انجام چه فعالیتی است. این امر از طریق ترسیم خطوط عمودی یا افقی تحت عنوان Swim Lane یا خطوط شناوری میسر میشود که در آن واحد سازمانی انجامدهنده، نقش شخص انجامدهنده عملیات و نیز در برخی موارد واحد سازمانی خارجی انجامدهنده عملیات مشخص میگردد.
استاندارد EPC
یک نمودار EPC یک نمایش تصویری از رخداد و عملیات مربوط به فرآیندهای سازمان است. نمودار EPC بر پایه چارچوب ARIS ایجاد گردیده است. نقطه قوت این نمودار سادهسازی نمودار و درک راحت است.
استاندارد EPC هم از اهمیت خاصی برخوردار است مخصوصاً برای سازمان هایی که قصد خرید ERP از شرکت SAP را دارند.
EPC یکی از مدلهای اصلی ARIS برای نمایش فرایندها است. توالی فعالیتهای اجرایی در فرایندهای کسب و کار که منجر به تولید ارزش میگردند، در این نمودار تشریح میشوند.
نکته پنجم: استفاده از نرم افزارهای CaseTools بجای نرم افزارهایی مثل VISO
ابزارهای تجزیه و تحلیل فرایندهای کسب و کار، به معماران کسب و کار و مدلسازان و تحلیلگران فرایند کمک خواهد کرد که بتوانند از طریق آن عملیات مستندسازی، تجزیه و تحلیل فرایندها و ساده سازی فرایندهای پیچیده را به نحوه مطلوب انجام دهند. مدیریت فرایندهای سازمان بدون بکارگیری Case Tools امری بسیار زمانبر، پرهزینه، همراه با اشتباه، دوباره کاری و قطعاً خطای انسانی خواهد بود. هنوز برخی از سازمانها فرایندهایشان را در نرم افزار Visio مدل میکنند.
در ادامه برخی از مهمترین دلایلی که نباید فرایندها را درVisio مدلسازی کرده و باید آنها را در Case Tools مدل کرد ارائه شده است.
- مدیریت همزمان روی چند پروژه کلان و امکان یکپارچهسازی سریع و آسان آنها
- استفاده از ماتریسها برای تقابل و مقایسه انواع اطلاعات موجود
- سیستم گزارشگیری با فیلترینگ قوی و ارائه گزارشات متنوع با فرمتهای Word ، html و Xml
- شبیهسازی فرآیندها و امکان شناسایی تغییرات بهینه در فرآیند، سازمان، مکان و اطلاعات
- طراحی پایگاههای داده و برنامههای کاربردی و مهندسی معکوس پایگاههای داده
- قابلیت تبدیل برخی نمودارها به یکدیگر
- قابلیت تبدیل نمودارها به ماتریسهای مختلف
- و…
انواع و اقسام Case Tools ها در دنیا وجود دارد که باید یکی از آنها را انتخاب نمود. پروسه انتخاب ابزار مورد نظر بعضاً زمانبر بوده و با پیچیدگیهایی همراه است. تیم ما پیشتر و درچند پروژه بزرگ کشوری این مسیر را پیموده است و جالب است که در همه موارد به نرم افزار ویژوال پارادیم رسیده ایم.
نکته ششم: برای مدلسازی روش های مختلفی وجود دارد.
به منظور استخراج وضعیت موجود فرایندهای کسب و کار، روشهای مختلفی وجود دارد که برخی از مهمترین آنها عبارتند از:
- مشاهدات مستقیم
- مصاحبه ها
- کارگاه های ساختاریافته
- کنفرانسهای بر مبنای وب
یکی از روشهای رایج در مدلسازی فرایندها انجام مصاحبه است ولی انجام مصاحبه معمولاً به دلایل مختلف زمانبر است. در ادامه با توجه به تعداد بالای فرایندهای سازمان و زمانبر بودن مصاحبه، یک روش جایگزین یا به عنوان بهتر مکمل برای مصاحبه ارائه خواهیم کرد که از آن طریق میتوان فرایندهای سازمان را در زمان بسیار کوتاه تری مدلسازی نمود. نکته مهم که باید بدانید این است که در موردهای مصاحبه، مشاهده و کنفرانس مبتنی بر وب که معمولاً توسط تیم مدیریت فرایند خود سازمان برگزار میشود نیاز به صرف منابع و زمان نسبتاً طولانی است. همچنین امکان برونسپاری این فاز یعنی استخراج فرایندها به پیمانکاران نیز وجود دارد.
یک روش خوب که بسیاری از سازمانهای پیشرو در سطح دنیا از آن بهره میبرند، بکارگیری بدنه خود سازمان بصورت کارگاهی در استخراج فرایندها است. به اینصورت که پس از انتخاب افراد واجد شرایط، یک دوره آموزشی مختصر و مفید (دو روزه) با محوریت مدیریت و مدلسازی فرایند برای ایشان برگزار شده و طی ۲-۳ روز آتی بوسیله برگزاری کارگاه و با هدایت و مدیریت کارشناسان واحد مدیریت فرایند، نفرات برگزیده واحدهای مختلف سازمانی خود اقدام به مدلسازی و استخراج فرایندهای واحد خود خواهند نمود.
البته قاعدتاً حجم و نوع مطالبی که در این دوره آموزشی ارائه میشود نسبت به دوره مدیریت فرایند کمتر و سبکتر خواهد بود. همچنین در نظر داشته باشید که پس از اتمام کارگاه، خروجی های تهیه شده توسط کارشناسان واحد مدیریت فرایندها مورد بررسی و بازنگری قرار گرفته و یکدست، یکپارچه و تکمیل میگردند.
یکی از مهمترین نکاتی که عدم رعایت آن منجر به عدم موفقیت در این روش میشود، استفاده نکردن از سازو کارهای مناسب انگیزشی و جبران خدمت است. یعنی باید به گونه ای عمل نمود تا افرادی که تخصصشان چیز دیگری است حاضر به یادگیری مباحث مدیریت فرایند و مشارکت در استخراج فرایندهای واحد سازمانی خود شوند. معمولاً مدیران سازمان برای ایجاد انگیزه، پاداش مناسبی برای این افراد در نظر میگیرند. اینطور میتوان گفت که فقط کافی است کمتر از ۱۰ درصد از هزینه های انجام اینکار از طرق دیگر (انجام مصاحبه کارشناسان واحد مدیریت فرایند یا برونسپاری به پیمانکار) صرف مسائل انگیزشی شود. همچنین ارائه گواهینامه معتبر که مورد تایید واحد آموزش سازمان است و منجر به افزایش حقوق یا مزایای شرکت کنندگان میشود نیز میتواند ثمربخش باشد.
از عوامل دیگر موفقیت این روش انتخاب صحیح این افراد است که خود مقوله مفصل دیگری است ولی ذکر چند نکته خالی از لطف نیست:
- ترجیحاً افرادی انتخاب شود که در رشته های مثل صنایع، انواع گرایشات مدیریت، نرمافزار، کامپیوتر و موارد مشابه تحصیل کردهاند.
- این افراد باید سابقه کاری حداقل ۴-۵ سال به بالا در حوزه مورد نظر داشته باشند.
- این افراد نباید از مدیران ارشد واحدها باشند.
- سن این افراد بین ۳۰-۴۰ سال باشد که انگیزه کافی برای پیشرفت دارند.
به عنوان جمع بندی باید اشاره کرد که برگزاری کارگاه های ساخت یافته یکی از روش هایی است که بوسیله آن میتوان با استفاده از منابع داخلی سازمان و با هزینه بسیار پایین در مقایسه با سایر روشها اقدام به استخراج فرایندهای وضع موجود نمود.
نکته هفتم: دانستن تکنیکهای مصاحبه در مدلسازی به اندازه دانستن اطلاعات در مورد BPMN2 اهمیت دارد.
از مهم ترین روش های استخراج فرایندها و مدلسازی فرایندهای کسب و کار مصاحبه است. برای مدلسازی فرایندها نیاز به تخصص های مختلفی داید که مهم ترین آنها در ادامه تشریح شده است.
اولین مورد داشتن اطلاعات کافی در مورد مدیریت فرایند جهت پرزنت افراد حاضر در جلسه مصاحبه است.
این پرزنت که باید در اول تمام جلسات مدلسازی اتفاق بیفتد و بعضاً برای شما خسته کننده خواهد شد، بسیار ضروری است. زیرا یکی از بزرگترین موانع شما در مدلسازی فرایند، گارد گرفتن مصاحبه شنوده است.
هزار و یک خیال به ذهن مصاحبه شونده خطور میکند مثلاً: اینها با پرسیدن این سئوالات می خواهند سر از کار من دربیاورند که این باعث خواهد شد در آینده من مزیت رقابتی خود را در سازمان از دست بدهم و جایگاه شغلی ام دچار ریسک شود و بسیاری تفکرات منفی دیگر. حتی ممکن است فرد مصاحبه شنوده از خود رفتار منفی بروز ندهد که دلیل این امر می تواند دستور و تاکید مدیران ارشد وی جهت همکاری با شما باشد. برای اینکه مانع از شکل گیری چنین افکار منفی در ذهن مصاحبه شنوده شوید، قطعا لازم است هدف تان از برگزاری این جلسه را در مدت نسبتاً کوتاهی در حدود ۱۰-۱۵ دقیقه بیان کنید.
بسیار کار سختی است که در فقط ۱۰ دقیقه اینکار را بصورت مفید و اثربخش انجام دهید. قطعاً ارائه توضیحات کلیشه ای و جملاتی که فقط آنها را حفظ کرده اید گره گشا نخواهد بود. زیرا اینکار فراتر از انجام یک تکلیف است و واقعاً مصاحبه شنوده باید از اعماق افکار و قلب خود با شما همسو شود.
باید در نظر بگیرید که اگر فرد مصاحبه شنوده مدیر ارشد باشد، مطالبی که به او می گویید با یک کارشناس قطعاً باید متفاوت باشد. اگر مصاحبه شونده مدیر میانی باشد، باز هم متفاوت باید سخن گفت.
همچنین باید درنظر بگیرید که با کدام واحد در حال مصاحبه هستید. اگر واحد فنی بود، یک نوع ادبیات، واحد مالی، منابع انسانی و … . قطعا این ملاحظه را رعایت کنید و با ادبیات یکسان با تمامی واحدها صحبت نکنید.
پس بسیار مهم است که خود با گوشت و خون در مورد مزیت های مدیریت فرایند بسیار مطالعه کرده و در موردشان تفکر کرده باشید. مطالعه داستان موفقیت های منتشر شده در این خصوص تا حدودی میتواند در این زمینه به شما کمک کند منتها اگر امکان مشاهده از نزدیک این سازمان ها (سازمان ها و بنگاه هایی که مدیریت فرایند را به خوبی مستقر کرده و از منافع آن منتفع شده اند) برای شما مقدور نیست، پس از مطالعه داستان های موفقیت با مکث و حوصله، تفکر کنید.
دوستان این بسیار مهم است که خود در مورد اهمیت مدیریت فرایند مسلط باشیم زیرا به نوعی صورت مسئله ماست که از طریق مدیریت فرایند به دنبال حل آن هستیم. گاهاً اینقدر بر روی راه حل تمرکز میکنیم که صورت مسئله را از یاد می بریم. پس بهتر است دائماً بصورت ملموس نه کلیشه ای در مورد صورت مسئله تفکر کنیم.
در ادامه این مقاله استاندارد BPMN2 و نمادهای اصلی این استاندارد را بصورت فشرده آموزش خواهیم داد.
آموزش فشرده استاندارد و نمادهای BPMN2
به منظور آشنایی حداقلی شما خوانندگان عزیز و اهمیت درک نمادهای بکار رفته در استاندارد BPMN2 توسط مدیران سازمان، در این بخش به معرفی برخی از نمادهای پرکاربرد این استاندارد پرداخته ایم.
۴ دسته نماد اصلی در استاندارد BPMN2 وجود دارد که عبارتند از:
- خطوط شناوری یا مسیرهای جریان (Swim lanes)
- مصنوعات (Artifacts)
- اشیاء ارتباط دهنده (Connecting Objects)
- اشیاء جریان (Flow Objects)
هر یک از این دسته ها را در ادامه بصورت کاملاً ساده تشریح خواهیم کرد. منتها درنظر داشته باشید که نمادهای اصلی استاندارد BPMN مربوط به دسته اشیاء جریان (Flow Objects)ها هستند. در واقع سه دسته اول از پیچیدگی زیادی برخوردار نیستند منتها تنوع انواع نمادها در اشیاء جریان کمی توضیحات مربوط به این دسته را طولانی میکند لیکن با زبان ساده و مختصر به توصیف آنها خواهیم پرداخت.
خطوط شناوری یا مسیرهای جریان (Swim lanes)
خطوط شناوری در استاندارد BPMN به دو بخش اصلی تقسیم میشود: Pool و Lane
Pool نشان دهنده شریک تجاری یا موجودیت کسب و کار میباشد که از لحاظ گرافیکی این دو شریک در نمودار از هم جدا میباشند. نکته مهم اینکه یک فرایند دیگر میتواند برای فرایند فعلی یک شریک تجاری محسوب شود. در نظر داشته باشید که مشتری نیز یک Pool جداگانه است یعنی داخل چارت سازمانی ما نیست. در این موارد ما تمایلی به مدلسازی و تعیین فعالیتهای انجام شده توسط عناصر خارجی را نداریم.
موارد زیر میتوانند جزء pool ها باشند:
- فرایند اصلی که در حال مدلسازی آن هستیم
- فرایندهای دیگر
- موجودیت های خارجی
- مشتریان و تامینکنندگان
در تصویر پایین مشخص شده است که فرایندی که در حال مدلسازی آن هستیم به عنوان pool در نظر گرفته شده است.
یک Lane برای جدا کردن فعالیتهایی است که به یک نقش یا واحد خاص در سازمان مربوط میشود، به کار میرود و معمولاً بیانگر نقشهای سازمانی هستند.
این موارد میتوانند جزء lane ها باشند:
- واحدهای سازمانی
- پستهای سازمانی
- نقشهای سازمانی
مصنوعات (Artifacts)
از مصنوعات جهت شفافتر شدن مدلسازی استفاده میشوند که شامل چند نوع مختلف است:
- Data Object یا اشیاء داده: با شکل زیر نمایش داده میشود.
این شکل نماد یک فرمت یا سرفصل اطلاعاتی است از جمله فرم، نامه، گزارش، چک لیست و…. به این معنی است که سرفصل اطلاعاتی توسط یک وظیفه تولید یا توسط یک وظیفه مورد استفاده قرار میگیرد.
- Annotation یا حاشیه نویسی: با شکل زیر نمایش داده میشود.
از این نماد زمانی استفاده میشود که مدلساز فرایند بخواهد توضیحات اضافی در مورد قسمتی از نمودار فرایندی ارائه نماید درحالیکه این توضیحات اضافه بوده و جزء نمودار نیستند. اگر از این نماد در مرحله مدلسازی فرایندها در سیستمهای BPMS استفاده شود، این نماد تاثیری در اجرای فرایند نخواهد داشت.
- Group یا گروه: با شکل زیر نمایش داده میشود.
این نماد نیز تاثیری در اجرای فرایند نخواهد داشت بلکه فقط برای اهداف نمایشی مورد استفاده قرار خواهد گرفت.
اشیاء ارتباط دهنده (Connecting Objects)
اشیاء ارتباط دهنده در استاندارد BPMN2 به سه دسته زیر تقسیم میشوند:
- Sequence Flow یا جریان توالی
- Message Flow یا جریان پیغام
- Association یا پیوند
Sequence Flow یا جریان توالی که با شکل زیر نمایش داده میشود:
جهت نمایش ترتیب و توالی انجام فعالیتها در داخل Lane های یک فرآیند بکار میرود که در واقع مسیر اصلی فرایند میباشد. به تصویر پایین دقت کنید:
Sequence Flow بین دو Task نشان میدهد که که ابتدا بایدTask2 انجام شود و سپس کار به Task3 ارسال شده تا فرآیند ادامه یابد.
Message Flow یا جریان پیغام برای نمایش ارتباط بین دو شریک تجاری یا دو Pool استفاده شده که با شکل زیر نمایش داده میشود.
Association یا پیوند که با شکل زیر نمایش داده میشود:
برای نمایش ارتباط بین مصنوعات (Data Object یا Annotation) با سایر المانهای اصلی BPMN2 از این خط استفاده میشود.
در تصویر پایین کاربرد همزمان هر سه نوع اشیاء ارتباط دهنده را میتوانید مشاهده نمایید:
اشیاء جریان (Flow Objects)
اشیاء جریان در استاندارد شامل سه گروه اصلی از نمادها هستند:
- Event یا رخداد
- Activity یا فعالیت
- Gateway یا دروازه
Event یا رخداد: پیشامدی که در ابتدا، میانه یا انتهای یک فرآیند روی میدهد و بر جریان فرآیند تأثیر میگذارد. پس میتوان آنها را به سه گروه تقسیم بندی کرد.
- رخدادهای آغازین
- رخدادهای میانی
- رخدادهای پایانی.
هر فرایند قطعاً دارای حداقل یک رخداد آغازین و یک رخداد پایانی است. پس رخدادها برحسب زمان تأثیر بر فرآیند به سه گروه Start، Intermediate و End (شکلها از چپ به راست) تقسیم میشوند.
Activity یا فعالیت: فعالیت ها اقداماتی هستند که در طول فرایند توسط دینفعان فرایند انجام میشوند و در یک دسته بندی کلی به دو گروه قابل تقسیم هستند:
فعالیت های اتمیک که به آنها Task نیز گفته میشود و همانطور که از نام آنها پیداست قابل شکستن به فعالیت های جزئی تر نیستند و فعالیت های ترکیبی که به آنها Sub-Process نیز اتلاق میشود. Sub-Process خود یک فرایند دیگر در دل فرایند فعلی هستند که بنا به نیاز از آنها استفاده خواهد شد.
Taskها دارای انواع مختلفی هستند که مهمترین آنها عبارتند از:
- User Task: این نوع وظیفه در مواردی کاربرد دارند که انجام کار میبایست توسط افراد و از طریق کارتابل و سیستمهای مکانیزه انجام شوند. یعنی شخصی باید در کارتابل خود، آن کار را باز کند تا فرم مربوطه آن را دیده و تکمیل نماید.
- Manual Task: این فعالیت زمانی کاربرد دارد که میخواهیم یک کار بصورت دستی توسط یک شخص انجام شود. به ازای این Manual Task کاری به کارتابل کسی ارسال نخواهد شد.
- Script Task: این Task را مواقعی به کار میبریم که میخواهیم BPMS یا سیستم مکانیزه کدی را که در آن نوشتهایم اجرا کند. یعنی وقتی فرایند به این وظیفه رسید، کدی که پشت این وظیفه نوشته شده است اجرا خواهد شد و کار به کارتابل کسی ارسال نمیشود.
- Send Task: برای ارتباط بین دو فرآیند طراحی شدهاند. این فعالیت زمانی کاربرد دارد که وقتی که میخواهیم پس از انجام یک کار مشخص به یک فرآیند پیام ارسال کنیم تا موجب محقق شدن رویدادی در آن فرآیند شویم.
- Receive Task: در هنگام ارتباط بین دو فرآیند کاربرد دارد. وقتی کار به این فعالیت برسد، صبر میکند تا پیامی را از فرایند دیگری دریافت نماید تا بتواند کار خود را ارسال کند.
- Service Task: از این نوع Task برای نمایش ارتباط فرایندی که توسط سیستم BPMS مکانیزه شده است با سیستمهای مختلف موجود در سازمان استفاده میشود. به معنی است که پشت این Task یک وب سرویس قرار خواهد گرفت.
نوع دیگری از فعالیتها، فعالیتهای ترکیبی هستند که به آنها Sub-Process نیز اتلاق میشود. Sub-Process خود یک فرایند دیگر در دل فرایند فعلی هستند که بنا به نیاز از آنها استفاده خواهد شد. Sub-Process ها دارای یک علامت + در مرکز و پایین مستطیل هستند.
Gateway یا دروازه
دروزاه ها دو کاربرد اصلی دارند:
۱- تصمیم گیری ها در فرایند را نشان میدهند
۲- برای منشعب شدن (forking) و بهم پیوستن (joining) مسیرها در فرایند مورد استفاده قرار میگرند.
Gateway برای نمایش نقاط کنترلی و تصمیمگیریها استفاده میشود. به علاوه از این Notation هم به عنوان تفکیک کننده مسیر و هم در جهت ترکیب مسیرها استفاده میشود. به عبارت دیگر به یک Task تنها یک ورودی، وارد میشود و تنها یک خروجی، از آن خارج میگردد. در صورت وجود بیش از یک ورودی یا خروجی باید از Gateway استفاده نمود.
Gatewayها انواع مختلفی دارند که مهمترین آنها عبارتند از:
- دروازه انحصاری (Exclusive gateway)
- دروازه موازی (Parallel gateway)
- دروازه جامع یا مشمول (Inclusive gateway)
- دروازه پیچیده یا مجتمع یا مرکب (Complex gateway)
- دروازه مبتنی بر رویداد (Event based gateway)
دروازه انحصاری (Exclusive gateway)
این دروازه جهت منشعب کردن فرآیند به دو یا چند مسیر متفاوت به کار برده می شود. شاخه های خروجی از این دروازه دارای هیچگونه اشتراکی نبوده و صرفا یکی از آنها شاخه ها فعال می گردد. به عبارت دیگر هرگاه بخواهیم از چند مسیر فقط یکی را انتخاب کنیم از این دروازه استفاده می کنیم.
گفتنی است این دروازه مانند سایر دروازه ها حالت واگرا و همگرا دارد. توضیحات بالا مربوط به حالت واگرای دروازه انحصاری بود. در ادامه در خصوص حالت همگرای این درزاوه توضیح خواهیم داد.
کاربرد دوم این دروازه جمع کردن شاخه های قبلاً منشعب شده فرآیند است. هنگامی از آن استفاده می کنیم که بخواهیم با وارد شدن اولین انشعاب (هر کدام از انشعابات) بلافاصله فرآیند به مسیر خود ادامه دهد.
دروازه موازی (Parallel gateway)
دروازه موازی واگرا:این دروازه با ورود یک جریان توالی بلافاصله تمامی جریان های خروجی را فعال می کند. این دروازه را هنگامی به کار می بریم که بخواهیم چند فعالیت به صورت موازی با هم انجام شوند.
دروازه موازی همگرا: این دروازه که وظیفه جمع کردن چند شاخه ورودی را دارد، با ورود هر شاخه منتظر بعدی مانده و با ورود آخرین شاخه بلافاصله شاخه خروجی را فعال می کند.
دروازه جامع یا مشمول (Inclusive gateway)
این دروازه نیز مانند دروازه های قبل دارای دو حالت واگرا و همگرا است و شمای کلی آن بصورت زیر است:
رفتار این دروازه در حالت واگرا به این ترتیب است که فرایند میتواند به هر یک از مسیرهای بعدی، همه مسیرها یا ترکیبی از مسیرها برود.
دروازه پیچیده یا مجتمع یا مرکب (Complex gateway)
این دروازه مسئول رسیدگی به وضعیت هایی را دارد که سایر دروازه ها از آن پشتیبانی نمی کنند. دروازه های قبلی دارای رفتاری از پیش تعریف شده هستند. در حالی که این دروازه روشی را جهت برنامه ریزی هر نوع رفتار مورد نظر برای مدلساز مهیا می کند.
در تصویر بالا که حالت واگرای دروازه مشمول را نمایش میدهد، میتوانیم بصورت انتخابی هر یک از شاخه ها را، همه شاخه ها را و یا ترکیبی از حالت های دلخواه را فعال نماییم.
در حالت همگرا، رفتار این دروازه به اینصورت است که فرایند را تا رسیدن همه مسیرهایی که در دروازه واگرا فعال شده اند نگه داشته و پس از رسیدن همه مسیرهای فعال شده اجازه ادامه فرایند را خواهد داد.
به تصویر پایین توجه کنید:
فرض کنید در حالت واگرای این دروازه مسیر 1 و مسیر 3 فعال شده باشند. دروزاه مشمول در وضعیت همگرا فرایند را تا زمانی که هر دو مسیر فعال شده یعنی مسیر 1 و مسیر 3 به انجام نرسیده باشند، نگه خواهد داشت و هر زمانی این دو مسیر به انجام برسند، مجوز ادامه فرایند و انجام Task 15 را خواهد داد.
دروازه مبتنی بر رویداد (Event based gateway)
دروازه های قبلی دارای رفتاری از پیش تعریف شده و مبتنی بر داده هستند. این دروازه ها بر پایه داده ها حرکت نمیکنند بلکه وابسته است به اینکه کدام رخداد در ادامه اتفاق خواهد افتاد. این درگاه بیان کننده نقاط منشعب شونده ای در هر فرایند هستند که در آن هر یک از انشعاب ها بر اساس اتفاق افتادن یک رویداد انتخاب میشود. زمانیکه اولین شاخه فعال شد فرایند از آن شاخه ادامه می یابد و مابقی مسیرها دیگر معتبر نیستند و اجرا نمیشوند.
پس به عنوان جمع بندی: در Data Based Gateway بر اساس متغیرهای فرایند مسیر تعیین میشود و در Event based gateway بر اساس رویداد بعد از درگاه مسیر معلوم میشود. یعنی حتما حداقل یکی از شاخه ها بعد از این درگاه، رویداد خواهد بود.
شمای کلی این دروازه به شکل زیر است:
فعالیت یا Activity
فعالیت یا Activity برای مدلسازی ایستگاههای کاری به کار برده میشوند و انجام کار توسط اشخاص مختلف در بازههای زمانی را مدل میکنند. در یک دسته بندی کلی به دو گروه قابل تقسیم هستند:
- فعالیت های اتمیک که به آنها Task نیز گفته میشود و همانطور که از نام آنها پیداست قابل شکستن به فعالیت های جزئی تر نیستند.
- فعالیت های ترکیبی که به آنها Sub-Process نیز اتلاق میشود. Sub-Process خود یک فرایند دیگر در دل فرایند فعلی هستند که بنا به نیاز از آنها استفاده خواهد شد.
در این بخش در نظر داریم انواع Task ها و انواع Sub-Process ها را معرفی نموده و مثال هایی از کاربرد آنها ذکر کنیم.
انواع Task ها
Task ها به انواع مختلفی تقسیم میشوند که مهم ترین آنها عبارتند از:
- User Task
- Manual Task
- Script Task
- Send Task
- Receive Task
- Service Task
User Task
پرکاربردترین نوع فعالیت User Task ها میباشند که معمولاً به یکی از دو حالت زیر نمایش داده میشود.
این نوع وظیفه در مواردی کاربرد دارند که انجام کار میبایست توسط افراد و از طریق کارتابل انجام شوند. یعنی شخصی باید در کارتابل خود، آن کار را باز کند تا فرم مربوطه آن را دیده و تکمیل نماید. این نوع وظیفه نیازمند تعربف فرم در BPMS برای خود میباشند.
Manual Task
این فعالیتها در زمانی کاربرد دارد که میخواهیم یک کار بصورت دستی که توسط یک شخص انجام میشود را نمایش دهیم. به ازای این Manual Task کاری به کارتابل کسی ارسال نخواهد شد.
به عنوان مثال در انتهای فرآیند، یک فعالیت دستی را به مسئول دبیرخانه ارسال میکنیم تا فرم مربوطه را پرینت گرفته و بایگانی نماید و در عمل یک کار خارج از کارتابل را انجام دهد.
Script Task
Script Task را مواقعی به کار میبریم که میخواهیم BPMS یا سیستم مکانیزه کدی را که در آن نوشتهایم اجرا کند. یعنی وقتی فرایند به این وظیفه رسید، کدی که پشت این وظیفه نوشته شده است اجرا خواهد شد. پس انجامدهنده این کار خود BPMS یا سیستم مکانیزه میباشد و کار به کارتابل کسی فرستاده نمیشود.
Send Task
برای ارتباط بین دو فرآیند طراحی شدهاند. این فعالیت زمانی کاربرد دارد که وقتی که میخواهیم پس از انجام یک کار مشخص به یک فرآیند پیام ارسال کنیم تا موجب محقق شدن رویدادی در آن فرآیند شویم. این وظیفه را را با شکل زیر نمایش میدهند.
Receive Task
در هنگام ارتباط بین دو فرآیند کاربرد دارد. وقتی کار به این فعالیت برسد، صبر میکند تا پیامی را از فرایند دیگری دریافت نماید تا بتواند کار خود را ارسال کند.
Service Task
از این نوع Taskبرای نمایش ارتباط فرایندی که توسط سیستم BPMS مکانیزه شده است با سیستم های مختلف موجود در سازمان استفاده میشود. به معنی است که پشت این Task یک وب سرویس قرار خواهد گرفت.
انواع Sub Processها
زیرفرایندها نوعی از فعالیت هستند که بصورت ترکیبی بوده و تعریف میشوند تا پیچیدگی فرایند اصلی را کم کنند. زیرفرایندها معمولاً جزئی از فرایند پدر خود هستند و خود میتوانند به صورت مستقل هم اجرا شوند.
برای هر یک از زیر فرایندها شروع و پایان مجزا داریم و وقتی جریان فرایند به یک زیرفرایند برسد، Start در آن زیر فرایند تحریک می کند.
به مثال ساده پایین توجه کنید:
متقاضی در مرحله اول اقدام به تکمیل درخواست استعفاء خواهد نمود. درخواست توسط سرپرست متقاضی بررسی شده و در صورت عدم تایید مراتب به متقاضی اطلاع رسانی شده و فرایند پایان خواهد یافت.
در صورت تایید استعفاء متقاضی، کار به زیرفرایند تسویه حساب ارسال خواهد شد.
علت استفاده از زیرفرایند در خصوص تسویه حساب میتواند به دلایل مختلف باشد:
- چنانچه مراحل مربوط به تسویه حساب را در این فرایند ذکر میکردیم، از نظر مدلسازی فرایند پیچیده تر شده و خوانایی خود را از دست میداد. البته در نظر داشته باشید که این برش و مثال ساده از یک فرایند واقعی است در حالیکه در فرایند واقعی مربوط به استعفاء این موضوع قطعاً مصداق خواهد داشت. یعنی در یک فرایند واقعی استعفاء اگر مراحل تسویه حساب را ذکر میکردیم، فرایند شلوغ شده و از خوانایی آن کاسته می شد.
- دلیل مهم تر اینکه مراحل مربوط به تسویه حساب فقط در فرایند استعفاء بکار برده نمیشوند بلکه در بسیاری فرایندهای دیگر مثل اخراج، تعدیل نیرو، از کارافتادگی، بازخرید و… نیز کاربرد دارد. در نتیجه به جای اینکه مراحل مربوط به تسویه حساب را در چندین فرایند مختلف قید کنیم، یکبار آنها را در یک فرایند مستقل مدل میکنیم و هر جا نیاز داشتیم، آن فرایند (تسویه حساب) را صدا خواهیم زد.
Sub–process ها به انواع مختلفی تقسیم میشوند که مهم ترین آنها عبارتند از:
- Embedded sub process
- Reusable sub process
- Event Sub Process
انواع Eventها
رخدادهای آغازین
همانطور که از نام شان پیدا است در ابتدای فرایند اتفاق خواهند افتاد و فرایند بواسطه این رخدادها تحریک شده و آغاز میشود. این نکته را در نظر داشته باشید که یک فرایند میتواند چندین رخداد آغازین داشته باشد.
رخدادهای آغازین خود دارای انواع مختلفی هستند که مهم ترین آنها عبارتند از:
- None
- Message Start Event
- Timer Start Event
- Signal Start Event
- Multiple Start Event
- Parallel Start Event
- Conditional Start event
رخدادهای میانی
همانطور که از نام شان پیدا است در میانه فرایند اتفاق خواهند افتاد. در واقع بعد از شروع فرایند و قبل از پاین آن. در بسیاری موارد جایگاه آن روی مرز فعالیت ها است و برای رفع ایرادات یا استثناهای جریان فرایند استفاده میشود و وقتی به مرز یک فعالیت متصل باشد، نشان دهنده یک جریان استثنا است.
رخدادهای میانی خود دارای انواع مختلفی هستند که مهم ترین آنها عبارتند از:
- None intermediate Event
- Message intermediate Event
- Timer intermediate Event
- Signal intermediate Event
- Link intermediate Event
- Error intermediate Event
- Escalation event
- Conditional intermediate event
رخدادهای پایانی
همانطورکه از نام آنها مشخص است در انتهای فرایند اتفاق خواهند افتاد و به معنی شاخه ای از فرایند است که در آن حضور داریم و یا به معنی پایان تمام شاخه ها و مسیرهای موجود در فرایند است.
رخدادهای پایانی خود دارای انواع مختلفی هستند که مهم ترین آنها عبارتند از:
- None End Event
- Message End Event
- Signal End Event
- Error End Event
- Terminate event
چند اشتباه بسیار رایج در مدلسازی فرایندها:
اشتباه اول: یک دروازه نمی تواند همزمان واگراو همگرا باشد. به تصویر پایین دقت کنید:
دروازه ترسیم شده در تصویر بالا همزمان هم واگرا است و هم همگرا. در نتیجه این مدل صحیح نیست. پاسخ صحیح را در تصویر پایین می توانید مشاهده نمایید:
چند استاندارد دیگر برای مدلسازی فرایند وجود دارد که به تدریج آنها را معرفی خواهیم کرد. به عنوان مثال استاندارد IDEF0 یا استاندارد EPC نیز برای مدلسازی فرایندها کاربرد دارد.
برای آموزش بیشتر در مورد مدلسازی فرایند دو اقدام زیر را می توانید انجام دهید:
۱- شرکت در دوره های عمومی آموزش مدیریت و مدلسازی فرایند که تقریباً هر دو ماه یکبار برگزار میشود یا برگزاری این دوره بصورت سازمانی
۲- مطالعه کتاب اصول و مبانی مدیریت فرایند (Fundamentals of Business Process Management) و کتاب BPMN_Method_and_Style