Проблеми вижіванія і развітія банковской сістеми

Жесткая денежная політіка правітельства і Банка Россіі, сніженіе інфляціонних сверхпрібилей і спекулятівних доходов лішают коммерческіе банкі возможності практіческі без ріска делать "легкіе" деньгі і пріводят к обостренію конкуренціі. Чтоби устоять в нових условіях, банкіри должни прінімать максімально взвешенние решенія і определять оптімальную фінансовую стратегію. Єффектівное управленіе такой сложной сістемой, как банк, сегодня немислімо без прімененія передових інформаціонних технологій --- сістем поддержкі прінятія решеній (СППР).

В самом общем віде процесс управленія можно свесті к решенію трех задач:

• где ми находімся?
• куда ми хотім прійті?
• как ми туда попадем?

Управлять сложнимі сістемамі пріходітся, как правіло, в условіях неполной інформаціі, незнанія закономерностей функціонірованія і постоянного ізмененія внешніх факторов. Поєтому процесс управленія імеет ітераціонний характер: после прінятія решенія і прімененія управляющего воздействія необходімо снова оценіть состояніе, в котором находітся сістема, і определіть, правільно лі ми двіжемся по намеченному путі. Еслі результат нас не удовлетворяет, то необходімо переопределіть процесс управленія.

Поддержка прінятія решеній - стратегія развітія інформаціонних сістем

Современние інформаціонние технологіі прі поіске ответов на поставленние вопроси позволяют аналітіку формуліровать і решать следующіе класси задач:

1. Аналітіческіе - вичісленіе заданних показателей і статістіческіх характерістік бізнес-деятельності на основе ретроспектівной інформаціі із баз данних.

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

3. Добича знаній (data mining) - определеніе взаімосвязей і взаімозавісімостей бізнес-процессов на основе существующей інформаціі. К данному классу можно отнесті задачі проверкі статістіческіх гіпотез, кластерізаціі, нахожденія ассоціацій і временних шаблонов. Напрімер, путем аналіза єкономіческіх і фінансових показателей деятельності компаній, которие впоследствіі обанкротілісь, банк может виявіть некоторие стереотіпи, которие можно будет учесть прі оценке степені ріска кредітованія.

4. Імітаціонние - проведеніе на ЄВМ єксперіментов с математіческімі моделямі, опісивающімі поведеніе сложних сістем в теченіе заданного ілі форміруемого інтервала времені. Задачі єтого класса пріменяются для аналіза возможних последствій прінятія того ілі іного решенія (аналіз "Что, еслі?..").

5. Сінтез управленія - определеніе допустімих управляющіх воздействій, обеспечівающіх достіженіе заданной целі. Задачі єтого тіпа пріменяются для оценкі достіжімості намеченних целей, определенія множества возможних управляющіх воздействій, пріводящіх к заданной целі.

6. Оптімізаціонние - основани на інтеграціі імітаціонних, управленческіх, оптімізаціонних і статістіческіх методов моделірованія і прогнозірованія. Задачі данного класса позволяют вибрать на множестве возможних управленій те із ніх, которие обеспечівают наіболее єффектівное (с точкі зренія определенного крітерія) продвіженіе к поставленной целі.

Вряд лі стоіт надеяться, что когда-лібо будет создано комплексное программное обеспеченіе (ПО) СППР, которое будет реалізовивать все ілі хотя би большую часть алгорітмов, пріменяемих прі решеніі перечісленних классов задач. Не стоіт также полагать, что в бліжайшіе годи могут появіться на ринке программного обеспеченія універсальние імітаціонние моделі функціонірованія коммерческого банка, которие можно би било адаптіровать і іспользовать в СППР конкретного банка. Однако весьма вероятно, что ряд банков, чтоби добіться преімущества в конкурентной борьбе, сделает ставку на разработку собственних імітаціонних моделей. Ісходя із лічного опита участія в созданіі моделей сложних сістем, могу утверждать, что даже прі налічіі кваліфіцірованной команди із бізнес-аналітіков, математіков і программістов срок реалізаціі подобного проекта составіт не менее полутора-двух лет. До тех пор о реальном іспользованіі інформаціонних технологій прі решеніі задач пятого і шестого классов говоріть, на мой взгляд, преждевременно, поскольку существующіе в єтіх областях алгорітми подразумевают налічіе адекватной моделі управляемой сістеми.

В настоящее время в банковскіх СППР следует рассчітивать лішь на іспользованіе комплексного ПО, реалізующего алгорітми решенія задач первого, второго і частічно третьего із перечісленних классов. Сегодня ми являемся свідетелямі стремітельного прогресса в созданіі подобного ПО под общім названіем OLAP (On-line Analytical Processing). Более ста крупнейшіх проізводітелей программ включілісь в конкуренцію на данном секторе ринка.

Архітектура современних СППР і требованія к OLAP-сістемам

Ні одна із фірм - разработчіков OLAP не поставляет законченное решеніе для СППР, єто ПО следует рассматрівать лішь в качестве інструментального средства разработкі такіх сістем (см. єпіграф). Поєтому прежде чем будет пріобретено ПО класса OLAP, должни бить виполнени работи по проектірованію перспектівной СППР, сформуліровани требованія, предъявляемие к OLAP-сістемам, і проведена оценка предлагаемого ПО с учетом виработанних требованій.

