Архітекторський рівень — всі 28 тем в одному місці

Мета системи операційних покращень — підвищення ефективності компанії шляхом безперервних поліпшень. Програми ОП збільшують загальну продуктивність на 10–30%.

Три важелі операційної ефективності

• Операційні поліпшення (Лінкор) — оптимізація процесів (усунення втрат), «розшивка» вузьких місць, зниження витрат, скорочення оборотних коштів
• Інвестиції — оновлення обладнання, придбання продуктивнішої техніки, використання випробуваних технологій світового досвіду
• Інновації — впровадження нових технологій, виведення нових продуктів на ринок
• Результат — впровадження програми ОП збільшує загальну продуктивність на 10–30% за даними міжнародної практики

Структура команди Лінкор

1. Координаційний комітет — вибір пілотного підрозділу, постановка цілей проекту, контроль та затвердження результатів, забезпечення необхідними ресурсами
2. Керівник проекту — управління проектом, координація між учасниками, контроль виконання задач
3. Проектна команда — 1–3% від чисельності персоналу підрозділу. Аналіз виробничих процесів, розробка та впровадження ініціатив підвищення ефективності
4. Критерії відбору учасника — ініціативність, аналітичне мислення, знання процесів підприємства, навички наставництва, роботи в команді та координації між підрозділами

Мобілізація людського потенціалу

"70% трансформацій провалюються не через інструменти — через людей. Lean впроваджується в голови, а не в цехи. Перша перемога будує довіру — довіра відкриває людей до змін."

Модель: Готовий — Налаштований — Здатний

• Готовий — знає що і навіщо змінювати. Чіткі цілі прив'язані до мотивації
• Налаштований — хоче змінюватись. Культура, лідерство, колективна відповідальність
• Здатний — вміє змінюватись. Навчання інструментам і обмін найкращим досвідом
• Головне завдання — щоб зміни були впроваджені й утримані, не просто запущені

6 чинників мобілізації:

1. Цілі — прозора система цілей прив'язана до відповідної системи мотивації
2. Управління ініціативами — простий процес від генерації ідеї до впровадження та відстеження ефекту
3. Залучення персоналу — залучення ВСІХ співробітників, не тільки команди впровадження
4. Управління знаннями — навчання інструментам і обмін найкращими практиками між підрозділами
5. Культура та лідерство — виробнича культура і колективна відповідальність за результати компанії
6. Організація — структура що сприяє розвитку ініціативи, а не гасить її процедурами

Погляд консалта: типові помилки

• Навчати інструментам до першої перемоги — знання без мотивації не застосовуються
• Команда 1–3% впроваджує Lean за всіх — замість того щоб заражати решту прикладом
• Говорити про користь для компанії — людина змінюється коли бачить користь для себе
• Великі проблеми вирішуються зверху. Дрібні — тільки залученим персоналом знизу

"Учасник команди Лінкор — штатний співробітник, тимчасово повністю звільнений від основних обов'язків і зайнятий формуванням культури ощадливого виробництва. Не консультант ззовні — своя людина, що знає процес зсередини."

Критерії відбору — 3 виміри

• Особисті якості — ініціативність, відкритість новому, лідерські якості, аналітичний склад розуму, нацеленість на результат
• Навички — робота в команді, виявлення кореневих причин, наставництво, зворотний зв'язок, координація між підрозділами
• Знання — технічна експертиза, розуміння взаємозв'язків між процесами, власні ідеї щодо підвищення ефективності
• Ключова умова — повне звільнення від основних обов'язків. Lean «по сумісництву» — не працює

5 компетенцій Lean-архітектора

1. Інструменти Lean — знати, застосовувати на практиці та вміти навчати інших — три рівні одної компетенції
2. Аналітика — структурний підхід до проблем, кількісний аналіз, оцінка ризиків та пошук альтернативних шляхів
3. Результативність — орієнтація на результат, пріоритизація задач, пошук найкоротшого шляху до ефекту
4. Командна робота — взаємодія, повага до думки інших, ентузіазм і мотивація на успіх всієї команди
5. Комунікація — спілкування з персоналом, логічний виклад думок, ефективне представлення результатів

Програма розвитку Lean-архітектора

• Базовий тренінг — Lean та інструменти СНС, комунікація в команді, структуроване мислення
• Аналітика і дані — Excel: обробка масивів даних, діаграми. PowerPoint: презентації результатів
• Поглиблений тренінг — система управління ефективністю, оцінка ініціатив, методологія розрахунку економічного ефекту
• Тренінг із впровадження — управління проектами, проведення експериментів, технічна документація, утримання ефекту

Погляд консалта

• Lean-архітектор — внутрішній агент змін, а не технічний спеціаліст з Lean
• Найкращі кандидати — ті кого колеги вже слухають, а не ті хто краще знає теорію
• Інструменти — 20% роботи. Зміна поведінки людей — 80%
• Різниця між знавцем Lean і архітектором — вміння передати знання так щоб люди почали діяти

"Kaizen, який тримається на ентузіазмі кількох людей, помирає разом з їхньою мотивацією. Kaizen, який тримається на системі — переживає зміну керівництва."

Три рівні Kaizen у зрілій системі

• Quick Kaizen (мікрорівень) — ідея впроваджується оператором/майстром за 1 день без погоджень. Бюджет: до символічної суми, ліміт визначає майстер дільниці
• Team Kaizen (рівень процесу) — 1-3-денний Kaizen-воркшоп міжфункціональної команди на конкретну проблему дільниці. Результат — впроваджене рішення до кінця воркшопу, не звіт «на потім»
• Project Kaizen (системний рівень) — переростає в А3-проект (Модуль 28), коли причина виходить за межі однієї дільниці або потребує інвестицій

Архітектура системи управління ідеями

1. Єдина точка входу — одна форма/дошка для всіх ідей, незалежно від розміру. Складна форма = менше ідей
2. SLA на реакцію — 48 год на першу відповідь (прийнято / відхилено з поясненням / потребує уточнення). Мовчання вбиває довіру швидше за відмову
3. Прозорий статус — кожен бачить свою ідею на дошці: подано → в роботі → впроваджено → ефект підтверджено
4. Власник процесу приймає рішення — не централізований комітет. Децентралізація = швидкість

Метрики зрілості Kaizen-культури

• Охоплення — % співробітників, що подали хоча б 1 ідею за квартал. Ціль зрілої системи: 60%+
• Швидкість впровадження — середній час від ідеї до впровадження. Toyota: медіана < 1 тижня для Quick Kaizen
• Конверсія — % впроваджених ідей від поданих. Низька конверсія (<30%) — сигнал про завищені бар'єри входу, не про «погані ідеї»
• Повторюваність — % співробітників, що подають ідеї регулярно (не одноразово)

Типові пастки при масштабуванні на підприємство

• Kaizen-тиждень замість Kaizen-системи — разовий захід дає сплеск активності і швидке згасання
• KPI «кількість поданих ідей» без KPI «% впроваджених» — стимулює кількість формальних заявок замість якості рішень
• Централізований комітет-«бутилка» — усі ідеї чекають затвердження зверху; черга на місяці вбиває мотивацію
• Відсутність зворотного зв'язку по відхилених ідеях — автор має зрозуміти чому «ні»

Роль Lean-архітектора

1. Спроєктувати SLA та маршрут ідеї (хто приймає рішення на кожному рівні бюджету/складності)
2. Інтегрувати Kaizen-метрики в стандартну звітність підрозділу, не окремий «Lean-звіт»
3. Навчити майстрів і керівників дільниць приймати рішення на місці — без цього Quick Kaizen не працює
4. Раз на квартал — аудит зрілості культури за 4 метриками вище, а не лише підрахунок кількості ідей

