Порядок описания бизнес процессов. Бизнес-процессы: примеры и описание

Выделяют, так называемое, вертикальное и горизонтальное описание бизнес-процессов.

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

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

Рисунок 1.2 «Горизонтальное и вертикальное описание бизнес-процессов»

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

Способы описания бизнес-процессов.

Давайте рассмотрим основные подходы к горизонтальному описанию бизнес-процессов. В настоящее время существуют три основных способа описания (рис. 1.3).

Первый способ - есть не что иное как текстовое последовательное описание бизнес-процесса. Примером текстового описания фрагмента бизнес-процесса является следующий текст: «Отдел продаж составляет договор купли-продажи и согласует его с Юридическим отделом».

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

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

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

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

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

Рисунок 1.3 «Способы описания бизнес-процессов»

Описание окружения бизнес-процесса.

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

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

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

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

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

Рисунок 1.4 «Схема окружения бизнес-процесса»

Классификация входов и выходов бизнес - процесса.

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

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

Таблица 1.1 - «Характеристики первичных и вторичных входов и выходов бизнес-процесс»

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

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

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

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

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

Описание бизнес-процессов верхнего уровня.

Классический подход к описанию бизнес-процессов.

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

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

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

Согласно классическому подходу стандарт DFD, который расшифровывается как Data Flow Diagram представляет из себя диаграмму потоков данных, которая используется для описания бизнес-процессов верхнего уровня. В свою очередь стандарт WFD расшифровывается как Work Flow Diagram и представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеются и другое название - диаграмма алгоритмов.

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

Построение диаграмм потоков данных - DFD

Стандарт описания бизнес-процессов DFD - Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня.

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

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

Рисунок 1.5 «Диаграмм потоков данных - DFD»

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

Рисунок 1.6 «Пример несовпадения временной последовательности

работ и направления движения документа»

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

Рисунок 1.7 «Пример бизнес-процесс верхнего уровня»

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

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

Правило 1. Названия работы нужно формулировать согласно следующее формуле.

Название работы = Действие + Объект на которым действие осуществляется

Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать <Продажа продукции>, а еще лучше конкретизировать что это за продукция. В данном случае <Продажа> это действие, а <продукция> - объект над которым действие по продаже производится.

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

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

Название потока = Объект, представляющий поток + Статус объекта

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

Построение сети бизнес-процессов.

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

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

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

Рисунок 1.8 «Разработка сети бизнес-процессов»

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

На практике сеть процессов часто называют сетью или схемой взаимодействия бизнес-процессов. Отличие сети процессов от классической схемы DFD состоит в том, что на сети нужно показать внешние субъекты, с которым взаимодействуют бизнес-процессы компании - клиенты, поставщики, банки и др. На рис. 1.9 приведен пример сети бизнес-процессов для производственной компании.

Рисунок 1.9 «Пример сети бизнес-процессов»

Описание бизнес-процессов нижнего уровня.

Декомпозиция бизнес-процесса.

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

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

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

В случае необходимости работы на схеме процесса второго уровня могут быть декомпозированы на схемы бизнес-процессов третьего уровня и т.д. Декомпозиция бизнес-процесса должна продолжаться до тех пор, пока не будут достигнуты цели его описания. В данном случае удобно использовать понятия вложенный процесс или подпроцесс. На рис. 1.9 процессная схема работы 3 является вложенным процессом или подпроцессом процесса верхнего уровня. Аналогичным образом процессные схемы работ 3.1 и 3.4 являются вложенными процессами или подпроцессами процесса второго уровня.

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

Построение диаграммы потоков работ - WFD

При описании бизнес-процессов нижнего уровня используются немного другие процессные схемы, под названием WFD - Work Flow Diagram, что переводится как диаграмма потоков работ. На этой схеме появляются дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки (рис. 1.11).

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

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

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

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

Рисунок 1.11 «Диаграмма потоков работ - WFD»

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

Итак с помощью двух классических схем DFD и WFD можно описать подробно все бизнес-процессы компании.

Станислав Тульчинский

Генеральный директор и партнер ООО «b2b.Технологии развития»

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

