1-1 First, envision the output
When you send data to a printer, you get a printout.
When you give a vending machine money and your wish, you get a product.
What exactly is the output of the business process (workflow) you are in charge of? This can be a difficult question to answer, even with processes we perform daily.
When you make an inquiry at an information desk, you get an answer.
When you inform a salesperson of what you want, you get an estimate.
When you submit a job application to HR, you may go through various exchanges in between, but in the end you get an acceptance/rejection letter.
There may be complicated transactions involved within an organization, and some things may be concluded arbitrarily by one member, but there is always some sort of processing followed by some sort of output. When designing business processes, it is important to first grasp each process objectively and think of what the output should be.
1-2 Define the final output
“The materials are the input, and the balance sheet and Profit & Loss statement are the outputs.”
Although this is a bit extreme, it is, so to say, a correct statement. However, the moment you try to grasp processes too macro-scopically, you begin to lose the efficiency of the discussion. The greatest aim of BPM is consistent improvement, and we want to talk about improvement in units that appropriately divide the company.
This brings us to the question: What is the optimum way to divide a company? Let’s use a website production company as an example. We can think of various deliverables in a website production company, such as estimate sheets, websites, setup manuals, etc. Naturally, it is not conducive to define a business process for every single possible
deliverable. For example, the website and setup manual are both managed by the
production team, and created at the same stage in a one-on-one work environment. These should be thought of as outputs of the single Website Production process. In this case, a data CD could be envisioned as the final output of the Website Production process, and
the website and setup manual can be created at various tasks within the process.
This is why it is important to define the deliverable “the final output” when establishing business processes.
1-3 ALWAYS define the final output
There are many business processes for which the deliverable (final output) is difficult to define. For example, what would be the deliverable of a “Respond to request for deletion of personal information” workflow?
Generally, business processes that entail mere browsing, updating or deletion of stored information rarely create new information, so defining the deliverable is challenging. Of course, we can demand a “performance record” or some such output, but in some cases security measures limit the information that can be included in the record. Also, these processes tend to end before the generation of the deliverable (final output) because the main objective has already been fulfilled.
Still, it is important to define the deliverable and make sure it is generated each time the process is completed. Why?
- To clarify the condition for ending each process.
- To be able to refer to the past records of each process.
It is particularly valuable for an organization to keep records. This way, we can optimize new process operations based on past performance, or use records as reference when discussing the improvement of business processes.
It is preferable to define deliverables for all business processes — including those that prove to be difficult to define — such as records of operation time and content, or comments and evaluations of performance. And there are many ways to consider better efficiency, such as automatic recording and system coordination.
1-4 Anticipate the QCD of each output
In many cases, business processes are evaluated by comparing the QCD (quality, cost, delivery) of deliverables. It goes without saying that the higher the quality of deliverables the better, the lower the cost (labor) of operation the better, and the shorter the time until delivery the better.
However, QCD analysis usually signifies a tradeoff situation, as in, “the quality improves in proportion to the cost invested.” So it is important to keep a comprehensive view on the “ideal QCD.”
Let’s look at some business processes and corresponding deliverables of a website production company.
- Client Meeting Report (Record of proceedings)
- Proposal Preparation (Proposal)
- Estimate Preparation (Estimate sheet)
- Finalization of Order Agreement (Agreement)
- Negotiation of Specifications (Specifications)
- Production, Quality Management, Delivery (Data CD)
Let’s say that 5 and 6 are business processes managed by the production team, which consists of 20 staff members, and 1 through 4 are managed by the sales team, which consists of 5 members. Say, for instance, if the overall business goal is “to achieve 4 regular website production orders each week,” then an average order ratio (from
experience) may imply the necessity of “6 estimate sheets a week,” “10 proposals a week,” and “20 records of proceedings a week,” giving clear goals for each deliverable. Thus, the cost and quality to be allotted to each regular order can be hypothesized.
- Record of proceedings: A quality that ensures 50% lead to proposals, about 5 hours per case
- Estimate sheet: A quality that ensures 50% lead to orders, about 2 hours per case
If we anticipate the QCD of deliverables beforehand, in accordance with the specific business environment of the organization, this will ensure more efficient discussions in the future.