A.2.1.1.5. Объединение определения требований на уровне функциональной модели
На рис. 33 представлена объединенная метамодель определения требований на уровне функций.
А.2.1.2. Конфигурирование функций
Если мы хотим использовать собственные интерфейсы систем управления процессами, потоками работ и конфигурацией прикладных систем, необходимо следовать определенным требованиям моделирования. Однако модели должны по-прежнему оперировать только понятиями бизнеса.
Сначала формируются связи функций с классами прикладных систем (системы управления проектами, текстовые процессоры, бизнес-приложения), которые нужно сконфигурировать. Если типы прикладных систем уже можно описать более подробно (MS Project, MS Word for Windows, R/3 и т.д.), эти связи могут быть установлены. Кроме того, следует указать. предполагают эти системы обмен данными или нет (см. рис. 34).
Функциональные модели и списки операций создают основу для функционального анализа, оценки стоимостных характеристик функций и управления бизнес-процессами (например, методом пооперационного исчисления стоимости). Для пооперационного исчисления стоимости функциям присваиваются необходимые атрибуты (время, количество, стоимость за единицу продукции и т.д.).
Содержание соответствующих функции планирования мощностей конфигурируется согласно функциональным моделям.
Рис. 33. Метамодель определения требований на уровне функционального представления
Рис. 34. Формирование связей прикладной системы
Описание функций необходимо для того, чтобы настроить систему планирования проектов на конкретное приложение в рамках проекта, связанного с производством или организационной структурой, например, при подготовке к торговой выставке.
Рассмотренные метамодели описания на уровне функций уже могут быть использованы для моделирования приложений workflow (Caller. Vom Geschaftsprozeftmodellzum Workflow-Modell. 1997, с. 62). При описании атрибутов функций целесообразно внести конкретные уточнения, например предельные сроки (среднюю продолжительность функции, среднее время цикла, возможные наложения во времени и т.п.).
Вызов функции может осуществляться по принципу «вытягивания» («pull») или «проталкивания» («push»). В первом случае сотрудник извлекает соответствующую функцию из электронного почтового ящика вместе со списком операций, которые требуется выполнить. Во втором случае функции, управляемые событиями, присылаются ему на обработку.
Моделирование процессов workflow должно удовлетворять дополнительным требованиям на уровне экземпляров. Эти требования копируются из определения требований на уровне функций, но при необходимости их можно изменять таким образом, чтобы смоделировать сами экземпляры.
После того как бизнес-приложения связаны с функциями и сконфигурированы, особенно важно иметь возможность активизировать или исключать функции в рамках существующей первоначальной модели.
Если определенное бизнес-приложение использует определенную функциональную модель-прототип, модели для конкретных пользователей можно создавать путем активизации или «вычеркивания» соответствующих функций. Можно задать правила согласования, учитывающие логические связи между функциями. Например, при вычеркивании функции «управление складом грузов, предназначенных для отправки» необходимо удалить и функцию «заказ на отправку груза».
Чтобы обеспечить целостность модели-прототипа, каждую функцию нужно либо активизировать, либо исключить (см. Scheer. ARIS — Business Process Frameworks. 1998, рис. 50). На рис. 35 представлен фрагмент модели-прототипа SAP R/3, иллюстрирующий редактирование с помощью ARIS Toolset. Структуру проекта для индивидуальной настройки SAP R/3 (нижнее окно) можно вызвать непосредственно из функциональной модели (верхнее окно). Внимательно изучив функцию, можно задать выбранные параметры в соответствии с определением требований. Программа SAP R/3 Business Engineer, обращающаяся непосредственно к системе настройки IMG (Руководство по управлению реализацией), предлагает для этой цели интерфейс, построенный по принципу вопросов и ответов.
Рис. 35. Редактирование SAP R/3 с помощью APIS Toolset
На рис. 36 приведен фрагмент прототипа SAP AG Business Engineer. Модель проекта показывает функциональное дерево приложения. Активизация и деактивиза-ция функций осуществляются путем установки флажков. Функции — в данном примере это «Credit processing» («Обработка кредитов») — отсылают пользователя непосредственно к нужным подфункциям настройки (нижнее окно слева), а отсюда можно выйти на нужные параметры (верхнее окно справа). Нижнее окно справа иллюстрирует, как функция встраивается в контекст процесса.
Рис. 36. Настройка функции в SAP R/3