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.

Stepwise Logistics Management is Problem Plagued (LMI Part 3)

In our last article, we noted that Logistics Management, in addition to being costly and risky, is not an easy ordeal. You have a lot of steps to execute in an ordered fashion, which today typically requires at least five different loosely integrated (mostly standalone) modules in a big enterprise Operations Planning solution or, more typically, a number of standalone solutions which only support, at most, endpoint data integration where the outputs of one phase can be fed into another.

While this works, there are a number of issues with using separate systems for each step, including, but not limited to:

  • Inefficiency: entering and leaving multiple systems is timely, especially if 3 or 4 steps in you realize you made a mistake and have to go back to the beginning
  • Opaqueness: you only have visibility into the output of the previous step at any time; e.g. when a carrier asks if you can use a different truck size or pallet size, and you have no details on why you calculated a certain pallet and truck size as optimal, you have no idea and have to go back to the packaging system and do the calculations all over again;
  • Cost Bloat: due to limited visibility into data and models of other systems, each step has to introduce a safety margin, leading to ever increasing safety margins; e.g. the order adds a few extra units; the packaging adds a few extra boxes of units to create some give in the packing calculations; the quote adds an extra pallet or two to make sure enough space is quoted; the contract keeps this extra space; and so on … especially since there are usually different team members, each an expert in the different systems, doing each step
  • Hidden Risks: neither of these systems are good at identifying and tracking risks, and if not propagated to the TMS or a separate risk management system, they will stay buried until they materialize (with no mitigations ready to address them)
  • No Closed Loop Feedback: tracking, learning from, and adjusting future plans and predictions vs. actuals is the only way to improve transportation planning / logistics management

Not to mention the major issues present in most of the current piece-meal solutions being used.

  • Order Management solutions tend to be dependent on the MRP and very limited in terms of how far out they can accurately plan, then defaulting to (often) decades old forecasting models; they also can’t provide any insight into the packaging requirements
  • Package Management solutions depend on accurate inputs from the order management solution and the ERP/MRP, and can only compute packaging sizes, packages per standard pallet, and standard pallets per standard containers; no real issues here, but because they don’t connect to freight (quote) management systems, the users don’t often know the best package options to choose and the best configurations to consider
  • Quote Management solutions collect the quotes, allow comparisons, and allow some to be marked as contract (for a timeframe); no real issues here either, except the fact that because they aren’t a TMS, a buyer can’t understand the full cost associated with selecting a carrier or a lane for a particular shipment, and may make suboptimal decisions
  • Transportation Management Systems plan the transportation needs a few months out (at most; most traditional systems are very limited in how far ahead they can plan due to architecture, calculation requirements, constantly changing requirements as demand shifts and issues arise, and the need to regularly start the entire planning chain over again), create the orders, distribute them, collect the shipment notifications and estimated delivery dates, and maybe track updates; not bad, but not enough anymore
  • Financial Planning Systems are usually either modules of larger operational cash-flow planning solutions and limited in transportation specific cost planning, or sub-modules of TMS, and limited in overall financial planning and cost analysis capability

In other words, the logistics solutions created in the age of logistics (when logistics was also more predictable when natural disasters were few and far between, global pandemics were more theory than reality, global political stability was greater, and so on), while great at the time, are no longer sufficient for optimal supply chain management in the modern world.

What we need is a Total Logistics Management Solution.

A Brief Introduction to the Components of Logistics Management (LMI Part 2)

In our last article we noted that Logistics Management is something that many procurement professionals overlook because most larger organizations have a separate logistics department, but it’s something that they shouldn’t because they won’t understand the true cost, the true delivery times, or the true risk of their sourcing decisions, which may, because of this, turn out to be more costly, more risky, and considerably less efficient than they expect.

