«Диаграмма Исикавы примеры»: букет есть, заказ не готов
Диаграмма Исикавы: примеры причин задержки в цветочной мастерской. Показываю дерево гипотез, проверки и четыре мифа, из-за которых схема не помогает делу.
Ольга
Основатель малого бизнеса, партнёр
8 мин чтения
Букет стоит в холодильнике, покупатель ждёт у кассы, а заказ всё ещё нельзя выдать: потерялся текст открытки. Когда я искала «диаграмма исикавы примеры», хотелось получить схему, которая объяснит такие задержки. Ниже — дерево для цветочной мастерской и проверки к его ветвям. Они помогают разобрать процесс прежде, чем отправлять флориста на обучение скорости сборки.
У нас было восемь предзаказов на 18:00. Три не были готовы вовремя. Первый разговор закончился ожидаемо: «Вечером слишком много работы». Я почти записала решение — нужен ещё человек. Потом выяснилось, что один букет собрали заранее, а дополнительные 20 минут ушли на открытку и поиск нужного пакета.
Букет есть. Заказа пока нет.
Миф 1. «Диаграмма Исикавы примеры» — это список найденных причин
На листе я нарисовала стрелку вправо. На её конце написала «Заказы опаздывают», выше добавила «флорист медленно работает». Получилось аккуратно. Только на моей схеме стрелка была убедительнее основания под ней: время сборки я ещё не сравнила ни с чем.
ASQ описывает диаграмму Исикавы как способ распределить возможные причины проблемы по категориям. От появления на ветке догадка не становится установленной причиной. Это особенно легко забыть, когда схема уже красиво оформлена и её пора показать команде.
Сначала я переделала саму проблему. «Плохой сервис» слишком широко. «Опоздания» тоже: покупатель мог прийти позже, а заказ лежать готовым. Мы договорились разбирать конкретное событие — предзаказ на самовывоз не готов к согласованным 18:00.
Чтобы все считали одинаково, я записала границы:
готовность означает, что собраны букет, упаковка и заказанная открытка;
заказ отмечен готовым в сменном списке, его можно сразу найти и передать;
ожидание опаздывающего покупателя в эту проблему не входит;
переделка после новой просьбы клиента отмечается отдельно, а не смешивается с исходным заказом.
Это заняло больше места, чем первая стрелка. Зато стало понятно, о чём спорим. Если сборка закончена, а открытки нет, прибавлять скорость работы с цветами может быть бесполезно. Если весь заказ готов, но его не могут найти, проверять придётся передачу между сотрудниками.
С гипотезами я обращаюсь проще: ставлю рядом вопросительный знак. «Текст открытки поздно попадает к сборщику?» — рабочая версия. «Администратор опять всё потерял» — обвинение, которое мешает разбору. Мне нужно увидеть передачу текста, а не угадать характер человека.
Миф 2. Без шести ветвей 6M схема неправильная
У знакомого производственника я видела шесть крупных «костей». Хотелось повторить. Машины, материалы, методы, измерения, люди, среда — эти категории 6M помогают начать обсуждение. Но ASQ допускает переименование категорий ради ясности для тех, кто будет пользоваться схемой.
Я попробовала поместить открытку в «материалы». Бумага туда подходила, а текст из переписки — уже с трудом. Дальше пришлось бы объяснять сотрудникам мою классификацию. Работа мастерской от этого понятнее не становилась.
Поэтому я собрала четыре ветви вокруг пути заказа. Вот текстовый пример диаграммы: эффект стоит наверху, под ним категории и предполагаемые причины. При переносе на лист эффект окажется в правой «голове рыбы», категории станут большими наклонными ветвями, а версии под ними — маленькими.
```text
ЭФФЕКТ: предзаказ не готов к выдаче к 18:00
│
├─ Данные заказа
│ ├─ ? Текст открытки остался только в переписке
│ └─ ? Изменение состава не перенесли в сменный список
│
├─ Комплектация
│ ├─ ? Подходящий пакет ищут после сборки букета
│ └─ ? Открытку начинают подписывать перед самой выдачей
│
├─ Очередь сборки
│ ├─ ? Заказы идут по времени оплаты, а не выдачи
│ └─ ? Срочную покупку с витрины вставляют без пересмотра очереди
│
└─ Передача на выдачу
├─ ? Готовый заказ не отмечен в сменном списке
└─ ? Номер заказа не виден на упакованном букете
```
Это дерево можно использовать и как заготовку для Word: название проблемы, четыре категории, затем восемь отдельных подписей. Я бы сначала разместила текст, потом соединяла блоки. Если сразу рисовать декоративный скелет, длинную подпись про изменение состава придётся втискивать в оставшийся угол.
Названия ветвей не обязаны совпадать с должностями. Наоборот, «данные заказа» помогают обсуждать весь путь сведений, даже если сообщение сначала получил владелец, потом кассир, а собирает другой человек. Одна проблема может касаться нескольких этапов. Повтор допустим, если он показывает разные связи, а не размножает одну догадку.
LibraChat пригодится для сокращения подписей и поиска неясных формулировок в таком дереве. Достаточно текстового разговора. Если планируешь регулярно разбирать рабочие процессы, сопоставь свой объём задач с условиями доступа. Сам по себе выбор тарифа сведений о задержке не добавит.
Миф 3. Чем больше причин, тем лучше проведён разбор
Вторая версия моего листа разрослась. «Нагрузка», «много покупателей» и «вечерний поток» сначала стояли тремя отдельными пунктами. Я проверила формулировки: пока они описывали один и тот же фон. А вот где этот поток ломает очередь, из них не следовало.
Я стала задавать каждой подписи короткий вопрос: какое наблюдение поможет её проверить? Если ответа нет, ветку нужно уточнить. «Плохая организация» не подсказывает, куда смотреть. «Срочный заказ вставляют перед предзаказом, не проверив время выдачи» уже можно сопоставить с очередностью работы.
Гипотеза из дерева · Что посмотреть · Что ослабит эту версию
Текст открытки не дошёл до сборки — Когда текст согласован и когда появился в рабочем списке — Полный текст был доступен сборщику до начала работы
Нужный пакет ищут слишком поздно — Когда выбрана упаковка и сколько длится её поиск — Упаковка лежала рядом заранее, ожидания не было
Очередь не учитывает время выдачи — Порядок начала сборки и обещанное время каждого заказа — Приоритеты соблюдались, задержка возникла уже после сборки
Готовый заказ не отмечен — Время полной готовности и время отметки в списке — Отметка появилась сразу, заказ был виден кассиру
Одна строка не обязана объяснить все три задержки. У них могут оказаться разные причины. И совпадения недостаточно: если пакет искали именно вечером, это ещё не доказывает, что весь вечерний поток задержался из-за пакетов.
В версии про открытку я отдельно посмотрела бы последнюю согласованную редакцию. Допустим, покупатель прислал подпись утром, а за несколько минут до выдачи попросил заменить имя. В списке может лежать старый текст. Это другая цепочка событий, чем забытая с утра подпись. Для первой нужно проверить передачу изменений, для второй — первоначальное заполнение заказа. Одинаковая жалоба «нет открытки» не делает эти причины одинаковыми.
Начать можно с одной смены, чтобы понять, удаётся ли вообще собирать нужные отметки. Но я бы не объявляла найденный порядок универсальным после одного вечера. Следующий спокойный день даст полезное сравнение: возникают ли те же разрывы, когда очередь короче?
Я бы записывала одни и те же события и у вовремя подготовленных заказов. Иначе сравнивать не с чем. Если открытки поздно попадают в список и у своевременных, и у опоздавших заказов, версия требует уточнения. Возможно, важен ещё объём подписи или момент начала комплектации.
Перед чтением таких записей полезно посмотреть разбор работы с данными: нейросеть помогает обсуждать таблицу, но пропущенное время готовности не превращается в измерение. Я оставляю пустое поле пустым и выясняю, почему запись потерялась.
У ASQ после сбора идей следует анализ причин, которые стоит изучать дальше. Поэтому я не округляю число причин до красивого. Лучше четыре версии с понятными проверками, чем двадцать взаимозаменяемых слов.
Миф 4. На ветвях сразу нужно писать, что исправить
«Обучить флориста», «купить пакеты», «нанять администратора» — такую схему удобно обсуждать: все уже что-то предлагают. Но надпись «обучить флориста» звучит деятельно, а задержку ещё не объясняет. Я сама начала именно с такого решения, только про дополнительного сотрудника.
В методе 8D у ASQ проверка коренных причин отделена от выбора и проверки исправления. Мне здесь полезно само разделение. Для мастерской не требуется изображать полный производственный отчёт, чтобы перестать смешивать предположение с планом расходов.
Я бы действовала в таком порядке:
Выбрала одну версию: согласованный текст открытки не попадает в рабочий список.
Сопоставила переписку, список и время начала комплектации. Проверила также заказы без задержки.
Если связь подтверждается, определила место потери текста: при приёме или после изменения заказа.
Предложила меру под это место: например, переносить согласованную подпись до передачи заказа на сборку.
После изменения снова смотрела бы полноту списка и готовность заказов к обещанному времени.
Меру тоже придётся проверить. Обязательное поле может остаться пустым, а сотрудник — начать писать в нём «позже». Тогда красивая форма сохранилась, передача текста не наладилась. Ещё человек тоже не поможет, если оба ищут подпись в разных переписках.
Для проверки своих формулировок открой чат LibraChat и предложи ему такую задачу:
Разбираю задержку предзаказов цветочной мастерской: к 18:00 должны быть готовы букет, упаковка, открытка и отметка в сменном списке. Ниже моё дерево возможных причин. Найди слишком общие подписи и меры, ошибочно записанные как причины. К каждой выбранной гипотезе предложи наблюдение для проверки и наблюдение, которое её ослабит. Не называй гипотезы установленными причинами. Дерево: [вставь свои ветви].
А сегодня возьми только одну веточку. Кто и когда передаёт текст открытки? Запиши, где увидишь ответ. Если завтра придётся искать его в работе мастерской, а не в красоте схемы, диаграмма уже задаёт полезный вопрос.
