О девочке на шаре и консультанте на кубе

16/04/2011

Quo vadis?

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

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

Чаще всего, работу над бизнес-процессами начинают при проведении проектов  по трансформации бизнеса ­­­­– изменении организационной структуры, оптимизации бизнес-правил и поддерживающих их информационных систем.

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

Помимо шкалы зрелости при оценке функционирования процессов определяют, насколько качественно происходит преобразование входов в выходы:

• Ресурсоёмкость:  сколько ресурсов тратится на один «запуск» процесса
• Себестоимость: как дорого обходится «один запуск процесса»
• Скорость:  сколько времени тратится на отдельные шаги в процессе и на ожидание между шагами
• Качество: как часто возникают несоответствия и претензии потребителей процесса

Также, важным показателем является число запусков процесса в единицу времени. В совокупности с данными о себестоимости подобная информация может послужить основой для внедрения в организации ABС-costing’а.

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

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

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

Создание библиотеки

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

Чтобы совершенно не запутаться в этом клубке на первых же минутах после начала работы, его нужно с самого начала держать под контролем с помощью каталога бизнес-процессов. Каталог бизнес-процессов – во всех отношениях полезный инструмент, без которого не стоит даже думать об успехе начинания. Существуют ли простые и безболезненные способы составления каталога бизнес-процессов? К счастью, да. Во-первых, можно художественно заимствовать готовый каталог в организации American Productivity & Quality Center (APQC), занимающейся измерением эффективности бизнес-процессов и вынужденной такой каталог использовать для своих исследований. Этот каталог хорош тем, что он содержит иерархическую универсальную модель, годную практически для любого вида деятельности. Помимо универсальной модели, можно получить доступ и к отраслевым версиям каталога, разработанным в соавторстве с IBM. В таком каталоге бизнес-процессы разделяются на 4 уровня детализации:

• Уровень 1 – категория:  наивысший уровень иерархии процессов организации, такой, как Управление клиентским сервисом, Цепочка поставок, Управление финансами и др.
• Уровень 2 – группа: набор процессов, логически входящих в категорию. Примеры: Послепродажное обслуживание и ремонт, Закупка запчастей, Оплата поставщиков.
• Уровень 3 – бизнес-процесс:  набор взаимосвязанных шагов, преобразующих входы (ресурсы, информацию) в выходы (результаты процесса). Процесс предполагает наличие стандартов, определяющих его повторяемость во времени.
• Уровень 4 – шаг процесса:  отражают ключевые события, возникающие при выполнении процесса. Примерами могут быть: «Обработать рекламацию клиента», «Заключить контракт на закупку» и т.д.

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

Второй источник информации для создания каталога – это, так называемые, «сквозные» процессы (end-to-end или E2E).  К сожалению, нет общепринятого представления, каким процессам удаётся пробуравить организацию насквозь, а каким нет, но есть более-менее устоявшиеся названия, приведённые ниже:

Хороший каталог сквозных процессов можно получить на сайте Пентагона, посвящённом разработке архитектуры управления вооруженными силами США. Удобством сквозного разделения процессов является то обстоятельство, что их названия точно отражают суть выполняемых шагов и легки для запоминания. С другой стороны, сквозные процессы позволяют разделить специалистов на команды, соблюдая при этом принцип межфункциональной интеграции, т.к. в команду O2C, например, будут входить специалисты отдела по клиентскому обслуживанию, бухгалтер по дебиторской задолженности, специалисты по логистике, финансисты, специалисты службы контроля качества и другие. Это означает, что один раз создав межфункциональную команду и потратив силы на её интеграцию (несколько походов в боулинг или бар), в дальнейшем можно заметно снизить издержки, связанные с недостаточностью межфункциональных связей, как внутри команды (здесь стоит быть осторожным с характером связей), так и между отдельными проектными группами.

Ещё одним вариантом формирования библиотеки процессов является подход, основанный на концепции жизненного цикла продукции. Например, при разработке нового продукта можно выделить фазы проектирования, подготовки к производству, закупки компонентов и материалов, производства, маркетинга и продаж, сервисного обслуживания, вывода продукта с рынка и фазу утилизации. Эти фазы будут являться группами бизнес-процессов, в которые будут входить отдельные процессы и их шаги.

Ещё одним удобным источником создания каталога бизнес-процессов является специализированный сайт MIT, который содержит разработанную специалистами этого института классификацию процессов, исходя из базовых и специализированных видов деятельности внутри компаний. Подход MIT интересен своей простотой и возможностью применения «процессного компаса» в любых проектах по картированию процессов, независимо от методологии. Смысл «компаса» состоит в том, что все процессы рассматриваются как подвиды более высокоуровневых процессов с одной стороны, а с другой стороны, могут иметь несколько «детей», специализирующихся в разных областях. Работа над процессом предполагает движение от более общего процесса к более частному путём ответов на наводящие вопросы.

