Циклы в менеджменте конечно должны быть. Циклы совершенствования это прямо таки мантра менеджеров в моей компании. Все хотят operational excellence и ongoing improvements, притом, сами циклы пока что, внедрены совсем не везде.
Например, на уровне проектных команд, многие agile frameworks тот же scrum, предписывает иметь ретроспективы как цикл улучшения работы команды. Я постоянно настаиваю, что по результату работ над кейсом/набором кейсов в итерации и даже во время работа над кейсом с определенной периодичностью, необходимо постоянно делать ретроспективы, как механизм совершенствования и порой стратегирования.
Конечно scrum ретроспективы не в точности повторяют циклы Деминга и Бойда, но они могут быть очень приближены к ним. Для того, чтобы можно было использовать цикл улучшения качества, необходимо обязательно планировать какие то показатели и разбираться, достигнуты ли они и если нет, делать анализ вносить исправления и прочее. Вместо этого scrum предлагает просто получать обратную связь о том, что работает и что не работает и улучшаться. Я думаю, что этап сверки с планом, нужно добавлять в агенду ретроспектив команды, для того, чтобы все понимали, что планировали достичь, что не достигли и получить какие то гипотезы для дальнейшего анализа.
Тоже самое нужно начинать вводить как часть change management, те любой орг изменение (например, улучшение какой то практики) нужно начинать планировать и анализировать его результаты. Сейчас такого в моей компании не происходит. Особенно важным мне кажется высказывание Деминга: ”Опыт учит же (дает возможность планировать и предсказывать) только тогда, когда мы используем его для модифицирования и понимания теории”. Вот именно объяснительной теории как раз таки и не хватает при принятии решений об очередном изменении, решения как правило применяются быстро и по наитию. Те нужно a) вводить практики создания гипотез на базе разных объяснительных теорий b) выбирать наиболее убедительную с) планировать ожидания от изменения на базе этой теории d) анализировать результаты, если они сильно отличаются от теоретических, разбираться где проблема, в теории или в том как сделаны изменения e) делать этот как можно быстрее и дешевле.
Если говорить о цикле Бойда, то это конечно то, чем должны заниматься роли работающие с надсистемой/ми. Такие роли есть, и цикличность вводиться через QBR (quarterly business review) с клиентами, для понимая того, работает ли текущая стратегия с этим конкретным клиентом, что происходит с конкурентами, которые также работают с этим клиентом и прочее. Ну уровне компании существуют годовые и квартальные OKR сессии. Однако сама стратегия как правило приходит adhoc, владельцы бизнеса постоянно стратегируют и оценивают, что делают конкуренты и что происходит на рынке, однако они очень предвзяты относительно того, куда смотреть, и не смотрят на то, что происходит на соседних рынках и куда движутся тренды. А вот некоторые менеджеры смотрят и приходят с идеями, которые потом обсуждаются. Те цикл происходит, но у него нет cadence.
Идеи Lean Startup я применял, когда основывал свои стартапы retouchpro.ai и getluft.com там так все и работает, есть learning cycle и есть improvements cycle. Сначала пытаются найти market fit, те насколько хорошо идея принимается рынком, если принимается хорошо, то начинается цикл совершенствования, если нет, по pivot. Я совершил одну (на самом деле много) ошибку и не закрыл один из стартапов раньше, не потому, что не было market fit, а потому что системная схема проекта показала бы, что есть куча неразрешимых проблем и проект дохлый. Хотя даже и без этого, показатели не росли быстро, значит market fit нет, но деньги продолжали инвестировать.
Цикл Голдратта я сам не использовал, но я был свидетелем, как один очень опытный менеджер перестроил все производство пытаясь убрать один bottleneck. Было много боли и пота, и возражений и лидерства, но в результате bottleneck был снят и все заработало.