“Определите свои классы обслуживания с помощью Триаж Таблиц» Podcast «Kanban talks» Эпизод № 7.

Эфир/cтатья Дианы Деряжной, маркетинг менеджера компании Mauvisoft. Mauvisoft является частью группы компаний Mauvius Group, куда входит также David J Anderson School of Management.

  1. Что такое приоритеты и что приоритет значит для наших клиентов\заказчиков ?

Действительно, давайте задумаемся, какое значение несёт в себе слово «приоритет». Что мы под ним подразумеваем? Обычно, это просто выражение отношения говорящего к той или иной задаче. Оно не подразумевает никакого действия. Если кто-то говорит, что это приоритет, понимают ли сразу остальные что они должны с этим делать, какие дальнейшие шаги нужно выполнять? И как относиться к этой задаче по отношению к остальным? Мы говорим «это наш приоритет» и в оригинале значения слово подразумевает, что приоритет только один. Но разве в наших задачах обычно только один приоритет?

 «Приоритет» — это то, как мы относимся к запросу и что мы с ним делаем. Еще 10 лет назад Дэвид Андерсон призывал Канбан сообщество убрать слово «приоритет» и «приоритизация» из своего лексикона, так как с Канбан они теряют смысл. Статью об этом мы, кстати, перепечатали у нас в блоге на Mauvisoft. На англ. Она называется «Banish “Priority” and “Prioritization”

 «https://mauvisoft.com/2020/12/07/banish-priority-and-prioritization/». Впервые эта статья была опубликована в марте 2011 и по сегодняшний день является актуальной. Это один из материалов книги «Lessons in Agile Management», которую ребята из русского Канбан сообщества планируют скоро переводить на русский.

В этой статье Дэвид говорит о том, что слово «приоритет» на самом деле артефакт, который маскирует реальную информацию о рисках. Такую, как стоимость задержки, возможный ущерб и так далее. 

В работе над визуализацией Kanban системы наша цель – найти способы сбора и отображения реальной информации о рисках, с которыми работает бизнес. И классы обслуживания отлично справляются с этой задачей. Но только в том случае, если правильно и очень четко сформулированы правила, которые отображают, что означает принадлежность задачи, т.е. рабочего элемента к тому или иному классу обслуживания, и как элемент этого класса должен обрабатываться, как мы относимся к этому элементу по отношению к другим.

Тогда «приоритет» становится чем-то, что может быть определено динамически при принятии решения о вытягивании. А само слово «приоритет» можно заменить на «определение последовательности», «планирование» или «отбор». И тем не менее, слово «приоритизация» очень сильно укоренилось в обиходе, поэтому мы, с нашей стороны, не настолько строги к использованию этого слова, если речь идет о материалах для широкой аудитории или базового начального Канбан — уровня. В таких случаях мы можем его использовать, чтобы объяснить студенту, ученику, о чем речь простым, понятным ему языком.

  1. Что такое Триаж?

Триаж — это широко распространенная методика в отделениях скорой помощи в больницах по всему миру.

Когда новый пациент поступает в больницу, дежурная медсестра сразу же оценивает, нужно ли его осмотреть сейчас или можно подождать, и если можно, то сколько и какая подготовка потребуется, чтобы его принять.

Понятие «триаж» пришло к нам из 1850-1860-х годов. В Крымской войне, которая велась в эти годы, параллельно с Гражданской войной в США, впервые в военных действиях начали использовать нарезные винтовки. Их разрушительное действие было намного существеннее их предшественников – однозарядных мушкетов. И как результат – на поле боя резко возросла смертность и количество раненых: полевые госпитали были перегружены, не хватало ни врачей, ни помещений для всех раненых.

Врачам нужно было каким-то образом быстро оценить, кому они могут помочь и как срочно, а кому уже нет. Разработанная методика заключалась в разделении раненых на три категории:

  • срочно – если мы окажем помощь этому солдату прямо сейчас, то сможем спасти ему жизнь;
  • позже – этот солдат нуждается в помощи тут, в полевом госпитале, но не умрет в ближайшие несколько минут;
  • не будем помогать ему вовсе – с двумя подкатегориями: этот солдат умрет независимо от того, поможем мы ему или нет, и ранения этого солдата достаточно легкие, поэтому он может быть отправлен в госпиталь за линией фронта вдали от поля боя, где ему окажут помощь местные медики.

