Category Archives: SaaS

Kodiak Hub: A Supplier Relationship Management for Sustainability

Kodiak Hub is a relatively new Swedish solution for Supplier Relationship Management. Founded in 2015, it primarily served the Nordics for its first few years but began its expansion into the DACH and UK Regions during COVID (and even serves the NA market, although they don’t plan to tackle the NA market until the coming year).

A visit to its site might lead you to believe it’s a category management platform, billing itself as the starting point in a journey towards smart strategic sourcing, but that’s not quite what it is, or at least not where it’s found its niche and its true capability shines.

It’s true capability shines in sustainability, responsibility, risk assessments, and performance evaluations of suppliers, and their products, where those suppliers are creating (custom) (build-to-order) (manufactured) products where regulations need to be adhered to, carbon/GHG needs to be reported, and the organization needs to ensure they are acquiring a sustainable product (or service) as well as a sustainable supplier.

It’s primary platform is organized into three sections: Insights, Impact, and Intelligence along with a home dashboard that visually shows you the regions of all of your global suppliers and allows you to hover over those regions to see the number of suppliers, the regional economic rating, and the Country safe(SOURCE)TM Rating.

The safe(SOURCE)TM Rating is one of the truly unique capabilities of Kodiak Hub and one of the capabilities that positions it as a strong Sustainable Supplier Relationship Management platform. Using indices and public data sources, it is able to create a regional risk assessment profile that allows an organization to quickly spot geopolitical, environmental, and sustainability risks even before sending out an assessment to a supplier, and to create a generic risk profile when specific information is (not) yet available. When this is combined with local economic indicators (to spot risks of [significant] currency fluctuations, increased bankruptcy, etc.) as well as the ability to pull in credit scores (from credit agencies) (with appropriate data feed subscriptions), it provides an organization relatively deep insight into what expectations it should have for a supplier even before analyzing its policies, practices, and external assessments.

The supplier profiles or scorecards that Kodiak Hub can maintain are quite extensive, allowing an organization to maintain all the compliance, performance, risk, and sustainability data it needs on suppliers, products, and services to power its supplier management, sourcing, and procurement. It supports all standard company profile data, including supplier type and spend totals, detailed (customizable) assessment data, detailed on-site audit data (which will override the existing data as necessary), (third-party) risk/ESG/CSR data/rankings/metrics, externally computed KPIs, and related company, product, and service linkages. It can also store any and all documents of relevance or interest (insurance, certification, specifications, contracts, etc.).

Insight is the entry point to the platform’s supplier, product, and services summary screens that capture, and allow a user to query, all of the data associated with a supplier, product, or service.

Impact allows you to create and dive into (data-driven) supplier assessments, (onsite) supplier audits, KPI-based evaluations, and identified actions (in progress).

Assessments are unlimited and can be on the supplier in general, specific products or services, and even restricted to specific category management or sourcing projects. They can cover quality, health and safety, compliance & governance, human rights, environmental, business, product, information security, and other areas of relevance to the organization and use pre-built (template) questionnaires, customized variants, or custom questionnaires.

Right now, even though they can be assigned a “type”, actions are essentially requests to the suppliers with an integrated messaging trail for asynchronous communication that allows suppliers to ask questions, buyers to provide answers, and action states to be recorded (pending approval, in progress, completed, etc.). Future versions of the platform will contain specific types to ensure necessary information is captured, processes and workflows are followed, interim checks and approvals are in place, and so on.

Intelligence is its integrated analytics platform that allows a procurement professional to analyze suppliers across campaigns, projects, KPIs, assessments, categories, products, capabilities, etc. Relationship managers and buyers can create custom dashboards and reports, and customize the pre-built dashboards as needed.

The UX is very clean, modern, broken into logical segments, and very easy to use. It’s intuitive where to go to get the information you need and how to update new information when it comes in. This reviewer finds it so intuitive that he believes you can jump in and be productive with it without any training whatsoever.

So if you’re looking for a great supplier relationship management platform to manage your sustainability efforts and assess your supplier risks, we recommend you include Kodiak Hub in your shortlist.

