Standaardinterfaces maken integratie systemen eenvoudig

Als gevolg van fusies en overnames kampen veel organisaties met een spaghetti aan systeemarchitecturen. Een goede integratie van systemen levert natuurlijk veel voordelen op: minder dubbele invoer van gegevens, geen tegenstrijdige informatie, lagere kosten, eenvoudiger beheer enzovoort. Op het moment van de fusie wordt echter vaak onderschat hoeveel tijd en geld het gaat kosten om de systemen van de fusiepartners goed te integreren. Erger nog, de moeizame integratie van systemen kan leiden tot een vertraging van de integratie van de twee organisaties, en kan daarmee schade toebrengen aan de doelstellingen van de fusie. Dit probleem vraagt om realistische integratieplannen, waarbij de prioriteiten goed zijn afgestemd op de businessdoelstellingen van de fusie. In de praktijk wordt echter vaak een ad-hocbenadering gevolgd. Het management laat de integratie van systemen ook regelmatig over aan de IT-afdeling, en de keuzes en prioriteiten worden niet gebaseerd op de doelstellingen van de fusie. Tegelijkertijd gebeurt het vaak dat de overnemende partij domweg alle eigen systemen oplegt aan de overgenomen dochter, zonder goed te overwegen in welke gevallen dat zinvol is en wanneer niet. Indien een bedrijfsonderdeel verkocht gaat worden, ontstaat er ironisch genoeg een vergelijkbaar probleem als bij een fusie. Alleen is het dan geen integratieprobleem maar juist een scheidingsprobleem. Als een organisatie de integratie van systemen op het eerste gezicht perfect op orde heeft, dan kan het voornemen om een bedrijfsonderdeel te verkopen een behoorlijk probleem zijn. Het bedrijfsonderdeel moet qua systemen dan zelfstandig kunnen functioneren, en de systemen moeten dus losgemaakt worden uit één geïntegreerd systeem. Soms kan dat een heel dure en tijdrovende operatie worden, de kosten ervan gaan dan af van de verkoopprijs. Als een volledige integratie zoveel tijd en geld kost om na een fusie te bereiken, en als deze ‘perfecte’ integratie zoveel kosten veroorzaakt in het geval van een verkoop van een bedrijfsonderdeel, dan rijst de vraag: is integratie wel een ideaal om na te streven? Eén gezicht Een optie is om te kiezen voor een minimale vorm van integratie. Hierbij vindt financiële consolidatie plaats van de twee fusiepartners door een holding, en voor de rest verandert er (nog) niets. De mate waarin verdergaande integratie van systemen noodzakelijk is en in welke volgorde hangt vooral af van de businessdoelstellingen van de fusie (zie kader). De integratie van de operationele systemen kan grote efficiencyvoordelen hebben, maar er is op korte termijn meestal geen onmiddellijke noodzaak voor. Indien de fusiepartners met één gezicht op de markt willen opereren dan moeten de web portal voor klanten en de CRM-applicaties wel snel geïntegreerd worden. En een gezamenlijk financieel systeem en managementinformatiesysteem zijn nodig indien het de wens is om de fusiepartners als één bedrijf te besturen. Het voorgaande betekent dat integratie moet plaatsvinden aan de voorkant (klantgerichte systemen zoals een web portal en een CRM-systeem) en aan de achterkant (financieel systeem en managementinformatie; zie figuur). Deze integratie is veel sneller en eenvoudiger te realiseren door binnen het bedrijf standaardinterfaces af te spreken en te realiseren tussen drie domeinen: klantgerichte systemen; operationele systemen; financiële systemen. Flexibiliteit Deze standaardinterfaces tussen de drie domeinen vergroten ook de flexibiliteit. Het is bijvoorbeeld relatief gemakkelijk om later voor een nieuwe fusiepartner een ander operationeel systeem in te voegen. Het vergroot ook de flexibiliteit omdat het eenvoudiger is om voor een nieuw product of een nieuwe business line andere operationele systemen in te voegen. Het omgekeerde is ook waar: een afsplitsing van bedrijfsonderdelen en van systemen is een stuk hanteerbaarder door deze duidelijke scheiding met standaardinterfaces, het is immers niet nodig om spaghetti te ontwarren. Het af te splitsen onderdeel kan een ‘kopie’ van het operationele systeem blijven gebruiken, en de interfaces met klantgerichte en financiële systemen kunnen eenvoudig losgekoppeld worden. Door een dergelijke opzet is het eenvoudiger om samenwerkingsvormen met andere bedrijven te intensiveren (alliantie, joint venture, fusie) of losser te maken (afsplitsen van systemen). Er worden dus flexibele overgangsvormen mogelijk. Dat is ook van belang voor tussenliggende samenwerkingsvormen zoals in supply chains, bijvoorbeeld co-makership of andere vormen van de ‘extended enterprise’. Het gaat daarbij om een relatief losse samenwerking van zelfstandige organisatie-eenheden, waarvoor toch een aanzienlijke integratie van systemen nodig is. Kader 1: Opties voor integratie na fusie 1 Een integratie van klantgerichte systemen (in het bijzonder de web portal voor klanten en de CRM-systemen) verdient hoge prioriteit indien beide fusiepartners de bedoeling hebben om als één bedrijf op de markt te opereren. In het andere geval dat de fusiepartners autonome business units blijven met een eigen gezicht en/of eigen merknamen, zal de integratie van klantgerichte systemen een lage prioriteit hebben of niet eens gewenst zijn. 2 Een integratie van infrastructuur is in alle gevallen een voorwaarde, en verdient daarom altijd een hoge prioriteit. Het meest urgent daarbij is de integratie van de netwerken van de fusiepartners. 3 De integratie van de systemen die het primaire proces van productie en service ondersteunen is nodig indien de fusie als doelstelling heeft om operationele synergievoordelen te behalen. Deze integratie is echter in veel gevallen erg complex en heeft vele risico’s in zich. Het is daarom gewoonlijk niet realistisch om hiermee te beginnen. Deze stap kan meestal beter starten nadat de bovengenoemde opties overwogen en, waar zinvol, gerealiseerd zijn. 4 De integratie van systemen voor ondersteunende processen (zoals HR, IT, facilitymanagement) is nodig indien de fusie als doelstelling heeft om kosten te besparen door ondersteunende afdelingen samen te voegen, bijvoorbeeld in de vorm van shared service centers. Voor deze integratie geldt net als bij de primaire processen dat het vaak complex en tijdrovend is, en dat het beter is eerst de opties 1 tot en met 3 te realiseren (zie figuur 2). Kader 2: Stellingen systeemintegratie 1 Er moet een duidelijke scheiding zijn tussen drie domeinen: de klantgerichte systemen (de web portal voor klanten en een CRM-systeem), de operationele applicaties voor productie en dienstverlening, en de financiële systemen & managementinformatie. Grote ERP-leveranciers prijzen ‘best-of-suite’ aan om daarmee de software voor alle drie domeinen te verkopen, en klanten geheel aan zich te binden. Aparte systemen voor deze drie domeinen hebben diverse voordelen uit oogpunt van flexibiliteit. 2 Ook indien een bedrijf besluit om één softwaresuite te gebruiken voor alle drie bovengenoemde domeinen dan nog is het erg belangrijk om transparante en goed gedocumenteerde interfaces te definiëren en te realiseren tussen deze drie domeinen. Deze interfaces moeten zodanig zijn dat daarmee koppelingen met andere softwarepakketten eenvoudig te maken zijn, bij voorkeur door middel van XML en XSLT. Als er bijvoorbeeld een bedrijf overgenomen wordt, dan moeten de operationele systemen van het overgenomen dochterbedrijf eenvoudig en snel te koppelen zijn aan de klantgerichte systemen en aan de financiële systemen van het nieuwe moederbedrijf. Deze mogelijkheid voor koppelen is ook van belang indien een bedrijf een nieuwe productlijn start waarvoor aparte operationele systemen nodig zijn. 3Het is gewenst dat leveranciers van softwarepakketten (zoals CRM- en ERP-pakketten) alle relevante standaardinterfaces leveren met transparante documentatie, zodanig dat er geen belemmeringen zijn voor bedrijven om pakketten van verschillende leveranciers te combineren. 4 Bij de ontwikkeling en het beheer van software is het de gewoonste zaak van de wereld dat een applicatie of een component een versienummer heeft, zodat je weet met welke versie van het product je te maken hebt. Dit zou net zo normaal moeten zijn voor iedere interface, maar vaak wordt een interface nu beschreven als de koppeling tussen ‘applicatie-X-versie-N’ en ‘applicatie-Y-versie-M’. Elke interface moet als zelfstandige entiteit met een eigen versienummer bekend en gedocumenteerd zijn. Dit is bijvoorbeeld van groot belang indien een oudere versie van een interface een tijdlang in productie moet blijven naast de nieuwe versie, omdat de verschillende gekoppelde applicaties tijd nodig hebben om van de oude naar de nieuwe interface te migreren. 5Een ‘perfecte’ ofwel volledige integratie van alle systemen in een bedrijf heeft als voordeel dat er geen tijd en geld nodig is voor het ontwikkelen van interfaces. Maar als een bedrijf besluit om een onderdeel af te splitsen of te verkopen, dan kan deze perfecte integratie extra kosten veroorzaken. Immers, het te verkopen bedrijfsonderdeel moet ontkoppeld worden van de moeder. Bij een perfecte integratie van systemen kan dit een heel kostbare en tijdrovende operatie zijn. 6 De drie-domeinenarchitectuur als hier beschreven (aparte systemen en transparante interfaces) is ook een effectief en flexibel platform voor de ‘extended enterprise’, dat wil zeggen een samenwerkingsverband van een bedrijf met toeleveranciers en afnemers of een alliantie of losse federatie van autonome organisaties. Een extended enterprise is in steeds meer situaties een essentiële voorwaarde voor optimalisering van de supply chain, en daarmee voor het voortbestaan van een bedrijf op lange termijn. Arend Stemerding is binnen Deloitte Consulting werkzaam op het terrein van IT-strategie en Architectuur en is vaak betrokken bij projecten voor het optimaliseren van de supply chain tussen organisaties of organisatie-units (astemerding@deloitte.nl).