Category Archives: Technology

Do You Have a Procurement FocalPoint?

Last month we asked where’s the procurement management platform primarily because we now have a plethora of procurement-centric applications but very little integration between them. However, once you tackle that issue, you have the secondary issue of all these applications, but often no clear starting point and, even worse, no way for an average organizational employee outside of Procurement to interact with Procurement beyond an inbound email to “please get this for me” and the eventual, possibly many months later, outbound email to “we got it, it’s finally here … it will be on your desk tomorrow“.

This is a big problem, even in organizations that supposedly have market leading source-to-pay suites. While all the modules are connected, and the integrated workflow will guide a buyer from project selection to sourcing to supplier selection to award to contracting to supplier onboarding to order creation to receipt creation to invoice confirmation and payment approval and loop back to the order creation until pending contract expiration when the contract can be renewed, renegotiated, or
revoked and the sourcing process started all over. This is great, but for predefined sourcing projects on encoded categories only!

It’s not great for any category not already encoded and typically strategically sourced, and it’s atrocious as new product and service needs arise within the organization, as new hires need new assets for onboarding, as customer requirements change and the organization needs to adapt rapidly and source new products or services to meet new, or one-off, needs. There’s no intake, and no collaboration with the organizational stakeholders Procurement is there to serve.

And that’s a huge problem. That’s why you’re seeing a few companies talking about “intake”, “orchestration”, or “PPM” (which stands for either Procurement Performance Management or Procurement Process Management, depending on who is talking about it) because, without this capability, a Procurement platform will never be complete or support the organization.

Following the introductory post on the procurement management platform, we lamented and celebrated that Per Angusta was going away and being integrated into SpendHQ as the foundations of a new PPM. It’s a great start, but today the focus of SpendHQ is on managing the existing workflows and creating visibility into existing projects — and savings tracking is limited to integrated projects. However, when it comes to intake support and project tracking for arbitrary organizational needs, that’s not there yet.

However, there are other players which are strong here, and one of those players is Focal Point, which was built from the ground up as an intake-to-orchestrate solution that is capable of

  • capturing all organizational requests for Procurement and Procurement-related activities,
  • assigning those requests to customizable workflows using either built in automation rules or manual (re-)assignment,
  • allowing an end-user to see exactly where any request is in the process at any time,
  • allowing for in-platform communication between the stakeholder and Procurement,
  • integrating with any external tool through jump-out/jump-in to support the process, and
  • supporting whatever approval chains are required, among other intake and orchestration functions.

The tool was built to solve the most significant problem the founders repeatedly saw as CPOs and implementers of various leading sourcing solutions — little to no intake management or general purpose procurement process orchestration. And it does it incredibly well. The visual workflow construction is extremely usable, and the wizards that power both the process, form construction, and form completion automatically extend and compress the form as needed based upon user selections and actual needs, making for a very smooth flow.

All of the workflow elements and steps support deep conditional logic, allowing the organization to create as many branches as possible but ensuring that the end user making a request, and the end buyer assigned to deal with that request, only see the relevant paths and only need to enter the relevant information to be guided by the platform.

There can be as many intake types, with associated branching workflows, as the organization needs, each can have the appropriate level of automation, and, most importantly, each can have as many milestones as needed to walk the process through at a high level, allowing the requester to easily see at a high level where the process is, and then, if interested, dive into the detailed workflow within the current milestone to get a more accurate picture of where the process is.

The only thing the platform doesn’t do is actual sourcing, supplier management, contract management, analytics, procurement, or payment management. It expects the organization to have tools for this already and integrates into the appropriate modules in those tools as needed to accomplish the workflow in progress.

In terms of getting up and running, Focal Point typically has a fully fleshed out, functioning, and integrated instance that captures all of the organization’s workflows up and running within 90 days, even if the organization is a multi-(multi-)billion dollar organization, which is Focal Point’s target market size. This is because it’s typically the 1B+ organizations that have a lot of tools, and a lot of stakeholders, but no way to manage those tools effectively or to give stakeholders any visibility into where their requests are and how their spending is being managed.

The reason it typically takes 90 days is that, unlike many sourcing suite providers, who just flip a virtual switch and drop an empty SaaS suite on you and say “good luck“, Focal Point fully configures the platform as part of their statement of work. This includes:

  • working with the organization to understand all of their requirements and current workflows
  • encoding all of those intake workflows with milestones, task-breakdowns, and existing platform jump-outs
  • integrating any existing procurement system you need to complete the workflow
  • creating a UAT instance and allowing for at least one iteration and approval before it goes live
  • training your team on how to use the system and maintain the workflows

