Category Archives: Best Practices

Seven Easy Mistakes Source-to-Pay Tech Vendors Can Avoid

A few weeks ago we wrote about Five Easy Mistakes Source-to-Pay Tech Buyers Can Avoid in their effort to procure a fit-for-purpose technology solution to help them with their current challenges because the wrong solution can often be worse than having no solution at all.

However, and this is one thing the doctor knows very well, it’s not just buyers that make mistakes. Vendors do too. Lots of them. Lots more than they’ll care to admit, and these mistakes cost them time, money, sleep, and, sometimes, satisfied customers — which is ultimately the most important thing as satisfied customers will renew software subscriptions indefinitely (while unsatisfied customers will try to end the subscription as soon as possible).

Especially newer vendors, and especially those that haven’t built and/or run a company in our space before. And while some mistakes will be unavoidable (innovation doesn’t happen the first time, some things can only be learned the hard way, etc.), most aren’t. (In fact, the vast majority aren’t.) Usually all that is needed is research and insight, which can often be obtained by overworked founders without enough time by engaging the right advisor*.

So, to help these vendors understand overlooked areas where they are likely making mistakes, and where they should at least get an independent review, so that they can bring you better solutions, we’re bringing to them (and you, so you ask the right questions when considering their solution) the most common mistakes the doctor has seen over and over (and over) in his long career as an (independent) industry analyst, blogger, technical solution reviewer, consultant, researcher, CTO, etc.

Lack of market understanding and the real needs of their potential market

The first time the doctor talks to a new company, either for an introduction, review, or due diligence, one of the first things he hears (or will ask if he doesn’t), is why the founders started this company. And the answer he gets the most by far, so much so that he’s lost count of how many times he’s heard it and struggles to point to significant companies where he didn’t, is because XYZ didn’t do this function we needed to be efficient so we figured there was an opportunity. This would be a perfectly logical response if:

  • XYZ was a company/product that was designed to serve the function the founders were trying to address
  • there weren’t already two dozen products out there that addressed the function already and, at the baseline, did the same thing; literally, the same thing

This becomes especially prevalent during every M&A frenzy where a PE firm decides they need a company that does X, like (accounts) payable(s) during the last frenzy (exacerbated by COVID when PE firms realized/decided that business needed to be conducted entirely online, and decided they all need a virtual collaboration and online payment solution in their network). And the doctor doesn’t want to tell you how many times he heard payments company X was started because bill.com or quickbooks didn’t do basic accounts payable functionality or how few (read: almost none) didn’t do any real research which, in just a few hours, would have uncovered two dozen plus companies with payables capability the founders were sure didn’t exist, and the real opportunity was only in differentiation, specific country/regulatory support, or price-point (as there weren’t a lot of solutions at an affordable price point for smaller mid-size businesses until a few years ago). And even worse, many of these founders thought analysts and potential buyers should be super impressed that they essentially re-invented the software process wheel for a particular function for the twenty-forth time.

So, dear vendor, before you go to market, do your research (or contract someone who can do it properly for you)! And if you don’t understand your real value, contract an analyst that can identify it for you. The market is fickle, unforgiving, and easily swayed by a better presentation (even when from a competitor with lesser technology). Given that the knowledge and resources are out there, there’s no reason NOT to get it right.

Lack of competitive landscape knowledge and the real needs going unserved overall or at an affordable price-point for their target market

Building on our last point, it’s not just knowing what’s out there and what it does, but where your competition is strong and weak, what markets they are going after, what markets you should be going after based on your relative strengths and weaknesses, and what price point that market can easily afford and buy within a reasonable length sales cycle.

the doctor realizes this can be very time consuming, but this is where an implementation consultant or the right analyst can be extremely valuable, as they can quickly provide you with this information based on publicly available knowledge on currently released products based on demos and product reviews they have done, (feedback from) implementations they have been associated with, and (feedback from) integrations that they (or consultants they work with) needed to do, and buyers. A good analyst can do this without sharing any roadmap or non-public details on not-yet released capabilities, and should do that as roadmap and un-released capabilities might never be released, and is not something you should be basing your direction on.

Not knowing your true capitalization needs pre-profitability

While we should applaud companies that can bootstrap, and provide a standing ovation to companies that can raise angel / VC capital early to accelerate development, we should ONLY do so if they make an effort to understand their true cost of development, how long it’s really going to take to make that first sale, how long after that until they will make enough sales to support the minimum headcount they will need to sell and support those customers, and how much cash it’s going to take to get them there and raise it, or at least pre-negotiate follow on raises/loans to get there after the first investment.

Too many good companies fail because

  • they don’t take the time to estimate the true cost
  • they do, but don’t stick to their guns and when the investors say “final offer” at 70% of the estimated amount, they say “we’ll make it work”

And they try. They make a valiant effort. And as money dwindles, they put in 80 hour work weeks, developing more, faster. They amp-up cold-calling, content generation, reach outs, etc. They make their most heroic efforts. But all for naught. You can rush development, but you can’t rush a sales cycle. People need to realize they need a solution, do their research, qualify you, get a budget, go out to RFP, follow an archaic corporate process, and, then, hopefully, they can buy your product. If you’re lucky, you’re entering the process after they get the budget, but then you are fighting against a favoured “incumbent” that they plan to buy from (once they eliminate you), but usually it’s before, which means, on average, you are waiting six months for them to get a budget in the next cycle. If you’re a few months away from closing the doors, that doesn’t help you.

So if you can’t get what you need, don’t start. We all know entrepreneurship sounds great. We all know it’s a great experience to have on your resume. But it’s stupid to start something you know has no chance of succeeding. After all, there’s always another opportunity out there where you stand a chance of success. (And that’s it, even if you have enough in a typical case scenario, pandemics can happen, disasters can happen, markets can shift, or a better solution can be released halfway through your development by someone else that had the idea before you and is currently developing it in stealth mode with double your funding and a marketing budget out of the gate.) So, dear vendor, wait until have you a true chance. Otherwise, you’re wasting your contribution and letting down your early adopters when you close your doors (and that hurts us all when they lose faith in smaller companies and go back to ERP).

Overvaluing the tech (and AI)

A good tool is worth good money, and a great tool is worth great money. And if the great tool significantly increases efficiency, identifies meaningful cost avoidance, and delivers a 5X ROI, such a tool can be worth hundreds of thousands (or even millions of dollars if it is used by hundreds, or thousands, of users globally). But good and great is relative to what it does, how many people in the business it’s used by, the value it is delivering, and, ultimately, the budget the business class you are targeting can afford to pay based on the first three factors.

Tech for the sake of tech, while cool, has no value beyond being cool. Even if you have a lot of actual “AI” baked in (and let’s face it, if you do, the “AI” is only solving a very focussed, niche, problem), it’s still valueless unless it delivers value. It doesn’t matter how long you took to build it, how much it cost you (which can be a very poor measure because if you didn’t have a good team, overpaid that team, didn’t have the product or goal well designed when you started, p!ss3d hundreds of thousands away on Class A office space and big parties, it might have cost you tens of millions to build something a smarter, more focussed, cost conscious team could have built for two million), or how unique it is — in business, it needs value.

And before you try to sell it, you need to understand that value from a customer’s viewpoint, otherwise you’re going to have quite a challenge and customers who would otherwise jump on something fairly priced will not buy it even when it could be the best solution for them. (It’s not what the competition is selling it for, it’s what it should be sold for … one of the reasons too many Procurement departments don’t have modern tech is that they can’t get the budget for software priced using traditional enterprise software pricing that only the F500s/G3000s can afford.)

Undervaluing the tech (and AI)

Again, a good tool is worth good money and a great tool is worth great money when it delivers the right efficiency gains, cost avoidance, and value to a business that is losing a lot of money due to inefficiency and lack of insight.

Thus, you also have to be careful NOT to undervalue the tool or slash the price in an effort to get customers in the door quickly or sell to smaller organizations than you should be selling to, especially if the tech was expensive to build and no other organization could build it for less than 80% (or more) of what your organization invested into it and the cost of maintenance/continued development (due to advanced tech or unique capabilities or lots of integrations) is high. The reality is that once you set a price, that doesn’t become the floor, it becomes the ceiling, and if the price is not sustainable, you will go out of business and that will hurt not only you, but any early adopter that buys into you (and, again, that will hurt us all when they lose faith in smaller companies and go back to ERP).

Overestimating the DiY nature of the tech

Easy for you is not easy for a buyer. Remember, you’re the expert in the Tech — you built it, as well as an expert in the inefficiencies in the tech that came before — that’s why you built it, and an expert in the workflows that work well — that’s how you built it. You have the deep knowledge of the tech, the deep knowledge of the best practices, and the deep knowledge to know when a problem is best addressed by the tool, and when it’s not, and how out-of-the-box the support is, and how much has to be customized.

