مدل های فرآیند عملیاتی (جلسه ۲۱)
در ادامه جلسه قبل به بررسی سطح سوم از چهارچوب کاموندا میپردازیم. با ما همراه باشید…..
بدست آوردن قواعد کسبوکار از فرایند
در بخش های قبل فرایند «تایید سفارش» را مشاهده کردیم و صحبت کردیم که کدام خطاها در حین اجرا کار میتوانند رخ دهند.
حال میخواهیم یک سوال دیگر را مطرح کنیم، که تحت کدام شرایط باید اعتبار مشتری اصلاً موردبررسی قرار گیرد؟ فرض میکنیم که این سوال به ویژگیهای مشخصی از مشتری و ارزش سفارش بستگی دارد. سپس اولین قدم در فرایند را بهطور کلی بهعنوان «بررسی اطلاعات سفارش» تعریف میکنیم و تصمیم میگیریم که آیا بررسی اعتبار در اینجا لازم است یا خیر (شکل زیر)
تایید سفارش با بررسی اعتبار مشتری تحت شرایط مشخص
حال باید با شرایط مشخصی که تحت آن اعتبار مشتری میبایست بررسی شود، مواجه شویم. با شرایط زیر شروع میکنیم:
■ اگر میزان سفارش بیش از ۳۰۰۰۰۰ یورو شود، اعتبار مشتری بررسی میگردد.
■ اگر مشتری برای بار اول است که به ما مراجعه میکند، اعتبار از مبلغ ۵۰۰۰۰ یورو موردبررسی قرار میگیرد.
■ اگر مشتری جزء مشتریان درجه یک است، نیاز به بررسی اعتبارش نیست.
حال میتوانیم این شرایط را در دیاگرام فرایند بهصورت کامل مدلسازی نماییم، همانطور که در شکل زیر قابل مشاهده است.
شرایطی که منجر به بررسی اعتبار مشتری میشوند
نظر شما در مورد این دیاگرام چیست؟ فرض کنید که شرایط دیگری اضافه میشوند، برای مثال شرایطی که تنها برای تعداد خاصی از مشتریان وجود دارند. احتمالاً دارید به مشکلاتی که با آنها همراه هستند، فکر میکنید:
■ هر شرط دیگری دیاگرام را با دروازههای بیشتر بزرگتر میکند.
■ زمانی که شرایط پیچیدهتر میشوند، این مشکل شدیدتر میشود (در مثال ما نوع مشتری و میزان سفارش).
■ دیاگرام فرایند بهسرعت نامفهموم میشود.
■ زمانی که شرایط تغییر میکنند، برای مثال شرایط جدیدی اضافه میشوند و یا حذف میشوند، باید این شرایط خود را با دیاگرام وفق دهند، در غیر این صورت تنها تعدادی نشانه را داریم که بهصورت نامرتب و نامفهوم فقط در کنار هم قرار دارند.
■ اگر اعتبار مشتری در دیگر فرایندها نیز میبایست بررسی شود، برای مثال در چهارچوب یک درخواست دیگر، باید این شرایط را بهصورت اضافی مدلسازی نمایید و آن را در نظر بگیرید.
خلاصه اینکه این شرایط تصمیمگیری پیچیده در مدلسازی فرایند بوجود میآیند. برای اجتناب کردن از آنها میبایست این شرایط را درک و «قواعد کسبوکار» را خوب متوجه شویم و آنها را از «قواعد مسیریابی» که دروازهها تعریف نموده بودیم، جدا نماییم.
مدیریت قواعد کسبوکار
قواعد کسبوکار که بهعنوان «مدیریت قواعد کسبوکار» نیز نامیده میشوند، نظم و انضباط خاصی برای خودشان دارا میباشند. همانطور که از نام آن پیدا است، برای کسبوکار خودمان قواعدی را تعیین میکنیم. آنها به ویژه شرایطی را ارائه میدهند که تحت آنها بهصورت روزمره فعالیتهایی را انجام یا از دستور کار خارج میکنیم. بهکارگیری قواعد کسبوکار بهصورت مرکزی، ساده و منعطف یک عامل مهم برای مدیریت فرایند میباشند. بنابراین برای مدلسازی فرایند باید یکراهی را پیدا کنیم که قواعد مسیریابی و کسبوکار را از هم جدا نماییم. در ارتباط با این مفهوم تنها نیستیم: حتی یک سری قانون وجود دارند به نام «گروه قواعد کسبوکار» که در آن یک تفاوت و جداسازی بین قواعد کسبوکار از فرایند اعلام میشود.
در ادامه برای مدلسازی قواعد باید یک ابزار مناسب انتخاب گردد. برای قواعد نسبتاً ساده همیشه از جدولهای تصمیمگیری استفاده میکنیم، زیرا بهسرعت قابلفهم هستند و میتوانند بدون استفاده از نرمافزار خاصی استفاده شوند. در غیر این صورت میتوانید قواعد را بهصورت شفاهی بیان کنید.
جدولهای تصمیمگیری برای این سوال که آیا اعتبار مشتری باید بررسی شوند یا خیر مانند شکل زیر به نظر میرسند.
جدولهای تصمیم گیری برای این سوال که آیا اعتبار مشتری بررسی شود یا خیر
هنگام مدلسازی شرایط باید در اصل تا آنجایی که امکان دارد بهصورت رسمی عمل کنید:
■ بد: «زمانی که تعداد شمارههای سفارش وارد شده بیش از ۱۰ نشانه داشته باشد…»
■ بهتر: «زمانی که تعداد نشانهها (شمارههای سفارش)»
از این طریق احتمال اینکه سوءتفاهم به وجود آید کاهش مییابد. علاوه براین مبنایی را درست میکنید که این قواعد نه تنها برای اشخاص بلکه توسط نرمافزارها نیز قابل تفسیر باشند.
جدولهای تصمیمگیری و مدل فرایند را چطور باهم استفاده میکنیم؟ برای این منظور میتوانید از یک الگو ساده استفاده نمایید. (مثال شکل زیر):
■ قبل از دروازه XOR یک فعالیت قرارداده میشود که تنها برای بهکارگیری قواعد تعریف شده پیشبینی شده است.
■ نتیجه فعالیت تصمیمگیری برای این است که چه چیزی در ادامه میبایست اتفاق افتد.
■ دروازه XOR تنها در ارتباط با این تصمیمگیری است و جریان فرایند را هدایت میکند.
■ ارتباط با جدولهای تصمیمگیری را یا بهطور مستقیم در فعالیت در نظر میگیریم یا یک شی اطلاعاتی ورودی را تعریف میکنیم که به جدول ارجاع میکند.
تایید سفارش با ارجاع دادن به جدول تصمیم گیری
ابزار BPMN
ارتباط نشان دادهشده شی اطلاعاتی با جدول تصمیمگیری جزو نشانهها نیست. بلکه باید توسط ابزار BPMN شما مورد پشتیبانی قرار گیرد. ویژگیهای BPMN اجازه غنیتر کردن اشیاء اطلاعاتی را با استفاده از مشخصات منحصر به فرد فراهم میسازد. از این امکان خیلی از سازندگان ابزارها استفاده میکنند، تا بتوانند با اشیاء اطلاعاتی ارتباطی را با وبسایتها یا دادههای خارجی برقرار سازند. ناظران مدلهای فرایند میتوانند برحسب علاقه بر روی شی اطلاعاتی کلیک کنند تا جدولهای تصمیمگیری قرار دادهشده را مشاهده نمایند. زمانیکه مدل فرایند در قالب یک وبسایت و بهصورت اینترانت که در سازمان قابل دسترسی باشد، نشان داده شود بهتر خواهد بود.
لطفاً یکبار دیگر این دو نوع از قواعد را در نظر بگیرید:
■ قواعد مسیریابی توسط دروازههای XOR، OR و توالی جریانهای شرطی ارزیابی میشوند. آنها بسیار ساده هستند و از تعداد زیادی از شرایط احتمالی تشکیل شدهاند. قواعد مسیریابی مستقیماً در مدل فرایند قرارداده میشوند.
■ قواعد کسبوکار میتوانند بسیار پیچیده باشند و خارج از مدل فرایند قرارداده میشوند. یک قانون کسبوکار میتواند از شرایط مرتبطی که برای قواعد مسیریابی تعیین میشوند پشتیبانی کند. برای مثال، قاعده کسبوکار «بررسی اعتبار» بر اساس نوع مشتری و میزان سفارش است و باید درمجموع پنج ترکیب احتمالی را بررسی کرد. اما فقط دو نتیجه «بله» یا «خیر» را بدست میدهد. اینها دقیقاً همان دو شرط احتمالی هستند که قاعده مسیریابی دروازه XOR مدل فرایند با آنها در ارتباط است.
در فرایند مثال زده شده، فعالیت «بهکارگیری قواعد» یک قاعده کسبوکار است، اگر آن را بخواهیم بر اساس ۲٫۰ BPMN مدلسازی کنیم و یک نوع خاص را ایجاد نماییم. این متنوعسازی اثباتی بر این موضوع است که OMG الگو جداسازی مدلهای فرایند و مدلهای قواعد را تایید میکند. در ارتباط با معانی لغات کسبوکار و قواعد آن (SBVR ، OMG )یک زبان اختصاصی برای مدلسازی قواعد تعریف میکند که آن را در این کتاب بیشتر از این توضیح نخواهیم داد. به نظر ما کاربرد عملی SBVR کمتر از BPMN است. ضمن اینکه هیچ توسعه خاصی در SBVR در ۲٫۰ BPMN دیده نشده است. از این رو برای اکثر افراد استفاده از جدولهای تصمیمگیری نمایش سادهتری است.
طبیعتاً رخداد شرطی میتواند با قواعد کسبوکار ترکیب شود. هم ویژگیها در ۱٫۲ BPMN و هم چنین طرح ۲٫۰ BPMN در این مورد متاسفانه کامل نیستند. از دید فنی میتوان این طور تفسیر کرد که یک موتور قاعده بهطور مرتب چک میکند که آیا شرط قرار دادهشده در رخداد اتفاق میافتد یا نه. اگر این اتفاق رخ دهد، به موتور فرایند خبر داده میشود که این رخداد وارد شده و فرایند باید شروع شود یا باید ادامه پیدا کند (شکل زیر).
رخداد شرطی و موتور قواعد
برای هماهنگی و ارتباط بین IT و کسبوکار مثل همیشه مهم است که اصول اصلی پشت این ساختار را متوجه شوید، زیرا به هیچ وجه تنها به استفاده تکنیکی محدود نمیشود. زمانی که به استفاده تمام سازمانی از فرایند فکر میکنیم، این اصول را پیدا خواهیم کردیم. در سازمان ما برای مثال قواعد خاصی باید رعایت شوند مانند تاییدیههای امنیتی. در اینجا یک کسی باید همیشه رصد کند که آیا این شرایطی که وارد میشوند با این قواعد در ارتباط هستند یا خیر. زمانی که این شرایط وارد میشوند کارهایی نیز باید انجام شوند، لذا باید یک فرایند آغاز گردد. در شرایط دیگر یک فرایند میبایست یا شروع یا ادامه پیدا کند، اگر یک شرط تعریف شده ایجاد گردد.
اگر بخواهیم در مورد افزایش چابکی فرایند صحبت کنیم، ترکیب بین BPM و BRM اغلب اوقات این توانایی بالقوه را دارد. با استفاده از مدیریت قواعد کسبوکار این امکان وجود دارد که این قواعد توسط واحد فنی تعریف و در صورت نیاز مطابقت داده شوند. بهکارگیری قواعد قرار دادهشده توسط موتور فرایند که با موتور قواعد در ارتباط است به این مورد منجر میشود که آنها بهصورت یک به یک و بدون فوت وقت در فرایند واقعی وارد شوند.
همانطور که مشاهده میکنید موضوع «مدیریت قواعد کسبوکار» سطوح مختلفی دارد و انواع مختلفی از قواعد کسبوکار برای آن وجود دارد. لطفاً زمان کافی صرف کنید و این قواعد را بهطور کامل فرابگیرید. در این کتاب تنها میتوانیم شما را تشویق کنیم و نشان دهیم که آنها باید با مدیریت فرایند کسبوکار ترکیب شوند.
نکته جانبی: چون فعالیت «بررسی اعتبار» در تاییدیه سفارش بهکارگیری یک قاعده را نشان میدهد، باید برای شما الآن نمایان باشد.
بیست و یکمین جلسه از دوره “نحوه مدلسازی فرآیندها” به پایان رسید. از اینکه تا به اینجای کار با ما همراه بودید، سپاسگزاریم.
