2 Уровень

и т.д.

Модель процессов

Цепочка процесса связана с событиями. Данная модель предназначена для детального описания процессов выполняемых в рамках одного подразделения несколькими подразделениями или конкретными сотрудниками. Она позволяет выявлять взаимосвязи между организационной и функциональной моделями. Модель процессов отображает последовательность функциональных шагов в рамках одного бизнес процесса, которые выполняются организационными единицами за ограниченный промежуток времени, налагаемый на отдельные функции. Для каждой функции могут быть определены: начальное и конечное событие, ответственные исполнители, материальные и документальные потоки, а так же проведена декомпозиция на более низкие уровни. Модель процессов является наиболее информативно и удобной при описании деятельности подразделений организации. Процедурная последовательность функций в рамках бизнес процессов отображается виде цепочки процесса, где для каждой функции могут быть определены начальное и конечное событие, которые активизируют функции или могут быть результатом выполнения какой-то функции. В данной модели описание события должно содержать не только информационный объект (заказ), но и описание изменения состояния (выполнение заказа).

Переключение функции возможно с одной позиции на другую. События самостоятельно переключают функции и могут быть результатом её выполнения. Упорядочивание комбинаций событий и функций в последовательности позволяет создать событийные цепочки процессов.

Событийная цепочка

Заказ на Появилась

производство необходимость

получен во внешней детали

Отдел информационных

Отследить Управлять Закупить технологий

заказ на производством деталь

производство Сведения о

поставщиках

Заказ клиента Изделие Внешняя

обработан создано деталь

получена

Отгрузить

деталь Подготовка

соответствующих

документов

Можно рекомендовать следующие правила модели процессов:

1. Графические элементы процесса или последовательность событий и функций располагается сверху вниз.

2. Графические элементы обозначающие исполнителей функции располагаются справа от функции.

3. Документы, используемые при выполнении функции, а так же формируемые в результате выполнения функции располагаются слева от функции.

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

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

Этот тип подели отражает дополнительные связи и отношения, детализирующие эту функцию на уровне данных.

Данные о

прескуранте

цен в меню

Определить дату Данные о запросах

Делает заказ и время потребителя

Заказ выполняется

Оплата счёта

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

Таким образом пользователь при моделировании процесса с помощью модели управления моет ограничиться описанием событий и функций, затем связать с функцией диаграмму окружения функции и уже в ней отразить дополнительные детализирующие связи и отношения. Это позволяет отображать бизнес процессы более чётко, а так же поясняет название нового типа моделей.

Общие принципы моделирования Айрис

Моделирование деятельности подразумевает создание модели адекватно отражающей реальный объект при этом моделирование должно проходить в соответствие соблюдения ряда требований и выполнением набора правил однозначных для понимания и единых для всех участников моделирования к подобным правилам относятся:

1. Выделение набора используемых моделей, интерпретация выбранных моделей, принятие правил их построения.

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

3. Определение глубины моделирования.

4. Задание правил именования объектов и моделей.

5. Определение правил проверки созданных моделей.

Выбор типов моделей

Интегрированная система Айрис содержит множество моделей, каждая из которых отнесена к определённому типу представления и уровню описания, полный набор моделей является избыточным для проведения конкретного проекта, так как существуют группы моделей, представляющих альтернативные способы описания.

Кроме того, использование большого количества различных типов моделей почти всегда означает дублирование описания, то есть представление одной и той же информации с нескольких точек зрения на разных уровнях обобщения. При подготовки каждого проекта, проводимого в среде Айрис необходимо определиться с набором используемых типов моделей, а следовательно объектов их атрибутов и связей. Выбор методов моделирования зависит от описываемого объекта и перечня задач, которые должны быть решены, например, при выборе моделей, которые будут использоваться для комплексного описания системы управления и её окружения необходимо учитывать следующие обстоятельства:

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

2. Две или несколько моделей могут дополнять друг друга.

3. Две и более модели могут быть альтернативой друг другу.

4. В каждом проекте должен быть использован свой ограниченный и настроенный набор моделей, основанный на методологии Айрис.

5. Задание методологии моделирования для каждого конкретного случая осуществляется путём настройки методологических фильтров Айрис и назначения этих фильтров соответствующим пользователям и их группам, участвующим в проводимых работах.

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

7. Выбор моделей напрямую зависит от целей моделирования и соответственно ожидаемого результата, в этом случае трудно дать однозначное соответствие моделей решаемым задачам.

Структурирование информации при моделировании

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

• на типах используемых моделей;

• на функциональной структуре компании;

• на структуре процессов компании;

• на этапах проведения работ по моделированию;

• модулях и функциях стандартных систем управления;

• на комбинации указанных выше критериев.

Иерархия папок, построенная в соответствие с типами моделей, используются редко, так как концепция Айрес сама по себе подразумевает разделение предметных областей на типы представления и уровни описания внутри которых выделяются типы моделей. Это разделение поддержано функционалом системы Айрес, обеспечивающим фильтрацию и сортировку моделей в соответствие с этим критерием.

Варианты моделей

Для цели создания и анализа альтернативных моделей используется концепция вариантов, подразумевающая создание вариантов моделей и объектов с этой концепцией связаны такие понятия как мастер (исходная модель) и вариант (так модель, которая получается на основе альтернативы). Каждая модель или объект может иметь несколько вариантов, но только одного мастера. При создании варианта модели делается её точная копия, состоящая из объектов, которые являются вариантами объектов мастер-модели. В последствие модель и каждый объект могут быть изменены независимо от мастер-модели и её объектов, в том числе путём удаления объектов или создания новых. После внесения всех необходимых изменений может быть проведена процедура сравнения модели варианта с её мастером. При это сравнение может происходит по нескольким сценариям. Таким образом, сравнение моделей может проводиться на экспертном уровне, когда специалист в предметной области проводит визуальный анализ альтернативных моделей и исходя из своего опыта выбирает наиболее предпочтительный вариант. Можно провести более точное сравнение. Для этого создаётся несколько вариантов исходной процедуры, причём все варианты могут отличаться друг от друга:

• количеством исполнителей;

• наличием или отсутствием дублирования исполнителей;

• параллельными работами, выполняемыми различными исполнителями;

• графиками работ исполнителей и их дублёрами.

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

Отношение между моделями

Связи или отношения между моделями Айрис реализуются через общие для них объекты, выделяют два вида отношений между моделями:

1. использование одного и того же объекта в нескольких моделях;

2. детализация объекта с помощью модели.

Для иллюстрации первого вида отношений можно привести следующий пример: тип объекта функция существует как в модели процесса, так и в модели типа дерево-функций, то есть они связаны через общие для них функции, при этом одни и те же типы объектов в различных моделях могут изображаться различными символами – это необходимо для конкретизации предназначения типа объекта. Причём следует отметить, что при использование одного и того же объекта в нескольких моделях каждая из них содержит его различные экземпляры, создание нового экземпляра осуществляется по средствам последовательности операций «копировать и вставить». Детализация будет проводиться путём привязки моделей данному экземпляру для этого следует воспользоваться командой «создать новую» во вкладке диалогового окна. При этом, детализация будет создана не для каждого экземпляра объекта, а для его описания.

Указанные два механизма формируют сложную систему взаимосвязей моделей, обеспечивающую комплексный взгляд на моделируемый объект как с точки зрения различных аспектов его функционирования, так и с точки зрения различных форм его описания.

Для выявления отношений между моделями необходимо выявление глубины моделирования.

….

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

• степени обобщения и детализации разрабатываемых моделей;

• количества уровней моделей, представляющих переход от общих моделей к детальным.

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

Иерархические модели – это модели, которые отражают подчинение объектов одного типа другому. К ним относятся: диаграмма целей, дерево функций, организационная схема. Для этих типов моделей необходимо определить количество отражаемых на одной диаграмме уровней и иерархий.

Неиерархические модели – это модели, которые отражают взаимосвязь объектов одного уровня. К ним можно отнести модель процесса. В этом случае выполняется следующая закономерность: чем меньшее количество уровней используется, тем более детальными, а значит и загруженными получаются модели. Таким образом, формируется карта иерархии моделей, где запечатлён от моделей верхнего уровня обобщения к детальным моделям.

Правила именования и оформления моделей

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

