Что такое нотация в моделировании
Нотации моделирования бизнес-процессов
Нотация IDEF0
Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT. Методология IDEF0 — это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции (на рисунке представлена графическая диаграмма в нотации IDEF0 — пример реализован в системе Business Studio, которая включает в себя функции программы для построения IDEF0). Бизнес-процессы в нотации IDEF0 представляются в форме прямоугольника, а стрелки отражают связь с другими процессами и внешней средой. Особенностью нотации является:
Нотация IDEF0 используется для создания верхнего уровня модели бизнес-процессов. Построение IDEF0-диаграммы верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. На нижнем уровне для описания алгоритма (сценария) выполнения процесса допустимо сменить стандарт IDEF0 на нотацию Процесс, Процедура, EPC или BPMN 2.0.
Подробнее о нотации IDEF0
С методологией SADT можно подробно ознакомиться в монографии Дэвида А. Марка и Клемента МакГоуэна «Методология структурного анализа и проектирования SADT».
Нотация Процесс (Basic Flowchart в Visio)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Используются графические элементы: событие, процесс, решение, два типа стрелок — стрелки предшествования и стрелки «Поток объектов».
Нотация Процесс поддерживает декомпозицию на подпроцессы.
Нотацию Процесс можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотация Процедура (Cross-Functional Flowchart в Visio)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Дополнительно к графическим элементам, применяемым в нотации Процесс, используются дорожки (Swim Lanes), обозначающие организационные единицы — исполнителей действий процесса.
Нотация Процедура поддерживает декомпозицию на подпроцессы.
Нотацию Процедура можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Нотация BPMN 2.0
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Особенностью нотации BPMN 2.0, появившейся в качестве стандарта моделирования в 2011 году, является то, что она предназначена как для моделирования бизнес-процессов, так и для их исполнения. Она доступна для понимания и удобна как бизнес-аналитикам, так и разработчикам, которые занимаются автоматизацией исполнения процессов. Для экспорта схемы процесса в BPMS-систему в Business Studio используется стандарт XPDL.
В Business Studio представлено 2 типа диаграмм BPMN 2.0 — диаграммы процессов и диаграммы взаимодействия процессов. Используются следующие графические элементы: процессы, события, шлюзы; 3 типа стрелок: поток управления, поток сообщений, ассоциации; объекты: документы, информация, сообщения, базы данных. Важно, что в Business Studio все элементы диаграмм BPMN являются объектами репозитория.
В Business Studio в нотации BPMN можно строить иерархическое дерево процессов, т.е. поддерживается декомпозиция.
Для процесса BPMN можно автоматически сформировать регламент и другие отчеты, эта нотация применяется преимущественно для описания процессов нижнего уровня, особенно со сложной логикой исполнения.
Нотация EPC (Event-Driven Process Chain)
Данная нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Диаграмма, описанная в нотации EPC (событийная цепочка процессов), представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её. В нотации EPC ветвление стрелок осуществляется с использованием операторов.
Нотация EPC поддерживает декомпозицию на более низкие уровни. Диаграмма декомпозируемой функции EPC может быть описана только в нотациях EPC или BPMN 2.0.
Нотацию EPC можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.
Организация эффективного управления
Главная страница » Блог » Самые популярные нотации описания и моделирования бизнес процессов
Самые популярные нотации описания и моделирования бизнес процессов
Я уже рассказывал об основных типах описания бизнес процессов и обозначил своё отношение к самому продвинутому из них — графическому описанию. Все методологии моделирования бизнес-процессов состоят из определённых элементов и правил. Пришла пора поговорить о нотациях.
Нотация — это набор знаков и правил, которые используются для графического описания или моделирования бизнес-процессов. Проще говоря, нотация определяет, как мы обозначаем на схеме процессы, операции, события и т.д., а также по каким правилам соединяем их между собой.
Можно отметить 3 самые популярные нотации: семейство IDEF, eEPC и BPMN 2.0. Я не буду рассказывать об истории возникновения, развития и правилах использования нотаций — все это можно прочитать в Википедии. Вместо этого представляю свой взгляд на их использование сугубо с практической точки зрения.
Популярные методологии моделирования бизнес-процессов
Семейство IDEF
Ну всё-таки небольшое вступление будет. IDEF — это не одна нотация, а целое семейство. Различаются они по порядковым номерам — IDEF0, IDEF1, IDEF2 и т.д. Каждая нотация имеет свои особенности и используется для описания разных элементов бизнес-системы. Рассматривать будем семейство в целом.
Итак, IDEF. Первое что надо знать, IDEF является самой «старой» нотацией. Второе, она уже очень давно (десятилетия!) не развивается. Отсюда первый камень в огород. Семейство IDEF безнадёжно, морально, функционально устарело.
Дальше. Использовать модели бизнес процессов, выполненных в IDEF, крайне сложно. Как для изучения, так и для анализа. Ниже представлен пример схемы бизнес процесса. Судите сами.
Модель процесса в нотации IDEF3
Нотация имеет ограничения по количеству отображаемых на схеме процессов — не больше 7. Отсюда возникает необходимость подстраивать описания под эти правила. Кроме того, существуют правила, которые сильно усложняют жизнь как «писателям» бизнес процессов, так и «читателям».
В совокупности это влечёт за собой огромное количество тяжёлых для восприятия, крайне запутанных схем. Но есть и плюс — вне зависимости от того, в какой программе вы составляете модель процесса в нотации IDEF, блок-схема будет ориентирована на лист формата А4 в альбомной ориентации. То есть распечатывать такие схемы удобно. На этом плюсы закончились)
О программном обеспечении. Да, существует огромное количество ПО, поддерживающего моделирование в этой нотации. В том числе и бесплатное. Но в большинстве своём оно тоже устарело и не позволяет решать актуальные на сегодняшний день задачи. В конце концов, нарисовать модель бизнес процесса можно в любом графическом редакторе. Начиная от элементарного Paint и заканчивая профессиональными инструментами, например, Microsoft Visio. Даже от руки на листе бумаги можно создать схему.
К слову, именно из потребности в автоматизации, т.е. в переводе моделей бизнес процессов в программу, и родились современные нотации. В том числе IDEF. Именно этим обусловлена строгость соблюдения правил моделирования. Машина может понять строгий графический язык, но не в состоянии понять текстовое описание.
Резюме — если вы встали перед выбором нотации для описания и моделирования бизнес-процессов, ни в коем случае не останавливайтесь на IDEF.
Нотация eEPC
А вот это уже интересно. Само название нотации Событийная цепочка процессов (event driven process chain, «e» вначале означает extended, расширенное) говорит о том, что моделирование в данной нотации сосредоточено вокруг событий. А именно события и определяют развитие процесса.
В основе этой нотации лежит… Одна из нотаций семейства IDEF. А конкретно IDEF3. Впрочем, eEPC намного функциональнее и нагляднее.
Модель процесса в нотации eEPC
Модели, построенные в этой нотации, позволяют довольно эффективно изучать и анализировать бизнес-процессы. На одной схеме можно увидеть не только порядок выполняемых процессов, но и события, которые управляют его развитием, документы, информационные системы, ресурсы, персонал и т.д. Несмотря на то, что базовый набор знаков нотации невелик, существует большое количество возможностей для моделирования любого процесса. Логика построения весьма проста и понятна.
Безусловно, присутствуют и существенные недостатки. К примеру, невозможно отобразить процесс в виде переходящего потока работ по ролям бизнес-процесса. Иными словами, не очевидно как происходит взаимодействие между его участниками. А это серьёзный недостаток как с точки зрения восприятия схемы, так и с точки зрения анализа.
В нотации eEPC отсутствуют типы событий, что не позволяет отличить, к примеру, событие времени от входящего сообщения. Также отсутствует разделение потоков на рабочие и информационные, а это усложняет чтение диаграмм.
Практически любое программное обеспечение, если только оно не заточено под конкретную нотацию, позволяет моделировать бизнес-процессы в eEPC.
Платформа ARIS, предназначенная для комплексного управления бизнес-процессами, использует именно eEPC для моделирования процессов. Платформа позволяет задавать характеристики всех элементов в процессе, изменять их и оценивать влияние на систему, т.е. проводить полноценное моделирование.
Все это, конечно, неплохо, но, на мой взгляд, ПО имеет два существенных недостатка: высокая стоимость и ориентация на сложные, комплексные программные решения. Оба недостатка не позволяют использовать ПО в небольших компаниях и даже в крупных требует огромного количества ресурсов для интеграции и поддержания работоспособности.
Резюме — нотация eEPC является не самым плохим решением для описания и моделирования бизнес процессов.
Нотация BPMN 2.0
Скажу сразу, на мой взгляд, это лучшая нотация для описания и моделирования любых бизнес процессов.
BPMN (Business Process Model and Notation) — нотация управления бизнес-процессами. Вот так скромно и без прикрас назвал своё детище Институт управления бизнес процессами (BPI). Да, созданием и развитием BPMN занимается целый институт. Одно это говорит о том, что нотация является результатом серьёзной, научно обоснованной работы. Более того, работа эта происходит постоянно, а в настоящее время нет ничего важнее постоянного развития инструментов управления. Впрочем, перейдём к сути.
BPMN — самая удобная, гибкая, наглядная, функциональная и вместе с тем простая нотация.
Существенным отличием является наличие понятия «дорожка». Дорожка — это область в модели процесса, которая отображает все, что выполняет конкретный человек в данном процессе. Естественно, если процесс затрагивает разных людей, то посредством дорожек отображается их взаимодействие. И это крайне важно.
Модель процесса в нотации BPMN
Дело в том, что наибольшие проблемы в бизнес-процессах лежат на стыках работ разных исполнителей (ролей, процессов). Модели в нотации BPMN позволяют увидеть и проанализировать все взаимодействия.
Набор знаков в BPMN достаточен для описания любого процесса и обозначения любых типов событий. Кстати, только в этой нотации существует разделение событий на события начала, окончания и промежуточные события. Почему это важно? Потому что процесс всегда начинается и заканчивается событием. Или событиями. Данное разделение позволяет сразу понять, с чего начинается и чем заканчивается процесс.
Существует разделение потоков на рабочие, информационные и ассоциации. Это позволяет разделять поток работ, потоки обмена информацией и потоки, определяющие принадлежность, к примеру, документов к тому или иному процессу. В свою очередь, данное разделение облегчает чтение и анализ моделей бизнес процессов.
Помимо стандартных наборов значков, BPMN позволяет создавать свои, что позволяет адаптировать нотацию к любым потребностям.
Отдельно хочу отметить правила нотации. Они очень гибкие. Существует множество вариаций моделирования процесса. С одной стороны, это снижает упорядоченность и требует определить, какие правила мы будем использовать в компании до начала описания процессов. С другой стороны, это позволяет создать уникальный, учитывающий ваши особенности инструмент моделирования бизнес-процессов. На основе BPMN вы можете создать собственную нотацию без особых проблем.
Программы, ориентирующиеся на использование нотации BPMN, являются самыми активно развивающимися. Многие из них можно использовать бесплатно, при этом получать полный функциональный набор. К примеру, программа BizAgi. Это целая платформа, которая позволяет не только моделировать и анализировать, но и создавать исполняемые бизнес-процессы. Это ПО можно внедрять в компании любого типа, размера, с ориентацией на любой бюджет.
Одним из огромных плюсов данной нотации является возможность многих программ переводить модели бизнес-процессов непосредственно в программный код. Это существенно упрощает процесс разработки ПО. Поэтому многие разработчики отдают предпочтение нотации BPMN.
Есть ещё возможности связки моделей BPMN и 1С. В итоге получается эффективная система управления процессами с возможностью отслеживания онлайн. Но об этом я буду рассказывать в другой раз в обзоре программ для моделирования и управления бизнес-процессами.
Резюме — нотацию BPMN выбирает большинство профессионалов в управлении бизнес-процессами. Она наиболее современная и активно развивающаяся. Я рекомендую работать именно с ней.
На основании чего стоит выбирать нотацию? Я мог бы начать рассказывать о целях и задачах описания. Подробно рассматривать сравнительные особенности каждой нотации. Рассуждать об удобстве работы с каждой из них. Но не стану. Все намного проще.
Нотации бизнес-процессов.
Сегодня мне даже сложно представить, что я когда-то не пользовался нотациями. Я применяю их практически всюду:
Но при встрече с новым клиентом мне очень часто приходится пояснять, что такое нотации и зачем они нужны. Практически всегда поначалу графическая нотация вызывает некоторое недоумение, потом, в процессе обсуждение, приходит понимание и принятие преимуществ такого подхода. В этой статье я решил подвести своеобразный итог этих многочисленных обсуждений, и собрать все «за», «против» и «почему» воедино. Я надеюсь, что после изучения этого материала у вас не возникнет вопросов, почему нужно пользоваться нотациями, и какие из них подходят для ваших целей.
Цели моделирования
При взаимодействии заказчика с исполнителем важнейшая задача – донести до второй стороны, что именно вы хотите получить или предложить. Проблема взаимопонимания нередко становится причиной неудачных решений или многочисленных доработок.
Первая цель моделирования – наглядно и однозначно поставить задачу или пояснить решение. Графика – всегда нагляднее слов. В случае использования нотаций разночтений практически не возникает.
Графика против текста
На начальном этапе сотрудничества у меня нередко клиенты просят предоставить техническое задание, спецификацию или другой подобный текстовый документ. Как правило, я отказываюсь или сокращаю текстовую часть до необходимого минимума.
Каждый раз, когда я интересуюсь, зачем клиенту нужен такой документ, в ответ слышу «у нас так принято» или «так делают все». В ответ я поясняю, что хочу достичь взаимопонимания, а не просто предоставить какой-то документ. Мне важно, чтобы мои предложения были поняты однозначно. А поэтому, вместо больших объемов трудно читаемого текста, я предлагаю графическую бизнес-модель.
Преимущества такого подхода:
Можно возразить, что текст дает больше возможностей, ведь описать словами можно все, что угодно. Текстом можно максимально детализировать любые нюансы. Но с другой стороны, этот текст должен быть внимательно прочитан и понят. А это – дополнительное время, да и подготовка у человека должна быть достаточной, чтобы он разобрал все термины, сумел понять суть идеи, и не «заблудился» в подробностях.
В своей практике я видел технические задания, состоящие из 200 или 300 страниц. Честно говоря, я с трудом представляю, как можно в голове «связать» такой объем информации. А ведь это не художественная литература, здесь каждая страница содержит огромное количество технической информации. А ведь ее нужно не просто изучить и понять, но еще и обсудить, а иногда и «защитить» идею. Графическая нотация в этом случае явно выигрывает.
Но есть у графики и недостатки. Здесь нет возможности подробно и развернуто описать все нюансы решения. Часть процессов придется оставлять без детализации, от описания других – отказываться, так они «уводят» в сторону от основного процесса.
Какие бывают нотации
Подробно о видах нотаций я уже писал ранее в статье «Моделирование бизнеса. Основные подходы». Подробно на этом останавливаться я здесь не буду. Но напомню, что моделирование бывает:
Так, если вы нуждаетесь в разработке стратегии развития, то последовательность действий в каждом процессе вам не нужна. И тогда выбирают функциональный подход, где каждый процесс рассматривается как «черный ящик» или функция. Если необходимо оптимизировать последовательность действий, то понятно, что лучше всего подойдет процессное моделирование. Ментальный подход удобен для наглядной демонстрации идеи. Он не скован строгими рамками и правилами, не имеет какого-то языка моделирования. По сути, это просто графические наброски, которые помогут наглядно увидеть «слабые места» и нюансы решения.
В зависимости от поставленной задачи выбирают и языки моделирования – IDEF0, IDEF3, BPMN, UML, ARIS и многие другие.
Нередко мне задают вопрос, почему я не использую отечественные разработки. Дело в том, что в России графическое моделирование практически не развивалось. Существует две системы – сетевой графики «дракон». Но, к сожалению, они не столь популярны и не так хорошо документированы, как IDEF0 или BPM.
Выбор языка моделирования.
Язык графических нотаций выбирают с точки зрения выбранного подхода и особенностей применения.
Например, UML используют для работы с базами данных и алгоритмизации компьютерных информационных систем. Графические элементы этого языка отражают преимущественно объекты и управляющие элементы для взаимодействия с базами данных, а поэтому этот специализированный язык будет удобен разработчиками в этой сфере деятельности, но описать с его помощью производственный процесс не получится.
Для описания последовательности действий при выполнении каких-то работ оптимально подойдет IDEF3 или BPMN.
Для функционального моделирования я рекомендую IDEF0, он был создан именно для функционального подхода к бизнесу, поэтому здесь вы найдете те самые «черные ящики», но детализировать процессы в этой среде крайне сложно, да и нет в этом необходимости. Выбирать язык моделирования необходимо, исходя из поставленных целей.
Что касается вопроса: «А какой из языков, созданных для одинаковых целей лучше?» — я считаю, это зависит от личных предпочтений. Я не использую ARIS или Дракон, предпочитаю языки семейства IDEF0 и BPM. С моей точки зрения они удобны, и другие просто ни к чему. Другие люди работают в том же Драконе, и, думаю, смогут привести массу доводов, почему он для них оказался самым лучшим.
Впрочем, я рекомендую придерживаться IDEF00, IDEF03, BPMN. Просто потому, что они наиболее развиты и популярны. Инструменты проверены на практике, синтаксис в них развит и стандартизирован. Это снижает вероятность ошибок или отсутствия нужного инструмента. Кроме того, в случае создания исполняемых нотаций, т.е. при автоматизации процессов, намного легче будет найти разработчика, который также работает с этими инструментами.
В любом случае, нотацию нужно выбирать под задачу, а не наоборот.
В каком порядке моделировать?
Для начала вспомним бессмертную истину – «нельзя объять необъятное». Следовательно, необходимо:
Очертить границы модели.
Например, если поставленная цель – автоматизация работы отдела продаж, то ваша модель должна быть ограничена рамками работы этого подразделения. Все, что находится вне продажи, в том числе, бухгалтерские отчеты, производство или закупка товаров, может присутствовать только как входящие или исходящие «стрелки», если в этом есть необходимость.
Изучаем поставленную задачу.
Если речь идет о работе с людьми, как в примере выше, необходимо понять, что и как они делают. Для этого проводятся интервью с руководителем подразделения и его подчиненными. В других случаях список опрашиваемых может быть другим. Но он обязательно необходим, даже если в будущем функции этих людей заменит программа.
При этом важно вовремя остановиться. Так, нет никакой нужды опрашивать всех исполнителей, можно выбрать только наиболее компетентных. А поможет выбрать – руководитель подразделения, тем более, что интервью с ним должно быть первым.
Создается первый вариант графической нотации и вносятся уточнения.
Т.е. вы по итогам опросов создаете модель, после чего демонстрируете ее тем людям, у которых брали интервью. В результате обсуждения и уточнений модель корректируется. Этот этап завершается только тогда, когда все обсуждения пройдены, а сама модель утверждена заказчиком.
Текстовые пояснения.
Любая графическая модель, как я уже писал, ограничена определенными рамками и несколько абстрактна. Обойти эти рамки и донести суть модели поможет текст, где будут описаны все подробности каждого действия.
Например, в графической нотации присутствует элемент «заказ поставщику». Большей детализации графика не позволяет. В текстовом пояснении нужно подробно перечислить все поля этого заказа, другие дополнительные данные, которые будут присутствовать в документе. Такой документ-сопровождение может называться отчетом, пояснительной запиской или т.д.
Насколько важно знать сферу деятельности при моделировании?
Этот вопрос я слышу очень часто. И суть его заключается в том, надо ли быть специалистом, например, в продаже автомобилей или производстве какого-то оборудования, чтобы создать модель и оптимизировать (автоматизировать) работу.
Нет. Чтобы создать грамотную бизнес-модель нет никакой необходимости изучать все особенности сферы деятельности клиента. Моделирование описывает не особенности какой-то сферы деятельности, а трудовые процессы в коллективе.
Сфера деятельности влияет только на определенные нюансы. Но, по сути, заказ покупателю – всегда определенная последовательность действий. Отличаться будут только перечень позиций и, может быть, еще какие-то незначительные нюансы. Все необходимые сведения и уточнения вам предоставит заказчик и его сотрудники.
Помимо изучения ситуации «как есть», от вас ждут предложений «как надо». И здесь вы будете использовать собственный опыт, информацию из внешних источников (учебники, статьи, советы), а также идеи от сотрудников заказчика, которые нередко появляются в процессе обсуждения модели. В процессе таких обсуждений обязательно будут выявлены профильные нюансы, касающиеся определенной сферы деятельности или даже конкретной организации. В остальном моделирование бизнес-процессов – это описание трудовой деятельности, а потому от сферы деятельности заказчика здесь мало что зависит.
Подведем итоги.
Итак, графические нотации бизнес-процессов – удобное решение для достижения взаимопонимания между заказчиком и подрядчиком. В процессе моделирования принимают участие сотрудники и другие заинтересованные лица. При этом форма подачи информации позволяет в сжатые сроки даже неподготовленному человеку понять, что именно вы предлагаете и какие важные особенности вы могли пропустить.
Результат – однозначно утвержденная нотация, прочитать которую неправильно практически невозможно, а также текстовое описание того, что не помещается в рамки графики. После утверждения такого документа вероятность в итоге услышать «я это представлял себе иначе» от заказчика или «я не так вас понял» от исполнителя стремится к нулю. Изучайте моделирование, оно того стоит.