Автоматизированная информационная система учета пациентов на примере ОАО "Авитек"

 

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ВЯТСКИЙ СОЦИАЛЬНО-ЭКОНОМИЧЕСКИЙ ИНСТИТУТ

Факультет информационных технологий

Кафедра информатики и вычислительной техники

Курсовая работа по дисциплине

Проектирование информационных систем

Тема: Автоматизированная информационная система учета пациентов на примере ОАО «Авитек»

Киров 2011

Содержание

Введение

. Обоснование выбора инструментальных средств

. Анализ требований к системе

. Функциональная декомпозиция системы

.1 Построение модели AS-IS

. Построение ролевой диаграммы

. Функционально-стоимостной анализ процессов (ABC)

Заключение

Библиографический список

Приложения

Введение

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

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

Санаторий «Авитек» - это натуропатическая клиника, где долечивают (реабилитируют) пациентов после тяжелых заболеваний сердца и сосудов, занимаются профилактикой обострений хронических заболеваний, укрепляют здоровье и продляют молодость. Это многопрофильный лечебно-оздоровительный комплекс на 165 мест [7].

На текущий момент учет пациентов (создание амбулаторной карты и ее заполнение по мере лечения пациента) ведется вручную, финансовые расчеты стоимости лечения выполняются в системе 1С. Кроме того, на базе санатория имеется специализированное оборудование для снятия различных медицинских параметров пациента (артериальное давление, пульс, частота дыхания при физических нагрузках и т.п.). Очевидно, предприятию требуется автоматизированная информационная система, обеспечивающая с одной стороны, хранение и автоматическое обновление амбулаторной карты пациента в электронном виде и с другой стороны, взаимодействующая с другими системами, применяемыми в ОАО «Авитек».

Цель работы: разработать проект автоматизированной информационной системы, обеспечивающей учет пациентов в ОАО «Авитек».

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

. Ознакомиться с методологией построения моделей в нотациях IDEF0, IDEF3 и DFD.

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

. С помощью выбранного инструмента провести моделирование деятельности по учету пациентов на ОАО «Авитек».

1. Обоснование выбора инструментальных средств

автоматизированный информационный бизнес учет

Российский рынок программного обеспечения предлагает довольно широкий спектр инструментов визуального моделирования бизнес-процессов: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer. За рубежом, помимо упомянутых, активно используются такие средства как Ithink Analyst, ReThink и др.

Краткая характеристика перечисленных инструментальных средств представлены в таблице 1.

Таблица 1 Перечень инструментальных средств

№НаименованиеПоставщик, официальный сайт. Основной представитель в РоссииКраткая характеристика12341BPWin и ERWinComputer Associates (ранее компания Platinum) <#"justify">Один из участников мирового рынка

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

§устойчивое положение продукта на рынке (срок его существования, программа развития продукта, система отчетов о проблемах, совокупность применений и др.);

§распространенность продукта (количество проданных лицензий, наличие, размер и уровень деятельности пользовательской группы);

§доступность поддержки поставщика. Такие услуги могут включать телефонную "горячую линию", техническую и консультационную поддержку через представителя поставщика в России;

§доступность обучения. Обучение может проводиться на территории представителя поставщика в России, пользователя или где-либо в другом месте;

§доступность материалов по продукту. Они могут включать компьютерные учебные материалы, учебные пособия, книги, статьи, информацию в Интернете, демоверсии.

Из приведенного в списка инструментальных средств более подробно рассмотрим BPWin и ERWin компании Соmputer Associates.Associates International, Inc. (CA) входит в пятерку ведущих производителей программного обеспечения, предлагая средства моделирования, резервного копирования, управления инфраструктурой предприятия (сетями, серверами и т.д.), информационной безопасности, business intelligence и т.д. Пакет BPWin основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Методология IDEF, являющаяся официальным федеральным стандартом США, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Возможности BPwin:

§поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область наиболее комплексно;

§позволяет оптимизировать процедуры в компании;

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

§позволяет облегчить сертификацию на соответствие стандартам качества ISO9000;

§интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.;

§интегрирован со средством имитационного моделирования Arena;

§содержит собственный генератор отчетов;

§позволяет эффективно манипулировать моделями - сливать и расщеплять их;

§имеет широкий набор средств документирования моделей, проектов [5].

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

2. Анализ требований к системе

Постановка задачи

1. Разработка должна осуществляться в соответствии с основными стадиями жизненного цикла продукта с применением структурного подхода.

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

-создание новой амбулаторной карты пациента;

-учет процедур, полученных пациентом в период лечения;

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

-взаимодействие с системой расчета стоимости лечения (1С);

-печать различных отчетов.

Кроме того, проектируемая система должна предоставлять возможности простейшего статистического анализа.

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

Различным организационным уровням соответствуют четыре типа ИС:

§оперативному уровню управления - системы с эксплуатационного уровня, системы уровня знаний;

§тактическому уровню управления - ИС тактического управления;

§стратегическому уровню управления - ИС стратегического управления.

ИС эксплуатационного уровня предназначены для автоматизации элементарных функций ОИ оперативного уровня управления компанией. Такими функциями являются: ввод информации, первичная обработка текущей информации, проведение платежей, осуществление «почтовых операций». ИС эксплуатационного уровня применяются для ведения складского учета, кадрового учета, организации документооборота, ввода первичной бухгалтерской информации, оперативное планирование и т.д. Основная цель систем на этом уровне состоит в том, чтобы автоматизировать рутинные операции по воду информации и проводить потоки транзакций через организацию [4].

На эксплуатационном уровне задачи, данные и действия предопределены и высоко формализованы.

Таким образом, приведенные ранее требования к АИС для ОАО «Авитек» позволяют отнести ее к системам эксплуатационного уровня.

3. Функциональная декомпозиция системы

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

Декомпозиция позволяет представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой [6].

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ, другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком Уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области") [2].

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

Анализ системы будем осуществлять в терминах бизнес-процессов организации с использованием методологий IDEF0, DFD, IDEF3.

Первый шаг в построении модели - это определение цели модели, т.е. ряда вопросов, на которые призвана ответить модель.

Из требований к модели, приведенных в п.2, следуют такие общие вопросы:

§из каких процессов состоит деятельность регистратуры санатория;

§какие данные используются при учете пациентов;

§каковы общие алгоритмы обработки этих данных.

Второй шаг - определение масштаба модели, то есть степени детальности или уровней декомпозиции диаграмм. Решение о том, следует ли дальше декомпозировать диаграмму, будем принимать исходя из того, насколько полно данная диаграмма отражает интересующий нас процесс.

Третий шаг - определение точки зрения на модель. Ее можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования.

Так как с проектируемой АИС будет работать регистратор, то целесообразно проводить рассмотрение с его точки зрения.

Обычно строится модель существующей организации работы - AS-IS (как есть). Анализ функциональной модели позволяет определить:

-наиболее слабые места;

-преимущества новых бизнес-процессов;

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

Найденные в модели недостатки можно исправить при создании модели TO-BE (как будет) - модели новой организации бизнес-процессов.

Технология проектирования ИС подразумевает сначала создание модели AS-IS, затем ее анализ и улучшение бизнес-процессов. И только на основе модели TO-BE строится модель данных, прототип и затем окончательный вариант ИС.

.1 Построение модели AS-IS

Построение контекстной диаграммы

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.

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

Контекстная диаграмма выполняется в нотации IDEF0 и показывает систему с точки зрения внешнего наблюдателя.

Взаимодействие работ с внешним миром и между собой описывается в виде интерфейсных дуг (стрелок).

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

Основная деятельность регистратуры санатория ОАО «Авитек» заключается в учете пациентов, поэтому контекстная диаграмма содержит единственную работу (активность) «Учет пациентов» (Приложение 1).

В соответствии с методом IDEF0 для любой активности необходимо определить входные данные, выходные данные, управление и механизм, которые изображаются на диаграмме стрелками:

-Входные данные: данные о потенциальных пациентах, данные о доступных процедурах, биометрические данные.

-Выходные данные: данные о пациентах, предоставленные процедуры.

-Управление: инструкции и нормативные документы.

-Механизм: персонал (регистраторы, медики).

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

Таблица 2 Стрелки контекстной диаграммы

Имя стрелки (Arrow Name)Определение стрелки (Arrow Definition)Тип стрелки (Arrow Type)Потенциальные пациентыЗапросы информации об услугах и т.п.InputДоступные процедурыПроцедуры, предоставляемые санаториемInputРезультаты обследованияДанные, полученные при обследовании пациентаInputИнструкции и нормативные документыПравила предоставления медицинских услуг, правила оформления документации и т.п.ControlПерсоналЗаполнение карточек учета, оказание медицинских услуг и т.д.MechanismПредоставленные процедурыДанные о процедурах, полученных пациентом за период леченияOutputЗаметим, что выходными данными выбраны предоставленные процедуры, поскольку именно эта информация нужна бухгалтерии для расчета стоимости лечения.

Поскольку мы отразили основную деятельность регистратуры санатория ОАО «Авитек» в целом, можно сказать, что контекстная диаграмма построена (Приложение 1). Это самый высокий уровень абстракции, выражающий точку зрения любого внешнего субъекта на организацию.

Детализация контекстной диаграммы

При декомпозиции контекстной диаграммы выделим четыре основные работы (активности), представленные в таблице 3.

Таблица 3 Работы диаграммы декомпозиции А0

Имя работы (Activity Name)Определение (Definition)Анализ возможности лечения (А1)Информирование пациента, консультацииНовый пациент (А2)Создание амбулаторной картыЛечение (А3)Обследование, процедуры, стационарПостановка на учет (А4)Дополнительные услуги, повторное лечение

Первой работой является «Анализ возможности лечения» (А1). Этот процесс начинается, когда потенциальный пациент интересуется возможностью пройти процедуры на базе санатория ОАО «Авитек». Если у пациента не имеется противопоказаний и среди спектра медицинских услуг санатория имеются те, которые наиболее подходят для его реабилитации, пациент поступает на лечение.

Входными данными для функции А1 являются потенциальные пациенты и доступные процедуры. Выходными данными являются сведения о пациенте. Исполнителями функции являются регистраторы.

Если пациента устраивают условия оказания медицинских услуг и их стоимость, то в базе данных должна быть создана его амбулаторная карта. Этот процесс назван «Новый пациент» (А2). Входными данными для его являются сведения о пациенте, выходными - направление на лечение. Исполнителями функции являются также регистраторы.

Центральной и самой важной активностью является «Лечение» (А3). Поскольку все лечебные процедуры должны проводиться с учетом медицинских показаний и состояния пациента, необходимо знать результаты анализов. Они могут быть как у пациента на руках (из районной поликлиники), так и получены при обследовании на базе санатория (в том числе на специализированном медицинском оборудовании). При необходимости, пациент может быть помещен на стационарное лечение сроком до 10 дней.

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

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

Входные данные для функции А3: сведения о пациентах, выходные данные: повторное лечение.

Таким образом, первый этап детализации контекстной диаграммы завершен. Данная модель является одним из уровней деятельности регистратуры. Полученная диаграмма представлена в приложении 2.

Создание диаграммы декомпозиции в нотации DFD

Для дальнейшей детализации рассмотрим активности, выполняемые при анализе возможности лечения.

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

Регистратор по соответствующей базе данных проверяет, возможно ли удовлетворить запрос пациента. Если требуемое время занято, регистратор предлагает другое свободное время. И если потенциального пациента устраивают предложенные условия, то регистратор записывает его данные для дальнейшего внесения в базу данных пациентов.

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

В диаграмму DFD «Анализ возможности лечения» внесем следующие имена работ:

§Обработка запроса на посещение процедур.

§Обработка запроса на прием специалиста.

§Обработка запроса на лечение в стационаре.

Для выполнения этих работ будут использоваться соответствующие хранилища данных:

§База данных «Процедуры».

§База данных «Специалисты».

§База данных «Стационар».

Согласно правилам DFD граничные стрелки должны быть преобразованы во внутренние. Поэтому диаграмма будет содержать две внешние ссылки: входящую «Звонок или явка потенциального пациента» и исходящую «Запись сведений о пациенте». Эта исходящая ссылка связывает активность «Анализ возможности лечения» с активностью «Новый пациент» (Приложение 3).

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

Входящей внешней ссылкой будет «Запись сведений о пациенте». Диаграмма представлена в Приложении 4.

Создание диаграммы декомпозиции в нотации IDEF3

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

Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы.

Для представления в нотации IDEF3 выберем активность «Лечение», поскольку она является центральным процессом, который должен быть отражен в проектируемой АИС. В зависимости от потребностей пациента лечение может проходить по различным сценариям.

При декомпозиции диаграммы А3.1 «Лечение» выделим восемь основных работ, представленные в таблице 4.

Таблица 4 Работы диаграммы декомпозиции А3.1

Имя работы (Activity Name)Определение (Definition)Регистрация направленияВнесение направления в соответствующую Базу данных для статистического учетаОбследованиеАнализы, обследование пациента на медицинском оборудованииПроцедурыПредоставление лечебных процедурПрием специалистаКонсультация с врачом-специалистомЛечение в стационареГоспитализация пациентаВнесение в карту пациентаОбновление информации в амбулаторной карте пациента (внесение результатов анализов, заключений специалистов, отметки о пребывании в стационаре)Формирование списка оказанных услугФормирование списка услуг, оказанных данному пациенту за текущий период леченияПередача информации в бухгалтериюПередача списка предоставленных процедур в бухгалтерию для расчета стоимости лечения

