+31(0)6 21886161info@processminery.com

In veel administratieve processen is het vereist dat verschillende stappen in het proces worden uitgevoerd door verschillende medewerkers, het “vier ogen” principe. Een goed voorbeeld van een proces waarbij dit geldt is het inkoop proces. Het is bijvoorbeeld niet gewenst dat de medewerker die de inkooporder invoert ook de medewerker is die de ontvangst van de goederen inboekt.

Anne Rozinat heeft eerder al een artikel geschreven over het gebruik van process mining in Disco bij het controleren op functiescheidingsconflicten. Zie: https://fluxicon.com/blog/2014/03/how-to-check-segregation-of-duties-with-disco/

In dit artikel zullen we zien hoe deze controles uitgevoerd kunnen worden op een dataset die afkomstig is van de Oracle EBS Release 12.1.3 Vision omgeving. We maken gebruik van een dataset waarbij als case ID het inkooporder distributie ID is gebruikt. Het inkooporder distributie ID is het laagste niveau van een inkooporder in Oracle EBS.

Deze dataset bevat alle stappen in het inkoop proces in Oracle EBS gerelateerd aan het inkooporder distributie ID: bestelaanvragen, inkooporders, ontvangsten en facturen.

Importeer de dataset in Disco

Zodra we de event log in Disco openen zien we de volgende kolommen:

  • Case ID: het inkooporder distributie ID in Oracle Inkoop. We markeren deze kolom als “Case”
  • Activity: dit is de activiteit die heeft plaatsgevonden. We markeren deze kolom als “Activity”
  • Time Stamp: dit is de datum en het tijdstip waarop de activiteit heeft plaatsgevonden of is gestart. We markeren deze kolom als “Timestamp”
  • End Date: dit is de datum en het tijdstip waarop de activiteit beëindigd is. We kunnen zien dat deze kolom alleen is gevuld indien in Oracle EBS de eind datum bepaald kan worden. We markeren deze kolom eveneens als “Timestamp”. Disco zal automatisch de vroegste datum als start datum gebruiken en de laatste datum als eind datum voor de activiteit.
  • Resource ID: dit is het ID van de gebruiker in Oracle die de activiteit heeft uitgevoerd. We markeren deze kolom als “Resource”
  • User name: dit is gebruikersnaam van de gebruiker in Oracle die de activiteit heeft uitgevoerd. We kunnen deze kolom eveneens als “Resource” markeren. Hierdoor zal Disco het gebruikers ID en de gebruikersnaam samenvoegen en tonen als “Resource”.
  • Event ID: dit is het ID van de activiteit in de bron tabel in Oracle. We markeren deze kolom als “Other” attribuut en met de resterende kolommen zullen we hetzelfde doen.

Het event log heeft de volgende case specifieke attributen:

  • Org ID: het ID van de bewerkingseenheid (Operating Unit) in Oracle. We markeren deze kolom als “Other”.
  • Operating Unit: de naam van de bewerkingseenheid in Oracle. We markeren deze kolom als “Other”.
  • PO Number: het inkooporder nummer in Oracle Inkoop. We kunnen dit inkooporder nummer gebruiken om de inkooporder in Oracle EBS op te zoeken in het werkcentrum voor de inkoper of het inkooporder overzicht scherm.

Het event log uit de Vision omgeving heeft een beperkt aantal additionele, activiteit specifieke, attributen. Deze attributen zijn allemaal gerelateerd aan de activiteit “Create Purchase Order Distribution” en we markeren deze allemaal als “Other”:

  • Buyer: de inkoper die is ingevoerd in de koptekst van de inkooporder
  • Linetype: de regelsoort van de inkooporder, zoals Goederen of Diensten
  • PO Category: in inkoop categorie van de inkooporder regel. Deze inkoop categorie geeft aan welke soort goederen of diensten er worden ingekocht. In het geval van de Vision omgeving bestaat de inkoop categorie uit twee segmenten.
  • Supplier: de leverancier die is ingevoerd op de inkooporder koptekst.
  • Item description: de omschrijving van de inkooporder regel.

