🍏 🍎 Same same but different - how to address different User Groups from Order Processor to Executive Management


#1

Often I get the question: Who is using the O2C Monitor in Siemens - and the answer is easy: very many different user groups. So we have order processors in the regions who are also posting in the transactional systems from day to day, global process managers who take care of a specific business unit, shared services organizations, regional CFOs or audit organizations.

But how do you make sure it makes sense if it is only one data model?

As I mentioned in my other posts, the Design principle still upholds: no mapping or filtering across the different use cases --> at the end it is only one data model.

But we show different dimensions and points of views and thus: the topic of comparing :apple::green_apple::pineapple::pear::watermelon: is avoided as much as possible because we are answering each and every question of the respective user groups:

  • Order processor: wants to know how automation and rework rate is of particular customers and does detailed analysis on document level
  • global process manager: wants to know how different regions are performing related to process performance
  • regional CFO: wants to know which business units within the country are performing in which way

Let me briefly show some screens (just a teaser, the content of each is far more extensive)

1 - Out of the box (and slightly adjusted) O2C Monitor for regional order management (customer facing)

  • you can see the details of all documents (out of the box) and also see the activity details for each (we extended it)
  • this way, you can see the transaction code and change document and the values before and after
  • usually this is the lowest level of details a user needs and it represents the case explorer in a table view

2a - Our Reporting environment that can be used by performance controlling, management, etc.

  • here you cannot see the details of a document, but it is also not necessary for this particular audience
  • more interesting is the point of view along time (month by month, etc.)

2b - Our Reporting environment that is used by global process managers who also need to use detailed interactive functions to drill down and analyze on the fly

  • you can customize any dimension to your liking by hiding and unhiding
  • basically like a pivot report of unimaginable dimensions, but when creativity kicks in…
  • your imagination can go wherever it needs to take you

3 - the Idoc analysis is for more technical related use cases

  • if you are familiar with Status 51 and EDIDS tables, you will enjoy this part

4 - this analysis is for anyone who wants to quickly assess potential RPA/RDA use cases

  • there are lots of different screens here, but one of the most important visualizations is the interactive chart between absolute occurrences and rates in percentage
  • below you see a global view and then selecting one particular country
  • you can see that “Approve Credit Check” is a mathematically / statistically worth topic to look for a potential RPA/RDA use case

So now you have the teaser how ONE data model can fit organizationally for ALL different use cases: Reporting, process improvement, identification of RPA/RDA, performance controlling, etc.
Can you derive potentially dangerous insights? Yes. But you have at least the option not to do so!


#2

Just for fun:

This is a Chinese Pear also known as an Apple Pear!
Let’s focus on the fact it is delicious and healthy and provides value rather than segmenting it


#3

Hi Thi,

thanks for sharing. I think this is a must read for every project manager/data scientist/tool owner during a first project. We often see customers looking for ideas about how to organize their analyses (and defining the authorizations).

Best
Manuel


#4

Hi Thi,

thanks for sharing. This is really inspiring and helpful. I have one question to the shown dashboards (tables). How did you managed to represent KPIs and then KPIs related to individual activities in the different columns? For example: Dimension - Month, KP1, KP2, KP1 for SO Creation etc.

Best Regards,

Friedemann


#5

@andre maybe you can answer :wink: don’t want to take credit away!


#6

Hi Fthiel,

I am aware of two ways of achieving that, one way using PU functions and another not using it. Explaining the difference between both isn’t much easy.
Let’s take the Rework rate of Change Price KPI as example. In our O2C dashboards, this is the percentage of cases - sales order items, which have had the Change Price activity performed manually.
We need to hardcode in KPI formula what is the activity that is in scope (Change Price in this example).
If I use PU functions, one can apply any activity filter and KPI is calculated as expected.
If I don’t use PU functions, one can’t exclude Change Price activity from activity selection. Otherwise, you will see the rework rate of change price activity as zero.
On top of that, depending of dimensions/KPIs you might have in a component (table, chart…), you may or may not use both KPIs using and not using PU functions in the same component.

Formula not using PU functions:

1.0*COUNT(DISTINCT
CASE
WHEN (“ACTIVITIES”.“ACTIVITY” = ‘Change Price’ AND “ACTIVITIES”.“ACTIVITY” IN (<%=rework_activities %>) AND <%=MANUAL_ACT%>)
THEN “ACTIVITIES”."_CASE_KEY"
ELSE NULL
END
)
/
COUNT_TABLE(“CASES”)

Formula using PU functions:

SUM(1.0PU_COUNT_DISTINCT(“CASES”, “ACTIVITIES”."_CASE_KEY", “ACTIVITIES”.“ACTIVITY” = ‘Change Price’ AND <%=MANUAL_ACT%>))
/
SUM(1.0
PU_COUNT_DISTINCT(“CASES”, “ACTIVITIES”."_CASE_KEY"))

Best Regards,
André


#7

Hi André,

thanks a lot for your answer. It helped me a lot!

Best Regards,

Friedemann