Беспроблемная закупка аналогов импортных материалов и деталей — острый насущный вопрос для производств. Как свойственно крупным компаниям, в «Северстали» закупкой занимается большая группа людей — около 400 закупщиков и ещё больше так называемых заявителей потребностей. У каждого своя специфика работы: кому‑то подходит одна номенклатура на замену, но не подходит другая. С начала 2022 года каждое подразделение компании пыталось наработать свою базу замен используемых материалов (оригиналов) новыми (аналогами). Разрозненный подход усложнял закупку аналогов для всех участников процесса.

Алексей Бочаров, старший консультант направления «Закупки», рассказывает, как удалось унифицировать подход и автоматизировать работу с аналогами, пусть и с небольшими трудностями на пути.

С чего начать? Конечно, с понимания потребностей, бизнес‑задач и рисков

Для чего конкретно нам нужны аналоги, заменяющие ранее используемые материалы? Как закупать их без риска непоставки и соответствующих ему проблем на производстве (например, простоя оборудования)? Какое техзадание надо поставить IT‑отделу, чтобы команда разработала решения, выполняющие задачи бизнеса? И какие, собственно, это задачи? Пойдём по порядку.

Потребности производства

Источников появления потребности на предприятиях «Северстали» несколько. Это:

• заказы на техническое обслуживание и ремонт оборудования (ТОРО);

• аварийные потребности ТОРО на сетевых графиках;

• инвестиционные потребности на сетевых графиках;

• сбытовые объекты.

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

Задачи бизнеса и IT 

Нам надо:

1. Реализовать для закупщиков функционал по работе с аналогами на основании возникновения необеспеченной потребности. Функционал должен размещаться в справочнике основных записей материалов (ОЗМ) оригинала.

2. Объединить все текущие наработки по подобранным аналогам в единую базу. Использовать базу во всех процессах при планировании потребности.

3. Увеличить количество подобранных аналогов на будущее на основании плановых документов и исторической потребности.

4. Унифицировать процесс подбора и ведения аналогов для всех заявителей.

5. Приоритизировать подбор аналогов к оригиналу в зависимости от критичности в ремонтах и от рисков поставки с точки зрения закупщиков.

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

7. Обеспечить доступ к просмотру существующей базы аналогов, который должен иметь любой сотрудник компании, даже тот, у которого нет учётной записи в SAP (авторизация ADFS).

Риски

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

С точки зрения заявления потребности в SAP должна поменяться процедура: при наличии в ОЗМ оригинала метки «Риск поставки» и при отсутствии запаса позиция резервирования автоматически блокируется для дальнейших шагов по поиску аналогов. В потребности проставляется статус «Никогда», и до принятия решения закупщиком его невозможно изменить. 

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

Решено писать своё ПО для подбора аналогов и согласования их применимости на производстве

Пишем своё! Когда нас это пугало? Мы решили реализовать web‑приложение для заведения пар «оригинал‑аналог» и согласования их применимости в ремонтах. Оно должно быть доступно для просмотра любому сотруднику компании, имеющему табельный номер и доменную учётную запись. Также ПО должно быть интегрировано с ERP‑системой, работающей на S/4 HANA. Именно в нём будет осуществляться процесс взаимодействия закупщика и заявителя, подбор аналогов и согласование применимости. Мы решили назвать ПО просто: «Подбор аналогов».

Функции ПО «Подбор аналогов»:

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

• Согласование применимости пар. Позволяет заявителю потребности согласовать закупку конкретного аналога вместо оригинала для определённого объекта заявления потребности (заказа ТОРО). Либо принять постоянное решение о возможной закупке аналога вместо оригинала для будущих потребностей (так называемый повторяющийся критерий применимости: техническое место, цех, СПП мероприятия ТОРО, СПП бюджета ТОРО, ОЗМ восстановления в заголовке заказа ТОРО).

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

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

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

Как стало выглядеть взаимодействие информационных систем после внедрения ПО «Подбор аналогов»

