TSB, април 2018: уикендът, след който една банка не можа да се върне назад

В неделя, 22 април 2018 г., около един часа следобед, една банка във Великобритания даде разрешение за последната стъпка на проект, продължил почти три години. През този уикенд тя беше прехвърлила на нова технологична платформа по-голямата част от дейността си: системите си, услугите си и данните на клиентите си. В шест вечерта телефонното и интернет банкирането вече работеха. Мобилното приложение се забави малко: тръгна в 18:45 [1].

Петнайсет минути по-късно банката изключи всичките си дигитални канали.

Около 40 клиенти бяха съобщили нещо, което никоя банка не иска да чува: като влезли в сметката си, виждали парите на друг човек, най-често на роднина. По-късно се потвърди, че това се е случило на 440 клиенти [1]. Банката се казваше TSB, имаше около 5,2 милиона клиенти [1] и онази вечер започна криза, която според регулатора приключи напълно едва на 10 декември 2018 г. [1].

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

Едно уточнение, преди да започнем: Hábil не е участвала в този случай. Разказваме го с онова, което регулаторите (FCA и PRA) са съобщили публично, и с независимия доклад, публикуван от TSB.

Първо, четири думи

За да разбираме всички на масата едно и също:

• Основна система (core): системата, в която живеят сметките, салдата, движенията и правилата на бизнеса. В една банка тя решава дали едно плащане е приложено.
• Миграция: прехвърляне на дейността и данните от една система в друга.
• «Big bang»: струпване на по-голямата част от миграцията в едно събитие, почти винаги уикенд. Може да има предварителни стъпки, но основният риск остава в този момент.
• Път назад (или roll-back): възможността да се върнете към старата система, ако новата се провали.

Запомнете последната. Тя обяснява всичко останало.

Понеделникът, в който всичко си личеше

В понеделник, 23 април, в два часа през нощта банката отново включи интернет банкирането и приложението. Но част от новата платформа поглъщаше огромни количества памет и банката трябваше да ограничи влизанията, за да не падне приложението [1].

Същия ден имаше около 900 000 опита за влизане в онлайн банкирането. Само около 10 % от опитите през интернет успяха. От плащанията, които клиентите се опитаха да направят, не бяха завършени 48 % в приложението и 59 % през интернет [1].

Клиентите, които не успяха да влязат, направиха логичното: позвъниха. До два следобед телефонният център вече беше получил 69 000 обаждания. Банката се беше подготвила за до 50 % повече обаждания от обичайното, но проблем в конфигурацията остави на разположение само около една четвърт от капацитета на линиите, който трябваше да има. Чакането беше около 90 минути, а седем от всеки десет души затваряха, преди да бъдат обслужени [1].

Който не постигна нищо по телефона, отиде в клона. Там касовото приложение падаше и четците на карти не работеха. Образуваха се дълги опашки [1].

Регулаторът го описва като каскаден ефект: дигиталният срив пренасочи хората към телефона, телефонът се претовари и хората стигнаха до клонове, които също не работеха [1]. Телефонът и клоновете си имаха собствени проблеми, така че никой канал не успя да поеме натиска от другите.

Дигиталните канали останаха «нестабилни и почти неизползваеми» до четвъртък, 26 април [1]. До този ден банката беше регистрирала 10 315 оплаквания, при очаквани 1 146 [1]. Някои дефекти останаха до юни [1].

Цената на кризата

Последвалото може да се изрази в числа, всички от официални документи:

• 225 492 оплаквания между 22 април 2018 г. и 7 април 2019 г., от около 4,3 % от клиентите ѝ [1].
• 32,7 млн. паунда, изплатени на клиенти като обезщетение през същия период [1].
• Почти 12 месеца, за да се обработят оплакванията от миграцията [1].
• 48,65 млн. паунда глоби на 20 декември 2022 г.: 29,75 млн. от Financial Conduct Authority (FCA) и 18,9 млн. от Prudential Regulation Authority (PRA), двата регулатора на Обединеното кралство. Без отстъпката от 30 % за постигнато споразумение щяха да бъдат 69,5 млн. [1][2][3].
• Една лична глоба през април 2023 г.: PRA санкционира бившия директор по информационните системи с 81 620 паунда, защото не е предприел разумни мерки банката да контролира както трябва своя доставчик по време на миграцията [5].

