IT-aorta voorkomt data-infarct (II)

Transcriptie

1 INFORMATIETECHNOLOGIE F. Conijn RA, drs. R. Klop, drs. F. van der Waa RA, World Class Finance, onderdeel van Atos KPMG Consulting Van houtje-touwtje-oplossingen naar maatwerk IT-aorta voorkomt data-infarct (II) Door fusies, een steeds kortere time to market voor de lancering van nieuwe producten en het inspelen op vragen van klanten en andere stakeholders is bij veel organisaties sprake van een groeiende informatiebehoefte. Om in deze behoefte te voorzien, wordt vaak gebruikgemaakt van te snel ingevoerde deelsystemen, die veelal provisorisch gekoppeld zijn aan reeds bestaande, deels zelfgebouwde systemen. Dit resulteert in een wirwar aan gegevensverwerkende systemen (houtje-touwtjeoplossingen), die steeds sneller een sterk groeiende stroom aan data moeten verwerken. Een data-infarct dreigt. In dit artikel staat het behandelplan centraal. 59 FRED CONIJN, RONALD KLOP EN FRED VAN DER WAA

2 60 In deel I gingen we in op de componenten van de IT-architectuur en de ontwikkelingen op softwaregebied. Daarna zijn we ingegaan op de signalen die duiden op een naderend datainfarct. In dit artikel gaan we in op de knelpunten en presenteren we een aanpak. Verschillende prioriteiten Een belangrijke randvoorwaarde voor het aanpakken van de problematiek van de IT-architectuur is een eensgezind managementteam dat het strategisch belang van IT onderkent en bereid is samen te werken. Men zal persoonlijke belangen en prioriteiten over boord moeten zetten (zie figuur 1). In figuur 1 is ervan uitgegaan dat er op managementniveau een CIO of informatiemanager is. In veel Nederlandse multinationals doet één van de leden van de raad van bestuur IT er helaas nog bij. Maar stel dat dit niet het geval is, dan moet de CIO dus in staat zijn op strategisch niveau invulling te geven aan de IT. Daarnaast moet hij niet alleen voldoende invloed hebben om de individuele prioriteiten van de andere bestuursleden te stroomlijnen, maar ook in staat zijn om de veranderingen echt te implementeren. De informatiemanager dient beide informatiestromen (externe verantwoording en interne sturing) te faciliteren. De financial accounting (FA) is vooral extern georiënteerd op verantwoordingsinformatie, die volgens een vaste periodiciteit (maandelijks, kwartaal, halfjaar, et cetera) naar buiten wordt gebracht. Deze verantwoording voldoet aan een aantal verslaggevingsregels (IAS of US GAAP) en is redelijk gedetailleerd. De gepresenteerde cijfers dienen immers consistent en betrouwbaar te zijn. De functionarissen die zich bezighouden met management accounting hebben een hele andere informatiebehoefte. Voor de dagelijkse of wekelijkse aansturing van de interne organisatie willen zij inzicht hebben in de orderportefeuille, de marges op verkochte producten, actuele debiteurenstanden enzovoorts. Deze managementinformatie zal niet voor 100 procent achter de komma correct hoeven te zijn, de gegevens dienen slechts om de richting te kunnen bepalen en de organisatie proactief te kunnen bijsturen. Kortom de functionele eisen voor financial en management accounting verschillen met betrekking tot: de frequentie van de gewenste rapportages en analyses; de mate van gewenst detail-inzicht; de benodigde doorrekencapaciteit (verrijkingsprocessen zoals allocatie, validatie, eliminatie, consolidatie en simulatie van financiële en niet-financiële gegevens). De vertaling van deze functionele eisen naar IT-eisen is een slag die een informatiemanager voor zijn rekening zal moeten nemen. Hij of zij zal moeten toetsen of de ingezette architectuur wel robuust genoeg is en uit beheersoogpunt wel zo lean and mean mogelijk is opgezet om efficiënt en effectief te blijven opereren. De informatiemanager heeft tevens tot taak om de beheersinspanning te minimaliseren en de gerelateerde beheerskosten in de hand te houden. Complexiteit Het is vaak de onderlinge samenhang die IT-problemen bij het ontwerpen van een gedegen IT-architectuur in de praktijk zo complex maken. Een simpel voorbeeld. Om een hondenhok te bouwen heb je naast wat creativiteit, hout, spijkers, verf, een aantal gereedschappen nodig. Het ontwerp kan uit de losse pols op één A4 (in het slechtste geval kan het hok weer worden afgebroken en opnieuw worden opgebouwd). Voor de bouw van een hotel daarentegen is een gedegen ontwerp absoluut noodzakelijk. Het ontwerp dient rekening te houden met veiligheidsaspecten, lichtinval en liftschachten en voorzien te zijn van een fundering die rekening houdt met toefiguur 1 Verschillende prioriteiten De leden van het managementteam... Financial accounting (CFO) Uitgangspunten externe verantwoording Legal consolidation Periodieke externe rapportages IAS/ US GAAP-waarderingsbeginselen Toezichthouders (DNB, STE) Operationeel: cash management, asset management Strategisch: VBM Management accounting (CEO/COO) Uitgangspunten interne sturing KPI s/ performance management Inzicht in kosten (cost management) Inzicht in orderportefeuille/marges/ winstgevendheid klanten Productmarktcombinaties Onderliggende IT-architectuur (CIO) Uitgangspunten ten aanzien van IT-beheer Lage beheersinspanning/ beheerskosten Passend binnen IT-beleid (huidige ERP-inrichting) Schaalbaarheid voor toekomstige ontwikkelingen... hebben verschillende prioriteiten

