A new general came in and insisted on using SAP. 6 months later, they had to rebuild both warehouses.
EDIT: For some additional context, the system managed to basically eliminate the "bull whip effect" all the way down the supply chain. It's really a fascinating system. Developed by Dr. Bill Kernodle and Dr. Steve Davis from Clemson Apparel Research.
It’s a really broken system that no one seems interested in fixing.
If you could hide the budgeting effects from anyone with the ability to 1. start projects or 2. add scope to projects, then it seems like it'd work out just fine.
(Of course, actually doing that would require splitting "planning" roles into separate, almost-adversarial "defining projects + increasing scopes for projects" and "feasibility-analyzing + cost-optimizing + decreasing scope for projects" roles. But that seems like exactly the sort of thing the DHS would be fond of. War-games for the project managers; and separate levers for both kinds of sitting presidents to pull on to satisfy their bases, where building up one capability doesn't tear down the other.)
A market economy does not really help, that just means you don't have a budget to cut in the first place.
It’s more the opposite, that many people have a strong financial interest in maintaining the system.
Authored by Joseph W Kernodle of CLEMSON APPAREL RESEARCH.
I was a GA from 2003-2004.
Later I meet a former procurement officer who was reprimanded for excess purchases in the year leading up to the system launch. In the end his team was the only one able to provide equipment for an extended period of time after the new system was introduced. Everyone else had relied in JIT supply chains, but this guy didn't believe that the new system would work and spend a year building up inventory.
I do some Scaled Agile Framework consulting and the implementation a good example, because it can be fantastic but if leadership at the top of the company doesn't get on board the entire process will self destruct or be bastardized.
The professors who built the system knew this about every customer they talked to and it was a big learning experience for me. New leaders will come in and often insist on tools that they already know, rather than take the time to learn about better options.
If you've ever read Skunk Works (fantastic book), you see lots of this in the military procurement process in the US. It's bad enough that you worry how much it's hurting US national security innovations.
I've seen this with developers. Newly joining developers, particularly junior and mid career developers, tend to insist on using the languages, libraries, and techniques they are familiar with. Senior Developers don't seem to do it as much. Either because they are familiar with many things, or because they have been on the other side of these well intentioned suggestions to know when it is actually productive.
I saw it posted below. The system was/is called Balanced Flow.
For example, the solution may not have worked well with other procurement items and they wanted a single platform. Or the navy already had an SAP contract that could be leveraged without spending money on a separate stand-alone army solution.
So it can look like a bad decision that generated local inefficiency while globally it was a better choice. That's not to say SAP actually delivered on those promises.
Its always good to call out corruption, but its also important to realize when a situation is actually crazy complex and while its an awesome story might not be worth formulating a summary judgement from.
In this case, it sounds like they should’ve bolted the JIT platform onto SAP
Basic business logic is built into SAP - but because it covers all aspects of business, it’s a massive tangle of rules.
For instance, let’s say you get an invoice from a vendor. Now you have to update your balance with that vendor, and your general ledger. You have to record the new inventory moving in. Perhaps the inventory has a barcode, or a serial number with a warrantee date, or a batch with an expiry date. The inventory movement will be tied to the cost of that invoice - remember to take into account those exchange rates. Also, there’s a variety of ways to account for item cost. You will have had one or more purchase orders - those have to be closed. If the vendor is to be paid in a different currency, you have to do every accounting entry in your currency and theirs, and record the exchange rate differences. Your accounts payable are now in that other currency, which means that has to be updated all the time for accurate bookkeeping. You have to note which employee was the buyer. This buyer has targets and metrics to be tracked. Perhaps there are reports and alerts set up for them. You will have a budget, which may impact this transaction. Of course you also have master data for the vendor, the employee, and the items bought.
There is a lot more to this than the above, and this is for the simplest business case - one that happens hundreds or thousands of times a day depending on the business. Usually there are special considerations to program into the above as well. Now imagine what happens when a complicated situation arises, where you have complex transactions spanning months, many countries, and many other businesses. Sometimes there are legal rules built into the logic. Usually those rules only alply to one country. And I haven’t even mentioned freight or tax or landed costs from secondary invoices.
SAP is a ball of wire because it simply has to be.
If you built a new ERP, you will end up the same.
I developed a custom engine for things like aluminium rails, and thermal sensors, to generate a new product with the production tree in SAP, so it would be able to decrease the right ammount of raw materials from the warehouse.
It does not make sense for Amazon to run there own shipping fleet... until it does.
The other point is that armed forces tend to have a mandate to control the supply chain, this might be a case of that.
The Army isn't a business and should never be run as one.
