Кастомізація ERP: як не вийти за бюджет під час впровадження

Баланс між кастомізацією і типовою функціональністю – питання, яке команда CBPM Service бачить практично на кожному проєкті впровадження. Обсяг доопрацювань здатний непомітно розростатися навіть тоді, коли на старті всі домовленості виглядали чіткими.

Про причини цього явища і про те, як утримати кастомізацію під контролем, говорять Євген Моргаєв, комерційний директор CBPM Service, та Нестор Барановський, архітектор ERP-рішень CBPM Service, які регулярно стикаються з цим питанням із двох різних боків проєкту: комерційного й технічного.

Чотири організаційні пастки, що розширюють проєкт

Практика ERP-впроваджень ділить замовників на дві крайності: 

• одні хочуть повторити типову функціональність без жодної зміни, 
• інші вимагають повністю переробити систему під себе. 

Здебільшого правда лежить десь посередині, а причина розширення обсягу кастомізації рідко пов’язана з реальними потребами бізнесу.

“Найбільші проблеми з розширенням скоупу пов’язані здебільшого не з потребами клієнтів, а з іншими питаннями, що виникають у процесі реалізації проєкту.”

– Нестор Барановський, архітектор ERP-рішень CBPM Service

У практиці команди CBPM Service такі причини зазвичай зводяться до чотирьох.

1. Відмова від проєктних процедур

Коли замовник відходить від узгоджених організаційних процедур ведення проєкту, у нього формується забагато центрів прийняття рішень. Вони конфліктують між собою і вимагають змін, які не завжди достатньо обґрунтовані, тож бюджет проєкту виходить за межі плану.

2. Автоматизація непропрацьованого процесу

Інша поширена причина – спроба перенести на систему процес, який компанія організаційно ще не довела до ладу. Дешевше й надійніше спершу відпрацювати процес вручну, а вже потім переносити його на автоматизовану основу.

3. Спроба скопіювати стару систему

Частина замовників хоче повторити діючу систему з усіма її недоліками просто тому, що звикла до звичної форми роботи. Буквальне відтворення старої логіки в новій системі обертається значною і дорогою кастомізацією.

4. Нечіткий скоуп заради швидкої оцінки

Коли замовнику потрібна оцінка проєкту для тендеру, він часто просить лише експрес-обстеження без повноцінного Discovery. Історичні оцінки, отримані так, рідко відповідають реальності, яка стає зрозумілою вже під час впровадження.

Євген Моргаєв підсумовує цю закономірність просто: у кожному з цих сценаріїв компанія зрештою платить за прогалини в організації проєкту, яких можна було уникнути ще до старту розробки.

Три історії, де недооцінка обсягу коштувала бюджету

Нестор Барановський розкриває цю закономірність на прикладі трьох реальних проєктів команди, де щось пішло не так ще до старту повноцінної розробки.

Кейс №1. Відсутність організаційної готовності

В одному проєкті в будівельній галузі замовник виявився організаційно не готовим до впровадження: оплату послуг він вважав достатнім внеском зі свого боку і не долучив команду до координаційних нарад та виконання пунктів протоколу. Взаємозв’язок між сторонами поступово втрачався, узгодженість процесів порушувалася, а бюджет виходив далеко за межі початкових очікувань. 

У результаті стало зрозуміло, що проєкт потрібно перезапускати й повертатися до вже пройдених етапів, а це означало додатковий бюджет, який замовник спершу вносити не планував.

Кейс №2. Компанія, яку будували “по ходу”

Схожа історія трапилася із клієнтом, що працює з програмним забезпеченням: команда почала будувати систему експериментально, без чіткого плану, пробуючи один підхід і, переконавшись, що він не спрацьовує, бралася за інший. Кожна така невдала спроба тягнула за собою додаткову роботу, яку доводилося переробляти. 

Такий підхід виявився значно дорожчим, ніж пропрацювати рішення заздалегідь або протестувати його на простішому кейсі.

Кейс №3.Оцінка на тендер без Discovery фази

