Software gestionale di produzione su misura: cosa deve fare, come si costruisce e quanto costa

Il titolare di un'azienda di stampaggio plastico in provincia di Brescia mi mostra il suo "sistema di produzione". È un foglio Excel di quarantadue schede, aggiornato a mano da tre persone, che ogni mattina alle sette qualcuno stampa e appende in reparto. Il gestionale che usano da undici anni fa bene la fatturazione e il magazzino, ma non sa che un ordine passa da tre macchine, che uno stampo si rompe, che un lotto di granulo va richiamato. Quando il cliente chiede "da quale lotto viene questo pezzo?", la risposta richiede due ore e un telefono.

Questa guida è per chi si trova in quella stanza: imprenditore di una PMI manifatturiera o responsabile IT che deve decidere se far costruire un software gestionale di produzione su misura. Ti dico che cosa deve fare davvero, come si modella, quanto costa e dove sbagliano quasi tutti. Un software gestionale di produzione su misura ha senso quando il tuo modo di produrre è ciò che ti distingue dai concorrenti e nessun pacchetto lo rappresenta senza deformarlo: in quel caso un nucleo piccolo, costruito attorno a distinta base, ordini di produzione e tracciabilità dei lotti, si realizza in circa dieci settimane per 25.000-45.000 euro.

Se stai ancora scegliendo fra pacchetto e sviluppo dedicato in generale, parti da gestionale aziendale: pacchetto o su misura. Qui si parla solo di produzione, che ha regole sue.

Quando ha senso un gestionale di produzione su misura e quando no?

Il software di produzione su misura ha senso quando il processo produttivo è un vantaggio competitivo e i pacchetti costringono a cambiarlo; non ha senso quando la tua produzione è standard, perché un MES o un modulo ERP già pronto costa meno e si mantiene da solo. La domanda giusta non è "pacchetto o su misura", è "il mio modo di produrre è davvero diverso?".

Ho visto aziende comprare un modulo di produzione da 40.000 euro e usarne il dieci per cento, perché per il resto del processo il pacchetto pretendeva un ordine delle fasi che in reparto non esiste. Ho visto anche aziende far costruire un sistema su misura per fare esattamente ciò che un pacchetto da 6.000 euro l'anno faceva già. Sbagliano in due direzioni, e il costo dell'errore è alto in entrambe.

Tre segnali che il pacchetto non basta

Il primo segnale è il foglio Excel parallelo: se in reparto vive una cartella di fogli che il gestionale non conosce, il pacchetto non rappresenta la realtà. Il secondo è la lista di eccezioni: quando per ogni ordine speciale serve un'autorizzazione, un campo note e una telefonata, le eccezioni sono diventate la regola. Il terzo è la tracciabilità a mano, con etichette scritte e registri cartacei, perché il programma registra il pezzo finito ma non da dove arriva.

Tre segnali che il su misura è una spesa sbagliata

Se produci su commessa con cicli classici (taglio, assemblaggio, collaudo) e nessuna regola speciale, un modulo di produzione di un ERP medio basta. Se hai meno di dieci persone in reparto e un solo turno, il costo di un sistema dedicato difficilmente si ripaga. Se non hai nessuno in azienda che conosca il processo e possa affiancare lo sviluppatore, il progetto finisce su requisiti inventati.

La regola che uso io

Prima di consigliare lo sviluppo dedicato chiedo di descrivermi una giornata tipo, ora per ora, di un ordine speciale. Se il racconto entra in un modulo standard con due adattamenti, consiglio il modulo. Se il racconto continua a contenere frasi come "ma da noi si fa diversamente", allora il su misura è giustificato, e il racconto stesso diventa il primo documento dei requisiti. Per i costi generali di un progetto simile, i numeri sono in quanto costa un software gestionale su misura.

Che cosa deve fare davvero un software di produzione: il perimetro minimo

Un gestionale di produzione minimo gestisce sei cose: anagrafica degli articoli, distinta base, ciclo di lavorazione, ordini di produzione con avanzamento, movimenti di magazzino legati agli ordini e tracciabilità dei lotti. Tutto il resto (pianificazione avanzata, manutenzione, costi consuntivi, qualità statistica) arriva dopo, quando il nucleo gira e il reparto lo usa.

L'errore classico è il perimetro gonfiato. Il primo incontro produce una lista di sessanta funzioni, tutte "indispensabili", e il preventivo diventa di 180.000 euro. Il progetto parte tardi, si ferma a metà e il reparto continua con Excel. Un nucleo piccolo e usato ogni giorno batte un sistema completo che nessuno apre.

Le sei cose del nucleo

L'anagrafica degli articoli dice che cosa esiste: materie prime, semilavorati, prodotti finiti, con unità di misura e codice. La distinta base dice di che cosa è fatto un prodotto. Il ciclo di lavorazione dice in quali fasi, su quali macchine o reparti e con quali tempi. L'ordine di produzione è la richiesta concreta di fare una quantità entro una data. I movimenti di magazzino registrano consumi di materiale e carichi di prodotto finito. La tracciabilità lega i lotti di ingresso ai lotti di uscita.

Che cosa lasciare fuori dalla prima versione

