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 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!