Event log-ът е спецификацията, не диаграмата от уъркшопа

Помолете екип да нарисува своя purchase-to-pay процес и след четиридесет минути ще имате диаграма: девет до четиринадесет правоъгълника, един ромб за решение, нито един цикъл назад. После извадете change документите за същия процес за дванадесет месеца и пребройте пътищата от начало до край. Няколкостотин е нормално.

И двете са честни. Диаграмата е процесът, който хората вярват, че изпълняват. Timestamp-ите са това, което организацията реално е направила с поръчката на клиента. Когато се разминават, печелят timestamp-ите — не защото са по-добродетелни, а защото те са преживяното от клиента.

Уъркшопът надеждно произвежда варианта, който всички харесват

Process mining тръгва от групата на Wil van der Aalst в TU Eindhoven около 1999 г.; Gartner брои около 40 комерсиални инструмента през 2025 г. Находката, заради която изобщо си струваше да се строят инструменти, е постоянна и нелицеприятна: при здрав процес първите пет варианта покриват 60–80% от обема, а зад тях стои опашка от стотици пътища, всеки от които се среща по няколко пъти.

Опашката не е шум. В нея живеят изключенията и гасенето на пожари в края на месеца, и в нея умира наивното RPA: автоматизирате пътя от уъркшопа и откривате, че четвърт от обема пропада в опашка без назначен човек.

Другата редовна находка е пренареждане. Кандидатът, с когото всички са дошли, често е малък дял от обема, докато цикъл на преработка, който никой не е споменал — защото се усеща като нормална работа — струва повече. А ако разпределението на вариантите излезе плоско, това само по себе си е отговор: още няма процес, има навици.

Четири полета, а четвъртото обяснява чакането

Минималният event log е три колони — case ID, activity, timestamp — формализирани като IEEE 1849 (XES). Resource е четвъртото, и всяко от тях се чупи по свой начин.

Case ID свързва събитията в един случай, и грешният избор не влошава резултата постепенно, а го обезсмисля наведнъж. Order-to-cash е класическият капан: една поръчка става три доставки и две фактури, а свеждането им насила до един case ID произвежда convergence и divergence артефактите, заради които mining-ът бърка едновременно за преработките и за времето на цикъла. OCEL 2.0 съществува заради тази форма. Въпросът се задава преди извличането, не когато първата графика изглежда странно.

Activity е решение за именуване, маскирано като поле в таблица. Твърде ситно — 400 имена и нечетим модел; твърде едро — цикълът на преработка изчезва в едно каре „Обработка“. Работещото правило: activity е промяна на състояние, за която някой може да носи отговорност.

Timestamp носи две скрити изисквания: часова зона и достатъчна резолюция, за да подредите събитията в рамките на един ден. Само дата, без час, е най-честата причина един log изобщо да не става за mining — продължителностите оцеляват, последователността не, а повечето инструменти мълчаливо ще подредят събитията от същия ден по row ID и ще върнат модел, построен върху реда на вписване в базата.

Resource — кой или какво е извършило стъпката — превръща продължителността в обяснение. Без него виждате, че случаят е чакал девет дни; с него — че е минал през четири предавания, а чакането се натрупва именно там.

Извличането е в одитните таблици, а не в справките

Справките носят текущото състояние. Логът има нужда от преходите, тоест от одитната следа.

В SAP това са change документите — CDHDR и CDPOS — присъединени към header и item таблиците на процеса: EKKO/EKPO/EKBE за доставки, BKPF/BSEG/RSEG за финанси, VBAK/VBAP/LIKP за продажби и експедиция. Ограничението, което си струва да кажете още на първата среща: change документите записват само полета, маркирани за change logging в data dictionary-то. Ако едно поле никога не е било маркирано, историята му не съществува и никакво извличане не я връща със задна дата — твърда граница за това какво може да покрие базовата линия, по-добре открита в първата седмица, отколкото пред управителния съвет.

Съответствията другаде: Business Events и Data Management Framework в Dynamics 365 F&O, system notes през saved searches или SuiteTalk в NetSuite, mail_tracking_value през XML-RPC в Odoo. При българските пакети — Microinvest Delta Pro, Ажур L, Плюс Минус — извличането е схема на база данни и експорт на справка, а не API: факт за обхвата, не пречка, но влиза в оценката.

