Готовый сервис или разработка под бизнес: как принять решение

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

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

Отделите обязательное от привычного

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

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

Проверьте готовый продукт на сквозном примере

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

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

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

Учитывайте полные расходы каждого варианта:

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

Пример такого расчёта для личного кабинета есть в статье «Сколько стоит личный кабинет клиента».

Сравнение разовой разработки с месячной подпиской без срока использования ничего не говорит о полной стоимости.

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

Своя разработка означает своё сопровождение

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

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

Возможен промежуточный вариант

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

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

Как принять решение

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

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