Think Before You Automate…

The Concept:

Did you hear about that great new CRM/billing/inventory/ forecasting/fulfillment/ ordering/ whatever application? It’s going to save our business! I hear it uses bilateral n-dimensional hypercube technology in a virtual “on-demand” nano-warehouse environment to figure out everything you need BEFORE you even realize it! It synergizes, empowers, works out-of-box, seamlessly integrates (with no downtime), never goes down, pays for itself, and requires no training. The sales person told us it can be installed yesterday, costs virtually nothing, includes “platinum-level support,” is always installed on-time and under-budget, has nothing but thrilled users, and OF COURSE IT WILL INTEGRATE WITH YOUR PARTICULAR PROCESSES! Wheeeee!

Oh, if only this were just a bad version of a George Carlin routine. Unfortunately, it seems to be the path more and more companies are taking these days to solve their performance woes. To be clear, we are big proponents of using technology solutions to solve performance issues – but with one caveat. It MUST be done wisely.

The lure of the magic bullet application that solves all issues with no drawbacks is certainly enticing (my endless stream of smartphones can attest to that…) However, such a solution simply does not exist. It is our experience that the vast majority of “pick-a-system-and-just-deploy-it” type solutions result in partially deployed applications, solutions that fail to address key aspects of the problems to be solved, implementation costs that are 30-50% higher than expected, and deployment timeframes that are at least 25% greater than expected.

Whatever technology you choose must be the result of thoroughly and intimately understanding both the current problems being experienced and the desired “future state” you wish to achieve. Deploying a technology solution without understanding these two things is like a kid building a model aircraft carrier without any instructions. It might work out in the end, but at some point someone is going to notice that you used 27 tubes of glue, forgot the rudder, and it won’t float.

Why do companies routinely jump to the deployment of systems and application without thorough process planning? We believe the primary reasons to be the following:

1. A belief that technology alone is the solution:

As a society, we have been led to believe that technology can solve anything. By itself. This is almost never the case - miracle drugs work best with modified lifestyle, hybrid cars work best with a change in driving habits, and a technology solution to a business problem works best when preceded by a change in process strategy.

2. A demand that something gets deployed NOW:

Selecting/buying/building “feels” more like taking a proactive step to solving the problem to some people than does identifying current problems and planning out a future path. It is natural to want to give in to the desire to buy or build immediately, but action without direction can lead to disastrous consequences.

3. A lack of understanding of the intertwined nature of the problem:

Rarely do we find that a process stands alone with no interaction with other processes inside or outside the business. Process and their associated problems are always deeply intertwined with other process and cannot be changed without significant implications. As discussed previously ( EIR 1, Understanding the Organization as a System ), significant change to one process in a system can have serious impacts elsewhere in the system. You can’t change billing processes without impacting ordering processes. Lack of understanding of the intricacies involved in the company’s business processes leads many decision-makers into the trap of deploying without adequate process planning.

Applications for the Executive:

How do you combat the siren call to deploy the latest and greatest technology right this minute? We recommend the following three strategies:

  1. Understand the Current Problem

The first step to developing a successful technology solution is to understand the problems that are causing you to seek a solution in the first place. Is it an inability to handle certain types of transactions? Lengthy cycle times? High levels of fallout or errors? We recommend that organizations develop a model of the current state of the process – including all the manual and automated steps that will be supplanted by the proposed automation. Additionally, we recommend that companies capture a list of the “disconnects” or process issues that are causing a need for change. With a process map and a list of problems in hand, it is less likely that the systems solution chosen will recreate the ugliness of the past.

  1. Use the Future Flowchart to Build Requirements

The second step prior to choosing new technology is to develop a flowchart of the future state that you wish to achieve. By developing a detailed flowchart of the “future mode of operation” (FMO), you will accomplish two things.

First, you will have a document that helps you know what to buy or build. The flowchart can very easily be translated into detailed business requirements that can be used to assist in the technology selection.

Second, the FMO gives you a checklist to help select a vendor, should you choose that route. Most software vendors count on the fact that you have a very fuzzy picture of what you actually need the software to do. If you don’t fully understand your specific needs, they will spend lots of time discussing all the wonderful features of their product instead of spending time demonstrating how the product meets (or doesn’t meet) your specific requirements. Build the FMO and insist that candidate software vendors review the flowchart and color-code each box on the chart - green (the software can perform that step right off the shelf), yellow (the software can perform the step, but only with customization), or red (the software cannot perform the process step). It is a surefire way of finding out how closely the technology matches your vision and how much custom (read: expensive) development work will be required. Plus, software sales people really love going through a huge flowchart and having to explain that their application only performs 20% of the steps right out of the box…

  1. Deploy in Logical, Process-based Phases

Here’s how most process automation deployments happen: IT and/or the vendor develops a plan in which all functionality for a product line gets automated, then the next product line, and the next, and so on. They tell you that this way, they get to work out any issues or bugs and then each successive product roll-out goes much more smoothly. All true. What they DON’T mention is that this causes major process problems for the employees. Instead of just the old “bad” process/system, the employee now has to deal with the old process PLUS the new process – but just for certain products. It can end up as a nightmare scenario for quality and customer satisfaction.

Instead, try to deploy entire “clusters” of functionality at the same time. Your deployment looks like this: the “pricing tool” is developed and deployed for all products and the old tool/process is decommissioned, then the “billing tool” is developed/deployed for all products and the old tool is decommissioned, etc. An added benefit of this type of deployment is that even if the automation project gets derailed half-way through, you still will have sections of the process that have benefited from the work deployed to date.

Let’s face it – the promise of slick, new technology that will automate all of our processes while driving down costs and increasing productivity is very enticing. But, like most anything, a little caution is advisable. In whatever technology you choose, proceed first with process design to determine the optimal future state for your particular situation. Once that is complete, start examining technology solutions, but make absolutely sure that the process drives the technology choice. Don’t be forced in to a sub-par business process as a result of the system you chose.

 

 

About the Author:

Kevin Smith is a co-founder and managing partner at NextWave Performance LLC.

©2007 NextWave Performance LLC

Comment