Проанализируйте спрос и свои возможности

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

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

Такой анализ должен обеспечить и качественное, и количественное понимание. В качественном плане:

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

В количественном плане:

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

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

Знание того, что вы поставляете, кому и почему

Что

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

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

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

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

Вот как две команды, в работе которых я участвовал, могли бы описать свое «что»:

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

Кому

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

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

Вот как две команды, упомянутые выше, могли бы описать свое «кому»:

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

Зачастую «кому» оказывается множественным: в таких случаях имеет смысл выяснить, различается ли производственный процесс, ориентированный на разных клиентов.

Почему

Мы уже многое установили, но «что» и «кому» — это на самом деле лишь преамбула к главному вопросу: «Почему?»

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

1. «Наши платные клиенты потребляют энергию (электричество, газ, нефть) в таких количествах, что им стоит хеджировать свои риски, покупая часть этого товара заблаговременно (иногда за несколько месяцев) или приобретая деривативные контракты. Наши инструменты помогают им покупать и продавать нужные объемы в нужное время, так что своевременная доставка информации здесь жизненно важна. Мы усиленно работаем и над расширением охвата рынка (энергетические рынки очень фрагментированы), и над тем, чтобы обогнать конкурентов по сложности инструментов и по своевременности поставки информации».
2. «Торговля облигациями всегда сопряжена с риском: процентным риском, кредитным риском, контрагентским риском, которые нужно хеджировать. Деньги здесь крутятся огромные! Никто из участников не может себе позволить надолго отвлекаться от рынка, особенно в те моменты, когда делаются ключевые объявления и выдвигаются важнейшие предложения. Нашим пользователям нужна быстрая и надежная платформа, способная адекватно справляться с постоянно растущим разнообразием и объемом сделок, которые осуществляют бизнес-институты высшего эшелона».

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

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

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

Количественный анализ

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

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

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

Если можно, визуализируйте это! Временны́е диаграммы (как на рис. 19.1) отлично подходят для отражения количественных показателей, изменяющихся в зависимости от рабочей задачи или выборки, даже когда сам объем выборки ежедневно меняется.

Гистограммы показывают распределение данных. Рис. 19.2 основан на тех же интервалах разработки для клиента, что контрольная диаграмма на рис. 19.1. Может оказаться существенным, что на этом графике два пика (они соответствуют интервалам в один день и в три дня): возможно, данные естественным образом разбиваются на две различные «популяции».

Диаграммы Парето служат для организации классифицированных данных, например рабочих задач по типу клиентов или дефектов по их основной причине. Такие графики полезны, когда нужно выстроить приоритеты анализа. На рис. 19.3 видно, что на клиентов А и В (в общей сложности) приходится 80% работы. Вероятно, на данном этапе не очень-то продуктивно фокусироваться на клиентах C, D и Е. Конечно, у вас может возникнуть искушение представить эту информацию в виде круговой диаграммы, но она совсем не так наглядно показывает ранжирование параметров.

Даже на этой начальной стадии иногда можно использовать диаграмму суммарного потока (см. главы 1 и 17). Первая часть диаграммы на рис. 19.4 получена из одной презентации в SharePoint, найденной мною. Я очень обрадовался такой находке, поскольку уже готовился прошерстить протоколы совещаний за несколько месяцев. В итоге я всего за пару часов сумел собрать нужные данные и наглядно представить 50-кратный рост пропускной способности. Так что иногда такой подход явно стоит применять!

Эффективность потока

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

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

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

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

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

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

Как к нам прибывает работа

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

Для каждого типа работы нужно выяснить:

• Как она прибывает? Это активный поиск работы, пассивное ожидание ее прихода или нечто среднее — беседы, переговоры, исследования и т.п.?
• С какой скоростью она прибывает (сколько единиц в день, в неделю, в месяц)?
• Она появляется регулярно (скажем, на заранее спланированных совещаниях) или случайным образом (скажем, когда клиенты звонят в службу поддержки)?
• Работа поступает в виде больших партий или единичных, но крупных заказов? Как насчет предсказуемых сезонных вариаций?
• Каковы ваши ключевые критерии успеха? Насколько они согласуются с клиентскими впечатлениями?

Те две команды, с которыми я когда-то работал, могли бы ответить на эти вопросы так:

1. «Какой-то регулярной картины прибытия работы нет. Более крупные проекты начинаются по согласованию с командой менеджеров. Более мелкие задачи появляются в результате частных бесед или поступления писем в почтовый ящик команды. Наша цель — разрешать каждую возникшую проблему, касающуюся поддержки продукта, за 24 часа (и нам это очень хорошо удается). Ожидания в отношении разработки очень разнятся в зависимости от масштабов проекта и нужд клиента».
2. «Новой работой управляют на региональном уровне, обычно через регулярные совещания, которые проводят региональные менеджеры или бизнес-аналитики высшего звена. Масштабная работа отслеживается с помощью двух дистанционных глобальных конференций, которые проводятся дважды в неделю (по одной для каждого из двух главных направлений нашего бизнеса). В них участвует и команда менеджеров, и наши бизнес-партнеры. График работы формируется согласно планируемым релизам. Иногда какая-то часть работы перетекает на следующий релиз, но этому всегда предшествуют предупреждения и обсуждения».

Складывается ли все это воедино?

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

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

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

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

Отправить