Fuori finiscono la contabilità industriale con costi consuntivi per commessa, la manutenzione programmata delle macchine, i cruscotti con dieci indicatori e l'integrazione diretta con ogni PLC. Sono tutte funzioni utili e tutte costruibili sopra un nucleo sano. Chi le mette in partenza rallenta tutto e scopre dopo tre mesi che il reparto usa solo l'avanzamento ordini.

Il test del lunedì mattina

Per decidere se una funzione entra nel nucleo mi faccio una domanda: lunedì mattina alle sette, il capo reparto la usa o no? Se la risposta è no, la funzione aspetta. Questo test taglia due terzi della lista iniziale e lascia ciò che serve davvero a far partire gli ordini.

Sul piano tecnico, chi ha già un impianto con supervisione trova il quadro nei miei articoli su automazione industriale con PLC e su SCADA, MES e OPC UA: il gestionale di produzione sta sopra quei livelli e li legge, non li sostituisce.

Come si modella la distinta base senza farsi male

La distinta base è un albero: ogni prodotto contiene componenti, ciascuno dei quali può avere la propria distinta; per modellarla bene servono revisioni con data di validità, quantità con scarto previsto e un controllo che impedisca i cicli. È la struttura dati su cui poggia tutto, e quella in cui gli errori si pagano di più.

In un'azienda di stampaggio la distinta di un tappo è semplice: granulo, colorante, imballo. In un'azienda di carpenteria la distinta di una pressa ha cinquecento righe su quattro livelli. Il modello deve reggere entrambe, quindi ogni riga dice quale articolo serve, in che quantità e con quale scarto, e non presuppone la profondità dell'albero.

Revisioni: il problema che nessuno prevede

Le distinte cambiano. Un fornitore cambia il tipo di vite, un cliente chiede una variante, un'ottimizzazione toglie un componente. Se il sistema ha una sola distinta per prodotto, un cambiamento di oggi altera il costo e la lista prelievi degli ordini già lanciati. Si risolve con le revisioni: ogni distinta ha un numero di revisione e una data di validità, e ogni ordine di produzione si porta dietro la revisione con cui è stato lanciato.

L'esplosione della distinta

L'operazione tipica è "dato un prodotto e una quantità, dimmi tutto il materiale che serve". Si chiama esplosione e si scrive in poche righe. Il codice qui sotto percorre l'albero, moltiplica le quantità tenendo conto dello scarto e segnala le distinte circolari, cioè i casi in cui un componente contiene sé stesso e il calcolo non finirebbe mai:

public sealed record Componente(string CodiceArticolo, decimal Quantita, decimal ScartoPercentuale);

public sealed record Distinta(string CodiceArticolo, int Revisione, IReadOnlyList<Componente> Componenti);

public static class EsplosioneDistinta
{
    // Restituisce il fabbisogno di materiale di primo livello (articoli senza distinta).
    public static IReadOnlyDictionary<string, decimal> Fabbisogno(
        string codice, decimal quantita, Func<string, Distinta?> trovaDistinta)
    {
        var totali = new Dictionary<string, decimal>();
        Esplodi(codice, quantita, trovaDistinta, totali, new HashSet<string>());
        return totali;
    }

    private static void Esplodi(string codice, decimal quantita, Func<string, Distinta?> trova,
        Dictionary<string, decimal> totali, HashSet<string> percorso)
    {
        if (!percorso.Add(codice))
            throw new InvalidOperationException($"Distinta circolare sull'articolo {codice}");

        var distinta = trova(codice);
        if (distinta is null)
        {
            totali[codice] = totali.GetValueOrDefault(codice) + quantita;
        }
        else
        {
            foreach (var c in distinta.Componenti)
            {
                var richiesta = quantita * c.Quantita * (1 + c.ScartoPercentuale / 100m);
                Esplodi(c.CodiceArticolo, richiesta, trova, totali, percorso);
            }
        }

        percorso.Remove(codice);
    }
}

Il codice è corto di proposito. La difficoltà non sta nell'algoritmo, sta nei dati: scarti dichiarati a occhio, unità di misura miste (chili e metri), articoli duplicati con due codici. Il primo mese di progetto serve spesso a ripulire l'anagrafica più che a scrivere software, ed è un lavoro che nessun preventivo dichiara.

Distinta ingegneristica e distinta di produzione

In aziende con ufficio tecnico esistono due distinte dello stesso prodotto: quella progettata, con ciò che il disegno prescrive, e quella di produzione, con ciò che in reparto si prende davvero dal magazzino (sostituti approvati, imballi, consumabili). Conviene modellarle come due livelli distinti, con un legame esplicito, invece di forzarle in un solo elenco: le discussioni su "quale distinta è giusta" finiscono lì.

Ordini di produzione e avanzamento: la macchina a stati che regge il reparto

Un ordine di produzione attraversa pochi stati (pianificato, rilasciato, in lavorazione, sospeso, completato, annullato) e il software deve permettere solo i passaggi consentiti, registrando chi li ha eseguiti e quando. Una macchina a stati esplicita elimina la classe di errori più comune nei gestionali di reparto: ordini "completati" che hanno ancora materiale da consumare.

