Introduction

Business Process Design (BPD) is the activity of defining how people work together to achieve complex business objectives, and explaining this design to the business so that it can be understood and applied. BPD comprises an entire consulting industry, yet the terms used are often ambiguous, which tends to foster miscommunication and drive inefficient behavior. In particular, the term Business Requirement, the key input to BPD activity and impacting the entire scope and objective of any BPD engagement, seems to be the most critical term and yet also the most confusing.

In practice, the term business requirement is often used to refer to any functional capability or solution characteristic considered beneficial for a business, basically any perceived business need. For example: Respect Lot Sizing, or Consider Storage Constraints. Such use of the term focuses attention on features and functions rather than on how these feature/functions need to support business activity to best enable desired outcomes.

The problem with this language is that businesses often do not fully comprehend the optimal To-Be solution at the outset of BPD (which is why they engage in it), and have a tendency to impose As-Is functional requirements into the To-Be process and solution design since the As-Is state is more familiar, and thus more easily accepted and understood. However, this tendency lends itself to inappropriately constraining the To-Be design, looking backward rather than focusing on future state business goals and designing To-Be processes which maximize business benefit. The choice of language and terminology itself can actually influence this behavior, directly affecting To-Be processes and solution design. Poor BPD behavior can be minimized or perhaps eliminated simply by using language which maintains focus on business activities and how best to structure and enable them to optimize business metrics.

Clarifying what is meant by Business Requirement, and relating this to terms such as Business Metric, Business Process, Functional Requirement, and Technical Requirement, is thus a key to BPD success.

Business Metric

Let’s start at the top, with 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, and to most profitably drive business behavior, these goals must be expressed in a quantifiable manner and consistently measured and tracked.

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.

This term, business metric, is commonly understood and easily agreed upon in a BPD engagement, but is seldom given appropriate focus during the BPD itself. It is easy to skip over this basic step of identifying and 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 inefficient BPD, and in an inability to realize the ultimate benefit derived 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 a very valuable.

Business Requirement

Once we have agreed on what we mean by a business metric, it is essential that we identify specific business requirements that must be satisfied to maximize these metrics and achieve the goals of the enterprise. But to effectively identify a business requirement we must first agree on what the term means, and this is where confusion inevitably begins; this term, in particular, must be carefully and thoughtfully defined.

Again, thinking simply (not simplistically), a business is composed of 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.

The 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 what we mean by a business process to get the right things done in the right way, and see how the two terms are related.

Business Role

Next, to satisfy business requirements, the actions necessary to achieve business objectives, we must intelligently engage people to perform these activities. Ultimately, it is people who drive value in a business and impact business metrics, so properly defining what is required to operate a business efficiently requires knowing what people are performing which activities, how to perform each activity, and what responsibilities, authorizations and tools they need to get their work done. This gives us the concept of a …

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

As we bring people and technology together to drive value for a business, we need to carefully define the training, skills and temperaments that are required to most effectively fill each business role, and identify the people within the organization who are best suited to fill them. 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.

Business Process

Equipped with an understanding of the business metric, business process, and business role, we may clarify explicitly how each role is supposed to achieve each business requirement by defining the detailed steps or process that must be followed.

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

A business process then 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 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 is thus 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 result. 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.

Functional Requirement

Once we clearly define what we mean by the key terms business requirement and business process, it is much easier to identify the enabling skill sets, features and technological capabilities required to effectively execute business processes to meet business requirements. This is typically the focus of BPD in deployments of new technology, and defining functional requirement in context with the above definitions of business requirement, business role, and business process helps maintain focus on value delivery.

Functional Requirement: a capability or characteristic needed by a business role to efficiently execute a business process.

This is where the true business value of employee skill sets and system functional capabilities is understood: these capabilities enable people to complete business processes efficiently and effectively to satisfy their business requirements. For example, an APS system may be required to provide a Late Orders Report to enable a planner to efficiently execute the steps of a Resolve Late Orders business process. To enable a planner to efficiently execute the steps of the Generate Production Schedule business process, the automated solver in a scheduling application must respect material, machine, tool and labor availability constraints. Defining functional requirements in the context of business processes and business requirements, when both of these concepts are clearly tied to business metrics, helps ensure that enabling technologies are configured and implemented to provide maximum value to the business.

Technical Requirement

Once we clearly define what we mean by functional requirement, it natural then to identify the enabling system infrastructures, capabilities and data sources required to enable functional requirements.

Technical Requirement: a system feature or capability needed to enable a Functional Requirement.

This is where report configurations, interface designs, system performance and data sources are clearly understood to be of value to a business, and documented with this value in mind. The language of these definitions places the technical requirements inherent in BPD in their proper context, which tends to drive more efficient technical design. For example, focusing on the purpose of a Late Orders Report, and how it would best enable a master planner to take effective corrective actions in a timely manner as he/she executes the steps of the Resolve Late Orders business process, drives design decisions about report content and layout, data sourcing, system performance and timing to maximize its value to the business.

Conclusion

Effective business process design requires a common understanding of the key terms used throughout the BPD engagement. Lack of clarity in terminology can easily lead to improper focus, inefficient process design and thus waste. Defining terms which focus BPD on value delivery through effective enablement of coordinated business activities is likely to improve business process design, and ultimately drive more business value.