Технология перевода ЦХД на новый источник данных: делимся опытом

Технологии
8448
0
Анна Филиппова, директор производственного центра департамента аналитических систем, R-Style Softlab
Когда в банке принимается решение о смене АБС, это рикошетом затрагивает практически все установленные в нем автоматизированные системы и программные компоненты. В том числе и хранилище данных, для которого АБС является основным источником информации. Как сделать так, чтобы при переходе на новую учетную систему банк не утратил доверия к существующему хранилищу данных и по прежнему смог принимать качественные управленческие решения на основе содержащихся в нем детальных данных и отчетов? Столкнувшись на практике с подобным вопросом, наша компания нашла на него верный ответ и готова поделиться технологией «бесшовной» миграции ЦХД на новую АБС.


«…менять свои привычки — очень хлопотно не только для того, кто их меняет, но и для окружающих».
Наталья Осис. «У самого синего моря. Итальянский дневник»

Разрабатываем план действий


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

Определяем участников проекта, их зоны ответственности и роли


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

Формулируем требования к загружаемым из новой АБС данным


При загрузке в ЦХД данных из новой АБС очень важна преемственность, поэтому нужно правильно сформулировать верхнеуровневые требования к данным с точки зрения семантики. В качестве примера приведем несколько формулировок таких требований:

  • На старте каждый филиал банка ведет учет в своем, отдельном экземпляре АБС. Внедрение новой АБС подразумевает централизованный учет для всех филиалов и головного офиса в одном экземпляре системы.
  • Для элементов справочников, создаваемых в новой АБС, при выгрузке в ЦХД должна соблюдаться принятая для старой АБС логика формирования их кодов.
  • При выгрузке клиентов из старой АБС в новую выполняется их дедубликация (удаление дублей), благодаря чему в формируется новый «дедублицированный» клиент.
  • Проводки по мигрировавшим счетам, проведенные в АБС до даты миграции (и мигрировавшие в новую АБС), в ЦХД загружаться не должны.
  • Счета и сделки, закрытые в АБС до даты миграции (и мигрировавшие в новую АБС как закрытые), в ЦХД загружаться не должны.
Чем точнее и подробнее будут сформулированы эти требования, тем проще вам будет начать работать с данными хранилища, поступающими из новой АБС, и легче будет им доверять.

Особое внимание — контролю


Как мы уже упомянули, при смене в ЦХД основного источника данных особое внимание следует уделить контролю качества данных. Рассмотрим подробнее, какие именно аспекты подлежат проверке, и в чем она заключается.

Контроль детального слоя


Основной принцип контроля детального слоя таков: в архивной выгрузке из новой АБС все значимые атрибуты (реквизиты) и связи клиентов, счетов и сделок должны быть сопоставимы с аналогичными данными, загруженными ранее в ЦХД из старой АБС. Для такого сопоставления используются таблицы соответствия. Процесс сверки архива в ЦХД может быть автоматизирован, при этом должны соблюдаться следующие условия:

  • Каждой мигрировавшей в новую АБС и выгруженной в ЦХД сущности должна соответствовать в ЦХД закрытая сущность (выгруженная ранее из старой АБС). Сверка выполняется после загрузки архива из новой АБС в ЦХД с использованием таблиц соответствий старых-новых сущностей. Исключения должны быть объяснены явно: дедубликацией клиентов, наличием у счета признака «сводный» у счета и т.д.
  • Каждой закрытой сущности в ЦХД (выгруженной ранее из старой АБС) должна соответствовать мигрировавшая сущность, выгруженная из новой АБС. Сверка выполняется после загрузки архива из новой АБС в ЦХД с использованием таблиц соответствий старых-новых сущностей. При этом необходимо, чтобы дата привязки в таблице соответствия равнялась дате миграции. Исключения должны быть объяснены явно — дедубликацией клиентов, наличием признака «сводный» у счета и т.д.
  • Значения ключевых реквизитов мигрировавших в новую АБС клиентов, счетов, договоров и прочих объектов в ЦХД должны совпадать со значениями ключевых реквизитов сущностей, выгруженных ранее в ЦХД из старой АБС. Различия должны быть объяснены (например, попаданием в «Корзину» — область «плохих» данных).

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


Основные принципы контроля агрегатов (то есть расчетных показателей) остатков и оборотов таковы:

  • Данные агрегатов, рассчитанные по дату миграции включительно на основе загруженных из действующей АБС данных, считаются константой и не пересчитываются.
  • Изменения, которые приходят в инкрементальных порциях по дату миграции включительно, при выполнении сверок игнорируются.

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

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

