SAP Workflow vs. Pure ABAP Based Task Management for Business Process Transformation – the False Choice

It is well established by now that business processes requiring repeated manual data entry, paper transport and/or 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 as 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 ad hoc 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 users 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 the 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.

Back to Blog

SAP Workflow vs. Pure ABAP Based Task Management for Business Process Transformation – the False Choice

It is well established by now that business processes requiring repeated manual data entry, paper transport and/or 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 as 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 ad hoc 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 users 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 the 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.