Об особенностях эволюционного развития информационной системы банка

Автор: Анатолий Грушко, Директор по развитию ЗАО "Банковские Информационные Системы" ("БИС")
Издание: Банки и технологи №3, 2002

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

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

Немного о формализации процесса разработки ИС

До определенного времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов. Появление в 70-80-х г.г. структурной методологии, предоставившей в распоряжение разработчиков существенно более строгие формализованные методы описания ИС и принимаемых технологических решений способствовало появлению средств автоматизации разработки ИС - CASE-средств. Разработки интегрированных инструментальных систем, основанных на концепциях жизненного цикла управления качеством программной продукции, привели к созданию ряда концептуально целостных технологий, оснащенных высокоуровневыми средствами проектирования и реализации программных продуктов. Большинство существующих CASE-средств основано на методологиях структурного или объектно-ориентированного анализа и проектирования. Их многочисленность, безусловно, указывает на перспективность подхода, однако разнообразие подходов и нотаций затрудняет обмен информацией и использование построенных моделей. К тому же выбранный подход и используемая в его рамках система обозначений накладывают определенные ограничения на методику моделирования, а в итоге и на получаемый результат.

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

Анализируя отличия структурного и объектного подходов, Г. Буч [1] отмечает, что методы структурного проектирования помогают упростить процесс разработки сложных систем за счет использования алгоритмов как готовых строительных блоков. Аналогично, методы объектно-ориентированного проектирования созданы, чтобы помочь разработчикам применять мощные выразительные средства объектного и объектно-ориентированного программирования, использующего в качестве блоков классы и объекты. Центральным в объектно-ориентированной методологии является понятие "объект", определяемое как "осязаемая сущность, которая четко проявляет свое поведение". Главным в понятии объекта является объединение идей абстракции данных и алгоритмов.

Отметим влияние на объектный подход теории построения баз данных, прежде всего модели "сущность-связь" или ER(entity-relationship)-модели, предложенной Ченом в 1976 году. В этой модели моделирование происходит в терминах сущностей, их атрибутов и связей между ними.

Таким образом, объектно-ориентированный анализ - это методология, при использовании которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.

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

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

Процессный подход к моделированию деятельности банка

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

Использование новейших информационных технологий само по себе не гарантирует повышение эффективности бизнес-процесса. Выделяют три направления повышения эффективности бизнес-процесса с помощью информационных технологий:

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

При оценке эффективности информационного обеспечения бизнес-процесса могут использоваться различные метрики:

1. Соответствие принятому стандарту информационного обеспечения бизнес-процесса (эталонному процессу);
2. Соответствие целям участников;
3. Стоимость реализации экземпляра бизнес-процесса с учетом стоимости затрат на информационные технологии;
4. Время процесса как косвенная характеристика его стоимости.

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

Общую схему формирования интегрированной оценки в процессе принятия решения по многим критериям можно представить следующим образом (Рис. 1):

Рис.1. Схема формирования агрегированной оценки.

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

1. Протяженностью во времени (или конечным числом моментов времени в случае дискретного процесса).
2. Множеством входных переменных (множеством начальных состояний процесса).
3. Множеством выходных переменных (множеством конечных состояний процесса). Множество конечных состояний процесса представляет собой множество готовых продуктов или оказанных услуг, востребованных потребителем (под потребителем понимается клиент или другой бизнес-процесс).
4. Множеством промежуточных состояний процесса. Процесс переходит в промежуточное состояние после завершения очередной элементарной его функции (операции).
5. Внутренней структурой совокупности элементов бизнес-системы, реализующих данный процесс (организационной структурой процесса);
6. Множеством управляющих воздействий. Каждое управляющее воздействие выбирается лицом, принимающим решение о способе выполнения элементарной бизнес-функции.
7. Множеством операторов перехода, последовательно переводящих процесс из точки, принадлежащей множеству начальных состояний, в точку, принадлежащую множеству конечных состояний.

