Волшебная коробка

Вас не устраивает состояние отчётности? Вы слышали о моде на хранилища данных? Думаете о внедрении Продукта, который решит Проблемы и наведёт Порядок? Тогда эта статья для вас.

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

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

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

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

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

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

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

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

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

На третьем шаге будем выбирать способ представления отчётов. Помните, я не хотел говорить, как назвать этот компонент? Дело в том, что точки зрения на то, как должен выглядеть отчёт, у всех разные. Кому-то нужен прямой доступ в хранилище с помощью SQL-запросов. Кому-то нужно просто ежедневно получать два листочка с цифрами. Для кого-то отчёт — это текстовый файл, который потом отдаётся другому приложению. А ещё есть люди, которые хотят получить OLAP-куб и покрутить его в разные стороны. Или построить на базе хранилища Универсальный Автоматический Предсказатель, Data Mining. Мало того, до появления хранилища все эти люди как-то получали свою информацию и привыкли к своим форматам и инструментам, и под их вкусы неизбежно придётся подстраиваться.

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

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

Однажды, открыв учебник по философии, я был поражён названием первой главы: «Для чего нужна философия?» Почему-то ни один автор учебника по математическому анализу не начинал свой учебник с такого вопроса.

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

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

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

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

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

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

Давайте предположим, что у нас есть Универсальная Модель, в которую можно положить всё, что так или иначе относится к банковской деятельности. Будем строить хранилище на её основе, отсекая лишнее.

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

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

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

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

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

1.10.2008