Litti Pro

Почему проекты по операционной эффективности «не взлетают», подводим итог.
В серии постов выше я разобрали роли в проектах операционной эффективности: заказчик, спонсор, руководитель проекта и исполнитель.
И главный вывод простой и неприятный:
❗️большинство провалов происходит не из-за инструментов, а из-за ролей, которые не выполняются или смешиваются.

Бережливое производство, реинжиниринг процессов, СМК - методологии разные, а сценарий провала один и тот же.

Чтобы было нагляднее, представим проект как съёмку фильма 🎥

• Заказчик - это продюсер: даёт деньги, задаёт жанр и ожидания. Без него фильм не укладывается в сроки, бюджеты, не приносит реальный доход.

• Спонсор - это студия / главный инвестор: обеспечивает бюджет, решает глобальные проблемы. Если спонсор пассивен - съёмки или остановятся на полпути или привраться в бесконечную яму для денег.

• Руководитель проекта - это режиссёр: планирует сцены, координирует команду, следит за видением. Если он слаб – съёмочная площадка станет хаосом, а фильм не получится.

• Исполнитель - это актёры и съёмочная бригада: играют роли, монтируют, освещают. Без их энергии и навыков - даже лучший сценарий с прекрасным режиссером превратится в любительское видео.

А теперь посмотрим, что идёт не так:
🔻 Продюсера (заказчика) нет или он пассивный - фильм снимают «потому что надо», любой результат будет считаться приемлемым.
🔻 Инвестор (спонсор) не включён - поддержки хватает ровно до первого конфликта или будут расти бюджеты, а окупаемость будет под вопросом.
🔻 Режиссёр снимает сам, таскает свет и спорит со сценарием - фильм разваливается.
🔻 Актёры начинают решать, каким будет финал - получается артхаус, который никто не заказывал.

Особенно плохо, когда один человек совмещает несколько ролей.

Продюсер + режиссёр + спонсор в одном лице - почти гарантированный провал, даже если человек умный и опытный, в лучшем случае получится авторское кино, для фестиваля эстетов.

То же самое в проектах операционной эффективности, если человек совмещает роли в одном лице риск неудачи велик. Конечно, есть нюансы, кто этот человек, если:

- генеральный директор – шансы на успех выше, минус в том, что таких проектов в моменте может быть очень ограниченное количество, в компаниях же требуется множество новаций;

- руководитель проектного или лин офиса – это скорее будет проект ради проекта, разработанные модели бизнес-процессов будут не востребованы, и участки по 5С в скором вернутся к хаосу.

🎯 Вывод
Проекты по операционной эффективности проваливаются не потому, что Lean «не работает» или BPM «слишком сложный».

Они проваливаются по многим причинам, но точно одной из ключевых является то, что:
• роли не определены,
• ответственность размыта,
• ожидания не проговорены.

Хочешь хороший фильм - сначала собери команду и раздай роли.
С проектами всё ровно так же.
Если тема откликается - значит, вы это уже где-то проживали 😉

На этом тему ролевой структуры будет считать раскрытой, если есть вопросы, пишите.

⭐️Если интересно разобрать другие причины провалов программ роста операционной эффективности, все просто:
- лайк,
- репост,
- комментарий
это очень важно.

