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.