Техническое задание на внедрение сервисной шины данных и системы нси в зао «Группа компаний «Медси» Общие требования к системе - polpoz.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
Техническое задание на изготовление баннеров общие требования 1 18.96kb.
Техническое задание на кровать больничную четырехсекционную с регулируемой... 1 94.19kb.
Техническое задание к Государственному Контракту на разработку информационной... 3 374.94kb.
Приложение № техническое задание на проектирование системы отопления... 1 45.94kb.
Задание: Для модели базы данных, разработанной в первой самостоятельной... 1 22.43kb.
Техническое задание по выбору поставщика для сертификации системы... 1 93.86kb.
Техническое задание на техническое обслуживание оборудования транспортабельной... 1 120.03kb.
Техническое задание к лоту № Исследование глубинных проб пластовых 1 88.75kb.
Зао «Аграрная Группа» 1 42.22kb.
Информационные системы и технологии образовательными организациями... 1 302.69kb.
Техническое задание Временная консультационная деятельность 1 18.04kb.
Модели дискретных каналов связи Михаил Владимирович Марков 1 150.93kb.
1. На доске выписаны n последовательных натуральных чисел 1 46.11kb.

Техническое задание на внедрение сервисной шины данных и системы нси в зао «Группа - страница №1/1









«УТВЕРЖДАЮ»








Директор департамента ИТ

ЗАО «Группа компаний «Медси»







________________ / Калюжный И.О. /








































ТЕХНИЧЕСКОЕ ЗАДАНИЕ


на внедрение сервисной шины данных и системы НСИ в

ЗАО «Группа компаний «Медси»


  1. Общие требования к системе

Общие требования:
Цель проекта – повышение эффективности управления предприятием за счет:

  • консолидации информации из различных источников (медицинские информационные системы, финансовые информационные системы);

  • повышение качества данных за счет их нормализации в системе управления нормативно-справочной информацией;

  • увеличения скорости обмена данными между информационными системами при сокращении рисков потерь данных;

Проект внедрения сервисной шины данных является первым этапом в создании комплекса интеграции финансовой, медицинской и управленческой информации ЗАО «Группа компаний «Медси». В рамки данного ТЗ предусматривается подключение к сервисной шине данных обменов по медицинским договорам, услугам, пациентам, и прикреплениями в ЗАО «Группа компаний «Медси».




  1. Требования к составу решения:

Система должна состоять из следующих программных модулей:

  • Сервисная шина данных (Enterprise Service Bus, далее ESB). Предназначена для интеграции гетерогенных программных комплексов в единое информационное пространство.

  • Система управления нормативно-справочной информацией (Master Data Management System, далее MDM). Предназначена для хранения эталонных справочных данных, общих для всех информационных систем предприятия.

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


  1. Функциональные требования к системам




    1. Функциональные требования к ESB:

Поддержка синхронного и асинхронного транспорта данных.

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



Гарантированная доставка сообщений (данных).

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



Транзакционная модель обмена данными.

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



Наличие возможности создания маршрутов с помощью средства визуализации или программирования.

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



Доступ к сообщениям ESB из сторонних информационных систем в механизмах передачи данных.

Система должна поддерживать такие виды транспорта данных как передача файлов на FTP-сервер, передача данных по технологии SOAP, передача данных через общий поток по протоколу TCP/IP, передача данных через COM, передача файлов по электронной почте (e-mail).

Система должна поддерживать следующие форматы передаваемых сообщений:


  • файл: произвольного формата, XML-файл произвольной структуры, XML-файл структуры HL7, XML-файл, являющийся пакетом типового обмена 1С:Предприятие.

  • данные: строка, число, дата, COM объект, данные 1С:Предприятие (структура, таблица значений)

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

Доступ к сообщениям сторонних систем из ESB в механизмах передачи данных.

Система должна поддерживать такие виды транспорта данных как получение файлов с FTP-сервера, получение файлов по технологии SOAP, получение файлов через общий поток по протоколу TCP/IP, получение файлов через COM, прием файлов по электронной почте (e-mail).

Система должна поддерживать следующие форматы передаваемых сообщений:


  • файл: произвольного формата, XML-файл произвольной структуры, XML-файл структуры HL7, XML-файл, являющийся пакетом типового обмена 1С:Предприятие.

  • данные: строка, число, дата, COM объект, данные 1С:Предприятие (структура, таблица значений).

  • система обязательно должна поддерживать формат обмена данными HL7 версии 2.5;

Преобразование входящих сообщений (данных) в формат хранимых или исходящих сообщений средствами визуализации.

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



Преобразование входящих сообщений (данных) в формат хранимых или исходящих сообщений средствами программирования.

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



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

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



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

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



  • использование таблиц конвертации,

  • настройка оркестровки с применением средств разработки.

Защита передаваемых сообщений (данных) от несанкционированного доступа.

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



Наличие аудита (протоколирования).

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



Наличие рабочего стола администратора системы.

Система должна иметь пользовательский интерфейс для администраторов Системы, наглядно предоставляющего информацию о:



  • сбоях в каналах передачи данных,

  • сбоях в настройках межсетевых экранов,

  • сбоях в правах доступа к ресурсам,

  • статистике транспорта сообщений,

  • загрузке каналов передачи данных.

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

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



Интеграция с MDM.

Система должна иметь специальный интерфейс для интеграции с внешней системой управления нормативно-справочной информацией (MDM) или встроенную систему класса MDM.



Интеграция с BI.

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



Управление потоками работ (Workflow).

Система должна иметь возможность включать пользователей в процесс разрешения конфликтов несоответствия и процесс принятия сложных решений (Workflow), а именно:



  • наличие возможности просмотра и исправления несоответствий,

  • информирование в режиме реального времени о наличии несоответствия,

  • ведение списка задач пользователя,

включение пользователя в бизнес-процесс маршрутизации сообщений.

Требования к локализации и поддержке системы производителем:

Система должна быть официально локализована для использования в Российской федерации.

В Российской Федерации должна быть организована официальная поддержка системы силами производителя, включающая в себя возможность оказания консультаций по телефону и электронной почте в режиме не менее чем 9х5 (9 часов в день по рабочим дням, 5 дней в неделю)
Производительность и масштабируемость системы

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

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


  • медицинская информационная система «1С:Поликлиника» на платформе 1С:Предприятие 8 (3 различные базы данных);

  • медицинская информационная система «1С:Стационар» на платформе 1С:Предприятие 8 (2 различных базы данных);

  • лабораторная информационная система «АЛИСА» на платформе 1С:Предприятие 8 (4 различные базы данных);

  • аптечная информационная система 1С:Управление финансово-хозяйственной деятельностью на платформе 1С:Предприятие 8 (5 различных баз данных);

  • система 1С:Бухгалтерия 8 КОРП;

  • система 1С:Управление производственным предприятием 1.3;

  • система 1С:Зарплата и управление персоналом (2 различные базы данных);

  • система 1С:Учет медицинских договоров на платформе 1С:Предприятие 8 (2 различные базы данных);

  • система 1С:Единый расчетный центр на платформе 1С:Предприятие 8;

  • система 1С:Санаторно-курортная деятельность на платформе 1С:Предприятие 8;

  • система 1С:Учет питания на базе 1С:УПП (3 различные базы данных);

  • система КСПП: Консолидированная система поддержки продаж;

  • система управления денежными средствами (АСУ ДС);

  • корпоративный портал (Битрикс);

  • сайт записи на прием через интернет (php).

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


    1. Функциональные требования к MDM:

Хранение эталонных данных.

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



Поиск информации в механизмах нормализации, в том числе отложенных по регламентному заданию.

Система должна производить поиск информации в целях нормализации:



  • по набору полей;

  • по набору полей с применением формул и условий, взятых из текущей записи,

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

Условия, применяемые в механизмах поиска информации.

