T I J D S C H R I F T CONTROLLING
I N F O R M AT I E T E C H N O L O G I E
F. Conijn RA, drs. R. Klop, drs. F. van der Waa RA, World Class Finance, onderdeel van Atos KPMG Consulting (
[email protected])
Her ken de vo or t ekenen
nr 11
november 2002
IT-aorta voorkomt data-infarct (I)
46
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, die steeds sneller een sterk groeiende stroom aan data moeten verwerken. Een data-infarct ligt op de loer.
FRED CONIJN, RONALD KLOP EN FRED VAN DER WAA Alleen menselijk ingrijpen kan een data-infarct nog voorkomen. Veel organisaties zijn daarom momenteel bezig met het te ontwarren van de kluwen aan systemen, die een belemmering vormen om verbeteringen in de bedrijfsvoering door te voeren. Een adequaat functionerende informatievoorziening is daarvoor immers een randvoorwaarde. In twee artikelen beschrijven wij de voortekenen van een dreigend data-infarct en leren wij hoe u deze signalen tijdig kunt herkennen. Tevens geven wij u tips hoe u een data-infarct kunt voorkomen. In dit eerste artikel behandelen we de relevante ontwikkelingen op software-gebied en de contouren en de elementen van de ITarchitectuur. Tevens schetsen we de verschillende stadia waarin uw organisatie zich kan bevinden voor wat betreft de IT-architectuur-problematiek. Onder IT-architectuur verstaan we ‘het geheel van soft- en hardware, inclusief de benodigde connecties, die ervoor zorgt dat soft- en hardware met elkaar kunnen communiceren, zoda-
nig dat we de software vanuit gebruikersoogpunt kunnen gebruiken.’ Een IT-architectuur bestaat uit vijf componenten: transaction processing, data modelling, calculation engines, datalaag en data delivery. Deze componenten spelen een rol in het transformatieproces van transactiegegevens naar stuurinformatie. De onderlinge relaties zijn weergegeven in figuur 1. Transaction processing Aan de operationele processen van organisaties liggen verschillende bronsystemen ten grondslag. Het laagste registratieniveau (transactieniveau) kan binnen een ERP-omgeving worden vastgelegd. In de praktijk wordt een ERP-oplossing vaak alleen voor de financiële functie gebruikt. Dit betekent dat voor de overige primaire processen aanvullende softwarepakketten worden gebruikt. Daarbovenop kunnen ook nog eens dedicated zogenoemde niche software tools voor bijvoorbeeld klachtenregistratie, cash management, competentie- en kennismanagement en dergelijke in gebruik zijn. Een veelheid aan bronsystemen zorgt kortom voor de registratie en verwerking van transactiegegevens, het zogenoemde transaction processing.
T I J D S C H R I F T CONTROLLING
nr 11 november 2002
47
Net als in ‘real life’ kunnen organisaties door regelmatig te bewegen een (data)infarct voorkomen.
figuur 1
Componenten IT-architectuur
Information delivery
Datalaag
Calculation engines
Data modelling
Transaction processing
Data modelling Om transactiedata te kunnen gebruiken voor managementinformatie, zal een aantal aanvullende bewerkingen (manipulaties) moeten worden uitgevoerd op de brongegevens. De data worden ‘gemodelleerd’. Deze manipulatie kan betrekking hebben op inzichten die uit oogpunt van managementinformatie nodig zijn, maar die niet in transactiesystemen worden geregistreerd. Een voorbeeld hiervan is het vastleggen van een overzicht in business areas, terwijl het transactiesysteem gebaseerd is op een juridisch organisatiestructuur. Datamodelling kan worden gezien als een interface, waarbij informatie uit verschillende systemen bij elkaar wordt gebracht. Daarbij zal meestal een bewerkingsslag plaatsvinden om de uniformiteit van definities te waarborgen. Daartoe wordt gebruik gemaakt van zogenoemde ETL-tools (extraction, translation, loading).
T I J D S C H R I F T CONTROLLING
figuur 2
Ontwikkelingen softwareleveranciers versus componenten IT-architectuur
Calculation engines
Datalaag
3 Consolidatie
4 ETL Data modelling
Calculation engines Om een grote hoeveelheid gegevens specifieke berekeningen te laten ondergaan, wordt gebruikgemaakt van calculation engines. Voorbeelden hiervan zijn: het bepalen van kostprijzen, het maken van voorcalculaties, het bepalen van optimale waarden voor variabelen en/of het consolideren van gegevens. Deze calculation engines verrijken de transactiegegevens tot stuurinformatie. Datalaag Na het modelleren of het uitvoeren van de berekeningen wordt de verrijkte informatie in een datalaag opgeslagen.
Transaction processing
liteiten in het informatievoorzieningsproces. ERP-leveranciers hebben in de jaren negentig vele implementaties bij vele verschillende typen organisaties doorgevoerd ter vervanging en standaardisering van transactiesystemen voor multidisciplinaire functies binnen organisaties. Bovenop deze gestandaardiseerde basis werden vervolgens rapportage- en business intelligence (BI) tools van andere leveranciers ingericht om informatie te kunnen ontsluiten. De laatste jaren bieden ERP-leveranciers aanvullende modules waarmee rapportage- en analysefunctionaliteit wordt aangeboden. De leveranciers van business intelligence-pakketten zitten natuurlijk ook niet stil. Zij hebben functionaliteiten ontwikkeld figuur 3 De IT-architectuur-problematiek...
chaos
Information delivery Via rapportage-tools kan de informatie uit de datalaag worden ontsloten voor rapportage- en analysedoeleinden. Er is dan sprake van information delivery. Functionaliteiten De softwareleveranciers spelen vaak ‘landjepik’ (zie figuur 2). De softwareleveranciers weten dat hun klanten de wirwar aan systemen zoveel mogelijk willen beperken. Zij zien nieuwe mogelijkheden en verruimen de reikwijdte van hun kernfunctionaliteit. Zij richten zich op voor- of achterliggende functiona-
geen p proble kwalita goed inadeq chaos geen beperk groot urgent ... vers
geen probleem probleem
inadequaat
Merendeel bedrijven heeft problemen met IT-architectuur
geen
beperkt goed
48
kwalitatief
nr 11
november 2002
1 ERP
2 BI
Information delivery
groot
urgentie
... verschilt per organisatie
T I J D S C H R I F T CONTROLLING
om allerlei rekenslagen te kunnen uitvoeren. Tevens hebben ze ter standaardisering en gelijkschaling van gegevens ETL-functionaliteit ontwikkeld om data modelling te kunnen faciliteren, zodat de aansluiting kan worden gemaakt tussen bronsysteem en business intelligence-oplossingen voor rapportage- en analysedoeleinden.
IT wordt gezien als iets operationeels en overgelaten aan de IT-manager
De IT-organisatie van een multinational werd verzelfstandigd met als doel vergelijkbare diensten aan andere organisaties aan te bieden en uiteindelijk naar de beurs te gaan. In het verleden was het doorbelasten van de diensten een interne aangelegenheid, die alleen diende om de kosten toe te rekenen aan de verschillende onderdelen. Er was derhalve niet veel noodzaak om dit op transparante wijze te doen. Na verzelfstandiging werden de klanten kritischer en gingen ze vragen stellen over de totstandkoming van de facturen. Door de gebrekkige informatievoorziening kostte het beantwoorden van deze vragen veel tijd en kwamen er ook fouten aan het daglicht. De (interne) klanten weigerden hun nota’s te betalen. De organisatie beschikte ook niet over een adequaat credit managementsysteem, waardoor ook de juiste nota’s niet meer op tijd werden betaald. Toen er liquiditeitsproblemen ontstonden, werd het probleem ‘urgent’. Door heel veel energie te steken in credit management, alle oorzaken van fouten te analyseren en stap voor stap aan te pakken, eerst door middel van lapmiddelen en later op structurele wijze, heeft deze organisatie dit datainfarct overleefd. Mede omdat de moederorganisatie in eerste instantie bijsprong. De moraal van het verhaal: als er sprake is van een chaos in de informatievoorziening en men geen actie onderneemt, zal men automatisch naar een ‘urgent probleem’ toegroeien. Als men wel actie wil ondernemen, is de oplossingsrichting afhankelijk van de situatie waarin men verkeert (zie figuur 5).
Ter geruststelling: het merendeel van de Nederlandse bedrijven heeft een probleem met de IT-architectuur. Het merendeel van de grote goedgeleide organisaties in Nederland bevindt zich in het gele kwadrant linksonder: de IT-architectuur behoeft verbetering, maar het probleem is nog niet urgent. In deze organisaties wordt vaak nog gewerkt met veel verschillende systemen. Als het meezit, gaat het daarbij alleen om verschillende stan-
november 2002
Pr a k t i j k voorbe e ld
Urgentie De omvang van de problematiek wordt hierbij bepaald door de kwaliteit van de IT-architectuur en de urgentie. Om de problematiek inzichtelijk te maken, hanteren wij het model uit figuur 3. De urgentie is afhankelijk van de mate waarin een inadequate IT-architectuur de dagelijks gang van zaken in de organisatie belemmert. Plat gezegd: ‘als het invloed heeft op de inkomsten wordt het in het algemeen vanzelf urgent’. Per situatie behandelen we de signalen en mogelijke oorzaken. De situatie dat er ‘geen IT-architectuur probleem’ is (het witte vlak uiterst links onderaan in figuur 3), kan als bijzonder worden bestempeld. Als het management het belang van IT voor de bedrijfsvoering tijdig onderkent, daaraan zelf actief een bijdrage levert en bereid is hierin te investeren, kunnen problemen worden voorkomen. nr 11
Daarnaast zijn er softwareleveranciers die vanuit een specifieke niche opereren en bijvoorbeeld consolidatiesoftware op de markt brengen. Zij bieden de laatste jaren aanvullende functionaliteit, zowel op het gebied van business intelligence- als ook ETL-functionaliteit. Tot slot zijn de leveranciers van ETL-tools aanvullende producten aan het ontwikkelen om business intelligence-functionaliteit aan te kunnen bieden. Een aantal leveran-
ciers kiest ervoor om aanvullende functionaliteit zelf te ontwikkelen ter verbreding van hun scope. Anderen focussen op hun kernfunctionaliteit en zoeken samenwerking met leveranciers die aanvullende functionaliteit bieden. Kortom, er is een heel scala aan mogelijkheden.
49
figuur 4 Signalen
Pas als de problemen met IT-architectuur invloed hebben op het primaire proces gaan er ‘bellen rinkelen’
De signalen zijn...
• spreadsheetrapportages • geen beeld ITarchitectuur/datastromen • ad hoc-oplossingen • manuele interfaces kwaliteit • beeld van de imperfectie • onbetrouwbare info • ads-on • niet ‘in control’ • verschillende urgentie systemen • raakt de ondersteunende • raakt de primaire processen processen/de business • afhankelijkheid IT beperkt • belemmering om • oplosbaar door personele veranderingen door te inspanningen voeren
... duidelijk herkenbaar
nr 11
november 2002
T I J D S C H R I F T CONTROLLING
50
daardsoftwarepakketten, die middels interfaces aan elkaar zijn gekoppeld. Als het tegenzit, is er zelfs sprake van zelfgebouwde systemen. Door middel van adds-ons worden specifieke eisen van de gebruikers ingevuld. De organisatie heeft een duidelijk beeld van de huidige ‘imperfecties’ en hoe deze kunnen worden beheerst. Tevens blijkt uit het beleid hoe men deze imperfecties in de toekomst wil gaan elimineren. Problematischer wordt het als de IT-architectuur echt een chaos is. De organisatie bevindt zich in dan het oranje kwadrant linksboven. Er bestaat binnen de organisatie geen (gedeeld) beeld van de datastromen en de IT-architectuur. Door middel van manuele interfaces gaan gegevens van het ene naar het andere systeem. Uitkomsten sluiten niet met elkaar aan, als gevolg van verschillende definities. Fouten worden achteraf, na grote inspanningen, gecorrigeerd. Door middel van uitgebreide spreadsheet-rapportages probeert men zo goed en kwaad als het gaat, te voldoen aan de rapportage-eisen. Elke organisatie die recentelijk is gefuseerd of grote overnames heeft gepleegd, bevindt zich in deze situatie. Als de aanleiding duidelijk is en er tijdig acties worden ondernomen om de systemen te stroomlijnen (op weg naar het gele kwadrant), is er echter nog niets onoverkomelijks aan de hand. Pas als de problemen met de IT-architectuur invloed hebben op het primaire proces, gaan alle alarmbellen rinkelen. Ernstiger wordt het als men langzaam naar deze situatie is ‘toegegroeid’. Dit gebeurt in organisaties waar het management onvoldoende affiniteit heeft met IT en het belang daarvan voor de bedrijfsvoering niet inziet. De IT wordt als iets operationeels gezien en overgelaten aan de IT-manager. Een ding is zeker, als u geen actie onderneemt, krijgt u vroeg of laat een probleem met uw IT-architectuur. figuur 5
De oplossingsfocus verschilt...
• vertaal IT-problemen naar business-problemen • creëer beeld wat nodig is en hoe het realiseerbaar is roei met de riemen die je hebt kwaliteit • maak een plan om in de • implementeer eerst no problem-area te lapmiddelen en quick wins komen en voer het uit urgentie • plan en implementeer structurele verbeteringen (gericht op IT/ mensen/ procesen/ inhoud) ter voorkoming van ‘alarmfase rood’ ... per situatie
Strategisch belang Goede IT-managers zullen proberen aan te tonen dat IT niet alleen iets operationeels is maar ook van strategisch belang. Om dit aan managers zonder IT-affiniteit duidelijk te maken, zijn uitzonderlijke communicatieve vaardigheden vereist. En dat zijn nu net niet de selectiecriteria waarop de gemiddelde IT-managers in dit soort organisaties primair op wordt aangenomen. Bovendien zullen hun medewerkers veelal ‘bouwers van de oude stempel zijn’, toen klantgerichtheid, managementcapaciteiten en service nog van minder belang waren. Vaak hebben ze ook te kampen met de consequenties van de chaos van de IT-architectuur: de houtje-touwtje-oplossingen, die bij problemen op ad hoc-basis snel opgelost worden. Wat dit betekent voor de performance laat zich gemakkelijk raden. In plaats van te luisteren naar de IT-manager, zal het management benadrukken dat hij eerst zijn ‘zaakjes op orde moet hebben’, voordat hij zich met het beleid mag bemoeien.
Houtje-touwtje-oplossingen leiden tot chaos
De reden dat de problemen bij dergelijke organisaties nog niet urgent zijn, heeft vaak te maken met het feit dat de primaire processen slechts beperkt afhankelijk zijn van IT. IT wordt bij hen voornamelijk ingezet voor de ondersteunende processen. Als zich daarbij problemen voordoen, wordt dit met behulp van grote personele inspanningen opgelost. Deze situatie is echter slechts beperkt ‘houdbaar’. Door maatschappelijke ontwikkelingen zoals bijvoorbeeld sturen op output, klantgericht werken, intra- en internettoepassingen en dergelijke, zullen steeds meer (non-profit)organisaties het (strategisch) belang van IT onderkennen. In profitorganisaties zullen klanten steeds vaker en sneller (on line) inzicht eisen in de consequenties van de transacties. In dergelijke situaties wordt het probleem opeens urgent. De chaos in de IT-architectuur en daardoor de datastromen, raakt de primaire processen en de business. Onbetrouwbare informatie als eindresultaat is een van de signalen dat men niet meer in control is. Het wordt daardoor heel moeilijk om verbeteringen door te voeren (zie het praktijkvoorbeeld in het kader). Het is aan u om te bepalen in welke situatie uw organisatie zich bevindt en wat u er concreet aan kunt doen. Door regelmatig en tijdig te bewegen, kunt u in ieder geval een data-infarct voorkomen. In deel II zullen we aan de hand van een praktijkvoorbeeld de belangrijkste knelpunten behandelen, waarmee u in de praktijk geconfronteerd kunt worden. Tevens komen de risico’s en remedies bij het aanpakken van problemen met de IT-architectuur aan bod. Binnenkort verschijnt van dezelfde auteurs het boek World Class Finance in de praktijk (ISBN: 9072194667). –C
