Filed under: Customer Feedback
Two types of people stand in the way of oncoming trains: the totally insane and software implementers. The primary difference between them is that the first group has an excuse.
The very fact that software implementers have been making the same error leading to the same deadly outcomes over and over again for decades now speaks to something, and I believe I’ve finally figured out what. Software implementers have an overwhelming aversion to defining workflow/information flow and individual work process in sufficient specificity to determine what the software actually should do—so they flat out refuse to go there. And as a result, they don’t know what the software should do before they implement—and they thereby default to attempting to run the application either “as-is,” with limited configuration or with misaligned configuration. Both cases are described by a three-letter acronym: DOA. The software arrives out of alignment with business process, and all hell breaks loose, typically in user acceptance training.
Before trying to identify the source of the aversion, let’s first define “sufficient specificity.” Process definition occurs at two levels. The higher level is workflow that connects employee with employee; function with function; company with customer; and company with supplier. Workflow includes information flow, because the two are joined at the hip everywhere except in manufacturing. The second and lower level is individual work process that describes how individuals do their own work. Individual work process is a dependent variable driven by workflow and should never be reengineered before workflow redesign.
Within the context of a software implementation, workflow redesign has to encompass every movement of work and information involving the new software, including source and destination flows. Further, workflow definitions should n-e-v-e-r represent the “as-is state.” If that happens, you’ll either minimize the value of the new system—or, worse yet, damage your company by doing the wrong stuff faster.
Individual work process design should follow the “to-be” workflow and drill all the way down to the user keystroke level to capture not only the data needs but navigation needs as well. Just don’t make the mistake of dissecting your as-is individual work process, because changing workflow requires reengineering work process – and why spend gads of time dissecting something that’s about to go away.
Okay, so why won’t most companies and individuals responsible for software implementations take these steps before deploying new software that immediately disrupts the business and takes a year or two to straighten out—if it ever can be straightened out? At first blush I can offer a host of reasons: lack of internal process skills; trying to apply Lean or six sigma to develop technology requirements; IT trying to define business process instead of business-side people doing the work; silo management interfering with process redesign; no budget; no one with time to execute process design; and “no time.” Of course, fixing things later takes exponentially more time and expense than doing things right, but I suppose that having new software arrive DOA is one way to get time and budget for process work, although the process design phase has almost surely been fatally compromised by putting technology ahead of process.
These are all contributors, but I suspect not the main driver. Over time, I’ve come to believe that most train wrecks that pass for software implementations stem from one, simple fact—we’ve made redesigning business process too damn hard. And indeed, if you don’t know how to streamline and automate the process of designing process, it becomes ugly quickly.
For example, we’ve just witnessed a company courageously attempt to redesign their enormously complex process for global service delivery before implementing SAP. Why “courageously?” Because without understanding how to streamline and automate the process design process, they did all their work slowly and manually—stretching an initiative they could have accomplished expeditiously in two months into a year’s work, and countless extra resource hours. And they still couldn’t get past identifying individual work processes by name and on to actually engineering them step-by-step, task-by-task—the level that provides the majority of application software requirements.
I had an epiphany over this. Seeing what it took to accomplish process design across this company by brute force hit me like a blinding flash of the obvious. Very few people or companies have the will power and resources to subject themselves to an exercise like this. But since skipping business process design shouldn’t even be on the table as an option, the only rational alternative is to learn how to streamline and automate process design.
Interested in learning how? If so, download a free Visual Workflow white paper from our site. Using the VW framework will save you untold hours and effort—and most importantly, could save your new software implementation.
No Comments so far
Leave a comment
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: