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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

♦ Структура хранения моделей в базе данных.Элементы проекта, такие как модели и объекты (активности), желательно структурировать в определенные папки проекта в инструментальной среде.

При создании иерархии папок возможно использование нескольких критериев:

♦согласно этапам проведения проекта;

♦согласно процессно-ориентированной структуре;

♦согласно функциональной структуре компании;

♦согласно описываемым предметным областям;

♦комбинации указанных выше критериев.

В данном разделе указываются выбранные критерии построения и непосредственно общая структура папок.

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