Свод знаний по управлению бизнес-процессами: BPM CBOK 4.0

● возможности инструмента поддерживать первоочередные сценарии использования;

● возможность применения инструмента в сценариях использования, которые вы хотели бы реализовать в будущем;

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

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

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

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

4.9.7. Регулирование использования репозитория

Регулирование использования репозитория является составной частью процессного регулирования, подробно рассматриваемого в разделе 10.2.3. Репозиторий процессов обеспечивает несколько аспектов процессного регулирования:

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

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

● Многоуровневая система показателей эффективности процессов. Делая иерархию процессов прозрачной, репозиторий предоставляет основу для структурированного многоуровневого измерения эффективности процессов.

● Управление жизненным циклом. Репозиторий поддерживает управление жизненным циклом (создание, модификация, запуск в эксплуатацию) моделей бизнес-процессов и связанных моделей.

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

● нотации моделирования, применяемые на каждом уровне процессной иерархии;

● типы объектов, используемые в каждой нотации;

● типы соединителей, используемые в каждой нотации;

● символы, используемые для каждого типа объекта;

● соглашение об именовании моделей и объектов;

● макеты/правила размещения объектов на диаграмме.

Также документ включает аспекты, специфические для репозитория:

● предполагаемую структуру папок;

● соглашение об именовании папок;

● статусы модели и на что они влияют;

● права пользователей по ролям;

● семантические проверки.

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

Процессное регулирование и регулирование использования репозитория пересекаются везде, где создание, модификация и запуск процессов в эксплуатацию касается репозитория.

Следующий пример иллюстрирует взаимосвязь между процессным регулированием и регулированием использования репозитория:

● модель процесса создания заказа на продажу уже находится в репозитории;

● процесс запущен в эксплуатацию;

● в модель нужно внести небольшие корректировки;

● участники:

○ владелец процесса – имеет доступ на чтение, может комментировать;

○ процессный аналитик – имеет доступ на запись, может редактировать;

○ процессный архитектор – имеет доступ на чтение, может комментировать.

Как вносится изменение?

1. Владелец отдает аналитику распоряжение на изменение.

2. Аналитик создает новую версию модели в состоянии «черновик», не публикуя ее.

3. Аналитик просит архитектора проверить черновик по электронной почте или встроенными возможностями программного обеспечения.

4. Архитектор оставляет комментарии о требуемых корректировках.

5. Аналитик получает уведомление о комментарии.

6. Аналитик корректирует модель процесса и просит архитектора ее утвердить.

7. В комментариях к модели архитектор сообщает о своем согласии с корректировками.

8. Аналитик и владелец процесса получают уведомление о комментарии.

9. Аналитик меняет статус модели процесса на «Согласовано».

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

11. Аналитик получает уведомление о комментарии.

12. Аналитик меняет статус модели на «Утверждено».

13. Аналитик публикует модель, делая ее общедоступной, а новую версию процесса – текущей.

14. Владелец внедряет измененный процесс в повседневные операции.