Linea di pesatura industriale automatizzata in un impianto luminoso e contemporaneo

Il software che pesa corretto per vent'anni si decide adesso, prima che concorrenza e volumi trasformino ogni ripensamento in un rifacimento.

Il peso è certoRendiamo altrettanto sicura l'architettura che lo governa

La vostra prossima generazione di macchine dovrà pesare corretto per vent'anni. L'architettura dati che lo garantisce si valida adesso, sul codice reale, prima che concorrenza, volumi e omologazione trasformino una scelta in un rifacimento.

Vedi le due offerte Come funziona
15-20 anniOrizzonte del software omologato
fino a 200 pezzi/minSulle linee automatiche
10 sviluppatoriDue reparti, una sola base dati
SCORRI

Quello che state scegliendo adesso dovrà reggere concorrenza, più device sullo stesso dato e query sotto carico, e restare funzionante per 20 anni senza toccarlo

Come ci siamo arrivati

L'evoluzione dell'accesso ai dati, in due minuti

01 / Lo scenario

Ogni settimana di codice in più rende il ripensamento più costoso

Avete già .NET 10, MariaDB ed Entity Framework in piedi, con un'architettura dati comune alle macchine automatiche e non automatiche. Oggi funziona. A macchina ferma e a volumi bassi un database perdona quasi tutto: le domande difficili restano fuori dalla porta. Poi la linea parte davvero, e arrivano tutte insieme.

  • Concorrenza

    Più terminali e più bilance leggono e scrivono lo stesso dato. Chi arriva primo lo aggiorna, e il secondo? Oggi non vi tocca. Con gli impianti multi-accesso vi torna davanti.

  • Sincronizzazione

    PC, PLC, scheda bilancia e stampante si sincronizzano a inizio lavorazione, e devono farlo nel minor tempo possibile. Ogni millisecondo di lettura in più allunga l'avvio.

  • Query sotto carico

    Dal LINQ che scrivete alla query SQL che viene generata: quando i volumi diventano reali, la differenza si sente tutta.

  • Migrazioni e omologazione

    Ogni macchina sul mercato da dicembre 2027 passa da test e fascicoli tecnici. Le scelte di oggi verranno lette allora.

Nessuno di questi è un errore vostro, sono le domande che ogni sistema industriale serio prima o poi incontra. Cambia solo il momento in cui trovate le risposte: adesso costano una decisione, dopo costano un rifacimento.

L'ultima volta che ho diretto la progettazione del data layer di una bilancia certificata, la usavano 15.000 ricercatori e doveva rispondere alla FDA. Quindici mesi di lavoro, con ambienti separati fino alla produzione. So che domande vi farà l'ente di omologazione, perché le ho già sentite.

Matteo MiglioreProgetto in ambito farmaceutico, certificazione FDA
02 / Due mondi, una sola base dati

Una sola architettura per due carichi opposti

Un unico impianto luminoso: in primo piano un terminale di pesatura statica, sullo sfondo una linea automatizzata ad alta velocità
  • Non automaticaUn terminale collegato a una pesa: il camion con container. Ritmo umano, schema semplice, spesso dieci tabelle con tre o quattro usate di frequente.
  • AutomaticaUn impianto in linea fino a 200 pezzi al minuto. Non si può bloccare: la query dev'essere veloce, ottimizzata, asincrona. Conta la stabilità.
  • La sfidaUna sola architettura che serve entrambi. Semplice dove basta, robusta dove il carico non perdona.
03 / Immaginate tra sei mesi

Il Direttore Tecnico apre il registro davanti all'ente di omologazione

Dicembre 2027. L'ente di omologazione chiede come vengono gestiti i dati quando due bilance scrivono sullo stesso record nello stesso istante.

Il Direttore Tecnico apre il registro delle decisioni. La scelta è lì, datata, con la motivazione tecnica e l'alternativa che avete scartato. Risponde nella stanza, senza ricostruire niente a memoria e senza rimandare a settimana prossima. Poi arriva la domanda dopo, e va allo stesso modo.

