Een duidelijke dienstverlening zonder onduidelijkheid: 10 elementen zodat de klant weet wat hij koopt

De huidige Amerikaanse Federal Acquisition Regulation voor resultaatgerichte diensten adviseert om werk vooral te beschrijven aan de hand van de vereiste resultaten, in plaats van precies voor te schrijven hoe het moet worden uitgevoerd of alleen een aantal uren te noemen. De regels verwijzen ook naar meetbare prestatienormen en noemen in doelstellingen onder meer doel, scope, periode en plaats van uitvoering, achtergrond, vereiste resultaten en operationele beperkingen. [1]

Ook het Britse Digital, Data and Technology Playbook bevordert duidelijke, resultaatgerichte specificaties. Het adviseert expliciet om uit te gaan van de gebruiker en het op te lossen probleem, in plaats van vooraf een technische oplossing vast te leggen. [2]

De actuele Britse richtlijn over risicotoedeling en prijsbenaderingen stelt daarnaast dat prestatie-indicatoren meetbaar en objectief moeten zijn en dat leveranciers verantwoordelijk moeten worden gehouden voor resultaten waarop zij daadwerkelijk invloed hebben. [3]

Deze bronnen komen uit de publieke inkoop en vormen geen universele sjabloon voor elke dienst. Ze laten wel een zeer bruikbaar principe zien: een goede scope benoemt het verwachte resultaat, hoe dat kan worden beoordeeld en waar de verantwoordelijkheid ophoudt.

Een goede beschrijving moet tegelijk helpen:

De klant - begrijpen wat hij ontvangt, wat hij niet ontvangt en wat van hem wordt verwacht.

De specialist - grenzen van verantwoordelijkheid, aannames en het moment waarop een nieuw verzoek een scopewijziging wordt vastleggen.

Beide partijen - bepalen hoe redelijkerwijs kan worden vastgesteld dat het afgesproken werk is afgerond.

Als de beschrijving maar één van deze functies goed vervult, kan er nog steeds veel ruimte zijn voor discussie of verschillende interpretaties.

Begin met waarom de dienst nodig is.

Start niet met een lijst tools of werkzaamheden als de klant het doel nog niet begrijpt.

In plaats van:

"Configuratie van analyse, rapportages en gebeurtenissen."

beter:

"Het doel is betrouwbare gegevens te krijgen over de stappen in het formulier waar gebruikers het vaakst afhaken, zodat het team kan bepalen welke onderdelen verbetering nodig hebben."

Dit sluit aan bij het principe om behoeften en resultaten te beschrijven in plaats van vooraf een oplossing op te leggen, zoals het Britse Digital, Data and Technology Playbook aanbeveelt. [2]

Het doel beantwoordt "waarom?", terwijl het resultaat antwoord geeft op "wat moet er bestaan of waar zijn wanneer het werk klaar is?"

Een resultaat kan bijvoorbeeld zijn:

• een afgerond document,
• een werkende functie,
• een geïmplementeerde configuratie,
• afgerond onderzoek met conclusies,
• een voorbereid pakket materialen,
• een uitgevoerde sessie met een afgesproken samenvatting.

Bij resultaatgerichte diensten beschrijft de FAR eisen vooral via vereiste resultaten en niet alleen via de manier waarop het werk wordt uitgevoerd. [1]

Dat betekent niet dat elke dienst een bedrijfsresultaat moet garanderen dat de specialist niet beheerst. Een specialist kan zich verbinden aan het lanceren van een campagne binnen de afgesproken scope, terwijl een gegarandeerde omzetstijging van 30% van veel factoren buiten zijn controle kan afhangen.

De scope moet de concrete onderdelen van het werk benoemen die onder de afspraak vallen.

Bij een websiteproject kan dat bijvoorbeeld zijn:

• analyse van de huidige website,
• opstellen van de informatiearchitectuur,
• ontwerp van een afgesproken aantal schermen,
• mobiele versies,
• implementatie van het goedgekeurde ontwerp,
• basisdocumentatie voor overdracht.

