فرایندکاوی

چکیده

امروزه با افزایش یکپارچه‌سازی سیستم‌های اطلاعاتی در نظامات فرایندمدار، بستری برای رویکردهای جدید تحلیل داده فراهم شده است. فرایندهای کسب و کار روز‌به‌روز پیچیده‌تر می‌شوند و به موازات آن سیستم‌های اطلاعاتی سازمان، وظیفه اجرای مکانیزه‌ی تراکنش‌های مرتبط با کسب و کار را دارند. هدف هوش تجاری فراهم‌سازی روش‌ها و ابزارهای تحلیل داده به‌منظور بهبود فرایندهای تصمیم‌گیری است. فرایندکاوی همانند یک پل رشته‌های داده‌کاوی، هوش تجاری و مدیریت فرایندهای کسب و کار را با هم مرتبط می‌سازد.  هدف اصلی فرایندکاوی کشف مدل‌های فرایندی بر اساس گزارشات رویداد (event log) در سیستم‌های اطلاعاتی می‌باشد.  از مدل‌های کشف شده می‌توان در زمینه‌‌های گوناگونی به منظور تحلیل استفاده نمود. این مقاله مقدمه‌ای از فرایندکاوی را ارائه می‌نماید و همچنین کلیه‌ی مفاهیم بنیادی که برای درک فرایندکاوی الزامی هستند را پوشش می‌دهد.

 

 ۱– مقدمه

سازمان‌ها از سیستم‌های اطلاعاتی به‌منظور تسهیل پردازش تراکنش‌های کسب و کارشان استفاده می‌کنند. برنامه‌ریزی منابع انسانی (ERP) و سیستم‌های مدیریت‌گردش‌کار (WFMS) از برجسته‌ترین سیستم‌های اطلاعاتی هستند که از آنها در جهت پشتیبانی و اجرای فرایندهای کسب و کار استفاده می‌شود. فرایندهایی مانند تدارکات، عملیات لجستیک، فروش و منابع انسانی را به سختی می‌توان بدون یکپارچه‌سازی سیستم‌های اطلاعاتی متصور شد. افزایش یکپارچگی سیستم‌های اطلاعاتی نه تنها ابزارهایی را در جهت افزایش کارایی و بهره‌وری فراهم می‌سازد، بلکه امکانات جدیدی را  نیز در ارتباط با دسترسی و تحلیل داده‌ها ارائه می‌نماید. تولید داده زمانی صورت می‌گیرد که از سیستم‌های اطلاعاتی برای پشتیبانی و مکانیزه‌سازی پردازش تراکنش‌های کسب و کار استفاده شود. این اطلاعات می‌توانند بعنوان مثال در جهت بهبود تصمیم‌گیری‌های کسب و کار مورد استفاده قرار گیرند

هوش تجاری(‌BI)  عبارتست از مجموعه‌ای از ابزارها و تکنیک‌ها که از آن‌ها برای تولید و استخراج اطلاعات از داده‌های دیجیتال استفاده می‌شود. از مهم‌ترین رویکردها در حوزه‌ی هوش تجاری، می‌توان به پردازش تحلیلی برخط(OLAP)  و داده‌کاوی (Data Mining) اشاره کرد. ابزارهای OLAP با استفاده از  عملگرهایی از جمله Roll-up، Drill down، Slice، Dice، و یا Split و Merge امکان تحلیل چندبعدی داده‌‌ها را فراهم می‌سازند. داده کاوی عموماً به‌منظور کشف الگوهای موجود در مجموعه داده‌های بزرگ مورد استفاده قرار می‌گیرد.

اما همانطور که دسترسی به داده بعنوان منبع اطلاعات، می‌تواند یک امتیاز باشد، در عین حال می‌تواند  مشکل‌ساز و دردسرآفرین هم باشد. پدیده‌ه‌ای “سرریز اطلاعات(information overflow)”، “انفجار داده(Data explosion)” و  “کلان داده(Big data)”  نشان‌دهنده‌ی مشکلات زیادی هستند که از در دسترس بودن حجم عظیمی از داده‌ ها ناشی می‌شوند. انسان‌ها تنها قادر به پردازش حجم معینی از اطلاعات در یک بازه زمانی معین هستند. با افزایش حجم داده‌های در دسترس، چگونه می‌توان بدون اینکه به گیرنده‌های انسانی فشار وارد شود از این داده‌ها بطور صحیح استفاده کرد؟

منظور از داده‌کاوی، تحلیل داده بمنظور یافتن ارتباط میان داده‌ها و الگوهای موجود در حجم مشخصی از داده است. در واقع این الگوها چکیده‌ای از داده‌های تحلیل شده‌اند. این چکیده، پیچیدگی را کاهش داده و اطلاعات را در دسترس گیرنده قرار می‌دهد. هدف از فرایندکاوی، استخراج اطلاعات مربوط به فرایندهای کسب و کار می‌باشد. فرایندکاوی شامل “تکنیک‌ها، ابزارها و روش‌هایی برای کشف، پایش و بهبود فرایندهای واقعی از طریق استخراج دانش از گزارشات رویداد (event log) می‌‌باشد” .این داده‌ها در حین اجرای فرایندهای کسب و کار موجود در سیستم‌های اطلاعاتی تولید می‌شوند و از آنها به‌منظور بازسازی مدل‌های فرایندی استفاده می‌شود. این مدل‌ها برای تحلیل و بهینه سازی فرایندها، سودمند می‌باشند. فرایند کاوی یک رویکرد نوپا می‌باشد که که همانند یک پل، دو حوزه‌ی داده کاوی و مدیریت فرایندهای کسب و کار را باهم مرتبط می‌سازد. 

مفهوم فرایندکاوی برگرفته از متن کتاب “تحلیل فرایندهای مهندسی نرم افزار” نوشته‌ی Cook  و Wolf در اواخر دهه‌ 90 می‌باشد. Agrawal ، Gunopulos، Herbst و Karagiannis فرایند کاوی را به مفاهیم مدیریت جریان کار اضافه کردند. عمده‌ترین و اصلی‌ترین تلاش‌های انجام شده در این حوزه‌ در دهه‌ی اخیر توسط Van der Aalst و سایر محققین همکار او و از طریق توسعه‌ی الگوریتم‌های داده‌کاوی و اشاره به چالش‌های متنوع مرتبط با این موضوع، صورت گرفته است. این فعالیت‌ها منجر به پیدایش مجموعه‌ای از روش‌ها و ابزارها شد که در دسترس متخصصین این حوزه قرار گرفت. 

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

سوال مطالعاتی:A  دلیل اهمیت فرایندکاوی چیست و چرا می‌تواند بعنوان پلی میان داده‌کاوی و مدیریت فرایند کسب و کار (BPM) باشد؟

