Designing an SAP workflow for a paper-based credit memo process

Enter the accounts payable department: „We have to process about 300 incoming supplier credit memos per month. Some get lost or are processed twice because the process is paper-based.“ So we sat down and drafted the requirements for an SAP-based workflow. This post tells you about how the requirements were gathered using Six Sigma tools and an EAM modelling application.

When the client approached me with the problem I told him to arrange a meeting of 90 minutes with participants from accounts payable department, operations department and order processing department. I did plan this more as a KAIZEN event since the problem´s root cause and the solution was more or less clear (replace the paper flow with an electronic solution).

If you know me, you will guess my first step. Yes, I made the team to exactly define the business problem first (old Six Sigma habit). Here is an outline:

ABC company receives about 250 to 300 credit memos from suppliers per month. These have to be parked, verified and allocated to the exact client bill.

Processing time of a credit memo is up to one month. This oftentimes interferes with the invoicing process for clients. About 2 to 3 items get lost per quarter. About 5% of the items have to be processed twice.

My next step was to draft the process on a high level using the SIPOC diagram. SIPOC stands for „supplier“, „input“, „process“, „output“, „customer“. The diagram helps you to quickly understand who does what in the process (the process chain) and which items are processed. It takes you about 15-30 minutes to fill it with the necessary information and is incredibly useful!

Since the process relied completely on using paper and physical mail we could easily link this as a root cause to the problems. The in-house mail service was reliable but sometimes stuff got lost. People receiving the credit memos simply forgot to process them, procrastinated cases or had to work on cases two or three times since they were now sure if they had already done so.

So what the team wanted was an electronic workflow carrying scanned documents to each responsible person. The system would remind everyone exactly when required and follow-up each case automatically.

The Best-Run Business Run SAP – so we designed the SAP support in the next step. It was useful to have participants from all involved departments at the table: we could decide about the process and the application landscape in one step.

As a modelling tool I used „Archi“ – an Enterprise Architecture Management editor. It allows to create diagrams on three layers: process, application and infrastructure. Since we wanted to design a process and its IT application support, Archi was the perfect fit. Archi uses Archimate, an open Enterprise Architecture modelling language hosted by The Open Group. It´s fully aligned with TOGAF, an enterprise architecture framework widely used in the SAP world.

First step was to „knock over“ the SIPOC diagram. While a SIPOC shows a process in simple steps vertically we now used a horizontal process . The result was the diagramm below. The process was triggered by each incoming credit memo and consisted of the following steps:

  1. Park an incoming invoice or credit memo – this was usually done by the accounts payable department
  2. Select verifier and send documents – the accounts payable department has to identify the responsible person, create a hard copy of the paperwork and send him or her the case (identifying the correct person is sometimes harder than you think)
    Verify credit memo documents – the operations department needs to check the documents and verify the credit memo´s correctness. Sometimes this step involves 2-3 people from different operations departments
  3. Complete billing process – the order processing department uses the verified credit memo documents to reduce the clients´ bills by the credited amount

We planned two major changes that you can see in the figure below. First the process will rely on an electronic workflow engine in the future. This is modeled as an application service simply called „Workflow-Service“. This service will provide the workflow support. The Workflow-Service will rely on another service for creating the scans and presenting them to the end user: the „Scan-Service“.

The second change is to remove the manual process step „Select verifier and send documents“ (step two in the list above). The workflow service will replace this business function with a software solution.

Image

As you can see in the diagram, Archi uses different symbols for business processes, events, business roles and business objects.

The connection between the process layer and the application layer is established by application services. From a business process point of view an application is primarily considered a service – regardless the actual software used to realize the service.

Please note that in Archi you can create diagrams over all three layers on one canvas. If it gets to complicated – simply highlight the layer you want to discuss using the „Viewpoint“ function. I used the Business Process Viewpoint to highlight process steps and application services.

In the team we discussed to have the incoming credit memos scanned by an OCR software. However due to time and cost tradings we postponed this suggestion into a second generation (configuration level 2) of the project. Scanning incoming documents with OCR is a bit too complicated to discuss it in such a short meeting.

So we had now created a diagram for a new process and a service relying on another service. Next step was to model the application architecture for these services. As outlined above an application service is an abstract entity. We now had to fill this abstract with the required applications.

The Workflow-Service consists of three software applications: the workflow engine X-Flow, the SAP financial module and the document management solution SAPERION. The latter creates the scanned version of the supplier´s credit memo. X-Flow uses a work item pointing to the scanned credit memo in order to present it to the end-user. Furthermore X-Flow relies on Workflow-Rules to manage the different work items follow-up actions.

SAP ERP FI holds the ERP work items relevant for accounting. It´s items are linked to X-Flow and SAPERION items so the relevant business documents are stored in the company´s ERP at every point in time.

For our second generation service – the OCR extension – we need to rely on an OCR software. In this case the client relies on Kofax for such purposes. Kofax will access the scanned version of the credit memo and „send“ this information to SAP FI. There an SAP document is automatically created and stored – while in our first generation solution this is all part of the manual work in accounts payable.

ImagePlease note how I faded the business process layer out in the figure in order to highlight the application structure.

After the meeting I created a small documentation that I briefly discussed with the IT department. They will now go and get an effort estimation.

When completed the team will present the solution to management and receive an approval for implementing it.

Archi proved to be a very helpful tool for modeling and visualizing a business process and its IT support. It´s free and open source, so feel free to try it out.

Weitere Blog-Artikel