Каким образом можно создать бизнес процесс в business studio

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

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

Методика построения системы процессов компании

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

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

• Визуально представить себе готовую картинку в целом (обычно она приводится на коробке к пазлу);
• Терпеливо отбирать и складывать нужные элементы между собой.

Очевидно, что в случае потери общей картинки задача сборки элементов пазла существенно усложняется.

Переводя эту аналогию на язык бизнес-моделирования можно сказать, что:

• Общая картинка пазла — это системное понимание процессов бизнеса на верхнем уровне, и;
• Отдельные детальные элементы — это деятельность на среднем и нижнем уровне, выполняемая структурными подразделениями организации.

Один из возможных алгоритмов построения системы процессов организации представлен на рис 1.

Рис. 1. Алгоритм построения системы процессов организации

На первом шаге осуществляется разработка модели процессов организации на верхнем уровне. Цель создания модели — понимание того, как устроен бизнес организации. Рекомендуется создавать эту модель, используя принципы определения и построения схем цепочек создания ценности (ЦСЦ). Формируемая модель является структурной. Ее назначение — системно показать процессы компании на верхнем уровне и основные, наиболее важные связи между ними. Для создания структурной модели можно использовать любую, понятную и удобную бизнес-аналитикам нотацию (в т. ч. IDEF0 и т. п.). Главное, чтобы эта нотация соответствовала поставленной задаче. Для создания структурной модели можно использовать MS Visio, как наиболее доступный инструмент. На крайний случай, можно нарисовать модель на бумаге.

На шаге 2 осуществляется анализ деятельности структурных подразделений, выявление и структурирование процессов, которые в них выполняются. В случае, если позволяют человеческие ресурсы, шаги 1 и 2 можно выполнять одновременно. Заметим, что информация о процессах подразделений представляется в табличной форме (в MS Excel).

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

• Номер процесса;
• Наименование процесса;
• Ответственный за выполнение процесса руководитель;
• Участники;
• Входы;
• Инициирующие события;
• Выходы;
• Завершающие события.

Заметим, что схемы ЦСЦ являются промежуточным, рабочим материалом, необходимым для понимания бизнеса в целом и создания основы, «скелета» системы процессов. Но результат работы (система процессов) представляется в табличной форме.

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

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

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

Обычно для разработки адекватной бизнесу системы процессов требуется не менее 3–4 итераций. Для компании среднего размера (численность 1000–1500 человек, 100–150 сотрудников руководящего состава) такая работа занимает около 2 месяцев.

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

Использование отраслевых решений и материалов других компаний

На практике при построении системы процессов могут использоваться:

1. Информация по структуре процессов других компаний, работающих в той же отрасли;
2. Опыт экспертов по выделению и описанию процессов в аналогичных компаниях;
3. Отраслевые референтные модели разного типа, подходящие для контекста решаемой задачи (например, отраслевая модель APQC).

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

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

Необходимость графической модели процессов на верхнем уровне

Отдельно стоит обсудить, насколько полезны графические модели процессов для построения системы процессов. Например, с точки зрения автора, ошибкой является попытка построения многоуровневой системы процессов организации в одной модели IDEF0 (или другой нотации). Если соблюдать формальные правила, то в такой модели может получиться 7–8 уровней декомпозиции. Но реальную ценность для последующего описания и регламентации имеет всего 1–2 нижних уровня, где выполнятся конкретные операции процессов и осуществляется реальный документооборот! Именно на этих уровнях процессы могут быть описаны в формате Work Flow (поток работ), и при помощи этих описаний сформированы регламенты работы сотрудников («регламент процесса», «инструкция по выполнению процесса» и т. п.).

Можно сказать, что структурная модель верхнего уровня нужна:

1. Бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь, для корректного перехода к процессам уровня Work Flow — «регламентируемым» или «автоматически исполняемым» в BPMS процессам);
2. Руководителям, которым такая модель нужна для анализа и совершенствования архитектуры бизнеса.

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

Пример построения системы процессов торговой компании

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

Рис. 2. ЦСЦ торговой компании

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

В результате обсуждения появилась первая версия системы процессов компании. Ее фрагмент представлен на Рис. 3.

Рис. 3. Первая версия системы процессов торговой компании

На рисунке видно, что уровень «подпроцессов» и «операций» не заполнен. Определены только «группы процессов» и «процессы».

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

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

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

Рис. 4. Четвертая версия системы процессов торговой компании

Было принято решения описывать на отдельных листах MS Excel процессы:

1. Центрального офиса (индекс — ЦО);
2. Распределительного центра (индекс — РЦ);
3. Типового универсама (индекс — УН).

Засчет такого решения удалось сократить количество процессных групп на каждом листе MS Excel и уйти от создания в системе «псевдо-процессов». Например, если бы деятельность типового универсама описали в общей системе процессов, то возникла бы процессная группа под названием «Процесс универсама». Фактически, это означало бы, что появлялся лишний, практически ненужный уровень декомпозиции. Кроме того, такое представление системы процессов удобно для согласования — можно согласовывать документ по частям. Заметим, что некоторые специалисты предпочитают создавать систему процессов на одном листе.

Создание системы процессов в Business Studio

После того, как система процессов была создана и согласована в виде файла MS Excel, было принято решение перенести ее в среду моделирования Business Studio. Данные были предварительно обработаны и загружены в Business Studio. Это легко можно сделать путем пакетного импорта из файла MS Excel. Результат (дерево процессов) представлен на Рис. 5.

Рис. 5. Система процессов торговой компании в Business Studio

Были созданы три папки: «Процессы ЦО», «Процессы РЦ» и «Процессы УН». Внутри этих папок процессы имеют 4-уровневую структуру. Четвертый уровень — это уровень операций, выполняемых конкретными сотрудниками подразделений.

На Рис. 6. показан пример описания одного из операционных процессов в нотации «Процедура» Business Studio.

Заметим, что в данном проекте стыковка процессов по входам/выходам в файле MS Excel не осуществлялась. Это решено было делать при последовательном описании и согласовании схем процессов 3 или 4 уровня в Business Studio.

Рис. 6. Описание процессов в нотации «Процедура»

Для того, чтобы можно было моделировать процессы, используя существующие названия подразделений и должностей, в среде Business Studio была описана схема организационной структуры компании. Поскольку она была довольно сложной, пришлось создавать модель на нескольких уровнях (см. Рис. 7 и 8).

Рис. 7. Описание организационной структуры компании в Business Studio

Рис. 8. Описание организационной структуры подразделения компании в Business Studio

После описания ряда пилотных процессов, был разработан отчет, выводящий информацию о процессах в нужном компании виде — «Инструкции по выполнению процесса». Данный документ предназначался для регламентации деятельности конкретных сотрудников компании на операционном уровне.

Заключение

Еще раз обратим внимание на систему процессов в среде моделирования Business Studio, представленную на Рис. 5. Важно, что описание процессов в такой системе можно начинать с третьего или, лучше, с четвертого уровня — там, где есть реальный документооборот. Это означает, что процессы первого и второго уровня вообще можно не описывать! В этом случае исключаются значительные затраты времени на моделирование и согласование «неисполняемых» (в BPMS) и «нерегламентируемых» (слишком общие для этой цели) «процессов» 1 и 2 уровня.

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