При исследовании структуры бизнес-процесса, как правило, возникает вопрос об эффективности его функционирования. В этом случае качество процесса оценивается на основании целевой функции (критерия эффективности) бизнес-процесса.

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

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

Как устроена адаптивная система?

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

1. изменение состава и структуры бизнес-процессов, подлежащих автоматизации;
2. изменение требований к интерфейсу и эргономике системы;
3. изменение объемов операций по автоматизируемому бизнес-процессу.

Можно выделить два стандартных подхода к обеспечению адаптивности информационной системы:

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

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

1. Информация для поддержки управленческих решений стратегического характера.
2. Информация, необходимая для обслуживания клиентов и решения задач внутрибанковского управления.
3. Учетно-операционная информация о конкретных операциях банка.

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

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

Выделим технологические блоки, наличие которых позволяет решать задачи адаптации:

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

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

При построении методики нас будет интересовать структура и изменение характеристик трех компонент бизнес-процесса: интерфейса, бизнес-логики и данных.

Общая схема методики адаптации

Кратко суть методики эволюционного преобразования информационной системы можно представить следующим образом:

1. Создание и постоянная актуализация формализованной модели представления бизнес-процессов и характеристика банковских продуктов на основе модели.
2. Концептуальное описание бизнес-процессов для определенного продуктового ряда на основе выбранной формальной модели.
3. Выявление степени соответствия предлагаемой структуры программного продукта описанию (БД, возможности ПО, средства настройки).
4. Выбор инструментария, обеспечивающего адаптивность.
5. Описание банковских продуктов средствами внутреннего инструментария используемой системы.
6. Определение направлений последующего адаптивного развития системы:
• Разработка процедур компонентного изменения корпоративной БД;
• Разработка методики и процедур донастройки и перенастройки технологий;
• Разработка методики модификации интерфейса.

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

На стадии реализации необходимо:

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

Рис.3. Схема настройки нетипового бизнес-процесса.

Структура данных - это очень важно!

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

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

Остановимся несколько подробнее на способе реализации расширяемой метасхемы. Ее основными характеристиками являются:

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

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

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

Рис.4. Реализация расширения схемы данных.

Для реализации расширенной метасхемы в структуре данных присутствуют следующие сущности:

• словарь классов;
• методы классов;
• словарь реквизитов классов;
• классификатор значений реквизитов.

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

Как настраивать бизнес-логику?

Для примера остановимся на некоторых наиболее простых составляющих процесса настройки слоя бизнес-логики.

Маршрутизация финансового документооборота осуществляется с помощью механизма статусов документов. Для описания этого механизма будем основываться на ряде понятий и определений из теории графов [2]. Рассмотрим ориентированный конечный граф G = (V, E) с конечным множеством вершин V = {v1,…, vn} и ориентированных ребер eij = (vi, vj), vi, vj О V, eij О E. Множество V будем называть множеством допустимых состояний или множеством статусов, а множество E - множеством допустимых переходов между статусами. Тогда ориентированный граф GD = (VD, ED), где VD - множество допустимых статусов документа, а ED - множество допустимых переходов между статусами, назовем графом статусов документа. Структура графа GD зависит от вида документа. Конечная последовательность ориентированных ребер

S = (ekl, elj,…,epq)

(1)

называется конечным ориентированным маршрутом в ориентированном графе G, если каждые два соседних ребра имеют общую вершину. Соответственно, маршрут SD назовем маршрутом документа в графе статусов документа. Если в (1) нет ребер, предшествующих ekl , то вершина vk называется начальной вершиной маршрута, а если нет ребер, следующих за epq, то vq называется конечной вершиной маршрута.

Ориентированный граф статусов отображает последовательность переходов состояний и действий (операций), совершаемых над документом в процессе его обработки. Важное значение при маршрутизации документа имеет учет прав доступа исполнителя, осуществляющего операцию. С этой целью определим подграф GI = (VI, EI), где VI - множество статусов документа, при которых он доступен для обработки исполнителем, EI - множество переходов между статусами, которые уполномочен производить исполнитель, VI Н V, EI Н E.

