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

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

VAD (v alue added chain diagram)

Нотация VAD, предложенная Майклом Портером (Michael Porter) в его работах по корпоративной стратегии, концентрируется на моделировании бизнес-процессов, «создающих ценность» в виде услуг или продукции для потребителя. Модель бизнес-процесса, построенная в нотации VAD, дает общий, не детализированный взгляд на бизнес-процессы.

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

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

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

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

Модель нотации VAD можно нарисовать во множестве инструментов, например, в MS Visio, и многих других инструментах моделирования бизнес-процессов.

Моделирование бизнес-процессов – EPC (event-driven process chain)

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

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

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

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

Существует множество вариантов нотации EPC, в формате столбцов, строк, а также с разными перечнями используемых объектов, однако все эти варианты доступны только в инструментарии ARIS, тогда как в остальных инструментах, например, MS Visio или Business Studio доступно моделирование бизнес-процессов EPC лишь в классическом формате.

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

Моделирование бизнес — процессов – BPMN (Business Process Model and Notation 2.0)

Нотация BPMN создана консорциумом Object Management Group (OMG) и предназначена для моделирования бизнес-процессов с целью их последующей автоматизации. Нотация BPMN используется для детального моделирования бизнес-процесса, а количество объектов в данной нотации превышает 100, что позволяет описать все нюансы поведения бизнес-процессов для того, чтобы информационная система могла преобразовать созданную модель в исполняемый код.

Открытость нотации BPMN и поддержка большинством средств моделирования и автоматизации бизнес-процессов сделали данную нотацию лидером в моделировании бизнес-процессов.

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

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

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

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

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

Моделирование бизнес-процессов — Flow Charting

Название нотации Flow Charting, проще всего перевести как блок-схемы. Данная нотация изначально появилась в стандарте ANSI в 1970 году, и содержит очень простой набор символов.

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

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

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

Из недостатков Flow Charting можно выделить отсутствие типового перечня объектов и атрибутов, что является обратной стороной «свободы» данной нотации. Это позволяет моделировать один и тот же бизнес-процесс в данной нотации так, что модели будут серьёзно отличаться друг от друга.

Несмотря на то, что модели бизнес-процессов в нотации Flow Charting можно встретить достаточно часто, скорее всего она будет уходить в прошлое, уступая место более «строгим нотациям»

Моделирование бизнес — процессов – IDEF (Integrated Definition Language)

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

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

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

UML (Unified Modeling Languages )

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

Данная нотация очень похожа на EPC и BPMN, единственное отличие в отображении логических операторов и событий, и, хотя по нотации UML существует множество книг, и поддержана она множеством инструментов моделирования, используется UML Activiti Diagram в основном для системного анализа и проектирования, и лишь незначительное число компаний используют UML, чтобы моделировать бизнес-процессы

VSM (Value Stream Mapping )

Название нотации VSM можно перевести н русский язык, как картирование потока создания потребительской ценности. Оригинальное название этой нотации в корпорации Тойота, где как считается, ее и придумали — Карта потоков материалов и информации.

Нотация VSM была разработана как часть методологии бережливого производства, и использует набор специфических символов для отображения элементов затрат ресурсов и времени для анализа эффективности бизнес-процесса в проектах Lean 6Sigma. Карта потока создания ценности изображает физическое окружение и потоки материалов и продукции в производстве и используется для того, чтобы привязать к процессу затраты ресурсов и времени, и таким образом дать представление о производительности

Задача данной нотации вовлечь в анализ бизнес-процесса его участников, для того, чтобы стимулировать их к самостоятельному поиску возможностей оптимизации. Как правило модели VSM рисуются в проектах на Flip Chart и не требуют серьёзных средств моделирования бизнес-процессов, ведь на ее основании принимаются решения, а сама модель не становится основой ни для регламента, ни для ИТ-решения.

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

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

SIPOC

Аббревиатура SIPOC означает: Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (потребитель). Это шаблон документирования процессов, принятый в методологии Шесть сигм, фактически это даже не нотация модели, а формат таблицы, который позволяет описать бизнес-процесс на верхнем уровне. Модель SIPOC наиболее эффективно применять при определении границ бизнес-процесса, взаимодействующих сторон и входов/выходов процесса.

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

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

