Моделирование бизнес-процессов средствами языка моделирования uml Основные сведения. Диаграмма бизнес процессов


Искусство создания диаграмм процессов / Хабр

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

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

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

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

Итак, сначала договоримся об основном предмете статьи — диаграммах процессов (далее для лаконичности иногда просто диаграммы). Как правило, диаграмма процессов представляет собою набор графических объектов, поименованных текстом, которые связаны между собою стрелками. Объекты обозначают процессы, ресурсы, состояния и т. д. Стрелки же обозначают порядок перехода управления от одного объекта к другому. Следует отличать диаграммы процессов от внешне очень похожих структурных диаграмм, диаграммы процессов предполагают динамику, в то время когда структурные диаграммы носят статичный характер, описывая конструктивные взаимосвязи объектов, обычно это описание организационных иерархий, структур данных или “карты разума”.

Существует много нотаций описания диаграмм процессов, это IDEF0, BPMN, UML, EPC, CMMN и другие. Данная статья в равной степени относится к ним всем, в примерах использована нотация собственного приложения.

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

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

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

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

Шаг 1. Разместите свои цели как ресурсы в правом нижнем углу диаграммы. Обычно процессы, которые имеет смысл описывать, имеют чётко выраженную конечную цель или группу целей. Такой целью может также служить состояние, после которого дальнейшее исполнение процесса не имеет смысла. Как правило, процессы создаются под конкретные цели, и зачастую очевидно, что написать в правом нижнем углу диаграммы. Однако иногда бывает дальновидным указать не только положительную цель, но перечислить состояния, в которых исполнение процесса прерывается, но исходная цель не достигнута или достигнута не полностью. Рекомендуется явно перечислять подобные негативные цели в случаях, если вероятность достижения основной цели ниже 60%.

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

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

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

Шаг 4. Перед целями, имеющимися на диаграмме, разместите процессы, которые приводят к достижению данных целей, и соедините новые процессы с их целями.Заметьте, что пока на нашей диаграмме процессов не было ни одного процесса, это неслучайно. Специфика нашего мышления такова, что, начиная что-то делать, мы больше концентрируемся на процессах, немного забывая, что суть нашей деятельности в целях. Диаграммы процессов, состоящие из одних только процессов, — частое явление, однако следует помнить, что мы стремимся к непрерывности и ясности изложения, а зачастую указание целей исполнения процесса говорит о нём больше, нежели название процесса и его описание. Старайтесь всегда явно указывать цели процесса, на практике это означает, что стрелка от одного процесса к другому — это редкое явление, обычно между процессами располагается промежуточный ресурс, являющийся результатом исполнения одного процесса и исходным ресурсом для другого. В некоторых формализмах (например DFD) сама стрелка может являться описанием ресурса. Однако если такой промежуточный ресурс очевиден, то ради упрощения схемы его можно опустить и провести стрелку от одного процесса к другому. Например, если в прачечной после процесса “Сушка” следует процесс “Глаженье”, то в некоторых случаях промежуточный ресурс “Сухое бельё” можно пропустить.

Шаг 5. Проведите связи от имеющихся на диаграмме ресурсов к использующим их процессам; если необходимого для процесса ресурса нет на диаграмме, добавьте новую цель, вернувшись к Шагу 3 ↑. Очевидно, что если требуемого процессом ресурса нет, то это приводит к противоречию в исполнении задачи, так как соблюдены не все причины для желаемых следствий.  Следовательно, необходимо исполнить критерий полноты — всё необходимое для исполнения каждого процесса должно быть в наличии. Впрочем, не всегда оправдано явно указывать очевидные ресурсы, например, при обработке детали станком одним из очевидных ресурсов является электроэнергия, явное выделение этого ресурса, скорее всего, не сделает диаграмму понятнее, однако без значимых причин усложнит её. Помните о своей аудитории: часть диаграммы зритель всегда достраивает мысленно, это неизбежно. Старайтесь, чтобы мнимая часть диаграммы касалась очевидных всем моментов, более того, слишком явные вещи, выписанные на диаграмме, могут утомлять и даже раздражать.

Шаг 6. Проведите связи между процессами, исполнение которых зависит друг от друга. Попарно проверьте все процессы, размещённые на диаграмме, нет ли между ними неявных зависимостей или взаимного влияния. Например, часто полезно “грязные” процессы группировать вместе, чтобы экономить на очистке рабочей области. Также если два процесса конкурентно используют ограниченный ресурс, то их следует развести во времени, проложив связь от одного из них к другому.  Заметьте, что ресурсы, которые мы не отображаем на диаграмме, тоже могут быть причиной скрытых зависимостей, к примеру, когда два процесса используют энергоёмкие станки, которые не следует включать одновременно.

Шаг 7. Убедитесь, что диаграмма легко читается и содержит не более 20 объектов; если это не так, сгруппируйте несколько контекстно связанных объектов в один объект подходящего типа с вложенной диаграммой, содержащей данную группу. Практика показывает, что когда диаграмма содержит более 20 объектов (ресурсов или процессов), то схема перестаёт восприниматься цельно, а начинает выглядеть, как лабиринт, в котором зрителю нужно выискивать интересующие его пути. С другой стороны, редко какой проект или бизнес-процесс уложится в такое небольшое число объектов. К счастью, то, что не вместит одна диаграмма, поместится на нескольких, не стремитесь всё изложить сразу, помните: всегда можно сделать ещё одну диаграмму. 

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

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

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

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

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

Шаг 9. Для процессов, не являющихся элементарными операциями, постройте вложенную диаграмму, начиная с Шага 1. На Шаге 7 мы синтетически создавали новую задачу из группы объектов и детализировали её вложенной диаграммой. На этом шаге делается то же самое, но аналитически: мы пытаемся сложный объект разложить на более простые процессы и отобразить их во вложенной диаграмме. В управлении проектами этот процесс называют структурной декомпозицией работ. Разбивая задачи на более мелкие или объединяя их в более крупные, следует следить, чтобы задачи одного уровня, отображаемые в одной диаграмме, были приблизительно равны по значимости и трудоёмкости.

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

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

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

Ниже приложена диаграмма пошагового процесса, изложенного в статье, потратьте несколько минут на её изучение.

UPD Следующая статья: «Техническая композиция диаграмм процессов»

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

habr.com

Краткое описание BPMN с примером / Блог компании Trinion / Хабр

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

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

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

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

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

Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.

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

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

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

BPM: ОСНОВНЫЕ ПОНЯТИЯ

Для того чтобы разобраться, что такое BPMN, нужно понимать, что часть этой аббревиатуры «BPM» имеет две расшифровки — Business Process Modeling и Business Process Management. В первом случае – это непосредственно моделирование бизнес процесса, а во втором – управление бизнес-процессами, т.е. общая система, частью которой и является Business Process Modeling.

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

Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.

