Когда говорят о картировании бизнес-процессов, в голове всплывают сложные схемы, утыканные стрелочками, шагами-кубиками, ромбиками с описанием решений, плавательными дорожками и множеством других, не менее полезных символов. Давайте воспарим над этим, смею предположить, привычным представлением о процессах и порассуждаем на тему того, зачем и кому нужны описания и карты бизнес-процессов, каким образом будет происходить сбор информации для анализа процессов, с какой детальностью и широтой, с помощью каких средств будет осуществляться работа над процессами?
Описания бизнес-процессов, как и положено хорошим картам, отражают тропинки и пути, дорожки, мостики и преграды к достижению целей, которые стоят перед организацией. Способность организации достигать целей является мерой её эффективности и, очевидно, важнейшей информацией для высшего руководства. Помимо высшего руководства потребителями информации о бизнес-процессах могут быть как руководители различного ранга, осуществляющие преобразования операционной деятельности (оптимизацию штатного расписания, изменения документооборота и т.д.), так и рядовые сотрудники, читающие свои рабочие инструкции.
Чаще всего, работу над бизнес-процессами начинают при проведении проектов по трансформации бизнеса – изменении организационной структуры, оптимизации бизнес-правил и поддерживающих их информационных систем.
По определению, бизнес-процессом является повторяемая, управляемая владельцем процесса, стандартизованная деятельность исполнителей, направленная на преобразование входов (ресурсов и информации) в выходы, т.е. результаты деятельности. Повторяемость и стандартизованность процессов лежат в основе многочисленных шкал оценки зрелости процессов в организациях. Приведённой ниже шкалой пользуются как для определения текущего состояния процессов, так и для задания операционных целей организации.
Характеристика процесса | Описание |
---|---|
Идентифицируем | Процесс имеет реактивный характер, исполнители и ход процесса меняются в зависимости от ситуации |
Повторяем | процесс явно выделен в организации, зачастую унифицирован, распределены постоянные роли между участниками |
Документирован | процесс в определённой мере автоматизирован и документирован, отслеживается эффективность исполнения |
Измерим и управляем | цели процесса увязаны со стратегией компании, метрики процесса определены и отслеживаются, эффективность процесса прогнозируема |
Оптимизирован | используется методология непрерывных улучшений, высокий уровень автоматизации позволяет пробовать и внедрять новые управленческие технологии |
Помимо шкалы зрелости при оценке функционирования процессов определяют, насколько качественно происходит преобразование входов в выходы:
Также, важным показателем является число запусков процесса в единицу времени. В совокупности с данными о себестоимости подобная информация может послужить основой для внедрения в организации ABС-costing’а.
С описанием процессов связаны проекты по организационному проектированию, когда в результате анализа действий исполнителей, количества шагов, приходящихся на одну роль, количества транзакций, возникающих в процессах, принимаются решения о штатном расписании, механизмах оценки эффективности персонала и компенсационных выплатах сотрудникам.
Рано или поздно каждая организация приходит к пониманию того, что как внутри организации, так и во внешнем мире существуют риски, которые могут нанести финансовый ущерб, парализовать операционную деятельность или вызвать кризис общественного доверия. Существуют методы, позволяющие эти риски отслеживать и предотвращать. Очевидно, что задача решается с помощью создания реестра рисков, и определения ответственных за их мониторинг и предотвращение. Этот реестр преобразуется в отдельные шаги бизнес-процессов, контрольные процедуры, которые позволяют либо осуществить раннее оповещение о наступлении событий, связанных с рисками, либо такие риски предотвратить вовсе.
При подготовке технического задания или спецификации на программное обеспечение, шаги бизнес-процессов являются инструментом для определения требований к системе. Для каждого шага определяется, в какой системе он будет выполняться, какие системные роли его будут исполнять, какой модуль системы будет реализовывать бизнес-логику и какие настройки необходимо выполнить в конфигурации.
Выше было сказано, что бизнес-процессы отражают способы достижения целей организации. Они являются своеобразными удавами, в голове которых находится бизнес-цель, а туловище составляет путь из 38 попугаев. Так как целей у организации, обычно, несколько и для полноты картины они могут противоречить друг другу, совокупность бизнес-процессов представляет собой настоящую голову Горгоны.
Чтобы совершенно не запутаться в этом клубке на первых же минутах после начала работы, его нужно с самого начала держать под контролем с помощью каталога бизнес-процессов. Каталог бизнес-процессов – во всех отношениях полезный инструмент, без которого не стоит даже думать об успехе начинания. Существуют ли простые и безболезненные способы составления каталога бизнес-процессов? К счастью, да. Во-первых, можно художественно заимствовать готовый каталог в организации American Productivity & Quality Center (APQC), занимающейся измерением эффективности бизнес-процессов и вынужденной такой каталог использовать для своих исследований. Этот каталог хорош тем, что он содержит иерархическую универсальную модель, годную практически для любого вида деятельности. Помимо универсальной модели, можно получить доступ и к отраслевым версиям каталога, разработанным в соавторстве с IBM. В таком каталоге бизнес-процессы разделяются на 4 уровня детализации:
Приведённая степень детализации, обычно, вполне достаточна для подготовки компании к внедрению информационной системы или для оптимизации её деятельности. Наиболее употребляемой на практике договорённостью о детальности является следующая: один шаг – это одно законченное действие одной роли над одним документом. Под ролями, при этом, понимаются либо целые отделы, либо функциональные специалисты.
Второй источник информации для создания каталога – это, так называемые, «сквозные» процессы (end-to-end или E2E). К сожалению, нет общепринятого представления, каким процессам удаётся пробуравить организацию насквозь, а каким нет, но есть более-менее устоявшиеся названия, приведённые ниже:
Order-to-cash | O2C | От получения заказа клиента до его исполнения и оплаты клиентом |
Plan-to-produce | P2P | От планирования до производства |
Procure-to-pay | Pr2P | От формирования потребности до оплаты поставки |
Hire-to-retire, Hire-to-fire | H2R | От приёма на работу до увольнения (пенсии) |
Record-to-report | R2R | От проводки до бухгалтерской отчётности |
Acquire-to-retire | A2R | От получения оборудования до его списания |
Concept-to-Product | C2P | От идеи до вывода продукта на рынок |
Хороший каталог сквозных процессов можно получить на сайте Пентагона, посвящённом разработке архитектуры управления вооруженными силами США. Удобством сквозного разделения процессов является то обстоятельство, что их названия точно отражают суть выполняемых шагов и легки для запоминания. С другой стороны, сквозные процессы позволяют разделить специалистов на команды, соблюдая при этом принцип межфункциональной интеграции, т.к. в команду O2C, например, будут входить специалисты отдела по клиентскому обслуживанию, бухгалтер по дебиторской задолженности, специалисты по логистике, финансисты, специалисты службы контроля качества и другие. Это означает, что один раз создав межфункциональную команду и потратив силы на её интеграцию (несколько походов в боулинг или бар), в дальнейшем можно заметно снизить издержки, связанные с недостаточностью межфункциональных связей, как внутри команды (здесь стоит быть осторожным с характером связей), так и между отдельными проектными группами.
Ещё одним вариантом формирования библиотеки процессов является подход, основанный на концепции жизненного цикла продукции. Например, при разработке нового продукта можно выделить фазы проектирования, подготовки к производству, закупки компонентов и материалов, производства, маркетинга и продаж, сервисного обслуживания, вывода продукта с рынка и фазу утилизации. Эти фазы будут являться группами бизнес-процессов, в которые будут входить отдельные процессы и их шаги.
Ещё одним удобным источником создания каталога бизнес-процессов является специализированный сайт MIT, который содержит разработанную специалистами этого института классификацию процессов, исходя из базовых и специализированных видов деятельности внутри компаний. Подход MIT интересен своей простотой и возможностью применения «процессного компаса» в любых проектах по картированию процессов, независимо от методологии. Смысл «компаса» состоит в том, что все процессы рассматриваются как подвиды более высокоуровневых процессов с одной стороны, а с другой стороны, могут иметь несколько «детей», специализирующихся в разных областях. Работа над процессом предполагает движение от более общего процесса к более частному путём ответов на наводящие вопросы.
Для специалистов в области управления цепочками поставок наибольший интерес представляет модель SCOR, которая использует ту же самую идею описания бизнес-процессов, что и в модели MIT, но ограниченную процессами планирования, закупок, доставки, производства, отгрузки и обратной логистики.
Ещё два источника каталогов бизнес-процессов можно использовать благодаря сайту MIT:
Итак, мы во всеоружии, имеем на руках список процессов, крепко спаянную вечерними похождениями команду, жаждущую применить свои глубокие знания и остро оточенные умы на деле. Остаётся начать на намеченной территории составление карт процессов.
Вот тут-то нас встречает первый, как сказали бы геодезисты, пикет на трассе: что за процессы мы собираемся рисовать – фактические «как есть» или воображаемые процессы светлого будущего? Если мы аудиторы и хотим зафиксировать текущую ситуацию, то вопрос исчерпан – «как есть», а если мы собираемся менять ситуацию (искренне полагая, что к лучшему), то как следует поступать? Теоретики говорят, что существует два подхода: рисовать сначала процессы «как есть», потом – «как будет». Практики, хотя бы раз послушавшие теоретиков, более категоричны в своих суждениях: нужно сразу рисовать «как будет», оглядываясь на «как есть», но не более.
Почему так? Представьте себе ситуацию: вы консультант и картируете процессы как есть, затем мучительно применяете методы непрерывных улучшений, ищите «муды», потери, источники неэффективности, возможности параллельной работы, строите диаграммы Ишикавы, устраняете лишнее и получаете идеальный процесс «как будет».
Возникает риторический вопрос: нужно ли на каждом проекте проделывать такой путь или достаточно пройти его один раз с одним отраслевым клиентом, усреднить результаты, зафиксировать «отраслевую референтную модель» и, в дальнейшем, использовать её как стандарт? Ещё одним аргументом в пользу изначальной разработки процессов «как будет» является следующей подход к совместному созданию процессов: консультант предлагает адаптированный вариант «как будет», а клиент говорит, почему отдельные шаги невозможно реализовать предложенным способом и нужно делать по-другому. Такие сессии проходят гораздо живее, чем «конвульсиумы» экспертов по улучшениям.
Важный момент, как организовать эффективный сбор данных у клиента. Первый вариант – организовать ряд интервью с ключевыми сотрудниками компании и после этого провести второй раунд встреч, на которых будут продемонстрированы откорректированные версии процессов. После этого, обычно, нужен ещё один прогон для синхронизации входов и выходов процессов и определения границ ответственности ролей. Классический подход, дающий хорошие результаты, но несколько затянутый по времени.
Следует иметь в виду, что в некоторых проектах самая увлекательная для сотрудников работа – это перераспределение ответственности между ролями: как «подбросить» соседнему отделу максимум задач, а самому избавиться от «лишней» ответственности. Если вторую встречу подряд вы занимаетесь перемещением кубиков с шагами между плавательными дорожками, следует немедленно подумать о подключении высшего руководства для арбитража.
Второй вариант организации проекта – сразу приходить к клиенту с готовыми процессами и править их вместе. Это быстрый, но рискованный и требующей высокой квалификации консультантов вариант. Его опасностью является случай, когда, глядя на процесс, клиент безапелляционно заявляет: «Всё не так». Приходится рисовать процесс с нуля, на ходу фантазируя на тему улучшений и вникая в детали. В этом случае, бывает полезно отложить картинки и препарировать бизнес-процесс с помощью «сипоку». Это отнюдь не средневековый обычай, реализуемый с помощью колюще-режущих инструментов, а переиначенная на русский лад аббревиатура SIPOC.
Для процесса приёма заказа от клиента карточка SIPOC будет иметь следующий вид:
Suppliers | Inputs | Processes | Outputs | Customers |
---|---|---|---|---|
Поставщики | Входы | Процессы | Выходы | Потребители |
|
|
|
|
|
На выходе из «сипожек» мы получаем верхнеуровневое описание процессов, понимаем, что же в них происходит и, главное, зачем это происходит. Небольшим расширением к классическому варианту «сипожки» в разделе «процессы» является детальное описание шагов с фактическими данными, исключениями и т.д. Такое описание позволит подготовить удобные сценарии использования для разработки программного обеспечения или тестирования информационной системы.
В итоге, идеальной схемой работы по картированию процессов видится следующая:
Чтобы подготовиться к встрече №2, необходимо перейти к составлению графической карты шагов или к их более детальному текстовому описанию. «Конечно же, нужна картинка с кубиками!» – воскликнете вы и будете далеки от истины. При всей лаконичности графического описания, в нём теряются важные элементы повествования, придающие описанию живость и реалистичность красок: «Поигрывая гаечным ключём, Пётр Сергеевич зашёл в сумеречно-зелёную прохладу цеха, окинул привычным взглядом опилки на луже масла, разбросанный инструмент, милые завитки стружки с фиолетовым отливом и разразился забористой матерной тирадой. Он педантично вспоминал всех мам и бабушек конструкторов, не уделивших достаточного внимания раннему развитию своих чад. Привычным жестом вырвал из рук недоумевающего работяги замызганный машинным маслом чертёж и смял его. Немного помолчав, выудил из брюк новёхоньких документ, уже пропахший мужичиной и лихо пришпилил его к станине. Взглянув исподлобья на токаря, он кивком попросил снять со станка негодную более заготовку и поплёлся в свой кубрик залить горе потерянных нормочасов и обломившейся квартальной премии». Теперь попробуйте описать тот же самый процесс управления инженерными изменениями в графической форме…
Надеюсь, мне удалось убедить вас, что текстовый вариант обладает определёнными преимуществами, про которые не нужно забывать, и которые хочется, отчасти, реализовать в графическом варианте.
Чтобы максимально ёмко передать ход процесса, давайте вспомним, что процесс – это путь, состоящий из шагов-действий к достижению цели. Этот путь лучше всего раскрывается, отвечая на два вопроса: «кто делает шаг», «что происходит на шаге». Несложно обратить внимание, что для наиболее эффективного описания шагов нужно использовать глаголы, чтобы отражать суть деяний и существительные для уточнения деталей. Идеальное описание шага процесса – это комбинация глагола и существительного. Например: получить извещение об изменении, остановить работу по …, изъять устаревшие документы, выдать наряд на работу. Неудивительно, что многие рассмотренные ранее модели выделения процессов базируются на ключевых глаголах (MIT, SCOR, LEM и др.). Второй момент, о котором нужно всегда помнить, это наличие в процессах вариантов их выполнения. Когда вы описываете процесс продаж, всегда полезно помнить, что продажи могут осуществляться за наличный и безналичный расчёт, напрямую и через дилеров, с помощью автоматов по продаже продукции или с помощью автофургонов. Все эти варианты таят в себе важные отличия, которые полезно чётко зафиксировать в своём описании. Обычно, при большом разнообразии вариантов исполнения процесса стараются выделить их общие черты и ключевые отличия. Отличия удобно описывать как отдельные ветки основного процесса или подпроцессы.
При описании процессов, обычно, концентрируются на основной деятельности и описывают нормальное течение процесса. Тем не менее, в любой ситуации бывают исключения. О них важно помнить, их важно включать в текстовое описание процессов (не стоит загромождать графические схемы), но нельзя на них «зацикливаться». В моей практике был клиент, которого по какой-то внутренней причине гораздо больше интересовали способы «отлова» и обработки исключений, чем способы выстраивания работоспособных процессов. Следует иметь в виду, что при описании процессов не стоит тратить на исключения более 20% времени, отведённого на сами процессы.
Выше мы указали, что одним из элементов описания процесса является указание субъекта действия, осуществляющего отдельные шаги. Обычно, это задача решается путём группировки описываемых шагов в соответствии с исполнителем. Такая группировка называется «плавательной дорожкой». Очевидным недостатком плавательных дорожек является тот факт, что они указывают лишь того, кто непосредственно выполняет действие, в то время, как в реальной жизни процессы выполняются несколькими исполнителями с разными полномочиями и степенью ответственности. Чтобы решить эту проблему, описание процесса можно дополнить так называемой RACI-таблицей. RACI – это акроним от Responsible, Accountable, Consulted, Informed. Смысл этого разделения приведён в таблице:
Responsible | Непосредственный исполнитель шага |
Accountable | Руководитель исполнителя, отвечающий за результат исполнения шага |
Consulted | Тот, с кем проводятся консультации при выполнении шага и результат выполнения может меняться в зависимости от полученной информации |
Informed | Специалист, которого необходимо ставить в известность о результатах выполнения шага |
Существуют и другие варианты таблицы, использующие расширенный набор видов ответственности.
На протяжении уже длительного времени мы обсуждаем субъектов, отвечающих за выполнение процессов. Кто же эти мифические персонажи? С одной стороны, это могут быть специалисты, которых мы указываем, ссылаясь на имя и фамилию. С другой стороны, бизнес-процессы пишутся для определённых функциональных ролей. Функциональная роль может быть как названием должности сотрудника по штатному расписанию, так и отдельной абстракцией, включающей в себя задачи одного или нескольких реальных людей.
Мы вплотную приблизились к составлению карты процессов, осталось лишь договориться о легенде к ней. На данный момент существует значительное число стандартов графического описания, ссылки на некоторые приведены ниже:
Вы удивитесь, но в реальности совершенно неважно, какой стандарт вы выбрали для проекта, т.к. различия между ними далеко не принципиальны. Важно помнить следующее: богатство выразительных средств стандарта вовсе не предполагает их обязательного употребления. Да-да, лучше взять за правило использовать лапидарный стиль, максимально ограничив подмножество языка моделирования, чтобы добиться следующего:
Итак, мы определили назначение проекта, целевую аудиторию, договорились о каталоге процессов (и границах процессов), стандартах сбора информации и картирования (подготовили документ «Соглашение о моделировании» и его выжимку в виде одностраничной шпаргалки). Осталось выбрать подходящий инструмент для работы.
Инструменты для картирования процессов входят в класса систем, называемых BPM (Business Process Management), на рынке их существует великое множество – от графических редакторов до мощных распределённых систем с возможностью создания единого банка моделей. Где-то в середине этого функционального диапазона находится инструмент для быстрого старта команды «картографов» процессов под названием BizAgi Process Modeler. Основное достоинство, помимо очевидной бесплатности, – это возможность использования упрощённого режима картирования процессов в формате BPMN, русскоязычный интерфейс и гибкие средства выгрузки описаний процессов (в том числе, в платную BPM-систему BizAgi для «исполнения» спроектированных процессов). Из негативных свойств этого инструмента: «задумчивость» при работе с большими картами процессов, некоторая нестабильность, требующая регулярного сохранения незавершённой работы, не всегда корректный импорт диаграмм из формата Visio и проблема с экспортом в pdf-формат кириллицы (в версии 1.6.1.0).