Ще один, доволі масштабний проєкт стартував із вимоги “просто дайте нам оцінку”, бо замовнику потрібні були цифри для тендеру. Провести повноцінне передпроєктне дослідження на цьому етапі команді не дали можливості, тож довелося давати грубі орієнтовні суми. 

Точність цих оцінок, за визнанням самої команди, виявилася далекою від фінальної вартості проєкту, яка розкрилася вже під час реалізації.

Спільне для всіх трьох випадків одне: чим менше уваги приділено організаційній готовності на старті, тим дорожче обходиться виправлення на середині проєкту.

Чи можна взагалі уникнути розширення обсягу проєкту

Ідеальних замовників, які повністю розуміють проєктні процедури й довіряють обраному підряднику з першого дня, на практиці не існує. Проблема розширення обсягів проєкту через затримки чи адміністративні питання виникає майже завжди.

“За теорією управління ризиками неможливо передбачити всі ризики, але можна бути готовим до того, що вони виникнуть. Робота з ризиками полягає в тому, щоб мати конкретний план дій на випадок, коли вони виникають.”

– Євген Моргаєв, комерційний директор CBPM Service

Ми у CBPM Service наголошуємо: системна робота з ризиками спирається на кілька умов, які команда узгоджує із замовником ще до старту проєкту:

• чіткі відповідальні особи та ролі з боку замовника: хто ухвалює рішення про розширення обсягу, а хто відповідає за бюджет;
• регулярні координаційні наради: статусні раз на два тижні, за участю спонсора проєкту раз на місяць;
• закладений у проєкт час і бюджет на управління: планування, контроль виконання, протоколювання нарад;
• погоджений план залучення фахівців замовника на кожен місяць проєкту;
• мотивація проєктної команди замовника, прив’язана до результату впровадження;
• дисципліна термінів виконання з обох сторін, включно з дзеркальними гарантіями з боку CBPM Service.

Саме ця системність дозволяє вчасно реагувати на проблемні моменти і вносити зміни в проєкт як у бік узгодженого розширення кастомізації, так і в бік її зупинки.

Усе це є частиною ширших принципів і передумов успішного впровадження, з якими можна детальніше ознайомитися на сторінці, що розкриває нашу методологію.

Міф про кастомізацію як зайву статтю витрат

Поширена теза звучить так: чим менше кастомізації, тим краще для проєкту. У CBPM Service вважають це правило справедливим лише частково.

“Кастомізацію не варто сприймати як ворога. Ворог – це невиправдана кастомізація, яка замовнику приносить від’ємний ефект.”

– Нестор Барановський, архітектор ERP-рішень CBPM Service

Типова функціональність системи вже протестована вендором і не потребує додаткової оплати. Будь-яка кастомізація, натомість, накладає додаткові витрати: вона вимагає окремого тестування, ведення документації і підтримки при кожному оновленні системи. 

У платформах на кшталт 1С, де зміни можна вносити напряму в будь-який модуль, оновлення після накопичення багатьох правок перетворюється на серйозну проблему. 

У Business Central доопрацювання здебільшого реалізують як окремі розширення, не змінюючи типові модулі, і це суттєво полегшує процес оновлення, хоча повністю не знімає питання підтримки.

Євген Моргаєв визнає, що порахувати виправданість конкретної кастомізації непросто: ефект від неї часто нематеріальний і важко монетизований. Саме тому команда наполягає на повноцінному Discovery і дотриманні проєктних процедур ще до старту розробки, щоб кастомізації вистачало там, де вона справді потрібна.

MVP проти системного пропрацювання процесів: що працює краще на практиці

Перед командою CBPM Service регулярно постає вибір: почати з MVP і мінімальної кастомізації чи спершу системно пропрацювати всі процеси замовника за класичною waterfall-логікою.

Але існує ряд причин, чому класичний Waterfall в ERP-проєктах частіше програє.

У межах MVP кастомізація також присутня, просто в мінімальному обсязі, потрібному для конкретного етапу. Наскільки легко його побудувати, залежить від організаційної зрілості замовника: у клієнтів із пропрацьованими процесами MVP формується швидко, у решти це виходить значно важче. 

