Бизнес процесс схема: Как построить схему бизнес-процесса — SNOW DIGITAL AGENCY — агентство полного цикла в сфере интернет-маркетинга

Содержание

Все процессы компании как на ладони — Трибуна на vc.ru

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

Итак, поехали. 😉

Как часто вы сталкивались с попытками регламентировать деятельность в компании? С написанием инструкцией? Насколько быстро они терялись в куче папок на компьютере и превращались в абсолютно бесполезный инструмент? Как быстро Ваши сотрудники открывали и закрывали регламент, состоящий из 20 и более страниц, не дочитав до конца?

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

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

Примеры бизнес-процессов, которые часто требуют регламентации в компаниях:

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

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

С какими проблемами мы столкнулись?

Кстати, напишите в комментариях, если сталкивались с похожими проблемами и как вы их решали. Интересно, одни ли мы такие. =))

Как мы пытались их решать?

Во-первых, мы описали процесс в Visio в виде блок-схем. Постарались визуализировать процесс и уместить на несколько А4.

В качестве примера, прикрепляю описание одного из процессов:
«Обработка заявок/звонков с сайта»:

Описание бизнес-процесса «Обработка заявки/звонка с сайта» Киселев П.Д.

Во-вторых, перенесли блок-схему в дизайнер бизнес-процессов Битрикса. Это наш основной корпоративный портал, поэтому выбор пал на данное ПО.

Дизайнер бизнес-процессов в Битрикс Киселев П.Д.

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

Бизнес-процессы. Извлечение BPMN-модели из документа. Часть 1 / Хабр

Современные проекты по оптимизации и автоматизации бизнес-процессов, как правило, предполагают на начальном этапе анализ больших объемов документов Заказчика с целью моделирования на их основе бизнес-процессов
«as-is» в сжатые сроки. Перечень анализируемых документов может включать нормативно-правовые акты, отраслевые стандарты, протоколы интервью, регламенты, положения, технические задания и другие корпоративные документы.

Перед аналитиком проекта ставится довольно трудоемкая и, в то же время, рутинная задача, которая в настоящий момент не имеет средств автоматизации. Как показывает анализ современных средств моделирования бизнес-процессов, даже такие известные на рынке приложения как Enterprise Architect, Business Studio, Bizagi Modeler – не имеют механизмов поддержки построения моделей бизнес-процессов по их текстовому описанию.

В статье решается задача Извлечения BPMN‑модели из документа.

Надо отметить, что в настоящее время на рынке управления бизнес-процессами (BPM) существует технология интеллектуального анализа процессов (Process Mining). Однако, в отличие от описываемой ниже технологии, на вход Process Mining системы подается база данных с результатами выполнения моделируемого бизнес-процесса, а не набор документов с его текстовым описанием.
Постановку идеальной задачи можно представить как «большую красную кнопку», по нажатию которой весь объем, подлежащих анализу документов, автоматически преобразуется в сеть BPMN-моделей бизнес-процессов Заказчика, доступную для анализа, оптимизации и автоматизации.

Решение задачи в такой постановке – дело будущего. Введем ряд логических и технических ограничений для реальной пилотной задачи.

Цель: минимизировать трудоемкость построения модели бизнес-процессов по текстовому описанию при обеспечении полноты и связанности модели.

На входе имеется документ в формате Microsoft Word, который:

содержит текстовое описание одного внутреннего бизнес-процесса (Private Business Process).
в бизнес-процессе участвует один исполнитель (Participant).
бизнес-процесс описан на одном уровне детализации (Sub-Process отсутствуют).

На выходе получаем xml-файл в формате BPMN2.0, который:

содержит модель бизнес-процесса, соответствующую базовому уровню описания (BPMN Descriptive Conformance Sub-Class).
корректно открывается для редактирования в Bizagi Modeler.

В качестве тестового примера будем использовать текстовое описание, такого широко распространенного процесса, как Управление инцидентами (Incident Management) из стандартной библиотеки ITIL (Information Technology Infrastructure Library). Тестовый пример сознательно взят на английском языке. Английский язык не имеет падежей и выбран для облегчения обработки ссылок (coreferences ) на элементы бизнес-процесса в рамках пилотной задачи (более подробно об этом будет рассказано во 2-й части).

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

Рисунок 1. Блок-схема процесса Управление инцидентами (ITIL v.3 Official Introduction, p.98)

Согласно глоссарию стандарта BPMN (Business Process Model and Notation, version 2.0), бизнес-процесс (

Process) представляется «графом Flow-элементов (набором активностей, событий, шлюзов) и отношений Sequence Flow, связывающих их в исполняемый поток».

Определение. Под BPMN-графом будем понимать конечный, ориентированный граф (Теория графов) со следующими расширениями:

Вершины графа соответствуют BPMN-элементам процесса (Flow, Data, Participant).
Ребра графа соответствуют BPMN-связям процесса (Sequence Flow, Message Flow, Association).
Вершины и ребра имеют обязательные атрибуты: идентификатор (id), наименование ( name), комментарий (documentation).
Обязательные типы вершин – это элементы категории Flow (Activity, Event, Gateway).
Обязательные типы ребер – это связи потока управления (Sequence Flow).

Утверждение 1. Текстовое описание бизнес-процесса в документе (на естественном языке) — содержит BPMN-граф в неявном виде.

Утверждение 2. Задача извлечения BPMN модели из документа относится к классу задач извлечения информации из слабоструктурированных машиночитаемых документов (Information extraction), основными подзадачами которого являются: идентификация сущностей (named entity recognition), идентификация связей (relationship extraction), разрешение ссылок (coreference resolution).

Комбинируя алгоритмы Теории графов и Information extraction, получаем следующие шаги решения.

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

Рисунок 2. Схема процесса Извлечения BPMN-модели из документа (BPMN Text Extraction)

Решение. Шаг 1: Разметка документа BPMN-тегами

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

Определение. BPMN-тег – это цветной текстовый маркер с идентификатором, содержащим тип BPMN-элемента. Наименование и цвет BPMN-тега соответствует определенной категории BPMN-элемента.

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

Таблица 1. Описание BPMN-тегов

Общий принцип выполнения операций с BPMN-тегами: выделить фрагмент текста, содержащий BPMN-элемент, и нажать кнопку соответствующего BPMN-тега.
Например, для выделения бизнес-процесса — выделить «INCIDENT MANAGEMENT«, затем нажать кнопку <Business Process>. Фон выделенного BPMN-элемента окрасится в цвет выбранного BPMN-тега, а в закладки документа будет добавлена закладка с идентификатором BPMN-тега.

Рисунок 3. Лента меню вкладки BPMN (группы BPMN tags, Edit tags)

Ниже перечислены основные операции над BPMN-тегами:

Добавление (BPMN tag) – добавляет новый BPMN-тег в закладки документа (Word Bookmarks) и маркирует соответствующим цветом выделенный фрагмент текста.
Отображение/Скрытие (Show Tags) — включает/отключает маркеры BPMN-тегов в тексте документа.
Изменение размера (Resize) — изменяет область маркированного текста BPMN-тега.
Удаление (Delete) — удаляет BPMN-тег (закладку и маркер) из документа.
Детальная информация (Details) — показывает детальную информацию по BPMN-тегу (идентификатор, категорию, тип и текст BPMN-тега).
Отчет (Report) — показывает статистический отчет о количестве и типах BPMN-тегов в активном документе.

В результате разметки тестового документа получаем следующий результат.

Рисунок 4. BPMN-разметка текстового описания процесса Управление Инцидентами (картинка кликабельна)

Заметим, что в тексте есть «повторяющиеся» BPMN-теги, имеющие одинаковый текст и цвет (например, Service Desk, Problem Management, Incident Record) – это ссылки на один и тот же элемент процесса. Обработка таких ссылок (coreferences) будет рассмотрена на 2-ом шаге решения.

