Моделирование бизнес-процессов (стр. 7 )

Этап определения требований включает также описание типа предварительной обработки для системных функций. Один из ключевых параметров типа обработки определяется в зависимости от ситуации: могут ли пользователи вносить коррективы в процесс (оперативная обработка) или же функции выполняются без вмешательства со стороны пользователей (пакетная обработка). Чтобы решить, подходит ли данная функция для оперативной обработки, можно воспользоваться параметрами, приведенными и на рис. 29. Исходя из этих соображений, мы подразделяем класс СИСТЕМНАЯ ФУНКЦИЯ на подклассы ОПЕРАТИВНАЯ ФУНКЦИЯ и ГРУППОВАЯ ФУНКЦИЯ.

Свойства Цели	Управляемость событиями	Возможность интеграции функции	Допускает интерактивные решения	Устраняет пиковые нагрузки	Позволяет вносить улучшения	Позволяет повышать качество
Экономия времени	•	•	•	•	•
Экономия рабочей силы		•		•	•
Получение Информации	•		•			•
Создание благоприятных условий работы	•	•		•	•	•
Оптимизация организационных процессов		•	•		•

Рис. 29. Параметры и цели оперативной обработки

А.2.1.1.4. Модели решений

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

В качестве примера приведем типичную структуру модели решеня и рассмотрим метод линейного программирования (ЛП). В моделях ЛП — при соблюдении всех вторичных условий — переменные задаются таким образом, чтобы максимизировать целевые функции (см. рис. 30). Структуры ЛП не связаны с каким-либо конкретным приложением и располагаются на метауровне описания моделей решений. На рис. 31 представлена модель ЛП на 2-ом уровне абстракции, относящаяся к приложению для планирования производства (уровни абстракции в моделировании см. Scheer. ARIS — Business Process Frameworks. 1998, с. 120-125; в русском издании с. 109-115).

Целевая функция:
Вторичные условия:	для всех i для всех j
Переменные:
Коэффициенты:

Рис. 30. Структура модели ЛП

	= вклад j-ro продукта = объем производства j-ro продукта
(для всех I)	= потребности в мощностях 1-го типа на еденицу j-ro продукта = предельные мощности 1-го типа
(для всех j)	= максимальный объем продаж j-ro продукта

Рис. 31. Модель ЛП для планирования производства

В представлении модели ЛП как диаграммы классов внимание фокусируется на объектах метамодели ЛП (см. рис. 30). Модели ЛП состоят из элементов ПЕРЕМЕННАЯ, УРАВНЕНИЕ (вторичные условия и целевые функции) и КОЭФФИЦИЕНТ.

Для отдельных моделей решений формируется класс МОДЕЛЬ РЕШЕНИЙ (см. j рис. 32). В одной ФУНКЦИИ (например, в планировании производства) можно использовать несколько моделей решений. И наоборот, одну модель решений можно » применять к нескольким разным функциям. Мощности отношений равны соответственно, (0,..*).

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

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

Отношение между заданными переменными (столбцы матрицы ЛП) и уравнениями (строки матрицы ЛП) устанавливается с помощью коэффициентов. В каждом столбце (т. е. для каждой переменной) коэффициенты можно подставлять во множество уравнений. И наоборот, в каждой "Роке (уравнении) можно рассматривать несколько переменных.

Генераторы матриц, переменные, уравнения и коэффициенты модели можно получить из базы данных, описав все допустимые индексные комбинации переменной на основе хранящегося в ней логического контекста (Scheer. Business Process Engineering. 1994, с. 525). Формат системы математического программирования (MPS) позволяет стандартизировать описание.

Рис. 32. Логическая структура моделей решений

Логическая структура модели решений, изображенная на рис. 32, представляет собой структуру данных для репозитория, где хранятся модели приложений (Scheer. Principles of Efficient Information Management. 1991, c. 157).

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 (Руководство по управлению реализацией), предлагает для этой цели интерфейс, построенный по принципу вопросов и ответов.