Связи между процессами, оборванные входы/выходы
Бизнес-аналитик должен ясно осознавать, что между процессами всегда существует взаимодействие. На схеме его можно показать через обмен данных. Это означает, что из процесса выходят и, наоборот, в процесс входят документы (в бумажном или электронном виде). При этом очень важно понимать, что эти документы не берутся из воздуха, а появляются в каком-то одном процессе, используются другим процессом, передаются третьему и т. д. Если бизнес-аналитик рисует на схеме процесса документы, не отдавая себе отчета в том, откуда они берутся, не уточняя их название и содержание, то схема будет мало соответствовать реальности.
На схеме процесса не допускаются оборванные входы и выходы (рис. 4.9.7). Всегда должны стоять ссылки на соответствующие процессы поставщиков и потребителей информации/документов.
Рис. 4.9.7. Оборванные входы/выходы процессов
Нарушение нотации моделирования
Нарушение нотации моделирования создает проблемы – схема становится нечитаемой, возникают неоднозначные моменты в ее интерпретации и т. д. Если в организации установлен стандарт моделирования бизнес-процессов, то обязательно нужно его придерживаться. Чем сложнее выбранная нотация, тем больше вероятность, что неопытный бизнес-аналитик нарисует схему, содержащую множество ошибок (рис. 4.9.8).
Опыт показывает, что сотрудники склонны упрощать любую нотацию до примитивного уровня (это можно назвать профанацией моделирования процессов). К сожалению, при этом качество схем оказывается никуда не годным. В таких компаниях руководство утверждает: «Мы пытались рисовать графические схемы, но что-то у нас они не получились. Мы решили описывать все текстом». Так появляются довольно увлекательные управленческие «новеллы» и «романы» в регламентирующем стиле.
Рис. 4.9.8. Чрезмерно сложные схемы процессов
Проверка на здравый смысл
Даже самому опытному бизнес-аналитику полезно оценить полученную схему процесса с точки зрения здравого смысла (рис. 4.9.9). Это означает, что нужно, например, проверить процесс на физическую реализуемость: мы показываем, что сотрудник делает то-то и то-то, а он в это время давно уже занят чем-то другим и т. п.
Целесообразно обратить внимание на:
• ненужное повторение операций;
• перегрузку исполнителей;
• контрольные операции, от которых можно отказаться;
• возможность параллельного выполнения операций;
• возможность упрощения алгоритма выполнения процесса;
• неоправданное усложнение (лишние, устаревшие операции);
• узкие места различного характера;
• недостаточное обеспечение ресурсами;
• прочее.
Рис. 4.9.9. Проверка на здравый смысл
Рекомендации по внедрению среды моделирования процессов
Внедрение среды моделирования процессов в масштабах организации – важный и сложный проект. Для его успешного выполнения нужно разработать план, адекватный задаче. Предлагаю один из возможных вариантов такого плана[103].
Для крупной компании внедрение среды моделирования – серьезный проект, который может состоять из трех этапов[104]:
1. Выбор и тестирование среды моделирования.
2. Опытная эксплуатация среды моделирования.
3. Внедрение среды моделирования в масштабах компании.
Этап 1. Выбор и тестирование среды моделирования:
• определение потребностей внутренних пользователей;
• определение и согласование целей и задач проекта;
• анализ сред моделирования, представленных на рынке (по документации), и выбор системы для тестирования;
• установка пробной версии среды моделирования (два-три рабочих места);
• создание пилотной модели организации:
– описание двух-трех процессов на двух уровнях;
– описание фрагмента организационной структуры;
– описание некоторых документов, терминов, ТМЦ;
– формирование пилотных отчетов (регламентов выполнения бизнес-процессов);
• тестирование среды моделирования на основе пилотной модели:
– тестирование функциональных возможностей системы;
– тестирование выгрузки отчетов (регламентирующих документов);
– тестирование управления изменениями;
• анализ результатов тестирования среды моделирования на пилотной модели, принятие решения о выборе системы;
• определение конфигурации системы, необходимой для решения задач организации;
• принятие решения и закупка среды моделирования;
• установка системы (три-пять конкурентных лицензий);
• обучение группы специалистов работе со средой моделирования (включая прохождение теста и получение официальных сертификатов);
• разработка детального плана опытной эксплуатации среды моделирования.
Этап 2. Опытная эксплуатация среды моделирования:
• администрирование системы:
– создание групп пользователей и определение прав доступа;
– настройка функционала контроля внесения изменений в систему;
• анализ и внесение необходимых изменений в метамодель:
– анализ требований внутренних потребителей по выгрузке отчетов из среды моделирования (регламенты, положения, прочие отчеты);
– анализ возможностей метамодели с точки зрения хранения информации, необходимой для выгрузки отчетов;
– определение и внесение необходимых дополнений в метамодель (структуру данных);
– определение требований по использованию метамодели при моделировании организации;
• ввод в систему необходимых справочников:
– иерархический справочник процессов организации (возможно, путем импорта системы процессов организации из файла MS Excel);
– иерархический справочник подразделений и должностей;
– справочник бумажных и электронных документов (уровня компании);
– справочник терминов;
– прочее.
• разработка и тестирование необходимых шаблонов регламентирующих документов и других отчетов;
• разработка решений по интеграции с другими системами («экспорт – импорт»);
• разработка стандарта моделирования (нормативный документ, регламентирующий использование функционала системы и метамодели при описании процессов, подразделений, документов и т. п.);
• разработка и тестирование регламента управления изменениями (нормативный документ, регламентирующий взаимодействие сотрудников и порядок внесения изменений в объектную модель организации);
• анализ эффективности функционирования среды моделирования; внесение необходимых изменений в регламенты работы с системой.
Этап 3. Внедрение среды моделирования в масштабах компании:
• определение количества необходимых лицензий;
• закупка и установка среды моделирования в структурных подразделениях организации;
• обучение руководителей и специалистов подразделений использованию системы (соглашение по моделированию, регламент управления изменениями и т. д.);
• разработка плана описания процессов организации;
• описание приоритетных процессов организации силами специалистов подразделений; выгрузка регламентирующих документов;
• анализ эффективности эксплуатации среды моделирования, внесение необходимых изменений в регламенты работы с системой.
В стандарте по моделированию сформулированы требования по использованию системы при описании процессов, подразделений, документов и т. п. Это подробная инструкция, в соответствии с требованиями которой сотрудники организации обязаны работать со средой моделирования: заносить информацию в соответствующие атрибуты объектов модели, формировать графические схемы и т. д. Документ может иметь такую структуру (на примере стандарта, разработанного для использования среды Business Studio):
1. Общие положения
1.1. Назначение и область действия
1.2. Используемые сокращения
1.3. Термины и определения
1.4. Нормативные ссылки
2. Ведение справочников в Business Studio
2.1. Справочник «Процессы»
2.2. Справочник «Субъекты»
2.3. Справочник «Объекты деятельности»
2.4. Справочник «Управление»
3. Описание процессов в Business Studio
3.1. Элементы нотации «Процедура» Business Studio
3.2. Описание операций процесса
3.3. Использование стрелок типа «Связь предшествования»
3.4. Использование стрелок типа «Поток документов»
3.5. Использование событий
3.6. Использование блока «Решение»
3.7. Использование междиаграммных ссылок
3.8. Использование сносок
4. Схемы организационной структуры в Business Studio
4.1. Используемые графические элементы
5. Заполнение атрибутов объектов модели
5.1. Заполнение атрибутов процесса
5.2. Заполнение атрибутов операции процесса
5.3. Заполнение атрибутов стрелок
5.4. Заполнение атрибутов субъекта деятельности
5.5. Заполнение атрибутов объекта деятельности
5.6. Заполнение атрибутов целей и показателей
6. Приложения
6.1. Пример схемы процесса в нотации «Процедура» Business Studio
Регламент управления изменениями – это инструкция по внесению существенных изменений в систему, в том числе изменение модели организационной структуры, изменение справочника процессов на верхнем и среднем уровне, массовое переназначение ответственности за выполнение процессов. Подобные действия могут выполнять только квалифицированные бизнес-аналитики, имеющие соответствующие полномочия. Регламент может выглядеть примерно так:
1. Общие положения
1.1. Назначение
1.2. Термины, определения и сокращения
2. Общее описание процесса управления изменениями
3. Типы изменений и распределение ролей и ответственности за управление изменениями
4. Изменения справочников
4.1. Организационная структура
4.2. Процессы
4.3. Объекты деятельности (документы, ТМЦ, программные продукты)
4.4. Цели и показатели
4.5. Прочее
5. Изменение схем процессов
6. Изменение шаблонов отчетов
7. Изменение метамодели
8. Архивирование и восстановление объектной модели
9. Изменение прав доступа
10. Изменение версии системы (переход на новые версии)
11. Изменение решений по интеграции с другими системами
В заключение приведу пример графика проекта по созданию репозитория бизнес-процессов организации на платформе среды моделирования Business Studio (рис. 4.10.1).
Рис. 4.10.1. График Ганта создания репозитория бизнес-процессов на платформе среды моделирования Business Studio
После покупки и установки системы Business Studio следует обучить рабочую группу. Несколько специалистов из нее образуют потом центр компетенции по использованию репозитория бизнес-процессов. Остальные будут совмещать текущую деятельность в подразделениях с моделированием, анализом и регламентацией бизнес-процессов. Они станут агентами влияния процессной методологии в структурных подразделениях компании.
Для эффективного использования системы нужно разработать архитектуру (систему) бизнес-процессов компании. Удобно это делать в MS Excel, но можно и сразу в системе. Далее полученная архитектура процессов переносится в Business Studio – создается иерархический справочник процессов. Этот справочник – основа для накопления знаний о процессах в рамках электронного репозитория.
Затем рабочая группа описывает несколько пилотных процессов. Это делается для того, чтобы в полной мере освоить возможности инструмента и сформулировать предварительные требования к стандарту моделирования и шаблонам регламентирующих документов.
Чтобы выгрузить из репозитория информацию о процессах в необходимой форме (регламенты, инструкции, положения и т. п.), нужно определить требования к этим документам. При проектировании шаблонов отчетов увязываются между собой требования к документам и возможности системы. Например, если мы хотим видеть в документе какой-то атрибут бизнес-процесса, надо понимать, какую информацию и как следует заносить в репозиторий. Создание шаблонов для выгрузки сложных регламентирующих документов может потребовать изменений объектной модели Business Studio. Это легко делается при помощи специального инструмента Meta Edit, входящего в комплект поставки системы (в версии Enterprise).
Когда станет понятно, как моделировать процессы и какая информация должна заноситься в атрибуты объектов модели, разрабатывается стандарт моделирования (соглашение по моделированию).
Кроме этого документа полезно создать стандарт (инструкцию) по администрированию репозитория и стандарт по внесению изменений в модель организации.
После разработки и согласования стандартов проводится обучение руководителей и специалистов подразделений компании работе с электронным репозиторием бизнес-процессов на платформе Business Studio.
Список литературы
1. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. – М.: Стандарты и качество, 2007.
2. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Стандарты и качество, 2004.
3. Руководство пользователя Business Studio (2012).
4. Руководство технического специалиста Business Studio (2012).
5. Создание пользовательских отчетов Business Studio. Методика (2012).
6. Маклаков С. В. Моделирование бизнес-процессов с AIIFusion Process Modeler. – М.: Диалог-МИФИ, 2008.
7. Черемных С. В., Семенов И. О., Ручкин В. С. Структурный анализ систем: IDEF-технологии. – М.: Финансы и статистика, 2001.
8. Моделирование бизнеса. Методология ARIS. Практическое руководство / М. Каменнова [и др]. – М.: Серебряные нити, 2001.
9. Silver B. BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0. – Cody-Cassidy, 2009.
Глава 5