"КПСЦ без чотирьох етапів методики — просто малюнок. З методикою — це інженерний проект."

Чотири етапи побудови КПСЦ (повна методика)

1. Визначення вимог клієнта та етапів процесу — оберіть варіант продукції для аналізу; зафіксуйте вимоги покупця, частоту постачання, коливання попиту; пропишіть усі стадії, які проходить продукція
2. Нанесення потоків матеріалів та інформації — комунікація з покупцями/постачальниками; характер матеріальних потоків; централізоване чи неформальне планування
3. Внесення даних по процесу — тривалість циклу; час запуску обладнання; рівень надійності; розмір партії; рівень запасів; кількість співробітників
4. Визначення часових параметрів — довжина виробничого циклу всіх етапів; тривалість перебування напівфабрикатів на складі; загальна тривалість циклу

Алгоритм класифікації кожного етапу процесу

• Необхідний для виробництва? Ні → Підтримує бізнес-функцію (закон, регламент)? Так → Дія: усунення або мінімізація
• Необхідний для виробництва? Ні → Підтримує бізнес-функцію? Ні → чисті втрати → Дія: усунення
• Необхідний для виробництва? Так → Відповідає вимогам клієнта? Так → Дія: оптимізація (не видалення — вдосконалення)

Дерево створення вартості (Value Tree) — доповнює КПСЦ, не замінює

• Value Tree: візуалізація з високим рівнем деталізації, прив'язка операційних показників до фінансових елементів вартості. Застосування — фінансове моделювання, аналіз чутливості EBITDA
• VSM: послідовність дій у ланцюжку вартості, дані про запаси/потужності/обсяги. Застосування — знайти процеси без доданої вартості і вузькі місця
• Коли який — Value Tree відповідає на «скільки грошей і де саме», VSM відповідає на «де в потоці ця втрата фізично живе»

Модель Кано — перш ніж картувати потік, зрозумій ЩО саме є цінністю для клієнта

• Базові вимоги (Must-be) — мінімум, що не створює задоволеності сам по собі, але його відсутність викликає гостре незадоволення
• Очікувані вимоги (Performance) — задоволеність росте пропорційно якості виконання
• Випереджальні вимоги (Delighters) — викликають «захоплення» за наявності, але не незадоволення за відсутності
• Фактор часу — Delighters з часом стають Performance, а Performance — Must-be. Вчорашня «родзинка» — сьогоднішній мінімум

Аналіз голосу клієнта (VOC) для кожного вхідного сигналу фіксує: ключові проблеми → реальні потреби → критично важливі вимоги. Це вхідні дані для Етапу 1 методики КПСЦ вище.

Типові помилки архітектора при масштабуванні VSM

• Карта майбутнього стану малюється в переговорній без операторів — Гемба-складова методики пропущена
• КПСЦ будується один раз і не оновлюється — потік змінюється, карта старіє за квартал
• Фокус лише на виробничих кроках, без інформаційних потоків — половина втрат ховається саме там

Роль Lean-архітектора

1. Встановити стандартний цикл оновлення КПСЦ для кожного продуктового потоку
2. Пов'язати кожен «майбутній стан» з конкретним власником і датою
3. Використовувати Value Tree для вибору ЯКИЙ потік картувати першим
4. Навчити керівників читати класифікаційний алгоритм самостійно

"Такт-тайм каже правду, навіть коли план каже інше."

Повний розрахунковий кейс — від замовлення до перебалансованої лінії

Умови: замовлення клієнта 800 деталей/день, 2 зміни по 4 години, перерва 30 хв у кожній зміні.

1. Доступний робочий час: 2 × 4 год = 480 хв, мінус перерви 60 хв → 420 хв доступного часу
2. Час такту: 420 хв ÷ 800 деталей = 31,5 сек на деталь
3. Фактичний час циклу за етапами: різка металу 45 сек, свердління 40 сек, гнуття 35 сек, зварювання 55 сек, фарбування 60 сек
4. Вузькі місця: фарбування (60 сек) і зварювання (55 сек) — обидва суттєво перевищують такт. Вузьких місць може бути кілька одночасно

Пакет рішень для лінії з кількома вузькими місцями

1. Паралелізація станцій — 2 фарбувальні станції замість однієї: кожна працює з циклом 30 сек замість 60
2. Автоматизація найповільнішого кроку — маніпулятори для зварювання скорочують час операції без додавання людей
3. Усунення транспортних втрат між кроками — конвеєрна система замість ручного перенесення деталей
4. Паралельні лінії/зміни — розподілити частину обсягу, якщо перебалансування станцій недостатньо

Проектування системи, що витримує зміну попиту

• Такт не сталий — перераховується щоразу, коли змінюється попит клієнта. Гнучка система — та, де перебалансування триває години, а не тижні
• Резерв потужності — проєктуй станції з запасом 10-15% нижче такту, а не рівно на межі
• Модульність станцій — проєктуй обладнання, що можна швидко здублювати, а не тільки прискорити
• Yamazumi як інструмент проєктування, не лише аудиту (Модуль 25) — використовуй ДО запуску лінії

Типові помилки архітектора

• Балансувати лінію під одне вузьке місце, коли їх насправді два
• Купувати додаткове обладнання до того, як вичерпано паралелізацію і усунення втрат
• Проєктувати під поточний попит без запасу гнучкості

Роль Lean-архітектора

1. Затвердити єдину методику розрахунку такту для всіх ліній підприємства
2. Вимагати аналіз ВСІХ операцій відносно такту при проєктуванні нової лінії
3. Закладати резерв гнучкості ще на етапі проєктування
4. Пов'язати перегляд такту з циклом бюджетування

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

Дерево створення вартості — каскад від P&L до кореневої причини

Фінансові показники → Операційні показники → Кореневі причини та важелі:

• Виручка ← Ефективність обладнання ← Коефіцієнт готовності, рівень простоїв ← Якість ремонтів, наявність запчастин
• Витрати ← Енергоефективність ← Питомі витратні показники ← Втрати енергії, втрати при зберіганні палива
• Витрати ← Матеріалоефективність ← Питомі витратні показники ← Високий рівень запасів, неекономна витрата
• EBITDA ← Якість ← Рівень дефектів ← Якість обладнання, якість ремонтів

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

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

• Розклади проблему на чіткі лінії аналізу з вагою впливу — наприклад: Лінія А (50%), Лінія В (40%), Лінія С (10%)
• Пріоритизуй факти всередині кожної лінії: які важливі й уже проаналізовані, на які неможливо вплинути, які варті аналізу пізніше
• Це запобігає пастці: команда витрачає тиждень на аналіз лінії С (10% ваги), поки лінія А (50%) чекає

Розширення TOC-циклу на рівень підприємства

1. Знайди — не «вузьке місце цеху», а вузьке місце, що обмежує виручку/маржу всього підприємства
2. Використай — максимально завантаж це обмеження ще до інвестицій — часто 20-30% прихованої потужності знаходиться без капітальних витрат
3. Підпорядкуй — усі суміжні підрозділи підлаштовують свій темп і пріоритети під системне обмеження
4. Розшир — інвестиції тільки після вичерпання кроків 2-3, і тільки в точку, визначену деревом вартості
5. Повтори — обмеження системи переміщується після кожного циклу; дерево вартості треба перебудовувати

Типові помилки архітектора