3 komstige uitbreidingen. Alle mogelijke figuur 2 bouwcomponenten dienen al op de tekentafel op elkaar te worden afgestemd, voordat er daadwerkelijk wordt begonnen met de bouw. Het ontwerpen van een stad is nog complexer. Als gevolg van een jarenlange historie is er vaak een aantal facetten aanwezig waaromheen zal moeten worden ontworpen. Het ontwerp zal beleidsplanmatig worden ingestoken en zal door de jaren heen met zowel mee- als tegenvallers te maken krijgen. Een stad in zijn geheel afbreken en opnieuw opzetten is uit economisch oogpunt onbespreekbaar, voor een hotel is dit ook al moeilijk, maar kan het een optie zijn. Het ontwerp van een IT-architectuur binnen een organisatie nu bevindt zich qua complexiteit tussen het ontwerp van een hotel en een stad, waarbij het beleidsmatige (van een stad) belangrijk is en de mogelijkheid tot opbouw van scratch af aan (van een hotel) tot de mogelijkheden behoort. Hierdoor kan met een state-of-the-art technisch platform de functionele oplossingsrichtingen worden ingevuld zonder historische belemmeringen uit het verleden. Complicerende factor is dat de reguliere activiteiten wel gewoon door moeten gaan. Vandaar dat een groeimodel meestal de voorkeur heeft, waarbij stap voor stap naar een state-of-the-art informatievoorziening wordt toegegroeid. Groeimodel Met een groeimodel worden de huidige problemen opgelost en wordt geanticipeerd op toekomstige ontwikkelingen. Het vraagstuk rondom IT-architectuur kan niet los worden gezien van de binnen een organisatie aanwezige bedrijfsprocessen en de inhoud van rapportages. Deze drie facetten (processen, IT-architectuur en inhoud) dienen zich in een bepaalde balans tot elkaar te verhouden om efficiënt en effectief te kunnen opereren. In figuur 2 zijn deze drie facetten in de tijd qua ontwikkeling weergegeven. Daarbij onderscheiden wij de volgende fasen: Fase 1: manuele houtje-touwtje informatievoorziening Fase 2 : geautomatiseerde houtje-touwtje informatievoorziening Fase 3 : geïntegreerde informatievoorziening Fase 4 : IT op maat Fase 1: manuele informatievoorziening In deze fase zijn allerlei stand-alone softwareoplossingen in gebruik waarmee afzonderlijke standaardrapportages kunnen worden gegenereerd. Er bestaan geen interfaces tussen oplossingen, zodat er veel tijd en energie gaat zitten in het verwerken van data om acceptabele managementinformatie te kunnen opleveren. Als uw organisatie zich nog in deze fase bevindt, heeft u zelfs geen tijd om dit artikel te lezen. Transformatie van managementinformatie (content) Fase 2 : geautomatiseerde houtje-touwtje informatievoorziening In fase 2 zijn de afzonderlijke softwareoplossingen met interfaces aan elkaar gekoppeld. Al deze oplossingen zijn vaak afzonderlijk geïmplementeerd en zullen allemaal beschikken over hun eigen stambestanden (metadata) zoals rekeningschema s, organisatiestructuren, product-/artikelstructuur, klantstructuur en branche- en geografische indelingen. Wijzigingen in deze stambestanden worden in alle oplossingen afzonderlijk onderhouden. De rapportages kunnen bestaan uit samengebrachte actuals en budgetcijfers en geven inzicht in de onvolkomenheden van de onderliggende bronsystemen. Eventuele reparatiewerkzaamheden van deze onvolkomenheden dient in het bronbestand plaats te vinden, die vervolgens via de interfaces uiteindelijk resulteren in redelijk betrouwbare gerapporteerde cijfers. De ingerichte processen zullen in geval van reparatiewerkzaamheden van begin tot eind moeten worden doorlopen. Fase 3 : geïntegreerde informatievoorziening In fase 3 wordt er gestreefd naar één centrale plaats waar de stambestanden onderhouden worden, waardoor aansluitend geïntegreerde rapportages (bijvoorbeeld actuals, budget- en ABC-gegevens) kunnen worden gecreëerd. De onderliggende processen in fase 3 kennen een hoge mate van integratie doordat ze op elkaar afgestemd zijn tijdens het ontwerp. Doordat het beheer in deze fase van de stambestanden effectief plaatsvindt, is er qua tijdsbesteding meer ruimte voor analyse-activiteiten. De tussenopslag van data (eigenlijk dode data) dient regelmatig te worden ververst. 61

