Разработка исполнимых бизнес-процессов - появление новой парадигмы программирования
Новая парадигма программирования
Одной из причин выбора процессного варианта автоматизации предприятия является уменьшение затрат на автоматизацию. При традиционной автоматизации сначала бизнес-аналитик описывает функциональность проектируемой системы в виде текста, потом программист переводит это описание в программный код. Использование исполнимых бизнес-процессов позволяет в значительной степени избежать дублирования работы: в этом случае бизнес-аналитик совместно с заказчиком при помощи визуальных графических программных средств разрабатывает бизнес-процессы автоматизируемой функциональности, которые будут потом непосредственно исполняться в компьютерной среде.
Схемы исполнимых бизнес-процессов представляют собой понимаемое человеком графическое описание соответствующей функциональности, при этом их не требуется переводить в программный код. Поэтому затраты на аналитическую деятельность в этом случае будут примерно такими же, а затраты на программирование - существенно ниже.
При изменении условий бизнеса бизнес-аналитик может быстро изменить соответствующим образом схемы бизнес-процессов без участия программиста. Также во многих случаях бизнес-аналитик может самостоятельно (без участия программиста) разрабатывать новые бизнес-процессы.
Поэтому стоимость разработки, внедрения, сопровождения и поддержки ИТ-решения на основе исполнимых бизнес-процессов оказывается существенно меньше стоимости решений традиционной автоматизации, при которой для различных задач и подразделений разрабатываются отдельные компоненты приложения. При этом скорость разработки, внедрения, а также последующих изменений ИТ-решений на основе исполнимых бизнес-процессов оказывается существенно выше.
Эти преимущества (быстрее, дешевле, легче в поддержке и сопровождении) совпадают c преимуществами парадигмы объектно-ориентированного программирования по сравнению с парадигмой процедурного программирования. По аналогии мы можем назвать деятельность по проектированию исполнимых бизнес-процессов новой парадигмой программирования относительно традиционного подхода.
Понятие парадигма рассматривается в данном случае в терминах концепции парадигм программирования Роберта Флойда 1Флойд Р. О парадигмах программирования. В кн.: Лекции лауреатов премии Тьюринга. М: Мир, 1993, которая является расширением концепции парадигм Томаса Куна, предложенной в работе "Структура научных революций 2Кун Т. Структура научных революций. М.: Прогресс, 1975 ".
Внедрение СУБП на предприятии приводит к появлению единого для всех менеджеров предприятия языка для работы с бизнес-процессами, основанного на графических диаграммах. После освоения этого языка работники предприятия могут быстро читать существующие определения бизнес-процессов, разбираться в состояниях выполняющихся экземпляров бизнес-процессов, бизнес-аналитики могут производить быстрые изменения и разработку новых бизнес-процессов.
В последние годы исполнимые бизнес-процессы активно внедряются как в бизнесе, так и в государственных организациях. Однако, автоматизация на основе исполнимых бизнес-процессов требует от специалистов процессного мышления, отличающегося от мышления ИТ-специалистов по традиционной автоматизации предприятий. Кроме знания нотаций описания бизнес-процессов и интерфейсов СУБП, бизнес-аналитики должны уметь реализовывать в виде исполнимых бизнес-процессов типичные ситуации в бизнесе. Всвязи с этим появляется задача обучения специалистов как экономических специальностей, так и специальностей, связанных с информационными технологиями, процессному подходу, разработке исполнимых бизнес-процесов и работе с СУБП.
В настоящей лекции предложены правила построения схем бизнес-процессов, приведены некоторые типичные бизнес-ситуации и представлены для них решения.
Правила разработки исполнимых бизнес-процессов
Формулировки, используемые в названиях узлов схемы бизнес-процессов, соответствующих действиям исполнителей
Наименование узла, в котором дается задание исполнителю, в большинстве СУБП также является названием задания, которое отображается пользователю. Задания нужно формулировать так, чтобы они были максимально понятны исполнителю. Если задание непонятно, то у исполнителя уйдет много усилий и времени на его интерпретацию, возможно задание будет исполнено не так, как планировал разработчик бизнес-процесса.
Например, получив задание, сформулированное как "договор подряда", исполнитель не будет знать, каких именно действий требует от него бизнес-процесс в этом узле: напечатать договор, подписать договор, согласовать договор, проверить договор и т.п. Исполнителю придется затратить дополнительные усилия на выяснение этого. То есть, недостаточно понятные формулировки заданий увеличивают затраты на эксплуатацию бизнес-процесса.
По опыту автора наиболее понятными являются формулировки, включающие в себя глагол в неопределенной форме и существительное, например, "Издать приказ", "Рассмотреть заявку". На занятиях по обучению студентов разработке бизнес-процессов, проводимых автором настоящего курса лекций, такой вид именования узлов бизнес-процесса является обязательным.
Размер схемы бизнес-процесса
Желательно, чтобы схема бизнес-процесса умещалась на экране компьютера. Схемы, размер которых превышает полтора размера экрана компьютера, крайне сложно анализировать, поэтому следует избегать использования таких схем. Если схема не помещается на экране, то ее части надо стараться вынести во внутренние или внешние подпроцессы.
Направления движения точек управления по схеме бизнес-процесса
Бизнес-аналитику комфортно анализировать перемещения точек управления по схеме бизнес-процесса, когда общее движение точек управления соответствует перемещению области, на которую смотрит человек при чтении текстов. Поэтому желательно так располагать узлы схемы бизнес-процессов, чтобы общее движение точек управления по ним было слева-направо или сверху-вниз. Пример общего движения точек управления слева-направо приведен на ранее. Пример общего движения точек управления сверху-вниз приведен на Рис. 4.1.
В некоторых случаях, при длинных участках движения точек управления без разветвлений, можно располагать связанные линиями переходов узлы схемы слева-направо - сверху-вниз, аналогично тому, как человек читает слова на листе печатного документа. Пример такого движения точек управления приведен на Рис. 4.1.
Конечно, в случае сложной логики поведения бизнес-процесса, когда в нем появляются повторы выполнения действий и на его схеме возникает большое число петель направленных переходов, этого сложно добиться. Однако большинство использующихся на практике бизнес-процессов имеют простую логику, при их разработке надо стараться, чтобы общее движение точек управления соответствовало выбранному направлению (слева-направо или сверху-вниз).
Отказ от использования ролей в виде дорожек на схеме бизнес-процесса
Роли предназначены для связывания узлов схемы бизнес-процесса, в которых выполняются действия, с исполнителями заданий. При разработке бизнес-процесса создаются роли и ставятся в соответствие определенным узлам-действиям схемы бизнес-процесса. Во время выполнения бизнес-процесса ролям назначаются конкретные исполнители. Большинство современных графических нотаций для схем бизнес-процессов позволяют задавать роли на схеме бизнес-процесса в виде горизонтальных или вертикальных полос, называемых дорожками. В этом случае все узлы схемы бизнес-процесса, расположенные на определенной дорожке, связываются с соответствующей дорожке ролью.
Практический опыт автора показывает, что в отличие от учебных бизнес-процессов, в находящихся в эксплуатации промышленных бизнес-процессах предприятия использование ролей в виде дорожек неудобно, так как необходимость помещать узлы схемы бизнес-процесса на определенную полосу мешает создавать схемы понятными с точки зрения движения точек управления, а также сильно увеличивает занимаемую схемой бизнес-процесса площадь, что, как правило, не позволяет схеме промышленного бизнес-процесса помещаться на один экран компьютера. А это делает работу со схемой бизнес-процесса сложной и неудобной.
Нотация BPMN позволяет не рисовать дорожки на схеме. Однако при анализе схемы бизнес-процесса информация о связанной с узлом роли очень важна. Поэтому предлагается помещать название роли на графический элемент узла-действия схемы бизнес-процесса. Графическая нотация UML AD позволяет помещать название роли над именем узла-действия в круглых скобках. В нотации BPMN такой возможности нет, однако мы предлагаем даже в случае BPMN нотации располагать название роли в круглых скобках в верхней части графического элемента узла-действия и считать его префиксом названия узла. Этот прием будет использован в приведенных в настоящей лекции схемах бизнес-процессов.
Реализация действия, которое должно быть выполнено одновременно двумя исполнителями
В некоторых случаях определенное действие должно быть выполнено сразу двумя исполнителями. Например, один сотрудник должен расписаться на документе, находящемся у другого сотрудника. Как правило, интуитивная реализация такого сценария соответствует последовательному расположению двух узлов на схеме бизнес-процесса, при этом исполнителем в первом узле является сотрудник, который должен поставить подпись на документе, а во втором - сотрудник, у которого находится документ (См. Рис. 4.2).
Однако, практика эксплуатации бизнес-процессов на предприятии показывает, что такое решение является неудачным: Если сотрудник, подписывающий документ, отметит выполнение задания до того, как пойдет к сотруднику, у которого находится документ, то во многих случаях эта отметка о выполнении задания окажется ложной, так как у сотрудника могут возникнуть более приоритетные работы и он может срочно заняться другой задачей.
При этом задание будет удалено из его списка заданий и сотрудник легко может забыть, что задание реально не выполнено.