Проектирование информационной системы «Выполнения работы оператора»

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока - приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии - в таком случае, они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

 

 

Рис. 2. Декомпозиция функциональных блоков

 

Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:

• ограничение количества функциональных блоков на диаграмме тремя-шестью. Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание;
• ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.

Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.

Модели AS-IS и ТО-ВЕ

Обычно сначала строится модель существующей организации работы - AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, «кто что сделал» и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т.д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных / лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

Следует указать на распространенную ошибку при создании модели AS-IS - это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD_BE (как должно бы быть).

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т.е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т.е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состояния системы, поскольку такой переход - это тоже бизнес-процесс.

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

 

 

2. Описание предметной области

2.1 Краткая характеристика выполнения работы оператора ПК

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

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

Учет случаев заболеваний, с которыми население обратилось за медицинской помощью, осуществляется всеми медицинскими учреждениями. Непременным условием правильности статистического учета заболеваемости являются единые правила регистрации заболевания и кодирование болезни согласно единой классификации и номенклатуры болезней. В Российской Федерации для этой цели утверждена к использованию Международная классификация болезней и проблем, связанных со здоровьем, 10-го пересмотра (МКБ-10).

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

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

Талон предназначен для регистрации законченного случая оказания медицинской помощи и примененном медико-экономическом стандарте. В талоне будут регистрироваться данные о:

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

 

"Талон амбулаторного пациента" и его автоматизированная обработка позволяют осуществлять:

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

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

2.2 Набор диаграмм и описания к ним

 

Процесс моделирования системы начинается с создания контекстной диаграммы - диаграммы наиболее абстрактного уровня описания системы в целом контекстную диаграмму, описывающую деятельность оператора ПК (рисунок 1).

 

 

Рисунок 1 - Контекстная диаграмма «Выполнения работы оператора ПК»

 

Операции, выполняемые оператором, представлены в таблице 1.

Таблица 1 - деятельность оператора ПК

Функциональный блок	Описание
Введение информации	Оператор ПК ответственный за работу с программой АИС «Поликлиника», заводит информацию из талона амбулаторного пациента в базу данных программы. После ввода информации она хранится в оперативной базе данных программы. Для составление отчетов и дальнейшей работы с информацией необходимо программным методом перенести информацию из оперативной базы в архив программы.
Проверка на ошибки	Что бы исключить ошибочные данные в статистических отчетах и счетах, необходимо проверить информацию в базе данных на ошибки. Оператор ПК формируют реестр и отправляет его в территориальных фонд обязательно медицинского страхования для сверки. В фонде данные реестра сравнивают с данными находящимися в их базе данных, после чего формируется ведомость ошибок. Ведомость ошибок возвращается оператору. Оператор исправляет ошибки в базе данных программы.
Формирование счетов, статистической отчетности	После исправление всех ошибок оператор формирует из реестра счета для оплаты страховым медицинским организациям, а также статистическую отчетность посещения поликлиники.
Печать счетов стат. отчетности	Сформированные счета, статистическую отчетность необходимо распечатать.

 

Результат описания модели получим с помощью отчета (таблица 3).

Таблица 2 - Описание модели с помощью отчета BPwin.

Наименование	Значение
Model Name	выполнение работы оператора ПК
Definition	модель, описывающая выполнения работы оператора ПК
Purpose	моделирования деятельности оператора ПК, анализ и  формулирование рекомендаций    по повышению эффективности организации труда.деятельность оператора сервиса

 

 

На основании таблицы 1 производится  функциональную декомпозицию, чтобы рассмотреть деятельность оператора со всех сторон (рисунок 2).

Рисунок 2 - Диаграмма декомпозиции «Выполнения работы оператора ПК»

 

 

Рисунок 3 - Диаграмма декомпозиции «Введение информации»

 

Рисунок 4 - Диаграмма декомпозиции «Проверка на ошибки информации»

Рисунок 5 - Диаграмма декомпозиции «Формирование счетов, стат.отчетности»

Основные элементы диаграммы описаны в таблице 2.

 

 

2.3 Анализ полученных результатов

 

Анализируем полученные данные обращая внимания на типичные ошибки.

Бесполезные работы (функции не имеют выходов или их результаты нигде не используются) - такие работы отсутствуют.

Неправильно описанные функции, либо имеющие какой-то не отражённый в модели смысл - таких функции нет.

Работы не имеют входов (создают выходы из пустоты) - все работы на диаграммах имеют входы.

Неуправляемые работы (не определены правила / ограничения их выполнения) - вся работа определена должностным инструкциями и правилами техники безопасности.

Функции находятся в модели на одном и том же уровне, а на самом деле относятся к разными уровням - все функции находятся на разных уровнях .

Дублирующиеся работы (выполняются по несколько раз разными сотрудниками или на разных уровнях управления)- таких работ нет.

Функции выполняются работниками, не имеющим к ним отношения или с несоответствующей компетенцией - все работа выполняемая оператором соответствуют его компетенции.

Неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время) - каждый документ оказывается в нужное время в нужном месте.

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