۲– مفاهیم پایه فرایندکاوی

   ۲-۱– مدل‌های فرایند و  گزارشات رویداد  (event logs)

هدف فرایندکاوی مدلسازی فرایندها بر اساس “داده‌های ثبت وقایع (log data)” موجود می‌باشد. در مفاهیم سیستم‌های اطلاعاتی، یک مدل نماینده‌ای مجرد از نمونه‌ی دنیای واقعی آن است که از آن  (مدل) برای هدفی معین استفاده می‌شود. از مدل می‌توان بمنظور کاهش پیچیدگی استفاده کرد، بدین سان که خصوصیات مورد نظر و مطلوب در مدل نمایش داده شوند و سایر خصوصیات حذف گردند. یک مدل فرایندی، نمایشی گرافیکی از یک فرایند کسب و کار است که به تشریح وابستگی‌های میان فعالیت‌هایی می‌پردازد که بصورت مجتمع و برای تحقق یک هدف کسب و کار معین، اجرا می‌گردند. این مدل شامل مجموعه‌ای از “فعالیت‌های مدل شده” و ارتباطات و شروط میان آنهاست.

مدل‌های فرایندی می‌توانند در قالب “زبان‌های مدلسازی فرایند” مختلف توصیف شوند؛ بعنوان مثال BPMN، “زنجیره‌های فرایندی مبتنی بر رویداد (Event Driven Process Chains – EPC)”یا شبکه‌های پتری (PetriNets).  شبکه‌های پتری بعنوان زبان غالب مدلسازی در زمینه‌ی فرایندکاوی شناخته می‌شود. با وجود اینکه زبان شبکه‌های پتری از قدرت (قدرت توصیف مدل) زیادی برخوردار است اما برای مخاطبینی که با گرامر (Syntax) و قواعد معنایی (Semantic) آن آشنا نیستند کاربرد چندانی نداشته و مناسب نمی باشد. BPMN قواعد معنایی را عموماً در قالب اشکال قابل درک ارائه می‌کند که این امر باعث می‌گردد تا درک آن برای افرادی که دارای پیش‌زمینه تئوری در حیطه‌ی انفورماتیک نیستند، آسانتر گردد. به همین دلیل در این مقاله از مدل‌های BPMN برای توصیف استفاده شده‌است.

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

شکل۱ – فرایند ایده‌آل خرید

مدل فرایند مذکور بصورت دستی ساخته شده است. بنابراین مشخص نیست که آیا مدل طراحی شده بیانگر و نماینده‌ی نمونه‌ی واقعی این فرایند می‌باشد یا خیر. فرایند ممکن است دستخوش رویدادهای مختلفی قرار گیرد بعنوان مثال ممکن است شرایطی پیش آید که فاکتورها قبل از دریافت کالاها پرداخت شوند.حتی ممکن است هیچ مرحله‌ای (state) برای ثبت رکوردهای کالاهای تحویل داده شده در نظر گرفته نشده باشد. در اینجا این سؤال پیش می‌آید که: چگونه می‌توان اطلاعاتی قابل اطمینان در مورد عملکرد واقعی فرایند کسب و کار بدست آورد؟

رویکرد مورد استفاده در فرایندکاوی برای پاسخ به این سوال بر پایه‌ی استفاده از داده‌هایی است که در سیستم‌های اطلاعاتی ذخیره شده‌اند که البته این داده‌ها با پردازش‌های انجام شده روی تراکنش‌های کسب و کار، تولید شده‌اند. در سیستم‌های اطلاعاتی، داده‌ها از طریق پردازش تراکنش‌ها  تولید شده و در پایگاه داده و یا فایل‌های ثبت وقایع (log files) ذخیره ‌می‌گردند. در مورد فرایند “تحویل سفارش”، داده‌های مربوط به نوع، تعداد کالاهای سفارش داده شده، فروشنده‌های مرجع، زمان سفارش و غیره ثبت و ذخیره می‌گردند. این داده‌ها می‌توانند از سیستم‌های اطلاعاتی استخراج شده و در قالب گزارشات رویداد (event logs) در دسترس و مورد استفاده قرار گیرند. این event logها داده‌های مورد نیاز برای الگوریتم‌های فرایند کاوی را فراهم می‌سازند.

                       جدول ۱ – ساختار گزارشات رویداد (event logs)

یک event log اساساً جدولی است که شامل تمامی رخدادهای (event) ثبت شده‌ی مرتبط با فعالیت‌های (Activity)  انجام شده در فرایند می‌باشد. هر رخداد به یک مورد (Case) نگاشت می‌گردد. یک مدل فرایندی در واقع انتزاعی از اجرای یک فرایند کسب و کار در دنیای واقعی است. اجرای یک واحد از فرایند کسب و کار را “نمونه فرایند” می‌نامند. این نمونه فرایندها در قالب مجموعه‌ای از رخدادهای نگاشت شده به مورد (case) نمود می‌یابد. توالی (trace)را ترتیب رخدادهای ثبت شده در یک مورد می نامند. “مدل نمونه فرایند” یا Process instance model، مدلی است که توصیف‌گر اجرای یک نمونه فرایند می‌باشد. یک مدل فرایندی، انتزاعی از “رفتار نمونه‌ فرایندها” می‌باشد که منعکس‌کننده رفتار تمام نمونه‌هایی است که متعلق به یک فرایند هستند.  موارد (cases) و رویدادها (events)  توسط “طبقه‌بندی کننده‌ها” (classifier) و صفاتشان  مشخص می‌گردند. طبقه‌بندی کننده‌ها با نگاشت کردن اسم‌های یکتا به هر رخداد و مورد از صحت و اعتبار آن ها اطمینان حاصل می‌کنند‌. صفت‌ها اطلاعات تکمیلی را ذخیره ‌می‌کنند که در آینده می‌توانند برای اهداف تحلیلی مورد استفاده قرار گیرند. در جدول ۱ نمونه‌ای از یک event log نمایش داده شده است.

سؤال مطالعاتی:B  تفاوت میان گزارشات رخداد، مورد، رخداد و توالی چیست و این عناصر چگونه با یکدیگر مرتبط می‌گردند؟

   ۲-۲– رویه کاوش 

شکل ۲ بررسی اجمالی فعالیت‌های مختلفی است که در فرایندکاوی ارائه شده است. قبل از اینکه قادر به‌ بکارگیری هرگونه تکنیک فرایندکاوی باشیم، ابتدا باید به داده‌ها دسترسی داشته باشیم. این داده‌ها باید از سیستم‌های اطلاعاتی مناسب استخراج شوند. با توجه به نوع منبع اطلاعاتی (سیستم تأمین‌کننده اطلاعات)، داده‌های مربوطه در میان جداول مختلف پایگاه داده توزیع گردیده‌اند. داده‌های وارد شده در پایگاه داده را باید به شکلی معنادار ترکیب نموده تا آماده‌‌ی استخراج گردند. حجم داده‌ها می‌تواند یکی دیگر از موانع باشد. با توجه به هدف فرایندکاوی، احتمال اینکه میلیون‌ها داده‌ی ورودی یا داده ثبت شده نیاز به استخراج داشته باشند، وجود دارد که البته این کار نیازمند بکارگیری روش‌های کارآمد استخراج {داده} می‌باشد. “قابلیت اطمینان” یکی‌ دیگر از جنبه‌های مهم استخراج داده می‌باشد. ممکن است داده‌های استخراج شده حاوی اطلاعات شخصی باشند که در اینگونه موارد، با توجه به الزامات قانونی، ممکن است ملزم به “گمنام سازی یا مخفی‌سازی اطلاعات” شویم.

شکل ۲ – تشریح روال کاوش

قبل از اینکه بتوان از event log  استخراج شده استفاده نمود باید این event log را فیلتر و در نرم افزار مورد نظر بارگذاری نماییم. فیلتر کردن (پالایش) داده‌ها دلایل بسیاری دارد؛ سیستم‌های اطلاعاتی عاری از خطا نیستند و  ممکن است داده‌های ذخیره شده منعکس‌کننده عملکرد واقعی فعالیت‌ها نباشند. خطاها می‌توانند به دلیل عملکرد اشتباه برنامه‌ها و همچنین اشتباهات کاربر و یا بروز نقص سخت افزاری بوجود آمده و باعث ثبت داده‌های نادرست در event log گردند.

یک فرایند مشخص، معمولاً در یک بازه‌ی زمانی معین تحلیل می‌گردد. هنگامی که داده‌ها از سیستم مرجع استخراج شدند، نمونه فرایندهایی که در بازه‌ی زمانی تعیین شده اجرا شده‌اند می‌توانند حذف گردند. این نمونه فرایندها باید بطور کامل از event log استخراج شده یا حذف گردند؛ در غیر اینصورت این نمونه فرایندها موجب اختلال در مدل‌های فرایندی بازسازی شده می‌شوند. معمولاً داده‌های موجود در event log ها فقط منحصر به یک فرایند نیستند. برای مختصرسازی یا کم کردن حجم event log نیاز به فیلتر کردن داده‌‌ها داریم، چرا که با این کار می‌توان اطمینان حاصل کرد که event log تنها حاوی رخدادهایی است که فرایند مرتبط با آنها بدقت بررسی شده است. این نوع فیلترینگ باید بدقت انجام شود چرا که ممکن است باعث بروز نقص در نمونه فرایندها گردد. در این خصوص یکی از معیارهای رایج، انتخاب فعالیت‌هایی است که به فرایند مورد نظر مرتبط هستند. فیلتر کردن و بارگذاری داده‌ها عموماً توسط ابزارهای نرم افزاری و در یک مرحله انجام می‌شود. اما امکان انجام این کار بصورت مجزا هم وجود دارد.

به محض اینکه داده‌ها در نرم‌افزار فرایندکاوی بارگذاری شدند، کاوش اصلی و بازسازی مدل فرایند می‌توانند آغاز گردند. این کاوش شامل کشف ارتباطات موجود در داخل event log می‌باشد، در‌حالی‌که عملیات بازسازی به تولید یک مدل فرایندی می‌پردازد که آن را بصورت گرافیکی نمایش می‌دهد. کاوش و بازسازی مدل‌های فرایندی عموماً توسط یک نرم‌افزار و در یک مرحله انجام می‌شود.

پس از اینکه کاوش و بازسازی مدل‌های فرایندی انجام شد می‌توان از آن‌ها برای هدف اصلی مورد نظر (تحلیل) استفاده نمود. این مرحله را می‌توان تحت عنوان “تجزیه و تحلیل شرایط” (term analysis)  خلاصه نمود.  یکی از اهداف بنیادی فرایند کاوی کشف فرایندهای ناشناخته می‌باشد. در چنین مواردی بازسازی فرایند به خودی خود بعنوان یک هدف شناخته می‌شود. اما فرایند کاوی تنها به این موارد محدود نمی‌شود. عملیات تحلیل ممکن است اهداف دیگری را نیز دنبال کند. از جمله این اهداف می‌توان بعنوان مثال شناسایی فرصت‌ها و موقعیت‌های بهینه‌سازی فرایند، شناسایی جنبه‌های سازمانی و نظارت و بررسی مطابقت را نام برد.

   ۲-۳– الگوریتم‌های کشف

الگوریتم کاوش، مؤلفه‌ی اصلی در فرایند کاوی می‌باشد. این الگوریتم‌ها چگونگی ساخته شدن مدل‌های فرایندی را تعیین می‌کنند. در ادامه 3 گروه از این الگوریتم‌‌ها را با جزئیات بیشتر، مورد بررسی قرار می‌دهیم:

1. الگوریتم‌های کاوش قطعی  (Deterministic)
2. الگوریتم‌های اکتشافی  (Heuristic)
3. الگوریتم‌های ژنتیک  (Genetic)

قطعی به این معناست که یک الگوریتم نتایجی معین و قابل تکرار را تولید می‌نماید. این نوع از الگوریتم‌ها در ازای یک داده‌ی ورودی مشخص، همیشه خروجی (نتیجه) یکسانی را ارائه خواهند داد.  الگوریتم آلفا (α) بعنوان نماینده این نوع از الگوریتم‌ها شناخته‌ می‌شود. در واقع این الگوریتم یکی از اولین الگوریتم‌هایی بود که توانایی مقابله با مسئله‌ی همزمانی (concurrency) را داشت. این الگوریتم event log را بعنوان ورودی دریافت نموده و ترتیب (رابطه‌ی ترتیبی) رخدادهای موجود را محاسبه می‌نماید.

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

الگوریتم‌های ژنتیک از یک رویکرد تکاملی استفاده می‌کنند که این رویکرد در واقع از فرایند “تکامل تدریجی در طبیعت” تقلید می‌نماید. این الگوریتم ها شامل ۴ مرحله می‌باشند:

1. مقداردهی اولیه  (Initialization)
2. انتخاب
3. تولید مجدد یا تکثیر
4. خاتمه (انقضاء)

ایده‌ی اصلی این الگوریتم‌ها تولید یک جمعیت تصادفی از مدل‌های فرایندی و همچنین یافتن راهکاری مطلوب از طریق انتخاب مکرر هرکدام از مدل‌ها (بصورت منفرد) و تولید مجدد آن‌ها از طریق “روش متقاطع  “(crossover) و متحول سازی مدل مورد نظر با توجه به سایر مدل‌های تولید شده می‌باشد. جمعیت اولیه‌ی مدل‌های فرایندی بصورت تصادفی تولید می‌شود و ممکن است با event log وجوه اشتراکی داشته باشد. اما بعلت تعداد زیاد مدل‌ها در جمعیت تولید شده، انتخاب و تولید مجدد (تکثیر) مدل‌های مناسب‌تر در هر بار از تولید {جمعیت} صورت می‌گیرد. 