Продолжение следует…

Краткое описание 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Схема описания бизнес процессов. Краткий алгоритм

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

Изучение документации

Начинать описание бизнес процессов можно как с проведения интервью с участниками, так и с изучения документации процесса. Я рекомендую начинать с документации по нескольким причинам:

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

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

Кстати, мне часто доводилось слышать фразу: “Мы хотим, чтобы у нас были процессы”. На мой удивленный вопрос: “А разве у вас их нет?” я получал не менее удивленный ответ “Нет”.
Бизнес процессы есть в любой компании. Даже компания, основанная на проектом управлении, имеет бизнес процессы. Просто они не формализованы, т.е. не зафиксированы в документах.

Проведение интервью

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

Наблюдение

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

Еще лучше – это самому выполнить все операции процесса.

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

Набросок диаграммы процесса

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

Построение диаграммы процесса

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

Согласование диаграммы процесса

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

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

Подготовка регламента

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

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

Лучше всего регламент иметь в электронном виде. Так намного удобнее и проще работать с ним.

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

Согласование регламента

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

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

Как моделировать бизнес-процессы в нотации eEPC? / Хабр

В ходе своей работы и преподавания я сталкиваюсь с описанием бизнес-процессов организации в нотации eEPC (Extended event driven process chain), которая принята стандартом де-факто для описания процедур и регламентов после обследования деятельности организации. К сожалению, используя эту нотацию очень просто допустить ошибки моделирования, не зная правил, по которым она составляется. Эти ошибки приводят в последующем к несоответствию логики процесса, и как следствие – непониманию реальной ситуации в организации. Эта статья является некоторым обобщением моего опыта моделирования бизнес-процессов, и надеюсь, послужит некоторым читателям полезным руководством.

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

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

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

наступление плановой даты, времени, например, «принято решение о начале проекта»
получение или отправка сотрудником заявки, распоряжения, формы, информации, например «поступила заявка от клиента»

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

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

Самыми распространенными ошибками являются использование оператора «ИЛИ» и «исключающего ИЛИ» после события, например:

Обе эти ситуации запрещены, так как событие не может принимать решения. В данном случае единственными вариантом является использование оператора «И»:

либо добавление двух дополнительных состояний:

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

Самой распространенной ошибкой является неправильное использование обратной связи, например, как тут:

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

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

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

Где рисовать процессы? — bpmn2.ru

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

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

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

Количество убивает качество

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

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

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

В каких случаях нужно рисовать схемы?

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

Как пользоваться нотациями

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

Действие. Этот элемент отражает определенную часть работы.
Событие. Показывает, когда что-то «случилось»: например, пришел заказ.
Шлюзы. Они соединяют или разделяют другие элементы схемы.
Артефакты. Задача этого элемента – улучшить читаемость схемы, дать дополнительную информацию.
Потоки. Отображают последовательность работы.
Дорожки и пулы. Разделяют ответственность между задачами.

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

Схема процесса

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

Схема процесса без исполнителей

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

Схема процесса с исполнителями

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

Подпроцессы отображаются в виде свёрнутых элементов

Сравнение разных инструментов для нотации BPMN

Мы описали основные элементы BPMN. Рисовать процессы в этой нотации можно в разных инструментах. Сравнение их возможностей – в таблице ниже.

	bizagi	visio
Стоимость	Бесплатная	Платная
Удобство	Тяжело работать со сложными схемами	Подходит для описания бизнес-процессов, но может понадобиться дополнительная библиотека элементов
Верификация схем	Есть	Нет
Возможность выгрузки	Поддерживает выгрузку в отдельных форматах	Поддерживает выгрузку в картинки

Как пользоваться бесплатной программой

Воспользоваться BPMN вы можете бесплатно, просто перейдите по ссылке http://storm.bpmn2.ru/ – и перед вами откроется рабочая область, процессник. Нотация работает прямо из браузера, ничего скачивать и устанавливать на компьютер не нужно.

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

