От переработки данных - к анализу
Жесткая денежная политика правительства и Банка России, снижение инфляционных сверхприбылей и спекулятивных доходов лишают коммерческие банки возможности практически без риска делать “легкие” деньги и приводят к обострению конкуренции. Чтобы устоять в новых условиях, банкиры должны принимать максимально взвешенные решения и определять оптимальную финансовую стратегию. Эффективное управление такой сложной системой, как банк, сегодня немыслимо без применения передовых информационных технологий - систем поддержки принятия решений (СППР).
В самом общем виде процесс управления можно свести к решению трех задач: где мы находимся? куда мы хотим прийти? как мы туда попадем?
Управлять сложными системами приходится, как правило, в условиях неполной информации, незнания закономерностей функционирования и постоянного изменения внешних факторов. Поэтому процесс управления имеет итерационный характер: после принятия решения и применения управляющего воздействия необходимо снова оценить состояние, в котором находится система, и определить, правильно ли мы движемся по намеченному пути. Если результат нас не удовлетворяет, то необходимо переопределить процесс управления.
Поддержка принятия решений - стратегия развития информационных систем
Современные информационные технологии при поиске ответов на поставленные вопросы позволяют аналитику формулировать и решать следующие классы задач:
- Аналитические - вычисление заданных показателей и статистических характеристик бизнес-деятельности на основе ретроспективной информации из баз данных.
- Визуализация данных - наглядное графическое и табличное представление имеющейся информации.
- Добыча знаний (data mining) - определение взаимосвязей и взаимозависимостей бизнес-процессов на основе существующей информации. К данному классу можно отнести задачи проверки статистических гипотез, кластеризации, нахождения ассоциаций и временных шаблонов. Например, путем анализа экономических и финансовых показателей деятельности компаний, которые впоследствии обанкротились, банк может выявить некоторые стереотипы, которые можно будет учесть при оценке степени риска кредитования.
- Имитационные -- проведение на ЭВМ экспериментов с математическими моделями, описывающими поведение сложных систем в течение заданного или формируемого интервала времени. Задачи этого класса применяются для анализа возможных последствий принятия того или иного решения (анализ "Что, если?..").
- Синтез управления - определение допустимых управляющих воздействий, обеспечивающих достижение заданной цели. Задачи этого типа применяются для оценки достижимости намеченных целей, определения множества возможных управляющих воздействий, приводящих к заданной цели.
- Оптимизационные - основаны на интеграции имитационных, управленческих, оптимизационных и статистических методов моделирования и прогнозирования. Задачи данного класса позволяют выбрать на множестве возможных управлений те из них, которые обеспечивают наиболее эффективное (с точки зрения определенного критерия) продвижение к поставленной цели.
Вряд ли стоит надеяться, что когда-либо будет создано комплексное программное обеспечение (ПО) СППР, которое будет реализовывать все или хотя бы большую часть алгоритмов, применяемых при решении перечисленных классов задач. Не стоит также полагать, что в ближайшие годы могут появиться на рынке программного обеспечения универсальные имитационные модели функционирования коммерческого банка, которые можно бы было адаптировать и использовать в СППР конкретного банка. Однако весьма вероятно, что ряд банков, чтобы добиться преимущества в конкурентной борьбе, сделает ставку на разработку собственных имитационных моделей. Исходя из личного опыта участия в создании моделей сложных систем, могу утверждать, что даже при наличии квалифицированной команды из бизнес-аналитиков, математиков и программистов срок реализации подобного проекта составит не менее полутора-двух лет. До тех пор о реальном использовании информационных технологий при решении задач пятого и шестого классов говорить, на мой взгляд, преждевременно, поскольку существующие в этих областях алгоритмы подразумевают наличие адекватной модели управляемой системы.
В настоящее время в банковских СППР следует рассчитывать лишь на использование комплексного ПО, реализующего алгоритмы решения задач первого, второго и частично третьего из перечисленных классов. Сегодня мы являемся свидетелями стремительного прогресса в создании подобного ПО под общим названием OLAP (On-line Analytical Processing). Более ста крупнейших производителей программ включились в конкуренцию на данном секторе рынка.
Архитектура современных СППР и требования к OLAP-системам
Ни одна из фирм - разработчиков OLAP не поставляет законченное решение для СППР, это ПО следует рассматривать лишь в качестве инструментального средства разработки таких систем. Поэтому прежде чем будет приобретено ПО класса OLAP, должны быть выполнены работы по проектированию перспективной СППР, сформулированы требования, предъявляемые к OLAP-системам, и проведена оценка предлагаемого ПО с учетом выработанных требований.
В соответствии с современными воззрениями OLAP-система должна базироваться на специальной базе данных -- хранилище данных (Data Warehouse), которая надстраивается над существующими транзактными АБС, обслуживающими повседневную деятельность. Хранилище данных аккумулирует информацию, которая поступает из АБС и из внешних источников (данные о клиентах, о конкурентах, политические, социологические, демографические и пр.). В зависимости от задачи хранилище данных может быть реализовано как на основе многомерной базы, так и на основе реляционной. Однако принципиальная позиция автора состоит в том, что важнейшим показателем OLAP-системы служит время отклика, которое должно быть настолько мало, чтобы не успевали размыкаться ассоциативные связи, возникающие у аналитика в ходе осмысления проблемы. Поэтому если хранилище данных реализуется на основе реляционной базы, то между ней и OLAP-системой все равно должен располагаться специализированный сервер многомерных баз данных.
Рис. 1. Архитектура перспективной системы поддержки принятия решений
Дополнение информации в хранилище осуществляется периодически, по завершении некоторого бизнес-цикла (рабочего дня, недели, месяца). Следовательно, промежуточным звеном между хранилищем данных и АБС должна являться оперативная база данных (Operational Data Storage), которая служит буфером для накопления и очистки ретроспективных данных в промежутках между добавлениями информации в хранилище.
Если в середине 1990-х гг. наиболее продвинутые информационные системы базировались на традиционной архитектуре клиент-сервер, то сегодня ведущей технологией построения приложений представляется расширение стратегий клиент-сервер до уровня Web в сетях Интернет/интранет. В первую очередь это обусловлено стремительным совершенствованием Интернет-технологий и постоянным снижением стоимости высокопроизводительных серверов. С другой стороны, традиционные клиенты становятся все более “толстыми” и требуют все большей мощности аппаратно-программного обеспечения и затрат на обслуживание. По оценкам зарубежных специалистов (Удо Флор, BYTE, сентябрь 1997 г.) в перспективных информационных системах 80% информационных потребностей корпорации будут удовлетворяться при помощи Web-приложений и лишь 20% наиболее “изощренных” пользователей будут продолжать использовать “толстых” клиентов. Важным доводом перехода к Web-технологиям является кроссплатформенность приложений, создаваемых для Интернета.
В реальной СППР может отсутствовать оперативная база. Многомерная база также может отсутствовать, в этом случае данные для анализа будут находиться в реляционном хранилище (ROLAP). С другой стороны, само хранилище данных может быть реализовано на основе многомерной базы.
Как уже отмечалось, в настоящее время на рынке ПО предлагается большое число OLAP-систем. Arbor Software, IBM, Informix, Microsoft, Oracle, SAS Institute, Sybase - это лишь небольшой перечень в алфавитном порядке ведущих производителей ПО OLAP. Безусловно, окончательный выбор производителя OLAP-системы остается за разработчиком СППР. Естественно, что выбираемое ПО в первую очередь должно удовлетворять традиционным требованиям к OLAP-системам, однако хотелось бы привести некоторые соображения, которые, на взгляд автора, целесообразно учесть при анализе предлагаемых продуктов:
Система OLAP должна основываться на сервере многомерных баз данных (MOLAP). Существующие решения на основе реляционных баз ( ROLAP) в ближайшее время не смогут удовлетворять требованиям разработчиков по важнейшей характеристике - скорости обработки заранее не регламентированных запросов данных.
ПО OLAP - в первую очередь средство создания СППР, поэтому оно должно включать в себя мощные инструменты администрирования и разработки OLAP-приложений - как сервисной логики, так и клиентских.
ПО должно содержать развитые средства импорта данных из разнообразных источников, в первую очередь из банковской транзактной АБС и предполагаемых внешних источников информации.
ПО должно позволять разрабатывать системы, которые были бы легко масштабируемы и модифицируемы применительно к постоянно изменяющимся масштабам, условиям и задачам предпринимательской деятельности.
Должна обеспечиваться поддержка Web-технологий как наиболее перспективных и дешевых средств построения информационных систем.
Разработка СППР носит итерационный характер и требует постоянных доработок и усовершенствований, как в связи с изменением характера и условий бизнеса, так и с уточнением используемых моделей и алгоритмов. Поэтому, приобретая ПО, ориентируйтесь на поддержку производителя - это обеспечит Вам уверенность в завтрашнем дне.
Системы поддержки принятия решений на базе Oracle Express OLAP
В качестве примера рассмотрим возможность реализации СППР на базе семейства программных продуктов Oracle Express OLAP. Покажем, каким образом здесь удовлетворяются перечисленные выше требования.
Рис. 2. Семейство программных продуктов Oracle Express OLAP
Семейство базируется на сервере многомерных объектно-ориентированных баз данных Oracle Express Server, который может быть установлен на большинстве платформ, в том числе Microsoft Windows NT, Digital Unix, OSF/1, HP-UX, IBM AIX, SunOS4, Sun Solaris, AT&T Svr4 (NCR), DEC Ultrix, DEC VAX/VMS, IBM MVS, NEC UX/4800, Sequent DYNIX/PTX, Siemens-Nixdorf SINIX, SGI IRIX, Tandem IRIX и др.
Express Server имеет встроенный язык манипулирования и обработки многомерных данных Express Language (4GL), который обеспечивает построение серверной логики любой сложности - от простых статистических вычислений до имитационных моделей.
Personal Express - функционально полный вариант сервера многомерных баз, портированный на ПК. Он совместим с Express Server по объектам, хранимым в БД, что обеспечивает масштабируемость разрабатываемых систем от ПК до мейнфреймов.
Windows-приложения Express Administrator и Relational Access Administrator служат средством разработки, создания и сопровождения многомерных БД. Они поддерживают технологию графического переноса ( drag & drop) для автоматической генерации подпрограмм импорта данных из реляционных БД Oracle и ODBC-источников, файлов MS Excel и текстовых файлов. Приложение Express Spreadsheet Add-In позволяет использовать электронные таблицы MS Excel версии 7.0 и выше в качестве среды разработки “клиентских” OLAP-приложений.
Express Objects - профессиональная инструментальная среда для визуальной объектно-ориентированной разработки OLAP-приложений для архитектуры клиент-сервер под MS Windows. Express Objects поддерживает необходимые объектные механизмы: инкапсуляцию, наследование и полиморфизм.
Использование Web-технологий в Oracle Express делает привлекательным применение данного ПО при разработке СППР (в настоящее время данная технология поддерживается далеко не всеми OLAP-производителями). Применение Web-технологий обеспечивает также простое решение проблемы интеграции различных платформ в информационных системах. В настоящее время практически для всех платформ Web-браузеры распространяются условно бесплатно. Oracle WebServer является стандартным Интернет-сервером, поддерживает протокол HTTP и обеспечивает доступ к базам данных. В стандартную поставку Oracle Express включены Java-аплеты, представляющие данные в графическом виде, и автоматический генератор VRML-сценариев, отображающих трехмерную графику компании Silicon Graphics.
Рис. 3. Пример динамической HTML-страницы, с интерактивным Java-аплетом и VRML-графикой
Подводя итог, можно сделать следующие выводы:
Одним из главных направлений развития банковских информационных систем на ближайшие годы должна стать разработка систем поддержки принятия управленческих решений на основе хранилищ данных. Главной архитектурной особенностью таких систем будет применение Web-технологий в сетях Интернет/интранет. Современные СППР должны строиться на базе OLAP-технологий.
При выборе производителя ПО OLAP целесообразно концентрировать свое внимание на задачах, которые должна решать ваша СППР, а не на достоинствах той или иной OLAP-системы. Совершенного ПО не бывает, поэтому не стоит слишком долго размышлять над выбором. Приобретите ПО, которое удовлетворяет вашим потребностям, и употребите сэкономленное время на разработку своей СППР.
Источник - С.Архипенков - От переработки данных - к анализу, Банковские технологии, №3, 1998.