На столе лежат два предложения. В одном — доступ к готовому сервису за ежемесячную плату. В другом — разработка собственной системы с заметным первоначальным бюджетом. Первое кажется безопасным: можно быстро начать. Второе обещает точное соответствие процессу. Затем выясняется, что готовому сервису нужны платные интеграции, а собственной системе — постоянное сопровождение. Сравнение цен с первых страниц больше не помогает.

Выбирать стоит не между подпиской и программным кодом. Компания приобретает способность выполнять конкретную работу: принимать заказы, рассчитывать стоимость, планировать загрузку, выпускать документы. Сначала нужно описать эту работу и допустимые ограничения, затем сравнить способы её организации на одинаковом горизонте. Иначе дешёвый вариант окажется неполным, а дорогой будет обоснован возможностями, которыми никто не воспользуется.

Найдите границу между особенностью бизнеса и привычкой

Утверждение «у нас всё устроено иначе» полезно перевести в список проверяемых отличий. У каждого должно быть объяснение: какую ценность оно создаёт, почему нельзя упростить правило и что произойдёт, если следовать стандартному процессу продукта.

Например, индивидуальный расчёт комплектации оборудования может определять срок подготовки предложения и точность себестоимости. Это серьёзное основание сохранять собственную логику. А привычный порядок колонок в отчёте редко оправдывает разработку отдельной системы. Между этими крайностями находятся особенности, которые проще изменить организационно: убрать лишнее согласование, унифицировать справочник, договориться о едином статусе заказа.

Проведите обсуждение с людьми, которые выполняют работу, и с руководителем, отвечающим за результат. ИТ поможет понять ограничения, но не должно самостоятельно решать, насколько бизнесу необходимо исключение. Владелец процесса должен объяснить последствия: задержка расчёта, риск неверной комплектации, лишняя ручная проверка, невозможность обслужить нужный тип заказа.

Распределите требования по смыслу:

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

Сравнивать нужно законченные варианты работы

Готовый сервис подходит, когда его модель близка к вашему процессу, ограничения понятны, а типовые операции не дают компании самостоятельного конкурентного преимущества. Вы получаете работающую основу и принимаете порядок развития продукта, который определяет поставщик. Это разумный обмен, если изменения внутри вашей компании укладываются в доступные настройки.

Заказная разработка имеет смысл, когда существенная часть результата зависит от особой логики, которую трудно выразить настройками, либо от взаимодействия нескольких систем, оборудования и ролей. Но возможность изменить код сама по себе ничего не гарантирует. Понадобятся человек, принимающий решения по продукту, бюджет на развитие и команда, способная сопровождать решение после запуска.

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

Не объявляйте сочетание систем автоматически более простым. Если сотрудник ежедневно переносит сведения между ними, экономия на разработке может оплачиваться его временем. Если одна и та же сущность редактируется в нескольких местах, заранее определите источник правильного значения. При существенном объёме обмена полезно отдельно разобрать, как устроить надёжные интеграции.

Практический ориентир из руководства британской Government Digital Service — учитывать полную стоимость владения, возможность последующих изменений и контроль над данными. Это полезные критерии выбора, хотя само руководство адресовано государственным цифровым сервисам Великобритании, а не российским коммерческим компаниям. Руководство GOV.UK по выбору технологий.

Готовый продукт с глубокими изменениями его внутренней логики заслуживает отдельной оценки. Узнайте, кто проверяет совместимость доработок с новыми версиями и сколько стоит перенос изменений при обновлении. Если обновления приходится откладывать, компания фактически начинает сопровождать собственную разновидность продукта. Тогда низкая цена первоначальной лицензии мало говорит о последующих расходах.

Обратная ошибка — заказывать с нуля то, что не связано с особенностью бизнеса. Обсудите с разработчиком использование подходящих готовых компонентов для вспомогательных задач. Это не отменяет проверки их ограничений и условий использования, но помогает сосредоточить бюджет на логике, ради которой создаётся система.

Стоимость владения начинается раньше первого входа

Для каждого варианта составьте единый перечень затрат. Не нужно добиваться точности до рубля там, где ещё нет обследования. Лучше честно указать диапазон и причину неопределённости, чем получить аккуратную сумму из непроверенных допущений.

До запуска учитываются обследование процесса, настройка или разработка, очистка и перенос данных, интеграции, обучение, подготовка инструкций и участие сотрудников в проверке. Время руководителя подразделения тоже ограниченный ресурс: если его участие необходимо каждую неделю, это нужно отразить в плане и расчёте.

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

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

При завершении использования потребуются выгрузка и проверка данных, перенос документов, отключение обменов, обучение работе в новой системе и некоторое время параллельной работы. Эти расходы легко не заметить, потому что они находятся за пределами первоначального проекта. Однако именно сложность перехода определяет, насколько свободно компания сможет сменить поставщика.

Для подписок проверьте все единицы тарификации. Помимо пользователей, плата может зависеть от объёма хранения, операций или обращений к API. FinOps Foundation отдельно рассматривает такие дополнительные измерители и условия изменения лицензий; поэтому оценивать будущий счёт только по числу рабочих мест недостаточно. FinOps Framework: Licensing & SaaS.

