Last year I bought a new house. This was at least my fourth mortgage process with the same lender, a major national commercial and retail bank, but the process was different this time.<\/p>\n
In the past, I’d been asked for a pile of information, which I either faxed or handed over to a mortgage officer. This time, I was given a login to a website where I found a massive list of information I was asked to upload to the site.<\/p>\n
If I had a question, I still had to submit something along with my question, no matter how pointless – and it was sometimes several days before I got a response.<\/strong> Some of the questions were repetitive, and I found it impossible to clarify certain sticking points. I found myself missing the fax machine.<\/p>\n I imagine from the bank’s perspective this was all just fine. It was an efficient workflow process that eliminated the need for expensive, experienced mortgage officers. Their smaller and more specialized mortgage staff could handle a larger load of mortgages in this re-engineered business process<\/a>. But it was a terrible experience for the customer.<\/p>\n Business process redesign has passed from the Michael Hammer craze of the 1990s into standard practice. Few in business question the need to look at process efficiencies when implementing a new system, business function or service.<\/strong><\/p>\n A few of the classic principles from 1993’s “Re-engineering the Corporation” by Michael Hammer and James A. Champy:<\/p>\n I love<\/i> these principles.<\/strong> They are an engineer’s dream. They are about efficiency and rationality, and as a recent TV ad coined, perfect for “efficiency enthusiasts.” That’s me.<\/p>\n However, those are the engineering principles, the key instructions given to the team reviewing the process.<\/p>\n As process re-engineering – or business process improvement<\/a> – became standard, it also had to take on pragmatic business principles\u00a0that defined what it would take to get acceptance for the new process.<\/strong><\/p>\n Those less formally stated principles included:<\/p>\n These points are management principles and are really more about money than efficiency. At first glance, though, this doesn’t matter. Hammer’s efficiencies would seem to translate directly to reduced costs and cycle times.<\/strong><\/p>\n As for the happy path (i.e., not designing to exceptions), this is pure pragmatism in getting something delivered. If more than 90 percent of your instances, you will follow a standard path and make sure that’s as efficient as heck.<\/p>\n There remains a gap between these two principles, however. It so happens that the customer lives there.<\/p>\n First of all, a lot of Hammer’s focus was on behind-the-scenes processes where there was no external customer to worry about. Internal customers, it was presumed, could be encouraged to support the new and efficient processes.<\/p>\nWhat’s Wrong with Today’s Process Design?<\/h2>\n
\n
\n
Redesigning Processes with Customers in Mind<\/h2>\n