ЛК
Меню
Что такое STATIK

Системный подход к использованию Канбан: разбираемся как нам поможет STATIK

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

STATIK (Systems Thinking Approach to Introducing Kanban) — это подход, который является результатом многолетней практики большого количества менеджеров и консультантов. Был описан в виде алгоритма Майком Барроузом (Mike Burrows). Он помогает компаниям применять принципы системного мышления для успешной реализации Канбана.

STATIK помогает понять текущее состояние системы, определить необходимые изменения и шаги для использования Канбан Метода.

Если вам требуется внедрение Канбан — оставьте заявку на бесплатную консультацию от Neogenda и мы поможем не внедрять, а использовать метод именно под ваш контекст.

Далее в статье:

  • что такое сервисная парадигма в Канбан;
  • STATIK и понятие сервисной археологии;
  • 8 шагов STATIK к использованию Канбана.

Что такое сервисная парадигма в Канбан

При объяснении что такое STATIK, часто встречается понятие сервиса, сервисного подхода и сервисной парадигмы. Многие могут подумать, что раз они производят продукт и не оказывают услуг клиентам, то эти методы организации процессов не для них. На самом деле понятие сервиса применимо к любому продукту. Разберемся подробнее, в чем же суть этих терминов.

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

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

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

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

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

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

А можно приобрести товар известного бренда с качественными линзами, поляризационным эффектом, с фирменным футляром для хранения и т. д.

То есть, покупая продукт клиент закроет сразу несколько своих потребностей:

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

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

Но есть и другой вариант: для кого-то очки с рынка — это то, что нужно. Для некоторой целевой аудитории это будет тот самый продукт, который закроет все потребности, в том числе — потребность в сервисе.

Важно помнить: не всегда и не всем нужно быстро-дорого-качественно. На каждый продукт найдется своя аудитория.

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

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

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

STATIK и понятие сервисной археологии

Алгоритм STATIK иногда называют сервисной археологией, потому что он направлен на изучение и раскрытие скрытых деталей процесса предоставления сервиса.

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

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

8 шагов системного подхода к использованию Канбана (STATIK)

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

Как стоит проводить STATIK в вашей компании? Ответ на данный вопрос будет зависеть от культуры вашей компании и готовности к использованию новых инструментов. Можно выделить несколько способов проведения:

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

У каждого из этих способов есть свои особенности, подробнее можно прочитать в книге Алексея Пименова.

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

Основная цель проведения STATIK заключается в изучении производственного процесса и описания его в виде канбан-системы. Спроектированная через STATIK Канбан Система будет отражать процесс поставки клиентской ценности в соответствии с:

  • реальной нагрузкой и возможностями сервиса;
  • существующими источниками неудовлетворенности;
  • особенностями реализации работ.

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

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

STATIK предлагает последовательность из 8 шагов. Прежде чем мы рассмотрим подробнее каждый из них, необходимо вспомнить, что любой продукт или услугу мы расцениваем как что-то, что удовлетворяет потребность заказчика — клиентскую ценность. Которую мы «производим» через Сервис поставки клиентской ценности.

Шаг 1. Анализ цели вашего сервиса

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

Важно ответить на следующие вопросы:

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

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

Шаг 2. Выявление источников неудовлетворенности

Второй этап направлен на выявление мотивации к изменениям через текущие проблемы сотрудников или заинтересованных лиц сервиса, основных проблем существующей системы или сервиса.

Источники неудовлетворенности можно разделить на две категории:

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

Если внутренних источников неудовлетворенности много и они достаточно сильные, то у команд сервиса не возникает эмпатии к заказчику и они не могут взять его источники неудовлетворенности в фокус. Важно понимать внутренние источники неудовлетворенности и устранять их для возможности появления эмпатии команд к источникам неудовлетворенности заказчика.

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

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

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

Шаг 3. Анализ нагрузки

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

Вопросы, на которые стоит ответить во время анализа:

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

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

  1. Определения того, как мы справляемся с работой.
  2. Грамотного планирования загрузки нашего сервиса поставки ценности.

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

Шаг 4. Анализ возможностей системы

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

Вопросы, которые следует задать на этапе:

  • Какие возможности уже имеет система и соответствуют ли они потребностям пользователей?
  • Какие есть типы работ?
  • Какие есть особенности у каждого типа работ?
  • Какая пропускная способность системы по каждому типу работ?
  • Каков процент выполнения каждого типа работ?
  • Как выглядит диаграмма распределения времени выполнения каждого типа работ (Lead Time Distribution)?
  • Какие ограничения существуют у системы сейчас и как они влияют на работу?

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

Определить возможности системы можно изучив распределение времени выполнения по каждому типу работ и Накопительную диаграмму потока (Cumulative flow diagram).

Что такое накопительная диаграмма потока

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

 

График Распределение времени выполнения рабочих элементов

