Аналітика процесів та формування технічного завдання

На початку проєкту впровадження ваші процеси не передбачають використання Creatio. Це абсолютно нормально, ви ще не встигли впровадити Creatio, тому ваш бізнес, люди, департаменти адаптувалися до існуючої моделі. Але чи нормально, якщо процеси залишаться незмінними під час або після впровадження Creatio? Звісно, ні. Адже головна мета впровадження не просто перенести те що маємо. Ключова цінність – вдосконалення або трансформація процесів (вдосконалені процеси – вдосконалений результат). Послуга аналітики – це етап, коли ми готуємо ваші процеси до змін та трансформації. Ми покажемо й детально опишемо нашу технологію, щоб ви могли заздалегідь переконатися в її ефективності.

Коли потрібно формувати ТЗ?

Найбільший профіт від розробки ТЗ ви отримаєте:

  • якщо ваш проєкт по ємкості перевищує 250 годин впровадження. Чим більше обʼєм впровадження, тим цініше процес формування письмових вимог, так як дозволяє структурувати іі віртуально перевірити ідеї впровадження;
  • якщо це ваше перше впровадження CRM/ERP/систем оцифровки процесів. Чим якісніше ви продумаєте ваші процеси, тим менше змін, редагувань та допрацювань вони вимагатимуть;
  • якщо у вас відсутня власна команда впровадження. Це означає, що ви, скоріше за все, не зможете приділити достатньо часу та увагу проєкту, що потенційно може збільшити к-ть операційних помилок;
  • якщо “ставки” високі. Наприклад від успішності впровадження залежить ваше підвищення або доля проєкту в цілому;

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

Як працює технологія

Технологія будується за наступними принципами (в середині ми називаємо “три П, два З”):

  • Поступово;
  • Послідовно;
  • Постійно;
  • Заглиблюючись;
  • Зрозуміло;

 

ПОСТУПОВІСТЬ. Один із дефіцитів, який ми дослідили в процесі побудови нашої технології – це геометричне зростання “сірих зон” в процесі аналітики. Наприклад: під час розбору одного процесу (наприклад, «Ліди») рівень невизначеності становить лише ~5%; якщо одночасно аналізувати вже два процеси, цей показник зростає до ~15%; при трьох і більше процесах частка “сірої зони” може перевищити 30%. Чим більша “сіра зона” (невизначеність), тим вище шанс допустити операційну помилку впровадження: не врахувати важливий нюанс; витратити час на некорисний обʼєкт автоматизації; неточно відворити процес.

Щоб принципово зменшити можливі операційні помилки ми дотримуємось принципу поступовості:

  1. спочатку беремо більш прості та очевидні процеси;
  2. переходимо до наступного лише після розбору та візуальної презентації попереднього;
  3. виділяємо окремі сесії «питання–відповідь» та дискусії щодо найкращих варіантів реалізації;
  4. використовуємо демо-кейси відтворені в інтерфейсі Creatio та приклади, щоб спростити розуміння кінцевого результату;

Приклад попередньої (ознайомчої) презентації одного із обʼєктів документу, щоб спростити процес сбору вимог:

 

ПОСЛІДОВНІСТЬ. Ми свідомо будуємо послідовність розбору вимог і формування технічного завдання так, щоб кожний попередній процес «пояснював» або охоплював наступний. Наприклад, в інтернет-комерції процеси: “Замовлення → Відправка замовлення → Отримання і Оплата” є взаємопов’язаними та взаємозалежними. Розбираючи їх саме в такій послідовності, ми принципово спрощуємо роботу учасників з боку Замовника. Вони моделюють реальну діяльність свого підприємства без необхідності додатково готувати чи спеціально структурувати інформацію. Візуально це може мати наступний вигляд:

 

