Общие положения автоматизации риск-менеджмента в страховых компаниях

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

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

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

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

Классическое проектирование

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

"запуск": организация основания для деятельности и запуск работ: приказ и/или договор о разработке автоматизированной системы, задание на выполнение работ (proposal for the development, agreement, mobilization);

"обследование": предпроектное обследование, общий анализ ситуации на предприятии, разработка общего обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning, requirement definition);

"концепция, ТЗ": исследования требований предприятия и пользователей, выработка рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам (strategy planning, analysis, requirement specification, function description);

"эскизный проект": разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level design);

опытный вариант ИС: разработка упрощенного варианта, пилотного проекта будущей ИС (pilot-project, test development);

опытное использование пилот-проекта ИС, разработка исправлений и дополнений к ТЗ (test, corrected requirement specification);

"ТП": разработка технического проекта ИС (detailed analysis and design, test development);

"РП": разработка рабочей документации проекта (development, test, system implementation);

"ввод в действие": по другому – "внедрение" ИС (deployment, put into operation).

Одно из использовавшихся в западной литературе названий такой схемы организации работ: "водопадная модель" (waterfall model). Эта схема обязана была включать итерационные процедуры уточнения требований к системе и рассмотрения вариантов проектных решений. Все же эти процедуры и целые этапы работ носили, в основном, последовательный характер, а, кроме того, предметом была проектируемая ИС целиком, в целостном ее представлении.

Данная схема имеет свои положительные и отрицательные стороны применения. Положительные стороны применения:

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