In our third 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. That’s why our last post covered 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 today’s post is going to outline some key requirements that Procurement suites should possess if we are going to consider them as B2B 3.0 platforms.
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 Procurement), but if these requirements are not 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 using Sourcing Innovation’s standard definition of a Procurement platform from a technology perspective, which is defined as the the platform that is used from the time the first order needs to be placed (after a contract is signed, or the need for a spot-buy that does not have to be strategically sourced identified) until the last order is placed, received, paid for, and gone out of warranty. Such a platform will often be used alongside an SRM platform, but will not necessarily contain SRM as that is not a key capability in the procure-to-pay cycle, which is the latter half of the larger source-to-pay cycle.
From a historical perspective, the primary “capabilities”, organized into one or more modules, that such a platform would possess would include requisition, approval, and PO management; invoice and receipt management; m-way match; payment platform integration; tax tracking and reclamation support; discount management and cash flow tracking; and budget management. Such a platform may or may not includes special capabilities for T&E or contingent labour, which may be managed through separate, parallel workflows in parallel platforms.
From this viewpoint, some key capabilities that such a suite must possess include:
- intelligent requisitions
semantic technology and predictive algorithms must be brought together to help a user properly define what they want, preferably against standard goods, services, and work order “catalogs” so that the proper goods and services can be selected or, if a sourcing project is required, sourced; the platform should guide the buyer to the right type of good (FGPA and not off-the-shelf motherboard), service (database programmer and not administrator), or ATM installation (and not acquisition) based upon what the user free-form enters in the description field (when he bypasses the wizard-based workflow that was custom-designed to get him there) - auto-generated purchase orders
that are generated against a contract, approved requisition, or recurring order to make sure all data is complete, and all part numbers match both supplier and buyer databases - automatic m-way match and invoice correction
not only should the system automatically m-way match every invoice that comes in, but it should automatically kick-back any errors to the suppliers with a complete description (missing data, invalid prices, etc.) and a suggestion for an auto-corrected re-submission – the goal is that only when there is a dispute that needs to be manually resolved should a human be involved; this also goes for payment, if the invoice is against a contract, against a pre-approved requisition, or within a payment threshold, it should be automatically queued for payment – manual approval should only be required in exceptional circumstances - working capital optimization
not only should the platform support early payment discounts and invoice factoring, but it should be capable of using this information to present cash-flow optimized payment schedules, subject to no late payment or max late payment rules by supplier, that schedule all approved payments to optimize the organization’s working capital without unduly burdening suppliers (and hiking their costs, which will just result in price hikes to the organization in the following year) - tax database integration
the system should pull in tax rates in real time, verify all taxes paid are correct, track each tax paid by appropriate municipal, state, federal, or union body, determine which taxes the organization is eligible to get back in rebates, link to appropriate filing documents, and automatically fill out the necessary documents for rebates as appropriate - intelligent catalogs
that seamlessly integrate supplier catalogs, be they EDI, XML, or custom format, open web-store catalogs (from un-contracted merchants or contract merchants for un-contracted products), and buyer developed catalogs that custom define products and services unique to the organization (and automatically suggested by the intelligent requisitions above) that not only allow any product or service that could be requisitioned to be easily found, but that guide the user to any contracted, preferred, or low-cost alternative - returns and defects and warranty tracking
the system should also track all products rejected at the warehouse due to defects, all returns within the warranty window, and all related warranty service costs that can be billed back to the supplier and insure that defective items received are taken off of the invoice before it is paid and returned and warranty items are credited and taken off future payments
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 e-Procurement platform that, in the early days, was anything that could manage requisitions, approvals, purchase orders, and manually entered invoices. Do any of the platforms out there make the cut? We’ll get to that. But first we had to provide some food for thought.