Максим Цепков - Менеджмент цифрового мира

Гибридная схема частичной перестройки.

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

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

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

Проектируем Agile-трансформацию компании

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

На что опираться в таком решении? Как раз на анализ ситуации компании и ее окружение на рынке и сложность деятельности. При этом надо помнить, что мы работаем с запутанной (по Кеневин, смотри предыдущую главу) социальной системой, поэтому тот образ перестройки компании, который мы получим в результате анализа является не более, чем гипотезой, подлежащей экспериментальной проверке. Гарантированного результата тут получить невозможно. Именно поэтому Kanban вообще предлагает начать стартовать с существующей организации компании, сделать прозрачным поток создания ценности и запустить эволюционный процесс перестройки. Правда, есть опасность, что этот эволюционный процесс увязнет в привычной рутине, и поэтому данный путь сложнее, чем революционная реорганизация.

В любом случае, бывают ситуации, когда переход к кросс-функциональным командам для определенных участков компании является достаточно очевидным решением, исходя из анализа деятельности или просто с учетом сопротивления преобразованиям. В этом случае надо организовать будущие команды. При этом опыт IT однозначно говорит, что их недостаточно организовать логически, просто собрав людей и объявив, что они теперь будут работать одной командой, как иногда делают при организации проектных групп. Надо провести физическую реорганизацию, объединив людей одной команды в единое физическое пространство. Разумеется, сейчас есть техники работы распределенных команд, но, во-первых, они сложнее, а, во-вторых, сохранение привычного окружения надежно останавливает любые новшества. Фраза Питера Друкера, «культура ест стратегию на завтрак» к этой ситуации тоже вполне применима. Должен ли сотрудник работать только в одной команде? Ответ из опыта IT – это крайне желательно. У любой команды должно быть ядро сотрудников, у которых команда является единственным местом работы. Может быть некоторое количество специалистов, занятых частично, и участвующих в 1—2 командах. Но не больше, во всяком случае, сотрудник, разрывающийся между 5—10 проектами – пример вопиющей неэффективности, потому что, как правило, он не помнит ни об одном. Разумеется, бывают исключения, и я сам знаю таких людей, но это – крайне редкие случаи, а обычно такие ситуации возникают потому, что руководители не знают, кем бы сейчас заткнуть дыру в деятельности, и нагружают сотрудников, которые в результате ни с чем не справляются, выгорают и уходят. И в большинстве случаев это все равно иллюзия решения проблемы.

Инфраструктура компании.

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

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

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