Схема бизнес процесса — краткий алгоритм создания

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

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

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

1 – Задайте границы процесса

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

2 – Нарисуйте основные блоки процесса

Расположите основные блоки (подпроцессы, операции) бизнес процесса в том порядке, в котором они выполняются.

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

3 – Добавьте развилки и другие события

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

4 – Обозначьте роли участников процесса

В бизнес процессах нет должностей или конкретных сотрудников. Вместо этого используется понятие “роль”. Один сотрудник может выполнять множество ролей. Одну роль может выполнять множество сотрудников. Из набора ролей складывается должность.

По необходимости добавляйте недостающие операции.

5 – Разместите на схеме документы

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

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

6 – Добавьте используемые программы и базы данных

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

7 – Расположите инструменты и материалы

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

8 – Определите показатели эффективности в бизнес процессе

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

9 – Свяжите полученную схему с другими процессами

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

Связь бизнес процесса с другими процессами

10 – Проверьте полученную модель бизнес процесса

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

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

В качестве нотации моделирования я рекомендую использовать BPMN

Качественно подготовленная схема должна быть проста для восприятия и достаточно информативна.

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

Данный алгоритм позволит вам довольно просто и быстро описать необходимые бизнес процессы. Далее я буду подробно рассказывать об описании бизнес процессов. Оставайтесь на связи.

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

rzbpm.ru

Что такое исполнимые бизнес-процессы. Введение в предметную область / Habr

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

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

Термин «процессное управление» применяется к двум разным сферам деятельности:

1. В случае, когда не производится автоматизация исполнения бизнес-процессов. Задача — составить описание бизнеса в виде графических диаграмм, которые легко воспринимаются людьми. Такие диаграммы фактически представляют собой специальный язык общения менеджеров, бизнес-аналитиков и руководителей предприятий и используются для выработки и объяснения базовых решений по организации бизнеса предприятия.
2. В случае, когда бизнес-процессы непосредственно исполняются в компьютерной среде предприятия. Будем называть процессы этого вида — исполнимые бизнес-процессы. Для исполнения таких бизнес-процессов на предприятии устанавливается специальная компьютерная система — BPMS (Business Process Managrment System) в английском варианте наименования, или СУБП (Система Управления Бизнес-Процессами) в русском варианте. Этим бизнес-процессам и посвящена данная статья.

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

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

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

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

Фактически основная функция BPMS — раздавать задания исполнителем в соответствии с перемещением точек управления по схеме бизнес-процесса и контролировать выполнение этих заданий.

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

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

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

Процессный подход в случае исполнимых бизнес-процессов

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

Процессным управлением в случае исполнимых бизнес-процессов можно назвать следующую деятельность:

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

Основные преимущества процессного подхода в случае исполнимых бизнес-процессов

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

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

Все необходимое для выполнения задания возникает перед работником на экране компьютера.

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

Более подробное описание исполнимых бизнес-процессов

Схема бизнес-процесса

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

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

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

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

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

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

Рисунок 1. Обозначения узлов: а – начало; б – завершение потока; в – окончание; г – действие

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

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

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

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

Рисунок 2. Обозначения узлов: а – исключающий шлюз; б – параллельный шлюз

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

Рисунок 3. Пример (упрощенный) схемы бизнес-процесса “Оплата счета поставщика”

Переменные бизнес-процесса

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

Роли бизнес-процесса

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

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

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

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

Для выполнения этих функций в BPMS служат следующие графические интерфейсы:

• интерфейсы для работы с заданиями исполнителей
• интерфейсы для работы с загруженными в BPMS определениями бизнес-процессов
• интерфейсы для работы с выполняющимися в BPMS экземплярами процессов
• интерфейсы для администрирования пользователей и групп пользователей
• интерфейсы для настройки замещений исполнителей заданий

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

Типичная BPMS состоит из следующих основных компонентов:

• Среда исполнения бизнес-процессов
• Среда разработки бизнес-процессов и связанных с ними объектов
• Клиент-оповещатель о поступивших заданиях
• Компонент-коннектор к другим информационным системам

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

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

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

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

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

При помощи интерфейсов для работы с заданиями исполнителей пользователь может:

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

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

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

При помощи интерфейсов для администрирования системы администратор может:

• Создавать-удалять пользователей и группы пользователей
• Включать (исключать) пользователей в группы
• Раздавать права на объекты системы пользователям и группам пользователей
• Принудительно останавливать экземпляры бизнес-процессов
• Добавлять, изменять правила замещения пользователей

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

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

Рисунок 7. Пример интерфейса, в котором можно разрабатывать бизнес-процессы

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

