Талдоолор

Эмне үчүн АБС киргизүүлөрүнүн 40% ийгиликсиз аякталат

Адистердин баасы боюнча, Борбордук Азия жана КМШда АБС долбоорлорунун 40%тен ашуунусу ийгиликсиз. Алты системалык себеп.

Тапшырманы талкуулоо

Бул сейрек эмес — бул норма

40% ийгиликсиздик региондук норма. Жалпыга маалым учурлар сейрек: банктар ийгиликсиздиктерди моюнга алууну жактырышпайт, интеграторлор аны “скоупу түзөтүлгөн ийгиликтүү долбоорлор” катары көрсөтүшөт. Бирок акыркы 10 жыл ичинде КМШ менен Борбордук Азия боюнча анекдоттук маалыматтар чогултулса, көрүнүш ачык болот — ар үчүнчү же төртүнчү ядро алмаштыруу долбоору же баштапкы пландан алыс аяктайт же кайра кайтарылат.

Негизги себеп жалпы — банк жетилүүсүндө, вендордо эмес

Бардык алты системалуу ийгиликсиздик себеби бирөөгө келет: банк ядрону күчтөн эмес, алсыздыктан алмаштырууга чечим кабыл алат. Алсыздык продукт саясаты расмийлештирилбегенде, маалыматтар кир болгондо, IT-команда долбоорду башкара албаганда жана бизнес жоопкерчиликти IT-ге өткөргөндө көрүнөт. Мындай абалда кандайдыр бир ядро — 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 и бюджетом, а не только словами

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

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

Тапшырмаңызды талкуулоого даярсызбы?

Эмне иштебей жатканын же эмне куруу керектигин айтыңыз. Биринчи сүйлөшүү — милдеттемесиз.

Адатта бир нече сааттын ичинде жооп берем

Тапшырманы талкуулоо
Ыңгайлуу байланыш ыкмасын тандаңыз
Telegram
Тез жооп
Тез
WhatsApp
Yнy жана документтер
📞
Чалуу
+998 99 838-11-88