С чего чаще всего начинается

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

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

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

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

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

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

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

Несколько замечаний по постановке задачи

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

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

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

Третьей проблемой является надежда на то, что новая программа MRP, ERP, CRM, SCM, BPM, DFM и т. д. и т. п. (зачастую флагман западной экономики), которая (со слов ее продавцов) является неиссякаемым источником мудрости и референсных моделей бизнеса, после внедрения сотворит чудо. И бизнес сам изменится в «правильную» сторону. Увеличатся доходы, будут выбраны правильные сегменты рынка, сократятся издержки и конфликты между сотрудниками. Но, как говорят продавцы «волшебной» программы, для того, чтобы ее внедрить, надо описать процессы.

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

Важное замечание про оптимизацию

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

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

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

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

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

Переход на новые (оптимизированные) процессы

Как уже было сказано, описание бизнес-процессов, скорее всего, приведет к тому, что в компании нужно будет что-то изменить. Либо сам сложившийся уклад деятельности сотрудников, их взаимоотношений, порядок общения, либо продукты/услуги, либо рынки, либо клиентов компании, а скорее всего в некоей пропорции все из описанного. И очень часто это становится неприятной новостью. Описанные бизнес-процессы сами по себе не работают. А сам заказчик, сотрудники компании, и, тем более, менеджеры компании не готовы и не стремятся к тому, что-то еще надо сделать. Действительно, ведь плохо или хорошо, но компания работает, что-то зарабатывает, а что будет, если все поменять? Никто не знает. А это усугубляет то, что первоначальная задача «просто описание бизнес-процессов » точно не включает в себя разработку программы по переходу на новые процессы, программы управления бизнес-процессами в дальнейшем. Бытует упрощенное мнение: «примем одним приказом по компании новые регламенты с первого числа, и все заработает». К моменту окончания описания процессов становится понятно, что приказом не получится. Изменений много, не все их понимают, не все к ним готовы, не хватает многих составных частей для перехода (например, надо поменять ИТ систему, внести изменения в инструменты, оснастку, инфраструктуру, переобучить персонал). И инвестиции в описание и оптимизацию бизнес-процессов списываются на убытки.

Выбор инструментария и методологии для описания процессов

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

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

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

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

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

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

Поверхностный анализ Интернета показывает, что данная тема (выбор методологии и инструментария) недостаточно освещена (анализ META Group мало того, что больше ориентирован на IT-решения, так еще и практически не учитывает особенностей Российского рынка, рассматривает только типичных представителей сложившегося западного рынка). Наиболее часто встречаются статьи сравнения методологий ARIS и IDEF. Другой наиболее распространенной темой является перечисление сильных и слабых сторон (обычно методологий) без учета того, применительно к какой задаче эти качества анализируются. Становится несколько странно: неужели, например, грузоподъемность грузовика всегда является неоспоримым преимуществом, независимо от того, для чего я выбираю машину?

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

• CA ERwin Data Modeler (ранее называвшийся AllFusion Data Modeler, BPwin). Наиболее удачно реализована возможность описания взаимосвязанных сложных моделей, задачи описания алгоритмов и последовательности действий реализованы заметно слабее. Простые (лаконичные) нотации описания. Сложно, либо вообще никак не реализуются дополнительные задачи (увязка целей и процессов, создание дерева показателей, проведение имитационного моделирования);
• ARIS (набор программных обеспечений, модулей компании IDS Scheer). Само название (Architecture of Integrated Information Systems) говорит о том, что программное обеспечение изначально было ориентировано на решение задачи описания алгоритмов и последовательности действий. Все остальное в ARIS тоже можно делать, но это будет получаться очень непросто. Для описания бизнес-процессов придётся использовать большое количество моделей (в ARIS их более 80, и количество их растет) достаточно сложной семантики, в которой путаются даже наиболее ярые адепты. Без большого опыта и существенного переосмысления основ методологии реализовать сложные описания взаимосвязанных моделей непросто;
• Corporate Modeler (Casewise Systems) во многом является английским более юным аналогом ARIS — не по методологии и решениям, но по самим идеям 1 ПО. Также ориентировано на помощь в описании бизнес-процессов для последующей разработки программного обеспечения. Но стоит оно в среднем дешевле;
• iGrafx Enterprise Central (подразделение Corel Inc) пока менее известное в России, но очень симпатичное решение из Канады. Включает в себя целый набор модулей по описанию, моделированию процессов, приложения по планированию и управлению качеством управлением рисками. Существенным ее минусом является ее нераспространённость;
• Business Studio (ГК «Современные технологии управления»). Наиболее известная российская разработка из семейства рассматриваемого ПО. Пожалуй (на наш частный взгляд), удачно совмещает (насколько это возможно) некоторые наиболее полезные возможности BPwin и ARIS, чем-то напоминая по своему решению iGrafx (но не по стоимости). Если для заказчика важно соотношение цена/возможности, наверное, это оптимальный выбор для российских предприятий. Имеет один недостаток, так как очень плотно интегрирована с MS Office (Word, Excel, Visio), а поэтому все шероховатости этих решений автоматически переносятся и на Business Studio.