با توجه به الگوریتم مورد استفاده، خروجی فرایندکاوی می‌تواند متفاوت باشد.  در اینجا از event log نمایش داده شده در جدول ۲ برای تشریح مدل‌های ساخته شده توسط الگوریتم‌های مختلف کاوش و همچنین بمنظور ادراک نحوه‌ی عملکردکاوش (فرایندکاوی) استفاده شده است.

جدول ۲ – نمونه  event log

 

event log مورد نظر شامل تعداد محدودی رخداد و مورد می‌باشد. با این وجود برای نمایش دادن جنبه‌های کلیدی مرتبط با فرایندکاوی، و همچنین انتخاب الگوریتم‌های کاوش، مناسب هستند.

تصویر ۳ مدل فرایند کاوش شده‌ای را نمایش می‌دهد که با اعمال الگوریتم آلفا (α) بر روی event log بازسازی شده‌ است. بمنظور مقایسه‌پذیری بهتر، این مدل فرایندی به یک مدلBPMN  تبدیل شده است.  واضح است که این مدل  با مدلی که در تصویر ۱ نمایش داده شد، مطابقت ندارد. این مسئله به این علت است که event log  کاوش شده شامل مواردی است که از اجرای خطی مسیر فرایند نمایش داده شده در تصویر ۱ منحرف شده‌اند. در مورد ۳، فاکتور قبل از اجناس دریافت می‌شود. با توجه به اینکه هر دو احتمال در event log وجود دارد (در موارد ۱، ۲ و ۵ اجناس قبل از فاکتور دریافت می‌شوند و در مورد ۳، فاکتور قبل از جنس دریافت می‌شود) الگوریتم کاوش با این فرض پیش می‌رود که این فعالیت‌ها می‌توانند باهم و بصورت موازی انجام شوند.

شکل ۳- مدل فرایندکاوش شده توسط الگوریتم آلفا (α)  

با نگاه دقیق‌تر به مدل نمایش داده شده در شکل ۳ متوجه نکته‌ی مهم دیگری می‌شویم. در حقیقت مورد ۴ در مدل فرایند منعکس نشده‌ است. هیچ ترتیب اجرایی در مدل قادر به بازسازی مسیر مورد ۴ نمی‌باشد. این مدل تنها به دو “ترتیب اجرایی”  امکان اجرا می‌دهد:  ABCD و ACBD اما به ACD اجازه اجرا داده نمی‌شود.  دروازه یا گذرگاه (gateway) پایانی بعد از فعالیت “order the goods” یا “سفارش کالا” نیازمند اجرای هر دو شاخه (مسیر) می‌باشد. بنابراین امکان وجود یک ترتیب اجرایی بدون اجرا شدن فعالیت B وجود ندارد. این مدل بعلت عدم توانایی در منعکس ساختن تمام مسیرهای مناسب درevent log، از میزان مطلوبیت و برازش ضعیفی برخوردار است. مدل نمایش داده شده در شکل ۴ امکان پیمایش مجدد تمام مسیرها را دارد. با توجه به دروازه‌های انحصاری (exclusive-gateways)، امکان اجرا شدن تمام مسیرهای  ABCD، ACBD  و ACD  وجود دارد. اما حالا این مسئله پیش می‌آید که تعداد ترتیب اجراهای ممکن، بسیار بیش‌تر از چیزی است که در event log منعکس شده است. در حقیقت مدل فرایندی اجازه‌ی وجود مجموعه‌ای نامتناهی از ترتیب‌های اجرایی را می‌دهد. حالا امکان اضافه کردن حلقه (loop) در مدل فرایند وجود دارد؛ این حلقه‌ها می‌توانند از B شروع شده و به C بروند یا از C به B و می‌توانند مسیرهایی را ایجاد کنند که شامل بینهایت تکرار از B به C یا بالعکس باشند. بعنوان مثال ترتیب ABCBCD امکان‌پذیر است، اگر چه در event log بعنوان یک مسیر وجود ندارد.

اگر یک مدل فرایندی بیش از حد عمومیت داشته باشد، “کم برازش(Under-fitting) ” نامیده می‌شود.  چنین مدل‌هایی از دقت پایینی برخوردار هستند. یکی از چالش‌های اصلی در فرایندکاوی یافتن راهکار مناسب با درنظر گرفتن معیارهای ذیل می‌باشد:

1. 1.  تناسب  (fitness)
2. دقت  (precision)
3. سادگی  (simplicity)
4. امکان تعمیم  (generalizability)

شکل ۴- مدل فرایند نامطلوب

الگوریتم‌های کاوش پیشرفته و متنوعی وجود دارند که می‌توانند برای اهداف مختلف مورد استفاده قرار گیرند. تصویر ۵ مدل کاوش شده‌ای را نمایش می‌دهد که از الگوریتم اکتشافی (Fuzzy  Miner) استفاده می‌نماید. این مدل از استاندارد BPMN  تبعیت نمی‌کند اما در عوض توسط یک گراف وابستگی نمایش داده شده است. این تصویر شامل هیچگونه دروازه‌ای (Gateway) نمی‌باشد اما وابستگی‌های مابین فعالیت‌های مختلف را نمایش می‌دهد.  بعنوان مثال این گراف نمایانگر این است که فعالیت A، سه بار توسط فعالیت B و دوبار توسط فعالیت C  دنبال شده است.

شکل ۵- مدل فرایندکاوش شده توسط الگوریتم Fuzzy Miner

یکی از موارد حائز اهمیت، شناسایی نیازمندی‌هایی است که برای دستیابی به اهداف هر پروژه‌ی فرایندکاوی باید مورد ملاحظه و بررسی قرار گیرند. میزان تناسب یا کارآمدی یک الگوریتم باید با توجه به حوزه‌ی {کاربرد} نرم‌افزار مورد استفاده، ارزیابی گردد.

سؤال مطالعاتی C: چرا الگوریتم‌های مختلف فرایندکاوی، مدل‌های فرایندی مختلف تولید می‌کنند؟

۳– حوزه های کاربرد نرم‌افزار

   ۳-۱– کشف و بهبود فرایند

