A few weeks ago, we asked Do You Have a Data Foundation as a follow up on our post that asked Where’s The Procurement Management Platform because, as has been made clear in our ongoing Source-to-Pay is Extensive Series (which is now at Part 6), even the best platform is useless without data — so what’s your data foundation? And is it enough?
You need a LOT of data for effective Procurement. This includes, but is not limited to:
- Catalog Data
- which represents commodity goods and packaged services that your buyers can buy in an e-commerce fashion
- Contract Data
- that encapsulates custom/proprietary goods and services you can buy and the obligations made by both parties as well as standard clauses you use
- Supplier Data
- that describes suppliers you have done business with, are doing business, and that you are considering doing business with
- Product Data
- that represents products a potential supplier could provide you with, not in a standard catalog, or product descriptions (and bills of materials) for products you need a supplier to contract manufacture
- Purchase (order) Data
- that represents what you have bought from suppliers, vendors, and service providers
- Invoice & Billing Data
- that represents what suppliers bill you for the goods and services you order, regular service/utility/rental payments, and other external payments requested by third parties
- AP Data
- that represents what Finance actually paid
- Inventory Data
- that represents what the organization actually received, and what it actually sold
- Carrier Data
- what carriers are available to bring the organization it’s goods from suppliers and then transport the organization’s products to its end customers, as well as what modes (truck, train, plane, or cargo ship) and types (dry, liquid, frozen, hazardous) of transport they support, the lanes they ship down, and their standard LTL/FTL crate/pallet rates
- Risk Data
- because you want to understand the inherent risk of a supplier from its operations, finances, regions, and inbound supply chain before you place your survival in their hands
- ESG & Carbon/GHG Data
- because reporting, and sometimes even reductions, are required in countries where organizations have limits
- Supplier Diversity Data
- as you need to support goals, and sometimes hit targets to do business with governments or keep existing customers
- Supplier Bid Data
- from tenders, RFQs, RFBs, and other RFX activities you send out
- Market / Benchmark Data
- that you can use to analyze your quotes, spend, risk factors, etc.
- Document Data
- which represent your contracts, product sheets, sales and marketing artifacts, financial reports, etc.
- Organizational Data
- employees, org structure, office locations, plant locations, etc.
- Application Specific Data
- created by other applications in the enterprise application ecosystem that power the business and impact what Procurement needs to do
And, moreover, this data takes multiple formats — numeric, fixed value from fixed list, free form text, image, audio file, video file — of various lengths and sizes, and is organized in various ways. Sometimes in a record structure, sometimes in a document structure, sometimes in a spreadsheet structure, and sometimes in a table structure. And it’s stored in various formats (ANSI, UTF8, UTF16, etc.) and communicated in various standards (EDI, c(XML), JSON, etc.)
And you need all of this data to do your job. And, moreover, you need to mangle all of this into a coherent federated schema so that you can do the analysis you need to make the necessary business decisions that Procurement must make to accomplish its task and achieve the business objectives.
But point to one platform that can
- Store all this data
- Organize all of this data into a federate schema to support holistic analysis
- Allow the organizational users to create arbitrary slices (cubes in spend analysis) for analysis
- Allow for the creation of arbitrary analysis on those slices
- Use the results as baselines for forecasting and predictive analytics
- Extract prescription advice based on those results
while integrating with the other modules and applications in the larger ecosystem the organization needs, and do it with a flick-of-the-switch or out-of-the-box configuration (engine).
SAP, Oracle, and other databases and ERPs don’t normally make it past 1 with a baseline implementation. With snowflaking and other advanced offerings (that support warehouses, lakes, and lake houses), maybe you get some of level 2. You then need to buy separate BI tools to get part of level 3 and part of level 4. You then need to turn to external tools and inject the right data to get level 5. And level 6 is still few and far between (and AI ain’t gonna help you here for a while because AI is just very advanced algorithms that can, depending on the problem, do millions, billions, and sometimes trillions of calculations on large, very large, and, if available, extremely large data sets to find likely outcomes — but only if there is enough good data to populate the data set [size] it needs — and where the internet is concerned, that’s usually not the case and the old adage of “Garbage In, Garbage Out” applies here).
But you need this in your future “platform” (ecosystem), and you will only get this if you have a good data foundation that captures all of the data elements above as well as providing a data foundation to enable the six (6) levels of capability that an organization will require at a minimum.