فرایندکاوی

فرایندکاوی یا کاوش فرایند (به انگلیسی: Process mining) موضوع نسبتاً جوانی است که بین هوش محاسباتی و داده‌کاوی از یک سو و مدل‌سازی و تحلیل فرایندهای سازمان از دیگر سو قرار می‌گیرد. هدف فرآیندکاوی کشف، نظارت و بهبود فرایندهای واقعی از طریق استخراج دانش از داده‌های ذخیره شده در سیستم‌های اطلاعاتی می‌باشد. فرآیندکاوی یا Process Mining بیشتر به آنالیز فرایندها با استفاده از لاگ های رخداد (EventLogs) می‌پردازد. تکنیک‌های کلاسیک داده‌کاوی نظیر خوشه بندی، طبقه‌بندی، انجمن یابی و ... بر روی مدل‌های فرایند تمرکز ندارند و فقط برای تحلیل گام مشخصی در فرایند کلی استفاده می‌شوند. فرآیندکاوی دیدگاه فرآیندی را به داده کاوی می افزاید. تکنیک‌های فرایندکاوی از داده‌های رخدادهای ثبت شده برای کشف و تحلیل و بهبود فرآیند استفاده می‌کنند. هر رخداد ثبت شده به یک فعالیت اشاره دارد و مرتبط با یک نمونه فرآیند می‌باشد. مرجع اصلی فرایندکاوی سایت processmining.org و وبسایت شخصی پروفسور آلست پدر علم فرآیندکاوی است. در این سایت آخرین اطلاعات در ارتباط با این حوزه نوظهور آورده شده‌است. در ایران آقای دکتر نبی اله یوسفی گرجی کتاب های تالیف و ترجمه با نگارش ساده و قابل فهمی در باب فرایندکاوی دارند. از جمله:فرایندکاوی و مهندسی مجدد سازمان ها(تالیف)و تکنیک‌های فرایندکاوی ... آندرئا بوراتین دانشگاه آزاد اسلامی واحد(ترجمه)

انواع روش‌های فرایندکاوی

تکنیک‌های فرایندکاوی، براساس داده‌های رخداد، به سه دسته کلی تقسیم‌بندی می‌شوند:

• الف) تکنیک‌های کشف فرایند (process discovery)
• ب) تکنیک‌های بررسی انطباق(conformance checking)
• ج) تکنیک‌های بهبود فرآیند (process enhancement)

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

یک مثال ساده از کاوش فرایند در سیستم آموزش

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

مقایسه فرایندکاوی با داده‌کاوی

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

1. حجم عظیمی از داده‌ها

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

1. دیدگاه فرایندی

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

1. استثناءها نیز مهم هستند

در داده‌کاوی عمومی‌سازی به منظور جلوگیری از سرریز شدن داده‌ها امری بسیار مهم است. این یعنی می‌خواهیم تمام داده‌هایی را که با قانون کلی سازگاری ندارند دور بیندازیم. در فرایندکاوی نیز عمومی‌سازی در کار کردن با فرایندهای پیچیده و درک جریان فرایندهای اصلی لازم است. همچنین در بیشتر موارد درک استثناءها به منظور کشف نقاط ناکارآمدی و نیازمند بهبود ضروری به نظر می‌رسد.

1. تمرکز بر روی اکتشاف

در داده‌کاوی معمولاً مدل‌ها برای پیش‌بینی نمونه‌های مشابه در آینده استفاده می‌شوند. در واقع روش‌های داده‌کاوی و یادگیری ماشین کمی وجود دارند که مانند یک جعبه سیاه پیش‌بینی‌هایی تولید می‌کنند بدون اینکه امکان برگشت به عقب یا بیان علت آن‌ها را داشته باشند. از آنجا که فرایندهای تجاری کنونی خیلی پیچیده هستند پیش‌بینی‌های دقیق معمولاً غیر واقعی هستند. دانش بدست آمده و بینش عمیق‌تر نسبت به الگوهای و فرایندهای کشف شده به رفع پیچیدگی کمک خواهد کرد؛ بنابراین اگرچه داده‌کاوی و فرایندکاوی مشترکات زیادی دارند اما تفاوت‌های پایه‌ای بین آن‌ها در کاری که انجام می‌دهند و جایی که مورد استفاده قرار می‌گیرند وجود دارد.

چالش‌های فرایندکاوی

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

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

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