Распределение времени выполнения рабочих элементов. Показывает статистические данные по времени выполнения завершенных задач. Сколько рабочих элементов данного типа за какое время было сделано. Строится отдельно для каждого типа рабочих элементов, только для элементов, работа над которыми закончена (они сделаны).

График, на котором видно несколько несколько типов рабочих элементов

Здесь мы видим на одной диаграмме несколько типов рабочих элементов. Нагляднее строить отдельную диаграмму для каждого. Источник изображения: https://www.youtube.com/watch?v=cw1U5XXXuiI

Шаг 5. Построение жизненных циклов

Полученный на этом этапе результат ляжет в основу визуализации процесса. На этом этапе важно определить, какой жизненный путь проходит запрос.

Проще всего это делать как большое упражнение, в котором задействованы все специалисты, обслуживающие ваш сервис поставки ценности:

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

На этом можно данный этап исследования считать законченным.

Шаг 6. Определение классов обслуживания

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

  • срочности;
  • приоритетности;Важно: под приоритетностью в контексте Канбан Метода мы понимаем механизм распределения внимания к работе, которая уже находится в производственной системе.
  • важности для процесса предоставления сервиса;
  • особенностей выполнения;
  • стоимости задержки поставки.

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

Шаг 7. Проектирование канбан-системы

Этап направлен на проектирование канбан-системы под контекст сервиса, на основании всех собранных нами данных. Доска не должна быть шаблонной или скопированной.

Суть STATIK-а в том, чтобы разработать систему, которая будет подходить под контекст конкретного сервиса. Один сервис — один STATIK.

Элементы Канбан-системы:

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

Система должна учитывать всю информацию, собранную на предыдущих этапах:

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

При проектировании Канбан-доски стоит следовать рекомендациям:

  1. Помните, что доска и стикеры — это отражение того, как у вас сейчас устроен рабочий процесс. Они не должны диктовать правила работы, они являются их отражением.
  2. Проектировать канбан-систему важно с теми, кто участвует в производственном процессе, а не приносить людям уже готовую.
  3. При проектировании есть два очень сильных визуальных элемента, видимых издалека и легко распознаваемых, — это цвета стикеров и дорожки. Используйте их для обозначения самой важной информации.
  4. Каждая Канбан Система уникальна и создается для контекста конкретного процесса. Их нельзя эффективно копировать из других подразделений или компаний.
  5. Помните, грамотный дизайн тикета упрощает дизайн доски. На карточке должна быть информация, которая помогает нам сделать доску проще. Например, использование чек-листов в карточках часто сокращает количество необходимых столбцов. Это может быть как в цифровом инструменте типа Кайтена, так и на бумажной карточке, если доска аналоговая (висит на стене в кабинете).

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

Пример Канбан-доски и дорожек с этапами работ

Пример Канбан-доски и дорожек с этапами работ

Шаг 8. Запуск и социализация

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

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

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

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

Важно всегда помнить: визуализация — это выходной артефакт. Она отражает то, как у вас идет работа в текущий момент. В начале вы должны поменять рабочий процесс и только потом отразить изменения на визуализации.

Нельзя сначала поменять WIP-лимит или добавить пару новых колонок на доску, а затем сказать команде, что теперь следует работать согласно доске. Доска не диктует правила работы — она их отражает. Поэтому вначале вы меняете процессы, договариваетесь с командой, убеждаете их в необходимости внесения изменений, подводите людей к самостоятельному принятию решения о корректировках производственных процессов, и только после принятия «новых правил игры» отражаете это на визуализации.

Итеративное повторение шагов

Итеративное повторение STATIK — важный фактор успешного развития канбан-инициатив.

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

Повторное проведение STATIK желательно делать регулярно, но не чаще чем раз в месяц.

Также могут возникать события при которых необходимо провести STATIK повторно, такие как:

  • изменение состава сотрудников вашего сервиса;
  • появление новых заказчиков или прекращение сотрудничества со старыми;
  • технологические изменения производственного процесса.

Хороший формат проведения повторного STATIK-а — проведение его в обратном порядке. Такой формат получил название Реверсивный STATIK (Reverse STATIK).

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

Если вам требуется помощь с внедрением Канбан или других методологий управления проектами — обратитесь в Neogenda. Наш тренинг ответит на все вопросы про запуск канбан инициатив и проведение STATIK. Прямо во время курса вы сможете разработать свою Канбан-систему для вашего процесса или команды.

Тренинги по теме

Введение в продуктовку

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

от 45 000 ₽

Продуктовка на максималках

Практикуемся в продуктовых исследованиях, определении позиционирования, разработки стратегии продукта, проектируем эксперименты, собираем экономику и дерево метрик продукта.

от 55 000 ₽


Подписка на рассылку

Раз в неделю отправляем дайджест о новых статьях и событиях в жизни нашей команды
Для заполнения данной формы включите JavaScript в браузере.