Разборы

Почему 40% внедрений АБС проваливаются — и как не попасть в статистику

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

Обсудить задачу

Это не редкость — это норма

40% провалов — это не мрачная статистика, это описание нормы в регионе. Публичные кейсы редки: банки не любят признавать неудачи, интеграторы переобувают их в «успешные проекты с корректировкой скоупа». Но если собрать анекдотические данные по СНГ и Центральной Азии за последние 10 лет, картина проясняется — каждый третий-четвёртый проект замены АБС заканчивается либо далеко от первоначального плана, либо откатом.

Корневая причина общая — зрелость банка, а не вендор

Все шесть системных причин провалов сходятся к одному: банк принимает решение о замене АБС из слабости, а не из силы. Слабость проявляется в том, что продуктовая политика не формализована, данные грязные, ИТ-команда не способна управлять проектом, а бизнес перекладывает ответственность на ИТ. В такой ситуации любая АБС — хоть Temenos, хоть самодельная — упрётся в те же стены.

Что реально работает

Правильный порядок обратный тому, что обычно делают банки. Сначала — навести порядок вокруг действующего ядра: автоматизировать процессы, очистить данные, формализовать продукты, выстроить управляемость. Это занимает 6-18 месяцев и даёт 60-70% целевого эффекта. Только после этого можно осмысленно планировать замену ядра, если она всё ещё нужна — а часто оказывается, что не нужна.

CTA

Если проект замены АБС уже запущен и идёт со срывом — стоит остановить и провести независимый аудит. Если только обсуждается — правильный первый шаг это аудит зрелости банка, а не запрос предложений у вендоров.

Как это проявляется в жизни

Банк подписывает контракт на замену АБС за $10-50 млн, назначает сроки 18-36 месяцев, начинает проект с амбицией. Через полтора года — просрочка первого релиза, пересмотр бюджета на 30-50%, конфликты с интегратором, часть функциональности не покрывает реальные сценарии, а когда дело доходит до миграции данных, обнаруживается что справочники дублируются, а кредитные продукты описаны по-разному в разных системах. В худших случаях банк возвращается к старой АБС и списывает бюджет на убытки.

Почему так получается

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

Что обычно пробуют — и почему это не помогает

Выбрать «проверенного вендора» — будто бренд снимает риск. Не снимает: рынок СНГ и ЦА полон историй сорванных внедрений Temenos, Oracle, Diasoft
Нанять «сильного интегратора» — но интегратор не заменит отсутствующей внутренней ответственности и слабой постановки задачи
Пойти в методологию Agile — хотя АБС по природе каскадный проект с длинными зависимостями, и «гибкость» без базовой дисциплины усугубляет проблему
Урезать scope до «MVP АБС» — не работает: банковское ядро либо закрывает минимум регуляторики и учёта, либо нет, промежутка не существует
Сменить интегратора в середине проекта — почти всегда хуже чем довести с текущим до конца и разобрать причины провала после

Что реально нужно

Никакой волшебной формулы нет, но есть способ снизить риск провала с 40%+ до 10-15%. Он начинается не с выбора платформы, а с честного внутреннего аудита: насколько формализована продуктовая политика, насколько зрелая ИТ-команда, насколько чистые данные, кто реально отвечает за результат — бизнес или ИТ. Если хотя бы два из четырёх ответов «слабо», замена АБС преждевременна. Правильный шаг — сначала собрать минимальную управляемость вокруг действующего ядра через wrap-слой и автоматизацию процессов, а потом уже планировать замену ядра с позиции силы, а не хаоса.

Что проверить до старта

Формализованы ли продуктовые правила — или они живут в головах сотрудников
Есть ли внутренний product owner по каждому направлению (розница, корпоративный, МСБ, казначейство)
Какая реальная зрелость ИТ-команды — может ли она держать вендора, а не быть заложником
Состояние справочников и мастер-данных — клиенты, продукты, контрагенты, счета
Формализованная кредитная политика и decision flow по продуктам
Готовность регуляторной отчётности ЦБ РУ и IFRS 9 процессов
Поддержка проекта топ-менеджментом измерима KPI и бюджетом, а не только словами

Как двигаться шаг за шагом

Провести внутренний аудит зрелости банка до выбора вендора — бизнес-процессы, данные, ИТ-команда, регуляторика
Если зрелость слабая — отложить замену АБС, начать с автоматизации процессов вокруг действующего core (LOS, BPM, данные)
Если зрелость достаточна — формализовать целевую операционную модель до тендера, а не в его ходе
Выбирать вендора по соответствию требованиям, а не по бренду и цене
Назначить сильного внутреннего program manager, не отдавать руководство интегратору
Декомпозировать проект на управляемые релизы с бизнес-ценностью в каждом, не в финале
Контролировать данные и миграцию с первого месяца, а не в последнем квартале
Измерять результат через бизнес-метрики (TAT кредита, объём обработки, уровень ошибок), а не через технические milestones

→

Что ещё стоит изучить

Темы из этой же области, которые часто разбираем вместе с этой

Решение

Это не только статьи

Об этом не просто пишу — могу прийти, разобрать вашу ситуацию и спроектировать решение под ваш контур.

Обсудить применение →

← Назад

Готовы обсудить вашу задачу?

Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.

Обсудить задачу Написать в Telegram

Обычно отвечаю в течение нескольких часов