Моделирование бизнес-процессов – выводы

Итак, я рассмотрел некоторые нотации моделирования бизнес-процессов, которые можно встретить на российском рынке (более подробно они описаны в главе BPM CBOK , посвященной моделированию бизнес-процессов). Какую из нотаций выбрать для использования – это вопрос открытый, например, для моделирования бизнес-процессов организации на верхнем уровне я использую нотацию VAD, для первичного моделирования бизнес-процесса, выбранного для оптимизации, проще использовать SIPOC или VAD. Для создания детальных моделей бизнес-процессов – упрощённый BPMN для моделирования кросс-функционального взаимодействия или EPC для детального моделирования с целью формализовать информационный поток и множество объектов, связанных с бизнес-процессом. Ну а если необходимо автоматизировать бизнес-процесс в BPMS системе, то тут уже не обойтись без нотации BPMN.

14.02.2017, Вт, 16:00, Мск , Текст: Андрей Коптелов

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

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

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

Текстовый формат описания бизнес-процесса

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

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

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

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

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

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

Табличный формат описания бизнес-процесса

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

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

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

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

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

Графическая модель бизнес-процесса

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

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

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

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

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

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

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

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

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

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

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

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

От моделирования к автоматизации

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

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

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

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

Что же выбрать?

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

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

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

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

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

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

При дальнейшем анализе будут рассматриваться только характеристики программ ARIS ToolSet (далее, ARIS), BP-Win – Erwin (далее, BP-Win) и ОРГ -Мастер (далее, ORG-Master). Программу Rational Rose - как в наибольшей степени ориентированную на построение чисто программных, а не организационных систем, чтобы упростить изложение мы исключим из рассмотрения, тем более что лежащая в ее основе методология UML реализована сейчас в АРИС).

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

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

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

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

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

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

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

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

Так, например, после построения модели бизнес процесса в BP-Win, с помощью ERwin строится отдельная модель данных, в которой устанавливаются связи между компонентами системы (сущностями модели данных по методологии). Затем эти модели связываются посредством механизма, по сути своей схожим с используемым в ORG-Master механизмом построения проекций (см. Приложение 1 . Компоненты моделей программно-методического комплекса ОРГ -Мастер).

С учетом этого, вторая из рассматриваемых возможностей анализа модели: анализа распределение ответственности за реализацию отдельных функций и расходование ресурсов системы , оказывается автоматически реализованной в процессе построения модели бизнес-процесса в системе ORG-Master. Действительно, проекции вида Оргзвенья – Функции и Функции - Ресурсы, задаваемые при построении моделей бизнес-процессов в ORG-Master, непосредственно показывают ответственных за тот или иной участок работы или ресурс (и позволяют проанализировать их любые комбинации). Кроме того, ORG-Master позволяет экспортировать матричные проекции в MS Excel, где на их основе формируются диаграммы организационного анализа.

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

Вопрос о загрузке исполнителей и инструментальных ресурсов в системе , а также получение оценок по основным временным параметрам моделируемой системы, может решаться на основании количественных данных о сложности (или просто продолжительности) реализуемых ими функций. Для решения этой задачи необходимо тем или иным способом ввести в систему такие данные, а также предусмотреть средства получения сводных оценок. Поддержка методологии IDEF3 (в BP-Win), ABC-методов в ARIS и BP-Win, а также средств имитационного моделирования в ARIS (и, частично, в BP-Win) предусматривает определенную обработку этих оценок. Что касается собственно исходных данных, то они задаются пользователем, который, таким образом, и несет ответственность за конечный результат.

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

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

Более адекватные результаты можно попытаться получить с помощью имитационного моделирования поведения системы. Однако, для времен задержек обслуживания приходится либо принимать весьма приблизительные предположения о законе распределения их во времени, либо проводить достаточно дорогие и трудоемкие процедуры хронометража и последующую статистическую обработку. При этом достоверность полученных результатов не будет слишком высокой, либо потребует значительных дополнительных затрат. Поэтому, представляется разумным подход, заключающегося в том, что: «стоимость затрат на моделирование для получения какой-либо информации, не должна превышать ценность (стоимость) результатов ее использования. Кроме того, всегда надо помнить о законе Парето, из которого, применительно к рассматриваемой проблеме, следует, что 20% усилий по моделированию обеспечивают 80% эффекта.

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

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

