Britse bank TSB krijgt ruim 48 miljoen pond boete wegens langdurige IT-problemen

De Britse bank TSB heeft twee boetes gekregen die gezamenlijk 48,65 miljoen pond bedragen. De bank krijgt de boetes wegens een mislukte migratie van zijn IT-platform in 2018. Het duurde acht maanden voordat alle problemen waren opgelost en klanten geen hinder meer ondervonden.

De boetes zijn afkomstig van twee financiële toezichthouders: de Financial Conduct Authority (FCA) en de Prudential Regulation Authority (PRA). TSB heeft van de FCA een boete van 29,75 miljoen pond en van de PRA een boete van 18,9 miljoen pond gekregen. Door in te stemmen met een schikking kreeg TSB een korting van 30 procent, schrijven de toezichthouders in een verklaring.

In april 2018 begon TSB met het overzetten van zijn bedrijfs- en klantendiensten naar een nieuw IT-platform. De gegevens waren succesvol overgezet, maar het platform zelf ondervond 'onmiddellijk technische storingen'. Dit heeft geleid tot een 'aanzienlijke verstoring van de bankdiensten van TSB', waaronder bankfilialen, telefoon, online en mobiel bankieren, schrijven de FCA en PRA. Alle kantoren van TSB en een groot deel van de 5,2 miljoen TSB-klanten werden door de problemen getroffen. Het heeft tot december 2018 geduurd voordat de dienstverlening van de bank weer normaal verliep.

"De migratie van TSB was een ambitieus en complex IT-project met een hoog operationeel risico. Het succes ervan was cruciaal voor het vermogen van TSB om continuïteit van kritische functies en veiligheid en soliditeit te bieden. De toezichthouders hebben echter vastgesteld dat TSB het IT-migratieprogramma niet naar behoren organiseerde en controleerde en er niet in slaagde de operationele risico's te beperken", aldus de FCA en PRA.

In een verklaring heeft TSB-ceo Robin Bulloch zijn excuses aangeboden aan klanten die door de problemen zijn getroffen, schrijft Reuters. "We hebben hard gewerkt om de problemen voor onze klanten op te lossen en sindsdien hebben we ons bedrijf getransformeerd. In de afgelopen vier jaar hebben we onze technologie ingezet om nieuwe producten en betere diensten voor TSB-klanten te leveren." TSB heeft ook 32,7 miljoen pond aan schadevergoeding betaald aan klanten die destijds schade hebben geleden.

Reacties (61)

[Umbrah]

Aan de ene kant: "goed! Zal ze leren om te luisteren naar IT pro's en dingen die niet direct waarde genereren, zoals testen en updates uit te voeren! Lifecycle management wat niet uitgevoerd wordt is dé oorzaak dat mega migraties soms nodig zijn en de afwezigheid van soms zelfs een "N-1"-beleid zorgt er voor dat spul soms ineens omvalt en er dus mega projecten nodig zijn!!!".

Aan de andere kant: "shit... als dit ze maar niet ontmoedigd om nooit meer iets aan IT te doen, voor hetzelfde geld is dit de reden dat er fortran/cobol mainframes staan die alleen met sneakernet benaderbaar zijn met een stel 80+ers als beheerders, waarna er een hoop verbazing is omdat hun bedrijf failliet gaat omdat de concurrenten blijkbaar wel op een veranderende vraag konden insturen".

Ik ben het eigenlijk wel eens met het feit dat deze boete uitgebracht wordt, maar ik twijfel over de motivatie. De impact is natuurlijk duidelijk voor de klanten. Hoewel ik niet alle ins- en outs weet, is het gevoel dat ze een nieuw systeem hadden, maar zodra er écht data op kwam, ontstonden de problemen. Instinct zegt dan: "duidelijk niet goed getest", maar de ervaring leert dat dat niet eens zo hoeft te zijn. Er kan scope creep geweest zijn aan de ene kant terwijl de andere kant heel hard hamerde op deadlines (en dus on-affe dingen afrondde). Er kan een "SAAS-silo" cultuur ontstaan zijn (dit gebeurd bij veel Nederlandse bedrijven, startups/bedrijfjes met mooie one-point oplossingen maken management enthousiaste presentaties van hun app die een specifieke use-case voor één afdeling oplost, waarbij de organisatie in feite hun data voor dat proces "verkoopt" aan die partij, en in ruil daarvoor er voor mag betalen, met als nadeel dat data/proces nu niet meer aansluit en integreerd met overige processen, wat weer voor complexe andere API-lagen/datafabrics zorgt). En dat ontstaat als business en "de tak die over gereedschappen gaat", in dit geval IT/Automatisering, niet met elkaar praat. Ik weet het niet.

Ik zal er blij mee zijn als de boete is voor het ongemak, MITS de boete er niet voor zorgt dat er nóg meer afstand tussen de stuurlui en de machinisten ontstaat.

[this]

Inderdaad, ik zou er als IT'er ongelofelijk onzeker van worden als ik daar verantwoordelijk voor ben en weet dat het bedrijf boetes van 48 miljoen pond riskeert als het misloopt.

[cariolive23]

Wanneer jij willens en wetens fouten maakt, hoor jij imho die boete te krijgen... Misschien niet de volledige 48 miljoen pond, maar wel eentje die pijn doet. Jouw fout, jouw pijn.

Bij TSB hebben de verantwoordelijke managers helemaal niets gevoeld van de fouten die zij maakten en ook van deze boete gaan ze niks voelen. Grote kans dat ze morgen weer vergelijkbare fouten maken.

[this]

Daar zijn we allemaal voor verzekerd. Tenzij het echt bewust is, maar dan ga je geen stress hebben natuurlijk want je doet er om.

Hoe weet je dat van TSB? Heb je daar bronnen van? Dat lijkt me wel interessant om eens over te lezen hoe managers hier volledig ontsnappen aan de verantwoordelijkheden na een boete van 48 miljoen pond.

[Umbrah]

Exact! Maar dat is een valkuil an-sich. Lifecycle management gaat er juist om dat updates zo klein en incrementeel zijn, dat de risico's te overzien zijn. Op het moment dat je een pakket neerzet en niet dit soort dingen doet, is het ineens na 4 á 5 jaar een migratietraject geworden, want je moet alles in één keer doen.

