Лабораторная работа №2. «Моделирование бизнес-процессов организации»

 

Цель лабораторной работы

Освоение программного комплекса Business Studio, ознакомление с возможностями моделирования бизнес-процессов предприятия.

 

Теоретическая основа лабораторной работы

Основные элементы системы управления

Управлять – значит приводить объект управления в целевое состояние. Исходя из этого определения можно выделить основные элементы системы управления организацией. Целевое состояние объектов управления задает система целей и показателей, деятельность по приведению объектов управления в нужное состояние описывается с помощью модели бизнес-процессов, исполнители этой деятельности определяются организационной структурой (Рис.1):

Рис.1. Элементы системы управления

 

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

Исходя из состава элементов системы управления и их логической взаимосвязи последовательность проектирования системы управления «с нуля» выглядит следующим образом:

Формулирование наивысшей цели организации

Разработка стратегии

Формирование верхнего уровня системы целей и показателей

Определение объектов управления

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

Проектирование организационной структуры

Формирование регламентирующей и методической документации

Автоматизация системы управления (при необходимости)

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

 

Регламентирующая и методическая документация

Разработанные элементы системы управления необходимо зафиксировать в регламентирующей документации для обеспечения необходимого уровня формализации. Полученные документы используются как рабочая документация сотрудников и для проведения аудитов СМК.

Выделяются три основных вида регламентирующей документации (Рис.2):

Регламенты бизнес-процессов (в т. ч. регламенты процедур, используемые в Business Studio).

Положения о подразделениях

Должностные инструкции

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

Рис.2. Структура регламентирующей документации

 

Business Studio позволяет осуществлять выполнение следующих этапов по проектированию системы управления:

Формирование верхнего уровня системы целей и показателей

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

Проектирование организационной структуры

Формирование регламентирующей документации

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

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

 

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

 

Понятие бизнес-процесса

Бизнес-процесс – последовательность действий (подпроцессов), направленная на получение заданного результата, ценного для организации.

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

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

Ключевыми понятиями процессного подхода являются:

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

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

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

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

Основным вопросом, который встает перед разработчиком модели является принцип выделения бизнес-процессов. Исходя из определения, принцип выделения процессов один – это результат. При выделении бизнес-процессов необходимо следить, чтобы на одном уровне модели присутствовали одноуровневые результаты деятельности, а следовательно и процессы.

 

Последовательность разработки модели бизнес-процессов

Для того, чтобы разработать модель бизнес-процессов необходимо:

Выявить набор объектов управления

Выбрать подход к описанию бизнес-процессов

Выбрать конфигурацию модели (моделей) бизнес-процессов

Разработать модель (модели) бизнес-процессов

Заполнить параметры процессов

Выбрать и назначить процессам показатели эффективности деятельности.

Оценить время и стоимость выполнения процессов и провести их оптимизацию (при необходимости).

 

Нотация IDEF0

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

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

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

 

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

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

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

Символ	Изображение	Описание
Блок		Блок описывает процесс. Типичный блок показан на рис. 1. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте.
Стрелка		Стрелки обозначают входящие и исходящие из процесса объекты (данные). Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок-стрелка, В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока - входы. Стрелки, входящие в блок сверху - управления. Стрелки, покидающие процесс справа – выходы, т.е. данные или материальные объекты, произведенные процессом. Стрелки, подключенные к нижней стороне блока, представляют механизмы.
Туннелированная стрелка		Туннелированные стрелки означают, что данные, обозначаемые этими стрелками, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме. Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции. Стрелка, помещаемая в туннель на свободном конце означает, что выраженные ею данные отсутствуют на родительской диаграмме.
Внешняя ссылка		Внешняя ссылка – место, сущность или субъект, которые находятся за границами моделируемой системы. Используются для обозначения источника или приемника стрелки вне модели. На диаграммах Внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование Внешней ссылки.
Междиаграммная ссылка		Элемент, обозначающий другую диаграмму. Служит для обозначения перехода стрелок на диаграмму другого бизнес-процесса без показа стрелки на вышележащей диаграмме (при использовании иерархических моделей).

 

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

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

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

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

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

