Design Principle - it's easy! Just very hard to keep up to it - every single day!


#1

Make friends with reality. I wasn’t even attracted to reality. And reality and I - we don’t share the same values, the same goals … I have fantasies. They’re exactly like goals but without the hard work.
– Emily Levine.

Often I get asked the question: how were you so quick to get the organization thrilled to using process mining?
Because we adhered to our Design Principle that enables speed and scalability.

You can find the text also here.

  • When you start, try to avoid filtering of data from the back-end into the front-end; take everything and if performance is an issue, just load everything with a limited scope of time (e.g. just one month instead of a year). You will be amazed by the creativity you could spark to actually improve many things immediately - or in other words: do not steal your own low hanging fruits.
  • If country A has 12 different item categories and country B has 15 but your management only understands 5 on the Powerpoint - resist! Ask the “Why”-related questions first. Why do I have 12 or 15 different item categories and does it even matter? Don’t think immediately about a standardization for the sake of standardization project. Is there an overarching global use case, or is it a regional topic only - the fact that you can show it globally does not mean you must also be able to derive actionable insights from it.
  • This one is related to process mining only: when looking at processes activities like “Create Sales Order item” or “Create Invoice”, it is tempting to also look into the content of each activity. For example, the activity “Change Price” could be broken down into “Increased Price due to error in unit of measurement” or “Change price currency mismatch” and so on. Though this kind of information is very helpful and we are reading and using it, too, the activity itself should stay generic, standardized and universal.
  • The last one also goes hand in hand with the previous bullet: How do you define an activity? We try not to. We try to take what is already there from the back-end system. In case it is SAP HANA and SAP wants to call it “Incoming invoice processed”, I am going to use this wording in the front-end. Too often have I seen the creation of seemingly more accurate and helpful definition of activities, but the maintenance efforts and lack of value generation is tremendous.

With this approach, something magical has happened.

Standardization has unlocked creativity because of two underlying factors: scalability and speed .

.


#2

Dear Ti,

Again a nice story.
In our cockpit setup using User Stories we actually defined Management Cockpits which do not go into “details”.
For the vital SAP item categories which are of course technical but on the other hand define the route = “process type” the item goes. We have at the moment 14 Process Type’s in O2C and almost 300 item categories. The process types are good for the management as well as everybody who is not a SAP Keyuser. It is also very useful to use in drop-down and sheetfilter. We also have a process type called “Else” in case new item category show up which we did not consider yet in the formula yet.
Do you use something similar as “process type”?

Many thanks.

Best regards,
Hans.


#3

Hi Hans,
Yes of course we have in our business language and Powerpoints topics like process type: product business, solution business, purchase to order, engineer to order etc. I was mixing different levels on purpose just now.

The reality though is : with over 70 SAP systems there is no data criterion that could ubiquitously tell across the world: yes, you are drop ship, and you are spare parts.
For one system, yes. Or a white list would be possible: in system x, product business means these item categories. In system y it means these document types in relation to certain item categories and their underlying sales org, but not for all plants etc.
So you know where I am going…

Solution: no mapping no translation. The management reports take the simplicity to focus only on the KPI, everything else is metrics.

In a nutshell let me offer this metaphor: the Digital FIT Rate is like EBIT. You can’t change EBIT. It’s a result of top line and expenses. So automation rate is top line and rework is expenses. Management cares about results, we show them. The people in the trenches do the work: they need meaningful transparency to do so : they got it.


#4

Hi Thi,

Thanks for the further explanation.
Makes totally sense to me.
It mirrors our User story for the top management level. This resulted in our “Company comparison cockpit”
The people in the trenches have there own cockpits specialized in each PPI).

Best regards,
Hans