Сентябрь 2010 г.

Рекомендуемые материалы по тематике

Карточка бизнес-процесса — инструмент руководителя

Принципы оптимизации бизнес-процессов на основе анализа результатов ФСА-моделирования в системе Business Studio

Электронный репозиторий бизнес-процессов: инвестиция в будущее компании

Конференция «Системная практика управления бизнес-процессами»: вопросы и ответы. Часть 1.

В программе Business studio можно создать модель бизнес процессов в нотации IDF0, декомпозировать бизнес-процессы на более низкий уровень и описать в нотации IDF0, EEPC, BPMN.

IDEF0 — нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

• использование контекстной диаграммы;
• поддержка декомпозиции;
• доминирование;
• выделение 4 типов стрелок.

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

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

Диаграмма, описанная в нотации EPC (событийная цепочка процессов), представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её. В нотации EPC ветвление стрелок осуществляется с использованием операторов (и, или, исключающие или). Диаграмма декомпозируемой функции EPC может быть описана только в нотациях EPC или BPMN 2.0.

На каждый созданный процесс можно сформировать отчет по описанию процесса и его входам и выходам.

№	Процесс	Владелец	Исполнители	Входы	Выходы
Тип	Название	Объекты	Название	Объекты
1.	А1 Создание компании			Вход	Пакет документов	Пакет документов	Договор об аренде помещения	Договор об аренде помещения
Список необходимого оборудования	Список необходимого оборудования	Документы организации	Документы организации
Управление	Договор об аренде помещения	Договор об аренде помещения
Документы для учреждения фирмы	Документы для учреждения фирмы
Шаблон устава	Шаблон устава
Механизм	Администратор_1
Администратор_2
Главный инженер
Директор
Снабженец
Юрист
2.	А2 Привлечение клиентов			Вход	Документы организации	Документы организации	База данных клиентов	База данных клиентов
Управление	Шаблон договора	Шаблон договора	Технические документы	Технические документы
Механизм	Менеджер 2		Требования	Требования
3.	А3 Оформление выставки			Вход	Технические документы	Технические документы	Партнерский договор	Партнерский договор
Требования	Требования	Список партнеров	Список партнеров
Управление	База данных клиентов	База данных клиентов
Договор с клиентом	Договор с клиентом
Свидетельство о регистрации	Свидетельство о регистрации
Шаблон Партнерского договора	Партнерский договор
Механизм
Администратор_1
Дизайнер
Маркетолог 2
4.	А4 Реализация			Вход	Шаблон договора с контрагентом	Шаблон договора с контрагентом	Договор с контрагентом	Договор с контрагентом
Управление	Список партнеров	Список партнеров	Официальное открытие выставки
Механизм	Главный инженер
5.	А5 Завершение проекта			Вход	Официальное открытие выставки		Закрытые документы	Закрытые документы
Управление	Договор с контрагентом	Договор с контрагентом	Отчет о рекламной компании	Отчет о рекламной компании

Входы и выходы процесса

№	Тип	Название	Объекты
1.	Вход	Пакет документов	Пакет документов
Список необходимого оборудования	Список необходимого оборудования
2.	Выход	Договор об аренде помещения	Договор об аренде помещения
Документы организации	Документы организации
3.	Управление	Договор об аренде помещения	Договор об аренде помещения
Документы для учреждения фирмы	Документы для учреждения фирмы
Шаблон устава	Шаблон устава
4.	Механизм	Администратор_1
Администратор_2
Главный инженер
Директор
Снабженец
Юрист

Описание подпроцессов

№	Процесс	Владелец	Исполнители	Входы	Выходы
Тип	Название	Объекты	Название	Объекты
1.	А1.1 Регистрация фирмы			Механизм	Директор		Свидетельство о регистрации	Свидетельство о регистрации
2.	А1.2 Закупка инвентаря			Вход	Список необходимого оборудования	Список необходимого оборудования	Закупленное оборудование	Список необходимого оборудования
Управление	Свидетельство о регистрации	Свидетельство о регистрации	Счета фактуры на оборудование	Счета фактуры на оборудование
Механизм	Администратор_1
3.	А1.3 Поиск помещения			Вход	Закупленное оборудование	Список необходимого оборудования	Договор об аренде помещения	Договор об аренде помещения
Управление	Договор об аренде помещения	Договор об аренде помещения
Счета фактуры на оборудование	Счета фактуры на оборудование
Механизм	Администратор_2

Пример моделей EPC в рамках организации

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

Организационная структура, выполненная в нотации Business studio

После выполнения моделирования бизнес-процессов можно произвести имитацию бизнес-процесса «as is» с помощью функционально-стоимостного анализа и имитационного моделирования средствами bussiness studio 4.1.

Этапы выполнения имитации:

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

Отчет по результатам имитации «as is»

Временные ресурсы

№	Название	Смена	Ставка в час	Среднее время использования	Средняя стоимость использования, руб.
1.	Маркетолог 1	Смена 1	200	руб.
2.	Маркетолог 2
	Сумма	11333,33

Материальные ресурсы

№	Название	Стоимость	Среднее потребляемое количество	Средняя стоимость потребления, руб.
1.	Word	0		1
2.	Акт-передачи	0		1
3.	Заключенный договор на размещение	0		1
4.	Компьютер	0		1
5.	Список необходимого оборудования	0		1
6.	Список необходимых мероприятий	0		1
7.	Шаблон договора на размещение	0		1
	Сумма	0

Произведенные продукты

№	Название	Среднее производимое количество
1.	Акт-передачи	1
2.	Доставка осуществлена	1
3.	Заключенный договор на размещение	1
4.	Регистрация на товарный знак	1
5.	Список материалов для украшения	1
6.	Список необходимого оборудования	1
7.	Список необходимых мероприятий	1
8.	Счета	1

Средние значения времени и стоимости подпроцессов

№	Процесс	Время выполнения	Время ожидания	Время в очереди	Время в ожидании материальных ресурсов	Полное время	Стоимость, руб.
1.	А6.1 Подготовка рекламной продукции	1д. 00:00:00	2:00:00	9д. 06:42:51	0:00:00	10д. 08:42:51	4800
2.	А6.2 Заключение договора на размещение	1д. 00:00:00	2:00:00	7д. 14:30:00	0:00:00	8д. 16:30:00	4800
3.	А6.3 Регистрация товарного занака	1:00:00	3д. 00:00:00	17:15:00	0:00:00	3д. 18:15:00	200
4.	А6.4 Размещение рекламной продукции	2:00:00	3:00:00	4:00:00	0:00:00	9:00:00	400
5.	А6.5 Подготовка списка необходимого оборудования	1:00:00	1д. 00:00:00	0:15:00	0:00:00	1д. 01:15:00	200
6.	А6.6 Осуществление доставки оборудования	0:10:00	4:00:00	8:47:30	0:00:00	12:57:30	3000
7.	А6.7 Осуществление монтажа оборудования	1:00:00	0:30:00	0:12:30	0:00:00	1:42:30	3500
8.	А6.8 Подготовительные работы по отделке помещения	0:40:00	0:10:00	3:45:00	0:00:00	4:35:00	133,33
9.	А6.9 Подготовка необходимого материалы для укращения	1:00:00	0:30:00	0:15:00	0:00:00	1:45:00	200
10.	А6.10 Провести закупку метериалов	3:00:00	2:00:00	4:00:00	0:00:00	9:00:00	600
11.	А6.11 Украсить помещение	1:00:00	0:30:00	11:00:00	0:00:00	12:30:00	200

Средние затраты времени и стоимости экземпляров подпроцессов на выполнение экземпляра процесса

№	Процесс	Частота в рамках вышележ.	Время выполнения	Время ожидания	Время в очереди	Время в ожидании материальных ресурсов	Полное время	Стоимость, руб.
1.	А6.1 Подготовка рекламной продукции	1	1д. 00:00:00	2:00:00	9д. 06:42:51	0:00:00	10д. 08:42:51	4800
2.	А6.2 Заключение договора на размещение	1	1д. 00:00:00	2:00:00	7д. 14:30:00	0:00:00	8д. 16:30:00	4800
3.	А6.3 Регистрация товарного занака	1	1:00:00	3д. 00:00:00	17:15:00	0:00:00	3д. 18:15:00	200
4.	А6.4 Размещение рекламной продукции	1	2:00:00	3:00:00	4:00:00	0:00:00	9:00:00	400
5.	А6.5 Подготовка списка необходимого оборудования	1	1:00:00	1д. 00:00:00	0:15:00	0:00:00	1д. 01:15:00	200
6.	А6.6 Осуществление доставки оборудования	1	0:10:00	4:00:00	8:47:30	0:00:00	12:57:30	3000
7.	А6.7 Осуществление монтажа оборудования	1	1:00:00	0:30:00	0:12:30	0:00:00	1:42:30	3500
8.	А6.8 Подготовительные работы по отделке помещения	1	0:40:00	0:10:00	3:45:00	0:00:00	4:35:00	133,33
9.	А6.9 Подготовка необходимого материалы для укращения	1	1:00:00	0:30:00	0:15:00	0:00:00	1:45:00	200
10.	А6.10 Провести закупку метериалов	1	3:00:00	2:00:00	4:00:00	0:00:00	9:00:00	600
11.	А6.11 Украсить помещение	1	1:00:00	0:30:00	11:00:00	0:00:00	12:30:00	200
	Сумма

Экземпляры процесса

Количество запущенных экземпляров	22
Количество завершенных экземпляров	4
Количество незавершенных экземпляров	18
Среднее количество запусков в день	0,724
Среднее количество завершенных экземпляров в день	0,132

Результат: количество экземпляров равно 22, завершенных равно 4, незавершенных равно 18, среднее количество запусков в день равно 0,724, среднее завершенных экземпляров в день равно 0, 132.

Матрица ответственности

№№	Наименование процесса/процедуры	Менеджер 1	Менеджер 2	Владелец БП	Зам. директора
БП1	Бизнес-процесс «Реализация»	О	О	В	И
Пр1.1	Подготовка рекламной продукции	У	У	И	К
Пр1.2	Подготовительные работы по отделке помещения	У	У	И	К
Пр1.3	Заключение договора на размещение	У	У	И	К
Пр1.4	Регистрация товарного знака	У	У	И	К
Пр1.5	Подготовка необходимых материалов для украшения	У	У	И	К
Пр1.6	Размещение рекламной продукции	У	У	И	К
Пр1.7	Провести закупку материалов	У	У	И	К
Пр1.8	Украсить помещение	У	У	И	К
Пр1.9	Подготовить список необходимого оборудования	У	У	И	К
Пр1.10	Осуществление доставки оборудования	У	У	И	К
Пр1.11	Осуществление монтажа оборудования	У	У	И	К

Сводная ведомость отчетной информации

Наименование отчета	Менеджер 1	Менеджер 2	Владелец БП
Акт передачи	ежемесячно
Отчет о доставке		ежемесячно	еженедельно

Взаимодействие с другими процессами

	Реализация
Получает информацию	Передает информацию
Бизнес – процесс «Оформление выставки»	Заключенный партнерский договор	Заключенный договор на размещение Регистрация товарного знака Акт передачи Отчет о доставке
Бизнес-процесс «Завершение проекта»	Акт передачи и тд	Подписанные акты

В процессе to be «Привлечение клиентов» клиентов стало равно 12, что на 4 больше чем в «as is». Количество привлеченных клиентов увеличилось на 4 (по сравнению с показателем до оптимизации бизнес-процесса). Количество сделанных сайтов увеличилось на 4, количество заработанных денег увеличилось на 160 тысяч рублей. В среднем привлеченный клиент оплачивает услуги на 40 тысяч рублей, до оптимизации у нас было 8 клиентов, которые оплатили услуги на 320 тысяч рублей, сейчас этот показатель ровняется 480 тысяч рублей.

Метки: business studio

В статье Владимира Репина рассмотрены функциональные возможности по использованию программных продуктов при создании моделей бизнес-процессов в нотации BPMN в Business Studio 5. Обсуждаются преимущества и недостатки представленных способов. Материал может быть полезен при разработке Соглашения (стандарта) по моделированию бизнес-процессов вашей организации.

Зачем моделировать программные продукты в Business Studio?

В статье речь пойдет об использовании объектов справочника «Программные продукты» в моделях бизнес-процессов в нотации BPMN в Business Studio 5. Например, можно для каждой операции процесса указывать конкретный программный продукт, который используется при ее выполнении. Программные продукты являются элементами общей модели организации и хранятся в соответствующем разделе более общего справочника «Объекты деятельности».

Для чего нужна информация о программных продуктах на схемах типа Work Flow (eEPC, BPMN)? Конечно, в модели такого типа нас интересует, прежде всего, корректный (без логических ошибок) алгоритм выполнения процесса. Движение документов на схеме, взаимодействие по входам-выходам с другими процессами, описание используемого программного обеспечения, рисков и прочих объектов делают из графической схемы модель бизнес-процесса. Это дает нам возможность выполнять анализ процесса «как есть», находить проблемы и выявлять их причины, определять потенциал повышения эффективности процесса за счет реализации ряда мероприятий.

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

Формирование структуры программных продуктов в справочнике

В Business Studio 5 можно создать структуру используемых в компании программных продуктов в справочнике «Объекты деятельности/Программные продукты». На рис. 1 показан пример структуры программных продуктов компании.

В начале создается объект справочника «Информационная система», например «1С». Затем для нее может быть добавлен «Модуль ИС», например «1С: Бухгалтерия». Далее, при необходимости, внутри модуля можно создать «Функцию ИС». В целом, группировка по модулям и функциям может быть многоуровневая.

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

Три способа использования программах продуктов на схеме процесса в нотации BPMN

Способ № 1. Привязка через интерфейс

Рассмотрим три основных способа использования программных продуктов в моделях бизнес-процессов в нотации BPMN. На рис. 2 показана схема процесса (учебный пример). По правой кнопке открыты «Свойства» операции «Собрать информацию». Из справочника программных продуктов в список «Программные продукты» перетянут мышкой продукт «MS Word».

Далее нужно выбрать тип связи программного продукта и операции процесса. Можно использовать два типа связей: «поддерживает» и «выполняет» (вы можете создать любой новый тип связи при необходимости). Какой из них выбрать?

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

При использовании типа связи важно принять решение, в каких случаях она может использоваться, и четко закрепить эти требования, например в Соглашении по моделированию.
Тип связи «поддерживает» можно, например, интерпретировать следующим образом. Привязка программного продукта к операции с этим типом связи означает, что:

1. операция выполняется сотрудником, и при этом:
2. какие-то действия выполняются сотрудником в соответствующей информационной системе.

Тип связи «выполняет» можно интерпретировать следующим образом:

1. операция выполняется полностью автоматически в соответствующей информационной системе.

Действительно, что значит, что программное обеспечение что-то «выполняет»? Может ли MS Word что-то «выполнять» сам без участия человека? С моей точки зрения, нет. А вот например, антивирусная система может приступить к проверке автоматически, по расписанию, без участия человека. В этом случае операция «Проверить РС на вирусы» будет полностью автоматический и будет «выполняться» соответствующей информационной системой.

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

Способ № 2. Визуализация на схеме

Программные продукты можно просто перетаскивать мышкой на схему процесса в виде фигуры. Но чтобы это сделать, в Business Studio 5 сначала нужно выбрать тип фигуры. При открытой схеме процесса надо выбрать мышкой программные продукты в палитре элементов и нажать правую кнопку. Далее поставить галочку напротив «Фигура», как показано на рис. 3. После этого можно перетаскивать программные продукты из справочника на диаграмму.

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

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

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

Более глубокий анализ указанных проблем дает возможность обосновать мероприятия по улучшению процесса и внедрению новых информационных систем, например iBPMS+RPA вместо тяжеловесной, неудобной и устаревшей СЭД.

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

Как быть в случае, если операция выполняется полностью автоматически? На рис. 6 показан один из допустимых вариантов. Можно одновременно использовать маркер автоматического выполнения («вызов внешней функции или сервиса») и тип связи «выполняет». По типу связи вы всегда сможете отфильтровать все операции процессов, выполняемые автоматически. Кстати, в Business Studio 5 можно настраивать визуализацию параметров для стрелок, используемых в модели. Это удобно.

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

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

Способ № 3. Представление в виде отдельной дорожки

В Business Studio 5 появилась возможность использовать программное обеспечение в качестве дорожки на схеме в нотации BPNN. На рис. 7 показана измененная схема процесса, на которой модуль «FI-CO» показан в виде дорожки. Дополнительно для наглядности использован маркер автоматического выполнения операции.
Обратите внимание, что тип связи программного обеспечения с операцией процесса – «выполняет». Таким образом, можно визуально показывать программное обеспечение в качестве полноценного участника процесса.

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

Хотя, возможно, это будет удобно для описания алгоритмов выполнения процессов, полностью автоматизированных в различных системах: веб-сервисы, BPMS, RPA, ERP.

Преимущества и недостатки методов представления программных продуктов в моделях процессов в нотации BPMN

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

Критерии сравнения	Метод 1. Привязка через интерфейс	Метод 2. Визуализация на схеме	Метод 3. Представление в виде отдельной дорожки
Полнота	«-» Невозможно вывести объект на показ на схеме. При последующей визуализации (вручную) на схеме возникает дублирование объектов в списке	«+» При визуальной привязке объект автоматически попадает в список «Программные продукты» для операции.	«+» Объект автоматически попадает в список «Программные продукты» для операции. Нет дублирования.
Возможность визуального анализа	«-» Отсутствует	«+» Есть.	«+» Есть.
Наглядность и удобство визуального анализа	«-» Отсутствует	«+» Есть. Наглядно и понятно.	«-+» Есть, риск усложнения схемы за счет создания дополнительных дорожек
Возможность формирования аналитических отчетов	«+» Есть.	«+» Есть.	«+» Есть.

Мы рассмотрели различные подходы к моделированию программных продуктов на схемах бизнес-процессов в нотации BPMN в Business Studio 5.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»

Январь 2021 г.

Александр Климчук
к.т.н., доцент, начальник отдела бизнес-администрирования банка «Кредит-Днепр» (Украина)
mail@klimchuk.info

Статья описывает опыт построения моделей бизнес-процессов деятельности банка в «Бизнес-Студии». Акцент сделан на сложных моментах работы программы и «подводных камнях». Приведены рекомендации по проверке модели с использованием матрицы ответственности и матрицы документооборота. Статья будет полезна практикам, занятым моделированием бизнес-процессов в банке и не только.

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

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

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

Недавно я познакомился с оригинальной концепцией, предложенной А.Лебедевым (промышленный дизайн). Концепция называется «Метод прогрессивного джипега».

Автор описал его очень просто «В любую секунду любой проект готов на 100%, хотя проработанность может быть и на 4%». Давайте порассуждаем, что будет, если применить эту концепцию к моделированию бизнес-процессов. В любую секунду модель бизнес-процессов компании готова на 100% (иначе бы компания не работала), но формализована модель может быть и на 4% (просто представление об устройстве бизнеса в голове у его собственника, который «пинками» заставляет сотрудников делать бизнес).

Рассуждая о бизнес-процессах и процессном управлении нельзя не упомянуть таких почтенных авторов, как П.Друкер и М.Хаммер. Десяток и более лет назад в своих трудах они готовили нас к мысли, что скоро закончиться пора «правильных решений» для бизнеса. Наступит пора «правильных систем» в бизнесе, которые способны генерировать эти правильные решения по мере поступления информации (или при ее отсутствии). Как раз бизнес-процессы – это инструмент построения таких «правильных систем».

Вернемся к рассматриваемой программе. Программа «Бизнес-Студия» — это инструмент формализации бизнес-процессов. Поэтому необходимость данной программы определяется как раз необходимой степенью проработки картинки (в терминологии А.Лебедева). Как определить, какая формализация бизнес-процессов требуется коммерческому банку? Наши коллеги из Ассоциации российских банков предложили т.н. шкалу зрелости бизнес-процессов банка. Шкала предусматривает следующие состояния бизнес-процессов банка:

0. «Нулевой» (процессы управления не применяются)
1. «Начальный»(процессы специализированы и не организованны)
2. «Повторяемый» (процессы повторяются на регулярном основании)
3. «Определенный» (процессы документированы взаимосвязаны)
4. «Управляемый» (процессы наблюдаются и измеряются)
5. «Оптимизированный» (процессы соответствуют «лучшей практике» и автоматизированы)

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

Сразу оговорюсь, утверждать, что устройство бизнеса совсем не документировано в большинстве банков я не берусь. Естественно – где-то есть должностные инструкции и положения о подразделениях. Банковские продукты утверждаются в виде решений правления банка и т.д. Но вся беда в отсутствии системы. Даже самая простая задача – найти актуальную версию документа может оказаться не решаемой сходу (ее кто-то видел, но где точно уже забыл). Если же говорить об описании не функций, а связанных бизнес-процессов – тот тут картина еще печальнее. Возможно, когда-то в банк приглашали консультантов и те создавали модели, возможно руководство банка на выездных стратегических комитетах само пыталось изобразить эталонную модель бизнеса. Но как показывает практика, в большинстве своем в банках процессы не документированы.

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

Не последнюю роль при выборе программы «Бизнес-Студия» для нас сыграла серия статей Р.Исаева о типовой модели бизнес-процессов для коммерческого банка. Тем не менее, мы решили не применять предлагаемую универсальную модель и сконцентрировать усилия на разработке собственного решения.

До прихода в банк наша команда имела многолетний опыт работ с бизнес-процессами в различных отраслях. Чем отличается банк от других отраслей с т.з. формализации бизнес- процессов? Тем, что в условиях банка процессное управление приживается более органично в силу природы банковского бизнеса. Банк не терпит хаоса и неконтролируемого творчества. Банк имеет жёсткие ограничения со стороны национальных и международных институтов. В банке значительное влияние имеет служба безопасности, для которой обычным делом является установление правил и процедур. Но, тем не менее, формализация и регламентация бизнес- процессов – это не лекарство от неэффективных процессов в банке. Более того – это тонкая система, которая сможет выжить лишь в достаточно высокой культуре менеджмента.

Давайте возьмём некий гипотетический бизнес-процесс из банковской деятельности и рассмотрим, где для него будет полезным применение инструментария моделирования бизнес- процессов. Пусть это будет бизнес-процесс предоставления банковского продукта. См. рис. 1.

На стадии концептуального проектирования продукта применять инструментарий для моделирования бизнес-процессов еще рано. Тут на первое место выходит творчество, маркетинг и экономика в сочетании с риск-анализом. На стадии, когда продукт уже реализуется клиентам банка, применение инструментов моделирования бизнес-процессов уже не нужно, поскольку необходимо стимулирование сотрудников, контроль, планирование и автоматизация их деятельности. А вот как раз на стадии перехода от концепции до практики инструментарий моделирования бизнес-процессов востребован в наибольшей степени.

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

Чтобы показать особенности, преимущества и недостатки «Бизнес-Студии» нам необходимо с чем-то сравнить данный продукт. Мы предлагаем следующих конкурентов:

• карандаш и бумага;
• MS Word и MS Excel;
• BPwin;
• MS Visio.

Инструменты, не представленные в списке, были дисквалифицированы по причине неудобства работы, высокой стоимости, не поддержки необходимых стандартов моделирования или низкой популярности. В результате сравнения «Бизнес-Студии» с перечисленными конкурентами мы выделили три слова: «много», «медленно» и «не интуитивно» (см. рис. 2).

Далее приведены обоснования этим трем характеристикам программы.

Характеристика. Много

Чего же много в программе? Мы выделяем 5 значений слова «много» для программы «Бизнес- Студия»:

1. много меню;
2. много стандартов;
3. много справочников;
4. много отчетов;
5. много дополнительных модулей.

Много меню. Меню есть слева и меню есть сверху. Непродолжительная работа с программой позволяет определить, что меню справа означает набор элементов для построения модели бизнес-процессов. Причем элементы можно создавать как в самом меню, так и на диаграммах процессов. А меню сверху – это в большинстве своём действия, которые можно сделать с моделью процессов. Например – сформировать отчет. См. рис. 3.

Много стандартов. «Бизнес-Студии» конечно далеко до “ARIS”, но выбор тоже широк. См. рис. 4.

Давайте рассмотрим предлагаемый программой набор стандартов.

IDEF0. Тут комментарии излишни. Этот стандарт был, есть и будет «рабочей лошадкой» для системного анализа бизнеса.

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

Стандарт EPC. В нашей практике данный стандарт не прижился. Чтобы не повторяться – причины этого достаточно аргументированно изложены также В.Репиным.

Если рассматривать перечень предлагаемых стандартов – нам кажется что не хватает стандарта VAD (Value Added Diagram – диаграммы создания ценности). Этот стандарт очень хорош для концептуальной прорисовки бизнеса, для определения групп бизнес-процессов: основных, управляющих и вспомогательных. За счет минимизации объектов и стрелок между ними очень удобно сконцентрировать внимание на главные аспекты бизнеса.

Много справочников. BPwin использует два основных справочника: процессы и стрелки (дуги). Есть еще справочники внешних ссылок и т.п. – но они используются редко. «Бизнес-Студия» предлагает намного больше справочников. Чтобы их рассмотреть – достаточно развернуть группы в меню, находящимся в левой части экрана.

Хорошо это или плохо? Ответить сложно. С одной стороны – это структурирует мысли и позволяет постепенно «навешивать» на модель необходимые объекты. Но с другой стороны – это может быть ограничением. Например, мы около недели настраивали справочник «термины» для того, чтобы можно было связать бизнес-процесс со специфическими терминами из справочника и автоматически формировать раздел «термины» в регламенте процесса. Причина – изначально данный справочник предназначался для отражения различных статусов документов в системе СМК. Кто бы мог подумать? 🙂

Хорошая новость заключается в том, что мы всегда можем использовать три основных справочника, которые дают ответы на ключевые вопросы о бизнес-процессе: что делаем? Кто делает? И где отражается результат? См. рис. 5.

Много отчетов. Только что установленная программа содержит в себе довольно внушительный набор стандартных отчетов. Они сгруппированы по разным категориям. Довольно тяжело сориентироваться, что и зачем может понадобиться. См. рис. 6.

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

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

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

• СМК (система менеджмента качества);
• ССП (система сбалансированных показателей);
• ФСА (функционально-стоимостной анализ).

Насколько эти модули полезны – вопрос спорный. Автор не знаком с примерами их эффективного использования. Но с точки зрения маркетинга – это бесспорно добавляет баллов программе.

Характеристика. Медленно

Я считаю неправильным, когда программа думает дольше, чем человек (особенно, если от программы требуется простое очевидное действие, например – нарисовать стрелку или передвинуть блок). Так вот, «Бизнес-студия» думает медленнее человека и медленнее его движений мышкой. С эти придется мириться. BPwin работает рамного быстрее. Рисовать карандашом на бумаге намного быстрее. MS Visio будет откликаться намного быстрее.

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

Медлительность программы объясняется выбранными разработчиками технологиями:

• графический «движок» от MS Visio – программы даже самой по себе не очень проворной, а тут еще сверху на нее нагрузили логический блок бизнес-конструктора;
• хранение данных на SQL сервере; технология несомненно современная и полезная, но оправдывает она себя в полной мере только при групповой работе; часто встречается ситуация, когда серьезно моделированием бизнес-процессов занимается много и одновременно сотрудников? Я таких ситуаций не встречал.

Характеристика. Не интуитивно.

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

На диаграммах нет участников процесса. Второй неожиданностью было то, что стандарт IDEF0 был лишен одного из главных своих достоинств – наглядного отображения участников процесса (владельца и исполнителей). Вернее — их можно отобразить, но для формирования отчетов будут использованы данные, которые записаны как свойства бизнес-процесса и не видны на диаграмме. См. рис. 8.

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

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

Модель храниться не в файле. Поработав какое-то время с программой, вы неизбежно захотите сохранить результаты своего труда. Тут вас ожидает сюрприз. В привычном меню «Файл» нет строки «Сохранить». См. рис. 9.

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

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

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

Единственная недоработка – контекстное меню нельзя вызвать на диаграмме. Можно вызвать только из навигатора. См. рис. 10.

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

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

Объяснение было очень простым. В каждом отчете есть динамическая составляющая (что показывать) и статичная составляющая (как и где показывать). Вторую составляющую тоже придется настраивать. Настройка выполняется в шаблоне MS Excel или MS Word (в зависимости – что вы выберете). См. рис. 11.

Не обошлось без досадных недоработок. Например, вы не сможете в регламенте бизнес-процесса (который естественно вы захотите видеть в MS Word) размесить матрицу ответственности. Матрицы программа «Бизнес-студия» имеет без ошибок формировать только в MS Excel. Данный факт подтвердили разработчики и пообещали в будущем устранить.

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

Выводы

Несмотря на то, что изложение получилось в критических тонах, хочу однозначно сказать – программа «Бизнес-Студия» может быть полезна для банка. И в первую очередь — для автоматизации формирования регламентирующей документации. Никто не говорил, что это просто сделать 🙂 Но как раз об этом я хочу поделиться в следующих статьях.

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

Если вы делаете только первые шаги в области описания и управления бизнес-процессами – используйте более простые и понятные программы. Я бы советовал начать даже просто с карандаша и бумаги. Когда вы достигнете первых успехов и признания у собственников (высшего руководства) бизнеса – переходите на MS Visio и BPwin. И только когда ваш бизнес осознает необходимость построения системы управления с ориентацией на бизнес-процессы – задумайтесь о приобретении «Бизнес-Студии».

Business Studio. Основные объекты программы

Разноцветные панели инструментов и большие распахивающиеся меню: как из этого сделать полезную модель? Что использовать сразу, а что – потом? От чего стоит отказаться? Какой алгоритм разработки модели лучше?

2.1. Перед тем, как сесть за компьютер

Перед тем как начать строить модель бизнес-процессов банка задайте себе вопрос ЗАЧЕМ?

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

Главное правило: от того что мы просто нарисует бизнес-процесс ничего не измениться. Более того, после того, что мы нарисуем улучшенную модель бизнес-процесса – тоже ничего не измениться. Модель процесса – это всего лишь инструмент.

Как ни банально бы звучали рекомендации методики SADT4 [1], тем не менее – за все время существования процессного менеджмента не было предложено ничего лучшего. Эта методика предлагает перед началом моделирования определиться со следующим:

• Зачем создается модель бизнес-процесса (цель)?
• С какой позиции мы описываем бизнес-процесс (точка зрения)?
• Где начинается и где заканчивается моделируемый бизнес-процесс (охват)?

Ответы на эти вопросы крайне желательно формулировать перед началом моделирования бизнес-процесса. Это избавит вас от потери времени на исправления модели. См. рис. 2.1.

В банковской практике набор целей довольно предсказуем и мы из своей практики может предложить следующий «топ 5» таких целей:

1. определение зон ответственности (например, кто из подразделений в банке ответственный за работу с проблемными кредитами: только юристы и безопасность или бизнес-подразделения также должны принимать участие в «обработке» клиента);

2. сокращение времени принятия решения по кредитной заявке;

3. автоматизация создания и обновления регламентирующих документов;

4. формирование технического задания на автоматизацию бизнес-процессов;

5. разработка системы стимулирования сотрудников, основанная на их вкладе в прибыльность деятельности банка.

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

• проанализировать текущее состояние процесса (в виде его модели или просто схем);
• обозначить ключевые проблемы бизнес-процесса (очень удобно использовать симпатичную диаграмму «скелет рыбы»);
• зафиксировать ключевые требования к будущей модели процесса.

Заручившись поддержкой руководства банка можно приступать к моделированию бизнес- процесса.

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

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

У каждого варианты есть «+» и «-», о них много уже было написано (например — [2]), поэтому останавливаться на данном вопросе не буду. Хочу лишь предостеречь от распространенной ошибки, когда моделирование поручают неким «smart – специалистам» параллельно с их повседневным функционалом. Из этого нечего хорошего не выйдет! Как минимум из-за того, что у этих сотрудников не будет достаточных полномочий для проведения работ и повседневная «текучка» рано или поздно заставит их отложить моделирование в долгий ящик.

Если в банке уже принято решение моделировать процессы, и решено делать это собственными силами – выделите для этого отдельных сотрудников, которое не будут выполнять другие функции. Для банка средних размеров (2000-3000 тыс. сотрудников) достаточно 3-4 таких специалиста. Более того, при наличии специализированного подразделения для моделирования бизнес-процессов целесообразно создавать временные проектные группы из участников моделируемого процесса. Это обеспечит поддержку работ ресурсами и упростит доступ к информации о выполнении процесса.

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

И последнее, что хочу отметить перед тем как прейти к описанию моделирования процессов в «Бизнес-Студии»: как быть с общей моделью процессов? В данном случае под общей моделью процессов мы понимаем схему, на которой обозначены все процессы банка. Такую схему традиционно называют «ландшафтом бизнес-процессов».

В литературе описано два мнения относительно общей модели бизнес-процессов: «нужна» и «не нужна». Мы считаем, что всё-таки «нужна» и вот почему. При описании процессов всегда используется принцип приоритетности: наиболее важным процессам мы посвятим время сейчас, а менее важным – после. Но при последовательном описании и оптимизации процессов может сложиться ситуация, когда новая модель процесса будет включать в себя элементы, которые уже отражены в других моделях (например, мы занялись процессом «валютный контроль», но элементы этого процесса уже описали в процессах привлечения депозитов и выдачи кредитов) или останутся сферы деятельности – не описанные ни в одном процессе («пробелы»). Чтобы избежать перечисленных ситуаций – как раз и нужен ландшафт бизнес-процессов.

Но ландшафт должен быть простым. Тут мы полностью согласны с мнением В.Репина [3] по поводу увеличения сложности модели по мере углубления декомпозиции. Критерию простоты соответствует стандарт моделирования VAD. Но, к сожалению, данный стандарт не присутствует в программе «Бизнес-Студия». Компенсировать данный недостаток мы предлагаем за счет использования структуры процессов в навигаторе программы.

2.2. Исследуем строительные материалы

Давайте ответим на вопрос: что должна содержать в себе хорошая модель бизнес-процесса банка? Первый раз, начав заниматься моделированием бизнес-процессов в банке (около 5 лет назад), я для себя отметил приятную новость: в банке не нужно моделировать материальные потоки!

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

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

И наконец, последней приятной новость есть традиционно высокая степень автоматизации деятельности банка. Естественно, описать поведение программы гораздо проще, чем поведение человека.

Что же нам предлагает «Бизнес-Студия» в качестве строительных материалов для создания модели процессов? Все строительные «кубики» можно свести по назначению в четыре группы (см. рис. 2.2):

• Что делаем? (перечень процессов);
• Кто делает? (перечень участников процессов);
• Где отражаются результаты работы? (перечень документов);
• При помощи чего делаем работу? (программные продукты);
• Описание терминов – слов, которые неоднозначно могут быть поняты читателями диаграмм.

Все необходимые элементы для построения модели находятся в левой части окна программы. См. рис. 2.3.

Прочие элементы, предлагаемые «Бизнес-Студией», не следует использовать на первых стадиях построения модели. Давайте, к примеру, рассмотрим такой элемент, как информация. Что такое информация в банке? Это устный разговор, это мысли сотрудника, это слухи о личной жизни руководителя? Если информация представляет интерес для бизнеса банка – она должна быть зафиксирована в документе. Если этого не сделано – значит это не важно. См. рис. 2.4.

Давайте рассмотрим характеристики перечисленных строительных элементов модели бизнес- процессов.

Стандарты моделирования бизнес-процессов, которые предлагает «Бизнес-Студия» делятся на две группы: структурные и временные. См. рис. 2.5.

Основное отличие структурных и временных (их еще называют “Work Flow”) стандартов состоит в назначении стрелки между процессами. В структурных стандартах стрелка означает поток ресурсов (документы, материалы), для временных стандартах стрелка означает последовательность выполнения бизнес-процесса. Еще одним дополнением последней группы стандартов является возможность описания логических конструкций (например: если кредит небольшой – простой круг согласования, если кредит большой – сложное согласование).

Из перечисленных стандартов мы рекомендуем использовать два: IDEF0 и «Процедура». IDEF0 хорошо справляется для моделирования бизнес-процессов на верхнем уровне [6]. Процедура является вариантом хорошо всем известной блок-схемы, дополненной вертикальными или горизонтальными полосами, отражающими исполнителей процессов. Этот стандарт хорош для моделирования бизнес-процессов на нижних уровнях [7].

Мы уже затрагивали вопрос: как быть с ландшафтом бизнес-процессов? Мы предлагаем реализовать ландшафт в виде структуры папок процессов в «Бизнес-Студии». Делается это так. Сначала создадим папку, где будет храниться вся наша модель. См. рис. 2.6.

Внутри созданной папки создадим три папки для каждого вида процессов: основных, управления и вспомогательных. См. рис. 2.7.

Внутри каждой папки мы будем хранить модели бизнес-процессов соответствующих видов.

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

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

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

• выполняет бизнес-процесс;
• является владельцем бизнес-процесса.

Следующий элемент модели – это документы. Тут я хочу отметить две важные особенности. Первая заключается в том, что программа «Бизнес-Студия» предлагает нам разделить все документы на две группы: электронные и бумажные. Вторая особенность заключается в возможности связать наименование документа в программе с его электронным аналогом. Это удобная возможность, например если необходимо утвердить шаблон оформления того или иного документа. Рассмотрим подробнее эти две особенности использования документов.

По поводу необходимости классифицировать документы на электронные и бумажные. Какой документ электронный в организации, а какой — бумажный? Я однозначного ответа дать не могу.

Любой документ имеет электронную форму (в базе данных учетной системы или в виде «вордовского» файла приказа), в тоже время любой документ можно распечатать и получить его бумажную версию. Поэтому по нашему мнению данная классификация только запутывает пользователей. См. рис. 2.10.

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

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

Хотим еще обратить внимание на интересную концепцию, которую использовали разработчики программы — т.н. концепцию объектов стрелок. Простыми словами: мы можем назвать стрелку как угодно, но в ее свойствах (невидимых на диаграмме) указать, что именно она означает. Т.о. некий аналитик может увидеть на диаграмме стрелку с названием «информация от потенциального заемщика банка» и решить, что дело идет об устной информации, которую клиент рассказал о своих потребностях. Но на самом деле может оказаться, что автор модели глубоко в свойствах модели указал, что она означает весь перечень документов, передаваемых клиентом для заключения кредитного договора: копию паспорта, справки о доходах и т.п. См. рис. 2.11.

Сложностей не возникает, если мы перетаскиваем стрелку из справочника документов. В этом случае и наименование стрелки и наименование объекта совпадают.

2.3. Строим модель

Мы уже выяснили, какие элементы предлагает «Бизнес-Студия» для построения модели процесса и какие стандарты мы можем использовать. Теперь рассмотрим последовательность действий при построении модели бизнес-процесса.

Главное что нужно помнить при построении модели процесса – в результате модель должна давать ответ на некий вопрос. Модель должна быть полезна.

Мы предлагаем использовать такую последовательность стандартов описания бизнес-процесса (см. рис. 2.12):

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

Создавать диаграммы бизнес-процессов в стандарте IDEF0 мы рекомендуем такой последовательности:

1. определение перечня подпроцессов;
2. определение их доминирования (последовательности);
3. определение исполнителей и владельцев;
4. определение основных результатов подпроцессов (документов);
5. связывание подпроцессов по выходам-входам;
6. отображение прочих документов на диаграмме;
7. указать информационные потоки между подпроцессами (при необходимости).

Создание диаграмм бизнес-процессов в стандарте «процедура» рекомендуется проводить в такой последовательности:

1. указать начальное и конечное событие процесса;
2. обозначить точки принятия решений (объект – «проверка условия»);
3. указать перечень подпроцессов;
4. обозначить временную последовательность подпроцессов;
5. указать документальные потоки между подпроцессами;
6. указать информационные потоки между подпроцессами (при необходимости).

Примеры диаграмм бизнес-процесса кредитования в стандарте IDEF0 и «процедура» приведены на рисунках 2.13 и 2.14 соответственно.

Как вы могли заметить, диаграмма IDEF0 в «Бизнес-Студии» имеет необычный вид. Она лишилась верхнего колонтитула. См. рис. 2.15.

Почему так произошло? Немного изучив программу Visio можно найти ответ. В самой программе именно таков шаблон диаграммы IDEF0. Почему выбран такой шаблон, несмотря на другие рекомендации стандарта [6] – сказать не берусь.

Что теряется вместе с верхним колонтитулом? автор модели, название модели, название проекта, в рамках которого она была разработана, даты создания и последнего обновления модели, схема верхнего уровня. На наш взгляд потерь слишком много, чтобы оправдать их стремлением к упрощению жизни программистам. См. рис. 2.16.

Хотим подробнее остановиться на вопросе отражения сотрудников в модели процессов.

Как мы отметили ранее, мы считаем, что для работы вполне достаточно описать два типа участия субъекта в процессе: владелец и исполнитель. Программа «Бизнес-Студия» предлагает нам 4 типа субъекта: должность, подразделение, роль и внешний субъект. В результате мы получаем следующие возможные сочетания «процесс – субъект», см. рис. 2.17.

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

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

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

Еще одной особенностью программы «Бизнес-Студия» является необходимость в стандарте IDEF0 отражать участников процесса и в виде стрелок и в свойствах самих процессах. Об этом недостатке мы говорили в первой статье цикла. Если вы укажите участников процесса только в виде стрелок – вы не сможете полноценно формировать регламентирующие документы. См. рис. 2.19.

Также будьте готовы к тому, что при переходе от диаграммы к диаграмме программы будет вас настойчиво спрашивать о необходимости сохранения изменений на текущей диаграмме. Тут есть один подвох. Если вы запустите формирование отчета и при этом не сохраните последние изменения на диаграмме, с которой вы работали в последнее время – есть шанс потерять последние изменения. Поэтому мы советуем вам перед формированием отчета сохранять изменения в диаграммах:

Не могу не отметить потерю очень удобного и полюбившегося многим инструмента декомпозиции – автоматического создания нужного количества блоков на диаграмме декомпозиции. Коллеги, которые активно занимались созданием диаграмм IDEF 0, надеюсь со мной согласятся, что данный инструмент в IDEF0 значительно упрощал работу. При создании же декомпозиции в «Бизнес-Студии» мы получаем сиротливый прямоугольник на пустом экране. См. рис. 2.21.

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

