Bedrijf
advertisement
CONTROL & ASSURANCE Deel I.6 Information and Communication Hoofdstuk 13: Internal control rondom ERP-systemen Door: Prof. drs P.L.A.M. van Kessel RE RA INHOUDSOPGAVE 13.1 Het internal control proces en ERP informatiesystemen 3 13.2 13.2.1 13.2.2 13.2.3 13.2.4 13.2.5 Achtergronden en ontwikkelingen Supply chain management Business process redesign Informatiesystemen De West-Europese markt voor ERP informatiesystemen Implementatie 5 5 6 7 9 11 13.3 13.3.1 13.3.2 13.3.3 Internal controls in het ERP informatiesysteem Het duale karakter van internal control binnen ERP systemen De modelmatige aanpak van het ontwerp van internal control maatregelen Een praktijkvoorbeeld 13 13 16 19 13.4 13.4.1 13.4.2 13.4.3 13.4.4 Quality assurance en quality control Begrippen Quality assurance tijdens het ERP implementatieproject Quality assurance met betrekking tot het ERP informatiesysteem Quality assurance met betrekking tot het beheerproces 24 24 26 27 27 13.5 Samenvatting 27 Bijlage 1: Controlmogelijkheden van SAP R/3 30 Bijlage 2: Procesflow inkopen. 35 -- 2 13.1 Het internal control proces en ERP informatiesystemen Dat ‘Internal’ control reeds gedurende langere tijd als een proces wordt gezien, blijkt uit de vele verwijzingen die in dit verband naar de cybernetica en daarmee samenhangende voorwaartskoppelende en achterwaartskoppelende regeling worden gemaakt. Met het verschijnen van het COSO-rapport (COSO 1992) is het proceskarakter van internal control nader expliciet gemaakt en verder uitgewerkt. De elementen van het controlproces zijn: (1) control environment, (2) risk assessment, (3) control activities, (4) Information & communication en (5) monitoring. Deze procesonderdelen zijn elders in dit boek reeds uitvoering toegelicht. Implementaties van ERP informatiesystemen kennen drie belangrijke aandachtsgebieden. Twee aandachtsgebieden hebben betrekking op de omgeving van het ERP informatiesysteem; één aandachtsgebied betreft de inrichting van het ERP informatiesysteem zelf. De drie belangrijke aandachtsgebieden worden hierna kort beschreven: Het ERP implementatieproject Het ERP implementatieproject (let op: project = tijdelijk) omvat alle organisatorische, procedurele en geautomatiseerde maatregelen die worden getroffen om de activiteiten gericht op het inrichten van het ERP informatiesysteem en het gereedmaken voor dagelijks gebruik zo effectief en efficiënt mogelijk te laten verlopen. Het ERP beheerproces Het ERP beheerproces (let op: proces = doorlopend) omvat alle organisatorische, procedurele en geautomatiseerde maatregelen die worden getroffen om het ERP informatiesysteem dagelijks conform de daaraan gestelde kwaliteitseisen (in termen van capaciteit, beschikbaarheid, snelheid, kosten etc.) ter beschikking te laten zijn van de eindgebruikers. Het ERP informatiesysteem Het ERP informatiesysteem omvat alle organisatorische, procedurele en geautomatiseerde maatregelen die worden getroffen om te zorgen dat het informatiesysteem de effectiviteit en efficiency van de bedrijfsprocessen alsmede de betrouwbaarheid van de informatieverschaffing ondersteunt. Elk van de drie aandachtsgebieden dient te worden beheerst, ofwel: op elk van de drie aandachtsgebieden is het internal control proces van toepassing. In schema 1 is voor elk van de drie aandachtsgebieden weergegeven aan welke onderwerpen per fase van het internal control proces aandacht dient te worden geschonken. De tabel beperkt zich tot de belangrijkste onderwerpen. Dat zijn de onderwerpen die een directe relatie met de aandachtsgebieden hebben. Onderwerpen die buiten beschouwing zijn gelaten, zijn bijvoorbeeld ethisch handelen, personeelsbeleid, stijl van leidinggeven, ondernemingsdoelstellingen, bedrijfsbrede risico analyse. Hoewel deze onderwerpen onmisbare elementen zijn van een goede internal control liggen ze buiten de scope van dit hoofdstuk. -- 3 Internal control proces ERP implementatieproject ERP beheerproces ERP informatiesysteem Control environment Projectstructuur Taken/bevoegdheden Competenties Organisatiestructuur Taken/bevoegdheden Competenties Organisatiestructuur Taken/bevoegdheden Competenties Risk assessment Projectdoelen Project risico’s Beheerdoelen Beheerrisico’s Control activities Projectmanagement Functioneel appl. beheer Technisch appl. beheer Servicelevel management Support management Bedrijfsprocesdoelen Bedrijfsprocesrisico’s Informatiesysteemdoelen Informatiesysteemrisico’s (zie paragraaf 13.3) Geparameteriseerde controls Geprogrammeerde controls Handmatige controls Information Ontwikkeltools Projectman. Tools Beheertools Securitytools Communication Voortgangsverslagen Teamoverleg Servicelevel rapportages Afdelingsoverleg Controleverslagen Monitoring Quality assurance Quality assurance Performance meting (zie paragraaf 13.4) (zie paragraaf 13.4) Quality assurance Quality control Werking controls (zie paragraaf 13.4) (zie paragraaf 13.3) - schema 1: Internal control proces voor het ERP implementatieproject, beheerproces en informatiesysteem Bij een nadere beschouwing van de tabel valt op dat nagenoeg alle onderwerpen die genoemd zijn in de kolommen ERP implementatieproject en ERP beheersproces ook kunnen worden genoemd bij niet-ERP implementatieprojecten en beheersprocessen. Bij het ERPimplementatieproject gaat het vanuit het oogpunt van internal control om projectmanagement, planning, voortgangsbewaking; bij het ERP beheerproces om security, beheerprocessen (vaak vanuit de ITIL referentiemodellen), servicelevelmanagement en performance meting. Allemaal zaken die niet specifiek een ERP informatiesysteem betreffen, maar een veel ruimere werking hebben. De verdere behandeling van het internal control proces voor het ERP implementatieproject en het ERP beheerproces blijft daarom in dit kader buiten beschouwing. Wel wordt in paragraaf 13.4 het onderwerp quality assurance (onderdeel van monitoring) aan de orde gesteld omdat de afgelopen tien jaar in de praktijk is gebleken dat deze functie met name bij de omvangrijke en complexe ERP implementaties niet meer kan worden gemist. -- 4 In het ERP informatiesysteem zelf dient een omvangrijke hoeveelheid controls te worden opgenomen. Deze controls kunnen geparameteriseerd (de controls worden in de standaard software geactiveerd door het instellen van parameters), geprogrammeerd (de controls worden door het toevoegen van programmacode ontworpen) of handmatig zijn. De wijze waarop het ontwerp c.q. de beoordeling van deze controles kan plaatsvinden, wordt behandeld in paragraaf 13.3. Dit hoofdstuk wordt gestart met een paragraaf (13.2) waarin inzicht wordt gegeven in de wijze waarop ERP informatiesystemen tot ontwikkeling zijn gekomen, het belang van ERP informatiesystemen aan de hand van een marktanalyse en de wijze waarop ERP informatiesystemen worden geïmplementeerd. Daarmee wordt een basis gelegd voor de nadere uitwerking die in de vervolgparagrafen plaatsvindt. 13.2 Achtergronden en ontwikkelingen 13.2.1 Supply chain management In de eerste helft van de 19e eeuw is het industriële tijdperk ook in Nederland van start gegaan. Dit ging gepaard met voor die tijd nieuwe fenomenen zoals de scheiding tussen eigendom en kapitaal, de voortrazende mechanisatie, de internationalisatie en toenemende concurrentie. Productieprocessen werden als gevolg daarvan opnieuw opgezet, fabrieken anders ingericht en de focus van het management verschoof van aandacht voor de inhoud van het werk (meester-leerling model) naar aandacht voor het organiseren en besturen van de bedrijfsprocessen. Met name het inrichten en besturen van de materiaalstromen onderging een ingrijpende verandering. Het succes van de organisatie (in termen van het behouden van de concurrentievoorsprong en uiteindelijk in termen van overleven) hing voor een belangrijk deel samen met de vraag of het management in staat was om de inkomende stroom grondstoffen onder controle te krijgen, de voorraadkosten te beheersen, de productieprocessen efficiënt in te richten en de eindproducten op tijd en met de gevraagde kwaliteit bij de klanten te krijgen. In de jaren ’50 van de twintigste eeuw kreeg het oplossen van deze bedrijfseconomische vraagstukken ondersteuning vanuit de vakken productieplanning en –programmering, operations research en quality management. In die tijd wordt voor het eerst gesproken van de supply chain. De supply chain brengt in kaart op welke wijze organisaties en onderdelen van organisaties met elkaar zijn verbonden. Deze afbeelding van de werkelijkheid is nodig om zicht te krijgen op de wijze waarop grondstoffen naar het productieproces worden gebracht, de productiestromen zijn georganiseerd en de eindproducten bij de klanten komen. In schema 2 wordt een algemene weergave van een supply chain gegeven en een voorbeeld van een productieproces. -- 5 Internal Upstream Downstream 2nd 2nd Tier Tier Suppliers Suppliers The Generic Process 1st 1st Tier Tier Suppliers Suppliers 2nd 2nd Tier Tier Suppliers Suppliers Assembly/ Assembly/ Manufacturing Manufacturing and and Packaging Packaging 2nd 2nd Tier Tier Suppliers Suppliers Cereal Grain Processing Processing Facility Facility Grain Grain Producer Producer The Cereal Manufacturing Process Distribution Distribution Centers Centers Retailers Retailers Customers Customers Distributors Distributors Stores Stores Customers Customers 1st 1st Tier Tier Suppliers Suppliers Corrugated Corrugated Paper Paper Co. Co. Lumber Lumber Company Company Label Label Manufacturing Manufacturing Packaged Cereal Packaging Packaging Boxes Paperboard Labels schema 2: Componenten van de supply chain (Bron: Handfield 1999) Onderscheid wordt gemaakt tussen: Upstream supply chain – dat deel van de supply chain dat zich richt op de stroom grondstoffen en halffabrikaten tussen de leveranciers en de productieorganisatie; Internal supply chain – de processen die zich in een organisatie voltrekken en zorgdragen voor het omzetten van de grondstoffen (input) naar eindproducten (output); Downstream supply chain – dat deel van de supply chain dat zich richt op de stroom eindproducten tussen de productieorganisatie en haar klanten. De problematiek rondom de supply chain werd al gauw omvangrijker en complexer doordat het besef ging ontstaan dat het niet alleen om de grondstof- halffabrikaten- en eindproductenstromen ging, maar ook om (1) de input van geld en arbeidsuren, (2) het efficiënt en effectief uitnutten van kapitaalgoederen, (3) de organisatie van bedrijfsprocessen en de inrichting van de organisatie en (4) de met de supply chain samenhangende gegevens- en informatiestromen. Het plannen, organiseren en coördineren van alle activiteiten in de supply chain wordt tegenwoordig aangeduid als supply chain management, afgekort met SCM. Met SCM wordt getracht om de onzekerheden en risico’s in de supply chain te verminderen met het doel een positieve bijdrage te leveren aan het verminderen van de voorraadniveau’s en de doorlooptijd alsmede het verhogen van de kwaliteit van services aan klanten. Deze doelstellingen verhogen de winstgevendheid van de organisatie en versterken de concurrentiepositie. 13.2.2 Business process redesign Het supply chain management heeft met name in de afgelopen twintig jaar een enorme ontwikkeling doorgemaakt. De vraagstukken die in dit kader het hoofd zijn geboden breiden zich tot op de dag van vandaag uit. Als voorbeelden worden genoemd: het maken van keuzes tussen -- 6 kopen/maken en outsourcen/zelf doen, het aangaan van strategische allianties met leveranciers, de implementatie van een just-in-time aanpak, terugdringen van het aantal leveranciers, productie op voorraad c.q. na ontvangst van orders en de overgang van ‘mass production’ naar ‘mass customization’. Van oudsher waren de activiteiten van de organisatie ingericht rondom de bekende functies: inkoop, productie, expeditie, verkoop (functionele oriëntatie). Het oplossen van bovenstaande vraagstukken vereist echter een oriëntatie op de bedrijfsprocessen ofwel een oriëntatie op de activiteiten binnen meerdere bedrijfsfuncties (cross-functional activities). Deze fundamentele herbezinning op de inrichting van de bedrijfsprocessen leidde eind jaren tachtig tot de opkomst van business process reengineering (BPR) gevolgd door business process improvement (BPI). Bij BPR is de focus gericht op de herinrichting van de bedrijfsprocessen; bij BPI wordt ernaar gestreefd om de prestaties van de bedrijfsprocessen te verhogen. Beide begrippen worden ook wel samengevat onder de naam: business process redesign. Zowel BPR als BPI hebben rond de laatste eeuwwisseling een nieuwe impuls gekregen door de opkomst van de internettechnologie, e-business, client relation management en datawarehousing. 13.2.3 Informatiesystemen Aanvankelijk werden alle activiteiten in de supply chain handmatig uitgevoerd, werden de gegevens met betrekking tot de activiteiten op papier vastgelegd en door middel van handmatige gegevensverwerkende processen werd informatie over de activiteiten geproduceerd. Op grond van deze informatie werd de supply chain bestuurd. Door de opkomst van de computer in de jaren vijftig ontstonden mogelijkheden om te komen tot kostenbesparingen en foutenreductie. Relatief kleine onderdelen van de supply chain werden vanaf dat moment ondersteund door geautomatiseerde informatiesystemen. Voorbeelden hiervan zijn: voorraadbeheer, facturering en productieplanning. Deze informatiesystemen sloten aan bij de functionele indeling van de organisatie en werkten onafhankelijk van elkaar. Later werden deze op zich zelf staande programma’s aangeduid met de term ‘bread-and-butter’ jobs. Het werd al snel duidelijk dat er relaties bestonden tussen de verschillende informatiesystemen en dat grote efficiency voordelen konden worden behaald door deze relaties te automatiseren. Met name door de snelle ontwikkelingen in de operations research werden als eerste de relaties tussen de productieplanning, de voorraden grondstoffen en de inkooptransacties verder uitgewerkt. Omdat vele organisaties behoefte hadden aan dezelfde functionaliteiten kwamen begin zestiger jaren standaardsoftware pakketten op de markt onder de verzamelnaam material requirements planning (MRP). Hoewel de MRP informatiesystemen ertoe leidden dat voorraadniveau’s beter konden worden beheerst (lees: lager konden worden gehouden) en transactiekosten konden worden beperkt, bleek al snel dat ook softwarematige ondersteuning op het gebied van andere inputcomponenten van het productieproces (kapitaalgoederen en arbeid) tot nog meer efficiencywinsten zou kunnen leiden. De MRP pakketten werden uitgebreid tot manufacturing requirements planning pakketten, -- 7 later afgekort met MRP II. De MRP II pakketten maakte het mogelijk om de stap te zetten van aantallen naar guldens zodat ook geïntegreerde budgetten, geautomatiseerde voor- en nacalculaties en beheersing van cashflows tot de mogelijkheden gingen behoren. De daarop volgende dertig jaar heeft deze evolutie zich voortgezet door integratie van steeds meer functionaliteit. Op het moment dat de MRP II pakketten alle activiteiten binnen een organisatie ging omvatten (zie paragraaf 13.2.1: internal supply chain), werd gesproken van enterprise resources planning (ERP). Verdere ontwikkelingen op het gebied van het integreren van de bedrijfsprocessen van verschillende business units binnen grote concerns (verhouding interne leveranciers/klanten) en het ontwikkelen van ERP informatiesystemen voor organisaties waarbij het productieproces bestaat uit het verwerken van financiële transacties (banken, verzekeringsmaatschappijen, pensioenfondsen) leidden tot de extended ERP systemen. Door de integratie van customer relation management (CRM) en e-business toepassingen, spreekt met tegenwoordig ook wel over de enterprise application suite (EAS). De verwachting is dat de komende jaren de nadruk komt te liggen het optimaliseren van de positie in de bedrijfskolom. De focus verschuift naar collaborative-commerce (c-commerce). Ccommerce heeft betrekking op elektronische samenwerking tussen organisaties, businesspartners en consumenten in de handelsgemeenschap. De handelsgemeenschap kan een industrie, industriesegment, bedrijfstak of bedrijfstaksegment zijn. De nadruk komt te liggen op diepgaande industrie domeinkennis en inter-organisatie relaties (de waardeketen maakt plaats voor een waardeweb). Door Gartner wordt hiervoor ook wel de term ERP II gebruikt. Het schema 3 geeft een samenvatting van de beschreven ontwikkelingen: Inventory Inventory Production Production scheduling scheduling MRP MRP Finance, Finance, labor labor MRP MRP IIII + All All internal internal resources resources ERP ERP + Internal Internal customers customers and and suppliers suppliers Extended Extended ERP ERP Internal ERP/SCM Extended ERP/SCM 1960 Purchasing Purchasing Production management + + 1970 MRP MRP 1980 MRP MRP IIII 1990 ERP ERP 2000 Extended Extended ERP ERP + External External suppliers suppliers and and customers customers EAS EAS 2010 EAS EAS + eMarkets eMarkets and and communities communities ERP ERP IIII Major manufacturing resources Coordinated manufacturing and service transactions Collaborative commerce Time schema 3 : Evolutie van MRP tot Extended ERP (Bron: Turban 2001, gewijzigd) ERP-systemen zijn van oudsher gericht op het tot stand brengen van de integratie binnen bedrijfsprocessen (en daarmee samenhangende gegevens) en het verlagen van de time-to-market. Daarmee worden ook strategische doelstellingen als verlaging van de kosten en het vergroten van -- 8 de flexibiliteit ondersteund. Dat ERP-systemen geen oplossing zijn voor alle kwalen, wordt treffend in kaart gebracht door schema 4. De ontwikkeling van ERP-systemen naar ERP IIsystemen leidt er wel toe dat ERP-systemen steeds meer strategische doelstellingen gaan ondersteunen. Standaarden, Outsourcing Workflowmanagement low cost producer Object Computing CASE flexibiliteit vergroten Datawarehousing Datamining integratie processen time-to-market verlagen kennis vergroten Middleware Verbeteren communicatie Intranet ERP Intranet, Datawarehousing en Groupware Platformstandaardisering schema 4: Fit tussen strategische business-doelstellingen en IT (Bron: Giarte 1997) 13.2.4 De West-Europese markt voor ERP informatiesystemen1 De West-Europese markt in 1999 De West-Europese markt voor ERP informatiesystemen, gemeten in termen van licentieopbrengsten groeide in 1999 met 8,5% tot 4,6 miljard dollar. Daarmee samenhangende omzetten uit hoofde van BPR/BPI, opleiding en training, ontwikkelen van maatwerk, ondersteuning bij de implementatie en vergoedingen aan application service providers zijn daar een veelvoud van. Het belangrijkste onderdeel van de genoemde licentie-opbrengsten wordt gevormd door de financiële software (accounting, ruim 47% ofwel 2,2 miljard dollar), gevolgd door software voor materials management (24%) en HRM software (Human resource management, ruim 14%). Engeland, Duitsland en Frankrijk zijn de grootste afnemers van ERP informatiesystemen. Tezamen nemen zij bijna 54% van de markt voor hun rekening. Nederland, het land waarin 8% van de licentie-opbrengsten wordt gerealiseerd, volgt op de vierde plaats. Daarna volgen de landen Italië, Zwitserland en België/Luxemburg. Alle genoemde landen tezamen vormen ongeveer 80% van de West-Europese markt. 1 Deze paragraaf is voor een belangrijk deel ontleend aan onderzoek van IDC -- 9 Het zal geen verbazing wekken dat in 1999 SAP AG de grootste aanbieder was van ERP informatiesystemen. Met een omzet van bijna 1,1 miljard dollar was het marktaandeel van SAP AG ruim 23%. De Nederlandse aanbieders Exact Holding BV (marktaandeel van 2,3%) en Baan Company (marktaandeel 1,9%) stonden op de vijfde respectievelijk achtste plaats. Bijna 75% van de ERP informatiesystemen worden geleverd op een Unix of Windows infrastructuur. Mainframe omgevingen en OS/400 systemen vormen tezamen 18% van de totale markt. De West-Europese markt in 2000-2004 Gemiddeld wordt in de jaren 2000-2004 een jaarlijkse groei van 12% verwacht, hetgeen tot bijna een verdubbeling van de totale markt (8,1 miljard dollar) zal leiden. De groei wordt ondersteund door de volgende ontwikkelingen: Toenemende internationalisering: waardoor de vraag naar multi-currency functionaliteit en electronic banking toeneemt; Leveranciers zullen hun software verbeteren door meer branche-specifieke pakketten te ontwikkelen (een ontwikkeling die zich in de afgelopen jaren reeds heel duidelijk aftekent in de financiële sector (verzekeringen en banken); De implementatie methoden worden verbeterd, waardoor het mogelijk is met resultaat verplichting (fixed-fee, fixed-time en fixed functionality/quality) de middle market te veroveren (met name aanbieders als SAP, Oracle en SAGE laten de afgelopen jaren verhoogde activiteit in deze markten zien); Toenemende vraag naar management informatie leidt tot datawarehouses en software om de enorme hoeveelheden transactiegegevens te ontsluiten. Factoren die de groei zowel kunnen temperen als verder kunnen opvoeren zijn application service providing2 en e-commerce. De ontwikkeling in de markt wordt nader weergegeven in schema 5: Markets 1999 2000 2001 2002 2003 2004 1999 share 1999-2004 2004 share CAGR Accounting HRM & Payroll 2 2,187 2,638 2,920 3,305 3,689 4,071 47.4% 13.2% 50.0% 663 702 731 748 760 780 14.3% 3.3% 9.6% Dat door application service providing de marktgroei kan worden getemperd en tegelijkertijd kan worden opgevoerd, is niet eenvoudig uit te leggen. Kort samengevat is de kern hiervan als volgt. Temperen zal plaatsvinden indien de som van door organisaties aan application service providers betaalde vergoedingen (welk vergoedingen, na aftrek van de kosten en winstopslag van de application service provider, in de vorm van licentie-vergoedingen worden doorbetaald aan de softwarehuizen) lager zijn dan de som van de licentievergoedingen die door deze organisaties zouden zijn betaald indien rechtstreeks met de softwarehuizen zaken zouden zijn gedaan. Verder groei van de markt ontstaat indien bovenstaande ‘application service provider consructie’ met name wordt toegepast bij die (kleinere) organisaties die juist door de met deze constructie samenhangende lagere kosten kunnen overstappen op een ERP-systeem, hetgeen niet mogelijk zou zijn geweest indien rechtstreeks met de softwarehuizen zaken zouden zijn gedaan. -- 10 Materials Management 1,109 1,343 1,600 1,827 2,049 2,276 Total 4,618 5,443 6,095 6,804 7,495 8,147 24.0% 15.5% 27.9% 12.0% schema 5: Licentie-opbrengsten in West-Europa 1999-2004 (Bron: IDC) Naar verwachting zal de bijdrage van Engeland, Duitsland en Frankrijk in het totaal van de licentie-opbrengsten toenemen tot 56%. Alhoewel Nederland naar verwachting zal dalen naar 6%, blijft Nederland op de vierde plaats staan3. De Unix en de 16-bits Windows infrastructuren zullen terrein prijsgeven aan de 32-bits Windows infrastructuren. Laatst genoemde infrastructuur zal meer dan 57% van de ERP-implementaties voor haar rekening gaan nemen. 13.2.5 Implementatie Fundamentele keuze In paragraaf 13.2.2 zijn de begrippen business process reengineering en business process improvement reeds aan de orde geweest. Bij de implementatie van een ERP informatiesysteem dient in dit kader een belangrijke afweging te worden gemaakt. Bepaald dient te worden of (1) het standaardpakket leidend is en de bedrijfsprocessen zodanig moeten worden herzien dat ze aansluiten bij het standaardpakket of (2) dat de (her-)ontworpen c.q. geïnnoveerde bedrijfsprocessen leidend zijn en het standaardpakket zodanig moet worden ingericht en moet worden voorzien van maatwerksoftware dat deze aansluit bij de bedrijfsprocessen (conform het oude adagium: ‘organiseer eerst, automatiseer daarna’). Aan de hand van schema 2 wordt dit verder uitgewerkt. Project Segment Types 1. 2. 3. 4. U.S. Europe 1. 2. 3. 4. • Package Leads • Package Leads • Reengineering Leads • Slam-It-In • Client Still Wants Reengineering Benefits but Doesn’t Want to Take More Time • Strong Inclination Towards Package • Make Process Changes Necessary to Slam-It-In • Enablers and Fences • Reengineering is the Driving Process • Reengineering Not Limited to Package schema 6: Implementatievarianten 3 Let op: de licentie-opbrensten in Nederland stijgen nog wel. De stijging in Engeland, Duitsland en Frankrijk (met name door de ontwikkelingen in de Oost-Duitse markt) is echter groter, waardoor Nederland relatief gezien wat terugvalt. -- 11 Indien het standaardpakket leidend is, zullen de bedrijfsprocessen (en vaak ook de organisatorische opzet van de organisatie) zoveel mogelijk worden aangepast aan wijze waarop het standaardpakket de transacties behandeld (segment type 1). Het gevolg van deze keuze is dat (1) slechts beperkt aan het standaardpakket behoeft te worden gesleuteld en (2) het implementatieproject een relatief korte doorlooptijd kent. Indien de (her-)ontworpen c.q. geïnnoveerde bedrijfsprocessen leidend zijn (segment type 4), zal het implementatieproject relatief lang lopen. Niet alleen moet eerst een herinrichting van de bedrijfsprocessen plaatsvinden (BPR of BPI), maar ook zal de parameterisering van het pakket aanzienlijk complexer komen te liggen en zal relatief veel maatwerk nodig zijn (customizing). De andere kant van de medaille is dat bij een succesvolle implementatie kan worden gerekend op een efficiënter en effectiever bedrijfsvoering (meer toegevoegde waarde). In de praktijk ligt het karakter van de implementaties veelal tussen beide uiterste in (segment type 2 of 3). Een en ander is afhankelijk van de verbeterkansen en -ruimte ten opzichte van de huidige situatie, veranderingsbereidheid bij medewerkers, beschikbare doorlooptijd voor het project en mogelijkheden van het gekozen ERP-pakket. De grafiek laat zien dat in de Verenigde Staten het merendeel van de implementaties kan worden geplaatst in de segmenten 2 en 3 terwijl in Europa de meerderheid van de implementaties plaatsvinden in de segmenten 1 en 2. Aanpak De aanpak van de ontwikkeling van informatiesystemen (maatwerk), de implementatie van pakketten (standaard) of een combinatie van beiden (zoals veel ERP-implementaties) is reeds vele decennia onderwerp van discussie. En niet voor niets! Reeds in 1982 publiceerde Oonincx (Oonincx 1982) een boekje met de suggestieve titel: ‘Waarom falen informatiesystemen nog steeds?’ Ook recent onderzoek naar trends in ICT (Ernst &Young 2001) bracht aan het licht dat meer dan de helft van het Nederlandse bedrijfsleven van mening is dat (eveneens) meer dan de helft van hun ICT-projecten niet heeft gebracht wat werd verwacht. Een gestructureerde aanpak, die de kans op succes verhoogt, is dus van groot belang Gezien het marktleiderschap van SAP springt bij ERP-implementaties de door deze organisatie ontwikkelde aanpak het meest in het oog. Deze aanpak, bekend onder de naam ASAP, kent (kort samengevat) de volgende onderdelen: Fasering De fasering, binnen ASAP ‘roadmap’ genoemd, bestaat uit: - Project preparation phase, bestaande uit het bepalen van de projectdoelstellingen, de scope en de implementatiestrategie (zie ook paragraaf 13.2.5, onder ‘fundamentele keuze’). Voorts wordt de projectorganisatie opgezet bestaande uit projectgroepen, werkgroepen, vastleggen van taken en bevoegdheden van projectmedewerkers en het maken van een overall projectplan; -- 12 - - - Business blueprint phase: in deze fase wordt vastgelegd op welke wijze de toekomstige gebruikers het ERP-informatiesysteem willen inzetten. Gezien de vele (parameteriseerbare) mogelijkheden van een ERP-informatiesysteem is dit geen sinecure; Onderdeel van deze fase is het uitvoeren van een Gap-analyse: deze analyse heeft tot doel om vast te stellen welke eisen en wensen van gebruikers met het ERP-standaardpakket kunnen worden gerealiseerd en welke eisen en wensen door middel van maatwerk dienen te worden gerealiseerd. De hieruit resulterende business blueprint is dus te zien als het functioneel ontwerp; Realisation phase: in deze fase wordt het ERP-standaardpakket geparameteriseerd, het maatwerk gebouwd en aansluiting met de legacy-systemen gerealiseerd (interfaces); Final preparation phase: deze fase omvat een groot aantal activiteiten die als de laatste voorbereiding voor de ingebruikname kunnen worden gezien zoals: de integratietest, de conversie, de afronding van de opleidingen en het inregelen van het systeembeheer; Go live support phase: in deze fase wordt het ERP-informatiesysteem overgedragen aan de reguliere organisatie. De projectorganisatie blijft vaak nog enige tijd bestaan voor de afhandeling van openstaande punten en ondersteuning aan de gebruikers in de eerste weken van de live-fase. Work Breakdown Structure (WBS) Elk van de besproken fasen wordt verder ingedeeld in work packages, activities en tasks; een werkwijze die bij vele systeemontwikkelmethoden wordt toegepast (zie bijvoorbeeld de in Nederland bekende SDM II-methode). Op het laagste niveau (tasks) is aangegeven wat de input voor de task is, wat moet worden gedaan, welke hulpmiddelen (accelerators, zie hierna) beschikbaar zijn en welke output moet worden opgeleverd. Accelerators Accelerators zijn hulpmiddelen die bij de uitvoering van tasks kunnen worden gebruikt. De accelerators maken ‘het leven gemakkelijker’ of letterlijk: versnellen de implementatie. Als voorbeelden worden genoemd: templates (bijvoorbeeld voor de projectplanning), databases (bijvoorbeeld: vragenlijsten voor het inventariseren van functionaliteit) en testhulpmiddelen. Hoewel deze aanpak de implementatie van een ERP-informatiesysteem optimaal ondersteunt blijven zogenaamde ‘industry knowledge’ (kennis van de organisatie en bedrijfsprocessen) en implementatie-ervaring de belangrijkste kritieke succesfactoren. 13.3 Internal controls in het ERP informatiesysteem 13.3.1 Het duale karakter van internal control binnen ERP systemen In haar rapport (COSO 1992) beschrijft het Committee of Sponsoring Organizations of the Treadway Commission internal control als ‘a process, effected by an entity’s Board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in the following categories: (1) effectiveness and efficiency of opera- -- 13 tions, (2) reliability of financial information and (3) compliance with applicable laws and regulations’4. Gelinas (1999, blz. 7-24) zegt het iets bondiger door internal control als volgt te omschrijven: ‘a system of integrated elements – people, structure, processes and procedures – acting together to provide reasonable assurance that an organization achieves both its operations system and its information system goals’. Deze werkdefinitie wordt in dit hoofdstuk als volgt gelezen: onder de doelstellingen van het ‘operations system’ vallen (1) effectiveness and efficiency of operations, (2) compliance with applicable laws and regulations and internal policies en (3) safeguarding of assets against unauthorized acquisition, use or disposition; onder de doelstelling van het informatiesysteem valt de reliability of financial and non-financial information (internal and external). In paragraaf 13.2 is uiteengezet dat de ERP-systemen aanvankelijk (MRP-tijdperk) tot doel hadden om de diverse activiteiten in bedrijfsprocessen te ondersteunen. Daarmee leverden ERPsystemen een bijdrage aan de efficiency en effectiviteit van die processen. Door de grote hoeveelheid transactiegegevens die werden vastgelegd, werden ERP-systemen al snel tevens gebruikt voor het verwerken van gegevens en het verstrekken van informatie. Deze ontwikkeling is in feite reeds vanaf het MRP II tijdperk ingezet. Heden ten dage is het ‘operations system’ zodanig verweven met het ‘information system’ dat het in het geheel niet meer mogelijk om binnen ERP-systemen onderscheid te maken tussen de onderdelen van het systeem waarmee de bedrijfsprocessen worden ondersteund en de onderdelen van het systeem waarmee bestuurlijke informatie wordt gegenereerd. Een ERP-systeem en de internal control maatregelen daarin hebben daarmee een duaal karakter. 4 Later is daaraan toegevoegd: ‘safeguarding of assets against unauthorized acquisition, use or disposition’ -- 14 Geen overlap/integratie Gedeeltelijke overlap/integratie (a) (b) BP GP (c) BP GP 2 MP 1 2 MP BP = Bedrijfsprocessen GP = Gegevensverwerkende processen MP = Management processen GP BP 3 1 Nagenoeg geheel overlap/integratie 3 1 2 MP 1 Management control op BP 2 Management control op GP 3 Management control op BP en GP schema 7: Overlap en integratie tussen bedrijfsprocessen en gegevensverwerkende processen Het invullen van internal control (als onderdeel van de managementprocessen) binnen een ERPsysteem richt zich daarmee op zowel de efficiency en effectiviteit van de bedrijfsprocessen als op de betrouwbaarheid van de financiële en niet-financiële informatie. Internal control van het bedrijfsproces is voor een belangrijk deel ook internal control van het gegevensverwerkende proces. Omgekeerd kan worden gesteld dat maatregelen die worden getroffen om de gegevensverwerkende processen te beheersen, tevens een positieve werking hebben of kunnen hebben op de beheersing van de bedrijfsprocessen. Het is derhalve niet zo dat het beheersen van de informatieverzorging een set van maatregelen vraagt en het beheersen van bedrijfsprocessen een set van geheel andere maatregelen vraagt. Doordat gegevensverwerkende processen en bedrijfsprocessen niet van elkaar kunnen worden gescheiden, zijn ook de sets van toe te passen beheersmaatregelen niet te scheiden. Binnen de leer van de accountantscontrole is deze ontwikkeling in de afgelopen tien jaar uitdrukkelijk onderkend. Waar voorheen louter de financiële risico’s en interne controle maatregelen met betrekking tot gegevensverwerkende processen in de aanpak werden betrokken, zien we tegenwoordig dat de bedrijfsrisico’s in algemene zin en de daarmee samenhangende beheersmaatregelen een belangrijke rol spelen. Onderkend wordt derhalve dat de inrichting van internal control in brede zin een positieve uitwerking heeft op de kwaliteit van de informatievoorziening. -- 15 De duale werking van internal control wordt in de volgende paragraaf nader uitgewerkt. 13.3.2 De modelmatige aanpak van het ontwerp van internal control maatregelen Om zowel de doelstellingen van het operationele systeem als van het informatiesysteem te bereiken, wordt een intern control framework gehanteerd, dat is omgenomen in schema 8: Bedriijfsprocessen Informatiesystemen Proces flowchart Stap 2 Stap 1 Stel structuur, processen en controles vast. Stap 1 Documenteer vastgestelde situatie Stel structuur, processen en controles vast. Stap 3 Analyseer de de systeem proces flowchart Stap 4 Controle matrix Stel aanpassingen voor Stap 4 Stel aanpassingen voor Stap 0 Stel doelen, Bepaal risico’s Managementsystemen schema 8: Internal controlmodel (Bron: Gelinas 1999) In schema 8 worden twee elementen van internal control proces weergegeven namelijk de risk assessment (risico-beoordeling) en de control activities (internal control activiteiten). Zie ook schema 1 voor de positionering van deze elementen in het geheel. Risk assessment De risk assessment komt in schema 8 tot uitdrukking in ‘stel doelen, bepaal risico’s’ (stap 0). Het gewenste informatiesysteem wordt weergegeven in termen van te bereiken (control-) doelstellingen en in termen van risico’s die het bereiken van deze doelstellingen kunnen verhinderen. De te bereiken doelstellingen zijn in paragraaf 13.3.1 aan de orde geweest; de risico’s dienen afhankelijk van de situatie te worden uitgewerkt. Control activities De control activities komen tot uitdrukking in de overige blokken van schema 8 en bestaan uit: -- 16 (Bij een ERP-systeem waarvan de implementatie onderhanden is): (1) identificeer de controlmogelijkheden van het ERP-systeem; (2) documenteer de wijze waarop de controlmogelijkheden zullen worden gebruikt; (3) stel vast dat de risico’s in voldoende mate worden afgedekt en doelstellingen worden bereikt; (4) stel zonodig de mix van controlmaatregelen bij. (Bij een reeds geïmplementeerd ERP-systeem): (1) het waarnemen van de getroffen controls binnen het ERP-systeem; (2) het documenteren van de getroffen controls; (3) stel vast dat de risico’s in voldoende mate worden afgedekt en doelstellingen worden bereikt; (4) stel zonodig de mix van controlmaatregelen bij. Doordat operationele processen en informatieverzorgende processen van een organisatie niet meer los van elkaar worden gezien (zij zijn geheel of gedeeltelijk in elkaar gevlochten, zie het in elkaar grijpen van de cirkels), is het met name bij de stappen (2) en (3) niet meer mogelijk om onderscheid te maken tussen het operationele proces en het informatieverzorgende proces. Het documenteren van de structuur, processen en controlmaatregelen alsmede het evalueren van de mate waarin de controldoelstellingen worden bereikt, is een geïntegreerde activiteit. Als onderdeel van de analyse, welke in stap (3) wordt uitgevoerd, worden de controldoelstellingen op systematische wijze afgezet tegen de controlmaatregelen. Dit kan bijvoorbeeld plaatsvinden in de vorm van een matrix (zie schema 9). In de kolomhoofden zijn de in paragraaf 13.3.1 beschreven doelstellingen van internal control te vinden voor zowel de bedrijfsprocessen (operations system) als de informatieverzorging (information system). Per doelstelling dienen risico’s te worden geformuleerd (zie de letters A t/m I). Deze zijn situatie afhankelijk en in dit kader niet verder uitgewerkt. Om een en ander te concretiseren zijn aan de linkerzijde van de matrix in hoofdlijnen de controlmogelijkheden van een specifiek ERP-systeem weergegeven (SAP R/3). In de matrix zijn de controlmaatregelen kort genoemd; in bijlage (1) wordt op elke controlmaatregel een toelichting gegeven. In de cellen van de matrix is nu aan te geven welke controlmaatregelen dienen te worden getroffen (in de situatie dat de organisatie bezig is het ERP-systeem te implementeren) dan wel welke controlmaatregelen zijn getroffen (in de situatie dat na de implementatie van het ERP-systeem dient te worden vastgesteld of de mix van controlmaatregelen nog in voldoende mate aansluit bij de doelstellingen en de risico’s). Controldoelstellingen voor operationele processen -- Controldoelstellingen voor infoverzorging 17 Effectiviteit Efficiency Veiligstellen Betrouwbaarheid invoer van waarden Controlmaatregelen A B Nummerreeksen D H I Tolerantieniveaus Boekingssystematiek Centrale koerstabel Berekeningspad belastingen Verwerken batchinput Logging mutaties Logging error messages Controlerapportages Referenties G Check-tabellen Verwerken EDI berichten F Vasthouden invoergegevens Blokkeren documenten E Automatische boekingen Standaardwaarden mastergegevens Boekingssleutels Controlerekeningen C 5 Gebruik transactiedocumenten Betrouwbaarheid schema 9:Confrontatie controldoelstellingen/risico's met controlmaatregelen Op grond van de matrix kunnen we de controlmaatregelen in drie groepen indelen: (1) maatregelen die louter en alleen een bijdrage leveren aan de controldoelstellingen op het gebied van informatieverzorging; (2) maatregelen die gelijktijdig een bijdrage leveren aan de controldoelstelling op het gebied van informatieverzorging en operationele processen; (3) maatregelen die louter en alleen een bijdrage leveren aan de controldoelstellingen op het gebied van operationele processen. Bij de keuze van de te treffen maatregelen wordt de voorkeur gegeven aan de maatregelen die het meeste bijdragen aan de realisatie van een controldoelstelling (gekozen wordt derhalve voor de meest effectieve controlmaatregelen) en aan de maatregelen die bijdragen aan meerdere controldoelstellingen (gekozen wordt derhalve voor de meest efficiënte controlmaatregelen). 5 Aangezien het invullen van risico’s situatie afhankelijk is (concreet benoemen van de letters A t/m I) zijn de -tekens slechts geplaatst ter illustratie van de werkwijze. -- 18 13.3.3 Een praktijkvoorbeeld De modelmatige presentatie in paragraaf 13.3.2 doet vermoeden dat het ontwerpen c.q. beoordelen van de controlmaatregelen in een ERP-omgeving een relatief eenvoudige en compact weer te geven aangelegenheid is. Niets is echter minder waar. Nadere bestudering van de tot nu toe beschreven uitwerking leidt tot de volgende constateringen: er is weliswaar gesproken over het documenteren van de structuur van de organisatie en processen, maar dit is niet verder uitgewerkt. In paragraaf 13.3.2 is verondersteld dat een procesflow beschikbaar is; er is aangegeven dat de hoofddoelstellingen verder kunnen worden uitgewerkt in subdoelstellingen en/of in risico’s die een belemmering kunnen vormen voor het bereiken van de doelstellingen, maar deze nadere uitwerking is gemakshalve in de matrix met letter (A t/m I) weergegeven; er is niet uitgewerkt welke controlmaatregelen handmatig moeten worden uitgevoerd (waarvoor derhalve procedures moeten worden ontwikkeld) en welke controlmaatregelen geautomatiseerd kunnen plaatsvinden (waarvoor derhalve in het ERP-informatiesysteem voorzieningen dienen te worden getroffen). Als bovenstaande punten wel worden uitgewerkt, dan wordt onmiddellijk duidelijk dat het ontwerp c.q. de beoordeling van controlmaatregelen in een ERP-omgeving een activiteit is, welke zeer nauwgezet en systematisch dient te worden uitgevoerd. Het volgende praktijkvoorbeeld illustreert dat. Een internationaal werkende onderneming wil haar inkoopproces (procurement) centraliseren en vervolgens een ERP-informatiesysteem invoeren.. In bijlage (2) is dit (voor deze onderneming nieuwe) bedrijfsproces, ontdaan van alle details, bijzondere omstandigheden en uitzonderingen weergegeven. Daarbij wordt onderscheid gemaakt tussen hetgeen fysiek is waar te nemen (wat is vast te pakken; deze zaken zijn gecodeerd met een F), hetgeen ‘administratief’ wordt gedaan (wat wordt vastgelegd en gecontroleerd; deze zaken zijn gecodeerd met een P), welke beslissingen dienen te worden genomen (welke vragen zijn te beantwoorden; weergegeven met de bekende ‘wiebertjes’), wie (c.q. welke afdeling) voert de activiteit uit, op welke wijze wordt een en ander boekhoudkundig verwerkt en aan de hand waarvan (output uit het informatiesysteem) is het fysieke en administratieve proces te volgen. Voor nadere analyse zijn elementen van deze procesflow weergegeven in de linker helft van de hierna volgende tabel. Vervolgens is het proces stap voor stap doorlopen en is bij elke processtap nagedacht over de vraag door welke oorzaken de doelstellingen uit de COSO-definitie (al dan niet verder toegespitst op het inkoopproces) mogelijk niet worden gehaald. De uitkomst van dit denkproces wordt in de vorm van issues of risico’s weergegeven. Per issue/risico’s wordt bepaald welke controlmaatregelen dienen te worden getroffen. -- 19 Bij het weergeven van de controlmaatregelen is onderscheid gemaakt tussen de maatregelen die handmatig of automatisch (PC=programmed control) dienen/kunnen worden uitgevoerd6. In dit hoofdstuk is nadrukkelijk aan de orde geweest dat ERP informatiesystemen de mogelijkheid bieden om zowel binnen een bedrijfsproces als over bedrijfsprocessen heen tot integratie te komen (eenmalige vastlegging van gegevens, gemeenschappelijke database). Op grond daarvan is de verwachting gerechtvaardigd dat steeds meer van de controlmaatregelen die voorheen handmatig plaatsvonden thans binnen het ERP informatiesysteem kunnen worden uitgevoerd. Uit de matrix kan worden opgemaakt dat inderdaad veel controlmaatregelen zijn geautomatiseerd. Daarbij worden de volgende opmerkingen gemaakt: ondanks het feit dat veel controlmaatregelen zijn geautomatiseerd, valt op dat ook nog een respectabel aantal handmatige controlmaatregelen noodzakelijk zijn. In het algemeen kan worden gesteld dat de routine-matige controlmaatregelen automatisch kunnen worden uitgevoerd (bijv. voor elke binnenkomende factuur vaststellen dat: de in rekening gebrachte prijs overeenstemt met de gemaakte (contractuele) afspraken, de in rekening gebrachten hoeveelheden overeenstemmen met de bestelde en ontvangen hoeveelheden, de factuur rekenkundig juist is en dat bij ontvangst van de goederen geen opmerkingen zijn gemaakt ten aanzien van de kwaliteit van de ontvangen goederen). Het blijft echter wel zaak dat signalen, uitzonderingen en afwijkingen die uit deze automatische uitgevoerde controls blijken, handmatig worden afgewerkt; organisaties die ERP informatiesystemen gebruiken, moeten er wel vanuit kunnen gaan dat de (eenmalig) geïmplementeerde controlmaatregelen voortdurend hun functie blijven uitvoeren. Hiervoor is het noodzakelijk dat de controlmaatregelen na implementatie niet meer (bewust of onbewust) kunnen worden gewijzigd of worden uitgezet. In dit kader zijn met name maatregelen op het gebied van de logische toegangsbeveiliging (maatregelen die ervoor zorgen dat de controlmaatregelen niet toegankelijk zijn) en software changemanagement (maatregelen die ervoor zorgen dat als er wijzigingen noodzakelijk blijven, de wijzigingen op een doordachte en geautoriseerde wijze worden aangebracht) nodig. Deze maatregelen maken deel uit van het ERP beheerproces en vallen verder buiten de scope van dit hoofdstuk (zie voor de scope afbakening paragraaf 13.1). voort dienen organisatie die ERP informatiesystemen gebruiken ervoor te zorgen dat bij de implementatie van het systeem de controlmaatregelen (eenmalig) goed worden ingesteld. Hierbij is een belangrijke taak weggelegd voor het ERP implementatieproject en de quality assurance die daarvan onderdeel uitmaakt. Quality assurance is het laatste onderwerp van dit hoofdstuk. 6 De mogelijkheden om te werken met programmed controls worden bepaald door het ERP-informatiesysteem waarmee wordt gewerkt. Tussen de ERP-informatiesystemen bestaat (soms grote) verschillen. In de tabel zijn de meest gebruikelijke en meest voorkomende programmed controls weergegeven (best practices). -- 20 Description Standard Procurement Proces Nr P1. P2. Physical Flow Process Flow Postings Reports Issues / Risks Suggested PC (best practices) Manual and reporting controls) Purchase requisitions are Open purchase - Purchase requisitions are entered and changed - Transaction Purchase requisition activated - Check report open purchase orders. created in the system. requisitions. unauthorized. - Restrict authorizations to enter and change - Purchase requisitions are not entered on time. purchase requisitions. Purchase requisitions are - Approval strategy is not followed or unauthorized - Transaction Purchase requisition activated - Check report released purchase requisi- released. release of purchase requisitions. (can be automatic routines) tions. - Restrict authorizations to release purchase requisitions. Set up approval strategy Q1. Is there an outline Outline agree- agreement? ments reports. - Outline agreements are invalid or incorrect - In case the agreement is prepared by the - Check if the outline agreements are system, authorizations should be set to the valid, correct and complete. amounts of the contracts P3. Request for quotation. - System can generate proposals (Link between goods and (potential) suppliers should be active) - Restrict authorizations to enter new suppliers P4. Input quotations. P5. Select Vendor. - Wrong vendor is selected as preferred supplier. - Restrict authorizations to select vendor - Quotation procedure: returned quotations are collected and opened on day of closing. P6. Create outline agree- - Wrong or unlawful outline agreements are entered - Restrict authorizations to create outline - Check on outline agreements. ment. in the system. agreements. - Head of purchase department can block - Outline agreements are not created on time. P7. Create Purchase Order. outline agreements if necessary. Open purchase - Unauthorized creation and change of purchase - Restrict authorizations for create and change orders. orders, purchase orders. - Purchase orders are not created on time. - Set up purchase order procedure. Most ERP - Purchase orders are not created correct. systems can match an purchase order price to a - Purchase orders are incomplete created. contract price. - Check report open purchase requisitions. - Most ERP systems can assign critical field that a buyer has to fill out. P8. Release Purchase Or- Released purchase - Unauthorized release of purchase orders. - Restrict authorization to approve purchase - Set up approval strategy on purchase ders. orders report. - Approval strategy is not followed. orders. orders. P9. F7. Purchase order monitor- Outstanding ing. purchase orders. Goods return. - Approval strategy can deliberately be undermined - Check report of released purchase (for instance several purchase orders instead of one orders (amount, quantity, person who big order for which there is no approval). released PO). - Purchase orders are to late. Goods return. - Unauthorized, incorrect goods return. - Routine to check for outstanding purchase - Check on outstanding open purchase orders orders. - Set up procedure and authorizations for Goods return. P10 Goods receipt for con- - Cost to Goods Goods receipt - No matching of goods receipt to purchase order. - 2 way matching (mostly as part of 3 way - Check on goods receipt without pur- . sumption. receipt/ invoice against PO. - Wrong goods, quantity, price, quality. activiated. Some systems do this only for chase order referenc receipt account. Goods receipt goods in warehouse. Tolerance limits set for to - Check on reported diffences and check without purchase report differences with supplier or reject goods receipt. order. - Limit authorization tolerance settings. P11 Goods receipt for stock. . - Stock to GR/IR Goods receipt - No matching of goods receipt to purchase order. - 2 way matching (mostly as part of 3 way - Check on goods receipt without pur- account (to price against PO. - Wrong goods, quantity, price, quality. activiated. Some systems do this only for chase order referenc differences). Goods receipt goods in warehouse. Tolerance limits set for to - Check on reported diffences and check without purchase report differences with supplier or reject goods receipt. order. P12 Post Invoice. . - Limit authorization tolerance settings. GR/IR to accounts List of Invoices - Invoices differ from goods receipt or purchase - 3 way match on PO, GR and IR. Tolerence - Run report to list all invoices and their payable (to price referring to an document. settings reference to a purchase order and goods differences). Purchase order - Incorrect invoices. - Limit authorization for posting invoices Limit receipt and Goods Re- - Unauthorized invoices are posted. authorization tolerance settings - Analyse the report with differences ceipt (three way match). P13 Park Invoice. List of parked - Parked invoices are not handled on time. - Check on parked invoices. invoices. P14 Block Invoice. - Contact supplier for source documents List of blocked - Invoices are not handled on time. - 3 way match on PO, GR and IR. Tolerence invoices. (difference with parked invoices is that blocked settings, lead to this transaction - Check blocked invoices. invoices are rejected and parked invoices wait for source documents) F12 P15 Approve invoices. - Risk of negative cash flow. Unblock invoices. Report unblocked invoices - Invoices are incorrect or unauthorized. - Block-unblock invoice functions activiated - Check list of unblocked invoices. PC) Limit authorizations to unblock invoices. - Check on payment, one-time vendor, amount, etc. -- 22 - Check on open payments/finished payments and cash level. P16 Payment. Accounts payable to bank. -- 23 13.4 Quality assurance en quality control 13.4.1 Begrippen Quality assurance en quality control zijn beide instrumenten die in het internal control process in de fase monitoring vallen (zie schema 1). De fasen control environment, risk assessment, control activities en information & communication zorgen er voor dat aan de gestelde kwaliteitseisen wordt voldaan; in de fase monitoring wordt bewaakt dat dit ook daadwerkelijk het geval is. Indien tijdens de monitoring afwijkingen van de gestelde kwaliteitseisen worden geconstateerd, dienen correctieve acties te worden genomen. Kwaliteit Onder kwaliteit wordt over het algemeen verstaan de mate waarin aan klantenbehoeften en verwachtingen tegemoet wordt gekomen. In feite is dit een holle definitie die in elke specifieke situatie dient te worden geconcretiseerd. De kwaliteit van een ERP informatiesysteem wordt bepaald door de mate waarin dit systeem bijdraagt aan het realiseren van doelstellingen die zijn gesteld aan de bedrijfsprocessen en aan doelstellingen die zijn gesteld aan de informatievoorziening (zie hiervoor paragraaf 13.3). Als voorbeelden van doelstellingen kunnen worden genoemd: Kwaliteitsdoelstellingen gericht op de bedrijfsprocessen: binnen x-tijd na implementatie een zodanige verbetering van het voorraadbeheer dat jaarlijks euro x,-- per vestiging kan worden bespaard op voorraadkosten; binnen x-tijd na implementatie verminderen van foutieve leveringen met x-%; binnen x-tijd na implementatie het binden van klanten (verhogen herhalingsaankopen met xprocent) door gebruik te maken van EDI of internetfaciliteiten. Kwaliteitsdoelstellingen gericht op het informatiesysteem: stuurinformatie dient online, up-to-date en betrouwbaar beschikbaar te zijn voor alle kritische prestatie-indicatoren; de onderhoudskosten van het ERP informatiesysteem dienen met x-procent te worden verlaagd ten opzichte van de huidige onderhoudskosten de responstijd voor eindgebruikers dient x-seconden te zijn, de beschikbaarheid dient x-% te zijn en het systeem mag niet langer dan x-uur niet beschikbaar zijn; het aantal klachten van gebruikers over het ERP informatiesysteem dient met x-procent te worden verlaagd, waarbij kritische klachten binnen x-werkdagen dienen te worden opgelost. Of het ERP informatiesysteem aan al deze kwaliteitsdoelstellingen in voldoende mate voldoet is afhankelijk van het ERP informatiesysteem zelf in combinatie met het ERP beheerproces. Verder kan worden gesteld dat de kwaliteit van het ERP informatiesysteem voor een belangrijk deel afhankelijk is van de kwaliteit van het ERP implementatieproces. De kwaliteitsdoelstellingen die in het kader van het ERP implementatieproces worden gesteld hebben vaak het karakter van tijd en geld. -- 24 Quality assurance De quality assurance functie heeft tot taak om vast te stellen in welke mate de kwaliteitsdoelstellingen worden gehaald. De quality assurance functie heeft daarmee niet alleen een formele taak (vaststellen of aan alle richtlijnen, eisen en procedures is voldaan; vergelijk het afwerken van checklisten), maar tevens een materiële taak (vaststellen of kwaliteitsdoelstellingen zijn gehaald). Indien afwijkingen van de gewenste kwaliteit worden geconstateerd, dienen door de quality assurance functie correctieve maatregelen te worden aanbevolen. Voorwaarden voor een goede quality assurance functie zijn: vastgelegde en meetbare kwaliteitsdoelstellingen, continue betrokkenheid bij het implementatieproces c.q. beheerproces (zie ook hierna), onafhankelijke positie ten opzichte van de projectleider (implementatieproject), de ICT-managers (beheerproces) en de ERP informatiesysteem eigenaar en toegang tot alle relevant geachte informatie. Quality control De quality control functie heeft tot taak om vast te stellen in welke mate aan formele voorschriften, procedures, producteisen, methodieken e.d. is voldaan. De quality control functie heeft derhalve een formele taak (checklisten toepassen) zonder zich te bekommeren over de vraag of door het voldoen aan de checklisten de achterliggende kwaliteitsdoelstellingen daadwerkelijk worden gehaald. Quality control is veelal een onderdeel van de projectorganisatie. Het is de monitoringfunctie ten behoeve van: de projectleider (ERP implementatieproject) om bijvoorbeeld vast te stellen of de implementatie geheel volgens de implementatiemethode wordt uitgevoerd, of alle regels en voorschriften op het gebied van projectmanagement worden toegepast en of opgeleverde documenten aan alle voorschriften voldoen; de ICT-managers (ERP beheerproces) om bijvoorbeeld vast te stellen of de security voorschriften worden gevolgd, of de change management procedures juist en volledig worden toegepast en of de helpdesk alle vereiste gegevens van incidenten vastlegt; de ERP informatiesysteemeigenaar om bijvoorbeeld vast te stellen of alle procedures met betrekking tot het verwerken van facturen worden toegepast, of signaallijsten worden afgewerkt en of de afloop van tussenrekeningen wordt bewaakt. Quality control kan naast quality assurance voorkomen, waarbij quality control dan kan worden gezien als voorwerk voor quality assurance (vergelijk de verhouding tussen een interne controle afdeling en de interne accountantsdienst bij een bancaire instelling). Gezien de bredere scope van de quality assurance functie worden de volgende subparagrafen hiertoe beperkt. Tijdstip Quality assurance en quality control kunnen het beste vanaf de start van het implementatieproces worden ingezet. Zoals in schema 10 wordt weergegeven zijn fouten bij het opzetten van de projectinfrastructuur tegen relatief lage kosten te herstellen. Worden de fouten niet hersteld, dan -- 25 zal dat gevolgen hebben voor het implementatieproject en uiteindelijk voor de eindproducten. Het aanpassen van eindproducten vergt relatief hoge herstelkosten. Hoog Beoordelingsobject ProjectHerstelkosten infrastructuur Project Produkt eind produkt tussen produkt Tijd schema 10: Herstelkostencurve 13.4.2 Quality assurance tijdens het ERP implementatieproject De praktijk van de afgelopen decennia laat zien dat: ERP implementatieprojecten vaak duurder waren en langer duurden dan gepland, waarbij het eindproduct ook nog vaak niet voldeed aan de klantenverwachting; het projectmanagement beperkte ervaring met of tijd had voor deze projecten, waardoor behoefte aan objectieve en onafhankelijke informatie ontstond; direct succes gewenst is (‘doing things right the first time’) in verband met de grote bedrijfsbelangen, investeringen en menselijke (in)spanningen bij ERP implementatieprojecten; de voor- en nadelen van strategische implementatie beslissingen zorgvuldig en tijdig moeten worden afgewogen; voortdurend gewaakt moet worden voor een ontkennings- en inslaapsyndroom dat zich kan voordoen doordat ERP implementatieprojecten relatief lang lopen, waardoor bewust of onbewust niet-gewenste situaties ingeburgerd kunnen raken. Deze risico’s van het implementatieproject hebben het belang van een quality assurancefunctie onderstreept. Tegen de achtergrond van de kwaliteitsdoelstellingen worden a-tempo de volgende aspecten beoordeeld: projectorganisatie, toepassing van de projectbeheersingsprocedures, voortgangsverslagen, contracten met externen, projectplannen/budgetten en de realisatie daarvan, toepassing van de implementatiemethode, testplannen, de toepassing van de testprocedures en de toereikendheid van de conversie- en rolloutprocedures. -- 26 13.4.3 Quality assurance met betrekking tot het ERP informatiesysteem De quality assurance functie gericht op het ERP informatiesysteem zelf, kan op twee momenten worden uitgevoerd: tijdens het ERP implementatieproject om te waarborgen dat het ERP informatiesysteem op het moment van oplevering aan de gestelde kwaliteitsdoelen voldoet; tijdens de periode dat het ERP informatiesysteem wordt gebruikt om te waarborgen dat het ERP informatiesysteem nog steeds in overeenstemming is met (mogelijk inmiddels gewijzigde) kwaliteitsdoelstellingen. Ook kan de quality assurance waarborgen dat de internal controls worden toegepast als bedoeld (werking). De quality assurance met betrekking tot het ERP informatiesysteem tijdens het ERP implementatieproject richt zich onder andere op de vraag of voldoende controls in het ERP systeem worden opgenomen (zie hiervoor paragraaf 13.3), de interfaces betrouwbaar werken, gebruikersdocumentatie juist en volledig is en voldoende handmatige procedures zijn ontwikkeld. De quality assurance met betrekking tot het ERP informatiesysteem tijdens het gebruik richt zich onder andere op de vraag of de controls nog steeds voldoen aan de kwaliteitseisen (zie hiervoor eveneens paragraaf 13.3); tussenrekeningen worden bewaakt, signaallijsten worden afgewerkt, verbanden worden gelegd en totaalafstemmingen worden gemaakt. 13.4.4 Quality assurance met betrekking tot het beheerproces Ook ten aanzien van de quality assurance functie met betrekking tot het beheerproces kan onderscheid worden gemaakt tussen activiteiten die tijdens het ERP implementatieproject worden verricht (dat wil zeggen: op het moment dat de beheeromgeving wordt ingericht) en activiteiten die worden uitgevoerd op het moment dat het ERP informatiesysteem al in gebruik is genomen. In het eerste geval richt de quality assurancefunctie zich op de inhoud van de servicelevelagreements, de inrichting van service delivery functies zoals capaciteit, beschikbaarheid en kostenbeheer, de inrichting van service support functies als helpdesk, problemmanagement, configuratiebeheer, changemanagement en software control & distributie, de inrichting van de technische infrastructuur met name op het punt van de toegangsbeveiliging en de beheerprocedures met betrekking tot netwerken en operations. In het tweede geval richt de quality assurance functie op de vraag of alle ontworpen controlvoorzieningen in voldoende mate worden toegepast. 13.5 Samenvatting In dit hoofdstuk is ingegaan op drie vragen: Wat zijn ERP informatiesystemen? -- 27 In dit kader is aandacht geschonken aan ontwikkelingen op het gebied van supply chain management en business proces redesign, aan de wijze waarop deze ontwikkelingen werden ondersteund c.q. gerealiseerd met ERP informatiesystemen, aan de West-Europese markt voor ERP informatiesystemen en aan enkele aspecten van de implementatie van dergelijke systemen. Welk karakter hebben de internal controls in ERP informatiesystemen? In dit kader is gewezen op het verschijnsel dat het steeds moeilijker wordt om fysieke en administratieve bedrijfsprocessen van elkaar te scheiden. De controlmaatregelen hebben daardoor niet alleen betrekking op de (COSO) doelstelling ‘betrouwbaarheid van de informatie’ maar ook op de (COSO) doelstelling ‘effectiviteit en efficiency van de bedrijfsprocessen’. Voorts is ingegaan op een gestructureerde wijze om de vele controls (handmatige of geautomatiseerd) op een verantwoorde wijze te ontwerpen en de effectiviteit ervan te beoordelen. Op welke wijze kan de kwaliteit van een ERP omgeving worden bewaakt? In dit kader is ingegaan op quality assurance, waarbij onderscheid is gemaakt tussen het ERP implementatieproject, het ERP beheersysteem en het ERP informatiesysteem. -- 28 LITERATUURVERWIJZINGEN Cadbury (1992), The Financial aspects of Corporate Governance, The Committee on the Financial Aspects of Corporate Governance, Gee??, London Cadbury working party (1994), Internal control and financial reporting: guidance for directors of listed companies registered in the UK, The Institute of Chartered Accountants in England and Wales, London CoCo (1995), Guidance on Control, Canadian Institute of Chartered Accountants, Toronto, Ontario (zie ook de nauwverwante stukken: preface tot ??guidance en guidance for directors) COSO (1992), Internal Control – Integrated Framework, The Committee of Sponsoring Organizations of the Treadway Commission Ernst & Young (2001), Trends in ICT 2001 in relatie tot management en organisatie, Maarssen, Gianotten (1997), M.H.E., Topmanagement en IT, Giarte Media Group Handfield (1999), R.B., en E.L. Nichols Jr., Introduction to supply chain management, Upper Saddle River, NJ: Prentice Hall IDC (2000), Enterprise resource management applications in Western Europe – 2000: forecast & analysis Oonincx (1982), J.A.M., Waarom falen informatiesystemen nog steeds?, Samson Uitgeverij, Alphen aan den Rijn-Brussel Turban (2001), E., E. McLean, J. Wetherbe, Information technology for management, John Wiley & Sons, Inc, New York -- 29 Bijlage 1 Controlmogelijkheden SAP R/3 Bijlage 1: Controlmogelijkheden van SAP R/3 In deze bijlage is een aantal belangrijke controlmogelijkheden van het ERP-systeem SAP R/3 opgenomen. De behandeling is op een relatief hoog abstractieniveau en niet-limitatief. 1 Gebruik transactiedocumenten SAP R/3 slaat alle mutaties op als transactiedocumenten. Documentensoorten zijn daarbij het basisraamwerk om inkoop-, verkoop- en financiële mutaties vast te leggen. De wijze waarop deze documentsoorten worden ingericht en toegepast, bieden controlmogelijkheden. Per documentsoort is vastgelegd welke velden verplicht zijn, welke optioneel door de gebruiker worden ingevuld en welke velden niet aan de gebruiker worden getoond. Documentsoorten kunnen ook binnen het systeem van toegangsbeveiliging worden gebruikt als selectiecriterium. Voorbeelden van standaarddocumentsoorten zijn: AB-Algemeen boekingsdocument (‘Algemeine Buchung’); DZ-Debiteurenbetaling (‘Debitoren Zahlung’); DR-Debiteurenfactuur (‘Debitoren Rechnung’); KZ-Crediteurenbetaling (‘Kreditoren Zahlung’); KR-Crediteurenfactuur (‘Kreditoren Rechnung’). 2 Nummerreeksen Elke occurrence uit de bestanden met stam- en standgegevens, als ook elk transactiedocument, krijgt in SAP een uniek sequentieel nummer. De nummerreeksen zijn vastgelegd in één tabel, waarin per nummerreeks de begin- en eindnummers worden vastgelegd. Per bedrijfscode/per documentsoort kunnen nummerreeksen worden gebruikt. Maar het is ook mogelijk om nummerreeksen over bedrijfscodes en documentsoorten heen toe te passen. Bij de bepaling van de documentnummer wordt onderscheid gemaakt tussen: • interne nummerbepaling; het systeem bepaalt automatisch het volgende sequentiële nummer en slaat dit op. Voor interne nummerreeksen wordt in de nummerreekstabel ook het laatst uitgegeven nummer bijgehouden. Wordt veelal gebruikt voor door SAP aangemaakte documenten; • externe nummerbepaling; de gebruiker geeft zelf het documentnummer in. Het systeem checkt of dit nummer valt binnen de nummerreeks van het betreffende bestand of documentsoort. Er kan een rapport worden gemaakt om de ontbrekende nummers te identificeren. 3 Boekingssleutels Boekingssleutels besturen de financiële verwerking. Boekingssleutels worden gebruikt voor alle boekingen naar het grootboek en gerelateerde (sub)administraties zoals crediteuren-, debiteuren-, activa- en voorraadadministratie. De volgende activiteiten worden aangestuurd door de boekingssleutels: bepalen of soort administratie geldig is (financieel: S, crediteuren: K, debiteuren: D, voorraad: M); check of soort administratie overeenstemt met documentsoort; bepalen of het een debet- of creditboeking betreft; eventueel bijhouden van additionele subadministraties; bepalen van layout en inhoud van invoerscherm (in samenhang met documentsoort). 4 Automatische boekingen De FI-module (TOELICHTEN)kan automatische boekingen genereren op basis van voorgedefinieerde criteria. Deze criteria verwijzen op hun beurt naar informatie in zowel financiële (FI) als logistieke (SD en MM) -- 30 Bijlage 1 Controlmogelijkheden SAP R/3 transactiegegevens. Deze optie wordt toegepast voor bijvoorbeeld de automatische berekening en boeking van BTW, kortingen, koersverschillen, betalingsverschillen et cetera. 5 Controlerekeningen Controlerekeningen zijn grootboekrekeningen die als controlerende (tussen)rekening worden gebruikt voor de subadministraties (zoals debiteuren, crediteuren en vaste activa) en als totaalrekening voor automatische boekingen. Voor deze rekeningen mag het in principe niet direct mogelijk zijn handmatige boekingen in te voeren. Per ‘occurrence’ in de subadministratie moet een rekeninggroep worden ingegeven. Elke rekeninggroep is gekoppeld aan een controlerekening in het grootboek. Door een doordacht ontwerp van de controlerekeningen kunnen ook rekening-courantadministraties en dergelijke worden gerealiseerd, omdat het mogelijk is om aan relaties die zowel debiteur als crediteur zijn, ieder een aparte rekeninggroep toe te kennen en dan zowel de debiteuren- als de crediteurengroep aan dezelfde grootboekrekening te koppelen. 6 Standaardwaarden Het systeem kan de invoervelden met standaardwaarden tonen, die uit diverse bronnen afkomstig kunnen zijn: intern werkgeheugen van het systeem (die de laatst ingevoerde waarde per veld onthoudt); systeemgegevens (bijvoorbeeld systeemdatum); informatie uit het stambestand (bijvoorbeeld betalingstermijnen, kortingspercentages); gebruikersprofiel (bijvoorbeeld naam startmenu, printervoorkeur, maar ook voorkeurinstellingen voor een groot aantal velden zoals bedrijfscode, magazijncode et cetera). Deze worden aangeduid als zogenaamde parameter id’s. De standaardwaarden kunnen (bijna) altijd worden overschreven en moeten dus worden beschouwd als invoerhulpmiddel, waardoor mede accuratessefouten kunnen worden voorkomen. 7 Vasthouden van invoergegevens Met deze optie kunnen in het interne werkgeheugen van het systeem, de invoergegevens van een vorig transactiedocument worden vastgehouden en automatisch worden overgenomen in het volgende invoerscherm. Dit voorkomt dat de gebruiker dezelfde informatie opnieuw moet invoeren en elimineert het risico van accuratessefouten. 8 Check-tabellen De ABAP/IV Dictionary bevat verschillende controles per veld, die door elk invoerscherm worden uitgevoerd: het veldformaat (lengte, numeriek, alfanumeriek, alfabetisch et cetera); verwijzing naar een check-tabel die automatisch wordt geraadpleegd bij elke ingave. Alle occurrences uit deze tabel worden geaccepteerd, dus ook de door SAP standaard uitgeleverde tabelwaarden, die bij de inrichting niet zijn geselecteerd, maar nog wel in de betreffende tabel staan. Voor elk veld met een check-tabel is op het invoerscherm een drill-down button beschikbaar waarmee de gebruiker een selectie kan maken uit de beschikbare waarden; toegestane occurrences die vastgelegd zijn in het domein van het betreffende veld in de data dictionary. 9 Tolerantieniveaus Door middel van tolerantieniveaus, worden de toegestane afwijkingen (in hoeveelheden en/of in percentages) op verwachte waarden binnen het systeem beheerst. Enkele voorbeelden: FI: inkomende betalingen, koersverschillen, afwijkingen in kortingen, et cetera; MM: afwijkingen op ontvangen volumes en/of hoeveelheden (als percentage) in relatie tot bestelde hoeveelheden; -- 31 Bijlage 1 Controlmogelijkheden SAP R/3 MM: prijsafwijkingen tussen orderprijs en gefactureerde prijs; SD: afwijkingen bij goederenafgiften in volume en/of hoeveelheden. SAP R/3 verwerkt de geconstateerde verschillen als volgt: afwijkingen binnen de norm worden automatisch geboekt; documenten met afwijkingen die de norm overschrijden, worden vastgelegd en geblokkeerd voor verdere boeking (totdat bijvoorbeeld de order is aangepast door een bevoegde functionaris). 10 Blokkeren van documenten Een document wordt geblokkeerd indien aan bepaalde controles niet wordt voldaan. Dit gebeurt automatisch door het systeem of wordt handmatig door de gebruiker ingegeven. Voorbeelden van automatische blokkering zijn een ingevoerde verkooporder die de kredietlimiet van de betreffende debiteur overschrijdt, of een inkoopfactuur die wordt geblokkeerd voor betaling omdat niet voldaan wordt aan de check van de tolerantieniveaus. 11 Boekingssystematiek De standaardcontroles die SAP uitvoert bij de verwerking van (wijzigingen in) financiële transactiedocumenten zijn: geen enkel veld in de kopregel van een transactiedocument (behalve een hulpveld voor de verwijzing naar een referentiedocument en tekstinformatie) mag worden aangepast; bepaalde velden per transactieregel mogen niet worden aangepast (zoals bedrag, rekeningnummer, boekingsjaar, belastingsbedrag); afhankelijk van welke modules verder worden gebruikt (en via de integratieschakelaars zijn geactiveerd) kunnen nog additionele velden worden geblokkeerd. Van deze standaardcontroles kan in sommige gevallen worden afgeweken door met behulp van een ‘X’ in de updateconditie van het veld aan te geven dat het veld mag worden gewijzigd. 12 Centrale koerstabel SAP kent een gecentraliseerde registratie van de vreemde valutakoersen, waardoor koersen binnen het systeem op een standaardwijze worden verwerkt en de tijdige en correcte verwerking van de koerswijzigingen, op eenvoudige wijze kan worden gerealiseerd. Er is één centrale koerstabel waarin deze koersen worden opgeslagen (met de datum vanaf welke deze koers van toepassing is). Voor elk bedrijfsnummer wordt een lokale currency gedefinieerd. Vervolgens kan de conversiekoers op vier manieren worden bepaald: door de boekingsdatum uit de kopregel van het document te gebruiken; door ook een valutadatum in de kopregel van het document vast te leggen; door de wisselkoers direct in de kopregel van het document te registreren; door het bedrag in zowel vreemde als lokale valuta rechtstreeks in elke transactieregel in te geven. In alle gevallen wordt gecheckt op de tolerantieniveaus als hiervoor behandeld. 13 Berekeningspad belastingen SAP R/3 beschikt voor de verwerking van belastingen, over een specifieke functionaliteit per land. Afhankelijk van het betreffende land worden de van toepassing zijnde belastingen berekend en verwerkt. Er zijn immers verschillende voorschriften per land ten aanzien van bijvoorbeeld BTW, invoerrechten et cetera. Voor de bepaling van belastingen kan een complex berekeningspad worden gevolgd, op basis van onder meer land, de staat, de stad, en ‘condition types’ voor de bepaling van percentages. 14 Verwerken batch input -- 32 Bijlage 1 Controlmogelijkheden SAP R/3 Mutaties die als zogenaamde batch input worden aangeleverd, ondergaan exact dezelfde invoercontroles als de online ingaven. Batches kunnen in de voorgrond of de achtergrond worden verwerkt. Bij de voorgrondverwerking kunnen door de gebruikers wijzigingen worden aangebracht. Fouten in batches in de achtergrond leiden tot een blokkering van het document c.q. de boekingsregel of worden op een verschillenrekening geboekt. Van elke batch inputsessie wordt een log vervaardigd. 15 Verwerken EDI berichten Mutaties, die als EDI bericht binnenkomen, kunnen automatisch door SAP worden verwerkt, mits het betreffende EDI bericht is ‘gemapt’ naar de betreffende SAP on line transactie. 16 Controlerapportages ‘Controlerapportages’ is een heel belangrijke functie binnen SAP R/3. Het systeem bevat veel rapportages die door middel van varianten en selectiecriteria, zeer specifiek kunnen worden gemaakt. Vanuit control-optiek zijn met name de totaalrapportages (‘Abstimmungsabaps’) en de uitzonderingsrapportages belangrijk. Het systeem bevat bijvoorbeeld een rapport om goederenafgiften die nog niet in een factuur hebben geresulteerd, af te drukken. Door organisaties worden vaak additionele ABAP-rapporten vervaardigd. Met een ABAP-query of de transactie om de inhoud van tabellen op te vragen, kunnen daarnaast snel eenvoudige opvragingen worden gedaan. Tegelijkertijd is de veelheid van ABAP-rapporten ook een potentiële bedreiging. Een aantal ABAP-programma’s dient uitsluitend om bijvoorbeeld initieel bestanden aan te maken of tabellen te vullen. Deze mogen niet per ongeluk door een gebruiker in een productief systeem opnieuw kunnen worden uitgevoerd. 17 Logging wijzigingen Wijzigingen in stam- en mutatiegegevens worden door het systeem gelogd. Vastgelegd worden datum en tijdstip van de wijziging, naam gebruiker, veldnaam en de oude en nieuwe veldinhoud. Sommige logs vinden niet automatisch plaats, maar moeten eerst door de gebruiker worden geactiveerd. Wijzigingen in de SAP besturingstabellen worden wel tijdens de dagverwerking vastgehouden, maar bij de eindedagverwerking verwijderd. De gebruiker dient dus voor de eindedagverwerking eerst het controlerapport tabelwijzigingen en/of een archiefrun naar een historisch bestand uit te voeren, voordat de eindedagverwerking wordt uitgevoerd. 18 Logging error messages Alle ‘error messages’, dus zowel de blokkeringen en waarschuwingen als de andere signaleringen, worden in een ‘error log’ opgeslagen. Het eerste scherm van het log geeft samenvattende informatie, waarna een ‘drill down’ kan worden uitgevoerd om de details op te vragen. 19 Referenties SAP R/3 biedt de mogelijkheid om bij het aanmaken van een retourorder een referentie naar onder andere de oorspronkelijke order of factuur te maken (zie ook figuur 8). Deze verwijzing kan als ‘verplicht’ of ‘optioneel’ worden ingesteld in een tabel. Bij een ‘verplichte’ verwijzing dient bij het aanmaken van een retourorder verplicht naar de oorspronkelijke order te worden verwezen. Dit heeft als gevolg dat SAP R/3 automatisch de prijs- en hoeveelheidsgegevens ophaalt die als basis hebben gediend bij de oorspronkelijke verkoop. Is de oorspronkelijke verkooporder niet bekend, dan is invoer van de retourorder niet mogelijk. Bij een ‘optionele’ verwijzing neemt SAP R/3 de verkoopprijs van het moment van ingave van de retourorder als uitgangspunt. Dit kan als risico met zich meebrengen dat klanten voor verkeerde bedragen kunnen worden gecrediteerd. -- 33 Bijlage 1 Controlmogelijkheden SAP R/3 De organisatie die SAP R/3 implementeert dient zelf te bepalen, hoe ‘flexibel’ hun SAP-systeem, vanuit interne control-oogpunt, wordt ingericht. Activering binnen SAP hangt af van de wijze zoals de betreffende organisatie met het bedrijfsproces wenst om te gaan. Vanuit edp-audit optiek bestaat meestal de voorkeur om deze verwijzing altijd als ‘verplicht’ in te stellen, aangezien preventieve geprogrammeerde controles het sterkst qua werking zijn. Echter, er zijn organisaties die uit andere businessmotieven de voorkeur geven aan de primaire registratie van de retour/klacht in het systeem, met de bijbehorende gedachte dat vervolgens nog een aantal organisatorische acties ondernomen dient te worden, voordat acceptatie van de retourorder plaatsvindt. Referentie verplicht gesteld? Neen Verkooporder bekend? Ja Verkooporder bekend? Ja Ja Neen Geen invoer retourorder mogelijk! Invoer verkooporder (autom. vermelding hoeveelheid + prijs Neen Invoer mogelijk zonder referentie prijs? hoeveelheid? -- 34 Bijlage 2 Procesflow inkopen Bijlage 2: Procesflow inkopen. Process: Standard Procurement Cycle Physical Flow Process Flow P0 Pur.Req. MRP P1 Create Purchase Requisition F1 Purchase Requisition P2 Release Purchase Requisition Who Reports Postings Automatic N/A Anyone/limited group N/A R1 Check for open purchase requisitions Purchase Department N/A R2 Purchase Requisition Release document Outline Agreement? N R3 Check Outline Agreements One Time Vendor? N F2 Request for Quotation P3 Request For Quotation F3 Quotations P4 Input Quotations F4 Rejection letters P5 Select vendor Purchase Department Y Y Purchase Department N/A Purchase Department N/A Purchase Department N/A P7 Create Purchase order Purchase Department N/A P8 Release Purchase order Purchase Department N/A P9 Purchase order Monitoring Purchase Department N/A Warehouse N/A Quality department/warehouse N/A P6 Create Outline Agreement F5 Goods receipt N/A Quality Inspection? R4 Check for open purchase orders R5 Purchase order release doc. R6 Check for outstanding purchase orders Y N F6 Quality Inspection Quality OK? Y R7 Check Goods return N F7 Goods Return GR for Consumption Y N P10 Enter Goods Receipt for Consumption Warehouse P11 Enter Goods Receipt for stock Warehouse - Cost to GR/IR account R8 Check of GR against PO - Stock to GR/IR account (to price differences) R9 Check PO w/o GR F8 Store in Warehouse R10 Goods Movement analysis F9 Goods direct to Department -- 35 Bijlage 2 Procesflow inkopen Process: Standard Procurement Cycle Physical Flow Process Flow F10 Receive Invoice F11 Check Invoice Invoice correct? N Y Who Reports Postings Purchase Department/ Financial department N/A Financial department - GL Accounts List Invoice against PO/GR Financial department N/A List of parked Invoices Automatic N/A List Blocked invoices Financial/Controlling Department N/A P15 Unblock Invoice Financial/Controlling Department N/A P16 Payment Financial Department - Accounts payable to bank P12 Post invoice P13 Park invoice P14 Block Invoice F12 Approve Invoice Unblocked invoices -- 36
