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



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

1.2. Aris — Моделирование Бизнес-Процессов. Продолжение.

Таким образом, программное обеспечение на уровнях конфигурации от II до IV представляет собой некую оболочку. Для привязки к конкретным приложениям эту оболочку необходимо заполнить содержанием моделей бизнес-процессов, определяемых на уровне I.
Например, информационная система планирования пропускной способности хирургической больницы на уровне II сначала должна быть увязана с моделью лечебного процесса, прежде чем ее можно будет использовать для управления деятельностью операционной. Точно так же система планирования пропускной способности автомобильного парка должна быть согласована с моделью процесса автомобильных перевозок, прежде чем ее можно будет использовать для диспетчирования. Следовательно, принятые на первом уровне модели бизнес-процесса содержательные наименования ресурсов, таких как "хирург, аппарат искусственного дыхания и кровать" или "курьер, автомобиль и место на складе", определяют наименования ресурсов системы планирования пропускной способности.
Таким же образом модели процессов используются для конфигурации систем управления потоком на уровне III и прикладных систем на уровне IV, что говорит о необходимости для этих систем соответствующего интерфейса. Современные стандартные приложения, такие как SAP R/3 или BAAN IV, снабжены собственным интерфейсом, ориентированным на внутренние инструменты конфигурации и средства диалога с пользователем. В системах управления потоком используются специальные языки конфигурации, такие как FDL (flow defining language) в системе FlowMark фирмы IBM.
Учитывая тот факт, что конфигурация рассматривается на уровне модели бизнес-процесса, мы считаем конфигурацию вершиной описания требований. Поэтому мы обсудим вопросы конфигурации после анализа требований.
Затем мы рассмотрим применение бизнес-моделей для спецификации дизайна и описания внедрения, соответственно.
Если информационные системы применяются на всех четырех уровнях концепции HOBE, переход от анализа требований к описанию внедрения в общем случае требует вмешательства в программное обеспечение на каждом уровне. Эта процедура не зависит от типа используемой программной системы. На рис. 2 показаны фазы определения требований, спецификации дизайна и описания внедрения как последовательные этапы на уровне IV. Это же касается программного обеспечения на остальных уровнях. Следуя концепции автора о компьютерных науках, применяемых в бизнесе, в данной книге мы будем только поверхностно рассматривать вопросы внедрения.
Диаграммы классов в нотации унифицированного языка моделирования UML (Unified Modeling Language) используются для описания каждой метамо-дели (см. UML Notation Guide 1997). Диаграммы классов похожи на иллюстрации в рамках модели "сущность-связь" (Entity Relationship Model; ERM) Чена, используемые в предыдущих изданиях данной книги (см. Chen, Entity Relationship Model 1976).
На рис. 3 диаграммы классов в нотации языка UML, используемые в данном издании книги, сравниваются с иллюстрациями в рамках модели "сущность-связь". Диаграммы классов в нотации UML рассматриваются более детально в разделе A.III.2.1.1.1.
Aris — Моделирование Бизнес-Процессов


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

<< Предыдущая статьяСледующая статья >>
1.1. Aris — Моделирование Бизнес-Процессов 1.3. Стратегический анализ бизнес-процессов





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