Category Archives: Spend Analysis

Procuri Spend Analysis

During my brief Chicago tour, I had a chance to sit down with Rod True of Procuri (acquired by Ariba, acquired by SAP), Senior Vice President and the former President and Founder of TrueSource, acquired by Procuri last year, and talk not only about Procuri’s TotalSpend solution, but about what Spend Analysis, Visibility, and Intelligence means to Procuri and where their solution is going.

Although I do believe that their tool is not yet a perfect “total” spend solution (but to be fair, I do not think any tool is – which is probably obvious from my recent posts on the spend visibility space), I also believe that with the acquisition of TrueSource, Procuri are just as close, if not closer, than any of the other big players in the space. The reason for this lies largely with Rod True and the team he built and the fact that they get that “spend intelligence” requires three major components to be successful: accurate visibility across all of the relevant data, analysis capabilities, and the ability to use the data for compliance initiatives.

To this end, TrueSource spent a great deal of time on ETL tools that could not only load data from a large number of data sources, but map such data into a plethora of out-of-the-box and custom categorization schemes and do so in such a way that duplicates are detected and dropped. (After all, if your data is no good, neither is your analysis.) Moreover, knowing that most companies still use old ERP or database systems where the best they can muster is a full database dump (for the last month / quarter / year), they have built their ETL tools in such a way that their spend warehouse can be incrementally updated from a full database dump at any time.

They have also built in a large number of reports (over 70) and standard reporting capabilities (through a custom report builder) to allow for role-based reporting and analysis, compliance & audit management, category management, and diversity management and built their warehousing capabilities to support just about any categorization you can desire. They also have role-based dashboards, category project management, and category intelligence built into the solution.

Furthermore, knowing that they could not possibly think of all of the things you might want to do with the data, they also support the fine-grained export of any set or subset of data or report that you might want to analyze in further detail.

And this is where I believe their one weakness lies. They have visibility down pat (and pride themselves on their ability to be able to quickly develop an automated cleansing, classification, and refresh for just about any data source you can imagine), they understand that the entire point of any spend effort is all about compliance – with diversity requirements, with reporting regulations, with business decisions, and with sourcing decisions (otherwise your “savings” might never be realized), but their analytics is limited to what you can do with their pre-defined reports and report builder. And although I have to admit that what they have is most likely more than enough for most of the users in an organization – executives, managers, and even average users – I am not convinced it will ultimately satisfy the emerging spend power users.

It is true that a power user can easily integrate into their cleansed data feed and extract just the data they want (and they told me that they are surprised at how fast their power users can get just the data they want for a custom report and build it in another tool), but I believe that the next generation of spend power users are going to want the ability to create their own custom views, reports, and analyses in the tool itself, versus on their desktop with a Microsoft Office or similar end-user tool.

However, you still need a centralized spend repository with complete, clean, categorized data for your analysis, reporting, and compliance management – and this solution is definitely a valid starting point from that perspective.

Aptium Global : An Emerging Spend Powerhouse

Regular readers of this blog will remember that I’ve mentioned Aptium Global a few times, chronicled one of their success stories in Tuesday’s Lean Services post (with another hitting the blog sphere tomorrow),and ran a great guest post on Quantifying Quality in Lean Sourcing Initiatives by founder and principal Lisa Reisman. Aptium Global is a specialized consultancy that works primarily with small and medium sized manufacturing companies to help them save money on purchases through Lean Sourcing approaches.

Well today, in addition to industry heavyweight Stuart Burns, who runs their European practice, Aptium Global can add FreeMarkets legend Tony Poshek, inventor of The Puddy Principle to strategic sourcing. Tony, who has also put in considerable time at GE (as well as managing events for GM and other Fortune 50 heavyweights) has sourced almost $2B in his sourcing career and saved over 300M, or an average of 15% above and beyond what industry leading sourcing teams have saved. Tony was interviewed by Lisa last year and the interview is archived over on e-Sourcing Forum. Check it out!

Add this to Aptium’s forthcoming launch of an industry specific Metal Miner offering for companies that source metals, commodities, and components with high metal concentrations, and it’s easy to predict that Aptium Global is poised to become a powerhouse in their corner of the sourcing space.

