In my last post, I used the blueprint analogy to explain what a business architecture is – a visual business model used to facilitate or accelerate coherent decision-making. Another way to look at it is to view it as an insurance policy against siloed thinking and management.
In this post, I thought it would be important to explain how build a valid process-based business architecture.
First things first – from KYC (know your customer) to KYS (know your stakeholders)
Your business architecture has to be valid from a business-strategy perspective.
Your model must be anchored on a good and shared knowledge of your key stakeholders’ needs, and from which you derived your core strategic intents. This is the first, and one of the biggest by far, traps that management or executive teams fall in to. We are often tempted to race through this, either because we think this is day-dreaming and not about real life, or because we think we know all about our strategic priorities, our stakeholders and our stakeholders’ needs. More often than not, this is not quite true. As CEO, you may think that your organisation’s strategic plan is known and understood, and that it means the same thing to everyone. Well, surprise, it does not! Your business architecture is a key governance tool, and ought to be purpose-outcomes driven, not just a pretty picture of what your organisation does.
Designing your process architecture model is a critical ‘social’ and ‘business’ act, as important as building your strategic plan.
Your business architecture has to be valid from an ownership/engagement perspective.
Many executive teams think the a strategic plan is solely the job of the strategic planning department. They also treat it so confidential that only the executives should have access to it. These leaders then wonder why is the plan not executed well! A valid business architecture is the same – it is a very powerful collaborative alignment lever.
During the next steps, we design your value creation or business model. We may or may not use an existing industry process referential to help us spark the work. The design is done through a series of workshops with all the key leaders. We sweat it out, make sure we agree on triggering and ending events, outcomes and possible KPIs, and validate that the model reflects who you are, how you think, and support where you want to go from a process perspective. We confront visions, understandings, readings of our external and internal contexts; we talk business, how it flows or does not flow. This is a first moment of truth for the management team. The methodology is anchored on ‘lean thinking’, and the socialisation of the model is as important as the model itself. The approach reinforces ownership and engagement.
It’s about processes, not functions!
A process-based business architecture is valid when it’s building blocks, nomenclature, and design comply with best practices, the BPM Manifesto, and design and semantic rules.
A business process is not a function, and we often find that organisations confuse functional architecture and process architecture. They are not the same – their purpose is different. Functional architecture may be useful for IT, but not as useful for the business leaders. The key focus here is business and transversal view (end-to-end view). Clients do not care about your organisation or your functions. They care about value delivery, and this is done via your people and your processes. A process-based architecture shows how the value is created from an end-to-end perspective. It shows all the disconnect and failure points to deliver your targeted customer experience. You cannot map or model your customers’ experiences with a functional model – you need a process model.
It’s about an actionable and aligned investment plan
A process-based business architecture ought to be valid from an execution point of view, and must facilitate alignment and traceability between strategic priorities, performance projects portfolio, and results.
The other big moment of truth – and key critical success factor to make the model actionable/useful – are the steps when we prioritise processes using a ‘High Pain – High Gain’ matrix, and take time to add a process capabilities perspective to it (using Roger Burlton’s Hexagon). This forces the management and leadership team to agree on priorities, critical capability gaps, and a story board (execution plan). Again, the approach forces ownership and engagement, because it is done by the team. They sweat it out. At this stage, we often hear the wows and astonishment comments like: “We should have done that before!”; “This really helped us to get where we needed to be together!” – lots of aha moments.
No magic tricks or thinking here. A working methodology needs to be executed in a disciplined way, yet leaving space for engagement, discussions, healthy confrontations, paradigms, and dictionary (words and meanings) collisions, etc. This is not about command and control – marching orders; it is about the team, and about leadership building – getting the organisation ready to write its next sustainability chapter.