
Часто слышу, как коллеги говорят о внедрении ERP для проектов как о серебряной пуле. Но на практике, классическая ERP система, заточенная под учет ресурсов и финансов, может создать больше хаоса, чем порядка, если пытаться втиснуть в нее всю динамику проектного управления. Это не просто софт — это философия, и не всякая философия подходит для живого, меняющегося проекта.
Взялись как-то за крупный инфраструктурный проект с использованием одной из популярных ERP-платформ. На бумаге всё сходилось: бюджеты, закупки, человеко-часы. Но как только начались ежедневные стендапы и потоки изменений от заказчика, система начала буксовать. Она требовала четких, фиксированных задач, а реальность требовала гибкости. Мы тратили больше времени на внесение данных и согласование изменений в модулях, чем на саму работу.
Здесь и кроется главный подводный камень: ERP часто рассматривают как единый источник истины, но для проектного управления нужен не столько архив, сколько живой пульт управления. Нужно видеть зависимости, риски, прогресс по спринтам, а не только фактические затраты против плановых. Это разные языки.
Поэтому сейчас многие, включая нашу компанию ООО Хэнань Цзюйхэ Текнолоджи, подходят к вопросу иначе. Мы не пытаемся заменить специализированные Project Management инструменты на ERP. Вместо этого мы интегрируем их, создавая связующий слой. Это позволяет финансовому блоку ERP видеть общую картину затрат, а проектным командам — работать в привычной, гибкой среде. Подробнее о таком подходе можно посмотреть на нашем сайте, где мы как раз описываем кейсы цифровой трансформации бизнес-процессов.
Если всё-таки решились на использование ERP системы в управлении проектами, сфокусируйтесь на трех точках интеграции. Первая — планирование ресурсов. ERP обычно оперирует должностями и ставками, а в проекте нужны конкретные люди с их навыками и загрузкой. Приходится создавать сложные правила сопоставления, и они часто дают сбой.
Вторая точка — управление закупками и контрактами. Тут ERP, наоборот, может быть сильна. Но если проект подразумевает agile-закупки или частые изменения в спецификациях, жесткий контур утверждения в ERP будет тормозить все процессы. Мы однажды чуть не сорвали сроки из-за того, что на согласование мелкой дополнительной закупки ушла неделя, хотя технически работа стояла.
И третье, самое болезненное — учет рабочего времени и прогресса. Сотрудники ненавидят вбивать часы в несколько систем. А без этого данные в ERP о фактических трудозатратах становятся фикцией, и всё управление затратами летит в тартарары. Пришлось разрабатывать упрощенные мобильные интерфейсы и настраивать автоматический сбор данных из систем разработки.
В нашей работе как поставщика услуг цифровой трансформации мы прошли путь от попыток использовать монолитные ERP для всех проектов до гибридной модели. Мы убедились, что для R&D-проектов или проектов внедрения ПО нужна одна конфигурация, а для строительных или инфраструктурных — другая. Универсального рецепта нет.
Например, для проектов, связанных с аналитикой данных, мы используем связку, где ERP отвечает за финансовый контроль и расчеты с подрядчиками, а вся оперативная деятельность — планирование задач, коммуникация, трекинг багов — ведется в Jira и Confluence. Синхронизация происходит раз в сутки через API. Это не идеально, но это работает и не мешает команде.
А вот для проектов по развертыванию оборудования, где важен учет материальных потоков и складских остатков, мы, наоборот, глубже задействуем соответствующие модули ERP (например, SAP или 1С), но значительно дорабатываем интерфейсы для полевых сотрудников, чтобы те могли быстро отмечать выполнение операций со смартфона. Это тот самый баланс, который и является сутью цифровой трансформации.
Самый горький урок — не пытайтесь настроить ERP систему для проектов силами только финансового департамента или ИТ-администраторов. Без активного участия руководителей проектов и даже рядовых исполнителей вы получите идеальную систему отчетности, в которую никто не вносит актуальные данные. У нас был случай, когда из-за этого расхождение между 'официальным' прогрессом в системе и реальным достигло 40%.
Еще одна ошибка — чрезмерная кастомизация. Начинаешь подстраивать ERP под каждую мелочь workflow, а в итоге получаешь 'франкенштейна', которого невозможно обновить. Лучше смириться с некоторой неидеальностью процессов в системе и компенсировать это внешними, но простыми инструментами.
И главное — не ждите, что система сама наведет порядок. Если в компании хаос в процессах, то внедрение ERP его только усугубит, сделав более дорогим и заметным. Сначала нужно хотя бы на уровне здравого смысла договориться о базовых правилах игры в проектах, а уже потом искать для них цифровую поддержку.
Сейчас я вижу тренд на появление более гибких, облачных ERP-решений, которые из коробки предлагают более приспособленные для проектов модули. Но даже они не панацея. Ключевым становится не выбор 'той самой' системы, а архитектура данных: как настроены конвейеры передачи информации между специализированным PM-инструментом, системой коммуникаций и ERP.
Всё чаще мы в ООО Хэнань Цзюйхэ Текнолоджи говорим с клиентами не о внедрении ERP для управления проектами, а о создании единой цифровой экосистемы. В которой ERP система выполняет свою узкую, но важную функцию учета финансов и ресурсов, а управление сроками, содержанием и рисками происходит в более подходящих для этого средах. Это сложнее продать, но зато это работает в реальности.
Итог моего опыта прост: ERP в проектах — это мощный инструмент контроля, но плохой инструмент для собственно управления. Используйте его силу там, где она нужна — для финансовой дисциплины и отчетности. А для руководства проектом, для мотивации команды и быстрого реагирования на изменения ищите другие решения или грамотно комбинируйте. И помните, что любая система должна служить людям и процессам, а не наоборот.