business process design

BPM vs CM: Designing for Success

Change is essential in facing today’s business challenges, and it will likely become even more so over time, so let’s take a fresh look at it. Perhaps the root cause for transformation failure isn’t in what many call Change Management, but rather in inadequate business process methodology.

Business Process Management (BPM) is the science of designing and improving business processes; Change Management (CM) is the science of helping people transition from Current State to Future State business processes with minimum disruption and uncertainty, and it’s where the blame is generally placed for the 70% failure rate of transformation initiatives.

The definitions of BPM and CM imply significant overlap between the two domains; the similarity is compelling enough to explore what the real differences are, if any. In other words, when we do BPM correctly, shouldn’t this address most, if not all of the CM requirements, and significantly improve the success rate of our transformation efforts?

World-class business process design focuses on fulfilling business requirements driven by business metrics, and defines business requirements as behaviors required by the business (rather than focusing on feature/function). So, presenting detailed Current State and Future State Business processes in this context, as behaviors, should naturally convey the change that is expected of our people in the transition, taking all the mystery out of it and facilitating process adoption for everyone involved. So, if we did this well, engaging everyone in understanding current and future state behaviors, explaining the differences between them at a detailed level and providing a value-based justification for the transition, what kind of change is left to manage?

Certainly, in addition to the actual business processes changing, there might be systems, applications and technical infrastructures that are changing; in fact, the need for system improvements often drives the need for process change. Yet documenting these tool and system related changes, and how user workflows leverage them in Future State processes, is inherent in any thoughtful process design. If we’re doing BPD as we ought, we’re covered here.

There’s also a need for proper user training in Future State processes and workflows, and for engaging subject matter experts and relevant business roles in shaping, defining, and ironing out Future state process details, but best practice BPM methodology takes this into account as well.

What else is left for CM when we’re following best practice BPM? Perhaps the concept of CM as a separate domain has arisen because we’ve not been thorough and thoughtful in our business process design. And perhaps it continues to be a problem because we aren’t thinking about change the way we should, as an inherent aspect of BPM. Addressing transformation failure as a process gap and employing world-class BPM methodology to resolve it is an insight that can drive success.

Value-Driven Business Reporting

Business Intelligence (BI), has been corporate center stage for a while now, but experience tells us that creating a new report for a business and getting it right can be immensely challenging, time consuming, and frustrating.

More often than not, those asking for a new report don’t fully understand what they want, or why they want it, or exactly what to ask for, and those providing the report don’t understand much more. The result can be a number of painful iterations, and significant wasted time and effort. In most IT departments, this type of waste is expensive, in both opportunity cost and monetary cost. What are some keys that can help us collaborate efficiently to get the outcome we need without all the hassle?

The first question to ask when designing a new report, or sprucing up an existing one, is: What action should this report trigger? When a user views the report, what decision(s) are they looking to make? This is another way of stating the business requirement enabled by the report. What does a user want to do as a result of looking at it? This is, by definition, the purpose of the report. Until this is clear, the need is suspect; answer this question before proceeding with any design.

And if we understand what a business requirement is, then we also realize that every well-defined business requirement drives a valuable business behavior, measured by a business metric. This gives the What of our report the needed Why, providing a sense of the business value potential inherent in the report.

Once the purpose and value of the report are clearly understood, the next question to ask is: What data is both necessary and sufficient to inform the user to take this action? The user needs information to act on, not too much and not too little, so determine what this specific information is, what the user needs to know to accomplish their purpose, and how the user is going to interpret this data.

Next, we must source the data, and synchronize it with the user’s purpose. Locate or envision the data store, determine who should be responsible to maintain this data and technical infrastructure, and specify when the data is needed and how often it must be refreshed, so that we understand supporting system requirements to keep the input data up-to-date and accurate. We may determine from this research that the data is not available in any of our systems, that it will be difficult to acquire and maintain, and/or that the user will need to interact with the report to supply additional tribal or business knowledge to get the desired outcome. We may also find that the data is sensitive or crucial to our business, such that special permissions are needed to see or edit it, which implies more difficulty and cost to develop and manage the report.

