Bij het selecteren van een softwarepakket of het inrichten van een bedrijfsproces, dat door software wordt ondersteund, komt altijd de vraag aan bod welke van de twee leidend moet zijn; het bedrijfsproces (proces) of de functie in de applicatie (functie). Dit artikel schetst een model dat helpt deze vraag te beantwoordenen signaleert welke factoren hierop van invloed zijn.

Vragenlijsten niet voldoende

In software selectie trajecten wordt veelal gewerkt met checklijsten die per onderdeel met ja of nee kunnen worden beantwoord. Een leverancier die zeer gemotiveerd is om u als klant binnen te halen zal dan zoveel mogelijk vragen uit de vragenlijst beantwoorden met ‘ja’. Dat de leverancier voor elke ‘ja’ een aantal zelf gedefinieerde uitgangspunten heeft gehanteerd en dat er in sommige gevallen een aantal randvoorwaarden geldig zijn voor die ‘ja’ is misschien iets waar u niet direct bij stilstond. Voor die delen van de applicatie die cruciale onderdelen van uw processen ondersteunen zijn enkel vragenlijsten niet voldoende. Ook bij de identificatie van deze kritische onderdelen kan ons model worden gebruikt. Afsluitend wordt ingegaan op de rol van het kostenaspect en de gevolgen van de keuze voor de implementatie.

Processen in kaart brengen

De eerste stap om de functionele behoefte te bepalen is het in kaart brengen van de processen. Dit lijkt een triviale stap, maar een goede proceskaart vergt kennis van zaken. Ten eerste dient u zich te realiseren wat u precies onder een proces verstaat. De hoofdregel daarbij is dat een proces een opeenvolging van activiteiten is die zorgt voor een toegevoegde waarde binnen het bedrijf. Het proces moet een bepaalde noodzaak onderbouwen.

Een tweede regel is dat een proces altijd een begin en een einde heeft. Ook dit lijkt een open deur, maar het vaststellen van de gebeurtenis die het proces aan het rollen brengt is belangrijk. Deze ‘events’ ontstaan in eerste instantie aan de buitengrenzen van het bedrijf (doorgaans een klantorder). Hoofdprocessen starten dus altijd op basis van een extern signaal.

Ten derde moet een proces niet worden verward met een afdeling. Een waardetoevoegend proces wordt integraal door meerdere afdelingen ondersteund.

Methoden voor het uitschrijven van processen op verschillende niveaus zijn legio. Meest gebruikelijk is om start- en eindpunt, activiteiten en beslissingen onderling in kaart te brengen.

Uniek, complex of risicovol proces?

Op basis van de in kaart gebrachte processen moet worden bepaald of er überhaupt een behoefte is om het proces door systeemfuncties te laten ondersteunen. Als dat het geval is komt de vraag aan bod hoe het proces door een ERP-systeem ondersteund moet gaan worden. Deze vraag kan worden beantwoord met behulp van onderstaand raamwerk. Op basis van drie vragen wordt vastgesteld of u beter gebruik kan maken van standaard aanwezige functionaliteit of dat u behoefte heeft aan maatwerk, ofwel; het proces volgt de functie, of de functie volgt het proces. Die drie vragen zijn gebaseerd op de volgende criteria:

• Is uw proces uniek?
• Is uw proces complex?
• Is uw proces risicovol?

Uniek proces

Wanneer is een proces uniek? Veel bedrijven en ondernemers hebben de neiging hun eigen proces uniek te noemen. Dit komt voornamelijk doordat zij hun eigen identiteit indirect aan die processen ontlenen. Dat is een begrijpelijk standpunt, maar niet altijd terecht. In onze optiek is een proces uniek als u er niet alleen uw identiteit aan ontleent, maar bovenal uw onderscheidend vermogen ten opzichte van concurrenten. Uw product of dienst is anders dan van de concurrent; daarom kloppen klanten bij u aan. Uw unieke product kan alleen maar tot stand komen doordat u op een bepaalde manier werkt. Als dat niet het geval is, dan is het voor concurrenten relatief eenvoudig u na te bootsen en is het proces niet uniek.

Verwar een uniek proces niet met een unieke resource. U kunt bijvoorbeeld beschikken over een bepaalde unieke machine, medewerker of licentie, waardoor u een significant voordeel heeft ten opzichte van concurrenten. Dat betekent echter nog niet dat u daardoor ook op een unieke manier werkt. Als bovenstaande criteria gelden voor uw proces, dan kunt u zich niet veroorloven met standaard functionaliteit te werken. Een concurrentievoordeel moet niet worden ingekaderd in een standaard werkwijze.

Complex proces

