De meeste CIO’s slaat nog altijd de schrik om het hart wanneer zij worden geconfronteerd met de noodzaak om nieuwe applicaties te ontwikkelen. Ook het management maakt zich zorgen over de kosten, levertijden en het realiseren van de zakelijke doelstellingen. Waarom is het ondanks alle technologische vooruitgang van de afgelopen tijd nog altijd een problematische opgave om een nieuwe toepassing te ontwikkelen? Het komt neer op complexiteit, richtingloosheid en gebrekkige ontwikkelingspraktijken. In dit artikel ga ik in op het ‘core context’-model dat Geoffrey Moore in zijn boek ‘Dealing with Darwin’ beschreef. Daarbij zal ik u drie sleutels tot een verbeterde efficiëntie van applicatieontwikkeling aanreiken.
In dit artikel ga ik in op het ‘core context'-model dat Geoffrey Moore in zijn boek ‘Dealing with Darwin' beschreef. Daarbij reik ik drie sleutels tot een verbeterde efficiëntie van applicatieontwikkeling aan.
Het eerste dat aan het model van Moore opvalt, is het verschil tussen de kern(‘core')zijde en contextzijde van de horizontale as. De kernzijde heeft betrekking op processen en toepassingen waarmee een bedrijf zich van de concurrentie onderscheidt. Het gaat om toepassingen die processen automatiseren die de manier waarop je zaken doet uniek maken en je van de concurrentie onderscheiden. Ik noem dit zelf graag de differentiatiezijde van het model. De contextzijde vertegenwoordigt de bedrijfsprocessen die weliswaar nodig zijn voor de bedrijfsvoering, maar aanwezig zijn binnen alle ondernemingen die in jouw branche actief zijn. Dit noem ik commodity(gemeengoed)-processen en -toepassingen. Het is niet mogelijk om zonder deze processen en toepassingen zaken te doen. Voorbeelden zijn het salarisverwerkingsproces en financiële processen.
Hoe zit het nu met de verticale as binnen het model van Moore? Hier maakt de schrijver een onderscheid tussen processen die wel en niet van bedrijfskritisch belang zijn. Ik noem deze respectievelijk ‘afdelingsspecifieke' en ‘bedrijfsbrede' processen. Het interessante van dit model is dat het een prachtig kader biedt voor het beschrijven van de manier waarop applicatiesoftware zich binnen ondernemingen ontwikkelt. Bovendien reikt dit model drie sleutels tot het verbeteren van de ict-efficiëntie aan.
Processen gaan in de meeste gevallen links onderin van start in wat Moore het 'innovatieve kwadrant' noemt. De processen in dit kwadrant zijn uniek, omdat ze zijn bedacht door mensen aan de periferie van de onderneming – zoals medewerkers van de logistieke afdeling of verkopers – voor het oplossen van een specifiek probleem of het aanboren van nieuwe omzetkansen (waardoor het een differentiatie- of kernproces wordt.) Het proces is niet-bedrijfskritisch omdat het recent is bedacht. Vanuit technologisch en systeemperspectief worden deze processen doorgaans ondersteund door spreadsheets, documenten en e-mailberichten.
Hetgeen je in de praktijk ziet gebeuren is dat deze processen naar verloop van tijd uitgroeien tot afdelingsspecifieke toepassingen die zijn ontwikkeld door een 'schaduw-ict-team' dat binnen of namens de afdeling werkzaam is. Daarmee zijn we aangekomen bij de eerste sleutel tot een efficiënte ontwikkeling van toepassingen:
Sleutel 1: Zorg ervoor dat het schaduw-ict-team binnen jouw afdeling de mogelijkheid heeft om maattoepassingen te ontwikkelen op basis van technologie die de ict-organisatie van de onderneming in staat stelt om deze maattoepassingen in te zetten voor andere bedrijfsdoeleinden, zonder de noodzaak om ze volledig te hoeven herschrijven. Op deze manier investeer je in een ontwikkelingsplatform dat is gebaseerd op een ‘bouwen op verandering'-aanpak en je ict-organisatie in staat stelt om deze groeiende afdelingsspecifieke toepassingen elders binnen de organisatie te gebruiken en hun levenscyclus verder te beheren en te controleren.
Volgens het model van Moore zal het belang van sommige van deze afdelingsspecifieke processen voor de onderneming in zijn totaliteit toenemen en in sommige gevallen zelfs van strategisch belang worden. In dat geval verplaatsen ze zich naar het kwadrant linksboven, dat Moore het ‘build to scale'-kwadrant noemt. Het gaat om kerntoepassingen die voor de onderneming van bedrijfskritisch belang zijn.
Wanneer deze processen zich eenmaal in het ‘build to scale'-kwadrant bevinden, zal de (centrale-) ict-organisatie ze onder hun hoede nemen en in de vorm van bedrijfstoepassingen proberen te implementeren. Aangezien het gaat om recent ontwikkelde en bedrijfsspecifieke processen moeten ze worden geïmplementeerd met behulp van maatsoftware. Vanwege hun unieke karakter zullen er geen toepasselijke commodity-oplossingen op de markt beschikbaar zijn. En daarmee zijn we aangekomen bij de tweede sleutel tot een efficiënte ontwikkeling van toepassingen:
Sleutel 2: Voor deze bedrijfskritische ofwel kerntoepassingen moet je een reeks van processen, kaders en verzamelingen van tools creëren om voor al je maattoepassingen 'de kosten van verandering te stabiliseren'. Dit is van essentieel belang, aangezien deze toepassingen de belangrijkste oorzaak zijn van achterstand op ict-gebied. Het vermogen om deze toepassingen tegen lage kosten aan te passen biedt het bedrijf de grootst mogelijke toegevoegde waarde.
Uiteindelijk zullen veel van deze processen geleidelijk aan door de branche worden gekopieerd.
Hierdoor begeven ze zich naar het kwadrant rechtsboven en worden ze gemeengoed. Maar let op: deze processen blijven een bedrijfskritisch karakter houden aangezien een deel van de bedrijfsvoering ervan afhankelijk is. Ze stellen ondernemingen echter niet langer in staat om zich van de concurrentie te onderscheiden. Wanneer ze gemeengoed worden, zal dit gepaard gaan met een bepaalde mate van stabilisering en standaardisering.
Grote leveranciers van erp-oplossingen zullen nieuwe componenten in hun softwarepakketten opnemen om deze inmiddels stabiel geworden processen in hun oplossingen te integreren. Voor dergelijke stabiele processen is het nodig om softwarepakketten aan te schaffen of oplossingen in eigen beheer te ontwikkelen. De truc is om ervoor te zorgen dat je deze toepassingen op eenvoudige wijze kunt gebruiken voor processen die nog steeds tot de kernprocessen behoren en regelmatig veranderen. En daarmee zijn we aangekomen bij de derde sleutel tot een efficiënte ontwikkeling van toepassingen:
Sleutel 3: Wanneer je een softwarepakket aanschaft, moet je voor een oplossing kiezen die een complete reeks van web service-api's biedt die je in staat stellen om alle functionaliteit van het pakket te benutten. Mijd leveranciers die te weinig api's aanbieden, met een groot aantal processen werken waartoe je geen toegang hebt of je dwingen om hun aanpassingstools en -schermen of hun diensten te gebruiken. Met dergelijke pakketten zal het een nachtmerrie zijn om een soa te creëren. Kies dus alleen voor een softwarepakket van een leverancier die een complete reeks van api's biedt die open toegang bieden tot alle relevante processen en functies.
Door deze drie sleutels te hanteren en kernprocessen van contextprocessen te onderscheiden zul je op veel dynamischer en flexibelere wijze toepassingen kunnen ontwikkelen. Het resultaat: lagere kosten, een snellere time-to-market en een betere afstemming van toepassingen op de bedrijfsvereisten.
Een CIO die de schrik om het hart krijgt van het laten ontwikkelen van een applicatie zit duidelijk niet op de juiste plek in de organisatie.
De tekst sluit niet aan bij het plaatje. Naast elkaar, op de horizontale as staan Core en Context; boven elkaar, dus langs de verticale as, staan Non mission critical en Mission critical. Een vreemde vergissing.