All Posts in Organizational Design

|In: Industry Commentary|Last Updated:

The New Economy must truly be dead.

In the New Economy, I’ve been told by experts, the customer is king. If it were alive, how would you explain Larry Ellison?

Even notorious industry bad boy Computer Associates thinks good customer relations are important, and is promoting a new image as a kinder, gentler software company.

But then there’s Ellison, who, at Oracle AppsWorld, told his customers … his customers! … that they should customize their companies to his software. Customizing the software is wrong. Complementing it with third-party software is wrong. Building applications in-house? Don’t you dare! That would get in the way of your company’s primary mission according to Oracle: Software integration.

The right thing to do? Adapt your business to the predefined processes Oracle has thought up for you, and run your business on nothing but Oracle software, of course.

This attitude would be predictable coming from a communist, but Ellison’s a rich guy. So what is he thinking of? He’s telling us to trust a central planner (Oracle) to anticipate everything we need, and to figure that if he didn’t anticipate it you don’t really need it.

That’s a centrally planned information economy. Memo to Larry Ellison: Centrally planned economies don’t work, and it takes a long time to recover from the failed effort of trying to make them work. If you don’t believe me, take a look at the Russian economy.

Ellison’s mandate is bad for his customers for two entirely different reasons, both related to the fall of world communism.

The first: Ellison ignores the complexity built into every real company — the same complexity that causes all centrally planned economies to fail. Market-based economies don’t out-compete centrally planned ones because they’re more efficient. They’re actually inefficient in some ways, encouraging redundant effort (we call it “competition”). What makes market-based economies superior to centrally planned ones is their ability to recognize and fine-tune the satisfaction of demand.

So while an ERP vendor’s information-economy central planners can recognize and satisfy the big-ticket items like supply chain management and financial reporting, your IS organization is more likely to recognize and satisfy requirements that are closer to home, like (for example) your real estate management department’s need for an investment management system.

Nor does it stop there. Your IS organization also consists of central planners. They’re unlikely to recognize and satisfy (to take another example) your marketing department’s need for a system to schedule use of your company’s trade-show booths. That’s what personal databases, electronic spreadsheets, and Jane, who’s “good with this stuff,” are for.

Unmet need isn’t the only problem, either. There’s also the clothing-size issue: Just because a suit is well-made doesn’t mean it looks good on you. It also has to fit.

Oracle’s process designs are, I’m sure, neither better nor worse than any other carefully plotted swim-lane diagrams (the standard way to graphically describe a process design). It’s just that they almost certainly don’t all line up with your current processes, so taking Ellison’s advice means process re-engineering on a massive scale. The good news is that the process designs themselves are done. The bad news is that the good news only covers about 10% of the total effort of changing every process in your company.

Ellison isn’t completely wrong, of course. Many ERP implementations are unnecessarily complicated because of that’s-how-we-do-things-around-here thinking. It’s quite true that many companies don’t give their ERP vendor’s shrink-wrap processes a fair hearing.

But imagine your meeting with the CEO, COO, and CFO where you explain the benefit of standardizing on nothing but Oracle’s software and processes: “Sure, we’ll have to change how every bit of work in the company is done, but in return we’ll save on the cost of Oracle upgrades! Not only that, but we’ll operate exactly like every one of our competitors. Think of the benefit to our customers — they’ll be able to switch among all of us at virtually no cost!”

Good luck finding your next CIO position.

The whole thing is silly. If every company took Ellison’s advice, then every company would follow identical processes throughout — those envisioned by their ERP vendor, and only those envisioned by their ERP vendor. Taken to its logical conclusion, the result would be that every company in a particular industry would be identical to all others.

Hmmm. Maybe he is a commie after all.

Comments

|In: Career Management|Last Updated:

In the beginning was Electronic Data Processing (EDP). In EDP we wrote computer programs to automate business processes. Ignorant about methodologies, we just talked with the people who were going to use the system, figured out together what it should do, and tweaked things until everyone was satisfied. Eventually these programs turned into legacy systems.

Like baseball managers, most of whom once played the game, the guy who ran EDP was a former programmer who could talk to the company’s business leaders without scaring them. A lot of his conversations started, “Didja know …” as in, “Didja know we could automate that and save you a lot of money?”

Then database management systems happened, and some genius decided our real job was to manage information – a clear case of confusing means and ends. EDP became Information Systems (IS), the person in charge became Chief Information Officer (CIO), and theorists inflicted bulky methodologies on project teams. The result? Long delays before the writing of actual code, and an organizational hierarchy to separate programmers from the people who need their product.

Along the way we gave up on the baseball manager theory of CIO selection. Instead we focused on the need for “business knowledge.” If that wasn’t bad enough, we defined “business knowledge” as “understands how to perform a Return On Investment (ROI) analysis”. We got what we asked for: Late, bloated projects, fictional ROIs, and a management-fad orientation leading to the belief that late projects and fictional ROIs are fine so long as we “satisfy our internal customers”. Mired in these time-wasters, most CIOs missed the Internet. Oops.

So now we have Chief Technology Officers (CTOs).

Sometimes the CTO is the CIO’s peer, with the former focused on the Internet and the latter on everything else. This is worrisome from the organizational design perspective because it has strong potential for dividing accountabilities.

If your company insists on having both titles, minimize conflict by giving the CTO application-layer authority only, but responsibility for all customer-facing applications, not just the Internet. Why? If your CTO owns the Internet, your Telecommunications Manager (presumably re-titled to “CVO” for “Chief Voice Officer”) will own your interactive voice response and call centers, another bizarre title will own sales force automation, and the chance customers have of getting consistent service across all channels is exactly zip.

In most companies, though, CTO is the new title for “the person we hold accountable for all of our computer stuff”, accompanying a name shift from IS to IT. “CTO” implies rejection of a lot of the intellectual baggage we’ve accumulated since EDP first changed its name.

Like the EDP manager, but not the CIO, the business wants its CTO to have a strong technical focus, because that’s how you figure out what the business can do today that it couldn’t do yesterday. And where EDP lacked formal methodologies, in the CTO’s world they exist but they’re pretty lightweight, because the ones we’ve been using are way too slow. Mostly, programmers work with whomever to design the customer interface, then work backward to design the system’s innards.

Best of all, CTOs reject the whole, ridiculous concept of “internal customer”. They’re far too busy worrying about real ones.

Comments