All Posts in Process Management and Improvement

|In: Industry Commentary|Last Updated:

Here’s an adjective/noun/object combination I never expected to type: I just read an excellent analysis by McKinsey.

Usually, when I read something by McKinsey my reaction is how useful it would have been five years ago. Not this time.

The article in question is: “Raising your Digital Quotient,” by Tanguy Catlin, Jay Scanlan, and Paul Willmott.

While you should read the original, as a public service here are some key takeaways:

  • Not every company can transform global marketplaces: Thank you! It’s easy to spot a business that’s succeeded in spectacular fashion, generalize from its success, and then recommend everyone else do the same thing. Temptation and good logic, though, rarely coexist.

The magic buzz-phrase I most often read about “digital” (and when did “digital” become a noun?) is that it “enables new business models.” Strikingly absent from most of these sources are examples of truly new business models. Even the oft-mentioned Uber is little more than a broker … a business model best described as ancient.

McKinsey’s advice for most companies is to figure out how digital stuff make them better at the business models they currently rely on.

  • Customers: McKinsey points out, and KJR completely endorses the notion that one of the most important aspects of digital disruption is how digital stuff affects or transforms how customers research and decide on products and services. Digital strategy should be built around determining how a company can best integrate itself into this new pattern.

Simple example: The big deal about Uber is supposed to be how easily you can book a ride by clicking on a mobile app. In the Minneapolis/St. Paul metro area I easily book taxis with an app called iHail … and I get a ride from a fully insured driver who has a chauffeur’s license. Had the U.S. taxi industry figured this out instead of relying on lawsuits and lobbying, I wonder if Uber would have made the inroads it did.

  • Culture overcomes: Without taking anything away from the importance of the digital technologies themselves, a “strong and adaptive culture” can overcome a lot of lacks.

The more I consult, the more convinced I am that no matter what the business change, culture is the lead story, not one factor among many in reducing an organization’s resistance to change.

  • Integrating the unintegratable: Not really unintegratable, but almost always unintegrated, are data about customers from internal systems and data about customers from the social web. Put them together — demographic and purchase history from your internal systems, combined with search patterns, consumption data, and psychographic tells from customers’ on-line behavior — and you can predict what customers are likely to want to buy far better than with either in isolation.
  • Process automation: McKinsey is more diplomatic about this than what follows:

Once upon a time, before the reign of “internal customers” put a halt to IT’s habit of provided technology leadership, conversations about the role of computers was how to automate business processes.

Whether or not there’s truly a causal relationship between the two events, at roughly the same time internal customers became IT’s reason for being, process optimization disciplines like Lean and Six Sigma supplanted the assumption of full automation.

It’s time for the past to become the future. For true processes (regular readers will recall KJR’s ongoing crusade to distinguish between processes and practices), everyone involved should assume full automation is possible, and design the process accordingly. As part of the design, kick out exceptions for human intervention when needed.

But assume you can fully automate at least the 20 percent of the cases that account for 80 percent of the work. This will inevitably reduce cycle times by orders of magnitude, reduce error rates to trivial fractions of their former selves, and cut incremental costs to the bone.

What McKinsey also doesn’t say: Do not, under any circumstances, let savings fall to the bottom line. Either use them to reinvest in your business, or to reduce product pricing. Like that annoying song about poker, it isn’t time to count your money yet — you’re still playing the game.

  • Agility applies to more than just Agile: Apply incremental “test-and-learn” (to use McKinsey’s phrase) everywhere. Or if you, like me, prefer OODA theory, increase the speed and reduce the scope of your loops. There comes a point when evidence trumps analysis. So emulate direct marketers — stop theorizing and test, test, test. It’s cheaper, and it works better besides.

There’s much more to the McKinsey paper than this. Take the time to read the whole thing.

Even though it lacks the inordinately valuable commentary I’ve added in the above summary.

Comments

|In: Architecture|Last Updated:

Don’t apply traditional IT portfolio governance to shadow IT.

Why? Start with two iron-clad rules of IT portfolio governance:

  • No business sponsor, no project. With shadow IT, sponsorship is automatic. If nobody in the business cares at sponsorship levels the project wouldn’t be happening. A formal governance check is superfluous.
  • The only legitimate outcomes are “no” and “when.” There’s no maybe, and no priority scoring. With formal IT, approved projects are those added to the master schedule, to start when the necessary staff are available to work on them.

With shadow IT, the whole point is that the business area undertaking the project isn’t willing to wait.

The entire reason businesses need so-called IT governance … really, business change governance … is because of scarcity. In most companies there just aren’t enough IT developers to satisfy the business appetite for change and improvement.

Scarcity isn’t part of the shadow IT equation. Rather than trying to get their slice of the IT developer pie, with shadow IT, business units own the whole pie.

Does this mean shadow IT should be governance-free?

Yes … but no.

“Governance” almost always means “a committee must review this.”

That’s the no. Just as we have to restrain our natural impulse to strangle idiots, so, in business, we should restrain the impulse to form committees.

The yes comes from what we might call the John B. Finch principle: “Your right to swing your arm leaves off where my right not to have my nose struck begins.” (Oliver Wendell Holmes usually gets the credit.)

Shadow IT projects (really, shadow business-change projects) have three noses in range:

Re-keying: Shadow IT tends to deliver “islands of automation,” unintegrated with the rest of the company’s applications and information portfolios. That often results in the need to re-key data from other systems into the shadow-IT system, and to re-key data from it back into the company’s systems of record.

The former isn’t a problem. If the department head decides re-keying into the system is just fine, it is, by definition, just fine.

But the latter? If the re-keying must be performed by employees who report elsewhere, the project might violate the Finch Principle. It doesn’t if they’re keying the data now and this just changes the source. But if one manager is shoveling new work into a different department’s inbox, it’s a Finch Principle violation.

Fortunately, there’s a committee-free solution readily available. All the manager whose nose has been put out of joint has to do is document the offense and its budget impact. The result: The Finch Principle violator has to bear the expense. The company budgeting process obviates the need for separate governance.

Data exposure: Imagine the point of a shadow-IT system is to facilitate working with an external partner. Now imagine it inadvertently exposes sensitive data beyond the walls of the corporation. It’s a clear Finch Principle violation.

Happily, there’s a committee-free solution to this too. It’s a policy, probably an existing policy: InfoSec reviews all systems that are used by or expose data to outsiders.

Data governance: A popular approach to IT integration is the “federated architecture” — an environment that looks like a unified whole even though under the covers it’s been assembled from a variety of COTS and SaaS solutions.

A major challenge for federated architectures is reconciling data definitions so that data entered into one system can flow into the corresponding fields in other systems without mishap. As those in the trenches know while those who rely on PowerPoint do not, semantic mismatch, not field-level synchronization, is the big challenge to systems integration.

Shadow IT systems will often ignore the usual controls for this because it’s an eye-glazingly boring problem. Unless, that is, you’re either responsible for the integrity of the IT architecture, or genetically predisposed to lexicography.

Even if integration happens through re-keying, semantic mismatches can pollute data in the company’s systems of record.

The solution, to the extent there is one, doesn’t require a committee, although regrettably, many companies rely on committees to handle data governance.

Companies that want consistent data create and maintain some sort of glossary (data dictionary or encyclopedia) for that purpose. Everyone who uses data relies on it.

Which in turn probably means you’ll need to create some form of “Glossary Police” to make sure even shadow IT projects adhere to its definitions. But please … don’t make the Glossary Police a committee.

You’re better than that.

Comments