Поэтому планирование, определение последовательности задач или, простыми словами, как мы упоминали раньше «приоритизация» — это и есть триаж.

Принятие решения о начале работы над одним запросом, но не над другими — это и есть триаж. Система, которая имеет ограничение работы в процессе, нуждается в триажировании. Триажирование — это отбор того, что начать сейчас, что отложить на потом, а что и вовсе отбросить.

  1. Как запросы от заказчиков обрабатываются?

Мы используем триажирование, чтобы определить класс обслуживания рабочего элемента, когда он попадает в систему. Дэвид Андерсон выделяет 4 типа классов обслуживания:

  • Ускоренный – это срочные задачи с мгновенной стоимостью задержки. Обычно, такие задачи делают в первую очередь, откладывая все остальные, их пропускают вперед, как скорую на автостраде. Как правило, ускоренные задачи идут как +1 к количеству задач, определенному, как лимит работы в процессе. 
  • Фиксированная дата – обычно это задачи с фиксированным дедлайном. При классе обслуживания «фиксированная дата» мы понимаем, что стоимость задержки резко возрастает после дедлайна.
  • Стандартный — это наши стандартные задачи без зафиксированного дедлайна, при которых стоимость задержки будет повышаться плавно, приближаясь к дедлайну.
  • Нематериальный – это самый хитрый класс обслуживания. Эти задачи не срочные и не обязательные (в данный момент). Их выполнение не влияет на текущий рабочий процесс, поэтому стоимость их задержки незначительна и не будет заметна какое-то время, возможно, очень долго, но если вырастет, то возрастёт резко и будет очень существенна.

Чтобы детальнее объяснить, какого типа задачи могут иметь класс обслуживания «нематериальный», приведу пример. К примеру, наша компания для работы использует какой-то определенный софтвер или какую-то программу, которая в какой-то момент начала требовать ее обновить. Эта задача не срочная, ее можно сделать в любой момент. Ее выполнение никак не повлияет на наш текущий рабочий процесс или результат. Теперь представим, что по каким-то причинам мы достаточно долго откладывали эту задачу. Возможно, потому что, чтобы обновить эту программу нам нужно было приостановить рабочий процесс на какое-то время, или каким-то образом это было для нас сложно и не до того, так как было много работы и были более срочные задачи. В общем, мы это откладывали и не делали. Пока в один прекрасный день мы столкнулись с тем, что все перестало работать, потому что устаревший софтвер нашей программы больше не совместим с другими программами, которые мы используем. В этот момент эта задача нас как раз и ужалила в самое уязвимое место – стоимость задержки этой задачи ракетой взлетела вверх, так как весь рабочий процесс остановлен, ничего не может работать, компания не зарабатывает деньги, пока эта задача не будет выполнена в срочном порядке. Ей сразу же присваивается класс обслуживания «ускоренный» и она пулей полетела по нашей Канбан доске, как +1 ко всем ограничениям работы в процессе. Стоимость задержки этой «нематериальной» задачи мы сможем оценить по потерям, которые понесет компания из-за простоя, потому что эта задача не была выполнена ранее.

Таким образом, с помощью классов обслуживания мы видим, что с помощью классов обслуживания мы можем сразу наглядно видеть и легко классифицировать рабочие элементы по их важности и срочности. Для каждого класса обслуживания должны быть разработаны четкие правила, план действий, как задачу такого класса нужно обрабатывать в системе. Так, мы видим класс обслуживания этой задачи и сразу понимаем, что с ним делать. Необходимость иметь кого-то, кто должен определять, что это приоритет, а это нет – просто исчезает. Вместо этого мы просто планируем или определяем последовательность при вытягивании.

  1. Можем ли мы использовать Триажирование, когда запрос перешел через точку принятия обязательств?

