Эпоха после SAP: как замена софта стимулирует пересборку бизнес-процессов в российском бизнесе

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

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

Главный вопрос такого проекта звучит как «зачем этот процесс компании в его нынешнем виде?». Если ответ на него отсутствует, переносить такую конструкцию в новую систему экономически нецелесообразно.

Внедрение SAP в российском крупном бизнесе в 2000-е и 2010-е годы было не просто переходом на более современное программное обеспечение. Для многих компаний это был переход от разрозненного управления к формализованной системе, в которой финансы, закупки, производство, продажи, логистика и управление запасами начинали работать взаимосвязанно по единым правилам.

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

Таким образом, ERP-система становилась не только IT-инструментом, но и способом закрепить управленческие практики, которые до этого могли существовать в разных подразделениях в совершенно разном виде.

Хорошо это видно на примере Bauer Media в России. До внедрения SAP компания, в состав которой входило более 40 российских изданий, столкнулась с необходимостью унифицировать управленческие процессы по мере роста бизнеса. Перед настройкой системы консультанты сначала провели анализ и реинжиниринг бизнес-процессов, после чего сформировали единую модель управления, которую уже переносили в SAP. То есть система в данном случае стала не просто автоматизатором существующих операций, а инструментом стандартизации процессов внутри растущей структуры.

Другой показательный пример — «СИБУР», где внедрение SAP ERP охватило большое количество юридических лиц и объединило процессы, проходившие через разные уровни организации: от формирования потребности до оплаты, от производственных систем на предприятиях до корпоративных систем консолидации. Сам проект требовал не только внедрения программного продукта, но и перестройки взаимодействия между многочисленными системами и подразделениями. В компании прямо отмечали, что SAP поддерживал изменения самого бизнеса, а не просто автоматизировал уже существующие операции.

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

Один из наиболее затратных сценариев миграции — это попытка максимально точно воспроизвести существующую архитектуру в новой системе. В этом случае новая платформа начинает адаптироваться к процессам, которые сами ранее адаптировались под SAP. Возникает эффект «двойной подгонки»: бизнес сохраняет логику исторических процессов, а разработчики создают дополнительные настройки и доработки, чтобы воспроизвести ее в новом технологическом контуре.

В результате компания фактически переносит в новую систему не только рабочие процессы, но и все накопившиеся за годы управленческие компромиссы. Показательный пример — проект в производственном холдинге, где техническое задание на новую систему занимало около 600 страниц. При детальном анализе выяснилось, что примерно 40% требований описывали не бизнес-правила, а конкретные SAP-поля, статусы и последовательности действий.

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

Один из ключевых вопросов при пересмотре процессов можно сформулировать предельно просто: «Это правило бизнеса или привычка системы?» Ответ принципиален для каждого статуса, согласования, поля, отчета и контрольной процедуры, которые планируется сохранить в новой ERP. Регуляторное требование, контроль лимита, разделение полномочий или обязательное подтверждение сделки имеют понятную управленческую функцию и должны быть сохранены независимо от используемой платформы.

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

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

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

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

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

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

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

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

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

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

Отдельное направление пересборки связано с соответствием между квалификацией сотрудника и содержанием выполняемой работы. Условно эту проблему можно назвать «синдромом дорогого клика»: высококвалифицированный специалист тратит значительную часть рабочего времени на операции, которые не требуют его уровня экспертизы.

Например, финансовый контролер со стоимостью рабочего часа около 3 000 рублей может ежедневно тратить 30 минут на выгрузку данных из двух систем, сопоставление идентификаторов, проверку расхождений и перенос информации в таблицу. За 20 рабочих дней стоимость такого времени составляет около 30 000 рублей в месяц. Если техническую сверку без потери качества может выполнять специалист со стоимостью часа 600 рублей, затраты составят около 6 000 рублей. Стоимость времени на такую операцию различается в пять раз. При этом оценка существенных расхождений может по-прежнему требовать участия финансового контролера.

Разница в расчете показывает стоимость занятого ресурса; фактическая экономия зависит от того, как компания использует освободившееся время. Поэтому в ходе трансформации необходимо анализировать не только возможность автоматизации, но и уровень квалификации исполнителя. Одни задачи целесообразно автоматизировать, другие передавать на более подходящий уровень, третьи объединять в общие сервисные функции, а некоторые полностью исключать. Такой анализ позволяет одновременно повышать производительность и рациональнее использовать наиболее дорогой человеческий ресурс компании.

Для оценки экономики процесса его необходимо разложить на конкретные операции и связать каждую из них с исполнителем, квалификацией, трудоемкостью, количеством повторений, загрузкой в эквиваленте полной занятости (FTE) и стоимостью. Пока процесс описывается как «финансовый блок обрабатывает платежи», невозможно определить, где именно возникает избыточная нагрузка и какие изменения дадут экономический эффект.

При этом важно различать высвобождение рабочего времени и прямое сокращение затрат. Если десять сотрудников после автоматизации тратят на определенный процесс на 20% меньше времени, это не означает автоматического снижения фонда оплаты труда на 20%. Экономический эффект возникает, если высвободившийся ресурс позволяет сократить будущий найм, перераспределить сотрудников на более приоритетные задачи, объединить функции или полностью отказаться от части работ. Поэтому эффективность трансформации необходимо оценивать не только по сокращению трудоемкости, но и по тому, как компания использует высвободившийся рабочий ресурс.

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

Отдельно необходимо оценивать способность операционной модели поддерживать рост бизнеса без пропорционального увеличения административного персонала. Если компания увеличивает объем операций на 30%, а для их обработки требуется аналогичное увеличение численности бэк-офиса, новая система сама по себе не решила проблему масштабирования. Эффективная операционная модель должна позволять бизнесу расти быстрее, чем увеличивается объем ручного труда.

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

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

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