Blog

Wat staat er te doen voor de CIO nu de staatsbank Fortis waarschijnlijk ABN Amro gaat heten?

De overheid koopt Fortis. ABN Amro is het grootste onderdeel, dus wellicht gaat die combinatie volgens Wellink ABN heten. Maar hoe zit dat dan nu met eigenaarschap en innovatie in de nieuwe duo-organisatie?

Dit is een vraagstuk want 1) de huidige noodzakelijke veranderingen moeten in goed tempo blijven doorlopen bij de organisaties en 2) nieuwe noodzakelijke verandering moeten in goed tempo kunnen worden opgestart en 3) de nieuwe 'tijdelijke' duo-organisatie zorgt voor een aardverschuiving van de businesscase voor de huidige en nieuwe veranderingen.

Vanuit architectuuroogpunt ben ik nu zeer benieuwd in welke mate besturing, bedrijfssystemen, informatievoorzieningen en ICT-Infrastructuren worden geïntegreerd in totaal, op specifiek bankgebied en op specifiek verzekeringsgebied. En welke sourcingstrategie heeft men voor ogen? In het verleden heeft ABN Amro volgens mij haar verzekeringstak bij Delta Lloyd neergelegd. In hoeverre wordt nu de interne ICT van ABN leading. Dat lijkt mij ook het vraagstuk nu: Wie is er eigenaar van een bouwsteen van de organisatie? Ook al schuif je wel en niets in elkaar.

Hoe zijn de businesscases nu onderliggend aan allerlei veranderingen, initiatieven en projecten bij de nieuwe organisatie? Voor de CFO's en CIO's van Fortis en ABN is dit allemaal een geweldige opgave. Want immers, wat zijn de strategische uitgangspunten en architectuurprincipes voor de nieuwe combinatie als geheel, voor de organisaties afzonderlijk en voor de bankactiviteit en verzekeringsactiviteit afzonderlijk? Wie gaat nu welke kosten dragen (zoals voor infrastructuurprojecten)? Welke veranderprogramma's worden in elkaar geschoven en met elkaar in lijn gebracht?

Deze strategische uitgangspunten en architectuurprincipes MOETEN nu snel inzichtelijk worden gemaakt, met name op ICT gebied, wil de CIO snel een hernieuwd Business-IT-vernieuwingsplan op kunnen stellen.