И последнее, что мы хотим отметить по поводу особенностей моделирования бизнес-процессов в программе «Бизнес-Студия». Особенность касается копирования процессов на диаграмме. Если вы с помощью контекстного меню скопируете блок на диаграмме, а затем вставите его на этой или другой диаграмме – вы создадите не новый подпроцесс, а всего лишь экземпляр существующего процесса. При изменении одного экземпляра процесса будут меняться и прочие экземпляры процесса. См. рис. 2.23.

2.4. Проверка модели

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

Для первичной проверки модели бизнес-процесса мы рекомендуем использовать три метода, см. рис. 2.24.

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

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

Нам понадобятся отчеты двух видов: матрица ответственности и матрица документооборота.

Матрица ответственности показывает связь между процессами и субъектами модели. На пересечении строк и столбцов указывается тип связи. Как мы уже говорили – мы рекомендуем использовать только два типа связи: владелец и исполнитель.

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

Схематически матрицы ответственности и документооборота показаны на рисунке 2.25.

По поводу матриц ответственности и документооборота у нас есть две новости: хорошая и плохая:

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

Как быстро обойти все «подводные камни» программы и построить эти два отчета мы опишем ниже. Первое, что нам бросилось в глаза – в навигаторе программы мы не нашли отчетов. См. рис. 2.26.

Искать отчеты нужно в меню «Отчеты». Зачем разработчики допустили такую путаницу – для нас осталось загадкой.

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

Первая неприятность, которая вас подстерегает с отчетами: они корректно могут формироваться только в MS Excel. Несмотря на то, что программа предложит вам выбрать также формат MS Word – не верьте этому! Матричные отчеты в версии «Бизнес-Студии» 3.5 включительно формироваться не могут.

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

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

Аналогично следует поступать при выборе места хранения фильтров, используемых при работе ответа. См. рис. 2.30.

Другая особенность формирования матриц – не следует сразу выбирать формат «шахматка». Выберите сначала формат «таблица», а затем в свойствах отчета сменить тип. У нас ни разу не получилось построить отчет изначально выбрав его тип «шахматка». См. рис. 2.31.

Давайте рассмотрим поочередно алгоритм создания отчета «Матрица ответственности» и «Матрица документооборота».

Для формирования матрицы ответственности нам необходим перечень подпроцессов, начиная с процесса, от которого мы вызываем отчет, а также заполненная таблица «Субъекты» подпроцесса. В таблице должен быть указан и владелец и исполнитель (исполнители) процесса. См. рис. 2.32.

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

Алгоритм создания отчета «Матрица ответственности» следующий:

1. создаем новый отчет в формате «список»;
2. выбираем привязку «Упорядоченный список процессов с корнем»;
3. внутри привязки выбираем первое свойство «Название процесса»;
4. вторым свойством выбираем вложенную привязку «Процесс.Субъекты»;
5. внутри вложенной привязки выбираем свойства «Субъект» и «Тип связи. Сокращение»;
6. меняем тип отчета на «Шахматка» (в свойствах отчета).

Пример построенного отчета приведен на рисунке 2.33.

Для формирования матрицы документооборота необходимыми исходными данными являются стрелки, связанные с процессом, у которых в свойствах «Объекты» указаны документы (бумажные или электронные).

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

Алгоритм построения матрицы документооборота:

1. создаем новый отчет в формате «список»;
2. выбираем привязку «Упорядоченный список процессов с корнем»;
3. в первый столбец выносим свойство процесса «Название»;
4. выбираем привязку «Связи процесса по объектам» и настраиваем фильтр «Объект = Документ»;
5. во второй столбец таблицы выносим свойство привязки «Стрелка SADT»;
6. в третью колонку выносим свойство привязки «Тип стрелки»;
7. меняем тип отчета на «Шахматка» (в свойствах отчета).

Пример построенного отчета приведен на рисунке 2.35.

Примеры отчётов

Информационные источники

1. П. Друкер. Задачи менеджмента в XXI веке. М. «Вильямс». 2007.
2. М. Хаммер. Бизнес в ХХI веке: повестка дня. М. «Добрая книга». 2005.
3. Стандарт качества организации работы по описанию и оптимизации бизнес-процессов в кредитных организациях. Ассоциация российских банков. www.arb.ru/site/action/list_anons.php?id=3381
4. Р.А. Исаев. Референтные (типовые) модели банковской деятельности. www.businessstudio.ru/procedures/business/typebank/
5. Р.А. Исаев. Комплексная бизнес-модель коммерческого банка. www.businessstudio.ru/procedures/business/bank_complex
6. А.В. Шеер Моделирование бизнес-процессов. М. «Серебряные нити». 1999.
7. В.В. Репин. Описание процессов при помощи Work Flow. www.finexpert.ru
8. В.В. Репин. Описание бизнес-процессов: стремление к простоте. www.businessstudio.ru/procedures/business/simple_descr/
9. Д. Марка, К. МакГоуэн Методология структурного анализа и проектирования SADT. М. «Серебряные нити». 1999.

По материалам сайта Finexpert.ru

Показаны возможные первые три шага, чтобы начать работать с системой бизнес-моделирования Бизнес-инженер или Business Studio

Цели и задачи бизнес-моделирования в среде Бизнес-инженер или Business Studio

В данном разделе представлено одно из множества решений как проводить бизнес-моделирование и какие результаты можно получить уже в течение первых дней работы.

Решение показано в основном на примере Бизнес-инженер, но данный подход полностью применим и для системы Business Studio (различия будут лишь в пользовательском интерфейсе и в составе пользовательских отчетов).

В приведенном примере мы коснемся следующих вопросов:

• самостоятельной разработки описания бизнес-процессов организации и построения модели в виде дерева бизнес-процессов с настроенными атрибутами, а также в виде набора графических схем;
• построения организационной структуры компании в системе бизнес-моделирования;
• распределения ответственных и участников по бизнес-процессам;
• формирования внутренних нормативных документов на основе введенной информации:

• положения о процессном управлении;
• регламентов бизнес-процессов;
• положения о компании;
• должностных инструкций для сотрудников.

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

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

Шаг 1. Разработка модели бизнес-процессов организации в среде Бизнес-инженер или Business Studio.

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

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

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

Альтернативным подходом может служить обращение к референтным моделям – накопленным «лучшим практикам» в описании деятельности компаний различных отраслей.

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

 

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

 

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

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

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

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

Шаг 2. Описание организационной структуры компании и построение матрицы распределения ответственности

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

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

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

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

Шаг 3. Описание бизнес-процессов на нижнем уровне в среде Бизнес-инженер и Business Studio.

Если Вы воспользовались библиотекой референтных моделей Бизнес-инженер, то описание бизнес-процессов для нижних уровней уже будет достаточно детализированным. Фактически, содержание  работ следует из названия бизнес-процесса и нужно только поделить эту деятельность между несколькими участниками.

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

 

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

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

Подведем итог. В данном разделе продемонстрировано, как и для чего можно сравнительно быстро начать работу в системе бизнес-моделирования Бизнес-инженер или Business Studio и получить практически значимые результаты.

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

Чтобы сделать заказ на Бизнес-инженер или Business Studio, отправьте запрос на Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. или позвоните по тел. (903) 792:84:52. Дополнительно к системе бизнес-моделирования Вы получите двухчасовой вводный курс по работе в системе (на вашей территории, если офис компании расположен в Москве, либо по скайпу, если ваша компания находится в другом регионе).

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