Feb 16

The unofficial Assortment Planning maturity model

A client recently asked if there was an assortment planning maturity model.  I was pretty sure that someone out there would have published one.  Maybe it was my poor google search skills, but I could not find one.

I decided to create one.

So what is a Maturity Model?

A maturity model helps assess a clients capability in a number of areas and points out the areas for improvements.  It can provide a roadmap of increasing capabilities for the roll out of a process or a solution for example.  A maturity model is an independent set of benchmarks.

Who creates this model?

The maturity model itself while having subjective elements should itself be objective.  It should be based on surveys or backed by strong evidence and or breadth of experience.  Usually, consultants have the breadth of experience or can carry out the surveys and hence they usually are the source of the models.

Who decides the current capability?

Either the consultant or the clients themselves can estimate current bucketization of capability.  Consultants usually can reliably estimate the current level of performance through techniques like interviews, comparison to competitors, reviewing existing data, and their deep understanding working with the client.

The clients themselves can self evaluate their level of performance using a questionnaire or their honest evaluation of the model.  In my view, the maturity model should be clear and have sufficient detail for any client to self assess their current performance level.

The unofficial Assortment Planning Maturity Model

Here is my attempt at the maturity model for Assortment Planning.  It is not derived from any systematic survey and is very subjective based mainly on my thoughts.  If it reeks of my limited understanding and experience of assortment planning at different retailers, that is because it that is exactly what it is.

I wanted to put it out there and improve it based on feedback.  I would appreciate any inputs and comments.

Here is the maturity model for assortment planning.  I liked the format used by AT Kearney for their other maturity models and decided to use something similar.

Feb 16

Top 5 takeaways from NRF16

 The 5 things that stand out for me from this years NRF are
  1. Stores are becoming more about shopper experience to maintain their relevance and also their symbiotic role in omni channel
  2. Increasing use robots for all things – both mundane (inventory counting) to experiential (interactive product information, size and fit suggestions)
  3. Ubiquitous sensors (beacons, wifi, cameras) and collection of real time customer movements in stores.  It is still TBD how these will affect retailer planning behavior but they are collecting a lot of information in the store for now
  4. Lots of customer analytics.  There are many ways retailers are using to get shoppers to opt-in.  Once they do, there is a lot of cool technology available to mine the information and market directly, in a very personal way to each shopper.  Interesting possibilities to directly influence retail planning …
  5. Not much innovation in the retail planning application space.  They are still behind in  using the best available analytics to help decision making. Same vendors, same old stuff.
Here is a great recap on NRF16 with good information.  Please watch the podcast at the top of the page.

May 14

Crawl scenario for Omni Channel – pre-requisites for Omni strategy in Retail

There are a number of reasons to consider omni channel retailing and most retailers are in the process to varying degrees. There are a number of white papers extolling the virtues and promise of Omni Channel Retailing. This post is not about why retailers should consider omni channel but what it will take to get there. The focus is on IT and back end support (both systems and people) to enable the execution required for Omni channel. There are various degrees of capabilities required to achieve the full potential of the omni vision that is being painted in Retail. This post is about the foundational capabilities that are prerequisites to start the crawl towards Omni Channel Retailing.

Common Item Definition (product hierarchy)

To present a common view of an item to a customer in all channels, it becomes essential to have a common product hierarchy between the brick and mortar and online channels. The organization of items into categories and classes and the organization of the items for presentation online need to be aligned. This in itself is a huge change/challenge to many retailers with strong online presence. Over time the different businesses have evolved to have either completely separate product hierarchies or have different branches within the hierarchy branching off at some level. In the absence of a common hierarchy and items, it becomes essential to have a Master Data Management system that can map items between the two channels. It is likely that items will be considered only for one channel or the other (or may be certain sizes are available only online for e.g.). Therefore, an additional qualifier of some kind (an attribute perhaps) will be needed to tag items for one or both channels. This will necessitate all planning and execution systems to be able to not only deal with the common hierarchy but account for the attribute — in planning logic or execution logic.

Handling returns

One key aspect of multi channel are returns. Returns can be made either back to the purchase location or to a different location. Returns will cause two problems — how to handle reversing the sale and what to do with the inventory. In addition, returns to different locations from the purchase location will cause the assortment at that location to break down. It is possible that item returned to a store was not in the original assortment for that store. When returns occur there are four possibilities to handle the returns 1. Ship them to the original purchase location 2. Put them on the shelf in the return location 3. Leave them in the back room of the return location 4. Ship them to a warehouse Options involving intra company shipping will incur shipping costs and increase the probability of damaging the merchandise before it is sold. Putting it on the shelf in the return store makes sense if the item was part of the original assortment but can cause problems if the item was not in the original assortment. Options to hold the inventory at the return location could lead to weird results. When returns are received, sales adjustments are posted back to the location of the original sale. But inventory is incremented at the return location. If there are large number of returns, this could cause the sales to be negative at the return location. In addition it is important to know the true demand at any location to be able to properly assort and plan for inventory. Properly adjusting sales and returns while accommodating the integrity of the stock ledger is crucial.

