Il Kick-off Odoo visto dall'interno

Spoiler: non prende appunti.

C'è una scena che si ripete in molti progetti ERP. Il fornitore arriva alla riunione di Kick-off con un template da compilare, fa le domande standard ( quanti utenti, quali moduli, avete un IT interno?) e dopo novanta minuti torna in ufficio con quattro pagine di note che sembrano complete ma non lo sono.

Il problema emerge tre mesi dopo quando, in fase di test, qualcuno alza la mano e dice: "ma noi questa cosa la facciamo diversamente." E "diversamente" significa dover rimettere mano a qualcosa che si credeva chiuso.

In Unitiva, il Kick-off funziona in un altro modo.. Non perché abbiamo un metodo più elaborato da mostrare, ma perché il Business Analyst che entra in quella stanza ha un obiettivo preciso: trovare quello che non vi verrà spontaneo raccontarci.

La domanda vera non è "cosa fate", è "cosa succede quando qualcosa va storto"

Un'azienda ben organizzata sa descrivere i propri processi in condizioni normali. Sa raccontare il flusso dell'ordine di vendita, la gestione del magazzino, il ciclo passivo. Lo racconta in modo lineare, logico, sensato.

Il problema è che Odoo non lavora solo nelle condizioni normali. Lavora anche il venerdì sera quando manca un componente e la produzione rischia di fermarsi il lunedì. Lavora quando un cliente chiama per modificare un ordine già in produzione. Lavora quando il fornitore consegna in ritardo e bisogna riallocare le priorità.

Per questo le prime domande che facciamo non riguardano i processi. Riguardano le eccezioni:

• Qual è la cosa che gestite ancora su WhatsApp o su un foglio Excel perché il gestionale attuale non riesce a tracciarla?

• Se domani mattina non riusciste ad accedere ai dati di magazzino, chi smetterebbe di lavorare per primo?

• C'è un processo che tutti sanno fare ma nessuno ha mai scritto da nessuna parte?

Queste domande fanno un certo effetto nella stanza. Non perché siano provocatorie, ma perché toccano esattamente i punti in cui il flusso informativo si interrompe e dove un'implementazione ERP, se non li intercetta, li consolida invece di risolverli.

Come si prendono appunti in un Kick-off che conta

La risposta breve: non si prendono appunti, si disegna.

Dal primo minuto in cui un process owner inizia a descrivere il flusso di un ordine, il BA inizia a mapparlo visivamente. Non su un template predefinito. Su una lavagna, su uno strumento di diagrammazione condiviso, su qualsiasi superficie che permetta di vedere il flusso mentre lo si racconta.

Il motivo è semplice: quando le persone vedono disegnato quello che stanno descrivendo, si correggono da sole. Dicono cose come "no aspetta, prima di questo step c'è un'approvazione" oppure "questa freccia non va lì, va all'ufficio acquisti". Quella correzione spontanea vale più di un'ora di domande.

Quello che il BA cerca mentre disegna sono tre cose specifiche:

1. I punti di handoff. Dove l'informazione passa da una persona a un'altra, da un reparto a un altro. Sono lì che si creano i ritardi, le duplicazioni, i dati che "spariscono". In Odoo, ogni handoff è un'opportunità di automazione o di notifica strutturata. Ma prima bisogna sapere dove sono.
2. Le dipendenze nascoste. Se un ordine di vendita innesca un fabbisogno in produzione che a sua volta genera un ordine di acquisto, bisogna vedere questa catena nella sua interezza prima di configurare qualsiasi cosa. Un modulo configurato senza conoscere il modulo a valle è una bomba a orologeria.
3. Il dato che esiste solo nella testa di qualcuno. In ogni azienda c'è almeno una persona che sa una cosa che nessun sistema traccia. Di solito è la persona più anziana del reparto. Quella conoscenza va estratta e formalizzata prima del go-live, non dopo.

Chi deve essere in quella stanza

Non è una questione di gerarchia. È una questione di copertura dei processi.