Можно сказать, что BPMN является частью двух важнейших составляющих:

  • BPM (Business Process Modeling) – это та среда, где вы занимаетесь непосредственно моделированием. Самостоятельно или в команде.
  • BPMS (Business Process Modeling System) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Comundo,ELMA и пр.
  • Итак, основные понятия у нас есть. Подробнее о BPM я планирую поговорить в следующих статьях.

ЯЗЫК ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ

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

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

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

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

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

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

НЕМНОГО ИСТОРИИ BPMN

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

Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative. Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.

Следующая версия BPMN 1.1 выходит в январе 2008, и здесь разработкой и поддержкой занималась уже Object Management Group, организация, появившаяся в результате слияния BPMI с другой компанией-разработчиком программного обеспечения.

Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.

В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.

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

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

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

ИЗ ЧЕГО СОСТОИТ НОТАЦИЯ BPMN?

И здесь я хочу сделать небольшое отступление. Дело в том, что перевод терминов и понятий с английского языка на русский – занятие сложное. Найти наиболее точное слово обычно может специалист, но переводом занимается совсем другой человек, часто вообще не имеющий понятия о сути тех понятий, которые он переводит. В результате появляется множество неточностей, понятия усложняются, возникает путаница. Об особенностях перевода и сложностях применения терминов в сравнении с графикой я уже писал, например, в статье Знакомство с нотацией IDEF0 и пример использования (см. раздел “Несколько слов о преимуществах графики”).

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

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

Язык описания бизнес-процессов опирается на следующие базовые объекты:

  • Event – Событие;
  • Activity – Действия;
  • Gateway – Шлюзы или Развилки;
  • Flow – Поток.
  • Date – Данные;
  • Artefact – Артефакты;
  • Swimline – «плавательные дорожки»;
  • Pool (Пул) — набор.
Здесь я не буду рассказывать обо всех существующих элементах BPMN, их на самом деле очень много. И при необходимости вы всегда можете воспользоваться документацией по BPMN, где подробно описаны все существующие элементы.

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

EVENT (СОБЫТИЕ)

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

Например, опишем процесс получения заказа от клиента по телефону:

  • Событие Старт – это входящий звонок от клиента.
  • Событие Финиш – это отправка готового расходного документа на печать.
Конечными могут быть самые разные события. Здесь и запись перечня потребностей клиента, и сохранение документа заказа, и создание на его основе расходной накладной, налоговой и т.д.

ACTIVITY (ДЕЙСТВИЯ)

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

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

Обычно действия делят следующим образом:

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

GATEWAY (ШЛЮЗ, РАЗВИЛКА)

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

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

FLOW (ПОТОК) И MESSAGE FLOWS (ПОТОК СООБЩЕНИЙ)

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

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

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

POOL (ПУЛ)

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

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

DATE OBJECT (ДАННЫЕ, ОБЪЕКТЫ ДАННЫХ)

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

MESSAGE (СООБЩЕНИЕ)

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

ARTEFACT (АРТЕФАКТЫ)

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

Выделяют два вида артефактов:

  • Object Group (Группа объектов)
  • Text Annotation (Текстовая аннотация)
Object Group (Группа объектов) – это еще одна возможность объединить под общим символом несколько элементов, чтобы сэкономить место на диаграмме и повысить простоту ее восприятия. Здесь собираются различные активности под одним общим названием. Группу объектов также всегда можно рассмотреть детально. Группа выглядит как прямоугольник с закругленными углами, выполненный штриховой линией с точками.

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

ИСПОЛНЯЕМЫЕ И НЕИСПОЛНЯЕМЫЕ БИЗНЕС-ПРОЦЕССЫ

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

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

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

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

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

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

ПОДХОДИТ ЛИ BPMN ДЛЯ МАЛОГО И СРЕДНЕГО БИЗНЕСА?

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

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

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

МИНУСЫ И ВАЖНЫЕ ОСОБЕННОСТИ BPMN

О том, насколько удобна BPMN, я сказал уже много. Но для выбора любого инструмента важно также понимать и возможные минусы. О них я сейчас и расскажу:
  • Система имеет значительное количество понятий и терминов, их нужно знать и применять грамотно.
  • Высокий уровень вхождения. Как и любой инструмент с широкими возможностями требует большего времени на изучение, по сравнению с другими нотациями (IDEF0, IDEF3).
  • Необходимо знание бизнес-анализа. В BPMN модели — это не просто картинки или схемы, которые вы можете нарисовать в любом графическом редакторе. Здесь очень важна грамотная структура и четкая последовательность.

ПРИМЕР ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ BPMN

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

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

Данный бизнес-процесс выполняется следующим образом:

  1. Менеджер по продажам получает информацию о потребностях клиента (заказ).
  2. В системе CRM создается документ Заказ покупателя.
  3. Если нужные товары есть в наличие, то менеджер создает расходный документ в программе учета. Если товара нет в наличии, менеджер делает запрос в отдел закупки.
  4. Отдел закупки оформляет запрос поставщикам на получение товара.
На этом мы будем считать бизнес-процесс завершенным, так как покупатель сейчас или после поступлений товаров от поставщиков, сможет купить все необходимое.

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

Точкой входа служит получение заказа от покупателя. Точкой выхода – «резервирование товара».

Обратите внимание, что после получения заказа стрелка ведет к этапу-ромбу, т.е. условию:

  • Если весь товар имеется в наличие, то менеджер выполняет подпроцесс «резервирование товаров». Я специально оформил эти действия именно подпроцессом, чтобы иметь возможность при необходимости детализировать действия менеджера. А потом – к точке выхода «Резервирование товаров проведено».
  • Если товаров в наличие нет, то менеджер выполняет запрос в отдел закупки. Информация о заказе переходит в отдел закупки к другому исполнителю – менеджеру по закупкам, что наглядно видно на схеме, и уже этот исполнитель создает заказ поставщику. На схеме также видно, что заказ поставщику создан на основе запроса на поставку и заказа поставщикам.
Зачем может понадобиться такое описание бизнес-процесса? В наглядной форме вы можете показать своим бизнес-клиентам каким образом функционирует или должна функционировать связь между отделами продаж и закупки с целью максимального удовлетворения потребностей покупателей. Также при помощи этого бизнес-процесса техническим специалистам будет намного проще создавать и настраивать программное обеспечение для автоматизации работы компании, так как на диаграмме наглядно видно, какие процессы в какой последовательности должны происходить, какая информация поступает на каком этапе, а также из каких источников, какие из пользователей должны иметь доступ к тем или иным процессам и документам.

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

