Нотации моделирования бизнес процессов uml. BPMN (нотация): описание процесса. Моделирование бизнес-процессов — Flow Charting

BPMN (Business Process Management Notation) – это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализацией и воплощением бизнес-процесса.

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

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

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

История возникновения BPMN

Первая версия нотации BPMN вышла в мае 2004 года (BPMN 1.0). Следующая версия появилась в январе 2011 года (BPMN 2.0). Наконец, в январе 2013 года компания OMG выпустила ту версию, которая в основном используется и сегодня – BPMN 2.0.2.

Основные графические элементы BPMN

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

Элементы нотации BPMN – это элементы графической схемы, но также и элементы самого бизнес-процесса.

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

• Пул и Дорожки
• Действия
• Шлюзы или Развилки
• События
• Потоки
• Артефакты

В BPMN 2.0 элементы представлены в виде специальных значков. Создатели данной системы стремились к тому, чтобы набор значков был исчерпывающим и обеспечивал возможность наглядного отображения максимального разнообразия схем бизнес-процессов. В итоге значков очень много и с полным списком можно ознакомиться в документации по BPMN, которая переведена на русский язык членами Ассоциации BPM-профессионалов России. Здесь мы остановимся только на базовых элементах, без которых не обойдётся ни одна схема бизнес-процесса. Этого достаточно для общего знакомства с BPMN и понимания основных принципов нотации.

BPMN элементы “Пул” и “Дорожка”

Весь бизнес-процесс состоит из пулов: совокупности операций + лиц, которые эти операции выполняют.

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

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

BPMN элемент “Действие”

Под “действием” понимается единица работы, выполняемой в ходе исполнения бизнес-процесса. Действия могут быть как элементарными (задача/task), так и составными (подпроцесс/sub-process).

Есть несколько типов элементарных действий, которые отличаются условиями выполнения:

• Многократное выполнение действия в рамках одного процесса. Например, одно и то же действие может выполняться параллельно для каждого товара в заказе клиента.
• Циклическое действие выполняется многократно, пока заданное условие верно.

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

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

Здесь стоит отметить, что современные BPM-системы зачастую предлагают более широкий набор типов действий, чем предлагает BPMN. Например, в инструменте для моделирования бизнес-процессов в Comindware Business Application Platform вы найдёте графические элементы для нескольких типов элементарных действий, а также встроенных кейсов:

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

BPMN элементы “Развилка” или “Шлюз”

Под шлюзами понимаются элементы, определяющие ветвление и слияние потоков работ.

BPMN описывает 7 типов развилок. В качестве основных выделяют 2 типа:

	Шлюз исключающего «или»	Используется для создания альтернативных потоков процесса или сходящихся потоков управления.
	Параллельный шлюз	Используется для создания параллельных путей без оценки какого бы то ни было условия или для сходящихся потоков и синхронизации параллельных веток выполнения процесса.

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

Пример использования шлюза исключающего «или» для создания альтернативных потоков процесса:

• Этап 7. Звонок клиенту с целью оценить качество обслуживания.
• 1. Если клиент доволен, фиксация положительной оценки, закрытие бизнес-процесса.
• 2. Если клиент недоволен, выяснение причины.

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

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

BPMN элемент “Событие”

“Событие” является одним из главных элементов BPMN и служит для описания того, что должно случиться (в отличие от задачи, когда что-то должно быть сделано). Событием может быть, например, подписание договора, или разговор с клиентом.

Графические элементы событий в BPMN классифицируют двумя способами:

1. В зависимости от положения события на схеме процесса:

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

В случае с доставкой товара начальным событием будет, очевидно, заявка клиента. Либо же – звонок менеджера клиенту с предложением совершить покупку. Конечным событием в такой цепочке станет факт доставки, подтверждённый подписью клиента.

1. По типу события классификация следующая:

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

Очень часто начальные и конечные события являются событиями-сообщениями.

BPMN элементы “Потоки”

Поток – это последовательность действий, которая обозначается стрелкой. Элемент “поток” показывает какое действие после какого необходимо совершить.

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

BPMN элементы “Артефакт”

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

Основные виды артефактов:

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

Преимущества BPMN

