Frequently Asked Questions about SAP's WebFlow Engine
(See also FAQ Workflow Techniques )
None! The name 'WebFlow' was estabilished during the internet boom to highlight the internet features of SAP Business Workflow. But nowadays, the internet is no longer exotic and it makes no sense to focus on a User Interface in the Web Browser (e.g. the Universal Worklist iView in SAP Enterprise Portal user package) or an internet-based protocol such as wf-xml. So WebFlow is synonymous with SAP Business Workflow and vice versa.
Yes, "Practical Workflow for SAP" by Rickayzen, Dart, Brennecke and Schneider. Available from SAP press at the end of July. A german translation of this workflow book is also available directly from Galileo-Press, the publisher.
Feedback from user groups emphasizes that although the competitive advantage gained by using workflow eclipses the financial savings, it is the financial savings that are the deciding factor when obtaining support from senior management. Projects getting the blessing at the CEO level are much easier to manage, and far more likely to reach their goal within the project time frame. So plan well, and don't neglect the business case.
Because the following questions deal with the financial case in more detail, this section will finish by listing the competitive advantages.
The quality of the process is assured by pushing the relevant information together with links to related transactions directly to the user. Managers don't have the time to search for information so give them what they need to reach the correct decision.
Cycle time is reduced by pushing the process directly to the users. The users receive notification of a task immediately and can even be prioritized by the system.
The tasks are performed consistently and diligently by the users. The workflow system pushes all the necessary information needed to perform a task, including a clear description of what has to be done, how to do it and the impact this task has on the business process for your company. At any time, the user can check the list of tasks pending and determine at a glance which are the important tasks, and which tasks can be completed the next day without any negative impact.
The process instance is transparent. Any user can check at any time how far the process has progressed and which stage the process has reached. For example the call center can immediately see the status of a purchase order, an employee requisitioning a purchase would see at a glance if a colleague has been sitting on it for too long, the ad hoc notes made when approving an engineering change request are visible long after the request has gone into production.
The process is flexible, allowing it to be changed on the fly without retraining everyone involved. The description accompanying the change takes care of on-the-fly process improvements.
Deadline handing ensures that users perform the tasks within the time planned. Escalation measures ensure that the failure to meet a deadline can be corrected by other means.
Intelligent reporting highlights the weaknesses of a process. Often there is a simple cure to such weaknesses such as reeducating the users involved in the bottleneck or providing additional information (automatically). The difficulty of a non-automated process is identifying such bottlenecks.
The process definition is transparent. You can see at a glance how the process works and who will be selected to perform the different tasks. Think of the workflow as the process book. If you can spot the pattern and define the process without headaches, you can create a workflow definition effortlessly. However, don't forget that if a company has business processes that are erratic and lack a consistent pattern, the company is very likely to be losing a lot of money in terms of lost contracts, labor intensive administration and low customer confidence. It is my personal opinion that automating exactly this type of processes will yield the best returns, but only if you limit yourself to automating the basic skeleton of the process first. Don't get bogged down in the detailed exception handling. That can be done in the next phase once you've checked the process statistics and determined which exceptions are worth tackling.
As with most software the reasons for automating business processes are primarily to increase the competitive edge of your company and to cut costs. Although the increase in competitively gained by radically reducing process times is by far the most insignificant gain from workflow, you should not ignore the cost savings. The cost saving calculations are needed by upper management in order to approve workflow projects. This upper management signature will be very useful in different phases of the project and cannot be underestimated.
Calculate the cost of the manual process in terms of man hours. Don't neglect the time spent gathering information. Ask the following questions:
Is the user forced to log into different systems, or scan through printed documentation....?
Does a skilled user spend time on parts of a task, where less skilled (less expensive) user could do the groundwork? I.e. Can a single task be split into skilled and unskilled tasks to free the skilled worker for work where his/her skills are really needed?
Is time spent researching the progress of a process (usually done by someone not involved in the process directly)?
Is time spent determining who to give the task to next?
Probably the most significant cost will the be the cost of failure?
How often does the process fail?
What is the real cost of failure? Loss of a contract? Loss of a customer? Law suit?
If the failure can be rectified, how labor intensive is it?
A manually processed accounts payable invoice will cost about 25 USD. After workflow enabling about 15 USD (one example based on customer feedback from a user group meeting).
A traditional paper based approval process involving three people will typically take seven days to complete. The automated process will take one day (results based on customer feedback).
Based on customer feedback from the various regional users groups, the main strengths of SAP Business Workflow are:
Robust production workflow system, (upgrade continuity with the rest of the SAP system, versioning, scalability, no gluing....)
Standard workflow templates delivered by SAP can be used out-of-the-box or tweaked to deliver the optimum business process for your company. Workflows can be up and running including training in under a day (thanks to the knowledgeware delivered as part of the template packet).
Seamlessly integrated into the SAP environment, be it R/3, Business to Business Procurement, CRM, APO, mySAP.com.... Examples of integration are:
Business Reporting (WIS),
Context sensitive availability at any time through the system menu (available anytime, anywhere)
More and more standard SAP functionality is being provided by using SAP Business Workflow so your homegrown workflows fit the landscape exactly,
More and more workflow functionality is available directly within the SAP transaction or Web MiniApp.
WebFlow is becoming more and more important because companies are no longer being judged by their own performance but by the combined performance of the company AND its partners. In other words it is not enough that the business processes within your company run smoothly and faster than your competitors. You have to ensure that the processes between you and your partners are also as fast, efficient and flexible as possible. WebFlow delivers this.
The users are informed by a work item which you may think of as being very like an e-mail. The difference is the work item contains intelligence and by executing the work item you will be taken to the form or SAP transaction that makes up the step in the workflow. This form or transaction could be a decision, a request for information or a request for confirmation that a particular task has been performed.
The work item is usually accompanied by a description of what has to be done, where to refer to when assistance is needed (help desk, intranet...) and a summary of information about the business object or process which enables the operator to attack the task immediately.
This work item can be received and executed in MS OutlookÒ, Lotus NotesÒ, mySAP Workflow MiniApp or the SAP integrated inbox. If this is not enough, the workflow system can transmit e-mail notifications directly to any mail system, informing the user of the need to log in to the SAP system to execute the task. The e-mail notification is done on a subscription basis so that users can de-subscribe from this service if they already check their work item inbox regularly.
Standard workflow reports exist which allow the administrator to check statistics such as the frequency and average duration of the workflow processes. However the real strength of the workflow reporting is that it allows reports to be configured which analyze the process statistics in combination with the data involved within the workflow process and the organizational units associated with the process. For example you can determine the average time invested in a failed contract renewal request, the time taken to create material masters in different plants or the frequency of rejected purchase requisitions on a department to department basis. Often, big reductions in cost or cycle time can be obtained without touching the workflow definitions. Reeducating a particular group of users or incorporating supplementary information in a work item description can often cause dramatic improvements on the cycle times of particularly critical subsets of the process. It is not unusual that this may have a big impact on specific products, plants or organizational units. This will show up in the WebFlow reporting in LIS or the Business Warehouse but it might not show up in traditional statistical workflow reporting. Even though the average time does not change significantly, the impact on costs and profit can be dramatic.
A work item is assigned to one or more users. Whoever reserves or executes the task first wins and the work item vanishes from the other users' inboxes. This eliminates the need to assign the user to one single user. I.e. No need for complicated algorithms to determine which single user will receive the work item and no need to worry about what will happen when one user is ill for the week (also taken care of by sophisticated substitution mechanisms which can be linked to the SAP organizational model).
Tasks can be assigned to an organizational unit but the strength of the workflow system is to enable business rules which select users according to the data being processed. For example, you might have one group of users associated with one quality notification type. The workflow can be configured to query the QM module directly to determine the users. You can define fallbacks using the default role associated with a task and allow agents to be specified on the fly by a supervisor.
Tasks can be assigned to office distribution lists which is useful when you want your users to subscribe or unsubscribe to a particular task. A typical use of this would be where you have a work rote or want to reduce user maintenance to an absolute minimum. The users subscribe or unsubscribe by joining or leaving an office distribution list (one mouse click).
This depends on your workflow definition. In the simplest case an e-mail is sent to another user by the system (typically your supervisor so watch out!). However in more sophisticated scenarios a missed deadline can redirect that path that the workflow takes. One customer uses deadlines to automatically make an approval if the deadline is missed (at about the eighth approval level!!!). This gives the user the chance to make rejections but does not force him/her to go into the system to approve the other 99.9% of the requests. In safety critical environments the workflow might trigger off preventative action when a deadline is missed or might put other processes on hold. There is no limit as to how you can use this functionality.
Many different types of deadlines can monitored. At the single workflow step level you can define deadlines which trigger when the work item has not completed within a certain time and other deadlines when no one starts working on the work item within a given time. You can specify the task deadline statically (e.g. 1 week) or dynamically (e.g. 1 week for material type A and 2 weeks for all the other materials). The offset can be related to the step (e.g. you have 1 week to complete this step) or related to the process (e.g. complete within 2 weeks of the complete process starting, irrespective of how long your colleagues have hogged the previous steps).
Last but not least, deadlines can be set for sub-processes, which is often more important than the deadline of a single step in a workflow.
This is one of the very cool features of SAP Business Workflow. You can usually navigate directly from the business object to check the workflow progress. For example, while viewing a purchase order you can select "workflow" from the system menu or toolbar and you will see a list of workflows related to the purchase order. Usually just one, but if you have created a few of your own and these have been triggered you will see the status of these too. And that is not all. You also see a simplified summary of all the steps that have taken place so far including who performed them, when they were executed and which ad hoc notes were attached.
Workflows can be triggered automatically by changes in the system or manually by an operator. Manually triggered workflows are good for processes that remedy a problem the operator has noticed or for dealing with a forms-based requests (E.g. my PC won't boot). Automatically triggered workflows are useful because the operator does not even have to be aware of the workflow's existence to trigger it. In addition to triggers embedded in transactions there are also generic triggering mechanisms such as a change in the status of a business object or a change in the HR data. Irrespective of how the workflow is triggered, it is linked to the business object as described in the previous answer and can be tracked easily. Because WebFlow is part of the basis system, this triggering is reliable and easy to implement.
Workflows may be triggered by events but this is not essential. The event-handling makes it easy to trigger workflows from transactions and system changes without you having to make modifications. If you are creating your own report or transaction which triggers a workflow, avoid events and trigger the workflow directly with the WAPI function call. This is particularly important when triggering a workflow from outside the SAP system. This method reduces flexibility (the workflow ID is hard-coded) but increases performance if this is an issue (we're talking about 50 000 work items a day here!).
Any exception handling workflows that are intended to be triggered manually can be triggered from the system menu when viewing the relevant transaction. The SAP system has the intelligence to suggest workflows that can be triggered manually based on the authorization of the operator and the context that the operator is working in. No additional customizing is needed here.
The most significant interface supported is the Wf-XML standard from the Workflow Management Coalition. This is an independent organization of which SAP is a funding member, along with most other major workflow vendors. The Wf-XML interface is based on XML and allows workflows from different vendors to communicate with each other. A detailed description of the interface is available on the WfMCs web site at www.wfmc.org. BPML is also supported for the XML representation of the workflow definition.
Wf-XML is the 'html' of process integration. Although a company is better off workflow enabling their system with SAP WebFlow when SAP software is used anywhere within the process, a collaborative process can take place between partners using different software platforms employing different workflow systems. To support SAP customers in this situation, WebFlow offers the open interface Wf-XML. This allows Business Processes enabled using different tools to communicate and control each other. Any workflow tool offering this interface can connect up with other tools that also offer this interface.
Wf-XML is the only open interface for supporting interoperability of business processes, independent of what the business process being integrated.
Wf-XML comes from the Workflow Management Coalition, an independent body of workflow vendors, customers and higher education establishments.
The Actional control broker integrates directly into SAP WebFlow enabling proxy objects to be called directly from the workflow step. When called, the proxy method will make a call to the outside system either as a background task or as a dialogue step. These proxy objects are generated in the SAP system using a converter which converts the objects interface (DCOM, CORBA...) to the SAP syntax. A syntax converter also lets developers view any object in any of the participating systems in the developer's preferred language.
What ad hoc features can my users use?
To be continued....
Content last changed:22th July 2003