Что такое кросс функциональный проект
Что такое кросс функциональный проект
[Сейчас будет штамп, но по-другому тут и не скажешь, ведь]
Наверняка, каждый из вас сталкивался с проблемой сложности выстраивания коммуникаций с другими командами. У этих «других» ведь все как-то иначе: у «этих» задачи разработчики вместо аналитиков заводят, «вот эти» по спринтам живут, а «вон те» вообще говорят, что до II квартала 21-ого года задачи не принимают…
И ты такой стоишь посреди всего этого великолепия и не знаешь, с чего начать, чтобы все же сделать задачу? Надеюсь, эта статья поможет тебе.
Хочу рассказать о том, как мы все можем сделать работу над кросс-проектами в нашем IT более предсказуемой, понятной и более эффективной. Работая над проектом по запуску постаматов, наша команда накопила кое-какой опыт. В этой статье постараюсь донести все полезные наработки, которые может использовать каждый сотрудник IT подразделения.
Сначала давайте обговорим, что же такое кросс-функциональные проекты и какой проект можно к ним отнести, а какой нет. За общий случай мы берем:
Кросс-функциональные проекты – проекты или крупные фичи, в которых задействовано 2 и более функциональных модуля от разных команд
Почему именно разные функциональные модули и разные команды? Все просто: в рамках одного модуля у нас постоянно происходит взаимодействие между разными командами. Например, между бэком и фронтом. Это уже настолько обыденная ситуация, что было бы странно объявлять это кросс-проектом и как-то по-особому с ним работать. Тоже самое касается и «разных команд»: если одна и та же команда работает над двумя модулями, то у нее тоже вряд ли возникнут проблемы в реализации, особенно, если писать код или аналитику будет один и тот же разработчик или аналитик. Но если команды разные и модули разные – тут уже вполне могут начаться проблемы…
При работе с постаматам мне и моей команде очень повезло: очень четко были определены цели проекта, обозначены сроки и выделены ресурсы. Более того, объем ресурсов даже позволял, в теории, уложиться в обозначенные сроки! Но встал большой вопрос – как всем этим хозяйством распоряжаться?
Быстро выяснилось, что так или иначе задействованы будут практически все модули ЭК5 и интеграции. Одних только аналитиков было задействовано 19 человек! При этом изначально вся наша команда: я в качестве PM и Мария Колесникова как главный аналитик проекта.
1. Убедись, что понимаешь, что и зачем тебе нужно сделать. Если нет – самое время спросить у главного по твоему направлению.
2. Если нет главного – стоит спросить об этом своего менеджера. И о том, что непонятно и о том, почему нет главного по направлению. Менеджер не любит вопросов (фи-и-ить, щютка), так что он, наверняка, быстро организует назначение «точки входа».
3. Убедись, что ты и твои коллеги составили план работ – понятный всем и выполнимый (хотя бы на ближайшую перспективу). Если нет – подними этот вопрос сам в общем чате или же снова напомни о себе менеджеру (надеюсь, меня не побьют и не отравят).
4. Если что-то меняется в проекте – не забудь предупредить об этом коллег по проекту. Может быть, это даже не у тебя меняется, а ты где-то на митинге услышал об этом: если считаешь, что это может что-то задеть в проекте – лучше «перебдеть» и лишний раз переспросить.
5. Верь в своих коллег! Даже если у них срываются сроки и они тебя подводят – скорее всего, они это не специально и расстроены не меньше твоего (если это не так – да осквернят шакалы прах их предков). Лучше спроси их, чем можешь помочь и поддержать.
6. Если твои задачи систематически «задвигаются» коллегами – тут уже не стоит это терпеть. Время ставить вопрос о том, что «без моей левой гусеницы танк тоже не поедет!»
Сейчас мы работаем над трансформацией вышеописанного в простой и понятный регламент работы по кросс-функциональным проектам. А вообще, самый лучший регламент – это ответственное отношение к своему делу и окружающим.
Agile
Кросс-функциональные команды и самоорганизация в основе Agile. Part 2.
В первой статье из цикла “Кросс-функциональные команды и самоорганизация в основе Agile” мы рассмотрели само понятие и явление Agile культуры, обсудили имеющиеся стереотипы и заблуждения, сформировавшиеся вокруг данного термина, а также рассмотрели принципы, лежащие в основе Agile.
Основная цель данной статьи — разобраться с явлением “кросс-функциональных команд”, понять в чем же именно заключается особенность данного подхода и что делает его столь популярным и эффективным.
Кросс-функциональные команды
Обращаясь к понятию кросс-функциональных команд мы часто сталкиваемся с большим количеством разночтений и отсутствием четкой определенности “кросс-функциональности”.
Термин “кросс-функциональная команда” берет корни из фреймворка Scrum. В то же время, опыт множества проектов показывает, что такой подход к формированию команд является оптимальным как с точки зрения скорости внедрения изменений, так и в плане оптимизации процесса разработки и снижения издержек — ключевых принципов подходов Kanban и Lean. Это позволяет применить данную концепцию и в рамках других Agile фреймворков.
В поисках определения данного термина, логичным будет обратиться к Scrum Guide (здесь и далее приводятся цитаты из официальной русскоязычной версии Scrum Guide):
Scrum‐команды являются самоорганизующимися и кросс-функциональными… Компетенций кросс-функциональной команды достаточно для выполнения полного объема работ. Под последним следует понимать весь комплекс работ в сочетании с оптимальным способом ее исполнения, необходимым для реализации бизнес‐ценности.
Прежде всего стоит обозначить, что сама сущность кросс-функциональной команды подразумевает активное участие в ней не только технических специалистов (Back-end, Front-end разработчиков и QA специалистов). Такая команда может и по возможности должна включать в себя бизнес-аналитиков, маркетологов, UX-дизайнеров и других специалистов, принимающих активное участие в проекте. Все это делается для достижения следующего немаловажного пункта из Scrum Guide:
Модель команды в Scrum предполагает минимизацию внешних зависимостей, располагая к гибкости, творчеству и продуктивности.
Роли в рамках кросс-функциональной команды
Какие же роли есть в кросс-функциональной команде? Раз уж мы начали рассмотрение данной концепции на примере Scrum, предлагаю продолжить и взять за пример состав стандартной Scrum Команды:
При этом в рамках Команды Разработки отсутствует формальное деление по “зонам ответственности” и грейдам — все являются равноценными членами команды и несут равную степень ответственности как за успехи, так и за провалы.
В некоторых командах это приводит, например, к отсутствию выделенного QA специалиста, ведь итоговое качество продукта и его соответствие ожиданиям бизнеса является ответственностью и критерием качественной работы всей команды, а не отдельно взятого специалиста. В связи с этим, широкое распространение получили такие технические практики как Test-Driven Development и Pair Programming, являющиеся частью фреймворка Extreme Programming(XP). Возможность применения практик из различных фреймворков, дополняющих базис основного — одно из главных свойств и преимуществ Agile.
Кросс-функциональный подход к формированию команды может применяться и в рамках любого другого фреймворка. Главное ограничение — размер команды. При этом оно не носит формального характера. Вы не обязаны укладываться в рекомендованный Scrum Guide размер “3–9 человек”, но всегда стоит помнить про формулу, предлагаемую нам Project Management Body of Knowledge (PMBOK):
Общее количество каналов коммуникации равно n(n-1)/2, где n — количество участников проекта.
Таким образом, для команды из 10 участников, число потенциальных каналов коммуникации будет равно 45, для 9 человек — 36, и так далее. В справедливости данной формулы не трудно убедиться. Возьмите стандартный набор инструментов коммуникации внутри команды:
Прибавьте к этому такие варианты как CRM-система, использование разных мессенджеров для общения внутри команды и с Заказчиком, телефон и любые другие варианты, которые есть в Вашей компании, и цифра стремительно пойдет вверх.
На мой взгляд, оптимальный размер команды равен 5+/-2 человека.Стоит учитывать, что в рамках Scrum роли Scrum Master’а и Product Owner’а вынесены за пределы команды разработки и не учитываются при определении размера команды.
Преимущества кросс-функционального подхода
Каковые же преимущества кросс-функциональных команд над классическими?
Чтобы ответить на этот вопрос, давайте вернемся к нашему списку принципов, лежащих в основе Agile культуры, который мы озвучили в первой статье цикла. Грамотное применение данного подхода позволяет реализовать сразу половину из них:
Собираем кросс-функциональную “команду мечты”
Конечно я не смогу дать Вам универсальный рецепт состава команды на все случаи жизни. Вместо этого я предлагаю кое-что получше — перечень инструментов и факторов, которые стоит подготовить и/или принять во внимание при формировании кросс-функциональной команды для Вашего продукта или проекта.
Следующие факторы должны помочь убедиться что все, кто нужен для работы над проектом, на борту:
Надеюсь в данной статье Вы смогли найти для себя весомые доводы в пользу кросс-функционального подхода к формированию команд или ответы на вопросы о данном подходе.
В следующей статье из цикла мы рассмотрим принцип, лежащий в основе работы кросс-функциональных команд — самоорганизацию.
Зачем HR-специалисту становиться «расческой», или Кросс-функциональность как конкурентное преимущество
Что такое кросс-функциональность и чем она хороша
В интернете можно встретить термин «люди-расчески» — это про тех специалистов, которые оттачивают знания сразу в нескольких сферах. Признаюсь, что такое название мне не близко, однако в своей работе я замечаю стойкий спрос на кросс-функциональных специалистов. Это может быть юрист, обладающий знаниями в области психологии конфликтов, логист, разбирающийся в экономике или sales-менеджер с экспертизой в аналитике.
Вы слышали разговоры о том, что через какое-то время специалистов заменят роботы? Так вот, не заменят, или, вернее, заменят не всех. Машине можно передать рутинные процессы, но творческая деятельность, генерация новых идей и умение в сложной ситуации найти необычное решение останется за человеком.
Кросс-функциональный специалист, работающий на стыке двух или более сфер, — это как раз такой незаменимый «винтик». Он ведет свою карьеру по пути, по которому до него либо вообще никто не шел, либо шло очень ограниченное количество людей. Он постоянно сталкивается с новыми вызовами и обладает принципиально новым, уникальным опытом.
Например, специалист по маркетингу, в обязанности которого входит подготовка новостей, пресс-релизов и контента для рассылки по клиентской базе, начинает заниматься программированием и версткой сайта компании. В какой-то момент он становится уникальным профи на стыке маркетинга и ИТ.
Развитие в новой сфере может стать хорошим вариантом для человека, который достиг карьерного потолка или столкнулся с эмоциональным выгоранием. В этом случае подумайте, в каких близких отраслях или даже соседних отделах можно применить ваши знания? Универсальный пример: вместо того чтобы увольняться, секретарь может продолжить развитие в рамках своей компании на позиции младшего маркетолога или аналитика.
Зачем кросс-функциональность HR-менеджеру
Сфера HR остро нуждается в кросс-функциональных менеджерах. Успешные HR-специалисты постигают основы маркетинга и учатся грамотно применять самые разные маркетинговые инструменты — от «воронок» до исследований и таргетинга, чтобы сделать поиск специалистов эффективнее и быстрее. Марчар, или HR-маркетолог, — это уже не столько новый тренд, сколько новая реальность, объявления о поиске таких специалистов постоянно появляются на hh.ru.
Растет спрос на HR-специалистов с опытом и экспертизой в ИТ-сфере. Знание основ программирования дает новые инструменты для оптимизации поиска и найма, рынок диджитал-инструментов для управления персоналом растет, и для того, чтобы ориентироваться в них и грамотно использовать, нужны навыки работы с высокими технологиями и глубинное понимание диджитал-процессов.
Чтобы выигрывать в борьбе за таланты, компании серьезно работают над своим работодательским брендом. Представьте, какую пользу делу может принести HR-специалист, который знает современные тренды, умеет анализировать целевую аудиторию, проводить исследования, «упаковывать» и доносить уникальное предложение работодателя до потенциальных сотрудников самым эффективным способом. Такой человек, сочетающий функции HR-специалиста, социолога, маркетолога и порой SMM-специалиста, на рынке труда обладает мощным конкурентным преимуществом.
Как стать кросс-функциональным
В первую очередь — задуматься над тем, чем вам действительно нравится заниматься. Решение стать кросс-функциональным специалистом — отличная возможность чуть больше полюбить свою работу, добавив в нее той деятельности, которая приносит вам удовольствие.
Может, вы увлекаетесь словесностью, много читаете и друзья часто говорят, что вы хорошо пишете? Или следите за трендами в социальных сетях и смотрите вебинары для эсэмэмщиков? А может, у вас есть чувство вкуса и вам интересен дизайн сайтов? Все эти навыки можно отточить и развить с пользой для карьеры и для компании.
Не обязательно и даже не нужно сразу идти на второе высшее. Присмотритесь к краткосрочным курсам, интенсивам, мастер-классам от профи.
Не гонитесь за модой и не уходите в какую-то сферу просто потому, что «все так делают». Повальное увлечение языком программирования Python привело к тому, что рынок стал перенасыщен «питонистами», тогда как хорошие программисты на более сложном языке JAVA по-прежнему в дефиците.
Следуйте за своим интересом, учитесь, пробуйте, находите что-то новое, становитесь уникальными экспертами — и это обязательно принесет результат.
Как сформировать кросс-функциональную команду
Воплощение большинства бизнес-проектов требует широкого спектра навыков и знаний. Если вы руководите таким проектом, то практически обязательно вам приходится управлять группой представителей разных профессий. Они могут быть частью вашей организации, представлять различные подразделения вашей компании или работать в совсем отдельных структурах. Откуда бы они ни были, они объединены в то, что называется «межфункциональной» или «кросс-функциональной» командой.
Как менеджер проекта, над которым работает команда, вашей задачей является организация членов команды с тем, чтоб превратить их эффективную и слаженную группу специалистов, способную достичь целей, поставленных перед проектом. Сложная задача? Бесспорно, сложная — даже запутанная и трудоемкая. Однако, если следовать определенным правилам, сплочение команды может стать вполне благодарным занятием, а также более легким и вполне успешным. В этой статье изложены самые основные моменты.
Что необходимо знать
Я новичок в менеджменте проектов и мне необходимо сформировать кросс-функциональную команду. С чего мне начать и как найти подходящих людей?
Начните с того, какие задачи ставит перед собой проект и каких навыков требует их выполнение. Затем присмотритесь к сотрудникам и определите, кто из них обладает необходимыми знаниями и энтузиазмом. В то же время необходимо определить, требует ли проект привлечения сотрудников извне. После этого надо нанять людей, которые вам подходят, — для этого может понадобится разного рода одобрение вашего и их начальства. Очевидно, что список кандидатов может сильно разниться в зависимости от характера проекта и объемов необходимой работы.
Если, например, вам необходимо совершить переезд в более подходящее для проекта рабочее помещение, то вам скорее всего понадобятся планировщики, упаковщики, грузчики, электрики, специалисты по установке оборудования, специалисты по телекоммуникациям и т.п. Вероятно, вашим новым сотрудникам нужно будет переехать из разных подразделений компании, потому что вы выбрали именно тех, у кого есть необходимые знания и навыки и тех, кто готов хорошо выкладываться.
Вполне вероятно, что человек, заинтересованный в выполнении проекта — то есть тот, кто назначил вас руководителем, — будет вашим союзником и поможет вам выбрать необходимых людей и нанять их.
Как соблюсти правильные пропорции личностных качеств и знаний в команде проекта?
Это правильный ход мыслей! Взаимодействие разных по характеру личностей во время работы может внести разлад в общее дело, или даже совсем застопорить его. В конечном счете может оказаться, что то, как члены команды взаимодействуют между собой, было гораздо важнеей тех знаний, которыми они обладали.
Так какие же типы личностей должны быть присущи членам новой команды?
Начнем с десятка стандартных командных ролей, выделенных доктором Мередитом Белбином, выдающимся британским автором книг о бизнесе, преподавателем и консультантом. Эта классификация появилась благодаря его исследованию, проведенному в конце 1960-х годов. Классификация прошла проверку временем и по сей день актуальна по обе стороны Атлантики.
В идеале, пропорции личностей указанных типов должны быть разумно соблюдены, поскольку если представителей одного типа будет больше, это может создавать проблемы. Представьте себе команду, состоящую из судей или испытателей! И помните о том, что один член команды может выполнять несколько ролей одновременно.
Так что не переживайте, если в вашей команде по несколько человек на одну роль — это тоже можно использовать. Скажем, можно разбить команду на более мелкие подгруппы, каждая из которых будет заниматься определенными аспектами работы и делать таким образом вклад в общее дело.
Что делать дальше
Ознакомьтесь со стадиями формирования команды
С момента формирования команда проходит через ряд этапов, и на каждом из них могут возникать сонмы проблем и испытаний.
Например, ваша команда пытается разрешить запутанную дилемму, в процессе чего, естественно, возникают конфликты и споры. Если вы вовремя поймете, что это просто такой период развития внутрикомандных отношений, а не будете ломать голову на тем, как успокоить сотрудников, — вы гораздо легче сможете оценить объем необходимой работы, а не тратить время на конфликты.
На стадии устаканивания необходимо подтолкнуть команду в нужную сторону
Для каждой команды необходимо определить вектор. Векторы — это как бы направляющие, и каждый из членов получает свою такую направляющую, руководствуюясь собственными представлениями, мыслями и стремлениями. Для команды было бы катастрофой, если бы все векторы были направлены в разные стороны, и даже если один из членов команды движется в противоположном направлении, это может сослужить дурную службу.
Одна из первостепенных задач менеджера проекта — заставить всех двигаться в одном направлении, чтобы достичь общих целей — это называется «направленность». Хоть это и очевидно, все равно удивляет количество проектов, которые терпят неудачу из-за того, что члены команд тянут одеяло на себя, и на это никто толком не реагирует.
Что мотивирует, а что раздражает членов команды
Мотивация крайне важна для того, чтоб команда работала эффективно и гармонично. Исследования мотивирования показывают, что мотиваторы и демотиваторы — это не совсем связанные вещи. Нечто способное мотивировать людей и подпитывать их энтузиазм — это не всегда то, при отсутствии чего они будут чувствовать неудовлетворение, недовольство и апатию.
Вот список из десяти мотиваторов для членов проектной команды и десяти демотиваторов.
(Из книги Р.Дж. Юрзака «Мотивация в проектах»)
Держите в памяти эти списки, пройдитесь с ними по списку сотрудников и подумайте, что могло бы наилучшим образом промотивировать каждого из них по отдельности или в небольших группах. Затем подумайте, какие из демотиваторов присутствуют на вашеи проекте. Наконец, подумайте, как можно усилить эффект от положительных явлений и снизить влияние негативных.
Делегируйте, но не забывайте контролировать
Делегирование полномочий — еще один важнейший инструмент руководства проектной командой. Раздавать задания — что и является сутью делегирования — кажется очень просто, но далеко не все справляются с этим, особенно, в начале.
Секрет успешного делегирования в том, чтоб почувствовать себя в шкуре членов команды. Скажем, вы опытный и ответственный профессионал, вы хорошо разбираетесь в своей работе и любите ее, но над вами стоит менеджер проекта, который постоянно заглядывает вам через плечо, готовый заранее раскритиковать каждый следующий ваш шаг! Или, к примеру, вы совсем новичок, неуверенный в себе, своих способностях и обязанностях, а над вами стоит руководитель, который умывает руки и ждет, выплывете вы сами, или утонете. Как бы вы вели себя в каждой из ситуаций?
Делегирование требует правильного баланса между контролем и независимостью
Потому, помимо советов по делегированию, запомните еще и правила контроля за выполнением.
Быстро решайте конфликтные ситуации
Чего стоит избегать
Невовлечение коллег в первоначальное планирование
Устанавливать все правила самостоятельно, диктовать методы без обсуждения с командой — это поиск неприятностей на свою голову. Вы собрали этих людей вместе, потому что они опытны и хорошо разбираются в своей работе — так вовлекайте же их в общее дело с самого начала. Они не только преоставят информацию и полезные идеи, но еще и почувствуют себя соавторами общего плана, что поможет им следовать ему в будущем более ответственно и лучше вкладываться в проект.
Отказ от лидерства
С другой стороны, команда — это не совет и не комитет, чтоб коллективно руководить проектом. Вы все еще руководитель, и от вас ожидают, что вы направите все усилия участников в нужное русло, ставя на службу общему делу все полезные идеи и опыт, которые есть у вас в распоряжении. Лучший способ поддерживать согласие в команде — вовлечь всех в планирование на начальном этапе, объяснив объем работы и масштабы проекта. Обязательно нужно добиться комментариев и замечаний, и затем, держа их в уме, пересмотреть еще раз конечные задачи с теми, кто будет их выполнять, и откорректировать план так, чтоб всех он устраивал.
Микроменеджмент
Просто забудьте о нем. Вы не сможете уследить за каждой мелочью самостоятельно. Более того, ваша команда потеряет всяческий интерес к самостоятельной работе. Большинство членов команд гордятся тем, что для проекта выбрали именно их, и это помогает им выполнять свою задачу. Используйте это. Передавайте задачи, поручайте отдельные куски работы, следите за выполнением должным образом, но сосредотачивайтесь на проекте в целом — не упускайте из виду целостную картину. Именно в этом заключается работа руководителя проекта.
Вероятно, самый старый в рунете сайт о менеджменте качества
Храни порядок, и порядок сохранит тебя. (Латинская формула)
Управление кросс-функциональными процессами
Вульгарное представление о кросс-функциональных бизнес-процессах
Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:
Рис. 1. Функции и кросс-функциональные процессы.
Процесс начинается, когда отдел продаж получает заказ клиента.
Получив и оформив заказ, отдел продаж передает его в производство.
Производство приступает к выполнению заказа.
Изготовленный товар доставляется заказчику.
Финансовый отдел производит расчеты.
Рис. 2. Кросс-функциональный процесс «от заказа до оплаты», workflow-версия.
Представьте себе: производственный цех стоит пустой, темный и безмолвный. Тут приходит заказ, мастер включает рубильник и все завертелось. Скажете, чушь? Конечно, чушь! Но наивная диаграмма, изображенная выше, предлагает именно такую картину деятельности предприятия.
Более правдоподобной выглядит следующая схема:
Отдел продаж оформляет заказ клиента и размещает его в производстве.
С определенной периодичностью (например, ежедневно) запускается производственное планирование, которое просматривает накопившиеся заказы и составляет производственный график.
Выполнив очередной заказ в соответствии с составленным графиком, производство уведомляет процесс, связанный с клиентским заказом, о том, что товар готов к отгрузке.
В графическом виде:
Рис. 3. Кросс-функциональный процесс «от заказа до оплаты», BPM-версия.
У нас появилось два процесса, взаимодействующих через данные (БД заказов) и сообщения (уведомление о выполнении заказа). Реализовать эту схему в рамках одного пула (одного процесса) принципиально невозможно, так как у процессов «клиентский заказ» и «производство» разные триггеры: поступление заказа от клиента и таймер, соответственно.
Та же история с доставкой и расчетами: их вряд ли удастся реализовать в рамках процесса «клиентский заказ». То есть технически процессов (пулов) тут не два, а больше.
Workflow, BPM и многопоточное программирование
Кросс-функциональные процессы невозможно реализовать при помощи workflow, потому что границы между подразделениями существуют не просто так: они разделяют области с разными распорядками работы и разными ритмами. Существование этих границ нельзя игнорировать, и их нельзя ликвидировать, просто изобразив поток работ, переходящий из одного подразделения в другое так, как изображено на рис. 2.
Технически эти задачи решаются при помощи процессных паттернов, один из которых изображен на рис. 3. А на уровне методологическом картинка, изображенная на рис. 1, может выглядеть так:
Рис. 4. Кросс-функциональный процесс как координатор функций.
Workflow работает только в пределах одной функции. Как только мы выходим за ее пределы, т.е. как только беремся за кросс-функциональные процессы и начинаем разбираться со стыками между подразделениями, необходимо задействовать более изощренные механизмы взаимодействия между workflow.
Переходя от workflow к межпроцессному взаимодействию, мы переходим от однопоточного к многопоточному программированию.
К сожалению, для многих это становится непреодолимым барьером.
Кто-то этот барьер не видит. Бьется об него, набивает шишки, но не понимает, с чем столкнулся.
Кто-то барьер инстинктивно обходит: выполняет пилотный проект BPM с процессом типа «Оформление заявление на отпуск». Пилот получается успешный, только какое он имеет отношение к бизнесу?
Отсюда, как мне кажется, проистекает большая часть разочарований в BPM: те, кто сводят его к workflow, терпят прогнозируемое поражение.
Но сказать «осваивайте многопоточное программирование процессов» легче, чем последовать этому совету. В ответ раздается стон: «какой же сложный этот BPMN, и кто только придумал в нем 50 разных видов событий!».
Если бизнес и можно запрограммировать, то только как многопоточную систему.
BPM и ACM
Тут я сознательно ступаю на скользкую почву, так как предвижу реакцию адептов ACM (Advanced/Adaptive Case Management): «Ага! Мы всегда говорили, что бизнес в принципе нельзя запрограммировать!»
Может быть можно, может быть нельзя: Скорее всего, в каких-то случаях можно, а в каких-то нет.
В свете вышеизложенного я хотел бы поинтересоваться у критиков BPM из числа адептов ACM: вы уверены, что критикуете BPM, а не wokflow? Не являются ли объектом вашей критики BPM-проекты, в которых либо пытались решать задачи бизнеса, не выходя за рамки workflow, либо бизнес-проблематика вообще отсутствовала?
Потому что в этом случае их провал предсказуем, но он вовсе не означает, что BPM указывает неверный путь. Просто тщательнее надо работать.
Что касается ACM, то это безусловно вещь полезная, но только как дополнение к BPM, а не как замена. Плюс к этому, ACM на сегодняшний день вещь менее зрелая, чем BPM, и поэтому тот, кто наломал дров с BPM, с ACM скорее всего наломает дров еще больших.
Кросс-функциональные паттерны
Воспользуемся следующим примером:
В рамках текущего финансового планирования все счета, полученные компанией, сначала рассматриваются в финансовом отделе: определяется правомерность требования об оплате, уточняются сумма и срок платежа, в соответствии с установленными бизнес-правилами назначается приоритетность каждого требования. Затем требования на оплату поступают на утверждение финансовому директору, который принимает решение об оплате, сообразуясь с приоритетностью, суммой и сроком.
В простейшем виде процессная диаграмма может выглядеть так:
Рис. 5. Синхронный процесс
В реальной жизни компании зачастую устанавливают дифференцированный порядок для разных счетов: например, счета на сумму ниже какого-то предела или требования об уплате налогов проходят без утверждения. Также некоторые счета могут не пройти проверку и отвергаться, не поступая к финансовому директору. От всего этого мы абстрагируемся.
Схема процесса для такого алгоритма действий:
Рис. 6. Планирование ресурса
Для тех, кто не вполне владеет BPMN, даю пояснения к схеме:
После проверки счет помещается в базу данных, а процесс обработки счета переходит в состояние ожидания наступления первого из трех возможных событий: приход сообщения о том, что счет одобрен; приход сообщения о том, что счет отвергнут (платить не будем) или таймаута (для общности).
Одобрение счетов выполняется в рамках самостоятельного процесса планирования платежей, который запускается с определенной периодичностью (например, ежедневно или еженедельно). Первым шагом автоматически выбираются из базы накопившиеся счета с датой оплаты, попадающей в запрошенный период. Отобранные счета представляются в виде списка финансовому директору, и он может для каждого из них выбрать один из трех вариантов действий: «оплатить», «отказать», «отложить».
После того, как он это сделал и нажал кнопку «Готово», экземплярам процесса процесса обработки счетов, для которых выбрано «оплатить» или «отказать», автоматически шлется сообщение о том, что счет одобрен или отвергнут, а соответствующие записи в базе данных счетов помечаются как обработанные. Счета, для которых выбрано «отложить», остаются неизменными, и они снова попадают в выборку при следующем запуске процесса планирования.
Если счет одобрен, процесс обработки автоматически выполняет финансовую транзакцию.
Процессные диаграммы, похожие изображенную на рис.6, регулярно встречаются на практике. Если меня попросить назвать один самый полезный процессный паттерн, то я выберу этот.
Мне больше нравится название «Планирование ресурса».
Еще вариант: «Буфер заказов».
Некоторые используют также термин «Групповая обработка», но мне он не нравится: слишком общо, может означать все что угодно.
Рис. 7. Оптимистичное планирование
Процесс финансового планирования проверяет, достаточно ли средств, чтобы оплатить все предварительно одобренные счета, и назначает задание финансовому директору только в тех предположительно редких случаях, когда средств оказывается недостаточно.
Соответственно, надо предусмотреть обработку исключительной ситуации: если в итоге оплата счета была отменена, то нужно сообщить об этом поставщику.
Рис. 8. Планирование нескольких ресурсов
В этой схеме финансовый отдел, проверяя счет, одновременно готовит решение о том, с какого из расчетных счетов его оплачивать (вероятно, руководствуясь при этом определенными бизнес-правилами).
Финансовый директор, одобряя счет, может согласиться с предложением финансового отдела или перебросить счет на другой банк.
Как видим, в этой схеме разделены процессы обработки счета, планирования оплаты и собственно оплаты. Это дает возможность планировать разные ресурсы или один и тот же ресурс, но на разные даты: например, финансовый директор может запланировать платежи на сегодня и на завтра. Процесс оплаты дождется наступления заданного времени (таймер на схеме) и произведет оплату всех счетов.
Подобная ситуация возникает всегда, когда процесс пересекает границу между подразделениями: клиентский заказ требует активности от производства, производство требует закупки материалов снабжением, разработка новой продукции требует маркетингового исследования, обработка рекламации требует внесения изменений в инструкцию пользователя и т.п.
Но и в более мелком масштабе происходит то же самое: например, ограниченным ресурсом может быть время руководителя. Люди на высоких должностях всегда очень заняты, поэтому если какому-то процессу требуется утверждение или подпись директора, то будьте готовы к тому, что он предпочтет утверждать списком, а не каждый запрос по отдельности.
С этой точки зрения, в рассмотренном примере мы за счет буферизации повысили эффективность использования сразу двух ресурсов: и оборотного капитала, и финансового директора.
Оптимизация кросс-функциональных процессов
Два основных способа организации работы смежных участков в рамках кросс-функционального бизнес-процесса:
По моим наблюдениям, в жизни чаще реализуется асинхронные режим, потому что и подразделения, и отдельные люди чувствуют себя более комфортно, когда их не «дергают» непрерывным потоком разнообразных заданий, а дают возможность как-то упорядочить и спланировать свою деятельность.
1. Линейная система
Начнем с простейшей постановки задачи: N подразделений выполняет каждое по одной из N задач (или подпроцессов) в рамках единственного бизнес-процесса (других процессов нет). Пример:
Рис. 9. Производительность ресурсов и производительность процесса
Просто по теории вероятности, производительности подразделений не будут в точности совпадать. Кроме того, выровнять производительность зачастую невозможно технологически. Скажем, прием заказов обладает запасом по производительности, так как заказы принимаются в распределенных офисах продаж, а половину человека в офис не посадишь. А с другой стороны, производительность дизайнерского отдела не удается повысить из-за нехватки квалифицированной рабочей силы.
Что более существенно, увеличение производительности любого звена, не являющегося «бутылочным горлышком», никак не отразится на производительности цепочки.
Согласно Теории ограничений, буфер следует организовать перед «бутылочным горлышком», но только в этом единственном месте: дополнительные буфера не повысят производительность, а только приведут к лишним затратам.
Рис. 10. Оптимальная схема для процесса с одним «бутылочным горлышком»
2. Ограничение на входе системы
В рассмотренном выше примере производительность участка приема заказов есть число заказов, которые он способен принять и обработать в единицу времени. Не следует путать этот показатель с потенциальным спросом, т.е. числом заказов, на которое мы в принципе можем рассчитывать. Предположим, что спрос меньше, чем производительность нашего процесса:
Рис. 11. Процесс, ограниченный по входу
В этом случае оптимальной будет полностью синхронная схема:
Рис. 12. Оптимальная схема для процесса, ограниченного по входу
Ситуация может показаться абсурдной: зачем держать ресурсы, превышающие имеющийся спрос? Тем не менее, такая ситуация встречается достаточно часто:
Может сказываться сезонность. Скажем, компания, выпускающая прохладительные напитки,
Конъюнктура всегда отчасти непредсказуема, и поэтому полезно иметь некоторый запас производительности.
Спрос не является чем-то абсолютным: на него влияют в том числе цена и качество наших продукции и услуг.
В рассматриваемом примере запас производительности процесса относительно спроса составляет 20%. Если спрос колеблется в этих пределах, то синхронная схема будет предпочтительной; если больше, то есть смысл вернуться к схеме на рис. 12.
К сожалению, рассмотренные линейные модели слишком просты, чтобы полученные выводы можно было непосредственно использовать на практике. В жизни есть как минимум два источника нелинейностей: старты и переналадки.
3. Влияние стартов
Синхронный режим работы является таковым с точки зрения процесса, а с точки зрения исполнителя (ресурса) вовсе наоборот:
сидим, курим, заказов нет
пришел заказ- работаем, особо не спешим
второй заказ, третий- откуда их столько?
аврал, не справляемся, выполнение заказов задерживается
уф, справились, снова курим
И наоборот, асинхронный режим предполагает, что мы заранее составляем план работы, скажем, на рабочую смену, и спокойно, ритмично, рассчитывая свои силы, без авралов и перекуров, его выполняем.
Аналогично тому, как производственная линия выходит на рабочий режим не сразу, а через некоторое время, человеку тоже нужно время, чтобы перейти от простоя к производительной работе.
4. Влияние переналадок
На уровне процессов верхнего уровня это не так заметно, но если мы спустимся на один-два уровня ниже, то обнаружим, что исполнитель (т.е. каждый из нас) задействован не в одном, а в нескольких процессах. Причем как правило, чем выше человек поднимается по служебной лестнице, тем большее число процессов требует его участия.
Теперь представьте, что вам во входящие непрерывно поступают задания от десятка разнообразных процессов. Переключение между задачами сопряжено с усилиями и дополнительными затратами, аналогичным тем, которые возникают при переналадке универсальной производственной линии с выпуска одной продукции на другую.
Чем меньше таких переключений, тем меньше затраты на «умственную переналадку» и следовательно, тем выше ваша индивидуальная производительность. Уменьшить число переналадок можно за счет асинхронной обработки.
при синхронном режиме исполнения процессов вы будете их обрабатывать в той последовательности, в которой они к вам поступили: А1, А2, Б1, А3, Б2, А4, А5, Б3,:
при асинхронном режиме исполнения процессов задания будут накапливаться в буфере и обрабатываться сериями: А1+А2+А3+А4+А5, Б1+Б2+Б3,:
Выполнять однотипные задачи всегда легче. Может быть для двух типов задач это не так очевидно, но что если их десятки? Это объясняет, почему финансовый директор скорее всего предпочтет, чтобы заявки на оплату поступали к нему не по одному, а списком.
5. Рекомендации по оптимизации с учетом нелинейных факторов
Итак, в синхронном режиме время исполнения процесса минимально (хорошо), но этот режим сопряжен со снижением производительности из-за стартов и переналадок (плохо).
В результате мы можем получить, например, такую картину:
Рис. 13. Снижение производительности из-за стартов и переналадок
То есть, применительно к работе, выполняемой людьми:
бороться с собственной инерцией, браться за любую работу сразу и не раскачиваясь
не создавать себе комфортную зону, давая задачам «вылеживаться» во входящих
Конечно, всему есть предел, и если тот или иной руководитель или специалист реально перегружен, то ему как раз надо создать такую комфортную зону.
Однако в большинстве случаев это не так. Но тут, чтобы добиться успехов, необходимо учитывать психологические факторы:
У исполнителя должно быть понимание, что его личная производительность не имеет значения. Синхронное исполнение процессов создает для него лично дополнительное напряжение, которого при иной организации работы можно было бы избежать, но это делается не для того, чтобы над ним поиздеваться, а потому, что так лучше для клиента, который царь и бог в правильно организованном бизнесе.
Если человек быстро справляется с поступающими задачами, без задержки выполняя их в том темпе, в котором они к нему приходят, то он должен быть уверен, что он из-за этого не пострадает- что начальство не решит, что он мало работает.
6. Оптимизация вспомогательных процессов
Все сказанное выше относилось к основным процессам, качество и производительность которых непосредственно отражается на клиентах.
Что касается вспомогательных процессов, то там время исполнения не столь важно, и на первый план выходит экономное расходование ресурсов. Поэтому для вспомогательных процессов асинхронный режим исполнения следует считать основным.
С точки зрения бухгалтерии это будет выглядеть так: балансовая отчетность и расчеты с персоналом ведутся в размеренном ритме, а счета готовятся в режиме немедленного реагирования. Такая организация легко может вызвать протесты и конфликты, так как:
в рамках функционального мышления первые два процесса бухгалтерия будет считать «своими», так как является в них основным исполнителем, и соответственно, будет уделять им внимания больше, чем выписке счетов в рамках «чужого» бизнес-процесса
в процессной же логике дело обстоит иначе: она требует, чтобы к задачам в рамках основных процессов относились как к приоритетным вне зависимости от того, «свой» это процесс или «чужой»