Спринтовий підхід

Спринтовий підхід, коли команда рухається короткими ітераціями з координаційними нарадами на кожному кроці, дає чітке розуміння поточного стану проєкту, не виключаючи загального бачення. 

Класичний waterfall

Класичний waterfall, коли спочатку прописується повне технічне завдання, а вже потім усе реалізується, на практиці часто не витримує: проєкти виходять за бюджет у три-чотири рази, коли початковий план розходиться з реальністю і специфікацію доводиться переписувати. 

Нестор Барановський підкреслює ще один нюанс: на практиці жоден із двох підходів не працює в чистому вигляді, тож успішні проєкти поєднують дисципліну попереднього планування з гнучкістю ітеративного запуску.

Коли галузева специфіка вимагає кастомізації з першого дня

Втім, наші аналітики одразу застерігають: повністю стандартні впровадження без жодної кастомізації на практиці трапляються рідше, ніж здається на старті проєкту.

“Значно легше пригадати замовників, яким доопрацювання були потрібні майже з перших етапів, ніж знайти клієнтів, здатних працювати без принципових змін. Серед клієнтів, які продають чи впроваджують програмне забезпечення, або займаються виробництвом ювелірних виробів, вимога зручного інтерфейсу для користувача з’являється вже на старті проєкту.”

– Євген Моргаєв, комерційний директор CBPM Service

Нестор Барановський доповнює технічним поясненням: команда називає такий підхід тунельними інтерфейсами: користувач виконує спрощені дії, а система під капотом відпрацьовує повний стандартний ланцюжок, не порушуючи типову функціональність. 

→ Оскільки ядро Business Central закрите для прямих змін, усі подібні доопрацювання реалізуються через розширення, а не редагування типових модулів; інколи ж управлінський процес замовника настільки не вкладається у стандартну логіку системи, що доводиться будувати окрему надбудову збоку. Глибина кастомізації відображає радше галузеву специфіку та вимоги конкретного клієнта, ніж технічні можливості самої системи. Один із таких прикладів наша команда докладно описала в кейсі впровадження для ювелірного виробництва.

Офіційна позиція Microsoft: де стандарт, а де кастомізація

Рекомендація команди спирається на офіційну позицію вендора щодо співвідношення стандарту й кастому.

“Офіційна рекомендація Microsoft для продуктів Dynamics звучить так: використовувати стандарт там, де це можливо, і адаптувати там, де це реально виправдано. Якщо кастомізація виправдана, відмовлятися від неї не варто: це стримуватиме розвиток компанії, коли процеси всередині залишаються неавтоматизованими.”

– Нестор Барановський, архітектор ERP-рішень CBPM Service

Однозначної відповіді “завжди відмовляти” чи “завжди погоджуватися” не існує: кожне рішення про кастомізацію команда приймає окремо, зважаючи на реальну цінність, яку вона додає бізнесу замовника.

Як утримати баланс між стандартом і кастомізацією ERP-системи на практиці

Команда CBPM Service зводить кожен із розглянутих сценаріїв до формули збалансованого ERP-впровадження.

“Тут важливе розумне балансування всіх цих факторів на кожному етапі: інвестиція часу в Discovery, щоб точно визначити скоуп; рух за спринтами, щоб тримати руку на пульсі; дотримання проєктних процедур. Ідеться про розумний баланс між типовою функціональністю та кастомізацією.”

– Євген Моргаєв, комерційний директор CBPM Service

Впровадити такий баланс на практиці допомагає лише досвід, напрацьований на реальних проєктах: команда CBPM Service спирається на власну методологію впровадження, вибудовану за 25 років і понад 200 завершених проєктів у 12 галузях.

Плануєте ERP-впровадження чи оптимізацію наявної системи?

Якщо ваш проєкт наближається до етапу, де баланс типової функціональності й кастомізації стає критичним питанням, консультанти CBPM Service готові оцінити реальний обсяг доопрацювань ще до старту розробки і допомогти утримати проєкт у межах бюджету. Зв’яжіться з нами для консультації.