In our last post (Part 10), after reviewing the spend analysis process which, in short is:

• Extract the relevant data
• Load the data into the solution (mapping it to a starting taxonomy)
• Structure for the types of analyses you need to perform
• Analyze the data and get useful insights to
• Act on the insights you get

We identified that the core requirements a spend analysis system needs to support are those that enable:

• Load
• Structure
• Analyze

with a focus on

• Efficiency

Let’s take these requirements one by one.

Load: The first step is to get the data in. It needs to be easy to ingest large data files and map the data to a starting taxonomy that can be manipulated for the purposes of analysis. Particularly, those data files in classic csv, row, or column formats that are universal. The ingestion needs to be fast and intelligent and learn from everything the user does so that the next time the application sees a similar record, it knows what to do with that record. This allows us to identify our first two core requirements:

• rules: the application needs to support rules that allow for deterministic based (re)mappings when certain data values (within a tolerance) are identified (and these rules need to be easily editable over time as needed)
• hybrid AI: that can analyze the data and suggest the rules for the user to select to speed up rule definition and mapping during load

Structure: The next step is to structure the data for analysis. In spend analysis, the core structure is a

• Cube: the application must be able to build a custom cube for each type of analyses required; one size, and thus one cube, does NOT fit all; the cubes must also support derived dimensions using measures and summaries

Sometimes the cube needs to be explored, which means that the application also needs to support

• Drill Down: to the data of interest
• Filters: to define the relevant data subset
• Views: that can be configured and customized using measures, drill downs, and filters for easy exploration and easy revisiting

Also, while the theory is that you have one record in your ERP, AP, etc. for a supplier, product, and other real-world entity, the reality is that you have multiple (multiple [multiple]) entries, so the application has to also support

• Familying of like entites: suppliers, products, and even locations
• Mapping of children organizations to their parent when you can cut master contracts / agreements (such as with hotel chains)

At this point, we’ve built a cube, and we’re ready for:

Analysis: where we analyze our slices of the data to get insight that we can eventually act on; this requires:

• Measures: that can summarize the data in a meaningful way
• Benchmarks: that can be compared against
• Reports: which can be bookmarked views that show the right summary (and can be saved or printed)
• Data Science Hooks: to external algorithms and libraries for forecast generation, trend analysis, etc.

And at this point, while we don’t necessarily have everything the doctor would want in a modern spend analysis system, we almost have everything that is needed to meet the baseline, with one exception, and that’s the functionality needed to enable

Efficiency which, in spend analysis, equates to the technical requirements that eliminate the need to “reinvent the wheel” every time the analysis effort needs to be repeated. The problem with traditional spend analysis systems is that any time the data changes, all of the work has to be repeated. A good system will remember everything that was done, preserve it, just identify the data changes and new data, and pull them in. Some systems do this okay, but if the underlying data source changes, they fall apart.

However, when there’s more than one user, which is the case in most organizations, the implementation creates a central, “master”, cube and everyone has to work off of that. Usually this involves creating a copy of that cube, and then working off of that central cube. And then, when that cube is updated, create a copy of that cube and start all over.

Better systems will allow the user to pull in “just the new data” if the structure of the core cube hasn’t changed and the data can be mapped by the existing rules. But any time the base cube undergoes even a minor structural change, all of the analysts have to start again, from scratch. But this is mitigated if the system supports

• Inheritance: which creates every user’s cube as a sub-cube of another system cube or the master cube and, when any parent cube changes, use the relationship to automatically propagate any changes without any effort required on the part of the user

There are, of course, other features and functions that can be added to increase efficiency even more, but this one capability makes a spend analysis system exponentially more efficient than any system that came before.

We should note that, as of today, only one spend analysis system supports full inheritance, but a couple support partial inheritance and are attempting to improve their offering. So keep this in mind when you are comparing solutions, as not all will be equal.

Continue to Part 12.

In Part 8 we briefly reviewed the major modules in Source-to-Pay in an attempt to identify which module to work on after e-Procurement, and concluded that you select Spend Analysis, and start using it (even without integration) as soon as possible because. Spend Analysis not only helps your organization identify its best opportunities, but also what module should come next (in terms of implementation and integration).

Then, in Part 9 we elaborated on our comment that spend analysis can help you identify the most important Source-to-Pay modules for your organization based upon the types of opportunities that are identified. We identified situations in which Supplier Management, Contract Management, Risk Management, Source-to-Pay, and even I2P is relevant to capture opportunities. We did this to illustrate the criticality of getting going on spend analysis as soon as possible.

The next step is to identify what you need in a spend analysis solution. But before we can do that, we need to review the basic spend analysis process:

Extract

you need to extract the relevant data from the relevant applications

Load

you need to load the data into the spend analysis solution (and map it a starting taxonomy)

Structure

you need to structure the data for the various types of analyses you want to perform

Analyse

you need to perform the analyses and get insight

Act

you need to take action, which involves initiating processes, tracking progress, and getting results

Looking at this process, you need whatever functionality is required to

• Load,
• Structure and
• Analyze the data

Most older platforms don’t support modern API hooks or data transfer standards, so the reality is that you will need to export the data from those platforms, and there will be limited “extraction” in the spend analysis platform beyond support for requesting data through an API in the standard format the spend analysis tool supports and the API calls the spend analysis tool supports. As a result, the “extraction” part of the process is mostly outside the scope of the spend analysis tool.

Similarly, most organizations will have, or want, to use other tools to create projects, assign actions, track progress, and so on. As a result, the “act”ion part of the process is often mostly outside the spend analysis tool with, of course, the ability to push the results out in a standard format through a supported API.

Thus, in order to define a solid spend analysis baseline, we need to define all of the functionality to

• Load,
• Structure and
• Analyze the data

and, most importantly, do it in a manner that

• supports efficiency.

In other words, the last thing you want to do is have to repeat the entire process every time data is updated or re-classified in the source system. In our next installment, Part 11, we will review the core functionality required for each of these four core requirements.