Il difetto tipico dei sistemi fatti in fretta è il campo "stato" di testo libero, modificabile da chiunque. Dopo sei mesi nella tabella compaiono "finito", "FINITO", "chiuso", "ok" e "da rifare". Nessun rapporto è affidabile, e per capire dove sono gli ordini si torna al foglio appeso in reparto.

Transizioni consentite e storico

Ogni stato ha un elenco di stati raggiungibili. Un ordine pianificato può essere rilasciato o annullato, non completato. Uno in lavorazione può essere sospeso o completato. Uno completato non torna indietro: per riaprirlo si crea una rettifica tracciata. Ogni cambio di stato scrive una riga di storico con utente e ora, e quello storico serve sia per le contestazioni sia per misurare quanto tempo un ordine resta fermo fra una fase e l'altra.

public enum StatoOrdine { Pianificato, Rilasciato, InLavorazione, Sospeso, Completato, Annullato }

public sealed record CambioStato(StatoOrdine Da, StatoOrdine A, string Utente, DateTimeOffset Quando);

public sealed class OrdineProduzione
{
    private static readonly Dictionary<StatoOrdine, StatoOrdine[]> Consentiti = new()
    {
        [StatoOrdine.Pianificato] = [StatoOrdine.Rilasciato, StatoOrdine.Annullato],
        [StatoOrdine.Rilasciato] = [StatoOrdine.InLavorazione, StatoOrdine.Sospeso, StatoOrdine.Annullato],
        [StatoOrdine.InLavorazione] = [StatoOrdine.Sospeso, StatoOrdine.Completato],
        [StatoOrdine.Sospeso] = [StatoOrdine.InLavorazione, StatoOrdine.Annullato],
        [StatoOrdine.Completato] = [],
        [StatoOrdine.Annullato] = []
    };

    private readonly List<CambioStato> _storico = [];

    public StatoOrdine Stato { get; private set; } = StatoOrdine.Pianificato;
    public IReadOnlyList<CambioStato> Storico => _storico;

    public void CambiaStato(StatoOrdine nuovo, string utente, DateTimeOffset quando)
    {
        if (!Consentiti[Stato].Contains(nuovo))
            throw new InvalidOperationException($"Passaggio non consentito: {Stato} verso {nuovo}");

        _storico.Add(new CambioStato(Stato, nuovo, utente, quando));
        Stato = nuovo;
    }
}

Avanzamento per fase, non solo per ordine

Sapere che un ordine è "in lavorazione" non basta a nessuno. Il responsabile vuole sapere che la fase di stampaggio è chiusa, quella di assemblaggio è a metà e il collaudo non è partito. Per questo l'avanzamento si registra per fase: quantità prodotta, quantità scartata, tempo impiegato, operatore. Da questi dati nascono sia la consuntivazione dei tempi sia la stima della data di consegna realistica.

Come l'operatore comunica con il sistema

Se registrare l'avanzamento richiede tre minuti al terminale, l'operatore lo farà a fine turno, a memoria, e il dato sarà sbagliato. Il terminale deve chiedere al massimo tre gesti: leggere il codice dell'ordine con la pistola ottica o il tablet, premere "inizio" o "fine", inserire la quantità. Il resto (reparto, macchina, orario) lo sa già il sistema. Ho visto progetti riusciti e progetti falliti con la stessa tecnologia: la differenza era sempre il numero di tocchi richiesti all'operatore.

Pianificazione: come promettere date di consegna senza costruire un solutore

Una pianificazione utile per una PMI parte dalla data di consegna e risale all'indietro sommando i tempi delle fasi e le code dei reparti; un algoritmo di capacità finita completo serve di rado e va introdotto solo quando le regole semplici non reggono più. La prima versione deve rispondere a una domanda sola: "se mi arriva questo ordine oggi, quando posso consegnarlo?".

I fornitori di software di pianificazione avanzata vendono ottimizzatori che minimizzano i cambi di attrezzaggio e bilanciano le macchine. Sono strumenti seri per stabilimenti con centinaia di ordini al giorno. In un'azienda da quaranta persone producono un risultato più sofisticato dei dati che ricevono: i tempi di ciclo sono stime, i fermi macchina non sono registrati, e l'ottimizzatore raffina numeri sbagliati.

Pianificazione all'indietro in venti righe

Il metodo che consiglio per partire è il più semplice: dalla data di consegna promessa si sottraggono i giorni lavorativi necessari per ogni fase, e si ottiene la data entro cui l'ordine deve essere lanciato. Se quella data è già passata, il sistema lo dice subito, prima che il commerciale prometta una consegna impossibile.

public sealed record Fase(string Reparto, double OreLavoro, double OreAttesaMedia);

public static class Pianificatore
{
    // Data entro cui lanciare l'ordine per consegnare puntuali. Ignora festivi e sabati e domeniche.
    public static DateOnly DataLimiteLancio(DateOnly consegna, IEnumerable<Fase> fasi, double oreGiorno = 8)
    {
        var ore = fasi.Sum(f => f.OreLavoro + f.OreAttesaMedia);
        var giorni = (int)Math.Ceiling(ore / oreGiorno);

        var data = consegna;
        while (giorni > 0)
        {
            data = data.AddDays(-1);
            if (data.DayOfWeek is not (DayOfWeek.Saturday or DayOfWeek.Sunday))
                giorni--;
        }

        return data;
    }
}

