What not to WF

[keohanster]

In susan.keohan/blog/2010/11/21/what-not-to-wf of this series, I gave a few (opinionated) tips about what kinds of requests might not be appropriate scenarios for SAP Workflow. 

In this entry, I would like to focus on what has been called 'Workflow for bickering children'. 

Of course, this scenario has not occurred in any real world application - not to my knowledge at least.

Those of you with two or more kids can easily picture the scenario (perhaps it also works if you have multiple pets).  You are snowed in and rapidly approaching 'The Shining' mindset - and your kids have decided that this is a great time to test your remaining patience.

Child A - That piece of cake is mine.

Child B - No it's not, it's mine!

Child A - It's not your cake, it's my cake. Na-ne Na-ne foo foo!

Okay, well you get the idea.  What I am really talking about here is when you have multiple business groups who each own part of a business process - and they can't seem to agree on how that process should flow.  There is absolutely nothing wrong with this!  This is how you get to a good, solid design.

When someone says 'Well, if Org A rejects it, send it back to Org B' and then someone else says 'And if Org B rejects it, send it back to Org A' you have just achieved Workflow for Bickering Children.

I am not saying that each organization is not acting in the best interests of their organization when they reject something, and I really don't mean to imply that these folks are children.  What I am saying is that, at some point in some processes, you may be better off to let the two (or more) parties communicate the old-fashioned way and work out their differences.  To model a workflow based on the back-and-forth-and-back-and-forth is going to be:

a) Time consuming

b) Frustrating

c) Hard to test to the n-th degree

d) Enabling this behavior in future processes too!

Of course, you can model the approval to occur inside a loop and just keep routing the object back and forth.  SAP Workflow is flexible enough to allow you to do this!   And there may very well be valid reasons for keeping something moving back and forth between groups of agents.   But I encourage you, the SAP Workflow Developer, as the objective person, to help sort through what is really happening in this process.  Helping your business colleagues avoid continuous and non-productive back-and-forth is also the job of a good SAP Workflow architect.   An automated process can only do so much. 

And if you end up solving the bickering children issue, please do share.