Константин Подолько: «Хранилище данных нельзя купить — его можно только построить»

Июль — Август 2001

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

Валерий Юфа: Решение каких задач привело к использованию в Газпромбанке системы класса BusinessObjects? Как эти задачи решались ранее?

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

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

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

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

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

В. Ю.: Вы рассматривали разные системы. Почему была выбрана именно система BusinessObjects, ведь систем много? Каковы были критерии выбора? Были ли альтернативы и какие? Сколько времени длился период выбора?

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

Конечно же, мы рассматривали системы Oracle Express фирмы Oracle, PowerDimensions фирмы Sybase, Teradata фирмы NCR, BusinessObjects фирмы Business Objects, Crystal Reports фирмы Seagate Software, Actuate e.Reporting Suite фирмы Actuate Software, Microsoft OLAP Server и ряд других. Результат выбора известен — BusinessObjects.

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

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

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

Евгений Иванов: А еще, на мой взгляд, большое значение в нашем выборе имели неформальные консультации не с фирмами, которые представляют системы, а с теми, кто уже делал проекты с помощью тех или иных средств. У нас хорошие отношения с московским представительством фирмы Sybase и фирмой «БизнесТех». Сотрудники компании «БизнесТех» представляли нам OLAP-сервер PowerDimensions и систему BusinessObjects в качестве инструмента для построения клиентской части приложения. Важными оказались беседы не с продавцами и разработчиками ПО...

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

Е. И.: Один из первых опытов у нас был с компанией Oracle. Мы ездили к ним два раза.

К. П.: Мы смотрели несколько решений Oracle, в том числе и решения, связанные с аналитической системой и с АБС. Они к нам очень серьезно подошли и представили нам целую серию систем различного назначения.

В. Ю.: Речь идет об Oracle Express. Но если использовать Oracle Express, то это значит, что у вас должна быть и БД под Oracle.

К. П.: Желательно, но не обязательно.

Е. И.: Oracle Express может общаться с разными БД. Но, естественно, самое эффективное решение получается, когда один интегратор.

К. П.: Самое главное — стыков меньше. И можно вызвать специалистов и сказать, что там Oracle и здесь Oracle, и компания будет вынуждена решать возникшие вопросы, у нее не будет возможности сказать, что у вас СУБД-источник работает некорректно. Фирме придется взять полностью ответственность на себя, что очень удобно для нас как для заказчика.

Е. И.: Что нас в некотором смысле остановило, это то, что они говорили: «Вам с нами будет трудно работать, если у вас не будет СУБД Oracle». С другими, в частности с «Терном», было все-таки легче (и это нас прельстило), они говорили, что у вас полная свобода в выборе источника данных.

К. П.: BusinessObjects — это отдельная аналитическая система, не привязанная к СУБД. Многие серьезные разработчики (да, наверно, все), сделав СУБД, тут же начинают разрабатывать и предлагать услуги для бизнеса. СУБД сама по себе не представляет интереса для конечных пользователей. Важны приложения, которые ее используют. И в этом смысле фирмы, серьезно присутствующие на рынке, разрабатывают собственные приложения и тем самым делают привлекательными свои СУБД.

В. Ю.: А что вы можете сказать о Teradata?

К. П.: Это продукт фирмы NCR. Она достаточно активно с нами работала по программе пластиковых карточек. И здесь они не могли мимо нас пройти, и мы тоже — мимо них. На самом деле, Teradata — это целый комплекс, в том числе и специализированное оборудование, это — очень серьезная система, которая сделана, как я оцениваю, именно для информационных хранилищ. Как вы знаете, самые большие объемы данных в мире хранятся в системах, построенных на Teradata, — до 20 терабайт.

Е. И.: Вопрос спорный, потому что IBM считает, что самые большие объемы данных у них. Кстати, мы и у IBM тоже были.

С фирмой NCR было очень интересно, нам было сказано: «Главное, это СУБД, у нас СУБД очень хорошая и работает оптимально. Мы оказываем консалтинговые услуги, и у нас есть модель банковской деятельности, состоящая из почти сотни объектов. А собственно аналитические приложения можно строить, например, на BusinessObjects».

К. П.: Я благодарен NCR, потому что они подошли к нам очень внимательно, по сути, они прочитали нам курс лекций. Я у них услышал фразу: «Хранилище данных нельзя купить — его можно только построить, готовое не купишь». Это для меня является краеугольным камнем с точки зрения построения нашего «Информационного хранилища» — его нельзя нигде найти, никто его готовое не предложит. И если кто-то предложит какое-либо решение, то потом его придется адаптировать к нашим условиям, по сути, строить самим. В этом смысле для меня было очень полезно знакомство с Teradata и другими решениями NCR. А модель банковской деятельности, предложенная NCR, к сожалению, нам не подошла. Оказалось, что тех сущностей, которые у них есть, нет у нас в нашей информационной системе, мы не можем наполнить данными их модель. Пять — семь объектов совпадает, не больше, причем не все атрибуты этих объектов у нас присутствуют.

