Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Анализ корпоративной системы поставки медицинских товаров в клинику "Медси"

Анализ корпоративной системы поставки медицинских товаров в клинику "Медси"

Описание структуры клиники "Медси" в городе Пермь. Система поставки медицинских товаров. Разработка подсистемы формирования отказов, основные требования к ней. Пользователи системы, их взаимодействия и роли. Порядок контроля и приёмки подсистемы.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 29.04.2014
Размер файла 849,5 K
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

460.МСА.220200.62-2010.05150- 01 81 01

460.МСА.220200.62-2010.05150- 01 81 01

Размещено на http://www.allbest.ru/

Перечень условных обозначений

БД - база данных

ВКР - выпускная квалификационная работа

ВДН - внутренняя норма доходности инвестиций

ЗАО - закрытое акционерное общество

ИД - индекс доходности

СУДБ - система управления базой данных

ТЗ - техническое задание

ЧДД - чистый дисконтированный доход

Содержание

  • Введение
  • 1. Анализ корпоративной системы поставки медицинских товаров в клинику "Медси"
  • 1.1 Описание структуры клиники "Медси" города Перми
  • 1.2 Описание системы поставки медицинских товаров в клинике "Медси"
  • 1.3 Вывод
  • 2. Разработка подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "МЕДСИ"
  • 2.1 Постановка задачи на проектирование подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "МЕДСИ"
  • 2.2 Пользователи системы их взаимодействия и роли
  • 2.3 Описание подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "Медси"
  • 2.4 Составление технического задания на разработку подсистемы формирования отказов в системе поставки медицинских товаров в клинику "Медси"
  • 2.4.1 Общие сведения
  • 2.4.2 Назначения и цели создания системы
  • 2.4.4 Требования к системе
  • 2.4.5 Состав и содержание работ по созданию подсистемы
  • 2.4.7 Порядок контроля и приёмки подсистемы
  • 2.4.8 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы в действие
  • 2.4.9 Требования к документированию
  • 2.5 Вывод
  • 3. Обзор и анализ программного обеспечения для реализации системного обеспечения подсистемы формирования отказов в медицинском учереждении
  • 3.1 Программный продукт QWERTY
  • 3.2 Программный продукт "Инфоклиника"
  • 3.3 Вывод
  • 4. Анализ программной архитектуры системы поставки медицинских товаров в клинику "Медси"
  • 4.1 Взаимодействие компонентов подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "Медси"
  • 4.2 Вывод
  • 5. Технико-экономическое обоснование проектируемой подсистемы
  • 5.1 Перечень эффектов от разработки подсистемы формирования отказов в корпоративной системе поставки медицинских товаров
  • 5.2 Расчет себестоимости разработки системы
  • 5.2.1 Материальные затраты
  • 5.2.2 Расчет прямых затрат
  • 5.2.3 Амортизация основных фондов
  • 5.3 Прочие затраты
  • 5.3.1 Общие затраты на разработку системы
  • 5.4 Расчет цены на систему
  • 5.5 Расчет эффективности инвестиций
  • 5.5.1 Расчет инвестиционных вложений
  • 5.5.2 Определение экономического эффекта
  • 5.6 Оценка инвестиционного проекта
  • 5.6.1 Расчет чистого дисконтированного дохода
  • 5.6.2 Расчет индекса доходности (ИД)
  • 5.6.3 Расчет внутренней нормы доходности (ВДН) инвестиций
  • 5.6.4 Расчёт периода окупаемости инвестиционного проекта
  • 5.7 Принятие инвестиционных решений
  • 5.8 Вывод
  • 6. Безопасность жизнедеятельности. Организация рабочего места заведующей аптекой
  • 6.1 Анализ условий труда
  • 6.1.1 Характеристика помещения
  • 6.1.2 Характеристика рабочего места
  • 6.1.3 Вид и объем выполняемой работы
  • 6.2 Мероприятия по обеспечению защиты от опасных и вредных факторов
  • 6.2.1 Организация рабочего места
  • 6.3 Расчёт освещения рабочего места
  • 6.4 Вывод
  • Заключение
  • Список литературы

Введение

Функционирование медицинских учреждений невозможно без наличия необходимых медикаментов и оборудования. Поэтому одной из главных задач в процессе работы клиники является разработка системы поставки медицинского товара. В данной выпускной квалификационной работе (ВКР) рассматривается система поставки медицинского товара в клинике "МЕДСИ" города Перми.