Были определены основные интеграционные потоки:

Нюансы реализации интеграций

Интеграции 1 и 2 реализовали на уже существующих интерфейсах XI/PI, расширив их на новых получателей на стороне XI.

Интеграция 4 была выполнена по техническим картам с помощью донастройки Z‑IDOC под нового партнёра «ANALOG» (вид партнёра «LS») в транзакции WE20, настройки модели распределения в транзакции BD64 с фильтрацией по 9 балансных единиц (БЕ) для партнёра «ANALOG», а также с настройкой фильтра ненужных сегментов технических карт через транзакцию BD56. Благодаря этому объём данных по техническим картам снизился в 10–20 раз относительно стандартной интеграции для других получателей.

Интеграции 3, 5, 6 реализовали на Odata по следующим причинам:

• скорость и уменьшенный объём получаемых данных в формате JSON вместо XML;

• удобство и простота работы с JSON;

• обмен данными напрямую между двумя системами, без XI/PI;

• невозможность или сложность online‑режима 3 интеграции и вычисления «дельты» по резервированиям, изменённым с момента последней успешной интеграции. Сложность объясняется тем, что резервирование, его текущий статус и обеспечение в системе может зависеть от многих операций в учётной системе: списание запаса к потребности, сторно списания, изменение статуса заказа ТОРО, актуальность прогона ППМ по ОЗМ оригинала, перемещение запаса с одного склада на другой, изменение коэффициента критичности технического места с точки зрения простоев, изменение самого объекта ремонта либо рабочего места в заказе ТОРО.

Конечно, хотелось бы увеличить частоту третьей интеграции с целью получения ещё более актуальной информации в ПО «Подбор аналогов». Но делать можно это не чаще, чем 1 раз в 4 часа из‑за сбора данных по обеспечению из разметки ППМ. Это некий функционал, который по сути массово читает ведомость ППМ по всем ОЗМ (ФМ MD_STOCK_REQUIREMENTS_LIST_API). Затем информация сохраняется в табличку, из которой уже читаются данные по обеспечению каждого актуального резервирования ТОРО. Проект объёмный — 9 балансовых единиц со 111 заводами и около 800 областями ППМ. Поэтому в рабочее время не хотелось нагружать систему такими тяжелыми фоновыми заданиями в условиях большой изменяемости данных, особенно в рабочие дни.

Интеграция 7 была выполнена стандартными инструментами BW. Здесь собиралась отчётность по обеспечению аналогами, а также учитывалась ситуация по статусу контрактования аналогов и по количеству аналогов для оригиналов с рисками поставки.

Интерфейс ПО «Подбор аналогов»

Программное обеспечение имеет два основных режима (экрана) работы:

1. Предназначен для работы закупщиков и технических экспертов ТОРО с парами «оригинал‑аналог».

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

На первом экране отображается информация по: количеству аналогов для оригиналов, статусу согласования, приоритету подбора, критичности для ремонтов. Работа происходит с учётом приоритетов 10–99 и критичности 1–3 (чем меньше число, тем больше приоритет подбора). Таким образом, подбор аналогов максимально необходим для Приоритета = 10 и Критичности =1.

Второй экран подбирается каждому заказчику в зависимости от ролей, выданных в ПО на определённую связку Производство‑Подразделение‑Цех. Так каждому заказчику выдаются только те заказы ТОРО, за которые он отвечает по ролевой модели.

Существует ещё внутренний подэкран согласования, который выводит информацию к конкретной паре «оригинал‑аналог». Там заказчик видит достаточную информацию для согласования или отклонения замены:

• номера ОЗМ;

• краткие и длинные тексты ОЗМ;

• кликабельные ссылки на вложения в MDG к этим ОЗМ;

• использование оригинала в определённых заказах ТОРО, а также на уровне критерия применимости (в нашем случае это техническое место).

После успешного согласования применимости в функционале работы закупщика в заказе ТОРО появляется возможность подмены оригинала аналогом. Просмотр пар и применимостей возможен в отдельной транзакции SAP (это результат работы пятой интеграции).

