Когда бизнесу нужна собственная система

Производитель редко просыпается с желанием заказать «большую IT-систему». Обычно есть конкретный сбой: менеджер продаёт по старому прайсу, склад живёт в другой таблице, заказ приходится переносить из почты в CRM, а руководитель сводит показатели вручную. На встрече звучит название знакомого продукта, потому что его уже используют другие компании. Но название системы не описывает задачу. Описывает её путь заказа, правило расчёта цены и ответственный за следующий шаг.

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

Готовая система приносит зрелые функции, документацию и понятную поддержку. Цена этой зрелости — необходимость принять её модель данных, роли и порядок операций. Это хороший обмен, пока модель совпадает с бизнесом. Интеграция подходит, когда источники уже надёжны, а граница между ними ясна: например, сайт передаёт заявку в CRM, а 1С остаётся владельцем номенклатуры и остатков. Тогда важно договориться, где живёт каждое поле и что происходит при ошибке обмена.

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

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

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

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

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

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

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

Мы ведём такой проект как продукт: отвечаем за границы, решения и передачу контекста, а не за количество отработанных часов. Открытый вопрос к заказчику — не «нужна ли вам своя система вообще», а «где сейчас теряется управляемость и какой один процесс стоит сделать прозрачным первым». Это и есть предмет технического разбора.