КАК РАЗРАБАТЫВАТЬ ДИАГРАММЫ BPMN НА ПРАКТИКЕ?

Здесь я хочу поделиться некоторыми советами о том, с чего начать и как производить разработку моделей бизнес-процессов. Мои советы основаны на знаниях особенностей бизнес-моделирования и личном практическом опыте.
  1. Необходимо запланировать начало и конец процесса. С этого начинается моделирование любого процесса. Так мы обозначаем рамки, в которых будем работать.
  2. Для начала лучше всего описать линейную последовательность действий: шаг за шагом движение от начала к финальному результату. Далее при необходимости добавляются ветвления. В таком порядке работать намного проще, чем ставить две или более ветвей одновременно и путаться в стрелках, что откуда и куда идет.
  3. Пришло время определить ответственных лиц. До этого мы работали с событиями «в чистом виде». Теперь у них появились исполнители и ответственные.
  4. Добавляем данные, сноски, комментарии.
Я лично создаю диаграммы именно в этой последовательности. В принципе, вы можете это делать как-то иначе. Главное, чтобы не возникало путаницы в процессе моделирования.

Что еще хотелось бы посоветовать:

  1. Создавайте диаграммы как можно менее разветвленные. Чем больше элементов окажется на вашей диаграмме, тем сложнее ее будет читать и вам, и вашим заказчикам.
  2. Используйте наиболее простую и понятную терминологию. Очень важно, чтобы ваши заказчики, а также технические специалисты, которые будут работать с диаграммами, без лишних пояснений понимали все (или почти все) термины.
  3. Все названия процессов должны быть максимально информативны и понятны. Иначе читабельность диаграммы также будет крайне низкой. Для названий процессов лучше всего подойдут либо термины, принятые в конкретной организации для описания работы, либо – просто понятные интуитивно фразы.
  4. Зоны ответственности также важно называть понятно для сотрудников компании, бизнес-модель работы которой вы описываете. Самое простое решение – выбирать названия среди существующих подразделений. А если необходимой должности или отдела в компании пока еще не существует, не бойтесь придумывать его сами. Но постарайтесь, чтобы название также было «говорящим», понятным для широкого круга бизнес-аудитории.
  5. Подпроцессов должно быть столько, чтобы избежать ненужной детализации, но не более того. Помните о чувстве меры. Если подпроцессов будет слишком мало, то действия, которые стоило бы спрятать в них, будут находиться в общем процессе, создавая дополнительные объекты, стрелки, ветвления и, как следствие, путаницу. Если вы перестараетесь с желанием убрать все в подпроцессы, то диаграмма потеряет свою информативность, а какие-то изменения в подпроцессе начнут ненаглядно влиять на результаты всего процесса.
  6. Не бойтесь ошибаться! Если вы ошибетесь в исполняемой методологии, это очень быстро выяснится в процессе исполнения (отладки) процесса. Если вы создаете просто наглядную схему, то мелкие ошибки не столь важны, главное, чтобы эта схема помогла вам и людям, для которых вы ее делаете (заказчики, технические специалисты), понять все нюансы вашей идеи. И в любом случае, на ошибках учатся, а исправления внести в бизнес-модель можно быстро и просто.
И, конечно же, независимо от того, какой вариант бизнес-моделирования вам нужен, не стоит бояться BPMN – выучить нотацию очень просто, а для чтения таких диаграмм вашим коллегам и клиентам даже минимальные знания не понадобятся, моделирование очень наглядно и готовые диаграммы понятны интуитивно. Попробуйте, у вас также обязательно все получится.

Еще статьи по данной теме:

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

habr.com

Моделирование бизнес-процессов средствами языка моделирования uml Основные сведения

Лекция

Язык моделирования - это графическая система обозначений для описания программного проекта. Кроме того, языки содержит ряд правил, в соответствии с которыми создаются те или иные диаграммы.

Одним из наиболее распространенных языков моделирования является UML. В нем предусмотрены все аспекты создания программного обеспечения: анализ, проектирование, разработка. UML принят в качестве международного стандарта моделирования программных систем. Стандарт UML поддерживается многими крупнейшими производителями программного обеспечения (Microsoft Visual Modeler for Basic, Rational Rose, Delphi и др.). В настоящее время действует стандарт UML 2.0.

Стандарт моделирования UML предназначен для реализации объектно–ориентированного подхода в проектировании программных средств и моделирования бизнес-процессов предприятий и организаций.

Стандарт моделирования UML включает в себя следующий набор диаграмм:

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

  • Диаграммы классов – для моделирования статической структуры применяемых в системе классов и связей между ними;

  • Диаграммы взаимодействия – для моделирования процессов обмена сообщениями между объектами системы. Существует два вида таких диаграмм: диаграммы последовательности и кооперативные диаграммы;

  • Диаграммы состояний – для моделирования поведения объектов при переходе от одного состояния к другому;

  • Диаграммы деятельностей – для моделирования поведения системы в рамках различных вариантов использования;

  • Диаграммы размещения – для моделирования физической архитектуры системы и другие.

Далее рассмотрим сущность и применение основных диаграмм языка UML при моделировании систем на основе объектно-ориентированного подхода.

Диаграммы вариантов использования

Диаграммы вариантов использования иногда в литературе называют диаграммами прецедентов. Мы будем использовать первый термин.

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

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

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

Действующие лица делятся на три основных типа:

  • пользователи системы,

  • другие системы, взаимодействующие с данной,

  • время.

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

Рис. 1. Пример диаграммы вариантов использования

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

  • перевести деньги,

  • сделать вклад,

  • снять деньги со счета,

  • просмотреть баланс,

  • изменить PIN-код

  • сделать платеж.

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

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

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

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

Конкретная цель диаграмм вариантов использования - это документирование:

  • вариантов использования (все, входящее в сферу применения системы),

  • действующих лиц (все вне этой сферы),

  • связей между ними.

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

  • не моделируйте связи между действующими лицами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции;

  • не соединяйте стрелкой два варианта использования непосредственно. Диаграммы данного типа описывают только, какие варианты использования доступны системе, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяют диаграммы деятельностей;

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

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

Варианты использования обозначают действия системы. Для того чтобы фактически разработать систему, потребуются более конкретные детали. Эти детали описываются в документе, называемом «поток событий» (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы и что - сама система.

Для моделирования бизнес-процессов организаций и предприятий также средствами UML также можно применять диаграммы деятельности. Ранее при проектировании информационных систем эти диаграммы мы использовали для моделирования динамических аспектов создаваемых ИС.

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

studfiles.net

Создание диаграммы бизнес-процесса

 

Окно Выбор типа диаграмм, появляющееся после запуска приложения Visio,состоит из двух частей: панели Раздел, где находится список всех базовых групп шаблонов, и поля Шаблон, где проиллюстрированы шаблоны, доступные в выбранной категории

Шаблоны IDEFO Diagram расположены в разделе Flowchart. Чтобы создать новый документ на основе стандартного шаблона IDEFO Diagram, выполняем следующие действия:

1. В диалоговом окне Выбрать тип чертежа (Choose Drawing Type) нажимаем Flowchart.

2. В поле Шаблон (Drawing Type) выбираем необходимый шаблон. При наведении указателя мыши на рисунок шаблона IDEFO Diagram в левом нижнем углу окна Выбрать тип чертежа появится подсказка, описывающая содержимое выбранного шаблона (на английском языке).

3. Щелкаем по выбранному шаблону IDEFO Diagram левой кнопкой мыши.

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

 

 

Рис. 2. Окно выбор типа диаграммы

 

После создания нового документа на основе шаблона IDEF0 Diagram окно будет выглядеть так, как показано на рисунке 3.

Окно приложения можно условно разделить на четыре части: панели инструментов, окно редактирования рисунка, окно трафаретов Формы и панель состояния.

 

 

Рис. 3. Новый документ на основе шаблона IDEF0 Diagram

Окно редактирования представляет собой лист с наложенной на него сеткой из вертикальных и горизонтальных линий. Сетка является удобным средством для позиционирования готовых фигур или рисования, а при печати она не видна. Окно трафаретов Формы содержит все открытые для данного документа трафареты. Каждый трафарет является специальной панелью, которая содержит различные мастера фигур, графические и вспомогательные элементы, используемые на листе рисунка. Трафарет IDEFO Diagram Shapes содержит все необходимые элементы для создания модели бизнес-процесса.

Начнем описание процесса с того, что поместим на диаграмму три функции, как показано на рисунке 5. Первую функцию назовем «Планировать деятельность», вторую – «Осуществлять деятельность и вести регистрацию фактической информации», третью – «Анализировать, контролировать и управлять деятельностью». Обратите внимание, что по требованиям нотации для наименования функций будем использовать только глаголы или глагольные существительные.

Для того чтобы начертить диаграмму, воспользуемся инструментом Activity Box.

На панели трафаретов IDEFO Diagram Shapes выбираем щелчком мыши инструмент Activity Box и перетаскиваем его на страницу чертежа. На экране появляется диалоговое окно, в котором требуется описать действие (рис. 4).

 

 

Рис. 4. Описание действия

 

Как видно из рисунка 5, объекты расположены в шахматном порядке или в порядке доминирования.

 

Рис. 5. Формирование модели бизнес-процессов на первом шаге

 

Допустим, что на предприятии функцию управления выполняет коммерческий отдел (КО), который использует при этом средство автоматизации MS Excel, для планирования КО использует информацию о рынке (прайс-листы и т.п.) и заявки клиентов. Регламентируется деятельность КО документом «Регламент планирования», «План организации на год». Результатом работы КО является «План отгрузки ГП (готовой продукции)». Вся эта информация отображена на рисунке 6.

Для отображения входов, ресурсов и управления используйте инструмент 1 legged connector

Для отображения выхода используйте инструмент IDEF0 connector.

 

 

Рис. 6. Моделирование бизнес-процесса на втором шаге

 

Рассмотрим функцию «Осуществлять деятельность…». Её выполняет Производственный отдел (ПрО) и Цех. Для выполнения работ требуются сырье и материалы. Работы регламентируются нормативами на расход сырья, государственными и отраслевыми стандартами, техническими условиями и требованиями клиентов. Для работы ПрО требуется АСУ ТП собственной разработки. Для производства готовой продукции Цеху требуются станки и прочее оборудование, т.е. основные средства (ОС). Результат работы ПрО и Цеха – готовая продукция, которая является выходом функции «Осуществлять деятельность и вести регистрацию фактической информации». Кроме того, выходом данной функции является информация о выполнении плана производства и отгрузки готовой продукции (рис. 7).

Нам осталось показать входы и выходы функции «Анализировать, контролировать и управлять деятельностью». На предприятии данную работу контролирует тот, кто ее планировал, то есть коммерческий отдел. В своей работе по анализу и контролю КО руководствуется «Регламентом анализа и контроля», а также Годовой план работы организации в целом. Для работы КО использует MS Excel.

Судя по схеме процесса, представленной на рисунке 7, КО использует вход «Фактическая информация по выполнению плана».

 

 

Рис. 7. Моделирование бизнес-процесса на третьем шаге

 

Для выполнения работы по контролю КО также требуется плановая информация, иначе не с чем будет сравнивать фактические данные и принимать решения. Таким образом, требуется показать на схеме, что «План отгрузки ГП» (являющийся выходом первой функции «Осуществлять деятельность») должен попасть и на вход функции «Анализировать, контролировать и управлять деятельностью». При этом, как видно из рисунка 8, стрелка, изображающая план отгрузки, ветвится. Ветвление стрелок – прекрасный инструмент, позволяющий сделать диаграмму более наглядной.

 

Рис. 8. Четвертый шаг формирования модели бизнес-процесса

 

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

Для отображения обратных связей мы используем инструмент Dynamic connector.

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

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

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

Для отображения меток используйте инструмент Label.

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

Для добавления рамки укажите щелчком мыши инструмент Title block (на панели трафаретов IDEFO Diagram Shapes) и перетащите его на страницу чертежа. На экране появляется диалоговое окно, в котором требуется ввести следующую информацию (рис. 9).

 

 

Рис. 9. Специальные настройки инструмента Title block

 

На поле Node проставляется номер узла, присвоенный данной диаграмме в соответствии с рассмотренной в п. 1.2 нумерацией. В нашем случае это А0.

Затем следует поле Title, где указывают название диаграммы. Название диаграммы совпадает с названием декомпозированной функции верхнего уровня. В нашем примере «Бизнес-процессы производственного предприятия).

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

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

 

Рис. 10. Модель бизнес-процессов в IDEF0

 

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

Декомпозиция в IDEF0

 

Выполним декомпозицию функции «Осуществлять деятельность». На более детальном уровне эта функция включает в себя следующие функции (работы):

1. «Разрабатывать график производства».

2. «Выполнять график производства».

3. «Изготавливать готовую продукцию».

4. «Хранить готовую продукцию на складе».

5. «Отгружать готовую продукцию клиенту».

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

Теперь необходимо подвести каждую стрелку к соответствующему объекту – функции.

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

Входящая стрелка «Сырье и материалы» ветвится на две стрелки: «Вспомогательное сырье» и «Основное сырье и материалы».

