Over the years in both corporate America and as a consultant, I get many questions about using software to automate processes. Invariably, the question goes something like this “what is the best software to automate my product development process” or “what is a good software package for my Intellectual property process.” I think these questions put the cart before the horse. Yes, we all want our processes to be efficient, low cost, and provide value to the customer. But too many times I have seen an organization automate a bad process. This is particularly true with applications like SAP or other ERP packages. Immense amount of time is put into implementing the software, but how much time was spent mapping the process? Is the process optimized? Many processes evolve over time and as such have a lot of “bolt on” fixes that may negatively impact the process flow.
So how do you go about this in a different way? In one company, they needed an improved product development process. I was asked to lead the development of a new product development process. A team was already working on automating an existing process. It turns out they were working on automating only a portion of the overall process. We put together a multifunctional team that had stakeholders from all of the functional groups so that input was captured from everyone involved from the customer to final manufacturing. The first thing we did was map the process. Then the team identified the key process inputs and outputs. What evolved was a customized phase/gate process for the business. The next step was to build the right tools to help all of the stakeholders (marketing, R&D, applications engineers, process engineers, finance, sales, etc.) run the process. This was actually the best part. The team developed some really nice tools (risk assessment, Intellectual Property assessments, financial analysis tools, R&D transfer to manufacturing package, etc.) that were laser-focused on the business and fit exactly into the process. If we would have gone straight to finding a software tool, this never would have happened. By mapping the process and looking at the key requirements all along the process, we found gaps in our tools and didn’t move forward until we had developed the right tools and when to use them. Once we had the process framework put together, we built an in-house prototype software tool. Then we trained all of the users on the process. The strategy here was to use the process for at least a year to find out what works and what needed “tweaking.” The original team was focused on getting the process 70-80% correct, knowing that after some user experience, the process would need to be optimized. During the beta testing, some very useful feedback led to very practical and specific improvements. The take action, revise later strategy was useful in getting the process developed and implemented, and then using the process to find out were improvements were needed. Only then did the team think about implementing a software solution.
How does your company approach these types of situations?
Remember, optimize before you automate and you will be much better off in the long run.
Leave a Reply