How Do You Evaluate a Sourcing Suite?

Good question, and one that both customers and vendors are going to have to answer very, very soon. As per our post on What Makes a Sourcing Suite, a decade ago, it was pretty simple. If you had decent e-Negotiation support with some document management and reporting, you could claim a Sourcing suite. It might have been a bit of a stretch, but that was the accepted baseline. If you had contract management and some basic spend analysis, then you were best-of-breed. If you had basic project management or category guidance, you were awesome. And if you had optimization, you were a true market leader and way ahead of the pack (as even the majority of The Famed Hackett 8% weren’t there yet).

But that was then, and this is now. These days, if you are a vendor and you don’t have basic Source-to-Contract [S2C], which consists of decent spend analysis, extensive e-Negotiation (customizable RFX and e-Auction), and Contract Management, jacked up with Supplier Information Management, you’re not even a contender (and shouldn’t even get in the ring). Plus, given that many providers offer some project/workflow management, expert driven category guidance, bill of materials support for direct sourcing, [deep] contract analytics [which is not the same as contract management], deep SRM (Supplier Relationship Management, which goes far beyond 1st generation SIM and 2nd generation SPM), Contract/Award Performance Management, Compliance Management, Risk Evaluation and Management, and even true Optimization (as well as other non-core S2C related offerings that they expect to bring them market share), you need more than just a core to compete.

So how do you, as a customer, evaluate an offering? The answer is, on each and every product component that should be there, across every core and supplementary feature that is required and/or adds value. And yes, that’s a lot. But fortunately for you, Spend Matters and Sourcing Innovation have teamed up to help you. As you may know, with the departure of the anarchist (who has since ended up at Coupa as Thought Leader), the doctor took over Sourcing and Supplier Management as Consulting Analyst. But now that the medic is on-board and handling standard sourcing and supplier management as well as business / market analysis, the doctor is now Consulting Analyst for Advanced Supply Management Technologies, including Advanced Sourcing, and putting his PhD (in computer science) and technical chops to good use (putting vendors through the wringer on a regular basis — and, to this end, has co-authored 45 deep dive vendor reviews over the past year, which, if you’re counting, puts most analysts at the big boy firms to shame).

As part of this new Consulting Analyst role, the doctor will be leading the Solution Map efforts for Sourcing and Spend Analysis and co-leading the Solution Map efforts for Supplier Management (with the prophet) and Contract Management and Analytics (with the maverick), as these collectively cover advanced sourcing, advanced analytics of a traditional kind, advanced metrics and process management, and advanced analytics of a semantic kind. Sourcing Innovation and Spend Matters are in the process of finalizing the RFIs now, which will go out over the next week to leading vendors in these categories, and in July you’ll see multi-persona analyses of all the major vendors.

As with the Procurement Solution Maps, the core of the RFIs and the evaluation criteria will be made fully public, as well as the high-level analysis of each vendor across all relevant categories and functions for each of the covered areas. And you will have a robust, completely vendor independent, baseline to evaluate perspective vendors for inclusion in your technology RFIs going forward. And unlike the vendor created RFI templates that used to proliferate and give certain vendors an unfair advantage (as those vendors would always score high on their own feature-rich templates, whether or not the majority of the market needed those features), no vendor is going to have an edge here. First of all, no vendor does everything. Secondly, any vendor that rates themselves higher than a 3 (on a 5-point scale) on any function is gonna have some serious ‘splaining to do as a vendor can only truly innovate in a few areas (and deserve a 4), and there is only one best-in-class vendor against any function, and, thus, only one best-in-class vendor that can actually win business on that function alone (and deserve a 5). Since the doctor is known for being [the] ruthless [honey badger* of the space], these RFIs have been designed so that an average best-in-class vendor will score a 3 [rounded up]. The idea is to fairly evaluate each vendor and push the market forward. And while a slight majority of vendors will likely have been Spend Matters customers over the past year, the number of vendors that have had a relationship with SI over the past year will be around the 10% mark if all of the invited vendors participate, so there should be no doubt in your mind that these will be objective and independent weightings that you should be able to trust and use as a foundation for your evaluations.

