As you consider your ERP post-implementation activities, remember that almost everyone focuses on the go-live event and at that time considers the implementation complete. However, the real return on investment from the ERP comes from the post-implementation activities that occur within the first year. It is a sad fact that most ERP teams disband after the go-live. Ideally, the team remains, if even for on a part-time basis to continue the excellent work that led to the successful go-live. Many books, blogs, articles, and other resources focus on the Technology aspects of the Post ERP Implementation activities. They fail to address the People and Process aspects of ERP after the go-live.
The first year after the ERP implementation is imperative in determining the long-term success of the system. Many post-go-live activities need to be both planned and executed after the launch. Performing a post-implementation review, transitioning the consultants, determining the governance strategy, continued training, and other activities ensure on-going success of the ERP solution.
Ideally, around the time you are running your User Acceptance Testing (UAT), or earlier, you should be putting together your post-implementation strategy. Don’t wait until the week of go-live to ask “Now what?” Just as you had a project plan to execute on the design, build, test and roll-out of the ERP Project, you must put in place a post-go-live plan. The plan should address the People, Processes, and Technology of the operational ERP environment. Let’s discuss some significant ERP activities in those domains:
People:
Post-implementation review – capture the wins, learns and changes
After the go-live event, ensure that the core team meets to discuss what was successful about the implementation, what did we learn from the project, and what would you change going forward? The team must document theses “wins”, “learns”, and “changes” (WLC). Include a WLCs review session when planning out future initiatives. Develop a practice of incorporating this knowledge of your projects into the future project planning activities. It is our experience that these sessions provide valuable insights into not only how the project executed, but the perceptions of the team members on what worked and what didn’t work. Writing down these discussion points will help you on future projects.
Transition the consultants
You likely had a team of advisers from your implementation partner involved in the ERP deployment. Once you are live on the new system, request their updated implementation documentation. Key documents such as a solution design or technical design need to be updated and delivered to you as a reference document for future changes or troubleshooting issues.
Additionally, in your contract with your consultants, did you include any post-go-live support hours? Is the internal team who will support the ERP system adequately trained and able to assist the users with technical or process questions? Use some of these hours to ensure that there is a skill and knowledge transfer.
Quarterly review training
A fundamental way to make sure that you get the adoption you desire from the ERP system is to initiate quarterly refresher training classes. In the first quarter after go-live, it should be simply a refresher course. But as you continue, you should dive into deeper functionality that will help the users in their tasks and expand their knowledge of the software. Always communicate the “What’s in it for me” benefits to the users before go-live. If you didn’t do that, this is a perfect time to remind them why they should be using the system to the fullest and how it will help them with their jobs.
These refresher classes may be in person, but many companies are now using online training courses. Allowing users to view videos of the classes or take self-guided training are excellent ways of providing system reinforcement training. Keep these training classes going and archive them. As there is turnover in your organization, new users will appreciate the catalog of past courses they can reference.
Processes:
Capture the knowledge
As mentioned above, it is important to capture the system expertise of the consultants, but it is equally important to ensure that you have sufficiently documented the new processes in all areas of the implemented system. Typical processes you should include in your documentation are the Order-to-Cash cycle and the Procure to Pay cycle. But even the GL Posting process and the inventory cycle counting methods should be documented. Capture decisions made during the project so that in six months to a year when everyone has forgotten the implementation cycle, that you have a reference as to “why” you expect people to operate in a particular fashion.
Many ERP systems have a useful life of 5 years or so because the people who implemented the system have typically moved on to other departments or have left the company. That leaves a knowledge gap, so arbitrary decisions get executed without understanding the initial considerations of “why” the system was setup the way it was. Documenting the processes and significant decisions will help extend the life of the ERP solution. Yes, the system will evolve, but as you grow the system, you should create a written knowledge of the how and why considerations. Future decision makers will be more informed and will have an understanding of the original vision for the system.
Documenting the processes and decisions points may seem like a lot of extra work, but in the scope of a million dollar or 50 million dollar investment, it ensures that that investment will continue to provide a return.
Post-implementation process review
Performing a post-implementation process evaluation provides a checkpoint and validation to your original implementation assumptions. One or two months after go-live, the implementation team (or a key subset) should work with the users who are using the system to ensure that the setup for the system matches with the end-users expectations and that there are no bottlenecks for the users to get their work done. Often, the initial ERP implementation team includes a representative who makes process decisions based on his/her understanding of their business unit’s methods. As much as they may try during the implementation, they may miss key process requirements from other similar business units. An example is having a person representing the purchasing group in the United States, miss the requirements his/her colleague has in the United Kingdom. They may have made some assumptions about a common process, but missed the detailed requirements for the partner business unit. This misalignment should be remedied as soon as possible. If there are gaps in the alignment between processes and the system, a user story (an agile user requirement) should be documented and added to the backlog for system enhancement.
Providing a post-implementation review, provides users with a feedback mechanism and also provides a way of catching issues early, before they lead to significant adoption issues, such as abandonment by the affected users. On a continuing basis, a business analyst should work with the user community to ensure that there is a perpetual alignment of the system to current processes.
Technology:
Post-implementation backlog review
During the implementation, requirements are captured, but often there are some user requests are not fulfilled during the initial deployment. These may be out of scope, nice-to-have requests, or items that are not feasible within the timeline defined. As such, a request backlog is collected. The backlog of requests should be reviewed post-go-live to determine the appropriate time frame in with which to deliver. In some cases, the requests are deprioritized. Alternatively, some user stories are put into the next release cycle. Many companies today are working with an agile process for delivering on these requirements. In addition to user requests, there may be additional systems to integrate with, other, non-critical data to load, or even standard software maintenance releases to apply. All of these should be planned for and put into a structure that allows for on-going innovation of the ERP system. This delivery is often part of a governance plan.
Establish your system governance structure
Do you have a process in place for managing changes to the ERP system? How will you capture ongoing user feedback and requests for enhancements? How will you adjudicate the priorities and conflicts in requests? How will you manage your backlog of user requests?
Many IT departments have processes in place to solve users issues. But these traditional IT tools and methods do not necessarily handle the request backlog for an ERP system. Most importantly, they do not always tie back the functionality to the original request (or “user story”). There is a class of software that is used to manage these issues called Application Lifecycle Management (ALM) software. Using a quality ALM, your IT team can both manage and document the user stories (requirements) and provide traceability from system functionality to the original request.
Aligning user requests is a major component of a governance structure. Think through how you may harmonize conflicting enhancement requests. For example, one division may want to rename a set of fields to accommodate the way they do business, but in doing so, it may break another groups’ way of operating. When establishing a governance structure, initiate a method of judging and aligning requests. Sort out how to break logjams of conflicting priorities. All-in-all, it is necessary to plan out how you manage, harmonize, build and deploy changes to the system.
Begin execution of an on-going maintenance plan
ERP systems need care and feeding. As mentioned above, there are usually quarterly or semi-annual releases of software updates. These need to be scheduled and deployed appropriately, without significant user interruption. Along with vendor updates, new functionality developed internally needs to be prepared and released. A release cycle needs to be developed. How often and when will you release new features to the user community? More importantly, how will you communicate the new features and will any of the new software capabilities require user training? Can this be timed with the quarterly update training, or will special sessions need to be scheduled? Keep an eye on development capacity. You may only have a handful of resources who can implement the ERP changes. They may already have their hands full managing the system and preparing for vendor enhancements. IT must provide feedback on capacity back to the business stakeholders. Clear, open communication should be part of any governance plan.
System evolution planning
Lastly, keeping the ERP system fresh and evolving will continue to allow the business to operate at peak performance. Re-orgs, acquisitions, divestitures, and other business management activities will add new complexity or challenges to the ERP software maintenance. Where possible, have regularly scheduled executive meetings focused on system direction. When you began your deployment, you likely had a functional team working on the details of the system and process alignment, and you had an executive steering committee providing guidance and direction. These groups ideally should remain and continue to offer improvements and directions for the evolution of the ERP system.
ERP Post-implementation activities summary
We have defined here a high-level list of activities that a medium-to-large organization may wish to focus on post-implementation. This is not an exhaustive list, but should start the conversation about what to consider and plan for after the ERP go-live. Please comment below if you have other activities that should be included after the launch of an ERP system.
One thought on “Post Evaluation and Maintenance”