Систему обирають один раз, а з інтегратором працюють роками — спершу на впровадженні, потім на підтримці й розвитку. Саме тому невдалі ERP-проєкти майже завжди виявляються не проблемою платформи, а проблемою підходу до реалізації.
Нижче — 10 критеріїв і запитання до кожного. Відповіді на них дають більше розуміння, ніж будь-яка презентація.
1. Партнерський статус
Microsoft / офіційне партнерство означає наявність сертифікованих спеціалістів, прямої лінії підтримки вендора та доступу до roadmap продукту. Без такого партнерства нестандартні проблеми часто доводиться вирішувати методом спроб і помилок.
Запитайте: який у вас партнерський статус і чи можете показати сертифікати команди.
2. Досвід саме на вашому продукті
Dynamics — це сімейство рішень, а не один продукт. Business Central, Finance & Operations, Customer Engagement мають різну архітектуру та різні команди впровадження. Досвід у F&O не означає компетенції в BC.
Запитайте: скільки проєктів саме на цьому продукті ви завершили за останні три роки.
3. Релевантні галузеві кейси
Виробництво, дистрибуція, роздріб і сервіс мають різні критичні точки — загальних знань про ERP тут недостатньо.
Запитайте: покажіть кейс у моїй галузі — із задачами, обмеженнями й результатом, а не логотипом клієнта.
4. Українська локалізація
Ключовий фільтр для бізнесу в Україні. Перевіряйте не наявність локалізації взагалі, а конкретні ділянки:
- ПДВ-облік, податкові накладні, реєстрація в ЄРПН
- інтеграція з M.E.Doc і «Вчасно», підтримка SAF-T UA
- зарплата: табелювання, відпустки, лікарняні, звітність
- клієнт-банк: імпорт виписок і платіжних доручень
Окремо уточніть, хто оновлює локалізацію під зміни законодавства — вендор рішення чи сам інтегратор.
5. Формат передпроєктної оцінки
Найважливіший критерій зі списку. Якщо бюджет називають після однієї зустрічі — це не оцінка, а вгадування. Точні цифри дає лише передпроєктне дослідження з Fit-Gap-аналізом, коли ваші реальні процеси накладають на типову функціональність системи.
Запитайте: як ви рахуєте обсяг і яке допустиме відхилення фінальної суми від початкової.
6. Прозорість кошторису
До підписання договору ви маєте бачити не тільки цифру, а й межу: що входить у вартість, а що рахується окремо.
Зазвичай окремо тарифікуються:
- нові вимоги після затвердження обсягу робіт
- розширення на нові підрозділи чи юрособи
- ліцензії та їх підбір
Запитайте: що станеться з бюджетом, якщо в процесі з’явиться нова вимога.
7. Методологія реалізації
Проєкт одним великим циклом означає, що перший реальний зворотний зв’язок ви отримаєте аж на запуску, коли виправляти дорого. Спринтова модель дає перевіряємий результат кожні два тижні.
Запитайте: з якою періодичністю проходять координаційні наради і коли я побачу перший робочий функціонал.
8. Хто фактично працюватиме над проєктом
На презентації часто виступає одна команда, а працює інша — поширена причина розчарування.
Запитайте: назвіть поіменно консультантів і розробників на моєму проєкті та їхнє завантаження у відсотках.
9. Підхід до кастомізації
Надлишковий кастом — головна причина, чому системи згодом неможливо оновлювати. Здоровий підхід: максимум типового функціоналу, доопрацювання лише там, де вони дають конкурентну перевагу.
Запитайте: як ваші доопрацювання вплинуть на встановлення майбутніх оновлень від Microsoft.
10. Що відбувається після go-live
Запуск — не фініш. Перший місяць у системі критичний: саме тоді проявляються всі неточності налаштувань.
Мінімальний прийнятний набір:
- навчання команди до, а не після запуску
- присутність консультантів під час першого закриття звітного періоду
- регламент SLA із зафіксованим часом реакції
- оновлення під зміни законодавства
Якщо жоден із цих пунктів не прописано в договорі, підтримка після запуску існує лише на словах.
Як порівняти двох фінальних кандидатів
Коли залишилося дві пропозиції, дешевша частіше виявляється дорожчою. Порівнюйте не цифру, а її структуру:
- Обсяг робіт — однакові переліки функцій чи в дешевшій пропозиції половини модулів немає
- Години на управління проєктом — якщо їх не закладено взагалі, наради й протоколи все одно з’являться, але вже поза бюджетом
- Навчання та стабілізація — входять у вартість чи стануть окремим рахунком після запуску
- Кількість годин на доопрацювання — занижена оцінка кастому найчастіше і дає розрив між очікуваннями й фінальним чеком
Якщо різниця в ціні пояснюється саме цими позиціями, дешевша пропозиція просто переносить частину бюджету на майбутнє.
Червоні прапорці
Окремі речі мають насторожити ще до етапу порівняння комерційних пропозицій:
- бюджет називають без аналізу процесів
- обіцяють «зробити все, що скажете» без оцінки доцільності
- у договорі немає зобов’язань щодо строків з боку виконавця
- немає жодного кейсу, який можна прочитати цілком
- відповідальність за результат покладається лише на замовника
Один такий сигнал ще не привід відмовлятися, але два й більше зазвичай означають, що ризики проєкту доведеться нести самотужки.
Як це виглядає на практиці
CBPM Service закриває всі десять пунктів: офіційне партнерство Microsoft, 25 років в ERP-автоматизації, 200+ завершених проєктів у 12 галузях і гібридна експертиза в Business Central, 1С, BAS та Odoo.
Оцінку формуємо за результатами Discovery з Fit-Gap-аналізом — з відхиленням до 10% і фіксацією того, що входить у вартість, а що рахується окремо. Впровадження ведемо спринтами: наради кожні два тижні, щомісячна зустріч зі спонсором проєкту, демонстрація готового функціоналу. Процеси проєктуємо на типовому ядрі з мінімальним кастомом, щоб система залишалася оновлюваною. Після запуску консультанти працюють поруч із командою під час першого закриття періоду, далі — підтримка за регламентом SLA.
І окремий пункт, якого зазвичай немає в інших: зустрічні гарантії. Ми фіксуємо зобов’язання обох сторін, і санкції за зрив строків діють дзеркально — не лише для замовника.
Щоб зрозуміти масштаб робіт для вашої компанії, почніть із безкоштовної експрес-оцінки: дві-три зустрічі й перелік необхідних робіт на виході.