Так выглядит рабочее окно программы

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

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

определите начало и конец процесса. Процесс не может заканчиваться передачей задачи в другой отдел компании, он всегда должен завершаться передачей товара или услуги клиенту, иначе он не имеет смысла. Вход – это точно определенная потребность клиента. Вход и выход в процесснике маркируются как «событие»;
опишите всё, что нужно сделать, чтобы товар или услуга дошли до клиента. Для начала обозначьте только порядок действий, но не уточняйте, кто этим должен заняться;
укажите последовательность действий, расположив элементы схемы в нужном порядке;
укажите исполнителей, выполняющих действия. Если какие-то действия совершает один и тот же человек, их можно объединить в один пункт для экономии времени;
детализируйте схему, расписав, как нужно совершать каждый отдельный шаг. Это самый трудоемкий из всех этапов;
продумайте контроль за исполнением проработанной схемы. Нельзя ли ее автоматизировать?
предусмотрите исключительные случаи.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Описание бизнес процессов — типы описания

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

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

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

Очень просто сделать – просто садись и пиши.
Не требует специальных навыков – темные времена прошли, теперь писать умеет каждый:)

Минусы

Текст сложно обрабатывать – работа с массивами текста весьма сложна, ведь нам нужно найти суть, скрытую за словами.
Затрудняет целостное восприятие процесса: читая вторую страницу, можно уже забыть, что было на первой. Очень тяжело читать текст, описывающий сложный, разветвленный процесс. Приходится постоянно возвращаться назад, чтобы понять, о чем речь. В итоге восприятие картины целиком нарушается.
Сложно для восприятия – если текст готовит человек без писательских навыков, его прочтение превратится в пытку. У каждого свой язык, и порой он может быть очень сложен. Вы же встречали «плохие» книги? Описание процесса может быть еще хуже:)
Сложно структурировать и анализировать – процесс может иметь множество путей развития. Это значит, что в зависимости от результатов, событий и условий мы выполняем разные действия в процессе. А теперь представьте, каково это – описывать текстом. Очень сложно сохранить простую структуру, когда у вас десяток «если» на одну страницу. В результате этого анализ потребует от вас огромных усилий и титанической предварительной работы.

Подсказка – используйте структурированные списки

Описание бизнес процессов в виде таблиц

Таблица – это здорово! Таблицы я люблю. Их можно рассматривать часами… и не найти ответ на свой вопрос:) Шучу. На самом деле описание бизнес процессов компании в виде связанных таблиц – это не такая уж плохая идея. По крайней мере, намного лучше текстового описания. Самая большая сложность заключается в том, чтобы подготовить хороший шаблон таблицы, в которую, собственно, потом уже внесут данные.

Плюсы описания бизнес процессов текстом в виде таблиц

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

Минусы

Некомпактно – описание больших процессов со всем множеством подпроцессов и элементов будет выглядеть как «простыня». Компактным такой вид назвать сложно.
Отсутствует необходимая детализация – для того чтобы таблица имела более компактный вид, количество данных должно быть ограничено. Это значит, что даже если вы вносите текст в таблицу, он должен быть ограничен. А значит, добиться необходимой детализации может стать непросто.
Нет целостности восприятия – большое количество данных не способствует этому. Хотя если необходимо просмотреть данные одной операции (подпроцесса) в строке или данные одного типа в столбце, то лучше таблицы не придумать.
Сложно отобразить ветвления – та же проблема, что и с текстом. Большое количество ветвлений и, что важно, развитие процесса исходя из условий ветвления довольно сложно отобразить наглядно.
Требует подготовки – нужно потратить время на подготовку хорошего шаблона.

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

Описание в виде схемы, модели бизнес процесса

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

Плюсы описания бизнес процессов в виде модели

