One important lesson that I learned in my Industry 4.0 journey is to incorporate a feedback loop for the end users and stakeholders for every implementation, even if the project is a pilot. My first implementation of a major IT software was in 2012. The company I worked for was building a new, state of the art factory in Texas and was the first site to receive the software. There were only a handful of users. We decided that bugs and requests for improvements would occur via email.
One of the major modules was a system to collect the first article inspections for the first machined pieces and provide a formal approval of those parts from the Quality Leader. The new machines, new operators and poor work instructions created a perfect storm for quality. Good parts were a rare occasion and quality was not signing off the equipment for production use. This created significant delays to the production schedule, so the senior leader called a meeting. Somehow, since my IT project managed this process, I was invited to the meeting.
During the meeting, the Senior Leader challenged the process and the application. My defense was that the IT tool was not causing the problems with the parts. After all how could an IT system that was not connected to the CNC machine cause bad parts? Well, the Quality Leader chimed in and said that the Second Shift employees had not been given access to the tool and the process was impacted significantly. I was shocked! It stung even more when he reminded me of the email he had sent several weeks earlier asking for the additional access. Thank goodness the meeting was a conference call because my face was red and I was sweating profusely.
I don't like to repeat the same mistake twice, so I gathered the team together in an emergency meeting to discuss. We decided at that point to create a workflow in our application to collect any feedback. We all agreed to direct any requests to the system so that all communication would be centralized. One developer on the team created a button on the home screen to make the process as simple as possible.
Once we centralized the communication to avoid the lost email scenario, the team established an operating rhythm to hold ourselves accountable to driving the request for change to closure. In our meetings, the requests would be assigned to a developer or an administrator to execute. I could go into the details of the workflow, the escalations and service-level agreements, but I'll spare the details. The bottom line is we had a robust mechanism to collect feedback and hold the team accountable.
What was created out of an embarrassing situation, actually proved to have quite a few benefits. Over the years, our team could track the number of improvements made to the system, which assisted with planning the application team's resources. Metrics were established around the cycle time on the feedback, with goals for improvement established every year. The biggest benefit was the rapport we created with the end users. When they had process issues, our team became the go-to for solving those problems.
Now, I've certainly been called to the table after that miserable experience for varying issues. I will say that not one of them was a missed change request from a key user and stakeholder of the process. Whether you are purchasing an application, or developing technology in house, I highly recommend introducing a robust feedback process UP FRONT.
Commentaires