FOCUS OP KLANTWAARDE: BEGIN BIJ HET EIND

Sofon gastheer van geslaagde bijeenkomst PMI Netherlands Chapter

De agile manier van werken biedt oplossingen voor de uitdagingen die in elke sector spelen: namelijk het juiste product, of de gewenste dienst, op tijd en vooral sneller opleveren. Om dit goed te kunnen doen, moet men beginnen bij het eind, namelijk het scherp krijgen van de klantbehoefte. Wat heeft de klant nu echt nodig om succesvol te zijn? Oftewel, wat levert klantwaarde? Eind februari organiseerde het PMI Netherlands Chapter er een bijeenkomst over bij Sofon, leverancier van guided solutions software, in Son. “Het gaat erom zo duidelijk mogelijk aan een ander te vertellen wat je wilt. Het moet twee keer goed zijn: de juiste behoeften (die de moeite waard zijn om in te investeren) invullen en deze ook nog eens goed (met een bepaalde kwaliteit) formuleren.”


Sofon fungeerde op 27 februari als gastheer voor de bijeenkomst van het PMI Netherlands Chapter, de Nederlandse tak van ’s werelds grootste beroepsorganisatie voor projectmanagement. Namens Sofon, leverancier van verkoopondersteunende software, trapte Chief Operating Officer Harry Doedens af met een korte presentatie.

1

Dialoog

Harry Doedens

Doedens illustreerde met een klantcase hoe de software van Sofon kan helpen om het offerteproces te stroomlijnen en versnellen. “Voordat ze met onze software werkten, had het bedrijf tien dagen nodig om een offerte door de eigen organisatie te krijgen. Dat kwam doordat de voor de offerte benodigde data niet goed gestructureerd waren. Daardoor gingen er intern heel veel vragen tussen de verschillende afdelingen heen en weer.” De software van Sofon bouwt modellen waarin gestructureerd alle informatie wordt verzameld over standaardonderdelen en -modules en hun onderlinge afhankelijkheden. Uit al die standaardonderdelen en -modules kan – zo nodig met verschillende opties voor de delen – een product worden opgebouwd. Aan de hand van de modellen kunnen in een dialoog met de software snel klantspecifieke producten worden geconfigureerd. “Na invoering van onze software duurde het uitbrengen van een offerte nog maar een half uur. Met alle winst van dien: een bedrijf hoeft niet meer met Excel-sheets en catalogi te werken, maar kan zijn offertes op een gestandaardiseerde manier uitbrengen. Zo verandert onze software bedrijven in winnende bedrijven. Toen ik dat vertelde tijdens de bijeenkomst, gingen bij veel deelnemers de ogen open. De projectmanagers stelden daarna gelijk de goede vragen, bijvoorbeeld hoe je deze nieuwe werkwijze voor offertes in de organisatie van een bedrijf kunt inbedden en wat daarvoor nodig is.”

Multidisciplinair

Zo gaf Doedens een mooi voorschot op de presentatie van Edwin Schumacher, die de hoofdmoot van de bijeenkomst vormde. Schumacher is managing partner van Synergio, een consultancybureau dat organisaties in uiteenlopende sectoren helpt bij het verbeteren van hun productontwikkelprocessen: sneller een beter resultaat behalen, dat aantoonbaar aan alle regelgeving voldoet. De aangewezen methode daarvoor is tegenwoordig lean en agile software en systems engineering. Actuele uitdaging volgens Schumacher is om de agile methodieken, zoals de scrum-aanpak bekend uit software engineering, op te schalen naar grotere, multidisciplinaire ontwikkelteams. “Hoe behouden grote organisaties de snelheid en wendbaarheid om nieuwe producten snel naar de markt te brengen? Daarvoor is bijvoorbeeld het Scaled Agile Framework ontwikkeld.”

Schumacher

Twee keer goed

