STATIK - Systems Thinking Approach to Introducing Kanban - это системное мышление при внедрении Канбан-метода.
Говоря о любой системе, мы понимаем, что это некая совокупность элементов, действий, шагов и т. д., находящихся в связи между собой и образующая некую целостность.
Системное мышление - это способ понять поведение системы как целого, а не путём анализа составных частей по отдельности. Это ключевое понятие, необходимое для определения шагов по внедрению Kanban в организации. Шаги в этом процессе не обязательно последовательны, но итеративны, таким образом, знания и умения, полученные на одном из этапов, влияют и помогают освоению других.
Дэвид Андерсон, как гуру метода Kanban и Enterprise Services Planning говорит о том, что таких шагов восемь.
Но прежде, чем переходить к первому шагу, важно понять, кто ваш реальный потребитель и какой сервис он ожидает.
Шаг 1. Критерии удовлетворенности потребителя
Изучите критерии, которые определяют удовлетворенность клиентов предоставлением услуги. Они, как правило, связаны со сроками, качеством, предсказуемостью, безопасностью и т.д.
Эти критерии известны как критерии удовлетворенности потребителя, потому что они определяют то, как оценивается ваш продукт, сервис или услуга приемлемой. Изучите и установите ожидаемые показатели для каждого критерия.
Эти критерии должны стать метриками эффективности продукта по которым можно будет понять, что идет не так или где у нас все отлично. Если этот шаг пропущен, вам неизбежно придется к нему вернуться. Без измерения удовлетворенности потребителя, будет совсем сложно понять, что идет не так.
Шаг 2. Источники неудовлетворенности текущей системой
Важно собрать обратную связь, как от внешних потребителей продукта, так и от внутренних. Внешние потребители - это клиенты. Внутренние - люди, производящие ваш продукт.
Обратная связь даст источники неудовлетворенности - вещи, которые мешают им качественно и профессионально делать свою работу и оправдывать ожидания клиентов. Часто источники неудовлетворенности на каждой стороне, внешней и внутренней, можно сопоставить - решить один, и второй решится сам.
Например, клиент может пожаловаться на непредсказуемость доставки и опоздания, в то время как внутри компании работники могут жаловаться на задержки и сбои по вине незапланированных или дополнительных задач с другим приоритетом. Если мы решим проблему незапланированных и дополнительных задач, мы можем устранить перебои в работе службы и сделать оказание услуг более предсказуемым.
Устранение одной проблемы может осчастливить обе стороны - работники не прерываются и могут сосредоточиться на профессиональном оказании услуг, а заказчик получает доставку в разумные сроки. Источники неудовлетворенности являются входными данными для Kanban-системы.
Шаг 3. Анализ спроса
Чтобы разработать подходящую Kanban-систему, мы должны понимать природу спроса: кто является клиентами; чего они хотят; каковы скорость и паттерны поступления запросов; каковы ожидания потребителей.
Понимание объема спроса, характера посещения и ожиданий клиента или бизнес-рисков, связанных с различными типами запросов, позволит нам разработать продуманную Kanban-систему с распределением нагрузки по различным типам и классам обслуживания.
Например, некоторый объём спроса связан с фиксированными сроками и точными датами, такими как сезонные события, праздники, выставки, крупные мировые события (например, Олимпийские игры) или нормативные даты, которые не подлежат обсуждению (выполнение требований регулятора).
Какая часть спроса приходится на их долю? Каковы темпы поступления таких запросов и когда они начинают поступать? Сколько времени у нас есть в запасе? Этот тип запросов может потребовать своего класса обслуживания, чтобы гарантировать приоритет обработки и выполнение задач в срок.
Шаг 4. Анализ возможностей
Анализ возможностей - это шаг, который часто пропускается новичками и незрелыми продуктовыми командами, или же при создании новой системы с нуля, когда нельзя оценить производительность уже существующей поставки услуг. Анализ возможностей включает изучение исторических данных уже работающих услуг. Анализируя возможности, мы понимаем текущее время и объем выполнения задач. На основе этих данных, появляется возможность оценивать новые задачи с наибольшей точностью.
Шаг 5. Модель рабочего процесса
Моделирование рабочего процесса должно выполняться для каждого типа задач.
Создавая модель рабочего процесса, мы должны следовать принципу, которой говорит о том, что каждый шаг процесса должен давать нам знания. Если нет знаний, значит этого шага не должно быть.
Если за пример взять процесс разработки программного обеспечения, то мы получаем знания анализируя проблему, создавая архитектурное решение, разрабатывая код, тесты и т. д. На каждом этапе мы обогащаемся новыми знаниями и знаем больше, чем на предыдущем, владеем более подробной информацией о конечном результате.
Это итеративный подход, при котором большее знание наслаивается поверх существующего и дает нам понимание, куда двигаться дальше. Очень часто, особенно в больших организациях, есть шаг «Согласование». На этом шаге, команды ожидают получить новые знания, которые они упустили ранее. Но раз они этого ожидают, значит вопрос не был проработан ранее и это говорит о низком качестве взаимодействия с другими участниками процесса.
При построении рабочего процесса, очень важно составить шаги действий, а не рабочих контактов. Мы должны акцентироваться на видах деятельности и что с ними происходит.
Шаг 6. Классы сервисов
Класс обслуживания - это набор описывающих правил, как следует работать с некоторым объектом (задачи, продукты и т.д.).
В Kanban-системах классы сервисов обычно описывают дисциплину очередей или приоритетный порядок задач. Классы обслуживания могут также описывать стратегию рабочего процесса, например, должен ли рабочий элемент быть обработан специалистом или протестирован на соответствие определенному уровню качества. Классы сервисов могут также давать информацию о расписании или о том, может ли данный элемент превышать ограничения WIP (работы, выполняющейся одновременно).
Если классы сервисов существуют, они должны быть зафиксированы, поскольку Kanban-система должна будет их учитывать. Обычно их называют скрытыми классами, например, указание руководителя. Запросы от руководителя обычно не проходят через формальные процедуры и отбор, но они становятся первоочередной задачей. Мы должны зафиксировать эти скрытые классы сервисов и сделать их явными. И чтобы справляться с ними, наша Kanban-система должна быть рассчитана на это.
Шаг 7. Проектирование системы Kanban
Чтобы спроектировать доску, нам нужно понять последовательность действий (рабочий процесс) для каждого типа работы. Нам необходимо принять решение, нужна ли нам единая доска для всех видов работ и классов обслуживания, или нужно две или более досок. Нам нужно решить, как распределить столбцы (они обычно обозначают этапы (состояния) рабочего процесса), строки (виды деятельности или сгруппированные типы работы) и цвет стикеров - задач (соответствующий классу обслуживания).
Если на вашей доске существуют задачи, у которых разный набор видов деятельности и они могут обрабатываться в любой последовательности и даже одновременно, мы можем выбрать простой дизайн доски со столбцами «План - В работе - Готово».
Метод Kanban предполагает регулярные встречи у доски. Выберите ведущего, частоту и продолжительность встреч, участников, какую информацию должен предоставить каждый участник, какие решения будут приниматься на этих встречах, какие показатели отчеты необходимы.
Шаг 8. Социализация системного мышления
Метод STATIK поощряет совместные встречи для анализа и совершенствования Kanban-систем. Вследствие совместной работы и общения, все участники оказываются увлечены переменами и ощущают личный вклад в реализацию проекта и гордость за него. Другими словами, наш основной подход к достижению личной заинтересованности участников во внедрении продукта и его вывода на рынок – это совместное участие в разработке/производстве.
Для семинаров STATIK разумно набирать межфункциональные группы с привлечением клиентов и других внешних заинтересованных сторон – влиятельных лиц, людей, принимающих решения, и органов управления - а также членов команды разработчиков. Цель состоит в том, чтобы вовлечь в проект как внутренних, так и внешних лиц.
Тем не менее, нереалистично полагать, что каждое вовлеченное лицо сможет поучаствовать в семинарах STATIK.
Имеет смысл встретиться с отдельными заинтересованными сторонами в частном порядке. Если они являются внешними заказчиками, нужно принять позицию смирения. Объясните, что вы понимаете, что предоставление услуг не соответствует целям, и вы пытаетесь внести изменения в рабочий процесс, чтобы улучшить его и лучше обслуживать клиентов. Объясните, что изменения в основном внутренние, но внешние участники смогут заметить изменения в том, как вы взаимодействуете с ними, в интерфейсе, который они используют для отправки запросов и утверждения или выбора объекта разработки, а также в некоторых показателях, отчетности и прозрачности новой системы по сравнению со старой.
Расскажите им, как новая система будет работать, объясняя это с их точки зрения. Прислушайтесь к их отзывам. Вы можете получить возражения, которые потребуют корректировки классов сервисов, распределения мощностей (канбан-ограничений), дизайна доски или требований к отчетности. Насколько это возможно, обещайте принять эти изменения. Постарайтесь прийти к согласию, что предлагаемые изменения помогут удовлетворить потребности заинтересованной стороны при условии надлежащего их внедрения.
Пересмотрите свой проект, чтобы учесть то, что вы узнали из общения с заказчиками.
Посетите ещё раз некоторых заинтересованных лиц, чтобы убедить их в том, что вы адекватно отреагировали на их замечания.
Запуск изменений
После этого, вы готовы провести стартовую (установочную) встречу для запуска Канбан-инициативы и начала изменений.
Пригласите всех заинтересованных лиц. Вы понимаете, что предоставление услуг не было достаточно хорошим, вы хотите изменить и улучшить то, как вы работаете, чтобы удовлетворить всех заинтересованных лиц, в условиях ограниченности ресурсов и необходимости прийти к некоторым компромиссам. Насколько это возможно, вы стремитесь сохранить то, что работает хорошо, и свести изменения к минимуму, сосредоточившись только на том, что необходимо для улучшения предоставления услуг.
Присутствующие могут заметить изменения в том, как они взаимодействуют с вами, но в остальном их роли и обязанности не будут затронуты. Теперь расскажите о деталях проекта, объясняя, как они затрагивают каждого участника и соответствующие ему типы рабочих элементов и классами сервиса. Внутренним участникам, тем, чьи роли или обязанности подвергнутся изменениям, объясните, что это значит для них и для тех, с кем они работают. Предоставьте подробные сведения о пересмотре существующих совещаний в целях внедрения регулярных встреч у доски Kanban. Объясните, где будут размещаться доски или какое программное обеспечение будет использоваться.
Успехов!
--
По материалам статьи автора Канбан-метода Девида Андерсона https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/