В нотации IDEF3 единицы работы (UOW) являются центральными компонентами модели и требуют более подробного описания. Должны быть определены Объекты (Objects) и Факты (Facts), связанные с работой и Ограничения (Constrains), накладываемые на нее. Для диаграммы А3.1 данные параметры работ представлены в таблице 5.

Цикл реабилитации пациента зависит от параметров, указанных в направлении на лечение. Эти параметры определяют следующие возможные сценарии:

.пациент сразу идет на процедуры,

.пациент вначале проходит обследование, затем по его результатам идет на нужные процедуры;

.после обследования пациент консультируется со специалистом;

.пациент направляется в стационар.

Пути выполнения процессов на диаграмме отражены в виде точек ветвления (Приложение 5).

Таблица 5 Свойства UOW для работ диаграммы декомпозиции А3.1

Имя работы (Activity Name)Свойства UOWРегистрация направленияОбъекты: Амбулаторная карта пациентаФакты: В направлении указана программа реабилитацииОграничения: нетОбследованиеОбъекты: Лаборатория, диагностический центрФакты: Пациент может иметь результаты анализов на руках.Ограничения: нетПроцедурыОбъекты: процедурыФакты: некоторые процедуры могут предоставляться без обследования (ИК-сауна, косметические и т.п.).Ограничения: Для некоторых типов лечебных процедур нужно специальное направление.Прием специалистаОбъекты: Прием врачаФакты: Для приема косметолога не требуются результаты анализов.Ограничения: нетЛечение в стационареОбъекты: стационарФакты: Для учета важна длительность лечения в стационареОграничения: Лечение в стационаре требует наличия анализов и направления районной поликлиники или мед. пункта предприятияВнесение в карту пациентаОбъекты: Амбулаторная карта пациентаФакты: Должны вноситься все результаты анализов, обследований, заключения специалистовОграничения: Обновление данных в амбулаторной карте должно производиться оперативно (в течение одного рабочего дня)Формирование списка оказанных услугОбъекты: Список оказанных услугФакты: Задается период оказания услуг и из амбулаторной карты пациента экспортируется списокОграничения: нетПередача информации в бухгалтериюОбъекты: Список оказанных услугФакты: Предполагается экспорт данных в систему 1СОграничения: нет

Создание диаграммы декомпозиции функции А4

Для полной декомпозиции функций А0 необходима декомпозиция работы А4 «Постановка на учет». Будем проводить декомпозицию в соответствии с методикой IDEF0. Работы диаграммы декомпозиции А4 представлены в таблице 6.

Таблица 6 Работы диаграммы декомпозиции А4

Имя работы (Activity Name)Определение (Definition)Определение группы здоровьяВ соответствии с результатами анализов или пройденными процедурами, пациента относят к некоторой группе здоровья, что отражается в базе данных "Пациенты"Извещение пациентовУведомление пациентов о проводимых плановых мероприятияхСтатистическая обработкаЕжемесячные отчеты о предоставленных услугах, статистика о группах пациентов и т.п.Обращение пациентаПовторное обращение пациента

Диаграмма декомпозиции А4 представлена в Приложении 6.

.2 Определение типов связей между функциями в модели

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

На диаграмме декомпозиции функции А0 «Лечение» связь функций «Новый пациент» и «Постановка на учет» коммуникационная (используются одни входные данные - «Сведения о пациенте»). Во всех остальных диаграммах построенной модели типы связей последовательные.

4. Построение ролевой диаграммы

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

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

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

Поскольку моделируется очень конкретная область деятельности санатория (учет пациентов), то ролевая группа будет всего одна: санаторий, непосредственно обеспечивающий учет пациентов и прохождение ими обследования, процедур и осуществляющий лечение (Таблица 7).

Таблица 7 Ролевые группы

Название (Name)Определение (Definition)Важность (Importance)СанаторийМоделируемое подразделениеHigh

Ролевые группы и роли вносятся в специальные словари (словарь ролевых групп (Dictionary/Role group) и ролей (Dictionary/Role) соответственно). Заполненный словарь ролей для санатория ОАО «Авитек» представлен на рисунке 1.

Рис. 1. Словарь ролей

Полученная автоматически ролевая диаграмма представлена в Приложении 7.

5. Функционально-стоимостной анализ процессов (ABC)

BPwin предоставляет аналитику два инструмента для оценки модели -стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой. Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), и др. в каждой из моделей AS-IS и ТО-ВЕ. Следовательно, стоимостный анализ позволяет оценить, каковы будут последствия внедрения ИС, действительно ли это приведет к повышению производительности и экономическому эффекту и к какому именно.

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

