Кросс функциональная диаграмма бизнес процесса

1

Откройте программу веб-сайта

Сначала перейдите на веб-сайт программы, чтобы получить доступ к инструменту. Для этого запустите браузер на своем компьютере и введите название инструмента в адресной строке.

2

Выберите шаблон

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

3

Создайте дорожку для процессов

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

4

Экспортируйте свою окончательную работу

Наконец, сохраните свою работу и загрузите копию. Для этого нажмите кнопку Экспорт кнопку в правом верхнем углу. Затем выберите выходной формат. С другой стороны, вы можете поделиться им с другими, используя ссылку на диаграмму.

Как создать многофункциональную блок-схему в Visio 2010?

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

Есть ли в Excel многофункциональные шаблоны блок-схем?

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

В чем разница между кросс-функциональными блок-схемами и блок-схемами развертывания?

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

Вывод

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

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

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

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

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

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

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

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

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

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

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

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

Та же история с доставкой и расчетами: их вряд ли удастся реализовать в рамках процесса «клиентский заказ». То есть технически процессов (пулов) тут не два, а больше.

Workflow, BPM и многопоточное программирование
Кросс-функциональные процессы невозможно реализовать при помощи workflow, потому что границы между подразделениями существуют не просто так: они разделяют области с разными распорядками работы и разными ритмами. Существование этих границ нельзя игнорировать, и их нельзя ликвидировать, просто изобразив поток работ, переходящий из одного подразделения в другое так, как изображено на рис. 2.

Технически эти задачи решаются при помощи процессных паттернов, один из которых изображен на рис. 3. А на уровне методологическом картинка, изображенная на рис. 1, может выглядеть так:

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

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

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

Технически, многопоточность — это то, что отличает BPM от worflow. Уберите из BPM взаимодействие асинхронно исполняющихся процессов через данные, сообщения и сигналы, и это будет не BPM, а «workflow на стероидах».

К большому сожалению, это относится ко многим современным программным продуктам с агрессивным маркетингом, позиционирующим их как BPMS. Для меня главный критерий полноценной BPMS — это наличие в продукте поддержки сообщений в стиле BPMN. Есть и другие критерии, но этот на практике оказывается самым полезным, так как со всем остальным — графическим моделированием, workflow-движком, веб-порталом, бизнес-аналитикой — лучше или хуже справляются все разработчики, а с поддержкой межпроцессного взаимодействия — единицы. Скорее всего не потому, что это так уж сложно, а потому, что никто не объяснил насколько это важно.

Но сказать «осваивайте многопоточное программирование процессов» легче, чем последовать этому совету. В ответ раздается стон: «какой же сложный этот BPMN, и кто только придумал в нем 50 разных видов событий!».

Сложен не BPMN — сложен бизнес!
Кто бы вам не обещал простые средства решения бизнес-проблем, будь то BPM или что-то другое — не верьте! Бизнес — это конкурентная область человеческой деятельности: талантливые и изощренные люди соревнуются в ней за то, кому будет житься хорошо, а кому — не очень. Поэтому бизнес был, есть и останется делом сложным.

Сложность BPMN не чрезмерна — она адекватна сложности бизнеса. У слушателей моего тренинга по BPMN не остается вопроса зачем столько событий: все нужны! И кстати, обратите внимание: в части workflow BPMN 2.0 практически не отличается от 1.x — стандарт развивается в направлении более изощренной поддержки многопоточного программирования: choreography, conversation.

Если бизнес и можно запрограммировать, то только как многопоточную систему.
BPM и ACM

Тут я сознательно ступаю на скользкую почву, так как предвижу реакцию адептов ACM (Advanced/Adaptive Case Management): «Ага! Мы всегда говорили, что бизнес в принципе нельзя запрограммировать!»

Может быть можно, может быть нельзя: Скорее всего, в каких-то случаях можно, а в каких-то нет.

