Нотации описания бизнес процессов виды: Нотации бизнес-процессов. — Trinion. Системный интегратор.

Содержание

Нотации бизнес-процессов. — Trinion. Системный интегратор.

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

    при изучении организации работы компании;

    при выборе и внедрении программных систем, в начале работы над новым проектом;

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

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

Цели моделирования

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

Первая цель моделирования – наглядно и однозначно поставить задачу или пояснить решение. Графика – всегда нагляднее слов. В случае использования нотаций разночтений практически не возникает.

Графика против текста

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

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

Преимущества такого подхода:

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

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

В своей практике я видел технические задания, состоящие из 200 или 300 страниц. Честно говоря, я с трудом представляю, как можно в голове «связать» такой объем информации. А ведь это не художественная литература, здесь каждая страница содержит огромное количество технической информации. А ведь ее нужно не просто изучить и понять, но еще и обсудить, а иногда и «защитить» идею. Графическая нотация в этом случае явно выигрывает.

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

Какие бывают нотации

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

     функциональным;

     процессным;

     ментальным.

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

В зависимости от поставленной задачи выбирают и языки моделирования – IDEF0, IDEF3, BPMN, UML, ARIS и многие другие.

Нередко мне задают вопрос, почему я не использую отечественные разработки. Дело в том, что в России графическое моделирование практически не развивалось. Существует две системы – сетевой графики «дракон». Но, к сожалению, они не столь популярны и не так хорошо документированы, как IDEF0 или BPM.

Выбор языка моделирования.

Язык графических нотаций выбирают с точки зрения выбранного подхода и особенностей применения.

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

Для описания последовательности действий при выполнении каких-то работ оптимально подойдет IDEF3 или BPMN.

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

Что касается вопроса: «А какой из языков, созданных для одинаковых целей лучше?» — я считаю, это зависит от личных предпочтений. Я не использую ARIS или Дракон, предпочитаю языки семейства IDEF0 и BPM. С моей точки зрения они удобны, и другие просто ни к чему. Другие люди работают в том же Драконе, и, думаю, смогут привести массу доводов, почему он для них оказался самым лучшим.

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

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

В каком порядке моделировать?

Для начала вспомним бессмертную истину – «нельзя объять необъятное». Следовательно, необходимо:

     очертить границы модели.

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

Следующий этап:

      изучаем поставленную задачу.

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

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

Далее,

     создается первый вариант графической нотации и вносятся уточнения

.

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

И последний этап –

     текстовые пояснения.

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

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

Насколько важно знать сферу деятельности при моделировании?

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

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

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

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

Подведем итоги.

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

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

Нотации для описания бизнес-процессов: виды, преимущества и недостатки

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

Заказчик формулирует свои запросы и потребности, исполнитель предлагает способ, которым это будет реализовано. 

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

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

1. Текстовое описание

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

2. Произвольная схема

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

3. Блок-схема

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

4. Функциональная блок-схема

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

5. ВPMN

Нотация BPMN похожа на функциональную блок-схему, но ее отличие в том, что начало процесса проходит параллельно: он может быть запущен и у заказчика, и у других участников. Движение потока действий и сообщений разделено. Каждая задача имеет иконку, которая объясняет ее суть. Также, здесь появляется «событие» — событие начала и событие окончания. Есть также много условных разделений. Это одна из самых мощных нотаций, используемых в IТ компаниях.

6. IDЕF0

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

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

Еще больше узнать об автоматизации бизнес-процессов вы можете из наших материалов:

  1. Что такое бизнес-процесы и какие их основные элементы?
  2. Строй — автоматизуй! Почему построение и автоматизация бизнес-процессов не одно и то же
  3. Автоматизация бизнес-процессов — с чего начать?
  4. Как автоматизация бизнес-процессов влияет на бизнес

Способы описания бизнес-процессов — обзор популярных вариантов

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

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

Предпосылки к описанию Б-П

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

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

Графический способ

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

Графический способ (блок-схема) описания Б-П

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

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

Текстовый

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

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

Табличный

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

  • таблицы выглядят некомпактно. Если в бизнес-процесс задействовано много исполнителей и структурных подразделений, таблица может иметь вид «простыни», в которой достаточно сложно разобраться;
  • нет детализации. Чтобы создать подобие компактности, в таблицах нет возможности вносить большие массивы информации и детализировать процесс;
  • могут возникнуть сложности с изображением ветвления;
  • требуется много времени для подготовки правильного и удобного шаблона.
Табличный способ описания Б-П

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

Современные BPM-системы работают с графическим способом построения Б-П используя нотацию BPMN версии 2.0. Встроенный графический дизайнер и отладчик помогает в построении и запуске процесса. Дальнейшая аналитика и мониторинг способствует постоянному улучшению и оптимизации процессов.

Похожие статьи

Моделирование бизнес-процессов | Forward Telecom

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

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

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

ВИДЫ МОДЕЛИРОВАНИЯ

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

  • Функциональное. Модель бизнес-процесса состоит из диаграмм, текста и глоссария. Каждый элемент может ссылаться на другой. Основа модели – диаграммы, которые отображают последовательность функций, связанных общими объектами. Плюсы функционального моделирования в графической простоте, потому что оно базируется на двух элементах – функциональном блоке и интерфейсной дуге, которая связывает блоки между собой.
  • Процессное. Ключевой принцип – отображение последовательности. Определяется цепочка совокупности бизнес-процессов, которые увеличивают конечную стоимость услуг или товаров. Процессное моделирование лежит в основе популярных нотаций IDEF3, DFD и ARIS, о которых мы поговорим позже.
  • Ментальное. . Этим типом моделирования владеет каждый из нас. Под ним подразумеваются графические наброски схем в свободной форме, которые помогают структурировать и упорядочить спутанные представления о бизнес-процессах и делаются в основном «для себя».

ЭТАПЫ МОДЕЛИРОВАНИЯ

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

  1. Определите роли сотрудников и зоны ответственности.
  2. Определите бизнес-функции, которые выполняют сотрудники в рамках своей деятельности.
  3. Соотнесите роли и бизнес-функции работников.
  4. Определите порядок исполнения бизнес-функций.
  5. Добавьте действия, которые проводят сотрудники в рамках бизнес-функций.
  6. Добавление документы и ресурсы, используемые в процессе выполнения бизнес-функций.

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

  1. Финансовый директор принимает окончательное решение об оплате счета и несет за это решение ответственность.
  2. Финансовый директор должен проверить счет на наличие ошибок, определить назначение платежа и инициатора.
  3. Действия, производимые финансовым директором, являются последними в цепочке перед оплатой счета.
  4. Сотрудник должен получить счет, проверить его, проинформировать инициатора о принятом решении, передать счет на оплату или вернуть его для корректировки.
  5. Проверка счета, взаимодействие с инициатором, взаимодействие с другими сотрудниками финансовой службы.
  6. Счет на оплату в электронном или бумажном виде, электронная почта и/или информационная база для информирования инициатора и сотрудников, ответственных за оплату.
  7. В результате моделирование бизнес-процессов должно наполнить полученные модели следующей информацией:

  • Набор бизнес-функций;
  • Порядок выполнения;
  • Принципы контроля и управления в рамках бизнес-процесса;
  • Исполнители
  • Входящие и исходящие документы;
  • Ресурсы;
  • Документация или условия, регламентирующие выполнение бизнес-функции;
  • Общая характеристика процесса.

Информация в модели может варьироваться в зависимости от используемой нотации.

НОТАЦИИ

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

  1. IDEF00Акцент в нотации смещен на логические отношения между объектами и соподчиненность. На схеме управляющая информация входит в функциональный блок сверху, а механизм или человек, ответственный за выполнение действия, «входит» снизу. Левой стрелкой обозначена входная информация, а результаты на выходе показаны правой стрелкой. Каждый компонент модели может быть расшифрован более подробно на другой диаграмме. Нотация IDEF00 обычно используется для бизнес-процессов верхнего уровня.
  2. Выделяют два уровня моделирования бизнес-процессов: верхний и нижний. «Сверху» находится обобщенный комплекс взаимосвязанных функций, который в дальнейшем можно детализировать. Нижние уровни – это выборка далее неделимых процессов (например, обработка заказа), для которых создается описание и проводится дальнейшая оптимизация.
  3. IDEF3. Нотация из одного «семейства» с предыдущей, но с акцентом на очередность выполнения бизнес-процессов и ориентацией на нижние уровни моделирования. То самое процессное моделирование бизнес-процессов, которое легло в основу многих популярных нотаций.
  4. BPMN. Отличительный признак нотации – наличие «дорожки», которая обозначает совокупность действий ответственного в рамках бизнес-процесса. Если в нем участвует несколько человек, на графике отражается взаимодействие «дорожек». С помощью нотации BPMN удобно искать «слабые места» бизнес-процессов, которые в большинстве случаев находятся на стыке работ разных исполнителей.
  5. Basic Flowchart. Нотация класса workflow используется для составления алгоритма выполнения процесса. Составляющие элементы графика: событие, процесс, решение, стрелки входящей информации и стрелки «Поток объектов». Basic Flowchart больше всех похожа на блок-схему.
  6. ARIS EPC. Нотация по принципу схожая с предыдущей и тоже относящаяся к классу workflow. Схема представляет собой комбинацию событий и функций, для каждой из которых определены начальные и конечные события, участники, исполнители, материалы и документы.

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

