Category Archives: SaaS

Source-to-Pay+ is Extensive (P38) … Prettying Up the Project with Procurement Project Management

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 continuing with Procurement Project Management, because the next step is to manage the project, which could go beyond the existing source to pay modules the organization currently has.

Procurement Project Management is exactly what it sounds, the project management of a procurement. It’s essentially project management, tweaked to support Procurement vs. just a generic project. Whereas intake has capabilities for the buyer and the stakeholder, project management is primarily geared towards the buyer.

Phases, Milestones, Tasks, Owners, Obligations, Tracking
The ability to create phases, milestones, tasks, owners, obligations, and track progress throughout the project timeline — all the standard project management functionality — as previously indicated, is a core must. Basically, anything you would expect any other project management tool to do — including team management, GANTT charts, etc. etc. etc. must be supported.

Standard Project Templates
Just like intake management must support Sourcing / Procurement Workflow Process Definition, the procurement project management module must support the definition of standard project templates for each of these processes such that there is a template for every category of good and service being sourced that can quickly be instantiated as needed for each procurement project undertaken.

Customizable Approval Flows
Depending on the category, the amount, the vendor, etc. etc. etc. the approval flow that is required may be slightly different from the default flow for the category, good, amount, vendor, etc. The module must support the definition of the customized approval flow, which can be role based, user specific, or both; parallel, serial, or both; or even process step dependent. And this approval flow must be seamlessly embedded in the project workflow, ensuring that a project does not advance when one or more approvals are needed.

Deep links into Sourcing/Procurement Products
If the procurement project management module is not capable of being integrated into the modules and tools used to execute the project, it’s not procurement project management — it’s just a regular project management tool and you might as well use the cheapest freeware/shareware project management tool that you can find as it’s not providing any value from a Procurement perspective. It must support integration into the modules that are used to execute procurements, and not just a shallow link. It must support a deep link directly into the current screen that represents the current step of the process. It must also support data pulls for metrics, alerts, and necessary pushes into subsequent modules and steps.

Dynamic Project Shifting
If, at some point, the buyer decides that the procurement should follow a different process, or, due to quotes (and likely costs) being higher than expected, the need to introduce new (potential) suppliers into the process, or the need to accelerate the acquisition, the module should make it as easy as possible to convert the current project plan into the new/modified project plan, by automatically populating the new project plan with all of the existing project configuration that can be reused. Requirements, team members, approvers, etc. etc. etc. that are capable of being ported should be. In addition, it should note that the procurement process was modified and link back to the original process that was followed, and where the buyer was in the prior process prior to the shift.

Efficiency KPI Tracking
The platform must track metrics around how long different processes generally take, down to the individual milestone and step, as well as the configuration settings and parameters (such as category, contract length, etc.) that will allow the metrics to be sliced and diced into specific metrics meaningful for a precise subset of procurement processes.

Issue Alerting / Exception Dashboards
Just like an intake management platform should alert the stakeholder and the buyer when there is a question, issue, or requirement that needs their attention, a procurement project management platform must alert the buyer not only when something needs to be done, but when a certain process step is taking longer than was allocated or than the average process time for that step in similar projects. It must make it easy to see all of the outstanding alerts applicable to the buyer and/or a particular process, as well as any exceptions that arise during a project that could cause a delay, whether or not they are to be resolved by the buyer (so that the buyer can see if they need to contact a stakeholder to see if that stakeholder needs help to keep the project moving).

A good procurement project management module will, of course, do even more than this, but as with all of the previous modules we covered in our series, we consider this the bare minimum set of functionality that a procurement project management module should support.

We still have Orchestration, so come back for Part 39.

Source-to-Pay+ is Extensive (P37) … Investigating Intake – Diving in to the Details