L'attesa media fra una fase e l'altra è il numero più importante e quasi sempre il meno misurato. In molte officine un pezzo lavora due ore e aspetta due giorni davanti alla macchina successiva. Un sistema che registra gli orari di inizio e fine delle fasi fornisce, dopo un mese, le attese reali di ogni reparto, e la promessa di consegna diventa una stima basata su dati e non su ottimismo.

Quando serve davvero la capacità finita

Serve quando un collo di bottiglia (una pressa, un forno, una verniciatura) lavora oltre l'ottanta per cento del tempo disponibile e le code diventano imprevedibili. In quel caso il sistema deve conoscere il calendario del collo di bottiglia, i tempi di cambio attrezzaggio e la priorità degli ordini. Si costruisce come modulo successivo, sopra dati già raccolti, ed è il momento in cui valutare se comprare un pianificatore esterno o scrivere le regole su misura. Prima di quel punto, un foglio che mostra il carico per reparto per settimana, calcolato dagli ordini rilasciati, risolve il novanta per cento dei problemi.

La data promessa va tracciata

Ogni ordine conserva la data promessa al cliente, la data pianificata e la data reale di fine. Tre date, una riga di report: percentuale di ordini consegnati nei tempi, ritardo medio, reparto che ritarda più spesso. Basta questo per cambiare le conversazioni in azienda, perché il ritardo smette di essere una sensazione e diventa un numero.

Tracciabilità dei lotti: rispondere a un richiamo in dieci minuti

La tracciabilità dei lotti si realizza registrando, a ogni consumo di materiale, quale lotto di ingresso è finito in quale lotto di uscita; con questo legame un richiamo del fornitore si risolve con una sola interrogazione, in pochi minuti invece che in due giorni. Per molti settori (alimentare, farmaceutico, automotive, dispositivi medici) non è facoltativa.

La scena del titolare di Brescia è comune: un cliente segnala un difetto, il fornitore del granulo comunica che un lotto ha un problema, e in azienda parte la ricostruzione. Si cercano i bollettini, si controllano le etichette sui bancali, si chiede ai capi turno chi ricorda quale sacco è stato aperto. Nel frattempo altri pezzi dello stesso lotto sono già in viaggio verso altri clienti.

Il modello dei dati

Servono tre tabelle e un legame. I lotti di ingresso nascono quando la merce entra in magazzino, con fornitore, data e codice del lotto del fornitore. I lotti di produzione nascono quando l'ordine termina una fase o l'intero ordine. Il legame di consumo dice che il lotto di produzione X ha consumato la quantità Q del lotto di ingresso Y. Con queste tre cose si percorre la catena in avanti (dal lotto di materia prima ai clienti raggiunti) e all'indietro (dal pezzo difettoso ai materiali che lo compongono).

-- Quali clienti hanno ricevuto prodotti realizzati con il lotto di granulo G-2026-0417?
SELECT DISTINCT c.RagioneSociale, s.NumeroDocumento, s.DataSpedizione
FROM ConsumiLotto AS cl
JOIN LottiProduzione AS lp ON lp.Id = cl.LottoProduzioneId
JOIN RigheSpedizione AS rs ON rs.LottoProduzioneId = lp.Id
JOIN Spedizioni AS s ON s.Id = rs.SpedizioneId
JOIN Clienti AS c ON c.Id = s.ClienteId
WHERE cl.LottoIngressoId = (SELECT Id FROM LottiIngresso WHERE CodiceFornitore = 'G-2026-0417')
ORDER BY s.DataSpedizione;

Quell'interrogazione, con gli indici giusti sui legami, risponde in meno di un secondo anche con milioni di righe. Il tempo vero va nel registrare i consumi con onestà: se in reparto il sacco si apre senza leggere l'etichetta, la catena si spezza al primo anello. Per questo il lotto si legge con il codice a barre al momento del prelievo, non si digita a mano a fine turno.

Il costo della tracciabilità

Registrare i lotti aggiunge in media dieci secondi per ogni prelievo. In cambio si ottiene la risposta al cliente in minuti, il blocco mirato dei soli lotti coinvolti invece di fermare tutta la produzione e, nelle gare e negli audit di qualità, una prova documentale che molti concorrenti non hanno. Il valore economico di un richiamo gestito bene, rispetto a uno gestito male, è dell'ordine di decine di migliaia di euro per episodio.

Il lotto non è il numero di serie

Confondere i due concetti produce modelli sbagliati. Il lotto raggruppa pezzi prodotti nelle stesse condizioni, il numero di serie identifica un singolo oggetto. Alcune aziende hanno bisogno di entrambi (una pompa con numero di serie composta da componenti tracciati a lotto). Decidere all'inizio quale livello serve a quale prodotto evita di rifare il modello dati al sesto mese.

Il reparto e le macchine: terminali, codici a barre e quando collegare i PLC

