"There Is An App For That" Mentality Is Hurting Your Workflow

As I have worked with various project teams across a spectrum of industries and countries, I have noticed we are too fast to jump on the "There is an app for that" bandwagon. Whether implementing a new ERP system, looking to remove complexity or bottlenecks in a production line or improving a customer service process, the majority of situations quickly lead to an interruption and someone excitingly suggesting that there is an app that can take over and solve our problem. The hook is set and now other members are quick to one-up the other with a better app suggestion, to which the parties stop all listening and bury their heads into their laptops or tablets to reinforce why they are right. Some even rush to take over the presentation with an open hand across the table employing the Jedi "Mind if I connect for a second?" The disruption continues as everyone cuts the meeting short, thinking it was a success and each take on the task of scheduling a demo for each app. And so a month goes by and not only has no progress been made, but now you have a team of deflated individuals who are not as eager to continue.

I have been in the industrial automation sector for over 20 years and have worked with many large to small companies looking to upgrade their processes or even make their first leap into robotic production. When I see the execution failures, setbacks, and delays, it has been poor front-loading of the project to properly understand the real pain(s), the dependencies, and the current state vs. desired state workflows.

Aside from a Project Charter with an emphasis on 'In-Scope' and likely more importantly, 'Out-Of-Scope', the team should first take the humble approach to ask if they even know what the current process or workflow has evolved into today? It is most common that it is poorly documented if at all, and while many claim to have a policy, procedure, or process for the activity, it ends up being cardinal knowledge. The challenge then is to test if all stakeholders perceive the process the same and do they even use the same lingo? Where are corners cut, and why? Where are the decision points? Where is the bottleneck or constraints? The emphasis on humility is that leadership, and the team must create an environment that fosters an open-minded debate and a learner mentality. All parties have to avoid absolutes regarding opinions or taking things personally. It should be a fun, rewarding, and enlightening experience that provides transferable skills.

The first step is to designate an area with no interruptions, a diverse team, lots of whiteboard space, and a multitude of coloured Post-It Notes. CAUTION: Don't complicate things by letting someone derail the process; promote an app that can do the same. K.I.S.S. applies at this stage and helps all parties stand up and engage. Don't overthink what is required or that a level of expertise is required. Start where the team feels most comfortable. An example could be to map out the perceived process. Once agreed upon, challenge the flow. Then I like to introduce the paper flow. What paper is created and moved through the process from Input to Output? Actual samples should be included on the wall in the specific space.

Another step I like to include is a dummy-downed version of Value Stream Mapping. It is kept simple so that the exercise is not intimidating or the process goes deep down specific rabbit holes that provide diminishing returns for the task at hand. In this step, we want to code the steps and/or paperwork and/or decisions into one of three categories:

1. Value Added - There is a perceived value that benefits the customer.
2. Non-Value Added - There is no perceived value .... to the customer or company
3. Non-Value Added BUT NECESSARY - There will be steps that cant be avoided due to certain current constraints, etc. They might offer areas for improvement in a Future-State.

Now that the team has completed the above half or full-day exercise, they should celebrate the achievement and close the books until the next day or two ... but not too many days, before reassembling for the final stage. The recharge time will have allowed members to digest the learnings (I know, not a word). The first quarter of the allotted time should be prepared to challenge and rehash the prior work. Then the team is ready to postulate areas for improvement. Ideally, this can be done on an opposing wall. The exercise will establish a new and improved future state.

After completing the above, teams remain quick to now jump to an automated solution. After all, they can now be very specific about how the platform should flow for them, and they are keenly aware of this requirement from all the prior demos. The solution companies concluded the demos with a request of the current process for them to automate the same thing that has flaws already. When the team gained intelligence and asked questions, the demo companies were happy to provide pricing (usually substantially more costly and run by a different division) to improve the current workflow before automation. So, I suggest taking one more deep breath and spending a month or a few implementing the proposed changes. Doing so will help work out the kinks and flaws, highlight new errors or missed dependencies and conclude with a more robust workflow.

Good luck on front-loading your next process improvement project with this simple, yet critical, and agile tool.

Some added insight: Thomas H. Davenport & David Brian published the article “Before Automating Your Company’s Processes, Find Ways to Improve Them “in 2018 in the Harvard Business Review. The article focuses on robotic process automation or RPA. In the article, Andrew Spanyi, is quoted as saying, “RPA does not redesign anything. It doesn’t ask whether we need to do this activity at all. It operates at the task level and not the end-to-end process level.” The article cautions that most businesses jump into implementation without examining the current processes and gaps in performance. This alone will likely achieve faster returns than converting an inefficient process to RPA. “Process mapping, analysis, and redesign work are essential...” for effective implementation.