In the first article of this series, I discussed the current interest in Business Architecture that has been brewing in the last little while and also discussed some of the frameworks that professionals have been looking at for inspiration. The first article was intended to provide an overview of the field and it introduced an overarching set of concepts that we in Process Renewal Group have been successfully using to classify and categorize issues of concern. In the second article, I tackled the challenge of scoping your architecture and the usefulness of selecting what’s in and out based on Value Chains rather than organization charts. The third dealt with the challenge of defining the expectations of the external stakeholders in terms of their core service needs and experiences. The fourth looked at the strategy of the organization from understanding external pressures and threats, looking at various possible futures, looking at the strategic intent (ends) and strategies and tactics (means) and the derivation of a ‘North Star’ for architectural guidance and decision making. All of these are absolutely essential to establish a relevant architecture that makes business sense.
Roger T. Burlton, P. Eng., CMC, firstname.lastname@example.org
Roger will be presenting his seminar Business Architecture: The Foundation for Enterprise Transformation, 6-8 March 2017, London & 27-29 November 2017, London and he will be chairing and speaking at IRM UK’s annual BPM Conference Europe 2017, 16-19 October, London
At this point in the series of articles I will stop viewing the organization or value chain as a black box and will delve inside. I must apologise for writing such a long article. This is an essential part of business architecture and deserves attention.
I will continue to take an external stakeholder perspective using our knowledge of the drivers, goals and objectives of the North Star and especially the nature of the products, services and information exchanged. This will give us the start and end of all comprehensive processes that create mutual value regardless of organizational structure.
What is a business process?
The knowledge we should have now documented regarding stakeholders’ expectations of value and experience, described in article 3, provides a context for our processes which does more to directly connect the other architectural domains than any other. Figure 2 shows the criticality of the Business Process perspective in sychronizing many other aspects of the architecture.
Let’s start out by being clear what we mean by the term ‘Business Process.’ A process perspective provides a critical foundation for effective business operations and change. Simply put, business operations are simply the execution of your business processes. Your processes are your work, done by people or technology. The process architecture organizes the work required to deliver the business strategy. End-to-end processes assure a business perspective in business architecture because they deliver the day-to-day business results to outside stakeholders and provide the measurement structure needed to monitor and manage those results. To be relevant, organizations must start with a robust set of business processes that everyone understands and figure out what it needs to have in place so it can deliver operational business results. It has to start with a clear focus on running the business.
|Business processes are the pipelines that deliver operational results to stakeholders.|
A focus on processes comes from a deep-seated passion for making the business run better not just building systems. That is, improving how processes execute operationally every day in order to continue to deliver value and optimal outcomes. This is job one. It’s what organizations do. It’s how they survive, thrive, and grow. This understanding must come before consideration of technologies or organization charts no matter what is the latest technological fad. A business must start by striving to enhance the performance of business operations end-to-end for customers and other stakeholders. Doing the right work and making the right operational decisions is what processes and business operations are all about. It’s why we get rewarded or punished in the marketplace.
A solid process foundation is needed to connect the dots among strategic intent, business relationships, business capabilities, enabling technology, and human resources to name a few. This end-to-end process structure is essential to achieve digitization or customer centricity goals and ensure that all business resources are optimally aligned towards a common objective and not working at cross purposes. To do this, organizations need to architect their intellectual and physical assets and shared capabilities using business processes as the glue tracing all work to enterprise intent and stakeholder outcomes. A practical, shareable, and implementable business-process-driven change portfolio will ensure organizations choose the right transformation initiatives and optimize operational business outcomes. From this, organizations can scope, analyze, and design new ways of working using process innovation and improvement practices and models. These will help organizations realize any new business model intent and prescribe what’s required technically, as well as organizationally and culturally.
The Business Process Manifesto
The Business Process (BP) Manifesto states that ‘an organization’s business processes clearly describe the work performed by all resources involved in creating outcomes of value for customers and other stakeholders.’ In other words, a business process is not just a list of connected activities but a value creating proposition for external service recipients. It emphasizes an end-to-end perspective, starting with those in our external world as defined in Articles 3 and 4 of this series and working back to our internal operations. These manifesto guidelines emphasize this strategic point of view.
- A business process should create measurable value for customers and other stakeholders by delivering outcomes that satisfy their particular needs and expectations.
- A business process delivers outputs to and receives inputs from external customers and stakeholders as well as other Business Processes within the organization.
- A business process should be guided, formally or informally, by the organization’s business mission, vision, goals, and performance objectives.
The manifesto goes on to say that ‘a business process model represents the fundamental abstract structure and organization of a Business Process or set of Business Processes as described by their activities, their relationships to one another and to the environment in which they operate.’ This structural perspective emphasizes integrity, completeness, and decomposition of critical knowledge. This view is well supported by comprehensive process frameworks such as the Process Classification Framework® (PCF) from APQC. The manifesto also states:
- The complete set of business processes of an organization describes all the work undertaken by that organization.
- A business process model contains all the information required to describe the business process and its environment.
Key Traits of Robust Process Architecture
In order to manage business processes as reusable assets, organizations need to establish a robust process architecture (enterprise process map) that leverages end-to end thinking. A sound enterprise level view of all processes will exhibit some key traits.
Business processes do not directly correlate to an organization’s formal reporting structure. Certainly the work described by the processes in the architecture, at some level of detail, will be performed by people or technologies 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 process structure could survive a drastic reorganization. If the answer is ‘no’ then it is a poor process architecture and will have to be changed often. The architecture can be changed but keep in mind that customers will judge your business by how well you meet their expectations of process delivery, nothing more or less.
|We execute, measure, manage, and improve processes. We build capabilities to serve that purpose.|
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, if they will even expose it. However, there is not always a one-to-one correlation between the two. Each process may have more than one enabling technology in use and each technology is typically employed by multiple processes making shared data available to all of them. 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.
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. This issue is covered in more depth in Article 2 of this series.
True to the proposition of value creation, processes from top to bottom should exhibit a high quality naming structure. Organizations that have effectively named their 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.
Simple Categorization based on Process Purpose:
A process architecture oriented to an end-to-end view of the business is generally partitioned into three major categories: Core, Guiding, and Enabling Processes.
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 any higher 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). This is the actioning of the Mission. It is what the organization gets paid to do. 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 can be extremely important.
Enabling processes provide reusable resources that make it possible to do the work of all processes. Again most organizations go into business to do this type of work but the Core cannot be effective without the right operational capability in place provided by the Enabling processes.
Many models or organizations use the terms “management processes for guiding” and “support processes for enabling.” In my experience, these terms are not clear enough and are often confused with what managers or support departments do or are responsible for, not with the intention of the role they play as part of an end-to-end proposition.
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 so much the variations in ‘how we do it.’ It should also be stable over time unless the business model 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 in many ways concurrently through varying channels and employing a variety of mechanisms. While not a strict rule, approximately three levels of depth are usually sufficient in an architecture with perhaps ten processes per sub 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.’ This is typically levels 1-3. The ‘what’ perspective 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 where appropriate. The customization is often a requirement due to regional and product differences because of varying regulations, norms, systems, and cultures.
As mentioned in the value chain section in Article 2, a well-formed architecture level process should be quantifiable. That’s the first test and the first measurement indicator; how many instances of this process are there? If you cannot answer and a good measure is unavailable, then you may have a poor process definition on your hands. Perhaps it should be and should be re-examined or re-scoped. At a minimum, architectural-level processes should always be measurable in terms of their effectiveness and how well each one meets the expected value received in terms of needs met and experiences satisfied. A later article this year will deal with measurement in depth.
In terms of measurement, from the value chain down to lower levels of activities (more detailed) we should ensure that each process contributes to the value expectations of the recipients. With a well-formed, end-to-end architecture this is easier than when using a functional or organizational view of the work. Again later this year I will deal with this issue from a measurement point of view in depth.
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 to or receive anything from other processes are orphans and are not allowed into an aligned process architecture because they would not be adding to value chain outcomes. Typically these are just not well designed and the architecture needs revision to find the right fit for them. 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.
What Does A Good End-to-End Process Architecture Look Like?
A process architecture can take many forms and can be easy to do. I have seen a lot of variation, however, and sadly most are not useful for actually operating or managing the business or creating value. Most are too functional, meaning they often line up too conveniently with the organization structure and therefore are not versatile enough to withstand an organizational realignment. That’s what you get when you start by asking people in the organization ‘what do you do’ as opposed to starting with the external stakeholders and the products and services they deliver, create and receive. Another potential pitfall is architectures mostly created by blindly copying a process framework. Frameworks can be extremely useful, but most do not deal with end-to-end value creation well, although they may have a lot of the bits and pieces needed somewhere. They have most of the parts but the assembly of them into a working value chain is often a problem. I know that all the parts to build a car are in the car parts catalog but those parts are not categorized by how you want the car to drive. A useful process architecture must be built from the point of view of the work that must be performed to add value along a chain of activities all the way out to the external world. That means coming inside starting from the outside and being agnostic to the organizational groups or the parts catalog. The parts have to be assembled for a purpose.
Useful process architectures have several common characteristics. The first is a macro classification into bands of processes grouped by their role in value creation for customers 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. Consequently some industries lend themselves to extra distinction professionally and politically. 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 further segmentation possibilities.
Further High-Level Process Categories
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 and I hope that includes ‘with luggage.’ The core processes will also usually include everything the organization does to innovate, bring and keep products and services in market as long as they are viable and remove them when they are no longer so. 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 farther you get from the Core you can expect to see more cross industry generic processes. The guiding processes typically include the planning and control processes that managers employ to keep the core day-to-day working at their best in near time. These are shown 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.
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 level 1 process is a value stream within the value chain and represents a logical progress in value contribution to the end stakeholder goal of the value chain. Within each level 1 is a set of level 2 core processes. In Figure 4 P or S stands for ‘Product or Service’.
Since the main focus of the core are the recipients of our goods and services it is logical to look at what interactions we have with the customers over their whole experience with us. The first step is to understand the 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 and we deal with them or they with us differently. Then we can 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 hopefully orders many times. We may provide a service on a calendar basis once a month for example, and the customer relationship re-assessment points occur regularly through typically scheduled periodic calendar reviews or action due to a specific positive or negative 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 main transition points 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.
Bank Consumer Example: Processes and Transition Point Connections
Since our business is all about our products and services we must focus on how we gain the best mix of them in the right market at the right time and for the right prices. This is a second perspective on the core; the product or service lifecycle (Figure 6), starting with the initial product or service (P or S) concept all the way through to the end of the product or service life. Once again, we would 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.
Generic Product or Service Example
Similar to the customer and other stakeholder journey 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 into market from the time a fragile idea was conceived including a lot of processes that make a go/no go decision. Product or service operations deliver on a regular iterative service cycle, and product or service re-assessment occurs based on scheduled review or specific triggers 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 differently 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.
Level 1 guiding processes, as illustrated by our example shown in Figure 4, can be viewed as a holding grouping and one is required for every guiding or constraining concept or item that must be managed. Typically this includes self-contained Level 1 processes for dealing with strategies, policies, budgets, regulations and other governance issues and the entire journey for directional, governance, or compliance types of stakeholder relationships such as owners or regulatory bodies. Each has its own sub-levels (level 2 on down) similar to the core journeys or cycles. The approach is the same as shown earlier for the consumer cycle and the pattern is similar with regard to the three major stages. Directional or constraining guidelines that we manage internally, such as strategies, budgets, or policies of the organization, all follow a lifecycle similar to stages seen in products and services. By identifying the guiding aspects of organizations we can define the top level of the guiding architecture. The use of frameworks in this domain is helpful since these frameworks often have full cycle views of such organizational assets. The APQC frameworks are particularly strong in these aspects. Figure 7 shows an illustration for the Level 1 process ‘Mitigate Regulatory Risk’. The other Guiding Level 1 processes will follow a similar pattern.
Level 1 enabling processes can be viewed as a holding grouping for everything in its sub-levels (2 on down) 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 provision and optimization 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. By identifying the enabling aspects of organizations we can define highest level of the enabling architecture. Like guiding processes the use of frameworks is beneficial. Figure 8 shows an illustration for the Level 1 process ‘Provide Facilities’. The other Enabling Level 1 processes will follow a similar pattern.
Describing a Process
Every process still needs a full description of its attributes. Not all of the information will be available or known when doing the early parts of architectural work but at some point in time, once it is better understood and some design decisions have been made, the contents can be documented. This information is an important complement to the graphic models and should be stored in an appropriate repository along with the pictures. An Illustration for one of the processes in our banking model is shown as Figure 9. The template is applicable for any level of process description and will cascade along with the decomposition of processes themselves.
Connecting the Dots
There are several ways that organizations can connect processes. Many start at the detailed task level and show pure workflow sequencing but this is at a detailed level of work and the volume of activities is vast. These bottom up approaches are well supported by traditional model types such as BPMN where the question of ‘who does what next’ is most appropriate. The notational advantages of sequencing at such a workflow level are not realizable, however, for architectural work since they do not handle or make visible the exchange of value with other architectural processes and where sequence is very hard to discern. To trace value it is much more useful to create a view that examines product, service and information exchanges (provided or received). Figure 10 illustrates this perspective. This is a powerful way to connect the architecture and keep it measurable and focussed on value creation. Fortunately, with the architecture concepts defined in the model described to this point we can describe each process’ scope in terms of such exchanges and its connection to strategy and stakeholder expectations. In the Process Worksheet in Figure 9 you will find four scoping questions covering the Inputs as well as the Outputs from the process in scope. In addition, there are questions of the provision of guides and enablers for the process. These are different in terms of the role they play with regard to a process action. They are not inputs to be transformed into outputs but are critical to the success of the process in question. In addition many processes produce outputs that are not changed in every subsequent process but are used over and over again such as a business rule to be consistently applied to make a decision in every transaction or a system to always be used when making a calculation. For an architecture with integrity, every input, guide or enabler must come from either another architectural process or an external stakeholder; nothing else and no one else! Likewise, every output can only go to another architectural process as an input, guide or enabler or to an outside stakeholder; that’s all! An architecture with integrity cannot have disconnected orphans.
There is a tremendous advantage to this approach which I pulled together based on the concepts of IDEF0, in the mid nineties and that is its data or information orientation. If we can find everything that moves between pairs of processes then we can identify the information requirements of the organization or value chain since processes create, update, or delete such information or perhaps just read it and take no action. Regardless, poor data quality of information leaving a process means there is something wrong with that process or one of its predecessors. The role of Information Management will be treated in an upcoming article. This Input, Guide, Output, Enabler (IGOE) model is also ideal for initial scoping of process improvement or Lean projects since it proves traceble integrity back to the architecture and the strategy of the enterprise. Managing scope is eminently manageable with this starting point.
The business process knowledge gained and made available here should produce more than a nice picture. The configuration is the structure of operational work and the basis for measurement and capability to optimize the ability to do work. It is the heart of the business pumping the blood through the organization’s arteries and veins. It tells you what is important to be good at regardless of what your organization chart says. It is the basis of operational governance and change decisions. It is a view based on value creation and that’s what we are striving to achieve. The performance management system will connect to the top of the strategy and process scorecard and all the way down to the detailed elements of everyone’s work. But that’s the topic of the next article in this series.
That’s the way I see it. Comments would be appreciated
Roger T Burlton, P. Eng., CMC, is the President of Process Renewal Group and co-founder of BPTrends Associates, the services arm of the BPM knowledge portal BPTrends.com. He is the author of the thought leading book ‘Business Process Management: Profiting from Process’. He is considered the industry leader in the introduction of realistic ways of implementing enterprise BPM programs as well as innovative approaches for organizational and process change. He is the editor of the ‘Business Process Manifesto’ which is now available in fourteen languages. He is regarded as a realistic practitioner, who delivers pragmatic solutions for his clients. He has helped over one hundred organizations implement BPM as a corporate strategy in many different industries, countries and cultures. An exceptional speaker, he has chaired over forty high profile conferences on Advanced Business Architecture and Process Management around the world. To date, he has conducted over seven hundred seminars and has presented to over sixty thousand professionals. His seminars have been translated for diverse audiences around the globe.
Copyright © 2016 Roberto Burlton