Ventinovesima guida operativa Odoo 19 per PMI italiane. La go-live week (settimana del passaggio in produzione) è la fase più stressante e più critica di tutto il progetto. Cinque giorni in cui il rischio di fallimento è massimo. Cinque giorni in cui un team preparato consegna una transizione fluida, mentre un team impreparato vive l’incubo “bloccato in produzione”. In questa guida vedremo come gestire ogni singolo giorno della go-live week con check-list operative.
Vediamo: pre-checklist 7 giorni prima, agenda di ognuno dei 5 giorni go-live, monitoring giornaliero, gestione incidenti, comunicazione stakeholder, errori comuni, casi pratici PMI.
La go-live week NON è il go-live
Errore comune: “go-live = giorno X”. In realtà la go-live week è un percorso strutturato di 5 giorni dove ogni giorno ha obiettivi specifici. Il giorno X è solo il “switch flag” che attiva Odoo come sistema operativo unico. Tutto il resto (preparazione, cutover, monitoring) è la vera differenza tra successo e disastro.
T-7: pre-checklist obbligatoria
7 giorni lavorativi prima del go-live, queste cose DEVONO essere già fatte. Se anche una sola manca, posticipa il go-live.
Tecnica
- Ambiente produzione configurato e testato (separato da staging)
- Backup automatici attivi e testati con restore
- Disaster recovery procedura testata
- SSL e dominio configurati
- Integrazioni esterne (banca, SdI, e-commerce) testate end-to-end
- Performance test con dati realistici (no demo data)
- Monitoring tool attivo (uptime, error rate, performance)
Funzionale
- UAT completato con approvazione formale stakeholder
- Tutti i workflow business validati su staging
- Personalizzazioni testate da utenti reali
- Report e dashboard configurati
- Documentazione aggiornata (manuali, FAQ, video)
Dati
- Master data importati e validati (clienti, fornitori, prodotti, contatti)
- Saldi contabili aperti calcolati e pronti per import
- Inventario fisico fatto, valori a sistema verificati
- Dati storici migrati (almeno 2 anni per analitica)
- Strategia “data lock” definita (quando il sistema vecchio diventa read-only)
Persone
- Formazione utenti completata (non < 80% staff)
- Help desk dedicato attivo (telefono, email, ticket)
- On-call rotation team partner definita
- Communication plan per stakeholder
- Comunicato interno “perché stiamo migrando” inviato a tutti
Giorno 1 (lunedì): cutover
Mattina (6:00 – 12:00)
- 06:00: backup finale sistema vecchio
- 07:00: ultimo import saldi/movimenti dal sistema legacy
- 08:00: validazione finale dati su Odoo produzione (smoke test)
- 09:00: kick-off operativo team con CEO
- 09:30: comunicazione formale “go-live” a tutti i dipendenti
- 10:00: utenti iniziano a lavorare su Odoo
- 10:00 – 12:00: monitoring intensivo, war room aperta
Pomeriggio (12:00 – 18:00)
- Affiancamento on-the-job continuo
- Triage ticket: P1 immediato, P2/P3 in coda
- Comunicazione status ogni 2 ore al management
- Verifica integrazioni esterne (fatturazione, banca, e-commerce)
- End-of-day report: ticket aperti, blocker, rischi
Monitoring magazzino: verifiche giornaliere
La dashboard magazzino è uno dei primi punti di controllo della go-live week. Da qui si vede in tempo reale se i ricevimenti e i prelievi stanno funzionando:
- Numero ricevimenti registrati (target = volume giornaliero tipico)
- Numero spedizioni in uscita
- Trasferimenti interni
- Pending operations da risolvere prima fine giornata
- Discrepanze giacenze vs sistema vecchio
Giorno 2 (martedì): stabilizzazione
Obiettivi
- Risolvere bug emersi giorno 1
- Hot fix per P1 entro 4 ore
- Sessioni Q&A su problemi ricorrenti
- Test transazioni real-time (vendite, acquisti, fatture)
Standup quotidiana go-live (08:30, 30 minuti)
- Numero ticket aperti per severity
- 3 blocker principali
- Owner di ogni blocker e ETA risoluzione
- Decisioni operative: continuiamo? rollback?
Metriche da tracciare
- Numero ordini di vendita creati (vs media settimana standard)
- Numero fatture emesse (vs media)
- Tempo medio inserimento ordine (vs sistema vecchio)
- Numero ticket help desk per area
Giorno 3 (mercoledì): monitoring contabile
Verifica registrazioni contabili
La dashboard accounting permette di verificare in real time che le registrazioni siano generate correttamente da tutti i workflow (vendite, acquisti, banca):
- Giornali vendite: tutte le fatture generano registrazioni
- Giornali acquisti: ciclo passivo allineato
- Giornale banca: estratto conto importato e riconciliato
- IVA: registri compilati correttamente
- Anomalie (registrazioni squadrate, conti mancanti)
Riconciliazione SdI
- Verifica fatture inviate a SdI e ricevuta consegna
- Gestione eventuali scarti SdI (entro 5 giorni)
- Verifica fatture passive ricevute
Giorno 4 (giovedì): consolidamento vendite
Verifica funnel commerciale
Il dashboard vendite deve mostrare lo stesso volume del periodo equivalente sul sistema vecchio. Se c’è uno scostamento > 15%, c’è un problema:
- Lead → Opportunità (verifica funzionamento CRM)
- Opportunità → Preventivi
- Preventivi → Ordini confermati
- Ordini → DDT → Fatture
- Statistiche per addetto vendite
User satisfaction check
- Survey breve 5 domande a tutti gli utenti
- NPS interno: “raccomanderesti il sistema?”
- Top 3 frustrazioni emerse
- Top 3 risultati positivi
Giorno 5 (venerdì): chiusura settimana
End-of-week report
- Numero ticket aperti vs chiusi
- SLA performance (P1 risolti in tempo?)
- Volume transazioni vs sistema vecchio
- 3 blocker residui da gestire la settimana successiva
- 3 win da celebrare con il team
Lessons learned mini-meeting (90 minuti)
- Cosa è andato meglio del previsto
- Cosa è andato peggio del previsto
- 3 azioni concrete per la settimana 2 di hypercare
- Documentazione lessons learned per progetti futuri
Comunicazione formale “go-live completato”
- Email del CEO a tutti i dipendenti
- Ringraziamenti specifici per chi ha fatto la differenza
- Roadmap prossimi 30 giorni hypercare
- Punti di contatto help desk
War room: come strutturarla
Layout fisico
- Sala dedicata con monitor (uno per area: vendite, magazzino, contabilità)
- Lavagna fisica per tracking ticket P1/P2
- Caffè/snack a disposizione (energia alta tutta settimana)
- Whiteboard “lessons learned” sempre aggiornata
Persone presenti
- Project Manager partner (dedicato, no altri progetti)
- Project Owner cliente
- 2-3 sviluppatori senior partner
- IT Manager cliente
- Key user per area (a rotazione)
- Project Sponsor (almeno 2 ore/giorno)
Strumenti
- Ticket system condiviso (Odoo Helpdesk, Jira, Linear)
- Canale Slack/Discord “war-room” sempre attivo
- Dashboard monitoring real-time (uptime, errors)
- Communication template pronto per stakeholder
Quando fare rollback (e quando NO)
Rollback giustificato
- Bug critico irrisolvibile in 24h che blocca operatività completa
- Perdita dati significativa non recuperabile
- Performance inaccettabili dopo 48h di tuning
- Sistema legacy ancora utilizzabile (data lock non ancora attivo)
Rollback NON giustificato
- Utenti che si lamentano della UI (= resistenza al cambiamento)
- Bug minori risolvibili con workaround
- Lentezza generica (di solito è formazione mancante, non sistema)
- Stress del management (decisione emotiva, non tecnica)
Criteri decisionali
Decidere rollback richiede consenso 3-3:
- Project Sponsor (CEO o equivalente)
- Partner Account Manager
- Technical lead (interno o partner)
- Maggioranza 3 su 3, mai unilaterale
Errori comuni nella go-live week
“Go-live in data critica”
Problema: go-live a fine mese (chiusura fatturazione), inizio anno (denunce IVA), agosto, dicembre.
Soluzione: scegliere una settimana “tranquilla” (es. seconda settimana di marzo, ottobre).
“Big bang completo senza pilota”
Problema: tutti i moduli, tutti gli utenti, tutte le sedi insieme dal giorno 1.
Soluzione: rollout per fasi (modulo o sede) se possibile. Riduce rischio.
“Team partner non dedicato”
Problema: consulenti partner gestiscono 3 progetti contemporaneamente, risposte lente.
Soluzione: contrattualmente esigere team dedicato per go-live week + 2 settimane hypercare.
“Comunicazione assente”
Problema: utenti non sanno chi contattare, problemi non vengono segnalati.
Soluzione: poster/cartelli con numero help desk in ogni reparto, training di 5 minuti su “come segnalare problemi”.
“Pressione su utenti finali”
Problema: CEO che chiede “perché non state già usando il sistema?”.
Soluzione: CEO comunica empatia (“ci stiamo abituando insieme”), non pressione.
Casi pratici PMI italiane
Caso 1 — Manifattura: go-live fluido
- War room in presenza, 6 persone dedicate full-time
- 15 ticket P1, tutti risolti entro 4h
- Volume vendite giorno 1: -8% vs media (recuperato in 3 giorni)
- Soddisfazione utenti fine settimana: 4.2/5
- Lesson learned: la war room fisica vale 10x quella virtuale
Caso 2 — Distributore: rollback evitato per poco
- Giorno 2: integrazione banca non funziona, blocco riconciliazioni
- Decisione team: NO rollback, hot fix in 18h
- Sistema vecchio mantenuto read-only 1 settimana extra
- Soluzione: bug API banca, fix lato partner Odoo
- Lesson learned: sistema legacy read-only è la migliore safety net
Caso 3 — Servizi B2B: rollback necessario
- Giorno 3: sistema lento (15s per caricare lista ordini)
- Performance test pre-golive insufficienti
- Decisione: rollback a sistema vecchio
- Settimane perse: 4, costo rollback: 18k €
- Lesson learned: performance test con volume reale è essenziale
Caso 4 — Studio professionale: go-live al weekend
- Go-live tecnico venerdì pomeriggio, utenti operativi lunedì
- Weekend per stabilization, lunedì war room ridotta
- Volume settimana 1: -3% (negligibile)
- Lesson learned: weekend go-live è ottimo se hai team disponibile
FAQ
Quanto deve durare l’hypercare post-golive?
Minimo 30 giorni di hypercare attivo (consulenti partner reattivi). Idealmente 60-90 giorni con presenza decrescente. Sotto 30 giorni = rischio elevato di lasciare problemi irrisolti.
Posso fare il go-live in remoto (no presenza fisica partner)?
Sconsigliato per PMI con > 20 utenti. La presenza fisica del consulente lead durante la prima settimana cambia drasticamente la velocità di risoluzione problemi e l’engagement utenti.
Quanti ticket P1 sono “normali” nella prima settimana?
Per progetto PMI 30-50 utenti: 10-25 ticket P1 in settimana 1 è normale. Sotto 5 = utenti non stanno usando attivamente il sistema (red flag). Sopra 40 = preparazione insufficiente, considera rollback.
Devo bloccare le vendite il giorno del cutover?
Idealmente sì, mezza giornata (fino alle 14:00). Permette validazione finale dati senza interferenze. Se non possibile, “data lock” su sistema vecchio dalle 9:00 e batch finale alle 14:00.
Quanto costa la go-live week?
Per PMI 30-50 utenti: 8-15k € di sole ore consulenti dedicati (5-7 giornate × 2-3 persone). Oltre al costo opportunità interna del team (40-60 ore/persona × 5-10 persone). Investimento totale “go-live week” ben fatto: 20-40k €. Risparmio rispetto a un go-live mal gestito: 100k+ €.
Prossimi passi
Nelle prossime guide vedremo come monitorare l’adozione Odoo nei primi 90 giorni con KPI dedicati, come strutturare il supporto post-golive di lungo termine, e come gestire i ticket e l’evoluzione del sistema.
Vuoi supporto per la tua go-live week Odoo?
G Tech Group accompagna le PMI italiane durante la go-live week con war room dedicata, monitoring real-time e hot fix prioritari. Hypercare 30-90 giorni post-golive incluso.
Richiedi un preventivo gratuito oppure prova la nostra demo Odoo 19 live. Oppure prova Odoo direttamente su odoo.com (link partner Brentasoft).
Vuoi una soluzione su misura per la tua azienda?
Brentasoft sviluppa gestionali, CRM e software personalizzati per PMI italiane. Parliamo del tuo progetto.