4 62 Fase 4 : informatievoorziening op maat Tot slot laat fase 4 een ideaalsituatie zien, waar de inhoud van rapportages een hoge mate van voorspellende waarde heeft, continu up-to-date is en de processen een virtueel karakter kunnen hebben (niet-plaatsgebonden). De ondersteunende IT-architectuur is lean and mean en prikt rechtstreeks in op onderliggende bronsystemen. Having the right info when you need it en The continuous monitoring and analysis of critical info necessary to effectively run the business zijn in dit verband bijvoorbeeld kreten die Cisco Systems voor deze fase hanteert. Ten behoeve van het groeimodel is een uitgebalanceerd IT-beleid cruciaal. De visie op het groeimodel moet in het beleid verankerd zijn. Dit beleid vormt de basis voor selectie en investeringsvraagstukken. Een ander aspect is de benodigde flexibiliteit om overnames in een acceptabele tijdspanne te kunnen incorporeren. Na een fusie zal er in eerste instantie worden gekozen voor een geautomatiseerde houwtje-touwtje informatievoorziening die later nog moet worden geïntegreerd. Bovendien zorgen de technologische ontwikkelingen op het terrein van hard- en software ervoor dat periodiek beoordeeld moet worden welke zwakste schakel van een architectuur moet worden vervangen. Ook dit aspect zal in het IT-beleid moeten worden meegenomen. Gelet op het voorgaande lijkt het ondenkbaar voor organisaties om van scratch af aan een IT-architectuur op te bouwen. Toch lijkt een gefaseerde aanpak op korte termijn concrete resultaten op te leveren. Een vooronderzoek (fase 1) van enkele tientallen dagen ligt hieraan ten grondslag, gevolgd door een fase van prototyping (fase 2) met een beperkte scope gedurende ongeveer drie maanden. De opgedane ervaringen tijdens deze twee fasen geeft een scherper inzicht in de gewenste content van de rapportages, de processen die geraakt worden voor de totstandkoming van deze rapportages en de efficiënte inzet van IT-oplossingen (componenten IT-architectuur) om dit te faciliteren. Vervolgens kan de afbouw (fase 3) plaatsvinden voor de gehele informatiehuishouding. Samengevat luidt het credo: Think big, start small, act quickly. Fase 1: Vooronderzoek Tijdens het vooronderzoek wordt op hoofdlijnen een totaalbeeld vastgesteld. Vragen die daarbij beantwoord worden zijn: waar staat de organisatie momenteel in het groeimodel? Welk ambitieniveau heeft de organisatie ten aanzien van kosten, snelheid, relevantie en juistheid? Waar wil de organisatie aan het eind van fase 3 staan? Welke deliverables zijn per fase te verwachten? Een ander onderdeel van dit vooronderzoek heeft betrekking op de scope van fase 1 en fase 2: er worden bijvoorbeeld vijf representatieve managementrapporten of KPI s geselecteerd als onderzoeksterrein. Afzonderlijke interviews met de CFO, CEO en CIO alsook interviews met al deze functionarissen gezamenlijk zal op bovenstaande vragen en de scope antwoord moeten geven. Als afsluiting wordt een functioneel en technisch ontwerpplan opgesteld voor wat betreft de activiteiten van fase 2. Het vooronderzoek geeft inzicht in de kwaliteit van de gegevens in het bronsysteem, de noodzaak en mogelijkheden van data modelling en de inspanningen die nodig zijn voor enerzijds het inrichten van processen en inhoudelijke rapportages/kpi s en anderzijds het inrichten van de componenten van een IT-architectuur. Na een fusie kiest men vaak voor een geautomatiseerde houtje touwtje-oplossing Het team dat het onderzoek uitvoert beschikt over expertise met betrekking tot alle componenten van de architectuur (transaction processing, data modelling, calculation engine, data collectie en data delivery), procesverbeteringen, managementrapportages en de onderliggende definities, technische hardware en connecties tussen hard- en softwarecomponenten. Het team wordt uiteraard geleid door een projectmanager die van alle markten thuis is, om ervoor te zorgen dat al deze experts goed samenwerken en tot concrete resultaten komen. Fase 2 : Prototype Een kopie van de brondata wordt opgenomen in het solution center in hetzelfde softwarepakket waarover de organisatie beschikt. Dit zal als bronsysteem dienen. Overeenkomstig het ontwerp kan vervolgens een ETL-tool in combinatie met calculation engines en/of business intelligence-tools worden ingericht, die resulteert in de vooraf vastgestelde rapportages/kpi s. Alle componenten van een IT-architectuur komen in dit vooronderzoek aan bod. De routing van fase 2 bestaat uit vier stappen (zie figuur 3): het vaststellen van wensen. In het vooronderzoek wordt de scope (de vijf rapporten/kpi s ) en het ambitieniveau als vertrekpunt bepaald. figuur 3 Het creëren van een informatiebrug Vaststellen van wensen Het creëren van een Gewenste data Ontwerp haalbare informatiebrug architectuur Realiseren van rapportages Componenten van een IT-architectuur: Infromation delivery Datacollectie Calculation engines Datamodellering Transaction processing

