Іра Пемпусь

Стейкхолдер – вже звичний термін в бізнес-лексиконі. Він з проєктного менеджменту вже вдало мігрував і в інші професії. Всім зрозуміло, що стейкхолдер – це зацікавлена особа, замовник проєкту. Однак на практиці не завжди просто правильно виявити, хто дійсно зацікавлена сторона в замовленому проєкті. Тому хочу поділитися історією з власного, не гіркого, але дуже непростого досвіду. Моя команда займається розробкою і впровадженням управлінських систем. А наші замовники – це підприємства, які зважено і ґрунтовно приймають рішення з впровадження нового чи заміні старого програмного забезпечення. В цій сфері нема «імпульсивних покупок». Принаймні я так думала раніше. Одного разу до нас звернувся керівник ІТ підрозділу від імені власника підприємства. Запит – перейти на нову ERP систему. Вимоги до проєкту були сформовані досить чітко і ґрунтовно. Були описані ключові бізнес-вимоги, описані поточні бізнес-процеси, закцентована увага на слабких сторонах, які мають бути вирішені. Підкріплено це було запевненням, що рішення прийняв сам власник. До того ж задача термінова – через 1,5 місяця ціле підприємство має перейти на нову систему. Єдиний нюанс – на тій самій зустрічі замовник озвучив про своє звільнення і познайомив з командою, яка залишається в процесі. Все виглядало як поточна ситуація передачі вже підготовлених і систематизованих справ. Тому звісно ми взялися за проєкт. Цілі визначені, дорожню карту (road map) сформовано, договір підписано, вирушаємо в шлях реалізації. Однак виявилося, що корабель наш відчалив без капітана. Команда розробки замовника залишилась фактично без функціонального керівника і формально була приєднана до іншого великого підрозділу. Роль керівника проєкту від замовника взяв на себе керівник іншого підрозділу, який не мав ні авторитету, ні адміністративних повноважень, ні відповідних компетенцій в області IT-проєктів. Прямої комунікації між нашою командою розробки та власниками бізнесу не було, ми мали тільки запевнення функціонального керівника, який, нагадаю, невдовзі звільнився. От така собі валіза без ручки. Однак навіть в ситуації організаційної невизначеності наша команда взялася до розробки нової ERP системи. В результаті обговорень дату старту таки відсунули ще на 3 місяці. Автоматизації підлягало два напрямки бізнесу – B2C та B2B. В обох напрямках був свій лінійний керівник (топ-менеджер), кожен з яких підзвітний лише напряму власнику і не співпрацював один з одним. Крім того, під цими керівниками стояли керівники відділів, які також мали право скеровувати роботу своїх підлеглих та впливали на їхнє ставлення до переходу на нову систему. При цьому користувачів системи налічувалося понад сто. І, нагадаю, в цьому коловороті управлінців Замовником та керівником проєкту виступала людина без авторитету, але наближена до власника підприємства. Почався саботаж. Через місяць після старту виробничої експлуатації, один підрозділ на чолі з керівником заявив, що їм взагалі ніхто не повідомив про те, що вони повинні були перейти на нову систему, і тому продовжували працювати в старій. Інший підрозділ вводив документи частково в нову, частково у стару системи, коли їм це було простіше. В результаті бухгалтерія не мала повноти даних ні в новій, ні в старій системі. Звернутися по допомогу не було до кого, бо керівник проєкту лише вів розмови та наче передавав рішення власника, але ніяк не брав участі у вирішенні конфліктів та просуванні проєкту. Кожна проблема, помилка, банальна некомпетентність, небажання користувачів чи нерозуміння роботи системи подавалися, як її недієздатність і, як наслідок, втрата бізнес-цінності підприємства. Ніхто не заглиблювався в суть проблеми, ніхто не брав на себе обов'язок вияснити та зрозуміти, лише зливали свій негатив на команду розробки й нову систему. Навіть дійшло до попередження про звільнення проджект-менеджера розробки та керівників фінансового сектора. Але як би то не було, ми перейшли (точніше перевели за ручку) на нову ERP систему підприємство, як і було обговорено на першій зустрічі. Як? Бо прийняли рішення не здаватися, а навантажили себе розглядом кожної ситуації, психологічним розбором команди замовника і виявленням основних протестуючих проти нового софту. Цей досвід допоміг нам надалі розробити якісну навчальну базу. Але цей кейс міг би бути не описаним в цьому блозі, якщо б на самому початку ми комунікували зі справжнім стейкхолдером. Бо максимально залученим, зацікавленим та переконаним у потрібності змін на підприємстві має бути CEO або власник бізнесу, що своєю чергою зобовʼяже керівників підрозділів, функціональних менеджерів, просувати ці зміни. Якщо ви не залучаєте вище керівництво, ви можете витратити час на налаштування свого рішення лише для того, щоб з’ясувати, що кінцевий результат не відповідає вимогам керівництва. Як в моїй ситуації, наша співпраця закінчилася запитанням від власника: «так, а для чого ми відмовилися від старої системи та чому вирішили почати проєкт розробки й впровадження нової?» . Відповіді на останнє питання я, на жаль, так і не знайшла. Бо це теж саме, що запитати «навіщо ви це зробили?» у офіціанта, який замінив вам каву на чай за вашим же запитом. Але тепер точно знаю, що в такій сфері як впровадження ERP системи не може бути іншого замовника, ніж власник чи CEO бізнесу. Чого і кожному проєктному менеджеру бажаю – знати свого по-справжньому зацікавленому в проєкті стейкхолдера.