Выходом второй функции процесса «Выполнять подготовку производства» являются «Данные по готовности оборудования».

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

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

Для того чтобы сделать стрелку выхода «Брак» туннельной, выберите инструмент IDEF0 connector. Прорисуйте стрелку выхода. Затем щелкните правой кнопкой мыши и выберите в контекстном меню пункт Tunnel Out, как показано на рисунке 11. На конце стрелки добавятся круглые скобки.

 

Рис. 11. Туннелирование стрелок выхода

 

Для того чтобы сделать туннельную стрелку для входа для четвертой функции процесса «Хранить готовую продукцию на складе» формируем выходы: «Данные по запасам ГП» и «ГП на складе». При ее описании необходимо дополнительно ввести в рассмотрение и отобразить в виде стрелок исполнителя «Склад ГП» и управляющий вход «Условия хранения ГП на складе». Ко всем четырем новым входам мы должны применить механизм туннелирования по входу. Для этого выберите в контекстном меню инструмента IDEF0 connector пункт Tunnel In, как показано на рисунке 12. В начале стрелки добавятся круглые скобки.

 

 

Рис. 12. Туннелирование стрелок входа

 

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

 

Рис. 13. Модель бизнес-процесса «Осуществлять деятельность

и вести регистрацию фактической информации»

 

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

 

 

ЗАКЛЮЧЕНИЕ

 

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

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

Помимо метода функционального моделирования IDEF0, в семейство IDEF входят применение и другие методы. Например, IDEF1 – метод моделирования информационных потоков внутри системы; IDEF1Х – метод моделирования данных и проектирования реляционных баз данных; IDEF2 – метод динамического моделирования систем; IDEF3 – метод получения описания функционирования системы; IDEF4 – метод объектно-ориентированного проектирования; IDEF5 – метод получения онтологического описания и исследования сложных систем.

 

 

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

 

1. Макарова, Н.В. Информатика [Текст] : учебник для вузов / Н.В. Макарова, В.Б. Волков. – СПб. : Питер, 2011. – 576 с. : ил.

2. Информатика : учебное пособие для вузов / Е.Б. Ивушкина, Г.Д. Диброва, И.В. Барилов [и др.]. – Шахты : ФГБОУ ВПО «ЮРГУЭС», 2013. – 331 c. – URL: http://www.libdb.sssu.ru

3. Введение в анализ «что если» [Электронный ресурс] / Корпорация Майкрософт (Microsoft Corporation), 2014.– Режим доступа: http://office.microsoft.com/ru-ru/excel-help/HA010342628.aspx

4. Экономическое моделирование в Microsoft Excel. 6-е изд. : Пер с англ. / Мур Джэффри, Уэлерфорд Ларри Р. и др. – М.: Издательский дом «Вильямс», 2004. – 1024 с.

5. Поляк Б. Т. История математического программирования в СССР: анализ феномена. M.: Институт проблем управления.

6. Построение IDEF0 моделей бизнес-процессов управления в VISIO : учебно-методическое пособие / [составители И.Б. Кушнир, А.Н. Самоделов, О.С. Бурякова]. – Шахты : Изд-во ЮРГУЭС, 2008. – 23 с.

7. Шалумов А.С., Никишкин С.И., Носков В.Н. Введение в CALS - технологии: Учебное пособие. Ковров: КГТА, 2002. – 137с.

8. Аппроксимация экспериментальных данных : практикум / составители В.И. Науменко, И.Б. Кушнир. – Шахты : Изд-во ЮРГУЭС, 2007. – 21 с.

9. Колесов Ю.Б., Сениченков Ю.Б. Моделирование систем. Динамические и гибридные системы. Учебное пособие. – СПб. : БХВ-Петербург, 2012. – 224 с. – URL : http://ibooks.ru/reading.php?productid=24856

10. Экономическое моделирование в Microsoft Excel. 6-е изд. : Пер с англ. / Мур Джэффри, Уэлерфорд Ларри Р. и др. – М.: Издательский дом «Вильямс», 2004. – 1024 с.

11. И.Я. Лукасевич ([email protected] или [email protected]). Имитационное моделирование инвестиционных рисков / Анализ финансовых операций. – Режим доступа: http://bre.ru/risk/11788.html

pdnr.ru

BPMN (нотация): описание процесса

Процессным подходом к организации бизнеса мир занимается уже давно и достаточно эффективно, и стандарт Business Process Model and Notation (BPMN, нотация) является процедурой продуманной с правильным описанием бизнес-процессов. Компании постоянно совершенствуют разные специализации данного стандарта и тем самым добиваются весьма существенного повышения всех качественных показателей своей работы. Нотация BPMN понятна не только для экспертов той предметной области, в которой она создавалась, её логическими выкладками может оперировать любой работник.

bpmn нотация

Моделирование и стандартизация

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

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

шлюзы в нотации bpmn

Специалисты

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

Эта методика обеспечила доступной информацией практически всех пользователей - от самых крупных аналитиков, которые создают схемы, и разработчиков, внедряющих технологии выполнения бизнес-процессов по этим схемам, до руководителей компаний, то есть обычных пользователей, которые заняты управлением и отслеживанием выполнения построенной модели. Таким образом, нотации моделирования бизнес-процессов (BPMN) устраняют расхождение между созданием модели и её реализацией. Здесь собраны лучшие идеи, имеющиеся в других методологиях. Например, для лучшей гибкости и читабельности моделирование бизнес-процессов в нотации BPMN 2.0 ведётся в традициях блок-схем.

нотация bpmn в примерах

Символы (элементы) BPMN

Поддерживает и развивает BPMN организация OMG. Это не мем интернетных завсегдатаев, обозначающий "о майн гот", а весьма знаменитая фирма Object Management Group, в которой участвуют более восьмисот компаний, разрабатывающих стандарты, подобные BPMN-нотации. Всеми полезными изменениями в новых версиях мы обязаны разработчикам OMG. Именно эта организация выбрала ключевым направлением продвижение нотации UML BPMN, с помощью которой моделируются объектно-ориентированные системы. А потому при разработке диаграмм помимо концепций и понятий (поток управления, действие, объект данных и тому подобное) в BPMN много понятий, характерных для подхода объектно-ориентированного: сообщение, обмен и поток сообщений.

Символы графической нотации разобраны по назначению и объединяются в категории. Это: Flow Objects - объекты потока, Data - данные, Swimlanes - зоны ответственности, Connecting Objects - соединяющие объекты, Artifacts - артефакты. Поток управления, объект данных и символы объектов потока дополнительно разделяются на подгруппы по семантическому признаку, чтобы отобразить специфику происходящих событий, особенности ветвления потоков, выполнение действий и так далее. Указывают специфику за счёт дополнительных графических изображений - маркеры, иконки, помещённые внутри главного символа. Также символы событий бывают с разным видом контура и фоновым цветом.