Если состояние пациента ухудшилось, то мы, конечно же, можем и даже должны пересмотреть его класс обслуживания в процессе, не дать же ему умереть. Но вообще да, после коммитмент поинта ставки считай уже сделаны, ставок больше нет.

  1. Что такое стоимость задержки поставки (delivery dalay cost)?

Стоимость задержки — задержка означает, что мы получаем меньшую ценность, выгоду, заработок от возможности. Стоимость задержки призвана приблизительно оценить размер потерь, связанных с задержкой. Стоимость задержки можно смоделировать в виде кривой, нарастающей с течением времени. Если форма кривой резко и быстро возрастает в краткие сроки, значит, риск задержки значителен.

Давайте рассмотрим это на примере. Скажем, мы планируем маркетинговую рекламную кампанию для продвижения отеля на Пасхальные праздники. Мы хотим продать как можно больше гостиничных номеров на эти праздничные дни, допустим всего у нас их тысяча.

Мы хотим запустить кампанию в начале января. Жизненный цикл нашей рекламной кампании будет 90 дней, большая часть продаж — во второй части периода (это функция обратной загрузки, на англ. back-loaded). Математически пик продаж будет составлять 58 номеров в день. Если кампания будет проведена вовремя, начиная с января, — мы рассчитываем продать всю 1000 гостиничных номеров.

Теперь давайте представим, что произойдет, если случится задержка? Допустим, что-то пошло не так и наша маркетинговая кампания не была готова вовремя, мы запустили ее позже и, как следствие, продали меньше номеров, чем ожидали. Разница между тем, что мы ожидали продать, и тем, что мы продали по факту — и есть стоимость задержки. Из-за задержки мы потеряли возможность. Когда мы говорим о стоимости задержки, идея заключается в том, чтобы понимать: по мере того, как увеличивается задержка — сколько мы теряем как следствие? Другими словами, во сколько нам обходится эта задержка?

Стоимость задержки тоже не цифра, а кривая. Для того, чтобы лучше понять этот пример давайте представим, что наша функция имеет предварительную загрузку вместо обратной. Допустим, по каким-то причинам в связи со спецификой нашего бизнеса, мы продаем больше номеров на первых сроках жизненного цикла нашей рекламной кампании. Таким образом, давайте мысленно перевернем нашу функцию из функции обратной загрузки в функцию предварительной загрузки. Теперь, к примеру, мы увеличиваем задержку на 20%, в 100-дневном жизненном цикле это будет на 20 дней каждый раз. Итак, мы как бы убираем кусочки нашей кривой, начиная спереди, с ее наиболее высокой части, с января, при этом с каждым шагом в 20 дней наша кривая в целом становится меньше и ниже. Итак, первые 20 дней задержки с учетом нашей кривой теперь с передней загрузкой, стоят нам 400 номеров, которые мы не продали, следующие 20 дней задержки меньше — только 250, но вместе, 40 дней задержки обойдутся нам в 650 номеров, и так далее до 1 тыс. 

  1. Есть такие понятия как толстый и тонкий хвост. Что это значит, и какое распределение лучше для нашей Канбан системы?

Да, есть и такое 😊 В данном случае речь идет о функции распределения времени выполнения. Время выполнения — это сколько времени потребуется для выполнения задачи. А точнее, это период между моментом, когда мы взяли на себя обязательство сделать что-то, т.е. когда наш тикет пересек точку взятия обязательств, и до того момента, когда работа считается выполненной, т.е. тикет попал в колонку «выполнено» на данной Канбан доске.

Для начала давайте осознаем один важный момент — время выполнения, а точнее распределение вероятности времени выполнения — это не число, это кривая!   Английском распределение вероятности времени выполнения – это lead time probability distribution. Мы всегда используем простую мантру «проблема всегда в хвосте».

Давай детальнее разберемся, что такое толстый и тонкий хвост, как это увидеть и что с этим делать.

