<< Пред.           стр. 3 (из 6)           След. >>

Список литературы по разделу

  Учет взаимных расчетов (учет в разрезе контрагентов и оснований расчетов, формирование отчетов по дебеторско-кредиторской задолженности).
  Учет затрат (учет затрат в разрезе объектов, статей и т.д., формирование отчетов по фактическим затратам).
  Отчетность (формирование главной книги, кассовой книги, баланса и приложений к нему, и всей финансово-статистической отчетности для представления в налоговые органы; расчет и анализ итоговых финансово-экономических показателей).
 Анализ и отчетность
  Этот модуль предназначен для руководства страховой компании и ее экономических и аналитических служб. В нем сосредоточены разделы, предназначенные для подготовки информации оперативного и стратегического характера как основы для принятия управленческих решений. Основные возможности:
  Гибкие возможности настройки параметров расчета страховых резервов по каждому виду страхования.
  Расчет страховых резервов по видам страхования иным, чем страхование жизни.
  Расчет резервов по страхованию жизни нормативным методом.
  Автоматический расчет комиссионного вознаграждения страховым агентам по настраиваемому алгоритму и контроль за своевременностью выплат.
  Подготовка сводных и аналитических отчетов, необходимых для анализа страховой деятельности, оценки эффективности деятельности отделов и отдельных сотрудников.
  Подготовка форм ведомственного государственного статистического наблюдения за деятельностью страховых организаций.
 Администратор
  Модуль предназначен для настройки и администрирования Системы.
  Основные возможности:
  Настройка и подготовка к работе словарных регистров Системы.
  Регистрация пользователей Системы.
  Управление распределением прав доступа к информации пользователей Системы.
 Программное и аппаратное обеспечение
  Необходимое для работы Системы аппаратное обеспечение и системное программное обеспечение должны иметь следующий состав и отвечать указанным требованиям:
  Система реализована в двухуровневой архитектуре "клиент-сервер".
 
 СУБД Oracle7(tm) Операционная система сервера БД Windows NT(r), UNIX
 (либо любая другая операционная система, в которой поддерживается работа СУБД Oracle7(r)). Операционная система рабочей станции Windows(r) 95, Windows NT(r)
  На компьютерах рабочих мест должны быть установлены сетевые драйверы, соответствующие типу сети и программы сетевой поддержки. Все принтеры, входящие в состав рабочих мест, должны быть русифицированы.
  В качестве сервера БД могут быть использованы практически любые компьютеры на базе процессоров Intel и RISC. В следующей таблице приводятся минимальные технические требования к серверу БД.
 Процессор не ниже Pentium(r)133 Оперативная память не менее 48 Мб Дисковая память не менее 1 Гб
  В качестве рабочих станций используются компьютеры на базе процессоров Intel, которые должны иметь следующие параметры:
 Процессор не ниже Pentium(r)100 Оперативную память не менее 16 Мб Свободную дисковую память не менее 100 Мб
  Для подключения этих компьютеров к серверу должна быть оборудована локальная вычислительная сеть типа Ethernet(tm) или TokenRing(tm), поддерживающая протокол TCP/IP или/и IPX/SPX.
 Информационное обеспечение
  Информационное обеспечение пользователей Системы включает подробную документацию в нескольких книгах и справочную систему. Любые дополнительные сведения можно получить по бесплатной "горячей" справочной телефонной линии. При необходимости, пользователи Системы могут пройти обучение в учебном центре Корпорации или пригласить нашего специалиста к себе в компанию.
  Из всего богатства справочно-информационных возможностей чаще всего пользователь прибегает к услугам электронной справки, которая представлена структурированной справочной системой и системой оперативной подсказки.
  Система оперативной подсказки позволяет непосредственно при работе с Системой получить о любом элементе диалогового окна (поле, кнопке, столбце таблицы и т.д.) информацию, разъясняющую его назначение и использование.
  Структурированная (то есть снабженная оглавлением, глоссарием и поиском по ключевому слову) справочная система содержит подробные сведения о назначении каждого раздела, их взаимосвязи, принципах работы и управления Системой.
 
 ИНТЕГРИРОВАННЫЙ ПАКЕТ ИНЭК-СТРАХОВЩИК"21
  Основные преимущества "ИНЭК-Страховщик" по сравнению с аналогичными программными продуктами других фирм - разработчиков заключаются в следующем:
 * программный комплекс "ИНЭК-Страховщик" соответствует правилам нормативного регулирования бухгалтерского и страхового учета (заключение Института Профессиональных Бухгалтеров и Центра Исследований экономических систем ЦИЭС БиПрос. Рекомендован Министерством Финансов РФ к использованию в страховых организаций).
 * довольно низкая цена, несмотря на ряд значительных преимуществ комплекса;
 * специализация и комплексный подход к ведению страхового и бухгалтерского учета;
 * возможность осуществления анализа деятельности;
 * тесный контакт с пользователем (годовое сопровождение гарантирует любые консультации с пользователями по телефону непосредственно с разработчиками комплекса, все пожелания пользователя которые можно внести в стандартную поставку реализуются бесплатно)
 * постоянная связь данных по договорам страхования и бухгалтерских проводок по этим договорам;
 * гибкая настройка расчета резервов, учитывая тип договора;
 * возможность вести историю изменений договора, то есть получать данные за любой период в зависимости от состояния договора в этом периоде;
 * достаточно простой подход к регистрации договоров;
 * журнал учета договоров содержит все виды договоров страховщика с возможностью жесткой привязки договоров страхования с договорами перестрахования;
 * поставка комплекса осуществляется с максимально возможным количеством настроек (план счетов, стандартные финансовые операции, годовая, квартальная отчетность страховых организаций, расчет резервов,
 * формирование статистической отчетности) в соответствии с требованиями Департамента страхового надзора Министерства финансов РФ и действующим законодательством;
 * бухгалтерский блок прост и доступен к быстрому освоению;
 * ведение информации на субсчетах и счетах аналитического учета определенных на счете, позволяет получать достоверные отчеты;
 * мощный редактор форм обеспечивает формирование отчетов в любой форме с использованием графических рисунков, дополнительных функций, обеспечивающих вызов справочников;
 * при эксплуатации комплекса осуществляется контроль пользователя по вводу данных, необходимых для проведения расчетов и формирования отчетов.
 Структура комплекса
  Комплекс обеспечивает наиболее естественную технологическую цепочку операций, рассчитанную на квалифицированных специалистов страховых организаций, имеющих минимальные навыки как пользователи персонального компьютера.
  Программный комплекс состоит из двух основных блоков: блок бухгалтерского учета и блок страхового учета. Эти блоки функционируют на единой базе данных и взаимодействуют на программном уровне. То есть, по желанию пользователя может поставляться отдельно программа "ИНЭК-БУХГАЛТЕРИЯ СО" или программа "СТРАХОВЩИК".
 Блок страхового учета Программа "Страховщик"
  Назначение программы - ведение автоматизированного страхового учета в разрезе договоров всех видов страхования и перестрахования, включая непропорциональное, с любыми схемами оплаты.
  Программа обеспечивает (рис. 5):
  1) Учет договоров по следующим реквизитам:
 * номер договора;
 * виды страхования;
 * статус договора;
 * страхователи;
 * застрахованные;
 * объекты страхования;
 * агенты и брокеры;
 * контрагенты;
 * страховые риски;
 * тарифы;
 * дополнительные сведения;
 * реквизиты времени;
 * страховая сумма;
 * валюта договора;
 * порядок уплаты взносов;
 * платежи и убытки по договорам;
 * метод учета сумм договора (кассовый, начислений);
 * ведения о прекращении действия договора.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Рис. 5. Структура программы ИНЭК-БУХГАЛТЕРИЯ
 
  При этом осуществляется:
 * регистрация, редактирование и удаление договоров;
 * редактирование информации о договоре;
 * учет прямых договоров;
 * учет договоров с одним объектом страхования;
 * учет договоров с несколькими застрахованными и объектами;
 * учет принятых в перестрахование договоров;
 * учет переданных в перестрахование договоров;
 * копирование и тиражирование договоров;
 * подсчет значений показателей по выбранным договорам;
 * поиск договоров;
 * печать данных об убытках и платежах;
 * отбор договоров по заданным условиям;
 * изменение формы отображения журнала договоров;
 * просмотр истории изменения условий договоров;
 * печать информации по договорам;
 * графическое отображение плановых и фактических платежей;
 * графическое отображение убытков;
 * сообщения о запланированных убытках и платежах при запуске программного комплекса;
 * подсчет значений показателей по выбранным выплатам и платежам;
 * отбор выплат и платежей по заданным условиям.
  2) Расчет страховых резервов для видов страхования I, II, III учетной группы в соответствии с правилами формирования страховых резервов "Приказ Росстрахнадзора от 18 марта 1994 г. № 02-02/04 "Об утверждении Правил формирования страховых резервов по видам страхования иным, чем страхование жизни" с последующими изменениями и дополнениями.
  Страховые резервы представлены в следующих таблицах:
  Базовая страховая премия;
  Резерв незаработанной премии (в т.ч. для первой учетной группы рассчитанный двумя способами - "Pro Rata Temporis" или "24-ой");
  Резерв заявленных, но неурегулированных убытков;
  Резерв произошедших, но незаявленных убытков;
  резерв предупредительных мероприятий;
  резерв катастроф;
  резерв колебаний убыточности;
  доля перестраховщика в технических резервах.
  3) Расчет резерва по страхованию жизни для вида страхования учетной группы "жизнь" в соответствии с правилами формирования страховых резервов "Письмо Росстрахнадзора от 27 декабря 1994 г. № 09/2-16р/02", письмо от 5 апреля 1995 г. № 09/2-12р/02 с последующими изменениями и дополнениями.
  4) Формирование итоговых таблиц по страховым резервам в любой валюте на любую отчетную дату.
  Итоговые данные по резервам представляются в следующих таблицах:
 * общая величина страховых резервов (прямые и переданные в перестрахование договоры);
 * общая величина страховых резервов (полученные и переданные в ретроцессию договоры);
 * общая величина доли перестраховщика в технических резервах по договорам, переданным в перестрахование;
 * общая величина доли перестраховщика в технических резервах по договорам, переданным в ретроцессию.
  5) Расчет статистических данных в форме стандартных отчетов 1С в соответствии с приказом Росстрахнадзора от 30 января 1996 г. № 02-02/03 и 2С в соответствии с приказом Росстрахнадзора от 26 февраля 1996 г. № 20н с последующими изменениями и дополнениями.
  6) Анализ страховых резервов и статистических данных.
  Анализ обеспечивается двумя методами:
 * метод "Анализ динамики" - для просмотра значений нескольких показателей по одному виду страхования;
 * метод "Сравнение показателей по видам страхования" - для просмотра значения одного показателя по нескольким видам страхования.
  Результаты анализа представляются в табличном и графическом виде.
  По рассчитанным в результате анализа показателям формируются:
 * базисные темпы роста показателей;
 * базисные темпы прироста показателей;
 * цепные темпы роста показателей;
 * цепные темпы прироста показателей.
 1.4.ОБЩИЕ ПОЛОЖЕНИЯ АВТОМАТИЗАЦИИ РИСК-МЕНЕДЖМЕНТА В СТРАХОВЫХ КОМПАНИЯХ
  Основным требованием, предъявляемым к системе управления крупными рисками в страховых компаниях, является его проблемно ориентированная направленность, т.е. данный программный комплекс должен быть ориентирован на решение задач оценки, прогнозирования, мониторинга крупного риска на всем этапе работы страховой компании с ним. Вместе с тем он должен быть тесно интегрирован в существующие информационные системы страховой компании. Такое требование предопределяет необходимость четкого ограничения круга задач, решаемых в рамках данной проблемы с помощью разрабатываемой информационной системы.
  Можно выделить два основных подхода к проектированию информационных системы коммерческого предприятия, а в частном случае и страховой компании.
  Первый подход основан на использовании организационной структуры предприятия, когда проектирование системы идет по структурным подразделениям. Технологии деятельности в этом случае описываются через технологии структурных подразделений, а взаимодействие структурных подразделений - через модель верхнего уровня. Если компания представляет собой сложную структуру типа холдинг или предприятие -сеть, то необходимо также иметь модель взаимодействия всех входящих в него элементов, в котором будут отражены не только технологические моменты, но также финансовые и юридические.
  Второй подход, так называемый "процессорный подход", ориентирован не на организационную структуру, а на бизнес-процессы. Информационные системы основанные на данном подходе более перспективны, так как бизнес-процессы, в отличии от организационной структуры меняются значительно реже.
 КЛАССИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
  Первый подход к проектированию информационных систем предполагает использование так называемого "классического проектирования, которое в свою очередь использует "каскадное схему" организации работ. Состоящую из следующих этапов:
 * "запуск": организация основания для деятельности и запуск работ: приказ и/или договор о разработке автоматизированной системы, задание на выполнение работ (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). Эта схема обязана была включать итерационные процедуры уточнения требований к системе и рассмотрения вариантов проектных решений. Все же эти процедуры и целые этапы работ носили, в основном, последовательный характер, а, кроме того, предметом была проектируемая ИС целиком, в целостном ее представлении.
  Данная схема имеет свои положительные и отрицательные стороны применения. Положительные стороны применения:
 * на каждой стадии формировался законченный, отвечающий критериям полноты и согласованности набор проектной, а затем и пользовательской документации, охватывающий все предусмотренные стандартами виды обеспечения ИС: организационное, методическое, информационное, программное, аппаратное и др.,
 * выполняемые в логичной последовательности этапы работ достаточно очевидным образом позволяли планировать сроки завершения всех работ и соответствующие затраты.
  Структура ИС, как она формируется в ходе разработки, могла быть представлена такой схемой:
 СТАДИИ ПРОЕКТА Организационное Методическое Информационное Программное Аппаратное Запуск +- Обследование +- +- +- Концепция ТЗ +- +- +- Эскизный проект +- +- +- +- ТП + ++ + +- +- РП ++ ++ ++ ++ + Ввод в действие ++ ++ ++ ++ ++
  Символами "+", "+-" и "++" показаны примерные оценки доли наличия каждого компонента на каждой стадии
 
  Эти стадии работ стали также называть частями "проектного цикла" системы. Такое название возникло потому, что в этапы включалось много итерационных процедур уточнения требований к системе и вариантов проектных решений. Жизненный цикл самой системы - существенно сложнее и больше. Он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходило и развитие ИС, и модернизация ее компонентов.
  Отрицательные факторы применения описанной схемы проектирования также аблюдались постоянно, были описаны в литературе и хорошо известны практикам.
  Чаще всего в качестве основного недостатка называлось существенное запаздывание с получением результатов, которое имело несколько аспектов:
 * согласование результатов с пользователем производилось только в точках, планируемых после завершения каждого этапа работ; это приводило к тому, что разработчики делали не ту информационную систему, которую хотел Заказчик или тем более пользователи, а ту, которую представили себе проектировщики-аналитики, затем - программисты,
 * модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, для мало-мальски крупного проекта ИС устаревали (т.е. переставали отвечать реальным внешним требованиям) вскоре после их утверждения, а иногда и одновременно с ним; это относится и к функциональной модели, и к информационной, и к проектам интерфейса пользователя, и к инструкциям персоналу,
 * попытки довести до внедрения проект, выполняющийся в такой манере, заставляли или искажать требования к ИС, или превышать сроки и смету разработки, или делать и то, и другое.
  В [19] об этом сказано так: "В конце 1960-х гг. появилась идея о создании полностью интегрированной базы данных (БД) организации. Она оказалась практически недостижимой". Правда, Дж. Мартин указывал в качестве причины практического краха идеи сложность и размер задачи. Мы будем далее анализировать еще одну, самую актуальную причину - динамику изменений в требованиях к базе данных и информационной системе в целом. Показательно, что в настоящее время эта идея продолжает жить до сих пор.
  Существовал и явным образом описывался в литературе еще один крупный недостаток разрабатываемых информационных систем, относящийся, скорее, к практике разработки информационных систем, чем к теории. И в зарубежной, и в отечественной литературе практики и ведущие аналитики оценивали проектирование информационной системы как очень часто ведущее к примитивной автоматизации (по сути - "механизации") существующих производственных действий работников. См. об этом также в [19]: "Анализ должен подвести руководство к вопросу о том, как надо изменить организацию..." и далее: "... легче идти по проторенной дорожке документирования сложившегося бумажного потока, чем определять насущные потребности бизнеса". В отечественной практике возник афоризм, описывающий эффект работы типичной АСУ, механически перемалывающей существующий бумажный поток: "Что на входе, то и на выходе". Ниже мы укажем, что современные аналитики до сих пор указывают на существование этого эффекта.
  Как альтернатива такому подходу требовалось получение с помощью информационной системы качественно новых результатов, позволяющих осуществлять оптимальное управление производством в целом, динамически менять управление производственными процессами на предприятии, принимать лучшие управленческие решения, встраивать контроль качества и рациональное управление внутрь производственных процессов, использовать их самими производственными коллективами.
  Такой подход рекомендовалось осуществлять всегда, но он встречал скрытое и явное сопротивление работников на предприятиях. Это было и является в настоящее время проблемой во всех странах. Такой подход полностью отвечал бы определениям кибернетики по Н. Винеру, но был очень редко достижим.
  Вместе с тем, в прошлом десятилетии большинству проектировщиков информационных систем казалось, что имеющиеся модельные и организационные методы проектирования, а также поддерживающие их программные средства составляют законченную дисциплину, которая может совершенствоваться, но уже позволяет в общем успешно планировать и осуществлять разработки больших информационных систем.
  Для планирования формально целостной ИС рекомендовалось на стадии обследования вначале определять укрупненные функции системы, затем - детализировать их. По мере реализации фрагментов информационных систем предполагалось использовать детальные описания функций соответствующего фрагмента.
  Такая организация проектирования названа проектированием "сверху вниз". Упоминаемая функциональная иерархия - очень важный признак рассматриваемых подходов. Из-за определяющего влияния на процессы и результаты проектирования ИС иерархических структур для представления функций и данных в ИС применявшиеся подходы получили общее условное название "структурное проектирование". Привычность и доступность иерархических моделей были привлекательным фактором. В [16], основываясь на результатах сравнительных исследований, опубликованных к тому времени, и на собственных наблюдениях авторов формулировали: "... в подавляющем числе случаев пользователю естественней и проще представлять модели предметной области в иерархическом виде, а не в виде сетевых структур, что, очевидно, объясняется его постоянными контактами с иерархическими зависимостями реального мира". Однако жесткость иерархических структур ограничивает их пользу, и чем дальше, тем менее эти ограничения допустимы.
  Не только жесткость моделей, но и использование фирменных ("патентованных") архитектур используемых компьютеров, Операционных Систем (ОС) и Систем Управления Базами Данных (СУБД) приводила к отрицательным результатам при возникновении неизбежной необходимости развития информационных систем (ИС). Эти недостатки получили оценку как недостатки закрытых систем: закрытые ИС было трудно или очень дорого развивать, очень дорого или практически невозможно стыковать с другими системами.
  Одно из популярных в то время представлений архитектуры такой закрытой ИС показано на рис. 6, где:
 * компьютер конкретного типа (конкретной фирмы-производителя),
 * конкретная операционная система для данного типа компьютера,
 * СУБД для 1 и 2,
 * прикладные программы для 2 и 3: пакетные/диалоговые для фиксированных функций или языки нерегламентированных запросов,
 * пользователь-оператор, обученный именно для 2, 3 и 4
 * конечный пользователь: обучен и снабжен инструкциями для работы именно с 4 и 5.
  Потенциальная возможность и необходимость применения оргмероприятий для построения ИС (или АСУ), меняющих оргструктуры повышения эффективности работы предприятия в отечественных условиях, практически не использовалась. Для каждого предприятия, его отделения или отдела существовали т.н. типовые оргштатные структуры, расписания и положения. Для того, чтобы произвести изменение в этой области чаще всего нужно было решение соответствующего министерства. Поэтому в большинстве случаев оргструктура оставалась неизменной, а информационная система повторяла те функции, которые ранее выполнялись вручную.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Рис. 6. Модель-луковица закрытой ИС
  Прежде, чем перейти к характеристикам методов, соответствующих тем или иным стадиям классического системного проектирования, опишем наблюдавшуюся ранее ситуацию с организацией совершенствования управления производством, которая, по большому счету, всегда должна была быть целью проектирования ИС.
  Вместе с тем подходы к совершенствованию собственно процессов управления производством развивались параллельно и почти независимо от информационных технологий. Часто в них информационные системы и автоматизация вообще рассматривались в последнюю очередь.
 Классические методы проектирования ИС
  Конец 70-х - начало 80-х гг. - это время становления технологии интегрированных баз данных (БД) как одной из головных технологий в проектировании ИС. Был разработан и вошел в практику большой набор теоретически обоснованных методов: проектирование концептуальных и логических схем БД, организация физической среды хранения данных, планирование путей доступа к данным и др. Развивались методы проектирования функций: от методов формальной спецификации функций до структурного программирования и первых непроцедурных языков программирования четвертого поколения (4GL). Анализ функций (задач) предприятия также служил основой и в проектировании БД. Появились CASE-системы, ориентированные на формализацию информационных и функциональных требований к ИС и предназначенные для формального описания и бригадной разработки больших программных комплексов. Эти методы и инструменты, которые в идеале должны были бы соединяться с методами преобразований управления производством, составляли классическую Мастерскую ИТ. Правда, соединение этих методов в целостные технологии производилось эмпирически и не всегда.
  В конце 70-х - середине 80-х гг. и в нашей стране большое количество разработчиков успешно применяли методы разработки ИС и БД не только на интуитивно-ремесленном уровне, но и как элементы сложившейся дисциплины. Укажем на наиболее популярные из них, применявшиеся на первых стадиях проектирования.
  1. Обследование, общий анализ ситуации на предприятии и разработка общего обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning):
 * общий системный и ситуационный анализ текущего состояния и целей предприятия, его масштабов, возможности, стоимости и способов разработки ИС, решающей задачи, способствующие достижению целей предприятия, использование методов [19], структурного анализа [25], ГОСТов на разработку АСУ и САПР,
  2. "Концепция, ТЗ": исследования требований предприятия и пользователей, выработка вариантов и рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам (strategy stady, analysis, requirement specification),
 * анализ критических факторов успеха и риска с использованием системного и ситуационного анализа,
 * обследование предприятия методами анализа документов, интервью, прямых наблюдений, хронометража и др. (большое количество методик: от SADT Д. Росса до ГОСТа по предпроектным исследованиям при разработке САПР),
 * определение соответствия существующей оргструктуры, функций, документов и др. целям предприятия,
 * проектирование более целесообразных и учитывающих создаваемую ИС оргструктуры, набора и иерархии функций ("задач"), видов документов и правил документооборота,
 * вычленение предметных БД, определение взаимосвязей между ними,
 * разработка предложений по изменениям на предприятии, затрагивающим оргструктуру, документооборот и др.,
 * построение недетализированных моделей БД и функций ИС (с использованием диаграмм данных Ч. Бахмана, модификаций ER-модели П. Чена, функциональных моделей по стандартам IDEF0, по методике HIPO или др.),
 * сбор и описание детальных требований к составу данных и алгоритмам реализации функций (см., например, популярную [10], а также [32], [30], также требования серий ГОСТ24 и ГОСТ36),
  3. "Эскизный проект": разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level design),
 * построение нормализованной реляционной или сетевой модели БД (методы получения нормальных форм Бойса-Кодда, четвертых и пятых нормальных форм, использование предложений комитета CODASYL),
 * определение принципов организации в ИС интерфейсов конечного пользователя (принципы эргономики, как, впрочем, и влияние компьютерной моды, переход от командного интерфейса к диалоговым режимам "вопрос-ответ", "управление через меню"),
 * определение модульной иерархии (верхние уровни) программного обеспечения ИС (модульное программирование, метод HIPO),
 * определение принципов организации аппаратного компьютерного комплекса, на базе которого должна функционировать ИС (расчеты физических параметров ИС: объемов БД, временных характеристик отдельных операций доступа к данным, целых функций и режимов в целом, организации компьютерных сетей, см. также [30]),
 * определение основных оргмероприятий по созданию и вводу в действие ИС,
 * определение совокупности требований к приемке будущей ИС,
 * определение сроков, состава работ и их стоимости для последующих работ по ИС.
  Существовал набор методов, которые применялись и на других этапах.
  Все эти методы остались в арсенале разработчиков и в настоящее время. Однако они и соответствующие инструменты начинают совсем по иному применяться в условиях проектирования бизнес процессов (BPR) и открытой архитектуры ИС. Кроме того, теперь они сочетаются с новыми методами, позволяющими достичь большей гибкости и процесса разработки, и самой ИС, причем за меньшее время. В отношении собственно классических методов изменения, в первую очередь, касаются качества их компьютерной поддержки, т.е. применения новых ИТ для поддержки классических методов.
  Некоторые из усовершенствований в компьютерной поддержке проектирования ИС начиная со второй половины 80-х гг.:
 * широкое применение графических диалоговых интерфейсов (диаграммы структур данных, иерархий функций, потоков данных и др.),
 * использование компьютерных сетей и работа с распределенными базами данных для поддержки кооперативной групповой разработки (использование общих словарей-справочников данных, теперь - "репозитариев"),
 * постепенное расширение использования понятийных моделей и методов объектного моделирования.
  Конечно, новые ИТ заставили включать в классические методики соответствующие новые функции. Как пример, это относится к средствам динамического моделирования архитектур клиент-сервер и систем с распределенными базами данных. Однако включение отдельных новых функций не меняло подхода в целом и не устраняло описанных выше недостатков.
  Тем не менее и несмотря на то, что у большинства отечественных разработчиков возможности использовать, например, распределенные БД отсутствовали из-за плохих линий связи и низкой надежности компьютеров, изменения в ИТ происходили во всем мире, влияли на методы проектирования и стандарты и проникали в отечественные разработки.
 Открытая архитектура
  В 80-х гг. произошел целый ряд качественных изменений в информационных технологиях. Некоторые из них осознавались постепенно (например, развитие архитектуры и стандартов открытых систем), другие, как феномен персональных вычислений, входили в жизнь гораздо более революционным путем. Кратко рассмотрим, как эти изменения все более ограничивали применение классических методов системного проектирования, требуя новых подходов в разработке чисто "компьютерных" компонентов ИС. Далее, будет рассмотрено, как эти изменения помогали также появлению бизнес-реинжиниринга (BPR).
  Понятие открытой архитектуры начало проникать в практику вместе со стандартами на аппаратуру и программным обеспечением компьютерных сетей и переносимым (мобильным) программным обеспечением СУБД и ОС.
  Оно предполагало строгое соответствие формата передаваемых по сети сообщений стандарту протокола обмена, наличие нескольких стандартных уровней обмена сообщениями со стандартами протоколов для каждого уровня. Такая открытость позволяла свободно заменять аппаратуру и программы обмена протоколов нижних уровней, если заменяющие аппаратура и программы соблюдали стандарты более высоких уровней, с которыми должны были работать СУБД или прикладные программы.
  Понятие переносимости прикладных программ относилось к возможности использовать один и тот же прикладной комплекс на разных компьютерах. Переносимость базировалась первоначально на наличии компилятора с одного языка высокого уровня на разных типах компьютеров: Фортран, затем - Си, Паскаль, при использовании варианта языка, соответствующего стандарту. Затем, с первой половины 80-х гг., предполагалось также наличие тождественных для пользователя и его прикладных программ СУБД на нескольких типах компьютеров. Пионерами в этой области были СУБД ORACLE и INGRES. Одновременно стал решаться вопрос переносимости баз данных.
  В понятие открытой архитектуры стал вкладываться более широкий смысл. Укажем лишь на интероперабельность: открытость системы, позволяющая встраивать ее как компонент в сложную разнородную распределенную информационную среду. Это свойство позволило более эффективно формировать ИС предприятия на основе готовых "покупных" приложений разных поставщиков.
  Это показывает, что понятие открытых систем нельзя трактовать упрощенно. Так, кроме указанных выше свойств, в открытость систем входит соответствие стандартам (в том числе - стандартам "де факто") и открытость в областях: масштабируемость, расширяемость, интернационализация, переносимость пользователя. Достаточно полную информацию по разным аспектам этого вопроса можно получить в журналах "Открытые системы" (1993 г.) и "СУБД" (с 1995 г.).
  Наконец, к концу 80-х - началу 90-х во всем мире не только разработчиками, но и пользователями были осознаны три действительно революционных феномена. Они стали все шире входить в отечественную практику, качественно меняя деятельность компьютеризованных предприятий:
  1. Феномен персональных вычислений, основанный на постоянной доступности работнику возможностей ЭВМ, в первую очередь - на использовании персональных компьютеров. Феномен состоит в том, что во многих видах информационных, проектных и управленческих работ исчезла необходимость в работниках-исполнителях (машинистках, чертежниках, делопроизводителях и др.), являющихся посредниками между постановкой задачи и ее решением.
  2. Феномен кооперативных технологий, состоящий в компьютерной поддержке совместной согласованной работы группы работников над одним проектом. Этот феномен возник на основе суммы методов, обеспечивающих управление доступом членов группы к разным частям проекта, управление версиями и редакциями проектной документации и согласованным выполнением работ в последовательной процедуре работ, управление параллельным конструированием и др.
  3. Феномен компьютерных коммуникаций, состоящий в резком увеличении возможностей обмена любой информацией. Он возник, в частности, на основе стандартизованных протоколов обмена данными прикладного уровня в локальных и глобальных сетях. Это позволило исключить необходимость передачи бумажных документов для получения согласия или содержательных замечаний, ненужные переезды для проведения совещаний, обеспечить постоянную готовность работника получить и отослать сообщение или информативные записи данных вне зависимости от места его географического расположения и др.
  Оценка их влияния на производственную деятельность и оргструктуры, разработка соответствующих методик производились не только за рубежом, но и отечественными специалистами, хотя тогда у нас время реального применения этих методов еще не настало.
  Открытые архитектуры стимулируют использование готовых покупных компонентов ИС разных разработчиков. Современный подход к проектированию информационных систем: "Не разрабатывать, а покупать". Необходимость строить ИС на основе набора "покупных" приложений разных поставщиков, причем набора, состав которого надо уметь изменить в нужное время, привела к практической невозможности использовать классические структурные технологии проектирования интегрированных систем. Например, замена программного комплекса бухгалтерской или складской подсистемы на более развитый, но других разработчиков, приводит к тому, что меняется структура БД и набор действий с данными. Даже если "по большому счету" в новом приложении будут выполняться те же функции, но, например, быстрее и в более удачной компоновке, а информация хранится "всего лишь" в виде более детальных сведений и т.п., то информационные и функциональные модели могут отличаться друг от друга практически во всех деталях! Из-за этого старые способы построения интегрированных моделей стали отказывать все чаще и чаще.
  В силу этого проектирование ИС из покупных компонентов на формальном уровне может оказаться близким к хаотичной "самодеятельной" разработке полностью несогласованных программ для решения частных задач предприятия, то есть к т.н. "позадачному подходу", с попытками последующего соединения таких задач в целостную систему.
  С другой стороны, постепенно осуществлялись попытки преодолеть разрыв между формальными требованиями к проектированию целостных больших ИС с интегрированными базами данных и реальной динамикой жизни, требующей постоянной смены то одного, то другого программного комплекса. (Часто такие попытки помещались критиками в одну графу с "позадачным подходом" и отвергались.) Постепенно и практикам, и теоретикам, и рискованным новаторам, и критикам-консерваторам становилось ясно, что обе крайности неприменимы: ни вульгарный позадачный подход, ни попытки разработки полностью законченных больших ИС с заранее полностью спроектированной интегрированной базой данных.
  Эти и другие предпосылки (см., например, [15]) являлись основанием того, что единственным достаточно стабильным интегрирующим элементом современной ИС может являться не информационная, и тем более не функциональная модель предприятия, а только понятийная модель предметной области, да и то при условии ее постоянного пересмотра и обновления. Пассивные понятийные модели такого прикладного рода строились и представлялись в виде терминологических словарей и тезаурусов понятий. Такие словари строились как часть обеспечения ИС и содержали описания элементов информационных, функциональных, организационных и других моделей для ИС. Однако практически все использование таких моделей для проектирования и развития ИС приходилось и приходится делать вручную.
  Активные понятийные модели разрабатывались не только для хранения описаний используемых понятий и связей между ними. Ставились цели динамически формировать новые суждения, определять тождество или сходство понятий, производить их интерпретацию вычислительного характера. К таким моделям относятся разные представления семантических сетей, некоторые специальные понятийные модели, например, [9]. Однако создание технологически полных механизмов такого рода оказалось очень сложной задачей. Для непосредственного использования в промышленных разработках ИС активные понятийные модели до последнего времени были непригодны.
  В настоящее время слияние средств представления знаний с технологией обобщенных объектов и стандартизацией в области объектно-ориентированных представлений реально ведет на следующий, качественно новый уровень в технологии системного проектирования. В качестве одного из примеров укажем на систему СИНТЕЗ, см. [17].
  Описанные выше, а также некоторые другие Новые Информационные Технологии дали возможности принципиально пересмотреть технику как собственно проектирования ИС, так и управления процессами проектирования. Но влияние этих новых технологий оказалось более широким.
 БИЗНЕС-РЕИНЖИНИРИНГ
  Проникновение описанных изменений в среду производственных коллективов меняло принципы управления на таких предприятиях. Менялись и возможности индивидуальных потребителей, их требования к рынкам товаров и услуг. Сумма таких - и ряда иных, экономических - изменений привела к качественным переменам в организации управления на предприятиях, включая принципы т.н. BPR - "business process reengineering" или реконструкции бизнес-процессов.
  Однако и BPR не является последней точкой или исчерпывающим подходом в вопросах управления. Общий бизнес-реинжиниринг, строительство киберкорпораций (термин, часто употребляемый Дж. Мартином), в том числе - виртуальных, постоянное использование принципов CPI Э. Деминга, социопсихологическое экспертирование и обязательный учет "человеческого фактора" - вот другие понятия, также формирующие подходы к новому системному проектированию.
  Появление качественных изменений в ИТ, включая три описанных "великих феномена" ИТ, само по себе стало сильно менять внутреннее устройство производственных коллективов, в первую очередь - специалистов компьютерных фирм, разработчиков ИС, поскольку они оказались на переднем крае использования всех информационных новаций. Эти новации касались и отечественных разработчиков, в недостаточной степени, но все же использовавших терминалы хост-машин, а затем персональные компьютеры для организации своей собственной деятельности.
  В 80-х гг. были исследованы и описаны соответствующие эффекты в области организации компьютеризованных подразделений и изменений в их функционировании и управлении. В работе [27] рассматривалась работа т.н. малых формальных компьютеризованных групп, изменение в их организации и др. особенности. Рост динамики изменений и рисков демонстрировался на показателях эволюции макросреды таких групп, приведенных на рис. 7.