Пиджак не застегивается (об интеграции банковских IT)

На портале Bankir.ru опубликованы комментарии нашего первого заместителя генерального директора Сергея Тихомирова об интеграции банковских IT. Часто ли приходится адаптировать промышленное решение к конкретным нуждам банка? Какие проблемы обычно возникают при интеграции различных решений? Сколько времени занимает интеграционный проект и есть ли дефицит интеграторов-профессионалов на рынке труда? Ответы на эти и другие вопросы — в материале «Пиджак не застегивается».

Bankir.ru: Часто ли вам приходится своими силами адаптировать промышленное решение к конкретным нуждам банка? Легко ли это? Есть ли практический и экономический смысл в такой «работе напильником»? Или проще сразу сделать «самописное» решение? Как интегрируются промышленные разработки с «самописными»? и часто ли бывает, когда по заказу бизнес-подразделений банковские «айтишники» работают в авральном режиме, а потом это оказывается не столь нужным и не используется максимально или «микроскопом забиваются гвозди»?

С. Тихомиров: Все зависит от того, что вкладывается в понятие «адаптация». в юридической терминологии под «адаптацией» понимается изменение программного продукта, в ходе которого не возникает нового объекта авторского права.

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

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

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

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

Bankir.ru: Сейчас рынок заказчика и время построения компонентной архитектуры — у кого-то с нуля, у кого-то — «смесь бульдога с носорогом». Насколько для интеграции IT-решений от разных поставщиков характерна поговорка «К качеству пуговиц претензий нет, но пиджак не застегивается»? Какие проблемы обычно возникают при интеграции? Есть ли контакт и уступки разработчиков при решении интеграционных проблем отдельного банка-заказчика?

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

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

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

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

Bankir.ru: Имеет ли банк собственных интеграторов в штате или использует только аутсорсинг? Если в команде есть и штатные интеграторы и приглашенные, то не возникает ли конфликта интересов? Сколько времени занимает интеграционный проект и «выживает» ли при этом команда или в процессе может замениться? Чувствуется ли дефицит интеграторов-профессионалов на рынке труда?

С. Тихомиров: Интеграционный проект — не инфраструктурный, а ключевой для банка. Поэтому такого, чтобы в банке вообще не было собственных специалистов по интеграции, я не видел. Это слишком рискованно — полностью полагаться на аутсорсинг, чаще всего такие проекты отдаются на частичный внешний подряд.

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

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

Профессионалов в принципе не хватает, и это касается не только интеграторов и даже не только IT-сферы, но и всего рынка труда.

---

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Пиджак не застегивается (об интеграции банковских IT)»