Six Sigma

Думки про вдосконалення бізнесу

Six Sigma

Категорія: Лін

Програми безперервного вдосконалення ніколи не дають справжньої трансформації

(переклад статті Кріса Терона, Регіонального лідер CDI Holdings AAE, який займається трансформацією ефективності через автономні команди)

Оригінал статті тут

16 лютого 2026 р.

Роками мене переслідував неясний сумнів: чи не були наші реальні успіхи в операційній трансформації переважно везінням — може нам просто пощастило працювати з винятковими топменеджерами? Але це було лише припущення. Тож я почав шукати відповіді.

Питання, що змінило нашу роботу

Я проаналізував понад 150 детально задокументованих впроваджень MDW (Mission Directed Work) у 47 країнах, маючи на меті одне питання: що насправді відрізняє ті впровадження, які забезпечують тривалу трансформацію, від тих, що зазнають краху — або не витримують перевірки часом?

Відповідь кардинально змінила наш підхід до операційної досконалості. Вона підтвердила, що ми мали правильні інгредієнти, але нам потрібно було набагато ретельніше узгоджувати наш підхід із рівнем зрілості клієнта.

Та перш ніж я поділюся результатами, дозвольте змалювати картину, яка може здатися вам болісно знайомою.

Безперервне вдосконалення сьогодні — невтішна реальність

Дослідження незмінно показують, що менше ніж 20% впроваджень Lean / CI (безперервного вдосконалення) дають очікувані результати. Деякі звіти свідчать, що менше 2% виробничих операцій є справді «ощадливими». Це не поодинока статистика — це системна закономірність, яка щодня розігрується в залах засідань і в цехах.

І все ж індустрія вдосконалення продовжує зростати. Консультантів наймають. Інструменти розгортають. Навчання проводять. Ради директорів затверджують бюджети. І цикл повторюється.

Щось тут не сходиться.

Що ми виявили насправді

З даних викристалізувалися п’ять закономірностей — і кожна з них набагато тонша за звичний діагноз «брак лідерської підтримки», який люблять озвучувати на конференціях.

Шаблон 1: Фальстарти — вдосконалення посеред хаосу

Значна кількість невдач припала на організації, які розпочали свій шлях удосконалення, перебуваючи в режимі глибокого «гасіння пожеж». Керівники щодня були перевантажені нестабільністю та непередбачуваністю. Можливо, вони щиро вірили в принципи досконалості — мали найкращі наміри — але це було надто далеко від їхньої реальності.

Ви не можете делегувати стабільність. Ви не можете побудувати автономію команди, коли лідер групи витрачає кожну зміну на виправлення вчорашніх проблем. Ці впровадження не були провалом зобов’язань. Це були провали в черговості — спроби звести дах до того, як з’явився фундамент.

Шаблон 2: Система стає метою

Цей варіант підступніший, бо починається він добре. Впровадження стартує енергійно. Команди залучаються. З’являються дошки візуального управління. Проводяться щоденні наради. Перші результати надихають.

Але потім щось змінюється. Замість того, щоб система управління слугувала інструментом для досягнення операційної досконалості, сама система стає кінцевим пунктом. Керівники починають вдосконалювати систему заради самої системи — додають рівні, створюють виділені ресурси для її підтримки, вимірюють відповідність процесу, а не результати, які цей процес мав забезпечити.

Система управління, яка мала бути двигуном трансформації, поступово перетворюється на бюрократію. Вона отримує власний бюджет, власну команду, власні KPI. І десь по дорозі початкова мета — створення здатних, мислячих команд, що постійно вдосконалюються, — тихо зникає.

Шаблон 3: «Бігова доріжка» фахівців

У багатьох організаціях безперервне вдосконалення є відповідальністю виділених фахівців — відділу CI, департаменту Lean, кількох інженерів та аналітиків. Щороку ці фахівці мають знаходити можливості для покращення, виконувати проєкти та презентувати результати. І щороку цикл повторюється.

Ось про що ніхто не говорить: оскільки покращення належать фахівцям, а не людям, які безпосередньо виконують роботу, вони рідко приживаються. Операційна діяльність тимчасово вбирає зміни, а потім відкочується назад. Темп природної ентропії в більшості організацій такий, що покращення, зроблені п’ять років тому, знову стають цілями для «нових» проєктів сьогодні.