Равиль, спасибо за ваше сообщение.
Никогда не использовал Метод «Шесть шляп мышления» Эдварда де Боно на практике, хотя прочитал его книги еще в начале 2000-ных.
Честно - он кажется мне немного театральным что ли, хотя идея хорошая.
Суть в двух словах: вместо того чтобы все вместе спорить в одной плоскости, команда по очереди надевает «разные шляпы» и смотрит на проблему только с одной стороны за раз.
Белая шляпа → только факты и цифры
Красная шляпа → эмоции, интуиция, «чувствую, что это не то»
Чёрная шляпа → критика, риски, почему это НЕ сработает
Жёлтая шляпа → польза, выгоды, почему это МОЖЕТ сработать
Зелёная шляпа → креатив, новые идеи, «а давайте сделаем вообще по-другому»
Синяя шляпа → управление процессом, повестка, итоги, следующий шаг
Применительно к операционке это может выглядеть примерно так:
Обсуждаем идею снижения времени переналадки с 4 часов до 40 минут
→ Белая шляпа: текущие замеры, OEE до и после, стоимость простоя, любые иные факты.
→ Чёрная шляпа: риски брака, поломок, сопротивление рабочих, рост нагрузки на рабочих и т.п.
→ Жёлтая шляпа: экономия 3,5 млн руб/год, рост выпуска на 12 %, прочие выгоды.
→ Зелёная шляпа: а если вообще перейти на однотипную оснастку? Или все подготовительные работы передать мастеру?
→ Синяя шляпа: фиксируем решение - пилот на одной линии, дедлайн 6 недель, ответственный - Петров
Только я не помню шляпы в один момент у всех участников одни, или в команде у всех шляпы разные?
Плюсы подхода (по моим представлениям):
- все высказываются без страха «а вдруг скажу глупость»;
- снижается эмоциональный накал и личные нападки;
- видны слепые зоны, которые обычно пропускают;
- проще приходить к консенсусу.

Кто пробовал «шесть шляп» в операционных проектах? Поделитесь.

Роли в проекте операционного совершенствования: Исполнитель проекта.

Мы уже разобрали Руководителя, Куратора и Заказчика.
Сегодня говорим про тех, на ком в реальности держится весь результат – Исполнителей проекта.

Исполнитель – это не просто «человек, который делает задачи».
Это ключевая роль, которая превращает планы, идеи и красивые презентации в реальные изменения на производстве, в процессах, в цифрах.

Но вот в чём главная сложность правильной команды:
Исполнители должны быть очень разными по характеру, стилю мышления и сильным сторонам.
Чего часто не бывает, люди в команду попадают скорее по должности, нежели по своим отличительным сильным чертам. И это повышает риск провала проекта

Один и тот же человек редко может одновременно блестяще планировать, жёстко контролировать, креативно придумывать, красиво оформлять и ещё зажигать команду.
Наиболее популярная ролевая модель проекта принадлежит Белбину, который выделяет 9 ролей по 3 группам ролей.
1. Мыслительные роли.
2. Социальные роли.
3. Роли действия.
В общем и целом, можно ориентироваться на неё.
Я рекомендую упрощённую модель 6 ключевых ролей:

1. Планировщик
Согласует цели, этапы, сроки, ресурсы и взаимосвязи. Делает план логичным и реалистичным, синхронизирует ожидания всех. Он – переводчик с языка целей на язык конкретных действий. Его задача: сделать так, чтобы план был не на бумаге, а в головах членов команды.

2. Контролёр
Ловит отклонения, фиксирует риски, первым бьёт тревогу. Внутренний радар проекта. Он не «стучит», а объективно фиксирует: «Мы отклонились здесь, здесь – риск, а здесь нужно срочное решение». Благодаря ему проект остается управляемым, а не летит в пропасть неожиданностей

3. Оформитель
Превращает хаос мыслей и данных в ясные схемы, отчеты, инструкции и презентации. Его сверхспособность – делать сложное простым и наглядным. Без него даже блестящая идея может быть не принята просто потому, что её не поняли.

4. Генератор идей
Ломает шаблоны, предлагает нестандартные решения, расширяет пространство вариантов. Без него всё идёт по проторенной дорожке.

5. Исполнитель мероприятий
Те самые «руки», которые берёт задачу и доводит её до качественного результата в своей зоне. Надёжность и качество исполнения – его зона ответственности. Он превращает «надо» в «сделано»

6. Вдохновитель
Поддерживает огонь в глазах команды. Помогает переживать сопротивление, усталость и кризисы веры. Без него даже лучшие планы умирают от демотивации, команды выгорают.

Самая частая ошибка подбора, когда руководитель проекта берет «похожих на себя» людей.
Получается команда клонов: все планируют, никто не исполняет, или все креативят, но никто не доводит до конца.