Давайте представим себе график распределения времени производства, который мы создали, собирая данные из нашей Канбан системы. Кто не зает, как это делать, опять же, на сайте mauvisoft.com в блоге, есть полезная статья о том, как это делать – Как читать функцию распределения времени производства (добавить ссылкой в заголовок: https://mauvisoft.com/2020/10/08/how-to-read-lead-time-distribution/

Так вот, ось x – это время выполнения, ось y – это количество выполненных рабочих элементов. К примеру, вы анализируете данные за 3 месяца работы. Вы знаете, что минимальное время выполнения в вашей канбан системе составляет 1 день. Через 3 месяца у вас есть 53 выполненных рабочих элемента с 1-дневным временем выполнения и 32 элемента с 2-х дневным и так далее. Это означает, что ваша первая точка данных на графике будет 1 на оси x, и 53 на оси у, затем 2 на оси х и 32 на оси у, и так далее вырисовывается кривая, которая стремится вправо в зависимости от времени выполнения готовых рабочих элементов.

Представим себе, что в этом примере есть рабочие элементы, чей срок выполнения доходит до 77 дней. Таким образом наша кривая имеет длинный толстый хвост, который тянется долго вправо от срока выполнения в один день и аж до 77. Мы используем в наших материалах реальный пример реальной компании с этими данными. Для нас это наглядный пример распределения времени выполнения с толстым хвостом. Проанализировав его, мы видим, что в этой компании в лучшем случае рабочий элемент может быть выполнен сегодня, в худшем — через 77 дней. 50% всех рабочих элементов выполняются за 6 дней или меньше. Но если вам не повезло, и вы попали во вторые 50%, то выполнение вашего элемента может занять от 7 до 77 дней. При такой кривой слишком большая вариативность, поэтому очень сложно что-либо планировать.

Теперь давайте разберемся что же такое тонкий хвост. При тонком хвосте у нас нет такой большой вариативности. В нашем примере, который мы часто используем на классах, это пример крупной хардвер компании из Китая, среднее время выполнения- около 10 или 11 дней. Кривая не уходит так далеко вправо, а скорее постепенно сходит на нет. Это хорошо управляемая работа с совсем небольшой вариативностью. С таким распределением времени производства мы понимаем, что это надежный предсказуемый процесс, в которым мы можем что-то прогнозировать. 

  1. При каком распределении у нас больше риски?

Конечно же, при толстом хвосте. Возвращаясь к нашему примеру выше, допустим вы заказали диван. В 50% случаев вам доставят его в течение 6 дней или меньше, что просто прекрасно. Но если вам не повезло попасть в другие 50%, вам привезут ваш диван через 77 дней, т.е. через 2 с половиной месяца. Чем это грозит для такого бизнеса? Конечно же, отменой заказов и потерей продаж. Какова будет работа менеджера по продажам этой компании? Может ли он что-то обещать своим клиентам или как-то прогнозировать? «Дорогой клиент, в 50% случаев ваш диван приедет к вам вовремя, но если нет, вам возможно придется ждать 2,5 месяца, чтобы получить его». Купит ли клиент этот диван, после такой откровенности? Особенно, если у этого клиента есть какие-то ограничения по времени. К примеру, Новогодние праздники, где он планировал сидеть на этом диване со своими друзьями и пить шампанское. Думаю, что скорее он найдет другого поставщика, который сможет чётко определить и гарантировать их время выполнения. Того, чья функция распределения времени производства имеет тонкий хвост, где заказ будет выполнен в среднем через 10 или 11 дней.

Поэтому, в Канбане мы всегда говорим, что очень важно работать над тем, чтобы сократить вот этот хвост функции времени производства, чтобы добиться функции с тонким хвостом, при которой можно спокойно работать и что-то прогнозировать.

  1. Как по шагам использовать Триаж таблицы?

Конечно, на этот вопрос гораздо проще было бы ответить имея визуальное сопровождение, но я обязательно поделюсь ссылками на всю упомянутую информацию с Лешей, чтобы он смог опубликовать их в сопутствующих материалах.

Итак, Триаж Таблицы. Это таблица, которая помогает определить класс обслуживания рабочего элемента, опираясь на стоимость задержки. Эта таблица – это результат 10 лет работы, исследований и расчётов Дэвида и его партнёров и коллег. Таблицы можно использовать в виде Постера, который можно бесплатно скачать с наших сайтов, к примеру, он есть у нас на mauvisoft.com. Или через приложение, но об этом, опять же, чуть позже. Начнем с постера.

История создания этого постера такова,, что ранее Дэвид и его команда, разработали формулы, по которым можно вычислить принадлежность рабочего элемента к тому или иному классу обслуживания. Но эти формулы были достаточно сложными и в них было нелегко разобраться неподготовленному человеку без определенного математического образования. Т.е. они не были пригодны для широкого применения в нормальных рабочих условиях. В один прекрасный день Драгош Димитриу (Dragos Dumitriu) сказал Дэвиду «а почему бы не разработать что-то, что было бы похоже на таблицы для дайверов». Кто не знает, декомпрессионные таблицы для дайверов — это такие таблицы, по которым ты можешь легко высчитать, в зависимости от того сколько ты пробыл под водой и на какой глубине, когда ты можешь спускаться под воду в следующий раз или, к примеру, летать на самолёте, чтобы не навредить своему здоровью перегрузками. Эти таблицы построены на основе математических и теоретических моделей. Благодаря декомпрессионным таблицам дайверы могут самостоятельно рассчитывать график погружений, гарантирующий безопасность дайвинга.

С тех пор Дэвидом и его командой была проведена колоссальная работа, выведены и рассчитаны наиболее популярные в современном бизнесе паттерны работы, которые позволяют без особой математической подготовки с легкостью определить точный класс обслуживания для задачи, с учетом ее возможной стоимости задержки.

Итак, чтобы воспользоваться таблицами, вам нужно знать несколько незамысловатых вещей о вашем рабочем процессе: 1) ваше время выполнения, 2) жизненный цикл рабочего элемента, 3) когда вы планируете вашу поставку, 3) какие ожидания ваших клиентов в контексте их толерантности к возможной задержке, 4) какая ваша функция распределения времени производства, о которой мы говорили ранее – имеет она тонкий или толстый хвост. Тут, конечно, есть один трюк – если вы не знаете, или у вас нет достаточно данных, предположите худшее, рассчитывайте все с учетом функции с толстым хвостом. Далее, когда вы сможете убедиться, что у вашего процесса все-таки тонкий хвост, вы сможете считать ваши результаты по части таблицы для тонкого хвоста.

