Software is not the end but means to an end

As we move into our third year of operations, this post is all about reflecting on where we came from and lessons learned, that we would like to share with you. Today we would like to talk about supply chain planning software and key challenges facing the industry. Supply chain planning software got its own identity in the nineties and has been around since then. ​Look at the three distinct waves in this industry as shown below. The promises spanning three decades are, at best, under-delivered. ​If planning software truly delivered the promise then why are 93% of the users still dependent on spreadsheets? ​

​Death by Features, Functionality and Dashboards

Early in our careers, say about two decades ago, we experienced something called "death by features and functionality". It meant that every single software feature, functionality, advanced math, personal or customer 'wish-list' should somehow be packaged into software. More features was (and still is) perceived as the better software in supply chain planning. The end result was clear - complicated software with all the bells and whistles of which 80% were never used!. Additionally, in recent times, we have seen BI solutions posing as supply chain planning solutions. Very simply put: Dashboards/Charts/Visualization ≠ Supply chain planning. It is a small part and output of planning but that's not planning.

Packaged supply chain planning software is a myth
​
We also observed that no two supply chain planning processes are the same. They may look similar but a close look tells us that every process and associated data has its own personality that is sculpted by its creators and users. Yes, there's demand planning, supply planning, inventory planning, S&OP in every company but naming is as far as the similarity goes. Solution providers have long tried and failed with the 'packaged software' approach i.e. let's build and customers will come. Alas, "packaged" or "plug N' play" supply chain planning software is a myth. Software providers cannot build every solution from scratch nor can they have a packaged solution. There needs to be a middle ground.

Oops...that was a demo.

As many solution providers start with packaged software approach and load it with 'wishful thinking' features, when it comes to implementation they need to customize to their client needs.  It is a nightmare for their software development team but for the client, it's worse. Here is a very typical scenario: Client wanted A, and the demo had it, but it was a demo and that feature/functionality would be released after one year (or never). So let's implement B which is not want the client wants but it is a feature/functionality that is available right now however that requires changes to the client's business process. And the story goes on...

Show me the value

Most implementations models are 'time & materials'. This industry has gone far too long with this business model of consultants sitting at the client's site for months, quarters and years billing their hours trying to implement something. Where is the incentive to get anything done?. Implementations are stretched from months to quarters to years for a good reason. Also, 3rd party implementations seldom result in good outcomes. Implementation partners do not have the leverage on the technology and its future roadmap which results in finger pointing, long implementations and money down the drain. 
​
By the time anything is implemented, the business, people, processes have changed and the cycle continues or its back to spreadsheets. Software becomes shelf-ware. The prevalent business model in the industry is not incentivized to deliver value.

Why supply chain planning software keeps under-delivering?

Here are few basic DOs and DONTs:

• Don't start with a list of features and functionality but rather define the key pain points in your business process (e.g. data retrieval/processing is too long or complex what-if scenarios need to be analyzed rapidly or simply automating the existing manual spreadsheet work)​

• Don't fall for polished software demos. They are exactly as they call it - a 'Demo'. See the safe harbor statement below by Oracle after a demo of their S&OP solution. The focus should be on the adaptability of the platform to your business requirements and the speed based on the software technology architecture.  ​ 

• Avoid 'death by features' i.e. the software solution needs to be smart enough to automate, simplify or eliminate non-value add workflows. A software solution should not simply replicate your spreadsheet workflows in an online tool through a complex set of features that requires a training manual and weeks of user-training.

• Use 'building blocks' approach to get to the final solution. This ensures faster, better ROI and happy users. (The planning team needs a car but along with the promise of a car they would be very happy with a scooter today if it gets them home sooner tonight!)

Implementation Methodology

• Pay only for what is needed and when it is needed. The implementation should be a 'fixed fee' model based on the scope. This approach would de-risk both, client and the solution provider, and create right incentives to deliver value.

• Last but not the least, even if the solution and business model is solid, its implementation would define success or failure. It is not what you negotiate but what you manage. Ask the questions - Who will implement the solution? Would it be the software vendor team or a 3rd party? If it is the vendor team, is anyone from the implementation/R&D function of that vendor in that room or part of the requirements and proposal discussion? What is the experience of the implementation team?

Supply chain planning is an old problem that requires new thinking on applying technology to solve it. For too long the industry has thought of software as a silver bullet but software is not the end, it is means to an end.