In addition to being costly and risky, Logistics Management is not an easy ordeal. In order to manage logistics effectively, you need to:

  1. determine what you need and when you need it
  2. determine how to package it and how much room the packaging takes, and this requires the organization to calculate
    1. how many packages you can get on a pallet
    2. how many pallets you can get in a truck / container / rail car
    3. how many trucks / containers / rail cars you need
  3. determine the viable lanes for shipping from the suppliers to your warehouses and get quotes
  4. select the providers and plan the transport
  5. accurately cost the orders, shipments, and tariffs to make sure you have enough cash on hand to meet your obligations when your invoices come due

This typically requires five different systems, and/or modules. Namely a(n):

OM/FS: Order Management/Forecasting System
This integrates with your MRP system, looks at the production plan, looks at the inventory level, and determines the order quantities needed by week for the next X weeks based on how far out the production plan goes (which, in most systems, typically isn’t that far out, maybe a few months) and then uses the forecasting capabilities to project out a few months ahead of the average transportation time. It will also allow a user to override plans and projections, override default suppliers and carriers if there are options, and calculate any ramifications. And any related functions the organization needs around order management and forecasting. (We’re not going to go deep on any particular capability in this article.)

PMS: Package Management System
Logistics management is not as simple as calculating an order and contracting a carrier. You have to know how much space you will need for the shipment, which will dictate how many trucks, rail cars, or containers. That will depend on how many packaged units you can fit in the space, and that’s often more than a simple volume calculation, as you have to fit parts to boxes, boxes to pallets, and pallets to containers/cars. This requires more sophisticated volume and weight calculations than one would expect, which are not easy to do in a spreadsheet. Plus, if you have multiple options, you have to figure out which is best to minimize your shipping requirements.

FQMS: Freight Quote Management System
Once you know what you need, where it’s coming from, where it’s going to, how it’s going to be packaged, what kind of transport you need, and how many units (trucks, rail cars, containers, etc.), you need to find, and contract, a carrier. But the first step is to get inclusive quotes (costs per mile, fuel surcharges, handling charges, etc.) from carriers, compare and analyze them, contract one or more carriers, and then mark their quotes as contract rates, and others as quotes, but not guarantees.

TMS: Transportation Management System
Once you’ve determined your shipping needs, selected a carrier, and contracted a quote, you need to manage the transportation. You need to provide all the appropriate information to the carrier, get the pickup dates and expected delivery dates, receive and track updates, manage any issues that arise or reroutings that need to be done, identify any delays that will cause production or customer delivery risks and determine resolutions, and so on.

FPS: Financial Planning System (Cash Flow Planning)
Finally, you need to track all of the current and projected costs, and changes, so that you can manage your cash-flow and have the necessary cash when the invoices come in.

In other words, Logistics Planning and Management is currently quite an involved process that requires quite a few modules and process steps to do (reasonably) well.

A Brief Introduction to the Importance of Logistics Management (LMI Part 1)

Logistics Management is something that many procurement professionals overlook because most larger organizations have a separate logistics department. Logistics should not be separated from the whole of supply chain operations management because not only can you not compute a total cost of acquisition (which is the minimum calculation you should do during sourcing) without a solid understanding of the true logistics cost, but underperforming logistics teams costs an organization much more than Procurement thinks (and way more than the Logistic Division’s estimate of getting a product from point A to point B).

Logistics represents a significant part of Cost of Goods Sold (COGS). It’s more than just the transportation costs quoted by the carriers in each multi-modal leg in the journey. (Truck to the outbound port, ocean freight to the inbound port, rail to the regional distribution center, truck to your warehouse.) For an average shipment, costs also include:

  • (special) packaging (sur)charges
  • fuel surcharges
  • surcharges
  • loading/unloading/cross-docking fees
  • interim storage/inventory fees
  • insurance
  • loss (damage or theft)
  • tariffs (dictated by route)
  • losses from unplanned delays
    (loss of sales due to stock-outs; losses from production downtime due to missing parts)
  • inventory fees due to overstock

And all of these costs are variable depending on:

  • the route
    determines legs, length of legs, costs for the leg, tariffs, etc.
  • the carrier
    determines rates, surcharges, risk/OTD expectation, etc.
  • the transportation timings
    determines intermediate inventory needs, risk of delay, risk of loss, etc.

And that’s just the cost considerations. You also have to consider delivery times, inaccurate estimates, improper performance measurements and lack of end-to-end visibility here can lead to:

  • part shortages
    which can cause production line slowdowns/shutdowns
  • stockouts
    which can lead to lost sales
  • inventory build-up
    if too many shipments come in too fast, and this drives up costs and can cause space constraints for other orders
  • unexpected cost increases
    if you have to expedite

And then there’s the risk factors. Depending on the route, and the carrier, you could have increased risk of:

  • natural disaster
  • geopolitical disruption
  • port slowdown or shutdown
  • provider bankruptcy
  • cost increase due to currency exchange fluctuations, new regulations coming into effect, etc.

In other words, you should not overlook the implications of logistics cost to serve and service levels when sourcing. You don’t necessarily have to lock in the contracts, but if you already have contracts locked in, only have a few options, or need to use certain routes or carriers to keep costs down, you will need to ensure that the suppliers, and locations, you select are congruent with any options you may be restricted to. And if you are unrestricted, then you should know the assumptions you are making when sourcing, capture them, and pass them on to the logistics team at order/fulfillment time to make sure that the logistics team is planning and contracting appropriately.

Per Year, How Much Should You Outlay for a Multi-National Enterprise Source to Pay? Good Question! Poor Answer. 500K+

Whereas we were willing and able to put a real, actual, number, or a very tight range, for mid-markets, the situation gets more tricky for a multi-national enterprise with 1 Billion + in Revenue.

Why? Aren’t they using the same advanced tech as a large mid-market, except using advanced capabilities across the board? And, because of this, shouldn’t it max out at 500K? Well, yes, but there are additional considerations you don’t have in the mid-market.

[01] If you are using a lot of decision optimization, semantic analysis, network modelling, etc., then you are using a lot of computing power — that’s driving up the vendors’ hosting costs well beyond the mid-market. Now, at some point, it maxes out at costs on a dedicated machine basis, but it’s still higher.

[02] As a true multi-national enterprise, you are going to need a vendor that has extensive multi-lingual and multi-currency support in the product AND at the help desk when suppliers and third parties have difficulties using the solution to bid, provide information, submit invoices, etc. And while it’s only a one-time cost for a a suite built for true internationalization to add another language pack and currency, an enterprise that offers support in those languages usually has to add more headcount to support that language, and that adds cost.

[03] You’re not only going to have a larger Procurement team using it, but you’re going to have a decentralized global team with a lot more differentiation in capability, with a lot less people capable of being full DIY. They’re going to need more support on a regular basis, and you’re going to need to contract for this up front.

[04] You’re going to need a lot more data. You’re going to be subject to a lot more regulations and you’re going to need to collect, and verify, a lot of data on your partners and suppliers. A LOT of data. You’re going to need a number of data subscriptions on business identifiers, (beneficial) owners, and credit scores for verification that they aren’t on any embargo lists, involved in any legal suits, and acceptable to your insurance provider. Then you need data on their human/workers’ rights practices, compliance, and third party assessments for those countries with laws enforcing compliance and putting you responsible for your supply chain actions. Then you need Carbon/GHG data for countries with reporting requirements or limits. Then you need other ESG/Risk data for your own internal risk assessments. And so on. These subscriptions add up.

So even though the suite itself should still be within that 250K to 500K per year range, when you add up the additional support needs, additional data needs, and dedicated computing power needs, you’re going to double or triple that cost. That being said, before you sign on the dotted line, especially if the quote gets close to 7 figures (one million), you need to do your expected ROI calculation. If you’re not going to see at least a 5X ROI a year on a conservative estimate, with an expected ROI of 7X to 10X a year by years 2 and 3, you need to step back and decide if you need all the functionality, all of the support, and all of the data subscriptions you’re asking for / being quoted, and if so, if you’ve included the right vendors in your RFX for (a) technology solution(s). The reality is that you should NOT be paying a million plus annually for an extended S2P suite unless you’re getting the ROI.

