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.