Перед вами стоит задача описать бизнес процессы компании и построить модель работы организации. Начинать нужно сверху — описать окружение бизнес процессов компании, их информационные и материальные потоки, бизнес процессы верхнего уровня, а далее детализировать каждый процесс и при необходимости все его функции.
Полученная модель бизнес процесса называется иерархической моделью, а построение такой модели базируется на принципе Декомпозиции.
Принцип декомпозиции
Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Основные модели процессов верхнего уровня. Этапы построения.
Начать стоит с контекстной диаграммы, на которой вся организация будет представлена в виде одного блока и для нее будет показано ее окружение и взаимодействие с внешними объектами. Цель контекстной диаграммы — описать окружение, предметную область и установить границы бизнес процесса.
Далее можно построить Дерево бизнес процессов, в котором процессы классифицируются на: основные, обеспечивающие и управленческие. Основной задачей данной классификации является облегчение работы по выделению процессов, снижение вероятности пропуска важных процессов, а также наглядное представление выделенных бизнес-процессов, разбитых на небольшие группы.
Как альтернатива дереву бизнес процессов или его дополнение, можно построить сеть процессов. Модель строится на основе Дерева бизнес процессов и отображает взаимодействие между процессами организации. Помимо этого сеть процессов обеспечивает проверку разработанной модели деятельности организации на целостность, правильность выделения бизнес процессов и описания их окружения. Если выход одного из бизнес процессов, например документ, нигде далее не используется, то есть не является входом для другого бизнес процесса или внешнего субъекта, то это означает следующее:
- или описанный выход бизнес-процесса является либо ошибочным, либо лишним.
- или нужно найти бизнес процесс, для которого данный выход является входом, и доработать схему окружения этого бизнес-процесса.
Далее уже детализируем выделенные бизнес процессы в виде логической последовательности функций бизнес процесса с отображением отделов, которые их выполняют, информационных и материальных потоков, которыми оперируют данные функции. Эту детализацию можно назвать детализацией верхнего уровня.
После достижения требуемой глубины декомпозиции, следует описание бизнес процессов нижнего уровня. При этом отображается четкий алгоритм выполнения функции. Для этого используются методологии описания потоков работ.
Методологии. Особенности и использование.
| Основные элементы | Особенности | Использование, плюсы и минусы | |
| DFD | Работа, Потоки, Внешние сущности, Хранилища. | Не задает последовательность работ. Отображает как бизнес процесс преобразует информационные и материальные потоки. | Построение сети бизнес процессов; Построение диаграмм потоков данных. |
| IDEF0 | Работа, Потоки (управляющие, входные,выходные, механизмы) | Прототип DFD стандарта. Отличия: Типизация потоков; Последовательность работ задается четко. | Является излишне информационно насыщенным и сложным стандартом. Целесообразнее применять для небольших локальных бизнес процессов. |
| UML- Use case | Прецедент (функция), Актор (исполнитель); Стрелки (ассоциации, обобщения, расширения, включения) | Не может быть использована для моделирования потоков данных; На диаграмме нельзя показать последовательность выполнения работ. В основе моделирования — объектно ориентированный подход. | Подходит для построения контекстной диаграммы; Используется для определения функций создаваемой системы и их отношениями между собой и пользователем. |
| ARIS | |||
Источник: www.nazametku.com
Визуальное моделирование бизнес-процессов
Очевидно, что модели, созданные с помощью BPMN , алгоритмичны, т .е. можно сконструировать некоторый вычислитель, который их будет исполнять. Это будет особенный вычислитель.
- Он работает параллельно тому, как развертывается во времени реальный бизнес-процесс (в нашем случае — покупка мебели).
- Он постоянно находится в диалоге с пользователем (в нашем случае — с продавцом-дизайнером). То есть поток управления вычислителя нуждается в данных, которые пользователь вводит по мере продвижения бизнес-процесса.
Такой вычислитель в англоязычной литературе обычно называют Workflow Engine (WE) . Он полезен по следующим причинам.
- WE может вести параллельно несколько таких бизнес-процессов во времени. Это важно, так как работа с одним клиентом может откладываться, и нужно запоминать не только данные клиента, но также и состояние, в котором она отложена, чтобы при получении соответствующего события корректно возобновить работу — открыть перед продавцом-дизайнером нужные диалоговые окна, загрузить туда нужные данные и т. д.
- При переходе на следующий шаг WE , согласно спецификации бизнес-процесса, проверяет, что все условия завершения предыдущего шага были правильно выполнены. Разумеется, WE не может исправлять орфографические ошибки в выходных документах, но проверить, что каждый из требуемых документов создан, что все его графы заполнены и т. д., он вполне может, а это уже предотвращает многочисленные ошибки в делопроизводстве (например, продавец-дизайнер не может забыть создать или отдать клиенту список товаров).
- WE интегрирует в одну среду многочисленные программные приложения и базы данных, полезные для работы сотрудников компании.
- WE автоматически может выполнять многие шаги без участия человека, в нашем случае — сохранять и удалять проект, генерировать событие от таймера (по истечении десяти дней) и т. д. Разумеется, далеко не все действия бизнес-процесса могут быть полностью автоматизированы. Например, дизайн-проект создает человек, а не WE .
- Для сложных бизнес-процессов, в которых участвуют многие сотрудники, WE берет на себя все, связанное с коммуникациями — он рассылает необходимые уведомления о начале/конце соответствующего шага, пересылает запросы на данные и сами данные в ответ и т. д. При этом участники такого бизнес-процесса могут находиться в разных частях земного шара. Становится возможной виртуальная компания, для которой неважно, где физически расположены ее отдельные подразделения, — главное, чтобы все они были связаны сетью и компьютерами, оснащенными нужным программным обеспечением.
В итоге, как показано на рис. 9.3, WE оказывается ядром мощной системы автоматизации бизнеса компании. И программа , которую он выполняет, — это спецификация бизнес-процесса.
Рис. 9.3. Схема окружения автоматизированного бизнес-процесса
Рассмотрим, как WE может выполнять фрагмент бизнес-процесса покупки мебели, изображенный на рис. 9.2. Сразу после старта наш процесс начинает деятельность под названием «Создание дизайн-проекта». Например, открывается рабочее окно графического редактора, где создается дизайн-проект (это пример полезного ПО , которое может быть интегрировано с WE ). Выход из этого редактора может осуществляться с сохранением промежуточных результатов — проект еще не готов, процесс продолжает пребывать в состоянии «Создание дизайн-проекта», а продавец -дизайнер вместе с клиентом, например, пошли пить кофе. Второй вариант выхода из редактора — дизайн-проект готов. WE предлагает продавцу-дизайнеру выбрать один из трех вариантов (в виде окошка со списком выбора):
- клиент готов заплатить;
- клиент заплатит позже;
- от клиента ожидается дополнительная информация.
Продавец -дизайнер выбирает тот ответ, который соответствует ситуации, и WE продолжает исполнять процесс.
Одними из самых распространенных WE являются ERP -системы. Кроме того, существует множество различных workflow-систем, которые умеют выполнять бизнес-процессы , определенные в той или иной формальной нотации, а также имеют различные интерфейсы — пользовательский, административный, программный (для подключения стороннего ПО ) и т. д.
Бизнес-процессы и web-сервисы
Отдельным действиям бизнес-процесса могут соответствовать определенные программные компоненты, в том числе и распределенные в сети. Тогда бизнес-процесс оказывается общим алгоритмом, связывающим их в единое целое и предоставляющим клиентам некоторый компьютеризированный сервис. Например, сервис по бронированию гостиниц через Интернет может включать в себя поиск отеля по критериям, сформулированным клиентом, по разным сайтам отелей.
С бизнес-процессами тесно связны web-сервисы . Так, язык BPMN имеет исполняемые проекции в язык BEPL , а последний описывает бизнес-процессы как набор взаимодействующих web-сервисов.
Web-сервисом, согласно, называется программная система, идентифицируемая строкой URI , чьи открытые интерфейсы и привязки определены и описаны посредством языка XML . Ее описание может быть найдено другими программными системами, которые могут взаимодействовать с ней посредством сообщений, описанных на XML и передаваемых через Интернет -протоколы. URI -строка ( Uniform Resource Identifier ) состоит из унифицированного указателя информационного ресурса — URL ( Uniform Resource Locator ) — и унифицированного имени ресурса — URN ( Uniform Resource Name ). URN — это имя, которое не ссылается на физический ресурс .
Вокруг web-сервисов существует большое количество стандартов, и в целом мировое сообщество здесь движется к созданию автоматизированных и интегрированных через Интернет бизнес-процессов, реализующих многочисленные B2B (Business to Business) связи. Однако в настоящий момент существует большое количество параллельных стандартов, крупные производители, пользуясь этой парадигмой, продвигают свои системы и платформы и т. д. Одним словом, реализация этой идеи — пока дело будущего.
Обзор BPMN
Далее будет рассмотрен известный язык визуального моделирования бизнес-процессов — BPMN (Business Process Management Notation ). Исходно он был стандартизован международным комитетом BPMI (Business Process Modeling Initiative, http://www.bpmi.org), первая версия стандарта вышла в 2004 году. Позднее этот стандарт перешел под эгиду комитета OMG и в 2006 году была выпущена первая OMG -версия этого стандарта [9.3].
Процесс с точки зрения бизнеса — это отдельная деятельность (часть бизнес-процесса), выполняемая компанией или организацией. В терминологии BPMN процесс является сложным действием, которое, в свою очередь , состоит из действий, переходов между ними и т. д. Процесс можно вызывать, приостанавливать, прерывать, также он может завершаться сам, процессы могут выполняться параллельно и обмениваться сообщениями.
Итак, процесс в BPMN может состоять из следующих конструкций:
- сущности (flows objects):
- действие (activity);
- порт (gateway);
- событие (event);
- поток исполнения (sequence flow) — переход от одного действия к другому;
- поток сообщений ( message flow ) — обмен сообщениями между разными участниками процесса;
- ассоциация (association) — опредяет переход между действиями в особенных ситуациях (например, при возникновении исключений); может использоваться для «прикрепления» комментариев, данных и пр.;
- внешние (pools);
- внутренние ( lanes );
Рассмотрим эти конструкции подробнее.
Источник: intuit.ru