Mesi prima, quella riga era stata una decisione da venti minuti presa insieme. In sala omologazione vale la differenza tra un esame che scorre e uno che si pianta.

04 / Come funziona

Un metodo in sei fasi, ognuna con un deliverable verificabile

Sempre sul vostro codice, non su esempi da manuale. Ogni fase produce un documento che resta.

Tavolo di lavoro tecnico luminoso durante una revisione architetturale: schemi, laptop, calibro e un componente di precisione
  1. 01

    Rilievo dell'architettura

    Analisi del codice reale: modello dati, ciclo di vita del DbContext, transazioni, concorrenza e il SQL che Entity Framework genera davvero.

    Deliverable · fotografia tecnica dello stato attuale
  2. 02

    Diagnosi

    Vincoli e decisioni architetturali messi nero su bianco, con la motivazione tecnica. Cosa regge resta, cosa va rivisto viene isolato.

    Deliverable · punti critici prioritizzati
  3. 03

    Misura

    Benchmark sulla sincronizzazione delle quattro entità e sulle letture sotto carico, con numeri misurati sui vostri percorsi critici.

    Deliverable · baseline di performance misurata
  4. 04

    Correzione mirata

    Entity Framework dove è la scelta corretta, Dapper o ADO.NET dove il carico lo impone. Nessuna riscrittura inutile.

    Deliverable · interventi verificati sul codice
  5. 05

    Trasferimento dei criteri

    I criteri di decisione passano al team, applicati sul vostro codice. Alla fine si decide senza di noi.

    Deliverable · team autonomo sulle scelte dati
  6. 06

    Documentazione

    Registro delle decisioni e matrice dei rischi, in un formato pronto per l'omologazione e per il Direttore Tecnico.

    Deliverable · dossier tecnico difendibile
05 / Cosa resta in mano vostra

Un documento che il Direttore Tecnico porta in riunione

  1. Assessment dell'architettura dati

    Lo stato reale della base comune alle macchine automatiche e non automatiche.

  2. Mappa dei flussi e dei confini di responsabilità

    Chi scrive, chi legge, dove passano i dati tra PC, PLC, bilancia e stampante.

  3. Revisione del modello e del ciclo di vita del DbContext

    Il punto dove nasce la maggior parte dei problemi di concorrenza.

  4. Analisi di concorrenza e gestione dei conflitti

    Più terminali sullo stesso dato: chi arriva prima, cosa succede, come si risolve.

  5. Revisione delle query e del SQL generato

    Dal LINQ alla query reale, con gli strumenti per vederlo e ottimizzarlo.

  6. Criteri: dove Entity Framework, dove valutare alternative

    Una regola difendibile, non una preferenza personale.

  7. Registro delle decisioni architetturali

    Ogni scelta motivata e datata: la responsabilità diventa tracciabile.

  8. Matrice dei rischi prioritizzati e piano d'azione

    Cosa affrontare prima, cosa può aspettare, con quali tempi.

Dossier tecnico rilegato aperto su una scrivania luminosa, accanto a un componente di pesatura industriale lavorato con precisione
06 / AI, revisione e responsabilità

L'AI vi fa risparmiare ore. Ma la firma sotto una scelta architetturale se la prende una persona

Usate Codex e strumenti simili come si usava una volta la ricerca: per andare più veloci. È il modo giusto. Il valore che aggiungiamo è a valle: una decisione architetturale merita una revisione con esperienza e contesto prima di entrare in un sistema omologato.

Su un software che dovrà durare vent'anni, ciò che conta è la revisione, la tracciabilità e la responsabilità di ogni scelta. Il percorso vi dà un punto di validazione esterno: le decisioni le prendete voi, ma non le prendete da soli.

Ingegnere software che confronta con serenità una bozza sul laptop con documentazione e un componente reale di una macchina di pesatura
07 / Chi è Matteo Migliore

Entity Framework in produzione dal 2010, su dati che non perdonano

Matteo Migliore, fondatore di Sviluppatore Migliore