Кроме того, в семейство ОРГ -Мастер входит и программный комплекс “Тайм-Мастер”, одна из компонент которого, обеспечивающая управление процессами (workflow), позволяет накапливать статистику по ходу их выполнения, что обеспечивает получение оценок для необходимых для анализа временных параметров процессов.

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

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

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

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

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

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

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

Кроме того, должна обеспечиваться возможность создания специальных отчетных форм, для создания документов в различных функциональных областях: Технического задания на информационную систему управления предприятием, Руководства по качеству (см. например, Приложение 3) и других специальных документов по стандарту ISO9000 и т.п.

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

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

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

В BP-Win прямая возможность получения различных регламентов не оговорена.

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

В части документации для разработки информационной системы наиболее традиционные возможности предусматривает среда BP-Win/ERwin, которая, собственно, для этого и создавалась.

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

Возможности ORG-Master позволяют полностью представить структуры данных, необходимые для организации информационной поддержки моделируемых бизнес-процессов с помощью собственных универсальных средств – классификаторов и проекций. Отсутствуют формализмы типа ER-диаграмм, хотя в последних версиях возможна визуализация в стандарте DFD. Кроме того, появилась возможность отражать на IDEF0-диаграммах взаимодействие между функциональными блоками не только с помощью непосредственной передачи документов и файлов, но и через разделяемые базы данных!

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

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

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

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

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

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

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

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

Функции управления проектом создания баз данных и программных средств являются специфическими именно для разработки программных продуктов. В такой форме они реализованы в BP-Win. Управление проектами в семействе ОРГ -Мастер полностью поддерживает программный комплекс «Тайм-Мастер». (Хотя, строго говоря, данные функции не являются обязательными для рассматриваемого класса инструментальных средств).

Интеграция с другими программными продуктами предполагает расширение области применения рассматриваемого средства и может проводиться как в рамках разработки семейства совместимых программных средств (по типу фирмы Platinum Technologies) или с программными средствами других разработчиков (third party software).

Интеграция с программными продуктами “третьих сторон” выполняется с одной из следующих целей:

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

С точки зрения функциональной направленности можно рассматривать интеграцию с:

• CASE средствами,
• ERP системами,
• прикладными программами.

ARIS имеет интерфейсы с некоторыми CASE-средствами, а также является средством создания моделей для непосредственной настройки таких систем управления предприятиями, прежде всего SAP R/3. Как отмечалось выше, система опирается на собственную нотацию для представления бизнес-процессов, поэтому в ней используются встроенные средства имитационного моделирования и инструментом стоимостного анализа, результаты которых, впрочем, могут экспортироваться в форматы MS Excel.

Системы ORG-Master и BP-Win поддерживают систему обозначений IDEF0 для описания представляемых бизнес-процессов. В принципе, это является некоторым связующим звеном как между этими средствами, так и для связи с другими программными продуктами, использующими эту методологию. Однако, не рассматривая здесь вопросы «возраста» нотации IDEF0, следует указать, что внутреннее представление данных в каждой системе свое, а стандартный интерфейс по типу “сокетов” или классов для системы IDEF0 не оговорен. Вместе с тем, существует стандартизованный формат файлов для представления IDEF диаграмм. Поэтому, хотя описания, сделанные с его помощью и не слишком удобны как для человека, так и для ЭВМ, использовать их в качестве средства обмена моделями возможно при наличии соответствующих конвертеров данного формата. Такой конвертер предусматривается в следующих версиях ORG-Master.

BP-Win поддерживает методологии IDEF0 , DFD и IDEF3 и интегрируется со следующими программными продуктами (в основном, того же производителя):

• инструментом моделирования данных ERwin (Platinum Technology),
• системой управления и хранения проектов ModelMart (Platinum Technology),
• специализированным генератором отчетов по модели RPTwin (Platinum Technology),
• системой имитационного моделирования BPSimulator (System Modeling Corporation),
• инструментом стоимостного анализа EasyABC (ABC Technologies).

(*Platinum Technology – с 1999 г. вошла в Computer Associates)

ORG-Master изначально позиционируется как система организационного класса, ориентированная на решение задач моделирования и проектирования бизнес процессов и структур и поддержки принятия организационных решений. В нем предусмотрена возможность интеграции с собственными пакетами разработчика («BIG-SPB Software»), ориентированными на решение различных функциональных задач. В системе ORG-Master, при необходимости, автоматически создаются простые исполнительные информационные системы в среде MS Office:

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

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

Возможно (и было опробовано в проектах) сопряжение по данным через файлы обмена в рамках построения интегрированных информационных систем с исполнительными и аналитическими программами фирм-партнеров: 1С, АиТ:Софт, Инталев, Комтех+ , ИНЭКи др., а также с комплексными системами управления ресурсами предприятия (например, IPS-производство).

В новой версии также предусматриваются механизмы экспорта описаний бизнес-процессов в программный комплекс «Тайм-Мастер», сочетающий свойства систем типа Project Management, WorkFlow и Personal Information System и построенную на технологиях Internet/Intranet.

Резюме по разделу:

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

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

Однако в ходе обсуждения функциональных возможностей подчеркивалось, что непосредственно для решения задач бизнес инжиниринга, отдельные группы функциональных возможностей имеют различное значение. Этот факт отражен коэффициентами, записанными в графе “Bес”, Таблицы 2. С учетом этого фактора видно, что общая оценка комплекса ORG-Master немного превосходит ARIS.

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

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

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

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

1. ARIS Express - инструмент для моделирования бизнес-процессов, достаточно простой в установке и использовании, так что его могут применять и начинающие пользователи, и студенты вузов. Данный продукт прнадлежит к семейству средств моделирования ARIS (ARchitecture of Integrated Information Systems) компании IDS Scheer (в настоящее время являющейся частью фирмы Software AG), широко представленных на российском рынке, локализованных еще несколько лет назад и даже обеспеченных русскоязычной технической поддержкой. Семейство продуктов ARIS (ARchitecture of Integrated Information Systems), которые производит компания IDS Scheer, включает не только инструменты моделирования бизнес-процессов и публикации моделей, но и интегрирующиеся между собой средства разработки системы сбалансированных показателей, оценки и оптимизации стоимости бизнес-процессов, их имитационного моделирования, инструменты, упрощающие внедрение ERP-систем, проектирование распределенных приложений и ИТ-инфраструктуры, а также инструменты контроля за выполнением бизнес-процессов. Ведущие аналитические компании Gartner Group и Forrester Research относят компанию IDS Scheer к лидерам мирового рынка средств моделирования и анализа бизнес-процессов.

2. Bizagi Process Modeler - бесплатное программное обеспечение для создания диаграмм процессов и документации в нотации стандарта BPMN.

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

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

4. AllFusion Process Modeler - Позволяет проводить описание, анализ и моделирование модели данных — построитель мета-моделей данных. Занимает одно из лидирующих мест в своём сегменте рынка.
Включает три стандартные методологии: IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ).

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

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

6. ELMA - Российская разработка. Система управления бизнес-процессами основана на простой идее: идет построение модели бизнес-процессов вашей компании с помощью наглядных диаграмм (нотация BPMN), загружаете эти описания в компьютерную систему ELMA, и программа позволяет отследить исполнение процессов в реальной практике работы предприятия. Есть бесплатная версия.
Помимо управления последовательными задачами, которые выгодно автоматизировать, есть модуль управления проектами. Существующая система контроля (в том числе через модуль управления KPI) и отчетов создает оптимальный условия для работы в команде, в том числе удаленно (особо ценно для филиалов).
Электронный документооборот связан со всеми модулями системы и обеспечивает хранение, классификацию документов. Это значительно экономит время и сводит концепцию «незаменимого работника» к минимуму.
Учет клиентов и прав доступа решен в модуле CRM: появилась функция интеграции с call центрами. Для рядового пользователя ELMA может быть полезна как альтернатива внутрикорпоративной почте и инструмент управления задачами.