Итак, поехали. Если таблица у вас перед глазами, вы можете следовать за мной. В правом верхнем углу вы увидите пошаговые инструкции. Следуйте им, иначе у вас может получиться что-то не то или вы быстро запутаетесь.

Шаг 1 – Определите жизненный цикл получения ценности. Тут представлено 11 разработанных наиболее распространенных функций жизненных циклов получения ценности. Все, что вам нужно сделать – это определить, какой из примеров наиболее соответствует вашей рабочей возможности, для которой вы хотите рассчитать класс обслуживания. Давайте, опять же, рассматривать все на примерах.

Допустим, вы хотите создать собственную развивающую детскую социальную игру, рассчитанную на родителей с детьми в возрасте 2–4  лет.

  • Вы предполагаете, что жизненный цикл игры составит 5 лет.
  • На создание и запуск может уйти от 9 месяцев до 1 года.
  • Вы хотите запустить продукт в ноябре 2022 года к сезону праздничных покупок.
  • Сроки выполнения заказа зависят от внешних факторов, но жестких сроков нет.
  • Ваша игра – это уникальный новый продукт, ноу-хау, которого еще нет на рынке. Но он не защищен патентом или зарегистрированным дизайном. Следовательно, вы ожидаете, что конкуренты скопируют вас через 1-2 жизненных цикла.
  • Предположим, что вы готовы начать сегодня, и планируете запуск на 1 ноября 2022 года.

