Статья Мэтта Шумера наводит на глубокие размышления о скорости изменений и нашем восприятии реальности. В контексте ERP-систем этот разрыв между "кажущимся" и "реальным" особенно опасен. Вот несколько пунктов-размышлений о том, как сейчас меняются требования к ERP на всех этапах жизни системы — от выбора до утилизации.
Статья Мэтта Шумера наводит на глубокие размышления о скорости изменений и нашем восприятии реальности. В контексте ERP-систем этот разрыв между "кажущимся" и "реальным" особенно опасен. Вот несколько пунктов-размышлений о том, как сейчас меняются требования к ERP на всех этапах жизни системы — от выбора до утилизации.
Этап выбора: От "монолита под ключ" к "конструктору для сборки"
- Архитектура как критерий выбора №1. Раньше смотрели на функциональность "из коробки". Теперь ключевой вопрос: насколько легко ERP становится центром экосистемы, а не закрытым островом . Требуется не монолит, а стабильное ядро с открытыми API, позволяющее подключать специализированные сервисы (WMS, TMS, CRM, системы предиктивной аналитики) без "танцев с бубном" и многомесячных доработок .
- Готовность к "агентной эре". Выбирая ERP в 2026 году, нельзя игнорировать вопрос: как эта система будет взаимодействовать с ИИ-агентами? Речь не о встроенном чат-боте, а о том, может ли система стать "фабрикой агентов", которые автономно перестраивают производство, ведут переговоры с поставщиками или прогнозируют кассовые разрывы . Те, кто не закладывает эту возможность сейчас, рискуют отстать навсегда, как те, кто в 2023-м не начал общаться с GPT.
- Безопасность как бизнес-логика. После рекомендаций ФСТЭК от января 2026 года стало окончательно ясно: безопасность ERP — это не только защита периметра, но и контроль внутренней логики. Особенно это касается компаний, все еще использующих SAP, но уже актуально и для растущих российских платформ. Требование к прозрачности совокупной стоимости владения (TCO) теперь включает и аудит безопасности как обязательную статью расходов .
Этап внедрения: От "запуска любой ценой" к "эволюции без сбоев"
- Реинжиниринг процессов до кода. Статья про "недовнедренные" ERP бьет в самую точку: нельзя тащить в новую систему старые "болезни" процессов . Если просто автоматизировать хаос "как есть", система превратится в дорогую "печатную машинку". Сегодня успех внедрения зависит не от количества написанного кода, а от методологической чистоты: насколько "чисты" мастер-данные и избавлены ли процессы от хрониеческих разрывов между логикой системы и реальностью цеха .
- Композитность вместо кастомизации. Вместо того чтобы годами дорабатывать монолит (и бояться обновлений), бизнес требует возможности собирать решения из "кубиков" . Микросервисная архитектура и корпоративные маркетплейсы приложений позволяют закрывать потребности конкретных ролей (кладовщик, юрист, HR) без перестройки всего ландшафта . Внедрение превращается из проекта с датой конца в непрерывный процесс развития.
Этап использования: От "учета фактов" к "управлению будущим"
- Система как "интеллектуальная рабочая сила". Использование ERP меняется кардинально: пользователь перестает быть "оператором" и становится "контролером" . Если раньше нужно было вручную создать заказ, то теперь агент сам перепланирует производство из-за сбоя поставки, а человек лишь утверждает или отклоняет действие . Это требует новых навыков от сотрудников и новых подходов к управлению изменениями.
- Качество данных = выживание бизнеса. Как верно замечено в статье про ИИ, если ваша ERP система генерирует хаос, искусственный интеллект лишь ускорит этот хаос и сделает его масштабнее . Требование к "чистоте" данных становится критическим для выживания. Ошибка в мастер-данных теперь оборачивается не просто кривым отчетом, а автоматическим принятием неправильного решения агентом.
- Борьба с FOMO через осознанную архитектуру. Возвращаясь к мысли Мэтта Шумера — многие боятся отстать, и этот страх толкает к поспешным решениям. Но в ERP-ландшафте паника ведет к лишним тратам так же, как и выбор, продиктованный общим рефлексом: автоматически взять самое массовое решение, просто потому что "так принято", "все так делают". Однако универсальные продукты, построенные на устаревшей архитектуре, не смогут ответить на вызовы завтрашнего дня, сколько бы денег вы в них ни вложили сегодня. Необходимо идти от конкретных задач бизнеса и новых критериев выбора, которые диктует время: микросервисная архитектура и готовность к интеграции ИИ-агентов как неотъемлемая часть ERP-системы. Именно эти принципы заложены в основу развития программного комплекса CLBS, где каждый компонент можно развивать, масштабировать или заменять независимо, не ломая целостность управления. Это позволяет не гнаться за "модой на массовость", а гибко встраивать возможности будущего на уровне архитектуры, а не дошивать их "поверх" устаревшего монолита ценой бесконечных доработок.