یکی از حوزه‌های اصلی در زمینه نرم افزارهای فرایندکاوی، کشف مدل‌های فرایندی ناشناخته به‌منظور تحلیل یا بهینه‌سازی می‌باشد.  مهندسی مجدد فرایندها (Business Process Reengineering) و پیاده‌سازی سیستم‌های ERP از اوایل دهه‌ی 90 مورد توجه سازمان‌ها قرار گرفتند. همزمان با این رویدادها، کارشناسان این حوزه هم تمرکز اصلی خود را بر طراحی و پیاده‌سازی فرایندها و بکارگیری آنها گذاشتند. رفته رفته و با تکامل یکپارچه‌سازی سیستم‌های اطلاعاتی و حرکت آن‌ها به سمت اجرای فرایندهای کسب و کار و همچنین تکامل امکانات فنی جدید، تحلیل و بهینه‌سازی فرایندها در کانون تمرکز قرار گرفت.

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

تحلیل و بهینه‌سازی تنها محدود به بررسی پس از زمان اجرا (post-runtime)  نبوده و می‌تواند بعنوان “پشتیبان عملیاتی”(operational support)  مورد استفاده قرار گیرد؛ در این عملیات (پشتیبان عملیاتی) مسیرهایی کشف می‌شوند که در حال اجرا بوده و از مدل فرایندی تعیین شده تبعیت نمی‌‌کنند. همچنین می‌توان برای پیش‌بینی رفتار مسیرهای در حال اجرا نیز از این عامل (تحلیل و بهینه‌سازی) بهره برد. یکی از مثال‌هایی که در ارتباط با تحلیل زمان اجرا می‌توان به آن اشاره نمود، پیش‌بینی زمان اتمام مورد انتظار از طریق مقایسه‌ی نمونه‌ی (instance) در حال اجرا با سایر نمونه‌های پردازش شده می‌باشد. یکی دیگر از ویژگی‌ها فراهم ساختن مجموعه‌ای از پیشنهادها به‌منظور انتخاب فعالیت‌های (activity) بعدی در فرایند توسط کاربران می‌باشد. همچنین می‌توان از فرایندکاوی بمنظور بدست آوردن اطلاعات مورد نیاز برای طراحی فرایندها (قبل از پیاده‌سازی‌شان) استفاده نمود.

   ۳-۲–  بررسی انطباق  (Conformance Checking)

“بررسی انطباق” نوعی خاص از تحلیل در فرایندکاوی می‌باشد. برای اینکه قادر به اجرای این بررسی باشیم باید فرض را بر وجود مدل فرایندی قرار دهیم که نماینده و بیانگر فرایند مورد نظر می‌باشد. با توجه به هدف مذکور، اهمیتی ندارد که مدل فرایندی با استفاده از مدل‌سازی‌های مرسوم و قدیمی (دستی) تولید شده یا با استفاده از فرایندکاوی. 

در گام بعدی به‌منظور مشخص شدن انطباق یا عدم انطباق (انحراف) رفتارها (behavior)، باید event log موجود را با مدل ایده‌آل مقایسه نمود.  نمونه‌های فرایند (process instance) به همان شکلی در log نمایش داده می‌شوند که موردها (Case) در یک مدل شبیه‌سازی و نمایش داده می‌‌شوند. مواردی (Case) که می‌توانند مجدداً اجرا و پیمایش شوند (تکرار شوند) برچسب “منطبق (conform)” و مواردی که نمی‌توانند مجدداً پیمایش شوند برچسب “نامنطبق  یا منحرف (deviant)” دریافت نموده و مشخص می‌گردند.

اگر انطباق event log در جدول 2 را با مدل فرایند نمایش داده شده در شکل 2 مورد مقایسه و بررسی کنیم، مشاهده می‌کنیم که موارد 1، 2 و 5 با مدل مطابقت دارند (منطبقند) در حالیکه موارد 3 و 4 منطبق با مدل مورد نظر نبوده و نسبت به آن “انحراف” دارند. عموماً استفاده از این عبارت ساده که “موردها منطبق هستند یا خیر” به تنهایی کافی نیست. مورد فرضی با گام مسیر ABCDD به این معناست که برای جنسی که سفارش داده شده و تحویل گرفته شده است، دوبار فاکتور صادر گردیده و این عدم انطباق با فرایند ایده‌آل اهمیت زیادی دارد و بعد از این مورد، ترتیب اشتباه فعالیت‌های B و C در مسیر ACBD که در مورد 3 قابل مشاهده‌ می‌باشد در درجه‌ی دوم اهمیت قرار دارند. عموماً “عیب‌یابی محلی” می‌تواند به نحوی محاسبه گردد که نتیجه‌ی آن در موارد ذیل بصورت برجسته نمایش داده شود:

1. برجسته‌سازی نقطه ای در مدل که نمایانگر انحراف‌ها و عدم مطابقت‌هاست.
2. برجسته‌سازی “معیارهای عمومی تطابق (global conformance measures)” که مشخص‌کننده میزان کلی مطابقت مدل با event log می‌باشند.

زمانی که در حال “بررسی انطباق” (conformance checking)  هستیم باید همیشه این نکته را بیاد داشته باشیم که هر انحراف یا عدم تطابقی لزوماً منفی نیست.  ممکن است بیشتر انحراف‌ها از مدل ایده‌آل به این معنا باشند که مدل مورد بررسی، منعکس‌کننده شرایط محیطی و نیازمندی‌های دنیای واقعی نمی‌باشند.

   ۳-۳–  بررسی تبعیت   Compliance Checking

عبارت “تبعیت” به رعایت و پیروی از قوانین داخلی و خارجی اشاره دارد. قوانین خارجی عمدتاً شامل قواعد و مقررات کلی می‌‌باشند. اما علاوه بر موارد ذکر شده این قوانین همچنین می‌توانند منعکس کننده استانداردهای صنعت و نیازمندی‌ها و الزامات خارجی هم باشند. قوانین داخلی شامل دستورهای مدیریتی، سیاست‌ها و استانداردها می‌شوند. در واقع بررسی پیروی از قوانین متناسب (در فرایند) به عهده‌ی “بررسی تبعیت” می‌باشد. “بررسی تبعیت” بویژه در زمینه‌ی بازبینی قوانین داخلی  و خارجی حائز اهمیت می‌باشد.

فرایندکاوی امکانات جامع و جدیدی را برای “بررسی تبعیت” ارائه نموده است. یکی از این مزایای اصلی، همانطور که قبلاً هم به آن‌ اشاره شد، قابلیت اطمینان و معتبر بودن اطلاعات استفاده شده می‌باشد؛ همچنین فرایندکاوی در زمینه‌ی “تبعیت” تأثیرگذاری بیشتری دارد چرا که در تکنیک‌های قدیمیِ جمع‌آوری اطلاعات- بعنوان مثال در مصاحبه‌ها،- افراد بعلت مواجه شدن با پیامدهای منفی و ناخوشایند احتمالی، از اقرار به رفتارها یا عملکردهای نامطلوب (در زمینه‌ی اجرای فرایند) خودداری می‌کنند.

