In the fall of 2000, I received a call from Nabisco. We had not even thought about working on our scanning service yet, but they read in some of the trade magazines about how Scott Systems Inc. and StoreReport had teamed up with IBM to create a cloud computing environment for convenience stores, and they were interested in incorporating our system in the 100,000 retail locations they serviced.
According to them, they felt if the deliveryman could determine what a customer needed before he pulled away from the warehouse, it would result in millions of dollars in savings to both Nabisco and their customers. They were so adamant about it they even suggested they might pay for the services and offer them to their customers for free. Of course, after Philip Morris acquired Nabisco, December 11, 2000, that was the end of our negotiations.
That got me to thinking. If a supplier was even entertaining the idea of bearing the entire cost of a rollout to 100,000 locations, there had to be a reason for it. In spite of the fact that I was no longer able to deal with Nabisco, the seeds had been planted and I started working on the project in the spring of 2003.
In order to test and perfect such an undertaking, I chose to work with a customer we had been working with for over twenty years. Over the previous two decades we had established an excellent relationship with that particular customer. They were a forward thinking organization and had served as a guinea pig for much of my unorthodoxies in the past.
In the spring of 2004, my customer arranged a meeting with five suppliers to ask for their assistance in implementing our scanning project. In addition to the customer, the group involved two major beverage distributors — one soft drink and one beer, a major grocery suppler, a chip rack-jobber and a local knick-knacks guy. We were assured by each and every one they would cooperate in our research project. The only thing we asked of them was that they send us store purchases electronically.
The basic idea was the supplier would send an electronic spreadsheet, EDI or XML file to us, we would scan the items into the store, match the results to the electronic document received by the supplier, and report any errors to both the supplier and the retailer.
The supplier would be able to track the delivery from the warehouse to the store, and the retailer would notify the supplier of the items received.
Then the inventory would be added to the retailer's stock, sales would reduce the inventory, and audits would correct any losses due to spoilage and shrink, giving the retailer an accurate count of what was on the shelves and how many selling days would cycle before the next delivery. Then the supplier could peer into the retailer's database and see what the retailer needed on the morning of the next delivery.
As it turned out, only one supplier lived up to their bargain and actually attempted to send invoices to our computers. However, very few of the items on the electronic invoice matched up to what was being received at the store. In general, the majority of the items were correct, but the UPC codes they supplied with the supplier's unique ID's were not, making proper identification all but impossible.
We struggled with that supplier for a year. We even offered to come to their warehouse and build an inventory database for them. Since both of us ran on AS/400 mainframe systems, we could have done the job in less than a week. However, they refused, citing of all things 'insurance liability issues'.
Without boring you with the details, let me just say that suppliers do not want you to track the inventory in your stores. It is not in their best interests at the moment. The reason I say this is because I have been dealing with them for seven years and I have gotten that impression time and time again. Knowing what you have in your store gives rise to an exorbitant number of embarrassing errors popping up.
This is very important. Suppliers are not purposely trying to take advantage of you. They just have their own little way of doing things and they don't want their retailers messing with it.
The trouble with most suppliers I dealt with was their systems were engineered in the early eighties and changing it scared the daylights out of them. Most of their systems were set up to assign a number to bins and racks in their warehouse and they really had no provisions for handling the UPC codes on individual items. To exacerbate the problem, they seldom sold retailers what the retailer passed on to the consumer — For example a carton of candy versus a candy bar.
To put it simply, if a customer ordered items, they would order by the supplier number that was assigned to the place in the warehouse where the item was located. And whatever happened to be in that spot at the time the order was received, was what the retailer was shipped.
A good example is those little air fresheners that are shaped like trees. If we looked on the peg where they resided, we would find two brands of the same product mixed together. This system allows a supplier to swap products without informing their customers of the switch. That's why I say one day a specific supplier identification number might apply to Campbell's Pork and Beans, and the next day if might be pork and beans of a different brand. This sloppy way of identifying products often gets out of hand, and what started out as pork and beans and remained so for several months might evolve into a completely different product overnight — any vegetable in a can would do. Asking the suppliers to be specific with the items ordered and/or shipped turned out to be an impossible task.
After a year of struggling with that supplier, we finally decided that we would simply cut the supplier out of the loop. We developed a method whereas items would be scanned into the store by store personnel and the results of the operation would be the store manager would compare the paper invoice to what was actually scanned into the store and discrepancies would be turned over to headquarters to resolve. That's when we started noticing the enormous number of errors on supplier invoices.
In a February 15, 2003 article entitled 'Data To', Progressive Grocer Magazine reported 60% of all supplier invoices contained errors, some 40% were in the favor of the retailer and it cost from $40-$400 to correct even one simple error. We were proving their study to be accurate.
The same article also claimed that $40 Billion is lost in the supply chain each year. If 40% of that money would be in favor of the retailer, that meant that retailers were losing $16 Billion a year due to errors in the way suppliers are doing business. With the remaining $24 Billion being lost by the suppliers, you would think they would be all over this kind of technology. I predict that sooner or later suppliers will begin to research this issue and make the decision to clean up their inventory control problems because it's only going to get worse.
In the meantime, the retailer has to figure out a way to solve his own problems, and that means bypassing the supplier entirely and doing the detective work on their own. Being confronted by invoice errors from all of their customers each day is something suppliers do not want. So, for the time being, instead of cleaning up their inventory control systems, they prefer to ignore the problem as long as possible.
In summary: Dealing with suppliers seems to be a waste of time for the moment. We must clean up the inventory problems in our own stores first. This will lead to arguments and negotiations that will eventually end up with suppliers cleaning up their own inventory problems.