Het bouwen van software, hoe werkt dat eigenlijk?

Innoveren en omgaan met onzekerheden

Ook bij het bouwen van software speelt wet- en regelgeving een rol (al wordt die soms pas tijdens het ontwikkelproces duidelijk), ben je afhankelijk van software die door externe partijen wordt ontwikkeld, en kom je soms voor verrassingen te staan. Het is de kunst van software-ontwikkeling om te innoveren en tegelijkertijd rekening te houden met al deze onzekerheden. In onze tak van sport doen we dit via ‘agile development’. Je begint te werken zonder alle antwoorden te weten, en rondt steeds kleine stukjes werk af die je leren wat de beste oplossing is (of welke ideeën juist niet werken). 

Heel vaak gaat dit goed, en leveren we binnen afzienbare tijd een technische oplossing op die grote impact maakt op de zorg. Denk aan het ondersteunen van mobile device management in onze apps, onze functionaliteit voor avond-, nacht- en weekendzorg, onze nieuwe cliënt-header, of onze nieuwe flex-functionaliteit voor roosteraars. Soms lukt het niet en blijkt een innovatie toch lastiger om te realiseren dan we hoopten. 

De komende tijd wil ik jullie graag meenemen in enkele praktijkvoorbeelden. Ontwikkelingen die volgens plan gaan, ontwikkelingen die verrassen, maar ook ontwikkelingen die tegenvallen. Deze keer neem ik je mee in de uitdagingen van Ons® Berichten. 

Uitdagingen bij het bouwen van Ons® Berichten

Een voorbeeld van een ontwikkeltraject waarbij we met tegenvallers te maken hebben is de nieuwe Ons® Berichten, onze veilige berichtendienst voor de zorg. Ons® Berichten is het product van een samenwerking van vele disciplines en kent veel afhankelijkheden binnen en buiten Nedap. Dit zorgt voor een enorm aantal interacties tussen verschillende stukjes techniek die allemaal vlekkeloos moeten werken, wil de dienst in z’n geheel goed werken. Over een aantal van die stukjes hebben we veel controle, over andere stukjes weer wat minder. Een concreet voorbeeld van zo’n interactie die een uitdaging werd was de licentie voor een stuk software waarop Ons® Berichten voortbouwt. Voor al onze klanten onderhandelen we met de aanbieder van dat stuk software. Dit wordt dan gelijk een heel groot contract, omdat we zoveel eindgebruikers vertegenwoordigen. Zulke onderhandelingen duren normaal al lang en in dit geval nog langer omdat gaandeweg de voorwaarden voor de licentie veranderden. Toch is het nemen van deze horde wel een voorwaarde voor uitrol van de dienst. Anderzijds stelden de verschillende technische onderdelen die samen Ons® Berichten vormen andere eisen aan authenticatie (het proces van vaststellen wie de eindgebruiker is wanneer deze inlogt). Het kostte ons vele rondes van ‘agile werken’ om daar de juiste oplossing te vinden. En omdat authenticatie een heel belangrijk onderdeel is van data-veiligheid doen we hier geen concessies. Dit moet heel erg goed – en waterdicht – werken, ook als dit meer tijd kost. 

Lering trekken uit het proces

Bij Ons® Berichten moesten we dus meer onverwachte uitdagingen oplossen die pasten binnen de buffer in onze planning. Het is geen toeval dat dit net gebeurt bij een dienst met veel eindgebruikers, een grote impact op de zorg, en waar de behoefte zo groot is. Er zijn weinig veilige berichtendiensten voor de zorg, juist omdat het zo’n groot en complex stuk techniek is. Dit zal nooit een reden voor ons zijn om een innovatie links te laten liggen. Wel moeten we er scherp op zijn dat we lering trekken uit dit proces. De volgorde waarin we zaken hebben aangepakt had slimmer gekund, zodat we tegen minder blokkeringen aan waren gelopen. En we hadden opener kunnen communiceren over de uitdagingen waar we tegenaan liepen zodat de context van een vertraging duidelijk werd. Met lessen als deze in ons achterhoofd willen we in de toekomst grote impact maken op de zorg, terwijl we het ontwikkel- en implementatie-pad voorspelbaar houden. 

Overigens is de lancering van Ons® Berichten dichtbij. Momenteel werkt een aantal (grote) zorgorganisaties met de dienst in een pilot en bereiden we de grootschalige uitrol voor.