All Posts in Outsourcing

|In: Career Management|Last Updated:

A popular outsourcing rationalization has it that companies should “keep the core and outsource the rest.”

I call it rationalization rather than rationale because:

  • It solves nothing: Outsource something you don’t know how to manage and you still don’t know how to manage it, only now, you’re badly managing a company that wants as much of your money as it can get.
  • It suffers from recursion failure.

KJR has already covered the first two points—click on the links or buy yourself a copy of Outsourcing Debunked (Bob Lewis, 2011). But what’s recursion failure? Glad you asked.

Outsourcing is like anything else in business—to succeed, you have to be good at it.

But as anything that isn’t core must be outsourced, and as the notion that managing outsourcers might be a core competency is absurd, the only logical conclusion is that companies that outsource must outsource outsourcing management to an outsourcing management outsourcer.

To succeed at that, the company must be good at outsourcing outsourcing management. And so on, ad infinitum—recursion at its finest.

Okay, I wouldn’t want to try that logic on a business executive weighing the pros and cons of outsourcing, but it was fun, wasn’t it?

What isn’t fun: Why an increasing number of American business managers are receptive to the even-more absurd arguments in favor of IT outsourcing, both the traditional kind and its current commodity end-point, cloud computing.

Look, even those unenlightened IT shops that thought they had internal customers usually involved themselves in the business processes and practices they were helping improve through automation to some extent. Few business analysts strictly limited their conversations to “what do you want the software to do?”

IT outsourcers, in contrast, deliver software that fulfills requirements and meets specifications. If they do that, all is good with the world, whether or not the software does anything useful.

Deep down inside, every business executive who ever endorsed an IT outsource understood this difference, and yet it didn’t matter. They considered overseeing IT to be an aggravation, and so they willingly “kept the core and outsourced the rest.”

Now we have the cloud, and software as a service (SaaS). The “new” question is, “Why should we spend lots of time with IT on a CRM implementation when we can call Salesforce and be up and running the next day?”

What’s sad is that they know the answer to this seemingly rhetorical question: If they do this they’ll be up and running with what we used to call, in more enlightened times, an island of automation.

Multiple islands, really — as many as they have sales representatives configuring Salesforce as they prefer. Add to that a database that’s completely unusable for reporting and analytics, as each sales rep stashes the data they want in whatever data fields appear convenient for that purpose.

Heck, IT could do that in a day, too, if it was amateurish enough to be satisfied with an implementation that banal. It could buy Act! licenses for a fraction of what SalesForce would cost, too, installing the software on individual sales rep laptops with no attempt to integrate them.

Nothing to it.

We in IT have failed in at least three respects, and we’d better fix all three soon, or we won’t be around to say “I told you so.”

The first is that we thought business executives long-ago absorbed the islands-of-automation argument, so we stopped making it. They had absorbed it, but ideas have a half-life, and because we stopped repeating it, this idea long ago lost its potency.

The second is that we argue rather than discuss. Faced with a sales executive who is thinking about Salesforce, too many CIOs say, “You can’t do that. Here’s why …” instead of, “We can do that … in at least three different ways, depending on what you want to accomplish and how much you’re willing to invest to get it.”

Then there’s the third — failing to focus everyone in IT, from the CIO on down to every help desk analyst—on the importance of managing relationships throughout the company. Without this, nobody will give the CIO or anyone else the time to have these discussions, or the patience to listen to the to-them complex engineering issues we need them to engage in.

So of course they outsource, and go to the cloud without involving us.

We’ve given them no reason not to.

Comments

|In: Industry Commentary|Last Updated:

Oh, what the heck. Best Buy isn’t going to bring me in as a consultant anyway — not after last week’s column about the retention bribes it paid to execs whose names are all over its steady decline.

So now, a few words on why its headlined 2004 IT outsource to Accenture (followed by its covert 2011 re-insource from Accenture) should have failed. Not, I have to add, why it failed. Best Buy hasn’t even formally admitted that the outsource was a bad idea, let alone explained in non-ManagementSpeak terms what led it to reconstruct its internal IT organization.

But a key reason it should have failed, and in fact why Best Buy should never have considered it in the first place, was right there in the press release:

Accenture advocates taking “packaged vanilla solutions and weaving them together in as simple a fashion as possible” and changing business processes, rather than heavily customizing software, as the most cost-effective approach for retailers, [Angela] Selden [Best Buy’s spokesperson] said.

Selden said she recognizes that the approach would represent a dramatic change for the legions of retailers that claim they had to heavily customize systems because of the unique needs of their businesses. But she said they must change the way they do business in order to be nimble enough to “absorb innovation quickly.”

What’s wrong with this picture?

Had Accenture’s pitch been that it had the expertise to help Best Buy leverage its bricks-and-mortar retail strength so as to beat Amazon.com at its own game, there might have been some sense in this arrangement. But that wasn’t the supposed logic. Understanding how flawed that was could help your company avoid a number of common mistakes. Here goes:

In 2004, Best Buy was at the top of the consumer-electronics heap, growing while its largest retail competitor, Circuit City, was in a state of steady decline.

Let’s pretend, just for a moment, that its success wasn’t entirely accidental. If that was the case … if Best Buy’s success was due to actual business competence … then its business processes were a source of competitive advantage, even if they did need heavily customized software to support them.

Which means Accenture’s sales pitch, rephrased for honesty, went something like this: “In exchange for hefty fees, we’ll rip out your sources of competitive advantage and replace them with generic alternatives.”

Accenture, that is, claimed it had more expertise in Best Buy’s business than Best Buy had … a sales pitch that might have made sense had Accenture pitched it to Circuit City. But to Best Buy? Seriously?

Even if Accenture did know more about retailing than Best Buy, its assertion that changing business processes is more cost-effective than customizing software strongly suggests that Accenture knew nothing about what it takes to change a business process. Changing a business process takes more than drawing the new one on a swim-lane diagram and teaching it to the employees who will have to live with the new way of doing business.

Because when the trainers have all finished, those employees will have to become practiced at the new process. That takes time, during which the whole company is less effective than it used to be.

But wait! It’s even worse than that! You see, the effort needed to customize software is a one-time investment. The inefficiencies that are the inevitable consequence of tailoring business processes to deal with the software’s limitations are costs the business has to absorb every day.

Which is why the whole plain-vanilla vs customized-software argument is the wrong conversation to have.

Best Buy fell for it. It’s no longer competitive. Draw your own conclusion about cause and effect, but please, don’t allow anyone in your company to debate the merits of plain-vanilla vs customization, because no matter which side wins the debate, the company will only follow the optimal course of action by accident.

Understand, I’m a theory-of-constraints guy. ToC says that for every business function, right after ranking the six dimensions of optimization (fixed costs, incremental costs, cycle time, throughput, quality, and excellence) in order of importance, the next step is identifying the most serious barrier to improving the top-ranked dimension, doing what’s necessary to remove it or reduce it until it’s no longer the most serious barrier. If that means customizing the supporting software, so be it.

Repeat ad infinitum.

It’s straightforward. It works.

Even better, you won’t need to renegotiate terms after the thrill of an outsourcing deal is gone.

Comments