Onze aanpak

1. Dream

Het begint allemaal met een idee en dat idee, dat vertaalt zich naar een droom. Die droom heeft over het algemeen een bepaalde waarde. Dat is waar het bij de eerste fase om draait. Over het verkennen van ideeën, dromen, visies en het analyseren waar dan de pijnpunten liggen om zo’n droom te realiseren. De eerste fase gaat dus echt over de richting die je op wilt. In deze fase komt ook de technologie al aan bod. Het is een moment om te verkennen welke technologieën het beste past bij de bestemming die je voor ogen hebt.

Een van de methodes die we daarvoor gebruiken is service design. Bijvoorbeeld: je hebt een end-to-end proces lopen, waarmee je je gebruikers zo goed mogelijk wilt ondersteunen. Dat kunnen zowel interne medewerkers als klanten zijn. Daar haken we verschillende processen en systemen op in, wat een hele mooie uitgangspositie biedt voor een nieuw ontwerp. Als je dit hebt kan je door naar de design fase.

We beginnen in de dream fase door de workflow te onderzoeken. Hierin wordt duidelijk hoe het end-to-end proces eruitziet en eruit moet gaan zien. We doen een SWOT-analyse om te kijken wat sterke en zwakke punten zijn in zo’n proces. Als je een digitale transformatie doet ga je namelijk niet één op één nabouwen. Je wilt iets naar een hoger niveau tillen en daar helpt zo’n soort analyse goed bij.

Uiteindelijk vertalen we dat naar een roadmap waarbij we de epics en features gewoon in een tijdlijn zetten. Je kan dan bepalen dat bij afronding van een bepaalde epic/feature, de applicatie ook echt waarde gaat toevoegen. Daarnaast kan je de roadmap nog verder uitbreiden door een duidelijke visie statement en business KPI’s toe te voegen.

2. Design

In de design fase, vertalen we functionele eisen en wensen naar een prototype en technisch ontwerp. We beginnen altijd met het maken van een prototype om te valideren dat de oplossing voldoet aan de behoeften van mens en organisatie. Zo besparen we onnodige ontwerp- en ontwikkelkosten. Prototypes zijn namelijk sneller gemaakt dan software, zelfs wanneer die met low-code is ontwikkeld. Pas nadat we de functionele oplossing hebben gevalideerd, vertalen we deze architectuur en datamodellen.

Tijdens deze fase draait het voornamelijk om het vaststellen van wat precies moet worden opgelost en met welk doel. Hier zal een enterprise/domein architect voornamelijk de vraagstelling definiëren en valideren met de belanghebbenden. Dit wordt gedocumenteerd in enterprise- en referentiearchitecturen.

“Een enterprise-architectuur (EA) is een conceptuele blauwdruk die de structuur en werking van organisaties definieert. De bedoeling van enterprise-architectuur is om te bepalen hoe een organisatie haar huidige en toekomstige doelstellingen effectief kan bereiken.”

“Een referentiearchitectuur is als een handleiding die je vertelt hoe je mensen, processen, producten en diensten samenbrengt om een oplossing te creëren. Het laat zien hoe je specifieke technologieën het beste kunt gebruiken, waarbij je de best practices uit de sector volgt.”

Daarnaast hebben we gebruikersacceptatiecriteria nodig bij het opstellen van nieuwe functionaliteiten. Van tevoren checken we met de gebruiker wat de applicatie nodig heeft om te voldoen aan de eisen en daarmee goed genoeg is. Deze worden dan verwerkt in user stories.

3. Develop

Om in de development fase flexibel in te spelen op de behoeften van gebruikers, werken we agile en in sprints en geven we een demo. Tijdens een demo kan er feedback worden opgehaald met de gebruikers. Peer reviews en regressietesten zijn voor ons manieren om de software tussentijds te testen. Daarnaast vinden we het belangrijk dat de gebruiker nieuwe software accepteert voordat deze naar productie gaat. Met een gebruikersacceptatietest zorgen we ervoor dat nieuwe software pas wordt opgeleverd als de gebruikers tevreden zijn. Het moet bijdragen aan de werkzaamheden in het proces en meerwaarde toevoegen. Als de software op een gegeven moment groot genoeg is om ook echt waarde toe te voegen, dan gaat het over in de drive fase.

In deze fase wordt door een solution en/of technische (software, infrastructuur, data, cloud, security etc.) architect het ontwerp voor de technische oplossing gemaakt. Het doel van architectuur is om de meest optimale “fit for purpose” oplossing te bieden. Dit houdt in dat de oplossing effectief is en voldoet aan de behoeften, mogelijkheden en doelen van de organisatie, en tevens voldoet aan de eerdergenoemde Enterprise- en/of referentiearchitectuur. Daarnaast is architectuur is deze tijd ook agile en dus continu onderhevig aan veranderingen.

4. Drive

In de drive fase voegen we steeds nieuwe functionaliteiten toe door dezelfde stappen weer toe te voegen aan het proces. Met deze manier van werken heb je uiteindelijk een veel hogere ontwikkelsnelheid. In de drive fase nemen we ook nieuwe applicaties in beheer. Zo kunnen we ondersteunen bij het gebruik van de app en doen we het onderhoud zodat de applicatie probleemloos blijft werken.

Resultaat

De uitkomst van onze aanpak meten we in cijfers. Dat kan zijn als het gaat om een nieuw project en het nieuwe product moet zorgen voor een hogere omzet. Gaat het om een bestaand product? Dan kun je ook kijken naar het verbeteren van de winstmarge. De belangrijkste resultaten waar de focus op ligt zijn automation rate, marge en medewerkerstevredenheid.

Door het gebruik van low-code en door een goede analyse te doen voordat je begint met het ontwikkelen hoeft er minder geïnvesteerd te worden. Als je meer investeert in de dream en design fase, ben je minder geld kwijt in de develop fase en zal de ontwikkeling van de applicatie sneller worden doorlopen.

Benieuwd naar de mogelijkheden?

Ben je nieuwsgierig naar hoe jouw probleem opgelost kan worden met het 4D-model? Of ben je zelf al goed op weg met je eigen plan en wil je dat 1 van onze professionals met je mee kijkt? Neem dan vrijblijvend contact met ons op!

Jimmy Iliohan