1. Opzetten van het ERP-project

De projectopzet is de eerste, belangrijke stap van een softwareproject en vereist een uitgebreide, solide projectmanagementstrategie. In het begin is het belangrijk om de algemene voorwaarden voor het ERP-project vast te stellen. Er moet worden bepaald wie bij het project wordt betrokken en welke functie elke persoon zal vervullen.

Welke doelen worden nagestreefd?

Ook moet er een dialoog op gang komen over de doelen die met de introductie van (nieuwe) ERP-software bereikt moeten worden. Dergelijke doelen worden vaak bepaald door het managementniveau. Op dit moment is er nog geen sprake van een concrete formulering van doelen volgens het SMART-principe. Het gaat veeleer om de fundamentele verbeteringen die het ERP teweeg moet brengen. Voorbeelden van veelvoorkomende doelen van een ERP-implementatie zijn het optimaliseren van bestaande bedrijfsprocessen of het verbeteren van de beschikbaarheid van informatie in het bedrijf.

Budget en tijdsbestek

De kaderfactoren die in het begin door het projectteam moeten worden bepaald, zijn enerzijds het tijdsbestek en anderzijds het financiële kader. Het is daarom noodzakelijk om een concreet projectplan en tijdschema op te stellen. Zowel de tijd als het financiële kader is zeer individueel en hangt grotendeels samen met de grootte van het bedrijf en de complexiteit van het systeem. Hoe groter het bedrijf, hoe duurder en complexer de implementatie vaak is. Naast de externe kosten moet met name rekening worden gehouden met de interne inspanning.

2. Analyse van potentieel en behoeften

De potentieelanalyse streeft in wezen twee doelen na.

• Creëren van een basis voor het formuleren van eisen voor de ERP-software en
• Identificatie van optimalisatiemogelijkheden in bestaande bedrijfsprocessen.

Voor een succesvol selectieproces is het essentieel dat specifieke eisen voor het nieuwe ERP worden gedefinieerd, op basis waarvan; in de vorm van een specificatie; een geschikt systeem kan later worden gezocht. Het is echter net zo belangrijk om van deze gelegenheid gebruik te maken om bestaande processen in vraag te stellen en, indien nodig, passende reorganisatie- en herstructureringsmaatregelen door te voeren voordat het nieuwe systeem wordt ingevoerd.

Structurele veranderingen vóór de ERP-implementatie

Het is van belang dat bestaande processen veelal niet worden geoptimaliseerd door het louter invoeren van een (nieuw) systeem, maar dat gevestigde structuren alleen maar verder worden geconsolideerd, aangezien deze nu ook aan IT-kant in een vast raamwerk verankerd zijn. Daarom moeten processen altijd worden onderzocht als onderdeel van een potentiële analyse van een acuut ERP-project.

Maak een catalogus van vereisten

Als onderdeel van de behoefteanalyse kan ook een eisencatalogus worden gemaakt, die later in de specificatie wordt opgenomen en erdoor wordt gespecificeerd. Zoals de naam al doet vermoeden, bevat het essentiële vereisten; meestal op functioneel niveau; naar ERP-software. De twee termen "vereistencatalogus" en "specificaties" worden vaak gelijkgesteld, hoewel er een onderscheid kan worden gemaakt in termen van reikwijdte en detail.

3. Procesanalyse

De procesanalyse bouwt voort op de potentieelanalyse en specificeert hoe. Het doel is hierbij om het gevonden optimalisatiepotentieel tot in detail te volgen om veranderingen op procesniveau in de praktijk te kunnen doorvoeren. Ook buiten een acuut softwareproject moet regelmatig een procesanalyse worden uitgevoerd om ervoor te zorgen dat deze is aangepast aan marktveranderingen en veranderende wettelijke en interne bedrijfsvereisten. De analyse van bedrijfsprocessen is een omvangrijk project dat alleen kan worden gemanaged met voldoende expertise binnen een passend, proportioneel kader.

Procedure voor de daadwerkelijke analyse van processen

Als je kijkt naar processen in bestaande legacy-systemen, dan zijn die vaak opgedeeld in gefragmenteerde subprocessen. Het is moeilijk om het "grote plaatje" te zien. Zogenaamde referentiemodellen kunnen daarbij helpen. Dit zijn concrete modellen voor de presentatie van zakelijke of technische inhoud met betrekking tot structuren en processen. Een referentiemodel heeft een hoger abstractieniveau dan een vergelijkbaar, bedrijfsspecifiek model. Referentiemodellen kunnen dus gebruikt worden in vergelijking met de eigen actuele toestanden om bestaande processen te evalueren en om concrete aanbevelingen te formuleren voor acties voor het doorvoeren van optimalisaties.

4. Opstellen van de specificaties

Nadat de eigen werking en alle processen onder de loep zijn genomen, is het tijd om de specificaties te maken. Een specificatie bevat alle eisen in concrete vorm die een bedrijf heeft aan een ERP-systeem om de vooraf gedefinieerde doelen te kunnen realiseren. Om deze reden dient het ook als basis voor het verkrijgen van aanbiedingen van leveranciers.

Eisenspecificatie als basis voor besluitvorming voor de ERP-aanbieder

Bij het opstellen van de specificatie kunnen bedrijven gebruik maken van sjablonen. Het is belangrijk dat alle geïdentificeerde TARGET-processen en -functies worden vermeld. Op basis hiervan kunnen potentiële ERP-aanbieders beslissen of ze geschikt zijn als implementatiepartner voor een specifiek project.

5. De ERP-markt verkennen

Als de specificaties eenmaal zijn opgesteld, is de eerste stap het verkennen van de ERP-markt. Dit is even groot als divers. Het voordeel is dat door de sterke differentiatie voor elk nichebedrijf met zelfs de meest specifieke eisen een passend systeem te vinden is. Aan de andere kant hebben bedrijven op dit moment keuze te over. Het simpelweg verzenden van de specificaties naar de eerste 10 bedrijven die in een korte zoekopdracht van een zoekmachine verschijnen, is geen veelbelovende strategie.

Top 10 lijsten

Overeenkomstige "top 10-lijsten" moeten ook met voorzichtigheid worden behandeld. Enerzijds kunnen ze geen rekening houden met de individuele eisen van het betreffende bedrijf. Anderzijds bevatten ze vaak ook betaalde advertenties van aanbieders. Neutraliteit en objectiviteit worden dan ook in deze gevallen niet meer gegeven.

Casestudy's en referenties

Daarnaast kunnen casestudy's van aanbieders of branchespecifieke referenties informatie geven of een ERP-aanbieder geschikt zou kunnen zijn om het project in uw eigen bedrijf uit te voeren. In principe geldt het volgende: hoe meer het beschreven bedrijf op dat van u lijkt, des te toepasselijker is de succesvolle verwijzing naar uw eigen omstandigheden en des te zinvoller is de case study voor uw eigen doeleinden. Het is belangrijk dat casestudies en referenties niettemin de succesvolle projectprocessen en veranderingen beschrijven in andere bedrijven waarvan de processen verschillen van die van u, zelfs in dezelfde branche en bedrijfsgrootte. Casestudy's en referenties kunnen daarom vooral als ondersteuning worden gebruikt.

Gebruik vergelijkingswebsites

Bij het systematisch verkennen van de ERP-markt kunnen bedrijven in plaats daarvan leveranciersonafhankelijke vergelijkingswebsites gebruiken. Deze stellen beslissers in staat om de ERP-markt te filteren op specifieke functies en andere vereisten en om geschikte systemen weer te geven die voldoen aan de eerder gedefinieerde vereisten. Bedrijven kunnen ook overwegen om onafhankelijk ERP-advies in te zetten. Wat hierbij vooral van belang is, is de onafhankelijkheid van de aanbieder om objectief advies te kunnen geven.

6. ERP-presentaties van leveranciers

Geschikte systemen of providers kunnen dan worden samengesteld in de vorm van een longlist en later een shortlist. De shortlist mag slechts enkele systemen en providers bevatten, die allemaal kunnen voldoen aan de vereisten die in de specificatie zijn gedefinieerd. Op dit punt moet een gedetailleerde persoonlijke uitwisseling plaatsvinden tussen de klant en potentiële aanbieders. Potentiële providers zouden hun oplossing idealiter in realtime aan bedrijven moeten presenteren, zodat eventuele vragen direct kunnen worden beantwoord.

Proefversies

Veel ERP-aanbieders laten bedrijven ook een bepaalde tijd gratis hun software-oplossing testen. Deze periode is meestal beperkt tot twee tot vier weken, maar verschilt van aanbieder tot aanbieder. In dit tijdvenster hebben bedrijven de mogelijkheid om eerste indrukken op te doen in de praktijk. Testversies fungeren dus als hulpmiddel bij de besluitvorming.

7. Selectie van ERP-software

Uiteindelijk moet een beslissing worden genomen op basis van alle eerder verzamelde informatie. Bedrijven moeten er rekening mee houden dat ze bij het kiezen van een ERP-systeem altijd twee beslissingen nemen: een voor een systeem en, indien nodig, een onafhankelijke beslissing voor een provider. Met name grotere aanbieders van bedrijfssoftware vertrouwen doorgaans op een breed netwerk van verkooppartners.

De rol van de ERP-provider

Naast verschillen in locatie, hebben veel distributiepartners zich ook gespecialiseerd in de vereisten van specifieke industrieën of bedrijfsgroottes. De rol van de ERP-aanbieder in het selectieproces mag dan ook niet worden onderschat. Uiteindelijk vertegenwoordigt dit ook een ideale zakelijke partner voor de lange termijn, zodat interpersoonlijke factoren niet volledig mogen worden genegeerd.