Модернизиране на основната система: случаят за комитета, не техническото ръководство

Представете си комитет, който разрешава началото на заместването на централната система на институцията през един уикенд. Зад това има повече от четири години планиране, репетиции, вътрешен пилот и гаранции от доставчиците. На хартия подготовката изглежда пълна.

Това е, по същество, онова, което се случи в една британска банка: съветът на TSB и неговият подкомитет разрешиха между 18 и 19 април 2018 г. началото на миграцията, изпълнена през уикенда от 20 до 22 април. Почти веднага се появиха сериозни проблеми и следващият понеделник показа, че подготовката и достатъчната увереност не са едно и също.

Под «основна система» (core) разбираме тук системата за водене на записите, от която зависят критични операции: клиенти, сметки, полици, поръчки, наличности, вземания, съгласувания или отчети, според отрасъла, а чрез нея и останалите системи (канали, плащания, счетоводство). Тази статия не е техническо ръководство. Тя е случаят за онзи, който трябва да реши: какво може да научи един комитет от публичния случай на TSB, когато миграцията на критични данни и функции е концентрирана в едно-единствено събитие, каква алтернатива съществува и как се представя тази алтернатива на комитет, който пита за риск, за цена и за срокове. Написана е за онзи, който отговаря за операциите, бюджета или риска в банка, финтех, застрахователна компания, търговска верига или регулирана компания.

Какво публикуваха TSB и PRA за случая

TSB, британска банка, изпълни своята основна миграция към нова платформа през април 2018 г. Самата банка описа програмата като най-сложната промяна, която е предприемала, и «една от най-сложните в историята на британското банкиране», с повече от четири години планиране [2]. Според банката съветът разреши основното събитие за миграция въз основа на «значителен обем обективни доказателства»: удостоверения на ръководството, писмени и устни гаранции от доставчици, девет генерални репетиции и успешни събития на прехода и пилот с повече от 1600 служители [2]. Миграцията също не беше едно-единствено събитие от начало до край: според TSB тя е била направена на етапи (банкомати, плащания с карти, ипотеки и мобилното приложение, между другото), а наведнъж е било основното събитие за миграция на данните на клиентите [2].

Тоест не беше импровизация. Имаше планиране, репетиции и осигуряване на увереност. Въпреки това, според британския пруденциален регулатор (PRA) [1] (самата TSB не е съгласна с някои аспекти на независимия преглед [2][5]):

• Всички клонове на TSB и значителна част от нейните 5,2 милиона клиенти са били засегнати от първоначалните проблеми.
• На TSB й отне до декември 2018 г., за да се върне към нормалната си дейност.
• Банката е изплатила 32,7 милиона лири компенсации [1] на клиенти, понесли вреда.
• През декември 2022 г. PRA и FCA наложиха съвместно на TSB глоба от 48,65 милиона лири [4].
• През април 2023 г. PRA наложи глоба от 81 620 лири [1] на тогавашния директор по информационните технологии, за това, че не е осигурил банката да надзирава по подходящ начин възлагането на външен изпълнител на нейната програма за миграция от 2018 г. Между другото, според регулатора, не е преоценил в достатъчна степен възможностите на третата страна, нито е получил необходимата увереност за готовността на платформата, преди да даде гаранции на съвета.

Има два урока за един комитет и нито един не е технически.

Първият: заявената подготовка не замества достатъчната увереност. Съветът е имал много документация. Онова, което регулаторът постави под въпрос, е колко здрава е била увереността зад нея: според PRA отговорното лице не е предприело разумни стъпки банката да получи достатъчна увереност от третата страна за нейната готовност, нито е преценило в достатъчна степен дали е трябвало да се проучи повече, преди да се дадат гаранции на съвета [1]. «Всичко е зелено» в една презентация не е същото като тази увереност.

Вторият: отговорността може да стигне до хората, не само до компаниите. Глобата на директора по информационните технологии почива на британския режим за индивидуална отговорност на ръководители; в Мексико приложимата рамка е друга и всяка институция трябва да я провери. Случаят показва, че при приложимия британски режим надзорът над трета страна може да доведе до индивидуална отговорност в допълнение към санкциите за институцията; той не позволява това последствие автоматично да се пренесе върху мексиканската рамка.

Онова, което тази статия не прави, също има значение. Комитетът на мексиканска институция би могъл да попита дали и тук става същото, но тук не се сравняват мексикански санкции или инциденти. За конкретно решение институцията трябва да определи приложимата за нея секторна рамка и да я потвърди със своите юридически отдели, отдела по съответствие и отдела за рискове.

Защо еднократното превключване концентрира риска