Fondatore di Sviluppatore Migliore. Ventisei anni su .NET e architetture software, con Entity Framework in produzione dal 2010. Ha fondato tre software house: l'ultima, un gestionale per studi legali dove EF Core gestiva milioni di documenti sotto carico reale, è sul mercato da quindici anni.

  • Ottimizzazione del data layer su applicazioni con milioni di record, dove il dato non può sbagliare.
  • Si lavora sul codice reale, con un principio: la soluzione più semplice che soddisfa i vincoli.
  • I percorsi one-to-one li segue personalmente. In una realtà come la vostra è troppo delicato per delegarli.
08 / Referenze

Chi ha lavorato con Matteo su Entity Framework, con parole sue

La cosa che mi è piaciuta di più è la nuova gestione della struttura del progetto: la suddivisione dell'interfaccia grafica dalla progettazione, non scrivere il codice direttamente nella UI.
Claudio Sofonio
Claudio SofonioEsperto di Business Intelligence, Cotonella S.p.a.Percorso Entity Framework
Una cosa nuova che non avevo mai provato e che abbiamo visto insieme è stato l'utilizzo degli unit test. Sarà sicuramente molto utile nel mio lavoro, e consiglio Matteo perché si può parlare con lui di come sta andando e aggiustare il tiro.
Jessica Filippi
Jessica FilippiSviluppatrice .NET, Cotonella S.p.a.Percorso Entity Framework
Una grande passione nella formazione. Oltre agli argomenti specifici, trovo suggerimenti su argomenti molto trasversali: progettazione, controllo del software, testing.
Luca Affini
Luca AffiniAnalista Software, WakiwiPercorso Entity Framework
09 / Il percorso, modulo per modulo

Otto fronti critici del vostro data layer, chiusi uno per uno sul vostro codice reale

Ogni modulo prende un punto dove il vostro data layer può cedere e lo chiude sul codice del vostro repository. Le competenze restano nel prodotto anche quando ce ne andiamo.

Fase 1 Fondamenta che reggono il carico · settimane 1-4
01Modulo 1

Un DbContext configurato a metà produce, dopo sei mesi, migrazioni che nessuno vuole più toccare

Rendiamo esplicito dal primo giorno come EF Core mappa lo schema comune alle macchine automatiche e non: Fluent API, configurazioni separate, ereditarietà e filtri globali. Il contratto tra il vostro codice e MariaDB torna leggibile.

Cosa mettiamo in sicurezza
  • Ciclo di vita del DbContext e context pooling. Scoping per richiesta, e perché condividere un'istanza tra thread è un errore che prima o poi corrompe i dati.
  • Fluent API al posto delle Data Annotation. Owned type, value object e table splitting, con le classi di dominio pulite.
  • Configurazione separata con IEntityTypeConfiguration. Un OnModelCreating di poche righe invece di un metodo da 500 che nessuno osa toccare.
  • Ereditarietà TPH, TPT, TPC. Cosa genera davvero ciascuna in SQL, e quale scegliere in base a query e sottotipi.
  • Shadow property e backing field. Chiavi esterne, timestamp e stato interno mappati senza sporcare l'interfaccia delle entità.
  • Filtri di query globali. Multi-tenancy e soft delete applicati in un punto solo, impossibili da dimenticare.
Strumenti e tecniche
DbContext poolingFluent APIIEntityTypeConfigurationTPH / TPT / TPCShadow propertyGlobal query filter
Cosa ottieni
  • Il modello comune alle macchine automatiche e non automatiche mappato correttamente dal primo giorno
  • Un DbContext pulito e leggibile, non un metodo da 500 righe
  • Migrazioni future che non riservano sorprese
02Modulo 2

L'applicazione rallenta, tutti giurano che le loro query sono a posto, e intanto EF manda a MariaDB SQL che nessuno ha mai letto

Apriamo il cofano. Logging del SQL reale, proiezioni con Select, IQueryable, split e query compilate: leggete quello che parte davvero verso il database e lo ottimizzate dove la linea non aspetta.

Cosa mettiamo in sicurezza
  • Logging del SQL generato. La prima verifica quando qualcosa è lento, e quasi l'unica che nessuno fa.
  • Proiezioni con Select. Caricare 3 colonne invece di 50, perché EF materializza l'intera entità se non glielo impedite.
  • IQueryable contro IEnumerable. La riga che decide se il filtro finisce in un WHERE nel database o in memoria dopo aver scaricato 200.000 record.
  • Split query. Quando spezzare gli Include elimina la moltiplicazione cartesiana e quando invece peggiora.
  • Query compilate. Precompilare una volta ed eseguire migliaia di volte, sui percorsi ad alta frequenza.
  • Tag delle query. Un'etichetta leggibile nel SQL per ritrovare subito nei log la query colpevole.
Strumenti e tecniche
Query loggingSelect projectionIQueryableSplit queryCompiled queryQuery tags
Cosa ottieni
  • Leggi il SQL generato come se lo avessi scritto tu, nessun mistero sotto il cofano
  • Letture rapide dove la linea non può aspettare
  • La sincronizzazione delle quattro entità sotto controllo
03Modulo 3

In produzione, coi dati veri, una pagina fa 500 query al posto di una, e ve ne accorgete dal cliente

Il bug di performance più comune di EF lo rendiamo visibile prima degli utenti. Include mirati, caricamento esplicito, split query e interceptor che segnalano ogni query oltre soglia, pagina per pagina.

Cosa mettiamo in sicurezza
  • Include e ThenInclude. Caricare le relazioni in un'unica query, navigando più livelli senza far esplodere i comandi.
  • Caricamento esplicito. Tirare su una relazione solo quando serve davvero.
  • Lazy loading. Come funziona con i proxy, e perché in quasi tutti gli scenari enterprise nasconde centinaia di query.
  • AsSplitQuery contro query singola. I compromessi tra righe duplicate in rete e viaggi in più verso il database.
  • Interceptor di monitoraggio. Registrare ogni query oltre una soglia, e vederle dai log prima degli utenti.
  • MiniProfiler integrato. Pagina per pagina, quante query girano e quanto durano.
Strumenti e tecniche
Include / ThenIncludeExplicit loadingLazy loadingAsSplitQueryInterceptorMiniProfiler
Cosa ottieni
  • Zero query nascoste che ammazzano la linea in silenzio
  • Performance prevedibili quando i volumi diventano quelli veri
  • I problemi visti dai log, non dagli utenti
04Modulo 4

Due branch, due migrazioni in conflitto, e il sabato sera si chiude con un rollback di emergenza in produzione

Diamo al team una strategia di migrazione che regge i merge: seeding, migration bundle, script idempotenti e controllo del drift. Aggiornare lo schema di macchine già installate smette di far paura.

Cosa mettiamo in sicurezza
  • Strategia di migrazione per il team. Chi le genera e come si integrano al merge, senza conflitti tra branch.
  • Popolamento dei dati iniziali. HasData per i lookup stabili, seeding in codice per i dati con logica.
  • Migration bundle. Le migrazioni in un eseguibile autonomo, senza tool EF sul server di produzione.
  • Rollback e migrazioni idempotenti. Script applicabili due volte senza danni.
  • Ambienti multipli. Differenze tra sviluppo, staging e produzione gestite in modo controllato.
  • Confronto degli schemi e drift. Accorgersi che la produzione si è allontanata dal modello prima che una migrazione fallisca a metà.
Strumenti e tecniche
Strategia teamHasData / seedingMigration bundleMigrazioni idempotentiAmbienti multipliDrift detection
Cosa ottieni
  • Il deploy del database diventa un evento noioso, non un rischio
  • Aggiornare lo schema di macchine già installate senza sorprese
  • Rollback sempre possibile
Fase 2 Architettura e scenari critici · settimane 5-8
05Modulo 5

Un Repository applicato per abitudine diventa un layer che ripete Entity Framework e non serve a niente