The next step is to determine how best to present the required information so that the report enables the user to understand what needs to be done with the least possible effort in the shortest amount of time. This typically involves minimizing the number of screens the user needs to view, the amount of scrolling needed, and the number of mouse clicks required to obtain and correctly interpret the relevant information. This usually means maximizing the use of screen real estate by compacting column headers, smart filtering, and eliminating unnecessary detail. Using colors, graphs and pictures to draw the eye of the user to essential details is often a must, and it’s smart to assume the user understands the report and how to use it, rather than designing for a first-time experience, since this will most often be the case and allows for much more efficiency and elegance in the report layout.

With a concept for the report layout and content in mind, it’s time to create a quick and dirty mock up for the users so they can make tweaks and corrections before investing in the final product. There’s nothing like seeing to put things in perspective, especially for those of us with a more visually-oriented learning style.

Finally, now that we understand the data sourcing and reporting requirements, we begin to understand the cost of the creating and maintaining the report, which ought to be justified by the report’s value. So here is where we get ask and answer the key fiscal question: Is the value we expect from using this report worth the cost we expect in developing and maintaining it?

If the expected cost of the report is warranted by the expected value, if the payoff appears to be worth the investment in time and company resources, then it’s time to get to work and build it, working closely with the user community to ensure that the report provides optimal value for our business.

And, last but not least, be sure to document how to use the report and the justification for its design, why the report is built the way it is. This helps train new users, keeps the report’s purpose and value in view, and prevents recycling through bad designs as new people inherit and begin using the report. Provide this documentation on line through a Help button built into the report, so that this information is always readily accessible to everyone with access to the report.

Good reporting design and infrastructure makes life easier for everyone, and can bring immense, ongoing value to our business. So let’s be smart about it, and do it right.

Value-Driven Metric Maturity

In this series on value-driven metrics we have looked at the purpose and structure of business metrics, and have identified a number of characteristics of a world-class business metric design. How do we leverage this information to set our sights on actually making this a reality? How do we get started, and make it happen?

Knowing what we need in each metric through a world-class metric definition, and how each component of the metric fits with the others and completes the whole, allows us to identify inter-dependencies and precedence relationships between the metric elements. This insight allows us to sort the requirements into a series of milestones, forming roadmap for developing a complete metric.

Once we understand the roadmap, we have an intuitive way to classify the maturity or completeness of any given metric, and by extension, the overall maturity of a business metric infrastructure.

Rating	Status	Description
1	Conceptual	identified as useful
2	Manual	calculated and reported manually
3	Automated	calculated and reported with no manual intervention
4	Systematic	consistently monitored in a business process
5	Bounded	trigger points define acceptable behavior
6	Actionable	corrective actions are defined and carried out
7	Detailed	business case details are fully documented and accessible
8	Integrated	placed in the global metric hierarchy
9	Tuned	trend/tension analysis maintains globally optimized trigger point(s)
10	Mature	intrinsic to system governance, enables root cause analysis, and full business value is established

By classifying each metric as above and taking a weighted average across all of the metrics required for a business, based on a relative prioritization of their perceived importance, one may derive an overall maturity score for a metrics system and set goals for enhancing overall metrics capability.

A well-defined metrics system is essential for the value-driven enterprise. Understanding world-class metrics methodology is the first step toward realizing it.

Value-Driven Metric Design

In our last post we considered the importance of defining corrective actions for each business metric: a business process with the specific goal of reversing sub-optimal performance trends, and triggering these corrective workflows by setting metric trigger points which identify an acceptable range of behaviors associated with the metric. These insights identify two key design components of a well-defined metric: trigger points and corrective actions. What are the other components of a world-class metric design?

To define the ideal design for a metric, we must keep its purpose in mind: to drive a business toward optimal performance. What else do we need in a metric definition to enable an enterprise to reach its full potential?