Значительную часть информации относительно графа статусов G можно представить в удобной форме, используя соответствующие ему матрицы - матрицу смежности A = {aij},
матрицу смежности A = {aij},
где aij = 1, если (vi, vj) О V, и aij = 0, если (vi, vj) П V;
матрицу достижимости B = {bij},
где bij = 1, если vj достижима из vi, и bij = 0, если vj недостижима из vi;
и матрицу расстояний D = {dij},
где dij - расстояние, определенное как длина кратчайшего маршрута от vi к vj.

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

Таким образом, граф статусов расчетно-денежного документа несет следующую смысловую нагрузку:

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

В процессе настройки бизнес-логики важное значение принадлежит настройке бизнес-операций. Фиксация выполнения бизнес-операции в системе осуществляется с помощью стандартной транзакции. Каждый тип стандартной транзакции настраивается в соответствии с описанием набора шаблонов стандартной транзакции. Настройка производится в соответствии с типом операции (индивидуальная или групповая), видом транзакции (определяется обрабатывающей выполнение операции процедурой) и двумя видами атрибутов настройки - основными и дополнительными. Функциональная иерархия процесса настройки приведена на Рис. 5.

Рис.5. Структурная схема настроек бизнес-операции.

При выполнении бизнес-операции осуществляется вызов процедур, обеспечивающих:

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

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

Как обмениваться информацией?

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

Обычно выделяют входной интерфейс - интерфейс ввода информации и выходной интерфейс - интерфейс вывода информации.

Можно выделить три способа организации входного интерфейса:

• Ручной ввод информации;
• Автоматизированный ввод с генерацией части информации на основании типовых схем настроек;
• Автоматический ввод информации на основе электронных документов.

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

Одной из наиболее актуальных задач в сфере создания и развития банковских информационных систем является разработка единых форматов электронного обмена данными (ЭОД).

В настоящее время в банковских системах наиболее известны следующие форматы ЭОД:

• Фиксированный, предполагающий расположение реквизитов (полей) в определенных позициях и с заданной длиной;
• DBF-файл, содержащий необходимый стандартный заголовок и записи с содержимым описанных в заголовке полей;
• SWIFT-ориентированный;
• На основе стандарта UN/EDIFACT;
• На основе XML.

Последний формат имеет наибольшие перспективы. Его можно рассматривать как перспективный инструмент для выработки межкорпоративного стандарта представления метаданных. Корпоративные системы с появлением XML приобретают новый уровень гибкости.

Тип формата	Краткая характеристика	Преимущества	Недостатки
Фиксированный текстовый	Текстовый файл, последовательное расположение реквизитов, фиксированная максимальная длина реквизита	Простота описания структуры данных	Необходимость выборки данных из фиксированных позиций, изменение длины реквизитов требует изменения программ, расходы на обмен незаполненными полями
DBF-файл	Содержит стандартный заголовок, описывающий общие характеристики файла и его полей, и записи с данными	Распространенность DBF-формата и средств его обработки, присутствие описания структуры	Описание структуры в виде фиксированного набора полей, необходимость пересылки структуры в виде заголовка, расходы на обмен незаполненными полями, использует средства СУБД для полноценной обработки
SWIFT-ориентированный	Основан на использовании заранее определенного набора сообщений. Каждому виду финансового документа соответствует свой тип сообщения - текстовый файл, формируемый в соответствии с определенными правилами синтаксиса. Число строк - не менее количества полей, разрешено использование субполей.	Один из распространенных международных стандартов. Не передается информация о структуре сообщения, возможна передача неструктурированных данных.	Ограничен набор сообщений.Отсутствует общепризнанный стандарт для рублевых расчетов: SWIFT RUR-4 и SWIFT RUR-5 являются только рекомендациями.
На основе UN/EDIFACT	Сообщение представляет собой текстовый файл и состоит из заранее определенной совокупности сегментов, расположенных в определенной последовательности. Число строк файла равно числу сегментов. Элементы данных внутри сегмента располагаются в соответствии с описанием сегмента.	Распространенный международный стандарт для электронного документооборота, широкая сфера применения	Высокая сложность, неполное соответствие особенностям российского документооборота
На основе XML	Описание содержания документа на основе разметки, задаваемой пользователем, может восприниматься без дополнительного описания.	Основа - мощный расширяемый язык, созданный для стандартного представления документов на основе средств разметки. Возможность описания классов объектов и объектов данных сложной структуры. Позволяет описать внутреннюю иерархическую структуру документа, допустимый набор тегов и их атрибуты.	Отсутствие общепризнанных стандартов, ориентированных на обработку финансовой информации - отсутствуют стандартные библиотеки DTD (Document-Type Definitions)