Что может получить заказчик

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

• Из умной книги (ведь «еще Портер писал что-то про это, а у нас этого нет!») или во время обучения, например, на ставшей сейчас модной степени МВА;
• От ИТ директора или продавцов дорогих информационных систем («эта программа точно решит все проблемы, посмотрите на список успешных компаний, которые ее используют, в этом есть заслуга программы, но для ее внедрения надо описать процессы»);
• От молодого и энергичного зама, который тоже ее где-то услышал и успешно «продал программу для бизнес-процессов » своему шефу, не донеся самых главных ее нюансов.

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

В первом исполнитель без лишних вопросов, нервирующих заказчика, добросовестно приступает к описанию процессов. Всех, или тех какие ему предложат: «давайте начнем с процесса выставления подрядчикам и возврата подтверждающих документов, об этом очень просит бухгалтерия». Как правило, при этом используются знакомые и простые нотации описания процедур (или кросс-чарт, или EPC). Работа идет очень споро, без лишних вопросов (описываем, что скажут или как есть). Но в итоге результат получается незамысловатым. Как говорят специалисты ИТ: «при попытке автоматизировать бардак — получается автоматизированный бардак», с процессами получается еще хуже — бардак в квадрате. Описанные процессы, которые описаны именно так, как это происходит в жизни, и на бумаге сложны и запутанны. Следующим шагом исполнитель может попытаться что-либо улучшить (увы, называют это громко — оптимизировать). Но при этом он, как правило, учитывает точку зрения ограниченного круга лиц, не учитывает всех возможных связей с другими процессами, особенностей корпоративной культуры, и потому, по сути, не улучшает ничего. Но при этом потрачено значительное количество времени и ресурсов. После этого, скорее всего, заказчиком принимается решение, что описание процессов не помогло.

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

• В компании нельзя описать процессы «как есть» (а это является аксиомой для компаний, впервые задумавшихся об описании процессов) просто потому, что их в компании зачастую нет. Деятельность выполняется, опираясь на опыт сотрудников (а он у всех разный), решения по задачам принимаются ситуационно (и, следовательно, они тоже не одинаковы в разных случаях). Даже регулярно совершаемые процессы — и те в компании совершаются не так, как думает руководство, а так, как удобно исполнителям (зачастую, совсем не так, как об этом думают руководители). Поэтому надо не описывать, а создавать ряд процессов, как повторяющейся, стандартизированной деятельности;
• При описании процессов выясняется, что существующий бизнес не оптимален по своей сути (например, нет целевых показателей, часть необходимой деятельности не выполняется, а часть выполняется неоптимальным способом, неверная система мотивации, отсутствует грамотный учет затрат);
• Бизнес существенно подвержен внешним и/или внутренним рискам;
• При описании бизнес-процессов потребуется провести существенные изменения в модели бизнеса (например, в зонах ответственности, выполняемых задачах, взаимоотношениях между подразделениями и людьми, системе мотивации).

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

Не лучшее решение

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