Requirements zijn een belangrijk onderdeel van software en systems engineering, als input voor het ontwikkelproces én voor het test- en validatieproces. Requirements zijn er in vele vormen en maten en iedereen is een ‘requirements engineer’, zegt Schumacher onder verwijzing naar het huishoudelijke boodschappenlijstje dat hij thuis meekrijgt. “Het gaat erom zo duidelijk mogelijk aan een ander te vertellen wat je wilt. Dus niet alleen brood, maar ook of het wit of bruin moet zijn, en hoeveel.” Zoals hij met de titel van zijn presentatie, “The right requirements right”, aangeeft, moet het twee keer goed zijn: “De juiste behoeften (die de moeite waard zijn om in te investeren) invullen en deze ook nog eens goed (met een bepaalde kwaliteit) formuleren.”

Daarbij is het belangrijk dat steeds weer de focus gelegd wordt op de requirements die relevant zijn om de volgende stap uit te werken. “Zo houd je met minder requirements meer focus op de waarde voor de klant.” Synergio heeft voor het schrijven en checken van requirements een praktische set richtlijnen geformuleerd, die ervoor moeten zorgen dat de juiste requirements door de verschillende lezers eenduidig worden geïnterpreteerd.

Behoeften

Bij het eind beginnen, luidt het recept. “Wij gebruiken de metafoor van het leggen van een puzzel: je hebt een hoop stukjes en weet haast niet waar te beginnen, maar gelukkig is er de foto op de doos als referentie. Dit is het gewenste eindresultaat, en hiermee is voor iedereen helder waar hij naartoe moet werken.” Het vastleggen van deze ‘product vision’ moet expliciet gebeuren, ook al lijken delen soms vanzelfsprekend. Want als ze alleen maar impliciet in de hoofden van (sommige) mensen zitten, heeft iedereen z’n eigen aannames en een verschillend vertrekpunt.

Schumacher bepleit een aanpak waarbij men eerst de behoeften van de klant formuleert en dan de mogelijke oplossingen inventariseert. Door vervolgens de kenmerken van de verschillende oplossingen op een rij te zetten, kan men checken of die de behoeften van de klant vervullen. In andere woorden: de verwachtingen en de mogelijkheden met elkaar matchen.

Compliancy en complexity

Dat checken kan puntsgewijs gebeuren door elk kenmerk van de oplossing aan één of meer klantbehoeften te koppelen. Is aan alle behoeften voldaan en resteren er nog kenmerken, dan is de oplossing blijkbaar te ‘zwaar’ en dus ook te duur. Die oplossing kan dan worden ‘uitgekleed’ totdat er precies voldoende kenmerken over zijn om aan alle behoeften te voldoen. Omgekeerd kan een oplossing te ‘licht’ zijn als er onvoldoende kenmerken zijn om te voldoen aan alle behoeften. Dan moet de oplossing breder, of zwaarder, worden gemaakt.

graphicBij dit alles moet natuurlijk rekening worden gehouden met de interne en externe beperkingen die respectievelijk de eigen organisatie en de wet- en regelgeving opleggen. In een vergelijkbaar circulair proces moet worden gecheckt of aan deze randvoorwaarden wordt voldaan. “Dat is de spagaat of sandwich waar je inzit, tussen de klantbehoeften en de restricties.” Schumacher noemt dit het “managen van compliancy”. Tegelijk vragen moderne multidisciplinaire ontwikkeltrajecten ook om het “managen van complexity”. Om de complexiteit onder controle te houden, brengt hij een gelaagdheid aan in het ontwikkelproces (zie de illustratie): waarde / gebruik / werking / functie.

Integrale productontwikkeling

In de bovenste laag gaat het om de waarde die een nieuw product moet genereren. De conceptoplossingen daarvoor hebben – zoals gezegd – bepaalde kenmerken, die aan de verwachtingen van de klanten moeten voldoen. Tegelijkertijd zijn die kenmerken op te vatten als de verwachtingen (business requirements) voor de laag eronder, die van het gebruik van het nieuwe product. De mogelijke oplossingen voor de business requirements zijn processen die hun eigen kenmerken hebben waarmee op het gebruiksniveau aan de verwachtingen kan worden voldaan. Op hun beurt zijn die kenmerken de verwachtingen (user requirements) waarvoor in de volgende laag, die van de werking, mogelijke oplossingen worden bedacht: systemen.

