Category Archives: RFX

Cutting Edge Tech Is NOT Defined by the C-Suite, …

… Financiers, or the Marketers pushing hype (from the A.S.S.H.O.L.E.) at you 24/7.

Nor is it defined by the algorithms it uses, the software stacks it runs on, or the hardware stacks it makes use of.

Cutting edge tech is ANY and ALL tech that

  • solves one or more significant problems that not being solved by your tech today and
  • does it by automating at least 90% of the tactical data processes that can be automated

It can be based on the latest AI algorithm or twenty year old RPA. It doesn’t matter if it shines a light using a LAMP stack, if it is an edgy MEAN stack, an Austin Powers inspired Grails stack, or even a .NET stack (though the doctor personally shuddered typing those last three caps out). The entire point of enterprise software is to solve your problems.

The point of software is NOT to provide

  • an excuse for a C-Suite to cut his tech-bro buddy a fat check,
  • a new Tulip Market for greedy financiers who think they can score big and get out before the crash, or
  • marketers a platform to pump out pompous poop on a daily basis.

As Mr. Koray Köse penned in a recent piece on LinkedIn on how you are in need of cutting edge technology, the last thing you want to do is take your direction from the VC-pumped C-Levels who do nothing but repeat the marketing garbage they are fed, sometimes changing the baseline of the garbage mid-sentence!

You have to remember:

  • All the VCs and most of the PEs want to create the next unicorn and get rich quick overnight. So most of these VCs and PE firms are pumping huge amounts into companies with little to no product (to support their grand vision that even SAP and Oracle haven’t managed to achieve after 5 decades and trillions of dollars) and directing the majority of that to be spent on buzz-creating sales and marketing (and not real product development). After all, you don’t actually have to create anything beyond buzz to get rich — market crashes throughout history have proven that since Tulip Mania. (What was created there of value? Nothing. But hype made a few men rich and many men poor.)
  • Even though today’s LLMs are dumber than a doorknob (and demonstrate more than any previous generation of the tech that AI should stand for Artificial Idiocy), with performance degrading every iteration (because there is no more data to steal, and the AI engines are now training each other on regurgitated digital garbage), marketers are still taking storytelling to a whole new level (and we mean storytelling because ALL the claims are fake) with a spin that even the Spin Doctors of old would be envious of. (Little Miss Can’t Be Wrong now, right? They want to Make You A Believer so you hand over all your Money when you should Exit … Stage Left and Run To The Hills!)
  • This copy is being pushed onto the C-Suites of all of the other investments in their portfolio with assurances that it’s all true, and being similarly echoed to all of the CXOs that attend the conferences they speak at, the golf outings they are invited to, and the exclusive social gatherings they arrange.

Not one of these groups knows what you need, and two of these groups have absolutely no interest in giving it to you — their interest is all about getting your money, building the hype, inflating the value, and, hopefully, cashing out big before the next hype cycle and/or the inevitable market crash that’s coming.

The technology you need is the technology that is:

  • built with real world problems in mind,
  • tested on real world problems in real companies and proven to deliver, and
  • scalable and extendable to your operations and needs.

This type of tech is built over years and doesn’t use unreliable probabilistic AI at the core. (It runs on traditional, configurable, RPA that is 100% reliable and auditable. Now, this tech might employe AI to help with the configuration by analyzing your systems and processes and self-assessed gap analysis by recommending configurations for you to approve, and that’s okay, because it’s not randomly making decisions, its recommending options and letting you confirm or deny. It might also use SLMs for specific problems where they work a high percentage of the time to jump-start searches, documents, and processes for you, and as long as you retain full control and can accept, modify, or reject, that’s okay too. But everything is built on a solid core, with 100% dependable automation for all key data intake, processing, and pushes that is done without any manual intervention, appropriately calibrated to your business rules, processes, and goals.)

It’s also built slow, rolled out to a small group of beta customers or development partners, and hardened in the field before being rolled out en masse.