برای نمایش تفاوت “بررسی مطابقت “(Conformance Checking)  با ” بررسی تبعیت “(Compliance Checking) به یکی از قوانین تبعیت رایج و شناخته شده به نام “قاعده‌ی چهار چشم” اشاره می‌کنیم. این قانون بیانگر این‌ است که بمنظور جلوگیری از بوجود آمدن خطا و تخلف در اجرای یک فرایند کسب و کار، حداقل 2 نفر باید در فرایند شرکت داشته و با آن درگیر باشند. کشف و جلوگیری از بروز خطا در صورت وجود نفر دوم احتمال بیشتری دارد، از طرف دیگر احتمال تخلف هم کمتر می‌شود چراکه تخلف فقط زمانی می‌تواند صورت گیرد که این دو نفر با یکدیگر تبانی کرده باشند.

“بررسی تبعیت” حوزه‌ی تحقیقاتی نسبتاً جدیدی در زمینه‌ی فرایندکاوی می‌باشد. این حوزه را می‌توان به 3 بخش مجزا تقسیم نمود:

1. بررسی تبعیت قبل از زمان اجرا (Pre-runtime)
2. بررسی تبعیت در زمان اجرا (Runtime)
3. بررسی تبعیت بعد از زمان اجرا (Post-runtime)

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

 روش‌های مختلفی برای “بررسی تبعیت قبل از زمان اجرا” وجود دارند که بخشی از این روش‌ها (روش‌های اولیه) بصورت مشترک در “بررسی بعد از زمان اجرا” نیز وجود دارند. اما قبل از اینکه راهکارهای مرتبط با بررسی تبعیت در اختیار کارورزان قرار گیرند، همچنان نیاز به توسعه دارند.

   ۳-۴– کاوش سازمانی  (Organizational Mining)

تاکنون تمرکز ما بر کنترل جریان مدل‌های فرایندی از طریق بازرسی ترتیب فعالیت‌های موجود در یک مدل فرایندی بوده است. همانطور که در مثال‌ها نمایش داده شد، صفات دیگری در event log وجود دارند که فرصت‌های مناسبی را به‌منظور بررسی فرایند در اختیار ما قرار می‌دهند.

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

سؤال مطالعاتی : D تفاوت میان بررسی تبعیت و بررسی مطابقت را شرح دهید.

۴– پشتیبانی ابزاری

نرم افزارهای کاربردی (مبتنی بر فرایند) نیازمند ابزارهای فرایند کاوی می‌باشند. جدول 3 مجموعه‌ای از ابزارهای موجود را نمایش می‌دهد.

جدول 3- ابزارهای فرایندکاوی (تجاری C=،  متن باز = O)

