Куперс

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

Определение бизнес-процесса

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

Бизнес-процесс – это сквозной и кросс-функциональный процесс, дающий ценный с точки зрения заказчика результат.

End-to-end Process — это процесс, рассматриваемый от начала до конца, т.е. до достижения ценного для заказчика результата.

Кросс-функциональный процесс — это процесс, не ограниченный функциональными рамками, т.е. пересекающий границы функциональных подразделений.

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

Определение процессного подхода

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

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

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

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

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

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

В качестве вывода:

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

Я слышал очень много нареканий в сторону Agile подходов по поводу стремления к кроссфункциональности в командах. Обычно в критических материалах приводятся достаточно идиотические примеры. Вот парочка из них:

• “Ага! Давайте задействуем уборщицу! Она будет у нас заниматься базами данных по совместительству!”
• “Ну и как, скажите мне пожалуйста, тестировщик сможет заменить разработчика? Он же не умеет программировать!”
• “Ну-ну! Интересно что натворят junior разработчики в базе данных…”

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

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

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

Еще один мифический персонаж – DBA. У него вообще огромное число возможных активностей (и опять я груб): раздача прав на базы, создание схем, тюнинг запросов, модификация и миграция данных и т.д. Большая часть из них относятся к административной работе и может быть автоматизирована. Или выполнена разработчиком с последующим ревью DBA.

Но зачем все это нужно? Я вижу 3 цели у кроссфункциональности в моем понимании этого термина:

• Возможность балансировать нагрузку между членами команды, чтобы избежать простоев и затыков в работе
• Возможность частично заменить члена команды, который ушел в отпуск или банально заболел, и не останавливать процесс разработки
• Дать возможность членам команды сменять на некоторое время сферу деятельности, что стимулирует профессиональное развитие и делает работу разнообразнее

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

Как сформировать кросс-функциональную команду

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

Что необходимо знать

Я новичок в менеджменте проектов и мне необходимо сформировать кросс-функциональную команду. С чего мне начать и как найти подходящих людей?
Начните с того, какие задачи ставит перед собой проект и каких навыков требует их выполнение. Затем присмотритесь к сотрудникам и определите, кто из них обладает необходимыми знаниями и энтузиазмом. В то же время необходимо определить, требует ли проект привлечения сотрудников извне. После этого надо нанять людей, которые вам подходят, — для этого может понадобится разного рода одобрение вашего и их начальства. Очевидно, что список кандидатов может сильно разниться в зависимости от характера проекта и объемов необходимой работы.
Если, например, вам необходимо совершить переезд в более подходящее для проекта рабочее помещение, то вам скорее всего понадобятся планировщики, упаковщики, грузчики, электрики, специалисты по установке оборудования, специалисты по телекоммуникациям и т.п. Вероятно, вашим новым сотрудникам нужно будет переехать из разных подразделений компании, потому что вы выбрали именно тех, у кого есть необходимые знания и навыки и тех, кто готов хорошо выкладываться.
Вполне вероятно, что человек, заинтересованный в выполнении проекта — то есть тот, кто назначил вас руководителем, — будет вашим союзником и поможет вам выбрать необходимых людей и нанять их.
Как соблюсти правильные пропорции личностных качеств и знаний в команде проекта?
Это правильный ход мыслей! Взаимодействие разных по характеру личностей во время работы может внести разлад в общее дело, или даже совсем застопорить его. В конечном счете может оказаться, что то, как члены команды взаимодействуют между собой, было гораздо важнеей тех знаний, которыми они обладали.
Так какие же типы личностей должны быть присущи членам новой команды?
Начнем с десятка стандартных командных ролей, выделенных доктором Мередитом Белбином, выдающимся британским автором книг о бизнесе, преподавателем и консультантом. Эта классификация появилась благодаря его исследованию, проведенному в конце 1960-х годов. Классификация прошла проверку временем и по сей день актуальна по обе стороны Атлантики.