Тикет системите имат собствен дефект. Changelog-ът на Jira дава реалните преходи между статуси, а не текущия статус, ServiceNow има sys_audit и task_sla, Zendesk има audits — но всички отбелязват момента, в който записът е обновен, а не момента, в който работата е свършена. Служител, който затваря шест тикета в 17:40, произвежда шест събития в 17:40, и логът описва навика за отчитане, а не операциите. Начертайте събитията по часове от работния ден, преди да повярвате на число от тикет система.

Под около 80% пълнота се поправя измерването, не процесът

Проверката, която пуска или спира всеки mining проект, е оценка за готовност на данните: делът случаи с пълни timestamp-и, разрешими идентификатори и без стъпка, живееща само в Excel или в пощенска кутия. Под около 80% резултатът е опасен по конкретен начин — вариант, който се среща в 4% от случаите, е неразличим от 4% пропуск в извличането, а двете искат противоположни реакции.

Същата двусмислица удря и conformance checking. Fitness под около 0,8 се чете като „документираният процес е измислица“, и често наистина е така — но fitness се срива по същия начин, когато в лога липсват събития, а token-based replay сочи същите места и в двата случая. Установете кое от двете имате, преди някой да е започнал да преработва процеса.

Изречението „първият месец е ремонт на измерването, а не автоматизация“ е непопулярно на старта и е точно това, което прави всяко по-късно число за ползи защитимо: финансите обезценяват до нула базова линия, която не могат да проследят до системни timestamp-и — и са прави.

Преработките се крият в средната стойност, а тя влиза в отчета

Отчитайте p50 и p90 поотделно, винаги. Средното време за цикъл смесва бърз и бавен път и не описва нито един от двата; проблемът, който операционният директор има, е p90.

Rework rate — делът случаи, в които една и съща активност се задейства повече от веднъж — е точно това, което агрегатът скрива. По полетата за цена и условия за плащане 20–40% е често публикуван диапазон, а всяко докосване е легитимно: цената наистина се е променила, значи някой наистина я е одобрил повторно. Поръчката се затваря, нищо не се маркира като проблем, а разходът не се появява никъде, защото нито един случай не изглежда необичаен и средното поглъща разликата.

Сложете touch time до elapsed time. Девет дни с 14 минути човешко време е проблем с опашките; девет дни с четири часа човешко време е проблем с организацията на работата. Да автоматизирате второто, когато имате първото, не купува нищо.

Колоната resource е разговор с представителите на служителите

Анализът на ниво изпълнител е наблюдение на представянето на служители, както и да се казва проектът. Annex III на AI Act изброява мониторинга на представянето на работниците и разпределянето на задачи според поведение сред високорисковите — основната част от задълженията от 2 август 2026 г., класификацията по чл. 6(1) от 2 август 2027 г. — а чл. 22 от GDPR ограничава всичко, което се превръща в решение за конкретен човек.

Отговорът не струва нищо аналитично: псевдонимизирайте resource до роля или екип още при извличането, дръжте съответствието до конкретни хора извън аналитичния набор и запишете, че логът не участва в атестацията. Анализът на предаванията работи отлично на ниво роля. И в мига, в който логът се приеме на терен като хронометър, хората започват да трупат отчитанията си на партиди — и сте платили за по-лош измервателен уред.

Докъде важи това

Ако процесът тече основно извън системите — по телефон, в цеха, в пощенска кутия — логът ще бъде честно оскъден, а mining-ът уверено ще опише 20-те процента, минали през ERP-то. Това е задача за task mining или за пряко наблюдение и никакво извличане не я превръща в друго. Има и долен праг за обем: няколкостотин случая годишно не дават разпределение, което си струва да се анализира. Прочетете ги всичките — по-евтино и по-точно е.

Една граница за нас. Palamed има четири проекта, за които може да отговаря: европейски маркетплейс за автомобили с над 300 000 обяви, речникът на Министерството на образованието и науката на beron.mon.bg, email маркетинг автоматизация за козметичен бранд, където около 60% съкращаване на времето за комуникация е числото на клиента, измерено по неговия метод, и NLP модул, който чете, класифицира и отговаря на търговски запитвания по имейл и в Instagram от продуктовите и ценовите данни, които екипът и без това поддържа — около 85% по-малко ръчно писане по повтарящите се запитвания е също число на клиента, а всеки отговор се одобрява от човек, преди да тръгне. Не сме правили process mining върху SAP среда. Горното е публикуваният модел, стандартите под него и проверките, които бихме пуснали първи. Ако някой ви каже, че е минирал петдесет процеса, попитайте кои таблици е извадил, каква е била готовността на данните и кой кандидат от списъка логът е убил.