Заметки о разработке ПО «Подбор аналогов»    

Поначалу нам было сложно определить перечень «рискованных материалов» (не только импортных, но и отечественных), к которым надо подбирать аналоги. Также непросто было понять, как обозначать уровень хранения риска поставки на ОЗМ: по мнению бизнеса, его необходимо хранить на уровне балансовой единицы, а стандарт SAP позволяет хранить только на «основных данных» или «заводских» ракурсах. Для решения этого вопроса мы разработали отдельную транзакцию на основании рекомендаций системы, которая позволяет анализировать риск поставки в разрезе заводов. В основу алгоритма легла аналитика «Производитель» в основной записи материала (импортные производители), аналитика исторических закупок и стран, откуда закупались ОЗМ, а также ручные решения по ОЗМ, в составе которых находятся импортные комплектующие. Большинство ОЗМ, у которых указаны импортные производители, попадает под риски поставки. Также под рисками оказываются ОЗМ с поставками из недружественных и нейтральных стран.

Далее нужно было определить подход к подбору аналогов и приоритизации оригиналов. Он должен быть общим для всех балансовых единиц в объёме проекта, то есть статус подбора аналогов к оригиналу должен отображаться в целом по компании, а не для какой-то определенной БЕ, где возникла потребность. Переход к новому ПО происходил одновременно для 9 БЕ. И так как для одного технического кода группы закупок на разных БЕ закупщики отличаются, то возник закономерный вопрос: кто именно отвечает за подбор аналогов, если закупщиков по конкретной группе закупок несколько, а необходимость подбора отражается для всех, так как по ОЗМ оригинала у них общий статус? В качестве ответа мы просто договорились, что закупщики заходят внутрь первого экрана ПО и по заявленной потребности понимают, к какому производству, подразделению или цеху относится потребность.

Потребовалось реализовать множество вспомогательных интеграций для удобной визуализации на стороне ПО, например: 

• справочник СПП‑элементов и проектов бюджета;

• справочник производств ТОРО;

• справочник подразделений ТОРО;

• справочник цехов ТОРО;

• справочник рабочих мест ТОРО;

• справочник технических мест ТОРО;

• справочник основных данных пользователей;

• расширенный справочник групп закупок с ответственными закупщиками по БЕ;

• таблица управления статусами ОЗМ T141;

• таблица присвоения «Завод‑Область оценки‑БЕ» на основе T001W и T001K.

Чтобы создать ролевую модель по согласованию применимости в ПО, понадобилось привести в порядок бизнес-данные по заказам ТОРО в части наличия заполненных полей производства, подразделения и цеха. Также надо было найти технических экспертов, которые будут ответственны за определённые сочетания производство + подразделение + цех. Это важно, поскольку нельзя заменить оригинал на аналог без того, чтобы заказчик согласовал применимость к конкретному заказу ТОРО или к соответствующему критерию применимости (на будущее). Мы определились, что если по прошествии трёх дней с момента отправки применимости на согласование решение принято не будет, то эта применимость будет считаться просроченной. 

Ещё одна проблема заключалась в том, что технический подход к подмене ОЗМ в потребности ТОРО подразумевает изменение существующей позиции резервирования. Из-за этого мы теряем исторические системные данные о том, что оригинал был необходим в ремонтах. В подменённой потребности мы сразу видим аналог, а изменение кода ОЗМ видно только в истории изменений заказа ТОРО. Более правильный подход заключался бы в том, чтобы создавать новую позицию резервирования, но это могло негативно повлиять на другую часть решения с точки зрения архитектуры: пришлось бы хранить и протаскивать связь старой позиции резервирования и новой; искусственно «завышалась» бы потребность в заказах ТОРО, как будто заказчик планировал и оригинал и аналог одновременно; пришлось бы придумывать какие-то статусы на компонентах заказа ТОРО, запрещающие навсегда работу в заказе со старыми позициями резервирования, до подмены на аналог.