• TOC застосовується на рівні цеху, а інвестиційні рішення ухвалюються на рівні підприємства без зв'язку між ними
• Дерево вартості будується один раз при запуску проекту і не оновлюється
• Пріоритизація фактів (50%/40%/10%) пропускається — команда аналізує все з однаковою глибиною

Роль Lean-архітектора

1. Побудувати й підтримувати Дерево створення вартості підприємства як живий інструмент
2. Забезпечити, щоб кожен новий А3-проект явно посилався на гілку дерева вартості, яку він закриває
3. Раз на квартал — перевірити, чи не змістилось системне обмеження підприємства
4. Навчити керівників підрозділів пріоритизувати факти за вагою впливу

"PDCA і DMAIC — це інструменти які МІНЯЮТЬ процес. Але хто змінить 400 людей, які звикли працювати по-старому? Це вже не інструмент — це модель Коттера."

8 кроків моделі Коттера — послідовність, яку не можна пропускати

1. Створення відчуття невідкладності — без болю немає руху. Покажіть дані: скільки втрачаємо щомісяця
2. Формування коаліції лідерів змін — не самотній ентузіаст, а 5-10 впливових людей з різних рівнів і підрозділів
3. Формування бачення і стратегії — куди йдемо і чому саме туди. Одне речення, яке зрозуміє будь-хто
4. Комунікація бачення — повторюйте в 10 разів частіше ніж здається достатнім
5. Усунення перешкод — структурні бар'єри, застарілі KPI, опір керівників середньої ланки
6. Швидкі перемоги — перший видимий результат за 60-90 днів
7. Закріплення здобутків і нові зміни — не зупинятись на першій перемозі
8. Укорінення в культурі — нова поведінка стає «як у нас прийнято», а не «спецпроект з Lean»

Чому 70% програм змін провалюються (за дослідженнями Коттера)

• Пропускають крок 1 — починають з рішення, не створивши відчуття невідкладності
• Святкують перемогу заскоро — після кроку 6 визнають проект завершеним. Кроки 7-8 пропущені
• Бачення не комунікується достатньо — керівник сказав один раз на зборах

Зв'язок з PDCA/DMAIC: Коттер — модель зміни системи. PDCA/DMAIC — інструменти зміни процесу. Архітектор використовує Коттера щоб впровадити САМУ культуру PDCA на підприємстві.

Типові помилки архітектора

• Впровадження Lean-інструментів без кроків 1-4 Коттера — інструмент є, зацікавленості немає
• Коаліція лідерів формується лише з топ-менеджменту — без майстрів зміна не проникає на рівень цеху
• Немає плану на кроки 7-8 — святкували перше SMED чи Kaizen-воркшоп, а системного закріплення не спланували

Роль Lean-архітектора

1. Провести діагностику готовності до змін за 8 кроками Коттера перед запуском масштабної Lean-програми
2. Сформувати коаліцію змін з представників усіх рівнів
3. Спланувати послідовність швидких перемог на 12 місяців наперед
4. Перевести Кроки 7-8 у конкретні артефакти — оновлені посадові інструкції, KPI, ритуали

«Генті Генбуцу (現地現物) — наявний товар на місцях. Директор, який керує лише за звітами, керує вчорашнім днем.»

П'ять правил менеджменту Гемба

1. Коли виникає проблема — треба йти на Гемба, до місця робочого процесу, а не викликати людей до кабінету
2. На Гембі — перевір Гембуцу: огляни фізичне оточення, а не тільки вислухай пояснення
3. Приймай рішення й контрзаходи безпосередньо на Гембі, поки факти ще «неспотворені»
4. Після цього знайди причину виникнення проблеми — «5 Чому» (Модуль 18) або діаграма Ішикави
5. Недопущення повторення — зафіксуй рішення в стандартах та інструкціях (СОП, Модуль 15)

Чотири дії на Гемба

1. Йти в місце виконання робочого процесу
2. Дивитися на поточний процес — без упереджень щодо «як має бути»
3. Спостерігати за тим, що відбувається насправді, включно з відхиленнями від стандарту
4. Збирати дані та факти — muda walk: цілеспрямований аналіз втрат просто на робочому місці

Каскад Gemba-культури зверху вниз

• Директор — 1-2 обходи/місяць, фокус на системних бар'єрах між підрозділами
• Керівник підрозділу — щотижня, фокус на стабільності процесу і виконанні стандартів
• Майстер/бригадир — щодня, фокус на конкретних відхиленнях і швидких контрзаходах
• Без каскаду Gemba залишається одноразовою модою одного ентузіаста-директора

Типові помилки архітектора

• Gemba walk перетворюється на інспекцію з блокнотом «хто винен»
• Рішення приймаються після Гемби, у кабінеті, «щоб все обдумати»
• Немає зв'язку між тим, що знайдено на Гембі, і оновленням стандартів

Роль Lean-архітектора

1. Спроєктувати каскад регулярності Gemba walk по рівнях управління
2. Створити єдиний формат фіксації спостережень
3. Навчити керівників задавати відкриті питання на Гембі замість закритих перевірочних
4. Пов'язати знахідки з Гемби напряму з Kaizen-системою і waste ledger (Модуль 9)

"Втрата, яку не перевели в гривні, — для фінансового директора не існує. Waste Accounting — це переклад Lean-мови на мову P&L."

5 видів втрат — причини та фінансові важелі

• Перевиробництво — фінансовий важіль: вартість капіталу, замороженого в НЗВ і готовій продукції
• Дефекти — фінансовий важіль: Cost of Poor Quality (COPQ) — брак + переробка + рекламації + втрачена довіра клієнта
• Надлишкові запаси — фінансовий важіль: вартість зберігання + ризик знецінення запасу
• Надлишкова обробка — фінансовий важіль: собівартість операцій, за які клієнт не платить
• Надмірні переміщення — фінансовий важіль: втрачений продуктивний час × вартість людино-години

Побудова Waste Accounting системи

1. Waste ledger — реєстр, що конвертує кожну знайдену Kaizen-ідею чи А3-проект у гривні на P&L конкретного підрозділу
2. Категоризація за 8 видами — щомісячний зріз: у якій категорії найбільший потенціал цього кварталу
3. Пріоритизація за Парето (Модуль 20) — топ 20% причин втрат зазвичай дають 80% фінансового ефекту
4. Верифікація ефекту — фінансовий контролер підтверджує цифру до того, як вона потрапляє у звіт керівництва

Типові помилки архітектора

• Рахувати лише видимі втрати (брак, простої), ігноруючи приховані (запаси, зайва обробка, переміщення)
• Waste ledger без власника результату
• Одноразовий waste-аудит замість системи, що оновлюється щомісяця

Роль Lean-архітектора

1. Спроєктувати єдину методику монетизації втрат, однакову для всіх підрозділів
2. Інтегрувати waste ledger у фінансовий цикл підприємства
3. Навчити керівників підрозділів рахувати вартість власних втрат самостійно
4. Раз на квартал — звірка накопиченого ефекту waste ledger з фактичним P&L

"Кейс з розпилювачем переконує майстра. Фінансовому директору потрібні цифри в іншому форматі — hard savings, soft savings, і термін окупності. Архітектор говорить обома мовами."

Структура бізнес-кейсу Lean-проекту

