Бизнес процесс это работа плюс управление потоками работ

Управление бизнес-процессами — активно развивающаяся область, и многие термины в ней еще не до конца устоялись. Различные авторы прибегают к таким понятиям как BPMS, системы управления потоками работ (Workflow), системы управления документооборотом (Docflow), системы интеграции масштаба предприятия (EAI -Enterprise Application Integration) и т.п.

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

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

Бизнес процесс по приему на работу за 15 минут без регистраций и смс

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

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

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

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

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

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

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

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

Дадим формальное определение исполнимого бизнес-процесса, основу которого составляют идеи С. Яблонского и С. Бусслера.

Исполнимый бизнес-процесс определяется при помощи задания следующих перспектив (точек зрения или слоев/уровней рассмотрения):

• • поток управления (control-flow perspective);
• • данные (data perspective);
• • ресурсы (resource perspective);
• • операции (operational perspective).

Рассмотрим подробно все уровни формального определения исполнимого бизнес-процесса. При этом в качестве примера будем ис пользовать бизнес-процесс «Оплата счета поставщика». При его помощи постараемся пояснить все перспективы формального определения бизнес-процесса.

ПЕРСПЕКТИВА ПОТОКА УПРАВЛЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Остальные прямоугольники со скругленными краями являются узлами-действиями. Элементы в виде ромбов соответствуют маршрутным узлам- местам разветвления маршрутов точек управления.

В начале бизнес-процесса бизнес-менеджер поставок вводит параметры предполагаемого платежа (номер счета, дата счета, сумма счета, фирма-контрагент, фирма-агент, комментарий).

Получить данные из бюджета к_________________>

Рис. 1.3.1. Пример схемы бизнес-процесса «Оплата счета поставщика» (BPMN-нотация)

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

Бизнес-процессу «Оплата счета поставщика» соответствуют следующие бизнес- правила:

1) если внешнее приложение, вызванное в узле «Получить данные из бюджета», вернуло значение «нет» в переменную «Превышен ли бюджет подразделения», то следует перейти к проверке лимита, в противном случае — перейти в узел завершения бизнес-процесса;

• 2) если значение переменной «Сумма счета» меньше значения константы «Лимит разового платежа», нужно перейти к узлу «Оплатить счет», в противном случае — к узлу «Подтвердить платеж»;
• 3) если исполнитель, принадлежащий к роли «Финансовый директор», заполняя поля в соответствующей форме, вернул значение «да» в переменную «Утвердил ли руководитель», то перейти к узлу «Оплатить счет», в противном случае — к узлу завершения бизнес-про-цесса.

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

Пример, представленный на рис. 1.3.2, соответствует этапу оформления очередного отпуска сотрудником предприятия.

Рассмотреть заявку на отпуск

Ознакомиться с уходом сотрудника в отпуск X_________________/

Ознакомиться с сообщением об одобрении отпуска руководителем

Ознакомиться с сообщением об отказе X____________/

Рис. 1.3.2. Схема бизнес-процесса рассмотрения заявления об уходе в отпуск (BPMN-нотация).

Данный пример иллюстрирует следующее:

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

ПЕРСПЕКТИВА ДАННЫХ

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

Список глобальных переменных

Источник: bstudy.net

Управление потоками работ

Понятие поток работ (workflow) — одно из базовых в современ­ной практике управления и, в частности, в области ИПИ. Это по­нятие объединяет подходы к формализации и управлению бизнес-процессами предприятия, а также программные средства, реали­зующие эти подходы. Популярность и многообразие реализаций технологий workflow привели к созданию в середине 1990-х гг. меж­дународной ассоциации WfМС (Workflow Management Coalition — WfMC), занимающейся стандартами, регламентирующими требо­вания к системам workflow и средствам их реализации.

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

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

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

Приведем два определения из глоссария WfMC.

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

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

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

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

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

Буч Г. Язык UML. Руководство пользователя: пер. с англ. / Г. Буч, Д. Рамбо, А.Джекобсон. — М.: ДМК, 2000. — 432 с.

Карпова Т. С. Базы данных: модели, разработка, реализация / Т. С. Карпова. — СПб.: Питер, 2001. — 304 с.

Рамел Д. Visual Basic.Net. Справочник программиста / Д. Рамел. — М.: Эком, 2002.