Простота восприятия – наш мозг устроен таким образом, что картинку мы воспринимаем быстрее, чем что-либо. Поэтому схему воспринимать очень просто. Мозг «фотографирует» схему и обрабатывает ее на бессознательном уровне в разы быстрее, чем наше сознание. Схему воспринимать просто еще потому, что мы сразу видим взаимосвязи элементов.
Целостность восприятия – 1 схема представляет из себя модель процесса на определенном уровне. Это значит, что схема сразу дает нам представление о процессе в целом. В частности, о его границах, основных элементах и т.д. Если процесс детализируется на нескольких уровнях, то схемы все равно остаются связанными.
Необходимая и достаточная детализация – в то же время на схеме можно отобразить относительно большое количество деталей без потери качества восприятия.
Наглядное отображение ветвлений и путей развития процесса – правильно построенная схема сразу дает представление о том, каким путем должен развиваться процесс в правильном варианте. А также другие варианты развития событий.
Удобство автоматизации – многие программные инструменты позволят переводить диаграммы в языки программирования, что очень сильно упрощает жизнь разработчикам и внедренцам ПО.

Минусы

Требует специальных навыков – нужно знать, как правильно строить диаграммы. Знать разные нотации. А иногда даже самостоятельно сделать набор элементов и правил, которыми вы будете пользоваться для описания.
Относительно большое время на подготовку описания – хорошо построенная модель процесса должна быть проста и понятна. Для того, чтобы сделать схему таковой, необходимо потратить кучу времени. Сложно может сделать каждый дурак, а вот простота требует мастерства;)

Инвестиции в графический тип описания окупаются весьма неплохо.

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

В итоге

В итоге вы будете задействовать все типы описания. Документ под названием «Описание бизнес процесса…» будет содержать и графическую схему, и таблицы, и текст. Это нормально. Но мой вам совет – ориентируйтесь на графические модели и избегайте текста. Хорошая модель не нуждается в сопровождении текстом. В большинстве случаев.
Создание бизнес процессов начинается с их описания.

образцов ConceptDraw | Бизнес-процессы — диаграммы BPMN

Образцы диаграмм бизнес-процессов (BPMN 2.0) создаются с помощью программного обеспечения ConceptDraw DIAGRAM для построения диаграмм и векторной графики, дополненного решением Business Process Diagram от ConceptDraw Solution Park. ConceptDraw DIAGRAM предлагает вам множество инструментов для построения диаграмм, а решения из Solution Park предоставляют шаблоны диаграмм и библиотеки готовых диаграмм и форм для быстрого и простого рисования бизнес-диаграмм профессионального качества.ConceptDraw DIAGRAM обеспечивает экспорт векторных графических многостраничных документов в несколько форматов файлов: векторная графика (SVG, EMF, EPS), растровая графика (PNG, JPEG, GIF, BMP, TIFF), веб-документы (HTML, PDF), презентации PowerPoint (PPT). ), Adobe Flash (SWF).

Пример 1: Схема бизнес-процессов (BPMN 2.0) — Обработка приложений и процесс выставления счетов

Модель и обозначение бизнес-процессов 2.0 (BPMN 2.0) Пример схемы: процесс обработки приложений и выставления счетов.

Этот пример создан с использованием программного обеспечения для построения диаграмм ConceptDraw DIAGRAM, дополненного решением Business Process Diagram от ConceptDraw Solution Park.

Пример 2: Диаграмма бизнес-процессов (BPMN 2.0) — Система сообщений о неисправностях

Модель и обозначение бизнес-процессов 2.0 (BPMN 2.0) Пример схемы: Система заявок на устранение неисправностей.

Пример 3: Схема бизнес-процессов (BPMN 2.0) — Хореография бронирования такси

Модель и нотация бизнес-процессов 2.0 (BPMN 2.0) Пример схемы: Хореография заказа такси.

Пример 4: Схема разговорной BPMN 2.0 — процесс создания рекламы

Модель бизнес-процесса и нотация 2.0 (BPMN 2.0) Пример диаграммы: Процесс создания рекламы.

