Опыт использования KANBAN в бизнес-процессе подготовки материалов для производства Александр Груздев

Функциональная область: Логистика, Производство, ТОРО / Logistics Ролевое назначение: SAP Консультант / Consultant Ключевые слова: SAP ERP, Демонстрация решений

Александр Груздев (Alexander Gruzdev) – руководитель группы «Практика SAP – Логистика» в компании ALPE Consulting. Более пяти лет занимается внедрением SAP в российских и зарубежных компаниях. Является экс-пертом в области логистики (управление запасами, закупки, сбыт, производство, техническое обслуживание и ремонт оборудования, управление складами). Проходил обучение в британском учебном центре SAP в Лондоне и является сертифицированным консультантом по планированию и управлению производством.

На одном из проектов нашей компании для планирования и учета производства использовалась функциональность системы SAP – «серийное производство» (PP-REM). Использование функциональности «серийное производство» является стандартом для отрасли Automotive. Наш клиент принадлежал именно к этой отрасли.

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

Большое количество обсуждений с ключевыми пользователями вызвала реализованная в системе SAP логика процесса подготовки материалов для производства (material staging). Функциональность «серийное производство» по умолчанию предполагает использование ведомости подготовки материалов (pull list). (рис.1)

Рис. 1 Ведомость подготовки материалов

Однако при использовании данной ведомости основанием для пополнения склада производства являются созданные в системе плановые заказы. Количество материалов для перемещения со склада сырья на производственный склад определяется в системе автоматически, исходя из объема выборки плановых заказов (например, за смену или сутки). Но у клиента уже был отработанный (вне системы) бизнес-процесс пополнения склада, основанный на бумажных картах Канбан. Таким образом, основанием для перемещения материалов являлся не план производства, а пустота контейнера с комплектующими.

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

Первой альтернативой стандартному процессу было использование ручного перемещения запаса (311 видом движения - рис.2). Такое движение, по замыслу, могло совершаться в момент наполнения контейнера Канбан на складе сырья и его отправке в производство. Преимуществом такого способа была, разумеется, его крайняя простота, в том числе, простота пользовательского интерфейса. С другой стороны, часть процесса (генерация потребности на перемещение) происходила бы вне системы. Также, в перспективе клиент планировал использование штрих-кодирования для подготовки материалов. При использовании данного способа потребовался бы значительный объем разработок.

Рис. 2 Перемещение запаса

В качестве третьего варианта реализации процесса (позднее принятого клиентом) был предложен стандартный функционал управления по событию (event-driven) Канбан в SAP ERP. Основным преимуществом такого рода функциональности является полное соответствие процесса в системе фактическому процессу на предприятии (как упоминалось выше, использовались бумажные карты Канбан). Также использование функциональности Канбан обеспечивало наглядность процесса как для пользователей производства, так и для пользователей склада – график Канбан (Kanban board) в графическом режиме показывает статус контейнеров. (рис.3)

Рис. 3 График Канбан

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

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

Во-первых, требуется настройка стратегии пополнения запаса (транзакция OM13), которая выполняется на уровне завода. В простейшем случае (без использования СУС и штрих-кодирования) настройка выглядит следующим образом (рис.4).

Рис. 4 Стратегия пополнения запаса

Также на уровне завода необходимо создать область производственного обеспечения (supply area) – транзакция PK06 (рис.5)

.

Рис. 5 Создание области производственного обеспечения

В качестве основных данных для работы Канбан необходимо создавать запись цикла регулирования (control cycle) для каждого материала, перемещаемого при помощи Канбан (рис.6).

Рис. 6 Создание области производственного обеспечения

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

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