Essential Upstream Kanban 9780984521470, 098452147X

Citation preview

Восходящий Канбан Руководство к бизнес-гибкости

Патрик Стеарт

Восходящий Канбан. Руководство к действию. Авторские права © 2017 Патрик Стюарт ISBN: 978-0-9845214-7-0 Первая цифровая версия, 23 Сентября, 2017. Текущая версия – 23 Сентября, 2017. Перевод: ​Филипьев И​. Вычитка и ревью: ​Климов К​. Редактура: с​ообщество LeanKanbab Community Russia​. Отдельные благодарности Екатерине Носковой и Сергею Федорову. Все права защищены. Эта публикация защищена авторскими правами, и для любого воспроизведения, хранения в поисковой системе или передачи в любой форме или любыми средствами, электронными, механическими, копировальными, записывающими или аналогичными должно быть получено разрешение от издателя. Для запроса на получение прав, индивидуальных изданий и оптовых заказов обращайтесь на ​[email protected]​. Книгу “Восходящий Канбан. Руководство к действию” можно загрузить на сайте www.leankanban.com/upstream​. Дополнительные печатные копии этой публикаций Канбана можно приобрести через ​www.shop.leankanban.com​.

и

других

Для получения списка аккредитованных классов, коучей и тренеров по Канбану, а также информации о том, как стать коучем или тренером в Канбане посетите http://edu.leankanban.com​, Для получения информации относительно частного обучения или консультаций для вашей организации посетите http://services.leankanban.com или напишите по адресу ​[email protected]​.

1

Содержание

Предисловие

3

Пролог

8

Условные обозначения

10

Иллюстрированный пример

11

Успех Системного Канбана

13

Гибкость, а не гибкий

18

Ограничить, чтобы преуспеть

20

Сквозной поток

22

Более глубокий / более широкий взгляд

25

Создание ценности

28

Расширяя границы

31

Восходящий Канбан

33

Клиентский Канбан

37

Клиентский Канбан – больше, чем Системный Канбан

40

Пример Бизнес-гибкости

42

Заключение

43

С чего начать

45

Благодарности

46

Об авторе

47

2

Предисловие

Мы склонны думать о канбан-системах и об их ограничениях на незавершенную работу (WIP-лимиты, незавершенное производство) как о решении для снижения перегруженности. На индивидуальном или командном уровне использование WIP-лимитов снижает перегрузку отдельных лиц и позволяет им сосредоточиться на отдельных задачах. В результате получается более качественная работа, выполненная с большим чувством удовлетворения. Люди чувствуют себя лучше, а клиенты замечают рост качества. Следствием такого подхода также является сокращение количества сделанно работы из-за более высокого качества. Также это может привести к улучшению времени выполнения и повышению производительности. Однако эти преимущества в основном являются внутренними. Только после того как мы избавим Канбан-систему от перегруженности, ограничив количество незавершенной работы на всех этапах рабочего процесса, мы увидим существенный рост экономических показателей, удовлетворенности клиентов и сокращение времени ожидания в очереди задач. В итоге Канбан-система, охватывающая весь процесс от момента принятия обязательств до момента поставки, значительно сокращает общее время производства и повышает предсказуемость. Канбан-системы полного цикла обеспечивают лучшее обслуживание клиентов и их удовлетворенность. Эти преимущества являются уже внешними. Гибкость предоставления услуг ощутимо растет. В ранние годы Канбан фокусировался на сотрудниках, представляющих IT-сервисы, которые отвечали за полное выполнение работы. Основное внимание уделялось более

3

быстрой и предсказуемой поставке. Следующее значительное улучшение пришло из практики принятия отложенных обязательств, поскольку работа, которую нужно было переделать, была ограничена лимитами Канбан-системы. Подразумевалось, что работа по подготовке запросов до передачи в IT-сервисы, т.е. работа “выше по течению” или “над потоком”, остается необязательной. Однако использование Канбана для улучшения поставки выявило еще один побочный эффект. Он связан с обязательным и жестким следованием требованиям «сортировки» или, проще говоря, пониманию того, что нужно делать, а что не нужно. В результате возникла необходимость ответить на такие вопросы, как: “Над чем мы должны работать сейчас? Что можно сделать позже? И если позже, то когда? Что мы вообще должны отбросить и не делать?” Для многих организаций, которые работают в сфере профессиональных услуг, организовать и настроить прозрачный процесс сортировки является очень сложной задачей. Индивидуумам никогда не приходилось ранее сталкиваться с трудными решениями: “Что, когда и сколько нужно делать? И хорошая ли эта идея вообще, то есть стоит ли ее делать?” По сути отрасли с такими товарами как реклама, исследования рынка, видеопродукция, разработка программного обеспечения, юридические услуги, HR и бухгалтерский учет неосязаемы по своей природе и борются с концепцией теории ограничений. В таких отраслях слишком легко сказать «да», дать обязательство и начать что-то делать. Гораздо сложнее потом это что-то сделать, т.е. довести до конца, и сделать это с предсказуемым временем завершения. Чем больше вы говорите «да», чем больше вы начинаете, тем меньше дел у вас в итоге заканчивается, и тем больше времени на это требуется. Любая предсказуемость окончания работ растворяется в бесконечном потоке дел. К счастью, у вас по-прежнему есть защита от перегрузок в виде установления ограничений на незавершенную работу. И как раз

4

эта выгода осязаема для тех, кто выполняет работу в таких отраслях. Если снижение перегрузки у тех, кто поставляет ценность клиентам, имеет смысл, можно ли освободить от подобных перегрузок творческих работников, тех, кто по своим обязанностям должен создавать новые концепции и проверять идеи? В 2010 году мы впервые заметили примеры проявлений так называемого канбана «выше по течению» (Upstream Kanban – далее Восходящий Канбан - ​прим. переводчика)​, возникающие независимо в Париже и в Бельгии. Патрик с тех самых пор и по сей день продолжает фокусироваться в профессиональной деятельности и работать над Восходящим Канбаном, совершенствуя творческие идеи компании с помощью Исследовательского Канбана и Клиентского Канбана. За сделанный вклад в развитие Канбан-метода он стал лауреатом престижной премии «Brickell Key» от LeanKanban. Восходящий Канбан и его варианты моделируют творческие рабочие процессы, процессы генерации идей и развития бизнеса и обеспечивают ограничения на незавершенную работу для устранения перегрузки сотрудников и творческих сервисов “выше по течению” сквозного потока создания ценности. Вместе с тем выяснилось, что более важным для находящихся выше по течению творческих сервисов является не ограничение количества вариантов развития идей, но сигнализация, подсвечивание необходимости дополнительного пополнения набора идей на определенном этапе работы. Иными словами, необходимо всегда иметь достаточное количество вариантов выбора для лучшего выполнения обязательств и облегчения процесса сортировки. Внедряя

5

минимальные

пределы

WIP-лимитов,

Канбан,

расположенный выше по течению, вводит второй вид сигналов в Канбан-методе. Этот вид существует в физических, материальных товарах и реализациях концепций. Есть Канбан, чтобы ограничить производство и предотвратить перегрузку системы, есть Канбан, чтобы уведомлять нас о необходимости пополнения идей. В обычной жизни это уведомление о необходимости поставки компонентов “точно в срок”, которые будут доставлены со склада и доведены до точки производства, как правило, в виде партии. Таким образом, Канбан “выше по течению” завершает внедрение и адаптацию Канбан-систем в сферах профессиональных услуг и нематериальных товаров. На каждом этапе процесса исследования выше по течению есть возможность отказаться от плохой идеи: слишком дорого; слишком сложно технически; займет слишком много времени; ограниченная ценность или что-то нежелательное для потребителей. Эта концепция известна как наличие “встроенных опций”. Восходящий Канбан или Канбан выше по течению – это не только управление потоком, как в Канбане “ниже по течению” или Канбан-системах поставки. Речь идет об упорядочивании или сортировке идей, чтобы иметь достаточный выбор вариантов в нужное время, но в тоже время не перегружать систему и творческих сотрудников, которые генерируют эти варианты. Это происходит за счет того, что мы перестаем просить их прорабатывать слишком много идей одновременно. Канбан выше по течению все еще является развивающейся областью. Это активная область для развития инноваций и создания новой интеллектуальной собственности, поскольку мы больше узнаем о том, как помочь творческим, деловым людям создавать идеи. Между тем, мы наблюдаем быстрый рост Канбана благодаря его корням из IT-поддержки и разработки программного обеспечения. Восходящий канбан дает нам возможности предложить лучший способ работы и управления

6

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

Дэвид Дж. Андерсон Секим, Вашингтон, США, Апрель 2017

7

Пролог Цель бизнес-организации – создавать ценность для клиентов посредством значимой работы. В быстро меняющемся мире это довольно сложная задача. Идеи, удовлетворяющие потребности клиентов, появляются гораздо быстрее, чем могут быть реализованы. Это становится причиной большой напряженности не только между организацией и клиентами, но также и в самой организации между теми, кто представляет интересы клиентов, и теми, кто удовлетворяет потребности и доносит ценность до клиентов. Бизнес-гибкость требует совершенно противоположного –чтобы те, кто изучает потребности, тесно сотрудничали с теми, кто удовлетворяет потребности. Ключ к успеху – это возможность подстроить быстро развивающуюся идею/запрос/требование к более медленному удовлетворению этой идеи/запроса/требования. В прежние времена решения нужно было принимать время от времени; мы все помним ежегодные бизнес-циклы, связанные с годовым бюджетом или годовым циклом выпуска продукции. Решения принимались редко и изолированно. Это часто приводило к тому, что клиенты или представители клиентов проталкивали большие партии запросов в команду поставки ценности, которая в итоге проталкивала большие партии выполненных запросов клиентам, которые в свою очередь были не в состоянии их принять или сделать с ними что-то осознанное. Сотрудничество между конечными клиентами, представителями этих клиентов (например, менеджером по продуктам, владельцем продукта или ключевым бизнес-пользователем) и командой поставки было из рук вон плохим. Сегодня,

8

когда

темпы

развития

бизнеса

растут,

а

неопределенность возрастает, решения нужно принимать гораздо быстрее и в совместном сотрудничестве. Многие организации уже сделали или совершают переход к сочетанию гибкой разработки, бережливого Канбана и непрерывной поставки, тем самым увеличивая скорость и частоту поставки. Однако очень быстро они понимают, что более быстрая и частая поставка сама по себе недостаточна. До тех пор пока не будут созданы надлежащие механизмы синхронизации скорости запросов со скоростью их выполнения, напряжение останется. Потребительский Канбан вместе с Восходящим Канбаном – это те самые механизмы преодоления этой напряженности и вовлечения всей организации (а не только команды поставки) в движение к цели «бизнес-гибкости». Откройте для себя уникальный подход, который называется Клиентский канбан, и узнайте, как начать думать с точки зрения бизнес-гибкости (в дополнение к гибкой разработке).

9