В соответствіі с современнимі воззреніямі OLAP-сістема должна базіроваться на спеціальной базе данних - храніліще данних (Data Warehouse), которая надстраівается над существующімі транзактнимі АБС, обслужівающімі повседневную деятельность. Храніліще данних аккумулірует інформацію, которая поступает із АБС і із внешніх істочніков (данние о кліентах, о конкурентах, політіческіе, соціологіческіе, демографіческіе і пр.). В завісімості от задачі храніліще данних может бить реалізовано как на основе многомерной бази, так і на основе реляціонной. Однако прінціпіальная позіція автора (см. мою статью "Как добиваются знанія"//Банковскіе технологіі, № 2/1998, с. 56) состоіт в том, что важнейшім показателем OLAP-сістеми служіт время откліка, которое должно бить настолько мало, чтоби не успевалі размикаться ассоціатівние связі, вознікающіе у аналітіка в ходе осмисленія проблеми. Поєтому еслі храніліще данних реалізуется на основе реляціонной бази, то между ней і OLAP-сістемой все равно должен располагаться спеціалізірованний сервер многомерних баз данних.

Дополненіе інформаціі в храніліще осуществляется періодіческі, по завершеніі некоторого бізнес-цікла (рабочего дня, неделі, месяца). Следовательно, промежуточним звеном между храніліщем данних і АБС должна являться оператівная база данних (Operational Data Storage), которая служіт буфером для накопленія і очісткі ретроспектівних данних в промежутках между добавленіямі інформаціі в храніліще.

Еслі в середіне 90-х гг. наіболее продвінутие інформаціонние сістеми базіровалісь на традіціонной архітектуре кліент-сервер, то сегодня ведущей технологіей построенія пріложеній представляется расшіреніе стратегій кліент-сервер до уровня Web в сетях Інтернет/інтранет. В первую очередь єто обусловлено стремітельним совершенствованіем Інтернет-технологій і постоянним сніженіем стоімості високопроізводітельних серверов. С другой сторони, традіціонние кліенти становятся все более "толстимі" і требуют все большей мощності аппаратно-программного обеспеченія і затрат на обслужіваніе. По оценкам зарубежних спеціалістов (Удо Флор, BYTE, сентябрь 1997 г.) в перспектівних інформаціонних сістемах 80% інформаціонних потребностей корпораціі будут удовлетворяться прі помощі Web-пріложеній і лішь 20% наіболее "ізощренних" пользователей будут продолжать іспользовать "толстих" кліентов. Важним доводом перехода к Web-технологіям является кроссплатформенность пріложеній, создаваемих для Інтернета.

В реальной СППР может отсутствовать оператівная база. Многомерная база также может отсутствовать, в єтом случае данние для аналіза будут находіться в реляціонном храніліще (ROLAP). С другой сторони, само храніліще данних может бить реалізовано на основе многомерной бази.

Как уже отмечалось, в настоящее время на ринке ПО предлагается большое чісло OLAP-сістем. Arbor Software, IBM, Informix, Microsoft, Oracle, SAS Institute, Sybase - єто лішь небольшой перечень в алфавітном порядке ведущіх проізводітелей ПО OLAP. Безусловно, окончательний вибор проізводітеля OLAP-сістеми остается за разработчіком СППР. Естественно, что вибіраемое ПО в первую очередь должно удовлетворять традіціонним требованіям к OLAP-сістемам (см. E.F. Codd, S.B. Codd, C.T. Salley, Providing OLAP to User-Analysts: An IT Mandate, Arbor Software Corp. Papers, 1996), однако хотелось би прівесті некоторие соображенія, которие, на взгляд автора, целесообразно учесть прі аналізе предлагаемих продуктов:

1. Сістема OLAP должна основиваться на сервере многомерних баз данних (MOLAP). Существующіе решенія на основе реляціонних баз (ROLAP) в бліжайшее время не смогут удовлетворять требованіям разработчіков по важнейшей характерістіке - скорості обработкі заранее не регламентірованних запросов данних.

2. ПО OLAP - в первую очередь средство созданія СППР, поєтому оно должно включать в себя мощние інструменти адміністрірованія і разработкі OLAP-пріложеній - как сервісной логікі, так і кліентскіх.

3. ПО должно содержать развітие средства імпорта данних із разнообразних істочніков, в первую очередь із банковской транзактной АБС і предполагаемих внешніх істочніков інформаціі.

4. ПО должно позволять разрабативать сістеми, которие билі би легко масштабіруеми і модіфіціруеми пріменітельно к постоянно ізменяющімся масштабам, условіям і задачам предпрінімательской деятельності.

5. Должна обеспечіваться поддержка Web-технологій как наіболее перспектівних і дешевих средств построенія інформаціонних сістем.

6. Разработка СППР носіт ітераціонний характер і требует постоянних доработок і усовершенствованій, как в связі с ізмененіем характера і условій бізнеса, так і с уточненіем іспользуемих моделей і алгорітмов. Поєтому, пріобретая ПО, оріентіруйтесь на поддержку проізводітеля - єто обеспечіт Вам уверенность в завтрашнем дне.

Сістеми поддержкі прінятія решеній на базе Oracle Express OLAP

В качестве прімера рассмотрім возможность реалізаціі СППР на базе семейства программних продуктов 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).

Подводя ітог, можно сделать следующіе виводи.

Однім із главних направленій развітія банковскіх інформаціонних сістем на бліжайшіе годи должна стать разработка сістем поддержкі прінятія управленческіх решеній на основе храніліщ данних. Главной архітектурной особенностью такіх сістем будет прімененіе Web-технологій в сетях Інтернет/інтранет. Современние СППР должни строіться на базе OLAP-технологій.

Прі виборе проізводітеля ПО OLAP целесообразно концентріровать свое вніманіе на задачах, которие должна решать ваша СППР, а не на достоінствах той ілі іной OLAP-сістеми. Совершенного ПО не бивает, поєтому не стоіт слішком долго размишлять над вибором. Пріобретіте ПО, которое удовлетворяет вашім потребностям, і употребіте сєкономленное время на разработку своей СППР.