И има един факт, който променя начина, по който се чете всичко останало: миграцията на данните беше успешна [1]. Това не предотврати проблемите с достъпа и с работата, нито случаите на клиенти, видели чужда информация. Урокът е неудобен: добре мигрираните данни не доказват, че една платформа е готова да обслужва милиони клиенти едновременно. Според FCA преките причини са свързани с конфигурацията, капацитета и кода на платформата [1].

Как се стигна до онази неделя

За да разберем нощта на 22 април, трябва да се върнем почти три години назад.

TSB е създадена през 2014 г., при отделянето от групата Lloyds, и продължаваше да ползва технологичната платформа на Lloyds по договор. През 2015 г. я купи испанската банка Sabadell (за 1700 милиона паунда, според Reuters [7]), която имаше опит в миграцията на банки към собствената си платформа, наречена Proteo [1]. Миграцията на TSB към тази платформа беше част от бизнес обосновката на покупката [1].

След кризата съветът на директорите на TSB възложи на адвокатската кантора Slaughter and May независим преглед. Докладът, датиран октомври 2019 г. и публикуван от TSB през ноември същата година, възстановява историята [4][6]. Три от констатациите му обясняват неделята през април.

1. Датата дойде преди плана

До 1 юли 2015 г., деня след като офертата за покупка стана окончателна, вече беше избрана дата за пускане на новата система: неделя, 5 ноември 2017 г. [4]. Първият официален план, завършен девет месеца по-късно, запази същата дата.

Докладът я нарича «амбициозна и нереалистична» и посочва нещо по-сериозно от самата дата: наложил се е един модел — първо се фиксира желаната дата, после се строи план, който да се побере в нея, независимо дали е реалистичен [4].

През септември 2017 г. банката отложи старта и преработи плана, без да проучи основно защо е имало закъснение, а девет дни по-късно обяви публично нова дата. До януари 2018 г. проектът вече се беше отклонил отново [4].

2. Основната миграция, за един уикенд и без да се обсъди докрай

Начинът на миграция е едно от най-важните решения в такъв проект: на части или наведнъж. Докладът го обяснява направо: наведнъж е «най-бързият, най-евтиният и най-малко сложният начин», но изисква да се разбират рисковете и платформата да се изпита основно, преди да се изправи пред всички клиенти [4].

И добавя важен нюанс: не би било непременно погрешното решение, ако бяха взети правилните мерки, които да компенсират риска [4]. Проблемът беше друг: изборът не беше обсъден докрай в съвета, не му бяха представени вариантите с техните рискове и не беше поискан външен съвет по този въпрос [4].

Банката наистина премести по-рано някои части: незабавните плащания, приложението и банкоматите [1]. Но докладът заключава, че тези предварителни етапи са покрили само малка част от платформата и че пилотът с реални потребители не е имал достатъчен мащаб, за да покаже какво ще се случи с всички клиенти [4].

Причините, които банката изтъкна, за да направи почти всичко в едно събитие, са разумни и затова си струва да се прочетат: трудността да се мине на етапи от един доставчик към друг, цената на етапите, схващането, че предишният доставчик няма да го улесни, и предимството клиентът да вижда всичките си продукти на едно място [1].

3. Това, което съветът не успя да види

Тук е центърът на историята. Няколко сигнала съществуваха, но не стигнаха пълни до онзи, който взимаше решението:

• Дефектите. На съвета беше съобщено за «около 800 дефекта», които щели да преминат в работещата система. Докладът установи, че в действителност са били 3317: 800-те били групи от функции, които събирали по няколко дефекта, а липсвали онези, открити при други тестове [4]. Проблемът не беше само в числото, а в това, че отчетът не казваше какво отчита и какво оставя вън.
• Целите на тестовете. При тестовете за натоварване на интернет банкирането и приложението целите бяха намалени, след като тестовете не минаха с първоначалното натоварване. Резюмето не изясни промяната, а реалното ползване след старта надмина намалените цели [4].
• Реалната конфигурация не беше изпитана цялостно. Работата зависеше от два центъра за данни, действащи заедно, но тестовете за производителност бяха направени само в единия. Проблемите в конфигурацията между двата, които удариха дигиталните клиенти още от първия момент, не можеха да се появят в тези тестове [4]. FCA добавя, че решение, взето извън органа, който трябваше да го вземе, в края на февруари 2018 г., съкрати един тест, който вероятно би открил проблема [1].
• Доставчикът. Доставчикът, който изграждаше и щеше да експлоатира платформата, дъщерно дружество на Sabadell, на свой ред зависеше от 85 трети страни [1]. Един доклад на одиторска фирма, поръчан от този доставчик, който откри слабости във вътрешните му контроли, не беше споделен с TSB [4].

