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

Елена Николенко, Axenix
Елена Николенко, ведущий специалист по внедрению программных решений Axenix

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

Многие из этих механизмов воспринимались сотрудниками как «естественная» часть процесса. Вплоть до момента локализации ИТ-ландшафта мало кто задумывался, насколько большой объем операционной логики был фактически скрыт внутри ERP. Именно это стало главным вызовом проекта.

Почему типовая «1С:ERP» требовала доработки

Типовая конфигурация «1С:ERP» предполагает участие сотрудников в пошаговом ведении заказов. Таким образом менеджерам по продажам пришлось бы вручную вводить каждый из 500–1000 ежедневных заказов и дальше проводить их по системе, а именно:

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

 

После демонстрации типового продукта у заказчика возник ряд сомнений:

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

Карта функциональных разрывов

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

К работе подключили три стороны: бизнес-команда расставляла приоритеты автоматизации, команда внедрения 1С искала способы воспроизвести нужные механизмы в новой платформе, а методолог описывал алгоритмы, правила и исключения старой системы — те самые, что давно превратились для пользователей в «черный ящик».

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

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

Как строили автоматизацию в «1С:ERP»

Целевой сценарий был сформулирован так же, как в прошлой системе: после поступления заказа через EDI вся дальнейшая обработка должна идти в «1С:ERP» без участия менеджеров по продажам.

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

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

Параллельно настроили интеграцию с WMS (системой управления склада) удалённого логистического центра: сформированный расходный ордер «1С:ERP» автоматически уходил в складскую систему как распоряжение на отгрузку. При этом цепочка автоматизации не заканчивалась на складе. После подтверждения отгрузки со стороны WMS система автоматически формировала документы реализации и счета-фактуры по фактически отгруженным позициям, а затем отправляла клиенту УПД через ЭДО.

По сути, поверх типовой «1С:ERP» был выстроен дополнительный слой бизнес-логики, который позволил сохранить привычный уровень автоматизации.

После запуска

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

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

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

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

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

Лучшей оценкой такой работы становится вопрос сотрудников после запуска: «А что, уже все?».