Il Project Sponsor (tipicamente un direttore generale o un imprenditore) serve perché è l'unico che può rispondere alla domanda più importante del Kick-off: dove vogliamo essere tra due anni? Senza quella risposta, si rischia di implementare Odoo ottimizzando processi che l'azienda ha già deciso di cambiare.

I Key User — i responsabili operativi dei singoli processi — sono i custodi della realtà. Sono loro a sapere che l'eccezione del venerdì sera esiste. Sono loro a conoscere il cliente che ha condizioni commerciali particolari, il fornitore che consegna sempre in anticipo e va gestito diversamente, la distinta base che ha una variante non documentata. Senza di loro, si costruisce un sistema perfetto su carta e impraticabile in produzione.

L'IT Manager, quando esiste, porta una prospettiva diversa ma essenziale: l'ecosistema. Odoo non vive da solo. Si integra con sistemi di logistica, con piattaforme e-commerce, con software di BI, a volte con MES di reparto o con strumenti verticali di settore. Sapere cosa c'è già, come è configurato e cosa non si può toccare è un vincolo progettuale che emerge meglio in Kick-off che in fase di analisi avanzata.

Una nota pratica: le riunioni con troppe persone non funzionano. Se il Kick-off diventa una platea, i Key User tacciono perché non vogliono dire la cosa sbagliata davanti al management. Meglio sessioni separate per area di processo, con un momento di sintesi comune alla fine.

La domanda che cambia tutto

C'è una domanda che facciamo sempre, di solito verso la fine del primo incontro, quando il clima si è sciolto abbastanza: “Siete disposti a cambiare il vostro processo per adattarvi allo standard di Odoo?”

Non è una provocazione. È la domanda più concreta che esista in un progetto ERP.

Odoo è costruito su best practice consolidate in migliaia di implementazioni globali. Quando un'azienda chiede una personalizzazione, quasi sempre sta chiedendo di replicare digitalmente qualcosa che fa in un certo modo perché "l'abbiamo sempre fatto così". A volte quella personalizzazione ha senso perché il processo è un vantaggio competitivo reale, qualcosa che l'azienda fa meglio di chiunque altro nel suo mercato. In quel caso, si personalizza e si investe in quel codice.

Più spesso, quella personalizzazione è debito tecnico travestito da requisito. E il Kick-off è il momento giusto per dirlo, non quello sbagliato.

Ogni customizzazione evitata è un aggiornamento futuro che non si blocca, una manutenzione che non si paga, un bug che non si genera. Il principio che seguiamo è semplice: prima di scrivere una riga di codice custom, bisogna dimostrare che lo standard non è sufficiente.

Cosa esce da un Kick-off fatto bene

Non un documento di analisi. Non ancora.

Quello che deve uscire da un primo incontro ben condotto è una mappa condivisa: tutti i partecipanti devono poter guardare quel diagramma e riconoscere la propria azienda. Non la versione ideale, quella reale con le eccezioni, i workaround, i processi informali.

Da quella mappa si parte per l'analisi As-Is vs To-Be: dove siamo oggi, dove vogliamo arrivare e quale distanza tra i due punti è coperta dal modulo standard di Odoo e quale richiede un lavoro aggiuntivo.

È un processo che richiede onestà da entrambe le parti. Noi portiamo la conoscenza della piattaforma e dei processi di settore, dal manufacturing alla logistica, dal food al pharma. Il cliente porta la conoscenza del proprio business. Il Kick-off è il momento in cui queste due conoscenze si incontrano per la prima volta. Se funziona, il progetto ha già le basi giuste. Se non funziona, il problema non è mai tecnico.

Avete un processo che vi sembra troppo complesso, troppo specifico o troppo "nostro" per essere messo in un ERP?

Conosciamoci. La prima call è gratuita e senza impegno: uno spazio per presentarci reciprocamente, approfondire le vostre sfide aziendali e capire insieme se Odoo è il partner tecnologico giusto per la vostra crescita e in che modo può diventarlo.
Prenota una call conoscitiva →