Докладът обобщава заключението си в две изречения: новата платформа не е била готова да обслужва всички клиенти, а доставчикът не е бил готов да я експлоатира [4]. За съвета казва, че е задавал уместни въпроси, но са му липсвали някои «от здрав разум», и че заседанието му на 10 април 2018 г. е било пропусната възможност да спре и да помисли [4].

За да бъдем справедливи, трябва да се каже, че съветът на TSB не се съгласи с всичко в доклада. Той заяви, че ключова причина е било това, че двата центъра за данни са останали конфигурирани по различен начин, макар да са били определени като идентични, и че е решил да продължи въз основа на обширни тестове, отчети за готовност и гаранции от доставчика [6]. Констатациите в този раздел са от независимия доклад; позицията на съвета е онази, която TSB публикува.

Думата, която липсваше: път назад

От всичко, което се провали, има едно решение, което превръща лошия старт в криза от осем месеца.

FCA го обяснява така: когато се мигрират почти всички клиенти едновременно, един сериозен проблем може да навреди на огромен брой хора. Затова понякога се подготвя план за връщане към предишната система. За TSB такъв план не беше възможен [1]. По договор, като уведоми Lloyds, че ще излезе чрез миграция, банката се отказваше от другата си възможност за излизане: копие на платформата, експлоатирано от трета страна. А след мигрирането на данните оставаше много кратък прозорец, преди предишната платформа да бъде изключена. На практика връщането беше технически почти невъзможно [1].

Рискът не беше тайна. През декември 2015 г. протоколът от заседанието на съвета на TSB предупреди, че съветът не може да остане в положение, в което се е отказал от опцията си за излизане, а миграцията е засякла или се е оказала неосъществима, «оставяйки банката без технологична инфраструктура» [1].

А подготовката за криза не беше на нивото на този залог. Ръководствата за управление на инциденти бяха проектирани за първите 48 часа [1]. Симулациите предполагаха, че инцидентите ще се решават за няколко дни; много траяха седмици [1]. FCA заключава, че без връщане назад и при зависимост от един-единствен доставчик, който да поправя няколко проблема едновременно, банката е трябвало да се подготви много по-добре [1].

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

TSB не е случай на лоша технология. Това е случай на риск, концентриран в един-единствен момент, без изход, с непълна информация на масата. Това може да се случи на всяка компания, която сменя основната си система, своя ERP (системата, която обединява финанси, доставки, наличности и операции) или системата си за полици, независимо от марката. Шест урока, на езика на бизнеса.

1. Ако датата командва над доказателствата, планът е желание. Когато всяко закъснение се решава със затягане на плана, а не с преместване на датата, рискът се трупа тихомълком. Поискайте измерими критерии за старт и комитетът да може да мести датата, без това да изглежда като провал.

2. Въпросът не е «ще работи ли?», а «какво става, ако не работи?». Старт наведнъж може да е правилният избор. Но ако няма как да се върнете, цената на грешката вече не е лош уикенд: това е цялата дейност за месеци. Преди да одобрите, попитайте кой е пътят назад, колко време е на разположение и кой решава да се ползва.

3. Искайте да видите вариантите, не само препоръката. На съвета на TSB не бяха представени начините за миграция с техните рискове [4]. Комитет, който вижда само едно предложение, не решава: одобрява.

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

5. Вашият критичен доставчик трябва да докаже, че може да експлоатира, не само да изгражда. Това са две различни способности. Ако доставчикът ви зависи от десетки трети страни, зависите и вие. Поискайте доказателства за експлоатация, не само гаранционни писма.

6. Подгответе се за седмици, не за 48 часа. Попитайте какво става на десетия ден: кой отговаря на обажданията, как се обезщетяват клиентите и как се разпознават най-уязвимите.