Символ	Изображение	Описание
Действие		Прямоугольный блок обозначает действие (функцию). Внутри блока помещается название действия. Временная последовательность выполнения действий задается расположением действий на диаграмме процесса сверху вниз (слева направо на горизонтальной диаграмме Процедуры).
Решение	Рис.9   Рис.10     Рис.11	Выбор следующего выполняемого действия в зависимости от условия. Может иметь несколько входов и ряд альтернативных выходов, один и только один из которых может быть активизирован после проверки условия. Блок «Решение» должен содержать вопрос, решение или условие. Выходящие стрелки помечаются как «Да» или «Нет», или другим способом для учета всех возможных вариантов ответов. Возможны следующие виды изображения стрелок: Рис.9, Рис.10, Рис.11 Блок «Решение» аналогично элементу «Исключающее ИЛИ» (XOR) в других нотациях моделирования.
Связь предшествования	Рис.12     Рис.13	Такие стрелки обозначают передачу управления от одного действия к другому, т.е. что предыдущее действие должно закончиться прежде, чем начинается следующее. Стрелка, запускающая выполнение действия изображается входящей в действие сверху. Стрелка, обозначающая передачу управления другому (другим) действиям изображается выходящей из действия снизу (Рис.12). Если стрелка служит только для обозначения передачи управления, то имя стрелки оставляется пустым (Рис. 1). Если кроме передачи управления из предыдущего действия в следующее действие поступает Объект(ы), то стрелка именуется и в список объектов стрелки заносится соответствующий Объект(ы) (Рис.13).
Поток объектов	Рис.14   Рис.15	Используется в случаях, когда необходимо показать, что из одного действия объекты передаются в другое, при этом первое действие не запускает выполнения второго. Стрелки «Поток объектов» обозначаются стрелкой с двумя треугольниками. Если обозначение источника Объекта(ов) не важно, то такой Объект показывается стрелкой с туннелированным началом (Рис.14). Если источником Объекта(ов) является одно из действий процедуры, то такой Объект показывается с помощью стрелки, исходящей из действия-источника и входящей в действие-потребитель, для выполнения которого необходим Объект (Рис.15). При этом Действие «Регистрация в журнале «Исходящая корреспонденция» не запускает выполнение действия «Заполнение графы «Номер накладной» в журнале «Исходящая корреспонденция»
Дорожки (диаграмма Процедура)		Дорожки предназначены для отображения организационных единиц (должности, подразделения, роли) – исполнителей действий процедуры.
Сноска		Выносной элемент, предназначенный для нанесения комментариев.
Текст		Комментарий без сноски.
Терминатор		Отображает стартовую и конечные точки процедуры. В качестве названия терминаторов можно задавать названия стартового события, приводящего к началу выполнения процесса, и конечных событий, наступлением которых заканчивается выполнения процесса. Началом процедуры считается терминатор, из которого только исходят стрелки передачи управления. Концом процедуры считается терминатор, в который только входят стрелки передачи управления.
Междиаграммная ссылка		Элемент, обозначающий другую диаграмму. Служит для обозначения перехода стрелок на диаграмму другого бизнес-процесса либо процедуры без показа стрелки на вышележащей диаграмме (при использовании иерархических моделей).

Правила моделирования для нотаций Процесс и Процедура

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

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

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

Стрелки типа Связь предшествования рекомендуется делать вертикальными (при вертикальной ориентации диаграммы).

Стрелки поток объектов (передачи объектов) рекомендуется делать выходящими и входящими в левую/правую грани действия (при вертикальной ориентации диаграммы).

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

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

Стрелки «Управления» и «Механизмы» на родительской диаграмме IDEF0 (если таковая используется) туннелируются на уровне всей процедуры, как относящиеся ко всей процедуре целиком.

Если после выполнения действия должно быть инициировано выполнение нескольких действий, которые должны выполняться параллельно, то это обозначается с помощью нескольких исходящих стрелок Связь предшествования. На Рисунке Рис.16 после завершения Действия1 начинают выполняться Действие2 и Действие3.

Рис.16. Параллельные ветви

Если действие инициирует выполнение только одного из нескольких следующих действий в зависимости от определенного условия, то это показывается с помощью блока «Решение» (Рис.17).

Рис.17. Условное выполнение действий

 