Il modo più economico e più affidabile di portare i dati dal reparto al software è un terminale semplice con lettura di codici a barre; il collegamento diretto alle macchine con OPC UA o ai PLC si aggiunge solo dove automatizza un dato che l'operatore oggi inserisce a mano e sbaglia. Cominciare dalle macchine è l'errore più costoso del settore.

Un progetto che parte dal collegamento di dodici macchine di quattro marche diverse impiega mesi, dipende dal fornitore di ciascuna macchina e produce un cruscotto bellissimo di dati che nessuno sa leggere. Un progetto che parte da un tablet per reparto produce, in tre settimane, il primo dato vero: quanto tempo è stato impiegato su quell'ordine, da chi.

Tre livelli di collegamento

Il primo livello è manuale assistito: l'operatore legge il codice dell'ordine, preme inizio e fine. È sufficiente per l'80% delle aziende. Il secondo è semiautomatico: un contapezzi o un sensore invia la quantità prodotta, e l'operatore conferma solo gli stati. Il terzo è l'integrazione completa con il PLC tramite OPC UA o protocolli del costruttore, che comunica cicli, fermi e allarmi. Ogni livello si aggiunge al precedente senza buttare via nulla.

Quando conviene il terzo livello

Conviene quando il fermo macchina è un costo grosso e non registrato (linee ad alto valore orario) oppure quando la quantità prodotta è difficile da contare a mano (flussi continui, pezzi piccolissimi). Prima di spendere devi sapere quanto costa un'ora di fermo e quanti fermi hai al mese. Senza questi due numeri l'integrazione è una spesa di prestigio.

La rete di reparto

Un dettaglio che affossa progetti perfetti: il wifi del capannone. Muri di cemento, macchine che disturbano il segnale, zone d'ombra. Prima di acquistare i tablet si fa un sopralluogo con un misuratore di segnale e si decide dove servono punti di accesso. Se il progetto prevede l'uso con collegamento instabile, l'applicazione del terminale deve funzionare anche offline e sincronizzare quando torna la rete: nel nostro caso la scelta tecnica (un'applicazione web progressiva con coda locale) incide sul preventivo, e conviene deciderla all'inizio.

Per chi ha già una supervisione in funzione, la modernizzazione di quei sistemi segue un percorso suo, descritto in modernizzare un sistema SCADA legacy.

Come convivere con il gestionale e la contabilità che già hai

Il software di produzione non sostituisce il gestionale amministrativo: ne legge anagrafiche e ordini cliente, e gli restituisce consumi, carichi e spedizioni; i confini si definiscono con contratti di scambio chiari, non condividendo il database. Chi prova a rifare tutto in un colpo ripete l'errore dei grandi ERP: anni di progetto e un reparto ostile.

Il gestionale che hai ha clienti, fornitori, listini, fatture, magari anche un magazzino che funziona. Buttarlo via per una funzione che manca è sproporzionato. Si costruisce invece il nuovo pezzo (produzione) accanto al vecchio, con uno scambio di dati ben definito. È lo stesso principio del pattern Strangler Fig: si sostituisce un confine alla volta, senza spegnere il sistema esistente.

Che cosa passa in ciascuna direzione

Dal gestionale al sistema di produzione arrivano articoli, clienti, ordini cliente confermati e giacenze iniziali. Dal sistema di produzione al gestionale tornano i carichi di prodotto finito, i consumi di materiale, le quantità evase e, se serve, i costi di lavorazione. Sono due flussi, con un proprietario chiaro per ogni dato: l'anagrafica clienti è del gestionale, la distinta base è della produzione. Quando due sistemi possono modificare lo stesso dato, prima o poi si contraddicono.

Livello di protezione: lo strato anti-corruzione

Il formato dei dati del gestionale vecchio ha le sue stranezze: codici articolo con spazi, date salvate come testo, stati numerici senza descrizione. Se queste stranezze entrano nel modello della produzione, lo contaminano per sempre. Si risolve con uno strato di traduzione al confine, che converte i dati del vecchio mondo nel linguaggio del nuovo e lo fa in un solo punto del codice. Quando in futuro cambierai gestionale, riscriverai quello strato e non il resto.

Scambio per eventi, non per accesso diretto

La scorciatoia più tentante è leggere direttamente le tabelle del gestionale dal nuovo software. Funziona per un mese e poi si rompe al primo aggiornamento del fornitore, perché le tabelle non sono un contratto. Meglio un meccanismo di eventi o di esportazioni pianificate: "ordine cliente confermato" in ingresso, "ordine di produzione completato" in uscita. Se il gestionale non espone nulla, si usa un file o una tabella di scambio dedicata, con formato scritto e versione.

Se il gestionale è in Access o in Excel

Capita spesso nelle realtà più piccole. In quel caso la migrazione dei dati è parte del progetto e il gestionale amministrativo diventa il secondo passo, non il primo. I percorsi sono descritti in da Excel a un gestionale vero e in da Access a un gestionale su misura.

Architettura e tecnologia: che cosa scelgo per una PMI manifatturiera

