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.