of 59045 LinkedIn

Afhankelijkheid softwareleveranciers behoeft doorbraak

Harrie Gooskens Reageer

Toen PinkRoccade onlangs haar tarieven onverwacht drastisch verhoogde, laaide de discussie over leveranciersmanagement weer op. Tal van gemeenten en opinieleiders mengen zich in deze discussie door de aandacht te vestigen op de ongewenst sterke afhankelijkheid van softwareleveranciers. Daarbij valt op dat de meningen sterk uiteen lopen. Enerzijds de ‘eigen schuld, dikke bult’ reacties, waarbij wordt gedoeld op gebrekkig leveranciersmanagement / opdrachtgeverschap bij gemeenten. Anderzijds een oproep tot het beëindigen van de afhankelijkheid door het stuur weer volledig in eigen handen te nemen en daarmee afscheid te nemen van de hedendaagse marktwerking. Bijvoorbeeld via gezamenlijke aanbesteding en/of andere samenwerkingsverbanden.

Die gevoelens van te sterke afhankelijkheid van de leverancier van een softwarepakket komen niet alleen voor bij gemeenten. Ook in het bedrijfsleven leeft dat gevoel want het vervangen van een leverancier is meer dan alleen maar het contracteren van een nieuw softwarepakket. Het betekent ook dat de gebruikers moeten leren werken met het nieuwe gereedschap. En het betekent dat de gegevens vanuit het oude systeem moeten worden geconverteerd naar het nieuwe systeem. De kosten van softwarevervanging en opleiding blijven doorgaans binnen de perken, maar de kosten van gegevensconversie overtreffen vaak de stoutste verwachtingen.

Dat wordt veroorzaakt door een veel voorkomend monopolie dat de oude leverancier heeft op alle technische specificaties van het gegevensmagazijn (of zakenmagazijn) dat bij zijn softwarepakket hoort. Zonder die specificaties is een geautomatiseerde conversie onmogelijk. Slechts zelden hebben gemeenten in hun softwarecontracten vastgelegd dat de leverancier deze specificaties moet vrijgeven op eerste verzoek. Dus moeten ze meestal aan de oude leverancier zijn medewerking gaan vragen op het moment van afscheid, want de gemeente heeft een vervangende concurrent gecontracteerd.

Iedereen weet het; dat gaat niet van harte. Klantvriendelijkheid jegens een vertrekkende klant is economisch immers niet aantrekkelijk, ook niet bij gemeentelijke ICT-leveranciers. Vaak ontstaat de indruk dat vooral de van oudsher marktleiders Centric en PinkRoccade zich hieraan schuldig maken. Ik kan u verzekeren dat nagenoeg elke ‘uitgerangeerde’ leverancier die neiging heeft. Ook de niche spelers in de gemeentelijke markt en ook de ERP/SCM/CRM leveranciers in het (MKB-) bedrijfsleven.

Moeten we ons daar dan maar bij neerleggen? Of moeten we de pakketleveranciers als marktpartij buitenspel zetten door zelf de softwarebouw ter hand te nemen via een opdracht aan één of enkele grote dienstverleners? Ik denk geen van beiden want er is een veel betere oplossing.

We moeten gaan zorgen dat de data van de proceslogica wordt gescheiden. We hebben mooie StUF standaarden maar dat zijn standaarden voor de uitwisseling van gegevens tussen applicaties. Na uitwisseling verdwijnen die gegevens in het bedrijfseigen gegevensmagazijn of zakenmagazijn van de ontvangende leverancier. Als we ervoor gaan zorgen dat gegevens terecht komen in een RSGB gestandaardiseerd registratiemagazijn (basisregistraties, kernregistraties en zaken) dan hoeven applicaties niets meer uit te wisselen en worden de bedrijfseigen magazijnen werkeloos. Bij voorkeur plaatsen we het registratiemagazijn in de cloud en is het gekoppeld aan landelijke voorzieningen. Dit maakt meteen samenwerking mogelijk. Of misschien is het registratiemagazijn in extremis zelf een landelijke voorziening?

Elke applicatie moet dan zogenaamde services gaan gebruiken die op veilige wijze de geautoriseerde toegang tot dat registratiemagazijn verzorgen. Alleen op die wijze komen de applicaties van de leveranciers aan hun gegevens. Leveranciers kunnen zich van elkaar onderscheiden via slimme proceslogica en sexy user interfaces, over de data hebben ze niets meer te zeggen, ook niet over de opslagstructuur van die data. Ook nieuwe kleine leveranciers kunnen eenvoudig slimme oplossingen introduceren zonder dat dit meteen tot problemen in de gemeentelijke applicatiearchitectuur leidt.

Deze oplossing levert een mes dat aan twee kanten snijdt. Enerzijds omdat de afhankelijkheid sterk wordt teruggedrongen, want bij vervanging van de leverancier is gegevensconversie niet meer nodig. Anderzijds omdat we dan geen last meer hebben van leveranciers die elkaar de oorzaak van falende gegevensuitwisseling in de schoenen schuiven, of versieverschillen duiden als oorzaak van de mismatch. Mooi meegenomen is dat dit concept ook de softwarematige aansluiting vereenvoudigt voor het toenemend aantal samenwerkingsverbanden waarin de gemeente participeert.

Komt daarmee een einde aan StUF? Ik denk het niet want StUF is goed herbruikbaar als poortwachter voor het gestandaardiseerde registratiemagazijn. Alleen nieuwe gegevens toevoegen en bestaande bijwerken als het betreffende bericht aan de StUF standaarden voldoet. Bovendien blijft de StUF gegevensuitwisseling tussen applicaties nodig tot het moment dat zo’n RSGB gestandaardiseerd registratiemagazijn operationeel is.

Ik besef dat mijn pleidooi een forse investering vergt van alle betrokkenen en dat de nodige jaren nodig zullen zijn voor de transformatie. Maar alles laten zoals het is of afscheid nemen van marktwerking is nog minder aantrekkelijk. We hebben een doorbraak nodig, bij voorkeur met behoud van het goede.
 
Harrie Gooskens
Telengy Associé

Verstuur dit artikel naar Google+

Reageer op dit artikel
















Even geduld a.u.b.