Tijdens de implementatie worden gegevens als de lijst met betalingscategorieen, de BTW categorieen, de tolerantie instellingen bij matchen en de goedkeuringshierarchie gevuld.

Op het moment dat er een factuur wordt ingevoerd worden de inrichtingsparameters opgeroepen in routines.De crediteurenmedewerker kiest bijvoorbeeld de BTW code en een logische routine voegt op basis daarvan de BTW regel toe en berekent alvast het bedrag. Op het moment dat de factuur volledig is gaat deze de routing in op basis van de goedkeuringshierarchie. Etcetera. Er zit de nodige complexiteit binnen de crediteuren module zelf.

Ook andere modules en het grootboek zijn nodig om een factuur vast te leggen. Er heeft integratie plaats gevonden in een ERP waardoor dezelfde gegevens maar 1 keer in 1 van de modules worden vastgelegd. Indien er een projectcode wordt ingevuld bij een distributie regel zal de projecten module bij absolute budgetcontrole controleren of er wel voldoende budget aanwezig is. Zo niet dan houdt de projecten module de boeking tegen. De inkoopmodule geeft op basis van het ingevoerde inkooporder nummer de distributie. Tevens wordt bij matchen gekeken of de toleranties niet overschreden worden. Etcetera.

Visuele voorstelling van een module

Er zijn dus de nodige routines binnen een module. En automatische routines kunnen vastlopen. Als Oracle een routine niet kan volbrengen is er een meestal voorgrprogrammeerde actie die de uitzonderingen in bijvoorbeeld een aparte tabel wegschrijft. Bij onvolledige facturen komen deze op een aparte lijst te staan die niet op de proefbalans crediteuren voorkomt. Deze lijst dient u per maandeinde natuurlijk te controleren of daar grote facturen staan. Indien dat zo is dan zou met een stelpost (memo boeking in het grootboek) het resultaatseffect toch in de juiste periode genomen kunnen worden.

Er zijn ook relaties met andere modules. Ons model mbt de EBS begint nu vorm te krijgen. Hieronder ziet u een aantal modules met enkele relaties die gelden. Let wel dat dit een grove versimpeling is, er zijn nog veel meer relaties. Maar onderstaand voorbeeld geeft u een idee over hoe de modules zelf zijn opgebouwd en geeft weer dat er relaties tussen de modules zijn.

Visuele voorstelling van de relaties tussen de modules (sterk vereenvoudigd)

Visuele voorstelling van de relaties tussen de modules onderling en de relatie met het grootboek (sterk vereenvoudigd)

U ziet hier meteen een risico van de opzet. Er lopen veel automatische routines. Doordat Oracle relatief flexibel is in te richten en er vrij veel mogelijk is, bestaat de kans dat er soms routines fout gaan lopen. Menselijke fouten spelen ook een rol. Stel dat de link weergegeven tussen crediteuren en projecten op een gegeven moment niet goed gaat verlopen dan zal dit een onderuitputting bij de projecten overzichten laten zien. Er is ook een relatie tussen de voorraad module en de projecten module. Ik heb en keer meegemaakt bij een klant dat die link tijdens de implementatie niet was aangelegd waardoor het zogenaamde cost collector proces niet liep. Gevolg was dus het ontbreken van de materiaal afgiftes drukkende op de projecten. Relaties tussen veel andere modules heb ik ook fout zien gaan.

Hier wordt een groot risico van de EBS zichtbaar. Niet goed verlopende processen die uw organisatie niet tijdig opspoort en corrigeert. Meestal probeert men deze met periode / maand einde routines te ondervangen. De enige methode is volgens mij daadwerkelijk deze controles uit te voeren en vervolgens indien er gecontroleerd is en er geen fouten zijn geconstateerd de modules voor de betreffende periode dicht te zetten. Enkele modules kunt u indien nodig altijd opnieuw open zetten, bij de vaste activa en de voorraadmodules is dat niet het geval. Eenmaal dicht blijft dicht. Het maandeinde routine document dat u bij de implementatie heeft gekregen dient echter de rapporten en controle mogelijkheden te vermelden die u heeft voordat u deze 2 modules definitief dicht zet. Hiermee kunt u vooraf controleren of deze modules aansluiten met het grootboek.

Een andere reden om de maandeinde routine uit te voeren is zojuist hierboven gemeld. Het gaat niet alleen maar om transacties tussen modules onderling maar ook tussen module en grootboek. De transacties vanuit de modules worden doorgezet naar het grootboek. Dit kan een keer per periode gebeuren aan het einde van de periode (vaste activa afschrijvingen worden eenmalig aan het einde van de periode uitgevoerd). Andere modules worden vaker doorgezet. Soms loopt de interface tussen crediteuren en het grootboek ieder uur. De accountant wil natuurlijk zekerheid dat alle transacties uit de modules van de betreffende periode inderdaad zijn doorgezet. Dus u dient uw aansluitingen van de subs / modules met het grootboek niet alleen te maken maar ook nog eens op te slaan. Sommige organisaties gaan zover dat ze de eerste medewerker grootboek of de eerste medewerker van de betreffende module fysiek het aansluit document laten tekenen.

U begrijpt natuurlijk dat het bovenstaande model een vereenvoudiging is, zowel in het aantal tabellen als in het aantal relaties tussen de modules. Daarnaast heeft u te maken met andere interfaces van niet Oracle modules zoals uw salarissysteem. Of andere maatwerk bedrijfs applicaties. Ook deze interfaces dient u te controleren en aan te sluiten.

Het is natuurlijk evident dat in het grootboek minder detail is opgenomen dan in de modules. U kunt in het grootboek uw budgetten opnemen. Er zijn vrij veel organisaties die deze budgetten liever in een aparte applicatie opnemen. Een al dan niet datawarehouse achtige oplossing als OFA, PSB, Cognos of Hyperion. In dat geval geldt meestal een pyramide waarin onderaan in de modules het detail zit, men in het grootboek detail verliest en overzicht wint, en men in de laag daarboven nog minder detail ziet. U dient natuurlijk ook uw rapportage laag aan te sluiten met het grootboek.

Een van de zaken die soms minder aandacht krijgen dan gewenst is het verklaren van verschillen geconstateerd in uw rapportage oplossing / datawarehouse. Hier worden de overuitputtingen geconstateerd. Uw hele systeem dient er zo op ingericht te zijn dat verschillen geconstateerd in uw rapportage systeem kunnen worden gedupliceerd in het grootboek, anders kunt u de verschillen niet analyseren. Een van de applicaties op de markt is de Insight oplossing van the InsightSoftware. U kunt het ook realiseren door de nodige aandacht te geven bij de inrichting van uw EBS.

Tenslotte komen we dan tot het volgende model:

Visuele weergave van het oracle EBS model inclusief datawarehouse oplossing

Er is nog een aandachtspunt binnen de EBS, en dat is rapportage. De gedachte achter ERP pakketten was dat als alle informatie binnen 1 systeem werd gebracht het met de rapportage wel goed zou komen. Dat is helaas niet zo. Wenst u snel ad hoc te kunnen rapporteren over diverse feiten dan betekent dat dat u binnen de EBS de informatie uit tal van tabellen uit verschillende modules dient te halen. Dat komt doordat de EBS primair een transactie verwerkend systeem is. Het middels vele joins combineren van alle tabellen om de informatie eruit te halen zorgt voor een traag systeem op rapportage vlak.

Ik hoop dat het bovenstaande model voor u een kader schept waarmee u de EBS beter kan begrijpen en iets abstracts als een ERP systeem toch kan visualiseren.

De risico's zijn dus
A] onvolledige of onjuiste processen binnen een module
B] onvolledige of onjuiste processen tussen modules onderling
C] onvolledig doorzetten van de transacties naar het grootboek
D] onvolledig doorzetten van de proefbalans naar het rapportagesysteem

Daarnaast kunnen gebruikersfouten natuurlijk ook een impact hebben. Die impact hoeft bijvoorbeeld niet direct zichtbaar te zijn in de betreffende module waar de fouten worden gemaakt. Fout vaste verrekenprijs beheer heeft een impact bij bijvoorbeeld crediteuren, de voorraadmodule heeft er niet zoveel last van. Doordat het een geintegreerd pakket is kunnen fouten gemaakt in de ene module op diverse andere plaatsen een grote impact hebben. Van deze indirecte effecten dient u zich bewust te zijn, in ieder geval dat ze kunnen optreden.

Dus verdere elementen van een ERP pakket zijn:
E] indirecte effecten
F] matige performance op rapportagevlak

Een aantal van deze risico's kunt u mitigeren door enkele van uw medewerkers met een kritische blik de tijd te geven vreemde zaken op te sporen en uit te zoeken. (naast natuurlijk het strikt uitvoeren van de maandeinde routines). Daarnaast kan het geen kwaad een ervaren post implementatie consultant eens in de zoveel tijd langs te laten komen om een soort van quick scan uit te voeren.