Заказная разработка проигрывает по цене на старте и выигрывает там, где процессы отличаются от типовых. Ошибка в обе стороны стоит дорого: типовая система заставляет ломать работающий процесс, а заказная — оплачивать разработку того, что уже есть в готовом виде.
Проверка 1: сколько в процессах уникального
Если правила расчётов, маршруты согласования и роли укладываются в типовую логику — берите типовую. Если часть процессов существует только в вашей компании и именно она даёт результат, приведение к «как принято» лишит смысла сам процесс.
- Уникальные расчёты: себестоимость, бонусы, тарифы, которые считаются по вашим формулам.
- Ролевая модель: не «директор, менеджер, бухгалтер», а роли, привязанные к вашей структуре ответственности.
- Отраслевые правила: то, как работа устроена в вашей отрасли, а не в среднем по рынку.
Проверка 2: что уже работает в компании
Заказная система не означает «всё с нуля». В большинстве проектов учётный контур остаётся на месте, а заказным делается то, чего в готовом виде не существует: управленческий контур, интеграции, рабочие места, которых нет в типовых решениях.
- Учёт — в типовой системе: 1С и подобные остаются источником финансовых данных.
- Уникальный контур — заказной: роли, интерфейсы, аналитика, отраслевые модули.
- Обмен между ними — отдельная работа, которую нужно оценить заранее, а не «по ходу».
Проверка 3: сколько ролей и людей
Влияние на роли — главный источник скрытых расходов. Когда в одном контуре пять разных ролей, каждая требует своего интерфейса: у руководителя один экран, у линейного сотрудника другой. В проекте для государственной системы мы собирали контур с пятью ролями и разными правами доступа — типовая система потребовала бы приводить их к общей логике.
- Одна-две роли и общий сценарий — почти всегда типовая система.
- Пять и больше ролей с разными правами и разными задачами — повод считать заказную.
- Роли меняются от проекта к проекту (подрядчики, заказчики, проверяющие) — заказная гибче.
Проверка 4: интеграции и данные
Число систем, с которыми придётся обмениваться данными, определяет сложность проекта сильнее, чем объём функциональности. Банки, отраслевые сервисы, производственное оборудование, внутренние базы — всё это отдельные работы.
- Одна учётная система без внешних обменов — типовая справится.
- Банки, ЭДО, государственные сервисы, оборудование — считайте интеграции отдельными этапами.
- Данные в таблицах и файлах — сначала этап сбора, потом система.
В одном производственном проекте данные о выпуске, материалах и загрузке площадок жили в разных таблицах, которые не сводились между собой. Пять площадок удалось собрать в один контур только после того, как данные из 1С, систем контроля доступа и внутренних баз свели в общую модель.
Проверка 5: кто будет поддерживать
Заказная система живёт дольше проекта, и вопрос поддержки важнее технологии. Оценивайте не только разработку, но и то, кто будет менять систему через год.
- Есть ли в компании человек, который понимает модель данных и сможет формулировать задачи.
- Передаётся ли документация и доступы: код и архитектура должны остаться у вас.
- Как устроены доработки: сроки, оценка, порядок приоритетов.
Практический вывод: если по первым трём проверкам отвечаете «уникально много, роли разные, интеграций много» — считайте заказное решение и начинайте с обследования. Если уникального мало — сначала посмотрите, что даёт настройка типовой системы: это дешевле и быстрее, и честнее сказать об этом до старта.
Не уверены, нужна ли заказная система?
Разберём процессы, роли и интеграции, сравним варианты по стоимости владения и скажем прямо, где хватит типового решения.