В. Ю.: Там ведь все совсем по-другому устроено.

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

Е. И.: Если ситуация будет развиваться более или менее предсказуемо, то в итоге наш банковский бизнес будет очень похож на банковский бизнес развитых стран. Учитывая консервативность предметной области, можно предположить, что модели, предлагаемые в готовых аналитических системах, еще долго не устареют. При любом выборе речь должна идти о разумности инвестиций. Все вертикальные решения, в том числе и Teradata, достаточно дорогие, так же как и Oracle Express, и PowerDimensions. Это решения за весьма большие для нашей страны деньги, которые очень трудно мотивировать, так как не очень понятно, когда они окупятся.

В. Ю.: А вот насчет специализированного OLAP-сервера — вы сказали, что у вас по-другому, что вы пользуетесь двумя уровнями.

Е. И.: Обычно, когда речь идет об аналитических системах и хранилищах данных, то подразумевается, что используется технология многомерного анализа и в работе участвуют агрегированные данные. Очень большое внимание уделяется структуре агрегатов, что лучше — «звезда», или «снежинка», или еще что-то. Следующим по важности рассматривается вопрос о составе агрегатов. А важнейший, на наш взгляд, вопрос о состоянии дел с детальными данными из оперативных систем не представляет теоретической ценности и выпускается из рассмотрения.

На ранее упомянутом семинаре представитель фирмы Informix отмечал как большое преимущество их подхода к построению хранилищ данных тот факт, что в основе их архитектуры находится мощный реляционный сервер, в котором собираются и хранятся детальные данные из различных систем-источников. В этом случае неважно, какая стратегия хранения применяется в исходных системах, а это, в свою очередь, позволяет не терять детальные данные, не вошедшие к настоящему моменту в состав агрегатов, и постепенно уточнять модели анализируемых сегментов бизнеса. Главный лозунг — «Не бывает бесполезной информации!»

В. Ю.: Хорошая мысль.

Е. И.: Да, мы учли этот подход при проектировании нашего хранилища данных и решили, что у нас будет трехуровневая структура.

На нижнем уровне у нас реляционная СУБД, в которой мы собираем данные из разных источников. Над ней — витрины данных на OLAP-серверах, а клиентская часть — на BusinessObjects. OLAP-серверы витрин данных будут считать агрегаты и предоставлять сервис многомерного анализа. Настольные приложения клиентского уровня, построенные с помощью BusinessObjects, в качестве источников данных будут использовать эти OLAP-серверы с уже рассчитанными агрегатами. Вот такая планируется архитектура.

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

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

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

В. Ю.: А сколько времени строится одна такая свертка?

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

Е. И.: Это зависит от того, насколько к данной информации требуется оперативный доступ. У нас есть свертки по определенным признакам документов, по синтетическим счетам, по счетам аналитического учета, которые строятся раз в квартал. И мы легко можем себе позволить грузить их раз в неделю, даже раз в месяц, главное, чтобы ко времени «Ч» они были готовы.

Когда мы все это начинали, темпы развития вычислительной техники были впечатляющими, сейчас тактовая частота дошла до гигагерц. Три года назад мы покупали четырехпроцессорный сервер для хранилища (четыре процессора Pentium II Xeon производительностью 400 МГц), в России он был один такой — самый мощный сервер класса PC. Тогда этот сервер на порядок стоил больше, чем сейчас. Видя такой уровень роста производительности, мы считаем, что часть функций по агрегированию данных можно по-прежнему доверять настольным станциям, используя их вычислительные мощности и тем самым балансируя нагрузку на вычислительную систему.

К. П.: Модная идея распределенных вычислений получает здесь свое отражение. На практике она реализуется следующим принципом: мы распределяем нагрузку между сервером и рабочими станциями — часть агрегаций выполняется на рабочих станциях. Мы извлекаем сырые или полусырые данные из хранилища данных, и дальше на рабочих станциях идет их дальнейшая агрегация и обработка. Таким образом, мы действительно разгружаем центральный сервер и тем самым загружаем станции, производительность которых теперь уже зачастую не ниже 900 МГц. Сервер, конечно, более эффективное устройство, но те же 900 МГц использовать для рисования окошек на экране нерационально. Поэтому рабочая станция решает свою задачу, сервер — свою, и получается в целом достаточно эффективная система. Специальный инструментарий позволяет извлечь быстрыми запросами (за 2—3 с) данные и агрегировать их. Если бы мы агрегировали данные на сервере, получая абсолютно готовый отчет, то сервер не смог бы обслужить всех пользователей или делал бы это очень медленно.

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

