Терміни проєкту впровадження
Однією з найчастіше обговорюваних нами тем при погодженні угод із Замовниками, є терміни проєкту впровадження. І, як наслідок, жвава дискусія по юридичному відображенню відповідальності за порушення термінів.
Наведемо кейс із практики. Клієнт – міжнародна компанія. Рішення про впровадження приймалося протягом двох років. Коли врешті підійшли до угоди, наш шаблон був повністю перероблений клієнтом таким чином, щоб додати штрафи за будь-яке відхилення від термінів, починаючи з першого дня протермінування. Ми кілька разів пояснювали клієнту, що в таких проєктах це не працює.
По-перше, 90% задач в проєкті неможливі без залучення Замовника:
- не прийшли Ключові користувачі на інтерв’ю – ми не можемо виконувати опис вимог та налаштування системи,
- не протестували Ключові користувачі систему – ми не можемо переходити до етапу підготовки до запуску.
По-друге, у випадку роботи за схемою «зсув по термінах-штраф» замість фокусу на результаті команда починає «адмініструвати відхилення» і постійно шукати, хто винен. Це заважає досягненню основної мети нашого співробітництва.
Аргументи не спрацювали, ми відмовились від таких умов. Згодом клієнт повернувся, знайшли компроміс і почали проєкт.
Повернення в реальність
Далі прийшла реальність. Проєкт, що був розрахований на 5,5 місяців, і мав закінчитися тиждень тому, станом на сьогодні виконаний десь на 50%. Значну частину часу ми чекаємо на клієнта: завантаженість операційними задачами, погодження всередині, зайнятість власника, а тільки він може затвердити деякі рішення.
Така ситуація трапляється майже на кожному проєкті. Ті клієнти, в яких немає подібних проблем, є скоріше виключенням, ніж правилом. Насправді, такий патерн зрозумілий, адже впровадження ERP для нас – це операційна діяльність, а для клієнта – це додаткове і нетипове навантаження і момент, коли хочеться приймати дуже зважені рішення, погодивши їх з усіма зацікавленими сторонами, і для цього потрібен час.
Можемо сказати, що з точки зору економіки компанії, що впроваджує, подібні затримки – це витрати, а точніше недоотриманий дохід, бо ми бронюємо команду під клієнта і коли вона недозавантажена, ми не отримуємо того доходу в одиницю часу, який планували, маючи при цьому фіксовані витрати. 5-10 років тому ми навіть ображались на клієнтів, коли вони «гальмували» процес.
Об’єктивний підхід
Як і з будь-якою «проблемною» ситуацією, для початку її треба усвідомити, а потім подумати, чи ти можеш її змінити. Досвід показує, що ні, навряд чи клієнти зможуть приділяти впровадженню стільки часу, скільки ми. Тому тепер ми дивимося на життя відкрито і розуміємо, що 100% завантаженість нашої команди на проєкті можлива лише у двох проєктних етапах – на виконанні погоджених кастомізацій та на запуску, тобто тоді, коли ми вийшли на етапи, де ми не залежимо від замовника, або тоді, коли для клієнта ERP стає вже не додатковим навантаженням, а основною роботою (це я про етап запуску системи в експлуатацію).
Приймаючи цей факт, ми стали планувати навантаження команди по-новому. Для кожного з учасників команди, окрім основного проєкта/проєктів завжди є ще невеликі завдання по зовнішніх чи внутрішніх проєктах в черзі, які дозволяють «перекривати» паузи на проєктах. Таким чином, ми ще й стали більш продуктивними, виконуючи більший об’єм задач, ніж могли б, виділяючи людину на проєкт на 100%.
Повертаючись до нашого «повільно працюючого» замовника, який хотів всі затримки обкласти штрафами. Пройшов час, проєкт рухається, але не так швидко, ніж очікувалося. Ми згадали обговорення угоди з клієнтом, і зайвий раз зраділи, що все ж таки знайшли компроміс при погодженні умов договору і сконцентровані на виконанні проєкту, а не на пошуках винних.
Практичні рекомендації
Підсумовуючи, важливо розуміти природу ERP-проєктів і те, що завжди треба враховувати контекст. Можливо, 100% відповідальність Виконавця за терміни в якихось галузях працює, але в ERP-впровадженні – ні. Щоб проєкт йшов так, як запланували, потрібно:
- реалістично оцінити
- заручитися підтримкою топ-менеджмента обох сторін
- проводити щотижневі зустрічі по статусу за участю обох сторін, відслідковувати прогрес
- проводити один раз на 3-4 тижні зустрічі Керуючого комітету, і не боятися озвучувати замовнику всі новини – як хороші, так і погані (все йде за планом/все йде повільніше з таких-то причин/є затримки/є складнощі). Ідея в тому, щоб давати відкриту картину про стан справ і разом працювати над подоланням складнощів
- призначати на роль ПМ людину, яка знає, що таке впровадження ERP, розуміється на сутності кожної задачі та може гнучко, «творчо» підходити до розподілу задач та послідовності їх виконання. Тобто не просто відслідковувати, чи зроблена задача, а мати знання та досвід для того, щоб перерозподіляти задачі, переставляти, не нашкодивши проєкту, а навпаки, просуваючи його вперед.
Для тих, хто обирає команду по впровадженню, зверніть увагу – якщо підрядник легко погоджується на жорсткі штрафи за строки, це не завжди ознака надійності. Часто це означає або недооцінку складності і відсутність досвіду, або те, що ризики «заховані» в інших частинах проєкту.