Drie thematische domeinen die elk een eigen front- en backoffice nodig hebben. Met eigen specialistische processen, die elk om eigen ondersteuning vragen. Dit onderscheid is te zien bij gemeenten, maar ook bij softwareaanbieders. Zo zijn er partijen in de automatisering actief die zich in de ontwikkeling van ‘burgerportalen’ hebben gespecialiseerd, bijvoorbeeld in de ondersteuning van gemeenten bij keukentafelgesprekken en ‘het gesprek met de burger’.

Andere bedrijven bieden modules voor aandachtsgebieden, zoals schuldhulpverlening, de verwijsindex risicojongeren en CORV. En tot slot zijn er automatiseringsbedrijven die zich specifiek richten op de backoffice, op een soepele (geautomatiseerde) administratie aan de achterkant. Dit laatste doet Stipter.

Vendor lock-in: met de rug tegen de muur

Er bestaat onterechte huiver bij veel gemeenten om met gespecialiseerde aanbieders in zee te gaan. Zij hebben de neiging te blijven zoeken naar de ‘heilige graal’, een totaaloplossing voor al hun ict-behoeftes. Maar nog relatief recent in 2014 hebben veel gemeenten ervaren wat het kan betekenen als alle eieren in één mandje worden gelegd en één specifieke leverancier wordt gecontracteerd voor de afhandeling van het gehele sociale domein.

Eén van de grootste leveranciers in het sociaal domein besloot in de zomer van 2014 om de prijzen van zijn software met gemiddeld tientallen procenten te verhogen. Gemeenten stonden met hun rug tegen de muur. Doordat alle onderdelen van het sociaal domein bij één leverancier waren belegd, was het onmogelijk om binnen een half jaar te migreren.

‘Common ground’ bouwt flexibiliteit in

Dit heeft geleid tot een tegenbeweging: de common ground, waarbij gemeenten als uitgangspunt nemen dat zij meer flexibiliteit in het applicatielandschap willen. De combinatie van functionele decompositie en gestandaardiseerde API’s voor gegevensuitwisseling zorgt ervoor dat per onderdeel de beste leverancier kan worden gekozen, waarbij je zorgt dat tussen verschillende onderdelen informatie goed wordt uitgewisseld.

Geoperationaliseerd betekent dit dat gemeenten samen met leveranciers zorgen voor  goede ‘koppelpunten’ tussen de verschillende domeinen, front- en backoffices. Vergelijk het met het kopen van een caravan en een auto: dat doe je ook niet bij dezelfde leverancier. Dan krijg je nooit het beste resultaat. Ook auto’s en caravans hebben koppelstukken, dat noemen we trekhaken. Die zijn betrouwbaar, mits je bij aankoop goed rekening houdt met specifieke gegevens, zoals gewicht en trekkracht.

Geen ‘vendor lock-in’

Informatie-uitwisseling in de automatisering werkt niet anders. Belangrijk is om te zorgen dat je flexibiliteit inbouwt. Zodat je altijd van ict-leverancier kan wisselen en niet vastzit aan eenmaal gekozen oplossingen. En geen last hebt van ‘vendor lock-in’ en niet te beïnvloeden beheerkosten.

Daarbij zijn de koppelpunten tussen de verschillende ict-systemen tegenwoordig het probleem niet meer. Er bestaan inmiddels goed ontwikkelde koppelvlakken voor informatie-uitwisseling tussen bijvoorbeeld front-office en back-office. De volgende stap is dat we deze ‘trekhaken’ in gebruik gaan nemen. Zodat niet een halfslachtige ‘totaaloplossing’, maar een flexibele en een leveranciersonafhankelijke applicatieomgeving de nieuwe norm in het sociaal domein wordt.

Wat betekent dit voor inkoop?

Cruciaal om dit te kunnen realiseren, is dat gemeenten bij de inkoop van nieuwe softwareoplossingen hier voldoende rekening mee houden. De ‘alles-in-één’-uitvraag lijkt misschien aantrekkelijk, maar kan leiden tot de beruchte vendor lock-in en weinig tot geen invloed op de kosten. Kies daarom al bij de inkoop voor functionele specialisatie en neem samen met aanbieders de ontwikkelde ‘trekhaken’ in gebruik. Zo ga je op weg naar een meer flexibel, goedkoper applicatielandschap.