The Metal Miner sourcing solution is a packaged two-week analysis that is designed to provide a small or mid-sized company with real time market condition and savings strategies for all of their metals and metal services spending in two to three weeks. A proprietary analytical solution built on over half a century of combined global metals sourcing experience, the solution is designed to provide you with a strategic framework to metals sourcing that can provide you and your executive team the insight you need for critical strategic sourcing decisions. Metal Miner uses state-of-the art analysis technology, takes into account a high-level assessment of the supply market for each category (including the main price drivers, the degree of fragmentation, domestic/offshore supply bases, and hedging mechanisms), and produces a customized report with specific implementable savings strategies for each category in which a significant savings can be achieved.

So, if you need sourcing help, particularly in metal or metal services categories, I’d contact them now. The secret’s out … and it won’t be long before the lines are jammed and the e-mail boxes overflowing.

Spend Analysis VI: New Horizons (Part 2)

Today I’d like to welcome back Eric Strovink of BIQ (acquired by Opera Solutions, rebranded ElectifAI) who, as I indicated in part I of this series, is authoring the first part of this series on next generation spend analysis and why it is more than just basic spend visibility. Much, much more!

Federation

One of the most serious limitations of OLAP analysis is the schema structure itself — typically a “star” schema, where a voluminous “fact” or “transaction” file is surrounded by supporting files, or “dimensions.” In the case of spend analysis, dimensions are Supplier, Cost Center, Commodity, and so on; transactions are typically AP records.

Why is this schema limiting? Because there are only certain ways that a dimension file can be linked to transaction files, and it isn’t always clear which file ought to be the transaction file and which files ought to be dimensions. For example, suppose that the transaction file consists of AP transactions, and a dimension file consists of invoice line items. The problem is that the invoice line item file is “moving faster” than the AP file; i.e. for every invoice number that appears in AP, there are multiple invoice lines that match. Which invoice line item should we link to?

Well, we could invert the problem and build the dataset from the invoice detail file instead, except that we typically won’t have invoice detail for every AP record, so that probably won’t work. Here’s a couple of ideas that will work: (1) we could build a separate measure column for invoice line items, and include them as AP record equivalents (coercing the two record types into a common format); (2) we could drop the associated AP record whenever we have invoice line item data, and include the AP information inside those line items, redundantly.

There are other options, too.

But the essential problem is that we have two separate datasets, and we’re trying to join them at the hip. There is an AP dataset, and there is an invoice line item dataset, and never the twain shall meet, except artificially. Even when there is no granularity issue at all, and when one dataset can be normalized or snowflaked such that every matching line item can be joined through from the other, the amount of effort required to set up the index->index->index relationships can be daunting.

Instead, why not create two separate datasets, efficiently and quickly; and then as a final step, federate them together on a common dimension? Suppose the federation logic was “join” — in that case, we’d drill on an element in dataset A; dataset B would drill on the common dimension from A; and then A would drill again on the common dimension from B. What we’d see is the perfect join of all of the records from A and from B that shared a common key in the common dimension; and we’d have the ability to reference all data from any dimension of both A and B.

There are many forms of federation in addition to join — for example, “master-slave,” where we drill on A, and B shows us its common nodes; but does not feed those back to A. That relationship can go the other way, as well, from B to A. In addition, there’s a “disjoint” operation — show me all the nodes in B that don’t share a key in the common dimension with A (and vice versa).

Federation represents a key productivity enhancer for dataset creation, as well as a simplification to the dataset building process in general. Federation also passes the “usability” litmus test, in that the resulting datasets are much easier to understand than massive levels of index indirection and snowflaking, and have the potential to produce richer results.

The technical challenges for federation are considerable: maintaining multiple connections to multiple datasets; representing multiple data dimensions inside the context of a single data viewer; providing mechanisms for pulling data seamlessly from multiple datasets for reports and analyses; and last but not least, augmenting the OLAP engine to perform federation operations effectively and quickly.

Is federation worth it? I think so, emphatically.

This brings to an end our initial Spend Analysis series. Thanks for the opportunity, Michael; and thanks to everyone who took the time to wade through it.

As Eric said, this ends Sourcing Innovation’s initial series on spend analysis. I’d like to thank Eric for his enlightening posts and hope that you learned something from them.

Spend Analysis V: New Horizons (Part 1)

Today I’d like to welcome back Eric Strovink of BIQ (acquired by Opera Solutions, rebranded ElectrifAI) who, as I indicated in part I of this series, is authoring the first part of this series on next generation spend analysis and why it is more than just basic spend visibility. Much, much more!

Many of the limitations of spend analysis derive from its underlying
technology. As I’ve discussed in previous installments, the extent to which spend analysis can be made more useful to business users is often the
extent to which those limitations can be hidden or eliminated. In essence: an analysis tool is useful to business analysts only if business analysts actually use it. Which means that there is a fine line that vendors must walk between delivering technology to business users, and shielding them from it — without going too far and creating an unnecessary vendor dependency.

In this installment and the next, we’ll look at a few advanced features that aren’t necessarily available today, but that should be possible to provide in future, without crossing that line.

Meta Aggregation

By definition, a spend transaction contains the “leaf” level of a
hierarchy only. Consider the following:

   HR Consulting
Mercer
Deloitte
IT Consulting
IBM
Accenture
Management Consulting
KPMG
CGI

Low level transactions typically contain “Mercer” or “CGI,” but
not “IT Consulting” or “HR Consulting,” because those intermediate
hierarchy positions (“nodes”) represent an artificial organization
imposed by the user, and have no reality at the transaction level.

Suppose, though, that I’d like to be able to treat intermediate nodes as though they had reality inside the transaction set itself. Simple example: I’d
like to derive a new range dimension based on the top level of the above
dimension. I want to know which consolidated groupings are at $0-$100K,
which are at $100-$500K, and so on. I don’t care about IBM or
KPMG any more; all I care about is aggregating my own groupings.

In mathematical terms, I’m asking for f(g(x)) — the ability to apply
dimension derivation to a previous aggregation step; and, inductively and more generally, to do the same to the meta-aggregated dimension itself.

In OLAP implementation terms, I’m asking the engine to treat the intermediate nodes from any dimension, at any hierarchy level, as virtual transaction columns rather than as dimensional nodes. The problem is, intermediate nodes aren’t static; they’re changing all the time. That means a dimension derived on artificial rollup values must be re-derived whenever the hierarchy of the source dimension is altered; and, since hierarchy editing must be a real-time operation (as I have argued in this series and elsewhere),  the dimension derivation must also be performed on-the-fly.

Tricky as this might be to implement, the logic is easy to specify from the business user’s perspective. The user simply picks a previously-defined dimension and a hierarchy level on which to base his new dimension, and he’s done.

Visual Crosstabs

The utility of Shneiderman diagrams (or “treemaps”) to display hierarchical information is well known; the BIQ site has a live example.

The treemap is useful because it is visually intuitive; in this example, the relative sizes of the rectangles represent the relative magnitude of spending. The colors indicate relative change in spending; red is bad, green is good; lighter green is better. Inner rectangles show the breakdown at the next level of the hierarchy.

Clicking inside one of the white-bordered rectangles provides an expanded lower-level view of the hierarchy; clicking the up-arrow button moves back up a level.

Now, suppose that rather than the inner rectangles showing a lower level of the same hierarchy, instead they showed the breakdown of spending
within another dimension entirely — i.e., a “visual crosstab.” The visual crosstab would not only show magnitudes, but trends as well.

Unlike with meta aggregation, where the user interface is simple and
the implementation complex, here the user interface is complex and the
implementation fairly simple. The utility of the visual crosstab will
depend strongly on the user interface — for example, how does the user change the resolution of the outer dimension to a different hierarchy level? What might that do to the level of the inner dimension? How might the user invert the view, so that the inner dimension becomes the outer, and the outer becomes the inner? Globally, how can the user be kept aware of what’s being viewed/inverted/clicked, and therefore be able to make sense of the result?

Spend Analysis IV: Defining “Analysis”

