SAP Workflow: The Sleeping Dragon Not to Be Woken
By Klaus Brettschneider
Over the last few months, I had the privilege of working with some of our customers to redesign their workflow. Inspired by new functionality and having the goal in mind of enabling the line of business to deal with workflow changes directly in the SAP system, we approached it from two aspects:- We knew we had to develop a methodical approach to building a sustainable framework in which changes can be applied quickly.
- We knew we had to provide a simplified interface for the line of business to implement changes with limited IT support.
The second aspect is probably difficult to describe here. That’s why we will address it in our upcoming webcast “Taking the Work Out of SAP Workflow.” However, this post will describe the first aspect of a sustainable framework.
Several companies are currently rethinking their approach to workflow because of new capabilities provided by the latest SAP enhancement packages (EHPs). The opportunity to tie workflows into all business processes of a company is SAP’s strength, but, at the same time, creates a burden. Workflows are growing, getting more complex, and are difficult to manage. The flexibility to be able to meet all business requirements with additional programs often creates very complicated IT environments. As a result, the responsibility to enhance and maintain SAP’s workflows in the system has shifted from the business side to the IT department.
Thus, workflows are often perceived as a huge dragon that no one wants to wake up. It seems to be too hard to change such workflows, and, as a consequence, such changes are avoided or the realization gets buried under other IT projects. This is especially concerning in product design and new product introduction phases, referred to as NPDI processes, where flexibility and change are critical.
“Workflows are often perceived as a huge dragon that no one wants to wake up. It seems to be too hard to change such workflows, and, as a consequence, such changes are avoided or the realization gets buried under other IT projects.”
We refined five rules out of our recent customer projects:
- Define the purpose of workflow steps, classify them, and define rules for deployment
- Keep the organization structure harmonized and real in SAP
- Automate transactions and not email notifications
- Utilize reports wherever possible
- Implement with an agile approach
Rule #1: Define the purpose of workflow steps, classify them, and define rules for deployment.
Most of my clients had too many purposes mixed into the implemented workflows. The expectation was that workflows had to document the decision processes (who approved what and when), distribute information (everyone has to know when a product is released), balance workload (who has time to take the task), assign and remind users about open tasks (emails to remind or escalate) and much more. Even if all of these functions are important to the organization and part of the holistic business workflow, it is necessary to separate them and treat them differently. It is better, for example, to document the approval process directly at the business-object level in SAP. On the other hand, the assignment of task items to users or departments is generally better accessed in SAP’s inbox and so on. By identifying the purpose and classifying the workflow steps accordingly, it is possible to define rules for their deployment.
Example Rules:
- Approvals are documented as status at the business-object level.
- Task assignments are provided by SAP’s workbench.
Such rules will lead to a defined framework, and, if the same rules are applied to changes, they will fit into the framework that is easier to manage and to maintain.
Rule #2: Keep the organization structure harmonized and real in SAP.
Almost all of my clients struggled because of ambiguous organizational structures. Often times, the structure in SAP does not represent reality, or workflows are built on “made up” structures that have nothing to do with the one in SAP and reality. It is not necessary to have all structures in harmony, but it makes it much easier to keep the system consistent.
Rule #3: Automate transactions and not email notifications.
Workflows are very often abused as reminder engines to advise users to perform transactions in SAP or other systems. In one of my client’s cases, an approver would receive an email whenever she had to approve a design. She had to sign off on the “Approve” task on each design document, drafted bill of material, compliance report, and cost analysis. Isn’t it better to automate all of the transactions instead of making her click through every step? Instead of fifty clicks, a smarter workflow could sign off on all documents once she signed off on the task with just one click. Yes, she has to review all documents and “approve” them, but isn’t that her responsibility anyway before she signs off on the task?
Rule #4: Utilize reports wherever possible.
Does it make sense to send an email for each document that has to be approved? Whenever we have implemented such a function, we ultimately had to take it out after awhile because the approver got annoyed. Isn’t it better to provide a report for all documents that have to be approved? Most approvers are involved in the approval process and know what documents need to be reviewed. Before automatically sending emails, consider sending reports to provide access and to communicate current status.
Rule #5: Implement with an agile approach.
As with all task management systems, successful deployment requires finding that happy balance between too much and not enough breakdown in task detail. You need to make sure critical items in a workflow are attended to while being mindful that the system does not need to micromanage its users.
In recent projects we had great experience with the approach to define the most important workflow steps first, deploy them in the system, expose them to the users, and put more detail in later. The 20/80 rule applies for workflow projects as well. Maybe it has more value to get 80% in place right away and fill out the last 20% later.
