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.