Целью ВКР является:

1. Описание и анализ существующей на данный момент в клинике "МЕДСИ" системы поставки медицинских товаров;

2. Выявление недостатков данной системы;

3. Разработка подсистемы формирования отказов;

4. Определение пользователей подсистемы и их взаимодействий;

5. Анализ программного обеспечения (ПО) для реализации подсистемы;

6. Разработка технического задания (ТЗ) на проектирование подсистемы формирования отказов;

7. Описание взаимодействия компонентов подсистемы;

8. Технико-экономическое обоснование проектируемой подсистемы;

9. Анализ условий труда пользователей подсистемы.

1. Анализ корпоративной системы поставки медицинских товаров в клинику "Медси"

1.1 Описание структуры клиники "Медси" города Перми

Клиника "МЕДСИ" в Перми открылась в мае 2009 года по адресу ул. Пушкина, д. 109. Это медицинское учреждение с новейшим оборудованием, предоставляющее полный комплекс медицинских услуг для взрослых и детей и отвечающее единым стандартам качества обслуживания клиентов, принятым в ЗАО группе компаний "МЕДСИ". Организационная структура клиники представлена на рис. 1.1.

Рис. 1.1 Организационная структура клиники "МЕДСИ"

Число сотрудников клиники - 167 человек, в том числе медицинского персонала 71 человек.

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

1.2 Описание системы поставки медицинских товаров в клинике "Медси"

Работа любого медицинского учреждения не возможна без наличия необходимого медицинского товара. Важнейшей задачей для руководителей клиники, является создание системы поставки медицинских товаров. В ходе дипломного проектирования была рассмотрена система поставок в клинике "МЕДСИ".

Для полного описания системы, необходим детальный анализ всех функций, взаимодействий и операций происходящих внутри неё. Наилучшим способом такого анализа является моделирование системы. Существует немало методологий позволяющих смоделировать процесс работы системы, такие как: ARIS, IDEF, Ericson Penker, Geram и т.д. Для моделирования данной системы поставки медицинского товара были использованы методологии: IDEF0 - отображает структуру процессов и функций системы в виде набора взаимосвязанных функциональных блоков, IDEF3 - моделирование процесса, предназначенное для создания сценариев и описания последовательности операций для каждого процесса. Описание взаимосвязей бизнес процедур, как функций или действий

Первая контекстная диаграмма построена в IDEF0 (рис. 1.2). Представляет собой обобщенную модель системы поставки медицинских товаров.

Рис. 1.2 Контекстная диаграмма системы поставки медицинских товаров.

Для реализации внутренних процессов система должна обладать:

· определённым набором входных, выходных данных

· наличием элементов регламентирующих и управляющих работой процессов

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

Для данной системы входом является наличие информации о поставщиках.

На выходе имеем наличие заказанного товара в клинике либо возврат не качественного товара поставщику.

Управляющими воздействиями для данной системы являются:

1) Собственники клиники

2) Стандарты, ГОСТы, СанПиНы РФ регламентирующие работу и функционирование клиники

Механизмы, без которых невозможна реализация данной системы:

1) Персонал клиники

2) Оборудование необходимое в бизнес-процессе

3) Финансы

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

Рис. 1.3 Декомпозиция контекстной диаграммы процесса

Декомпозиция первого функционального блока "Формирование заказа" выполнена в методологии IDEF3 (рис. 1.4).

Рис. 1.4 Декомпозиция процесса "Формирование заказа"

Включает в себя последовательное исполнение 3 действий:

1. Подать заявку

2. Анализ заказа

3. Согласование заказа

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

На выходе активируется одна из исходящих ветвей. Если заказ согласован с директором клиники, то на выходе получаем сформированный заказ, который поступает в блок "Заказ товара"; иначе заказ возвращается в блок "Анализ заказа".

Декомпозируем блок "Анализ заказа" для полного отображения всех происходящих процессов (рис. 1.5).

Рис. 1.5 Декомпозиция блока "Анализ заказа"

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

Рассмотрим декомпозицию блока "Заказ товара" (рис. 1.6). Декомпозиция выполнена в методологии IDEF3. Включает в себя последовательное исполнение четырёх действий.

