Контрольная работа: Бизнес-инжиниринг страховой компании

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

.        Точилкина Т.Е. Моделирование архитектуры предприятия с Archi // Экономика и менеджмент инновационных технологий. 2014. № 11 [Электронный ресурс]. URL: #"881660.files/image015.jpg">

Рисунок 15.

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

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

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

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

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

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

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

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

-   администратор системы;

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

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

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

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

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

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

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

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

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

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

-   Время работы системы - круглосуточно

-   Время обработки заявки - до 30 минут

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

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

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

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

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

-   минимизацию производимых пользователем операций

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

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

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

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

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

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

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