On the other hand, your potential client might be spending most of their time in Gmail and Excel, have never used the previous tool, and have no knowledge of current best practices. The customer may need training on the best practices, the workflows, and the tech, as well as a large reference library to remind themselves on how to use the tool if certain aspects of the process are not done very often (like once a month at most).

If services are needed, customers are not going to respond well to software only, or believe a low-cost when they know they will need the services. Understand the balance, present it appropriately, and sell it appropriately.

Misunderstanding the average customer capability & TQ

Building on the above, in addition to not overestimating the DiY nature of the tech, you should not misunderstand the average customer capability and the Technical Quotient of your target market. As we noted above, not all Procurement departments are advanced in the tech they have access to, and not all Procurement Professionals are adept with / used to modern tech. One has to remember that, for the longest time, Procurement was literally the island of misfit toys, and their understanding of technology and technology-enabled best practices was literally non-existent (as they typically didn’t use technology beyond the fax machine).

Even today, they may not be familiar with much more than basic consumer software for searching, e-reading, e-commerce, email, and gaming. Customized, deep, enterprise software may not be in their experience or repertoire.

Alternatively, if you are selling to a risk management or data analytics departments at big companies, they may have hired data scientists with deep training in mathematics and computer science used to not only using difficult mathematical (like Matlab and Octave) and analytics platforms (Qlik and Tableau), but building their own using open source analytics and data science platforms (like SciKit and Dataiku).

Know your audience and what they are capable of.

Failing to put the relationship first

In consumer software, it’s a transaction. But in enterprise software, it’s a relationship that you need to build, support, and adapt with. If the customer wants a transaction, they’ll use mass-market user-subscription based software or shareware. They’re going to you because they need services and support from a software provider that are experts in the technology and the process, can help them achieve their goals, and will keep the SaaS platform relevant.

* (HINT! HINT! STARTUPS/BEST-OF-BREEDS, STOP ASSUMING YOU KNOW IT ALL AND CAN DO IT ALL IN HOUSE! YOU CAN’T! YOU DON’T HAVE THE BUDGET FOR A FULL TIME EXPERT IN EVERY AREA. BUT YOU CAN OFTEN GET AWAY WITH PART TIME/SHORT TERM CONSULTING / ADVISORY. SO JUST DO IT!)

It Doesn’t Matter Where You Start, You End with BoB in Analytics!

In a recent article, we asked in the battle of Suite vs. BoB (Best-of-Breed), which do you choose, and ended up with the answer of neither, but potentially both, because, as indicated in our article we asked in our post on Where’s the Procurement Management Platform, you need a true platform (that enables the creation of a true source-to-pay plus ecosystem for the various workflows and processes that need to be managed).

As a result, we indicated you could start where you wanted, provided:

  • you could conceivably manage it,
  • the vendor offers, and publicly publishes, a complete Open API, and
  • the vendor offers the necessary quick-start services.

(And for even more details on each of these requirements, stay tuned for our upcoming article on how it doesn’t matter where you start, you end with BoB in SXM).

But where do you end up? For some Procurement Practitioners, it depends on:

  • the module,
  • the organization’s biggest need for workflow/process management, and
  • the organization’s biggest savings/cost avoidance/value creation opportunities.

(And again, we’ll have even more details in our upcoming article on how you end with BoB in SXM for more details.)

But for Analytics, like SXM, you will end at BoB for analytics as no suite equals the best in class (BiC) (spend) analytics solutions (even if they are built in BiC technologies for generic analytics like Qlik or Tableau) as the true BoB spend analysis solutions (which are fewer and further between than you would expect) are leagues beyond them.

Moreover, for Analytics, you should start with BiC, even if the suite has a pre-packaged solution that’s pretty good, enough to get going, more than your fledgeling analysts are likely to be able to handle in the first year, and appears to be offering the module cheap as an add on to everything else they are selling you. Why?