• Несостоявшийся заказчик не потратил времени и средств в погоне за миражом. Более того, к моменту, когда он, возможно, созреет в понимании того, зачем ему на самом деле нужно описание бизнес-процессов, у него не будет прошлого негативного опыта, который может тянуть его камнем на дно, не давая запустить ту работу, которая может принести ему пользу;
• Несостоявшийся исполнитель не получит денег за работу, но при этом он не получит и заведомо проблемный проект, который не отнимет существенную часть его жизни, нервов, репутации, а позволит заняться ему чем-то более полезным. А несостоявшееся сотрудничество станет возможным, когда несостоявшийся заказчик созреет для проведения работ.

Хотя, конечно, это скорее удовлетворительное решение, которое минимизирует сиюминутные риски, но не приносит никому выигрышей на более длительном горизонте. Более удачное решение требует несколько большего, чем умение описывать бизнес-процессы. В любом случае, описание бизнес-процессов — это задача, которая требует не только опыта и знаний от непосредственного исполнителя, но и знаний, готовности и желания пройти этот непростой путь от заказчика.

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

• Определить какие именно бизнес-задачи (бизнес-показатели) бизнес хочет улучшить. Чего на самом деле заказчик хочет достичь, задумывая изменения в своем бизнесе? Для этого, вполне возможно, нужно будет переосмыслить видение бизнеса;
• Определить критерии оптимизации для бизнес-процессов: что компания хочет в них улучшить и насколько улучшить. Важным моментов в этой задаче будет осмысление явных (не мнимых) ограничений — что в организации определенно неприемлемо, а что точно менять нельзя;
• Определить программу действий по достижению поставленных целей, которая может включать в себя описание бизнес-процессов, а может и не включать. Обязательно детально проработать в программе действия по переходу на новые (оптимизированные) процессы;
• Выбрать достаточный для выбранной программы действий и поставленных целей необходимый набор инструментов (прежде всего, потребное программное обеспечение), которое лучшим образом соответствует поставленным целям;
• Только после того, как описанная в первых пунктах работа проделана, поискать достойных исполнителей для поставленной задачи.

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

1 «Для каждого существующего продукта будет разработан такой же аналог, интегрируемый с решениями SAP. Этим будет заниматься отдельное подразделение в нашей компании. Поэтому, можно сказать, что мы выходим на новый сегмент рынка в мировом масштабе — нашими клиентами станут заказчики SAP». Из интервью Бернарда Фишера, Президента компании Casewise.

Ковалев Сергей Михайлович
Ковалев Валерий Михайлович
(Журнал "Консультант директора", № 12, Июнь, 2004 г.)

Семь "золотых" правил описания бизнес-процессов

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

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

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

Правило 1. Составляйте, уточняйте, подтверждайте схемы вместе с "владельцами"/"участниками" бизнес-процессов.

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

Правило 2. Используйте визуальные подходы описания бизнес-процессов, способствующие повышению эффективности работы в группе.

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

Правило 3. Используйте язык, понятный "владельцам"/"участникам" бизнес-процесса.

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

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

При описании бизнес-процессов нужно "забыть" про существующую организационную структуру и не использовать ее как средство выделения бизнес-процессов и работ. Бизнес-процессы строятся на основе стратегии, а организационная структура подстраивается под них, но не наоборот. Именно поэтому организационная структура описывается и накладывается на бизнес-процессы в последний момент. Факт того что, она будет не состыковываться с процессами говорит об ее неоптимальности. Если пренебречь этим правилом и в качестве средства выделения бизнес-процессов и работ использовать действующую оргструктуру, то вероятность того, что разработанные описания бизнес-процессов будут искажены в случае неоптимальной организационной структуры достаточно велика.

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

Правило 5. Избегайте излишней детализации бизнес-процессов, особенно на схеме "как есть".

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

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

Правило 6. Избегайте составления схемы бизнес-процесса ради схемы, не ведущей к дальнейшему анализу и действиям.

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

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

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

Правило 7. Не смешивайте понятия "как есть", " как должно быть", "как будет".

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

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

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

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

