Why Your Standard Sourcing Solution Doesn’t Work For Direct

Too many of you have been there. You sign that seven figure deal for that end-to-end Source-to-Pay suite, spend another seven figures and 18 months integrating with the ERP, PLM, AP, BI and existing Legal CR solutions, and then try to source your first NPI project natively only to … fail. Why is that?

They just weren’t built for direct.

And it’s not just something you can add in later. If the platform wasn’t designed from the ground up for direct sourcing, there’s zero chance it will ever do a decent job at it. (And, FYI, the majority of the S2P suites the big analyst firms are drooling over in their annual quadrants and waves started out as simple indirect Sourcing or Procurement tools.) People who don’t understand the nature of software don’t get this, but software has to be constructed like a building. You might hear vendors and techies throw around MVC model, which stands for Model-View-Controller, when they talk about how new and well architected their solution is, but that just means it’s built in a maintainable web-friendly way for what, and only what, it was initially designed to do.

It all comes down to the data model and the software architecture of the controller, and neither can be a black box. The data model has to be designed from the ground up to support bill of materials and direct sourcing and procurement data requirements. The controller has to provide the infrastructure to support the complexity of the application that is required. For those who don’t understand software, I like to put it this way. If you pour the foundation for a two story house, and buy wooden beams for all of your structure and supports, you can’t build a 10 story apartment building. You need a foundation for an apartment building and steel and concrete supports. (Even though you can theoretically build a 10-story structure on a two-story foundation if you have the right steel and supports, it won’t be stable. The slightest tremor on the Richter scale [which might not even be detectable by a human] or a strong wind will send it crashing down.) You need both. And just like you can’t replace the foundation under a building or replace the entire support structure in real life, you can’t do the same in code. You have to rebuild, usually from scratch.

So why weren’t they built for direct? Well, there are a number of reasons (besides they wanted to get a product to market fast and/or just weren’t smart enough to build a direct sourcing solution). They include:

  1. direct material sourcing is hard
  2. substitution is not guaranteed
  3. demand aggregation is not straight forward
  4. delivery time guarantees and on-time arrival is significantly more important

To understand these, and learn about the rest of the reasons the majority of sourcing solutions were not built for direct, dive into Standard Sourcing Technology Solutions Don’t Work for Direct – Part One and Standard Sourcing Technology Solutions Don’t Work for Direct – Part 2 over on Supply Chain Matters.