Per un software di produzione di una PMI consiglio un monolite modulare su .NET 10 con database SQL Server, un'interfaccia web per l'ufficio e un'applicazione leggera per i terminali di reparto: poche parti, un solo servizio da pubblicare, nessun costo fisso eccessivo. I microservizi, in questa dimensione, aggiungono complessità che un'azienda da quaranta persone non può mantenere.

Ho visto proposte con dodici servizi, un bus di messaggi e un cluster di container per gestire cinquanta ordini al giorno. Il preventivo era di 200.000 euro e il costo di esercizio di 2.500 euro al mese. Lo stesso sistema, come monolite modulare su un server virtuale, costa un decimo e un solo sviluppatore lo capisce per intero.

Monolite modulare: confini interni netti

Un monolite modulare (la guida Microsoft alle architetture web lo descrive bene) ha un solo processo ma moduli separati con regole di dipendenza: Anagrafiche, Distinte, Ordini, Magazzino, Tracciabilità. Ogni modulo espone un'interfaccia pubblica e nasconde il resto. Se fra tre anni un modulo dovrà crescere da solo, sarà già staccabile. La struttura segue i principi che descrivo in Clean Architecture in .NET, applicati con misura.

Il database come fonte della verità

SQL Server o PostgreSQL, con transazioni vere. La produzione è un dominio in cui la coerenza conta: un consumo di materiale e il relativo movimento di magazzino devono riuscire insieme o fallire insieme. Per le parti che richiedono storia completa (movimenti di magazzino, cambi di stato, consumi di lotto) il modello a eventi con registro in sola aggiunta è una buona scelta, descritta in Event Sourcing in .NET: niente righe modificate o cancellate, ogni correzione è un nuovo movimento e il reparto trova sempre chi ha fatto che cosa.

Per l'accesso ai dati, una query lenta si riconosce e si corregge come in query lente con Entity Framework Core.

Interfaccia: web per l'ufficio, terminale per il reparto

L'ufficio lavora su un'interfaccia web classica: elenchi, filtri, esportazioni in Excel (sì, serviranno sempre). Il reparto lavora su schermate grandi, con pulsanti da toccare con i guanti, lettura di codici a barre e lingue mescolate quando gli operatori non sono tutti italiani. Le due interfacce usano lo stesso nucleo ma vivono separate, perché hanno esigenze opposte: l'ufficio vuole densità di informazioni, il reparto vuole un gesto per volta.

Ospitare il sistema

Un server virtuale in un data center europeo o su cloud pubblico, con copie di sicurezza giornaliere fuori sede e un ripristino provato almeno una volta. Una scelta che molte PMI rimandano: dove vive il sistema se manca la connessione a internet? Per un reparto che non può fermarsi, la risposta può essere un piccolo server locale con sincronizzazione verso il cloud. È una decisione di continuità operativa, e va presa con la direzione, non solo con l'informatica.

Quanto costa e quanto tempo richiede un gestionale di produzione su misura

Un nucleo di produzione su misura (anagrafiche, distinte, ordini, magazzino collegato, tracciabilità, terminali di reparto) richiede circa 40-75 giorni di lavoro, cioè 25.000-45.000 euro a 600 euro al giorno, e si consegna in dieci-quattordici settimane con un reparto pilota in funzione dalla sesta. I numeri crescono con l'integrazione di macchine e la pianificazione avanzata.

Sono stime indicative, e come tutte le stime dipendono da quanto è chiaro il processo. Un'azienda che sa descrivere i propri cicli, ha anagrafiche pulite e un referente disponibile due ore al giorno chiude vicino al minimo. Un'azienda che scopre il proprio processo durante il progetto sfora, e la colpa non è dello sviluppatore.

Il percorso completo di preventivo, tempi e metodo di lavoro è nella pagina software su misura per aziende.

Che cosa fa salire il conto

Tre cose, sempre le stesse. La pulizia dei dati (anagrafiche con codici doppi, distinte inesatte, unità di misura miste) può valere da sola 5-10 giorni. La formazione e il tempo del reparto: se gli operatori non hanno tempo per essere formati, il sistema parte e non viene usato. E le eccezioni scoperte tardi, tipicamente un cliente con un modo particolare di etichettare o di dichiarare i lotti.

Il costo dopo la consegna

Un software vivo costa. Prevedi il 12-18% del costo iniziale l'anno per correzioni, piccole evoluzioni, aggiornamenti del runtime e supporto. Su un progetto da 35.000 euro sono 4.200-6.300 euro l'anno, meno di un canone medio di un MES commerciale, ma non zero. Il costo del ciclo di vita completo è il vero metro, e lo stesso ragionamento vale per ogni software legacy, come spiego in quanto costa il software legacy.

Il ritorno dell'investimento

