Раньше ERP-проекты выглядели примерно одинаково: команда внедрения приходила, настраивала систему под требования заказчика, обучала пользователей, передавала ключи и уходила. А потом начиналась настоящая работа — когда система уже живёт в бою, данные растут, процессы меняются, запросы от бизнеса становятся сложнее. И вот здесь-то и возникали проблемы. Потому что никто не думал заранее, как поддерживать систему после внедрения.

ERP — это не просто набор модулей и справочников. Это часть ежедневной работы предприятия. Любое изменение в системе влияет на бизнес-процессы, логистику, финансы, HR. Поэтому важно, чтобы команда внедрения не только настраивала функционал, но и понимала, как за этим будет следить эксплуатационная команда. Чтобы те, кто делает, знали, как и кому это потом поддерживать.

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

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

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

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

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

Когда мы начали внедрять CI/CD для ERP-проектов, казалось, что это решит все проблемы. Собрались, настроили pipeline, подключили тестирование, автоматический деплой. Через неделю всё сломалось. Почему? Потому что никто не учёл, что перед выпуском нужно проверять не только функциональность, но и миграции данных. Потому что среда разработки отличалась от боевой. Потому что никто не проверял, как новая версия влияет на доступы и производительность на реальных объемах.

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

CI/CD стал частью культуры, а не просто технической задачей. Мы начали обсуждать, какие этапы должны быть в пайплайне, кто за что отвечает, как быстро можно получить обратную связь после каждого изменения. Это уже не просто инфраструктура. Это способ работы.

Интересно, что DevOps не предлагает ничего нового в техническом плане. Все инструменты были и раньше. Были и команды, которые давно делали автоматизацию. Но раньше это считалось скорее исключением, чем правилом. DevOps помог создать общую картину: показал, что интеграция внедрения и эксплуатации — это не мода, а необходимость.

Сейчас я часто вижу, как компании пытаются внедрить DevOps в ERP-проектах, нанимая "специалиста по DevOps". Как будто это должность, которая всё исправит. На самом деле, это не должность, а подход. Это культура, которую нужно внедрять во всё: в процессы, в коммуникацию, в отношения между командами.

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

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

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

Почему я люблю DevOps в ERP?

Потому что он показывает: технологии — это вторично. Первое место всегда остаётся за людьми. За тем, как они общаются, как принимают решения, как учатся на своих ошибках. Именно поэтому переход на DevOps — это не технический вызов, а культурный. Он требует изменений внутри команды, а не просто новых инструментов.

Источник: Лаборатория цифровых решений.

Больше новостей читайте в телеграм-канале SAPLAND: Новости экосистемы.