РЕЗУЛЬТАТЫ

На выходе вы должны получить:

  1. Процессную карту бизнес-процессов компании с их взаимосвязью;
  2. Диаграмму ролей сотрудников;
  3. Модель «как есть» каждого бизнес-процесса.

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

Моделирования в среде ARIS Express

К списку публикаций

15.02.2018г.

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

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

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

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

Введение

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

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

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

Правила моделирования (далее Правила) базируются на методологии ARIS и ориентированы на использовании принципов процессного подхода и процессного описания деятельности организации.

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

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

Таблица 1 Перечень областей

 

ОБЛАСТЬ

ОПИСАНИЕ

 
 

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


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

 
 

Структура
процессов
предприятия


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

 
 

Структура
целей бизнес-процессов


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

 
 

ИТ-инфраструктура


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

 

 

Наименование объектов организовано по следующим правилам:

  • Конкретность: выбранное наименование должно однозначно и кратко определять описываемый объект и однозначно трактоваться пользователями репозитория бизнес-процессов
  • Однозначность: разные по смыслу объекты должны иметь разные наименования. Необходимость создания нового объекта определяется на основе анализа уже существующих объектов

Модель должна содержать такое число объектов, которое обеспечит читаемость модели на формате листа – А4.

Термины/Определения

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

Таблица 2 Основные термины

 


ТЕРМИН

ОПРЕДЕЛЕНИЕ

 
 


1

Процессная система
управления предприятием


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

 
 


2

Цель


Конечный результат, на который направлен бизнес-процесс

 
 


3

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


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

 
 


4

Основной бизнес-процесс


Бизнес-процесс, который добавляет стоимость. Например, «Производство», «Проектирование продукта», «Логистика производства»

 
 


5

Обеспечивающий
бизнес-процесс


Бизнес-процесс, поддерживающий инфраструктуру предприятия. Например, «Управление кадрами», «Бухгалтерский учет»

 
 


6

Продукт


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

 
 


7

Функция


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

 
 


8

Нотация


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

 

 

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

Концепция подхода к моделированию

Общие положения

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

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

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

  • Цепочки добавленного стоимости (value added chain diagram, VAD) в нашем случае при использовании ARIS Express это модель «Process landscape»
  • Последующая детализация полученных моделей осуществляется с использованием событийных цепочек процессов (event-driven process chain, EPC with material flow) в нашем случае при использовании ARIS Express это модель «Business process»
  • Для изображения на одной диаграмме событий, исполнителей, материальных и документальных потоков, сопровождающих выполнение процесса, используется модель «BPMN diagram»

Для моделирования процессной структуры ИТ организации/предприятия используются модели:

  • «IT infrastructure» — возможно представить модель сетевых взаимосвязей инженерно- технического оборудования и ИТ-систем
  • «System landscape» — схематическое представление взаимосвязей ИТ-систем

Детальное описание правил моделирования

Organization chart. Описание организационной структуры

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

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

Уровень подразделений предприятия детализируется на модели организационной структуры второго уровня штатного расписания. Эта детализация отражается на модели (уровня подразделений) с использованием связи типа `is composed of`. Модель уровня штатного расписания представляет детальный уровень иерархии организационной структуры предприятия.

Для описания отдельных должностей используется тип `position`. Одна организационная единица может быть связана с несколькими должностями. Смысл соединений соответствует связям между организационными единицами.

Правила выделения объектов для описания организационной структуры приведены в таблице 3.

Таблица 3 Правила выделения объектов для описания организационной структуры

 

ТИП И СИМВОЛ ОБЪЕКТА

ОПИСАНИЕ

ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ

 
 


Organizational
unit

 


Подразделение Служба, Отдел, Бюро организации/предприятия, Должность в составе
подразделения


Правила задания имени

Имя задается в соответствии с принятым в организации наименованием подразделения, в соответствии с названием штатной единицы (для должности)
Пример:
Центр развития
Отдел маркетинга и сбыта
Генеральный директор
Детализация
Каждый объект, отражающий подразделение предприятия, отображается на модели организационной структуры.

 
 


Person


Сотрудник предприятия


Правила задания имени

Имя задается в соответствии с ФИО конкретного сотрудника. Фамилия задается полностью, далее указываются инициалы.
Пример:
Иванов И.В.
Заполняемые атрибуты
‘Full name’ – указывается фамилия, имя и отчество полностью.

 
 


Role


Бизнес-роль


Правила задания имени

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

 
 


Location


Локация (месторасположение)


Правила задания имени

Имя должно давать представление о месторасположении подразделения, должности.
Пример:
г. Москва

 

 

В ARIS Express типы связей между объектами устанавливаются автоматически.

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

 

Рисунок 1 Пример модели организационной структуры

Process landscape Описание структуры процессов предприятия (цепочки добавленной стоимости — VAD)

Диаграммы цепочки добавленной стоимости (Value-Added Chain Diagram, VAD-диаграмма) используются для верхнеуровневого описания групп бизнес-процессов компании, непосредственно влияющих на выход готовой продукции.

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

Правила выделения объектов для описания структуры процессов организации/предприятия приведены в таблице 4.

Таблица 4 Правила выделения объектов для описания структуры процессов

ТИП И СИМВОЛ ОБЪЕКТА

ОПИСАНИЕ

ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ

Process

Процесс/подпроцесс

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

 

Пример модели VAD на рисунке 2 

 

 Рисунок 2 Пример модели VAD

Business process Описание событийной цепочки бизнес-процесса

Общие правила описания событийной цепочки бизнес-процесса

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

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

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

Правила наименования операций, шагов и событий:

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

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

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

Нотация eEPC

Модель бизнес-процесса в нотации eEPC (with material flow) представляет собой направленный граф, формируемый из событий, бизнес-функций и операторов ветвления. Исполнители, документы и элементы прикладных комплексов являются окружением бизнес-функций.

Объекты графа представлены в таблице 5

Таблица 5 Объекты модели eEPC

ТИП И СИМВОЛ ОБЪЕКТА

ОПИСАНИЕ

ПРАВИЛА ВЫДЕЛЕНИЯ,ИМЕНОВАНИЯ И ИСПОЛЬЗОВАНИЯ

Event

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

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

Function

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

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

Entity

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

Правила задания имен
Название сущности формируется исходя из наименования используемого ресурса

Database

Хранилище данных, база данных

Правила задания имен
Название соответствует предназначению хранилища данных

Document

Документ

Правила задания имен
Объект соответствует любому носителю информации – документ, файл

IT system

ИТ-система

Правила задания имен
Название соответствует наименованию используемой ИТ-системы

Product

Продукт

Правила задания имен
Название соответствует наименованию целевого продукта процесса

Risk

Риск

Правила задания имен
Название отражает суть имеющегося риска

Process interface

Процессный интерфейс

Правила задания имен
Название полностью совпадает с наименованием декомопзируемого процесса

 

Оператор И

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

 

Оператор Искл. ИЛИ

 

Оператор ИЛИ

 

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

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

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

Обязательные элементы окружения функции(процесса):

  • Сам объект функция/бизнес-процесс/операция/шаг – в центре
  • Входящие документы – слева сверху друг под другом
  • Объекты организационная единица и роль – справа
  • Исходящие документы – справа снизу друг под другом

Необязательные элементы окружения функции(процесса) (добавляются в случае необходимости конкретизации либо пояснения по смыслу):

  • Место исполнения функции – справа сверху
  • Сущность, ресурс – слева
  • База данных, хранилище информации, источник информации – слева внизу

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

Пример правильного расположения представлен на рисунке 3.

 

Рисунок 3 Пример правильного расположения объектов окружения функции

Важным также является правильное отражение ветвлений процесса. Для ветвления используются соответствующие операторы ‘AND’ (И), ‘OR’ (ИЛИ), ‘XOR’ (Исключающее ИЛИ). Одним из основных правил является ограничение на количество входящих и исходящих соединений для событий и функций – их не должно быть больше одного.