И един седми урок, който случаят изяснява: отговорността стига до хората. Глобата на бившия директор по информационните системи беше за това, че не е предприел разумни мерки банката да контролира адекватно доставчика [5]. Гаранцията на един доставчик не замества доказателствата, които самата компания трябва да получи и да прегледа.

Алтернативата: модернизиране на части, в съжителство с основната система

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

Ако рискът на TSB беше струпването на всичко в един момент без изход, алтернативата е той да се разпредели: модернизиране на части, докато действащата система продължава да работи, и с път назад във всеки етап.

На езика на бизнеса изглежда така:

• Сегашната основна система продължава да работи. Не се изключва в петък, за да се включи друга в неделя. Около нея се изгражда слой, който я свързва с каналите, с партньорите и с новите функции, без да пипа правилата ѝ отвътре.
• Сменя се по една функция. Например първо справката за салда за малка група клиенти; после плащанията; после друг продукт. Всяка част се приема, преди да започне следващата.
• Всеки етап има уговорено връщане назад. Преди да започне, се уговаря как тази функция да се върне към предишния път, ако нещо тръгне зле, без да повлече остатъка от дейността.
• Старото и новото се съгласуват. Докато съжителстват, се сравнява какво казва едното с какво казва другото. Новата функция си печели мястото с доказателства, не с дата.
• Растежът е постепенен. Първо една група клиенти, после друга. Проблемите обикновено се появяват, докато засягат малко хора, и са по-лесни за поправяне.

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

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

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

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

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

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

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

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

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

Hábil е мексиканска инженерна консултантска компания, основана през 2006 г., която се интегрира с централните системи, които вашата компания вече има. Не заменяме основната ви система: изграждаме около нея слоя, който позволява модернизиране на части, докато сегашната система работи, със съгласуване между старото и новото и с уговорено връщане назад във всеки етап. Така всяка нова функция си печели мястото с доказателства, а модернизирането е замислено така, че дейността ви да продължи междувременно. Вижте страницата Модернизиране на основната система без спиране на бизнеса.

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

Често задавани въпроси

Какво се случи с TSB през април 2018 г.?

От 20 до 22 април 2018 г. TSB прехвърли по-голямата част от дейността си на нова платформа. Данните бяха мигрирани добре, но платформата се провали във всички канали, а банката не се върна към нормалното до декември [1].

Колко бяха глобите и кой ги наложи?

На 20 декември 2022 г. FCA глоби TSB с 29,75 млн. паунда, а PRA с 18,9 млн.: общо 48,65 млн., с отстъпка от 30 % за постигнато споразумение [1][2][3]. През април 2023 г. PRA глоби бившия директор по информационните системи с 81 620 паунда [5].

Значи миграцията наведнъж винаги е грешка?

Не. Независимият доклад казва, че не би било непременно погрешното решение, ако бяха взети правилните мерки, които да компенсират риска [4]. Което не издържа, е да се избере без оценка на алтернативите, без тестове в реалния мащаб и без изход, ако нещо се провали.

Модернизирането на части не излиза ли по-скъпо?

Може да струва повече във време и в поддържане на две системи едновременно. В замяна всеки етап излага по-малко. TSB показва другата страна на сметката: обезщетения, глоби и почти година обработка на оплаквания [1].

Отнася ли се това само за банки?

Не. Отнася се за всяка компания, която сменя системата, която решава нейната дейност: системата за полици на една застрахователна компания, ERP на една индустриална фирма, системата за поръчки на един търговец. Размерът се променя; рискът от струпване на всичко в един момент без изход, не.

Кога не е удачно да се модернизира на части?

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

Hábil заменя ли основната ни система?

Не. Hábil се интегрира с вашата сегашна основна система и изгражда около нея слоя, който позволява модернизиране на части. Основната система продължава да работи, а всеки етап има уговорено връщане назад.

Цитатите са преведени от английски. Числата, датите и санкциите са от решенията на FCA и PRA; анализът на решенията по проекта е от независимия доклад на Slaughter and May, публикуван от TSB; позицията на съвета е от съобщението на TSB. Източниците са консултирани на 20 и 21 октомври 2026 г.