Category Archives: Market Intelligence

Breaking Down The Barriers: Data Integration/Management/Analytics

We’re continuing our foray into the top barriers to success that we outlined in our top barriers post that chronicles the barriers that keep coming up over and over again in every Procurement survey in our effort to ensure that you don’t have to read another state of procurement study for the next 5 years. Today we turn to one of the biggest barriers in any organization, and especially if they don’t realize it. Data*

A Brief History …

Unlike all of the other barriers on this list, this is the one barrier that is relatively new. Up until the introduction of computers in the average business, the only real data that was maintained was the accounting data. Orders, and costs, sales, and revenues. That’s it. Other than that, the
“data” of the business was its contracts (on paper), its product designs (on paper), and its processes (on paper).

But with the introduction of modern computing into the average business in the 1980s, a lot of this data became computerized. Plus, the amount of data collected, and maintained, started to increase significantly over time. In addition to costs you could maintain quotes. In addition to revenues, you could maintain sales volume by product and location. In addition to current designs, you could maintain historical designs and alternate designs being considered.

You could start to collect and maintain market data on commodity costs and availability. You could collect and maintain data on currencies and exchanges and markets. You could build your own database of global logistics options instead of relying on suppliers and trading partners to select local carriers for you. And so on.

As time went on the average business unit went from having essentially no data when computers were introduced in the 80s to having lots of data as the internet took over in the late 90s to having a combinatorial explosion of data by the 10s when there was a SaaS app for everything!

The Problem

As data exploded, a number of problems arose.

  • How do you manage and maintain the data?
  • How do you analyze the data?
  • How do you integrate data from other departments? partners? the internet?
  • What data do you need for a meaningful analysis to make meaningful decisions?
  • What data do you need to send to other departments? partners?

And the reality is that as the data exploded, the need to understand the data exploded, and the need to integrate the data exploded

  • training and technical competence fell behind with each advancement
  • data formats and models exploded (as SaaS apps exploded)
  • internal and external data needs exploded, but the ways to easily get and send the right data at the right time shrank

The Necessary Realization

The data explosion that was supposed to be the blessing has instead become the curse.

  • Every system uses its own storage formats behind it’s own data models — so you need to obtain custom middleware / iPaaS to integrate data between systems, and often services to link in all the systems not supported out of the box
  • Back office analytics software has not kept up — most of the big name software is ROLAP, Relational Online Analytical Processing — where you are limited to drilling down in pre-defined cubes (and it’s not easy to create new cubes to power new reports)
  • Analytics capability has not kept up — the average employee doesn’t know what can be done (and what techniques to use to do it)
  • AI is more of a curse than a blessing — sure it can uncover interesting trends, outliers, deviations, etc. — but it doesn’t really understand the data, whether its prediction on what should be done is accurate (as AI is NOT intelligent), or how to guide you on what additional analysis to do to figure out what to make of its “discoveries”

This means that to make progress you need to understand:

  • what modern analytics is (and what AI is not)
  • what systems support it
  • what systems you need for integration and transformation of data
    (even though most analytics can do all the necessary data transformations, some systems still require proprietary integrations to get that data)

And there is very little education out there on all of this. (A lot of marketing, but not a lot of real education.)

The Technological Requirements

The technological requirements are considerable and require supply chain aware sourcing and sourcing aware supply chain and expertise from source to sink and back again on both sides.

A continuing reminder that if you want guidance in the short term, hope that your favourite provider reaches out to Bob Ferrari of Supply Chain Matters or the doctor and enables us to focus on writing the series (or in-depth e-book) explaining what modern Procurement and Supply Chain Tech needs to look like (and how it needs to be implemented) to address the challenges, reduce the risks, and address the priorities versus just dripping out tidbits as free time permits.

* Remember every office worker’s favourite song!


Well …
I have a little data
I store it on my drive
And when it’s old and flawed
The data I’ll archive

Oh, data, data, data
I store it on my drive
And when it’s old and flawed
The data I’ll archive

It has nonstandard fields
The records short and lank
When I try to read it
The blocks all come back blank

I have a little data
I store it on my drive
And when it’s old and flawed
The data I’ll archive

My data is so ancient
Drive sectors start to rot
I try to read my data
The effort comes to naught

Oh, data, data, data
I store it on my drive
And when it’s old and flawed
The data I’ll archive

If You Want Proper Solution Selection Advice — Hire the A-Team!

In 1972, a crack commando unit was sent to prison by a military court for a crime they didn’t commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, still wanted by the government, they survive as soldiers of fortune. If you have a problem, If no one else can help and if you can find them. Maybe you can hire, The A-Team.

Forty years ago, if you had a problem, you could hire the A-Team, and get a solution. They did what they were supposed to. That’s because there were only a few solutions; developers, implementors, and consultants worked under the same roof on the same team; and, due to the high price tag, the vendors worked hard on delivering enough value to keep their clients and get referrals for new clients.

