Практика и проблематика моделирования бизнес-процессов

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

2. Цветовое выделение «маршрута» на фоне общей модели и его сохранение. При прохождении по модели рекомендуется маркировать получаемый «уникальный» маршрут посредством цветового выделения объектов модели, чтобы визуально зафиксировать этот путь и затем иметь возможность заново пройти по нему.

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

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

Пример:

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

Пример:

6. Получение отчета по загрузке (доступности) ресурсов.

7. Анализ пропускной способности организационно-технологической архитектуры предприятия.

Общим концептуальным требованием к проектированию общесистемных сервисов («общесистемной» функциональности) является минимизация обязанности пользователя:

по «прониканию» внутрь общесистемной платформы модели и тем более ее корректировке;

по вниканию в общесистемные настройки;

по вниканию в разветвленный стандартный «некастомизированный» функционал в рамках поиска нужного приложения.

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

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

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

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

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

возможность многопользовательской работы;

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

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

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

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

входные события для модели (внешняя среда);

выборы по принимаемым решениям в точках ветвления бизнес-процесса (внутренняя среда).

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

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

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

Разработка Соглашения о моделировании

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