1. Координатор: Пытается извлечь максимальную пользу из работы каждого члена команды, определяет потребности, формирует команду, определяет цели, следит за выполнением, обеспечивает стабильность структуры и отвечает за постановку задачи.
2. Испытатель: Раскачивает лодку — применяет необщепринятые подходы, подвергает сомнению распоряжения, может быть источником инновационных идей.
3. Эксперт: Предоставляет консультации специалиста и объективную оценку (например в ИТ или расчетах).
4. Посол: Легко устанавливает контакты, развивает внешние связи, разбирается во внешней среде, рекламирует команду.
5. Судья: Приземлен, логичен и аккуратен — выслушивает, оценивает, взвешивает все «за» и «против», избегает споров, добивается истины, поощряет команду в поисках лучшего решения.
6. Инноватор: Является источником нового видения, находчивости и творчества — пользуется воображением, мотивирует других, развивает идеи, работает с задачами. Требующими комплексного подхода.
7. Согласователь: Умеет помогать, надежен, легко сотрудничает — заполняет пробелы, мастер на все руки, не подвергает сомнению решения руководства.
8. Исполнитель: Мыслит прогрессивно, мотивирован, сосредоточен на задачах и результатах, следит за временем и прогрессом, нетолерантен к другим.
9. Посредник: Сосредоточен на отношениях в команде, следит за боевым духом, решает конфликты, дает советы, поддерживает и поощряет других членов команды.
10. Контролер: Проверяет, хорошо ли выполнена задача, следит за результатами работы, требует соблюдения высоких стандартов и сосредоточен на качестве в целом.
11. Ревизионист: Следит за производительностью, требует обратной связи, ищет подвоха.

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

Что делать дальше

Ознакомьтесь со стадиями формирования команды

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

1. Формирование. Все очень увлечены, все ново и интересно, никто еще не знает, что должен делать, но и не переживает из-за этого.
2. Волнение. Роли распределены, личности начинают проявлять себя, люди уже не так открыты друг с дугом, они переживают из-за чужих способностей, и это провоцирует конфликты, которые могут выйти на поверхность, если не пресечь их на скрытой стадии.
3. Устаканивание. Взаимное доверие и уверенность возвращаются, отношения укрепляются, чужое мнение вызывает уважение, все вопросы решаются легко. Цели не кажутся недостижимыми, и все стараются слаженно работать, чтоб их достичь.
4. Исполнение. Команда становится гибкой, все по очереди перенимают лидерство, полномочия делегируются, так что члены команды растут в профессиональном плане, текущие цели доcтигаются и прогресс очень ощутим.

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

• Свободное распространение информации. Убедитесь, что каждый из членов команды располагает всей информацией, необходимой для текущей работы.
• Открытое общение. Не держите секретов и не позволяйте команде чувствовать, что кто-то из ее членов скрывает что-то, чего не скрывают другие.
• Налаженная обратная связь. Люди должны знать, насколько хорошо они себя показали и как их оценивают, а также что им стоит исправить или улучшить.
• Частое общение один на один. Говорите с членами команды, как с равными, и не жалейте времени на то, чтоб убедиться, что они всем довольны и чувствуют себя полезными.
• Культура слушанья. Убедитесь в том, что люди свободно могут высказаться о том что думают и что чувствуют, и что они будут услышаны, даже если их мнение в меньшинстве.

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

• Признание
• Достижения
• Ответственность
• Хорошие отношения с коллегами
• Вознаграждение
• Хорошие отношения с руководителем проекта
• Лидерство
• Работа сама по себе
• Продвижение
• Личностный рост

Демотиваторы:

• Отношения с руководителем проекта
• Отношения с сотрудниками
• Вознаграждение
• Лидерство
• Безопасность
• Условия труда
• Политика компании
• Субординация внутри команды
• Личное время
• Звание / статус

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

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

Секрет успешного делегирования в том, чтоб почувствовать себя в шкуре членов команды. Скажем, вы опытный и ответственный профессионал, вы хорошо разбираетесь в своей работе и любите ее, но над вами стоит менеджер проекта, который постоянно заглядывает вам через плечо, готовый заранее раскритиковать каждый следующий ваш шаг! Или, к примеру, вы совсем новичок, неуверенный в себе, своих способностях и обязанностях, а над вами стоит руководитель, который умывает руки и ждет, выплывете вы сами, или утонете. Как бы вы вели себя в каждой из ситуаций?
Делегирование требует правильного баланса между контролем и независимостью
Потому, помимо советов по делегированию, запомните еще и правила контроля за выполнением.
Обычно, интенсивность контроля зависит от опыта и мотивации:

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

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

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