Целостность подбора = сила команды.
Когда в проекте есть хотя бы по одному яркому представителю каждой роли - магия случается: планы реалистичны, контроль жёсткий, идеи свежие, оформление понятное, исполнение качественное, а мотивация держится даже в самые тяжёлые моменты.

А вы уже знаете, какие роли преобладают в ваших проектах по операционке?
И каких ролей остро не хватает?

Если вам интересно то, что я делаю – поддержите канал. Лайк, репост, пригашение в канал новых участников - очень важно.

Почему одни проекты по росту операционной эффективности приносят реальные эффекты, а другие заканчиваются красивым отчётом? Часто всё решает не методология, а человек во главе.

Сегодня поговорим о руководители проекта.

Не просто менеджер, а «архитектор» бизнес-процессов, «хирург» потоков создания ценности, «ловец» времени, не создающей ценность.

Часто думают, что руководитель проекта по Lean (BPM, 6 sigma и т.п.) – это тот, кто лишь анализирует процессы, составляет отчеты, разрабатывает инструкции.

На деле – это ключевой агент изменений.
Его миссия – не «сделать проект», а ИЗМЕНИТЬ РАБОЧИЕ ПРИВЫЧКИ десятков, а то сотен людей, и получить ИЗМЕРИМЫЙ результат.

Руководитель проекта – это «двигатель» изменений.
Формальные функции (база, без которой нельзя):
• Планирование: разработка детального плана проекта, включая этапы, сроки, ресурсы и KPI.
• Координация: управление командой проекта, распределение задач, обеспечение взаимодействия между исполнителями.
• Контроль исполнения: мониторинг прогресса проекта, выявление отклонений, корректировка действий.
• Анализ данных: сбор и интерпретация метрик, выявление узких мест и точек роста.
• Коммуникация: регулярные отчёты для заказчика и куратора, вовлечение сотрудников в изменения.
• Управление рисками: прогнозирование проблем и разработка антикризисных мер.
• Внедрение решений: сопровождение пилотных запусков, масштабирование успешных практик.

Это формально описание функций роли, которое абсолютно верное – это база, если этого нет, то роль не выполняется.
И при этом, по моему убеждению, выполняя лишь эти функции, не стать классным руководителем проекта.
Хотел бы дополнить их «истинными» задачами (которые не описаны в регламентах):
• Находить приемлемые варианты разрешения конфликта требований между заказчиком, куратором и командой проекта (о конфликте интересов я писал выше).
• Понимать и переводить бизнес-боль заказчика в техническое задание. «У нас плохо организована работа на местах» → «1. Нам нужно сократить непроизводительное время бригад КРС. 2. Снизить время демонтажа, переезда и монтажа бригад. И так далее».
• Создавать, вести и самое главное мотивировать команду. Держать ритм работы над проектом, избегать затухания активности и авралов. Честно отражать отклонения по проекту, реагировать на них, не ждать, что «само как-то наладится».
• Соблюдать методологию реализации проектов роста операционной эффективности, определению консультантом или корпоративными стандартами. Подавлять желания «срезать углы», сделать что-то по-своему.
• «Продавать» изменения каждый день. Мотивировать, вдохновлять, развеивать сомнения, праздновать маленькие победы.
• Находить и создавать союзников на местах реализации проекта среди сотрудников участков, где проект реализуется. Без широкой поддержки, реализовать проекта и обеспечить его долгосрочную успешность не получится.
Такое в регламентах не пишут, но это то, что хорошие руководители проектов ставят во главу угла. Именно из-за того, что эти задачи не решаются руководителем проекта, проекты проваливабтся.

ИТОГ
Руководитель проекта по операционной эффективности – это не просто «менеджер задач», а лидер изменений, находящий компромисс в конфликте интересов. Его успех зависит от баланса между жёстким контролем процессов и умением работать с людьми. Помните: его цель – не просто закрыть проект, а создать устойчивые улучшения, которые принесут долгосрочную пользу компании.

А с какими вызовами сталкивались вы в подобных проектах? Делитесь в комментариях!

