A gap analysis is useful for comparing expected deliverables versus project results. Our methodology incorporates steps for effective knowledge transfer and overall support to change management. As you examine whether new processes are being followed, you will identify areas in which employees could benefit from additional or ongoing training.
Query your stakeholders, including employees, managers, the IT department, customers and vendors. Are they satisfied with the new system? What was successful — Talk about what went well in the project, where your people are seeing improvements in their day-to-day, etc.
What was challenging — Discuss areas that are falling short of expectations, teams that still need more training, etc. What you would change — Typically, this will include aspects of the project that could have been managed better. These are important insights to feed into future phases.
What still needs to be addressed — During the implementation, you may have re-prioritized your requirements, so make a list of features or functionality you still want to implement in a future phase.
This is also a good opportunity to validate your processes. Your project team should gather input from key users to make sure the system is working as expected and uncover any bottlenecks. Make a running list of issues that come up and create a plan to fix them as soon as possible. Finally, include your ERP partner in your post-implementation review. Documentation is often put on the back burner because it takes time.
Document why important decisions were made during implementation. Understanding why a task is done a certain way will provide context for users. Update your documentation over time as your processes change. They will continue to evolve as your business does, so make documentation a requirement for each employee.
In the months after go-live, schedule refresher sessions with each team to reinforce new processes and give people an opportunity to ask questions. As time goes on, you can go into deeper functionality beyond the essential features they need to know. Having worked side-by-side throughout implementation , hopefully you and your partner will already have a close partnership. One transaction inventory is where we use batch processes to post transactions at set intervals.
Downstream work might be delayed or even a downstream user forced into a sub-optimal choice through lack of information. Excess motion can be a defect in the ERP system. Have we limited computer access in production areas causing shop floor workers to stop work and move to where the terminal is to enter their transactions?
When they arrive, do they need to remove gloves and other personal protection equipment or is our system ready to use with touch screens and measuring tools linked to the ERP through USB connections? Defects are a waste that includes ERP transactions and data as well as the inventory of products.
An audit will find those defects. We can now use Pareto analysis to identify those defects that cause the most problems and occur the most frequently. When we chose the ERP system we use today, we justified the purchase and implementation through certain returns on that investment.
We could audit our use of that ERP to quantify those returns after implementation. We planned to save payroll expense by reducing our labor force because of gains from ERP. Has that reduction in force been completed and did we realize the savings expected? What are the actual costs as compared to those assumptions? If we promised a return on investment of 7. Whatever your audit objectives, a team to perform that audit is needed. Who should staff your team?
A good rule of thumb is to choose people outside the domain of the audit. Engineers should not audit bills of material, but financial people have the understanding of complex data relationships and could perform the audit. Auditors must be people who can think critically and spot flaws in logic. They must also be agile enough to understand when a user-developed workaround is an improvement from the expected process flow.
The developers of your ERP cannot have understood every situation possible but they did their best. That resource could also be overtime or bonus pay rewarding the auditor for the additional time required during the audit. If an ERP audit is to add value, it must lead to actions. Faults or defects found need to be corrected.
Those faults also have a priority. 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.
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. 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. 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.
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.
As much as they may try during the implementation, they may miss key process requirements from other similar business units. 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. 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.
0コメント