Suite vs BoB. Which Do You Choose?

Neither!

But you need something. And there is no other option (yet). So are you doomed?

That depends. But first, let’s talk review the Primary Pros and Cons of each.

SUITE
BoB
PRO

  • one vendor relationship to manage
  • modular integration out of the box
  • consistent UX (or it’s not really a suite)
  • pre-implemented with major ERPs
  • the primary module offered by the vendor is truly Best in Class and considerably beyond the average suite capability
  • implementation is typically vendor supported, along with some integration services
  • low (subscription) cost out of the gate, pay as you need
  • today’s BoB comes with full, complete Open APIs to build your own ecosystem
CON

  • likely that only one or two modules are Best-of-Breed (BoB)
  • implementation and integration services are likely third party
  • high cost out of the gate
  • traditionally a closed ecosystem
  • multiple vendor relationships to manage
  • limited integrations out of the box to other modules you will need
  • inconsistent UX across the modules
  • limited to no ERP/MRP support in many modules

In other words, many of the weaknesses of the suites are the strengths of BoB and vice versa. But you want the strengths of both and the weaknesses of neither, even though that doesn’t exist today as no vendor does everything well, nor can they because they would need to be experts in everything. (So unless a vendor hired all the experts, and became a monopoly [and we generally agree monopolies are bad], no vendor could even come close.) Even if a vendor did hire all the experts of today, and build everything out to the best of those experts’ capabilities, they’d soon become an unaffordable mega-suite (and then still not be best in breed in anything because once they built what the experts they hired envisioned, there would be a new generation of experts they still wouldn’t have employed with new, innovative, possibly revolutionary, ideas).

So what do you do? Well, the answer is, as we pointed out in our post that asked where’s the Procurement Management Platform, acquire a platform that is designed to support data-centric end-point integrations for specific processes and organizational needs as this will allow you to select the right module for each task, configure the right procurement workflows, integrate new, even previously unthought of, modules with the Open API, and even support intake and supply chain platform integration.

But, as we noted, there’s no platform. So, unfortunately, you have to assemble your own. But at least today you can. A decade ago there were no options to do this, so either you bought a suite, and lived with it, or you bought best of breed and did extensive work to glue them together in a grit, spit, & a whole lot of duct tape situation (that would take about 69 months).

But today, all of the new best of breed applications are being built from the ground up with complete Open APIs and the newer suites are also offering you APIs to easily get data in and out as well. (Not so much on the workflow configuration / function execution front, but that’s not necessary.) [But please note that an App Store or Marketplace is not an Open API, it’s a closed ecosystem limiting you in what third party add-ons you can select.]

So you can theoretically start with the right instance of a BoB or a Suite as your base and build out the right platform over time, depending on your needs today, and how fast you can digest a new module. If you already have one or more first generation modules, you have the understanding of what these modules do and how to use them and can likely digest new versions of those modules pretty quickly, so you could start with that many modules plus one. If you have no modern S2P modules, then, as we indicated many, many times in our very long Source-to-Pay series, you need to pick a module that represents your most immediate need, start with it, and start to grow your platform from it.

The 39 Steps … err … The 39 Clues … err … The 39 Part Series to Help You Figure Out Where to Start with Source-to-Pay

Figuring out where to start is not easy, and often never where the majority of vendors or consultants say you should start. They’ll have great reasons for their recommendations, which will typically be true, but they will be the subset of reasons that most benefits them (as it will sell their solution), and not necessarily the subset of reasons that most benefits you now. While you will likely need every module there is in the long run, you can often only start with one or two, and you need to focus on what’s the greatest ROI now to prove the investment and help you acquire funds to get more capability later, when you are ready for it. But figuring out how much you can handle, what the greatest needs are, and the necessary starting points aren’t easy, and that’s why SI dove into this topic, with arguments and explanations and module overviews, both broader and deeper than any analyst firm or blogger has done before. Enjoy!

Introductory Posts:
Part 1: Where Do You Start?
Part 2: Where Should You Start?
Part 3: You Start with …
Part 4: e-Procurement, and Here’s Why.