Поддержите канал, поставьте лайк, сделайте репост, пригасите в канал новых участников - это очень важно.

Проекты по операционной эффективности никогда не проваливаются из-за:
• инструментов Lean, BPM, TOC, Six Sigma, TQM, Hubbard Management System, QRM, «20 ключей Кобояси», СУОД, ИСО, НОТ, PMI, Scram, Kanban или еще бог знает чего,
• работы консультанта, прочитанных книг, прослушанных или просмотренных подкастов, посещения конференций,
• выбора участка, процесса, потока оптимизации, поставленной задачи,

Они проваливаются из-за неясной или искажённых ролей проекта, и большая часть проблем в проектах связана с ролью заказчика. Слишком часто эта роль сводится к формальному утверждению документов, в то время как от поведения и вовлеченности Заказчика зависит до 70% успеха.

Именно заказчик определяет, станет ли проект источником реальной бизнес-ценности или превратится в очередную «инициативу ради инициативы».


Заказчик – это не просто руководитель, подписавший паспорт проекта. Это владелец бизнес-процесса или функции, которую предстоит улучшить. Он – главный бенефициар (выгодоприобретатель) и «хозяин» будущих изменений.
Его ключевые характеристики:

1. НЕСЕТ КОНЕЧНУЮ ОТВЕТСТВЕННОСТЬ ЗА РЕЗУЛЬТАТ ПРОЕКТА. Оценка его труда (KPI) должны улучшиться благодаря проекту, а риск провала, вызывать тревожность.

Здесь чуть подробнее, это важно.
Многие убеждены, что конечную ответственность за результаты проекта несет руководитель проекта, но это не так. Руководитель проекта – временная роль, проекта закончится, и она исчезнет. Роль заказчика вроде как тоже временная, но именно заказчику дальше жить с результатами.

Для примера, можно рассмотреть ситуацию со строительством дома. Заказчик нанимает прораба - руководителя проекта строительства. Прораб построил дом с недоделками. Прораб со стройки уйдет, а заказчику в этом доме жить. Все недоделки – это теперь проблемы заказчика.

2. Определяет: цели, результаты, границы и требования к проекту.
Именно заказчик определяет какой дом построить, а не прораб.

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

4. Согласует со спонсором выделение ресурсов, обосновывает ему стратегические выгоды от проекта компании.
Именно заказчик ищет финансирование, и если не хватает своих денег, убеждает дать их ему спонсоров (банки, родственники, знакомые, мафия и т.п.), прораб этим не занимается.

5. Поддерживает и контролирует команду в реализации проекта.
Если заказчик не будет контролировать ход строительства, полностью доверится прорабу, то риски того, что все будет в 2-3 раза выше план (сроки, затраты), или в хуже качество, отклонения от проектной документации и архитектурного замысла буду огромными.

Проще говоря, Заказчик – это тот, кто после ухода консультантов и роспуска проектной команды останется жить с измененным процессом.

Светлана, спасибо за ваше участие. Это очень важно для меня.
Отвечу, продолжая тему, связанную с ролью куратора, но на этом примере, можно понять и о других ролях.

Как проверить, что роль куратора реально принята?
Простой и надёжный тест - не спрашивать «поддерживает ли куратор проект», а смотреть на его поведение в первые 2-4 недели.
Есть несколько признаков.

А. Участие в формировании целей, ожиданий и требований к проекту.
Признак принятой роли:
• куратор лично участвует в обсуждении:
- целевых показателей;
- границ проекта и его результатов;
- необходимых ресурсах для реализации;
- ожидаемого экономического эффекта и/или существенного снижения существенных для компании рисков;
- влиянии проекта на стратегию компании в целом.
Три последних пункта являются для куратора ключевыми, это его отличия от заказчика проекта (роли во многом схожи).
Если все вышеописанное проходит без участия куратора, роль формально не принята.

Б. Приоритет проекта относительно операционной работы
Признак живой роли:
• куратор явно проговаривает, что проект:
- имеет приоритет выше части операционных задач;
- допускает перераспределение времени ключевых сотрудников;
• это проговаривается публично, а не в личном разговоре.
Важно: не слова «проект важен», а конкретные управленческие последствия.