Рис. 1.6 Декомпозиция процесса "Заказ товара"

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

В блоке "Возврат" осуществляется оформление необходимых документы с указанием причин возврата и возврат некачественной продукции поставщику (рис. 1.7).

Рис. 1.7 Декомпозиция блока "Возврат"

Рассмотрим декомпозицию следующего функционального блока "Оплата", выполненная в IDEF0 (рис. 1.8).

Рис. 1.8 Декомпозиция блока "Оплата"

На вход блока "Произвести оплату" поступает счёт. На выходе из этого блока мы получаем оплаченный счёт или оплаченный счёт по факту поставки.

Управляющими воздействиями для данного блока являются:

1. Собственники клиники

2. Стандарты, ГОСТы, СанПиНы РФ регламентирующие работу и функционирование клиники

3. Выделенные деньги

4. Оплата счёта по факту поставки

Для работы блока требуется: оборудование, персонал, финансы.

Для более детального понимания процесса оплаты, декомпозируем данный блок при помощи методологии IDEF3. (рис. 1.9).

Рис. 1.9 Декомпозиция процесса "Произвести оплату"

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

Рассмотрим декомпозицию следующего функционального блока "Получение товара", выполненную в IDEF3 (рис. 1.10).

Рис. 1.10 Декомпозиция блока "Получение товара"

Состоит из двух функциональных блоков. На вход блока "Поставить" поступает информация о заказанном товаре (из блока "Заказать товар"). Поставка товара подразумевает поставку:

· Товара

· Сопроводительных документов

· Сертификатов соответствия или их заверенных копий

При наличии всего необходимого происходит процесс принятия товара, который осуществляет заведующая аптекой. На выходе из блока мы получаем результат: товар принят либо товар не принят, активируется лишь одна ветвь. Если товар принят, и вид оплаты предусматривает оплату по факту поставки, тогда отправляем соответствующее сообщение на управляющее воздействие в блок "Оплата" (см. рис. 1.8).

Для более детального понимания процессов происходящих в блоках "Поставить" и "Принять" декомпозируем их при помощи методологии IDEF3.

Рассмотрим декомпозицию блока "Поставить" (рис. 1.11). Заказанный товар, поступающий на вход, может доставляться двумя способами:

· Самовывозом (т.е. представитель клиники сам едет за товаром к поставщику)

· Доставка

На выходе, вне зависимости от вида поставки должны быть:

· Товар

· Сопроводительных документов

· Сертификатов соответствия или их заверенных копий

Рис. 1.11 Декомпозиция блока "Поставить"

Рассмотрим декомпозицию блока "Принять" (рис. 1.12).

Рис. 1.12 Декомпозиция блока "Принять"

Все компоненты, полученные на выходе из предыдущего блока, идут на вход рассматриваемого. Приём товара разделяется на 2 стадии. Сопроводительные документы и сам товар отправляются в блок "Проверить наличие заказанного товара". После проверки наличия товара он отправляется в блок "Проверка соответствия товара сертификатам" туда же отправляются сертификаты соответствия. На выходе из блока получаем результат: либо принятию товар принят, либо товар не принят (см. рис. 1.10).

1.3 Вывод

Детальный анализ всех протекающих процессов позволил выявить недостатки данной системы поставки медицинских товаров:

1. отсутствие системы учёта и формирования отказов, возникающих в системе в процессе её функционирования:

2. отсутствие системы позволяющей отслеживать качество работы поставщиков.

Корректировка этих минусов позволит ускорить время процесса и обеспечит корректную работу всего процесса поставки медицинского товара в частную клинику "МЕДСИ".

2. Разработка подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "МЕДСИ"

2.1 Постановка задачи на проектирование подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "МЕДСИ"

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

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

1. отсутствие системы учёта и формирования отказов, возникающих в системе в процессе её функционирования:

ѕ отказ в выделении денежных средств;

ѕ отсутствие товара у поставщика;

ѕ получение не качественного товара;

2. отсутствие системы позволяющей отслеживать качество работы поставщиков.

Наличие этих проблем замедляет процессе поставки медицинского товара и приводит к потере рабочего времени.

В данном дипломном проекте разработана подсистема "Формирования отказов". Цель - отслеживание и анализ возникающих в системе отказов, для выявления факторов риска для всей системы поставки медицинских товаров.