Пример 5: Диаграмма бизнес-процессов (BPMN 2.0) — процесс бронирования такси

Модель бизнес-процесса и нотация 2.0 (BPMN 2.0) Пример схемы: процесс бронирования такси.

Пример 6: Диаграмма бизнес-процессов (BPMN 1.2) — Создание мобильного контента

Модель бизнес-процесса и нотация 1.2 (BPMN 1.2) Пример схемы: создание мобильного контента.

Пример 7: Диаграмма бизнес-процессов (BPMN 1.2) — Порядок заказа такси

Модель бизнес-процесса и нотация 1.2 (BPMN 1.2) Пример схемы: Порядок заказа такси.

Пример 8: Диаграмма моделирования бизнес-процессов (BPMN 1.2)

Модель бизнес-процесса и нотация 1.2 (BPMN 1.2) Пример диаграммы.

Пример 9: Схема бизнес-процессов (BPMN 2.0) — процесс бронирования

Модель и обозначение бизнес-процессов 2.0 (BPMN 2.0) Пример схемы: процесс бронирования.

Пример 10: Диаграмма бизнес-процессов (BPMN 2.0) — Хореография логистики

Модель бизнес-процесса и нотация 2.0 (BPMN 2.0) Пример диаграммы: Логистика Хореография.

Пример 11: Диаграмма бизнес-процессов (BPMN 2.0) — процесс заказа

Модель бизнес-процесса и нотация 2.0 (BPMN 2.0) Пример диаграммы: Процесс заказа.

Пример 12: Диаграмма бизнес-процесса — процесс с нормальным потоком

Пример диаграммы бизнес-процесса: процесс с нормальным потоком.

Пример 13: Диаграмма бизнес-процесса — процесс цикла обсуждения

Пример диаграммы бизнес-процесса: процесс цикла обсуждения.

Пример 14: Схема разговорной BPMN 2.0 — набор и обучение

Модель бизнес-процесса и нотация 2.0 (BPMN 2.0) Пример диаграммы: Набор и обучение.

Пример 15: Диаграмма бизнес-процессов — группа на активном пленарном заседании

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

Пример 16: Диаграмма бизнес-процессов (BPMN 1.2) — Процесс приема на работу

Модель бизнес-процесса и нотация 1.2 (BPMN 1.2) Пример схемы: процесс найма.

Пример 17: Диаграмма бизнес-процессов — Пример BPMN предложения

Пример диаграммы бизнес-процесса: Пример BPMN цитаты.

Пример 18: Схема бизнес-процессов (BPMN 1.2) — процесс заказа такси

Модель бизнес-процесса и нотация 1.2 (BPMN 1.2) Пример схемы: процесс заказа такси.

Пример 19: Диаграмма бизнес-процесса — процесс сбора голосов

Пример диаграммы бизнес-процесса: процесс сбора голосов.

Диаграмма бизнес-процесса | Руководство пользователя Enterprise Architect

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

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

Лента: Дизайн> Диаграмма> Вставить> BPMN x.y> Бизнес-процесс

Панель инструментов обозревателя проектов: значок новой диаграммы> BPMN x.y> Бизнес-процесс

Контекстное меню обозревателя проектов | Добавить диаграмму …> BPMN x.y> Бизнес-процесс

Диаграммы бизнес-процессов

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

Диаграммы бизнес-процессов

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

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

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

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

Как сделать один за 6 простых шагов

Блок-схема бизнес-процесса — один из традиционных графических инструментов, используемых профессионалами BPM.

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

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

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

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

Определение блок-схемы бизнес-процесса

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

Определение модели процесса

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

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

Подробнее: CASE: пример отображения процесса компании

6 шагов к созданию блок-схемы бизнес-процесса

1. Определите основные компоненты процесса.

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

Выписка: Картирование и методы оптимизации процессов

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

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

2. Заказать мероприятия

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

3. Выберите правильные символы для каждого действия

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

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