В механизмах поиска информации Системы в целях нормализации должны использоваться следующие условия:



  • для числовых значений: равно, не равно, больше, меньше, не больше, не меньше,

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

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

  • Готовые шаблонные сложные механизмы поиска и обработки информации в регламентных заданиях и по запросу пользователя;

Система должна иметь встроенные инструменты для выполнения обработки нормативно-справочной информации (НСИ):

  • произвольный поиск информации;

  • поиск и замена дублирующихся элементов НСИ;

  • механизм работы со связанными таблицами;

  • установка между элементами НСИ связи типа «аналог»

  • создание сценариев для сопоставления данных из различных систем и справочников;

  • ведение журналов изменений атрибутов и полей справочников;

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

Управление заявками на добавление, изменение объектов.

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

MDM должен передавать и получать заявки от внешних систем посредством ESB в полностью автоматическом режиме.

Бизнес-процесс с участием пользователя в механизмах работы системы.

В Системе должна быть предусмотрена возможность включать пользователя в процесс обработки заявок на изменение, добавление, удаление элементов НСИ (Workflow).



Бизнес процесс без участия пользователя в механизмах работы системы.

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



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

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



Управление релевантностью при идентификации записей по набору ключевых полей.

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



Механизм выдачи заданий операторам НСИ.

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



Механизм контроля работы операторов НСИ.

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



  • мониторинг статистики работы операторов,

  • настройка и автоматический мониторинг лимитов времени по обработке различных видов заявок различных справочников, в случае их превышения - уведомление ответственного лица и/или полностью автоматизированная обработка по определенным алгоритмам;

Наличие аудита (протоколирования).

В модуле MDM Системы должен быть предусмотрен механизм протоколирования:



  • всех поступающих заявок на обработку НСИ,

  • всех действий операторов НСИ,

  • всех прочих действий, направленных на нормализацию НСИ,

  • всех сбоев в Системе.

Формирование уведомлений по e-mail.

Система должна позволять настраивать возможность уведомления операторов НСИ о различных событиях, происходящих с НСИ, администраторов – о сбоях в работе модуля Системы. Как минимум должны поддерживаться такие способы уведомления как e-mail и SMS.



Требования к разделению административных полномочий в системе

Система должна обеспечивать распределение полномочий по ролям: пользователь системы, сотрудник службы НСИ, эксперт службы НСИ;



Требования к локализации и поддержке системы производителем:

Система должна быть официально локализована для использования в Российской федерации;

Все пользовательские интерфейсы системы должны быть на русском языке;

В Российской Федерации должна быть организована официальная поддержка системы силами производителя, включающая в себя возможность оказания консультаций по телефону и электронной почте в режиме не менее чем 9х5 (9 часов в день по рабочим дням, 5 дней в неделю);





  1. Общие требования к архитектуре интеграционного решения

  • Архитектура проектируемого интеграционного решения должна исключить реализацию соединений систем по принципу «точка-точка» и быть реализована с использованием централизованного подхода.

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

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

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

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

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




  1. Требования к выполнению работ




    1. Общие требования и допущения проекта:

      1. Исполнитель должен выполнить следующие виды работ:

  • Общее проектирование решения и согласование его с Заказчиком;

  • Проектирование и согласование с Заказчиком механизмов интеграции бизнес-систем с ESB и MDM;

  • Проектирование и согласование с Заказчиком состава ИТ инфраструктуры для выполнения проекта;

  • Установку и настройку систем на оборудовании Заказчика;

  • Организация необходимых доработок бизнес-систем Заказчика, входящих в периметр интеграции - не входит в данный проект и выполняется в рамках других проектов (КСПП, Казначейство и т.п.);

  • Выполнение работ по подключению систем, перечисленных в п.8 данного ТЗ к системе ESB и системе НСИ;

  • Нормирование справочных данных внешних систем, в т.ч. построение кросс-таблиц связей между однородными справочниками, не входит в границы проекта. Кросс-таблицы связей предоставляет Заказчик;

  • Проведение обучения сотрудников Заказчика работе с внедренными системами;

  • Тестирование системы;

  • Ввод системы в промышленную эксплуатацию;

  • Гарантийное сопровождение системы.




      1. Внедрение модуля ESB Системы должно включать в себя следующие работы:

  • проведение обучения администраторов;

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

  • проведение тестирования системы;

  • ввод и передача системы в промышленную эксплуатацию.

      1. Для интеграции каждой отдельной внешней бизнес-системы с модулем ESB работы по внедрению (настройки интеграции) должны включать в себя следующие этапы:

  • обследование и детальное описание существующих информационных обменов с внешними бизнес-системами;

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

  • проектирование маршрутов потоков данных и трансформации сообщений;

  • проведение работ по реализации маршрутов потоков данных и трансформации сообщений;

  • подключение внешней системы к ESB;

  • Нормирование справочных данных внешних систем, в т.ч. построение кросс-таблиц связей между однородными справочниками, не входит в границы проекта. Кросс-таблицы связей предоставляет Заказчик или организует процесс постепенного нормирования в рамках проектов внедрения КСПП, Казначейство и др.;

  • ввод подключения системы в промышленную эксплуатацию.

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


      1. Внедрение модуля MDM Системы должно включать в себя следующие работы:

  • установка системного и прикладного программного обеспечения;

  • проведение интеграции с ESB;

  • проведение тестирования интеграции с ESB;

  • проведение обучения операторов НСИ;

  • загрузка НСИ из внешних бизнес-систем;

  • организация работ по дальнейшему ведению НСИ силами Заказчика;

  • ввод и передача MDM в промышленную эксплуатацию.

      1. Интеграция MDM с каждой внешней бизнес-системой должна включать в себя следующие работы:

  • определение детальных требований к интеграции MDM с внешней системой;

  • проведение работ по интеграции внешней системы с MDM;

  • проведение тестирования интеграции;

  • ввод интеграции в промышленную эксплуатацию.

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


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

      1. Система должна обеспечить защиту персональных данных на всех этапах их передачи, приема, обработки, записи и хранения в соответствии с Федеральным законом о персональных данных.

      2. Система должна иметь механизмы разделения ролей по доступу к справочникам.

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

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




    1. Нефункциональные требования:

Эргономика.

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



Адаптивность.

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



Отказоустойчивость.

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



Дизайн.

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



Язык системы.

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




  1. Требования к составу и количеству лицензий




    1. Лицензии на один отказоустойчивый кластер MDM.

    2. Лицензия на 5 удаленных внешних систем.

    3. Лицензия на один отказоустойчивый кластер ESB.

    4. Лицензия на 100 рабочих мест операторов НСИ.




  1. Требования к гарантийному обслуживанию




    1. Гарантия на все доработки Интегратора должна составлять не менее одного календарного года с момента принятия Системы в промышленную эксплуатацию.

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

    3. Интегратор должен провести первичное обучение выделенных сотрудников, а впоследствии проводить и периодическое обучение новых сотрудников ЗАО «ГК «Медси» программированию в среде разработки Системы, стоимость обучения одного сотрудника необходимо указать отдельной строкой коммерческого предложения.

    4. Гарантийное обслуживание должно состоять из (должно быть указано в коммерческом предложении раздельными строками):

  • удаленных консультаций сотрудников ЗАО «ГК «Медси» Интегратором (по телефону, электронной почте, с приведением конкретных примеров разработки в Системе при необходимости);

  • выездов сотрудников Интегратора для решения проблем и консультирования «на месте».



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




    1. Серверная и клиентская часть Системы должна корректно функционировать на платформах x86-64 под управлением операционной системы Microsoft Windows Server 2008 и Linux.

    2. Клиентская часть системы должна поддерживать работу в браузере IE 7 или выше.




  1. Требования к этапности и срокам реализации проекта

    1. Все работы по проекту должны быть завершены (Система передана в промышленную эксплуатацию) не позднее 01 ноября 2014 года, при условии начала работ 01.05.2014. В случае, если работы по факту будут начаты позже, срок окончания работ сдвигается на ту же величину.

    2. Все работы по интеграции с внешними системами и подключению справочных данных должны быть разделены на две очереди, в соответствии с таблицами «Перечень систем для интеграции», «Перечень справочных данных». Работы каждой очереди могут выполняться параллельно. Сроки выполнения каждой очереди:

  • 1 очередь – 01.07.2014 г.

  • 2 очередь – 01.11.2014 г.

    1. В рамках выполнения работ по данному ТЗ система ESB должна обеспечивать обмен данными между следующими системами:

