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

In many administrative processes there is a requirement that different actions are performed by different persons. A typical example of such process is the procurement process. For example you do not want the person who is entering the purchase order is the same person that is entering the receipt of the goods. 

Anne Rozinat already described the usage of Disco for checking segregation of duties with the demo dataset in Disco. See https://fluxicon.com/blog/2014/03/how-to-check-segregation-of-duties-with-disco/

We will see how we can perform these checks with a dataset from the Oracle EBS Release 12.1.3 Vision instance. We use a data set with the purchase order distribution ID as case ID. The purchase order distribution ID is the lowest level of the Purchase Order in Oracle.

This dataset contains all the steps in the procurement process in Oracle EBS related to the purchase order distribution ID: requisitions, purchase orders, receipts and invoices.

Import the dataset in Disco

When we open the event log in Disco we see the following columns

  • Case ID: the purchase order distribution ID in Oracle Purchasing. We mark this column as “Case”
  • Activity: this is the activity that has taken place. We mark this column as “Activity”
  • Time Stamp: this is the date and time when the activity has taken place or has started. We mark this column as “Timestamp”
  • End Date: this is the date and time when the activity has been completed. We can see that this column is only populated for activities where the end date can be determined in Oracle. We mark this column for “Timestamp” as well. Disco will use the ealiest timestamp as start and the latest as end timestamp for the activity.
  • Resource ID: this is the id from the user in Oracle who performed the activity. We mark this column as “Resource”
  • User name: this is the user name of the user in Oracle who performed the activity. We can mark this column as “Resource” as well so that Disco will concatenate both the user id and the user name as the resource in Disco. 
  • Event ID: this is the id of the activity in the source table in Oracle. We mark this column as “Other” attribute and will do the same for all remaining columns

The event log has the following case attributes:

  • Org ID: the id of the operating unit in Oracle. We mark this column as “Other”.
  • Operating Unit: the name of the Operating Unit in Oracle. We mark this column as “Other”.
  • PO Number: the Purchase Number in Oracle Purchasing. We can use the Purchase Order number to query the purchase order in the Buyer Work Center or the Purchase Order Summary form.

The event log from the Vision instance only has a limited number of additional, activity specific, attributes. These attributes are all related to the “Create Purchase Order Distribution” activity and we mark these all as “Other”:

  • Buyer: the buyer who is entered on the purchase order header.
  • Linetype: the purchase order line type, like Goods or Services
  • PO Category: the purchasing category from the order line, indicating what category of goods or services are being purchased. In the Vision instance the category contains out of two segments.
  • Supplier: the supplier on the purchase order header
  • Item description: the description from the purchase order line.

Now that we have marked all the columned we can import the data. Let’s have a closer look at what we see in Disco once we have imported the data.

With the “Activities” slider at the top we see the process map with all activities from the event log.

Because of the number of different activities this is not very easy to understand.

Apply filters

We click on filter and we see what different activities are in the event log. If we want to check a specific segregation of duties conflict we can limit the number of activities to only those two that are part of the check: “Create Purchase Order Distribution” and “Receipt Receive”.

This results in a process map with only those two activities. The number indicates the number of times each activity has taken place in the event log. The same applies to the paths.

But we are only interested in the case where the user who entered the purchase order is the same as the user who entered the receipt. So we apply an additional filter. We select the “Follower” filter and select that “Create Purchase Order Distribution” is “eventually followed” by “Receipt Receive” and require “the same value” of “Resource”.

The result is the following process map:

This indicates that there are 46033 purchase order distributions where the user who entered the purchase order is the same as the user who entered the receipt. We now want to know who entered all these purchase orders and receipts. We can see this when we select the “Statistics” tab and select “Resource”.

We see that in total 183 users entered at least once both the purchase order and the receipt. The user SSCNEWALL is on top of the list. Now let’s have a closer look at the purchase orders where SSCNEWALL was involved. We apply a filter that selects only cases where SSCNEWALL is a resource.

We can see in the Statistics tab the values for the different attributes, like Operating Unit, Buyer, Supplier, PO Category and Item description.

If we want to see the individual case we use the “Cases” tab.

In this example we do not see a good reason why this user should be allowed to enter both the purchase order and the receipt so this is a candidate for further investigation. We remove the filter that only selected the two activities to get some more information about the complete process.

We see something strange here. We would expect that all the purchase orders are initiated by a requisition but here we see that almost all purchase orders are not related to a requisition. We also see that all the purchase orders are approved, are received and have an invoice. Let’s see if user SSCNEWALL has performed any of the other activities in this process as well. We apply an additional “Follower” filter to get only the cases where SSCNEWALL is also the user who entered the invoice.

The result is that user SSCNEWALL is also the user who entered the invoice. This really shows that the segregation of duties controls did not work in these cases and action needs to be taken to prevent this in future.

Marcel Koolwijk

Comments are closed.