Een complex proces is waarschijnlijk eenvoudiger vast te stellen dan een uniek proces. De grens van complexiteit hangt af van het beoordelingsvermogen van u en uw ERP-leverancier. De modules die tegenwoordig worden ontwikkeld zijn steeds geavanceerder, waardoor ze op een flexibele manier kunnen worden ingericht. De complexiteit van een proces is doorgaans af te leiden uit (a) het aantal actoren en beslissingen dat bij het proces is betrokken, (b) het aantal divergente en convergente stromen in het proces en (c) de onderliggende ‘business logic’ van het proces. Met dit laatste wordt bedoeld dat er door ondersteuning van programmatuur informatie moet worden bewerkt op basis van berekeningen. Denkt u bijvoorbeeld aan planningsprocessen met veel afhankelijkheden en/of restricties of het bepalen van een verkoopprijs waarbij activity based costing moet worden ondersteund?

Het aantal uiteenlopende en samenkomende stromen binnen een proces stelt bepaalde eisen aan de softwarematige ondersteuning ervan. Vaak zijn de stappen binnen het proces van elkaar afhankelijk, moet er worden gewacht op informatie die door derden wordt aangeleverd, zijn er veel autorisaties nodig van hogere functionarissen, etc. Het is van belang voor de inrichting van de software dat deze onderlinge afhankelijkheden goed worden ingericht. Deze criteria hangen ook samen met het aantal actoren dat bij het proces is betrokken.

Ook hier bestaat een valkuil. In dit artikel gaan we nog steeds uit van de ondersteuning van het proces op basis van ERP-systeemfunctionaliteit. Er zijn natuurlijk complexe processen aan te wijzen die op geautomatiseerde wijze worden aangestuurd, maar die weinig te maken hebben met ERP-software. Denk bijvoorbeeld aan chemische processen die worden toegepast voor de vervaardiging van kunststoffen. De ‘business logic’ van deze procesondersteuning wordt ondersteund door specifieke software die doorgaans buiten de grenzen van de ERP-omgeving valt. Het komt voor dat uw proces ten onrechte complex is. Het proces moet worden geanalyseerd, eventueel met hulp van externe experts. Uit de analyse volgt of het proces vereenvoudigd kan worden. Indien vereenvoudiging mogelijk is vervalt dit criterium.

Risicovol proces

Dit criterium zorgt er niet per definitie voor dat de beschikbare functionaliteit uw proces moet volgen. Ook een eenvoudig facturatieproces brengt risico’s met zich mee, als bijvoorbeeld de prijs niet goed wordt berekend of als de betalingstermijn niet goed wordt overgenomen vanuit de klantinstellingen. Deze risico’s zijn prima af te dekken met het huidige aanbod van functionaliteit. Wij bedoelen hier een meer drastische ‘impact of failure’.  Vaak is deze verbonden aan sectoren waar de risico’s van nature hoger zijn; denk bijvoorbeeld aan het registreren van medicijngebruik van patiënten. Dit lijkt op het oog net zo eenvoudig als het bijhouden van een artikelbestand, maar een typefout kan hier fataal zijn. Bij dergelijke processen dienen meer controles te worden ingebouwd die een nauwkeurige informatieverwerking garanderen.

Toepassingsscenario

Indien er sprake is van één van bovenstaande situaties dan kunt u ervan uitgaan dat de functionaliteit van de ERP-module moet worden aangepast aan uw proces. Er zal niet snel een ERP-leverancier te vinden zijn die op basis van de bovenstaande criteria een module heeft ontwikkeld. We pretenderen niet dat er helemaal geen basis in functionaliteit voorhanden zal zijn. Het is best mogelijk dat met een bescheiden aanpassing toch een fit kan worden gevonden. Waarborg in ieder geval met uw leverancier dat er een goede beschrijving van de oplossing en een inschatting van de kosten wordt afgegeven. Zelfs op papier kleine aanpassingen kunnen binnen het hierboven geschetste model nog veel budget en tijd opslurpen.

Met behulp van een toetsingsscenario kan samen met de leverancier worden bepaald in hoeverre de ontwikkelde oplossing voldoet aan uw eisen. Volsta indien u met ‘ja’ hebt geantwoord op één van de criteria in het model niet met slechts een checklist. Deze kunt u wel toepassen indien uw proces niet uniek, complex of risicovol is.

Ontwikkeling en flexibiliteit

Als is vastgesteld welke processen met een specifieke functie ondersteund moeten worden, dan start het ontwikkelingstraject. De praktijk leert dat het afstemmen van de functionele behoefte met de leverancier een uitdaging is. Weliswaar wordt over dezelfde behoefte gesproken, maar de interpretatie van wat werkelijk nodig is, is niet eenduidig. Ook worden de wensen van eindgebruikers vergeten bij het in kaart brengen van de informatiebehoefte. De ontwerpen sluiten niet goed aan bij de belevingswereld van de eindgebruikers. Er moet niet alleen worden gezorgd voor een ontwerp voor de ontwikkeling van een specifieke functie, maar ook voor de juiste randvoorwaarden - bijvoorbeeld het betrekken van gebruikers in het traject.

Ten tweede dient u rekening te houden met de flexibiliteit van het specifiek ontwikkelde maatwerk. Uw unieke processen moeten beweegbaar blijven om uw voorsprong op concurrenten te behouden. Het gevaar dat de extra module niet modulair en variabel wordt ontworpen zorgt voor dezelfde ‘lock in’ die u zou hebben gehad als u met standaard software zou zijn gaan werken.

SOA

Eén van de laatste ontwikkelingen op het gebied van informatiemanagement is de ‘service georiënteerde architectuur’ (SOA). Binnen dit concept worden uw processen, zoveel als mogelijk, opgeknipt in diensten die als zelfstandige eenheid kunnen worden beschouwd, liefst bediend door slechts één bedrijfsfunctionaris of team van functionarissen. Dit kunnen ook ‘interne’ diensten zijn. Elke dienst wordt binnen het SOA-concept ondersteund met eigen software. Tussen alle diensten onderling wordt een communicatienetwerk opgericht, waardoor de diensten op eenvoudige wijze met elkaar kunnen communiceren. Zo ontstaat een architectuur waarbij elk onderdeel afzonderlijk en op flexibele wijze kan worden aangepast. Controleer en bespreek met de leverancier in hoeverre uw unieke processen ook op langere termijn ondersteund kunnen blijven binnen hetzelfde softwareconcept.

Proces volwassenheid

De toepassing van het beschreven model staat of valt bij het definiëren van de processen. Afgezien van de manier waarop dit gebeurt en welke criteria hierbij worden gebruikt moeten de processen bovenal vaststaan. Dit is niet voor elke onderneming het geval. Zeker als het een jong bedrijf betreft staan de processen vaak helemaal niet vast. De processen zijn nog niet volwassen. Ook bij bedrijven die reeds langer bestaan kan dit voorkomen, vooral als het activiteiten betreft die de onderneming sinds kort uitvoert. Deze bedrijven zijn vaak wel ervaren en gewend om de processen vast te stellen en te standaardiseren.

Investeren

De vraag die rijst is hoe hiermee om te gaan. Het proces leidend verklaren betekent investeren. Serieus investeren in een proces dat nog niet volledig is uitgekristalliseerd, is niet raadzaam. Een dergelijke investering kan weggegooid geld betekenen. Aan de andere kant moet ervoor worden gewaakt dat het toepassen van de applicatiefunctie de creativiteit uit het proces wegneemt. De ontwikkeling naar een uniek proces of product kan hierdoor worden belemmerd. Dit betekent dat een toekomstig concurrentievoordeel de nek wordt omgedraaid. We hoeven u niet uit te leggen dat dit een enorme gemiste kans zou betekenen. Een eenduidig antwoord is in dit geval dan ook niet te geven. Wel is duidelijk dat het hierdoor niet makkelijker wordt; de afweging moet dus zeer zorgvuldig gemaakt worden. Wellicht kan een strategie worden gevondenom de keuze over de manier van ondersteuning van dat deel van het proces uit te stellen. Dit levert tijdwinst op, en geeft het proces extra tijd om meer vorm krijgen

De kosten

Natuurlijk kan het kostenaspect niet buiten beschouwing worden gelaten. Indien de functie het proces moet volgen hangt hier een prijskaartje aan. De leverancier, system integrator of uw eigen onderneming zal aan de slag moeten om de functie specifiek te maken voor het unieke, complexe of bijzondere risicovolle proces. U doet er goed aan de kosten vooraf vast te stellen. Als de kosten inzichtelijk zijn, moet worden geëvalueerd of de functie echt het proces moet volgen. Het opstellen van een business case kan u helpen bij het maken en onderbouwen van deze beslissing. Ondanks dat een concurrentievoordeel veel waard kan zijn moeten de baten wel opwegen tegen de kosten. Om een complex proces te ondersteunen kan een applicatie helpen maar als de kosten hiervan de pan uitrijzen kan ook worden gedacht aan een specifieke applicatie om dit proces te ondersteunen. Tevens zijn maatregelen denkbaar, anders dan applicatie gerelateerd, om de complexiteit te kunnen beheersen. Dit geld ook voor high impact of failure, ook hier zijn andere maatregelen dan applicatie gerelateerde mogelijk om de risico’s te beperken. Als u na deze aspecten in overweging te hebben genomen nog steeds overtuigd bent dat de functie het proces moet volgen, lijkt de investering gerechtvaardigd.

Niet de functie, niet het proces, maar de eigen organisatie

Denkt u dus niet te eenvoudig over standaard beschikbare modules. Ze kunnen wel een goede basis vormen voor een succesvolle implementatie, maar het betekent niet automatisch dat deze standaard modules ook bij uw processen passen. Ga niet uit van de stelling dat de softwarefunctie leidend moet zijn voor al uw processen, maar beoordeel uw processen kritisch. Bepaal ook of uw processen niet te nieuw zijn en nog teveel aan verandering onderhevig voordat u een maatwerkmodule laat implementeren. Ook bij de ontwikkeling van maatwerk kan een keurslijf ontstaan. Bepaal met uw leverancier hoe, tegen acceptabele kosten, toch een flexibele oplossing kan worden gerealiseerd.

Kortom: niet het proces of de functie, maar uw eigen organisatie is leidend bij de implementatie van ERP systemen.