Описание работы пользователей и компонентов BPMS

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

На клиентских компьютерах пользователей запускается клиент-оповещатель о поступивших заданиях или браузер, в котором открывается web-интерфейс BPMS.

На клиентских компьютерах аналитиков запускается среда разработки бизнес-процессов и связанных с ними объектов. Также на клиентских компьютерах аналитиков запускается симулятор бизнес-процессов.

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

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

Web-интерфейсы и клиенты-оповещатели периодически обращаются к среде исполнения и отображают задачи пользователей.

Пользуясь web-интерфейсом BPMS пользователи:

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

Пользуясь web-нтерфейсом BPMS администраторы:

• Загружают или изменяют определения бизнес-процессов
• Создают или изменяют параметры пользователей и групп пользователей
• Раздают права на объекты системы
• Изменяют параметры ботов и бот-станций

При помощи среды разработки аналитики:

• разрабатывают и модифицируют бизнес-процессы

Для разработки бизнес-процесса аналитику надо:

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

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

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

Клиенты-оповещатели сигнализируют пользователям о появлении новых заданий.

Реинжиниринг и эволюционное управление бизнес-процессами

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

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

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

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

Для образного понимания того, как бизнес-процессы используются в качестве инструмента управления бизнесом в случае эволюционного управления с использованием КПЭ А. Белайчук (председатель Ассоциации профессионалов по управлению бизнес-процессами) предложил следующую аналогию: Управление предприятием можно образно сравнить с управлением автомобилем. В этом случае КПЭ являются аналогом того, что видит водитель — вид через лобовое стекло автомобиля и значения показателей датчиков (скорость, давление масла, количество оборотов двигателя, количество бензина и т.п.), а бизнес-процессы выполняют роль руля, педалей (газ, тормоз, сцепление) и рычага переключения передач автомобиля. То есть, служат для непосредственного управления траекторией в пространстве и времени.

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

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

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

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

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

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

Математические основы исполнимых бизнес-процессов

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

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

• теория сетей Петри
• концепция Пи-исчисления

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

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

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

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

Концепция Пи-исчисления (Pi calculus) была разработана в конце 80-х годов ХХ века Робином Милнером и основана на алгебре параллельных процессов. В отличие от сетей Петри, математическими объектами Пи-исчисления являются не графы, а выражения над элементами специальных множеств и преобразования над этими выражениями. В настоящее время Пи-исчисление является перспективной, но еще молодой и развивающейся теорией, в ней много открытых вопросов и нерешенных проблем. Математически было доказано, что функциональные возможности Пи-исчисления выше, чем сетей Петри.

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

habr.com

Где рисовать процессы? — bpmn2.ru

Нотации – инструмент для отображения бизнес-процессов.

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

Количество убивает качество

Когда ваша компания состоит из нескольких человек, когда вы знаете каждого поимённо, схемы вам вряд ли пригодятся.

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

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

В каких случаях нужно рисовать схемы?

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

Как пользоваться нотациями

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

• Действие. Этот элемент отражает определенную часть работы.
• Событие. Показывает, когда что-то «случилось»: например, пришел заказ.
• Шлюзы. Они соединяют или разделяют другие элементы схемы.
• Артефакты. Задача этого элемента – улучшить читаемость схемы, дать дополнительную информацию.
• Потоки. Отображают последовательность работы.
• Дорожки и пулы. Разделяют ответственность между задачами.

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

Схема процесса

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

Схема процесса без исполнителей

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

Схема процесса с исполнителями

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

Подпроцессы отображаются в виде свёрнутых элементов

Сравнение разных инструментов для нотации BPMN

Мы описали основные элементы BPMN. Рисовать процессы в этой нотации можно в разных инструментах. Сравнение их возможностей – в таблице ниже.

	bizagi	visio
Стоимость	Бесплатная	Платная
Удобство	Тяжело работать со сложными схемами	Подходит для описания бизнес-процессов, но может понадобиться дополнительная библиотека элементов
Верификация схем	Есть	Нет
Возможность выгрузки	Поддерживает выгрузку в отдельных форматах	Поддерживает выгрузку в картинки

Как пользоваться бесплатной программой

Воспользоваться BPMN вы можете бесплатно, просто перейдите по ссылке http://storm.bpmn2.ru/ – и перед вами откроется рабочая область, процессник. Нотация работает прямо из браузера, ничего скачивать и устанавливать на компьютер не нужно.

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

Так выглядит рабочее окно программы

Как нарисовать регламент бизнес-процесса

