Workflow in the CRM world quite often involves a consultant (in cahoots with a willing client) automating everything; simply because they can. I’ve been there myself (kicking and screaming); I once developed a really cool approval routing system that was end-user configurable. Unfortunately, as in my example, what was really happening was something Bill Gates warned us about:
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency”
And
“The second is that automation applied to an inefficient operation will magnify the inefficiency”
This is actually pretty simplistic in that there is no discussion of value or whether making something faster actually aligns with your organization’s competitive differentiators; but it’s still something worth remembering. To make things even simpler, we can also use this old adage…
OO + NT = EOO
(Old Organization plus New Technology equals Expensive Old Organization)
Any organization ready to take on a workflow project needs to take a few things into consideration first:
- What are the true end-to-end business processes and can you see them?
- Which actors play a role in the process(es) today?
- What are the discrete results of each process; who are the customers (internal and external) and what job does it help them get done?
- What are your competitive differentiators in the market?
- What are the drivers & enablers for value creation?
Until you know these things, it’s impossible to know what to fix, or whether the process itself creates a result that customers give a hoot about. In many cases, you don’t need to dig down into the nitty-gritty details of service procedures and tasks. Simply identifying what the true process is, and looking at how a work item is handed off between actors over time will show you all you need to know. Even without getting into group sessions one can get a good sense of the waste occurring in an organization through an initial discovery process.
Putting together a basic swimlane diagram of hand-off level events (not details) can sometimes quickly show you that a problem is hiding in plain site. Excessive back and forth of work items between actors can create various types of waste. While context is important here (perhaps there are regulatory issues), generally one can quickly see where more probing might be necessary by simply looking for the “W”. This “W” essentially depicts areas of potential waste and examples might include:
- Sales rep calling the office to retrieve phone number, or address because it takes too long to boot up their laptop while driving 85 mph in the wrong direction
- A paper or spreadsheet-based tracking system which requires a work item to pass back to an actor after each stage or work is completed, so the log can be updated.
- Excessive auditing of transactions: e.g. all quotes or sales orders must be processed by office staff
I’m sure you can come up with a lot more examples; waste is a very prevalent problem in most organizations and outside of Lean operations seldom is there a process designed to eliminate it incrementally over time.
If you’re looking for waste in your organization, here is a list of 7 types of waste that you can look for:
- Overproduction – more, or sooner than is needed by the customer of the process. In the front office, this could actually mean selling more than can be fulfilled
- Inventory – Any form of batch processing or work in process. This could mean partially completed tasks or documents or items prepared in advance of an anticipated future need.
- Waiting – Delays in getting information or some other result. Most often I will see excessive approval processes or team members that have information or resources required, but are not available when they are needed.
- Extra Processing – Time spent doing unnecessary steps. I see the re-keying or re-formatting of data quite often, creating unused/unnecessary reports, etc.
- Correction – Any kind of defect or rework required. In the front office is this is most often related to stored data about customers or transactions
- Excess Motion – Movement of people. Retrieving anything essential that is out of reach. Data, information that is physically stored in a centralized location or in a system that is inaccessible in your current context (such as on the road)
- Transportation – Movement of work between locations, offices, floors, buildings, systems and people. We see this in email today, in the context of handoffs or approvals
A closing note about automating work; don’t speed things up that your customer doesn’t expect to be speeded up. For instance, if you are Jesse James, building killer custom motorcycles, your customer is willing to wait; speeding this process up would inevitably lead to defects, and waste, that they are not willing to tolerate (i.e. Correction). However, that same customer might value regular updates regarding the status of the job (including production stage pictures so they can see the progress). This is a something that automation can certainly help with.
Also, automating steps that do not add value are simply making a worthless step happen faster. This will lead to the slippery slope of believing that you can now introduce more of these steps or processes. An example would be the approval system I developed that supported a management directive that everything needed to be pre-approved and re-approved by a hierarchy of approvers (from travel to entering a new Opportunity into their CRM system). The actors in this process were actually excited about this system because when looking at the problem through the lens of the current implementation; faster looked better; even if it added no value.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
Mike, I’ve always like that formula: OO + NT = EOO.
However, isn’t it true that sometimes new tech is simply cheaper? For example, a company could swap out an old/expensive installed Siebel or SAP CRM system for a newer cloud-based CRM and save some money without any real changes to the underlying processes.
Likewise, a people-intensive manual process could be automated but unchanged. The savings in people could more than offset the tech costs.
I don’t think tech always makes an “old” organization more expensive. But, the larger point is simply automating a bad process is no recipe for long-term success, even if there are some cost savings up front.
One of the problems with automating manual processes “as-is” is not taking into consideration that those old paper systems tended to be very sequential. Automation introduces more capability to perform transformative work in parallel and/or collaboratively (although not necessarily needed for the latter).
As far as swapping out technology on a cost savings basis only, why not take the extra step of finding something that can enable more competitive capabilities? Our vendors have not package that and there is still plenty of research out there to back up their lack of value-add to the equation.
Yes, that is what companies should do.
My point was simply that technology doesn’t necessarily make an organization more “expensive.”
I suspect a lot of software has been sold on the basis of doing the same thing, cheaper. Because reworking processes, while a big payoff in the long term, looks too much like Work in the short term.
And that’s another “W” to keep in mind!
Good point.
Hi Bob
Unfortunately, your analysis is incomplete.
Replacing old technology with new technology automatically makes an old organisation more expensive. The reason why is that even a like-for-like technology swap requires many additional activities to be carried out before you can start to use the new technology. Software needs to be customised. Data needs to be transferred. Interfaces need to be rebuilt. The software needs to be tested. Staff need to be trained. Projects need to be managed. Etc, etc, etc. SAP’s minimalist Rapid Deployment Solution lists 14 different activities that need to be carried out for even the simplest of implementations. And a 90 day minimum period required to make them. And that is all before the new technology has been used even once. That all sounds very expensive to me.
OO + NT Really Does = EOO
Graham Hill
@grahamhill
Graham, in the main I think you’re probably right.
But like all generalizations, this one surely has exceptions. If the cost of implementing the technology (including everything you mentioned) is offset by the benefits then then the automation won’t make the organization more expensive.
The costs will be realized earlier than benefits, of course. That’s true of every investment.
Hi Bob
The OO + NT = EOO formulation was originally created by my colleagues at PwC’s Change Practice in the 1980s. It was created to illustrate that just buying and implementing technology without pulling other levers in transformational change projects was a recipe for failure. The high early failure rates of technology-driven change projects like ERP, BPR, CRM and now CEM, all illustrate the general principle.
Implementing technology rarely, if ever produces business benefits without pulling other levers too. And certainly not in transformational change projects. Data gathered directing transformational change programmes in major corporations over the past 25 years suggests that technology is tyically responsible for approx. 15% of the available benefits from a transformational change programe. Planning is worth 20%, processes 20%, mesurement 20% and people 25%. The more levers are pulled in a coherent, integrated way the higher the business benefits that a transformational change programme can generate.
Unfortunately, just implementing technology by itself won’t even produce the 15% of benefits available from technology. Transformation change project returns follow an approximate (field) hockey stick shaped curve. Piece-meal implementation, e.g. of just technology, creates a lot of costs but doesn’t pull enough of the other levers for enough people to generate any net benefits. It is only when more of the levers are pulled and more people are affected (research suggests approx. 40-50% of people) that the benefits start to outwight the costs and the net benefits start to climb the handle of the hockey stick.
There is enough research into project failure reasons, complementary capabilities and phase changes in transformation projects to validate all three points. And all of them point to the inexorable fact that…
OO + NT Really Does = EOO.
You know it makes sense.
Graham Hill
@grahamhill
Graham, I intuitively agree with you. I think CRM tech is a great example — layering tech on top of old processes doesn’t help much.
However, what is your basis for saying “implementing technology rarely, if ever produces business benefits without pulling other levers too.”
Have you seen any formal studies of IT implementation that found this to be true?
Hi Bob
Proving something to be true or false is a complicated philosophical endeavour.
There have been a number of independant academic studies, e.g. by Day at Wharton and Reinartz at Insead, that showed that the choice of CRM vendor, and also the choice of CRM software, were not predictors of success in CRM project, providing a minimum level of enablement was provided. Although these studies looked at approx, 2,000 CRM projects they were based on reports from project managers rather than carefully-controlled trial experimemts. That makes them inductively true, but not deductively so.
If you use Popper’s falsifiability principle as a guideline, it would only take one CRM project that implemented CRM software without doing anything else at all and still produced CRM project benefits, to refute Day and Reinartz’s claims. In my 25 years of consulting, interim and service operations management I have not seen nor heard of a single instance of this being the case.
I conclude that epistemologically speaking, the proposition that ‘implementing technology rarely, if ever produces business benefits without pulling other levers too’ to be inductively true.
Unless of course you know different.
Graham Hill
@grahamhill
Thanks, your logic makes sense. However, I still think a lot of software has been sold, and bought, on the illusion that software will deliver benefits without changing anything… except the software!
Bob,
There is this illusion that because the CRM industry (for example) is growing, that it must be doing something right. Companies continue to purchase CRM software; however not necessarily from the same vendors. Take a look at how Seibel and Salesforce have switched positions of dominance in the past 8 years. Companies are still trying to figure something out, and they are not necessarily succeeding – they are just switching a lot.
I spent a number of years as a bank examiner (internal and external) and have reviewed hundreds (if not thousands) of business plans, forecasts and the results. It was clear to me then, and even clearer to me now, that executives assure us that they will generate sustained and profitable growth. Unfortunately, 95% of them are dead wrong in their predictions. There is definitely research to back this up. http://hbr.org/2008/03/when-growth-stalls/ar/1
The result of that research suggests that the differentiators are leaders who make the correct strategic choices, repeatedly, and build the requisite capabilities to support the initiatives. The technology simply supports and amplifies these efforts.
I’ve heard the argument many times that sales force automation will make us more efficient, allowing the sales reps to spend more time with customers. Unfortunately, there is no evidence that this has had a long term effect (which is what we are looking for, right?) on the growth and profitability of the vast majority of businesses.
Hi Bob
I agree 100% with your assertion.
A lot of software has been sold on the false promise of instant business results after implementing it. Only a fool would buy such a proposition. There are obviously lots of fools out there. Even today I frequently come across vendors and corporate buyers who take part in some sort of purchasing dance around their mighty technology totem poles. Vendors prostrate thenselves before buyers and utter strange incantations about the latest cloud services, users adoption and ROI. Buyers writhe in ecstacy and salivate at the prospect of their pending promotion on the back of the new technology. Copious food is eaten, wine drunk and tall tales told until early in the morning when the sale is consumated. Both usually wake with a bad hangover the night after consumating the sale when they realise it wasn’t just a dream. And that hope is not a viable strategy. Caveat emptor!
Graham Hill
@grahamhill