Book.od.ua Книги для вашего бизнеса



Одесская библиотека бизнес литературы
полезные книги для бизнеса

1.12. Последовательность функций в процедурах

Помимо изучения структуры функций, на этапе определения требований анализируется последовательность функций в процедурах, что прямо ведет к описанию процессов. В отличие от описаний управленческих процессов, рассматриваемых позже, определяются логические последовательности функций, а не триггеров. Это уместно, когда инициирующие события или сообщения не предоставляют никакой дополнительной информации в ходе определения требований или когда триггеры добавляются позже, на этапе спецификации дизайна. Методы описания процедур исходят из методик построения сетевых диаграмм, описывают различные связи подчинения и доминирования, измеряют расстояние между событиями, фиксируют любые наложения событий или их густоту. Более того, логически увязываются входные и выходные элементы соответствующих взаимосвязей.
На рис. 25 представлена в виде процедуры часть иерархической диаграммы, изображенной на рис. 19, а. Рис. 25 подтверждает, что контекст процедуры нельзя вывести из древовидного индекса. После вычислений с использованием приближенных значений ("ballpark figures") и количественной структуры заказа, имеет место узел решений, из которого выходят три ветви: составить новое техническое предложение, если вычислена нереальная цена; приостановить процесс, если есть основания полагать, что предложение будет отвергнуто; обслужить заказ, если клиент принял предложение. Вероятности различных альтернатив указаны рядом с соответствующими стрелками. Так как эти альтернативы взаимоисключающие, сумма вероятностей равна 1.
Данная концепция взята из методики графического анализа GERT (см. El-maghraby, Activity Networks 1977; Scheer, Projektsteuerung 1978).
Последовательность функций в процедурах
Узел решений, представленный здесь, можно рассматривать как отдельный элемент, но его также можно интерпретировать как нормальное событие нулевой продолжительности или как часть предыдущего события.
Упорядочивание взаимосвязей формирует новый класс ассоциаций ПОЗИЦИОНИРОВАНИЕ внутри класса ассоциаций ФУНКЦИЯ. Каждая позиция определяется предшествующей и последующей функцией. Добавляя класс ассоциаций ПОЗИЦИОНИРОВАНИЕ на рис. 26, получаем возможность определить расстояние между событиями, наложение или отсрочку событий.
Логические зависимости между предельными значениями размещены как атрибуты связей позиционирования.
Для функций сферы материального производства последовательность функций в процедурах описывается в рабочем задании. Понятие "рабочее задание" уже подразумевает описание процесса, потому что элементы других аспектов ARIS (организационные единицы, ресурсы, материальный продукт) содержатся в рабочем задании. Однако управление событиями не присутствует явно в рабочем задании, следовательно, динамика процессов не представлена в явном виде.
Последовательность функций в процедурах
Рабочие задания касаются производства деталей различных уровней сложности. Рабочие задания для подклассов создаются на уровне типа, как показано на упрощенном примере на рис. 27, а. Каждая операция описывает функцию, а рабочее задание описывает, как из операций составляется процесс.
Последовательность функций в процедурах
Операции соответствуют техническим процедурам. Технические процедуры описываются независимо от контекста рабочего задания, а затем детализируются в контексте рабочего задания или процесса. Диаграммы классов соответствуют рис. 27, б. Технически это совпадает с метамоделью структуры функций
на рис. 21 (БИЗНЕС-ПРОЦЕСС, ОБЩАЯ ФУНКЦИЯ, ФУНКЦИЯ). Таким
образом, последовательность технических функций можно трактовать так же, как и административных функций.
Последовательность функций в процедурах
 Документирование рабочих заданий - одна из классических задач при моделировании процессов планирования производства и контроля в информационных системах. Рабочие задания анализируются на уровне деталей и классов деталей; создаются большие базы данных. Диаграмма классов для управления рабочими планами на уровне деталей приведена на рис. 27, б (см. Scheer, Business Process Engineering 1994, p. 216). Контекст процесса выясняется с помощью определения взаимосвязей деталей.
Не принято использовать функции на уровне деталей в моделировании бизнес-процессов. Это делается только для особо важных конечных продуктов.
Рабочие задания на уровне типа и экземпляра, которые мы обсуждали до этого момента, похожи на описание обработки основных данных, так как они не зависят от контекста заказов (хотя экземпляры, управляемые системами документооборота, зависят от заказов). В данном случае рабочие задания на уровне типа и экземпляра похожи на шаблоны. В системах планирования производства и контроля параллельно разрабатываются рабочие задания, зависящие от основных данных и заказов.


Понравился материал? Поделитесь с друзьями!

<< Предыдущая статьяСледующая статья >>
1.11. Структура функций. Часть Третья. 1.13. Типы обработки





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