ERP – Follow-up Training 04/27/2012
Posted by TBoehm30 in ERP.Tags: End Users, ERP, ERP Implementation, Implemenation Plan, Methodology, Project Management, Training
1 comment so far
I spent last week in another System Administration class. There were 9 other people in the class with me. Most of those 9 had taken the class at the beginning of the project, but now they understand the system so the class actually made sense.
The first time we took the class, it was like drinking from a fire hose. We saw what the system could do, but there was no possibility that anyone walked away with the ability to fix anything immediately. We took our notebooks filled with pre-printed material, our extra notes and went home to practice what we learned. Hopefully, we at least got the big picture. It would take time to learn the details.
I had taken the class previously as well. Since I have been heavily involved in the technical issues of this project, I knew most of what we talked about during this round. I was only there to make sure that when we talked about something that was customized, or company specific, I could lead the discussion. Several times, I had to interrupt to say that this subject didn’t apply to us, or explain how we had already implemented a particular feature.
During the 4 day class, we covered numerous topics. Every now and then I would glance around the room to notice how much people were paying attention. The class was usually divided in their attention since they are the entire technical team for a company covering 4 states. I expected some division of attention while they had to attend to other duties.
Some topics were easier to understand than others, and some people had more practical experience with some topics. I hoped that, like me, people were paying extra attention to the few topics that they did not understand completely. I also hoped that they listened carefully to any topics that seemed new to them.
I walked away from the class with new ideas on how to use the system to improve the flow of information at my client. For example, the ERP system we work with has a statistical module for storing data over time. I had created a few dashboards using real-time data, but now I can use the statistical data to show those same dashboards over time.
This is the training model that needs to be followed for a successful ERP implementation. Like a good presentation, people need to be told what they are going to hear, then they need to hear it, then they should be told what they just heard. The plan for a new ERP system should include a plenty of training for all users of the system. They need at least two official training sessions. The first one gives them the overview of what they will need to learn. The second one goes over the same material, but this time the users understand the details.
Between the two training classes, people will need to practice with the new system. Some of them will design and document the new procedures. A few users will test out the limits of the system by pushing every button, clicking every link, and choosing every option. Some of them will go back and not think about the new software until the next class. Obviously, a good implementation plan will optimize the probability of users going back to practice with the new software.
A third class might also be a good idea to plan. At some point in the future, users will want to see what else they can do. They will want to go to a new phase where they wring out every improvement possible. A class scheduled for a year after go-live is a good time for that one. Users will have a very good idea of what they are doing, some small ideas for what they want to do, and a big appetite for new possibilities.
The good ones go like that because it’s a global world and Technology makes it happen.
Conference Room Pilot Techniques – The Handoff 09/30/2010
Posted by TBoehm30 in ERP.Tags: Conference Room Pilot, End Users, ERP, ERP Implementation, Implemenation Plan, Project Management, Software
add a comment
In a Conference Room Pilot the object is to practice the process. You get a group of people in the same room to use the new software and make sure that you understand how to use the system. One of the most important aspects of this meeting is to practice the handoff.
There are so many processes at any company that require more than one person to complete. Many processes take more than one department. At what point does a person know to start their part of the process? What does a person do at the end of their job to let someone else know to begin theirs? That is what the handoff is all about.
A good ERP system will have a screen that a user can go to that will show him all of his current responsibilities. This needs to be fully tested during the Conference Room Pilot. You need to make sure that when things go right, the screen shows all that it should. You also need to test that the screen still shows the next steps when things go wrong.
Some ERP systems will send a notification, most likely email, to let someone know that they are next in line for the process. Testing email in a software system can be tricky, but definitely worth the extra time.
Sometimes the process will be to run a query showing you what still needs to be done. The queries are good to test, but also show the user what they will see on a regular basis. When the process isn’t followed correctly, you will need to know if the right records show up in the query.
If users don’t know how to find their work, then their work won’t get done. The best time to evaluate whether they know what they are doing is before you go-live with a new system. The Conference Room Pilot will test the process and test the people. If the process isn’t as smooth as it could be, then you should have plenty of time to fix it and then have the users practice.
The other side of the coin is important as well. When a user is done with his work, what do they need to do to make sure the process is completed? It is not good enough to finish their own tasks, they need to do what is good for the company as a whole. That means making sure that the processes are finished correctly. It means that the person creating a payment approval alerts the person printing the checks. It means that the person receiving material notifies the person who matches the purchase order. This should be documented and practiced in the Conference Room Pilot.
Take a look at what processes your company uses that include a handoff. Could the process be improved by better or easier communication? You’ve got Sales Orders that have to be filled, then invoiced; eventually the payment has to be recorded and possibly finalized to a General ledger. You’ve got Purchase orders that have to be ordered, received, and then paid for. You’ve got inventory that has to be moved around and possibly inspected. For manufacturing plants, you’ve got plenty of processes around the routing of materials. For distributing companies, you’ve got to get the shipping process exactly right.
Technology should have a good way of notifying users that there is work to be done. Users should understand the process of making sure that tasks are fully completed. The Conference Room Pilot is the place to make sure that the process works, it is documented, and that people understand what to do. It is good practice to be ready for go-live; now is the time to test the process for when things work and when things go wrong.
The Conference Room Pilot is a safe place to get processes in order. It is the time to get used to the new software system. Sometimes change can be difficult and users need time to practice without any pressure. Project Managers should schedule plenty of time for the Conference Room Pilot because they know that it’s a global world out there and Technology makes it happen.
Lessons Learned 06/17/2010
Posted by TBoehm30 in Project Management.Tags: End Users, ERP Implementation, Implemenation Plan, Plan, Project Management, Success
add a comment
I recently participated in a meeting to discuss the Lessons Learned during the recent ERP implementation. Many projects skip this vital step because they don’t have time, or after a successful implementation, what’s the point? This meeting turned out much better than I thought it would, and we actually documented a list of items to review for the next projects.
The project ended successfully, so we didn’t have to point fingers blaming anyone. I have been to plenty of those types of meetings where nothing gets done except making people feel bad. When it was my turn to talk, and I suggested improvements to the way we prepared for the Conference Room Pilots or Dry Run, I prefaced it by reiterating the successful nature of the project. I couldn’t pin blame on lack of preparation because in the end everyone was prepared enough.
People did listen to the suggestions. We still have 2 Business Units that will go live on the new ERP system, and they now have on idea of what issues they need to review to improve their chances of success.
The project manager for the software vendor attended the meeting. During the project, there were times that he became defensive about his software. He would come up with ‘reasons’ why it wasn’t their fault, or get upset with us about our tone. During this meeting, however, he listened to everything in the spirit of constructive criticism. He didn’t get too defensive on the phone and said that he would take our comments to an appropriate resource. He responded in email with extra documentation that could have helped during the project (we actually had it, but some people didn’t know that), and will definitely help the last 2 Business Units in their project.
We spent some of the time patting ourselves on the back with the things that went well. We didn’t just talk about the things on the project that went poorly or could have been done better. We put in extra hours over the weekend before go-live and were totally prepared for that work. Talking about that work and reminding everyone how great they did felt so much better than focusing only on the problems. Reviewing the items that went well made everyone feel good about the work they did and prevented deep depression over our faults.
We concentrated on the actions we could have taken, or will take next time, to do better. We tried to direct the discussions toward constructive criticisms instead of blame or complaints. When the conversation turned more negative we directed it toward a more positive note.
I think everyone walked away from the meeting feeling good. We documented a full list of items to keep in mind for the next projects. Lessons were learned, and they will stick with those who learned them.
Putting in new technology is not easy. We need to make sure we get better at it by improving each time we do a project.
For your next project, make sure to schedule time for the Lessons Learned meeting. It will improve future projects, and people will be more comfortable with taking on the responsibilities of the project.
While we didn’t create a list of questions beforehand, that would have been a good idea. Send out a list of open-ended questions to prepare people for the meeting. “What worked best?” “What could have worked better?” “What prevented goals from being achieved?” etc.
If you need to include many people in the Lessons Learned process, then send out a survey. This could be done over email if you properly include everyone, and make sure that you follow up with summaries.
You may know it, but others may not, so spread the word: It’s a global world out there and Technology makes it happen.
ERP Project Management – Make Them Sweat 05/18/2009
Posted by TBoehm30 in ERP.Tags: End Users, ERP, ERP Implementation, Hard Work, Implemenation Plan, Implementation, Plan, Software, Success
4 comments
Build some slippage time into your project plan.
Our plan calls for four business units to go-live on four different dates. The first one in September, but because of fourth quarter restraints, our next one isn’t until February. This is the plan approved by upper management giving everyone enough breathing room to perform their day jobs and still have enough time for the implementation project.
We had wanted the first two business units to perform together in their tasks. We scheduled the pilot programs together, the business process modeling, the testing, etc would all be done at both locations at the same time. This would allow comparisons in problems, coordination of solutions, and a general feeling of comraderie during the project. Everyone thought this was a good idea until the pressure started.
Our second business unit has more work to get their system running than the first business unit. The companies are different enough that this was obvious from the beginning. The longer project for the second unit was a perfect plan to allow them the time needed for that extra work. Unfortunately, they can already feel the pressure coming from the amount of work being projected to get them ready. We had planned on doing the first pilots together in a few weeks for the two business units.
They decided that there just wasn’t enough time to be ready for that pilot. In the steering committee meeting we fully discussed the pros and cons of letting a few tasks slip for the second business unit. After pleading their case, we agreed that it was in their best interests to expand their time frame for certain tasks, without changing the final go-live. We didn’t touch the timeline for our first business unit.
This experience showed everyone the amount of work that is needed for a company-wide software implementation. It opened their eyes to the tasks that need to be completed by their deadlines. They spent a little time worrying about how to finish their responsibilities on time.
A little sweat never hurt anyone. Now they will have no trouble figuring out what to do. After all, everyone here knows that it’s a global world and Technology makes it happen.
I will help you understand your technical issues from a business point of view. Please read the blog to see what I am currently working on, or have done in the past. If you have questions, please leave them here and I will get back to you quickly.