Первый определяет формы используемых слов и словосочетаний, здесь имя функции состоит из глагола, отражающего операцию и существительного, указывающего на объект, над которым эта операция производится. Имя события состоит из существительного, указывающего на объект и глагола отражающего операцию, которая была произведена над этим объектом. Имя сущности отражает описываемый её объект предметной области, задаётся в виде единственного существительного. Имена типов отношений могут формироваться двумя способами, если возможно, то желательно использовать независимый термин, производимый из отношений. Во всех других случаях имена формируются связыванием имён типов сущностей, находящихся в отношениях. Если выбранное имя длиннее сорока символов, рекомендуется использовать логичное однозначное сокращение. В этом случае полное имя должно быть введено в атрибут объекта. Сам по себе синтаксический аспект именования не может гарантировать единство названий в проекте. Одно и тоже действие может быть названо несколькими способами, то есть с помощью слов близких по смыслу при решении семантической проблемы целесообразно составить глоссарий терминов для именования объектов. Для анализа и описания терминологии предметной области могут быть использованы модели специальных терминов. Информация о явных объектах, таких как устоявшиеся формы рабочих документов, типовые отчёты, стандартные бланки, может быть занесена в базу данных ещё до начала моделирования. При этом все участники моделирования будут использовать уже занесённые объекты, а не создавать новые. Таким образом, снижаются трудозатраты на поддержание моделей в целостном виде. Одним из важных факторов успеха моделирования является получение наглядных моделей, которые с лёгкостью воспринимаются всеми заинтересованными лицами. Такое качество может быть достигнуто при выполнении правил выполнения моделей к правилам графического оформления объектов и моделей относят:

• внешний вид объектов;

• соответствующее взаимное расположение объектов в модели;

• отображение важных характеристик объектов в поле моделирования.

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

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

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

Заданные два вида правил позволяют осуществить проверку моделей. К синтаксическим относятся общие правила использования и соединения объектов в моделях, а также правила детализации объекта в модели определённого типа. Синтаксические правила определяются методологией Айрис, а также дополнительными настройками, ограничивающими применение этой методологии. Проверка следования этим правилам проводится в процессе моделирования, то есть система не позволит выполнить действие, непредусмотренное методологией.

Семантические правила связаны с синтаксическими правилами заполнения моделей. По семантическим правилам определяется степень полноты проработки и согласованность моделей и объектов. Модель процесса является полноценной, если для каждой функции этого процесса определён как исполнитель так и ответственный. Модели процессов и организационных структур являются согласованными только в том случае, если все организационные элементы, представленные в моделях процесса, находят своё отражение в моделях организационных структур. Для проверки следования семантическим правилам используется механизм семантических проверок, реализованный в модуле Айрес. Проверки проводятся после завершения процесса моделирования. В системе Айрес выделено 7 основных типов правил семантических проверок:

1. правило существования объектов;

2. правило взаимосвязи объектов;

3. правило структуры объектов;

4. правило структуры моделей;

5. правило атрибутов объектов;

6. правило атрибутов связей;

7. правило детализации объектов.

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

Правила существования объектов в системе Айрис.

1. Функция из модели процесса существует в дереве функций.

2. Функция из модели процесса существует в модели выбора процесса.

3. Функция из дерева функций не присутствует в другом дереве функций.

4. Организационный элемент из модели процесса существует в организационной модели.

5. Сущность из модели процесса существует в модели данных.

6. Информационная функция существует в структуре системы.

Правила взаимосвязи объектов в системе Айрис:

• Каждая функция должна иметь исполнителя.

• Каждое подразделение должно содержать в своём составе как минимум одну должность.

• Для каждой информационной системы должен быть определён ответственный за разработку.

Правила структуры моделей в системе Айрис (с помощью этих правил проверяют корректность формирования структуры, взаимосвязи объектов в модели, правила объединены в несколько групп.):

1. Общие структурные правила для всех типов моделей.

• каждый объект должен иметь одно или более соединений с другими объектами;

• объект не может быть замкнут сам на себя;

• каждый путь должен начинаться и заканчиваться событием или интерфейсом в другой процесс;

• проверка корректности количества входящих и исходящих соединений логических операторов;

• все функции и события должны иметь только одно входящее и одно исходящее соединение.

2. Специальные структурные правила для иерархических моделей.

• возможен только один корень;

• каждый объект может иметь только одного родителя;

• разрешено только одно соединение между двумя объектами;

• все исходящие соединения объекта должны иметь один и тот же тип;

• все соединения в модели должны иметь также один и тот же тип;

• только функции без исходящих соединений могут быть детализированы;

3. Детализация функций системы Айрис.

• функция должна быть детализирована в виде дерева функций;

• функция должна быть детализирована в виде диаграммы окружения функций;

Для вышеназванных функций должны выполняться следующие условия:

• существование объектов;

• взаимосвязи между ними;

• существование атрибутов этих объектов.

Анализ моделей

Анализ является важной частью методологии Айрис, позволяющий получить информацию об оптимальности модели. Анализ реализуется при помощи стандартных или разработанных пользователем сценариев. В Айрис возможны следующие сценарии стандартного блока для анализа моделей и объектов:

1. Организационные изменения в процессе.

2. Информационные разрывы в процессе.