• Проблема і базова лінія — поточний стан у грошах: скільки коштує статус-кво щороку
• Hard savings (тверда економія) — прямо знижує витрати або вивільняє потужність: менше браку, менше понаднормових, вивільнені FTE
• Soft savings (м'яка економія) — покращує умови, але не одразу видно в P&L: менша плинність, менше травм, вища залученість
• Інвестиція — вартість команди, обладнання, навчання, консультації
• Термін окупності — інвестиція ÷ річна hard-економія × 12 місяців

Правило класифікації hard vs soft

• Hard: вивільнений FTE ТІЛЬКИ якщо людину реально перевели на іншу продуктивну роль або скоротили вакансію
• Hard: менше браку — пряме зниження собівартості, легко перевірити за даними якості
• Soft: покращення морального клімату, швидша адаптація новачків — реальна цінність, але не в чисельник ROI

Портфельна пріоритизація Lean-проектів

1. Розрахувати ROI і термін окупності для кожного кандидата
2. Оцінити складність впровадження (низька/середня/висока) — незалежно від фінансового ефекту
3. Матриця 2×2: Ефект × Складність — квадрант «високий ефект, низька складність» — виконувати негайно
4. Проекти «високий ефект, висока складність» — окремий А3, спонсорство на рівні директора

Типові помилки архітектора

• ROI рахується «на глибину» з завищеними hard savings — підриває довіру фінансового директора
• Кейс подається без базової лінії — «покращили на 30%» від чого?
• Не рахується вартість підтримки рішення — Kaizen без бюджету на моніторинг деградує за квартал

Роль Lean-архітектора

1. Впровадити єдиний шаблон бізнес-кейсу для всіх Lean-проектів підприємства
2. Вести портфельний реєстр: всі активні і завершені проекти з фактичним ROI
3. Навчити власників А3 рахувати ROI самостійно
4. Раз на квартал звіряти сумарний ефект портфеля з фактичними даними P&L

"Yellow Belt вирішує проблему яку бачить. Black Belt вирішує проблему яку весь завод вважає невирішуваною — і вимірює це статистикою, а не відчуттям."

Чим Black Belt-проект відрізняється від Kaizen/DMAIC на рівні підрозділу

• Причина невідома навіть експертам — якщо майстер і технолог не можуть на Гемба вказати причину, потрібен статистичний аналіз
• Множинні змінні — дефект залежить від комбінації 5-10 факторів одночасно
• Повна зайнятість — Black Belt веде проект 100% часу 4-6 місяців
• Фінансовий поріг — типовий Black Belt-проект: очікуваний ефект від 10 млн грн/рік

Статистичний інструментарій понад базовий DMAIC

• MSA (Measurement System Analysis) — перш ніж вимірювати процес, перевір чи вимірювальна система сама достатньо точна
• Перевірка гіпотез (Hypothesis testing) — чи різниця статистично значуща, чи це випадковий шум
• Регресійний аналіз — кількісний зв'язок між вхідними факторами (X) і результатом (Y): Y = f(X)
• Контрольні карти (Control charts) — після Improve: чи процес стабільний у часі

Project Charter для Black Belt-проекту (розширення А3 з Модуля 28)

1. Бізнес-кейс — фінансовий вплив, зв'язок зі стратегією підприємства
2. Постановка проблеми — конкретна, з базовою лінією Sigma-рівня (поточний DPMO)
3. Мета — цільовий DPMO/Sigma-рівень і дата
4. Межі проекту (Scope) — що входить, що свідомо виключено
5. Команда і ролі — Black Belt (веде), Green Belt (підтримка), Champion (спонсор з топ-менеджменту)

Типові помилки архітектора при масштабуванні Six Sigma

• Black Belt призначається без захисту часу — проект розтягується на рік замість 4-6 місяців
• Обирають Black Belt-проект там де причина насправді очевидна — переплата за статистику
• Немає Champion на рівні топ-менеджменту — міжфункціональні бар'єри зупиняють проект

Роль Lean-архітектора

1. Формалізувати критерії відбору: коли проблема йде в Kaizen/PDCA, а коли ескалується в Black Belt-проект
2. Розвинути внутрішній пул Green Belt → Black Belt через реальні проекти
3. Забезпечити кожному Black Belt-проекту Champion і захищений час команди
4. Вести реєстр Sigma-рівнів по ключових процесах

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

Розширення Pull за межі цеху — три рівні

1. Внутрішньоцеховий Pull — між операціями однієї лінії (базовий Канбан)
2. Міжцеховий Pull — супермаркети між підрозділами з власними WIP-лімітами на кожному
3. Pull з постачальниками (VMI / зовнішній Канбан) — постачальник бачить рівень запасу і сам поповнює за сигналом

Розрахунок розміру супермаркету

Кількість Канбан-карток = (Середній попит за період поповнення + Буфер безпеки) ÷ Розмір контейнера

• Буфер безпеки залежить від варіабельності попиту І варіабельності часу поповнення
• Занадто малий буфер → дефіцит і зупинки. Занадто великий → Канбан перетворюється на замаскований push
• Переглядати розмір супермаркету щоквартально — попит змінюється, статичний Канбан застаріває

CONWIP як альтернатива класичному Канбану

• Класичний Канбан — картка на кожен SKU. Ефективно при стабільному асортименті
• CONWIP (Constant Work In Process) — загальний ліміт WIP на всю лінію, незалежно від SKU
• Коли обирати — багато SKU з нерегулярним попитом → CONWIP. Стабільний асортимент → класичний Канбан

Закон Літтла — математика, що стоїть за Pull

Lead Time = WIP ÷ Швидкість виробництва. Єдиний спосіб скоротити Lead Time без збільшення потужності — зменшити WIP.

Типові помилки архітектора при масштабуванні Pull

• Впроваджують Канбан на одній дільниці, а постачання сировини лишається на місячних замовленнях push
• E-Kanban впроваджують без спочатку відпрацьованого паперового Канбану
• Немає власника перегляду карток — кількість Канбан встановили рік тому і не переглядали

Роль Lean-архітектора

1. Картувати Pull-ланцюг цілком — від постачальника до клієнта
2. Впровадити VMI або зовнішній Канбан з ключовими постачальниками
3. Встановити регулярний цикл перегляду розміру супермаркетів і кількості карток
4. Навчити керівників рахувати WIP і Lead Time через закон Літтла

"Компанія з переналагодженням 2 години планує виробництво на місяць вперед і продає прогноз. Компанія з переналагодженням 10 хвилин продає гнучкість — і забирає клієнтів, яким прогноз не потрібен."

Економічний розмір партії (EOQ) — чому SMED змінює саму формулу

• Класична формула EOQ балансує вартість переналагодження проти вартості зберігання запасу
• SMED атакує саме змінну «вартість переналагодження» — знизьте її в 5 разів, і оптимальний розмір партії теж падає в рази
• Наслідок — менші партії → менше WIP і готової продукції на складі → менше замороженого капіталу

Гнучкість як ринкова стратегія, не тільки виробнича метрика

• Make-to-stock економіка — великі партії, прогноз попиту, ризик неліквіду при помилці прогнозу
• Make-to-order з коротким SMED — виробництво під конкретне замовлення, менший ризик
• Гібридна стратегія — стабільний асортимент (80% обсягу) партіями більшими; змінний (20%, вища маржа) — SMED-режим

Матриця пріоритизації SMED-проектів на рівні підприємства

• Вісь 1: Частота переналагодження. Вісь 2: Тривалість переналагодження
• Квадрант «висока частота × велика тривалість» — перший кандидат SMED, найбільший фінансовий важіль
• Квадрант «низька частота × мала тривалість» — не інвестувати

Модель вартості переналагодження: (Втрачений час × Вартість години простою) + (Вартість браку налагодження) + (Понаднормові через відставання від плану)

Реальний кейс Multiformer → Revoportion: −41,2% (34→20 хв) — від пілоту до програми

1. Пілот (1 обладнання) — повний цикл SMED з відеозйомкою, командою, виміряним результатом
2. Документування методології — стандартний playbook: як знімати відео, класифікувати дії, шаблон аналізу
3. Навчання внутрішніх SMED-коучів — 2-3 людини з пілотної команди стають тренерами
4. Тиражування — SMED-коучі ведуть проекти самостійно, архітектор — лише на складних випадках

Система підтримки результату (щоб −41,2% не стало +15% через півроку)

• Візуальний стандарт на обладнанні — нова послідовність дій зафіксована на фото/схемі біля станка, власник — майстер зміни, не архітектор
• Регулярний контрольний хронометраж — раз на квартал перевіряти відповідність новому стандарту
• Управління інвестиціями — спочатку організаційні рішення (безкоштовно), тільки потім капітальні (оснастка); ROI рахується на рівні всієї програми, не одного пілоту

Типові помилки архітектора

• SMED впроваджують на обладнанні з рідкісними переналагодженнями — нульовий фінансовий ефект
• Скорочений час переналагодження не використовується для зменшення партії — виграш «з'їдається» старими обсягами
• Кожен новий SMED-проект веде особисто архітектор — вузьке місце програми, масштабування обмежене його часом
• Результат не підтримується контрольним хронометражем і немає зв'язку з відділом продажів — виграш поступово «з'їдається», а комерційна пропозиція не змінюється

Роль Lean-архітектора

1. Побудувати матрицю пріоритизації SMED для всього парку обладнання і керувати портфелем інвестицій за нею
2. Формалізувати playbook на основі першого пілоту і підготувати пул внутрішніх SMED-коучів
3. Впровадити систему контрольного хронометражу для підтримки результатів
4. Звести операційну гнучкість з комерційною стратегією підприємства

"5С без системи аудиту — це один суботник на рік. 5С як частина архітектури управління — це стандарт, що тримається без вашої присутності."

Система оцінки зрілості 5С (5-рівнева шкала)

1. Хаос — немає сортування, немає позначених місць
2. Базовий порядок — сортування і систематизація проведені одноразово, тримаються тиждень-два
3. Стандарт — чек-листи є, аудит проводиться, але не завжди веде до дії
4. Система — регулярні аудити з наслідками, відхилення виправляються за 48 годин
5. Культура — оператори самі ініціюють покращення 5С без нагадування

Каскад аудитів 5С за рівнями управління

• Оператор — самоаудит на початку і в кінці зміни (5 хв)
• Майстер — щотижневий аудит дільниці за чек-листом з балами
• Начальник цеху — щомісячний аудит з фокусом на трендах
• Директор — щоквартальний огляд зведеного рейтингу всіх дільниць

Зв'язок 5С з формальними KPI

• Безпека — кореляція між балом 5С дільниці і кількістю інцидентів
• Якість — захаращене робоче місце корелює з вищим рівнем дефектів
• OEE — час пошуку інструменту напряму знижує компонент «Продуктивність» (Модуль 17)

Типові помилки архітектора

• 5С запускається як разова акція без системи регулярних аудитів
• Аудит існує, але результати ніде не публікуються і не мають наслідків
• Немає зв'язку 5С з бонусною системою чи офіційними KPI

Роль Lean-архітектора

1. Впровадити єдину 5-рівневу шкалу зрілості 5С для всього підприємства
2. Встановити каскад аудитів з обов'язковими наслідками для низьких балів
3. Інтегрувати бал 5С у формальну систему KPI підрозділу
4. Проводити щоквартальний бенчмарк дільниць

"Один хороший СОП вирішує одну проблему. Система управління СОП на 500+ документів вирішує проблему втрати знань при звільненні будь-якого співробітника підприємства."

Життєвий цикл СОП — від створення до архівації

1. Створення — Гемба → кращі практики → відео → формалізація
2. Затвердження — власник процесу + технічний експерт погоджують перед випуском
3. Впровадження — навчання всіх виконавців, перевірка розуміння
4. Періодичний перегляд — плановий цикл перегляду навіть якщо явних проблем немає
5. Оновлення через Kaizen — кожне покращення = нова версія СОП з датою і номером
6. Архівація — застарілі версії зберігаються окремо для аудиту

Дворівнева система документів

• Візуальний СОП (на робочому місці) — 1 сторінка, фото/схема, критерії якості
• Детальний СОП (в системі) — повний опис з винятками, історією версій

Матриця компетенцій (Skill Matrix)

• Кожна операція — рядок, кожен оператор — колонка. Значення: не навчений / навчається / кваліфікований / може навчати
• Використання — планування відпусток без втрати покриття критичних операцій; виявлення точок ризику
• Рівень «кваліфікований» присвоюється тільки після навчання за актуальним СОП і практичної перевірки

Аудит відповідності Гемба ↔ СОП

Оператор виконує «по-своєму», СОП застарів — тривожний сигнал. Дія архітектора: спосіб оператора кращий → оновити СОП; спосіб гірший → повернути до стандарту і з'ясувати чому відхилились.

Типові помилки архітектора

• СОП пишуться централізовано технологами без залучення операторів
• Немає єдиного власника методології СОП на підприємстві
• Перегляд СОП відбувається тільки «коли стався інцидент»

Роль Lean-архітектора

1. Впровадити єдиний стандарт формату і життєвого циклу СОП
2. Побудувати і підтримувати матрицю компетенцій
3. Запровадити плановий цикл перегляду СОП
4. Регулярно аудитувати розбіжність Гемба↔СОП і використовувати як джерело Kaizen-ідей

"Один Poka-Yoke пристрій закриває одну помилку. Стратегія Zero Defect закриває здатність системи народжувати нові помилки."

Вартість якості (Cost of Quality)

• Витрати на запобігання (Prevention) — навчання, Poka-Yoke, СОП, дизайн процесу. Найдешевші, часто недооцінені
• Витрати на оцінку (Appraisal) — контроль, інспекція, тестування. Не усувають дефект, лише виявляють
• Внутрішні втрати від браку (Internal Failure) — переробка, утилізація, простій
• Зовнішні втрати від браку (External Failure) — найдорожче: рекламації, повернення, втрата довіри клієнта

Правило 1-10-100: вартість усунення дефекту зростає в 10 разів на кожному наступному етапі — джерело (1) → наступна операція (10) → клієнт (100).

Від точкового Poka-Yoke до системи Zero Defect

1. Реєстр дефектів підприємства — всі дефекти за типом, частотою, вартістю, точкою виникнення
2. Пріоритизація за Парето (Модуль 20) — 20% типів дефектів, що дають 80% втрат
3. Вибір типу захисту — фізичний спочатку, сенсорний якщо фізичний неможливий, процедурний як мінімум
4. Верифікація ефекту — вимір частоти дефекту до і після, протягом кварталу

Якість на джерелі vs контроль на виході

• Контроль на виході — 100% інспекція готової продукції. Дорого, не запобігає, лише сортує
• Якість на джерелі — кожен оператор перевіряє свою операцію ПЕРЕД передачею далі + Poka-Yoke на ризикованих кроках

Типові помилки архітектора

• Інвестують у Poka-Yoke без реєстру дефектів — вирішують «помітну», а не найдорожчу проблему
• Zero Defect подають як гасло для персоналу замість системної роботи над причинами
• Appraisal-витрати не скорочують після впровадження Poka-Yoke — платять двічі

Роль Lean-архітектора

1. Побудувати реєстр дефектів підприємства з класифікацією за Cost of Quality
2. Пріоритизувати Poka-Yoke інвестиції за Парето-аналізом дефектів
3. Системно скорочувати Appraisal-витрати по мірі впровадження якості на джерелі
4. Звітувати керівництву структуру Cost of Quality щоквартально

"Стандартна система вимірювання порівнює факт з бюджетом, побудованим на історичній продуктивності — тому показує майже 100% ефективності завжди. ОЕЕ порівнює з абсолютним ідеалом — і показує правду."

Повний каскад від календарного часу до цінності

1. Календарний час (365 днів × 24 год) = плановий робочий час + надлишкова потужність
2. Плановий робочий час → Втрати доступності → Експлуатаційний час
3. Експлуатаційний час → Втрати ефективності → Чистий експлуатаційний час
4. Чистий експлуатаційний час → Втрати якості → Час, що створює додану вартість

Три коефіцієнти каскаду

• КТГ (Рівень технічної готовності) = Експлуатаційний час ÷ Плановий час
• КВО (Коефіцієнт використання обладнання) = Чистий експлуатаційний час ÷ Експлуатаційний час
• КМЧ (Рівень якості) = Час доданої вартості ÷ Чистий експлуатаційний час

Класифікація втрат за методикою МОП (1957)

• A — викликані конструктивними дефектами або дефектами специфікації
• B — викликані неадаптованими методами роботи
• C — викликані помилками організації
• D — викликані ставленням робітників

A/B — питання інвестицій та інженерії, C — організації, D — культури і навчання. Різні бюджети, різні власники рішення.

Типові помилки архітектора

• OEE вважається виробничою метрикою «для цеху», а не активом фінансового аналізу
• Плутають КТГ/КВО/КМЧ з простим A/P/Q
• Порівнюють OEE різних ліній без урахування типу обладнання і продукту

Роль Lean-архітектора

1. Впровадити єдину методику розрахунку каскаду календарного часу для всіх ключових активів
2. Класифікувати кожну категорію втрат за МОП A/B/C/D і направити відповідному власнику рішення
3. Інтегрувати OEE-каскад у щомісячний огляд капітальних інвестицій
4. Навчити фінансовий відділ читати КТГ/КВО/КМЧ як мову активів

"Один Ішикава на одну проблему — інструмент майстра. Стандартизований Ішикава-протокол на всі повторювані проблеми підприємства — інструмент архітектора."

Мультикатегорійний аналіз якості — другий повний кейс

10% продукції з дефектами. Аналіз одночасно по всіх 6M: Персонал (навчання, дисципліна), Методи (час смаження, порядок змішування), Матеріали (якість сировини), Обладнання (калібрування), Оточення (температура, вологість), Вимірювання (точність приладів).

Системна відмінність архітектурного підходу від майстрового

• Майстер запускає Ішикаву при виникненні конкретної проблеми на своїй дільниці
• Архітектор стандартизує: коли запускати, хто модерує (не винуватець проблеми), як фіксується (шаблон А3), куди йде результат (реєстр рішень)
• Без стандарту той самий корінь проблеми аналізується заново на кожній дільниці окремо

Побудова реєстру кореневих причин підприємства

1. Кожен завершений аналіз реєструється з категорією 6M, кореневою причиною і рішенням
2. Перед новим аналізом — перевірка реєстру: чи не аналізувалась вже подібна проблема на іншій дільниці
3. Патерни по категоріях — якщо 60% причин потрапляють у «Методи» — сигнал про системну прогалину в СОП
4. Реєстр — вхідні дані для Waste Accounting (Модуль 9) і пріоритизації Kaizen-програми (Модуль 3)

Типові помилки архітектора

• 5 Чому зупиняється на першій зручній відповіді, а не на системній помилці
• Ішикава проводиться людиною, відповідальною за процес, що аналізується — конфлікт інтересів
• Реєстр ведеться, але ніхто не аналізує патерни по категоріях раз на квартал

Роль Lean-архітектора

1. Затвердити стандартний тригер і шаблон запуску Ішикава + 5 Чому для всього підприємства
2. Забезпечити незалежну модерацію аналізу
3. Вести і щоквартально аналізувати реєстр кореневих причин на предмет системних патернів
4. Пов'язати реєстр з навчальною програмою

"6 напрямків ТРМ — операційний рівень. Стратегія надійності — це питання яке обладнання отримує ресурс в першу чергу, і як виміряти що інвестиція в ТО повернулась."

RCM — Reliability Centered Maintenance

1. Класифікація обладнання за критичністю — вплив відмови на безпеку, якість, обсяг виробництва
2. Критичне обладнання (єдина точка відмови) — максимальний рівень: планове + автономне + предиктивна діагностика
3. Некритичне обладнання — базовий рівень ТО, ремонт за фактом економічно виправданий
4. Результат — ресурс ремонтної служби спрямований туди, де відмова коштує найдорожче

Від профілактичного до предиктивного обслуговування

• Реактивне (найдорожче) — ремонт після поломки
• Профілактичне — за розкладом, незалежно від реального стану вузла
• Предиктивне — датчики вібрації, температури, аналіз мастила. ТО за реальним станом

MTBF і MTTR

• MTBF (Mean Time Between Failures) — середній час між відмовами. Зростає завдяки автономному і плановому ТО
• MTTR (Mean Time To Repair) — середній час усунення відмови. Скорочується завдяки SMED-підходу до ремонту
• Availability = MTBF / (MTBF + MTTR) — компонент A в OEE (Модуль 17) залежить від обох

Типові помилки архітектора

• Автономне обслуговування впроваджують скрізь одночасно замість пілоту на критичному обладнанні
• Немає розділення MTBF і MTTR у звітності
• Предиктивні датчики закуповуються без попередньої класифікації критичності

Роль Lean-архітектора

1. Провести класифікацію парку обладнання за критичністю (RCM)
2. Впровадити роздільний облік MTBF і MTTR по кожній критичній одиниці
3. Обґрунтувати інвестицію в предиктивну діагностику фінансовою моделлю
4. Пов'язати стратегію запасних частин з критичністю обладнання через Value Tree

"Парето не вирішує проблему. Він рятує команду від вирішення не тієї проблеми."

Місце Парето в чотирьох групах аналізу проекту

1. Аналіз ефективності — витрати за ланцюжком створення цінності, VOC, КПСЦ наступного рівня
2. Аналіз кореневих причин і важелів — Парето звужує список причин з Ішикави до «важливих небагатьох»
3. Оцінка важелів і постановка цілей — вплив на показники, деталізація за часом і обсягом
4. Пілотні проєкти та пріоритизація — об'єднання ініціатив, запуск хвилі 1

Ланцюжок інструментів

Парето (що вирішувати першим) → Ішикава (які категорії причин) → 5 Чому (чому це відбувається) → А3 (Модуль 28). Пропуск будь-якої ланки ламає ланцюжок.

Де Парето застосовується системно на рівні підприємства

• Після Ішикави — список причин → Парето → топ 20% → 5 Чому тільки по них
• ТРМ та ОЕЕ (Модулі 17, 19) — типи поломок → фокус ТО на 20% обладнання, що дає 80% простоїв
• Управління якістю — типи дефектів → 20% видів браку = 80% рекламацій
• Kaizen-пріоритизація (Модуль 3) — топ-20% ідей за ефектом отримують ресурс першими

Типові помилки архітектора

• Парето будується один раз на старті проєкту і не оновлюється
• Категорії для діаграми обираються довільно, без єдиного стандарту
• Команда «вирішує все потрошку» замість фокусу на топ-20%

Роль Lean-архітектора

1. Вбудувати Парето як обов'язковий крок між збором причин і оцінкою важелів
2. Стандартизувати категорії збору даних для кожного типу аналізу
3. Вимагати оновлений Парето при кожному перегляді А3-проекту
4. Навчити команди зупинятись на топ 20% свідомо

"Хто атакує лише Муду — грає в вибивання кротів. Хто усуває Муру — вимикає джерело, що породжує решту двох."

Мура — детальна причинно-наслідкова карта

• Причини: погане прогнозування попиту; незбалансованість виробничих етапів; варіативність процесів; система мотивації, що заохочує нерівномірні пориви активності
• Усунення: Канбан для витягування (Модуль 12); балансування такту (Yamazumi, Модуль 25); єдині стандарти праці (Модуль 15); мотивація за збалансоване, а не «ударне», виробництво

Мурі — детальна причинно-наслідкова карта

• Причини: сама варіативність (Мура — перевантаження майже завжди вторинне); низький рівень організації робочого місця; погана якість ремонтів; відсутність інструментів
• Усунення: усунення Мура — первинна дія; 5С (Модуль 14); якість ремонтів і автономне ТО (Модуль 19); навчання і якість інструктажів

Програма трансформації — послідовність, а не паралельна атака

1. Спочатку Мура — стабілізуй попит і завантаження (S&OP, Heijunka, буфери Канбан)
2. Потім Мурі — знімай перевантаження людей і обладнання: ергономіка, автономне ТО, навчання
3. Тоді Муда стає видимою і дешевою для усунення
4. Вимірюй на кожному кроці — варіація завантаження, понаднормові/травматизм/поломки, ОЕЕ і waste ledger

Типові помилки архітектора

• Запускати Kaizen-програму на усунення Муда, не займаючись плануванням (джерелом Мури)
• Трактувати скарги на перевантаження як «слабкість персоналу», а не сигнал про системну Мурі
• Вимірювати тільки середні показники завантаження, ігноруючи розкид

Роль Lean-архітектора

1. Побудувати систему раннього виявлення Мури — дашборд варіації завантаження по дільницях
2. Пов'язати ергономічний аудит з програмою автономного ТО і 5С
3. Встановити послідовність трансформації (Мура → Мурі → Муда) як стандарт для нових А3-проектів
4. Захищати ресурси на стабілізацію — керівництво завжди хоче одразу «усунути втрати»

"MIRA аудитує один процес за раз. Lean-аудит підприємства відповідає на інше питання: наскільки зріла Lean-система в цілому — і хто наступний повинен отримати ресурс на розвиток."

Три виміри зрілості Lean-системи

1. Інструменти (Tools) — чи впроваджені 5С, Канбан, SMED, Poka-Yoke, VSM там де це доцільно
2. Система управління (Management System) — чи є регулярний ритм: добові наради, KPI-дошки, каскад аудитів
3. Культура (Culture) — чи персонал сам ініціює Kaizen, чи Andon зупинку сприймають як геройство

Шкала зрілості Lean-аудиту

• Рівень 1 — Початковий: окремі інструменти без системи
• Рівень 2 — Повторюваний: інструменти на кількох дільницях, немає єдиного стандарту
• Рівень 3 — Визначений: єдина методологія, регулярні аудити
• Рівень 4 — Керований: дані аудитів впливають на пріоритизацію ресурсів
• Рівень 5 — Оптимізований: самостійна культура покращень

Калібрування аудиторів

Різні аудитори по-різному оцінюють один і той же чек-лист. Рішення — спільний аудит «каліброваної команди» раз на квартал: 2-3 аудитори оцінюють одну дільницю незалежно, звіряють бали.

Типові помилки архітектора

• Аудит оцінює тільки наявність інструментів, ігноруючи систему управління і культуру
• Немає калібрування — рейтинг підприємства втрачає довіру
• Результати аудиту не впливають на розподіл ресурсу

Роль Lean-архітектора

1. Розробити єдину трьохвимірну модель зрілості для всього підприємства
2. Сформувати і регулярно калібрувати команду внутрішніх Lean-аудиторів
3. Прив'язати результати аудиту до розподілу ресурсів розвитку
4. Раз на рік переглядати саму методологію аудиту

"Один воркшоп покращує один процес за 5 днів. Портфель з 20 воркшопів на рік, підпорядкований стратегії — це вже механізм тиражування Lean по всьому підприємству."

Річний календар Kaizen-воркшопів

1. Стратегічна прив'язка — кожен воркшоп закриває конкретний розрив зі стратегічної карти (Hoshin Kanri, Модуль 27)
2. Розподіл по кварталах — рівномірне навантаження на ресурс фасилітаторів
3. Баланс складності — суміш «легких перемог» і складніших міжфункціональних воркшопів
4. Резерв гнучкості — 20% календаря незаплановим для нових пріоритетів

Розвиток внутрішніх фасилітаторів

• Рівень 1 — Учасник. Рівень 2 — Співфасилітатор. Рівень 3 — Фасилітатор. Рівень 4 — Майстер-фасилітатор
• Мета архітектора — не бути єдиним фасилітатором, а мати пул із 5-10 підготовлених людей

Kaizen Event Fatigue — і як її уникнути

Симптом: та сама команда бере участь у 4-му воркшопі за рік, ентузіазм падає. Рішення: ротація учасників, чіткий зв'язок з business impact, святкування результатів.

Типові помилки архітектора

• Воркшопи обираються реактивно, а не за стратегічною пріоритизацією
• Один і той самий фасилітатор веде всі воркшопи підприємства — вузьке місце програми
• Немає закріплення через 30-60-90 днів на рівні всього портфеля

Роль Lean-архітектора

1. Скласти річний календар воркшопів, прив'язаний до стратегічних пріоритетів
2. Побудувати пул внутрішніх фасилітаторів через систему з 4 рівнів розвитку
3. Відстежувати ознаки Kaizen Event Fatigue і свідомо ротувати учасників
4. Звітувати портфельний ROI програми щорічно топ-менеджменту

"VSM однієї лінії картує один потік. Архітектор бачить підприємство як портфель потоків — і будує організаційну структуру, яка відповідає за кожен з них наскрізно."

Розширена карта потоку (Extended VSM)

Включає постачальника сировини і кінцевого клієнта як повноцінні вузли карти. Вузьке місце часто ховається НЕ в цеху, а на стику — очікування сировини, запаси на складі дистриб'ютора.

Value Stream Manager

• Проблема традиційної структури — начальник цеху відповідає за функцію, ніхто не відповідає за потік цілком
• Рішення — власник наскрізного потоку відповідає за Lead Time і PCE від сировини до клієнта
• Матрична структура — координує з начальниками цехів, тримає Future State VSM і план переходу

Портфель потоків підприємства

1. Картувати всі продуктові сімейства окремими VSM
2. Порівняти PCE і Lead Time кожного потоку
3. Ранжувати за фінансовим важелем через Value Tree (Модуль 6)
4. Розподілити ресурс Lean-команди пропорційно пріоритету

Типові помилки архітектора

• Кожен цех картує свій шматок ізольовано — розриви на стиках залишаються невидимими
• Немає власника потоку — Future State VSM залишається малюнком без повноважень щось змінити
• Портфель потоків не пріоритизується фінансово

Роль Lean-архітектора

1. Побудувати розширену VSM для ключових продуктових сімейств
2. Впровадити роль Value Stream Manager
3. Вести портфель потоків з фінансовою пріоритизацією через Value Tree
4. Звітувати наскрізні метрики на рівні топ-менеджменту щоквартально

"Yamazumi балансує лінію яка вже існує. Проектування збалансованої системи — це рішення яке приймається ДО того, як куплено перше обладнання."

Балансування на етапі проектування vs існуючої лінії

Проектне балансування — операції розбиваються на станції ще до закупівлі обладнання, з запасом під takt-коливання. Перепроектувати на етапі креслення коштує в рази менше, ніж переробляти після монтажу.

Балансування при змішаному асортименті (Mixed-Model)

• Зважений Takt Time — розрахунок через середньозважений час з урахуванням частки кожного SKU
• Найдовша операція серед усіх SKU визначає мінімальну кількість станцій — проектувати під найскладніший продукт

Буфери між збалансованими станціями

Невеликий буфер між станціями з найвищою варіабельністю циклу амортизує коливання. Розрахунок розміру буфера — на основі реальної варіабельності CT (стандартне відхилення), не інтуїтивно.

Ротація операторів

Статичне закріплення — вища швидкість навчання, але вищий ризик монотонних травм. Ротація кожні 1-2 години — нижчий ергономічний ризик, ширша кваліфікація (матриця компетенцій, Модуль 15).

Типові помилки архітектора

• Лінія проектується під середній Takt Time, а не під найдовшу операцію серед усього асортименту
• Буфери розставляються «про всяк випадок» рівномірно замість розрахунку на основі варіабельності
• Баланс перевіряється один раз при запуску і ніколи при зміні асортименту

Роль Lean-архітектора

1. Залучатись до проектування нових ліній ДО закупівлі обладнання
2. Впровадити методику зваженого Takt Time для ліній зі змішаним асортиментом
3. Розраховувати розмір буферів на основі статистичної варіабельності CT
4. Впровадити систему ротації операторів там, де ергономічний ризик найвищий

"KPI-дошка дільниці показує стан однієї лінії. Корпоративна система візуального управління — це те, як інформація з 20 дощок доходить до директора за 10 хвилин щоранку, без жодного звіту в Excel."

Каскад візуальних дощок за рівнями управління

1. Дошка оператора/зміни — погодинний факт/план, Andon-статус. Оновлюється щогодини
2. Дошка дільниці/лінії — денні підсумки, тренд тижня. Оновлюється щодня
3. Дошка цеху — тижневі тренди, топ-3 проблеми. Оновлюється щотижня
4. Дошка підприємства (Obeya) — стратегічні KPI, статус Hoshin-цілей (Модуль 27). Оновлюється щомісяця

Obeya (大部屋) — фізична кімната стратегічного управління

Одна кімната з усіма стратегічними візуалізаціями: Hoshin X-матриця, портфель А3-проектів, VSM ключових потоків. Щотижнева нарада керівництва саме тут, а не в переговорній з презентацією.

Стандартизація візуальної мови між дільницями

Єдина колірна кодировка і базовий набір метрик (OEE, FTT, безпека, Kaizen-статус) на кожній дошці — щоб керівник розумів будь-яку дошку без пояснень.

Типові помилки архітектора

• Кожен цех вигадує власний формат дошки — керівник не може швидко прочитати чужу дільницю
• Цифрові дошки впроваджуються на рівні оператора — втрачається залученість
• Немає каскаду — дошка підприємства існує окремо від дошок цехів

Роль Lean-архітектора

1. Спроєктувати каскад візуальних дощок за 4 рівнями
2. Створити або визначити Obeya-простір для щотижневих стратегічних нарад
3. Затвердити єдиний візуальний стандарт для всіх дільниць
4. Визначити межу фізичне/цифрове для кожного рівня каскаду

"Каскад цілей у 4 рівні показує ЩО каскадується. X-матриця — конкретний інструмент, яким архітектор пов'язує стратегію, тактику, процеси і людей на одному аркуші."

Структура X-матриці — чотири зони одного документа

• Ліва зона — довгострокові стратегічні цілі (3-5 років)
• Нижня зона — річні пріоритети поточного року
• Права зона — очікувані результати (метрики): OEE, FTT, Lead Time
• Верхня зона — процеси і власники: хто відповідає за який пріоритет

Catchball — узгодження цілей знизу-вгору і згори-вниз

Ціль «перекидається» між рівнями: директор пропонує → начальник цеху оцінює здійсненність і повертає з коригуванням → узгодження до консенсусу. Цілі, узгоджені через catchball, мають вищий рівень виконання.

Річний цикл Hoshin Kanri

1. Огляд минулого року — які цілі досягнуті, чому
2. Формування 3-5 річних пріоритетів — не більше, інакше розпорошення
3. Catchball по рівнях — узгодження до консенсусу
4. Щомісячний огляд X-матриці — 30 хв, у тому ж Obeya (Модуль 26)
5. Річний перегляд — новий цикл з урахуванням результатів

Типові помилки архітектора

• X-матрицю заповнює тільки топ-менеджмент без catchball
• Забагато річних пріоритетів (10+) — це вже список побажань, не стратегія
• X-матриця складається раз на рік і не переглядається

Роль Lean-архітектора

1. Впровадити X-матрицю як єдиний формат зв'язку стратегії, пріоритетів, метрик і власників
2. Провести процес catchball між рівнями управління
3. Прив'язати портфель Kaizen/Black Belt/SMED-проектів до річних пріоритетів
4. Встановити щомісячний ритм огляду X-матриці в Obeya

"Одну А3-команду можна тримати на ентузіазмі власника. Портфель з 15 А3-команд на три роки тримається тільки на системі підбору, ролей і групового мислення."

Командні ролі за методологією Белбіна

• Генератор ідей, Дослідник, Координатор, Творець, Експерт, Реалізатор, Виконавець, Дипломат, Спеціаліст — 9 ролей, кожна зі своєю силою і слабкістю
• Задача архітектора — не шукати ідеальних кандидатів, а закривати ролями склад команди з 3-5 осіб

Матриця ефективності команди

• Низький фокус на задачах + низький на стосунках → «Контора»: дублювання зусиль, апатія
• Високий фокус на задачах + низький на стосунках → «Бурлаки»: результат є, але без синергії
• Низький фокус на задачах + високий на стосунках → «Пікнік»: команда згуртована, результат посередній
• Високий фокус на задачах + високий на стосунках → «Чемпіон»: результат вищий за суму внесків

SMART-цілі для А3 — 9 етапів постановки

Потреба → Актуальність → Конкретизація → Вимірність → Дедлайн → Досяжність → Перешкоди → Декомпозиція → Нагорода. Без кроків «Потреба» і «Перешкоди» на початку і «Декомпозиція» в кінці, ціль лишається гарним формулюванням без плану досягнення.

Методики групового мислення

• Мозковий штурм у 2 фази — дивергенція (без критики) → конвергенція (категоризація, ранжування)
• Метод «Шести капелюхів» (де Боно) — для команд, де дискусія зациклюється на одній позиції
• Метод «Мішень» — швидка альтернатива повній матриці пріоритизації (Модуль 6)

Типові помилки архітектора

• Портфель А3-проєктів росте, а система підбору ролей і діагностики команд — ні
• Групове мислення використовується епізодично, а не як стандартний інструментарій
• Немає ретроспективи на етапі розформування — досвід не переноситься на наступний проєкт

Роль Lean-архітектора

1. Впровадити діагностику команд за матрицею ефективності як частину квартального огляду портфеля
2. Навчити власників А3 базовим ролям Белбіна
3. Стандартизувати 2-3 техніки групового мислення як частину методології А3-воркшопу
4. Побудувати 3-річний roadmap як план розвитку самої проєктної спроможності підприємства