Implementation Based on Partnering with the Customer
In many implementations, the step directly following Discovery calls for the implementor to step back and develop a configuration and deployment plan based on the information gathered. This is usually followed by a series of submissions to the customer, along with explanations and presentations, followed by requests for revision, after that re-submission and then a recurrence of the entire cycle.
This can be very time consuming.
The Algorithm Implementation Methodology is instead based on a collaborative approach between the Algorithm team bringing deep knowledge of the ERP system, and the customer Project Team who are decision-makers from each functional area of the client company. Both teams are well-versed in the stated goals and objectives for the implementation.
Meeting in the Middle
Since the Discovery process has brought the Algorithm team closer to the customer’s team in terms of understanding their unique business processes, the next step is to bring the customer’s team up to speed with a better understanding of the ERP application: what it does, how it works, what is possible, what the potential design options are.
During the Project Team Training, an initial data conversion is done. This data conversion iteration will help validate some of the initial configuration decisions, as well as give the Project Team a better understanding of what their legacy data will look and act like in its new environment. Subsequent data conversions and how they help to validate and inform processes as the project team moves through them are also described.
Implementation Team Training
The primary goal in the Project Team Training phase is to “train-the-trainers” to enable the Project Team Leaders to conduct end-user training in their areas in the future. Each will be responsible as the “process owner” for a specific role in the company that performs specific activities using the ERP. Examples would include:
• Customer Service
• Order Entry
• Inventory Management
These Project Team Leaders will designate the appropriate Subject Matter Experts (SME) for the processes in their departments. These are the employees who are the most well-versed in any given process, the “boots on the ground” people who will be doing the actual work. Although the SME’s will not participate in the actual Project Team Training, they will assume an advisory role later in the Solution Building phase. By using management personnel for these functions our effort benefits from their experience and input, and the company’s managers benefit from deeper level training on the functionality of the ERP solution.
As we train on the various functional roles, such as entering an order, we discuss how each might be applied to their operations and the specific way in which they now perform their processes to identify best opportunities for automation of each. This deep-dive into the ERP platform and the customer’s operations consistently produces very customer-specific solutions that truly meet the unique needs of the customer. It also builds a deep understanding of how the ERP connects the various parts and functions of the company. This also informs the creation of all ERP operations in the context of how they will interact with each other.
To be clear, the entire Project Team participates in the training on every function and the development of how the application will be configured for their specific need. This builds stronger, deeper understanding of the entire operation for all managers which can only enhance their collaboration.
Implementation Team Training is the preparation for the Solution Building phase of the methodology. Here’s where we get very focused on processes so we can develop the best way to configure the ERP to accomplish each one. The approach is very granular. We’ll schedule time to develop the specific solution for creating, for example, drop-ship sales orders and workflow they require, from required fields for the actual order, settings for each inventory item to be included in each drop-ship, sales order specifics, purchasing requirements, order types, payment types, setting up merchant accounts for credit card processing, how prepaid orders are accounted for, the entire process workflow.
We go through that same procedure for each process anyone at the company performs on the ERP.
Development and configuration activities don’t wait for weeks of discussion, planning, or development and testing. As we make firm decisions, we develop them right into the test system in something resembling an adapted form of Agile methodology. They are then tested both individually and holistically and approved before we move on to the next.
This continues, focusing on each module in turn. We'll do that for sales orders, and accounts receivable and purchasing and everything else across the enterprise. Our quasi-agile approach keeps the momentum of the project going.
It's all about momentum. We build energy and keep that momentum going. Once all processes and procedures have been designed and developed, we have a complete platform ready for end-to-end testing. That's exactly what goes on in the Pilot Testing phase. The implementation team exercises the entire system using the end-to-end process working on the second, more refined, converted data set.
It’s important to note that this is not classic user acceptance testing (UAT) in that we are not taking a small group of users to go live with. Instead, the implementation team, our group of process SMEs, will pilot each process to make sure that each process functions properly.
As such, a sales order will be created. If something needs to be purchased or produced, they'll go through that exercise. And once it's in stock, they'll create the shipment and that'll create the invoice. If they had to purchase something, they'll have an accounts payable bill to enter. So now they've got accounts receivable and accounts payable, they'll collect the cash, they'll pay the vendor, they'll run a financial statement.
In that way, during pilot testing we test end-to-end.
We test the various scenarios to make sure that a dropship order processes correctly, a regular order processes correctly, a prepaid order processes correctly, even a customer return. We test all the different variations of the process.
During testing we consider the key issues. What is the outcome we want? What can happen to make things go bad? Then we can focus on those areas to put governance and control systems in place to really tighten that up and build a sound process. We ensure that the data and the processes, including all forms, reports, dashboards, etc. are 100% accurate before proceeding to the next step.
End User Training
A few weeks before the scheduled “Go Live” date, we commence End-User Training. This training is conducted by the client Project Team Leaders to the users in their areas. They provide a comprehensive sequence of training classes having each user practice the functions they’ll be performing on a daily basis to familiarize them with how those actions will look and feel on the new ERP platform. They confirm that each user understands each process and recognize when it’s giving them their desired outcome.
We’ve found that users can be remarkably adept at finding ways to break the system that we didn’t provide for during solution building. This gives us time to remediate those problems well in advance of go-live.
At this point every user is tested on the functions they will be performing on the system culminating in the “Conference Room Pilot” which is the go/no-go decision point to determine if the entire team is ready to go-live. Failure during this session will result in returning some users for more training preparing them for another cycle of testing.
Once every user has passed their test and the entire process has been approved in the “Conference Room Pilot”, we are ready for the full pilot.
This is the last step before Go-Live and is the client-led practice sessions for all users. The most important job of our piloting “proctors” is to help the end-users become rapidly adept at their new ERP processes. Minor fine-tuning of any part of the system is still acceptable at this point and is done at the discretion of the entire team.
We’re in “the Red Zone”
In our next, third, and final segment we’ll describe what day zero of “Go-Live” looks like when it’s done using the Algorithm method!
CONTINUE: The Algorithm Implementation Methodology Part III
GO BACK: The Algorithm Implementation Methodology Part I