3. Прикладные системы в процессе.

4. Классификация функций.

5. Сравнение моделей.

6. Сравнение вариантов моделей.

Кроме этого, доступно ещё 2 сценария для анализа моделей. Правила поведения анализа моделей и объектов хранятся в каталоге, причём между ними имеется чёткое разделение: одни их них ориентированы на проверку моделей, а вторые на проверку объектов. Стандартные сценарии анализа моделей и объектов делятся по следующим направлениям:

1. Организационные изменения – данный сценарий применяется для разновидности моделей производственного и офисного процессов, определяет степень ориентированности на процесс, причём расчёт основывается на количестве переходов ответственности от одного исполнителя к другому.

2. Информационные разрывы по стандартному сценарию используются для анализа производственного и офисного процесса. В ходе анализа определяется коэффициент, отражающий степень информационных разрывов процесса. Этот коэффициент может принимать значения от нуля до единицы. Чем ниже степень информационной интеграции в процессе, тем выше значение коэффициента.

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

4. Сценарий классификации функций применяется для анализа всех моделей, содержащих объекты типа функция. Проводится группировка всех функций выбранных моделей, согласно значению атрибута определённого типа.

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

6. Сценарий сравнения вариантов моделей применяется для сравнения только двух моделей, мастер моделей и её варианта.

7. Так же существуют сценарии анализа причинно-следственной диаграммы, дерева функций, модели структуры и организационной схемы. Данные сценарии выводят результаты сравнения фактических и планируемых показателей достижения цели компании.

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

Определение прав доступа

Для организации доступа к базе данных, содержащих модели создаются элементы Айрис – это пользователи и их группы. Определение этих элементов обеспечивает:

1. Распределённое моделирование.

2. Структурированный, контролируемый доступ к моделям организации.

3. Распределение полномочий и ответственности участников.

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

Администратор сервера – это пользователь с особыми привилегиями, он является единственным пользователем, отвечающим за администрирование на сервере. Он может создавать, реорганизовывать, удалять, сохранять и восстанавливать базы. Как правило, он имеет системное имя, которое не может быть изменено. Администратор сервера получает пароль, который может быть изменён в случае необходимости. В задачи администратора сервера входят: установка и проверка базы данных сервера, установка программного обеспечения сервера, создание новых баз данных, резервное копирование без данных, восстановление после сбоев, обеспечение совместимости с новыми версиями инструментальной системы Айрис, создание баз данных пользователей.

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

Администратор базы – создаётся в каждой новой базе и не может быть удалён. Это тип пользователя в среде Айрис, который имеет все права на базу данных. В его задачи входит: формирование папок, управление пользователями, управление правами доступа, управление языками и шрифтами. Администратор базы является исполнителем решений руководителя проекта по моделированию, который в случае необходимости может самостоятельно осуществлять настройки.

В задачи руководителя проекта по моделированию входят: администрирование процесса моделирования, определение структуры модели организации и прав доступа, выбор методов моделирования, определение правил автоматической идентификации объектов, принятие решений о форме отчётности, мониторинг объектов и моделей.

Рядовые пользователи осуществляют работы по моделированию в соответствии и их правами, выделенными с учётом их роли. Обычно для удобства администрирования пользователи объединяются в группы пользователей, причём каждый пользователь имеет набор прав, образованный на основе его личных прав и прав, полученных по средствам вхождения в одну или несколько групп пользователей. Так же обычно среди пользователей выделяется так называемый гость, который имеет право навигации по моделям без возможности их изменения. Все пользователи за исключением администратора должны быть введены в базу данных. Каждый пользователь имеет свои индивидуальные настраиваемые свойства: каждый пользователь имеет методологические фильтры, атрибуты, параметры идентификации, пароль, право на вхождение в группы пользователей и функциональные привилегии.

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

Права доступа отдельных пользователей или их групп к моделям и объектам могут быть определены через свойство папок. Обычно устанавливают следующие права: нет доступа, только чтение, чтение и запись, чтение и запись и удаление.

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

Среда Айрис имеет развитую систему доступа к базам данных моделей – это означает, что возможна организация структурированного доступа участников к информации по моделям, а так же исключение нежелательных посетителей. Таким образом, система Айрис как инструментарий для комплексного моделирования и анализа деятельности организации заставляет серьёзно подойти к процессу моделирования с точки зрения методологии, правил проверки и распределения доступа. Игнорирование данного этапа может привести к получению непригодного для анализа материала виде неполноценных и несогласованных моделей, которые в этом случае не будут отличаться от других способом отражения информации.