Search This Blog

Showing posts with label process mapping. Show all posts
Showing posts with label process mapping. Show all posts

Tuesday, June 11, 2013

Understand first the "why" of your Process Mapping Effort.



 "I have no special talent. I am only passionately curious"

Albert Eistein.


It can sound obvious, but the purpose of the process mapping effort should be defined clearly from the beggining. If not, all the construct can be useless and the organization may feel dissapointed with the results of the effort. I have seen several mapping efforts that at the end didn´t fit with what the company expected from it.

I suggest to use techniques, like 5 Whys, to understand the roots of the process mapping effort in order to select what is the best approach. "5 Whys" is a simple technique for problem solving, typically used in the phase of "analysis" of the Six Sigma methodology, Kaizen and Lean Manufacturing, but also can be used in isolation. This technique was originally developed by Sakichi Toyoda and was built by Toyota in its "Toyota Production System".

This technique consists in asking questions iteratively in order to find the root cause of a problem. For example, let´s use this technique to understand the root cause analysis of an initiative of business process mapping:



You can use this technique or any other that help you understand the "why" and the expectations for the process mapping initiative. When you agree with your client what is the purpose, select the best approach for process mapping, in order to guarantee that you will have the proper tools to get the expected outcomes. For example, you can select the tool depending on the business situations as illustrated in the following table:



As you can see, you should select the right approach from the beggining. If there are several issues you want to solve, use a more general approach (like swim lanes or BPMN). For solving specific business situations, you may need to select a specialized technique (like VSM for improving processes).

Wednesday, May 15, 2013

5 steps to consider before starting your Process Mapping effort.


A process mapping effort, especially if it will be enterprise-wide, implies an important investment of resources and time. Hence, it is important to consider at least five important things before starting to map:
 
1.     Define the Strategy: be clear what the business objective(s) of the process mapping effort is. This objective (or objectives) must be shared with the project team. Depending on the strategy, the type of mapping shall be defined. For example, you may want to do a mapping effort for:


·        Compliance: to have the process maps to fulfill requirements of auditing, ISO-9000 initiatives, normative, company documentation, enterprise architecture, etc.
·        System implementation: the process maps will be the business blueprint for an ERP or another type of information system.
·        Process improvement: the maps will be used to detect areas of opportunities to be more efficient or productive.
·        Reengineering: the process maps will be used as the tool to reengineer the operation.
·        Process orchestration: the main purpose is to serve as the basis for the process orchestration using a methodology like BPM/SOA.
·        Training: main objective is to train employees in the way the company do the work.
·        Process harmonization/homologation: the company requires having standard process across geographies, business units, etc. Typically, we need this approach in a post-merger integration or in the preparation of the company to a global strategy.
·        Cost reduction: when you want to understand where the cost opportunities are in the different process of the company.

It is clear that depending on the purpose, the information reflected in the process map (so, in the same way, the methodology used for mapping) will be different. The other aspect that must be well defined is the time horizon of your mapping:

·        Is it an “As-is” process mapping?
·        Is it a “To-be” process mapping? If so, what is the time horizon (i.e. next year, aligned to a milestone, etc?)

This time horizon must be applied to the whole process mapping. If not, you are going to have a mixture of future with present processes.

If the strategy is not clear, you will have an organization “frustrated” because it didn´t get the expected benefits of the mapping effort.

2.     Create a process inventory: have a preliminary list of all the process that will be part of the mapping effort. This inventory will change, but you should have a starting point. This inventory and the complexity of each process will help you to dimension the size of the teams. The approach should be “top-down” with adjustments coming “bottom-up”. This is one of the reasons that you may start with a business process framework for the company and then go down to the list of the further levels.

3.     Establish the plan: have a detailed plan of the process mapping effort, indicating clearly time and resources required in each activity. You should use the estimation based on the process inventory to identify quantity and skills of resources needed.

4.     Select and prepare a process repository: based on the strategy, you should define the type of repository and tools needed. If for example, you want to do simulations, you have to be sure that the tool will support this functionality. The same applies to other functionalities like process orchestration.

5.     Establish the process mapping conventions: define clear rules for the process mapping. You should not start any process mapping effort without the rules of mapping. You can use a standard as a basis (i.e. BPMN), but always aligned to the strategy you already defined. The conventions must help you to achieve the project objective. The rules must be easy to understand and to apply, and be as exhaustive as required. You have to define, in this convention:

·        The standard that will be the base of the convention
·        The naming conventions
·        The symbols conventions
·        The style conventions
·        Diagrams of what is allowed and what is not, and examples of good mapping
·        Attributes to be filled in the diagrams
·        Change control procedures and documentation
·        Users and security standards

If you fill these steps, you will have a better chance to start with the right approach the mapping effort.