So even though Focal Point has obviously achieved efficiency in terms of workflow creation and customization, external platform integration, and implementation project management, it takes time for an average organization to collect and document their existing processes and requirements and for FocalPoint (or a third party consulting organization if that is the customer’s preference) to fill in the gaps, so it’s not possible to get it much below 90 days. But when you think about the fact that they have fully implemented a 10B+ organization in that timeframe, when some major suite players will take 18 months working with a consulting partner to fully implement those solutions, that’s an incredible time to value, which is generated day one when every request flows into the tool; gets tracked, assigned, and executed; and stakeholders have full visibility into the process and can intervene if necessary.

Focal Point solves the problem it was built to solve, fills the hole the vast majority of sourcing and procurement solutions make, and does it incredibly well. If any part of this post resonates with you, the doctor encourages you to check them out.

What’s Your Data Foundation? And is it enough?

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

  1. Store all this data
  2. Organize all of this data into a federate schema to support holistic analysis
  3. Allow the organizational users to create arbitrary slices (cubes in spend analysis) for analysis
  4. Allow for the creation of arbitrary analysis on those slices
  5. Use the results as baselines for forecasting and predictive analytics
  6. 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.

Do You Have a Data Foundation?

Last week we asked Where’s the Procurement Management Platform as the future of procurement is a platform that allows Procurement to build up, maintain, and evolve the solution it needs to be successful over time, over time. Such a platform needs to be the foundational data source for Procurement, but not necessarily the data hub that is used to integrate all of the organizational and external data into the core data source (which is either the internal data store or the data store supported as the platforms foundational data source).

While a procurement management platform could be the data foundation, since it’s primary purpose is process based procurement solution integration, it isn’t necessarily … after all, an API / Integration Engine focused on process doesn’t need to support every data source out of the box, nor does it need to make integration with arbitrary data sources easy, and, most importantly, it doesn’t need to support advanced data processing and transformation features, which is key when trying to integrate multiple data sources into a foundation that can be universally processed by the platform and support true end-to-end spend, and risk, analysis.

Like a Procurement Management Platform, which we may see four (4) of by year end, Data Foundation solutions are also quite few and far between. The reason? Most “data” solutions are focused on BI [Business Intelligence], Spend Analysis, or Contract/Document management, etc. and most “data” feeds on risk data, supplier data, catalog data, etc., which means they are built for certain data types and processing operations. This means that they will support a straight-forward integration for any data source with similar data types, or data types with compatible processing operations, but not any others.

When you look across Source-to-Pay and the broader Supply Chain spectrum, there are a lot of different applications that support a lot of different processes that need a lot of different data requirements of different types and formats. You need a modern MDM [Master Data Management] solution that works on web and cloud data, can pull in and process data on the fly, and push it back out enriched as needed. And support any data format and standard, not just flat files or relational tables in text (like old school MDM).

This capability is a lot rarer than you think. Most suites are built on transactions, most supplier networks on relational supplier data record, and contracts on documents and simple, hierarchical, meta-data indexes. But you also need models, meta-models, semi-structured, unstructured, and media support. And that’s just a start. But there are possibilities emerging. Just watch this space.

Now that Per Angusta is going away …

… we’re finally getting a new Procurement Management Platform! And that’s a great thing!

Hopefully that last line caught your attention enough to read on (since Per Angusta isn’t actually going away, just its name) because the reason it’s a great thing is that Per Angusta, which finally completed it’s integration with SpendHQ, is soon to be one with SpendHQ. This will provide the procurement space with one of the first, true, Procurement Management Platforms, which, as per yesterday’s post, is something the space is desperately needing. (We doubt it will be the last such platform this year, but it’s certainly the first.)

Why?

1) It will be spend data driven, not just pull and push spend data around.

2) It will support all of the necessary intake requests and output reporting.

3) It is built to support procurement-centric workflows or projects.

4) It is built to integrate with any application an organization needs to support a certain process, sub-process, or data-centric capability through easy multi-endpoint integration with push-pulls at either end.

… which solves the four big problems created by Source-to-Pay suites as pointed out in yesterday’s post that asked where the Procurement Management Platform was.

