Вот уж не знаю была ли навеяна публикация в блоге Эли Шрагенхайма процессом подготовки к конференции 25-26 мая 2017 года в Петербурге (подробности здесь: http://eventvmscg.ru) или нет, но она очень совпадает с тем, о чем я собираюсь на конференции рассказать.
Все привыкли к историям успеха и рассказам о том, какие классные результаты были получены. Однако, мало кто рассказывает о том, какие трудности были на пути к этому результату. По каким граблям скакали, как их инвентаризировали и нумеровали.
Я в своем выступлении намерен поделиться собственным опытом освоения решений Теории ограничений от обучения через внедрения. Что было пропущено мимо ушей, какие пробелы пришлось заполнять на практике, как «изобретался велосипед» и какие нестандартные решения были разработаны, исходя из общих принципов и стандартных решений ТОС. Как справлялись с управлением запасами при длинных сроках пополнения? Как работать с управлением буфером в смешанных средах? Как выявляли «скрытые» предпосылки, лежащие в основе решений ТОС. И «скрытые» они совсем не потому, что их от нас скрывали, просто это — «кислород», который забывают при построении логики, как очевидное условие. Для тех, кто разрабатывал решения они очевидны, а вот для того, кто только начинает осваивать — далеко не всегда.
В общем, если бы у меня была эта публикация в 2011 году, мне было бы, наверное, намного легче, и ошибок было бы заметно меньше.
Вот так, нежданно — негаданно Эли опубликовал статью в поддержку темы моего доклада на конференции :)
Как обычно, ссылка на оригинал и картинка из поста автора.
Ваш Дмитрий Егоров
Я думаю, что ни одно решение ТОС не находится на той стадии, когда можно просто следовать рецепту его внедрения. Конечно, для Упрощенного Барабана-Буфера-Каната (SDBR), Производства для наличия (МТА), Управления запасами (Replenishment или PTA/DTA) и Критической цепи (CCPM) есть рецепты, но в реальности слишком часто существует необходимость от него отклониться.
Существует две категории базовых, иногда неочевидных, предпосылок ТОС, лежащих в основе рецепта успешных внедрений[i].
- Ошибочные предпосылки о необходимых условиях, описывающих реальность организации.
- Ошибочные предпосылки о поведении клиентов этой организации.
Все решения ТОС имеют несколько предпосылок о необходимых условиях, которые определяют границы, в рамках которых решение эффективно. Стоит упустить одну из необходимых предпосылок, и при внедрении возникают проблемы. Вот некоторые примеры:
Основная предпосылка Упрощенного Барабан-Буфер-Канат: Общая продолжительность технологического времени (touch—time[ii]) менее чем 10% от общего производственного цикла (production lead—time). Если эта предпосылка не соответствует действительности, то возникает проблема с управлением буфером, когда попадание в красную зону буфера не оставляет достаточно времени для «экспедирования» заказа. В таком случае требуются определенные изменения в механизме управления буфером, учитывая, что технологическое время лежит в основе расчета сроков изготовления заказа. Когда технологическое время составляет 50% или более, то проблема больше, чем просто управление буфером. В такой среде или очень много простаивающих мощностей или исполнение заказов необходимо планировать по методу Критической цепи.
Замечание: Технологическое время также включает в себя время необходимого ожидания, например, сушку, даже если не требуется мощности какого-либо ресурса.
Базовая предпосылка SDBR: С момента запуска материала в производство до момента завершения заказа, он находится под полным контролем организации. Это не так, если один или более процессов выполняются на аутсорсинге. Контрагент обычно не привержен следованию приоритетам, которые устанавливаются управлением буфером. К контрагенту уходит и возвращается партия целиком. В некотором смысле это похоже на ситуацию с длительным технологическим временем, но проблемы, которые возникают, нам не подконтрольны. Эта ситуация требует защиты промежуточной даты готовности, когда заказ должен быть отправлен контрагенту. Это означает, что нам нужны вплотную состыкованные буферы, один до момента отправки поставщику, и второй покрывающий процесс до момента завершения заказа.
Общая предпосылка ТОС для производственных компаний: Запуск заказа в производство как можно раньше является общей практикой. Был поразительный случай, когда это почти автоматическое предположение оказалось ошибочным! Завод было очень аккуратным[iii], на самом деле: слишком аккуратным, в запуске заказов в производство, что давало очень низкий уровень незавершенного производства на всем заводе. Можете представить, что произошло, когда продолжительность производственного цикла сократили вдвое и не разрешали до этого срока запускать заказы в производство?
Базовая предпосылка CCPM: Проект приносит больше дохода при быстром завершении и большие убытки при медленном исполнении. Если эта предпосылка неверна, то вся концепция «критической цепи» (или критического пути) утрачивает свое положительное действие. Хотя всегда верно, что быстрое завершение проекта – ценно, а опоздания причиняют некоторый ущерб, важный вопрос: действительно ли ценность быстрого завершения и убытки от задержки таковы, чтобы организация была готова вкладывать усилия и деньги в быстрое завершение проекта! Причина, по которой концепция критической цепи в производстве мало известна, в том, что ценность быстрого исполнения заказов меньше, чем поддержание высокой производительности[iv] дорогостоящих ресурсов. Когда некоторые ресурсы сильно загружены, задачи вынуждены ждать, когда такой ресурс освободится. ТОС ставит под сомнение ценность производительности для не-ограничений, но не подвергает сомнению концепцию ожидания заказами освобождения загруженных ресурсов, если, конечно, речь идет об ограничении. Таким образом, в производстве производственный цикл значительно длиннее, чем технологическое время, тогда как в проектной среде предпринимаются специальные усилия, чтобы избежать простоя в проекте. Понимание, что быстрое окончание является критически важным, должно быть частью определения «проекта», который должен планироваться методом критической цепи.
Общая предпосылка CCPM: Профессионалы склонны завышать длительность выполнения работ, чтобы всегда завершать заказ в срок. Эта предпосылка может быть ошибочной в области разработки программного обеспечения и сложных технологических компаниях, где профессионалы не обеспокоены завершением в срок, а заинтересованы получить зеленый свет разработке чего-нибудь нового и захватывающего. Для достижения этой цели они могут намеренно сокращать оценку времени, необходимого для выполнения работы! Сокращение вполовину такой оценки времени – большая ошибка!
Предпосылка ТОС в области дистрибуции: Решение ТОС значительно снизит уровень запасов. Это обычные ожидания, и иногда успешность внедрения оценивается объемом снижения запасов. Подлинная цель решения ТОС – это обеспечить высокий уровень наличия. Чаще всего попытки сделать это без применения решений ТОС заканчиваются слишком большими запасами. Поэтому, чаще всего ожидания оправдываются. Но, если в соответствии с моделью ТОС поддерживается высокий уровень наличия для медленно оборачиваемых товаров, то необходимый уровень запасом может оказаться выше, чем текущий. Должна ли организация быть привержена поддержанию высокого уровня наличия медленно оборачивающихся товаров? Этот вопрос приводит нас ко второй категории ошибочных предпосылок.
Вот примеры неправильного понимания клиентов организации.
Обычная предпосылка производства и дистрибуции «для наличия»: рынок страдает от частого отсутствия всех видов товара. Вот два следствия, проистекающих из этой предпосылки.
- Обеспечивается наличие всех товаров, включая медленно оборачивающиеся, которые для поддержания наличия требуют больших буферов запаса, даже когда клиенты готовы какое-то время ожидать доставки. Связанная проблема – это предложение наличия товаров с нестабильной поставкой.
- Всем клиентам нравится предложение высокого уровня наличия. Что же, прекрасное наличие — это всегда хорошо, но:
Клиенты действительно страдают от отсутствия наличия?
Часто клиенты действительно страдают, и выгодно предложить отличную надежность, на которую можно положиться. Но иногда, отсутствующие товары имеют очевидные замены, и ущерб – минимален. В других случаях клиенты имеют достаточные запасы и не беспокоятся о кратковременном отсутствии наличия. Если ценность для клиента невысока, то обеспечение наличия просто «мило». Например, предложение наличия для оптовиков, которые основывают свое конкурентное преимущество на низких ценах и не предлагают наличия конкретных товаров, обречено на провал.
Скрытая предпосылка в CCPM: Первоначальная дата завершения проекта, которая важна для клиента, не меняется. В CCPM важный принцип планирования – это сохранение неизменности плана. Однако, дата завершения может сдвигаться на более позднее время из-за других потребностей клиента. Когда это случается, то это не добавляет ценности завершению проекта в первоначальный срок. Попадание проекта в красное, если клиент легко может подождать, создает ненужное давление и напряжение. Это может также заставить руководителей проекта сомневаться в управлении буфером, если буфер показывает, что проект в красном, но они прекрасно знают, что это не так. Если изменение даты завершения невелико, то буфер проекта может увеличиться, снижая давление на отложенные цепи. Если изменение значительно, то рекомендуется перепланирование. Главное: почаще проверять с клиентом – в силах ли первоначальная дата окончания.
Мы все делаем ошибки. На своих ошибках нам нужно учиться, а лучше – учиться на чужих ошибках. Главный урок, извлекаемых из ошибок, — это способность обобщения частных случаев таки образом, что оно становится новым решением. Меня беспокоит, что большинство кейсов, презентованных в TOCICO, используют обычный подход: демонстрируют успешные результаты, нераскрывая ошибок и препятствий по ходу внедрения, как будто стыдясь ошибок, и таким образом скрывая достоинство выявления и устранения ошибок. Я помню одну великолепную презентацию Канадской CMS group, где было рассказано об уроках, извлеченных из ошибок при внедрении. Очевидно, после обретения нового понимания, внедрение закончилось хорошо. Я думаю, что мы все должны извлекать уроки из ошибок, сделанных как нами, так и другими.
[i] Так в тексте, хотя ниже в списке скорее категории, объясняющие не успешность внедрения. – прим. переводчика
[ii] touch-time – в российской практике нет термина, который бы полностью соответствовал значению термина тач-тайм – времени, когда с заказом/продуктом, что либо делают. Технологическое время – это самое близкое по смыслу понятие. – прим. переводчика
[iii] В тексте «careful» — осторожный, бережливый, аккуратный – прим. переводчика
[iv] В тексте «efficiency» — экономичность, которая часто переводится как эффективность. Обычно: выработка на единицу ресурса. – прим. переводчика