В соответствии с этим правилом ошибочными являются представленные на рисунке 4 примеры.

 

Рисунок 4 Примеры ошибочного отображения ветвления

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

 

 Рисунок 5 Пример исправленных ошибок

При отражении ветвлений важным также является правильность выбора оператора (подробности см. в разделе «Правила выделения объектов») и его корректное использование. Корректное использование подразумевает необходимость отражения ветвлений таким образом, чтобы из представленной структуры модели были ясны условия, при которых процесс продолжается по каждой из веток ветвления. Для выполнения указанных правил необходимо использовать следующее ограничение – оператор ‘OR’ (ИЛИ) или ‘XOR’ (Исключающее ИЛИ) не может следовать за событием. Пример правильного и некорректного отражения подобных ветвлений представлен на рисунке 6.

  Рисунок 6 Пример некорректного и правильного отражения ветвления процесса на альтернативные направления

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

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

 

 Рисунок 7 Пример использования событий в качестве исходов функций

Нотация BPMN

В модели операций определены следующие правила:

  • Модель всегда начинается со стартового события
  • Для разветвления моделей по нескольким маршрутам необходимо использовать логические операторы
  • Количество пересекающихся связей на моделях следует минимизировать
  • На моделях не должно быть объектов без связей
  • Модель должна заканчиваться завершающим событием

 Ниже в таблицах 6-8 представлены типы объектов и связей, используемых при моделировании операций.

Таблица 6. Типы объектов, используемые в модели операций

ОБЪЕКТ

СИМВОЛ В ARIS

ОПИСАНИЕ

Операция и шаги

Неавтоматизированная задача

Шаг, выполняемый исполнителем без средств автоматизации

Задача получения сообщения, информации

Объект показывает получение сообщения

Задача отправки сообщения, информации

Объект показывает отправку сообщения

Пользовательская задача

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

Автоматизированная задача

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

Служебная задача

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

Задача бизнес-правила

Шаг, технология выполнения которого зависит от текущих обстоятельств и выбирается на основе заданного бизнес-правила

События

Стартовое событие без указания типа

Объект соответствует событию, с которого начинается бизнес-процесс или операция

Промежуточное событие без указания типа

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

Завершающее событие без указания типа

Объект соответствует событию, завершающему бизнес-процесс или операцию

Пул и дорожки (представляют объекты соответствующих моделей)

Пул

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

Дорожка (Lane) «Роль»

Представляет объект модели соответствия ролей и организационных единиц

Логические операторы

Исключающий шлюз

При ветвлении активируется один исходящий поток. Для активации исходящего потока при слиянии ожидает завершения любой (но только одной) входящей ветви. (Логическое Исключающее ИЛИ)

Включающий шлюз

При ветвлении активируется один или более исходящих потоков. Для активации исходящего потока при слиянии ожидает завершения всех активированных входящих ветвей. (Логическое ИЛИ)

Параллельный шлюз

При ветвлении все исходящие потоки активируются одновременно. При слиянии ожидает завершения всех входящих ветвей и активирует исходящий поток. (Логическое И)

Прочие объекты

Хранилище данных

Объект соответствует базе данных и хранилищу данных

Объект данных

Объект соответствует любому носителю информации – документ, файл

Сообщение

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

Текстовое примечание

Объект соответствует текстовому комментарию

Группа объектов

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

 

Таблица 7. Типы событий, используемые в модели операций

СОБЫТИЕ

СТАРТОВОЕ

ПРОМЕЖУТОЧНОЕ ОБРАВТЫВАЮЩЕЕ

ПРОМЕЖУТОЧНОЕ ГЕНЕРИРУЮЩЕЕ

ЗАВЕРШАЮЩЕЕ

Сообщение: получение и отправка сообщений

       

Отправка сообщений

     

Таймер: ожидание (таймаут) в ходе выполнения бизнес-процесса или операции

       

Ошибка: ошибка, возникшая в ходе выполнения бизнес-процесса или операции

     

Остановка: немедленное прекращение бизнес-процесса или операции

     

 

Таблица 8. Типы связей, используемые в модели операций


СИМВОЛ


ОПИСАНИЕ

 


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

 


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


 


Поток сообщений. Отображает передачу сообщений между пулами

 

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

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

  • Модель и описание бизнес-процессов «AS-IS» («как есть»), которая позволит отобразить текущее состояние и систематизировать выполняющиеся в данный момент бизнес-процессы, а также используемые информационные объекты, которыми оперируют описываемые процессы. На основе данной модели выявляются проблемные места при выполнении и взаимодействии процессов и определяется необходимость тех или иных изменений в существующей структуре
  • Модель и описание процессов «TO-BE» («как должно быть»), которая учитывает результаты, полученные на этапе моделирования процессов «AS‑IS» («как есть») и устраняет недостатки, выявленные в существующей организации процессов, описывает оптимальные варианты бизнес-процессов

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

К списку публикаций

Что такое бизнес-процессы. Описание, регламентация, оптимизация. Виды нотаций и их применение.

Что такое бизнес-процесс? 

Существует много разных определений понятия «бизнес-процесс». Вот, некоторые из них:

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

Процесс — это совокупность взаимосвязанных или взаимодействующих видов деятельности, которая преобразует входы в выходы. ИСО 9001

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

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

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

Функциональный и процессный подход

Процессный подход часто противопоставляется функциональному. В чем разница?

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

 

Рис. 1 Линейно-функциональная иерархическая структура.

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

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


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

 

 Рис. 3 Синие пунктирные линии – решение проблем через руководителя.

 

А что же процессный подход?

В процессном подходе взаимодействующие сотрудники – договариваются между собой. У процесса появляется свой горизонтальный «руководитель» (его ещё называют Владельцем процесса).

В результате применения процессного подхода, мы получаем:

— оптимизированные процессы

— сформулированные и согласованные всеми участниками процессов требования к качеству процессов и процедур.

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

Категории Бизнес-процессов

На уровне организации ценность для потребителя создаётся координированным управлением многими бизнес-процессами, поэтому бизнес-процессы можно разделить на три категории:

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

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

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

 

Описание бизнес-процессов

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

 При описании бизнес-процессов важно соблюсти следующие принципы:

1. Описанию подлежат те процессы, которые уже сложились(сформировались).

2. Описание процессов начинается с моделирования схем.