Today I’d like to welcome back Eric Strovink of BIQ (acquired by Opera Solutions, rebranded ElectrifAI) who, as I indicated in part I of this series, is authoring the first part of this series on next generation spend analysis and why it is more than just basic spend visibility. Much, much more!

“No canned report survives first contact with the analyst.”

Analysis = Agility

Reporting on a large transaction dataset is
technically challenging. For example, pointing ordinary reporting
tools at a large dataset doesn’t work well, because what might
seem like a perfectly ordinary and reasonable database query can require minutes to complete, sometimes even hours. That’s why OLAP (“On Line
Analytical Processing”) technology is required in order to
return results quickly on large datasets, and that’s why every data
warehouse uses some variant of it.

OLAP is not a panacea. OLAP database queries only
work within a rigid framework — that is, queries are
fast only within the data dimensions and hierarchies that have
been pre-defined. To ask a question outside of that rigid
framework, and to get an answer to that question in a reasonable
amount of time, the underlying dataset structure must be changed —
either dimensional hierarchies must be altered, data re-mapped, or
entirely new data dimensions created.

Data analysis is an inherently ad hoc process —
to paraphrase Sun Tzu, “no canned report survives
first contact with the analyst.” But, in order to be able to perform the
OLAP queries that support ad hoc reporting, it is necessary to change the dataset structure to support those queries. And, it had better be possible
to do that quickly and easily; otherwise OLAP power cannot
be brought to bear on the ad hoc report, which means that
the report can’t be generated without great pain.

Analysis therefore equates, in a very real sense, to “agility”;
in other words, how quickly and easily one can:

  • generate new dimensions;
  • change existing dimensional hierarchies;
  • map and family new and existing dimensions.

Agility also applies at a higher level. I argued in

Spend Analysis I: The Value Curve that the notion of
one dataset for spending data is limiting, because many
different analysis views — especially commodity-specific
views — can be key to driving additional value. If the spend analysis process involves the creation of multiple datasets over time, and it’s hard or expensive to build or modify datasets, then that process can’t move forward.

Agility also requires that the above operations be performed by
business users with limited IT skills, on their own, without
assistance from vendor or internal experts. If the system is
not agile, then the default decision is not to analyze,
as pointed out in

Spend Analysis II: The Psychology of Analysis. That is
the worst possible outcome for the enterprise, because it perpetuates
information starvation in a land of data plenty.

Analysis = Speed

Here’s a heretical statement, coming from a spend analysis vendor:
anything that a spend analysis system does for you can be done
with ordinary tools. You can use a database system to load a large dataset; you can cleanse your own data by writing database queries; you can write programs to build reports; you can dump data to pivot tables. You can get great answers to your questions. Some old-school sourcing consultants still use manual methods like these, and some home-grown spend analysis systems built around tools like Microsoft Access are still operating today.

However, if you do use a modern spend analysis system, you can produce
those same pivot tables and reports with a few mouse-clicks; and, you can alter their properties and constraints with slice-and-dice operations easily and quickly. For every report that the old-school consultant generates, you’ll have had the opportunity to generate hundreds. Does this mean that your insights will be better than those of the consultant? Not necessarily; but it’s hard to argue that they shouldn’t be.

If your spend analysis system isn’t agile, though, you’ll be back in the same boat as the crusty old consultant, and he’ll be laughing at you. You’ll have to extract transactions from the system and hack at them with the same tools that the consultant uses, with the same productivity loss.

Analysis = Power

It’s important to distinguish between ad hoc reporting and reporting in general. Does the spend analysis system have the ability to produce complex and custom reports, guided by you? Or are its reports written in some programming language like Java or C++, the source code for which is inaccessible to you and unmodifiable by anyone but the vendor?

Analysis power is precisely the power that you wield as a business user,
independent of canned reports supplied by a vendor. Complex, multi-page
reports such as the original MMG Commodity Spending Report (below),
variants of which are now commonplace across the e-sourcing space, should be within your reach to create quickly and easily — without any
programming, database queries, or other IT magic, and yet with full flexibility to build whatever it is that you need.

Next: Spend Analysis V: New Horizons (part 1)