Het is juist waarom CI/CD en bizdevops zo belangrijk zijn, zeker voor een bedrijf als een bank wat qua operationele requirements heel erg op het snijvlak van een techbedrijf opereert maar tegelijk op high security. Banken moeten heel veel regelgeving toepassen, toetsen, en tegelijk garant staan voor een hoge mate van veiligheid, betrouwbaarheid, en reservekopieën.

[KRBM123]

Bedankt voor de nuttige bijdrage, maar wat is N-1 beleid?

[Umbrah]

N-1 beleid komt vaak voor. Het is een soort van "utopie" van balans tussen stabiliteit, en innovatie. Ooit ontstaan vanuit een wanhoop: "niemand wil voor ons werken, specialisten willen met nieuwe technologie werken". Het idee is dat je altijd op de één na laatste versie van een stuk software werkt (en bijvoorkeur de nieuwste al aan het testen bent). Zo ben je nooit té oud, en té ver buiten support. Tot zo ver de utopie.

De praktijk is dat het meer een dystopie is, want men is het nooit eens over het concept "wat ís een versie". Vertel mij maar eens zonder te kijken wat jouw huidige versie van chrome/firefox/edge/etc is. Gaat je niet lukken. Spoiler: ik werk op een chromium browser met als versienummer 110.0.1556.0. Dit soort browsers update bijna dagelijks. N-1 bestaat eigenlijk hier niet.

Andersom heb je producten als databases, postgres/oracle/etc. Een versie is daar meer een "iteratie" waarbij ze diverse tegelijk in support hebben, elk met een eigen patchcycle. Wat kies je?

N-1 is wat dat betreft een compromis, en een manier om als IT-er in de 'machinekamer' eigenlijk met de officieren te praten van het 'schip': "wij moeten iets moderner doen en IETS een beleid noemen", en met N-1 zeg je aan de ene kant: "de een na laatste versie", waardoor de officieren horen: "het is stabiel, we worden niet té gek". Als machinist/IT-er heb je een beleid in handen waardoor je zowaar tijd vrij kan maken voor updates, refactoring, en lifecycle management binnen "landschapbeheer".