Lots and lots of reasons. Here are five to get you started:

  • Top X Opportunities: Suites will only show you your top 10 categories, top 10 suppliers, top unmanaged tail categories, etc. No guarantee that these primitive, canned, analysis will be YOUR biggest opportunities. BoB will come with hundreds of built-in analytics, considerably more customization capability, and the power to find opportunities that pre-built suites and dashboards will never give you.
  • Better Classification: Suites will do a decent classification, usually through their black box AI (trained on billions and trillions), but even if they get to 95%, it won’t be great, it won’t be manageable, and it won’t be customizable to your organization’s need. BoB, when it uses AI, will use it to create rules, that can be corrected and overridden, that you can customize to your specific taxonometric needs for optimized Procurement (and no standard industry classification is worth its weight in protactinium), usually starting with an out-of-the-box taxonomy customized to your industry using the vendor’s experience and community knowledge.
  • Better Analytics: many of these tools have a lot more capability in terms of report construction, dimension derivation, metric support, integrated data science, etc. etc. etc.
  • Better UX: while UX is completely subjective, and as per a (previous/upcoming) rant, is not something an analyst should be scoring and advising you on (as the best UX is the one that works best for you), in general, the probability is very high that you will find these BoB tools more customizeable in workflow and configuration, more logical in workflow, and much easier to use (if this wasn’t the case, no one would buy these tools and the vendors would have closed their [virtual] doors a long time ago)
  • Beyond Analytics: most BoB solutions will have integrated opportunity selection and project/savings tracking, performance/throughput/project metric support, and/or risk-based analytics. The value of analytics is continually overlooked because the “Savings” is identified in the sourcing event, captured in the contract, and realized in Procurement, and no one wants to acknowledge the opportunity would not even have been identified without analytics.

And, finally, why not get used to using a best-in-class tool from the get-go so you don’t have to relearn a new tool when you max out the capabilities of the suite solution and are ready for the next level? Especially when, as you get better and better at analytics and dive deeper and deeper into categories, you can improve the taxonometric mappings, track all the opportunities you identify (and your progress), do what-if analysis when the mood strikes, and get productive in a tool that will do [much, much] more for you in the long run?

So, while you might select a suite SIM module as a foundation for your supplier data store when you need to start centralizing supplier data somewhere for your sourcing projects and procurement buys (which is where your organization has determined it needs to start its S2P journey), when you’re ready for analytics, just go straight to BoB. (And if the C-Suite wants to see reports in the fancy suite, buy the basic reporting package and let them use the basic dashboards. And if the suite supports custom dashboards, then pump the appropriate analytics back in as reporting data. Get good with best-in-class analytics from the go with the best solution you can.)

Suite vs BoB. Which Do You Choose?

Neither!

But you need something. And there is no other option (yet). So are you doomed?

That depends. But first, let’s talk review the Primary Pros and Cons of each.

SUITE
BoB
PRO

  • one vendor relationship to manage
  • modular integration out of the box
  • consistent UX (or it’s not really a suite)
  • pre-implemented with major ERPs
  • the primary module offered by the vendor is truly Best in Class and considerably beyond the average suite capability
  • implementation is typically vendor supported, along with some integration services
  • low (subscription) cost out of the gate, pay as you need
  • today’s BoB comes with full, complete Open APIs to build your own ecosystem
CON

  • likely that only one or two modules are Best-of-Breed (BoB)
  • implementation and integration services are likely third party
  • high cost out of the gate
  • traditionally a closed ecosystem
  • multiple vendor relationships to manage
  • limited integrations out of the box to other modules you will need
  • inconsistent UX across the modules
  • limited to no ERP/MRP support in many modules

In other words, many of the weaknesses of the suites are the strengths of BoB and vice versa. But you want the strengths of both and the weaknesses of neither, even though that doesn’t exist today as no vendor does everything well, nor can they because they would need to be experts in everything. (So unless a vendor hired all the experts, and became a monopoly [and we generally agree monopolies are bad], no vendor could even come close.) Even if a vendor did hire all the experts of today, and build everything out to the best of those experts’ capabilities, they’d soon become an unaffordable mega-suite (and then still not be best in breed in anything because once they built what the experts they hired envisioned, there would be a new generation of experts they still wouldn’t have employed with new, innovative, possibly revolutionary, ideas).

So what do you do? Well, the answer is, as we pointed out in our post that asked where’s the Procurement Management Platform, acquire a platform that is designed to support data-centric end-point integrations for specific processes and organizational needs as this will allow you to select the right module for each task, configure the right procurement workflows, integrate new, even previously unthought of, modules with the Open API, and even support intake and supply chain platform integration.

