Описание и анализ бизнес-процессов
Рассмотрим и сравним нотации, наиболее часто используемые для описания бизнес-процессов, на примере описания бизнес-процесса найма персонала с помощью каждой из них.
Моделируемый процесс можно представить состоящим из следующих пяти этапов:
• отбор кандидатов на вакансию, проводимый отделом кадров;
• первичное собеседование соискателя на должность, проводимое специалистом отдела кадров;
• вторичное собеседование соискателя с потенциальным руководителем;
• проверка соискателя службой безопасности;
• вынесение руководителем организации окончательного решения но соискателю.
Нотация кросс-функциональная схема представляет собой структурированное представление алгоритма выполнения процесса (нотация класса workflow), раскладывающее бизнес-процесс в двух измерениях – последовательности шагов и исполнителей.
Таблица 8.1
Основные элементы нотации: кросс-функциональная схема
|
Пиктограмма |
Название |
Обозначение |
|
|
Начало или завершение |
Первый и последний этапы процесса |
|
|
Процесс и ручной процесс |
Стандартный этап процесса |
|
|
Решение и подготовка |
Выбор следующего этапа в зависимости от принятого решения. Вариантов может быть несколько, но чаще всего их два – "да" или "нет" |
|
|
Подпроцесс |
Несколько этапов, которые в совокупности образуют подпроцесс, определенный в другом месте, например, на другой странице документа |
|
|
Документ и пакет документов |
Этап, на котором создается документ или пакет документов |
|
|
Хранение и данные |
Данные, поступающие в процесс или выходящие из него |
Каждый шаг бизнес-процесса представляется на диаграмме при помощи специальных фигур-пиктограмм, основные из которых приведены в табл. 8.1.
Элементы нотации связываются между собой однонаправленными стрелками, обозначающими информационные или материальные потоки между элементами, а также переход от одного этапа бизнес-процесса к следующему.
Модель бизнес-процесса согласно нотации кросс-функциональной схемы строится в горизонтальных или вертикальных областях, называемых дорожками (Swim Lane). Дорожка означает организационную единицу – должность, подразделение или роль, т.е. исполнителя действия процесса. В дорожках размещаются действия, за которые отвечает соответствующая должность, подразделение или роль. При этом действие может быть разбито на более детальные бизнес-процессы, описываемые в данной либо в других нотациях.
Нотация кросс-функциональная схема (рис. 8.1) обладает простотой синтеза моделей и последующего их анализа, что позволяет строить понятные сотрудникам диаграммы. В то же время она не содержит достаточного набора элементов для моделирования сложных процессов. Кроме того, диаграммы процессов, построенные в данной нотации, не могут использоваться для исполнения в режиме реального времени, в отличие от схожей нотации BPMN. Указанные особенности обуславливают применение нотации в основном для описания простых и вспомогательных процессов, либо для составления предварительной схемы сложных процессов с целью отражения общей логики без детализации.
Нотация IDEF0 основана на методологии структурного анализа и проектирования SADT и служит для создания функциональной модели, включающей структурированное описание функций, действий или процессов моделируемой системы.
Модель строится по иерархическому принципу от самого агрегированного уровня до детализированного, применяя операцию декомпозиции в соответствии с функциями, которые выполняет организация (функциональная декомпозиция), в соответствии с известными подсистемами или по физическому процессу. Каждый уровень представляется диаграммой (подмоделью), содержащей пять-шесть действий, объединенных общей логикой.
Нотация IDEF0 содержит два графических элемента – блок (прямоугольник, содержащий имя, – активный глагол
Рис. 8.1. Описание бизнес-процесса найма сотрудников в нотации кросс-функциональная схема
или глагольный оборот, описывающий функцию, и номер, используемый для идентификации блоков на диаграмме) и стрелку (рис. 8.2).
Блоки обозначают процессы или функции рассматриваемой системы, среди которых выделяются четыре основные вида: деятельность, процесс, операция и действие (табл. 8.2).
Кроме приведенных в табл. 8.2 четырех основных видов функций выделяются два дополнительных – субдеятельность и подпроцесс.
Субдеятельностъ определяется как совокупность нескольких процессов в составе деятельности, объединенная некоторой частной целью ("подцелью" деятельности).
Под подпроцессом понимается группа операций в составе процесса, объединенная технологически или организационно.
Все функции, входящие в приведенную классификацию, находятся между собой в отношениях иерархической подчиненности по принципу "сверху вниз": деятельность → субдеятельность → процесс → подпроцесс → операция → действие.
Рис. 8.2. Пиктограмма блока в нотации IDEF0
Таблица 8.2
Основные виды функций в нотации IDEF0
|
Вид функции |
Осуществляется в соответствии с |
|
Деятельность |
определенной и постоянно корректируемой целью, потреблением ресурсов (финансовых, энергетических, трудовых и материальных), при выполнении ограничений со стороны внешней среды |
|
Процесс |
управляющими директивами, вырабатываемыми на основе целей деятельности |
|
Операция |
а) директивами, вырабатываемыми на основе директив, определяющих протекание процесса, в состав которого входит операция; б) потреблением всех видов необходимых ресурсов; в) соблюдением ограничений со стороны других операций и внешней среды |
|
Действие |
командой, являющейся частью директивы на выполнение операции, с потреблением необходимых ресурсов и с соблюдением ограничений, налагаемых на осуществление операции |
Блоки в IDEF0 модели могут быть функционально связаны между собой и находиться в одном из шести видов отношений:
• "доминирование" (отражает влияние, которое один блок оказывает на другие блоки диаграммы, и определяется взаимным расположением блоков: блоки, расположенные на диаграмме выше и левее, "доминируют" над блоками, расположенными ниже и правее);
• "управление" (выход одного блока служит управляющим воздействием на блок с меньшим доминированием (рис. 8.3));
• "выход – вход" (соединение выхода одного блока с входом другого блока с меньшим доминированием (рис. 8.4));
• "обратная связь по управлению" (выход некоторого блока создает управляющее воздействие на блок с большим доминированием (рис. 8.5));
• "обратная связь по входу" (выход блока становится входом другого блока с большим доминированием (рис. 8.6));
• "выход – механизм" (выход одной функции становится средством достижения цели для другой (рис. 8.7)). Связи вида "выход – механизм" возникают при отображении в модели процедур пополнения и распределения ресурсов, создания или подготовки средств для выполнения функций системы (например, приобретение или изготовление требуемых инструментов и оборудования, обучение персонала, организация физического пространства, финансирование, закупка материалов и т.д.).
Рис. 8.3. Схема отношений вида "управление"
Рис. 8.4. Схема отношений вида "выход-вход"
Рис. 8.5. Схема отношений вида "обратная связь по управлению"
Рис. 8.6. Схема отношений вида "обратная связь по входу"
Рис. 8.7. Схема отношений вида "выход – механизм"
Все описанные выше отношения отображаются внутренними стрелками, у которых оба конца связаны с блоками диа- граммы.
Стрелки в нотации IDEF0 нс представляют поток или последовательность событий, как в традиционных блок-схемах потоков или процессов (потоковых диаграммах), а показывают, какие данные или материальные объекты должны поступить на вход функции для ее выполнения. В нотации используются пять основных видов стрелок: три стрелки, входящие в блок (слева, сверху и снизу), одна стрелка, выходящая из блока (справа), а также специальная стрелка вызова (табл. 8.3).
Кроме основных видов стрелок нотация предполагает использование "пунктирных" стрелок отношения, используемых для привязки элементов-комментариев к функциям, и стрелок потока объектов от одной функции к другой. Последний вид отличается наличием двойного треугольника на наконечнике.
Таким образом, модель в нотации IDEF0 строится из блоков следующего вида (рис. 8.8).
Таблица 8.3
Основные виды стрелок в нотации IDEF0
|
Пиктограмма |
Название |
Обозначение |
|
|
Стрелка входа (входящая слева) |
Входящие документы, материальные и информационные ресурсы, необходимые для выполнения работы (работа может не иметь ни одной стрелки входа) |
|
|
Стрелка выхода (выходящая справа) |
Исходящие документы, материальные и информационные ресурсы, являющиеся результатом выполнения работы |
|
|
Стрелка управления (входящая сверху) |
Правила, ограничения и другие управляющие воздействия (каждая работа должна иметь не менее одной стрелки управления) |
|
|
Стрелка механизма (входящая снизу) |
Ресурсы, которые необходимы для выполнения работы, но которые не подвергаются изменению |
|
|
Стрелка вызова (выходящая снизу) |
Обращение из работы данной модели к работе вне моделируемой системы для обеспечения связи между моделями |
Рис. 8.8. Схема блока в нотации IDEF0
С каждым из блоков в качестве атрибутов могут быть связаны стоимость исполнения, время выполнения функции или какой-либо другой показатель, что позволяет реализовать функционально-стоимостной анализ путем интеграции показателей декомпозированных блоков в показатель родительского блока.
Нотация IDEF0 удобна для построения моделей, отображающих только общее взаимодействие процессов, без глубокой детализации, и плохо подходит для моделирования сложных процессов, в которых задействовано большое количество элементов и логических связей. Кроме того, нотация ориентирована, прежде всего, на описание состава и структуры процессов (рис. 8.9), протекающих в рассматриваемой системе, не учитывая последовательности их реализации во времени. В связи с этим IDEF0 в основном используется для создания моделей бизнес-процессов верхнего уровня, а для описания процессов нижних уровней применяются нотации IDEF3, ЕРС, Cross Functional Flowchart и ΒΡΜΝ.
С 2000 г. нотация IDEF0 принята в качестве стандарта в Российской Федерации ГОСТ Р 50.1.028–2001 "Информационные технологии поддержки жизненного цикла изделия. Методология функционального моделирования", принятого и введенного в действие постановлением Госстандарта России от 02.07.2001 № 256-ст.
В целях отражения причинно-следственных связей между функциональными блоками, используя привычный для эксперта структурный метод выражения знаний, была разработана нотация IDEF3, имеющая прямую взаимосвязь с методологией IDEF0, каждый функциональный блок которой может быть представлен в виде отдельного процесса средствами IDEF3.
В нотации IDEF3 используется два вида диаграмм: диаграммы описания последовательности этапов процесса (Process Flow Description Diagrams (PFDD)) и диаграммы перехода со-
Рис. 8.9. Описание бизнес-процесса найма сотрудников в нотации IDEF0
стояния объекта (Object State Transition Network (OSTN)). Первые ориентированы на моделирование последовательностей и стадий обработки в рамках бизнес-процесса (с точки зрения наблюдателя), вторые используются для иллюстрации трансформаций, которые происходят на каждой стадии бизнес-процесса (с точки зрения объекта).
Нотация IDEF3 разрабатывалась для технических специалистов, вследствие чего включает специальные операции, требующие дополнительного пояснения менеджерам. Кроме того, в отличие от IDEF0 она не поддерживает отображение "механизмов" и "управления", что ограничивает применение IDEF3 моделированием процессов нижнего уровня. В результате, несмотря на то, что IDEF3 получила широкое применение при моделировании информационных систем, данная нотация не стала стандартом бизнес-моделирования.
Более современной бизнес-ориентированной нотацией, используемой для описания процессов нижнего уровня в виде потоков последовательно выполняемых работ, является нотация описания цепочки процесса, управляемого событиями (Event Driven Process Chain (EPC)) и ее расширенная версия (extended Event Driven Process Chain (eEPC). ЕРС-метод был разработан А.-В. Шеером в рамках работ над созданием методологии ARIS (Architecture of Integrated Information Systems) в начале 1990-х гг. Основой для ЕРС послужила нотация IDEF3.
Нотация еЕРС предназначена для описания процессов в виде последовательности функций, управляемых событиями, и таким образом сочетает в себе функциональный и событийный подходы. еЕРС можно применять как для моделирования отдельных процессов компании, так и на нижнем уровне модели, созданной в нотации IDEF0.
Ключевым понятием нотации еЕРС является событие, представляющее собой механизм отражения изменений состояния внешней или внутренней среды. Событием начинается и заканчивается любая ЕРС-диаграмма. Примерами событий могут служить получение документов (договоров, платежных документов и т.п.), принятие решений, наступление определенного момента времени, достижение определенного лимита (запаса сырья на складе, лимита кредитной линии), влекущего за собой необходимость управленческих воздействий. События являются результатом выполнения функций, а также необходимостью выполнения других функций, т.е. только фиксируют состояния определенных параметров на момент времени.
Другим важным понятием нотации является функция, определяемая как действие или набор действий, выполняемых над исходным объектом с целью получения заданного результата. Для каждой функции могут быть определены цели, начальное и конечное события, ответственные исполнители, материальные и документарные потоки (входы, выходы, ресурсы). Инициируется и завершается исполнение функции событием, входящим и исходящим соответственно. При этом в каждую функцию не может входить более одного события, "запускающего" ее выполнение, и выходить более одного события, описывающего завершение выполнения. При необходимости к функции может быть применена операция декомпозиции на подфункции и т.д.
Помимо указанных основных элементов, при построении диаграммы еЕРС могут быть использованы элементы вида "организационная единица", "информация", "материал" или "объект ресурса" и др.
Для каждого элемента на диаграмме при помощи специальных элементов связи (стрелок) отражаются его отношения с другими элементами. В качестве таких связующих элементов выступают (табл. 8.4):
• поток управления (соединяет события с функциями, путями процесса или логическими взаимосвязями, создавая хронологическую последовательность или логическую взаимозависимость между ними);
• поток информации (соединяет функции и данные (входящие и исходящие), с которых функция считывает изменения или вносит их);
• назначение организационной единицы (соединяет организационные единицы и функции, за которые она ответственна);
• путь процесса (соединяет процессы между собой).
Связи между событиями и функциями в рамках процесса, а также между самими процессами могут быть организованы через логические операции – конъюнкцию ("и"), дизъюнкцию ("или") и строгую дизъюнкцию ("исключающее или"). Использование данных операций требуется, например, в случае, когда процесс разделяется на ветви или, наоборот, соединяются параллельные ветви процесса, после чего выполнение процесса происходит по одному пути. В табл. 8.5 приведены схемы простого ветвления и соединения процессов.
Важно отметить, что аналогичные структуры и языковые средства присущи и многим другим нотациям.
Нотация еЕРС содержит значительное количество функциональных элементов, что с применением соответствующего средства моделирования позволяет строить комплексные модели бизнес-процессов, моделировать риски и KPI, осуществлять выгрузку информации в виде регламентирующих документов (рис. 8.10). Среди недостатков нотации можно отметить сложность еЕРС моделей для восприятия рядовы-
Таблица 8.4
Основные элементы нотации еЕРС
|
Пиктограмма |
Название |
Обозначение |
|
|
Функция |
Функции (процедуры, работы), выполняемые подразделениями или сотрудниками предприятия |
|
|
Событие |
Состояние системы, влияющее и управляющее выполнением функций |
|
|
Организационная единица |
Организационные звенья предприятия, например, департамент, управление, отдел |
|
|
Штатная должность |
Должность, которой может быть поручено выполнение функции |
|
|
Документ |
Носители информации, например, бумажный документ |
|
|
Прикладная система |
Прикладная система, используемая в рамках технологии выполнения функции |
|
|
Кластер информации |
Объекты, которые могут быть как входными данными, выступающими в качестве основы функции, так и выходными данными, полученными с помощью функции; используется для отображения объектов в информационных системах (например, запись в базе данных, проводка в бухгалтерской системе и т.д.) |
|
|
Интерфейс процесса |
Ссылка на смежный процесс |
|
|
Стрелка связи между объектами |
Отношения между объектами, например, активация выполнения функции некоторым событием; пунктирной стрелкой представлен поток управления |
Таблица 8.5
Схемы ветвления и соединения процессов в нотации еЕРС
|
Схема операции |
Операция "и" |
Операция "исключающее или" |
Операция "или" |
|
|
|
|
|
|
|
|
|
|
|
|
Функция выполняется, если наступили все события |
Функция выполняется, если наступило ровно одно из событий |
Функция выполняется, если наступило хотя бы одно из событий |
|
|
После выполнения функции наступают все события |
После выполнения функции наступает ровно одно из событий |
После выполнения функции наступает хотя бы одно из событий |
|
|
Событие наступает, когда выполнены все функции |
Событие наступает после выполнения ровно одной функции |
Событие наступает после выполнения хотя бы одной функции |
|
|
При наступлении события выполняются все функции |
Важно: запрещенная ситуация, так как событие не может принимать решения |
|
ми сотрудниками и, в отличие от BPMN, непригодность для прямой автоматизации в системах класса ВРМ. В то же время, если речь идет не о разработке, а о внедрении и сопутствующей кастомизации ERP, то еЕРС позволяет транслировать процессные диаграммы, например, в настройки SAP R/3.
Нотация BPMN (Business Process Model and Notation) разработана некоммерческой организацией BPMI (сокр. от англ. Business Process Management Initiative) в 2001–2004 гг.
Рис. 8.10. Описание бизнес-процесса найма сотрудников в нотации еЕРС
для отображения бизнес-процессов в виде процессных диаграмм. Разработка новой нотации преследовала несколько основных целей. Во-первых, целью являлось создание нотации разработки моделей бизнес-процессов для различных категорий специалистов: аналитиков и экспертов, моделирующих бизнес-процессы, технических разработчиков, создающих системы для выполнения процессов, менеджеров различных уровней, которые должны понимать процессные диаграммы, и др. Во-вторых, ко времени разработки стала очевидной необходимость нотации, легко перекладываемой на универсальный язык исполнения бизнес-процессов в автоматизированных системах. С появлением BPMN указанные цели были достигнуты.
Моделирование бизнес-процессов в BPMN осуществляется на основе элементов четырех категорий: объекты потока управления, соединяющие объекты, роли и артефакты.
Объекты потока управления подразделяются на события, действия и логические операторы.
События изображаются окружностью и, так же как в нотации еЕРС, означают какое-либо изменение внутри или вне процесса, инициируют действия или являются их результатами. В нотации определено более 10 типов событий (рис. 8.11), например, сообщения, моделирующие получение или отправку сообщений, или сигналы, отражающие обмен сигналами между процессами (рис. 8.12).
Согласно расположению в процессе события классифицируются на начальные, промежуточные и завершающие. Кроме того различают события обработки и генерации.
Действия отображаются прямоугольниками со скругленными углами (рис. 8.13).
Множественные экземпляры действия показывают, что одно действие выполняется многократно, по одному разу для
Рис. 8.11. Пиктограммы событий
Рис. 8.12. Пиктограммы сигналов
Рис. 8.13. Пиктограммы действий
Рис. 8.14. Пиктограмма задания (слева) и подпроцесса (справа)
каждого объекта. При этом экземпляры действия могут выполняться параллельно или последовательно.
Циклическое действие выполняется, пока условие цикла верно. Условие цикла может проверяться до или после выполнения действия.
В свою очередь действия подразделяются на задания – атомарные единицы работы, и подпроцессы – логически объединенные группы действий в рамках бизнес-процесса.
Свернутый подпроцесс является сложным действием и скрывает детали реализации процесса (рис. 8.14).
Развернутый подпроцесс (рис. 8.15) также является составным действием, но содержит внутри себя диаграмму бизнес-процессов.
Ad-hoc[1] подпроцесс содержит задания, которые выполняются до тех пор, пока не выполнено условие завершения подпроцесса (рис. 8.16).
Логические операторы представлены тремя операциями, стандартными для современных нотаций описания бизнес- процессов – логическими "и", "или", "исключающее или", моделирующими операциями конъюнкции, дизъюнкции и строгой дизъюнкции соответственно, а также сложным оператором, активизирующим исходящие ветви в зависимости от выполнения того или иного условия.
Логические операторы представляют точки принятия решений в процессе, с их помощью организуются ветвление и синхронизация потоков управления в модели процесса. На диаграммах логические операторы изображаются ромбами.
Объекты потока управления связаны друг с другом соединяющими объектами. Существует три вида соединяющих объектов: потоки управления, потоки сообщений и ассоциации.
Поток управления задаст порядок выполнения действий, на диаграмме изображается сплошной линией, оканчивающейся закрашенной стрелкой (рис. 8.17). Поток управления
Рис. 8.15. Пиктограмма развернутого подпроцесса
Рис. 8.16. Пиктограмма Ad-hoc подпроцесса
Рис. 8.17. Пиктограммы потока управления
Рис. 8.18. Пиктограмма потока сообщений
разделяется на два подвида – поток но умолчанию (определяет ветвь процесса, выполняемую, когда все условия ветвления не выполнены) и условный поток (связан с условием, определяющим, будет ли данный поток выполнен).
Поток сообщений показывает, какими сообщениями обмениваются участники. На диаграмме изображается штриховой линией (рис. 8.18).
Ассоциации используются для ассоциирования артефактов, данных или текстовых аннотаций с объектами потока управления, изображаются пунктирной линией, заканчивающейся стрелкой (рис. 8.19).
Роли представляют собой визуальный механизм организации действий со сходной функциональностью. Существует два вида ролей: пулы и дорожки. Они отражают распределение обязанностей, обозначают организацию, роль или систему.
Пулы (участники) содержат объекты потока управления, соединяющие объекты и артефакты, изображаются прямоугольником (рис. 8.20).
Дорожки являются частью пула и позволяют организовать объекты потока управления, связывающие объекты и артефакты.
Рис. 8.19. Пиктограммы ассоциаций
Рис. 8.20. Структура организации объектов в нотации ΒΡΜΝ
Артефакты позволяют отображать в диаграмме дополнительную информацию. Существуют три предопределенных вида артефактов: данные, группа и текстовые аннотации.
Первый вид показывает, какие данные необходимы действиям для выполнения и какие данные действия производят.
Группа позволяет объединять различные действия, но не влияет на поток управления в диаграмме, изображается прямоугольником со штрихованной границей и закругленными углами.
Текстовые аннотации используются для уточнения значения элементов диаграммы.
При необходимости расширения языковых средств нотация BPMN позволяет создавать новые типы объектов потока управления и артефактов.
Нотация BPMN изначально создавалась для моделирования рабочих потоков, вследствие чего предлагает широкие возможности для контроля структуры потоков. Сильной стороной нотации BPMN также является абстрактное представление моделей, сочетающееся с детальностью описания процессов, что позволило разработать программные решения для преобразования BPMN диаграмм в исполняемые процессы на языках ВРМL (Business Process Modeling Language) и BPEL (Business Process Execution Language). Эти процессы затем могут быть запущенны сервером управления бизнес- процессами и обработаны в реальном масштабе времени. Таким образом, BPMN является единственной распространенной нотацией, позволяющей реализовать концепцию непосредственного исполнения бизнес-процессов.
Наряду с этим, для нее характерна сложность спецификации, избыточность семантики для описания простых процессов и неудобство при создании сложной, многоуровневой процессной модели организации в целом. Также следует учитывать, что хотя BPMN и позволяет моделировать потоки данных и сообщений, а также ассоциировать данные с действиями, она не является схемой информационных потоков. Кроме того, в BPMN не описывается моделирование таких аспектов, как модель данных или организационная структура.
В целом BPMN является хорошей заменой IDEF для построения диаграмм процессов нижнего уровня (рис. 8.21).
На сегодняшний день для построения детализированных диаграмм бизнес-процессов наибольшей популярностью пользуются нотации еЕРС и BPMN. Обе нотации располага-
Рис. 8.21. Описание бизнес-процесса найма сотрудников в нотации BPMN
ют достаточными языковыми средствами для решения прикладных задач бизнес-аналитиков, но каждая имеет особенности и ограничения своего применения.
Основной причиной все более широкого распространения указанных нотаций является их поддержка современными системами управления бизнес-процессами, а также прикладными корпоративными системами классов ERP и CRM. Так, например, еЕРС применяется в ARIS (Software AG), сопряженной с известными системами управления предприятием, в том числе SAP R/3 (SAP AG), BPMN – в системах BPM-Online (группа компаний Terrasoft), SAP Net Weaver BPM (SAP AG), IBM Business Process Manager (IBM).
На практике нотация еЕРС часто используется для построения диаграмм процессов верхнего уровня, где важно отразить организационные единицы, риски, эффективность процесса, основные функции, a BPMN – для последующей детализации, с указанием конкретных исполнителей, последовательных алгоритмов выполнения действий, используемой документации.
Выбор конкретной нотации определяется, прежде всего, поставленной задачей. Если требуется исключительно моделировать архитектуру и схемы процессов без необходимости последующего исполнения, то связка IDEF и Workflow или IDEF и ЕРС будет удобнее, чем BPMN. Когда же стоит задача построения исполняемых бизнес-процессов, то для BPMN, изначально разрабатываемой с учетом задачи трансформации диаграмм бизнес-процессов в языки исполнения, практически отсутствует альтернатива.
Анализ бизнес-процессов заключается в детальном изучении деятельности организации с целью определения качества ее бизнес-процессов. Исследуются эффективность бизнес-процессов, соответствие структуры бизнес-процессов целям организации и т.д., выявляются некачественные бизнес-процессы, определяются возможности по их улучшению или реинжинирингу. При этом индикаторами плохого качества бизнес-процессов могут служить, например, низкая результативность операционной деятельности, задержки в обслуживании, простои оборудования, долгие процедуры решения однотипных задач.
Основными видами анализа бизнес-процессов являются:
• визуальный просмотр моделей бизнес-процессов для поиска неэффективных элементов, например, дублирования функций;
• стоимостной анализ операций, выполняемых в рамках процессов;
• анализ времени выполнения операций;
• функционально-стоимостной анализ (анализ по центрам затрат);
• анализ путей перемещения материальных, финансовых и информационных потоков между операциями процессов;
• анализ соответствия ресурсов, задействованных в процессе, их использованию.
Результаты анализа служат базисом для построения моделей бизнес-процессов "как должно быть", а также используются для улучшения или оптимизации существующих процессов.
Как правило, проведение комплексного анализа включает в себя моделирование исследуемых бизнес-процессов в программных системах классов ЕА (Enterprise Architecture – архитектура предприятия), ВРА (Business Process Analysis – анализ бизнес-процессов) или BPMS/BPMT (Business Process Management Suite/ System/Tool – пакет управления бизнес- процессами).
Лидерами рынка ВРА систем по критериям технологичности и стратегии ("полнота видения") и маркетинговым показателям ("способность реализации") согласно оценке консалтинговой компании Gartner за 2012 г. (рис. 8.22) являются компании:
• Software AG (среда ARIS);
• OpenText-Metastorm (Metastorm В PM и Metastorm Provision);
• IBM (System Architect во взаимодействии c BlueWorks);
• Mega (Mega Modeling Suite);
• iGrafx (Enterprise BPA tools);
• Microsoft (Visio);
• Casewise (Corporate Synergy).
Приведем практический пример моделирования бизнес- процессов.
Описание ситуации. Вы работаете аналитиком (менеджером, технологом, методологом, консультантом по оптимизации бизнес-процессов) в коммерческом банке. В условиях конкурентной среды и нестабильной экономической ситуации банк теряет рыночные позиции по ряду направлений деятельности. Руководство банка считает, что возникшие проблемы во многом обусловлены низким качеством процессов, реализуемых в бизнес-практике.
Рис. 8.22. Магический квадрант Gartner для рынка инструментов анализа бизнес-процессов
Постановка задачи. В целях повышения качества бизнес- процессов, а также формирования единых правил их выполнения сотрудниками всех структурных подразделений, вам поставлена задача разработки модели операционной деятельности банка (операционной модели) "как должно быть". Операционная модель представляет собой систему взаимосвязанных процессов, описывающих центральные сферы деятельности банка и ориентированных на обслуживание клиентов и контрагентов.
Вам ставится локальная задача построить модель процесса открытия вклада физическому лицу наличными денежными средствами но всей структурной иерархии: от модели описания предметных областей деятельности банка до детализированной модели процесса.
Согласно принятым в банке стандартам бизнес-моделирования описание модели должно быть выполнено в среде ARIS с применением реализованных в ней нотаций структурного и процессного моделирования (рис. 8.23).
В целях выполнения задачи самостоятельно найдите в сети Интернет и изучите нотации, применяемые в методологии ARIS для моделирования
Рис. 8.23. Структурный элемент
организационной структуры компании, ее информационной инфраструктуры и бизнес-процессов, обращая внимание на используемые в моделях элементы, типы связей между ними, требования к заполнению атрибутов элементов модели. После изучения приступайте к моделированию в среде ARIS, последовательно выполняя следующие этапы.
1. Постройте модель предметных областей деятельности банка. Декомпозируйте операционную модел! банка на организационную структуру, бизнес-процессы и информационную систему, отобразив их специальными элементами (рис. 8.24).
Элемент "Организационная структура" служит для дальнейшей декомпозиции в организационную структуру и бизнес-роли, в процессе которой на диаграмме вида "Организационная схема" элементами "Должность" должны быть отображены руководители банка и ряд должностных лиц, находящихся в их подчинении; элементами "Организационная единица" – структурные подразделения и отношения подчинения между ними.
Элемент "Бизнес-процессы" декомпозируется на модель "Процессы верхнего уровня" (процессная модель банка) вида "Цепочки добавленного качества".
Элемент "Информационная структура" декомпозируется на модели вида "Прикладная система", описывающие состав и структуру информационных систем.
На следующем этапе элементы, обозначающие предметную область (или составную часть), детализируются на моделях верхнего уровня (рис. 8.25).
Постройте модель бизнес-процессов верхнего уровня. Декомпозируйте элемент "Бизнес-процессы" на диаграмме цепочки добавленного качества VAD (Value Added Chain Diagram), определив основные виды банковских операций
Рис. 8.24. Модель "Описание предметных областей"
Рис. 8.25. Звено цепочки добавленного качества
Рис. 8.26. VAD диаграмма бизнес-процессов банка верхнего уровня
(рис. 8.26). Элементы диаграммы отображаются в виде пиктограмм, представленных на рис. 8.25, и соответствуют отдельному процессу или процессу верхнего уровня, если он является корнем дерева.
3. Постройте модель группы процессов "Привлечение денежных средств". Декомпозируйте элемент "Привлечение денежных средств" на группы по источникам привлечения (рис. 8.27).
Обратите внимание, что для наименования процессов необходимо использовать реальное название, состоящее из двух частей – отглагольного существительного, описывающего выполняемый процесс, и существительного, показывающего объект, над которым он выполняется.
Рис. 8.27. VAD диаграмма группы бизнес-процессов "Привлечение денежных средств"
4. Постройте модель подпроцессов "Вклады физических лиц". Обратите внимание, что данная детализация не является переходом на следующий уровень описания, а предназначена для более четкой классификации процессов и удобства восприятия моделей (рис. 8.28).
5. Постройте модель сценария процесса "Открытие вклада". Моделирование сценария процесса следует начинать с идентификации владельца бизнес-процесса, задействованных участников и их бизнес-ролей[2].
Для бизнес-процесса "Открытие вклада" владельцем является начальник операционного департамента, участниками – операционист и уполномоченное должностное лицо.
Операционист – это сотрудник отдела обслуживания физических лиц операционного департамента, ответственный за работу с клиентами – физическими лицами – по открытию, пополнению и истребованию вкладов. Операционист участвует в подпроцессах идентификации физического лица, открытия вклада наличными денежными средствами, переводом с текущего либо карточного счета.
Уполномоченным должностным лицом выступает сотрудник банка, наделенный полномочиями на представление интересов банка при подписании договоров и иных документов, связанных с операциями по вкладам. Уполномоченное должностное лицо задействовано в подпроцессах открытия
Рис. 8.28. VAD диаграмма подпроцессов "Вклады физических лиц"
счета наличными денежными средствами или посредством перевода с текущего счета.
По завершению идентификации декомпозируйте элемент "Открытие вклада" (рис. 8.29,8.30) на модель сценария, описав алгоритм выполнения данного процесса в виде последовательности выполнения подпроцессов, составляющих сценарий.
6. Постройте модель детального процесса "Открытие вклада (наличными)". Модель детального процесса (событийная цепочка процесса – еЕРС) предназначена для декомпозиции модели сценариев процесса и представляет собой последовательность событий и функций, отражающих логику выполнения действий в рамках бизнес-процесса, а также их ресурсное окружение. Главное внимание в модели этого уровня уделяется последовательности выполнения функций (рис. 8.31,8.32).
Обратите внимание: любая модель детального процесса обязательно начинается и заканчивается одним или несколькими событиями или интерфейсами в другие детальные процессы.
Рис. 8.29. Модель сценария бизнес-процесса "Открытие вклада" (верхняя часть)
Рис. 8.30. Модель сценария бизнес-процесса "Открытие вклада" (нижняя часть)
Рис. 8.31. Модель детального бизнес-процесса "Открытие вклада наличными денежными средствами" (верхняя часть)
Рис. 8.32. Модель детального бизнес-процесса "Открытие вклада наличными денежными средствами" (нижняя часть)
В процессе моделирования придерживайтесь следующих правил расположения элементов:
• расположение последовательности событий и функций осуществляется сверху вниз;
• документы, бизнес-роли, информационные системы и технические ресурсы располагаются относительно функции следующим образом:
– входящая информация (документы, файлы, кластеры информации) – слева сверху от функции;
– исходящая информация (документы, файлы, кластеры информации) – слева снизу от функции;
– исполнители (бизнес-роли) – справа сверху от функции;
– информационные системы, модули информационной системы – справа снизу от функции.