Het opstellen van een eisen- en functionele specificatie is gewoonlijk een van de verplichte taken vóór een ERP-implementatie. Toegegeven, het opstellen van deze twee documenten is niet een van de meest geliefde taken in het kader van een ERP-project. De voorbereiding vergt veel tijd en legt beslag op middelen die gewoonlijk elders dringender nodig zijn. Tijdsdruk of de benutting van capaciteiten zijn zelfs vaak een reden om de voorbereiding helemaal achterwege te laten of slechts zeer kort en oppervlakkig uit te voeren. De gevolgen van deze aanpak worden vaak pas later in de loop van het project duidelijk. Vooral in het geval van veeleisende ERP-projecten mag u echter niet voorbijgaan aan het opstellen van een specificatie van eisen. Het helpt u de implementatie zo goed mogelijk te plannen en zo de risico’s in het project te minimaliseren – om maar een paar van de voordelen te noemen. Waarom het zinvol is om een requirements specificatie op te stellen, wat deze moet bevatten en waar u nog meer op moet letten, leert u in dit artikel.

Definitie – Wat is een specificatie?

De specificatie van eisen is een document dat door de contractant wordt opgesteld. In een ERP-project is dit altijd de ERP-leverancier. Het is gebaseerd op de specificaties die de opdrachtgever, in dit geval de klant of belanghebbende, heeft geformuleerd in de specificatie van eisen. In een eisenspecificatie beschrijft de dienstverlener, meestal in zeer gedetailleerde vorm, hoe hij de eisen van de klant wil implementeren. Het bevat derhalve een concrete beschrijving van de oplossing, alsmede een gedetailleerd werkconcept en vastomlijnde, vooraf gezamenlijk overeengekomen streefdoelen. Bovendien definieert dit document de technische opties, functies en configuraties van het ERP-systeem waarmee deze doeltoestanden kunnen worden gerealiseerd. Kortom, het “hoe” en “waarmee” staan vooral centraal bij het opstellen van een eisenspecificatie. Het is als het ware de “routekaart” voor een soepele uitvoering en vormt een kader voor het gehele verloop van het project.

Bovendien dient de inhoud van de specificatie van eisen als contractuele basis voor de samenwerking tussen de klant en de ERP-leverancier en heeft deze ook een juridisch bindende status. Bovendien dient het als een acceptatiecriterium voor de geïmplementeerde ERP-oplossing aan het einde van het project. Zoals u ziet, heeft de specificatie van eisen haar bestaansrecht. Het komt steeds weer voor dat de termen specificatie van eisen en functionele specificatie als synoniemen worden gebruikt, hetgeen vaak tot misverstanden en verwarring leidt. Vanuit zuiver juridisch oogpunt is het zelfs bijzonder belangrijk in welk van de twee documenten iets is vastgelegd. Als een van de twee partijen zich niet houdt aan de eerder overeengekomen inhoud, kunnen de klant en de ERP-leverancier altijd terugvallen op de schriftelijke afspraken uit de functionele specificatie. Het is in dit verband belangrijk te weten dat alle eerder besproken afspraken tussen de klant en de ERP-leverancier hun geldigheid verliezen door de eisenspecificatie, tenzij daarin iets anders is aangetekend.

Misschien bent u ook geïnteresseerd in:

Wat zijn de voordelen van een eisenspecificatie?

Een bestek wordt eigenlijk altijd gebruikt wanneer er een opdrachtgever en een aannemer zijn. Het is bijzonder nuttig voor zeer omvangrijke projecten. Naast de rechtszekerheid die het beide partijen biedt, heeft het nog drie andere grote voordelen:

Planning beveiliging voor de klant en ERP provider.

Dankzij de zeer nauwkeurige documentatie van de doelstaten en de noodzakelijke werkstappen is er zowel bij de klant als bij de ERP-leverancier op elk moment duidelijkheid over het projectproces. Zo wordt ervoor gezorgd dat de termijnen zoveel mogelijk worden nageleefd. Bovendien weten beide partijen op welk ogenblik de voltooiing van het project wordt verwacht en kunnen zij dienovereenkomstig plannen. Maar dat niet alleen – het helpt ook om het budget in de gaten te houden. Elke aanpassing heeft een invloed op de kosten en zo kan worden voorkomen dat het uit de hand loopt. De klant weet dus precies wat hij krijgt voor zijn geld en de aannemer kan zijn uitgaven met vertrouwen berekenen.

Transparante processen

De gedetailleerde schriftelijke formulering van de oplossingsrichtingen maakt het hele traject naar go-live transparant. Alle betrokken partijen weten op elk moment op welk punt van de uitvoering zij zich bevinden en welke verdere stappen nog nodig zijn totdat het project is voltooid.

Minder heronderhandeling

Een goed uitgewerkte specificatie van eisen bespaart in de eerste plaats zenuwslopende nieuwe onderhandelingen en discussies. Zoals reeds gezegd, kunnen zowel de klant als de ERP-leverancier te allen tijde vertrouwen op de punten die in het document zijn overeengekomen – wat niet in de specificatie van eisen staat, maakt geen deel uit van de leveringsomvang. Voor alle volgende wijzigingsverzoeken wordt een vervolgverzoek aangemaakt. Latere opleveringen, wijzigingen en de zogenaamde “scope creep” – een ongecontroleerde wildgroei van projectvereisten tijdens de uitvoering – kunnen zo gemakkelijk worden vermeden.

Misschien bent u ook geïnteresseerd in:

Proces – Van specificatie van eisen tot functionele specificatie

In de regel bereidt de klant of potentiële klant de specificaties voor en tijdens een ERP-workshop bespreken de klant en de potentiële ERP-leverancier welke punten kunnen worden geïmplementeerd en hoe. Daartoe nemen de aspirant-klant en de aanbieder samen de afzonderlijke punten door en de aanbieder bepaalt of deze in de norm zijn opgenomen dan wel of een aanpassing noodzakelijk is. Met betrekking tot de eisen die in het bestek zijn opgenomen, wordt vaak advies verstrekt door de ERP-leverancier. Als een eis niet zinvol lijkt of een aanvullende functie of dienst in dit verband geschikter zou zijn, doet de dienstverlener gewoonlijk een tegenvoorstel. De specificatie van eisen wordt gewoonlijk opgesteld nadat de selectie van de EPP is voltooid en aan het begin van de uitvoeringsfase. Bij TimeLine wordt de eisenspecificatie soms tijdens de workshop of kort daarna opgesteld. De met de belanghebbende besproken punten worden gedocumenteerd en voor dit doel samengevat.

In de regel heeft de projectmanager één dag per workshopdag nodig voor follow-up. De specificatie van de vereisten bepaalt uiteindelijk de inspanning, d.w.z. hoe duur het ERP-project uiteindelijk zal uitvallen. Hoewel het de basis voor de offerte vormt, betekent het niet dat de bestelling zal worden geplaatst. Op dit moment kunnen andere aanbieders nog “in het spel” zijn. De prospect kan dan beslissen of de concurrentie misschien een bod heeft gedaan dat meer mogelijkheden biedt of gewoon beter bij het bedrijf past. Voordat de prospect een keuze maakt, kunnen nog wijzigingen in de specificaties worden aangebracht. Op het moment dat de potentiële klant een ERP-leverancier selecteert, maakt de functionele specificatie deel uit van het koopcontract en kan deze niet meer worden gewijzigd. De potentiële klant bestelt op basis van het bestek en u bereikt een zogenaamde wilsovereenstemming.

Wat als de klant nog aanpassingen wil doen?

Vooral bij grote projecten doen zich tijdens de uitvoering vaak ongeplande wijzigingen voor. Indien de klant echter achteraf iets wil herzien, verandert ook de koopovereenkomst. Voor elke aangevraagde wijziging beslist de ERP-leverancier dus of de post in kwestie nog in het budget is opgenomen of niet. Indien dit niet het geval is, wordt een tweede aanbieding of een vervolgopdracht aangemaakt. Alles wat verder gaat dan de specificaties is een vervolgopdracht. Het uurtarief blijft hetzelfde, maar de klant bevindt zich in een betere onderhandelingspositie als hij vanaf het begin meer werk bestelt en niet achteraf extra functies bestelt.

Hoe wordt een succesvolle implementatie gemeten?

Licenties worden na de installatie met de klant doorgenomen. Wat de aanpassingen betreft, deze worden niet eenmalig gecontroleerd aan het einde van het project, zoals u misschien zou denken. Het is veeleer een proces dat continu wordt uitgevoerd en gecontroleerd, bijvoorbeeld wekelijks of maandelijks. Tegelijkertijd is dit ook een terugkoppeling voor beide partijen of u nog op schema ligt.

Misschien bent u ook geïnteresseerd in:

Structuur en inhoud – Deze punten moeten worden opgenomen in een specificatie van eisen

