Привіт, мене звуть Любік Кислюк, і сьогодні я хочу поділитися з вами своїм досвідом побудови й супроводу бізнес-процесів, а також розповім про перешкоди, які можуть виникнути у вас на цьому шляху та як їх долати.
Маю відзначити, що, незалежно від посади, яку я обіймав у різних компаніях, мені завжди дуже допомагав бізнес-аналітичний майндсет, який я виробив на старті кар’єри і який удосконалюю досі. Для кращого розуміння мого досвіду далі пару слів про мій кар’єрний шлях в IT:
- керував вебстудією;
- працював ВА, а потім керував відділом ВА у компанії Verta Media (Adtelligent);
- обіймав посаду COO у компанії Robosoft Industries;
- керував RnD-відділом доповненої реальності у Snap Inc;
- під час роботи в Snapchat мене запросили в Autodoc AG, щоб побудувати в компанії відділ маркетингової аналітики й керувати ним, чим зараз і займаюся і про що зараз розповім.
Задача — побудова відділу в компанії, що трансформується
Коли я прийшов у Autodoc, компанія вже перебувала в фазі трансформації з бізнесу, що органічно зростає, у круту технологічну IT-компанію. В рамках цієї трансформації необхідно було перейти від інтуїтивного підходу в прийнятті бізнес-рішень до data driven підходу, тобто до прийняття рішень, на основі даних.
Щоб забезпечити перехід, необхідно було побудувати відділ аналітики. Насправді не лише аналітики — є ще дата-інженери й розробники, процеси збору, трансформації та зберігання даних і багато чого ще, але стаття не про це. Важливо також врахувати, що відділ маркетингової аналітики буде працювати не у вакуумі, а в щільній взаємодії з іншими департаментами компанії, для чого необхідно виробити процеси і процедури, які не ускладнять життя, а принесуть максимум цінності з мінімальним ускладненням взаємодії. Для того щоб все це організувати, необхідно виконати кілька кроків.
Крок 1. Аудит. Зрозуміти як це працює зараз
Якщо перед вами стоїть задача трансформувати щось, починайте з аудиту поточної ситуації. Для цього досить просто виділити ключових учасників існуючого процесу і провести з ними інтерв’ю. На інтерв’ю зберіть інформацію про те, як це працює зараз: який процес від етапу постановки задачі до постачання рішення, які ресурси задіяні, за якими правилами це працює.
Важливо поговорити хоча б із трьома ключовими учасниками: це дозволить вам дізнатися, як існуючий процес бачать різні люди. Якщо вони бачать картину однаково — люди синхронізовані, нехай і в старому процесі. Якщо ж вони опишуть вам різні процеси, хоча насправді він один, то люди розсинхронізовані, й вам, крім зміни процесів, потрібно буде продумати ще й синхронізацію учасників. Інакше який сенс працювати над новим класним процесом, якщо люди сприйматимуть його по-різному.
На етапі аудиту важливо не просто зібрати інформацію про процес, а розпочати вибудовувати довірливі стосунки з учасниками процесу. Під час інтерв’ю не просто збирайте інформацію про стан справ, а просіть дати оцінку того, що відбувається, поділитися болями й ідеями про те, як на думку співробітника можна це змінити. По-перше, це дозволить вам отримати варіант вирішення проблеми, який можна буде «докрутити» до витонченого рівня. По-друге, ви таким чином починаєте налагоджувати ті самі довірливі відносини, адже людям дуже приємно, коли цінують їхню експертну думку, тим більше що ця думка часто буває корисною.
Люди повинні розуміти, що ви не черговий «манагер», який бездумно робить бюрократичне відгородження, а що ви налаштовані на те, щоб відділ давав бізнесу максимум цінності, враховуючи при цьому інтереси й біль учасників процесу як з боку замовника, так і з боку виконавців.
Результати інтерв’ю конспектуйте в документ: можна робити позначки безпосередньо під час розмови. Після того, як ви поспілкуєтеся з усіма ключовими учасниками, зберіть до цілого те, що ви записали. На цьому етапі стане зрозуміло, що багато болів і проблем перетинаються, і насправді їх не так багато, як здавалося на перший погляд. Тепер можна розпочинати другий етап.
Крок 2. Запропонувати зміни. Описати, як і що працюватиме по-новому
Після того, як аудит проведено і зрозумілі «масштаби трагедії», необхідно розробити змінений флоу, який має вирішити існуючі проблеми (в ідеалі не створивши нові). Даний флоу необхідно описати в форматі, зрозумілому для всіх учасників: загалом, буде досить добре структурованого гуглодока, який за бажанням можна присмачити нескладними схемами, які спростять розуміння нового процесу.
Загалом цей документ повинен відповідати на такі запитання:
- Як поставити задачу на відділ: куди натиснути в Jira, щоб задача потрапила туди, куди потрібно й не загубилася.
- Як правильно описати задачу: шаблон з DoR, щоб не затягувати етап дискавері й одразу вказувати в задачі те, що потрібно.
- Як виглядає життєвий цикл задачі: в ідеалі з прив’язкою до статусів задач у тій же Jira для прозорості.
- Як відбувається пріоритизація задач й утилізація беклогу. Можливі різні варіанти: в нас, наприклад, через велику кількість задач від різних відділів, замовники розбиті по тирах для спрощення пріоритизації.
- На якому етапі й за якими правилами відбувається приймання задач замовником.
- Яка політика роботи з правками і змінами у вимогах.
Мета другого кроку – розробити новий бізнес-процес. Причому зовсім необов’язково робити для цього BPMN або якісь інші схеми. Підійде й кастомна блок-схема з текстовим описом. Важливіше не те, що ви використовували крутий інструмент, а щоб це було зрозуміло вам і людям, яким ви це презентуватимете.
Крок 3. Зібрати фідбек
Не поспішайте впроваджувати новий флоу одразу після того, як розробили його на папері, оскільки ви могли щось не врахувати, й тут вам на допомогу прийде зворотний зв’язок від людей, для яких цей процес і розробляється.
Попросіть учасників процесу покритикувати, «рознести» ваш документ. І ставтеся до цього розносу правильно, адже це робиться не для того, щоб поставити вашу експертність під сумнів, а щоб врахувати максимум можливих проблем ще до запуску нового процесу.
Не бійтеся підступних запитань. Ви завжди можете відповісти: «Гарне зауваження, дякую. Поки я не маю рішення, над ним мені треба буде попрацювати». Важливо розуміти, що ці запитання можуть підсвітити проблеми, які ви могли упустити.
Після того, як отримаєте зворотний зв’язок, внесіть правки, які враховують недоліки, що спливли, і проведіть презентацію для всіх причетних. Причому ця презентація не має бути односторонньою — у всіх учасників повинна бути можливість ставити запитання та уточнювати деталі.
Коли проводите презентацію якихось нововведень, обов’язково надсилайте учасникам відповідні документи для ознайомлення. В іншому випадку, ви проведете презентацію, ніхто нічого не зрозуміє і запитань не буде, тому що люди не встигнуть заглибитись у контекст.
Крок 4: Подолати опір
Коли аналітик починає вносити зміни, він, швидше за все, зустрінеться з опором. Навіть якщо всі погодилися, будьте готові до того, що дехто писатиме, що стало гірше/незручно/незрозуміло.
Люди бояться змін, бо навіть поганий процес став для них зрозумілим і звичним. Люди звикли «страждати по-старому» і звикати до чогось нового страшно. Раптом краще не буде, а переучуватися доведеться в будь-якому разі.
Опір навряд чи буде активним, особливо якщо в розробку нового флоу були підключені всі причетні, адже складніше заперечувати те, в чому ти сам брав участь. Максимум опору, який на вас чекає — це скарги на те, що стало незрозуміло чи незручно. Хочу зазначити, що до цього зворотного зв’язку також варто прислухатися, адже учасники можуть звернути вашу увагу на якісь реальні проблеми. Щоб зрозуміти природу проблеми, просіть аргументацію: «Чому це погано/незручно?». Якщо аргументація буде розмитою, то, швидше за все, варто просто попрацювати над тим, щоб співробітники краще розуміли процес: провести воркшоп або Q&A-сесію.
Крок 5: Супровід змін
Дуже часта помилка — не стежити за супроводженням змін. Бізнес-аналітик може вважати, що коли він зробив аудит і прописав процес — на цьому його задача завершена. Зміни не впроваджені, поки всі не звикли до нового процесу і поки всі його не дотримуються. Якщо процес не дотримується, він і не працює.
Ще один важливий момент, який необхідно врахувати, — занурення у процес нових співробітників. У велику компанію часто приходять нові люди, й потрібно продумати механізм, в якому новачки знайомитимуться з процесами, інакше проблеми неминучі: задачі приходитимуть не на той проєкт, не з тими компонентами тощо.
Менше проблем, якщо кадри «добираються» — тоді «старший» колега допоможе вписатися в процес. Коли ж кадри приходять на заміну, то замість однієї функціональної одиниці з’являється нефункціональна одиниця, яка «починає робити дивне».
Життєвий цикл зміни бізнес-процесу: чекліст
- Провести аудит існуючого процесу, записати проблеми.
- Записати всі можливі вирішення кожної проблеми в одному документі.
- Зібрати фідбек з усіх причетних з боку бізнесу й розробки.
- Внести зміни до документації.
- Супроводжувати зміни, доки їм не почнуть слідувати всі.
І пам’ятайте, що оптимізувати бізнес-процеси в компанії можуть не лише бізнес-аналітики. Якщо, наприклад, саппорт-спеціаліст побачив проблему в процесах і вигадав як її вирішити, він теж займається управлінням бізнес-процесів.