In the first part of this post we looked at how finding a minimal set of people satisfying a list of SOD constraints is equivalent to finding the chromatic number of a graph, which is NP-complete. We then took a list of possible SOD conflicts and showed a simple transformation to a graph form which can then be further analyzed with standard mathematical programs like Matlab or Mathematica.
But these were toy examples. I therefore take a real example by doing an analysis of the standard rulebook delivered with SAP BusinessObjects Access Controls 5.3. When cleaned up from degenerate cases this rulebook contains 183 risks. Transforming this rulebook into a graph structure (GraphML) and visualizing it with the excellent yED program yields following structure (see image). Attention: The colors in this image are just for aesthetics, they do not correspond to the vertex coloring we will apply later.
I spoke in the last post about a randomized algorithm. Unfortunately I cannot find it anymore, so we will use instead a greedy heuristic algorithm for vertex coloring by Brelaz. Running this algorithm loose on our data gives a results of 5. We theoretically just need 5 people to comply with all the Segregation of Duties constraints.
Amazing isn’t it? Imagine all the discussions we had with clients and auditors along the lines of: ” We would need 100s of people to comply with all SOD constraints”. And 5 isn’t an optimal solution, it is just a heuristic solution we found in a short timeframe. Maybe there is a solution with 4, but it would take eventually too much time to find it.
So, if it takes only 5 people, then also small branches could implement it? Well, it is not so easy. We will look at some of the solutions and realize that while theoretically possible, it doesn’t make sometimes sense from an organizational theory perspective. Imagine putting an ad on a newspaper for following skills: “Looking for excellent candidate with know-how in SAP Development, Month-end closing, Accounts Receivables clerk experience”. Again, this dreaded gap between the theory and the doable!
But out of curiosity lets take a look at 2 areas from the analysis: Procure-To-Pay (P2P) and Order-To-Cash (O2C). In the attached images I have listed the different functional groups and we have given a color. In O2C for example we would need at least 4 people to satisfy all SOD constraints. In P2P we would need at least 5.
Other things to consider:
- We ran the algorithm globally on the SOD list, but you could also be interested only on running it inside Finance or Procure-To-Pay. That might yeld a globally less optimal solution but might be more suitable to how companies are traditionally organized.
- Stability of the solution: if the SOD list gets changed frequently then this could completely change the results of the analysis. That means that by just changing 2 or 3 SOD constraints we could have a completely different grouping of the functions. Fortunately sod lists do not change so frequently.
- Organizational constraints 1: companies always need “backups”. Someone is missing or sick or on travel. Work has to continue and this could easily double the minimum number of people required.
- Organizational constraints 2: Languages.. problem is often found in large Shared Service Centers. If serving multiple countries with diverse languages, SSC tend to organize as much around countries than processes. This creates a second dimension of complexity and can easily undermine SOD requirements out of practical needs.
Now you have a number of discussion points for the next round with your auditors on Segregation of Duties. You can:
- Mathematically show that your small branches may not have enough people to comply with their requirements. And therefore there are no other possibilities than use mitigating controls.
- That parts of the SOD discussion is, even in its static and simplified form, NP -complete. And considering that aour organization is a living entity with ever-changing processes and organization, it is even more complex.
- Analyze your SOD list for some insights about how you split up the responsibilities inside processes.
In a next post I will talk about a possible usage of these ideas at small companies, called ColorSOD™.