кросс функциональные проекты что это
Пять советов для тех, кто собирается создать кросс-функциональную команду
Chief Happiness Officer в Qmarketing
Кросс-функциональная команда может значительно усилить любой проект и быстро решить поставленные задачи. Однако просто собрать профессионалов с различными компетенциями не получится – нужно следовать определенным правилам. Мила Максалиева, Chief Happiness Officer в Qmarketing, поделилась своим опытом в формировании кросс-функциональных команд.
Изначально кросс-функциональные команды появились в agile-культуре. Но так же, как agile вышел за пределы IT, практика команд, собранных из разных профессионалов, переросла гибкую разработку и стала использоваться во многих компаниях для решения небольших задач. Я, например, ввела команды такого типа в структуру издательства «Эксмо» и медиахолдинга Independent Media.
Зачем нужны такие команды
Итак, кросс-функциональная команда – это группа профессионалов с разными компетенциями, которая собирается специально под проект. Причем обязательно краткосрочный: запуск нового продукта, решение задачи или тестирование гипотезы.
Дело в том, что работа в команде не освобождает сотрудников от их ежедневных обязанностей, наоборот – становится дополнительной нагрузкой. Если она еще и длительная, то это уже не проект, а вторая работа.
Для большого и долгосрочного проекта кросс-функциональные команды не подходят. Но если в вашей компании есть краткосрочные задачи, для которых нужна сила лучших умов из разных областей – эта практика идеальна.
Кросс-функциональная команда обладает большим видением и опытом, чем классические разделенные по функционалу отделы, работающие по своду правил. Каждый член команды обладает глубокой экспертизой в своей области, а значит точно поможет пройти «минное поле» без потерь и задержек. В конечном итоге решения будут приниматься быстрее и эффективнее.
Но есть проблема: если просто собрать профессионалов, то в 99,9% случаев они не найдут общий язык, и волшебства не получится. Поэтому нужно учиться правильно подбирать, мотивировать и выстраивать связи между участниками группы. Так что, создавая новую структуру, вы столкнетесь со множеством трудностей. Делимся лайфхаками, которые помогут их преодолеть.
1. Отнеситесь к команде, как к инвесторам
Собирая людей в команду, постарайтесь донести до них всю важность проекта, которым они будут заниматься. Честно расскажите не только о целях, но и о возможных проблемах, которые наверняка будут ждать вас в этом совместном полете. Кто бы что ни говорил, а больше всего люди ценят честность.
Подойдите к подготовке этого так, будто выступаете перед потенциальными инвесторами, которым хотите продать проект. Не поленитесь подготовить несколько слайдов в таком порядке: сначала описание проекта и его ценность для бизнеса или компании, затем – возможности (роста/финансовые бонусы и так далее) для самих участников, а в конце расскажите о рисках, которые вы берете на себя как команда.
На всех больших кросс-проектах в «Эксмо» перед первой встречей я готовила файл, в котором было описание с механикой проекта, бенефиты для каждого стейкхолдера, отдельный слайд о возможных точках риска и распределение ролей в проекте. Если вы не указали этого в самом начале, ничего не получится, так как все будут сдвигать в дальний угол приоритетности.
2. Станьте лидером проекта
Своим примером показывайте правильный подход к планированию: вы тот человек, который будет задавать скорость работы команды.
Для подстраховки дедлайнов после составления road map проекта я сразу ставила напоминание и время в собственный календарь, чтобы не забыть чекнуть все вовремя.
3. Установите правила
Договоритесь о зонах ответственности каждого участника и их целях (KPI). Каждый член команды до начала реализации проекта должен четко понимать сферу собственных задач, действий и полномочий.
На первой встрече можно взять обычный флипчарт и разделить его пополам. В верхнюю половину выписать членов команды с функционалом каждого. В нижнюю – задачи, которые понадобится решить для реализации проекта. На соседнем флипчарте соедините каждую задачу с несколькими исполнителями, которые будут сообща над ней работать.
Далее, не откладывая, создайте проект в таск-менеджере вроде Asana или доску в Kaiten. В описание самой доски или проекта перенесите то, что у вас получилось на флипчарте. А дальше постройте временной road map и отметьте на нем реперные точки по каждой задаче.
Из опыта работы в «Эксмо»: бренд-менеджер ставил задачу на PR-группу, но в большинстве случаев они уходили в песок. Всего «брендов» было 12 и три PR-менеджера, а проектов в продвижении около 100 в месяц с разным набором задач.
Вместе с командой разрисовали процесс на ватмане с помощью стикеров и маркеров. Потом пометили узкие места и распределили ответственных на каждой стадии, а после перенесли в Kaiten.
Каждый проект разбит на основные стадии.
В описании самой доски зафиксировано, кто в какой зоне ответственный и как происходит механика процесса. Такое четкое распределение помогло ускориться на проектах по PR в три раза.
4. Мотивируйте
Обязательно празднуйте маленькие победы – это один из самых прекрасных мотиваторов для вашей команды. После каждого успешного завершения этапа проекта устраивайте небольшой праздник. Пишите письмо на всех, хвалите публично, «мол, молодцы, все круто сделали, давайте отпразднуем это!». Дальше уже дело техники. Можно заказать пиццу, суши, купить на всех билеты в кино или квест. Я чаще всего приношу пару бутылок просекко и шарики, которые висят в кабинете еще несколько дней.
Кроме того, можно использовать и технику «спасибо» – это когда каждый член команды по очереди благодарит за что-то хорошее, что случилось в работе, одного коллегу или всех.
5. Боритесь с неизвестностью
Следите за процессом и не забывайте рассказывать о проекте смежным подразделениям. Неизвестность пугает любого нормального человека. Поэтому, если не рассказывать коллегам и департаментам, с которыми вы связаны, о том, как продвигается проект, – могут быть проблемы.
Самый простой способ – проводить раз в месяц общую отчетную встречу лидера команды со стейкхолдерами соседних департаментов, с которыми связан ваш проект.
Можно даже не заморачиваться с презентацией. Покажите им road map и расскажите, что происходит: всего 30 минут и все счастливы, потому что в курсе.
Я ставила встречу с коллегами из соседних, связанных с проектом, департаментов раз в месяц. Это необязательно должно происходить в офисе. Иногда более приятный и эффективный формат – совместный поход в кофейню и обсуждение задач по проекту в свободном формате.
Как получить максимум
Все советы, которые написаны ниже, основаны на собственном опыте и не претендуют на истину (но точно работают).
Как настроить работу внутри большой кросс-функциональной команды
Железные из Redmadrobot рассказывают, как отладить работу внутри команды из более семи человек так, чтобы каждый понимал свою зону ответственности, а новый специалист не тратил много времени на погружение в проект.
Для этого мы используем спринт-пульс. В статье даём заготовку этого инструмента в Miro, которую можно докрутить под свой проект, и практические советы для организации.
Дисклеймер: данный материал для специалистов, которые работают по Agile, в особенности по Scrum. В тексте присутствуют такие слова, как «блокер», «тайминг», MVP, QA и вот это вот всё. Они могут оскорбить чувства неподготовленных к такому людей.
Предупреждён, значит, вооружен, а теперь к делу. Чем отличается спринт-пульс от спринта:
Спринт — это отрезок времени, за который Scrum-команда создаёт полезную часть продукта, которую можно выпустить в свет.
Спринт-пульс — это инструмент, который помогает минимизировать простои и выстроить работу команды во время спринта с учётом зависимостей внутри.
Мероприятия спринта поменять нельзя, а вот спринт-пульс — это та часть, которую можно настроить под конкретный проект.
Чтобы рассказать, как мы пришли к спринт-пульсу, берём в пример историю нашего проекта по созданию мобильного приложения. Но этот инструмент подходит и под другие типы проектов.
Стартовая команда проекта состояла из 6 человек: владелец продукта, менеджер проекта, UX-исследователь, арт-директор и два дизайнера. Одна итерация — одна неделя. Для всего этого подошёл Scrum.
Работа шла так: после проектирования целевых сценариев в wireframes и тестирования их на пользователях, мы должны были создать дизайн-концепцию приложения, а затем приступить к проектированию остальных сценариев и разработке MVP.
Чтобы разработчики могли вовремя стартануть свою часть, их подключили к работе на пару спринтов раньше. Это время нужно было для того, чтобы команда могла продумать архитектуру приложения и настроить непрерывную интеграцию.
В это время появился вопрос — а как, собственно, можно «подружить» создание UI с кодингом? Но так, чтобы сохранился темп работы и постоянный инкремент (прирост продукта). Кроме того, команда разрослась, появились QA и четыре разработчика, пришлось увеличить срок спринта до двух недель.
Мы решили провести встречи с тимлидами по направлениям и с владельцем продукта со стороны клиента.
После этого зафиксировали этапы работы и узнали, что необходимо каждой подкоманде, чтобы стартовать свою часть. Например, функциональные требования от аналитика — это основа работы разработчиков. Если тут случится задержка, то и весь проект «съедет» по сроку.
В процессе анализа работы мы поняли, что нам нужно что-то большее, чем мероприятия Scrum, для того чтобы всё работало чётко.
С помощью стандартных инструментов Scrum сложно эффективно распределить время специалистов. В большом проекте это может привести к блокерам из-за того, что артефакт для следующего этапа не будет готов.
Самые первые зарисовки нашего спринт-пульса
Собрав информацию, мы нашли и зафиксировали зависимости внутри команды: что после чего идёт и в какой промежуток времени должно быть сделано — всё это и стало спринт-пульсом.
Последний этап — интегрировать спринт-пульс в сам спринт.
Спринт-пульс со стикеров и бумаги мы пересобрали в Miro. Вообще, можно использовать любую другую программу (хоть на физических носителях, если удобно). Главное, чтобы все участники спринта могли в любое время посмотреть на схему: синхронизироваться по времени, задачам и связью с другими подкомандами.
Несколько ситуаций, с которыми нам помогает справляться инструмент. Это именно наш опыт. И конечно же, это не весь список. У каждого пользователя спринт-пульса он может быть свой.
По правилам Scrum, команда сама должна выстроить работу внутри спринта, опираясь на его мероприятия. Но проблема номер раз — у членов команды разный уровень способностей в коммуникациях и организованности. Два — чтобы наладить коммуникацию и процессы, специалистам нужно провести серию встреч, потратив на это время.
Решение: спринт-пульс — это «стартовый кит», схема работ. Сформировав его до момента, когда командам будут даны задачи, можно быстро и слаженно стартовать.
Во время работы специалисты сфокусированы на выполнении своих задач. Они могут не видеть риски и связи с коллегами.
Без плана внутри спринта команде сложно увидеть всю картину целиком, поэтому появляются блокеры, мешающие следующим в цепочке начать вовремя. Результат такого «снежного кома» — недостижение целей спринта, а иногда провал всего проекта.
Пример: тестирование приложения для банка.
Если не заложить время на тестирование и стабилизацию, то к концу спринта будет кодовая база, но времени на поиск и исправление дефектов не останется. А без этого нельзя назвать разработанный функционал «законченным инкрементом». Отдать такой продукт клиентам банка не получится: он будет работать со сбоями, и это может привести к проблемам для банка. Например, может случиться утечка персональных данных, взлом аккаунтов, кража денежных средств и прочие ужасы.
Решение: на протяжении всей работы команда видит единый спринт-пульс. Каждый знает, кто и что от него ждёт в конкретный день, и выстраивает свою работу исходя из этого. Также спринт-пульс своего рода «контракт» между подкомандами. И если артефакты не были предоставлены в срок, то у специалиста есть право просигнализировать о проблеме, ведь все ключевые сроки зафиксированы в спринт-пульсе.
Обычно на онбординг новичка уходит большое количество времени. Чтобы начать работать в полную мощь, ему нужно понять, что вообще происходит и погрузиться в процессы.
Пример: к проекту подключается ещё один дизайнер. Ему рассказывают про проект и задачи, общекомандные и его подкоманды. Затем ему нужно пообщаться с другими дизайнерами и разработчиками. Важно узнать все тонкости, к примеру, когда он может привлечь разработчиков для оценки технической сложности спроектированной им реализации. Это занимает время и отвлекает остальных от задач, а значит, снижает её эффективность.
Решение: подготовленный для проекта спринт-пульс упрощает и ускоряет процесс онбординга. В нём уже наглядно показаны зависимости в команде: кому, в какой момент и что необходимо предоставить.
Спринт-пульс может ускорить работу, но есть случаи, когда тратить время на его организацию не стоит. Эта табличка — подсказка: если количество «нет» больше, чем «да», то, возможно, вам подойдёт другой инструмент.
Чтобы организовать спринт-пульс для своей команды, нужно ответить на шесть вопросов. Это поможет собрать информацию для выявления зависимостей и блокеров, которые нужно будет разложить на тайминг каждого спринта.
Вначале нужно определить направление работы: что делаем, кто делает, какая цель, что считаем за результат и так далее.
Находим все активности, которые затрагивают каждую из команд. Например, QA: ревью требований, написание тест-кейсов, тестирование, верификация исправленных дефектов и прочее. Прописываем их этапы от начала и до конца спринта.
Определяем контрольные точки в спринте каждой команды. Они обозначают завершение работ над задачей в рамках спринта. Например, закончили разработку новой функциональности → пора проводить регрессионное тестирование.
Определяем время на производство всех «зависимых» артефактов, нужных для работы других команд (например, макеты дизайнеров для разработчиков). Находим все взаимозависимости. Затем соединяем их и раскладываем на таймлайне спринта.
Выявляем простои — моменты, которые могут сказаться на скорости и достижении целей спринта. Также находим задачи, которыми можно занять подкоманды во время вынужденных простоев. Но не просто, чтобы специалисты что-то делали, эти задачи должны помочь другой команде работать эффективнее в будущем.
Например, у нас первый день спринта посвящен планированию и оценкам, нежели непосредственной работе, поэтому для нас таким мероприятием стал «чистый день» команды дизайна, в который они могли навести порядок в макетах и актуализировать карту экранов.
Здесь нужно понять, на каких контрольных точках будет синхронизироваться команда. Все эти моменты фиксируем: какой результат, в каком объеме и к какому сроку должен быть готов. Мы синхронизируемся на встречах, звонках или в Slack.
Как только дизайнеры завершили проектирование сценария в ваерах, мы собирались всей командой на синк. На нем мы презентовали наработки и собирали обратную связь по техническим ограничениям. В результате дизайнеры выдавали максимально реализуемые результаты.
Важно понимать, что на протяжении какого-то времени спринт-пульс будет «притираться» к реальностям проекта. Но даже несмотря на это, стартовать получится всё равно быстрее, чем без него.
Чтобы собрать спринт-пульс для своей команды, можно использовать вот такой шаблон. Мы указали основные моменты, дальше вы можете адаптировать всё под свой проект.
Эффективный процесс получается настроить, когда каждый специалист понимает, что, когда и зачем он делает. Для этого команду нужно синхронизировать, и спринт-пульс хорошо справляется с этой задачей.
Это дополнительный и необязательный инструмент для SCRUM-команд, но он точно полезный. Особенно, если команда кросс-функциональная и в ней больше семи человек. Спринт-пульс поможет двигаться в тайминге спринта, а вовремя завершенные спринты в свою очередь гарантируют готовый продукт к сроку.
Гибкая экосистема: как проанализировать эффективность кросс-функционального взаимодействия подразделений?
Татьяна Руппель.
Когда бизнес масштабируется, превращаясь в многофункциональную компанию, возникает острая потребность формировать эффективные модели коммуникаций между сотрудниками.
Кросс-функциональное взаимодействие предполагает объединение специалистов различных зон ответственности для решения одной бизнес-задачи. Построение «живой» экосистемы, внутри которой персонал может обмениваться информацией, генерировать идеи, вместе разрабатывать и реализовывать проекты становится для HR и руководителей стратегической миссией.
Бизнес-трансформации, формирующие кросс-функциональное взаимодействие
Иногда на успешное формирование кросс-функциональных связей уходит несколько лет. Ведь от людей, ответственных за реализацию этой цели, потребуется ювелирная точность, скульптурная терпеливость и упорство спортсмена. Внедрение такой формы взаимодействия проектных групп состоит из комплекса микрозадач, над которыми предстоит работать системно.
Тем не менее, выделяют три фундаментальные трансформации, без которых наладить продуктивные связи внутри команды вряд ли получится.
Как кросс-функциональная модель помогает бизнесу совершенствоваться
Какие, собственно, возможности открывает кросс-функциональное взаимодействие для работодателя? Их немало, перечислим пять ключевых.
Роль HR в обеспечении продуктивных коммуникаций
HR играет ключевую функцию не только на этапе создания кросс-функциональной среды. Он же должен обеспечивать бесперебойную работу этого механизма. Эйчар следит за тоном коммуникаций, оценивает их конструктивность и ценность для проекта.
Выясняет, насколько системно происходит информирование команды о новостях, результатах очередного этапа и т.д. Изучает принятые модели общения и анализирует, насколько они действенны. Наблюдает за частотой совещаний, где собирается вся команда, оценивает роли и вклад каждого участника проектной группы, проясняет, всем ли сотрудникам понятны цели, комфортно ли им работать над общей задачей.
В зону ответственности HR входит анализ вовлеченности сотрудников в проект. Его цель – определить «достигаторов», которые смогут работать в команде, принося пользу бизнесу и самому себе.
Инструменты, которые выявят слабые места кросс-функционального взаимодействия
Когда в 2020 году в стране разразился локдаун и российские компании массово отправились в Home Office, пожалуй, самые большие опасения бизнес-сообщества были связаны с неспособностью персонала эффективно работать в дистанционном режиме, что приведет к исчезновению креатива и прогресса.
Время показало, что сотрудники с опытом работы в кросс-функциональных командах быстро адаптировались к удаленке. Гибкий и равный подход в управлении персоналом, в основе которого лежит самодисциплина, осознанность сотрудников, их понимание ценности своей роли в процессе, идеально подошел к условиям неопределенности.
Тем не менее, HR-подразделение должно регулярно осуществлять оценку эффективности кросс-функционального взаимодействия, проводить глубокий анализ и поиск «узких» мест, чтобы понять, на каком уровне нужна модернизация.
Существует немало способов выяснить это – пульс-опросы, тесты, глубинные интервью. Одни тесты показывают, насколько совместимы члены команды, другие помогают определить роли в проектной группе (тест Белбина), выявляют неформальных лидеров, третьи позволяют оценить эффективность управления проектом ответственного менеджера.
Опросы могут проводиться среди всех сотрудников, выборочно, или экспертно, когда исследование осуществляется среди руководителей. Процедура должна быть анонимной, иначе ответы будут не вполне недостоверными.
Безусловно, работа эта сложная и длительная, но крайне важная, поскольку дает ответ на несколько важных вопросов. Во-первых, позволяет заметить этапы, на которых требуется реконструкция. Во-вторых, по итогам оценки эффективности кросс-функционального взаимодействия команды HR может составить рейтинг и найти амбассадоров. В-третьих, узнает истинный уровень NPS (Net Promoter Score).
Что касается трудозатратности, то значительно облегчит оценки ИТ-решения, которые автоматизируют процесс сбора данных и их систематизацию.
Программа регулярно осуществляет анализ работы проектной команды, структурирует аналитику в отчеты и передает эти знания HR, которому останется лишь грамотно использовать эту информацию и скорректировать стратегию управления персоналом с фокусом на межфункционального сотрудничество и гибкость.
Кросс-функциональное взаимодействие
Современные технологии позволяют наладить мгновенную коммуникацию, упрощая сотрудничество. Таким образом, координация работы разных сфер может быть практически исключена.
Сфера кросс-функционального взаимодействия обширна. Это могут быть повседневные задачи, единовременные проекты, работа с клиентами, продажи и многое другое. Данная система позволяет решать вопросы комплексно, внося изменения на каждом этапе реализации.
Преимущества кросс-функционального взаимодействия в том, что каждый член группы вовлечен в рабочий процесс, может реализовать себя и узнать что-то новой в смежных областях. Также повышается командный дух и доверие в коллективе.
Подобное сотрудничество может принести максимальную эффективность в компании. Однако, наладить данный процесс не так то и просто.
На начальном этапе участник группы имеет слабые представления о том, чем именно занимается его коллега. И не может в полной мере оценить их вклад. Для того-чтобы команда работала единым фронтом необходимо знакомство и общение всех участников. А также информационный портал, где каждый участник может узнать обязанности своих коллег.
Для успешной и автономной работы, руководителю группы необходимо грамотно расставить цели, задачи, этапы, сроки и наладить коммуникацию. А также распределить их по всем участникам. Работники могут находиться в разных офисах, городах или странах и важно донести информацию до каждого.
Важно знать, что кросс-функциональному взаимодействию необходимы: четкая связь и высокая квалификация участников. Работники должны уметь работать в команде, быть ответственными и автономными. В данной схеме большую роль играет доверие и общение. Ведь традиционные подходы решения возникающих проблем очень часто не работают, при подобном взаимодействии. Важно предоставить возможность работникам выполнять работу в своем привычном ритме. И создавать инструменты для совместной работы.
Стоит отметить, это метод является новшеством в сфере менеджмента, и данная модель взаимодействия подходит высокотехнологичным компания.
Вероятно, самый старый в рунете сайт о менеджменте качества
Лишены прозорливости не те люди, которые не достигают цели, а те, которые проходят мимо нее. (Франсуа де Ларошфуко)
Управление кросс-функциональными процессами
Вульгарное представление о кросс-функциональных бизнес-процессах
Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:
Рис. 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. Оптимизация вспомогательных процессов
Все сказанное выше относилось к основным процессам, качество и производительность которых непосредственно отражается на клиентах.
Что касается вспомогательных процессов, то там время исполнения не столь важно, и на первый план выходит экономное расходование ресурсов. Поэтому для вспомогательных процессов асинхронный режим исполнения следует считать основным.
С точки зрения бухгалтерии это будет выглядеть так: балансовая отчетность и расчеты с персоналом ведутся в размеренном ритме, а счета готовятся в режиме немедленного реагирования. Такая организация легко может вызвать протесты и конфликты, так как:
в рамках функционального мышления первые два процесса бухгалтерия будет считать «своими», так как является в них основным исполнителем, и соответственно, будет уделять им внимания больше, чем выписке счетов в рамках «чужого» бизнес-процесса
в процессной же логике дело обстоит иначе: она требует, чтобы к задачам в рамках основных процессов относились как к приоритетным вне зависимости от того, «свой» это процесс или «чужой»