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

Автор работы: Пользователь скрыл имя, 09 Января 2013 в 11:09, курсовая работа

Краткое описание

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

Содержание

Введение 3
1. Термины, определения и сокращения 10
1.1. Термины и определения 10
1.2. Сокращения 12
2. Моделирование бизнес-процессов 13
2.1. Понятие бизнес-процесса 13
2.2. Последовательность разработки модели бизнес-процессов 14
2.3. Подходы к выбору конфигурации модели бизнес-процессов 15
2.4. Структура модели бизнес-процессов 17
2.5. Нотация IDEF0 19
2.6. Нотации Процесс и Процедура 26
Заключение 35
Библиография 40

Вложенные файлы: 1 файл

metodika_proektirovanie_sistemy_upravleniya.doc

— 1.55 Мб (Скачать файл)

 

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

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

    1. Нотация IDEF0

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

Контекстная диаграмма. Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу. Пример диаграммы A-0 (Рис.8):

Рис.8. Диаграмма A-0 нотации IDEF0

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

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

Выделение 4 видов  стрелок. Выделяются следующие виды стрелок: Вход, Выход, Механизм, Управление. Входы преобразуются или расходуются процессом, чтобы создать то, что появится на его выходе. Управления определяют условия, необходимые процессу, чтобы произвести правильный выход. Выходы – данные или материальные объекты, произведенные процессом. Механизмы идентифицируют средства, поддерживающие выполнение процесса. Таким образом, блок IDEF0 показывает преобразование входа в выход с помощью механизмов с учетом управляющих воздействий.

Используемые графические  символы

Название

Графический символ

Описание

Процесс

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

Стрелка

Стрелки обозначают входящие и исходящие из процесса объекты (данные).

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

Туннелированная стрелка

 

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

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

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

Внешняя ссылка

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

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

Междиаграммная ссылка

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

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

Процесс-ссылка

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

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

Параметры типового процесса заполняются непосредственно в  свойствах типового процесса.

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

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

Сноска

Выносной элемент, предназначенный  для нанесения комментариев.

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

Текст

Комментарий без сноски.

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


 

Информация о способах добавления элементов на диаграмму  содержится в Руководстве пользователя (глава 4 «Создание модели бизнес-процессов в Business Studio»).

Пример диаграммы процесса в нотации IDEF0 (Рис.9):

Рис.9. Диаграмма процесса нотации IDEF0

Подробнее с правилами создания диаграммы нотации IDEF0 можно познакомиться в источниках [1], [2].

    1. Нотации Процесс и Процедура

Нотации Процесс (Basic Flowchart в Microsoft Visio) и Процедура (Cross Functional Flowchart в Microsoft Visio) используются для представления алгоритма (сценария) выполнения процесса и позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса. Нотации поддерживают декомпозицию на подпроцессы, также как и нотация IDEF0.

Различие между нотациями Процесс и Процедура состоит в том, что дополнительно к графическим элементам, применяемым в нотации Процесс, в нотации Процедура используются дорожки (Swim Lanes), обозначающие организационные единицы – исполнителей действий процесса. Это позволяет повысить наглядность диаграммы.

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

 

Используемые  графические символы

Название

Графический символ

Описание

Действие

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

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

Решение

Рис.10

Рис.11

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

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

Возможны следующие  виды изображения стрелок: Рис.10,  Рис.11.

Блок «Решение» аналогичен элементу «Исключающее ИЛИ» (XOR) в других нотациях моделирования.

Связь предшествования

 

Рис.12

Рис.13

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

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

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

Поток объектов

 

Рис.14

Рис.15

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

Стрелки «Поток объектов»  обозначаются стрелкой с двумя треугольниками.

Если обозначение источника  Объекта(ов) неважно, то такой Объект показывается стрелкой с туннелированным  началом (Рис.14).

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

Дорожки

(диаграмма Процедура)

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

Событие

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

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

Концом процесса/процедуры  считается событие, в которое  только входят стрелки передачи управления.

Этап

Элемент «Этап» предназначен для определения этапа в рамках процесса на диаграмме, созданной в  нотации «Процедура».


 

Информация о способах добавления элементов на диаграмму содержится в Руководстве пользователя (глава 4 «Создание модели бизнес-процессов в Business Studio»).

Пример диаграммы в нотации  Процесс приведен на рисунке (Рис.16), а диаграммы в нотации Процедура – на рисунке (Рис.17).

Рис.16. Пример диаграммы в нотации Процесс

 

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

  1. Диаграмма функции EPC должна начинаться как минимум одним стартовым событием (стартовое событие может следовать за интерфейсом процесса) и завершаться как минимум одним конечным событием (конечное событие может предшествовать интерфейсу процесса).
  2. События и функции по ходу выполнения процесса должны чередоваться. Решения о дальнейшем ходе выполнения процесса принимаются функциями.
  3. Рекомендуемое количество функций на диаграмме – не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.
  4. События и функции должны содержать строго по одной входящей и одной исходящей связи, отражающей ход выполнения процесса.
  5. События и операторы, окружавшие функцию на вышележащей диаграмме (Рис.33), должны быть начальными/результирующими событиями и операторами на диаграмме декомпозиции функции (Рис.34).

Рис.33. Диаграмма процесса, на которой встречается Функция 1

Рис.34. Диаграмма декомпозиции Функции 1

  1. На диаграмме не должны присутствовать объекты без единой связи.
  2. Каждый оператор слияния должен обладать хотя бы двумя входящими связями и только одной исходящей, оператор ветвления – только одной входящей связью и хотя бы двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями.
  3. Если оператор обладает входящей связью от элемента «событие», то он должен обладать исходящей связью к элементу «функция» и наоборот.
  4. За одиночным событием не должны следовать операторы «OR (ИЛИ)» или «XOR (Исключающее ИЛИ)».
  5. Операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно.
  6. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда оператор ветвления «И», оператор объединения – «ИЛИ».

Примеры допустимых ситуаций (Рис.35, Рис.36, Рис.37, Рис.38):

Рис.35

Рис.36

Рис.37

Рис.38

Пример недопустимой ситуации (Рис.39):

Рис.39

Пример диаграммы процесса в нотации EPC приведен на Рис.40:

Рис.40. Пример диаграммы процесса в нотации EPC

Заключение

 

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

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

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

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

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

  1. Недорогими. Особенно это актуально для средних и небольших организаций, которые не могут себе позволить внедрять дорогостоящие решения.
  2. Простыми и понятными рядовым сотрудникам организации.
  3. Практически направленными, иметь достаточно «быстрые», и в то же время, долгосрочные результаты.
  4. Учитывали специфику менеджмента российских компаний.
  5. Содержали примеры и типовые решения.

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

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