And how they did it is very slick. Not only did they follow the levels of integration appropriately (where they started by re-creating the Per Angusta UX using SpendHQ look-and-feel, while they were working on data model integration on the back-end [which is a difficult task that many companies don’t actually achieve]) to get to the point where they are now working on full integration, but they built the solution to support third-party solution integration at key process points, not just separate integration tabs / menus, and this allows all of the embedded applications to be extensions of each other, not a pool of disconnected apps you have to glue together with Excel.

In other words, every solution that is integrated is inserted at key points of the process flow where it makes sense to do so … for example:

* sourcing partners are brought up when an opportunity is being created and sourcing is selected as the mechanism
* data partners are displayed in a supplier overview / risk report so that an analyst can punch in to the source system for deeper analysis, metric breakdowns
* partner spend solutions are integrated at key parts of category drill downs if an analyst wants to push out a subset of data for what-if or experimental (AI) analyses without messing up the categorization or mappings of the source system
* key data from CLM systems can be pulled into the core to drive the application, and when contracting opportunities arise, data can easily be pushed out and pulled in at key points

etc.

And on top of all of this, there’s a solid, modern, competitive spend analysis platform built into the solution that is both a leader in data usability and in multi-data source integration, which is a key requirement for spend analysis, and Procurement success, as a whole, because, unless you can get a complete picture across all of your spend (related) data, you can’t truly make informed decisions and determine which opportunities are worth pursuing and likely to deliver the best organizational results over all.

The only thing that’s missing is the message.

* SpendHQ is all about “Spend Intelligence: Clear & Simple” (which is not a unique message or capability)
* Per Angusta is all about “Powering Up Procurement” and “Procurement Performance Management” (which is not a unique message or capability either)
… but neither comes close to capturing what the integration truly is, or can do, or how they’re one of the handful of players that will be creating the new foundations for Procurement offerings going forward (as Suite 4.0 is not just a suite, it’s a platform).

I hope they get it right, as we don’t want SpendHQ to go away too …

AI: Applied Indirection, Artificial Idiocy, & Automated Incompetence … The April Fools Joke Vendors are Playing on You Year Round!

So on the one day of the year when they should be making the joke, I’m going to reveal it.

The vast majority of vendors who claim “AI”, where they want you to think “AI” stands for Artificial Intelligence, have no “AI” in that context, and many don’t even have anything close. A few may have “Assisted Intelligence” (Level 1) and even fewer still may have “Augmented Intelligence” (Level 2), but “Analytical (Cognitive) Intelligence” (Level 3)? Forget it! And as for, Level 4, “Autonomous Intelligence”, which is the baseline that must be met before you could even consider a system true “AI”, doesn’t exist (at least as far as we know). (ChatGPT would be a 3 on this scale, 3.5 if you’re dumb enough to use it to power a semi-autonomous application.) (For more details on the levels of “AI”, see the detailed Pro piece the doctor wrote over on Spend Matters on how Artificial intelligence levels show AI is not created equal. Do you know what the vendor is selling?.)

However, thanks to ChatGPT/OpenAI and other offerings, every vendor all of a sudden feels that their solution has to have “AI” to compete, and is now claiming they have AI when, at best, they’ve implemented some third party “library” into their analytics module, which itself may or may not be AI, or, at worst, they just have classical rule-based automation and statistical-based predictive analytics (i.e. trend analysis) but have called it “AI” because, just like a classic decision-tree expert system from three decades ago, it can make a “recommendation”. Woo hoo.

Not that this is nothing new, three years ago a study by London Venture Capital Firm MMC found that 40% of European startups that are classified as “AI” don’t actually use AI in a way that is “material” to their business. MMC studied 2,830 “AI” startups across 13 EU countries, and in 40% of cases, [they] could find no mention of evidence of AI. (See the great summary in The Verge.) And even that statistic is a bit misleading, because I’m willing to bet that the “evidence” they did find was technology that didn’t necessarily mandate “AI” and could be implemented with “classical” techniques because, as a longtime blogger, analyst, due diligence professional and, most importantly, a PhD in theoretical computer science (read: advanced applied mathematics), I have found that most claims of “AI” weren’t really AI — in most cases they were just using a combination of automation and/or configurable rules and/or advanced statistics and/or machine learning and just had some of the foundations, but no real “AI”.