Sul vostro codice decidiamo quando un pattern porta valore e quando è peso morto. Repository, Specification, CQRS ed eventi di dominio, ognuno con la sua motivazione, difendibile davanti all'ente di omologazione.

Cosa mettiamo in sicurezza
  • Pattern Repository. Quando aggiunge valore reale e quando è solo un wrapper che ripete l'API di EF.
  • Unit of Work già nel DbContext. Come EF lo implementa, e perché reimplementarlo introduce bug sottili.
  • Pattern Specification. Query riutilizzabili e componibili, senza far uscire IQueryable dal data layer.
  • CQRS con EF Core. Un modello di lettura a proiezioni e uno di scrittura sul change tracker.
  • Eventi di dominio con MediatR. Pubblicati solo dopo che la transazione è confermata.
  • Più DbContext per bounded context. Confini netti tra i moduli.
Strumenti e tecniche
RepositoryUnit of WorkSpecificationCQRSDomain events / MediatRMulti DbContext
Cosa ottieni
  • Un'architettura dati chiara e testabile, senza layer inutili
  • Ogni scelta motivata, e per questo difendibile in omologazione
  • Niente pattern applicati per abitudine
06Modulo 6

Due bilance salvano lo stesso record nello stesso istante, una vince e l'altra perde i dati senza saperlo

Il vostro scenario multi-device lo chiudiamo con concorrenza ottimistica, risoluzione dei conflitti, livelli di isolamento e pattern Outbox. I dati smettono di sparire, e la codebase lo dimostra all'ente.

Cosa mettiamo in sicurezza
  • Concorrenza ottimistica con RowVersion. EF solleva un'eccezione invece di sovrascrivere in silenzio.
  • Risoluzione dei conflitti. Far prevalere client o server, deciso a monte e non lasciato al caso.
  • Ambito transazionale e livelli di isolamento. Serializable contro Read Committed, tra deadlock e letture sporche.
  • Pattern Outbox. Un evento pubblicato solo se la transazione va a buon fine, senza messaggi persi o duplicati.
  • Idempotenza. Operazioni che, richiamate dieci volte, fanno l'effetto di una sola.
  • Transazioni distribuite. Perché evitarle quasi sempre e cosa usare al loro posto.
Strumenti e tecniche
RowVersionConflict resolutionIsolation levelsOutboxIdempotenzaRetry
Cosa ottieni
  • Più terminali e più bilance sullo stesso dato senza perdite invisibili
  • Conflitti gestiti secondo una politica decisa, non il caso
  • La codebase che lo dimostra all'ente di omologazione
07Modulo 7

Test tutti verdi che poi si rompono in produzione, perché nessuno stava testando davvero contro il database

Costruiamo la rete di sicurezza vera: SQLite in memoria, TestContainers con un MariaDB reale, builder di dati leggibili e test di performance sulle query critiche. Le regressioni le prendete prima dell'omologazione.

Cosa mettiamo in sicurezza
  • Provider InMemory. Cosa verifica davvero e cosa lascia passare fino al SQL di produzione.
  • SQLite in memoria. Avvicinarsi al database reale con overhead minimo, e dove restano le differenze.
  • TestContainers. Un vero MariaDB in Docker per i test di integrazione, usa e getta.
  • Costruttori di dati di test. Oggetti complessi in modo leggibile, senza factory da venti parametri.
  • Test di integrazione con WebApplicationFactory. L'intera pipeline, database reale incluso, in dieci righe.
  • Test di performance sulle query critiche. Intercettare le regressioni prima degli utenti.
Strumenti e tecniche
InMemory providerSQLite in-memoryTestContainersTest data builderWebApplicationFactoryPerformance test
Cosa ottieni
  • Le regressioni sul database le trovate nei test, non a macchina avviata
  • Un data layer coperto da test che trovano i bug veri
  • La rete di sicurezza che serve prima dell'omologazione
08Modulo 8

Arriva il bulk da 10.000 record o la stored procedure legacy, ed Entity Framework da solo vi lascia a piedi

