Интеграционное решение на основе системы Equation

== Интеграционное решение на основе системы Equation миграция данных и взаимодействие с внешними системами) ==

В настоящем документе приведен анализ возможных вариантов построения интеграционного решения на основе системы Equation для автоматизации банковской деятельности, а также приведено описание решения, использованного в рамках проекта внедрения Equation в АК БАРС банке. Интерфейсные функции системы Equation используются на следующих этапах внедрения системы : 1. Миграция данных 2. Взаимодействие систем в процессе эксплуатации интеграционного решения

Миграция данных

Существует два подхода к миграции данных: 1. Заполнение таблиц с данными для последующей обработки в Equation (структура таблиц должна совпадать со структурой журнальных файлов) 2. Экспорт информации из эксплуатируемой системы и ее последующая обработка специально созданным программным обеспечением

Подход 1.

Заполнение журнальных файлов выполняется, как правило, силами программистов банка. Почему: - экспорт информации в таблицы не составляет большого труда; - на презентациях демонстрируется легкость использования данного подхода: «просто заполните файлы»; - можно сэкономить средства, выполнив часть работ самостоятельно, без привлечения внешних ресурсов; - исполнитель работ разделяет риски с заказчиком и имеет возможность переложить проблемы миграции данных на заказчика (называя этот процесс «подготовкой корректных исходных данных»).

Риски: Основная проблема состоит в правильном заполнении файлов. В структуре таблиц кроме бизнес-параметров операций присутствует много дополнительной информации. Часть ее появляется вследствие особенностей обработки информации в системе. Назначение этих параметров и логика их обработки не всегда подробно описана. Кроме того, существует большое количество проверок информации, которые зависят от конкретного набора параметров операций.

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

Пример из интеграции Equation и Диасофт. В системе Equation основные параметры обработки объектов настраиваются на уровне «типов объектов». Основные объекты в Equation: клиент, счет, проводка, сделка. Т.е. для открытия счета необходимо указать тип счета. В системе Диасофт такого параметра нет. И нет набора признаков, по которому можно автоматически подобрать нужный счет.

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

Подход 2.

Создание специального программного обеспечения потребует дополнительных затрат. Рассмотрим на примере внедрения Equation в АК БАРС банке, что может дать подобный подход:

1. Банк выгружает ту информацию, которая содержится у него в системе, без ее предварительной обработки.

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

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

4. Данные для миграции могут поддерживаться в актуальном состоянии

5. Миграция данных может быть выполнена в любой момент в автоматическом режиме

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

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

8. Возможность использования ПО для проверки правильности базы клиентов и счетов филиалов банка (соответствие открытых клиентов, счетов, реквизитов документов нормативным требованиям ЦБ РФ).

Результаты: ||Кол-во миграций – 21||Первая миграция||Итоговая миграция при вводе в промышленную эксплуатацию|| || || || ||