The theme of our fourth educational webinar, The Importance of End User Acceptance, was a reminder of how important it is to engage with those who will be using a Manufacturing Execution System (MES) or any other IT system as part of the implementation. This is a mindset that should be in place throughout the process of scoping, vendor selection, and training. It is easy to get caught up in features, functionalities, and integration requirements. But, without a clear focus on acceptance testing, it will be hard to justify the value and have any sort of long-term success.
Register now to watch a recording of this acceptance testing presentation.
At the end of the MOM Institute’s presentation, there were several questions raised – plus others we didn’t have time to include in the original broadcast. Below is a summary of what was discussed. Consider these as you manage your current and next systems implementation to achieve the greatest success!
During the presentation it was mentioned how important it is to set up KPI metrics to measure the success of acceptance testing – can you share any?
This is a good question, but a difficult one to answer. One option is to ask users to sign off on their acceptance, but that is more theoretical. One approach is to match KPIs that track your progress, with the concept being that if you don’t achieve those progress checkpoints, the reasons is because of a lack of user acceptance. But, once again, this is probably more theoretical as there could be other reasons for not achieving this project based KPI metrics. Probably your best option is to do a series of interviews, just like you did at the start of the project when you defined its scope. Follow up interviews can then ask users if their needs have been met. Or, if not, identify the shortcomings and continue to address them until fixed. The key is opening and continuing with a line of communications that persists through the entire project, including post go-live.
What are some techniques for managing changing business stakeholder requirements over a long implementation period?
To start, I’ll assume that your team of stakeholders has project insights that will progress over time. You undoubtedly have smart people who initially bought into the project. The best way to manage how this set of expectations will evolve over time is to manage this process with regular, effective communication. Your stakeholder team will have cycles and objectives of what they want to accomplish in the next 3, 5 or 7 years of time. Similarly, as we talked about with regular communications with end users, it is equally important to embrace this approach with the business stakeholders too. You need to manage perspective and adjust to maintain close alignment.
Should my software vendor have representation on my manufacturing Center of Excellence team?
Yes. Not only for the duration of your project, but it would be a good idea to do so on a continuous basis, if possible. Vendors should be partners to work closely as part of your organization. During the time while you are working on the project and deploying the software, of course, it is a great idea to have a vendor expert on your team. They are the subject matter expert on the best way to use their software, how it works, and what other customers are doing. You don’t have to reinvent the wheel. Use them as an expert to help with both specific project initiatives as well as in the future on how to extract greater value from your investment.
A comment came in from an attendee during the response to the above question. Their company has a change board approval committee, so all users and stakeholder review any changes to projects, to add structure to change management. This also helps with managing the possible “shiny new features” that can creep into a project to stay focused on what is most important and maintain alignment in the right project objectives.
Read this article for further insights, Easing Change Management in Manufacturing
I like this user-centric approach in viewing the Manufacturing IT design and deployment; in Software Development this is (part of it) specifically addressing UI/UX methodologies. Any comments?
This is a great analogy and has much relevance. In the same way that a software program is designed from the start to meet a challenge and deliver a user experience that is well thought out, intuitive, and easy to use, a successful software implementation should follow the same steps. While no one will likely argue with this type of logic, it is easy to get distracted or too focused on one component of a project or software release. Taking a step back and realizing that nothing else really matters in the broader scope of the project without the right UI/UX to ensure user needs are met.
