Нова АБС
Публікації
Про причини, що змушують банки змінювати АБС, про взаємини банкірів з розробниками та про ітераційний підхід до впровадження великих ІТ-систем.
Ганна ЧорнобильськаКерівник Управління маркетингу компанії «ПрограмБанк»
Ганна Чорнобильська: Змінити АБС – це не одна пожежа, а цілих дві пожежі. Тому, зазвичай, причин зміни системи не одна, а кілька. Існують різні сценарії зміни АБС.
Найбільш логічний – коли банк «виростає» із існуючого рішення. Як правило, це пов'язано із застарілою архітектурою. Непромислова СУБД, не підтримується централізована робота, немає документообігу, закритого рішення, застарілий інтерфейс, і.т.д.
У цій ситуації зміна АБС необхідна і ціна переходу тим вища, чим більше банк затягує неприємне рішення. Тому що якщо АБС вже почала «тиснути» банку, це означає, що банк зростає. Це, звісно, гарна новина. Але. Зростання означає дедалі більше завдань ІТ, паралельно проблеми з АБС продовжують накопичуватися. Частина завдань реалізується банком самостійно, причому ці рішення розглядаються ІТ-службою як тимчасові, що, звісно, впливає їх якість.
В результаті, до моменту, коли банк ухвалить рішення про впровадження нової АБС, накопичиться безліч проблем – від невдоволення користувачів до значної кількості недокументованих змін до поточної АБС. В результаті як вибір АБС, так і саме використання проходять в умовах цейтноту. Іноді проблеми, пов'язані із цим, можна мінімізувати. Але зазвичай така екстремальна заміна АБС веде до збитків банку. Найприкріше, що часто можливості, закладені в новому рішенні, банк не може через такий «зім'ятий»Використання.
Зміна АБС через низьку якість підтримки практично не зустрічається. Незадовільна підтримка може бути додатковим фактором, який прискорює прийняття рішення, але не більше. Трапляються випадки заміни АБС при неадекватній ціновій політиці розробника, якщо зміна АБС виявляється дешевшою за річний супровід поточним постачальником. Але таких випадків все ж таки небагато.
А ось те, чи буде банк змінювати при зміні АБС і розробника – це якраз залежить від якості підтримки. Тільки це не просто «якість підтримки», а партнерські відносини з клієнтом, як не замилено це слово.
Чи реалізує компанія безкоштовно заявки своїх клієнтів чи чекає, доки хтось не витримає та заплатить? Як поводиться, якщо починаються проблеми з ІТ-рішенням (як правило, незрозуміло, з чиєї вини)? Чи вміє шукати оптимальне рішення у тому випадку, коли бізнес-підрозділи банку та ІТ не можуть домовитися? Чи може надати індивідуальне обслуговування кожному банку – а «індивідуальне» - це саме таке, якого банк потребує? Наскільки швидко розробник розвиває функціональність АБС, що використовується банком, чи основні інвестиції спрямовуються в нове рішення, на якому можна більше заробити за рахунок переведення клієнтів на нові версії?
Ось увесь цей спектр питань можна поєднати єдиним терміном «партнерські відносини». Якщо банк сприймає розробника як партнера, а чи не як грабіжника з великої дороги. Якщо розробник сприймає банк як партнера, а не як дійну корову, якій нема куди подітися з підводного човна. Тоді при зміні АБС нове рішення поточного постачальника матиме безперечний пріоритет перед іншими варіантами.
АБЖ: Чи може банк відкласти перехід на нову систему «до кращих часів»? Чи можерозробник допомогти з цим банку?
Ганна Чорнобильська: Відстрочити зміну АБС досить часто можна досить легко. Як правило, є гострі проблеми, що накопичилися, їх можна оперативно вирішити (безкоштовно або за символічну ціну). Більше того, ці проблеми, швидше за все, мучать і інших клієнтів, тому розробнику це в будь-якому разі варто зробити. Багато вендори не вживають цих мінімальних заходів рівно тому, що їм вигідніше фокусуватися на великих клієнтах, де зовсім інші цифри доходів. Дрібні та середні банки обслуговуються за залишковим принципом - їх запити на доопрацювання реалізуються в останню чергу, роботи в них виконують найменш досвідчені співробітники та ін.
Але розглянемо вендора, який дбає про кожного свого клієнта. Вирішити проблему з поточною АБС, як правило, цілком реально і навіть не дуже трудомістко. Реалізувати найбільш потрібні доопрацювання, змінити індивідуального менеджера, знизити ціну супроводу. У більш серйозних випадках необхідно провести комплексний аудит, налаштувати в АБС правильний документообіг, додати необхідні звіти, зіштовхувати із зовнішніми рішеннями - і вона запрацює «як нова», а питання про зміну зніметься з порядку денного. Найчастіше такий сценарій «ви просто не вмієте правильно використовувати наше рішення», трапляється при зміні ІТ-команди банку.
Але в багатьох інших випадках зміна АБС необхідна, і, як було викладено вище, якщо банк об'єктивно виріс із рішення, що використовується, то не варто затягувати питання з його заміною.
Питання в тому, як організувати і провести ту саму зміну АБС. Якщо між банком та ІТ-компанією налагоджено партнерство, про яке сказано вище, то вони зможуть дійти рішення спільно: який оптимальний час для заміни АБС, початиіз заміни ядра чи окремих блоків, як підготуватися до зміни АБС тощо.
Однак у житті часто виходить інакше. Банк (обґрунтовано) не вірить розробнику і за наявності проблем тишком-нишком починає шукати інше рішення, а розробник дізнається про зміну АБС тільки після отримання листа, що клієнт відмовляється від супроводу, оскільки вже змінив систему. Розробнику це, зрозуміло, невигідно, але й банку не завжди.
Але якщо банк обирає нову АБС того ж постачальника, то виникають інші проблеми – цього разу лише у вендора. На компанію лягає дуже серйозна відповідальність – насамперед за те, що нова АБС ні в чому не поступатиметься попередньою і при цьому вирішуватиме левову частину всіх тих проблем, через які, власне, банк і пішов на зміну рішення.
Щодо фінансового аспекту зміни АБС, то все залежить від політики постачальника. Наша компанія гарантує всім своїм клієнтам збереження всіх інвестицій, вкладених у минулу АБС, відповідно такі впровадження набагато менш прибуткові, ніж запуск рішення у нового клієнта. Але «ПрограмБанк» упевнений, що у довгостроковій перспективі вигідно вкладати у лояльність клієнта. Зрозуміло, що думки різних компаній із цього питання можуть розходитися.
АБЖ: Наскільки довго банк може працювати на старій системі?
Ганна Чорнобильська: Стандарти ринку щодо терміну життя рішення змінюються з часом. Ще 10 років тому формулювалося, що "АБС живе п'ять років". Але це тому, що у 90-ті середній термін переходу був місяць-два, перехід, як правило, був тиражним – і це був «хвіст ілюзій» 90-х. Зараз, думаю, кожен банк, змінюючи рішення, планує використовувати його, як мінімум, протягом 10 років.
Вихід для розробника у тому, щоб, створюючи нову АБС,використовувати всі технології, що є на даний момент. Наприклад, нашій АБС "Гефест" 15 років. Але вона створювалася на найсучасніших технологіях того часу (централізована архітектура, документообіг, що налаштовується, повністю відкритий код та інші). Завдяки цьому більшість клієнтів «Гефесту», які перейшли на неї 12-13 років тому, не потребують зміни АБС.
Хоча деяким з них вже потрібні технології нового покоління (ергономічний інтерфейс, що налаштовується, поділ прикладного і системного коду, занурення в дані при формуванні звітності і т.д.). Ці технології реалізовані в АБС "Центавр Омега", рішенні нового покоління, яке використовує вже понад 30 банків. Тому, коли нашим клієнтам «Гефесту» знадобиться таке рішення, вони зможуть перейти на нього з мінімальними витратами та складнощами.
АБЖ:Чи не простіше замість повної заміни АБС купити та впровадити невелике рішення з необхідним функціоналом?
Ганна Чорнобильська: Питання у тому, якому банку простіше. p align="justify"> Для формування багатьох форм звітності для Центрального банку (наприклад, 128, 129, 135, 302 форми) потрібна інформація з різних напрямів діяльності банку: і по кредитних договорах, і по операціях з цінними паперами, і по операціях з пластиковими картками. А питання з регламентованою звітністю, з урахуванням поточної ситуації, досить критичне для будь-якого банку. Великі банки для формування регламентованої звітності використовують спеціалізовані Сховища даних, куди вони завантажують інформацію з різних ІТ-рішень. І тут підхід best of breed виправданий.
Але такий вибір потребує не лише значних інвестицій на побудову Сховища. Набагато складніше підтримувати формування у регламентованій звітності у побудованомуСховище. Якщо звітність для ЦП формується в АБС, то підтримка всіх змін - біль голови постачальника. Оперативно реалізовувати всі зміни при формуванні звітності у Сховищі набагато складніше. Невипадково переважна більшість банків, які використовують Сховище даних, формує там саме управлінську звітність.
В іншому банку здійснювався поетапний перехід на АБС різними філіями банку. І тому ми створили спеціалізований шлюз, що дозволяє формувати зведену звітність, використовуючи частину даних з іншого АБС. Є банки, в яких спочатку було впроваджено певний бек-офіс, це дозволяє банку оцінити нас як постачальника перед прийняттям глобальних рішень.
АБЖ: Стандартний підхід до впровадження ІТ-систем передбачає проведення обстеження, розробку ТЗ, і погано працює в компаніях, що швидко змінюються. Як знизити ризики впровадження у сучасному динамічному світі?
Ганна Чорнобильська: Каскадне впровадження передбачає спочатку створення детально опрацьованого ТЗ, потім його погодження із замовником, а потім, власне, роботи у повній відповідності до створеного документа. Такий підхід має свої переваги. Він формалізує, що отримає на виході клієнт та скільки він за це заплатить розробнику.
Але в останні роки різко змінилася мобільність усіх галузей бізнесу, і банки не є винятком. А це означає, що на момент закінчення впровадження ТЗ банально застаріває, і в результаті банк отримує зовсім не те, що хотів, хоча рішення формально відповідає ТЗ. Крім цього, зростають вимоги користувачів, їм уже потрібне не тільки рішення, що відповідає бізнес-процесам, а й зручне, а сформулювати це заздалегідь у ТЗ далеко не завжди можливо.
Виходом для багатьох ІТ-компаній стали Agile-технології. Цеозначає, що у впровадженні використовується прототипування, і за кілька ітерацій підрозділи банку практично здійснюють приймання бізнес-процесів. Потім здійснюється приймання наскрізних бізнес-процесів вже на рівні банку. Це дозволяє уникнути відразу двох бід: і те, що ТЗ застаріє за час впровадження, і того, що замовники системи просто не можуть сформулювати свої детальні вимоги у форматі ТЗ. Більшість впроваджень ми реалізуємо саме в рамках Agile-підходу, або інакше кажучи, ітераційного впровадження.
Зрозуміло, що у великих та найбільших банках (наприклад, ВТБ чи НКЦ) ми виконуємо впровадження каскадним способом на основі деталізованого ТЗ. Там зовсім інший рівень формалізації та документування бізнес-процесів та більш централізована система управління.
Але в деяких ситуаціях Agile-підхід можна застосувати і для великих банків. Коли йдеться про управлінські рішення, важливо щоб бізнес досить швидко отримав конкретний бізнес-результат. Це дає стимул до подальших інвестицій у рішення (не лише фінансових).
Такий підхід ми використовували при впровадженні системи централізованого управління бізнесу у фінансових групах "Ренесанс Груп" та "ВТБ Капітал". На першому етапі була побудована система оцінки фінансових результатів різних підрозділів. Практичний результат дозволив надалі розвивати рішення у різних напрямках (можливість переходу до детальних даних, нові аналітичні розрізи, Score-Card для менеджменту).
Думаю, зараз така технологія є актуальною і для CRM-систем. Спочатку окремий блок з конкретною віддачею для бізнесу (переважно це кредитний конвеєр), потім поетапне використання комплексного CRM-рішення (зазвичай, паралельно з використання CRM-підходу в банку).
Практика більшедесятка наших останніх проектів показує, що ітераційний підхід можна застосувати для більшості банків. Насамперед, він дозволяє швидко реалізовувати проекти. Наприклад, цього року "Фреско-банк" перейшов на АБС "Центавр Омега" за 4 тижні. У минулому впровадження в КБ «Радіан» та НКО «Яндекс-гроші» вимагали лише по 2 місяці на виконання.