Il ritorno si misura su quattro voci: ore di coordinamento risparmiate (spesso un'ora al giorno per tre persone), scarti e rilavorazioni evitati, ritardi di consegna ridotti e richiami gestiti in minuti. Per un'azienda da trenta persone in reparto con 3,5 milioni di euro di fatturato, un recupero del 2% di efficienza vale 70.000 euro l'anno. Con numeri così il progetto si ripaga in sei-otto mesi, ma è un'ipotesi che va verificata con i tuoi dati, non accettata sulla parola.

Come partire senza sbagliare: i primi trenta giorni

I primi trenta giorni non si scrive codice di produzione: si affianca il reparto per tre giorni, si disegna il flusso reale di due ordini campione, si ripuliscono anagrafiche e distinte di un solo prodotto e si costruisce un prototipo cliccabile da far provare agli operatori. Questa fase costa poco e previene i due terzi dei fallimenti.

Il metodo che uso è sempre lo stesso. Il primo giorno passo in reparto con un taccuino e non propongo nulla. Guardo dove si ferma un pezzo, chi cerca un foglio, cosa si dice al telefono. Il secondo giorno ricostruisco con il capo reparto due ordini veri, dal momento in cui arrivano al momento in cui partono, fase per fase. Il terzo giorno mostro cosa ho capito e mi faccio correggere. Quasi sempre la correzione più grossa è "questo passaggio lo facciamo, ma non lo dici a nessuno": è il processo reale, quello che nessun documento riporta.

Un reparto pilota, non tutta l'azienda

Il sistema entra in un solo reparto o su un solo prodotto, con un responsabile contento di provarlo. Dopo quattro settimane si decide se estendere. Un lancio generale lo stesso giorno in tutta l'azienda concentra tutte le difficoltà nello stesso momento e rovina la fiducia di chi doveva essere convinto.

Affiancamento, non manuale

Un manuale di quaranta pagine non lo legge nessuno in reparto. Funziona di più una mezza giornata sul posto con l'operatore, e una scheda plastificata con i cinque gesti da fare appesa vicino al terminale. Il responsabile di reparto deve essere il primo utente, perché se lui usa il sistema, gli altri lo seguono; se lui continua con il foglio, il sistema è già morto.

La convivenza con Excel

Nelle prime settimane il foglio Excel e il nuovo sistema coesistono. Non è un fallimento, è un test: se i numeri dei due coincidono, si spegne il foglio. Se non coincidono, uno dei due sta sbagliando, e capire quale vale più del software stesso. Fissa una data di spegnimento di Excel prima di cominciare, altrimenti la convivenza dura anni.

Scegliere con chi lavorare

Il successo dipende dalla persona che scrive il software, non dalla tecnologia. Chi non ha mai visto un reparto produce un'interfaccia da ufficio. I criteri per valutare un fornitore stanno in come scegliere una software house, e la prima domanda da fare è sempre la stessa: mi mostri un reparto in cui questo sistema gira da almeno un anno.

Gli errori che vedo più spesso nei progetti di software di produzione

Gli errori ricorrenti sono sette: partire dalle macchine, gonfiare il perimetro, non pulire i dati, ignorare gli operatori, non avere un referente interno, rinviare la tracciabilità e non decidere chi possiede ogni dato. Nessuno è tecnico: sono tutti errori di impostazione.

Partire dalle macchine

L'abbiamo già visto: i dati delle macchine sembrano il cuore e sono la ciliegina. Senza ordini, distinte e fasi ben definite, un flusso di segnali non ha cosa raccontare.

Gonfiare il perimetro

Ogni funzione aggiunta alla prima versione ritarda la consegna e rimanda il momento in cui il reparto vede qualcosa di utile. La regola del lunedì mattina taglia la lista. Il resto va in un elenco ordinato per valore, rivisto ogni mese.

Non pulire i dati

Un sistema nuovo con anagrafiche sporche diventa un sistema nuovo con la stessa confusione, più veloce. La pulizia è parte del progetto: va stimata, assegnata a qualcuno in azienda e fatta prima del collaudo, non durante.

Ignorare gli operatori

Gli operatori conoscono i trucchi che tengono in piedi la produzione. Se non sono coinvolti dall'inizio, aggirano il sistema nel giro di un mese, scrivendo le quantità su un foglio e inserendole il venerdì. Il progetto dichiara successo e il dato è falso.

Nessun referente interno

Il software di produzione ha bisogno di una persona in azienda che abbia l'autorità di decidere "il processo è questo" e due ore al giorno da dedicare. Se tutte le decisioni passano dal titolare, il progetto procede alla velocità della sua agenda.

Rinviare la tracciabilità

"La tracciabilità la aggiungiamo dopo" significa rifare il modello dati. I legami fra lotti devono esserci dal primo giorno, anche se la schermata che li mostra arriva dopo.

Non decidere chi possiede ogni dato

Due sistemi che modificano lo stesso dato si contraddicono. La mappa dei proprietari è un foglio di una pagina da scrivere nella prima settimana, e vale più di qualunque diagramma.

Cosa fare se il progetto è già partito male

Succede, e non è irreversibile. Si ferma la scrittura di funzioni nuove, si misura che cosa il reparto usa davvero e si decide se correggere o ricostruire. Il criterio per scegliere è quello che spiego in riscrivere o rifattorizzare il software: raramente si butta tutto, quasi sempre si salva il database e si rifà l'interfaccia che nessuno apriva.

L'intelligenza artificiale in un gestionale di produzione: dove serve e dove no

L'intelligenza artificiale è utile in produzione per tre compiti circoscritti (leggere documenti di trasporto e certificati, stimare i tempi di ciclo dallo storico, rispondere a domande sui dati in linguaggio naturale) ed è dannosa quando decide al posto del sistema di regole che deve restare deterministico. Una distinta base non si "indovina": si legge, si calcola, si verifica.

Il primo compito è l'estrazione di dati da documenti. Il certificato di conformità di un lotto di acciaio arriva in PDF, ogni fornitore con un formato diverso. Un modello di linguaggio legge il documento e propone i campi (numero di colata, norma, valori), un operatore conferma con un clic. Si risparmia la digitazione e si tiene l'uomo come ultima verifica.

Il secondo compito è statistico: dopo sei mesi di avanzamenti registrati, il sistema sa che la fase di verniciatura dura in media il 30% più del tempo di ciclo teorico. Usare lo storico per correggere le stime è un calcolo, spesso senza nemmeno bisogno di un modello complesso. Il terzo compito, interrogare i dati in linguaggio naturale ("quali ordini del cliente X sono in ritardo questa settimana?"), diventa possibile con un server MCP che espone al modello solo funzioni di lettura: il modello chiede, il sistema risponde con dati veri, nessuno scrive nulla. L'approccio è descritto in agenti MCP per la manifattura.

Per costruire il server in pratica, c'è la guida creare un MCP server in .NET.

Dove l'AI non deve mettere le mani

Non deve decidere un cambio di stato, non deve scrivere movimenti di magazzino, non deve modificare una distinta. Sono operazioni con conseguenze legali e di sicurezza: richiedono regole esplicite, registro e un responsabile umano. L'AI può proporre, il sistema valida, la persona conferma. Un assistente che legge e suggerisce vale molto; uno che scrive senza controllo è un rischio che nessuna assicurazione copre.

Prima i dati, poi l'AI

Ogni progetto di "produzione intelligente" fallisce se manca la base: ordini ben registrati, tempi veri, lotti collegati. L'AI amplifica la qualità dei dati che ha, in bene e in male. Il nucleo di cui abbiamo parlato è il prerequisito di qualunque funzione intelligente, e costruirlo bene oggi rende possibile domani tutto il resto.

Domande che ricevo più spesso sul software di produzione su misura

Le domande ricorrenti sono sei: quanto tempo serve, se si può partire piccoli, di chi è il codice, come si collega al gestionale, cosa succede se lo sviluppatore sparisce e se il sistema regge la crescita. Le risposte sono dieci settimane, sì, tuo, con uno strato di scambio, il codice è documentato e tuo, e sì.

Il codice è mio?

Dovrebbe esserlo, per contratto. Il sorgente, la documentazione e gli accessi all'ambiente di pubblicazione sono tuoi dal primo giorno, in un repository intestato all'azienda. Chi tiene il codice sul proprio computer crea una dipendenza che non ti conviene accettare. Se il fornitore sparisce, un altro professionista deve poter riprendere il lavoro in una settimana.

Si può partire solo con un reparto?

Si deve. Un reparto pilota per quattro settimane è il modo più economico per scoprire cosa manca. Il sistema è costruito fin dall'inizio per più reparti, ma si attiva uno alla volta, con un responsabile contento di provarlo.

Regge la crescita?

Un monolite modulare con un database ben indicizzato regge decine di utenti contemporanei e milioni di righe senza difficoltà. I colli di bottiglia, quando arrivano, sono quasi sempre una query lenta o una pagina che carica troppo, non l'architettura. Il giorno in cui servisse dividerlo, i confini interni sono già tracciati.

E se arrivano certificazioni nuove?

Un sistema su misura si adegua alle norme del tuo settore (tracciabilità alimentare, audit di qualità, richieste dei clienti automotive) con evoluzioni mirate. Per questo il registro delle modifiche e dei consumi è in sola aggiunta: un'ispezione chiede "chi, quando, perché" e il sistema risponde senza ricostruzioni.

Il passo per lunedì

Prendi un ordine speciale recente e scrivi su un foglio, fase per fase, tutto quello che è successo: chi l'ha toccato, dove si è fermato, quale documento l'ha accompagnato, quale telefonata è servita. Conta quante volte il foglio dice "poi qualcuno ha chiamato". Quel numero è la misura di ciò che oggi il tuo software non sa, e il punto di partenza di ogni progetto serio.

Il titolare di Brescia ha fatto proprio questo esercizio. Dodici telefonate in un solo ordine. Dieci settimane dopo, il reparto pilota registrava avanzamenti dal tablet, la distinta del suo prodotto principale viveva in un sistema con revisioni, e il richiamo simulato di un lotto di granulo è stato chiuso in nove minuti. Il foglio Excel è stato spento alla data fissata, e il lunedì mattina alle sette nessuno ha più stampato niente.

Se hai una produzione simile e vuoi capire se ti serve un software su misura, o se un pacchetto basta, vieni a parlarne: nel percorso di sviluppo software su misura per aziende guardiamo il tuo processo reale, stimiamo costo e tempi del nucleo e decidiamo insieme da quale reparto cominciare. La prima conversazione serve a capire se il progetto ha senso, anche quando la risposta è che non ne ha.