В. Готовность принимать неудобные решения
Куратор «оживает» не в отчётах, а в конфликтных точках.
Признак: он готов:
- указать на отклонение хода проекта от намеченного плана;
- не дает команде успокоится, пока не будет достигнуто необходимое состояние, обеспечивающее стратегическое движение и экономическую эффективность;
- вмешаться в конфликт между подразделениями;
- принять решение, которое кому-то не понравится.
Если куратор говорит:
«Вы делайте самостоятельно, а если будут сложности - приходите»,
роль пока не принята.

Ранние признаки, что роль куратора реализуется
Есть несколько очень надёжных маркеров, которые видно уже на старте.

А. Решения, зависящие от куратора, принимаются быстро
• вопросы от команд не «висят» неделями;
• эскалации доходят до куратора и закрываются решениями, а не комментариями.

Б. Проект не «проигрывает» операционке автоматически
Если возникает выбор:
• «производство сегодня» или «работа над проектом»
и проект хотя бы иногда выигрывает — это сильный сигнал.

В. Команда чувствует легитимность
Очень показательный момент:
• команда не боится обращаться к куратору, активно с ним коммуницирует;
• решения проекта не требуют постоянного «дополнительного согласования».
Когда команда говорит:
«Это поддержано куратором»
и этого достаточно для команды и её окружения- роль работает.

Красные флаги 🚩
Вот признаки, по которым почти гарантированно можно предсказать будущие проблемы.
А. Куратор появляется только на этапе защиты
Если его роль:
• послушать отчёт;
• задать пару общих вопросов;
• «пожелать удачи»
- это не куратор, а наблюдатель.

Б. Все ключевые конфликтные вопросы остаются у руководителя проекта
Фразы типа:
• «Попробуйте ещё раз согласовать»
• «Давайте пока не эскалировать»
- означают, что управленческая воля отсутствует.

В. Приоритет проекта нигде не зафиксирован
Нет:
• явного решения о приоритете;
• договорённости по ресурсам;
• публичного сигнала от куратора.
Значит, при первой нагрузке проект проиграет.

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

Краткий вывод
Роль куратора проверяется не декларациями, а управленческими действиями.
Если:
• он участвует в формировании целей;
• задаёт стратегические приоритет;
• концентрируется на экономической эффективности (экономический эффект не сам как таковой, а как мерила правильного приложения усилий);
• анализирует как влияет проект на системные риски компании;
• принимает неудобные решения;
• снимает ограничения,
проект почти всегда доходит до реальных изменений.
Если нет - он возможно будет идти, но «ни шатко ни валко».

Если тема откликается - поставьте реакцию и сделайте репост.

Продолжая тему ролевой модели в проектах операционных улучшений.

Сегодня - о самой недооценённой и при этом критически важной роли.
О кураторе проекта. Его ещё часто называют спонсором.
В теории всё выглядит просто:
куратор - это руководитель высокого уровня, который:
• принимает окончательное решение по запуску проектов,
• поддерживает ход проект,
• концентрируется на стратегической значимости и экономической эффективности проекта;
• обеспечивает команду необходимыми ресурсами.

В реальной практике именно здесь возникает наибольшее количество проблем.
Что я вижу снова и снова в компаниях:
• куратор назначен формально;
• его имя стоит в приказе и презентации;
• но фактически он не встроен в управление проектом.

Чаще всего куратор:
• не участвует в формировании целей и ожидаемых эффектов;
• не задаёт приоритет проекта относительно других инициатив;
• не обеспечивает ресурс (люди, время, внимание);
• не снимает системные ограничения;
• подключается только к статус-отчётам или защите результатов.

По сути, роль куратора сводится к «присутствию на слайде».

Почему это критично.
Проекты улучшений почти всегда упираются не в инструменты, а в пересечение интересов, приоритетов и ограничений системы:
• конфликт между операционкой и проектной работой;
• нехватка ресурсов;
• сопротивление смежных подразделений;
• решения, выходящие за полномочия руководителя проекта.