1. ممکن است داده‌ها بر روی چندین منبع توزیع شده باشد. این اطلاعات باید ادغام گردند. این مشکل زمانی حادتر می‌شود که از چندین شناسه برای منابع مختلف استفاده شود. مثلاً یک سیستم از نام و تاریخ تولد برای شناسایی افراد استفاده کند و سیستم دیگر از شماره امنیتی اجتماعی فرد.
2. داده‌های سازمانی غالباً object محور می‌باشند و نه فرایند محور. به عنوان مثال محصولات و ظرف‌ها می‌تواند تگ‌های RFID ایی داشته باشند که خودکار منجر به ثبت رکورد گردند. برای رصد کردن سفارش یک مشتری، این اطلاعات شی محور باید ادغام و پیش پردازش شوند.
3. داده‌های رویداد ممکن است ناکامل باشند. یکی از رایج‌ترین مشکلات این است که رویدادها به صورت صریح به نمونه‌های فرایند اشاره نمی‌کنند.
4. داده‌های رویداد ممکن است حاوی اطلاعات پرت باشد. منظور از داده‌های پرت نمونه‌هایی است که از الگوی عمومی پیروی نکرده و به ندرت اتفاق می‌افتند.
5. لاگ ممکن است حاوی اطلاعاتی با سطوح مختلف دانه‌دانه شدن باشد. داده‌های لاگ بیمارستانی ممکن است به یک تست خون ساده اشاره کند یا اینکه به یک رویه پیچیده جراحی اشاره نماید. همچنین برچسب زمانی هم می‌تواند از دقت میلی ثانیه (28-9-2011:h11m28s32ms342) تا اطلاعات درشتتر نظیر روز (۲۸-۹-۲۰۱۱) را شامل شود.

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

• چالش دوم: استفاده از داده‌های رویداد پیچیده‌ای که ویژگی‌های گوناگونی دارند

داده‌های لاگ ممکن است که ویژگی‌های خیلی متنوعی داشته باشند. بعضی از داده‌های لاگ ممکن است که آنچنان بزرگ باشند که رسیدگی به آن‌ها دشوار باشد و بعضی از آن‌ها ممکن است آنقدر کوچک باشند که نتوان نتایج قابل اطمینانی از آن‌ها استحصال کرد. ابزارهای موجود در مواجه با داده‌های با ابعاد پتابایت دشواری‌هایی دارند. در کنار تعداد رکوردهای رویدادهای ذخیره شده ویژگی‌های دیگری نظیر متوسط تعداد رویدادها در هر حالت، شباهت میان حالت‌ها، تعداد رویدادهای منحصر به فرد و تعداد مسیرهای واحد نیز هستند که باید مورد توجه قرار گیرند. به عنوان مثال فایل لاگ داده L1 با مشخصات ذیل را در نظر بگیرید: ۱۰۰۰ حالت، به‌طور متوسط ۱۰ رویداد به ازای هر حالت. فرض کنید فایل لاگ L2 حاوی تنها ۱۰۰ حالت باشد اما هر حالت حاوی ۱۰۰ رویداد باشد و همه رویدادها از یک مسیر واحد تبعیت کنند. پر واضح است که آنالیز L2 بمراتب دشوارتر از آنالیز L1 می‌باشد، علی‌رغم اینکه هر دو فایل سایز برابر و یکسانی دارند. از آنجایی که داده‌های لاگ تنها حاوی نمونه‌های مثال می‌باشند، بنابراین نباید اینطور فرض شود که آن‌ها کامل هستند. تکنیک‌های کاوش متن باید با استفاده از «فرض جهان باز» با این عدم کامل بودن کنار بیایند: این واقعیت که اگر پدیده‌ای اتفاق نمی‌افتد به معنای عدم امکان رخداد آن نیست. این موضوع تعامل با داده‌های لاگ با سایز کم و حاوی تغییرات زیاد را دشوار می‌کند. همان‌طور که پیش‌تر هم اشاره شد، بعضی از فایل‌های لاگ ممکن است حاوی رکوردهایی با سطح انتزاع بسیار پایین باشند. داده‌های با سطح پایین چندان مطلوب ذی نفعان نمی‌باشند؛ بنابراین عموماً سعی می‌شود تا داده‌های سطح پایین با همدیگر تجمیع شوند تا داده‌های با سطح بالاتر تولید گردد. به عنوان مثال، زمانی که فرایند تشخیص و درمان گروهی از بیماران آنالیز می‌شود، احتمالاً دیگر علاقه‌مند به دانستن نتایج آزمایش‌ها انفرادی افراد نیستیم. در این گونه از موارد، سازمان‌ها لازم است که از روش سعی و خطا استفاده نمایند تا دریابند که آیا داده‌ها مناسب برای کاوش فرایند می‌باشند؛ بنابراین ابزارها باید سرویس آزمایش امکان‌سنجی سریع برای یک پایگاه داده مشخص را فراهم نمایند.

