Чтобы разобраться, почему отсутствуют «коробочные» решения в банковском секторе, попробуем собрать «коробку», из которой любой банк сможет достать… хранилище данных

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

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

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

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

Состав

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

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

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

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

Рынок ETL-инструментов в России, в отличие от рынка СУБД, пока только формируется, и явных лидеров здесь нет. Согласно мнению аналитиков Gartner, в лидеры рынка попадают решения Transformation Extender (который раньше назывался Data Stage), IBM и Informatica PowerCenter. И с этим нельзя не согласиться. Но, к сожалению, далеко не всегда решение даже о выборе инструментария принимается техническими специалистами, огромную роль здесь также играет политика. И такие имена, как SAS или Oracle, звучат более привлекательно.

Затем нужно выбрать способ представления отчетов. Точки зрения на то, как должен выглядеть отчет, у всех разные: кому-то нужен прямой доступ в хранилище с помощью SQL-запросов, кому-то — получать ежедневно краткий отчет, а для кого-то отчет —
это текстовый файл, который потом передается другому приложению. Кроме того, есть специалисты, которые хотят получить OLAP-куб и покрутить его в разных перспективах или построить на базе хранилища универсальный автоматический предсказатель, используя Data Mining. Кроме того, надо учесть, что до появления хранилища все эти люди как-то получали свою информацию и привыкли к своим форматам и инструментам и под их вкусы неизбежно придется подстраиваться.

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

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

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

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

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

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

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

Если процедура загрузки не легла в «коробку», то, может быть, туда можно поместить хотя бы модель данных, тем более что таких моделей уже немало?

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

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

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

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

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

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

Владимир Комаров — менеджер AT Consulting, vkomarov@at-consulting.ru