Process Before Automation
One of the most valuable lessons that I've learned in the pratical world has been "Process before automation." This statement is extremely simple and extremely obviously, but the context is valuable.
When did it click?
Prior to my time at Malibu Boats, this statment didn't mean as much to me because almost every problem that I was solving, was something that I was already doing manually. This meant that I understood the intricacies of the process and also the pitfalls in the process. It all came so naturally, that I never took the time to full ingest that statment.
However, when I got to Malibu, I was assigned a project to help remove a critical bottleneck in our production process. Unfortunately, I didn't know anything about how to build a boat, how to program a CNC router, or how we as a company managed CAD files. As a result, when I built the initial draft a program at Malibu, I went straight into building a solution that solved the process problem identified by the Process Engineering department. The application worked bueatifully and solved the exact problem that they had. I spent the next few days working side by side with the users to refine the product to be the most user friendly application that I could provide. However, within a few weeks they realized that this program could benefit many more areas within the company.
I reached out to my boss and told him the incredible news that the company loved the program and wanted to scale it out. I was going to need to spend a few days adapting the program to the other applications. He stopped me and told me "Process before automation." As a bull headed newbie in the field, I told him that the process engineers had already identified the process optimizations that were needed, I was just automating it. I was fortunate to have my boss as an incredible mentor; he advise to slow down and actually go down to the floor and evaluate the entire boat building process. He allocated the time for me to learn what were the individual components that went into the various functional areas of the production lines. Through this process, I realized that there was a distinct gap in our existing process and if we could implement consistency in the way that we named and distributed CAD files, then we would be able to update the program once so that it would for not only the areas we had now, but the areas we had on the roadmap for the next 3 years.
That was the moment that "process before automation" clicked for me. I was able to save future development hours by evaluating, defining, implementing, and reinforcing a process change that was focused on people, not software.
How to scale out this thought process?
Since then I've refined the way that I approach "process before automation."
- Define the question that got you involved.
- List out all of the steps for all impacted areas.
- Find the consistency and differences.
- Generate the new list of steps that you plan on automating.
- Implement the manual steps and observe
- Refine and go back to step 4 until you feel confident that it works for people and software
- Now, implement your newly definded process that people are trained on and understand
- Follow proper SDLC
- Observe and refine
Let me know if this works for you.
If you've had a similar experience or if you have any feedback, reach out through the contact form or reach on Mastodon, arbdev@hachyderm.io
