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

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

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

چالش دوم: تعامل با نگاره های رویداد پیچیده که ویژگی های متفاوت دارند.
 نگاره های رویداد می توانند ویژگی های بسیار متفاوتی داشته باشند. برخی از نگاره های رویداد ممکن است به شدت بزرگ باشند، طوری که نگهداری و بررسی آن ها را مشکل سازد، در حالی که نگاره های رویداد دیگری ممکن است آن قدر کوچک باشد که داده های کافی برای نتیجه گیری قابل اطمینان موجود نباشد.
در برخی از حوزه ها، مقادیر بسیار عظیمی از رویدادها ثبت شده است. بنابراین، چالش مضاعفی برای بهبود کارایی و مقیاس  پذیری نیاز است. به عنوان مثال، شرکت ASML تمامی اسکنرهای ویفرش را به صورت پیوسته رصد می کند. سازمان ها یا شرکت هایی نظیر سامسونگ  از این اسکنرها برای تولید تراشه ها استفاده می کنند. تقریبا 70 درصد تراشه ها توسط اسکنرهای ویفر ASML  تولید می شوند. ابزارهای موجود در مواجه با حجم پتابایتی داده ها در حوزه های این چنینی مشکل دارند. علاوه بر تعداد رویدادهای ذخیره شده، ویژگی های دیگری نیز هستند که باید محاسبه شوند، نظیر متوسط تعداد رویدادها در هر نمونه، شباهت بین نمونه ها، تعداد رویدادهای منحصر به فرد و تعداد مسیرهای منحصر به فرد. نگاره رویداد L1 با ویژگی های ذیل را در نظر بگیرید: 1000 نمونه فرآیند، به طور متوسط 10 رویداد به ازای هر نمونه و مقدار کمی هم تفاوت در نمونه ها (به عنوان مثال، تعداد زیادی از نمونه ها مسیرهای یکسان و یا بسیار مشابه را طی می کنند).
نگاره رویداد L2 شامل 100 نمونه، و هر نمونه به طور متوسط حاوی 100 رویداد و تمامی نمونه ها هم یک مسیر واحد دارند. واضح است که علی رغم آن که سایز هر دو نگاره برابر است (به طور تقریبی ۱۰۰۰۰ رویداد)، اما آنالیز نگاره L2 به مراتب سخت از L1  می باشد.
همان طور که نگاره های رویداد فقط شامل رویدادهای ساده هستند، اما ممکن است که کامل نباشند. تکنیک های فرآیند کاوی باید با بهره گیری از "فرض جهان باز" (این حقیقت که اتفاق نیفتادن یک چیز به معنای عدم امکان رخداد آن چیز نیست) با ناکامل بودن داده ها تعامل کنند. ناکامل بودن داده ها باعث می شود که تعامل با نگاره های رویداد کوچک که تفاوت زیادی دارند پر چالش باشد.
 برخی از نگاره ها حاوی رویدادهای با سطح انتزاع بسیار پایین هستند. این نگاره ها غالبا بسیار بزرگ هستند و معمولا ذینفعان علاقه کم تری به رویدادهای سطح پایین دارند. بنابراین ممکن است که نیاز باشد تا رویدادهای سطح پایین را با هم تجمیع کرده و تبدیل به رویدادهای سطح بالا نماییم. به عنوان مثال، زمانی که فرآیند تشخیص و درمان گروه مشخصی از بیماران را تجزیه و تحلیل می کنیم، ممکن است که علاقه ای به تست های انفرادی افراد که در سیستم اطلاعاتی آزمایشگاه بیمارستان ذخیره شده است، نداشته باشیم.
 در این نقطه از زمان، سازمان ها از روش های سعی و خطا برای تعیین این که نگاره های رویداد آن ها مناسب فرآیند کاوی هست یا خیر، استفاده می کنند. به همین دلیل، ابزارها باید اجازه آزمایش های امکان سنجی سریع برای یک مجموعه داده مشخص را فراهم کنند. این چنین آزمایش هایی باید مشکلات عملکردی بالقوه را شناسایی کرده و در مورد نگاره هایی که خیلی ناقص هستند یا خیلی اطلاعات جزیی دارند، هشدار دهند.

چالش سوم: ایجاد representive benchmark
 با توجه به این که فرآیند کاوی یک تکنولوژی نوظهور است، به همین دلیل هنوز نیاز به محک های خوب می باشد. به عنوان مثال، ده ها روش و نرم افزار کشف فرآیند وجود دارد و فروشندگان مختلف محصولات متفاوتی را توصیه می کنند، اما هیچ اجماعی در مورد کیفیت این تکنیک ها وجود ندارد. علی رغم این که تفاوت های بسیاری در عملکرد و کارایی این ابزارها و تکنیک ها وجود دارد، اما مقایسه آن ها کار دشواری است. بنابراین، محک های خوب شامل مجموعه دادهای نمونه و معیارهای نشان دهنده کیفیت مورد نیاز است.
برای تکنیک های داده کاوی کلاسیک، تعداد زیادی محک وجود دارد. این محک ها، باعث شده اند تا تولیدکنندگان ابزار و محققان انگیزه بیش تری برای افزایش کیفیت کارایی تکنیک هایشان داشته باشند. در مورد فرآیند کاوی این موضوع پرچالش تر می باشد. به عنوان مثال، مدل رابطه ای که توسط Codd در 1969 ارایه شد، ساده است و به صورت گسترده پشتیبانی می شود. در نتیجه، برای تبدیل از یک پایگاه داده به پایگاه داده دیگری انرژی کمی نیاز است و مشکلات تفسیرهای گوناگون وجود ندارد. اما در مورد فرآیندها، این چنین مدل ساده ای وجود ندارد. استانداردهایی که برای مدل کردن فرآیند ارایه شده است، بسیار پیچیده تر بوده و تعداد کمی از تولید کنندگان هستند که از مفاهیم یکسانی استفاده می کنند. فرآیندها، به مراتب پیچیده تر از داده های جدولی هستند. با این اوصاف، ایجاد محک های نماینده برای فرآیند کاوی ضروری است. چندین کار ابتدایی در این زمینه انجام شده است. (جهت اطلاعات بیش تر می توان به سایت  www.processmining.org رجوع کرد.)
از طرف دیگر نیاز به تولید داده های مصنوعی است که ویژگی های خاصی داشته باشند. این داده های مصنوعی در تولید تکنیک های فرآیندکاویی که در خور نگاره های رویداد ناکامل، نگاره های رویداد نویزی، یا جمعیت مشخصی از فرآیندها هستند، کمک می کنند. در کنار ایجادrepresentative benchmarks ، همچنین نیاز به توافق بیش تری بر سر معیارهایی که برای ارزیابی کیفیت نتایج فرآیند کاوی (چالش 6 ) به کار می روند، می باشد. علاوه بر این، می توان از تکنیک های ارزیابی متقابل در داده کاوی نیز برای ارزیابی نتایج اقتباس کرد. به عنوان مثال، روش چک کردن fold-k را در نظر بگیرید. یک راهکار این است که نگاره های رویداد را به k قسمت شکست. سپس k-1  قسمت را برای یادگیری یک مدل فرآیند استفاده کرد و از تکنیک های چک کردن انطباق برای ارزیابی نتایج با توجه به قسمت های باقی مانده استفاده نمود. این فرآیند را می توان k بار تکرار کرد، و بنابراین می توان به بینش هایی در مورد کیفیت مدل دست یافت.

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

چالش پنجم: ارتقای Bias Representational که برای کشف فرآیند استفاده می شوند
 روش های کشف فرآیند با استفاده از یک زبان مشخص (مثلا BPMN یا شبکه پتری) یک مدل تولید می کنند. به هر حال، ذکر این نکته مهم است که باید بین شیوه نمایش نتایج با شیوه نمایشی که در حین کشف فرآیند استفاده می شود، تمایز قائل شد. انتخاب زبان هدف غالبا شامل چندین فرض ضمنی است. فرآیندهایی که نمی توانند با استفاده از زبان هدف نشان داده شوند، نمی توانند کشف هم شوند و این امر فضای جستجو را محدودتر می کند. این موضوع که bias representational یا تعصب بازنمودی نامیده می شود و در فرآیند کشف استفاده می شود، باید یک انتخاب آگاهانه باشد و نباید فقط مبتنی بر شیوه نمایشی گرافیکی که مورد ترجیح است، انتخاب شود.

چالش ششم: ایجاد توازن بین معیارهای کیفی نظیر تناسب، سادگی، دقت و تعمیم
غالبا نگاره های رویداد فاصله زیادی تا کامل بودن دارند، و غالبا تنها رفتارهای نمونه در دسترس می باشند. در مدل های فرآیند معمول امکان وجود تعداد نمایی یا حتی نامحدود (در حالتی که حلقه وجود داشته باشد) دنباله وجود دارد. علاوه بر این، برخی از دنباله ها ممکن است احتمال بسیار کم تری نسب به سایر دنباله ها داشته باشند. بنابراین، این تصور که همه دنباله های ممکن در نگاره رویداد موجود هستند، فرض غیرواقعی است. برای نشان دادن این موضوع که دسترسی به نگاره های کامل غیر عملی است، فرآیندی را در نظر بگیرید که شامل 10 فعالیت بوده و می توانند به صورت موازی اجرا شوند و همچنین یک فایل نگاره رویداد مرتبط که حاوی ۱۰۰۰۰ حالت است. تعداد کل حالت های ممکن جایگذاری در یک مدل با 10 فعالیت موازی برابر با 10! (10 فاکتوریل) می باشد. بنابراین، عملی نیست که تمامی این 10! حالت در فایل نگاره رویداد حضور داشته باشد. حتی اگر میلیون ها حالت هم در نگاره موجود باشد، بسیار بعید است که تمامی گونه های ممکن در آن موجود باشد. پیچیدگی مضاعف دیگری که وجود دارد این است که برخی از حالت ها بسیار کم رخدادتر از سایر حالت ها هستند. این حالت ها ممکن است به عنوان "نویز" در نظر گرفته شوند. ساخت یک مدل مناسب برای چنین رفتارهای نویزی امکان پذیر نیست. مدل کشف شده باید انتزاعی از این رفتارها باشد و بهتر است که رفتارهای با فرکانس کم با بهره گیری از تکنیک های چک کردن انطباق بررسی شوند.
وجود نویز و ناکامل بودن داده ها، مساله کشف فرآیند را پر چالش کرده است. در حقیقت، چهار بعد کیفی رقابت وجود دارد: الف) تناسب، ب) سادگی، ج) دقت و د) تعمیم. یک مدل با تناسب خوب اجازه بازپخش بیش تر رفتارهای دیده شده در نگاره رویداد را می دهد. یک مدل استخراج شده دارای تناسب کامل است، هرگاه تمامی دنباله های موجود در نگاره رویداد قابل باز تولید توسط مدل از ابتدا تا به انتها باشند. ساده ترین مدلی که بتواند رفتار دیده شده در نگاره رویداد را نشان دهد، بهترین مدل است. این اصل به عنوان قانون Razor’s Occam شناخته شده است. تناسب و سادگی به تنهایی برای ارزیابی کیفیت مدل فرآیند کشف شده کافی نیست. به عنوان مثال، به راحتی می شود یک مدل شبکه پتری بسیار ساده (مدل گل) تولید کرد (که همه دنباله های موجود در نگاره رویداد را باز تولید کند) و البته هر نگاره رویداد دیگری که دارای مجموعه فعالیت های مشابه است. به طریق مشابه، مطلوب نیست که مدلی داشته باشیم که فقط اجازه تولید دقیق رفتارهای نشان داده شده در نگاره رویداد را بدهد. به یاد بیاورید که نگاره رویداد تنها حاوی رفتارهای مثال است و از تعداد بسیار زیاد نگاره های قابل رخداد، ممکن است که هنوز بسیاری دیده نشده باشند. یک مدل دقیق است هرگاه اجازه تولید رفتارهای خیلی زیاد ندهد. به وضوح، "مدل گل" فاقد دقت است. یک مدل که دقیق نباشد، کمتر از حد مناسب است. Underfitting مشکلی است که در آن، مدل، رفتارهای نمونه دیده شده در نگاره رویداد را بیش از حد تعمیم می دهد (به عنوان مثال، مدل اجازه رفتارهای بسیار متفاوت از رفتارهایی که در نگاره رویداد دیده شده است را می دهد). یک مدل باید تعمیم دهد و نباید رفتارها را فقط محدود کند به آنچه در نگاره است. مدلی که تعمیم نمی دهد،  overfitting است. بیش از حد مناسب بودن یاoverfitting ، مشکلی است که در آن یک مدل خیلی خاص تولید شود، در حالی که واضح است که نگاره های رویداد تنها حاوی رفتارهای نمونه هستند. به عنوان مثال، مدل یک نگاره نمونه را توضیح می دهد، اما یک نگاره نمونه دیگر از همان فرآیند ممکن است که یک مدل فرآیندی کاملا متفاوت دیگر تولید نماید.
ایجاد توازن بین تناسب، سادگی، دقت و تعمیم پرچالش است. به همین دلیل، بیش تر روش های قدرتمند کشف فرآیند پارامترهای گوناگونی را ارائه می کنند. الگوریتم های بهبود یافته بیش تری برای ایجاد توازن بین 4 بعد کیفی رقابتی مورد نیاز است. علاوه بر این، هر پارامتری که استفاده می شود باید قابل فهم توسط کاربر نهایی باشد.

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

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

چالش نهم: ترکیب فرآیندکاوی با سایر انواع آنالیز
 مدیریت عملیات و به صورت ویژه تحقیق در عملیات یک شاخه از علم مدیریت است که به شدت متکی بر مدل سازی است. در این حوزه، انواع مدل های ریاضی اعم از برنامه ریزی خطی و برنامه ریزی پروژه تا مدل های صف بندی، زنجیره های مارکو و شبیه سازی استفاده می شود. یک تعریف از داده کاوی "تجزیه و تحلیل مجموعه های داده (غالبا بزرگ) برای پیدا کردن روابط ناپیدا و برای خلاصه کردن داده ها در یک شیوه جدید که قابل فهم و مفید برای مالک داده باشد" است. طیف گسترده ای از تکنیک ها (نظیر خوشه بندی k-4، خوشه بندی)، رگرسیون (نظیر یادگیری درخت تصمیم)، طبقه بندی (means5 و کشف الگو) نظیر یادگیری قوانین انجمنی توسعه داده شده است.
 هر دو زمینه (مدیریت عملیات و داده کاوی) تکنیک های تجزیه و تحلیل ارزشمندی را فراهم آورده اند. چالشی که وجود دارد این است که چطور این تکنیک ها را در حوزه فرآیندکاوی استفاده کنیم. به عنوان مثال شبیه سازی را در نظر بگیرید. تکنیک های فرآیند کاوی می تواند برای یادگیری یک مدل شبیه سازی براساس داده های تاریخچه ای استفاده شود. متعاقبا، مدل های شبیه سازی برای ارائه پشتیبانی عملیاتی می تواند به کار رود. از آن جایی که ارتباط تنگاتنگی بین نگاره رویداد و مدل وجود دارد، مدل برای بازتولید تاریخچه می تواند استفاده شود.
 به طور مشابه، ترکیب فرایند کاوی با تجزیه تحلیل های تصویری نیز مطلوب است. آنالیز بصری، به منظور درک بهتر مجموعه داده های پیچیده و بزرگ، تجزیه و تحلیل خودکار را با تصویرسازی تعاملی ترکیب می کند. آنالیزهای تصویری، از قابلیت های شگفت انگیز انسان برای دیدن الگوها در داده های غیر ساخت یافته استفاده می کنند. با ترکیب تکنیک های خودکار فرآیندکاوی با آنالیزهای تصویری تعاملی، می توان بینش بیش تری از داده های رویداد استخراج نمود.

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

چالش یازدهم: بهبود قابلیت فهم برای افراد غیرمتخصص در فرآیندکاوی
حتی اگر بتوانیم به نتایجی دست یابیم، لزوما به این معنا نیست که این نتایج مفید و قابل استفاده هستند. کاربران ممکن است که در درک نتایج خروجی مشکل داشته باشند و یا این که نتیجه گیری های نادرستی انجام دهند. برای جلوگیری از چنین مشکلاتی، باید نتایج با استفاده از یک شیوه ارائه مناسب (چالش 5)، نمایش داده شوند. علاوه بر این، قابل اعتماد بودن نتایج نیز باید به صورت شفاف مشخص شود. ممکن است که داده های اندکی برای تصدیق کردن نتایج وجود داشته باشد. در حقیقت، تکنیک های کنونی کشف فرآیند برای تناسب پایین و یا تناسب بیش از حد هشداری نمی دهند. آن ها همیشه یک مدل را به عنوان خروجی نشان می دهند، حتی اگر واضح باشد که داده ها آن قدر کم هستند که نشود هیچ نتیجه ای را تصدیق کرد.

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