Gli approcci a cascata: non c’è un prima e un dopo
Poche settimane fa è arrivata una richiesta da un potenziale cliente. Una importante società europea nel gas naturale, ci chiedeva di inviare un’offerta per la realizzazione di un sistema per l’ottimizzazione del loro portafoglio gas. Il processo delineato prevedeva due fasi ben distinte:
- scrivere un modello matematico che descriva il problema da risolvere;
- implementare una soluzione software funzionante che risolva il problema.
Questo processo è talmente semplice da delineare, che già altre volte mi è capitato di essere tra quelli che hanno lavorato all'implementazione di un modello che qualcun’altro aveva scritto su carta.
Tutte le volte che questo è accaduto, si è sempre verificato che il comportamento atteso era diverso da quello ottenuto. Mi spiego con un esempio reale e pertinente all’ottimizzazione di un portafoglio gas.
Avevamo appena modellato gli stoccaggi del gas, che permettono di modulare l’approvvigionamento praticamente costante giorno per giorno, con il consumo che ha delle forti stagionalità. I primi risultati che si ottenevano, mostravano un comportamento strano e non atteso: gli stoccaggi si svuotavano alla fine dell’orizzonte di ottimizzazione.
— “Perché gli stoccaggi si svuotano?”
— “Perché così il costo di approvvigionamento è minimo.”
— “Ma uno stoccaggio non si può svuotare”
— “Allora dobbiamo aggiungere un vincolo che lo vieti”
Gli approcci a cascata sono semplici da delineare, ma si portano dentro delle fonti di fallimento. Questo il mio suggerimento al potenziale cliente:
[…] in order to increase the success probability of the project, I really suggest you focus your attention on working models rather than on written models.
Write and test even small portions of the biggest model. In this way, you will write a model that suit your needs.
