SAP process consulting

Understand, simplify and cleanly implement SAP processes

We analyse how business processes actually work in the SAP environment, identify unnecessary steps and turn that into a target picture you can implement. We combine process methodology with SAP know-how, from the existing procedure through fit-to-standard to configuration or a targeted extension.

Arrange a conversation See how we work

The starting point

The process runs. Only nobody knows exactly how.

The typical case is not the broken process but the one that has grown: data is created in two places, an approval step waits on an email, a bill of material is maintained in SAP and kept in Excel alongside. Every single step made sense at some point.

The manual is out of date

What is documented and what people actually do are two different processes. Usually nobody knows both of them completely.

Variants nobody knows about

A process everyone believes to be uniform in fact runs in a dozen forms, depending on the plant, the material type or the individual clerk.

Custom development as a reflex

Every gap gets programmed rather than checked against whether the SAP standard now closes it. That comes back at the next upgrade.

How we work

Four phases along DMAIC

DMAIC is the method from Lean Six Sigma: Define, Measure, Analyze, Improve, Control. We apply it to SAP processes and combine it with the fit-to-standard thinking of the SAP world: first check what the standard can do, then talk about everything else.

01

Workshops with the business Define · Measure

We start where the process actually happens: in facilitated workshops with your business department. Not with IT, not with the project manager, but with the people who run the process every day. Added to that is watching at the screen, because what people do and what they describe are rarely the same thing.

First the scope: which process, from which trigger to which outcome, with which participants.

The result is a model in BPMN 2.0, in a notation your next service provider can read as well, not just us. Alongside it we take the document data from your system: throughput times, frequencies and deviations are there in black and white, and they reveal variants nobody mentioned in the workshop.
02

Measuring where it hurts Analyze

Without figures, any prioritisation is a matter of taste. We measure throughput times, waiting times between the steps, return rates and how often each variant occurs.

Then the root cause analysis: why does this step wait three days? Why is this approval rejected in forty per cent of cases? Only then do we talk about measures.
03

Target picture and fit-to-standard Improve

The target picture does not start from a blank sheet. We run the process against the SAP standard: what can S/4HANA already do today that you had built years ago? What remains as a real gap, and does it justify a custom development?

Whatever remains is sorted by leverage and effort. You get a sequence with an effort estimate, not a wish list.
04

Implementing and securing it Control

We see the implementation through, if need be right into the configuration or the development, because we come from SAP development. And we define with you the measures by which you will later see whether the change has held.

A process that looks the way it did six months later was not an improvement, it was a workshop.

An example

This is what a mapping looks like

A purchase requisition process as it runs in many organisations, mapped in BPMN 2.0. The notation is not an end in itself: only when the flow lies in front of you like this do you see where the time goes.

1
The document leaves the system
From the moment it is printed, SAP no longer knows where the requisition stands. From here on, chasing it up runs on shouted questions and internal post.
2
Six days for three signatures
The signature takes seconds. The time goes by in the folder on the desk, with three people one after another, regardless of the amount.
3
A second media break when scanning it back
The paper is scanned and filed so that someone can find it again later. Work that only exists because it was printed in the first place.
4
The approval is entered by hand afterwards
Somebody sets the indicator that the workflow would set by itself. Mistakes here only come to light at invoice verification.

The same requisition, approved digitally:

Processing time: 6 mininstead of 13 minutes
Throughput time: < 1 dayinstead of 8 working days
Media breaks: 0instead of print, sign, scan
Saved per year: 70 hrsat 50 requisitions a month

And purchase orders that reach the supplier a week earlier.

An illustrative view of an approval process.
Deliberately kept very simple; in practice variants, special cases, substitutions and further participants are added. The paper steps are highlighted.
All four points here could be solved with the Flexible Workflow in the standard, without a line of code.

The outcome

What you hold in your hands at the end

Not a slide deck, but documents you can work with, and that belong to you.

The process as it is, documented

How it really runs, as a model in BPMN 2.0. Including the variants nobody had on their radar before. Readable by anyone who knows the notation, not only by us.

The analysis, with figures

Where time is lost, how much, and why. Throughput and waiting times, return rates, variant frequency, evidenced rather than estimated.

A requirements specification

The measures as prioritised requirements, sorted by leverage and effort. Deliberately written so that you can put it out to tender: precise on the business side, open on the technical side. What the SAP standard covers is marked as such.

A quote for the implementation

If you like, we walk the rest of the way with you, from configuration through to development. The quote comes with it, without obligation.

Why us

Method and SAP depth in the same heads

Process consulting without SAP knowledge ends in pretty diagrams. SAP knowledge without methodology ends in the next custom development. Our goal is not a theoretical target process but a procedure that works in the system and in day-to-day business.

Certified Lean Six Sigma Green Belts on the team. Improvement projects are run along DMAIC, with measurement before and after.
We come from development, not from presenting. We do not need your data models explained to us.
We tell you when the standard is enough. Even when we would have earned more from the custom development.
Short routes. You talk to the people who build the software as well.

Our principle

Standard first. Extensions where they add value.

Not every requirement needs development. Where the standard is enough, we use it. Where an extension adds value, we build it upgrade-ready.

1
Check the standard
We first check every requirement against what the SAP standard can do.
2
Extend sensibly
Where the standard is not enough, we rely on clean extensions that stay as upgrade-ready as possible.
3
Recommend clearly
We recommend the solution that makes sense technically and for the business, not the one with the most development effort.

Name a process that bothers you

We will tell you what we see in it, and whether mapping it is worth the effort.

Arrange a conversation