Результат — нескінченна петля: фахівці вічно перевідкривають і заново вирішують проблеми, які операційні підрозділи ніколи не вважали «своїми». Робота виглядає продуктивною. Щорічні презентації вражають. Але операційна діяльність по суті не змінилася. Це біг на місці.

Шаблон 4: Протиріччя головного офісу

Це характерно для великих корпорацій і, мабуть, завдає найбільшої шкоди, бо залишається невидимим для тих, хто це спричиняє. Головний офіс затверджує програму операційної досконалості для своїх філій. Можливо, це Lean, можливо TPM, або власна система. Філіям кажуть: «Ви повинні це робити». Виділяються ресурси. Приїжджають консультанти. І багато об’єктів справді успішно впроваджують нові практики — команди залучаються, системи вкорінюються, показники зростають.

Але сам головний офіс не змінюється. Ті самі директиви «згори донизу», той самий короткостроковий фінансовий тиск, той самий стиль управління, який і створив потребу в трансформації, продовжуються без змін. Посил, озвучений чи ні, зрозумілий: ця програма для вас, а не для нас.

Це створює дисонанс, який відчувається на кожному рівні. Керівники філій, які почали коучинг своїх команд, бачать, що їхні власні начальники продовжують управляти ними в старому командно-адміністративному стилі. З часом новий спосіб роботи на операційному рівні починає сприйматися як експеримент, який вище керівництво терпить, а не як стратегічне зобов’язання всієї організації. А оскільки топменеджмент зберіг старе мислення, усі рівні нижче зрештою підлаштовуються під нього.

Ви не можете вирішити проблему з тим самим мисленням, яке її створило. І ви не можете підтримувати трансформацію на рівні заводу, якщо вона суперечить тому, як керується все підприємство.

Шаблон 5: Досконалість як ярлик, а не стандарт

Цей останній шаблон менше стосується помилок організацій, а більше — того, що вони називають успіхом. Багато компаній щороку завершують кілька проєктів із вдосконалення. Деякі дають реальні результати — економію витрат, приріст ефективності, покращення якості. І організація називає це «операційною досконалістю».

Але кілька успішних проєктів на рік — це не операційна досконалість. У найкращому випадку це проєктне вдосконалення. У цьому немає нічого поганого — це створює цінність. Але називати це «досконалістю» небезпечно: створюється ілюзія, що робота виконана, що організація досягла мети.

Справжня операційна досконалість — це не набір проєктів. Це всеохопний спосіб світосприйняття, де кожна людина думає про те, як зробити свою роботу краще; де вдосконалення вплетене в щоденну рутину, а не в річні заходи; де рядові працівники вважають і результативність, і вдосконалення невід’ємними частинами своєї роботи.

Цей стандарт високий. Він не для всіх. І чесно кажучи, багато організацій цілком успішно існують з проєктним підходом. Але ті, хто прагне справжньої досконалості, мають розуміти прірву між тим, де більшість програм зупиняється, і тим, де починається справжня майстерність.

Чесне зізнання

Хочу бути відвертим: наші стандарти в CDI вищі за більшість. Ми визначаємо успіх не за тим, наскільки добре стартувало впровадження, а за тим, чи відбулася трансформація — чи стала організація фундаментально іншою через п’ять років, з нами чи без нас.

За цим критерієм у нас також були впровадження, які не досягли мети. Саме тому ми шукали відповіді в даних. Не для того, щоб звинувачувати клієнтів, а щоб зрозуміти, що ми можемо робити інакше.

Що сказали дані

Описані вище шаблони не є ізольованими випадками. Вони перекриваються і посилюють один одного. «Бігова доріжка» фахівців існує частково тому, що лідери застрягли в режимі гасіння пожеж. Протиріччя головного офісу зберігається, бо досконалість вважається ярликом, а не стандартом. Система стає метою, бо ніхто не визначив, що буде після того, як вона запрацює.

Але дані також показали дещо обнадійливе: організації, які подолали ці шаблони, мали напрочуд схожі характеристики. Вони дотримувалися певної послідовності — стабільність перед автономією, автономія перед досконалістю. Це поважало і реальність того, з чого вони починали, і амбітність того, куди вони хотіли прийти. Це також показало, що фальшива автономія не працює. Командам потрібна реальна самостійність, перш ніж ви зможете перейти до фінальної стадії.

