Project Texel: Een nieuwe manier van werken 

We hebben een compleet nieuw team samengebracht voor Project Texel. Een nieuwe organisatorische structuur met de volgende rollen: developers, consultants, een test coördinator, een UX designer, application & solution architects en een program manager. De taken en verantwoordelijkheden die hierbij komen kijken, kunnen het best uitgelegd worden terwijl ik onze ‘nieuwe manier van werken’ illustreer. 

Het vertalen van klantbehoeftes naar Foodware 365 

In dit eerste jaar van Project Texel ontwikkelen we een ‘Minimal Viable Solution’ voor foodbedrijven over de hele wereld. Om dit te bereiken hebben we een nieuwe manier van werken ontwikkeld. Maar voordat ik daar verder op inga, wil ik het eerst even over onze geschiedenis hebben. Schouw Informatisering bestaat meer dan 20 jaar. In deze periode hebben we SI Foodware voor Microsoft Dynamics NAV ontwikkeld en wereldwijd geïmplementeerd bij veel bedrijven in de foodindustrie. Dit hebben we niet alleen gedaan. Onze lokale Microsoft partners hebben ons geholpen om dit te bereiken. Deze ervaringen zorgen ervoor dat we een grondige kennis van de voedingsmiddelenindustrie hebben. Nu staan we voor de uitdaging om deze kennis door te zetten naar onze nieuwe oplossing: Foodware 365 voor Microsoft Dynamics 365 Business Central. Wat we niet gaan doen is onze huidige oplossing simpel ‘knippen en plakken’ naar Foodware 365. We gaan op basis van onze kennis de klantbehoeftes vertalen naar Foodware 365.

Rethink: Het herbedenken van functies per app 

Als eerste hebben we een lijst gemaakt van apps die noodzakelijk zijn voor een foodbedrijf. Per app beginnen we met het bedenken van welke functies nodig zijn. Het gaat in deze fase om de ‘Wat’ vraag: “Wat is nodig en welke functies zijn nodig om een volwaardige app te maken?”

En omdat we met een strakke planning werken, moeten we deze functies prioriteren. Daarom wijzen we elke afzonderlijke functie toe aan een van de volgende categorieën: Dissatisfiers, Satisfiers en Delighters. Uiteindelijk willen we een module realiseren met een gezonde mix aan functies uit alle drie de categorieën. De rollen uit het team die we in deze rethink fase nodig hebben, zijn de functionele experts, de solution architect en de application architect. De output van deze fase is een functionele decompositie.  

Tijdens deze fase betrekken we ook onze referentiegroep. Deze groep bestaat uit een paar van onze zeer gewaardeerde wereldwijde Microsoft-partners en een Nederlandse eindgebruiker van onze huidige oplossing. In een wekelijkse conference call bespreken we de functionele decompositie met hen en krijgen we waardevolle feedback. De interactie met de referentiegroep is om ervoor te zorgen dat we een Cloud oplossing met een wereldwijde ‘fit’ maken en dat we tegelijkertijd belangrijke feedback krijgen vanuit het perspectief van eindgebruikers. 

Redesign: Het herontwerpen van de softwareoplossing

De functionele decompositie is input voor de volgende fase, de redesign fase. In deze fase gaat het vooral om “hoe?”. Hier werken naast de functionele expert en de solution architect ook de lead developer, UX designer, test coördinator en consultants aan mee. De functionele decompositie wordt besproken, waarna we besluiten hoe de app ontwikkeld zal worden: in Business Central met AL code of buiten Business Central, gebruikmakend van de mogelijkheden van Azure en het Dynamics 365 platform. We beslissen ook of er API’s nodig zijn om de Foodware 365 functionaliteit beschikbaar te maken voor software oplossingen van derden. Een andere uitdaging in deze fase is het feit dat we een Cloud oplossing ontwikkelen die via Microsoft’s AppSource verkocht wordt. We weten daardoor niet welke Foodware 365 apps een klant uiteindelijk gebruikt. Daarom moeten alle apps ook los van elkaar goed werken. Ze kunnen niet meer monolithisch ontwikkeld worden, maar tegelijkertijd willen we wel dat het totale pakket van Foodware 365 apps meer is dan alleen een som van de onafhankelijke apps.

De output van de redesign fase zijn use cases en test scripts.  

Ontwikkelen, testen & documentatie

Deze output wordt in de volgende fase weer gebruikt: ontwikkelen, testen en het documenteren van de functies van de apps. Tijdens deze fase is heel het team betrokken. Een grote verandering tijdens het ontwikkelen van onze apps is dat dit niet meer via embedded code kan, maar het nu via extensies gaat. Deze mogelijkheid bestaat al langer, maar is nu essentieel omdat het een Cloud oplossing is.  

We bedoelen met ontwikkelen niet alleen het ontwikkelen van de code voor de benodigde functionaliteit, maar ook het ontwikkelen van geautomatiseerde test scripts. Deze geautomatiseerde test scripts garanderen de kwaliteit van onze oplossingen. Omdat het een Cloud oplossing is, is het onmisbaar om geautomatiseerde test scripts te hebben, anders kun je de snelheid van de periodieke Microsoft updates niet bijhouden.  

Tijdens periodieke validatiesessies toont de developer zijn of haar voortgang en worden de volgende stappen besproken en uiteindelijk overeengekomen.  

Intuïtieve en gemakkelijk toegankelijke Cloud oplossing 

Tijdens deze fase zorgen we er ook voor dat onze apps ‘Saasified’ zijn, wat betekent dat onze Cloud oplossingen intuïtief en gemakkelijk toegankelijk voor de eindgebruikers zijn. Dit doen we door tooltips, quick entry, notifications, headlines, assisted setup, ready to use cues, charts en Power BI reports toe te passen.  

En last but not least: we bieden per app een grondige documentatie. 

That’s it, hope you enjoyed reading my blog!