Итак, давайте посмотрим, какие жизненные циклы предлагает нам наша таблица:

  1. Первая функция – это РАЗОВАЯ ВОЗМОЖНОСТЬ С ИСТЕЧЕНИЕМ СРОКА. Это означает, что возможность только одна, ею можно воспользоваться и заработать, или пропустить ее. Например, ваш клиент обращается к вам в конце года и говорит, что у него есть некий остаток бюджета, который он может потратить на дополнительный проект до начала нового финансового года. Вы можете воспользоваться возможностью и получить дополнительный заработок, или же отказаться и упустить возможность.
  2. ПРИБЫЛЬ НА ОЧЕНЬ РАННИХ СРОКАХ – означает, что 80% прибыли будет получено в первые 20% жизненного цикла. Например, производитель лыж выпускает новую модель каждый год в ноябре, и большая часть лыж продается в первые 3 месяца при жизненном цикле продукта сроком в 1 год.
  3. ПРИБЫЛЬ НА РАННИХ СРОКАХ- 80% прибыли будет получена в первые 50% жизненного цикла. Примером будет производитель велосипедов, который выпускает новую модель каждый год в ноябре-декабре, но большинство продаж происходит в начале сезона, весной, то есть в середине жизненного цикла, и снижается к концу лета.
  4. КОЛОКОЛООБРАЗНАЯ КРИВАЯ, ПРЕИМУЩЕСТВО ПЕРВОГО — существует сетевой эффект на рынке, который дает преимущество, тому, кто запускает функционал или продукт первым, но последующие игроки рынка этого преимущества не получают. Такой эффект в первую очередь ассоциируется с технологическими платформами такими, как операционные системы, стандарты мобильной телефонии, средства обмена сообщениями и коммуникации, социальные сети. Например, кто-то из них выпустит первым на рынок что-то такое, что остальные не смогут повторить.
  5. КОЛОКОЛООБРАЗНАЯ КРИВАЯ, БЕЗ ПРЕИМУЩЕСТВА ПЕРВОГО — Колоколообразная кривая без преимущества у первого, кто реализовал функционал или продукт. Все участники рынка могут догнать и даже обогнать первого. Первый производитель автомобилей, который представил светодиодные фары на рынке, имел преимущество. Потребовался один год, чтобы его догнал другой производитель, который предложил такую же технологию. Затем потребовалось несколько лет, чтобы другие игроки рынка смогли догнать их. Тем не менее, первый игрок не заблокировал рынок, его нововведение не остановило продажи конкурентов.
  6. ПРИБЫЛЬ НА ПОЗДНИХ СРОКАХ — 80 процентов выгоды реализуется в последние 50 процентов жизненного цикла. Это наш случай из предыдущего пасхального примера. Наша пасхальная маркетинговая кампания отеля начинается после Нового года (жизненный цикл 90–100 дней). При этом большинство бронирований осуществляется во второй половине жизненного цикла.
  7. ПРИБЫЛЬ НА ОЧЕНЬ ПОЗДНИХ СРОКАХ — 80 процентов выгоды реализуется в последние 20 процентов жизненного цикла. Организатор конференции предлагает мероприятие в местном регионе или мегаполисе, ориентированное на участников из этого географического региона. Если не существует ощутимого дефицита билетов, посетители ждут до последних 20 процентов жизненного цикла, прежде чем купить билет.
  8. ФИКСИРОВАННАЯ СТАВКА — Функция постоянной ставки отображает те случаи, когда ввиду выполнения того или иного рабочего элемента можно сэкономить на последующих расходах. Например, при внедрении того или иного продукта или услуги происходит экономия – возможно сокращается необходимость вовлечения работников, например, автоматизация каких-то процессов. Следовательно, если бы у нас была эта функция сегодня, мы получили бы экономию завтра, а сумма экономии является фиксированной и постоянной.
  9. КОЛОКОЛООБРАЗНАЯ ПРОДЛЕННАЯ КРИВАЯ, УГАСАЮЩИЙ ЖИЗНЕННЫЙ ЦИКЛ И ЛОЯЛЬНОСТЬ — моделирует длительный, но сокращающийся жизненный цикл, вместе с угасающей лояльностью. Это ситуации, когда задержка в выпуске продукта, функции или услуг после желаемой даты имеет незначительное влияние из-за лояльности клиентов, технологической монополии, монополии предложения или ограниченного выбора на рынке. Однако длительные задержки приводят к тому, что период жизненного цикла сокращается, а лояльность снижается. Лояльные клиенты будут ждать, пока их любимый бренд (например, мобильные телефоны, ноутбуки, планшеты), не выпустит продукт с новейшей технологией (например, процессор, наборы видеочипов, камеры и т.д.). Но задержка снижает, как лояльность, так и жизненный цикл продукта, поскольку устаревшие технологии будут заменены сами по себе в их собственном независимом жизненном цикле.
  10. КОЛОКОЛООБРАЗНАЯ КРИВАЯ, ПРОДЛЕННЫЙ ЖИЗНЕННЫЙ ЦИКЛ, угасающая лояльность. Это моделирует длительный жизненный цикл, с ослаблением лояльности с течением времени. Это ситуации, когда задержка в выпуске продукта, функции или услуги после желаемой даты имеет незначительное влияние из-за лояльности, технологической блокировки, монополии на предложение или ограниченного выбора на рынке. Microsoft Windows и Apple iPhone/iOS — это оба примера, но более точный пример — следующий альбом популярной рок-группы, такой как Depeche Mode или Coldplay. Depeche Mode выпускает альбомы с периодичностью в четыре года, но, если бы произошла задержка, преданные поклонники фанаты будут ждать и все равно купят альбом. Однако, более длительные задержки в итоге приводят к тому, что лояльность падает.
  11. СПАД В ПОСЛЕДНЮЮ МИНУТУ — Немедленная выгода независимо от задержки, однако, длительная задержка и объявление в последнюю минуту приводит к быстрому сокращению выгоды. Это моделирует такой бизнес, как продвижение концерта популярного исполнителя. Представим, что речь идет о Бейонсе. Если объявят, что Бейонсе будет выступать в вашем городе, когда билеты поступят в продажу, весь стадион будет распродан в течение несколько часов. Если мы задержимся на неделю или месяц, билеты все равно будут распроданы. Продажи в любом случае будут мгновенными, несмотря на задержку, если только мы не будем ждать до последней минуты, не объявляя о событии.

