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

Зуева А. Г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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