BPMN-описание бизнес процесса имеет несколько преимуществ.

Первое – простота трансляции диаграмм в исполняемые модели с помощью языка формального описания бизнес-процессов.

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

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

Елена Гайдукова, маркетолог-аналитик, бренд-менеджер решений на базе , специалист по партнёрским отношениям.

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

VAD (v alue added chain diagram)

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

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

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

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

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

Модель нотации VAD можно нарисовать во множестве инструментов, например, в MS Visio, и многих других инструментах моделирования бизнес-процессов.

Моделирование бизнес-процессов – EPC (event-driven process chain)

Нотация EPC разработана профессором Августом Вильгельмом Шеером в рамках методологии инструментария ARIS. С помощью бизнес-процесс моделируется в виде перечня шагов процесса, запускаемых событиями. Нотация удобна для последующей регламентации бизнес-процесса, а также для анализа информационного потока бизнес-процесса (входящих/исходящих документов).

Свобода нотации EPC позволяет описывать в рамках моделирования бизнес-процессов дополнительные объекты, такие как операционные риски, контрольные процедуры, экранные формы, информационные системы, показатели и многое другое.

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

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

Существует множество вариантов нотации EPC, в формате столбцов, строк, а также с разными перечнями используемых объектов, однако все эти варианты доступны только в инструментарии ARIS, тогда как в остальных инструментах, например, MS Visio или Business Studio доступно моделирование бизнес-процессов EPC лишь в классическом формате.

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

Моделирование бизнес — процессов – BPMN (Business Process Model and Notation 2.0)

Нотация BPMN создана консорциумом Object Management Group (OMG) и предназначена для моделирования бизнес-процессов с целью их последующей автоматизации. Нотация BPMN используется для детального моделирования бизнес-процесса, а количество объектов в данной нотации превышает 100, что позволяет описать все нюансы поведения бизнес-процессов для того, чтобы информационная система могла преобразовать созданную модель в исполняемый код.

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

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

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

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

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

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

Моделирование бизнес-процессов — Flow Charting

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

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

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

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

Из недостатков Flow Charting можно выделить отсутствие типового перечня объектов и атрибутов, что является обратной стороной «свободы» данной нотации. Это позволяет моделировать один и тот же бизнес-процесс в данной нотации так, что модели будут серьёзно отличаться друг от друга.

Несмотря на то, что модели бизнес-процессов в нотации Flow Charting можно встретить достаточно часто, скорее всего она будет уходить в прошлое, уступая место более «строгим нотациям»

Моделирование бизнес — процессов – IDEF (Integrated Definition Language)

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

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

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

UML (Unified Modeling Languages )

Унифицированный язык моделирования (UML) – это набор нотаций и методов моделирования, предназначенных для описания требований к информационным системам, однако среди нотаций UML есть и специализированная нотация, предназначенная именно для моделирования бизнес-процессов. UML поддерживается Object Management Group (OMG), что сделало данную методологию достаточно распространенной среди ИТ-специалистов.

Данная нотация очень похожа на EPC и BPMN, единственное отличие в отображении логических операторов и событий, и, хотя по нотации UML существует множество книг, и поддержана она множеством инструментов моделирования, используется UML Activiti Diagram в основном для системного анализа и проектирования, и лишь незначительное число компаний используют UML, чтобы моделировать бизнес-процессы

VSM (Value Stream Mapping )

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

Нотация VSM была разработана как часть методологии бережливого производства, и использует набор специфических символов для отображения элементов затрат ресурсов и времени для анализа эффективности бизнес-процесса в проектах Lean 6Sigma. Карта потока создания ценности изображает физическое окружение и потоки материалов и продукции в производстве и используется для того, чтобы привязать к процессу затраты ресурсов и времени, и таким образом дать представление о производительности

Задача данной нотации вовлечь в анализ бизнес-процесса его участников, для того, чтобы стимулировать их к самостоятельному поиску возможностей оптимизации. Как правило модели VSM рисуются в проектах на Flip Chart и не требуют серьёзных средств моделирования бизнес-процессов, ведь на ее основании принимаются решения, а сама модель не становится основой ни для регламента, ни для ИТ-решения.

