Нов ABS
За причините, принуждаващи банките да променят ABS, за връзката на банкерите с разработчиците и за итеративен подход към внедряването на големи ИТ системи.
Анна Чернобилская
Ръководител отдел маркетинг
на фирма "ProgramBank"
Анна Чернобилская: Смяната на ABS не е един пожар, а цели два пожара. Следователно, като правило, има не една, а няколко причини за промяна на системата.
Има различни сценарии за смяна на ABS.
Най-логично е, когато банката "израства" от съществуващо решение. Обикновено това се дължи на наследената архитектура. Неиндустриална СУБД, централизирана работа не се поддържа, няма персонализиран работен поток, затворено решение, остарял интерфейс и т.н.
В тази ситуация е необходима смяната на ABS и цената на прехода е колкото по-висока, толкова повече банката забавя неприятното решение. Защото, ако АБС вече е започнал да „жъне” банката, това означава, че банката се разраства. Това е добра новина, разбира се. Но. Растежът означава все повече предизвикателства за ИТ, докато проблемите с ABS продължават да се натрупват. Някои от задачите се изпълняват от банката самостоятелно и тези решения се разглеждат от ИТ услугата като временни, което, разбира се, се отразява на тяхното качество.
В резултат на това, докато банката реши да въведе нов ABS, се натрупаха много проблеми - от недоволството на потребителите до значителен брой недокументирани промени в настоящия ABS. В резултат както изборът на ABS, така и самото изпълнение се извършват под натиск на времето. Понякога проблемите, свързани с това, могат да бъдат сведени до минимум. Но обикновено такава екстремна подмяна на ABS води до загуби за банката. Най-досадното е, че често възможностите, присъщи на новото решение, банката не може да използва поради такова "смачкано" изпълнение.
На практика няма промяна на ABS поради лошото качество на поддръжката. Лошата подкрепа може да бъде допълнителен фактор за ускоряване на вземането на решения, но нищо повече. Има случаи на подмяна на ABS с неадекватна ценова политика на разработчика, ако промяната на ABS е по-евтина от годишната поддръжка от настоящия доставчик. Но такива случаи все още са малко.
Но дали банката ще се промени при смяна на ABS и разработчика - това зависи само от качеството на поддръжката. Само че това не е просто "качество на поддръжката", а партньорство с клиента, независимо колко размита е тази дума.
Прилага ли компанията безплатно приложенията на своите клиенти или чака някой да се изправи и да плати? Как се държи, ако проблемите започват с ИТ решение (като правило не е ясно чия е вината)? Знае ли той как да търси оптималното решение в случая, когато бизнес единиците на банката и ИТ не могат да се споразумеят? Може ли да предостави индивидуална услуга на всяка банка - а „физическото лице“ е точно това, от което се нуждае банката? Колко бързо разработчикът разработва функционалността на ABS, използвана от банката, или основните инвестиции са насочени към ново решение, на което можете да спечелите повече, като прехвърлите клиенти в нови версии?
Цялата тази гама от въпроси може да бъде обединена от един термин „партньорство“. Ако банката възприема предприемача като партньор, а не като магистрален грабител. Ако разработчикът възприема банката като партньор, а не като крава за пари, която няма къде да отиде от подводницата. Тогава, при смяна на ABS, новото решение на настоящия доставчик ще има безусловен приоритет пред другите опции.
ABJ: Може ли банката да отложи прехода към новата система „до по-добри времена“? Може ли разработчикът да помогне на банката с това?
Анна Чернобилская: Доста е лесно да се забави смяната на ABS. Като правило има натрупани най-остри проблеми, които могат бързо да бъдат разрешени (безплатно или на символична цена). Освен това тези проблеми вероятно ще измъчват и други клиенти, така че разработчикът трябваше да го направи все пак. Много доставчици не предприемат тези минимални мерки именно защото им е по-изгодно да се фокусират върху големи клиенти, където цифрите на доходите са напълно различни. Малките и средните банки се обслужват по остатъчен начин - техните искания за подобрения се изпълняват последни, работата в тях се извършва от най-малко опитни служители и т.н.
Но помислете за доставчик, който се грижи за всеки от своите клиенти. Решаването на неотложния проблем с настоящия ABS, като правило, е съвсем реалистично и дори не е много трудоемко. Приложете най-търсените подобрения, сменете индивидуалния мениджър, намалете разходите за поддръжка. В по-сериозни случаи е необходимо да се извърши изчерпателен одит, да се настрои правилният документооборот в ABS, да се добавят необходимите отчети, да се съберат с външни решения - и той ще работи „колкото нов“, така и въпросът за промяната ще бъдат премахнати изобщо от дневния ред. Най-често този сценарий „просто не знаете как да използвате правилно нашето решение“ се случва, когато смените ИТ екипа на банката.
Но в много други случаи промяната на ABS е необходима и, както беше посочено по-горе, ако банката обективно израства от използваното решение, тогава не трябва да отлагате въпроса за подмяната му.
Въпросът е как да се организира и извърши самата промяна на ABS. Ако се установи партньорство между банката и ИТ компанията, което е споменато по-горе, те ще могат да вземат решение заедно: кое е оптималното време за подмяна на ABS, започнете с подмяна на ядрото или отделните блокове, как да се подготви за смяната на ABS и др.