Martin Fowler, автор и авторитет в софтуерната архитектура, го казва без заобикалки за заместването на наследени системи: «видяхме как този план с проста на вид формулировка се срива в пламъци през повечето време» (собствен превод) [3]. Причината, която дава, е бизнес, не техническа: заместването на сериозна система отнема много време, а междувременно потребителите не могат да чакат нови функции [3].

Преведено на езика на комитета, еднократното превключване събира в един момент три неща, които е добре да се разделят:

1. Стойността има склонност да идва накрая. Години наред се инвестира и бизнесът не получава нищо, което да може да измери. Ако проектът се забави, няма нищо частично, което да се покаже.
2. Рискът се концентрира в един ден. Клиентите, клоновете, дигиталните канали, плащанията и съгласуванията се променят едновременно. Ако нещо се провали, може да се провали всичко заедно.
3. Връщането назад обикновено е трудно или не съществува. Когато данните вече са мигрирали и операциите от понеделник са записани в новата система, връщането към старата престава да е бутон и става друг проект.

Виждането на тези три точки на един лист помага на комитета да промени разговора. Въпросът престава да е «кога свършваме?» и става «какво става, ако нещо излезе зле в деня на превключването и колко от бизнеса е изложено?».

Алтернативата: на етапи, с връщане назад

Fowler даде име на алтернативата, взето от едно растение, което расте около дърво, докато го замести: смокиня удушвач (strangler fig). Идеята е проста за обясняване на комитет: вместо да се изключи старата система и да се включи новата, се изгражда около старата, част по част, и се прехвърля по една функция наведнъж. Докато една функция се прехвърля, предишната система може да продължи да обслужва онези, които още не са прехвърлени, според проектирането на данните, операциите и контролите. Fowler, цитирайки Ian Cartwright, Rob Horn и James Lewis, споменава четири дейности (редът, в който са изброени, не означава последователност): да се разберат резултатите, които се искат да се постигнат, да се реши как проблемът да се раздели на по-малки части, да се доставят успешно тези части и да се промени организацията, за да може това да се случва непрекъснато [3].

И е честен за цената: изграждането на този преходен слой може да изглежда като загуба, но «по-малкият риск и по-ранната стойност на постепенния подход надвишават неговата цена» [3]. Това твърдение е негова преценка, не универсално измерване; затова е добре комитетът да го провери със собствените си числа, както е обяснено по-долу.

Практическата разлика с еднократното превключване се вижда в едно сравнение:

Последният ред е важен. Пътят на етапи не е безплатен и който го представи така, губи доверие пред финансовия директор (CFO).

Връщането назад също не става само. Един етап да може да бъде върнат е свойство, което се проектира: коя функция се прехвърля, колко трафик получава, кой сигнал показва, че трябва да се върне към предишното състояние, и кой има властта да реши. Има легитимни необратими етапи, но те запазват концентрирана изложеност в рамките на обхвата си и трябва изрично да се обосноват пред комитета: какво ги прави необратими, как се ограничава вредата и какви контроли компенсират липсата на връщане назад.

Как се представя на комитета

За това решение комитетът може да даде приоритет на три неща, в този ред, пред техническите подробности.

1. Рискът, с неговото връщане назад

Въпросът, на който е добре да се отговори на една страница: кое е най-лошото, което може да се случи във всеки етап, и как се връщаме? За всеки етап — три данни: коя част от бизнеса засяга, кой показател предупреждава, че нещо не е наред, и колко време отнема връщането към предишното състояние.

Сценарий (илюстративен, без клиент). Застрахователна компания с полица за медицински разходи, която се администрира в централна система отпреди две десетилетия, решава да започне от офертите, а не от издадените полици. Първият етап прехвърля изчисляването на офертата към ново звено, докато централната система продължава да издава. Ако новата оферта дава резултати, различни от тези на сегашната система, в процент, който комитетът е определил предварително, трафикът се връща към предишното изчисление. Изложена е една функция, не цялата дейност.

2. Цената на бездействието

Това е частта, която често се пропуска и която може да тежи най-много. Комитет, който вижда само цената на модернизацията, сравнява едно число с нула и нулата често печели. Но поддържането на сегашната система също струва, и тази сметка е добре да се прави със собствени данни, не с цифри на трети лица. Не използваме тук общи пазарни проценти за дела от бюджета, който отива за наследени системи, или за провалите на замествания, защото не са нужни, за да се реши този случай. Сметката на комитета трябва да излезе от собственото му счетоводство, от инцидентите му и от сроковете му за промяна:

• колко се харчи годишно за поддържане, кърпене и експлоатация на сегашната система;
• колко време отнема днес да се пусне продукт, тарифа или регулаторна промяна и какъв доход се отлага междувременно;
• колко души концентрират знанието за системата и какво става, ако един си тръгне;
• какви инциденти или ръчни приключвания приписва днес на ограничения на основната система.

Ако комитетът няма тези цифри, това само по себе си е първата констатация и първият резултат.

3. Измерими ориентири, не процент на напредък

«Вървим към 60 %» е фраза, която една програма за заместване може да каже до деня, в който се провали. Ориентирите на една модернизация на етапи могат да се измерват в бизнеса, а не в проекта:

• каква част от трафика или от операциите вече върви през новото звено;
• колко време отнема сега да излезе промяна на тарифа, продукт или правило, спрямо онова, което е отнемало в началото;
• колко пъти връщането назад е било упражнявано и изпитвано и с какъв резултат;
• колко струва поддържането на слоя за съвместно съществуване и на коя дата е планирано да бъде премахнат.

Тази последна точка избягва един известен риск на подходите на етапи: преходният слой да стане постоянен. Премахването му трябва да е в плана от първия ден, с дата и отговорник.

Регулаторната част не се оставя за накрая

Ако един от етапите включва преместване на функции в облака или към трета страна, изискванията на вашия регулатор са част от графика, а не последваща формалност. В Мексико отговорът зависи от институцията и от третата страна: кредитните институции, институциите за електронни фондове за плащане (IFPE), застрахователите и гаранционните дружества имат свои правила за възлагането и надзора на трети страни, които могат да предвиждат предварително уведомление или разрешение според услугата и мястото, където се предоставя. Преди да се разреши един етап, юридическият отдел и отделът по съответствие трябва да потвърдят приложимото задължение, орган, преписка и срок. Три конкретни въпроса, които да им отнесете: изисква ли този етап предварително уведомление или разрешение пред CNBV (Националната банкова комисия и комисията по ценните книжа) или CNSF (националния застрахователен регулатор)? С колко предварение? Какво доказателство за увереност от третата страна очаква регулаторът да види документирано? Задължението, компетентният орган и срокът зависят от институцията, функцията, данните, местонахождението на услугата и наетата трета страна. Случаят TSB илюстрира, че британският регулатор не попита само дали системата работи: попита кой е осигурил, пред кого и с какво доказателство [1].

Затова е добре всеки етап, когато се представя на комитета, да носи приложена страница от този вид: какво се премества, кой се уведомява, какво доказателство от тестове има и кой отговаря.

Пет въпроса за вашия следващ комитет

1. Колко от нашия бизнес би бил изложен в най-лошия ден на първия етап и колко време ни трябва, за да се върнем към предишното състояние?
2. Имаме ли количествено определена годишната цена на немодернизирането, с данни от нашето счетоводство, а не от презентация на доставчик?
3. Какво независимо доказателство от тестове на натоварването и на данните имаме днес и кой, различен от онзи, който изгражда, го е прегледал?
4. Какъв ориентир на бизнеса, не на проекта, ще видим през първите шест месеца? Например една функция, която върви през новото звено с реален трафик.
5. Какъв орган, функция и отговорно лице посочва приложимата за нас рамка за надзор на третата страна и какво доказателство трябва да се съхранява?

Ако няколко отговора са «не знам», вероятно не липсва доставчик: липсва информация, за да се реши.

От къде да започнете тази седмица

Преди да разрешите по-голяма програма, можете да започнете с един лист с една-единствена колона от функции на основната система (откриване на клиент, оферта, издаване, плащане, съгласуване, регулаторни отчети) и до всяка три отметки: колко се променя годишно, колко други системи зависят от нея и какво би станало, ако спре за половин ден. Комитетът може да оцени всяка функция по пет критерия: проверима бизнес стойност, зависимост от други системи, обратимост, представителност на данните и натоварването и регулаторно условие. Първият етап ще е онзи с най-добър баланс за контекста, не непременно най-лесният; функция, чиято пауза не боли никак, може да даде пилот без значение. С този критерий комитетът има ред, който да защитава.

Какво прави Hábil

Hábil подкрепя организации, които трябва да решат как да модернизират основни системи, без да изпускат от поглед непрекъснатостта, контрола и проследимостта. Това е идеята на страницата Модернизиране на основната система без спиране на бизнеса; за обединяване на вашите системи и канали — страницата Обединяване на дейността и каналите.

Първият разговор за диагностика е безплатен и служи за очертаване на системата, предстоящото решение и информацията, която комитетът Ви би имал нужда да събере, за да го оцени. Пишете ни в WhatsApp.