Ця послідовність тепер визначає все, що ми робимо сьогодні.

Питання до вас

Якщо ви керуєте зусиллями з вдосконалення, погляньте на ситуацію чесно:

Чи належать ваші вдосконалення фахівцям, чи людям, які виконують роботу? Чи служить ваша система управління трансформації, чи вона сама стала кінцевою метою? Чи демонструє ваше вище керівництво ті самі практики, які воно вимагає від операційних підрозділів? І коли ви кажете «операційна досконалість» — ви маєте на увазі кілька хороших проєктів чи фундаментально інший спосіб роботи?

Плато — це не назавжди. Але прорив починається з того, щоб побачити його чітко. І зрозуміти шлях, що лежить за його межами.

Чому Lean-департамент є ознакою незрілої операційної системи

Нижче подаю машинний переклад з моїм творчим редагуванням статті відомого експерта Лєдєньова Є.Є., що керує агенцією LED AI business consulting і просуває лін мислення в Чорногорії.

Оригінал статті тут: https://www.linkedin.com/pulse/why-lean-department-sign-immature-operating-zsfgf/

Наявність «Lean-департаменту» або керівника з безперервного вдосконалення / операційної досконалості (CI / OpEx) може бути одночасно і каталізатором змін, і милицею. Питання не в тому, чи потрібна вам така роль, а в тому — на який період і для чого саме.

Нижче — структурований погляд у форматі статт: що роблять функції Lean/CI/OpEx на різних етапах розвитку, коли і як вони мають поступово «розчинятися» в лінійному менеджменті, і як це пов’язано з моделлю Shingo та оцінкою Shingo Insight.

  1. Навіщо взагалі потрібна функція Lean / CI / OpEx?

Майже всі великі компанії, описані в класичній Lean-літературі (Jeffrey Liker — The Toyota Way та Toyota Culture, David Mann — Creating a Lean Culture, кейси Shingo Institute тощо), починали трансформацію зі створення окремої функції — Lean офіс, Команди безперервного вдосконалення або Офісу операційної ефективності.

Це нормальний старт. Системі потрібен «зовнішній поштовх», щоб зрушити з поточного стану. Невелика центральна команда зазвичай відповідає за:

  • проєктування операційної системи,
  • запуск пілотів,
  • навчання керівників і співробітників,
  • побудову базової інфраструктури ідей, KPI, стандартів і проблем-менеджменту.

Більшість моделей впровадження Систем операційного вдосконалення та Lean Six Sigma рекомендують такий самий підхід: спочатку створити корпоративний центр експертизи або офіс впровадження; згодом, у міру зростання внутрішньої спроможності, ця функція переходить у роль менторства замість прямого ведення всіх змін.

Критичний момент інший: ця функція не повинна залишатися постійною милицею для лінійного менеджменту.

 

  1. Три етапи: як еволюціонує роль Lean / CI / OpEx

Етап 1. Старт: «запуск реактора»

Ключова роль — архітектор і каталізатор змін.

Типові задачі на початку:

  • Проєктування операційної системи. Вибір моделі методології (Toyota, Shingo, Lean Six Sigma тощо), визначення цільової архітектури: розгортання цілей, портфель проєктів, візуальний менеджмент, система ідей, навчання та сертифікація.
  • Діагностика резервів ефективності. Спостереження в полі (gemba), картування процесів (за книгою Rother і Shook), кількісна оцінка втрат і потенціалу мовою, зрозумілою топ-менеджменту.
  • Пілотні проєкти. Вибір 1–2 зон з підтримуючими керівниками і фокус на критичних потоках створення цінності, а не «покращувати все одразу».
  • Дизайн ролей і структури. Lean/CI-спеціалісти, Black/Green Belts, Чемпіони операційної ефективності, лідери впровадження, офіс впровадження.
  • Базове навчання. Спільна Lean-мова і інструментарій: 5S, стандартизована робота, інструменти вирішення проблем, картування процесів (КПСЦ), базова статистика, візуальний менеджмент.
  • Комунікації та історії успіху. Внутрішні кейси, візуалізація ефектів, «швидкі перемоги».

На цьому етапі Lean-функція неминуче «веде за руку»: ініціює проєкти, проводить воркшопи, будує карти, готує аналітику. Це нормально — культура ще не навчилась вдосконалюватися самостійно.

 