Е. И.: Я хотел бы сказать насчет архитектуры. Мы сейчас так браво говорим, что мы распределяем и балансируем нагрузку. Такое решение нормально именно при нашем объеме сырых данных. Вопрос о серверах возник не у нас, а там, на Западе — у них эти объемы мерятся другими масштабами. У нас сейчас хранилище около 30 Гбайт — это достаточно много для нас, а там, в принципе, не бывает хранилищ данных такого объема, счет начинается с сотен гигабайт. Именно из-за разницы в объемах мы можем себе позволить агрегировать на клиенте, но опять же учитывая объем каждой конкретной выборки.

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

Е. И.: Не только клиент, но и сеть не испытает напряжения при передаче такого объема.

К. П.: Например, если извлечь баланс банка за день, это составит 2—3 тысячи счетов, т. е. 2—3 тысячи записей. Это легко помещается в оперативную память и легко обрабатывается обычными алгоритмами. Если обрабатывать их на сервере, то, понятно, один запрос в 2—3 тысячи записей не загрузит сервер, но если таких запросов будет 20—30, то, соответственно, время реакции сервера, а значит, и всей системы возрастет.

В. Ю.: Как проходило в банке внедрение системы?

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

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

К. П.: Да, я помню, что к заданию было приложено требование на 32 отчета.

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

Станислав Власов: Мы начинали с задачи «Кредитный портфель». Буквально с нуля — до этого я о BusinessObjects вообще ничего не слышал.

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

С. В.: Самая первая семантическая модель была построена за неделю, потом мы ее раза три-четыре переделывали. На начальном этапе мы выпускали по два отчета в день, потом три, четыре, последние 16 отчетов мы сделали за один день. А весь процесс вместе с обучением пользователя занял месяц.

К. П.: Следует сказать, что в начале проекта мы определили для себя дату, когда нам нужно будет принять решение о продолжении работы либо начать выполнение задания старыми методами. Хочу отметить, что результаты теста оправдали ожидания. Более того, в дополнение к заданному набору был построен отчет, на базе которого аналитику продемонстрировали возможности инструмента и новые возможности собственно аналитика. Эффект был ошеломляющим. Он понял, что он может не программировать больше в Access, не тратить на это свое время и попросил документацию на BusinessObjects.

С. В.: Когда он получил все свои 32 отчета, он был доволен, посмотрел и сказал, что хочет все-таки немножко не так — это объединить с этим, это повернуть сюда, еще какой-то график построить, еще что-то. На что было сказано: «Мы Вам поможем. Давайте мы Вас научим». Ему потребовалось обучение в течение полудня — знакомство с основными принципами работы в BusinessObjects, потом он в течение недели несколько раз звонил по телефону. После этого он стал звонить два раза в неделю, один раз в неделю, раз в месяц. И сейчас это наиболее успешно реализованная задача на BusinessObjects, потому что с моей точки зрения как администратора система BusinessObjects не требует к себе практически никакого внимания. Теперь наш первый пользователь и другие сотрудники, работающие в кредитном департаменте, сами составляют многостраничные отчеты с красивыми графиками — многие вещи из того, что делают они, мне было бы сложно повторить, настолько они уже углубились не в обработку данных, а в способы представления полученных результатов.

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

В. Ю.: В концепции BusinessObjects семантическая модель является ключевым элементом.

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

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

В. Ю.: Я понимаю это дело так — можно построить сначала общую модель, но ведь потом ее постоянно нужно переделывать.

К. П.: А самое главное — появляются новые данные в хранилище, какие-то новые источники, которые ранее не были интегрированы в хранилище. Постоянно идет процесс увеличения числа объектов в информационном хранилище.

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

В. Ю.: Как выглядит итоговая цепочка? Есть вы, потом аналитики, потом пользователи, кому вы отдаете свою работу?

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

В. Ю.: Для доступа к какой информации используется система BusinessObjects и какими отделами банка?

Е. И.: В настоящее время мы рассматриваем BusinessObjects как основной инструмент построения аналитической системы. Можно констатировать, что с той или иной степенью полноты модули аналитической системы используются подразделениями, работающими с клиентской базой, главной книгой, кредитами, депозитами, торговыми операциями, частными вкладами и пластиковыми карточками.

В. Ю.: Каковы отзывы пользователей системы BusinessObjects?

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

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

В. Ю.: Что дает аналитическая система банку в настоящий момент?

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

В. Ю.: Каковы дальнейшие планы развития аналитической информационной системы в банке?

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

Мы надеемся на плодотворное сотрудничество в этих вопросах с компанией «Терн» и на то, что линейка продуктов фирмы Business Objects поможет нам успешно решить поставленные задачи.