In the Third Stage Consulting Blog, @EricKimberling wrote a post provocatively titled 'Organizational Change Management is dead'.
In my opinion it summarized two key points. One, a structured approach
to OCM involving a wider set of stakeholders is the need of the hour.
Two, you are the owner of OCM, not the external vendors.
In my comment to the post, I made a bold claim that 'bad ERP Implementation is the cause, not the effect of OCM Issues'.
Soon, I got a notification that Mr.Kimberling liked my comment. Since he liked it, he should agree with it, no? Since the author of the original article agrees with it, the other readers should also like it, right?
I was waiting for the 'likes' to pour in for my comment. I was prepping myself to bask in glory.
But not all readers of my comment were ready to take me at face value, One reader Mr. @EduardoMuniz, wanted me to justify my position. On what basis was I making that 'bold claim'.
This post explains the reasons of why I made that claim. These are some of the random set of thoughts. I will add on to them and refine them as I go on. I am making about 7-8 points in this article. I have written posts in My Blog or LinkedIn articles to support some of these points. I am giving links to the posts here. So to get a complete understanding of why I made that claim, you will need to go through those 'badly edited' posts of mine.
(How am I qualified to write this article, you may ask. I have been implementing ERP for over 18 years with about 90% Average Customer Satisfaction rating and a slew of satisfied customers. If you want I can give you references)
If you read the article by Mr.Kimberling, he concurs with what I am saying, when he says that The problem isn’t with the need for organizational change management, but with the way that their large Oracle system integrator and others had tried to introduce change management into their organization.
So here goes,, a set of reasons for my bold claim that a bad ERP Implementation is the cause and not the effects of OCM Issues
One, Lack of an integrated approach to ERP Implementation: In my prescient blog post titled 'Letter to the CFO' that I had written in 2007 I had identified 15 points that an Organization planning an ERP Implementation should consider. One of the points was to have a clear and measurable objective (present) and another was to ensure Scalability of Organizational growth and ERP's ability to handle the future transactions and the load(future). Without this integrated approach of linking present and future requirements, ERP cannot be implemented successfully and there will be continued internal resistance in the Organization.
Two, Objectives are not percolated down to the consultant level: Even when you have a clear Objective, it does not percolate to the consultant level. While the senior stakeholders know it, the consultant do not know that the company wants to 'reduce period closing from 7 days currently to 3 days after implementation'. To achieve this objective, Consultants will need to design processes and reports. For example to achieve 3 day period closing objective, a 'shadow closing' in clone instance have to be done in the last week of the month to identify potential period closing challenges. Also, a few exceptions reports will have to be designed to ensure that relevant stakeholders identify the potential period closing issue. If the consultant is not aware of the objective, how will he put in place these processes or design these reports?
The ultimate effect is dissatisfaction with ERP, beginning of a perception that 'ERP do not meet our requirements' and resistance to using ERP.
Three, Objectives are not clear: One of the objectives could be 'To reduce waste'. Another will be 'Move to a paperless organization'. These are hazy terminologies but with clear detailing can be achieved in ERP. The problem is that while ERP is not designed to meet these 'objectives', the Users in the Organization are given targets to achieve these goals and their performance is measured based on them. 'What is the trend of stationery costs in your department over the last three quarters after we implemented ERP?', the management asks. The department manager do not have the knowledge to ask pertinent counter questions like, how many workflow customizations were designed to ensure adequate flow of notifications at each stage of the process?', 'how do I comply with statutory filings if you keep insisting on going 'paperless'? 'How was the ERP designed for 'paperless'? Ultimate result, resentment against ERP and resistance in the Organization which could have been easily avoided by some proper planning and ERP execution
Four, Consultant Quality - Communication Skills: Let us understand one thing. Most of the OCM issues after ERP Implementation are from ground up, from frustrated users. For these users, the ERP consultant is the expert, the doctor who is supposed to cure their ailments, as it were. But what does the doctor do? He follows a mechanical process. He doesn't answer some of their pertinent questions, probably because he do not know the answer. He do not ask pertinent questions which will assure the users that he has understood their requirements and concerns. He talks to the users only during formal meetings, do not try to build rapport or elevate the knowledge level of users. Result? The end users are confused and worried. Classic recipe for OCM challenge. I have seen consultants and customer users sitting in different rooms and do not cross the 'Line of Separation' between the two rooms.
How can consultant instill confidence in product if he is not able to build rapport with the end users?
Another challenge is that Customer is kept out of the entire ERP Solution design phase and is able to see the proposed solution and comment on it only during the conference room pilots. As I mentioned in this LinkedIn article, the earlier you transfer ownership of the ERP solution to the customer, better will be the quality of solution, stronger will be the ownership and higher will be the Custsat. And even when the solution is discussed, the consultant will continue talking about 'Let us create a purchase order for TEST_ITEM1 on a DUMMY_VENDOR, 1000 quantities at a price of 1 USD per TEST_ITEM1'. Ideally they should talk about 'Procuring 100 Widgets from your regular Widget Supplier John Pemberton Inc. for 1.25 Dollars per Widget'. This will help the customer visualize the transaction and identify the potential challenges.
There are some tips that consultants can use during any Solution Demonstration. One is to tell it as a story. This approach will improve customer's trust on the knowledge of the consultant and the solution. This helps in getting quick buy in to the solution
A recipe for a satisfied customer ready to embrace change.
Five, Consultant Quality - ERP Paradox: Over my years of ERP Implementation I have noticed this paradox. Organization works in silos. They decide to implement ERP to integrate the business process from Purchase Requisition to Financial Report. They call an SI to implement ERP. What do the SI bring? Procurement consultant, manufacturing consultant, financial consultant, order fulfillment consultant... Do you see what is happening here? Consultants with knowledge silos are implementing an application meant to integrate business processes. How will they succeed? How will the customer be satisfied? Is it not a recipe for OCM Issues and lack of acceptance of the solution?
Six, Consultant Quality - Lack of Business Process Knowledge: Consultants do not understand the 7 Flows of ERP Implementation. Due to this, application configuration, which is the most important aspect of ERP Implementation become sub-optimal. In one of the implementation, the consultant had configured each 'depot' as a 'Company Segment' in ERP. The company segment is the most critical configuration in ERP and that has to be cast in stone. Due to this bad configuration, every time the organization opened a depot, they had to add a value to this segment and the number of 'Intercompany' transactions and associated reconciliation issues, exploded.
Another example is the choice of costing method. Many consultants do not have knowledge of the implications or complexity of choosing a costing method. In one implementation, 'Standard Costing' was chosen without any thought and preparation and the associated Variance accounts impacted the P&L negatively. Another example is of configuring 'Average Costing' for a commodity industry with seasonal purchases and tracking batch-wise profitability. I have personal experience with these challenges.
In my opinion, bad configurations that slow down the processes and creates complexities are one of the key causes of resistance to adoption of ERP in the company
Seven, poor requirement gathering: As my LinkedIn post on 'Peeling Onion Approach to requirement gathering' show, most of the ERP Implementations stop at Layer 2, while OCM Issues start with Layer 3 and above. Checkout that article
Eight, Poor data planning: Every expert and their mothers in law will tell you that data and configuration are the two main aspects of an ERP Implementation. And data conversion, arguably the most important activity in ERP Implementation is handled very casually. As my post on Data Migration Strategy show, without a structured approach, the implementation will fail to stabilize or never stabilize as in case of PMAC costing method (Period Moving Average Costing) in OPM (Oracle Process Manufacturing) where the current period cost is linked to the costs in all the previous periods including the opening balance. I had reviewed an implementation which took almost 16 months after go live to close the first year!This happened only because the discipline required to take in the Opening Balance was not followed by the implementation team. You can imagine the pressure, despair and frustration that the users had to face as they had to explain week after week to the top management as to why after ERP we are not able to close the financial year!
Even though I can go on and on on this issue since I am passionate about it, let me conclude my article here. In conclusion, I want to make three points. One, OCM issues build up from ground up. The resistance normally start from the users and the department heads before escalating. Two, ERP Implementation starts first. At that time the Organization and the users are in a wait and watch mode. As ERP Implementation progresses, depending on the customer's perception about the ability of ERP solution to address their concerns, the OCM Issues will commence. This is why I claim that bad ERP implementation is the cause for OCM Issues Three, ERP's impact on OCM is minimal on a large process oriented company that can absorb the shocks than on an SME that has invested a significant portion of management time and effort in the success of the ERP. A bad implementation can slow down the entire Organization in such cases and there will be a lot of resistance at the operational levels of the company.
With a patient and competent consultant handling the ERP Implementation, you will have a delighted customer who will embrace change.
In my comment to the post, I made a bold claim that 'bad ERP Implementation is the cause, not the effect of OCM Issues'.
Soon, I got a notification that Mr.Kimberling liked my comment. Since he liked it, he should agree with it, no? Since the author of the original article agrees with it, the other readers should also like it, right?
I was waiting for the 'likes' to pour in for my comment. I was prepping myself to bask in glory.
But not all readers of my comment were ready to take me at face value, One reader Mr. @EduardoMuniz, wanted me to justify my position. On what basis was I making that 'bold claim'.
This post explains the reasons of why I made that claim. These are some of the random set of thoughts. I will add on to them and refine them as I go on. I am making about 7-8 points in this article. I have written posts in My Blog or LinkedIn articles to support some of these points. I am giving links to the posts here. So to get a complete understanding of why I made that claim, you will need to go through those 'badly edited' posts of mine.
(How am I qualified to write this article, you may ask. I have been implementing ERP for over 18 years with about 90% Average Customer Satisfaction rating and a slew of satisfied customers. If you want I can give you references)
If you read the article by Mr.Kimberling, he concurs with what I am saying, when he says that The problem isn’t with the need for organizational change management, but with the way that their large Oracle system integrator and others had tried to introduce change management into their organization.
So here goes,, a set of reasons for my bold claim that a bad ERP Implementation is the cause and not the effects of OCM Issues
One, Lack of an integrated approach to ERP Implementation: In my prescient blog post titled 'Letter to the CFO' that I had written in 2007 I had identified 15 points that an Organization planning an ERP Implementation should consider. One of the points was to have a clear and measurable objective (present) and another was to ensure Scalability of Organizational growth and ERP's ability to handle the future transactions and the load(future). Without this integrated approach of linking present and future requirements, ERP cannot be implemented successfully and there will be continued internal resistance in the Organization.
Two, Objectives are not percolated down to the consultant level: Even when you have a clear Objective, it does not percolate to the consultant level. While the senior stakeholders know it, the consultant do not know that the company wants to 'reduce period closing from 7 days currently to 3 days after implementation'. To achieve this objective, Consultants will need to design processes and reports. For example to achieve 3 day period closing objective, a 'shadow closing' in clone instance have to be done in the last week of the month to identify potential period closing challenges. Also, a few exceptions reports will have to be designed to ensure that relevant stakeholders identify the potential period closing issue. If the consultant is not aware of the objective, how will he put in place these processes or design these reports?
The ultimate effect is dissatisfaction with ERP, beginning of a perception that 'ERP do not meet our requirements' and resistance to using ERP.
Three, Objectives are not clear: One of the objectives could be 'To reduce waste'. Another will be 'Move to a paperless organization'. These are hazy terminologies but with clear detailing can be achieved in ERP. The problem is that while ERP is not designed to meet these 'objectives', the Users in the Organization are given targets to achieve these goals and their performance is measured based on them. 'What is the trend of stationery costs in your department over the last three quarters after we implemented ERP?', the management asks. The department manager do not have the knowledge to ask pertinent counter questions like, how many workflow customizations were designed to ensure adequate flow of notifications at each stage of the process?', 'how do I comply with statutory filings if you keep insisting on going 'paperless'? 'How was the ERP designed for 'paperless'? Ultimate result, resentment against ERP and resistance in the Organization which could have been easily avoided by some proper planning and ERP execution
Four, Consultant Quality - Communication Skills: Let us understand one thing. Most of the OCM issues after ERP Implementation are from ground up, from frustrated users. For these users, the ERP consultant is the expert, the doctor who is supposed to cure their ailments, as it were. But what does the doctor do? He follows a mechanical process. He doesn't answer some of their pertinent questions, probably because he do not know the answer. He do not ask pertinent questions which will assure the users that he has understood their requirements and concerns. He talks to the users only during formal meetings, do not try to build rapport or elevate the knowledge level of users. Result? The end users are confused and worried. Classic recipe for OCM challenge. I have seen consultants and customer users sitting in different rooms and do not cross the 'Line of Separation' between the two rooms.
How can consultant instill confidence in product if he is not able to build rapport with the end users?
Another challenge is that Customer is kept out of the entire ERP Solution design phase and is able to see the proposed solution and comment on it only during the conference room pilots. As I mentioned in this LinkedIn article, the earlier you transfer ownership of the ERP solution to the customer, better will be the quality of solution, stronger will be the ownership and higher will be the Custsat. And even when the solution is discussed, the consultant will continue talking about 'Let us create a purchase order for TEST_ITEM1 on a DUMMY_VENDOR, 1000 quantities at a price of 1 USD per TEST_ITEM1'. Ideally they should talk about 'Procuring 100 Widgets from your regular Widget Supplier John Pemberton Inc. for 1.25 Dollars per Widget'. This will help the customer visualize the transaction and identify the potential challenges.
There are some tips that consultants can use during any Solution Demonstration. One is to tell it as a story. This approach will improve customer's trust on the knowledge of the consultant and the solution. This helps in getting quick buy in to the solution
A recipe for a satisfied customer ready to embrace change.
Five, Consultant Quality - ERP Paradox: Over my years of ERP Implementation I have noticed this paradox. Organization works in silos. They decide to implement ERP to integrate the business process from Purchase Requisition to Financial Report. They call an SI to implement ERP. What do the SI bring? Procurement consultant, manufacturing consultant, financial consultant, order fulfillment consultant... Do you see what is happening here? Consultants with knowledge silos are implementing an application meant to integrate business processes. How will they succeed? How will the customer be satisfied? Is it not a recipe for OCM Issues and lack of acceptance of the solution?
Six, Consultant Quality - Lack of Business Process Knowledge: Consultants do not understand the 7 Flows of ERP Implementation. Due to this, application configuration, which is the most important aspect of ERP Implementation become sub-optimal. In one of the implementation, the consultant had configured each 'depot' as a 'Company Segment' in ERP. The company segment is the most critical configuration in ERP and that has to be cast in stone. Due to this bad configuration, every time the organization opened a depot, they had to add a value to this segment and the number of 'Intercompany' transactions and associated reconciliation issues, exploded.
Another example is the choice of costing method. Many consultants do not have knowledge of the implications or complexity of choosing a costing method. In one implementation, 'Standard Costing' was chosen without any thought and preparation and the associated Variance accounts impacted the P&L negatively. Another example is of configuring 'Average Costing' for a commodity industry with seasonal purchases and tracking batch-wise profitability. I have personal experience with these challenges.
In my opinion, bad configurations that slow down the processes and creates complexities are one of the key causes of resistance to adoption of ERP in the company
Seven, poor requirement gathering: As my LinkedIn post on 'Peeling Onion Approach to requirement gathering' show, most of the ERP Implementations stop at Layer 2, while OCM Issues start with Layer 3 and above. Checkout that article
Eight, Poor data planning: Every expert and their mothers in law will tell you that data and configuration are the two main aspects of an ERP Implementation. And data conversion, arguably the most important activity in ERP Implementation is handled very casually. As my post on Data Migration Strategy show, without a structured approach, the implementation will fail to stabilize or never stabilize as in case of PMAC costing method (Period Moving Average Costing) in OPM (Oracle Process Manufacturing) where the current period cost is linked to the costs in all the previous periods including the opening balance. I had reviewed an implementation which took almost 16 months after go live to close the first year!This happened only because the discipline required to take in the Opening Balance was not followed by the implementation team. You can imagine the pressure, despair and frustration that the users had to face as they had to explain week after week to the top management as to why after ERP we are not able to close the financial year!
Even though I can go on and on on this issue since I am passionate about it, let me conclude my article here. In conclusion, I want to make three points. One, OCM issues build up from ground up. The resistance normally start from the users and the department heads before escalating. Two, ERP Implementation starts first. At that time the Organization and the users are in a wait and watch mode. As ERP Implementation progresses, depending on the customer's perception about the ability of ERP solution to address their concerns, the OCM Issues will commence. This is why I claim that bad ERP implementation is the cause for OCM Issues Three, ERP's impact on OCM is minimal on a large process oriented company that can absorb the shocks than on an SME that has invested a significant portion of management time and effort in the success of the ERP. A bad implementation can slow down the entire Organization in such cases and there will be a lot of resistance at the operational levels of the company.
With a patient and competent consultant handling the ERP Implementation, you will have a delighted customer who will embrace change.
No comments:
Post a Comment