As-is
AS-is means the current situation. Especially, as a counterpart to To-be, this word often indicates the result of analysis to identify problems.
Contents |
Overview
As-is is a word meaning the "current figure/situation" and indicates the status to be improved. The current situation. The counterpart of
- As-is
is
and this indicates the "ideal figure." "Improvement" is a task to dissolve a gap between As-is and To-be. In improvement activities, by clarifying As-is and To-be, we can expose various problems. In improvement activities for business architecture and business processes, the current architecture and processes are considered as "As-is model," and the ideal architecture and processes are regarded as "To-be model." Then, we aim at closing the gap between the two.
Use of As-is in BPM
| PDCA Cycle |
|---|
|
PDCA refers to the methodology and way of thinking with regard to all activities by individuals and organizations in the sequences of:
Which are repeated continuously. Nowadays, PDCA is introduced in a variety of management activities and has become the central point in the business process management. |
In BPM, by introducing PDCA Cycle, we can use As-is model as "the way of current business execution" and To-be model as "the ideal way of business execution" in each step.
- Model the way of current business execution as As-is model. The process model created as As-is is used as a subject of Process Improvement.
- Establish a business process defined as To-be model by modifying a business process defined as As-is model.
- Execute the To-be model at the time.
- Based on the results of monitoring, identity the problems of the To-be model. This To-be model executed is used as As-is model of the next step.
This cycle is iteratively executed.
When creating Business Process Diagrams used as As-is model and To-be model, we need to consider the following issues.
- What tasks are comprised in a process
- How these tasks are connected
- Who is responsible for each task
- What information is input/output in each task
- By whom and at which timing information can be accessed
| What is Fair Process? |
|---|
| Fair Process is a method to ask for opinions and participation of
members, to publish reasons that led to the final decision, and to articulate new goals in manager's decision-making process. |
In terms of execution of Fair Process, it is highly important to describe the way of business execution with "diagrams" so that everyone can understand.
As-is Model in Process Improvement
As-is Model at Flow-model Level
Creating As-is model of workflow-model level help us identify problems. When many changes from As-is to To-be at flow-model level are required, it is difficult for all people in charge of the process, also called Participants, to keep track of the current flow. In such a case, support by Workflow Engine is desired.
Simultaneous Parallel Processing
- As-is
Tasks are executed sequentially. (C1 -> C2 -> C3)
- To-be
After Task "C1" is done, task "C2" and task "C3" are started at the same time to shorten the overall execution time.
Adding Tasks
- As-is
After task "C2" is finished, the process is immediately terminated.
- To-be
By adding a "review task" or "evaluation task" at the end (or in the middle) of the process, we can improve the quality of process outcomes. (Iteration can be additionally used. )
Conditional Split
- As-is
Regardless of the contents of "projects to be executed," which are also called Process Instances, the process route is the same.
- To-be
By changing the process route depending on the contents of "projects to be executed," we can mitigate the business load or reduce retention risk. It is also used to realize the selection of a more suitable process route.
Deleting Tasks
- As-is
For example, there are a number of "approval tasks," "confirmation task," and so on in a process.
- To-be
By eliminating tasks with high retention risk in a process, such as "approval tasks and confirmation tasks that do not examine the contents carefully," we can lower the business load and reduce retention risks.
As-is Model at Data-model Level
Data to be input upon execution of tasks in a process and output data generated as a result of task execution are designed throughout the process. (They are called "Process Data.") Transition from As-is to To-be at data-format (data-model) level might cause some cost to dissolve the gap among formats upon data aggregation.
Adding Data
- As-is
Supposing "Agreement Reporting Process" shown in the right figure, we can consider As-is model of basic data output throughout the process as follows. For example, in "L1: Review" task, all information entered at the upstream task, "S1: Draft" are displayed. Then, based on the input data, which are shown in bold face, "Agreement Draft Acceptance Check," which is the output data, 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 |
- To-be
Let's think about adding a data item, "Agreement Amount," for example. By adding it, we can quickly understand the importance of an agreement document at tasks after "L1: Review." In addition, we can easily aggregate the agreement amount and also can add split of the route based on the agreement amount, which is considered as process improvement at flow-model level.
| 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 |
Change Data Visibility
- To-be
At "A1: Bill" task in "Agreement Reporting Process" shown above, it is not necessary that the personal information about the contact of the purchaser can 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 |
As-is Model at Resource-model Level
Allocation of Multiple Resources
- As-is
One specific participant is in charge of a task or is designated by the supervisor etc. for a task.
- To-be
By allocating a group (multiple people), which works collaboratively, to a task, we can mitigate the retention risk. (Candidacy System)
Automatic Allocation Based on Capability and Experience
- As-is
Tasks are allocated without taking capabilities of participants, such as languages they can translate and qualifications, or experiences, including the years of employment or patterns, into consideration.
- To-be
We can keep track of capabilities, such as language skills and qualifications, and experiences, including years of employment and patterns, and automatically assign resources based on the capabilities and experiences. 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
- As-is
For example, an organization comprises 10 groups of 10 members.
- To-be
For example, by re-organizing the existing groups 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.