Het gaat er niet om de langst mogelijke lijst te maken. Het gaat erom de belangrijkste onderdelen te benoemen die vóór de start invloed hebben op inspanning en verwachtingen.

De scope beschrijft het werk, terwijl opleveringen beschrijven wat de klant daadwerkelijk ontvangt.

Bijvoorbeeld:

• een bronbestand,
• een rapport in een afgesproken formaat,
• een werkende module,
• een code-opslagplaats,
• een set afbeeldingen,
• een opname,
• documentatie,
• een lijst met aanbevelingen,
• toegang tot een geconfigureerde omgeving.

Als de vorm van het resultaat belangrijk is, benoem die dan. "Rapport" kan twee pagina's tekst betekenen of een uitgebreid document met analyse, prioriteiten en voorbeelden. Alleen de naam is niet altijd voldoende.

Acceptatiecriteria beantwoorden de vraag: waaraan kan worden vastgesteld dat het afgesproken resultaat volgens de eisen is geleverd?

Ze kunnen bijvoorbeeld gaan over:

• volledigheid,
• overeenstemming met de afgesproken specificatie,
• een vereist formaat,
• werking op aangegeven apparaten of omgevingen,
• een maximumaantal fouten van een bepaalde categorie,
• levertijd,
• afgesproken kwaliteitsparameters.

De FAR vereist dat prestatienormen in resultaatgerichte diensten meetbaar zijn en zo zijn ingericht dat de uitvoering kan worden beoordeeld. [1]

De Britse richtlijn over risicotoedeling voegt toe dat indicatoren objectief moeten zijn en betrekking moeten hebben op resultaten waarop de leverancier invloed heeft. [3]

Daarom is "de klant is tevreden" veel minder bruikbaar dan een criterium dat gekoppeld is aan een specifiek en waarneembaar resultaat.

Een dienst is vaak afhankelijk van handelingen van de andere partij.

Het is nuttig om aan te geven of de klant moet zorgen voor:

• toegang tot systemen,
• inhoud of materialen,
• gegevens,
• merkinformatie,
• beslissingen en goedkeuringen,
• een contactpersoon,
• een testomgeving,
• reacties binnen een bepaalde termijn.

Als ontbrekende input van de klant het werk kan stilleggen, moet dat duidelijk zijn.

Verantwoordelijkheid voor de planning moet niet worden beschreven alsof de specialist handelingen beheerst waar hij feitelijk geen controle over heeft.

Prijs en planning zijn vaak alleen geldig onder bepaalde aannames.

Voorbeelden:

• de bestaande database is beschikbaar en werkt correct,
• de klant heeft rechten op de aangeleverde materialen,
• een extern systeem beschikt over een werkende interface,
• het project vereist geen migratie van historische gegevens,
• het aantal taalversies is vooraf vastgesteld,
• beslissingen worden genomen door één aangewezen persoon.

De GAO-gids voor betrouwbare kostenramingen beschouwt duidelijke scope, technische uitgangspunten, regels en aannames en analyse van risico en onzekerheid als belangrijke onderdelen van een degelijk ramingsproces. [7]

Een kleine dienst hoeft geen proces over te nemen dat voor grote programma's is ontworpen. Het principe blijft wel waardevol: als de raming afhangt van iets dat onjuist kan blijken, benoem dat.

Uitsluitingen zijn geen teken van een zwak aanbod. Ze laten vaak juist zien dat de afspraak goed is afgebakend.

Als iets gemakkelijk kan worden aangezien voor een inbegrepen onderdeel, is het nuttig expliciet te vermelden dat het niet inbegrepen is.

Bijvoorbeeld:

• aankoop van licenties,
• maken van inhoud,
• betaalde afbeeldingen,
• vertalingen,
• onderhoud na oplevering,
• werk aan een ander systeem,
• onbeperkte revisies,
• kosten van diensten van derden.

Het is niet nodig alles op te sommen wat de specialist niet doet. De nuttigste uitsluitingen zijn zaken waarvan de klant redelijkerwijs zou kunnen denken dat ze bij de dienst horen.

Een planning moet meer zeggen dan "ongeveer twee weken" als de voortgang afhangt van goedkeuringen of materialen van de klant.

Het is nuttig vast te leggen:

• wat de start van de planning activeert,
• of er tussenfasen zijn,
• welke beslissingen een fase afsluiten,
• hoeveel tijd de klant heeft om te reageren wanneer dat de planning beïnvloedt,
• hoe vertragingen worden gecommuniceerd,
• hoe de eindacceptatie verloopt.

Bij een eenvoudige dienst kunnen enkele zinnen voldoende zijn. Bij een grotere samenwerking helpen fasen beide partijen te begrijpen wat al is afgerond en wat er daarna moet gebeuren.

Een goede dienstbeschrijving moet uitleggen wat er gebeurt wanneer na de start een nieuwe eis ontstaat.

Een praktisch mechanisme kan heel eenvoudig zijn:

"Werk buiten de beschreven scope vereist vooraf bevestiging van de nieuwe scope, de gevolgen voor de planning en eventuele extra kosten."

Het is ook nuttig duidelijk te vermelden:

• het prijsmodel,
• de prijs of de manier waarop die wordt berekend,
• betalingsregels,
• mogelijke bijkomende kosten,
• regels voor extra revisierondes.

Dit voorkomt veranderingen niet. Het maakt van een verandering een bewuste beslissing in plaats van een verborgen uitbreiding van de oorspronkelijke afspraak.

Een duidelijke scope betekent niet dat elke stap van het werk van de specialist moet worden voorgeschreven.

Het Britse Digital, Data and Technology Playbook waarschuwt voor te gedetailleerde oplossingsspecificaties en stelt dat resultaatgerichte specificaties leveranciers ruimte kunnen geven om een effectievere aanpak voor het probleem voor te stellen. [2]

De FAR geeft eveneens de voorkeur aan het beschrijven van vereiste resultaten boven het exact voorschrijven van hoe het werk moet worden uitgevoerd. [1]

Daarom kan:

"de website moet de afgesproken scenario's correct ondersteunen op de aangegeven apparaten"

een betere eis zijn dan het exact voorschrijven van de technische implementatie wanneer de technologie zelf geen wezenlijke beperking is.

Natuurlijk kan de methode bij sommige diensten belangrijk zijn vanwege beveiliging, naleving, integratie of een technische norm. Dan moet die methode wel worden beschreven.

Bij het bepalen van de scope is het belangrijk onderscheid te maken tussen:

het directe werkresultaat van de specialist en een bedrijfsresultaat dat ook van andere factoren afhangt.

Een specialist kan zich bijvoorbeeld verbinden aan:

• het voorbereiden en lanceren van een campagne binnen de afgesproken scope,
• het uitvoeren van een analyse,
• het leveren van een afgesproken aantal materialen,
• het implementeren van een functie die aan vastgestelde criteria voldoet.

Veel meer voorzichtigheid is nodig bij garanties over omzet, klantenaantallen, zoekmachineposities of andere uitkomsten die afhangen van de markt, het budget, het product, acties van de klant of externe systemen.

De huidige Britse richtlijn voor risicotoedeling zegt expliciet dat leveranciers verantwoordelijk moeten zijn voor resultaten waarop zij invloed kunnen uitoefenen. [3]

Een goede beschrijving verzwakt verantwoordelijkheid niet. Ze legt verantwoordelijkheid daar waar daadwerkelijk controle bestaat.

Niet elke dienst heeft een document van meerdere pagina's nodig.

Bij een eenvoudige taak kan alle essentiële informatie in enkele alinea's passen. Bij een groter project kan dezelfde manier van denken uitgroeien tot een gedetailleerde specificatie, planning, acceptatiecriteria en formeel wijzigingsproces.

