Интеграция банковских систем: операция высокой точности

19 июня 2013
7 10009

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

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

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

Любой крупный банк использует серьезный программно-аппаратный комплекс, включающий «свои» системы, а также интеграции со сторонними. Перечислим лишь основные используемые системы:

  1. АБС — критически важная система, сердце любого банка;
  2. Контакт-центр;
  3. CRM-система;
  4. Хранилище данных и системы бизнес-анализа;
  5. Система документооборота и электронный архив;
  6. Интернет-банкинг;
  7. Скоринг;
  8. Системы проверки на мошенничество;
  9. БКИ (наряду с системами скоринга, являются важным звеном при реализации кредитного конвейера или системы принятия решений).

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

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

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

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

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

Между тем, описанных ситуаций легко можно избежать, если на этапе выбора системы (до начала проектирования и тем более реализации) помнить о нескольких простых, но важных вещах:

  1. Для каких задач выбирается система и каким образом решаются эти задачи на данном этапе;
  2. Какая информация будет загружаться в систему, как это будет происходить (однократная миграция данных, периодическая — по требованию или по расписанию, постоянная (онлайн), и в каких системах находятся эти данные;
  3. Насколько платформа, которую вы планируете выбрать, легко встраивается в вашу инфраструктуру, а именно:
    • поддерживает принятую СУБД,
    • имеет доступный API для взаимодействия со сторонними системами и получения данных, а также встроенные возможности для расширения функционала системы,
    • обслуживание системы и установка обновлений не требуют остановки системы на длительный срок;
  4. Как будет выглядеть архитектура интеграционного решения и технология взаимодействия систем, включая использование интеграционной шины;
  5. Какие системы в дальнейшем будут появляться в архитектуре, как они будут связаны друг с другом, какими данными будут обмениваться — в соответствии с ИТ-стратегией развития банка.

Как пример грамотного подхода к подобным проектам, приведем пример внедрения Microsoft Dynamics CRM в КБ «Локо-Банк» (ЗАО), где был реализован проект по автоматизации процесса продажи банковских продуктов малому и среднему бизнесу, а так же процессов кросс-продаж и развития клиентов розничного бизнеса. Еще на начальном этапе была определена архитектура решения, включая взаимодействие CRM-системы со всеми информационными источниками банка. Для разработки и тестирования были созданы несколько зон, а также были выделены специалисты, хорошо знающие свои информационные системы и бизнес. Совместно с исполнителем работ была выработана технология интеграции и периодичность синхронизации систем. Как результат, бизнес получает в системе актуальную информацию, при этом интеграционные процессы в системе проходят в прозрачном для пользователе режиме.

Также важно отметить, что внедрение проходит поэтапно. Были определены приоритеты в части процессов, автоматизируемых в первую очередь, и затем — в рамках развития.

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


Коментарии: 7

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

  • 25.06.2013 10:30

    Интересно, а в Локо-Банке, при вндрении просто случайно не забыли об этих вопросах или вся прелесть заключалась в применении технологии управления проектами типа PMBOK или специфичные для ИТ методики управления проектами внедрения ИТ систем? Если да, то какие? При определении архитектуры решения, как определялись взаимодействие с существующей ИТ архитектурой и учитывалось влиянияние на ИТ архитектуру и бизнес архитектуру предприятия? Какие методолгии описания архитектуры использовались? Может TOGAF, модель Захмана или BIAN - если мы говорим о банках? И что делает Корус консалтинг, если ИТ архитектура бизнес архитектура не описана в банке? Как в этом случае убедиться, что при вндрении ничего не забыли? Или это опять на воле случая остается?

    • Михаил Петров
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      25.06.2013 19:08

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

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    25.06.2013 19:21

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

  • Максим Потапов
    Рейтинг: 30
    КОРУС Консалтинг
    Руководитель проектов по внедрению Microsoft CRM
    27.06.2013 12:20

    При внедрениях нашего продукта мы используем методологию SureStep, рекомендованную вендором. Сохраняя стадии проекта внедрения системы, мы, опираясь на свой опыт, адаптируем данную методологию под реальные проекты. Относительно методологии описания архитектуры, то действительно не всегда в банке есть описанная по определенному стандарту архитектура, либо это описание находится в зачаточном состоянии и недостаточно для построения решения. В таких случаях совместно с архитекторами и разработчиками описывается схема текущего решения и определяется место новой внедряемой системы. Дальнейшие действия идут по нескольким направлениям. На выходе необходимо получить сформированную архитектуру в нескольких видах – функциональный, структурный, физический, с точки зрения данных, пользователей. Получение этих результатов тоже не является, разумеется, гарантией от ошибок и просчетов, но тем не менее риски снижаются существенно. Так же, уже при планировании интеграции важно учесть основные моменты, которые для многих являются очевидными, но тем не менее часто не делаются. Среди них: учет масштабируемости решения, соблюдение баланса между количеством точек интеграции и количеством полей в существующих точках, реализация детального подробного логирования, учет возможным «узких мест» выбранной технологии интеграции. Что касается второго вопроса, то в первых двух примерах описываются как раз варианты неверного подхода как IT проекту в целом, так и к реализации интеграции. К сожалению, такие случаи встречаются чаще, чем можно было представить, потому об этом важно и нужно говорить. Иногда за реализацию сложных интеграционных проектов берутся компании, которые не имеют должного опыта. Я опущу вопросы относительно получения денежных средств подрядчиками, но, к сожалению, система так и не была запущена в промышленную эксплуатацию. Насчет грамотного подхода, то, безусловно, соглашусь с Вами, что здравый смысл и опыт обеих сторон, имеют немаловажное значение в успешности проекта  Тем не менее, в статье указаны важные пункты, которые даже при наличии здравого смысла и опыта важно соблюдать – прежде всего, это выделение грамотных специалистов, знающих свои системы (причем, как с точки зрения разработки, так и с точки зрения бизнеса, в частности, что, например, является мастер-системой для тех или иных данных) и взаимодействие с бизнес-заказчиками на предмет управления данными для передачи между системами. Дополнительно можно выделить то, что отличает действительно серьезные компании – это написание подробной документации, что позволит, в частности, поддерживать и дополнять решение, а также управление рисками.

    • Михаил Петров Максим
      Рейтинг: 809
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      27.06.2013 14:20

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

    • Максим
      27.06.2013 17:53

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

      • Михаил Петров
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        27.06.2013 18:56

        Интересная статья, спасибо

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.