But, as we noted, there’s no platform. So, unfortunately, you have to assemble your own. But at least today you can. A decade ago there were no options to do this, so either you bought a suite, and lived with it, or you bought best of breed and did extensive work to glue them together in a grit, spit, & a whole lot of duct tape situation (that would take about 69 months).

But today, all of the new best of breed applications are being built from the ground up with complete Open APIs and the newer suites are also offering you APIs to easily get data in and out as well. (Not so much on the workflow configuration / function execution front, but that’s not necessary.) [But please note that an App Store or Marketplace is not an Open API, it’s a closed ecosystem limiting you in what third party add-ons you can select.]

So you can theoretically start with the right instance of a BoB or a Suite as your base and build out the right platform over time, depending on your needs today, and how fast you can digest a new module. If you already have one or more first generation modules, you have the understanding of what these modules do and how to use them and can likely digest new versions of those modules pretty quickly, so you could start with that many modules plus one. If you have no modern S2P modules, then, as we indicated many, many times in our very long Source-to-Pay series, you need to pick a module that represents your most immediate need, start with it, and start to grow your platform from it.

The 39 Steps … err … The 39 Clues … err … The 39 Part Series to Help You Figure Out Where to Start with Source-to-Pay

Figuring out where to start is not easy, and often never where the majority of vendors or consultants say you should start. They’ll have great reasons for their recommendations, which will typically be true, but they will be the subset of reasons that most benefits them (as it will sell their solution), and not necessarily the subset of reasons that most benefits you now. While you will likely need every module there is in the long run, you can often only start with one or two, and you need to focus on what’s the greatest ROI now to prove the investment and help you acquire funds to get more capability later, when you are ready for it. But figuring out how much you can handle, what the greatest needs are, and the necessary starting points aren’t easy, and that’s why SI dove into this topic, with arguments and explanations and module overviews, both broader and deeper than any analyst firm or blogger has done before. Enjoy!

Introductory Posts:
Part 1: Where Do You Start?
Part 2: Where Should You Start?
Part 3: You Start with …
Part 4: e-Procurement, and Here’s Why.

e-Procurement
Part 5: Defining an e-Procurement Baseline
Part 6: There are Barriers to Selecting an e-Procurement Solution (and they are not what you think)
Part 7: Over 70 e-Procurement Companies to Check Out

Interlude 1
Part 8: What Comes Next?

Spend Analysis
Part 9: Time for Spend Analysis
Part 10: What Do You Need for A Spend Analysis Baseline, I
Part 11: What Do You Need for A Spend Analysis Baseline, II
Part 12: Over 40 Spend Analysis Vendors to Check Out

Interlude 2
Part 13: But I Can’t Touch the Sacred Cows!
(including Over 20 SaaS, 10 Legal, and 5 Marketing Spend Management / Analysis Companies to Check Out)
Part 14: Do Not Stop At Spend Analysis!

Supplier Management
Part 15: Supplier Management is a CORNED QUIP Mash
Part 16: Supplier Management A-Side
Part 17: Supplier Management B-Side
Part 18: Supplier Management C-Side
Part 19: Supplier Management D-Side
Part 20: Over 90 Supplier Management Companies to Check Out

Contract Management
Part 21: Time for Contract Management
Part 22: Contract Management is a NAG: Let’s Start with Negotiation
Part 23: Contract Management is a NAG: Let’s Continue with [Contract]Analytics
Part 24: Contract Management is a NAG: Let’s End with [Contract] Governance
Part 25: Over 80 Contract Management Vendors to Check Out

e-Sourcing
Part 26: Time for e-Sourcing
Part 27: Breaking Down the ORA of Sourcing Starting With RFX
Part 28: Breaking Down the ORA of Sourcing Continuing with e-Auctions
Part 29: Breaking Down the ORA of Sourcing Ending with [Strategic Sourcing Decision] Optimization
Part 30: Over 75 e-Sourcing Vendors to Check Out!

Invoice-to-Pay (I2P):
Part 31: Time for Invoice-to-Pay
Part 32: Breaking Down the Invoice-to-Pay Core
Part 33: Over 75 Invoice-to-Pay Companies to Check Out

Orchestration:
Part 34: How Do I Orchestrate Everything?
Part 35: Do I Intake, Manage, or Orchestrate?
Part 36: Over 20 Intake, [Procurement] [Project] Management, and/or Orchestration Companies to Check Out
Part 37: Investigating Intake By Diving In to the Details
Part 38: Prettying Up the Project with Procurement Project Management
Part 39: Deobfuscating the Orchestration and Fitting it All Together