3. Моделировать процессы следует в соответствии с уровнями детализации.

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

  • Операция — минимальная часть дейтяльеости. Выполняется «автоматически» (переключить скорость в автомобиле, скопировать в Word и т.п.)
  • Действие — несколько последовательно выполняемых операций, требующие осознанного контроля (доехать из пункта А в пункт B, написать текст и т.п.)
  • Процедура — несколько последовательно выполняемых действий. У процедуры всегда есть результат (устное сообщение
  • Бизнес-процесс базового уровня — последовательность взаимосвязанных процедур, выполняемых несколькими исполнителями, приводящая к значимому для организации результату.
  • Направление деятельности — укрупнённая часть деятельности компании, состоящая из нескольких групп бизнес-процессов базового уровня

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


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

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

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

 

Зачем моделировать и регламентировать процессы? Всем ли это нужно?

 Всем ли подходит Процессный подход? Процессный подход полезен практически для любй компании с устоявшимися процессами. Но есть категория, для которых возврат на вложенные ресурсы будет максимальный.  Это такие компании с достаточно большим количеством управленческих воздействий. По опыту консультантов, регламентация деятельности приносит наибольшую пользу там, где количество постоянных управленческих воздействий превышает 1000.  Где Управленческие воздействия (УВ) = правила х исполнители. 

 

 

Рис. 4  Регламентация деятельности  и управление по отклонениям.

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

Язык описания бизнес-процессов. Нотации.

Нотаций описывающих процессы много. Самые популярные нотации процессов:  eEPC, BPMN, Cross Functional Flowchart (Процедура), Flowchart, IDEF0,.

Что такое нотация ?

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

 

Как правило при описании процесса отражают, как минимум четыре сущности процесса:

  • вход процедуры (процесса)
  • исполнитель процедуры
  • сама процедура (текстовое обозначение- отглагольное существительное)
  • выход процедуры (результат процедуры/процесса)

 

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

 Каждая нотация имеет свои плюсы и минусы:

Диаграмма Cross-functional Flowchart  – не отображает исполнителей, EPC – наиболее подробная, но если процессы большие, то схема разрастётся до больших плохо читаемых размеров, BPMN – современная, наиболее развивающаяся нотация, но наиболее полезна, если в будущем вы планируете автоматизировать процессы.

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

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

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

Оптимизация процессов

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

группа 1. Методы оптимизации «здравого смысла»:
  • убрать избыточный контроль
  • избавиться от дублирования 
  • автоматизация часто повторяющихся операций
  • запараллеливание процессов
  • равномерное распределение ресурсов и т.п.

    Примеры оптимизаций из первой группы : 
    При описании взаимодействия между отделом бронирования заказов и отделом продаж туристической компании было замечено, что 80% всех причин отказов в бронировании вызвано всего пятью причинами. Стандартизовав эти 5 причин, ИТ-специалисты сделали 5 кнопок во внутренней ERP-системе, что позволило значительно сократить объём переписки между отделами, ускорило и упорядочило информирование менеджеров продаж.

группа 2. Методы бережливого производства

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

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

 

Метод согласования входов — выходов между на стыках процессов SIPOC.

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

Для решения проблем на таких стыках разработана методика SIPOC. SIPOC — акроним  от слов supplier, input, process, output, customer (поставщик, вход, процесс, выход, клиент).

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

 
Рис. 5 Методика согласования требований «клиент-поставщик» SIPOC.

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

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

Автоматизация бизнес-процессов

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

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

Категории процессов

Процессы принято делить на :

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

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

Мифы и заблуждения

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

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

P.S.  Если вас интересует повышение конкурентноспособности вашей организации через повышение операционной эффективности и процессный подход — мы готовы вам в этом помочь. Имеем большой опыт проектов в разных отраслях от промышленных производств до интернет-платформ. Подробнее..

Больше полезных материалов в моем Instagram

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

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

Что такое бизнес-моделирование

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

Ключевые задачи бизнес-моделирования:

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

Бизнес-моделирование устанавливает связь между целью и исполнительным процессом. Результат процесса — документ, предоставляющий команде точное понимание границ и особенностей проекта, а также основную информацию о программном и аппаратном обеспечении клиента. Конечный результат бизнес-процесса должен включать в себя:

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

Когда возникли нотации?

Первой нотацией считается модель IDEF0, которая возникла в 1980-х годах в ВВС США. Цель ее происхождения — оптимизация работы предприятий, которые занимаются производством и реализацией военной продукции.

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

Нотация BPMN охватывает сферу управления бизнес-процессами. Версия 1.0 возникла в 2004 году и модернизировалась больше 4 раз — в 2008, 2009, 2011 и 2013 годах. Сегодня в работе применяется последняя версия 2.0.2 или ее основа 2.0.

Основные виды нотаций

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

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

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

  • VAD (value added chain diagram) — концентрируется на услугах и продукции для потребителей, представлена в виде общего, не детализированного взгляда на бизнес-процесс. Для чтения графической модели не требуется специализированных навыков.
  • EPC (event-driven process chain) — в основе модели представлены перечень шагов и запускаемые события. Нотация актуальна для анализа информационного бизнес потока, а именно входящих/исходящих документов. Поможет определить операционные риски, информационные системы, ресурсы и экранные формы.
  • Flow Charting — позволяет моделировать бизнес-процессы, учитывая различные точки зрения, применима в большинстве бизнес-моделей.
  • IDEF — создает модели, отражающие структуру системы, ее основные функции и потоки ресурсов или информации.
  • BPMN — применяется для демонстрации решения конкретных задач бизнес-процесса или схемы его прохождения в целом. Описывает все нюансы проведения бизнес-процесса, моделирует стартовые, промежуточные и итоговые события, а также определяет информационные потоки.
  • UML (Unified Modeling Languages) — применима для системного анализа и проектирования, необходима для описания требований к информационным системам бизнес-процессов.
  • VSM (Value Stream Mapping) — представлена в виде набора специфических символов, отображающих показатели затрат ресурсов и времени, используемого для анализа бизнес-процесса.
  • SIPOC — эффективна для определения границ бизнес-процесса, а также выделения взаимодействующих сторон и входов/выходов итогов процесса.

Плюсы и минусы IDEF

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

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

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

Графические отметки:

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

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

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

Недостатки:

  • графическая модель достаточно объемная и занимает много места, поэтому ее сложно прочитать, если вы не обладаете специальными навыками.
  • модель носит специализированный характер и подходит для описания бизнес-процессов, представленных в формате одной цепочки задач и событий. Многочисленное количество «или» вызовет трудности в работе с IDEF.

Особенности eEPC

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

Графические отметки базируются в основном не на фигурах, а на цветах:

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

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

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

Недостатки:

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

BPMN 2.0

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

Графические отметки:

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

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

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

Недостатки:

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

Рекомендации по выбору

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

  • Динамическая. Демонстрирует ход потоков данных и логику выполнения процессов. К данной категории относятся графические модели DFD, EPC, BPMN.
  • Структурная. Показывает связь между объектами и основные особенности исследуемого объекта. Рекомендуется обратить внимание на нотации: IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF6.

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

Что такое модель и обозначение бизнес-процессов (BPMN): преимущества и примеры

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

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

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

BPMN помогает компаниям и организациям:

  • Визуализировать бизнес-процессы
  • Документирование процессов
  • Анализировать бизнес-процессы
  • Обсудить процессы на общем языке

В чем разница между управлением бизнес-процессами (BPM) и нотацией моделирования бизнес-процессов (BPMN)

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

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

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

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

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

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

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

Примеры BPMN

Пример 1: Создание счета

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

Пример 2: Проверка кредита

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

Особенности BPMN

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

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

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

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

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

  1. Это позволяет предприятиям определять и понимать свои процедуры.
  2. Это стандартное обозначение, которое легко понимают все заинтересованные стороны компании.
  3. Помогает преодолеть коммуникационный разрыв, который часто возникает между проектированием и реализацией бизнес-процессов.
  4. Он обеспечивает отраслевой стандарт консорциума OMG.
  5. Он превосходно отображает сложность бизнес-процесса, но достаточно прост для понимания

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

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

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

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

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

Эти вопросы:

  • Чем вы сейчас занимаетесь?
  • Что вы в настоящее время делаете, что не нужно?
  • Что вы делаете в настоящее время, что можно улучшить?
  • Что вы не делаете из того, что должны делать?
  • Что вы не делаете, чего не знаете, что должны делать?

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

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

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

Есть несколько техник моделирования бизнес-процессов:

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

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

символов BPMN подразделяются на следующие категории:

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

2. Единый язык моделирования диаграмм

Унифицированный язык моделирования (UML) — это более современный подход к моделированию и документированию процессов. Первоначально UML был разработан разработчиками программного обеспечения, но был успешно использован при моделировании бизнес-процессов с более объектно-ориентированным подходом к его 14 типам диаграмм UML.

3. Технологическая схема

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

4. Диаграммы передачи данных

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

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

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

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

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

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

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

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

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

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

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

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

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

Сети Петри

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

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

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

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


Стратегическое мышление при проектировании бизнес-процессов

Зарегистрируйтесь сейчас и присоединитесь к MIT Sloan онлайн

  • 1 (Nd). «Почему и как бизнес-моделирование». Получено из KissFlow. По состоянию на 22 апреля 2019 г.
  • 2 Проктор, Дж. (2018). «10 опасных заблуждений об осуждении текущего отображения статистики и анализа». Получено из Inteq Group.
  • 3 (Nd). «Что такое BPM?». Получено из Коалиции управления рабочими процессами.По состоянию на 22 апреля 2019 г.
  • 4 (Nd). «Почему и как бизнес-моделирование». Получено из KissFlow. По состоянию на 22 апреля 2019 г.
  • 5 Pearson, S. (Nd). «9 лучших методов моделирования бизнес-процессов (с примерами)». Получено из Таллифи.
  • 6 Pearson, S. (Nd). «9 лучших техник моделирования бизнес-процессов (с примерами)». Получено из Таллифи.
  • 7 Ceta, N. (Nd). «Все, что вам нужно знать о диаграммах UML: типы и 5+ примеров».Получено из Таллифи.
  • 8 Pearson, S. (Nd). «9 лучших техник моделирования бизнес-процессов (с примерами)». Получено из Таллифи.
  • 9 Роуз М. (август 2008 г.). «Блок-схема». Получено с TechTarget.
  • 10 Ambler, S. (Nd). «Диаграмма потока данных (DFD): быстрое введение». Получено из Agile Modeling.
  • 11 Бангертер Дж. (Июль 2017 г.). «Символы, типы и подсказки диаграммы потоков данных». Получено из LucidChart.
  • 12 (сентябрь 2018 г.). «Методики моделирования бизнес-процессов с примерами». Получено с Creately.
  • 13 Джайн, А. (Nd). ‘Унифицированный язык моделирования (UML) | Диаграммы последовательностей ». Получено с GeeksforGeeks. По состоянию на 22 апреля 2019 г.
  • 14 Джайн, А. (Nd). ‘Унифицированный язык моделирования (UML) | Диаграммы последовательностей ». Получено с GeeksforGeeks. По состоянию на 22 апреля 2019 г.
  • 15 (Nd). «Что такое диаграмма сотрудничества UML?».Получено из Visual Paradigm. По состоянию на 25 апреля 2019 г.
  • 16 (сентябрь 2018 г.). «Методики моделирования бизнес-процессов с примерами». Получено с Creately.
  • 17 Pearson, S. (Nd). «9 лучших техник моделирования бизнес-процессов (с примерами)». Получено из Таллифи. Доступ 25 апреля 2019 г.
  • 18 (сентябрь 2018 г.). «Методики моделирования бизнес-процессов с примерами». Получено с Creately.
  • 19 Дженсен, К.(Июнь 2005 г.). «Введение в теоретические аспекты раскрашенных сетей Петри». Получено из Springer Link.
  • 20 (сентябрь 2018 г.). «Методики моделирования бизнес-процессов с примерами». Получено с Creately.
  • 21 (Nd). «Объектно-ориентированные методологии». Получено из Career Ride.

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

Цель: Раньше брак был вопросом самоподготовки.Они становятся комитетом, который занимается приготовлением пищи, дизайном свадебных украшений, приемом гостей и подготовкой всего к свадьбе. Не забывайте, что у ведущего тоже много работы, особенно это касается организации мероприятий в день свадьбы. Однако теперь все было по-другому. Многие хозяева настолько заняты работой, что уже не могут позволить себе оформить свадебную церемонию. Тогда лучшим решением станет свадебный организатор, который станет одним из самых продаваемых предприятий на рынке. В основном текущие услуги WO ограничиваются координацией всего, что необходимо для свадьбы.Они предлагают услуги клиентам через определенные пакеты на выбор для свадеб. Действительно, для некоторых людей, имеющих достаточный бюджет, нетрудно скорректировать пожелания, содержащиеся в этих пакетах. Однако для групп людей с минимальным бюджетом все обстоит иначе. Большая часть бюджета — это проблема сама по себе для пар, которые будут пользоваться услугами WO Services. На этом фоне выполняется стратегический бизнес-план, помогая потенциальным женихам и невестам как клиентам планировать свою свадьбу в соответствии с их бюджетом через свадебные порталы на базе ИТ и контейнер в виде «брачного банка» для финансирования свадьбы. свадьба.Дизайн / методология / подход: в этом исследовании используется качественный метод, направленный на описание и анализ социальных действий, которые имели место. Исследование будет состоять из нескольких этапов, в том числе на первом этапе исследователь начинает собирать различные материалы, которые могут поддержать исследование и быть в состоянии предоставить адекватную информацию. Дальнейший анализ выполняется для бизнес-среды и внешней и внутренней среды IS / IT с использованием анализа бизнес-среды, SWOT-анализа и т. Д.Выводы / результат: Цель данного исследования — составить карту стратегического планирования бизнеса и информационных технологий Smart Bank Wedding Organizer. На основе анализа внутренней и внешней среды, SWOT-анализа и т. Д. Можно отобразить бизнес-стратегию и стратегию управления ИБ / ИТ, которая состоит из финансов, сотрудников, ИТ / ИБ, заинтересованных сторон, клиентов, рынка и операционной деятельности. к их соответствующим потребностям. Планируя бизнес-стратегию и стратегию управления ИБ / ИТ, можно надеяться, что планирование, развитие и управление бизнесом будут осуществляться хорошо и устойчиво.Тип статьи: Концептуальное исследование.

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

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

Хотя процедура подробно описывает, как задача выполняется и как она вписывается в процесс, в отношении того, как и кто выполняет задачу, i.е. процедура детализирует технические требования задачи к процессу [4], процесс представляет собой совокупность действий и поведения, выполняемых людьми или механизмами для достижения одного или нескольких результатов [5]. Процесс описывает последовательность действий, выполняемых от начала до конца, направленных на достижение результата для клиента, с акцентом на деятельности и ее проведении [4].

На рис. 1 представлена ​​последовательность операций процесса и взаимодействие его элементов. У каждого процесса есть свои конкретные индикаторы мониторинга и измерения, необходимые для управления.Формализация процесса необходима для создания продукта или услуги, поскольку это зависит от входных данных, нескольких шагов и процедур для изготовления конечного продукта [5, 6]. 1.

Представление элементов в процессе

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

2.1 Процессы отображения и моделирования

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

Процесс картирования организации — это знание и анализ ее процессов и взаимосвязи данных, и он структурирован по нисходящей схеме (от верха организации к основанию) до уровня, позволяющего тщательно понимание продуктов, услуг и результатов [4].

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

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

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

2.2 Управление бизнес-процессами

BPM — это управленческая дисциплина, которая объединяет стратегии и цели организации с ожиданиями и потребностями клиентов, сосредоточиваясь на процессах от начала до конца.Эта методология включает в себя стратегии, цели, культуру, организационные структуры, роли, политики, методы и технологии для анализа, проектирования, внедрения, управления производительностью, процессов и установления процессов управления [5]. Он основан на двух столпах:

Первый касается исследований [9, 10] о статистическом контроле процесса, который порождает нынешнее управление качеством, представленное Шесть сигм.

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

Применение BPM в качестве метода управления бизнес-процессами, которые включают несколько технологий, таких как онлайн-инструменты, облачные вычисления, является конкурентным преимуществом, а также поддерживает такие изменения, как: маркетинг, новые технологии, ИТ-инфраструктура, а также клиенты и поставщики. предметы первой необходимости [7].

2.3 ISO, BPM CBOK и BABOK

Стандартизация процедур стала обычным явлением в основном из-за глобализации окружающей среды [7].При совместном применении три основных инструмента обеспечивают поддержку для построения процесса: ISO 9000, Общий свод знаний по управлению бизнес-процессами (BPM и CBOK) и свод знаний бизнес-анализа (BABOK). Свод знаний (BOK) — это практическое руководство для профессионалов, которое является источником знаний для большинства профессиональных учебных программ. Его содержание представляет основные компетенции, необходимые профессионалам до их аккредитации [7].

Международная организация по стандартизации (ISO) была создана в 1947 году для содействия нормализации продуктов и услуг благодаря идеологии постоянного совершенствования.Среди нескольких публикаций серия стандартов ISO 9000 касается менеджмента качества. Процессный подход [13] позволяет управлять организацией за счет взаимодействия процессов. Несколько предприятий по всему миру ищут сертификат ISO [13], поскольку сертификация соответствия ISO 9000 повышает доверие к организации.

Чтобы избежать вмешательства между бизнес-аналитиками и бизнес-аналитиками, они оба должны понимать потребности организации.Опыт этих специалистов может быть подтвержден сертификатом. Ассоциация профессионалов управления бизнес-процессами (ABPMP) сертифицирует профессионалов на основе экзамена CBPP (Certified Business Process Professional), который требует глубокого знания процедур CBOK BPM [5].

Кроме того, Международный институт бизнеса предлагает два сертификата: CBAP (Certified Business Analysis Professional) для юниоров и CCBA (Certificate of Competency in Business Analysis) для профессионалов высшего уровня.Однако требуется тщательная экспертиза BABOK [6].

Модель и нотация бизнес-обработки (BPMN) — BPI


Описание

Обзор языка моделей и нотаций бизнес-процессов (BPMN) для моделирования бизнес-процессов.
При реализации бизнес-процессов обычно существует большой разрыв между бизнес-семантикой (процесс, действие, участник, оркестровка, хореография, элементы данных и т. Д.) И техническими языками реализации (REST, WSDL, транспортный протокол, шина сообщений и т. Д.)). Цель BPMN — восполнить этот пробел, предоставив стандартную нотацию для описания бизнес-процессов плюс стандартное отображение этой нотации в исполняемый язык описания, такой как WSBPEL. Стандарт BPMN 2.0 даже позволяет напрямую выполнять бизнес-модели BPMN без необходимости перевода.
Основные элементы нотации BPMN — это объекты потока для моделирования действий и событий, объекты данных для моделирования фрагментов информации, соединения объектов с информацией модели и потока управления, а также дорожки для моделирования участников процесса.Четыре различных типа диаграмм позволяют моделировать процессы, хореографию процессов, взаимодействие между участниками и разговоры.

Выписка

© Питер Р. Эгли 2015
1/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
ОБЗОР БИЗНЕС-ПРОЦЕССА
ЯЗЫК МОДЕЛИ И ОБОЗНАЧЕНИЯ (BPMN) ДЛЯ
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
ПИТЕР Р. ЭГЛИ
INDIGOO.COM
BPMNBUSINESS PROCESS
МОДЕЛЬ И ОБОЗНАЧЕНИЯ
© Peter R.Egli 2015
2/24
Ред. 1.60
BPMN — Модель и обозначение бизнес-процесса indigoo.com
Содержание
1. Что такое BPMN?
2. Основные части BPMN
3. Область действия BPMN
4. Основные концепции BPMN
5. Сравнение BPMN и BPEL
6. Элементы нотации BPMN
7. Сравнение BPMN 2.0 и BPMN 1.2
© Питер Р. Эгли 2015
3/24
Ред. 1.60
BPMN — Модель и обозначение бизнес-процессов indigoo.com
1. Что такое BPMN?
BMPN — это язык графического моделирования и нотации для бизнес-процессов (= графический DSL —
Domain Specific Language) со следующими целями:
1.Общий язык, понятный для разных заинтересованных сторон.
2. Визуализация языков исполнения, таких как WSBPEL.
3. Формат обмена между инструментами для описания процесса и диаграмм.