нотация bpmn 2 0 pdf

События по времени

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

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

нотации uml bpmn

События: прерывание подпроцесса и тип результата

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

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

Действия

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

Task - задача. Элементарное действие, то есть неделимое. Разновидность или специфика задачи отображается маркером или иконкой в верхнем углу слева на символе действия. Задача может быть Service (сервисная), для оказания услуги, являющейся автоматизированным приложением или веб-сервисом. Send - отправка сообщения. Если хотя бы единожды сообщение отправлено, задача может считаться выполненной. Receive - получение сообщения (тот же принцип: если единожды получено сообщение, задача выполнена). Задача User - пользователя, считается характерной, выполняется исполнителем при помощи программного обеспечения и содействии других сотрудников. Задача, требующая ручного исполнения, - Manual, которая исполняется без помощи автоматизации. Business-Rule - бизнес-правило, по технологии выполнение этой задачи зависит от обстоятельств, выбрать способ помогает заданность бизнес-правила. Script - сценарий, где выполнение операций строго по порядку, описанному на распознаваемом исполнителем языке. Обычно этот вид задач выполняется автоматическими средствами.

Подпроцессы

Sub-Process - подпроцесс. Он включает в себя шлюзы в нотации BPMN, потоки операций, события и много других действий. Таким образом, подпроцесс является составным действием, части которого непосредственно отображаются внутри символа на диаграмме или же выносятся на отдельную декомпозиционную диаграмму. В последнем случае на главной диаграмме в центре подпроцесса (нижний край действия) должен отображаться знак +. Есть стандартные подпроцессы, но их недостаточно, поэтому и появились две его специфические разновидности. Это Event Sub-Process - событийный подпроцесс, который запускается всегда при появлении стартового события. Диаграмма показывает его никак не связанным с остальными действиями и потоками операций. Контур такого подпроцесса изображён точками.

Вторая разновидность - Transaction (транзакция), это состоящее из разных операций действие с удачным завершением, то есть получением положительного результата. Получить конкретный результат можно только при условии удачного завершения абсолютно всех составляющих. Если же возникают проблемы по ходу выполнения подпроцесса, результаты всех предыдущих операций будут отменены (отмена события). Такими помехами могут стать невозможность выполнения той или иной операции или некорректное выполнение её. Чтобы не отменять предыдущие события, можно попробовать неудавшуюся операцию компенсировать (компенсация события). Контур такого подпроцесса отображён двойной сплошной линией. Для включения в диаграмму всех задач или подпроцессов, используемых повторно, существует Call - вызов, который на диаграмме обозначен жирным контуром.

bpmn нотация описание

Шлюзы

Шлюзы в нотации BPMN предназначены для того, чтобы указывать специфику потока операций и их пропуска по параллельным или альтернативным ветвям. Шлюз может обходиться без исходящих или входящих потоков, но всегда имеет как минимум два собственных либо входящих потока, либо исходящих. Маркер внутри его символа задаёт тип шлюза. Это может быть Exclusive, XOR - эксклюзивный с исключающим "или", предназначенный для разделения потока на альтернативные маршруты. По ходу выполнения процесса активирован может быть только один из предлагаемых маршрутов. Условия пропуска содержатся рядом с обозначающей линией. Inclusive, OR - неэксклюзивный с логическим "или" шлюз, предназначенный для разделения потока на маршруты, где активируется каждый, если соблюдено условие истинности логического выражения, связанного с ним. В этом процессе можно выполнять несколько маршрутов, но если хоть в одном отсутствует истинность, то выбор невозможен.

Аналог неэксклюзивного шлюза - Complex (комплексный). Отличие в том, что определяющее активизацию того или иного потока операций выражение только одно. Parallel, AND - параллельный с логическим "и" шлюз нужен для ветвления или слияния параллельно выполняемых операций. Exclusive Event-Based - шлюз эксклюзивный, но основанный на событиях, разделяющих поток операций на альтернативные маршруты. Exclusive Event-Based Gateway to start a Process - тоже эксклюзивный шлюз, события, на которых он основан, запускают весь процесс. Это начальный символ процесса или подпроцесса, входящих потоков не имеет. Таким же образом работает и Parallel Event-Based Gateway to start a Process - шлюз параллельный, также основанный на запускающих процесс событиях. Однако при его помощи можно активировать несколько процессов одновременно, если события, связанные с ними, сработают. Входящих потоков, естественно, не имеет. На картинках ясно видна нотация BPMN в примерах построения диаграмм с двумя видами шлюзов.

моделирование бизнес процессов в нотации bpmn 2 0

Данные и потоки

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

Стандартное изображение потока операций может быть дополнено в диаграмме указанием специфических потоков. Conditional Sequence Flow - обозначение условного потока операций при ветвлении его. Отображён исходящим из действия (если нет желания использовать в диаграмме шлюз). Default Sequence Flow - поток операций, совершающийся по умолчанию, чаще всего исходит из шлюза или действия, с логическими выражениями не связан.

Примеры и выводы

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

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

fb.ru

Графические диаграммы бизнес-процессов (не включая методологию ARIS), входящие в состав типовой конфигурации программных модулей График-студио и График-студио Лайт системы Бизнес-инженер

 

Графические диаграммы стратегии, продуктов и услуг, системы BSC, ключевых показателей - KPI, оргструктуры, ИТ-системы, бизнес-анализа и др., входящие в состав типовой конфигурации программных модулей График-студио и График-студио Лайт системы Бизнес-инженер

 

Графические диаграммы методологии ARIS, входящие в состав типовой конфигурации программных модулей График-студио и График-студио Лайт системы Бизнес-инженер

 

 

Графические диаграммы методологии ARIS, входящие в состав типовой конфигурации программных модулей График-студио и График-студио Лайт системы Бизнес-инженер (продолжение)

 

Диаграммы бизнес-процессов (не включая методологию ARIS)

- График-студио диаграмма «БИТЕК Диаграмма бизнес-процесса»

и производные диаграммы «Swimmer lanes diagram» и «Process variant matrix diagram»

Элементы диаграммы

 

 

Примеры диаграмм

 

 

 

 

- График-студио диаграмма «IDEF0»

Элементы диаграммы

Примеры диаграмм

 

Схема бизнес-процесса "Увольнение сотрудника"

 

 

 

- График-студио диаграмма «Data flow diagram в нотации Гейна-Сарсона»

Элементы диаграммы

Примеры диаграмм

 

Схема бизнес-процесса "Оформление и выдача трудовой книжки сотруднику"

 