Выписка: 23 значения символов блок-схемы процесса

4. Установите связь между действиями

Для этого используются разъемы. Обычно стрелки и линии, пунктирные или нет. Их значение описано в посте выше. Проверьте это!

Хотите узнать больше о нотации BPMN 2.0? Отъезд: http://www.omg.org/spec/BPMN/2.0/

5. Укажите начало и конец процесса

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

6. Изучите схему бизнес-процесса

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

Не все ли шаг за шагом просто?

Итак, смотрите видео ниже. Это один из уроков тренинга HEFLO BPMN, и в нем объясняется, как шаг за шагом создать вашу первую диаграмму BPMN.

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

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

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

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

Нотация моделирования бизнес-процессов (BPMN)
Диаграммы UML
Блок-схема
Диаграммы передачи данных
Диаграммы ролевой деятельности
Диаграммы взаимодействия ролей
Диаграммы Ганта
Интегрированное определение для моделирования функций
Цветные сети Петри
Объектно-ориентированные методы
Техника рабочего процесса
Имитационная модель

Чтобы не начинать с новейших технологий.

1. Нотация моделирования бизнес-процессов (BPMN)

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

BPMN состоит из следующих основных строительных блоков;

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

BPMN is one of the latest business process modeling techniques used by many professionals

Бизнес-процесс, смоделированный с использованием BPMN

Creately имеет отдельную библиотеку с последней версией BPMN 2.0 объект включен в библиотеку. Кроме того, вы получаете интеллектуальные элементы группировки, профессионально разработанные шаблоны BPMN и многое другое. Узнайте, как Creately упрощает моделирование с помощью BPMN.

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

Процесс, смоделированный с использованием BPMN, который имеет дорожки

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

2. Диаграммы UML

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

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

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

Гибкость делает UML популярным методом моделирования бизнес-процессов.

Наше программное обеспечение UML поддерживает рисование всех типов диаграмм UML.У нас есть шаблоны, отдельные библиотеки для различных диаграмм UML и статьи, которые помогут вам в этом процессе. Нажмите здесь, чтобы начать рисовать UML с Creately >>

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

3. Методика блок-схемы

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

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

Простая блок-схема с процессами, блоками решений и т. Д.

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

4. Диаграммы потоков данных — метод Йордона

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

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

Диаграмма DFD, используемая при моделировании

5. Диаграммы ролевой деятельности — RAD

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

Схема ролевой деятельности, используемая при моделировании бизнес-процессов

6. Диаграммы взаимодействия ролей — RID

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

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

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

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

7. Диаграммы Ганта

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

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

An example of a Gantt chart with timelines

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

8. Интегрированное определение для моделирования функций (IDEF)

IDEF — это семейство методов, поддерживающих парадигму, способную удовлетворить потребности в моделировании предприятия и его сфер деятельности (IDEF, 2003). Семейство IDEF используется в разных приложениях.Наиболее важные части: IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3, IDEF4 и IDEF5. Однако для моделирования бизнес-процессов наиболее полезными версиями являются IDEF0 и IDEF3.

Модель IDEF

9. Цветные сети Петри (ЦПН)

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

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

Диаграмма, смоделированная с помощью цветной сети Петри

10. Объектно-ориентированные методы

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

Наконец, сообщения — это запросы объектов-получателей на выполнение указанного метода или поведения и возвращение результата этого действия объектам-отправителям. Состояния изменяются в зависимости от поведения, когда объект получает сообщение. Есть много разных техник, основанных на ОО.Унифицированный язык моделирования (UML) считается стандартным языком объектно-ориентированного моделирования. Метод Коада и Юрдона предшествует UML.

11. Техника рабочего процесса

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

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

A diagram showing the workflow technique

Концепция рабочего процесса

12. Моделирование

Имитационная модель

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

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

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

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

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

Надеюсь, теперь вы хорошо разбираетесь в методах BPM.В следующей статье мы обсудим важность методологии BPM.