7. Fox Manager Бизнес Процессы Бесплатная. Программа для построения и анализа бизнес процессов, а также генерации отчётов по процессной модели предприятия. Программа позволяет построить единую цельную процессную модель предприятия. Используемая нотация близка к Basic Flow Chart, которая многим хорошо знакома своей простотой построения бизнес процессов. Программа автоматически строит процессы верхнего уровня, отображая взаимодействия категорий и бизнес процессов в виде наглядной диаграммы. Аналитические функции программы позволяют вовремя заметить и устранить ошибки, допущенные при построении построенной процессной модели, а именно выделить процессы, за которые никто не отвечает, найти ссылки на несуществующие документы, должности, поставщиков или бизнес процессы.

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

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

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

Инструменты бизнес-моделирования и их эволюция

Для создания бизнес-моделей используются средства проектирования информационных систем и соответствующие им языки описания (самый известный среди них язык UML - Unified Modeling Language). C помощью таких языков строятся графические модели и диаграммы, демонстрирующие структуру бизнес-процессов организации, организацию взаимодействия между людьми и необходимые изменения для улучшения показателей организации в целом. Инструменты бизнес-моделирования находятся в процессе постоянного развития. Изначально с помощью таких инструментов можно было описывать лишь бизнес-функции (работы) компании и движение данных в процессе их выполнения. При этом если одна и та же бизнес-функция использовалась при выполнении различных видов работ, то было трудно понять, имеется ли в виду та же самая бизнес-функция или уже другая. Отсутствие возможности в явном виде определить иерархию бизнес-процессов (например, «цепочка создания ценности», «бизнес-процесс», «подпроцесс», «работа», «функция») создавало проблемы при использовании таких описаний. Сами же описания представляли собой просто набор картинок. Позднее стали появляться средства, позволяющие описывать организацию не только со стороны бизнес-функций, но и с других сторон. Так, появилась возможность создания отдельных диаграмм, отражающих организационную структуру компании, потоки данных в организации, последовательность выполнения бизнес-функций, составляющих единый бизнес-процесс, с возможностью использования символов логики и др. Из-за непрерывно возрастающих требований к инструментам бизнес-моделирования стало появляться все больше и больше диаграмм для описания различных аспектов деятельности организации, из-за чего создание модели все более усложнялось. В связи с этим следующий важный этап развития средств бизнес-моделирования связан с идеей использования единого репозитория (хранилища) объектов и идеей возможного повторного использования объектов на различных диаграммах. Какой бы инструмент не был выбран, требуется обеспечение взаимодействия локальных информационных систем между собой. На сегодняшний день самым современным и одновременно общепринятым стандартом для организации управления бизнес-процессами является BPEL (Business Process Execution Language). На базе этого продукта можно создать единую интеграционную платформу для всех используемых приложений. После моделирования процессов в одном из инструментов моделирования применяются специальные трансляторы, чтобы привести модель к стандарту BPEL.

Примеры бизнес-моделирования и его результатов

• Снижение издержек. Бизнес-модель даст представление о том где можно избежать лишних затрат и как оптимизировать использование ресурсов. На основе бизнес-модели проводится функционально-стоимостной анализ для расчёта себестоимости продукта или услуги и строится система бюджетного управления, которая позволяет контролировать расходы предпрития.
• Повышение эффективности. Возможность снизить затраты на адаптацию и обучение персонала. Регламентирующая документация на основе подготовленной бизнес-модели соответствует текущему положению дел организации, распределяют обязанности, строят иерархическую систему карьерного роста.
• Расширение сферы влияние, увеличение сети, организация филиалов. Наличие бизнес-модели позволит снизить затраты и дать возможность описать структуру обустройства новых ветвей предприятия.
• Адекватность инвестиций. С помощью бизнес-моделирования можно с достаточной степенью точности определить сумму капиталовложений, снизить риски и финансовые потери на стадии старт-апа нового проекта.
• Внедрение СЭД . Бизнес-модель предприятия стандартизирует состав документов предприятия и устанавливает маршруты движения документов.
• Автоматизация и внедрение систем класса ERP , SCM , CRM или другого ПО. На основе бизнес-модели можно сформулировать более качественные требования к системе и подобрать решение оптимальное с точки зрения затрат и функциональности.
• Сертификация системы менеджмента качества. Разработка бизнес- модели предприятия позволяет существенно сократить сроки и затраты на разработку, внедрение и сертификацию системы менеджмента качества и получить комплект необходимых документов для успешного прохождения сертификации, снизить затраты на поддержку системы управления качеством.

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

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

Решения

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