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.
Delivering Sourcing Optimization
August 6, 2009
It’s a plain fact that there are certain kinds of math problems that even bright people don’t solve very well and computers solve better than we do. Some of these look surprisingly simple. If you’re a retailer, when should you mark down product and by how much? Or if you’ve got to make six deliveries, should you use one truck and make six stops, two trucks with three each, etc.
Entrepeneurs in the world of enterprise software have recognized this fact for a long, long time and have seen an opportunity there. They develop so-called optimization software, which solves an essentially mathematical problem and then provide it in various forms to the market. A few have provided only the engine itself, most of them ending up in I-Log, and many more that provide optimization solutions that address specific problems, like supply chain optimization, markdown optimization, or the subject of this post, sourcing optimization.
Now if there’s one thing that’s completely clear about optimization software, it is that the track record has been disappointing. I’m not just talking about the overpromising and underdelivering that afflicted the big-name supply chain optimization vendors. (No names, but you know who you are.) I’m talking about really wonderful products, like Joe Shamir’s ToolsGroup, which have struggled to put their tools in the hands of people who need it.
Sourcing is no exception to the general rule. In sourcing, optimization came to the fore when companies like FreeMarkets or Digital Freight wanted to set up sourcing “events,” where possibly hundreds of bidders could bid on thousands of line items, offering discounts for bundles of selected lines. What if A bids X for lines 1, 2, and 3, and B bids Y for lines 2, 3, and 4, etc.? This is one of those math problems that linear programming solutions solve better than human beings do.
A number of vendors still in the market place (you know who you are) proceeded to develop solutions for setting up and managing these events, which of course did a lot more than just figuring out which bids to accept. And to some extent, they worked; they did change the way many companies do business, and sourcing events are now fairly normal, with several large companies being big proponents.
But in my (admittedly somewhat limited) view, the optimization piece has been relatively unimportant. Certainly some companies have developed some good optimization algorithms, and they are used, but in the events I’ve seen or heard about, it’s not clear to me that the solutions they offered were actually all that optimal, and the reaction of buyers that I know to the solutions they offered have been tepid, shall we say.
I’m not surprised, as I say, because I’ve seen similar reactions from users of other optimization software.
Now I have a degree in math, and I’ve taken a course in linear programming. I know that the solutions they give you are better than what people can come up with by themselves. So are the people who don’t like these solutions just grousing? That’s certainly what most vendors think.
Well, the other day, I got a glimmer of the answer from some terrific research done by Vishal Gaur of Cornell University. (See my earlier post, “An Automated Replenishment System.”) He found in his case study that a solution produced by optimization software had a highly suboptimal operational effect because it was optimizing around the wrong things. The math was done perfectly, but the problem had been set up incorrectly.
This is always a problem in principle when you set optimization software chugging away. The software draws a box around the problem and finds the point inside the box with the best available solution. If you draw a different box (usually a larger one), the solution will be different, and will take longer to find.
In Professor Gaur’s case, the software developer had drawn the wrong box around the problem. Now what’s interesting here is that the software developer never knew that he’d done anything wrong. He delivered the software, and the IT people who were using it expressed satisfaction. And you might think, “Well, so what, even if it drew slightly the wrong box, it got roughly the right answer.” But in fact, when you change the box, you change the answer completely. So in this case, the users had to replace (manually) all the solutions the software offered (manually) with better and completely different solutions.
If you have optimization software, in other words, you have to draw the right box, or the answers that it gives you are not better than what you can provide, they are worse, often much, much worse.
Now look at how this applies to sourcing optimization. Let’s say that you set up the problem in one way. (You only allow bids from certain vendors, for instance, and you require that they offer discounts of a certain percentage.) If you draw the box differently, you will come up with quite different answers.
I was discussing this problem with Garry Mansell, president of TradeExtensions, a small sourcing optimization vendor. He argues that the only way of solving this problem is to provide a lot of services, along with the software. The experts that he provides (it just so happens, of course, that he’s in the business of providing this pairing) can keep the sourcing on track and make sure the right box is drawn.
Now I react to most honeyed words from vendors the way I react to offers of honey for my tea. (Hint: “No, thank you.”) But this struck me as roughly right. The problems that I’ve seen with implementations of myriad kinds of optimization software wouldn’t be solved, then, by fixing the software. It would be solved by helping people to make sure that they’re drawing the right box around the problem.
So who knows. Maybe Mansell is right. (Or maybe he’s just selling software. Or both.) But it seems to me to be a useful thing to keep in mind. If you’re looking at sourcing optimization software (or, more generally, any optimization software), don’t buy it and don’t use it, unless you have some serious experts, who can help you make sure that you drew the right box.
An Automated Replenishment System
May 8, 2009
There’s an assumption, these days, that systems whose basic design principles and strategies have been around for twenty years are, by this time, working pretty well. If you think that, consider the following.
A person I know well was asked to evaluate the effectiveness of some automated replenishment software at a retailer of his acquaintance. The automated replenishment system had been built to optimize inventory levels, so it automatically asked for replenishment when inventory was low.
What he found was that the store managers were systematically ignoring the replenishment requests and overriding them. Hah. We all know about this, right? Stupid, willfull store managers ignoring the mathematically sophisticated system that was calculating real supply and demand. The real trouble with business is people, right?
Not at all. It turns out that the best way to optimize inventory levels is to delay orders. (First day, Supply Chain 101). The peak days for the stores were Thursday, Friday, and Saturday. Since the stores got daily deliveries, taht meant that the peak replenishment days were…Thursday, Friday, and Saturday. Unfortunately, the store managers didn’t want deliveries on those days. They didn’t have the staff for it. They wanted deliveries on slow days, when the staff would be available for it. So every week, they were going into the system and moving the replenishment requests forward to Monday and Tuesday. Every single week. For thousands of SKUs.
Now there’s a good use for managers’ time.
My friend is a skeptical sort, though very helpful. So before throwing up his hands, he tried to decide whether they were doing the right thing. He wrote an optimization algorithm that optimized deliveries based on inventory levels AND labor costs. Guess what. The store managers were doing exactly the right thing. His algorithm slightly outperformed the managers, probably because they had to do all that changing by hand. But the outcomes (the actual outcomes by the store managers and his theoretically optimal outcomes calculated by his algorithm) were very close.
And yes, he did leave the algorithm behind him, so now the managers don’t have to do it by hand any more.
So here’s what we know. Basically, the people who wrote the automated replenishment system had done a bad job. They had written an “advanced,” “automated,” replenishment system that optimized decision-making, but they had optimized on the wrong thing. So instead of providing a system that did optimal, automated ordering, they created a system that generated thousands of orders, each of which had to be corrected by the highest paid person at the store.
And until my friend came along, nobody seemed to know about it.
Now, I’m not saying who is responsible for this, whether it is a commercial replenishment system or a custom-built replenishment system. But what I can say is that all the commercial replenishment systems that I know about do it in exactly the same way; they optimize around inventory levels.
Why do they do that? Well, for one thing, the system is self-contained. They have the inventory information available in the same system, so adding in an optimization doesn’t require any integration.
For another, the people who are building systems like this do not think like retailers (even though their customers are retailers). If they did, they would realize that the orders need to be staggered.
And for another, neither they nor their bosses nor the people who bought the system never, ever followed up on what they did. If they had followed up, they would realize that the system they built was not doing the job that it should.
What it should have done is generate the right orders automatically. But all it was actually doing was generating template orders all of which had to be inspected and corrected by hand. It wasn’t a complete wash. It did generate orders with roughly the right amounts (over a week). And, because of the way the system worked, some of the corrections were relatively rapid. (Sometimes, if you moved two orders forward, subsequent orders would automatically self-correct, because the system would reduce subsequent orders by the amount that had already been ordered.)
So is this some isolated instance? I don’t think so. As you probably know, the basic operation and design of these systems has been around for twenty years. All the commercial systems, so far as I know, optimize around inventory, without taking labor availability into account. If this particular system works very poorly because of a design error, there’s every reason to believe that others don’t work either.
If that’s the case, it’s a little scary. There have been a lot of automated replenishment systems put in over the past twenty years, and almost all of them have been justified by the claim that they kept inventory levels down to optimum levels. If that claim is wrong (because keeping inventory low necessarily entails excess labor costs), then there are a lot of systems out there that were sold and installed under false pretences and are now being used incorrectly.
The ironic thing about this is, of course, is that only a very little attention to how these systems are being used would not only show you the problem, but also show you the solution. To correct the system, you don’t need to integrate with a labor availability system (that would be hard and isn’t what my friend did). All you’d need to do is write a small program that corrected the timing, using the corrections that the humans were doing already as a guide.
The Applicator 