In one of the organizations I worked for the internal auditor wrote a nice 40 pages long document about how one of the approval levels in the purchasing release strategy wasn’t secure enough, simply too many people had authorizations to one of the approval codes.
This caused two reaction, the first “wow, the internal auditor guys really know what they are doing” the second was a bit of desperation from the purchasing team, making a lot of new approver codes will solve the authorization problem, but will also cause a lot (let’s say hundreds) of new release strategies, which will be a nightmare to maintain.
Well, they thought, maybe we will give the workflow team a chance to solve this; they have wanted to change the workflow process to a decision task one for a long time, let’s give them a try.
So they did, we changed the workflow to a decision task based workflow, built a few complex rules to find the right approvers, and let the workflow approve the release strategy in the background so no one will have authorization to the release strategy except the WF-BATCH user.
Now the authorization problem was solved, the users had a nice decision task to approve the workflow by, the purchasing team didn’t have to build new release strategies and the authorization team had actually less work to do. Everybody should be happy, right? Wrong!
Now enter the stage the GRC team saying: “what have you done? Our system authorization checks monitor authorization objects but now the authorizations are meaningless and the workflow rules are the real authorization. Our log checks monitor change documents but now all of them are written by WF-BATCH!”
Well we said: “sure the workflow rules are not authorizations but they are secure enough, the users can’t bypass them and if you want to see them simply look at OOCU_RESP which is much easier to read then authorizations, and although the GRC can read change documents logs, when it comes to purchasing release strategies any user trying to read them will have a lot of problems since they are written as: user A changed the release strategy status from XXX to XXXX, the workflow log is much clearer!”
This deteriorated to a few hours long argument at the project manager’s desk with the workflow team on one side of the table and the GRC one on the other side shouting arguments and technical expressions one at the other. The project manager’s solution to this was a simple one, since we seemed to be at a stalemate, “Who was around longer?” well, I said: “The SAP workflow has been around for decades, the SAP GRC only a few years…”
The project manger decision was to leave the workflow as it is, and to send the GRC team to find a way to monitor the workflow. To the best of my understanding there is no standard way for the GRC to monitor workflow rules or logs. If anyone has faced a similar problem I would be glad to hear of it.