What is Vendor Managed Inventory (VMI)?

I've seen the term Vendor Managed Inventory (VMI) used in about a million different manners now, and I just realized that the term is so liberally used, it can be cut up into various pieces that might make more sense for those uninitiated with or considering a VMI move in the supply-chain management world.  I don't want to argue the merits or demerits of VMI, I could probably write a book about it (whew! Looks like I don't have to?), but my take is that it's broken down into a few categories (I'm making it really simple for quick guide like sake):

Vendor Managed Inventory – Supply Side

Vendor Managed Inventory (VMI) in its purest form is when a vendor (supplier of goods) manages the inventory level AND stock level of its goods on a buyer’s (demand side) premise.  That is to say, they are responsible for scheduling / delivering a set amount of their inventory to a buyer’s stock room, and also re-stocking the buyer’s shelves with their goods.  Requisite levels of inventory are determined by sharing point of sales data (POS) and analyzing it in order to predict the best inventory level possible for the buyer based upon evaluated sale trends. 

Generally this system isn’t used as it requires the supplier of goods to be on site continually to make sure shelves are stocked.  This could mean a permanent resource on site or a daily visit to the buyer's location to ensure shelves are stocked and consumers have access to buy the goods.  With expensive, large, or slower moving goods, these human resource needs might not be as demanding, but the risk of losing a sale is very real if the good in question is not available to the customer seeking the product.

Vendor Managed Inventory – Supply/Demand collaboration

This is a growing, and usually more successful, form of Vendor Managed Inventory (VMI).  In a collaborative effort, both sides share sales data and analysis in order to fully optimize their inventories and sales opportunities.  In such cases, both sides divide up responsibilities (by agreement) and do their best to support each other as means allow (this can mean a lot of human communication, physical visits to buyer’s site by vendor, and  even sharing human resources at loading bays or even stocking store shelves, to get the job done).  Goods may be on consignment, delayed payment (90 day pay period on invoices), or purchased outright -- depending on agreement.

Vendor Managed Inventory – Buyer side

This is probably the most common form of Vendor Managed Inventory (VMI).  In Buyer side centric models, Vendors are usually leaving goods on consignment at the Buyer’s premise, and/or invoicing for a 90 day or more period before getting paid ... giving the demand side buyer time to make sales and earn cash before actually paying for the goods.  When this happens, usually the buyer is the sole entity responsible for keeping shelves stocked in order to make sales.  However, depending on the relationship and agreement, this type of relationship may demand that the supplier take back all goods not sold or alternatively that the buyer pay for the goods regardless if they’ve been sold or not.  Not the best system for creating trust and a positive business relationship among partners (hence why it’s in slow decline), but it’s still today the most dominate form of VMI.  Large players like Walmart almost use exclusivey this model, because they can.

Buyer Managed Inventory

This method is all but dead in the FMCGs business to all but the smallest players.  In this relationship, the buyer is wholly responsible for pre-purchasing goods to sell, incurring losses on items not sold, and responsible for all stocking/restocking of goods that are customer facing.  The vendor plays no role in the inventory process aside from dropping off goods at the bay doors of the buyer’s place of business.

Of course, there are hybrids in-between the above -- each one has a positive or negative element to them that might be better or worse for the supply or buyer involved.  Which one do you use?  Or which hybrid model do you use or do you think is best?  As stated above, these are mainly in the FMCG world, but they could apply to others as well.  Thoughts?

 

What makes a successful Project Manager?

I was recently asked by a recruiter (who “cold called” me for a job I didn't deem I was qualified to fulfill) to describe the attributes of a successful project manager.  I think my no holds barred replies shocked him a bit.  I said uncensored (make sure there are no children present):

•  To know what the fuck you’re talking about (I don’t know why I dropped the F-Bomb to a stranger, but I did …): Basically, don’t say “I know” if you don’t.  I have no problem saying I don’t know something and asking for help from someone with more wisdom in the matter than me.
  
•  To ignore process when it’s in the way*** : For example, if you have the bandwidth (time), and somebody needs your help – help them. Don’t make them raise tickets and bother 3 other people in the organization and waste their time to solve a problem.  Especially if it’s a customer.
  ***This can even work in more serious changes like production rollouts, but you really have to know what you’re doing.  You're either a hero or fired.  Not for the squeamish.
  
•  To garner social capital with your teammates and customers on a regular basis … ie, get shitted (drunk) with them once in a while and have some fun.  If you don’t drink, that’s fine, just don’t be a bore.  Nobody wants to help people who aren't fun, and they will do so only by “force” or necessity. 

That’s it.  All the certificates in the world mean nothing (Yes, I’m Prince2 certified, but I was forced to do it!).  I knew many PMs with certificates covering their walls, but they were notoriously unsuccessful because nobody wanted to help them (see point #3 above), they moved way too slow (see point #2 above), and they tended to escalate way too much (instead of trying to find the solution themselves in a diplomatic manner …. point #1 kinda applies).

There is nothing magical otherwise.

The importance of productivity ...

As I get into the final phases of development before the first release of my smart shelf solution, I am focusing a lot on usability and productivity features.  Outside of elite software development circles, these intangibles are still little understood and highly undervalued in the IT world.  Such features are always hard to elucidate to potential customers because they’re immaterial (not easily written into a feature list) and can usually only be perceived after the fact (ie… after using them).

When I say productivity what does that mean?  Well, there is the dictionary definition of it, but let me give you an example:

Many years ago I got the opportunity to work for a new start-up ran by some real math geniuses at JetBrains.  When I was asked to come on, it was a small team just releasing the 2^nd version of their now industry famous and unbelievably awesome Java IDE IntelliJIDEA.  These guys were the first to put refactoring features into a Java IDE and not only that, made it quick and easy to use.  Developers (their niche market) saw the value immediately and sales quickly took off.  A simple refactor like “rename” immediately saved 10s of minutes if not hours of manual (and error prone) work renaming items in your code.  You could now fire up the “rename” refactor with a push of a button, and all (for example, class names) within the entire project would be renamed to whatever you chose (error free).  Seems simple in retrospect, but it was a huge time saver at the time, and companies were willing to pay for such features.   Here’s why:

Let’s say you pay a developer 80,000 USD per year to program for you. He works 8 hours a day, 5 days a week, 4 weeks a month – an average of 20 days per month.  That yearly salary roughly translates into 6,666 USD per month, 333 USD per day, 42 USD per hour, .70 cents per minute.  This new feature saves 15 minutes per day.  Time = Money, so around 10 USD per day of developer time (ie… more work completed in the same amount of time).  Now, basic math: 10 USD per day = 50 USD per week = 208 USD per month = 2500 USD per year.  The software license cost was 500 USD.  That’s 2000 USD in increased productivity or programming value for that 1 developer.

And of course, that wasn’t the only feature (the tool had way more, with much larger productivity savings, but general time savings per day with the new tool was probably around 1 hour a day total).  Other elite programmers understood it immediately and had their bosses buy it; in companies where there was no budget, or worse, somebody who did not understand productivity was in charge of finances (which is usually the case), many programmers bought the software with their own money!

Then came the competition.  As our software added these productivity features, other vendors started to add them as well.  In this market, our competitors were open source software Eclipse (funded by IBM) and NetBeans (funded by Sun Microsystems).  Backed by billion dollar corporations, the foundations running these open source variants offered their software FREE, with features rivaling IntelliJ IDEA – maybe always 1 or 2 steps behind, but basically great value for the money (free!).  But you know what, although on a 2 dimensional feature list, they could compete with similar features, they still could not compete on the productivity side.  Their “rename” feature might work just as well, but to use it, you had to take your hand off of the keyboard, click around on the mouse, and basically go thru 4-5 steps to invoke this feature.  With IntelliJ IDEA, you needed just one press of a button (superior usability).  To this day, JetBrains is around, making a ton of software variants for different platforms and languages (all of them born out of IntelliJ IDEA) and always keeping 1-step ahead on productive features against their rivals.

That’s what tools you buy for your company should do.  If they complicate things, then they really do not have much productivity value.  Having played with many of the leading ERP system variants and their modules (SAP, Ariba, ex-People Soft now Oracle, Salesforce, and even smaller system), some of them are just horrible to use.  Slow, complex menus, nothing intuitive about them when using them … they’re not productivity inducing at all and even add some initial complexity to the organization (usually requiring expensive trainings, consulting for refinement, etc….).  Such systems shouldn’t be that way, but they are.  And they rule the logistics world.

However, knowing the above ... how can one sell “productivity” to a potential customer if the customer is unwilling to try something new, or due to the size of the company at hand, it’s simply impossible to rollout and demo a new product in their environment?  This is a problem I’m looking to answer.  And it’s a question supply-chain related companies need to figure out as well.  Being dominated by slow-moving, expensive 800-pound gorillas isn’t doing their organization (or the industry!) any justice, they need to internally think of ways they can “test” disruptor like chasm crossing solutions at the same time, to keep their current vendors honest and innovating.  Stay tuned! :-)

-

Inventory vs. Stock

In my entrepreneurial quest to redefine how shelf stock levels are managed, I'm coming into a rather interesting dilemma in choice of words to use in the English language.  Generally, I am using "stock" to define items on a shelf for sale and "inventory" for items that will be for sale, but are not yet customer facing (ie... in the stockroom!?!, on a truck being delivered to a store, etc.).


As an example, if something is "out-of'stock" what does that mean to you?  According to its general definition, it means the store no longer has that item available for sale.  However, what is it called when the customer facing shelf is empty with the item you want to buy but the stock room is full of that item?  In the this article about Walmart's inability to keep its shelves full with goods, they refer to it as "out-of-stocks".  You see the confusion?  They have goods in the back stockroom, but the goods are not on the shelves for sale.  Do those of you in retail have different words for these two issues, because I'm not able to find a clear separation between them.  I've seen somebody refer to missing items on shelves as "stock gaps" but I don't see it being used anywhere else.

For the solution I'm working on, I'm only concerned with fixing the gap that the customer sees.  "Stock gaps" or "out of stocks" or whatever you want to call them, is what I'm trying to fix.  I am not (yet) trying to make my own inventory management system, as there are a plethora already out there (albeit most of them are horrid and have poor usability and data analytics).  So, in the meantime, I'm focusing on stock levels, not inventory levels, if that makes any sense at all.

In the VMI world, the two words stock and inventory are almost used interchangeably, making it even more confusing and even more difficult for me to articulate the problem I'm trying to solve.  Maybe the specific words or meanings exist and I just don't know them, if so, I'd like to hear them so I can use the proper words in describing what I'm trying to solve. Anybody?

Rebooting the Blog - Hello Again! ;-)

Well hello again, it has been a while since my last post :-) I've been enjoying life so much that I've not thought much about posting. However, summer is ending and I'm self-inflicting some new misery on myself by developing some new software to deal with a little problem that always bugs me: empty shelves.  Not just any old shelves, but I mean shelves that should have things on them, usually things that I want, and they don't. Being empty in the age of Big Data (current leading trend word in the logistics world, slightly ahead "in the Cloud") is simply unacceptable although understandable: Big Data is basically dependent on a slow, analytic process of trending future market events.

Data collection this way almost never happens in real time (usually in scripted collections during off-peak hours), and this is why it may take a day, 2 days, or even more for your favorite goodies to reappear back on the shelves.  Even systems that work in "real-time" don't work in real-time.  Some more agile systems (usually in smaller stores with more agile POS systems) don't collect the data until an item is sold.  What if you remove the last item off of a shelf and then keep shopping for another hour?  A few more people will miss getting what they want and the store will lose another sale.


How can this be solved then?  Simple: By tracking product movements at the shelf-level.  This type of tech has been on the radar of big players like Walmart for years, betting on RFID to help do it, but because of continued RFID tag costs and the extensive labor needed to implement and maintain, it hasn't come to fruition. Thus, stores like Walmart openly say that they have a 90-95% in-stock level.  More so, it seems the items aren't out-of-stock, they're just sitting in the stock room.  In Walmart's case, that 5-10% "out of stock gap" is worth billions alone.  Hmm.

Anyway, back to me. :P  I'm making some simple, agile software that will send alerts when stock is getting low and/or empty, so stock people know exactly where and what to re-stock.  I'm currently targeting VMI vendors, so they get an alert when to re-stock the shelves in the buyer's location (or can keep pressure on the buyer to keep their goodies stocked).  It'll be a good performance management tool to measure a product's popularity (time/dates they move off shelf, location, etc..), how fast the buyer re-stocks (if they're responsible) or if the vendor is responsible it will help them organize their supply-chain/human resources, on a real-time basis, in order to keep their goods on shelves for sale.

So the next time you go shopping at any FMCG store, see how many stock gaps you can find and then see how long it takes for them to be filled. You'll be amazed.