Incoming_Flow


isInterrupting = «true» parallelMultiple = «false»>
Outgoing_Flow


startQuantity = ”1 ″ triggeredByEvent =” false ”>
Деловые люди
используют и отслеживают процессы
Бизнес-аналитики
определяют процессы
Разработчики
реализуют процессы
BPMN = общий язык и нотация
© Питер Р.Egli 2015
4/24
Ред. 1.60
BPMN — Модель и обозначение бизнес-процесса indigoo.com
2. Основные части BPMN (1/3)
A. Типы диаграмм:
BPMN определяет следующие 4 типа диаграмм.
Хореография Организация / процесс
Совместная беседа
© Питер Р. Эгли 2015
24/5
Ред. 1.60
BPMN — Модель и нотация бизнес-процесса indigoo.com
2. Основные части BPMN (2/3)
B. Нотация бизнес-процесса :
BPMN определяет общий набор элементов моделирования, которые будут использоваться в диаграммах BPMN.
Data
Connecting Objects
Flow Objects
Swimlanes
Artifacts
Activity
Event Gateway
Data
Object
Data
Input
Data
Output
Data
Store
Message Flow Sequence Association Data Association
Annotation Group
Lane Text
Group
© Питер Р. Эгли, 2015 г.
6/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
2. Основные части BPMN (3/3)
C. Отображение на язык выполнения:
BPMN определяет отображение на язык исполнения WSBPEL.
BPMN примерно отображается на WSBPEL, но может также отображаться на другой язык выполнения.
BPMN
Модель бизнес-процесса
Отображение на

bpmn: id = ”_ Oig9ANU5Edyqa7yB__NlQQ”>

$ thisStartRequestMsg.body / tns: city rom>
$ timeService1GetCityTimeRequestMsg.param
eters / TimeService1: city


WSBPEL to run в среде исполнения BPEL
© Peter R.Egli 2015
24/7
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
3. Объем BPMN
Для моделирования бизнес-аспектов используются разные нотации и языки моделей.
BPMN — это обозначение для моделирования бизнес-процессов.
StrategyVision Организация
Функциональная структура

Услуги
Бизнес
Правила
Бизнес
Процессы
Данные
Информация
Сбалансированная
оценочные карты
Организация
Диаграмма
BPMN
Корпоративная
Архитектура
Стратегия
Схема
908 908 ArchiMate Entity Бизнес
Правила
Модель
Функциональная
Разложение
Диаграмма
© Peter R.Egli 2015
8/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
4. Основные концепции BPMN (1/5)
A. Оркестровка / процессы (1/2):
Процесс описывает последовательность или поток действий как часть работы, которую предстоит выполнить
(= рабочий процесс).
Процессы содержат элементы потока BPMN (события, действия, шлюзы) и вызываемые процессы
.
Типы процессов:
a. Частный неисполняемый процесс (процесс только для документальных целей)
b.Частный исполняемый процесс (содержит достаточно деталей, чтобы быть исполняемым)
c. Открытый процесс
Действие
Шлюз событий
Задача
Подпроцесс
Действие
(= абстрактный класс super
)
Конкретное действие

типов
Действие вызова
© Питер Р. Эгли 2015
24/9
Ред. 1.60
BPMN — Модель и обозначение бизнес-процессов indigoo.com
4. Основные концепции BPMN (2/5)
A. Согласование / процессы (2/2):
a. Частный процесс:
Частный процесс специфичен для организации.Нет взаимодействия с другой дорожкой
(пул = участник).
г. Открытый процесс:
Общедоступные процессы показывают взаимодействия между частным процессом и другим процессом или участником (пулом)
.
Внутреннее устройство публичного процесса не показано, только взаимодействие с другим процессом.
PrivateProcess
Начало
Проверить кредитную историю Проверить заказ
Полнота
Рассчитать цену Отправить уведомление
Конец
«BusinessPro…
Утвердить заказ
« BusinessPro…
Утвердить заказ
CarOwner
Начало
Линия помощи Получить
Запрос
Отправить адрес Получить повреждение

Мы проверим, в чем проблема.Egli 2015
10/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
4. Основные концепции BPMN (3/5)
B. Сотрудничество:
Сотрудничество показывает взаимодействие между участниками, смоделированное в виде дорожек (пул , переулок).
Диаграмма сотрудничества обычно содержит 2 или более пулов / дорожек.
Потоки сообщений пересекают границы пула, в то время как потоки последовательностей соединяют действия в пулах.
ПациентЗдравоохранениеКонтакт
Центр / Врач
Заболевание
Обратитесь к врачу
Запрос
Получите
Запрос
Отправьте
Запись на прием
Получите
Запись на прием
Отправьте
Симптомы
Получите
Симптомы
Дайте лекарство
Получите
Лекарство
см. докторЯ хочу к своему врачу
© Peter R.Egli 2015
24/11
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
4. Основные концепции BPMN (4/5)
C. Хореография:
Хореография показывает взаимодействия между участниками, смоделированные в виде пулов.
Хореографии определены вне пулов и существуют между пулами.
Основное внимание в хореографии уделяется обмену информацией между участниками.
В хореографии нет центрального контроля, ответственного лица или наблюдателя.
Пациент
Доктор
Запрос врача
Я хочу увидеть
мой доктор
Сходи на прием
доктор
Пациент
Доктор
Принять симптомы
Я чувствую себя больным
Пациент
Доктор
Справиться с рецептом
Забрать свое лекарство

Пациент
Доктор
Hanlde Medicine
Мне нужно мое лекарство

Вот ваше лекарство

