Найпоширеніший сценарій провалу виглядає мирно: власник підписує договір, призначає відповідальним ІТ-директора й повертається до операційних справ. Через півроку виявляється, що проєкт стоїть, бюджет виріс, а команда тихо продовжує працювати в Excel.
Причина не в ІТ-директорові. ERP-система змінює не програмне забезпечення, а порядок ухвалення рішень у компанії — а це рівень повноважень, якого в ІТ-відділу просто немає. Впровадження ERP — управлінський проєкт, який лише виглядає як технічний.
Чому делегувати проєкт повністю не виходить
Під час впровадження постійно виникають питання, на які може відповісти лише перша особа:
- Змінюємо процес чи дописуємо систему? Кожне доопрацювання — це гроші й ускладнення майбутніх оновлень
- Чия версія процесу правильна? Коли фінанси й продажі описують один процес по-різному, арбітром має бути керівник
- Хто тепер погоджує платежі? Матриця погоджень — це перерозподіл влади в компанії, а не технічне налаштування
- Що робимо зі співробітником, який саботує перехід? Питання не до консультанта
Поки ці рішення чекають на власника, проєкт стоїть. Саме тому залученість топменеджменту фігурує серед головних факторів ризику в будь-якій методології впровадження.
Що конкретно робить керівник
Роль спонсора проєкту не про присутність на нарадах. Це п’ять зобов’язань, кожне з яких має вимірюваний вигляд.
1. Захищає межі проєкту
Головна загроза бюджету — не складність системи, а нескінченні «а давайте ще додамо». Кожна нарада народжує нові ідеї, і без людини з правом сказати «ні» обсяг росте безконтрольно.
Робоче правило: усе, що не входило в затверджений обсяг, іде у список другої черги. Через три місяці тестової експлуатації половина цих вимог відпаде сама.
2. Виділяє людей і фіксує їхнє завантаження
Ключові користувачі не можуть паралельно закривати місяць і описувати процеси. Якщо їхню участь не запланувати, вони просто не з’являться на зустрічах.
Робочий формат — письмовий план залучення: який спеціаліст, у якому місяці й на яку частку часу (наприклад, 50%) виділяється під проєкт. Без цього команда виконавця простоює, а строки їдуть.
3. Забезпечує мотивацію внутрішньої команди
Для співробітників впровадження — це додаткове навантаження поверх основної роботи, ще й із перспективою втратити звичні зручності. Без явного стимулу мотивація дорівнює нулю.
Практика показує: проєкти йдуть помітно швидше, коли керівник затверджує внутрішній документ про винагороду проєктної команди за результат — і команда знає, за що саме її оцінюють.
4. Тримає дисципліну термінів
Зрив графіка з боку замовника коштує не менше, ніж помилки підрядника: команда виконавця заброньована під конкретні місяці, і її простій оплачується в будь-якому разі.
Керівник — єдиний, хто може перерозподілити пріоритети, коли ключовий користувач раптом «зайнятий важливішим».
5. Ухвалює рішення про баланс типового й кастомного
Найдорожчі проєкти виростають не з ліцензій, а з рішення «зробіть як у нас було». Кожен відділ природно захищає звичний порядок роботи, і без керівника цю дискусію ніхто не закриє.
Питання, яке варто ставити на кожне доопрацювання: цей процес справді дає нам конкурентну перевагу чи ми просто до нього звикли? У першому випадку кастом виправданий, у другому — дешевше й надійніше перейти на типовий функціонал системи.
Скільки часу це насправді забирає
Найчастіше власник уникає ролі спонсора, бо уявляє собі щоденне занурення. Реальні витрати часу скромніші.
- Щомісячна зустріч зі спонсором — 1–2 години на статус за бюджетом, обсягом і напрямами розвитку
- Ескалації — 2–3 короткі рішення на місяць, зазвичай у форматі листа
- Ключові точки — презентація цільової моделі, затвердження обсягу, рішення про перехід у промислову експлуатацію
- Перший місяць після запуску — підвищена доступність, поки команда адаптується
Разом виходить 4–6 годин на місяць. Це кратно менше, ніж коштує розбір провалених проєктів через рік, і саме ці години найчастіше визначають, чи вкладеться проєкт у бюджет.
Чого керівнику робити не варто
Надлишкова участь шкодить не менше за відсутність. Типові перегини виглядають так:
- сидіти на всіх робочих нарадах і гальмувати ухвалення дрібних рішень
- вимагати відтворити в новій системі всі звички старої
- обіцяти команді, що «нічого не зміниться» — це неправда, і довіру це руйнує
- після запуску продовжувати приймати звіти в Excel
Останній пункт критичний. Якщо керівник просить дані у звичному файлі, команда розуміє все правильно і повертається до старих інструментів. Особистий приклад тут працює сильніше за будь-який регламент.
Як це виглядає в реальному проєкті
У проєкті для міжнародної ювелірної компанії CBPM Service запустила перший етап підсистеми продажів у Business Central за чотири місяці. Ключовою умовою такого темпу стало саме управлінське рішення: замовник призначив керівника проєкту з реальними повноваженнями, а перша особа долучилася як спонсор до щомісячних координаційних нарад. Питання узгоджувалися одразу, без ескалацій і тижневих пауз.
Тому методологія CBPM Service будується на взаємній відповідальності сторін: ролі, план залучення фахівців і дисципліна термінів фіксуються ще до старту. При цьому гарантії дзеркальні — там, де замовник бере на себе зобов’язання, виконавець відповідає за строки на тих самих умовах. За 25 років і 200+ проєктів у 12 галузях це виявилося надійнішим за будь-які обіцянки в комерційній пропозиції.
Якщо ви лише оцінюєте масштаб майбутнього проєкту, почніть із безкоштовної експрес-оцінки: дві-три зустрічі й перелік необхідних робіт на виході.
Часті запитання
Хто має бути спонсором ERP-проєкту?
Перша особа компанії або топменеджер із повноваженнями змінювати процеси й перерозподіляти ресурси. Керівник ІТ-відділу цю роль закрити не може.
Скільки часу впровадження ERP забирає у власника?
У середньому 4–6 годин на місяць: щомісячна зустріч зі спонсором, кілька ескалацій і участь у ключових точках проєкту.
Що робити, якщо співробітники саботують перехід?
Причина зазвичай не в системі, а у відсутності мотивації та зрозумілих наслідків. Питання вирішується внутрішнім документом про стимулювання команди, а не додатковими доопрацюваннями.
Автор та редактор