Zeven actiepunten die ik zo op het eerste gezicht zie zijn:

  1. JEAP - De CIO of CFO dient samen met de enterprise architecten een Joint Enterprise Architecture Program op te starten voor de (beide) organisatie(s). Dit bundelt krachten en activiteiten.
  2. Uitgangspunten en Principes - In dit EAP programma dient binnen een maand een architecture principles document ligt op tafel waarin de tien belangrijkste strategische uitgangspunten en architectuurprincipes staan voor de belangrijkste activiteiten/onderdelen van de nieuwe organisatie op minimaal drie beschouwingsniveau's: keten, onderneming, bedrijven. De enterprise architecten dienen de executives (bestuurders en directieleden) te klankborden hierin zodat de executives op deze wijze de enterprise architectuur en enterprise transformatie sturen.
  3. Structuurplan - De CIO of CFO van de nieuwe organisatie dient de architectuurontwerpopdracht te krijgen van de CEO om een structuurvisie en een structuurplan te laten maken ism met de architecten. Er moet een structuurvisie worden gemaakt (een plaatje van alle systemen en domeinen voor besturing, business, informatievoorziening en ICT-Infrastructuur voorzien van eigenaren) als onderdeel van een structuurplan. Een structuurvisie kun je ook een systemen- en domeinenmodel noemen. In de structuurvisie staan alle domeinen en systeem die er in de oude en nieuwe organisatie te onderkennen vallen. Er dienen van drie situaties structuurvisies te worden gemaakt. De huidige situatie (AS-IS) van beide organisaties (dit zou je het bestemmingsplan kunnen noemen). De next step situatie (Plateau 1) voor over een jaar (met scenario's zoals 1: integratie van alles, 2: samenwerking bij alles) en de toekomstige (TO-BE) voor over drie jaar. Gezien het feit dat de overheid nu al zegt over drie jaar de boel weer te verkopen is het niet slim een Envision situatie voor over 7 jaar te maken. Een structuurplan en structuurvisie geeft overzicht en inzicht. Eigenaarschap wordt duidelijk. Eigenaarschap is nodig om veranderingen op gang te krijgen en te houden. De uitgangspunten en principes zijn nodig om de structuurvisie en het structuurplan te kunnen maken.
  4. Blauwdruk (het product) - Een volgende architectuurontwerpopdracht kan worden gegeven. De structuurvisie kan nu als achtergrond worden gebruikt voor het maken van een blauwdruk van de nieuwe organisatie(s). Maak voor alle situaties een blauwdruk (AS-IS, P1, TO-BE). Door in alle domeinen en systeem de nieuwe en huidige soorten oplossingen in die systemen en domeinen te plotten inclusief samenhang en afhankelijkheden, zie je de blauwdruk ontstaan van de nieuwe organisatie(s). Met deze blauwdruk kunnen bijvoorbeeld conflicten in bijtende oplossingen worden opgelost. Op de tekentafel is dit vele malen goedkoper dan als men al in programma's bezig is. In de blauwdruk indien mogelijk ook kavels onderkennen en die kavels een volgorde geven waarin ze kunnen worden gerealiseerd.
  5. Programmamanagement View (het proces) - Met de blauwdruk (AS-IS, Plateau1 en To-BE) als achtergrond kunnen in een programma-management-view alle strategische doelen (voor keten, onderneming en bedrijven) en strategische veranderingen m.b.t. huidige en nieuwe strategische soorten oplossingen, huidige en nieuwe programma's worden geplot. Dit is nodig om te zien welke veranderingen en programma's elkaar gaan verstrekken of tegenwerken. Deze programma-management-view zorgt ervoor dat issues en showstoppers in en over heen programma's sneller kunnen worden gespot en voorkomen. In deze view is de tijdsplan en planning van groot belang.
  6. Masterplan voor de vernieuwing - Op basis van de vorige genoemde punten dienen er programma's te worden gestopt, gestart en omgebogen. Zet dit met een duidelijke tijdslijn, opdrachtgevers en doelen in een document en noem dit masterplan. Wijs een eigenaar en opdrachtgever van het plan aan. Dit 'vernieuwingsplan' is voor iedereen leidraad in alles wat er aan veranderingen wordt uitgevoerd.
  7. Rommel opruimen - Het is nu eindelijk een kans om allebei de rommel op te ruimen. Net zoals bij mensen die gaan samenwonen. Met rommel bedoel ik slechte of halve implementaties van oplossingen killen of goed doen/migreren. Hierbij kan men met de eerder genoemde producten zoals een blauwdruk kijken naar onnodige dubbelingen in oplossingen en middelen. Denk maar aan mislukte interfacing op component based development gebied. Ga nou niet op basis hiervan aan de gang met service oriëntatie. Ook een gemeenschappelijk begrippenkader kan nu ook eens worden gemaakt. Weg met de miscommunicatie voor bijvoorbeeld begrippen zoals klant, product, formule, contract, pakket, service en applicatie.

 

Ik ben benieuwd welke actiepunten anderen hieraan toe zouden willen voegen. Het lijkt mij dat wij als architecten-community toch een bijdrage kunnen leveren aan de plannen van die nieuwe geweldig grote en ambitieuze bank/verzekeraars-combinatie. Wij en zij (de 2 banken) hebben nu de mogelijk om het goed te doen. Het enige is dat de goede architectuurontwerpopdracht op het juiste moment door de executives aan de kwalitatief goede enterprise architecten wordt gegeven die in naast de opdrachtgever gaan staan en niet aan IT-ers, leveranciers, consultants of adviseurs. En waarom niet zoals in de bouwkundige wereld, door middel van een serieuze ontwerpwedstrijd?

Deze blog is geschreven door Mark Paauwe. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.