Back to Resource
Jul 3, 2024

The misunderstood role of IT in buying Procurement technology


The internal IT is not your enemy. Put yourself in their shoes. Just as you try to ensure compliance with Procurement policies and processes, the IT department has strategies, policies, principles, and objectives, too. And they might be conflicting with yours at times. This article outlines how involving your IT team early on in the selection process and understanding their guardrails is the first step to improving the relationship with them and getting the solution you want, faster.

The average employee probably does not know the business strategy of other functions or departments. Why should they be concerned with it? Unless, of course, it has implications for their department, their job, or a specific task. 

Do your stakeholders understand the Procurement strategy?

Procurement is no different in that. Most stakeholders probably don’t think about procurement policies unless they want to purchase some goods or services. That’s when they encounter that next to procurement involvement, they need to perform risk assessments, obtain approvals, …the list goes on.

It can be hard to make sense of these requirements without understanding the overarching procurement strategy. And, honestly, most people don’t care enough to go there, they just want to get their stuff. Fair enough.

The challenge for Procurement is that they usually don’t buy ‘stuff’ very often. Did you ever place a PR? Even if you did, it was most likely for some kind of professional services, flowers, or team events, not for buying procurement technology.

Understanding your IT strategy

While for the former examples, Procurement is usually driving the strategy, the latter is heavily dominated by IT. Understanding their strategy and requirements for bringing on new solution providers is indispensable when exploring solutions like Cirtuo Guided Strategy Creation, for all involved parties.

The IT team has typically architecture strategies and principles like the following examples:

  • ERP (SAP, Oracle) solutions first: If a solution is available from our strategic partner, we should use their offering.
  • Cloud over on-premise: Cloud solutions are to be preferred over on-premise installations.
  • Buy before build: If a standard solution is available on the market, this should be prioritized over building it ourselves.

These architecture principles are underpinned by information and data security standards or policies, compliance, privacy, and hosting requirements, service level expectations, and many more. 

When buying technology, the business has to comply with the outlined strategies and principles or reasonably demonstrate why they don’t apply in a certain case. The solution providers have to prove their compliance with the underlying standards, policies, and requirements. 

Navigating the architectural principles

Understanding the architecture strategy and principles of your organization, including the degree of flexibility, is extremely important as it might exclude certain solutions and save all parties a lot of trouble.

In our experience, the following caveats, interpretations, and flexibilities apply to the architectural principles: 

ERP (SAP, Oracle) solutions first

If a solution is available from our strategic partner, we should use their offering unless it doesn’t meet the established business requirements. 

Cloud over on-premise

This is usually less of a friction point as most IT organizations have accepted that SaaS solutions are here to stay. This has changed dramatically in just 10 years but increased the focus on the underpinning policies and procedures.

Buy before build

We still hear the idea of building your own tool because it is “cheaper” quite frequently from procurement teams. This is surprising as people tend to underestimate the cost of design, development, maintenance, and enhancements, let alone the availability of resources.

Mastering the standards, policies, and requirements questionnaires

Being aware of the underlying standards, policies, and requirements for implementing a SaaS solution for Procurement early takes the friction out of a selection process. The requirements are presented in the form of questionnaires, often fairly long, detailed, and highly technical. Most questionnaires are based on security frameworks such as ISO 27001 or SOC2. While the elements are therefore consistent across organizations, they are unique and tailored to the needs, requirements, and risk appetite of each organization.

Their nature requires specialist attention and binds resources. Some questions may be open to interpretation, leading to misunderstandings or differing interpretations of requirements, inconsistencies in responses, and potentially in evaluation outcomes. Understanding the context of each question, being able to discuss them, and providing suitable responses therefore requires the ability to directly engage with the IT team.

IT resource requirements for integrating and implementing Cirtuo

In our recent blog “Ensuring client success with an established approach to implementing sustainable transformation” we outlined the components of successful technology implementations. The focus was on bringing people along a change journey, less on the element of technology implementation.

The notion of requiring heavy lifting from IT stems from previous on-premise implementations. The process for enabling SaaS solutions is much simpler, as they don’t require an installation to a hardware stack but rather the creation of user accounts. Theoretically, you can use a SaaS solution like Cirtuo without IT involvement. All you need is an email address to generate login credentials. 

As most organizations require some level of integration into the existing system landscape (e.g., Single Sign On, authentication, ERP, data feeds), IT support is still required. IT teams often work in development sprints of 6 or more weeks. It is important to understand their ways of working to ensure availability for requirement building, questionnaire reviews, and implementation tasks. 

Early involvement and clearly defined business requirements are the key to success

Understanding the architectural principles, the underlying requirements, and the ways of working of your IT team has direct implications for your ability to screen, select, or implement a Procurement SaaS solution. 

By involving your Procurement IT Business Partner early on in the process, you can understand the guardrails set by the IT strategy and ensure they fully understand your business requirements. It allows them to add their requirements to the review process and reduce ambiguity around standards, policies, and requirements. Involving them in the project early on enables them to efficiently plan the resource requirements for implementation tasks and fence off relevant resources.

Involving IT can feel to Procurement like involving Procurement to other business stakeholders. There are many benefits in early Procurement involvement. Involving your IT Business Partner early on in the selection process of a SaaS Category Management solution for Procurement can vastly improve your chance for a smooth process and getting the solution you want instead of the one IT believes you need.

Subscribe now

Related articles

View all resources
By clicking on "Accept all cookies", you agree to the storage of cookies on your device to improve navigation on the website, analyze the use of the website and support our marketing activities. You can find more information in our Privacy Policy.