Наше определение бизнес-процесса основано на определении, сформулированном в стандарте ISO-9001:2000. Мы считаем, что это наиболее адекватное, практически важное определение. Из него вытекают требования к описанию бизнес-процесса и подходы к его управлению. В нашем понимании описать бизнес-процесса означает:

1)    определить владельца бизнес-процесса;

2)    определить границы бизнес-процесса (границы ответственности и полномочий владельца процесса по управлению процессом);

3)    определить клиентов и выходы бизнес-процесса;

4)    определить поставщиков и входы бизнес-процесса;

5)    определить ресурсы, необходимые для выполнения бизнес-процесса (- находятся в распоряжении владельца процесса);

6)    описать технологию выполнения бизнес-процесса (например, с использованием графических схем в выбранных нотациях);

7)    разработать показатели, по которым оценивается бизнес-процесс, его результаты и удовлетворенность клиентов бизнес-процесса;

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

Рисунок 1. Документы,  используемые при управлении бизнес-процессом.

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

     Обратимся собственно к графическим схемам или, другими словами, моделям бизнес-процессов. В настоящее время для целей описания бизнес-процессов часто используют схемы потоков работ (Work Flow): ARIS eEPC, IDEF3, блок-схемы в Visio или MS Word. В основе указанных подходов лежит принцип построения бизнес-процесса в виде последовательно выполняемых во времени операций (работ), как показано на рисунке 2.

Рисунок 2. Пример схемы потока работ.

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

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

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

1)     все отображенные на схеме операции бизнес-процесса должны существовать реально и быть закрепленными за конкретными исполнителями; 

2)     на схеме должны отображаться реальные документы, файлы, ресурсы;

3)     схема процесса должна быть проста и понятна для визуального восприятия;

4)     схема процесса должна иметь компактный размер.

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

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

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

Рисунок 3. «Объемный бизнес-процесс».

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

     Каким же образом увязать деятельность руководителей и исполнителей при построении моделей потоков работ (ARIS eEPC, IDEF3)?  Очевидно, что сделать это можно несколькими способами. Первый и самый простой способ состоит в следующем: отдельно описываются потоки работ, выполняемых как руководителями, так и исполнителями. Такой простейший подход имеет несколько недостатков, основной их которых состоит в том, что взаимодействие руководителя и исполнителя становится в модели неявным, а опосредованным при помощи обратных связей по информации. Другой способ состоит в том, что при описании работ исполнителей можно указать прямые ссылки на процессы, выполняемые руководителями, или прямо отобразить их вмешательство в работу. Сказанное иллюстрирует рисунок 4.

Рисунок 4. От «плоского» процесса к «объемному».

На рисунке 4, вверху показана простейшая цепочка бизнес-процесса, состоящая из двух операций. Представим себе, что эти операции выполняются исполнителем и требуют управления со стороны руководителя. Как мы можем отобразить этот факт на модели? Согласно первому предложенному выше способу, мы указываем на модели процесса обратную связь по информации. В данном примере, нотация ARIS eEPC позволяет показать входящий и исходящий документ А, содержащий некоторую информацию. Документ А попадает от исполнителя руководителю после выполнения функции 2, и затем может быть возвращен на доработку при выполнении функции 1. При этом, «где-то в другом месте» мы должны описать работу руководителя по проверке этого документа и принятию решения. Это означает, что мы должны создать модель, описывающую деятельность руководителя. 

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

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

Подготовлено по материалам https://www.finexpert.ru/