In part 3 we exemplified our definition of B2B 3.0, simply defined as the first generation of technology that actually puts business users on the same footing as consumers, as the first generation of B2B technology that adds real content, community, and open-connectivity to B2B platforms through cutting edge technology like:

• web services
• intelligent agents
• meta-search
• real-time collaboration
• semantic technology
• mashups
• analytics and
• workflow

But we didn’t explicitly map these technologies to the different Supply Management technologies or workflows that you as a Supply Management professional have to use on a daily basis. That’s why Part 4 tackled some of the necessary, but not necessarily sufficient, requirements of a modern Sourcing platform (defined as the platform that is typically used from the time a need is identified until the contract is signed, covering the “planning” and “sourcing” phases of the strategic sourcing execution lifecycle if you will) and Part 5 tacked some of the necessary, but not necessarily sufficient, requirements of a modern Procurement platform (defined as the platform that is used from the time the first order needs to be placed until the time the last order is placed, received, paid for, and gone out of warranty). But it’s not Sourcing or Procurement, … It’s Sourcing And Procurement, and the organization not only needs an integrated Source-to-Pay process but a foundation for that process (and the execution that comes beyond). That foundation is Category Management, and today’s post is going to outline some key requirements that modern Source-to-Pay suites should possess if they are going to be considered B2B 3.0 platforms that support modern category management.

As with our last post, this list is not all inclusive, and simply possessing all of this capabilities will not make a suite B2B 3.0 (because it’s not a suite, it’s just the Source-to-Pay component of Category Management), but if these requirements are missing, then the suite will not make the cut. In mathematical terms, these are necessary, but not sufficient, conditions.

In order to avoid confusion, we are going to define a Source-to-Pay category management platform from a technology perspective as one that, possibly by way of multiple (seamlessly integrated) best-of-breed platforms, supports end-to-end category management throughout the Source-to-Pay process and enables key aspects of the execution phase of the strategic sourcing lifecycle. (For more details, download the free e-book written by the doctor and sponsored by Trade Extensions, registration required.)

From a historical perspective, the primary “capabilities”, organized into one or more modules, that such a platform would possess would include all of the capabilities described in the last two posts plus centralized master data management, collaboration portals for internal and external collaboration, and centralized risk and compliance management, among other advanced capabilities.

From this viewpoint, some key capabilities that such a suite must possess include:

• multidimensional category taxonomies

  Sauron may have forged the one-ring, and hackers may be searching for the one ping, but there is no single one-size fits all taxonometric wellspring and there will never be – not even for a single organization; sometimes you’ll want to bury installation services under IT, sometimes you’ll want to bury them under services, and sometimes you’ll want to analyze them with contingent labour and BPO spend … and so on … the system must allow for a detailed multi-dimensional taxonomy that allows every piece of spend to be tagged with all relevant identifiers (location, department, spend type, spend sub-type) and rolled-up into the taxonomy de-jour (d’acheteur) … because nothing is static

• global virtual “product” masters

  not just a centralized catalog, but a centralized master data system that captures each product description (and virtual product identifier) needed by the organization and each distinct supplier product that can meet that need (e.g. in F&B, tomato sauce can be canned or bagged, room temp or frozen, condensed or not, and packaged in different quantities; a supplier might offer three different FPGAs that do the trick, each with advantages and disadvantages [memory vs processing power vs battery tradeoffs]; etc) this will “power” the catalog, but the catalog visible to organizational users will only contain current(ly available) products (that are approved)

• centralized master data management inc suppliers

  centralized virtual product masters are just the start, the organization needs centralized supplier data, centralized spend data, centralized performance and usage data, and everything needed to do meaningful category analysis to find opportunities beyond spend

• centralized risk (and compliance) management, cross indexed by category
  including mitigation plan tracking and event monitoring

  there must be a place to define all types of organizational risks, the standard monitoring (and mitigation plans), and to cross index those risks against categories (and specific products) and then flesh out those risks on a category and product basis and evaluate the potential impact and cost of the risk as the drill down occurs (in a detailed risk taxonomy); similarly, there must be a way to track compliance requirements across categories and products independent of sourcing events, with added details upon drill down and cross-correlation to suppliers providing products and compliance status

• supplier development and innovation program management

  relationship management is good, relationship development is better – whether in the core sourcing suite, core procurement suite, or the SRM bolt-on, this capability has to be there … it’s too often overlooked despite it’s essential nature