Стрелки допускается объединять согласно правилам слияния стрелок методологии функционального моделирования IDEF0 [1]. Наиболее часто возникающие частные случаи:

при присоединении одного именованного сегмента к другому (основному), основной сегмент должен содержать все объекты, принадлежащие присоединяемому сегменту. На Рис. 18 стрелка «Проект документа» содержит объект «Документ», который есть на стрелке «Исправленный документ», поэтому их слияние допускается:

 

Рис. 18 Объединение стрелок

если сегменты содержат разные наборы объектов, то их слияние не допускается. На Рис. 19 стрелка «Исправленный документ, перечень исправлений» содержит два объекта – «Документ» и «Перечень исправлений», поэтому ее присоединение к стрелке «Проект документа», которая содержит только один объект «Документ», не допускается:

Рис. 19 Объединение стрелок не допускается

 

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

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

 

 

Задание для выполнения лабораторной работы

 

1. Создать процесс «Управления сервисами» в информационной службе предприятия.

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

 

2. Внести данные в диаграмму нулевого уровня.

Блок: Процесс управления сервисами

Входы:

- Спецификации сервисов;

- Календарные графики использования сервисов.

Выходы:

- Счета к оплате бизнес-подразделениям;

- Новые сервисы.

Управление:

- Методика ССВ;

- Методики прогнозирования;

- Методики технического анализа сервисов.

 

3. Создать от процесса нулевого уровня подпроцессы 1 уровня «Процесс управления затратами», «Процесс планирования сервисов» и «Процесс управления качеством сервиса».

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

 

4. Внести на диаграммы 1 уровня данные из соответствующих таблиц.

Для процесса управления качеством сервиса создать в Навигаторе в меню Субъекты организационную структуру предприятия, внести в нее сотрудников: Бизнес-пользователь, Сотрудник ИС, Руководитель бизнес-службы, руководитель ИС.

 

5. Где необходимо, установить связи между процессами.

Для того, что сделать ссылку на другой подпроцесс, перетащите его на диаграмму и присоедините к нему стрелку.

Процесс управления затратами

 

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

 

Процесс планирования сервисов

Блок	Вход	Выход	Управление
Анализ сервисов	Спецификации сервисов Соглашения об уровне сервисов (из процесса управления качеством сервиса) Календарные графики использования сервисов	Тех. задание на разработку новых сервисов Задание на прекращение действия сервисов	Методики технического анализа сервисов
Проектирование новых сервисов	Тех. задание на разработку новых сервисов	Новые сервисы
Упразднение сервисов	Задание на прекращение действия сервисов
Аутсорсинг сервисов	Решение об аутсорсинге сервисов (из блока управления затратами) Тех. задание на разработку новых сервисов	Новые сервисы

 

Процесс управления качеством сервиса

Блок (тип)	Исполнитель	Вход	Выход
Бизнес-цель (терминатор)	Бизнес-пользователь		Требования к функционалу сервиса Требования к уровню сервиса
Формирование требований к сервису (действие)	Бизнес-пользователь	Требования к функционалу сервиса Требования к уровню сервиса Необходимо изменить требования Сервис не выгоден бизнес-службе	Описание требований к сервису
Анализ требований (решение)	Сотрудник ИС	Описание требований к сервису Анализ «рынка» сервисов	Сервис возможен Необходимо изменить требования
Анализ функционала сервиса (действие)	Сотрудник ИС	Сервис возможен	Спецификация сервиса Сервис не выгоден
Расчет стоимости сервиса (действие)	Сотрудник ИС	Спецификация сервиса	Соглашение об уровне сервиса
Утверждение соглашения об уровне сервиса в ИС (решение)	Руководитель ИС	Соглашение об уровне сервиса	Соглашение об уровне сервиса, утвержденное ИС Сервис не выгоден ИС
Утверждение соглашения об уровне сервиса в бизнес-службе (решение)	Руководитель бизнес-службы	Соглашение об уровне сервиса, утвержденное ИС	Утвержденное соглашение об уровне сервиса Сервис не выгоден бизнес-службе Соглашения об уровне сервисов (поток данных, выход диаграммы)
Реализованный сервис (терминатор)	Бизнес-пользователь	Утвержденное соглашение об уровне сервиса