Конноли Т. Базы данных. Проектирование, реализация и сопровож­дение. Теория и практика: пер. с англ. / Т. Конноли, Б. Каролин. — 3-е изд. — М.: Изд. дом «Вильяме», 2003. — 1440 с.

Маклаков СВ. CASE-средстваразработки информационных систем / С. В. Маклаков. — М.: Диалог-МИФИ, 2000. — 256 с.

Матиас Н. Знакомьтесь: World Wide Web: пер. с нем. / Н. Матиас. — Киев: Торгово-издательское бюро BHV, 1996. — 336 с.

Толковый словарь по вычислительным системам / [под ред. В. Ил-лингуорта и др.; пер с англ. А. К. Белоцкого и др.]; под ред. Е. К. Маслов­ского. — М.: Машиностроение, 1990. — 560 с.

Фуфаев Э. В. Пакеты прикладных программ / Э. В. Фуфаев, Л. И. Фу-фаева. — М.: Изд. центр «Академия», 2004. — 352 с.

Фуфаев Э. В. Базы данных / Э. В. Фуфаев, Д. Э. Фуфаев. — М.: Изд. центр «Академия», 2005. — 320 с.

Источник: studopedia.su

Лекция 13. Описание процессов с помощью моделей Work Flow.

На рис. 1 приведен простейший пример схемы потока работ, выполненной без использования специальной методики (новации). Изображены три сотрудника и взаимодействие между ними.

Рис. 1. Упрощённая схема потока работ.

На рисунке видно, что работники последовательно выполняют операции процесса. Это, например, означает, что операция 4 не будет выполнена, пока не завершатся операции 1, 2 и 3. Стрелки в данном случае показывают последовательность операций, а текст над ними демонстрирует, в какой форме передается информация между сотрудниками (бумажный документ, электронный файл и т. п.). На более крупном уровне описания вся рассмотренная цепочка операций могла бы выглядеть как одна стрелка, изображающая деятельность по выполнению процесса.

Ранее нами была рассмотрена методика построения схем цепочек создания ценности (ЦСЦ). Этот метод очень удобен для описания бизнес-процессов на верхнем и среднем уровнях. Что касается детального уровня рассмотрения, то необходимо использовать другой инструмент, а именно схемы потоков работ (Work Flow). Иногда этот детальный уровень рассмотрения процессов называют операционным.

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

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

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

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

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

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

Рис. .2. Операции и связи между ними

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

Следует заметить, что данную деятельность весьма удобно осуществлять в MS Project.

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

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

Рис. 3. Отображение информационных и материальных потоков на схемах потоков работ

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

На рис. 2 и 3 изображены простейшие ситуации. А как показать на схеме более сложный случай, когда после выполнения операции 1 начинается параллельное осуществление нескольких операций? Необходимо использовать специальный графический символ, который будет указывать на ветвление процесса. В качестве такого символа часто используют ромб, как это показано на рис. 4.

Рис..4. Ветвление процесса

Внутрь ромба вписано условие, которое указывает на возможные результаты завершения операции 1. Например, эта операция заключается в анализе заявки клиента на поставку товара и проверке наличия последнего на складе. В подобном случае условие в ромбе может быть сформулировано следующим образом: «Товар есть на складе?». Если да, то можно выписывать клиенту счет. Если нет — нужно, например, уведомить об этом потребителя, согласовать сроки поставки и т. д.

Во многих нотациях (например таких, как ARIS еЕРС или IDEF3) для отображения ветвления (слияния) потоков работ используются специальные символы логики: «И», не исключающее «ИЛИ», исключающее «ИЛИ». Тем не менее на практике при регламентации потоков работ можно ограничиться использованием ромба, который заменяет (в определенной степени) все специальные операторы логики (И, ИЛИ, НЕ).

Воспроизводить на схемах ветвление процесса (и использовать ромб) целесообразно для:

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

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

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

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

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

Рис. 5. Отображение обратных связей на схемах потоков работ

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

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

Схемы потоков работ удобно строить при помощи программного продукта MS Visio или Business Studio. На рис. 6 показан фрагмент схемы потока работ, построенной в MS Visio.

Рис. 6. Фрагмент схемы потока работ

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

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

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

• простые схемы;
• простое сочетание схемы и таблицы;
• схемы, совмещенные с таблицами;
• схемы «свим лайн», в том числе:

— схемы с указанием участников процесса;

— схемы с указанием участников процесса и с привязкой ко времени;

Источник: studfile.net