Проектирование базы данных страховой компании ОАО «Согаз-Мед. Методологии моделирования предметной области

канд. физ.-мат. наук,
доцент кафедры «Программное обеспечение и интеллектуальные системы»,
Донецкий государственный институт искусственного интеллекта

Ручкина В.Н .,
аспирант Донецкого национального университета

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

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

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

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

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

Классическая методология структурного анализа и проектирования SADT («Structured Analysis& Design Technique») позволяет описать деятельность компании с функционально-структурной точки зрения. Диаграммы, построенные с помощью этого подхода, отражают систему бизнес-процессов компании как набор функций, процедур и задач, выполняемых в компании, и описывают принципы использования потоков данных. Такие диаграммы просты для понимания специалистами различных уровней управления компании.

Методология объектно-ориентированного анализа и проектирования с помощью унифицированного языка моделирования UML («Unified Modeling Language») позволяет отразить динамику процессов компании.

Следующим шагом на этом этапе является выбор средств и систем моделирования бизнеса. Системы CASE («Computer-Assisted Software Engineering» ) наиболее подходят для этого. Выбор CASE зависит от выбранной методологии моделирования. Технология классического структурного моделирования полностью реализуется с помощью системы BPWin, входящей в комплекс программ Computer Associates AllFusion Modeling 4.1. В системе BPWin создаются модели процессов следующих стандартов (нотаций): IDEF0, DFD и IDEF3.

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

Созданные с применением BPWin диаграммы позволяют точнее сформулировать постановку задачи и наметить этапы ее решения.

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

Учет договоров страхования включает следующие процессы:

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

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

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

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

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

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

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

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

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

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

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

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

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

Первый шаг на этапе программирования предусматривает выбор и проектирование модели хранения данных. ERWin, входящий в набор Computer Associates AllFusion Modeling 4.1, позволяет спроектировать выбранную модель данных с использованием диаграмм DFD.

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

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

Основные этапы внедрения предусматривают установку и наладку компьютерной информационной системы. Далее происходит уточнение первичных документов и форм отчетов. Адаптация системы предполагает доведение ее от уровня As Is до уровня To Be, вплоть до корректировки самих бизнес-процессов.

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

Рассмотрим подробнее работу экспертного блока. Этот блок представляет собой экспертную систему (ЭС) способную решать основные задачи компании, такие, как:
- оперативность принятия решения по выбору продукта страхования для клиента по заданным условиям страхования;
- возможность проведение андеррайтенговой политики в режиме on-line для структурных подразделений компании, которые удалены от головного офиса компании;
- анализ и прогнозирование тарифной политики по видам страхования, страховым продуктам компании;
- анализ деятельности компании на отчетную дату по заданным классификационным параметрам (например, поступления платежей по продающим подразделениям компании, по видам страхования, по страховым продуктам; оперативная информация по заявленным убыткам по компании, по видам страхования, по страховым продуктам; оперативная информация по фактическим выплатам; информация о техническом результате деятельности компании на любую дату).
Экспертная система оперирует как со знаниями, выработанными в области страхования, так и данными, накапливаемыми страховой компании. Программа решает поставленные задачи посредством логического вывода, имея доступ к системе фактов, и выводит заключения из информации, имеющейся в базе знаний. База знаний (БЗ) состоит из трех частей:

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

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

3. Система пользовательского интерфейса. Может помочь пользователям при работе с ЭС, даже если они не знают, как она организована; объясняет пользователю, как получить результат.

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

Также по этой теме.

Одна картинка стоит тысячи слов

Народная мудрость

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

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

Несколько слов о преимуществах графики

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

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

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

Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERP-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену - это и правда очень сложно.

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

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

Почему это важно для моей работы

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

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

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

Типичные ошибки

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

Использование различных цветов

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

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

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

Слишком большое количество блоков

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

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

Нарушение структуры при внесении корректировок

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

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

Правила названия управляющих элементов и блоков

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

Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

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

В чем трудность применения IDEF0

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

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

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

Еще статьи по данной теме.

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

хорошую работу на сайт">

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

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

Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".

курсовая работа , добавлен 03.05.2014


Создание сети подпроцессов. Определение цели процесса. Описание процесса верхнего уровня в методологии IDЕF0. Описание детальных процессов в методологии DFD. Управление проектированием с помощью методологии IDЕF3. Управление корректирующими действиями.

контрольная работа , добавлен 05.06.2016


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

курсовая работа , добавлен 13.02.2012


Понятие бенчмаркинга, его виды, этапы разработки в страховой компании и роль в управлении. Финансово-экономический анализ доходов и расходов страховой компании. Характеристика страховой компании. Управление в "АльфаСтраховании" посредством бенчмаркинга.

курсовая работа , добавлен 14.04.2014


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

дипломная работа , добавлен 28.04.2011


Управление кадрами в страховой компании. Характеристика страховой компании ЗАО СК "АСКО-Центр" и совершенствование менеджмента человеческих ресурсов. Расчет экономической эффективности при увеличении количества рабочих мест и подготовки кадров фирмы.

дипломная работа , добавлен 02.03.2008


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

контрольная работа , добавлен 15.09.2014


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

дипломная работа , добавлен 22.12.2010