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

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

В статье рассматриваются приемы, применяемые при разработке бизнес-процессов, непосредственно исполняемых в компьютерной системе предприятия (исполняемых бизнес-процессов), представлен опыт обучения элементам этой технологии, полученный в НИТУ МИСиС и МЭСИ в течение двух лет преподавания процессных дисциплин в бакалавриате и магистратуре.

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

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

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

Несмотря на то, что первые аналоги современных систем управления бизнес-процессами (тогда они назывались Workflow-системами [1]) появились более пятнадцати лет назад, до недавнего времени большинство работ по процессному управлению (например, [2 - 4]) ограничивались изучением производственной деятельности предприятий, выявлением повторяющихся цепочек действий, формализацией и объединению этих цепочек в законченные бизнес-процессы, анализом выделенных бизнес-процессов и рекомендациями по изменению бизнес-процессов таким образом, чтобы эффективность деятельности предприятия при этом увеличилась. При этом не подразумевалась автоматизация исполнения бизнес-процессов, использование компьютерных систем было ограничено только моделированием бизнес-процессов. То есть, после разработки или изменения бизнес-процесса его внедрение в организации производилось административными методами, что было долго, неудобно и дорого.

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

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

· Получение от других работников необходимых для выполнения задания данных,

· Передачу результатов своего труда другим работникам,

· Изучение должностных инструкций,

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

На предприятиях с устойчивыми повторяющимися цепочками операций использование СУБП дает и другие преимущества:

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

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

· Позволяет оперативно изменять бизнес-процессы в ответ на изменение условий деятельности предприятия,

· Позволяет решить задачу интеграции масштаба предприятия,

· Уменьшает стоимость работ по автоматизации предприятия, повышает скорость разработки и надежность программного обеспечения.

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

Автоматизация на основе исполняемых бизнес-процессов позволяет:

· Быстро адаптировать разработку к изменению задач и появлению новых идей за время разработки.

· Понизить стоимость разработки.

· Понизить стоимость технической поддержки.

· Существенно понизить стоимость доработок и сопровождения.

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

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

Понятие парадигма рассматривается в данном случае в терминах концепции парадигм программирования Роберта Флойда [6], которая является расширением концепции парадигм Томаса Куна, предложенной в работе «Структура научных революций» [7].

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

В настоящей статье предложены правила построения схем бизнес-процессов, приведены решения для некоторых типичных ситуаций. Данные правила можно рассматривать как расширение и уточнение набора правил, изложенных в разделе «BPMN Best Practices» работы [8].

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

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

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

· изучение нотаций описания бизнес-процессов и обучение работе с конкретными СУБП (аналог обучения синтаксису языков программирования и работе с конкретными компиляторами),

· изучение различных возможных вариантов реализации в виде исполняемых бизнес-процессов тех или иных типичных ситуаций в бизнесе предприятия (аналог обучения приемам программирования).

Существуют большое количество учебных курсов, посвященные первому подходу. Например, в работах [9-10] обобщен опыт обучения студентов разработке исполняемых бизнес-процессов в МЭСИ, НИТУ МИСиС и УГАТУ. На занятиях студенты изучают теорию исполняемых бизнес-процессов, графические нотации описания бизнес-процессов (наиболее популярной является нотация BPMN, но иногда используется и UML AD [11]), основные компоненты типичных СУБП и получают практический опыт разработки и исполнения простейших бизнес-процессов.

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

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

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

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

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

2. Размер схемы бизнес-процесса.

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

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

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

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

Рисунок 1. Схема с движением точек управления слева-направо - сверху-вниз

4. Отказ от использования ролей в виде дорожек на схеме бизнес-процесса.

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

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

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

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

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

Рисунок 2. «Интуитивная» реализация действия, выполняемого одновременно двумя лицами

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

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

6. Вынесение второстепенных действий в параллельную ветку.

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

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

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

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

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

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

