Методика моделирования процессов
Оглавление
1.... Стандарты используемых моделей. 2
1.1. Модель организационной структуры.. 2
1.2. Модель жизненных ситуаций. 2
1.3. Модель цепочки добавленного качества. 2
1.4. Модель выполнения государственной (муниципальной) функции. 2
1.5. Диаграмма окружения административной процедуры.. 2
1.6. Модель нормативных правовых актов. 2
1.7. Модель документов и данных. 2
1.8. Диаграмма типа прикладных систем.. 2
2.... Правила моделирования. 2
2.1. Общие замечания. 2
2.2. Наименование объектов. 2
2.3. Разрешение конфликтов наименования объектов. 2
2.4. Заполнение дополнительных атрибутов объектов. 2
2.5. Использование типов связей объектов моделей. 2
2. Стандарты используемых моделей
В настоящем разделе рассматриваются типы моделей, которые могут применяться при моделировании организационно-функциональной структуры Органов исполнительной власти (ОИВ) и местного самоуправления (ОМС), наделенных полномочиями для реализации (выполнения) государственных (муниципальных) функций и услуг. Моделирование осуществляется с помощью программных продуктов семейства ARIS.
2.1. Модель организационной структуры
1.1.1. Тип моделей организационной структуры в ARIS – Organizational chart.
1.1.2. Для анализа организационной структуры используются схемы организационной структуры, представленные в произвольном формате, а также положения о департаментах, управлениях, отделах и т. д. На основе этой информации формируется организационная структура в виде организационной схемы ARIS.
1.1.3. Организационная схема описывает организационные единицы разного уровня и их взаимосвязи. Организационные единицы, определяемые рассматриваемой моделью, могут использоваться и в других моделях.
1.1.4. В модели организационной структуры отражаются:
§ Подразделения ОИВ и ОМС;
§ Наименование должности и фамилии руководителей подразделений.
1.1.5. Модель строится иерархически, от верхнего уровня структуры к нижнему. В модель верхнего уровня включаются самостоятельные подразделения, входящие в структуру ОИВ и ОМС. Каждое из них детализируется на более низкие уровни — уровни структурных подразделений.
1.1.6. Каждое структурное подразделение, в свою очередь, детализируется на структурные подразделения в его составе, которые изображаются на одной модели.
1.1.7. Низшим уровнем является описание подразделений на уровне должностей - штатных единиц, занимаемых конкретными сотрудниками.
1.1.8. На Рис. 1 приведен фрагмент организационной схемы верхнего уровня (уровня обзорных моделей).
Рис. 1Организационная схема обзорного уровня
1.1.9. Применение модели этого же типа на детальном уровне иллюстрируется приведенной на Рис. 2 моделью, детализирующей представленную на Рис. 1организационную единицу — Территориальные управления Россельхознадзора.
Рис. 2 Организационная схема детального уровня
2.2. Модель жизненных ситуаций
2.2.1. Тип модели жизненных ситуаций в ARIS – Objective diagram.
2.2.2. Модель жизненных ситуаций описывает набор жизненных ситуаций, для разрешения которых гражданам (заявителям) необходимо обращаться в уполномоченные ОИВ и ОМС с привязкой жизненных ситуаций к государственным (муниципальным) функциям или услугам, выполнение которых разрешает жизненные ситуации граждан (заявителей).
2.2.3. Связь жизненной ситуации с набором государственных (муниципальных) функций осуществляется через комплексный процесс, что свидетельствует об иерархичности связи.
2.2.4. Типовая модель жизненных ситуаций приведена на Рис. 3
Рис. 3 Пример модели жизненных ситуаций
2.3. Модель цепочки добавленного качества
2.3.1. Тип моделей цепочки добавленного качества в ARIS – Value-added chain diagram.
2.3.2. Модель цепочек добавленного качества описывает комплексные процессы ОИВ и ОМС, которые реально влияют на результат выполнения государственных (муниципальных) функций и услуг. Эти процессы создают последовательность функций, формируя добавленные значения: стоимость, количество, качество и т. д.
2.3.3. Описываемые функции могут размещаться в модели комплексного процесса согласно иерархическому принципу, т. е. наиболее важные функции располагаются левее и выше. Эта иерархия всегда иллюстрирует подчинение функций.
2.3.4. Также функции комплексного процесса могут располагаться последовательно, обозначая логическую последовательность функций при преобразовании входных потоков в выходные.
2.3.5. Типовая модель комплексного процесса приведена на Рис. 4
Рис. 4 Пример модели цепочки добавленного качества
2.3.6. Для обеспечения простоты восприятия и высокого уровня наглядности моделей комплексных процессов, каждая из них должна содержать ограниченное (не более 10) количество объектов. При описании комплексных процессов данное условие обеспечивается соответствующим агрегированием государственных (муниципальных) функций и их детализацией на моделях более низкого уровня - моделях выполнения государственной (муниципальной) функции (описание модели см. в п. 1.4). Таким образом, модели комплексных процессов образуют иерархическую структуру. Верхним уровнем иерархии является Цепочка добавленного качества. Взаимосвязь модели цепочки добавленного качества и моделей государственных (муниципальных) функций (модель Событийная цепочка процесса) показана на Рис. 5
Рис. 5Взаимосвязь модели цепочки добавленного качества и моделей государственных (муниципальных) функций
2.4. Модель выполнения государственной (муниципальной) функции
2.4.1. Тип моделей выполнения государственной (муниципальной) функции в ARIS – eEPC (Extended event driven process chain).
2.4.2. Событийная цепочка процесса (далее — модель еЕРС) предназначена для детального описания административных процедур, выполняемых в рамках одного подразделения, несколькими подразделениями или конкретными служащими. Модель еЕРС отражает последовательность административных процедур в рамках одной государственной (муниципальной) функции, которые выполняются организационными единицами, а также ограничения по времени, налагаемые на отдельные административные процедуры.
2.4.3. Для каждой административной процедуры должны быть определены начальное и конечное события, ответственные исполнители и документарные потоки, сопровождающие модель.
2.4.4. Последовательность административных действий в рамках государственной (муниципальной) функции отображается в виде цепочки процесса, где для каждой административной процедуры могут быть определены начальное и конечное события. Событие — это состояние, которое является существенным для целей управления реализацией государственных (муниципальных) функций и услуг и которое оказывает влияние или контролирует дальнейшее развитие одной или более государственных (муниципальных) функций.
2.4.5. События активизируют административные процедуры, т. е. передают управление от одной административной процедуры к другой. Они могут быть также результатом выполнения административной процедуры. В отличие от административных процедур, которые имеют некоторую продолжительность, события происходят мгновенно.
2.4.6. Описание события должно содержать не только информационный объект («заявка»), но и описание изменения состояния («зарегистрирована»). События переключают административные процедуры и могут быть результатом выполнения административной процедуры. Упорядочивание комбинации событий и административных процедур в последовательность позволяет создать событийные цепочки процессов (функций). С помощью этих моделей государственные (муниципальные) функции представляются как логические последовательности событий/административных действий.
2.4.7. Типовая модель государственной (муниципальной) функции приведена на Рис. 6
Рис. 6 Типовая модель государственной (муниципальной) функции
2.4.8. Для обеспечения простоты восприятия и высокого уровня наглядности моделей государственных (муниципальных) функций, каждая из них должна содержать ограниченное (не более 10) количество объектов.
2.5. Диаграмма окружения административной процедуры
2.5.1. Тип диаграммы окружения административной процедуры в ARIS – Function allocation diagram.
2.5.2. Диаграмма окружения административной процедуры используется для детального описания окружения административной процедуры.
Анализ диаграмм окружения позволяет выявить:
§ обеспеченность административной процедуры входной информацией;
§ наличие/отсутствие автоматизации административной процедуры;
§ «качество» автоматизации административной процедуры;
§ перечень информационных систем, поддерживающих данную административную процедуру.
2.5.3. Данная модель используется, если административная процедура на модели выполнения государственной (муниципальной) функции имеет большое информационное окружение (более 5 объектов), и его целесообразно вынести на отдельную диаграмму.
2.5.4. Типовая диаграмма окружения административной процедуры приведена на Рис. 7
Рис. 7 Диаграмма окружения административной процедуры
2.6. Модель нормативных правовых актов
2.6.1. Тип моделей нормативных правовых актов в ARIS – Knowledge structure diagram.
2.6.2. Модель нормативных правовых актов описывает состав нормативных правовых актов, регламентирующих выполнение комплексного процесса, государственной (муниципальной) функции или административной процедуры органами исполнительной власти или местного самоуправления.
2.6.3. Нормативные правовые акты могут быть взаимосвязаны и иерархически упорядочены. Регламентирующие документы, определяемые рассматриваемой моделью, могут использоваться и в других моделях.
2.6.4. Типовая модель нормативных правовых актов приведена на Рис. 8
Рис. 8 Модель нормативных правовых актов
2.7. Модель документов и данных
2.7.1. Тип моделей документов и данных в ARIS – Information carrier diagram.
2.7.2. Документы и данные могут иметь материальное воплощение в виде документов, а могут и не иметь такого, например, информация, передаваемая по телефону или электронной почте.
2.7.3. При моделировании государственных (муниципальных) функций приходится иметь дело с многочисленными документами и данными, определяющими информационные и иные объекты в ОИВ и ОМС. Модель документов и данных позволяет манипулировать различными документами (данными) как синонимами или как составными частями более общего документа.
2.7.4. Документы и данные могут быть взаимосвязаны и иерархически упорядочены. Документы и данные, определяемые рассматриваемой моделью, могут использоваться и в других моделях.
2.7.5. Модель документов и данных применяется для отражения структуры и состава информационных потоков и их классификации.
2.7.6. Пример модели документов и данных приведен на Рис. 9
Рис. 9 Модель документов и данных
2.8. Диаграмма типа прикладных систем
2.8.1. Тип диаграмм типа прикладных систем в ARIS – Application system type diagram.
2.8.2. Диаграмма типа прикладных систем предназначена для описания используемых информационных систем.
Анализ моделей типа прикладной системы позволяет выявить:
§ перечень информационных систем;
§ модульную структуру информационных систем.
2.8.3. Информационные системы могут быть взаимосвязаны и иерархически упорядочены. Информационные системы, определяемые рассматриваемой моделью, могут использоваться и в других моделях.
2.8.4. Пример диаграммы типа прикладных систем приведен Рис. 10
Рис. 10Диаграмма типа прикладных систем
3. Правила моделирования
В настоящем разделе изложены правила именования объектов, правила использования атрибутов объектов и правила использования допустимых связей между объектами при описании организационно-функциональной структуры Органов исполнительной власти (ОИВ) и местного самоуправления (ОМС), наделенных полномочиями для реализации (выполнения) государственных (муниципальных) функций и услуг. Моделирование осуществляется с помощью программных продуктов семейства ARIS.
3.1. Общие замечания
Общими для всех создаваемых моделей являются следующие правила, требования и замечания:
§ для обеспечения простоты восприятия и высокого уровня наглядности моделей детального уровня, каждая из них должна содержать ограниченное (оптимально не более 10) количество функциональных объектов;
§ наличие специального значка ниже и справа от объекта (см. Рис. 11) указывает на то, что данный объект (организационная единица либо функция) детализирован на отдельной модели.
Рис. 11 Указатель наличия детализирующей модели
3.2. Наименование объектов
Наименование объекта, графически отображаемое на модели (поле Name в свойствах объекта) не может состоять более чем из 80 символов, включая пробелы. В связи с этим ограничением, для длинных названий объектов необходимо применять сокращение, а полное название приводить в поле Description/Definition (см. Рис. 12)
Рис. 12 Заполнение атрибута Description/Definition
3.3. Разрешение конфликтов наименования объектов
3.3.1. При задании имен вновь создаваемого объекта периодически может возникать предупреждение о том, что объект такого типа с тем же именем уже существует, т. е. задаваемое имя не является уникальным в рамках репозитария (см. Рис. 13). В этом случае целесообразно просмотреть весь список моделей, где этот объект встречается, после чего либо использовать уже имеющийся объект, либо дать ему другое имя.
Рис. 13 Пример предупреждения о не уникальности имени для объекта определенного типа
3.3.2. В случае появления такого предупреждения следует выполнить следующие рекомендации:
3.3.2.1. Установить, к какому типу информационной системы относится этот объект.
3.3.2.2. Если новый объект описывает тот же объект (например, поле справочника и поле документа, использующего информацию этого справочника), целесообразно использовать уже существующий объект.
3.3.2.3. Если новый объект относится к другой информационной системе, целесообразно создать новый объект.
3.3.2.4. В случае если данный объект физически имеет одно и то же значение, то необходимо использовать один и тот же объект.
3.3.2.5. В случае если объекты имеют различные физические значения (например, поле «Id документа А» и поле «Id документа В», то необходимо использовать различные объекты).
3.4. Заполнение дополнительных атрибутов объектов
3.4.1. Для обеспечения автоматической генерации регламентных и отчетных документов, для некоторых типов объектов необходимо соблюдать следующие правила заполнения дополнительных атрибутов:
3.4.2. Для объекта Ответственный исполнитель функции (Organizational unit)
Атрибут | Наименование в ARIS | Описание |
Идентификатор | Identifier | Уникальный идентификатор |
Полное наименование подразделения | Fullname (Description/Definition в случае если длина имени подразделения превышает 80 символов) | Полное наименование в соответствие с уставными или иными документами |
Краткое наименование подразделения | Name | Краткое наименование в соответствие с уставными или иными документами |
Статья БС | Free attributes | Статья бюджетной классификации |
ФИО контактного лица | Free attributes | ФИО контактного лица |
Электронная почта | Free attributes | Электронная почта |
Телефон | Free attributes | Телефон |
Факс | Free attributes | Факс |
График работы | Free attributes | График работы |
1.1.1. Для объекта Функция (Function)
Атрибут | Наименование в ARIS | Описание/ Правило заполнения |
Идентификатор | Identifier | Уникальный идентификатор |
Полное наименование | Fullname (Description/Definition в случае если длина имени подразделения превышает 80 символов) | Полное наименование функции (услуги) как оно приводится в соответствующих нормативных правовых актах |
Краткое наименование | Name | Краткое наименование функции (услуги) как оно приводится в соответствующих нормативных правовых актах (при наличии) |
Вид функции | Free attributes | Вид функции (услуги). Например, «контрольно-надзорные», «нормотворческие». |
Категория функции | Free attributes | Категория функции (услуги) |
Категория заявителей | Free attributes | Категория заявителей |
Основание для отказа | Free attributes | Основание для отказа |
Плата заявителя | Free attributes | Наличие платности для заявителя |
Время выполнения | Avg. processingtime | Количество времени, затрачиваемое на выполнение функции |
Стоимость | Total costs | Стоимость выполнения функции |
3.4.3. Для объекта Нормативный акт (Documented knowledge)
Атрибут | Наименование в ARIS | Описание/ Правило заполнения |
Идентификатор | Identifier | Уникальный идентификатор |
Полное наименование | Fullname (Description/Definition в случае если длина имени подразделения превышает 80 символов) | Полное наименование нормативного акта |
Краткое наименование | Name | Краткое наименование нормативного акта |
Принявший орган | Source | Принявший орган |
Дата принятия | Free attributes | Дата принятия нормативного правового акта |
Номер акта | Short description | Номер акта |
Статус акта | Free attributes | Статус акта. Например, «действующий», «недействующий». |
Статья | Free attributes | Номер статьи |
Тема регулирования | Free attributes | Тема регулирования |
Документ | Free attributes | К объекту «Нормативный правовой акт» можно прикрепить соответствующий документ |
3.5. Использование типов связей объектов моделей
3.5.1. Связи на моделях представляются в виде линий или стрелок, соединяющих объекты (см. Рис. 14).
Рис. 14 Пример отражения связей между объектами
3.5.2. Типы связей для моделей организационной структуры:
Объект-источник | Объект-мишень | Тип связи |
Подразделение (Organizational unit) | Подразделение (Organizational unit) | Состоит из (is composed of) |
Подразделение (Organizational unit) | Должность (Position) | Состоит из (is composed of) |
Тип должности (Person type) | Подразделение (Organizational unit) | Принадлежит (belongs to) |
Тип должности (Person type) | Подразделение (Organizational unit) | Может принадлежать (can belong to) |
Должность (Position) | Подразделение (Organizational unit) | Является административным руководителем для (Is disciplinary superior to) |
Должность (Position) | Подразделение (Organizational unit) | Является руководящей для (is Organization Manager for) |
Должность (Position) | Должность (Position) | Является административным руководителем для (is disciplinary superior to) |
3.5.3. Типы связей для моделей цепочки добавленного качества
Объект-источник | Объект-мишень | Тип связи |
Цепочка добавленного качества (Value-added chain) | Цепочка добавленного качества (Value-added chain) | Предшествует (is predecessor of) |
Цепочка добавленного качества (Value-added chain) | Цепочка добавленного качества (Value-added chain) | Является процессно-ориентированным руководителем (Is process-oriented superior) |
3.5.4. Типы связей для моделей выполнения государственной (муниципальной) функции
Объект-источник | Объект-мишень | Тип связи |
*Оператор (operator[1]) | Оператор (operator) | Предшествует (links) |
*Оператор (operator) | Событие (Event) | Порождает событие через (Leads to) |
* Оператор (operator) | Функция (Function) | Активизирует (activates) |
* Оператор (operator) | Внешний процесс (Process interface) | Активизирует (activates) |
Информационная система (Application system) | Функция (Function) | Поддерживает (Supports) |
Событие (Event) | * Оператор (operator) | Оценивается с помощью (Is evaluated by) |
Событие (Event) | Функция (Function) | Активизирует (activates) |
Событие (Event) | Внешний процесс (Process interface) | Активизирует (activates) |
Функция (Function) | * Оператор (operator) | Порождает событие через (Leads to) |
Функция (Function) | Событие (Event) | Создает (Creates) |
Тип должности (Person type) | Функция (Function) | Выполняет (executes) |
Внешний процесс (Process interface) | * Оператор (operator) | Порождает событие через (Leads to) |
Внешний процесс (Process interface) | Событие (Event) | Создает (Creates) |
[1]Символ «*» означает «любой»