In our space, real “AI”, and by that I mean strong Level 2 / weak Level 3 (which is the best you can get) is quite rate and specific use cases are few and far between, and most AI is simply semi-unsupervised machine learning for transaction/categorical classification (spend analysis) or clause identification (contract analytics).

The problem is that, when no one really understands what “AI” is, and given that less than 1/10 Americans have the mathematical competency to even begin the university studies to try and garner an understanding [Level 4 on the PIAAC], it’s really easy form them to try and pull a fast one on you. This is especially true when the solution is able to automate certain tasks or recommend best practices in the majority of situations faster and more consistently than the average buyer (who, let’s face it, is under-educated — thanks to limited supply chain / operations management programs and almost no real Procurement training in Colleges and Universities, under experienced, and not an expert in modern technology), and the solution can be made to look “smart” (but, in reality, is dumber than a doorknob and definitely dumber than Maxwell Smart). But it’s not smart. Not at all.  And don’t be fooled.

The good news is the marketing manager using Applied Indirection to push a false AI solution at you probably doesn’t have a clue what they have anyway, and a few smart questions asked by someone who understands what AI is, and isn’t, can probably get pretty close to the truth pretty fast. For example:

1) “We have advanced AI data auto-class. It’s the most intelligent, and accurate, classification in the space.”

‘How does it work?’

“It uses a multi-level neural net that has been trained on tens of millions of records across over a hundred clients in the indirect space.”

‘Great, so basically it categorizes transactions based on similarity to other transactions in a slowly evolving manner, and I’m guessing for a new client in the indirect space, out of the box, you’re around 85% to 90% accuracy out of the box and you approach 95% with semi-supervised retraining over time — and that’s the upper bound and it will never be perfect.’

“Uhm, … well, … more or less … “

‘Got it!’ At this point you know it’s “AI” level for classification is augmented (as it learns and evolves over time), and barely, but it’s not “the best” mapping in the space as platforms that use AI to suggest rules (upon implementation and then for unmapped transactions) and do mapping and categorization based on the user selected and verified rules can produce 100% accurate mappings, always outperforming an “AI” solution that uses neural nets that are good (but not perfect).

‘Do you use AI anywhere else?’

“Uhm, what, why? It’s great where, and as, it is.

And now you know that there is no real AI in the analytics part of the platform, and there’s no reason to choose it over any other.

2) “We use AI for OTD prediction and risk in delivery prediction.”

‘Cool. What algorithm do you use?’

“Huh, what do you mean?”

‘How does the application compute the OTD and/or risk associated with the delivery.’

>Wait for the hand off to their “data scientist” …< “We use a blended least-squares method to produce a prediction function where, if there is enough data for the product, carrier, and lane, we’ll primarily use that data for the function, but if there’s not enough, we’ll use the most similar (using a mathematical distance function) product, carrier, and/or lane data … “

Is that AI, well, if there’s some sort of learning involved in the selection of “similar data” or recommendations as to parameter tuning IF parameters can be tuned, maybe, but this is just classical statistical trend analysis and not really any different than classical ARIMA based forecasting from the 70s, and did they have ANY AI then?!? (The answer is “NO”!)

3) “We use AI for our supplier recommendation process?’

‘Sounds promising … please explain!’

“We compute a relevance score taking into account a large number of factors including product base, geographic location, diversity, risk, etc.”

‘OK … how … ‘

>Cue the Eventual Hand Off to “Data Science” Team<

“Product Base is computed as a percentage of the category they can likely cover, geographic location as an average distance function, diversity as an estimate of diversity employment if there is no diversity ownership data (in which case it’s just 50%), the risk score from our risk model, etc. “

‘So, in other words, it’s just a formula … ‘

“A very sophisticated multi-level formula with conditionals and nesting that computes … “

‘Got it thanks!’ NO AI! Not even a hint there of as it’s just a functional risk score that could be built in ANY application with a formula builder.

This isn’t to say that a solution without AI isn’t right for you! (In fact, it probably is!) It’s all about solving your business problem, and many problems have been solved in our space just fine for the last decade or so with rules-based workflow and automation, optimization, and statistical modelling and trend projection. When guidance is needed, decision trees/matrices tied to expert curated best-practices (the modern equivalent of a classic “expert system”) often work better than one could imagine. In other words, it’s not AI, it’s not the hype, it’s what solves your problem, reliably and predictably time-after-time.

So don’t fall for the false hype and be the April fool.