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

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

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

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

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

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

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

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

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

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

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

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