Firstly, a clear description of the metric, its purpose and scope, and its value to the business, should be documented. This should include any business scenarios where the metric is particularly relevant, how the metric is to be understood and interpreted, clear definitions of any special terms used in defining or describing the metric design or intent, why the current metric trigger points are understood to define acceptable business behavior and how these were determined, and how the metric is correlated with other metrics in the metric hierarchy.

Further, each metric requires a formula, or rule of some kind to translate the underlying system behavior the metric is designed to monitor into an objective measure of system performance that can be used to evaluate how well the business is achieving its goals. This formula is normally mathematical in nature, where the metric value and trigger points are numerical, but this need not be the case. Whatever the method for calculating the metric value, to be most effective it must be clearly documented, understood, and agreed to by all stakeholders. This includes the data sources for populating all of the variables in the formula, who is responsible for maintaining this data, and how frequently this data must be refreshed. When there are debates about the correct formula or data sources, these discussions and the resulting decisions should be captured for reference. Documenting this information removes ambiguity and uncertainty related to interpreting the metric and acting on it, which is especially essential when behaviors are evaluated and corrective actions are taken based on the metric.

The business roles and relationships tied to the metric should also be clearly documented and understood, including who is Responsible, Accountable, Consulted and Informed in the execution of corrective actions, and any business consequences for prolonged or significant non-compliance with related business processes. In addition, documenting the history of the evolution of the metric definition, past metric trends, any issues or problems and how they were addressed, why certain enhancements were made by whom and why, all serve to explain and justify current business practices and provide guidance for future deliberations in continuous improvement initiatives.

Finally, the technical details of how the metric is reported should be documented: what is needed in the metric report(s), who interprets the reports, what business decisions are made from them, and how/why these required features enable related business processes and add value to the business. Historical changes to report content and layout should be documented to capture enhancement motivations and prevent regressing back to less optimal states.

Clearly documenting all of this information for each metric, where all stakeholders can easily refer to it as needed, facilitates process adoption and compliance, and enables stakeholders to make knowledgeable, informed recommendations for continuous improvement. The completeness and accessibility of this documentation is a key enabler in driving the business to realize its full potential, and is particularly important in dynamic environments where continuous improvement initiatives require frequent modifications to hierarchical relationships, trigger points, formula(e), data sources, and / or the terminology related to each metric.

In our next post, we’ll consider a world-class metrics maturity model, to help us understand the current state of a metric system, which will help us take steps toward improving it.

Value-Driven Metrics: Corrective Action

In our last post we considered how well-designed metrics enable root cause analysis. Positioning metrics within a global hierarchy of interrelated metrics equips a manager to quickly traverse the hierarchy, drilling down into sub-metrics which are reporting sub-optimal behavior until root causes are identified. But discovering the root cause is just a diagnosis; the real goal is to restore optimal behavior within the system. This capability is provided by identifying corrective actions for each metric.

A metric provides measurable value when it both reports sub-optimal performance, and also triggers responsible business roles to carry out corrective actions: business processes specifically designed to reverse undesirable trends and restore optimum business behavior. When timely and appropriate corrective actions are taken in the context of problematic system dynamics, business goals are achieved more consistently and optimally.

For example, when a Customer Service metric begins trending downward, triggering a root cause analysis workflow might indicate that Forecast Accuracy has also been deteriorating, requiring an update to inventory segmentation and buffering policies, and an update or enhancement to demand forecasting workflows and enabling technologies. If Forecast Accuracy has been stable but inventory targets are still being violated, it might be due to increasing supply variability caused by lack of plan conformance, requiring an enhancement to supply planning capabilities, plan conformance metrics, and a review of execution-level business processes.

As in the above example, corrective actions are often not the same as routine business process execution, since in a well-defined system business processes are inherently designed to produce optimal business behavior when followed correctly. When sub-optimal behavior occurs under such conditions, this is often symptomatic of a systemic, underlying problem with the business processes themselves and/or their corresponding process metrics. This may be due to incomplete or inappropriate design, or to unexpected system dynamics which require an adjustment or enhancement to one or more business processes or metrics. This principle often positions corrective actions within relevant system governance business processes, where problematic situations are often unique and require innovative approaches to resolve.