Вот говорят, что доля knowledge work постоянно растет. Но где именно она растет? В США, активно выводящих всю рутинную деятельность в Азию. Вот и сообщают нам сидящие в США аналитики о своих вполне прогнозируемых наблюдениях. Но ведь насколько выросла доля knowledge work в одном месте, ровно настолько же выросла доля routine work в другом. А управлять рутинными процедурами, исполняющимися на другом конце глобуса — это ведь самая подходящая для BPM задача.

В свете вышеизложенного я хотел бы поинтересоваться у критиков BPM из числа адептов ACM: вы уверены, что критикуете BPM, а не wokflow? Не являются ли объектом вашей критики BPM-проекты, в которых либо пытались решать задачи бизнеса, не выходя за рамки workflow, либо бизнес-проблематика вообще отсутствовала?

Потому что в этом случае их провал предсказуем, но он вовсе не означает, что BPM указывает неверный путь. Просто тщательнее надо работать.

Что касается ACM, то это безусловно вещь полезная, но только как дополнение к BPM, а не как замена. Плюс к этому, ACM на сегодняшний день вещь менее зрелая, чем BPM, и поэтому тот, кто наломал дров с BPM, с ACM скорее всего наломает дров еще больших.

Воспользуемся следующим примером:

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

В простейшем виде процессная диаграмма может выглядеть так:

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

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

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

Схема процесса для такого алгоритма действий:

Как видим, в этой схеме разделены процессы обработки счета, планирования оплаты и собственно оплаты. Это дает возможность планировать разные ресурсы или один и тот же ресурс, но на разные даты: например, финансовый директор может запланировать платежи на сегодня и на завтра. Процесс оплаты дождется наступления заданного времени (таймер на схеме) и произведет оплату всех счетов.

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

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

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

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

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

Звенья, не являющиеся «бутылочным горлышком», изображены зеленым цветом, за исключением второго с конца по производительности звена — в данном примере это производственный участок, его мы покрасили желтым. Он определяет, на сколько можно повысить производительность процесса только за счет увеличения производительности «бутылочного горлышка»: в данном примере с 60 до 80, т.е. на 33%.

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

Согласно Теории ограничений, буфер следует организовать перед «бутылочным горлышком», но только в этом единственном месте: дополнительные буфера не повысят производительность, а только приведут к лишним затратам.

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

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

2. Ограничение на входе системы
В рассмотренном выше примере производительность участка приема заказов есть число заказов, которые он способен принять и обработать в единицу времени. Не следует путать этот показатель с потенциальным спросом, т.е. числом заказов, на которое мы в принципе можем рассчитывать. Предположим, что спрос меньше, чем производительность нашего процесса:

В рассматриваемом примере запас производительности процесса относительно спроса составляет 20%. Если спрос колеблется в этих пределах, то синхронная схема будет предпочтительной; если больше, то есть смысл вернуться к схеме на рис. 12.

К сожалению, рассмотренные линейные модели слишком просты, чтобы полученные выводы можно было непосредственно использовать на практике. В жизни есть как минимум два источника нелинейностей: старты и переналадки.

3. Влияние стартов
Синхронный режим работы является таковым с точки зрения процесса, а с точки зрения исполнителя (ресурса) вовсе наоборот:

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

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

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

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

Чем меньше таких переключений, тем меньше затраты на «умственную переналадку» и следовательно, тем выше ваша индивидуальная производительность. Уменьшить число переналадок можно за счет асинхронной обработки.

Проиллюстрируем это простейшим примером: пусть вам на вход поступают задачи двух видов: А и Б —

Выполнять однотипные задачи всегда легче. Может быть для двух типов задач это не так очевидно, но что если их десятки? Это объясняет, почему финансовый директор скорее всего предпочтет, чтобы заявки на оплату поступали к нему не по одному, а списком.