• определите проблему, которую нужно решить. Например, задерживается отправка готовых заказов;

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

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

bpmn2.ru

Как построить схему бизнес-процесса | Статьи iTeam

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

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

Этап 1. Определение и ограничение бизнес-процесса

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

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

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

Этап 2. Задание точек начала и окончания, основных блоков

Любая схема бизнес-процесса имеет начало и конец. Например, за начало берётся поступившая от клиента заявка, за конечную точку – момент передачи ему готового продукта (доставки).

Далее вычленяются основные этапы обработки бизнес-процесса. Например:

• Регистрация входящей заявки.
• Презентация клиенту подходящего продукта.
• Оформление конкретной заявки.
• Производство продукта (или поиск его на складе) и отправка клиенту.

Этап 3. Детализация схемы бизнес-процесса

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

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

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

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

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

Этап 4. Определение ролей участников процесса, документов, баз данных

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

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

Этап 5. Проверка схемы бизнес-процесса

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

Готовая схема бизнес-процесса может быть с лёгкостью автоматизирована с помощью систем BPM.

Автор: Е. Гайдукова

Источник: материалы сайта comindware.com

blog.iteam.ru

Введение в бизнес-процессы. Часть 2

В первой части мы рассмотрели основные понятия бизнес-процессов. В данной части мы рассмотрим моделирование бизнес-процессов и приведем пример моделирования.

 

 

 

 

Моделирование – процесс исследования деятельности организации с целью построения формализованного (графического, табличного, текстового) описания бизнес-процессов организации.

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

• интервьюирование;
• работа с законодательством, документами организации;
• методы мозгового штурма и т.д.

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

Ниже мы рассмотрим пример алгоритма моделирования бизнес-процессов. Итак, для моделирования бизнес-процесса необходимо:

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

 

Схема, иллюстрирующая алгоритм моделирования показана на рисунке ниже:

 

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

• дополнить существующую модель ответвлениями;
• предусмотреть отдельно действия «альтернативного» процесса.

 

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

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

Для фиксации бизнес-процессов в графическом виде используется система условных обозначений элементов (нотация). Наиболее известные нотации: SADT/IDEF0, IDEF3, DFD, BPMN, ARIS, UML. Рассмотрение и сравнительный анализ нотации не входит в предмет обсуждения данной статьи; интересующимся в интернете можно найти массу статей на темы сравнения нотаций, например «IDEF vs ARIS».

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

Приведем пример описания бизнес-процесса. В качестве примера возьмем процесс предоставления неоплаченного отпуска. Рассмотрим порядок и документооборот, возникающий при указанном выше процессе. Метод сбора информации: законодательство РФ как предварительный материал перед интервью с экспертами предметной области и Владельцем процесса. Нотация описания: ARIS eEPC.

1. Сбор исходного материала.

1.1 Предоставление отпуска регламентируется Трудовым Кодексом (при сборе материала необходимо опираться на последнюю редакцию, на момент написания статьи – с изменениями от 30 декабря 2015 г. № 434-ФЗ), статьей 128 Отпуск без сохранения заработной платы

 

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

Работодатель обязан на основании письменного заявления работника предоставить отпуск без сохранения заработной платы:

• участникам Великой Отечественной войны — до 35 календарных дней в году;
• работающим пенсионерам по старости (по возрасту) — до 14 календарных дней в году;
• родителям и женам (мужьям) военнослужащих, сотрудников органов внутренних дел, федеральной противопожарной службы, органов по контролю за оборотом наркотических средств и психотропных веществ, таможенных органов, сотрудников учреждений и органов уголовно-исполнительной системы, погибших или умерших вследствие ранения, контузии или увечья, полученных при исполнении обязанностей военной службы (службы), либо вследствие заболевания, связанного с прохождением военной службы (службы), — до 14 календарных дней в году;
• работающим инвалидам — до 60 календарных дней в году;
• работникам в случаях рождения ребенка, регистрации брака, смерти близких родственников — до пяти календарных дней;

 

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

 

1.2. Документооборот при оформлении отпуска регламентируется постановлением Госкомстата РФ от 05.01.2004 N 1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты», раздел «Приказ (распоряжение) о предоставлении отпуска работнику».

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

Составляются работником кадровой службы или уполномоченным им на это лицом, подписываются руководителем организации или уполномоченным им на это лицом, объявляются работнику под расписку. На основании приказа (распоряжения) о предоставлении отпуска делаются отметки в личной карточке (форма N Т-2 или N Т-2ГС(МС)), лицевом счете (форма N Т-54 или N Т-54а) и производится расчет заработной платы, причитающейся за отпуск, по форме N T-60 »Записка-расчет о предоставлении отпуска работнику».

 

