By Ruben Schuring

Eén van de belangrijkste stappen in een Salesforce-implementatie, of je nou de consultant bent of de klant, is het definiëren van de vereisten of requirements. Als je niet heel helder beschrijft wat het nieuwe systeem moet doen is de kans groot dat er later functionaliteit mist of dat er dingen niet zo werken als je had gehoopt. En dus zit je met een systeem dat ineffiecient is of nog erger: niet aansluit bij je ‘core business’.

Het beschrijven van systeemvereisten en ze verzamelen in een leesbaar overzicht is vaak een fikse klus. Een beetje zoals het opruimen van je zolder; je weet dat het nog moet gebeuren maar het is moeilijk te overzien. Waar moet je beginnen? En hoe gedetailleerd moet je zijn?

In deze blog wil ik je graag laten zien hoe je ‘use cases’ gebruikt om vereisten te verzamelen en deel ik een paar best practices hoe je documentatie minder vervelend kan maken en beter kan laten aansluiten bij de praktijk van jouw implementatie.

Stel je voor dat jouw nonprofit-organisatie een klantcontact-centrum heeft waar alle vragen van de achterban worden beantwoord. In het verleden heb je daarvoor misschien systeemvereisten opgeschreven als:

  • Het systeem moet cases accepteren die de achterban via de website indient
  • Het systeem routeert de case naar het juiste team voor afhandeling
  • De achterban moet een gesloten case weer kunnen openen
  • De achterban moet bestaande cases kunnen wijzigen
  • De achterban moet een bijlage kunnen toevoegen aan de case

En hoewel deze lijst de basics van case-invoer beschrijft, mis je hier ook nog een hoop cruciale informatie over hoe ze moeten worden afgehandeld. Wat moet een gebruiker bijvoorbeeld doen om een case te starten? Welke informatie is er nodig om de routering naar het juiste team mogelijk te maken?

Zonder de volledige context van case-afhandeling binnen jouw organisatie loop je de kans dat de vereisten straks netjes zijn afgetikt, maar de behoeften van jouw organisatie niet.

Een betere manier om je vereisten te structureren is met use cases. Een use case is een verzameling acties die de interactie tussen een gebruiker en het softwaresysteem beschrijft die gericht is op het stapsgewijs werken aan een activiteit van jouw organisatie of jouw achterban.

In een ideaal geval bevat een use case de volgende onderdelen:

  • Een gebruiker (dit kan jij of een supporter zijn)
  • Alle data input en output die benodigd is
  • Een duidelijke volgorde in de benodigde stappen
  • Een specifiek resultaat of doel (bijv. een succesvol ingediende case)

Maar hoe schrijf je nou een use case voor één van de bovenstaande punten? Laten we beginnen met een persoon die een case indient bij het klantcontact-centrum:

Use case: dien een case in bij het klantcontact-centrum

Korte beschrijving: Deze use case beschrijft een supporter die een vraag of probleem aandraagt bij het klantcontact-centrum.

De volgorde:

  1. De supporter logt in in het system. E-mail en wachtwoord worden gebruikt om de gebruiker te valideren.
  2. De supporter selecteert de optie om een case te openen
  3. De supporter beschrijft zijn of haar klacht of vraag. Vereiste data: naam, e-mail, beschrijving van de vraag. Optionele data: telefoonnummer, bijlage.
  4. De supporter krijgt de keus om de case in te dienen of te annuleren. De supporter kiest ‘indienen’.
  5. Het systeem valideert of alle benodigde informatie is verschaft. Het systeem geeft de case een uniek ID-nummer en meldt die aan de indiener. Het systeem geeft ook een melding weer dat de case succesvol is ingediend. Einde use case.


TIP: Begin optimistisch!

Begin je use cases optimistisch en beschrijf eerst hoe het proces loopt als het goed gaat. Dit is belangrijk want dit geeft weer hoe het systeem zou moeten werken en zo zie je ook makkelijk wat er mis kan gaan. Wat als de indiener op ‘annuleren’ klikt? Wat gebeurt er als niet alle vereiste informatie wordt ingegeven? Als je het gewenste scenario hebt beschreven kun je meer uitweiden over errors en uitzonderingen. En zo houd je de documentatie goed te volgen.

TIP: Houd je use cases simpel door CRUD weg te laten

CRUD staat voor create, read, update en delete. Een willekeurige gebruiker heeft vaak een bepaalde combinatie van deze rechten bij verschillende records. In de vereisten die we hierboven hebben beschreven zie je dat de indiener van de case hem ook moet kunnen wijzigen. Het is erg belangrijk dat je nadenkt over de verschillende soorten gebruikers in Salesforce en welke permissies ze moeten hebben. Het kan verleidelijk zijn om deze dingen mee te nemen in je use cases maar het mooie van Salesforce is nu juist dat je deze informatie niet hoeft te beschrijven. Salesforce regelt deze rechten namelijk via ‘Profiles’ en ‘Permission Sets’.

TIP: begin met het “wat” zodat je de beste “hoe” kan vinden

Een andere valkuil in het ontwikkelen van use cases is je verliezen in het beschrijven van hoe dingen gedaan moeten worden, of gedetailleerd vermelden hoe je Salesforce een bepaalde taak wilt laten uitvoeren. In de use case hierboven specificeren we niet hoe de gebruiker de vereiste informatie invoert in de case (door bijv. een dropdown-menu te gebruiken of een tekstveld). Maar als je de use case bekijkt kan het je zijn opgevallen dat de indiener zijn e-mailadres heeft moeten invoeren om in te kunnen loggen. Zou Salesforce dan enkele velden automatisch kunnen vullen zodat ze niet meer handmatig ingevoerd hoeven te worden? Natuurlijk kan dat! Door in de use case de “wat” te beschrijven wordt het makkelijker om de beste manier te vinden waardoor Salesforce dit proces kan stroomlijnen.

TIP: Zorg dat je use cases ook worden bijgewerkt

Stel je voor dat je na het bouwen van de use case voor het indienproces, je door wil gaan met het beschrijven van de case-routering. Misschien wordt dit nu handmatig gedaan, maar omdat je inmiddels de use cases aardig onder de knie hebt kun je je focussen op de data die nodig is voor het succesvol routeren van een case (en dus niet het “hoe” van je huidige, handmatige proces). Een belangrijke vraag is of de case gerelateerd is aan een dienst die je organisatie aanbiedt. Een geweldige optie in Salesforce is het gebruiken van routeringen om een case de juiste route te laten aflopen. Maar dan moet je wel die informatie al vragen wanneer men een case indient. Omdat je nu een use case hebt getiteld: ‘Indienen vraag/klacht bij klantcontact-centrum’ weet je precies waar je die informatie kunt updaten zonder dat je door ellenlange pagina’s hoeft te ploegen.

In deze blog gingen we in op hoe je vereisten kunt documenteren als ‘use cases’ zodat je gerelateerde informatie eerder identificeert en de gaten ontdekt die er nog in de data of processtappen zitten. Hopelijk helpen deze tips je met het verzamelen van belangrijke informatie voor jouw Salesforce-omgeving en maakt het jouw implementatie een succes!

Kijk ook eens naar:

 

 

Ruben Schuring

Ruben Schuring

Leave a Reply

Your email address will not be published. Required fields are marked *

USADutch