All Posts in Organizational Design

|In: Industry Commentary|Last Updated:

It’s scandal time!

Your intrepid reporter has uncovered an outrage of major proportions: Not one of the major ERP suites … not SAP, not PeopleSoft, nor Oracle … scales effectively. It’s true!

Oh, they scale up just fine. I’m sure there’s some level of organizational size and scale where they break, but I don’t know what it is. Here’s what I do know, though: They don’t scale down very well.

Imagine you run a 45 employee company, and one of the above-mentioned vendors offered to give you their software for nothing. (Why? Maybe it’s a charitable non-profit whose cause they like. Don’t worry about it.) Both the cost of the license and the cost of annual maintenance and upgrades are covered. Not only that, but they’ll handle all of the installation, customization and integration.

Should you accept?

Probably not. I suppose it’s possible that with enough customization you could trick one of these packages into handling your operation, but what would be the point? Major ERP suites are built on a set of assumptions, largely hidden, regarding how a company operates. They assume, for example, you have an accounts payable department, with people who spend much of each day receiving invoices, matching them up with purchase orders, and routing them for approval to pay. They don’t assume you have Jill, who deals with maybe a dozen invoices a week in her spare time, getting approval to pay by yelling to the guy who lives three cubicles down, “Hey, Jack, did you ever get that toner cartridge I ordered for you?”

The scaling-down question has received little attention in IT, and it isn’t limited to software packages. Most of what we consider to be professional ways of implementing IT … the software, tools, and especially the methodologies … are designed for big. When your needs are small, they don’t scale.

Modern methodologies do recognize the fallacy of big projects. The idea of “chunking” big efforts into a collection of separate six-month projects executed by small, focused teams has entered the mainstream. You, however, have a four-person IT department which you lead when you aren’t busy helping the CFO figure out how to build a pivot table in Excel that links to an Access database. For you, an eight-person six-month project is far from small. It’s equivalent to the entire work output of your department for a year.

The heads of IT who run operations this size (they rarely call themselves CIOs) read about “industry best practices” and chuckle, knowing that using them would bankrupt their employer. “Best?” Not in a small company. When a large development effort is Ralph working with Jill to activate electronic bill pay in QuickBooks, it’s a sure bet Ralph shouldn’t first spend a month or two writing use cases. As for Ralph’s test plan: He’ll have Jill make a one-dollar payment to the company. If it arrives within a week, everything is working.

It’s been more than twenty years since IT discovered the importance of good process. And good process is vital in large companies. The reason it’s vital explains why scaling down is so hard. It’s the result of the formulas for two different kinds of line.

The first is the combinatorial formula: n(n-1)/2. It describes the number of relationships between employees, which translates to the cost of doing business through relationships. If you have few employees, you don’t need much in the way of process. Work gets done with little organizational friction because everyone knows everyone. With a lot of employees, though, everyone doesn’t know everyone, and the cost of doing business this way skyrockets.

When you rely on processes, in contrast, you apply a different formula: a*n + b. That’s the formula for a straight line, and what it means is that processes impose overhead, but scale well. It’s great when you have a lot of employees. The overhead becomes irrelevant compared to the ability to grow without costs going through the ceiling.

But if you run a small operation, be cautious about adopting them.

They weren’t, after all, designed to scale.

Comments

|In: Leadership|Last Updated:

We used to say, “Quicker, cheaper, better … pick two.” Then process re-engineering came along, promising improvements in all three through the magic of being more insightful than those who built the current process. Sometimes re-engineering succeeds. Sometimes it does more harm than good, in part because, as discussed in this space over the last two weeks, neither quicker nor cheaper consists of just one measure. While “Shorter cycle time, higher throughput, lower overhead, reduced unit cost, and better … pick a few,” sounds dull, it’s more likely to keep you out of trouble than its snappier predecessor.

Quicker and cheaper are each multiple measures. How about “better” — is that just one measure, or is it more?

From the perspective of any given process, it really is just one measure. Quality (“better”) means adherence to specifications.

A process is a factory, producing a large number of items which are supposed to be identical in one or more respects. If your goal is to improve a process — perhaps the most common objective of any IT-related project — then improving process quality mean its outputs more closely meet specifications.

Not every activity in a business is a process, though. A lot of time and energy goes into figuring out what specifications the company’s processes must meet. “Better” in this sense can’t be constrained by any simple, single measure.

How does this relate to IT? It isn’t a new point, but it bears repeating: Nobody cares if the software works, only if the business has changed successfully. That means IT needs to be able to lead business improvement efforts, which in turn means understanding how to make the business “better” in all senses of the term — adherence to specifications, and choosing the right specifications in the first place.

So … specifications have two major sources. The first are customers — people who make buying decisions about our company’s products and services. Customer-driven specifications are a matter of aesthetics.

Aesthetic specifications are never right or wrong in any objective sense — all they can do is match the tastes of the customers we’ve decided to target. The specifications for a Lamborghini Gallardo, which are all about speed, handling, acceleration, and looking very, very cool, are neither more nor less right than those for the Toyota Prius, which emphasize price, reliability, and incredible gas mileage. Two different groups of customers, two different entirely right specifications.

The other source of specifications is competition … winning and losing. What determines whether your company wins? There’s no simple formula.

Think baseball: Some teams win on pitching, some on rallies, and some on home runs. Different strategies work better against different opponents, except, of course, that all strategies beat the Cubs … but I digress.

Think chess: Some players emphasize positional chess, building unassailable formations from which they can launch attacks; others concentrate on combinations — surprising sequences that win by tricking an opponent into making a mistake. Which is better depends on who you’re playing.

In military doctrine, as my friend Curt Sahakian, president of the Corporate Partnering Institute, reminds me from time to time, maneuver warfare holds the current key to success. It works through a process-like formula called the OODA loop (observation, orientation, decision, and action) developed by Colonel John Boyd after the Vietnam War debacle.

Whichever side has the faster OODA loops generally wins. Which doesn’t, however, mean the process of developing competitive “specifications” has been reduced to a predictable, repeatable process.

Far from it. Speeding up your OODA loops only works when the accuracy of observation and orientation, and the suitability of decisions and action, don’t suffer.

If this weren’t the case, any decision made quickly enough would win, as would action no matter how sloppily executed. But that isn’t the case.

For while indecision almost always leads to failure, the world has no shortage of stupid losers whose only ability is to make snap decisions without first understanding the situation.

And while failing to act guarantees losing even more than failing to decide, taking action certainly doesn’t guarantee winning. It’s the ability to execute that in the end makes the difference.

Want another description of the ability to execute? It’s having the discipline to make sure you adhere to the specifications that are, after all, the products of worthwhile decisions.

Comments