Для специалистов в области управления цепочками поставок наибольший интерес представляет модель SCOR, которая использует ту же самую идею описания бизнес-процессов, что и в модели MIT, но ограниченную процессами планирования, закупок, доставки, производства, отгрузки и обратной логистики.

Ещё два источника каталогов бизнес-процессов можно использовать благодаря сайту MIT:

• Lean Enterprise Manufacturing model
• European Foundation for Quality Management (EFQM)

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

Вот тут-то нас встречает первый, как сказали бы геодезисты, пикет на трассе: что за процессы мы собираемся рисовать – фактические «как есть» или воображаемые процессы светлого будущего? Если мы аудиторы и хотим зафиксировать текущую ситуацию, то вопрос исчерпан – «как есть», а если мы собираемся менять ситуацию (искренне полагая, что к лучшему), то как следует поступать? Теоретики говорят, что существует два подхода: рисовать сначала процессы «как есть», потом – «как будет». Практики, хотя бы раз послушавшие теоретиков, более категоричны в своих суждениях: нужно сразу рисовать «как будет», оглядываясь на «как есть», но не более.

Почему так? Представьте себе ситуацию: вы консультант и картируете процессы как есть, затем мучительно применяете методы непрерывных улучшений, ищите «муды», потери, источники неэффективности, возможности параллельной работы, строите диаграммы Ишикавы, устраняете лишнее и получаете идеальный процесс «как будет».

Best practices

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

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

Следует иметь в виду, что в некоторых проектах самая увлекательная для сотрудников работа – это перераспределение ответственности между ролями: как «подбросить» соседнему отделу максимум задач, а самому избавиться от «лишней» ответственности. Если вторую встречу подряд вы занимаетесь перемещением кубиков с шагами между плавательными дорожками, следует немедленно подумать о подключении высшего руководства для арбитража.

Второй вариант организации проекта – сразу приходить к клиенту с готовыми процессами и править их вместе. Это быстрый, но рискованный и требующей высокой квалификации консультантов вариант. Его опасностью является случай, когда, глядя на процесс, клиент безапелляционно заявляет: «Всё не так». Приходится рисовать процесс с нуля, на ходу фантазируя на тему улучшений и вникая в детали. В этом случае, бывает полезно отложить картинки и препарировать бизнес-процесс с помощью «сипоку». Это отнюдь не средневековый обычай, реализуемый с помощью колюще-режущих инструментов, а переиначенная на русский лад аббревиатура SIPOC.

Опыт самураев

Для процесса приёма заказа от клиента карточка SIPOC будет иметь следующий вид:

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

В итоге, идеальной схемой работы по картированию процессов видится следующая:

1. На первой встрече совместно составляется карточка SIPOC, определяются проблемы, которых хотелось бы избежать, цели которых хотелось бы достичь, оцениваются показатели эффективности и трудоёмкости процесса, определяются основные роли в процессе. Далее, обсуждаются исключительные ситуации и варианты процесса. Собираются требования регулирующих органов и имеющиеся у клиента нормативные документы.
2. На вторую встречу консультанты приходят с подготовленными схемами процессов, которые совместно обсуждаются и редактируются (это могут быть схемы «как есть» и «как будет»)
3. По окончании «процессных» сессии, когда библиотека процессов готова, проводится семинар, на котором сотрудники клиента рассказывают, что происходит в процессах, какие готовятся изменения по сравнению с текущей ситуацией, какие ожидаются улучшения. При этом, можно идти от процесса к процессу в логической последовательности или использовать так называемые «сквозные сценарии» (conference room pilot), описывающие всю деятельность компании, чтобы оценить качество «стыковки» разработанных процессов

Перо и кисти

Чтобы подготовиться к встрече №2, необходимо перейти к составлению графической карты шагов или к их более детальному текстовому описанию. «Конечно же, нужна картинка с кубиками!» – воскликнете вы и будете далеки от истины. При всей лаконичности графического описания, в нём теряются важные элементы повествования, придающие описанию живость и реалистичность красок: «Поигрывая гаечным ключём, Пётр Сергеевич зашёл в сумеречно-зелёную прохладу цеха, окинул привычным взглядом опилки на луже масла, разбросанный инструмент, милые завитки стружки с фиолетовым отливом и разразился забористой матерной тирадой. Он педантично вспоминал всех мам и бабушек конструкторов, не уделивших достаточного внимания раннему развитию своих чад. Привычным жестом вырвал из рук недоумевающего работяги замызганный машинным маслом чертёж и смял его. Немного помолчав, выудил из брюк новёхоньких документ, уже пропахший мужичиной и лихо пришпилил его к станине. Взглянув исподлобья на токаря, он кивком попросил снять со станка негодную более заготовку и поплёлся в свой кубрик залить горе потерянных нормочасов и обломившейся квартальной премии». Теперь попробуйте описать тот же самый процесс управления инженерными изменениями в графической форме…

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

