Самописное ПО в банках: шансы остаются?
Вопрос о самописном банковском ПО сохранится, похоже, на повестке дня до тех пор, пока на рынке будут оставаться небольшие банки. Традиционно многие из банков использовали собственные, изготовленные в соответствии со специфическими техническими требованиями информационные системы. Однако в условиях ужесточения конкуренции, снижения маржи, централизации рынка, банки все больше склоняются к переходу на стандартные управленческие решения. Веяния времени не обошли и Центральный банк России. «В ЦБ существует три важнейших ветви решаемых задач: учетно-оперативные, информационно-аналитические и хозяйственные», — отмечает Сергей Михайлов, заместитель директора департамента информационных систем ЦБ. Ранее для этого использовались десять систем, причем только одна из них не была «самописной». К настоящему времени выбраны две учетно-оперативные системы и начат переход на них. При этом число центров обработки данных сократится с 78 до 2. Эффективность применяемых технологий во многом определяет эффективность бизнеса в целом. Но выбор новой системы нелегок. При детальном изучении функционала становится очевидным, что предлагаемая система, возможно, не полностью отвечает потребностям банка. Естественно, встает вопрос о доработке продукта. Вообще, выбор стратегии информатизации — результат длительного согласования, с элементами внутрибанковского лоббирования, преодолением явного или скрытого сопротивления со стороны разработчиков программного обеспечения, использовавшегося в банке ранее. По данным ОТР, 20% российских банков из Топ50 до сих пор используют АБС собственной разработки. По тем же оценкам решение о смене системы автоматизации оперативной деятельности в 2005 году приняли 19 банков из Топ50. При этом выбор в пользу АБС собственной разработки предпочли всего 5%. С другой стороны, очевидно, что если анализировать не 50, а 200 банков, то распределение будет иными. Доводы ПРОТИВ самописных решений Банковские разработчики и разработчики промышленных решений ведут спор о выборе между этими двумя видами ПО. Каковы же доводы «против»? Прежде всего — фактор времени. Разработка «своего» решения нестабильна по срокам. Далее, процесс тестирования разрабатываемой самописной системы — тяжелый период для банка, бывают ситуации, когда отступать некуда, а АБС не работает (или работает не так, что то же самое). Если же взять софтверную компанию, то у нее масса тестировочных площадок, на которых АБС, прежде чем она будет одобрена и запущена в продажу, может «кататься» довольно долгое время, не мешая производственному процессу банка. Фактор опыта. Производителю АБС проще наработать базу ошибок, проще выпустить изменения и проще их протестировать. Самостоятельные решения упускают отдельные элементы функциональности, также присутствует негибкость настроек, «зашоренность» разработчиков. Работая «в своём кругу» долгие годы, люди неизбежно ограничивают себя опытом только своего банка. Зачастую встречается откровенное самолюбование. У сторонних разработчиков тоже «гонора хватает», однако они имеют больше возможностей для получения полезного опыта из разных кредитных организаций. Для создания системы и ее поддержки в рабочем состоянии приходится содержать большой штат ИT-службы. Рано или поздно зафиксированная сборка полностью устаревает морально (или ЦБ вносит какие-то изменения, требующие принципиальной переработки и смены текущего ПО и БД). В случае собственной разработки банку требуется держать на подобный случай постоянный штат программистов, платить им зарплату и занимать подсобными работами, чтобы в будущем не оказаться у разбитого корыта. Поскольку полноценно сопровождать систему и, тем более, дорабатывать ее могут только разработчики. При этом уход специалиста приводит к миграции выработанных идей и плагиату со стороны конкурентов. Минус собственной разработки — невозможность создания масштабируемого софта, построенного с учетом развития бизнеса. Самописное приложение трудно масштабировать в силу технических причин, а логика его работы понятна только его создателю. На первый взгляд, разработка системы силами ИТ-департамента банка дешевле. Однако со временем «самописный» продукт может стать убыточным. Главный же плюс и одновременно минус собственной разработки состоит в том, что она не нарушает сложившиеся бизнес-процессы. Ведь зачастую за счет внедрения типовой системы банк желает оптимизировать существующее положение вещей, получить квинтэссенцию лучшего опыта. Доводы ЗА самостоятельные решения Банки, как наиболее щепетильные в вопросах информационной безопасности структуры, крайне неохотно допускают к своим системам посторонних. И это, кстати, чуть ли не единственное ограничение, которое сдерживает рост рынка аутсорсинга сегодня. Разработчики банковского ПО считают, что самостоятельные решения — это почти идеальная адаптация АБС к условиям банка. Кроме того, они обеспечивают оперативное решение проблем, связанных с изменением инструкций ЦБ, отчетности и т.д. Пользователи получают грамотную консультацию "из первых рук". Создание системы силами ИТ-департамента банка, как правило, обходится дешевле. Если банк предоставляет клиентам полный набор банковских услуг, то ни одна покупная система не обеспечивает комплексного подхода к автоматизации всего их спектра, который весьма обширен. Причем все недостатки самописных систем, включая риски, присутствуют и во "внешних" системах. Однако борьба с негативными последствиями этих недостатков отнимает гораздо меньше времени и денег, когда АБС своя, родная. Если решение не самое дорогое, банк обречен на постоянное сопровождение своими силами, «дописывание» кусков, после чего в итоге от базовой системы мало что остается. Не стоит эксплуатировать полностью закрытую от изменений систему, от которой зависит весь бизнес, и в которой мало что понятно. Приобретя систему, необходимо изучить ее, обязательно потребовав у разработчиков возможность вмешиваться в любые участки ее работы. Важно само наличие этой возможности — реализовывать ее не обязательно. Хотя в какой-то момент может понадобиться. Как решить дилемму? Достаточно однозначным ответом на вопрос, какое ПО лучше, может стать тот довод, что банк в первую очередь оказывает финансовые услуги, а не создает софт. По мнению аналитиков Gartner, эффективность ИТ-службы организации зависит от систем, инфраструктуры, процессов, людей и взаимодействия с бизнесом. ИТ-служба занимается предоставлением ИТ-услуг бизнесу, а не собственно автоматизированной банковской системой (АБС). Крупные банки осознали это раньше. Мелкие и средние банки тоже пришли к этому выводу, однако для них ситуация упирается в цену и качество. Какие пути существуют для улучшения качества банковского ПО - в том числе недорогих решений, которые устраивали бы мелкие и средние банки? Программисты, разрабатывающие ПО «внутри» банка, предлагают: «Купить и доработать». Но тут возникают вопросы: позволяет ли система себя дорабатывать, насколько она открыта и имеются ли документы, предназначенные банковским программистам, то есть готов ли разработчик предоставить такую возможность. Программисту нужен базовый открытый инструментарий плюс открытые функциональные модули с готовой структурой данных и технологией работы, которые он мог бы при необходимости корректировать или же переписывать заново. И на отечественном рынке банковского ПО существуют продукты, которые под девизом «Есть универсальные банки, нет универсальных систем» предоставляют клиенту не только исполняемые модули, но и исходные коды своей системы. Например, компания БИС. Еще один путь — это ПО, разработанное софтверной компанией под спецзаказ. Принципиальное отличие заказных разработок ПО от тиражных: программа изменяется под клиента, а не клиент под программу. Фактически эта разработка — тоже проект доработки, а не создания системы «с нуля», но стартовые позиции и затрачиваемые ресурсы такой доработки совершенно иные, чем в случае тиражных «коробочных» систем. Нечто новое и глобальное в этом вопросе — инструментарий BPI (Business Process Insight), включенный в новую технологию с названием «динамические ИТ»: позволяет управлять ИТ-сервисами в интересах бизнеса в соответствии с подходом, называемым «управление бизнес-сервисами» (Business Service Management, BSM). Опыт использования BPI в «Альфа-банке» показал, что продукты класса BSM позволяют осуществлять проактивный мониторинг бизнес-процессов и ИТ-конфигураций силами операторов, а не экспертов, выполнять регистрацию и автоматическую эскалацию проблем, отлаживать новые бизнес-процессы. Многие крупные западные банки прошли эволюционный путь: сначала создали систему силами собственных разработчиков, затем приобрели «тяжелый» комплексный продукт. Замена или модернизация самописного банковского ПО постепенно становится ключевым процессом для большинства юго-восточных банков. Инвестиции в это направление уже идут. Цель — обеспечить долгосрочный рост организаций, а также стимулировать в их среде новые крупные проекты, задействующие значительные ресурсы. В России же пока остается довольно много банков, использующих системы собственной разработки. В тех из них, где внедряют готовые решения, в ходе эксплуатации системы ИТ-специалисты получают колоссальный опыт. Со временем, убедившись, что не все, что заложено в комплексную систему, устраивает банк, они начинают ее переделывать, используя собственные разработки и продукты других поставщиков. В конце концов, создается качественно иная система, рассчитанная на нужды конкретного банка. Елена Турдакина / CNews Analytics |