Identifying effective corrective actions for a given metric requires a thorough analysis of the business behavior being measured, understanding which actions most directly contribute to and influence this behavior, what steps must be taken to most efficiently correct sub-optimal trends and restore and maintain optimal behavior in likely business scenarios, and which business roles are responsible to carry out these actions.

For higher-level KPIs (those with supporting sub-metrics) corrective action often focuses on root cause analysis: exploring the metric hierarchy to understand why a given behavior is occurring and who is responsible to correct it. For base-level metrics (those without sub-metrics), corrective action is often related to parametric changes in planning and/or execution systems, business process or workflow enhancements, training and/or change management. Corrective actions and their corresponding RACI matrices must be well-documented, easily accessible to relevant roles, and continually enhanced as the business environment continues to evolve.

Now that we have considered how metrics should enable root cause analysis and drive corrective actions, next we will look at remaining aspects of a world-class business metric architecture.

Value-Driven Metrics: RCA

In our last post we discussed how world-class business metrics must be designed to optimize a global business system rather than focused on local optima; seldom is the optimal target for a metric a behavioral extreme. Ideal design requires metrics to be defined in a hierarchical relationship with other metrics such that their interdependencies are recognized and respected, and trigger points are set to achieve maximum business value.

Putting each metric into such an hierarchy requires understanding its relationship to the ultimate goals of the business, and ultimately provides justification for each metric in a global context. Metrics which appear to be isolated from real value creation are likely obsolete or irrelevant; these should be carefully reviewed and discontinued unless they can be fully justified as essential for understanding how the overall system generates value.

As parent-child metric relationships are identified and ironed out in the context of a global metrics hierarchy, metric trigger points should be set to drive corrective action which consistently tends toward optimal business value.

Once this hierarchical relationship structure begins to take shape, which certainly takes time and is seldom perfect, strategic metrics can begin to be used to perform root cause analysis: when a key business metric is reporting suboptimal behavior which requires corrective action, and the immediate steps of the business process are not designed to correct this behavior, then if its child metrics are well-defined, one or more of them should also be triggering corrective action, enabling a manager to drill down and traverse the metric hierarchy looking for root cause behavior in one or more supporting business processes, reflected in their respective process metrics.

For example, when a Customer Service metric begins trending downward, it might be noted that Forecast Accuracy has also been deteriorating, or that inventory targets are being violated frequently.

Alternatively, when a parent metric is triggering corrective action which is not directly and sufficiently addressed by its immediate business process steps, and neither are any of its child metrics calling for corrective action, this may be an indication that the metric hierarchy is incomplete, misunderstood, and/or that related metric trigger points are inappropriate. This condition may be used to tune metric trigger points, and/or to enhance/add business processes and process metrics in order to fully understand and efficiently manage the total system.

If in the above example, Forecast Accuracy has been stable but inventory targets are still being violated and no other cause is obvious, further exploration of recent supply plan and production history might reveal that machine breakdowns have been more frequent and longer than expected due to last minute execution-level overrides of planned maintenance, indicating a need to add plan conformance metrics and business process to the metric hierarchy.

In our next post, we will look more carefully at the concept of corrective action, and how defining this carefully is essential is to any business metric.

Value-Driven Business Metrics: Intro

Value-driven business process design focuses on business goals and how to optimize them. The business metric is central in this process; it’s how we identify and measure value creation.

Well-designed metrics help us consistently do the right things in the right ways to optimally achieve our goals.

What are the components of a fully-developed business metric? How do these components work together? What is the best-practice methodology for building and maintaining value-driven business metrics?

Three core principles drive world-class business metric design: value maximization, root cause analysis, and corrective action. First, let’s look at value maximization.

Each metric should be designed to drive business role behavior toward optimally achieving business objectives. The behavior monitored by each metric should therefore be understood in a global context where tensions between conflicting metrics are optimized globally rather than locally in order to maximize top-level metrics.

Designing a metric for this purpose requires positioning it within a structured hierarchy where the inter-dependencies between all metrics are clearly understood in relation to each other and the system objectives, measured by the top-level metrics which all other metrics support. It also requires setting the target value for the metric by considering the impact of its behavior on the global system objectives in an integrated context with other metrics rather than attempting to force isolated behaviors to extremes due to disconnected, sub-optimal targets.

For example, Expedited Freight and Inventory Turns are KPIs which help account for fluctuations in Profit, but they are generally conflicting metrics, inversely related to each other when trying to maximize profit: too little inventory of key SKUs tends to increase expedited freight; trying to eliminate expedited freight tends to require significant inventory buffers. In most supply chains, optimal inventory buffer settings allow for a small amount of expediting and/or stockouts; driving either metric to an extreme would reduce total profitability.

In our next post, we’ll look more carefully at how best-practice metrics methodology enables root cause analysis.

Value-Driven Business Process Detail

In this series, we’ve considered a value-driven context for business process design: focusing on value by defining business processes in light of target metrics, business requirements that people must fulfill, and how each business process defines the steps necessary to drive value. Now, let’s look carefully at the detail of the business process itself. What kinds of detail do we need? How should we document it? What kind of template or structure should we use?

Rather than re-inventing the wheel, it’s wise to begin with an industry standard: SIPOC, and then enhance it to drive optimal business value.

Suppliers – roles providing inputs to the process
Inputs – deliverable(s) provided by supplier(s)
Process – steps required to perform the business process
Outputs – deliverable(s) produced by the process
Customers – role(s) receiving output(s)

This certainly provides a great start, elegantly defining the business process in its proper relational context with suppliers and customers, and explicitly identifying related deliverables. Yet it’s clearly lacking a value-driven orientation, so let’s enhance it. What else do we need?

Stating the obvious, we must clearly identify all business roles directly related to the business process itself, to ensure accountability and quality in execution. We can use a RACI matrix here.

Responsible – The role(s) required to do the work, and perform the business process steps. Often reports to the Accountable role.
Accountable – The role which delegates the work of performing the business process, and ensures prerequisites are met, who is ultimately answerable for correct and thorough completion of deliverables or tasks. Often, this is the manager of the Responsible role.
Consulted – Roles which provide expert opinions when sought (e.g. subject matter experts), with whom there is two-way communication
Informed – Roles which are apprised of progress / completion, with whom there is just one-way communication.

Next, we must clearly identify three kinds of metrics related to the business process: KPIs (key performance indicators), the high-level goals impacted by the key business process, operational metrics (OM), which are lower-level metrics impacted by supporting business and execution level processes, and process metrics (PM) which are designed for each business process to [1] ensure that the business process steps are correctly followed, and [2] evaluate the timeliness and quality of the business process output(s).

All three types of metrics are critically important: KPIs tell us what our objectives are, what we’re aiming at, our destination; OM’s enable root cause analysis to help us correct systemic behavioral problems in our business, and PMs tell us how well we’re executing to our expectations along the way. KPIs are like our flight plan, OM’s are like the supporting navigational instruments in our cockpit, and PMs are the remaining dashboard indicators ensuring that all systems and mechanics are operating smoothly. If we’re missing any of these guides, we’re flying blind; we could be in real trouble and not even know it.

Another key component in any business process, which is very often overlooked, relates to enabling continuous improvement. One or more steps must be defined within each value-driven business process to document and/or report problems and/or opportunities encountered during execution. Design each business process to both heal / repair and enhance itself, or to trigger another business process for this specific goal. There is certainly flexibility in design, but the concept is essential for any business process to remain vibrant and effective in delivering value.

Finally, we should document the required timing, when the business process is executed; it might be scheduled at regular intervals or event-driven, triggered by an input or some other activity, or both.

Here’s a suggested template for documenting a value-driven business process, matching a wide-screen PPT format.

There may be other elements to consider in any given context, but this best-practice baseline should suffice for most environments. I recommend documenting business processes in summary form with the above template, and also in detail in more standard documents. I would love to hear if/how this works for you, and any ways to make it more useful.

