Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member181875
Contributor
0 Kudos
S e c t i o n   1:   The distinction up front Forum anguish column:
Dear auntie BPX,I want my workitem to be persistently present in my SAP inbox even after execution. This is a special requirement ... to enable the responsible agent to act on the task ...till the dead line.. Debabrata
Three hours later...
Dear troubledIt a very special requirement :-), 1. You can... 2. ...You can... 3. If you’re on release 4.7/WAS 6.20 or higher, you could ... e.t.c. Morten
This is one great thread. Not only does Debabrata ask a good question, and Morten gave a 100% complete answer - but it is the chance to look at the difference between the workflow engineering and the business process expert.  It's about how's and why's. >>>It a very special requirement 🙂Morten knew the 'how' and that's saved some customer somewhere perhaps even weeks of development. SAP's workflow deals with it.  But what about the why? There's a million and one possibilities and I'm guessing here in the hopes that Nebrata will give us the answer later...  One possible explanation: A not-so-uncommon requirement is to have process observers checking/monitoring the progress of one workflow instance as it proceeds. Maybe adding attachments or adding ad hoc steps up-stream or simply checking it doesn't got stuck with someone who's forgotten to maintain their substitute. The observer basically nudges the process on it's way if it looks like it's running into trouble or not leading to the outcome the line-of-business owner wants.  Technically, you can provide this feature by adding an observer to the process or triggering a monitoring-process that starts when the main process starts.  When the observer executes the monitoring workitem (task) the workflow log is displayed and the observer can take any of the actions described above.  Once the main process finishes, there's no longer a need to monitor it and the workitem should disappear automatically from that observing-persons inbox.  There are a number of questions that the business process expert will need to answer even though the workflow tool can provide this solution. Should the observer be able to complete the monitoring task before the main process is completed? After all the log, as Morten explained, is still available in the outbox (also in the portal/universal worklist).  Do we really want this monitoring task to appear in the tasklist along with the other real tasks that this observer must do? In other words is it unnecessary clutter? Is it a task or is it really a notification? What's the difference between the two?  My theory is that these questions are 'why' questions which a business process expert will be able to answer along with thousands of others along these lines. There is no simple answer to this - it depends. It depends on the type of industry, the type of the process and business area, and the way the company prefers to run its processes. But the customer will lose money and efficiency if the answer is wrong.  It is the business process expert that can answer this. The 'why' and 'whether'.  The 'how' is probably best answered in a technical forum. Workflow seems to be dealt with in the Business Process Management forum, BPEL processes in the XI forum and Guided Procedures in the CAF forum.  Nevertheless, a good BPeXpert will have knowledge of the basic capabilities offered by the tools being used (enough to know what they can do) - otherwise the expert will not be able to estimate the time or cost of implementing the suggestion (custom development versus setting a flag - it's worth investing an hour's time to find out). This skill is not a must - but it helps.  Similarly, the workflow engineer will with time have acquired a very good business process expertise in particular areas and could well be able to answer this too (but probably not other questions at a higher level of granularity- such as whether to outsource a process or not).  So there's an overlap.  Now I admit that most of a business process expert's skills are communication, experience and judgement because that's what's going to make or break a project. But assuming the basic skills are there and the process works as designed. Well, if the human interface is ignored you'll lose efficiency and money. That is wastage. So even in Debabrata's simple case the 'why' is worthy of an answer.  As I said at the beginning - I like this thread - it serves to show the distinction between workflow engineering and BPX, but also where they overlap.  By the way, a common complaint at the last teched is that so-called business process experts call in the workflow engineers far too late. It is common knowledge that involving the BPM engineer up-front as early as possible will save no end of time in the project phase and avoid disasters after the go-live. Workflow engineering is not simply configuration - it's a case of handing on the baton rather than dropping it somewhere on the running track in the hopes that someone will find it and interpret which direction you were running in... S e c t i o n   2:   The round tripThe previous section was a plagiarism of my own post in the forum which Mark asked to be converted into a blog. But I needed to include another aspect. And here it is.  A good Business Process Expert, a very good one, will not leave his or her best laid plans to chance. She knows that the rigors of going live on time are enough to whittle away at even the best intent of the BPX. And a chance conversation at the Amsterdam Teched with Phil K. (looking forward to your blog, Phil) reminded me of how disasterous an implementation can be (Phil took over once the mess was clear).   I'm just guessing here, that the Business Process Expert (not Phil) in this case did not have any idea of what BPM tools can provide and sort of mashed together something that could never work. The problem was, he didn't include any plans for monitoring this.  So a good Business Process Expert, a very good one, will not leave until there are real plans on how to monitor the process that has been engineered to check that it really is doing it's job. Sounds simple but this is often overlooked.  In a nutshell. Any business process churns out value. The more often it runs, the more value you can churn out. So you must put in a mechanism to track this value, track the KPIs.  Now there are standard tools and reports in SAP NetWeaver for monitoring processes generically. How often, how long, how much wait time. So the example from section one can be monitored and if the mechanism chosen is suspected of being improvable then you can make a snapshot of the process metrics before the improvement and one afterwards to make sure that it was a success (and make sure it's you that gets called back for future projects). But the really interesting stuff is when you combine these generic process metrics with other factors to enable you to discriminate between situations.  Here are some scenarios:  How much time is wasted on processes that do not reach a   successful conclusion? E.g. How much human effort is involved in creating a brochure that is not published in time? Was this related to the departments involved? E.g. brochures for new product releases meet the target more often than those produced for trade shows. Is this because the lead-time calculations are too optimistic? Is this because of delays in one step of the process? Is this because of missing context information in this step? Why does it take longer to produce a brochure in location X compared with location Y?  Now the business process expert does not have to produce such reports. But he or she should be aware that using SAP's BI /BPM integration such reports are possible. You mash-up  the process information with the organizational management (HR) information with the business context information and slice-and-dice the results as you see fit. In the case of SAP NetWeaver the key to doing this is BI Content Package for BPM delivered last year (prior to that this was possible with WIS). And the business process expert can produce rough mockups (whiteboard/pencil...) of what such a report or analytics dashboard should look like.  But once done, once this is put on the project plan for implementation, the benefits are immediate. You've shown your worth.  I hope this shows the value of the round-trip and that fact that some business process experts not only have communication, experience and judgement but also the confidence and foresight to put technology in place to make sure the client can pinpoint the spot to show the value of their work at any time in the live operations - long after they've moved on to other pastures.  And I hope this will spurn some of you to talk of your successes, irrespective of the tools used.      
1 Comment