ПОСТІЙНІСТЬ. Це другий дефіцит, який ми виявили під час досліджень. Якщо розбирати процеси та вимоги занадто інтенсивно, виникає «втома учасників». Ми назвали цей ефект так: «Багато говоримо, мало результату”. Учасники бачать як зростає документ та блок-схеми, але не розуміють, як це реально працюватиме, адже налаштування потребує більше часу, ніж сам розбір. Водночас, якщо робити занадто великі паузи між аналітичними блоками, учасники втрачають контекст. Переходячи від першого процесу до наступного, потрібно витрачати додатковий час на відновлення пам’яті про попереднє обговорення. Саме тому ми завчасно плануємо строки початку й завершення кожного аналітичного блоку, а також адмініструємо їх виконання. Це дозволяє зберігати ефект постійності та підтримувати продуктивну динаміку проєкту.

 

ЗАГЛИБЛЕННЯ. Процеси можна розбирати й описувати по-різному. Але якщо робити це поверхнево, то у 90% випадків Замовник залишиться розчарованим результатами налаштувань. Достатня глибина розбору процесів – це обов’язкова умова успішного впровадження. Процеси люблять:

  • точність. Точність процесів – це основа корисних умов автоматизації;
  • роботу з деталями. Робота з деталями – це основна зручного інтерфейсу;
  • достовірність. Розуміння достовірної інформації укріплює зазначені фактори вище;

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

 

ЗРОЗУМІЛІСТЬ. Класичний опис бізнес-процесів має стандартизовану мову (синтаксис). Проте подібний підхід незрозумілий і не доступний без спеціальної підготовки для більшості учасників проєкту впровадження зі сторони Замовника. Мова опису документу має безпосередній вплив на результат. Тому ми розробили власну “мову опису бізнес-процесів”, ключові особливості якої:

  • вона зрозуміла для 98% учасників, включно з тими, хто не має технічної спеціальності чи окремої підготовки;
  • дозволяє замовнику оцінити точність і коректність вимог ще до того, як вони будуть реалізовані у програмному продукті;
  • дає можливість описувати логіки будь-якої складності: від простих вимог до обов’язковості полів > до складних формул та умов автоматизації.

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

Оосбливості та фішки технології аналітики

Ось такий перелік фішок та особливостей отримують наші клієнти:

  1. Виконуємо демо налаштування. Якщо процес важко уявити, або розібрати під час аналітичних інтервʼю, то ми будуємо прототип процесу безпосередньо в вашій Creatio. І вже на базі прототипу проводимо додатковий розбір або пояснення;
  2. Використовуємо рішення та успішні кейси. Маємо власну бібліотеку розроблених нами рішень, які пропонуємо та використовуємо для оптимізації процесів. Саме рішення ми завжди адаптуємо під особливості процесів Замовника;
  3. Розробили свою мову опису бізнес-вимог. Ми розуміємо, що більшість клієнтів не мають регулярного досвіду участі в бізнес-аналітиці. Тому використання спеціалізованих термінів або формальних нотацій, як-от BPMN, може ускладнювати спільну роботу;
  4. Аналітика синхронізована з впровадженням. Ми знайшли оптимальний таймінг проведення аналітики у звʼязці з впровадженням так, щоб аналітика не гальмувала процес налаштувань. Але і не забігала вперед, що призводить до втрати актуальності даних;

Правила надання послуг

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

  1. План аналітики вимагає його дотримання. План аналітичних зустрічей формується на старті та підлягає обов’язковому виконанню;
  2. Ми не використовуємо AI у моделюванні процесів. Ми не використовуємо результат роботи AI як зі сторони інтегратора, так і з боку клієнта. Процеси моделюються індивідуально та персонально;
  3. Розбір процесу – незворотня процедура. Після проведення аналітики і розбору процесу(ів) всі зміни зміни/трансформація вимог вважаються новими процесами та узгоджуються окремо;
  4. Фокус на узгоджених процесах. Фокусуємося на процесах, які були попередньо включені в процес аналітики. Нові ініціативи йдуть в окремий трек з окремим KPI та строками;
  5. Всі учасники підключаються до зустрічі готовими (в рамках зон відповідальностей). Відповідальність Інтегратора: побудувати іннтервʼю максимально результативно Відповідальність Замовника: відповісти на питання Інтегратора достатньому та надавати достовірну інформацію;