Posted by TBoehm30 in .
Tags: , , , , , , ,
A new ERP system (or any new software) can be a huge project. It takes coordinated planning to get it implemented on time and on budget. One of the tools used to keep people on task is the Conference Room Pilot (CRP).
The CRP is where you can figure out what to do on your new software system, and practice what you think you know how to do. You should have the chance to demonstrate to management, the software vendor, and your consultants that you will be ready for go-live. If you are not prepared for the go-live, this is where it will show up. The decision to delay should be made after a bad pilot, and not hours before a go-live deadline.
When should you conduct the first CRP? When you sign the contract for a new software system, the first plans to make are for training and implementation. The length of the project will determine when you should schedule the pilots and dry run(s). After approximately 1/3 of the project time is done, you should be able to have a good CRP. If the project is going to last 6 months, then 2 months of practice should be sufficient to get together as a group and officially go through the software to practice your business processes.
There are several ways you can go through the software. You can start at the first menu and work your way to the bottom. You can start at the beginning of the documentation and follow it like a guide to the end. You can create test scripts and test each process that you will need. You bring in each employee who will use the system and have them show you what they know. People could come in alphabetically, or in the logical order of your choice.
The right way to do this, however, is to concentrate on your business processes. It is not enough to know how to use the receipt screen to receive boxes off the dock. Your people need to know what to do when there is a box on the dock. They need to know that if the box is there, then they will need to go to the receipt screen. They should know how to print the receiving documents and who will take them to get the products put away or quality tested. The quality people need to know who will be giving them new products and then how to mark them as tested in the system.
The business processes should be documented and brought into the CRP for validation and correction. If you have the software vendor or outside consultants with you at the pilot, they can help you to refine the processes and determine best practices. You need to schedule the pilot in a logical order such as starting with the Sales Orders, proceeding through the manufacturing and shipping processes to the invoice and A/R process. This will allow a smooth handoff between groups.
Understanding the business processes and how to use the new system to follow the processes is the single most important aspect of the CRP. The handoff of processes should be practiced until it is second nature. People should be living and breathing their new processes as much as possible until the switch is flipped at go-live when the new software is turned on and used to run the business.
There are other concerns for the first pilot. You need to have gotten legacy data into the system. If the data is loaded through an automated system, then you should have plenty of data to play with. If it is being manually loaded, then you should be well on the way to having it all done. You can use the first CRP as a chance to validate the way the data is entered into the system. You will find problems such as decisions made to manage products, the setup of BOMs, or the default address settings for customers. You still have plenty of time to get those problems fixed and re-tested.
Beyond static data such as customer, suppliers, products, BOMs, Routings, Installed Equipment, etc.; you need to have practiced getting transactional data into the system. If the software is replacing an existing system or process, then you will have to add in Sales Orders, Work Orders, Purchase Orders, A/R, A/P, Customer Complaint Cases, etc. The CRP will be a good time to use the data to validate that it is being loaded or entered correctly.
Reports is something to think about, but at a lower priority. You will need some reports for the CRP, but you won’t have time to finalize many of them. The CRP will be a good time to see if out-of-the-box reports will be good enough for your processes. If not, you can spend a short amount of time noting changes, and get that into the queue to have done before go-live.
Security is another item to put on the list, but not as a priority for the CRP. You will need separation of duties, or division of data between sites, or people. There are going to be plenty of functionality that you don’t want everyone to have. Setting that up too early could make a CRP more difficult. If a user doesn’t have the authority to get into screens required for their job would slow down a CRP. You can wait as long as the final Dry Run before setting up true security.
You may think that the system is completely setup after 2 months of practice, but in my experience, you always find little things that can be improved. A parameter here, a setup item there, a dropdown that can be tweaked are things that might be suggested during the CRP. These should be carefully tracked so that they can be duplicated on a Production system. It is not terribly important to get all of that correct this early.
If planned from the beginning, your CRP can be a successful way to keep the project on schedule. It shows everyone that people are practicing with the new system and working hard toward go-live. It will give people the confidence to keep on working hard to be ready for that terrific day when the new software is finally turned on to run the business.
On the other hand, a poor CRP could also motivate people to work harder. If the project team gets good constructive criticism, they might decide to turn things around. At the first CRP, you still should have plenty of time to fix the project and get it turned around.
Tell me your stories of the Conference Room Pilot – good or bad. I know you’ve got them because it’s a global world out there and Technology makes it happen.
This post was originally published on this site