2. Остатки и обороты на консолидированном счете сверяются с суммами остатков и оборотов на связанных субсчетах.

3. При условии ежедневной выгрузки из новой АБС суммарных остатков и оборотов выполняется сверка загруженных и рассчитанных в ЦХД остатков и оборотов по счетам.

Контроль витрин и отчетов


Отчеты — это объекты ЦХД, содержащие систематизированную информацию для определенной группы бизнес-пользователей.

Облегчить контроль качества данных позволяет автоматизация самого процесса сверок. В частности, нужно добиться корректного выпуска отчетов в безынтерфейсном режиме. Для этого необходимо определить значения параметров, позволяющие выполнять автоматизированный выпуск отчетов, и зафиксировать алгоритмы преобразования значений в сверяемых показателях с целью их сопоставления с эталоном. Это могут быть, например, допустимые технические изменения кода и метаданных отчетов, которые позволяют, не меняя бизнес-логики, выпускать отчеты в безынтерфейсном автоматизированном режиме (изменения порядка следования колонок, выполнение технических операций commit, приведение типа clob для сверяемого показателя отчета к строковому типу (VARCHAR2(4000)) и другие).
Основной принцип контроля отчетов, которому мы советуем следовать, такой: отчет, выпущенный в ЦХД до загрузки архивных данных из новой АБС, должен содержать те же данные, что и после загрузки архива.
С этой целью предлагаем провести два теста. Первый — на проверку соответствия эталонных данных данным отчетов, сформированным за дату «T» после загрузки архива из новой АБС. Этот тест должен показать, что загруженные архивные данные, которые начинают действовать с даты «T+1», не влияют на эталон, то есть не «портят» эталонные данные.

Второй тест — на проверку соответствия эталонных данных данным отчетов, сформированным за дату «T+1» после загрузки архива из новой АБС. Этот тест должен показать, что отчеты за дату «Т+1» имеют значения сверяемых показателей, соответствующие эталонам, за исключением объяснимых расхождений (например, «количество дней просрочки» должно увеличиться на один день).

В своей практике мы эти тесты автоматизировали. С учетом того факта, что в ЦХД есть как динамические, строящиеся «на лету», так называемые «Ad hoc»-отчеты, так и отчеты, формирующиеся на основе ранее рассчитанных витринах показателей, реализация тестов велась по двум направлениям: отдельно для динамических отчетов и для отчетов, построенных на витринах данных.

Сверка динамических отчетов предполагала следующие шаги:

1) Перед загрузкой архивных данных выпускаются контрольные отчеты за дату «Т».

2) После загрузки архива и разбора корзины отчеты за дату «Т» формируются повторно. Они должны быть идентичны тем, что получены в п.1.

3) Имитируется логическая смена дня (пересчитываются агрегаты за дату «Т+1» без дополнительной догрузки данных).

4) Формируются отчеты за дату «Т+1». Они должны быть идентичны полученным в п.1 за дату «Т» (разумеется, за исключением объективно изменившихся показателей, таких как «количество дней просрочки» и пр.).

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

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

1) Вначале формировался список контрольных отчетов.

2) Выпустили отчеты за контрольную дату (перед загрузкой архива). Контрольная дата должна быть меньше либо равна «Т». Данные отчетов зафиксировали как эталон.

3) Загрузили архив из новой АБС.

4) Сверили отчетность до загрузки архива (эталон) и после загрузки за контрольную дату. Итоговые цифры должны сойтись.

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

Анализируем результаты, исправляем ошибки


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

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

1) Ошибки, связанные с выгрузкой данных: нарушения в форматах выгружаемых данных, их семантике или полноте (объеме).

2) Ошибки в исходных данных: незаполненные атрибуты, нарушение полноты аналитического учета (фактические операции), отсутствие настроенных банковских продуктов (отсутствие связи бухгалтерской, аналитической и договорной информации).

3) Ошибки, делающие невозможным получение данных отчетов в определенных условиях.

Результаты выполнения процедур контроля протоколируются, проблемы с данными анализируются и исправляются.

Следуя предложенному нами алгоритму, банк сможет обеспечить практически «бесшовную» смену источника данных для ЦХД при переходе с одной АБС на другую.

Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2016 2017 2018