Быстрый поиск
Ключевые слова:
  Раздел портала:
 



Найти в Интернете
 
Часто задаваемые вопросы    Методология ARIS
Алгоритм расчета, применяемый в отчете ProcessInitiativesAnalysis.asm

АВТОР: Jull

Эффективность цели – ее важность, значимость на всей карте. «Конечная/верхняя цель» (Superior objectives) – Цель без исходящих связей.

a. Ели «конечная/верхняя» цель одна – ее Приоритет=1, Эффективность=1 i. если несколько «конечных» целей, тогда

  1. Эффективность каждой =1/(количество таких целей)
  2. Приоритет каждой такой цели = 1

b. Рассматриваем цели, у которых есть исходящие связи на цели, эффективность которых уже известна.

i. Весовые коэффициенты для связей (отражают степень влияния цели на цель)

  • 1. very weak – 1
  • 2. weak – 2
  • 3. normal – 3
  • 4. strong – 4
  • 5. full (very strong) – 5

ii. Вариант расчета эффективности для цели, имеющей одну исходящую связь:

  1.  Эффективность = (Эффективность цели, на которую оказывает влияние рассматриваемая цель) * вес исходящей связи от цели / сумма весов всех связей на цель, на которую оказывает влияние рассматриваемая цель

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

  1. Эффективность по связи1 + Эффективность по связи2 + …

c. Определение приоритета:

  1.  Приоритет цели с минимальным значением эффективности = числу (которое отражает общее количество целей)
  2. Приоритет оставшихся целей – Приоритет цели = количество целей, у которых показатель эффективности >, чем у рассматриваемой + 1.

d. Efficiency initiatives/functions = strength of influence * Efficiency objective/critical factor



Как отслеживать статусы длокумента?
Один из вариантов - использование технических терминов для обозначения статусов документа.

Каждый статус обозначается отдельным объектом Technical term.
При изменении функцией статуса документа, с функцией соединяется документ а с ним соединяется соответствующий статусный Technical term.

Объекты Technical term - статусы документов целесообразно так же отображать на диаграмме технических терминов (Technical terms model).


Может ли после функции следовать вместо события другая функция?

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

А будет ли ругаться семантик чек?
Да. Но это формальная проверка. Ее можно редактировать так, что ругани не будет.

Не забывайте, что в данном случае могут быть некорректно отработаны Simulation, а также взаимодействие с SAP и т.д. В каждом конктретном случае выясняйте необходимость и возможность игнорирования событий.



Назначение Process Interface

"Ребята" из Sheer используют этот объект для того чтоб показать перекрестные ссылки между процессами/процедурами.
К примеру : модель типа eEpc должна начинаться и заканчиваться событием, что они делают, они присоединяют к верхнему событию и к последнему обект типа Process Interface и указывают в них , типа Переход от процедуры .... , переход к процедуре .....
и делают у этого объекта ассигмент на ту модель из которой пришло событие или в которую оно уходит.
Чтоб можно было наглядно отобразить из какого процесса/ процедуры пришло "событие" и куда оно "уходит" (Хотя Семантик чек будет ругаться на то что модель начинается и заканчивается на объектом типа Event, но это всего навсего лишь модуль для проверки и его критерии можно изменять).
А так это та же самая Function. В Арисе вообще много всяких различных объектов, но не обязательно их все использовать. Можно в модельном соглашении отразить те объекты которые будут использоваться при описании моделей (соответственно с определенной переодичностью это соглашение пересматривается, если что то можно что то и добавить или убрать оттуда).

ToropovDV



Есть ли стандартные правила моделирования?
Ниже приведены некоторые правила, поставляемые с инструментальной системой ARIS.
(изъято из Моделирование бизнеса (методология ARIS. Практическое руководство) М. Каменова, А. Громов, М. Ферапонтов, А. Шматлюк, Весть МетаТехнология)

Правила могут создаваться и меняться. Не могут создаваться и меняться типы правил.

Правила существования объектов
 • Функция из модели процесса существует в дереве функций (целей).
 • Функция из модели процесса существует в матрице выбора процесса.
 • Функция из дерева функций не присутствует в другом дереве функций.
 • Организационный элемент из модели процесса существует в организационной модели.
 • Сущность из модели процесса существует в модели данных.
 • Информационная функция из алгоритма модуля существует в структуре системы.
Правила взаимосвязи объектов
 • Каждая функция должна иметь исполнителя.
 • Каждое подразделение должно содержать в своем составе как минимум одну должность.
 • Для каждой информационной системы должен быть определен ответственный за разработку.
Правила структуры моделей
С помощью этих правил проверяют корректность формирования структуры взаимосвязей объектов в модели. Правила объединены в несколько групп.
Общие структурные правила для всех типов моделей
 • Каждый объект должен иметь одно или более соединений с другими объектами.
 • Объект не может быть замкнут сам на себя.
Специальные структурные правила для всех моделей процессов
 • Каждый путь должен начинаться и заканчиваться событием или интерфейсом в другой процесс.
 • Проверка корректности количества входящих и исходящих соединений логических операторов.
 • Все функции и события должны иметь только одно входящее и одно исходящее соединения.
 • После события не должен следовать оператор «ИЛИ-НЕ» или «ИЛИ».
 • В модели запрещены циклы.
Специальные структурные правила для моделей eERM
 • Тип связи определяется, по крайней мере, для типов сущностей.
 • Только один супертип представляет подтип.
 • Группа атрибутов содержит не менее двух атрибутов.
Специальные структурные правила для иерархических моделей (относятся к иерархическим моделям с перекрестными связями и без, например дерево функций, оргсхема и т.п.)
 • Возможен только один корень.
 • Каждый объект может иметь только одного родителя.
 • Разрешено только одно соединение между двумя объектами.
 • Все исходящие соединения объекта должны иметь один и тот же тип.
 • Все соединения в модели должны иметь один и тот же тип.
Структурные правила для специфических иерархических моделей
 • Только функции без исходящих соединений могут быть детализированы.
 • Только организационные элементы без исходящих соединений могут быть детализированы.
Правила атрибутов объектов и связей
 • Для всех функций заполнено поле описания.
 • Для всех объектов заполнено поле имени.
 • Для всех должностей заполнены возрастные требования.
 • Для всех сотрудников заполнена дата рождения.
 • Требования к заполнению атрибутов для динамического моделирования.
 • Требования к заполнению атрибутов для метода АВС.


FAQ: 1 - 5 из 6следующая >  Страницы:  1 2 

На правах рекламы.
Ролики sexwife на xepok.com
© ARIS-portal.RU © 2004-