Skip to Content

It is well established by now that business processes requiring repeated manual data entry, paper transport, approvals or intervention from a diverse group of users can hamper productivity, increase cost and introduce systemic risks in any organization. When such processes involve enterprise business applications such as SAP, they need to be brought under a controlled framework, or the promised ROI could be elusive. Workflow technology has been around for a while now, and promises such a controlled and consistent framework. In general, if all of the following checkpoints are valid for any business process, it is a good candidate for a workflow based transformation:

  • Are different people involved in the process?
  • Is the processing-time critical?
  • Is process-tracking or auditing critical?
  • Is the process-consistency critical?
  • Is the cost of failure high?

If a process passes these checks, proper modeling of the business process, tasks, users and events can help optimize high volume or high risk business processes when coupled with advanced data ingestion tools and user interface. Typical examples of such processes in SAP are Accounts Payable, Sales Order processing, Accounts Receivable Cash Application and Human Resources new hire processes.

For SAP customers, the technical implementation of such workflows may present many choices. The most obvious choice is to leverage the SAP workflow engine since it is, without any consideration of SAP Business applications, one of the most robust workflow engines out there.

Because SAP workflow skillsets  are not in abundance, SAP developers occasionally write custom ABAP-based task management and pseudo status based workflow scenarios as a workaround. Typical arguments in support of this approach are:

  • Let’s not be purist and go for the seemingly simpler solution. Business process transformation is not another IT academic exercise
  • Custom ABAP based task management interface provides better UI possibilities as we are not limited to the constraints of the SAP inbox
  • ABAP skills are more widely available
  • Debugging problems are easier with no workflows involved
  • Perception (as misguided it may be) that SAP HR is needed to define workflow roles.
  • Personnel changes require involvement of IT resources as a business user  cannot manage the workflow roles

While some of these arguments are valid, one should consider this:  At the onset, workflow may seem simple enough where real life issues associated with high volumes such as deadline management, detailed logging, and workitem reservation/locking/unlocking may seem trivial. However it took SAP 20 years to perfect them in their workflow engine. Re-implementing these from scratch on an adhoc basis may infest the process with a continuous need for expansion of ABAP components responsible for these tasks.

So what’s the solution as both options have their own set of issues?

The solution lies in the realization that these are not mutually exclusive options. You can implement the business logic, rules, UIs and even the task queue user interface through pure ABAP. However, you can still leverage the SAP workflow engine as an invisible framework for managing task allocation, record locking, deadline monitoring, and load balancing. This approach can counteract all of the concerns listed earlier:

  • Users are given optimal UI for specific tasks; no need to use the SAP inbox
  • The use of workflow only for core services ensures that workflow templates are stable, reducing the need for workflow skills. All business rule changes are managed through configuration or ABAP exits.
  • ABAP based routing that uses custom tables with references to work centers ensures that no SAP HR is needed. Business user can be given pointed access to user/group assignments through IMG like table and work center maintenance.
  • Debugging is easier since  the business logic is in ABAP
  • Standard SAP “out of the office” assignment and  substitution options just work
  • Non SAP users can be involved in this workflow through the use of events that can be triggered through the SAP NetWeaver gateway or another implementation of simple REST based APIs that can be triggered from mobile devices

To summarize, an ideal approach for SAP centric process optimization implementation is to leverage the SAP workflow engine for core services and ABAP components for everything else. This approach addresses aforementioned concerns about using SAP workflow engine without risking a short-sighted and sub-optimal architecture that is not designed for growth.

After all, there is a happy middle ground in this dilemma 🙂

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member

    Having worked as a SAP WF and ABAP developer for many years, I could not agree more with Vishal on this topic of strategic importance in solution designs. We have to do a careful analysis of every business logic to know wether we should implement it as WF steps or as pure ABAP code. This blog gives good guidelines in such analysis.

  2. Former Member

    This blog provides insite on using SAP WF as a solution for business process transformation. As Vishal has mentioned, there are advantages of the simplicity of designing a WF based solution, still one needs to analyse the requirement and find a middle ground with WF engine for core services and abap based logic for better control of business logic. An overall good blog for people planning for business process transformation.


Leave a Reply