Category Archives: Technology

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.

Source-to-Pay UIX 2017 (Collected Links)

What Makes a Great U(I)X?

What Makes a Great e-Sourcing U(I)X?

What Makes a Great (Strategic Sourcing Decision) Optimization U(I)X?

What Makes a Great Spend Analysis U(I)X?

UX Epilogue

3-D Printing Will Bring Changes to Direct Sourcing

But not overnight, at least not for the changes being touted as the future of direct sourcing.

Print a part on demand? Not likely. Not soon.

Print a sample part on demand for evaluation — you could have that tomorrow.

What’s the difference?

First of all, today’s 3-D printers can only work with very specific plastics. Generally speaking, these plastics will not be suitable for the vast majority of parts the organization needs.

Secondly, most 3-D printers cannot mass produce parts fast enough to be useful to an organization that needs the parts in quantity.

Thirdly, the economics of 3-D printing today are not nearly where they need to be for mass production compared to current production techniques.

It will be a while before each of these criteria are met, and until they are, 3-D printing won’t be the future of direct sourcing.

But they do have their uses. Let’s say you are collaborating with a supplier halfway around the world in the design and development of a new part. If it requires regular review of a physical part, and getting that part on a regular basis requires global expedited shipments that cost hundreds of dollars a shipment and take up to a week to arrive, then the organization will be spending thousands of dollars on shipments and losing weeks, if not months, of production time while it waits for a part to arrive.

But with 3-D printing, an almost exact replica of the part, down to at least 2mm, even if it’s a metal part, can be printed locally from the CAD/CAM design files. And this can be done for a few dollars in a few hours. This is a significant contribution to the NPD process. And a considerable change to direct sourcing as life-cycles, and costs, can be considerably compressed and quality improved before the first part is delivered.

This simple change alone is significant, and we don’t need to wait for the future to get results. As long as we go in with an understanding of what those results will be.

UX is More Than a Functional Experience, It’s a Program Experience

This year we’ve attacked the UX in Sourcing and Procurement solutions, and for e-Auctions, e-RFX, Optimization, Spend Analytics, and Procure-to-Pay in particular. This was great, but if you really understand Sourcing and Procurement, you know that it’s more than just a set of (integrated) modules with a great user experience. It’s a plan, a process, and, most importantly, a program.

Those organizations that are reasonably advanced in their sourcing journey know that the best success often comes from a category management program that starts with category identification and opportunity assessment, proceeds through a sourcing plan, and then the sourcing process, which culminates in a contract, that then flips over to Procurement which issues a purchase order, receives one or more goods receipts and invoices, issues approvals, and, finally payments. This is all part of a program that works against a project plan and one or more category goals.

This project plan also needs to be managed. Hopefully within your S2P suite, but if not, in another tool that, hopefully, integrates with the S2P suite or, in some cases, the organization’s mix of best-of-breed Supply Management applications. But, as one might surprise by now, such a tool must be immensely usable and provide a great user experience if it is to be used.

However, this is easier said than done because simply slapping a great user experience on a traditional project management tool is not going to cut it. This is because the types of programs that revolve around Sourcing, SRM, Analytics, and P2P are considerably different and require functionalities considerably above and beyond a typical project management application. In other words, slapping a category management theme onto a project management or sourcing application won’t make the grade.

This is why the next UX series produced by the doctor will be on Program Management UX, with the P2P posts co-authored by the revolutionary. So keep a watchful eye out for this one — it might help you understand some of the key functionality that should be included in your S2P platform, which many platforms are still missing today.