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

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

Коробочные решения — готовые ERP-, CRM- и учетные системы, рассчитанные на большинство компаний. Вендор закладывает в коробочный продукт базовую модель работы: структуру нормативно-справочной информации (НСИ), последовательность документов, роли пользователей, правила учета, типовые отчеты и интеграционные механизмы. Такой набор закрывает стандартные процессы и позволяет использовать обновления и поддержку производителя.

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

1. Внедрение типового решения. Компания использует штатные возможности платформы: настраивает права, роли, отчеты и маршруты согласования. Такой подход оправдан для бухгалтерского и кадрового учета, расчета зарплаты, регламентированной отчетности.
2. Адаптация системы. Компания дорабатывает прикладной слой: расширяет НСИ, настраивает управленческую отчетность, добавляет интеграционные обмены, меняет формы документов. Это ограниченные изменения, которые не затрагивают ядро продукта. При грамотной реализации платформа сохраняет обновляемость, а команда не превращает каждую доработку в самостоятельный проект.
3. Кастомная разработка. Компания создает функциональность, которой нет в коробочном продукте и которую нельзя реализовать штатными инструментами. Речь идет не о работе одного разработчика, а о проекте с аналитикой, архитектурой, интеграциями, тестированием, поддержкой и управлением изменениями.

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

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

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

Типового решения достаточно, когда:

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

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

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

Перед стартом стоит ответить на три вопроса:

1. Насколько процесс уникален?

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

2. Какой эффект даст доработка?

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

3. Кто отвечает за результат?

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

До запуска разработки нужно проверить возможности платформы. В большинстве решений есть low-code и no-code инструменты для настройки форм, маршрутов, ролей, правил обработки данных и отдельных сценариев. Их используют аналитики и администраторы системы. Полноценная кастомная разработка становится оправданной, когда требуется изменить логику процесса, создать новый модуль или организовать сквозной обмен данными между несколькими системами.

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

Для расчета используют совокупную стоимость владения — Total Cost of Ownership (TCO). В нее входят первоначальные затраты, сопровождение, развитие, интеграции и расходы, которые возникают после внедрения и даже затраты на вывод системы из эксплуатации. У типовой системы стоимость увеличивается по мере роста числа пользователей, объема данных, количества интеграций и требований к поддержке. У собственной разработки основные затраты сосредоточены в начале: аналитика, проектирование, архитектура, реализация, тестирование, ввод в эксплуатацию. После этого компания оплачивает поддержку и развитие своей команды, а не лицензии за созданную под ее процессы функциональность.

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

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

• Технологический долг

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

• Потеря обновляемости

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

• Конфликт приоритетов

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

Автобизнес объединяет продажу автомобилей, сервис и ремонт, гарантийные работы, запасные части и аксессуары, кредитование, страхование, контакт-центр и логистику. Эти направления связаны автомобилем с уникальным VIN-кодом.

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

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

У каждого производителя или импортера есть требования к отчетности, форматы обмена данными и уровень зрелости ИТ-процессов. В портфеле холдинга может быть 20–30 брендов и до 15 различных обменов: ежедневные и ежемесячные выгрузки, API, файловый обмен, иногда отчетность на бумажных носителях. Подробные API-спецификации есть не у всех партнеров, поэтому единый готовый продукт для большинства компаний практически невозможен. Каждый новый обмен нужно встроить в существующую архитектуру, контролировать данные и поддерживать при изменении требований партнера.

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

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

Кастомный подход нужен там, где он обоснован через бизнес-эффект: сокращение затрат, скорость работы с клиентом, изменение процессов или объединение нескольких систем в единый контур. До старта важно проверить возможности платформы, рассчитать TCO, определить владельца процесса и заранее установить правила работы с доработками.