Il punto di partenza.
L’ERP web operativo era un monolite su SQL Server, C# e .NET Framework 4.8, Entity Framework, KnockoutJS, JavaScript, jQuery, Bootstrap e Crystal Reports. L’affidabilità era un requisito di prodotto, non una nota di manutenzione.
Il database non aveva un sistema di migrations e non apparteneva soltanto all’applicazione web. Un ERP desktop e un’applicazione cassa VB6 molto più vecchi usavano lo stesso schema, quindi una modifica corretta nel percorso web poteva comunque interrompere il lavoro quotidiano altrove.
Il perimetro comprendeva feature, bug, stored procedure e view, reporting, due integrazioni con corrieri, requisiti, formazione e supporto. Il contatto diretto con il cliente era cruciale per capire l’uso reale del software prima di modificarlo.
Cosa doveva rispettare il lavoro.
Il sistema poteva evolvere soltanto se i percorsi operativi vecchi e nuovi continuavano a concordare:
- I flussi esistenti dovevano continuare a sostenere il lavoro retail quotidiano.
- Le modifiche allo schema SQL Server dovevano essere retrocompatibili perché non esisteva uno storico di migrations capace di coordinare ogni consumer.
- L’ERP web .NET Framework e le vecchie applicazioni desktop e cassa VB6 condividevano lo stesso contratto dati.
- KnockoutJS, jQuery, regole backend e comportamento del database dovevano cambiare insieme quando cambiava il flusso web.
- I requisiti dovevano essere verificati con il cliente in termini operativi prima di diventare codice, report o comportamento d’integrazione.
- Due integrazioni esterne con corrieri dovevano restare comprensibili al confine del sistema.
La diagnosi.
In un ERP a più livelli, il ritardo o l’errore visibile è spesso l’ultimo anello. Una schermata può essere lenta per la forma della richiesta, il lavoro backend o l’accesso al database. Un problema d’integrazione può apparire come incoerenza frontend.
Il database condiviso cambiava la definizione abituale di dettaglio interno. Tabelle, colonne e stored procedure erano anche contratti con software VB6 che non poteva seguire una moderna sequenza di migrations.
Ho unito il tracing end-to-end alle conversazioni dirette con il cliente. Query e stored procedure SQL Server, regole .NET Framework, schermate KnockoutJS e jQuery, report, scambi con i corrieri e percorso desktop legacy erano parti dello stesso comportamento operativo.
La vista utile del sistema.
L’unità utile di cambiamento era l’intero contratto operativo: un’azione nell’interfaccia web KnockoutJS e jQuery, regole .NET Framework 4.8, lavoro sullo schema SQL Server condiviso e i vecchi percorsi desktop e cassa VB6 dipendenti dagli stessi record. Report e corrieri aggiungevano altri confini attorno a quel nucleo.
Perché la continuità era una scelta architetturale.
Era l’evoluzione di un ERP operativo, non un’approvazione greenfield del suo stack. La scelta tecnologica corretta consisteva spesso nel preservare un contratto di lavoro e migliorarlo sul posto, invece di rendere nuovo ogni livello nello stesso momento.
Conservare C#/.NET Framework e KnockoutJS per cambiamenti incrementali
- Perché
- Funzionalità, difetti e flussi quotidiani attraversavano già questi livelli. Lavorare al loro interno permetteva di seguire ogni richiesta lungo il percorso reale e rilasciarla senza sospendere l’operatività.
- Cosa ho escluso
- Una riscrittura in un unico passaggio di backend e frontend avrebbe richiesto di riscoprire e sostituire il comportamento esistente prima di consegnare miglioramenti operativi più piccoli.
- Quanto è costata
- Il lavoro accetta i vincoli dei framework meno recenti, modelli frontend misti e competenze di manutenzione continuative invece di ottenere subito una base moderna e uniforme.
Trattare SQL Server come contratto dati condiviso
- Perché
- ERP web, ERP desktop VB6 e applicazione cassa leggevano e scrivevano lo stesso schema. Modifiche SQL compatibili proteggevano applicazioni che non potevano avanzare con ogni release web.
- Cosa ho escluso
- Migrare database o schema insieme al lavoro web avrebbe presupposto un passaggio simultaneo di tutte le applicazioni, nonostante l’assenza di un sistema di migrazione.
- Quanto è costata
- Modifiche additive e strutture transitorie possono restare più a lungo; il design del database deve considerare letture e scritture vecchie oltre al nuovo percorso.
Far evolvere Crystal Reports e i percorsi di reporting esistenti
- Perché
- Il reporting faceva già parte del sistema operativo e del suo comportamento su SQL Server. Mantenerlo nel perimetro permetteva di verificare i cambiamenti con lo stesso contratto dati e applicativo.
- Cosa ho escluso
- Introdurre nello stesso momento una nuova piattaforma di reporting avrebbe aggiunto un’altra migrazione e imposto di tradurre il comportamento dei report mentre applicazione e database stavano ancora cambiando.
- Quanto è costata
- La soluzione conserva strumenti di reporting storici e i loro vincoli di progettazione; le modifiche continuano a richiedere competenze specifiche e verifiche tra più livelli.
Consegnare un workflow end-to-end alla volta
- Perché
- Una modifica poteva attraversare schermata operatore, regole .NET, comportamento SQL e, quando coinvolti, report, integrazioni e applicazioni preesistenti come un’unica sezione operativa coerente.
- Cosa ho escluso
- Modernizzare un livello tecnico alla volta avrebbe diviso il comportamento tra percorsi vecchi e nuovi, rimandando la prova del workflow reale fino al completamento di più migrazioni.
- Quanto è costata
- Ogni sezione deve essere completata e verificata in tutti i livelli e le applicazioni che tocca; il progresso richiede quindi confini rigorosi invece dell’uniformità visiva di un programma per livelli.
Regole per cambiare un sistema in uso.
La continuità dello stack definiva il perimetro; queste regole hanno mantenuto ogni modifica collegata all’intero percorso operativo e alle persone che lo utilizzano.
Seguire tutta la richiesta
Il lavoro su performance e affidabilità parte da un comportamento che cliente o operatore riescono a descrivere, poi lo segue attraverso stato web, regole backend e lavoro sul database invece di fermarsi al primo sintomo visibile.
Il compromessoRichiede più indagine di una patch al primo componente lento, ma evita di spostare il collo di bottiglia o risolvere un sintomo che il cliente non aveva davvero.
Rendere la compatibilità un criterio di accettazione
Una modifica viene accettata soltanto dopo aver funzionato nel gestionale web e nei percorsi desktop e cassa che condividono gli stessi dati. Stored procedure, viste, report e scambi con i corrieri entrano nella verifica quando il workflow li attraversa.
Il compromessoLa superficie di accettazione è più ampia del componente modificato, ma un successo locale non può trasformarsi in silenzio in un guasto su un altro percorso quotidiano.
Definire il completamento nel workflow reale del cliente
Le conversazioni con il cliente traducono una richiesta in workflow concreti, casi limite e verifiche di accettazione prima della modifica. La consegna è completa soltanto quando il comportamento risultante si ricollega all’uso quotidiano, non quando un singolo componente funziona in isolamento.
Il compromessoQuesta definizione del completamento richiede tempo di coordinamento, ma costa meno che consegnare un’interpretazione tecnicamente coerente e inadatta al processo retail reale.
Usare supporto e formazione come feedback di rilascio
Le domande emerse durante supporto e formazione mantengono i requisiti legati al modo in cui le persone comprendono e svolgono il lavoro. Quel feedback orienta la successiva correzione o evoluzione circoscritta.
Il compromessoLa responsabilità della consegna continua oltre il merge del codice, ma le difficoltà d’uso diventano visibili mentre possono ancora guidare il rilascio seguente.
Delivery e verifica.
Ogni modifica veniva verificata nel proprio livello e nel flusso operativo: stored procedure e view, regole .NET, risposte dei corrieri, Crystal Reports e stato KnockoutJS dovevano concordare.
Il lavoro sul database richiedeva anche una domanda di compatibilità: cosa leggeranno o scriveranno l’ERP e la cassa VB6 dopo questa modifica? Senza migrations, la risposta doveva stare nel design e non poteva essere rimandata all’automazione del rollout.
Il feedback diretto del cliente completava la verifica dei percorsi quotidiani. Una modifica tecnicamente corretta non era finita se rendeva il lavoro abituale più difficile da capire o non corrispondeva più all’operatività descritta da chi usava il sistema.
Il risultato qualitativo.
Il risultato documentato non è stato un unico lancio di modernizzazione, ma una serie di modifiche circoscritte a funzionalità e difetti applicativi, procedure e viste SQL Server, Crystal Reports, due integrazioni con corrieri e flussi di ricezione della merce.
Ogni modifica è stata verificata sul percorso web e, quando toccava record condivisi, sul contratto dati usato dall’ERP desktop VB6 e dall’applicazione di cassa. In questo modo l’ERP web ha potuto evolvere senza trattare lo schema condiviso come se avesse un solo consumatore.
Questo case study non dichiara un aumento misurato di performance o affidabilità. Documenta il metodo di delivery usato sul sistema in esercizio: ricostruire il flusso con il cliente, definire la compatibilità ai confini interessati e verificare l’intera modifica prima di considerarla conclusa.
Organizzazione, prodotto, utenti, fornitori, dati commerciali, KPI e date di consegna sono omessi. Tecnologie e confini delle integrazioni derivano dal record di progetto.