But then the World Wide Web was invented in 1989 and by 1999, corporations were starting to embrace it not only for online business but for app delivery. SaaS startups burst onto the scene and we went from a few options to a few dozen to a few hundred options for standard office applications within a decade. At the same time, many doubled down on development, not implementation or integration, and implementation shops sprung up. Then consultancies decided that, no matter where they started (strategy, finance, operations management, etc.) they were all going to be technology advisory experts and opened big technology consulting and implementation shops, because they had the size, and the cash, to hire lots of warm bodies fresh out of university desperate to work for a renowned firm.

This is where and when solution selection and advisory began to break down. First of all, the consultants had no deep knowledge of the solution. Second, they had no deep knowledge of the domain. Third, the selection and advisory consultants had little understanding of the implementation requirements. And, due to a lack of deep economic and supply chain knowledge, they all ignored the increasing complexity of global business, the increasing complexity of the software solutions designed to support global business, and the increasing complexity of interaction across platforms and systems.

That’s why you need … The A-Team!

THE BRAINS

First and foremost you need someone who understands the big picture. The domain, the core processes that power the business functions, the levels of operational maturity and how to assess them. Someone who knows how to get to the core of the problem and what is needed in a solution and can lead the team to successful execution. This person ensures the focus is on what’s needed, which is often different than what you might think you want. That the inputs to each successive phase of the selection process are the right one. That the requirement strands flow from initial collaborative root problem identification all they way through final solution implementation and integrations. Someone who ensures every step of the process is designed to maximize your chance of success while being as efficient as possible. Someone who’s always thinking about you.

THE SMOOTH TALKING FACE MAN

Secondly, you need someone who can converse with all of the stakeholders in their language, put their fears at ease, and foster the necessary collaboration between themselves and the solution selection A-Team to help ensure a successful project. Someone who can is capable of securing the data and resources that are needed when they are needed and navigating the tough scenarios when vendors who don’t want a fair and unbiased selection process decide to get down and dirty and bypass the CPO and go straight to the CFO or CEO with fear tactics or unreasonable ROI promises. Someone who’s always there when the client needs someone to be there.

THE HOWLING MAD CRAZY TECHIE
(WHO CAN BUILD AND OPERATE ANYTHING)

You need someone who has a deep understanding of the technology to identify vendors that supply tech that match your should haves, to help you script the demos, to rip apart the RFX responses and demo claims, and give you real, unbiased, solution — and not marketing — based advice. Understanding that goes well beyond the limited knowledge you get as a solution implementor where all you do is set configuration options. You need someone who was trained in tech (not operations, or psychology, or “business” or whatever else gets them into consulting), who built tech from the bottom up, who understands not only what stacks can deliver but what algorithms can deliver, and can assess not only what the tech does now but what it will actually be capable of with further development (as many vendors will claim anything you need is on the roadmap, even though they know that they are not capable of building some of the promised technology as their architecture just wasn’t built to support it).
In addition, this is someone who has spent a large amount of time reviewing and studying every solution they can get their eyes and hands on, not just a small set of clients or the big vendors that dominate every big firm analyst map. Some who loves tech and has lived tech their entire career from even before they entered university/college and through at least a decade of hands on experience (and at least five years of broad space review and experience).

THE TOUGH ONE

When the going gets tough, you need someone who can do the heavy lifting and brute force the project to conclusion. The critical support person who helps the brains with all the stakeholder interviews, ensures the crazy techie has everything he needs, makes sure the vendors get their responses in on time, and runs the project, through fear and intimidation if it comes to that, but usually with a strong, silent, honest-to-goodness resolve to get the project done right, no matter what. Someone who pities the fools not wise enough to engage the services of a team who’s only goal is solving your solution selection problem and moving on to the next engagement after a job well done (and not trying to find ways to hold you hostage and add endless billable hours to the project). Someone who alone has more heart then you will find in entire implementation teams.

But if you don’t believe me, go ahead and keep hiring The F Team. You might be part of the 12% they succeed for (or 6% if its a Gen-AI project). That’s at least a one in ten chance of success for a regular technology selection and implementation and one in twenty chance of success for a Gen-AI technology selection and implementation. Still better odds than the lottery, right?

Myself, I’d prefer odds of success of at least 4 in 5. But, as they say, you do you.

The Seven Step Process for Vendor Assessment and Selection

In our last posting we told you that solution selection is a seven stair methodology, and that the vendor assessment step was itself a seven step process. It’s not just as simple as taking a vendor pool, pulling five names out of a hat, and issuing an RFP, even though some consultancies would like you to believe that it is. But all that does is get you to a wrong conclusion fast.

