Анализ и прогноз финансовых процессов - информационно-технологическое обеспечение

“По сведениям, полученным от Meta Group, создание хранилища данных обходится
в среднем в три миллиона долларов, его объем составляет от 100 до 150 Гб...”
- Стэн Гибсон, “Хранилища данных вступают в игру”, PC WEEK/RE N34(58) за 1996 г.

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

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

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

Каждому банку — по информационному хранилищу?

В последнее время появилось большое количество публикаций, противопоставляющих технологии OLTP (On-Line Transaction Processing) и DSS (Decision Support Systems). Большинству авторов архитектура систем ОLTP представляется источником всех бед, возникающих при попытках решения на их базе аналитических задач, а создание выделенных информационных хранилищ, как правило, на основе OLAP (On-Line Analytical Processing), — некой технологической панацеей.

Чем же обосновывается невозможность или неэффективность решений на базе OLTP-систем? Пожалуй, наиболее показательна в этом отношении статья Н. Соколова (фирма “Диасофт”) “Хранилища, которые мы выбираем” (COMPUTERWEEK-MOSCOW 6(260) 20-26 февраля 1997 г.):

“…данные, аккумулированные в недрах OLTP-систем, труднодоступны, содержащаяся в них информация часто изобилует ненужными деталями или, наоборот, важные детали там отсутствуют…”;

“…между разными транзакционными системами [одновременно используемыми в банке], как правило, не соблюдаются общие правила именования, кодировки и измерения переменных …”;

“…информация, необходимая для принятия решений, часто располагается на разных платформах. Задача ее извлечения по плечу лишь квалифицированному специалисту…”;

“…после того как данные собраны… конечный пользователь вряд ли сможет работать с ними напрямую, поскольку уровень компьютерных знаний управленцев относительно невысок…”;

“Запросные” программы приходится не только писать и отлаживать, но и “ловить удобный момент для их прогона, чтобы нечаянно не “подвесить” работающую транзакционную систему или не снизить ее производительность…” и т.д., и т.п.

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

Стоит ли игра свеч?

Итак, использование информационного хранилища не компенсирует субъективных недостатков “плохой” OLTP-системы, но может быть на этом проблемы и кончаются?

Рассмотрим некоторые вопросы, возникающие при прогнозировании финансовых показателей.

Очевидно - качество прогноза тем выше, чем меньшей долей исходной информации мы при этом вынуждены пренебречь. Поэтому в прогнозе финансового состояния банка должна учитываться информация не только об уже выполненных операциях, но и о тех что запланированы на период прогноза (требования и обязательства банка по заключенным, но не завершенным договорам, сделкам и т.д.). То есть исходной информацией являются не только “исторические” — гарантированно постоянные данные, но и те, что с определенной степенью вероятности еще могут измениться.

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

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

Как же быть, если неправильно агрегированная информация о неправильно учтенных операциях уже загружена в хранилище?

Учитывая все это трудно не согласиться с тем, что идея создания аналитической подсистемы, непосредственно использующей единую с АБС базу данных, выглядит весьма заманчивой, так как дает ряд определенных преимуществ: простота технологии и оперативность решения задач, гарантированная непротиворечивость результатов, достигаемая за счет отсутствия этапа “перекачки” данных из базы ОLTP в информационное хранилище и др.

Что же делать?

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

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

Пятилетний практический опыт специалистов фирмы БИС, накопленный в процессе работы над банковской интегрированной системой (БИСКВИТ) показывает - проблема действительно существует, но она вполне разрешима.

Пути и средства ее решения таковы:

• хорошо проработанная модель данных и интерфейсы;
• использование современной корпоративной реляционной СУБД;
• эффективные средства разработки приложений.

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

Модель данных — фундамент интегрированной банковской системы

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

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

Кажущаяся избыточность информации при такой организации базы данных не только компенсируется компактностью ее хранения в СУБД PROGRESS, но и дает принципиальные технологические преимущества, так как позволяет легко создавать отчеты или отображать необходимые характеристики объектов учета в интерактивном режиме на любые даты или за любые периоды.

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

Другие важные характеристики модели данных, необходимые для эффективного финансового анализа и прогноза, включают:

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

Интерфейс пользователя не менее важен

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

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

Кроме того, информация из базы данных может передаваться в реальном режиме времени в электронные таблицы Microsoft Excel, и банковский аналитик сможет использовать их возможности при решении разнообразных задач финансового анализа и составления банковской отчетности. Сегодня все большее число профессиональных статистических, нейросетевых и других аналитических пакетов использует в качестве основного пользовательского интерфейса таблицы Microsoft Excel, что практически снимает проблему обмена данными между системой БИСКВИТ и подобными прикладными пакетами других фирм.

Таким образом, надлежащим образом спроектированная транзакционная система может представлять собой достаточно упорядоченное хранилище с удобным, гибким и открытым интерфейсом. Действительно, решение аналитических задач на транзакционной базе данных накладывает на нее большую дополнительную нагрузку, однако практика показывает, что эффективность современных корпоративных СУБД, а также относительная дешевизна вычислительных ресурсов легко позволяют сконфигурировать и настроить информационную систему так, что все пользователи - и “транзакционные” и “аналитические” - могут работать с приемлемым временем отклика, не мешая друг другу.

Золотая середина

Ни в коей мере не отрицая очевидных преимуществ выделенных информационных хранилищ и отчетливо представляя себе все их недостатки, хотелось бы отметить, что сегодня их применение может быть оправдано, правда, лишь в весьма небольшом (а в России — и вовсе крохотном) секторе рынка. На наш взгляд, гораздо практичнее развивать аналитические возможности АБС путем грамотного использования современных корпоративных СУБД, большей интеграции функциональных модулей, более тщательной проработки моделей данных и интерфейсов и даже использования OLAP-архитектуры в рамках транзакционных систем. Только после того, как все эти возможности будут исчерпаны, можно подумать и о построении выделенных информационных хранилищ.