close

Вход

Забыли?

вход по аккаунту

...процессов_Методология описания ландшафта (5)

код для вставкиСкачать
ЕДИНАЯ ГОСУДАРСТВЕННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА В СФЕРЕ
ЗДРАВООХРАНЕНИЯ
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА К СИСТЕМНОМУ ПРОЕКТУ
КНИГА 1 ОСНОВНЫЕ СИСТЕМОТЕХНИЧЕСКИЕ РЕШЕНИЯ ПО
ПОСТРОЕНИЮ ЕГИСЗ
РАЗДЕЛ 4 ОБЕСПЕЧЕНИЕ ФУНКЦИОНАЛЬНОЙ И ТЕХНОЛОГИЧЕСКОЙ
СОВМЕСТИМОСТИ КОМПОНЕНТОВ ЕГИСЗ
РАЗДЕЛ 5 ОПТИМИЗАЦИЯ ПРОЦЕССОВ С ИСПОЛЬЗОВАНИЕМ
ТЕХНОЛОГИИ РАБОЧИХ ПОТОКОВ
РАЗДЕЛ 6 МЕТОДОЛОГИЯ ОПИСАНИЯ ФУНКЦИОНАЛЬНОГО И
АРХИТЕКТУРНОГО ЛАНДШАФТА КОМПОНЕНТ ЕГИСЗ
2
Содержание
4 Обеспечение функциональной и технологической совместимости
компонентов ЕГИСЗ ................................................................................................. 3
4.1 Обеспечение функциональной совместимости компонентов ...................... 3
4.1.1 Определение структур данных ............................................................ 4
4.1.2 Единые стандарты взаимодействия .................................................... 4
4.1.3 Единые правила анализа информации и принятия управленческих
решений .............................................................................................................. 5
4.1.4 Представление медицинской информации ........................................ 5
4.2 Обеспечение технологической совместимости компонентов ...................... 6
4.2.1 Реестр спецификаций интерфейсов обмена ....................................... 7
4.2.2 Принципы формирования спецификаций .......................................... 8
4.3 Совместимость с унаследованными системами ............................................ 9
4.4 Использование подсистемы интеграции прикладных систем .................... 10
5 ОПТИМИЗАЦИЯ ПРОЦЕССОВ С ИСПОЛЬЗОВАНИЕМ
ТЕХНОЛОГИИ РАБОЧИХ ПОТОКОВ................................................................ 13
5.1 Рабочие потоки ................................................................................................ 13
5.1.1 Анализ и обработка данных ............................................................... 16
5.1.2 Классификация и описание рабочих потоков .................................. 18
5.1.3 Анализ отношений/взаимодействий рабочих потоков ................... 18
5.1.4 Описание и обоснование проблемных мест ..................................... 21
5.1.5 Формулирование рационализаторских решений ............................. 21
5.1.6 Согласование ....................................................................................... 22
5.2 Оптимизация бизнес-процессов с использованием технологии
рабочих потоков .............................................................................................. 22
5.2.1 Текущая ситуация ............................................................................... 22
5.2.2 Дополнительные возможности .......................................................... 23
5.3 Заключение ...................................................................................................... 25
6 Методология описания функционального и архитектурного ландшафта
компонент ЕГИСЗ ................................................................................................... 26
6.1 Критерии выбора эффективной методики описания................................... 26
6.2 Обзор методологий описания функционального и архитектурного
ландшафта компонент ЕГИСЗ ....................................................................... 28
6.3 Выбор обоснованной методологии функционального и
архитектурного ландшафта компонентов ЕГИСЗ ....................................... 38
3
4
ОБЕСПЕЧЕНИЕ ФУНКЦИОНАЛЬНОЙ И ТЕХНОЛОГИЧЕСКОЙ
СОВМЕСТИМОСТИ КОМПОНЕНТОВ ЕГИСЗ
Обеспечение функциональной и технологической совместимости разнородных
компонентов в сложной, распределенной, многокомпонентной информационной
системе - ключевое требование к созданию ЕГИСЗ.
С архитектурной точки зрения ЕГИСЗ - это сложный комплекс компонентов,
работающих во взаимодействии друг с другом.
Система
состоит
из
разнородных
компонентов,
создаваемых
и
разворачиваемых поэтапно в разное время.
В настоящем разделе приводятся обоснования и решения по обеспечению
функциональной и технологической совместимости компонент ЕГИСЗ.
4.1
Обеспечение функциональной совместимости компонентов
Функциональная совместимость – это способность компонентов, входящих в
ЕГИСЗ, взаимодействовать друг с другом и обмениваться информацией в
соответствии с установленной процедурой для достижения
предсказуемых
результатов (см. ГОСТ Р ИСО/ТО 16056-1-2009).
Такая совместимость позволяет наращивать функциональные свойства
разработанных и существующих компонентов с минимально необходимыми для
этого затратами. Для достижения такой совместимости требуется, чтобы функции,
выполняемые компонентами системы, были четко определены, разграничены и
взаимоувязаны (см. Принцип модульности и уникальности функционала в Разделе
1).
Для обеспечения функциональной совместимости необходимо:

определить общие для разных компонентов структуры данных, а также
формат и протокол обмена данными;

выбрать стандарты, определяющие взаимодействие компонентов;

определить единые правила анализа информации и принятия
управленческих решений;
4

установить набор используемых стандартов представления медицинской
информации.
4.1.1 Определение структур данных
На этапе определения структур и состава данных, которые предназначены для
использования в различных компонентах ЕГИСЗ необходимо:

осуществить анализ существующих информационных моделей;

разработать модели данных вновь создаваемых компонентов;