Основное при создании модели в нотации VSM это заполнение временных атрибутов по процессу, для поиска «бутылочных горлышек» и мест излишнего хранения запасов.

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

SIPOC

Аббревиатура SIPOC означает: Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (потребитель). Это шаблон документирования процессов, принятый в методологии Шесть сигм, фактически это даже не нотация модели, а формат таблицы, который позволяет описать бизнес-процесс на верхнем уровне. Модель SIPOC наиболее эффективно применять при определении границ бизнес-процесса, взаимодействующих сторон и входов/выходов процесса.

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

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

Моделирование бизнес-процессов – выводы

Итак, я рассмотрел некоторые нотации моделирования бизнес-процессов, которые можно встретить на российском рынке (более подробно они описаны в главе BPM CBOK , посвященной моделированию бизнес-процессов). Какую из нотаций выбрать для использования – это вопрос открытый, например, для моделирования бизнес-процессов организации на верхнем уровне я использую нотацию VAD, для первичного моделирования бизнес-процесса, выбранного для оптимизации, проще использовать SIPOC или VAD. Для создания детальных моделей бизнес-процессов – упрощённый BPMN для моделирования кросс-функционального взаимодействия или EPC для детального моделирования с целью формализовать информационный поток и множество объектов, связанных с бизнес-процессом. Ну а если необходимо автоматизировать бизнес-процесс в BPMS системе, то тут уже не обойтись без нотации BPMN.

Бесплатный BPMN инструмент

Cawemo - это бесплатный онлайн-инструмент для разработки, обсуждения и обмена диаграммами BPMN с вашей командой.

Бесплатный BPMN инструмент

Обзор

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

Мы присоединились к OMG в 2009 году как влиятельный член. С тех пор мы участвуем в разработке BPMN 2.0.

BPMN Примеры

Бизнес-правила и BPMN

Сценарий моделированияo

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

Это очень простой пример, который покажет нам, где применять BPMN, а где нет.

Роли двигателя Создать счет Запрос счета Вычислить скидку Создать счет Счет создан

Объяснение

Во время моделирования мы фокусируемся на потоке процесса. В этом примере процесс имеет два шага. Скидка рассчитывается до создания счета. Результат - очень простой процесс.

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

Поэтому имеет смысл разделить процессы и бизнес-правила.

Создать счет Сделать 2% скидку добавить 1% скидки Кто покупатель? Запрос счета Сумма заявки? Тип покупателя? Создать счет Счет создан Сделать 3% скидку Сделать 4% скидку Кто покупатель? добавить 1% скидки добавить 1% скидки 1000 - 1500 500 - 999 >2000 < 500 Тип A Тип A Тип A обычный обычный обычный

Зависимые экземпляры

Сценарий моделирования

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

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

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

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

Решение с сигнальным событием

Creditworthiness Check Посмотреть запросы Посмотреть запущеные события (с ними) запуск экземпляров одного и того же клиента? и того же клиента? Првоерить кредит Проверка выполнена Проверка выполнена Запись в базуданных нет да

Объяснение

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

Решение с событием Message

Проверка кредитоспособности Проверить запросы Проверить запущенные процессы тот же клиент) запущенные экземпляры одного клиента? проверить кредит кредит подтвержден ожидать события покупателя? проверить на ожидание случаев (из тот же клиент) запуск экземпляра завершен проинформировать ожидание экземпляра База Данных База Данных нет нет да да

Объяснение

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

Решение с таймером и циклом

Creditworthiness Check Проверить запросы проверить запущенные процессы (одного пользователя) запущенные экземпляры одного клиента? perform credit check подождать немного времени проверить кредит База Данных нет да

Объяснение

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

Принцип четырех глаз

Сценарий моделирования

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

Случаи использования

Варианты использования для этого шаблона многочисленны. Вот некоторые примеры:

• Утверждение оплаты
• Утверждение счета
• Утверждение контракта

Решение как диаграмма BPMN 2.0

