1. Business Proces Modeling

ERP en Kwaliteitsmaatregelen

Business Proces Modeling

1. Business Proces Modeling 1.1. Inleiding Doel Een eerste onderdeel in ‘ERP en Kwaliteitsmaatregelen’ is ‘Business Proces Modeling’. Deze discipline is vooral van belang om de context te beschrijven waarbinnen en waartoe (met welk doel) de verandering (de implementatie van ERP software) plaatsvindt. Op de organisatie en de processen vindt een analyse plaats en worden de IST- en de SOLL-situaties beschreven.

Belang Een aantal vragen die elke opdrachtgever zichzelf moet stellen zijn:  Wilt u het laten slagen alleen van de leverancier af laten hangen?  Is al eerder een succesvolle implementatie van een ERP-pakket uitgevoerd?  Is uitvoerig naar de risico’s van een ERP implementatie gekeken en niet alleen naar de risico’s die de leverancier heeft benoemd?  Een ERP pakket is vaak het hart van een organisatie, wilt u dan risico lopen dat de implementatie mislukt?  Is het antwoord op de vraag of de business of de IT bepaalt op welke manier de implementatie verloopt, de business? Is het antwoord op 1 of meerdere van bovenstaande vragen “nee”, dan is het van belang de juiste maatregelen te nemen. Met dit document vergroot u uw kans om een succesvolle implementatie af te dwingen.

Diepgang De essentie van bedrijfsmodellering als context en gericht op besluitvorming is dat de grote lijnen en de major issues niet worden vertroebeld door details en bijzaken, zonder dat daarmee risico’s zoals onzorgvuldigheid en onvolledigheid worden geïntroduceerd. Voldoende diepgang in de modellen is bereikt zodra de rest een kwestie is van uitwerken volgens geldende principes en richtlijnen of als de irrelevantie van verder uitwerken voldoende aannemelijk is gemaakt. De modellen en de uitwerking dienen als vastlegging van bedrijfsprocessen en ontwerpkeuzes daarin en vormen de basis voor functionele specificaties en voor de inrichting van de administratieve organisatie. De beschrijving van de administratieve organisatie moet vanzelfsprekend voldoen aan de gewenste diepgang om bruikbaar te zijn voor (eind)gebruikers.

Resultaten De producten van Business Proces Modeling kunnen niet alleen de huidige (‘IST’) situatie beschrijven, maar ook de gewenste (‘SOLL’) situatie:  De scope van de modelleeractiviteit wordt afgestemd op het verandergebied, waarbij de scope voldoende ruim is gekozen om de context van het probleemgebied volledig in beeld te hebben. De scope wordt vastgelegd in termen van producten, processen en organisatie.  De dynamiek van het verandergebied wordt vastgelegd in termen van processen: bedrijfsprocessen, procedures, activiteiten en handelingen. Beschreven wordt: o de naam en inhoud van het proces; o de procesdecompositie; o de events of triggers die het proces storten; o de essentiële invoer voor het proces met de herkomst; o de essentiële uitvoer van het proces met de bestemming; o de betrokken actoren (afdelingen, teams, functionarissen, externe partijen en systemen).  De administratieve organisatie wordt gemodelleerd in termen van rollen, taken, verantwoordelijkheden en bevoegdheden. Hieraan refereren de eerdergenoemde actoren. Uitwerking van het model vindt plaats in termen van met name procedures, werkinstructies en handleidingen op basis van de procesbeschrijvingen, gerelateerd aan de (nieuw ontwikkelde) geautomatiseerde systeemfuncties.

© Infocon

Versie 0.1

Pagina 1 van 6



Input voor (vervolg)taken De IST- en de SOLL-situaties zijn input voor een GAP analyse. Door middel van een GAP analyse worden de wijzen geïdentificeerd en voorgesteld om de kloof tussen ‘IST’ en ‘SOLL’ te overbruggen. De ‘SOLL’ situatie dient als input voor het modelleren/inrichten van de ERP software door (consultants van) de ERP software leverancier. Een (of meerdere) ‘Conference Room Pilot(s)’, afgekort tot CRP(‘s), worden dan gebruikt door de eindgebruikers om de ERP software te valideren tegen de bedrijfsprocessen (‘SOLL’ situatie). Hoewel een CRP enkele kenmerken van een gebruikersacceptatie test deelt, moet het niet worden beschouwd als een testproces – het probeert te identificeren hoe goed de ERP software voldoet aan ‘business needs’ en ‘gaps’ te identificeren, terwijl de ERP software nog steeds in de ontwerp-/implementatiefase van het project zit.

Business Proces Modelling

GAP analyse

CRP(‘s)

1.2. Rollen Business Proces Analist De rol van Business Proces Analist is verantwoordelijk voor het documenteren van bestaande en/of gewenste bedrijfsprocessen. Hij staat in nauw contact met de business en kent hun doelen. Hij ontwerpt organisatieaanpassingen en vormt zich een beeld van de hiertoe benodigde ondersteuning door nieuwe of aan te passen ERP software. Tevens draagt de Business Proces Analist de verantwoordelijkheid voor het communiceren van de bedrijfsprocessen en ziet hij erop toe dat deze ook worden geïmplementeerd in de organisatie.

1.3. Samenhang begrippen Een bedrijfsproces van een organisatie wordt gekenmerkt door de rechten en plichten die de organisatie heeft om haar rol als schakel in de waardenkelen te kunnen vervullen. De afbakening van een bedrijfsproces leidt tot een bruikbaar resultaat als voldaan is aan drie voorwaarden:  Het proces valt binnen de eigen grenzen van bevoegdheid.  Het proces is te benoemen als verplichting (commitment) die twee of meer partijen op zich nemen omtrent het leveren van een gedefinieerde prestatie in de waardenketen.  Het proces kent gevallen: concrete situaties die op min of meer dezelfde wijze worden afgehandeld. Een procedure wordt afgebakend door de lifecycle van een 'stromend object' en beschrijft de samenhang (workflow) tussen de activiteiten van verschillende functionarissen. Een activiteit wordt afgebakend door hoe deze door gebruikers wordt ervaren. Dat wil zeggen: een pijl tussen twee activiteiten komt in principe overeen met het overdragen

© Infocon

Versie 0.1

Pagina 2 van 6



van werk naar een andere persoon, een ander tijdstip of een andere locatie. Een activiteit bestaat uit taken die moeten worden uitgevoerd. Een taak is een atomaire proceseenheid, de kleinste eenheid van verandering van de toestand van het bedrijf, vastgelegd in de bedrijfsgegevens. Een taak kon worden omschreven als het veranderen van de status van één of meer bedrijfsobjecten op één moment van tijd en wordt gecoördineerd uitgevoerd door een medewerker of door een automatisme in een systeem. (Op het taakniveau stelt een procesarchitect vast op welke wijze de informatie- en communicatietechnologie het inhoudelijke werk ondersteunt. De taaklaag is dan ook de laag waar de business-ICT alignment een concrete invulling krijgt.)

1.4. Aanpak en diepgang Business Proces Modeling is een iteratief proces, waarbij een eerste, algemeen model wordt opgesteld en uitgewerkt. De activiteiten van de Business Proces Analist bevinden zich met name in de Conception- en Inception-fase. In deze fasen vindt de voorbereiding van het project plaats en ligt de focus van de Business Proces Analist met name op het modelleren van de business. Hierbij worden de gewenste of noodzakelijke wijzigingen hierin vastgesteld. Op basis van de gewenste situatie ten aan zien van de business processen is het mogelijk om globaal de benodigde applicatie/ERP services te definiëren. In de Elaboration- en Construction-fase richt de Business Proces Analist zich met name o het ontwerpen en vastleggen van de administratieve organisatie van de gewijzigde of nieuwe procesgang die tijdens de Transition-fase wordt geïmplementeerd.

© Infocon

Versie 0.1

Pagina 3 van 6



2. GAP analyse Nadat de huidige en toekomstige processen van uw organisatie zorgvuldig in kaart zijn gebracht met behulp van Business Proces Modeling, is er de zogenaamde GAP analyse die beoordeelt in welke mate deze aansluiten bij het ERP pakket. De vraag is dus eigenlijk welke processen worden voldoende ondervangen door het systeem (‘fits’) en welke niet (‘gaps’)? Met deze informatie kunt u als opdrachtgever beoordelen wat het verstandigst is: de ERP software (op onderdelen) accepteren ‘as is’ of de ERP software (op onderdelen) laten aanpassen. Als u ervoor kiest aanpassingen te (laten) maken in het ERP systeem, dan weet u precies welke functionaliteiten aangepast moeten worden, en hoe, en is het ook mogelijk om een eisenkader te formuleren ten behoeve van de betreffende aanpassingen. De volgende vier, verschillende methoden kunnen worden gebruikt voor een (Fit) Gap Analyse: 1. Simulatie. 2. Brainstorming/discussie. 3. Questionnaire. 4. Een mix van de Simulatie, Brainstorm/discussie en/of Questionnaire.

2.1. GAP analyse m.b.v. Simulatie In deze methode wordt het ERP-pakket geïnstalleerd in een (gesimuleerde) ontwikkelingomgeving of in een pilotomgeving of in een sandbox testomgeving. Alle belanghebbenden komen samen om gemeenschappelijk, in de vorm van workshop, de aangeboden functionaliteiten met de reeds geïdentificeerde systeem- en ondernemingseisen te begrijpen en te vergelijken. De eisen waaraan niet wordt voldaan worden geïdentificeerd en vastgelegd. Alle mogelijke systeemwijzigingen worden geïnventariseerd. Het kan voorkomen dat systeemanalyse uitgevoerd tijdens deze fase tijdens de gedetailleerde ontwerpfase weer kunnen worden herzien om te voldoen aan de vereiste functionaliteiten. De primaire deelnemers in deze fase zijn (de kern van) het implementatieteam en de stakeholders. Conference Room Pilot (afgekort tot CRP) is een simulatie techniek om de gewenste werking van een ERP systeem te protoypen, om te leren hoe het systeem werkt of zou moeten werken, en om te beslissen hoe de business het beste er mee kan omgaan voorafgaand aan de go-live gang. De CRP techniek wordt in het volgende hoofdstuk 3, Conference Room Pilot (CRP) kort toegelicht.

2.2. GAP analyse d.m.v. brainstorming/discussie Bij deze methode wordt er gebrainstormd (besproken en vergeleken) over wat het ERP systeem kan leveren versus de bedrijfsvereisten van ERP pakket. Systeem consultants presenteren en bespreken met stakeholders tot op detail niveau de systeem functionaliteiten en mogelijkheden. De gehele brainstormsessie draait rond de onderwerpen, die ‘shortlisted’ zijn voor de discussie. Elke dag en agenda is gevuld met te bespreken onderwerpen. Systeem consultants komen met presentaties om communicatie doeltreffender te maken. Meestal presenteren systeem consultants eerst systeemfuncties en waarna discussie/afstemming volgt. Stakeholders uiten (beter) hun behoeften tegen wat wordt gepresenteerd en tijdens de discussie; notities worden vastgelegd om te komen tot de lijst van ‘fits’ en ‘gaps’.

© Infocon

Versie 0.1

Pagina 4 van 6



2.3. Questionnaire Bij deze methode wordt de fit en gap analyse voornamelijk gedreven door een eenvoudig proces waarin de input is de questionnaire of vragenlijst en de output is, de antwoorden op deze vragenlijst. Op hun beurt, worden deze antwoorden afgestemd en vergeleken met systeem functionaliteiten en features om te komen met systeem fits en gaps. De vragenlijst gebruikt voor het peilen van vereisten wordt meestal voorbereid door zeer ervaren systeem consultants en probeert de belangrijkste gebieden van de ondernemingsdomeinen te dekken. Deze vragenlijst is normaal gestructureerd rond enerzijds de behoeften van de onderneming en anderzijds de mogelijkheden van het ERP systeem. De antwoorden worden verstrekt door de goed geïnformeerde domein experts. Soms om te staven en antwoorden en vragen uit te leggen, wordt ‘live’ voorbeelden en gegevens aangeleverd als een addendum bij de antwoorden.

2.4. Hybride fit gap analyse In de hybride methode, worden alle drie de vormen van fit gap analyse methoden gebruikt. Het begint vaak met workshop-/brainstormsessies tijdens welke zowel de systeem simulaties als de vragenlijst methode worden toegepast. Eerst wordt de gedetailleerde workshop agenda opgesteld in de vorm van brainstormsessies. Systeem consultants en onderneming stakeholders zijn beiden zeer actief tijdens deze sessies. Systeem consultants presenteren met de hulp van de presentatie media systeemfuncties en geven tegelijkertijd demonstraties van de systeemfuncties en features in test- of sandbox-omgeving. Discussiepunten worden vastgelegd door de sessie leider (die is meestal een systeem consultant) om toe te kunnen wijzen aan/als systeemvereisten. Enterprise stakeholders worden gevraagd de vragenlijst in te vullen aan het einde van sessies waarmee gedetailleerde requirements worden vastgelegd. Dus, de output van elke discussie sessie en antwoorden op de vragenlijst helpt bij het bereiken van een volledige lijst van fits en gaps.

2.5. Vergelijkende evaluatie van fit gap analyse methoden Tijdens de uitvoering van de fit gap analyse, moeten de onderneming stakeholders en systeem consultants er zeker van zijn, dat de communicatie effectief en ‘naadloos’ is om alle fits en mis-fits boven tafel te kunnen krijgen. Dit is bepalend voor het succes van de verdere fasen van ontwerp en realisatie van de oplossing. De onderstaande tabel geeft de vergelijkende evaluatie van de vier hierboven genoemde methoden. Hierbij wordt een vijftal factoren gebruikt om elke methode met de andere te vergelijken. De methoden zijn gewaardeerd op laag, gemiddeld en hoog tegen elk van deze parameters. Bijvoorbeeld, de Brainstorming Fit Gap Analyse methode scoort hoog op ‘Context’, maar laag op ‘Beknoptheid’ en ‘Concreetheid’. Parameter Methode Simulatie Brainstorming Questionnaire Hybride

© Infocon

Duidelijkheid

Beknoptheid

Concreetheid

Samenhang

Context

Hoog Gemiddeld Gemiddeld Hoog

Gemiddeld Laag Hoog Gemiddeld

Gemiddeld Laag Gemiddeld Hoog

Gemiddeld Gemiddeld Hoog Hoog

Hoog Hoog Gemiddeld Hoog

Versie 0.1

Pagina 5 van 6



3. Conference Room Pilot (CRP) Conference room pilot (CRP) is een term die gebruikt wordt in bij ERP software selectie/verkrijging en bij ERP software acceptatietesten. Een CRP kan worden gebruikt tijdens de selectie en implementatie van een ERP applicatie in een organisatie of bedrijf. Het doel van de Conference room pilot is een ERP applicatie te valideren tegen de bedrijfsprocessen van de eindgebruikers van de software, door eindgebruikers de software te laten gebruiken voor het uitvoeren van typische of belangrijke business processen met behulp van de nieuwe ERP software. Een commercieel voordeel voor een Conference room pilot is dat hiermee de klant kan aanvoelen dat de nieuwe ERP software het werk kan doen (voldoen aan business requirements en verwachtingen) alvorens over te gaan tot de aanschaf van de ERP software. Hiermee kan worden vermeden dat een ‘ongepaste toepassing’ wordt gekocht.

3.1. Compared to user acceptance testing Hoewel Conference room pilot enkele kenmerken deelt met gebruikersacceptatie testen (UAT), het moet niet worden beschouwd als een testproces – het valideert het ontwerp of de oplossing geschikt is voor gebruik op een hoger niveau dan functioneel testen. Gedeelde eigenschappen van CRP en UAT zijn:   

Bij beide worden end-to-end bedrijfsprocessen gebruikt als ‘business input’. Demonstraties van functionaliteiten. Niet-functionele validatie (bijv. performance testing).

Verschillen tussen een CRP en een formele UAT:   

Het is een poging om te identificeren hoe goed de applicatie voldoet aan business behoeften, en spoort hiaten op, terwijl het project nog in de ontwerpfase zit. De verwachting is, dat wijzigingen noodzakelijk zullen zijn vóór de acceptatie van de oplossing. De ERP software is ‘op proef’ en kan volledig worden verworpen, ten gunste van een andere oplossing.

© Infocon

Versie 0.1

Pagina 6 van 6

1. Business Proces Modeling

Recommend Documents