осуществить выделение общих информационных компонентов, которые
будут предназначены для взаимодействия компонентов функциональных.
На этом же этапе необходимо определить правила описания интерфейсов,
определяющих взаимодействие функциональных компонентов. В качестве одной из
возможных нотаций описания таких интерфейсов может быть нотация язык
описания веб-сервисов и доступа к ним (WSDL – Web Services Description
Language).
Для достижения функциональной совместимости информационных систем
необходимо также формирование и поддержание в актуальном состоянии реестров
нормативно-справочной информации (НСИ), реестров отраслевых технологических
стандартов.
4.1.2 Единые стандарты взаимодействия
Единые стандарты позволяют не только организовать правильный обмен
информацией между компонентами, но и обеспечивают единый подход к обработке
данных всеми участниками информационного взаимодействия. Принцип единых
стандартов охватывает как обмен нижнего уровня (протоколы обмена, XML, SOAP),
так и ряд отраслевых стандартов по обмену информацией медицинского характера,
такие как стандарт ISO/HL7 27932, HL7 v.3.x CDA R2, IHE.
Единые стандарты поддерживают унификацию деловых и медицинских
процессов для поддержания единых правил принятия решений и стандартов
оказания медицинской помощи.
5
Взаимодействие между системами должно осуществляться на основе набора
специально разработанных документов – описаний интеграционных профилей.
4.1.3 Единые правила анализа информации и принятия
управленческих решений
Унификация процессов обработки информации медицинского характера
позволит ввести единую и актуальную систему индикаторов и показателей, что
обеспечит
возможность
принятия
своевременных
и
непротиворечивых
управленческих решений.
Кроме того, унификация процессов обработки информации позволит
однозначно определить какие функциональные компоненты реально обмениваются
информацией в процессе функционирования системы, что в свою очередь позволит
уточнить спецификации сервисов, обеспечивающих взаимодействие компонентов
ЕГИСЗ.
4.1.4 Представление медицинской информации
Интегрированная медицинская информация накладывает требования на
единообразие медицинских данных, их передачу и обработку. Для обработки такой
информации разработаны и широко используются международные стандарты.
4.1.4.1 Стандарт HL7
HL7 (Health Level 7 - Седьмой Уровень медицинского документооборота) —
стандарт обмена, управления и интеграции электронной медицинской информации.
Седьмым уровнем стандарт назван по аналогии с семью уровнями взаимодействия
открытых систем OSI, поскольку он описывает протокол обмена самого высокого
уровня. Этот стандарт описывает взаимодействие медицинских информационных
систем.
Стандарт
поддерживает
обмен
информацией
между
ИТ
системами,
функционирующими на самом широком спектре технических средств и языков
программирования.
Он
обладает
большой
степенью
стандартизации,
с
возможностью совмещения с местной системой стандартов и местными вариациями
6
и возможностью постепенного расширения по мере выявления новых требований.
Разработка стандарта ведется в тесном взаимодействии с другими организациями,
занимающимися стандартизацией.
Стандарт HL7 определяет обмен на уровне данных, а не прикладных систем.
Ни структура, ни архитектура прикладной системы, создавшей транзакцию, никак
не затрагиваются. Рамки стандарта HL7 ограничены спецификацией сообщений,
передаваемых прикладными системами, и событий, которые инициировали эти
сообщения.
В рамках стандарта существуют важные концепты (domains, домены),
определяющую структуру обмена и хранения информации, такие как Архитектура
Клинического
документа
(АКД,
CDA,
Clinical
Document
Architecture),
Управление сведениями о пациентах (PA, Patient Administration). В АКД
определён синтаксис и комплекс структур для полного выражения семантики
клинического документа. Все домены используют язык разметки информационных
объектов XML, стандартный для HL7 V3.
4.1.4.2 Стандарт DICOM
Стандарт DICOM (Digital Imaging and Communications in Medicine) —
отраслевой медицинский стандарт создания, хранения, передачи и визуализации
медицинских изображений и документов обследованных пациентов. Этот стандарт
широко
поддерживается
производителями
рентгеновского,
ультразвукового
оборудования, томографов.
4.2
Обеспечение технологической совместимости компонентов
Технологическая совместимость компонентов обеспечивается фиксацией
ключевых протоколов обмена, форматов данных, стандартизированных сетевых
служб, платформ создания приложений и аппаратных интерфейсов, обязательных к
использованию
внутри
их внешних интерфейсов.
информационной
системы, так
и
для
реализации
7
Стандартизация интерфейсов обмена компонентов и систем обеспечивает
интеграцию
не только
между
существующими,
но и вновь
создаваемыми
информационными системами.
Под «интерфейсом обмена» понимается граница между информационными
системами или их компонентами, через которую в процессе работы системы
осуществляются информационное взаимодействие.
Соответствие требованиям по стандартизации интерфейсов обмена является
обязательным как для компонентов внутри системы, так и для тех компонентов,
данные которых могут использоваться внешними информационными системами.
Требование касается как разрабатываемых в рамках государственного заказа
информационных систем, так и при поставке готовых программ.
Работа компонентов не должна зависеть от оборудования, на котором
построен проект. Кроме того, компоненты должны исполняться одинаково на
различных
операционных
системах,
либо
на
различных
версиях
одной
операционной системы.
4.2.1 Реестр спецификаций интерфейсов обмена
Все
разработчики
проекта
должны
иметь
доступ
к
спецификациям
интерфейсов обмена. Такие спецификации должны явно указываться в ТЗ на
разработку компонентов, либо содержаться в виде перечня на специально
выделенном ресурсе, доступном всем участникам проекта.
Регламент формирования такого перечня спецификаций, включающего не
только описание функций, но также форматов и протоколов обмена, должен
базироваться на полной открытости предусмотренных в нем процедур, включая
гласность исполнения регламента и принятия решений.
8
4.2.2 Принципы формирования спецификаций
При разработке спецификаций интерфейсов (интеграционных профилей)
необходимо придерживаться следующих принципов:

спецификация должна быть опубликована в виде документа,
содержащего информацию, достаточную для независимой от
разработчика стандарта реализации описанной в нем технологии;

отсутствие ограничений использования;

целостность;

авторитетность - предпочтение при выборе форматов и спецификаций
должно отдаваться стандартам, утвержденными ведущими
международными и отраслевыми организациями по стандартизации (ISO,
IETF, W3C, OASIS и др.);

отсутствие дискриминации - спецификация не должна явно или косвенно
устанавливать предпочтение каким-либо конкретным реализациям,
производителям или технологиям;

зрелость - практика использования спецификации должна
продемонстрировать ее стабильность и устойчивость, которые позволяют
достичь необходимых результатов с разумными затратами ресурсов и
времени; спецификация должна сопровождаться достаточным
количеством справочного материала и практическими наработками.

современность - предусмотренные спецификацией решения должны
соответствовать современному уровню развития информационных
технологий;

перспективность - спецификация должна иметь потенциал развития,
возможность создания расширений и наследуемых версий, готовность
разработчика к поддержке и развитию спецификации;

наличие рыночной поддержки - на рынке должно быть представлено
достаточное количество качественных и востребованных реализаций
данной спецификации;
9

наличие свободных реализаций - на рынке должны быть представлены
свободные реализации спецификации, позволяющие использовать ее без
дополнительных затрат и отчислений хотя бы на минимальном уровне
требований по соответствию;

адаптивность и гибкость - спецификация должна обеспечивать
достаточную приспособляемость к изменению объектов стандартизации,
целей и задач государственных информационных систем, а также
возможность учета национальной специфики (в отношении состава
данных, принятых административных процедур и законодательных
ограничений, поддержки языков субъектов федерации и т. п.);