© Peter R.Egli 2015
12/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
4. Основные концепции BPMN (5/5)
D. Беседа:
Диаграммы диалогов показывают логические обмены сообщениями между участниками.
В отличие от диаграмм процессов, сотрудничества и хореографии, диаграммы разговоров
показывают различные разговоры (обмен информацией) между участниками с высоты птичьего полета.
Розничный продавец Поставщик
Доставка
Переговоры
Грузополучатель
Отгрузка
График
Доставка /
Отгрузка
План
Грузоотправитель
Доставка /
Отгрузка
План
Страхование перевозчика
Страхование
© Peter R.Egli 2015
13/24
Ред. 1.60
BPMN — Модель и обозначение бизнес-процессов indigoo.com
5. Сравнение BPMN и BPEL
BPMN и BPEL разделяют общие концепции, но не являются инструментами для одной и той же цели.
BPMN — это в основном обозначение, которое определяет, как бизнес-процессы могут быть смоделированы графически.
WS-BPEL определяет машинно-обрабатываемый и исполняемый формат для бизнес-процессов.
BPMN 1.2 обычно переводится в BPEL 2.0, который, в свою очередь, выполняется во время выполнения BPMN.
БПМН 2.0 может быть напрямую выполнен во время выполнения BPMN без перевода в другой формат.
Переводчик языка описания
Выполнение
Язык
Среда выполнения
BPMN 1.2 Отображение BPMN
WS-BPEL
(BPEL 2.0)
Среда выполнения BPMN, такая как intalio
BPMN 2.0 — BPMN 2.0 Среда выполнения BPMN
Java-компилятор Java Байт-код Java C ++ Виртуальная машина
C / C ++ Компилятор Машинный код CPU
© Питер Р. Эгли 2015
14/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
6. Элементы нотации BPMN (1/10)
Действие:
Действия (задачи, подпроцессы) — это исполняемые элементы процесса BPMN.
Тип действия Символ Описание
Задача
Атомарная активность в процессе, которая не может быть далее разбита
.
Обычно задача выполняется конечным пользователем или приложением.
Подпроцесс
Действие с внутренней структурой, содержащей действия,
шлюзы, события и потоки последовательности.
Активность вызова
Определяет точку, в которой вызывается глобальная задача или процесс.
Действие вызова отличается от подпроцесса тем, что это ссылка
на процесс, в то время как подпроцесс — это сам процесс.
Это означает, что действие вызова вызывает повторно используемый процесс или задачу.
Вызываемый подпроцесс или задача может вызываться несколько раз с помощью
различных операций вызова.
Задача
Подпроцесс
Действие вызова
(Задача)
Действие вызова
(Подпроцесс)
© Питер Р. Эгли 2015
15/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
6. Элементы нотации BPMN (2/10)
Типы задач (1/2):
Тип задачи Символ Описание
Абстрактная задача Задача без какой-либо специализации.
Служебная задача Задача, использующая какую-то службу, например веб-службу.
Отправить задачу
Задача для отправки сообщения внешнему участнику. После отправки сообщения
задача завершена.
Задача приема
Задача, ожидающая получения сообщения от внешнего участника. После того, как сообщение
получено, задача завершена.
Создание экземпляра
задачи приема
То же, что и задача получения, но создает экземпляр процесса
(«создает маркер процесса»).
Задача
Сервисная задача
Отправить задачу
Получить задачу
Процесс
Создать экземпляр
Получить задачу
© Питер Р. Эгли 2015
16/24
Ред. 1.60
BPMN — Модель и нотация бизнес-процесса indigoo.com
6. Элементы нотации BPMN (3/10)
Типы задач (2/2):
Тип задачи Символ Описание
Пользовательская задача Задача, выполняемая человеком с помощью программного приложения.
Задача, выполняемая вручную
Задача, выполняемая человеком без помощи какого-либо процесса
механизма выполнения или приложения.
Бизнес-правило
задача
Предоставляет входные данные для механизма бизнес-правил.
Получает выходные данные от механизма бизнес-правил.
Задачи бизнес-правил связывают процесс или подпроцесс с механизмом бизнес-правила
.
Задача сценария
Задача сценария выполняется подсистемой бизнес-процессов.
Когда сценарий завершается, задача также завершается.
Задача пользователя
Задача вручную
Бизнес-правило
Задача
Задача сценария
© Peter R.Egli 2015
17/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
6. Элементы нотации BPMN (4/10)
Маркеры задач:
Дополнительные маркеры добавляют к задачам дополнительную семантику.
Маркер задачи Символ Описание
Цикл Задача цикла повторяет свое действие, пока установлен флаг цикла.
Мульти-
экземпляр
последовательный
Задача выполняется в нескольких экземплярах в последовательном порядке.
Multi-
instance
parallel
Несколько экземпляров задачи выполняются параллельно.
Компенсация
Компенсация используется в случае ошибок (исключений) для отмены шагов, которые уже выполнены
(вызов обработчика компенсации для «отката»).
Разрешено
маркер
комбинаций
Несколько экземпляров последовательная и
компенсация
Многоэкземплярная параллельная и
компенсация
Цикл и компенсация
Циклическая задача
Мультиэкземплярная
Последовательная задача
Мультиэкземплярная
Параллельная задача
Компенсация
Задача
Задача
Задача Задача
© Питер Р.Egli 2015
18/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
6. Элементы нотации BPMN (5/10)
Типы подпроцесса:
Подпроцесс
тип
Символ Описание
Транзакция
подпроцесс
Транзакционный подпроцесс выполняет все внутренние действия либо
успешно, либо ничего (случай исключения).
Обычно подпроцесс транзакции объединяется с событием отмены, чтобы
вызвать обработчик отмены (отката) транзакции.
Подпроцесс события
процесс
Выполнение подпроцесса события запускается событием. Выполнение
не зависит от родительского потока процесса, поэтому нет входящих и исходящих потоков последовательности
. Однако подпроцесс
события выполняется только тогда, когда родительский процесс (или подпроцесс) активен.
Транзакция
Подпроцесс
© Питер Р. Эгли 2015
19/24
Ред. 1.60
BPMN — Модель и нотация бизнес-процесса indigoo.com
6. Элементы нотации BPMN (6/10)
Маркеры подпроцесса (1 / 2):
Подпроцессы могут иметь те же маркеры, что и задачи.Кроме того, специальный маркер
может использоваться в подпроцессах для выражения менее строгого порядка выполнения.
Подпроцесс
маркер
Символ Описание
Цикл
Циклический подпроцесс повторяет свои внутренние действия, пока установлен флаг цикла
.
Мульти-
экземпляр
последовательный
Подпроцесс выполняется в нескольких экземплярах в последовательном порядке.
Multi-
instance
parallel
Несколько экземпляров подпроцесса выполняются параллельно.
Компенсация
Компенсация используется в случае ошибок (исключений) для отмены шагов, которые уже выполнены
(вызов обработчика компенсации для «отката»).
Ad-hoc
sequence
Ad-hoc подпроцессы имеют менее строгий временной порядок действий.
Внутренние действия могут иметь или не иметь потоков последовательности.
Одноранговый последовательный означает, что содержащиеся в нем действия выполняются последовательно.
Ad-hoc
parallel
В параллельном специальном подпроцессе содержащиеся действия выполняются параллельно.
Цикл
Подпроцесс
Несколько экземпляров
Последовательный
Подпроцесс
Несколько экземпляров
Параллельный
Подпроцесс
Компенсация
Подпроцесс
Одноранговый
Последовательный
Подпроцесс
Одноранговый Параллельный
Подпроцесс Процесс
© Питер Р. Эгли 2015
20/24
Ред. 1.60
BPMN — Модель и нотация бизнес-процесса indigoo.com
6. Элементы нотации BPMN (7/10)
Маркеры подпроцесса (2/2):
Маркер задачи Символ и описание
Разрешено
маркер
комбинаций
Цикл и компенсация
Цикл и одноранговая (параллельная
и последовательная)
Многоэкземплярная и
компенсация (параллельная и
последовательная)
Многоэкземплярная и специальная
( параллельный и последовательный)
Ad-hoc и компенсация
(параллельный и последовательный)
Цикл и компенсация и
ad-hoc (параллельный и
последовательный)
Многоэкземплярный и компенсация и ad-hoc (параллельный и последовательный)
Loop &
Компенсация
Sub-Pro cess
Цикл и Ad-hoc
Подпроцесс
Мультиэкземпляр и
Ad-hoc
Подпроцесс
Мультиэкземпляр и
Компенсация
Подпроцесс
Ad-hoc и
Компенсация
Подпроцесс
Loop & Ad -hoc
и
Компенсация
Подпроцесс
Многоэкземплярный и
Специальный и
Компенсация
Подпроцесс
© Peter R.Egli 2015
21/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
Пул процесса

Пул черного ящика
Нет ссылки на процесс
Содержит процесс
Типы пула
6. Элементы нотации BPMN (8/10)
Дорожки (1/2):
Дорожки представляют собой бассейны (белый или черный ящик) или дорожки (= перегородки в пулах).
Пулы представляют участников, которые являются партнерскими организациями, например, поставщиками.
Участники часто несут ответственность за выполнение процесса в пуле.
Упрощенная метамодель:
PartnerEntity
Пример:
Компания
Участник
PartnerRole
Пример:
Покупатель
Процесс
<<представляет>>
<<представляет>>
<< отвечает за >>
Пул
<< Графический
представление >>
Swimlane
Lane
(= подраздел
в пуле)
© Питер Р. Эгли 2015
22/24
Ред. 1.60
BPMN — Модель бизнес-процесса и обозначение indigoo.com
ProcessPool
6. Элементы нотации BPMN (9/10)
Дорожки (2/2):
Маркеры дорожек:
Дорожка плавания
тип
Символ Описание
Пул процесса
(«Белый —
»)
Пул, содержащий процесс.
Черный ящик
Пул
Пул, не содержащий процесса.
Дорожка
Дорожки — это подразделы в пуле или процессе. Дорожки могут быть вложенными. Дорожки
не имеют семантики в BPMN, т. Е. Дорожки представляют собой простую концепцию группировки и разделения
.
Пул Blackbox
Пул с
дорожками
Продакшн-продажи
Swimlane
маркер
Обозначение Описание
Множественный экземпляр

