Фокус на главном. ТОС в управлении развитием, производством, запасами

Типичные ошибки практиков в хорошо известных решениях TOC Я думаю, что ни одно из решений TOC не является готовым рецептом для внедрения. Конечно, есть рецепты для Упрощенного барабана-буфер-каната (SDBR), производства для обеспечения наличия (MTA), пополнения запасов и Критической цепи (CCPM), но слишком часто в действительности приходится отклоняться от рецепта. Есть две различные категории основных (иногда скрытых) исходных посылок TOC в основе рецепта для успешного внедрения: 1. Неверные необходимые исходные посылки о текущей реальности в этой организации. 2. Неверные исходные посылки о клиентах этой организации. Все приложения ТОС имеют ряд необходимых допущений, которые определяют границы, в которых применение ТОС будет эффективным. Вот некоторые примеры, в которых не заметили, что одна необходимая исходная посылка неверна, что вполне логично вызвало проблемы в процессе внедрения. https://tocpeople.com/2017/02/tipichnye-oshibki-praktikov/

Как точно определить, почему внедрённый метод не работает Когда внедрённый метод (Лин, Канбан, OKR, «шесть сигм») не даёт результата, обычно винят сопротивление людей или нехватку обучения. Почти всегда это неверно: настоящая причина лежит на уровне предположений, и её можно назвать за несколько вопросов. Сначала - три ложных диагноза Их называют чаще всего, и все три уводят в сторону. Сопротивление — это симптом, а не причина. Люди разумно действуют в рамках старых предположений, и пока предположения те же, поведение не изменится. «Не хватило обучения». Обучили инструменту, но не сменили мышление - метод и не мог заработать. «У нас особая отрасль». Удобное объяснение, которое закрывает разговор о настоящей причине. Ставим точный диагноз. Четыре вопроса по порядку У каждого метода есть две группы предположений: те, что он рассчитан преодолеть (болезнь, под которую он создан), и те, на которых он сам стоит. Проверьте по очереди и остановитесь на первом «нет». 1. Метод вообще под вашу болезнь? Возьмите предположения, которые метод призван снять. Узнаёте в них свою компанию? Если нет - вы лечили не ту болезнь, дальше можно не искать. 2. Сменились предположения или только инструменты? Доска висит, церемонии идут, пояса обучены - а думают по-старому. Если новые предположения не стали реальностью, это карго-культ: форма без сути. 3. Предположения сменились в практике или только на словах? На сессии все согласились - но изменились ли правила, показатели, ритуалы? Если нет, через несколько месяцев компания откатывается к привычному. Предположение держится контекстом, а не словами. 4. Нет ли встречного предположения, которое всё гасит? Метод требует одного, а другое правило компании требует обратного. Классика: метод говорит «причина в системе, а не в человеке», но людей продолжают ранжировать и штрафовать по показателям. Пока встречное предположение живо, метод буксует. Главное Точный вопрос звучит не «почему метод не работает», а «какое предположение должно было смениться - и сменилось ли оно на самом деле». Как только вы называете конкретное предположение и видите, на каком из четырёх шагов оно не сменилось, причина перестаёт быть туманным «человеческим фактором» и становится управляемой. Но пожалуй, самое важное другое: осознаете ли вы вообще роль предположений в бизнесе? Именно на этот вопрос и отвечают мыслительные процессы ТОС: они находят конкретное ограничивающее предположение, а не общую жалобу на сопротивление.

