Inhoudsopgave
Requirementsanalyse in het kort
Bij een requirementsanalyse gaat een bedrijf na welke wensen en eisen het heeft voor het veranderen van bedrijfsprocessen en voor de implementatie van nieuwe software . Hiervoor moeten eerst de bedrijfsprocessen en de verbeterpunten bestudeerd worden. Op basis van de huidige situatie kan er dan gekeken worden wat ontbreekt of anders moet.
ICT Portal kan helpen bij het opstellen van een requirementsanalyse. Meer informatie vind je op deze pagina.
De complexiteit van de analyse zal afhangen van het specifieke verbeterpunt, en van hoe het bedrijf dit wil aanpakken. Een voorbeeld van een verbeterpunt is als er bij een bedrijf geen plaats meer is voor de steeds groeiende papierstapel. In dit geval kan de onderneming aan een digitaliseringsslag denken, waarbij ze naar een paperless office toe werkt. Afhankelijk van het bedrijf zal dit een eenvoudig proces zijn, of zal het veel voeten in de aarde hebben. De requirementsanalyse helpt bedrijven bij het bepalen van de ideale situatie, en is de eerste stap naar het zetten van de juiste stappen. In het Digiboek Digitalisering vinden zich oriënterende projectleiders specifieke stappen om te zetten in een digitaliseringstraject.
Om tijd te besparen bij het opstellen van de wensen en eisen voor een softwarepakket, heeft ICT Portal alvast een aantal functionaliteitenoverzichten opgemaakt:
- DMS Functionaliteitenoverzicht
- QMS Functionaliteitenoverzicht
- HRM Functionaliteitenoverzicht
- CRM Functionaliteitenoverzicht
- Financieel Systeem Functionaliteitenoverzicht
- ERP Handel Functionaliteitenoverzicht
- ERP Productie Functionaliteitenoverzicht
- Digital Signage Functionaliteitenoverzicht
Waarvoor dient een requirementsanalyse?
Door een requirementsanalyse uit te voeren weet een bedrijf precies op welke punten verbetering mogelijk is. Hierdoor wordt het veel eenvoudiger om een oplossing te vinden. Bovendien ondersteunt de analyse ondernemingen in de verdere stappen van het verbetertraject.
Requirementsanalyses zijn vooral nuttig bij softwaretrajecten. Het gebeurt namelijk vaak dat projectleiders zich laten leiden door alle functionaliteiten die mogelijk zijn, en niet door wat het bedrijf precies nodig heeft. Een requirementsanalyses kan voorkomen dat een te uitgebreid pakket wordt aangeschaft.
De analyse helpt bedrijven ook met een duidelijke communicatie naar de leverancier toe, en bovendien met het budgetbeheer. Heel vaak is het voor de leverancier niet duidelijk dat er nog een aantal verborgen wensen en eisen is, zoals de aanschaf of het huren van een server . Zonder requirementsanalyses wordt dit soort zaken nogal eens vergeten te melden, waardoor de leverancier een relatief lage offerte uitbrengt. Het bedrijf is er natuurlijk helemaal blij mee, tot de server ter sprake komt, en er een flinke meerprijs moet worden berekend.
Andere wensen en eisen die vaak over het hoofd worden gezien zijn die voor de diensten na de implementatie van het systeem. Bedrijven gaan er vanuit dat ze updates zullen krijgen, en dat ze met vragen en problemen steeds bij de leverancier terecht kunnen. Dit is gedeeltelijk waar, maar de afspraken moeten wel duidelijk in een Service Level Agreement (SLA) vastgelegd worden. Hierin wordt beschreven op welke service de klant precies recht heeft, en wat de kosten voor die service zijn.
Wat zijn de verschillende stappen bij een requirementsanalyse?
Bepaal de pijn- en verbeterpunten
De eerste taak bij het maken van een requirementsanalyse is het detecteren en beschrijven van de pijn- en verbeterpunten. Hiervoor moeten de bedrijfsprocessen gedetailleerd in kaart worden gebracht. Dit kan met softwaretools zoals Blueprint , Data Flow Diagram en Business Process Modeling .
Tip! ICT Portal beschikt over een team van specialisten om de requirementsanalyse te vereenvoudigen. Zij kunnen u helpen de processen en de wensen en eisen in kaart te brengen: +31 (0)20 369 0457
Beschrijf de ideale situatie
Zodra de huidige situatie en de verbeterpunten duidelijk zijn, kan het projectteam overgaan tot het bepalen van de ideale situatie. Hierbij hoort ook de strategie om tot deze situatie te komen. Bijvoorbeeld: een bedrijf kan beslissen om een ERP-systeem in fases te implementeren omdat het niet over het budget en/of de medewerkers beschikt om alles tegelijkertijd te veranderen. Bovendien denkt men dat een gefaseerde implementatie de gebruikersadoptie ten goede zal komen. Zo kan een ERP-systeem bijvoorbeeld eerst worden geïmplementeerd bij de financiële afdeling , daarna op de productievloer en pas een jaar later voor de klantendienst en het projectbeheer .
Betrek de medewerkers
Niemand weet beter wat er op de werkvloer gebeurt als de werknemers die er dagelijks op actief zijn. Zij zijn degenen die verbeterpunten het eerste zien. Vandaar dat leidinggevenden hen vanaf het begin zouden moeten betrekken bij het maken van de requirementsanalyse. Projectleiders kunnen bijvoorbeeld gesprekken voeren met de key users van het nieuwe systeem.
Leg de prioriteiten vast
Zodra duidelijk is wat de verbeterpunten zijn, en hoe werknemers en leidinggevenden hieraan een mouw willen passen, moet er nagegegaan worden wat de prioriteiten zijn. Niet alle functionaliteiten of modules zijn namelijk even belangrijk. Een bedrijf wil niet te veel geld of tijd kwijtraken aan zaken die niet essentieel zijn, of die pas in een latere fase relevant worden. Om te bepalen wat de prioriteiten zijn, kunnen bedrijven gebruik maken van diverse methodes, onder andere de MoSCoW-methode en de Eisenhower-matrix.
Eisenhower-matrix | ||
---|---|---|
Dringend | Niet-dringend | |
Belangrijk | Voer het zelf uit (nu) | Plan het in voor later |
Niet belangrijk | Delegeer | Annuleer het of stel het uit |
Hoe flexibel moet een requirementsanalyse zijn?
Een requirementsanalyse is een dynamisch proces dat niet op voorhand helemaal vastligt. Een bedrijf dat bijvoorbeeld begint aan de analyse in maart, kan zich in mei in een (lichtelijk) andere situatie bevinden. Vooral bij langer durende projecten is er een risico dat de wensen en eisen veranderd zijn op het moment dat de software geïmplementeerd moet worden. Vandaar dat veel bedrijven kiezen voor projectmethodes zoals Agile of Scrum . Deze methodes bieden de mogelijkheid om snel bij te sturen op basis van de veranderde requirementsanalyse.
De bedrijfssituatie hoeft niet per se te veranderen voor het ontdekken van nieuwe wensen en eisen. Vaak merken bedrijven in gesprekken met leveranciers dat er toch nog andere verbeterpunten zijn, of dat ze met bepaalde functionaliteiten een behoorlijke verbeteringslag kunnen maken. Let hierbij wel op: de leverancier is natuurlijk happig op het verkopen van een groot pakket. Zorg er dus voor dat de Return On Investment (ROI) van deze nieuwe modules of functionaliteiten voldoende is.