e-Procurement
Part 5: Defining an e-Procurement Baseline
Part 6: There are Barriers to Selecting an e-Procurement Solution (and they are not what you think)
Part 7: Over 70 e-Procurement Companies to Check Out

Interlude 1
Part 8: What Comes Next?

Spend Analysis
Part 9: Time for Spend Analysis
Part 10: What Do You Need for A Spend Analysis Baseline, I
Part 11: What Do You Need for A Spend Analysis Baseline, II
Part 12: Over 40 Spend Analysis Vendors to Check Out

Interlude 2
Part 13: But I Can’t Touch the Sacred Cows!
(including Over 20 SaaS, 10 Legal, and 5 Marketing Spend Management / Analysis Companies to Check Out)
Part 14: Do Not Stop At Spend Analysis!

Supplier Management
Part 15: Supplier Management is a CORNED QUIP Mash
Part 16: Supplier Management A-Side
Part 17: Supplier Management B-Side
Part 18: Supplier Management C-Side
Part 19: Supplier Management D-Side
Part 20: Over 90 Supplier Management Companies to Check Out

Contract Management
Part 21: Time for Contract Management
Part 22: Contract Management is a NAG: Let’s Start with Negotiation
Part 23: Contract Management is a NAG: Let’s Continue with [Contract]Analytics
Part 24: Contract Management is a NAG: Let’s End with [Contract] Governance
Part 25: Over 80 Contract Management Vendors to Check Out

e-Sourcing
Part 26: Time for e-Sourcing
Part 27: Breaking Down the ORA of Sourcing Starting With RFX
Part 28: Breaking Down the ORA of Sourcing Continuing with e-Auctions
Part 29: Breaking Down the ORA of Sourcing Ending with [Strategic Sourcing Decision] Optimization
Part 30: Over 75 e-Sourcing Vendors to Check Out!

Invoice-to-Pay (I2P):
Part 31: Time for Invoice-to-Pay
Part 32: Breaking Down the Invoice-to-Pay Core
Part 33: Over 75 Invoice-to-Pay Companies to Check Out

Orchestration:
Part 34: How Do I Orchestrate Everything?
Part 35: Do I Intake, Manage, or Orchestrate?
Part 36: Over 20 Intake, [Procurement] [Project] Management, and/or Orchestration Companies to Check Out
Part 37: Investigating Intake By Diving In to the Details
Part 38: Prettying Up the Project with Procurement Project Management
Part 39: Deobfuscating the Orchestration and Fitting it All Together

Just What Is a Start-Up?

Do you know? I bet you don’t! And based upon what he’s seeing in the market, even the doctor doesn’t know anymore! (While he knows what a start-up has traditionally been defined as, that doesn’t appear to be the definition anymore, but we’ll get to that.)

Investopedia defines a startup as a company in the first stages of operations.

TechTarget defines a startup as a newly formed business with particular momentum behind it based on perceived demand for its product or service.

Wikipedia defines a startup as a company undertaken by an entrepreneur to seek, develop, and validate a scalable business model … intend[ed] to grow large beyond the solo founder.

Forbes defines startups as a young company founded to develop a unique product or service, bring it to market and make it irresistible and irreplaceable for customers.

StartUps.com quotes Eric Ries and defines a startup as a human institution designed to create a new product or service under conditions of extreme uncertainty.

You get the point. A startup should be:

  • new
  • innovative (seek, develop and validate; unique product or service)
  • market demand focussed
  • growth focussed beyond the founder / founding team
  • awash in uncertainty

This should mean that a company should no longer be considered a startup when:

  • it’s no longer new (after some reasonable amount of time has passed since product launch)
  • the product has been out long enough to be replicated or surpassed by competition (who figured it out on their own without IP theft)
  • the market demand has evolved based upon the product capability
  • it’s grown beyond the founders (and stabilized)
  • the company has been operating with reasonable stability for a while