Условные обозначения Канбан (слово) появляется много раз в этой книге, но читатели заметят, что не всегда с большой буквы. ​Канбан, как метод появился в 2007 году после презентации управленческого подхода, который Дэвид использовал в Майкрософт (Anderson, 2005) и Корбис, а также после образования сообщества вокруг этой и похожих идей. “​Канбан метод​”, “​Канбан​” или “​Канбан сообщество​” всегда пишется с большой буквы, если используется в смысле метода. Однако, японское слово “канбан” (в значении “сигнал”, “сигнальная карточка”, “подсчет” или “большая визуальная доска”) использовалось в контексте определения процесса производства еще по меньшей мере с 1960-х годов, когда Тойота назвала системы для ​ограничения незавершенной работы на заводах “​канбан-системами​” (Шимокава, 2009). Такие системы являются лишь одним из многих проявлений ​Канбан-метода​, хотя именно благодаря им в сообществе и возникло само название метода. Таким образом, когда слово “​канбан​” используется в контексте ​канбан-систем​ , ​канбан-карточек (физических или виртуальных карточек для контроля незавершенной работы) или ​канбан-досок​ , оно пишется с маленькой буквы.

10

Иллюстрированный пример Предположим, что вы работаете в организации, которая занимается несколькими направлениями. Это могут быть проекты клиентов, разработка собственного продукта, изменения бизнеса, запросы от клиентов и так далее. Время от времени проекты выполняются и для новой работы высвобождаются ресурсы. В это же самое время клиент делает новый заказ. Все отлично. В идеальном мире мы можем управлять объемом вновь прибывшей работы и синхронизировать ее с производственными возможностями, которые нам доступны. Работа завершена, и требуемые навыки/возможности снова доступны именно в тот самый момент, когда необходимо браться за новый заказ. Скорость завершения текущей работы равна скорости поступления новой работы. Но… Мы живем не в идеальном мире. Новые заказы поступают тогда, когда нет свободных рук или нужные члены команды не готовы к старту; команда становится доступной, когда новой работы нет или клиент не готов к запуску готового проекта. Часто клиент делает новые заказы, еще не проверив результаты работы по старым заказам. Ни организация, ни клиент, находясь в изоляции друг от друга, не смогут преодолеть вышеуказанные препятствия. Они оба нужны для решения проблемы. В этой книге мы обсудим Клиентский и Восходящий канбан как способ сопоставить скорость спроса со скоростью обслуживания. Мы рассмотрим случай команды ИТ-поддержки, которая использовала Канбан для улучшения возможностей поставки. Мы выбрали такой пример, потому что он наглядно демонстрирует, почему недостаточно просто повысить скорость поставки (и в чем разница между простой маневренностью и бизнес-гибкостью. Тот факт, что команда уже использовала Канбан,а не, например, Скрам, пригодится нам, поскольку предлагаемое решение –

11

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

12

Успех Системного Канбана Время производства становится короче и более предсказуемым, а частота поставки увеличивается. Команда ИТ-поддержки, которую мы используем в качестве примера в этой книге, выполняет запросы на изменение существующего продукта, а также реализует небольшие проекты в системе планирования ресурсов предприятия (ERP), Business Intelligence

(BI),

электронного

обмена

данными (EDI) и

приложений Java. Исторически сложилось, что команда работает с постоянно большой очередью задач (80+ рабочих элементов, см. Рис. 1) и длительными непредсказуемыми сроками. Общее время обслуживания клиента (время от «пришел запрос» до «готово к поставке”) варьируется от менее чем одной недели до более чем тридцати

недель.

Кроме

того,

время

непосредственной

разработки, или время производственной системы от «Готово к разработке» до «Готово к приемке пользователем» (приемочное тестирование пользователей) было довольно большим, более тринадцати недель, и непостоянным.

Рис. 1: Спрос и возможности.

Чтобы лучше обслуживать своих пользователей, команда ИТ-поддержки начала использовать Канбан-метод. Первоначальный

13

фокус

этой

инициативы

заключался

в

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

Рис. 2: Нисходящий/Системный Канбан

Часто Канбан ассоциируется с визуальным управлением. На рисунке 2 показана канбан-доска команды ИТ-поддержки. Несмотря на то, что канбан-доски могут быть сами по себе полезны в работе, они являются лишь верхушкой айсберга. В этой книге мы будем проводить различие между визуальным управлением с помощью канбан-досок (часто также называемых “протоканбан”) и настоящими Канбан-системами. Цель настоящей Канбан-системы – улучшение потока работы. А именно потока работы в команде или в группе команд, которая/которые предоставляют услуги клиенту (в нашем случае внутреннему клиенту команды ИТ-обслуживания). По этой очевидной на наш взгляд причине мы будем ссылаться на эти Канбан-системы как на Системный Канбан. Системный Канбан начинается в момент принятия обязательств о том, что работа будет выполнена (обычно это этап “Готов к

14

работе” или “Сделаем”) и заканчивается в момент возвращения обязательств по выполненной работе, то есть непосредственно перед поставкой клиенту (обычно это этап «Готово к приемке»). Эти две точки являются границами Системного Канбана, в рамках которого команда может самостоятельно организовываться вокруг создания потока. Таким образом, Системный Канбан создает поток, позволяя сотрудникам вытягивать работу вместо того, чтобы решать за них, что им делать сейчас. Такой подход полезен, если мы хотим создать

для

людей

условия

творческой

атмосферы

и

сотрудничества. Он также полезен для клиента, поскольку это приводит к более надежному и комфортному обслуживанию. Вытягивание осуществляется либо с помощью ограничения незавершенного производства (WIP-лимит), либо иногда также с использованием видимых Канбан-токенов. Хотя

ниже

на

рисунке

3

показаны

как

ограничения

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

ограничений,

обеспечивающих

сотрудничество,

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

время производства коротким и

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

15

каденция по планированию того, над чем нужно будет работать команде, и каденция планирования того, что готово к поставке. Эти и другие каденции, петли обратной связи, такие как регулярные (операционные) обзорные совещания, помогают поддерживать и развивать поток. В изучаемом примере команда проводила встречи по пополнению очереди и планированию поставки и собирала качественную обратную связь по процессу через ретроспективные встречи как форму рефлексивного наблюдения с O-O-D-A: Наблюдать - Определять - Решать Действовать. Когда WIP-лимиты были установлены и поток стал более стабильным, накопились количественные данные о потоке и команда смогла начать активное экспериментирование с циклом Деминга PDCA (Планирование - Выполнение - Проверка Настройка). Результатом работы Системного Канбана является то, что время производства системы (время от этапа «Готов к работе» или “Сделаем” до этапа «Готово к приемке») становится все короче и стабильнее, а скорость поставки медленно увеличивается. Таким образом

команда

может

начать

выполнять

обещания

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

оптимизирован

путем

проведения

небольших

экспериментов (например, парная работа для дальнейшего расширения узких мест).

16

Рис. 3: Системный Канбан

17

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

привело

к

ряду

характеристик,

которые

часто

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

кросс-функциональная

команда​:

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

WIP-лимиты, Часто

кросс-функциональным.

членам это

В

команды

сотрудничество

изучаемом

необходимо является

примере фактически

поощрялось сотрудничество между людьми с различными компетенциями, чтобы расширить узкие места в процессе работы. Благодаря этому расширению и сотрудничеству команда стала более функциональной. Инспекция и адаптация: Системный Канбан управляется короткими петлями обратной связи. Самая короткая петля обратной связи обеспечивается WIP-лимитами. Они дают обратную связь, можно ли начинать новую работу или нет? Канбан-каденции, такие как операционное ревью, представляют собой еще один набор циклов обратной связи. Что еще более важно, драйвер сокращения времени производства – это уменьшение циклов обратной связи между теми, кто выполняет работу, и теми, кто должен принять работу. Короткое время производства связано с повышением ловкости, независимо от того, использует ли команда Agile разработку или нет. Стоит отметить, что с уменьшением времени производства также

18

приходит стабильность. Это делает команду одновременно более гибкой и предсказуемой.

19

Ограничить, чтобы преуспеть Ловкость на уровне команды будет только тогда, когда есть тесное

взаимодействие

и

сотрудничество

между

бизнес-командой или клиентом. Благодаря Системному Канбану команда ИТ-поддержки смогла обеспечить пользователям положительные результаты, поскольку ее действия по сокращению незавершенного производства (установление WIP-лимитов) привели к более коротким и стабильным срокам производства системы и к более высокой скорости поставки. Бизнес-пользователи («Клиенты» команды) признали эти улучшения. Тем не менее, они считали, что требуется ещё больше улучшений. Для бизнес-пользователей общее время производства от начала до конца (время от появления запроса на выполнение до его полной реализации) оказалось более важной метрикой, чем время производства системы (​время производства в команде ИТ-поддержки - прим. переводчика​).

Для

бизнес-пользователей

отсчет

времени

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

20

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

возвращается

в

виде

результатов

обратно

к

пользователям). Они считали, что бизнес-пользователи должны сотрудничать с ними для завершения работы. Было очевидно, что ловкость (​маневренность, проворство - прим. переводчика​) на уровне команды ограничена этими пределами. В этом случае им необходимо было начать сотрудничество не только внутри команды, но и между командой разработки и заказчиками. При этом они должны были не только продолжать выполнять обязательства, которые взяли на себя, но и учитывать входящую и нисходящую работу. Если говорить в терминах Канбана, им необходимо было начать рассматривать сквозной поток. В следующих главах мы объясним, почему и как.

21

Сквозной поток Согласно английскому словарю, поток – это устойчивое, непрерывное действие (или факт) перемещения. В терминах бизнеса поток – это создание ценности для клиента посредством значимой работы. Явным в данном определении является то, что важны обе стороны – и клиент с потребностью и спросом, и сотрудники, которые удовлетворяют потребность и спрос. Неявным в определении является то, что основное внимание уделяется ​короткому времени производства​. По существу это означает, что время между стартом и завершением должно быть коротким. В сквозном потоке в бизнес-контексте это означает, что между подозрением на необходимость удовлетворить какую-то потребность клиента и удовлетворением этой потребности время должно быть коротким (или, по крайней мере, должно быть коротким время, затраченное на получение опыта при попытке сделать это). Системный Канбан фокусируется на потоке работы в рамках определенного сервиса. Как показано на рисунке 4, это лишь относительно небольшая (хотя и важная) часть сквозного потока. Учитывая, что границы вытягивающей системы являются (по определению) двусторонними (Системный Канбан не является исключением из этого), подразумевается, что в то время, когда исполнители уже могут жить по принципу вытягивания новой работы, клиенты могут все еще жить в мире проталкивания этой самой работы (т. е. проталкивания запросов, идей, требований и т. д.).

22

Рис. 4: Системный Канбан в контексте сквозного потока.

Процесс проталкивания заказов клиентами сегодня – это, как правило, Восходящий поток с (большим) запасом заказов (очередью

работ),

стоящий

перед

Системным

Канбаном.

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

заказы,

которые

не

соответствует

разнообразию

компетенций в команде). Команда или простаивает, или работает на низком уровне качества или с низким уровнем ценности, в то время как работа с высоким уровнем ценности застревает в дебрях Восходящего потока. Это часто приводит к более высоким затратам (например, простаивающая команда ИТ-поддержки) или потере потенциального выигрыша (упущенные возможности из-за задержки поставки). В целом, постоянный поток работ может быть устойчивым только в той мере, в какой существует постоянный ​поток запросов, когда ​клиенты вытягивают что-то ценное для себя, а не просто

23

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

24

Более глубокий / более широкий взгляд Пришло время взглянуть на сквозной поток от запроса к поставке. Вскоре

после

внедрения

Системного

Канбана

команда

ИТ-поддержки приступила к внедрению Канбана выше по течению (Восходящий Канбан) (см. Рис. 5). Целью Восходящего Канбана было управление потоком входящих запросов, прежде чем по ним будут даны обязательства о выполнении в Нисходящем (Системном) Канбане. Восходящий Канбан был смоделирован в соответствии с жизненным циклом запросов на изменение (CR) и жизненным циклом проектов, который был согласован с консультативным советом по изменениям (CAB). Жизненный цикл запросов на изменение требовал, чтобы для небольших запросов была заполнена карточка оценки изменения с целью оценки приоритета CR. В случае непонятности CR требовалось разъяснение от бизнес-заказчиков. Проекты в свою очередь

требовали

так

называемый

план

бизнес-требований.

Figure 5:

25

Upstream +Downstream Kanban

согласования

Доска,

которую

команда

использовала

для

визуализации

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

пользователям.

Сквозной

поток

состоял

из: 1)

восходящего, 2) нисходящего потоков и 3) набора опций 1​ – рабочих элементов, которые ожидают, что по ним будут даны обязательства о выполнении. Набор опций находился между восходящим

и

нисходящим

потоками.

Точка

принятия

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

основано

на

системном времени выполнения. Это

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

WIP-лимитов,

означало,

что

над

временем,

затраченным на эти шаги рабочего процесса, нет контроля. Одни бизнес-заказчики быстро реагировали, когда элемент готов к приемке, другие никогда не были готовы принять выполненную работу. 2. Смотря на поток выше по течению, команда не могла дать какие-либо честные обещания о времени выполнения до тех пор, пока не будет пройдена точка принятия обязательств. Причина крылась в большом наборе опций прямо перед точкой принятия обязательств. a. Некоторые запросы сталкивались с различными трениями в восходящем потоке. Часто это были небольшие, но очень заметные проекты, которые имели высокую и неопределенную ценность. Из-за трений (т. е. различий во

26

мнениях, наличия заинтересованных сторон и т. д.) они, как правило, застревали до тех пор, пока не попадали в категорию “ускоренных” задач. Поскольку команда из нисходящего

потока

не

могла

обосновать

несостоятельность таких “ускоренных” проектов, они часто приводили к слишком большому объему работы ниже по течению. b. Многие другие элементы, такие как изменения с низким приоритетом, не сталкивались с этим трением. Они быстро перемещались в восходящем потоке до точки принятия обязательств. Однако застревали в наборе опций перед ней, поскольку их продолжали обходить более высокие, приоритетные и ускоренные запросы. Результатом стало сильно изменчивое сквозное время ожидания клиента, как показано на рисунке 6 (ось x = время производства (ожидание клиента) в неделях, ось y = частота повторения ожидания). Следует отметить обратную корреляцию между временем проработки запроса в восходящем потоке и общим временем ожидания клиента. Запросы с коротким временем проработки выше по течению (например, небольшие изменения) имели тенденцию превышать средние сроки общего времени ожидания

клиента;

и

наоборот.

Я

оставляю

читателю

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

Распределение времени ожидания клиента

27

Создание ценности Выделение восходящего потока в отдельную часть процесса было сделано для получения оптимального выбора среди входящих запросов. Основная идея здесь – разделить принятие решения об исполнении и фактическое исполнение: бизнес определяет приоритеты, а команда ИТ-поддержки обеспечивает исполнение в соответствии с приоритетами. Такой подход усиливает роль группы ИТ-поддержки как исполнителя и бизнеса как заказчика. Кроме того, принятие решений основывается на количественной оценке запросов. Все запросы ранжируются на основе карты оценки (скор-карты). Рассмотрим приведенный пример с этой позиции. Для анализа и оценки запросов прилагались очень большие усилия. Однако эти усилия не приводили команду к оптимальному результату. Запросы с высокой ценностью или высоким уровнем риска сталкивались с большим трением выше по течению (задержки, переделка, путаница...). Они не только требовали наибольших усилий для оценки, но также являлись наиболее вероятными кандидатами на откладывание, изменение или даже отказ. Это приводило к бессмысленной потере времени и сил. С другой стороны, запросы с низкой ценностью/низким уровнем риска, которые сталкивались с небольшим трением в восходящем потоке, были склонны перемещаться быстро выше по течению, но затем не выполняться. Опять же, это приводило к пустой трате сил и разочарованию. Команде ниже по течению казалось, что существует маленький запас работы с высокой ценностью/более высоким риском (если только они не попадают в категорию “ускоренных”)

и

большой

запас

работы

с

низкой

ценностью/низким уровнем риска. Большие усилия, затраченные на принятие решений, в конце концов, казались противоречием

28

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

высока

(как

в

запросах

с

высокой

ценностью/высоким риском), желательно все же разделить оценку на этапы. В более технических терминах это означает, что для запросов с низкой неопределенностью мы можем выполнять полную проверку и оценку сразу, как только мы решим оценить запрос. Для работы с высокой степенью неопределенности мы сначала создаем опцию (т. е. первоначальную ограниченную оценку усилий), прежде чем делать полную аналитику и всю работу по оценке элемента. Ниже мы увидим, как это происходит на практике:

Не вся ценность одинакова.

29

Из приведенного выше анализа ясно, что в рассматриваемом примере были возможности для улучшения. В то время, как команда ИТ-поддержки уже работала со своей «Канбан-доской» как с Системным Канбаном (с этапами от «Готово к работе» до «Готово к приемке»), остальная часть доски стала представлять собой визуализацию процесса сортировки, правда пока без остальных практик Канбан-метода (иногда такие “неполные” Канбан-системы еще называют «протоканбаном»). Однако даже такая визуализация выявила проблемы в сквозном потоке. В восходящем потоке, который, с одной стороны, граничил с Системным Канбаном, запросы на работу (также называемые “возможностями”) помещались в очередь перед точкой принятия обязательств. Впоследствии они стали вытягиваться отсюда в столбец команды “Готово к работе”. С другой стороны, ниже по течению от Системного Канбана, работа стала возвращаться клиенту на приемку. В следующих двух разделах мы рассмотрим, как можно расширить сферу покрытия Системного Канбана, чтобы охватить более широкую часть сквозного потока, заново рассмотрим Восходящий Канбан и подойдем к представлению Клиентского Канбана.

30

Расширяя границы Чтобы охватить более широкую область сквозного потока, нужно расширить рамки канбан-системы. Чтобы добиться более надежного времени производства для конечного клиента и улучшить с ним взаимодействие, команде из нашего примера необходимо было распространить “принцип вытягивания” работы выше и ниже по течению. Прежде всего нужно было пересмотреть Канбан выше по течению. Целью Восходящего Канбана является оценка различных вариантов и подготовка рабочих элементов, чтобы они были готовы к работе. Смысл заключался в том, чтобы команда выполняла работу без неоправданных задержек. Канбан-доска Системного Канбана и накопительная диаграмма потока (CFD, см. Рисунок 7) указали на недоработки на этапе подготовки рабочих элементов в восходящем потоке. Команда заметила большое количество незавершенной работы

Рисунок 7: Накопительная диаграмма потока (CFD) для нисходящего потока.

на этапе “Анализ в работе” после этапа “Готово к работе”. В CFD

31

можно заметить, что большое количество элементов на этапе “Анализ в работе” не случайно. Оно отображается как большая область в CFD (светло-голубая область в верхней части CFD). Дальнейшее исследование показало, что работа, как правило, блокировалась, потому что рабочий элемент не был должным образом подготовлен. Как правило, было не совсем ясно, что нужно

сделать,

требовалось

дополнительное

разъяснение

бизнес-заказчика и/или данные, необходимые для дальнейшего анализа.

Другие

проблемы,

например,

обнаружение

конфликтующих точек зрения между пользователями только после начала работ, свидетельствовали о том, что процесс в восходящем потоке необходимо пересмотреть. Команда решила, что запросы на изменение и (небольшие) проекты должны проходить через аналогичный, но немного измененный процесс в восходящем потоке. Они сочли важным сделать четкое разделение в процессе восходящего потока между этапами синтеза и анализа (см. ​Рис. 8​). Первый шаг – синтез – направлен

на

пользователями противоречивыми

поиск и

их

компромисса

между

эпизодическими,

запросами

путем

а

различными иногда

создания

и

общей

согласованной концепции. Только после этого концепция может быть детально описана, проанализирована и, при необходимости, разбита на рабочие элементы, которые могут быть переданы дальше для исполнения. Команда сочла, что правильный синтез необходим, чтобы избежать недопонимания для работы с высокой ценностью/высоким риском. Для работы с низкой ценностью/низким уровнем риска шаг синтеза можно было пропустить. На ​Рисунке 10 показано, как была спроектирована Канбан-доска восходящего потока.

32

Восходящий Канбан Команда также осознала, что процесс выше по течению по существу является процессом сортировки: каждый запрос должен пройти несколько этапов отбора (см. рисунок 9), но не все запросы должны проходить через одинаковые этапы и не в каждом этапе есть "острая необходимость". Раньше выбор был главным образом основан на «готовности» запроса к работе: если запрос заключался в небольшом изменении, имел низкий приоритет и был готов к следующему шагу, переход выполнялся практически сразу. Поскольку небольшие запросы не требовали большого количества синтеза или анализа, они, как правило, моментально наполняли набор опций (вариантов для работы) до точки принятия обязательств (они почти сразу переходили от стадии «Идея/Запрос» к стадии «Готов к обязательству» на Канбан-доске выше по течению). С другой стороны, проекты с более высокой стоимостью, которые требовали более сложной работы выше по течению (синтез и/или анализ), застревали, пока не становились неотложными.

Рисунок 8: Процесс выше по течению для высокоценных/высокорисковых запросов.

33

Рисунок 9: Опциональный отбор в процессе выше по течению.

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

34

Возможно не выживут в процессе отбора выше по течению. Немедленно отказаться. Чрезвычайная срочность. Пропустить восходящий процесс сортировки и отбора; требует немедленного внимания ниже по течению. Высокая, но неопределенная ценность. Начинать пораньше, но давать обязательства попозже: сначала создать опцию (провести частичный анализ). Низкая, но определенная ценность. Обязательства могут быть даны по требованию (сразу). Начинать только при необходимости.

Рисунок 10: Восходящий Канбан со структурой сортировки и минимальным пределом.

Следующей за структурой сортировки была введена концепция “минимальных WIP-лимитов”. Ее цель – исключить отсутствие работы в нисходящем потоке (т. е. избежать отсутствия вариантов для выбора у команды ниже по течению). Вместо WIP-лимитов, которые налагают максимальное ограничение на незавершенную работу, минимальный WIP-лимит устанавливает минимальное количество рабочих элементов, которые должны быть в работе. Минимальный WIP-лимит работает как точка

35

заказа. Когда предел не достигнут, он требует внимания команды и бизнес-пользователей. Как только предел достигнут, внимание снова направляется в другое место (например, к поставке ниже по течению, если речь идет о членах команды ИТ-поддержки или повседневной деятельности бизнес-пользователей). Правильно составленные правила могут служить руководством к действию для команды и бизнес-пользователей, какой приоритет следует задавать наполнению системы работой, если минимальные пределы не достигнуты.

36

Клиентский Канбан От проталкивания клиентами к вытягиванию клиентами. Но одного только Восходящего Канбана недостаточно. Несмотря на то, что он создает условия, в которых у команды ИТ-поддержки в любой момент времени есть достаточный выбор для работы с правильной сортировкой, это не мешает клиентам (или бизнес-пользователям, как в рассматриваемом случае) проталкивать работу в команду. Часто это выглядело так: бизнес-пользователи создавали запрос на работу и использовали всё могущество для работы команды над этим запросом, но не могли ей помочь, когда было необходимо. Часто это отсутствие помощи проявлялось в том, что работа была на этапе «Готово к приемке», но бизнес-пользователи не принимали ее.

Рисунок 11: Клиентский Канбан.

«В идеальном мире темп спроса соответствует темпу выполнения работ; в реальном мире такое бывает редко. Клиентский Канбан вовлекает команду и клиентов для решения этой проблемы».

37

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

на

рисунке

11,

Клиентский

Канбан

вводит

одноуровневое CONWIP-ограничение (CONstant – постоянный, WIP – работа в процессе) поверх ограничений Системного Канбана и ограничений минимального предела Восходящего Канбана. На практике это выглядит следующим образом: клиенты/заказчики получают несколько токенов (ключей) для Клиентского Канбана. Каждый клиент может в любое время передать в работу новый запрос (он появится в столбце «Идея/Запрос»), но из этого столбца для дальнейшей работы (или подготовки работы) разрешается вытягивать новый запрос только тогда, когда у клиента есть свободный ключ Клиентского Канбана. Этот ключ прикрепляется к запросу в момент вытягивания и возвращается клиенту тогда, когда тот принимает результаты работы готового к поставке запроса (т. е. когда элемент «Готов к поставке»). Общая идея заключается в том, что клиент не должен передавать в работу новые запросы до тех пор, пока старые обрабатываются или ждут приемки. Получается следующее: в то время как WIP-лимит Системного Канбана необходим для коротких и стабильных сроков работы команды ИТ-поддержки (стабильное время производства, важное для команды), Постоянный лимит (CONWIP-лимит) Клиентского Канбана имеет важное значение для короткого и стабильного времени выполнения заказов клиентов (время между возникшей потребностью и ее удовлетворением, т.е. время, важное для клиента).

Бизнес-пользователям

необходимо

сотрудничать,

и

чтобы

команде

ИТ-поддержки

оставаться

в

рамках

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

38

которое в свою очередь включается WIP-лимитами. В целом Восходящий и Клиентский Канбан расширяют границы Канбана. Они вводят два новых сигнала-петли обратной связи. Первый

–

это

минимальный

WIP-лимит,

а

второй

–

CONWIP-лимит. На практике они могут использоваться по отдельности. Но если мы хотим создать постоянный поток запросов и вытягивание от клиентов, должны присутствовать оба. Если

CONWIP-лимит

имеет

более

глобальный

характер

(гарантируя, что общее количество запросов в работе будет постоянным), минимальный WIP-лимит имеет более локальный характер

(обеспечивая

достаточное

количество

рабочих

элементов на каждом этапе потока выше по течению). Поскольку они связаны, мы часто используем термин Клиентский Канбан как обобщающий для Клиентского и Восходящего Канбанов. О Клиентском и Восходящем Канбане можно рассказать гораздо больше. В приведенном выше примере осталось несколько вопросов. Как установить CONWIP-лимит? Как определить CONWIP-лимит для разных типов клиентов? Как определить минимальные WIP-лимиты? Нужны ли вам максимальные WIP-лимиты в дополнение к минимальным WIP-лимитам? (Я полагаю, что нет, особенно если CONWIP-лимит уже установлен). Какие петли обратной связи и каденции должны быть введены в действие и т. д.? Ответы на эти вопросы остаются для дальнейших публикаций и презентаций.

39

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

имеет

проталкивающие-вытягивающие

границы.

В

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

если

команда

уже

работает

по “вытягивающему”

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

40

Несмотря на то что Клиентский и Восходящий Канбан – это еще не окончательный сквозной поток, все же это еще один шаг к нему. Стоит рассказать читателю о еще более обтекаемом потоке, который учитывает обучение с обратной связью от клиентов (как показано в сквозном потоке на рисунке 4). Этот поток определяется еще бóльшим набором Канбан-систем, которые называются запросов

с

Исследовательским Канбаном. Помимо потока клиентским

вытягиванием

в

Восходящем

и

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

рефлексивного

наблюдения

и

экспериментирования.

Рисунок 12: Клиентский Канбан в сравнении с Системным Канбаном

41

активного

Пример Бизнес-гибкости Ключевой

характеристикой гибкости является способность

быстро реагировать на изменения, не теряя скорости. Гибкие команды

разработки

демонстрируют

эту

характеристику,

позволяя пользователю повторно пересматривать и изменять требования

по

мере

выявления

новых

потребностей.

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

с

разнообразными,

изменяющимися

запросами,

отрывочными

часто

и

созданными

противоречивыми

требованиями, когда задействованы несколько клиентов или заказчиков. Без надлежащих механизмов, даже когда команды работают

в

формате

продолжать

настаивать

гибкой на

разработки, выполнении

клиенты могут запросов

без

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

или

их

представители

проблемы,

максимальную

отдачу

описанной

испытывают выше.

Чтобы

зеркальное получить

от команды, они должны создать

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

42

Заключение Сегодняшний

деловой

ритм

требует

Бизнес-гибкости.

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

и

большему с

числу

организаций

изменчивыми,

неполными

приходится и

часто

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

темп

удовлетворения. меняющиеся

приходящих Однако

требования

запросов

недостаточно только

одного

с

темпом

их

реагировать

на

клиента.

Также

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

возможных

вариантов,

которые

могут

быть

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

43

способом содействия этому сотрудничеству. Он опирается на основы Канбана. Системный Канбан (Канбан уровня команд, с которым организации уже хорошо знакомы сегодня) развивает командную

гибкость

(гибкость,

которая

сродни

гибкой

разработке) с использованием WIP-лимитов; Клиентский Канбан развивает бизнес-гибкость за счет использования минимальных лимитов и CONWIP-лимитов. Вместо того чтобы просто фокусироваться на потоке работы, он фокусируется на сквозном потоке

(от

подозрения

на

удовлетворение

запроса

до

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

процессов

управления

продуктом

с

процессом разработки продукта (а также согласованных действий между менеджерами продуктов); 3. Проектные организации или аутсорсинговые компании, которые могут использовать Клиентский Канбан для согласованных действий с клиентом. Хотя этот список не является полным, он дает представление о том, когда и где применимы Клиентский и Восходящий Канбан. На следующей странице мы закончим некоторыми указаниями о том, как начать работу с Клиентским Канбаном.

44

С чего начать Первым шагом в направлении “Бизнес-гибкость” является опыт потока – не только на уровне команды, но настоящего сквозного потока. Концепция потока, как уже отмечалось в этой книге, не является легкой концепцией для людей, которые ее не испытывали. Рациональные объяснения потока пока только появляются. Часто их недостаточно для запуска потока в команде или организации. Поток должен быть испытан. Это проблема начального запуска: чтобы запустить поток в команде, он должен быть испытан; чтобы иметь возможность испытать поток, команда уже должна использовать поток. Для решения проблемы запуска в примере, который мы описали (и во многих других случаях), мы использовали обучение через моделирование потоков – так мы называем нашу лабораторию потока. В лаборатории потока команды погружаются в мышление потока,

рефлексивное

экспериментирование

наблюдение

посредством

и

активное

моделирования,

которое

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

(зависимости

между

командами)

и

вплетение

экспериментов в поток (Исследовательский Канбан). Больше информации об ​Okaloa Flow lab ​и/или ​Канбане Открытий в​ дополнение к ​Восходящему Канбану и​ Клиентскому Канбану,​ вы можете получить от автора (​[email protected]​) или через веб-сайт Okaloa (​www.okaloa.com​).

45

Благодарности Прежде всего я хотел бы поблагодарить моего партнера Арлетт за поддержку и помощь в написании этой статьи. Кроме того, я хотел бы поблагодарить людей, которые прочитали эту статью и помогли мне оформить мысли: Арно Корпершук, Йохан Ванвелкенхуйзен, Томас Де Фриз, Винсент Вандерхерен и Вим Боллен. Глава “Иллюстрированный пример” была вдохновлена постом в блоге Павла Бродзински. Патрик, 27 сентября 2016

46

Об авторе Патрик Стюарт [email protected] Патрик Стюарт – интегративный мыслитель

и

агент

изменений,

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

гибкости

предсказуемости

в

и

контексте

инноваций и изменений. Он является тренером университета Lean Kanban, коучем и постоянным спикером на международных конференциях. Патрик также является лауреатом премии Brickell Key в 2015 году за работу над Исследовательским Канбаном, что является признанием исключительного вклада в Канбан-сообщество. Вместе с Арлет Веркаммен Патрик Стюарт основал Okaloa, чтобы помогать клиентам привносить больше “потока” в организациях, используя в его основе интегративный подход Канбана. Список клиентов

Okaloa

варьируется

от

высокотехнологичных

SME-компаний до крупных компаний, применяющих Канбан в трансформации и реализации стратегии.

47

О Lean Kanban, Inc. Lean Kanban, Inc. (LKI) занимается разработкой и продвижением принципов и практик Канбан-метода для достижения высокого качества предоставления профессиональных услуг посредством использования Канбана. Программы LKI включают профессиональную подготовку, сертифицированную учебную программу, мероприятия и публикацию материалов.

Сертифицированные тренинг по Канбану Lean Kanban University (LKU) предлагает полный учебный план сертифицированных тренингов по Канбану, начиная от начального и до продвинутых уровней, а также корпоративных услуг. Посетите www.edu.leankanban.com​, чтобы найти сертифицированное обучение Канбану или опытного тренера или коуча в вашем регионе. Кроме того, Lean Kanban Services предлагает частное обучение, коучинг и консультации по всему миру.

Программы лицензирования LKU предлагает обучение руководителей и программы лицензирования для менеджеров, тренеров и коучей. Профессиональные направления включают Kanban Team Practitioner, Kanban Management Professional, Kanban Coaching Professional и Accredited Kanban Trainer. Посетите сайт ​www.leankanban.com​для получения дополнительной информации.

Международные конференции Присоединитесь к международному сообществу Канбана с мероприятиями Lean Kanban. Мероприятия Lean Kanban фокусируются на предоставлении прагматичного, действенного руководства для повышения гибкости бизнеса и управления рисками с помощью Канбана и связанных с ним методов. Посетите сайт www.conf.leankanban.com​для расписания предстоящих конференций и мероприятий.

48