Don’t get me wrong: I’ve got nothing against pigeonholes. Pigeonholes work fine in situations where everyone knows exactly what the right solution should look like.
Is picking supply chain planning (SCP) software such a situation? I think you’d agree that it isn’t. Not by a long shot.
Take programming languages. Recently I’ve been coming across RFPs for SCP software that require vendors to identify the programming language the software is written in. In subsequent conversations, it’s not unusual to be told that new equals good. Old is bad.
As a geek myself, I understand the desire to be right there on the bleeding edge. However when it comes to business-critical applications, there are sound reasons for preferring a more conservative approach.
The advantages of using time-tested, reliable building blocks are well known. Stability is one of them, and stability is absolutely crucial in mission-critical applications. It’s no coincidence that the avionics software behind the space shuttle program was written in HAL/S, a language developed in 1989 as an extension of PL/1 (which, in turn, dates from 1964!).
So does the programming language an SCP application is written in matter?
Yes, it does. Absolutely. But not to the buyer of that software.
Quintiq software is written in C++ and Java. Quintiq applications are configured using a proprietary language (Quill) that was developed specifically for creating planning and scheduling applications. Quill is, arguably, the optimal language for creating such applications quickly and reliably. Yet no RFP I’ve ever seen has had a check box for Quill – and that’s fine. Programming languages and IT buzzwords are fundamentally irrelevant. The more useful questions have to do with what a company actually needs to accomplish with the software.
For example, if an IT department needs to know whether an application has a failover strategy with a guarantee of uptime, why not ask that question instead of creating a check box based on the latest buzzword? As many a cautionary fairy tale suggests, getting exactly what you asked for can be the last thing you need.
Almost by definition, software that exceeds expectations cannot be pigeonholed. Question: Are those boxes in your RFPs letting the eagles through?