Un'applicazione in produzione continua a evolversi anche quando non viene aggiunta alcuna funzionalità. Browser, sistemi, librerie, certificati, volumi e servizi di terze parti cambiano. Gli utenti incontrano casi imprevisti e i rischi di sicurezza vengono rivalutati.
La manutenzione applicativa organizza questa continuità. Non si riduce a un monte ore né a un indirizzo e-mail. Definisce il perimetro, le responsabilità, le priorità, i tempi di presa in carico, la capacità di evoluzione e il modo di misurare il servizio.
Questa guida aiuta a strutturare il dispositivo. Non costituisce un modello legale; le clausole devono essere adattate al contesto e validate dalle parti.
TMA, support, manutenzione e gestione IT: distinguere i servizi
La manutenzione correttiva tratta le anomalie. La manutenzione preventiva riduce i rischi prima dell'incidente: aggiornamenti, revisioni, test di backup. La manutenzione evolutiva modifica il prodotto. Il supporto accompagna gli utenti o gli amministratori. L'outsourcing copre l'esercizio dell'infrastruttura e dei servizi tecnici.
La TMA, o terza manutenzione applicativa, può raggruppare diverse di queste attività quando vengono affidate a un fornitore. Il contratto deve precisare cosa è incluso. Un errore di codice, un dato errato, una saturazione del server e una domanda sull’utilizzo non richiedono la stessa competenza né lo stesso impegno.
Definire il perimetro prima delle scadenze
Il perimetro comprende le applicazioni, le versioni, gli ambienti, le interfacce, i processi pianificati, i servizi di terze parti e le ore di utilizzo. Specifica chi gestisce il cloud, il database, i certificati, i backup, il DNS, il postazione utente e i fornitori esterni.
Bisogna inoltre elencare le esclusioni: sistema non documentato, componente non supportato, accesso non fornito, modifica diretta da parte di terzi o ambiente di test assente. Un'esclusione deve portare a un piano di riduzione, non diventare una scusa permanente.
Costruire una matrice di priorità
Una priorità è determinata dall’impatto, dall’estensione e dall’esistenza di una soluzione alternativa. Un esempio generico:
| Livello | Situazione | Esempio | Obiettivo iniziale |
|---|---|---|---|
| P1 critica | Servizio o funzione vitale non disponibile, rischio dati/sicurezza | impossibilità di elaborare ordini | assistenza e cellula di incidente immediata secondo copertura |
| P2 maggiore | Funzione importante degradata, bypass limitato | import bloccato per una squadra | diagnosi prioritaria |
| standard P3 | Anomalie circoscritta, aggiramento accettabile | errore di visualizzazione o regola secondaria | pianificazione nella manutenzione |
| P4 minore | fastidio lieve o richiesta di miglioramento | etichetta, comfort, ottimizzazione | backlog evolutivo |
La qualificazione deve poter essere rivista dopo la diagnosi. Un sintomo visibile da un solo utente può rivelare un difetto di dati globale; un avviso impressionante può essere senza impatto.
Non confondere i termini
Il tempo di presa in carico corrisponde all'inizio del trattamento. Il tempo di diagnosi mira a una comprensione iniziale. Il tempo di recupero riporta il servizio a un livello accettabile, talvolta con soluzioni alternative. Il tempo di risoluzione apporta la correzione definitiva.
Promettere una risoluzione fissa per qualsiasi anomalia è raramente realistico, poiché la causa può dipendere da terzi o richiedere una migrazione. Un impegno più solido riguarda il coinvolgimento, la comunicazione, il ripristino e l’escalation.
Definire gli orari di copertura
Un'applicazione utilizzata dal lunedì al venerdì non ha automaticamente bisogno di una reperibilità 24/7. Al contrario, i processi notturni, gli utenti internazionali o le campagne possono creare periodi critici fuori dall'ufficio.
La copertina deve distinguere:
- ricezione e registrazione delle richieste;
- supervisione automatica ;
- assistenza umana ;
- intervento tecnico;
- disponibilità dei decisori aziendali.
Una reperibilità senza accesso, documentazione, monitoraggio né autorità decisionale offre poca protezione.
Organizzare il canale d'ingresso e l'arrampicata
Ogni richiesta deve ricevere un identificativo, una priorità, un ambiente, un impatto, elementi di riproduzione e un richiedente. Le urgenze utilizzano un canale esplicito; un'email inviata di notte non deve essere considerata come attivazione di reperibilità se questo meccanismo non è concordato.
L'escalation precisa che viene contattata quando l'incidente supera il perimetro, coinvolge un fornitore, richiede una decisione aziendale o diventa una crisi. Le coordinate e i ruoli vengono rivisti regolarmente.
Lo schema rappresenta sette fasi successive. Il ripristino del servizio non chiude il ciclo: l’analisi e la prevenzione trasformano ogni incidente in un miglioramento misurabile.
- Rilevare : individuare l'anomalia tramite supervisione, log o segnalazione da parte dell'utente.
- Qualificatore : misurare l'impatto, l'estensione, la criticità e i rischi associati.
- Contenere : limitare la propagazione e proteggere i dati o i percorsi ancora disponibili.
- Ripristinare : riportare il servizio a un livello accettabile, se necessario tramite un bypass controllato.
- Analizzare : identificare le cause tecniche e organizzative a partire dai fatti.
- Prevenire : aggiungere le correzioni, gli avvisi, i test o le procedure che riducono la ricorrenza.
- Migliorare : seguire le azioni e adattare il dispositivo di manutenzione durante la revisione del servizio.
Prevedere una capacità, non solo un tasso giornaliero
La manutenzione ordinaria beneficia di una capacità riservata. Può assumere la forma di un forfait, di un numero di giorni mensili, di un consumo minimo o di un budget reale con tetto massimo. Ogni modello distribuisce in modo diverso il rischio di disponibilità delle risorse.
Il budget deve distinguere:
- base di servizio e governance;
- supervisione e reperibilità;
- correttivo corrente;
- aggiornamenti preventivi;
- evoluzioni pianificate;
- cantieri eccezionali.
Mescolare tutto in una sola busta porta spesso a sacrificare gli aggiornamenti a favore delle richieste visibili.
Mantenere una politica di versioni
Il contratto descrive come vengono monitorate le dipendenze, le vulnerabilità e le fine del supporto. Gli aggiornamenti minori vengono testati regolarmente; le versioni principali sono oggetto di uno studio e di un progetto pianificato.
L'obiettivo è evitare l'alternanza tra immobilismo e migrazione urgente. Un bilancio preventivo livella lo sforzo e mantiene la possibilità di evolversi.
Misurare un servizio utile
Il numero di ticket chiusi non è sufficiente. Gli indicatori possono includere:
- disponibilità dei percorsi critici;
- termine di rilevamento;
- tempi di presa in carico e di recupero per priorità;
- tasso di riapertura;
- incidenti ricorrenti;
- cambiamenti che hanno provocato un guasto;
- età del backlog di sicurezza;
- consumo correttivo, preventivo ed evolutivo;
- soddisfazione degli interlocutori.
Le misure devono essere interpretate. Un aumento dei ticket può riflettere una migliore rilevazione, non un peggioramento.
Organizzare le revisioni di servizio
Una revisione mensile o trimestrale esamina gli incidenti, la capacità, i rischi, le versioni e la roadmap. Identifica le cause ricorrenti e decide le azioni preventive. Gli argomenti di bilancio vengono discussi con prove, non solo durante un'emergenza.
Il verbale attribuisce ogni azione, la sua scadenza e il suo criterio di chiusura. Le divergenze di impegno vengono analizzate per migliorare il processo.
Preparare l'uscita fin dall'ingresso
Il dispositivo deve includere la reversibilità: documentazione, accesso del cliente, esportazione dei ticket, proprietà degli account, trasferimento delle conoscenze e rotazione dei segreti. Questa preparazione protegge il cliente e migliora anche la qualità quotidiana.
Un contratto allineato alla criticità reale
La disponibilità perfetta non esiste e ogni esigenza ha un costo di architettura, di strumenti e di organizzazione. Il buon contratto rende esplicito questo compromesso. Esso definisce ciò che è critico, come il servizio viene ripristinato e come i rischi vengono ridotti nel tempo.
Partitech assicura la manutenzione correttiva, evolutiva, l’hosting, l’outsourcing e, secondo le necessità, i turni di reperibilità. Possiamo rilevare un progetto sviluppato da terzi e costruire un quadro di servizio adatto ai suoi usi reali.
Per approfondire l'approccio, consulta il metodo per riprendere la manutenzione di un'applicazione esistente, preparate la continuità e ripresa dell'attività e imparate a calcolare il TCO di un'applicazione su cinque anni. Scoprite anche l’offerta Manutenzione, evoluzioni e hosting di Partitech.
Riferimento ufficiale
Riferimento consultato il 17 agosto 2026 :