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.