Итак, определяем процесс , который нужно описать. Далее

- собираемся с ответственным за процесс и основными участниками/ экспертами (до 3 человек);
- определяем границы процесса, участников, входы/ выходы, этапы процесса – блоки, на которые разбиваем процесс и результаты этих этапов;
- договариваемся и в итоге рисуем такую схему процесса:

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

В описании мы используем обозначения:

В результате схема процесса (этапа) выглядит так:

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

Схема, нарисованная в MS Visio, - это уже окончательный вариант. Вся суть в ее создании. И главное здесь – вовлечение непосредственных участников процесса.

Мы описываем процесс так:

1. Организуем рабочее совещание участников процесса и экспертов;

2. Готовим «клейкую стену» , карточки формата A5, маркеры;

3. Определяем модератора, который ведет дискуссию, пишет и клеит карточки на стену;

4. Размечаем горизонтальные строки малярным скотчем;

5. Определяем участников процесса, записываем на карточках и клеим слева на стене в соответствующих строках;

6. Определяем (подтверждаем) вход/ выход процесса (желтые карточки);

7. Участников разбиваем на две группы, каждая группа обсуждает и пишет на карточках действия процесса от «входа» до «выхода». Раскладывает на столе;

8. По очереди берем от каждой группы по одной карточке, начиная от «входа» процесса; определяем, кто его выполняет, и наклеиваем на стену, соединяя последовательно малярным скотчем (это стрелки). В ходе этой работы договариваемся о формулировках и использовании различающихся карточек, приводим участников к общей схеме;

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

10. Фотографируем и отдаем на оцифровку.

В итоге получаем схему в MS Visio, как на предыдущем рисунке.

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

Если процесс сложный, действия требуют пояснения или непоследовательны – добавляем страницу с комментариями или пишем их на свободном месте в рамочке прямо на схеме.

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

Личная информация:

Консультировал в области регулярного менеджмента более 70-ти компаний: от 10 до 9.000 человек (включая: холдинги, сети магазинов, фабрики, сервисные компании, строителей, государственных служащих, веб-агентства, интернет-магазины). Ученик Александра Фридмана.

Один из соавторов книги "Социальные технологии Таллиннской школы менеджеров. Опыт успешного использования в бизнесе, менеджменте и частной жизни": http://www.ozon.ru/context/detail/id/140084653/

генеральный директор

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

Конфуций

кому: собственникам, топ-менеджерам, руководителям

Управление процессами через регламенты приводит к управлению «рукой через ногу»

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

• минимизация ошибок со стороны сотрудников;
• стандартизация качества работы;
• ликвидация персоналозависимости;
• возможность каждому сотруднику выполнять работу наиболее эффективным способом.

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

Почему? Сейчас попробую объяснить. Регламент - это описание какой-либо части рабочего процесса (последовательности действий), протекающего в компании: либо процесса целиком, либо нескольких процессов, либо части процесса.

Процесс (синоним “бизнес-процесс”) - это последовательность действий для решения какой-либо типовой задачи (нетиповые задачи относятся к проектам).

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

Процессы делятся на простые и составные. Составные - содержат в себе несколько простых процессов. Ещё бывают сквозные процессы . Так называют процессы, разные этапы которых проходят через несколько отделов компании. В этом обычно и заключается их сложность.

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

В управлении процессами напрямую помогает их графическое и схематичное представление (например, в нотации BPMN). Прежде чем приступить к изучению матчасти, предлагаю разобраться, почему регламентов недостаточно для управления процессами.

Почему регламентов недостаточно