- График-студио диаграмма «Data flow diagram в нотации Йордона-Де Марко»

 

Элементы диаграммы

 

 

 

Примеры диаграмм

 

Схема бизнес-процесса "Оформление и выдача трудовой книжки сотруднику"

 

 

 

- График-студио диаграмма «IDEF3»

 

Элементы диаграммы

 

 

 

Примеры диаграмм

 

Схема бизнес-процесса "Заключение договора"

 

- График-студио диаграмма «ORACLE diagram»

 

Элементы диаграммы

 

 

Примеры диаграмм

 

Сеть бизнес-процессов верхнего уровня компании

 

 

Схема бизнес-процесса "Регистрация и обработка документов/при поступлении ТМЦ от поставщика"

 

- График-студио диаграмма «BAAN diagram»

 

Элементы диаграммы

 

 

Примеры диаграмм

 

Сеть бизнес-процессов верхнего уровня компании

 

 

 

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

 

Диаграммы стратегии, оргструктуры и пр.

- График-студио диаграмма «БИТЕК Диаграмма стратегической карты BSC»

 

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «БИТЕК Диаграмма продуктов и услуг»

 

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «БИТЕК Диаграмма организационной структуры»

 

Элементы диаграммы

 

 

Примеры диаграмм

 

 

 

- График-студио диаграмма «БИТЕК Диаграмма информационной системы»

 

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «БИТЕК Диаграмма ключевых показателей – KPI»

 

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «Диаграмма причин и следствий (Исикавы)»

 

Элементы диаграммы

Примеры диаграмм

 

 

 

 

 

 

 

 

- График-студио диаграмма «БИТЕК Сетевая диаграмма проблем и решений»

 

Элементы диаграммы

 

 

Примеры диаграмм

 

 

 

- График-студио диаграмма «БИТЕК Структурная диаграмма»

 

Элементы диаграммы

 

 

 

Примеры диаграмм

 

Диаграммы методологии ARIS

- График-студио диаграмма «ARIS BSC Cause-and-effect diagram (BSC)»

Элементы диаграммы

Примеры диаграмм

- График-студио диаграмма «ARIS Key performance indicator tree (KT)»

Элементы диаграммы

Примеры диаграмм

- График-студио диаграмма «ARIS Product/Service tree (PST)»

Элементы диаграммы

Примеры диаграмм

- График-студио диаграмма «ARIS Function tree (FT)»

Элементы диаграммы

Примеры диаграмм

- График-студио диаграмма «ARIS Value-added chain diagram (VAD)»

Элементы диаграммы

Примеры диаграмм

 

 

Схема бизнес-процесса "Торговля товаром"

 

- График-студио диаграмма «ARIS Process selection diagram (PSD)»

Элементы диаграммы

Примеры диаграмм

- График-студио диаграмма «ARIS Extended event-driven process chain (eEPC)»

Элементы диаграммы

 

Примеры диаграмм

Схема бизнес-процесса "Доставка товара от поставщика"

 

 

 

- График-студио диаграмма «ARIS Information flow diagram (IFD)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Material flow diagram (MFD)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Organizational chart (OC)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Communications diagram (CD)»

Элементы диаграммы

 

 

Примеры диаграмм

 

 

- График-студио диаграмма «ARIS Information carrier diagram (ICD)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Technical terms model (TTM)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Application system type diagram (ASD)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Knowledge structure diagram (KSD)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Knowledge map (KM)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Cost category diagram (CCD)»

Элементы диаграммы

 

 

Примеры диаграмм

 

- График-студио диаграмма «ARIS Cost driver diagram (CDD)»

Элементы диаграммы

 

 

Примеры диаграмм

 

Кокпит-диаграммы

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

Бизнес-процессы

q Диаграмма анализа и ранжирования бизнес-процессов

q Матрица ранжирования бизнес-процессов

q Стоимостная диаграмма бизнес-процесса

q Временная диаграмма бизнес-процесса

Качество

q Диаграмма самооценки уровня зрелости

Ключевые показатели - KPI

q Диаграмма весов ключевых показателей - KPI

q Диаграмма отклонений ключевых показателей - KPI

q Диаграмма выполнения ключевых показателей - KPI

q Диаграмма динамики значений ключевого показателя - KPI

q Диаграмма динамики отклонений ключевого показателя - KPI

q Диаграмма динамики выполнения ключевого показателя – KPI

Проекты

q Диаграмма анализа и ранжирования проектов

q Матрица ранжирования проектов

 

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

Бизнес-процессы

- Кокпит-диаграмма «Диаграмма анализа и ранжирования бизнес-процессов»

 

 

- Кокпит-диаграмма «Матрица ранжирования бизнес-процессов»

 

- Кокпит-диаграмма «Стоимостная диаграмма бизнес-процесса»

 

 

- Кокпит-диаграмма «Временная диаграмма бизнес-процесса»

 

Качество

- Кокпит-диаграмма «Диаграмма самооценки уровня зрелости»

 

 

Ключевые показатели - KPI

- Кокпит-диаграмма «Диаграмма весов ключевых показателей - KPI»

 

- Кокпит-диаграмма «Диаграмма отклонений ключевых показателей - KPI»

 

 

- Кокпит-диаграмма «Диаграмма выполнения ключевых показателей - KPI»

 

- Кокпит-диаграмма «Диаграмма динамики значений ключевого показателя - KPI»

 

 

- Кокпит-диаграмма «Диаграмма динамики отклонений ключевого показателя - KPI»

 

- Кокпит-диаграмма «Диаграмма динамики выполнения ключевого показателя – KPI»

 

 

Проекты

- Кокпит-диаграмма «Диаграмма анализа и ранжирования проектов»

 

- Кокпит-диаграмма «Матрица ранжирования проектов»

 

Иерархические диаграммы

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

Стратегия и BSC

q Иерархическая диаграмма «Дерево факторов внешней среды»

q Иерархическая диаграмма «Дерево факторов внутренней среды»

q Иерархическая диаграмма «Дерево стратегических направлений»

q Иерархическая диаграмма «Дерево стратегических целей»

Продукты и услуги

q Иерархическая диаграмма «Дерево продуктов и услуг»

Бизнес-процессы

q Иерархическая диаграмма «Дерево бизнес-процессов»

Организационная структура

q Иерархическая диаграмма «Дерево должностей»

q Иерархическая диаграмма «Дерево бизнес-ролей»

q Иерархическая диаграмма «Дерево подразделений»

q Иерархическая диаграмма «Дерево групп»

q Иерархическая диаграмма «Дерево контрагентов»

Персонал

q Иерархическая диаграмма «Дерево сотрудников»

q Иерархическая диаграмма «Дерево ответственности»

