Stopping Escalation

[Mike Pokraka]

Agree to limiting escalation and looking at BRF+
If a shorter term solution is needed, I would just fix a number of levels
similar to Mark's comment, one or two should be enough. Then you don't
have to maintain stop points.

Otherwise you could just extend the position or org unit infotype and add
a "Stop Escalation" boolean field.

Regards,
Mike


On Thu, October 30, 2014 5:29 pm, Edward Diehl wrote:
> Jocelyn,
> I wholeheartedly  agree with escalation being overused.  The big question
> is "What am I supposed to do with all of these?"
>
> Ed Diehl
> "Success consists of going from failure to failure without loss of
> enthusiasm."
>
>
>
> Date: Thu, 30 Oct 2014 11:17:42 -0400
> From: claude.bourque at rcmp-grc.gc.ca
> To: sap-wug at mit.edu
> Subject: Re: Stopping Escalation
>
>
>
>
>
> Thanks everyone for the suggestions and Jocelyn for the words of wisdom.
>
> I will seriously look at the BRFPlus suggestion. I'm also looking at
> possibly using IT1010 (Authorities and Resources) to set an attribute
> similar to what Mark mentioned.
>
> Cheers
>
> Claude
>
>>>> Mark Pyc <mark.pyc at gmail.com> 2014/10/29 5:23 PM >>>
>
> I second Jocelyn's concerns around escalations. At my current site after
> much discussion I have managed to convince them to restrict to a single
> level of escalation. Once an item is sitting with both the original agent
> and their line manager further inaction is likely to be for genuine
> business reasons rather than laziness.
>
>
> Having said that we are restricting escalation at all to the very highest
> level. In our case we have attributes maintained against the positions
> though custom object and relationships and so we can assess these rather
> than use a Z table or BRF+ mapping.
>
>
> Have fun,
> Mark
>
> Sent from my iPhone
>
> On 30 Oct 2014, at 8:07 am, Dart, Jocelyn <jocelyn.dart at sap.com> wrote:
>
>
>
>
> Hi Claude
> I'd second Ed & also point out that we have a chapter on BRFplus & related
> DSM (rule governance & hot deployment to any SAP system in the landscape)
> in the recently released edition 3 of Practical Workflow for SAP book.
>
>
> One option for instance would be to use a decision table (aka a
> spreadsheet like rule) to hold the position id per system/client.
>
>
> Btw - to both of you -  it's quite likely that you already have BRFplus
> available in your system as it's part of the NetWeaver platform. A quick
> test is to try going to transaction BRFplus - its webdynpro so will fire
> up a web browser.  There's also a bunch of tutorials blogs & avid
> fans/practicioners in the Business Rules Management space on SCN
>
>
> Also in my very personal opinion the true business value of escalation
> should be challenged in any workflow design. Too often I see it placed on
> almost by default & the net result is too often to add stress without any
> improvement in productivity or efficiency.  But like I said that's my
> personal view #justsayin
>
>
> Cheers
> Jocelyn
>
> Sent from my iPhone with many apologies for the spelling, grammar and any
> other deficiencies
>
> On 30 Oct 2014, at 6:38 am, "Edward Diehl" <edwarddiehl at hotmail.com>
> wrote:
>
>
>
>
>
>
> Hi Claude,
> This, ultimately, might not be much different than the z-table approach,
> but I just finished ( a while ago) reading through the SAP-PRESS
> publication for BRF+.  It is different from BRF as the + version is in the
> ABAP stack.
>
> If you're not looking for a quick solution, you might want to take a look
> at it.  I don't know what release you're on, but I think it is generally
> available by now.
>
> It supports several different rule structures and the resulting tables are
> available to the business process owners.  The tables are read by function
> calls.
>
> Would love to get a chance to use this myself.
>
> Ed Diehl
> "Success consists of going from failure to failure without loss of
> enthusiasm."
>
>
>
>
>
>
> Date: Wed, 29 Oct 2014 13:44:32 -0400
> From: claude.bourque at rcmp-grc.gc.ca
> To: sap-wug at mit.edu
> Subject: Stopping Escalation
>
>
> Greetings WUGgers
>
> The following is more to start a discussion that to get an answer to a
> specific technical problem. So, here it goes.
>
> I've been dealing with this for about 10 years and I'm wondering if
> there's a better way.
>
> In a lot of workflows that I've built, the business wants escalation to
> stop once it reaches a certain position in the hierarchy. For example,
> don't go higher than the CFAO or the Director of HR. Or, if the user
> requestion leave, travel, training, etc is the CFO/CFAO then the approval
> is different than for other users.
>
> I've used a variety of ways to do this including the following
>
> 1. Hard-code the position(s) within the workflow (bad, very bad)
> 2. Hard-code the position(s) within an ABAP method (still very bad)
> 2. Use a Z-table to store the position(s) in question and read that table
> from WF
> 3. Use table TVARVC (or TVARV)
> 4. I saw a customer once use table T77S0 to save the position(s).
>
> Are there other significantly different options out there?
>
> The main dilemma is that the CFO/CFAO position is most likely NOT the same
> in DEV, QA and Prod.
>
> Thanks.
>
> Cheers
>
> Claude
> Workflow Consultant RCMP
> _______________________________________________ SAP-WUG mailing list
> SAP-WUG at mit.edu http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>