Vendor selection takes time, sometimes longer than you want, but when you get the right solution, it’s always worth it in the end. Here’s the process outline.

1. RFI Creation

The first step is to create an RFI that accomplishes two things:

  1. verifies the vendor has the necessary must-have functionality to meet core needs
  2. collects the necessary information for rapid fire vendor elimination so you don’t waste time on a vendor that the business can’t accept

2. Collaborative RFI Review

Once the consultant or the analyst does their initial review, does their initial scoring, draws their initial conclusions and documents the rationale, the next step is to work through the RFI collaboratively with the client to make sure that every vendor invited back is not only acceptable to the client, but both parties understand the reason why vendors were cut.

3. Qualifying Demo

Before the full RFP, a demo verifying the promised must-have functionality must be taken to make sure what was written is currently in production and that the vendor truly understood the requirements. This can be considered phase two of the rapid fire elimination phase and strengthens the reasoning for any vendors pushed forwards.

4. RFP Creation

The next step is to create a full RFP that:

  • goes beyond the core and includes questions related to the should-have and value-add functionality appropriate to your needs (not some random feature list)
  • allows all organizational requirements for vendor onboarding to be evaluated
  • allows for an assessment of the depth and breadth of services and training provided by the vendor
  • contains additional questions designed to elicit the input necessary to answer any questions that come up from the RFI and initial demo review
  • address all of your business requirements (not just the ones that permit rapid fire vendor elimination)

5. Collaborative RFI Review

Once the consultant or the analyst does their initial review, does their initial scoring, draws their initial conclusions and documents the rationale, the next step is to work through the RFI collaboratively with the client to make sure that the client’s final two/three vendors are not only appropriate, but all of the strengths and weaknesses that can be assessed are understood.

6. Deep Demo Specifications

You need to give each vendor their own demo script that you want them to execute because it’s your problems you need to see solved, not their best whizz-bang features that look good but function poorly.

7. Decision

After the consultant provides their deep dive analysis of the demo and their overall vendor assessment, using all the information at your disposal, you make a decision that you believe will best serve your organization.

In other words, it’s a methodical, deliberate, process that takes what it takes because that’s the only way to ensure you get the right solution. But it will be worth it because the right solution will bring an ROI of at least 5X while increasing efficiency between three-fold and ten-fold once adopted, but the wrong solution will be an albatross around the necks of every employee that depends on it.

Assisted Solution Selection is a Seven Stair Methodology

… and skipping any step breaks the strands that are necessary for success.

And the process is a lot more involved than most consultants or analysts believe it is. But first, let’s outline the steps the consultant or analyst has to walk through if they want to reverse the odds and give you an 80% chance of success vs. an 80% chance of failure.

1. Real Need Identification

We’ve all forgotten the wisdom of Richards and Jaggaer, and the realities of life. You Can’t Always Get What You Want but if you try sometimes you just might find that you get what you need. But you have to try. And so does any consultant or analyst who purports their desire to help you.

2. Holistic Solution Requirement Assessment

This is NOT technology. Not even close. This is identifying what results would define a solution, what processes would get you there, and what resources — people AND technology — are needed to get there.

3. Organizational Maturity

The solution has to be appropriate for the organizational, and technical, maturity of the organization. If someone has only ever ridden a horse to get from point A to point B, you can’t drop them in a Boeing 737 cockpit during mid-flight and say “good luck”. But that’s what happens in the vast majority of technology solution identifications and implementations — an organization running off of email, spreadsheets, and word documents is being told to upgrade to a modern best-of-breed AI-orchestrated source-to-settle platform with advanced optimization models, multi-stage analytics, twelve-step supplier onboarding and evaluation, 360 risk and compliance, multi-channel procurement, AI powered payments, and features with no apparent use. The solution has to be matched to the organizational capabilities with an future upgrade plan consistent with the rate the organization should be capable of maturing.

4. Vendor Pool Selection

The vendor pool has to be a set of vendors that meet all of the core requirements identified in the holistic solution requirement assessment, in a manner appropriate for the client’s organizational maturity. Clients should NEVER have to evaluate whether a vendor meets the core requirements, but how it meets the requirements; what should, nice-to, and value-add functions are included in their offering; and how they can effectively be a partner, and not just a provider, to your organization.

5. Vendor Assessment Process

A seven step process that centers the RFP and helps the client make the right selection.

6. Project Assurance

Processes that stop at the selection of the vendor can cut the chances of success in half. Implementors don’t understand how the conclusion was reached, vendors don’t understand the client’s unique situation, and neither are incentivized to ensure success. Independent, unbiased, project assurance is key.

7. Post Implementation Monitoring, Advisory, and Training

A successful implementation does not guarantee success — that requires adoption, continued utilization, and results. That might require training, that might require ongoing support, that might require additional advisory. There’s no success until an ROI is achieved.