5. Рекомендации по оптимизации с учетом нелинейных факторов
Итак, в синхронном режиме время исполнения процесса минимально (хорошо), но этот режим сопряжен со снижением производительности из-за стартов и переналадок (плохо).

В результате мы можем получить, например, такую картину:

Снижение производительности на участке дизайна привело к тому, что он стал узким местом — его производительность стала ниже уровня спроса. Простейший способ справиться с этой проблемой — вернуться к асинхронной схеме работы, изображенной на рис. 12. Мало того, из-за снижения производительности на участке производства он тоже «провалился» ниже уровня спроса — следовательно, его тоже надо перевести на асинхронный режим.

Но переход от синхронного режиму к асинхронному — только один из возможных вариантов действий. Другой предлагает система Тойоты: не компрометировать качество (не увеличивать продолжительность процесса), а сокращать время, затрачиваемое на старты и переналадки.

То есть, применительно к работе, выполняемой людьми:

Конечно, всему есть предел, и если тот или иной руководитель или специалист реально перегружен, то ему как раз надо создать такую комфортную зону.

Однако в большинстве случаев это не так. Но тут, чтобы добиться успехов, необходимо учитывать психологические факторы:

В конечном итоге, все зависит от мотивации: когда в маленькую компанию звонит клиент, то никому не надо объяснять, что клиент — это главное, а все остальные дела могут подождать. А в большой компании? «Если мой звонок так важен для вас, то черт возьми, возьмите наконец трубку!» Но эта тема уже выходит за рамки данной статьи.

6. Оптимизация вспомогательных процессов
Все сказанное выше относилось к основным процессам, качество и производительность которых непосредственно отражается на клиентах.

Что касается вспомогательных процессов, то там время исполнения не столь важно, и на первый план выходит экономное расходование ресурсов. Поэтому для вспомогательных процессов асинхронный режим исполнения следует считать основным.

Если посмотреть в разрезе ресурсов, то они, как правило, задействованы и в основных, и во вспомогательных процессах. Например, бухгалтерия является основным исполнителем во вспомогательных процессах сдачи баланса и расчетов с персоналом, а кроме того, бухгалтерия готовит счета покупателям в рамках основного процесса продажи. В соответствии с изложенными выше принципами, задачи в рамках сдачи баланса и расчетов с персоналом должны выполняться в асинхронном режиме, а выписка счета — синхронно (при условии, что бухгалтерия объективно не является «бутылочным горлышком», что маловероятно).

С точки зрения бухгалтерии это будет выглядеть так: балансовая отчетность и расчеты с персоналом ведутся в размеренном ритме, а счета готовятся в режиме немедленного реагирования. Такая организация легко может вызвать протесты и конфликты, так как:

В мировой практике наибольшее распространение получили следующие нотации описания БП:

· Процессные диаграммы

· Кросс-функциональные диаграммы

· Бизнес-графика

· IDEF 0 диаграммы

· Нотации консалтинговых компаний.

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

Кросс-функциональные диаграммы: отличие от процессной в том, что блоки уже привязаны к подразделениям. Может быть вертикальной и горизонтальной. Выбор направления зависит от стандарта предприятия или вкуса разработчика Процедуры.

Процедура отображает детальный алгоритм выполнения бизнес-процесса, а так же всех участников бизнес-процесса и как они взаимодействуют между собой в рамках Процедуры. Дорожка на диаграмме означает должность, подразделение и роль. На дорожках Процедуры размещаются действия, за которые и отвечает должность, подразделение, роль. Каждое действие может быть декомпозировано (разбито на более детальные бизнес-процессы) в нотациях Процедура, EPC или Процесс.

Действия на дорожках связаны между собой информационными или материальными потоками.

Так же могут использоваться решения (условия) для ветвления бизнес-процесса.

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

Преимущества значительные, т.к. нотация является очень простой для создания и пониманиями сотрудниками с разным уровнем подготовки.

Основные потребители – сотрудники разных уровней организации.