Откуда берутся уверенные мифы о методах Самые уверенные суждения о методе обычно делают те, кто не разбирал, как он устроен. Покажу на одном примере, как это работает - и почему это дорого обходится. Недавно мне встретилось уверенное утверждение: теория ограничений, мол, слепа к вариабельности, она про причины и следствия, а не про разброс и неопределённость. Звучит солидно. И разбивается об один вопрос: зачем тогда в теории ограничений буфер? Буфер — это и есть инструмент против вариабельности. Барабан-буфер-канат, буфер проекта в управлении по критической цепи, динамический буфер запасов - всё это придумано ровно затем, чтобы поглощать неопределённость и не дать системе встать. Сказать «теория ограничений не видит вариабельность» - примерно как сказать «зонт не знает про дождь». Почему так выходит Метод судят по витрине, а не по устройству. У витрины есть ярлык: «это про потери», «это про статистику», «это про причины». Ярлык дёшев и звучит уверенно. А разобрать механизм - что метод на самом деле видит, на каких предположениях стоит, что должно быть верно, чтобы он сработал, - стоит времени и усилий. Особенно сейчас, когда метод можно за секунду «спросить у ИИ» и получить гладкий, уверенный, но поверхностный ярлык. Почему это опасно На ярлыках принимают решения: внедрять метод или нет, копировать конкурента или нет, считать подход устаревшим или нет. Решение на основе витрины — это решение вслепую, даже когда оно звучит обоснованно. Что с этим делать Прежде чем судить метод - чужой или свой, - восстановите его механизм и предположения: что он видит, на чём стоит, что в вашей компании должно быть верно, чтобы он заработал. Ярлык говорит, как метод выглядит. Предположения говорят, когда он сработает именно у вас. Это разные вещи, и решать стоит по второму. Короткий тест Возьмите любой метод, о котором у вас есть мнение. Можете назвать хотя бы одно предположение, на котором он держится? Если в ответ приходит только ярлык - значит, вы пока судите витрину, а не метод.

Как эксперт ТОС помогает внедрить Лин, LSS, Канбан или OKR Любой управленческий метод - Лин (бережливое производство), LSS (бережливое плюс «шесть сигм»), Канбан, OKR - приносит готовый ответ на заранее заданный набор управленческих предположений. Но сам он не умеет определить, какое предположение ограничивает именно вашу компанию. Эту работу и берёт на себя эксперт ТОС. Почему внедрения чаще проваливаются, чем приживаются По разным оценкам, от 60 до 80% таких проектов не дают устойчивого результата. Причина почти всегда одна из двух. 1. Метод выбран не под вашу болезнь. У каждого подхода есть набор предположений, которые он рассчитан преодолеть. Если ваша компания живёт в других предположениях - инструменты не срабатывают. 2. Скопировали инструменты, но не сменили предположения. Доска Канбан висит, церемонии идут, пояса обучены - а думают в компании по-старому. Это карго-культ: формы есть, сути нет. Сам метод эту ловушку не видит. Он приносит ответ, а не вопрос «какое предположение вас держит». Что добавляет эксперт ТОС Он приносит то, чего в самих методах нет, - диагностику. Мыслительные процессы ТОС позволяют: Найти ограничение. Сначала определить, какое предположение реально мешает компании выйти на результат, и только потом выбирать метод. Не «давайте внедрим OKR», а «вот что вас ограничивает, и вот метод, который это снимает». Проверить совпадение. Сверить, как принято думать в компании, с тем, на что рассчитан метод. Если не совпадает - сказать об этом до того, как потрачены год и бюджет. Вскрыть скрытые предположения метода. Без их принятия инструмент не работает. Например, OKR не живёт, пока премия привязана к выполнению целей. Эксперт делает такие условия явными заранее. Сменить контекст, а не уговаривать людей. Новое предположение приживается, только когда меняются правила, показатели и ритуалы. Иначе через полгода компания откатывается к привычному. Сфокусировать усилия. Лин и LSS улучшают везде, где видят потери. ТОС подсказывает, где именно улучшение поднимет результат всей системы, а где это просто потраченное время. Поймать внутренние противоречия. Скажем, «шесть сигм» утверждает «причина в системе, а не в человеке», но компания одновременно ранжирует и штрафует людей по показателям. Пока это противоречие живо, метод буксует. Главное Эксперт ТОС не конкурирует с Лин, Канбаном или OKR и не заменяет их. Он делает так, чтобы они сработали: сначала ставит диагноз, затем подбирает метод под него и закрепляет новые предположения в ежедневной практике. Управленческий метод приносит ответ - ТОС задаёт вопрос. Метод бьёт по своему предположению - ТОС находит ваше.

