Process Improvement

From Q-BPM

Process Improvement

Process Improvement is mainly to change current "business process" into "what it should be."

1 Overview of Process Improvement
2 Motivation of Process Improvement
3 Procedures of Process Improvement
- 3.1 Participant in Charge of Process Improvement Execution
- 3.2 Framework for Process Improvement
4 Examples of Improvements at Flow-Model Level
5 Examples of improvements at Data-Model Level
- 5.1 Adding Data
- 5.2 Modification of Data Visibility
6 Examples of Improvements at Resource-Model Level
7 Examples of Improvements at Company-Wide Level
- 7.1 Connecting Processes
- 7.2 Standardizing and Unstandardizing Process
8 Examples of Failures in Process Improvement
9 Related Articles
10 References

Overview of Process Improvement

We can consider that corporate activities are "consist of multiple business processes." Process improvement (business process improvement) is an activity to modify business process so that the process approaches "what it should be" for the company. It is also called BPI (Business Process Improvement).

However, it is difficult to reasonably describe "definition of an ideal model," which makes organizational decision making difficult. In addition, it is also hard to determine "exactly when we should define the ideal model" because it is, in nature, varies over time depending on internal and external factors. Moreover, managing and keeping track of modification of "business process" are not easy tasks. In other words, business process, which defines how to execute the business, includes a variety of know-how as well as rules and conventions, so it is not easy to describe the whole picture of the business process. Thus, it is often managed and grasped by means of a couple of diagrams and tables that simplify and formalize the business process. The entire definition that is simplified by using diagrams and tables is called process model, and a diagram to define "business flow" is called business flow diagram.

"Process Improvement" includes not only improvement of existing business processes but also creation, abolishment, integration, and disaggregation of business process.

Motivation of Process Improvement

There are potentially a variety of motivations to execute process improvement, but in most cases, they are categorized into two groups, each of which consists of two types.

Verification of hypotheses derived reasonably (deductively)
1. Top-down order
2. Bottom-up improvement
Solution of problems found empirically (inductively)
1. Top-down order
2. Bottom-up improvement

"Verification of hypotheses" is a motivation to experiment with policies assumed through analysis and simulation of process model and, in some cases, imagination. On the other hand, "solution of problems" is a motivation to work on process improvement based on actual situations caused by misconduct, spoofing, accidents, and decrease in an amount of production or situations in which those problems are happening.

In addition, "top-down order" is a motivation based on orders from managers, and "bottom-up improvement" is a voluntary activity by employees.

Procedures of Process Improvement

In general, process improvement can be done by defining the current figure and targeting future figure of the process (or a process group) to be improved and then enumerating and executing tasks and procedures to reduce the gap between the two figures.

A model that simplifies and formalizes the current business process (This model is called "current model" or "As-is Model.")
A model that simplifies and formalizes the targeting future business process or the ideal business process (This model is called "ideal model" or "To-be Model.")

BPM Cycle

In many cases, tasks are enumerated based on the differences in "business flow diagrams" (flow models) that describe the business processes, but we should often additionally take differences in "task division tables (responsibility tables)" (organizational models) or "business data formats" (data models) into consideration. Practically, many of enumerated tasks are activities to reach a consensus.

In addition, such "circulative and continuous execution" (PDCA Cycle) of process improvement is sometimes called "BPM Cycle".

Participant in Charge of Process Improvement Execution

In many cases, a participant in charge of process improvement execution is a manager or a chief of each department. However, especially in case of bottom-up improvement, sometimes a participant in charge is assigned to each process. A participant in charge of process improvement is sometimes called "process owner."

"Whether a change in process can be considered as improvement or not" varies depending on organizations and statuses of organizations. In other words, "improvement" for one company is often "debasement" for others. There are various patterns of methodologies, and many of them require supports of information systems (BPMS, ERP, etc.). A process owner is required to have a good ability for decision making from a broad perspective.

Framework for Process Improvement

In business of production by commissioning and business emphasizing quality of products, a maintenance status of production process critically impacts the result of the business.

For instance, in a software industry, continuous effort to quantitatively evaluate abilities of improvement of software (information systems) development process is being made. From commissioning parties' perspective, results of such evaluation is usually helpful when they determine which company to be commissioned. (It is called "CMMI (Capability Maturity Model Integration).")

CMMI
ITIL
Automotive SPICE
ISO/IEC 15504

Examples of Improvements at Flow-Model Level

In case a lot of changes in flow-model level are expected, it is difficult that all people concerning a process, also called participants, keep track of the actual status of the flow. In such a case, a support by "a workflow engine" is desired.

Task-level improvements (or know-how about business), such as "always assigning an auditor when an important task is executed," are out of scope here.

Simultaneous Parallel Processing

When tasks are executed sequentially, say "C1 -> C2 -> C3," we can shorten total time needed to complete the tasks by starting task "C2" and task "C3" in parallel at the same time after task "C1" is completed.

Simultaneous Parallel Processing

Adding Tasks

We can improve the quality of process artifacts by adding a "review task" or "evaluation task" at the end (or in the middle of) the process. (Iteration can be additionally used.)

Judgement or Scoring (L1 Task)

Conditional Branching

We can reduce the business load and retention risk etc. by changing process route based on the contents or statuses of "process instances." Conditional branching is also used to choose more suitable process routes.

Conditional Branching

Deleting Tasks

We can reduce the business load and retention risk by deleting tasks with high retention risk in the process, such as "sealing task and confirmation task without carefully reviewing the contents."

Examples of improvements at Data-Model Level

Agreement Reporting Process

Input data for each task in a process and output data as artifacts of execution of each task are designed through the entire process. (They are called process data.) Data-format (data-model) level process improvements might cause some cost to deal with the differences among formats upon data aggregation.