Следите и за двойным учётом. Если резервное копирование включено в услугу сопровождения, не добавляйте ту же работу второй строкой. Если внутренний администратор уже учтён в трудозатратах подразделения, покажите, какую часть времени занимает новая система. Для каждой строки полезно указать плательщика, исполнителя, периодичность и документ, подтверждающий состав работ. Так сравнение останется проверяемым после уточнения предложений.

Расчёт, который можно пересчитать

Возьмём полностью условный пример для одинакового объёма функций и 36 месяцев эксплуатации после запуска. Все суммы ниже придуманы для демонстрации метода, выражены в одной ценовой и налоговой базе и не являются тарифами ExtentLab или рыночной оценкой. Рост цен пока не учитываем.

Для готового решения примем следующие затраты: запуск, настройка, перенос данных и первоначальные интеграции — 600 тысяч рублей; подписка — 80 тысяч в месяц; сопровождение настроек и обменов — 20 тысяч в месяц; труд внутреннего администратора — 15 тысяч в месяц. На согласованный перечень последующих изменений заложим 300 тысяч, на завершение использования — 150 тысяч.

Получится: 600 000 + 36 × (80 000 + 20 000 + 15 000) + 300 000 + 150 000 = 5 190 000 рублей.

Для собственной системы условно примем 3 миллиона рублей на обследование, разработку, первоначальные интеграции, перенос данных и запуск. Инфраструктура стоит 20 тысяч в месяц, техническое сопровождение — 45 тысяч, труд внутреннего администратора — те же 15 тысяч. Ожидаемые изменения оцениваем в 600 тысяч, завершение использования — в 150 тысяч.

Получится: 3 000 000 + 36 × (20 000 + 45 000 + 15 000) + 600 000 + 150 000 = 6 630 000 рублей. При этих допущениях готовый вариант дешевле на 1 440 000 рублей за выбранный период. Аргумент «собственная система избавит от подписки» этого сравнения не выдерживает: расходы просто имеют другой состав.

Но решение ещё не принято. В расчёте одинаковый полезный результат и подтверждённая достаточность сопровождения. Если готовый продукт оставляет обязательную ручную операцию, её стоимость нужно добавить. Если собственную систему невозможно поддерживать за указанную сумму, её бюджет нужно исправить. Нельзя подгонять предположения под предпочтительный ответ.

Проверьте, от каких предположений зависит победитель

В том же условном примере увеличение ежемесячной подписки на 50 тысяч на все 36 месяцев добавит 1,8 миллиона рублей. Стоимость готового варианта станет 6,99 миллиона, что на 360 тысяч больше рассчитанной стоимости собственного. Это верно только если расходы собственной системы при соответствующей нагрузке останутся прежними. Такое допущение нужно проверить, а не принимать автоматически.

Посчитайте несколько сценариев: текущую нагрузку, ожидаемый рост и неблагоприятный вариант. Меняйте число пользователей, объём данных, количество интеграций, частоту доработок и стоимость сопровождения. Для каждой чувствительной переменной обозначьте источник оценки и человека, который её подтвердит.

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

Время запуска тоже входит в решение

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

Для каждого варианта обозначьте зависимости: доступность специалистов заказчика, качество справочников, готовность внешнего API, необходимость нового оборудования. Если без решения владельца процесса работа остановится, это должно быть видно до заключения договора, а не объяснять задержку задним числом.

Отдельно оцените период параллельной работы. Сотрудникам придётся поддерживать старый порядок и осваивать новый; отчёты могут временно собираться дважды. Установите условия переключения и ответственного за решение. Бессрочная параллельная эксплуатация превращает переходные расходы в постоянные.

Потери от задержки оценивайте осторожно. Их основанием может быть измеренный объём повторного ввода или подтверждённая невозможность принять дополнительный заказ. Ожидаемая выручка не равна прибыли, а предполагаемый спрос не равен заключённым сделкам. Лучше показать диапазон эффекта и его основания, чем включить в окупаемость весь желаемый рост.

Демонстрация должна пережить неудобный заказ

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

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

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

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

Независимость определяется возможностью продолжить работу

Наличие исходного кода не делает компанию автоматически независимой. Если инструкции отсутствуют, сборку умеет запускать один специалист, а доступы находятся у подрядчика, смена команды будет трудной. Проверьте состав передаваемых материалов: код, описание данных, инструкции развёртывания, настройки окружения и порядок восстановления.

У готового сервиса проверьте выгрузку на небольшом примере до масштабного внедрения. В выгрузке должны сохраняться нужные связи, документы и справочники. Уточните сроки, стоимость и ограничения экспорта. Фраза «данные можно скачать» мало полезна, если потом невозможно связать заказ с позициями и историей обработки.

Сопровождение также требует предметного разговора. Кто принимает сообщения о сбоях, определяет приоритет, обновляет зависимости и проверяет восстановление? Как заказчик узнаёт о проблеме? NIST описывает практики безопасной разработки как часть жизненного цикла и предлагает общий язык для разговора покупателей с поставщиками. Этот подход полезен для проверки обязанностей сторон; сам по себе он не подтверждает качество конкретного продукта. NIST SP 800-218.

Оформите решение так, чтобы его можно было пересмотреть

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

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

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

Все материалы →