And, most importantly, it’s built by a company that is boot-strapped or frugally running on a shoe-string budget from minority SEED investors to get that first version up-and-running successfully in its first 10 customers before that company goes for any VC funding to scale up. A company that has the time to get it right before being under constant pressure to make demanding, if not impossible, sales targets.

Moreover, to have any chance of getting this software, you need to know three things:

  1. how to identify what you need that will form the heart and soul of the RFX,
  2. how to write a good technology RFX and analyze the responses, and
  3. how to identify the right companies to invite to the RFX.

What You Need

For Supply Chain, as Mr. Koray Köse points out, if you need help identifying your true needs and cutting through the noise, he can help you out with that with the eyes of a hawk, the skill of a surgeon, and the wit of a Williams (a Robin Williams). For Procurement, Joël Collin-Demers can slice through your organizational landscape like a hot knife through butter and let you know exactly what you need in priority order.

The Technology RFP

Every consultancy and their mascot claims they can help you here, but you need to be very, very careful.

  • many of their consultants are not technology experts and tend to prioritize features over functions, as that’s all they know
  • many of these firms have partnerships with the (mega) suite players, and you don’t maintain sycophant, sorry, Gold/Platinum/Diamond, status unless you direct a LOT of business their way each year, so they tend to try to fit everyone into one of these buckets
  • many follow the old consulting model of “give the client exactly what he thinks he wants” and don’t take the time to figure out what you actually need and educate you, leading to an RFP that is no better than what you would have written yourself, as they spend half their time questioning you, and the other half writing down your responses

For true success, you need someone who is simultaneously:

  • an expert in the domain,
  • an expert in technology, and
  • not incentivized to help any vendor whatsoever and, preferably
  • an expert in project assurance (but not always necessary)

If you need help writing that ProcureTech / Direct Sourcing/Supply Chain RFP, feel free to reach out. This is my expertise. And for some tips, feel free to start with our recent series on How Do You Write A Good RFP?

Vendor Selection

Very few analysts and consultants know more than a handful of vendors. The big firms focus on the big vendors who cut big cheques, which are the 20-ish same vendors you see in their maps year after year after year. They don’t know about the other 700. Only a few of us independent analysts go far and wide and actually know what is out there and how it can help you.

For ProcureTech, SI should be your first stop. It’s the site that gave you the mega map to open your eyes as to just how wide the playing field is. Moreover, if you need something really niche where the doctor doesn’t have the expertise, he’ll find the right expert to refer you to.

For SupplyChain, Mr. Köse knows a lot of the players. But don’t overlook Bob Ferrari of The Ferrari Group. As one of the original supply chain analysts, he knows all the players and what their platforms can and can’t do inside and out.

And if you reach out to the right experts and get the right help, maybe you can get true cutting edge tech that actually helps you!

How Do You Write A Good RFP? Part V: Software

As per the many series we have written on this over the years, this is often the hardest RFP to write, because it’s really hard to specify what you need when you don’t understand software, what’s on the market, what it can do, and when it can’t. Especially when you’re inundated daily with marketing about why you need SoftwareSpectacle Version Seven with the latest and greatest self-sealing AI technology to solve all of your function X business processing needs. And then vendor Y comes along with Binary BitBlaster Release Bravo with the new and improved board-based AI-backed BI technology that will do even better!

As we’ve said again and again in our many series on technology selection and RFPs, which include:

Unless you are a tech expert, you can’t truly know what you want. We’re at the point that even most analysts, especially those who work at the big firms and who need to spend at least half of their time on client advisory to justify their positions, don’t even know half of what’s out there (as evidenced by the maps they publish year after year with the same 20-ish vendors when, in some areas, there are over 100 providers, as can be attested by the Source-to-Pay Mega Map).

As with services, the only way to get close to what you want is to focus on specifying what the software has to do, who it has to do it for, what outputs are required, what systems it needs to integrate with, where it fits in the ecosystem, and how the affected individuals are expecting it to make their job better. The vendors really need to define the specifics of how the software will accomplish its tasks and how they will deliver it to do that.

Keep that it mind, along with the best practices we outlined in Part I, and you’re well on your way to writing a good Tech RFP, as long as you steer clear of the “Free RFPs” (as there is no such thing as a FREE RFP). For more best practice advice and insight, see the prior series.

This concludes our initial series on how do you write a good RFP. Hopefully you found it useful.

How Do You Write A Good RFP? Part IV: Services

When it comes to services, many buyers think this is the easiest RFP to write, because you just have to specify what you want, right (wrong, but more on that later), but it’s really the hardest, and not just because, until recently, no tools were ever constructed to help with this.

It’s the hardest because the instinct is to specify what you want when the reality is that you have no clue what you want (because if you did, you wouldn’t have a problem or a need that required you to go out to market for a service). You know what is not being done, what problems need to be solved, and that if you don’t take care of it, things will get worse, but if you knew exactly what you wanted, that’s a specific resource to fill a specific role and an RFQ for contingent worker/contractor worker rates and possibly one or more products or tools to get the job done.

As with indirect and direct, if you are going out for an RFP, you are looking for a solution, but unlike indirect and direct, you are looking for an inclusive solution where the vendor will identify all of the resources required — be they personnel, products, or software — and put together a solution that will meet your needs and do so at a price lower than your organization attempting to do everything in house, either because they have the expertise to do it better, the resources to do it faster, or the scale to do it cheaper, or all three.

It’s absolutely critical here to focus in on the processes you want implemented, the problems you want solved, and the deliverables you expect. Not on the personnel you think you need, the systems you think should be put in place, or the reports that should be produced. Clear descriptions of what you are doing now, why it’s not working, what kind of improvement you are looking for, and what outcomes you desire (metrics, etc.) are a must.

It’s also critical to focus on what type of operation you are, how you run the processes you are not outsourcing, your organizational culture, and how you would interface with the service provider on an ongoing basis. This defines the what you are looking for because it’s not just what needs to be done, but how it needs to be done to support your organization.

As with indirect and direct, the who, what, where, when and why is more critical than the how.

How Do You Write A Good RFP? Part III: Direct

This is not so easy, right? After all, the number of sourcing platforms out there that support direct is about 1/10 of the platforms that support indirect, and they tend to be over-the-top suites, new startups still building out complete solutions, or over-customized to particular industries. The exceptions to these rules are few and far between and you have to look. But this isn’t why it’s not easy.

As per our last post, the platform alone doesn’t make writing a good RFP easy. If you don’t have the knowledge of what goes into a good RFP, and the platform doesn’t provide it, it doesn’t matter if the platform is the best one out there.

And when it comes to direct, since you’re usually looking for a component, part, or raw material to support a product or system build, you need a lot more insight into what the (end) product or system is as well as the requirements for the component, part, or material.

Again, if you need grade 5 carbon steel bolts for your bus frame, that’s an RFQ, as you are going out to market for a very specific product. You’re going out for an RFP when you’re doing NPD/NPI, and you’re trying to figure out the best component, part, or material to use in your new design.

The key here is to be specific about two things:

  1. the intended use and goal of the product or system
  2. the form factor, durability, capability, and integration requirements of the component, part, or material being sourced

For example, in the first case, if you are building a power transformer, is it a DC to AC converter to allow people to run small appliances off of their truck battery or is it a stepwise transformer to convert power over a long distance transmission line (that can be over 750,000 volts) to a local substation to power a 460V distillery. This makes a big difference in the required durability and design of any component you plug in.

In the second case, if you are looking for an FPGA, you’re going to specify the preferred and maximum dimensions for that power transformer, the durability (based on expected lifespan), capabilities required (simple display to dynamic stepwise current recalculations based on fluctuating power in the lines to give forewarning of a power drop or cut-off if it predicts a surge that will flip the breaker), and integration requirements (pins, bus speed, etc.). You’re not going to specify the entire design, materials, etc.

Again, it comes down to specifying the need more than the actual design or product. Because if you need a specific product, that’s an RFQ.