Приводим данные, необходимые для моделирования бизнес-процесса (действуем согласно описанной ранее схеме): 

1. Результат бизнес-процесса — оформленные согласно законодательству РФ и стандартам организации документы. 

2. Владелец бизнес-процесса: руководитель кадровой службы. Как определить владельца? Владелец – это сотрудник, обладающий ресурсами для осуществления бизнес-процесса (в данном случае ресурсы – сотрудники кадровой службы) и несущий ответственность за результат бизнес-процесса.

3. Набор и порядок действий:

написание заявления -> составление приказа -> подписание приказа у руководителя инициатора -> подписание приказа у инициатора –> оформление кадровых документов.

В последовательности действий отсутствует расчет заработной платы, т.к. статья Трудового Кодекса, согласно которой оформляется отпуск, – Отпуск без сохранения заработной платы.

4. Исполнители бизнес-процесса.. Для более наглядного предоставления информации приведем последовательность шагов и исполнителей в таблице:

№ действия	Наименование действия	Исполнитель	№ след. действия
1	Написание заявления	Инициатор	2
2	Составление приказа	Сотрудник кадровой службы	3
3	Подписание приказа у руководителя инициатора	Сотрудник кадровой службы	4
4	Подписание приказа у инициатора	Сотрудник кадровой службы	5
5	Оформление кадровых документов	Сотрудник кадровой службы	(конец)

 

5. События. Дополним вышеуказанную таблицу информацией о событиях:

 

№ действия	Входящее событие	Наименование действия	Исполнитель	Исходящее событие	№ след. действия
1	Инициатору необходим отпуск за свой счет	Написание заявления	Инициатор	Составлено заявление на отпуск за свой счет	2
2	Составлено заявление на отпуск за свой счет	Составление приказа	Сотрудник кадровой службы	Составлен приказ об отпуске	3
3	Составлен приказ об отпуске	Подписание приказа у руководителя инициатора	Сотрудник кадровой службы	Приказ об отпуске подписан руководителем инициатора	4
4	Приказ об отпуске подписан руководителем инициатора	Подписание приказа у инициатора	Сотрудник кадровой службы	Приказ об отпуске подписан инициатором	5
5	Приказ об отпуске подписан инициатором	Оформление кадровых документов	Сотрудник кадровой службы	Оформлены кадровые документы на отпуск	(конец)

 

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

 

№ действия	Входящее событие	Наименование действия	Документ, информация	Исполнитель	Исходящее событие	№ след. действия
1	Инициатору необходим отпуск за свой счет	Написание заявления	Заявление на отпуск за свой счет	Инициатор	Составлено заявление на отпуск за свой счет	2
2	Составлено заявление на отпуск за свой счет	Составление приказа	Приказ на отпуск	Сотрудник кадровой службы	Составлен приказ об отпуске	3
3	Составлен приказ об отпуске	Подписание приказа у руководителя инициатора	Приказ на отпуск	Сотрудник кадровой службы	Приказ об отпуске подписан руководителем инициатора	4
4	Приказ об отпуске подписан руководителем инициатора	Подписание приказа у инициатора	Приказ на отпуск	Сотрудник кадровой службы	Приказ об отпуске подписан инициатором	5
5	Приказ об отпуске подписан инициатором	Оформление кадровых документов	Т-2, Т-54а	Сотрудник кадровой службы	Оформлены кадровые документы на отпуск	(конец)

 

 

7. Проведем анализ «что если».

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

• Что если инициатор откажется подписывать приказ (например, у него изменились обстоятельства, согласно которым он брал отпуск)? Мы прекращаем процесс.
• Что если внесение отметок в кадровые документы Т-2 и Т-54а будет некорректным? Данный вопрос аналогичен вопросу, рассматриваемому в п. 3.2.

 

 

Дополним существующую таблицу полученной информацией. Фактически мы получили предварительное описание процесса в табличном виде:

 

Открытые вопросы

• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор имеет право на отпуск, согласно 128 статье Трудового кодекса
• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор не имеет право на отпуск, согласно 128 статье Трудового кодекса

 

Краткое обозначение элементов нотации ARIS eEPC приведено в таблице ниже (описаны не все элементы нотации, а используемые. Графическое обозначение элементов взято из пакета MS Visio):

 

Схема, отображающая взаимодействие элементов показана ниже:

 

Графическое отображение процесса предоставлено выглядит следующим образом:

 

 

 

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

 

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

