De impact van Supplier Relationship Management (SRM) op het bestaande inkoopproces

Inleiding

Na een relatief langzame start zien we in de laatste jaren een sterke toename in het gebruik van SAP SRM. Steeds meer organisaties zien SRM als het middel om meer efficiency te kunnen behalen in het inkoopproces en het inkoopproces beter te kunnen beheersen. Denk bijvoorbeeld aan het gebruik van workflow ter ondersteuning van het inkoopproces. We zien echter ook genoeg organisaties die na implementatie van SRM niet tevreden zijn omdat SRM niet de verwachte resultaten oplevert. Er dient zich een vergelijking aan met de opkomst van Enterprise Resource Planning (ERP) in de jaren negentig waarbij veel organisaties kozen voor een ERP-implementatie als wondermiddel voor verdere integratie en optimalisatie van de bedrijfsprocessen maar hierbij lang niet altijd de gewenste resultaten behaalden.

Als we één ding geleerd hebben van ERP is het wel dat voor het behalen van de gewenste resultaten het maken van een juiste fit met de organisatie een randvoorwaarde is. Deze fit kan worden bereikt door het aanpassen van het systeem aan de bestaande processen en/of het herontwerpen van de bestaande processen om meer aan te sluiten bij de geïntegreerde aanpak van ERP. Voor SRM geldt hier min of meer hetzelfde. Er dienen belangrijke keuzen te worden gemaakt in het inkoopproces om vast te stellen op welke wijze SRM zal worden ingezet. Het feit dat SRM in meerdere varianten beschikbaar is (classic, extended classic en stand-alone) en bovendien zelf ook voortdurend aan verandering onderhevig is, maakt het er niet makkelijker op om deze keuzen te maken. Een gedegen kennis van de mogelijkheden en uitgangspunten van SRM is benodigd om niet voor onaangename verrassingen te komen te staan.

In dit artikel bieden wij een verder inzicht in SRM door naast het geven van een korte historie van SRM de functionaliteit van de diverse SRM-scenario’s toe te lichten. Hierbij wordt steeds de koppeling gemaakt met het reguliere inkoopproces zoals we dat kennen vanuit de SAP Enterprise Core Component (ECC)-omgeving waarin inkoop plaatsvindt met de SAP Materials Management (MM)-module.

Met de functionaliteit van SRM in gedachten maken we de stap naar interne controle. Door het gebruik van SRM vinden er verschuivingen plaats in de wijze waarop de organisatie risico’s binnen het inkoopproces af moet dekken. Niet alleen kunnen andere controlemaatregelen worden gebruikt, ook de plaats waar deze controlemaatregelen worden uitgevoerd kan sterk verschillen van de situatie zonder SRM. Denk bijvoorbeeld aan de keuze tussen het goedkeuren van bestellingen in SRM of in ECC en het realiseren van functiescheidingen over systemen heen. We lopen in dit artikel in vogelvlucht door de mogelijkheden van SRM heen waar het gaat om interne controle en laten zien dat de mogelijkheden van SRM impact hebben op de bestaande interne controle en de wijze waarop deze wordt geaudit.

Een korte historie

Elke organisatie heeft in meerdere of mindere mate te maken met een inkoopproces. Tot het inkoopproces worden alle activiteiten gerekend die gerelateerd zijn aan de aanschaf van materialen en diensten om goederen te produceren of te verhandelen en om de organisatie draaiende te houden (bijvoorbeeld kantoorartikelen en reserveonderdelen). Tot eind jaren negentig was het inkoopproces voornamelijk handmatig en daardoor veelal inefficiënt, foutgevoelig en duur. Ook was het moeilijk om daadwerkelijk inzicht te verkrijgen in het inkoopproces en het goed te kunnen beheersen.

Met de implementatie van ERP in de jaren negentig kon inkoop worden ondersteund door geautomatiseerde systemen waardoor inkoop al meer efficiënt kon worden uitgevoerd. Ook kon gebruik worden gemaakt van geautomatiseerde goedkeuringsstromen en werd het inzicht in de inkoopactiviteiten versterkt door rapportages. Met de doorbraak eind jaren negentig van het gebruik van internet ontstond bovendien de mogelijkheid tot het elektronisch inkopen via internet (e-procurement), waarbij onder meer gebruik kon worden gemaakt van elektronische catalogi al dan niet onderhouden door de leveranciers zelf.

Alhoewel e-procurement en daarmee het automatiseren van het inkoopproces een belangrijke stap was in de optimalisatie van het inkoopproces, kwamen organisaties ook tot de conclusie dat alleen het automatiseren van inkoop niet voldoende was om de echte kostenbesparingen en voordelen te realiseren die mogelijk zouden moeten zijn rondom inkoop. Andere aandachtsgebieden zoals sourcing, contractbeheer en spendanalyses werden ook belangrijk geacht om de daadwerkelijke voordelen te behalen die met e-procurement mogelijk moesten zijn. Sinds enkele jaren heeft e-procurement zich verder doorontwikkeld tot het huidige Supplier Relationship Management (SRM).

Naast SRM zien we de laatste jaren ook ontwikkelingen op het gebied van elektronische facturatie om de van oudsher tijdrovende papierstroom en factuurcontrole te verminderen. Bij elektronische facturatie wordt e-procurement gebruikt om op elektronische wijze facturen te versturen, ontvangen, verwerken en archiveren. Met deze vorm van facturatie wordt de digitale inkoopcyclus voltooid. In dit artikel zal de focus liggen op e-procurement en niet op e-invoicing.

Supplier Relationship Management

Het is goed zich te realiseren dat SRM geen vervanging of nieuwe vorm is van e-procurement maar veel meer een overkoepelende term waaronder alle activiteiten vallen rondom het managen van de interacties tussen een organisatie en haar leveranciers. Hier maakt e-procurement (of Operational Procurement) onderdeel van uit. Gangbare onderdelen van SRM zijn:

• Operational Procurement: ondersteuning voor het uitvoeren van de dagelijkse activiteiten rond de aanschaf van goederen en diensten vanaf het moment dat een aanvraag tot bestellen wordt gedaan tot en met de verwerking van de factuur voor de ontvangen goederen en diensten.
• Catalog Management: ondersteuning voor onderhoud en publicatie van catalogi waarin producten en prijzen zijn vastgelegd voor specifieke leveranciers op basis waarvan kan worden ingekocht.
• (Strategic) Sourcing: ondersteuning voor alle activiteiten rondom het selecteren van leveranciers inclusief het voeren van onderhandelingen (bijvoorbeeld via veilingen of tenders) en het vastleggen van afspraken.
• Contract Management: ondersteuning voor het vastleggen en monitoren van contractuele afspraken met leveranciers.
• Spend Analysis: ondersteuning van inkopers bij de analyse van inkopen per leverancier, product of productgroep.
• Supplier Enablement: ondersteuning voor samenwerking van leveranciers met de organisatie, bijvoorbeeld door de leverancier toegang te geven tot voorraadgegevens en deze verantwoordelijk te maken voor het tijdig aanvullen van voorraden.

Alhoewel elke SRM-applicatie een andere indeling kan hanteren, is de functionaliteit in grote lijnen steeds te herleiden naar de genoemde kernonderdelen.

Het gebruik van SRM beoogt een aantal belangrijke voordelen. Hieronder worden enkele genoemd:

• stroomlijnen van het inkoopproces in SRM inclusief het vervangen van handmatige door geautomatiseerde stappen waardoor de doorlooptijd van het inkoopproces zal afnemen;
• nieuwe internecontrolemaatregelen in SRM waardoor afname in het aantal fouten en daarmee in duur correctiewerk;
• gebruik van catalogi waardoor in te kopen goederen en diensten makkelijk te vinden zijn en er meer waarborgen zijn dat er van geautoriseerde leveranciers wordt ingekocht;
• gebruik van spendanalyse waardoor meer inzicht ontstaat in uitgaven en leveranciersprestaties ter ondersteuning van het sourcingvraagstuk;
• sterkere gerichtheid op sourcing, want doordat minder tijd benodigd is voor operationele inkoopactiviteiten kunnen (centrale) inkopers zich meer richten op het selecteren van leveranciers, het onderhandelen over contracten en het onderhouden van relaties.

De markt voor SRM-pakketten wordt geleid door drie partijen, namelijk SAP (15%), Ariba (14%) en Oracle (12%). Wij zullen ons in dit artikel richten op SAP SRM. Dit niet alleen omdat SAP marktleider is maar vooral ook omdat de auteurs zich in de praktijk voornamelijk bezighouden met bedrijfsprocessen en interne controle in en rondom SAP-omgevingen. Alhoewel SAP SRM centraal staat is hetgeen genoemd wordt in dit artikel grotendeels ook toepasbaar op andere SRM-pakketten.

SAP SRM

De start van SAP op het gebied van e-procurement was in 1999 met Business-to-Business Procurement (BBP), dat vrijwel direct daarna Enterprise Buyer Professional (EBP) werd genoemd. EBP was nog niet zo uitgebreid als het huidige SRM en richtte zich primair op het onderdeel ‘Operational Procurement’ ofwel het meer efficiënt maken van de dagelijkse inkoopactiviteiten. In de jaren daarna is EBP doorontwikkeld tot het huidige SRM 2007 (SRM 6.0) waarmee een volledige oplossing wordt aangeboden voor het managen van interacties met de leveranciers. De gangbare SRM-versie die op dit moment bij klanten wordt aangetroffen, is SRM 4.0.

SAP SRM bestaat uit drie kerngebieden die tezamen de eerdergenoemde generieke SRM-onderdelen afdekken. De door SAP gekozen gebieden zijn:

Operational Procurement

Dit kerngebied is gericht op ondersteuning van de dagelijkse inkoopactiviteiten in SAP SRM en is onderverdeeld in de volgende gebieden:

• Self-service procurement (indirect procurement): gericht op decentraal inkopen door eindgebruikers van doorgaans indirecte materialen zoals kantoorartikelen en reserveonderdelen welke vastliggen in een catalogus.
• Plan-driven procurement (direct procurement): gericht op centraal inkopen van kernmaterialen (grondstoffen, etc.) waarbij inkopen gekoppeld kunnen worden aan bestaande planningsapplicaties.
• Service procurement: gericht op ondersteuning van het inkopen van diensten, zoals consultancy, tijdelijk werk en onderhoudsdiensten.

Strategic Sourcing

Dit kerngebied is gericht op ondersteuning voor het aangaan, vastleggen en monitoren van leveranciersrelaties en afspraken:

• Catalogus content management: ondersteuning voor onderhoud en publicatie van catalogi.
• Strategic Sourcing and Contract management: ondersteuning voor alle activiteiten rondom het selecteren van leveranciers inclusief het voeren van onderhandelingen en het vastleggen en monitoren van contractuele afspraken met leveranciers.
• Spend analysis: ondersteuning van inkopers bij het analyseren van inkopen.

Supplier Enablement

Dit kerngebied is gericht op integratie van leverancier met inkoopprocessen:

• Supplier self-registration: ondersteuning voor inkopers om potentiële nieuwe leveranciers te identificeren doordat leveranciers zichzelf bij de organisatie kunnen aanmelden.
• Design collaboration: ondersteuning voor integratie met leverancier tijdens ontwerpfase, waarbij leverancier bijvoorbeeld kan meekijken naar specificaties.
• Order collaboration: ondersteuning voor automatisch uitwisselen van inkoopdocumenten zoals bestellingen en facturen.
• Collaborative replenishment: gericht op integratie met leverancier rondom voorraadbeheer, bijvoorbeeld door de leverancier toegang te geven tot voorraadgegevens en deze verantwoordelijk te maken voor het tijdig aanvullen van voorraden.

Om de bovengenoemde ondersteuning te kunnen bieden maakt SAP SRM gebruik van een aantal technische componenten waarvan de belangrijkste zijn:

• SAP Enterprise Buyer (EBP): de kernmodule van SRM voor het afhandelen van inkopen vanaf het aanleggen van een winkelwagen tot het verwerken van de factuur. Tevens de vroegere benaming van SRM toen dit nog slechts gericht was op de operationele inkoopactiviteiten, nu onderdeel van de meeromvattende SRM-applicatie.
• SAP Bidding Engine: component voor het uitvoeren van leveranciersselecties door middel van biedingen en veilingen.
• SAP Supplier Self-Services (SUS): component die het mogelijk maakt leveranciers te integreren in de inkoopprocessen van de organisatie.
• SAP Catalog Content Management (CCM): component voor het onderhouden en publiceren van catalogi. De steeds verdergaande ontwikkeling rondom SAP Master Data Management (MDM), de overkoepelende oplossing van SAP voor het onderhoud van stamgegevens, heeft SAP doen besluiten CCM niet verder te ontwikkelen maar het catalogusbeheer op termijn op te nemen in MDM via de ‘SRM-MDM Catalog’-oplossing.
• SAP Business Information Warehouse (BW): dit is de overkoepelende business intelligence tool van SAP die door SRM wordt gebruikt voor het leveren van rapportages rondom inkoop.
• SAP Exchange Infrastructure (XI): overkoepelende interfacetechniek van SAP die bij SRM wordt gebruikt voor het koppelen van diverse technische componenten en voor het uitwisselen van inkoopdocumenten met leveranciers.
• SAP Enterprise Portal: overkoepelende oplossing van SAP voor het geïntegreerd aanbieden van applicaties aan eindgebruikers via een zogeheten portaal dat bij SRM wordt gebruikt om bijvoorbeeld de inkoopapplicatie te tonen.

Het bovenstaande geeft een overzicht van de functionaliteit van SRM en de diverse componenten waaruit SRM is opgebouwd. In het vervolg van dit artikel gaan wij voornamelijk in op de onderdelen Operational Procurement, Catalog Management en de onderliggende SAP EBP-component omdat hiermee het daadwerkelijke inkoopproces (ook wel Purchase-to-Pay of PtP genoemd) wordt ondersteund.

We zullen de relatie leggen tussen het klassieke PtP-proces en SRM, en daarna aangeven wat de impact is van SRM op de interne controle in en om het PtP-proces.

De integratie van SAP SRM met PtP

Het gebruik van SRM heeft een grote impact op het PtP-proces zoals dat wordt uitgevoerd zonder SRM. Niet alleen betekent de integratie met SRM dat de uitvoer van specifieke activiteiten van het back-end ERP-systeem naar SRM wordt verplaatst, er dienen ook keuzen te worden gemaakt rondom interne controle in PtP. Voordat wij zullen ingaan op de integratie van SRM in het PtP-proces, wordt eerst het PtP-proces kort geschetst.

De basis van PtP bestaat hoofdzakelijk uit drie stappen: het aanleggen van een bestelling voor benodigde goederen en diensten, het boeken van de ontvangst hiervan en het verwerken en betalen van de bijbehorende factuur. Alle andere activiteiten zoals het aanleggen van een bestelaanvraag, het uitvoeren van voorraadplanning en het contractbeheer zijn in principe alleen aanwezig om de drie hoofdstappen efficiënter en betrouwbaarder uit te voeren. In een contract kunnen prijsafspraken worden vastgelegd welke (al dan niet verplicht) gebruikt worden in een bestelling, voorraadplanning zorgt voor tijdig initiëren van nieuwe inkopen, etc.

In figuur 1 is het volledige PtP-proces weergegeven. De binnenste cirkel (groen) geeft de PtP-activiteiten weer inclusief de naamgeving zoals gehanteerd in de back-end inkoopmodule SAP Materials Management (SAP MM) en de back-end financiële module voor crediteurenbeheer SAP Accounts Payable (SAP FI-AP). In de buitenste cirkel (oranje) zijn vervolgens de equivalenten van de PtP-activiteiten in SRM weergegeven. Hierbij worden de diverse SRM-scenario’s, waarbij de verdeling van activiteiten tussen back-end ERP en SRM varieert, vooralsnog even buiten beschouwing gelaten.

Figuur 1. Het Purchase-to-Pay proces.

Het mag duidelijk zijn dat dit inkoopproces algemeen geldend is en niet ineens anders wordt nu SRM wordt gebruikt. SRM wordt vooral ingezet om het inkoopproces efficiënter te maken, wat in principe gebeurt door stappen in het inkoopproces uit te voeren in SRM. Doordat activiteiten in SRM worden ondersteund door geautomatiseerde workflows kunnen deze stappen sneller uitgevoerd worden (bijvoorbeeld de goedkeuring van winkelwagens) en is tevens meer inzicht aanwezig in de huidige status van een bestelling.

We lopen de figuur langs en geven een toelichting bij de diverse stappen.

Winkelwagen (Shopping cart)

Elke inkoop start met een winkelwagen, het SRM-equivalent van een bestelaanvraag in SAP MM. De winkelwagen kan worden gebruikt om een zogenoemde ‘vrije tekst inkoop’ te doen waarbij de gebruiker een omschrijving opgeeft van de benodigde producten die bijvoorbeeld niet in de catalogus te vinden zijn, maar beter is natuurlijk om producten te selecteren uit een catalogus. In de catalogus ligt precies vast wat de prijs is van een bepaald product als dit wordt ingekocht bij een specifieke leverancier. Denk bijvoorbeeld aan catalogi voor kantoorartikelen. Hoewel het back-end ERP-systeem catalogi niet als zodanig kent, kan de doelstelling hiervan (prijs-product-leveranciercombinatie) het best worden vergeleken met een contract of inforecord. Er wordt later meer specifiek ingegaan op het catalogusbeheer.

Nadat de winkelwagen is vastgelegd wordt, afhankelijk van de SRM-instellingen, een goedkeuringstraject gestart. Deze goedkeuring, het equivalent van de vrijgavestrategie in SAP MM, is bijvoorbeeld gebaseerd op de waarde van de winkelwagen, de productgroep en de volledigheid van de winkelwagen (in het geval van vrije tekst bestellingen of onvolledige bestellingen). Via workflow wordt de winkelwagen langs één of meer goedkeurders gestuurd. Nadat de winkelwagen is goedgekeurd, is deze beschikbaar voor verdere verwerking.

