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.