A change is always difficult because it involves risk, costs, and requires giving up familiar and comfortable ways. But change is the only way to evolve. It is hence a necessary evil. In today’s world, the IT systems landscape for an organization can be moderately complex to very complex including legacy systems (mainframes), ERP systems, product information hubs, catalog management systems, warehouse management systems, sales planning, finance, etc. Also, depending on the organization, you have 1 to many business units that can initiate a process change. Sometimes the implementation of these changes needs a concerted effort across business units.
Below is a sample process flow that depicts how a business process change could get communicated with end downstream customers, and how the impact analysis can be achieved in collaboration with them to provide a recommendation back to the initiators of the change. In the text below I am going to explain some characteristics of each of the steps involved.
What are some characteristics of a Business Process change?
A process change could arise because a business unit could be recommending a new way to classify their products by adding/modifying some attributes; another business unit may want to streamline their purchase order process, etc. The initiating business unit/organization clarifies the business driver for the change, the benefits (in terms of ROI) to the company from the change, and gives a high-level time line for when they would like to see the change implemented across the company’s value chain.
A business process change could be a brand new business process being put in place or a combination of a new process and some changes to an existing process. In most cases (in all established organizations), it is the latter.
How do you communicate and collaborate with the downstream customers?
What does a business process change involve? It can involve some or all of the following:
- Process changes
- Data structure changes (entities, relationships, and attributes including key identifiers).
- Meta data changes (definitions of business elements across the enterprise, business rules, etc.)
- Data changes from end user stand point
- System changes/enhancements in the change initiating systems, and downstream end customers.
Business Process Expert is the role that is called into action to collaborate with the downstream customers, communicate the proposed business process changes, and provide a recommendation back to the business unit initiating the change. The business process expert fits this role for 4 key reasons:(1) extensive business knowledge combined with IT systems knowledge, (2) ability to map and model the business changes to systems, (3) excellent communication skills to facilitate, negotiate, and collaborate, and (4) helicopterability that lets the BPX delve into details of a given process or systems landscape, perform the mapping, and soar up back high to summary level.
How do you approach the impact analysis of business process changes?
The approach you take is a function of the nature of the change being proposed. In general, the impact analysis may be conducted in 2 phases:
- A high level impact analysis to get a ball-park estimate of feasibility, extent of disruption this change may cause to mission critical systems, the breadth of system changes required (high level #s of applications and interfaces this change would impact), and the depth of training required. This would give cost and risk estimates that can be compared with (original) expected numbers from BU. Based on the facts and numbers from high-level analysis, a decision can be made on whether to continue with detailed analysis or stop.
- A detailed impact analysis may then be conducted to identify the scope of changes required by application, and interface, projected time lines, detailed cost estimates, resource estimates, approach, etc.
Depending on the nature of the business process change, the impact analysis could follow one or more of the following methods:
- DATA focused approach
- Data Modeling focused approach
- Enterprise Architecture focused approach.
A business unit could aim at adding and changing a number of business elements that define multiple views of their item classification. An enterprise architecture focused approach may be well suited for such a scenario enabling a look across various business units, standardizing the business element definitions, removing redundancy, minimizing duplication, and providing consistent item classification across the organization.
A data modeling approach may be more suitable if the business process change involves redefinition of key fields, and comparison/ mapping of old view data structures to new view data structures. An example may be redefining the hierarchy of location subject area in the enterprise.
A data focused approach is used along with the above approaches in most cases simply because showing the actual data is the easiest way to communicate the change to a business audience. A data focused approach alone would be appropriate if the proposed business process change involves redefinition of values of a given business element, and remapping.
How do you recommend back and close the process flow?
Depending on whether the impact analysis proceeded to the detailed analysis phase or concluded after the high-level analysis, the BPX, in collaboration with end downstream partners, prepares a report that describes the reasons and method for the implementation of a given business process change.
For instance, if the business process change were too disruptive, and hence not acceptable, the recommendation to change initiating business unit would include sections on:
- Process Change description
- Downstream system Name
- System modification details
- System modification risks
- System modification costs
- Recommendation Contingency Plan for BU
The BPX may, in certain cases, want to identify the contingency plan in collaboration with the change initiating BU before taking the changes to downstream customers. Currently, organizations follow a very rigorous process in the analysis of change proposals, and one of the first questions the steering committee of downstream customers may ask is What happens if the change is not acceptable? What is the plan B for the business unit?
When the proposed changes are acceptable to downstream customers, additional sections such as projected timelines for implementing the change, options/alternative solutions for each of the change items, etc. need to be added in addition to the aforementioned ones.
The entire role of BPX is evolving rapidly. This blog represents the fundamental elements for Change Management and Process Flow, and the involvement of BPX in facilitating the flow. In practice, business process changes that are incremental and do not endanger the status quo (status of people, expertise, the investment, etc.) are accepted relatively easily. Changes that are disruptive, replace old technology, and render old expertise obsolete, encounter greater resistance. Acceptabilityof changes also depends on the pain to learn the new process/technology relative to the pain that we have with the old process/technology.