Per il 10% dei casi dove EF non basta vi diamo gli strumenti senza smontare l'architettura: FromSql, procedure tipizzate, bulk insert, interceptor e AsNoTracking. Sapete quando uscire da EF e come rientrarci.

Cosa mettiamo in sicurezza
  • FromSql, SqlQuery ed ExecuteSql. SQL a mano mantenendo change tracker e type safety.
  • Stored procedure e funzioni. Richiamate in modo tipizzato, riusando la logica già nel database.
  • Bulk insert e update. 10.000 record in un paio di secondi, non nei minuti di SaveChanges.
  • Interceptor per audit trail e soft delete. Comportamenti trasversali senza toccare il codice applicativo.
  • Diagnostica del change tracker. AsNoTracking per le letture, meno overhead sulle query pesanti.
  • Provider per database a documenti. EF su NoSQL con lo stesso modello, e dove il paradigma cambia le regole.
Strumenti e tecniche
FromSql / ExecuteSqlStored procedureBulkExtensionsInterceptor auditAsNoTrackingNoSQL provider
Cosa ottieni
  • Mai bloccati da un limite di EF
  • Scritture massive da 10.000 record in secondi
  • Sapete quando uscire da EF e come farlo, sulle linee automatiche ad alta velocità

"Perché non lo facciamo con i nostri?"

Domanda giusta. Avete dieci sviluppatori e sono capaci. Il problema non sono le persone.

Un team interno vede il proprio sistema, e lo vede bene. Quello che non può avere è il confronto: decine di altri data layer visti rompersi negli stessi punti, sotto gli stessi carichi. Un architetto esterno non è più bravo dei vostri. Ha solo visto sbagliare più volte, e sa dove si rompono le cose prima che si rompano.

Per nove mesi quel confronto ce l'hanno accanto. Poi resta a loro.

09b / Il conto vero

Una decisione architetturale sbagliata non si paga una volta. Si paga a ogni macchina

Il termine di paragone non è un corso. È quello che costa scoprire tardi, su un sistema omologato che deve durare vent'anni, che la fondazione andava rivista. Facciamo il conto insieme, coi vostri numeri.

Dieci sviluppatori fermi tre settimane a rimettere mano alla fondazione150 giorni-uomo × 350 € di costo pieno

52.500 €

Le macchine già assemblate da rivedere e ricollaudare una per unaore di rework e fermo linea

da 15.000 €

Il fascicolo tecnico da riscrivere per l'omologazionecirca 15 giorni-persona

5.000 €

Il ritardo sui prodotti già a listinosettimane di mancato time-to-market

difficile da stimare
Oltre 70.000 € per una sola decisione sbagliata.E non è una tantum. Se la scoprite dopo l'omologazione o con le macchine già sul campo, il conto è quello di un trimestre di sviluppo dell'intero team: oltre 200.000 €. La stessa scelta si ripaga a ogni nuova macchina che la eredita.

Stima a costo pieno di 350 € al giorno per sviluppatore, da tarare sui vostri numeri. Serve l'ordine di grandezza, non la cifra al centesimo.

Quanto costa correggere la stessa decisione, a seconda di quando la scopri
Scala illustrativa. Più tardi arriva la correzione, più lavoro è già stato costruito sopra la scelta sbagliata.
1×
Validare
adesso
5×
Rifare
fra 6 mesi
15×
In fase di
omologazione
30×+
Macchine
installate

Validare adesso costa una frazione del primo errore che evita. Il resto del conto lo avete appena visto.

10 / Le due offerte

Due modi per mettere sotto controllo l'architettura Entity Framework

Lo stesso metodo, sullo stesso codice. Cambia solo quanto lontano andate: una diagnosi netta con l'Architecture Sprint, oppure il Percorso Completo che accompagna il team fino all'autonomia.

Primo passo

Architecture Sprint

