Діаграма Ісікави (Fishbone): як знайти корінну причину проблеми

Діаграма Ісікави (Fishbone diagram) – це інструмент структурованого пошуку причин проблеми, який групує можливі причини за категоріями навколо чітко сформульованого наслідку, візуально нагадуючи риб’ячий скелет. Її мета – не просто зібрати список здогадок, а систематично розкласти всі можливі напрямки, звідки могла з’явитися проблема, перш ніж переходити до перевірки, яка з причин справжня.

Метод розробив японський інженер і професор Токійського університету Каору Ісікава у 1960-х роках у рамках руху гуртків якості (quality circles), який тоді активно впроваджувався на японських підприємствах, зокрема на металургійному заводі Kawasaki Steel Works. Ісікава шукав спосіб, який дозволив би робочим командам – а не лише інженерам – структуровано аналізувати причини дефектів, не покладаючись на інтуїцію окремої людини.

Офіційна назва методу – діаграма причин і наслідків (cause-and-effect diagram): наслідок (проблема) вказується один раз, а причини групуються навколо нього за категоріями. Назва «Fishbone» (риб’ячий скелет) – неформальна, але саме вона прижилась у щоденному вжитку, бо графічно діаграма справді нагадує кістяк риби: горизонтальна лінія – «хребет», що веде до «голови» (формулювання проблеми), а діагональні лінії, що відходять від хребта, – «кістки» з категоріями причин.

Ісікава також відомий тим, що систематизував сім базових інструментів контролю якості, до яких, крім його власної діаграми, входить і діаграма Парето – обидва інструменти в японській практиці управління якістю традиційно застосовують у парі.

З чого складається діаграма: анатомія риб’ячого скелета

Структура діаграми чітко фіксована й складається з трьох елементів:

• Голова – рамка справа, у якій записаний сам наслідок: конкретна, вимірювана проблема («зросла кількість повторних звернень клієнтів», а не розмите «погана якість сервісу»).
• Хребет – горизонтальна лінія, що веде від лівого краю аркуша до голови.
• Кістки – діагональні лінії, що відходять від хребта; кожна відповідає окремій категорії причин, а дрібніші «кісточки», що відгалужуються від кожної категорії, – конкретним причинам усередині неї.

Для виробничих проблем класично використовують шість категорій, відомих як 6M:

1. Man (люди) – кваліфікація, втома, недотримання інструкцій.
2. Machine (обладнання) – несправність, знос, неправильне налаштування.
3. Method (метод) – сама процедура роботи, її послідовність чи логіка.
4. Material (матеріали) – якість сировини чи комплектуючих.
5. Measurement (вимірювання) – похибки контролю, неточні прилади.
6. Mother Nature / Environment (середовище) – температура, вологість, освітлення, зовнішні умови.

Для сервісних і невиробничих задач категорії адаптують: замість Machine і Material часто використовують Policies (політики), Procedures (процедури), People (люди) і Place (місце) – так звані 4P. Головне правило вибору категорій не в тому, щоб точно скопіювати чиюсь готову модель, а в тому, щоб категорії дійсно відповідали природі процесу, який аналізується.

Розглянемо алгоритм на прикладі команди виробництва, яка зафіксувала зростання браку на одній з ліній.

Крок 1. Чітко сформулюйте наслідок у “голові”. Не «якість погіршилась», а «частка бракованих деталей на лінії №2 зросла з 2% до 7% за останній місяць». Чим конкретніша й вимірюваніша проблема, тим точніше команда зможе шукати причини – розмите формулювання одразу зробить весь подальший аналіз малокорисним.

Крок 2. Оберіть категорії причин. Для виробничої лінії команда бере класичні 6M і малює шість гілок від хребта.

Крок 3. Проведіть мозковий штурм по кожній гілці окремо. Команда послідовно проходить кожну категорію й фіксує всі можливі причини, не оцінюючи одразу їхню ймовірність – на цьому етапі мета зібрати якомога ширший список, а не одразу звузити його. У прикладі з лінією №2 результат може виглядати так: у гілці Machine – «не проведено плановий сервіс верстата»; у гілці Material – «новий постачальник комплектуючих з іншого місяця»; у гілці Man – «на лінію нещодавно вийшли два нових оператори»; у гілці Method – «інструкція з налаштування верстата не оновлювалась два роки».

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

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

Як знайти справжню кореневу причину

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

Як звузити список гіпотез до реальної причини:

1. Пріоритизуйте гілки за ймовірним внеском, а не за суб’єктивним відчуттям. Якщо є дані (частота, вартість, кількість інцидентів по кожній причині), варто побудувати на їх основі діаграму Парето – вона покаже, яка з категорій причин, ймовірно, відповідає за основну частку проблеми, і саме з неї варто починати перевірку.
2. Перевіряйте гіпотези даними, а не голосуванням команди. Якщо гіпотеза – «новий постачальник комплектуючих», перевірте статистику браку окремо для деталей від нового і старого постачальника за той самий період. Гіпотеза, яка не підтверджується даними, відкидається, навіть якщо вона здавалась найбільш очевидною під час мозкового штурму.
3. Заглиблюйтесь у підтверджену причину методом 5 чому. Коли конкретна гілка чи причина підтверджена даними, її варто розкрити далі: чому не проведено плановий сервіс верстата → чому графік сервісу не був дотриманий → чому відповідальний за графік не отримав нагадування → і так далі, поки не дійдете до причини, яку компанія реально може усунути системно, а не лише прибрати симптом.

Саме поєднання цих трьох кроків – а не сама діаграма – і виводить команду від списку здогадок до справжньої кореневої причини.

Розмите формулювання проблеми в “голові”. Якщо наслідок сформульований абстрактно («погана якість»), уся діаграма вийде такою самою абстрактною, і команда згенерує загальні, малокорисні причини.

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

Оголошення першої причини кореневою без перевірки. Це саме той крок, який пропускають найчастіше – команда будує діаграму, вибирає найбільш «резонансну» на слух причину і одразу переходить до дій, минаючи перевірку даними.

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

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

Діаграму Ісікави застосовують не лише у виробництві – вона однаково працює для аналізу причин у сервісі, ІТ-інцидентах, управлінні проєктами чи навіть у розборі організаційних проблем команди. Метод найчастіше використовують у зв’язці з двома іншими інструментами: діаграмою Парето – щоб визначити, яку категорію причин перевіряти першою, і методом 5 чому – щоб заглибитись у підтверджену причину до її справжнього кореня. Разом ці три інструменти складають один з найпоширеніших робочих циклів аналізу проблем у практиці управління якістю.

Діаграма Ісікави, разом із принципом Парето та методом 5 чому, – базовий набір інструментів аналізу причин, який системно розбирають на курсі Школа управління якістю.