Skip to Content

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…”

P.S

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.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Susan Keohan

    Hi Ronen,

    We don’t have GRC implemented, so I can’t comment on that aspect.  What I can say is that in my opinion, having users limited to decision tasks, and WF-BATCH making all the important changes to a document (since WF-BATCH is a restricted ID) has been tried and true.  The tracking of changes to documents shows clearly in the GOS, and I believe this methodology has satisfied many audits over the years.

    I hope that this will get some attention (perhaps from my fellow ASUG  volunteer and GRC expert http://scn.sap.com/people/gretchen.lindquist will weigh in.  It would certainly be a valuable discussion.

    Sue

    (0) 
  2. Modak Gupta

    Hi Ronen

    I would agree with you….just for the GRC reporting, we cannot start building new and complex solutions …AND that too for just ONE workflow!!!!

    I mean, their “demand: clearly reeks of “Oh Man! I will have to work a lot and standard GRC reports will not help”.

    Okay, the don’t want to read the workflow log….just because they hate it now (after a heated argument with the workflow team)….but creating a small report around table SWWWIHEAD would have given them Actual Agents of approvals!! That it! 🙂

    WF-BATCH approach is most secure and I would any-day go for your approach instead of creating hundreds of Release Strategies and changing so many things here and there!

    Regards,

    Modak

    (0) 
    1. Ronen Weisz Post author

      Hi Modak,

      First of all thanks for your support, but don’t judge the GRC team too harshly.

      The GRC authorization object –  authorization object checks at the user level, for example lets say a user has authorization to create a vendor and to create invoices to that vendor, the GRC will give a warning that this is a risk, It is not that simple to change that to an authorization object – workflow responsibility check. (authorization to create vendors and an assignment to a workflow responsibility)

      And you must remember that the workflow has substitutions which give users the option to delegate their approvals, which they can’t do in authorizations.

      The same problem exists for the logs, lets say we continue our example for the vendor, a small organization might have only one accountant, which has both authorizations, since he is the only one in the organization who can do that, in this case another part of the GRC will monitor the change documents for suspicious activity to see the accountant is not misusing this authority. changing this to a workflow decision log check is also not that simple.

      I agree with your statement that we don’t need to change the workflow for the GRC, and think that the GRC should learn to monitor the workflow, or relay on the standard workflow logs. If checks of that type should be developed, I am not sure it that can be done by a local GRC team.

      Ronen,

      (0) 
      1. Modak Gupta

        Hi Ronen

        Thanks for letting me see the other side of the coin (which i normally tend to miss out)!

        Agreed that GRC cannot develop their checks, they surely will have to use workarounds to automate the checking of workflow responsibilities/assignments and involve WF/ABAP guys to do some custom coding.

        regards,

        Modak

        (0) 
      2. Gretchen Lindquist

        Ronen,

        We are not live yet on GRC10 (SP12), so I may feel differently after the go live, but I think it is entirely reasonable to expect the GRC team to use the standard workflow log functionality. For us, the workflows in 10.0 are a big improvement over those in 5.3; there are still some improvements we would like to make to further automate request handling, but that is down the road. Right now, workflow monitoring is the least of our worries.

        Thanks, Sue, for bringing me into the discussion.

        Gretchen

        (0) 

Leave a Reply