Купить, интегрировать или разработать? Как выбрать внутренний инструмент

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

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

Какой вариант подходит под реальную задачу?

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

Вопрос	Купить	Интегрировать	Разработать
Где выполняется работа?	В существующем продукте с настройкой	В существующих инструментах с согласованным обменом данными	В новом инструменте для недостающего процесса
Что я должен проверить?	Нужные роли, шаги согласования и пригодные выгрузки	Доступ к каждой системе, владение полями и восстановление	Правила, права, приёмочные тесты и эксплуатацию
Что определяет стоимость настройки?	Конфигурация, миграция и обучение	Сопоставление, реализация, обработка сбоев и тесты	Проектирование, разработка, миграция, тесты и передача
Что определяет регулярные расходы?	Лицензии, использование и администрирование	Существующие лицензии плюс эксплуатация интеграции	Хостинг, зависимости, сопровождение и администрирование
Что нужно учесть при замене?	Экспорт, конфигурацию замены и переобучение	Замену соединения и проверку обеих сторон	Перенос данных и кода или замену инструмента

Руководство GOV.UK по технологиям рекомендует командам разобраться в существующих системах и данных, сохранять технологии гибкими по мере того, как меняется понимание потребностей пользователей, и минимизировать совокупную стоимость владения. Я использую это как ориентир для решения. Руководство написано для государственных сервисов.

Если проблема в передаче, ближе всего ситуация «Заменить Zapier прямыми интеграциями по API». Если требование в том, чтобы вы контролировали хостинг и эксплуатацию, прочитайте ситуацию «Свой стек в ваших руках». Это разные причины заказывать работу.

Что входит в бюджет на 12–24 месяца?

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

Моя рабочая модель:

Совокупная стоимость владения (TCO) за N месяцев = начальная работа + N × ежемесячные эксплуатационные расходы + резерв на выход.

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

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

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

Гипотетический сценарий 1: стандартная очередь согласования

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

Гипотетические входные данные:

• Купить: $600 начальной работы; $150/месяц на лицензии и $50/месяц на администрирование; резерв на выход $400.
• Интегрировать: $2000 начальной работы; $100/месяц на существующие инструменты и $150/месяц на сопровождение интеграции и администрирование; резерв на выход $800.
• Разработать: $8000 начальной работы; $50/месяц на хостинг и $300/месяц на сопровождение и администрирование; резерв на выход $1000.

Вариант	TCO: 12 месяцев	TCO: 24 месяца
Купить	$3400	$5800
Интегрировать	$5800	$8800
Разработать	$13 200	$17 400

Например, покупка на 24 месяца: $600 + 24 × $200 + $400 = $5800. Результат зависит от того, проходит ли продукт проверки процесса. Если нужное правило согласования недоступно, я пересмотрел бы короткий список, а не подгонял процесс под этот продукт.

Гипотетический сценарий 2: два инструмента, один сбой обмена данными

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

Гипотетические входные данные:

• Купить: $3000 начальной работы на переход на другой комплект продуктов; $500/месяц на лицензии и $100/месяц на администрирование; резерв на выход $1500.
• Интегрировать: $3500 начальной работы; $150/месяц на существующие лицензии и $150/месяц на сопровождение и разбор исключений; резерв на выход $800.
• Разработать: $10 000 начальной работы; $150/месяц на сохраняемые лицензии, $50/месяц на хостинг и $350/месяц на сопровождение и администрирование; резерв на выход $1500.

Вариант	TCO: 12 месяцев	TCO: 24 месяца
Купить	$11 700	$18 900
Интегрировать	$7900	$11 500
Разработать	$18 100	$24 700

Интеграция на 24 месяца: $3500 + 24 × $300 + $800 = $11 500. Перед выбором способа соединения я бы написал бриф на API-интеграцию: поля, направление, периодичность, дубликаты и восстановление.

Если эти заказы ещё и попадают в аналитику, я согласую стабильный ключ сопоставления. Термин transaction ID объясняет идентификатор покупки в GA4, который, по словам Google, должен быть уникальным для каждого заказа. Сверка заказов показывает, как я сверяю эти покупки с исходными заказами. Интеграции по фулфилменту всё равно нужны собственное согласованное сопоставление полей и приёмочные тесты.

Гипотетический сценарий 3: правило, которое имеющиеся инструменты обеспечить не могут

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

В гипотетические входные данные включена ручная обработка, она не считается бесплатной:

• Купить: $1500 начальной работы; $250/месяц на лицензии и $1250/месяц на администрирование и ручные проверки правил; резерв на выход $1000.
• Интегрировать: $4000 начальной работы; $200/месяц на лицензии, $200/месяц на сопровождение интеграции и $600/месяц на ручные проверки правил; резерв на выход $1500.
• Разработать: $12 000 начальной работы; $100/месяц на хостинг и $350/месяц на сопровождение и администрирование; резерв на выход $2000.

Вариант	TCO: 12 месяцев	TCO: 24 месяца
Купить, с ручными проверками правил	$20 500	$38 500
Интегрировать, с ручными проверками правил	$17 500	$29 500
Разработать	$19 400	$24 800

Разработка на 24 месяца: $12 000 + 24 × $450 + $2000 = $24 800. У интеграции итог за 12 месяцев ниже, но она не проходит заявленное требование. Я бы либо финансировал разработку, либо пересмотрел это требование, либо пока оставил задачу ручной. Эти цифры не доказывают, что ПО под заказ становится дешевле при каком-то определённом масштабе.

Кому принадлежат данные и сколько стоит выход?

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

Руководство GOV.UK по привязке к облачному поставщику разделяет коммерческие ограничения и техническую зависимость. Оно охватывает доступ к данным, переносимые форматы, а также стоимость и время выхода из хостинговых договорённостей. При этом руководство отмечает, что определённая зависимость может быть полезна. Я так же планирую возможную замену внутреннего инструмента; полную независимость я не считаю требованием для любого небольшого инструмента.

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

Как я проверяю это на реальных внедрениях

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

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

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

Типичные ошибки

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

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

Ограничения и альтернативы

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

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

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