Анализ страховых резервов и статистических данных.

Анализ обеспечивается двумя методами:

v метод “Анализ динамики” – для просмотра значений нескольких показателей по одному виду страхования;

v метод “Сравнение показателей по видам страхования” – для просмотра значения одного показателя по нескольким видам страхования.

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

По рассчитанным в результате анализа показателям формируются:

v базисные темпы роста показателей;

v базисные темпы прироста показателей;

v цепные темпы роста показателей;

v цепные темпы прироста показателей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СТАДИИ ПРОЕКТА	Организационное	Методическое	Информационное	Программное	Аппаратное
Запуск	+-
Обследование	+-	+-	+-
Концепция ТЗ	+-	+-	+-
Эскизный проект	+-	+-	+-	+-
ТП	+	++	+	+-	+-
РП	++	++	++	++	+
Ввод в действие	++	++	++	++	++

 

Символами " +", " +-" и " ++" показаны примерные оценки доли наличия каждого компонента на каждой стадии

 

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

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

Чаще всего в качестве основного недостатка называлось существенное запаздывание с получением результатов, которое имело несколько аспектов:

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

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

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

В [19] об этом сказано так: " В конце 1960-х гг. появилась идея о создании полностью интегрированной базы данных (БД) организации. Она оказалась практически недостижимой". Правда, Дж. Мартин указывал в качестве причины практического краха идеи сложность и размер задачи. Мы будем далее анализировать еще одну, самую актуальную причину – динамику изменений в требованиях к базе данных и информационной системе в целом. Показательно, что в настоящее время эта идея продолжает жить до сих пор.

Существовал и явным образом описывался в литературе еще один крупный недостаток разрабатываемых информационных систем, относящийся, скорее, к практике разработки информационных систем, чем к теории. И в зарубежной, и в отечественной литературе практики и ведущие аналитики оценивали проектирование информационной системы как очень часто ведущее к примитивной автоматизации (по сути – " механизации" ) существующих производственных действий работников. См. об этом также в [19]: " Анализ должен подвести руководство к вопросу о том, как надо изменить организацию..." и далее: "... легче идти по проторенной дорожке документирования сложившегося бумажного потока, чем определять насущные потребности бизнеса". В отечественной практике возник афоризм, описывающий эффект работы типичной АСУ, механически перемалывающей существующий бумажный поток: " Что на входе, то и на выходе". Ниже мы укажем, что современные аналитики до сих пор указывают на существование этого эффекта.

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

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

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

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

Такая организация проектирования названа проектированием " сверху вниз". Упоминаемая функциональная иерархия – очень важный признак рассматриваемых подходов. Из-за определяющего влияния на процессы и результаты проектирования ИС иерархических структур для представления функций и данных в ИС применявшиеся подходы получили общее условное название " структурное проектирование". Привычность и доступность иерархических моделей были привлекательным фактором. В [16], основываясь на результатах сравнительных исследований, опубликованных к тому времени, и на собственных наблюдениях авторов формулировали: "... в подавляющем числе случаев пользователю естественней и проще представлять модели предметной области в иерархическом виде, а не в виде сетевых структур, что, очевидно, объясняется его постоянными контактами с иерархическими зависимостями реального мира". Однако жесткость иерархических структур ограничивает их пользу, и чем дальше, тем менее эти ограничения допустимы.

Не только жесткость моделей, но и использование фирменных (" патентованных" ) архитектур используемых компьютеров, Операционных Систем (ОС) и Систем Управления Базами Данных (СУБД) приводила к отрицательным результатам при возникновении неизбежной необходимости развития информационных систем (ИС). Эти недостатки получили оценку как недостатки закрытых систем: закрытые ИС было трудно или очень дорого развивать, очень дорого или практически невозможно стыковать с другими системами.

Одно из популярных в то время представлений архитектуры такой закрытой ИС показано на рис. 6, где:

v компьютер конкретного типа (конкретной фирмы-производителя),

v конкретная операционная система для данного типа компьютера,

v СУБД для 1 и 2,

v прикладные программы для 2 и 3: пакетные/диалоговые для фиксированных функций или языки нерегламентированных запросов,

v пользователь-оператор, обученный именно для 2, 3 и 4

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

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

 

 

Рис. 6. Модель-луковица закрытой ИС

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

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

⇐ Предыдущая45678910111213Следующая ⇒

Поделиться: