Category Archives: Technology

Why Do We Still have First Generation ERP/Data Warehouse BI?

the doctor was recently asked by a senior consultant if a CFO was right when he said why should I use Spend Analysis if my ERP has BI functionality that allows me to do ‘any’ analytics and generate reports … and I only have one ERP instance as the company was relatively small (< 100M).

How is the CFO wrong? Can we even count the ways? First of all, let’s go back ten (long years) to when SI published this great post from the spend master himself, Eric Strovink on screwing up the screw-ups in BI where he noted that Baseline, in their efforts to defend AI, were simply pointing out more holes in the process. In this post, the spend master noted:

1. A central database won’t solve the analysis problem, and at the end of the day you’ll have just as many spreadsheets as before … which, as every CFO and CIO knows, is way too many.

2. Business analysts should be able to construct BI datasets on their own, as needed, from whatever data sources are useful/appropriate, and it shouldn’t be difficult for them to do so … but most BI tools only make it easy to construct datasets and reports on data in the ERP. And you NEVER, EVER, EVER have all the data you need in the ERP. Some is in the AP. Some is in the sourcing and procurement systems. Some is in the WIMS. And then there are market data feeds that can provide insight, not in the ERP.

3. While BI is said to be the cornerstone of a governance program, a governance and stewardship program doesn’t actually put any meat on the table … whereas modern spend analysis systems do.

4. While BI can support data integrity, it typically isn’t cleansing that’s the problem, it’s (1) the fixed organization of the data, which is guaranteed to be inappropriate for any analysis that hasn’t been anticipated a priori, (2) the ad hoc reporting on it, which has to be easy to accomplish, as opposed to requiring IT resources (see below), and (3) the fact that cleansing can’t be accomplished on-the-fly (as it should be) by the business analysts themselves.

5. BI systems are difficult to use and set up, it is difficult to create ad hoc reports, and it is impossible to change the dataset organization … especially compared to spend analysis.

And this doesn’t even begin to address the facts that

6. BI reports are pretty generic, and not fine tuned to Sourcing, Procurement, or Finance. Modern SA systems, built by Sourcing, Procurement, and Finance professionals, have out of the box reporting fine-tuned to the needs of sourcing, procurement, and finance professionals that report on spend by category, supplier and metrics by category and supplier with easy drill down and segmentation by department, category, etc.

7. BI engines work on one schema — the ERP schema. And this is not always appropriate for Sourcing and Procurement who need to manage by category. and then do what if analysis against different re-categorizations to try and find the best way to source and procure for the organization. Modern SA tools allow for the creation of different schemas, different cubes on those schemas, and different views on those cubs. Power not in the BI.

8. BI engines expect the data in the ERP. SA systems don’t. They can import data from multiple systems, flat files, market feeds, etc. — put it in private, or public workspaces, reclassify and modify and augment the data as needed, and create true intelligence on a category or a supplier — not just a summary of last year’s spend by product or supplier.

9. The ability of first (and even second generation) BI engines to create arbitrary reports is considerably overstated. Most of them limit the facts and dimensions that can be used in reports to those in defined tables, and limit the self-service reporting to modification of pre-defined templates. Not the freeform capability of a modern Tableau or Qlik solution, and definitely not the freeform capability in a best in class Spend Analysis solution that can allow any dimensions or facts to be used and reports and dashboards to be created using any defined report components in an easy drag and drop manner.

And so on. Hopefully by now you get the point — especially when there are SA solutions out there that start at only a few thousand a month and provide at least 10 times the value of that outdated BI solution the ERP company should be paying you to use. (The technical debt they owe you on this is huge!)

Scared of AI? Try Auto-Classify!

Last week we noted that if you were scared of AI (and rightfully so, as it tends to over-promise and under-deliver), you should start with Auto-Buy — specifically, auto-buy for certain tail-spend products and services where the platform can at least get you market average pricing on a product or service you’re likely overpaying by 15% or more on. The platform might not be able to match the best expert, but it can far surpass an average buyer, and paying market average is better than overpaying by 15%.

In this post we said that your spend generally breaks down into strategically sourced, bought from the GPO, catalog buy, and the rest falls into the tail. And the way to save significant money quickly and easy is to get the tail out of control … a large tail spend can be costing you 6% against the bottom line. That’s huge. And there’s only one way to get this under control. Auto-buy. And there’s only one way to do better — get the spend out of the tail into the other categories.

This is easier said then done. Tail spend might only be 20% of the spend by dollar, but it’s 80% to 95%+ of spend by volume — trying to classify each and every purchase to a strategically source, GPO, or catalog category it could fall into is a monumental task, and that’s why the tail spend stays high,

But it’s not a monumental task for AI. Remember, we can’t do millions of calculations a second – computers can. And when enough of these calculations are done, and correlated, computers can make assignments that, on average, greatly exceed the accuracy of an average buyer in significantly less time. Plus, the rare-misclassification will be found quickly by a human buyer and re-assigned to the right category — either the product has an equivalent in the GPO, or it doesn’t. Either it has an equivalent in the catalog, or it doesn’t. Or it fits the way the strategic buyers buy, or not. But in the first two cases in particular, the computer will be not only be able to identify the best matches with high accuracy, but even provide its reasoning.

So use the AI for what it’s good at — bulk computation and analysis. And be confident that while it will greatly reduce your tactical workload and make you more efficient, it won’t replace you — in fact, it will make you irreplaceable as you will be freed up to spend more time on the strategic, value generating work.

Going Digital. Digitization. Digital Transformation.

Do you know what any of these terms mean? Are you sure? and I’ve been “digital” for three and a half decades — and I’m not sure I’m whatever “digital” is when it’s spoken by someone who hasn’t been digital since before it was cool. I had a TRS-80 which, supposedly, understood the BASIC programming language (it did, but even if you think you know BASIC, unless you had the joy of Level I Basic, you don’t … especially if you haven’t experienced the joy of only three error messages … which, I will admit, was better than the one error message I got on the VAX) and that was followed by an 8088 … remember that? Probably not … it was long before it was all about the pentiums … but, like the TRS-80, it was digital. (And if you don’t understand any of this, all you need to know is I’m the One That’s Cool.)

The thing is if you’re using a computer, you’ve already went digital. It works on bits, not analog signals. So what does it mean to go digital? Since there isn’t a business these days that doesn’t use computers, there isn’t a business that’s not digital. The only question is how much is done on the computer. And, more importantly, how much is done entirely on the computer. This is, simply put, a meaningless bullshit phrase.

Now let’s talk about digitization. Technically, this is just the process of converting an analog signal to a digital one (by selecting a sampling frequency, such as every second, tenth of a second, hundredth of a second, etc.). Or, more generally, converting something in the analog world to the digital world. In the back office, this usually means converting paper to documents. But this can just be the process of scanning paper documents to image files, which can not be searched, automatically indexed on key meta-data, etc. That requires (advanced) OCR, and machine learning to take corrections and improve the OCR so that future digitization of faxed documents (sent as images) or PDF documents can be automatically converted into searchable, indexed, text formats with accuracy. So while this isn’t as much of a bullshit term as going digital is, it’s a pretty ambiguous one. A software provider doesn’t have to do very much to honestly say they support digitization given the multitude of (rather weak) definitions that exist.

So this takes us to digital transformation. This is supposed to imply that you dramatically improve all of your business process through the implementation of a new platform that transforms the way you do business to a process that is faster, better, cheaper … and delivers more value. But if you think about this, pretty much any platform you implement is going to transform the way you do business … but is going to be for the better?

So before you fall into the “digital” craze, think about what it really means!

Just like infinite scroll websites aren’t new (that’s what we sorted with before we could frame and tab and paginate, for those that don’t remember), neither is digitization!

Why are We Still Hyping Big Data When We Haven’t Mastered Small Data?

The end of the year is coming, everyone is looking for next year’s tech, and everyone wants cognitive / AI that works on Big Data. But there are two real problems with this:

1. With current hard drive and memory capacities in a single machine, we typically don’t have enough data to fill it (at least with efficient encodings) in our typical back-office functions or unbearable computation times on a quad-core (with efficient algorithm implementations).

2. When it comes to learning, the biggest sets we have for training are typically quite small!

We’ll start with the second point first. Consider spend analytics, where the primary task is to map transactions to a categorization hierarchy. If you want to use a “deep learning” AI, then you need a big data set to train that AI. But how many transactions will the average organization have that have been mapped and verified individually by a human? Maybe 10K or 20K. Even a spend analysis provider will typically have only verified a few hundred thousand or maybe a couple of million compared to the tens or hundreds of millions of transactions its big customers will throw at it a year.

The situation is even worse for contract analytics. A large multi-national might have 20K contracts, but how many have been properly indexed with meta data at the clause and term level? If you have 2K you’ve struck gold. A contracts analytics provider might struggle to cobble together a data set of 20K contracts. This is even smaller data.

And then moving on to the first point. Even though most first (and even second) spend analytics applications are slow, (Opera) BIQ has been able to process and re-categorize a million transactions on a dual-core or better laptop with 8GB of memory in under a minute for almost ten years, and their most recent version on a modern quad-core laptop with 16GB of memory can handle a million transactions in a little over a second! In fact, it can handle ten million transactions in less time than it takes you to enjoy two sips of your coffee. And when you consider that most analytics are only on a set of related categories for a relatively short time period (at most 3 years), the number of transactions is typically only a few hundred thousands for a large company and in the tens of thousands for a mid-size company. That’s not only small data, but data that can, these days, even be processed in your browser (as a new analytics offering will prove next year).

So before you go goo-goo-ga-ga over big data, understand how big your data really is and get the application that works best for your data, which will more likely be at a cost point that works best for Finance as well.

How Much Technical Debt Do Your Vendors Owe You?

And when does the debt become too high to be repaid?

But first, what is technical debt? It’s the debt owed to you by vendors that continually collect moderate to high maintenance fees or annual subscription fees but yet do nothing more than the odd bug fix. These vendors owe you a solution that is continually enhanced year over year. Especially if you are a SaaS client paying big money to keep the solution alive.

And in many of the bigger vendors, it’s growing massively, as chronicled by the deal architect in his post on the other technical debt.

And, as he notes, it’s really easy to spot. When a customer:

  • makes significant customizations,
  • has a stable of “ring-fence” applications, and, most importantly
  • continues to use (large) spreadsheets that were supposed to be replaced by analytical tools

and the customer is still paying a significant SaaS license fee or maintenance fee years after product/platform acquisition, the vendor owes them a huge technical debt.

And as the deal architect pointed out, this debt will continue to grow if they dance to the investors’ tune and only spend 10% to 12% of revenues on R&D annually. Start-ups pay multiples of that, and that’s why they build great new technology. If a company isn’t spending about 1/3 of its revenues on R&D, it’s likely it will never deliver the value you need and its technical debt will only grow.

But don’t wait until its debt is too great to ever be repaid, that does you know good. Once it’s clear a vendor is not going to continually deliver the ROI you need, move on. Once a cost is sunk, throwing more coin on the pile only sinks it deeper.