Про Lean Six Sigma часто говорять як про щось складне і суто статистичне, доступне лише великим корпораціям з окремим відділом аналітиків. Насправді в основі методології лежить проста управлінська ідея: рішення про зміни у процесі слід ухвалювати на підставі даних, а не на підставі досвіду й інтуїції окремих людей. Усе інше – інструменти, які допомагають цю ідею реалізувати.
Ця стаття пояснює, з чого складається методологія, звідки взялася цифра «шість сигм», як влаштований цикл DMAIC і – що важливіше за все – у яких ситуаціях Lean Six Sigma дає результат, а в яких її застосування буде марною витратою часу команди.
Коротко: що таке Lean Six Sigma
Lean Six Sigma – це поєднання двох методологій, які виросли з різних джерел і вирішують різні завдання.
Six Sigma працює з мінливістю процесу. Логіка тут послідовна: будь-який процес має природну мінливість; мінливість створює можливості для помилки; можливості для помилки перетворюються на ризик дефекту; дефект призводить до незадоволеного споживача і прямих втрат грошей. Зменшуючи мінливість, ми зменшуємо кількість дефектів, а разом з ними – собівартість процесу.
Lean, або бережливе виробництво, працює з втратами і швидкістю потоку. Його питання інше: які дії в процесі не створюють цінності для споживача і як їх прибрати, щоб продукт проходив шлях від замовлення до відвантаження швидше й дешевше.
Чому їх поєднали. Процес може бути швидким, але нестабільним: продукція виходить за дві години замість восьми, але кожна десята одиниця йде в брак. І навпаки, процес може бути бездоганно стабільним, але настільки повільним і перевантаженим зайвими операціями, що жодна стабільність цього не виправдовує. Lean сам по собі не дає інструментів, щоб довести причину мінливості статистично. Six Sigma сам по собі не бачить втрат у потоці. Найкращий результат зазвичай виходить тоді, коли з процесу прибирають і дефекти, і втрати одночасно.
У нашій таксономії методологій операційної досконалості ми відносимо Lean Six Sigma до дослідницьких методологій підвищення результативності процесів. Це принципово відрізняє її від Lean і TPM, які працюють з потоком створення цінності та з надійністю обладнання. Lean Six Sigma застосовують тоді, коли звичайних експертних знань недостатньо і потрібні статистичні методи оцінки проведених експериментів.
Звідки взялася цифра «шість сигм»
Сигма – це літера, якою в статистиці позначають стандартне відхилення, тобто міру розкиду значень навколо середнього. Чим менший розкид відносно меж допуску, тим більше «сигм» вміщується між середнім значенням процесу і межею, за якою починається брак.
Рівень сигми прийнято виражати через кількість дефектів на мільйон можливостей. Різниця між сусідніми рівнями нелінійна, і саме це робить показник корисним для управлінських рішень.
| Рівень сигми | Дефектів на мільйон можливостей | Частка придатної продукції |
|---|---|---|
| 1 сигма | 690 000 | 31,0% |
| 2 сигми | 308 000 | 69,2% |
| 3 сигми | 66 800 | 93,32% |
| 4 сигми | 6 210 | 99,379% |
| 5 сигм | 233 | 99,977% |
| 6 сигм | 3,4 | 99,99966% |
Зверніть увагу на крок між третім і четвертим рівнем: кількість дефектів падає більш ніж у десять разів. Саме тому Волтер Шухарт свого часу визначив процес, який працює на рівні трьох сигм, як процес, що потребує втручання. Для бізнесу це означає, що витрати на помилки зростають не поступово, а лавиноподібно, щойно якість процесу просідає.
Порахувати поточний рівень нескладно. Спочатку визначають вихід придатної продукції:
Вихід = (кількість можливостей – кількість дефектів) / кількість можливостей × 100
Наприклад, ділянка пакування обробляє 150 000 одиниць на тиждень. Вибірковий контроль показує приблизно 750 дефектів. Вихід становить 99,5%, що за таблицею відповідає рівню приблизно 4,1 сигми.
Чому рівень сигми не можна читати механічно
Поширена помилка – вишикувати процеси за рівнем сигми і взятися за найгірший. Уявіть харчове виробництво, де нанесення декоративного елемента працює на рівні 2,2 сигми, пакування – на рівні 3,1, а відвантаження – на рівні 4,3.
Формально найгірший процес очевидний. Але якщо порушення герметичності упаковки означає, що партію доведеться утилізувати, а крива декоративна смужка лише трохи псує вигляд виробу, то починати слід з пакування. Рівень сигми показує, наскільки процес нестабільний. Він не показує, скільки ця нестабільність коштує компанії. Рішення про пріоритет ухвалюють, зіставляючи рівень сигми з ціною дефекту і з доступними ресурсами.
Сім видів втрат, з якими працює Lean
Друга складова методології розглядає процес з точки зору дій, які не додають цінності. Тайіті Оно, головний інженер Toyota, виділив сім категорій таких втрат, японською – муда.
- Надвиробництво. Продукт виготовлено зарано, у надмірній кількості або швидше, ніж його здатен спожити наступний процес.
- Виправлення. Брак, доопрацювання, повторна обробка того, що вже мало бути готовим.
- Запаси. Сировина, незавершене виробництво і готова продукція, що лежать без руху і заморожують гроші.
- Рухи. Зайві переміщення людини на робочому місці: нахили, пошук інструмента, кроки до стелажа і назад.
- Транспортування. Переміщення матеріалів і деталей, яке не змінює продукт, а лише переносить його з місця на місце.
- Надмірна обробка. Операції, точність або якість яких перевищує те, за що споживач готовий платити.
- Очікування. Простій людини, обладнання або партії, поки щось інше не буде готове.
Частину цих втрат видно простим оглядом ділянки, частину – ні. Саме тому Lean Six Sigma використовує картування потоку створення цінності: воно показує процес цілком і виявляє ті втрати, які з окремого робочого місця непомітні.
Базовий курс BPI Academy, що поєднує філософію Lean і методи Six Sigma. Логіка DMAIC, робота з даними та перший проєкт поліпшення на практиці.
Коротка історія методології
Lean Six Sigma зазвичай асоціюється з Toyota і Motorola, але її коріння сягає значно глибше.
Статистичну основу заклав Карл Фрідріх Гаус у XIX столітті, описавши нормальний розподіл. На початку XX століття Волтер Шухарт зробив два кроки, без яких методології не існувало б: він першим пов’язав рівень сигми з якістю і створив контрольні карти – інструмент, який дозволяє втримати досягнутий результат після завершення проєкту.
Едвардс Демінг переніс ідеї Шухарта за межі промисловості та сформулював цикл «Плануй – Виконуй – Перевіряй – Дій». Після Другої світової війни Демінг працював у Японії, де його ідеї лягли в основу виробничої системи Toyota. Кіітіро Тойода, Ейдзі Тойода і Тайіті Оно доповнили їх концепціями точно вчасно та дзідока – принципу, за яким процес зупиняють одразу після виявлення відхилення, а не шукають причину браку наприкінці лінії.
Власне Six Sigma народилася в Motorola у середині 1980-х. Приводом стало неприємне відкриття: японська компанія, що перебрала завод Motorola з виробництва телевізорів, почала випускати ту саму продукцію з кількістю дефектів у двадцять разів меншою. Генеральний директор Боб Гелвін поставив команді завдання підвищити якість у десять разів за пʼять років. Інженери Білл Сміт і Мікел Гаррі зрозуміли, що для цього потрібна інша одиниця виміру: замість дефектів на тисячу можливостей вони почали рахувати дефекти на мільйон. За наступні дванадцять років програма безперервних поліпшень заощадила компанії понад 16 мільярдів доларів.
Далі методологію доопрацювали ще тричі. В ABB Мікел Гаррі додав до неї фінансову логіку: проєкт має оцінюватися за впливом на результат бізнесу, а не лише за приростом якості. В Allied Signal Ларрі Боссіді наполіг, що вище керівництво має розбиратися в методології особисто, інакше воно не зможе обирати правильні проєкти й підтримувати їх. А General Electric під керівництвом Джека Велча зробила крок, який і досі залишається найкращою ілюстрацією управлінської підтримки: результати в Six Sigma привʼязали до системи винагороди співробітників. На момент старту GE працювала на рівні між трьома і чотирма сигмами, а потенційна економія оцінювалася в 7-10 мільярдів доларів.
DMAIC: як влаштований проєкт
Те, що відрізняє Lean Six Sigma від більшості підходів до поліпшень, – це жорстка структура проєкту. Для вдосконалення наявного процесу застосовують цикл DMAIC з пʼяти фаз.
Define: визначити
Команда формулює проблему, межі проєкту та критерії успіху. На цьому етапі зʼявляється статут проєкту: склад команди, відповідальні, формулювання проблеми, мета, показники та орієнтовні строки. Тут же описують процес на верхньому рівні та визначають зацікавлені сторони. Головна небезпека фази – розмитість: якщо межі не зафіксовані, проєкт почне розростатися і не завершиться ніколи.
Measure: виміряти
Команда збирає дані, щоб перевірити припущення, зроблені на попередній фазі. Це найтрудомісткіша частина проєкту, особливо коли потрібних даних раніше ніхто не збирав: доводиться створювати форми обліку, писати запити до систем або вимірювати вручну. Якщо з фази Define команда виходила з чернеткою формулювання проблеми, то з фази Measure вона має вийти з остаточною редакцією, підтвердженою цифрами.
Analyze: проаналізувати
Команда висуває гіпотези про причинно-наслідкові звʼязки між входами і виходом процесу і звужує коло підозрюваних до кількох найвагоміших причин. Саме тут статистичні методи дають те, чого не дає експертна думка: можливість відрізнити реальний вплив чинника від випадкового збігу.
Improve: покращити
Гіпотези перевіряють на практиці, обирають рішення і впроваджують їх. Паралельно рішення стандартизують, щоб їх можна було передати в щоденну роботу людям, які не входили до складу команди проєкту.
Control: закріпити
Фаза, яку найчастіше недооцінюють. Команда будує систему контролю, за якою процес не повернеться до попереднього стану, і передає відповідальність власнику процесу. Без цієї фази поліпшення тримається рівно стільки, скільки за ним особисто стежить керівник проєкту.
Коли процес треба не поліпшувати, а створювати заново, застосовують цикл DMADV: визначити, виміряти, проаналізувати, спроєктувати, верифікувати. Перші три фази схожі на DMAIC, а дві останні спрямовані на розробку та перевірку нового процесу або продукту. Іноді команда починає проєкт як DMAIC і переходить до DMADV, коли стає зрозуміло, що поліпшення наявного процесу бажаного результату не дасть.
Y = f(X): логіка, на якій усе тримається
Six Sigma розглядає будь-яку проблему як функцію. Y – це результат, який нас не влаштовує. X – це входи та чинники, які його формують. Завдання проєкту полягає в тому, щоб знайти ті кілька X, які справді визначають Y, і вплинути саме на них.
Приклад. Керівник сервісної бригади виявив, що його пʼятеро майстрів витрачають на виклик у 1,75 раза більше часу, ніж у середньому по компанії. Замість того щоб одразу вводити нормативи, він поїхав на виклики разом з кожним і зʼясував: один майстер – місцевий, знає половину клієнтів особисто і затримується на розмови; другий докладно пояснює господарям будову обладнання значно детальніше, ніж тим потрібно; третій працює нещодавно, перепровіряє себе і телефонує колегам за порадою. Двоє інших укладаються в норматив.
Проблема набула вигляду функції: додатковий час є функцією від зайвих розмов і недостатнього навчання. Замість одного розмитого «працюють повільно» керівник отримав дві конкретні причини, з якими можна працювати по-різному: перша вирішується стандартом комунікації з клієнтом, друга – програмою навчання.
Цінність цієї логіки не в математиці, а в дисципліні. Вона не дозволяє перестрибнути від симптому одразу до рішення – крок, на якому зривається більшість спроб щось покращити. Про прості інструменти такого аналізу ми писали в статті про метод «5 Чому», 5W1H і діаграму Ісікави.
Коли Lean Six Sigma доречна, а коли ні
Це найважливіший розділ для керівника, який вирішує, чи варто вкладати ресурс команди в такий проєкт.
Методологія виправдана в чотирьох ситуаціях:
- Причина невідома. Є показник, який поводиться не так, як потрібно, але чому – ніхто не знає. DMAIC дозволяє почати проєкт навіть у цьому стані.
- Проблема широка і погано визначена. Структура циклу стримує розростання меж і змушує рухатися кроками, замість того щоб узятися за все одразу і не завершити нічого.
- Процес складний, у ньому багато змінних. Коли чинників десятки, експертна думка перестає бути надійною, а статистичний аналіз дозволяє звести складну картину до кількох перевірених висновків.
- Ціна помилки висока. Коли невелика зміна параметра обертається значними сумами, припущення треба підтверджувати з мінімальною похибкою. Ані досвід, ані здоровий глузд такої точності не дають.
І щонайменше три ситуації, коли проєкт запускати не варто:
- Немає розриву між бажаним і поточним станом. Якщо різниці немає, покращувати нічого, а проєкт перетвориться на імітацію діяльності.
- Проблема очевидна, і рішення вже відоме. Якщо постачальник повідомив про дефектну партію матеріалу і надав інструкцію, потрібні дії, а не пʼять фаз DMAIC. Проходити цикл заради циклу – це витрата, а не поліпшення.
- Причина в людях і стосунках, а не в процесі. Статистика не лікує конфлікт у колективі чи наслідки невдалого призначення. Хоча тут є нюанс: якщо мотивація низька саме тому, що процес незручний і погано працює, то поліпшення процесу покращить і настрій команди.
Для простіших випадків існує аналіз корінних причин у форматах A3, QC Story або 8D. Вони спираються на базові інструменти якості, не потребують статистичної підготовки і для більшості щоденних проблем підходять краще.
Скільки коштує низька якість
Щоб керівництво ухвалило рішення про проєкт, потрібна не якість сама по собі, а гроші. Для цього в методології є показник вартості низької якості.
Його складають з двох частин. Зовнішні відмови виникають після того, як продукт потрапив до споживача: повернення, рекламації, гарантійний ремонт, втрата продажів через зіпсовану репутацію. Внутрішні відмови компанія виявляє в себе: брак, доопрацювання, ремонт, а разом з ними – затримки, нестача комплектуючих і втрачена гнучкість.
Айсберг. Очевидна частина витрат – це брак, повторна обробка, гарантійні випадки і додаткове перевезення. Її видно одразу. Під водою залишається значно більша частина: втрата лояльності клієнтів, падіння морального стану команди, звільнення людей, постійні перепланування графіків, зростання адміністративних витрат і непередбачуваність обсягів. Саме прихована частина зазвичай і робить низьку якість по-справжньому дорогою.
Практична користь показника проста. Якщо низька якість процесу коштує компанії певну суму щомісяця, а проєкт поліпшення коштує разово, то легко порахувати строк окупності й ухвалити зважене рішення. Проєкт, що окупається за сім місяців, і проєкт, який не окупиться ніколи, виглядають у презентації однаково переконливо, поки ніхто не порахував вартість низької якості.
Повна вартість якості включає ще дві категорії: витрати на запобігання дефектам (захист від помилок, навчання, планування якості) і витрати на оцінку (контроль, вимірювання, перевірки). Це витрати на відповідність вимогам, і скорочувати їх бездумно – найпоширеніший спосіб підвищити вартість низької якості.
Пояси: хто є хто в команді
Рівні підготовки в Lean Six Sigma позначають поясами. Кожен наступний рівень включає весь обсяг знань попереднього і додає свій. Нижче – структура за зводом знань Council for Six Sigma Certification.
- Білий пояс. Базове уявлення про методологію. Такий співробітник не входить до складу проєктних команд, але розуміє, навіщо вони працюють, і може осмислено брати участь в обговореннях.
- Жовтий пояс. Знає логіку DMAIC, ролі в команді, базові інструменти якості та основні показники, вміє збирати дані. Розуміє мову перевірки гіпотез і висновки, які з неї випливають, хоча сам таких перевірок не проводить. Це рівень учасника проєктної команди.
- Зелений пояс. Виконує основну частину збору та аналізу даних під керівництвом чорного пояса, володіє описовою статистикою, базовою перевіркою гіпотез і контрольними картами. Може самостійно вести невеликі проєкти у межах своєї функції. Зазвичай це керівник середньої ланки або аналітик, для якого поліпшення – частина роботи, а не основна посада.
- Чорний пояс. Керівник проєкту і агент змін. Відповідає за визначення проєкту та його меж, за строки і за комунікацію з керівництвом. Володіє статистикою на просунутому рівні, розуміє інші методології поліпшень, вміє проєктувати процеси та працювати зі спеціалізованим програмним забезпеченням.
- Майстер чорного пояса. Найвищий рівень. Керує чорними і зеленими поясами, консультує у складних випадках і навчає інших.
Окремо варто сказати про склад команди. Мінімальний комплект ролей – керівник проєкту, власник процесу, експерт з процесу і людина, яка відповідає за розрахунки та бюджет. Частину ролей може поєднувати одна людина. Оптимальний розмір постійного складу – близько пʼяти осіб: більша команда гірше керується і втрачає темп. Решту залучають точково, коли потрібна їхня експертиза.
Три міфи і чотири причини невдач
Хвиля впроваджень після успіху GE і Motorola залишила по собі не лише результати, а й стійкі хибні уявлення.
Міф перший: методологія підміняє здоровий глузд цифрами. Насправді більшість проєктів починається саме зі здорового глузду та досвіду людей, які працюють з процесом. Статистика потрібна не замість цього, а для того, щоб перевірити здогад до того, як компанія вкладе в нього гроші. Міф живучий з двох причин: керівникам, чиї рішення раніше не ставили під сумнів, незвично бачити спростування своєї позиції цифрами, а невміле використання статистики справді дозволяє обґрунтувати будь-яку дурницю.
Міф другий: це надто дорого. Розгортання в масштабі всієї компанії справді потребує інвестицій у навчання. Але поступове впровадження окремих елементів коштує небагато, а правильно обраний перший проєкт зазвичай окупає вкладення.
Міф третій: методологія вирішує будь-яку проблему. Lean Six Sigma застосовна до будь-якої проблеми процесу, але не до проблем культури і стосунків між людьми.
Що ж до реальних причин невдач, їх зазвичай чотири: відсутність підтримки керівництва, брак знань і ресурсів, невдало виконаний перший проєкт і проблеми з доступом до даних. Останні дві заслуговують на окрему увагу. Перший проєкт визначає ставлення компанії до методології на роки вперед, тому його варто обирати за принципом низького ризику і високої віддачі. А дані майже завжди виявляються гіршими, ніж очікувалося: потрібного показника ніхто не збирав, облік ведеться вручну, цифри спотворені припущеннями або надходять із запізненням. Закладайте на це час.
З чого почати
Якщо ви розглядаєте Lean Six Sigma для свого підприємства, розумний порядок дій виглядає так.
- Оцініть, у якому стані перебуває ваша виробнича система і які практики вже працюють. Без цього легко почати зі складного інструмента там, де не вистачає елементарного порядку.
- Знайдіть процес, де є виміряний розрив між поточним і бажаним станом, і де ціна цього розриву рахується в грошах.
- Перевірте, чи справді причина невідома. Якщо рішення очевидне, просто зробіть його.
- Підготуйте кількох співробітників до рівня жовтого і зеленого поясів, щоб у компанії зʼявилася спільна мова.
- Візьміть перший проєкт невеликим і доведіть його до фази контролю, а не до фази «начебто стало краще».
Базове розуміння методології дає онлайн-курс Lean Six Sigma в BPI Academy, а аудит виробничої системи допоможе визначити, з якого напряму почати саме вам.
Коротко про головне
Чим Lean Six Sigma відрізняється від Lean?
Lean працює з потоком створення цінності: усуває втрати і скорочує час проходження продукту. Lean Six Sigma – це дослідницька методологія, яка працює з результативністю окремого процесу і застосовує статистику там, де експертних знань недостатньо, щоб довести причину відхилення.
Чи потрібне підприємству програмне забезпечення для статистики?
На рівні жовтого і зеленого поясів більшість розрахунків виконується в табличному процесорі. Спеціалізоване програмне забезпечення стає потрібним на рівні чорного пояса, коли йдеться про дисперсійний аналіз, регресію та плановані експерименти.
Скільки триває один проєкт DMAIC?
Типовий проєкт зеленого пояса займає від трьох до шести місяців. Найдовша фаза – вимірювання, особливо якщо потрібних даних раніше ніхто не збирав і систему обліку доводиться створювати з нуля.
Чи працює методологія поза виробництвом?
Так. Motorola застосувала її в обслуговуванні клієнтів і технічній підтримці ще в 1990-х. Методологія придатна для будь-якого повторюваного процесу, де є вимірюваний результат: логістики, закупівель, документообігу, сервісу.
З якого поясу починати навчання команди?
З жовтого для учасників команд і з зеленого для тих, хто вестиме проєкти. Білий пояс має сенс як загальне ознайомлення, коли компанія розгортає методологію широко і потрібно, щоб усі розуміли, навіщо це робиться.
