How to succeed in IT system tendering while considering future needs

The procurement of a new system is often one of an organization’s most significant IT decisions. It is an investment that affects business operations for up to decades. At the same time, AI is rapidly changing the technology landscape and challenging the very concept of a ‘system’. However, for the majority of companies, system renewals will continue to appear on roadmaps for a long time to come.

A typical way to start is by gathering a long list of requirements, requesting quotes from vendors, and comparing them against those requirements. The process is logical in itself and can be very thorough, but the end result is still not necessarily good.

AI brings a new perspective to this. Technology evolves rapidly, and during a system’s lifecycle, significant new opportunities to utilize AI may emerge around it. Therefore, in tendering, it is not worth evaluating only what the system can do today, but also how well it enables the utilization of new ways of working and AI-assisted services in the future.

Do not acquire system features, but tools to achieve your goals

In relation to this, I have compiled 5 experience-based points to pay attention to for successful procurement.

1. Start with the need, not the system

First, ask yourselves “What do we want to achieve as an organization?” and only then “What kind of system do we need to support this?”.

The key question before tendering is to clarify the understanding of what business problem or goal is being solved, and under what constraints. Based on goals structured this way, it is possible to create requirements for the new system that are based on genuine needs.

This also applies to AI. Before requiring AI features from a system, it is worth structuring the goals behind them. Otherwise, there is a risk that AI becomes just one feature among others instead of genuinely supporting business needs.

It also often happens that if the current system includes a feature, it translates into a requirement for the new system. Correspondingly, if a process is currently implemented in a certain way, the same way of working is expected from the new system.

The risk is that one inadvertently tenders for a reproduction of the current state, even though the real goal is to develop operations.

2. Let the vendor propose a solution

A good tendering process gives vendors the opportunity to propose different ways to solve the same business need. Sufficient guidance is needed in the tendering process, but excessive definition can stifle competition.

The organization must understand the things it needs to decide for itself: strategic capabilities, the operating model, core business processes, data management principles, and architectural constraints. The technical solution itself should, as far as possible, be left for the vendors to propose.

Do not define the solution in the tendering process if you actually want to tender for alternative solutions.

This requires more expertise from the client than just listing requirements and wishes. One must understand which matters are the organization’s own decisions and at what point it is worth utilizing the vendor’s expertise.

The rapid development of AI emphasizes this even further. If the tendering process defines too precisely which technology or in what way the AI must function, solutions that fulfill the goal better in some other way may be excluded.

It is more essential to describe the desired way of working and give vendors the opportunity to propose how AI can be utilized within it.

3. Make the quotes genuinely comparable

Often, a few relevant business scenarios say more than hundreds of individual requirements. Requirements are certainly needed, and it is good to link them to business scenarios or some other structure, such as a capability map.

AI can also help at this stage. With the help of AI, contradictions and dependencies can be identified from a large amount of documentation and requirements, for example. This allows more time to be spent on evaluating essential matters and less time on processing the material.

Classifying requirements helps in comparing solutions. Must-have requirements are essential, as without them the solution is not possible. Business-critical requirements, in turn, have a major impact on the suitability of the solution. Important requirements are useful features but do not decide the choice on their own. Nice-to-have requirements bring added value to the solution but are not essential.

AI features should also be evaluated critically. Not all AI features in systems are by any means of equal value. In some cases, an AI capability can be business-critical, while in another, it may just be a nice extra feature. Regarding AI, it is also worth evaluating what data the AI features are based on and how easily and securely it is available.

The mere presence of AI in a product’s features does not make the solution better.

In addition, it must be possible to distinguish, for example, standard product features, configurable features, and solutions requiring customization from the proposed solutions. These have a major impact on the workloads in the development and maintenance phases later on.

If two systems fulfill the same requirement, but one does it directly with a standard feature and the other requires customization, they should not receive the same value in the tendering process. The same applies to AI features: it is worth finding out whether it is a genuine standard feature of the product, a separately purchased service, or vendor customization.

4. Real use cases instead of demos

A vendor demo is often the most anticipated moment of a tendering process, but at the same time, it is one of the most unreliable ways to compare systems. The vendor knows what you want to see, and the demo is naturally built to highlight the product’s strengths.

A better approach is to give all bidders the same use cases and ask them to show how they are implemented with their solutions. This allows for an evaluation of how well the solution supports the process, how much manual work the user has to do, and how exceptional situations are resolved. At the same time, it is possible to examine how much configuration and customization is needed, what kind of integrations the solution requires, and how the solution feels from the user’s perspective.

The key is to primarily evaluate which solution works best in our real operating environment, rather than who gives the best demo.

If the solution includes AI features, they should be evaluated in the same way in real use cases. Instead of the vendor showing a separate AI demo, they can be asked to show how AI participates in that specific business process. This shows whether AI actually brings benefit to the process or if it is mainly an extra feature tacked on.

5. Choose the whole picture

The purchase price is only one part of the total cost of the system. Therefore, the total cost should be examined over a sufficiently long period. Real costs arise from licenses, implementation, integrations, data transfer and migration, customization, testing, training, maintenance, future changes, and indirectly also from vendor lock-in.

At the same time, risks other than financial ones must also be evaluated. It is important to understand in which direction the product is being developed, how strong the vendor’s position is, whether there are enough experts available for the product, and how easily the system can be integrated as part of the architecture.

AI brings even more new perspectives to the total cost. AI features may, for example, be based on separate services or usage-based pricing, in which case the costs may not be visible in the system’s license price alone. In addition, utilizing AI may require new integrations, improving data quality, training, monitoring, and new operating models.

The cheapest quote is not necessarily the cheapest solution.

A good tendering process is also an organization’s decision-making process, where an overall picture of the costs, risks, and suitability of the alternatives in the long term is formed. It is about which solution helps the organization achieve its goals best, now and in the future.

Director, Services and Development

Henri has worked in various roles as a business and enterprise architect, as well as a project and program manager. Henri’s areas of expertise include strategy-driven development, data-driven management, and leveraging enterprise architecture in change management.

Contact an expert

Nothing is as costly as an error that makes it to production

Check your company’s current state. Book QA experts now!

Reflector is an ICT company whose primary mission is to help our clients with major and minor business transformation projects. Agilely and independently.

Share article

Contact us

Send Message

Contact us

Request a callback

We will contact you as soon as possible.

Request a callback

We will contact you as soon as possible.

Send Message

Get in touch!