Business Process Harmonization: Science and Art (I).

I have gone through the process of business process harmonization in big companies and I´ve learned some lessons I would like to share. We understand Business Process Harmonization as the “elimination of differences and inconsistencies in their activities, inputs, outputs or owners among processes that share the same goal in order to make them uniform or mutually compatible”(1).

Typically, the companies initiate a Business Process Harmonization (BPH) project as a result of:

•    A Post-Merger and Acquisition process
•    Implementation of a enterprise wide system (like an ERP)
•    Difficulties in the interoperability of Regions
•    A expansion strategy
•    Definition of a common model (or Company-Way)

The benefits of a BPH are:

•    Improvements in efficiency
•    Decreasing operating costs
•    Increasing internal control
•    Reduce IT spends
•    Improve interoperability across regions
•    Speed in the implementation on new operations
•    Achieve synergies

There are essentially two ways to define and implement a BPH:

I have used both path, but I consider Path B as my preferred. Why? Look at the following table:

If you want to seize the opportunity of process harmonization to redefine and implement best-practices, Path B should be the choice.

Sources:
(1)    “A literature review in process harmonization: a conceptual framework” http://cms.ieis.tue.nl/Beta/Files/WorkingPapers/wp_379.pdf

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.

The right sequence: Process, Organization and then, Technology.

It is normal to consider that one way of making changes to a better level of operation in the organization is through the implementation of a new technology (i.e. a new ERP or information system). One of the paradigms behind that is that the "ERP brings the best practice". Although this statement is partially true, this road has driven to more problems than solutions. With the high investment in technology the companies make, it is recommendable to take a second look to the sequence.

The main subject is that we are humans (and should be treated like that...), and there are some steps to be fullfilled to achieve the change required. In this article, we consider the definition on each element as follows (I´m assuming that the Strategy is clear for all cases):

- Process: changes in activities, way of doing the work, techniques, methodologies, KPIs.

- Organization: changes in roles, responsibilities, objectives, targets, job title, job description, organization charts.

- Technology: changes in systems, new technologies, equipments.

Let´s take a look to the combinations and see the possible outcomes (I do not pretend to be exhaustive...). Ideally, you should do all changes at the same time, but depending on the degree of the change, the organization may or may not absorb it completely. Also, the "Solution designer" may have a clear picture about the vision of all elements working together and not to be completely sequential. It means that if you are designing process supported by an ERP, you have to consider the ERP restrictions from the very beginning.