Adding Data

Assuming "agreement reporting process" shown in the right diagram, basic data that are output through the entire process are assumed as follows. For example, in "L1:Draft Confirmation" task, all information that is entered in the upstrem task "S1: Draft Creation" is displayed, and based on the input data (shown in bold-face), "Agreement Draft Acceptance Check," which is output information, is entered.

Data Name	Data Type	Condition	S1	L1	S2	L2	A1
Company Name of Purchaser	Text	Required	Enter	Display	Display	Display	Display
Name of Contact of Purchaser	Text	Optional	Enter	Display	Display	Display	Display
Contact Information of Purchaser	Phone Number	Optional	Enter	Display	Display	Display	Display
Contact Information of Purchaser	Address	Optional	Enter	Display	Display	Display	Display
Agreement Document	File	Required	Enter	Display	Display	Display	Display
Agreement Draft Acceptance	Check	Required	-	Enter	Display	Display	Display
Report of Agreement Completion	Text	Optional	-	-	Enter	Display	Display

As an example of data addition, if we add "agreement amount," the degree of importance of an agreement document can be grasped quickly at "L1:Draft Confirmation" and tasks after it. Furthermore, in this case, we can easily aggregate agreement amounts or add conditional branching based on the agreement amount, which is a part of flow-level process improvement.

Data Name	Data Type	Condition	S1	L1	S2	L2	A1
Company Name of Purchaser	Text	Required	Enter	Display	Display	Display	Display
Name of Contact of Purchaser	Text	Optional	Enter	Display	Display	Display	Display
Contact Information of Purchaser	Phone Number	Optional	Enter	Display	Display	Display	Display
Contact Information of Purchaser	Address	Optional	Enter	Display	Display	Display	Display
Agreement Document	File	Required	Enter	Display	Display	Display	Display
Agreement Amount	Number	Required	Enter	Display	Display	Display	Display
Agreement Draft Acceptance	Check	Required	-	Enter	Display	Display	Display
Report of Agreement Completion	Text	Optional	-	-	Enter	Display	Display

Modification of Data Visibility

In task "A1:Bill Issueance" in "agreement reporting process" described above, personal information of the contact of the purchaser does not have to be browsed. Although it is not shown in this example, some personal information that should be shared only in the sales department might be included here. By reducing the data visibility, we can mitigate the risk of information leakage.

Data Name	Data Type	Condition	S1	L1	S2	L2	A1
Company Name of Purchaser	Text	Required	Enter	Displayed	Displayed	Displayed	Displayed
Name of Contact of Purchaser	Text	Optional	Enter	Displayed	Displayed	Displayed	Not Displayed
Contact Information of Purchaser	Phone Number	Optional	Enter	Displayed	Displayed	Displayed	Not Displayed
Contact Information of Purchaser	Address	Optional	Enter	Displayed	Displayed	Displayed	Displayed
Agreement Document	File	Required	Enter	Displayed	Displayed	Displayed	Displayed
Agreement Amount	Number	Required	Enter	Displayed	Displayed	Displayed	Displayed
Agreement Draft Acceptance	Check	Required	-	Enter	Displayed	Displayed	Displayed
Report of Agreement Completion	Text	Optional	-	-	Enter	Displayed	Displayed

Examples of Improvements at Resource-Model Level

Allocation of Multiple Resources

By allocating a group (multiple people), which works collaboratively, to a task that one specific person is in charge of or is allocated to, we can mitigate the retention risk. (Candidacy System)

Automatic Allocation Based on Capability and Experience

Resources can be automatically allocated based on their capabilities and experiences. In this case, capabilities, such as language skills and qualifications, and experiences, including years of employment and patterns, need to be managed. For example, in "Answering to Inquiry" task, a participant who has been working for the company for more than 10 years can be allocated to the inquiries regarding products sold 10 years ago. Thereby, we can reduce the retention risk.

Increasing/Decreasing the Number of Organizations

For example, by re-organizing 10 groups of 10 members into 5 groups of 20 members, we can increase the number of resources allocated to each task by decreasing the number of groups, and thereby we can prevent the retention of the process.

Examples of Improvements at Company-Wide Level

Connecting Processes

For example, by connecting "Commissioned Service Sale Process" and "Commissioned Development Production Process," we can achieve continuous and uninterrupted business process and sharing of company data. In some cases, we could also realize development of human resources that have broad perspectives through understanding businesses in other departments.

Standardizing and Unstandardizing Process

For instance, by standardizing "Daily Report Process" and "Risk Management Process" across the company, we can achieve company-wide sharing of know-how and comparison among departments. This is called "process standardization." On the other hand, in case "Daily Report Process" and "Risk Management Process" lost flexibility and no one can propose modification of them, improvements could be done in some department by allowing each department freely change the flow models.

While "standardization of process" could cause rigidification of process, it is effective because it is based on the global optimization concept. From macro, long-term, evolutionary perspective, both of a period in which we eliminate unique processes of each department under "standardization of process," which is based on a global optimization concept, and a period in which we explore various possibilities under "autonomy" based on the local optimization concept are necessary.

Examples of Failures in Process Improvement

A company has no time to create "process models."
A company has no time to update "process models" when the ways of business execution are changed.
- Characteristics are not reflected. Especially, a modified way of business execution introduced upon replacement of the manager does not take effect.
- Whenever newcomers join, the way of execution changes (based on capabilities of members). But "process models" are not updated accordingly. (See "SL Theory".)
Although a "process model" is changed, "a way of business execution" is not changed.
- Consensus for improvement can not be built. (See "Fair Process.")
Rollback of "process models" and "the ways of business execution" can not be done even when it is desired.