Een voorbeeld van Terms of Reference dat door de Wereldbank is gepubliceerd, stelt dat zo'n document de eisen aan adviesdiensten en de verwachtingen van de opdrachtgever duidelijk moet beschrijven en moet worden aangepast aan het concrete project en de lokale omstandigheden. [4]

Lengte is niet het belangrijkste. De kernvraag is of ontbrekende informatie de prijs, planning, verantwoordelijkheid of het verwachte resultaat realistisch zou kunnen veranderen.

Een dienstbeschrijving op een website of profiel kan slechts één onderdeel van het contractproces zijn. Concrete juridische verplichtingen hangen af van het land, het type transactie, de status van de partijen en de verkoopmethode.

Voor transacties tussen bedrijven en consumenten in de EU noemt het officiële Your Europe-portaal precontractuele informatie zoals de belangrijkste kenmerken van de dienst, de totaalprijs inclusief kosten, betalings- en uitvoeringsafspraken en, indien relevant, de duur van het contract. [5]

EU-richtlijnen voor bedrijven geven ook aan dat standaardvoorwaarden in consumentencontracten eerlijk en in duidelijke, begrijpelijke taal moeten zijn opgesteld, zodat de consument ook de economische gevolgen kan begrijpen. [6]

Deze eisen gelden voor bepaalde consumentenrelaties in de EU. Ze mogen niet automatisch worden toegepast op alle transacties tussen bedrijven of op andere rechtsgebieden.

Dit artikel is redactionele begeleiding voor het beschrijven van diensten, geen contractmodel en geen juridisch advies.

1. Begrijpt de klant welk probleem of doel de dienst aanpakt?
2. Is het eindresultaat benoemd?
3. Is duidelijk wat binnen de scope valt?
4. Weet de klant welke concrete onderdelen hij ontvangt?
5. Is er een redelijke manier om te beoordelen of het werk is afgerond?
6. Is duidelijk wat de klant moet leveren of regelen?
7. Zijn de belangrijkste aannames zichtbaar?
8. Zijn voor de hand liggende, mogelijk verwarrende uitsluitingen beschreven?
9. Houden planning en fasen rekening met afhankelijkheden aan beide kanten?
10. Is duidelijk wat er gebeurt wanneer de scope verandert?
11. Worden prijs, prijsmodel en bijkomende kosten op het juiste moment getoond?
12. Vermijdt de beschrijving beloften over resultaten die de specialist niet beheerst?

De beste test van een goede beschrijving is eenvoudig.

Na het lezen zouden klant en specialist ongeveer dezelfde antwoorden moeten geven op deze vragen:

Wat moet worden bereikt? Wat wordt uitgevoerd? Wat ontvangt de klant? Wat is niet inbegrepen? Wat moet de klant doen? Hoe weten we dat het werk is afgerond? Wat gebeurt er als de scope verandert?

Als de antwoorden overeenkomen, krijgen prijs en planning veel betere context.

Als de antwoorden verschillen, begint het probleem vaak niet pas tijdens de uitvoering. Het begint al in de dienstbeschrijving.

[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Bron openen

[2] UK Government - The Digital, Data and Technology Playbook
Bron openen

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
Bron openen

[4] World Bank - Sample Consultants Terms of Reference
Bron openen

[5] Your Europe - Contract information: what you should know before buying
Bron openen

[6] Your Europe - Contracts with consumers
Bron openen

[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Bron openen

Methodologische toelichting: de bronnen hebben verschillende reikwijdtes en vormen samen geen universele standaard voor dienstbeschrijvingen. Dit artikel gebruikt alleen de principes die zij daadwerkelijk ondersteunen: focus op resultaten, meetbaarheid, duidelijke scope, aannames, verantwoordelijkheid voor beïnvloedbare factoren en transparante informatie voor de klant.