И вот здесь ключевой вопрос:
кто имеет право и обязанность эти ограничения снимать?
Не руководитель проекта.
Не команда.
И зачастую - не заказчик.
Это зона ответственности куратора.
Когда куратор не выполняет свою роль:
• решения «висят» неделями;
• приоритет проекта постоянно проигрывает операционным задачам;
• команда быстро понимает, что проект - не по-настоящему важен;
• руководитель проекта выгорает или уходит в формальную отчётность.
Проект начинает жить в режиме:
• «делаем, когда есть время»;
• «двигаемся к контрольной дате»;
• «главное - красиво отчитаться».
Важно:
это не вопрос плохих людей или низкой вовлечённости.
Это вопрос непроговорённых ожиданий к роли куратора.
Куратор - это не «наблюдатель».
Это:
• владелец приоритета проекта;
• носитель управленческой воли;
• источник легитимности решений;
• тот, кто превращает проект из инициативы «снизу» в управляемое изменение системы.
Пока эта роль не осознана и не выстроена – любые методологии, инструменты и обученные команды будут давать слабый эффект.
В следующем посте разберу:
• какие конкретно функции должен выполнять куратор;
• типовые ошибки кураторов в проектах улучшений;
• и как выглядит рабочая модель взаимодействия «куратор – заказчик – руководитель проекта».
Если тема откликается - поставьте реакцию и сделайте репост.
Продолжим.

В проектах по повышению операционной эффективности есть одна повторяющаяся картина.
Я много лет реализую масштабные программы по развёртыванию систем непрерывных улучшений в крупных компаниях. В рамках таких программ одновременно запускаются множество проектов - по улучшению процессов, снижению потерь, росту производительности.
И почти всегда старт выглядит одинаково:
проекты идут тяжело, сроки «плывут», результаты размыты, команды формально числятся, но реально начинают работать ближе к отчётной дате перед руководством.

Часто это списывают на сопротивление изменениям, перегруженность людей, недостаток мотивации или компетенций. Всё это действительно может иметь место. Но на практике одна из ключевых причин лежит глубже - неотстроенная ролевая структура управления проектами.
Особенно это заметно в треугольнике:
• руководитель проекта
• заказчик проекта
• куратор проекта
Формально роли назначены. В презентациях они есть. В приказах - тоже.

Но фактически каждый из участников либо:
• выполняет роль не полностью,
• подменяет одну роль другой,
• либо вообще выпадает из управленческого контура.
В результате:
• руководитель проекта остаётся один на один с проблемами, не имея реальных полномочий, переключается на решение других задач без должного контроля;
• заказчик ограничивается, не участвуя в формировании требований к проекту, ожидаемых результатов, не поддерживает, не контролирует проект по ходу, принимает итоги проекта формально;
• куратор существует номинально и подключается только на этапах отчётности.
Проект в такой конструкции неизбежно начинает «шататься»:
решения откладываются, приоритеты меняются, команда теряет фокус, а работа превращается в имитацию до контрольной точки.

Важно понимать:
проблема не в людях, а в неясности ролей и ожиданий.
Когда не определено:
• кто и за что принимает решения,
• кто обеспечивает ресурс и снимает ограничения,
• кто формирует требования к результату,
• кто поддерживает и контролирует по ходу реализации проекта,
- проект перестаёт быть управляемым процессом и превращается в набор разрозненных действий.
Именно поэтому в программах операционных улучшений работа с ролевой моделью - это не «методологическая формальность», а базовый управленческий инструмент. Без неё невозможно ни устойчивое выполнение проектов, ни масштабирование результатов.

В следующих постах разберу:
• ключевые роли в проектах улучшений;
• типовые управленческие ошибки в их распределении;
• и что именно стоит менять, чтобы проекты начинали работать с первого месяца, а не к моменту отчётности.
Если тема откликается – продолжим, поэтому поставьте лайк и сделайте её репост.