Stopping Escalation

Thu Oct 30 13:29:15 EDT 2014

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 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20141030/b3563195/attachment.htm