So please encourage your potential vendors to participate when they get the RFIs and maybe even go so far as to tell them that you expect them to participate if they want to be considered in further technology buys from you. Because if they truly are a BoB solution, or approaching a BoB solution, if they vendor is not included in the first round, they will definitely be included in the second round.

*Youtube it. (Best video NSFW.)

Supply Management Technical Difficulty … Part VI

In this post we conclude our initial 7 part (that’s right, 7, because Part IV was so involved, we had to do 2 posts) series on supply management technical difficulty, focussing on the source to pay lifecycle. We did this because many vendors, with last generation technology, have been touting their own horn with a “market leading” offering that was market leading a decade ago, but, due to lack of innovation on their part, is now only average. Moreover, much of what used to be challenging in this space is now, in the words of the spend master, so easy a high school student with an Access database could do it, and that ain’t far from the truth. Unless the platform comes with an amazing user experience (and the reality is most don’t), a lot of basic functionality can be accomplished using open source technology and an Access database.

So far, we’ve covered the basics of sourcing, the basics of procurement, supplier management, spend analysis, and (invoice to) payment, and while each have their challenges, the true technical challenges are few and far between comparatively speaking. Today we are rounding out the series with the true, hidden, technical challenges that you don’t see. And there aren’t many of those either, but they are doozies.

Technical Challenge: Large-Scale Scalability

If you’re selling an application that is only going to be used, by a few dozen, and maybe a few hundred, users, scalability isn’t an issue. An average low-end server with eight cores, 64 GB of RAM, and a few TB of solid state storage should be more than enough to support this user base even if the application is shoddily coded by junior developers who cobbled most of it together cutting and pasting code from SourceForge.

But if we are talking about a true e-Procurement system that is going to be rolled out to everyone across a Global 3000 organization with the authority to make a requisition or spot buy, this will be tens of thousands of users, serviced by hundreds of Procurement professionals doing daily spot buys and MRO inventory management and dozens of strategic buyers and analysts looking for opportunities and conducting complex events using optimization and deep data mining, an average high end server is not going to do the trick. Multiple server instances are going to be needed, but they are all going to have to work off of the same data store, and a significant amount of this data is going to need to be accessed and updated in real time, so it’s not just a matter of replicating the database and allowing the users to go to town. While some data can be replicated for analysis, MRO data has to always be updated in real time to insure requisitions are filled from on-site inventory or warehouse inventory first. This requires a complex data management scheme, fifth degree normalized design, real-time clustering, and so on and so on and so on on the data side as well as intelligent request routing on the application side as you can’t route all requests evenly (as 10 inventory look up requests are a lot less processor intensive then the creation of 10 detailed category reports).

Technical Challenge: User Experience

While the creation of just about any modern user interface component is a piece of cake using modern language libraries, there’s a big difference between user interface and user experience. And the most slick user interface in the world is useless if the process it forces the user through is kludgy and cumbersome and takes three times as long to accomplish a simple task as it should. A great user experience is one that requests minimal input, involves minimal steps, and, most importantly, involves minimal time and effort on behalf of the user. It takes context into account, known information into account, organizational processes and (approval) rules into account, etc. and makes it so that a user only has to do as little as possible and is in and out of the application as fast as possible so that she can focus on her primary task. If she’s not a strategic buyer or a spend analyst, she shouldn’t be spending her days in the tool — she should be spending her days doing her job. This is what many applications miss. A truly good software tool is elegant. In our space, even today, many aren’t.

So, hopefully by now you have a good understanding of what is truly difficult and what you should be looking for when evaluating a tool. There is still an intense amount of complexity that needs to be overcome in a modern application, but any application that does not tackle the complexity outlined in this series is not truly modern. Keep this in mind and you’ll make great selections going forward.

Remember: Big Bang = Big Bang!

While the doctor was at Coupa Inspire, he heard a very scary message over and over again from Coupa customers during the CPO panel. It seems that even though it’s been over 20 years since the demise of Foxmeyer Drug, organizations are still pushing for big-bang supply chain re-vamp projects and advising Procurement to “wait for the ERP upgrade to [almost] complete and then select a new BoB solution to fill any gaps as it will be quicker and easier to do it all at once“! Gadzooks! Six of the 11 biggest supply chain disasters of all time (as chronicled by Supply Chain Digest) were directly, or indirectly, caused by a big-bang ERP project and the fiasco it created, including the ruination of Foxmeyer Drug that was a 5 Billion global company. Big bang projects almost always end in big bangs that wipe out entire divisions, markets, or global organizations. There is no excuse for them in this day and age and no organization, consulting or otherwise, should be pushing for them.

