PR Release WF - GRC ME54N

[Mark Pyc]

G'day Kjetil,

Some clients, such as this Govt example, have such complicated rules
regarding who should approve what based on who ordered, what was ordered
and where it was costed to that Release Codes are simply impractical both
from a definition, config and security allocation perspective.

Beyond this my statement around SoD is that security alone (Release Code
based or otherwise) can not prevent self approval. There are many instances
where someone needs to have the ability to key documents and approve
identical documents, just not approve the documents they keyed. I've heard
this quaintly referred to as "the four eyes principle".

WFs based on User Decision steps (where there is no authority check) with
WF-BATCH performing the Release is my preferred method where either such
requirement exists. Users have no access to the direct Release transactions
at all, and the WF agent determination logic, however it's implemented (be
it Resp Rules, BRF+, custom code) is the source of control, not allocation
of security Roles. The power of "excluded" agents provides more control
than Security ever can.

Regarding updating change logs to say something other than WF-BATCH, I push
back on this. WF-BATCH did perform the Release. If you want to know who was
involved in the approval review the WF log. This means when someone is
given "fire fighter" exceptional access to perform a manual release it's
obvious from the Change Logs.

Still keen to know if anyone does know of any issues of WF-BATCH PReq
Release....

Have fun,
Mark

On 24 August 2016 at 08:44, Kjetil Kilhavn <list.sap-wug at vettug.no> wrote:

> onsdag 17. august 2016 07.37.43 CEST skrev Mark Pyc:
> > I'm all for user decision, system update. It's the only practical way to
> > ensure true instance level SoD
>
> Could you be bothered to elaborate on that?
> I fail to see any advantages in terms of Segregation of Duties (assuming
> that
> is what you refer to) achieved by letting the user execute a user decision
> task as opposed to, in this case, a task that starts transaction ME54N?
> My point being that I don't see what you can do in your decision task that
> you
> couldn't just as well do with the task delivered by SAP. So, perhaps its
> just
> because I am not looking at it from the right perspective.
>
>
> > If anyone does know of issues of background release I'd love details.
> > I don't intend to hack around them, I'll be bitching to SAP to get them
> > resolved.
> It's not really an issue of background release, but when a user approves
> the
> release code in ME54N or ME28 an event terminates the work item. This means
> you can also hook up other workflows.
>
> Plus, if you are preventing business users from using ME28/ME54N:
> >From a user perspective: choice between ME28/ME54N  and workflow inbox.
> >From a solution design perspective: you can choose to not use workflow
> for some
> release codes.
> --
> Kjetil Kilhavn / Vettug AS (http://www.vettug.no)
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20160824/575031f0/attachment.html