ABC включает следующие основные понятия:

-объект затрат - причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат;

-движитель затрат - характеристики входов и управлений работы, которые влияют на то, как выполняется и как долго длится работа;

-центры затрат, которые можно трактовать как статьи расхода.

На уровне функционального блока связь IDEF0 и АВС-моделей базируется на трех принципах:

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

.Стоимость или время функции, которая не имеет декомпозиции, определяется разработчиком системы.

.Стоимость или время функции, которая имеет декомпозицию, определяется как сумма стоимостей (времен) всех подфункций на данном уровне декомпозиции.

Начнем с определения центров затрат. Основной затратой при внедрении АИС по учету пациентов будет обучение специалистов регистратуры. Кроме того, требуется обеспечение доступа к базам данных, т.е. закупка сервера (как аппаратной, так и программной части).

Стоимость и продолжительность работ для диаграммы А0 «Учет пациентов» представлены в таблице 8.

Таблица 8 Стоимость и продолжительность работ на диаграмме «Учет пациентов»

Имя работы (Activity Name)Центр затрат (Cost Center)Сумма центра затрат (Cost Center Cost), в руб.Продолжительность, (Duration), в дняхЧастота (Frequency)Анализ возможности леченияОбучение специалистов10 00014Новый пациентЗакупка сервера150 00021Лечение----Постановка на учетТелефонная связь50015

Поясним приведенные в таблице данные. В регистратуре работает 4 человека (2 смены по 2 человека). Обучение одного человека будет стоить 10 000 руб. и займет 1 рабочий день. Поскольку сервер баз данных будет использоваться при выполнении нескольких работ, мы его стоимость посчитаем один раз для активности «Новый пациент». Закупка сервера осуществляется один раз и его установка и настройка займет в среднем 2 дня. При реализации активности «Лечение» будет использоваться сервер баз данных: для внесения обновлений в карту пациента, для формирования и передачи отчета об оказанных услугах в бухгалтерию. Стоимость сервера уже учтена, обучение специалистов тоже проводилось на этапе Анализа возможности лечения. Таким образом, здесь затрат не будет. Для активности «Постановка на учет» центром затрат будет телефонная связь, используемая для оповещения о плановых мероприятиях санатория. В месяц проходит в среднем 5 мероприятий по различным направлениям. Извещение пациентов проводится в течении 1 дня за неделю до начала мероприятий.

Таким образом, после внесения необходимых значений параметров денежные характеристики отразились на диаграмме А0 (Приложение 8), а общая стоимость всех работ по учету пациентов отражена на рисунке 2.

Рис. 2. Общая стоимость затрат

Заключение

В рамках выполнения курсовой работы мы ознакомились по литературным источникам с методологией построения моделей в нотациях IDEF0, DFD, IDEF3, изучили доступные на российском рынке инструментальные средства визуального моделирования бизнес-процессов и с помощью выбранного инструмента BPWin построили модель информационной системы, автоматизирующей деятельность регистратора на ОАО «Авитек», а также осуществили функционально-стоимостной анализ процессов.

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

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

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

Библиографический список

1.Вендеров А.М. Проектирование программного обеспечения экономических информационных систем: учебник. - 2-е изд., перераб. и доп. - М.: Финансы и статистика, 2006. - 544 с.

.Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. - М,: Диалог-МИФИ, 2002. - 224 с.

.Проектирование информационных систем: Методические указания по выполнению курсовой работы / Сост. О.В. Караваева. - Киров: ВСЭИ, 2009. - 36 с.

.Смирнова Г.Н. Проектирование экономических информационных систем: Учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред. Ю.Ф. Тельнова. - М.: Финансы и статистика, 2001. - 512 с.

Электронные ресурсы

5.Анализ современных средств моделирования бизнес-процессов / Режим доступа: <#"justify">Приложения

Приложение 1

Контекстная диаграмма

Приложение 2

Диаграмма декомпозиции А0

Приложение 3

Диаграмма декомпозиции А1

Приложение 4

Диаграмма декомпозиции А2

Приложение 5

Декомпозиция функции А3 «Лечение»

Приложение 6

Декомпозиция функции А4 «Постановка на учет»

Приложение 7

Ролевая диаграмма

Приложение 8

Диаграмма А0 с внесенными затратами

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ВЯТСКИЙ СОЦИАЛЬНО-ЭКОНОМИЧЕСКИЙ ИНСТИТУТ Факультет информационных технологий Кафедра информатики

Больше работ по теме: