La Briantea — il gestionale che parla la lingua dell'officina

Un'officina manifatturiera vive di cose che il software generalista non sa modellare bene. Un preventivo che diventa ordine. Un cliente che ha un proprio codice prodotto stampato sui suoi documenti, diverso dal nostro. Una distinta materiali che cambia il margine se cambia il costo del metallo questa settimana. Un operaio che entra in officina, prende in mano una commessa, lavora due ore, passa a un'altra, torna alla prima. Un dashboard finanziario che deve rispondere a una domanda semplice — "stiamo guadagnando?" — su dati che cambiano ogni giorno.

Per La Briantea abbiamo costruito il gestionale che modella esattamente questa realtà. Niente moduli generici riempiti di campi non pertinenti, niente flussi pensati per la grande azienda adattati a forza al piccolo capannone. Un sistema progettato attorno al modo in cui un'officina lavora davvero.

Il problema vero del gestionale per la manifattura

Chi gestisce un'officina ha provato, almeno una volta, a portarci dentro un ERP generalista. La storia finisce sempre allo stesso modo: due moduli vengono usati, otto restano vuoti, l'agenda della produzione resta su Excel, i costi reali continuano a essere calcolati a mente.

Il motivo non è l'inerzia degli operatori. È che gli ERP generalisti modellano "il prodotto" e "l'ordine" in modo astratto, mentre l'officina ha bisogno di modellare cose molto specifiche: un prodotto che esiste solo per quel cliente, un materiale che ha un prezzo che cambia ogni mese, un costo bloccato al momento della conferma dell'ordine perché altrimenti il margine continuerebbe a oscillare per ragioni che non c'entrano con la trattativa, un'operazione di lavorazione che dura quaranta minuti e va attribuita a una commessa precisa.

Senza questi dettagli, il gestionale è un quaderno digitale. Con questi dettagli, diventa lo strumento da cui dipende la marginalità dell'azienda.

La tesi: separare ciò che esiste da ciò che si trasforma

La spina dorsale del modello dati di La Briantea è una distinzione: ci sono entità che descrivono cosa esiste (un prodotto, un materiale, un'azienda) e ci sono entità che descrivono cosa è successo (un ordine confermato, una lavorazione completata, un prezzo pagato).

Questa distinzione, banale a dirla, è la cosa che permette al sistema di stare in piedi nel tempo. Il prezzo di un materiale può cambiare: ma se l'ho già usato in un ordine confermato del mese scorso, il margine di quell'ordine non deve cambiare. La distinta materiali può evolvere: ma se un cliente ha già ricevuto la consegna, il costo bloccato di quella commessa è la verità contabile, non l'ultima versione del catalogo.

Per questo, al momento della conferma di un ordine, il sistema fotografa il costo materiali della commessa e lo congela. Da quel momento in poi, il margine di quell'ordine è stabile contro qualunque modifica successiva al catalogo. È un dettaglio invisibile all'utente finale, ma è la differenza tra un sistema su cui costruire una dashboard finanziaria affidabile e un sistema che racconta storie diverse ogni volta che lo apri.

Prodotti che esistono solo per un cliente

Una delle scelte più peculiari del prodotto: non esiste un catalogo prodotti condiviso. Lo stesso oggetto fisico, venduto a due clienti diversi, è modellato come due prodotti separati.

Sembra una duplicazione. È invece l'unica scelta coerente con come funziona la manifattura su commessa. Ogni cliente ha le proprie specifiche, i propri codici, le proprie revisioni, le proprie immagini di riferimento. Trattarli come "varianti dello stesso prodotto" significherebbe forzare una falsa uniformità dove la realtà è eterogenea.

Ogni prodotto ha due codici. Il codice interno, generato dal sistema in formato leggibile (iniziali, anno, mese, progressivo), è il nostro modo di identificarlo. Il codice cliente è il codice che il cliente stampa sui suoi documenti. È il codice che il nostro sistema OCR usa per riconoscere il prodotto quando l'operatore carica un ordine cliente in PDF.

Questa doppia identità è la cosa che permette agli operatori di non rifare a mano l'inserimento dell'ordine: caricano il PDF, il sistema legge i codici cliente, abbina i prodotti, propone l'ordine pre-compilato.

L'assistente AI che avvia pipeline, non risponde a domande

La maggior parte degli "assistenti AI" infilati nei software gestionali rispondono a domande. La Briantea ha un assistente AI che avvia operazioni.

L'operatore può scrivere in chat: "Ho ricevuto questo ordine da Rossi", allegare il PDF, premere invio. L'assistente non risponde "ho capito": esegue una pipeline. Lancia l'OCR sull'allegato, estrae i prodotti, applica le regole di matching contro il catalogo del cliente, costruisce un payload di pre-compilazione, e apre il wizard di creazione ordine già popolato.

L'operatore arriva al wizard con tutto il lavoro pesante già fatto: deve solo verificare e confermare. Il tempo per creare un ordine cliente da un PDF passa da minuti a secondi.

Stessa cosa per i preventivi di acquisto a fornitori, per gli ordini di vendita con relativi ordini di acquisto materiali, per le conferme cliente complesse. L'assistente è il modo per innescare flussi che altrimenti richiederebbero molti click.

Operai, operazioni, tempi reali

Per produrre serve sapere chi sta facendo cosa, quando, su quale commessa. La Briantea modella le risorse (operai, fisicamente in officina) come entità distinte dagli account di sistema: l'operatore al PC condiviso registra le operazioni per conto di operai che non hanno credenziali proprie.

Ogni operazione è legata a un ordine, ha un inizio e una fine, e descrive in testo libero cosa è stato fatto. Lo stato è implicito: aperta finché non è chiusa. Un operaio può avere più operazioni aperte in parallelo, perché nella realtà succede.

A partire da queste operazioni, il report di produttività confronta i tempi effettivamente lavorati con il calendario di lavoro atteso (modellato come slot ricorrenti per giorno della settimana, con pause). Emerge il tempo morto, la metrica che dice se l'officina sta producendo al ritmo che dovrebbe.

Per chi gestisce un capannone, è la prima volta che questi numeri esistono in modo continuativo, senza dover essere ricostruiti a mano.

Dashboard finanziaria, margine reale

La dashboard finance non è una vista riassuntiva. È un modulo che ricalcola in tempo reale ricavi, costi materiali bloccati e margine, sui soli ordini effettivamente confermati. Mostra anche una metrica di "coverage margini" — quanta parte dei dati visualizzati è basata su distinte materiali complete e quanta è invece un'approssimazione perché manca il BOM o il prezzo storico di un materiale.

È un modo per non mentire a sé stessi. Se il novanta per cento del margine mostrato è "vero" e il dieci per cento è "stima", la dashboard lo dice esplicitamente. Chi guarda quel numero sa esattamente quanto fidarsi.

Lezioni dai primi mesi in produzione

La prima: l'OCR sui documenti cliente cambia la natura del lavoro di chi inserisce gli ordini. Non è più data-entry: è verifica. È un'attività molto più sostenibile e molto meno soggetta a errori da stanchezza.

La seconda: la separazione tra costi storici e prezzi correnti riduce drasticamente il numero di discussioni interne su "ma quanto abbiamo guadagnato davvero su quella commessa". Il numero è uno, è bloccato, è verificabile.

La terza: i report di produttività, una volta esistenti, modificano il comportamento degli operai. Non perché vengano usati per giudicarli, ma perché chi lavora ha per la prima volta un dato concreto sul proprio ritmo. È un'informazione, non un'arma.

Per chi vuole un gestionale che parli la sua lingua

Se gestisci un'officina, una manifattura su commessa, un laboratorio di produzione — e ti riconosci nella distanza tra come lavori davvero e come il software ti chiede di lavorare — scrivici. Possiamo capire insieme se costruire qualcosa di simile per la tua realtà ha senso, o se basta partire più piccolo e crescere per moduli.