Вернемся к нашему примеру с развивающей игрой для детей и родителей –очевидно, нам подходит КОЛОКОЛООБРАЗНАЯ КРИВАЯ, БЕЗ ПРЕИМУЩЕСТВА ПЕРВОГО, так как мы знаем, что с нашим нововведением у нас будет преимущество на рынке, но другие игроки рынка смогут скопировать его в будущем.

Шаг 2 – Определите ваш тип таксономии коэффициентов времени жизни. Звучит страшно, но тут нет ничего сложного. Грубо говоря, нужно определить, к какому из указанных примеров соотношения времени производства и жизненного цикла, относится ваша задача.

В нашем случае это 1 к 5, так как создавать игру мы планируем максимум 1 год, а продавать – 5 лет.

Зная эти два элемента нашей задачи, мы можем вычислить класс обслуживания по определению. КОЛОКОЛООБРАЗНАЯ КРИВАЯ, БЕЗ ПРЕИМУЩЕСТВА ПЕРВОГО и соотношение времени производства и жизненного цикла 1:5 дает нам класс обслуживания стандартный. Но в данном случае, мы пока не учитывали ни наши сроки, ни насколько толерантен наш клиент к задержкам. Давайте посмотрим, как изменится наш результат, когда мы учтём также эти факторы.