успешный опыт применения спецификации в сходных областях
государственного управления за рубежом.
4.3
Совместимость с унаследованными системами
Унаследованные системы – это информационные системы, введенные в
промышленную эксплуатацию на уровне регионов или городов, если их замена
нецелесообразна. Такие информационные системы могут быть интегрированы в
информационную среду с помощью посреднического программного обеспечения
(адаптеры и шлюзы). Посредническое ПО должно удовлетворять требованиям
информационного обмена. При этом его внутренняя архитектура и способы
реализации интерфейсов с унаследованными системами могут быть произвольными.
Возможны следующие способы подключения унаследованных систем в
единую информационную среду:
Локальные
адаптеры.
Используются
в том
случае,
если
необходимо
организовать сопряжение конкретной унаследованной системы. Такие адаптеры,
обычно, реализуются в виде компонентов унаследованной системы. Заказчиком
разработки локальных адаптеров должны выступать владельцы соответствующих
систем.
Ведомственные шлюзы. В случае, если какое-либо ведомство располагает
большим парком информационных систем, использующих унифицированные, но
10
несовместимые способы взаимодействия друг с другом, включение их может быть
произведено через общий компонент (шлюз), преобразующий внутриведомственные
информационные потоки к виду, необходимому для использования в ЕГИСЗ.
4.4
Использование подсистемы интеграции прикладных систем
В целях обеспечения функциональной и технологической совместимости
прикладных подсистем ЕГИСЗ будет использоваться Подсистема интеграции
прикладных систем (далее – Сервис ИПС). Сервис ИПС будет представлять собой
общесистемный
технологический
сервис,
входящий
в
состав
сегмента
централизованных общесистемных компонентов ЕГИСЗ.
Сервис интеграции будет обеспечивать построение ЕГИСЗ на основе сервисориентированной архитектуры (англ. service-oriented architecture, SOA).
Функционально Сервис ИПС реализуется в виде сервисной шины (англ.
enterprise service bus, ESB), на которой будут публиковаться веб-сервисы подсистем
ЕГИСЗ, основанные на технологии SOAP, и которая будет предоставлять единую
точку доступа к опубликованным в Сервисе ИПС веб-сервисам.
Общесистемные и прикладные подсистемы федерального и регионального
сегментов ЕГИСЗ будут как потребителями, так и поставщиками веб-сервисов в
рамках Сервиса ИПС.
Система будет обеспечивать возможность информационного взаимодействия
общесистемных и прикладных подсистем федерального сегмента между собой,
взаимодействие с внешними информационными системами и информационными
системами Инфраструктуры электронного правительства и единую точку входа для
прикладных компонентов федерального и регионального сегмента ЕГИСЗ при
обращении к функциям прикладных компонентов федерального и регионального
сегмента ЕГИСЗ с использованием сервисно-ориентированной архитектуры (SOA) и
технологии веб-сервисов.
Для взаимодействия Системы в части обмена данными с внешними ИС будут
разработаны форматы обмена данными в виде xml-шаблонов. Обмен данными будет
происходить путем формирования xml-файла с необходимыми данными, передачи
11
его во внешнюю ИС (или наоборот из внешней ИС в Систему) с последующим
разбором файла и загрузкой данных в хранилище данных.
Для обмена информацией с другими системами будет использоваться
технология SOAP (от англ. Simple Object Access Protocol, простой протокол доступа
к объектам) — протокол, позволяющий передавать XML-форматированные
сообщения посредством HTTP(S).
Подсистемы
федерального
и
регионального
сегмента
ЕГИСЗ,
осуществляющие информационное взаимодействие через Сервис ИПС путем
взаимного обращения к веб-сервисам, будут зарегистрированы в Регистре
компонентов и подсистем ЕГИСЗ Сервиса ИПС. WSDL-описания веб-сервисов
данных подсистем также будут размещены в Регистре.
Информационные системы Инфраструктуры электронного будут возможность
обмена SOAP-запросами и ответами через Сервис ИПС при необходимости
организации взаимодействия с ними через Сервис ИПС.
Детальные описания протоколов информационного взаимодействия систем
через Сервис ИПС будут определены в технических проектах на соответствующие
системы.
Схема взаимодействия Сервиса ИПС с внешними системами представлена на
Рисунок 1.
12
Инфраструктура электронного правительства
Региональные прикладные
подсистемы ЕГИСЗ
ЕСИА
ЕПГУ
СМЭВ
WSDL
Федеральные прикладные подсистемы ЕГИСЗ
SOAP 1.2
запрос/
ответ
описание
сервиса
WSDL
описание
сервиса
WSDL
описание
сервиса
SOAP 1.2
запрос/
ответ
SOAP 1.2
запрос/
ответ
Мониторинг
состояния
веб-сервисов
Рег.
данные
(в т.ч. ключи)
Сервис ИПС
Рег.
данные
(в т.ч. ключи)
WSDL
описание
сервиса
SOAP 1.2
запрос/
ответ
WSDL
описание
сервиса
SOAP 1.2
запрос/
ответ
Региональные
Региональные прикладные
прикладные
подсистемы
подсистемы ЕГИСЗ
ЕГИСЗ
Мониторинг
состояния
веб-сервисов
ЕСИАиА,
ЕСИАиА, АХД,
АХД, ИЭМК,
ИЭМК, Регистр
Регистр МП
МП
МЗ
МЗ РФ,
РФ, ФЭР,
ФЭР, ИАС
ИАС УР
УР
Рисунок 1 - Схема взаимодействия Сервиса ИПС с прикладными подсистемами ЕГИСЗ (схема окружения
Системы)
13
5
ОПТИМИЗАЦИЯ ПРОЦЕССОВ С ИСПОЛЬЗОВАНИЕМ
ТЕХНОЛОГИИ РАБОЧИХ ПОТОКОВ
5.1
Рабочие потоки
Технология WorkFlow (рабочие потоки) – представляет собой полную
или частичную автоматизацию бизнес-процессов, при которой документы,
информация или задания передаются от одного участника (бизнес-единицы)
к другому для выполнения действий согласно набору руководящих правил.
Технология рабочих потоков устанавливает связь между документами
и
операциями
бизнес-процесса,
управляют
правилами
прохождения
документов, доставкой «тому, кому нужно, и тогда, когда нужно».
Технология
рабочих
потоков
позволяет
существенно
повысить
управляемость движением, изменением и хранением практически любых
типов информации в компонентах ЕГИСЗ, обеспечить прозрачность и
управляемость бизнес-процессами и вывести на качественно новый уровень
контроль их выполнения.
Оптимизация процессов с использованием технологии рабочих
потоков, позволит проектировать и поддерживать единую информационную
систему и бизнес-процессов с четкими ответами на вопросы: «кто делает?»,
«что делает?», «в какой последовательности?», «что получает на входе и
предоставляет на выходе?», и «кто за все это отвечает?».
Оптимизация процессов с использованием технологии рабочих потоков
может быть эффективно использована в текущей системе. Бизнес-процессы,
протекающие
в
ЕГИСЗ
позволяют,
своевременно
реагировать
(адаптироваться) на внешние (экономические, социальные, демографические
и другие) изменения в её географически-распределенных компонентах,
обеспечивать передачу информации между удаленными бизнес-единицами и
сохранит централизованный контроль над информационными потоками.
В
здравоохранении
в
настоящее
время
широко
применяются
технологии рабочих потоков при лечении пациентов, при передаче
14
информации между учреждениями (например, при передаче сведений по
оплате лечения). Но эти технологии недостаточно формализованы, при их
создании применялись различные подходы.
Сообщество IHE разработало серию описаний рабочих потоков,
решающих различные задачи интеграции разнородных систем. К таким
описаниям можно отнести Scheduled Workflow (SWF, Исполнение заказа,
поток действий при выполнении заказов), интеграционный профиль
Echocardiography
Workflow
(поток
действий
при
выполнении
эхокардиографических исследований, включая спецификацию интерфейсов
мобильного оборудования) и многие другие.
Интеграционный профиль SWF устанавливает правила передачи
информации при обращении пациента за консультациями, в частности
радиологическими или ультразвуковыми исследованиями. Он определяет
операции, которые обеспечивают согласованность передачи информации о
пациенте от этапа регистрации через заказ, планирования, выполнения
диагностических исследований, хранения и просмотра. Эта согласованность
также является основой для последующих этапов рабочего процесса, таких
как отчетность.
К
ключевым
преимуществам
такого
подхода
можно
отнести
уменьшение числа ошибок и улучшение качества оказания медицинской
помощи за счет минимизации операций ручного ввода, однократного ввода
информации, гарантированной доставки сведений о сигнальных отметках
пациента всем ответственным лицам, ввод результатов исследований и их
доставка непосредственно из точки оказания медицинской помощи.
При
следовании
утвержденной
стандартизованной
технологии
увеличивается пропускная способность диагностических центров за счет
сокращения операций ручного ввода, уменьшения потерь времени при
поиске результатов исследований за счет единой системы идентификации
исследований и стандартизованной системы хранения, уменьшение времени
поиска ошибок.
15
Сокращение трудозатрат при выполнении исследований позволяет
повысить
эффективность
использования
мощностей
диагностических
центров.
В спецификацию интеграционного профиля могут входить не только
потоки передачи данных, но и системы оповещений всех заинтересованных
лиц, правила передачи сообщений, описания документов и пр.
Пример
диаграммы
процесса
SWF
из
спецификации
IHE
(http://wiki.ihe.net/index.php?title=Scheduled_Workflow), приведен на Рисунок
2
Рисунок 2 - Процесс передачи данных SWF
Интеграционный профиль, описывающий обмен документами между
организациями
(The
Cross-Enterprise
Document
Workflow,
XDW)
обеспечивает участникам информационного взаимодействия управление и
отслеживание пациент-ориентированных задач, связанных с координацией
16
деятельности различных служб и систем в здравоохранении. Этот профиль
основывается на других технологиях предоставления документов, таких, как
XDS? Уделяя особое значение среде передачи клинических документов с
учетом специфики общения с пациентами. Он разработан с учетом
сложности и комплексности процесса оказания медицинской помощи и
позволяет весьма гибко адаптироваться под существующие процессы.
Пример диаграммы, описывающей архитектуру XDW из спецификации
IHE (http://wiki.ihe.net/index.php?title=Cross_Enterprise_Workflow), приведен
на Рисунок 3.
Рисунок 3 - Архитектура интеграционного профиля XDW
5.1.1 Анализ и обработка данных
5.1.1.1 Анализ данных
Анализ данных представляет собой работу с информацией в 3 этапа:

первый этап «первичный»;
Сбор информации об исследуемой системе ЕГИСЗ выполняется путем
имеющейся документации и поверхностного исследования самой системы.

второй этап «интервьюирование»;
17
Проведения интервьюирования с владельцами основных процессов (на
региональном уровне) с целью получения информации о том, как происходит
функционирование
изучаемых
компонентов
изнутри.
Так
же,
при
необходимости получения полной информации о деталях функционирования
компонентов, интервьюирование может быть выполнено непосредственно с
исполнителем процесса.

третий этап «заключительный».
Согласование
получившегося
«видения»
изученной
системы
Здравоохранения (региональной/федеральной). Согласования производится
после объединения собранной информации (1 этап + 2 этап), устранение
противоречий и формирование по результатам проделанной работы
«видения» и краткой аналитической записки.
5.1.1.2 Обработка данных
Обработка данных происходит на каждом из этапов анализа.
Под обработкой данных понимается соотношение собранных данных
(анализ данных) с предполагаемыми рабочими потоками данных.
Приступая к анализу рабочих потоков необходимо убедиться, что
каждый из исследуемых потоков отвечает в обязательном порядке
совокупности следующих критериев:

выделен;

структурирован;

выполняется по правилам, которые можно сформулировать;

периодически повторяется.
Первые три ограничения являются ответом на вопрос: «Какие
процессы можно описать?», а последний - «Какие целесообразно описать?».
18
5.1.2 Классификация и описание рабочих потоков
5.1.2.1 Классификация рабочих потоков
Классификация рабочих потоков выполняется после анализа и
обработки данных. Результат анализа исследуемой системы ЕГИСЗ
позволяет отнести выявленные потоки к одному из условных типов данных:

информационный;

материальный;

финансовый.
Классификация
рабочих
потоков
подразумевает
классификацию
данных по типу используемых объектов (см. выше), используемых в бизнеспроцессе. Объектом может быть любой ресурс, используемый в процессе.
5.1.2.2 Описание рабочих потоков
Описание рабочих потоков выполняется в соответствии с общей
детализацией информационных, материальных и финансовых потоков на
основе согласованного выполнения операций, работ и заданий, не
ограничивая при этом творческую и деловую активность исполнителей,
ответственных за конкретный участок работы.
Описание рабочих потоков позволит провести дальнейший анализ
отношений
/взаимодействий
и
формирование
предложений
по
их
оптимизации.
5.1.3 Анализ отношений/взаимодействий рабочих потоков
После классификации и описания компонентов ЕГИСЗ по технологии
рабочих потоков, в первую очередь, как правило, выявляются имеющиеся
дублирующие бизнес-процессы.
После
исследуемой
внедрения
системы
правил
ЕГИСЗ
упразднению (аннулированию).
прохождения
появляются
информации
процессы
внутри
подлежащие
19
Оставшиеся рабочие потоки подлежат анализу в части эффективности
текущей системы ЕГИСЗ «as is» (сравнение план-факт - контроль).
Эффективность системы оценивается с различных сторон:
 экономическая эффективность;
Экономическая эффективность оценивается, как внутри рабочих
потоков исследуемых компонентов, так и при внешнем взаимодействии
рабочих потоков (между собой, с внешней экономической средой).
Повышение экономической эффективности протекающих процессов
возможно за счет:

оптимизации бизнес-процессов (рассмотрение, обоснование,
тестирование, внедрение);

рационализации бизнес-процессов (выбор более оптимального
решения задачи);

повышения прибыли за счет минимизации издержек (оптимизация
использования имеющихся ресурсов);

повышения прибыли за счет разработки и внедрения новых услуг
(мониторинг потребностей - НИОКР);

технологическая эффективность;
Технологическая
эффективность
лежит
в
основе
определения
экономической эффективности.
Технологическая эффективность позволяет обеспечить максимально
возможный объем предоставления услуг при заданном количестве ресурсов.

организационная эффективность;
Организационная эффективность - степень достижения организацией
поставленных целей. Высокая организационная эффективность означает, что
организация преуспевает в достижении того, что она пытается достичь.
Факторы, влияющие на организационную эффективность:

организационные результаты и группы интересов (соблюдение
баланса между стоимостью необходимых ресурсов/услуг и
качеством предоставляемых услуг);
20

отношение к труду, установки на труд (приверженность
ответственных лиц Министерства Здравоохранения к моральноэтическим нормам общества, принятие трудовым коллективом
морально-этических норм);

мотивационные теории поведения людей в организации
(совокупность внутренних побуждений к активности, основанных
на осознаваемых или неосознаваемых потребностях, на интересе,
на представлениях о ценностях и др.);

динамические формы удовлетворенности трудом
(удовлетворенность выполняемой работой или получение
удовольствия от выполнения совей работы);

организация и содержание труда как фактор мотивации
(Разнообразие навыков, Законченность задания, Значимость
задания, предоставление информации работнику о результатах его
деятельности).

оперативная эффективность.
Оперативная эффективность – это результативность использования
задействованных ресурсов компонентов, для решения текущих задач.
Оперативная эффективность достигается реализацией технологии
рабочих потоков и, как следствие, автоматизацией бизнес-процессов типовых
рабочих
потоков
(информационного,
материального,
финансового)
бюджетирования и планирования, всех компонентов ЕГИСЗ, сократит
процесс подготовки бюджета, что позволит лицам, принимающим решения,
сосредоточиться на долгосрочном планировании.
Детерминизм оперативной эффективности, заключен в корреляции
взаимодействия различных направлений деятельности (согласованность и
дополнение друг друга), или, другими словами, как они взаимосвязаны.
Достижение отличной согласованности затруднительно, так как это
требует
координации
решений
и
действий
множества
независимых
21
подразделений. В решении данной задачи и поможет оптимизация бизнеспроцессов с использованием технологии рабочих потоков.
 стратегическая эффективность.
Эффект - достигаемый результат в его материальном, денежном,
социальном (социальный эффект) выражении.
Эффективность - относительный эффект, результативность процесса,
операции, проекта, определяемый как отношение эффекта, результата к
затратам, расходам, обусловившим его получение.
Таким
образом,
рабочие
потоки,
считаются
стратегически
эффективными при совокупном достижении положительных результатов
каждого в отдельности из вышеописанных критериев и в общей их
совокупности.
5.1.4 Описание и обоснование проблемных мест
Описание
взаимодействий
проблемных
«узких»
компонентов
мест
внутри/между
или
не
эффективных
рабочими
потоками
производится после того, как были выявлены не эффективные ключевые
проблемные точки взаимодействий.
Обоснование проблем производится на основе результатов контроля
(план-факт) и описания выявленных проблемных мест.
Предоставление рационализаторских решений - согласование с
«Ответственными лицами» Министерства Здравоохранения Российской
Федерации.
5.1.5 Формулирование рационализаторских решений
Рационализаторские решения представляют собой предложения, по
улучшению
(изменению
аннулированию)
топологии,
протекания
расширению,
бизнес-процессов.
сокращению
Лучшими
или
практиками,
считается разработка минимум двух сценариев оптимальных моделей, для
повышения эффективности выявленных проблемных мест.
22
Рационализаторские решения предоставляются по выявленным и
обоснованным не эффективным взаимодействиям внутри/между рабочими
потоками.
Предлагаемые
решения
формулируются
для
реинжиниринга
выявленных и обоснованных проблемных мест.
5.1.6 Согласование
Процесс согласования представляет собой обоснование качественных
критериев,
«защиту»
предлагаемых
и
рекомендуемых
сценариев
и
рационализаторских решений.
«Ответственные лица» Министерства Здравоохранения Российской
Федерации при необходимости вносят корректировки или отправляют на
доработку предложенные решения с обоснованием несоответствий или
противоречий с целями системы ЕГИСЗ.
5.2
Оптимизация бизнес-процессов с использованием
технологии рабочих потоков
5.2.1 Текущая ситуация
Внедрение технологии рабочих потоков позволяет организовать
конвейер обработки информационных, финансовых и материальных потоков
на основе согласованного выполнения операций, работ и заданий, не
ограничивая при этом творческую и деловую активность исполнителей,
ответственных за конкретный участок работ.
Система ЕГИСЗ с внедренной технологией рабочих потоков, будет
более гибкой, быстро адаптирующейся к новым обстоятельствам, что
позиционирует ее как более эффективную систему управления ресурсами
(информационными, материальными, финансовыми).
Технология
рабочих
потоков
позволяет
получить
достоверную
информацию о деятельности всей системы ЕГИСЗ, анализ которой служит
основанием для принятия управленческих решений и своевременной
23
корректировки
направлений
деятельности
(усиление
или
снижения
активности в проблемном направлении), а при необходимости оперативных
планов и стратегии развития.
Разработка
выполняется
оптимальной
путем
структуры
внедрения
системы
согласованных
ЕГИСЗ
«to
be»
предложений
по
рационализации в существующую систему ЕГИСЗ. При внедрении больше
чем 50% рационализаторских предложений в какой либо из компонент
ЕГИСЗ – изменяемый
компонент подлежит полной
переработке с
последующим согласованием.
5.2.2 Дополнительные возможности
Формирование
краткосрочных
и
плана
оптимального/негативного
среднесрочных
стратегий
возможно
достижения
при
наличии
следующих исходных данных:

наличие цели развития на 3/5 лет;

наличие задач целей;

наличие краткосрочных/среднесрочных стратегий развития;

наличие прогнозов на 6 месяцев;

сформированные критерии успеха (что считается успехом);

сформированные критерии негативных результатов (что считается
негативным результатом);

реестр рисков (по убыванию) и методы их обработки;

имеющиеся статистические данные (перечень уточняется у
«Ответственных лиц» Министерства Здравоохранения РФ).
При наличии совокупности вышеописанных данных, исполнитель
будет в состоянии, используя экстраполяцию (с применением индукции и
дедукции)
с
вероятностью
70%
достоверности,
представить
оптимальный/пессимистический архитектурный ландшафт системы ЕГИСЗ.
Использование
развития
проектов
архитектурного
оптимальной/пессимистической
ландшафта
компонентов
ЕГИСЗ,
модели
позволит
24
составить более точную стратегию (среднесрочную/долгосрочную (35/свыше 10 лет)).
Формирование проектов осуществляется в следующем порядке:

формирование проекта оптимальной модели:

поэтапное описание расширения (масштабируемое увеличение
типов рабочих потоков, распределение нагрузки между
участниками бизнес-процессов и т.п.);

описание и обоснование перспективы развития компонентов
ЕГИСЗ;

описание поддерживающих и обеспечивающих компонентов
ЕГИСЗ с их масштабируемым расширением;

распределение оптимальной нагрузки для достижения
оптимальной стратегической цели;

описание «контрольных точек», необходимых для
отслеживания направления действий направленных на
достижение оптимальной стратегической цели.

формирование проекта пессимистической модели:

поэтапное описание сокращения (масштабируемое уменьшение
типов рабочих потоков, распределение нагрузки между
участниками бизнес-процессов и т.п.);

описание и обоснование необходимости сокращения
имеющихся ресурсов (информационных, материальных)
компонентов ЕГИСЗ;

описание поддерживающих и обеспечивающих систем
компонентов ЕГИСЗ с их масштабируемым сокращением;

распределение оптимальной нагрузки для достижения
оптимальной стратегической цели;

описание «контрольных точек», необходимых для
отслеживания направления действий направленных на
достижение оптимальной стратегической цели.
25
5.3
Заключение
Использование
организовать
формализованных
конвейер
обработки
рабочих
потоков
информационных,
позволит
финансовых
и
материальных потоков на основе согласованного выполнения операций,
работ и заданий. Для описания рабочих потоков необходимо провести выбор
технологии проектирования потоков, который описан в Разделе 6.
При проектировании рабочих потоков следует использовать опыт,
накопленный при формализации потоков работ на международном уровне,
использовать интеграционные профили сообщества IHE.
26
6
МЕТОДОЛОГИЯ ОПИСАНИЯ ФУНКЦИОНАЛЬНОГО И
АРХИТЕКТУРНОГО ЛАНДШАФТА КОМПОНЕНТ ЕГИСЗ
Ландшафт компонент ЕГИСЗ представляет собой совокупность
функционально-взаимосвязанных
компонентов,
объединенных
связью
бизнес-процессов, потоками работ и данных (информационными потоками),
а также базой НСИ, которая сама по себе является одним из компонентов
ЕГИСЗ. Границы ландшафта заданы изначально концепцией ЕГИСЗ и далее
определяются по мере развития системы.
Функциональный ландшафт компонент ЕГИСЗ представляет собой
административно определяемую группировку информационных потоков
между и внутри компонент ЕГИСЗ, и в описании представляется
систематизированной картой взаимосвязей.
В
свою
представляет
очередь
собой
архитектурный
высокоуровневый,
ландшафт
системы
ЕГИСЗ
программно-аппаратный
набор
взаимосвязанных компонентов (таких как ИЭМК, ИАС УР, АХД, ФЭР, ЕРЗ и
пр.).
Выбор
наиболее
подходящей
методологии
(нотации)
описания
функционального ландшафта компонент ЕГИСЗ позволит установить единый
подход к описанию набора функций и информационных потоков для каждого
компонента ЕГИСЗ и обеспечить возможность эффективной реализации
концепции каждого из компонентов ЕГИСЗ. Описание функционального
ландшафта компонент ЕГИСЗ в эффективной нотации позволит решить
наиболее важные вопросы реализации назначения компонента на этапе
проектирования,
и
на
этапе
разработки
проекта
интеграции
и/или
взаимодействия между компонентами.
6.1
Критерии выбора эффективной методики описания
Методология описания (нотации) ландшафта является совокупностью
способов, при помощи которых объекты и связи между ними представляются
27
в виде модели. Любая методика включает в себя три основные
составляющие:

теоретическая база;

описание шагов, необходимых для получения результата;

рекомендации по использованию.
Основное в методологии это предоставить план, последовательность
шагов, которые приведут к заданному результату. Способность получать
результат с заданными параметрами характеризует ее эффективность.
Важнейшими понятиями любой методики описания процессов являются
понятия
объекта
и
связи.
Связи
предназначены
для
описания
взаимоотношений объектов друг с другом. К таким взаимоотношениям в
частности относятся: последовательности выполнения во времени, связь при
помощи потока информации, использование данных другим объектом и пр.
Для каждого объекта и связи характерны ряд параметров (атрибутов),
отражающих их определенные характеристики. Состав таких атрибутов
зависит от типа объектов или связи. На практике описание функционального
и архитектурного ландшафта осуществляется при помощи специальных
инструментальных средств моделирования бизнес-процессов. Для задачи
описания функционального и архитектурного ландшафта компонент ЕГИСЗ
требуется методология, которая:

имела бы развитый набор инструментов описания и
моделирования;

предоставляла бы широкие возможности описания бизнеспроцессов на верхнем уровне с акцентом на управление
процессами;

позволяла бы отражать в нотации обратные связи различного типа
– по информации, управлению, движению и/или распределению
(резервированию) ресурсов;

развитые механизмы декомпозиции модели процесса.
28
Это и будет являться критериями при выборе наиболее эффективной
методологии описания функционального и архитектурного ландшафта
компонент ЕГИСЗ.
Обзор методологий описания функционального и
6.2
архитектурного ландшафта компонент ЕГИСЗ
В основе методов моделирования бизнес-процессов могут лежать как
структурный, так и объектно-ориентированный подходы к моделированию. В
настоящее время для описания, моделирования и анализа бизнес-процессов и
организационных схем используются несколько типов методологий, к числу
наиболее распространенных относятся методология моделирования бизнеспроцессов (Business Process Modeling), методология описания потоков работ
(Work Flow Modeling), методология описания потоков данных (Data Flow
Modeling) и ряд других.
Рассмотрим
более
подробно
следующие,
приведенные
методы
(нотации) описания бизнес-процессов:

метод функционального моделирования SADT (Structured Analysis
and Design Technigue);

методологии семейства IDEF;

моделирование потоков данных DFD;

метод ARIS;

метод моделирования, используемый в технологии UML;

нотация моделирования потоков работ BPMN.
SADT
Методология структурного анализа и проектирования (Structured
Analysis and Design Technique, SADT) была создана в конце 60-х гг. XX в.
Дугласом Россом. SADT нашла своё применение в области описания
большого количества сложных искусственных систем из широкого спектра
областей. В 1973 г. впервые при помощи SADT был реализован крупный
29
аэрокосмический проект. В виде конечного продукта SADT появилась в 1975
г. К 1981 г. методология SADT использовалась более чем в 50 компаниях при
работе над проектами, охватывавшими различные проблемные области, в
том числе телефонные сети, аэрокосмическое производство, управление и
контроль, учёт материально-технических ресурсов. Причина успешного и
разнообразного её применения заключается в том, что SADT является полной
методологией для создания описания систем, основанной на концепциях
системного моделирования.
Метод SADT поддерживается Министерством обороны США, которое
было
инициатором
разработки
семейства
стандартов
IDEF
(ICAM
DEFinition), являющегося основной частью программы ICAM (Integrated
Computer
Aided
Manufacturing
—
интегрированная
компьютеризация
производства), проводимой по инициативе военно-воздушных сил США.
Метод SADT реализован в одном из стандартов этого семейства — IDEF0,
который был утверждён в качестве федерального стандарта США в 1993 г.
IDEF1
Методологии семейства IDEF позволяют отображать и анализировать
модели деятельности широкого спектра сложных систем в различных
разрезах.
В настоящий момент в семейство IDEF входят:

IDEF0 — методология функционального моделирования
(изучаемая система представляется в виде набора
взаимосвязанных функций— функциональных блоков);

IDEF1 — методология моделирования информационных потоков
внутри системы, позволяющая отображать и анализировать их
структуру и взаимосвязи;

IDEF1X (IDEF1 eXtended)— методология построения
реляционных структур (как правило, используется для
30
моделирования реляционных баз данных, имеющих отношение к
рассматриваемой системе);

IDEF2 — методология динамического моделирования развития
систем;

IDEF3 — методология документирования процессов,
происходящих всистеме;

IDEF4 — методология построения объектно-ориентированных
систем, позволяющая наглядно отображать структуру объектов и
принципы их взаимодействия;

IDEF5 — методология онтологического исследования сложных
систем при помощи определённого словаря терминов и правил, на
основании которых могут быть сформированы достоверные
утверждения о состоянии рассматриваемой системы в некоторый
момент времени;

IDEF6 — методология использования рационального опыта
проектирования, позволяющая предотвратить возникновение
структурных ошибок при новом проектировании информационных
систем;

IDEF7 — методология аудита информационной системы;

IDEF8— методология разработки модели графического
интерфейса пользователя;

IDEF9 — методология анализа существующих условий и
ограничений, их влияния на принимаемые решения в процессе
реинжиниринга;

IDEF10 — методология моделирования архитектуры выполнения;

IDEF11 — методология информационного моделирования
артефактов;

IDEF12 — методология организационного моделирования;

IDEF13 — методология проектирования трёхсхемного дизайна
карт;
31

IDEF14 — методология моделирования компьютерных сетей.
IDEF0
Как сказано выше, стандарт IDEF0 был разработан в 1981 г.
департаментом ВВС США в рамках программы ICAM. Методология IDEF0
представляет собой развитие графического языка описания функциональных
систем SADT. Метод должен был обеспечить групповую работу над
созданием модели, с непосредственным участием всех аналитиков и
специалистов, занятых в рамках проекта.
IDEF0 реализует методику функционального моделирования сложных
систем.
Применять
IDEF0
рекомендуется
для
начальных
стадий
проектирования сложных искусственных систем управления, производства,
бизнеса, включающих людей, оборудование, программное обеспечение.
IDEF1 и IDEF1X
IDEF1
и
IDEF1X
реализуют
методики
инфологического
проектирования баз данных.
Стандарт IDEF1 был разработан как инструмент для анализа и
изучения взаимосвязей между информационными потоками анализируемой
системы.
Целью подобного исследования является структуризация и дополнение
существующей
информации,
обеспечение
качественного
управления
информационными потоками.
Применение методологии IDEF1 позволяет решить следующие задачи:

выяснить структуру и содержание существующих потоков
информации в системе;

выявить проблемы, вызванные недостатком управления
соответствующими потоками информации;

выявить информационные потоки, требующие дополнительного
управления для эффективной реализации модели.
32
IDEF1
является
аналитическим
методом
и
используется
преимущественно для выполнения следующих действий:

определение информации, имеющей отношение к деятельности
системы, а также структуры её потоков;

определение существующих правил и законов, по которым
осуществляется движение информационных потоков, а также
принципов управления ими;

выяснение взаимосвязей между существующими
информационными потоками в рамках системы;

выявление проблем, возникающих при некачественном
информационном управлении. IDEF1X является методом для
разработки реляционных баз данных. Использование метода
IDEF1X наиболее целесообразно для построения логической
структуры базы данных после исследования другими методами
информационных ресурсов системы и принятия решения о
внедрении реляционной базы данных, как части корпоративной
информационной системы. Основным преимуществом IDEF1X, по
сравнению с другими методами разработки реляционных баз
данных, является жёсткая и строгая стандартизация
моделирования, которая позволяет избежать различной трактовки
построенной модели.
IDEF2 и IDEF3
Методологии IDEF2 и IDEF3 реализуют поведенческое моделирование
системы. Если методика IDEF0 связана с функциональными аспектами и
позволяет отвечать на вопрос: «Что делает эта система?», то в этих
методиках детализируется ответ на вопрос: «Как система это делает?». В
основе
поведенческого
моделирования
лежат
модели
и
методы
имитационного моделирования систем массового обслуживания, сети Петри,
33
возможно применение модели конечного автомата, описывающей поведение
системы как последовательности смен состояний.
Основой методологии служит сценарий процесса, выделяющий из
модели последовательность происходящих в системе действий. Диаграммы
IDEF3
позволяют
моделировать
сценарии
происходящих
в
системе
процессов, исследовать связи между действиями процессов, описывать
последовательно.
IDEF4
Методология IDEF4 реализует объектно-ориентированный анализ
больших систем. Методология предоставляет пользователю графический
язык для изображения классов, диаграмм наследования, таксономии методов.
IDEF5
Методология IDEF5 обеспечивает наглядное представление данных,
полученных в результате обработки онтологических запросов в простой
естественной графической форме.
Как схематический язык, IDEF5 ближе всего к IDEF1 и IDEF1X.
Информация, отражающаяся в модели IDEF1 или IDEF1X, может быть
выражена в IDEF5. Но для проектирования реляционных баз данных IDEF5
не
подходит,
так
как
не
содержит
хорошо
продуманных,
специализированных представлений IDEF1/1X.2.3. IDEF
IDEF6
Методология IDEF6 направлена на сохранение рационального опыта
проектирования информационных систем, что способствует предотвращению
структурных ошибок.
IDEF6
используется
для
описания
и
обоснования
дизайна
разрабатываемой информационной системы, а также для отображения связи
проектных решений по разработке моделей и системы документации.
Преимуществом данной методологии является то, что она помогает
34
организации избежать повторения ошибок проектирования, определяя
влияние вносимых в дизайн системы изменений.
В отличие от других методик IDEF, в которых фиксируются результаты
проектирования, в IDEF6 главный упор сделан на пути получения этих
результатов и обосновании промежуточных решений. Такой подход
особенно
важен
при
разработке
сложных
систем
в
недостаточно
определённых ситуациях. Фиксация шагов и обоснований помогает при
дальнейших
модернизациях
рационального
опыта
обнаружение
и
систем,
сохранению
проектирования.
устранение
и
использованию
Методика
упорядочивает
неопределённостей,
ошибок,
неудовлетворительных ограничений.
IDEF8
Методология
взаимодействия
IDEF8
человека
и
предназначена
пользовательской
для
проектирования
системы.
Создаваемые
сценарии должны удовлетворять ряду оговорённых в методике принципов,
таких как уменьшение нагрузки на человека, идентичность средств диалога в
разных системах, наличие обратной связи для исправления ошибок, хранение
истории диалога, помощь советами по выполнению действий и т.д.
IDEF9
Методология IDEF9 предназначена для анализа имеющихся условий и
ограничений (в том числе физических, юридических, политических) и их
влияния на принимаемые решения в процессе реинжиниринга. Данная
методика призвана помочь в обнаружении и анализе проблем, возникающих
в бизнес-системах. Выявление ограничений в бизнес-системе и их
систематический анализ позволяют улучшить функционирование системы.
Обычно в качестве систем фигурируют сложные информационные
системы с ориентацией на экономические и управленческие приложения.
Под ограничением понимается отношение, которое должно соблюдаться.
Ограничения делятся на контексты (группы родственных ограничений).
35
Применение IDEF9 заключается в выполнении нескольких шагов:

сбор свидетельств (фактов, указывающих на наличие
ограничения);

классификация — определение контекстов, объектов, отношений;

прогнозирование — выявление ограничений на основе
свидетельств;

отбор значимых ограничений;

определение экспертов для тестирования результатов;

детализация и фильтрация ограничений.
В методике даны рекомендации по выполнению этих шагов.
Предлагается графический язык, элементами которого являются система,
блоки ограничений, контексты, линии связи, логические связки OR, AND,
XOR (исключающее ИЛИ).
IDEF14
Методология IDEF14 предназначена для представления и анализа
данных при проектировании вычислительных сетей на графическом языке с
описанием конфигураций, очередей, сетевых компонентов, требований к
надёжности и т.п.
DFD
Диаграммы
потоков
данных
(Data
Flow
Diagramming,
DFD)
представляют собой иерархию процессов, которые связаны между собой
потоками данных. Диаграммы показывают, как обрабатывает информацию
каждый процесс, как процессы связаны друг с другом, а также как работает
сама система, каким образом она обрабатывает поступающие данные.
Чаще
всего
методика
применяется
для
модернизации
уже
существующих сетей. Проектирование включает в себя определение
топологии сети или схемы коммуникаций, реализацию нужного качества
обслуживания,
анализ
функционирования
(трафик,
дисциплины
36
обслуживания в узлах, протоколы доступа). Модель топологии дополняется
моделями очередей, надёжности, материальных затрат. Важную роль играет
библиотека методов построения и компонентов сетей. Методика основана на
выполнении ряда шагов: установление целей модернизации, исследование
существующей сети, определение типов компонентов в ней, построение
модели «как есть», её верификация, анализ результатов, корректировка с
переходом к модели «как должно быть».
Aris
В настоящее время наблюдается тенденция интеграции разнообразных
методов моделирования, проявляющаяся в форме создания интегрированных
средств моделирования. Одним из таких средств является программный
продукт, носящий название ARIS (Architecture of Integrated Information
Systems), разработанный германской фирмой IDS Scheer.
ARIS поддерживает четыре типа моделей (и множество видов моделей
в каждом типе), отражающих различные аспекты исследуемой системы.
Основная бизнес-модель ARIS - eEPC (extended Event-driven Process
Chain, расширенная модель цепочки процессов, управляемых событиями).
Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в
нотации eEPC представляет собой поток последовательно выполняемых
работ (процедур, функций), расположенных в порядке их выполнения.
Реальная длительность выполнения процедур в eEPC визуально не
отражается. Для получения информации о реальной длительности процессов
необходимо использовать другие инструменты описания, например, MS
Project.
Модели в ARIS представляют собой диаграммы, элементами которых
являются разнообразные объекты – «функции», «события», «структурные
подразделения», «документы» и т.д. Между объектами определённых видов
могут
быть
установлены
связи
определённых
видов
(«выполняет»,
«принимает решение», «должен быть проинформирован о результатах» и
37
т.д.). Каждому объекту соответствует определенный набор атрибутов,
которые позволяют ввести дополнительную информацию о конкретном
объекте.
UML
Унифицированный язык моделирования (Unified Modeling Language,
UML) представляет собой общецелевой язык визуального моделирования,
который разработан для спецификации, визуализации, проектирования и
документирования
компонентов
программного
обеспечения,
бизнес-
процессов и других систем.
UML содержит в себе механизмы расширения, предназначенные для
адаптации определённого языка моделирования к конкретным требованиям
разработчика
без
необходимости
изменения
метамодели.
Наличие
механизмов расширения принципиально отличает UML от таких средств
моделирования, как IDEF0, IDEF1X, IDEF3, DFD, которые сильно
типизированы, т.к. не допускают произвольной интерпретации семантики
элементов моделей. UML, допуская такую интерпретацию, является слабо
типизированным языком.
BPMN
Целью проекта Business Process Modeling Notation (BPMN) является
создание общей нотации разработки моделей бизнес-процессов для
различных
категорий
специалистов:
от
аналитиков
и
экспертов,
моделирующих бизнес-процессы, технических разработчиков, которые
создают системы для выполнения этих процессов, до менеджеров различных
уровней, которые должны понимать процессные диаграммы, чтобы
принимать деловые решения.
Спецификация BPMN разработана организацией Business Process
Management Initiative (BPMI) в 2001-2004 годах с учётом множества ранее
существовавших диаграмм (в т.ч. всех, рассмотренных выше).
38
Благодаря абстрактному представлению модели нотация BPMN
позволяет
наглядным
образом
описывать
модели
бизнес-процессов
независимо от среды их функционирования. Для реализации нотации модели
используются языки исполнения бизнес-процессов — BPML (Business
Process Modeling Language) и BPEL (Business Process Execution Language).
Язык определения бизнес-процессов BPML, основанный на технологии Webсервисов.
6.3
Выбор обоснованной методологии функционального и
архитектурного ландшафта компонентов ЕГИСЗ
Подробно рассмотрев популярные нотации описания бизнес-процессов
для
реализации
информационной
«Концепции
системы
в
создания
сфере
единой
государственной
здравоохранения
(ЕГИСЗ)»
и
оптимизации процессов с использованием технологии рабочих потоков (см.
раздел 5) констатируем, что наиболее подходящей нотацией является
Business Process Modeling Notation (BPMN).
Business Process Modeling Notation (BPMN), представляет собой
графическую нотацию для отображения бизнес-процессов при описании
рабочих потоков, происходящих в системе ЕГИСЗ. Данная методология
активно
развивается,
поддерживающего
ее
развитие
связано
инструментария
с
совершенствованием
(программных
продуктов
для
моделирования бизнес-процессов, например BPWin, ProCap, IDEF0/EM Tool
и др.). Методология предоставляет широкие возможности для описания
управления процессами, происходящими в ЕГИСЗ и позволит при
использовании
обеспечить
достижение
целей,
стоящих
перед
разработчиками системы ЕГИСЗ и реализовать ее в полном объеме в
непротиворечивой и эффективной модели.
Результатом использования методологии описания функционального
архитектурного ландшафта компонентов ЕГИСЗ станет высокоуровневая
структурная схема с отображением взаимодействия между компонентами
39
ЕГИСЗ и детальные приложения со схемами отдельных участков данной
общей схемы (степень детализации определяется по необходимости на этапе
проектирования).
1/--страниц
Пожаловаться на содержимое документа