Подсистема формирования отказов включает в себя:

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

· анализ отказов;

· систематизация возникших отказов, путём занесения их в базу данных (БД) клиники;

· контроль над качеством работы поставщиков.

Это позволяет сократить время работы системы, благодаря:

· отсутствию дублирования заказов;

· сокращению времени на анализ и выбор поставщиков;

· сокращению времени для согласования с собственниками;

· сокращения вероятности получения не качественного товара.

2.2 Пользователи системы их взаимодействия и роли

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

Заведующая аптекой:

ѕ анализ поставщиков;

ѕ анализ заказа;

ѕ заказ товара, оговариваются сроки и способы доставки и оплаты заказа;

ѕ приём товара;

ѕ возврат товара и оформление сопроводительных документов.

Главная медсестра:

ѕ сбор заявок у врачей и отделений;

ѕ анализ заявок;

ѕ формирование заказа;

ѕ согласование заказа.

Директор клиники:

ѕ управление клиникой;

ѕ контроль над работой персонала;

ѕ принятие решения о необходимости товара;

ѕ согласование с собственниками.

Собственник:

ѕ принятие решения о выделении денежных средств.

Бухгалтер:

ѕ завизировать счёт;

ѕ оплатить счёт;

ѕ формирование бухгалтерской документации и отчётности.

Системный администратор:

ѕ поддержка программного обеспечения.

Поставщик:

ѕ получение заказа;

ѕ выполнение заказа.

Взаимодействия между всеми пользователями системы отражены на схеме (рис. 2.1).

Рис. 2.1 Схема взаимодействия пользователей системы поставки медицинского товара, в процессе её работы

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

2.3 Описание подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "Медси"

Разработанная подсистема "Формирование отказов" является частью существующей корпоративной системы поставки медицинских товаров, которая была ранее рассмотрена (см. п. 1.2). Для более ясного представления назначения данной подсистемы, смоделируем ее, используя методологии IDEF0 и IDEF3.

В отличие от ранее рассмотренной декомпозиции контекстной диаграммы (см. рис. 1.3), все возникающие в процессе работы отказы направляются в блок "Формирования отказов" (рис. 2.2). В изучаемой системе поставки медицинских товаров возможны 3 основных вида отказов:

отсутствие товара у поставщика;

отказ собственника в выделении денег на товар;

товар не принят клиникой.

Рис. 2.2 Декомпозиция контекстной диаграммы процесса

На выходе из блока имеем:

ѕ управляющие воздействия на смену поставщика;

ѕ информирование об отказе выделения денежных средств;

ѕ товар необходимый к возврату.

Для более детального понимая процесса, декомпозируем блок "Формирование отказов" (рис. 2.3). Данная декомпозиция выполнена в методологии IDEF3.

Рис. 2.3 Декомпозиция блока "Формирование отказов"

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

При поступлении в блок отказа "Товар не принят", данная информация поступает на вход функционального блока "Возврат". Декомпозируем данный блок (рис. 2.4).

Рис. 2.4 Декомпозиция блока "Возврат"

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

При проектировании подсистемы блок "Возврат" был перенесён из процесса "Заказа товара" (см. рис. 1.6) в блок "Формирования отказов". Поскольку это более логично, с точки зрения экономии рабочего времени специалиста, и не вносит коренных изменений в процесс поставки медицинского товара в целом. Изменения, произошедшие в блоке "Заказ товара" представлены на рисунке 2.5.

Рис. 2.5 Декомпозиция блока "Заказ товара"

2.4 Составление технического задания на разработку подсистемы формирования отказов в системе поставки медицинских товаров в клинику "Медси"

На основе данных изученных в пунктах 2.1 и 2.2 составляется ТЗ на разработку подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "МЕДСИ".

2.4.1 Общие сведения

2.4.1.1 Полное наименование системы и ее условное обозначение

Подсистема формирования отказов в корпоративной системе поставки медицинских товаров в клинику "МЕДСИ"

2.4.1.2 Шифр темы или шифр (номер) договора

№ 240888

2.4.1.3 Наименование предприятий разработчика и заказчика системы и их реквизиты.

Разработчик: студентка группы АУЦ-05, Назукина Юлия

Заказчик: клиника ЗАО группа компаний "МЕДСИ" г. Пермь

2.4.1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы.

Основанием для разработки является: решение совета директоров.

2.4.1.5 Плановые сроки начала и окончания работы по созданию системы.

Начало работ - 1.07.2009

Окончание работ - 1.09.2009

2.4.1.6. Сведения об источниках и порядке финансирования работ.

Финансирование ведется по выполнению каждой стадии разработки.

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

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

2.4.2 Назначения и цели создания системы

2.4.2.1 Назначение системы.

Формирование отказов в системе поставки медицинских товаров в клинику

2.4.2.2 Цели создания системы.

Отслеживание и анализ возникающих в системе отказов, для выявления факторов риска для всей системы поставки медицинских товаров.

2.4.3 ХАРАКТЕРИСТИКА ОБЪЕКТОВ АВТОМАТИЗАЦИИ.

2.4.3.1 Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию

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

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

· анализ отказов;

· систематизация возникших отказов, путём занесения их в БД клиники;

· контроль над качеством работы поставщиков.

2.4.4 Требования к системе

2.4.4.1 Требования к системе в целом.

2.4.4.1.1 Требования к структуре и функционированию системы.

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

2.4.4.1.2 Требования к численности и квалификации персонала системы и режиму его работы.

Должность

Кол-во человек

Чем занимается

Режим работы

Требования к образованию

Инженер-Программист

1

Заполнение БД,

программирование

10: 00-18: 00

Высшее

Инженер-проектировщик

1

Разработка проектов

10: 00-18: 00

Высшее

Системный администратор

1

Техническое обслуживание системы

10: 00-18: 00

Высшее

2.4.4.1.3 Показатели назначения.

Система должна бесперебойно работать в течение всего срока эксплуатации.

1 Эксплуатация системы во время гарантийного срока.

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

· Исполнитель уполномочен, в каждом конкретном случае, оценить, распространяется ли гарантийный период на всю подсистему в целом.

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

· Исполнитель обязуется совместно с заказчиком расследовать причины выхода из строя подсистемы, не отработавшего гарантийный срок, с составлением двухстороннего акта расследования установленной формы. Гарантийный ремонт, производится в течение 45 календарных дней с момента подписания сторонами акта расследования и установления вины исполнителя.

· В случае отсутствия вины исполнителя, заказчик оплачивает расходы, понесенные исполнителем при расследовании (транспортные расходы, командировочные, работа специалистов и пр.).

2. Эксплуатация системы во время эксплуатационного срока.

· При поломке системы в течение срока эксплуатации ремонт производится в установленный срок компанией - поставщиком.

3 Модернизация системы.

· Предусмотрена модернизация системы по заказу в установленные сроки.

4 Система должна работать и обеспечивать:

· Работу в среде операционных систем Windows XP, Vista и наиболее высоком уровне;

· Работу в локальной сети, в сети Интернет и автономно;

· Работу с БД;

· Работу с ПО 1: С - бухгалтерия;

· Работу с ПО QWERTY;

· Работу с ПО "Инфоклиника".

2.4.4.1.4 Требования к надежности.

1. Бесперебойная работа оборудования втечении срока эксплуатации.

2. Не допускаются простои системы из-за возможной поломки.

2.4.4.1.5 Требования безопасности.

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

2. Должна быть обеспечена защита от воздействий электрического тока.

3. Персонал должен быть ознакомлен с инструкциями техники безопасности.

4.2 раза в год проверка знаний персонала по ТБ и выполняемым функциям.

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

2.4.4.1.6 Требования к эргономике и технической эстетике.

Оборудование должно быть удобно в использовании для персонала, работающего на нем.

2.4.4.1.7 Требования к эксплуатации, техническому обслуживанию и хранению компонентов системы.

1. Оборудование должно проходить ТО 2 раза в год - проверяется вся система полностью в разных режимах.

2. Текущее ТО - проверка системы на работоспособность.

3. Оборудование должно эксплуатироваться в условиях, соответствующих требуемым.

4. Не допускается эксплуатация неработающего оборудования до устранения поломки.

5. Персонал, работающий с системой должен иметь образование не ниже среднего специального.

2.4.4.1.8 Требования к защите информации от несанкционированного доступа.

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

2. Пользователям запрещается разглашать логины, пароли.

2.4.4.1.9 Требования по сохранности информации при авариях.

1. Для обеспечения бесперебойности установить источники бесперебойного питания на сервер и компьютер.

2. База данных технологических процессов и резервные копии Windows сохраняются на отдельном жестком диске на сервере.

3. При повреждении информации она восстанавливается из резервных файлов на сервере.

2.4.4.1.10 Требования к защите от влияния внешних воздействий.

Условия эксплуатации должны соответствовать параметрам, описанным в инструкции по эксплуатации.

2.4.4.1.11 Требования к патентной чистоте.

Заказчик обеспечивает проверку проектируемой системы на патентную чистоту.

2.4.4.1.12Требования по стандартизации и унификации.

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

2.4.4.1.13. Дополнительные требования.

1. Необходимо провести подготовительные курсы по обучению работе в системе.

2. Необходимо предоставить персоналу документацию для работы в системе

2.4.4.2 Требования к функциям (задачам), выполняемым системой.

2.4.4.3 Требования к видам обеспечения.

2.4.4.3.1 Математическое обеспечение.

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

2.4.4.3.2 Информационное обеспечение

1. Все данные должны архивироваться и храниться в базе данных.

2. Для беспрепятственного обмена данными между элементами системы все изменения в системе должны быть унифицированы.

3. Система должна быть совместима со смежными системами.

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

классификаторы.

5. В проектируемой системе должны использоваться СУБД

6. Сервер должен быть оснащен системой обеспечения бесперебойного питания.

7. Данные о ходе технологического процесса должны храниться 12 месяцев, после чего отправляются в архив.

2.4.4.3.3 Лингвистическое обеспечение.

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

2.4.4.3.4 Программное обеспечение.

Список обеспечения:

№

Наименование ПО

Кол-во шт

1

Microsoft Office 2007

1

2

Windows XP professional AcademicEdition

1

3

1: С - бухгалтерия

1

4

Инфоклиника

1

5

QWERTY

1

2.4.4.3.5 Техническое обеспечение.

Все технические средства должны быть совместимы с остальными компонентами системы и с другими системами. Минимальные требования для установки и пользования системой 1: С-бухгалтерия:

· Операционная система Windows XP, Windows Vista

· Процессор Intel Pentium 2 (и выше), с частотой 400 МГц

· Операционная память 128 Мб

· Жёсткий диск 229 Мб

· Устройство чтения дисков

· USB порт

2.4.4.3.6 Организационное обеспечение.

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

В системе должна быть предусмотрена защита от ошибочных действий персонала.

2.34.3.7 Методическое обеспечение.

Нормативно-техническая документация системы включает в себя:

1. Правила техники безопасности

2. Инструкции по работе с системой

2.4.5 Состав и содержание работ по созданию подсистемы

В соответствии с ГОСТ 34.602 работа над системой должна состоять из следующих стадий и этапов.

Стадия 1. Исследование существующего объекта

Этап 1.1 Исследование существующего бизнес процесса

Стадия 2. Модернизация существующего объекта.

Этап 2.1 Модернизация существующих установок

Стадия 4. Установка компьютерного оборудования и ПО

Этап 4.1 Установка компьютеров и прокладка сети

Этап 4.2 Установка ПО и настройка ПО для работы с системой

Стадия 5. Тестирование системы

Этап 5.1 Провести тестирование системы на работоспособность.

Этап 5.2 Проверить системы на совместимость с ПО.

Стадия 6. Внедрение системы

2.4.6 ИСПОЛНИТЕЛИ РАБОТ

1. Исследованием, модернизацией и внедрением объекта занимается разработчик системы.

2. Установкой оборудования и ПО занимается системный администратор клиники.

3. Тестированием системы занимается программист и разработчик системы.

2.4.7 Порядок контроля и приёмки подсистемы

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

2.4.8 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы в действие

При необходимости вводятся как дополнение к настоящему ТЗ по результатам опытной эксплуатации первых версий системы.

2.4.9 Требования к документированию

В ходе работы над системой разработчиком подготавливаются следующие документы в соответствии с требованиями ГОСТ 34.201-89 и ГОСТ 19.101-77

1 Пояснительная записка к эскизному проектированию;

2 Описание организационной структуры;

3 Описание массива информации;

4 Ведомость держателей подлинников;