Als we alle kolommen gemarkeerd hebben kunnen we de data importeren. Laten we even nader bekijken wat we in Disco zien zodra de data geimporteerd is.

Met de “Activities” slider helemaal bovenaan zien we een proces model met alle verschillende activiteiten uit het event log.

Door het grote aantal verschillende activiteiten is het proces model nog niet heel eenvoudig om te begrijpen.

Filters toepassen

We klikken op filter en we zien de verschillende activiteiten die voorkomen in het event log. Indien we een specifiek functiescheidingsconflict willen controleren kunnen we het aantal activiteiten dat getoond wordt beperken tot alleen die twee activiteiten die van toepassing zijn voor het mogelijke functiescheidingsconflict. In ons geval zijn dat de activiteiten “Create Purchase Order Distribution” en “Receipt Receive”.

Dit resulteert in een proces model met alleen die twee activiteiten. De aantallen geven het aantal keer aan dat een activiteit heeft plaatsgevonden in het event log. Hetzelfde geldt voor de aantallen bij de paden.

Maar we zijn alleen geïnteresseerd in de cases waarbij de gebruiker die de inkooporder heeft ingevoerd ook de gebruiker is die de ontvangst heeft ingevoerd. We passen dus een extra filter toe. We selecteren het “Follower” filter en selecteren dat “Create Purchase Order Distribution” is “eventually followed” door “Receipt Receive” en dat “the same value” of “Resource” is vereist.

Het resultaat is het volgende proces model:

Dit geeft aan dat er 46033 inkooporder distributies zijn waarbij de gebruiker die deze heeft ingevoerd ook de gebruiker is die de ontvangst heeft ingevoerd. Nu willen we graag weten wie al deze inkooporders en ontvangsten heeft ingevoerd. We kunnen dit zien zodra we het tabblad “Statistics” selecteren en vervolgens “Resource”.

We kunnen zien dat in totaal 183 gebruikers minimaal 1 keer zowel de inkooporder als de ontvangst hebben ingevoerd. De gebruiker SSCNEWALL is koploper. Laten we nu de inkooporder nader bekijken waarbij SSCNEWALL betrokken was. We voegen een extra filter toe die alle de activiteiten selecteert waarbij SSCNEWALL een resource is.

In het Statistics tabblad kunnen we de waarden van de verschillende attributen zien, zoals de bewerkingseenheid, de inkoper, de leverancier, de inkoop categorie en de omschrijving.

Indien we de details van de individuele cases willen bekijken kunnen we het “Cases” tabblad gebruiken.

In dit voorbeeld zien we geen goede reden waarom deze gebruiker zowel de inkooporder als de ontvangst zou moeten hebben ingevoerd. Dus dit vereist nader onderzoek. We verwijderen het filter dat alleen de twee specifieke activiteiten selecteert om meer inzicht te krijgen in het volledige proces dat voor deze inkooporders is doorlopen.

Hier zien we iets vreemds. We zouden verwachten dat er voor alle inkooporders een bestelaanvraag is maar we zien dat vrijwel alle inkooporders niet gekoppeld zijn aan een bestelaanvraag. We zien ook dat de inkooporders allemaal zijn goedgekeurd, zijn ontvangen en een factuur hebben. Laten we eens kijken of de gebruiker SSCNEWALL nog andere activiteiten heeft uitgevoerd in dit proces. We voegen nog een extra “Follower” filter toe die er voor zorgt dat we alleen de cases zien waarbij SSCNEWALL ook de factuur heeft ingevoerd.

Het resultaat is dat zichtbaar wordt dat de gebruiker SSCNEWALL ook de facturen heeft ingevoerd. Dit toont overduidelijk aan dat de functiescheidingscontrole hier niet heeft gefunctioneerd en verdere actie is vereist om dit in de toekomst te voorkomen.

Marcel Koolwijk

Comments are closed.