Чому проекти Six Sigma зазнають невдачі на практиці

Незважаючи на те, що ця стаття може викликати несхвалення шанувальників методології Six Sigma, я все ж маю намір на реальному прикладі показати, чому більшість прагматичних клієнтів не зацікавлені в досягненні зверх-результатів, до яких прагне Six Sigma (3,4 дефекту на 1 000 000 операцій – прим. BPM-in-UA).

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

Астрофізика для колл-центру

Класичний приклад, без купюр, розповідає про реалізацію проєкту щодо поліпшення процесу «прийом дзвінка від клієнта» в колл-центрі за допомогою методології Six Sigma:

Мені потрібна допомога в реалізації проєкту Six Sigma, який багатьом може здатися простим: візьмемо процес« прийом дзвінка від клієнта». .

Критерієм якості даного процесу є час відповіді клієнту. Якщо вона більше 60 секунд, то – в термінології Six Sigma – це дефект. Для даного випадку кількість можливостей дорівнює 1. Припустимо, що з 300 дзвінків у 123 дзвінків час очікування клієнта перевищує 60 секунд. У цьому випадку значення Сигма дорівнюватиме 1,727. Дане значення було отримано за допомогою формули Сигма = НОРМСТОБР (1 123/300) +1,5. DPMO (кількість дефектів на мільйон можливостей) = 410000.

Чи може хто-небудь на підставі наведеного прикладу відповісти на питання: як мені отримати криву нормального розподілу? Звідки мені взяти значення нижньої і верхньої межі специфікації? Як побудувати криву нормального розподілу в Excel? З нетерпінням чекаю Ваших відповідей.

Прагматична відповідь

Я запитав BPM-консультанта про ситуацію, що описана вище, і він відповів наступне:

… Зрештою, якщо ви побудуєте криву нормального розподілу і скажете мені значення нижньої і верхньої межі специфікації, а також значення Сигма і DPMO, то що мені, з точки зору бізнесу, з цим робити, яка від цього користь?

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

Закон зниження ефективності

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

Припиніть покращувати процес до смерті і подивіться на проєкт з чистого аркуша.

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

Почати з нуля – непогана ідея

Нам потрібно донести до організацій і консультантів Six Sigma, що іноді потрібно припинити нескінченні поліпшення процесу і змінити підхід, щоб отримати максимальний результат. Ми повинні допомогти топ-менеджменту організацій зрозуміти, що доводити процес до досконалості – неправильно, навпаки, потрібно точно знати момент, коли слід зупинитися і переглянути підхід, почавши все з «чистого аркуша».

Нам всім (теоретикам і практикам) потрібно адаптувати методології під себе, під свої компанії, під мінливі обставини, а не прямолінійно слідувати методам і традиціям вчорашнього дня.

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

Чи стикалися ви з подібними ситуаціями? Чи доводилося вам адаптувати методологію під специфіку своєї компанії? Де та межа, коли подальше вдосконалення стає не доцільним?