Designed for Stability
June 22, 2009
I was just talking recently to a specialty chemical company whose specialty product is used primary by an industry that is now under water. They have a lot of middle-aged systems, and they’re looking for something, anything that they can do in the systems area that can help them out.
We’re talking about a company that needs to contract by, say, 50% until their market comes back.
So what can they do? Well, nothing. But the reason they can do nothing is well worth paying attention to and pondering.
You see, the systems they have–I won’t tell you which one is preponderant, but it’s one of the $AP family, that is, SAP, Oracle, PeopleSoft, JD Edwards, etc.–are all designed for stability. They work well only when things change very little. Change a manufacturing line, get a new big customer, add a new product or two, and these systems can deal; it only takes a few man years of work.
But change the business in some fundamental way and everything breaks. Move a line from one factory to another, and it might actually be easier to move the physical line than it would be to move the data in the old ERP system into the new one.
Chrysler faced this a while back, when Cerberus bought it; now, both GM and Chrysler are having to deal with it. I ran into the problem at an electronics company that was deciding to outsource and at a company that was trying to shift a lot of its business onto the web. Their systems wouldn’t let them change.
Well, it’s a good thing if the company that’s setting up the system is stable, has a product that doesn’t change too much, has reliable customers and a business model that will work for the next twenty years.
Know any companies like that?
It’s a bad thing, though, if your company wants to or needs to change fast. Then your systems will get in the way.
Do people ever think about this simple fact when they’re buying the systems in the first place? I’ve never seen any company that did. Do they think about it when they’re buying a company? I’ve only seen a few. When they’re figuring out whether to consolidate systems, that is, do they consider the tradeoff between the money they’ll save by consolidating systems and the money they’ll lose if they have to disentangle the newly consolidated entities? I’ve never run into anybody who did.
It makes sense, of course. Everybody thinks that things will stay more or less the same. Companies, their employees, the people who sell them systems, the people who design the systems. So that’s what they plan for, build for, and buy for.
The only problem is that much of the time, it isn’t true.
Not only the systems, my dear, but the entire mode of doing business with the vendor.
They come to the conversation talking to me about consolidation; they want to use fewer systems, servers, support personnel, etc.
I don’t think this is going to work; in fact, I think they’re going in exactly the wrong direction.