Total cost of ownership (TCO) of procurement software

When it comes to procurement analytics, the question of whether to build it yourself or buy it from an external service provider has been a long-standing debate.

In analytics build-or-buy decision-making, you need to consider various perspectives and form an educated TCO estimate. According to the Gartner Information Technology Glossary, TCO is:

“A comprehensive assessment of information technology (IT) or other costs across enterprise boundaries over time. For IT, TCO includes hardware and software acquisition, management and support, communications, end-user expenses and the opportunity cost of downtime, training and other productivity losses.”

Therefore, TCO is more than just a price tag. It looks beyond the hardware and software acquisition to assess the full costs associated over the lifespan of use.

In this article, TCO will be broken down into three main themes related to spend analytics:

1. Acquisition and development cost: the costs related to the acquisition, maintenance, and development of a spend analytics software solution, as well as their inherent opportunity costs.
2. User experience and functionality: the costs related to the training, onboarding, and support of users and the impact on productivity.
3. Data management and quality: the costs related to the long-term management of data, including data architecture, data quality, and data security.

Under each of these themes, there are various factors to consider and compare.

See what Spend Analysis software has to offer with this complete guide for all levels.

Total Cost of Ownership of Procurement Analytics

Even though this is an age-old topic, its specific application to the procurement analytics context is less talked about. There is still room for improving the overall understanding of what to consider when building or buying analytics solutions.

Certain cost elements may come as a surprise for an organization along the way. Organizations may not have taken all elements into account in the initial budgeting equation. To avoid hiccups like this, we’ve compiled a full list of considerations.

We define these two strategies as follows:

The “Build” Solution: An in-house managed, custom-built solution for one organization or business unit. Sometimes completed with the help of subcontractors, the operators remain internal. 

Recognize any of these pitfalls on in-house tools?

The “Buy” Solution: An externally sourced, ready-made solution from a proprietary software vendor. The final product for users will largely be the same across organizations, with variations in applications and modules based on industry or customer needs.

When choosing to buy, you can split that decision into two sub-paths: buying what you can build and buying MORE than you can build. If you buy what you can build, the choice will save time and resources but not provide much value beyond that.

Buying MORE than you can build means you are accessing features that are value-added services outside the scope of what can feasibly be built in-house. In the case of spend analytics, these services might include AI classification, benchmarking databases, or self-service visualizations.

Keep in mind that sometimes, “buying” means subscribing, as in paying a subscription fee for a licensed SaaS product.

There are many considerations in build or buy. Companies may prefer the build option because of a desire for better control and to address their specific needs and level of complexity. Often, building in-house is seen as the only way to fulfill these needs.

The resources needed to build, though, are substantial and require domain-specific competencies. Meanwhile, buying a software solution can itself be a time-consuming and expensive process that still might not satisfy what users were hoping to achieve. There are multiple factors to consider on this topic. The primary consideration should be Total Cost of Ownership (TCO).

The complete list of TCO factors to build or buy analytics

The table below shows the full list of factors related to each TCO theme.

Now, let’s break down each consideration in more detail:

Acquisition and development costs:

• Sourcing cost: The literal “price tag” and costs related to acquisition. With building, there are no sourcing costs. Market benchmarking and development will generate the most costs. Buying will require a competitive tender and a good amount of market research.
• Cost transparency: The ability to estimate the associated costs now and in the future. Building software may lead to surprising cost elements that have a budget impact along the way. Time, talent, and resources are harder to measure than a sticker price. Buying software benefits from economies of scale, which means the price is usually lower.
• Opportunity cost: The loss of time and resources that could have been used elsewhere. Building software takes a long time. Buying from a software provider, on the other hand, allows for testing the solution through a proof of concept (POC) first. Seeing the solution in action can minimize the opportunity costs because it can also be used as a starting point for the full implementation.
• Data cleansing costs: The costs associated with the cleansing of input data in analytics. If choosing to outsource this task alongside a built solution, costs can easily get out of hand. Vendors typically take care of this sort of input data cleansing during implementation, and you benefit from procurement experience in multiple industries.
• Data enrichment costs: The costs associated with adding external data or third-party data in analytics. While a solution provider can act as a bridge for connecting your data to external data ecosystems, doing it on your own requires more storage and architecture considerations.
• Maintenance costs: The cost of infrastructure and maintenance. Building a solution doesn’t end with deployment—it can include continuous maintenance costs. Vendors bear this burden for you.
• Development costs: The costs of updating the solution with new technologies. With the rate of change in technology, software must be continuously updated. This will also include keeping up to date with market developments. It will be challenging to consider all the needs of the organization and prioritize and justify decisions. Buying a solution means you are gaining benefits from the vendor’s developments with the market and working with multiple clients’ ideas and problems.
• Feature scalability: The costs of adding new analytics features. When building, new features can require large amounts of work, sometimes requiring returning to the drawing board entirely. From the vendor’s standpoint, they want to offer new features and be synergistic with other software in the market. Scaling the solution can be as easy as buying more functionalities.
• Capabilities: The use of talent put towards development. In building procurement analytics, you need to consider the capabilities in terms of aligning with the wider data strategy and procurement-specific knowledge. Vendors can offer expertise in both these domains.