Мультиэкземплярный пул представляет участников с множеством экземпляров.
Пример: несколько поставщиков.
Мультиэкземпляр
Пул
© Питер Р. Эгли 2015
23/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
6. Элементы нотации BPMN (10/10)
Шлюзы:
Шлюзы используются для производства и потребления токенов процессов (экземпляров процессов).
Тип шлюза Символ Описание
Эксклюзивный шлюз

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

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

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

Сложные шлюзы используются для моделирования сложного режима синхронизации.
Пример: 3 из 5 токенов входящего потока должны присутствовать для создания исходящего токена процесса
(в зависимости от условий исходящих потоков
). Семантика исходящего и входящего токенов
такая же, как и у включительных шлюзов
.
Шлюз событий
Шлюз событий представляют точки ветвления на основе событий, а не условий
.
Пример: получение разных сообщений отправляется по разным путям процесса
для обработки сообщений.
X
© Питер Р. Эгли 2015
24/24
Ред. 1.60
BPMN — Модель бизнес-процесса и нотация indigoo.com
7. BPMN 2.0 по сравнению с 1.2
В BPMN 2.0 внесен ряд изменений:
• Формализация и разъяснение семантика исполнения всех элементов BPMN
• Механизм расширения для графических элементов
• Уточнение композиции событий и корреляция
• Определение модели хореографии (хореография, хореографическая диаграмма)
• Переопределение и уточнение различных элементов BPMN (см. таблицу ниже)
BPMN 1.2 Функция BPMN 2.0 Функция
Подпроцесс многократного использования Действие вызова
Встроенный подпроцесс Подпроцесс
Абстрактный процесс Открытый процесс
Направленная ассоциация, чтобы показать, как объекты данных являются входами и выходами
действий
Соединитель ассоциации данных для отображения входов и выходов
Сообщение — это элемент BPMN. Сообщение — это только графический декоратор. В дополнение к роли исполнителя, роль HumanPerformer позволяет
идентифицировать людей, выполняющих задачу
Промежуточные события возможны без входящей последовательности
потоков
Промежуточные события должны иметь входящий поток последовательности

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

Деятельность

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

Аннотации

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

Артефакты

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

Ассоциация

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

Схема бизнес-процессов (BPD)

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

Модель бизнес-процесса

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

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

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

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

Соединение объектов

Объекты потока соединяются вместе с помощью Connecting Objects. Есть три типа связывающих объектов: поток последовательности, поток сообщений и ассоциация.

Объект данных

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

События

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

BPMN 2.0 Учебное пособие и примеры

Эта статья является частью учебного пособия по BPMN 2.0, включая понимание символов и диаграмм BPMN.

Business Process Modeling and Notation 2.0 (BPMN 2.0) был разработан, чтобы помочь устранить путаницу в понимании карт процессов, пытается ли сотрудник или консультант понять смысл. Часть секрета заключается в использовании стандартизированных символов.

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

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

Разрушение BPMN 2.0

Для создания диаграммы BPMN 2.0 используется базовый набор элементов, которые подразделяются на эти три основные группы:

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

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

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

  • События — отправляет триггер для запуска, например получение предупреждения или предупреждения о проблеме.
  • Действия — это выполняемые задачи, такие как циклы, различные экземпляры и даже подпроцессы.
  • Шлюзы — точка, в которой пути могут меняться в зависимости от принятого решения. Направление может идти по Пути A, или, если будет принято другое решение, будет выбран Путь B.
  • Поток последовательности — определяет порядок действий.
  • Поток сообщений — направление сообщений.
  • Associates — текст внутри действия, события или шлюза.
  • Объект данных — Объясняет, какие данные необходимы для продолжения действия.
  • Группа данных — не изменяют последовательность операций на диаграмме, но обозначают группу действий.
  • Аннотация — Дополнительные пояснения к модели.
  • Артефакты — сюда входят группы данных и аннотации.

Преимущества использования BPMN 2.0

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

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

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

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

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

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

Выплата может быть огромной

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

  • Частные бизнес-процессы — они не связаны между отделами или организациями.
  • Абстрактные бизнес-процессы — используются для передачи процесса во внешний мир, но не включают в себя действия частного процесса.
  • Бизнес-процессы совместной работы — используются для описания действий между несколькими бизнес-объектами.

В модели BPMN 2.0 также есть различные типы диаграмм:

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

Узнайте больше о типах шлюзов

Как вы можете представить в BPMN 2.0 существуют разные типы шлюзов. Давайте посмотрим глубже:

  • Исключительно: переадресация может происходить только на одном из выходных путей.
  • Включение: поток может отклоняться от одного или нескольких выходных потоков в зависимости от принятого решения. Но в следующем шлюзе все потоки должны быть завершены включительно. Единственное исключение — когда действие или триггер не определены.
  • Parallel: Это позволяет нескольким потокам параллельно, с любым условием, но потоки должны быть завершены в другом шлюзе, если нет определенного действия или триггера.
  • Эксклюзивный запуск: это когда вы создаете процесс через шлюз с несколькими параметрами.
  • Параллельный запуск: процесс может быть запущен при возникновении каждого последующего события.
  • События: шлюз будет приостановлен до тех пор, пока выходной поток не вызовет событие.
  • Сложный: Редкий шлюз, используемый только для представления сложных сценариев, в которых необходимы синхронизация и разделение.

Принципы моделирования BPMN 2.0

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

Также важно помнить, что BMPN 2.0 не является диаграммой потоков данных.

Затем следуйте этим ключевым принципам:

  1. Создайте простой и понятный поток
  2. Использовать стандарты BPMN
  3. Добавьте маркировку, где необходимо
  4. Включите четкие диаграммы

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

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

Хорошей практикой является использование стандартов и рекомендаций BPMN 2.0:

  • Пулы: в каждом расширенном пуле следует моделировать только один процесс.По всей длине разместите бассейны друг над другом. Свернутые пулы должны иметь только один поток исходящих сообщений.
  • Дорожки: Если одна задача выполняется в полосе, вы должны ее создать. Не создавайте схемы шлюзов, событий или задач между двумя полосами движения.
  • Действия: Не создавайте несколько одинаковых задач для нескольких участников. Разместите только одну задачу в одной области. Используйте условия распределения для обозначения актеров.
  • Шлюзы: используйте шлюзы только для разветвления потоков. Не присоединяйтесь и не разделяйте шлюз.Присоединяйтесь к любым сплитам одинаково. Поддерживайте балансировку шлюзов. Используйте один и тот же тип шлюза для присоединения к потоку и для разделения.
  • Коннекторы: соединяют все шлюзы, события и действия с помощью потоков последовательности. Не используйте потоки сообщений для подключения действий внутри одного пула. Убедитесь, что фигуры всегда связаны. Не соединяйте элементы из разных пулов потоками последовательности. Используйте потоки сообщений для соединения обменов данными между процессами.
  • Маркировка: Процессы всегда должны быть четко обозначены без сокращенных названий или сокращений.Мероприятия должны быть обозначены одним существительным и одним глаголом. Не используйте повторяющиеся имена. Продолжайте использовать метки для нескольких начальных и конечных событий. Любые шлюзы расхождения должны иметь четкое название. Если имена не подходят для конкретных шлюзов, можно использовать сокращения или числа.
  • Диаграммы
  • : должны быть удобными для чтения и упрощенными.

Чтобы данные и модели были понятными, очень важно правильно определить объем задач. Воспользуйтесь этими советами в помощь:

  • Ограничьте избыточность задач.Рассмотрите точку зрения конечного пользователя. Если один и тот же человек выполняет последовательные действия, их следует объединить, чтобы сохранить простоту.
  • Ищите способы интегрировать занятия. Бывает такое явление, как слишком много деталей и даже несовпадение.
  • Используйте подпроцессы только для группировки действий, которые обслуживают один и тот же процесс. Если вам нужно углубиться в подробности, вы можете расширить обозначенные подпроцессы.
  • Обязательно отправляйте сообщения в процессы, где это необходимо, до того, как дойдете до конечного события.
  • Большинство конечных событий имеют нормальное окончание, которое передает конечное состояние процесса.
  • Множественное окончание может иметь несколько конечных событий, которые выполняются одновременно.
  • Некоторые процессы могут инициировать запуск сообщения в конце, чтобы инициировать обмен между двумя пулами.
  • Эскалация может произойти в конце процесса, чтобы запустить потоки событий захвата.
  • Сигнал ошибки используется для завершения процесса.
  • Терминатор завершит процесс, закрыв любой активный токен.
  • Компенсация отменяет все ранее выполненные действия через поток компенсации.

Итого

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

Похожие записи

Вам будет интересно

Ип штрафы: 10 самых частых штрафов для ИП

Виды экономической прибыли: Недопустимое название — e-xecutive.ru

Добавить комментарий

Комментарий добавить легко