Одним из базовых инструментов Lean является картирование потока создание ценности (КПСЦ). Однако, на практике доля пользователей Lean занимается картированием процессов, а не потока. Какова эта доля – вопрос спорный, по личному опыту – это большинство. Рассмотрим здесь, в данной статье:
- в чем же разница между картированием процесса и потока, и какие последствия влечет за собой разночтение методики КПСЦ; - как идентифицировать потоки; - таблицу параметров производственных операций потока для семейства продуктов, как пример.
Итак, в чем разница между потоком и процессом и какая основная ошибка допускается при выборе объекта для картирования?
Потоком создания ценности мы называем совокупность всех процессов и операций, создающих и преобразующих наш продукт. Когда мы говорим о продукте, то имеем ввиду тот продукт, который попадает к потребителю, который платит компании деньги. Это внешний, «конечный» потребитель. Возможно есть еще более «конечные» потребители, в том случае, когда компания отгружает продукцию на склад (в магазин), а уже оттуда осуществляется сбыт продукции физическим лицам (покупателям).
Поток создания ценности – это все этапы создания продукта от заказа (спроса) потребителя до доставки и послепродажного обслуживания. В потоке мы рассматриваем множество процессов, связанных с физическим преобразованием продукта, а также обработкой информации.
Картирование потока – это схематичное отображение всех этапов, это определение и измерение всех необходимых показателей, позволяющих судить нам о текущем состоянии потока, о наличии в потоке отклонений. А также, определять цели, целевые показатели для оптимизации и план мероприятий. Т.е, если Вы производите насосы, то карта потока будет включать в себя этапы конструкторско-технологической подготовки, обеспечения материалами, планирования, производства всех комплектующих, сборки, доставки и в некоторых случаях гарантийного обслуживания.
А какие потоки чаще всего картирует большинство? Процесс производства вала или корпуса насоса, при этом данный вал или корпус – лишь часть сборной конструкции. Процесс заключения договора. Процесс технологической подготовки. Процесс технического обслуживания оборудования. И еще более режет слух: карта потока создания ценности ремонта оборудования. Картировать отдельные процессы можно. Но тогда и называть это надо соответственно: не поток, а процесс.
И понимать, что такое применение методики приводит к ряду последствий:
1.Улучшения процессов не приносят должного эффекта для компании. Ведь у потока всегда есть показатели, которые влияют на общую экономику компании. К основным показателям относятся:
- время выполнения заказа;
- своевременность доставки;
- время такта;
- показатели качества.
Оптимизируя весь поток, можно влиять на удовлетворенность потребителя, на уровень спроса, на операционную прибыль и рентабельность. Подобные эффекты весьма сомнительны в рамках оптимизации отдельного процесса. Да, уменьшили время выполнения процесса одной детали, навели порядок и убрали лишние перемещения на производстве. Стали делать одну из деталей быстрее, но как это повлияло на конечного потребителя? И удалось ли повлиять на себестоимость продукта?
2.Многие инструменты Lean не могут быть в полной степени применены к отдельным процессам. Так, нецелесообразно рассчитывать объем супермаркета для одной позиции сборочной единицы. Слегка нелепым становится применение стандартизированной работы. Да, можно исключить потери, описать операции, выровнять время цикла на операциях в соответствии времени такта. Но, из какой потребности это время такта рассчитано, если весь поток не рассматривался. В большинстве случаев улучшения одного процесса от применения инструментов lean закончатся там, где начнутся проблемы другого.
3. Формируется не верное видение потока. Монументы и разрывы потока остаются без внимания. Отсутствует понимание того, что потоком возможно и необходимо управлять непрерывно. Не только в проектах оптимизации. То есть необходимо переводить управление потоком на операционный уровень. Формировать команду потока, ячейки потока и серьезно трансформировать оргструктуру компании, изменять ключевые показатели эффективности во всей компании
Возможно ли все это реализовать в ходе одного проекта, на пилотном потоке, длительностью в полгода? Конечно, нет. Возможно, желание быстрых результатов заставляет компании заниматься картированием процессов, или попытка получить знания и навыки.
Но, даже, в учебных целях картирование отдельного процесса – это лишь возможность получить опыт сбора данных на отдельных операциях, изучить значки и способы отображения схемы потока на бумаге, научиться искать потери. Понимание потока, потоковое мышление в таком обучении и в таком проекте не сформируются.
Как идентифицировать потоки компании, и какие из них оптимизировать в первую очередь?
Прежде всего, необходимо сфокусировать внимание на продукты компании. И выделить из них те, оптимизация которых наиболее необходима, которые в общей продуктовой матрице компании:
А) пользуются наибольшим спросом потребителя;
Б) составляют максимальную долю в общей прибыли;
В) минимизация издержек по данным продуктам продиктована бизнес-моделью компании;
Г) есть тенденция к росту спроса на данный продукт, жизненный цикл продукта не подходит к его окончанию
Продукты следует, также, проанализировать в разрезе технологии и времени цикла производства, для того, чтобы объединить их в семейства, если потребуется. В семейства принято объединять продукты, которые:
А) в процессе производства проходят одни и те же этапы обработки (технологические операции и оборудование).
В) время цикла производства разных продуктов не сильно отличается. Разница +/- 20% является допустимой
В одном семействе необходимо будет иметь все расчетные параметры для каждого типа изделия. Поэтому, строить карту потока для семейства продуктов дело весьма хлопотное. Общая схема потока будет единая, а вот данных на некоторых этапах будет целый перечень.
Например, таблица производственных операций потока может иметь вид (рис1). Если в семейство выделено три вида продуктов, то время цикла и время переналадки необходимо замерять для каждого из них. Типов переналадок, также, будет три: переналадка с продукта А на продукт В, с продукта А на С, и с В на С. Иные простои оборудования (поломки), по возможности, также необходимо будет проанализировать в разрезе разных продуктов.
Если, корреляции между поломками и продуктами не выявлено, то можно рассчитать и использовать один общий показатель. Это всего лишь пример. Некоторые параметры в таблице могут быть изменены. Это зависит от принятых, в потоке, показателей. В некоторых случаях данные показателей дефектов, или простоев оборудования могут попросту отсутствовать, это типично для российских предприятий. Тогда в процессе построения карты потока необходимо выстроить сбор данных. Разработать чек-листы, порядок сбора и расчета. Определить исполнителей и ответственных за сбор данных.
Рисунок 1.
Таким образом, получая и применяя знания, неважно у консультантов, или из книг, задавайте себе вопрос: что же Вы картируете? Поток, или процесс?
Однако, есть о чем подискутировать.
По статье получается, что разница между потоком и процессом только в масштабе?
Любой процесс можно представить в виде потока создания ценности. И процесс ремонта в том числе.
Ты допускаешь возможность картирования процесса, но отказываешься присвоить процессу статус потока. А ведь он есть.
И при построении VSM можно выявить насколько грамотно process mapping сделан.
Т.е. VSM в данном случае как индикатор стоит ли изменять процесс или нет.
А process mapping уже покажет что конкретно можно изменить в процессе.
Это я имел ввиду.
Есть система, есть подсистемы, изменение в одной подсистеме, может как улучшить, так и ухудшить работу других подсистем и системы в целом.
У процесса производства того же вала есть конечный пользователь, пусть это даже последующая операция, например, сборка.
Да и сам процесс изготовления вала есть ни что иное, как поток.
Автор упустила, на мой взгляд, то, что ключевым словом является создание ценности, а не особенность процесса.
КПСЦ для изготовления вала тоже можно составить, весь вопрос насколько нужно мельчить и углубляться в процессы.
Есть система, есть подсистемы, изменение в одной подсистеме, может как улучшить, так и ухудшить работу других подсистем и системы в целом.
Построение карт для процессов возможно, но даже близко не так эффективно, как выстраивание для всего потока.
И у потока есть вполне четкое определение, не надо подменять понятия поток и процесс. Любой поток - это процесс, но не любой процесс поток.
Вы упомянули, что не каждый процесс является потоком.
Если не трудно, поделитесь примером именно по процессам.
Какой процесс не стоит рассматривать как поток и почему
Следующая история, почему начинается с заявки клиента. Чтобы клиент был потоком доволен (читай нес туда денюжку), надо требования его удовлетворять. А одним из первейших требований клиента обычно бывает время выполнения заказа. Вот мы и приходим к тому, что поток вытягивается и оптимизируется, начиная с этой точки. Все остальное - куски потока, которые не позволяют добиться главной цели - удовлетворения клиента и повышения маржинальности потока.
Кстати, на нашем предприятии есть процессы, когда один "внутренний клиент" платит другому "внутреннему клиенту" за изготовленные компоненты.
Смотрите, у нас глобальная компания с производственными площадками в разных странах.
По какой-то причине часть компонентов производится на заводе в одной стране, и затем поставляется на другой завод, где выпускается готовый продукт и отгружается клиенту.
Если одна площадка ставит нам меньший приоритет, мы не можем удовлетворить внешнего клиента
Как результат - backorders
Ну как платит, постфактум с бюджета завода списывают деньги
И да, запросто может получиться, что основной заказ делает один поток, а какую-нибудь булавку другой. Это не противоречит потоковой оптимизации. Просто внимательно надо будет устанавливать целевки для потоков.
В целом, вы все правильно сказали, что практика и реальность определяет нюансы. Но базовая методология никуда не девается и все еще универсальна.