And while you might debate whether or not

  • a company is still new after 1, 3, or 5 years
  • a company is no longer innovative when it has been equalled or if it’s when the competitors have stabilized
  • the market demand has grown as a result of initial adoption or if a couple of extra years are required for the market capability to mature
  • the company is large enough when the team is double the size of the founding team or if it needs to be triple, quadruple, or based on industry averages
  • you need 2, 3 or 5 years of stability

the doctor is quite certain the majority of you would agree that a company is NOT a startup

  • if it has been in existence and live with its product for over 5 years
  • any semi-unique capabilities have long been equalled by companies that followed (where some of those followers may even have been acquired for their maturity)
  • the market demand has considerably grown and matured (possibly to the point that even related solutions were started, grew, and were acquired into mainstream suite players)
  • the company has surpassed 10-15 employees or quadrupled in size relative to its founding team, whichever is larger
  • if it has well over 5 years of stability

But yet, on the list of companies being considered for the Demo 2023 start-competition at DPW, you have a company that:

  • has been in business for 13 years with a beta product in testing the year it was formed
  • barely had any unique capabilities on launch (just had a much lower price point and easier UX and added some semi-unique capabilities as it went along, along with stronger back-end processing, but since then new startups have come along that equalled it and one was acquired)
  • the market demand has consistently grown and matured since before the company was founded to the point related solutions were acquired and integrated into suites
  • the company is almost 10X it’s first month size (and over 100 employees)
  • while it had years of stagnation from a growth perspective, it never shrank

WTH? This is simply ridiculous. They basically let a company check a box and call itself a startup without any validation whatsoever (presumably because that company knows its only chance of winning a competition or award is to call itself a startup). It’s sad, and it’s not useful. the doctor has already complained about analyst firms (associations, and conferences) inventing meaningless awards, but if you’re not going to have any requirements or quality control, even the awards and competitions that could be meaningful are now meaningless as well.

And the doctor has to rant about this because it’s not just DPW that are including mature small companies in their startup competitions and startup award categories, it’s the majority of the publications, conference, and analyst firms in the space. DPW is just the latest example the doctor has seen over the last few years (and the one that pushed him over the edge).

(There’s a reason that, at least when he was Lead Consulting Analyst at Spend Matters, the doctor argued for strict limits on length of existence, product availability, customer count, and market size in the Future 5. Without guidelines, requirements, and limits, the designation is meaningless.)

So while the doctor might be calling out DPW as allowing one of the most egregious mischaracterizations of “start-up” that he has seen in quite some time, they should not be singled out, and definitely should not be singularly judged, for this. It doesn’t take more than a little research across the other analysts firms, associations, and award-giving conferences and directories for one to discover DPW is not alone in using a very loose definition of start-up (which sometimes barely qualifies in the “small company” category). Some days it seems that the majority of outfits are allowing any company that wants to be a startup to call itself one as long as it is under some arbitrary revenue number or employee count, even if the company should not have been considered a startup for over five years.

This is a problem that plagues enterprise software, and one, as professionals, we need to demand be fixed. Words and classifications have meaning, and the minute an organization that should be verifying that the words and classifications are used correctly stops doing so and allows anything to be anything, those words and classifications no longer have meaning and any evaluations (or awards) based on those words and classification lose all meaning.

As with an illogical insistence on undefined “AI” or maps that mesh 6 different, barely related, subjective factors into a single dimensional score, these categorizations are unhelpful, and may even cause harm when a company is misclassified as a startup. Some organizations are so risk averse that they will not deal with any company that has wrongly been called a start-up, and others will choose that startup assuming it’s in early stages and going to get bigger and bigger over time (and they should contract with the winner before it gets big and its prices go up, assuming it will fill in the missing functionality that they want over time as more employees are added). But how big a company gets is not just a function of (more) time, it’s a function of what it offers, how much of the market can use what it offers, and how much the company can sell it for. Some companies with niche offerings will never reach an arbitrary revenue threshold, and some with ultra efficient operations will never reach an arbitrary employee threshold, which means neither of these metrics (which are not part of the definition of startup) are an acceptable measure.