Перечень систем для интеграции:

N

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

База данных

Размещение

Канал передачи данных

Очередь выполнения работ

1

Медицинская информационная система «Медиалог», версия 7.20, база КДЦ на Белорусской

SQL

Клинико-диагностический центр на Белорусской, Москва

10 мбит\сек

2

2

Медицинская информационная система «Медиалог», версия 7.20, база Американского медицинского центра

SQL

Американский медицинский центр, Москва

5 мбит\сек

2

3

Медицинская информационная система «Инфоклиника», центральная база московского региона

FireBird

Центр обработки данных, Москва

10 мбит\сек

2

4

Медицинская информационная система «Медиалог», версия 7.20, база Медси-2

SQL

Детская клиника на Пироговке, Москва

5 мбит\сек

2

5

Бухгалтерская информационная система 1С КОРП 8.2, база Медси-2

SQL

Детская клиника на Пироговке, Москва

5 мбит\сек

1

6

Бухгалтерская информационная система 1С КОРП 8.2, централизованная база московского региона

SQL

Центр обработки данных, Москва

10 мбит\сек

1

7

Консолидированная система поддержки продаж, далее КСПП, внедряемая в рамках отдельного проекта

-

Центр обработки данных, Москва

10 мбит\сек

2

8


Внедряемая в рамках данного ТЗ система MDM

-

Центр обработки данных, Москва

10 мбит\сек

1

9

Автоматизированная система управления денежными средствами, далее АСУ ДС, внедряемая в рамках отдельного проекта внедрения

-

Центр обработки данных, Москва


10 мбит\сек

1




    1. В рамках выполнения работ по данному ТЗ система MDM должна обеспечивать ведение эталонных справочников:

Перечень справочных данных



Наименование справочника

Размерность справочника

(кол-во элементов)

О выполнения работ

1

Справочник "Организации"



1

2

Справочник "Контрагенты"



1

3

Справочник "Договоры контрагентов"



1

4

Справочник "Банковские счета"



1

5

Справочник "Статьи ДДС"



1

6

Справочник "Приоритеты платежей"



1

7

Справочник "Статьи затрат"



1

8

Справочник "Подразделения организаций" (ЦФО)



1

9

Справочник "Номенклатурные группы"



2

10

Справочник "Номенклатура"



2

11

Справочник "Склады"



2

12

Справочник "Основные средства"



2

13

Справочник "Должности"



2

14

Справочник "Медицинские программы"



2

15

Справочник "Услуги"



2

16

Справочник "Клиника"



2

17

Справочник "Отделения"



2

18

Справочник "Сотрудники"



2

19

Справочник "Пациенты"



2

20

Справочник «Кассы»



1

21

Справочник «Проекты»



1

22

Справочник "Физические лица"



2

23

Справочник "Специализации"