Как вы знаете, я собираюсь выступить в ближайшее время на выставке. И тут узнаю, что мой хороший знакомый, собственник производственного предприятия также участвует в выставке. Правда в отличие от меня, он со стендом. Я был на этом предприятии лично. Нет, не в качестве консультанта - в качестве исследователя. Славе (собственник) консультанты ни к чему. Он сам много освоил, перепробовал и внедрил. Его и предприятия основная идея: «Убиваем ПОТЕРИ!!! Сил, времени, денег!». Такая у него продукция. Ассортимент продукции, кстати, огромный. Собственник - настоящий Предприниматель и постоянно держит нос по ветру, быстро реагирует на запросы. Все время что - то разрабатывают и быстро тестируют. Производственный поток реально сбалансирован с использованием системы вытягивания (канбан). Система отношений на предприятии - дружественная. Кстати, если есть желание встретиться со мной или со Славой, приглашаю на его стенд (своего-то у меня нет). Лучше 24 июня или с утра 25-го. «Электронная коммерция» (ECOM Expo) Стенд H7.5 зал Вавилов

24 июня выступаю на выставке «Электронная коммерция» (ECOM Expo) Тема доклада - «Синхронизация управления запасами в цепи поставок». Расскажу, почему привычное управление запасами на маркетплейсе не спасает от главной беды интернет-торговли: когда на одних товарах склад забит неликвидами, а на других - дефицит и упущенные продажи. И всё это одновременно. Главная мысль простая. Рентабельность определяется не остатком на витрине маркетплейса, а согласованной работой всей цепи: производство, закуп, фулфилмент и сам маркетплейс. Управлять надо потоком, а не одной точкой. В докладе покажу: почему оптимизация каждого звена по отдельности убивает прибыль всей цепи как подход Теории ограничений синхронизирует запасы по всей цепочке как это работает в нашей системе WA-SCM «Гармония потока» реальный кейс: рост продаж на 30-120% при снижении запасов на четверть Если продаёте на маркетплейсах или производите для них - приходите. Будет полезно и собственнику, и тому, кто отвечает за закупки и наличие товара. 📅 24 июня 14-00📍 [площадка и зал №4] 🎟 https://expo.oborot.ru/ До встречи на выставке!

Отжившие установки в управлении производством Что лежит в основе большинства современных программных продуктов для управления производством? Очень простые допущения: 1. Производственный цикл может быть разделен на простые операции. 2. Длительность операций можно стандартизировать и ввести соответствующие нормы. 3. На основе введенных норм можно составить детальные планы, оптимизирующие использование оборудования. 4. Оборудование и человеческий труд необходимо использовать эффективно. Простой оборудования и людей – это потери. Допущения эти настолько просты и очевидны, что никому не приходит поставить их под сомнение. Тем более программисту, которому необходимо разработать программный продукт. Более того, эти допущения подтверждены «научным подходом» Фредерика Тейлора. Это он в начале 20 века, обнаружив на промышленных предприятиях бардак, решил применить свой научный подход. То есть разделить производственный цикл на операции, найти способы оптимизации этих операций и ввести соответствующие нормативы для каждого рабочего, выполняющего свою собственную простую операцию. Гениально? Конечно. Для массового производства однотипных изделий. https://tocpeople.com/2023/01/otzhivshie-ustanovki-v-upravlenii-proizvodstvom/

🪨 Метод критической цепи — это не алгоритм, а смена парадигмы Метод критической цепи знают многие. Прочитал книгу Голдратта, разобрался в схеме: буфер проекта в конце вместо подушек в каждой задаче, заморозка лишних проектов, фокус на критической цепи. Кажется, понятно — внедряй. Я видел десятки компаний, которые внедрили его формально. По шагам, как в книге. И через 4–6 месяцев откатились на старые показатели. «Метод не работает. У нас своя специфика». На самом деле — работает. Но он требует смены нескольких управленческих установок, без которых метод превращается в алгоритм без эффекта: 🟠 «Каждая задача должна иметь свою защитную подушку». Остаётся — единый буфер проекта рядом с подушками задач превращается в двойную страховку. Подушки съедаются законом Паркинсона, буфер не работает. 🟠 «Каждый ресурс должен быть загружен на 100%». Остаётся — заморозка лишних проектов воспринимается как разбазаривание ресурсов. Через пару месяцев замороженные проекты «по-тихому» размораживаются. 🟠 «Срок задачи — это норматив, исполнитель отвечает за его соблюдение». Остаётся — оценки в 50% (которые требует метод) выглядят как «дать меньше времени, чем нужно». Возвращаются страховочные оценки, поток ломается. 🟠 «Раньше начнем - раньше закончим». Остаётся — система наполнена слишком большим количеством работы, увеличивается количество переключений и сроки растут. Все эти установки выглядят как здравый смысл. Они работали, когда проект был похож на конвейер. В умственном труде с неопределённостью они работают против результата — но это незаметно, пока вы не попробуете внедрить метод «по букве». Внедрение начинается не с буфера. Оно начинается с разговора руководства: «От каких установок мы готовы отказаться?» Без этого разговора — алгоритм без результата. На курсе мы выводим эти установки на обсуждение до внедрения метода. Именно поэтому он приживается, а не отскакивает. 📚 С 16 июня стартует курс «Управление проектами по ТОС» — 5 недель, разбор метода критической цепи на ваших проектах. Сейчас в группе 9 человек. Регистрация:https://tocacademy.ru/course/pm/ или в личку @TOC_ACADEMY . Закрываю набор вечером 15 июня.