Етап 2. Масштабування: від проєктів до системи

Ключова роль — системний дизайнер і коуч для лідерів.

Фокус зміщується:

  • Від «робити проєкти» → до «будувати систему управління». Тут стає ключовою логіка David Mann: стандартна робота керівника, щоденні зустрічі, візуальні дошки, ескалація проблем.
  • Зміна ролі: з керівника проєкту на коуча. Lean/CI-спеціалісти:
    • допомагають лінійним керівникам будувати власні системи управління,
    • реплікують і стандартизують кращі практики,
    • створюють критерії масштабування.
  • Розвиток кадрового резерву. Люди не повинні назавжди залишатися в CI/OpEx. Через 2–3 роки вони мають переходити в лінію з більшою відповідальністю.

Ключовий індикатор Етапу 2: більшість ініціатив запускає лінійний менеджмент, а Lean/CI їх підтримує, а не тягне.

 

Етап 3. Стійкість: «розчинення» в лінії

Ключова роль — хранитель принципів і внутрішній консультант.

У зрілих системах:

  • лінійні керівники сприймають кайдзен як частину щоденної роботи;
  • є невелика група внутрішніх сенсеїв.

На цьому етапі:

  • 90% щоденних покращень реалізуються в лінії,
  • Lean-системи вбудовані в стратегію, бюджетування і управління ефективністю,
  • Центр операційної ефективності займається оцінками, розвитком принципів і проривними змінами, а не операційним менеджментом інструментів.

 

  1. Коли і чому Lean-функція має «зникнути» в лінії

Автори Liker, Mann і Shingo сходяться в одному: ідеальний стан — коли принципи і поведінка стали ДНК організації.

Якщо через 8–10 років:

  • кожне велике покращення потребує Lean-спеціаліста,
  • заводи чекають, поки «приїде корпоративний Lean»,
  • без Lean ніхто не пише A3 і не проводить ефективні стендапи,

то сильний Lean-департамент — це симптом незрілої системи.

Чому?

  • Розділена відповідальність. Покращення — «це їхня програма».
  • Фокус на інструментах замість поведінки.
  • Паралельна ієрархія. OpEx починає конкурувати з операційним блоком.

 

  1. Як передавати відповідальність у лінію

4.1. Переписати матриці RACI

Спочатку:
Lean — Responsible & Accountable
Лінія — Consulted / Informed

Середина шляху:
Лінія — Responsible
Lean — Accountable за методологію

Зрілість:
Лінія — Responsible & Accountable
Lean — Consulted

 

4.2. Вбудувати Lean в стандартну роботу керівника

Lean-обов’язки мають стати частиною формальної ролі керівників:

  • майстри — щоденна gemba, ескалація проблем, підтвердження стандартів;
  • керівники напрямків — щотижневий перегляд A3 і потоків;
  • топи — gemba, підтримка принципових рішень, узгодження систем.

Lean не «робить замість лідера», а спостерігає, коучить і змінює систему.

 

4.3. Правильний розмір команди змін

  • на старті — команда більша і виконує практичні задачі;
  • у зрілості — 0,1–0,3% персоналу;
  • робота в операційній ефективності — це розвиткова ротація, а не кар’єра на все життя.

 

  1. Як зрозуміти, чи ви готові «розчиняти» функції Lean

Оцінка Shingo Insight

Оцінює, наскільки принципи Shingo реально живуть у:

  • поведінці лідерів,
  • поведінці співробітників,
  • системах компанії.

Дає карту зрілості культури та систем.

 

  1. Висновок: справжнє призначення Lean / CI / OpEx
  1. На старті функція необхідна і здорова.
  2. Якщо через 5–10 років операції «чекають Lean» — система незріла.
  3. Справжня мета Lean-функції — зробити себе непотрібною в щоденних покращеннях і залишитися хранителем принципів і архітектором системи.

Наступний крок для читача — чесно оцінити, де знаходиться його організація: чи їй ще потрібен сильний «центральний двигун», чи вже час зробити Lean частиною щоденного лідерства.

Оригінал статті тут: https://www.linkedin.com/pulse/why-lean-department-sign-immature-operating-zsfgf/

Powered by WordPress & Theme by Anders Norén