(no title)

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.

Value-Driven Business Requirements

In our last post we considered the importance of focusing process design on business value by first identifying business metrics, and then identifying the actions required to drive metrics toward optimality. This introduces the concept of a business requirement.

Businesses specify requirements to orient both process and solution designs, but we seldom stop to ensure that we agree on what we mean by this term business requirement. Since this concept is the foundation of solution and process design, let’s define it intelligently.

Again, thinking simply (not simplistically), a business comprises people working together to achieve business goals. Their activities impact business metrics, so each person must act in a particular way to optimize these metrics. These required activities, which people need to perform to achieve the goals of the business, are the true business requirements.

Business Requirement: an action necessary to achieve an objective or optimize a business metric.

This definition is evidently reasonable since it is derived explicitly from the business context, and is designed to enable business goals.

This definition may seem non-intuitive at first, since we often associate the term business requirement with a particular capability required in an enabling automated solution. The problem here is that we confuse the design of a supporting application with the activity that drives business value. The business likely does not understand new enabling technologies well enough to specify configuration and capabilities, called Functional Requirements; it is the job of the application expert, not the business, to identify and validate which capabilities best support required business activities. When the business tries to prescribe the solution design rather than focusing on optimal behaviors and workflows, process and solution designs tend to be sub-optimal.

The ideal structure of a business requirement is thus always: Verb+Noun, an action (verb) performed to produce a given result (noun). For example: Resolve Late Orders, or Generate Production Schedule. Once we define what people need to do to optimize business metrics — in other words, we define the business requirements — then we can define a business process, the steps required to get the right things done in the right way, and see how the terms are related.

In our next post we consider a complimentary concept that also needs to be fleshed out in order to effectively design any business process: the business role.

Value-Driven Process Design

Value-driven business process design (BPD) starts with a focus on value: how to create it and how to measure it. Before we design a business process, we need to identify the business metrics we intend to improve, what behaviors impact each metric, and the desired target values. This is easier said than done.

The first step is to identify the business objectives, why a given business exists. The business objectives are the business goals, what the business is trying to achieve. To determine how the business is doing, how well it’s meeting its objectives, these goals must be expressed in a quantifiable manner and consistently measured and tracked. These measures are business metrics.

Business Metric: a quantifiable measure used to track and assess the performance of a specific area or activity.

These measures, the business metrics, include concepts like Late Orders, On Time In Full (OTIF), Return On Investment (ROI), Cost of Goods Sold (COGS), Inventory Turns, etc.

Once the business objectives are clearly defined, we need to identify the key behaviors which impact these metrics, in particular those behaviors which drive metric trends toward optimality. Once we do so, we can define how business roles must behave in order to drive business value.

It’s easy to skip over this basic step of identifying and carefully defining the key business metrics to be impacted by BPD, and assume they are clearly understood and will be met. Yet this lack of explicit focus on business value can easily result in inefficiency, an inability to realize the ultimate benefit desired from the BPD, so it is a very good place to begin.

Starting a BPD engagement by identifying the key business metrics that are expected to be impacted by the BPD, defining them clearly and designing each business process in the context of optimizing them, and benchmarking these business metrics at the point where the new BPD is enabled, is key to effective business process design.

In our next post, in order to drive optimal business value, we’ll define a key term, business requirement, in what might appear to be a non-intuitive way.

Planning, Schedule, Execution: Implications

In our last post we considered Execution in the context of Planning and Scheduling; now, let’s summarize our findings and consider why and how we uniquely consider these domains.

To accomplish an objective we plan: we break our objective down into a series of steps we can follow to achieve it efficiently. We include sufficient detail to reasonably ensuring feasibility, more detail in earlier steps. We measure how well our plan meets our objective, how well we’re following our plan, and re-plan remaining steps as circumstances change. The better we plan, the more likely we’ll succeed.

We schedule when efficient task sequences aren’t obvious. Finding an optimal schedule is likely impractical, so we often use specialized logic and tools to help us out, looking for good answers fast. “A bad schedule from a good plan is better than a great schedule from a bad plan.” (S. Sidhu, i2)

We plan/schedule to help us execute: to do the right things at the right times in the right ways to efficiently achieve our objective. We freeze the portion of our plan/schedule required to preserve prep time and leave it out of our re-planning/scheduling workflow, managing reality real-time during execution.

For several key reasons, we consider these three domains separately and uniquely.