Bestelling (Purchase order)

Goedgekeurde winkelwagens worden in principe omgezet naar een bestelling in SRM en/of het back-end ERP-systeem. Waarin de bestelling wordt aangelegd, hangt af van het ingerichte SRM-scenario. Deze SRM-scenario’s worden later toegelicht.

Indien de bestelling in SRM wordt aangelegd, wordt een kopie naar het back-end ERP-systeem gestuurd. Indien de bestelling in het back-end ERP-systeem wordt aangelegd, is er in SRM geen bestelling aanwezig maar alleen de achterliggende winkelwagen die als bron diende voor de bestelling.

Het omzetten van een winkelwagen naar een bestelling kan volledig automatisch plaatsvinden, bijvoorbeeld indien deze is gebaseerd op een catalogus. Alle benodigde informatie is dan bekend en de bestelling kan direct worden verstuurd. Indien er een vrije tekst inkoop is gedaan of er ontbreekt informatie, dan wordt de afdeling inkoop betrokken bij de bestelling. Hiermee wordt ook direct duidelijk dat juist het werken met catalogi de meeste efficiency oplevert doordat inkoop er zo min mogelijk bij betrokken wordt en zich meer kan focussen op zaken als sourcing.

Goederenontvangst (Confirmation)

Wanneer goederen worden ontvangen, wordt in SRM een confirmation gedaan, het equivalent van de goederenontvangst in SAP MM. Tevens wordt een kopie van deze boeking naar het back-end ERP-systeem gestuurd en gekoppeld aan de bestelling. De ontvangst kan ook direct in SAP MM worden geboekt. In dat geval wordt een kopie van de ontvangstboeking naar SRM gestuurd en gekoppeld aan de bijbehorende winkelwagen.

Factuurontvangst (Invoice confirmation)

De factuur die wordt ontvangen voor de geleverde goederen en diensten kan net als de goederenontvangst zowel in SRM als in het back-end ERP-systeem worden verwerkt. Afhankelijk van het systeem waar de factuur wordt ingeboekt, wordt tevens een gerelateerde boeking gemaakt in het andere systeem.

Anders dan bij de goederenontvangst, die vaak al in SRM wordt afgehandeld, wordt de factuur vrijwel altijd nog in het back-end ERP-systeem geboekt. De voornaamste reden hiervoor is dat de goederenontvangst in SRM niet veel meer omvat dan het bevestigen dat hetgeen in de winkelwagen staat ook binnen is gekomen (een functionaliteit die kan worden gebruikt in een SRM-workflow en die geen directe boekingen tot gevolg heeft). Voor de factuur dient echter veel meer informatie te worden ingevoerd waardoor het minder gemakkelijk is deze activiteit over te zetten. De financiële administratie werkt daarnaast toch al voornamelijk in het back-end ERP-systeem, en dus wordt het verwerken van facturen daarin meegenomen.

Zoals eerder genoemd wordt de factuur in het back-end ERP-systeem wel steeds vaker verwerkt via elektronisch factureren, waarbij na het scannen van de factuur deze via workflow langs de diverse behandelaars en goedkeurders wordt gestuurd. In dit artikel wordt elektronisch factureren buiten beschouwing gelaten.

De betaling van de factuur is geen activiteit die in SRM wordt uitgevoerd en is onderdeel van de reguliere betaalactiviteiten van de financiële administratie.

Stamgegevens (Master data)

Bij het uitvoeren van inkoopactiviteiten, zowel in SRM als in SAP MM, wordt een grote hoeveelheid stamgegevens gebruikt. Denk hierbij aan producten, prijzen, leveranciers, contracten, inkooporganisaties, etc. Deze stamgegevens dienen in beginsel om het inkoopproces te versnellen doordat zij niet steeds opnieuw hoeven te worden ingevoerd tijdens een inkoop maar direct worden meegenomen bij het selecteren van bijvoorbeeld een leverancier of product. Door dit kenmerk kunnen onjuiste stamgegevens in SRM of inconsistente stamgegevens tussen SRM en ERP echter grote impact hebben op het inkoopproces zoals onjuiste besluitvorming, vertragingen door correcties en – als de fout niet wordt opgemerkt – bijvoorbeeld het inkopen tegen onjuiste prijzen.

De meeste stamgegevens in het inkoopproces bestaan in zowel SRM als ERP. Alhoewel deze in beide systemen onderhouden kunnen worden is het gangbaar deze in ERP te onderhouden en daarna te repliceren naar SRM en waar nodig aan te vullen. Het spreekt voor zich dat er rondom stamgegevens voldoende internecontrolemaatregelen dienen te zijn om de integriteit van de stamgegevens te waarborgen.

Catalogusbeheer

Een speciale categorie stamgegevens zijn de catalogi. In een catalogus worden voor een specifieke (interne of externe) leverancier de producten met bijbehorende prijzen opgenomen waaruit kan worden gekozen bij het aanmaken van een winkelwagen. Door gebruik van een catalogus kan het inkoopproces verder worden versneld aangezien alle informatie rondom leverancier en prijs al is ingevuld en hierdoor de winkelwagen vaak automatisch kan worden omgezet naar een bestelling.

Oorspronkelijk maakte SAP SRM gebruik van een third-partyoplossing voor catalogi, genaamd Requisite. Dit was een relatief eenvoudige techniek volledig gericht op het beschikbaar stellen van product- en prijsinformatie aan de inkoper. Organisaties kwamen er echter al snel achter dat het publiceren van catalogi niet slechts een kwestie was van het periodiek uploaden van een nieuwe prijslijst, maar dat er ook een gestructureerde vorm van kwaliteitscontrole nodig was inclusief harmonisatie van onderhoud met andere stamgegevens over verschillende systemen heen. Om hierop in te springen heeft SAP enige jaren geleden een eigen oplossing ontwikkeld, genaamd Catalog Content Management (CCM), waarvan inmiddels versie 2.0 beschikbaar is.

Inmiddels is SAP zover dat zij het catalogusbeheer in beginsel niet meer los ziet van het onderhoud van andere stamgegevens. Het onderhoud van catalogi wordt vanaf nu dan ook ondergebracht in de overkoepelende SAP Master Data Management (MDM)-oplossing via SAP MDM Catalog. CCM wordt hiermee op korte termijn uitgefaseerd.

SAP SRM-scenario’s

In de vorige paragrafen is beschreven hoe SAP SRM integreert met het PtP-proces door het verplaatsen van activiteiten van SAP MM naar SRM. Maar welke stappen worden nu in SRM uitgevoerd en welke nog steeds in het reguliere back-end ERP-systeem? Dit hangt af van het SRM-scenario dat door een organisatie wordt gekozen en de specifieke invulling van dat scenario. SRM kent drie scenario’s, en wel:

Classic

SRM wordt primair gebruikt om winkelwagens aan te maken die na te zijn goedgekeurd in SRM verder worden verwerkt in het back-end ERP-systeem tot een bestelling. Er is dan ook geen bestelling in SRM anders dan de achterliggende winkelwagen. Alle vervolgacties zoals de ontvangst van de goederen en de factuur worden primair in het back-end ERP-systeem uitgevoerd, alhoewel het wel mogelijk is om via zogeheten ‘confirmations’ de ontvangst van de goederen en de factuur door referentie aan de winkelwagen via SRM te laten verlopen.

Extended classic

SRM wordt gebruikt om winkelwagens aan te maken en goed te keuren maar eveneens om de bestellingen die hieruit voortvloeien vast te leggen. Er wordt wel een kopie van de bestelling naar het back-end ERP-systeem gestuurd, maar deze kan daar alleen worden weergegeven en niet worden onderhouden. Alle vervolgacties zoals de ontvangst van de goederen en de factuur worden primair in SRM uitgevoerd via zogeheten ‘confirmations’, alhoewel het wel mogelijk is om de ontvangst van de goederen en de factuur via het back-end ERP-systeem te laten verlopen. Vooral voor de factuur geldt dat deze in de praktijk veelal nog gewoon via ERP wordt afgehandeld.

Stand-alone

SRM wordt gebruikt voor het gehele inkoopproces en er is geen back-end ERP-inkoopmodule meer bij betrokken. Bij het ontvangen van de factuur in SRM wordt wel een boeking gemaakt in het achterliggende financiële systeem van de organisatie.

In de praktijk wordt vooral het classic scenario gebruikt. Dat is niet zo verwonderlijk want dit scenario leunt nog het meest tegen het back-end ERP-systeem aan (bijvoorbeeld SAP MM), waardoor de omslag naar SRM het minst groot is en veel gebruikers in inkoop, magazijnbeheer en de financiële administratie de werkzaamheden kunnen uitvoeren als voorheen. In veel gevallen is het de organisatie eerst te doen om het efficiënter afhandelen van de vele bestelaanvragen. Via het classic scenario kunnen de eindgebruikers deze aanvraag veelal zelf afhandelen terwijl de hoofddocumenten (bestelling, goederenontvangst, factuur) nog gewoon in het ERP-systeem worden verwerkt.

Steeds meer organisaties kiezen echter voor extended classic. Het voordeel van extended classic is dat het volledige inkoopproces in principe via SRM wordt uitgevoerd met de meeste mogelijkheden om de efficiëntie te verbeteren. Het gebruik van dit scenario betekent veelal wel dat grote groepen gebruikers moeten omschakelen naar het SRM-systeem.

Naast de verdere stroomlijning van inkoop biedt extended classic ook extra functionaliteit ten opzichte van classic. Behalve indirecte artikelen, zoals kantoorartikelen en reserveonderdelen, wil de organisatie vaak ook de goederen via SRM inkopen die als bron dienen voor het handelsproces of het productieproces, zoals grondstoffen en halffabricaten. Dit type inkopen wordt vaak ook gekoppeld aan een voorraadplanning (bijvoorbeeld via back-end ERP). Hiervoor gebruikt SRM het onderdeel plan-driven procurement, dat niet volledig wordt ondersteund door het classic scenario.

Stand-alone wordt in de praktijk het minst gebruikt en is vooral van belang voor organisaties die geen back-end inkoopsysteem hebben zoals SAP MM of dit niet meer willen gebruiken voor inkopen.

Kenmerkend voor alle SRM-scenario’s is het gebruik van workflow. Via workflow, wat niets anders is dan het afdwingen van een aantal activiteiten in een vooraf vastgestelde volgorde en door een vooraf vastgestelde groep personen, wordt niet alleen de tijdigheid van het inkoopproces gewaarborgd maar ook dat waar nodig alle inkopen worden goedgekeurd. Aangezien er doorgaans wordt gesteund op controlemaatregelen in de workflow (bijvoorbeeld goedkeuring) is het van belang dat wordt gewaarborgd dat niet buiten de workflow om kan worden gewerkt waardoor er bijvoorbeeld een goedkeuringsstap wordt omzeild.

SRM en interne controle

In de voorgaande paragrafen is getoond welke uitgebreide mogelijkheden SRM biedt om het inkoopproces verder te ondersteunen en daarmee efficiënter te maken. Of dit lukt hangt niet alleen af van de vraag of de functionaliteit van SRM juist wordt ingezet maar ook van de vraag of er rekening wordt gehouden met de nieuwe vraagstukken rondom interne controle.

Bij het ontwerpen van de controledoelstellingen en het vaststellen van de risico’s is het in eerste instantie niet wezenlijk van belang in welk systeem de processtap zich voordoet. Het inkoopproces is algemeen geldend en het risico van onjuiste prijzen of het inkopen bij niet toegestane leveranciers staat los van het systeem. Echter, om vervolgens te beoordelen of risico’s voldoende worden afgedekt dient wel degelijk rekening te worden gehouden met het systeem en het hierbij gekozen scenario. Er vinden verschuivingen plaats in de keuze van de controlemaatregelen maar ook in de plaats waar deze controlemaatregelen worden uitgevoerd.

Als voorbeeld kan de juistheid van inkoopprijzen worden genoemd. Het is een risico als de juistheid van prijzen via het ERP-systeem wordt afgedekt terwijl de bestelling mogelijk direct vanuit SRM wordt verzonden aan de leverancier. Andersom zijn alleen prijscontroles in SRM niet voldoende als de bestelling, na te zijn overgezet naar het back-end ERP-systeem, alsnog kan worden gewijzigd.

CARP in een SRM-omgeving

Om een afgewogen keuze te maken tussen het implementeren van internecontrolemaatregelen in SRM of ERP dient men te weten wat er mogelijk is in SRM en dan met name rondom de geprogrammeerde maatregelen. Aan de hand van het CARP-model, dat de internecontrolemaatregelen indeelt naar configuratie, autorisatie, rapportages en procedures, willen wij laten zien wat de invloed is van SRM op interne controle. Dit artikel heeft niet als doel een raamwerk van interne controle te geven voor gebruik in een SRM-omgeving. Doel is wel om de problematiek rondom interne controle in een SRM-ERP-omgeving te laten zien en de lezer bewust te maken van de keuzen die hierbij gemaakt moeten worden.

Configuratie in SRM

In tegenstelling tot het reguliere SAP R/3-systeem, waarin configuratiemaatregelen worden ingesteld via de zogeheten implementation guide (transactie SPRO), zijn er in SRM meerdere manieren om te configureren. Op hoofdlijnen zijn er binnen SRM drie verschillende manieren om configuratiemaatregelen te implementeren:

IMG/SPRO

Net als ERP kent SRM ook de klassieke IMG (bereikbaar via transactie SPRO) waarmee een aantal instellingen kan worden gemaakt om het systeem te sturen. De IMG van SRM is echter veel minder uitgebreid dan binnen ERP. Binnen SRM is de IMG vooral gericht op het maken van technische instellingen zoals interfaces (RFC destinations) en attributen en bijna niet op functionele instellingen zoals toleranties.

Business Add-In (BAdI)

Een BAdI is een stuk standaardprogrammacode dat aanwezig is in SRM maar alleen actief is als de organisatie dit als relevant beschouwt voor haar proces. Een voorbeeld van een BAdI is een documentcontrole op volledigheid van velden. Een BAdI is deels aan te passen door de organisatie waardoor maatwerk wordt gerealiseerd. Een voorbeeld van een dergelijke BAdI is dat er bij het goedkeuren van een aanvraag tot bestelling naar maatwerktabellen wordt verwezen waar de budgethouders in staan.

Webbrowser

Binnen SRM is het mogelijk via de webbrowser (dit is dus eigenlijk de voorkant van het systeem) systeeminstellingen te wijzigen en deze dient veelal als web-based IMG voor SRM. Bijvoorbeeld met transactie BBPCTOL is het mogelijk de toleranties in te stellen voor hoeveelheidsverschillen tussen leveringen en facturen.

Het instellen van configuratiemaatregelen op meerdere plaatsen maakt het geheel complexer dan in R/3. Alhoewel er weinig overlap zit in de diverse instellingen in elk van de drie categorieën, is niet altijd eenvoudig aan te geven waar specifieke controlemaatregelen ingesteld moeten zijn.

De aandachtspunten bij het inrichten of beoordelen van controlemaatregelen liggen (naast de benodigde kennis waar men wat kan instellen in SRM) vooral in de plaats in het proces waar een controlemaatregel wordt ingezet. Het moet worden voorkomen dat bepaalde controlemaatregelen kunnen worden omzeild (waarborg effectiviteit van maatregelen), maar aan de andere kant moeten ook niet te veel controlemaatregelen worden ingezet (waarborg efficiency van maatregelen). Enkele voorbeelden:

• Prijzen kunnen worden ingevoerd in een catalogus die vervolgens wordt gebruikt in een winkelwagen. Het risico van onjuiste prijzen moet worden afgedekt in SRM (via beheer van catalogi, via vrijgave van winkelwagens) indien de winkelwagen na goedkeuring direct wordt omgezet in een bestelling en niet meer in R/3 verwerkt wordt. Voor winkelwagens die worden omgezet in een aanvraag tot bestelling in R/3 en daarna door inkoop verder worden afgehandeld, ligt de controle juist in R/3.
• Vrijgavestrategieën (in verband met goedkeuring winkelwagens) kunnen worden ingesteld in SRM op de winkelwagen, maar ook in R/3 op een (aanvraag tot) bestelling. Wederom geldt dat afhankelijk van het gekozen scenario al dan niet in SRM en/of in R/3 wordt goedgekeurd.
• Tolerantiecontrole voor het controleren van verschillen tussen de goederenontvangst en de bestelling kan zowel in SRM als in R/3 worden ingesteld. Afhankelijk van het scenario vindt de goederenontvangst in SRM of R/3 plaats.

Autorisaties / Logische toegangsbeveiliging

Autorisatiemaatregelen worden gebruikt om de toegang tot activiteiten en gegevens in SRM af te schermen. In tegenstelling tot SAP R/3 is de mogelijkheid om op basis van autorisaties af te schermen veel complexer doordat in SRM meerdere beveiligingsconcepten door elkaar worden gebruikt en deze op meerdere plaatsen in het systeem kunnen worden ingesteld.

Ten eerste gebruikt SRM bij het uitvoeren van activiteiten de gewone transactiecodecheck en ABAP-autorisatieobjecten zoals die ook in bijvoorbeeld SAP MM en SAP FI worden gebruikt. Naast de transacties, objecten en organisatorische waarden is het binnen SRM echter ook nodig te autoriseren via de organisatorische structuur. Dit is enigszins vergelijkbaar met SAP HR. Wanneer een gebruiker een winkelwagen wil vullen voor een bepaalde inkooporganisatie, dan dient deze gebruiker ook via de organisatiestructuur aan deze entiteit gekoppeld te zijn. Tot slot heeft een gebruiker zogeheten attributen nodig waarin waarden zijn opgenomen waarvoor hij activiteiten mag uitvoeren (bijvoorbeeld type winkelwagen, kostenplaats).

In figuur 2 is een totaaloverzicht gegeven. Elk van deze drie mogelijkheden wordt hieronder in meer detail beschreven.

Figuur 2. Een totaaloverzicht van de autorisatiecheck in SRM.

Afschermen via klassieke ABAP-autorisaties

Binnen SAP SRM zijn er twee soorten transacties te onderscheiden:

• Back-end transacties: deze kunnen alleen in de SAP GUI worden uitgevoerd. Deze transacties zijn met name gericht op customizing en systeemonderhoud.
• Webbrowsertransacties: deze kunnen alleen in de SRM-webbrowser worden uitgevoerd. Deze transacties beginnen meestal met ‘BBP_’ en hebben hoofdzakelijk te maken met de daadwerkelijke inkoopfunctionaliteit en de configuratie van SRM op functioneel niveau, zoals toleranties en gebruikersbeheer.

Voor beide groepen van transacties geldt dat deze kunnen worden afgeschermd op transactiecodeniveau, maar ook op objectniveau. Voor webbrowsertransacties zijn er andere objecten beschikbaar (beginnend met ‘B_’) dan voor back-end transacties, wat logisch is omdat de back-end transacties meer gericht zijn op de systeeminstellingen en de customizing. Daarnaast is er voor de webbrowsertransacties slechts een beperkte set van organisatorische niveaus beschikbaar, waarvan de belangrijkste de inkoopgroep ($BBP_PURGRP) en inkooporganisatie ($BBP_PURORG) zijn.

Tot slot is er nog een groot verschil met SAP dat vooral van invloed is op het oplossen van autorisatieproblemen. In het geval er in SAP een autorisatieprobleem is, kan met transactie SU53 vrij snel achterhaald worden wat de oorzaak van dat probleem is. Voor webbrowsertransacties is dit niet mogelijk. Om een autorisatieprobleem op te lossen dient in het back-end door middel van transactie ST01 een system trace te worden aangezet om op die manier de oorzaak van het autorisatieprobleem te achterhalen.

Afschermen via organisatiestructuur

Binnen SRM is een organisatiestructuur (boom) aanwezig, vergelijkbaar met SAP HR, waarin een medewerker kan worden gepositioneerd. Door een medewerker aan een bepaalde positie in deze boom te koppelen ‘erft’ deze persoon een aantal toegangsrechten welke van toepassing zijn op die positie in de boom. Denk hierbij aan inkoopgroepen en inkooporganisaties. Daarnaast is een aantal attributen per gebruiker in te stellen, zoals beschikbare catalogi, die eveneens via de boom aan de gebruiker worden toegekend. De organisatiestructuur is binnen SAP SRM in te stellen met de transactie PPOMA_BBP.

Attributen

Het gebruik van attributen met betrekking tot autorisaties is relatief nieuw in vergelijking met SAP R/3. Attributen kunnen worden ingesteld in de organisatiestructuur waarbij in de configuratie kan worden aangegeven wie welke attributen via de webbrowser mag bekijken of wijzigen.

Een voorbeeld is een catalogus die pennen en potloden bevat. Deze catalogus kan wereldwijd als standaard worden gedefinieerd waardoor alle SRM-gebruikers waar ook ter wereld toegang hebben tot die catalogus. Catalogi kunnen ook op lokaal niveau worden gedefinieerd, namelijk voor gevallen waarin een lokale businessbehoefte het gebruik van een specifieke (bijvoorbeeld landspecifieke) catalogus noodzakelijk maakt.

Een tweede voorbeeld is dat er wereldwijd kan worden ingesteld dat de maximale bestedingslimiet € 500 is, waarbij dit – bijvoorbeeld afhankelijk van het land – op lokaal niveau kan worden aangepast op € 250.

Door attributen op een zo hoog mogelijk niveau in te stellen is de onderhoudbaarheid vanzelfsprekend het hoogst (slechts eenmalig instellen), maar de flexibiliteit het laagst (geldig voor iedereen in de organisatie). Figuur 3 toont een aantal veelgebruikte attributen.

Figuur 3. Veelgebruikte SRM-attributen.

Door het gebruik van drie verschillende concepten wordt het instellen van bevoegdheden in SRM een stuk complexer dan in een klassieke SAP-omgeving. Eveneens betekent dit dat de huidige tools die gebruikt worden om de reguliere ABAP-autorisaties (transacties, objecten) te controleren niet altijd meer voldoen. Zie hierover meer in de paragraaf ‘Het auditen van SRM’.

De aandachtspunten bij het inrichten of beoordelen van bevoegdheden in SRM en R/3 zijn vooral de gekozen combinatie van de diverse beveiligingsmethoden en het ontstaan van systeemoverschrijdende autorisatievraagstukken (zoals functiescheiding).

De gekozen combinatie van methoden bepaalt of bevoegdheden in het inkoopproces volledig zijn afgedekt of dat er gaten in de beveiliging zitten. Denk aan de toegang tot bepaalde onderdelen van de organisatie, zoals de inkooporganisatie. Deze wordt toegekend via de organisatiestructuur maar ook via de ABAP-autorisatieobjecten.

De problematiek van systeemoverschrijdende bevoegdheidsvraagstukken zien we bijvoorbeeld terug in functiescheiding. Denk aan het aanleggen van een bestelling in SRM en het boeken van een goederenontvangst in R/3. Ook moet er in R/3 worden geautoriseerd op bepaalde aan SRM gerelateerde elementen, bijvoorbeeld een specifiek documenttype dat door R/3-gebruikers niet mag worden gewijzigd. Het spreekt voor zich dat het werken met deze systeemoverschrijdende bevoegdheidseisen het niet makkelijker maakt om bevoegdheden te beoordelen. De nieuwste generatie monitoring tools biedt dan ook veelal deze mogelijkheid al aan.

Rapportages

Rapportages als controlemaatregel worden in principe gebruikt om verstoringen in het procesverloop tijdig op te merken. In de klassieke SAP-omgeving zijn veel standaardrapportages aanwezig waarmee dit met wisselende diepgang kan worden gerealiseerd. In SRM is dit soort rapportages slechts beperkt aanwezig. Rapportages in SRM, die veelal via BW worden getoond, zijn voornamelijk gericht op uitgavenanalyse en analyse van de inkopen en niet zozeer op het vaststellen van uitzonderingen.

Het is lastig om als controlemaatregel beschikbare rapportages zodanig af te schermen dat daardoor wordt voorkomen dat één rapport door meerdere inkoopgroepen of inkooporganisaties kan worden gebruikt.

Een voorbeeld is transactie BBP_BW_SC3 (winkelwagens per product). Dit is een rapport dat meer duidelijkheid kan verschaffen in de status van een winkelwagen. Er kan zich voordoen dat organisatie A niet de winkelwagens van organisatie B mag zien omdat zij bijvoorbeeld concurrenten van elkaar zijn (ondanks dat ze bij dezelfde organisatie horen). In ERP kan door middel van het afschermen op bedrijfsnummer of vestiging in de rollen een scheiding worden aangebracht. In SRM is dit niet mogelijk voor dit rapport. Om een scheiding te bewerkstelligen kan er een user exit worden gemaakt en een organisatorisch niveau worden toegevoegd.

Nu we gezien hebben wat SRM is en hoe SRM functioneel kan worden ingezet (gebaseerd op de verschillende scenario’s), rijst de vraag hoe we SRM kunnen gebruiken als systeem waar de preventieve controles in worden vastgelegd.

In tabel 1 wordt ter illustratie een aantal risico’s van het inkoopproces beschreven en wordt gebaseerd op het SRM-scenario aangegeven waar de controles plaats dienen te vinden en hoe deze in het systeem gewaarborgd kunnen worden. Dit is vanzelfsprekend geen uitputtend overzicht.

Tabel 1. Voorbeelden van risico’s en controlemaatregelen in diverse SRM-scenario’s.

Het auditen van SRM

In aanvulling op de functionaliteit van SRM en de impact daarvan op de interne controle willen wij ter afsluiting van dit artikel nog enkele aandachtspunten meegeven voor de audit in een SRM-omgeving. In de voorgaande paragrafen zijn we vooral ingegaan op de inhoudelijke aspecten van interne controle in SRM. Het spreekt voor zich dat deskundigheid in de materie van belang is bij het uitvoeren van een audit in een SRM-omgeving. Naast de inhoudelijke kant dient er ook rekening te worden gehouden met de meer organisatorische en procesaspecten van de (audit)opdracht.

• Indien u als IT-auditor wordt gevraagd om een oordeel te geven over de betrouwbaarheid van een SRM-implementatie, dan is voor de scoping verstandig om eerst te bepalen voor welk scenario is gekozen. Indien het stand-alone scenario is gekozen, is er normaliter geen interface met een back-end ERP-inkoopmodule gerealiseerd en wordt het gehele inkoopproces via SRM afgehandeld. Hierdoor zal het beoordelen van de SRM-omgeving eenvoudiger zijn dan wanneer gekozen is voor het classic of extended classic scenario.
• Bij het vaststellen van de scope wordt vaak het ‘beoordelen van SRM’ genomen, maar zoals aangetoond bevat SRM enorm veel functionaliteit en moet dus de vraag worden gesteld wat de reikwijdte van de audit is. Moet catalogusbeheer worden meegenomen bij het beoordelen van het inkoopproces of is het voldoende om de afhandeling van winkelwagens op te pakken? Tot hoever wordt het proces in het back-end ERP-systeem meegenomen?
• Bij het opstellen van een normenkader dient men zich te realiseren dat bestaande producten zoals filtersets met functiescheidingsconflicten die voor bijvoorbeeld ERP worden gebruikt, moeten worden aangepast. SRM gebruikt immers nieuwe transacties met daarbij andere objecten en organisatorische waarden. Tevens wordt op attributen geautoriseerd. Daarnaast kunnen er transacties zijn die worden gestuurd op basis van workflowtabellen.
• Bij het opstellen van een normenkader moet ook worden bedacht dat controleraamwerken niet een-op-een worden (her)gebruikt, aangezien rapportage en configuratie niet op dezelfde manier werken als in een ERP-omgeving. Voorbeelden van internecontrolemaatregelen zijn in de voorgaande paragraaf al uitgewerkt.
• Bij de opdrachtuitvoering dient men zich te realiseren dat bestaande tooling nog niet altijd geschikt is om over meerdere systemen te auditen (denk aan functiescheidingen over twee systemen heen) of om geautomatiseerde maatregelen te controleren anders dan in ERP. Men dient te bepalen welke SRM-audittools beschikbaar zijn en of deze tools zijn geïntegreerd met de standaardtooling voor het ERP-systeem.
• SRM is technisch gezien een volledig apart systeem met eigen infrastructuur, database, servers, etc. Dit betekent dat de algemene beheersingsmaatregelen hiervoor dienen te worden beoordeeld.
• De beoordeling van de SRM-omgeving zal organisatorisch op centraal en decentraal niveau worden uitgevoerd. Op centraal niveau wordt bijvoorbeeld de goedkeuringsworkflow ingericht en onderhouden en op decentraal niveau wordt de goedkeuring van een winkelwagen door de budgethouders gegeven. Gebaseerd op de wijze waarop SRM wordt ingezet en de hoeveelheid geprogrammeerde maatregelen zal mogelijk meer werk door een centraal auditteam kunnen worden uitgevoerd.

Conclusie

De komst van SRM heeft een grote impact gehad op het reguliere inkoopproces zoals we dat kennen in de klassieke R/3-omgeving. Dit betekent eveneens nieuwe vraagstukken rondom interne controle. Denk aan het maken van keuzen rondom de plaats in het inkoopproces waar risico’s worden afgedekt en de komst van systeemoverschrijdende bevoegdheidseisen. Als we de algemene tendens volgen dat steeds meer gebruik wordt gemaakt van geprogrammeerde maatregelen in plaats van eindgebruikercontroles, dan is de conclusie dat juist kennis van de techniek en mogelijkheden van de systemen onontbeerlijk is. Laat hier nu net de complexiteit van SRM zitten door het kunnen instellen van configuratie en autorisaties op meerdere plaatsen en via meerdere methoden. Het inrichten of beoordelen van controlemaatregelen in een dergelijke nieuwe inkoopomgeving vergt van de auditor of adviseur dat deze zich bewust is van de invloed van SRM op het inkoopproces.