Prima di prendere in carico, capire cosa esiste.
Una schermata con blocchi collegati non descrive da sola il sistema. Per prendere in carico un flusso servono account, sorgenti, configurazioni, dipendenze, documentazione e un elenco delle azioni che produce. Verifichiamo anche quali componenti siano effettivamente modificabili e chi controlli le licenze.
La ricognizione distingue guasti attuali, fragilità note e miglioramenti desiderati. Non promettiamo il supporto a qualsiasi automazione senza una verifica preliminare. Un flusso senza proprietario degli account o senza una possibilità di prova può richiedere prima un intervento di recupero documentale.
Controllare l’esito del lavoro, oltre allo stato del servizio.
Google SRE descrive segnali come latenza, traffico, errori e saturazione. Per un’automazione aziendale affianchiamo a questi indicatori il risultato operativo. Un flusso che risponde rapidamente ma assegna le richieste alla persona sbagliata richiede comunque attenzione.
Fai scorrere la tabella per confrontare tutte le colonne.
| Segnale | Domanda a cui risponde | Possibile azione |
|---|---|---|
| Età della richiesta più vecchia | Il lavoro resta fermo anche se il servizio è acceso? | Controllare il collo di bottiglia e assegnare la coda |
| Esiti mancanti o incoerenti | Il risultato atteso è arrivato nel sistema finale? | Riconciliare prima di ripetere una scrittura |
| Correzioni sulle proposte AI | La qualità è cambiata su un tipo di richiesta? | Esaminare esempi e verificare fonti o configurazione |
| Consumo per pratica | I costi crescono per tentativi ripetuti o input più lunghi? | Limitare il flusso e indagare la causa |
Esempio: un cambio di campo interrompe il flusso.
Scenario illustrativo: nel CRM viene rinominato un campo usato per assegnare attività. Il sistema continua a ricevere richieste, ma non completa il passaggio finale. Un controllo sull’età della coda individua il problema; la procedura sospende nuovi tentativi e conserva gli identificativi delle richieste coinvolte.
Il referente verifica quali attività siano già presenti, corregge la mappatura in prova e ripete un campione prima della ripresa. Si rielaborano solo le richieste da completare. La chiusura dell’incidente include causa, impatto, pratiche riconciliate e un cambiamento che aiuti a individuare prima un problema simile.
Cosa definire nell’accordo di supporto.
La disponibilità del fornitore di un’API non è sotto il controllo di chi mantiene il flusso. Le condizioni devono distinguere dipendenze, possibilità di mitigazione e attività manuali del team. Copertura continua e tempi garantiti esistono solo se esplicitamente concordati; non sono impliciti in questa proposta.
- Flussi, strumenti e versioni inclusi, con le dipendenze esterne note.
- Fasce di copertura, canale di segnalazione e criteri di priorità concordati.
- Differenza tra presa in carico, contenimento e risoluzione del problema.
- Chi può interrompere il sistema, autorizzare modifiche e approvare la ripresa.
- Modifiche incluse nella manutenzione e nuovi sviluppi da stimare separatamente.
- Accessi, dati e documentazione da restituire alla fine del rapporto.
Ogni modifica deve lasciare una traccia.
Modelli, istruzioni, fonti e regole di integrazione possono cambiare indipendentemente. Un registro collega ogni modifica al motivo, alla verifica effettuata e alla versione precedente. Per un componente AI riproviamo un campione pertinente: l’assenza di errori tecnici non dimostra che le risposte siano rimaste equivalenti.
La consegna può includere un manuale operativo, un inventario aggiornato, controlli periodici e una procedura di passaggio a un altro referente. Il cliente deve poter capire dove si trova il sistema e come proseguire. Questo è anche un criterio pratico per scegliere un partner di manutenzione.
Un modello su cui lavorare.
Runbook di gestione operativa AI
Istruzioni accessibili al personale incaricato: segnali, allarmi, diagnosi iniziale, ripristino e revisione periodica.
Scarica il modello MarkdownRegistro delle modifiche AI
Una cronologia delle versioni con motivazioni, impatto, evidenze di verifica e decisione di rilascio.
Scarica il modello MarkdownPassaggio di consegne dell’automazione
Un verbale di consegna con materiali accessibili, responsabilità accettate, prova di gestione e attività residue assegnate.
Scarica il modello MarkdownDomande pratiche
Potete mantenere automazioni create da un altro fornitore?
È una possibilità da valutare con una ricognizione tecnica. Servono accessi autorizzati, configurazioni recuperabili e condizioni compatibili con i prodotti usati. La presa in carico viene proposta dopo aver identificato limiti e dipendenze.
Il supporto include nuove funzionalità?
Dipende dall’accordo. Correggere un errore rispetto al comportamento concordato è diverso dall’aggiungere un nuovo processo, un canale o un’integrazione. Queste categorie vanno separate per evitare aspettative diverse.
Riferimenti e metodo
Riferimento tecnico per segnali di monitoraggio e allarmi utili; livelli di servizio e copertura devono essere concordati.