5 Knelpunten In dit kader worden vijf knelpunten besproken die van invloed zijn op de te hanteren aanpak. Het is aan u om te bepalen in hoeverre deze voor uw organisatie van toepassing zijn. Er is sprake van een historisch gegroeide lappendeken aan systemen, bestaande uit tientallen jaren oude legacy-systemen. Daarnaast zijn afdelingsgewijs tools geïmplementeerd, bijvoorbeeld voor het ondersteunen van de financiële functie (cash management-, budgettering-, activity based costing-, consolidatie, risico-analyse), de commerciële functie (CRMtools), de inkoop-, de productie- en de logistieke functies (ERP-solutions). Het vervangen van deze tools mag niet leiden tot verstoring van de reguliere werkzaamheden. De impact op deze systemen moet dus worden nagegaan. Tevens zal op basis van een risicoanalyse moeten worden bepaald welke fall back-scenario s beschikbaar zijn. De reactiesnelheid en de onderzoekskosten laten te wensen over. Door de toenemende complexiteit binnen een historisch gegroeide IT-architectuur gaat elke aanpassing gepaard met grote inspanningen om de impact van dergelijke aanpassingen exact te kunnen vaststellen. De onderzoekskosten nemen exponentieel toe. Het kost de ICT-afdeling bovendien steeds meer tijd om dergelijke processen te begeleiden: de reactiesnelheid neemt sterk af. De vereiste samenwerking tussen de betrokkenen komt slecht van de grond. De samenwerking tussen CFO, CEO en CIO laat te wensen over: bij verschillende implementatievraagstukken worden de functionele gebruikerseisen en de technische IT-eisen onvoldoende doorgesproken en kan geen extrapolatie naar de toekomst worden gemaakt. Er is een gebrek aan uniformering. De definities van informatieobjecten (wat zijn de definities van posten als omzet, overige kosten en een FTE?) worden niet geregistreerd en dus door de verschillende functionele participanten binnen een organisatie naar eigen inzicht geïnterpreteerd en gerapporteerd. Uit recent onderzoek van Atos KPMG Consulting tijdens de jaarlijkse Nationale Administrateurs en Controllers Dag blijkt overigens dat men inmiddels bij het merendeel van de organisaties (64 procent) uniformering heeft doorgevoerd. Mensen kunnen niet multi-dimensionaal denken Mensen kunnen niet multidimensionaal denken. De techniek, zoals bijvoorbeeld de opslagcapaciteit in de jaren tachtig, is tegenwoordig geen beperkende factor meer. De mens is een beperkende factor geworden: het denken en communiceren in een x- en y-as eventueel gecombineerd met z-assen (voor het inzicht in verschillende managementdimensies) is voor de mens lastig. In de financiële hoek wordt voor de informatievoorziening bijvoorbeeld nog vaak in rekeningschemastructuren gedacht. Terwijl er bij de invoer eigenlijk sprake is van een sleutel waarmee informatie op verschillende manieren kan worden ontsloten. Hierdoor is sprake van inefficiënte en onvolledige implementaties, waardoor de verwachtingen groot zijn en de resultaten teleurstellend. 63 het creëren van een zogenoemde informatiebrug. In fase 2 wordt het prototype gebouwd. Er wordt een informatiebrug geslagen tussen transaction processing-data en information delivery door de IT-architectuurcomponenten in te richten voor het functionele ontwerp. De processen die nodig zijn om deze stappen te realiseren worden in kaart gebracht. het ontwerpen van een haalbare architectuur. het realiseren van de rapportages. Als afsluiting wordt getoetst of de ingerichte architectuur toereikend is en overeenkomstig het ontwerp is om vanuit de brondata (transaction processing) via data modelling en de andere ingerichte componenten te komen tot het gewenste eindresultaat, namelijk de rapportages/ de KPI s. Als afsluiting van fase 2 zal worden geëvalueerd wat de bevindingen zijn van het prototype, teneinde fase 3 scherp te kunnen inschatten. Fase 3: Definitieve afbouw van de overige rapportages en/of KPI s Met de ervaringen uit fase 2 kan het projectteam voor de inrichting van de overige rapportages/kpi s worden vastgesteld. Een beperkter aantal materiedeskundigen zal hierbij een rol spelen. Idealiter wordt het project samengesteld uit personen die afkomstig zijn uit de eigen organisatie. Het oplossen van vraagstukkken die verband houden met de ITarchitectuur in een organisatie werd vroeger meestal gedomi- neerd door technici. Resultaat: projecten met ellenlange doorlooptijden waarbij grote onbeheersbare gegevenspakhuizen werden opgeleverd. Op het moment van oplevering bleek bovendien dat de oorspronkelijke informatiebehoefte inmiddels was gewijzigd en dat het ontwikkelde model onvoldoende flexibel was om de managementvragen van vandaag, morgen en overmorgen te beantwoorden. Aandacht voor de achterliggende processen en de inhoud van rapportage-onderdelen waren niet in balans gebracht met de ingerichte techniek. De verwachte stap voorwaarts werd niet gerealiseerd en er ontstond een oneigenlijk beheer van stambestanden die werden toegepast voor meerdere tools. Onze aanpak daarentegen is incrementeel. De resultaten worden door prototyping en quick wins heel snel concreet en zichtbaar gemaakt. In de projectaanpak speelt de techniek een belangrijke rol, maar het project is functioneel gedreven met aandacht voor de achterliggende processen en de betrokken medewerkers. Er wordt een gedegen balans aangebracht tussen de ingezette techniek en de aansluiting met de business. Samen groeien zij stap voor stap naar de nieuwe situatie, gebruikmakend van de opgedane ervaringen en inspelend op nieuwe ontwikkelingen. Door deze inspanningen worden de datastromen steeds gezonder en wordt een data-infarct voorkomen. De auteurs hebben meegewerkt aan het boek 'World Class Finance in praktijk' (ISBN , zie C