What is and End-to-End Process Architecture?
In order to manage processes as assets, organizations needs to establish sound business architecture, and execute and improve operational processes for greatest stakeholder value and strategic advantage. To accomplish this requires a robust process architecture (enterprise process map) that leverages end-to end thinking and process frameworks. A sound enterprise level view of all processes will exhibit seven key traits.
Key Traits of Robust Process Architecture
Organizationally Agnostic
Business processes do not directly correlate to an organization's structure. Certainly the work described by the process architecture at some level of detail will be performed by people conducting roles within an organization, but end-to-end value creation is a factor of the stakeholder relationships with external parties not the internal hierarchy. A good test of the quality of an organization's process architecture is to ask if the structure could survive a reorganization. If the answer is 'no' then it is poor process architecture. The architecture can be changed but keep in mind that customers will judge your business by how well you meet their expectations; nothing more nor less.
Technologically Agnostic
The processes of the organization are typically enabled by technological services or capabilities. It is especially tempting, given the availability of Enterprise Resource Planning (ERP) suites and other off-the-shelf software, to follow the vendor's implicit design for the organization's processes.
However, there is not always a one-to-one correlation between the two. Each process may have more than one enabling technology and each technology may be employed by multiple processes. The perspectives are different. Falling into the trap of following the technology in a one-to-one mapping effort to create the overall process map will not result in an end-to-end view of the organization's world that can deliver business outcomes.
Value Chains
Organizations can have multiple lines of business, products, services, markets, and geographies. Trying to mix and match all of these into one consolidated process architecture may be unwise due to the sheer size and complexity of the effort. It may be more feasible to build architectures around a single value chain at a time, each with its own unique value proposition. For example retail banking is quite different from wealth management and what happens on the trading floor. These may all be supported by shared services such as human resource and IT service processes. To be sure you have well-formed value chains check to see if the processes in each are truly different and serve different stakeholders, measures, and goals.
Consistent with the proposition of value creation, processes from top to bottom should exhibit high quality naming structure. Organizations that have effectively named processes typically use commonly-understood language (i.e., no jargon), ensure they are quantifiable, and use an action-oriented verb-noun convention. There should be no nouns such as 'the order process', nouns are for data and things. There should be no gerunds or suffixed verbs such as 'marketing', that's for departments. There should be no vague, lazy verbs such as 'manage technology', those are for functions or job descriptions. There should be results or outcomes of value clearly visible in the name such as 'settle claim' and not 'handle claim'. The closing event representing the targeted result of the process should be derived easily from the name such as 'claim settled'. The process value goal or purpose should be apparent in the name.
Core, Guiding, and Enabling Processes
Process architecture oriented to an end-to-end view of the business is generally partitioned into three major categories.
- Core processes deliver goods and services to the customers, clients, or consumers of the value chain, or organization. Core should not be perceived as ascribing a degree of importance to these processes over any others. Core processes deal with what the organization does to action the customer relationship journey (from birth to death) and the product and service lifecycle (from concept through retirement of what it delivers). This is what the organization gets paid to do and everything else it does outside of the core must strive to optimize this set of processes.
- Guiding processes set direction, plans, constraints, and control over all other processes. They are not the heart of the business but perhaps are the brains. Despite not being core they are extremely important.
- Enabling processes provide reusable resources that make it possible to do the work of all processes. They could be thought of as the arms and legs that actually do work. Again most organizations are not in business to do this type of work but it cannot be effective without producing the right operational capability.
Many models use the terms “management processes for guiding” and “support processes for enabling”. These terms are not clear enough and are often confused with what managers or support departments do, not with the intention of the role they play.
Limited Depth of Structure
In order to remain architectural in perspective, the level of abstraction should remain high and organizations should not delve too deeply into the details of the process activities. The distinguishing factor should be that the architecture describes 'what we do' and not 'how we do it'. It should also be stable over time unless the business mode itself is changed. For example, 'sell' does not say how the organization sells but sales results can still be measured and sales can be performed many ways through varying channels and employing a variety of mechanisms. While not a strict rule, approximately three levels of depth are usually sufficient with ten processes per level for each parent level process. To sustain the architecture's effectiveness the end-to-end processes need to focus on the 'what do we do' at levels 1-3, because this stands the test of time. It also allows organizations to provide a balance between standardization (process and performance) across the organization (including divisions and regions) and the customization necessary to accommodate the 'how we do things' among different groups. The customization is often a requirement due to regional and product differences because of varying regulations, norms, systems, and cultures.
Measurable
As mentioned in the value chain section, a good architecture's component processes should be quantifiable. That's the first measurement; how many instances of this process are there? If a good measure is unavailable then it may be a poor process definition and should be re-examined or re-scoped. Architectural-level processes should always be measurable in terms of their effectiveness, how well each one meets the expected value received in terms of needs met and experiences satisfied. Decomposed lists of functions outside the context of the end-to-end view cannot satisfy this requirement. Only the end-to-end view can truly provide the foundation for this measure.
In addition to the measurement of instances, organizations should also look at other aspects of measurement using a process-oriented, balanced scorecard (Figure 2).
Figure 2
This score card is different from the classic organizational strategy balanced scorecard and tackles other forms of measurement, specifically: efficiency, quality, agility, and end-to-end effectiveness. Efficiency provides a set of indicators that deliver data regarding the use of resources while operational. Quality provides feedback on compliance levels and consistency with standards and regulations of various types. Agility measures the organization's track record with regard to time and ease of getting change to happen, especially regarding products and services to market and the capability to get them there. An end-to-end model is required to assess effectiveness and agility, while a functional model may help more with efficiency and quality.
Traceable
In terms of both value creation and measurement, the value chains should ensure that each process in the chain contributes to what is defined as value or expectations of the recipients. All performance measures must be indicators leading toward the overall outcome measures of value and be fully traceable to such outcomes. With a well-formed, end-to-end architecture this is easier than when using a functional or organizational view of the work.
The same can be said when it comes to deciding what processes should be prioritized for investment for new capability. The end-to-end architecture informs where the best opportunity exists based upon the strategic contribution of each process and its current health relative to needs of the end-user. Likewise organizations can assure that the assessment and design of each process supports the overall choice of their value proposition for the value chain and is not sub-optimizing the work results to attain an internal objective.
Aligned
Similar to the goal of traceability, each process in an end-to-end architecture must align with the other processes it interacts with and other management concerns. Outputs of upstream processes act as inputs, guides, or enablers to those downstream. There can be no disconnects and no gaps between the processes. Processes that do send or receive anything from other processes (orphans) are not allowed into an aligned process architecture because they would not be adding to value chain outcomes. The flow of information may not be explicit in the process architecture but it should be easily derived by looking at the process model from start to end. Likewise, a sound business or enterprise architecture model should assure that all operational capabilities are established based on the requirements of the processes that will use them. Furthermore, the roles required to perform the work of each process should be derived from the process architecture model and the organizations responsible for them should be easily discernable.
What Does Good End-to-End Process Architecture Look Like?
Useful process architecture can take many forms. But typically there are several bands of processes grouped by their role in value creation and support of the business strategy. As mentioned earlier, the highest-level classifications are core, guiding, and enabling processes. Within each of these categories there may be more divisions of work processes based on relative closeness to the core activities. Sometimes organizations break out extra categories to satisfy a need from some executives to make some processes more visible to the organization. Figure 3 illustrates a further segmentation.
Figure 3
The core processes are typically focused on the customer and value delivery chain, since that's what the organization gets paid to do. An airline would consider the process 'transport passengers to destination' as core. The core processes will also usually include everything the organization does to bring and keep products and services in market as long as they are viable. Enabling processes include the essential support processes that are very closely linked with the core as a separate band. For example 'maintain aircraft' would fall into the primary core business resources processes for an airline and would be different from the general enabling processes of 'provide staff' and 'build office systems' and the like which are very similar in all organizations. The guiding processes typically include the planning and control processes that manage the core day-to-day or in near time close to the core and may be shown separately from strategy and directional processes which will have their own band. 'Develop flight schedule' is a good example of a close managing core process. 'Set budgets' would be an example of long term and more universal. There can be many variations on this model that are specific to a particular business but this segmentation has served well historically and gains executive buy in without too much difficulty.
Core Processes
Let's briefly look at the development of the core processes for the illustrative example of a consumer bank with guiding and enabling processes at level 1 (each is value stream) and level 1 (value stream) and 2 core processes (Figure 4).
Figure 4
The first step is to take a customer journey (e.g., life of the potential relationship) and trace it from customer unawareness of the organization through to the end of the relationship and find the major transition points where a clear result is attained. This is the point where the state or status of the relationship changes. Then define the process that was executed to achieve the transition point. For customers, and indeed all external stakeholder relationships, there are three main stages that the relationship will go through. These are customer relationship establishment, customer business operations, and customer relationship re-assessment. The customer relationship establishment typically happens once in the stakeholder journey to get things going. The customer business operations processes typically occur on a regular iterative cycle ( the customer orders many times), and the customer relationship re-assessment points occur regularly through typically as scheduled periodic calendar reviews or action due to a specific trigger. This provides the opportunity to enhance the relationship or perhaps to terminate it. Each particular customer will be in a state potentially different from the others at any point in time of course.
Once the processes preceding the transition point are defined, look for the core relationships for business partners that are involved with you to jointly provide service to the customers or provide consumable resources used to provide products or service to them. Figure 5 is an illustration for the bank consumer.
Figure 5
Another example would be the product or service lifecycle (Figure 6), starting with the initial product concept to the end of the product or service life. You can first step identify all the transition points where the state or status of the product or service changes and then define the process that preceded the change or do it the other way around as shown.
Figure 6
Similar to the customer and stakeholder relationships in the first example, there are three main stages in play. These are product or service establishment, product or service operations, and product or service re-assessment. Product or service establishment typically covers everything that happens to get a product or service to market. Product or service operations delivers on a regular iterative service cycle, and product or service re-assessment occurs based on scheduled review or specific trigger to determine the opportunity to enhance the product or service or perhaps to decommission it. Again, different products or services will be in different states at any point in time.
While examining the natural stakeholder journeys or product and service lifecycles, organizations should constantly use reference frameworks to gain knowledge of industry standard processes and sequences and should create or modify the end-to-end process flow based on relevant insights gained from them. Many organizations miss this key use of frameworks and end up missing key activities. Whereas the top levels of the frameworks will sometimes be organized different from what derives from the journey and lifecycle approach, the frameworks will become more and more useful as each of the level 1 and 2 processes are drilled into for specific sub-process identification at level 3 and 4.
Guiding Processes
Level 1 guiding processes as illustrated by our example can be viewed as a holding grouping for its sub-level which is the entire journey for directional, governance, or compliance types of stakeholder relationships such as owners or regulatory bodies. The approach is the same as shown for the consumer cycle above. Directional or constraining guidelines that we manage internally, such as strategies, budgets, or policies of the organization, all follow a lifecycle similar to products and services. By identifying the guiding aspects organizations we can define the top level of the guiding architecture. Each level 1 guiding process will have journeys or lifecycles to make up their level 2 processes. The use of frameworks in this domain is very helpful since these frameworks often have full cycle views of such organizational assets. The APQC frameworks are particularly strong in these aspects.
Enabling Processes
Level 1 enabling processes can be viewed as a holding grouping for its sub-level which is the entire journey for reusable resource provisioning stakeholders, such as human resources (not the department), facility or technology provisioning relationships. In addition, the internal supply of resources such as equipment, technology, or people all follow a cycle similar to products and services with a clear beginning and end. Each level 1 enabling process will have clear demarcation points in the journeys or lifecycles for their level 2 processes. Like guiding processes the use of frameworks is beneficial. The APQC framework is, again, quite strong for these categories of processes.
Speak Your Mind