Een specificatie van eisen wordt op de meest uiteenlopende gebieden gebruikt, een standaardisatie is daarom eenvoudigweg niet mogelijk. Er zijn geen voorschriften of wettelijke normen die beschrijven wat de inhoud van een eisenspecificatie moet zijn, welke structuren moeten worden gevolgd of hoe een eisenspecificatie er in het algemeen uit moet zien. Er zijn echter verschillende benaderingen – bij de ontwikkeling van software is de volgende structuur succesvol gebleken:

Inleiding

Het is altijd raadzaam een samenvatting te maken van de belangrijkste kerngegevens van een ERP-project. Zorg ervoor dat alle betrokken personen uitdrukkelijk worden genoemd en dat het project kort wordt beschreven. Ook de communicatiekanalen moeten hier worden vermeld.

  • Wie is bij het project betrokken?
    • Aannemer en klant,
    • Belanghebbenden,
    • Projectteam,
    • Contactpersonen voor vragen of problemen
  • Zijn de communicatiekanalen vermeld?
  • Waar gaat het project over?
  • Hoe moet het eindresultaat eruit zien?
    • Beschrijving van de mijlpalen,
    • Algemene voorwaarden
      • Vaststelling van termijnen (voltooiing, aanvaarding, invoering)
  • Indien van toepassing, bijzondere kenmerken van het project

Doelstellingen en niet-doelstellingen van het project

Het moet duidelijk zijn dat het doel van het project moet worden vermeld. Er zijn echter vaak punten in een ERP-implementatie die op de een of andere manier “dokken” op de periferie van het project. Daarom kan het nuttig zijn om naast de projectdoelstellingen ook de niet-doelen te definiëren. Als uitdrukkelijk wordt bepaald welke gebieden tot het project behoren en welke niet, kunnen discussies gemakkelijk worden vermeden. Door niet-doelen te formuleren worden de grenzen van het project duidelijker en de “grijze zone” kleiner. Zo krijg je snel duidelijkheid over wat “In Scope” is en wat “Out Of Scope” is in een project.

  • Waar zal het project over gaan?
  • Wat wordt in het project uitdrukkelijk niet behandeld?
  • Welke problemen zal het project oplossen?

Toepassingsgebied en productomgeving

Ook het latere toepassingsgebied en de omgeving van het product moeten in de functionele specificatie worden gespecificeerd. Dit omvat onder meer de doelgroep, de toepassingsgebieden, de bedrijfsprocessen die zullen worden beïnvloed of zelfs de bedrijfsomstandigheden.

Functies

Zorg er bovendien voor dat alle functies en gebruikssituaties in detail worden beschreven.

  • Hoe en onder welke voorwaarden werkt de functie?
  • Welke invloed heeft dit op de verdere bedrijfsprocessen?

Diensten

De diensten beschrijven de eisen die u stelt aan een bepaalde functie. Dit omvat bijvoorbeeld de uitvoeringstijd of de nauwkeurigheid van een berekening. Zorg ervoor dat alle diensten vermeld zijn.

Kwaliteitseisen

Voorts moeten de kwaliteitseisen worden samengevat:

  • Wat zijn uw kwaliteitseisen?
  • Hoe ziet kwaliteitsborging, kwaliteitscontrole, kwaliteitsaanvaarding eruit?

Om dit nog preciezer te specificeren, is het nuttig om aan bepaalde kenmerken een kwaliteitsniveau toe te kennen, zoals:

  • Veranderlijkheid = niet relevant
  • Efficiëntie = goed
  • Gebruikersinterface

Basisvereisten voor het type lay-out, dialoogstructuur of toegangsrechten moeten hier worden vermeld.

Andere en bijzondere eisen

Het gaat bijvoorbeeld om documentatie, boekhouding of beveiligingseisen zoals wachtwoordbeveiliging.

Technische eisen

Hier moet de technische uitrusting worden vermeld die voor de uitvoering nodig is. Het is zinvol een lijst te maken van de software- en hardwaresystemen die voor de toepassing moeten worden geïnstalleerd. Dit is onder meer van belang om de beschikbaarheid van de netwerkverbinding te garanderen.

  • Welke uitrusting heb je nodig voor welke taak?

Interfaces

Alle bestaande systemen en producten, alsmede de interfaces moeten hier worden geregistreerd. Dit is belangrijk om het product te kunnen koppelen aan alle andere toepassingen. Zijn er misschien reeds projectgerelateerde systemen en/of producten die niet door de contractant hoeven te worden geïmplementeerd?

Probleemanalyse

Hierin moet een overzicht worden gegeven van de belangrijkste problemen en wellicht van de problemen die zich naar verwachting zullen voordoen. Voor de meest waarschijnlijke problemen moet een oplossingsaanpak klaarstaan.

Projectontwikkeling

In dit punt moet zo nauwkeurig mogelijk worden beschreven welke stappen op welk moment zijn gepland en hoe het gehele project is georganiseerd.

Tests en acceptatievoorwaarden

Tests controleren het product vóór voltooiing op functies, kenmerken en kwaliteitskenmerken. Na een foutloze run kan het product als afgewerkt worden verklaard.

  • Aan welke voorwaarden moet worden voldaan?

Dit is slechts één voorbeeld van hoe een specificatieblad eruit kan zien. Sommige criteria zijn onontbeerlijk, andere zijn belangrijk maar niet doorslaggevend. Weer andere zijn wenselijk, maar u kunt zonder. Welke functies een “must have” of “nice to have” zijn, verschilt van bedrijf tot bedrijf. Zorg er alleen voor dat ze duidelijk als zodanig herkenbaar zijn. De afzonderlijke punten kunnen meer of minder gedetailleerd worden beschreven, maar met name de technische vereisten moeten zeer gedetailleerd worden beschreven. Uiteindelijk is het van belang dat de eisen uit het bestek overeenkomen met de uitleg in de specificatie van eisen en dat er geen ruimte voor interpretatie overblijft. De specificatie van de eisen moet goed beschreven en gedocumenteerd zijn, weinig ruimte voor interpretatie laten, specifiek zijn, en een raming van de noodzakelijke inspanning bevatten. Als vuistregel geldt dat er geen vragen onbeantwoord mogen blijven en dat een buitenstaander moet begrijpen wat er bedoeld wordt.

Dit zou je ook kunnen interesseren:

Waar moet je nog meer op letten?

Vanuit het oogpunt van de klant moet u eerst de tijd nemen om de specificatie van de eisen zorgvuldig te bekijken en er niet zomaar doorheen te wuiven zonder ze te lezen. Concentreer u vooral op de interpretatie van uw eisen en controleer of ze volgens uw wensen zijn uitgevoerd – eenvoudig, maar het kan u later veel moeite besparen. Bovendien bestaat altijd het gevaar dat u bij het opstellen van de eisen en specificaties de werkelijke toestand van het bedrijf verdoezelt. Dit betekent dat u de kans mist om het potentieel voor verbetering door de invoering van het nieuwe systeem te benutten. Neem het ERP-project als een kans om uw workflows en bedrijfsprocessen kritisch te bekijken – op die manier kunt u het potentieel beter benutten.

Vanuit het oogpunt van de ERP-leverancier is het zinvol enige tijd te investeren in de ontwikkeling, tot in detail af te stemmen met de klant en niets onopgelost te laten. Als vragen onbeantwoord blijven, als u op zoek bent naar een antwoord en als er knelpunten zijn, verduidelijk dit dan onmiddellijk met de klant. Het komt erop aan bij het opstellen zo nauwkeurig en gedetailleerd mogelijk te werk te gaan. Het is ook raadzaam om in de formulering begrijpelijke taal te gebruiken en, indien mogelijk, technische termen te vermijden. Veel verschillende mensen lezen de specificaties – niet allemaal hebben ze een diepgaand technisch inzicht. Om complexe inhoud op een begrijpelijke manier over te brengen, zijn grafische voorstellingen ook nuttig. Werk met diagrammen, tabellen of mind maps om de wensen van de klant te visualiseren en ze zo begrijpelijk mogelijk te maken.

Conclusie

Het opstellen van een specificatie van eisen is een noodzakelijke stap om de risico’s in een ERP-project te minimaliseren. Enerzijds dient het om te voldoen aan de eisen die in het bestek zijn opgenomen en om de uitvoering zo goed mogelijk te plannen, zodat er aan het eind geen onaangename verrassingen zijn. Anderzijds helpt het om de geïmplementeerde oplossing aan het eind van het project te valideren en beide partijen zekerheid te bieden. Het is vooral belangrijk het verschil te kennen tussen specificaties en eisen. Juridisch gezien maakt het een groot verschil in welk van de twee documenten iets werd gedefinieerd.

Als u meer wilt weten over behoefteanalyse, specificaties en functionele specificaties of het gehele functionele aanbod van TimeLine ERP, stuur ons dan een bericht via het contactformulier, schrijf naar info@timelineconsulting.nl. We horen graag van u en adviseren u graag!