«Вас не устраивает состояние отчетности? Вы слышали о моде на хранилища данных? Думаете о внедрении продукта, который решит проблемы и наведет порядок? Тогда эта статья для вас», — обещает Владимир Комаров, менеджер практики BI.

_______

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

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

Может быть, такая ситуация — это «издержки переходного периода», и рынок банковского программного обеспечения просто не дорос до «коробочной» стадии? Чтобы ответить на этот вопрос, давайте попробуем собрать эдакую «волшебную коробку», из которой любой банк сможет достать... хранилище данных.

Состав

Для начала определимся с инструментарием. Во-первых, в «коробке» должна быть СУБД, которая, собственно, и является «хранилищем данных». Во-вторых, базу данных нужно чем-то наполнить. Компонент, занимающийся наполнением, называется ETL-машиной, от слов «Extract, Transform, Load». Ну и, наконец, должен быть обеспечен удобный доступ к данным. Имея все перечисленные инструменты, остается разработать структуру базы данных (модель), написать код, заполняющий эту структуру, и код, извлекающий данные и формирующий отчеты.

Казалось бы, что может быть проще? Положим в нашу коробку все необходимые инструменты, разработаем модель данных, напишем «стандартное решение» по наполнению этой модели и стандартные же отчеты, но все не так просто.

Вопросы и ответы

Первый вопрос, который возникает: какую СУБД выбрать? Обещает чудеса Sybase IQ. Teradata с легкостью ворочает огромными объемами данных и охотно рассказывает о технических решениях, обеспечивающих эту легкость. За DB2 сорокалетний опыт создания реляционных баз и поддержка практически любого оборудования. Создатели Oracle в последних версиях сделали поистине революционные шаги к поддержке хранилищ. Здесь главный критерий выбора — простота поддержки. Поэтому с огромной вероятностью российские компании выберут Oracle. Однако не стоит сбрасывать со счетов тех, кто вложится в решение Teradata и тех, кто поверит обещаниям Sybase. Пусть таких клиентов будет мало, зато они, по всей видимости, знают, чего хотят...

Рынок ETL-инструментов в России, в отличие от рынка СУБД, пока только формируется, и явных лидеров здесь нет. Если посмотреть на «магический квадрат», представленный Gartner group, то в лидеры попадают Transformation Extender (который раньше назывался Data Stage) компании IBM и Informatica PowerCenter, и с этим нельзя не согласиться. Но к сожалению, далеко не всегда решение даже о выборе инструментария принимается техническими специалистами, огромную роль здесь также играет политика. И такие имена, как SAS или Oracle, звучат несколько более привлекательно.
Затем нужно выбрать способ представления отчетов. И здесь возникают определенные проблемы: дело в том, что точки зрения на то, как должен выглядеть отчет, у всех разные. Кому-то нужен прямой доступ в хранилище с помощью SQL-запросов. Кому-то нужно просто ежедневно получать два листочка с цифрами. Для кого-то отчет — это текстовый файл, который потом отдается другому приложению. А еще есть люди, которые хотят получить OLAP-куб и покрутить его в разные стороны. Или построить на базе хранилища универсальный автоматический предсказатель, Data Mining. Мало того, до появления хранилища все эти люди как-то получали свою информацию и привыкли к своим форматам и инструментам, и под их вкусы неизбежно придется подстраиваться.
В общем, ясно, что ни о каком стандартном инструментарии говорить не приходится. Но давайте посмотрим, может быть, есть возможность стандартизации где-то на более высоком уровне?

Миф об универсальной модели

Набрав в поисковой системе запрос «отраслевая модель хранилища данных для банков», получим немало ссылок на документы, где утверждается, что некая компания разработала универсальную модель, которая внедряется за один-два месяца, максимум полгода, и сулит такие невообразимые конкурентные преимущества, что остается только удивляться, почему до сих пор остались банки, где хранилище данных не построено. Но ведь есть еще и зарубежные модели, которые были разработаны значительно раньше российских. Так почему же они не внедрены повсеместно, почему для наших моделей вообще нашлась ниша?

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

Если требуется банковская отчетность, то процедура извлечения данных должна быть прежде всего точной, если речь идет об управленческой отчетности — данные нужно извлекать быстро. Разработчики знают, что нередки случаи, когда для уточнения значения одного-единственного поля в 3% записей алгоритм приходится усложнять в несколько раз. А сделать выбор между скоростью и точностью разработчик не может — это должен сделать заказчик.

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

В рекламных проспектах некоторых компаний можно встретить фразу: «процедура загрузки в хранилище универсальна, надо только выгрузить данные из АБС в текстовый файл». Это значит, что сложных преобразований данных избежать не удается, просто теперь они называются не «загрузкой», а «выгрузкой». Можно спорить о том, кто должен осуществлять эти преобразования и на каком этапе, но сам факт наличия уникальных алгоритмов споров не вызывает.
Если процедура загрузки не легла в «коробку», то может быть, туда можно поместить хотя бы модель данных, тем более что таких моделей уже немало?

Предположим, что у нас есть универсальная модель, в которую можно положить все, что так или иначе относится к банковской деятельности. Будем строить хранилище на ее основе, отсекая лишнее. Пусть, например, модель предусматривает наличие справочника марок автомобилей, которые клиенты банка покупают в кредит. Банк действительно выдает автокредиты, но как раз такого справочника в исходных системах нет. Что делать? Можно попытаться создать справочник по ходу дела. Но, во-первых, такую возможность должна предоставлять ETL-машина, а во-вторых — бюджет проекта: справочник, например, банковских продуктов гораздо более важен, а время ограничено. Значит, в хранилище такого справочника не будет, причем изменение произошло из-за факторов, кажущихся малозначительными — сроков проекта и используемого инструментария.

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

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

Клиентоориентированность

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

А «коробочные» продукты останутся: есть же на рынке финансовых услуг «кредиты наличными за один час». Но как предприятие никогда не получит такой кредит, так и банк, решивший построить хранилище данных, никогда не обойдется коробкой, пусть даже волшебной.