مشکل کیفیت داده در فرایند کاوی (بخش ۶: متفاوت بودن درشت دانگی برچسب زمان)

مشکل کیفیت داده در فرایند کاوی (بخش ۶: متفاوت بودن درشت دانگی برچسب زمان)

مشکل کیفیت داده در فرایند کاوی (بخش 6: متفاوت بودن درشت دانگی برچسب زمان)

Different Timestamp Granularities

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

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

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

این مشکل تنها بعد از وارد کردن داده ها آشکار می شود. ما جریان های عجیب و غریب در نقشه فرایند را می بینیم. به عنوان مثال، چگونه می توان آن را در اکثر موارد (1587 بار) گام “سفارش تایید” قبل از “سفارش دریافت” رخ دهد؟

این امکان پذیر نیست. بنابراین، ما بر روی مسیر کلیک می کنیم و از فیلتر Short-cut Filter این مسیر استفاده می کنیم … برای نگه داشتن تنها مواردی که واقعا این مسیر خاص را در روند دنبال می کنند.

سپس به برگه Cases برویم تا موارد نمونه را بررسی کنیم (تصویر زیر را ببینید). در آنجا، ما بلافاصله می توانیم ببینیم چه اتفاقی افتاد: هر دو فعالیت “سفارش دریافت شده” و “تایید سفارش” در همان روز اتفاق افتاده است. با این حال، ‘دریافت سفارش’ دارای برچسب زمانی است که شامل زمان  است در حالی که “سفارش تأیید” تنها شامل تاریخ است. برای فعالیتهایی که فقط تاریخ را شامل می شوند (مانند ‘Order confirmed’) زمان به طور خودکار به عنوان «نیمه شب» نشان داده می شود. البته این به این معنا نیست که فعالیت در نیمه شب اتفاق افتاده است. بلکه بیانگر این موضوع است که ما نمی دانیم  در چه زمانی  در طول روز انجام شد.

بنابراین، واضح است که «سفارش تأیید شده» باید در همان روز پس از «سفارش دریافت شده» (یعنی پس از 13:10 در مورد نمونه برجسته) انجام شده باشد. با این حال، ما زمان سفارش “تأیید” (مشکل کیفیت داده در پایان ما) را نمی دانیم،  روند هر دو فعالیت در سفارش اشتباه نشان داده می شوند.برای اطمینان از اینکه «فعالیت تأیید شده» گاهی اوقات چندین روز قبل ثبت نشده است (که نشان دهنده مشکالت دیگر است)، ما تمام فعالیت های دیگر را در فرایند فیلتر می کنیم و به حداکثر بین “تایید سفارش” و “سفارش دریافت شده” نگاه می کنیم نقشه فرآیند (نگاه کنید به تصویر زیر). حداکثر مدت 3/23 ساعت، ارزیابی ما را تایید می کند که این دستور العمل اشتباه به نظر می رسد با توجه به زمان بندی های مختلف زمانی که «سفارش دریافت شده» و «سفارش تأیید شده» به نظر می رسد.

بنابراین، چه کاری می توانیم در مورد آن انجام دهیم؟ در این مثال خاص، زمان اضافی که ما برای فعالیت های سفارش دریافت می کنیم به میزان زیادی کمک نمی کند و سبب سردرگمی بیشتر می شود. برای تراز کردن جزئیات گرامر زمان، ما تصمیم می گیریم اطلاعات زمان را حتی زمانی که ما آن را داشته ایم حذف کنیم.برای مقیاس دادن جزئیات دقیق تمام نشانه های زمانی به فقط تاریخ آسان است: شما به سادگی می توانید به صفحه ورود به اطلاعات بروید، ستون Timestamp را انتخاب کنید، دکمه الگو … را فشار دهید تا محاوره ای از الگو را باز کنید، و سپس ساعت و دقیقه را حذف کنید کامپوننت به سادگی حذف آنها از الگوی زمانبندی (نگاه کنید به تصویر زیر). همانطور که می توانید در سمت راست در پیش نمایش تطبیق ببینید، زمان بندی با زمان 20:07 در حال حاضر تنها به عنوان یک تاریخ (16 دسامبر 2015) انتخاب شده است.

در نتیجه، جریان فرایند ناخواسته ناپدید شده است و اکنون شاهد فعالیت Order Received می باشیم که قبل از فعالیت Order Order تایید شده است (به تصویر زیر مراجعه کنید).

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

نویسنده: خانم Anne Rozinat
مرجع خبر:

Data Quality Problems in Process Mining and What To Do About Them — Part 6: Different Timestamp Granularities

ارسال دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

مقایسه
علاقه مندی ها 0