Существующая практика построения систем управления включает в себя несколько подходов к организации систем управления. Наиболее известны из них системы, построенные на управлении функциями и управлении бизнес-процессами организации.
Бизнес-процесс – последовательность действий (подпроцессов), направленная на получение заданного результата, ценного для организации.
Системы управления, построенные на принципах управления функциями, представляют собой иерархическую пирамидальную структуру подразделений, сгруппированных по выполняемым функциям. Под функциональным подразделением можно понимать группу экспертов в данной функциональной области. В организациях, построенных по данному принципу, управление осуществляется на административно-командных принципах. Другим подходом построения систем управления является управление потоками работ или процессами, составляющими деятельность предприятия. Процессное подразделение включает в себя координатора – владельца процесса и исполнителей из различных функциональных областей, сгруппированных по принципу единства результата бизнес-процесса. Подобные системы часто называют «горизонтальные», подразумевая под «вертикальным» управлением иерархию функциональных подразделений и руководителей в стандартной системе управления, построенной по функциональному принципу.
Понятие бизнес-процесс лежит в основе процессного подхода к анализу и синтезу деятельности организации. Процессный подход позволяет рассматривать деятельность организации как связанную систему бизнес-процессов, каждый из которых протекает во взаимосвязи с другими бизнес-процессами или внешней средой. В настоящий момент применение процессного подхода является обязательным условием для построения Системы менеджмента качества в соответствии с требованиями стандарта ISO 9001: 2008. Практика показывает, что система управления, построенная на принципах процессного управления, является более эффективной и результативной по сравнению с равной ей по масштабу функциональной системой. Вместе с тем, разработка и внедрение такой системы – сложный процесс.
Ключевыми понятиями процессного подхода являются:
Результат бизнес-процесса – то, ради чего осуществляется бизнес-процесс, т.е. деятельность всегда рассматривается вместе с целью этой деятельности – получение на выходе некоторого результата, удовлетворяющего заданным требованиям. Результаты бизнес-процесса часто упоминаются как выходы бизнес-процесса.
Владелец бизнес-процесса – должностное лицо, несущее ответственность за получение результата процесса и обладающее полномочиями для распоряжения ресурсами, необходимыми для выполнения процесса. Часто приходится наблюдать чисто формальные результаты внедрения процессного подхода – Владелец бизнес-процесса назначается практически произвольно, ему не дают реальных полномочий, например, по распоряжению персоналом, необходимым для осуществления процесса. В этом случае говорить о какой-либо ответственности Владельца бизнес-процесса за получение результата не приходится, и само получение необходимого результата оказывается под угрозой.
Исполнители бизнес-процесса – команда специалистов из различных функциональных областей (кросс-функциональная команда), выполняющих действия процесса. Исполнители процесса в большей степени ориентированы на результат, чем исполнители отдельных функций при функциональном подходе, так как основой мотивационной схемы при процессном управлении является распределение бонусов среди членов команды только при получении конечного результата. При функциональном подходе исполнители мотивируются только за исполнение функций и не заинтересованы в получении конечного результата.
Входы бизнес-процесса – ресурсы (материальные, информационные), необходимые для выполнения и получения результата процесса, которые потребляются или преобразовываются при выполнении процесса.
Основным вопросом, который встает перед разработчиком модели является принцип выделения бизнес-процессов. Исходя из определения, принцип выделения процессов один – это результат. При выделении бизнес-процессов необходимо следить, чтобы на одном уровне модели присутствовали одноуровневые результаты деятельности, а следовательно, и процессы.
Последовательность разработки модели бизнес-процессов
Для того чтобы разработать модель бизнес-процессов необходимо:
1. Выявить набор объектов управления
2. Выбрать подход к описанию бизнес-процессов
3. Выбрать конфигурацию модели (моделей) бизнес-процессов
4. Разработать модель (модели) бизнес-процессов
5. Заполнить параметры процессов
6. Выбрать и назначить процессам показатели эффективности деятельности.
7. Оценить время и стоимость выполнения процессов и провести их оптимизацию (при необходимости).
Подходы к выбору конфигурации модели бизнес-процессов
В зависимости от фазы развития организации и состояния ее системы управления можно использовать два похода к созданию модели бизнес-процессов:
№
Подход
Использование
1.
Выделение и описание набора отдельных бизнес-процессов компании.
Целесообразно использовать в организациях, которые недавно приступили к формализации своей системы управления.
Позволяет быстро решить задачи формализации отдельного набора бизнес-процессов. Бизнес-процессы, относящиеся к разным объектам управления можно группировать с помощью папок.
Для согласования бизнес-процессов между собой их можно связать по входам и выходам с помощью междиаграммных ссылок (нотации Процедура, Процесс) или интерфейсов процессов (нотация EPC).
Используемые нотации: Процедура, Процесс, EPC.
2.
Создание комплексной модели бизнес-процессов
Предназначен для организаций, осуществляющих полный цикл проектирования системы управления.
Модель создается в соответствии с методологией структурного анализа и проектирования SADT. Это позволяет создать комплексную непротиворечивую модель бизнес-процессов, получить распределение ответственности за основные результаты деятельности.
Используемые нотации: IDEF0 – на верхнем уровне модели, Процедура, Процесс, EPC - на нижних уровнях.
В случае создания модели бизнес-процессов в зависимости от количества уровней системы управления и набора объектов управления может создаваться не одна, а несколько моделей бизнес-процессов:
№
Моделируемая система управления
Состав моделей
1.
1 уровень управления - монопредприятие, количество объектов управления не более 8
Одна комплексная модель бизнес-процессов.
(Пример – нормативная 8-процессная модель БКГ: http: //www.businessstudio.ru/procedures/models)
2.
1 уровень управления - монопредприятие, количество объектов управления более 8
Возможно два варианта:
1. Создание одной модели, на верхнем уровне которой будет группировка по «метапроцессам», например, Процессы управления, Процессы развития, Основные процессы, Обеспечивающие процессы.
2. Создание нескольких моделей – по одной для каждого «метапроцесса». Модели можно связать между собой по входам и выходам с помощью междиаграммных ссылок.
3.
2-уровневая система управления (управляющая компания - производственные единицы)
1. Одна модель для управляющей компании.
2. В общем случае N моделей – по одной для каждой производственной единицы (количество моделей может быть меньше, если ряд производственных единиц должен иметь одинаковую систему управления).
Модели можно связать между собой по входам и выходам с помощью междиаграммных ссылок.
Структура модели бизнес-процессов
Модель бизнес-процессов, согласно методологии SADT, создается на основе принципа декомпозиции: «…декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание объекта». На верхнем уровне модели рассматриваемая система представляется в виде одного процесса, например, «Деятельность по производству и продаже оборудования», далее он декомпозируется на совокупность бизнес-процессов верхнего уровня. Каждый из бизнес-процессов верхнего уровня декомпозируется на ряд подпроцессов. В качестве критерия выделения подпроцессов второго уровня можно использовать промежуточные состояния объекта управления. Например, процесс «Продвижение и продажи» может быть декомпозирован на подпроцессы:
1. Продвижение продуктов
2. Выяснение потребности клиента
3. Заключение договора с потребителем
4. Прием текущих заказов
5. Производственное планирование
6. Организация выполнения заказа клиента
7. Организация удовлетворения претензий клиентов
8. Анализ удовлетворенности клиентов
Количество уровней декомпозиции выбирается исходя из стоящих задач и необходимой степени подробности описания. На практике используют 3-5 уровней декомпозиции.
Business Studio позволяет создавать графические модели бизнес-процессов с помощью диаграмм, выполненных в той или иной нотации моделирования. Поддерживается четыре типа нотаций графического моделирования – IDEF0, Процесс и Процедура, EPC. Для создания модели бизнес-процессов можно использовать любую из этих нотаций или их комбинации. Рекомендуется в зависимости от уровня процесса в модели для его описания использовать следующие нотации:
Уровень модели
Используемая нотация
Комментарий
IDEF0 (контекстная диаграмма)
Модель, выполненная в нотации IDEF0, имеет контекстную диаграмму верхнего уровня А-0, на которой объект моделирования представлен единственным блоком с граничными стрелками. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу.
IDEF0
1 уровень содержит процессы верхнего уровня модели.
IDEF0
2 уровень содержит декомпозицию процессов верхнего уровня. Например, процесс второго уровня «Продвижение продуктов» может быть декомпозирован на подпроцессы 3 уровня:
1. Группировка клиентов и анализ клиентской базы
2. Разработка программы удержания клиентов
3. Определение потребности по привлечению новых клиентов
4. Разработка комплекса продвижения продуктов на целевые рынки
5. Проведение мероприятий комплекса продвижения
3 и далее
Процесс, Процедура, EPC
На 3 уровне происходит смена нотации моделирования. 3 уровень при корректной декомпозиции будет представлять собой работы – наименьшие возможные процессы, создающие минимальный отделимый результат, за отдельные действия внутри работы будут отвечать конкретные должностные лица.
Если в модели используются метапроцессы, то уровни сдвигаются, начиная с 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].
Нотации Процесс и Процедура
Нотации Процесс (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. Пример диаграммы в нотации Процесс
Рис.17. Пример диаграммы в нотации Процедура
Нотация EPC
Нотация EPC (Event-Driven Process Chain – событийная цепочка процессов) используется для описания процессов нижнего уровня. Диаграмма процесса в нотации EPC, представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни. Декомпозиция может производиться только в нотации EPC.
При декомпозиции процесса ЕРС, расположенного на диаграмме SADT, стрелки с диаграммы SADT на диаграмму ЕРС не переносятся.
Используемые графические символы
Название
Графический символ
Описание
Функция
Блок представляет собой функцию – действие или набор действий, выполняемых над исходным объектом (документом, ТМЦ и прочим) с целью получения заданного результата.
Внутри блока помещается наименование функции.
Временная последовательность выполнения функций задается расположением функций на диаграмме процесса сверху вниз.
Событие
Событие – состояние, которое является существенным для целей управления бизнесом и оказывает влияние или контролирует дальнейшее развитие одного или более бизнес-процессов. Элемент отображает события, активизирующие функции или порождаемые функциями. Внутри блока помещается наименование события.
Стрелка
Стрелка отображает связи элементов диаграммы процесса EPC между собой. Связь может быть направленной и ненаправленной в зависимости от соединяемых элементов и типа связи.
Оператор AND («И»)
Рис.18
Рис.19
Рис.20
Рис.21
Оператор «И» используется для обозначения слияния/ветвления как функций, так и событий.
Если завершение выполнения функции должно инициировать одновременно несколько событий, то это обозначается с помощью оператора «И», следующего после функции и перед событиями. На рисунке (Рис.18) завершение выполнения Функции одновременно инициирует события: Событие 1 и Событие 2.
Если событие происходит только после обязательного завершения выполнения нескольких функций, то это обозначается с помощью оператора «И», следующего после функций и перед одиночным событием. На рисунке (Рис.19) Событие произойдет только после обязательного завершения Функции 1 и Функции 2.
Если функция может начать выполняться только после того, как произойдут несколько событий, то это обозначается с помощью оператора «И», следующего после событий и перед функцией. На рисунке (Рис.20) Функция начнет выполняться только после того, как произойдут Событие 1 и Событие 2.
Если одно событие может инициировать одновременное выполнение нескольких функций, то это обозначается с помощью оператора «И», следующего после события и перед функциями. На рисунке (Рис.21) Событие одновременно инициирует выполнение Функции 1 и Функции 2.
Оператор OR («ИЛИ»)
Рис.22
Рис.23
Рис.24
Оператор «ИЛИ» используется для обозначения слияния/ветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «ИЛИ».
Если завершение выполнения функции может инициировать одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после функции и перед событиями. На рисунке (Рис.22) завершение выполнения Функции 1 может инициировать 3 вида ситуаций: только Событие 1, только Событие 2, одновременно и Событие 1, и Событие 2.
Если событие происходит после завершения выполнения одной или нескольких функций, то это обозначается с помощью оператора «ИЛИ», следующего после функций и перед одиночным событием. На рисунке (Рис.23) Событие может произойти либо после завершения выполнения Функции 1, либо после завершения выполнения Функции 2, либо после завершения выполнения и Функции 1, и Функции 2.
Если функция может начать выполняться после того, как произойдет одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после событий и перед функцией. На рисунке (Рис.24) Функция может начать выполняться либо после того, как произойдет Событие 1, либо после того, как произойдет Событие 2, либо после того, как произойдут оба события: Событие 1, и Событие 2.
Оператор XOR («Исключающее ИЛИ»)
Рис.25
Рис.26
Рис.27
Оператор «Исключающее ИЛИ» используется для обозначения слияния/ветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «Исключающее ИЛИ».
Если завершение выполнения функции может инициировать только одно из событий в зависимости от условия, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего за функцией и перед событиями. На рисунке (Рис.25) Функция инициирует либо только Событие 1, либо только Событие 2.
Если событие происходит сразу после завершения выполнения либо одной функции, либо другой, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после функций и перед одиночным событием. На рисунке (Рис.26) Событие может произойти либо сразу после завершения выполнения Функции 1, либо сразу после завершения выполнения Функции 2.
Если функция может начать выполняться сразу после того, как произойдет либо одно событие, либо другое, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после нескольких событий и перед функцией. На рисунке (Рис.27) Функция может начать выполняться сразу после того, как произойдет либо Событие 1, либо Событие 2.
Интерфейс процесса
Рис.28
Рис.29. Диаграмма Процесса 1
Рис.30. Диаграмма Процесса 2
Элемент, обозначающий внешний (по отношению к текущей диаграмме) процесс или функцию. Используется для указания взаимосвязи процессов:
- обозначает предыдущий или следующий процесс по отношению к диаграмме рассматриваемого процесса;
- обозначает процесс, откуда поступил или куда передается объект.
Внутри блока помещается наименование внешнего процесса.
На рисунке (Рис.28) показано, что договор является результатом выполнения процесса «Заключение договора».
На рисунке (Рис.29) показано, что после окончания Процесса 1 (и наступления Событие 1) начинает выполняться Процесс 2.
На диаграмме Процесса 2 (Рис.30) показано, что перед началом Процесса 2 был завершен Процесс 1, инициировавший Событие 1.
Субъект
Используется для отображения на диаграмме организационных единиц (должности, подразделения, роли, внешнего субъекта) – исполнителей, владельцев или участников функций. Внутри блока помещается наименование организационной единицы.
Бумажный документ
Используется для отображения на диаграмме бумажных документов, сопровождающих выполнение функции. Внутри блока помещается наименование бумажного документа.
Электронный документ
Используется для отображения на диаграмме электронных документов, сопровождающих выполнение функции. Внутри блока помещается наименование электронного документа.
ТМЦ
Используется для отображения на диаграмме товарно-материальных ценностей (ТМЦ), сопровождающих выполнение функции. Внутри блока помещается наименование ТМЦ.
Информация
Используется для отображения на диаграмме информационных потоков, сопровождающих выполнение функции. Внутри блока помещается наименование информационного потока.
Информационная система
Используется для отображения на диаграмме информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование информационной системы.
Модуль информационной системы
Используется для отображения на диаграмме модуля информационной системы, поддерживающего выполнение функции. Внутри блока помещается наименование модуля информационной системы.
Функция информационной системы
Используется для отображения на диаграмме функции информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование функции информационной системы.
База данных
Используется для отображения на диаграмме базы данных, сопровождающей выполнение функции. Внутри блока помещается наименование базы данных.
Термин
Рис.31
Используется для отображения на диаграмме объектов, сопровождающих выполнение функции. Наименования этих объектов – термины, используемые в организации. Внутри блока помещается наименование термина.
Элемент может быть использован для обозначения данных, передаваемых между процессами или обрабатываемых при выполнении процессов.
Элемент может быть также использован для обозначения статусов бумажных/электронных документов и других элементов справочника «Объекты деятельности». На рисунке (Рис.31) статус документа «Акт выполненных работ» устанавливается с помощью термина «Подписанный».
Набор объектов
Используется для отображения на диаграмме наборов объектов, сопровождающих выполнение функции, например, «Документация по проекту». Внутри блока помещается наименование набора объектов.
Прочее
Используется для отображения на диаграмме потоков объектов, которые нельзя отнести ни к одной из предопределенных групп справочника «Объекты деятельности». Внутри блока помещается наименование прочего объекта.
Команды панели инструментов для диаграммы EPC
Команда
Графический символ
Описание
Удалить тип связи по умолчанию
Кнопка предназначена для удаления типов связей, установленных пользователем по умолчанию.
Показать/убрать все типы связей на диаграмме
Кнопка предназначена для показа наименований всех типов связей, наведенных на диаграмме.
Переместить контекст функции с вышележащей диаграммы
Кнопка предназначена для перемещения с вышележащей
Кардиналистский и ординалистский подходы Кардиналистский (количественный подход) к анализу полезности основан на представлении о возможности измерения различных благ в условных единицах полезности...
ЛЕКАРСТВЕННЫЕ ФОРМЫ ДЛЯ ИНЪЕКЦИЙ К лекарственным формам для инъекций относятся водные, спиртовые и масляные растворы, суспензии, эмульсии, новогаленовые препараты, жидкие органопрепараты и жидкие экстракты, а также порошки и таблетки для имплантации...
Рис.10
Рис.11
Рис.12
Рис.13
Рис.14
Рис.15
Рис.18
Рис.19
Рис.20
Рис.21
Рис.22
Рис.23
Рис.24
Рис.25
Рис.26
Рис.27
Рис.28
Рис.29. Диаграмма Процесса 1
Рис.30. Диаграмма Процесса 2
Рис.31