• چالش سوم: ایجاد شاخصه‌های ارزیابی

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

• چالش چهارم: مواجه با رانش مفهومی (Concept Drift)

عبارت رانش مفهومی در حوزه کاوش فرایند به موقعیتی اشاره می‌کند که در آن فرایند در عین حال که در حال آنالیز شدن می‌باشد، تغییر نیز می‌کند. به عنوان مثال در ابتدای یک فایل لاگ، ممکن است که دو فعالیت همزمان باشند در حالیکه در ادامه در لاگ این دو فعالیت ترتیبی شوند. فرایندها به دلایل مختلفی ممکن است تغییر کنند. بعضی از این تغییرات بنابه دلایل تغییرهای دوره‌ای می‌باشد (مثلاً در ماه مهر و اسفند خریدها بیشتر است یا اینکه بعد از ظهر جمعه کارمندان کمتری در دسترس هستند). بعضی از تغییرات هم به واسط تغییر شرایط رخ می‌دهند (مثلاً بازار رقابتی تر می‌شود). این تغییرات بر روی فرایند تأثیر می‌گذارند و ضرورت دارد که به آن‌ها توجه شود. پدیده رانش مفهومی با استفاده از شکستن فایل لاگ به قطعات کوچکتر و آنالیز رد پای(footprint) این قطعات قابل شناسایی می‌باشد. این آنالیز مرتبه دوم (second order) نیازمند داده‌های رویداد بیشتر می‌باشد. با این حال تعداد کمی از فرایندها در حالت ثابت می‌باشند و فهم رانش مفهومی دارای اولویت بالایی در مدیریت فرایندها می‌باشد؛ بنابراین ابزارها و تحقیقات بیشتری برای آنالیز مناسب رانش مفهومی مورد نیاز می‌باشد.

• چالش پنجم: ارتقای پیش فرض‌های نمایشی که در کشف فرایند استفاده می‌شوند(Representational Bias)

یک تکنیک کشف فرایند، با استفاده از یک زبان مشخص (BPMN، Petri Net و ...) یک مدل فرایند تولید می‌نماید. به هر حال مهم است که تجسم نتایج، مجزای از نمایی باشد که در کشف فرایند مورد استفاده قرار می‌گیرد. انتخاب یک زبان هدف غالباً تعدادی فرض ضمنی را هم دربر می‌گیرد. این فرضیات فضای جستجو را محدود کرده و فرایندهایی که نمی‌توانند با استفاده از زبان مقصد نمایش داده شوند، کشف نخواهند شد. این به اصطلاح پیش فرض‌های نمایشی که در کشف فرایند استفاده می‌شوند باید با انتخاب آگاهانه همراه گردند و نباید (فقط) بر مبنای اولویت‌های نمایشی گرافیکی انتخاب شوند. مثلاً شکل ذیل را در نظر بگیرید. بسته به آنکه زبان مقصد اجازه همزمانی را بدهد یا ندهد، می‌تواند بر روی نمایش مدل کشف شده و کلاس مدلهایی که توسط الگوریتم استفاده می‌شود تأثیر داشته باشد. اگر پیش‌فرض‌های نمایشی اجازه همزمانی را ندهند (بخش a تصویر) و اجازه استفاده همزمان چند فعالیت از یک برچسب را ندهند (بخش c از تصویر)، آنگاه شکل b تصویر که دارای مشکلات هم باشد تنها امکان‌پذیر خواهد بود.

• چالش ششم: برقراری تعادل بین معیارهای کیفیت نظیر سازگاری، سادگی، دقت و عمومیت