Also, be sure to build that model in-house or engage a third party that is not a reseller or implementer of the suite you’re considering. First of all, their savings averages are not guaranteed to be applicable to your situation. Secondly, their manpower requirements, and reduction, averages might not be appropriate for your business either. Thirdly, because they often build their savings model as a rollup of savings models across the different modules / functions, many of these suite models often end-up double-counting resource time or savings numbers by way of their design.

(Please note our choice of wording here — “end up“. Usually the provider or consulting organization is not trying to deceive you, and they often don’t realize that their roll-up model is double counting. What we’ve seen happen is they take the best calculators they have access to (through consultant or analyst relationships) in each area they are selling in the suite — sourcing, SXM, CLM, etc. — and then roll them up. But they fail to understand that the attributions of a savings percentage in each model always favours the solution/module being sold, which may also assume some baseline functionality of another module. As a result, especially since the savings opportunity often changes based on what technologies are available and applied together, all the estimates will be “Best Case” for the selected modules, and when you add those up across five/six modules, you will sometimes get a total “Best Case” that is as much as double what is actually reasonable. For example, you can have a category where if you just applied spend analysis on the RFX you could identify 6% savings, if you just applied supplier risk profiling to the RFX and eliminated the high risk suppliers and then took the low bids you could identify 4% savings, and if you just applied strategic sourcing decision optimization you could get 10%, but if you applied all three you only achieved 9% (since optimization finds everything spend analysis finds, but the risk assessment resulted in the manual elimination of a high risk supplier that optimization didn’t catch, lowering the initially identified savings opportunity). Rolling up 3 separate models, it would produce a 20% savings opportunity when it was in fact 9%. Now, in other situations, the rollup could be worse than the actual of combining all three technologies, i.e. the RFX is projected to only identify 3% on it’s own and the negotiation module to save 3% on overheads, but the application of both to a targeted subset of suppliers which are deemed to be most willing to negotiate based on volume could allow for an 8% reduction. But overall, these rollups don’t average out and usually over-count.)

[Also, most vendors feel they have to do it this way since most buyers don’t buy all the modules and they don’t have enough average savings data across the application of all advanced modules to all categories to have reliable numbers. So you really need to do your own models based on your own situation and come up with realistic estimates.]

Depending on your current state of affairs, current market conditions, and technologies available that your organization is actually capable of utilizing, that could be an overall, estimated, cost reduction of 3% against all spend expected to be put through the platform in the first year, or it could be 5% (or more, or less). Even 3% is good if you’re spending 1 Billion a year, 500 Million is addressable, and you think you can address 20% of that, or 100 Million, the first year. That’s an estimated savings of 3 Million, and if your year 1 cost was 750K, that’s reasonable with an ROI of 4X, especially if you think increased efficiency will come in year 2 with familiarity, that you will address 200 Million in year 2, and increases the estimated savings percentage to 4%, which would be 8 Million savings in year 2, and an 8X multiple even if you needed to add more data subscriptions and support, bringing the total solution cost up to One Million.

Probably not the answer you wanted, since the mid-market looks to be getting off cheap, but they are also spending less as an organization, addressing less of that spend, dealing with fewer volume or consolidation opportunities, fewer resources to tackle the mid-size categories, and losing on the tail since they can’t effectively manage it beyond catalogs, budgets, and hoping the 3-bids and a buy are fair (and not rigged through collusion). They might pay less for their S2P solution suite, but their total savings potential is also (considerably) less and, thus, their typical ROI is limited compared to yours.

But, well chosen, at least you’ll get an open, modern, usable solution for One Million dollars per annum — not something you can say in all areas of enterprise software.