Как подойти к задаче без лишней магии
Ошибка начинается с вопроса «строить или купить». Я бы сначала спросил, является ли эта функция конкурентным преимуществом. Для типовой расшифровки можно купить. Для уникальных данных и правил — возможно, нужен собственный workflow.
Ошибка, которую я бы сразу убрал: Строить свою систему ради контроля типовой задачи.
Что подготовить и какой результат ждать
- На выходе: Вы сравните варианты по полной стоимости владения и проверите их на одном пилоте.
- Запишите пользователей, процесс, интеграции, данные, срок, обязательные ограничения и путь выхода из решения.
- Сохраните исходные данные и права доступа отдельно от результата, чтобы можно было проверить, что сделал решение build или buy.
- Для двух вариантов измерьте время до результата, точность, стоимость операции, экспорт данных и замену поставщика.
Сравните купить, построить и гибрид на одном пилоте
- Соберите требования до выбора
В одной таблице зафиксируйте задачу, пользователей, интеграции, классы данных, SLA, объём и обязательные запреты.
Проверьте: В требованиях нет слова «современный» без измеримого смысла.
Если не сработало: Замените пожелание на критерий: время, точность, доступ, экспорт.
- Оцените варианты по весам
Заполните матрицу 1–5: соответствие 25%, безопасность 20%, скорость 20%, стоимость за 3 года 20%, контроль/переносимость 15%. Итог = сумма(оценка × вес) / 5.
Проверьте: Весы отражают риск бизнеса, а не личный вкус разработчика.
Если не сработало: Обсудите веса с владельцем процесса и безопасностью.
- Посчитайте TCO
TCO покупки = лицензии + внедрение + интеграции + обучение + выход. TCO разработки = аналитика + разработка + тестирование + инфраструктура + поддержка.
Проверьте: Есть оценка поддержки и ухода на третий год.
Если не сработало: Добавьте диапазон и явно укажите допущения.
- Сделайте одинаковый пилот
Дайте двум вариантам одну выборку входов и один критерий результата. Проверьте не только качество, но и насколько легко исправить ошибку и выгрузить данные.
Проверьте: Решение принято после реальной задачи, а не презентации.
Если не сработало: Остановите пилот, если нельзя безопасно проверить результат.
Сравниваю три варианта
В таблицу добавьте SaaS, API + собственный workflow и полностью свою систему. Для каждого посчитайте трёхлетний TCO: запуск, лицензии, API, интеграции, сотрудники, безопасность, инфраструктура, поддержка и миграция. Не сравнивайте месячную подписку с зарплатой разработчика.
Оцените скорость запуска 20%, соответствие 20%, TCO 20%, контроль данных 15%, безопасность 15% и выход от поставщика 10%. Итог = сумма(оценка × вес). Перед решением прогоните 20 реальных кейсов и попробуйте выгрузить данные.
TCO = запуск + лицензии + API + интеграции + люди + безопасность + поддержка
Итог = сумма(оценка * вес)Тест на выход из поставщика
Попросите выгрузку в понятном формате, проверьте удаление данных, права доступа, SLA, цену роста объёма в 10 раз и срок миграции. Если компания не может назвать владельца системы после запуска, неважно, build это или buy — решение ещё не готово.
Пилот, который снимает спор
Дайте SaaS, API-workflow и своей разработке одну выборку из 20 реальных примеров. Для каждого запишите время, точность, ручные исправления, стоимость и возможность выгрузить исходные данные. Не принимайте решение по demo с идеальным входом.
Если готовый сервис закрывает 80% типового процесса, а оставшиеся 20% можно оставить ручными, это часто лучше полноценной платформы. Собственную систему выбирайте только вместе с владельцем, бюджетом поддержки и планом выхода — иначе «контроль» закончится одним разработчиком, который ушёл в отпуск.
Что должно измениться после настройки
Вы сравните варианты по полной стоимости владения и проверите их на одном пилоте.
Почему «сделаем сами» почти всегда недооценивают
Строить свою систему ради контроля типовой задачи.
Покупать инструмент без API и экспорта данных.
Не считать поддержку и внутреннее время команды.
Сравнивать demo-возможности, а не реальную операцию.
Когда решение уже влияет на архитектуру бизнеса
Подключайте специалиста, когда выбор касается архитектуры, нескольких систем, персональных данных или многолетнего TCO.
Что проверить в договоре и в коде
Когда подходит гибрид?
Когда базовую часть можно купить, а уникальные правила, данные или интеграции оставить у себя.
Нужно ли учитывать зарплату владельца?
Да. В TCO входят часы команды, подрядчиков и внутреннего ответственного.
Когда покупать готовое?
Когда задача типовая, важны скорость и интеграции, а требования не дают сильного отличия.
Когда строить самому?
Когда процесс уникален, данные нельзя отдавать наружу, нужна особая логика или стоимость лицензии растёт быстрее разработки.