5 Описание программного обеспечения;

6 Инструкция по формированию и ведению базы данных;

7 Руководство пользователя (руководство оператора);

8 Общее описание системы.

9 Ведомость эксплуатационных документов

2.4.10 Источники разработки

ТЗ составил:

Наименование организации, предприятия

Должность исполнителя

Фамилия имя, отчество

Подпись

Дата

АУЦ-05

Студентка

Назукина Юлия Алексеевна

2525.05.2010

2.5 Вывод

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

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

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

3.1 Программный продукт QWERTY

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

· учета товара;

· управления ассортиментом;

· управления закупом;

· управления дисконтом;

· справочных столов.

Широко распространены решения фирмы для автоматизации розничной торговли. В настоящий момент программное обеспечение QWERTY используют около 800 розничных точек различных форм собственности в различных регионах России.

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

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

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

· региональные системы учета льготной рецептуры,

· справочные столы,

· единую систему заказа лекарств у поставщиков,

· систему контроля качества лекарственных средств;

· другие системы, требующие единого подхода на основе справочников.

Наличие единых для региона систем максимально организует рынок и

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

Перечень предоставляемых услуг:

· обследование предприятия или аптеки;

· конфигурирование программно-технического комплекса под требования заказчика;

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

· проектирование и монтаж ЛВС;

· настройка операционной системы и сетевого программного обеспечения;

· техническое обслуживание компьютерной техники;

· установка и настройка системы;

· продажа и внедрение программ фирмы "1С";

· обучение персонала Заказчика работе с системой;

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

· создание необходимых дополнительных отчетных форм;

· доработки программного обеспечения под требования Заказчика;

· техподдержка и/или сопровождение системы;

· обеспечение импорта документов в "1С-Бухгалтерию";

· осуществление консультаций по "горячей линии".

С 1999 года компания "Кверти" является официальным партнером фирмы "1С". Работает с различными торговыми и промышленными предприятиями города Перми и Пермского Края.

3.2 Программный продукт "Инфоклиника"

Комплекс программ автоматизации управления поликлиникой "Инфоклиника" - это:

· Ведение картотеки пациентов и электронной истории болезни;

· Формирование схем лечения;

· Управление расписанием клиники;

· Автоматический расчет стоимости работ;

· Учет кассовых операций;

· Складской учет. Расчет зарплаты;

· Работа со страховыми компаниями и предприятиями;

· Работа с RG-изображениями.

МИС ИНФОКЛИНИКА - комплексная медицинская информационная система (МИС), позволяющая организовать управление поликлиникой, больницей, стационаром или медицинским центром на современном уровне.

МИС ИНФОКЛИНИКА включает в себя следующие аспекты:

· Регистратура и расписание приема;

· Учет оказанных услуг;

· Электронная история болезни / электронная медицинская карта;

· Расчеты с пациентами, страховыми компаниями и подрядчиками;

· Медико-экономические стандарты;

· Учет работы служб скорой помощи и оказания помощи на дому;

· Статистика и аналитика (медицинский информационно-аналитический центр, МИАЦ);

· Автоматизация стационара;

· Управление сетью филиалов;

· модуль "Складской учет":

ѕ закупка, выдача и возврат материалов на склад;

ѕ перемещение материалов (между складами, кабинетами и докторами);

ѕ списание материалов в производство;

ѕ Планируемый расход материалов по нормативам и отклонение фактического расхода от планируемого;

ѕ Инвентаризация;

ѕ Реализация на сторону и списание по негодности;

ѕ Отчеты по остаткам, оборотам и закупочным ценам;

ѕ Оформление заявок на получение/закупку материалов;

ѕ Контроль неснижаемого остатка материала;

ѕ Расчет цены по средневзвешенной;

ѕ Учет закупочных партий;

ѕ Контроль сроков годности;

ѕ Розничная продажа медикаментов и материалов и отчеты по торговой наценке.

Рис. 3.1 Интерфейс программного обеспечения "Инфоклиника"

3.3 Вывод

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

4. Анализ программной архитектуры системы поставки медицинских товаров в клинику "Медси"

4.1 Взаимодействие компонентов подсистемы формирования отказов в корпоративной системе поставки медицинских товаров в клинику "Медси"

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

Выделим необходимые подсистемы:

