Breaking down complexity
Transformation sounds complex but ideally is nothing more than optimisation in continuous steps. You have to renovate the house from time to time but will do so with precision if you did built out your craftsmen capabilities via continuous practice over time. Also then the renovation is rather part of a continuous change with far less risk of failure vs. a complete disruption.
In this blog post, we bring it all together and share how SAP Signavio can contribute to adding value to every step of your process transformation journey across SAP S/4HANA, SAP BTP and any other solution.
Based on our Business Process Transformation manifesto let me highlight some key aspects to "de-compose" complexity:
- Get (additional) insights every day: don't bet on "one-off wonders". There are larger and smaller potentials hidden in your daily operations and the way you execute today. And there might be others tomorrow as you fixed some whilst business reality created new ones. Having a continuous grip on performance and continuously identifying improvement potentials enables consistency of investments as well as agility in execution.
- Create the demand where the problem is: you can't prescribe change or solutions or adoption. So take your employees on a journey they steer. The most productive places are where problems and solutions meet. Unleashing the immense potential of "steered and governed" collaboration is a prerequisite to successfully embedded continuous transformation into your operating model.
- Thrive for solutions and fixes: "Unblocking" bottlenecks - even if automated - is a quick fix. Which might have its merits. But not in the mid term as every fix blurs the case for the underlying problem. Real solutions go far beyond fixes "on the surface" as they unlock agility and even innovation. So dare to analyse deep down to "the core" vs. scratching on the execution level only. Understanding the underlying solution complexity is a key skill to take smart decisions that avoid future complexity or "lock-in legacy" effects.
Strictly applied to Business Process Transformation this means:
- Operationalising Process Analysis: you can't control what you can't see or measure. Complexity grows best in the dark where nobody sees it sprawling. Thus, shedding light on your real execution should be a key priority to activate your organizational immune system. People dislike complexity and thrive for optimisation. Give them sight and they will jump to solution mode. Not only the experts, but the entire team really.
- Guiding Process Design: knowing the problem does not mean knowing the solution. The abyss between "good process" and "good (software) solution" is complexity's best friend as it separates the Business (execution) from the IT (solution). Building the bridge is essential to give the "unleashed solution energy" clear direction and focus. Our "solution bridge" relies on "good practice" reference content that shows what good looks like on the business process and IT solution side. Knowing the reference solution will avoid reverse engineering a standard and allow for tailored localization / extensibility where required. This saves the "creative momentum" for (the view) real white spot areas where no standard solution exists.
- Being fast in Execution: sounds easy but requires rather structure than speed. Execution complexity in almost every case is not a problem of the unwilling and/or unable but rather an incentive (management) and/or "idea to solution" channel problem. If you found the problems and now the good practice reference, executing on the change should be a standard. If not check on your DevOps delivery model (across your solution portfolio) or read on as incentives for change might be missing.
Figure 1: How to accelerate the cycle between insights and adaptation
Building the case
The case for change is no rocket science. It just needs to survive the "why, why, why" challenge in the light of corporate strategy and priorities. Needless to say that data is not only your best friend but an absolute prerequisite to pass the test. If you can't show it in numbers it's a feeling. And most companies lack emotions in P&L and Balance Sheet (blame the accounting principles for missing out on that intangible asset).
From a very practical standpoint this means: priority follows value. If you want to pitch for investment you need to be able to indicate some payback and/or ROI. And you should not need a consultant to create the pitches but, as outlined above: it can be a standard task of everyone exposed to process analysis and/or Process Design.
All it takes is a sound steering concept that bridges process-level (performance) metrics to value-driver-level business outcomes. It's great to see process-level bottlenecks but translating those into real business impact is key. With this objective "value" tag, the business ambition behind improvement proposals gets transparent and can serve as commitment level for change and/or transformation requests.
Figure 2: exemplary value summary
Further details on how to build a case have been outlines by Rainer and Axel here. Value potential analysis can be done with SAP Signavio Process Insights and Process Intelligence already (more features to follow).
Executing across core and extensibility
My firm believe is that, from a process (transformation) and business perspective the "what" is more important than the "how": it matters WHAT initiatives you drive to improve and realise value, not so much the HOW in the sense of which IT solutions will do the trick. Though business departments are getting savvier in crafting solutions (e.g. "citizen development" for low code / no code), there is an expensive catch to "if you have a hammer every problem is a nail approaches". Business demand for change needs to be met with a sound IT supply of solutions.
To master the art of "driving solutions and fixes" in parallel there needs to be a point where a sound value case and process-level solution proposal meet the whole nine yard of available IT solutions and architecture - which transcendes the "shadow IT" spectrum.
Choosing solutioning wisely requires knowing all available alternatives. And the question "where to deploy the code" matters as there is a cost to IT landscape complexity and non-integration which the Business will feel if process requirements are prioritised without taking solution landscape strategy into consideration.
On the flip side this means: it does not matter whether you are driving your S/4HANA transformation from strategy to execution or if you are driving value around the core with Business Technology Platform or any value on any other solution... the process does not care. Neither does the continuous process transformation approach on the Business side - it's just the same. They key is to intelligently interlock the process and solution perspectives to enable sustainable business outcomes. And of course this gets a whole lot easier with an "integrated, clean core" landscape.
Figure 3: How Process Design connects to Solution Design
Where are you at your transformation stage? Let us know in the comments below or watch our SAP Community Call to learn more about how we can help with your transformation.
- SAP Managed Tags:
2 Comments
