Is Supply Chain Knowledge Key for ERP Implementations?
August 22, 2009
I used to work at QAD, a small manufacturing software vendor. I subscribe to a QAD chat group, and occasionally people ask questions like the one in the title.
It sounds as if the person asking is peddling something–who knows–but it’s an interesting question nonetheless. What kinds of knowledge are necessary (key) for an ERP implementation? If you run a manufacturing company, is APICS (that is, supply chain) knowledge particularly important?
Certainly, QAD used to think so. When I was an employee, you got a bonus for becoming APICS certified. (APICS is the American Production and Inventory Control Society; to get certified, you had to learn how MRP worked and how inventory should be managed.) And certainly, when the product was designed, the focus was on matching supply and demand. The product was built originally for Karl Lopker’s sandal manufacturing business, and the idea was always to have simple, usable product that managed inventory well.
So you would think that the answer, at least for QAD users, is, “Of course APICS knowledge is key. Duh.” But I don’t think so.
You see, while I was at QAD and then for some years afterward, I looked at a fair number of installations. And what I saw was disheartening, at least if you believed in good supply chain practices. The systems weren’t really using good supply chain practices, at least as APICS defined them.
Let me give you an example, which APICS-trained people will understand immediately. One of the ideas of these systems is to reduce the amount of inventory you have on hand at any one time. To do this inside the system, there are two parameters that you have to set, lead time (which is the amount of time it takes for an order to be fulfilled) and safety stock (the amount you want to have on hand at all times). The longer the lead time or the higher the amount of the safety stock, the greater your inventory expense.
So what would you say if discovered that in not one or even two installations, but many, the safety stock and lead time numbers for most of the inventory were set once, en masse, and then never set again? Well, I’ll tell you what to think. These figures, which are key to making the system work, are not being used.
Now this was not just true of QAD Software; it was equally true wherever I went, no matter what software was installed.
So doesn’t this say that supply chain knowledge is key, after all? If they had supply chain knowledge, wouldn’t they have paid more attention? At first, I thought so. But then after a while, I realized that more supply chain knowledge would have made very little difference.
You see, that’s not why they were using the software. All these companies, it turns out, didn’t really care about getting supply chain stuff right. They managed the supply chain fairly sloppily–tolerated a lot of inaccuracy and suboptimal behavior–and they got along (in their minds) just fine doing that. They didn’t want to put in the kind of care and rigor that is the sine qua non for doing with these systems what they were designed to do.
What were they using the software for? Well, mostly to manage the paperwork virtually. Please don’t cringe, Pam, if you happen to be reading this. This is not a hack on you. The plain fact is that the companies needed to keep track of their commitments (orders), their inventory, and their money, and that’s what they used the system for. They needed a piece of paper that told people what inventory to move that day and where to move it to. And the system gave it to them.
To do this, though, you didn’t need much APICS knowledge or, if you didn’t believe in APICS’s recipes for inventory management, other supply chain knowledge. All you really needed was to be able to count, which most of the users could do without being APICS-certified.
So is supply chain knowledge key for an ERP implementation? Not at all. You can have perfectly happy users who have got exactly the nice simple implementation they need without much supply chain knowledge at all.
This answer, of course, raises lots of questions. What is key? Why do these companies tolerate sloppy supply chain practices? Wouldn’t they be better off if they cleaned up their act. Herewith, brief answers.
What is key? At a rudimentary level, the financials. You have to get the basics right, here, or you’ll never close your books. In a system studied recently by a grad student at Harvard Business School, 65% of the inventory records were inaccurate. Can you imagine the upset if 65% of your account balances were incorrect?
Why do they tolerate sloppy supply chain practices? I think it’s largely because more finely tuned systems are much more brittle. They take a large amount of care and feeding and their ability to take hard, rude, unexpected shocks is limited.
And wouldn’t they do much better using the systems? In many cases, no. You see, at most of the companies I’ve run into, the MRP/APICS model that QAD (and every other software vendor) provided is not actually all that accurate. To make a really significant difference, you need more sophisticated tools that are better suited to the specifics of your supply chain.
Comments welcome.
Spend Less Money on the Buying
July 22, 2009
This is one of a series of posts on the high cost of buying enterprise applications and the high cost of selling the products. This high cost, I’ve been arguing, is just plain bad for both sides and almost certainly unsustainable. So the question for the analyst is, “What can be done about it?”
In the background, I’ve had a lot of discussion with industry pundits and the Twitterati: Vinnie Mirchandani, of course, and Jason Busch and @dahowlett and Brian Sommer and Dennis Moore and many others who don’t regularly comment over the airwaves. What accounts for the high cost, I’ve been asking? Two answers seem to emerge.
1. Too many cooks.
2. Too little trust.
If you’ve ever been involved in buying applications, you’ve seen the first one happen over and over again. Too many people get involved with the decision, each with their own agendas, each more or less connected to one of the contenders, and getting all these parties to agree requires too much head-banging. It’s Congress trying to pass health care, writ small, and it’s just as pathetic.
The lack of trust. Well, I get why people don’t trust, and I get why they erect structures that are supposed to control the vendor. But in my experience, it’s always been a losing game. Buyers are nowhere near as devious, oops, I mean sophisticated, as sellers–how could they be, the sellers do it for a living? So if you go into a deal, it’s natural to feel skittish, but giving in to the feeling doesn’t really protect you and does slow you down.
So what’s to be done? In the long run, you can’t do much about either problem without cooperation from the other side. If you’re going to have lots of cooks, the cost of sales for the vendor is just plain going to be astronomical, and the cost of buying will rise accordingly. If the vendor behaves in what has become the normal fashion, alas, defensive (and expensive) buying will be only too appropriate.
Granting that, you have to start somewhere, and here are some suggestions for the buyer, suggestions that should save money. All of these will really help, even though the second sounds completely ridiculous.
1. Limit the scope of what you’re buying as much as possible. Look only at what you clearly need; prefer things that you’ll use immediately; go for immediate results; and don’t buy anything else. You can always buy the rest later. (This reduces the number of cooks.)
2. Use a tape recorder and a camcorder. Keep track of what the vendor says, in full, precisely. Look the transcripts over. If you have questions or don’t understand, follow up. In the long run, it saves a lot of time. (This can help you to get more trust–kind of trust, but verify.)
3. Prototype, prototype, prototype. Get a small team to set it up and try it out, rather than assembling a large team to review demos that were set up by the vendor. If you have to pay the vendor to help you with the prototype, do it. You’ll save in the long run. (This, too, reduces the number of cooks.)
Enough from me. Suggestions from the readership are welcome.
Innovation in Enterprise Applications?
July 10, 2009
Those of us who have been in the business for a while feel it’s in the doldrums: there’s not much innovation, and every year, the apps get older.
Where will innovation come from? Well, the thing about innovation is that it has to change something that we think is fundamental and immutable: it has to be on a CD-ROM, it has to be typed from a phone keypad, etc. So you can’t look for innovation in the same old stuff.
That said, here are four areas that I think are wide open, wide open, wide, wide, wide open. An enterprise application (or an enterprise application company) can get an edge if they can do one of the following things:
Reduce the cost of sales by a factor of 10.
Reduce the risk of ownership by a factor of 2.
Increase the effectiveness of the application by a factor of 5. What’s a measure of effectiveness; well, let’s say it’s the number of users who use it seamlessly and easily.
Increase the speed of the application (usually by using a special-purpose database) by a factor of 50.
At least two of these aren’t impossible, because we’ve seen them happen.
Salesforce reduced the cost of sales for SMB customers by selling an enterprise-level application that you could test for free and buy with a credit card.
Workday and Qlikview both transformed applications in their area using special-purpose databases, and Hasso wants SAP to do the same.
And at least one large company, SAP, is trying for innovation in the third. Fumbling and clumsy as their effort to improve maintenance has been, the idea is to reduce the risk of owning SAP by making maintenance practices considerably more effective.
As for reduced risk of ownership or increased effectiveness (actually, maybe you’ve seen Qlikview do this), we’re still waiting.
Ideas on who’s done this or how it can be done?
Lower the Cost of Sales!
July 3, 2009
In many previous posts, I have complained, bitterly, about the sales tactics that every enterprise application vendor uses, mostly to defend aging, poorly designed products. It’s one thing to put lipstick on the pig, I’ve essentially said, but it’s outrageous to charge admission, just to see the pig.
This is, of course, what happens in most sales situations. Companies big and small buy the software through a highly-paid salesperson, part psychologist and part snake-oil salesman, who listens to you, discusses your pain with you, and then arranges a long, long process that you and your team will go through: functionality requirements and demos and business cases and who knows what all.
Let me fill you in on a little secret. It’s mostly a waste of time. And money. Not just your time and your money. But also the software company’s. You are both driving up the cost of software, simply by accepting and perpetuating a system where rigmarole is the rule of the day.
In a time of economic growth, maybe both companies could afford it. So what if you use up a lot of IT hours compiling functionality lists and sleeping through demos. (Who could stay awake in them?) The IT guys like it well enough, and they like to be asked for input. So what if the software company wastes a lot of, er, resources flying in executives or taking the team out after all their hard work to a place where attractive women perform. (Happens, believe me.)
In a time of economic frailty and, not coincidentally, a time of doubt about the value and merits of enterprise software, no one can afford it any more. Not you, who has better things to do with your resources. Not the software companies, whose sales resources are being spread thin by companies that are insisting that the salesperson do more and more for them.
Wouldn’t it be better to use some of the resources squandered on these endless sales cycles for something else a little more worthwhile? LIke getting both parties to the right solution faster?
The Applicator 