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

Новая парадигма программирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нотация BPMN позволяет не рисовать дорожки на схеме. Однако при анализе схемы бизнес-процесса информация о связанной с узлом роли очень важна. Поэтому предлагается помещать название роли на графический элемент узла-действия схемы бизнес-процесса. Графическая нотация UML AD позволяет помещать название роли над именем узла-действия в круглых скобках. В нотации BPMN такой возможности нет, однако мы предлагаем даже в случае BPMN нотации располагать название роли в круглых скобках в верхней части графического элемента узла-действия и считать его префиксом названия узла. Этот прием будет использован в приведенных в настоящей лекции схемах бизнес-процессов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.8. Схема бизнес-процесса на которой линии расположения парные разделений – слияний, выделены желтым цветом

Желательно, чтобы линии переходов, соответствующих одновременно выполняющимся потокам действий, были параллельными. Это увеличивает понятность схемы, так как бизнес-аналитику проще представить параллельно расположенные на схеме последовательности действий как "параллельно" выполняющиеся. Примеры таких расположений также представлены на рис. 4.5, рис. 4.7, рис. 4.8.

Решения с непарными разделениями - слияниями

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

Он состоит из следующих действий:

• Заключить договор аренды помещения
• Подготовить помещение к конференции
• Подготовить пригласительные материалы
• Впечатать в материалы конференции адрес
• Разослать материалы конференции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если кредитный менеджер принял отрицательное решение, то операционист и сотрудник службы безопасности знакомятся с информацией об отказе в оформлении кредита, SMS-шлюз выполняет задание "Уведомить об отказе", после этого бизнес-процесс завершается.

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

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

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

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

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

В качестве примера рассмотрим реализацию задачи об игре в камешки. Игра состоит в следующем: есть кучка в 100 камней. Игроки ходят по очереди. За один ход игрок должен взять из кучки не менее одного, но не более 9 камней. Тот, кто возьмет последний камень, является выигравшим. Надо разработать бизнес-процесс, реализующий игру в камешки. Также требуется придумать гарантированно выигрышную стратегию поведения игрока. В бизнес-процессе на форме задания каждому игроку должен находиться соответствующий стратегии совет от экземпляра бизнес-процесса, - какое количество камней игроку на данном ходе стоит взять из кучки. Если при данном количестве камней в кучке не существует "выигрышного" хода, то на форме должно содержаться сообщение "не могу дать совет". На рис. 4.11 представлен пример бизнес-процесса, решающего данную задачу.

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