So, let us next talk about three main pitfalls in change management, what are the major pitfalls that company's experience is underestimating the magnitude of change that ERP brings to the company. In this level, we see four different magnitudes of change, in the first level, the companies simply sees the implementation of the ERP system as a simple tests. What happens over here very often is that a company would assign a person responsible for buying the software packet, and that person usually, is the ERP manager, or the CEO, after that is done he goes on to install it. In a second order of change, this is slightly better the company sees that as mod as needed over here, in fact they will see that there is a need for people the employees to be trained. So they will also send a project manager to manage this, and get him or her to train the workers. However, the fact that if you're seeing this two levels of change as simply a change needed as an IT project, then when things do not go the way they are supposed to go, fingers will be pointing back to the IT department. The right way to sort of assess a change over here is to see that this change is actually much larger. It falls usually in the third or fourth level of change needed, in the third level of change, and the company will recognize that as a need to change the existing structure of the company, so as to fit the new way of doing business using ERP system. By structure, I refer to the different reporting structure that accompany uses, and also the incentive and punishment system that accompany use, will be leaded to ERP system. At the same time, culture is also another element that falls in the third order of magnitude of change, in which the company has to see, and recognize that the ERP implementation is not simply an IT project, but it is a strategic movement that could enable the company to get competitive advantage. If they're able to switch their mindsets to that, then the entire company would be able to move forward together to successfully, with the introduction of a new ERP system. Even better if they are able to move to a four order of magnitude level of change, they would be able to recognize that the change within the company, is not simply affecting them internally, but also externally with relationships with their partner. So, by recognizing that ERP introduction, can potentially affect the communications that they have with their partners, they can make more change plans to factor that in. A second pitfall that we commonly see in change management is that, the leadership of the company doesn't sustain the introduction of the ERP system well. If the top leaders don't show that they're enthusiastic about the introduction of ERP. The workers at the bottom level might perceive that, the ERP system is probably not as important. Hence they must skip your training sessions, they might not attend the meetings that they're supposed to give feedback to the implementation team. All of this could lead to again a downfall in the implementation of the system. A third problem that we see in change management is that, the techniques of change measures are not well integrated within the plan of implementing the system, and because this steps are not implemented in the overall plan. Whenever accompany hits a tough spot, there might be a temptation from the mid managers and even managers to cut resources allocated to the implementation team. For instance, they might not allow their workers to meet with the implementation team, or they might reduce the time to spend with the implementation team, to help to customize or to make the system work. So, seeing this three Pitfalls, lets us next talk about some of the strategies that companies could take, to defend themselves against this three Pitfalls. The first strategy, the main thing that companies could do, is first of all to assess the level of changes that are needed, as ERP system is being introduced. Going back to the framework that we see from the PPT sides, doesn't need to understand what are the changes involved in technology, the people, and also the process. At the same time after recognizing this different changes that are about to happen, there is a need for manages to effectively communicate different changes, that the company would experience to all his people involved. The number one fear that workers have upon the introduction of an ERP system is that, would the system replays my role. So, it doesn't need to be clear in explaining to the workers that how the jobs would be change, whether they will be relocated to a new department or would that has in their current role change. There's a need to assess the implication, and to come up with a line of action to mitigate these worries that people could have in the company. So, the second strategy that companies could utilize to defend against pitfalls, is to secure a commitment from the executive leaders early. What do I mean by that is to have a figurehead, or a senior management to come addressed the entire organization, so that it becomes evident to everyone in the organization that it is crucial that the ERP implementation has to succeed, right. Then in fact there's a saying that a implementation should not start, if the support from executive leaders are not there. Don't proceed, if the support disappear happily true, and if needed pause if the support from leadership has weakened. So, let's take a look at how companies could practically implemented, in the whiteboard. So, there's actually a proper way to utilize management support in the implementation of the ERP system. So, this is what is happening in the past where we have painfully realized that this is the wrong way, to actually communicate changes to your end users.Let us see the legacy approach, what really happened was that when an organization in need of implementing an ERP system. Will actually dedicated to a project team, all right so let's have this drawn on the board, so over here we have the organization, and typically on the top over here we have, the senior management, the managers, mid manages, and finally the workers, and the users on this chart here. So, that sexually denoted here, this is the senior executives, and then in this level here we have the mid managers, and over here we have the project team. The project team is often led by a project manager, and under the project manager, we have technical leads programmers who would figure out how the ERP system actually works all right, technical analysts, system analyst, programmers as well. So what happened in the old approach, and the wrong approach was that, the project team goes out to figure out how the ERP system works configures it, and then after that, the analyst programmers would then go talk to the users, so we hear telling them this is the way you should be using the system, let us know if there's any problem here right. So, the fact that this is coming from the programmer's tech analyst, but not coming from the mid managers right to the users. Users would naturally be asking like, why would we need to do our work in a different way using the system? You're changing the way that we have to do our work and this is not convenient for us. This is actually, something that is commonly known as resistance to change right, because users are now doing something that they're not used to, and they don't see a reason behind why they need to do that. In fact sometimes users because of the frustration that they see in switching to the new system, they might intentionally sabotaged, by mentioning bad things about the system back to the mid managers saying that the system that we recently acquired doesn't allow me to do my work, we should probably kill it. This actually sets up a bad sort of atmosphere in the accompany and the mid managers might buy into what the users are saying, and then slowly the news would get to propagate to the top levels. Then, if the executives were to believe that they might actually kill the entire project here, all right. So, this is one of the major races of not communicating effectively and incorrectly. So, what we found over the years was that, a better way to do it, the modern way of doing this, let's just put this on the board as well, so that we could see how this comes to play. Again, let's sketch out the two different groups here, the project team and also the organization sitting on the side of the board. So, the right way to do this is that the programmers and the analysts should be reporting back to the project manager. All right. Let's just put this back here so that you can all see this, the project team and the organization. With that, the project manager or with some of his staff, should be talking to the senior executives or to the managers on their findings. That they realize that there's other things that the system would allow us to do, the users will need to perform their tasks in a specific new way, all right? At the same time, here the managers and the senior executives would then taking this new pieces of information from the project team would cascade down. The new inflammation to the mid managers saying that, there's a need for us to change the way we operate and this is important for the long-term viability of the company. It will be a hard process but it's necessary. From there, the mid managers would then communicate to the workers or the end users on this news that they have to use a new system. Knowing that, the workers knowing that this is something that's important for the organization, for the company, and it's a direct order coming from the mid managers instead of coming from the analysts or from the programmers, they are more willing to accept these changes. As a result of seeing this support from the management level, we see a better ease into the process of adopting, all right? A better process of adopting the new ERP systems. Okay? So, with that, we'll move on to see the next strategy that companies would be benefiting when they are looking at utilizing management support. So, having seen how companies could secure upper management support in a practical fashion, let's also take a look at the remaining things that companies could utilize in order to secure and get commitment from leadership. There's a need for the implementation team to define the roles and expectations clearly, so that everyone knows who is the ultimate decision maker. This is important because during the implementation phase there will be times in which the team would not agree on decisions to make. So, if there are multiple options, there has to be one person that makes the final say. So, it's good to have that nailed down right in the beginning of the implementation. At the same time, there's a need for key managers and key users to be present and to show the support for the implementation. Simply because the key managers and the key users are the ones who know the business side very well and they will be needed to provide their inputs to the implementation team. So that the system can be configured and could be made in a way to support business processes. There's also a need for companies to secure leadership and commitment internally. This is something that external coaches could not do for them. They could engage external consultants and change management to help them but internally, they have to be convinced that this is an important task and strategic way for the company to progress and the senior management has to come in personally to show this. There's also a wrong misconception that the support from leadership can actually be toned down after the system is done or when the system goes live. This is wrong because users tend to have the largest amount of resistance when they are actually using the system. So, there's a need to continue to show support to the implementation of the system even after the system has gone live. Here's an excellent example of how leadership is being shown to implementation of the ERP system. This happens none other than in the University of Minnesota itself. So, in the University of Minnesota we had an upgrade to our system where we secured the people self human resource packet and we utilized that to upgrade our legacy system. So, during the implementation, the President of the university actually came out to address the users and the team implementing the system. He mentioned a very important statement, "I don't know of anything more important to the long-term viability and success of the university than the work you're engaged in right now." He further adds, "I have your back." Which is a very clear statement showing that he supports everyone's effort on this endeavor of making an upgrade to the system. A couple of more things to know in terms of having the right person to lead the change. The leadership has to be a person that is good at communicating. He has to be willing to provide information to the rest of the organization and be willing to take feedback so that everyone knows that their ideas and thoughts are important to the organization. At the same time, this has to be a person that has a certain degree of authority and respect from the staff. Such that in times where difficult decisions are made, people are willing to follow through those decisions made by the change leader. At the same time the change leader has to be a person that is able to show enthusiasm for the project and have a very positive attitude towards the things that he does. Because we know that during the phases of implementation, there'll be difficult times and there's a need for positive attitudes to be spilled over to employs. Finally, the change manager needs to be able to show empathy to stop constant, picking up this thoughts and concerns that staff have, integrate them into the change plan, so that the needs can be supported within the organization. There's a picture of procrastination. Procrastination is "Why do it now, when you can do it later." I wanted to show this picture to you to give you a warning on what not to do in change management. Definitely do not procrastinate and integrating change management techniques and the implementation of ERP. You want to start integrating and utilizing change management through kits as early as possible and continue for as long as needed. There's a need to communicate the benefits of the project to all levels of the organization, so that the entire company can be bought in on why a new system is needed. It's also important to integrate the milestones and measurements of success into the ERP project plan in the beginning. This is because ERP projects tend to span long periods of time, lasting for five years or longer. So, it's necessary for the implementers and for the users to see that they are making progress and they're gaining small wins over time, so as to keep the level of motivation high during the implementation period. Finally, there's a need for budget to be allocated in a wise fashion. Definitely do not scheme on allocating resources to the change team. For instance, the change team needs to be staffed by a senior leader. This is because if a change manager is a mid manager or a junior rookie person, in difficult times, different departments might come in and wrestle resources from the change team. Without the rights or the resources, the change team will not be able to do their job properly. So, having the change manager being staffed by a senior leader, he would be able to protect the resources that he has for change management.
