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

Intelligent Enterprise: Давайте начнем с описания деятельность агентства. Какие ее особенности диктуют необходимость внедрения технологий информационной интеграции?

Иван Зайцев: ОАО "Агентство по ипотечному жилищному кредитованию" (АИЖК) создано правительством России как одна из ключевых структур, призванных обеспечить развитие рынка ипотечного кредитования в России. Основная задача агентства - обеспечивать массовый приток долгосрочных рублевых средств в сферу ипотеки и организовывать размещение этих средств в ипотечные кредиты и займы. Для выполнения этой задачи создана сеть региональных операторов и сервисных агентов, занимающихся вопросами ипотечного кредитования в субъектах Федерации. Региональные операторы и сервисные агенты создают местную инфраструктуру, состоящую из банков, оформляющих ипотечные кредиты, оценочных компаний, риелтеров, страховых компаний.

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

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

И какие варианты информационной интеграции вы рассматриваете исходя из этой ситуации?

С технологической точки зрения, вариантов вполне достаточно и их можно вполне разумно сочетать. Начнем с Единой информационной системы (ЕИС АИЖК). Помимо ее части, отвечающей за информационную поддержку финансового учета и управления внутри нашей организации (на основе MBS Axapta), существенную роль в поддержке нашей деятельности играет тесно интегрированная с Axapta CRM-система на базе продукта компании Pivotal. Она автоматизирует функции работы с партнерами и клиентами, в том числе процессы выдачи, сопровождения и рефинансирования ипотечных кредитов и займов.

С этой системой через Web-интерфейс работают как сотрудники, так и партнеры агентства (региональные операторы и первичные кредиторы). Такая схема позволяет нам самим автоматизировать сложные бизнес-процессы, возникающие при ипотечном кредитовании, и предоставлять партнерам готовый сервис для выполнения возложенных на них задач. На начальном этапе подобный механизм информационного взаимодействия между нами вполне приемлем, однако деятельность наших партнеров довольно часто не ограничивается только ипотечным жилищным кредитованием. И поскольку полная автоматизация их процессов с помощью нашей системы крайне проблематична, встает задача взаимодействия между нашей информационной системой и внутренней ИТ-инфраструктурой партнеров. Особенно это касается банков, которые могут работать при подготовке и выдаче ипотечных кредитов как в среде ЕИС АИЖК, так и с использованием своих собственных информационных систем в контексте их основной деятельности.

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

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

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

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

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

Резюмируя все вышесказанное, можно отметить, что речь идет об организации очень насыщенного и вместе с тем гибкого взаимодействия между различными системами автоматизации бизнеса. В этих условиях один упомянутый выше Web-интерфейс нашей CRM-системы явно недостаточен. Рассуждая на технологическом уровне, можно было бы вести речь об интеграции на основе известных объектных стандартов - COM+ или CORBA. Однако независимо от того, идет ли информационный обмен между нами и нашими партнерами или между партнерами напрямую, или же данные приходят вообще от сторонних компаний, в результате должно быть учтено множество сложных смысловых категорий, условий и ограничений, характерных для предметной области ипотеки.

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

В таком случае давайте перейдем к вопросу о том, как происходит подготовка к использованию отраслевых XML-спецификаций на практике.

По-настоящему активно работать в этом направлении мы начали с августа текущего года. XML-спецификация в том виде, в котором она существует изначально, является лишь основой для строительства поверх нее того или иного отраслевого стандарта. Его создание в свою очередь состоит в том, чтобы сформировать необходимое и достаточное множество тегов и атрибутов, адекватных предметной области, чтобы затем иметь возможность формировать из них наши отраслевые документы. По сути, это работа по трансформации положений разработанных нами стандартов в области ипотечного жилищного кредитования (которые опубликованы на сайте www.ahml.ru) на язык, совместимый с XML. В технических терминах это создание так называемых XML-схем, в общедоступных - формирование единого словаря понятий и методов, принятых при работе с информацией в нашей области. Для практической реализации мы выбрали сервер Microsoft Biztalk. Кроме того, здесь хотелось бы поблагодарить наших коллег из компаний TopS BI и VDI, которые помогают нам в осуществлении данного проекта.

Отдельный вопрос - как лучше подходить к формированию словаря. И здесь также есть нюансы. С одной стороны, хочется учесть международный опыт. В нашем случае мы стремимся использовать наработки Организации по поддержке стандартов в сфере ипотеки (MISMO, www.mismo.org), специальной созданной ассоциацией ипотечных банков США для разработки и продвижения XML-спецификаций в данной отрасли. При этом наши зарубежные коллеги уже продвинулись дальше создания словаря. Они определили, как данные упаковываются, как подписываются, с помощью каких стандартов передаются, что нам также предстоит сделать.

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

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

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

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

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

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

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

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

Мне кажется, что базовыми спецификациями здесь являются непосредственно XML-стандарт, XML-схемы и таблицы стилей. Они стали фундаментальными для нас, и на мой взгляд, это было бы так и в любом другом отраслевом проекте. Далее следуют спецификации "второго эшелона", некоторые из которых целесообразно использовать по мере "взросления" отраслевых разработок. Так, например, если наши документы будут приобретать сложную составную структуру, мы будет использовать спецификацию Xlink. Использовать же язык запросов XQL мы, напротив, в ближайшем будущем не будем, поскольку храним данные не в XML-формате, а в классическом реляционном.

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