De begrippen behoefte, demand, vraag, aanvraag, requirement, eis, verzoek, opdracht, en wens worden vaak door elkaar gebruikt - en dat leidt net zo vaak tot (potentiële) misverstanden. Een degelijke architectuur vereist heldere definities. In USM zijn deze begrippen als volgt gepositioneerd en gedefinieerd in de context van dienstverlening.
- Een behoefte bestaat in het klantdomein. De behoefte specificeert iets wat de klant wenst of nodig heeft om in een tekort te voorzien.
- Zodra die klant besluit om die behoefte te activeren en het tekort in te vullen, vertaalt de klant de behoefte naar een verzoek aan de dienstverlener.
- De dienstverlener ontvangt de verzoeken in de vorm van meldingen en categoriseert deze naar de triggers van interne processen en werkstromen: wensen, wijzigingsverzoeken, incidenten, en service requests.
Deze relatie is weergegeven in het USM Klant-Leverancier Interactiemodel.
Primaire begrippen en alternatieve begrippen
USM definieert een behoefte dus als een (naar de leverancier) nog onuitgesproken specificatie van (een aspect van) de service die de klant wenst of nodig heeft om in een tekort te voorzien. Pas als de klant overgaat tot actie, door deze behoefte om te zetten in een melding (verzoek) aan de leverancier om in het tekort te voorzien, ontstaat er een op die interactie gebaseerde dienstverlening.
De behoefte c.q. het verzoek c.q. de melding kan betrekking hebben op zowel de voorziening als de ondersteuning daarvan.
De voorkeursbegrippen zijn dus behoefte, verzoek, melding. Ek van deze voorkeursbegrippen heeft één of meer alternatieve of verbijzonderde begrippen:
- Behoefte heeft als alternatieve begrippen: demand en vraag. De begrippen requirement, opdracht en eis kunnen hier ook als alternatief begrip voorkomen.
- Het verzoek van de klant heet vanuit het klantperspectief 'verzoek', maar vanuit het leveranciersperspectief heet dit 'melding'. De begrippen requirement, opdracht en eis kunnen hier opnieuw ook als alternatief begrip voorkomen, en soms zelfs vraag.
- Een melding wordt aan de leverancierszijde vertaald naar de meldingtypes wens, wijzigingsverzoek, incident, en service request. Ook als het een proactieve verbetering vanuit de leverancier betreft waarvoor een bijdrage van een toeleverancier is vereist, vertaalt die leverancier de bijdrage aan die verbetering (het risico) via een verzoek naar een reactieve melding voor de daaropvolgende toeleverancier in de keten.
