 |
Разработка прикладных приложений для работы с моделями
|
|
|
|
Одним из следующих важных этапов после определения проектных решений, касающихся составных компонент модели, является разработка прикладных приложений поддержки работы пользователя с моделями и связанных с ней общесистемных сервисов.
Общим требованием к «прикладной» функциональности является необходимость реализации принятых подходов по формализации, анализу и оптимизации бизнес-процессов. Подходы к формализации во многом базируются на стандартных средствах инструментальной среды и фиксируются в соглашении о моделировании. Что касается реализуемых в рамках функционала подходов по анализу и оптимизации, то их с определенной долей условности можно разделить на два основных направления: экспертные и расчетные.
Экспертные методы анализа и оптимизации основываются на визуальном изучении специалистами представленного в удобном графическом виде бизнес-процесса и проведении по своим методикам качественно-количественных оценок. Характерной особенностью экспертного подхода является сложность формализации знаний и опыта эксперта и соответственно их «отторжения» для обезличенного использования широким кругом пользователей, не имеющих столь высокой, как у эксперта, компетенции. Экспертные методы особенно важны, а в отдельных случаях являются единственно возможными при высокой новизне и соответственно неопределенности в решаемой оптимизационной задаче.
Существует расхожее утверждение, что зачастую у эксперта сложно или вообще невозможно получить объяснение по интуитивно полученным им оценкам. Поэтому при экспертном подходе необходимо выводы и рекомендации эксперта воспринимать как некоторую данность. При экспертном подходе прикладная функциональность модели в первую очередь ориентируется на обеспечение удобной для эксперта формы визуализации информации.
|
|
|
Расчетные, в том числе аналитические, методы предусматривают программную реализацию в виде готовых модулей различных алгоритмов качественной и количественной оценки модели бизнес-процессов и ее компонент. Значительная часть функциональных возможностей для численных расчетов временных и стоимостных затрат процессов реализуется в рамках стандартных возможностей инструментальной среды, а дополнительные специализированные методы расчета могут быть осуществлены на основе заказной разработки.
Следует отметить, что многие проектные решения, разработанные для функциональной модели, вполне могут быть применимы и для модели управления (процессной модели). Это касается в том числе задания состава атрибутов для описания объекта «процесс» и перечня значимых связей.
Не останавливаясь на подробном описании всех пользовательских приложений, которые стандартны в большинстве инструментальных средств моделирования, целесообразно указать следующие практически значимые функциональные возможности, которые должны быть представлены в системе «Модель бизнес-архитектуры» предприятия.
1. Интерактивный режим прохождения по модели бизнес-процесса с учетом заданных параметров входных условий и принятия бизнес-решений. Данный функционал необходим для выделения из всего множества спроектированных моделей процессов только той, которая требуется для рассмотрения и последующего анализа либо для протоколирования действий сотрудников в той или иной ситуации. Пользователь в диалоговом режиме определяет те значения из типового набора входных параметров, которые будут влиять на формирование специфичной под данный выбор итоговой модели процесса. В процессе обхода модели/моделей пользователь также должен иметь возможность произвести осознанный выбор альтернатив обхода в «точках принятия решения».
|
|
|
2. Цветовое выделение «маршрута» на фоне общей модели и его сохранение. При прохождении по модели рекомендуется маркировать получаемый «уникальный» маршрут посредством цветового выделения объектов модели, чтобы визуально зафиксировать этот путь и затем иметь возможность заново пройти по нему.
3. Интерактивный режим навигации по сохраненной модели маршрута. Для целей углубленного анализа, экспертизы, контроля правильности принятия решений необходима организация интерактивной работы в режиме пошагового повторного обхода помеченной цветом модели/моделей.
4. Построение технологической карты процесса. Технологическая карта будет являться документальным подтверждением пройденного маршрута, построенного на основе заданных входных данных и принятых в процессе прохождения бизнес-решений. Она должна содержать состав входных данных, список итоговых операций, используемых и получаемых при выполнении этих операций документов (операционных, нормативно-справочных), бизнес-роли, возможные информационные системы и другие данные.
Пример:
5. Получение должностных инструкций. Под построением должностной инструкции понимается формирование отчета, в котором выбранной должности ставятся в соответствие определенные роли и составляется полный список всех функций, выполняемых должностным лицом безотносительно к какому-либо процессу, в котором оно (лицо) участвует в конкретный момент.
Пример:
6. Получение отчета по загрузке (доступности) ресурсов.
7. Анализ пропускной способности организационно-технологической архитектуры предприятия.
Общим концептуальным требованием к проектированию общесистемных сервисов («общесистемной» функциональности) является минимизация обязанности пользователя:
♦ по «прониканию» внутрь общесистемной платформы модели и тем более ее корректировке;
♦ по вниканию в общесистемные настройки;
♦ по вниканию в разветвленный стандартный «некастомизированный» функционал в рамках поиска нужного приложения.
Поэтому общим направлением проектирования общесистемных сервисов является максимальный вынос всех пользовательских настроек – задание условий работы модели в интерфейсную часть. К числу пользовательских настроек, которые целесообразно вынести «наружу» в интерфейсную часть, следует отнести:
|
|
|
♦ задание входных условий – бизнес-событий, которые должны инициализировать анализируемый бизнес-процесс, в рамках предварительно сформированного набора (меню) возможных параметров;
♦ выбор организационных и технических ресурсов для исполнения бизнес-процесса в рамках предварительно сформированной библиотеки настроек под различные конфигурации организационно-технологической структуры;
♦ разработка штатного расписания и распределение ролей подразделения, состава информационных систем и т. д.
Помимо поддержки прикладных сервисов, связанных с анализом бизнес-процессов, общесистемная архитектура может проектироваться с перспективой более широкого использования. В частности, разрабатываемая модель бизнес-архитектуры может стать составной частью либо «workflow», либо автоматизированной системы управления предприятия. Потенциально модель может не только «иллюстративно» показывать задействование персонала и информационных систем в рамках формализации бизнес-регламента деятельности предприятия, но и формировать соответствующие управляющие сигналы для реально работающих информационных (технических) систем и должностных лиц. Для реализации такой потенциальной возможности необходимо предусмотреть в проектных решениях:
♦ возможность многопользовательской работы;
♦ возможность выгрузки управляющих сигналов по задействованию информационных систем и персонала в соответствующие форматы обмена, поддерживаемыми прикладными приложениями.
Очень важными самостоятельными компонентами общесистемных сервисов являются средства тестирования моделей. Многие промышленно поддерживаемые инструментальные средства имеют стандартные модули проверки корректности созданных моделей. Вместе с тем, как правило, они не могут учесть в полной мере как специфику области моделирования, так и разработанные проектные решения тех или иных компонент модели.
|
|
|
Наиболее «узким» местом является полная обкатка модели, включая разработанные программные модули анализа, по максимальному количеству вариантов задания исходных данных для инициирующих бизнес-событий. Очевидно, что при количестве вариантов свыше нескольких десятков вероятность, что они все будут пройдены даже при условии формирования большой группы «тестировщиков», мала.
По этой причине актуальным является формирование механизмов автоматизированного тестирования, в рамках которого генерируются случайным образом (либо по заданному порядку) внешние и внутренние события бизнес-процессов:
♦ входные события для модели (внешняя среда);
♦ выборы по принимаемым решениям в точках ветвления бизнес-процесса (внутренняя среда).
В качестве ядра механизма генерации различных сочетаний событий могут использоваться стандартные процедуры для датчиков случайных чисел.
В целом необходимо отметить, что тестирование модели, подобно тестированию любой другой информационной системы, должно осуществляется в соответствии с хорошо зарекомендовавшими себя практиками и стандартами [17].
Обязательным этапом, предваряющим реализацию проектных решений построения модели бизнес-архитектуры, является разработка Соглашения о моделировании – свода единых правил моделирования.
|
|
|
