Сім рішень, які ухвалюють на першому тижні й не змінюють потім: незворотні рішення.
Що варто питати в підрядника до підписання: партнерство і технології.
Провалюється не техніка
Коли проєкт зривається, першою версією стає «система не підійшла». Майже завжди це не так. Business Central, SAP, Odoo чи будь-яка інша зріла система технічно здатна закрити процеси звичайної торгової або виробничої компанії. Провалюється те, що навколо: рішення, домовленості й люди.
Це важливо, бо визначає, де шукати ризик. Якщо причина в системі — рятує вибір іншої системи. Якщо причина в тому, що ніхто не описав процеси, зміна вендора нічого не дасть: другий проєкт зірветься так само, тільки дорожче.
Нижче — сім причин у тому порядку, у якому вони справді трапляються.
Сім причин у порядку частоти
1. Ніхто з боку замовника не відповідає за проєкт
Найчастіша причина з великим відривом. Підрядник не може ухвалювати рішення про ваші процеси — він може лише запитувати. Якщо з вашого боку немає людини з повноваженнями й часом, кожне питання зависає на тижні, а проєкт розтягується вдвічі.
«Відповідає директор» зазвичай означає, що не відповідає ніхто: у директора немає двадцяти годин на тиждень на цей проєкт. Потрібна конкретна людина, яка розуміє бізнес, має право говорити «робимо так» і в якої знято частину поточних задач.
2. Автоматизують безлад
Якщо процес не описаний і працює на домовленостях у чаті, система його не полагодить — вона його зафіксує. Причому в жорсткішій формі, бо тепер обійти незручний крок стало важче, ніж раніше.
Правильний порядок: спершу зрозуміти, як процес має виглядати, потім налаштовувати. Не навпаки.
3. Дані переносять «як є»
Дублі номенклатури, контрагенти в трьох написаннях, залишки, які не сходяться зі складом. Усе це переїжджає в нову систему й починає псувати життя вже там, тільки тепер у цьому винна «нова програма». Про порядок чистки — у чек-листі підготовки даних.
4. Обсяг проєкту росте по ходу
Почали з фінансів і складу, за місяць додали виробництво, потім CRM, потім інтеграцію з сайтом. Кожне додавання виглядає розумним окремо, разом вони зривають строк і бюджет.
Проблема не в самих доповненнях, а в тому, що вони не оформлюються як зміна домовленостей. Строк лишається старий, обсяг новий — далі математика.
5. Навчання проводять зарано
Класика: команду навчили за два місяці до запуску, на демонстраційній базі. До моменту старту забулося все. Навчати треба близько до запуску й на власній налаштованій системі з реальними даними.
6. Паралельний період не має дати завершення
Стару систему залишають «про всяк випадок», і люди повертаються туди, бо там звичніше. Дві системи ведуться одночасно кілька місяців, обидві неповні. Дата відключення старої має бути призначена до старту, а не після.
7. Доробки замість перегляду процесу
Кожна доробка коштує двічі: один раз при написанні, другий — при кожному оновленні. Частина запитів на доробку насправді означає «ми звикли робити так», а не «інакше не можна». Розділяти ці випадки — окрема робота, і вона окупається. Критерії — у статті про доцільність кастомізації.
Ознаки, що проєкт іде не туди
Зрив рідко буває раптовим. Симптоми з’являються за місяці.
- Зустрічі закінчуються без рішень, ті самі питання обговорюються втретє.
- З вашого боку на дзвінки приходять різні люди, і кожен наступний скасовує домовленості попереднього.
- Строк здачі зсувається, але обсяг робіт при цьому не зменшується.
- Ключові користувачі жодного разу не бачили систему.
- Список доробок зростає швидше, ніж закривається.
- Ніхто не може назвати дату, коли стара система вимикається.
Дві й більше ознаки одночасно — привід зупинитися й перезібрати домовленості, а не прискорюватися.
Що робити, якщо вже почалося
Проєкт, який іде не туди, майже завжди рятується — але не збільшенням темпу.
Зупиніть додавання обсягу. Заморозьте перелік того, що запускається в першу чергу. Усе інше — у другу чергу, письмово, з окремим строком.
Призначте одну людину з вашого боку. Якщо її немає, це головне, що треба виправити, і виправити сьогодні.
Скоротіть перший запуск. Краще запустити фінанси й склад і побачити, що воно працює, ніж півроку готувати ідеальний старт усього одразу. Перший успішний запуск змінює ставлення команди до проєкту сильніше за будь-які пояснення.
Призначте дату відключення старої системи. Навіть якщо вона здається нереальною — без неї паралельний період не закінчиться ніколи.
Чотири речі, які знімають більшість ризиків
| Що зробити | Коли | Який ризик знімає |
|---|---|---|
| Призначити відповідального з повноваженнями | До підписання договору | Причина №1 |
| Описати процеси текстом | До вибору системи | Причини №2 і №7 |
| Почистити довідники | До міграції | Причина №3 |
| Зафіксувати обсяг першої черги й дату відключення | У договорі | Причини №4 і №6 |
Три з чотирьох робляться до того, як ви оберете підрядника, і жодна не вимагає бюджету. Це найдешевша страховка з можливих: описані процеси й чисті довідники скорочують і строк, і вартість самого проєкту. Порядок вибору підрядника розібрано в гайді з вибору ERP, а що з цього складається бюджет — у статті про вартість впровадження.
Часті запитання
Яка частка проєктів справді зривається?
Оцінки в галузевих дослідженнях дуже різняться, бо всі рахують по-різному: хтось вважає зривом перевищення бюджету, хтось — тільки повну відмову від системи. Практичніше дивитися не на статистику, а на власні ознаки ризику: відсутність відповідального, неописані процеси, брудні дані.
Чи можна врятувати проєкт, який уже зривається?
Майже завжди можна, але не прискоренням. Спершу заморожується обсяг, потім призначається відповідальний з вашого боку, потім скорочується перша черга запуску. Прискорення без цих трьох кроків лише наближає момент зупинки.
Хто винен, якщо проєкт зірвався — підрядник чи замовник?
Відповідальність зазвичай розподілена, і саме тому пошук винного не допомагає. Підрядник відповідає за те, щоб попередити про ризик і не братися за нереальний обсяг. Замовник — за рішення щодо власних процесів, які підрядник ухвалити не може.
Чи допоможе зміна підрядника?
Допоможе, якщо причина в підряднику: немає компетенції в галузі, зникає зі зв’язку, не фіксує домовленості. Не допоможе, якщо причина на вашому боці — тоді другий проєкт повторить долю першого, тільки дорожче через повторну міграцію.
Скільки часу керівник має закладати на проєкт?
Не керівник, а призначений відповідальний — і це щонайменше кілька годин щотижня протягом усього проєкту, з піками на етапах узгодження процесів і тестової міграції. Якщо такого часу немає ні в кого, проєкт краще перенести.