Moreover, each of these steps needs to be powered by an appropriate model and methodology that is standardized, domain appropriate, and continually enhanced by firm knowledge and best practice. Not just a seat of your pants assessment entirely dependent on the individual’s knowledge and experience.

Furthermore, each of the models and methods used in each step has to build on the outputs of the models and methods of the last step so that each implementation requirement can be traced all the way back to a need and each need can be traced all the way forward to an implementation requirement. If you can’t trace complete “strands” from end-to-end, you can’t expect success.

Breaking Down The Barriers: Lead Times/Supplier/Carrier Issues & Supply Chain Visibility/Network Complexity

We’re continuing our foray into the top barriers to success that we outlined in our top barriers post that chronicles the barriers that keep coming up over and over again in every Procurement survey in our effort to ensure that you don’t have to read another state of procurement study for the next 5 years. Today we are covering supply chain visibility and the issues it creates.

A Brief History …

This is very closely related to our last barrier of supplier reliability. In many ways it’s the same, except this one is more from a supply chain focus than a procurement focus and is more focussed around logistics, warehousing, free trade zones (FTZs), etc. Not only do you have supply assurance issues now that you’re sourcing from tens of thousands of suppliers all around the world, but you have lead time and carrier issues as well as issues of network complexity and real-time transportation balancing.

The Problem

We discussed the core problems of supplier and third party management and supply chain visibility in our last barrier, but that was just scratching the surface.

We now have the problem of logistics planning, modelling and real-time tracking. This is much easier said than done when sourcing from half a world away. How does it get to the “local port”? How does it get to the “destination port”? How does it get from the destination port to the local warehouse? Do you need cross-docking and load consolidation/splitting anywhere in that delivery chain? If so, will this involve intermediate warehousing anywhere along the delivery chain and/or will you need to manage intermediate warehousing at a Free Trade Zone next to a port where you transship to a neighbouring country?

All of this should be done before a supplier is selected to understand how it will impact the current network? Will it utilize the existing distribution network fully (because the supplier is in a city where you have a carrier already that can tap right into your existing supply network in the region)? Partially (and require you to find a new carrier to a local hub and / or lease a new warehouse for storage and cross docking)? Or is it in a new region/country you have no supply network at all and would require considerable upgrades, or changes, to your supply network. Otherwise, if this is done after the contract is signed, it could be a mad dash to try and get something, anything, in place before the shipment is needed, leading to suboptimal decisions and network designs that negate all of the expected savings from the new supplier and/or the other expected advantages (such as carbon in the logistics chain, shorter lead times, etc.).

Then there is the issue of warehouse and (remote) inventory management, as we know that, done poorly, this can increase your logistics and product costs considerably! You pay the same for a warehouse lease whether it is empty or full. Power and heat are quite consistent too. Water might increase slightly if you have a large staff, but that’s it. This means only a warehouse that is consistently mostly full is cost efficient. (In other words, you want inventory flowing through it regularly and keeping it near capacity.)

And, of course, you want to integrate all of this into your supply chain visibility solution so that you’re not just maintaining visibility into your suppliers, but also your carriers and your warehouses. A full supply chain network view.

The Necessary Realization

Supply chain aware sourcing is quite a challenge. It’s not just the supplier, it’s the supply network — the carriers, the warehouses, the ports — and all of the players you need visibility into. That’s why you not only need the:

TPRM (Third Party Relationship Management) solution and the SCV (Supply Chain Visibility) solution discussed in our last post, but also need:

A Logistics / Transportation Management System (LMS/TMS) to maintain (near real time) visibility into your global transportation network to track where your goods are and when they are expected to reach each stop in your network and finally be delivered.

A GTMS (Global Trade Management Solution) that allows you to manage free trade zones, import and export documentation (to keep things flowing on time), and (those beautiful, beautiful) tariffs.

And, of course, you need to understand not only how to link all of these systems but deploy them in unison so everyone has the right view at all times.

Then, each person involved in the chain needs to know how to make use of the information presented, and make the right decision keeping the needs of the other department in mind as well as the organizational priorities and goals. Easier said than done as there is a need to balance, at a minimum, Procurement, Supply Chain, Logistics, Risk Management, Operations, and possibly, Finance.

The Technological Requirements

The technological requirements are considerable and require supply chain aware sourcing and sourcing aware supply chain and expertise from source to sink and back again on both sides.

A continuing reminder that if you want guidance in the short term, hope that your favourite provider reaches out to Bob Ferrari of Supply Chain Matters or the doctor and enables us to focus on writing the series (or in-depth e-book) explaining what modern Procurement and Supply Chain Tech needs to look like (and how it needs to be implemented) to address the challenges, reduce the risks, and address the priorities versus just dripping out tidbits as free time permits.