In poche settimane, una risposta netta: la direzione regge o si corregge adesso. Senza fermare una riga di sviluppo.

  • Assessment dell'architettura dati sul codice reale
  • Revisione di DbContext, concorrenza e SQL generato
  • Registro delle decisioni e matrice dei rischi
  • Piano d'azione prioritizzato per il team

Uscite con: una risposta chiara sulla direzione e un documento da portare in riunione.

Raccomandato per Coop Bilanciai
Fino in fondo

Percorso Completo · 9 mesi

L'architettura sotto controllo e il team autonomo, proprio quando arrivano i problemi veri.

  • Tutto l'Architecture Sprint, come punto di partenza
  • Sessioni da due ore ogni due settimane, sul vostro codice
  • Vi accompagna su migrazioni, concorrenza e carico reali
  • Trasferimento di competenze fino all'autonomia del team
  • Documentazione finale pronta per l'omologazione
Mese 1 validazione della base Mesi 2-4 prime migrazioni Mesi 5-7 carico e concorrenza Mesi 8-9 autonomia del team

Uscite con: l'architettura sotto controllo e un team che non ha più bisogno di noi.

Modalità costruita sulla vostra: uno sprint iniziale, poi sessioni remote ogni due settimane, senza fermare l'operatività. Investimento e durata li definiamo insieme nella proposta, sul contenuto che serve davvero.

Tre impegni, messi per iscritto prima di iniziare

Non promesse di marketing. Sono le condizioni con cui lavoro, valide dalla prima sessione.

Sempre Matteo, mai un sostituto

Il percorso lo seguo io di persona, dalla prima all'ultima sessione. Niente junior, niente delega, niente docenti intercambiabili. Chi ha ventisei anni di esperienza è chi si siede al tavolo con voi.

Riservatezza assoluta, firmata

Prima di vedere una riga del vostro codice firmiamo un accordo di riservatezza. Architettura, dati e know-how restano vostri e riservati, durante e dopo il percorso. Su un prodotto che va in omologazione, non è un dettaglio.

Tutto documentato, tutto vostro

Ogni decisione presa insieme viene messa per iscritto, motivata e datata. Quel documento è vostro e resta vostro, anche se decidete di fermarvi prima. Nessun lock-in: l'obiettivo è che il team decida da solo.

11 / Il confronto giusto

L'assicurazione più economica che possiate stipulare su vent'anni di prodotto

Immaginate di scoprirlo all'ottavo mese.

Il codice è ormai ovunque. Le prime macchine sono in assemblaggio. Il fascicolo tecnico per l'omologazione è già in scrittura. E proprio lì vi accorgete che un modo di leggere i dati sotto carico, deciso mesi prima quasi senza pensarci, non regge quando la linea va davvero a 200 pezzi al minuto.

A quel punto non cambiate una riga. Smontate un pezzo di fondazione mentre il palazzo è già in piedi. Dieci persone si fermano e rimettono mano a quello che credevano finito. Le macchine già montate vanno riviste. Quello che era certificato va ricontrollato. E ogni settimana che passa, quel debito costa un po' di più, perché nel frattempo ci avete costruito sopra.

Oggi è una riga da cambiare. Tra otto mesi è un cantiere da riaprire.

Ecco perché metterlo nella casella della formazione è fuorviante. Quella è una spesa che si preventiva a inizio anno. Questo vi evita la spesa vera, quella che non entra in nessun budget perché arriva quando non ve la aspettate. Validare adesso significa investire una frazione di quel rischio, mentre correggere è ancora una decisione e non un intervento a macchine ferme.

Un sistema pensato per durare vent'anni merita di partire da fondamenta verificate. Il numero esatto lo calcolate voi, con i vostri costi. Ma il vero termine di paragone, ormai, lo conoscete.

Macro luminosa di un componente di pesatura industriale di alta precisione perfettamente installato

Il prossimo passo è concreto

Partiamo dall'Architecture Sprint e vediamo dove regge

Una sessione operativa per fissare perimetro, accessi e primo sprint sulla vostra architettura. Gli argomenti sono già chiari: resta da decidere modalità e durata.

Rivedi le due offerte