Готовый сервис или своя система: как выбрать выгодный вариант

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

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

Проверьте весь процесс на реальных данных

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

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

До испытания согласуйте несколько вещей:

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

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

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

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

Сравнивайте варианты по одним условиям

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

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

Требование хранить данные на собственных серверах тоже не ведёт автоматически к заказной разработке. Сначала стоит проверить готовые продукты, которые можно разместить на вашей инфраструктуре. Если на её части используется Astra Linux, нужна совместимость с этой операционной системой. Она сама по себе не подтверждает, что продукт подходит по функциям или требованиям безопасности.

Включите ручные обходы в стоимость решения

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

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

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

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

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

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

Посчитайте расходы за одинаковый период

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

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

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

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

Сопровождение своей системы требует отдельного ресурса

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

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

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

Проверьте, как продолжить работу без текущего поставщика

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

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

Я организовал перенос десятков ящиков, сотен тысяч писем и файлов. Подобрал стороннее ПО, которое работало через доступное API, изначально не предназначенное для миграции. Разобрал структуру папок и владение документами, настроил инструмент, провёл тестовый перенос, затем основной. Данные удалось перенести с минимальными потерями. Зависимость в этом случае возникла через посредника, а выход потребовал отдельной инженерной работы.

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

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

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

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

Рассмотрите готовую основу, надстройку и модернизацию

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

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

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

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

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

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

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

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

Проверьте, можно ли сохранить действующую систему

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

Корпоративный сайт на WordPress из нескольких сотен страниц я сначала рассматривал как кандидата на полную переделку. После изучения выбрал развитие существующей системы. Выполнил более 100 доработок, обновил WordPress и среду, подготовил тесты и регламент CI/CD - автоматизированной сборки, проверки и выпуска изменений. В нём определил источники компонентов и порядок обновления WordPress, плагинов и среды.

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

Основание для выбора и следующий шаг

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

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

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