Toetsbare PIM-eisen schrijven, met voorbeelden

Wanneer is een PIM-eis toetsbaar?

Een PIM-eis is toetsbaar als ze een actor, een functionaliteit en een voorwaarde noemt en een acceptatietest heeft. Haal één van die vier onderdelen weg en de eis wordt een uitspraak waar elke leverancier mee instemt. Deze pagina hoort bij de gids voor PIM-eisen, die laat zien waar het schrijfwerk in de selectie valt.

De actor is vaak het PIM zelf. Het kan ook een gebruikersrol zijn, zoals een data steward, of de leverancier, bij eisen over contract en service. De voorwaarde ontbreekt het vaakst. "Het PIM valideert GTIN's" klopt voor de meeste systemen. Bij "via elke invoerroute inclusief leveranciersimports" gaan leveranciers van elkaar verschillen.

De acceptatietest staat buiten de formulering. Houd de formulering op één zin en zet de test in een eigen veld, met de data, de handeling en het verwachte resultaat.

Slechte en goede PIM-eisen naast elkaar

Slechte PIM-eisen beschrijven een wens, een functienaam of twee functionaliteiten tegelijk. Goede eisen beschrijven één waarneembaar gedrag onder een benoemde voorwaarde. De tabel toont herschrijvingen zoals ze in PIMvendors-selecties vaak voorkomen.

Elke goede eis in de tabel kun je na een korte test beantwoorden met ja, gedeeltelijk of nee.

Hoe schrijf je de acceptatietest?

Schrijf de acceptatietest als één zin met de data, de handeling en het verwachte resultaat. De test is iets wat een leverancier in een scenariodemo op je eigen voorbeelddata uitvoert, of een document dat je kunt controleren.

In de praktijk dekken vier soorten bewijs alle eisen.

1. Live demo op je eigen data: voor de meeste DM-, PR- en IN-eisen, zoals een bestand importeren met opzettelijk ingebouwde fouten.
2. Configuratie op verzoek: voor eisen over inspanning, zoals live een workflow bouwen op basis van jouw procesbeschrijving.
3. Documentreview: voor eisen over security, SLA en beleid, zoals een ISO/IEC 27001-certificaat of een beleid voor API-versies.
4. Contractclausule of referentiegesprek: voor eisen over licentie, exit en partners.

Tests die jouw data vragen, bepalen wat je moet voorbereiden. Een test met "een van je leveranciersbestanden" betekent dat een echt leveranciersbestand klaar moet staan, waar nodig geanonimiseerd, voordat de scenario's vertrekken. In PIMvendors-selecties kost het voorbereiden van de voorbeelddata meer tijd dan het schrijven van de tests. Plan het als apart werkpakket. Hoe tests samen demostromen vormen, lees je bij scenariodemo's.

Hoe koppel je eisen aan bedrijfsprocessen?

Koppel elke eis aan één processtap en één eigenaar, en zet beide naast de ID van de eis. Met die herleidbaarheid wordt een lijst een verdedigbare set, omdat elke eis iemand heeft die haar nodig heeft en een proces dat zonder haar vastloopt.

Gebruik je procesplaten als ruggengraat. Gangbare PIM-processen zijn introductie van nieuwe producten, leveranciersonboarding, verrijking, vertaling, goedkeuring, publicatie naar kanalen, wijzigingsbeheer en uitfasering. Elke eis hoort bij één daarvan, of bij de platformprocessen van IT, security en inkoop.

Voeg drie kolommen toe aan je eisenlijst: processtap, eigenaar van de eis en demoscenario. De eerste kolom toont de dekking per proces. De tweede toont wie de eis bij het scoren verdedigt. De derde toont waar de eis wordt getest.

Eisen zonder processtap zijn kandidaten om te schrappen. Processtappen zonder eisen zijn gaten. Zodra de kolommen gevuld zijn, zie je beide binnen een uur. Prioriteiten volgen daarna uit de waarde van het proces, zoals uitgelegd bij PIM-eisen prioriteren.

Welke woorden maken een eis ontoetsbaar?

Vage bijvoeglijke naamwoorden en open werkwoorden maken een eis ontoetsbaar. Vervang ze door een maatstaf, een voorwaarde of concreet gedrag.

De EARS-patronen, ontwikkeld bij Rolls-Royce, geven een bruikbare discipline voor voorwaarden. Ze scheiden eisen die altijd gelden van eisen die gelden bij een gebeurtenis (when) of in een toestand (while). Andere patronen dekken ongewenst gedrag (if, then) en optionele functies (where). Voor PIM-eisen zijn de patronen voor gebeurtenissen en ongewenst gedrag het nuttigst. "Wanneer een leveranciersbestand wordt geïmporteerd" en "als een GTIN niet door de controle van het controlecijfer komt" maken de voorwaarde expliciet.

Een schrijfmethode in zes stappen voor PIM-eisen

Een programma van eisen schrijf je het best in een korte, gestructureerde reeks met één eigenaar. Onderstaande methode is hoe PIMvendors workshops over eisen begeleidt.

1. Breng de processen in kaart: teken de doelstromen voor introductie, onboarding, verrijking, publicatie en uitfasering.
2. Inventariseer de data: bouw de inventaris van attributen en families op zoals beschreven bij het productdatamodel ontwerpen.
3. Begin bij de checklist: filter de checklist met PIM-eisen op branche en regelgeving, en neem elk onderdeel over, pas het aan of schrap het.
4. Schrijf je eigen eisen: voeg eisen voor jouw specifieke processen toe in hetzelfde format, met een eigen ID-prefix.
5. Voeg tests en koppelingen toe: vul voor elke regel de acceptatietest, de processtap en de eigenaar in.
6. Review en bevries: haal dubbelingen weg, splits dubbele eisen, stel prioriteiten vast en bevries de set voordat de scenario's vertrekken.

Het bevriezen is essentieel. Eisen die na de demo's ontstaan, beschrijven meestal wat de favoriete leverancier liet zien, en daarmee verdwijnt de vergelijking die de selectie moest opleveren.