غالباً داده‌های ثبت شده کامل نیستند. مدل‌های فرایندی معمولاً محدودیتی برای تعداد نامحدود نمونه فرایند (درحالت وجود حلقه‌ها) ندارند. از طرفی، بعضی از نمونه‌ها هم نسبت به سایرین رخداد بمراتب کمتری دارند؛ بنابراین اینکه فکر کنیم هر نمونه فرایند قابل رخدادی در فایل وقایع ثبت شده موجود می‌باشد، تصور نادرستی می‌باشد. برای اینکه نشان داده شود که تصور داشتن داده‌های کامل، در عمل امکان‌پذیر نمی‌باشد، فرایندی را در نظر بگیرید که شامل ۱۰ فعالیت بوده و این فعالیت‌ها بتوانند به صورت موازی اجرا شوند. همچنین فرض کنید که فایل رویدادهای ثبت شده حاوی ۱۰٬۰۰۰ نمونه فرایند باشد. تعداد حالت‌های کلی (جایگشتها) در یک مدل با ۱۰ فعالیت همزمان، ۳٬۶۲۸٬۰۰۰=!۱۰ می‌باشد؛ بنابراین امکان‌پذیر نمی‌باشد که تمامی این نمونه‌ها در فایل رویدادهای ثبت شده (تنها حاوی ۱۰٬۰۰۰) وجود داشته باشد. وجود داده‌های نویز (داده‌های با رخداد کم) بر پیچیدگی‌ها می‌افزاید. ساخت مدل برای رفتارهایی که به ندرت رخ می‌دهند (داده‌های نویز) کار بسیار دشواری می‌باشد. در این گونه موارد، برای پردازش این دسته از رفتارها بهتر است که از چک کردن مطابعت استفاده شود. نویز و ناکامل بودن، کشف فرایند را به یکی از پرچالش‌ترین مسائل تبدیل کرده‌است. تعادل برقرار کردن بین معیارهای سادگی، سازگاری، دقت و عمومیت داشتن کار پرچالشی می‌باشد. به همین دلیل اکثر تکنیک‌های قدرتمند کاوش فرایند پارامترهای متنوعی را فراهم می‌سازند. الگوریتم‌های جدیدی برای تعادل برقرار کردن بین این معیارها نیاز می‌باشد.

• چالش هفتم: کاوش بین سازمانی

به‌طور سنتی، کاوش فرایند در یک سازمان اجرا می‌گردد. اما با گسترش تکنولوژی وب سرویس، یکپارچگی زنجیره تأمین و محاسبات ابری، سناریوهایی پیش می‌آید که در آن داده‌های چند سازمان برای آنالیز در دسترس می‌باشد. در حقیقت دو مشخصه برای کاوش فرایندهای بین سازمانی موجود می‌باشد. در سناریوی همکارانه، سازمان‌های مختلف همگی باهم در جهت رسیدن به اهداف مشخصی همکاری داشته و نمونه فرایندها بین این سازمان‌ها در جریان می‌باشد. در این مدل سازمان‌ها همانند قطعات یک پازل می‌باشند. فرایند کلی به قطعاتی شکسته شده و بین سازمان‌ها توزیع می‌شود تا هر سازمان وظیفه مربوط به خود را انجام دهد. آنالیز رویدادهای ثبت شده در تنها یکی از این سازمان‌ها کافی نمی‌باشد. به منظور کشف فرایندهای انتها به انتها، رویدادهای ثبت شده سازمان‌های مختلف باید بایکدیگر ادغام گردد که کار ساده‌ای نمی‌باشد. سناریوی دوم این است که سازمان‌های مختلف در عین حال که از زیرساخت‌های مشترکی استفاده می‌نمایند، فرایند یکسانی را اجرا نمایند. به عنوان مثال Saleforce.com را می‌توانید در نظر بگیرید. این شرکت فرایند فروش شرکت‌های دیگر را بر عهده دارد و مدیریت می‌کند. از یک طرف شرکت‌ها از زیر ساخت این سایت استفاده می‌کنند و از طرف دیگر مجبور نیستند که دقیقاً یک فرایند قطعی را دنبال کنند (چراکه سیستم امکان تنظیمات اختصاصی در دنبال کردن فرایند به آن‌ها می‌دهد. واضح است که آنالیز این تغییرات بین سازمان‌های مختلف کار جذاب و جالبی می‌باشد. این سازمان‌ها می‌توانند از همدیگر یاد بگیرند و فراهم کنندگان سرویس ممکن است که سرویس هایشان را ارتقا بخشند و سرویس‌های ارزش افزوده‌ای را برمبنای نتیجه کاوش‌های بین سازمانی ارائه نمایند.

• چالش هشتم: ارائه پشتیبانی عملیاتی

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

• چالش نهم: ترکیب کاوش فرایند با سایر روش‌های آنالیز

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

ابزارهای فرایندکاوی

• ابزار تجاری لانا LANA Process Mining
• ابزار متن باز ProM
• ابزار تجاری Disco
• ابزار تجاری Celonis بایگانی‌شده در ۱۰ اوت ۲۰۱۶ توسط Wayback Machine
• افزونه BIpm در Microsoft Power BI

پیوند به بیرون

• سایت مرجع فرایند کاوی http://processmining.ir
• سایت فرایندکاوی processmining.org
• مانیفست (بیانیه) فرایند کاوی [۱]
• صفحهٔ شخصی پروفسور آلست
• آزمایشگاه فناوری وب دانشگاه فردوسی مشهد
• لانالابس Lana Labs
• گروه تحقیقاتی Fluxicon
• گروه فرآیندکاو : Pkav

جستارهای وابسته

• علم داده‌ها

منابع

مانیفست فرایندکاوی