Чтобы максимально ёмко передать ход процесса, давайте вспомним, что процесс – это путь, состоящий из шагов-действий к достижению цели. Этот путь лучше всего раскрывается, отвечая на два вопроса: «кто делает шаг», «что происходит на шаге». Несложно обратить внимание, что для наиболее эффективного описания шагов нужно использовать глаголы, чтобы отражать суть деяний и существительные для уточнения деталей. Идеальное описание шага процесса – это комбинация глагола и существительного. Например: получить извещение об изменении, остановить работу по …, изъять устаревшие документы, выдать наряд на работу. Неудивительно, что многие рассмотренные ранее модели выделения процессов базируются на ключевых глаголах (MIT, SCOR, LEM и др.). Второй момент, о котором нужно всегда помнить, это наличие в процессах вариантов их выполнения. Когда вы описываете процесс продаж, всегда полезно помнить, что продажи могут осуществляться за наличный и безналичный расчёт, напрямую и через дилеров, с помощью автоматов по продаже продукции или с помощью автофургонов. Все эти варианты таят в себе важные отличия, которые полезно чётко зафиксировать в своём описании. Обычно, при большом разнообразии вариантов исполнения процесса стараются выделить их общие черты и ключевые отличия. Отличия удобно описывать как отдельные ветки основного процесса или подпроцессы.

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

Пловцы человеков

Выше мы указали, что одним из элементов описания процесса является указание субъекта действия, осуществляющего отдельные шаги. Обычно, это задача решается путём группировки описываемых шагов в соответствии с исполнителем. Такая группировка называется «плавательной дорожкой». Очевидным недостатком плавательных дорожек является тот факт, что они указывают лишь того, кто непосредственно выполняет действие, в то время, как в реальной жизни процессы выполняются несколькими исполнителями с разными полномочиями и степенью ответственности. Чтобы решить эту проблему, описание процесса можно дополнить так называемой RACI-таблицей. RACI – это акроним от Responsible, Accountable, Consulted, Informed. Смысл этого разделения приведён в таблице:

Существуют и другие варианты таблицы, использующие расширенный набор видов ответственности.

На протяжении уже длительного времени мы обсуждаем субъектов, отвечающих за выполнение процессов. Кто же эти мифические персонажи? С одной стороны, это могут быть специалисты, которых  мы указываем, ссылаясь на имя и фамилию. С другой стороны, бизнес-процессы пишутся для определённых функциональных ролей. Функциональная роль может быть как названием должности сотрудника по штатному расписанию, так и отдельной абстракцией, включающей в себя задачи одного или нескольких реальных людей.

Легенды о бизнесе

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

• IDEF – относительно устаревший стандарт, обладающий графическими ограничениями и не очень удобной нотацией
• Блок-схемы – этот формат существует более 50 лет и используется для описания любых алгоритмов. Он прост, удобен и понятен без лишних объяснений, поэтому весьма широко используется в настоящие дни
• EPC (Event Driven Process Chain) – расширение блок-схем, упрощающее описание процессов для целей автоматизации в информационных системах
• Подмножество UML – стандарт для описания деятельности, входящий в группу стандартов, привычных для разработчиков ПО. Не всегда удобен на практике, т.к. требуется определённое время на обучение специалистов клиента
• BPMN – удобный открытый стандарт для описания процессов, постоянно дорабатывается и развивается. На текущий момент выпущена спецификация 2.0

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

1. Клиент и коллеги должны полностью овладеть языком описания и его основными элементами не дольше, чем через час после вводного курса (обычно, это презентация и совместное картирование какой-нибудь рабочей инструкции клиента) и начала использования системы моделирования
2. Не нужно пытаться использовать графические средства для чего-то, отличного от основных шагов, документов и исполнителей. Для описания деталей должно быть предусмотрено текстовое пояснение к графической схеме, содержащее все необходимые сведения. Это особенно актуально для BPMN, где предусмотрено значительное число графических средств, напрямую не относящихся к задаче картирования шагов процесса
3. Нужно очень чётко продумать, стоит ли в графических схемах заострять внимание на синхронизации шагов (выполняемых параллельно или последовательно), информационном обмене в компьютерных системах, событиях и прочих элементах описания, усложняющих общее восприятие схем

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

Расчехляем инструмент

Инструменты для картирования процессов входят в класса систем, называемых BPM (Business Process Management), на рынке их существует великое множество – от графических редакторов до мощных распределённых систем с возможностью создания единого банка моделей. Где-то в середине этого функционального диапазона находится инструмент для быстрого старта команды «картографов» процессов под названием BizAgi Process Modeler. Основное достоинство, помимо очевидной бесплатности, – это возможность использования упрощённого режима картирования процессов в формате BPMN, русскоязычный интерфейс и гибкие средства выгрузки описаний процессов (в том числе, в платную BPM-систему BizAgi для «исполнения» спроектированных процессов). Из негативных свойств этого инструмента: «задумчивость» при работе с большими картами процессов, некоторая нестабильность, требующая регулярного сохранения незавершённой работы, не всегда корректный импорт диаграмм из формата Visio и проблема с экспортом в pdf-формат кириллицы (в версии 1.6.1.0).