یکی از ابزارهای اصلی و متن باز، ProM  می‌باشد. این ابزار افزونه‌های (plugin) مختلفی را برای بسیاری از الگوریتم‌های کاوش فراهم می‌سازد. از جمله این افزونه‌ها می‌توان به ماژول‌های تحلیل، تبدیل(conversion)  و صدور (صدور داده(export-  اشاره نمود.  Discoیک نرم افزار تجاری است که درک و کاربری آسان از مزایای این ابزار می‌باشند. پالایش  و بارگیری event logها بصورت یکپارچه از دیگر قابلیت‌هایی است که این ابزار فراهم می‌سازد. از این‌رو این ابزار برای افراد مبتدی در حوزه‌ی فرایندکاوی مناسب می‌باشد. همچنین یک نسخه‌ی غیر تجاری از این ابزار برای مراکز دانشگاهی در دسترس می‌باشد.

هیچکدام از این ابزارها قابلیت استخراج “داده‌های رخدادی(event data) ” از منابع داده را ندارند. استخراج اینگونه داده‌ها باید توسط نرم‌افزارهای مختص استخراج داده و یا با استفاده از قابلیت‌های صدور داده در سیستم‌های مرجع (منبع و منشاء داده)، صورت پذیرد.

۵– چالش‌ها و سؤالات تحقیقاتی متداول

   ۵-۱–  رکوردهای مخدوش و ناقص  (Noise and Incompleteness)

همانطور که قبلاً هم اشاره شد، وجود رکوردهای نادرست و معیوب در event log می‌تواند دلایل مختلفی داشته باشد بعنوان مثال عملکرد بد نرم‌افزار، اشتباهات کاربر، نقص‌های سخت‌افزاری و یا وجود نقص در نمونه‌های فرایندی (process instance) در هنگام استخراج اطلاعات، از جمله عوامل وجود اینگونه رکوردها می‌باشند. علت مخدوش بودن برخی از رکوردها وجود پدیده‌ای به نام نویز (noise) می‌باشد که این نوع رکوردها نباید با سایر رکوردهای نادرست موجود در event log در یک گروه قرار گیرند. در واقع نویز به رکوردهایی اشاره دارد که به درستی ثبت شده‌اند اما رفتارهای غیرعادی و نادری دارند. وجود نویز در داده‌ها در نهایت  منجر به افزایش پیچیدگی در مدل فرایند می‌گردد. بنابراین رویکردهای فرایندکاوی باید توانایی اداره و یا فیلتر کردن نویز را داشته باشند. اما این موضوع باید بیشتر مورد بحث قرار گیرد چرا که نویز از لحاظ “مفهوم” و “نقش” انواع مختلفی دارد که نوع آن وابسته به هدفی است که یک پروژه فرایندکاوی دنبال می‌نماید. در عین حال که برای کاهش پیچیدگی در مدل بازسازی شده، احتمال نیاز به استخراج چکیده‌ای از رفتارهای غیرمعمول وجود دارد، باید این نکته را هم مدنظر قرار داد که رفتارهای غیرمعمول و همچنین سایر رفتارهای خارج از حوزه‌ی فرایند، از جنبه‌های کلیدی هستند که در مباحث “بررسی تبعیت” و “بررسی مطابقت” مورد استفاده قرار می‌گیرند. حال باید دید که چگونه می‌توان نویز را از سایر رکوردهای نادرست و معیوب، متمایز ساخت. از این‌رو با توجه به سؤال مطرح شده لازم است که این نویزها برای هر پروژه بصورت جداگانه مورد بررسی قرار گرفته و اداره شوند.

رفتاری که در event log ثبت نشده نمی‌تواند برای کاوش در یک مدل فرایند مورد استفاده قرار گیرد. از طرف دیگر ماهیت مدل‌های فرایندی بگونه‌ای است که اجازه‌ی رفتارهای بسیار بیشتری نسبت به آنچه که در event log  ثبت شده‌ است را می‌دهد. در تصویر شماره 4 مشاهده کردیم که مدل فرایند نمایش داده شده در این تصویر به تعداد نامحدودی از ترتیب‌ها اجازه‌ی اجرا می‌دهد، این در حالیست که event log تنها شامل 5 مورد (case)   با 3 مسیر(trace)  مختلف می‌باشد. نویز به مشکل بالقوه‌ی ذخیره‌ی بیش از حد داده در event log اشاره دارد در حالیکه “نقص داده” (incompleteness)  بیانگر مشکل کمبود داده می‌باشد  (too little data). تصور اینکه یک event log تمامی اجراهای ممکن یک فرایند را شامل می‌شود، فرضیه‌ی اشتباهی است. هنگامی که یک پروژه‌ی فرایندکاوی در حال اجرا می‌باشد باید از وجود و در دسترس بودن یک event log مناسب و کارآمد به‌منظور کشف ساختار کنترل جریان اصلی، اطمینان حاصل کرد.

   ۵-۲– معیارهای رقابت کیفی مدل‌ها

برای تعیین میزان کیفیت جنبه‌های مختلف در فرایندهای بازسازی شده، می‌توان از چهار معیارکیفی اصلی استفاده نمود:

1. تناسب (fitness) بیانگر توانایی یک مدل در پیمایش مجدد تمام رفتارهای ثبت شده در یک event log  می‌باشد.
2. سادگی(simplicity)  به این معناست که ارجحیت  با ساده‌ترین مدلی است که توانایی تشریح رفتار مشاهده شده (مورد نظر) را دارد.
3. دقت (precision) نیازمند این است که مدل به رفتارهایی که با رفتارهای ثبت شده در event log تفاوت زیادی دارند، اجازه عمل ندهد.
4. عمومیت(generalization)  به این معناست که یک مدل فرایندی نباید منحصراً محدود به نمایش رکوردهای مربوط به رفتارهای موجود در event log گردد، بلکه این مدل باید بتواند چکیده‌ای از رفتارها را از نمونه فرایندهای مشخص استخراج نموده و {در سایر نمونه‌ها} تعمیم دهد.

شکل 6 – ابعاد کیفیت

همانطور که در شکل 6 نمایش داده شده، معیارهای کیفیت به رقابت با یکدیگر می‌پردازند. این امر به این معناست که وجود تمامی این معیارها بطور کامل در کنار یکدیگر بصورت همزمان امکان پذیر نمی‌باشد. به عنوان مثال مدل نمایش داده شده در شکل 3 دقت بسیار بالایی را نمایش می‌دهد چرا که به سایر رفتارها که در log وجود ندارند اجازه عمل نمی‌دهد اما این مدل “مطلوبیت و شایستگی” ضعیفی دارد چرا که توانایی پیمایش تمام موردها  را ندارد. مدل نمایش داده شده در شکل 4 بیانگر یک برازش کامل می‌باشد زیرا قادر به پیمایش تمامی موردهای (case) موجود در event log می‌‌باشد؛ اما در عین حال از دقت ضعیفی برخودار است چراکه به تعداد نامحدودی از ترتیب‌های اجرا که در event log موجود نمی‌باشند نیز اجازه‌ی اجرا می‌دهد. با توجه به خروجی مورد نظر (خروجی فرایندکاوی) و همچنین استفاده‌های آینده از مدل‌های فرایند بازسازی‌ شده؛ می‌بایست برای هر پروژه‌ی فرایندکاوی به توازنی مناسب از معیارهای کیفیت دست یافت.

۵-۳–  تعیین کیفیت و برچسب‌گذاری  event log

کیفیت event logها عامل اصلی تعیین‌کننده کیفیت مدل‌های فرایندی‌ است که تحت کاوش قرار گرفته و بازسازی شده‌اند. سیستم‌های مدیریت فرایند کسب و کار و سیستم‌های مدیریت جریان کار، event logهایی با بیشترین کیفیت را ارائه می‌دهند. تمرکز اصلی این سیستم‌ها بر پشتیبانی و مکانیزه‌سازی اجرای فرایندهای کسب و کار می‌باشد و از اینرو ذخیره‌سازی داده‌های رخدادی (event data) با کیفیت بالا توسط اینگونه سیستم‌ها بسیار محتمل است؛ که از این داده‌ها می‌توان به‌منظور فرایندکاوی استفاده نمود. عموماً داده‌های استخراج شده از سیستم‌های ERP، نمی‌توانند کیفیتی همانند داده‌های موجود در event logها را ارائه دهند.

یک فرضیه‌ی بنیادی در ارتباط با روش‌های رایج فرایندکاوی بیانگر این است که رخدادهای موجود در یک event log  به موردهای (case)متناظرشان نگاشت شده‌اند. اما این قضیه بستگی به کیفیت  event log  موجود دارد و همچنین اینکه آیا این رخدادها واقعاً مربوط به case مورد نظر هستند یا خیر. سیستم‌های ERP بعنوان یکی از منابع اصلی داده‌های تراکنشی در سازمان‌ها، معمولاً داده‌هایی که رخدادها را به موردها نگاشت کنند، ذخیره نمی‌کنند. یکی از روش‌های جالب برای “برچسب‌گذاری داده‌های رخدادی” توسط Ferreira  و Gillblad  ارائه شده است. بررسی “حیطه‌ی نرم‌افزار کاربردی” یکی دیگر از رویکردهای محتمل است که می‌تواند مورد تأمل و بررسی قرار گیرد. Gehrke و  Müller-Wickop الگوریتم کاوشی را ارائه نموده‌اند که توانایی کارکردن با  رخدادهای برچسب‌گذاری نشده را دارد و نحوه‌ی عملکرد این الگوریتم به این‌صورت است که از ساختارهای شاخص و منحصر بفرد موجود در داده‌ها استفاده نموده و در نهایت از این طریق و در طی فرایند کاوش، رخدادها را به موردها نگاشت می‌نماید.

۵-۴– مدل‌های فرایندی پیچیده

مثال‌های ارائه شده در شکل‌های 2 و 3، مدل‌های فرایندی بسیار ساده‌ای را به نمایش می‌‌گذارند. فرایندهای دنیای واقعی عموماً از پیچیدگی بیشتری برخوردارند. نمایش گرافیکی اینگونه‌ فرایندها -همانطور که در شکل 7 نمایش داده شده است- می‌تواند منجر به مدل‌های بسیار پیچیده و نامفهوم گردد. مدل‌های فرایندی پیچیده با توجه به ظاهر درهم تنیده‌شان به دو گروه اصلی تقسیم می‌گردند:

1. فرایندهای لازانیا  (lasagna)
2. فرایندهای اسپاگتی  (spaghetti)

کاهش پیچیدگی، یکی از چالش‌های اصلی و همچنین یکی از موضوعات تحقیقات اخیر می‌باشد.

                         شکل 7- مثالی از یک مدل فرایند پیچیده

۵-۵–  انحراف مفهوم  (Concept Drift)

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

سؤال مطالعاتیE: چرا باید از برقراری توازن میان معیارهای کیفیت (در فرایندکاوی) اطمینان حاصل کرد؟

۶– نتیجه گیری

فرایندکاوی همانند یک پل ارتباطی عمل نموده و حوزه‌های داده‌کاوی و مدیریت فرایندهای کسب و کار را با هم مرتبط می‌سازد. افزایش یکپارچه‌سازی سیستم‌های اطلاعاتی به‌منظور پشتیبانی و مکانیزه‌سازی اجرای تراکنش‌های کسب وکار، بستر مورد نیاز برای انواع روش‌های تحلیل داده را فراهم می‌سازد. از داده‌های ذخیره شده در سیستم‌های اطلاعاتی می‌توان به‌منظور کاوش و بازسازی مدل‌های فرایند کسب و کار استفاده نمود. این مدل‌ها بنیان و پایه‌ای هستند برای حوزه‌های مختلف و متنوع نرم‌افزاری از قبیل: تحلیل فرایند، بهینه‌سازی، بررسی تبعیت و بررسی مطابقت  Event logها. مدل‌های فرایندی و الگوریتم‌های کاوش از عناصر پایه‌ای در حوزه‌ی فرایندکاوی می‌باشند. در این مقاله مفاهیم ضروری فرایندکاوی و حوزه‌های نرم‌افزاری اصلی و همچنین ابزارهای موجود و مرتبط با آنها به اختصار تشریح شد.

فرایندکاوی همچنان بعنوان یک مبحث تحقیقاتی نوپا شناخته می‌شود و البته این نکته را هم باید در نظر داشت که هنگام استفاده از فرایندکاوی‌ باید سایر مفاهیم مرتبط با آن را نیز مورد بررسی قرار دهیم (نویز، توزیع مناسب، معیارهای رقابت کیفی و …). اگرچه برخی از حوزه‌های از قبیل برچسب گذاری رخدادها، کاهش پیچیدگی در مدل‌های کاوش شده، و پدیده‌ای بنام “انحراف مفهوم” هنوز نیاز به تحقیقات بیشتری دارند؛ اما مجموعه متدها وابزارهای موجودمی‌توانند منبعی غنی برای مدیریت مؤثر فرایندهای کسب و کار باشند.

۷–  بازبینی سؤالات و پاسخ‌ها

سؤال مطالعاتی  A: دلیل اهمیت فرایندکاوی چیست و چرا می‌توان آنرا بعنوان یک پل ارتباطی میان داده‌کاوی و BPM تعریف کرد؟

پاسخ: هوش تجاری {بعنوان یک رویکرد مهم} از داده‌های ذخیره شده در سیستم ‌های اطلاعاتی بمنظور تسهیل و بهبود فرایند تصمیم‌گیری و غلبه بر چالش‌هایی نظیر “انفجار داده (data explosion)” و  “سرریز اطلاعات” (information overflow)  استفاده می‌نماید. داده‌کاوی عملیاتی‌ است که داده‌ها را بمنظور کشف رابطه‌ها و الگوها مورد تحلیل قرار می‌دهد. فرایندکاوی از تکنیک‌های داده‌کاوی در حیطه‌ی مدیریت فرایند کسب و کار بهره برده و استفاده از روش‌های جدید بمنظور بهبود فرایندهای کسب و کار را امکانپذیر می‌سازد.

سؤال مطالعاتی B:  تفاوت میان event log، مورد (case)، رخداد(event)  و مسیر(trace)  چیست و این عوامل چگونه با یکدیگر مرتبط می‌شوند؟

پاسخ:

• Event log  مجموعه‌ایست از رخدادها.
• مورد (case)، رکوردی از رخدادهاست که با یک نمونه فرایند اجرا شده مرتبط می‌باشد.
• رخداد، رکوردی است که اجرای یک فعالیت را ثبت می‌کند.
• یک “مسیر”، ترتیبی است از رخدادهای ثبت شده که به یک “مورد” تعلق دارد.
• رخدادها به caseها نگاشت می‌شوند. هر case دارای یک “مسیر” می‌باشد. بطور معمولcaseهای مختلف می‌توانند در بر دارنده‌ی یک مسیر مشترک باشند.

سؤال مطالعاتی C: چرا هر کدام از الگوریتم‌های کاوش، مدل‌های فرایندی متفاوتی تولید می‌کنند؟

پاسخ: نتیجه‌ یا خروجی یک الگوریتم فرایندکاوی به طراحی آن بستگی دارد. هرکدام از الگوریتم‌های فرایندکاوی از روش‌های متفاوتی برای کاوش استفاده می‌نمایند. این الگوریتم‌ها می‌توانند جبری (deterministic) یا غیرجبری باشند. هچنین این الگوریتم‌ها می‌توانند از روش “ژنتیک” و یا  “اکتشافی (heuristic) ” استفاده نمایند. با توجه به روش مورد استفاده، نتایج متفاوت خواهند بود. زبان‌های مدل سازی از دیگر عواملی هستند که تنوع زیادی دارند. الگوریتم‌های فرایندکاوی از زبان‌های مدل‌سازی مختلف و متفاوتی استفاده می‌نمایند و در نتیجه مدل‌های فرایندی متفاوتی تولید می‌کنند.

سؤال مطالعاتی D: تفاوت میان بررسی تبعیت و بررسی مطابقت را شرح دهید.

پاسخ: هدف از بررسی مطابقت شناسایی نمونه‌ فرایندهایی است که منطبق با مدل فرایند مورد نظر نیستند. بررسی تبعیت، تحلیلی است که مشخص می‌کند که آیا از “قوانین (قوانین موجود در فرایند)”(rule) تبعیت و پیروی می‌شود یا خیر. رعایت “قوانین تبعیت” معمولاً توسط کنترل‌ها تضمین می‌گردد. می‌توان مدل‌ها و نمونه‌های فرایندی را به‌منظور مشخص کردن میزان اثر بخشی این کنترل‌ها، مورد بررسی قرار داد.

سؤال مطالعاتی E: چرا باید از برقراری توازن میان معیارهای کیفیت (در فرایندکاوی) اطمینان حاصل کرد؟

پاسخ:  عموماً در دنیای واقعی، دستیابی به معیارهای کیفیتی که متناظر با معیارهای مورد نظر باشند، امری غیرممکن است. هر پروژه‌ی فرایندکاوی شرایط محیطی متفاوتی دارد و اهداف متفاوتی را دنبال می‌کند. این اهداف و شرایط محیطی باید در ابتدای هر پروژه شناسایی شوند. میزان تناسب هرکدام از معیارهای کیفیت، باید با توجه به این شرایط و اهداف ارزیابی گردد. در نهایت رویکردی (رویکرد کاوش) باید انتخاب گردد که منجر به توازن مطلوب این معیارها گردد.

ترجمه و گردآوری: تیم مدیریت محتوای رایورز