La parte più costosa di qualsiasi progetto software non è lo sviluppo. Sono gli anni successivi, quando il sistema deve essere mantenuto in vita — aggiornato, protetto, monitorato, adattato a dipendenze che cambiano — e il fornitore originale non si trova da nessuna parte.
Il supporto IT gestito è il lavoro noioso e poco appariscente che fa la differenza tra un sistema che resta operativo e uno che si deteriora lentamente per diciotto mesi prima di fallire in modo spettacolare. È anche la parte di un incarico che la maggior parte dei fornitori vende con leggerezza e fornisce peggio di quanto promesso.
Le tre domande
Prima di firmare qualsiasi accordo di supporto — incluso uno con noi — fai queste tre domande.
1. Chi risponde esattamente quando apro un ticket alle 16:00 di venerdì?
La risposta giusta indica un team specifico, in un fuso orario specifico, con uno SLA specifico. La risposta sbagliata è un link a un portale di supporto e rassicurazioni vaghe. Qualsiasi offerta di supporto che non sappia indicare le persone che risponderanno davvero e i loro orari di lavoro è più vicina al marketing che al servizio.
2. Cosa copre il "supporto" — e, altrettanto importante, cosa non copre?
I veri accordi di supporto sono specifici: patch di sicurezza, aggiornamenti delle dipendenze, adattamento a modifiche incompatibili, monitoraggio, risposta agli incidenti, analisi della causa principale. Gli accordi vaghi permettono al fornitore di fatturare lavoro "aggiuntivo" ogni volta che succede qualcosa di interessante.
Chiedi l'elenco delle esclusioni. L'elenco delle esclusioni ti dice cosa sia davvero l'accordo di supporto. Se manca o è evasivo, l'accordo di supporto è una licenza di caccia — il fornitore potrà fatturare a ore alla prima anomalia.
3. Qual è il percorso di escalation quando il primo livello non riesce a risolvere il problema?
Ogni organizzazione di supporto ha un buon team e un ottimo team. L'ottimo team costa di più e viene coinvolto meno spesso. Se il percorso di escalation dal livello di triage dei ticket all'ingegnere senior non è chiaro, gli incidenti che richiedono l'ingegnere senior resteranno nel triage per giorni.
La risposta giusta indica un trigger di escalation specifico e una figura senior specifica. La risposta sbagliata è che "il team lo gestisce in modo collaborativo" — che è un modo educato per dire che non ne è responsabile nessuno.
Cosa copriamo
Il supporto IT gestito di KIMISUITE è l'attività continuativa che prosegue dopo che abbiamo sviluppato o migrato un sistema per te. Ha un ambito specifico:
- Monitoraggio dell'uptime — ogni sistema che gestiamo ha un monitoraggio attivo con avvisi agli ingegneri reperibili, non solo a una dashboard che nessuno guarda.
- Patch di sicurezza — aggiornamenti delle dipendenze con una cadenza definita, oltre a patch urgenti per CVE che interessano lo stack.
- Monitoraggio delle derive di conformità — il contesto normativo cambia continuamente. Il nostro servizio di supporto include la segnalazione delle modifiche che incidono sui tuoi sistemi prima che diventino rilievi di audit.
- Risposta agli incidenti — con uno SLA sulla prima risposta, uno SLA sulla risoluzione e un post-mortem scritto dopo ogni incidente significativo.
- Adattamento ai cambiamenti di terze parti — quando il provider di pagamento cambia la sua API, quando il sistema operativo rilascia un aggiornamento che rompe un'integrazione, quando il browser depreca qualcosa su cui facevi affidamento. La categoria di lavoro che nessuno nota finché non viene fatta.
Non copriamo: lo sviluppo di nuove funzionalità (è un incarico separato), cambiamenti significativi nell'ambito di funzionamento del sistema (anch'essi separati) o la formazione degli utenti (possiamo fornirla, ma come attività con ambito definito).
Domande frequenti
È un abbonamento o un retainer?
Un piano mensile definito legato a una copertura specifica. Non un retainer in cui le ore vengono consumate su attività ambigue — ti diciamo esattamente cosa include il piano.
Supportate sistemi che non avete sviluppato voi?
Caso per caso. Possiamo prendere in carico il supporto di sistemi sviluppati da altri fornitori se il codice e l'infrastruttura sono in uno stato tale da permetterci di assumerci l'impegno in modo responsabile. Se il sistema è fragile e privo di documentazione, potremmo consigliare un progetto di stabilizzazione prima di avviare il supporto.
E per la reperibilità in caso di emergenza?
Ogni piano include un numero di reperibilità per vere emergenze in produzione. Gli SLA di risposta variano in base al livello.
Gestite anche il supporto IT agli utenti finali — laptop, email, stampanti?
Di norma no. Il nostro ambito di supporto riguarda i sistemi e le applicazioni che noi o altri abbiamo sviluppato — non l'IT d'ufficio generale. Per l'IT generale possiamo consigliarti partner locali.
In sintesi
Sviluppare software è la parte piccola. Mantenerlo in vita per il prossimo decennio è la parte grande — ed è quella che i fornitori amano scorciare. Fai le tre domande sopra a qualsiasi offerta di supporto, inclusa la nostra. Se le risposte non sono specifiche, la copertura non è reale.