Per Year, How Much Should You Outlay for ADVANCED Source to Pay? 250K to 500K, MAX!!!

That’s right! Continuing last week’s post, we are again putting a stake in the ground on a real, actual, number! (With similar caveats, of course, but still, a real number!)

Why? Because, at least in North America, the one question everyone asks but no one wants to answer, is,

how much for that product on the SaaS cloud
the one with the advanced software
how much for that product on the SaaS cloud
I do hope that software’s priced fair!

Most vendors, especially in the enterprise software space, want to get as much as possible (as failing to do so, especially if they are public or owned by a PE Firm with a tight timeline to enhanced profitability, gets them a “bad” rating), and, thus, obscure their (true) pricing. Their (big) analyst clients want them to get as much as possible (as they all dream of the day they get that Million-Dollar PO from a vendor in exchange for simply keeping the vendor at the top of the charts). Clients who think they got a deal don’t want you to underpay (and then have their renewal prices hiked up as the vendor seeks to maintain it’s profit margins) … and clients who think they’ve overpaid don’t want to tell you. And when some of the bigger vendors won’t even talk to you unless they think you’re good for seven (7) figures (i.e. One Million Dollars) a year or more, you might be tempted to think good (DIY) suites are out of your grasp.

However, as per our last installment, they’re not! And, if you’re smart, they can be quite affordable (especially for baseline end-to-end functionality with some advanced functionality sprinkled here and there) and lead to not just an identified, but realized, ROI in a short time frame.

But sometimes the base is not enough! What if you need advanced features such as:

  • strategic sourcing decision optimization (SSDO)
  • enhanced analytics with market intelligence (commodity pricing, GPO/anonymized community pricing), ESG data, project tracking
  • supplier development with orchestration, network management, discovery, enablement, etc.
  • CLM with analytics or enhanced authoring with augmented intelligence
  • I2P with smart OCR/Free-Form Processing and partial m-way match

These, and other advanced features, are going to pump up the price. How much? It varies. For the list above,

  • the most advanced commercial solvers, which most of the SSDO offerings are built on, charge 5K+/month for their solver to be embedded in a third party application, and that’s one of the reasons this software is not cheap (and the other is that these models require extremely skilled and experienced PhDs to build and deploy; but considering it is the only application that, when you’re ready, will consistently identify 10%+ savings on categories that have never been optimized, it can be worth it)
  • you can get the most powerful analytics solution on the market for 2K/month, but if you want market intelligence, you’re either going with a company that has a large enough install base to build that (and paying a lot more for the company to collate, anonymize, and offer that) or multiple third party market feeds; this will cost you another 3K to 5K a month (but you don’t understand your should cost without this data, and can’t identify the true opportunities in some categories without this data, so it can be worth it)
  • networks seem easy enough (all the big vendors have one), but you need a lot of suppliers, and true networks are multi-tier (meaning every supplier is a buyer in a sub-network), orchestration requires a lot of different data of a lot of different types and sometimes requires complex graph algorithms to get right, discovery isn’t easy if you need specific capabilities and not just commodity products, and enablement, well, as you can tell if you go back and review the CORNED QUIP mash of vendors, there really aren’t that many that do true enablement for the supplier
  • core semantic tech seems pretty cheap with a lot of open source models, but well tuned and well trained semantic tech on appropriate data is not (because training it on social media garbage produces the electronic equivalent of hazardous waste as output, as per a piror/upcoming article), so you’re going to pay for this, especially if you want technology finely tuned to analyzing your contracts, auto-building suggested templates appropriate for your business, guiding you on where legal focus needs to be (due to low confidence or ambiguity), etc.
  • if the invoice comes in as a PO-flip or using an EDI/XML standard, any platform can process that efficiently and cheaply; but if you’re tying to process PDFs, even if a supplier sticks to a template, that’s work; you not only have to train models, but build customized models to each invoice type; that’s a lot of manpower on the vendor’s part to build those for you (or on the vendor’s part to build tools you can use to define those templates for the software using WSIWYG low-code or no-code interfaces)