Один буфер вместо ста подушек В понедельник разобрали парадокс: каждая задача получает «подушку безопасности», но проект всё равно опаздывает на 40%. Где исчезает эта подушка? 🟠 Закон Паркинсона. Работа расширяется до отведённого времени. Если на задачу дано 10 дней, она займёт 10 дней — даже если её можно сделать за 6. 🟠 Синдром студента. Исполнитель видит запас и приступает в последний момент. Подушка съедается до того, как начнётся реальная работа. 🟠 Подушка не передаётся вперёд. Закончил задачу раньше срока — не сообщаешь. «Зачем напрягаться, если в следующий раз срок ужмут». Сэкономленное время остаётся у исполнителя, а не у проекта. Результат: каждая задача завершается «в срок» или «с небольшой задержкой» — а проект целиком опаздывает на 40%, и никто не понимает, где деньги. Голдратт в «Критической цепи» показал контр-интуитивное решение: убрать подушки из каждой задачи и сложить всё сэкономленное в один общий буфер проекта в конце. Что меняется: 🟢 Задача получает медианную оценку — реальное время выполнения, без страховки. Это снимает Паркинсона: подушки нет, работа сжимается. 🟢 Когда задача завершена — следующая стартует сразу, без ожидания «планового срока». Это снимает синдром студента: следующий исполнитель готов принять эстафету. 🟢 Сэкономленное время копится в общем буфере в конце проекта. Расходуется только по факту задержек. Эффект: проекты завершаются в 2 раза быстрее, и менеджмент видит реальную картину через расход буфера (зелёная зона / жёлтая / красная — управляющий сигнал). Защищается проект, а не каждая задача. Подробно — на курсе. Мы в Максе: https://max.ru/id7453075335_biz

Вчера разобрали, почему даже подстраховка в задачах не защищает проект. Сегодня — следующий слой проблемы. Многозадачность — главный убийца проектов Звучит логично: чем больше проектов запустим одновременно — тем быстрее достигнем результатов. Время идёт параллельно, ресурсы загружены, прогресс везде. Так думают почти все. И почти все ошибаются. Что происходит на самом деле, когда исполнитель ведёт 5 проектов сразу: 🟠 Каждое переключение между проектами «съедает» 15-30% времени. Не на работу — на восстановление контекста: «на чём остановился, какие были договорённости, где файл». 🟠 Задачи в каждом проекте растягиваются пропорционально количеству параллельных проектов. Если задача занимает 1 неделю в фокусе — при 5 параллельных проектах она занимает 4-5 недель календарного времени. 🟠 Срыв сроков становится системным, а не случайным. Не потому что кто-то плохо работает — потому что сама модель работы делает срыв неизбежным. Голдратт в «Критической цепи» показал контр-интуитивное решение: заморозить 25% активных проектов. Не закрыть, не отменить — поставить на паузу. Что происходит дальше: освобождаются ресурсы. Оставшиеся проекты получают сфокусированную работу вместо разорванной. Они завершаются в 2-3 раза быстрее. Замороженные проекты размораживаются — но не «по запросу», а только когда завершается один из активных. Общая пропускная способность портфеля растёт, хотя количество одновременных проектов уменьшилось. Один из самых жёстких управленческих парадоксов в управлении проектами. Подробно — на курсе. 📚 С 16 июня стартует курс «Управление проектами по ТОС» — 8 недель, разбор метода критической цепи на ваших проектах. Сейчас в группе 9 человек. Регистрация: https://tocacademy.ru/course/pm/ или в личку @TOC_ACADEMY. Закрываю набор вечером 15 июня.