And it’s time for us independent analysts and consultants to say enough is enough — Procurement may not be the island of misfit toys anymore, but that doesn’t mean it’s still not relegated to the basement with the IT Crowd in many companies. Procurement’s not going to get its due, and the CPO is not going to have a seat at the big table, until we collectively start treating it with the professionalism it deserves.

Source-to-Pay+ is Extensive (P39) … DeObfuscating the Orchestration – Fitting it all Together

In our three installments last week (Part 34, Part 35, Part 36) we noted that, when you are in Sourcing/Procurement, you need to intake requests, manage projects, and/or orchestrate your technology-enabled processes, depending on what the modules/suite you have do and don’t do and what your particular situation warrants. However, we also noted, that you won’t find a single platform that does everything you need to do, and you’ll be lucky to find a platform that does even half of it. And even then, it probably won’t do more than half of that well. That’s because, as we explained, these emerging platforms typically fall into the categories of Intake Management, Procurement Project Management, or Orchestration. In Part 35 we overviewed the core capabilities at a high level, but skipped the deep dive in an effort to get you the fledgeling vendor list (which is still quite small) so you could start getting familiar with who is out there and have an idea who to investigate when the time is right.

However, once you get a shortlist, you need to be able to evaluate where the platform is now relative to where it should be and what you will need. Thus, in this installment, we are going to continue our dive into each of these three product classifications (which, hopefully, will someday become one as you need all three sets of capabilities for successful orchestration). We’re concluding with Orchestration, because once you have accepted the request and defined the project, you need to execute it.

Orchestration is, in essence, the integration of as many modules as you need into a configurable workflow that suits your specific organizational processes for the procurement at hand.

Easy Self-Serve Data Stream / Partner Module Integration
A buyer should be able to select the supported applications that they own, enter their license codes, and it should automatically integrate with the orchestration tool. It should be a single click to integrate a supported data stream (once purchased).

Low-Code Integration for Arbitrary Source to Pay+ Modules
It should be almost as trivial to integrate non-partner source to pay modules which have a well-defined (open) API simply by defining the API link, the buying organization’s unique keys, data mappings from the orchestration platform to module data tables/objects, entry and specific task links, etc. that is sufficient for pulling data from preceding modules into the application, pushing data out required for metrics and successive modules that are required in the procurement process, launching the application, quick-linking to a specific screen, and integrating the module into the appropriate process workflows.

Workflow Automation
The entire idea of process orchestration is to support the right workflows to support the various sourcing, contracting, onboarding, procuring, payment term analysis, and other source-to-pay projects the procurement organization needs to undertake. It should fully automate the workflow defined in the intake module and/or the project defined in the procurement project management platform.

Smart Progress Tracking
The orchestration module should automatically track where every single process is and when a buyer comes in, take the user to the right screen corresponding to the current step of each procurement process it is managing. It should also push the required data for process and project tracking into the intake and procurement project management modules that will allow those platforms to automatically track the current project process.

Effectiveness KPI Tracking
Whereas a procurement project management module should track the efficiency of the procurement projects, orchestration should track the effectiveness. For a sourcing project, what was the identified savings? (It should track the prior cost per unit, the estimated demand for the next year & contract term, and the identified cost per unit.) For a contract renewal, what were the cost/service/quality/etc. gains? For a catalog procurement, what was the cost savings over the prior (non-catalog) procurement? For an analysis, what opportunities were identified in what time frames? And so on.

Predictive Analytics Integration
The platform should be capable of integrating with a platform capable of doing predictive analytics around expected process times, expected performance (savings, etc.) outcomes, and other metrics the user might want to consider before kicking off a project.

Rule-Based Automation
The platform should support rules-baed automation that will allow parts of the process to be fully automated within certain constraints. For example, if it’s a sourcing project, the RFQ, once defined, can automatically go out to approved vendors, when the quotes are returned, the lowest cost quote(s) accepted, the contract draft auto generated, and so on.

Data Flow Definition
It should be trivial to define the data flows between the different source to play modules that will be used in a given procurement process.

This completes our deep-dive of the intake management / procurement project management / orchestration modules that exist today, and that we listed in Part 36.