Почему внедрение ERP не приносит эффекта, на который рассчитывали, как правильно ставить цели проекта и не тиражировать проблемы, как подготовиться к автоматизации, почему важно стандартизировать процессы, и чем может помочь интегратор — в нашей новой статье.
Неутешительный итог
ERP — инструмент, а не результат сам по себе
Информация должна появляться тогда, когда на неё ещё можно повлиять
ERP как инвестиция в бизнес
Корректная постановка целей
Нельзя автоматизировать хаос
Что необходимо сделать до автоматизации
А обязательно ли дорабатывать?
Сначала унифицировать, потом автоматизировать
Что даёт стандартизация
Как выглядит правильная последовательность шагов
Зеркало процесса
Неутешительный итог
Представим ситуацию: по результатам реализации проекта бюджет освоен в полном объёме, система введена в промышленную эксплуатацию, соответствующий приказ подписан. Формально проект завершён успешно.
Вместе с тем содержательная оценка результатов показывает иную картину: фактическая производительность ключевых операций осталась на уровне, предшествовавшем внедрению, либо снизилась, неудовлетворённость пользователей выросла, а затраты на обслуживание и доработку системы увеличились.
ERP внедрена, деньги потрачены, система работает, но ожидаемого результата предприятие не получило.
Почему?
Причину в такой ситуации легко искать в выбранной системе, интеграторе, отдельных технических решениях или пользователях. Однако нередко проблема возникает значительно раньше, ещё до начала автоматизации, когда предприятие определяет:
что именно оно собирается автоматизировать и какого результата хочет достичь.
Если существующие процессы до внедрения не были проанализированы и пересмотрены, новая система с высокой вероятностью воспроизведёт сложившийся порядок работы вместе с его ограничениями, исключениями, ручными операциями и исторически накопленными «костылями».
Тогда возникает закономерный результат: система новая, а проблемы — прежние.
ERP — инструмент, а не результат сам по себе
Стремительное развитие технологий требует от предприятий постоянно пересматривать сложившиеся модели ведения бизнеса. При этом само использование современных ERP-систем не создаёт экономическую ценность автоматически. Наличие лицензий, новая платформа или удобный интерфейс ещё не означают, что предприятие стало работать эффективнее.
Ценность возникает при изменении способа функционирования предприятия.
Результат должен быть заметен в конкретных показателях:
- сокращении количества ручных операций;
- снижении числа ошибок;
- сокращении времени согласований;
- повышении точности расчёта себестоимости;
- ускорении закрытия учётного периода;
- сокращении потерь;
- повышении прозрачности хозяйственной деятельности;
- ускорении принятия управленческих решений.
При этом нельзя игнорировать отраслевую специфику. Металлургическое предприятие, розничная торговля, строительство, транспорт имеют разные бизнес-процессы и регуляторные требования. Именно поэтому вокруг типовых платформ существуют отраслевые решения.
Задача автоматизации не заключается в попытке сделать все предприятия одинаковыми.
Истинная цель — понять, какая специфика действительно обусловлена бизнесом, а какая является лишь исторически сложившимся способом работы.
Информация должна появляться тогда, когда на неё ещё можно повлиять
Одна из основных задач ERP — своевременно фиксировать события хозяйственной деятельности и предоставлять информацию, необходимую для управления.
Для руководителя важна не только точность данных, но и момент, когда они становятся доступны. Информация имеет ограниченный период управленческой ценности.
Если предприятие своевременно видит изменение закупочной цены, оно ещё может пересмотреть условия закупки. Если вовремя выявлены признаки неблагонадёжности контрагента — можно приостановить дальнейшие отгрузки. Если руководство своевременно получает информацию о снижении маржинальности — можно изменить цену или условия продаж.
Те же самые данные, полученные через несколько недель, могут оставаться абсолютно точными, но уже использоваться преимущественно для ответа на вопрос: «Почему это произошло?» Повлиять на произошедшее поздно.
Поэтому скорость получения информации — не просто вопрос удобства работы с системой. Это одно из условий её применимости для управления.
Именно накопление подобных проблем часто приводит предприятие к решению о внедрении ERP: ручные сверки, разные источники данных, длительное формирование отчётности, информация «по факту», когда управленческое решение уже запаздывает.
Но в момент принятия решения о внедрении важно не остановиться на формулировке «нам нужна новая система».
Необходимо определить, что именно должно измениться в бизнесе благодаря этой системе.
ERP как инвестиция в бизнес
В условиях ограниченной доступности собственных и заёмных ресурсов ERP-проект нельзя рассматривать как бесконечный процесс адаптации системы под все существующие пожелания и привычки предприятия.
ERP конкурирует за деньги не только с другими ИТ-проектами. Те же средства предприятие может направить на:
- закупку сырья;
- ремонт оборудования;
- развитие производственных мощностей;
- логистику;
- персонал;
- другие направления деятельности.
Следовательно, вложения в ERP также должны быть обоснованы результатом.
Особенно это относится к индивидуальным доработкам.
Техническая возможность реализовать в системе определённую функцию ещё не означает, что её необходимо реализовывать.
Перед каждой существенной доработкой полезно задать простые вопросы:
- Какую проблему бизнеса решает это изменение?
- Как сейчас проявляется и измеряется эта проблема?
- Что должно измениться после доработки?
- Можно ли получить тот же результат изменением самого процесса, без усложнения системы?
- Как изменится ситуация, если оставить всё как есть?
Если ответы на эти вопросы отсутствуют, стоит ещё раз проверить: перед нами действительно бизнес-требование или попытка перенести в новую систему привычный способ работы.
Следуетт помнить, стоимость доработки — это не только часы разработчика, это ещё и её совокупная стоимость владения в будущем:
дополнительное тестирование;
- усложнение обновлений;
- расходы на сопровождение;
- риск возникновения новых ошибок;
- усложнение обучения сотрудников;
- необходимость документирования;
- зависимость от специалистов, понимающих реализованную уникальную логику.
Маленькая доработка сегодня может оказаться постоянным источником затрат завтра.
Корректная постановка целей
Отдельной и часто недооценённой причиной неуспешности ERP-проектов является размытая либо изначально завышенная постановка целей.
- «Навести порядок».
- «Повысить эффективность».
- «Сделать удобнее».
- «Система должна работать лучше».
Все эти формулировки понятны на бытовом уровне, но практически непригодны для оценки результата. Под них можно подвести почти любой итог проекта. И тот же самый результат позднее может быть признан неудовлетворительным, поскольку заранее не было определено, что именно должно стать лучше.
Корректная постановка целей предполагает несколько условий.
Измеримость
Желательно отказаться от расплывчатых формулировок «ускорить закрытие периода», заменив их на содержащие конкретные метрики и качественные значения «сократить срок закрытия периода с Х рабочих дней до Y».
Не «повысить точность себестоимости», а определить конкретные расхождения, причины их возникновения и ожидаемый результат после внедрения.
У проекта должно быть исходное состояние, целевое состояние и понятный способ проверки результата.
Связь целей разных уровней
Цели верхнего уровня — финансовые и управленческие — должны быть связаны с целями отдельных процессов.
Если предприятие планирует снизить себестоимость, должно быть понятно, за счёт изменения каких процессов это произойдёт.
При автоматизации отдельной операции, необходимо четко понимать, на какой показатель бизнеса она должна повлиять.
Иначе возникает риск автоматизировать большое количество операций, каждая из которых выглядит полезной сама по себе, но их связь с конечным результатом предприятия остаётся неочевидной.
Границы проекта
Не менее важно зафиксировать то, что проект не решает.
При обнаружении в ходе анализа проблемы, которую заказчик сознательно принимает решение не включать в объём проекта, ее необходимо зафиксировать.
В противном случае после запуска именно эта проблема может стать причиной неудовлетворённости результатом, хотя её устранение изначально не входило в задачу.
Согласование ожиданий до начала проекта.
Ожидания необходимо согласовывать не на этапе приёмки, а на старте.
Фраза «система должна работать лучше» для руководителя, пользователя и команды внедрения может означать совершенно разные вещи.
Отсутствие акцента на различиях в начале, может привести к невозможности их устранения, когда система уже фактически создана.
Нельзя автоматизировать хаос
После того как цели определены, возникает следующий вопрос: что именно мы будем автоматизировать?
На определённом этапе практически каждого ERP-проекта появляется понятное желание: «Сделайте, чтобы в новой системе было примерно так же, как в старой».
Желание рациональное.
Так проще снизить сопротивление персонала, быстрее обучить пользователей и уменьшить риски переходного периода.
Проблема возникает тогда, когда сохранение привычного порядка становится основным принципом проекта.
Один из распространённых сценариев выглядит следующим образом.
Команда внедрения подробно описывает существующие процессы «как есть» — as-is. Заказчик утверждает их в качестве основы будущей системы. После этого задача постепенно сводится к тому, чтобы новая ERP воспроизвела прежнюю учётную модель.
Вместе с действительно необходимыми процессами переносятся:
- обходные решения;
- лишние согласования;
- двойной ввод информации;
- исторически сложившиеся исключения;
- компенсаторные механизмы;
- ручные операции;
- решения, появившиеся когда-то из-за ограничений старой системы;
- «костыли», необходимость которых уже никто не может объяснить иначе, чем фразой «мы всегда так делали».
В результате предприятие получает в новой системе то же самое, что было в старой.
Только теперь этот порядок ещё и зафиксирован в программной логике.
Именно здесь кроется одна из ключевых причин, почему заказчик может не получить ожидаемого результата.
Если существующий процесс был неэффективным, его точная автоматизация не делает его автоматически правильным.
В лучшем случае он начинает выполняться несколько быстрее. В худшем — ERP тиражирует проблему и делает её исправление дороже.
Старый «костыль», который раньше можно было отменить управленческим решением, после автоматизации становится доработкой, которую необходимо сопровождать, тестировать и учитывать при каждом последующем изменении системы.
Поэтому ERP приносит экономический эффект не столько тогда, когда новая система максимально похожа на существующие привычки предприятия, сколько тогда, когда внедрение используется как возможность пересмотреть и улучшить процессы.
Но ИТ не может пересмотреть бизнес вместо заказчика
Здесь важно не свести проблему к качеству работы интегратора или ИТ-команды.
ИТ может автоматизировать согласованный процесс: настроить систему, разработать необходимую функциональность, выстроить интеграции и контрольные механизмы.
Однако ИТ не может самостоятельно решить: нужны ли предприятию пять уровней согласования, должны ли одинаковые операции в разных подразделениях выполняться одинаково, сохраняет ли исторически сложившееся исключение бизнес-смысл. Это управленческие решения.
Поэтому полноценный пересмотр процессов требует готовности самого заказчика.
Более того, аудит бизнес-процессов иногда показывает, что причина проблемы находится не в программе и не в работе конкретного сотрудника, а в ранее принятых управленческих решениях: распределении полномочий, системе согласований, организации взаимодействия подразделений.
Признать это зачастую сложнее, чем сказать: «Нам нужна другая система».
В результате сопротивление аудиту может возникать не только на уровне рядовых пользователей, но и на уровне руководства.
Если заказчик не готов пересматривать существующую модель, команда внедрения в конечном итоге автоматизирует именно её. И технически успешно выполненный проект может не дать ожидаемого бизнес-результата.
Что необходимо сделать до автоматизации
Условия для получения ожидаемого эффекта формируются тогда, когда внедрение используется как повод для полноценного анализа процессов: не формального интервью: «Расскажите, как вы работаете», а полноценного структурированного разбора того, как предприятие работает фактически.
Определить реальные процессы
Формально утверждённый регламент и фактическая практика могут существенно отличаться. Нередко отличается и представление руководства о процессе от того, как он действительно выполняется. Само такое расхождение уже является поводом для анализа.
Найти узкие места
Необходимо определить операции, которые ограничивают весь процесс.
Например:
- склад физически не успевает обработать документы к моменту закрытия периода;
- согласование зависит от одного перегруженного сотрудника;
- одни и те же данные несколько раз вводятся в различные системы;
- информация формируется вручную и появляется слишком поздно.
Автоматизация всего остального процесса без устранения его ключевого ограничения может практически не изменить итоговый результат.
Разделить типовые и действительно уникальные операции
Не вся уникальность является преимуществом бизнеса.
Часть её возникает исторически.
Особый порядок работы мог появиться несколько лет назад из-за единичной ситуации и продолжает применяться сегодня просто потому, что никто не вернулся к вопросу о его необходимости. При этом объективная уникальность действительно существует.
Она может быть обусловлена:
- отраслью;
- законодательством;
- технологией производства;
- требованиями безопасности;
- особенностями бизнес-модели;
- конкурентным преимуществом предприятия.
Задача аудита — отделить одно от другого до автоматизации, а не тогда, когда уникальная логика уже реализована в системе.
Проверить исключения
Исключение не всегда является «особенностью бизнеса», в ряде случаев это обычная ошибка процесса, которая со временем стала восприниматься как норма.
Разница принципиальна: особенность бизнеса необходимо поддерживать в системе; ошибку процесса необходимо устранить, а не автоматизировать.
Пересмотреть нормативно-справочную информацию
Перенос НСИ без предварительной нормализации означает перенос старого беспорядка на новую платформу.
Дубли контрагентов, устаревшая номенклатура, неактуальные данные, разные принципы заполнения справочников — данные необходимо анализировать до миграции.
Новая система не должна становиться новым местом хранения старого информационного хаоса.
А обязательно ли дорабатывать?
Результаты аудита — это не обязательно список необходимых доработок.
Иногда самый экономически эффективный результат анализа заключается в обратном: доработка вообще не нужна. Возможно, требуемая функциональность уже реализована в стандартных механизмах платформы или существует готовое отраслевое решение.
До аудита собственный процесс может восприниматься как уникальный, после разбора оказывается: его задача вполне решается типовым способом.
В таком случае отказ от индивидуальной разработки позволяет сократить:
- стоимость внедрения;
- сроки проекта;
- затраты на дальнейшее сопровождение;
- риски обновлений;
- зависимость от конкретных специалистов.
Поэтому важный результат качественного анализа — не только перечень необходимых изменений, но и перечень ненужных доработок.
Сначала унифицировать, потом автоматизировать
После описания процессов необходимо посмотреть и на внутреннюю неоднородность предприятия. Одинаковые по своей сути операции нередко выполняются по-разному в разных подразделениях, филиалах или компаниях группы. Для некоторых различий действительно существуют объективные причины. Но часть из них объясняется проще:
- «у нас здесь исторически сложилось»;
- «этот сотрудник привык работать иначе»;
- «в старой системе было настроено по-другому».
При отсутствии объективной причины для различий одинаковые операции целесообразно сначала привести к единой логике внутри предприятия и только после этого закреплять данную логику в ERP.
Иначе система не устраняет организационную сложность, а фиксирует её.
Что даёт стандартизация
Стандартизация типовых процессов позволяет получить несколько эффектов одновременно.
Снижение стоимости владения системой
Типовой процесс поддерживается стандартными механизмами платформы и не требует отдельной адаптации при каждом обновлении.
Чем меньше необоснованной уникальной логики, тем меньше:
- объём тестирования;
- стоимость сопровождения;
- вероятность дополнительных ошибок;
- сложность обучения;
- зависимость от конкретных разработчиков.
Повышение предсказуемости
Одинаковый процесс выполняется одинаково независимо от сотрудника или подразделения.
Для территориально распределённой структуры это особенно важно.
Упрощение диагностики
Когда существует понятный стандарт, отклонение от него легче увидеть и определить его причину.
Если же «особый порядок» уже встроен в саму систему и считается штатным поведением, понять, где заканчивается норма и начинается проблема, значительно сложнее.
При этом стандартизация не означает отказ от всей уникальности.
Процессы, действительно обусловленные бизнес-моделью, технологией, законодательством или конкурентным преимуществом, необходимо сохранить.
Вопрос заключается не в том, чтобы сделать всё стандартным.
Вопрос — в том, чтобы не платить за необоснованную уникальность.
Как выглядит правильная последовательность шагов
Теперь можно вернуться к ситуации, с которой мы начали.
ERP внедрена. Бюджет освоен. Система введена в эксплуатацию.
Результаты: производительность существенно не выросла, пользователи недовольны, расходы на сопровождение увеличились.
В рассматриваемой ситуации ключевая причина заключается в том, что необходимая работа с бизнес-процессами не была завершена до начала их автоматизации.
Если цели не определены измеримо, невозможно объективно оценить результат.
Если существующие процессы не проанализированы, в новую систему переносятся их старые проблемы.
Если исторические исключения воспринимаются как обязательная специфика, они превращаются в дорогостоящие доработки.
Если одинаковые операции не унифицированы, ERP закрепляет различия вместо того, чтобы снижать сложность.
Если заказчик не готов пересматривать собственные процессы, ИТ-команда может лишь автоматизировать ту модель, которую ей передали.
И тогда формально успешный проект вполне может оказаться экономически неуспешным.
Экономический эффект ERP возникает не столько в случае, когда система похожа на привычки предприятия, сколько тогда, когда предприятие использует внедрение как повод для улучшения процессов.
Поэтому правильная последовательность выглядит не так:
существующий процесс → техническое задание → автоматизация.
А так:
бизнес-цель → анализ фактического процесса → выявление узких мест и лишней сложности → пересмотр и унификация → определение обоснованной специфики → выбор типового решения или необходимой доработки → автоматизация → оценка результата.
Именно работа, выполненная до начала технической реализации, во многом определяет, получит ли предприятие ожидаемый эффект после её завершения.
Иначе можно успешно автоматизировать процесс и лишь после запуска обнаружить, что автоматизировать его в таком виде вообще не следовало.
Зеркало процесса
Технический специалист не заменяет заказчика в решении, как должен быть устроен процесс. Но с помощью подходящей нотации он может дать заказчику то, чего часто не хватает на старте проекта, - зеркало, в котором процесс виден целиком, а не фрагментами. И нередко именно это зеркало становится первым шагом к разговору, ради которого и затевалось всё обследование.
Консультант по внедрению, аналитик или разработчик, как правило, не дает содержательную рекомендацию по оптимизации бизнес-процесса. Он не работает в этом процессе каждый день, не отвечает за его результат и не обладает полнотой контекста, который есть у бизнес-заказчика: почему согласование устроено именно так, зачем существует конкретное исключение, какие последствия повлечёт его отмена.
Но у технического специалиста есть другая, не менее ценная возможность.
То, что технический специалист точно может сделать — показать процесс.
Даже не имея права принимать решение об изменении процесса, он способен помочь этот процесс увидеть.
Формализация процесса в графической нотации — будь то BPMN, IDEF0, EPC (Event-driven Process Chain), DFD (диаграмма потоков данных) или обычная кросс-функциональная блок-схема (swimlane diagram) — переводит устное описание «мы работаем вот так» в наглядную, проверяемую структуру.
И здесь происходит важный эффект.
Пока процесс существует только в виде рассказа сотрудника или разрозненных пунктов регламента, его несогласованности, дублирования и разрывы легко ускользают из фокуса. Собеседник интуитивно «достраивает» пробелы, сглаживает противоречия, не замечает петель и тупиков.
Как только тот же процесс выложен в виде диаграммы — с чёткими исполнителями, точками принятия решений, входами и выходами — становится видно то, что раньше не бросалось в глаза.
Ни одно из этих наблюдений не является рекомендацией «как нужно». Но каждое из них — законный повод для вопроса к бизнесу: а это действительно нужно именно так?