The objective in each domain is unique, so the tools and logic employed in each should suit the relevant objective.
The horizon in each domain is unique: Planning considers the entire unfrozen horizon; Scheduling considers an initial, smaller unfrozen horizon within the plan; Execution considers the frozen period.
The measure of success in each domain is unique: Planning considers the final objective(s); Scheduling considers localized efficiencies within the plan context, and Execution considers work quality and conformance to the plan/schedule.
The detail required in each domain is unique: Planning has just enough detail to reasonably ensure high level, overall plan feasibility; Scheduling requires significantly more detail to ensure efficiency and executability; Execution must manage to all of reality in real time.

Planning, Scheduling and Execution: considering planning theory and recognizing similarities, differences, and interdependencies helps us position the proper skill sets, logic, tools, workflows and data within each domain, and to integrate them effectively to ensure success.

Planning to Execute

In our last post we considered Scheduling in the context of Planning; now, let’s explore how both Planning and Scheduling enable Execution, noting their respective roles and analyzing their interdependencies.

We plan/schedule to help us execute: to do the right things at the right times in the right ways to efficiently achieve an objective. But in a dynamic world we’re constantly adjusting plans/schedules to reflect reality, which begs a key question: What parts of a plan/schedule can we change without sacrificing productivity?

We want our plan/schedule to reflect reality as much as possible, but we also need sufficient plan stability to avoid generating waste, getting ready to perform one task and then doing something else. So, inside this lead time we don’t re-plan (except for major disruptions, when such waste is warranted), and work with older data. This first part of the plan belongs to Execution, defining a frozen period, a boundary enabling us to consistently re-align our plans with reality without sacrificing efficiency.

Planning/Scheduling workflows need an accurate picture of the conditions expected at the Execution boundary, at the end of the frozen period. Given this starting condition, re-planning/scheduling can align plans with Execution, closely reflecting reality without destabilizing our work environment. When Execution experiences a major disruption, requiring a relaxation of all or part of the frozen period to enable more complete re-planning, execution and planning/scheduling workflows and interfaces should be designed to provide this capability.

Though planners may request visibility to frozen plan details within planning/scheduling workflows, such detail is irrelevant for planning/scheduling purposes. Providing it can actually be problematic since planning/scheduling tools generally approximate reality, not fully considering execution-level detail. Execution may work the plan/schedule in ways that violate simplistic constraints and interdependencies inherent in the system-generated plan/schedule, making accurate representation in planning/scheduling systems very difficult or impossible, encumbering and possibly destabilizing planning/scheduling workflows.

Now that we’ve explored planning theory and analyzed the relationships and interdependencies between Planning, Scheduling and Execution, in our final post we’ll take a step back and look at the big picture to summarize what we’ve found and why it’s important.

Planning to Schedule

In our last post we considered planning theory as a unique problem solving domain, so now let’s compare and contrast Planning and Scheduling, understanding how they work together.

In most every plan we’re following a series of steps, tasks following one after another, where task order is driven by their interdependencies. But when we have some flexibility and certain task sequences are much better than others, then we have a separate scheduling problem within our planning activity that deserves special attention.

Scheduling looks at small subsets of tasks within our overall plan, within a much shorter horizon, considering much more detail and using different measures, to generate efficient task sequences. It requires a completely different skill set and supporting capability than Planning.

For example, say we have some jobs lined up and hourly employees staffed to do them; each job has multiple steps that can be done in any order by anyone, but our staff has varying pay grades and skill sets, each being much more efficient at certain kinds of work. We want jobs done on time with the least cost.

We start by planning, sorting jobs by need time and estimating how many staff we need each week based job types and historical patterns. Then we task our trusty scheduler with finding least-cost weekly assignments, utilizing each worker between 20 and 60 hours per week, completing all jobs on time. In week one we plan four people to do a set of five jobs, each having three steps; if our scheduler evaluates ten thousand schedules per second, we’ll have the least-cost schedule for that first week in … (4*15!/[1E5*3600*24*365] = ) … 16 years!

Every type of scheduling problem is different, but we know in general that they’re notoriously difficult to solve optimally, being in an altogether different space than planning. Their difficulty is often completely independent of planning complexity, and varies enormously by problem type and size. We need good answers fast, not perfect answers, using common-sense rules of thumb to simplify problems and very specialized optimization tools to do the heavy lifting.

And we can’t forget that every scheduling problem is embedded within some kind of planning problem, and that the inputs to our scheduling problems come from our plans: “A bad schedule from a good plan is better than a great schedule from a bad plan.” (Sanjiv Sidhu, i2 Technologies co-founder)

Next we’ll explore how Execution fits in with both Planning and Scheduling.