Пиджак не застегивается (об интеграции банковских IT)
На портале Bankir.ru опубликованы комментарии нашего первого заместителя генерального директора Сергея Тихомирова об интеграции банковских IT. Часто ли приходится адаптировать промышленное решение к конкретным нуждам банка? Какие проблемы обычно возникают при интеграции различных решений? Сколько времени занимает интеграционный проект и есть ли дефицит интеграторов-профессионалов на рынке труда? Ответы на эти и другие вопросы — в материале «Пиджак не застегивается».
Bankir.ru: Часто ли вам приходится своими силами адаптировать промышленное решение к конкретным нуждам банка? Легко ли это? Есть ли практический и экономический смысл в такой «работе напильником»? Или проще сразу сделать «самописное» решение? Как интегрируются промышленные разработки с «самописными»? и часто ли бывает, когда по заказу бизнес-подразделений банковские «айтишники» работают в авральном режиме, а потом это оказывается не столь нужным и не используется максимально или «микроскопом забиваются гвозди»?
С. Тихомиров: Все зависит от того, что вкладывается в понятие «адаптация». в юридической терминологии под «адаптацией» понимается изменение программного продукта, в ходе которого не возникает нового объекта авторского права.
В обиходном употреблении адаптация может означать как реализацию штатных настроек и нефункциональных требований (например, нагрузочная адаптация), так и существенную доработку (кастомизацию) программного решения, которое может в результате измениться до неузнаваемости. Последнее, по сути, означает создание нового решения, и в этом случае, конечно, целесообразнее сразу разрабатывать его под заказ.
При покупке и внедрении промышленного решения нужно четко понимать его возможности и ограничения, ведь доработка такого программного продукта может обойтись банку очень дорого. к проектам по реализации изменений, затрагивающих архитектуру решения, лучше всего привлекать самого вендора (создателя системы) или его партнеров. Но возможны ситуации, когда доработка промышленного решения реализуется силами инхауса: например, если банк делает ставку на развитие внутреннего IT-подразделения и не хочет брать на себя риски взаимодействия со сторонними подрядчиками.
Что касается интеграции промышленных разработок с «самописными», то здесь нет никаких особенностей: в какую систему легче внести изменения, необходимые для интеграции, — ту и меняем. Естественно, в большинстве случаев проще всего доработать инхаусную систему.
Наличие или отсутствие «ненужных» доработок (как и любых других изменений) зависит в первую очередь от зрелости организации (банка) — в частности, от того, насколько эффективно в ней выстроен процесс управления изменениями.
Bankir.ru: Сейчас рынок заказчика и время построения компонентной архитектуры — у кого-то с нуля, у кого-то — «смесь бульдога с носорогом». Насколько для интеграции IT-решений от разных поставщиков характерна поговорка «К качеству пуговиц претензий нет, но пиджак не застегивается»? Какие проблемы обычно возникают при интеграции? Есть ли контакт и уступки разработчиков при решении интеграционных проблем отдельного банка-заказчика?
С. Тихомиров: Пока построение компонентной архитектуры — это новое веяние, и у нас нет информации о хоть сколько-нибудь значимом числе кредитных организаций, успешно завершивших этот процесс.
В целом возможны два подхода к реализации такого масштабного проекта, как переход к компонентному принципу построения IT-ландшафта. Первый — это когда есть продуманная стратегия интеграции и план проектов по ее реализации. Второй — когда банк не берет в расчет стратегические цели, а просто стремится уменьшить «интеграционный зоопарк». в этом случае концепция внедрения чаще всего отсутствует, а эффективность проекта зависит от того, насколько плохо дела обстояли до этого, — например, ситуация может улучшиться просто за счет нефункциональных свойств новой среды.
Если под «пуговицами» понимать компоненты, а под «пиджаком» — IT-ландшафт в целом, то в случае стихийного внедрения без концепции и плана никто не отвечает за качество этого самого «целого».
Налаживание эффективного взаимодействия между заказчиком и подрядчиком — актуальный вопрос не только для банков и не только для интеграционных проектов, а для всей сферы IT-услуг. Все зависит от взаимной заинтересованности и умения работать в модели партнерства, основанной на равенстве обеих сторон, доверии и уважении.
Bankir.ru: Имеет ли банк собственных интеграторов в штате или использует только аутсорсинг? Если в команде есть и штатные интеграторы и приглашенные, то не возникает ли конфликта интересов? Сколько времени занимает интеграционный проект и «выживает» ли при этом команда или в процессе может замениться? Чувствуется ли дефицит интеграторов-профессионалов на рынке труда?
С. Тихомиров: Интеграционный проект — не инфраструктурный, а ключевой для банка. Поэтому такого, чтобы в банке вообще не было собственных специалистов по интеграции, я не видел. Это слишком рискованно — полностью полагаться на аутсорсинг, чаще всего такие проекты отдаются на частичный внешний подряд.
Наличие конфликтов интересов, опять-таки, зависит от зрелости процессов управления: если организации нет, в проекте царит хаос, то может возникнуть и конфликт интересов, и вообще что угодно, и объем последствий будет пропорционален масштабу затеянных изменений.
Конечно, это длительные проекты, ведь они подразумевают изменение информационной архитектуры банка и отдельных компонентов IT-ландшафта. Риск, что команда распадется, уйдет и заберет с собой ключевые знания и компетенции, — самый серьезный, и банки обычно делают все, чтобы этого не случилось.
Профессионалов в принципе не хватает, и это касается не только интеграторов и даже не только IT-сферы, но и всего рынка труда.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».