— Не сомневаюсь, ты написал интересную статью. Но к чему такие сложности? Зачем нужны бизнес-процессы, неужели без них нельзя?

— Смотри, бизнес-процессы снижают вариабельность результатов за счет стандартизации операций. Вариабельность означает снижение разброса допустимых вариантов результатов процесса. Я описал простой пример, бизнес-процессы применимы не только к кадровому делу, но и к деятельности организации. Представь себе, что организация, специализирующая на поставке запчастей, будет производить детали с разным уровнем качества (мы помним, что качество – это соблюдение характеристик изделия). Далее автозапчасти будут ставиться на автомобили, и мы получим… продукцию АвтоВАЗа. Продукция АвтоВАЗа находит своего покупателя, но мы в последнее время предпочитаем автомобили качественной сборки.

— Я думаю, все дело в исполнителях. Достаточно найти грамотных исполнителей и мы получим хороший результат. Как в твоем примере – надо найти грамотного кадровика, только и всего.

— Хорошие исполнители, уже обеспечены работой, их труд стоит дорого. Ты не думаешь об оптимизации расходов организации, найма толковых специалистов, и обеспечения специалистов методической поддержкой. Еще один фактор – масштабирование работы. Представим, что в нашей организации работает 2 000 сотрудников. В данном случае у нас будет несколько специалистов кадровой службы и у них будет разный опыт. Наша задача в данном случае – предоставить инструмент обучения, осуществления операций и контроля операций со стороны руководителя подразделения.

— Даже если 2 000 человек и даже если специалисты будут ошибаться. Какова цена ошибки – всего-лишь неправильно оформленные кадровые документы, эти бумажки.

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

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

Автор

Евгений Пономарёв

[email protected]

 

analyst.by

Описание бизнес-процессов

Выполнить описание бизнес-процесса – значит: а) собрать информацию о процессе и б) представить ее в графическом и/или текстом виде.

Приступим:

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

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

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

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

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

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

micro-solution.ru

Описание архитектуры и бизнес-процессов с помощью Графолайт

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

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

Что нужно описывать

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

Согласно ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011:

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

Как можно описать архитектуру

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

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

• Предприятие, как база данных. Это основа для построения любой корпоративной ИС (ERP, CRM, складской, системы управления цепочками поставок и т. д.).
• Предприятие как договаривающиеся стороны. Совокупность участников, которые находятся в различных отношениях между собой — административных, управленческих, политических, отношениях подчинения, зависимости, влияния, авторитета и др. Этот подход полезен для управленческого консалтинга, выявления зон ответственности (и безответственности).
• Предприятие, как фабрика по переработке сырья/ресурсов/информации в конечный продукт. В фокусе этого подхода находятся бизнес-процессы.

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

• Абстрактные модели данных для описания информационных структур, воплощаемых в дальнейшем в базы данных. Для изображения этого слоя Grapholite поддерживает ER-диаграммы.
• Схемы баз данных, отражающие структуру БД (таблицы, представления, отношения между ними и т. п.). В Grapholite можно проектировать схемы баз данных, используя диаграмму классов UML.
• Организационные структуры, отражающие административную иерархию предприятия. Реализуется с использованием организационной диаграммы (простейшие структуры), либо при помощи базовых элементов блок-схем (флоучартов), с помощью которых можно отобразить любые аспекты отношений между участниками предприятия.
• Бизнес-процессы, наиболее важная часть описания архитектуры. Для их отображения в Grapholite имеется несколько возможностей: блок-схемы, кросс-функциональные диаграммы (дорожки), EPC диаграммы, UML и BPMN.

В рамках описания архитектуры предприятия последний пункт представляет наибольший интерес и на нем стоит остановиться и разобрать более детально.

Языки (нотации) для описания корпоративной архитектуры

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

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

Кросс-функциональная диаграмма

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

Шаблон IDEF0, построенный в Grapholite из обычного прямоугольника и стрелок

ARIS eEPC (extended event driven process chain) — мощная, оснащенная и технологичная методология. Несмотря на свой возраст, она все еще находит свое применение. Grapholite поддерживает создание EPC диаграмм «из коробки».

Пример EPC-диаграммы

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

Пример диаграммы UML Activity (деятельности)

BPMN (Business Process Model and Notation) в настоящее время является наиболее подходящим решением для описания бизнес-процессов. Эта методология (и нотация) моделирования — отличная альтернатива конкурирующим между собой «частным» решениям. Это открытый, публичный стандарт. Grapholite поддерживает как предыдущую версию BPMN 1.2, так и новую 2.0.

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

grapholite.ru

No related posts.