Чего стоит избегать

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

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

Узкая специализация профессионалов — прошлое. Чем шире кругозор специалиста, чем шире его опыт и знания, тем больше он эффективен в организации будущего.

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

Василий Алешин, Project Manager ГК «Новосибхолод», CEO LeanContora.ru:

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

Кросс-функциональные сотрудники — это как Хабиб Нурмагомедов и Конор МакГрегор: оба в базе отличные борцы, но стоило им добрать ударной техники и уйти в смешанные единоборства, насколько они выросли? Каких успехов добились? Так же и в работе. Ты можешь быть чемпионом в своей сфере, но добрав кросс-функциональных знаний и компетенций, ты станешь на голову выше (в первую очередь выше самого себя), и твои победы будут ярче!

Я считаю, что кросс-функциональные компетенции нужны во всех сферах деятельности. Но развивать можно только тех сотрудников, которые хотят развиваться. Поэтому ключевая и первостепенная задача HR-ов в компании — работать в первую очередь не с компетенциями, а с «изменением мышления» сотрудников».

Жанна Косолапова, эксперт-практик, преподаватель HR МВА:

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

Одна из компетенций, которая будет выходить на первое место, — это взаимодействие и сотрудничество с другими специалистами. Нужно наращивать экспертизу в смежных областях, быть обучаемым и открытым новому. Также важно понимать и осознавать себя, уметь управлять собой и развивать эмоциональный интеллект».

Лада Горченок, директор по управлению персоналом макрорегиона Сибирь компании Теле 2:

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

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

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

Главное не результат, главное процесс

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

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

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

Чисто функциональный взгляд на вещи влечет за собой искаженное представление о том, что для того или иного подразделения «свое», а что «чужое». Так, например, для бухгалтерии естественно считать, что основное ее занятие – это учет и отчетность. А выставление счетов за поставленный товар нужно кому-то другому, например, отделу продаж; для бухгалтерии это досадная помеха ее основной деятельности. Но с точки зрения бизнеса ведь все наоборот: выставление счета – это часть важнейшего с точки зрения ценности для клиента процесса «от заказа до оплаты», а учет и отчетность – это вспомогательная деятельность. Необходимая, так как ее требует государство и она нужна для планирования собственной деятельности. Но все же она не создает ценность, а следовательно, это затраты, которые по возможности следует минимизировать.

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

Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:

Рис. 1. Функции и кросс-функциональные процессы.

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

Рассмотрим в качестве примера – процесс «от заказа до оплаты»: приняли заказ – произвели – отгрузили – произвели расчеты. Попробуем смоделировать его для случая производства на заказ, буквально следуя картинке на рис. 1:

1. Процесс начинается, когда отдел продаж получает заказ клиента.
2. Получив и оформив заказ, отдел продаж передает его в производство.
3. Производство приступает к выполнению заказа.
4. Изготовленный товар доставляется заказчику.
5. Финансовый отдел производит расчеты.

Рис. 2. Кросс-функциональный процесс «от заказа до оплаты», workflow-версия.

Представьте себе: производственный цех стоит пустой, темный и безмолвный. Тут приходит заказ, мастер включает рубильник и все завертелось. Скажете, чушь? Конечно, чушь! Но наивная диаграмма, изображенная выше, предлагает именно такую картину деятельности предприятия.

Более правдоподобной выглядит следующая схема:

1. Отдел продаж оформляет заказ клиента и размещает его в производстве.
2. С определенной периодичностью (например, ежедневно) запускается производственное планирование, которое просматривает накопившиеся заказы и составляет производственный график.
3. Выполнив очередной заказ в соответствии с составленным графиком, производство уведомляет процесс, связанный с клиентским заказом, о том, что товар готов к отгрузке.

В графическом виде:

Рис. 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 скорее всего наломает дров еще больших.

Продолжение следует

В нем я планирую рассмотреть основные паттерны межпроцессного взаимодействияю, а также предостеречь от противоположной крайности – чрезмерного увлечения межпроцессным взаимодействием. Оставайтесь на связи.

• Часть 2: Кросс-функциональные паттерны
• Часть 3: Оптимизация кросс-функциональных процессов