‘Wij maken vooral onderscheid tussen functionele en technische processen, maar de technische kant noemen we, om verwarring te voorkomen, liever geen ‘’processen’’. Het is het eenvoudigst uit te leggen door te kijken naar wat een niet-technisch onderlegd persoon wel en niet snapt. Als het voor deze persoon begrijpelijke taal is, draait het om functionele processen, bijvoorbeeld een blokkenschema waarmee je een flow beschrijft. Een technisch proces beschrijft wat er in een blokje van een blokkenschema gebeurt, zoals het updaten van systemen of beheren van mail-acties. Deze technische processen proberen we vaak te ‘’verstoppen’’ voor de klant. Gebruikers zijn namelijk helemaal niet geïnteresseerd in zulke details; als ze bij een bepaalde stap komen, moet er gewoon een mail uit. Wat daar allemaal voor moet gebeuren, is voor hen minder relevant.’

‘Meestal ben je dan te laat. Je twijfelt, of je bent tot de conclusie gekomen dat je de verkeerde keuze hebt gemaakt. Grote kans dat je al tijd en geld hebt geïnvesteerd, ook al draait het soms om een maandelijks abonnement dat je makkelijk op kunt zeggen. De oplossing en winst zitten echt in de voorbereiding.’

‘Veel mensen en organisaties laten zich verleiden door de interface; deze ziet er tegenwoordig vaak fantastisch uit. In de mooi geproduceerde demofilmpjes laten ze vaak alleen de functionaliteiten zien die goed werken, maar de zwakke punten komen uiteraard niet aan bod.

Je hebt iemand nodig die functioneel sterk is in het in kaart brengen van wat een softwarepakket precies moet doen. Wat je nodig hebt als bedrijf? Niet op het technische vlak, maar bijvoorbeeld qua de hoeveelheid gebruikers, het belang van specifieke taken en de tijd die op dit moment verloren gaat. Als een bepaalde taak één keer per maand door een persoon uitgevoerd moet worden, is het niet zo erg; dan kun je ervoor kiezen om het handmatig te doen. Maar als er een heel team 40 uur per week mee bezig is, kun je met de juiste keuze je investering ontzettend snel terugverdienen.

Bij Codecast zitten we voornamelijk op het automatiseren van taken die snel een groot rendement opleveren. Maar soms gaat dit niet, of willen klanten dit niet. Dan kijken we of we het gedeeltelijk kunnen automatiseren, of het bedrijfsproces beter kunnen stroomlijnen. Zo kan een taak van vier uur misschien in twee uur uitgevoerd worden. Als je echt een onderscheidend bedrijf bent en wilt afwijken van je concurrenten, moet je software of een partner kiezen die je daarin ondersteunt. Als je zomaar wat doet, kan het een pijnlijk proces worden.’

‘We zien vaak dat klanten eerst zelf oplossingen verzinnen waar soms al half over de techniek is nagedacht, maar daar proberen we altijd van weg te sturen; uiteindelijk krijgen wij altijd de vraag over een functioneel probleem. Wij kunnen intern het best bepalen met welke techniek dat gedaan moet worden. Op het moment dat we gaan voortbouwen op de technische oplossingen van anderen, is het lastiger om op de vraag achter de vraag te komen.

Zo hebben we weleens het verzoek gekregen om een extra rapportage in te bouwen. De klant zocht een betere manier om foutieve mutaties te vinden, maar met een redelijk simpele oplossing konden we de foutieve mutaties al veel eerder in het proces herkennen, en vaak zelfs voorkomen. In dit geval verdween de noodzaak voor een nieuw rapportagesysteem. Als we niet hadden doorgevraagd naar het daadwerkelijke probleem, hadden we deze oplossing nooit kunnen verzinnen. Het belangrijkste voordeel bij deze case is dat er nu niet een saai rapport bekeken hoeft te worden; bij foutieve mutaties komt er nu gewoon een notificatie binnen die direct verwerkt en opgelost kan worden. Er blijft meer tijd over om leuke en nuttige dingen te doen. En volgens mij is het realiseren van dit werkgeluk het hoogst haalbare resultaat dat we kunnen bereiken.’