2


  1. Обязательные требования к Интегратору (Исполнителю)




    1. Присутствие Интегратора на рынке не менее 5 лет;

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

    3. Успешный опыт проектов по внедрению интеграционных платформ и систем НСИ в организациях численностью не менее 5000 человек;

    4. Выделенные сотрудники со стороны Исполнителя:

  • руководитель проекта (на время проекта);

  • архитектор решения (на время проектирования решения);

    1. Финансовая гарантия качества работ (любой вариант из списка):

  • обеспечение сделки специальной гарантией банка из списка:

    • СБЕРБАНК РОССИИ;

    • ВНЕШТОРГБАНК;

    • ЮНИКРЕДИТ;

    • БАНК МОСКВЫ;

    • РАЙФФАЙЗЕНБАНК АВСТРИЯ;

    • МТС-БАНК (ранее МБРР);

    • ИНГ БАНК (ЕВРАЗИЯ);

  • предоплата не более 50% от общей суммы контракта.

    1. Допускается субподряд.




  1. Требования к составу заявки




    1. Комплект документов, подаваемый Исполнителем в качестве заявки потенциального Исполнителя (далее – Заявка) должен включать, как минимум следующие документы:

      1. Документы, подтверждающие соответствие потенциального Исполнителя требованиям, предъявляемым к потенциальным исполнителям, а именно:

        1. регистрационные документы;

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

      2. сведения о платежеспособности компании.

      3. Технико-коммерческое предложение потенциального Исполнителя (далее – ТКП), содержащее исчерпывающее описание технической и финансовой сторон решений, предлагаемых потенциальным Исполнителем в рамках Заявки. Как минимум, ТКП должно содержать следующие разделы:

      4. архитектуру решения;

      5. функциональные возможности решения;

      6. стоимость программного обеспечения;

      7. сроки поставки программного обеспечения;

      8. гарантийные обязательства производителей и гарантии потенциального Исполнителя на поставляемое оборудование.

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

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

    3. В случае установления факта представления потенциальным Исполнителем в рамках Заявки неполной или недостоверной информации данный потенциальный Исполнитель не допускается к участию в закупочных процедурах ЗАО «Группа компаний «Медси» в течение одного года с момента установления такого факта.

    4. Потенциальный исполнитель и его аффилированное лицо не имеют права одновременно участвовать в Запросе.

    5. Присутствие на рынке поставок ИТ оборудования и программного обеспечения не менее 5-ти лет.

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

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




  1. Требование к Коммерческому предложению




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

      1. стоимость решения:

        • лот №2 - закупка лицензий на программное обеспечение п.5 настоящего ТЗ;

        • лот №1 - закупка услуг по созданию и внедрению систем ESB, MDM в соответствии с функциональными требованиями п.2 настоящего ТЗ;

        • лот №1 – годовое гарантийное обслуживание информационных систем ESB, MDM;

      1. условия оплаты и поставки:

        • лот №2 - закупка лицензий на программное обеспечение п.5 настоящего ТЗ;

        • лот №1 - закупка услуг по созданию и внедрению систем ESB, MDM в соответствии с функциональными требованиями п.2 настоящего ТЗ;

      1. архитектура решения;

    1. Закупка может быть осуществлена по лотам №1 и №2 независимо.

    2. Коммерческое предложение должно соответствовать шаблонам приведенным в Приложении №1 к настоящему ТЗ.

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

    4. В случае установления факта представления потенциальным Исполнителем, в рамках Заявки, неполной или недостоверной информации, ЗАО «Группа компаний «Медси» имеет право не допускать данного потенциального Исполнителя к участию в закупочных процедурах в течение одного года с момента установления такого факта.


Термины, определения и сокращения:

Заказчик, Компания – ЗАО «ГК «Медси».

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

Система – информационная система или набор информационных систем, являющихся объектом внедрения в рамках текущего проекта.

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

МИС – медицинская информационная система.

ESB – (Enterprise Service Bus, сервисная шина предприятия) информационная система, предназначенная для интеграции гетерогенных программных комплексов в единое информационное пространство в том числе на принципах сервисно-ориентированной архитектуры.

MDM – (Master Data Management System, система управления нормативно-справочной информацией) информационная система, предназначенная для единого управления процессом создания, изменения, удаления справочных данных, общих для всех информационных систем предприятия.

HL7 – (Health Level 7) международный стандарт обмена, управления и интеграции электронной медицинской информации.