• real-time on-line collaborative category plan creation

  planning is often the most critical phase of the strategic sourcing lifecycle – it doesn’t matter how well you source or execute if the plan is bad and will prevent you from ever realizing the value that exists in the supply chain; the best way to get a good plan, or at least a plan that will be accepted and implemented by all affected parties is to involve them in the process – there must be way for all parties to come together, share their piece, collaborate, and jointly work on a plan that will be accepted by all … as the musketeers said, it’s all for one (plan) and one (plan) for all

In other words, the requirements for a modern B2B 3.0 Procurement platform, even from this short list, are well beyond what has traditionally passed for an Category Management platform that, in the early days, was anything that incorporated sourcing and procurement capabilities and had the concept of a category. Do any of the platforms out there make the cut? We’ll get to that. But first we had to provide more food for thought.

In our last post we exemplified our definition of B2B 3.0, simply defined as the first generation of technology that actually puts business users on the same footing as consumers, as the first generation of B2B technology that adds real content, community, and open-connectivity to B2B platforms through cutting edge technology like:

• web services
• intelligent agents
• meta-search
• real-time collaboration
• semantic technology
• mashups
• analytics and
• workflow

But we didn’t explicitly map these technologies to the different Supply Management technologies or workflows that you as a Supply Management professional have to use on a daily basis. Today we are going to outline some key requirements that Sourcing Suites should possess if we are going to consider them B2B 3.0 platforms. This list is not all inclusive, and simply possessing all of these capabilities will not make a suite B2B 3.0, but if these requirements are missing, then the suite will not make the cut. In mathematical terms, these are necessary, but not sufficient, conditions.

In order to avoid confusion, for the purposes of this post, and this series, we are using Sourcing Innovation’s typical definition of a Sourcing platform from a technology perspective, which is defined as the platform that is used from the time a need is identified until a contract is signed. It is the platform that underlies the “planning” and “sourcing” phases of the strategic sourcing execution lifecycle (with Procurement, SRM, and similar technologies taking over during the “execution” phase).

From a historical perspective, the primary “modules” that such a platform would include RFX, e-Auction, optimization, analysis, and contract creation and management, but these would be integrated in one seamless process because, as SI has repeatedly said, it’s not a suite, it’s just sourcing.

From this viewpoint, some key capabilities that such a suite must possess include:

• near real-time market intelligence
  integration with market (price) indexes, including commodity exchanges, public sector price databases (from public contracts), best price databases (that compare listed prices across multiple sets), energy rates, and labour rate databases (from government and published data)
• automatic cost-model recalculation
  and alerts whenever there is a potential for costs to increase or decrease beyond a certain threshold
• single-sign-on supplier portals
  where the supplier can manage all interaction with you as the buyer and submit invoices, query payment status, resolve conflicts, collaborate on NPD, discover upcoming opportunities,and provide new product and service information
• automatic profile completion
  for current and new suppliers that uses IRS, credit and risk services, business directory, and other public sources to auto-fill missing data in a supplier’s profile, so all they have to do is confirm and correct data; also, automatic discovery of products and services they offer from online exchanges that they list on
• visual supply chains for each supplier
  that allows a buyer to visualize the supply chain for each and all products sourced from the supplier based on all available data as well as the global supply chains the supplier interacts in based upon public trading data from government import/export databases and public sector contracts
• auto-quote
  based upon current pricing, standard increases or decreases based upon market rates, and publicly available price data to simply initial supplier bids in an RFX or e-Auction
• (near-)real-time decision optimization
  that is able to compute the lowest cost award taking all cost (model)s, (business) constraints, and goals into account
• advanced spend analytics
  that can not only allow a power-user to slice, dice, enrich, re-categorize, and slice again the data any way they want to see it, but detect anomalies, project trends, and dig up insights that will allow new opportunities to be sourced in clever and valuable ways
• contract obligation tracking and auto-verification
  most contracts require submission of insurance certificate, government (tax) forms, certifications, audits, and similar data upon award that needs to be tracked and validated by the buyer – this is a very time-consuming task; the platform should allow buyers to upload and use semantic technology, government, insurance agency, and other APIs to automatically validate uploaded documents upon receipt so that all a buyer has to worry about is chasing down delinquent suppliers or suppliers who don’t upload documents in the require formats (to allow for automatic verification and validity tracking)

In other words, the requirements for a modern B2B 3.0 Sourcing platform, even from these short lists, are well beyond what has traditionally passed for an e-Sourcing platform that, in the early days, was anything that could manage a few RFX forms, power a simple e-Auction on a few lots, and index a scanned version of a contract on a few meta-data fields. Do any platforms out there make the cut? We’ll get to that, but first, in our next post, we’ll define some of the key capabilities of a B2B 3.0 Procurement platform.