Я часто спілкуюся з власниками мереж. У звичайних розмовах, коли ніхто не готує правильних відповідей для презентації, рано чи пізно хтось каже: «Так, ERP нам потрібна. Але зараз не час».
І щоразу, коли копаєш глибше, доходиш до пам’яті про попереднє впровадження. У когось це була 1С, яку роками доробляли. Спочатку з’явилися обхідні рішення, потім — люди, які єдині знали, як усе влаштовано. Зрештою компанія звикла жити з правилом «не чіпайте, бо зламаємо». На цьому тлі пропозиція ще раз упровадити ERP звучить майже як пропозиція вдруге купити той самий лотерейний квиток.
Тому пауза власника й фінансового директора цілком логічна. Вони хочуть бачити, за що платять, що працюватиме після першого етапу і як мережа переживе перехід. Почнімо саме із цих питань.
Як порівняти кошториси ERP для однієї мережі
Ціна ліцензії, кошторис запуску та витрати на кілька років експлуатації відповідають на різні запитання. У першому рядку двох пропозицій можуть стояти схожі суми, хоча одна охоплює бухгалтерський контур, а інша — ще й каси, WMS, контакт-центр і перенесення історії. Різницю видно, якщо всі команди оцінюють одне технічне завдання.
Що уточнити у пропозиціях для однакового обсягу робіт| Варіант | Питання до кошторису |
|---|
| BAS ERP або розвиток наявного контуру 1С | Що можна повторно використати, що треба переробити, хто підтримуватиме доробки після оновлень і як забрати дані при наступній міграції? |
| Odoo | Який план і тип розміщення потрібні для зовнішнього API? Окремо оцініть локалізацію обліку, каси, перенос історії й підтримку нестандартних модулів. |
| SAP ERP | Яку редакцію, модель розгортання та інтеграційний контур оцінюють? Попросіть розділити роботи інтегратора, міграцію, навчання, підтримку й регулярні платежі. |
| K2 ERP | Які модулі можна перевірити на даних мережі, що потребує налаштування чи розробки, скільки коштують інфраструктура та супровід після запуску? |
Для мережі, яка виросла на 1С чи BAS, міграція — це ще й рішення про залежності. Які з них зникнуть, які залишаться, а які з’являться? Попросіть показати доступ до даних, формат вивантаження, склад компонентів і можливість підтримки іншою командою. Важливо оцінити саме ту конфігурацію, яку використовуватимуть магазини.
Що входило до моделі запуску K2 ERP
K2 ERP — інформаційна система для роботи з бізнес-процесами мережі. K2 Platform — платформа розробки, на якій можна розширювати рішення. Для CFO різниця практична: за першу відповідають власники процесів і даних, а бюджет розробки варто прив’язати до конкретних змін та їх приймання.
У березні 2026 року я розглядав умовну мережу на 300–400 магазинів і 1 500–2 500 працівників. У неї кілька юридичних осіб, великий склад, власна логістика, онлайн-продажі, контакт-центр і виробничі операції. Нижче — цифри цієї моделі для уявної компанії. Вони показують, як розкласти бюджет за напрямами. Для перерахунку в гривні закладено 50 грн за євро.
Разові витрати за моделлю
Запуск K2 ERP у сценарії торговельної мережі| Стаття | Євро | Гривні за умовним курсом | Що оцінюємо |
|---|
| ERP-ядро | 5 000 | 250 000 | Управлінський, бухгалтерський і податковий контури. |
| Реплікатор і перенесення даних | 4 500 | 225 000 | Довідники, залишки, погоджений обсяг історії та звірка. |
| Виробничий блок | 5 000 | 250 000 | Планування, матеріали, операції та собівартість. |
| WMS для великого складу | 15 000 | 750 000 | Рух товару, адресне зберігання, ТЗД і штрихкоди. |
| CRM і контакт-центр | 2 600 | 130 000 | Продажі, звернення та історія комунікацій. |
| Логістика та GPS | 3 000 | 150 000 | Маршрути, транспорт і витрати на доставку. |
| Документообіг та e-commerce | 10 000 | 500 000 | Погодження, підписання, каталог і онлайн-замовлення. |
| Інтеграції | 8 800 | 440 000 | Обмін документами, платежі та канали зв’язку в погодженому обсязі. |
| Інші модулі та індивідуальні доробки | 13 500 | 675 000 | Кадри, зарплата, HelpDesk, мобільні застосунки та API. |
| Разом | 67 400 | 3 370 000 | |
|---|
Щомісячні витрати за моделлю
Інфраструктура й команда розвитку| Стаття | Євро на місяць | Гривні на місяць |
|---|
| Інфраструктура | 980 | 49 000 |
| Команда клієнта або спільного розвитку, три розробники | 15 750 | 787 500 |
| Разом | 16 730 | 836 500 |
|---|
У власному кошторисі окремо перевірте навчання, касове й складське обладнання, вартість зовнішніх сервісів, резервування, підтримку в неробочий час та утримання двох систем на перехідному етапі. Оцінку навантаження варто будувати на піковій кількості чеків, складських операцій та обмінів, а не лише на кількості магазинів.
Чому в моделі троє розробників
На цьому місці фінансовий директор зазвичай зупиняється: «Чому троє? У нас цим займаються п’ятнадцятеро». Різниця в тому, яку роботу доводиться виконувати з нуля. Коли кожна мережа пише власні модулі, виправляє ті самі помилки й окремо підтримує ті самі обміни, ринок кілька разів платить за одну й ту саму логіку.
Модель припускає, що частину типових компонентів уже підтримують спільно. Одна мережа допомагає розвинути модуль, інша фінансує форми або аналітику. Тоді власна команда може витрачати більше часу на те, що справді відрізняє її процеси. Числа три й п’ятнадцять тут описують різні способи організації роботи. Потрібний склад команди залежить від черги доробок, відповідальності за підтримку та того, які компоненти вдасться повторно використати.
Що перевірити на процесах мережі
У демо легко показати окремі вікна. На пілоті краще провести одну операцію через кілька відділів і подивитися, де дані доводиться вводити повторно. Документація модулів K2 ERP допомагає скласти перелік сценаріїв. Конкретні версії модулів, доступні інтеграції й межі відповідальності потрібно звіряти для вашої конфігурації.
1. Фінанси, облік і консолідація
У багатьох компаніях CFO працює археологом: збирає файли, узгоджує цифри і чекає «фінальної фінальної» версії звіту. Запустити управлінський контур можна окремим етапом. Почніть зі звірки руху коштів, доходів і витрат за точками, каналами та юридичними особами. Перевірте, як консолідований показник розкладається до первинного документа і як відокремлюються внутрішньогрупові операції. Для бухгалтерського й податкового контурів погодьте окремі критерії приймання.
2. Обмін із банками та сервісами документів
Випишіть обміни, які сьогодні тримаються на людині, що знає, «де натиснути». Для M.E.Doc, Вчасно, ПТАХ, банків і реєстрів уточніть доступні формати, напрям обміну, версії та відповідальних. На тесті перевірте повторне надсилання, відхилений документ і дубль. Коли один із сервісів недоступний, працівник має бачити, що вже пройшло, а що потребує повтору.
3. CRM, контакт-центр і зв’язок із замовленням
Якщо половина історії клієнта в пошті, а друга — у нотатках менеджера, CRM легко перетворюється на папку на полиці. Проведіть через пілот звернення клієнта з телефону, пошти чи месенджера і перевірте, чи оператор бачить замовлення та попередні домовленості. Окремо уточніть підтримуваного оператора IP-телефонії та канали повідомлень, зокрема SMS/Viber через TurboSMS, якщо вони потрібні.
4. Виробництво й фактична собівартість
Там, де виробництво «приблизно» знає, на чому заробляє, почніть із конкретної партії. Простежте специфікацію, маршрут, видачу матеріалів, проміжні етапи, брак і випуск продукції. Порівняйте нормативну собівартість із фактичною та перевірте, як відхилення потрапляє в управлінський звіт. Це дає власникові розмову про причини, які можна перевірити.
5. Кадри, табелі та зарплата
Проженіть через тест переведення працівника між магазинами, зміну графіка, табель, відпустку або лікарняний і перерахунок після виправлення. Порівняйте результат із контрольним розрахунком за погодженими правилами. Налаштуйте права так, щоб керівник точки бачив потрібний йому графік, а доступ до нарахувань отримували лише уповноважені працівники.
6. Каси, ПРРО й облік у магазині
Перевірте продаж за акцією, повернення, закриття зміни та звірку оплати, чека, залишку й облікового документа. Для обраного ПРРО окремо перевірте поведінку при втраті зв’язку, повторній синхронізації й помилці фіскалізації. Невідповідність має бути видна в операційному контролі до того, як її знайдуть під час закриття місяця.
7. Інтернет-магазин, оплати й повернення
Щоб онлайн-магазин перестав бути «відділом пригод», замовлення потрібно провести від номенклатури, ціни й наявності до видачі, доставки або повернення. Уточніть, де живе каталог і хто керує контентом. Для LiqPay чи WayForPay перевірте доступний спосіб інтеграції, повторні сповіщення та звірку повернень. Якщо потрібен дропшипінг, окремо визначте, хто резервує товар, підтверджує відправку і приймає претензію.
8. WMS, ТЗД і точність залишків
На складі дуже швидко видно різницю між залишком у програмі й товаром у комірці. У K2 WMS задокументовані адресне зберігання, приймання, відбір, відвантаження, інвентаризація й робота зі штрихкодами. Перевірте їх на своїх терміналах збору даних, принтерах та етикетках. Включіть пересортицю, часткове приймання, пошук партії та відвантаження в пікову годину.
9. Логістика, транспорт і вартість маршруту
GPS покаже, де машина. CFO хоче знати також, у що обійшлися маршрут, простій чи збій. Пов’яжіть рейс із доставленими замовленнями, витратами пального, ремонтами та поверненнями. Якщо мережа користується Новою поштою, Укрпоштою або власною кур’єрською службою, перевірте доступні статуси та розбіжності між даними перевізника й обліком.
10. Документообіг, погодження і підписання
Візьміть договір, який зазвичай довго мандрує між поштою й чатами. Покажіть ініціювання, погодження, повернення на виправлення, підписання й пошук остаточної версії. Визначте, які документи потребують підпису, який сервіс його забезпечує і хто бачить історію. Це дає керівникові можливість знайти затримку без ланцюжка дзвінків.
11. HelpDesk, задачі та внутрішній сервіс
У мережі завжди є ще один бізнес — внутрішній. Магазин повідомляє про касу, склад просить налаштувати сканер, офіс чекає на доступ. Перевірте, чи можна призначити відповідального, побачити строк реакції й згрупувати повторні проблеми. Для SLA погодьте робочий час, пріоритети та правила ескалації, інакше показник у звіті мало що скаже про сервіс.
12. Веб, робочі місця й мобільні застосунки
У матеріалах K2 про перехід заявлено доступ для Linux, macOS, Windows, Android та iOS. Для вашого проєкту перевірте конкретну операцію й пристрій: касир на робочій станції, працівник складу з ТЗД, керівник у браузері або на телефоні. Якщо потрібен застосунок під брендом мережі, у кошторисі мають бути окремо розробка, публікація в магазині застосунків і супровід.
13. API, шаблони, звітність і BI
Попросіть фінансового директора обрати один звіт, на який сьогодні довго чекають. Зберіть його за регіонами, магазинами або каналами і звірте зі звичним джерелом. Перевірте друковані форми, експорт, доступ BI до потрібних даних і права на зміну шаблонів. Для API зафіксуйте версію, обмеження, доступні методи та поведінку при повторі операції.
14. Linux, PostgreSQL і вартість експлуатації
Ліцензійна модель — питання і для фінансового директора. Ліцензія PostgreSQL дозволяє використовувати СУБД без плати за саму ліцензію за її умовами. У витратах усе одно залишаються сервери, адміністрування, спостереження за навантаженням, підтримка, резервні копії та відновлення. Порівняйте ці статті для Linux і PostgreSQL та іншого запропонованого стеку на однаковому обсязі роботи.
15. Масштабування магазинів і юридичних осіб
Відкриття нової точки покаже, що з розгортання можна повторити, а що вимагає ручної роботи. Складіть шаблон для довідників, цін, прав, кас, складів та інтеграцій, а потім пройдіть виняток для магазину іншого формату. Навантаження перевіряйте під час акції, одночасного оновлення залишків або іншого піку, який справді трапляється у вашій мережі.
16. Журнал змін і відповідальність
Непомітна зміна довідника або документа може зіпсувати звіт кількох підрозділів. Перевірте, хто, коли і як змінив критичне поле, чи видно старе й нове значення і як довго зберігається історія. Для змін через імпорт, інтеграцію чи безпосередньо в базі даних уточніть покриття журналу окремо. Відповідальні за аудит мають уміти відтворити подію на тестовому прикладі.
З чого почати, якщо «зараз не час»
Я б почав із магазину й складу, на яких видно типові винятки мережі. Визначте власників процесів і дайте їм реальні сценарії: акцію, повернення, розбіжність у партії, прострочене погодження, збій інтеграції. Зафіксуйте, як ці випадки проходять сьогодні, скільки ручної роботи вони потребують і де з’являються розбіжності.
- Погодьте, які довідники, залишки й періоди історії переносяться. Збережіть вихідний зріз і звірте контрольні підсумки після міграції.
- Проведіть обмежений період паралельної роботи. Щодня звіряйте залишки, касу, повернення й оплати та призначайте відповідального за кожну розбіжність.
- До перемикання погодьте прийнятні показники пропускної здатності, закриття зміни, обробки помилок і відновлення з резервної копії. Визначте, за якої розбіжності запуск зупиняється і як команда повертається до попереднього контуру.
- Розділіть бюджет першої черги й масштабування. За підсумками пілота уточніть вартість інтеграцій, навчання, підтримки й тиражування на інші точки.
Іноді фінансовому директору достатньо одного закриття періоду, щоб побачити, де він досі витрачає час на пошук цифр. Власникові один пілот дає предметну розмову про масштабування. Далі рішення можна ухвалювати за тим, що мережа вже перевірила у своїх процесах.
Для обговорення розрахунку K2 ERP — WhatsApp +380679016322.
Березневий розрахунок для торговельної мережі на сайті K2 ERP
