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

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

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

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

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

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

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

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



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



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



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

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



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



В заключении хочу отметить, что для успешного полного описания бизнес-процесса необходимо знать не только правила моделирования, но перед началом описания необходимо узнать:
  • Кто
  • какое задание выполняет
  • когда
  • с помощью каких инструментов
  • и каких данных (какие документы поступают на вход, какие на выходе)
  • кто отвечает за успех или неудачу (владелец процесса)
  • как измерить успех или неудачу (ключевые показатели результативности)
Метки:
Поделиться публикацией
Комментарии 26
  • 0
    Какие еще нотации описания бизнес процессов стоит использовать? И какие из них наиболее используются в бизнесе?
    • 0
      ARIS, в который eEPC входит.
      Например, в системе SAP ERP он считает стандартом.

      Еще многие рекомендуют IDEF 0.
      • 0
        BPMN EPC и IDEF — надо их все знать. Используются в разных случаях. EPC и BPMN в кейс-средствах, IDEF обычно для крупноблочных схем.
        UML, кстати, не нотация, а стандарт, он дофига для чего может быть использован, но в бизнесе наверное реже чем в IT.
      • +3
        Для начала можно описывать бизнес-процессы в неформальном текстовом виде. Такие описания трудны для быстрого просмотра и не подходят для оптимизации бизнес-процессов, но с другой стороны во многих российских компаниях это зачастую является единственной привычной и используемой на практике формой.
        Я бы выделила следующие нотации описания бизнес-процессов:
        1) SADT (Structured Analysis and Design Technique) –декомпозиции системы на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. В SADT существуют свои методологии, самая популярная из которых IDEF, которое состоит из IDEF0 (описание процесса в виде иерархической системы взаимосвязанных функций), IDEF (моделирование информационных потоков внутри системы), IDEF3 (методология документирования технологических процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях). SADT я не использую, он не предназначен для моделирования сквозных процессов и сейчас считается плохим тоном из-за того, что уже морально устарел. При увеличении количества уровней представления, анализ и модификация моделей становится сложными.
        2) Нотация EPC используется для представления алгоритма выполнения процесса (нотация класса workflow). Эта самая распространенная сейчас нотация, так как интуитивно понятна всем.
        3) Описание бизнес-процессов в UML основывается на диаграммах деятельности и последовательностей. Наибольшей трудностью, возникающей со всеми частичными моделями UML, является выбор необходимой степени точности и глубины описания. UML построен на основных принципах повторного использования и необходимой абстракции. Для создания прикладных систем эти принципы достаточно полезны. Для лица, ответственного за процесс и интересующегося развитием бизнеса, или для участников процесса, данные аспекты малоинтересны.
        4) BPMN ориентирована как на технических специалистов, так и на бизнес пользователей. Для этого язык использует базовый набор интуитивно понятных элементов. Важно, что спецификация BPMN определяет как диаграммы, описывающие бизнес процесс, могут быть трансформированы в исполняемые модели на языке BPEL.
        В итоге я бы дала такой совет: если Вам нужно просто описать бизнес-процесс, то используйте EPC, если потом вы собираетесь его трансформировать в BPEL — используйте BPMN.
        • 0
          Скажите, в арисе есть возможность построений процессов в нотации workflow?
          • 0
            workflow — это не нотация, так называют бизнес-процесс (в дословном переводе с английского означает поток работ /операций). Для того чтобы описать процессы для их последующей автоматизации используют различные нотации.
        • 0
          Вам удобно проектировать вертикально? Ведь, это ж не практично. eEPC помойму тем и удобна, что «в строки» складываь различные процессы и подпроцессы. Кстати, ARIS Express обладает этой нотацией в очень удобном виде, бесплатен.
          А по вопросу удоства — конкретно БИЗНЕС процессы, eEPC побеждает всё. А если нужно положить бизнес процессы на процессы системы — BPMN нет равных (Bizagi Modeler — лучший и бесплатный)
          • 0
            Да, вы правы, иногда я использую eEPC в виде столбцов или строк, так называемый column display или row display, но это неклассическое представление, а зачастую вся формальная документация требует классического вида диаграммы. Что касается ARIS Express — я поигралась с ним дома, он подойдет для простеньких процессов.
            • 0
              А что Вы называете классическим представлением? А так же интересно, почему для «простеньких»? Насколько мне известно там есть все существующие фигуры стенсила eEPC. Мне довелось попробывать корпоративный пакет ARIS, единственным плюсом могу отметить подпроцессы. Удобно складываются «плюсом-минусом». Ну и так же навигация на процесс по клику. Какой инструмент Вы используете для этой нотации?
              • 0
                Я использую ARIS Toolset 6-ой версии. На данный момент существует несколько актуальных продуктов из семейства ARIS для моделирования бизнес-процессов (Aris Disign Platform): ARIS Business Architect, ARIS Business Designer, ARIS Express (бесплатное ПО, о котором Вы говорите).
                На Процессном форуме 2011 года Software AG анонсировала следующее: ARIS Business Designer используется для моделирования моделей и создания отчетов по шаблонам. ARIS Business Architect может тоже самое, что и Aris Business Designer + управление пользователями, правами доступа, создание своих отчетов, фильтров, шаблонов.
                ARIS Express — это усеченная версия, которая создана для студентов и новичков (тоже самое, что и Visio по моему мнению). Основной недостаток ARIS Express — отсутствие централизованного хранилища моделей (они в файлах хранятся), нет многопользовательской поддержки, нет повторного использования объектов (все объекты моделей заново создавать нужно), нет связи с Aris Publisher, нет локализации. Ну и последнее, что останавливает — это цвета заливки объектов, какие-то они сказочные))
          • 0
            Если кому-то эта тема интересна, то вот: Соглашение по моделированию, которое я разработал и использовал для решения большого круга задач. Документ очень качественный и интересный. Хотел написать отдельный пост по этой теме, но никак не успеваю (
            • 0
              отличный документ! спасибо!
              • 0
                Можете ещё раз скинуть ссылку на документ? А то 404 от дропбокса.
                • 0
                  а можно снова ссылку? :))
                  • 0
                    Если кому-нибудь еще нужно будет — просите — отправлю в личку.
                  • 0
                    Может быть глупый вопрос, но у нас в компании используется просто Visio для описания бизнес-процессов. Особых нареканий от людей, которые этим занимаются, я не слышал. Зачем использовать такие сложные инструменты?
                    • 0
                      Визио, до 2010 версии «не подсказывает» следующие фигуры и по-прежнему заставляет мануально вытаскивать стрелку и потом соединять оба конца. На мой взгляд это основной минус (огромная трата времени на нужные действия)
                      • 0
                        извиняюсь, «не» нужные.
                      • +2
                        Я думаю, что существует принципиальное отличие Aris от Visio. Во-первых, многократное использование объектов за счет репозитория. Это как раз экономит много времени, потому что Вы можете каскадно изменять объекты, и эти изменения будут учтены во всех Ваших моделях. Многопользовательский доступ позволяет другим пользователям использовать Ваши объекты, то есть соблюдается целостность на уровне всех бизнес-процессов компании.
                        Во-вторых, Aris — это не в первую очередь не инструмент моделирования, а методология, поэтому все модели связаны между собой и представляют описание архитектуры всего предприятия, не только бизнес-процессов.
                        • 0
                          Помимо этого, в ARIS есть типы объектов — процессы, исполнители, документы, средства связи, компьютерная техника, местоположение и т.п., благодаря которым можно собирать аналитику. Самые простые варианты:
                          • — в каких процессах участвует то или иное лицо;
                          • — в каких процессах участвуют те или иные документы/объекты;
                          • — и множество других.

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

                          Ну и конечно же, в ARIS, в отличии от Visio, нативно есть декомпозиция процессов. Причём, что отличает ARIS от ряда других средств моделирования, он поддерживает множественные декомпозиции, таким образом обеспечивая «многомерность» модели.
                          • +1
                            Если я правильно понимаю, декомпозиция позволяет внести дополнительную детализацию одного составного процесса. Получается, что это еще одна модель в модели. В том же визио можно содать просто еще одну дополнительную модель. Получается, что отличие просто в том, что все модели четко взаимосвязаны друг с другом?
                            • 0
                              Почти так. Декомпозиция процесса позволяет развернуть (показать внутренности) процесса на отдельной диаграмме. А модель — это система диаграмм.

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

                              Визио хорош, если нужно быстренько набросать картинку. Но если стоит задача описать описать большой бизнес-процесс и потом производить анализ описанной деятельности, то тут удобнее пользоваться специализированными средствами такими как, например, ARIS.
                        • 0
                          Visio это не стандарт и не нотация, а просто редактор. Текст можно набирать в ворде, можно в фотошопе, а можно в латексе — разные возможности :) Так же и визио vs специализированные системы.
                        • 0
                          >eEPC (Extended event driven process chain), которая принята стандартом де-факто для описания процедур и регламентов после обследования деятельности организации

                          Кем принята?

                          Как описание процедур и регламентов эта нотация неудобна. EPC как и другие строгие нотации больше подходит для описания IT инфраструктуры, где человекопонятность стоит не на первом месте.
                          • 0
                            сколько людей, столько и мнений. Я не буду с вами спорить. В моей практике я никогда не использовала EPC для описания IT инфраструктуры, для этого есть специальная нотация под названием IT infrastructure. Но вообще мне кажется в данном случае удобнее использовать UML.
                            У меня к вас встречный вопрос- что вы предлагаете использовать для описания workflow вместо EPC? И для кого неудобна? Для программистов наверно неудобна (нет технической детализации), для заказчиков — то, что надо.
                          • 0
                            Спасибо — очень полезно об этом помнить. Данная ошибка характерна также и для UML ACTIVITY (игнорирование ромбов) и для BPMN. Часто тестовые задачи типа «найти ошибки в схеме процесса» на собеседованиях и экзаменах используют именно это.
                            Может быть вам доработать статью — привести еще и эти примеры.

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