Компания «СтрахТраст» является страховой компанией. В сферу деятельности компании входит - коммерческое страхование. На данный момент “СтрахТраст” испытывает проблемы, связанные с обслуживанием клиентов. Ожидание клиентов в офисах Компании превысило все допустимые нормы. Основная причина данной проблемы связанна с тем, что Менеджеры компании теряют 35% своего рабочего времени на заведении (добавление) заявок от новых клиентов, что повлекло за собой снижение дохода компании на 13%. В настоящий момент, менеджеры компании вместо звонков потенциальным клиентам и прочей деятельности, связанной с привлечением новых клиентов, вынуждены тратить больше времени при работе с заявками клиентов и заведением их данных в программу.

Руководство компании решило воспользоваться услугами компании по внедрению ИТ-сервисов и консалтинга - «ККБ» для решения проблем связанных с долгим ожиданием клиентов и неэффективным использованием времени менеджеров.

Компетенция компании “ККБ” включает решения в следующих областях: планирование и совершенствование деятельности предприятия, в том числе управление финансами, логистика (управление цепочкой поставок, снабжением, сбытом, складом), управление производством, управление персоналом, обслуживание и ремонт производственных мощностей, управление отношениями с клиентами, управление проектными работами; а также управление ИТ и системная интеграция.

Цель данной работы:

Бизнес-инжиниринг страховой компании «СтрахТраст»

Задачи:

Создание плана проекта по бизнес-инжинирингу
Формулирование образа будущей компании
Подготовка модели «AS IS» компании
Создание комплексной модели нового бизнеса компании (TOBE)
Анализ выполнения проекта

1.План проекта по бизнес-инжинирингу

1.1 Распределение ресурсов и ролей участников проекта

После выбора темы проекта, которой является бизнес-инжиниринг страховой компании «СтрахТраст» инициативной группой, которая занимается разработкой проекта инжиниринга страховой компании, был выбран руководитель группы разработки – Костюченко А.А., бизнес-аналитиками стали Климов Н.И. и Боровков Д.Ю.(рисунок 1, лист ресурсов проекта)

Рисунок 1- Лист ресурсов.

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

Руководитель Костюченко А.А. – общая работа по проекту, разработка планирования, разработка бизнес-процессов, создание отчетов.

Бизнес-аналитик Климов Н.И. – описание текущего состояния компании, создание моделей бизнес-процессов как в текстовом варианте, так и с помощью специализированных программ, проведение анализов бизнес решений.

Бизнес-аналитик Боровков Д.Ю. – описание бизнес-процессов компании, анализ бизнес-процессов, разработка новых бизнес-процессов и формулирование требований к ИС, и ее анализ.

Рисунок 2 – распределение обязанностей

1.2 Планирование календаря

Руководителем Костюченко А.А. был запланирован календарь с детальным распределением задач и времени соответствующему на их реализацию в рамках данного проекта(рисунок3).

Рабочее время на проект с 19-00 до 24-00, ежедневно.

Рисунок 3 – планирование проекта

1.3Планирование бюджета

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

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

Рисунок 4 – Запланированный бюджет

2. Образ будущей компании

2.1. Формировании миссии и стратегии

Миссия

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

Компания работает так, чтобы обеспечить лучшее будущее для частных и корпоративных клиентов, сотрудников, партнеров, акционеров. Успех компании неотделим от их успеха.

Стратегия

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

На рисунке 5 представлено дерево целей страховой компании.

Рисунок 5 – Дерево целей

2.2 Описание внешней и внутренней среды

Cильные стороны компании:

1. Страховая компания «СтрахТраст» признана одной из крупнейших универсальных российских страховщиков.

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

3. Многолетний успешный опыт работы, а также сформированный имидж.

4. Высокий уровень доверия населения.

5. Устойчивое финансовое положение.

6. Взаимовыгодные партнерские отношения с крупнейшими российскими финансовыми институтами.

Слабые стороны:

1. Высокие издержки.

2. Высокая загруженность

Возможностями компании являются:

1. Возможность стать абсолютным лидером российского рынка страховых услуг.

2.Динамичное развитие в будущем.

3. Дальнейшее создание филиальной сети «СтрахТраст».

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

5.Увеличение количества клиентов.

6. Расширение предоставляемых услуг.

Компания подвержена следующим угрозам:

1. Появление на рынке большого количества конкурентов.

2. Более быстрый рост выплат, по сравнению с ростом собираемых страховых премий.

3. Нестабильное финансовое положение клиентов (физических и юридических лиц).

4. Экономическая и политическая нестабильность в стране.

5. Допуск на российский страховой рынок иностранных компаний.

На рисунке 6 изображена внешняя среда компании.

Рисунок 6 – внеш=няя среда компании

2.4 Определение результатов деятельности компании

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

3. Модель «ASIS» компании

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

Организационная структура страховой компании представлена на рисунке 7.

Рисунок 7 - Организационная структура компании

Как видно из рисунка 7 на вершине организационной структуры находится генеральный директор. Ниже заместитель директора, ему подчиняются следующие отделы: хозяйственный отдел, коммерческий директор, юридический отдел. В хозяйственный отдел входит заведующий хозяйством и системный администратор. К юридическому отделу относится руководитель отдела, которому подчиняются юристы.

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

3.2 Описание функциональной структуры

Функциональная структура компании «СтрахТраст» представлена на рисунке 8.

Рисунок 8 - Функциональная структура компании

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

3.3 Карта бизнес-процессов

Карта бизнес-процессов представлена на рисунке 9.

Рисунок 9 - Карта бизнес процессов

Карта бизнес-процессов состоит из основных бизнес-процессов, вспомогательных бизнес-процессов, обслуживающих бизнес-процессов и управленческих бизнес-процессов.

В компании «СтрахТраст» к основным процессам относятся продажа страховых полисов и расширение клиентской базы.

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

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

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

3.4 Описание бизнес-процесса страхования клиента

Рисунок 10 – Основной бизнес-процесс

Описание бизнес-процесса

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

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

3.5 Описание информационной системы компании

3.5.1 Назначение системы

Главным объектом в системе, которые необходимо автоматизировать, является модуль страхования клиентов компании. Данная система необходима для автоматизации процесса продажа страховых продуктов клиентам.

3.5.2 Описание системы

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

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

3.5.3 Описание модулей системы

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

Данная информационная система состоит из следующих модулей:

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

3.6 Разработка предложений по бизнес-инжинирингу компании (TOBE)

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

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

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

4. Комплексная модель нового бизнеса компании

4.1 Первый вариант инжиниринга компании

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

Организационная структура компании не изменялась

4.1.2 Описание функциональной структуры

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

4.1.3 Карта бизнес-процессов

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

4.1.4 Описание бизнес-процесса страхования клиента

Рисунок 11 Основной бизнес-процесс

Описание бизнес-процесса

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

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

4.2 Второй вариант инжиниринга компании

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

Рисунок 12 Организационная структура

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

4.2.2 Описание функциональной структуры

Рисунок 13 Функциональная структура

В функциональную структуру были внесены следующие изменения, вследствие внедрения нового отдела верификации, ему были выданы следующие функции: обработка заявок и вынесение решения по заявке.

4.2.3 Карта бизнес-процессов

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

4.2.4 Описание бизнес-процесса страхования клиента

Рисунок 14 Основной бизнес-процесс

Описание бизнес-процесса

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

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

4.3. Анализ вариантов бизнес-инжиниринга

4.3.1 Определение критериев для оценки вариантов инжиниринга

Основными критериями при оценке варианта инжиниринга являются:

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

-стоимость внедрения

-время, необходимое для внедрения

Критерий	1ый вариант	2ой вариант
Освобождение времени у менеджеров	При внедрении данного варианта клиентопоток в офисах снизится и начнет переходить на удаленные каналы обслуживания, что позволит освободить необходимое для менеджеров время	При внедрении данного варианта клиентопоток в офисах останется, при этом загруженность менеджеров при обработке заявок на страховку немного снизится.
Стоимость внедрения	Стоимость данного решения, составляет порядка 300000 рублей.	Стоимость данного решения составляет 150000рублей, однако также возрастут издержки на зарплату сотрудникам нового отдела.
Время внедрения	Составляет от 2недель до 2 месяцев	Время внедрения – месяц.

4.3.2 Оценка и выбор вариантов инжиниринга

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

При внедрении первого варианта время работы менеджеров непосредственно с заведением новых заявок снизилось на 45%, количество ошибок при заведении новых заявок уменьшилось на 70%, в день было заведено 35% новых заявок через удаленные каналы обслуживания.

При внедрении второго варианта время работы менеджеров с заведением новых заявок было снижено на 20%, количество ошибок при заведении заявок снизилось на 40%.

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

4.4 Требования к ИС поддержки выбранного варианта инжиниринга

Объектом автоматизации является процесс оформления страховых продуктов. В данный момент в страховой компании работает автоматизированная информационная система от компании 1С. Для нее будет необходимо разработать или найти готовое решение CRM, совместимую с продукцией от компании 1С, которая в настоящее время автоматизирует все основные процессы в компании, а также обладающей возможностью бесперебойно работать и экономно использовать аппаратные ресурсы.

4.4.1 Цели, задачи создания АС

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

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

4.4.2 Выводы и предложения

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

Заключение

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

Список использованных источников

1.ГОСТ 34.601-90 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

2.ГОСТ 34.602-89 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

3.ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.

4.Точилкина Т.Е. Моделирование архитектуры предприятия с Archi // Экономика и менеджмент инновационных технологий. 2014. № 11 [Электронный ресурс]. URL: http://ekonomika.snauka.ru/2014/11/6308

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

6.http://www..com / Википедия – свободная энциклопедия

Приложение 1 Техническое задание на модернизацию Автоматизированную систему

Приложение №1 к Договору № 777

от «17» декабря 2015 г.

УТВЕРЖДАЮ		УТВЕРЖДАЮ

Генеральный директор		Генеральный директор
ООО «СтрахТраст»		ООО «ККБ»

_________ /Иванов И.И./		_________Костюченко А.А./

«____» _________ 20__ г.		«____» _________ 20__ г.

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

на модернизацию

информационной системы компании

г. Москва

Содержание

1. Общие сведения 29

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

1.2. Заказчик 29

1.3. Исполнитель 29

1.4. Сроки создания системы 29

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

1.6. Порядок оформления и предъявления Заказчику результатов 29

2. Назначение и цель создания системы 31

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

2.2. Цель модернизации системы 31

3. Характеристика объекта автоматизации 32

3.1. Общие сведения 32

3.2. Описание процесса продажи страховых продуктов 32

4. Требования к системе 34

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

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

4.1.2. Требования к численности и квалификации персонала 34

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

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

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

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

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

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

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

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

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

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

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

4.3.1. Требования к информационному обеспечению 38

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

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

4.3.4. Требования к техническому обеспечению 40

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

5.1. Состав выполняемых работ 41

5.2. Этапы и сроки выполнения работ 43

6. Порядок контроля и приемки системы 44

6.1. Виды, состав, объем и методы испытаний системы 44

6.2. Общие требования к приемке работ 44

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

7.1. Общие требования к разрабатываемой документации 46

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

1. Общие сведения

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

Информационная система страховой компании.

1.2. Заказчик

ООО «СтрахТраст»

1.3. Исполнитель

ООО «ККБ»

1.4. Сроки создания системы

Срок выполнения работ по созданию системы – 1 месяц с момента заключения Договора.

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

Работы по созданию системы финансируются из собственных средств ООО «СтрахТраст» в соответствии с договором на модернизацию информационной системы страховой компании (далее - Договор).

Порядок финансирования работ определяется Договором.

1.6. Порядок оформления и предъявления Заказчику результатов

Требования к составу и оформлению результатов работ определены разделами 5 и 7 настоящего ТЗ.

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

При передаче Заказчику программ для ЭВМ и баз данных, созданных и/или модернизированных при выполнении работ, в виде исполняемого или объектного кода Исполнитель должен передать Заказчику исходные тексты всех передаваемых программ и баз данных на электронном носителе.

Документация передается на бумажных (два экземпляра) и на машинных носителях (CD|DVD).

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

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

Система предназначена для автоматизации информационного взаимодействия подразделений Заказчика при выполнении основных бизнес-процессов.

2.2. Цель модернизации системы

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

3. Характеристика объекта автоматизации

3.1. Общие сведения

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

На начало работ у заказчика присутствует развитая информационная система, и требуется внедрение в текущую ИС CRM системы с глубокой интеграцией.

3.2. Описание процесса продажи страховых продуктов

Графическая модель процесса представлена на рисунке 15.

Рисунок 15.

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

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

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

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

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

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

Подсистема автоматизации приема и обработки заявок

4.1.2. Требования к численности и квалификации персонала

В состав персонала, необходимого для эксплуатации системы входят:

администратор системы;
администратор базы данных.

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

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

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

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

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

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

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

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

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

Время работы системы – круглосуточно
Время обработки заявки – до 30 минут

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

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

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

Интерфейс должен быть рассчитан на использование как персональных рабочих станций, так и переносных компьютеров (ноутбуков) с рабочим разрешением экрана не ниже 1024x768. Управление системы должно осуществляться с помощью набора экранных меню, кнопок, значков и прочих графических элементов. Клавиатурный режим ввода должен использоваться при заполнении и/или редактировании текстовых и числовых полей экранных форм.

Интерфейс системы должен быть направлен на:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3.1. Требования к информационному обеспечению

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

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

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

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

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

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

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

Общее программное обеспечение (ОПО) должно состоять из следующих компонентов:

серверные операционная (ые) система (ы);
СУБД;
прикладные программы;
телекоммуникационные программы;
программы защиты от несанкционированного доступа;
антивирусные средства;
программные средства мониторинга системы.

На серверах должны использоваться многозадачные операционные системы.

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

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

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

Минимальная конфигурация серверов баз данных:

Количество серверов баз данных – 2;
Процессор: не менее 4 ядер (64-х разрядная платформа);
ОЗУ: не менее 8 Гб;
Количество жестких дисков - от 2-4 шт. (общим объемом не менее 4 Тб).

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

5.1. Состав выполняемых работ

№ п.п.	Стадияразработки	Состав работ	Результаты / Отчетные материалы	Срок
1.	Разработка программного обеспечения	Разработка программного обеспечения в полном объеме	Программное обеспечение на машинном носителе; ведомость машинных носителей информации.	Не более 1 недели с даты начала работ.
2.	Разработка эксплуатационной документации	Разработка комплекта эксплуатационной документации	Комплект эксплуатационной документации согласно разделу 7 данного ТЗ.	Не более 1 недели с даты окончания п.1
3.	Развертывание системы на объекте внедрения	Установка и настройка всех компонентов системы на объекте внедрения.	Акт выполнения пуско-наладочных работ системы	Не более 3 дней с даты окончания п.3
4.	Подготовка персонала	Подготовка методических материалов для подготовки персонала по категориям на основе эксплуатационной документации; разработка План-программы подготовки персонала по категориям; проведение подготовки персонала.	План-программа подготовки персонала; отчёт о проведении подготовки персонала.	Не более 3 дней с момента окончания п.4
5.	Предварительные испытания	Разработка программы и методики предварительных испытаний. проведение предварительных испытаний; разработка программы опытной эксплуатации.	Программа и методика предварительных испытаний; протокол проведения предварительных испытаний. проект акта приемки системы в опытную эксплуатацию;	Не более 1 недели с даты окончания п.5
6.	Опытная эксплуатация	Проведение опытной эксплуатации в соответствии с утвержденной программой	Программа опытной эксплуатации; журнал опытной эксплуатации; отчет о проведении опытной эксплуатации.	Не более 3 дней с момента окончания п.6
7.	Приемочные испытания	Разработка программы и методики приемочных испытаний. Проведение приемочных испытаний.	Программа и методика приемочных испытаний; протокол проведения приемочных испытаний; проект акта приемки в промышленную эксплуатацию.	Не более 1 недели с момента окончания п.7

5.2. Этапы и сроки выполнения работ

Работы по настоящему ТЗ выполняются в один этап в срок не более 2ух месяцев с даты подписания Договора.

6. Порядок контроля и приемки системы

6.1. Виды, состав, объем и методы испытаний системы

Испытания должны быть организованы и проведены в соответствии с ГОСТ 34.603 «Информационная технология. Виды испытаний автоматизированных систем».

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

предварительные испытания;
опытная эксплуатация (ОЭ);
приемочные испытания.

Отдельные виды испытаний проводятся в сроки, установленные календарным планом выполнения работ.

Объем и методы предварительных и приемочных испытаний определяются документом «Программа и методика испытаний» для соответствующего вида испытаний.

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

6.2. Общие требования к приемке работ

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

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

В состав комиссии включаются представители организаций Заказчика, и Исполнителя, а также (по необходимости) специалисты, привлекаемые Заказчиком.

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

Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии системы предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, данных комиссией в ходе испытаний. Результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» и рассматриваются в ходе приемочных испытаний.

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

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

7.1. Общие требования к разрабатываемой документации

Техническая и эксплуатационная документация на систему (далее – документы на систему) должна быть разработана в составе, указанном в разделе 7.2, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы:

ГОСТ 34.003-90, ГОСТ 19.004-80-82 – в части терминологии;
ГОСТ 34.201-89, ГОСТ 19.101-77-82 в части наименования и обозначения документов;
ГОСТ 34.601-90, ГОСТ 19.102-77-82 в части определения стадий и этапов работ;
ГОСТ 34.603 -92 – в части определения видов испытаний;
РД 50-34.698-90, ГОСТ 19.105-78 – в части структуры и содержания документов.

Документы на систему оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания.

Если в состав документации включаются материалы, требующие больших форматов (схемы, чертежи, фотоматериалы и пр.), то по согласованию с Заказчиком допускается выполнение приложений к таким документам только на машинных носителях в форматах Adobe PDF, TIFF, JPEG и др. При этом основная часть документа выпускается в соответствии с требованиями, определенными выше.

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

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

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

определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации системы;
провести опытную эксплуатацию системы.

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

От Заказчика		От Исполнителя
ООО «СтрахТраст»		ООО «ККБ»

Бизнес-инжиниринг страховой компании

Информация о работе

Помогла работа? Поделись ссылкой

Есть ненужная работа?

Информация о документе

Можно ли скачать документ с работой

3. Модель «ASIS» компании

3.6 Разработка предложений по бизнес-инжинирингу компании (TOBE)

Приложение 1 Техническое задание на модернизацию Автоматизированную систему

Предыдущий документ

Похожие документы

Следующий документ