Синергичная команда
Ценность, создаваемая высокоэффективной командой, больше суммы индивидуальных вкладов ее игроков. → Синергия будет скорей достигнута, если все игроки команды хорошо понимают свою роль в ее создании и обладают прекрасными навыками взаимодействия... >>>
Уроки Джека Уэлча Создавай команду-звезду, а не команду звезд
Создавай разнородные кросс-функциональные команды
Облегчай «перекрестное опыление» идей
Расставайся с теми, кто не хочет играть в команде ... >>>
|
Н аше изобретение, помогающее создавать инновации эффективно Хочешь поставить себе эту компьютерную заставку? |
Зачем нужны кроссфункциональные команды?
Чтобы достойно принимать сложные вызовы новой эпохи, движимой знаниями, тебе необходимо создать широкий диапазон стилей работы, навыков и взглядов на вещи. Кроссфункциональные команды призваны решать здесь различные задачи, начиная с разработки общей концепции и кончая улучшением социальных аспектов совместной работы. Такие команды могут быть созданы, в частности, для решения таких задач как:
дизайн и разработка новых продуктов;
выбор и внедрение новых технологий во всей корпорации повсеместно;
совершенствование цепочки превращения услуг в прибыль;
сокращение себестоимости продукции.
Управление инновационными проектами
В случае инновационных проектов, фокусирующихся на эволюционное улучшение существующих продуктов или услуг, кроссфункциональная команда обычно включает в себя технического эксперта, инженера, дизайнера, производственника, специалиста по работе с поставщиками и специалиста в области маркетинга. Необходимо также не только держать основных поставщиков и покупателей в курсе твоих планов в области развития новых продуктов или услуг, но и вовлекать их в совместную разработку этих новых решений... >>>
Напомню, что кросс-функциональным называется процесс, в котором участвуют несколько подразделений верхнего уровня (по-английски «функций» — отсюда название). С точки зрения процессной методологии, именно на такие процессы в конечном счете должны нацеливаться инициативы BPM, поскольку именно здесь обычно кроются самые большие проблемы, а следовательно, наличествует самый большой потенциал улучшения. Ведь любая иерархическая организация, достигая определенного размера, сталкивается с тем, что собственные интересы подразделений начинают преобладать над интересами компании в целом.Собственно, это не новая идея: «сломать стены между подразделениями» — это призыв еще реинжиниринга образца начала 90-х. Другое дело, что предложенный классическим реинжинирингом подход к реализации через однократное радикальное преобразование оказался не вполне удачным. Современный BPM принес новые взгляды на то, как это надо делать, но цель осталась та же самая.
Для иллюстрации кросс-функциональных проблем часто используют метафору силосной башни —«functional silo». Аналогия тут следующая: после того, как крестьянин заложил скошенное сено в силосную башню, добраться он может только до небольшой части этого богатства — до верхнего слоя. Точно так же ресурсы, информация, знания, процедуры в иерархически организованной компании оказываются погребены в недрах функциональных подразделений — большая часть этого богатства недоступна для потребителей из других подразделений и не работает на достижения целей компании в целом.
Чисто функциональный взгляд на вещи влечет за собой искаженное представление о том, что для того или иного подразделения «свое», а что «чужое». Так, например, для бухгалтерии естественно считать, что основное ее занятие — это учет и отчетность. А выставление счетов за поставленный товар нужно кому-то другому, например, отделу продаж; для бухгалтерии это досадная помеха ее основной деятельности. Но с точки зрения бизнеса ведь все наоборот: выставление счета — это часть важнейшего с точки зрения ценности для клиента процесса «от заказа до оплаты», а учет и отчетность — это вспомогательная деятельность. Необходимая, так как ее требует государство и она нужна для планирования собственной деятельности. Но все же она не создает ценность, а следовательно, это затраты, которые по возможности следует минимизировать.
Бухгалтерия — это только один пример. Разработка новой продукции, подготовка коммерческого предложения, выполнение клиентского заказа «от и до» —- в компании есть множество вещей критически важных для клиента, а следовательно для бизнеса, но про которые нельзя сказать, что за них отвечает какая-то одна служба.
Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:
Рис. 1.
Однако картинка типа приведенной выше создает совершенно ложное представление о том, как следует решать проблемы, возникающие на стыках между подразделениями. Она порождает вульгарное представление о бизнес-процессе как о простой последовательности шагов: «делай раз — делай два — делай три». Но бизнес так не работает.
Рассмотрим в качестве примера — процесс «от заказа до оплаты»: приняли заказ — произвели — отгрузили — произвели расчеты. Попробуем смоделировать его для случая производства на заказ, буквально следуя картинке на рис. 1:
- Процесс начинается, когда отдел продаж получает заказ клиента.
- Получив и оформив заказ, отдел продаж передает его в производство.
- Производство приступает к выполнению заказа.
- Изготовленный товар доставляется заказчику.
- Финансовый отдел производит расчеты.
Рис. 2.
Кросс-функциональный процесс
«от заказа до оплаты», workflow-версия
Представьте себе: производственный цех стоит пустой, темный и безмолвный. Тут приходит заказ, мастер включает рубильник и все завертелось. Скажете, чушь? Конечно, чушь! Но наивная диаграмма, изображенная выше, предлагает именно такую картину деятельности предприятия.
Более правдоподобной выглядит следующая схема:
- Отдел продаж оформляет заказ клиента и размещает его в производстве.
- С определенной периодичностью (например, ежедневно) запускается производственное планирование, которое просматривает накопившиеся заказы и составляет производственный график.
- Выполнив очередной заказ в соответствии с составленным графиком, производство уведомляет процесс, связанный с клиентским заказом, о том, что товар готов к отгрузке.
В графическом виде:
Рис. 3.
Кросс-функциональный процесс
«от заказа до оплаты», BPM-версия
У нас появилось два процесса, взаимодействующих через данные (БД заказов) и сообщения (уведомление о выполнении заказа). Реализовать эту схему в рамках одного пула (одного процесса) принципиально невозможно, так как у процессов «клиентский заказ» и «производство» разные триггеры: поступление заказа от клиента и таймер, соответственно.
Та же история с доставкой и расчетами: их вряд ли удастся реализовать в рамках процесса «клиентский заказ». То есть технически процессов (пулов) тут не два, а больше.
Workflow, BPM и многопоточное программирование
Кросс-функциональные процессы невозможно реализовать при помощи workflow, потому что границы между подразделениями существуют не просто так: они разделяют области с разными распорядками работы и разными ритмами. Существование этих границ нельзя игнорировать, и их нельзя ликвидировать, просто изобразив поток работ, переходящий из одного подразделения в другое так, как изображено на рис. 2.
Технически эти задачи решаются при помощи процессных паттернов, один из которых изображен на рис. 3. А на уровне методологическом картинка, изображенная на рис. 1, может выглядеть так:
Рис. 4.
Workflow работает только в пределах одной функции. Как только мы выходим за ее пределы, т.е. как только беремся за кросс-функциональные процессы и начинаем разбираться со стыками между подразделениями, необходимо задействовать более изощренные механизмы взаимодействия между workflow.
Переходя от workflow к межпроцессному взаимодействию, мы переходим от однопоточного к многопоточному программированию.
К сожалению, для многих это становится непреодолимым барьером.
- Кто-то этот барьер не видит. Бьется об него, набивает шишки, но не понимает, с чем столкнулся. Кто-то барьер инстинктивно обходит: выполняет пилотный проект BPM с процессом типа «Оформление заявление на отпуск». Пилот получается успешный, только какое он имеет отношение к бизнесу?
Отсюда, как мне кажется, проистекает большая часть разочарований в BPM: те, кто сводят его к workflow, терпят прогнозируемое поражение.
Технически, многопоточность — это то, что отличает BPM от worflow. Уберите из BPM взаимодействие асинхронно исполняющихся процессов через данные, сообщения и сигналы, и это будет не BPM, а «workflow на стероидах».
К большому сожалению, это относится ко многим современным программным продуктам с агрессивным маркетингом, позиционирующим их как BPMS. Для меня главный критерий полноценной BPMS — это наличие в продукте поддержки сообщений в стиле BPMN. Есть и другие критерии, но этот на практике оказывается самым полезным, так как со всем остальным — графическим моделированием, workflow-движком, веб-порталом, бизнес-аналитикой — лучше или хуже справляются все разработчики, а с поддержкой межпроцессного взаимодействия — единицы. Скорее всего не потому, что это так уж сложно, а потому, что никто не объяснил насколько это важно.
Но сказать «осваивайте многопоточное программирование процессов» легче, чем последовать этому совету. В ответ раздается стон: «какой же сложный этот BPMN, и кто только придумал в нем 50 разных видов событий!».
Сложен не BPMN — сложен бизнес!
Кто бы вам не обещал простые средства решения бизнес-проблем, будь то BPM или что-то другое — не верьте! Бизнес — это конкурентная область человеческой деятельности: талантливые и изощренные люди соревнуются в ней за то, кому будет житься хорошо, а кому — не очень. Поэтому бизнес был, есть и останется делом сложным.
Сложность BPMN не чрезмерна — она адекватна сложности бизнеса. У слушателей моего тренинга по BPMN не остается вопроса зачем столько событий: все нужны! И кстати, обратите внимание: в части workflow BPMN 2.0 практически не отличается от 1.x — стандарт развивается в направлении более изощренной поддержки многопоточного программирования: choreography, conversation.
Если бизнес и можно запрограммировать, то только как многопоточную систему.
BPM и ACM
Тут я сознательно ступаю на скользкую почву, так как предвижу реакцию адептов ACM (Advanced/Adaptive Case Management): «Ага! Мы всегда говорили, что бизнес в принципе нельзя запрограммировать!»
Может быть можно, может быть нельзя… Скорее всего, в каких-то случаях можно, а в каких-то нет.
Вот говорят, что доля knowledge work постоянно растет. Но где именно она растет? В США, активно выводящих всю рутинную деятельность в Азию. Вот и сообщают нам сидящие в США аналитики о своих вполне прогнозируемых наблюдениях. Но ведь насколько выросла доля knowledge work в одном месте, ровно настолько же выросла доля routine work в другом. А управлять рутинными процедурами, исполняющимися на другом конце глобуса — это ведь самая подходящая для BPM задача.
В свете вышеизложенного я хотел бы поинтересоваться у критиков BPM из числа адептов ACM: вы уверены, что критикуете BPM, а не wokflow? Не являются ли объектом вашей критики BPM-проекты, в которых либо пытались решать задачи бизнеса, не выходя за рамки workflow, либо бизнес-проблематика вообще отсутствовала?
Потому что в этом случае их провал предсказуем, но он вовсе не означает, что BPM указывает неверный путь. Просто тщательнее надо работать.
Что касается ACM, то это безусловно вещь полезная, но только как дополнение к BPM, а не как замена. Плюс к этому, ACM на сегодняшний день вещь менее зрелая, чем BPM, и поэтому тот, кто наломал дров с BPM, с ACM скорее всего наломает дров еще больших.
- Анатолий Белайчук
, эксперт по BPM, президент компании
Я слышал очень много нареканий в сторону Agile подходов по поводу стремления к кроссфункциональности в командах . Обычно в критических материалах приводятся достаточно идиотические примеры. Вот парочка из них:
- “Ага! Давайте задействуем уборщицу! Она будет у нас заниматься базами данных по совместительству!”
- “Ну и как, скажите мне пожалуйста, тестировщик сможет заменить разработчика? Он же не умеет программировать!”
- “Ну-ну! Интересно что натворят junior разработчики в базе данных…”
Я расскажу о своем взгляде на эту проблему. Каждый из нас обладает определенным рядом навыков и опытом их применения. В зависимости от этих навыков мы можем делать различную работу с разным уровнем эффективности . Для меня кроссфункциональная команда характеризуется прежде всего возможностью членов команды делать некоторую часть работы вне своей основной зоны компетентности. Не факт, что эффективно. Не факт, что супер-качественно. Но может. Я даже не пытаюсь добиться полной замены других членов команды. Зачастую это просто невозможно . И я тоже не верю в то, что каждый тестировщик может писать код достаточного качества напрямую в production. 😉 Но любая работа состоит из частей . И не все части одинаково важны и требуют мега-навыков.
Приведу пару примеров. Работа тестировщика-автоматизатора может быть поделена на следующие части (грубое деление): продумывание сценариев, написание логики сценариев, сбор данных, реализация прослойки доступа тестов к тестируемому приложению. Все эти активности могут быть реализованы и другими членами команды, но каждая с разной эффективностью и качеством. В данном примере все, кроме продумывания сценариев, разработчик может сделать ничуть не хуже тестировщика (скажу “чуть хуже”, чтобы тестировщики не обиделись).
Работа HTML верстальщика также состоит из нескольких частей (снова грубое деление): верстка базовой версии HTML страницы, прикручивание основных стилей, хаки и правки под разные браузеры. И снова та же история. Только последняя активность требует критических навыков. Первые две активности достаточно адекватно может сделать и веб-разработик (в моем понимании не только может, но даже обязан уметь их делать).
Еще один мифический персонаж – DBA . У него вообще огромное число возможных активностей (и опять я груб): раздача прав на базы, создание схем, тюнинг запросов, модификация и миграция данных и т.д. Большая часть из них относятся к административной работе и может быть автоматизирована. Или выполнена разработчиком с последующим ревью DBA.
Но зачем все это нужно? Я вижу 3 цели у кроссфункциональности в моем понимании этого термина:
- Возможность балансировать нагрузку между членами команды, чтобы избежать простоев и затыков в работе
- Возможность частично заменить члена команды, который ушел в отпуск или банально заболел, и не останавливать процесс разработки
- Дать возможность членам команды сменять на некоторое время сферу деятельности , что стимулирует профессиональное развитие и делает работу разнообразнее
И напоследок еще один совет – кроссфункциональными нужно делать именно разработчиков , потому что они есть на любом проекте и без них разработка врядли сдвинется с мертвой точки. Все остальные специалисты в большей части случаев в меньшинстве и их работу нужно оптимизировать просто чтобы избежать затыков. Поэтому не надо решать задачу “научить тестировщика писать код” или “научить дизайнера тестировать”. Решайте задачу кроссфункциональности за счет разработчиков.
Исследователи еще не пришли к единой типологии команд. По мнению Д. Макинтош-Флетчер, существует два главных типа команд: кросс-функциональные и интактные команды.
Кросс-функциональная команда формируется из представителей различных подразделений формальной организации и отражает их интересы. Для команд этого типа характерно наличие конкретного, одноразового задания, обозначающего результат, проблему или возможность. Продолжительность существования команды определяется завершенностью задания. Для членов команды работа над заданием является вторичной по отношению к их основной работе. Руководитель команды может быть формально назначенным или выбранным из членов команды.
Интактная команда (интактный - нетронутый, неповрежденный, целый) является производственным подразделением или долговременно существующей рабочей группой, производящей определенный продукт или услугу. Она может иметь руководителя, который, не являясь членом команды, обеспечивает порядок и координацию работ, что позволяет членам команды фокусировать усилия на поставленных задачах. В других случаях команда может иметь руководителя, являющегося членом команды, который также проводит собрания и координирует взаимосвязи команды с другими группами. В некоторых случаях роль руководителя может выполняться и попеременно членами группы по мере развития их лидерских навыков или в зависимости от ситуации.
Достаточно развитые, зрелые, самоуправляемые, автономные интактные команды могут функционировать как небольшие предприятия. В таблице 1. представлена матрица типов команд.
Каждая команда устанавливает свои собственные цели. Цели создаются для выполнения заданий, стоящих перед командой, и для поддержания организационной миссии. Усилия команды и командные цели могут быть разбиты на три части:
- · определение рабочего процесса или решения, соответствующего организационному видению, или их совершенствование;
- · разработка рекомендаций по выполнению этих процессов, решений и усовершенствований;
- · выполнение этих рекомендации.
Команда может быть создана для любых целей. В некоторых случаях команды имеют взаимозависимые цели: одна команда выполняет свою часть работы только после того, как другая выполнит свою часть.
Ниже представлена типология, выделяющая четыре категории команд в зависимости от поставленных целей:
совещательная (совет, «круглый стол», группы, занимающиеся вовлечением работников в процесс управления);
производственная (производственные бригады, шахтерские команды, ремонтные бригады, команды летного состава, группы обработки данных);
Таблица 1. Типы команд
|
Тип команды |
Другие группы |
||
|
кросс-функциональные команды |
интактные команды |
комитеты, советы, комиссии и т. д. |
|
|
Членство |
Члены группы представляют естественную рабочую группу или подразделение |
Члены группы представляют более чем одно подразделение |
|
|
Продолжительность существования |
Продолжительность существования определяется завершенностью выполнения задания |
Постоянное существование |
Постоянное или определенное во времени |
|
Фокус на одной задаче |
Выполнение нескольких задач в определенных границах |
Координация или усовершенствование деятельности |
|
|
Измерение |
Достижение выполнения поставленной задачи или определенного рубежа |
Достижение поставленной организационной цели |
Выполнение работы в соответствии с уставом или правилами |
|
Группы решения проблем; Команды бизнес-совершенствования; Группы доставки товара |
Производственные подразделения; Рабочие группы |
Технические советы; Забастовочные комитеты; Координационные советы |
проектная (исследовательская группа, группа планирования, инженерная группа, целевая группа);
группа действий (спортивная команда, группа для развлечений, экспедиция, команда на переговорах, бригада хирургов, военное подразделение).
Дж. Катценбах и Д.Смит в соответствии с родом деятельности, которую выполняет в организации группа, выделяют следующие команды:
производственные команды;
управляющие команды.
Причем каждая из команд может находиться на одном из следующих уровней развития групповой активности в зависимости от командных усилий - эффективности взаимодействия членов группы:
рабочая группа;
псевдокоманда;
потенциальная команда;
реальная команда;
высокоэффективная команда.
Рабочая группа - это группа, у которой нет потребности в повышении эффективности совместного труда или нет возможности стать командой. Члены группы взаимодействуют между собой прежде всего для того, чтобы обменяться информацией, опытом работы или для определения перспективы и принятия решений, чтобы помочь каждому работать в пределах его области ответственности. В таких группах нет общей цели и взаимной ответственности. В отличие от команд рабочие группы полагаются на сумму «индивидуальных преимуществ», необходимых для выполнения работы. Они не ставят целью коллективное производство продукта, требующего объединенных усилий.
Выбирая путь команды, а не рабочей группы, люди берут на себя риски конфликта, объединяют усилия для производства изделий или услуг и используют коллективные действия, необходимые для определения общего направления, целей деятельности, подходов к работе и взаимную ответственность.
Псевдокоманда - это группа, у которой имеется потребность в повышении эффективности совместного труда, есть возможность стать командой, но она не сосредоточилось на коллективном выполнении работы и не пробует делать это. Члены группы не проявляют интереса к определению и формулированию общей направленности и целей деятельности, хотя при этом группа может называть себя командой. Псевдокоманды имеют самые низкие показатели результатов деятельности, потому что используемые ими методы работы уменьшают индивидуальную производительность каждого члена и не дают эффекта от объединения. В псевдокомандах негативная синергия - сумма целого меньше, чем потенциал индивидуальных частей.
Потенциальная команда - это группа, у которой имеется существенная потребность в повышении эффективности совместного труда, и она пробует это делать. Однако, как правило, такой команде не хватает ясности относительно направления, целей и процесса выполнения работы. Эта группа еще не установила коллективную ответственность, и ей требуется более высокий уровень дисциплины. Такие команды называются потенциальными, так как их члены берут на себя риски, пытаясь противостоять неизбежно возникающим препятствиям.
Реальная команда - это небольшое число людей с взаимодополняющими навыками, которые преданы общему направлению, целям и рабочему подходу, за который они чувствуют себя взаимно ответственными. Люди полностью определили процедуру и процесс совместной деятельности для достижений согласованных целей. Они осознают, что каждый из них важен для эффективного выполнения работы, но они еще не полностью реализовали сами себя.
Высокоэффективная команда - это реальная команда, члены которой обладают суперобязательностью относительно выполнения командной работы. Методы работы и взаимодействия в группе способствуют персональному росту и успеху членов команды. Такие группы обладают избытком синергии и добиваются результата, который превосходит ожидания окружающих.
ВКонтакте Facebook Одноклассники
В течение последнего десятилетия такие важные для бизнеса слова, как «команда», «командообразование», «умение работать в команде»,
В течение последнего десятилетия такие важные для бизнеса слова, как «команда», «командообразование», «умение работать в команде», использовались так часто, что их смысл и значение «замылились», потеряли фокус, превратились в часто употребляемое, но уже не несущее глубокого смысла слово.
Тем не менее, именно в работе в команде рождаются нетипичные идеи, возникает синергия, умножается конечный результат. Все более популярным и чаще используемым становится инструмент «кросс-функциональные команды». Чаще всего кросс-функциональные команды используются организациями для своего развития, для решения задач, связанных с совершенствованием бизнеса и внутренних практик, для совершенствования процессов и т.п.
Что же такое «кросс-функциональные команды»? Это команды, которые собираются для решения какой-то задачи, важной для бизнеса, т.е. для работы по определенному проекту (обычно внутреннему) в течение определенного периода. В такую проектную команду входят люди из различных подразделений компании, которые в той или иной степени имеют отношение к решению стоящей проектной задачи: например, финансового отдела, HR-отдела, НИОКРа, ИТ-отдела, отдела продаж и т.д. Наличие в проектной команде специалистов с различным опытом и знаниями позволяет максимально полно и подробно рассмотреть и проанализировать задачу, ее потенциальные выгоды и риски, а также выбрать оптимальный вариант решения. Например, для принятия решения о выборе и внедрении системы CRM в компании необходимо учесть мнение ИТ-департамента, отдела продаж, финансовой службы, маркетингового отдела, специалистов, которые создают сам продукт или услугу. В случае отсутствия такой разнообразной экспертизы (т.е рассмотрения вопроса специалистами одного-двух подразделений) увеличивается риск однобокого решения задачи или даже вероятность принятия не совсем честного решения, отвечающего интересам данного подразделения или руководителя и не совпадающего с интересами бизнеса в целом.
Кросс-функциональные команды могут собираться:
На короткий период, для решения вполне конкретного вопроса; на длительный период, для решения стратегической задачи - например, вывод бизнеса из кризисной ситуации. В этом случае они фактически приобретают статус временного управляющего органа.
Возможность использования различных взглядов является одновременно и риском для работы кросс-функциональной команды: иногда бывает сложно структурировать фонтан идей и выбрать из него 1-2 главных решения. Соответственно - здесь критична роль руководителя команды и его умение направлять работу команды в нужное русло и сохранением максимальной эффективности.
В случае, если члены проектной команды не находятся на одной территории, то необходимо подобрать необходимый инструмент коммуникаций, протестировать его перед началом использования, учесть разницу во времени, расписание каждого из участников, а также обеспечить запись встречи и сохранение копии материалов.
Как всегда в проектной работе, необходимо с самого начала четко определить цели и задачи команды, этапы работы, сроки окончания каждого этапа, промежуточные результаты и ожидаемый результат. По классике жанра эти промежуточные и конечный результаты должны быть измеримыми, иначе команда никогда не поймет, выполнила она стоящую перед ней задачу или нет.
И, конечно, каждый член такой команды должен с самого начала знать, какая у него роль и что от него ожидается.
Для лидера команды такой опыт управления непрост, однако очень полезен, поскольку именно кросс-функциональные команды чаще всего добиваются уникальных результатов, вносят необычные предложения, дают возможность организации сделать «прорыв». И это то, что для всех сторон: организации, руководителя команды и каждого из ее членов является бесценным опытом.
Иллюстрация из жизни:
В начале 2000-х одна крупная фармацевтическая компания обратилась к консультантам с просьбой помочь «отладить» систему управления и повысить эффективность работы управленческой команды.
Управление в тот момент осуществлялось в большей степени непосредственно Генеральным директором, которому приходилось вникать практически в каждый аспект работы компании, несколько раз перепроверять выполнение своих указаний, и самым действенным инструментом оказывались штрафы, повышенный тон, без которого задание подчиненными не воспринимались, и прочие аналоги.
Генеральный директор регулярно собирал всех ключевых управленцев компании для обсуждения ситуации, повестка таких заседаний обычно рассылалась участникам заранее. Каждый управленец готовил отчет по своему направлению в контексте обсуждаемого вопроса. В итоге часто оказывалось, что при обсуждении трудностей или невыполнения какого-либо задания на совещании руководители направлений, отчитавшись за себя, перекладывали вину за неудачу на другие подразделения и ссорились. Вопросы часто оставались нерешенными, руководители жили с постоянной обидой друг на друга. Нужно отметить, что практически каждый руководитель направления как отдельно взятая единица были очень профессиональными, компетентными в своих вопросах и очень болели за общее дело - процветание бизнеса.
Приглашенные консультанты, разобравшись в ситуации, предложили использовать работу кросс-функциональных команд. Для начала были выделены 3 ключевые для организации задачи на ближайший год. Эти задачи были трансформированы в задачи для каждого подразделения, которое должно было принимать участие в их решении. Под каждую задачу совместно с Генеральным директором сформировались проектные команды, а в каждой команде назначен руководитель проектной группы. Для всех участников было проведено необходимое обучение, а затем консультанты в качестве фасилитаторов приняли участие в первых встречах проектных команд.
Прошло некоторое время, и стиль работы управленцев изменился на 180 градусов: люди научились работать командами. Теперь, получив приглашение на совещание, они самостоятельно собирались вместе, обсуждали ситуацию, возникшие трудности, сами предлагали меры, которые были бы полезны другому подразделению для того, чтобы общий результат был положительным. Они стали сотрудничать и помогать друг другу, хорошо поняли роль и значение каждого из подразделений в общем процессе. Работа в кросс-функциональных командах научила их работать как единый механизм. И это не замедлило сказаться на результате работы компании.