Таблица 1. Сравнительный анализ форматов.

На основе сравнительного анализа наиболее распространенных форматов обмена электронными документами (Таблица 1) можно сделать выводы:

• Распространенность SWIFT-формата делает его реализацию, включая реализацию его модификаций для рублевых расчетов, необходимой в ИС банка;
• В целях обеспечения универсального интерфейса от ИС банка требуется обеспечить возможность организации интерфейса с внешними системами с использованием всех перечисленных форматов, кроме, быть может, UN/EDIFACT;
• Очевидна перспектива использования XML-формата в качестве основного.

Как анализировать данные и получать отчетность?

Для получения отчетных и аналитических данных применяется технология оперативной аналитической обработки данных на основе использования многомерной аналитической базы данных (OLAP-технология). OLAP-технология может быть практически реализована двумя способами:

• на базе автономных специализированных OLAP-платформ ( Oracle Express, Cognos и т.п.);
• путем реализации многомерных структур данных на базе обычных реляционных СУБД. С одной стороны, такой подход может не позволить использовать все возможности OLAP-технологий. Однако такая структура данных может быть интегрирована в состав схемы данных АБС, что позволит банку получить ряд технологических преимуществ, если предложенное решение является удачным.

Реализация технологии основана на следующих принципах:

• Работа всех входящих в систему модулей основывается на единой информационной базе и единой технологии обработки данных. Внутри единой базы данных были выделены транзакционная (OLTP) и аналитическая (OLAP) составляющие, при этом существует возможность физического выделения OLAP-базы. Построение транзакционной БД и технология организации учета финансовых операций ориентированы на подготовку информации для финансового анализа в режиме реального времени и для принятия управленческих решений. При проектировании аналитической составляющей хранимые данные представляются в виде многомерного куба, имеющего два общих измерения - элементы организационной структуры банка и произвольные периоды отчетности. Зафиксировав значения по двум общим измерениям, мы, в свою очередь, получим многомерный куб, содержащий отчетную и аналитическую информацию по выбранному для анализа объекту (например, "Отчет о прибылях и убытках") за указанный период времени.
• Выборка информации для расчета различных показателей или их динамических статистических рядов осуществляется в процессе формирования отчета непосредственно из единой базы данных, что гарантирует их целостность и непротиворечивость. При этом возможно одновременное использование информации из аналитической и транзакционной ее составляющих.
• Структура базы данных ориентирована на возможность формирования отчетной и аналитической информации в режиме "on-line". При этом ее архитектура спроектирована с учетом требования сохранять приемлемые размеры и быстродействие при значительном увеличении объемов хранимой информации.
• Механизмы расширения схемы данных, структуризации и группировки данных являются универсальными и позволяют агрегировать информацию в соответствии с требованиями выбранной экономической модели;
• Протоколируются изменения формул и результатов расчетов;
• Структура и вид отчетных и аналитических форм могут быть модифицированы или расширены штатными средствами настройки системы;
• Описание организационной структуры банка и соответствующее структурирование выполняемых финансовых операций дает возможность анализировать эффективность работы в разрезе центров ответственности (центров прибыли).

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

Литература

1. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. - СПб, 1998.
2. Оре О. Теория графов. - М.: Наука, 1968.