I have worked with several organizations that embraced the principles of BPM, selected a Business Process Management System (BPMS) platform, found it easy to deploy the first process automation solution, and then struggled to scale BPM across the organization to reach the level of process unification and standardization they originally aimed for.
As I will explain, this typically happens when you invest in process automation before having developed a sound business process architecture. By "business process" I am referring here to the logical description of the sequence of activities that an organization performs to produce a valuable outcome, independently from their level of automation. A sound architecture will maximise the value delivered by business operations by defining processes that are easy to manage, and can be reused and composed in larger value chains. In the article, I'll show how to achieve this architecture by designing processes that have well-defined responsibilities, clear ownership and are loosely coupled from each other.
Several articles already published on developerWorks have discussed how to classify and decompose processes on the basis of technical dimensions. My aim, however, is to apply architectural thinking to the business domain. Before even considering technology, how can you establish when a process starts and when it ends? What are its core responsibilities and its relationship with the other processes of the organization?
The basic technique of decomposing high-level process steps into subprocesses, at different levels of granularity, cannot be used on its own to develop a mature architecture. In my experience, this works only in those limited scenarios in which the business can be described simply as a linear sequence of activities and each functional area live in isolation from the rest of the organisation. This article presents a more holistic perspective of the design of a process architecture and to the definition of its components.
The level of complexity of an enterprise-wide business modeling initiative can be daunting. The risk of trying to "boil the ocean" is always high; defining a clear scope can make the difference between success and failure. To do that you need to have a frame of reference shared across the organization. This can be provided by a capability model: a high-level map of what the organization does in which each component represents a logical function, internally highly cohesive but loosely coupled from the others. IBM has developed a set of capability maps for every industry, called Component Business Models (CBM). The maps are organized in rows classifying levels of accountability, from strategy to control and execution, and columns designed around the different areas of the enterprise value chain.
Because the elements of a capability model are internally highly cohesive and loosely coupled from one another their boundaries provide valid guidance for carving the scope of a process modeling effort that will not have too many external dependencies. You should also not underestimate the value of being able to communicate in one page the scope of your effort in the context of the overall organization, just by highlighting the components addressed, as shown in Figure 1.
Figure 1. Component business model for retail banking
Once a clear scope is defined, how do you go about deriving a coherent architecture? As mentioned above, the most traditional techniques of process decomposition are insufficient in this regard. When you decompose coarse-grained activities into subprocesses you are analyzing only the behavior of the organization. There are at least two important dimensions missing: structure and information. A holistic approach should then leverage three complementary techniques: process analysis, structural analysis and information analysis.
You can think of a process as an organization's behavioral response to the demand for a product or service coming from someone within or outside of the enterprise. Process analysis focuses on how the organization works, breaking down each high-level process into more fine-grained activities, at different levels.
For example, let's consider the case of a car rental company. Figure 2 shows a decomposition of how the organization supports the customer demand of renting a vehicle.
Figure 2. Rent Vehicle behavioral decomposition
A structural analysis, on the other hand, looks at what the organization is made of and decomposes each high-level function into smaller, more discrete areas. As each functional area is being analyzed and described in terms of its responsibilities, it is also positioned in the larger context of its relationships to other functional areas.
The collaboration between functional areas finds direct mapping into the enterprise processes, indeed the two analysis approaches tend to converge after a few levels of decomposition, when a fine-grained function can be matched to a single activity in a process.
In our example, shown in Figure 3, Rentals and Reservations supports most of the customer-visible aspects of the rental experience, however Promotion Management and Price Management control the rental pricing, while Fleet Management is key to providing vehicle availability and delivery. Any issue faced by the customer before the vehicle is returned goes through Customer Service.
Figure 3. Structural decomposition of Car Rental operations. Components highlighted in red have a direct role in rental-related activities
Structural analysis and process analysis are complementary: the first is most effective at a very high-level of abstraction, for example for impact analysis and programme scope definition, while the second is most appropriate to decompose the business at a lower level of detail. It is therefore important to use the areas identified through structural analysis as a taxonomy for the activities modeled in the behavioral (process) analysis. This will help to identify common activities executed across multiple unrelated processes.
Often data is treated as an afterthought in the definition of a BPM solution. Activities and their flows are the main abstractions used by the business and design community. Only at a later stage do you realize that key terms like "account", "customer" or "product" have different meanings across different parts of the business. This leads to unmanageable variations in the process implementation. A business glossary, sometimes referred to as a data dictionary, is a foundational artifact that should contain precise semantic definitions, agreed to across the organization, of the terms associated with an initiative. A data model is also critical to specify the relationships between the information objects as well as their key attributes.
Information analysis also plays an important role in process decomposition, helping to untangle the description of business operations. The idea is to shift the focus of business modeling from the "actions" taken to the "entities" that are acted upon. These entities such as an Order, a Request, a Plan, or an Invoice are the information used by enterprises to keep track of their business operations; they are the core conceptual objects that are created, evolved, and (typically) archived in a process. For example, when bank customers withdraw money from their accounts, they fill out a withdrawal slip and pass it to the teller. The teller uses the slip to check the details of the customer account and, depending on the amount, requests a manager's approval. The manager approves by signing the slip and returning it to the teller, who hands out the requested money to the customer and then files the slip for the bank records. Although names such as account and customer are mentioned in the example, the "withdrawal slip" is the key business entity which captures all important data pertinent to the withdrawal process: describing its lifecycle is an effective way to describe how the process works.
The analysis of business entities lifecycles provides an additional perspective that combines data and process at a fundamental level. A business activity should always produce some meaningful value-adding change in the state of a business entity. If a business activity does not bring such changes, that activity can either be removed or combined with others. A process can then be seen as the management of the lifecycle of a core entity, where each state of the cycle corresponds intuitively to a business-relevant state. Adopting this modeling approach leads to a more modularized and loose coupled process architecture.
Take the example of an IT service provider with customers distributed across multiple sites. Services might include IT provisioning, installation, and maintenance as well as general support. The activity flow in Figure 4 could be used to describe what the organization does to serve a customer request.
Figure 4. IT service provider operations described as an activity flow
This simple model must be tested against the complexity of real-world operations. For example, a request for cancelling the order could be received at any step of the process flow - what is its impact into the invoicing and planning activities that might already have taken place? Or how is the Plan Schedule activity taking into account the requests coming from multiple orders to maximize the operational efficiency?
You can see how a modeling approach based only on the description of a rigid flow of activities can quickly evolve into extremely complex flow diagrams. This usually leads to process models that do not cover all the business scenarios (in particular exceptions) or enforce unnecessary dependencies between activities.
In a business entity-centric model, the same process could be described as the lifecycle of three business entities: Order, Invoice and Workforce Schedule. Separate event-driven processes will coordinate the business activities related to the lifecycle of each entity, as shown in Figure 5.
Figure 5. Core entities for the IT service provider operations
This approach leads to a better architected business. The increased modularization and loose coupling of the model has a direct business value, including the ability to identify opportunities for centralizing business operations and to make an efficient use of available resources.
It's very common, for example, for a business to run activities that are duplicated, with unnecessary variations, across different product lines. On the other hand, in the example in Figure 5, the business entity lifecycle representation suggests decoupling invoice processing from any process variation that might be specific to the fulfillment of different order types. This model also highlights the opportunity of optimizing the scheduling and delivery of work across multiple orders.
The techniques described above can be used to discover candidate building blocks for your process architecture. These "bricks" will be still in a rough state though, with blurry boundaries and identities.
For example, consider the decomposition of the Sales and HR processes of a bank. In Sales, when on-boarding a new customer, the bank executes a Customer ID&V process to verify that the customer is who they claim they are (ID&V stands for identification and verification). On the other hand, in the HR domain, the bank performs an Employee ID&V every time a new person joins the organization. Are these two different processes, or the same one (see Figure 6?
Figure 6. Decomposing different business domains might identify similar process areas
Process decomposition in itself is not going to answer the question, further analysis is required. This section presents multiple dimensions for that analysis (summarized in Figure 7), aimed at defining clearly what the responsibilities of a process are. Note that this section is deliberately titled "business process definition" and not "specification": the primary aim is to describe how to identify the boundaries of the process rather than to get to a complete specification of its behavior. Indeed, too often in the field we run the risk of jumping into business process "specification" without making a conscious definition of the scope of the process under consideration.
Figure 7. Business process definition dimensions
Process ownership defines who has the ultimate responsibility for what the process does and how it is managed. A lack of clear ownership will make any process unmanageable as soon as it is rolled out. This is particularly evident in BPM initiatives that aim at process simplification and unification. Consider an organization in which different departments run independent variations of the same process. What will happen when a new common process automation solution is deployed across departments if the process ownership structure is not changed as well? Multiple owners, motivated by different business drivers, will soon find ways around IT and processes will diverge.
Back to the example of the ID&V process in banking: a common process for customer and employee ID&V would require a single owner. Where would he or she sit? In HR or in Sales? In either case, this seems to introduce unnecessary dependencies between departments that, by their nature, tend to be quite independent of each other. This consideration hints at the opportunity to model and manage the two processes as independent assets. Actually, an analysis of the value proposition of identification and verification (described in the next section) demonstrates that the Anti-Fraud department of the bank is the natural owner of all the ID&V activities.
Each process should have a clear proposition of the value offered to its customers, internal or external to the organization. This value has to be weighed against the cost of the activities and resources required to provide it. Difficulties in articulating the value of a process might indicate that its scope is too narrow or too wide.
In our example, the value of both of the ID&V processes, in Sales and HR, is to reduce the fraud exposure of the bank by ensuring that the person the bank is dealing with is the person that they claim to be. This is a clear indication that the two processes could be unified into a single solution, as shown in Figure 8.
Figure 8. Sales and HR leverage a single ID&V process, owned by Anti-Fraud
Processes provide value to customers by performing key activities and leveraging valuable resources. Assessing what those activities and resources are helps in defining the process scope and separates key process requirements from the details of its realization.
The example in Figure 9 shows what an ID&V process might look like. The process verifies information about the individual collected from third parties, as well as from documentation directly provided by the person under ID&V; for example, the copy of a passport.
Figure 9. A sample ID&V process
The area highlighted in purple describes activities focused on the processing of documentation. These require human and technical resources with document handling capabilities that are not strictly related to ID&V. We can therefore consider those activities as a separate process, Receive Document, able to work with any document (not even related to ID&V), store it, associate it with a reference and broadcast the information to any process that might be interested in it. Indeed Banks usually have Document Management functions with these responsibilities, as shown in Figure 10.
Figure 10. Document handling activities can be factored out of ID&V and made reusable in a broader context
A process must clearly identify its customers: the actors who are going to receive value from it. A customer could be internal or external to the organization, it could be an individual or it could be another process. A dramatic variation in the number and type of customers will have a considerable impact on a process design. On the other hand, a process with a single customer might be better modeled just as a private component of a bigger process.
Processes can delegate the execution of some of their activities to external suppliers, again within or outside the enterprise boundaries. When defining a process, it's important to evaluate whether any of its activities can by themselves form an independent process that can stand on its own and provide value to different parts of the organization. This was the case for the Receive Document process in our example, as shown in Figure 11.
Figure 11. Customers and suppliers of the ID&V process
Actually, following "lean" best practices, the identification of the process customers should be a prerequisite to the definition of its value. That certainly makes sense and is a good practice; on the other hand, in this article I am not trying to suggest any sequencing too rigorous in the analysis of the nine process dimensions. In my experience, the definition of a process is a journey that involves a few iterations across the different aspects presented here and the clarification of one dimension will often cast a new light onto others that have been already assessed. For example, following the ID&V example, you can see how value has influenced the decision on ownership, and the latter has transformed HR and Sales from potential process suppliers to process customers.
An analysis of the information model of the process should start by verifying that the core business entity that changes state throughout the process has been clearly identified. In our example, this points out the fact that the core entity is not a Customer or an Employee, but simply a Person.
The information model should also define inputs and outputs, as well as a source for the entities that might have emerged from the analysis of all the other dimensions of the process. A good practice is to include in the scope of the process only the minimum set of information required by the activities that provide the core value, and leave any other context information under the control of its customer.
For example, the way in which ID&V is performed in the context of Sales can be highly dependent on the type of product a person is applying for. If you apply for a loan, the bank might want to perform a type of verification stronger than the one required for a savings account. If "Product" is a process input, ID&V will need to have knowledge of the all the bank offerings and the rules that will assign different verification levels to different products. An alternative approach could be to keep any product knowledge outside the process and have the process requester specify as an input only the verification level required. This single change in the input definition dramatically simplifies the process and makes it more reusable for employee on-boarding. Indeed the concept of product doesn't have any meaning in HR, while it would make sense to request different verification levels depending on the position a person is joining the organization for.
Events are triggers of process behavior. The best way to identify process boundaries is to look for start and end events. Start events are usually related to the action of a customer, and linked to the passage of time or to a certain entity state (for example, the balance of an account reaching a pre-set threshold). On the other hand, end events are usually related to a key business entity reaching a final value-added milestone.
Complex process interactions might involve multiple business events of the types described above, happening at different stages of the process.
Thinking about all the possible exception events is then a good way to surface the complete set of scenarios the process will have to handle and avoid the risk of focusing only on the "happy path" of the activity flow.
In our example, the external events handled by the process include receiving a new ID&V request (the start of the process) and the notification of the arrival of a document. Exception events might be related to the cancellation an ID&V request or a long delay in the delivery of a document.
External key performance indicators (KPIs), for example the average time required to complete the identification and verification of a person, are important to quantify and monitor the value provided by the process to its customers. On the other hand, internal KPIs, including the time spent by process participants on specific tasks, enable management to control the efficiency of the process.
Metrics describing the volume of requests received by customers are also important to establish a basic set of non-functional requirements that any realization of the process will have to satisfy.
Often the outcome of a business process depends on a few complex business decisions that should be made according to company policies. The ownership, lifecycle and information model of those policies can be significantly different from the ones of the process. It is important to call them out and enforce them as business rules decoupled from the process flow of activities.
The business policies relevant to ID&V might include the ones that decide what type of documentation is required for identity verification and those that govern the overall evaluation of risk associated to the personal information collected by the bank.
It is useful to assess in advance the variability of the process against key dimensions, including location, channel, product and end customer segments (see Figure 12). This will inform the decision whether to absorb the required variability into the process, or to create different processes for different variations.
Another aspect to consider is the variability that the process might have to cope with in its future evolutions. Obviously, it's not possible to predict the future, but assessing the predictability, speed, scale and ownership of change will give the service provider the best chance to design the right flexibility points into the solution.
Figure 12. Variability-oriented analysis of a process
As mentioned before, the ID&V process in our example could be designed so that its behavior is independent of any variations in the type of products the bank wants to sell. Other variability dimensions to take into account might be related to the fact that the bank might want to change third party provider in the future or to ask the person under ID&V for different types of documents. The effect of the first change might be very limited, as long as the information exchanged with the third party will remain the same, while the variability in the type of documentation might be managed by a business rule
In this article, I presented complementary perspectives, based on behavior, structure and information, to the decomposition of business processes. I have also discussed nine different lenses that can be used to define the boundaries and responsibilities of a process. These techniques reduce the level of complexity and enable a wider standardization across business operations, enabling the management of processes as valuable enterprise assets.
The author would like to thank Hugh Boyd, Ian Ramsay and Kim Clark for their contributions and reviews of this article.
- Process-oriented modeling for SOA, Part 1: A technique for process
decomposition: Learn about how to decompose processes into
technical components in the context of a Service Oriented
IBM Component Business Model: Find more information on this
component-based approach to strategic change.
- Business Artifacts: A Data-centric Approach to Modeling Business
Operations and Processes: Read this short paper in which experts
from IBM lay out an approach for combining data and process to reach an
holistic description of business operations. (PDF)
- 8020: A new perspective on Business Process Design and Automation:
Learn a simple, business-friendly, method to model processes using an
artifact-centric approach. (PDF)
- Business Process Change: A Guide for Business Managers, BPM and Six
Sigma Professional: Read this foundational book to have a broad
view of all the aspects of a business process transformation.
- Archimate: Learn about an enterprise architecture modeling
language based on the three dimensions of structure, behavior and
- Business Model
Canvas: Find out more about an intuitive business modeling
approach that has inspired some of the techniques described in this
Lean Service: Read a perspective on how to apply "Lean" techniques
to the design of processes in the service industry.
zone: Get the latest technical resources on IBM BPM solutions,
including downloads, demos, articles, tutorials, events, webcasts, and
Journal: Get the latest articles and columns on BPM solutions in
this quarterly journal, also available in both Kindle and PDF versions.
Carlo Marcoli is a Lead Architect in the BPM practice of IBM Software Services for WebSphere, where he specializes in Solution and Enterprise Architecture for the Financial Services sector. He has more than 10 years of experience on BPM and SOA strategy, architecture and delivery, working with customers across Europe and North America.