The reality is that any advanced application you need/want is going to triple to quintuple the price you’re paying for that module, depending on how advanced the functionality is, how much expertise is needed to build and maintain it, and how much the vendor itself has to pay in SaaS/license fees to third parties for advanced models/capabilities it is building off of or appropriate, reliable, human vetted data sources. What was a 2K module is now going to be 6K to 10K a month (or, if you have to augment what you have with a third party application, an additional 6K to 10K a month).

Not cheap, but when advanced technology, properly applied on the right categories / problems in the right circumstances can deliver 2X to 3X the cost reductions, it becomes very affordable. For example, let’s say you have a 100M components category in electronics and all a well-constructed RFP and analytics manages to find is a 3% cost reduction opportunity. That’s 3M, if captured, but what if there’s really a 6% opportunity through non-obvious re-allocations when logistics, tariffs, FTZs, and volume breaks are taken into account. That’s 6M, or an extra 3M. If the SSDO module cost you an extra 60K per year, even if used ONLY on that one category, that’s a 50X return! Similarly, if advanced contracted analytics with augmented intelligence allowed your legal team to dynamically build up clause libraries and templates on the fly, reducing contract preparation time by 70% on every category, that’s going to greatly increase your sourcing cycle velocity, allowing you to get through more events, and compound cost reduction opportunities. The manpower savings will likely be 10X the extra 60K a year.

And so on. The value is there, but, as per our S2P series, only if you have a need for it AND are ready for it. (That’s why we suggested implementing one module at a time, and starting with baseline capability so you can get your spend under management, get the data for a proper spend analysis, determine where the true opportunities are, determine what you need to address the true opportunities, and then upgrade to the advanced offerings of the vendor (or augment with third party modules).

But, at the end of the day, based on our knowledge of what provider offerings with best-in-class opportunities start at, average multiples over baseline, and just how much a mid-size organization will need across source to pay, we’re putting a stake in the ground that an advanced S2P offering with advanced capabilities across all 6 core modules should top out at 500K, and, in fact, we’re betting that an average organization, which will only need advanced capabilities in half the modules, should only need to pay 240K to 300K a year — or the cost of 2 FTEs, which is peanuts compared to the efficiency improvements the organization will realize and the cost reductions they will see. Even if a smaller organization (500M-ish in revenue with 250M-ish external spend that Procurement can influence) only gets 30% of their addressable spend under management (75M-ish) and only sees a reduction of 3%, that’s still 2.25M, which is 8X+ the cost, and definitely worth it!

However, all the same caveats from our last installment hold.

[01] You are a true mid-market company, which we’re defining as a company more-or-less between 500 Million and One Billion in Revenues and an addressable spend of 250 Million to 500 Million (as you can’t address payroll, government controlled utilities, mortgages/long term lease rates, etc.).

[02] You have an average sized procurement team of under 30 people. (In a 2019 Benchmark, average organizations had 33.5 Procurement personnel per 1 Billion in revenue.)

[03] You’re doing an average number of projects per year for those people (and likely maxing out at addressing 20% to 30% of the addressable spend per year).

[04] As you have (next to) nothing in terms of modern source-to-pay technology, your primary focus is the baseline capabilities (as defined in our Source-to-Pay series). You might want a few of the more advanced capabilities, but right now, getting the baseline (which will likely provide 80% of the value by allowing you to get all of your processes, and costs, under control) is the primary goal.

[05] This does not include integration costs, training costs beyond access to all of the online-training materials/virtual academy, and the implementation costs are limited to flicking the switch to activate the license and any necessary setup configuration. (Unless you are buying an advanced module, in which case the vendor will include more setup, configuration, and additional data load support.)

[06] The sales cycle is mostly virtual (web demos, video conference meetings, etc.). You won’t get to meet the sales rep in person more than once during the sales cycle (and that’s only if you’re buying a mini-suite or multi-year deal; these vendors stay affordable by keeping their costs down, and multiple on-site demos and meetings do nothing but drive up overhead and costs).

[07] Most vendors will help you with the initial data load (provided you are loading data from a supported system in a supported format), but refreshes will typically not be included in the ongoing support, which will mainly be limited to online help and workaround support for identified bugs while the bugs are being fixed.

[08] With the exception of some market intelligence from anonymized customer data or free public data sources, this will typically not include any data enrichment offerings also offered by the vendor, especially if those data enrichments are coming from third parties, but these will be pre-integrated and you will only pay the third party fee if you want to turn them on.

But what if you’re a borderline/true multi-national enterprise? Or a small company / borderline “small” mid-market? What should you pay then?

To be continued.