что такое кросс функциональный проект
Зачем HR-специалисту становиться «расческой», или Кросс-функциональность как конкурентное преимущество
Что такое кросс-функциональность и чем она хороша
В интернете можно встретить термин «люди-расчески» — это про тех специалистов, которые оттачивают знания сразу в нескольких сферах. Признаюсь, что такое название мне не близко, однако в своей работе я замечаю стойкий спрос на кросс-функциональных специалистов. Это может быть юрист, обладающий знаниями в области психологии конфликтов, логист, разбирающийся в экономике или sales-менеджер с экспертизой в аналитике.
Вы слышали разговоры о том, что через какое-то время специалистов заменят роботы? Так вот, не заменят, или, вернее, заменят не всех. Машине можно передать рутинные процессы, но творческая деятельность, генерация новых идей и умение в сложной ситуации найти необычное решение останется за человеком.
Кросс-функциональный специалист, работающий на стыке двух или более сфер, — это как раз такой незаменимый «винтик». Он ведет свою карьеру по пути, по которому до него либо вообще никто не шел, либо шло очень ограниченное количество людей. Он постоянно сталкивается с новыми вызовами и обладает принципиально новым, уникальным опытом.
Например, специалист по маркетингу, в обязанности которого входит подготовка новостей, пресс-релизов и контента для рассылки по клиентской базе, начинает заниматься программированием и версткой сайта компании. В какой-то момент он становится уникальным профи на стыке маркетинга и ИТ.
Развитие в новой сфере может стать хорошим вариантом для человека, который достиг карьерного потолка или столкнулся с эмоциональным выгоранием. В этом случае подумайте, в каких близких отраслях или даже соседних отделах можно применить ваши знания? Универсальный пример: вместо того чтобы увольняться, секретарь может продолжить развитие в рамках своей компании на позиции младшего маркетолога или аналитика.
Зачем кросс-функциональность HR-менеджеру
Сфера HR остро нуждается в кросс-функциональных менеджерах. Успешные HR-специалисты постигают основы маркетинга и учатся грамотно применять самые разные маркетинговые инструменты — от «воронок» до исследований и таргетинга, чтобы сделать поиск специалистов эффективнее и быстрее. Марчар, или HR-маркетолог, — это уже не столько новый тренд, сколько новая реальность, объявления о поиске таких специалистов постоянно появляются на hh.ru.
Растет спрос на HR-специалистов с опытом и экспертизой в ИТ-сфере. Знание основ программирования дает новые инструменты для оптимизации поиска и найма, рынок диджитал-инструментов для управления персоналом растет, и для того, чтобы ориентироваться в них и грамотно использовать, нужны навыки работы с высокими технологиями и глубинное понимание диджитал-процессов.
Чтобы выигрывать в борьбе за таланты, компании серьезно работают над своим работодательским брендом. Представьте, какую пользу делу может принести HR-специалист, который знает современные тренды, умеет анализировать целевую аудиторию, проводить исследования, «упаковывать» и доносить уникальное предложение работодателя до потенциальных сотрудников самым эффективным способом. Такой человек, сочетающий функции HR-специалиста, социолога, маркетолога и порой SMM-специалиста, на рынке труда обладает мощным конкурентным преимуществом.
Как стать кросс-функциональным
В первую очередь — задуматься над тем, чем вам действительно нравится заниматься. Решение стать кросс-функциональным специалистом — отличная возможность чуть больше полюбить свою работу, добавив в нее той деятельности, которая приносит вам удовольствие.
Может, вы увлекаетесь словесностью, много читаете и друзья часто говорят, что вы хорошо пишете? Или следите за трендами в социальных сетях и смотрите вебинары для эсэмэмщиков? А может, у вас есть чувство вкуса и вам интересен дизайн сайтов? Все эти навыки можно отточить и развить с пользой для карьеры и для компании.
Не обязательно и даже не нужно сразу идти на второе высшее. Присмотритесь к краткосрочным курсам, интенсивам, мастер-классам от профи.
Не гонитесь за модой и не уходите в какую-то сферу просто потому, что «все так делают». Повальное увлечение языком программирования Python привело к тому, что рынок стал перенасыщен «питонистами», тогда как хорошие программисты на более сложном языке JAVA по-прежнему в дефиците.
Следуйте за своим интересом, учитесь, пробуйте, находите что-то новое, становитесь уникальными экспертами — и это обязательно принесет результат.
Что такое кросс функциональный проект
[Сейчас будет штамп, но по-другому тут и не скажешь, ведь]
Наверняка, каждый из вас сталкивался с проблемой сложности выстраивания коммуникаций с другими командами. У этих «других» ведь все как-то иначе: у «этих» задачи разработчики вместо аналитиков заводят, «вот эти» по спринтам живут, а «вон те» вообще говорят, что до II квартала 21-ого года задачи не принимают…
И ты такой стоишь посреди всего этого великолепия и не знаешь, с чего начать, чтобы все же сделать задачу? Надеюсь, эта статья поможет тебе.
Хочу рассказать о том, как мы все можем сделать работу над кросс-проектами в нашем IT более предсказуемой, понятной и более эффективной. Работая над проектом по запуску постаматов, наша команда накопила кое-какой опыт. В этой статье постараюсь донести все полезные наработки, которые может использовать каждый сотрудник IT подразделения.
Сначала давайте обговорим, что же такое кросс-функциональные проекты и какой проект можно к ним отнести, а какой нет. За общий случай мы берем:
Кросс-функциональные проекты – проекты или крупные фичи, в которых задействовано 2 и более функциональных модуля от разных команд
Почему именно разные функциональные модули и разные команды? Все просто: в рамках одного модуля у нас постоянно происходит взаимодействие между разными командами. Например, между бэком и фронтом. Это уже настолько обыденная ситуация, что было бы странно объявлять это кросс-проектом и как-то по-особому с ним работать. Тоже самое касается и «разных команд»: если одна и та же команда работает над двумя модулями, то у нее тоже вряд ли возникнут проблемы в реализации, особенно, если писать код или аналитику будет один и тот же разработчик или аналитик. Но если команды разные и модули разные – тут уже вполне могут начаться проблемы…
При работе с постаматам мне и моей команде очень повезло: очень четко были определены цели проекта, обозначены сроки и выделены ресурсы. Более того, объем ресурсов даже позволял, в теории, уложиться в обозначенные сроки! Но встал большой вопрос – как всем этим хозяйством распоряжаться?
Быстро выяснилось, что так или иначе задействованы будут практически все модули ЭК5 и интеграции. Одних только аналитиков было задействовано 19 человек! При этом изначально вся наша команда: я в качестве PM и Мария Колесникова как главный аналитик проекта.
1. Убедись, что понимаешь, что и зачем тебе нужно сделать. Если нет – самое время спросить у главного по твоему направлению.
2. Если нет главного – стоит спросить об этом своего менеджера. И о том, что непонятно и о том, почему нет главного по направлению. Менеджер не любит вопросов (фи-и-ить, щютка), так что он, наверняка, быстро организует назначение «точки входа».
3. Убедись, что ты и твои коллеги составили план работ – понятный всем и выполнимый (хотя бы на ближайшую перспективу). Если нет – подними этот вопрос сам в общем чате или же снова напомни о себе менеджеру (надеюсь, меня не побьют и не отравят).
4. Если что-то меняется в проекте – не забудь предупредить об этом коллег по проекту. Может быть, это даже не у тебя меняется, а ты где-то на митинге услышал об этом: если считаешь, что это может что-то задеть в проекте – лучше «перебдеть» и лишний раз переспросить.
5. Верь в своих коллег! Даже если у них срываются сроки и они тебя подводят – скорее всего, они это не специально и расстроены не меньше твоего (если это не так – да осквернят шакалы прах их предков). Лучше спроси их, чем можешь помочь и поддержать.
6. Если твои задачи систематически «задвигаются» коллегами – тут уже не стоит это терпеть. Время ставить вопрос о том, что «без моей левой гусеницы танк тоже не поедет!»
Сейчас мы работаем над трансформацией вышеописанного в простой и понятный регламент работы по кросс-функциональным проектам. А вообще, самый лучший регламент – это ответственное отношение к своему делу и окружающим.
Вероятно, самый старый в рунете сайт о менеджменте качества
Управление кросс-функциональными процессами
Вульгарное представление о кросс-функциональных бизнес-процессах
Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:
Рис. 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. Оптимизация вспомогательных процессов
Все сказанное выше относилось к основным процессам, качество и производительность которых непосредственно отражается на клиентах.
Что касается вспомогательных процессов, то там время исполнения не столь важно, и на первый план выходит экономное расходование ресурсов. Поэтому для вспомогательных процессов асинхронный режим исполнения следует считать основным.
С точки зрения бухгалтерии это будет выглядеть так: балансовая отчетность и расчеты с персоналом ведутся в размеренном ритме, а счета готовятся в режиме немедленного реагирования. Такая организация легко может вызвать протесты и конфликты, так как:
в рамках функционального мышления первые два процесса бухгалтерия будет считать «своими», так как является в них основным исполнителем, и соответственно, будет уделять им внимания больше, чем выписке счетов в рамках «чужого» бизнес-процесса
в процессной же логике дело обстоит иначе: она требует, чтобы к задачам в рамках основных процессов относились как к приоритетным вне зависимости от того, «свой» это процесс или «чужой»