which features should you include in your CLM system?

find out here!

In a market full of ready-to-use IT solutions, it’s often difficult to decide what solution you should invest in. What’s more, buying and implementing a solution often isn’t cheap, so picking the wrong one could be disastrous for your company. 

What should you pay attention to when making your decision? We would recommend to first define the what- and why-question, and only then start thinking about how to implement the solution. Does that seem like a challenge that’s too big to face? No worries, we would love to help you out!

IT solutions: what if you don’t get the results you were looking for?

Today, many companies are confronted with an abundance of installed IT solutions that don’t always serve a purpose, or offer the desired results. More often than not, companies that are faced with a problem immediately want to buy or develop a solution. Without properly analyzing their needs first. 

The stakeholders will turn to tools used by the competition, or solutions that they have encountered at commercial events or on the internet. The solutions that are already available in the company aren’t good enough. Many stakeholders are convinced that the company needs something new. The knowledge already present in the company is rarely used: the architects, application managers and even the business experts aren’t involved in the decision. Often, there is no real solution structure. 

the impact of the wrong solution.

Many companies struggle with the following problems:

  • Their licence costs are incredibly high due to the continuing use of substandard applications.
     
  • Their applications are outdated, and there are so many that they lose oversight.
     
  • The enterprise architecture and underlying application architecture are chaotic and not up-to-date.
     
  • The budgetary reserves from the past, due to the impact of COVID-19, have shrunk, and they once again need a strong budget management based on their strategic vision.
     
  • The business and IT departments don’t communicate with each other. In many organizations, applications are build and managed by the IT department, but also by the business (without IT involvement). If they can’t fall back on a strong citizen development governance model, their application management will soon become chaotic.

What should you do to avoid these scenarios? 

  • Create a strong application architecture, preferably placed within the larger enterprise architecture, and linked to the process and data architecture. 
     
  • Rationalize your application portfolio: make sure the cost allocation versus the benefit of use leads to the best results, and create awareness for the users.
     
  • Establish a strong application governance: centralization should be the foundation, but controlled decentralized solutions with a central follow-up can also be implemented.
     
  • Set up an IT solution process, in order to control the influx of solutions and applications and define a well-thought-out what- and why-analysis before you move on to the how-phase.

We’ll support you in each of these actions, but in this article our main focus will be on that last bullet: setting up a strong IT solution process.

A woman looking away from the camera, smiling.

a strong IT solution process: how do you get started?

We’ve divided the IT solution process into a roadmap that leads to the correct solution and helps you achieve the desired results.

Our roadmap consists of the following steps:

  • what (the definition of the need, also called the scope)
  • why (feasibility study)
  • how

what.

The first step in the IT solution process is defining the problem and its cause. What does your company need right now? This is called the what-stage. It’s crucial to involve all your stakeholders during this stage.

After implementing the solution, it often becomes clear that the what-question wasn’t answered correctly. Then you’ll hear the remarks: “this isn’t what we asked for” or “this isn’t what we were expecting”. That’s frustrating, and can also entail extra costs when you have to make adaptations or new developments. 

why.

In the second stage, we’ll use the definition of your company’s need to figure out why the solution is so important for your company and especially for your clients. Where can we find added value? 

We’ll once again include all stakeholders. Once we have defined the ‘why’ and the added value, we’ll do a check-in. We’ll use a feasibility study in which we check whether we can solve the ‘what’ and reach the expected benefits of the ‘why’. In this step, we’ll try to quantify the advantages based on budget, but also soft parameters such as the positive impact on the working of the organization. 

how.

It’s not until the third step that we will determine how to answer the what-question and realize the why-question. We’ll start with a concept phase, in which we mostly work out the what-question in terms of process and organization. We’ll also do some market research to see if there already are existing solutions. We call this a limited process-, organization-, and application architecture exercise that, if available, can be made within the enterprise architecture.

This exercise clarifies the size of the change, but also checks if the organization already has a suitable internal solution. We mostly want to avoid that organizations pay for different solutions for the same process (licences, maintenance …) when a single solution would be sufficient.

The concept phase will lead to a description of the process and the data, an organization impact analysis and a suggested solution. 

design stage.

The next step in the search for a suitable solution, is the execution of the design stage, in which we will further refine the results of the concepts to come to a workable solution (process, data, technology, application and organization). 

The design stage is the last theoretical step in which all the elements (process, organization, data, application and technology) come together. It can also be the foundation for a business case. The outcome is a ready-to-use answer to the what-question, with a strong guarantee that the added value of the why-question will be realized. 

Once we have defined the theoretical solution, we can start the implementation. We recommend starting small: possibly with a proof of concept (POC) in which we will, apart from the actual realization of the concept, also pay attention to the possible partners (proof of partnership). We make sure that the planned approach is sufficient for further roll-out (proof of approach) and that the suggested architecture fits within the larger company and, more importantly, that it works (proof of architecture/tooling).

You can opt for a pilot implementation, in which we start by implementing the solution for a few users or websites, and further analyze the solution and the results in detail. The actual roll-out will happen afterwards.

By using these different stages when working out the solution, the organization stays in control of the implementation. We use the so-called stage gate approach, in which we plan the desired results and delivery of each stage. At the end of the stage, we can decide to stop solving the what- and why-question if we see that the costs don’t outweigh the benefits.

what if you don’t work according to these stages?

If you don’t clearly define the what- and why-question, the risk of failure is clearly higher, and your efforts could go to waste. Some examples:

  • The competition uses method X to digitize, so I should use this method too.
    • Result: the digitization results in little to no added value, and does not offer a clear advantage as compared to the competition. 
       
  • While at an event, I saw a reporting solution that’s brand new and looks fancy. I immediately decide to buy it.
    • Result: during or after the implementation, I notice that the solution is not that beneficial at all, and that my current way of working already satisfies all my needs.
  • I have done a what-analysis, and I’ve defined an issue. I decide not to do a why-analysis or feasibility study and just buy a solution that’s available on the market.
    • Result: the solution is implemented, but does not actually resolve the what-question, or has so many side effects that it barely has any added value.

This list of examples in which things went wrong, makes it clear that a good preparation and a clearly planned approach heightens your chances of success. By also using the stage gate approach, we set up an intermediate surveillance that makes sure the desired result is achieved.

concrete framework.

AUSY has already transformed the above-mentioned approach into a concrete framework for different companies. Would you like to know more, or do you have a specific question? Don’t hesitate to contact jan.verbieren@ausy.be