подсистема данных о поставщиках;

подсистема данных о персонале клиники;

подсистема документов;

подсистема данных о документах (метаданные);

подсистема бизнес - логики (содержит сведения о существующих в подразделении бизнес - процессах);

подсистема взаимодействия с пользователями;

подсистема связи с другими системами.

Данные подсистемы образуют следующие слои (составные части системы):

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

2. Слой - данные (хранилище документов) - фрагмент БД, содержащий информацию собственно о документах, функционирующих в системе.

3. Слой - метаданные (описание документов) - содержит структуру,

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

4. Слой - бизнес логики (правила работы с документами) - представлен набором хранимых процедур, инкапсулирующих логику работы с документами и справочными данными. Любое взаимодействие клиента с БД затрагивает этот слой.

5. Работа со справочниками - модуль приложения (клиента), обеспечивающий интерфейс к соответствующему слою.

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

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

8. Администрирование - обеспечения взаимодействия с другими ПО.

9. Модули связи - могут потребоваться для связи (экспорта данных) проектируемой системы с другими системами (внешними по отношению к проектируемой системе). Функциональность и технические требования к этим модулям должны быть согласованны отдельно.

На рисунке 4.1 показано взаимодействие этих слоев и модулей системы.

Рис. 4.1 Взаимодействие компонентов системы

4.2 Вывод

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

5. Технико-экономическое обоснование проектируемой подсистемы

5.1 Перечень эффектов от разработки подсистемы формирования отказов в корпоративной системе поставки медицинских товаров

Внедрение данной подсистемы даст следующие эффекты:

· Увеличится скорость процесса заказа товара, а именно анализа и выбора поставщиков;

· Увеличение скорости процесса формирования заказа, путём отсутствия дублирования отклоненных заказов;

· Сокращение расходов и потерь при возврате не качественного товара;

· Уменьшение внутренних потерь рабочего времени;

· Позволит отслеживать поставщиков контрафактной продукции.

5.2 Расчет себестоимости разработки системы

Под себестоимостью системы будем понимать общие затраты разработчика на создание программного продукта. Длительность разработки программного продукта - 2 месяца.

Себестоимость системы (или смета затрат на создание программного продукта) определяется по следующим экономическим элементам:

· Материальные затраты;

· Затраты на оплату труда + отчисления на социальное страхование;

· Амортизация основных фондов + аренда основного капитала;

· Прочие затраты.

Исходные данные

При расчете себестоимости системы будем принимать во внимание следующие данные:

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

· Компьютерное оборудование и программное обеспечение используется штатное (используемое в клинике "МЕДСИ".

5.2.1 Материальные затраты

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

Сумма материальных затрат приведена в таблице 5.1.

Таблица 5.1 Материальные затраты

Наименование материального ресурса

Единицы измерения

Цена 1 ед. потребляемого ресурса, руб.

Расход ресурса, ед. /мес.

К-во месяцев потребления

Стоимость потребляемого ресурса, руб.

Бумага

Упаковки

150,00

1

2

300,00

Флэш карта

Шт.

650,00

1,00

1

650,00

Картридж для принтера НР LaserJet 1020

Шт.

550,00

0,5

2

550,00

Канц. товары

Шт.

2

1000,00

Итого:

2500,00

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

5.2.2 Расчет прямых затрат

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

· Материалы, покупные изделия;

· Основная зарплата персонала;

· Дополнительная зарплата персонала;

· Отчисления на социальные нужды.

Затраты на оплату труда персонала (таблица 5.2).

Таблица 5.2 Персонал, необходимый для создания системы

Категория работников

Кол-во, чел.

Заработная плата, руб. /мес.

Технический персонал (программисты)

2

15000

Технический персонал (лаборант)

1

8000

Общехозяйственный и управленческий персонал

1

20000

Длительность разработки программного продукта: 2 месяца.

Затраты на оплату труда основного (технического) персонала:

Основная заработная плата основного персонала - Cосн. зар:

tраб. = 3 - количество месяцев, необходимых для разработки; Cосн. з/пл. програм. =15000 руб. - месячная зарплата программистов; Cосн. з/пл. техн. персон = 8000руб. - месячная зарплата технического персонала; Кпрограм. =2 - численность программистов; Ктехн. персонал =1 - численность технического персонала;

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены