Vereisten specificeren in het ERP-project – de wensen van de klant realiseren

Het opstellen van een vereisten- en functionele specificatie is meestal een van de verplichte taken voor een ERP-implementatie. Toegegeven, het opstellen van deze twee documenten is niet een van de meest populaire taken in een ERP-project. De voorbereiding ervan kost veel tijd en legt beslag op middelen die elders meestal dringender nodig zijn. Tijdsdruk of bezettingsgraad zijn vaak zelfs een reden om ze helemaal niet of slechts heel kort en oppervlakkig op te stellen. De gevolgen van deze aanpak worden vaak pas later in het project duidelijk. U moet het opstellen van een functionele specificatie niet overslaan, vooral niet bij veeleisende ERP-projecten. Het helpt u om de implementatie zo goed mogelijk te plannen en zo de risico’s in het project te minimaliseren – om maar een paar voordelen te noemen. In dit artikel leest u waarom het zinvol is om een functionele specificatie te maken, wat er in moet staan en waar u nog meer op moet letten.</strong

Definitie – Wat is een functionele specificatie?

De eisenspecificatie is een document dat door de aannemer wordt gemaakt. In het geval van een ERP-project is dit altijd de ERP-leverancier. Het is gebaseerd op de specificaties die door de klant, in dit geval de klant of belanghebbende, zijn geformuleerd in de eisenspecificatie. In een functionele specificatie beschrijft de leverancier, meestal in zeer gedetailleerde vorm, hoe hij van plan is om de eisen van de klant te realiseren. Het bevat daarom een concrete beschrijving van de oplossing, evenals een gedetailleerd werkconcept en duidelijk gedefinieerde doeltoestanden die van tevoren gezamenlijk zijn overeengekomen. Dit document definieert ook de technische mogelijkheden, functies en configuraties van het ERP-systeem waarmee deze doelstellingen gerealiseerd kunnen worden. Kortom, het “hoe” en “waarmee” zijn bijzonder belangrijk bij het maken van een functionele specificatie. Het is als het ware de “routekaart” voor een soepele implementatie en vormt een kader voor het hele verloop van het project.

 

Bovendien dient de inhoud van de eisenspecificatie als contractuele basis voor de samenwerking tussen de klant en de ERP-leverancier en heeft het ook een juridisch bindende status. Aan het einde van het project dient het ook als acceptatiecriterium voor de geïmplementeerde ERP-oplossing. Zoals u kunt zien, heeft de eisenspecificatie absoluut bestaansrecht. Steeds weer worden de termen eisen-specificatie en verplichtingen-specificatie door elkaar gebruikt, wat vaak tot misverstanden en verwarring leidt. Vanuit zuiver juridisch oogpunt is het in feite bijzonder belangrijk in welk van de twee documenten iets is vastgelegd. Als één van de twee partijen zich niet houdt aan de eerder overeengekomen inhoud, kunnen de klant en de ERP-leverancier zich te allen tijde beroepen op de schriftelijke afspraken uit de specificaties. In deze context is het belangrijk om te weten dat alle eerder besproken afspraken tussen de klant en ERP-leverancier hun geldigheid verliezen als gevolg van de eisenspecificatie, tenzij anders vermeld in de specificatie.

U bent misschien ook geïnteresseerd in:

• De eisenspecificatie – Een handleiding voor de klant
• Waarom is een requirements-analyse zo belangrijk?
• Kostenfactoren van een ERP-implementatie

Wat zijn de voordelen van een functionele specificatie?

Een functionele specificatie wordt eigenlijk altijd gebruikt als er een klant en een aannemer zijn. Het is vooral nuttig voor zeer uitgebreide projecten. Naast de rechtszekerheid die het beide partijen biedt, heeft het nog drie andere grote voordelen:

Planningszekerheid voor de klant en ERP-leverancier

Dankzij de zeer nauwkeurige documentatie van de doelstatussen en de noodzakelijke werkstappen, zijn zowel de klant als de ERP-leverancier te allen tijde op de hoogte van de planning van het project. Dit zorgt ervoor dat deadlines zoveel mogelijk gehaald worden. Bovendien weten beide partijen wanneer het project naar verwachting voltooid zal zijn en kunnen ze dienovereenkomstig plannen. Maar dat is niet alles – het helpt ook om het budget in de gaten te houden. Elke aanpassing heeft invloed op de kosten en dit voorkomt dat ze uit de hand lopen. De klant weet dus precies wat hij krijgt voor zijn geld en de aannemer kan zijn uitgaven met zekerheid berekenen.

Transparante processen

De gedetailleerde schriftelijke formulering van de oplossingsaanpak maakt het hele proces tot aan de go-live transparant. Alle betrokkenen weten te allen tijde in welk stadium van implementatie ze zich bevinden en welke stappen er nog nodig zijn totdat het project is afgerond.

Minder heronderhandelingen

Eerst en vooral bespaart een goed ontwikkelde specificatie zenuwslopende heronderhandelingen en discussies. Zoals al eerder vermeld, kunnen zowel de klant als de ERP-leverancier op elk moment vertrouwen op de punten die in het document zijn overeengekomen – alles wat niet in de specificatie van vereisten staat, valt niet onder de leveringsomvang. Voor alle latere wijzigingsverzoeken wordt een vervolgverzoek aangemaakt. Latere leveringen, wijzigingen en zogenaamde “scope creep” – een ongecontroleerde toename van projectvereisten tijdens de implementatie – kunnen zo gemakkelijk worden voorkomen.

U bent misschien ook geïnteresseerd in:

• 3 tekenen dat het tijd is voor een ERP-verandering
• Watervalmethode of agile ERP-implementatie?
• Waarom mislukt een ERP-project?

Procedure – van eisenspecificatie tot functionele specificatie

In de regel stelt de klant of potentiële klant de specificaties op en als onderdeel van een ERP-workshop bespreken de klant en de potentiële ERP-leverancier welke punten kunnen worden geïmplementeerd en hoe. De potentiële klant en de leverancier nemen samen de afzonderlijke punten door en de leverancier bepaalt of deze in het standaardsysteem zijn opgenomen of dat maatwerk nodig is. De ERP-aanbieder geeft vaak advies over de vereisten die in de specificaties staan. Als een vereiste niet zinvol lijkt of als een extra functie of service in deze context geschikter zou zijn, doet de leverancier meestal een tegenvoorstel. De eisenspecificatie wordt meestal opgesteld nadat de EPP-selectie is afgerond en aan het begin van de implementatiefase. Bij TimeLine worden de specificaties soms tijdens de workshop of kort daarna opgesteld. De punten die met de belanghebbende partij zijn besproken, worden gedocumenteerd en samengevat.

In de regel heeft de projectmanager één dag per workshopdag nodig voor vervolgwerk. De eisenspecificatie bepaalt uiteindelijk de kosten, d.w.z. hoe duur het ERP-project uiteindelijk zal zijn. Hoewel het de basis is voor de offerte, betekent het nog niet dat de order wordt geplaatst. Op dit punt kunnen andere aanbieders nog steeds “in het spel” zijn. De potentiële klant kan dan beslissen of de concurrentie misschien een aanbod heeft gedaan dat meer functies biedt of gewoon beter bij het bedrijf past. Voordat de potentiële klant een keuze maakt, kunnen er nog wijzigingen in de specificaties worden aangebracht. Op het moment dat de potentiële klant een ERP-leverancier selecteert, maakt de specificatie deel uit van het koopcontract en kan deze niet meer worden gewijzigd. De potentiële klant bestelt op basis van de specificaties en u gaat een zogenaamde intentieovereenkomst aan.

Wat als de klant toch nog aanpassingen wil doen?

Vooral bij grote projecten ontstaan er vaak ongeplande wijzigingen tijdens de implementatie. Maar als de klant achteraf iets wil wijzigen, verandert ook het koopcontract. Telkens als er een wijziging wordt aangevraagd, beslist de ERP-leverancier of het item in kwestie nog in het budget is opgenomen of niet. Als dit niet het geval is, wordt er een tweede offerte of een vervolgorder aangemaakt. Alles wat verder gaat dan de specificaties is een vervolgorder. Hoewel het uurtarief hetzelfde blijft, staat de klant in een betere onderhandelingspositie als hij vanaf het begin meer diensten bestelt en niet achteraf extra functies bestelt.

Hoe wordt een succesvolle implementatie gemeten?

De licenties worden na de installatie met de klant doorgenomen. Aanpassingen worden niet eenmalig aan het einde van het project gecontroleerd, zoals misschien wordt verondersteld. Het is veeleer een proces dat continu wordt uitgevoerd en gecontroleerd, bijvoorbeeld wekelijks of maandelijks. Dit geeft ook feedback voor beide partijen of u nog steeds op schema ligt.

U bent misschien ook geïnteresseerd in:

• Wat is een ERP workshop precies?
• Waarom online presentaties de moeite waard zijn
• ERP training in het bedrijf – is het de moeite waard?

Structuur en inhoud – deze punten moeten worden opgenomen in een specificatie van vereisten

Een specificatieblad wordt op veel verschillende gebieden gebruikt, dus standaardisatie is eenvoudigweg niet mogelijk. Er is geen regelgeving of wettelijke norm die beschrijft welke inhoud een functionele specificatie moet hebben, welke structuren gevolgd moeten worden of hoe een functionele specificatie er in het algemeen uit moet zien. Er zijn echter verschillende benaderingen – de volgende structuur heeft zich bewezen bij softwareontwikkeling

Inleiding

Het is altijd raadzaam om de belangrijkste kerngegevens voor een ERP-project samen te vatten. Zorg ervoor dat alle betrokken personen expliciet worden genoemd en dat het project kort wordt beschreven. De communicatiekanalen moeten hier ook vermeld worden.

• Wie is betrokken bij het project?
  • Aannemer en opdrachtgever,
  • Stakeholders,
  • Projectteam,
  • Contactpersoon voor vragen of problemen
• Zijn de communicatiekanalen vermeld?
• Waar gaat het project over?
• Hoe moet het eindresultaat eruit zien?
  • Beschrijving van de mijlpalen,
  • Kadervoorwaarden
    • Bepaling van deadlines (voltooiing, acceptatie, implementatie)

• Indien nodig, speciale kenmerken van het project

Doelstellingen en niet-doelstellingen van het project

Het zou duidelijk moeten zijn dat de doelstelling van het project vermeld moet worden. Er zijn echter vaak punten in een ERP-implementatie die op de een of andere manier aan de rand van het project “gedokt” zijn. Daarom kan het nuttig zijn om naast de projectdoelen ook de niet-doelen te definiëren. Als expliciet wordt vastgelegd welke gebieden deel uitmaken van het project en welke niet, kunnen discussies gemakkelijk worden vermeden. Door niet-doelen te formuleren, worden de grenzen van het project duidelijker en het “grijze gebied” kleiner. Op deze manier krijgt u snel duidelijkheid over wat “in scope” is en wat “out of scope” is in een project.

• Wat gaat het project behandelen?
• Wat gaat het project expliciet niet behandelen?
• Welke problemen lost het project op?

 

Toepassingsgebied en productomgeving

Het toekomstige toepassingsgebied en de omgeving van het product moeten ook worden gespecificeerd in de specificatie van eisen. Dit omvat de doelgroep, toepassingsgebieden, bedrijfsprocessen die beïnvloed worden en de bedrijfsomstandigheden.

Functies

Zorg er ook voor dat alle functies en use cases in detail worden beschreven.

• Hoe en onder welke omstandigheden wordt de functie uitgevoerd?
• Welke invloed heeft dit op de andere bedrijfsprocessen?

Services

De services beschrijven de vereisten die u hebt voor een specifieke functie. Hieronder valt bijvoorbeeld de uitvoeringstijd of de nauwkeurigheid van een berekening. Zorg ervoor dat alle services worden vermeld.

Kwaliteitseisen

De kwaliteitseisen moeten ook worden samengevat:

• Wat zijn uw kwaliteitseisen?
• Hoe zien kwaliteitsborging, kwaliteitscontrole en kwaliteitsacceptatie eruit?

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

• Veranderlijkheid = niet relevant
• Efficiëntie = goed

Gebruikersinterface

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

Andere en speciale vereisten

Hieronder vallen bijvoorbeeld documentatie, boekhouding of beveiligingsvereisten zoals wachtwoordbeveiliging.

Technische vereisten

De technische apparatuur die nodig is voor de implementatie moet hier worden vermeld. Het is zinvol om een lijst te maken van de software- en hardwaresystemen die voor de toepassing geïnstalleerd moeten worden. Dit is onder andere belangrijk om de beschikbaarheid van de netwerkverbinding te garanderen.

• Welke apparatuur hebt u nodig voor welke taak?

Interfaces

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

Probleemanalyse

De belangrijkste problemen en misschien ook de te verwachten problemen moeten hier samengevat worden. Voor de meest waarschijnlijke problemen moet een oplossingsrichting beschikbaar zijn.