НСИ – нормативно-справочная информация, совокупность справочных данных предприятия.

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

Оператор НСИ – сотрудник Компании, участвующий в процессе изменения, добавления, удаления, нормализации справочных данных в качестве эксперта.

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

Услуга – медицинская услуга, имеющая конкретные параметры, в том числе длительность и стоимость.

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

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

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

Роль - тип пользователей системы, обладающих определенным набором прав доступа.

Приложение №1
к Техническому заданию на внедрение сервисной шины данных и системы НСИ в

ЗАО «Группа компаний «Медси»


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

Шаблон коммерческого предложения для Лота №1 по закупке услуг на создание и внедрение систем ESB, MDM:


  1. Срок действия предложения: <указать число месяцев, не меньше 3-х> мес.

  2. Опыт Интегратора по реализации аналогичных проектов.

  3. Детальное описание архитектуры предлагаемого решения.

  4. Допущения проекта.

  5. Календарный план работ (приведенные ниже работы являются обязательными, но список может быть дополнен Интегратором):



Наименование работ

Сроки реализации

(период)


Трудозатраты (чел/д)

Стоимость (руб)

Гарантийное обслуживание

Постгарантийное обслуживание







Период гарантийного обслуживания, в мес. (минимум 12 мес)

Удаленное облуживание (руб /чел/д)

Выездное обслуживание

Руб/(чел/д)



Удаленное облуживание (руб/чел/д)

Выездное обслуживание

(руб/чел/д)





Обследование



























Моделирование (создание модели данных для первой очереди, см. п.№8 ТЗ)



























Обучение администраторов MDM, ERP



























Подключение систем первой очереди



























Обучение операторов систем первой очереди, гарантийное обучение



























Запуск систем первой очереди в промышленную эксплуатацию, гарантийное обслуживание

- 01.07.2014
























Моделирование (создание модели данных для второй очереди, см. п.№8 ТЗ)



























Подключение систем второй очереди


























Обучение операторов систем второй очереди, гарантийное обучение



























Запуск систем второй очереди в промышленную эксплуатацию, гарантийное обслуживание

- 01.11.2014
























Итог, вкл. НДС, руб.



























НДС, руб.




























  1. Стоимость гарантийного обслуживания

Составляющая предложения

Ед. изм.

Стоимость единицы удаленного сопровождения, руб.

Стоимость единицы выездного сопровождения, руб.

Гарантийное обучение










Гарантийное обслуживание













  1. Условия оплаты.




  1. Существенные условия договора:

    1. санкции в случае превышении сроков: в случае превышения указанных в настоящем предложении сроков выполнения работ по вине Исполнителя Заказчик вправе потребовать от Исполнителя компенсации в размере 0,1% от стоимости предложения за каждый день просрочки;

    2. сведения об организациях, привлекающихся на субподряд.




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

Шаблон коммерческого предложения для Лота №2 по закупке лицензий на программное обеспечение:


  1. Срок действия предложения: <указать число месяцев, не меньше 3-х> мес.

  2. Срок поставки не позднее п. №2 Моделирование (создание модели данных для первой очереди) Лота№1 Приложение№1, или 01.06.2014.

  3. Состав:



Наименование лицензий

Цена (руб)

Количество (шт)

Стоимость (руб)

Вендорское сопровождение

Первый период, (если есть)

Последующие периоды

(период)

Сумма,

(руб)


Сумма,

(руб)




Название систем приведенных в требовании данного ТЗ, п. №5 «Требования к составу и количеству лицензий»





























































Итог, вкл. НДС, руб.





















НДС, руб.





















  1. Условия оплаты.




ЗАО «Группа компаний «Медси», 119071, Москва, Ленинский проспект, дом 20, корпус 1

Т.: +7 (495) 737 07 22, Ф.: +7 (495) 737 07 22 #141, info@medsigroup.ru, www.medsi.ru



ОКПО 97180256, ОГРН 5067746338732, ИНН 7710641442, КПП 771001001




izumzum.ru