عبارت گزارش رویداد یا ایونت لاگ چیست؟

وجه مشترک تحلیل‌های داده محور استفاده آن‌ها از داده ها است. فرآیندکاوی به عنوان یک تحلیل داده محور نیز از این قاعده مستثنا نیست. یعنی پیش نیاز و پایه تکنیک های فرآیند کاوی مانند کشف فرآیند بررسی انطباق و بهبود فرآیند وجود داده ها کامل و باکیفیت است. معمولا داده های فرآیندی از سیستم های ERp Bpms  مالی انبار Srm و تمامی سیستم هایی اطلاعاتی که فرآیند های ما را پشتیبانی می کند به دست می آید. گاهی وقت ها نیاز است که داده های سیستم های مختلف با هم جوین شوند تا داده مورد نیاز ما برای انجام تحلیل های فرآیند کاوی حاصل شود بنابراین داده های ما برای برای شروع تحلیل های فرآیندکاوی باید ساختار خاصی داشته باشد. ما به داده هایی که چنین ساختاری را داشته باشد گزارش رویداد یا Event log می‌گوییم.

جدول 1. یک نمونه از گزارش رویداد .( هر سطر متعلق یه یک Event است)

جدول 1 اطلاعات معمول موجود در گزارش رویداد را نشان می دهد. بسته به تکنیک فرآیند کاوی مورد استفاده و سوالات موجود، تنها بخشی از این اطلاعات استفاده می شود. حداقل الزامات برای فرآیند کاوی این است که هر رویدادی می تواند هم به یکCase  و هم به یک فعالیت Activity  مرتبط باشد و رویدادهای درون یک Case مرتب شوند. از این رو، ستون های “case id” و “activity” و “”timestamp در جدول 1 حداقل داده مورد نیازرا برای فرآیند کاوی نشان می دهند. با نمایش اطلاعات در این دو ستون، نمایش فشرده تری را به دست می آوریم که در جدول 2 نشان داده شده است. در این جدول، هر مورد با توالی مشخصی از فعالیت ها نشان داده می شود که به آنها دنباله (Trace) نیز گفته می شود. برای وضوح، نام فعالیت ها به برچسب های تک حرفی تبدیل شده است، به عنوان مثال، a درخواست ثبت فعالیت را نشان می دهد.

جدول2. گزارش رویداد به طور فشرده

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

یکی از مسائل مهم در ایجاد ستون‌های ویژگی‌گزارش‌های رویداد ارتباط هریک از ویژگی‌ها با Event یا Case ها است. در واقع ستون‌های ویژگی موجود در گزارش رویداد می‌توانند به 2 دسته مرتبط با Case و یا مرتبط با Event تقسیم شوند. اگر این ستون‌ها به ازای هریک از سطر ها متفاوت باشند می‌گوییم این ستون ها مرتبط با Event هستند اما اگر این ویژگی‌ها با تغییر Case عوض شوند گفته می‌شود که این ویژگی ها مرتبط با Case هستند. برای نمونه ستون ویژگی منابع را در نظر بگیرید. از آنجا که هر فعالیت توسط یک شخص یا سخت افزار متفاوتی اجرا می‌شود این ویژگی مرتبط به Event ها است . در جدول 1 فعالیت با Eventid 35654423 که ثبت درخواست (Register Request) است توسط فردی با نام Pete انجام می‌شود اما فعالیت تصمیم (Decide ) توسط Sara اجرا می‌شود. ستون ویژگی هزینه نیز از این نوع است.

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

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