Fortunately for these customers (who were chosen because they were prime examples of successful Procurement organizations in the Coupa community who led the way), they didn’t listen to their organization and just did it. The beauty of a modern self-contained cloud-based solution like Coupa is that you don’t even need an ERP. You can just license an instance and go. This is what they did, and one organization, instead of waiting 18 months to get started, completed a global roll-out in 4 months and banked over 10M in savings before they would have even started product selection had they sided with their organization!

In other words, don’t go big bang unless you want to sabotage your organization (because you are a mole for, or taking kickbacks from, the competition) as the likely outcome is big bust. Just get going, one solution at a time, which you can integrate at the right time in a focussed project that is much more likely to succeed mostly on time and on budget as the project parameters will be better understood.

Supply Management Technical Difficulty … Part V

A lot of vendors will tell you a lot of what they do is so hard and took thousands of hours of development and that no one else could do it as good or as fast or as flexible when the reality is that much of what they do is easy, mostly available in open source, and can be replicated in modern Business Process Management (BPM) configuration toolkits in a matter of weeks.

So, to help you understand what’s truly hard and, in the spend master’s words, so easy a high school student with an Access database could do it, the doctor is going to bust out his technical chops that include a PhD in computer science (with deep expertise in algorithms, data structures, databases, big data, computational geometry, and optimization), experience in research / architect / technology officer industry roles, and cross-platform experience across pretty much all of the major OSs and implementation languages of choice. So far we’ve covered basic Sourcing, Procurement, Supplier Management, and Spend Analytics. Today we’re moving onto Payment, which, in e-Procurement, is usually part of Invoice-to-Pay.

Payment sounds pretty easy, as it’s just a matter of cutting a cheque, using a P-card, doing an ACH, or sending a wire, but is it? Mostly, but not entirely.

Technical Challenge: Automated Invoice Regulatory Compliance

Many countries have a lot of strict requirements when it comes to invoice acceptance, processing, and submission. And, generally speaking, they’re all different. Now, I bet you’re saying that there’s no technical challenge here — read the regulations, extract the requirements, define the workflow, implement it with one of a dozen different workflow tools. And you’re be right if that was true automated invoice regulatory compliance.

You see, the thing about regulations is that they are constantly changing. And if you’re supporting 100+ countries, in which many multi-nationals operate, that not only presents a challenge in workflow maintenance and redefinition, but also a challenge in even detecting when a regulation is about to change and when a workflow might need to be updated, or has changed (suddenly) and the workflow hasn’t been updated.

As much as one might need an invoice-to-pay solution that can adapt a workflow to changing requirements, one, especially if one is doing business in dozens of countries, needs a solution that can detect when a workflow needs to change and when invoices have to be halted as a result of a potential issue even more. And, of course, recommending the appropriate workflow updates based upon a semantic analysis of the new regulations.

In other words, if all you are being sold is a payment integration engine, which has existed for a decade, then you are not being sold anything modern or sophisticated.

Next up: the hidden elements.

Supply Management Technical Difficulty … Part IV.2

A lot of vendors will tell you a lot of what they do is so hard and took thousands of hours of development and that no one else could do it as good or as fast or as flexible when the reality is that much of what they do is easy, mostly available in open source, and can be replicated in modern Business Process Management (BPM) configuration toolkits in a matter of weeks. In this series we are tackling the suite of supply management applications and pointing out what is truly challenging and what is almost as easy as cut-and-paste.

In our first three posts we discussed basic sourcing, basic procurement, and supplier management where few technical challenges truly exist. Then, yesterday, we started a discussion of spend analysis, where there are deep technical challenges (that we discuss today), but also technical by-gones that vendors still perpetuate as challenges and stumpers that are not true challenges but are to many vendors who didn’t bother to spend the time it takes to hire a development team that can figure them out. Yesterday we discussed the by-gones and the first-stumper. Today, we discuss the second big stumper and the true challenges.