Итак, шаг 5 – Диапазоны дат начала.  Сегодня у нас 16 сентября, поставку мы планировали на 1 ноября 2022 года, при этом наше время выполнения, как мы сказали, от 9 месяцев до 1 года, возьмем максимум – 1 год. Таким образом, до желаемой даты поставки еще 1 год и полтора месяца, т.е. больше 100% необходимого нам времени производства. Согласно нашей таблицы этот временной диапазон называется «рано». Рано, это если сейчас мы находимся во временном промежутке в два раза больше, чем наше временя производство и до 100% нашего времени производства. Со 100% времени производства и до 85% времени производства мы будем находится на этапе «нормально» согласно таблице. Для нашего примера 100% нашего времени производства начнётся 1 ноября.

Шаг 6 – то, о чем мы говорили ранее. Какой хвост у вашей функции времени производства? Если он толстый – используйте таблицу справа, если тонкий – слева.

Мы сказали, что в примере у нас толстый хвост – нам направо.

Шаг 7 – выберите дату начала, которую вы только что определили в п.5 и ожидания вашего клиента. Предлагаемые опции: ASAP – то есть, как можно раньше, согласно ожиданий или договоренностей с клиентом, дедлайн, нулевая терпимость к задержкам, или не важно, то есть клиенту все равно, когда будет поставка.

В нашем случае мы на этапе рано и у нас нет дедлайна – это дает нам результат по таблице, что предыдущий полученный результат мы можем не менять, наш класс обслуживания сейчас «стандартный».

А теперь давайте представим, что у нас есть дедлайн. К примеру, мы хотим запустить нашу игру на каком-то мероприятии, которое будет проходить 1 ноября. Мы двигаемся вправо, выбираем «рано», «дедлайн» и видим, что таблица меняет наш результат на «фиксированную дату». А значит, мы должны относиться к этому запросу, понимая, что стоимость задержки вырастет в разы после дедлайна, то есть в нашем случае, мы продадим меньше игр, если запустимся позже.

Но что, если мы давно работаем с такими вещами, мы хорошо знаем нашу канбан — систему и уверены, что у нашей функции времени производства тонкий хвост? Давайте теперь посмотрим на левую часть таблицы.

«Рано» и «дедлайн» — таблица советует нам спуститься на 1 ячейку вниз от нашего первого результата, мы делаем это и видим, что наш класс обслуживания изменился, теперь он «нематериальный».

Что это значит для нас? Если мы можем положиться на наш процесс производства, мы уверены. Что у нас на пути не будет сюрпризов, мы хорошо поработали над нашим толстым хвостом и теперь наша функция распределения времени производства имеет тонкий хвост, мы можем спокойнее планировать нашу работу.

Многие наши ученики сказали нам, что с тех пор, как они познакомились с триаж таблицами, они обнаружили, что не все те задачи, которые, как нам на первый взгляд и наугад, кажутся с «фиксированной датой», на самом деле могут обрабатываться, как стандартные, если мы просчитываем класс обслуживания с таблицей и планируем начать вовремя. Это дает возможность работать спокойнее, легко планировать и избегать лишнего стресса, что, как мы знаем, положительно влияет на наше нормальное эмоциональное состояние и здоровье 😊

Для тех, кто ищет еще более легкие решения, чтобы не пользоваться постером, который может и не быть всегда под рукой, да и в целом вообще ничего не считать, мы разработали мобильное приложение – Menta Triage Decision Support. https://mauvisoft.com/menta-triage-ds-application/ Оно бесплатное, его можно скачать в любом апсторе. Оно работает по принципу калькулятора – ты просто выбрал нужные тебе значения – и приложение само тебе все посчитало. В нем можно сохранить данные о времени производства нескольких канбан — досок и потом выбирать нужную и считать класс обслуживания для каждой конкретной задачи, для каждой конкретной доски. Более того, мы внедрили туда мою любимую функцию ползунка дат – когда вы определили класс вашего обслуживания на сегодняшний день – вы можете модифицировать дату начала работы и смотреть, в какие даты будет меняться класс обслуживания вашей задачи.

Это помогает вам очень быстро и легко просчитать класс обслуживания и еще легче планировать.

Еще мы внедрили туда подсказки по управлению зависимостями, но это уже тема для какой-то другой нашей встречи 😊

Ссылки на материалы, упоминающиеся в статье:

Полезные материалы по теме (на англ.):


 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *