Неге АБС енгізулерінің 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 и бюджетом, а не только словами
Как двигаться шаг за шагом
- Провести внутренний аудит зрелости банка до выбора вендора — бизнес-процессы, данные, ИТ-команда, регуляторика
- Если зрелость слабая — отложить замену АБС, начать с автоматизации процессов вокруг действующего core (LOS, BPM, данные)
- Если зрелость достаточна — формализовать целевую операционную модель до тендера, а не в его ходе
- Выбирать вендора по соответствию требованиям, а не по бренду и цене
- Назначить сильного внутреннего program manager, не отдавать руководство интегратору
- Декомпозировать проект на управляемые релизы с бизнес-ценностью в каждом, не в финале
- Контролировать данные и миграцию с первого месяца, а не в последнем квартале
- Измерять результат через бизнес-метрики (TAT кредита, объём обработки, уровень ошибок), а не через технические milestones
Тағы нені зерттеу пайдалы
Осы саладағы тақырыптар, біз әдетте бірге қарастырамыз
CRM
Қораптағы CRM емес, клиенттерді басқарудың дұрыс құрылған контуры — бірінші байланыстан адалдыққа дейін.
→ШешімBI
Аналитика — қабырғадағы әдемі графиктер емес. Бұл мәселе шығынға айналмай тұрып 'неге?' сұрағына жауап.
→ШешімБайланыс орталығы
Байланыс орталығы — телефон станциясы емес, клиент сізбен қалу немесе кету шешімін қабылдайтын нүкте. Мәселе — оның ішінде қалай…
→Қалай таңдауКак выбрать АБС
АБС-ке үш тәсілді салыстыру: вендор платформасы, меншікті әзірлеу немесе қолданыстағы ядро айналасындағы басқарылатын қабат. Әр нұсқаның…
→Мен тек жазып қана қоймаймын — келіп, сіздің жағдайыңызды талдап, сіздің контурыңызға арналған шешім жобалаймын.
Қолдануды талқылау →Міндетіңізді талқылауға дайынсыз ба?
Не жұмыс істемейтінін немесе не құру керектігін айтыңыз. Бірінші әңгіме — міндеттемесіз.
Әдетте бірнеше сағат ішінде жауап беремін