Функционал подмены ОЗМ в заказе ТОРО выводил много ошибок расширений ОЗМ аналога, поэтому без автовыравнивания организационных уровней оригинала и аналога в SAP MDG работу закупщика представить тяжело. Самой типичной проблемой было отсутствие расширения на:

• завод и склад, 

• вид оценки, 

• склад СУС. 

Решалась эта проблема как для новых пар, которые будут появляться после внедрения ПО «Подбор аналогов», так и для существующих ~7000 пар, для которых нужно было выравнивать организационные уровни ОЗМ и расширения аналогов до старта. Без работающей второй интеграции постоянно требовалось бы дорасширять аналоги.

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

• если ОЗМ оригинала и ОЗМ аналога имеют разные группы закупок, возникает риск появления потребности без ведома закупщика аналога. Мы сделали так, что по факту согласования одним закупщиком-1, другому закупщику-2 приходит заявка на аналог из ППМ по «чужому» согласованию закущика-1. При этой особой ситуации выводится предупреждение, предполагается взаимодействие двух закупщиков и совместное принятие решения;

• если ОЗМ оригинала и ОЗМ аналога значительно отличаются по стоимости, то появляется риск превышения бюджета заказа ТОРО. Было принято решение, что допустимое отклонение по цене это 20%, при большем отклонении необходимо взаимодействие с заказчиком для принятия итогового решения;

• если ОЗМ оригинала и ОЗМ аналога имеют разные базовые единицы измерения (БЕИ), то для его подмены важно заполнить коэффициент пересчёта, который в ПО хранится в виде дроби = Числитель/Знаменатель (по аналогии с хранением пересчетов для альтернативных единиц измерения в ОЗМ SAP). Отметим, что заполнение коэффициента пересчёта в некоторых ситуациях — нетривиальная задача. Поэтому при загрузке пар «оригинал‑аналог» уделялось много времени проверке коэффициентов пересчета бизнесом, проводились коммуникации по корректному заполнению шаблона для загрузки, особенно по тарной продукции или с минимальными размерами партии в ППМ.

Реализация интерфейсов интеграций осложнилась наличием полей с функциональными модулями преобразований в SAP (например, CONVERSION_EXIT_TPLNR_OUTPUT для технических мест, CONVERSION_EXIT_ABPSP_OUTPUT для СПП-элементов). После реализации пришлось переделывать такие поля на хранение в формате String с последующими проверками на корректность данных внутри сервиса. В случае изначально некорректно поданных данных (например, отсутствующее техническое место или СПП) сервис Odata «падает» с одной общей ошибкой вызова, несмотря на то, что строк могло прийти 100, а ошибка — только по одной строке применимости.

Понадобилось создать детальные логи на стороне SAP для каждой совершённой бизнес-операции: 

• первоначальное заявление потребности;

• отправка пары и/или применимости на согласование в ПО;

• отправка уведомлений участникам процесса;

• принятие решений о применимости;

• обновление справочника пар и применимостей;

• сохранение решения закупщика о замене;

• осуществление подмены ОЗМ в заказе ТОРО;

• прогон ППМ по аналогу.

Для запроса и обновления данных мы решили использовать открытый веб‑протокол Odata (GET‑ и POST‑методы в SAP). Вот общие настройки для всех интеграций Odata:

• Транзакция /IWFND/APPS_LOG — логи запусков сервиса по объекту '/IWFND/'.

• Транзакция /IWFND/STATS — статистика запусков сервисов, типа запросов, всевозможные времена обработки запросов, количество получаемых или передаваемых строк, объёмы данных.

• Транзакция SEGW — настройка полей сервиса, сущностей, активация артефактов для обработки данных. Расширение Data Provider Extension Class — класс /IWBEP/IF_MGW_APPL_SRV_RUNTIME, метод — CREATE_DEEP_ENTITY.

• Транзакция /IWFND/ERROR_LOG — логи ошибочных запусков на уровне запуска сервиса.

