Что бизнес должен сделать до внедрения AI или новой ERP‑системы

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

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

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

Почему новая система не решает старые проблемы

Автоматизация часто воспринимается как способ навести порядок. Есть ручные операции — автоматизируем. Отчетность формируется долго — внедрим новую систему. Данные расходятся — построим единое хранилище. Финансовая модель слишком сложная — подключим AI.

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

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

Шаг 1. Договориться о методологии

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

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

До автоматизации нужно определить:

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

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

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

Шаг 2. Описать процесс как есть

Следующий уровень — процессы. Здесь тоже есть распространенная ошибка: компания автоматизирует не реальный процесс, а его формальное описание.

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

Поэтому перед внедрением я бы описывала процесс as is — как он работает сегодня, а уже затем проектировала to be — как он должен работать после изменений.

Полезно ответить на несколько вопросов:

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

Очень часто именно на этом этапе выясняется, что компании сначала нужно изменить сам процесс и только потом выбирать инструмент автоматизации.

Кейс: WMS внедрили, а расхождений стало больше

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

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

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

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

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

Шаг 3. Назначить владельца процессов и данных

Даже хорошо описанный процесс может перестать работать, если ответственность распределена между всеми.

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

Поэтому до автоматизации нужно определить как минимум:

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

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

Шаг 4. Навести порядок в данных

Можно идеально описать процесс и выбрать хорошую систему, но получить плохой результат из-за данных.

Типичная проблема — бизнес хочет построить прогноз с помощью AI, хотя исторические данные неполные, справочники не унифицированы, часть информации хранится в Excel, а одинаковые объекты могут называться по-разному.

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

Поэтому перед внедрением нужно проверить данные минимум по четырем критериям:

1. Достоверность: соответствует ли информация реальному состоянию бизнеса?
2. Полнота: есть ли все данные, необходимые для принятия решения?
3. Сопоставимость: одинаково ли одни и те же показатели определяются в разных периодах, подразделениях и системах?
4. Актуальность: обновляется ли информация с той скоростью, которая нужна для конкретного процесса?

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

Шаг 5. Выбрать технологию

Только после предыдущих четырех этапов имеет смысл обсуждать конкретную систему. К этому моменту компания уже должна понимать:

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

Тогда меняется и сам подход к выбору технологии. Вопрос перестает звучать как «какая ERP лучше?» или «какой AI-инструмент нам внедрить?». Он звучит иначе: «Какая технология лучше всего поддержит процесс, который мы уже спроектировали?».

Как понять, что компания готова к автоматизации

Перед запуском большого IT-проекта можно использовать простой чек-лист.

Если на несколько вопросов ответ «нет», я бы не спешила с полномасштабным внедрением. Это не означает, что проект нужно заморозить на год. Иногда подготовительный этап можно пройти достаточно быстро. Но несколько недель, потраченных на описание процесса и данных до внедрения, могут сэкономить месяцы доработок после запуска.

Как определить KPI автоматизации

Еще одна ошибка — считать успешным сам факт внедрения. ERP запущена, AI-модель работает, все сотрудники получили доступ, проект закрыт. Но бизнесу важен не запуск технологии, а изменение результата. Поэтому KPI лучше определить еще до начала проекта.

В зависимости от задачи это могут быть:

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

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

Например, вместо формулировки «автоматизировали согласование платежей» полезнее поставить цель: сократить среднее время обработки операции с 30 до 5 минут и уменьшить количество ручных проверок. Тогда через несколько месяцев можно оценить реальный результат.

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

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

Что делать, если система уже внедрена, а эффекта нет

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

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

• Если сотрудники создают параллельные Excel-файлы — почему они не доверяют системе?
• Если данные постоянно исправляются вручную — где появляется ошибка?
• Если система требует слишком много согласований — действительно ли они нужны?
• Если подразделения получают разные цифры — совпадает ли методология?

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

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

Поэтому до внедрения ERP, WMS, AI или другой большой системы я бы всегда прошла одну и ту же последовательность: методология → процессы → ответственность → данные → технология. Сначала порядок в методологии, процессах, ответственности и данных. И только потом — порядок в системе. Именно в такой последовательности технология становится инструментом повышения эффективности, а не дорогим способом автоматизировать существующий хаос.

Часто задаваемые вопросы