q Иерархическая диаграмма «Дерево прав и полномочий»

q Иерархическая диаграмма «Дерево требований к персоналу»

q Иерархическая диаграмма «Дерево знаний и компетенций»

q Иерархическая диаграмма «Дерево стимулирований»

Информационная система

q Иерархическая диаграмма «Дерево информационной системы»

Качество

q Иерархическая диаграмма «Дерево причин и следствий»

q Иерархическая диаграмма «Дерево требований к процессу»

Проекты

q Иерархическая диаграмма «Дерево проектов»

Финансы

q Иерархическая диаграмма «Дерево центров финансовой ответственности - ЦФО»

q Иерархическая диаграмма «Дерево бюджетов»

q Иерархическая диаграмма «Дерево категорий затрат»

q Иерархическая диаграмма «Дерево драйверов затрат»

Ключевые показатели - KPI

q Иерархическая диаграмма «Дерево ключевых показателей - KPI»

Регламентирующие документы

q Иерархическая диаграмма «Дерево регламентирующих документов»

Объекты деятельности

q Иерархическая диаграмма «Дерево объектов деятельности»

Оценка деятельности

q Иерархическая диаграмма «Дерево критериев оценки»

q Иерархическая диаграмма «Дерево уровней зрелостей»

 

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

 

Стратегия и BSC

- Иерархическая диаграмма «Дерево факторов внешней среды»

 

- Иерархическая диаграмма «Дерево факторов внутренней среды»

 

- Иерархическая диаграмма «Дерево стратегических направлений»

 

- Иерархическая диаграмма «Дерево стратегических целей»

 

 

Продукты и услуги

- Иерархическая диаграмма «Дерево продуктов и услуг»

 

 

 

Бизнес-процессы

- Иерархическая диаграмма «Дерево бизнес-процессов»

 

 

 

 

 

 

 

Организационная структура

- Иерархическая диаграмма «Дерево должностей»

 

 

 

 

- Иерархическая диаграмма «Дерево бизнес-ролей»

 

 

- Иерархическая диаграмма «Дерево подразделений»

 

 

 

- Иерархическая диаграмма «Дерево групп»

 

- Иерархическая диаграмма «Дерево контрагентов»

 

 

Персонал

- Иерархическая диаграмма «Дерево сотрудников»

 

 

- Иерархическая диаграмма «Дерево ответственности»

 

 

- Иерархическая диаграмма «Дерево прав и полномочий»

 

 

- Иерархическая диаграмма «Дерево требований к персоналу»

 

- Иерархическая диаграмма «Дерево знаний и компетенций»

 

 

- Иерархическая диаграмма «Дерево стимулирований»

 

Информационная система

- Иерархическая диаграмма «Дерево информационной системы»

 

 

 

 

Качество

- Иерархическая диаграмма «Дерево требований к бизнес-процессу»

 

- Иерархическая диаграмма «Дерево причин и следствий»

 

 

 

 

 

 

 

 

 

 

 

Проекты

- Иерархическая диаграмма «Дерево проектов»

 

Финансы

- Иерархическая диаграмма «Дерево центров финансовой ответственности - ЦФО»

 

- Иерархическая диаграмма «Дерево бюджетов»

 

 

 

 

 

- Иерархическая диаграмма «Дерево категорий затрат»

 

- Иерархическая диаграмма «Дерево драйверов затрат»

 

Ключевые показатели - KPI

- Иерархическая диаграмма «Дерево ключевых показателей - KPI»

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Регламентирующие документы

- Иерархическая диаграмма «Дерево регламентирующих документов»

 

Объекты деятельности

- Иерархическая диаграмма «Дерево объектов деятельности»

 

 

 

 

 

 

 

 

 

 

Оценка деятельности

- Иерархическая диаграмма «Дерево критериев оценки»

 

 

 

 

- Иерархическая диаграмма «Дерево уровней зрелостей»

 



infopedia.su

НОУ ИНТУИТ | Лекция | Разработка диаграммы деятельности для моделирования бизнес-процессов

Аннотация: Особенности проектов по моделированию бизнес-процессов в среде IBM Rational Rose 2003. Добавление дорожек на диаграмму деятельности. Построение диаграммы деятельности с дорожками и потоком объектов. Пример построения диаграммы деятельности с дорожками и потоком объектов для модели бизнес-процесса.

Особенности проектов по моделированию бизнес-процессов в среде IBM Rational Rose 2003

Продолжая рассмотрение особенностей разработки диаграмм деятельности, следует отметить, что программа IBM Rational Rose 2003 может быть успешно использована для выполнения проектов по моделированию бизнес-процессов. Наиболее подходящим типом диаграмм для визуального представления схем выполнения бизнес-процессов являются диаграммы деятельности, на которых дополнительно размещаются так называемые дорожки ( Swimlane ). Назначение дорожек состоит в том, чтобы указать зоны ответственности за выполнения отдельных деятельностей в рамках моделируемого бизнес-процесса. В качестве имен дорожек используются либо названия подразделений (департаментов) рассматриваемой компании, либо названия отдельных должностей сотрудников тех или иных подразделений.

Проекты по моделированию бизнес-процессов могут выполняться либо с целью реорганизации или реинжиниринга компании, либо с целью собственно документирования бизнес-процессов. Особенности данных проектов заключаются в том, что в обоих случаях необходимо построить модели бизнес-процессов некоторой существующей компании. Чтобы акцентировать внимание на подобных проектах, их часто называют проектами типа "As is" ("Как есть"). Соответственно проекты по разработке новых продуктов или моделей новых систем называют проектами типа "To be" ("Как должно быть").

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

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

Таким образом, первый этап выполнения проектов типа "Как есть" связан с построением моделей существующих бизнес-процессов компании в форме диаграмм деятельности. В качестве примера проекта этого типа в данной лекции рассматривается модель бизнес-процесса по оптовой продаже товаров со склада торговой компании. Хотя данный пример имеет упрощенный характер, он позволяет наглядно представить основные особенности моделирования бизнес-процессов в нотации языка UML с использованием средства IBM Rational Rose 2003.

Для вновь разрабатываемого проекта по моделированию бизнес-процессов торговой компании в среде IBM Rational Rose 2003 создадим новый проект с именем: МодельБП. В качестве первой диаграммы проекта будет служить диаграмма деятельности, которая описывает отдельный бизнес-процесс в виде последовательности выполнения действий подразделениями компании при оптовой продаже товаров клиентам. Для удобства можно включить эту диаграмму в логическое представление, для чего необходимо в браузере проекта выделить логическое представление ( Logical View ) и выполнить операцию контекстного меню: New \to Activity Diagram (Новая \toДиаграмма деятельности).

www.intuit.ru