ПЗ на замовлення чи готове рішення? B2B-посібник з вибору

Перше розрізнення: стандарт чи перевага?

Бухгалтерія, пошта, зарплата — стандартні процеси. Тисячі компаній роблять їх однаково. Готові пакети (SAP, QuickBooks, Workday) зрілі, безпечні, дешеві. Писати на замовлення тут зазвичай марнотратство.

Але ваша "конкурентна перевага" — власний алгоритм ціноутворення, інтеграція під клієнта, специфічний операційний потік — стає типовою в момент, коли ви запихаєте її в стандартний інструмент. Ті 20 %, що створюють реальну цінність, падають до 0 %. Тут розробка на замовлення — єдиний шлях: хто користується тими самими інструментами, що й конкурент, отримує той самий результат.

Чотири практичні запитання

Перш ніж обрати, дайте відповідь на ці чотири запитання:

1) Процес — галузевий стандарт чи специфічний для вашої компанії? 2) Чи змінюється модель даних разом із зовнішнім світом (білінг, інтеграції)? Якщо так — готове ПЗ або SaaS з відкритим API підходить. 3) Чи зміниться ваша бізнес-модель навколо цього процесу протягом 24 місяців? Якщо так — стеля конфігурації пакета вас зв'яже. 4) Конкурентна перевага схована всередині процесу? Якщо ви згадуєте його, пояснюючи "чому обирають нас", розробка на замовлення обов'язкова.

Дві або більше "відмінних" відповідей (унікальність, прихована перевага) — на користь замовної розробки. Інакше починайте з пакета та мігруйте, коли доб'єтеся стелі — це найдешевша стратегія.

Гібридний підхід: найпрагматичніший вибір

У житті більшість B2B-рішень — не "все на замовлення" і не "все готове", а розумна комбінація обох. Схема: стандартний шар (бухгалтерія, HR, кістяк CRM, пошта) працює на найкращому пакеті на ринку; диференційний шар (ціновий двигун, клієнтський портал, операційний потік, перетворення даних) будується як ПЗ на замовлення і інтегрується з пакетами через API.

Це дає три речі: (1) безпека постачальника та низький TCO у commodity-шарі, (2) повний контроль і швидкі ітерації в диференціаторі, (3) кожен шар еволюціонує у власному темпі. На практиці це "SaaS + API + тонкий власний прикладний шар". Зі зростанням замовний шар розширюється; пакетні шари лишаються стабільні. У Setviva близько 70 % клієнтів стартують гібридно — ті, хто просить суто замовне, після мапи процесів часто погоджуються також перенести стандарти на пакети.

Як правильно оцінити вартість міграції

Найчастіша помилка B2B-керівників: порівнювати лише вартість ліцензії чи проекту. Справжня ціна — під водою. При переході на пакетне ПЗ додайте: міграцію та очищення даних, навчання, втрату продуктивності під час переходу, розробку інтеграцій, кастомізацію звітності, реінжиніринг процесів. Зазвичай це 3–5× ліцензії. При переході на замовне додайте: дизайн та discovery, розробку, тестування, навчання, підтримку та постійну ітерацію, інфраструктуру (сервери, моніторинг, резервні копії), ризик власності (хто підтримає, якщо команда піде). Зазвичай це 1,5–2× вартості розробки.

Для чесного порівняння випишіть повну вартість володіння (TCO) на 24–36 місяців і зіставте обидва варіанти на одній шкалі. У кожній пропозиції Setviva ми даємо цей рядок-у-рядок TCO одразу — щоб рішення ґрунтувалося на "справді дешевому", а не на "виглядає дешевим". Правильно порахувати вартість міграції може важити більше за сам вибір.

Ризик прив'язки: він працює в обидва боки

Кожен, хто ухвалює рішення, запитує: "скільки це коштує сьогодні", але майже ніхто не запитує: "у кого буде важіль впливу на мене через три роки". У випадку SaaS дорожню карту пише постачальник, а не ви. Контракти продовжуються з підвищенням цін, яке може стати відчутним, щойно інструмент вбудується у ваші щоденні операції; функції знімають з підтримки або переносять у вищий тариф; постачальника можуть купити, а продукт — зняти з підтримки за графіком, який обираєте не ви. Ніщо з цього не гіпотетично — це звичайний життєвий цикл постачальників ПЗ, і чим глибше інструмент вбудований у ваші операції, тим дорожче обходиться відмова від нього, навіть якщо ціна утроїться. Це не привід уникати SaaS — для стандартних процесів це зазвичай усе ще правильний вибір, — але це означає, що порівняння за "щомісячною платою" приховує справжнє питання: скільки важеля впливу ви віддаєте стороні, чиї інтереси не збігаються з вашими?

Замовне програмне забезпечення розвертає проблему важеля впливу всередину. Ризик — це вже не дорожня карта постачальника, а "фактор автобуса" вашої власної команди. Якщо розробники, які створили систему, підуть, а рішення, що стояли за нею, ніхто не задокументував, система тихо перетворюється на чорну скриньку, до якої ніхто не хоче торкатися. Без підтримки залежності старіють, патчі безпеки перестають виходити, і зрештою "замовне" перетворюється саме на те, чого ви намагалися уникнути, — крихку застарілу систему. Прив'язка тут — це не пункт контракту, а сконцентровані знання, але ефект той самий: піти без високої ціни не вийде.

Рішення — з першого дня розглядати вартість виходу як критерій ухвалення рішення, з обох боків. Для SaaS перед підписанням перевірте, які дані можна вигрузити і в якому форматі, чи обмежує контракт зростання ціни, і наскільки болісним буде вихід на практиці. Для замовної розробки наполягайте, щоб право власності на вихідний код, доступ до інфраструктури та актуальна документація були прописаними обов'язками за контрактом, а не послугою — і обирайте партнера, який пише код для того, хто успадкує систему далі, а не лише для демонстрації. Який би шлях ви не обрали, ставте питання про вихід раніше за питання про покупку. Можливість піти без утрат коштує більше, ніж варіант, що сьогодні здається найдешевшим.