1й согласователь Согласование запрошено Оценить запрос прочитать и прокомментировать Задача завершена Процеесы в двигателе Подтвердить запрос подтвердить или согласовать (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден 2й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена нет да да нет

Объяснение

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

В пуле двигателей используются пользовательские задачи. Эти пользовательские задачи соответствуют задачам, которые показаны в списке задач 1-го и 2-го утвердителей.

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

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

Вариации

Утверждение в качестве сбитых пулов

1й согласователь 2й согласователь Движок процесса подтвердить запрос отклонить или подтвердить (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден нет да да нет

Определение приемника с помощью LDAP

1й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена LDAP Движок процесса подтвердить запрос отклонить или подтвердить (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден determine 1st and 2nd approver 2й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена нет да да нет

Ежемесячное выставление счетов

Сценарий моделирования

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

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

Решение как диаграмма BPMN 2.0

Адвокат Консультация Консультация запрос Предоставить совет Зарегистрировать время Запрос отработал Счетчик клиента Клиент Учет месячного дохода 1й день в месяце Определить оплачиваемые часы создать и отправить счет получить деньги Счет исполнен 14 дней Отправить напоминание Только один в месяц Несколько за месяц

Объяснение

Наиболее важным аспектом диаграммы является ее структура.

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

Конечно, эти два пула не полностью независимы друг от друга. Зачем? Они работают над одними и теми же данными - листом времени клиента. Наша способность моделировать такое связанное с данным соединение очень ограничена в BPMN. Это связано с тем, что BPMN ориентирован скорее на поток управления, чем на поток данных.

Однако мы можем использовать элемент хранилища данных для моделирования этого соединения на уровне данных.

Неправильный способ моделирования

Адвокат Консультация Консультация запрос Предоставить совет Зарегистрировать время 1 в следующем месяце определить оплачиваемые часы создать и отправить счет Получить деньги Счет исполнен 14 дней Отправить напоминание Клиент

Объяснение, почему это неправильно

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

Дополнительная информация, необходимая после задачи пользователя

Сценарий моделирования

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

Решение 1. Запросить информацию от другого пользователя

Пользоваель зашел Пользоваель зашел Движок процесса Задание для пользователя Нужна доп. информация? Запрос информации (от пользователя) ... нет да

Решение 2. Запросить информацию у технической службы

Пользоваель зашел Some Technical Service Движок процесса Задание для пользователя Нужна доп. информация? Отправить запрос Информация получена... нет да

Обработка партии заказов с рынка

Ситуация

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

Решение как диаграмма BPMN 2.0

ERP Система Рынок Импортирова заказы в ERP Каждые 10 минут Собрать все заказы с рынка Процесс заказа Новый одиночный заказ Проверить данные заказа данные корректны? Импорт заказа в ERP систему Один заказ в процессе Дата заказа некорректна Все заказы в процессе отдельные Заказ нет да

Объяснение

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

Переназначение пользовательских задач

Сценарий моделирования

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

Решение 1: Услуга передачи сообщений и переназначение

Заметка

Это имеет смысл, если движок вызывает службу для определения нового правопреемника.

Решение 2: Правила передачи сообщений и правила переназначения

Пользоваель зашел Движок процесса определить правопреемник задача пользователя... правопреемник недоступен

Заметка

Это имеет смысл, если движок вызывает механизм правил для определения нового правопреемника.

Решение 3. Событие границы сообщения и неявное переназначение

Пользоваель зашел Движок процесса задача пользователя... правопреемник недоступен

Заметка

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

Двухэтапная эскалация

Сценарий моделирования

Мы будем использовать следующий пример, чтобы проиллюстрировать, как моделировать двухэтапную эскалацию с использованием BPMN 2.0. Когда мы хотим пиццу, мы заказываем ее. Иногда доставка пиццы поднимается, и доставка занимает больше 20 минут. Затем мы жалуемся на службу доставки. После этого мы даем им еще 30 минут, чтобы доставить пиццу. Если они не сделают это своевременно, мы откажемся и отменим наш заказ.

Решение 1. Два шлюза на основе событий

Пицца разыскивается Заказать пиццу Пицца доставлен Есть пиццу Пицца съедена 30 минут Жаловаться в сервис доставки Пицца доставлен 20 минут Заказ отменен Заказ отменен

Преимущества этого решения

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

Недостатки этого решения

Шлюз, основанный на событиях, не является интуитивным символом BPMN стандарта BPMN, необходим опыт.

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

Решение 2: Принять задание с включенными таймерами

Пицца разыскивается Заказать пиццу Есть пиццу Пицца съедена Жаловаться в сервис доставки Заказ отменен Заказ отменен Ждать пиццу Жаловаться на заказ 50 минут 30 минут

Преимущества этого решения

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

Недостатки этого решения

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

То, как работает прерывающий и не прерывающий таймер, требует глубокого понимания приложенных событий.

Решение 3. Один шлюз на основе событий с общим таймером

Пицца разыскивается Заказать пиццу Пицца доставлен Есть пиццу Съесть пиццу Время вышло! Жаловаться на доставку Заказ отменен Заказ отменен Выполнено задание? Таймер показал больше да нет

Преимущества этого решения

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

Недостатки этого решения

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

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

BPMN Modeling Styles

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

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

Приведенные ниже примеры иллюстрируют проблему абстрактным примером.

Хороший пример обработки потоков

Процесс запущен выполнить первуюу задачу Обязательное действие? выполнить задачу два Процесс завершен выполнять задачу три ok? да План A План B нет

Встречный пример

Процесс запущен Задание первое Обязательное действие? perform task two Процесс завершен Задание третье Ок? да План A План Б нет

Самое главное: каждый символ BPMN должен иметь ярлык.

События должны быть помечены с использованием причастия «объект + прошлое». Начальные события всегда должны маркироваться указанием триггера процесса. Конечные события должны быть помечены конечным состоянием процесса.

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

Задачи должны быть помечены с помощью объекта + глагол. Это заставляет модельного человека сосредоточиться на том, что действительно сделано во время задания.

Шлюзы X-OR должны быть помечены вопросом. Потоки исходящей последовательности должны быть помечены возможными ответами на эти вопросы (условия).

Хороший пример наименования

Проверить дату заказаa Сервис Заказа Заказ получен Проверить заказ Проверить заказ Дата заказа корректна Дата заказа корректна? Дата заказа некорректна да нет

Общая версия

Имя процесса Роль, выполняющая процесс Триггер oпроцесса Объект + глагол Объект + Причастие Первое конечное состояние после окончания процесса Вопросы? Второе конечное состояние после окончания процесса ответ 1 ответ 2

Пример счетчика

Заказ сделан Старт Проверить Записать статус в БД Конец Ошибка Ок

Этот пример BPMN - это создание хорошего макета моделей процессов. Чем лучше макет, тем выше степень понимания. Это то, чего мы хотим достичь, когда мы создаем модели процессов.

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

Хороший пример симметричной модели

Готовить салат Появился голод Выбрать рецепт Какое блюдо? Готовить макароны Есть еду Голод утален Готовить стейк Какие компоненты? Выбрать: - Салат - Макароны - Стейк Стейк Макароны Салат Теплая еда

Встречный пример

Готовить салат Голод появился Выбрать рецепт Какое блюдо? Готовить макароны Съесть еду Голод утален приготовить стейкk Какие компоненты? Выбрать: - Салат - Макароны - Стейк Стейк Макароны Салат теплая еда

Хороший пример симметричной модели 2

Свежий товар Заказ доставлен использован старый товар Сумма заказа более 25.000 €? Процесс заказа Организовать доставку Package goods Доставить заказ Процесс заказа да нет

Встречный пример 2

Свежая продукция Закад доставлен старый товар на складе Сумма заказа больше 25.000 €? Заказать Сделать доставку Товар Доставка заказаr Процесс заказа да нет

Причина проста. Люди склонны интерпретировать размеры задач, хотя они не имеют семантики в стандарте BPMN.

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

Некоторые считают, что большие задачи занимают больше времени, чем меньшие задачи - по данным BPMN это неверно.

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

Хороший пример равных размеров задач

1й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена

Встречный пример

1й согласователь Подтвердите запрос Сделан запрос документ и комментарий удалены задача завершена

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

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

Контекстная модель:

Название: Реализация готовой продукции со склада.

Цель: Увеличение продаж.

Точка зрения: Начальник отдела продаж.

Входные данные: копия накладной, копия договора, заказ.

Выходные данные: требование, счет, выписка из журнала, отчет, отказ от выполнения заказа.

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

Механизмы: сотрудник отдела продаж.

Контекстная модель представлена на рисунке 18.

Рис.18. Контекстная диаграмма

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

Рис.19. Диаграмма декомпозиции

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

Основную функцию «Организация оплаты» можно декомпозировать на следующие действия: подсчет суммы оплаты, выставление счета, оплата счета. Основную функцию «Организация выдачи» декомпозируем так: выписка требования, сообщение на склад о подготовке товара, подготовка выписки для отдела договоров, изменение в журнале продаж. Основную функцию «Подготовка отчетов» декомпозируем на такие действия: анализ данных, выборка данных, печать отчетов. Соответствующие диаграммы представлены на рисунке 21, 22, 23.

Рис.20. Диаграмма декомпозиции A1

Рис.21. Диаграмма декомпозиции A2

Рис.22. Диаграмма декомпозиции A3

Рис.23. Диаграмма декомпозиции A4

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

⇐ Предыдущая567891011121314Следующая ⇒

Похожая информация:

Поиск на сайте:

Нотация ARIS Value-added Chain Diagram (ARIS VAD)

На рис. 2.30 представлена одна из важнейших нотаций ARIS - нотация ARIS VAD. Диаграмма цепочки процесса, добавляющего ценность, использует­ся при описании бизнес-процессов организации на верхнем уровне. Как прави­ло, консультанты, использующие ARIS, рекомендуют выделять шесть-восемь бизнес-процессов верхнего уровня и описывать их в нотации ARIS VAD. За­тем выполняется декомпозиция полученных процессов верхнего уровня в но­тации ARIS VAD или ARIS еЕРС.

Модели AS-IS и ТО-ВЕ

Рассмотрим объекты нотации ARIS VAD, представленные на рис. 2.30.

Основным объектом нотации ARIS VAD является Value-added chain - процесс или некоторая группа функций организации, которая служит для получения добав­ленной ценности. Объекты соединяются между собой пунктирной стрелкой, кото­рая имеет тип is predecessor of («является предшественником»). Этот тип связи по­казывает, что один процесс - предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные свя­зи. Поэтому термин is predecessor of, на наш взгляд, является неудачным.

Между процессами, приведенными на рис. 2.30, могут быть отображены пото­ки материальных ресурсов и информации, для описания которых можно вос­пользоваться объектами типа Cluster и Technical term, соответственно. Для опи­сания инфраструктуры, необходимой для выполнения процесса, в данном приме­ре выбраны типы объектов Product/Service и Information service. Выбор типов объек­тов для отображения реальных потоков является в достаточной степени услов­ным. Очень важно в начале работ по моделированию процессов определиться, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в случае примера, приведенного на рис. 2.30, можно было бы показать все потоки (информационные и материальные) при помощи объектов типа Technical term.

На рис. 2.30 показаны также объекты Organizational unit, отображающие под­разделения, выполняющие соответствующие процессы.

Объекты соединяются между собой при помощи связей определенного типа (см. рис. 2.30). Например, информационный поток, отображаемый объектом Cluster, является входящим для первого процесса и связан с ним при помощи стрелки типа is input for («является входом для»). Другой пример - тип связи executes («исполняет») между объектами Value-added chain и Organizational unit. Тип связи is used by показывает, что Product/Service используется процессом и т.д. Таким образом, в методологии ARIS важнейшим требованием является корректный выбор и дальнейшее использование связей и объектов определенного типа.

На рис. 2.31 представлен пример модели верхнего уровня, выполненный в нотации ARIS VAD. Вы уже знакомы с этим процессов. Выше, на рис. 2.16, этот же процесс представлен в нотации IDEF0.

88____________________________ ВВ. Репин, В.Г. Елиферов

Глава 2 Выбор методологии описания бизнес-процессов________________________________ 89

Принципы построения диаграммы процесса верхнего уровня в нотации ARIS VAD существенно отличаются от нотации IDEF0. Так. в нотации ARIS VAD стрелки могут входить в любую сторону объекта Value-added chain. (Напомним, что в нотации IDEF0 каждая сторона объекта Activity (функция) имеет глубоки и смысл). На рис. 2.32 представлена ситуация, возможная в нотации ARIS VAD. когда на диаграмме процесса приводится множество обратных связей, которые понятны только аналитику, создавшему модель.

Указанный недостаток нотации ARIS VAD можно исключить, заранее ого­ворив возможность специального использования обратных связей, как, напри­мер, на рис. 2.33. Отметим, что у специалистов по ARIS такой подход может вызвать критику, так как противоречит нотации. Но мы придерживаемся той точки зрения, что это вполне допустимо, так как модели верхнего уровня в нотации ARIS VAD реально могут быть использованы лишь в качестве простей­шего способа графического изображения цепочки процесса.

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

90 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению

2.7.2. Нотация ARIS еЕРС - расширение нотации IDEF3

Нотация ARIS еЕРС (extended Event Driven Process Chain) - расширенная цепочка процесса, управляемого событиями.

Нотация разработана специалис­тами компании IDS Scheer AG, Германия, в частности, профессором Шеером. В табл. 2.2 приводятся основные объекты, используемые в рамках нотации.

Таблица 2,2 Основные объекты, используемые при построении диаграмм еЕРС

Помимо основных объектов, указанных в табл. 2.2, при построении диаграм­мы еЕРС могут быть использованы многие другие объекты. На практике приме­нение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и затрудняет ее прочтение.

91

Для понимания смысла нотации ARJS сЕРС рассмотрим основные используе­мые типы объектов и связей (рис. 2.34-2.38). На рис. 2.34 представлена простей­шая модель ARIS еЕРС, описывающая фрагмент бизнес-процесса предприятия.

Из рис. 2.34 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрел­ка, соединяющая Событие 1 и Функцию 1, «активирует» (activates) или иници­ирует выполнение Функции 1. Функция 1 «создает» (creates) Событие 2, за которым следует символ логического оператора «И», «запускающий» выпол­нение Функций 2 и 3.

Внимательный анализ нотации ARIS еЕРС показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием ARIS еЕРС является наличие объекта «событие» (event). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выпол­няется та или иная последующая ветвь процесса. Нотация ARIS еЕРС называет­ся, очевидно, расширенной именно вследствие наличия в ней объекта «событие» (в IDEF3 такого объекта нет). На рис. 2.35 приводятся примеры применения символов логики и событий при построении моделей в нотации ARIS еЕРС.

При построении моделей в ARIS еЕРС необходимо соблюдать следующие правила:

1. Каждая функция должна быть инициирована событием и завершаться
событием;

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

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

На рис. 2.36 показано применение различных объектов нотации ARIS еЕРС при создании модели бизнес-процесса.

92____________________________ ВВ. Репин, В.Г. Елиферов. Процессный подход к управлению

Из рис. 2.35 и 2.36 видно, что бизнес-процесс в нотации ARIS еЕРС представ­ляет собой последовательность процедур, расположенных в порядке их выполне­ния. Следует отметить, что реальная длительность выполнения процедур в ARIS еЕРС визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено вы-

Глава 2 Выбор методологии описания бизнес-процессов___________________________________ 93

полнение двух задач одновременно. Используемые при построении модели СИМ-ЮЛЫ логики позволяют отразить ветачение и слияние бизнес-процесса. Для по­лучения информации о реальной длительности процессов и визуального отобра­жения загруженности персонала в процессе можно использовать другие инстру­менты описания, например диаграммы Гантта в системе MS Project.

Рассмотрим примеры применения нотации ARIS еЕРС для описания биз­нес-процессов. На рис. 2.37. представлен бизнес-процесс обработки заказа кли­ента. Этот же процесс изображен в нотации IDEF3 на рис. 2.23.

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

Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: 1) заказ не соответствует номенклатуре и 2) произ­водство невозможно. Для отображения на схеме процесса этих вариантов ис­пользуется символ логического оператора «ИЛИ» и т.д.

Как видно из рис. 2.37, схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и долж­ностей. Схема в ARIS eEPS визуально предстаатяется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает раз­мер схемы в IDEF3.

Рассмотренный выше процесс может быть представлен также в нотации ARIS PCD (Process Chain Diagram) - разновидности ARIS еЕРС. На рис. 2.38 показан бизнес-процесс обработки заявки клиента в нотации ARIS PCD. При описании этого процесса использованы все объекты, которые составляют процесс, по­казанный на рис. 2.37, но расположены они в виде столбцов таблицы. В пер­вом столбце представлены события и некоторые символы логики, во втором - функции, в третьем - входящие и исходящие документы, в четвертом - виды прикладного программного обеспечения, в пятом - должности сотрудников, задействованных в процессе. Такое представление процесса является более «стан­дартным». Оно лучше подходит для целей документирования процессов. Одна­ко представление в нотации ARIS PCD обладает существенным недостатком - его можно эффективно применять для простых (не более пяти-восьми функ­ций), желательно линейных, процессов. Сложные процессы с разветвленной логикой отображать при помощи нотаций ARIS PCD неудобно, что наглядно видно на рис. 2.38.

94_________________________________ ВВ. Репин. В.Г. Елиферов. Процессный подход к управлению

Рис. 2.37. Пример модели процесса

Глава 2 Выбор методологии описания бизнес-процессов_______________________________ 95

в нотации AR1S eEPC.

96____________________________ В.В, Репин, В.Г. Елиферов. Проц ессный подход к управлению

Рис. 2.38. Пример обработки

Глава 2 Выбор методологии описания бизнес-процессов 9 7

заявки и нотации AR1S PCD.

98 В.В. Репин, В Г. Елиферов Процессный подход к управлению

Нотация AR1S Organizational Chart

Нотация ARIS Organizational Chan яа!яется одной ИЗ основных нотаций ARIS и предназначена для построения схем организационной структуры предприя­тия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения пред­приятия в виде иерархической структуры, как показано на рис.

Модель строится из объектов Organizational unit, Position, Internal person и др.

Заложенные в нотацию типы связей позволяют отразить различные виды от­ношений между объектами организационной структуры. В представленном на рис. 2.39 примере Предприятие управляется Директором, при этом используется тип связи is Organization Manager for. Иерархия подразделений строится при по­мощи связей типа is composed of. Кроме того, могут быть указаны должности - Position и фамилии реальных сотрудников, их занимающие - Internal person, тип связи occupies.

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

Глава 2 Выбор методологии описания бизнес-процессов_________________________________ 99

Предыдущая78910111213141516171819202122Следующая

Модель AS-IS – это модель «как есть», т.е. модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. Построение функциональной модели AS-IS позволяет четко зафиксировать, какие процессы осуществляются на предприятии, какие информационные объекты используются при выполнении функций различного уровня детализации.
На основе модели AS-IS достигается консенсус между различными этапами процесса по тому, «кто что сделал» и что каждый этап добавляет в процесс. Функциональная модель AS-IS является отправной точкой для анализа потребностей предприятия , выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов. Модель AS-IS позволяет выяснить, «что и как мы делаем сейчас» перед тем, как определить то, «что и как будет делаться завтра». Анализ функциональной модели AS-IS позволяет понять, где находится проблемная ситуация, в чем будут состоять преимущества новых процессов и каким изменениям подвергнется существующая структура организации процесса. Исследование необходимости реструктуризации (выявление и ликвидация недостатков) в существующих процессах достигается за счет применения декомпозиции (анализа), производящаяся даже там, где функциональность на первый взгляд является очевидной.

Функциональная модель AS-IS

Так, например, признаками неэффективности существующих процессов могут быть:

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

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

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

2. Определить какой тип модели бизнес процесса вам необходимо построить и выбрать список методологий, которые могут быть использованы при моделировании (используйте путеводитель, описанный ниже);

3. Сравнить методологии и нотации моделирования для вашего типа модели и выбрать подходящую для вас методологию:

• Методологии моделирования бизнес процессов верхнего уровня и потоков данных;
• Методологии моделирования потоков работ;
• Методологии моделирования структуры информации.

4. Построить модель.

Путеводитель по нотациям и методологиям

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

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

Классические методологии

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