User support and maintenance: cost optimisation for IT department

Software maintenance & TPAM (Third Party Application Maintenance): the customer, its integrators and software publishers have to position themselves in terms of the different levels of maintenance they will take on. And the IT department has to organise all this to optimise budgets while ensuring user satisfaction: no easy task!

Level 1 maintenance: direct support for users

Level 1 maintenance, often referred to as user support or helpdesk (the hotline for old-timers...), is on the front line when a user encounters a problem.

Level 1 technicians focus primarily on the rapid resolution of common problems, such as password requests, user errors or difficulties with the user interface. Their main objective is to minimise user downtime and ensure that the software runs smoothly.

This level of support can be managed :

• by the customer himself: a good solution for maintaining control over changes to the solution, but at what cost? The time spent by the project team is not always properly accounted for, as the most expert staff are often working on multiple projects.
• by a service provider specialising in user support: this takes the pressure off the project team and can be provided by the integrator as part of a TPAM project.
• directly by the software publisher: this is often offered for ‘point solutions’, i.e. solutions that are not very cross-functional and that focus on the user (e.g. CAD software). On the other hand, this is much less the case for ERP, where some users' requests have to be filtered by the project team.

Level 2 maintenance: resolving technical and configuration issues

Level 2 maintenance comes into play when problems exceed the capabilities of level 1 support. This level involves resolving more technical issues and managing the specific configurations of the software (in particular the settings made when the software was implemented).

Level 2 technicians, often technical experts or integrators, can perform more in-depth diagnostics, adjust software parameters or resolve infrastructure-related issues.

Level 2 responsibility is carried out as part of an application management contract or as part of software maintenance (where the vendor is the integrator). In the former case, the cost is generally higher than in the latter.

Level 3 maintenance: bug fixing and development

Level 3 maintenance is almost always carried out by the software publisher itself, particularly in view of the intellectual property rights held by the publisher. The aim is to resolve software bugs: code errors or the need for additional development to resolve parameterisation difficulties.

Level 3 engineers are usually developers or technical specialists with in-depth knowledge of the software source code. They are responsible for fixing bugs and providing updates.

And what about TPAM?

As mentioned above, TPAM, or Third Party Application Maintenance, is an outsourced solution where a third party service provider takes care of application maintenance and upgrades. This often includes levels 1, 2 and sometimes even 3 for software that is not maintained by a software vendor (in the case of certain applications).

The TPAM provider takes care of user support, technical aspects, regular updates and relationships with publishers who provide level 3 maintenance. This global approach allows organisations to focus on their core business while ensuring that their applications remain up to date and effective.

However, the cost of this approach is driving organisations to enter into application management contracts for the most critical and/or complex applications in their information systems.

Roles between customers, integrators and publishers: an evolving choice?

The division of roles between customers, integrators and software publishers can vary according to the needs of the business and the complexity of the systems in place. Customers can choose to manage level 1 support in-house, while outsourcing levels 2 and 3.

This choice is particularly useful for the customer at the start of the project to fully understand user reaction and any changes that need to be made. However, given the hidden costs mentioned above, this strategy needs to be reviewed periodically as the deployed solution matures.

Similarly, level 2 maintenance, which is often performed by the original project integrator at the outset, may be called into question in the following years.

Governance: the key to effective maintenance?

Software maintenance governance is essential to ensure a clear division of responsibilities and effective communication over the long term. Good governance involves the implementation of clear processes and guidelines (RACI or equivalent), as well as regular coordination between customers, integrators and publishers. A steering committee comprising all these stakeholders should meet at least twice a year. Beyond RACIs, KPIs and other SLAs, the reality of projects and the notorious grey areas are legion, and the 'hot potato' effect of being passed back and forth can quickly set in!

Your maintenance: what are the trade-offs?

The IT department, in collaboration with the business departments, must position its software maintenance on several axes:

• Overall budget: user satisfaction vs. maintenance cost control
• Composition of the maintenance team: internal IT department vs. business sponsor
• Software budget: split between maintenance and upgrade requests
• Sustainability of knowledge: internal control vs. outsourcing
• The IT department must therefore regularly reassess its approach in order to optimise satisfaction and costs.

To help IT departments, Quadza Software offers a hybrid solution with profiles that can be integrated into the maintenance team in the long term, while optimising costs and relieving the project team's experts. Interested? Contact us now!