Як ШІ-консультанти оцінюють обсяг робіт із заміни SaaS власною розробкою

Будь-який консультант, вартий своєї денної ставки, оцінює обсяг робіт із заміни SaaS власною розробкою однаково: ділить кожен інструмент на частини, які ви бачите, і частини, які мають бути бездоганними щоразу. SaaS (програмне забезпечення, яке ви орендуєте щомісяця) складається здебільшого з екранів, робочих процесів і звітів, що спираються на менше ядро ведення обліку. Завдяки ШІ відбудувати першу половину стало дешево. На другій половині проекти із заміни гинуть, а якісна оцінка обсягу робіт потрібна саме для того, щоб виміряти, яка частина вашого рахунку за підписку насправді припадає на неї.

Ось як крок за кроком формується оцінка обсягу робіт із заміни SaaS власною розробкою, і єдине питання, яке вирішує більшість із цього. (Назви постачальників та дані опитувань нижче є точними на момент публікації; сприймайте деталі як зріз на певний момент часу.)

Що насправді містить оцінка заміни SaaS?

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

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

Навіщо ділити продукт на два рівні?

Тому що ШІ обвалив вартість одного рівня й залишив недоторканим інший. Рівень інтерфейсу (форми, дашборди, внутрішні інструменти, процеси узгодження) тепер можна швидко відбудувати заново; сучасні моделі створюють працюючі вебдодатки за лічені години, що саме відповідає нашим висновкам, коли ми досліджували, чи може GPT-5.6 створити працюючу POS-систему. Рівень інфраструктури влаштований інакше: обробка платежів, відповідність PCI (правила безпеки карток, які забезпечують еквайєри), облік товарних залишків за умов одночасного доступу (дві каси продають останній екземпляр товару) та звіти, які звіряються (підсумки, що збігаються з вашим банківським депозитом). Цей рівень складний не через довжину коду. Він складний тому, що «майже правильно» там нічого не варте, а доведення правильності коштує дорожче, ніж генерація коду.

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

Що насправді довів досвід Klarna із заміною SaaS?

Найгучніша історія про те, як «ми замінили наш SaaS на ШІ», насправді є уроком з оцінки обсягу робіт. Наприкінці 2024 року генеральний директор Klarna оголосив, що компанія відмовляється від Salesforce та Workday в межах реорганізації на основі ШІ, і в заголовках повідомили, що ШІ повністю замінює SaaS. Подальші звіти виявили дещо вужчий контекст: Klarna перевела HR до іншого постачальника та закрила потреби в CRM комбінацією альтернативних інструментів і внутрішніх зв'язуючих рішень із накладеним поверх ШІ¹. Ліцензований банк із однією з найагресивніших програм впровадження ШІ у фінтеху все одно зберіг свої системи обліку (офіційну першоджерельну копію даних вашого бізнесу) на перевірених платформах і відбудував лише периферійні елементи.

Це не було втратою рішучості. Це була належна робота з оцінки обсягу.

Які цифри виправдовують проект із заміни?

Спочатку усуньте марнотратство, потім будуйте. Звіт Zylo 2026 SaaS Management Index, складений на основі понад 40 мільйонів ліцензій під управлінням, оцінює медіанні витрати на SaaS у $9,455 на працівника на рік, показує, що в середньому 36% ліцензій не використовуються, а бізнес-підрозділи контролюють 81% витрат на SaaS, тоді як IT-відділ напряму керує лише 15%². Консультант порівнює ваш стек із цими цифрами, перш ніж щось пропонувати: скасувати невикористовувані місця, об'єднати перекриваючі інструменти й лише після цього сформувати список кандидатів на перебудову.

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

Яке місце посідає POS у цій оцінці?

На найсуворішому кінці спектра. Точка продажу (POS) виглядає як інтерфейсний проект, сітка кнопок і кошик, тому власники вважають, що її оцінюють так само, як і дашборд. Але співвідношення зворотне. Екран оформлення замовлення — це лише мала частка продукту; решта — це платежі, сертифіковане обладнання для прийому карток, облік залишків, що витримує одночасний продаж з двох кас, податкові правила та підсумкові звіти за день, які збігаються. Коли POS помиляється, вона помиляється в грошах щодня.

Тому консультанти оцінюють перебудову POS так само, як Klarna оцінювала свою головну книгу: власний інтерфейс, перевірена інфраструктура. Раніше для такого поділу потрібна була ціла команда розробників. Тепер це категорія продуктів: Final Build перетворює текстовий запит звичайною мовою на процес оформлення замовлення, який ви можете переглянути та розгорнути, і ви можете підключити власний ШІ через MCP, щоб будувати поверх тієї ж торговельної інфраструктури. Платежі, інвентаризація, звітність та обладнання залишаються на вже верифікованому рівні.

Тож як слід оцінювати заміну SaaS власною розробкою?

Поділіть кожен інструмент на два рівні, оцініть кожне завдання за вартістю непоміченої помилки у результаті та розраховуйте ціну верифікації, а не коду. Вільно відбудовуйте інтерфейси та робочі процеси; залишайте системи обліку на інфраструктурі, точність якої підтримує хтось інший. Перш ніж переписувати будь-який інструмент власними силами, запитайте себе: якби його результат виявився помилковим, як швидко ви б про це дізналися? Якщо відповідь «не швидко», це завдання має залишатися на перевірених рейках.

І якщо торговельна частина вашого стеку — це саме те, що ви хочете перебудувати, почніть із чесного аналізу того, що сучасні моделі можуть і чого не можуть побудувати самостійно: Claude проти ChatGPT проти Gemini у реальній розробці POS або два шляхи без коду у статті як використовувати Gemini 3.6 Flash для створення кастомної POS.