В сложных случаях иногда требуется использовать в схемах бизнес-процессов элементы разделения без парных им элементов - слияний. (Разделением мы называем параллельный шлюз с одним входящим и многими исходящими переходами, а слиянием - параллельный шлюз с многими входящими и одним исходящим переходом.) На таких схемах для удаления выполнивших свою задачу точек управления используется элемент - завершение потока управления (На Рис. 6 приведен пример схемы с непарными элементами, эквивалентной схеме рисунка 5). Однако, как отмечено в работе [8], предпочтительной схемой является схема с парными разделениями и слияниями, так как такие схемы являются более понятными.

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

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

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

8. Расположение парных разделений-слияний и переходов, их соединяющих.

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

9. Использование элемента «окончание бизнес-процесса».

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

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

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

Рисунок 8. Схема бизнес-процесса, реализующая согласование документа

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

10. Пример "компромиссного" решения по разделениям-слияниям и использованию элемента «завершение потока управления».

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

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

Рисунок 9. Схема бизнес-процесса розничного кредитования банка

11. Использование алгоритмов в схеме бизнес-процесса.

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

В качестве примера рассмотрим процессную реализацию классической задачи Мартина Гарднера о разборчивой невесте в формулировке академика Дынкина [12]: К невесте приходит по одному заранее известное количество женихов. Она общается с каждым не более одного раза и может сравнить его с любым из предыдущих. Если она кого-то выбирает, то процесс выбора останавливается. Если невеста кому-то отказывает, то еще раз его рассмотреть она уже не может. Цель невесты -- с максимальной вероятностью выбрать самого лучшего из всех женихов.

На Рис. 10 - 11 представлены бизнес-процесс и его подпроцессы, реализующие данную задачу.

Рисунок 10. Схема бизнес-процесса задачи о разборчивой невесте

Рисунок 11. Схемы подпроцессов бизнес-процесса задачи о разборчивой невесте

процессный программный автоматизация

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

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

Для обучения студентов процессной автоматизации в курсах [9-10] применяется свободная СУБП RunaWFE [13]. Использование свободного ПО для обучения позволяет легко внедрить курс обучения в учебный процесс любого российского ВУЗа: ПО бесплатно, доступно в интернете на сайте проекта RunaWFE (http://runawfe.org/rus), для установки системы не требуется каких-либо ключей или лицензионных файлов, количество инсталляций не ограничено.

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

Литература

процессный программный автоматизация

1. Wil van der Aalst, Kees van Hee. Workflow management. Models, methods and systems. MIT Press, 2004.

2. Абдикеев Н.М., Данько Т.П., Ильдеменов С.В., Киселев А.Д. Реинжиниринг бизнес-процессов. М.: Эксмо, 2005.

3. Тельнов Ю.Ф. Реинжиниринг бизнес-процессов: Компонентная методология. М.: Финансы и статистика, 2004

4. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. - М.: Финансы и статистика, 2006.

5. Вагнер Ю.Б. BPMS-эффект // Автоматизация в промышленности. №7 2009 с. 42 - 47

6. Флойд Р. О парадигмах программирования. В кн.: Лекции лауреатов премии Тьюринга. М: Мир, 1993

7. Кун Т. Структура научных революций. М.: Прогресс, 1975

8. Stephen A. White BPMN Modeling and Reference Guide: Understanding and Using BPMN. Future Strategies Inc. 2008

9. Куликов Г.Г., Михеев А.Г. Особенности реализации процессного подхода и обучения управлению бизнес-процессами при помощи свободного ПО с открытым кодом. / Открытое образование, № 4 2011 с. 47 - 57

10. Пятецкий В.Е, Михеев А.Г., Новичихин В.В. Система управления бизнес-процессами: основы разработки бизнес-процессов с помощью свободного программного обеспечения: практикум - М.: Изд. Дом МИСиС, 2013.

11. Фёдоров И.Г. Сравнительный анализ нотаций моделирования бизнес-процессов // Открытые системы 2011 № 8

12. Гусейн-Заде С.М. "Разборчивая невеста" - М.: МЦНМО, 2003

13. Михеев А.Г., Орлов М.В. Система управления бизнес-процессами и административными регламентами.

Размещено на Allbest.ru