Мы часто слышим от консультантов, что при внедрении тех или иных систем корпоративного управления необходимо тщательно учитывать особенности бизнеса каждого предприятия и соответствующим образом настраивать функциональность системы. Вендоры, в свою очередь, призывают заказчиков не изобретать велосипед, а в максимальной степени использовать стандартную функциональность продукта, в случае необходимости подстраивая не систему, а свои корпоративные бизнес-процессы. В проекте на Останкинском мясоперерабатывающем комбинате (ОМПК), о котором пойдет речь, подобной поляризации рекомендаций быть не могло попросту потому, что вендор (SAP) и внедренец (SAP Consulting) выступали фактически в одном лице. Целью проекта была автоматизация складской деятельности предприятия, которая оказалась совсем нетривиальной задачей.

Останкинский мясокомбинат, существующий с 1954 г., сегодня является одним из крупнейших в Европе с ежедневным объемом производства более 500 т. Выходу на столь высокие рубежи не в последнюю очередь способствовала гибкость в отношениях с клиентами и работа напрямую с торговыми точками с минимальным привлечением дистрибьюторов. В результате складу приходится обслуживать более 3000 заказчиков, которые имеют 8000 адресов доставки. При этом график доставки определяется клиентом, и все они, как правило, хотят получать продукцию примерно в одно время. Вследствие этого нагрузка на склады в суточном цикле распределяется неравномерно — возникают периоды пиковой активности.

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

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

Как рассказал ИТ-директор ОМПК Михаил Асеев, к моменту начала проекта все основные бизнес-процессы предприятия много лет были автоматизированы с помощь практически самописной программы “Секретарь”, задачи складского модуля выполняла система “КИТ-Логистика”. Она была построена на базе технологий 90-х годов прошлого века, работала крайне нестабильно, требовала постоянного внимания и периодических трудоемких ручных процедур по очистке БД. Разработчики системы были недоступны, а полноценная ее поддержка отсутствовала.

Система плохо масштабировалась и была не способна функционировать в территориально распределенной конфигурации: на каждой из упомянутых площадок существовали отдельные инсталляции, обменивающиеся данными между собой. По сути, был достигнут предел возможной дневной отгрузки через эти системы, больше данных они физически были не в силах обработать. Пожалуй, единственным плюсом предыдущей складской системы “КИТ Логистика” по сравнению с требующей качественного Wi-Fi-покрытия нынешней было то, что она позволяла кэшировать данные на терминалах сбора данных (ТСД) и передавать их в БД, когда появлялась связь. В свете сказанного и с учетом планов по развитию холдинга, повышению объемов производства и открытию новых заводов замена устаревшей системы была неизбежной.

Так уж получилось, что этот проект имеет длинную и сложную историю. Михаил Асеев вспоминает, что первая попытка была предпринята еще в те времена, когда на предприятии не использовалась SAP ERP. И руководство надеялось, что можно, внедрив ERP-систему SAP и интегрировав ее с “КИТ Логистикой”, сохранить хорошо знакомую персоналу старую складскую систему. Попытка завершилась неудачей, поскольку уже на этапе запуска в эксплуатацию выявились проблемы в интерфейсах, которые невозможно было обойти вследствие архитектурных особенностей “КИТ Логистики”. Тогда решили развернуть стандартный модуль SAP WMS в рамках децентрализованного решения на базе SAP ERP. Но и этот проект провалился из-за ошибок в концептуальном проектировании (упор на адресное хранение), негибкости SAP WMS при отходе от указанной концепции и в какой-то степени непрофессионализма команды внедрения. Для третьей попытки к проекту были привлечены консультанты вендора. Совместными усилиями внутренней команды и SAP Consulting удалось объединить SAP ERP и более мощное и функциональное решение SAP EWM (Extended Warehouse Management), входящее в состав логистической системы SAP SCM.

Выбор в пользу EWM был сделан по целому ряду причин. Продукт допускает гибкую организацию смешанного хранения, реализацию широкого спектра стратегий приемки и отгрузки, осуществление комплектования заказа несколькими исполнителями одновременно (очень важно в условиях жестких временных нормативов), поддерживает параллельное ведение двух единиц измерения (шт. и кг) и отслеживание перегрузов/недогрузов одновременно в обеих единицах, позволяет реализовать удобные и производительные сценарии работы с мобильными терминалами сбора данных и считывания штрихкодов.

“Конечно, внедрение не было легкой прогулкой, — сетует Михаил Асеев. — Хотя концепт согласовывался очень долго, демонстрация прототипа позволила владельцам бизнес-процессов и ключевым пользователям получить представление о продукте, помогла четче сформулировать бизнес-требования в терминах SAP EWM. Тем не менее на этапах реализации и интеграционного тестирования нередко выяснялось, что кто-то что-то недосказал, кто-то недопонял. Этап нагрузочного тестирования помог понять, что “размер имеет значение": ряд функций, отлично работавших на малых количествах при интеграционном тестировании, совершенно по иному вели себя на промышленных объемах. В итоге старт проекта задержался на 2,5 мес, но с учетом сложности внедрения на живом производстве без остановки всех бизнес-процессов это неплохой результат”.

Роли в проекте распределялись следующим образом: специалисты SAP Consulting и “Астерос” (отвечала за ERP) разрабатывали концептуальный проект, выполняли настройки и доработки, осуществляли интеграцию со складским оборудованием. Бизнес-аналитики ОМПК, опираясь на глубокое понимание процессов, стали связующим звеном между бизнесом и консультантами, проводили интеграционное тестирование, писали инструкции, обучали и поддерживали пользователей. Проект внедрения условно можно разделить на этапы работ по конфигурированию системы EWM, разработке интерфейсов с внешними системами и оборудованием и повышению эффективности функционирования программно-аппаратного комплекса в моменты пиковой нагрузки. Обязательным условием было четкое соблюдение календарного плана, который учитывал наличие цикличности периодов продаж: “низкий” и “высокий” сезоны требовали различной степени вовлечения ключевых пользователей и руководства проекта.

Непосредственно после развертывания в марте 2013 г. начался период стабилизации решения, который завершился к сентябрю. В это время были выявлены проблемы со скоростью работы, сопровождавшиеся периодическими провалами производительности вплоть до полной недоступности систем. Причин было несколько. В частности, основной парадигмой при концептуальном проектировании было представление всего склада в виде одной ячейки. Однако вскоре выяснилось, что при наборе короба из ячейки считывается весь лежащий в ней запас по единицам обработки, при этом в рамках одной операции генерировались сотни тысяч запросов на чтение к БД. Для решения проблемы пришлось определять виртуальные ячейки и взаимодействовать с ними независимо. Кроме того, в силу особенностей механизма блокировок используемой БД, одновременный доступ к таблицам при параллельной работе нескольких наборщиков с одной ячейкой был невозможен, что негативно сказывалось на скорости работы системы. Тем не менее с помощью настроек в EWM и БД приемлемый результат по производительности был в итоге достигнут.

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

В SAP ERP вводятся заказы от клиентов, поступившие по телефону или e-mail от торговых предприятий и через EDI-каналы от розничных сетей. После этого рассчитывается цена, проверяются кредитный лимит и наличие продукции. Всего есть четыре возможных пункта отгрузки: уже перечисленные заводы и база “Юг” — склад предназначенный для приемки продукции с производственных площадок большими фурами и последующей перегрузки ее в “Газели” для доставки мелким розничным клиентам. Каждый грузополучатель обычно жестко привязан к пункту отгрузки. Если при проверке доступности обнаруживается нехватка продукции в данном пункте, происходит автоматическое создание заказов на перемещение ее с других заводов. После завершения комплектования поставки в EWM происходит отпуск товара, отражающийся в ERP, и выезд машины через весовой контроль.

Итак, цели, которые ставило руководство компании перед началом проекта, достигнуты. Система успешно функционирует. Но можно ли оценить экономический эффект проекта? “К сожалению, нет даже приблизительно ответа на этот вопрос, — признает Михаил Асеев. — Можно утверждать лишь, что внедрение решений SAP позволило информационным технологиям если и не стать драйвером бизнеса, то по крайней мере перестать быть сдерживающим фактором для его развития”.