Владимир Репин: Описание бизнес-процессов: стремление к простоте

Владимир Репин

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:
1. «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

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


Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»). 

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

  1. «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
  2. «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
  3. «Процедура» системы Business Studio (один из возможных вариантов представления);
  4. ARIS eEPC. Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»). 

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

Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:


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

Сформулируем «плюсы» и «минусы» рассмотренного выше (рис. 1.) способа использования «ромбиков».

  

 По мнению автора статьи, рассмотренный на рис. 1. способ применения блоков «Решение» («ромбиков») является некорректным с точки зрения бизнес-моделирования.

На рис. 2. показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме рис. 1. Схема рис. 2. выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности, эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

 

Рис. 2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»).

«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 2., показаны ниже.

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

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

Второй особенностью схемы процесса, представленной на рис. 3., является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником – стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок – стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход дает возможность:

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

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

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

«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 3., показаны ниже.

 

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»).

    

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на рис. 3.

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

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на рис. 1-3. Трудоемкость формирования такой схемы так же существенно выше.

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio).

Описание процесса для целей последующей автоматизации

Интересно посмотреть на рассматриваемую схему процесса в случае, если она описана в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т.е. процессов которые поддерживает система BPM.

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

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением – «движком» BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0.

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний.

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

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

Выводы

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

Использование сложных, формализованных нотаций при описании процессов приводит к:

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

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

Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Researcher, Москва

Странно, что автор не упомянул BPWin (CA Erwin Process Modeler)

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

Консультант, Москва
Овсий Валерий пишет: Странно, что автор не упомянул BPWin
Пока функцию Undo не сделают в BPWin, упоминать его будут только вместе с чьей-то мамой :)
Технический директор, Москва
Коллеги. Удивительно, но в материале нигде не упомянут текущий уровень декомпозиции бизнес-процесса, для которого выбирается нотация. Хотя это не мешает автору давать варианты. Я знаю, что флоу-чарты (BFC & CFFC) чаще всего используются на уровне декомпозиции при описании ролей и функций. Но! Говорить о бизнес-процессе сразу с нижних уровней не есть правильно. Собрать в стройную систему, выполнить обратный процесс интеграции будет крайне затруднительно. Это первое. А второе, как следствие первого, предложенные варианты зависают в пустоте, целостной картины бизнес-процесса не выходит. А значит, связи между процессами удачно прописать не получиться. Кстати, всегда утверждал и продолжу, пока не докажут обратное, что проще IDEF0 для описания 1 и 2 уровней декомпозиции (грубо, департаменты и отделы для функциональных и матричных структур) нотации нет. Опровергните? Почему-то в статье о ней не слова.
Researcher, Москва
Андрей Маковер пишет: Удивительно, но в материале нигде не упомянут текущий уровень декомпозиции бизнес-процесса,
Вообще поддержка логической целостности при декомпозиции у указанных инструментах мне не известна. Может конечно и есть, но в BPWin это решено ОЧЕНЬ хорошо. Кто разрабатывал БП тот подтвердит важность ЭТОГО.
Андрей Маковер пишет: всегда утверждал и продолжу, пока не докажут обратное, что проще IDEF0 для описания 1 и 2 уровней декомпозиции (грубо, департаменты и отделы для функциональных и матричных структур) нотации нет.
Категорически согласен!!
Директор по развитию, Москва
В статье и обсуждениях, процесс моделирования бизнеса рассматривается почему то, однобоко - только через анализ нотаций бизнес-процессов. Но Aris, например, позволяет значительно удобнее других CASE-средств (в особенности всеми горячо любимого AllFusionPM) моделировать полную архитектуру бизнеса. То есть, до того как Вы начнете создавать модели движения сущностей (EPC), следует тщательно описать эти сущности, составить их диаграммы, а уж затем, используя копирование ссылок на эти элементы создаются диаграммы бизнес-процессов. Это несколько задерживает реализацию проекта описания бизнес-процессов предприятия на первом его этапе (описание сущностей или мета-данных), но именно благодаря такому подходу в дальнейшем Вы можете предоставить полезную информацию не только для бизнес-аналитиков, знакомых с правилами нотации, но и простым рабочим, менеджерам, руководителям, выгружая им табличные или текстовые отчеты в разных разрезах. В таких как например: должностные инструкции, документооборот и т.д. Правильное использование нотации, также помогает очень точно проанализировать узкие и широкие места в условиях производственных процессов имеющих значительный дефицит времени. Насчет избыточности в диаграммах Aris , можно сказать следующее... Избыточность происходит из-за формального использования правил нотации и незнания самих бизнес-процессов. Приведу пример... Функция ''Создание отчета'' у разработчика в статье заканчивается ''вырожденным'' событием ''Отчет создан''. Однако такого события в природе просто не существует. Существует ряд других событий по каждому из которых можно судить о завершении выполняемой функции. Например: ''Отчет подписан'', ''Отчет отправлен руководителю'', ''Отчет получен руководителем''. В этом случае не возникает кривотолков ''создан-не создан''...
Researcher, Москва
Михаил Кузнецов пишет: на первом его этапе (описание сущностей или мета-данных)
Михаил! Вы конечно правы! Но при выборе курицы на рынке можно сделать оценку ее качества по 2-5 обозримым показателям, а можно составить ФУНКЦИОНАЛ, доказать существование решения, выбрать метод... Разница в том, что выбрать курицу для супа может кухарка, а заработать ;) на этом процессе большие деньги только опытный консультант :D Вы, безусловно, опытный... :D
Директор по развитию, Москва
Валерий Овсий, Вы, безусловно, опытный...
Спасибо за лестный отзыв...
Но при выборе курицы на рынке можно сделать оценку ее качества по 2-5 обозримым показателям
Валерий, к сожалению выбирают по одному... цене. Только потому, что рынок CASE средств для руководителей предприятий(а именно они принимают, как правило решение) неведом. Это все равно что их заставить на рынке выбирать птеродактиля. Понятное дело, при таком подходе - чем проще тем лучше. А вопрос по возможностям средства отодвигается на задний план.
а заработать на этом процессе большие деньги только опытный консультант
Лично я не зарабатываю на том, какое средство я буду применять при моделировании. Оно уже давно окупило себя... Посоветовать могу, не более того 8)
Researcher, Москва
Михаил Кузнецов пишет: Только потому, что рынок CASE средств для руководителей предприятий(а именно они принимают, как правило решение) неведом. Это все равно что их заставить на рынке выбирать птеродактиля. Понятное дело, при таком подходе - чем проще тем лучше. А вопрос по возможностям средства отодвигается на задний план.
Я считаю, что CASE-средства в первую и основную очередь ИНСТРУМЕНТ аналитика, точнее – Бизнес аналитика. Но, к сожалению или к счастью с какого-то момента результаты работы аналитика требуют согласования, убеждения и продвижения. И вот с этого момента РЕЗУЛЬТАТЫ аналитика должны иметь такой вид, который учитывает менталитет, образование и в конце концов интеллект тех людей, которые принимают решения. Изобразительные средства и понятийный аппарат должны способствовать продвижению.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
В России запущен сайт с информацией о найме людей с инвалидностью

Цель проекта — создать полезную и актуальную базу знаний о найме людей с инвалидностью для работодателей и соискателей.

Разработичики Wildberries пожаловались на массовые увольнения

Сам маркетплейс это отрицает.

Новогодние подарки коллегам будут дарить вдвое реже, чем в прошлом году

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

Названы регионы с самой высокой и самой низкой безработицей

Наиболее благополучная ситуация в автономных округах Сибири, на Камчатке и в столицах.