User experience and functionality:

• Time to market: The expected timeline of implementation. Users probably needed the proposed solution yesterday, and building can take a substantial amount of time to do right. Buying is a much smoother journey to market.
• Control of customization: The degree of freedom to tailor the analytics solution. Building a solution can be fully tailored to your organizational needs and is completely in the hands of developers. While vendors may know the wider market needs of various customers, there’s always the chance you won’t find a 100% fit for your needs.
• Training and support: The resources dedicated to feedback, training, communication, and documentation. This is an important but often overlooked consideration: how much time will it take to teach users how to use a solution? Luckily, vendors work hard to make sure training materials are available and can continuously support users along the way.
• Service level: The resources dedicated to maintaining the quality and performance of the analytics solution. While vendors have service level agreements (SLA), it can be tricky to discuss unmet expectations with an in-house solution.
• Partnership: The possibilities for collaboration with partners for new features. With building, you are on your own—or limited to your own alliances. A procurement analytics vendor can be a partner in your digitalization journey and open more network possibilities than were possible on your own.
• Scalability of users: The ease of growth in user base. How scalable is the software? Can it grow with the company? Bought solutions are highly scalable and can easily grow with your business needs.

Data management and quality:

• Data security/ data privacy: The ability to meet all necessary INFOSEC regulations. Vendors have tested their infrastructure and their other customers have similar concerns, so it needs to be bulletproof. Some vendors will offer data security and privacy covering everything from GDPR-S to HIPAA, meaning you won’t need to hire your own cybersecurity experts to keep up with the complexity of regulations.
• Data location: The decision of where to store the data. There may be concerns or regulations regarding which region or country the data is stored in. With a build option, you have complete control over the data location if this is an issue. Legacy strategies may still apply to sensitive information, but average companies are moving towards the cloud trend.
• Data architecture: The consideration of how to align an analytics solution with the wider IT architecture and strategy. If all your relevant data is stored in one place, such as a data warehouse or data lake, it’s possible to build software on top of that which feeds the data directly to the application. However, there are costs involved in buying servers or cloud capacity, and fully on-premises storage may create further restrictions. When purchasing software, it is possible to connect to both data warehouse/ data lake strategies or directly to ERPs. Buy options offer flexibility in data architecture.
• Data quality: The continuous effort to ensure superior data quality and gain value from that data. This should be a major consideration. Whether building or buying, the data quality must remain good—it is the pre-requirement for users to gain value from the solution.

Will you build or buy your procurement analytics solution?

In software development, the build or buy debate was resolved decades ago. Most organizations turn to vendors for almost all their business software needs.

But the same trend has been slow to happen in procurement analytics. Why is that?

To learn more, read our full guide to compare Sievo and in-house procurement analytics tools!

IT departments may argue that they know their systems or users better, but the market space is in constant change and user requirements are evolving.

Buying a solution that serves a purpose for the time being doesn’t rule out the option to build better-fit in-house solutions later.

If the organization needs to harness the potential of its data now, they do not want to wait for years of development.

Serving existing user needs now and evaluating alternative development avenues later is not a duplication of effort: it is a step along the way in your organizational maturity.

By understanding the total cost of ownership (TCO) of the build or buy decision, you can make the best choice for your current needs.

Interested in learning more about how to work collaboratively with IT and ensure end users get the solutions they love using? Then read more in our full-length eBook Procurement Loves Data.

Photo credit: iMattSmart, Unsplash