Spend Matters on SCM: Data, Data Everywhere ...
This is part three of a three-part series.
Two days ago, we overviewed the key points that Jason "The Prophet" Bush, the Spend Master of Spend Matters, is making in his annual soapbox road tour, including his five -- new and improved -- predictions for the procurement world of tomorrow. Yesterday we discussed what it means if he's right. Today we focus on his response to my question that put him on the spot.
A few of the presentations at the recent 6th International Symposium on Supply Chain Management, sponsored by PMAC and the DeGroote School of Business at McMaster University, were about ERP implementations and how, done right they can save you time, money, and paper-based nightmares. But for every success story bloggers like Jason and I have ever heard, we can recount twice as many failures, including fiascos that have cost organizations hundreds of millions of dollars and put more than a couple out of business. (Some of the greatest supply chain failures of all time, including the collapse of more than one Billion dollar enterprise, can be blamed on bad ERP implementations.) So I had to ask, what's the right solution: ERP or Best-of-Breed?
But in yet another instance of blogger brilliance when pinned to the wall, he managed to sidestep the question entirely and point out, consistent with a couple of points in his presentation, that it's not about the application ... it's about the information ... and the future will be applications that enable the acquisition, access, and and application of information, which makes the ERP vs. BoB question irrelevant. But what are you to do if you're an average organization with ...
Data, data, every where
And all the tables burst
Data, data, every where
It can not get much worse
... and a Bloomberg terminal for sourcing is still a thing from an uncertain future?
You need an answer. And you need it today. Because you might not be around tomorrow if you make the wrong decision today.
So what's the answer? Hard to say ... it still largely depends on your specific organizational needs, and that's likely why the question was sidestepped. However, I believe it's still possible to provide some starting guidance which will at least lead you to ask the right questions and, if you are unable to come up with the right answers, call in some expert advice (and yes, this is one area where the doctor can help you).
So what does the doctor recommend?
It depends on whether or not you already have an ERP. If you do, you keep the core and use it for what's it good for -- data warehousing and transactional processing. Most ERPs were designed to be transactional powerhouses ... and that's probably why so few are good at supporting the best of breed strategic applications of today ... and they should be used simply as the transaction processing engines they are. Then, you find compatible best-of-breed applications to support your strategic sourcing and decision making functions, such as true spend analysis, decision optimization, and demand forecasting, and utilize their strategic strengths to complement the tactical strengths of the ERP backbone. You also audit your ERP implementation and make sure that you don't buy, or, in many cases, maintain, modules you aren't using and that you don't buy more licenses until you are sure you are using all the licenses you have. (The average organization has roughly 30% more user licenses than users actually using the system. Add this to the maintenance cost of blindly paying support for modules that were thrown in as part of a "package deal" that you never use, and the costs add up quickly ... and significantly. And if you don't believe me, ask Vinnie.)
If you don't have an ERP, you figure out whether you can get away with a good data store and a functional ecosystem of best-of-breed products that can be integrated rather seamlessly using standard XML. In other words, can you start with a solid, well documented, standard schema relational database, like Oracle, and then build your perfect supply chain support platform on top of it by integrating the right sourcing, procurement, and supply chain management solutions? I say solid, standard, and well-documented because it clarifies why SAP is rarely, if ever, the doctor's first recommendation. Oracle exposes it's schema. As a rule, SAP does not. This is very important if you need to do custom development, as it's easier to develop off of a standard, documented, relational database whose base schema rarely changes from version to version as compared to a system where the only data access is through APIs, which are constantly evolving, and where the schema is subject to change at any time. This might be meaningless to you as a user, but as a former enterprise system architect, it's VERY meaningful. Does this mean I'd recommend Oracle iProcurement over SAP SRM? Not necessarily. It's a good transaction engine, and it has some good features, but it all boils down to whether it supports your processes and best-practices. If it does, use iProcurement. If not, use the underlying high-performance Oracle RDB and transaction engine and stick a best-of-breed solution, like Vinimaya, on top of it.
And make sure to consult an expert with supply chain and supply chain technology expertise before finalizing your solution. Sometimes your first-choice products will play nice together, sometimes they won't, and sometimes your second-choice products have some benefits that magnify when they are used in conjunction and will give you a better overall solution. The reality is, today, the only thing I can tell you for sure is that there is no one-size-fits-all solution and no vendor, SAP and Oracle included, that can meet your every need. (That being said, there are some independent consultants, not tied to ay product, that can help you piece together the right solution for you and you should take advantage of them.)