Value-Driven Business Processes

In our last post, we re-discovered the hidden talents of people in execution, how business roles optimize team synergy to maximize value creation. Getting the right people to work together to do the right things in the right ways is what business process design (BPD) is all about. And the centerpiece of this design is the business process itself.

To keep everything in context, let’s review related concepts from the last couple of posts. Business metrics are how we measure success, business requirements define what people need to do to optimize these metrics, and business roles define which people are involved in execution and how they relate to each other as a team. But we’ve yet to precisely define how people actually achieve results: this is the business process.

Business Process: a set of logically related steps or activities performed by a business role to satisfy a business requirement.

This is where we get specific about how best to perform business functions. A business process is the set of steps involved when a person in a business role is fulfilling a business requirement; it is simply a more detailed explanation of how a business requirement is met, or accomplished. The business process documents how a person is to perform their role in the most optimal manner, describing what inputs they need from which suppliers to do their work, the steps they need to follow to produce optimal value, and the customers who depend on the timeliness and quality of their deliverables. Without a clear definition of what do do, we can’t expect people to consistently succeed in their roles.

The above definitions relate the terms business processes and business requirement in an interrelated fashion: each of the steps in a business process can be the business requirement for a related child (lower) level business process within the BPD hierarchy, and each business requirement can itself be a step within a parent (upper) level business process. Each activity performed within a business can be viewed as both a business requirement and also a step in a business process, depending on the focus level within the BPD. In this context, it is natural to name the business process after the business requirement that it satisfies, providing clarity and continuity throughout the BPD dependency structure. In addition, these definitions relate the terms directly with the ultimate goals of the BPD, to enable process design which drives optimal value (via business metrics) for the business.

In our next post, we’ll look in more detail at the structure and components of a business process, and provide a template for organizing this detail.

Value-Driven Business Roles

In our last post, we considered the concept of the business requirement, an elusive term at the heart of process design. Defining it as an action necessary to achieve an objective or optimize a business metric positions language itself to help us drive value. But who or what actually drives value in a business? This question brings us to the concept of the business role.

People are at the heart of any business; defining how they work together as a team is as much an art as it is a science. In designing processes and systems to drive value in a business, it’s easy to get our focus on the technology, or the data, or the metrics, and forget the cornerstone of any business process: the person executing it.

Associating the concept of a position with prescribed behaviors required to satisfy a business requirement, and filling this position with a person who understands how to effectively execute a business process, this is how we link people and process and technology together. The cornerstone of this design is the business role.

Business role: A position associated with prescribed behaviors required to satisfy a business requirement and filled by a person.

Ultimately, since it is people who drive value in a business and impact business metrics, properly defining how to operate a business efficiently requires knowing which people should perform which activities, how each activity is to be performed, what skills, training, responsibilities, authorizations and tools each person needs to get their work done effectively, and understanding task interdependencies: how each of these activities impact each other in the course of daily workflows. And as we bring people and technology together in an effective synergy to drive value for a business, we also need to carefully identify the appropriate temperaments required to most effectively fill each business role, and identify the people within the organization who are best suited for each one.

Every business requirement is associated with multiple business roles: those Responsible to execute the related business process and satisfy the business requirement, those Accountable for ensuring the business process is executed optimally and consistently, those Consulted and Informed during the execution of the process, those acting as suppliers providing deliverables as input to the process, and those acting as customers requiring process deliverables, all fill business roles which need to be carefully and thoughtfully defined.

As Sanjiv Sidhu, founder of i2 Technologies, used to say, “You don’t win wars with F-16 fighter jets, you win wars with F-16 fighter pilots.” We can install the finest agile technologies and collect data until the cows come home, but if we don’t have dedicated, skilled, driven people to execute our processes with passion and precision, then we will fail to realize the value we should.

Once we define what people need to do to optimize business metrics — in other words, we define the business roles and requirements — then it makes sense to define what we mean by a business process to get the right things done in the right way, and see how the terms are all related.

In our next post, we’ll take this a step further and tie it all together in the very foundation of business process design itself: the business process.