Projectontwikkeling

Hier moet zo nauwkeurig mogelijk beschreven worden welke stappen op welk moment gepland zijn en hoe het hele project georganiseerd is.

Testen en acceptatievoorwaarden

Tests controleren het product voor voltooiing op functies, eigenschappen en kwaliteitskenmerken. Na een foutloze uitvoering kan het product compleet worden verklaard.

• • Aan welke voorwaarden moet worden voldaan?

Dit is slechts één voorbeeld van hoe een specificatieblad eruit kan zien. Sommige criteria zijn essentieel, andere zijn belangrijk maar niet doorslaggevend. Weer andere zijn wenselijk, maar u kunt ook zonder. Welke eigenschappen een “must have” of “nice to have” zijn, verschilt van bedrijf tot bedrijf. Zorg er gewoon voor dat ze duidelijk als zodanig herkenbaar zijn. De afzonderlijke punten kunnen in verschillende mate van detail worden beschreven, maar vooral de technische vereisten moeten zeer gedetailleerd worden beschreven. Uiteindelijk is het belangrijk dat de eisen uit de specificaties consistent zijn met de verklaringen in de eisenspecificatie en dat er geen ruimte is voor interpretatie. De eisenspecificatie moet goed beschreven en gedocumenteerd zijn, weinig ruimte overlaten voor interpretatie, specifiek zijn en een noodzakelijke kostenraming bevatten. Als vuistregel geldt dat er geen vragen onbeantwoord mogen blijven en dat een buitenstaander moet begrijpen wat er bedoeld wordt.

U bent misschien ook geïnteresseerd in:

• Hoe herken ik als gebruiker een goed ERP-systeem?
• Het proces van een succesvolle ERP-implementatie
• Succesfactoren van een vlekkeloze ERP implementatie

Waar moet u nog meer op letten?

Vanuit het oogpunt van de klant moet u allereerst de tijd nemen om de specificaties zorgvuldig te bekijken en ze niet zomaar ongelezen door te wuiven. Concentreer u vooral op de interpretatie van uw eisen en controleer of ze volgens uw wensen zijn geïmplementeerd – eenvoudig, maar het kan u later een hoop problemen besparen. Bovendien bestaat altijd het risico dat u bij het opstellen van de vereisten en functionele specificaties de huidige situatie in het bedrijf vergeet. Dit betekent dat u de kans mist om het verbeteringspotentieel te realiseren door het nieuwe systeem te introduceren. Zie het ERP-project als een kans om uw workflows en bedrijfsprocessen kritisch onder de loep te nemen – zo kunt u het potentieel beter benutten.

Vanuit het oogpunt van de ERP-leverancier is het zinvol om wat tijd te investeren in de uitwerking, om tot in detail af te stemmen met de klant en om niets onopgelost te laten. Als er vragen onbeantwoord blijven, als u op zoek bent naar een antwoord en als er knelpunten zijn, verduidelijk dit dan onmiddellijk met de klant. Het is cruciaal om zo nauwkeurig en gedetailleerd mogelijk te zijn bij het opstellen van het rapport. Het is ook raadzaam om begrijpelijke taal te gebruiken en, indien mogelijk, het gebruik van technische termen te vermijden. Veel verschillende mensen lezen de specificaties – en niet iedereen heeft een diepgaande technische kennis. Grafische voorstellingen zijn ook een goede manier om complexe inhoud op een begrijpelijke manier over te brengen. Werk met diagrammen, tabellen of mindmaps om de wensen van de klant te visualiseren en zo begrijpelijk mogelijk te maken.

Conclusie

Het maken van een eisenspecificatie is een noodzakelijke stap om de risico’s in een ERP-project te minimaliseren. Aan de ene kant dient het om te voldoen aan de eisen die in de specificaties staan en om de implementatie zo goed mogelijk te plannen, zodat er aan het eind geen onaangename verrassingen zijn. Aan de andere kant helpt het om de geïmplementeerde oplossing aan het einde van het project te valideren en beide partijen te beschermen. Het is vooral belangrijk om het verschil te weten tussen specificaties en functionele specificaties. Juridisch gezien maakt het een groot verschil in welk van de twee documenten iets gedefinieerd is.

Als u meer wilt weten over eisen-analyses, specificaties en functionele specificaties of het hele scala aan TimeLine ERP functies, stuur ons dan een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!