The Digital FIT Rate explained in detail


These lines of coding above have changed and enabled us to speed up our digital transformation.

Why do we need another KPI?
Because we never had a KPI! In the realm of process performance, we only had metrics!

Let me explain: Every square is a rectangle, but not every rectangle is a square. The same goes for KPIs and metrics. We often say that a metric is a KPI because… it is easy and the only thing available.

But when it comes to measure the performance of a process, automation and rework are just metrics. It would only be a KPI if for automation rate higher is better ALWAYS apply. Or low rework is always good - for the metric is usually is, but we have very manual businesses and thus low rework rate and the process is therefore not efficient, either.

So we had to take both worlds: you have to be GOOD in BOTH Automation and Rework - and thus the Digital FIT Rate was created.

Yes, the Digital FIT Rate can be something similar or else in your business, but the key message here is actually another one: a true KPI can only be a true KPI if it is easily understood by anybody in the business and accepted and adopted throughout the entire organization! If people get disassociated by it because they do not know how to influence it or it is just en vogue to talk about it, then it cannot be a good KPI.

Furthermore, in our case the Digital FIT Rate is also morphing into any dimension - DFR by customer, DFR by country, etc. You could even see a DFR by any given material on any given day.

And finally, since we define certain activities to be included in the DFR, there are different catered DFRs (DFR Order Management, DFR all-in CFO, etc.)


Dear Thi,

Very nice story. We had for some time a discussion concerning the KPI. We actually call them Process Performance Indicator (PPI). We use the same setup but call the PPI “Touchrate”. It is also a little bit easier to understand. We also have a cross company comparison. We found that it is extremely useful to have a drill down to a second dimension for example Process type (Third party shipment versus Sales from own Stock and others). If not, we ended up with a real mess. Since we also have a project business this will even get worse. Also we have an obvious dependency of the TR and product groups. We ended up to incorporate in all important tables a double drop-down of two dimensions. Now the business can do a apple to apple comparison and learn from each other.
How is this at Siemens, since you must have a huge product portfolio and many different process type’s as well?

Many thanks and best regards,


Dear Hans,

Again thanks!

You are absolutely right again - and here is lmy take on your comments!

How do you deal with the mess? We embrace it and just don’t ask that stupid question of why Digital Factory, our short time cycle product business, is so much more automated than our trains business.

The metaphor Is: We CAN compare apples and oranges, because they are fruit. We love fruit and it is healthy. We CANNOT compare frogs and cucumbers, just because they are green.

So instead of any mapping filtering adjusting translating we just make sure that there are people who understand that differences can be embraced and explained instead of white washing them by grouping and clustering.

When it comes to the name Digital FIT Rate or else, it goes nomen est omen and we also know that this is only the beginning. This year we have adjusted our KPI by including more activities so it also keeps moving. There are FIT rates in production and in HR to discover, too. And their calculations might be very different. It is more of a mindset of talking about KPIs: we say, in a given business area there can be only ONE KPI (if it is a good one) - all others are just metrics that lead to the KPI. It doesn’t always work that way, but in our case to measure the process performance (not finance, not FTE efficiency, etc) the Digital FIT Rate works very well!


Hey Thi - I’m curious what the condition beneath the <%=MANUAL_ACT%> variable is. Is it ACTIVITIES.USER_TYPE = ‘A’ ? Or something more nuanced?



Dear Tyler,

user type = A = manual! exactly! Due to the missing differentiation in User Type in SAP, we also have lots of Robots. Thus we need to whitelist the Robots and have therefore a logic to say: User Type A but in Whitelist, treat as User Type “R” (workaround, does not exist in SAP), and thus out of scope.

For full disclaimer: We do have Digital Fit Rate All-in, Digital Fit Rate standard (Order Management related), etc.

We do have around 70+ activities, but in the Digital Fit Rate Standard only a selected amount of activities are relevant (around 30ish).

The variable MANUAL_ACT gives us the flexibility to cater for the scenarios.


Very cool - thanks for the explanation! Gives me some ideas for how we could improve our automation calculations… :thinking:


Dear Miner,

We use in SAP a central user administrator system.
This system distributes User and Role to all SAP systems. As long as you have a valid User, you can Read data from the US02 Table. As soon as the User leaves the company / gets invalid, this information is lost in the target system. We noticed that about 5% of our users are invalid. We could not use the A or B. The information is only in the SAP client with the CUA or SAP IDM… So if you have the chance, get the data directly from the CUA…

Have Fun,

Follow-up platform to support Process Mining outcome action items