Technical Stumper: Multi-Cube

The majority of applications support one, and only one, cube. As SI has indicated again and again (and again and again), the power of spend analysis resides in the ability to quickly create a cube on a hunch, on any schema of interest, analyze the potential opportunity, throw it away, and continue until a new value opportunity is found. This also needs to be quick and easy, or the best opportunities will never be found.

But even today, many applications support ONE cube. And it makes absolutely no sense. Especially when all one has to do to create a new cube is just create a copy of the data in a set of temporary tables designed just for that and update the indexes. In modern databases, it’s easy to dynamically create a table, bulk copy data from an existing table to the new table, and then update the necessary index fields. The cube can be made semi-persistent by storing the definition in a set of meta-tables and associating it with the user (which is exactly how databases track tables anyway).

Apparently vendors are stumped on how easy this is, otherwise, the doctor is stumped as to why most vendors do not support such basic capability.

Technical Challenge: Real-time (Collaborative) Reclassification

This is a challenge. Considering that the reclassification of a data set to a new hierarchy or schema could require processing every record, and that many data sets will contain millions of transaction records, and modern processors can only do so many instructions per second, this will likely always be a challenge as big data gets bigger and bigger. As a result even the best algorithms can generally only handle a few million records on a high end PC or laptop in real time. And while you can always add more cores to a rack, there’s still a limit as to how many cores can be connected to an integrated memory bank through a high-speed bus … and as this is the key to high-speed data processing, even the best implementations will only be able to process so many transactions a second.

Of course, this doesn’t explain why some applications can re-process a million transactions in real time and some crash before you load 100,000. This is just bad coding. This might be a challenge, but it’s still one that should be handled as valiantly as possible.

Technical Challenge: Exploratory 3-D Visualization

There’s a reason that Nintendo, X-box, and PlayStation keep releasing new hardware. They need to support faster rendering as the generation of realistic 3-D graphics in real-time requires very powerful processing. And while there is no need to render realistic graphics in spend analysis, creating 3-D images that can be rotated in real-time, blown up, shrunk down, drilled into to create a new 3-D image, which can again be rotated, blown-up, shrunk, drilled into, etc. in real time is just as challenging. This is because you’re not just rendering a complex image (such as a solar system, 3-D heated terrain map, etc.) but also annotating it with derived metrics that require real-time calculation, storing the associated transactions for tabular pop-up, etc. — and we already discussed how hard it is to reclassify (and re-calculate derived metrics on) millions of transactions in real time.

Technical Challenge: Real-time Hybrid “AI”

First of all, while there is no such thing as “AI”, because machines are not intelligent, there is a such thing as “automated reasoning” as machines are great at executing programmed instructions using whatever logic system you give them, and while there is no such thing as “machine learning” as it requires true intelligence to learn, there is a such thing as an “adaptive algorithm” and the last few years have seen the development of some really good “adaptive algorithms” that employ the best “automated reasoning” techniques that can, with training, over time improve to the point where classification accuracy can (quickly) get to 95% or better. And the best can be pre-configured with domain models that can jump-start the classification process and often get up to 80% accuracy with no training on reasonably clean data.

But the way these algorithms typically work is that data is fed into a neural network or cluster-machine, the outputs compared to a domain model, and where the statistical-based technique fails to generate the right classification, the resulting score is analyzed and the statistical weights or boundaries of the cluster modified, and the network or cluster machine re-run until the classification accuracy reaches a maximum. But in reality, what needs to happen is that as users correct classifications in real-time when doing ad-hoc analysis in derived spend cubes, the domain models need to be modified and the techniques updated in real time, and the override mapping remembered until the classifier automatically classifies all similar future transactions correctly. This requires the implementation of leading edge “AI” (which should be called “AR”) that is seamlessly integrated with leading edge analytics.

In other words, while building any analytics application may have been a significant challenge last decade when the by-gones were still challenges and the stumpers required a significant amount of brain-power and coding to deal with, that’s not the case anymore. These days, the only real challenge is real-time reclassification, visualization, and reasoning on very large data sets … even with parallel processing, this is a challenge if a large number of records have to be reprocessed, re-indexed, and derived dimensions recalculated.

But, of course, the challenges, and lack of, don’t end with analytics. Stay tuned!