• Транзакция /IWFND/GW_CLIENT — локальное тестирование сервиса. Без этой транзакции невозможно было бы локально тестировать разработанные сервисы на стороне SAP.

• Транзакция /IWFND/MAINT_SERVICE — активация и ведение сервисов, настройка ICF‑узла (SICF).

• Транзакция /IWFND/TRACES — транзакция трассировки запусков сервисов. Аналогично ST01 можно включить для конкретного пользователя и префикса ссылки.

• Транзакция /IWFND/GLOBAL_CONFIG — транзакция управления параметрами хранения статистики, логов и трассировок (в днях).

Нельзя не отметить некоторые архитектурные моменты в решении, которые были приняты за основу и оказались абсолютно верны с точки зрения работы бизнеса, хранения и обработки данных:

• справочник пар «оригинал‑аналог» имеет «односторонний» характер, то есть, если ОЗМ1 является оригиналом, а ОЗМ2 — аналогом, то в ПО добавляется пара ОЗМ1-ОЗМ2. Наличие такой пары не означает, что ОЗМ1 является аналогом для ОЗМ2;

• не работает принцип транзитивности для пар, то есть наличие двух пар ОЗМ1-ОЗМ2 и ОЗМ2-ОЗМ3 не означает, что ОЗМ1 и ОЗМ3 являются парой между собой. Если это так, необходимо добавлять отдельную строчку в справочник;

• не работает принцип наследования через оригинал, то есть при наличии двух пар ОЗМ1-ОЗМ2 и ОЗМ1-ОЗМ3 нельзя говорить о том, что ОЗМ2 и ОЗМ3 между собой являются парой.

Мы своевременно проработали необходимость ведения коэффициента пересчёта для пары «оригинал‑аналог» (около 600 «спорных» пар). Хорошо, что мы решили хранить его в виде дроби. Например, если берем коэффициент пересчета 1/3, и храним его в 2 полях «Числитель» и «Знаменатель», повышается точность вычисления. При переводе 6 штук оригинала * 1/3 получается ровно 2шт аналога, но если в ПО мы бы хранили какое‑то конечное значение с точностью до 8 знаков после запятой — 0,33333333, при переводе 6 штук оригинала в аналог получалось бы число 1,99999998, и пришлось бы писать отдельную логику округлений расчетов в большую сторону относительно размерности единицы измерения.

Также мы разработали методологию ведения полей «Числитель» и «Знаменатель» в ситуациях, когда отличается базовая единица измерения или тара, либо указан минимальный размер партии в ОЗМ оригинала или аналога.

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

В программе практически все интеграции выполняются в режиме online, то есть данные в ПО «Подбор аналогов» всегда актуальны.

Результаты внедрения ПО для закупки материалов‑аналогов в SAP

За 11 месяцев разработки мы решили все поставленные задачи по реализации ПО «Подбор аналогов» и максимально покрыли основные потребности бизнеса. Особенно удачным было решение использовать Odata, поскольку по сравнению с работой через XI/PI скорость интеграции увеличилась, а объём передаваемых данных снизился.

Некоторые показатели ПО «Подбор аналогов», которые мы получили за 1,5 месяца его работы в продуктивной среде:

• более 5500 пользователей;

• более 200 новых пар аналогов;

• более 150 решений по применимостям;

• более 10 проведённых замен на аналог.

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

Были достигнуты следующие экономические эффекты:

• снижение транзакционности сотрудников закупок на поиск аналогов и их согласование с заказчиками (высвобождение ~10 FTE);

• ценовой эффект от перехода на аналоги ~1% от суммы закупок за год;

• повышение своевременности обеспечения, оптимизация запасов компании.

В заключение, задача была интересна, поскольку позволила подразделению IT ещё глубже погрузиться в проблему заявления потребности заказчиками и её обеспечения закупщиками, понять важность реализации инструмента по аналогам. И конечно, ПО «Подбор аналогов» продолжает развиваться. Задавайте ваши вопросы в комментариях, пожалуйста.