• Далеко не все процессы линейные. Многие имеют множество условий “если…, то…”. Сложно быстро разобраться в “полотенце” текста регламента и понять, как этапы процесса связаны между собой . Например, регламент по подбору сотрудников изобилует подобными развилками почти на каждом этапе. В зависимости от должности соискателя собеседование может проходить удалённо или очно, с привлечением его непосредственного руководителя или без.
• Если процесс проходит через несколько звеньев, возникает проблема “кто ответственен за конечный результат”. В случае сбоев и косяков, сотрудники валят вину друг на друга и на обстоятельства, возникает круговая порука.
• Сотрудники не могут договориться между собой о том, кто выполняет какую работу.
• Из-за низкой наглядности (всё тот же гигантский объём текста регламента) крайне непросто заниматься оптимизацией и развитием процесса .
• Значительны затраты времени сотрудников на чтение, изучение, и понимание общей картины и всех взаимосвязей. Регламент редко описывает процесс целиком. Зачастую процессу, проходящему через несколько отделов, соответствуют разные регламенты.

Введение в управление процессами: в каком виде лучше описать процесс?

Управление процессами - целая наука. Но я буду целенаправленно упрощать многие вещи, чтобы было понятно, как это работает. Если кратко, то суть теории управления процессами в том, что вся деятельность компании может быть разбита на процессы (неожиданно, да?)

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

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

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

Всем этим критериям, по моему мнению, отвечает нотация BPMN (версия 2.0) . Для отрисовки схем рекомендую использовать бесплатную программу Bizagi Modeler .

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

Итого, схемы процессов решают следующие задачи:

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

Не забудьте задать цели оптимизации и подсчитать, насколько изменятся затрачиваемые ресурсы у новой версии процесса!

Ключевая фишка процессного управления - ответственный за весь процесс

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

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

Ответственный за весь процесс (иногда его называют “владелец процесса”) - это руководитель (или сотрудник), который отвечает за доработки и развитие бизнес-процесса; решение глобальных возникающих коллизий и анализ сбоев; помощь и обучение ответственных за копию процесса.

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

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

За развитие процесса и выполнение всех его копий должен отвечать один человек

Таким образом, есть человек, который несёт ответственность за весь процесс (в том числе и за работу ответственных за копии), а есть люди, отвечающие за выполнение копий. В рамках процессного управления ответственные за копии процесса подчиняются “владельцу процесса”, а ответственным в свою очередь подчиняются участники процесса.

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

Алгоритм описания и развития бизнес-процесса с помощью схем и регламентов

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

Этап 1. Нарисовать и согласовать схему процесса

1. Начертите схему процесса совместно с ответственным за развитие процесса и экспертами из числа ответственных за исполнение конкретных копий процесса. Выделите наиболее критичные точки процесса. У каждого процесса и у каждого этапа на схеме есть “вход” и есть “выход”. При написании регламента учтите, что будет подаваться на вход, а что будет результатом работы.
2. Согласуйте схему со всеми участниками процесса или начальниками подразделений участников.

Пример №1. Схема процесса “Подбор сотрудников” в нотации BPMN

Пример №2. Часть схемы “Подбор сотрудников” в нотации BPMN

Этап 2. Написать регламент выполнения этапов процесса

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

Пример описания в регламенте одного из этапов схемы процесса

Этап 3. Запустить управление процессом

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

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

В дальнейшем перейдите на бизнес-процессы в Битрикс24 или 1С. Вполне возможно, что их будет более чем достаточно для вашей компании.

Этап 4. Развивайте и оптимизируйте процесс с целью роста эффективности и качества

Как я уже упоминал, за развитие процесса должен отвечать его “владелец” (обращаю внимание, что это не из разряда “хочу/не хочу”, а почётная обязанность сотрудника).

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

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

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

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

Заключение, или Почему «всё и сразу» - это путь на кладбище проектов

Про процессы можно рассказывать много, хватит на целую книгу. Но… кладбища мёртвых проектов заполнены попытками внедрить “всё и сразу” и на самом дорогом и/или многофункциональном программном обеспечении. В лучшем случае сотрудники не использовали внедрённые технологии, или системы получались настолько громоздкими, что работать с ними было невозможно. В худшем - сложности при внедрении так и не позволили завершить работу до конца.

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

Читавшие эту статью, также читали

Время «Ч»: Когда внедрение регулярного менеджмента в вашей компании неизбежно, а оттягивание старта лишь принесёт дополнительные убытки

Сайт производителя товаров и оборудования: 10 типовых ошибок, которые препятствуют поиску новых дилеров и оптовиков