Как ИИ-консультанты оценивают замену SaaS собственным решением

Любой консультант, стоящий своих денег, оценивает замену стороннего SaaS собственной разработкой одинаково: разделяет каждый инструмент на части, которые вы видите, и части, которые должны работать безупречно каждый раз. SaaS (программное обеспечение, за которое вы платите помесячно) — это в основном экраны, рабочие процессы и отчеты, опирающиеся на более компактное ядро учета данных. Благодаря ИИ воссоздание первой половины стало дешевым. И именно на второй половине проекты замены терпят неудачу, поэтому хорошая оценка объема работ нужна для того, чтобы понять, какая часть ваших подписных расходов действительно приходится на нее.

Вот как шаг за шагом формируется оценка объема работ по замене SaaS собственной разработкой и один вопрос, который определяет почти всё. (Названия поставщиков и данные опросов приведены на момент публикации; относитесь к деталям как к снимку на текущий момент.)

Что на самом деле входит в оценку объема работ по замене SaaS?

Реестр задач, а не список функций. Консультант переписывает каждую задачу, которую выполняет инструмент, указывает, кто с ней работает и что происходит при ошибке в результатах. Цепочки согласований, дашборды и формы попадают в одну колонку. Движение денег, учет остатков, налоги и записи о сотрудниках — в другую. Результатом становится эта карта, уровень риска для каждой задачи и список всех систем, с которыми инструмент незаметно связан.

Вопрос об уровне риска определяет всё: если этот результат окажется неверным, как быстро вы об этом узнаете и во сколько это обойдется? Устаревший дашборд заметен с первого взгляда и ничего не стоит. Ошибка в итоговой сумме выплат обнаружится при подаче налоговой отчетности и обойдется в реальные деньги.

Зачем разделять продукт на два уровня?

Потому что ИИ кардинально снизил стоимость одного уровня и никак не повлиял на другой. Интерфейсный уровень (формы, дашборды, внутренние инструменты, процессы согласования) теперь воссоздается быстро; современные модели создают работающие веб-приложения за считанные часы — именно это мы выяснили, когда проверяли, может ли GPT-5.6 создать работающую POS. Инфраструктурный уровень устроен иначе: обработка платежей, соответствие стандарту PCI (правила безопасности карт, соблюдаемые процессингами), учет остатков при параллельном доступе (две кассы продают последнюю единицу товара) и сведение отчетов (итоговые суммы, совпадающие с банковским депозитом). Этот уровень сложен не потому, что код длинный. Он сложен потому, что вариант «почти правильно» здесь ничего не стоит, а подтверждение корректности обойдется дороже, чем генерация самого кода.

Более совершенные модели тоже не снимают это ограничение. Узким местом остается верификация и ответственность, а не генерация кода, поэтому честная оценка стоимости рассчитывает именно верификацию. Генерация — это демоверсия. Верификация — это итоговый счет.

Что на самом деле доказал опыт замены SaaS в Klarna?

Самая громкая история под заголовком «мы заменили наш SaaS на ИИ» на самом деле является уроком по оценке объема работ. В конце 2024 года генеральный директор Klarna объявил, что компания отказывается от Salesforce и Workday в рамках масштабной интеграции ИИ, и заголовки СМИ запестрели сообщениями о том, что ИИ полностью вытесняет SaaS. Однако последующие материалы прояснили картину: Klarna перевела HR к другому поставщику, а потребности в CRM закрыла комбинацией альтернативных инструментов и внутренней связующей логики с наложением ИИ поверх них¹. Лицензированный банк с одной из самых агрессивных ИИ-программ в сфере финтеха все же сохранил свои авторитетные системы учета (главную копию бизнес-данных) на проверенных платформах, перестроив только периферию.

И это было не проявлением слабости. Это была правильная оценка объема работ в действии.

Какие цифры оправдывают проект по замене?

Сначала устранение потерь, затем разработка. По данным отчета Zylo «2026 SaaS Management Index», основанного на анализе более 40 миллионов управляемых лицензий, медианные расходы на SaaS составляют $9455 на сотрудника в год, в среднем 36% лицензий не используются, а бизнес-подразделения контролируют 81% расходов на SaaS, тогда как IT напрямую управляет лишь 15%². Прежде чем что-либо предлагать, консультант сопоставляет ваш стек с этими цифрами: отменить неиспользуемые лицензии, объединить пересекающиеся инструменты и только потом сформировать список кандидатов на переработку.

Инструменты, попадающие в этот список, имеют схожий профиль: высокие регулярные расходы, задачи, состоящие в основном из интерфейсной части, и невысокий ущерб в случае сбоя. Проект получает одобрение, когда статья расходов на подписку растет быстрее, чем затраты на разработку и обслуживание, а каждую критически важную задачу можно оставить на инфраструктуре, которую уже поддерживает кто-то другой.

Какое место в этой оценке занимает POS?

На самом критическом конце спектра. POS-система кажется интерфейсным проектом — сеткой кнопок и корзиной, поэтому владельцы считают, что её объем работ оценивается как обычный дашборд. Но соотношение здесь обратное. Экран оформления заказа — это лишь небольшая часть продукта; всё остальное — платежи, сертифицированное оборудование для работы с картами, учет остатков, устойчивый к одновременным продажам на двух кассах, налоговые правила и итоговые отчеты за день. Когда POS ошибается, она ошибается в деньгах каждый день.

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

Так как же следует оценивать замену SaaS собственным решением?

Разделите каждый инструмент на два уровня, оцените каждую задачу по стоимости невыявленной ошибки и рассчитывайте цену верификации, а не кода. Свободно перерабатывайте интерфейсы и процессы; оставляйте авторитетные системы учета на инфраструктуре, корректность которой обеспечивает кто-то другой. Прежде чем перерабатывать любой инструмент своими силами, спросите себя: если его результат окажется неверным, как быстро я об этом узнаю? Если ответ «не сразу», эта задача должна остаться на проверенных рельсах.

И если торговая часть вашего стека — это то, что вы хотите перестроить, начните с честного взгляда на то, что современные модели могут и не могут создать самостоятельно: Claude, ChatGPT и Gemini при реальной сборке POS или два no-code пути в статье как использовать Gemini 3.6 Flash для создания пользовательской POS.