Аналіз процесів — найочевидніші проблеми та помилки

Аналіз процесів — розберемо найочевидніші проблеми та помилки.

1. Відсутність або брак даних для аналізу.

Можливо, десь така проблема здасться смішною, але в Україні часто-густо підприємства просто не ведуть операційний облік. Або ведуть так, що витягати його приходиться з великими труднощами, і все рівно отримані дані неповні.

Деколи можна отримати потрібні показники, відштовхуючись від наявних, та роблячи більш чи менш виправдані припущення (наприклад, оцінити завантаження працівника через затримку в часі його відповідних дій), але похибка може бути не тільки занадто великою, але й подекуди незрозуміло, наскільки великою (наприклад, той же працівник може затримувати виконання завдання не через завантаженість, а через недбалість).

Подекуди можуть бути відсутні не тільки проміжні показники, які допомагають "зрозуміти" процес, але й базові.

Це, в свою чергу, часто приводить до наступного:

2. Аналіз процесу виключно по його алгоритму.

Це може бути як несвідома помилка, так і вимушена дія. Що ще лишається, коли нема даних для аналізу, і їх неможливо отримати в рамках проекту?

Як це зазвичай виглядає: аналітик проводить інтерв'ю з ключовими працівниками, включно з менеджерами, та на цій основі робить опис процесів.

Далі аналітик, можливо, з представниками компанії, намагається аналізувати процеси фактично по діаграмам, що зображують їх поточний чи бажаний хід.

На практиці навіть такий простий прийом може дати позитивний результат. Але, здебільшо, такий підхід може згодитись для певних рішень керівництва, а для обгрунтованого аналізу цього замало.

Це може привести до наступної похибки чи помилки:

3. Надто велика увага малоймовірним "гілкам"-варіантам ходу процесу.

Коли учасники обговорення процесу бачать його опис, всі розгалуження його ходу виглядають приблизно однаково ймовірними. Тоді як насправді частина варіантів трапляється дуже рідко, а якісь взагалі суто гіпотетичні.

Аналіз реального ходу процесу це міг би показати наявно, але коли є лише діаграма, наприклад, у BPMN, то не завжди зрозуміло, наскільки вірогідний той чи інший сценарій.

Тут варто згадати ще принципову відмінність "традиційного" опису процесу (в тій же BPMN) від опису процесу, як ланцюга реальних подій:

4. Використання опису-інструкції замість опису зафіксованих подій.

Це дуже пов'язано з наявністю/відсутністю даних для аналізу: якщо нема чи недостатньо даних, то неможливо коректно побудувати діаграму реального перебігу подій, і приходиться вимушено використовувати традиційний опис процесу. Тоді як останній, фактично, можна розглядати як інструкцію: всі дії описані дієсловами-наказами, сам алгоритм передбачає той чи інший варіант для вказаних виконавців.

Тобто, якщо спрощено, такий опис є інструкцією, що має робити той чи інший виконавець в тому чи іншому випадку (подекуди описи і використовуються в якості інструкцій, це дуже зручно).

Тоді як для аналізу більш потрібен опис, який відображає ланцюжок фактів, що вже відбулись (і зафіксовані) і які з'єднані між собою по причинному чи послідовному принципу.

Щоб було зрозуміліше, наприклад, розділення ланцюжка на дві гілки в традиційному опису в BPMN описується через т.зв. гейти, які описують подальший перебіг та/чи вибір для виконавця. Тобто, наприклад, в якийсь момент виконавець, оператор контакт-центру, після запитання, чи є у клієнта страховка, має діяти в залежності від відповіді по одному чи другому сценарію. Тоді як опис процесу як опис вже відбувшихся подій просто показує, приміром, що оператор пішов по шляху "страховка є" 299 разів за вказаний період, тоді як по шляху "страховки немає" лише 43 рази. У мене був досвід, коли купа часу була витрачена на обговорення можливого варіанта подій, який насправді фактично ніколи не відбувався в реальності!

Іншими словами, є принципова різниця між описом того, що треба робити, і описом того, що вже сталось. Опис того, що вже сталось, взагалі не дуже схожий на опис алгоритму: зазвичай, це просто послідовність фактів, які подекуди розгалужуються, але не так різноманітно, як це може бути в описі-інструкції.

Інструменти для аналізу процесів можуть передбачати дуже корисну фунцію залишати в описі лише найбільш повторювані події. І тоді опис може взагалі перетворитись в послідовність подій без будь-яких розгалужень. Це фактично буде опис найбільш частого сценарію. Аналогічно в опис-інструкцію можна скласти як найбільш бажаний порядок виконання дій, т.зв. happy way, але і тут є принципова різниця між найбільш частим фактично порядком подій та найбільш бажаним порядком дій.

Крім того, опис процесу як пов'язаних зафіксованих фактів, зазвичай, передбачає часові показники між подіями. Тобто через який час після однієї події настала наступна. Часто це один з самих важливих показників процесу і один з самих цікавих з точки зору аналізу. Зрозуміло, що в традиційному описі цей показник можна вказати лише або гіпотетично, або як складову алгоритму. Це втрачає цінність, коли треба аналіз реального, а не гіпотетичного процесу.

Ці складнощі примножуються, коли діаграми взагалі не використовуються.

5. Використання лише текстових описів процесу.

Це не можна назвати помилкою: фактично, це просто ускладнює сприйняття, а теоретично все лишається таким самим.

Досить часто документи, пов'язані з аналізом чи описом процесів, насправді не використовуються. Причиною можуть бути помилки на різних рівнях, основні — невідповідність описів реальному життю та відсутність реальної користі від описів. Але однією з причин є також важкий для сприйняття формат опису. Структуризація через доповнення тексту діаграмами, примітками та вкладеннями значно полегшує сприйняття — і може зробити документ більш корисним, навіть якщо це аналіз та рекомендації, у яких коротке "життя".

Щодо рекомендацій, ще один делікатний момент:

6. Надання поспішних рекомендацій.

Доволі "популярна" помилка — консультант бачить знайому ситуацію і відразу ж дає вже відому відповідь чи пораду.

Насправді, за проблемою чи хибною процедурою може стояти багато факторів, які можуть бути навіть не пов'язані з суто процесами. Наприклад, брак кваліфікованих кадрів, специфічні вимоги клієнтів чи обмеження вже існуючих інформаційних систем.

 

Процеси виконуються неідеальними людьми в неідеальних умовах — тому нема сенсу рекомендувати, наприклад, перейти на хмарні сервіси, якщо нема жодного спеціаліста, який хоч трохи розуміє, що за цим стоїть і як це буде виглядати. 

Часто це наслідок вже сформованих та надто негнучких поглядів консультантів, але може бути і результатом ще однієї проблеми:

7. Упередженість аналітика (чи того, хто робить аналіз процесів).

Почну з прикладів: аналітики, які працюють з системами документообігу, часто все бачать через призму "ходу" документів, від пункта до пункта.

Аналітики, що працюють із складними системами, воліють відразу все бачити в межах "великої картини", що передбачає наявніть і ERP, і CRM систем, і системи документообігу, і багато чого іншого.

Найбільш часта причина такої упередженості — в тому, які саме послуги надає компанія, де працює аналітик. Той, в кого в руках молоток, все інше бачить як цвяхи.

Проста порада — залучати до аналізу незалежних фахівців, але є серйозна проблема: потрібно буде все одно як мінімум вміти скористатись результатом такого аналізу.

На цьому все, це далеко не повний перелік проблем та помилок — лише найочевидніша їх частина, дякую, що дочитали.