ERP не исправляет плохое управление - она делает его обязательным
Шантарин
директор по информационным технологиям завода "Уралхиммаш"
Продажи требуют гибкости, производство - стабильного плана, снабжение - длительного горизонта закупок. ERP-система не разрешает этот конфликт: она закрепляет выбранную модель работы в правилах, ролях и алгоритмах.
Когда единый план означает разное
В одной переговорной сидят представители продаж, производства, снабжения, финансов и ИТ. Все согласны, что предприятию нужна единая ERP. Но каждое подразделение представляет будущую систему управления по-своему.
Для продаж ERP должна сохранять возможность менять объем, комплектацию и сроки заказа под требования клиента. Производство ждет от нее устойчивого плана загрузки оборудования на несколько месяцев вперед. Снабжение - прогноза потребности в материалах на год, особенно по позициям с длительными сроками поставки.
Каждое требование по отдельности разумно. Вместе они образуют управленческий конфликт. Когда заказ должен перестать меняться? Кто может нарушить утвержденный производственный план? Кто оценивает последствия такого решения?
Пока работа держится на Excel, переписке и личных договоренностях, эти противоречия можно разрешать в каждом конкретном случае. ERP требует общего порядка. Но она не способна определить его за руководство.
Если компания не договорилась о правилах заранее, разногласия не исчезают. Они переходят в требования к системе, маршруты согласования, права доступа и доработки. Локальный конфликт становится частью общего контура управления.
Запуск ERP еще не создает управляемость
Наличие ERP не означает, что она стала инструментом управления.
По данным опроса участников бизнес-форума "1С:ERP 2025", около 23% респондентов сообщили, что система управления ресурсами предприятия внедрена лишь частично. Еще 21% отметили, что ERP работает, но требует оптимизации. Только 10% назвали ее ядром управленческого контура компании. [1]
Эти результаты нельзя автоматически переносить на всю российскую экономику: в исследовании участвовала профессиональная аудитория отраслевого форума, значительную долю которой составляли производственные предприятия. Но опрос хорошо показывает разрыв между техническим запуском системы и созданием единого контура процессов, данных и ответственности.
ERP может годами использоваться как большой учетный механизм, но так и не стать средством управления предприятием.
Управленческая несогласованность проявляется на разных стадиях проекта. Иногда подразделения не могут договориться еще при формировании требований. Иногда модель меняется во время реализации. В других случаях слабость процессов и контроля обнаруживается только после запуска. Чем позже выявлена проблема, тем дороже ее исправление.
На этапе требований: опыт завода "Сигнал"
Показателен опыт Ставропольского радиозавода "Сигнал". [2]
До внедрения 1С:ERP предприятие использовало несколько разрозненных информационных систем, а часть операций выполнялась вручную. Первый проект был технически запущен, однако руководитель ИТ-службы завода Сергей Кондратьев позднее назвал его неудачным.
Подразделения не договорились о результате автоматизации. Каждая служба предъявляла требования исходя из собственного представления о процессе и пыталась получить решение под локальные интересы. Межфункциональные разногласия фактически были перенесены в требования к ERP.
Перед второй попыткой руководство определило общие приоритеты: отчетность по гособоронзаказу, комплексный бухгалтерский и налоговый учет, ввод первичных данных непосредственно в цехах и на складах. Целью стала финансовая прозрачность предприятия, а не удовлетворение отдельных функциональных заказчиков.
Одновременно была уточнена ответственность за данные. Их ввод закрепили за подразделениями, в которых возникают хозяйственные операции, и отделили от последующего контроля и бухгалтерской обработки.
Вторая попытка началась не с перенастройки программы, а с согласования общей цели и распределения ответственности.
Во время реализации: смена модели работы
С похожей проблемой мне пришлось столкнуться в собственной практике.
В одном из проектов после смены куратора изменились приоритеты автоматизации. К этому моменту модель будущих процессов была спроектирована, основные решения согласованы, а команда уже приступила к их реализации.
Новый куратор иначе определил не отдельные функции, а саму логику будущей работы: цели процесса, границы автоматизации и распределение ответственности.
Продолжение проекта по первоначальному плану позволяло получить технически работоспособную систему. Но из-за неактуального способа управления нам пришлось бы сразу "резать ее по живому": перенастраивать интеграции, исправлять данные, переобучать пользователей и перестраивать процессы под операционной нагрузкой.
Поэтому проект пришлось перепроектировать. Команда пересмотрела принятые решения, уточнила процессы, переработала требования и адаптировала архитектуру. Промышленный запуск сдвинулся примерно на год.
Перепроектирование позволило изменить модель до того, как предприятие начало жить по ее правилам.
После запуска: случай Revlon
В феврале 2018 года американский производитель косметической продукции Revlon запустил новую SAP ERP на своей крупнейшей производственной площадке в Оксфорде.
После запуска компания столкнулась с перебоями в производстве и отгрузках. По оценке Revlon, она не смогла выполнить поставки, соответствовавшие примерно $64 млн чистых продаж, и понесла $53,6 млн дополнительных расходов на восстановление уровня обслуживания. [3]
Одновременно компания признала существенный недостаток системы внутреннего контроля над финансовой отчетностью. В подразделениях, затронутых внедрением, не хватало подготовленных сотрудников, а контрольные процедуры в области учета запасов, выручки и финансовых операций не были должным образом выстроены.
SAP не создала дефицит компетенций и слабость контрольной среды. Но после запуска эти проблемы начали одновременно влиять на производство, отгрузки и финансовую отчетность.
Все три истории показывают одно: ERP делает выбранный порядок работы обязательным для связанных подразделений.
Но разве ERP не дисциплинирует компанию?
ERP действительно дисциплинирует исполнение. Она заставляет сотрудников своевременно оформлять операции, соблюдать установленные маршруты и работать с едиными данными. Типовые процессы сокращают ненужную уникальность и делают действия подразделений более предсказуемыми.
Рассмотренные кейсы не опровергают это преимущество. Они показывают его обратную сторону: система одинаково последовательно исполняет как разумный, так и неудачный порядок.
В ERP управленческое решение становится правилом процесса, а результат одной операции - исходными данными для следующей. Поэтому неверный срок влияет уже не только на одного планировщика, но и на закупки, загрузку оборудования, движение денежных средств и обязательства перед клиентом. Размытая ответственность проявляется в зависших документах, повторных согласованиях и постоянных эскалациях.
Можно безупречно соблюдать избыточный маршрут согласования или оперативно планировать производство по недостоверным нормативам. Дисциплина исполнения не исправляет качество самого процесса.
Особенно велик этот риск при импортозамещении. Многие компании меняют ERP не потому, что готовы пересмотреть модель работы, а потому, что эксплуатация прежней платформы становится рискованной. Поэтому задача нередко формулируется так: "Сделайте все как сейчас, только на другой системе".
Однако за годы эксплуатации прежняя ERP накапливает доработки, исключения и обходные решения. Их механический перенос сохраняет не только необходимую функциональность, но и устаревшие правила, размытые зоны ответственности и управленческие компромиссы прошлых лет.
Поэтому импортозамещение нельзя сводить к воспроизведению старой системы на новой платформе. Оно требует отделить действительно необходимые процессы от накопленного управленческого долга.
Вопрос не в том, должна ли ERP дисциплинировать компанию. Вопрос в том, какой именно порядок компания собирается сделать обязательным.
Что нужно решить до проектирования ERP
До проектирования и настройки системы компания должна обеспечить три условия.
1. Согласовать модель работы и назначить владельцев сквозных процессов. Они должны обладать реальными полномочиями. Необходимо заранее определить права принятия решений и порядок разрешения межфункциональных конфликтов.
2. Подготовить данные и контрольную среду. Для критических справочников необходимо назначить владельцев, установить правила ведения и измеримые показатели качества.
3. Подтвердить готовность к запуску. Пользователи должны уметь выполнить реальный производственный цикл, закрыть отчетный период и обработать критические исключения. Необходимо проверить сверки, резервные сценарии и готовность ключевых сотрудников.
Интегратор способен описать и настроить процесс, но не может решить за руководство, как должна работать компания. Если этот выбор передан проектной команде, она фактически проектирует систему управления, не имея для этого долгосрочной ответственности.
Поэтому результат ERP-проекта определяется не в день запуска, а раньше - когда руководство решает, как предприятие действительно должно работать. Хорошую модель ERP усиливает, плохую - масштабирует, а несогласованную заменяет случайным проектным правилом.
Использованные материалы:
1. Исследование участников бизнес-форума 1С:ERP 2025
Официальная публикация ГК "КОРУС Консалтинг" — "ERP сегодня: приоритеты и барьеры".
Исследование проводилось среди участников Бизнес-форума 1С:ERP 2025. В публикации приведены использованные в статье показатели:
- 23,08% внедрили ERP частично;
- 20,51% считают, что система требует оптимизации;
- 10,3% называют ERP ядром управленческого контура.
2. Кейс Ставропольского радиозавода "Сигнал"
Основной источник — интервью Сергея Кондратьева в TAdviser. В нём он прямо говорит, что первая попытка внедрения 1С:ERP была неудачной, поскольку подразделения не договорились о результате проекта и предъявляли противоречивые требования. Там же описано разделение ответственности за ввод и контроль данных.
Дополнительный источник — описание проекта на площадке конкурса 1С. Оно подтверждает две попытки внедрения, причины неудачи первой попытки, цели второго проекта и исходный ИТ-ландшафт предприятия.
3. Кейс Revlon
Официальный первоисточник — годовой отчёт Revlon за 2018 год, форма 10-K на сайте Комиссии по ценным бумагам и биржам США.
В отчёте указано, что запуск SAP ERP в феврале 2018 года вызвал перебои на площадке в Оксфорде, штат Северная Каролина. Revlon оценила объём невыполненных поставок примерно в 64 млн долларов чистых продаж, а дополнительные расходы — в 53,6 млн долларов.
В этом же документе описан существенный недостаток внутреннего контроля: нехватка подготовленного персонала и недостаточные контроли по запасам, дебиторской задолженности, выручке, себестоимости, сверкам и ручным проводкам.
