Veel bestaande systemen zijn gebouwd op het fundament van lokale datamodellen. Deze raken echter steevast met elkaar in conflict. Volgens twee consultants biedt ‘enterprise application integration’ verlossing. Tegelijkertijd kan de ‘chief process officer’ beginnen met het invoeren van een procesgerichte infrastructuur en daarmee samenhangende methoden en instrumenten voor ontwikkeling en beheer. Tweede en laatste deel van een artikel over de cpo.
De agenda van de cpo
|
Deels door wensdenken, deels omdat men probeerde de spreekwoordelijke steen der wijzen te vinden. Het probleem valt gemakkelijk te begrijpen, als men zich voorstelt dat software en systemen een bepaalde vorm hebben. De huidige vormen van bedrijfssoftware – toepassingen en componenten – zijn slecht afgestemd op de behoeften van moderne bedrijfsprocessen. Verkeerde combinaties van bedrijfsprocessen en softwaremodules komen voort uit het datagericht denken dat de it-gemeenschap regeert. Pogingen om dit ‘wereldbeeld’ op te dringen aan de ‘echte wereld’ van bedrijven waar het procesdenken overheerst, zijn bedrijven duur komen te staan, zowel in termen van onkosten als ergernis. De symptomen zijn onder andere de voortdurende onmacht van technische en functionele teams om te communiceren en samen te werken, met als gevolg een volstrekt onoverzichtelijke integratie met bestaande systemen.
Bestaande systemen, toepassingen en componenten zijn altijd gebouwd op het fundament van lokale datamodellen, die in bestandssystemen en databases worden ingevoerd. Deze datamodellen raken steevast met elkaar in conflict, zowel semantisch als structureel. Elke softwaremodule kent zijn eigen criteria voor de begrippen klant of producten, en er is niets dat de tegenstrijdigheden tussen die criteria kan voorkomen. Bovendien is alle zakelijke logica die in deze softwaremodules is ingebracht, nauw verbonden met het lokale datamodel. Derhalve is die logica immuun voor de behoeften van de bedrijfsprocessen in de ‘real world’ die met het datamodel in strijd zijn.
Het oplossen van deze conflicten en tegenstrijdigheden in een complex van toepassingen is een uitdagend en riskant karwei. In veel gevallen zijn de conflicten onoplosbaar, maar daar kom je niet achter tot je het probeert. Dat is de reden waarom het integreren van een nieuw softwarepakket in een bestaande omgeving doorgaans zeven tot tien maal zoveel kost als de software zelf. En vergeet niet, voor al dat geld krijg je nog steeds een volstrekt onoverzichtelijke ‘oplossing’.
Op weg naar eai
Nu we weten waar de heersende mythen vandaan komen, rest de vraag hoe we ze de it-wereld uit kunnen krijgen. Eai-middleware biedt een nooduitgang om te ontsnappen aan de tirannie van de toepassingen die data centraal stellen. Ze schept de mogelijkheid bestaande functies en diensten binnen de toepassingen te abstraheren, te normaliseren en te gebruiken. Tegelijkertijd kan de cpo beginnen met het invoeren van een procesgerichte infrastructuur en daarmee samenhangende methoden en instrumenten voor ontwikkeling en beheer.
Beschikbare procesmodelleer-tools zijn nuttig, omdat zij gebruikt kunnen worden voor het identificeren van potentiële knelpunten, mogelijke capaciteitsproblemen aan het licht kunnen brengen, en algemene kostenramingen kunnen geven, aangenomen dat de kostenelementen gemeten kunnen worden. Deze instrumenten zijn echter veel minder bruikbaar om aan te geven hoe effectief een bepaald proces in de productie zal zijn. Het bepalen van die effectiviteit vereist het uitvoeren van het proces in de praktijk en het vaststellen of de feitelijke resultaten beter of slechter zijn dan de resultaten van alternatieve implementaties. De ‘als-dan’-mogelijkheden van de meeste instrumenten die op de markt zijn, blijven over het algemeen beperkt tot variaties van kosten plaatjes.
Het probleem is dat modellen worden verondersteld alleen onbelangrijke details te verwijderen. Helaas bestaat er geen formele theorie over modellen, noch een procedure die ons in staat stelt om in specifieke situaties systematisch belangrijke van onbelangrijke details te onderscheiden. Als een dergelijke procedure bestond, dan zouden we nu al over een model beschikken dat veel krachtiger was dan wat we nu proberen te bouwen.
Wat modelvorming op dit moment het dichtst benadert, is ‘wetenschap’. Wetenschap probeert niet a priori vast te stellen wat belangrijk of onbelangrijk is. Wel stelt het grenzen aan het elimineren van details. Als je zoveel details hebt verwijderd dat het model niet experimenteel kan worden getest, of binnen een computer kan worden nagebootst, dan ben je te ver gegaan en heb je de grens van wat wetenschappelijk verantwoord is, overschreden. Er bestaat simpelweg geen manier om een model dat niet op een ondubbelzinnige wijze kan worden toegepast, te valideren. Dat is de basis van onze stelling dat een effectief model uitvoerbaar moet zijn in elke fase van softwareontwikkeling. De analysefase vormt hierop geen uitzondering.
Slag in de lucht
Iedere automatiseerder weet dat je pas kunt voorspellen of een ingewikkeld proces goed zal werken, als je het uitprobeert. Wij stellen dat je elk bedrijfsproces minimaal op twee of meer manieren moet implementeren, zodat de effectiviteit van de verschillende versies kunnen worden vergeleken. Deze benadering kent beperkingen door de infrastructuur van de bestaande systemen. In de meeste omgevingen worden bedrijfsprocessen op één enkele manier geïmplementeerd vanuit de vooronderstelling dat een gebruiker ‘weet’ hoe het proces er uit behoort te zien om effectief te zijn. De manier waarop de gebruiker deze kennis zou vergaren, daar wordt niet over gesproken. Wat er gebeurt, is dat de gebruiker om te beginnen een slag in de lucht slaat. Deze slag wordt dan omgezet in systeemspecificaties die vervolgens alleen maar kunnen worden aangepast door nieuwe software-ontwikkeling.
De aanbevolen eai-methodologie voor het aanpakken van deze beperkingen gaat ervan uit dat de business-specificaties worden geïmplementeerd in de applicatielogica. In dit model staat eai-middleware boven het applicatieniveau en dient ze als instrument dat het proces orkestreert en berichten transporteert. Aangezien de ‘slag-in-de-lucht-strategie’ zich beperkt tot het applicatieniveau, kan eai-middleware worden gebruikt om de businesslogica aan te sturen zonder de applicatie-architectuur te verstoren of de businesslogica zelf over te nemen.
Een praktische benadering die wij tot op heden bij crm-toepassingen hebben gebruikt, is de applicatieportfolio lossnijden en de sturende businesslogica transplanteren naar een centraal regelsysteem. Dat maakt testen en ervaring opdoen mogelijk. Deze benadering is duurder, tijdrovend, en levert minder op dan wij zouden wensen, maar is niettemin veel beter dan de starre processen van een standaard applicatieportfolio.
Moet dat, die nieuwe naam?
Als de gedaantewisseling van cio naar cpo u te ver gaat, bedenk dan dat de cio-revolutie in de laatste tien jaar ook niet gemakkelijk was. Zie de titel cpo als de volgende stap in het cio-traject.
Of we nu praten over cio of cpo, beiden hebben ze hetzelfde verreikende doel – het bedrijf de kracht geven zichzelf te definiëren en te managen. Als u het creëren van nieuwe titulatuur wilt vermijden, houdt het dan bij cio, maar verander de betekenis van de ‘i’ van informatie in die van infrastructuur. Informatieverwerking op bedrijfsniveau is uit de tijd. De ‘chief infrastructure officer’ van vandaag moet iemand zijn die de overall-planning kan ontwerpen en een infrastructuur kan creëren die gebruikers in staat stelt te doen wat zij noodzakelijk achten. De cio/cpo moet denken en handelen als de ‘grote belangenbehartiger van de gebruikers’.
We moeten de strategische bedrijfsplanning ondersteunen door de concepten van stedelijke planning toe te passen en het netwerk voor de infrastructuur uit te zetten. Als we dat goed doen, kunnen we er echt in slagen onze organisaties te transformeren naar eai-gestuurde ondernemingen.
Deel 1: Procesgerichte aanpak biedt voordelen boven starre gecentraliseerde informatieverwerking .
Nick Leyland, Jochum Hoff, consultants American Management Systems Europa