Uiteraard hebben die systemen ook hun eigen kenmerken, waarmee aan de user requirements wordt voldaan. En het zijn zelf ook weer verwachtingen, waarvoor tot slot in de onderste laag, die van de functies, componenten met hun kenmerken (component requirements) worden gedefinieerd. “Zo krijg je een gelaagdheid in productontwikkeling. Vaak zie je dat men van klantbehoeften meteen naar de details van de oplossing springt. Dat zorgt voor verwarring, want op de verschillende niveaus heb je met verschillende stakeholders en verwachtingen te maken. Je kunt op al die niveaus tegelijkertijd actief zijn, zolang je de context maar kent. Dit noemen wij integrale productontwikkeling.”

Cirkelredeneringen

Het verhaal van Schumacher werd goed ontvangen en genereerde veel interactie met het publiek. De in totaal zestig deelnemers zorgden voor een vol huis bij Sofon. Onder hen Getjan Lammers, lid van het PMI Netherlands Chapter en projectmanager/scrum-master bij The PMO Company, die organisaties helpt bij het inrichten van hun projectmanagement office. “Heel veel dingen kwamen hier mooi bij elkaar. Zowel Harry als Edwin liet zien hoe je tot verbetering komt door in iteraties circulair te redeneren, om het offerteproces te verbeteren, respectievelijk tot betere requirements te komen. In beide gevallen gaat het erom de vraag van de klant goed te begrijpen, in de vorm van een passende offerte dan wel goede requirements. Ook bij projectmanagement gaat het erom dat je die cirkelredeneringen goed inricht. Uiteindelijk wil je de aannames die je altijd moet maken zo helder mogelijk krijgen, zodat je de risico’s die eraan zijn verbonden in kaart kunt brengen. Helemaal uitsluiten van die risico’s lukt niet, maar dit maakt het wel makkelijker om ze te minimaliseren.”

people

Raakvlakken

Harry Doedens zag duidelijke raakvlakken tussen Schumacher’s verhaal en Sofon’s aanpak van implementatieprojecten bij klanten. “Requirements zijn belangrijk, je moet weten wat de klant wil. We proberen aan de voorkant van ons salestraject de ‘pijn’ te vinden waar een bedrijf last van heeft. Als we die kennen, kunnen we daar oplossingen voor bedenken. Het invoeren gaat dan nog niet vanzelf, want de juiste mensen van de klant moeten erbij worden betrokken, er moet budget worden vrijgemaakt en het structureren van de data vergt vaak nog veel handwerk. We zijn nu in gesprek met The PMO Company hoe we onze projectaanpak nog kunnen verbeteren. Wij willen als bedrijf verder groeien en voor een volgende groeispurt is het wel handig als we veel ervaren projectmanagers hebben.”

Dynamiek

Wat Getjan Lammers ook aansprak was de ‘visual reasoning’ die zowel Doedens als Schumacher hanteerden. “Door dingen te tekenen maak je ze visueel en kun je er makkelijker over redeneren. Iets op een whiteboard of glazen wand tekenen, dat kom je in de agile/scrum-benadering veel meer tegen dan in de traditionele waterfall-projectaanpak.” Al met al was het wat Lammers betreft een succesvolle bijeenkomst en daar droeg de locatie een steentje aan bij. Het pand van Sofon bood een goede setting, verklaart hij. “De meeting was op de derde etage en de breaks waren op de begane grond. Mensen kwamen in beweging en legden telkens met anderen contact. Dat zorgde voor een eigen dynamiek.” Het is precies de uitdaging waarvoor Sofon zich in implementatieprojecten gesteld ziet, aldus Harry Doedens tot slot. “We leveren standaardsoftware, maar de klant is nooit standaard. Elke keer is de dynamiek in een project weer anders. Daarom moeten wij daar altijd mensen van de klant en van onszelf goed bij betrekken.” De dynamiek van projectmanagement vangen, daarin is het PMI Netherlands Chapter eind februari bij Sofon in Son uitstekend geslaagd.

Sofon Son