Aanpak project
Probleem
De RWZI's van waterschap Vechtstromen gebruiken voor het logistieke proces rondom de grondstoffen van een zuivering al jarenlang de applicatie Riloss. De leverancier van deze applicatie bestaat echter al jaren niet meer. Hierdoor kost het de organisatie veel tijd, dus geld, om de applicatie draaiende te houden. Hiernaast neemt het risico dat de applicatie in zijn geheel niet meer functioneert steeds verder toe omdat de omgevingen waarop de applicatie draait wel (moeten) doorontwikkelen.
Ook zijn er de laatste jaren rapportage-eisen vanuit zowel wetgeving als interne behoeften ontstaan waaraan Riloss niet kan voldoen. En zijn zowel de wensen rondom het proces als de hedendaagse mogelijkheden zoveel veranderd dat er flinke efficiencywinst te behalen is door hier iets mee te doen.
Oplossingsrichting
Voordat wij aan de case zijn begonnen is er een business case opgesteld door informatiemanagement. Deze is door de programmatafel beoordeeld en uiteindelijk is gekozen om de vervanger van Riloss te laten maken door de Digital Dojo in Outsystems*. De reden hiervoor was drieledig:
Een op maat gemaakte applicatie zorgt voor flexibiliteit, efficiency en gebruiksgemak;
Zelf ontwikkelen zorgt voor meer grip op de ontwikkel- en beheerkosten en is toekomstbestendiger;
Zelf ontwikkelen maakt harmonisatie met andere applicaties mogelijk en geeft de mogelijkheid om te innoveren.
* Outsystems is een low-code platform, aangeschaft vanuit de visie van de digitale transformatie, waarmee er gemiddeld 8x sneller dan traditioneel programmeren een applicatie gemaakt kan worden op een voornamelijk visuele manier.
Werkwijze
Het ontwikkelen van applicaties in Outsystems doen we volgens de Scrum-werkwijze. Voor we beginnen met ontwikkelen willen we echter wel een zo goed mogelijk ontwerp hebben afgestemd met onze klanten. In dit geval waren dat Joost van Dijk, senior proces operator zuiveren, en Mark Nijhuis, senior adviseur proces- en bedrijfsvoering.
We zijn samen met Joost en Mark begonnen met het opstellen van user stories in het programma Jira, een tool voor o.a. Agile projectmanagement.
Voorbeeld van User Stories in Jira
Deze user stories hebben we vervolgens vormgegeven in schermontwerpen die we hebben gemaakt met MarvelApp. Deze ontwerpen maken het product erg levend en zorgen er voor dat de gebruiker zich goed in kan leven. Uiteindelijk komt dit een user-centered design ten goede.
Schermontwerp 1 in Marvelapp
Schermontwerp 2 in Marvelapp
Nadat de ontwerpen waren afgestemd met onze leverancier LinkIT kregen we een kostenraming en konden we na goedkeuring hiervan van start met de sprintplanning. De verwachting was dat de applicatie binnen 3 sprints van een week afgerond zou kunnen worden. We hebben deze klus samen met LinkIT opgepakt met de intentie zoveel mogelijk te leren en zelf te doen.
Al snel bleek dat we zelf goed uit de voeten konden in Outsystems en hebben we het grootste gedeelte van de applicatie zelf kunnen bouwen.
Datamodel
Logica
Schermontwerp
Elke user story, dus elk stukje functionaliteit van de applicatie, heeft de onderstaande ontwikkelstraat doorlopen. Dit zorgde voor een nauwe en constante samenwerking met de eindgebruiker en garandeert een stuk kwaliteit omdat alle gemaakte functionaliteiten op alle gewenste platformen getest zijn, door een andere programmeur nagekeken zijn en uiteindelijk door de gebruiker getest en akkoord bevonden zijn.
Ontwikkelstraat in Jira
Resultaten
We hebben uiteindelijk in 3 weken tijd een volledige functionerende applicatie (door Joost gedoopt als "ChemLog") weten te bouwen die voldeed aan alle wensen van de gebruikers, kwalitatief goed in elkaar steekt en in beheer is overgedragen. Het grootste gedeelte hebben we ook nog eens zelf gebouwd, zij het met nog enige supervisie van onze externe leverancier. Hierdoor zijn de kosten uiteindelijk ruim onder de raming gebleven.
Screenshot Chemlog
Het zelf low-code ontwikkelen van een applicatie past goed in het gedachtegoed van de digitale transformatie. Het maakt ons namelijk adaptief. Als de wensen veranderen, kunnen wij de applicatie mee veranderen. Ook kunnen we de applicatie uitbreiden met innovatieve onderdelen als automatische bestellingen van grondstoffen door sensoring te plaatsen bij grondstoftanks. Tot slot groeit het Outsystemsplatform (en dus ook de applicaties die we er op maken) mee met zijn tijd en voorkomt dit dat er weer een legacy-applicatie zoals Riloss ontstaat.
Naast het product waren ook de werkwijze (Scrum) en de ondersteunende applicaties Jira en Marvel nieuw voor de meesten. Dit heeft bijgedragen aan de digitale vaardigheden van de betrokken medewerkers.
"Het ontwikkelen op basis van de scrummethode was voor mij nieuw. Ik heb deze kortcyclische manier van projectmatig werken als zeer efficiënt ervaren. Door de veelvuldige contactmomenten tussen medewerkers van WVS, de externe programmeurs en de interne klant kwamen we ontzettend snel tot het gewenste resultaat, een gebruiksvriendelijke tool die voorziet in de behoefte. Binnen een periode van 2 maanden (van opdrachtverstrekking tot in gebruikname) is een oplossing op maat geleverd die de verouderde applicatie kan vervangen. Een mooi resultaat!" - Mark Nijhuis
Conclusie
Er was/is(?) in de organisatie nog enige scepsis over het al dan niet zelf bouwen van een applicatie. Past dit wel bij een regiewaterschap? Maar is het bouwen in Outsystems wel echt bouwen? Of is het meer configureren? Deze discussie werd onder andere gevoerd aan de programmatafel waar het project uiteindelijk wel goedgekeurd is.
Inmiddels is het project voorbij en zijn de resultaten gedeeld met diezelfde programmatafel. Hier is er heel positief gereageerd op het verloop en de uiteindelijke resultaten. Dit kwam mede door de erg positieve feedback vanuit de organisatie, het halen van de planning en het ruim binnen budget blijven.
" Wat mij ook enorm tevreden stelt is dat we in de instructie momenten alleen maar tevreden mensen hadden. (...) Als je het project ChemLog in ogenschouw neemt dan hebben we een weg ingeslagen met enorme mogelijkheden voor ons als Waterschap Vechtstromen. Daarmee bedoel ik dat we hebben laten zien dat we in eigen beheer applicaties kunnen bouwen tegen lage kosten maar met een enorm beheers gemak. Wat ook erg positief is dat de gebruiker/klant centraal staat in het ontwerp en bouwproces." - Joost van Dijk
Wat ons betreft is het op maat maken van applicaties in een low-code platform de toekomst. Er moet van geval tot geval gekeken worden wat de behoeften zijn en wat daar het beste bij past. In sommige gevallen bestaat er een product of dienst in de markt die goed aansluit op deze behoeften, zelf bouwen is dan vaak te duur. Of is er zulke specialistische kennis nodig dat het een flinke uitdaging wordt om het zelf te bouwen en kun je beter voor de veilige en bewezen oplossing kiezen. In ieder geval ben je daarna wel altijd overgeleverd aan de leverancier en mis je de flexibiliteit die je wel hebt als je zelf iets bouwt.
In veel gevallen bestaat er in de markt echter geen oplossing op maat. En moet er of veel maatwerk aan te pas komen, moet de werkwijze aangepast worden of wordt slechts een deel van de behoeften geautomatiseerd. In zulke gevallen is low-code wat ons betreft sowieso een goede oplossing!
Externe publicaties van het artikel:
Auteur: Dennie Kamp