In our last three installments (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, and the next two, we are going to 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 starting with Intake, because the first step is to get the request.

Intake Management requires two sets of capabilities, one set that are requester stakeholder focussed, and one that are procurement buyer focussed, that must be connected and that are often two sides of the same coin.

For the Requesting Stakeholder:

Request Portal
This is the absolute requirement — an easy to access web-based enterprise procurement portal that anyone in the organization can access when they need to acquire something to do their job or satisfy a client. As per our initial discussion, the interface must be capable of being configured in a way that ensures that whatever information the buyer needs to fulfill the request will be collected before the requester can complete the request (such as high level categories, any budgets [codes] they have, whether or not any of the needs can be met with current contracts / catalog items, etc.). It must be incredibly easy to use, dynamically adjust the information requested to the minimum required for the product or service being requested, and support all of the other necessary requirements from the stakeholder perspective (that we are describing in this installment).

Process Visibility
Procurement is, or at least should be a process. Not just “I got a bid, negotiated a discount, and want to send the PO, so can you please approve it?” (even if one of the intake vendors seems to indicate this is an acceptable process! [It’s not!!!]). It should be multiple bids, comparison to current prices (or open market prices), negotiations with the best vendor(s), documentation of real reductions (not just a 20% reduction on a 25% markup because the sales person knows you have no clue of current market pricing, so they mark it up 25% to negotiate down 20% and make a killing off of your lack of knowledge), a proper contract, a PO tied to the contract, and an invoice management process that doesn’t pay the invoice until the goods are received and the prices are verified as matching those in the contract. And the stakeholder should be able to see once a request is assigned to a process, what the process is, and where the request is in the process at any time simply by logging in and selecting the request from their request history.

Asynchronous Messaging
The stakeholder should be able to ask questions of the buyer at any time, and be able to answer any questions asked by the buyer at any time.

S2P Platform Integration for Stakeholder Input
The Procurement process should be executed through the modules available to the buyer, which could include, but not be limited to, strategic sourcing, contract management, e-procurement, supplier management, spend analytics, accounts payable, etc. Wherever stakeholder review or input is needed for proposal review, order or invoice verification, approval, etc., the intake portal should integrate with, and allow a stakeholder to directly jump into, the module where, and when, needed to allow the process to continue smoothly and efficiently.

Budget Tracking
The portal either needs to track the budget(s) (remaining) that each of the users has control of, or access to, or integrate with the source to pay module that does the budget tracking. This way, when the stakeholder goes to make a request, they can see if there is budget available before submitting the request (and if there is not, make a budget request first as the Procurement Buyer may otherwise be required to reject the request).

Alerting
The portal needs to alert the stakeholder of any requests made by the buyer, or any requirements that need to be satisfied in the process, possibly through integrated source to pay modules, in order for the procurement process to continue. This should include the ability to configure the portal to send the stakeholder an email when something is urgent, as well as an ability to easily access all of the unaddressed alerts quickly and easily on every login.

For the Procurement Buyer:

Request to Process
Once the buyer analyzes a request and decides it is a valid request, the platform must make it incredibly easy to flip that request into a Procurement project, be it a (strategic) sourcing project, contract addendum/re-negotiation, a catalog buy, or another PO against a current (open) project. Literally select the option and one-click to project. (And, if the request is not valid, or the requesting stakeholder has no budget, be able to return it just as easily by selecting the pre-coded reason and one-click returning it.)

Sourcing / Procurement Workflow Process Definition
The platform must support the creation of procurement process workflows for each category of goods and services that the buyers need to acquire. These workflows must not only allow for the identification of the major process steps, but also the tools that will be used, and direct links into those tools.

Integrated Approval Workflows
The more costly the acquisition, the more checks and balances and approvals that are needed. Some of these will be possible in the modules used, and some won’t. But they need to be captured in a tool with secure audit trails so that anyone at any time can ensure that the process was followed, the checks were made, the necessary approvals acquired, and everything is above board.

Project Management Integration
While an intake platform must allow for process workflow definitions with major steps, it does not necessarily include extensive project management capability, which will be needed for complex acquisitions. Thus, unless it contains extensive project management capability (which we will describe in our next installment), it must support integration with a project management module.

Policy Tracking
All Procurements should not only follow a process, but be guided by a policy that dictates the acceptable processes for a (category of a) good or service, the considerations that must be made, the requirements that must be met, the approvals that must be made, and so on. If these are not tracked in a central location, they will be lost. The intake tool is where these should reside, as they should also be available to stakeholders who have questions.

Alerting
The portal needs to alert the buyer of any requests made by the stakeholder, or any requirements that need to be satisfied in the process that are waiting on the buyer, possibly through the integrated source to pay modules, in order for the procurement process to continue. This should include the ability to configure the portal to send the buyer an email when something is urgent, as well as an ability to easily access all of the unaddressed alerts quickly and easily on every login.

A good intake module will, of course, do even more than this, but as with all of the previous modules we covered in our series, we consider this the bare minimum set of functionality that an intake module should support.

Next up: Procurement Project Management in Part 38.

Tealbook: Laying the Groundwork for the Supplier Data Foundations

It wasn’t that long ago that we asked you if you had a data foundation because a procurement management platform, should you be lucky enough to get one (which is much more than a suite), generally only supports the data it needs for Procurement to function and doesn’t support the rest of the organization. Furthermore, when you look across the Source-to-Pay and Supply Chain spectrums, there are a lot of different applications that support a lot of different processes that have a lot of different data requirements that need to be maintained as different data types in different encoding formats.

Furthermore, as we noted in the aforementioned post, it’s rare enough to find MDM capability that will even support procurement. This is because most suites are built on transactions, most supplier networks on relational supplier data records, and contracts on documents and simple, hierarchical, meta-data indexes. But you also need models, meta-models, semi-structured, unstructured, and media support. And more. The need is broad, and even if you restrict the need to supplier data, it’s quite broad.

As you will soon garner from our ongoing Source-to-Pay+ is Extensive series, in which we just started tackling Supplier Management in Part XV, the supplier data an organization needs is extremely varied and extensive. Given that Supplier Management is a CORNED QUIP mash with ten (10) major areas of functionality, not counting broader enterprise needs around ESG, innovation, product design / manufacturing management, and other needs tied to operations management, engineering, and enterprise risk management, among other functions, it’s easy to see just how difficult even Supplier Master Data Management can be.

Considering not a single Supplier Management solution vendor (as you will come to understand as we progress through the Source-to-Pay is Extensive series) covers all of the basic functions we’re outlining, it’s obviously that not a single vendor can effectively do Supplier Master Data Management today. However, Tealbook, which has realized this since their exception, is aiming to be the first to fix this problem. As of the first release of their open API next month, they are transitioning to a Supplier Data Platform and will no longer focus on being just a supplier discovery platform or diversity data enrichment platform. (They will still offer those services, and will be upgrading them in Q4 with general release expected by the end of 2023, but their primary focus will be on the supplier data foundation that enables this.)

This is significant, and illustrates how far they’ve come in the nine (9) years since their founding when their original focus was on building a community supplier intelligence platform that was reliable, scalable, extensible, and appropriate for new supplier discovery (via a large database of verified suppliers with community reviews). From these humble beginnings, where they didn’t even have a million suppliers in their platform after their third year of existence, they grew into the largest supplier network with over 5 Million detailed supplier profiles that is integrated with the largest S2P suites out there (Ariba, GEP, Ivalua, Jaggaer, and Workday, to name a few) and powers some of the largest organizations on the planet. As part of this empowerment, they can take in an organization’s entire supplier data ecosystem, transform it into their standard formats, match to their records, verify or correct existing data, and then enrich the organization’s supplier records before sending them back. In addition, they integrate with a multitude of BI tools, databases / lakes / warehouses (including ERPs), digital platforms, and so on.

To summarize, that’s a ten fold increase in suppliers and an explosion in global utilization and usage. At the same time, the platform has been augmented with over 2.3M supplier certifications, global diversity data, and the ability to track an organization’s tier 2 supplier diversity data. Quite impressive.

And while this meets most of an organization’s discovery needs, Tealbook knew that it didn’t meet all of an organization’s supplier data needs, especially when you think about all of the regulatory, financial, compliance, performance, sustainability, risk, contract, product/service, relationship, quality, and enablement/innovation data an organization needs to maintain on a supplier. As a result, they have been aggressively working on two key pieces of functionality. An extended universal supplier profile and a fully open, extensible, API that an organization can use to do supplier master data management across their enterprise with the Tealbook Supplier Data Platform. An organization can use the Tealbook Supplier Data Platform to classify, cleanse, and enrich supplier records; augment those records with third party data for sustainability, compliance, and risk; find new suppliers in the network; and so on.

In short, Tealbook is on a mission to be the organization’s trusted supplier data source, and to constantly improve their data offering both with their own ML/AI enabled technology that monitors over 400M+ public websites for supplier-related data (supplier web sites, business registries, certification providers, supplier data providers, etc. etc. etc.), maintains data provenance (when was it last updated, by what/who, etc.), and provides trust scores (in their proprietary framework that indicates Tealbook’s confidence in accuracy and correctness).

The real mission begins next month when they release their new Open API that will allow an organization to integrate, and interact with, Tealbook the way it needs to across its enterprise applications. Congruent with this release, they will also start releasing their enrichment data-packs that will, within the next year, allow the organization to plug-and-play the data they need to confirm firmographics, contact channels and key information, diversity, supplier offerings, financials, certifications, and basic risk data (which Tealbook will offer through partnerships with specialty supplier data providers, giving an organization a one-stop shop vs. having to license with multiple providers separately to build its 360-degree supplier profile).

Then, over the next year, Tealbook will enhance the usability of their data platform by first rebuilding their diversity and discovery applications and then building out new applications around sustainability, risk, benchmarking, and other areas that their customers would rather a data platform handle for them.

Do You Have a Procurement FocalPoint?

Last month we asked where’s the procurement management platform primarily because we now have a plethora of procurement-centric applications but very little integration between them. However, once you tackle that issue, you have the secondary issue of all these applications, but often no clear starting point and, even worse, no way for an average organizational employee outside of Procurement to interact with Procurement beyond an inbound email to “please get this for me” and the eventual, possibly many months later, outbound email to “we got it, it’s finally here … it will be on your desk tomorrow“.

This is a big problem, even in organizations that supposedly have market leading source-to-pay suites. While all the modules are connected, and the integrated workflow will guide a buyer from project selection to sourcing to supplier selection to award to contracting to supplier onboarding to order creation to receipt creation to invoice confirmation and payment approval and loop back to the order creation until pending contract expiration when the contract can be renewed, renegotiated, or
revoked and the sourcing process started all over. This is great, but for predefined sourcing projects on encoded categories only!

It’s not great for any category not already encoded and typically strategically sourced, and it’s atrocious as new product and service needs arise within the organization, as new hires need new assets for onboarding, as customer requirements change and the organization needs to adapt rapidly and source new products or services to meet new, or one-off, needs. There’s no intake, and no collaboration with the organizational stakeholders Procurement is there to serve.

And that’s a huge problem. That’s why you’re seeing a few companies talking about “intake”, “orchestration”, or “PPM” (which stands for either Procurement Performance Management or Procurement Process Management, depending on who is talking about it) because, without this capability, a Procurement platform will never be complete or support the organization.

Following the introductory post on the procurement management platform, we lamented and celebrated that Per Angusta was going away and being integrated into SpendHQ as the foundations of a new PPM. It’s a great start, but today the focus of SpendHQ is on managing the existing workflows and creating visibility into existing projects — and savings tracking is limited to integrated projects. However, when it comes to intake support and project tracking for arbitrary organizational needs, that’s not there yet.

However, there are other players which are strong here, and one of those players is Focal Point, which was built from the ground up as an intake-to-orchestrate solution that is capable of

  • capturing all organizational requests for Procurement and Procurement-related activities,
  • assigning those requests to customizable workflows using either built in automation rules or manual (re-)assignment,
  • allowing an end-user to see exactly where any request is in the process at any time,
  • allowing for in-platform communication between the stakeholder and Procurement,
  • integrating with any external tool through jump-out/jump-in to support the process, and
  • supporting whatever approval chains are required, among other intake and orchestration functions.

The tool was built to solve the most significant problem the founders repeatedly saw as CPOs and implementers of various leading sourcing solutions — little to no intake management or general purpose procurement process orchestration. And it does it incredibly well. The visual workflow construction is extremely usable, and the wizards that power both the process, form construction, and form completion automatically extend and compress the form as needed based upon user selections and actual needs, making for a very smooth flow.

All of the workflow elements and steps support deep conditional logic, allowing the organization to create as many branches as possible but ensuring that the end user making a request, and the end buyer assigned to deal with that request, only see the relevant paths and only need to enter the relevant information to be guided by the platform.

There can be as many intake types, with associated branching workflows, as the organization needs, each can have the appropriate level of automation, and, most importantly, each can have as many milestones as needed to walk the process through at a high level, allowing the requester to easily see at a high level where the process is, and then, if interested, dive into the detailed workflow within the current milestone to get a more accurate picture of where the process is.

The only thing the platform doesn’t do is actual sourcing, supplier management, contract management, analytics, procurement, or payment management. It expects the organization to have tools for this already and integrates into the appropriate modules in those tools as needed to accomplish the workflow in progress.

In terms of getting up and running, Focal Point typically has a fully fleshed out, functioning, and integrated instance that captures all of the organization’s workflows up and running within 90 days, even if the organization is a multi-(multi-)billion dollar organization, which is Focal Point’s target market size. This is because it’s typically the 1B+ organizations that have a lot of tools, and a lot of stakeholders, but no way to manage those tools effectively or to give stakeholders any visibility into where their requests are and how their spending is being managed.

The reason it typically takes 90 days is that, unlike many sourcing suite providers, who just flip a virtual switch and drop an empty SaaS suite on you and say “good luck“, Focal Point fully configures the platform as part of their statement of work. This includes:

  • working with the organization to understand all of their requirements and current workflows
  • encoding all of those intake workflows with milestones, task-breakdowns, and existing platform jump-outs
  • integrating any existing procurement system you need to complete the workflow
  • creating a UAT instance and allowing for at least one iteration and approval before it goes live
  • training your team on how to use the system and maintain the workflows

So even though Focal Point has obviously achieved efficiency in terms of workflow creation and customization, external platform integration, and implementation project management, it takes time for an average organization to collect and document their existing processes and requirements and for FocalPoint (or a third party consulting organization if that is the customer’s preference) to fill in the gaps, so it’s not possible to get it much below 90 days. But when you think about the fact that they have fully implemented a 10B+ organization in that timeframe, when some major suite players will take 18 months working with a consulting partner to fully implement those solutions, that’s an incredible time to value, which is generated day one when every request flows into the tool; gets tracked, assigned, and executed; and stakeholders have full visibility into the process and can intervene if necessary.

Focal Point solves the problem it was built to solve, fills the hole the vast majority of sourcing and procurement solutions make, and does it incredibly well. If any part of this post resonates with you, the doctor encourages you to check them out.

Services Struggles? Get Zivio. It’s Apropos!

In Friday’s post we told you not to use a sub-standard sourcing solution for services sourcing because, in the end, you won’t realize the value you expect or collect the data you need to make better awards in the process. And we know that left you with questions because all the big platforms you know don’t do services, or at least do not do services well.

So, today, we provide one answer to that problem — Zivio, a relatively new player that specializes in complex services sourcing, that is Best of Breed, and that meets the requirement of being able to integrate into an existing platform or ecosystem that contains open APIs and that can accept all of the data it can capture, generate, and exchange, with its complete, open, APIs.

Zivio was designed to manage the entire process from initial project creation through supplier onboarding, selection, and approval to milestone tracking and management to close-out, final bill-out and reporting. Each step of the process is designed to be easy to use and efficient and makes use of any existing templates and knowledge in the tool, using AI where (and only where) appropriate.

Their new project definition wizard, called ScopeIQ, is designed for quick Statement of Work (SoW) creation and all a requisitioner has to do is enter a few short sentences with the most relevant keywords and the solution will suggest a title based upon similar projects in the past, which the user can accept or edit, and then, using past project descriptions (from the company and publicly available datasets), it will use AI to assemble a project description and statement of work that the user can then review and edit. If the organization does a number of similar projects, it works exceptionally well and the starting statements of work and project descriptions are quite good and often need little editing (comparatively speaking).

Once the user has accepted the SoW, they can complete the project definition by defining the appropriate metadata (category, subcategory, budget, milestones, project release date, bid closing date, award criteria, etc.) and send the project out for bid. The system can automatically identify the best suppliers based on project categorization, milestones, and past performance on similar project and the user can select these suppliers and invite them to bid with just one click.

When the bids are submitted, the users can see an overarching summary and select a sub-set for side-by-side comparison. At any time before award, the buyer can easily modify the project description and add or modify milestones. Milestones can also be added and modified after award with the right approvals and agreement from both parties.

The product has good supplier management, performance management, and approval management, especially around supplier onboarding, milestone approvals, and payment approvals. By default, the platform tracks on time performance, operational best practice, and on budget metrics by supplier, but can be configured on implementation to track more. It also computes an overall score for easy ranking purposes (which can also be customized on implementation). When it comes to reports, there are a large number of project, milestone, supplier, and financial reports out-of-the-box, and more can be easily configured on implementation. Plus, as the platform was built to integrate with your existing S2P/ERP platform / ecosystem, it can push all of the data out to an external tool where you can do additional reporting and analysis.

But the best part about the tool is the ability to define complex services projects to any level of detail needed, with as many milestones, tasks, and approvals as required, customized for the project, with breakdown costing and interim payments as needed. And then to log into the system at any time, see where a project is, see where all projects are with a supplier or where all suppliers are with a set of related projects. And the ability to quickly bring up summary reports of relevance to the appropriate level of detail at any time. It’s project based sourcing and it works great, especially when you’ve defined your first few projects and the system can use (and learn) from those templates and suggest SoWs, suppliers, and steps for you. It’s what general services sourcing should be.

Now, before we sign off, we should make it clear that we are not saying that Zivio is the only solution (especially as we’re sure we will see more in the months and years ahead as more people realize how critical proper services sourcing is), or the solution for every business (as there are custom solutions for Legal, Marketing, and SaaS, that we will be covering in our Source-to-Pay is Extensive series), but that Zivio is a solid general purpose solution for an organization with a wide array of services needs that should be considered if the organization does not have a services sourcing solution. It could be the right solution for your organization and, if it is, given the typical overspend in services categories, that means you should have been using it yesterday!