DE Arrange a conversation

SAP process consulting

Understand, simplify and cleanly implement SAP processes

We analyse how business processes actually work in the SAP environment and turn that into a practical target state. Process methodology and SAP expertise from one partner.

Arrange a conversation See how we work
Process steps Demand Requisition Approval PO Time line Waiting time Processing schematic

The starting point

The process runs. Nobody knows exactly how, though.

The typical case is not the broken process but the one that has grown over time: 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 who is handling it.

Custom development as a reflex

Every gap gets programmed instead of first checking whether the SAP standard now closes it. That catches up with you at the next upgrade.

How we work

Four phases, following DMAIC

DMAIC is the improvement model from Lean Six Sigma: Define, Measure, Analyse, Improve, Control. We apply it to SAP processes: first check what the standard can do, then talk about everything else.

  1. 01

    Workshops with the business Define · Measure

    We start where the process actually takes place: in facilitated workshops with your business users. Not only with IT and project management, but above all with the people who run the process every day. We also observe people at their screens, because what they do and what they describe are rarely the same.

    The result is a model in BPMN 2.0 that your next service provider can read as well. The document data from your system reveals variants that nobody mentioned in the workshop.

  2. 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.

  3. 03

    Target state and fit-to-standard Improve

    The target state 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 custom-built years ago? What remains as a real gap, and does it justify custom development?

    Whatever remains is sorted by impact and effort. You get a sequence with effort estimates, not a wish list.

  4. 04

    Implementing and sustaining it Control

    We see the implementation through, if need be right into the configuration or the development, because we come from SAP development. And together we define the metrics that will later show whether the change has stuck.

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

An example

This is what an as-is analysis 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.

Purchase requisition with paper-based approval Three lanes: the business department, purchasing and paper-based approval. The need is reported, purchasing creates the purchase requisition and prints it. The printout goes by internal mail to three signatories in turn, returns to purchasing, is scanned, and the approval is entered into the system by hand. Under each step is the measured time. In total around 13 minutes of processing over eight working days of lead time. Business Purchasing Approval on paper Report demand Create requisition Requisition printed out Signature Cost centre Signature Division head Signature Management Scan and file Enter approval in the system 3 min 3 min 2 min Ø 1.5 days Ø 2 days Ø 2.5 days 3 min 2 min Internal post 1 day Return 1 day 1 2 3 4
  1. 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 happens by word of mouth and internal mail.

  2. 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. 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. 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 there are also variants, special cases, substitutions and further participants. The paper steps are highlighted.
All four points here could be solved with the standard Flexible Workflow, without a line of code.

The outcome

What you have in hand at the end

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

01

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.

02

The analysis, with figures

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

03

A requirements specification

The measures as prioritised requirements, sorted by impact 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.

04

A quote for the implementation

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

Why us

Methodology and SAP depth in the same people

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 to-be process but one that works in the system and in day-to-day operations.

  • Certified Lean Six Sigma Green Belts on the team. Improvement projects follow DMAIC, with measurement before and after.
  • We come from development, not from presentations. Beyond the process, we also understand the technical SAP side behind it.
  • We tell you when the standard is enough. Even when we would have earned more from the custom development.
  • Short lines of communication. You talk to the people who also build the software.

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-safe.

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

Newsletter

Stay up to date.

News about M2 Digital, SAP and our software solutions.