Merchandise locator capability

It becomes extremely important to know where inventory is available so that when a customer shows up at one of the channels, a quick search can be made across the enterprise locations for availability. This will help fulfill the customer order directly from where the product is current located — this could be a store or a warehouse.  The ability to search for specific inventory in all holding locations is a key capability.

Shipping capability

Not all locations have the ability to ship. There is training and certain capability required to be able to ship depending on the type of products that need to be shipped. There will be a need for inspection and efforts to restore the returns to a new product state before they can be sent to another customer.  Developing Ship from Store or intact, ship from any location is a capability that will be required – especially if returns are not moved back to the warehouse.

Negative sales? Book-keeping impact? Incentives?

If the internal structure of the organization is that there are two separate teams – one managing brick and mortar stores and another managing online store — then there will be a proliferation of sales measures. Each team (depending on how they are incented) will demand different sales and inventory measures. Stores teams will not want online bought returns to effect their sales numbers. Who do you give the credit for the sale to? What happens when the product is returned to a different channel? Sales can be reversed but what about inventory? Stock ledger and its association of inventory to a location means that there could be locations with negative sales to balance on hands with sales. Very soon, there will be a need to have a number of inventory measures that adjust/compensate for the cross channel returns. Different measures of sales will also be required to be to understand the true demand at any location for better Assortment Planning in the future. It is important to have a process in place that covers systems, planning, measurements and compensation to deal with the challenges that will be presented. I would to hear from you on the above issues and any other that you will add to the list as pre-requisites to think about before you getting to amazing opportunities that Omni channel retailing will afford.

Feb 14

Staples have it right !

Staples, the office superstore, announced that they are abandoning Responsive Design and moving towards building different applications for mobile vs the web. See story here.

I think they made the right decision.

Responsive design is a concept that allows for the development of a web application in a such way that it can be rendered on multiple devices accounting for the screen sizes of those devices without having to build a special version for each device. The basic idea is to think of a regular website to be made up of a number of columns and rows like a grid. Content is then assigned to a multiple of these columns and rows. During the rendering of the page, CSS media queries are used to identify the device and knowing how many columns will fit on the screen, CSS is used to render the page appropriately by wrapping columns of content and stacking them one above the other. This makes it possible for the user to scroll through the entire page in a vertical arrangement on a smartphone for instance compared to seeing it arranged across on the desktop.

Historically, designers have approached the web first and mobile as secondary.  The buzz word associated with this is Graceful Degradation.  The content from the desktop browser is first gracefully degraded to fit the tablet and then further adjusted to fit the smartphone.  Mobile first argues for the concept of Progressive Enhancement.  Think smartphone first and then build up a full fledged desktop browser.  Mobile first strategy to put it simply accounts for some of the constraints of a smart phone like avoiding adobe flash, smarter use of bandwidth e.g. avoiding big image files, avoiding triggers like hover to activate something, avoiding concepts like right-click, double-click and so on.

The key reason to adopt the Responsive web design methodology is speed to market. It is hard enough getting one product ready for public use through the software development lifecycle. Imagine getting three versions of the software done. The thinking is that the team can focus on the intent of the app while accounting for certain constraints of mobile device and allow technology to make that app consumable on a number of devices.

When combined with Mobile First, Responsive design is a reasonable way to develop moderns applications. 

The need for speed exists for both startups and established companies. This was the approach we took after much deliberation in my previous company.

There are more people accessing application and sites on their mobile devices than desktops now.  It is extremely important to provide the experience that is tailored for the device rather than just adapting the content to fit the device. How users typically use the device and what actions they are used to on the device must be factored into the design.  This is especially true if you are selling something through your app. The responsive design may still be fine for content distribution.

It is time to develop specifically for the device and not employ build once use everywhere mindset.  Whether you build Native applications or Web applications that run on the device is not that important as long as you are complying with user expectations and making the application easier to use on the device – living within the constraints but also making use of the richness of sensors and input capabilities (touch, camera, microphone for example) of modern devices.

The typical use of the Staples site is to buy something you are looking for. Making it easier to search, compare and buy on the smartphone is as important as making it easier to search and buy on the desktop via a browser. While the end goal is the same, the how you get there is very different on the two devices.

I think Staples has come to the right conclusion by putting customer first and making it easy for that customer rather than ease, time and cost of development.

Feb 14

Enterprise Planning Software – Weak links remain


465459020 d8a492a31f

Photo Credit: Darwin Bell via Compfight cc

In early 2010 as I was moving into a product manager role for a start-up company, I discussed the then current state of enterprise planning apps and their problems with someone who has spent a long time in retail planning and is someone I deeply respect and admire. My objective was to pick his brain to help design new planning solutions that addressed these problems from the beginning.

In that discussion, he identified four problems with Enterprise Software as it pertains to Planning in Retail.  I suspect that the same apply in general to Enterprise Applications across the board.

The four areas identified as weak links increase the risk of retail planning implementations failing and solutions not being adopted by the user community are Configurability, Scalability, Usability and Reporting. It has been four years since and I believe the weak links still remain and are as valid today as they were years ago.


Many systems require an army of people with very specialized skills to implement adding significantly to the cost.   Complexity comes from proprietary/closed systems and need to learn specific planning language to be able to configure the system.  The definition of configuration itself is very loose.  Some systems need you to be able to write scripts to “configure” the systems whereas others give you an IDE in which you can write the code to configure the system.

In evaluating the configurability of the system, questions like the following should be considered.

  • How many people and what skills are needed for the implementation?
  • How configurable is the solution?  Is the configuration through an interface, text files, etc?  What is the language using which the software is configured to meet the functional needs?
  • Does the vendor have to be involved in the configuration? Is there an ecosystem of third parties that can deploy the solution?
  • Is the technology and data storage proprietary?
  • Handling of software bugs – patches, upgrades and such
  • Can the tool be configured to meet all/most/some requirements?
  • What kind of skills does it take to maintain post deployment?


Retail problems are naturally big. The usual refrain from vendors is that their solutions scale linearly – meaning that you need to throw more resources at the problem as the problem size grows.  While this is technically true, I believe this is a cop-out. Product managers should own coming up with a solution to both the scalability and usability questions by better understanding the use cases and proper design and factoring of the workflows.  In evaluating the scalability of a solution being proposed, questions of the following nature should be considered.

  • How scalable is the application?  What are some of the largest deployments?
  • Special hardware required? Can it run on generic low-cost off the shelf hardware?  What hardware was used in the largest deployment?
  • How much data is moved back and forth?  If the user community is geographically distributed, do we have to consider virtualized environment (e.g. Citrix) solutions to improve response times?


The biggest competitor to a planning system is excel.  Planners love excel and it is the yardstick against which the performance of the tool is measured.  Usability is a huge impediment to tool adoption.  Almost all vendors have adopted an internal mandate (technology driven) to move towards a common UI platform across all applications.  These platforms were built for transaction environments and are misfits for the planning tasks.  Planning tasks are naturally data entry intensive and are usually entered in a grid of some kind that is a window into the multi-dimensional nature of the problem.  None of the Web UI widgets current being used meet the needs of a planning application.  Various vendors have made efforts that go to different lengths in trying to mimic excel like look and feel for the planning grid but have not been successful in replicating excel like responsiveness in Web UIs.

In evaluating the tool for usability questions like the following should be considered

  • Response times to planner actions – how long to make one edit and move to the next cell?
  • Is it web based, desktop? Are both a thick and thin client available?  Is the user experience in terms of responsiveness the same in both clients?
  • Is there a mobile client?  What capabilities are supported/not supported in the mobile client?
  • What are the typical response times to be expected in the context of specific planning tasks -e.g. opening a Department-season plan, or reforecasting for a quarter, saving the plan, etc
  • Support for planner productivity tasks like copy/paste, export/import from excel, mass updates, etc
  • Configurability of the user interface – both design time and at run time by the end user
  • Support for things like annotations like notes, comments, colors
  • Collaboration – can two people be in the same plan at the same time?  How does the tool support a planner and a buyer working together on a plan at the same time for example


Reporting is often overlooked in implementations but is extremely important.  Costs associated with reporting are typically high – often much more than the cost of the tool implementation itself. Moreover, it is a key part of user adoption and satisfaction with the new tool.

This includes questions like

  • What reports are available as part of the tool?  What aspects of the planning process are being addressed by these reports?
  • Is the data model open? Can any BI tool be used?
  • What capability natively exists in the tool? Is there a reporting solution built into the application or the platform?
  • Can the reports always reflect the status of the plan in real time? If there is latency, how much, what are the guidelines?
  • Can both formal (pixel perfect) reporting and ad-hoc reporting be supported?

After four years my recent experience shows that the problems remain.  Most vendors have focussed on internal mandates like common UI, common platform.  While this does reduce the internal costs for development and maintenance, it has done nothing to alleviate the concerns of usability and inevitable comparisons to the configurability and usability of excel that the retail planning community will make with any system.