Stopping Escalation

[Mark Pyc]

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