Als je strict maatwerk/solutions werkt, en 100% agile werkt, zal ik zeggen: "elke sprint 30% refactoring". En dat moet je als organisatie eigenlijk ook doen. Kijk naar de systemen die draaien, de componenten waar ze afhankelijk van zijn, en de processen die ze ondersteunen. Ondanks dat het nú goed gaat, hoeft er ergens in een grote keten maar iets om te vallen (10 november dit jaar is Postgres 10-cycle uit support gegaan en heeft potentieel veiligheidsrisico's, volgend jaar is dat postgres 11, maar er zijn al sub-patches van 11 die niet meer supported zijn, welke producten kunnen nu niet met postges 15 overweg en misschien: moeten we alle core databases updaten naar 15?), en er hoeft maar één datalek te zijn, en je hangt.

[raro007]

Jij schuift de schuld aan de manager maar wie zegt dat het niet aan hun ITers kan liggen? Als die tegen de manager zeggen wij hebben maanden getest terwijl ze zaten te pokeren, dan gaat hij dat geloven.
Niet ieder ITer is er 1 goede en zat die zich overschatten.
Ik denk zelf dat er 2 problemen zijn
1 managers die geen verstand van hebben en te makkelijk denken.
2 vak bekwaamd ITers.
Ik zal hier wel op veel tweakers voeten stappen maar dat is wel een algemeen probleem ook met andere beroepen.

[Umbrah]

Het is een combo van beiden, maar de partij waar de schaarste zit, is uiteindelijk de lastigste. Kijk naar hoe de belastingdienst leegloop had toen er een kans was, en hoe IT-ers eigenlijk altijd al een vakgebied zijn geweest met de tekorten die nu pas in andere industrieën zitten.

Ik mag niet té veel aangeven, maar ik ben me heel erg bewust van het feit dat er bedrijven zijn (vooral CAO bedrijven) waar eigenlijk geen goede IT-ers meer zitten.

Het probleem is namelijk dat je twee soorten IT-ers hebt eigenlijk. Die met een zeer hoge motivatie voor geld, en het soort met een motivatie om écht iets te bereiken, en met coole tech bezig zijn. Dat is natuurlijk wat zwart/wit, en eigenlijk onterecht, maar ik ken een paar organisaties die in vergelijking met zelfs een basis outsourcer gewoon slecht betalen (omdat dit soort bedrijven de lonen van een IT-er gelijk legt aan een uitvoerder, wat natuurlijk een goed perspectief is, ware het niet dat IT-ers al heel lang schaarser zijn en met één klik meer kunnen verdienen elders). In dit soort bedrijven zijn managers lang bezig geweest om de motivatie voor de echt goede IT-ers lastig te maken. Dit heeft ze een hoop goede mensen gekost, waardoor de mensen die er nog zitten... eigenlijk niet het meest "goed" is (uitzonderingen daargelaten). En dan heb je dus een situatie waarbij managers doorgaan met hun PRINCE2 waterval aanpak van minimale IT en stricte deadlines (of het af is of niet), en IT-ers die niet zeggen: "I cannea give her anymore cap'n or she'll blow!", maar "ja", tot de dag dat het live moet, en alles zwart gaat. Die IT-er is dan net zo schuldig, maar de manager is schuldig aan het faciliteren van een omgeving dat het zo kan.

Het probleem is natuurlijk dat we allemaal mensen zijn met allerlei motivaties. Die van mij is altijd "tech ten goede van" geweest. We moeten immers met minder mensen meer werk doen, en dat wisten we al 20 jaar geleden. Uiteindelijk is IT echter een hulpmiddel (om dat mogelijk te maken). Een hulpmiddel wat zó belangrijk is dat veel organisaties, ondanks dat IT niet hun "core competence" is, wel een CIO heeft. Elke garagehouder zal je zeggen dat je goed voor je gereedschap moet zorgen, immers. En daar zit dan ook de crux. Dit soort veranderingen duurt gewoon lang. Dat zie je bij deze bank ook. Daar moest met een noodgang een mega-specialistisch IT bedrijf ingevlogen worden, die het redelijk konden fixen. Daarna kwam een rapport, waarbij "tech-illiteracy from management" een factor was. Dat het vóór het mis ging niet gemeld is, kan ik me niet voorstellen. Maar of dat door een roepende in de woestijn was (de laatste wél competente interne IT-ers), of door bergen mensen maar genegeerd, is me onbekend.

Dat van de externen die invliegen om alles te redden is mij overigens érg bekend. Laat ik zo zeggen dat ik zat organisaties ken die intern geen cent willen uitgeven, maar voor elk extern "oh shit" dingetje is ineens onbeperkt budget (uit publieke bronnen) beschikbaar.

[Blokker_1999]

Het is een combo van beiden,

We weten niet wat hier misloopt. En dat vind ik altijd zo spijtig. Een project mislukt en je leest direct in de comments dat het komt omdat management IT niet belangrijk vindt, niet luisterd naar de experts, er nooit geld is, enzoverder. En ja, er zullen zeker ondernemingen zijn waar dit het geval is. Maar in alle ondernemingen waar ik tot op heden gewerkt heb, ben ik die problemen zelf nog nooit tegengekomen.

Slecht project management? Absoluut, dat zie je vaak genoeg. Maar dat heeft dan weer minder met het echte management te maken want management heeft je project goedgekeurd en de benodigde financien zijn voorzien.

[david-v]

Het staat wel letterlijk in een van de berichten waar naar gelinkt wordt:

The TSB review has revealed a lack of technology literacy at the top of the organisation

Het zal niet zo zijn dat ze het niet belangrijk vinden, maar ze snappen er helemaal niks van. Laat het dan over aan mensen die er wel iets van weten.

[bkor]

Het zal niet zo zijn dat ze het niet belangrijk vinden, maar ze snappen er helemaal niks van. Laat het dan over aan mensen die er wel iets van weten.

Indien de top van een bedrijf in een bank niet genoeg verstand heeft van IT of hoe veranderingen te begeleiden dan is er echt iets mis met de top van dat bedrijf. Het lijkt erop dat je delegeren in gedachten had? Mijns inziens is gebrek hieraan meer tijd om wat mensen te roteren in de top van het bedrijf. En hierbij bedoel ik niet dat je IT'ers nodig hebt. Echter hoef je totaal geen expert te zijn om ervoor te zorgen dat je goed wordt ingelicht en hierbij begrijpt wat iemand je duidelijk probeert te maken.

Ik ben een top gewend dat redelijk weet wat elke afdeling binnen een bedrijf doet. Tegelijk ook gezien dat er een groep is welke denkt te kunnen besturen zonder dat ze echt inhoudelijke kennis hebben en dit ook niet opbouwen. Echter is bij de laatste soms erg duidelijk na een tijdje dat ze uiteindelijk problemen hebben tussen een keus tussen A/B/C. Waarbij A echt gigantisch logisch is en B/C echt overduidelijk een slechte optie zijn. Je wilt in de top mensen die dat gelijk kan doorzien of inschatten. Zonder dus een micromanager te worden natuurlijk.

[david-v]

Indien de top van een bedrijf in een bank niet genoeg verstand heeft van IT of hoe veranderingen te begeleiden dan is er echt iets mis met de top van dat bedrijf

Dat is letterlijk wat de review van deze bank naar voren heeft gebracht, zo staat het ook in mijn bericht. Dus ja, er is wel iets mis, dat kan ook niet anders als je ziet hoeveel "extra" geld hier tegenaan is gegooid. De boete van 48 miljoen pond is een schijntje vergeleken met de imago schade en het budget die gespendeerd is om het enigzins werkend te krijgen.

[bkor]

Kijk naar hoe de belastingdienst leegloop had toen er een kans was

De belastingdienst gaf aan dat ze veel en veel minder medewerkers nodig hadden vanwege de nieuwe en geweldige IT systemen. Als gevolg van dit gaven ze enorm riante vertrekvergoedingen. Je vat dit samen als "een kans", echter was dit een bewuste stap dat de belastingdienst had geboden.
Wat jaren later en de belastingdienst zegt nu dat ze oude systemen hebben. Iets daarvoor gaven ze ook aan dat ze niet verwacht hadden dat zoveel medewerkers zouden vertrekken. Tja.

Ik mag niet té veel aangeven, maar ik ben me heel erg bewust van het feit dat er bedrijven zijn (vooral CAO bedrijven) waar eigenlijk geen goede IT-ers meer zitten.

Kan je misschien aangeven wat je denkt dat er mis is aan een CAO en hoe dit effect heeft? Als je boeken leest zoals "Fantoomgroei" dan lijkt me juist dat je het verkeerde de schuld geeft.

Het probleem is namelijk dat je twee soorten IT-ers hebt eigenlijk.

Je manier van opsommen komt niet echt over op mij, lijkt meer alsof je 1 type opsomt. Vooral door gebruik van veel "en", "en".

Dat van de externen die invliegen om alles te redden is mij overigens érg bekend.

Dat is soms puur omdat een externe makkelijker gehoord wordt door de rest van het bedrijf. Bij een groot bedrijf is het soms erg lastig om iemand te overtuigen. Iemand extern inhuren is niet hetzelfde budget als salariskosten. Het is hierdoor gedeeltelijk geldverspilling, maar wel noodzakelijk.

[bkor]

Instinct zegt dan: "duidelijk niet goed getest", maar de ervaring leert dat dat niet eens zo hoeft te zijn. Er kan scope creep

Wat ik veel vaker heb meegemaakt is dat problemen worden toegewezen aan de test data of omgeving. Vervolgens blijkt veel later dat het toch een probleem was. Een nieuw systeem met vele koppelingen naar andere systemen goed testen blijft gewoonweg lastig. Ik zie te vaak statements zoals "test omgeving". Alsof dat zomaar goed opgezet is of de realiteit weergeeft.

Edit: In 2.14 in dit rapport:

A decision was taken outside of the appropriate governance forum around the end of February 2018 which reduced the scope of a particular type of non-functional testing on the digital channels

Echter wat ik gewend ben is dat er risicoanalyses worden gedaan. Plus acties om de risico's te minimaliseren. Bijvoorbeeld een nieuwere versie van het ERP systeem. Je kan redelijk inschatten wat er mogelijk mis kan gaan. Een risico was problemen om leveranciers te betalen. De procurement (inkoop) afdelingen hebben van te voren aangegeven welke leveranciers kritiek zijn, ze hebben leveranciers ruim van te voren gewaarschuwd, plus hebben ze aangegeven wie de leveranciers kunnen aanspreken bij problemen. Er waren inderdaad problemen met het betalen van leveranciers. Leveranciers wisten gelijk wie ze moesten inlichten en alle voorbedachte acties werden uitgevoerd. Leveranciers bleven vertrouwen houden dankzij communicatie vooraf, tijdens en na. Plus acties zoals o.a. lumpsum voor sommige leveranciers.

90% is misschien het systeem maken, daarna nog eens 90% werk om alle risico's in te schatten en mogelijke problemen voor te bereiden. En zeker dat laatste is prima te doen in een groot bedrijf.

Aan de andere kant: "shit... als dit ze maar niet ontmoedigd om nooit meer iets aan IT te doen

Een flinke boete is juist goed, zorgt ervoor dat het op het hoogste niveau aandacht aan wordt gegeven. En dus de juiste prioriteiten worden gesteld. Indien zo'n bedrijf dan mogelijk niks meer aan IT doet en niet meer concurrerend is, tja, we zitten in een kapitalistisch systeem.

[Reactie gewijzigd door bkor op 23 juli 2024 04:17]

[Triblade_8472]

Je zou verwachten dat dit soort giga-omgevingen een tijdje schaduw draaien waarna ze rekening voor rekening overzetten naar het nieuwe platform.

Volgens mij moet dat altijd wel kunnen. Maar ja, gelukkig hebben ze experts voor dat soort slimmigheden.

[CamelKnight]

Ik zal er blij mee zijn als de boete is voor het ongemak, MITS de boete er niet voor zorgt dat er nóg meer afstand tussen de stuurlui en de machinisten ontstaat.

De vraag in deze is heel erg 'Wie is er verantwoordelijk voor waarom het zo mis heeft kunnen gaan en waar wordt die verantwoordelijkheid neergelegd'. Als de verantwoordelijkheid bij de verkeerde neergelegd wordt (bv CEO is verantwoordelijk maar IT wordt als schuldige aangewezen) dan brokkelt daarmee de verstandhouding tussen andere afdelingen en IT nog verder af. IT wordt nog maar weinig vertrouwd want 'die faalactie heeft ons 48 miljoen gekost', er wordt nog minder in IT geïnvesteerd en uiteindelijk val je dan als bedrijf hoogstwaarschijnlijk om omdat je niet meer mee kan komen.

[Anoniem: 1837468]

Ik vraag mij als doorsnee consument altijd af waarom ICT projecten zolang moeten duren, gevalletje uurtje factuurtje?

Edit:
Een serieuze vraag die hoort bij het onderwerp is ook al een ‘irrelevant’

[Reactie gewijzigd door Anoniem: 1837468 op 23 juli 2024 04:17]

[david-v]

Voornamelijk mismanagement en de onkunde van een organisatie om agile om te gaan met IT. Ik zie nog steeds waterval om me heen, projecten die maanden dan niet jaren draaien om vervolgens weer de prullenbak in te gaan want niet meer van toepassing of voldoet niet aan de gewijzigde eisen.

De IT wereld heeft al enorme stappen genomen om dit probleem goed aan te pakken (onder andere met agile werken, devops enz), maar organisaties moeten daar nog enorm aan wennen en zijn vaak niet in staat om hier mee om te gaan. Inkoop wil graag weten wat het kost, managers willen weten wanneer het af is en wat ze gaan krijgen (waterval). In de tussentijd veranderd elke week/maand de scope van de opdracht....kan je weer opnieuw beginnen.

[WaarAnders]

Het woordje 'voornamelijk' dekt veel af, maar is dit gebaseerd op de bancaire wereld?

Misschien ook in andere sectoren, maar de veel gebruikte term MVP is bij banken soms erg lastig voor grote systemen. Zeker niet onmogelijk, maar je hebt echt heeeele goede mensen nodig die de hele keten goed kunnen doorzien als je aan de core processing systemen gaat sleutelen.
Voorbeeldje: een nieuw type transactie wordt geïntroduceerd op verzoek van klanten. Dat is niet een kwestie van een paar nieuwe velden aan de voorkant en klaar. Want dit moet ook door verschillende soorten risk management, finance, big data platforms externe connecties, compliance rapporten, etc etc. Voeg daaraan toe dat elke stap in tientallen legacy system en wat nieuwe gedaan moet worden en je hebt een ramp om echt agile uit te rollen. Er zijn een hoop stappen die 0 waarde zijn voor business / klant, maar wel nodig. Ook een hoop activiteiten die van elkaar afhankelijk zijn, zonder elkaar zijn ze onbruikbaar (denk aan risk en finance)

Ik zou graag goede ervaringen, artikelen, approaches en dergelijke lezen voor dit soort problemen

[FreezeXJ]

Wat je dan vooral nodig hebt zijn goeie specs, en vooral: heel veel losse blokjes. Alles in 1 gaat niet, je zult per onderdeel specs moeten hebben, en daar iets voor bouwen. Dat is lastig, want dan moet je gaan speccen wat er precies ge-risk-managed moet worden, en je zult veel nieuw moeten bouwen, want de huidige spaghetti is niet bruikbaar. Het punt is dat die stappen an sich 0 waarde hebben voor klanten, maar dat je daarmee wel risico vermindert. Daar zul je het mee moeten verkopen, inzicht en overzicht. "Kijk hier hebben we netjes in JSON op welke regeltjes er een mailtje naar compliance@bedrijf gaat" versus "Dat zit ergens in die module, en dan moet Piet een nieuwe build bakken die we dan door 3 man live laten zetten".

[Het.Draakje]

Punt is, die huidige spaghetti is er wel. En het werkt wel.

Afdeling A (woningfinanciering) heeft heel andere eisen dan afdeling B (Geldhandel) of C (Effectenhandel). Die afdeling woningfinanciering heeft eigen weinig budget, want er gebeurd niet veel in die markt. Maar de afdeling D (kredietrisico) is wel volop in beweging (moeten aan steeds meer wettelijke eisen voldoen). En dat kan weer impact hebben op de systemen van afdeling A. Die nauwelijks IT personeel heeft, want het systeem draait en verdere eisen hebben ze niet. En ach, 20 / 30 jaar terug deden we 'niet zo moeilijk' over documentatie. Dus werd e.e.a. wel gedocumenteerd in de wandelgangen. (Ik zie dat jij eigenaar bent van applicatie a, en ik kan gegeven xyz gebruiken dus geef je het even door als je dat gegeven aanpast?).

Nu willen we een bank met een web-site, e-banking en eTrading. Liefst ook met een goede risico-analyse (volgens de nieuwste inzichten) en geen belastingontduiking, terrorisme- of misdaadfinanciering. Ook uiteraard groen (dus niet beleggen in Oliemaatschappijen en zo. En aangezien het leven zo duur is, vooral gratis. Banken zoeken dus naar kostenbesparingen, waaruit mergers en (in het geval van TSB) afsplitsing en doorverkoop (TSB aan een Spaanse bank) aan de orde van de dag is.

Nu kun je denken, die banken hebben toch wel zo'n beetje dezelfde wensen (en dus systemen). Niet dus. De beleggingsmarkt die we hier hebben komt in het geheel niet overeen met die van Duitsland, Frankrijk of Amerika. En de wettelijke eisen nog minder. Ook binnen een land wijken de eisen die banken stellen van elkaar af. Dus bij een afsplitsing (of merger) wordt er gewoon een één op één kopie gemaakt (van de hardware, software en de data voor zover als dat nodig is) en daarna: succes ermee. Dan worden er wat extractie-programma's gemaakt zodat management zijn geconsolideerde rapportage kan krijgen en gaan met die banaan. Je mag blij zijn als je er nog wat expertise bijkrijgt. Hoofdzakelijk is dat de documentatie. En daar heeft, voor zover mijn ervaring strekt, iedere IT-er een hekel aan (om het te maken, laat staan om het bij te werken). JSON documentatie? Op cobol programmatuur van 30 jaar terug of voor een stuk ingekochte software? Dat geloof je zelf toch niet.

Maar de show must go on. Je hebt geen tijd om even een nieuw systeem neer te zetten. Dat duurt jaren. Als je geluk hebt. Met ruim veertig dienstjaren heb ik maar één keer meegemaakt dat er een nieuw hypothekenadministratie uitgerold werd.

Waarom denk je dat die 'nieuwe' financiële dienstverleners (zoals Revolut) het zo goed hebben? Zij beperken zich vaak tot enkele producten en een paar markten. En vooral: geen historische systemen. Zij kunnen hun bank inderdaad vanaf het begin opbouwen. En daar hebben ze vaak ook jaren over gedaan.

[WaarAnders]

Precies! Adyen nog zo'n voorbeeld, doen erg goed wat ze nu kunnen. Klein gestart, zonder spaghetti en slim aan het uitzoeken hoe ze uitbreiden. Maar ook die lopen tegen complexiteit aan nu ze verder komen.

Weet jij toevallig op welke site / blog /... Dit soort dingen veel besproken worden?

[WaarAnders]

Er zijn inderdaad een paar banken die in parallel een nieuwe bank proberen te bouwen, maar zelfs dat is complex. Een compleet nieuwe global payment engine zet je niet neer in 6 maanden, dus in die gehele transitieperiode moet je dus oplossingen vinden hoe je delen van het volume omzet naar de nieuwe engine. Alle betalingen in 1x overzetten wil je absoluut niet (check artikel )

[mutley69]

Organisatie en communicatie - en standvastigheid. Dat zijn i.d.d. de probleempunten. En 't is bijna overal van dat. De zorg voor de onderbouw is ook ondermaats - dat bewijzen de malware&ransomware-aanvallen.
En wat opgaat voor IT, geldt ook voor de rest van het bedrijf.

[Anoniem: 1837468]

Voornamelijk mismanagement en de onkunde van een organisatie om agile om te gaan met IT. Ik zie nog steeds waterval om me heen, projecten die maanden dan niet jaren draaien om vervolgens weer de prullenbak in te gaan want niet meer van toepassing of voldoet niet aan de gewijzigde eisen.

Dank voor je nette reactie, maar is er geen contract afspraak dat een bepaald project voor die en die tijd af/klaar moet zijn?

[Groningerkoek]

Bijna altijd zijn die data er wel, en vaak zijn daar ook boeteclausules aan verbonden. Maar die data worden alleen gehanteerd als de klant niets meer veranderd. Daarnaast is ook al gaat het fout het niet altijd de fout van de bouwer, die kan prima gebouwd hebben wat de klant vroeg, alleen vraag de klant niet goed genoeg naar wat die nodig had. En zeker bij grote organisaties is het lastig om de snelheid erin te houden omdat er teveel mensen die er niets van begrijpen bij het overleg zijn betrokken en helaas hebben die wel vaak een sterke mening over hoe het zou moeten.

Heel simpel voorbeeld, mijn neef heeft een paar bedrijven en hij is alleenheerser met zeer weinig IT kennis maar wel zeer sterke meningen over hoe en wat. Geeft een opdracht uit om een site met onder andere gebruikersprofielen te bouwen. Een week voor oplevering komt de vraag "Ik verwachtte een functie waar gebruikers tegen jaarlijkse betalingen met elkaar kunnen pm'en, en in elkaars fotoboek kunnen kijken." Dat 1e zat erin maar niet achter een betaalmuur want die was nooit genoemd, het 2e tsja.. dit was de 1e keer dat hij aangaf dat er zelfs maar een optie voor afbeeldingen moest zijn.

En naast andere dingen moest dat er dus allemaal nog in, en erger nog het moest goedkoop en snel en dan begint het echte gedonder. I.p.v. volledige integratie in de software wat duurder maar beter is wordt het deels elders weggehaald en aangepast en er maar bij gegooid waardoor eenheid verdwijnt, waardoor testen lastiger wordt, waardoor onderhoud lastiger en duurder wordt en de kans op fouten toeneemt en als er al een storing is duurt het vaak langer om die op te lossen en de opleverdatum tsja.. die ging in de vuilnisbak.

[Reactie gewijzigd door Groningerkoek op 23 juli 2024 04:17]

[bkor]

maar is er geen contract afspraak dat een bepaald project voor die en die tijd af/klaar moet zijn?

Volgens een analyse van/commentaar over de TSB migratie:

“This situation has all the hallmarks of business management strong-arming the IT organization into an unrealistic timeline. When business leaders push for overly-aggressive timelines, or regulators ask for multiple competing risk frameworks and excessive after-the-fact incident reporting, this all puts a strain on the delivery organization’s ability to untangle the complexity before ‘go live’. Business leaders must pay closer attention to IT estimates, especially those based on solid software intelligence, to drive more realistic timelines for mass systems transformations.”

Puur focussen op een deadline is ook niet de juiste aanpak.

[david-v]

Je hebt al een paar antwoorden gehad. Het belangrijkste is denk ik dit: bij standaard oplossingen weet je vaak wel wat de kosten zullen zijn en wat de doorlooptijd is, want, er is veel data van andere bedrijven die hetzelfde pad hebben doorlopen.

Maar, als je specifieke wensen hebt en je gaat zelf iets bouwen, dan is het vrij lastig om een prijs en datum af te spreken waarop het klaar is. Je kan het wel afspreken hoor, dat gebeurd heel vaak en is vaak de norm, maar het komt vrijwel nooit voor dat de prijs of de datum hetzelfde blijven. Je hebt dan de volgende scenarios:

• Klant is ontevreden en betaald niet of gaat op zoek naar andere leverancier
• Leverancier zal niks laten veranderen aan de opdracht, tenzij meer geld en tijd
• Klant is ontevreden, leverancier neemt de extra kosten op zich in de hoop dat ze ook het systeem in beheer mogen nemen of extra opdrachten gescoord kunnen worden
• enz

Dit alles staat lijnrecht tegenover een relatie klant-leverancier die opgebouwd moet worden vanuit het vertrouwen in elkaar, niet gebaseerd op de harde cijfers van een contract waar klanten en leveranciers graag mee zwaaien als het misgaat.

Er zijn genoeg alternatieven om dit proces beter aan te pakken, maar dat werkt anders, je weet niet hoeveel het gaat kosten en ook niet wanneer het klaar is, maar elke stukje functionaliteit die je krijgt is wel precies wat je wilt en de prijs is precies wat het gekost heeft om te bouwen. Deze manier van "Agile" werken, met een framework zoals Scrum, devops, enz kan je enorm helpen om je doelen te halen. Maar voor veel contract en inkoop mensen is het te vaag, want, geen vaste prijs of datum. Een dilemma voor veel bedrijven, maar ik denk dat het echt onvermijdelijk is.

[barbarbar]

IT projecten worden vaak ingewikkeld als een bedrijf iets wil wat niet standaard op de plank ligt. Denk aan het bouwen van een huis, dat is vrij simpel als je tegen de projectontwikkelaar zegt "doe mij die maar" en je er dan vervolgens tevreden mee bent. Het word een stuk lastiger, duurder en langduriger als je een villa bouwt die aan jouw hele specifieke eisen moet voldoen. Helemaal als je die eisen van te voren nog niet weet, en je er gaandeweg achter komt dat je toch elke keer wat anders wil.

Als je Office installeert zul je vrijwel geen problemen ondervinden met je "IT-project". Als je Office wilt nabouwen omdat jij tóch net iets bijzonders wil wat er niet in zit, dan gaat de teller lopen.

[gimbal]

Ik heb ooit aan een project gewerkt waar een oud stuk software vervangen moest worden met een web versie. Met bijna geen budget natuurlijk. Maar geen probleem want volgens de manager van het bedrijf waren 75% van de functies in de software overbodig dus die hoefden niet opnieuw gebouwd te worden.

6 maanden later: 100% van de functies moesten overgezet worden want oeps iemand ergens in het bedrijf vond het toch heel belangrijk. Dag deadline, hallo verdubbeling van budget.

En dat was maar een relatief simpel project met een behapbare scope, dan praten we niet over monsters die je vaak in overheidsomgevingen tegen komt.

Waarom lopen ICT projecten altijd uit? Omdat mensen.

[jhnddy]

Een huis kan je ook niet in 5 dagen bouwen, tenzij je alles van te voren prefabt en in elkaar past (Wordpress).

En aangezien er complexe eisen aan zulke systemen wordt gevraagd, en het moeilijk is om met teveel mensen tegelijkertijd aan hetzelfde stuk te bouwen, kost het tijd. En als je tijdens die tijd allemaal nieuwe eisen krijgt waardoor je je "fundering" moet aanpassen, tja...

[david-v]

De betrokken IBM experts (Mainframe uiteraard) zijn TSB dankbaar voor de vele uren die hiervoor in rekening zijn gebracht (dat zal ook wel in de miljoenen lopen schat ik zo). Die IBM mensen waren al duur 20 jaar geleden, nu zijn ze goud waard bij alle Mainframe klanten. Concurrentie op dat gebied is vrijwel nihil (90% mainframe markt in handen van IBM)

[Risce]

https://www.cityam.com/ib...t-after-digital-meltdown/

Een miljard.

[david-v]

Daar kun je wel een team van 1000 IBMers voor opzetten, voor één jaar (ik heb de prijs van 1000 euro per dag 20 jaar geleden maar verdubbeld, lijkt me wel correct?).

The TSB review has revealed a lack of technology literacy at the top of the organisation

Ik verwacht een reductie van 5% op de miljoenen bonus van het top management. zucht....

These highly complex systems must be rigorously tested before being implemented and long term strategic thinking is required when it comes to their design and architecture.

Hoe groter en complexer het systeem, hoe ingewikkelder. Misschien een tip....microservices? Maar ik vermoed dat hier nog steeds waterval proces gehanteerd wordt en enorme complexe systemen alleen maar groter én complexer worden. Maar goed, dat is mijn onderbuik gevoel en niet gebaseerd op feiten, want die kennen we niet.

[FreezeXJ]

Migreren is te duur (al jaren) waardoor je al tijden met een verouderd systeem zit waar je alle minpunten van kent... en nooit zult migreren. Nu moesten ze de stap eindelijk wagen, en dan weten ze al dat het fout zal gaan... en dus gaat het fout, ongeacht hoeveel mensen en managers je ertegenaan gooit. Opnieuw opbouwen is een no-go, want dan moet er meteen verbeterd worden, en krijg je een hopeloos project met tegenstrijdige requirements (die zijn er nu ook, maar zo lang je er niet aan zit kun je dat pareren met 'fiksen we ooit wel' ).
Van de grond af opbouwen kost jaren, maar is uiteindelijk wel nodig. Da's namelijk wat de startupjes doen die wel succesvol zijn; die sleuren de bagage niet mee. Daarnaast hebben de kleintjes nog geen track record. Als Bankiebank een dagje plat ligt is dat vervelend, en een leerproces. Als de ABN een dagje platligt komen er op z'n minst kamervragen, en vermoedelijk heel veel boetes en onderzoeken.

[david-v]

Als ik iets wel geleerd heb in software land is dat een big bang migratie nooit "goed" zal werken, te duur zal zijn en eindeloos lang zal duren. Dat moet je dus nooit doen. Maar dat is ook precies het doel van een architectuur waarbij je complexiteit in "stukjes" gaat hakken en van elkaar lostrekt. Je wilt niet één functie met 1000 regels code, maar 100 functies van elk 15 regels code. Je wilt niet een kolos van een applicatie maar modulariteit, flexibiliteit.

Geen big bang maar stuk voor stuk functionaliteit opnieuw bouwen en naast het legacy systeem plaatsen. Misschien doe je daar 5 of 10 jaar over, prima. Dat beter dan een kolos van een legacy systeem waar al 50 jaar aan gesleuteld wordt in stand houden door het nog complexer en groter maken.

[FreezeXJ]

Wat ik daarbij geleerd heb is dat je dan 100x je product management moet overtuigen dat je echt door moet met migreren, want anders loop je weer achter. Meestal is dan de keuze tussen snel en in legacy of meer werk en in een mooie service. Pas langzaam komt het inzicht op niet-technisch niveau er dat je toch weer door die zure appel heen moet, en dat snel-snel uiteindelijk langzaam is. Ik vrees dat het bij TSB nog even gaat duren als ik het zo lees.

[cariolive23]

Langzaam maar zeker nemen wel steeds meer banken (en andere organisaties) afscheid van het het mainframe. Zeer kostbaar en niet flexibel.

[david-v]

Afscheid nemen van IBM blijkt nogal een lastige te zijn is me al meerdere keren opgevallen. Ik kan me nog de tijd bij de belastingdienst herinneren waar uit de mainframe getallen in xml (xml werd dan zelf samengesteld als tekst in cobol) altijd met voorloopnullen eruit kwamen (000000000000000020000 was dan €200,00) en de ondersteuning voor iets anders dan ascii bij namen van particulieren met een buitenlandse naam "problematisch" was. Gelukkig was dat 20 jaar geleden en zijn we verder....toch?

[cariolive23]

Zelfs COBOL kan al enige jaren XML produceren en valideren, daarvoor hoef je geen stuk tekst aan te maken die er uit ziet als XML. Maar of de desbetreffende programmeur hier ook gebruik van maakt... Dat geldt ook voor het gebruik van voorloopnullen, volkomen zinloos maar mening programmeur wil het zo doen omdat ze dit altijd zo hebben gedaan. Bedragen in centen, nog zo'n ding dat ze doen omdat ze het altijd zo doen. Andere argumenten zijn er niet. Allemaal problemen die niet zijn gerelateerd aan het platform of de programmeertaal, maar voornamelijk de mensen die het gebruiken.

ASCII was al achterhaald toen het werd uitgevonden...

[david-v]

Ik heb het over 20 jaar geleden toen XML "relatief" nieuw was

[Het.Draakje]

De beweging die ik zag vóór mijn pensioen was dat het mainframe nog lang in gebruik zal zijn als een mega-database server. Waarop allerlei subsystemen met moderne technieken op aansluiten.

Vergis je ook niet in de kosten van alternatieve systemen. Een geclusterde Oracle database is ook niet goedkoop.

[ID-College]

Dit soort posts doet mij altijd denken aan projectdenken VS productdenken. In het belang van het project moet alles snel, en hoe het product er aan het eind bij staat: Who cares? Project toch gehaald dus we kunnen het "vieren". Vanuit het product gezien zou je meer tijd nemen om te kijken of het product wel echt een lang leven beschoren heeft op deze manier?

Ja er is een balans in de praktijk maar ik zie veel bedrijven nog steeds met een echte projectpet op, waar maar 1 ding telt: zsm live, met alle gevolgen van dien.. niets voor mij

[david-v]

IT governance is het belangrijkste bij een bedrijf. Je moet de kaders neerzetten waar een product aan moet voldoen. Statische code analyse (onderhoudbaarheid en security), dynamische code analyse (security) en het vermijden van "hacks" in de code. Hoeveel van ons heeft niet een keer in de comments "hack, lelijk, maar het kan niet anders" door druk vanuit de business geplaatst?

Gezien mijn positie kan ik steeds vaker nee verkopen, terwijl ik vroeger als jonge ITer maar mijn best deed om het op tijd af te kijgen met soms hier en daar een "hack" of een "todo" in de comments. Daar ben ik nu wel klaar mee. Of we maken het zoals ik/wij specialisten het zeggen of de business mag het zelf gaan programmeren.

[cariolive23]

Heeft ze in totaal een 80 miljoen pond gekost, waarbij 2 miljoen klanten ernstig zijn getroffen. Dus voor 40 pond per klant, kun je gewoon lak hebben aan je eigen klanten en hen ernstig in de problemen brengen. Ze konden geen geld opnemen, geen brood bij de bakker kopen, geen benzine voor de auto, niks. Helemaal niks meer. Onbegrijpelijk dat deze (of andere boetes) niet bij de verantwoordelijke managers zijn neergelegd, die wisten namelijk dondersgoed dat deze migratie bijna niet goed kon gaan. En geheel volgens verwachting ging het dus ook niet goed.

(was in die periode voor een andere klus betrokken bij deze bank, en in de wandelgangen ving je nog wel eens wat op)

[barbarbar]

Het is voor consumenten ook wel een les om niet hun hele financiële leven afhankelijk te maken van één aanbieder. We hebben zelf rekeningen bij zes banken waarmee we kunnen pinnen, en sparen en pensioen is ook bij meerdere ondergebracht. Onder andere voor risico spreiding. Het is vrij zuur als je een aanschaf wilt doen en je kun niet bij geld.

[cariolive23]

Alleen al die 6 banken kosten je een hoop geld aan vaste kosten. Denk je nou echt dat iemand met een modaal inkomen voor zoveel banken wil gaan betalen? En wat dacht je van mensen met een lager inkomen dan modaal? Niet realistisch.

Komt nog bij dat bankieren in Nederland erg goedkoop is, elders kan dat flink duurder zijn.

[barbarbar]

Maar twee daarvan betalen we voor. Er zijn genoeg gratis opties. N26, revolut, paypal kun je gewoon mee betalen in de winkel met je smartphone.

[Reactie gewijzigd door barbarbar op 23 juli 2024 04:17]

[Seal64]

Paypal kan ik met de beste wil van de wereld geen bank noemen, da's meer een creditcard/betalingsverwerker. Revolut is een Russisch/Oekraiense startup, maar geen bank. Ze hebben geen licentie.

Maar je punt gaat mank, want uiteindelijk moet je je salaris toch naar één rekening laten storten. Ik verwacht niet dat je werkgever meewerkt door je salaris in porties naar zes verschillende rekeningen te betalen. En als die bank toevallig degene is die zijn IT niet op orde heeft waardoor je niet aan je geld kan, dan kun je zoveel rekeningen hebben als je wil, betalen lukt dan alsnog niet.

[barbarbar]

Ja je kunt ook problemen zoeken waar ze niet zijn. Zet wat geld op een andere rekening en je hebt dan wat tijd om bij je werkgever je rekeningnummer aan te passen. Opgelost!

Hoezo is Revolut geen bank? Ik kan er toch echt gewoon mee betalen in de winkel. Er zijn genoeg alternatieven, bunq kan ook, open je een gratis spaarrekening en als je het toch nodig bent kun je alsnog een betaalrekening openen in 5 minuten.

Paypal kan ik ook gewoon koppelen aan google pay, en dan in winkels betalen. Ook ontvang ik daar gewoon inkomsten op.

Er is inmiddels meer in de wereld dan alleen de ouderwetse banken. Er is echt geen reden om door IT problemen bij één bank, zelf persoonlijk in de problemen te komen.

[Simon Weel]

@cariolive23 : die managers kregen waarschijnlijk een vette bonus omdat de migratie vlekkeloos verliep. De problemen daarna waren hun pakkie-an niet.... En dit soort boetes wordt zelden geïnd. Vele jaren en heel veel juridisch geharrewar later is de boete vaak van de baan of in elk geval een stuk minder.
En de klant - die kan toch 'gewoon' naar een andere bank gaan?

[cariolive23]

En de klant - die kan toch 'gewoon' naar een andere bank gaan?

Hoe zie je dat voor je? Jouw bankrekening is volledig geblokkeerd, kon je toen echt niks meer mee doen. Kun je wel een nieuwe rekening elders openen, maar dan heb je een bankrekening zonder geld. En ook daar kun je niet zo veel mee...

Klanten van TSB moesten bij vrienden, familie en buren bedelen om geld, om tenminste hun dagelijkse boodschappen nog te kunnen doen. En geen enkele manager is daarvoor gestraft...

[FreezeXJ]

Dan is de vraag of en waarom ze nu nog steeds klant van TSB zijn... De bestraffing moet niet van boetes komen, maar doordat ze 0 klanten overhouden.

[barbarbar]

Uiteraard moet je een alternatief al klaar hebben voordat je er problemen zijn. Er zijn echt wel genoeg opties inmiddels, ook gratis rekeningen, die je zonder moeite kun aanvragen. Zet er een noodgevallen potje op.

Toen het gedoe met icesave en dsb was, heb ik gezorgd dat ik voortaan altijd meerdere opties heb qua bank en rekeningen. Stuk spreiding kan geen kwaad.

[PinusRigida]

Laat me raden: het uitgelezen excuus om zowel op website als telefonisch aan de klanten te melden dat omwille van technische storingen, er extra lange wachttijden zijn, en hun oproep mogelijks niet beantwoord wordt met droogweg de melding "bel op een ander moment terug" waarna ingehaakt wordt, waarbij op gelijk wélk 'ander moment' de klant aan exact hetzelfde lijntje gehouden wordt?

Ze doen het sowieso al, laat ze dan ook nog een lang aanslepende technische storing hebben en het hek is helemaal van de dam, kwam ze wellicht goed uit om te laten aanslepen en zo te blijven besparen op klantendienstmedewerkers en klachtenbehandelaars, zoals tegenwoordig quasi overàl waar je als klant naar belt. 1 vraag = een paar uur van je dag kwijt en met geluk gedurende 5 minuten een medewerker aan de lijn die je met hoorbare tegenzin zeer minimaal helpt.

Ik chargeer misschien... maar dit soort praktijken zijn helaas alomtegenwoordig.

[bkor]

Laat me raden: het uitgelezen excuus om zowel op website als telefonisch aan de klanten te melden dat omwille van technische storingen, er extra lange wachttijden zijn

Ik raad je aan om het originele rapport te lezen. Behoorlijk leesbaar. Het geeft behoorlijk duidelijk weer dat het aantal medewerkers aan de klantenservice echt nietszeggend was in vergelijking met alle andere gigantische missers. Voor de klantenservice: ze hebben niet getest of het systeem het aantal mobiele klanten aan kon. Door alle problemen werkten de nieuwe systemen ook intern nauwelijks. Zelfs met meer medewerkers kan zo'n klantenservice ook niks doen als je gewoon niet van tevoren test of het systeem wel genoeg capaciteit heeft. Zie punt 2.14 in bovenstaand rapport. Echt beschamend hoe de top met deze verandering is omgegaan. Lijkt wel of ze alle verantwoordelijkheid aan het IT bedrijf hebben gegeven als een soort "cover your ass" actie ofzo. Dat is niet handig bij zo'n kritieke verandering.

[PinusRigida]

Thanx.
Je hebt gelijk, beschamend, incompetent zelfs.

[KKose]

Ik las eerst 'britse tank'...man man

[WaarAnders]

Deels gerelateerd, zijn er goede communities, blogs, yt channels, websites waar bancaire IT (use cases) is besproken?

En dan heb ik het niet over bank A koopt systeem XYZ