Simulazione ad agenti e sistemi complessi

Transcript

UNIVERSITÀ DEGLI STUDI DI TORINO
Facoltà di Economia
Corso di Laurea in Economia e Commercio
Tesi di Laurea in Economia Matematica
Simulazione ad agenti
e sistemi complessi.
Applicazione al caso BasicNet
Relatore:
Prof. Pietro TERNA
Correlatore:
Prof. Sergio MARGARITA
Candidato:
Roberto CROSETTO
ANNO ACCADEMICO 2003-2004
Desidero ringraziare il prof. Pietro Terna, mio relatore, e la dr.ssa Paola
Bruschi, sempre pronta a rispondere ad ogni mio dubbio.
Un particolare ringraziamento va ai miei genitori e ad Adriana.
Indice
Introduzione
1
1 Complessità e simulazione
5
1.1
La complessità
. . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2
I sistemi complessi . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3
Un modello per la realtà: il formicaio . . . . . . . . . . . . . . 10
1.3.1
Le formiche . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2
Applicazioni alla realtà . . . . . . . . . . . . . . . . . . 12
1.4
Complessità e ordine spontaneo . . . . . . . . . . . . . . . . . 14
1.5
La vita artificiale . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1
Genotipo e fenotipo . . . . . . . . . . . . . . . . . . . . 17
1.5.2
Gli algoritmi genetici . . . . . . . . . . . . . . . . . . . 18
1.6
La simulazione e le scienze sociali . . . . . . . . . . . . . . . . 19
1.7
Lo sviluppo di una simulazione . . . . . . . . . . . . . . . . . 22
1.8
I vantaggi della simulazione . . . . . . . . . . . . . . . . . . . 25
1.9
I problemi della simulazione . . . . . . . . . . . . . . . . . . . 26
1.10 L’interpretazione dei modelli . . . . . . . . . . . . . . . . . . . 27
1.11 Gli agenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2 Gli strumenti per la simulazione
2.1
32
Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.1
Sviluppo di una simulazione . . . . . . . . . . . . . . . 34
I
INDICE
2.2
2.3
II
2.1.2
Caratteristiche principali . . . . . . . . . . . . . . . . . 36
2.1.3
Le ‘‘sonde’’ . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1.4
Le librerie di Swarm . . . . . . . . . . . . . . . . . . . 39
NetLogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.1
Caratteristiche principali . . . . . . . . . . . . . . . . . 41
2.2.2
Obiettivi futuri . . . . . . . . . . . . . . . . . . . . . . 42
RePast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.1
Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.2
Caratteristiche della simulazione . . . . . . . . . . . . . 44
2.3.3
Le librerie . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3.4
Progetti futuri . . . . . . . . . . . . . . . . . . . . . . . 46
3 Impresa, imprenditore e conoscenza
47
3.1
La teoria neoclassica . . . . . . . . . . . . . . . . . . . . . . . 48
3.2
La Scuola Austriaca
. . . . . . . . . . . . . . . . . . . . . . . 50
3.2.1
L’attività imprenditoriale
. . . . . . . . . . . . . . . . 53
3.2.2
La competizione . . . . . . . . . . . . . . . . . . . . . . 55
3.3
L’imprenditore di Kirzner . . . . . . . . . . . . . . . . . . . . 55
3.4
Simon e la razionalità limitata . . . . . . . . . . . . . . . . . . 57
3.4.1
La razionalità procedurale . . . . . . . . . . . . . . . . 59
3.4.2
Il processo di scelta . . . . . . . . . . . . . . . . . . . . 60
4 jES: java Enterprise Simulator
61
4.1
Introduzione all’uso del simulatore . . . . . . . . . . . . . . . . 62
4.2
Lo schema ERA . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3
Applicazioni a casi aziendali . . . . . . . . . . . . . . . . . . . 65
4.4
Il primo formalismo: le cose da fare . . . . . . . . . . . . . . . 66
4.4.1
Le ricette . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.2
I layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
INDICE
4.5
III
4.4.3
I batch . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4.4
I procurement . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.5
Il processo OR . . . . . . . . . . . . . . . . . . . . . . 69
Il secondo formalismo: chi fa cosa . . . . . . . . . . . . . . . . 70
4.5.1
Le unità produttive . . . . . . . . . . . . . . . . . . . . 70
4.5.2
Le endUnit . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.3
La scelta delle unità . . . . . . . . . . . . . . . . . . . 72
4.5.4
La trasmissione delle informazioni . . . . . . . . . . . . 72
4.6
Il terzo formalismo: quando fare cosa . . . . . . . . . . . . . . 73
4.7
Le capacità computazionali . . . . . . . . . . . . . . . . . . . . 74
4.8
4.9
4.7.1
Un semplice esempio . . . . . . . . . . . . . . . . . . . 76
4.7.2
La matrice orMemoryMatrix . . . . . . . . . . . . . . . 77
4.7.3
Le ricette che lanciano ricette . . . . . . . . . . . . . . 77
Le capacità contabili . . . . . . . . . . . . . . . . . . . . . . . 79
4.8.1
I costi . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.8.2
I ricavi . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.8.3
L’utile . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Lanciare una simulazione . . . . . . . . . . . . . . . . . . . . . 81
4.9.1
I grafici di una simulazione . . . . . . . . . . . . . . . . 82
5 L’azienda reale: BasicNet
86
5.1
La storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2
Il business system . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3
La struttura del Gruppo . . . . . . . . . . . . . . . . . . . . . 92
5.4
Le divisioni dot.com
5.5
Il ciclo di produzione . . . . . . . . . . . . . . . . . . . . . . . 96
5.6
Le attività di promozione . . . . . . . . . . . . . . . . . . . . . 97
. . . . . . . . . . . . . . . . . . . . . . . 94
INDICE
IV
6 L’azienda virtuale: Basic_jES
99
6.1
Prima analisi e possibili sviluppi . . . . . . . . . . . . . . . . . 99
6.2
Novità nell’azienda . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3
Le modifiche al modello precedente . . . . . . . . . . . . . . . 102
6.4
Analisi del calendario . . . . . . . . . . . . . . . . . . . . . . . 104
6.4.1
La time-table di BasicNet . . . . . . . . . . . . . . . . 104
6.4.2
Il calendario di Basic_jES . . . . . . . . . . . . . . . . 108
6.5
Le ricette produttive . . . . . . . . . . . . . . . . . . . . . . . 109
6.6
Le memoryMatrixes . . . . . . . . . . . . . . . . . . . . . . . . 110
6.7
Le modifiche al codice . . . . . . . . . . . . . . . . . . . . . . 111
6.8
Analisi di diversi business system . . . . . . . . . . . . . . . . 115
6.9
Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.9.1
Le unità produttive . . . . . . . . . . . . . . . . . . . . 116
6.9.2
Le nuove ricette . . . . . . . . . . . . . . . . . . . . . . 120
6.9.3
Il calendario . . . . . . . . . . . . . . . . . . . . . . . . 121
6.9.4
Le modifiche al codice . . . . . . . . . . . . . . . . . . 122
6.9.5
I parametri della simulazione
. . . . . . . . . . . . . . 126
6.10 Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.10.1 Le modifiche al modello . . . . . . . . . . . . . . . . . 129
6.10.2 I costi delle unità produttive . . . . . . . . . . . . . . . 132
6.10.3 I ricavi aziendali . . . . . . . . . . . . . . . . . . . . . 134
6.10.4 Le modifiche al codice . . . . . . . . . . . . . . . . . . 136
6.10.5 I parametri della simulazione
. . . . . . . . . . . . . . 138
6.11 Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.11.1 Le modifiche al modello . . . . . . . . . . . . . . . . . 140
6.11.2 Le modifiche al codice . . . . . . . . . . . . . . . . . . 141
6.11.3 I parametri della simulazione
. . . . . . . . . . . . . . 141
6.12 Risultati della simulazione . . . . . . . . . . . . . . . . . . . . 142
INDICE
V
6.13 Considerazioni sui risultati . . . . . . . . . . . . . . . . . . . . 148
6.14 Focus sui licenziatari . . . . . . . . . . . . . . . . . . . . . . . 150
6.14.1 Licenziatari con tempo 1 . . . . . . . . . . . . . . . . . 150
6.14.2 Licenziatari con tempo 0 . . . . . . . . . . . . . . . . . 153
6.15 Approfondimento di BasicSamples . . . . . . . . . . . . . . . . 154
6.16 Analisi finale . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.16.1 Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.16.2 Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.16.3 Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Appendice
165
Bibliografia
202
Elenco delle tabelle
4.1
Esempio di ricetta produttiva . . . . . . . . . . . . . . . . . . 66
4.2
Sequential batch
4.3
Stand alone batch e indicazione dell’endUnit . . . . . . . . . . 68
4.4
Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5
Processo or . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6
recipeData/orderSequence.xls . . . . . . . . . . . . . . . . . . . 74
4.7
Uso di passi computazionali . . . . . . . . . . . . . . . . . . . 75
4.8
Ricette che lanciano ricette . . . . . . . . . . . . . . . . . . . . 79
6.1
Successione delle fasi per una collezione . . . . . . . . . . . . . 107
6.2
Suddivisione delle royalties . . . . . . . . . . . . . . . . . . . . 117
6.3
Costi fissi delle divisioni dot.com (in euro) . . . . . . . . . . . 120
6.4
Articoli creati ed effettivamente prodotti per ogni collezione . 146
6.5
File log/grossSales
. . . . . . . . . . . . . . . . . . . . . . . . . 68
. . . . . . . . . . . . . . . . . . . . . . . . 158
VI
Elenco delle figure
2.1
Logo di SWARM . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2
Struttura di una simulazione . . . . . . . . . . . . . . . . . . . 36
2.3
Esempi di sonde . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4
Logo di NetLogo . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5
Logo di RePast . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1
Interazioni tra ordini e unità . . . . . . . . . . . . . . . . . . . 63
4.2
Lo schema ERA . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3
File unitData/unitBasicData.txt . . . . . . . . . . . . . . . . . 71
4.4
File unitData/memoryMatrixes.txt
4.5
Grafico dell’andamento delle liste d’attesa . . . . . . . . . . . 83
4.6
Andamento dell’utile durante la simulazione . . . . . . . . . . 83
4.7
Rapporto
4.8
Liste d’attesa delle unità dell’impresa virtuale . . . . . . . . . 84
4.9
Livello delle endUnit . . . . . . . . . . . . . . . . . . . . . . . 85
5.1
Rappresentazione del business system di BasicNet . . . . . . . 91
5.2
La struttura del Gruppo . . . . . . . . . . . . . . . . . . . . . 92
6.1
Costi variabili e fissi di BasicNet . . . . . . . . . . . . . . . . . 119
6.2
Ricette 900 e 950 . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.3
Ricetta 800 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
totaltime
totallenght
. . . . . . . . . . . . . . . 75
. . . . . . . . . . . . . . . . . . . . . . . . 84
VII
ELENCO DELLE FIGURE
VIII
6.4
Ricetta 900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.5
Ricetta 302 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.6
Primo esperimento.
6.7
Primo esperimento. Tempi d’attesa degli ordini . . . . . . . . 145
6.8
Secondo esperimento.
6.9
Secondo esperimento. Tempi d’attesa degli ordini . . . . . . . 149
6.10 Terzo esperimento.
T empodiesecuzione
T empoprevistodallericette
6.12 Sesto esperimento.
T empodiesecuzione
T empodiesecuzione
6.11 Quarto esperimento.
. . . . . . . . . . . . 145
. . . . . . . . . . . . . 150
T empodiesecuzione
T empodiesecuzione
. . . . . . . . . . . 148
. . . . . . . . . . . . 151
. . . . . . . . . . . . . 152
T empodiesecuzione
. . . . . . . . . . 153
6.13 Licenziatari con tempo 0. T empoprevistodallericette
6.14 Approfondimento di Basicsamples.
T empodiesecuzione
. . . . 156
6.15 Andamento di costi, ricavi e profitti totali (Caso 1) . . . . . . 159
6.16 Andamento di costi, ricavi e profitti giornalieri (Caso 1) . . . . 159
Introduzione
La simulazione ad agenti è uno strumento di grande utilità per lo studio dei
sistemi complessi legati agli esseri viventi. Con questa metodologia è possibile
creare un mondo virtuale all’interno del computer basato su agenti autonomi
che interagiscono tra loro e osservare i fenomeni emergenti, che spesso si
rivelano di una complessità straordinaria. Un sistema si dice complesso se
non è possibile analizzarlo scomponendolo nelle parti che lo costituiscono,
ma è necessario studiarlo nel suo insieme; un esempio è l’azienda, oggetto di
studio di questo lavoro.
In questa tesi si applica il metodo della simulazione al contesto di un’impresa reale, con l’obiettivo di ricreare tutte le sue componenti e di osservare
il loro funzionamento all’interno del computer. Il modello di simulazione è
stato costruito utilizzando jES, piattaforma utile per la simulazione di impresa sviluppata dal professor Pietro Terna, e l’azienda oggetto di studio è la
torinese BasicNet S.p.A., che opera nel settore dell’abbigliamento alla moda.
BasicNet ha un particolare modello di business secondo il quale non partecipa direttamente al processo produttivo, in quanto la produzione è delegata
ad imprese esterne, chiamate Sourcing Centers o Trading Company, e gli articoli sono venduti direttamente da queste ultime ai licenziatari, che hanno
il compito di commercializzare i prodotti presso il pubblico. Il ruolo principale di BasicNet consiste nella gestione del network, nella finanza strategica
e nell’attività di merketing e la principale fonte di ricavo è costituita dalle
1
INTRODUZIONE
royalties pagate dai licenziatari, pari al 10% dei loro acquisti, per i servizi
loro offerti.
La costruzione di questo modello è iniziata in Lamieri (2002) e Merlo
(2003a) e questa tesi ne rappresenta la continuazione, con l’obiettivo finale
di un raffronto tra tre possibili modelli organizzativi, illustrati qui di seguito,
che BasicNet potrebbe adottare.
Nel primo caso si rappresenta la BasicNet reale nel modo il più possibile
vicino alla realtà. Grazie alla disponibilità della dottoressa Paola Bruschi,
direttore generale dei sistemi informativi di BasicNet, è stata possibile la
realizzazione di un’azienda virtuale con una struttura, un calendario delle
attività e una configurazione dei costi e dei ricavi simili alla BasicNet reale.
Nel secondo caso si presenta un possibile modello organizzativo che BasicNet potrebbe adottare, cioè un’azienda di tipo tradizionale che produce
e vende direttamente i propri articoli. La differenza con il caso precedente è rappresentata da una diversa struttura dei costi, perché la produzione
avviene internamente, e una differente origine dei ricavi, che sono calcolati
applicando un margine di ricarico ai costi sostenuti dall’azienda.
Infine, si presenta una BasicNet ancora differente, che fa produrre in
outsourcing i propri prodotti e li vende ai licenziatari. Questo modello organizzativo è una ‘‘miscela” dei precedenti, perché la produzione è delegata ad
altri, come per la BasicNet reale, e la vendita è effettuata direttamente, come
nel caso precedente; perciò i costi totali non comprendono quelli relativi alla
produzione e i ricavi sono calcolati in base ad un mark-up.
Occorre ricordare che lo studio qui affrontato non ha l’obiettivo di fornire
risultati assoluti su quale potrebbe essere la miglior struttura organizzativa,
ma offre soltanto un’indicazione generale per le scelte aziendali che, per essere
utilizzata nella realtà, dovrebbe essere affiancata da altri tipi di valutazione.
Il motivo principale è che con la simulazione ad agenti non è possibile ‘‘cat-
2
INTRODUZIONE
turare” e rappresentare tutti gli elementi di incertezza del mondo reale.
La tesi è composta di sei capitoli che, partendo dai concetti generali,
aiutano a comprendere le ragioni dell’utilizzo della simulazione ad agenti e
come costruire modelli di simulazione.
Nel primo capitolo si presenta una trattazione sulla teoria della complessità e sui modi con cui è possibile studiare i comportamenti individuali e
globali all’interno dei sistemi. In seguito si descrive la simulazione ad agenti
e il suo ruolo nello studio dei fenomeni complessi.
Nel secondo capitolo si effettua una breve presentazione di alcuni strumenti che possono essere usati per realizzare una simulazione ad agenti. In
particolare sono presentati Swarm, un protocollo di programmazione con
il quale è possibile creare modelli di simulazione utilizzabili per lo studio
di fenomeni complessi di ogni genere, NetLogo e RePast, altri ambienti di
simulazione.
Nel terzo capitolo è presentata una rassegna della letteratura economica
a riguardo dell’impresa, riservando una particolare attenzione al modo in cui
è considerata la figura dell’imprenditore. Secondo la teoria neoclassica l’imprenditore è un semplice amministratore delle risorse interne e non ha alcuna
funzione creativa, compito che al contrario è evidenziato dagli esponenti della Scuola Austriaca, che lo immaginano come lo scopritore delle occasioni
di profitto presenti nel mercato. L’impostazione Austriaca è poi ripresa da
Israel M. Kirzner ed integrata con spunti di originalità. Infine, si presenta
la visione di Herbert A. Simon, che ha rivoluzionato la figura dell’imprenditore introducendo i principi della razionalità limitata e della decisione più
soddisfacente anziché della migliore.
Nel quarto capitolo si descrive il modello jES (java Enterprise Simulator ), basato su Swarm, con il quale è possibile effettuare delle simulazioni
3
INTRODUZIONE
di impresa. Con questa piattaforma è possibile creare delle imprese virtuali
all’interno del computer per osservare i fenomeni complessi che si creano nelle
realtà aziendali. jES inoltre può essere usato per scopi teorici per lo studio
della nascita e dell’evoluzione delle imprese.
In seguito, nel capitolo cinque, si descrive l’azienda oggetto di studio di
questa tesi, la BasicNet S.p.A., proprietaria di alcuni marchi di abbigliamento
come Kappa, Robe di Kappa, Jesus Jeans, K-Way e Superga.
Infine, nell’ultimo capitolo si descrivono le modifiche e le novità portate al
modello di BasicNet creato con jES in Lamieri (2002) e Merlo (2003a); le modifiche hanno avuto l’obiettivo di rendere il più possibile simile all’azienda
reale quella creata all’interno del computer. Inoltre sono illustrate la costruzione degli altri modelli di azienda descritti precedentemente e un’analisi
finale dei costi e dei ricavi in cui si confrontano i diversi modelli organizzativi.
4
Capitolo 1
Complessità e simulazione
1.1
La complessità
La complessità è un concetto che deriva principalmente dalla matematica e
dalla fisica e con il passare del tempo è stata oggetto di studio di altre discipline, come la biologia e le scienze sociali. Il suo carattere di multidisciplinarità
crea delle difficoltà nel momento in cui si voglia dare una definizione di questo concetto e la conseguenza principale è che non ne esiste una ampiamente
condivisa. Infatti nessuno dei tentativi, per ammissione stessa degli autori,
è in grado di spiegare in modo esaustivo ciò che gli economisti e i sociologi
intendono con questo concetto.
Una definizione generale può essere che ‘‘un sistema dinamico è complesso
se a livello endogeno non tende asintoticamente ad un punto fissato, ma
mostra comportamenti discontinui e può essere descritto come un insieme di
equazioni non lineari con elementi stocastici’’ (Rosser, 1999). Un secondo
tentativo di definizione si può trovare in Tinti (1998), dove la complessità è
definita come ‘‘lo studio interdisciplinare dei sistemi complessi adattivi e dei
fenomeni emergenti ad essi associati’’.
Infine, in Kilpatrick (2001) è illustrato il Santa Fe approach, vale a di-
5
1. COMPLESSITÀ E SIMULAZIONE
re la visione della complessità nella ricerca economica secondo gli studiosi
dell’Istituto degli Studi sulla Complessità di Santa Fe, che la considerano
caratterizzata da sei elementi chiave:
1. interazioni disperse tra agenti eterogenei che agiscono localmente;
2. nessun controllo centrale che può sfruttare tutte le opportunità e le
interazioni nell’economia;
3. organizzazioni gerarchiche che danno vita ad un groviglio di interazioni;
4. continuo adattamento e apprendimento degli agenti;
5. continue novità, ad esempio nuovi mercati, nuove tecnologie e nuovi
comportamenti;
6. dinamiche senza equilibrio.
Inoltre il mondo così immaginato è a razionalità limitata con aspettative non
razionali. Questa definizione di complessità è stata delineata precedentemente dai chimici e dai fisici delle Università di Bruxelles e Stuttgart, i quali
hanno svolto anche alcune applicazioni di carattere economico che hanno
influenzato in modo particolare l’attività dei ricercatori di Santa Fe.
La nascita del pensiero della complessità avviene alla fine degli anni Quaranta da parte degli studiosi di cibernetica e di teoria dell’informazione; con
il passare del tempo ad essi si sono aggiunti studiosi provenienti da diverse
discipline. Una delle caratteristiche più importanti della teoria della complessità è rappresentata dal fatto che essa contribuisce ad unire la filosofia e
la scienza, infatti a questi studi partecipano in egual misura filosofi, biologi,
psicologi, chimici ed informatici; alcuni parlano della complessità come di
una ‘‘terza cultura” (Tinti, 1998).
Inoltre è da sottolineare il ruolo assunto dal computer nello studio della
complessità, che è utilizzato come laboratorio in cui sperimentare i modelli
6
computazionali del sistema che si intende studiare ed osservare il suo comportamento; questo tipo di esperimento è detto simulazione, della quale si
parlerà in modo più approfondito nei prossimi paragrafi di questo capitolo.
Inizialmente la maggior parte dei lavori sulla complessità hanno riguardato modelli spaziali, caratterizzati dalla possibilità per gli agenti di interagire
tra loro in modo disperso; da questi modelli si può notare l’emergere di una
struttura globale a partire da fenomeni strettamente locali, caratteristica che
rappresenta l’idea principale della moderna teoria della complessità. Questo
concetto trova l’anticipatore in un lavoro di Schelling, in cui è stato creato un modello che riguarda la segregazione razziale nelle città e può essere
dimostrato senza l’uso del computer.
Schelling considered a rectangle with many sub-rectangles, each occupied by a black or a white. He allowed for movement based
on local interactions and discovered that even a very slight preference by members of either group for living with their own kind
would eventually lead to a largely segregated city, even though
agents were only acting in relation to their immediate neighbors.
(Rosser, 1999, 176)
Il modello di Schelling è stato imitato per lo studio di sistemi formati
da agenti eterogenei che formulano strategie in base alle interazioni con gli
altri agenti; un esempio è il punto di vista della vita artificiale sviluppato da
Langton (1992), che usa automi cellulari per rappresentare agenti economici
che interagiscono tra loro.
1.2
I sistemi complessi
Gran parte del mondo è composto da sistemi complessi adattivi, strutture in
cui le componenti sono fortemente dinamiche e correlate tra loro; ciascuno di
7
questi sistemi evolve e deve adattarsi al cambiamento continuo per garantirsi
la sopravvivenza. Esempi di sistema complesso possono essere la società e il
nostro sistema immunitario.
Secondo Tinti (1998) la complessità di un sistema è una proprietà del suo
modello creato dall’osservatore esterno e non una caratteristica del sistema
stesso; perciò si definisce sistema complesso una struttura la cui rappresentazione scientifica ha la peculiarità di essere complessa. I sistemi di questo
tipo presentano alcune caratteristiche comuni:
• tante componenti più o meno complesse; quanto più numerose e complesse sono le parti che lo compongono, tanto più complesso è il sistema
in generale;
• interazioni tra le componenti, che si passano informazioni tra loro; le
informazioni non possono essere né troppo numerose né troppo poche,
perché nel primo caso il sistema diventerebbe caotico e nel secondo si
‘‘cristallizzerebbe’’;
• assenza di gerarchia piramidale; in caso contrario il funzionamento del
sistema potrebbe essere spiegato osservando soltanto la componente
che si trova al vertice della struttura;
• interazione adattiva con l’ambiente; il sistema è tanto più complesso
quanto maggiori sono i fattori esterni che influiscono sul suo adattamento all’ambiente e sulla sua evoluzione. Questa caratteristica rende
adattivi i sistemi complessi.
È possibile classificare i sistemi in tre differenti categorie in base al loro
grado di complessità. Si definiscono sistemi minimamente complessi tutti i
sistemi naturali non biologici che non manifestano interazioni con l’ambiente
esterno. I sistemi di media complessità sono gli artefatti complessi, come
8
ad esempio il computer; questi sistemi possono essere adattivi e manifestare
comportamenti imprevedibili. Infine, i sistemi complessi sono sistemi adattivi che manifestano fenomeni emergenti, esempi di sistemi complessi sono le
popolazioni umane e tutti i sistemi biologici.
I sistemi complessi sono detti non lineari (Sanders e McCabe, 2003),
perché le variabili al suo interno interagiscono tra loro costantemente e si
modificano in risposta alle variazioni delle altre; in questi sistemi piccoli
cambiamenti possono dare origine a variazioni di tutto il sistema. I sistemi non lineari non rispondono al principio della sovrapposizione, in quanto
anche scomponendoli nelle parti costitutive non è possibile comprendere il
funzionamento del sistema totale. La caratteristica fondamentale dei sistemi non lineari è l’importanza delle interazioni tra le parti piuttosto che le
proprietà delle sue componenti.
Al contrario, i sistemi lineari sono soggetti al principio di sovrapposizione,
cioè è possibile analizzare un sistema di questo tipo studiando separatamente
le parti che lo compongono e da esse comprendere il funzionamento completo
del sistema.
La principale differenza tra i sistemi complessi, o non lineari, e quelli
complicati, o lineari, è che per i secondi il comportamento globale è la somma
dei comportamenti locali delle sue parti; per i primi invece il comportamento
del tutto è maggiore della somma dei comportamenti locali, a causa delle
interazioni tra gli agenti del sistema (Langton, 1992).
È possibile fare un esempio legato alla realtà, mettendo a confronto il
motore di un’automobile e un formicaio (Terna, 2003a). Il primo è un sistema complicato, o lineare, perché può essere scomposto in tutte le sue parti
costitutive ed a ciascuna, ad esempio il carburatore o la marmitta, può essere
associata una particolare funzione che aiuta a comprendere il funzionamento generale del motore. Il formicaio è un sistema complesso, o non lineare,
9
perché la più piccola unità di questo sistema, la formica, non è in grado di
dire nulla sulla struttura aggregata; per comprendere il funzionamento di un
formicaio, e di qualsiasi altro sistema complesso, si rivela quindi necessario
osservarlo nel suo insieme.
1.3
Un modello per la realtà: il formicaio
Secondo Ormerod (2003) la società è un sistema complesso formato da agenti interattivi che imparano e si adattano continuamente all’ambiente circostante. Questa visione è fortemente in contrasto con quella degli schemi di
pensiero tradizionali delle scienze sociali e dell’aconomia, che offrono una visione del funzionamento del mondo che può essere paragonato a quello di una
macchina.
Nella realtà si incontrano spesso fenomeni che non possono essere spiegati
con regole rigide, ma soltanto con la consapevolezza che la società è molto
simile ad un organismo vivente; ad esempio, gli individui possono prendere
delle scelte in base alle proprie opinioni, ma possono anche essere influenzati
da quelle di altri individui. Nella teoria economica convenzionale questa idea
non trova spazio, in quanto è previsto che le preferenze siano fissate per tutti.
Un modello che può essere utile per spiegare i fenomeni che si verificano nella realtà è il formicaio, un esempio di sistema complesso composto da
agenti che interagiscono tra loro e si adattano all’ambiente circostante, che
consente una via interpretativa alternativa alla teoria meccanicistica tradizionale. Infatti l’osservazione del comportamento di un gruppo di formiche
si rivela di grande utilità nel momento in cui si voglia formalizzare il comportamento di individui che si trovano di fronte a più possibilità tra cui
scegliere.
10
1.3.1
Le formiche
Gli studi biologici sulle formiche hanno dato origine a risultati che sono difficili da spiegare e che mostrano l’emergere di comportamenti complessi da
parte loro che possono trovare analogie con le società umane.
Gli esperimenti entomologici condotti durante gli anni Ottanta hanno
avuto come obiettivo l’osservazione del modo in cui le formiche prendono le
decisioni e sono consistite nel posizionare due mucchietti identici di cibo a
distanze uguali da un formicaio; i due mucchietti erano reintegrati ogni volta
che una formica portava via del cibo da uno di essi.
Intuitivamente si può dire che una formica scelga in modo casuale dove
dirigersi, perciò la distribuzione delle formiche tra i due mucchietti potrebbe
essere analizzabile semplicemente lanciando una moneta e osservando la distribuzione di teste e croci. Tuttavia gli studi dei biologi hanno evidenziato
che se una formica ha successo nella ricerca di cibo in un particolare luogo,
in futuro tenderà a tornare nello stesso posto; inoltre durante il ritorno al
formicaio la formica lascia una scia di secrezioni, il ferormone, che possono
stimolare altre formiche a dirigersi verso il mucchietto in cui la prima ha
trovato cibo.
Alan Kirman, un economista e uno dei ‘‘pionieri” nell’applicazione all’economia dei modelli basati sugli agenti interattivi (Ormerod, 2003), osservando
gli studi effettuati dai biologi sulle formiche sviluppò l’idea che per comprendere il funzionamento di un intero sistema non è sufficiente osservare soltanto
il comportamento di un suo agente rappresentativo, che sia una formica oppure un agente economico o sociale. Il risultato del sistema studiato dipende
dalle interazioni che si creano tra gli agenti e dall’influenza che essi esercitano
tra loro.
Tornando all’esempio del formicaio, secondo Kirman una singola formica
può scegliere fra tre possibilità: dirigersi verso il mucchio di cibo da cui si
11
è rifornita in un momento precedente, essere indotta dalla scia lasciata da
un’altra formica a scegliere un mucchio in particolare, oppure prendere una
scelta nuova in modo indipendente. Date queste ipotesi, ogni esperimento di
questo modello genera risultati imprevedibili e diversi tra loro che dipendono,
di volta in volta, dalla propensione delle formiche a cambiare comportamento
e a farsi convincere dalle altre.
Il modello di scelta fra tre possibilità descritto per le formiche è adottabile anche per la descrizione delle scelte delle persone in molte situazioni
reali, infatti i fenomeni sociali ed economici presentano le stesse proprietà del
comportamento di un formicaio: nel breve termine sono imprevedibili e nel
lungo periodo originano fenomeni di carattere complesso.
1.3.2
Applicazioni alla realtà
In Ormerod (2003) si afferma che è possibile riscontrare delle analogie con
il modello del formicaio se si osservano situazioni reali semplici, come la
scelta di una serata al cinema, o altre più elaborate, come ad esempio alcuni
fenomeni che si originano sui mercati finanziari.
Il primo esempio riguarda la scelta di più individui a riguardo di quale film
da vedere al cinema. Il processo di scelta è simile a quello della formica, anche
se in questo esempio ci sono alcune differenze con il modello sopra descritto,
ad esempio i film tra cui scegliere non saranno uguali come i mucchi di cibo
per le formiche, ma i registi cercheranno il più possibile di differenziare i loro
prodotti.
Per comprendere quali siano i fattori che portano al successo un film è
necessario usare la teoria degli agenti interattivi, rappresentati dal pubblico e
dai critici, che sono responsabili del successo o dell’insuccesso di una pellicola.
Infatti le persone che ne vanno a vedere una ‘‘lasciano una traccia’’ proprio
come le formiche con il ferormone, rappresentata in questo caso dalle opinioni
12
e dai passaparola, che può influenzare le scelte degli altri individui. Perciò agli
individui è possibile applicare il modello decisionale delle formiche, infatti essi
possono decidere in modo autonomo oppure farsi influenzare dalle opinioni e
dai consigli altrui. Inoltre è anche importante l’ordine con cui i film sono visti,
in quanto il fatto di andare a vedere un film l’ultimo giorno della proiezione
esercita un effetto certamente minore rispetto a quello di chi è andato la
prima sera.
Un secondo esempio è l’applicazione sviluppata da Alan Kirman in relazione ad un fenomeno realmente avvenuto sui mercati finanziari. Nei primi
anni Ottanta iniziò a prendere forza l’opinione di un numero crescente di
operatori specializzati che il dollaro fosse sopravvalutato e, ovviamente, nel
1985 questa valuta crollò; il fatto ‘‘curioso” è che durante questo periodo
gli operatori si comportarono in modo inspiegabile, continuando a comprare
il dollaro e allo stesso tempo dichiarando che quest’ultimo era decisamente
sopravvalutato.
Per studiare questo fenomeno Kirman sviluppò un modello in cui si trovano due categorie di operatori finanziari, da un lato i fundamentalist, coloro
che ritengono che i prezzi delle attività finanziarie siano determinati dai fondamentali (ad esempio, nel caso delle azioni dal valore attuale dei dividendi
futuri), e dall’altro i chartist, secondo i quali l’andamento passato di un’attività finanziaria può aiutare a prevederne il futuro. Nel 1984 i primi ritenevano
che il dollaro avrebbe subito un brusco calo, mentre i secondi erano certi del
contrario.
Nel modello ogni operatore ha tre possibilità, come le formiche: può
scegliere di comportarsi come prima, può modificare la propria opinione influenzato dalle informazioni altrui, oppure può scegliere autonomamente di
cambiare. Come nel formicaio, per ogni attività finanziaria la ripartizione
tra i due gruppi di operatori varia continuamente e in modo rapido, pertanto
13
si possono verificare grandi variazioni di prezzo in modo repentino ed inspiegabile. La volatilità dei prezzi è dunque la conseguenza della volatilità delle
scelte degli operatori.
Questo modello permette di comprendere ex post anche un comportamento senza logica come l’acquisto di una moneta considerata sopravvalutata,
dovuto a frequenti cambiamenti di opinione degli operatori, situazione che la
teoria economica tradizionale non è in grado di spiegare.
1.4
Complessità e ordine spontaneo
Le idee di Hayek secondo alcuni studiosi sono considerate anticipatrici della
teoria della complessità in quanto, in base alle loro opinioni, quest’ultima rappresenta semplicemente la riscoperta di alcuni principi hayekiani, ad esempio
la conoscenza e l’ordine spontaneo, o una rievocazione della sua filosofia del
mercato.
Ordine spontaneo e sistema auto-organizzante possono essere considerati
sinonimi (Kilpatrick, 2001), perché in un sistema complesso adattivo si può
rilevare una sorta di ordine che non è prevedibile in alcun modo.
Secondo Hayek il mercato non è mai in equilibrio e con il passare del
tempo evolve. Nella visione hayekiana il mercato è organizzato dagli agenti
senza che sia necessaria la presenza di un controllo accentrato ed è quasi
sempre in grado di raggiungere in modo autonomo la miglior configurazione;
un’eventuale autorità esterna non potrebbe migliorare la sua efficienza, ma
solo peggiorarla, a causa della complessità della società e della presenza di
una conoscenza dispersa tra gli uomini.
La maggior parte di queste idee sono condivise dai teorici della complessità, con la sola differenza che secondo la loro visione un controllo centrale
pianificatore è in grado di sistemare la configurazione del mercato nel caso
che questa non sia la migliore.
14
Un altro elemento che avvicina Hayek alla teoria della complessità è il
suo interesse per la teoria biologica evoluzionistica e per la scienza cognitiva, che lo avvicinò a gran parte della letteratura studiata dai teorici della
complessità, anche se una differenza con questi ultimi è rappresentata dal
fatto che i lavori di Hayek sono di limitato utilizzo per ulteriori analisi sui
sistemi complessi, perché non considerava di grande aiuto per la loro analisi
gli strumenti statistici.
Tuttavia il pensiero di Hayek e la moderna teoria della complessità mostrano anche alcune caratteristiche che li distinguono tra loro.
Nelle opere di Hayek sembra che sia presente l’idea di un’entità soprannaturale benevolente che si cela dietro l’ordine spontaneo; secondo Hayek le
persone dovrebbero impegnarsi a lasciar guidare la società all’ordine spontaneo piuttosto di tentare il controllo del mercato per mezzo di un’autorità
centrale.
Al contrario, i teorici della complessità non vedono una forza benevolente
dietro le dinamiche complesse. Gli uomini agiscono e ciò che fanno può
causare eventi positivi o negativi, ma non esiste una mano invisibile che
guida automaticamente l’uomo verso la migliore soluzione, perciò si rende
necessaria la presenza di un controllo accentrato che in alcune situazioni
intervenga per sistemare l’andamento della società.
Si può pertanto concludere che il pensiero di Hayek in qualche modo anticipa la teoria della complessità e chi si accinge allo studio di questa disciplina
dovrebbe analizzare attentamente i lavori hayekiani. Occorre tuttavia sottolineare che le teorie espresse dalle due parti sono qualitativamente differenti
(Kilpatrick, 2001).
15
1.5
La vita artificiale
La vita artificiale mira a sintetizzare comportamenti di tipo biologico in ambienti artificiali, ad esempio in un computer, e ad osservare i fenomeni complessi che sono originati dalle interazioni tra gli agenti e dal loro adattamento
all’ambiente circostante.
Tradizionalmente la biologia ha considerato un organismo vivente come
una macchina complessa ed in seguito ha proceduto a ‘‘scomporre” gli organismi nelle loro componenti più piccole al fine di comprendere i meccanismi
della vita. Grazie alla conoscenza delle parti che costituiscono gli organismi
viventi la biologia è stata in grado di proporre uno schema generale sulla
vita.
Tuttavia la vita dipende non solo dalle caratteristiche degli esseri viventi
ma anche dalle interazioni che si creano tra loro, perché i fenomeni naturali
sono non lineari e conseguentemente gli organismi devono essere studiati
osservando il comportamento che assumono se sono immersi nell’ambiente.
Perciò secondo Langton (1992) la vita artificiale applica il punto di vista
sintetico alla biologia: mette insieme gli esseri viventi e analizza le interazioni
che si generano; con il termine sintesi si intende la combinazione di più parti
diverse tra loro per formare un tutto.
Gli obiettivi della vita artificiale sono espressi in Langton (1992, 190):
la vita artificiale intende 1) sintetizzare il processo dell’evoluzione, 2) usando i calcolatori, e 3) studiare qualunque cosa emerga
da questo processo, anche quando i risultati non hanno corrispettivi nel mondo naturale. È certo interessante, dal punto di vista
scientifico, sapere quali tipi di cose possono, in linea di principio,
evolversi − che siano o no evolute, di fatto qui sulla Terra.
La vita artificiale si differenzia dall’intelligenza artificiale per la diversa
16
prospettiva adottata. L’intelligenza artificiale ha sempre avuto come obiettivo la generazione di comportamenti intelligenti che non necessariamente
devono avere una corrispondenza con quanto avviene in natura. Al contrario, l’obiettivo della vita artificiale è la riproduzione dei meccanismi che
avvengono nei sistemi naturali.
Nello studio della vita artificiale i calcolatori elettronici giocano un ruolo
molto importante, perché possono essere considerati come un laboratorio
in cui effettuare gli esperimenti desiderati. Il computer offre ai ricercatori
un nuovo metodo di studio e permette l’analisi di fenomeni per i quali le
equazioni che li definiscono non hanno soluzione.
Con la simulazione della vita al calcolatore gli studiosi si sono resi conto
che i comportamenti che presentano una grande complessità a livello globale
generalmente emergono da insiemi di unità che hanno regole locali molto
semplici, perciò una conclusione che si può trarre è che anche in natura,
come si è visto precedentemente per la società, i fenomeni complessi hanno
cause semplici.
1.5.1
Genotipo e fenotipo
Dal punto di vista del comportamento dei sistemi viventi è importante la
distinzione tra genotipo e fenotipo. Il genotipo è l’insieme delle istruzioni
genetiche contenute nel DNA di un organismo, mentre il fenotipo è l’organismo fisico, cioè tutto ciò che emerge come risultato dell’interpretazione del
genotipo in un particolare ambiente.
Nel contesto di vita artificiale si rende necessaria la generalizzazione di
queste definizioni in modo che siano applicabili anche nel caso di situazioni
non biologiche. Perciò di si definisce genotipo generalizzato l’insieme
non ordinato di regole di basso livello e fenotipo generalizzato i com-
17
portamenti e le strutture che emergono dalle interazioni tra le regole di basso
livello quando sono attivate in un ambiente specifico.
Nella vita artificiale si utilizza la prospettiva bottom-up, secondo cui i
sistemi sono descritti a partire da semplici regole da cui possono essere originati comportamenti di grande complessità. In questo contesto inizialmente
si definisce il genotipo, cioè il repertorio di comportamenti, e in seguito dalle interazioni dell’insieme emerge il comportamento globale del sistema, il
fenotipo.
Se si simula la vita, si può andare incontro a fenotipi complessi costituiti
su più livelli che fanno sì che emergano delle strutture gerarchiche; questa
caratteristica è evidenziata in Langton (1992, 208):
Vale la pena di notare che il fenotipo è un fenomeno a più
livelli. Anzitutto, c’è il fenotipo associato a ciascuna istruzione
particolare − l’effetto che l’istruzione ha sul comportamento di
un’entità quando viene eseguita. In secondo luogo, c’è il fenotipo associato a ciascuna entità individuale − il suo particolare
comportamento nell’aggregato. In terzo luogo, c’è il fenotipo
associato al comportamento dell’aggregato come totalità.
1.5.2
Gli algoritmi genetici
Gli studi sulla vita artificiale hanno permesso di formulare delle tecniche
evolutive che si basano sull’imitazione del processo di evoluzione biologica.
In natura le regole, o gli individui, si riproducono, mutano e si estinguono
con l’obiettivo di diffondere soltanto gli esemplari migliori.
Uno dei primi esempi di utilizzazione del modello evolutivo per la ricerca
di soluzioni è rappresentato dagli algoritmi genetici, creati da John Holland,
che con il loro utilizzo ha cercato di rappresentare il processo naturale di
18
evoluzione biologica in un modello che sia utile a cercare le soluzioni dei
problemi.
In Ferraris (1999) si legge che in un algoritmo ogni genotipo è rappresentato da una stringa di caratteri (possono essere ‘‘0’’ e ‘‘1’’) che descrive
una particolare strategia; ad ogni individuo è assegnato un fitness value, che
indica il suo grado di adattamento ed è calcolato in base ai risultati ottenuti
dall’applicazione della strategia nell’ambiente circostante.
Durante ogni iterazione alcuni individui della popolazione sono selezionati
per la riproduzione, con particolare attenzione a scegliere quelli con il fitness
value più alto, e altri per l’estinzione. La riproduzione avviene copiando
e incrociando (crossover ) le stringhe dei genitori, in modo che ai figli sia
trasmesso il patrimonio genetico di entrambi, proprio come accade in natura.
Per rendere possibile gli errori nella trasmissione genetica genitori-figli è
stata introdotta la mutazione, secondo la quale alcuni caratteri possono essere
modificati in modo casuale; il meccanismo di scelta dei caratteri avviene in
base ad una data probabilità, che in genere è molto bassa.
Dopo l’esecuzione dei processi di evoluzione e di riproduzione per più
volte si può notare che la popolazione converge verso un unico tipo di individuo al quale è associato un alto fitness value; questo significa che strategia
incorporata nelle stringhe è la migliore per l’ambiente considerato.
1.6
La simulazione e le scienze sociali
Nelle scienze della natura, come la fisica e la chimica, le teorie formulate possono essere verificate direttamente in laboratorio affinché i ricercatori siano in
grado di verificare la correttezza delle loro ipotesi. Gli esperimenti di questo
tipo consentono di capire quali sono i fattori che danno origine a determinati
fenomeni e di modificare alcuni aspetti dei primi per osservare le conseguenze
al sistema generale.
19
L’opportunità di verificare le teorie non è invece disponibile per le scienze
sociali, in quanto non dispongono di un vero e proprio laboratorio. La simulazione al computer offre a queste discipline un nuovo ed importante strumento
di ricerca, in quanto grazie ad essa sociologi, psicologi ed economisti possono
studiare alcuni aspetti della realtà, ad esempio processi e relazioni non lineari,
tramite la creazione nel computer di modelli accuratamente specificati.
La simulazione al computer è considerata la ‘‘terza via’’ (Gilbert e Terna, 2000) disponibile agli studiosi delle scienze sociali, in una classificazione
che comprende i modelli letterario-descrittivi e quelli matematico-statistici;
i primi sono molto flessibili ma la loro adeguatezza non può essere verificata
con strumenti di calcolo, mentre i secondi sono computabili ma hanno un
grave problema rappresentato semplificazioni imposte, che possono causare
un allontanamento dalla realtà. I modelli di simulazione offrono perciò un
giusto compromesso tra le esigenze di flessibilità dei primi e le possibilità di
computazione dei secondi (Terna, 2003a).
Una definizione del metodo simulativo è fornita in Parisi (1999, 28):
Le simulazioni sono teorie interpretative dei fenomeni della
realtà formulate come un programma che gira in un computer. Le
teorie della scienza mirano a identificare i meccanismi, i processi,
i fattori che stanno dietro ai fenomeni e che spiegano i fenomeni,
ce li fanno capire. Adottare il metodo della simulazione significa
tradurre una teoria in un programma di computer, far girare il
programma nel computer e verificare se il programma, cioè la simulazione, riproduce i fenomeni che la teoria intende spiegare. Le
simulazioni sono il terzo strumento della scienza, uno strumento
che si è aggiunto abbastanza di recente, cioè da quando computer
veloci e potenti sono divenuti accessibili a qualunque scienziato,
20
ai due strumenti di ricerca tradizionali: le teorie e gli esperimenti
di laboratorio.
Axtell (2000) osserva che la tecnica della simulazione ad agenti può essere usata in tre casi distinti. Nel primo, il più semplice, si presenta quando
il fenomeno sociale che si va a studiare può essere completamente descritto
da equazioni risolvibili analiticamente o numericamente; in questo caso la
simulazione può essere usata come metodo alternativo per arrivare agli stessi
risultati o come strumento per presentarli in modo più facilmente comprensibile rispetto a quelli di un modello matematico. Un secondo uso emerge nel
caso in cui il modello matematico adottato per analizzare il processo sociale
possa essere descritto ma le sue equazioni non siano risolvibili oppure i risultati non siano stabili. Infine, il terzo tipo di utilizzo si ha nel caso di problemi
sociali per i quali non è possibile una spiegazione fondata su equazioni; la
simulazione ad agenti è perciò l’unico metodo con cui è possibile studiare
questi fenomeni.
Gli utilizzatori della simulazione possono avere diversi obiettivi e, in particolare, se ne possono distinguere almeno tre (Conte, 1998 e Edmonds,
2003):
1. la proiezione, cioè l’uso di modelli per prevedere gli avvenimenti futuri
legati ad un particolare fenomeno; queste simulazioni non sono necessariamente basate su un modello ad agenti e risultano molto utili quando
il sistema su cui si indaga è di natura complessa, ad esempio se si tratta
di un processo non lineare. La simulazione in questo caso può essere
utilizzata per prevedere gli esiti di interventi di politica economica o
sociale;
2. la sperimentazione, nel caso in cui con la simulazione si intendano spiegare dei particolari fenomeni e si desideri verificare la qualità dei modelli proposti. Il modello creato nel computer può essere usato in due
21
modi: manipolando le variabili del modello, possibilità particolarmente
indicata quando non si possono realizzare modifiche nella realtà oppure
quando si intende valutare quali siano le cause scatenanti di particolari eventi, con l’obiettivo di utilizzare il computer come un vero e
proprio ‘‘laboratorio” delle scienze sociali; un secondo modo di utilizzo
è l’osservazione del comportamento del modello ‘‘così come è’’ e dei
fenomeni che hanno origine da esso;
3. infine, l’esplorazione del fenomeno costruito nel ‘‘laboratorio virtuale”, per osservare e studiare i diversi aspetti delle dinamiche sociali e
l’evoluzione della cooperazione tra gli agenti.
1.7
Lo sviluppo di una simulazione
Lo sviluppo di una simulazione prevede lo svolgimento di due fasi, la prima
di modelling, cioè la costruzione nel computer del modello da simulare, e in
seguito la simulazione vera e propria.
Modelling
Durante questa fase si crea una struttura all’interno del computer che sia in
grado di imitare un certo aspetto della realtà (Edmonds, 2003); il modello
solitamente è soggetto a dei parametri, perciò è possibile che lo stesso possa
essere adattato per simulare e analizzare diversi aspetti della stessa realtà.
La ‘‘bontà’’ di un modello è valutata in base ai seguenti criteri (Edmonds,
2003):
• la correttezza; un modello può essere costruito scegliendo uno tra i due
metodi maggiormente diffusi: il primo propone di seguire i principi che
sono stati sviluppati precedentemente per fenomeni simili ed è funzione
22
del successo che essi hanno avuto; il secondo metodo consiste nel tentativo di imitare il più possibile il processo reale ed è il più impegnativo
e difficoltoso;
• la precisione dei principi utilizzati per costruire il modello, che è misurata dalla differenza tra i risultati del modello e quelli della realtà;
generalmente la perfetta correttezza non è raggiungibile a causa della
presenza persistente di fenomeni che la ostacolano;
• la generalità, che indica la possibilità di applicare un modello in diverse
circostanze; generalmente si tende a preferire un modello più versatile
rispetto ad uno più specifico;
• la semplicità, qualità importante quando il modello deve essere applicato o interpretato;
• il costo richiesto per la creazione del modello, che spesso rappresenta
uno dei criteri guida nelle scelte dei modelli di simulazione con lo scopo
di ricerca;
Un aspetto importante di questa fase riguarda la scelta del modello da
utilizzare, in quanto ne esistono di diversi tipi. In particolare, i modelli usati
dagli economisti e dai teorici dei giochi sono detti matematici e hanno la
caratteristica di definire gli agenti in base ai valori assegnati a determinate
variabili. Un secondo tipo di modelli, detti procedurali, definiscono gli agenti
in base a delle sequenze di azioni eseguite secondo regole interne.
Infine è necessario stabilire l’affidabilità del modello usato. Occorre osservare che si possono riscontrare diverse cause di inaffidabilità in un modello
(Conte, 1998), da un primo caso in cui sono elaborate previsioni non verificate
nella realtà fino a situazioni più gravi in cui non è possibile verificare l’attendibilità del modello perché le previsioni sviluppate sono troppo generiche e
perciò impossibili da valutare.
23
Simulazione
Durante questa fase si fa funzionare il modello nel computer. Si presenta
però un interrogativo, che riguarda l’utilità della simulazione per un modello
per cui è possibile l’esecuzione analitica; in almeno tre casi l’utilizzo della
simulazione si rende necessario (Conte, 1998):
1. negli studi su sistemi che presentano capacità di apprendimento, in cui
gli agenti imparano interagendo con l’ambiente e con gli altri agenti;
2. negli studi in cui possono emergere nuovi fenomeni a partire da situazioni conosciute, riscontrabili nell’osservazione di sistemi dinamici
auto-organizzanti, che possono subire delle modifiche per adattarsi ai
cambiamenti dell’ambiente esterno;
3. negli studi sull’evoluzione e sull’adattamento dei sistemi, come nel caso
degli studi dell’Istituto di Santa Fe sui sistemi complessi adattivi.
In tutti questi casi l’esecuzione analitica non può sostituire la simulazione,
perché questa tecnica si rende necessaria per tutti i sistemi il cui studio
prevede delle interazioni con l’ambiente; infatti solo con questo metodo è
possibile consentire ai sistemi di agire in un mondo artificiale, ed in seguito a
queste azioni si possono osservare fenomeni di apprendimento e di evoluzione
dei sistemi.
Infine, ci sono casi per cui l’uso della simulazione è fondamentale, in quanto di essi non si può ottenere una soluzione da un modello analitico. Alcuni
esempi riguardano lo studio degli effetti dei sistemi complessi e di quelli semplici; questo secondo caso è molto interessante, perché in queste situazioni la
simulazione ha un carattere esplorativo, cioè è usata per formulare una teoria
e per evidenziare le proprietà più importanti del modello e non per verificare
delle ipotesi, come avviene nel primo caso.
24
1.8
I vantaggi della simulazione
Un vantaggio della simulazione consiste nella possibilità di studiare fenomeni
e realtà non direttamente accessibili; questa caratteristica si è rivelata molto
importante per archeologi e storici, che con la simulazione dispongono così
di un nuovo e importante strumento di studio.
Con la simulazione si possono perciò studiare tutti i sistemi, sia quelli
semplici sia quelli complessi; da questo punto di vista la simulazione rappresenta per i ricercatori un metodo più completo rispetto al laboratorio,
all’interno del quale si possono analizzare soltanto i sistemi semplici, perché quasi tutti i fenomeni che interessano le scienze della natura e dell’uomo
danno origine a sistemi complessi (Parisi, 1999).
La simulazione consente inoltre di elaborare modelli che mirano ad ottenere particolari risposte, ad esempio conoscere quali saranno le conseguenze
originate da un particolare insieme di fattori; grazie a questo metodo gli studiosi delle scienze sociali possono valutare gli effetti originati da particolari
provvedimenti economici o sociali prima della loro applicazione nella realtà.
L’uso della simulazione costringe l’utilizzatore a specificare il modello in
modo molto dettagliato, senza lasciare spazio a ‘‘scatole nere’’ di cui non si
conosce il funzionamento. Quindi grazie questo metodo i ricercatori possono
conoscere la realtà in modo molto approfondito e sono in grado di formulare
le loro teorie in un modo chiaro ed esplicito (Parisi, 1999).
Infine, un altro pregio della simulazione è l’aver reso possibile l’incontro
fra diverse discipline, sia per quanto riguarda il metodo di ricerca scelto sia
per i temi di studio, che si sono rivelati, in alcuni casi, di carattere multidisciplinare. I temi unificanti che sono emersi dai vari studi sono i seguenti
(Conte, 1998):
• l’emergenza, cioè la manifestazione spontanea di fenomeni inaspettati
a partire da modelli conosciuti;
25
• la complessità, che si può concretizzare, ad esempio, nella formazione
di organizzazioni oppure nella specializzazione funzionale;
• l’evoluzione degli agenti e dei sistemi in risposta all’ambiente circostante;
• la distribuzione, ovvero la condivisione di proprietà e comportamenti
da parte delle unità del modello;
• la comunicazione, che è necessaria al coordinamento ed alla diffusione
di regolarità.
1.9
I problemi della simulazione
Il più noto dei problemi legati all’uso della simulazione riguarda l’interpretazione dei dati che sono originati dal modello, una questione approfondita nel
paragrafo seguente. Da un lato, se questi ultimi non confermano le ipotesi
iniziali, è difficile capire se il risultato sia attribuibile ad un errore di specificazione del modello o semplicemente ad uno di programmazione; dall’altro
lato, se le ipotesi sono confermate, risulta difficoltoso affermare l’adeguatezza dei risultati, perché oltre a quelli espliciti possono essercene anche altri
impliciti.
Un secondo tipo di problema riguarda la progettazione del modello. Pur
avendo il vantaggio di usare linguaggi di programmazione non particolarmente difficili, questa fase ha un primo tipo di costo che può essere misurato
nel tempo dedicato alla progettazione del modello, in quanto è necessario
imparare il linguaggio da usare; dopo aver scritto il codice si presenta un
altro costo, rappresentato dal tempo impiegato a controllare che non ci siano
errori nel programma.
Un ulteriore problema consiste nella definizione delle assunzioni relative
ai diversi aspetti delle realtà che si studiano e nella scelta del modello e dei
26
valori da assegnare ai parametri, che possono richiedere del tempo, necessario
all’utilizzatore per scegliere la migliore delle possibilità.
Infine, un ultimo problema riguarda il realismo della simulazione, definito
in Conte (1998) come la trappola della verosimiglianza. La simulazione rappresenta una semplificazione della realtà, individuando i fattori fondamentali
che determinano i fenomeni oggetto di studio, e ogni miglioramento che si
vuole portare richiede maggiori sforzi di progettazione. Tuttavia è anche importante trovare il giusto bilanciamento tra i dettagli necessari e quelli che
non lo sono, per non correre il rischio di fare un’errata specificazione e creare
un modello che non è in grado di rappresentare la realtà studiata.
1.10
L’interpretazione dei modelli
Il problema dell’interpretazione dei risultati di una simulazione ha una grande
importanza perché, come argomentato in Axtell e Epstein (1994), se non si
è in grado di comprendere i sistemi complessi artificiali meglio di quanto si
riesce a fare per quelli reali non si è giunti a nessun miglioramento.
Per rendere comprensibili per se stessi e per gli altri i modelli è necessario
seguire alcune indicazioni descritte in Gilbert e Terna (2000).
Occorre innanzitutto considerare gli agenti come degli oggetti, cioè parti
di codice informatico in grado di contenere dati e regole su come agire su
essi; queste regole forniscono la spiegazione di come gli agenti reagiscono ai
messaggi provenienti dall’ambiente esterno.
Inoltre è necessario osservare sia il comportamento individuale degli agenti, determinato dalle variabili di stato di ognuno di essi, sia il comportamento che emerge dalle loro interazioni a livello aggregato. In Terna (1998)
si afferma che, da un punto di vista metodologico, possono esistere due tipi di emergenza: l’emergenza imprevista, ma in qualche modo prevedibile,
cioè quando all’interno del modello compare un comportamento ricorrente
27
le cui cause sono nascoste all’interno della struttura stessa del modello, e
l’emergenza imprevedibile, che si manifesta quando i dati di un esperimento
hanno caratteristiche simili a quelli di un fenomeno caotico; il caos è osservabile nei fenomeni economici e sociali, ma non è facile tentare di riprodurlo
in un modello ad agenti.
Infine, occorre valutare se la simulazione ha successo e per fare ciò si
potrebbe utilizzare un metodo matematico-statistico, ma siccome potrebbe
risultare difficile da applicare ad un modello computazionale, spesso si utilizzano criteri differenti. Un primo modo consiste nel confrontare ciò che si
conosce del comportamento degli agenti appartenenti al modello con le loro
reali azioni durante la simulazione.
Un metodo di valutazione più rigoroso è rappresentato dall’esame degli
effetti degli agenti a livello aggregato, considerando le strutture ed i gruppi
che emergono; secondo Axtell e Epstein (1994) i modelli ad agenti possono
essere classificati in base a quattro livelli:
Livello 0, se il modello è una caricatura della realtà, come stabilito tramite
l’utilizzo di semplici dispositivi grafici.
Livello 1, se il modello è conforme qualitativamente con le macro-strutture
empiriche, come dimostrato se si tracciano le distribuzioni di alcune
caratteristiche della popolazione di agenti.
Livello 2, se il modello è conforme quantitativamente con le macro-strutture
empiriche, come stabilito da procedure statistiche.
Livello 3, quando il modello mostra coerenza qualitativamente e quantitativamente con le micro-strutture empiriche determinate da analisi
cross-section sugli agenti della popolazione.
Questi livelli sono progressivi, perciò se un modello presenta performance
di livello n conseguentemente sarà soddisfacente anche al livello n−1.
28
I risultati della simulazione riguardanti il comportamento collettivo potrebbero risultare difficili da comprendere tanto quanto la stessa realtà; questo problema è simile a quello incontrato nella vita artificiale riguardante la
comprensione dei legami tra il genotipo e il suo fenotipo1 . In questo ambito l’idea fondamentale è che il comportamento degli agenti è semplice ma
si adatta all’ambiente esterno e alle relazioni con gli altri agenti, perciò è
possibile che dalle interazioni emergano fenomeni complessi e inattesi.
Nel problema dell’interpretazione del modello è necessario includere anche la comprensione del programma utilizzato per far funzionare il modello
al computer (Axtell e Epstein, 1994), per verificare che esso faccia ciò che
l’utilizzatore desidera e che non ci siano delle imprecisioni dovute alla disattenzione del programmatore, ad esempio errori nell’indicizzazione delle
matrici usate dagli agenti.
1.11
Gli agenti
Wooldridge e Jennings (1995) sostengono che la definizione più generale che
può essere data al termine agente consiste nel considerarlo un sistema computazionale posto in un certo ambiente dotato delle seguenti caratteristiche:
• autonomia, che gli consente di operare senza la necessità di un intervento umano;
• abilità sociale, cioè capacità di interagire e comunicare con altri agenti;
• reattività, che gli permette di reagire in modo tempestivo ai cambiamenti dell’ambiente circostante;
• capacità di prendere iniziative guidate da obiettivi interni, o pro-attività.
1
vedi paragrafo 1.5.1
29
Secondo coloro che studiano l’intelligenza artificiale, l’agente è un sistema
computerizzato che, oltre a possedere le caratteristiche sopra descritte, è
concepito usando concetti che sono abitualmente applicati agli esseri umani.
Ad esempio, è possibile definire gli agenti usando caratteristiche come la
conoscenza, le opinioni, le intenzioni, i desideri e i doveri.
Una teoria soddisfacente degli agenti deve essere in grado di illustrare
in modo approfondito tutti gli attributi sopra considerati e di mostrare in
che modo sono collegati questi ultimi; ad esempio, dovrà specificare come
l’ambiente influisce sul comportamento dell’agente e come gli obiettivi e le
informazioni guidano le sue azioni.
È possibile effettuare una classificazione generale degli agenti usati in una
simulazione in base ai loro meccanismi di decisione, alla capacità di adattamento e di apprendere; se gli agenti sono privi di capacità di apprendimento
sono detti ‘‘senza mente”, in caso contrario ‘‘con mente”. Inoltre si può effettuare una distinzione anche secondo l’ambiente in cui si trovano, che può
essere neutrale o strutturato, cioè dotato di regole precise a cui gli agenti
devono attenersi. Ne consegue che gli agenti possono essere raggruppati in
quattro categorie (Terna, 2003a):
1. agenti ‘‘senza mente’’ in un ambiente neutrale, o non strutturato;
2. agenti ‘‘senza mente’’ in un ambiente strutturato;
3. agenti ‘‘con mente’’ in un ambiente neutrale;
4. agenti ‘‘con mente’’ in un ambiente strutturato.
Nel primo caso, agenti senza mente in ambiente neutrale, si osserva che
dalla simulazione emerge un fenomeno complesso, con elementi di caos generati indirettamente dagli agenti; in questi tipi di esperimenti si possono
30
notare due tipi di emergenza, quella imprevista e quella imprevedibile, illustrate nel paragrafo 1.10. Tuttavia i fenomeni provocati da agenti di questo
tipo non sono realistici, perciò sono di scarso interesse scientifico.
Al contrario, se si inseriscono agenti senza mente in un ambiente strutturato, ad esempio la borsa, si nota che si creano fenomeni complessi che
originano risultati realistici grazie alla presenza di un ambiente con regole.
L’aspetto interessante di questo esempio è che l’emergenza di situazioni complesse è dovuta alle caratteristiche dell’ambiente e non a quelle degli agenti
operanti.
Nel terzo caso si presentano agenti con mente in un ambiente neutrale.
In questa situazione gli agenti economici sono in grado di imparare ad agire
in modo coerente, conoscendo a mano a mano quali sono le conseguenze
che derivano da una particolare azione; per un osservatore esterno gli agenti
di questo tipo sembrano operare seguendo obiettivi e strategie interne, ma
in realtà sono guidati soltanto da semplici regole e il loro comportamento
è dovuto soltanto alla loro capacità di adattamento. I risultati indicano
l’emergere di un ordine in linea con la prospettiva dell’ordine spontaneo di
Hayek.
Infine, utilizzando agenti con mente in un ambiente strutturato si va incontro all’emergenza di fenomeni complessi come nel secondo caso; inoltre in
questa situazione gli agenti si adattano ed imparano e sono in grado di determinare risultati importanti anche a livello individuale, sviluppando strategie
che ad un osservatore esterno possono sembrare non ovvie.
31
Capitolo 2
Gli strumenti per la simulazione
In questo capitolo si presentano Swarm, NetLogo, e RePast, alcuni strumenti
con i quali è possibile costruire all’interno del computer modelli di simulazione
ad agenti.
Tra essi Swarm è quello che vanta la maggior diffusione e la maggior robustezza del codice (Terna, 2003a) ed è presentato in modo più approfondito,
perché è il protocollo di programmazione su cui si basa jES (java Enterprise
Simulator), che sarà descritto nel capitolo 4.
Su NetLogo e RePast sono fornite soltanto alcune informazioni che consentono di comprendere come è strutturato l’ambiente di simulazione.
2.1
Swarm
Il progetto Swarm1 nasce nel 1994 dall’idea di Chris Langton ed è successivamente sviluppato all’interno dell’Istituto degli Studi sulla Complessità di
Santa Fe.
Swarm è una piattaforma informatica con cui è possibile effettuare simulazioni di sistemi complessi adattivi; l’unità base della simulazione è lo sciame,
1
Disponibile alla pagina web http://www.swarm.org e http://wiki.swarm.org
32
2. GLI STRUMENTI PER LA SIMULAZIONE
che è definito come un insieme di agenti che eseguono una serie di azioni.
Swarm offre delle librerie di componenti con le quali si possono costruire
modelli e analizzarli.
Figura 2.1: Logo di SWARM
In Minar, Burkhart, Langton e Askenazi (1996) si legge che uno dei principali motivi della nascita del progetto Swarm è l’esigenza di disporre di uno
strumento versatile per lo studio dei sistemi complessi che possa essere facilmente comprensibile ed utilizzabile dai ricercatori di diverse discipline; il
progetto deve pertanto la sua nascita al lavoro congiunto di più studiosi, che
hanno avuto come obiettivo primario la creazione di una ‘‘lingua franca della
simulazione ad agenti” (Terna, 2003a).
Prima della sua creazione nell’ambito dello studio dei sistemi complessi
era presente un grande numero di modelli di simulazione, che risultavano di
difficile interpretazione e comprensione per chi tentasse di avvicinarsi allo
studio di un particolare fenomeno. Il motivo principale è che le piattaforme
di simulazione esistenti erano molto specifiche e contenevano un numero di
assunzioni implicite che erano chiare soltanto ai creatori del software.
Swarm presenta il vantaggio di poter essere utilizzato in diverse area di
ricerca, ad esempio nella chimica, nell’ecologia, nell’economia e nelle scienze
33
sociali, grazie al fatto che il codice informatico relativo al comportamento
degli agenti deve essere integralmente scritto dall’utilizzatore; il progetto
infatti fornisce soltanto le funzioni generiche di gestione del tempo, dei cicli
di funzionamento e di interazione grafica con l’utente.
2.1.1
Sviluppo di una simulazione
Il formalismo adottato da Swarm prevede un insieme di agenti che interagiscono tra loro mediante eventi. L’agente è l’oggetto principale all’interno di
una simulazione e può generare eventi che interessano se stesso o altri agenti.
Il verificarsi degli eventi è regolato da un calendario interno che descrive
le azioni nel preciso ordine in cui devono essere eseguite; il tempo avanza solo
nel momento in cui gli eventi inseriti nella sequenza sono stati eseguiti.
La componente che organizza gli agenti è detto sciame (o swarm) e rappresenta un intero modello, in quanto contiene gli agenti e la rappresentazione
del tempo, vale a dire una sequenza di attività che devono essere eseguite.
Gli sciami possono essere anche agenti, oltre che i loro contenitori; un
agente per definizione è costituito da un insieme di regole e di capacità di risposta agli stimoli ma, come si legge in Minar, Burkhart, Langton e Askenazi
(1996), può essere allo stesso tempo anche uno sciame, cioè una collezione di
oggetti e di sequenze di azioni da svolgere. In questa situazione il comportamento dell’agente è definito dalle interazioni che si svolgono all’interno dello
sciame.
Un semplice esempio di quanto esposto si può avere nel caso di una simulazione di carattere economico; se si sceglie di studiare un distretto industriale,
si ottiene che lo sciame è composto dalle aziende che compongono il distretto
e ogni azienda rappresenta un agente con un proprio comportamento. Ma si
può raggiungere un livello di dettaglio maggiore del sistema economico se si
afferma che ogni impresa appartenente al distretto è anch’essa uno sciame:
34
infatti può essere composta da agenti che rappresentano, per esempio, le unità produttive, gli impiegati e gli operai, e ha un calendario interno distinto
da quello del modello generale. Nel caso si volesse studiare il comportamento
dei singoli agenti all’interno di un’impresa, per analizzare ad esempio il ruolo
dell’imprenditore, si potrebbe creare uno sciame che lo rappresenta, formato da agenti che determinano il suo comportamento generale e un orologio
interno che indica gli eventi da svolgere. Si creerebbe in questo modo una
gerarchia di modelli interdipendenti tra loro.
Per effettuare una simulazione in qualsiasi ambito di ricerca occorre portare a termine una serie di azioni che possono essere riassunte in uno schema
generale:
• l’utilizzatore deve definire gli agenti e stabilire le regole che definiscono
il loro comportamento; inoltre deve decidere quali relazioni intercorrono
tra loro;
• in seguito deve inserire tutti gli agenti all’interno di uno sciame, descrivendo un elenco di attività da svolgere con l’indicazione dei tempi in
cui devono essere portate a termine;
• il ricercatore deve anche definire quali strumenti utilizzare per osservare
l’andamento della simulazione (grafici, statistiche, ...); essi sono messi a
disposizione dalle librerie di Swarm e sono anch’essi agenti appartenenti
ad uno sciame, detto observer. Il motivo del ricorso a questa opzione
dipende dal fatto che il fine ultimo dei ricercatori non è far funzionare il
modello, ma analizzare la nascita e l’evoluzione dei fenomeni complessi
nei mondi da loro costruiti;
• dopo aver definito e combinato il model e l’observer, l’apparato di
simulazione è completo ed è possibile far ‘‘funzionare” l’universo creato.
35
Dallo schema proposto risalta il fatto che la struttura di Swarm è composta da due livelli differenti (Terna, 1998): al primo livello si ha il modello
(model ), che rappresenta il fenomeno che si vuole analizzare, al secondo l’osservatore, (observer ) che considera il modello come un unico oggetto con
il quale interagisce per ottenere i risultati richiesti dagli strumenti che il
ricercatore utilizza per analizzare il mondo creato.
Riprendendo l’esempio precedente sul distretto industriale, nella Figura 2.2 è mostrato un esempio sintetico della struttura della simulazione. Nel
model sono presenti gli agenti, cioè le industrie, e un gestore del tempo che
contiene le azioni da svolgere; nell’observer vi sono altri tipi di agenti, vale a
dire gli strumenti di controllo del modello, e un altro gestore del tempo. Sia
il model sia l’observer sono sciami.
Figura 2.2: Struttura di una simulazione
2.1.2
Caratteristiche principali
La struttura di Swarm è realizzata con il linguaggio di programmazione ad
oggetti Objective C. Questo stile di programmazione consiste nella definizione
36
di varie classi di oggetti; un oggetto è la combinazione di variabili di stato, che
ne definiscono le caratteristiche interne, e di metodi, che ne rappresentano il
comportamento.
Dalla versione 2.0 di Swarm gli utilizzatori possono scrivere i modelli
con il linguaggio Java, creato dalla Sun Microsystem; i vantaggi principali
di questo linguaggio sono la scarsa possibilità di creare errori all’interno del
modello e la sua grande diffusione (Johnson e Lancaster, 2000).
Le caratteristiche più importanti della programmazione object-oriented
dal punto di vista dell’utilizzo di Swarm sono l’incapsulamento e l’ereditarietà, che permettono di creare software utilizzabili in più situazioni richiamando semplicemente la classe di una libreria che si vuole utilizzare.
Secondo il principio dell’incapsulamento i dettagli interni di un oggetto sono protetti e non possono essere messi a disposizione dell’utente, ad
eccezione di quei metodi che sono scritti con l’obiettivo di trasmettere informazioni all’esterno. Come spiegato in Sciabarrà (2003), la programmazione
object-oriented applica all’informatica dei concetti che sono comuni nel modo
in cui le persone considerano gli oggetti fisici. Prendendo una semplice radio
come esempio di oggetto, possiamo notare che presenta la caratteristica di
essere incapsulato: infatti, per poterla utilizzare non occorre essere esperti
di elettronica, è sufficiente agire sui pulsanti; la stessa cosa avviene nel caso
degli oggetti informatici, dal momento che gli utenti possono agire solo sui
metodi che sono messi a loro disposizione dall’oggetto, senza dover conoscere
le sue caratteristiche interne.
L’ereditarietà permette che ogni sottoclasse erediti le variabili ed i metodi
della classe base, che è chiamata superclasse. In questo modo si può creare
una classe che contiene i metodi della classe di livello superiore e ne aggiunge
di nuovi. Tornando all’esempio della radio, possono essercene di diverse tra
loro che hanno una maggiore ricezione o un altoparlante più potente; queste
37
ultime ereditano le caratteristiche di base dalla radio normale, che, con una
metafora informatica, potrebbe essere definita la superclasse delle radio.
2.1.3
Le ‘‘sonde’’
Le sonde, o probes, permettono all’utilizzatore di interagire con gli oggetti
della simulazione osservando e modificando i valori delle variabili; il loro
maggior vantaggio sta nel non dover aggiungere nuovo codice informatico
per poterle utilizzare.
Una sonda è una finestra rettangolare nelle cui righe sono descritti gli
attributi dell’oggetto preso in considerazione; i dati mostrati possono riguardare il modello in generale oppure possono rappresentare le informazioni di
un semplice agente che opera all’interno del modello. Tutti i progetti costruiti con Swarm hanno almeno due sonde: quella del ModelSwarm, che
indica i parametri del modello, e quella dell’ObserverSwarm, che contiene
le caratteristiche degli strumenti utilizzati per analizzare l’andamento della
simulazione.ella Figura 2.3 sono mostrati due esempi di sonde di model e
observer.
Figura 2.3: Esempi di sonde
38
2.1.4
Le librerie di Swarm
Le librerie di Swarm hanno due funzioni principali: elencano una serie di classi che i costruttori del modello possono utilizzare e sono impiegate per creare
delle sottoclassi più specifiche per le particolari finalità della simulazione.
In Minar, Burkhart, Langton e Askenazi (1996) le librerie sono suddivise
in due gruppi: da un lato quelle fondamentali per ogni modello di simulazione, swarmobject, activity e simtools, dall’altro le librerie di supporto, utili per
la creazione di modelli che rispondano a particolari esigenze, defobj, collections, random, tkobjc.
La libreria swarmobject contiene le classi principali su cui si basano gli
agenti creati nel modello. Questa libreria contiene la classe SwarmObject,
dalla quale tutti gli agenti ereditano il loro comportamento, e la classe Swarm,
che è utile per la scrittura del ModelSwarm e dell’ObserverSwarm.
La libreria activity permette la definizione del calendario degli eventi e
supporta l’esecuzione della simulazione.
Infine, l’ultima libreria specifica è simtools, un insieme di classi che controllano l’intero svolgimento della simulazione. Le classi contenute in questa
libreria possono, ad esempio, creare grafici riassuntivi ed elaborare statistiche.
Passando al secondo gruppo di liberie, defobj definisce le indicazioni standard per la creazione degli oggetti, per l’archiviazione di dati e per il trattamento degli errori.
La libreria collections mette a disposizione le classi utili per seguire gli
oggetti, per esempio mappe e liste.
La libreria random offre all’utente una serie di classi che generano numeri
casuali e che possono trasformare sequenze di numeri casuali in numerose
distribuzioni di probabilità. Nella simulazione al computer la fase della gene-
39
razione di numeri casuali è molto importante, in quanto influenza i risultati
finali, pertanto è fondamentale evitare di utilizzare generatori di numeri con
distorsioni o correlazioni tra loro.
L’ultima libreria del supporto di base di Swarm è tkobjc, che contiene gli
oggetti base per la creazione di un’interfaccia per l’utente; con le sue classi è
possibile creare bottoni, istogrammi e grafici.
In aggiunta alle librerie base richieste per la simulazione ci sono molte altre librerie che possono essere utilizzate per la costruzione di particolari modelli. Esistono librerie che supportano gli spazi bidimensionali, gli algoritmi
genetici e le reti neurali.
La libreria space è utile nella costruzione di ambienti in cui gli agenti
interagiscono tra loro; è prevista la definizione di uno spazio a due dimensioni, simile ad una griglia di punti nella quale sono collocati gli oggetti della
simulazione.
Infine, ga rappresenta la prima libreria creata dal gruppo di utilizzatori
di Swarm e consente l’uso di algoritmi genetici, mentre neuro permette di
utilizzare le reti neurali artificiali.
2.2
NetLogo
NetLogo2 è un ambiente per la simulazione di fenomeni naturali e sociali
scritto in Java.
Nasce nel 1999 dall’unione di StarLisp e Logo. Dal primo, un parallelo del
Lisp, eredita la struttura a più agenti, mentre dal secondo deriva la possibilità
di controllare una ‘‘tartaruga’’ (turtle); Logo era molto popolare per l’ottima
grafica, ma aveva il difetto, superato da NetLogo, che nel modello poteva
esserci una sola tartaruga. NetLogo rappresenta inoltre il risultato degli
2
Disponibile alla pagina web http://ccl.northwestern.edu/netlogo
40
studi su StarLogoT fatti dai suoi creatori, che hanno riscritto completamente
il linguaggio e ridisegnato l’interfaccia grafica.
Figura 2.4: Logo di NetLogo
Gli utilizzatori possono inserire istruzioni per gli agenti indipendenti che
operano in parallelo nel modello; questo rende possibile l’analisi delle connessioni tra i comportamenti individuali degli agenti e la caratteristiche che
emergono dall’interazione di popolazioni di individui.
Gli studi di fenomeni complessi effettuati con NetLogo possono interessare
una grande varietà di ambiti di studio, quali, per esempio, le scienze naturali,
la biologia, la medicina, la matematica, le scienze sociali, l’economia e la
psicologia.
2.2.1
Caratteristiche principali
Il mondo di NetLogo è popolato da agenti che seguono le istruzioni impartite
dall’utilizzatore. Nel modello possono esserci tre tipi di agenti (Wilensky,
1999):
• la tartarughe, turtles, che si muovono ed interagiscono tra loro nel mondo in cui si trovano; si possono anche definire diversi tipi di tartarughe, in modo da associare ad essi differenti variabili e comportamenti
e valutare i fenomeni che emergono dalla loro interazione;
• i patch, che sono delle sezioni quadrate di uno spazio continuo a due
dimensioni in cui le tartarughe si possono muovere. I patch hanno
delle coordinate chiamate pxcor, per la dimensione orizzontale, e pycor,
41
per la dimensione verticale; il patch al centro del mondo ha coordinate
(0, 0). Il mondo in cui si trovano le tartarughe non è limitato, è un
toroide, perciò se una tartaruga si muove oltre il limite sinistro del
mondo scompare per poi riapparire all’estremo destro della zona che
rappresenta il mondo;
• l’observer, che osserva ciò che accade nel modello; quando si avvia
il modello non esistono tartarughe ed è compito dell’observer crearne
nuove.
Un’importante e nuova caratteristica del linguaggio di NetLogo è l’introduzione dell’agentset, o collezione di agenti, che permette la definizione di un
insieme di agenti aventi le stesse caratteristiche e lo stesso comportamento.
Un agentset può essere costituito da un insieme di più tartarughe o di più
patch di un certo tipo, ad esempio solo tartarughe rosse oppure una colonna
di patch, cioè una serie di patch con la stessa coordinata per l’ascissa.
Oltre alle speciali strutture che supportano il modelli formati da più agenti, NetLogo prevede anche le altre possibilità della programmazione standard
come ad esempio i cicli, le condizioni, le recursioni e le liste.
2.2.2
Obiettivi futuri
In Tisue e Wilensky (2004) si legge che gli obiettivi per il futuro riguardano
l’aumento della velocità di simulazione e una maggiore estendibilità.
Per quanto riguarda il secondo aspetto, NetLogo è nato con la caratteristica di ‘‘piattaforma chiusa”: gli utilizzatori non potevano modificarlo o
controllarlo con codice esterno. I primi miglioramenti si sono avuti con la
versione 2.0.1, nella quale è presente un’interfaccia per le estensioni che consente all’utente di inserire nuovi elementi al modello base; per esempio è ora
possibile far produrre un suono agli agenti usando le capacità midi di Java.
42
Tra gli obiettivi delle future versioni del software si ricordano:
• la creazione di 3-D NetLogo, che al linguaggio base aggiunge la grafica
tridimensionale;
• ulteriori miglioramenti nel codice informatico;
• una maggiore flessibilità degli agenti.
2.3
RePast
RePast3 , acronimo per REcursive Porous Agent Simulation Toolkit, è uno
strumento per la simulazione ad agenti scritto completamente in Java e simile
a Swarm creato dal Social Science Research Computing dell’Università di
Chicago.
Questo software offre una libreria di classi utili per creare e far funzionare
i modelli di simulazione e per l’uso di grafici che visualizzino i risultati.
Figura 2.5: Logo di RePast
Inizialmente RePast era stato concepito con l’idea di creare una serie
di librerie Java da affiancare a Swarm per semplificarne l’utilizzo; tuttavia
questo progetto venne abbandonato nel momento in cui uscì la versione Java
di Swarm, in quanto RePast rappresentava soltanto un doppione. Pertanto
lo sviluppo di questo software è continuato in modo indipendente da Swarm
all’interno dell’Università di Chicago ed anche in altri ambienti di ricerca.
3
Disponibile alla pagina web http://repast.sourceforge.net/index.php
43
2.3.1
Obiettivi
In Collier (2003) si legge che gli obiettivi principali dei creatori di RePast
sono il raggiungimento di un buon livello di astrazione della struttura della
simulazione, l’estendibilità, e la performance ‘‘good enough’’.
L’astrazione è una delle caratteristiche più importanti di RePast, che
astrae la maggior parte degli elementi chiave della simulazione ad agenti e li
rappresenta in classi Java. La versione 1.4 di RePast offre una serie di classi
per molte delle più comuni astrazioni della simulazione ad agenti, come ad
esempio le sequenze e la raccolta di dati, componenti utili alla costruzione di
rappresentazioni.
L’estendibilità è resa possibile dall’uso del linguaggio Java, in quanto
la programmazione ad oggetti permette la creazione di strutture estendibili
grazie alle proprietà dell’ereditarietà e dell’incapsulamento.
Il concetto della performance ‘‘good enough’’ si riferisce al livello delle
prestazioni di RePast in rapporto agli altri benefici di questo strumento di
analisi. L’attenzione maggiore dei creatori di RePast è concentrata sulla
minimizzazione del numero di oggetti creati e sulla velocità della simulazione,
che si basa principalmente sui miglioramenti che saranno portati alla Java
Virtual Machine.
2.3.2
Caratteristiche della simulazione
Con RePast è possibile realizzare una simulazione concepita come una state machine costituita dagli stati di tutte le sue componenti; queste ultime
possono essere divise in due gruppi, l’infrastruttura e la rappresentazione.
L’infrastruttura rappresenta tutti i meccanismi che permettono di far funzionare la simulazione, come ad esempio mostrare e raccogliere dati. Lo stato
dell’infrastruttura è lo stato dei grafici e degli oggetti che raccolgono dati.
La rappresentazione è ciò che l’utilizzatore della simulazione costruisce,
44
cioè il modello. Lo stato della rappresentazione è lo stato degli agenti appartenenti al modello, indicato dai valori delle loro variabili e dello spazio in cui
operano.
Qualsiasi modifica agli stati dell’infrastruttura e della rappresentazione
sono realizzati attraverso un calendario; questo meccanismo permette una
grande flessibilità per l’utilizzatore della simulazione.
L’unità di tempo usata dal simulatore è, come in Swarm, il tick e il
passare del tempo è scandito dall’esecuzione delle attività programmate nel
calendario; durante la simulazione si passa al tick successivo solo nel momento
in cui l’azione programmata per un dato tick si è conclusa, perciò in RePast i
tick rappresentano soltanto un modo per far trascorrere gli eventi in un certo
ordine.
Una tipica simulazione costruita con RePast è composta da una serie di
agenti, che possono essere omogenei oppure inseriti all’interno di una gerarchia, e da un modello che controlla che gli agenti eseguano i loro comportamenti secondo il calendario interno. Il calendario ha anche il compito
di controllare gli eventi all’interno del modello, ad esempio aggiornando il
monitor e raccogliendo dati, e può essere può essere creato internamente al
modello o esternamente da parte dell’utilizzatore.
Nel formalismo di RePast gli eventi sono chiamati azioni (Collier, 2003).
2.3.3
Le librerie
RePast è composto da 210 classi Java organizzate nelle seguenti librerie:
• la libreria analysis contiene le classi che sono usate per raccogliere dati
e rappresentarli su grafici;
• le classi contenute nel pacchetto engine sono responsabili dell’organizzazione e del controllo di una simulazione;
45
• le classi del pacchetto event sono usate internamente da RePast e sono
incaricate, insieme ad alcune della libreria engine, della comunicazione
tra le parti interne del modello non di competenza del calendario della
simulazione;
• la libreria games contiene le classi utili a simulare giochi cooperativi
come il dilemma del prigioniero;
• le classi gui sono responsabili della visualizzazione grafica della simulazione e della possibilità di creare delle animazioni del modello con
QuickTime;
• la libreria network contiene le classi incaricate di creare la rete della simulazione; la classe interna NetworkFactory è usata per creare il
network o per caricarlo da un file;
• il pacchetto space contiene le classi che si occupano delle relazioni
spaziali e possono rappresentare vari tipi di spazio;
• la libreria util contiene classi che possono essere sfruttate sia internamente da RePast sia dall’utilizzatore; le più importanti sono la classe
Random, che contiene un grande numero di distribuzioni casuali, e
SimUtilities, in cui ci sono metodi per creare sonde e liste.
2.3.4
Progetti futuri
Il lavoro dei creatori di RePast è concentrato su Evolver, un rapido ambiente di simulazione che può essere composto da diverse parti, ad esempio da
modelli predefiniti e da componenti di analisi; tutto ciò che non è incluso nel
modello base può essere inserito usando il linguaggio NQPython (Not Quite
Python), simile a Python e più semplice di Java, specificamente creato per
integrare RePast.
46
Capitolo 3
Impresa, imprenditore e
conoscenza
In questo capitolo si presentano gli studi di diversi economisti che hanno avuto come oggetto l’impresa e le sue influenze sull’ambiente economico generale.
Nell’esposizione è riservata una particolare attenzione alla figura dell’imprenditore e al ruolo assunto dalla conoscenza, con l’obiettivo di comprendere l’importanza che hanno nell’impresa e nel sistema economico secondo le diverse
teorie presentate.
La teoria neoclassica ha presentato la figura dell’imprenditore considerandolo come un semplice fattore produttivo dell’impresa, il cui compito è
organizzare al meglio le risorse e scegliere la miglior funzione di produzione.
In piena contrapposizione con i neoclassici si trovano gli esponenti della
Scuola Austriaca, secondo i quali la figura dell’imprenditore è molto importante sia per l’impresa sia per il sistema economico in generale. L’imprenditore ha un ruolo di primo piano all’interno dell’impresa e il suo compito
è scoprire nuove opportunità di profitto nel mercato; questa funzione emerge anche dal significato etimologico del termine imprenditore, che deriva dal
verbo latino prehendo, il cui significato è ‘‘vedere, scoprire, percepire, ren-
47
3. IMPRESA, IMPRENDITORE E CONOSCENZA
dersi conto di qualcosa”. L’imprenditore inoltre ha la funzione di trasmettere
nuove conoscenze a tutti gli appartenenti al mercato, perciò nella visione
Austriaca ha una grande importanza per il sistema economico generale.
La visione della Scuola Austriaca è ripresa e approfondita da uno dei
suoi allievi, Israel M. Kirzner, che aggiunge degli elementi nuovi alla figura
dell’imprenditore, la cui principale caratteristica è la capacità di notare nel
mercato ciò che altri imprenditori non sono stati in grado di vedere e in
questo modo di sfruttare nuove occasioni di profitto.
Una nuova posizione emerge dagli studi di Herbert Simon sulle decisioni nelle organizzazioni, secondo i quali l’imprenditore agisce in condizioni
di razionalità limitata; questa situazione è causata dall’impossibilità per gli
individui di raggiungere il grado di conoscenza completa, che consentirebbe
loro di effettuare le scelte in modo perfettamente razionale. Perciò secondo Simon l’imprenditore non è in grado di prendere la decisione migliore
possibile, bensì la più soddisfacente in base alle informazioni di cui dispone.
3.1
La teoria neoclassica
Secondo la visione neoclassica l’impresa rappresenta un insieme di fattori che
sono utilizzati per produrre un bene che possa essere venduto ad un prezzo
almeno pari alla somma dei costi affrontati (Colombatto, 2001).
Il processo produttivo per ogni bene è una funzione a se stante all’interno dell’impresa ed agisce secondo meccanismi conosciuti che possono essere
modificati da eventuali variazioni delle variabili esogene, ad esempio il costo
dei fattori produttivi.
Nella prospettiva neoclassica non esistono l’incertezza e le asimmetrie
informative, infatti gli unici dubbi sul futuro riguardano i valori che le variabili esterne all’impresa possono assumere e non il funzionamento interno
o l’attività dell’imprenditore.
48
L’imprenditore ha il semplice ruolo di amministratore delle risorse, deve
scegliere la funzione di produzione che meglio si adatta all’impresa e verifica
che il funzionamento dell’impresa sia coerente al modello adottato. Le sue
responsabilità non comprendono la scoperta di nuove opportunità di profitto
o qualsiasi altra attività volta a produrre innovazioni; inoltre la perfetta
informazione non permette l’esistenza di imprenditori migliori di altri, che
siano cioè in grado di ottenere condizioni più vantaggiose nel mercato.
Tuttavia non è vero dire che l’impresa non è soggetta a nessun tipo di
incertezza, in quanto gli stessi neoclassici sostengono che il concetto di imprenditori tutti uguali è soltanto una finzione per rendere più semplice la
modellistica. In questo contesto se si considerasse l’esistenza di aleatorietà,
questa potrebbe essere eliminata dalla perfetta informazione, cioè dalla possibilità per gli imprenditori di conoscere tutte le caratteristiche degli eventi
che li potrebbero riguardare in modo da poter decidere la miglior strategia da
adottare. Ma le informazioni possono avere un costo e l’imprenditore sceglierà di non usufruirne più nel momento in cui la spesa generata sarà superiore
ai benefici creati.
Pertanto in Colombatto (2001) si sostiene che nell’ambito neoclassico è
possibile ottenere imprenditori e imprese diversi tra loro quando almeno una
delle seguenti ipotesi sia soddisfatta:
• gli imprenditori hanno una diversa percezione riguardo al beneficio generato dall’acquisto dell’informazione, pertanto le loro conoscenze si
distingueranno per contenuto e dimensione;
• a parità di spesa corrispondono insiemi di informazione distinti; in
questo caso gli imprenditori scelgono funzioni di produzione diverse
a seconda dell’informazione da loro posseduta.
Inoltre possono esistere elementi di incertezza legati anche alle risorse
49
interne all’azienda che, secondo l’impostazione neoclassica, possono essere
eliminati con l’acquisto di ulteriori informazioni.
Perciò si può concludere che l’imprenditore neoclassico è soggetto a due
forme di rischio, il rischio interno, che riguarda le variabili interne all’azienda, e il rischio esterno, che si riferisce alle variabili esogene.
L’idea di equilibrio della teoria neoclassica prevede il conseguimento di
profitti nulli sia nel caso di prodotti omogenei sia in presenza di prodotti
differenziati; in questo secondo caso l’azzeramento dei profitti è provocato
dall’entrata nel mercato di nuove imprese che, avendo notato la possibilità
di conseguire utili, cercano di cogliere le occasioni di profitto.
Ma non è sempre vero che i profitti dell’impresa neoclassica sono nulli,
perché se sono soddisfatte le ipotesi di incertezza sopra descritte è possibile
che esistano imprenditori migliori di altri che siano in grado di conseguire
profitti positivi anche in mercato concorrenziale. Tuttavia i profitti saranno
annullati con il passare del tempo, quando gli altri imprenditori imiteranno
le scelte del migliore, perciò nel medio-lungo termine soltanto delle variazioni
nelle variabili esogene possono causare differenziazioni tra le imprese.
Considerato in questo modo, il lungo periodo non è visto come un intervallo temporale esteso, ma come somma di più brevi periodi (Colombatto, 2001)
in cui possono avvenire dei cambiamenti che modificano l’assetto economico
generale.
3.2
La Scuola Austriaca
La Scuola Austriaca ha profondamente criticato la visione neoclassica dell’economia di mercato. Infatti, in contrasto con le assunzioni neoclassiche di
completa informazione e perfetto equilibrio, questa scuola di pensiero sostiene
che il sistema economico si trova perennemente in situazioni di disequilibrio,
50
dal momento che gli agenti operano in situazioni di incertezza e non conoscono tutti gli elementi dell’ambiente esterno che possono avere influenza su
di loro.
Il concetto di studio dell’economia secondo Mises, uno dei maggiori esponenti della Scuola Austriaca, è il seguente:
lo studio dell’economia non consiste nell’esame delle condizioni di
ottimo; bensì nell’analisi delle possibilità, in condizioni di incertezza, di allentare i vincoli tipici dell’attività economica − la scarsità delle risorse a disposizione dei produttori − e di accrescere la
soddisfazione dei consumatori, aumentando il loro potere d’acquisto e offrendo loro l’opportunità di acquistare nuovi beni e servizi,
in grado di soddisfare meglio le loro esigenze. (Colombatto, 2001,
14-15)
Secondo questa impostazione l’importanza dell’economia di mercato sta
nella capacità di creare le condizioni per cui gli agenti, o imprenditori, si
impegnino a superare i vincoli imposti dalle funzioni di produzione tramite
le innovazioni o con la ricerca di nuove opportunità, in modo da raggiungere
nuovi mercati e diversi tipi di domanda.
Secondo gli Austriaci l’attività imprenditoriale coincide con l’azione umana. Il significato etimologico della parola ‘‘imprenditore” illustrato nell’introduzione a questo capitolo aiuta a comprendere che, secondo la Scuola Austriaca, la sua attività consiste nel percepire e scoprire nuove opportunità nel
mercato e comportarsi in modo da ottenere un profitto.
L’attività imprenditoriale è un processo di apprendimento continuo, grazie alle scoperte degli agenti che generano nuove informazioni e nuove conoscenze; secondo la teoria Austriaca la conoscenza ha determinate caratteristiche (Huerta De Soto, 2003):
• è di tipo pratico;
51
• è esclusiva e dispersa nella mente di tutti gli uomini;
• è tacita e non articolabile;
• è trasmissibile.
La conoscenza imprenditoriale è definita pratica perché non è rappresentabile in modo formale, ad esempio con un modello matematico; la sua
principale caratteristica è che rappresenta tutte le informazioni che un agente considera importanti ai fini di una situazione in cui si trova. È possibile
acquisire nuove conoscenze attraverso concrete azioni umane.
Inoltre le conoscenze sono considerate esclusive perché il modo in cui la
mente degli uomini assimila e interpreta le informazioni è strettamente personale e varia da una persona all’altra. Perciò gli agenti che svolgono la
funzione di imprenditore lo fanno in modo assolutamente personale ed irripetibile, perché le decisioni adottate dipendono dalla loro personale visione
del mondo e dall’insieme di informazioni che non possono essere replicate da
nessun altro.
La conoscenza ha anche la caratteristica di essere dispersa, perché non
rappresenta un complesso di informazioni prestabilite e offerte alla comunità
nello stesso modo, ma è ottenibile da diverse fonti, quali, ad esempio, le
statistiche, i media o i libri.
L’ultima peculiarità della conoscenza è il fatto di essere tacita, in quanto
l’agente sa come effettuare determinate azioni, ma non conosce tutte le parti
e le caratteristiche di ciò che sta facendo; per comprendere meglio questa
caratteristica si riporta un esempio di Polanyi descritto in Huerta De Soto
(2003, 38):
È anche possibile citare, rifacendosi a Polanyi, l’esempio di
quella persona che impara ad andare in bicicletta cercando di
52
mantenere l’equilibrio muovendo il manubrio verso il lato dal quale sta per cadere, causando in tal modo una forza centrifuga che
tende a mantenerlo in equilibrio. Tutto ciò senza che nessun ciclista sia cosciente né conosca i principî fisici sui quali si basa la
sua abilità. Al contrario ciò che il ciclista utilizza è il suo ‘‘senso
di equilibrio” che gli indica, in qualche modo, come comportarsi
in ogni momento per non cadere.
È possibile comprendere il principio di conoscenza tacita prendendo come
esempio una sua manifestazione, l’intuizione, che è definita come ‘‘conoscenza
immediata delle cose ottenuta mediante una visione diretta di esse”; un’intuizione è difficile da spiegare agli altri individui, ed è per questo che la
conoscenza imprenditoriale è anche non articolabile.
Altri esempi di conoscenza tacita sono rappresentati dalle abitudini, dalle
tradizioni e dalle norme giuridiche e morali, a cui gli individui si adeguano
senza essere in grado di spiegare il ruolo che queste norme hanno nei processi
sociali in cui intervengono.
3.2.1
L’attività imprenditoriale
L’attività imprenditoriale è creativa, perché non comporta nessun costo per
la sua esecuzione e origina dei benefici che nascono dal nulla, che sono detti
benefici imprenditoriali puri.
Ogni atto imprenditoriale comporta tre effetti: crea informazioni nuove
che precedentemente non esistevano, permette la trasmissione delle informazioni sul mercato e, infine, fa sì che gli agenti imparino a comportarsi in
funzione delle necessità degli altri.
53
Creazione delle informazioni
Un’azione imprenditoriale consiste nella scoperta, da parte di un agente economico, di un’occasione di profitto sul mercato; grazie a questa scoperta si ha
la creazione dal nulla di una nuova informazione, che consiste semplicemente
nella conoscenza dell’esistenza dell’opportunità in questione.
La creazione di conoscenza può coinvolgere anche più di un solo soggetto,
infatti se si considera un’operazione di arbitraggio, come illustrato in Huerta De Soto (2003), gli agenti che apprendono nuove informazioni sono tre:
l’arbitraggista e i due soggetti da lui coinvolti. L’arbitraggista si rende conto
della possibilità di acquistare un bene ad un certo prezzo e rivenderlo o ad
uno superiore; il soggetto che vende impara che il suo bene ha un valore di
mercato maggiore di quello che gli era stato dato erroneamente; infine il soggetto che compra apprende che sul mercato esiste il bene di cui aveva bisogno
e grazie ad esso può intraprendere nuove iniziative.
La trasmissione delle informazioni
La creazione di informazioni comporta la sua immediata trasmissione nel
mercato.
Occorre ricordare che le informazioni, poiché sono percepite e trasmesse
dagli individui, non possono essere divise dallo scopritore e circolare indipendentemente. Si può perciò concludere che la trasmissione delle informazioni
nella società è tacita e soggettiva, cioè esse sono perfettamente comprensibili
a chi le diffonde, ma potrebbero non esserlo per tutti gli altri agenti presenti
sul mercato.
Il coordinamento
Grazie alle nuove informazioni gli agenti imparano ad agire in modo coordinato, modificando le loro attività in funzione dei bisogni degli altri; inoltre
54
apprendono senza rendersi conto e in un contesto in cui ognuno cerca di
conseguire i propri obiettivi.
Si può concludere che l’attività imprenditoriale è la funzione sociale per
eccellenza, perché rende possibile la vita degli agenti nella società adattando
e coordinando continuamente il loro comportamento.
Il processo di coordinamento sociale originato dall’attività imprenditoriale non si ferma mai, perché le informazioni che sono create modificano la
percezione degli obiettivi e dei mezzi degli altri imprenditori e creano nuove
opportunità ripristinando perciò il ciclo.
3.2.2
La competizione
L’attività imprenditoriale è per definizione competitiva, in quanto gli agenti
cercano continuamente nuove opportunità di profitto nei mercati per affermarsi nella società.
La competizione è pertanto intesa come un processo dinamico di rivalità,
in cui tutti gli imprenditori cercano di prevalere sugli altri, e non come il
modello di concorrenza perfetta in cui tutti vendono allo stesso prezzo.
3.3
L’imprenditore di Kirzner
Israel M. Kirzner, allievo di Mises, sviluppò notevolmente l’idea della funzione imprenditoriale della Scuola Austriaca.
Secondo Kirzner l’imprenditore è colui che è in grado di trovare occasioni
di profitto nei mercati e di trasformarle in fonte di reddito per se stesso e per
la comunità.
L’imprenditore kirzneriano cerca nel mercato imperfezioni che si possano
tradurre in attività fruttifere, ma la sua attività non si manifesta in un’assidua indagine degli errori compiuti dai rivali o delle occasioni da loro manca-
55
te, bensì in una costante attenzione dell’ambiente che lo circonda; infatti in
Kirzner (1997) si precisa che l’attività imprenditoriale consiste nel guardare
all’orizzonte senza sapere cosa si stia cercando e senza attuare una particolare
tecnica di ricerca, in attesa di sfruttare le scoperte che si presenteranno.
Nella visione kirzneriana e austriaca l’imprenditore esiste nel solo caso in
cui all’interno del mercato vi siano situazioni di disequilibrio o imperfezioni
di varia natura, grazie alle quali è possibile la presenza di occasioni di profitto, che sono viste come un segnale di vitalità imprenditoriale, di crescita
e miglioramento per il benessere collettivo. Pertanto quanto più è intenso lo
squilibrio nei mercati, tanto maggiori sono le opportunità di profitto per gli
agenti economici.
Il profitto è considerato in una nuova prospettiva, non è più il compenso per le capacità organizzative, perché questi incarichi non competono all’imprenditore, ma all’amministratore. Il profitto remunera la capacità dell’imprenditore di cogliere le opportunità di miglioramento prima ancora che
queste siano realizzate all’interno dell’azienda; anche se il guadagno si concretizza nel momento in cui si realizza l’attività nell’impresa, questo valore è
riferito all’atto precedente dell’imprenditore, alla ‘‘scoperta imprenditoriale”.
La teoria kirzneriana porta anche spunti di originalità alla figura dell’imprenditore delineata dagli Austriaci. Infatti questi ultimi sostengono che un
agente può decidere di dedicare del tempo all’attività imprenditoriale, al contrario Kirzner sottolinea che l’individuazione di occasioni profittevoli avviene
per caso, senza un’azione di ricerca alle spalle; se così non fosse, profitto sarebbe non solo la remunerazione della la scoperta, ma anche del tempo e delle
risorse impiegati nella ricerca.
Da queste osservazioni si può affermare che, secondo Kirzner, chiunque
può essere un imprenditore, in quanto l’unica qualità richiesta è l’alertness,
ossia vivacità, prontezza mentale, senza la necessità di mezzi di produzione.
56
Questa tesi tuttavia può creare alcune perplessità per due principali motivi (Colombatto, 2001). Da un lato, la conoscenza delle caratteristiche del
settore e dei potenziali consumatori può sicuramente costituire un vantaggio
per alcuni imprenditori a sfavore di altri. Dall’altro, se l’imprenditore non ha
una struttura produttiva alla quale appoggiarsi difficilmente vedrà realizzate
le occasioni scoperte nel mercato e pertanto non otterrà nessun profitto.
Pertanto è possibile rivedere la visione di Kirzner sostenendo che, a parità
di alertness, non tutti hanno le stesse possibilità di essere imprenditori di
successo.
3.4
Simon e la razionalità limitata
Herbert A. Simon propone, con le sue teorie, un modo nuovo per analizzare
le scelte fatte nelle organizzazioni capovolgendo le assunzioni neoclassiche
secondo le quali il decisore sceglie sempre la migliore delle possibilità. Lo
studio delle decisioni nelle organizzazioni può essere applicato anche allo
studio delle scelte all’interno delle imprese che, secondo Simon (1985), sono
organizzazioni formali.
La figura dell’imprenditore è studiata introducendo la teoria della razionalità limitata, secondo la quale in certe situazioni non è possibile avere una
conoscenza completa e pertanto le decisioni prese non sono le migliori, ma le
più soddisfacenti in base alle informazioni possedute.
L’idea della bounded rationality nasce dalla consapevolezza che il modello
classico dell’agire razionale non è più in grado di descrivere il comportamento
degli imprenditori, in quanto secondo Simon le decisioni sono prese in un
ambiente in cui è difficile valutare tutte le opzioni e le loro conseguenze
(Egidi, 2003).
Per illustrare il modo in cui i manager prendono le decisioni Simon fece
una serie di studi sui giocatori di scacchi, le cui mosse possono essere compa-
57
rate con le scelte imprenditoriali ma con il vantaggio di essere in un contesto
maggiormente dominabile rispetto a quello dell’impresa. Il giocatore di scacchi deve cercare in modo razionale la soluzione migliore e per fare ciò deve
avere essere in grado di prevedere le conseguenze che ogni spostamento della
pedina potrebbe generare. Tuttavia si pone il seguente problema:
In media, ad ogni data posizione in una partita di scacchi,
corrispondono circa trenta mosse possibili − in cifra tonda, considerando una mossa e le sue risposte, una media di circa 103
continuazioni della posizione data. Quaranta mosse non sono una
stima irragionevole della lunghezza media di una partita. Quindi
ci sarebbero circa 10120 possibilità di svolgimento di una partita di
scacchi. Ovviamente il numero esatto non ha importanza: un numero come 1040 sarebbe meno spettacolare, ma sufficientemente
grande per avallare le nostre conclusioni.
Studi sui processi decisionali degli scacchisti indicano attendibilmente che anche i giocatori forti guardano raramente ad un
centinaio di possibilità − cioè un centinaio di proseguimenti dalla posizione data − nella scelta di una mossa o di una strategia.
Cento è un numero ragionevolmente grande, rispetto ad altri parametri, ma è un po’ più piccolo di 10120 ! Gli scacchisti non prendono in considerazione tutte le strategie possibili scegliendo poi
la migliore, ma ne ipotizzano ed esaminano un numero piuttosto
piccolo, facendo una scelta appena ne trovano una che ritengono
soddisfacente. (Simon, 1985, 263-264)
Da queste righe si comprende come sia difficile per un giocatore di scacchi raggiungere la razionalità nelle decisioni, a causa del grande numero che
sarebbero necessarie. Simon conclude perciò che a maggior ragione la razionalità non è raggiungibile neanche nel mondo reale, perché in questo contesto
58
le variabili da conoscere sono di gran lunga più numerose rispetto a quelle
necessarie per una partita di scacchi.
Le ragioni per cui non è raggiungibile la completa razionalità nella realtà
sono l’incertezza sulle conseguenze che deriveranno dalle decisioni, il grande
numero di possibilità di scelta, le loro informazioni incomplete e la complessità dei calcoli necessari per valutare le diverse opzioni.
Un ulteriore ostacolo è rappresentato dalla difficoltà di previsione, perché
per gli individui può essere difficile descrivere completamente le conseguenze,
dal momento che la mente umana difficilmente è in grado di prevedere tutto
ciò che deriverà da una particolare scelta; questa motivazione emerge anche
dalla lettura dell’analisi di Simon sul gioco degli scacchi.
Per risolvere il problema dell’incompletezza della conoscenza si potrebbe
cercare di capire quali siano le variabili ed i fattori che hanno la maggiore importanza in relazione ad una determinata situazione (Simon, 1958). La scelta
si baserebbe perciò su quell’insieme di fattori e poterebbe essere considerata
razionale nel solo caso in cui non emergessero altri effetti non considerati
legati a quella decisione.
3.4.1
La razionalità procedurale
Simon introduce il concetto di razionalità procedurale nell’ambito dello studio
delle decisioni. Secondo questo principio non si prende più in esame la scelta
finale dell’individuo, ma il processo mentale che conduce ad essa. Un decisore è pertanto definito razionale se il suo comportamento è razionale in senso
procedurale. Il principio della razionalità procedurale è necessaria nel momento in cui si introduce nel modello di scelta l’incertezza, l’apprendimento
e la complessità.
Il processo di scelta segue delle regole che possono essere rappresentate
59
da semplici regole empiriche, o thumb rules, da routines complesse all’interno
dell’organizzazione, o da algoritmi computazionali.
Razionalità limitata e razionalità procedurale sono due aspetti dello stesso concetto (Avvisati, 2003), perché se si accetta l’idea che la razionalità
umana ha dei limiti è necessario introdurre un modello di comportamento
rule-follower, secondo il quale non è importante la scelta finale ma l’iter che
conduce ad essa.
3.4.2
Il processo di scelta
Nei casi in cui non è possibile raggiungere la completa razionalità per effettuare le scelte, il processo di formazione delle decisioni è caratterizzato
da quello che nella teoria dell’organizzazione è definito subgoal identification
(Simon, 1985). Secondo questo principio gli essere umani valutano le decisioni in base ad obiettivi subordinati, la cui formulazione è funzione delle
conoscenze, dell’esperienza e dell’ambiente organizzativo di chi decide.
I punti chiave del processo di scelta sono search e satisficing. La teoria
della ricerca prevede che se il decisore non dispone delle alternative per la
scelta deve cercarle. Durante la ricerca la massimizzazione dell’utilità può
non essere l’obiettivo guida, in quanto il soggetto può decidere un livello di
bontà che deve essere raggiunto dalle possibilità prese in esame; questo modo
di agire è definito statisficing, secondo cui l’individuo si indirizza sulla scelta
che raggiunge il livello di utilità prestabilito.
Con questo metodo è pertanto possibile effettuare delle scelte anche nel
caso in cui non si disponga di informazioni complete.
Questa teoria sovverte il modello classico secondo il quale per effettuare
una decisione è necessaria la completa conoscenza delle alternative e delle
loro conseguenze, modello più rigoroso ma che, come dimostrato da Simon,
non trova riscontro nella realtà.
60
Capitolo 4
jES: java Enterprise Simulator
Il modello java Enterprise Simulator (jES ) è una struttura interamente
basata sulla versione Java di Swarm, con la quale è possibile sviluppare modelli di simulazione di impresa per studiare l’attività di un’azienda reale o
per studiare la nascita e l’evoluzione di imprese ‘‘virtuali”, in una prospettiva
esclusivamente teorica.
Con la piattaforma jES è possibile effettuare lo studio del modo in cui
le scelte complesse sono trattate all’interno delle organizzazioni, in quanto
con esso si possono ricostruire le imprese reali all’interno del computer e
osservare il loro funzionamento durante tutte le fasi produttive. È inoltre
possibile effettuare il confronto tra più modalità organizzative per trovare
quale potrebbe essere la miglior struttura dell’impresa.
La simulazione ad agenti offre un importante strumento di studio della
realtà, tuttavia occorre ricordare che potrebbe essere ‘‘pericoloso” utilizzarla
come base unica su cui poggiare per le scelte aziendali, in quanto i risultati forniscono risposte adatte per il mondo creato all’interno del computer,
che potrebbe essere, e spesso è, diverso da quello reale, nel quale possono
verificarsi eventi diversi da quelli ipotizzati nella simulazione.
61
4. JES: JAVA ENTERPRISE SIMULATOR
4.1
Introduzione all’uso del simulatore
Per comprendere le funzionalità di jES è necessario illustrare il significato
di unità produttiva, ordine e ricetta. L’unità produttiva rappresenta una
struttura, che può essere interna o esterna all’azienda, in grado di eseguire
uno o più passi produttivi. Un ordine è un oggetto che rappresenta un bene
da produrre o un’attività da svolgere; le sue caratteristiche sono descritte
da una ricetta. La ricetta è una sequenza di passi produttivi che devono
essere portati a termine per la produzione di un bene o di un servizio; i passi
produttivi sono espressi da una sequenza di numeri.
Per la rappresentazione della realtà il formalismo jES consente tre differenti descrizioni del mondo:
• la prima, detta WD side (What to Do), è rappresentata dall’elenco
delle attività da svolgere, descritte da ricette che indicano i passi che
le unità produttive devono compiere;
• nella seconda, definita DW side (which is Doing What), si delinea la
struttura produttiva, elencando le unità che possono svolgere i passi
indicati nelle ricette;
• nell’ultima, denominata WDW side (When Doing What), si definisce
la sequenza degli eventi nel tempo.
L’assegnazione delle lavorazioni alle unità durante una simulazione avviene nel seguente modo: le unità che hanno eseguito un passo produttivo
chiedono alle altre unità e a se stesse per sapere quale sia l’unità in grado di eseguire il passo successivo della ricetta, e inviano l’ordine alla prima
unità che risponde. Questo meccanismo si ripete sino ad aver ultimato la
produzione e varia da caso a caso a seconda delle code nelle liste d’attesa
delle unità, dei parametri del modello e di tutte le interazioni che nascono
62
Figura 4.1: Interazioni tra ordini e unità
tra ordini, ricette e unità. Per valutare come agisce l’impresa virtuale in diverse situazioni è possibile effettuare delle modifiche al modello, ad esempio
ipotizzando una riduzione delle unità produttive o un aumento degli ordini
da eseguire, o ancora introducendo nuovi criteri di scelta per valutare quale
potrebbe essere il migliore.
Dai risultati delle interazioni tra ordini e unità che emergono nelle situazioni simulate è possibile studiare i problemi interni alle organizzazioni e
analizzare gli eventuali fenomeni complessi che si creano (Figura 4.1).
4.2
Lo schema ERA
Durante la simulazione gli agenti devono effettuare delle scelte di vario tipo e il meccanismo su cui si basa la decisione è fondato sul formalismo
Environment-Rules-Agents (ERA) illustrato in Gilbert e Terna (2000).
Secondo questo schema, mostrato in Figura 4.2, gli agenti non sono in grado di comunicare direttamente tra loro, ma soltanto attraverso l’ambiente;
63
questo non è obbligatorio, è soltanto un artificio volto a rendere il codice
meno complesso di quello che risulterebbe se gli agenti potessero comunicare
direttamente tra loro.
Figura 4.2: Lo schema ERA
Il comportamento degli agenti del modello è determinato da un oggetto
esterno, un gestore di regole, detto Rule Master. Quest’ultimo può essere
rappresentato da un insieme di regole, da una rete neurale o da un algoritmo genetico; si potrebbe anche scegliere di far operare come Rule Master un
agente umano e ciò permetterebbe di studiare in che modo le persone prendono le decisioni nelle organizzazioni e quali sono le scelte in diverse situazioni
aziendali.
L’oggetto Rule Master è a sua volta collegato all’oggetto Rule Maker, che
ha il compito di creare e modificare le regole su cui si basa il comportamento
degli agenti.
La rigidità della struttura dello schema ERA conduce ad una maggior
64
chiarezza del codice, che può essere visto come un vantaggio per l’utilizzatore finale. Un secondo vantaggio è la possibilità di agire separatamente sui
generatori e sui gestori di regole potendo passare a diversi sistemi di gestori
di regole, per esempio ad algoritmi genetici o a reti neurali.
4.3
Applicazioni a casi aziendali
Sono state e sono tuttora eseguite alcune applicazioni di simulazione di impresa su casi reali. I files utilizzati per la rappresentazione e le simulazioni si
trovano nella cartella appCases/.
Il primo caso (appCases/Case_i ) riguarda un’azienda del settore meccanico, la VIR S.p.A., che produce su larga scala prodotti per lo più simili ma
molto segmentati per quanto riguarda le dimensioni e alcune caratteristiche.
In questa applicazione il problema principale concerne l’assegnazione delle
priorità alle lavorazioni tenendo conto della disponibilità dei macchinari; la
simulazione ad agenti è stata utile per trovare quali sono i cosiddetti ‘‘colli
di bottiglia” legati alla produzione.
Il secondo caso (appCases/Case_ii ) è riferito ad un’azienda che opera
nel settore della moda, la BasicNet S.p.A., che gestisce la propria attività
esclusivamente tramite il web. Lo studio di questo caso è approfondito nei
capitoli che seguono.
Nel terzo caso (appCases/Case_iii ) è analizzata la struttura aziendale
del 118 di Grugliasco, che si occupa del trasporto medico di urgenza.
È in corso lo studio di una nuova versione di jES, chiamato jESopenfoundation, con il quale è possibile, all’interno di un’applicazione chiamata
jESevol, simulare e analizzare la nascita e l’evoluzione delle imprese. Si crea
pertanto un ‘‘sistema evolutivo” in cui da una parte ci sono le cose da fare
e dall’altra chi è in grado di eseguirle; con questo modello è possibile osser-
65
vare in che modo le nuove imprese sopravvivono o scompaiono e come e se
interagiscono tra loro, creando, ad esempio, dei distretti di imprese.
4.4
4.4.1
Il primo formalismo: le cose da fare
Le ricette
Gli ordini che l’impresa virtuale deve eseguire sono descritti nelle ricette
produttive. Una ricetta è composta da una sequenza di passi seguiti dall’indicazione del tempo necessario per l’esecuzione; nella Tabella 4.1 è mostrato
un semplice esempio di ricetta produttiva composta da un solo passo nella
quale n1 indica il passo produttivo da eseguire, ts l’unità di misura temporale, che può essere il secondo (second), l’ora (hour) o il giorno (day), e m1
rappresenta la quantità di tempo necessaria per l’esecuzione dell’ordine.
n1 ts
m1
Tabella 4.1: Esempio di ricetta produttiva
4.4.2
I layer
I layer possono essere definiti come delle ‘‘etichette” che contraddistinguono
prodotti simili tra loro ma che sono trattati in modo indipendente tra loro
dal simulatore; l’utilizzo dei layer all’interno del simulatore introduce la possibilità di differenziare due ordini associati ad una stessa ricetta produttiva
ma con caratteristiche qualitative diverse.
Ad esempio, se si considera un’impresa che opera nel settore della moda,
le T-shirt possono essere considerate un prodotto omogeneo se si guarda il
processo di creazione, ma sono diverse se si va a vedere dal punto di vista delle
collezioni; in questo caso due magliette appartenenti a collezioni diverse sono
66
considerate prodotti distinti tra loro. I layer sono utili per operare questa
distinzione nell’impresa simulata e il loro utilizzo è automatico all’interno di
jES.
Il numero di layer utilizzati è indicato dal parametro della simulazione
totalLayerNumber. Il numero di layer è pari a (totalLayerN umber − 1); se
il parametro è impostato su 1 significa che non si usano layer durante la
simulazione.
L’assegnazione degli ordini ai layer è effettuata dall’utente nel momento
in cui crea il file recipeData/orderSequence.xls 1 , che contiene il calendario
delle cose che devono essere fatte dall’impresa.
4.4.3
I batch
In alcune situazioni aziendali non è realistico considerare la produzione come
una serie di processi indipendenti tra loro, pertanto è più corretto ragionare
in termini di gruppi di prodotti uguali tra loro.
Sequential batch
Un processo sequential batch esegue contemporaneamente un insieme di ordini uguali; può essere impiegato per lavorazioni che richiedono un tempo
molto ridotto per essere portate a termine, perciò è più realistico considerare
che la loro produzione avvenga solo quando c’è un certo numero di ordini in
attesa.
Nella Tabella 4.2 è mostrato un esempio di sequential batch: l’unità che
deve svolgere il passo n1 deve attendere che b1 ordini simili siano arrivati
nella sua waiting list prima di iniziare la lavorazione; il tempo necessario
per la realizzazione del passo è pari a m1, mentre il tempo di produzione di
ciascun ordine è uguale a
1
m1
.
b1
Per maggiori chiarimenti su questo file vedere il paragrafo 4.6
67
n1 ts m1 \ b1
Tabella 4.2: Sequential batch
Stand alone batch
Un processo stand alone batch produce contemporaneamente un insieme di
ordini ed è utilizzato, ad esempio, nel caso di un approvvigionamento esterno
di semilavorati.
La ricetta (Tabella 4.3) contenente il processo deve essere composta di
due parti: lo stand alone batch e l’indicazione della endUnit 2 ; con endUnit si intende un magazzino nel quale vengono riposti i semilavorati quando non vengono utilizzati. Nell’esempio che segue, il passo n1 produce b1
semilavorati nel tempo m1 e li colloca nell’endUnit c1.
n1 ts m1 / b1
e c1
Tabella 4.3: Stand alone batch e indicazione dell’endUnit
4.4.4
I procurement
Il procurement è un passo che procura semilavorati, prodotti internamente
o esternamente all’azienda. Nel caso di semilavorati provenienti da fornitori
esterni, i procurement sono considerati come ‘‘black boxes’’, senza indagare
sul modo in cui vengono prodotti. Se, al contrario, sono prodotti all’interno
dell’azienda, la loro realizzazione può essere descritta in un modo più o meno
dettagliato con una ricetta composta di un solo passo o con uno stand alone
batch.
La sintassi dei procurement è la seguente:
il passo m1 prima della sua realizzazione richiede una fase di approvvigionamento nella quale vengono cercati semilavorati in k endUnit che han2
Per maggiori dettagli: paragrafo 4.5.2
68
p k c1 ... ck n1 ts m1
Tabella 4.4: Procurement
no codice c1 ... ck; nella sintassi del procurement l’indicazione della p è
obbligatoria.
4.4.5
Il processo OR
Grazie al processo or è possibile creare delle situazioni in cui l’azienda simulata si trovi a dover effettuare delle scelte su come operare. Ad esempio,
potrebbe essere possibile che per l’approvvigionamento di uno stesso semilavorato l’impresa decida una volta di produrlo internamente e la volta successiva decida invece di rivolgersi ad un fornitore esterno, oppure può avvenire
che per la produzione di uno stesso prodotto si possano usare due diversi
metodi di lavorazione, pertanto l’azienda sceglierà di volta in volta quale
utilizzare.
Per inserire una scelta tra due o più opportunità all’interno delle ricette
si usa, come nel formalismo del linguaggio C, il simbolo || seguito dalle alternative, come nella Tabella 4.5, tenendo presente che l’ultima ramificazione
deve iniziare con la notazione ||0. Nel caso mostrato l’impresa, dopo aver
eseguito il passo n1, può scegliere se eseguire il passo n2 o il passo n12 o n81.
n1 ts m1 ||1 n2 ts m2 ||2 n12 ts m12 ||0 n81 ts m81
Tabella 4.5: Processo or
Le possibilità di scelta tra le diverse ramificazioni dipende dal valore
assunto dal parametro orCriterion, che può variare tra 0 e 5:
• 0 significa che si eseguono tutte le alternative (utile solo nelle fasi di
test del simulatore);
69
• 1 per scegliere sempre il primo ramo;
• 2 per scegliere sempre il secondo ramo;
• 3 per una scelta effettuata in modo casuale;
• 4 nel caso in cui si scelga l’alternativa il cui primo passo ha la minor
lista d’attesa;
• 5 se la scelta del branch è basata sul risultato di un passo computazionale3
Il secondo formalismo: chi fa cosa
4.5
4.5.1
Le unità produttive
L’unità produttiva è una struttura aziendale in grado di eseguire uno o più
passi di una ricetta. Le unità sono semplici se sono in grado di eseguire solo
un passo, complesse se ne possono eseguire più di uno.
Unità semplici
Le unità produttive semplici sono elencate nel file unitData/unitBasicData.txt, che si presenta come mostrato in Figura 4.3, nel quale sono indicate,
per ciascuna unità, le seguenti informazioni:
• il numero dell’unità produttiva presa in considerazione;
• il parametro useWarehouse. Se è impostato su 1, l’unità produce magazzino in modalità stand alone, cioè nel momento in cui non è chiamata
ad operare da una ricetta; se ha valore 0 non produce magazzini;
• il numero del passo produttivo che è in grado di eseguire;
3
Per maggiori dettagli: paragrafo 4.7.2
70
• il valore dei costi fissi per ogni unità di tempo;
• il valore dei costi variabili per ogni unità di tempo.
Figura 4.3: File unitData/unitBasicData.txt
Unità complesse
Le unità complesse sono in grado di eseguire più di un passo produttivo;
nel file unitData/unitBasicData.txt sono indicate con uno 0 nella colonna
corrispondente al passo che svolgono; esempi di unità complesse sono l’unità
2 e 4 nella Figura 4.3).
Queste unità sono descritte in un foglio Excel, nel quale sono indicati il
numero di fasi che possono svolgere, il codice della fase, i loro corrispondenti
costi fissi e variabili, e l’indicazione se producono magazzini in caso di assenza
di attività.
4.5.2
Le endUnit
Le endUnit rappresentano dei magazzini in cui sono riposti i semilavorati o
i prodotti finiti e hanno lo stesso codice della componente che contengono;
sono elencate nel file unitData/endUnitList.txt. Nelle ricette le endUnit sono
indicate con una e che precede il loro codice identificativo.
Le endUnit possono essere layer sensitive, se indicate con un numero
positivo, o layer insensitive, se indicate con numero negativo; nel primo caso
71
si creano tante endUnit quanti sono i layer e i prodotti saranno immagazzinati
nella endUnit avente il suo stesso layer.
4.5.3
La scelta delle unità
Nel caso che più unità siano in grado di eseguire lo stesso passo il simulatore
deve scegliere quale di queste dovrà effettuare la lavorazione. Il metodo di
scelta è indicato dal parametro unitCriterion e può essere:
0, se si sceglie la prima unità disponibile seguendo l’ordine del file unitData/unitBasicData.txt;
1, se la scelta è effettuata in modo casuale;
2, se è scelta l’unità con la minore lista d’attesa.
4.5.4
La trasmissione delle informazioni
Un’unità può inviare informazioni riguardanti un ordine all’unità successiva
secondo l’ordine della ricetta; lo scambio di informazioni è possibile se il parametro useNewses è impostato su true. Questo aspetto è molto interessante
nel corso di una simulazione, in quanto è possibile osservare quali interazioni
si creano tra le unità in diverse situazioni aziendali e che tipo di fenomeni
complessi possono emergere.
Un’unità può inviare informazioni ad un’altra nel solo caso in cui siano
legate nella matrice presente nel file unitData/informationFlowMatrix.txt; le
righe indicano le unità che inviano le informazioni e le colonne da quelle che
le ricevono. Se due unità sono legate dal valore 1 si scambiano informazioni,
in caso contrario sono contrassegnate con 0; i valori sulla diagonale principale
della matrice non sono da tenere in considerazione, in quanto le unità non
scambiano informazioni con loro stesse.
72
4.6
Il terzo formalismo: quando fare cosa
Il terzo formalismo è alla base della sequenza degli eventi: descrive degli
ordini da eseguire, contenenti le ricette, e la sequenza in cui questi ordini
devono essere eseguiti.
L’elenco delle ricette è contenuto nel file recipeData/recipes.xls, in cui,
per ogni ricetta è indicato nel seguente ordine:
• il nome della ricetta;
• il numero identificativo;
• il ‘‘corpo’’ della ricetta;
• un punto e virgola che indica la fine della ricetta.
Tutti gli elementi della ricetta devono essere scritti uno per ogni cella del
foglio di lavoro.
La sequenza con cui devono essere eseguiti gli ordini è contenuta nel file
recipeData/orderSequence.xls. Ciascun blocco del file descrive gli eventi che
si verificano in un tick della simulazione e si conclude con un punto e virgola
che indica che sono finite le attività da compiere in quel tick. Ogni blocco è
composto dai seguenti elementi:
• numero del tick;
• la lettera l, che sta per layer, seguita dal numero di layer corrispondente;
• numero della ricetta che deve essere lanciata;
• il segno ‘‘*’’;
• il numero di volte che deve essere eseguita la ricetta.
73
74
Se ad un tick non accade nulla, nel calendario della simulazione si indica
il numero del tick seguito da un punto e virgola. La sintassi del file recipeData/orderSequence.xls è mostrata in Tabella 4.6; al tick 1 non accade nulla,
mentre al secondo deve essere lanciata la ricetta 101 con layer 5 per 25 volte.
1
;
2
l
5
101
* 25
;
Tabella 4.6: recipeData/orderSequence.xls
4.7
Le capacità computazionali
jES ha delle capacità computazionali che possono essere associate ai passi
delle ricette; il loro scopo è l’esecuzione di operazioni immateriali, ad esempio
previsioni, aste per selezionare gli approvvigionamenti e valutazioni di diverso
tipo.
I passi computazionali utilizzano i dati contenuti all’interno delle matrici
di memoria, che sono elencate nel file unitData/memoryMatrixes.txt mostrato
in Figura 4.4, e possono essere sensibili o no ai layer; se sono layer insensitive
sono indicate con un numero negativo, in modo analogo a quanto accade per
le endUnit. Nel file unitData/memoryMatrixes.txt sono indicati il numero
delle memoryMatrix ed i numeri di righe e di colonne di ciascuna. Occorre
ricordare che per usare le memoryMatrix si deve aggiornare il parametro della
simulazione totalMemoryMatrixNumber, che indica il numero delle matrici di
memoria usate durante la simulazione.
Per indicare che il passo di una ricetta richiede l’utilizzo di una computazione occorre usare il formalismo mostrato in Tabella 4.7, nel quale c è
obbligatorio e indica che si deve utilizzare un passo computazionale, code
rappresenta il codice del passo usato (che per convenzione può andare da
1001 a 1999), n esprime il numero di matrici di memoria che si intendono
Figura 4.4: File unitData/memoryMatrixes.txt
usare e a1 ... an i loro numeri, che si possono trovare nel file unitData/memoryMatrixes.txt. Pertanto il passo in Tabella 4.7 si può leggere nel seguente
modo: il passo n1 necessita di una computazione del metodo code che usa n
matrici numerate a1 ... an.
c code n a1 ... an n1 ts m1
Tabella 4.7: Uso di passi computazionali
Per inserire nuove capacità computazionali al simulatore è necessario modificare il file ComputationalAssembler.java, che eredita i suoi metodi di base
dalla classe ComputationalAssemblerBasic; entrambi i files si trovano nella
cartella src/ ed il ComputationalAssembler.java non contiene alcun metodo.
Nel momento in cui si aggiungono nuovi metodi alla classe ComputationalAssembler occorre spostare il file nella cartella principale, in modo che sia
visibile al comando make durante la compilazione.
I metodi seguenti sono quelli che i passi computazionali ereditano dalla
classe ComputationalAssemblerBasic e che consentono loro di interagire con
le matrici di memoria:
• getEmpty(layer, (int) row, (int) col), restituisce vero o falso a seconda che
la casella della memoryMatrix considerata sia, rispettivamente, vuota
o piena;
• setEmpty(layer, (int) row, (int) col), cancella il contenuto della casella
della matrice;
75
• getValue(layer, (int) row, (int) col), legge il valore contenuto nella riga e
colonna indicate della memoryMatrix;
• setValue(layer, (int) row, (int) col, (double) value) o setValue(layer, (int)
row, (int) col, (float) value), scrive un valore all’interno della casella
della matrice presa in considerazione.
4.7.1
Un semplice esempio
Si ipotizzi che durante la simulazione si presenti la seguente ricetta, composta
di un solo passo:
c 1998 1 25 7 s 4 ;
ciò significa che il passo 7 impiega 4 secondi per la sua esecuzione e ha
bisogno del passo computazionale 1998 che usa una matrice, la numero 25.
Il passo computazionale c1998, nel momento in cui viene chiamato ad
operare, legge il numero della matrice di memoria nella posizione 0, cioè la
prima posizione, con il metodo getMemoryMatrixAddress, e assegna l’indirizzo
della matrice alla variabile mm di tipo MemoryMatrix; in seguito controlla il
layer della matrice con il metodo getOrderLayer.
Il compito di questo passo computazionale è scrivere 1 nella riga 0 e
colonna 0 della matrice mm ed a tal fine utilizza il metodo setValue.
Infine, il passo computazionale è impostato su done. Questa operazione
è molto importante, perché in caso contrario l’ordine rimane in sospeso e il
passo successivo della ricetta non può essere eseguito; il passo computazionale sarà ripetuto in ogni ciclo di simulazione, fino a quando la variabile done
sarà impostata true.
76
77
Listing 4.1: Esempio di passo computazionale
¨
p u b l i c v o i d c1998 ( )
{
mm = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
getMemoryMatrixAddress ( 0 ) ;
layer = pendingComputationalSpecificationSet .
getOrderLayer ( ) ;
mm. s e t V a l u e ( l a y e r , 0 , 0 , 1 . 0 ) ;
done
= true ;
} // end c1998
§

4.7.2
La matrice orMemoryMatrix
Come accennato nel paragrafo 4.4.5, se il parametro orCriterion è uguale a 5
la scelta del ramo del processo or è effettuata grazie alle capacità computazionali del simulatore. Infatti in questo caso il ramo da scegliere è cercato
nella prima colonna di una matrice di memoria, che è individuata mediante
il parametro orMemoryMatrix.
Il contenuto della orMatrix può essere modificato dai passi computazionali
ed è uno strumento utile per aumentare la casualità all’interno dell’impresa
simulata.
4.7.3
Le ricette che lanciano ricette
Un ulteriore utilizzo delle capacità computazionali del simulatore è legato alla
presenza di ‘‘ricette che lanciano altre ricette’’. Questa potenzialità discende
dal fatto che durante la simulazione può accadere che, durante l’esecuzione di
una ricetta, contemporaneamente debba essere effettuata una lavorazione che
¦
richiede l’intervento di un’altra ricetta, oppure che una ricetta debba valutare
se eseguire o no una lavorazione e, in caso affermativo, avvii l’operazione
lanciando un’altra ricetta produttiva.
Questa funzione speciale è assolta da due passi computazionali presenti
nella classe ComputationalAssemblerBasic, il C1001 e il C1002. Per conoscere quali sono le ricette che devono essere lanciate si utilizza un file
di testo, recipeData/recipesFromRecipes.txt, nel quale l’utente scrive il loro
numero, ciascuno separato da uno spazio vuoto; in seguito il passo computazionale C1001 legge il contenuto di questo file ed inserisce ogni numero in una
memoryMatrix nella posizione (0, 0). Il lancio delle ricette è effettuato dal
passo computazionale C1002, che legge nella memoryMatrix il numero della
ricetta e lo invia al metodo distill della classe OrderDistiller, che si occupa di
avviare l’esecuzione della ricetta.
Ci sono due restrizioni nell’uso di questa funzionalità:
• non possono essere lanciate più di 10 ricette, anche se è possibile
modificare questo limite nel ComputationalAssemblerBasic.java;
• è consentito il lancio di un massimo di 1.000 ricette nello stesso tick
della simulazione; anche questo vincolo è modificabile nel file OrderDistiller.java.
La sintassi dei passi computazionali sopra descritti è mostrata nella Tabella 4.8. In questo esempio il passo C1001 richiede tre matrici, le numero
10, 20, 30; il passo produttivo 100 è fittizio, ha il solo scopo di permettere
l’esecuzione della computazione. Il passo C1002 richiede la sola matrice 20,
nella quale è contenuto il numero della ricetta che deve essere lanciata.
78
c 1001 3 10 20 30 100 s 1
c 1002 1 20 10 s 2
Tabella 4.8: Ricette che lanciano ricette
4.8
Le capacità contabili
jES è in grado di tenere automaticamente una semplice contabilità secondo
due differenti punti di vista:
• nel primo caso ogni prodotto è caricato dei costi fissi e variabili relativi
alle unità che sono state coinvolte nella produzione;
• nella seconda visione si contabilizzano i costi per unità produttiva; per
le unità inattive sono considerati solo i costi fissi.
I costi sono contabilizzati ad ogni tick dell’orologio della simulazione.
Per quanto riguarda i ricavi, sono calcolati dal simulatore applicando,
alternativamente, un margine di ricarico ad ogni costo sostenuto dall’azienda
oppure ad ogni passo produttivo eseguito. Il mark-up è pertanto definito da
un valore, detto v, che risulta dalla seguente somma:
v = [numeroDiT ick] × revenueP erEachStep
+ [costi] × revenueP erCostU nit
il parametro revenuePerEachStep indica il margine di ricarico da applicare
per ogni passo produttivo eseguito, il parametro revenuePerCostUnit quello
da applicare ad ogni costo sostenuto dall’azienda, che deve essere scritto nel
seguente modo: (1+mark-up). Nel corso della stessa simulazione soltanto
uno dei due parametri può essere diverso da zero.
79
4.8.1
I costi
Nella cartella Costs/ si trovano i seguenti files creati da jES che riportano i
costi relativi all’azienda simulata:
1. nel file totalDailyCosts.txt c’è la somma dei costi fissi e variabili giornalieri. Il giorno è considerato l’unità di tempo della simulazione ed è
definito come un blocco di tick il cui numero è fissato dal parametro
ticksInATimeUnit; pertanto se il parametro è uguale a 10, un giorno
della simulazione sarà composto da 10 tick;
2. in totalCosts.txt è presente la somma cumulata dei costi contabilizzati
nel file precedente;
3. finishedOrderCosts.txt riporta il costo degli ordini conclusi dall’inizio
della simulazione;
4. il file dailySemimanufacturedOrderCosts.txt indica i costi derivanti dalla produzione degli ordini alla fine di uno specifico giorno.
5. in totalInventoryFinancialCosts.txt si trova il costo dei magazzini contabilizzati secondo il criterio stabilito dal parametro inventoryEvaluationCriterion, che può essere 1 se si considerano solo i costi variabili,
2 per tenere conto anche dei costi fissi, 3 per valorizzarli secondo il
parametro v illustrato nel paragrafo precedente.
4.8.2
I ricavi
I ricavi sono contabilizzati nel momento in cui i beni o servizi creati sono
venduti. Nella cartella Revenues/ sono riportati i seguenti files di testo:
1. dailyRevenues.txt, nel quale si trovano i ricavi derivanti dagli ordini
conclusi, valorizzati secondo il parametro v ;
80
2. totalRevenues.txt, in cui si riporta il totale del file precedente dall’inizio
della simulazione;
3. nel file dailyStoredComponentValue.txt si trova il valore dei magazzini,
valorizzati secondo il criterio espresso dal parametro inventoryEvaluation;
4. in dailySemimanufacturedProductRevenues.txt si ha il valore dei semilavorati valorizzati con v.
4.8.3
L’utile
L’utile dell’impresa è riportato, per ogni tick, nel file Benefit/benefit.txt ed è
calcolato nel seguente modo:
totalRevenues
+dailyStoredComponentV alue
+totalSemimanuf acturedRevenues
−totalCosts
−totalInventoryF inancialCosts
4.9
Lanciare una simulazione
Per attivare una simulazione è possibile scegliere se lanciare gli ordini in modo
casuale o utilizzare un calendario preciso.
Nel primo caso gli ordini sono generati usando l’orderGenerator.
Nella seconda ipotesi si utilizza l’orderDistiller; in questo caso è necessario
introdurre il terzo formalismo, When Doing What, che contiene il calendario.
Questa modalità è la più adatta per lo studio di situazioni reali, come ad
esempio gli studi sulle imprese VIR S.p.A. e BasicNet S.p.A., in cui le attività
sono legate ad un preciso calendario.
81
4.9.1
I grafici di una simulazione
Durante una simulazione sono visibili i grafici che forniscono alcune informazioni sulla simulazione stessa e sulle attività che si stanno svolgendo
nell’azienda virtuale.
Il grafico mostrato in Figura 4.5 indica l’andamento generale delle liste
d’attesa delle unità nel corso della simulazione; è composto da tre linee che
rappresentano il livello minimo (linea arancione), massimo (linea gialla) e
medio (linea blu) delle waiting list.
Il grafico in Figura 4.6 indica l’andamento durante la simulazione del
guadagno o della perdita dell’impresa virtuale.
Il grafico della Figura 4.7 indica il rapporto tra l’attuale tempo richiesto
per l’esecuzione degli ordini già completati e il tempo previsto in ciascuna ricetta; un eventuale ritardo rispetto ai tempi previsti potrebbe significare un’errata specificazione dei tempi delle ricette oppure un problema
organizzativo all’interno dell’impresa.
Nel grafico mostrato in Figura 4.8 è indicato, con un istogramma per
ogni unità, il numero di ordini presenti nella waiting list di ciascuna unità.
Sull’ascissa sono rappresentate le unità produttive e sull’ordinata il numero
di ordini nella lista d’attesa.
In Figura 4.9 è mostrato il grafico relativo alle endUnit; sull’asse orizzontale sono indicate le endUnit e sull’asse verticale la quantità di semilavorati
o prodotti finiti presenti in ciascuna di esse.
82
Figura 4.5: Grafico dell’andamento delle liste d’attesa
Figura 4.6: Andamento dell’utile durante la simulazione
83
Figura 4.7: Rapporto
84
totaltime
totallenght
Figura 4.8: Liste d’attesa delle unità dell’impresa virtuale
Figura 4.9: Livello delle endUnit
85
Capitolo 5
L’azienda reale: BasicNet
Il Gruppo BasicNet opera nel settore dell’abbigliamento informale e sportivo,
delle calzature e degli accessori per lo sport e per il tempo libero. I marchi
con cui è presente sul mercato sono Kappa, Robe di Kappa e, da febbraio
2004, K-Way e Superga; il Gruppo possiede inoltre il marchio Jesus Jeans,
per il quale è previsto uno sviluppo nel futuro.
L’attività del gruppo consiste nello sviluppo dei marchi posseduti e nella
diffusione dei prodotti ad essi collegati attraverso una rete di aziende licenziatarie e indipendenti; secondo i dati di maggio 2004, il network dei licenziatari
copre 83 mercati a livello mondiale.
Il gruppo fa capo a BasicNet S.p.A., con sede a Torino, quotata alla Borsa
Italiana nel segmento STAR.
5.1
La storia
Il Gruppo BasicNet nasce nel 1994, quando Football Sport Merchandise S.r.l.
di Marco Boglione rileva dal fallimento il Maglificio Calzificio Torinese, proprietario dei marchi di abbigliamento Kappa, Robe di Kappa e Jesus
Jeans.
86
5. L’AZIENDA REALE: BASICNET
Football Sport Merchandise S.r.l. è fondata nel 1983 e il suo presidente
è Marco Boglione, attuale presidente di BasicNet. La società è la prima in
Italia, e tra le prime in Europa, ad ottenere dalle principali squadre di calcio
la licenza per produrre e distribuire capi d’abbigliamento per il tempo libero
contrassegnato dai loro marchi e segni distintivi.
Nel 1988 Football Sport Merchandise, a fronte di una rilevante crescita
a livello mondiale del mercato dei prodotti contrassegnati dai marchi delle
squadre sportive, costituisce la Basic Merchandise S.r.l.. L’obiettivo di questa nuova società, oggi BasicItalia, è l’ottimizzazione dei processi produttivi
e la distribuzione dei prodotti in alcuni mercati esteri, nonché diventare licenziatario e distributore esclusivo per l’Italia dell’americana Starter Inc., al
tempo leader mondiale di abbigliamento realizzato su licenza delle squadre
delle ‘‘Major Leagues” statunitensi.
Nel 1994, come affermato precedentemente, Football Sport Merchandise
rileva dal curatore fallimentare i marchi, il magazzino e l’immobile di proprietà del Maglificio Calzificio Torinese S.p.A., fondato nel 1916, in cui Marco
Boglione aveva iniziato la sua carriera professionale nel 1976. L’obiettivo
dell’acquisizione è quello di disporre di marchi conosciuti ed affermati per
poter valorizzare nel modo migliore le potenzialità organizzative e commerciali di Football Sport Merchandise nel mercato dell’abbigliamento informale,
sportivo e per il tempo libero.
Nel 1996 il gruppo Ventuno Investimenti, guidato da Alessandro Benetton, diventa nuovo partner strategico del Gruppo BasicNet. Si firmano nuovi
contratti di licenza per i principali mercati europei e si definiscono le strategie per la penetrazione dei marchi nei mercati degli Stati Uniti, dell’Asia e
dell’Africa. In questa occasione Football Sport Merchandise assume la nuova
denominazione sociale di Basic Properties Services S.p.A..
Nel 1997, coerentemente con la strategia di penetrazione del mercato
87
USA, sono acquisite le attività di una piccola azienda americana, fortemente
specializzata nel segmento dell’abbigliamento e delle calzature per il calcio
e con una struttura organizzativa e distributiva adatta a costituire la base
operativa del licenziatario statunitense del Gruppo. Nasce così la Kappa
USA, attualmente controllata da BasicNet. Nel corso dello stesso anno la
controllata Kappa Italia, oggi BasicItalia, avvia la costruzione di un nuovo
complesso immobiliare a Torino destinato ad attività di confezionamento,
magazzino e spedizione.
Nel 1998 ha inizio la ristrutturazione della sede del Gruppo BasicNet a
Torino, che prevede la realizzazione del primo progetto BasicVillage per ospitare, oltre alle attività gestionali del gruppo, anche il nuovo modello di punto
vendita, il Gigastore Kappa. Quest’ultimo rappresenta lo strumento con il
quale il Gruppo si propone di smaltire le rimanenze generate dall’attività
dei licenziatari e, allo stesso tempo, entrare in mercati ad alto potenziale di
consumo, ma a basso potere d’acquisto.
All’inizio del 1999 Basic World N.V., l’azionista di maggioranza relativa,
decide di quotare nella Borsa Italiana le azioni del Gruppo, il cui cespite
principale è rappresentato dai marchi Kappa e Robe di Kappa. Nel giugno del 1999 viene deliberato di far confluire in BasicNet S.p.A. tutte le
partecipazioni delle società attive del Gruppo detenuto da Basic World N.V..
A febbraio 2004 BasicNet, a seguito di una trattativa con Formula Sport
Group, acquisisce il marchio K-Way e diventa licenziatario unico mondiale
del marchio Superga, per un periodo di 14 anni e con un diritto di opzione
per l’acquisto dello stesso. L’acquisto di questi marchi rientra nel piano imprenditoriale di BasicNet, fondato sulla gestione di marchi aventi una buona
tradizione e forti prospettive di sviluppo. Per il marchio K-Way il Gruppo
prevede di sviluppare una strategia distributiva simile a quella di Kappa indirizzata soprattutto ai negozi multimarca di articoli sportivi; per Superga è
88
previsto il raggiungimento dei mercati asiatici e americani mediante accordi
di licenza, mentre quello europeo verrà in larga misura fornito con vendite
dirette organizzate da Kappa Italia, il licenziatario italiano del Gruppo, che
a luglio 2004 ha cambiato la sua ragione sociale ridenominandosi BasicItalia.
5.2
Il business system
Il gruppo BasicNet ha impostato il proprio sviluppo su un modello di impresa
‘‘a rete’’, identificando nel licenziatario il mezzo ideale per la diffusione e la
distribuzione dei propri prodotti nel mondo.
Questo modello di business ha consentito al gruppo di crescere rapidamente e, allo stesso tempo, mantenere una struttura flessibile ed efficiente.
Si presenta infatti come una grande azienda composta di tante piccole imprese collegate tra loro da una piattaforma informatica tramite internet. Alla
capogruppo BasicNet fanno capo tutte le attività strategiche:
• Ricerca e Sviluppo di prodotto;
• Global Marketing;
• sviluppo e coordinamento del network dei licenziatari;
• finanza strategica;
• Information Technology, cioé creazione di sistemi di software per consentire la gestione on line di tutti i processi della catena dell’offerta.
La piattaforma informatica rappresenta uno dei principali investimenti
strategici del Gruppo, al quale è dedicata la massima attenzione; è stata concepita e sviluppata completamente integrata al web, considerato dal Gruppo
lo strumento ideale di comunicazione fra gli elementi che costituiscono il
network.
89
Direttamente collegati con BasicNet vi sono i Sourcing Center, che hanno
il compito di individuare e coordinare le fabbriche a cui affidare la realizzazione dei prodotti. Ai licenziatari è affidata la distribuzione dei prodotti ai
dettaglianti e l’attività di marketing su base locale, secondo le linee guida del
Gruppo; per l’approvvigionamento dei prodotti finiti i licenziatari possono
appoggiarsi ai Sourcing Centers che BasicNet mette loro a disposizione.
Inoltre, il Gruppo BasicNet è anche presente nella vendita diretta al
pubblico con tre modelli di concept store:
• il negozio monomarca RDK, che trova l’ideale collocazione nei centri pedonali e storici cittadini e nelle gallerie dei centri commerciali. Gestito
in franchising, propone una gamma di abbigliamento classico-sportivo
per adulti;
• il Gigastore, grande boutique dei marchi BasicNet. Propone tutto
l’assortimento di sport, jeans e abbigliamento casual;
• lo Spaccio, realizzato in aree non tipicamente commerciali con la caratteristica di proporre un vasto assortimento di stock e convenienza di
prezzo.
La Figura 5.1 mostra il modello di business BasicNet, così strutturato:
1. attività di collaborazione e contatto tra il gruppo BasicNet ed i licenziatari; fase di acquisto del campionario da parte dei licenziatari;
2. realizzazione dei MetaSamples, scelta dei MetaSamples da realizzare come campionario, richiesta delle specifiche tecniche, produzione e
consegna delle merci;
3. richiesta di previsioni di vendita ai licenziatari;
90
Figura 5.1: Rappresentazione del business system di BasicNet
91
4. richiesta ai Sourcing Centers del preventivo per la produzione degli
articoli;
5. raccolta degli ordini delle merci; gli ordini sono passati ai Soucing
Centers;
6. vendita dei prodotti sul mercato.
5.3
La struttura del Gruppo
In testa al Gruppo, come si può notare dalla Figura 5.2, si trova BasicNet.
Accanto alla funzione di capogruppo, gestisce e coordina il network, presidiando direttamente le attività strategiche; inoltre supporta i licenziatari
nella gestione dei contratti di sponsorizzazione più importanti sia attraverso
le proprie strutture sia tramite la controllata Basic Properties.
Figura 5.2: La struttura del Gruppo
BasicNet controlla al 90% Kappa Italia S.p.A., ridenominata a luglio 2004
BasicItalia, che opera come licenziatario per l’Italia per i marchi Kappa, Robe
92
di Kappa, Jesus Jeans e K-Way e come licenziatario europeo per il marchio
Superga; inoltre si presenta come azienda licenziataria per tutti i paesi del
mondo in cui non sono già presenti altri licenziatari. BasicItalia gestisce
anche tutte le iniziative di vendita al dettaglio che fanno capo al Gruppo,
vale a dire i negozi RDK, i Gigastore e gli spaci aziendali.
Basic Village S.p.A., interamente controllata da BasicNet, è la società
immobiliare proprietaria dell’ex stabilimento del Maglificio Calzificio Torinese, ribattezzato Basic Village; la società concede in locazione gli immobili
del Village alle società del Gruppo.
BasicNet controlla interamente anche Basic Properties B.V., che opera
come licenziataria mondiale di Basic Trademark S.A., società proprietaria
dei marchi. La sua attività consiste nel concedere in sub-licenza i diritti
di proprietà intellettuale del Gruppo BasicNet ai diversi licenziatari locali,
amministrare e gestire i contratti di sub-licenza e le royalties da essi derivanti.
La società è titolare di contratti di sponsorizzazione e coordina l’attività di
comunicazione, promozione e marketing globale del Gruppo BasicNet.
LF Basic Ltd è controllata per il 50% da Basic Properties B.V. e per
il 50% da Li & Fung Trading Ltd di Hong Kong, società del gruppo multinazionale Li & Fung. LF Basic controlla a sua volta al 100% LF Basic
Europe S.r.l. di Torino; le due società operano come Sourcing Centers, la
prima prevalentemente per l’area asiatica, la seconda nell’area del bacino del
Mediterraneo.
Basic Properties America Inc., già Kappa USA Inc., ha operato fino al 30
ottobre 2001 come licenziatario del Gruppo negli Stati Uniti; successivamente
le operazioni sono state cedute a terzi, con la sub-licenza dei marchi. Dal
1◦ novembre 2001, dopo aver provveduto a cedere il proprio ramo di attività
operativa alla Kappa USA, opera esclusivamente come sub-licenziante dei
marchi per il mercato statunitense.
93
Kappa Spain Sports S.L., partecipata dal Gruppo BasicNet con una quota
del 30%, opera quale licenziatario per la Spagna.
5.4
Le divisioni dot.com
Il processo produttivo che dalla creazione conduce alla commercializzazione
delle collezioni è suddiviso in numerose fasi, ciascuna delle quali viene portata a termine da una divisione aziendale; queste ultime, nella terminologia
adottata da BasicNet, vengono definite divisioni dot.com, per sottolineare
ancora una volta l’importanza del web all’interno dell’azienda. Le divisioni
dot.com sono descritte qui di seguito.
BasicBiddings.com
Gestisce l’asta per la scelta delle aziende che dovranno produrre gli articoli
per i licenziatari e sceglie le vincitrici per ogni articolo. L’asta è rivolta alle
Trading Company (società esterne al Gruppo) ed ai Sourcing Center (società
gestite in joint-venture dal Gruppo). Nel 2004 le società che partecipano
all’asta sono 5.
BasicCountry.com
Rappresenta l’insieme dei licenziatari legati al gruppo BasicNet. È da sottolineare che i licenziatari non acquistano i loro articoli da BasicNet ma
direttamente dalle fabbriche asiatiche e pagano una commissione per l’intermediazione (7% del fatturato) alle Trading Company.
I licenziatari, ogni tre mesi, devono pagare al Gruppo una somma pari al
10% del loro fatturato per l’insieme dei servizi offerti; di tale somma, un 4%
spetta a World Wide Strategic Advertisement, che ha funzioni di
marketing, un 4% è destinato alla remunerazione dei marchi e il restante 2%
94
va a BasicNet che lo suddivide ulteriormente tra le divisioni dot.com.
Secondo i dati del 2004 esistono circa 35 licenziatari che coprono 83 paesi nel
mondo.
BasicFactory.com
Ha in carico la gestione della produzione; esistono due deadline per gli
ordini di produzione di ogni collezione, a distanza circa di un mese una
dall’altra. I licenziatari possono effettuare gli ordini non appena sul sito
www.basicfactory.com vengono pubblicate le immagini degli articoli che compongono la collezione. Una volta raccolti gli ordini la produzione viene lanciata. Le società che si occupano della produzione, generalmente asiatiche,
sono in continuo contatto con le fabbriche locali e forniscono loro adeguate
garanzie finanziarie.
BasicForecast.com
Si occupa delle previsioni di produzione e vendita interagendo con i licenziatari. Le previsioni sono sostanzialmente l’aggregato delle quantità di probabile
acquisto indicate dai licenziatari in sede di ordine dei MetaSamples.
BasicMarketing.com
Effettua lo studio del marketing globale dei marchi e la supervisione dei
licenziatari.
BasicSamples.com
Svolge l’attività di ideazione e design del campionari, considerata, all’interno dell’azienda, la fase più importante di tutto il processo produttivo. La
vendita del campionario è una delle principali fonti reddituali della divisione.
95
BasicSpecs.com
Determina le specifiche tecniche dei prodotti da consegnare alle Trading Company e ai Sourcing Centers. La divisione agisce in due momenti, la prima
volta prima della produzione del campionario e fornisce alla sartoria incaricata da BasicSamples.com la ‘‘distinta base” degli articoli. In seguito viene
chiamata ad operare prima che le Trading Company e i Sourcing Centers
inizino la produzione e fornisce loro tutte le caratteristiche che gli articoli devono possedere in modo più dettagliato rispetto al precedente. L’obiettivo di
BasicSpecs.com è che diverse fabbriche siano in grado di realizzare prodotti
uguali.
5.5
Il ciclo di produzione
La creazione di una collezione inizia circa un anno prima della sua data di
commercializzazione. L’ideazione e lo sviluppo degli articoli avviene all’interno di BasicSamples, divisione dot.com incaricata dell’attività di ricerca e
sviluppo, design e prototyping; questa fase è considerata la più importante
di di tutta la catena produttiva e culmina con la produzione e commercializzazione del campionario. Le collezioni possono essere di due tipi: General Make-Up (gmu), collezioni proposte interamente da BasicNet, e Special
Make-Up (smu), proposte dai licenziatari; queste ultime sono generalmente più piccole rispetto alle gmu e i licenziatari possono scegliere se avere
l’esclusiva degli articoli o permetterne l’acquisto ad altri licenziatari.
I licenziatari possono visualizzare e acquistare gli articoli sul sito internet di BasicSamples e hanno la possibilità di interagire con i designers e di
inviare commenti relativi agli articoli; i licenziatari possono acquistare anche solo una parte della mega-collezione proposta da BasicSamples, creando
una collezione più piccola personalizzata alle esigenze del mercato in cui si
96
trovano. Secondo i dati di BasicNet del 2002, il 95% degli articoli proposti
da BasicSamples è stato approvato dai licenziatari. Dopo aver ricevuto il
campionario, i licenziatari iniziano l’attività di promozione locale che dura
indicativamente 10 settimane.
Una volta ordinati i campionari, i licenziatari comunicano a BasicForecast
le loro previsioni di vendita; queste informazioni delineano con una buona
approssimazione quella che sarà la produzione per ogni singolo articolo.
L’industrializzazione del prodotto compete a BasicSpecs, che specifica la
distinta base dei singoli capi, in modo da fornire regole comuni a tutti i
produttori sparsi nel mondo.
Dopo la definizione delle specifiche tecniche di produzione degli articoli,
BasicBiddings si rivolge ai Sourcing Centers, gestiti in joint-venture, e alle
Trading Company, esterne al Gruppo, per l’asta di aggiudicazione dei prodotti e quindi alla stesura del listino definitivo, che conterrà il minor prezzo di
produzione offerto durante l’asta per ogni articolo della collezione. I Sourcing
Centers e le Trading Company hanno il compito di individuare e coordinare
le società alle quali affidare la realizzazione dei prodotti.
La fase successiva viene gestita da BasicFactory, che passa alle fabbriche
incaricate della produzione gli ordini dei licenziatari. La produzione richiede
circa quattro mesi di tempo.
Infine, le fabbriche consegnano i prodotti finiti direttamente ai licenziatari, che li distribuiscono ai dettaglianti. Generalmente il prezzo di vendita
all sale degli articoli è pari al prezzo di produzione offerto in fase di asta
moltiplicato per un coefficiente, che viene stabilito da BasicNet, pari a 2.2.
5.6
Le attività di promozione
BasicNet promuove la propria attività e la notorietà dei marchi attraverso
un’importante attività di sponsorizzazione in numerose discipline sportive.
97
Il calcio è lo sport dove il marchio Kappa storicamente è più presente e
oggi vestono questo marchio gli atleti di più di 100 team in tutto il mondo tra
cui il Totteham, Feyenoord, Werder Bremen, Real Betis, Genk, Sampdoria e
Brescia.
Tra gli altri sport, BasicNet è attiva nel rugby, con la Nazionale Italiana
ed il più esclusivo club di Francia, lo Stade Français, e nel ciclismo, con i
campioni del mondo della SAECO e nello sci con la fornitura tecnica a 30 tra
i più importanti sci club europei e con le federazioni nazionali di Argentina
e Messico.
Ulteriori attività dell’azienda torinese riguardano anche il basket, con ben
15 squadre di livello internazionale, il volley, con oltre 20 team in 5 paesi, il
motociclismo, con Honda, e l’hockey su ghiaccio.
A sostegno del marchio Robe di Kappa BasicNet è impegnata nel golf con
la federazione italiana campione d’Europa e con l’abbinamento ai prestigiosi
tornei dell’Italian Open e RDK Ladies Europen tour.
98
Capitolo 6
L’azienda virtuale: Basic_jES
6.1
Prima analisi e possibili sviluppi
L’azienda BasicNet è già stata oggetto di studio in due tesi di laurea, Lamieri
(2002) e Merlo (2003a), nelle quali è stata creata una prima formalizzazione
dell’azienda virtuale, Basic_jES. Con questo lavoro si intende rendere più
vicino alla realtà questo modello di impresa e creare uno strumento che sia
in grado di fornire una buona rappresentazione di una realtà complessa come
quella aziendale.
Con la simulazione è possibile mettere a confronto diversi modelli organizzativi che un’impresa potrebbe adottare e analizzare le caratteristiche di
ognuno per definire quali sarebbero i vantaggi e i problemi derivanti da un
cambiamento all’interno dell’azienda. Tuttavia occorre ricordare che questo metodo non è in grado di includere tutte le peculiarità del mondo reale,
pertanto i risultati della simulazione sono in grado di fornire indicazioni di
massima utili a scopo scientifico ma che devono essere considerate con le
dovute cautele nel caso di applicazioni concrete.
Nell’autunno 2004 è uscita una nuova versione di jES, che incorpora
l’analisi presente in Merlo (2003b), nella quale sono presenti tre diverse
99
6. L’AZIENDA VIRTUALE: BASIC_JES
ricostruzioni del business system dell’azienda:
• nella prima viene descritta l’azienda nel modo in cui realmente opera:
BasicNet non partecipa direttamente al processo produttivo, in quanto
quest’ultimo è attribuito totalmente ai Sourcing Centers. Le principali
fonti di ricavo dell’azienda sono rappresentate dall’incasso delle royalties, pari al 10% del totale degli acquisti effettuati dai licenziatari, e
dalla prestazione dei servizi di assistenza a favore delle altre società del
gruppo;
• nella seconda viene descritta un’ipotetica BasicNet che operi come un’azienda tradizionale producendo i prodotti e vendendoli direttamente ai
licenziatari;
• nel terzo esempio si descrive la BasicNet come un’azienda che faccia
produrre i propri prodotti in outsourcing e li venda direttamente ai
licenziatari.
Nel confronto tra modelli di business presente in Merlo (2003b) è stata
eseguita un’analisi dei costi e ricavi originati da ciascuna tipologia di azienda.
Alle divisioni dot.com sono stati assegnati degli ordini di grandezza di costi
fissi e variabili in base a quanto suggerito dalla dottoressa Bruschi1 ; il termine
‘‘dot.com’’ è utilizzato in BasicNet per riferirsi alle divisioni interne illustrate
nel paragrafo 5.4.
Alle Trading Company sono stati imputati costi fissi e variabili pari a 1, a
titolo di puro esempio, a causa della mancanza di dati che indichino il loro
vero valore dei costi di produzione. Infatti le Trading Company sono esterne
all’azienda e le uniche informazioni che BasicNet ha su esse è il prezzo offerto
nella fase di bidding per la produzione delle collezioni.
1
Direttore Generale dei Sistemi Informativi di BasicNet
100
Dalle simulazioni svolte si è notato che l’andamento dei costi totali è simile nei tre casi, in quanto il peso delle Trading Company, con costi fissi e
variabili pari a 1, è ininfluente sul totale; per ottenere risultati più realistici
occorrerebbe conoscere i costi reali imputabili alle Trading Company. Nel
secondo e terzo caso si nota inoltre, come previsto, che si registrano ricavi
consistenti durante l’intero periodo, a differenza di quanto accade nella situazione reale; questo perché in queste due ricostruzioni l’azienda partecipa
attivamente a tutte le fasi del processo produttivo e vende direttamente le
collezioni ai licenziatari.
Un possibile sviluppo proposto nei precedenti lavori (Lamieri 2002 e Merlo 2003a) riguarda l’approfondimento del confronto tra i diversi modelli di
business, inserendo valori di costo più vicini alla realtà, e in particolare l’analisi di una divisione dot.com, in particolare BasicSamples, considerata la
parte di maggiore interesse dell’intera azienda. Infatti studiando più a fondo
questa divisione dot.com sarebbe possibile definire un calendario più dettagliato della produzione, che nell’analisi di Lamieri (2002) e Merlo (2003a) è
stato solo ipotizzato.
Una seconda indicazione consiste nello studio più approfondito di due importanti momenti del processo produttivo: le aste bandite da BasicNet nei
confronti delle Trading Company, necessarie per stabilire a chi sarà affidata la produzione dei prodotti, e le previsioni eseguite dai licenziatari sulla
base dei MetaSamples proposti da BasicSamples. I MetaSamples sono, secondo la terminologia dell’azienda, le prime bozze dei modelli che verranno
commercializzati in seguito.
6.2
Novità nell’azienda
Nell’incontro del 26/03/2004 la dottoressa Bruschi mi ha informato di alcune
novità che forse verranno realizzate nell’azienda nel prossimo futuro.
101
Entro luglio 2004 il licenziatario italiano Kappa Italia cambierà la ragione sociale in BasicItalia. Il nome attuale era stato utile nel momento della
quotazione dell’azienda nella Borsa Italiana, per dare un punto di riferimento
facilmente riconoscibile agli investitori; l’esigenza di un nuovo nome viene dal
fatto che l’azienda attualmente possiede e commercia diversi marchi: Kappa, Robe di Kappa, Jesus Jeans, K-Way e Superga (gli ultimi due acquisiti
recentemente).
È in fase di studio la possibilità per i Sourcing Centers di assumere un
nuovo ruolo all’interno del gruppo. Attualmente essi propongono, durante la
fase di bidding, un prezzo per la produzione degli articoli di una collezione e in
seguito assegnano la produzione ad altre aziende; queste ultime si occupano
direttamente di consegnare e fatturare ai licenziatari.
La novità consisterebbe nell’affidare ai Sourcing Centers una funzione di
maggiore responsabilità: oltre ad organizzare la produzione delle collezioni
incaricando le aziende dovrebbe consegnare e fatturare la merce ai licenziatari; in questo modo diventerebbero direttamente responsabili del buon fine
della produzione e consegna delle collezioni.
Inoltre attualmente il processo produttivo dell’azienda segue una timetable che specifica le fasi e i relativi tempi necessari per il percorso dei prodotti dalla preparazione dei MetaSamples alla consegna del prodotto finito.
Questa è un’informazione molto utile per il modello, in quanto con queste
nuove indicazioni sarà possibile fare un passo avanti per ottenere una maggior
veridicità della simulazione.
6.3
Le modifiche al modello precedente
Ho effettuato alcune modifiche al modello presente in Lamieri (2002) e Merlo
(2003a) grazie alle nuove informazioni sull’azienda fornite dalla dottoressa
Bruschi e a causa di alcune variazioni nella prassi operativa di BasicNet.
102
Per quanto riguarda le collezioni, attualmente BasicNet non produce più
MegaCollection, collezioni di 300 articoli, ma le suddivide in più collezioni
piccole composte da circa 100-150 articoli; ho pertanto deciso di inserire questa novità nel modello. Inoltre attualmente le collezioni possono essere di
due tipi, General Make-Up (gmu) e Special Make-Up (smu); le prime sono
normali collezioni create da BasicNet, mentre per le seconde è presente la
possibilità per i licenziatari di proporre la creazione di nuovi articoli a BasicSamples, in base alle proprie esigenze o a particolari richieste del mercato.
I nuovi articoli possono essere messi a disposizione di tutti i licenziatari o
possono essere considerati come esclusiva del licenziatario, a seconda della
volontà del proponente. Nel modello descritto qui di seguito non è prevista
la presenza di Special Make-Up.
Ho inserito la possibilità per i licenziatari di effettuare un secondo ordine
ai Sourcing Centers a distanza di circa un mese dal primo ordine. La ragione
di questa opportunità è permettere ai licenziatari di ricevere un certo tipo
di articoli prima di altri; ad esempio, per una collezione primavera-estate i
licenziatari potrebbero decidere di ordinare prima le T-shirts e le canottiere
per averle a disposizione già all’inizio di maggio, e in seguito, con il secondo
ordine, i costumi da bagno per poterli commerciare all’inizio di giugno.
Ho inoltre deciso di simulare 2 anni (600 giorni) di vita di BasicNet, in
cui ogni mese è composto da 25 giorni. Per il calendario delle fasi di ciascuna
collezione mi sono basato sulla scansione reale degli ordini, che viene illustrata
nel prossimo paragrafo.
103
6.4
Analisi del calendario
6.4.1
La time-table di BasicNet
Secondo la time-table che mi ha consegnato la dottoressa Bruschi il processo
produttivo per ciascuna collezione si articola nelle fasi illustrate in seguito.
Dopo l’esecuzione ciascuna di esse deve essere notificata con una e-mail a
BasicNet. Nella prassi di BasicNet le date delle fasi sono stabilite a ritroso,
partendo dalla data in cui si desidera che sia commercializzata la collezione
fino ad arrivare a determinare il momento in cui deve essere creata; in alcuni
casi è possibile che alcune fasi siano saltate o che altre durino di meno, in
modo da accelerare il processo produttivo, a seconda delle esigenze aziendali.
1. Creation: BasicSamples crea i MetaSamples di una collezione.
2. smu Request: uno o più licenziatari propongono nuovi articoli da inserire in una collezione a parte; anche se il numero di articoli proposto è
esiguo, questi vengono inseriti in una collezione a se stante, una Special
Make-Up.
3. Collection Approved/Rejected: se il licenziatario proponente fornisce le garanzie necessarie viene iniziato lo sviluppo della nuova collezione. La principale garanzia che il licenziatario deve dare è il raggiungimento di una quota di acquisti sufficiente per la copertura dei costi
di produzione dell’articolo.
4. Development: rappresenta il periodo di tempo in cui BasicSamples
sviluppa e definisce i MetaSamples.
5. View What is Ready: è il momento in cui i licenziatari vedono i
primi disegni della nuova collezione ed esprimono un parere in merito;
in base alle loro opinioni BasicNet decide se continuare lo sviluppo degli
104
articoli o interromperlo. La maggior parte degli articoli viene in genere
approvato dai licenziatari, infatti le statistiche di BasicNet mostrano
che nel 2002 il 95% degli articoli proposti è stato approvato.
6. Proto Receiving: BasicSamples riceve i prototipi degli articoli della collezione, per essere in grado di effettuare una prima verifica dei
prodotti.
7. BasicSample Buy: BasicSamples vende il campionario ai licenziatari; per la sua realizzazione non viene bandita un’asta tra le Trading
Company, ma viene prodotto direttamente da una sartoria scelta da
BasicSamples.
8. Intermediate Forecast: i licenziatari effettuano una prima previsione degli acquisti per ciascun articolo della collezione. La necessità di
questa previsione è fornire immediatamente a BasicNet un’informazione di massima sui probabili acquisti dei licenziatari; in seguito viene
richiesta una seconda previsione, più attendibile della precedente, dopo
che i licenziatari hanno visionato il campionario.
9. Samples receiving at Licensee Warehouse: i licenziatari ricevono
il campionario.
10. Final Forecast: i licenziatari effettuano la previsione definitiva sugli
acquisti della collezione.
11. Sales Campaign: periodo di tempo di circa un mese nel quale i
licenziatari effettuano la campagna promozionale presso i negozi per
pubblicizzare la nuova collezione e raccogliere gli ordini.
12. Bid: in questa fase BasicBiddings indice l’asta tra i Sourcing Centers
interessati alla produzione della collezione; ciascuno propone un prezzo
105
per la produzione di ogni articolo e viene scelto il Sourcing Center che
offre il prezzo più conveniente per BasicNet, vale a dire il più basso.
13. BasicFactory: la collezione di cui è stato venduto il campionario viene pubblicata sul sito www.basicfactory.com; da questo momento i licenziatari possono ordinare la produzione di ogni articolo al Sourcing
Center che ha vinto l’asta;
14. First Deadline: i licenziatari hanno un mese di tempo per effettuare
il primo ordine di acquisto.
15. Second Deadline: secondo ordine dei licenziatari per gli articoli della
collezione.
16. Deliveries To Shop: periodo in cui può essere venduta la collezione;
la produzione e la consegna dei prodotti richiedono circa quattro mesi
di tempo.
Con le date precise in cui è stata eseguita ciascuna fase è possibile aggiornare il calendario della simulazione inserito nel file orderSequence.xls;
per calcolare il tempo da una fase all’altra (mostrato nella Tabella 6.1)
ho considerato soltanto i giorni lavorativi di una settimana (dal lunedi al
venerdi).
106
Fase
Data
107
Giorni
Giorni
effettivi
lavorativi
dalla fase seguente
dalla fase seguente
Creation
3-set-03
25
18
Development
28-set-03
10
7
View What is Ready
8-ott-03
25
18
Proto Receiving
2-nov-03
22
15
BasicSample Buy
24-nov-03
113
72
Intermediate Forecast
16-mar-04
0
0
Licensee Warehouse
16-mar-04
0
0
Final Forecast
16-mar-04
0
1
Sales Campaign
17-mar-04
15
10
1-apr-04
39
26
BasicFactory
10-mag-04
15
11
First Deadline
25-mag-04
27
18
Second Deadline
21-giu-04
133
94
Deliveries To Shop
1-nov-04
Samples receiving at
Bid
Tabella 6.1: Successione delle fasi per una collezione
6.4.2
Il calendario di Basic_jES
Per stabilire il calendario della simulazione ho ripreso il modello creato in Lamieri (2002) e Merlo (2003a) e ho adattato il calendario dell’azienda simulata
al calendario dell’azienda reale. Le fasi della simulazione sono le seguenti:
1. Disegno dei Metasamples: BasicSamples crea una nuova collezione.
2. Previsione dei licenziatari : ciascun licenziatario esprime una previsione
degli acquisti per ciascun articolo della collezione.
3. Somma delle previsioni : BasicForecast somma le previsioni dei licenziatari per ciascun articolo della collezione; se le previsioni superano
una certa soglia l’articolo viene sviluppato, in caso contrario viene
abbandonato.
4. Produzione campionario: BasicSample, tramite un Sourcing Center da
essa scelto, produce il campionario.
5. Consegna Campionario: il campionario viene consegnato ai licenziatari.
6. Asta Trading Company: le cinque Trading Company presenti nella simulazione offrono un prezzo per la produzione di ciascun articolo della
collezione.
7. Scelta Trading Company: BasicBiddings sceglie, per ciascun articolo,
la Trading Company che ha offerto il prezzo di produzione minore e
affida a questa la produzione.
8. Primo ordine: i licenziatari effettuano un ordine per la collezione.
9. Secondo ordine: i licenziatari effettuano il secondo ordine.
10. Produzione: la Trading Company che ha vinto l’asta inizia la produzione.
108
11. Consegna: le Trading Company consegnano i prodotti ai licenziatari.
6.5
Le ricette produttive
Le ricette produttive descrivono i passi che le unità del modello devono compiere. Ho mantenuto le stesse presenti in Lamieri (2002) e Merlo (2003a) e
ne ho aggiunta una nuova che permette ai licenziatari di effettuare il secondo
ordine alle Trading Company.
Le ricette 101, 102, 103, 104 descrivono la fase di creazione del campionario di quattro collezioni diverse. Nel modello precedente si riferivano rispettivamente alla creazione di una collezione Kappa, Robe di Kappa, ‘‘scarpe”
e ‘‘sport’’. Per aggiornare il modello ho chiamato queste quattro ricette con
i marchi posseduti attualmente da BasicNet, perciò:
• La ricetta 101 si riferisce ad una collezione Kappa.
• La ricetta 102 si riferisce ad una collezione Robe di Kappa.
• La ricetta 103 si riferisce ad una collezione K-Way.
• La ricetta 104 si riferisce ad una collezione Superga.
Le ricette da 201 a 235 consentono ai licenziatari di esprimere una previsione di acquisto su ciascun articolo della collezione.
Con la ricetta 300 BasicForecast somma le previsioni dei licenziatari per
ogni articolo.
La ricetta 301 simula la produzione del campionario della collezione e
accumula i prodotti nella endUnit 101.
La ricetta 302 esegue un procurement sulla endUnit in cui è contenuto
il campionario e simula la consegna ai licenziatari; in seguito sono anche
contabilizzati i ricavi derivanti dalla sua vendita.
Le ricette da 401 a 405 simulano l’asta tra le Trading Company.
109
Con ricetta 500 BasicBiddings sceglie la vincente dell’asta: vince la Trading Company che ha offerto il prezzo di produzione più conveniente.
Le ricette da 601 a 635 simulano il primo ordine dei licenziatari.
Le ricette da 701 a 735 descrivono il secondo ordine dei licenziatari.
Con la ricetta 800 le Trading Company producono le collezioni e accumulano gli articoli nella endUnit 102.
Con la ricetta 900 le unità rappresentative di BasicNet effettuano un
procurement sulla endUnit 102 e simulano la consegna delle collezioni ai
licenziatari; inoltre viene contabilizzato il valore delle royalties derivanti dalla
vendita.
La ricetta 1 conclude la simulazione.
6.6
Le memoryMatrixes
Le memoryMatrixes sono utili per gestire le operazioni immateriali e per
contenere i dati della simulazione per tutte le collezioni e possono essere
utilizzate con l’ausilio degli oggetti computazionali. Ho ridotto le dimensioni
delle colonne da 301 a 152, in quanto nel modello sono state eliminate le
MegaCollections sostituendole con collezioni minori. Le matrici di memoria
del modello sono le seguenti:
designMatrix : vettore di una riga e una colonna nel quale viene inserito il
numero di MetaSamples disegnati da BasicSample;
agentMatrix : matrice nella quale sono salvate, nella prima riga, le previsioni dei licenziatari per ciascun articolo della collezione e le quantità
richieste nel primo e nel secondo ordine, rispettivamente nella seconda e nella terza riga; nel modello è presente una agentMatrix per ogni
licenziatario;
110
tcMatrix : matrice in cui sono salvati i prezzi offerti dalla Trading Company;
anche in questo caso si ha una matrice per ogni Trading Company;
basicNetMatrix : contiene le informazioni possedute da BasicNet:
• la prima riga contiene la somma dei valori previsti dai licenziatari
per ogni articolo;
• la seconda indica lo status di ciascun articolo: 0 se è da non realizzare, 1 se è da realizzare, 2 se il campionario è stato realizzato,
3 se l’articolo è stato prodotto;
• la terza contiene il prezzo, per ogni articolo, che ha vinto l’asta
per la produzione;
• la quarta contiene la quantità di ogni articolo richiesta dai licenziatari per il primo ordine;
• la quinta contiene la quantità di ogni articolo richiesta dai licenziatari per il secondo ordine;
• la sesta indica la quantità totale richiesta dai licenziatari per ogni
articolo; il valore inserito in questa riga per ciascun articolo sarà
moltiplicato per il prezzo di vendita nel momento in cui si BasicNet
calcola e contabilizza le royalties.
orMatrix : in ogni colonna è indicata la Trading Company che deve produrre
l’articolo a cui è intestata la colonna.
6.7
Le modifiche al codice
Nella classe ComputationalAssembler.java ho inserito un nuovo oggetto computazionale, C1909, che permette ai licenziatari di effettuare il secondo
ordine.
111
Inizialmente il codice crea un contatore con il metodo privato getCounter
verifica che la riga e colonna 0 della designMatrix non sia vuota, cioè che la
collezione esista. In seguito controlla che il licenziatario abbia effettuato il
primo ordine alla Trading Company; per far ciò utilizza il metodo getEmpty,
il quale controlla che la casella della memoryMatrix del licenziatario preso in
considerazione non sia vuota, in caso contrario non si esegue il nuovo ordine
e nella riga 3 alla colonna corrispondente all’articolo dell’agentMatrix viene
scritto il valore 0; la stessa cosa avviene nella sesta riga della basicNetMatrix
nel caso che la casella in considerazione sia vuota. L’obiettivo di questo
accertamento è evitare che sia fatto un ordine per un articolo il cui sviluppo
è stato abbandonato.
In seguito il passo computazionale sceglie se effettuare un nuovo ordine
in modo casuale, utilizzando come parametro un numero estratto da una distribuzione normale con media 100 e varianza 50000; se il numero è maggiore
della media della distribuzione l’ordine è eseguito.
Anche la quantità da ordinare è scelta in modo casuale estraendo un
campione da una distribuzione normale con media 500 e varianza 900000 (si
attivano dei correttivi nel caso che il valore ottenuto sia troppo piccolo o
troppo grande). Il valore così ottenuto è salvato nelle caselle corrispondenti
all’articolo dell’agentMatrix e della basicNetMatrix con il metodo setValue,
e sul monitor è stampata l’indicazione dell’avvenuto ordine del licenziatario
e la quantità ordinata.
In seguito il passo computazionale somma, per ogni articolo, il valore dei
due ordini e lo inserisce nella riga 6 della basicNetMatrix; questo valore sarà
utile nel corso della simulazione per la Trading Company che dovrà produrre
l’articolo e per il calcolo del valore delle royalties.
¨
Listing 6.1: ComputationalAssembler.java: C1909
p u b l i c v o i d c1909 ( )
112
113
{
int threshold = 100;
checkMatrixes (1909 ,3);
d e s i g n M a t r i x =(MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
a g e n t M a t r i x =(MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
b a s i c N e t M a t r i x =(MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
l a y e r=p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t . g e t O r d e r L a y e r ( ) ;
i n t j = g e t C o u n t e r ( agentMatrix , 3 ) ;
i f ( ! d e s i g n M a t r i x . getEmpty ( l a y e r , 0 , 0 ) )
{
i f ( j <= d e s i g n M a t r i x . g e t V a l u e ( l a y e r , 0 , 0 ) )
{
// Checks i f t h e l i c e n s e e has a l r e a d y done t h e f i r s t o r d e r
i f ( ! a g e n t M a t r i x . getEmpty ( l a y e r , 2 , j ) )
{
int select = ( int )
normal . getSampleWithMean$withVariance ( 1 0 0 , 5 0 0 0 0 ) ;
// d e c i d e t o do or not a n o t h e r o r d e r
i f ( select > threshold )
{
int order2 = ( int )
normal . getSampleWithMean$withVariance ( 5 0 0 , 9 0 0 0 0 0 ) ;
//Min v a l u e
i f ( o r d e r 2 <10)
order2 = 10;
114
//Max v a l u e
i f ( o r d e r 2 >25000)
order2 = 25000;
agentMatrix . setValue ( layer , 3 , j , order2 ) ;
i f ( b a s i c N e t M a t r i x . getEmpty ( l a y e r , 5 , j ) )
basicNetMatrix . setValue ( layer , 5 , j , 0 . 0 ) ;
i n t totOrder2 = ( i n t )
basicNetMatrix . getValue ( layer , 5 , j ) + order2 ;
basicNetMatrix . setValue ( layer , 5 , j , totOrder2 ) ;
System . out . p r i n t l n ( "The␣2nd␣ o r d e r ␣ o f ␣ L i c e n s e e␣#"
+ myUnit . getUnitNumber ( ) + " ␣ i s ␣ " + o r d e r 2 + " ␣ f o r ␣ item␣#"
+ j + " ␣ with ␣ l a y e r ␣#" + l a y e r + " ␣ t o t O r d e r␣#"+ t o t O r d e r 2 ) ;
} // end i f ( s e l e c t )
else
{
agentMatrix . setValue ( layer , 3 , j , 0 . 0 ) ;
i f ( b a s i c N e t M a t r i x . getEmpty ( l a y e r , 5 , j ) )
} // end e l s e
i n t totOrder1 = ( i n t ) basicNetMatrix . getValue ( layer , 4 , j ) ;
i n t totOrder2 = ( i n t ) basicNetMatrix . getValue ( layer , 5 , j ) ;
i n t totOrder = totOrder1 + totOrder2 ;
basicNetMatrix . setValue ( layer , 6 , j , totOrder ) ;
115
}/ end i f ( c h e c k i n g f i r s t o r d e r )
}
}
}
done = t r u e ;
// The a r t i c l e can not be o r d e r e d −> done=f a l s e
} // end c1909
§

6.8
Analisi di diversi business system
L’obiettivo finale di questo lavoro è l’analisi di tre diverse modalità di business system che BasicNet potrebbe adottare. Nel primo caso si descrive la
BasicNet reale, che affida le fasi della produzione e delle vendite totalmente
ai Sourcing Centers o alle Trading Company. Nella seconda ricostruzione si
immagina una BasicNet che agisca come un’azienda tradizionale, producendo
i prodotti al suo interno e vendendoli direttamente ai licenziatari. Nel terzo
esempio si rappresenta la BasicNet come un’azienda che produce le collezioni
in outsourcing, tramite le Trading Company, ma che si occupa direttamente
della vendita.
Con l’analisi di costi e ricavi originati in queste tre situazioni è possibile
effettuare un confronto tra il modello di business adottato da BasicNet e due
ipotetici business system alternativi. Tuttavia occorre ricordare che lo studio
qui proposto prende in considerazione solo alcuni aspetti della realtà, perciò i
risultati ottenuti possono costituire un’indicazione per le scelte aziendali che
deve essere affiancata anche da altre valutazioni; questo modello infatti offre
un confronto tra tre diversi tipi di gestione partendo da una base comune,
la BasicNet come è descritta nel caso 1, che è diversa da quella reale per-
¦
ché nella vera azienda possono verificarsi eventi diversi da quelli immaginati
in Basic_jES. Il modello illustrato fornirebbe risultati assoluti nel solo caso in cui la realtà descritta nel computer riproducesse quella del mondo reale.
Nei prossimi paragrafi è illustrata la formalizzazione dei tre diversi modelli
di Basic_jES e le modifiche portate al modello generale descritto precedentemente.
6.9
Caso 1
In questa ricostruzione si presenta la BasicNet reale, che opera come descritto nel paragrafo 6.4.1. Gli unici costi che l’azienda sostiene sono legati al
mantenimento del network e all’ideazione e produzione del campionario; i
centri di costo sono rappresentati dalle divisioni dot.com. I ricavi sono originati dalla vendita del campionario ai licenziatari e dalla riscossione delle
royalties, che rappresentano il 10% degli acquisti effettuati dai licenziatari
alle Trading Company; le royalties sono suddivise all’interno della BasicNet
nel seguente modo:
• 4% a World Wide Strategic Advertisement, che ha funzioni di marketing;
• 4% per la remunerazione del marchio;
• il restante 2% ripartito tra le divisioni dot.com nel modo illustrato in
Tabella 6.2;
6.9.1
Le unità produttive
In questo modello, come nella BasicNet reale, le Trading Company consegnano direttamente la merce ai licenziatari, perciò per ciascuna di esse ho ag-
116
117
DIVISIONE
% royalties
BasicSamples
0,5%
BasicForecast
0,25%
BasicSpecs
0,25%
BasicBiddings
0,25%
BasicFactory
0,25%
BasicNet
0,5%
TOTALE
2%
Tabella 6.2: Suddivisione delle royalties
giunto un’unità produttiva nel file unitData/unitBasicData.txt, ipotizzando
che all’interno siano organizzate almeno in due divisioni: la prima si occupa
dell’asta per l’aggiudicazione e della produzione e la seconda della consegna
ai licenziatari.
In questo caso le unità produttive sono le seguenti:
• 35 licenziatari, ognuno suddiviso in due sezioni, una che si occupa di
effettuare le previsioni sugli acquisti futuri e una che esegue gli ordini;
• 5 Trading Company, strutturate nel modo illustrato precedentemente;
• BasicSamples, divisa in quattro sezioni ognuna incaricata della gestione
di uno specifico tipo di collezione;
• BasicForecast;
• BasicSpecs;
• un’ipotetica Trading Company che rappresenta una sartoria che produce il campionario per conto di BasicSamples. È un’unità esterna
a BasicNet, alla quale non sono imputati costi, in quanto sono già
compresi nei costi di BasicSamples;
118
• BasicBiddings;
• BasicFactory;
• unità rappresentative di BasicNet che si occupano della consegna del
campionario, della contabilizzazione dei ricavi e interrompono la simulazione al giorno 600.
In questa ricostruzione le uniche unità che originano dei costi sono le
divisioni dot.com, perché i licenziatari e le Trading Company sono unità
esterne a BasicNet. Per ottenerne un’indicazione plausibile ho estratto i
valori dalla sezione del bilancio consolidato di BasicNet in cui si elencano i
costi di gestione in base alla loro variabilità (Figura 6.1); i costi al di sopra
del Margine di Contribuzione sono tutti variabili, mentre quelli al di sotto
sono fissi. Nell’incontro del 26/03/2004 la dottoressa Bruschi mi ha suggerito
di ripartire i costi fissi in base alla suddivisione delle royalties mostrata in
Tabella 6.2 e di imputare solo a BasicSamples costi variabili, perché è l’unica
divisione la cui operatività è legata al numero di MetaSamples prodotti, a
differenza delle altre che hanno soltanto compiti di gestione del network di
BasicNet.
I costi fissi delle divisioni sono mostrati nella Tabella 6.3. Per ottenere
il costo unitario variabile da assegnare a BasicSamples occorre dividere il
valore a bilancio dei costi variabili totali per il numero di articoli creati da
BasicNet nell’anno 2002, pari a 66762 :
CU VBasicSamples =
CV T
n◦ M etaSamples
=
59.806.000 ∼
= 8.958
6.676
Il valore dei costi di ciascuna divisione deve essere diviso per il numero
di unità che nel modello la rappresentano; questo numero si può ricavare dal
2
Fonte: BasicNet (2002)
Figura 6.1: Costi variabili e fissi di BasicNet
unitData/unitBasicData.txt. In questo file sono indicati anche il valore dei
costi fissi e variabili di ciascuna unità.
Dal momento che i costi presi in considerazione sono annuali, i costi fissi
dovranno anche essere divisi per il numero di giorni che rappresentano un
anno nel modello (300) e per il numero di tick che compongono un giorno
della simulazione (32). La motivazione è che jES contabilizza i costi ad ogni
tick e non facendo ciò si causerebbe un’amplificazione dei costi dell’azienda.
I costi variabili di BasicSamples non devono essere divisi per il numero di
tick totali della simulazione, in quanto essi indicano quanto costa all’azienda
la produzione di ciascun articolo. Perciò questo valore deve essere diviso per
il numero di tick necessari alla produzione di ogni MetaSamples; il motivo è
che ad ogni tick jES contabilizza il costo variabile delle unità attive, quindi
se un’unità impiega 6 tick per la creazione di un articolo il costo totale sarà
pari a sei volte il costo indicato nel file unitData/unitBasicData.txt.
119
Divisione
% costo
120
CFT
imputabile
BasicSamples
25%
9.874.000
BasicForecast
12,5%
4.937.000
BasicSpecs
12,5%
4.937.000
BasicBiddings
12,5%
4.937.000
BasicFactory
12,5%
4.937.000
BasicNet
25%
9.874.000
TOTALE
100%
39.947.000
Tabella 6.3: Costi fissi delle divisioni dot.com (in euro)
6.9.2
Le nuove ricette
Ho diviso la ricetta 900, che simula la consegna dei prodotti ai licenziatari e
contabilizza il valore delle royalties, in due distinte, perché nella realtà questi
incarichi spettano a due soggetti diversi.
Ho creato la ricetta 900 (Figura 6.2) che simula la consegna degli articoli della collezione ai licenziatari effettuando un procurement sull’endUnit
102 da parte della Trading Company incaricata della produzione; in seguito
l’oggetto computazionale C1913 aggiorna lo status dell’articolo inserendo
nella riga 2 della basicNetMatrix il numero 4, che significa ‘‘prodotto consegnato”, e stampa sul monitor l’indicazione che l’articolo è stato consegnato
ai licenziatari dalla Trading Company che lo ha prodotto. Nella ricetta è
presente il processo or che è utilizzato per scegliere la Trading Company che
dovrà consegnare l’articolo ai licenziatari; per la decisione si fa ricorso alla
orMatrix, matrice di memoria in cui in ciascuna colonna è indicato il numero
della Trading Company che ha prodotto l’articolo a cui è intestata la colonna
stessa.
Figura 6.2: Ricette 900 e 950
La ricetta 950 (Figura 6.2) simula il pagamento e la contabilizzazione
delle royalties da parte di BasicNet; il passo computazionale C1912 ne calcola il valore moltiplicando per 0,1 il totale dei ricavi derivanti dalla vendita
degli articoli e lo inserisce nel file log/grossSales.txt creato dalla simulazione.
Nell’incontro del 13/07/2004 la dottoressa Bruschi mi ha informato che
in BasicNet il prezzo di vendita di ciascun articolo si ottiene moltiplicando
per un coefficiente il prezzo di produzione offerto dalla Trading Company che
ha vinto l’asta; questo coefficiente è calcolato da un software e attualmente
è pari a 2,2 per tutti gli articoli. Nel modello Basic_jES la determinazione
del prezzo all sale avviene nello modo descritto qui sopra.
6.9.3
Il calendario
Anche il calendario ha subito una modifica rispetto a quanto descritto nei
paragrafi precedenti, in quanto ho ipotizzato che i licenziatari paghino le
royalties a BasicNet dopo un certo periodo di tempo. Pertanto l’esecuzione
della sopra descritta ricetta 950 avviene 10 giorni dopo la consegna delle
collezioni.
121
6.9.4
122
C1913
Ho inserito nella classe ComputationalAssembler.java il metodo C1913, che
simula la distribuzione degli articoli da parte delle Trading Company.
Questo passo computazionale, dopo aver creato un contatore, verifica che
la designMatrix non sia vuota e controlla il numero di MetaSamples con
il metodo getValue. In seguito va a determinare lo status dell’articolo nella
seconda riga della basicNetMatrix e, se l’articolo considerato è stato prodotto
(il suo status è 3), inserisce nella casella il valore 4 con il metodo setValue,
per indicare che il prodotto è stato consegnato.
Successivamente l’oggetto computazionale cerca nella orMatrix il numero
della Trading Company incaricata di produrre l’articolo e lo copia nella colonna 0 della della matrice; si utilizza questo espediente perché jES durante
la simulazione legge il branch da scegliere per il processo or nella casella (1,0)
della orMatrix.
Infine, sul monitor è stampata l’indicazione che l’articolo è stato consegnato dalla Trading Company incaricata di produrlo.
¨
p u b l i c v o i d c1913 ( )
{
o r M a t r i x =(MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
l a y e r = pendingComputationalSpecificationSet . getOrderLayer ( ) ;
123
i n t counter = getCounter ( basicNetMatrix , 2 ) ;
{
i f ( c o u n t e r <= d e s i g n M a t r i x . g e t V a l u e ( l a y e r , 0 , 0 ) )
{
// Check i f item has been produced
i f ( basicNetMatrix . getValue ( layer , 2 , counter ) > 2)
{
f l o a t tc = orMatrix . getValue ( layer , 1 , counter ) ;
orMatrix . setValue ( layer , 1 , 0 , tc ) ;
System . out . p r i n t l n ( " Item␣␣#" + c o u n t e r + " ␣ with ␣ l a y e r ␣#"
+ l a y e r + " ␣ has ␣ been ␣ d e l i v e r e d ␣by␣ Trading ␣Company␣ " +
orMatrix . getValue ( layer , 1 , 0 ) ) ;
basicNetMatrix . setValue ( layer , 2 , counter , 4 . 0 ) ;
}
}
}
done = t r u e ;
} // end c1913
§

C1912
Ho portato alcune modifiche al passo computazionale C1912 che si occupa
della contabilizzazione delle royalties. Questo metodo inizialmente crea un
contatore, cerca il numero di MetaSamples creati nella designMatrix e in
seguito controlla nella basicNetMatrix, per ciascun articolo, il suo status (riga
¦
124
2), il prezzo di produzione che ha vinto l’asta (riga 3) e la quantità totale
ordinata dai licenziatari (riga 6). Successivamente, se lo status dell’articolo è
4, cioè ‘‘prodotto consegnato’’, si calcolano il prezzo di vendita dell’articolo
moltiplicando il prezzo offerto dalla Trading Company per 2.23 , il totale dei
ricavi e il valore delle royalties. Il valore delle royalties è memorizzato nel
file nel file log/grossSales.txt insieme all’indicazione del tick in cui è stato
contabilizzato. Infine sul monitor è stampata l’indicazione che le royalties
sono state pagate.
¨
p u b l i c v o i d c1912 ( )
{
{
{
i f ( ! b a s i c N e t M a t r i x . getEmpty ( l a y e r , 2 , c o u n t e r )
&& ! b a s i c N e t M a t r i x . getEmpty ( l a y e r , 3 , c o u n t e r )
&& ! b a s i c N e t M a t r i x . getEmpty ( l a y e r , 6 , c o u n t e r ) )
{
i f ( basicNetMatrix . getValue ( layer , 2 , counter ) > 3.0)
{
3
125
double itemPrice =
basicNetMatrix . getValue ( layer , 3 , counter ) ∗ 2 . 2 ;
double totRevenues =
itemPrice ∗ basicNetMatrix . getValue ( layer , 6 , counter ) ;
double itemSales = ( totRevenues ∗ 0 . 1 ) ;
System . out . p r i n t l n ( " R o y a l t i e s ␣ f o r ␣ item␣␣#" +
c o u n t e r + " ␣ with ␣ l a y e r ␣#" + l a y e r +
" ␣ have ␣ been ␣ payed ␣by␣ l i c e n s e e s " ) ;
String text =
G l o b a l s . env . getCurrentTime ( ) + " ␣ | ␣ " +
i t e m S a l e s + " ␣\n" ;
logOpen ( f a l s e , " l o g / g r o s s S a l e s . t x t " ) ;
try
{
grossSalesLog . write ( text ) ;
grossSalesLog . flush ( ) ;
}
c a t c h ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
}
}
}
done = t r u e ;
} // end c1912
§

¦
126
C1910
Ho effettuato una modifica anche al codice del metodo C1910, il cui compito
è concludere la simulazione e creare il file log/report.txt; questo file indica,
per ogni collezione, il numero di MetaSamples creati e il numero di articoli
prodotti e abbandonati, in base al loro status indicato nella riga 2 della
basicNetMatrix. Ho impostato la creazione di questo file in modo che sia
indicato anche il numero di articoli che sono stati consegnati per ciascuna
collezione.
Il file log/report.txt è utile perché permette di verificare quanti sono gli
articoli che sono prodotti e consegnati e quanti quelli che sono abbandonati
a causa delle insufficienti previsioni di acquisto dei licenziatari.
6.9.5
Qui di seguito viene mostrato il file jesframe.scm, nel quale sono indicati i
parametri su cui si basa la simulazione e che sono mostrati nel probe del
ESFrameModelSwarm e del ESFrameObserverSwarm. Il linguaggio di programmazione utilizzato in questo file si chiama scheme, ed è un dialetto del
linguaggio Lisp.
Listing 6.4: jesframe.scm per il Caso 1
¨
( list
(
c o n s ’ eSFrameObserverSwarm
(
make−i n s t a n c e ’ ESFrameObserverSwarm
#: d i s p l a y F r e q u e n c y
32
#: v e r b o s e C h o i c e
#f
#: p r i n t M a t r i x e s
#f
#: checkMemorySize
#f
#: unitHistogramXPos
1
127
#: unitHistogramYPos
600
#: endUnitHistogramXPos
578
#: endUnitHistogramYPos
1
)
)
(
c o n s ’ eSFrameModelSwarm
(
make−i n s t a n c e ’ ESFrameModelSwarm
#: u s e O r d e r D i s t i l l e r
#t
#: ticksInATimeUnit
32
#: totalUnitNumber
134
#: totalEndUnitNumber
2
#: totalLayerNumber
17
#:totalMemoryMatrixNumber
43
#: sameStepLifoAssignment
#t
#: assignEqualStepsToSameUnit
#t
#:maxTickInAUnit
2080
#: useWarehouses
#f
#: useNewses
#f
#: revenuePerEachRecipeStep
0
#: r e v e n u e P e r C o s t U n i t
0
#: o r C r i t e r i o n
5
#:orMemoryMatrix
#: u n i t C r i t e r i o n
42
2
)
)
)
;
§

¦
Essi significano:
useOrderDistiller: la successione delle ricette viene tratta dal file recipeData/orderSequence.xls; se il parametro fosse impostato false gli ordini
verrebbero generati in modo casuale;
ticksInATimeUnit: indica il numero di tick che costituiscono un giorno
della simulazione; in questo caso sono 32, ciascuno pari a 15 minuti;
totalUnitNumber: indica il numero di unità della simulazione;
totalEndUnitNumber: numero delle endUnit;
totalLayerNumber: numero di layer;
totalMemoryMatrixNumber: numero delle matrici di memoria;
sameStepLifoAssignment: se impostato su true, se un’unità è in grado
effettuare due passi per uno stesso ordine, la produzione avviene con
procedura LIFO; in questo modo la produzione risulta sequenziale;
assignEqualStepsToSameUnit: se impostato su true, se un ordine necessita dello stesso passo per due volte consecutive tra loro, la lavorazione
viene svolta dalla stessa unità;
maxTickInAUnit: indica il numero massimo di tick in cui un ordine può
rimanere nella lista d’attesa di un’unità; una volta trascorsi l’ordine
viene eliminato;
useWarehouse: se impostato su true significa che le unità creano magazzini;
useNewses: se è impostato su true le unità si scambiano informazioni;
revenuePerEachRecipeStep e revenuePerCostUnit: metodo di calcolo dei ricavi; siccome in questo caso Basic_jES non presenta ricavi, i
parametri sono entrambi nulli;
orCriterion: indica il criterio di scelta del ramo da parte del processo or
avviene con l’ausilio della orMatrix ;
128
orMemoryMatrix: numero della orMatrix ;
unitCriterion: indica il criterio di assegnazione degli ordini tra unità che
sono in grado di eseguire lo stesso passo; in questo caso, l’ordine viene
assegnato all’unità che ha la lista d’attesa meno lunga.
6.10
Caso 2
In questa seconda ricostruzione si presenta una BasicNet che si comporta
come un’azienda tradizionale che produce le collezioni al suo interno e le
vende direttamente ai licenziatari.
Costi e ricavi hanno una diversa origine causata dalla differente operatività dell’impresa rispetto al caso precedente. I costi derivano dalla produzione
diretta degli articoli da parte delle Trading Company, che in questo modello
sono considerate unità interne alle quali sono pertanto attribuiti dei costi. I
ricavi sono originati dalla vendita diretta delle collezioni ai licenziatari e sono
calcolati in base ad un margine di ricarico applicato sui costi di produzione.
Dal momento che le Trading Company sono unità interne all’azienda,
non ha più senso che l’assegnazione delle produzioni degli articoli sia decisa
tramite un’asta, perché è più corretto immaginare che di volta in volta le
lavorazioni siano affidate alla Trading Company con la lista d’attesa meno
lunga; per ottenere questo risultato ho portato alcune modifiche al modello
illustrato nei paragrafi precedenti.
6.10.1
Le modifiche al modello
Le ricette
Per ottenere un’azienda in cui i prodotti sono fabbricati internamente e le
attività sono assegnate alle unità secondo il criterio del numero di lavorazioni
presenti nelle liste d’attesa è necessario modificare la ricetta che descrive la
129
fase di produzione ed eliminare quelle che gestiscono l’asta tra le Trading
Company.
Ho perciò eliminato le ricette 401, 402, 403, 404, 405, che simulano
l’offerta di un prezzo di produzione da parte di ogni Trading Company, e la
ricetta 500, il cui compito è scegliere la Trading Company vincente.
Inoltre ho modificato la ricetta 800, riferita alla produzione; in questo caso gli articoli possono essere prodotti da una qualsiasi delle Trading Company
e la scelta è fatta in base alla waiting list di ciascuna. Perciò ho eliminato
il processo or secondo cui la decisione è effettuata in base alla orMatrix e
ho ottenuto la nuova ricetta mostrata in Figura 6.3 composta di un solo
passo incaricato della produzione degli articoli. Questa ricetta non contiene
nessuna computazione, perciò è lanciata per ogni prodotto, anche per quelli
abbandonati; questo non è però un errore, perché nella versione definitiva del
modello la ricetta sarà lanciata da un’altra ricetta nel solo caso in cui l’articolo debba essere prodotto. Per una trattazione più approfondita si rimanda
a Balla (2004).
Figura 6.3: Ricetta 800
In questo modello le collezioni sono consegnate direttamente da BasicNet,
perciò ho eliminato dal file recipeData/recipes.xls le ricette 900 e 950 descritte nel paragrafo 6.9.2 e le ho sostituite con una ricetta unica, mostrata nella
Figura 6.4 che simula la consegna degli articoli ai licenziatari effettuando un
procurement sull’endUnit 102; l’oggetto computazionale C1913 stampa sul
monitor l’indicazione che l’articolo è stato consegnato.
Ho anche modificato la ricetta 302, che si occupa di consegnare il campionario, eliminando l’oggetto computazionale C1911 il cui compito era cal-
130
colare il prezzo degli articoli del campionario. Infatti in questa ricostruzione
i ricavi del campionario sono compresi nel calcolo del margine di ricarico. La
nuova ricetta, mostrata in Figura 6.5, esegue un procurement sull’endUnit
101 (nella quali è ‘‘immagazzinato” il campionario) e simula la consegna ai
licenziatari. Nella versione definitiva del modello anche questa ricetta è lanciata da un’altra ricetta, il cui compito è valutare se il campionario debba
essere consegnato.
Il calendario
Nel calendario, descritto nel file recipeData/orderSequence.xls, ho eliminato
per tutte le collezioni prodotte durante la simulazione la fase dell’asta, che si
articola in due momenti: inizialmente le Trading Company offrono un prezzo
di produzione per ogni articolo e successivamente BasicBiddings sceglie la
vincente.
Le unità
Ho portato anche alcune modifiche al file unitData/unitBasicData.txt; in
questo modello tutte le Trading Company sono in grado di effettuare lo stesso
passo produttivo, il numero 2010, il cui compito è produrre gli articoli (come
si vede in Figura 6.3).
131
Ho anche eliminato dal modello le unità che rappresentano BasicBiddings
e BasicFactory, perché la prima rimarrebbe inattiva per tutta la simulazione,
e la seconda non ha più motivo di esistere, siccome l’assegnazione della produzione avviene secondo quanto stabilito dall’orCriterion. A causa di queste
modifiche ho modificato il parametro totalUnitNumber nel file jesframe.scm,
che indica il numero di unità del modello.
Le matrici di memoria
Le matrici di memoria relative alle Trading Company non sono più necessarie,
dal momento che non esiste più l’asta. Inoltre occorre cancellare la orMatrix,
che non è più utilizzata durante la simulazione.
Perciò in questo modello le memoryMatrix sono una per ogni licenziatario
e una per BasicNet. Per non causare errori nella simulazione ho modificato
il numero della basicNetMatrix nel file recipeData/recipes.xls per tutte le
ricette che la utilizzano.
Inoltre ho modificato nel file jesframe.scm il parametro totalMemoryMatrixNumber, perché in questo caso ci sono 36 matrici di memoria, e ho eliminato
i parametri orMemoryMatrix e orCriterion.
6.10.2
I costi delle unità produttive
I costi delle unità sono gli stessi mostrati per il caso 1, con due differenze
rispetto al caso precedente: nell’azienda non esistono più BasicBiddings e
BasicFactory e perciò nemmeno i loro costi; inoltre le Trading Company in
questo esempio sono considerate interne all’azienda, e pertanto il loro utilizzo
comporta dei costi.
Per ricavare un ordine di grandezza dei costi di produzione delle collezioni ho ricavato dal bilancio consolidato di BasicNet del 2002 il valore delle
Commissioni del Sourcing, che rappresentano la remunerazione conferita ai
132
Sourcing Centers dai licenziatari per coprire i costi di struttura originati dal
servizio di intermediazione loro offerto. Il dato a bilancio si riferisce alle società LF Basic Ltd, che opera come Sourcing Center per l’area asiatica, e LF
Basic Europe S.r.l., Sourcing Center dell’area europea.
Per avere un’indicazione dei costi ho ipotizzato che i Sourcing Centers
chiudano il bilancio in pareggio, pertanto il valore delle commissioni pagate
dai licenziatari corrisponde ai costi da loro sostenuti. Inoltre, su indicazione
della dottoressa Bruschi, ho ipotizzato che il valore delle commissioni sia pari
al 7% dei costi totali di produzione degli articoli. Grazie a queste congetture
mi è stato possibile ricavare il valore dei costi (CT ) per la produzione degli
articoli.
Costi Di Produzione =
=
1.588.000 × 100
CommissionidelSourcing × 100
=
=
7
7
= 22.685.714
Questo valore rappresenta il costo sostenuto da due Sourcing Centers;
per ottenere il costo complessivo per la produzione delle collezioni occorre
considerare i costi delle 5 Trading Company alle quali BasicNet si affida. Per
conoscere questo valore, adottando l’ipotesi che i Sourcing Centers abbiano
gli stessi costi, è sufficiente impostare la seguente proporzione:
22.685.714 ÷ 2 = Costi totali ÷5
CostiT otali =
22.685.714 × 5
= 56.714.286
2
Un ultimo problema da risolvere è il modo in cui ripartire i costi tra fissi
e variabili. Con il professor Terna abbiamo deciso di indicare tutti variabili
i costi delle Trading Company, immaginando che la scelta tra esse sia simile
133
ad una decisione di make-or-buy: le Trading Company avranno influenza sui
costi aziendali solo nel momento in cui verranno chiamate a operare e non
daranno origine a costi sommersi (o sunk costs).
Date queste assunzioni, il costo unitario variabile per la produzione di
un articolo è pari ai costi di produzione totali divisi per il numero di articoli ordinati, e perciò prodotti, che nel primo semestre del 2002 ammonta
a 40.0004 ; ipotizzando che nei sei mesi successivi si sia prodotta la stessa
quantità, il numero di articoli prodotti per il 2002 è 80.000. Perciò il costo
variabile unitario è pari a:
CU VT radingCompany =
CostiDiP roduzione
56.714.286 ∼
=
= 709
n◦ articoli
80.000
Per inserire i costi nel file unitData/unitBasicData.txt è necessario dividere questo valore per il numero di tick necessari ad una Trading Company
per produrre un articolo, in modo analogo a quanto fatto per BasicSamples
nel paragrafo 6.9.1.
6.10.3
I ricavi aziendali
Per ottenere i ricavi di questa ipotetica BasicNet ho impostato un margine
di ricarico che viene applicato a tutti i costi sostenuti dall’azienda durante
la simulazione; per ottenere tale margine mi sono basato sui costi e ricavi
reali di BasicNet indicati a bilancio, in modo da ottenere un mark-up il più
possibile vicino alla realtà.
Il valore dei costi totali si ottiene sommando i costi totali delle divisioni
dot.com a quelli di produzione delle Trading Company. I costi delle divisioni
dot.com si ricavano sommando i costi variabili totali di BasicSamples ai costi
fissi totali (Tabella 6.3), mentre quelli delle Trading Company si trovano nel
4
134
modo descritto nel paragrafo precedente. Si ottiene pertanto che i costi totali
(CT ) di questa ipotetica BasicNet sono pari a:
CT = CV TBasicSamples + CF T + CV TT radingCompany =
= 59.806.000 + 39.497.000 + 56.714.286 =
= 156.017.286
Per quanto riguarda i ricavi, in questa ricostruzione BasicNet vende il
campionario, come anche nel caso 1, e le collezioni; pertanto i proventi totali
si ottengono dalla somma dei loro importi. Per il valore del campionario mi
sono basato sulla voce Vendita campionari presente nel bilancio di esercizio
di BasicNet del 2002. Per determinare i ricavi derivanti dalla vendita delle
collezioni ho estratto dal bilancio consolidato di BasicNet del 2002 la voce
Royalties; siccome queste ultime sono pari al 10% degli acquisti dei licenziatari dalle Trading Company, per ottenere il valore delle vendite (RT V endite ) è
sufficiente impostare la seguente proporzione:
royalties ÷ 0.1 = RTV endite ÷ 1
Inoltre occorre anche considerare tra i ricavi aziendali quelli che derivano dalle vendite di Kappa Italia, ora BasicItalia, che a bilancio non sono
compresi nel computo delle royalties, ma sono indicati alla voce Vendite di
abbigliamento sportivo. Si ottiene pertanto che i ricavi totali aziendali (RT )
sono pari a:
RT = RTCampionario + RTV endite + RTKappaItalia =
= 2.602.375 + 163.110.000 + 91.739.000 =
= 257.451.375
135
In conclusione, il margine di ricarico che viene applicato a ciascun costo
effettuato dall’azienda è pari al 65%, che si ottiene nel modo seguente:
mark-up =
RT
CT
∼
= 1, 65
Questo valore sarà inserito nel file jesframe.scm, che contiene i parametri
della simulazione.
6.10.4
Rispetto al caso 1 la classe ComputationalAssembler presenta alcune novità.
Come descritto nel paragrafo 6.10.1, ho eliminato il passo computazionale
C1911, che si occupava del calcolo del prezzo del campionario, ed il passo
C1912, che calcolava il valore delle royalties.
Inoltre in questo modello non sono più necessari i passi computazionali
C1905, C1906, e C1908, che si occupano, rispettivamente, dell’offerta dei
prezzi da parte delle Trading Company, della scelta di BasicBiddings e della
scelta di BasicFactory della Trading Company che deve produrre. Ho perciò
eliminato questi metodi dal file ComputationalAssembler.java.
Infine, ho effettuato alcune modifiche all’oggetto computazionale C1913,
che sono illustrate qui di seguito.
C1913
In questa ricostruzione le collezioni sono consegnate ai licenziatari direttamente da BasicNet. Questo passo computazionale crea un contatore con il
metodo getCounter, controlla che i MetaSamples siano stati disegnati nella
designMatrix e ne memorizza il numero con il metodo getValue; in seguito
controlla con getValue nella seconda riga della basicNetMatrix che l’articolo
sia stato prodotto e ne aggiorna lo status impostando con setValue il valore
4; infine stampa sul monitor l’indicazione che l’articolo in questione è stato
consegnato.
136
137
¨
p u b l i c v o i d c1913 ( )
{
{
{
// Check i f item has been produced
{
System . out . p r i n t l n ( " Item␣␣#" + c o u n t e r + " ␣ with ␣ l a y e r ␣#"
+ l a y e r + " ␣ has ␣ been ␣ d e l i v e r e d " ) ;
}
}
}
done = t r u e ;
} // end1913
§

¦
6.10.5
138
I parametri su cui si basa il modello sono contenuti nel file jesframe.scm e
durante la simulazione sono indicati nel probe del ESFrameModelSwarm e
del ESFrameObserverSwarm.
Le differenze con i parametri del caso 1 sono le seguenti:
• il diverso numero di unità, perché le Trading Company non hanno più
una divisione incaricata della consegna dei prodotti e non esistono più
BasicBiddings e BasicFactory;
• l’indicazione del mark-up, rappresentato dal parametro revenuePerCostUnit, pari a 1.65, che esprime il margine di ricarico che viene applicato
a ciascun costo sostenuto da Basic_jES durante la simulazione;
• il numero inferiore di matrici di memoria;
• la mancanza dei parametri orCriterion e orMatrix;
¨
( list
(
(
)
32
#f
#f
#: checkMemorySize
#f
1
600
578
1
139
)
(
(
#t
#: ticksInATimeUnit
32
#: totalUnitNumber
124
2
#: totalLayerNumber
17
37
#t
#t
#:maxTickInAUnit
2080
#: useWarehouses
#f
#: useNewses
#f
0
1.65
2
)
)
)
;
§

¦
6.11
Caso 3
Il terzo esempio di modello organizzativo mostra una BasicNet con struttura
simile a quella descritta nel caso 1 ma con una diversa origine dei ricavi, simile
al caso 2. Infatti si immagina che la produzione delle collezioni avvenga
in outsourcing e che BasicNet si occupi direttamente della loro vendita ai
licenziatari.
La struttura aziendale è simile a quella del caso 1, con le Trading Com-
pany che sono considerate unità esterne all’azienda con costi nulli. Inoltre, a
differenza del caso 2, l’aggiudicazione della produzione degli articoli avviene
tramite l’asta tra le Trading Company ed è scelta quella che propone il costo
minore di produzione; l’utilizzo dell’asta fornisce anche una buona rappresentazione di quanto accade nella realtà, perché normalmente le aziende che
producono in outsourcing incaricano le imprese che garantiscono loro il minor
costo di produzione.
I ricavi vengono determinati come nel caso 2, applicando ad ogni costo sostenuto durante la simulazione il margine di ricarico calcolato nel
paragrafo 6.10.3.
6.11.1
Le modifiche al modello
Le unità
Il file unitData/unitBasicData.txt è simile a quello descritto nel paragrafo 6.9.1, con la sola differenza che in questo caso le Trading Company sono
rappresentate da una sola unità, perché non devono consegnare le collezioni
ai licenziatari.
Le ricette
La consenga del campionario avviene nello stesso modo illustrato nel paragrafo 6.10.1, con la ricetta mostrata in Figura 6.5, perché i ricavi derivanti
dalla vendita del campionario sono già compresi nel calcolo del margine di
ricarico.
La ricetta 800, che descrive la produzione è uguale alla corrispondente del
caso 1, perché le Trading Company sono scelte in base ai risultati dell’asta.
Per la consegna degli articoli si utilizza la ricetta 900 utilizzata anche nel
caso 2 (paragrafo 6.10.1).
140
6.11.2
141
Rispetto alla classe ComputationalAssembler utilizzata nel caso 1, ho eliminato i passi computazionali C1911 e C1912, che si occupano della contabilizzazione dei ricavi derivanti, rispettivamente, dalla vendita del campionario
e dalle royalties.
Inoltre ho modificato il metodo C1913 nello stesso modo illustrato nel
paragrafo 6.10.4.
6.11.3
I parametri su cui si basa la simulazione sono mostrati qui di seguito:
¨
( list
(
(
32
#f
#f
#: checkMemorySize
#f
1
600
578
1
)
)
(
(
#t
142
#: ticksInATimeUnit
32
#: totalUnitNumber
125
2
#: totalLayerNumber
17
43
#t
#t
#:maxTickInAUnit
2080
#: useWarehouses
#f
#: useNewses
#f
0
1.65
2
#: o r C r i t e r i o n
5
#:orMemoryMatrix
42
)
)
)
;
§

6.12
¦
Risultati della simulazione
Ho eseguito alcune simulazioni per verificare gli effetti provocati dalle mie modifiche al modello. Partendo dal modello di Basic_jES presente in Lamieri
(2002) e Merlo (2003a) ho fatto nuovi esperimenti per migliorare il funzionamento del modello, con l’obiettivo di ridurre il tempo di esecuzione delle
lavorazioni e renderlo pari al tempo previsto dalle ricette che le descrivono.
Primo esperimento
Ho avviato una simulazione per valutare gli effetti che il nuovo calendario
avrebbe avuto sul modello. Osservando il grafico della simulazione che in-
dica il numero di ordini presenti nella waiting list di ciascuna unità si può
notare che i licenziatari non sono in grado di eseguire nei tempi previsti
tutti gli ordini ad essi assegnati, perciò si creano lunghe code (in alcuni momenti anche dell’ordine di 103 ) che causano problemi anche nel resto della
simulazione. Infatti, se i licenziatari non riescono ad effettuare le previsioni
per gli articoli di una collezione prima che BasicForecast le sommi, molti
di questi non sono prodotti perché il totale delle previsioni non supera la
soglia prestabilita da BasicNet. Questa tendenza è confermata se si osserva il file log/report.txt, mostrato in Tabella 6.4, nel quale sono indicati, per
ogni collezione, il numero dei MetaSamples creati, dei prodotti abbandonati
e di quelli effettivamente prodotti: pochi articoli delle collezioni superano la
prima verifica dei licenziatari e perciò il loro sviluppo viene abbandonato.
La Tabella 6.4 evidenzia inoltre dei problemi nel momento in cui Basic_jES deve operare nello stesso momento su più collezioni. Un esempio si
ha nel caso delle collezioni 1, 2, 3 e 4 che, secondo il calendario, devono essere
prodotte contemporaneamente; si può infatti notare che gli articoli realmente prodotti sono pochi, perché per queste collezioni i licenziatari sono messi
sotto pressione da un grande numero di ordini e non riescono ad eseguirli
prima che BasicForecast sommi le previsioni.
Inoltre dal grafico di jES che indica l’andamento del rapporto tra il tempo
effettivo il tempo previsto dalle ricette produttive per l’esecuzione degli ordini
(Figura 6.6) si può notare che i tempi della simulazione sono circa 100 volte
maggiori rispetto a quelli previsti; anche il periodo medio di attesa per gli
ordini è molto alto, come si può notare in Figura 6.7 (la linea blu rappresenta
il tempo medio, quella gialla e rossa il tempo massimo e minimo).
Sulla base di questi risultati si può concludere che il modello così come
è costruito non è in grado di sostenere la reale time-table di BasicNet, e
perciò occorrono alcune modifiche che eliminino i problemi qui indicati per
143
migliorare l’andamento della simulazione.
Secondo esperimento
Dal momento che molti prodotti non sono realizzati a causa delle mancate
previsioni iniziali dei licenziatari, ho inserito due nuove unità per ogni licenziatario a supporto delle due già esistenti; in questo modo le operazioni di
previsione e gli ordini possono essere svolte da due unità ed intuitivamente
si può concludere che le code nelle liste di attesa dei licenziatari dovrebbero
ridursi. Nel file jesframe.scm ho impostato il parametro unitCriterion pari a
2, per far sì che gli ordini siano assegnati all’unità con la lista d’attesa meno
lunga.
Inoltre ho deciso di far slittare di 10 giorni il controllo delle previsioni dei
licenziatari da parte di BasicForecast; questa modifica può essere ragionevole,
in quanto è presumibile che anche nella realtà sia concesso un certo lasso di
tempo ai licenziatari e permette così alle unità che li rappresentano di eseguire
le previsioni su un maggior numero di articoli prima che siano sommate tra
loro.
Ho anche scelto di spostare il momento in cui BasicBiddings effettua la
scelta della vincente 5 giorni dopo l’asta in cui le Trading Company offrono
i prezzi di produzione per gli articoli.
Con queste modifiche l’andamento della simulazione è notevolmente migliorato, infatti osservando il file log/report.txt si può notare che circa il 90%
degli articoli disegnati è stato prodotto.
144
Figura 6.6: Primo esperimento.
145
T empodiesecuzione
Figura 6.7: Primo esperimento. Tempi d’attesa degli ordini
Layer MetaSamples
146
Articoli
Articoli
disegnati
abbandonati
prodotti
1
150
109
29
2
100
99
1
3
30
29
1
4
50
49
1
5
100
73
27
6
150
149
1
7
50
49
1
8
100
99
1
9
50
22
28
10
100
71
0
11
30
2
28
12
50
20
30
13
75
46
29
14
100
68
32
15
150
104
0
16
75
46
29
Tabella 6.4: Articoli creati ed effettivamente prodotti per ogni collezione
Tuttavia permangono ancora alcuni problemi, in quanto, pur essendosi
ridotte, le code nelle waiting list delle unità che rappresentano i licenziatari
in alcune situazioni raggiungono ancora dei livelli molto elevati (dell’ordine
di 102 ), soprattutto nel momento in cui si effettuano gli ordini alle Trading
Company; inoltre il tempo medio di attesa per ogni ricetta (Figura 6.9) e il
rapporto tra il tempo effettivo di esecuzione e quello ipotizzato (Figura 6.8)
sono ancora alti, anche se risultano quasi dimezzati rispetto alla simulazione
precedente.
In particolare, osservando l’andamento del grafico mostrato in Figura 6.8
durante la simulazione, si può notare che le situazioni in cui il modello non è
in grado di rispettare i tempi previsti dalle ricette corrispondono ai momenti
in cui sono chiamati ad operare BasicSamples e i licenziatari. Infatti si può
notare che i ritardi maggiori si registrano nei momenti in cui BasicSamples
crea i MetaSamples della prima collezione e, in seguito, quelli delle collezioni
1, 2, 3, 4 al tick 5.000; infine l’ultimo notevole ritardo, al tick 10.000, è causato
dai licenziatari chiamati a prevedere contemporaneamente per le collezioni
5, 6, 7, 8.
Per migliorare questa situazione occorre inserire nel file unitData/unitBasicData.txt nuove unità per i licenziatari e per BasicSamples, affinché gli
ordini siano eseguiti nei tempi previsti dalle ricette e non si creino code
eccessive nelle waiting list delle unità produttive.
Terzo Esperimento
Ho effettuato nuove modifiche al file unitData/unitBasicData.txt inserendo
altre unità per BasicSamples e per i licenziatari.
BasicSamples è suddivisa in quattro sezioni, ciascuna delle quali si occupa
della creazione di una delle quattro possibili collezioni5 ; per ogni divisione ho
5
vedi paragrafo 6.5
147
Figura 6.8: Secondo esperimento.
148
T empodiesecuzione
aggiunto un’unità in grado di effettuare lo stesso passo di quella già presente,
perciò ora BasicSamples è rappresentata da 8 unità produttive.
Per quanto riguarda i licenziatari ho aggiunto 2 nuove unità in grado di
effettuare le previsioni e altre 2 in grado di effettuare gli ordini, perciò ora i
licenziatari sono rappresentati complessivamente da 8 unità.
Dai risultati della simulazione mostrati in Figura 6.10 si può notare che
i ritardi nei tempi di produzione si sono dimezzati rispetto al caso precedente e sono pari a 30 volte i tempi previsti dalle ricette; tuttavia persistono
i rallentamenti durante le fasi di creazione dei MetaSamples e durante la
formulazione delle previsioni e degli ordini dei licenziatari.
6.13
Considerazioni sui risultati
Dalle simulazioni precedenti si intuisce che ogni volta che raddoppia il numero delle unità produttive i tempi di esecuzione si dimezzano, pertanto,
per ottenere un buon risultato in termini di tempi di produzione, occorre
Figura 6.9: Secondo esperimento. Tempi d’attesa degli ordini
aumentare il numero delle unità che rappresentano i licenziatari e BasicSamples, perché è proprio nei momenti in cui sono chiamate ad operare che si
riscontrano i maggiori ritardi nell’esecuzione delle ricette.
Occorre però fare una distinzione tra i licenziatari e BasicSamples. I
primi sono agenti esterni all’azienda e perciò un aumento delle unità che
li rappresentano non va a minare il risultato della simulazione totale, in
quanto in questa simulazione non si è interessati al funzionamento interno
dei licenziatari, bensì a quello di BasicNet.
Discorso diverso vale per BasicSamples, in quanto è una divisione interna
all’azienda e rappresenta una delle più importanti funzioni aziendali, l’ideazione delle collezioni e la produzione del campionario. Quindi aumentare
le unità nel modello senza particolari motivazioni potrebbe essere sbagliato
e potrebbe portare a delle conclusioni errate sui risultati della simulazione,
nascondendo un problema organizzativo dell’azienda.
Ho pertanto deciso di porre una maggiore attenzione sul funzionamento
di BasicSamples (paragrafo 6.15) e la dottoressa Bruschi mi ha informato che
149
Figura 6.10: Terzo esperimento.
150
T empodiesecuzione
i dipendenti di questa divisione sono 36. Conoscendo questo numero posso
infatti ottenere una migliore specificazione del modello e valutare con più attenzione se il funzionamento di BasicSamples crea dei bottle necks all’interno
dell’azienda.
Per quanto riguarda i licenziatari, ho seguito due metodi di lavoro: in un
primo caso ho continuato ad aggiungere unità come illustrato nei precedenti
paragrafi, nel tentativo di eliminare i ritardi legati alla loro attività (paragrafo 6.14.1); in un secondo momento ho cambiato il mio modus operandi e ho
introdotto il tempo 0 per l’esecuzione delle ricette da parte dei licenziatari
(paragrafo 6.14.2).
6.14
6.14.1
Focus sui licenziatari
Licenziatari con tempo 1
Negli esperimenti che seguono ho raddoppiato di volta in volta il numero di
unità che nel modello rappresentano i licenziatari, con l’obiettivo di eliminare
Figura 6.11: Quarto esperimento.
151
T empodiesecuzione
i ritardi dovuti alla formulazione delle previsioni e degli ordini sulle collezioni.
Con una nuova simulazione ho raddoppiato il numero di unità rappresentative dei licenziatari da 8 a 16, in cui 8 unità prevedono e 8 effettuano
gli ordini. I risultati evidenziano che, come ipotizzato, il ritardo nei tempi di produzione mostrato in Figura 6.11 è nuovamente dimezzato rispetto
all’esperimento eseguito nel paragrafo 6.12.
In seguito ho ulteriormente aumentato il numero delle unità dei licenziatari nel file unitData/unitBasicData.txt portandolo a 32, di cui 16 hanno il
compito di prevedere e le restanti effettuano gli ordini di articoli alle Trading
Company. Come si può notare nella Figura 6.12 il rapporto tra il tempo
di esecuzione e il tempo previsto per le lavorazioni si è ridotto della metà
rispetto al caso precedente (Figura 6.11).
Osservando l’andamento della simulazione, si può notare che i ‘‘picchi’’
di ritardo che si formano nel grafico della Figura 6.12 sono nei momenti in
cui BasicSamples è chiamata ad operare, in particolare:
152
1. all’inizio della simulazione, durante la creazione della collezione 9;
2. poco più tardi, nel momento in cui BasicSamples disegna la collezione
10;
3. prima del tick 5.000, nel momento in cui devono essere ideate contemporaneamente le collezioni 1, 2, 3, 4;
4. intorno al tick 7.500, quando si deve disegnare la collezione 6;
Figura 6.12: Sesto esperimento.
T empodiesecuzione
Per il resto la simulazione non accumula grandi ritardi, se non in due casi
in cui sono chiamati ad operare i licenziatari, poco prima del tick 5.000 con
la previsione delle collezioni 1, 2, 3, 4, e dopo il tick 7.500 quando devono
prevedere per la collezione numero 6.
In una nuova simulazione ho ulteriormente raddoppiato le unità dei licenziatari, ma non ci sono particolari miglioramenti rispetto a quanto mostrato
in Figura 6.12, in quanto ora la maggiore fonte di ritardo è l’attività di
BasicSamples.
6.14.2
Licenziatari con tempo 0
Ho effettuato nuovi esperimenti con il modello creato in Lamieri (2002) e
Merlo (2003a) impostando i tempi di esecuzione delle ricette dei licenziatari
pari a 0. Tutti i passi a tempo 0 sono eseguiti da jES in un solo tick senza
generare code nelle liste d’attesa delle unità.
La ragione è nel fatto che ai fini della simulazione non ci interessa sapere
come operano i licenziatari al loro interno, in quanto l’importante è che essi
eseguano le previsioni e gli ordini nei tempi previsti; pertanto consideriamo
i licenziatari come ‘‘scatole nere’’.
Eseguendo una simulazione si ottiene il risultato mostrato in Figura 6.13;
i ritardi nell’esecuzione delle ricette sono dovuti soltanto a BasicSamples. È
pertanto necessaria una maggiore attenzione alla sua struttura e alla scrittura
delle ricette che la riguardano.
T empodiesecuzione
Figura 6.13: Licenziatari con tempo 0. T empoprevistodallericette
153
6.15
Approfondimento di BasicSamples
Dal momento che i ritardi nella produzione sono causati da BasicSamples,
ho deciso di ‘‘mettere la lente d’ingrandimento’’ su questa divisione.
Ho inserito nel file unitData/unitBasicData.txt 36 unità in grado di eseguire i passi di BasicSamples, ciascuna delle quali rappresenta un dipendente
di questa divisione nella realtà. Ho immaginato che i designers si dividano
in quattro gruppi di nove unità ciascuno e che si occupino separatamente dei
quattro tipi di collezione presenti nel modello di simulazione6 .
Inoltre ho modificato i tempi delle ricette che descrivono la creazione delle
collezioni, ricalcolando i tempi di produzione secondo i dati sulla BasicNet
reale. Secondo le statistiche di BasicNet riferite al 20027 , nel primo semestre
sono stati creati 3338, perciò ho supposto che nell’intero anno BasicSamples
produca 6676 articoli. In seguito ho calcolato le ore lavorative nello stesso
anno, partendo dall’ipotesi che le ore di lavoro giornaliere siano 8 e che si
lavori per 5 giorni alla settimana, dal lunedi al venerdi. Pertanto si ottiene
che:
Ore lavorative = (giorni lavorativi nel 2002 ) × (ore lavorative al giorno) =
= 260 × 8 = 2080
Dopo aver calcolato le ore lavorative annuali occorre calcolare il numero
di articoli che si ipotizza siano creati da un designer nel corso di un anno,
dividendo il numero di articoli prodotti nel 2002 per il numero di dipendenti
di BasicSamples:
6676 ∼
= 185
36
Con questi dati è possibile calcolare il numero di ore necessario ad un
ArticoliP erDesigner =
designer per la creazione di un articolo nel seguente modo:
6
7
vedere paragrafo 6.5
154
h=
2080 ∼
= 11, 24
185
Perciò si può concludere che, in base a queste ipotesi molto semplicistiche,
un designer ha bisogno di 11,24 ore per creare un MetaSample o, trasformandole, di 11 ore e 15 minuti circa. Traducendo le ore in minuti totali e poi
in tick della simulazione, risulta che un articolo viene creato in 675 minuti e
quindi in un numero di tick pari a:
tick =
675
= 45
15
dato che 1 tick = 15 minuti.
Perciò occorre riscrivere nel file recipeData/recipes.xls le ricette che descrivono le lavorazioni di BasicSamples e modificare i tempi di produzione,
in modo che le unità impieghino 45 tick per lo sviluppo di ogni articolo.
Effettuando una simulazione con questo nuovo modello e mantenendo la
struttura dei licenziatari presentata nel paragrafo 6.14.2, si ottiene l’andamento della simulazione mostrato in Figura 6.14. Le code legate all’attività dei licenziatari sono eliminate, pertanto i ritardi sono dovuti soltanto
all’attività di BasicSamples.
Una conclusione che si può trarre dall’analisi svolta è che BasicSamples
potrebbe rappresentare un ‘‘collo di bottiglia” nel funzionamento della BasicNet reale, dal momento che non è in grado di eseguire le operazioni nei
tempi previsti dalle ricette.
È però necessario ricordare che questi risultati hanno la base nelle assunzioni fatte precedentemente, che potrebbero anche discostarsi da quanto
avviene nella realtà; infatti per eliminare i ritardi nella produzione i designers potrebbero lavorare più di 8 ore al giorno e non solo per 5 giorni alla
settimana o, ancora, potrebbero esserci articoli la cui produzione richiede un
tempo minore e altri che necessitano di tempi maggiori.
155
Figura 6.14: Approfondimento di Basicsamples.
156
T empodiesecuzione
Pertanto si può concludere che BasicSamples rappresenta un bottle neck
per BasicNet nel solo momento in cui tutte le ipotesi fatte durante la formulazione del modello sono verificate anche nella realtà. In tutte le altre
situazioni sarebbe necessario specificare nuove ipotesi e considerare i nuovi
risultati della simulazione.
Da queste considerazioni si intuisce quale sia la grande importanza della
simulazione ad agenti nella formulazione delle decisioni aziendali: una volta
creato il modello dell’azienda è sufficiente cambiare alcuni particolari nella
struttura generale per poter essere in grado di valutare quali potrebbero
essere gli effetti delle scelte della direzione generale.
6.16
Analisi finale
Dopo aver costruito i tre modelli di ‘‘azienda virtuale’’ è stata fatta un’analisi
finale dei costi e dei ricavi originati dai tre esempi di Basic_jES. I dati tecnici
riferiti ad essa sono contenuti negli allegati a questa tesi.
Lo studio presentato nelle pagine che seguono è una prima analisi del
modello formalizzato e descritto nei paragrafi precedenti; l’analisi definitiva
dei tre modelli organizzativi è mostrata nell’allegato a questa tesi e contiene
le modifiche illustrate in Balla (2004). Queste modifiche sono di carattere
metodologico e riguardano il funzionamento interno di jES.
In questo modello le ricette sono eseguite indistintamente per tutti gli
articoli di una collezione perché non c’è il modo di scegliere di simulare soltanto le attività riferite ai MetaSamples non abbandonati. Le modiche in
Balla (2004) consentono di eliminare questo difetto ed eseguire soltanto le
ricette riferite agli articoli che devono essere prodotti, grazie all’uso della
metodologia della ‘‘ricetta che lancia ricetta”; con questo sistema ogni volta
che deve essere svolta una fase produttiva si lancia una ricetta che controlla
lo status degli articoli e, in base ad esso, sceglie per ognuno di essi se lanciare
la ricetta.
Questa modifica comporta un importante miglioramento per il modello
dal punto di vista metodologico, ma a livello di analisi finale non dovrebbe
creare grandi cambiamenti sui costi, perché le unità di BasicNet che devono
effettuare le lavorazioni non hanno costi variabili, perciò la loro attività risulta ininfluente sul computo dei costi totali. Una variazione, anche se non
grandissima, si potrà riscontrare nel caso 2, in cui le Trading Company sono
unità interne e hanno costi variabili.
Per quanto riguarda i ricavi, l’analisi definitiva potrebbe avere alcune
differenze rispetto a questa, perché in quel caso si considereranno soltanto i
ricavi relativi agli articoli realmente venduti.
6.16.1
Caso 1
Questo modello rappresenta la BasicNet reale ricostruita al computer. I costi
imputati sono soltanto quelli relativi alle divisioni dot.com, tutti fissi con
157
l’esclusione di BasicSamples8 , e i ricavi derivano dalla vendita dei campionari
e dalle royalties.
Per ottenere i dati relativi ai costi occorre analizzare i file della simulazione
Costs/totalDailyCosts.txt, in cui sono indicati i costi giornalieri dell’azienda,
e Costs/totalCosts.txt, dove si trova la somma cumulata dei costi giorno per
giorno.
I ricavi sono indicati nel file log/grossSales.txt. La struttura di questo
file è mostrata nella Tabella 6.5: per ogni voce sono indicati il tick della
simulazione in cui si è conseguito il ricavo e il ricavo stesso; questa struttura
risulta molto utile nel momento in cui si deve fare l’analisi di costi e ricavi,
perché grazie ad essa è possibile contabilizzare i ricavi nei giorni in cui si sono
realizzati.
tick | ricavo
Tabella 6.5: File log/grossSales
Se si osserva la Figura 6.15, si può notare che i costi crescono con un
andamento abbastanza regolare, dovuto alla forte presenza di costi fissi nelle
attività di BasicNet e al numero esiguo di unità che presentano costi variabili. La curva dei ricavi cresce soltanto nei momenti in cui si consegnano i
campionari e si incassano le royalties; in particolare, gli aumenti più grandi
si verificano intorno ai giorni 420 e 550, periodi in cui la BasicNet simulata
riceve contemporaneamente le royalties per quattro collezioni.
La Figura 6.16 mostra l’andamento dei costi e dei ricavi giorno per giorno.
I costi dal giorno 271 fino alla fine sono costanti e sono pari alla somma dei
costi fissi calcolati per ogni giorno; nei giorni precedenti i costi sono invece
incrementati dall’operatività di BasicSamples, unica divisione alla quale sono
imputati costi variabili, quando è chiamata a creare gli articoli.
8
158
Figura 6.15: Andamento di costi, ricavi e profitti totali (Caso 1)
Figura 6.16: Andamento di costi, ricavi e profitti giornalieri (Caso 1)
159
Le curve dei ricavi e dei profitti presentano andamenti simili e, ovviamente, sono positivi nei soli giorni in cui BasicNet vende i campionari e riceve le
royalties.
I profitti totali non sono mai positivi e l’azienda chiude i due anni con
un’ingente perdita; osservando il loro andamento giornaliero, si nota che
l’azienda ottiene profitti positivi soltanto per 19 giorni della simulazione.
6.16.2
Caso 2
La BasicNet simulata in questo caso si comporta come un’azienda tradizionale che produce e vende direttamente tutti i prodotti. Perciò i costi di
produzione sono rappresentati dai costi delle divisioni incrementati da quelli
relativi alle Trading Company9 e i ricavi sono calcolati in base ad un margine
di ricarico del 65%10 .
I costi si ricavano nello stesso modo illustrato nel precedente paragrafo,
mentre i ricavi sono indicati nei file Revenue/dailyRevenues.txt, in cui sono
indicati i ricavi giornalieri, e Revenue/totalRevenues.txt, dove è indicata la
loro somma cumulata giorno per giorno.
L’andamento della curva dei costi totali mostrata Figura 6.17 è simile a
quella del caso precedente ma, se confrontate, si può notare che in questo
esempio la curva presenta una minore inclinazione; la causa sta nella minore
componente di costi fissi, dal momento che in questa azienda non esistono
BasicFactory e BasicBiddings.
Se si guardano soltanto i costi totali non si riesce a notare la presenza dei
costi originati dalla produzione diretta degli articoli che è più visibile nella Figura 6.18, dove la curva dei costi giornalieri ha dei ‘‘picchi” in corrispondenza
dei momenti in cui le Trading Company sono chiamate ad operare.
9
10
160
161
162
Dalla Figura 6.17 e dalla Figura 6.18 si nota inoltre che i ricavi crescono
di più nei primi 300 giorni per poi rimanere abbastanza stabili fino alla fine
della simulazione. La differenza con il caso 1 è motivata nella diversa origine
dei ricavi per questi due tipi di azienda; nel primo caso la BasicNet simulata,
come quella reale, contabilizza i ricavi quando vende il campionario e quando
riceve le royalties, ora invece i ricavi sono calcolati in base ad un mark-up sui
costi, perciò quando i costi sono alti lo sono anche i ricavi e viceversa, come
mostra la Figura 6.18.
In questo caso i profitti totali sono negativi, ma se si osserva l’andamento dei profitti giornalieri si nota che essi risultano positivi per 51 giorni,
ottenendo un risultato migliore rispetto al caso precedente.
6.16.3
Caso 3
In questo ultimo esempio di modello organizzativo l’ipotetica BasicNet fa
produrre in outsourcing i propri prodotti e li vende direttamente al pubblico. La configurazione dei costi è uguale a quella presentata nel caso della
BasicNet reale e i ricavi sono calcolati in base ad un ricarico pari al 65%11 .
Se si osservano le curve dei costi e dei ricavi si può notare che questo terzo
modello organizzativo rappresenta la ‘‘miscela’’ di quelli precedenti. Infatti
nella Figura 6.19 e nella Figura 6.20 si nota che, come ipotizzato, i costi
sono uguali a quelli mostrati per il caso 1. I ricavi al contrario hanno un
andamento simile a quelli del esempio precedente.
Le differenze tra i ricavi di questa azienda e quella del caso 2 si notano
nella Figura 6.20 e sono concentrate nella seconda metà della simulazione,
probabilmente dovute alla mancanza, in questo caso, dei costi legati alla
produzione degli articoli.
L’azienda simulata chiude i due anni con una forte perdita complessiva,
11
163
come nei casi precedenti, e i profitti giornalieri risultano positivi soltanto per
30 giorni, cioè in numero minore rispetto al caso precedente.
164
Appendice
Si riporta il codice sorgente dei file ComputationalAssembler.java aggiornati
con le modifiche illustrate nel Capitolo 6 di questa tesi. Per ogni modello
di azienda è stata creata una classe ComputationalAssembler che contiene i
passi computazionali necessari durante la simulazione.
Caso 1
Listing 6.8: ComputationalAssembler.java Caso 1
¨
//
ComputationalAssembler . j a v a
i m p o r t swarm . G l o b a l s ;
i m p o r t swarm . d e f o b j . Zone ;
i m p o r t swarm . o b j e c t b a s e . SwarmObjectImpl ;
i m p o r t swarm . c o l l e c t i o n s . L i s t I m p l ;
i m p o r t swarm . c o l l e c t i o n s . L i s t I n d e x ;
i m p o r t swarm . random . N o r m a l D i s t I m p l ;
import java . lang . Float ;
import java . i o . ∗ ;
import java . u t i l . ∗ ;
/∗ ∗
∗ The ComputationalAssembler c l a s s
i n s t a n c e s make
∗ c o m p u t a t i o n a l p r o c e s s e s ; we have a c o m p u t a t i o n a l a s s e m b l e r
∗ i n s t a n c e f o r each u n i t
∗
∗
∗ @author
∗ Marco Lamieri<a h r e f="m a i l t o : lamieri@econ . u n i t o . i t "></a>
∗ Francesco Merlo<a h r e f="m a i l t o : merlo@econ . u n i t o . i t "></a>
∗ @version 0 . 9 . 7 . 3 1 . b ( BasicJVE 1 . 0 )
∗/
public
class
ComputationalAssembler extends ComputationalAssemblerBasic
{
//Our MemoryMatrixes
MemoryMatrix d e s i g n M a t r i x ,
orMatrix ,
basicNetMatrix , tcMatrix ,
agentMatrix ;
165
APPENDICE
166
//A normal d i s t r i b u t i o n
f o r random numbers
N o r m a l D i s t I m p l normal ;
// g r o s s S a l e s
public
F i l e management
boolean
FileWriter
grossSalesLogFileOpen = f a l s e ;
g r o s s S a l e s L o g=n u l l ;
i n t samplesN =0;
float
sampleSales = 0;
float
itemSales = 0;
p u b l i c MyWriter r e p o r t=n u l l ;
/∗ ∗
∗ the constructor
f o r ComputationalAssembler
∗/
public
C o m p u t a t i o n a l A s s e m b l e r ( Zone aZone ,
O r d e r D i s t i l l e r od , ESFrameModelSwarm mo)
{
// C a l l t h e c o n s t r u c t o r
f o r the parent c l a s s .
s u p e r ( aZone , od , mo ) ;
normal = new N o r m a l D i s t I m p l ( g e t Z o n e ( ) ) ;
}
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// BasicJES Computational codes
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
/∗ ∗ c o m p u t a t i o n a l o p e r a t i o n s w i t h code −1901 
∗
∗
this
∗
t h e unique r e c e i v e d matrix and s e t
c o m p u t a t i o n a l code increment 1 by 1 p o s i t i o n 0 , 0 o f
the
status
t o done
∗/
public
void c1901 ( )
{
d e s i g n M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
// Zeroing t h e c o u n t e r
i f empty
i f ( d e s i g n M a t r i x . getEmpty ( l a y e r , 0 , 0 ) )
designMatrix . setValue ( layer , 0 , 0 , 0 . 0 ) ;
int
counter = ( i n t ) designMatrix . getValue ( layer , 0 , 0 ) ;
c o u n t e r ++;
//Here we s t o r e t h e number o f MetaSample produced
designMatrix . setValue ( layer ,0 ,0 , counter ) ;
System . o u t . p r i n t l n ( " MetaSample␣#" + c o u n t e r + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r
+ " ␣ h a s ␣ been ␣ drawn " ) ;
done=t r u e ;
} // end c1901
∗
∗
this
c o m p u t a t i o n a l code d i a l
∗
∗/
public
void c1902 ( )
with licensee ’ s p r e d i c t i o n s .
APPENDICE
167
{
a g e n t M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
// Making p r e d i c t i o n
for
a v a i l a b l e MetaSample
{
// S w i t c h i n g t o an o t h e r
int
article
j = getCounter ( agentMatrix , 1 ) ;
//The l i c e n s e e
int
prediction
f o r e c a s t = ( i n t ) normal . g e t S a m p l e W i t h M e a n $ w i t h V a r i a n c e ( 5 0 0 , 9 0 0 0 0 0 ) ;
//Min v a l u e
if
( f o r e c a s t < 10)
forecast = 10;
//Max v a l u e
if
( f o r e c a s t > 25000)
f o r e c a s t = 25000;
// S t o r i n g t h e p r e d i c t i o n
agentMatrix . setValue ( layer , 1 , j , f o r e c a s t ) ;
System . o u t . p r i n t l n ( " L i c e n s e e ␣#" + myUnit . getUnitNumber ( ) + " ␣ f o r e c a s t e d ␣ "
+ f o r e c a s t + " ␣ f o r ␣ MetaSample␣#" + j + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r ) ;
// End o f
predictions
done=t r u e ;
} // Waiting f o r some MetaSample −> done=f a l s e
} // end c1902
∗
this
∗
c o m p u t a t i o n a l code sums up p r e d i c t i o n s .
∗
∗/
public
void c1903 ( )
{
f l o a t sum = 0 ;
int
threshold = 18000;
boolean endForecast = true ;
b a s i c N e t M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
getMemoryMatrixAddress ( 3 6 ) ;
// G e t t i n g t h e number o f
int
articles
for ( int
j = 1 ; j <= c o u n t e r
;
j ++)
APPENDICE
168
{
for ( int
t = 1 ; t < = 3 5 ; t++)
{
MemoryMatrix a g e n t M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
getMemoryMatrixAddress ( t ) ;
// Checking
if
the
l i c e n s e e made a p r e d i c t i o n
for
t h i s MetaSample
i f ( ! ( a g e n t M a t r i x . getEmpty ( l a y e r , 1 , j ) ) )
{
sum = sum + a g e n t M a t r i x . g e t V a l u e ( l a y e r , 1 , j ) ;
}
}
// S t o r i n g
total
p r e d i c t i o n s i n b a s i c N e t Matrix
b a s i c N e t M a t r i x . s e t V a l u e ( l a y e r , 1 , j , sum ) ;
// Checking
if
i f MetaSample can be produced
( sum > t h r e s h o l d )
{
basicNetMatrix . setValue ( layer , 2 , j , 1 ) ;
System . o u t . p r i n t l n ( " MetaSample␣#" + j + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r +
" ␣ can ␣ be ␣ produced , ␣ f o r e c a s t=" + sum + " ␣ s t a t u s =1" ) ;
}
else
{
" ␣ can ␣NOT␣ be ␣ produced , ␣ f o r e c a s t=" + sum + " ␣ s t a t u s =0" ) ;
}
// Waiting
for ( int
all
predictions
t = 1 ; t < = 3 5 ; t++)
{
i f ( a g e n t M a t r i x . getEmpty ( l a y e r , 1 , j ) )
endForecast = f a l s e ;
}
if
( endForecast )
{
System . o u t . p r i n t l n ( " MetaSample␣#" + j + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r
+ " ␣ f o r e c a s t e d ␣ by ␣ a l l ␣ l i c e n s e e " ) ;
done=t r u e ;
}
sum = 0 ;
}
}
// end c1903
∗
∗
this
∗
s e t 1 t o row 2 matrix i n pos 1 ∗
c o m p u t a t i o n a l code check t r e s h o l d and i f
∗
1 cell
∗
whit a counter in p o s i t i o n ( 0 , 1 )
f o r each number o f row read i n matrix i n pos 0 ( 0 , 0 ) ,
∗/
public
void c1904 ( )
{
float
above
and s e t done=t r u e .
val ;
APPENDICE
169
int
article
i = getCounter ( basicNetMatrix , 1 ) ;
// check t h e number o f i t e m s and t h e
status
i f ( ! d e s i g n M a t r i x . getEmpty ( l a y e r , 0 , 0 ) & & ! b a s i c N e t M a t r i x . getEmpty ( l a y e r , 2 , i ) )
{
i f ( i <= d e s i g n M a t r i x . g e t V a l u e ( l a y e r , 0 , 0 ) & & b a s i c N e t M a t r i x . g e t V a l u e ( l a y e r , 2 , i ) = = 1 )
{
System . o u t . p r i n t l n ( " U n i t␣#" + myUnit . getUnitNumber ( ) + " ␣ p r o d u c e d ␣ MetaSample␣#" + i
+ " ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " , ␣ s t a t u s =2" ) ;
basicNetMatrix . setValue ( layer , 2 , i , 2 ) ;
done=t r u e ;
}
else
{
System . o u t . p r i n t l n ( " U n i t␣#" + myUnit . getUnitNumber ( ) + " ␣NOT␣ p r o d u c e d ␣ MetaSample␣#"
+ i + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " , ␣ s t a t u s =1" ) ;
}
}
}
// end c1904
∗
∗ This c o m p u t a t i o n a l code d i a l s
w i t h TC o f f e r −p r i c e
∗/
public
void c1905 ( )
{
float
o f f e r P r i c e , random ;
t c M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
//Making an o f f e r −p r i c e
for
available
articles
{
int
for ( int
i = 1 ; i <=c o u n t e r ;
i ++)
{
i f ( ! b a s i c N e t M a t r i x . getEmpty ( l a y e r , 2 , i ) )
APPENDICE
170
{
i f ( basicNetMatrix . getValue ( layer , 2 , i ) > 0)
{
//The o f f e r −p r i c e
o f f e r P r i c e = ( i n t ) normal . g e t S a m p l e W i t h M e a n $ w i t h V a r i a n c e ( 7 , 1 0 ) ;
//Min v a l u e
if
( o f f e r P r i c e <1)
offerPrice = 1;
//Max v a l u e
if
( o f f e r P r i c e >20)
o f f e r P r i c e =20;
// S t o r i n g t h e o f f e r −p r i c e o f t h e TC
tcMatrix . setValue ( layer , 1 , i ,
offerPrice );
System . o u t . p r i n t l n ( " U n i t␣#" + myUnit . getUnitNumber ( )
+ " ␣ o f f e r ␣ p r i c e ␣ f o r ␣ MetaSample␣#" + i +
" ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " ␣ i s ␣ $ "
+ offerPrice );
}
else
+ " ␣ can ␣ n o t ␣make␣ an ␣ o f f e r ␣ f o r ␣ Metasample␣#" + i +
" ␣ w i t h ␣ l a y e r ␣#" + l a y e r
}
}
done=t r u e ;
}
// Waiting f o r some MetaSample −> done=f a l s e
}
// end c1905
∗ This c o m p u t a t i o n a l code d i a l
w i t h t h e b i d d i n g phase
∗/
public
void c1906 ( )
{
MemoryMatrix c h o i c e M a t r i x ;
o r M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
// Checking MetaSamples
{
int
for ( int
i = 1 ; i <=c o u n t e r ;
i ++)
{
int
choice = 0;
float
o f f e r =0;
// Checking t h e
status
{
);
APPENDICE
171
{
//Here we make t h e b i d d i n g
for ( int
t = 1 ; t < = 5 ; t++)
{
MemoryMatrix t c M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
i f ( ! t c M a t r i x . getEmpty ( l a y e r , 1 , i ) )
{
i f ( tcMatrix . getValue ( layer , 1 , i ) < o f f e r
||
o f f e r ==0)
{
o f f e r = tcMatrix . getValue ( layer , 1 , i ) ;
choice = t ;
}
}
}
// Checking t h e TC chosen
{
i f ( b a s i c N e t M a t r i x . g e t V a l u e ( l a y e r , 2 , i ) > 0 & & ( ! ( c h o i c e ==0)))
{
// G e t t i n g
its
offer
price
...
c h o i c e M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
getMemoryMatrixAddress ( c h o i c e ) ;
float
o f f e r P r i c e = choiceMatrix . getValue ( layer , 1 , i ) ;
// . . .
storing
it
i n b a s i c N e t Matrix
...
basicNetMatrix . setValue ( layer , 3 , i , o f f e r P r i c e ) ;
// . . . and i n t h e orMatrix
orMatrix . setValue ( layer , 1 , i , choice ) ;
System . o u t . p r i n t l n ( " T r a d i n g ␣Company␣#" + o r M a t r i x . g e t V a l u e ( l a y e r , 1 , i ) +
" ␣ h a s ␣ been ␣ c h o s e n ␣ f o r ␣ MetaSample␣#" + i + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " ␣ p r i c e ␣ "
+ basicNetMatrix . getValue ( layer , 3 , i ) ) ;
}
}
}
}
}
done=t r u e ;
}
}
// end c1906
∗
this
∗
with licensee ’ s
first
order .
∗
∗/
public
void c1907 ( )
{
APPENDICE
172
{
int
if
( ! b a s i c N e t M a t r i x . getEmpty ( l a y e r , 2 , j ) )
{
//Check i f
if
the
licensee
received the
r e l a t e d MetaSample
( b a s i c N e t M a t r i x . g e t V a l u e ( l a y e r , 2 , j ) >1)
{
int
o r d e r 1 = ( i n t ) normal . g e t S a m p l e W i t h M e a n $ w i t h V a r i a n c e ( 5 0 0 , 9 0 0 0 0 0 ) ;
//Min v a l u e
if
( o r d e r 1 <10)
order1 = 10;
//Max v a l u e
if
( o r d e r 1 >25000)
order1 = 25000;
if
( b a s i c N e t M a t r i x . getEmpty ( l a y e r , 4 , j ) )
int
totOrder1 = ( i n t ) basicNetMatrix . getValue ( layer , 4 , j ) + order1 ;
System . o u t . p r i n t l n ( "The ␣1 s t ␣ o r d e r ␣ o f ␣ L i c e n s e e ␣#" + myUnit . getUnitNumber ( )
+ " ␣ i s ␣ " + o r d e r 1 + " ␣ f o r ␣ i t e m␣#" + j + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " ␣ t o t O r d e r␣#"
+t o t O r d e r 1 ) ;
done=t r u e ;
}
// The a r t i c l e can not be ordered −> done=f a l s e
}
}
}
// end c1907
∗
this
∗
w i t h or branch c h o i c e .
∗
∗/
public
void c1908 ( )
{
APPENDICE
173
{
// S w i t c h i n g t o another
int
article
i = getCounter ( orMatrix , 0 ) ;
i f ( i <= d e s i g n M a t r i x . g e t V a l u e ( l a y e r , 0 , 0 ) )
{
{
//Check i f
t h e item can be produced ( s t a t u s >1)
i f ( b a s i c N e t M a t r i x . g e t V a l u e ( l a y e r , 2 , i ) > 1 & & ! o r M a t r i x . getEmpty ( l a y e r , 1 , i ) )
{
float
branch = orMatrix . getValue ( l a y e r , 1 , i ) ;
orMatrix . s e t V a l u e ( l a y e r , 1 , 0 , branch ) ;
System . o u t . p r i n t l n ( " Branch␣␣#" + o r M a t r i x . g e t V a l u e ( l a y e r , 1 , 0 ) +
" ␣ p r o d u c e d ␣ i t e m␣#" + i + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r ) ;
basicNetMatrix . setValue ( layer , 2 , i , 3 . 0 ) ;
done = t r u e ;
}
}
// The a r t i c l e can not be produced −> done=f a l s e
}
}
}
//end c1908
∗
this
∗
w i t h l i c e n s e e ’ s second o r d e r .
∗
∗/
public
void c1909 ( )
{
int
threshold = 100;
int
if
( ! d e s i g n M a t r i x . getEmpty ( l a y e r , 0 , 0 ) )
{
if
( j <= d e s i g n M a t r i x . g e t V a l u e ( l a y e r , 0 , 0 ) )
{
// Checks
if
if
the
l i c e n s e e has a l r e a d y done t h e
first
order
( ! a g e n t M a t r i x . getEmpty ( l a y e r , 2 , j ) )
{
int
s e l e c t = ( i n t ) normal . g e t S a m p l e W i t h M e a n $ w i t h V a r i a n c e ( 1 0 0 , 5 0 0 0 0 ) ;
APPENDICE
174
// d e c i d e t o do or not another o r d e r
if
( select > threshold )
{
int
//Min v a l u e
if
( o r d e r 2 <10)
order2 = 10;
//Max v a l u e
if
( o r d e r 2 >25000)
order2 = 25000;
if
int
totOrder2 = ( i n t )
System . o u t . p r i n t l n ( "The ␣2 nd␣ o r d e r ␣ o f ␣ L i c e n s e e ␣#" + myUnit . getUnitNumber ( )
+ totOrder2 ) ;
} //end i f ( s e l e c t )
else
{
if
} //end e l s e
int
totOrder1 = ( i n t ) basicNetMatrix . getValue ( layer , 4 , j ) ;
int
int
totOrder = totOrder1 + totOrder2 ;
} //end i f ( c h e c k i n g
first
order )
}
}
done = t r u e ;
} // end c1909
∗
∗
∗
∗/
This c o m p u t a t i o n a l code p r i n t s t h e Report and s t o p s t h e s i m u l a t i o n .
APPENDICE
public
175
void c1910 ( )
{
try
{
r e p o r t = new MyWriter ( " l o g / r e p o r t . t x t " ) ;
report .
w r i t e ( " L a y e r ␣ | ␣ MetaSampleN ␣ | ␣ S t a t u s 0 ␣ | ␣ S t a t u s 1 ␣ | ␣ S t a t u s 2 ␣ | ␣ S t a t u s 3 ␣ | ␣ S t a t u s ␣ 4 ␣ ␣ \ n" ) ;
}
catch ( IOException e )
{
System . o u t . p r i n t l n ( e ) ;
}
for ( int
l n = 1 ; l n <=16; l n ++)
{
i n t metaSamplesN =0;
int [ ]
status ;
s t a t u s = new i n t [ 5 ] ;
for ( int
s = 0 ; s <=4; s++)
status [ s ]=0;
i f ( ! d e s i g n M a t r i x . getEmpty ( l n , 0 , 0 ) )
metaSamplesN = ( i n t ) d e s i g n M a t r i x . g e t V a l u e ( l n , 0 , 0 ) ;
for ( int
i t e m = 1 ; item <=150; i t e m++)
{
i f ( ! b a s i c N e t M a t r i x . getEmpty ( l n , 2 , i t e m ) )
s t a t u s [ ( i n t ) basicNetMatrix . getValue ( ln , 2 ,
item )]++;
}
String
t e x t = l n + " ␣ | ␣ " + metaSamplesN + " ␣ | ␣ " + s t a t u s [ 0 ] + " ␣ | ␣ " + s t a t u s [ 1 ]
+ " ␣ | ␣ " + s t a t u s [ 2 ] + " ␣ | ␣ " + s t a t u s [ 3 ] + " ␣ | ␣ " + s t a t u s [ 4 ] + " ␣\ n" ;
try
{
report . write ( text ) ;
}
{
}
}
try
{
report . close ( ) ;
}
{
APPENDICE
176
}
System . o u t . p r i n t l n ( " ∗∗∗∗∗␣THIS␣ I S ␣THE␣END! ␣ ∗ ∗ ∗ ∗ ∗ " ) ;
StartESFrame . eSFrameObserverSwarm . g e t C o n t r o l P a n e l ( ) . s e t S t a t e S t o p p e d ( ) ;
done = t r u e ;
} //end c1910
∗
This c o m p u t a t i o n a l code c a l c u l a t e s
∗
gross
s a l e s from samples .
∗
∗/
public
void c1911 ( )
{
float
int
s a m p l e P r i c e = ( f l o a t ) normal . g e t S a m p l e W i t h M e a n $ w i t h V a r i a n c e ( 3 5 , 6 ) ;
counter = getCounter ( basicNetMatrix , 4 ) ;
logOpen ( t r u e , " l o g / g r o s s S a l e s . t x t " ) ;
String
t e x t = G l o b a l s . env . g e t C u r r e n t T i m e ( ) + " ␣ | ␣ " + s a m p l e P r i c e + " ␣\ n" ;
try
{
}
{
}
done = t r u e ;
} //end c1911
∗
This c o m p u t a t i o n a l code c a l c u l a t e s
∗
the value of
royalties .
∗
∗/
public
void c1912 ( )
{
APPENDICE
177
int
if
{
if
( c o u n t e r <= d e s i g n M a t r i x . g e t V a l u e ( l a y e r , 0 , 0 ) )
{
i f ( ! b a s i c N e t M a t r i x . getEmpty ( l a y e r , 2 , c o u n t e r )
&& ! b a s i c N e t M a t r i x . getEmpty ( l a y e r , 3 , c o u n t e r ) & & ! b a s i c N e t M a t r i x .
getEmpty ( l a y e r , 6 , c o u n t e r ) )
{
if
( basicNetMatrix . getValue ( layer , 2 , counter ) > 3.0)
{
double
itemPrice =
basicNetMatrix . getValue ( layer , 3 , counter ) ∗ 2 . 2 ;
double totRevenues = itemPrice ∗ basicNetMatrix . getValue ( layer , 6 , counter ) ;
double
itemSales =
( totRevenues ∗ 0 . 1 ) ;
System . o u t . p r i n t l n ( " R o y a l t i e s ␣ f o r ␣ i t e m ␣␣#" + c o u n t e r + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r
+ " ␣ have ␣ been ␣ payed ␣ by ␣ l i c e n s e e s " ) ;
String
t e x t = G l o b a l s . env . g e t C u r r e n t T i m e ( ) + " ␣ | ␣ " + i t e m S a l e s + " ␣\ n" ;
logOpen ( f a l s e , " l o g / g r o s s S a l e s . t x t " ) ;
try
{
}
{
}
}
}
}
}
done = t r u e ;
} //end c1912
∗
This c o m p u t a t i o n a l code d i s t r i b u t e s
∗
items to the
licensees .
∗
∗/
public
void c1913 ( )
{
APPENDICE
178
int
if
{
{
//Check i f
item has been produced
{
float
tc = orMatrix . getValue ( layer , 1 , counter ) ;
orMatrix . setValue ( layer , 1 , 0 , tc ) ;
System . o u t . p r i n t l n ( " Item␣␣#" + c o u n t e r + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r
+ " ␣ h a s ␣ been ␣ d e l i v e r e d ␣ by ␣ T r a d i n g ␣Company␣ " + o r M a t r i x . g e t V a l u e ( l a y e r , 1 , 0 ) ) ;
}
}
}
done = t r u e ;
} //end c1913
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// P r i v a t e f u n c t i o n s
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
//The c o u n t e r
i s used i n some c o m p u t a t i o n l code i n o r d e r t o t a k e a c t i o n s
// on d i f f e r e n t
private
int
article
with only a recipe
g e t C o u n t e r ( MemoryMatrix c u r r e n t M a t r i x ,
i n t row )
{
i f empty
i f ( c u r r e n t M a t r i x . getEmpty ( l a y e r , row , 0 ) )
c u r r e n t M a t r i x . s e t V a l u e ( l a y e r , row , 0 , 0 . 0 ) ;
//Here we increment t h e c o u n t e r
int
c o u n t e r = ( i n t ) c u r r e n t M a t r i x . g e t V a l u e ( l a y e r , row , 0 ) ;
c o u n t e r ++;
//The c o u n t e r must be l e s s than t h e number o f MetaSample
c u r r e n t M a t r i x . s e t V a l u e ( l a y e r , row , 0 , c o u n t e r ) ;
return
counter ;
}
private
v o i d c h e c k M a t r i x e s ( i n t code ,
int
numberOfMatrixes )
{
i f ( pendingComputationalSpecificationSet .
getNumberOfMemoryMatrixesToBeUsed ( ) ! = numberOfMatrixes )
{
System . o u t . p r i n t l n ( " Code␣−"+ c o d e + " ␣ r e q u i r e s ␣ " + numberOfMatrixes + " ␣ m a t r i x ; ␣ "
+ p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t . getNumberOfMemoryMatrixesToBeUsed ( )
+ " ␣ f o u n d ␣ i n ␣ o r d e r ␣#␣" + p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t . getOrderNumber ( ) ) ;
APPENDICE
179
}
}
private
v o i d logOpen ( b o o l e a n
eraseFile ,
String
fileName )
{
File
f i l e O u t = new F i l e ( f i l e N a m e ) ;
i f ( ! t h i s . g r o s s S a l e s L o g F i l e O p e n && e r a s e F i l e )
{
try
{
FileWriter
erase
= new F i l e W r i t e r ( f i l e O u t ,
false );
erase . close ( ) ;
}
{
}
}
try
{
g r o s s S a l e s L o g = new F i l e W r i t e r ( f i l e O u t ,
this . grossSalesLogFileOpen = true
true ) ;
;
}
{
}
}
}
§

¦
Caso 2
¨
//
/∗ ∗
∗ c o m p u t a t i o n a l p r o c e s s e s ; we have a computationa a s s e m b l e r i n s t a n c e f o r
∗ each u n i t
∗
∗
∗ @author
APPENDICE
180
∗/
public
class
{
basicNetMatrix , tcMatrix , orMatrix ,
agentMatrix ;
public
F i l e management
boolean
FileWriter
i n t samplesN =0;
float
sampleSales = 0;
float
itemSales = 0;
/∗ ∗
∗ the constructor
∗/
public
{
}
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
∗
∗
this
∗
unique r e c e i v e d matrix and s e t
c o m p u t a t i o n a l code increment 1 by 1 p o s i t i o n 0 , 0 o f t h e
the
status
t o done
∗/
public
void c1901 ( )
{
i f empty
int
c o u n t e r ++;
+ " ␣ h a s ␣ been ␣ drawn " ) ;
done=t r u e ;
APPENDICE
181
}
// end c1901
∗
this
∗
∗
∗/
public
void c1902 ( )
{
for
{
int
article
int
prediction
//Min v a l u e
if
( f o r e c a s t < 10)
forecast = 10;
//Max v a l u e
if
( f o r e c a s t > 25000)
f o r e c a s t = 25000;
System . o u t . p r i n t l n ( " L i c e n s e e ␣#" + myUnit . getUnitNumber ( ) + " ␣ f o r e c a s t e d ␣ "
+ f o r e c a s t + " ␣ f o r ␣ MetaSample␣#" + j + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r ) ;
// End o f
predictions
done=t r u e ;
}
}
// end c1902
∗
this
∗
∗
∗/
public
void c1903 ( )
{
f l o a t sum = 0 ;
int
threshold = 18000;
APPENDICE
182
int
articles
for ( int
j = 1 ; j <= c o u n t e r
;
j ++)
{
for ( int
t = 1 ; t < = 3 5 ; t++)
{
// Checking
if
the
for
t h i s MetaSample
{
}
}
// S t o r i n g
total
// Checking
if
{
" ␣ can ␣ be ␣ produced , ␣ f o r e c a s t=" + sum + " ␣ s t a t u s =1" ) ;
}
else
{
+
" ␣ can ␣NOT␣ be ␣ produced , ␣ f o r e c a s t=" + sum + " ␣ s t a t u s =0" ) ;
}
// Waiting
for ( int
all
predictions
t = 1 ; t < = 3 5 ; t++)
{
}
if
( endForecast )
{
done=t r u e ;
}
sum = 0 ;
}
}
// end c1903
APPENDICE
183
∗
∗
this
∗
∗
1 cell
∗
above
∗/
public
void c1904 ( )
{
float
val ;
int
article
status
{
{
System . o u t . p r i n t l n ( " U n i t␣#" + myUnit . getUnitNumber ( ) + " ␣ p r o d u c e d ␣ MetaSample␣#" + i
+ " ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " , ␣ s t a t u s =2" ) ;
done=t r u e ;
}
else
{
}
}
}
// end c1904
∗
this
∗
with licensee ’ s
first
order .
∗
∗/
public
void c1907 ( )
{
APPENDICE
184
{
int
if
{
//Check i f
if
the
licensee
received the
{
int
//Min v a l u e
if
( o r d e r 1 <10)
order1 = 10;
//Max v a l u e
if
( o r d e r 1 >25000)
order1 = 25000;
if
int
System . o u t . p r i n t l n ( "The ␣1 s t ␣ o r d e r ␣ o f ␣ L i c e n s e e ␣#" + myUnit . getUnitNumber ( )
+ " ␣ i s ␣ " + o r d e r 1 + " ␣ f o r ␣ i t e m␣#" + j + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r
+ " ␣ t o t O r d e r␣#"+ t o t O r d e r 1 ) ;
done=t r u e ;
}
}
}
}
// end c1907
∗
this
∗
∗
∗/
public
void c1909 ( )
{
int
threshold = 100;
APPENDICE
int
if
185
{
if
{
// Checks
if
if
the
first
order
{
int
if
{
int
//Min v a l u e
if
( o r d e r 2 <10)
order2 = 10;
//Max v a l u e
if
( o r d e r 2 >25000)
order2 = 25000;
if
int
+ totOrder2 ) ;
else
{
if
} //end
int
int
int
first
order )
}
}
done = t r u e ;
APPENDICE
186
} // end c1909
∗
∗
∗
∗/
public
void c1910 ( )
{
try
{
report .
w r i t e ( " L a y e r ␣ | ␣ MetaSampleN ␣ | ␣ S t a t u s 0 ␣ | ␣ S t a t u s 1 ␣ | ␣ S t a t u s 2 ␣ | ␣ S t a t u s 3 ␣ | ␣ S t a t u s ␣ 4 ␣ ␣ ␣ \ n" ) ;
}
{
}
for ( int
l n = 1 ; l n <=16; l n ++)
{
int [ ]
status ;
s t a t u s = new i n t [ 5 ] ;
for ( int
s = 0 ; s <=4; s++)
status [ s ]=0;
for ( int
i t e m = 1 ; item <=150; i t e m++)
{
item )]++;
}
String
try
{
}
{
APPENDICE
187
}
}
try
{
}
{
}
done = t r u e ;
} //end c1910
∗
∗
items to the
licensees .
∗
∗/
public
void c1913 ( )
{
int
if
{
{
//Check i f
{
+ " ␣ h a s ␣ been ␣ d e l i v e r e d " ) ;
}
}
}
done = t r u e ;
} //end c1913
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
APPENDICE
//The c o u n t e r
188
private
int
article
with only a recipe
i n t row )
{
i f empty
int
c o u n t e r ++;
return
counter ;
}
private
int
numberOfMatrixes )
{
{
+ " ␣ f o u n d ␣ i n ␣ o r d e r ␣#␣" +
p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t . getOrderNumber ( ) ) ;
}
}
private
eraseFile ,
String
fileName )
{
File
{
try
{
FileWriter
erase
false );
erase . close ( ) ;
}
{
}
}
try
{
true ) ;
;
}
{
}
}
}
§

¦
APPENDICE
189
Caso 3
¨
//
/∗ ∗
∗ c o m p u t a t i o n a l p r o c e s s e s ; we have a computationa a s s e m b l e r i n s t a n c e f o r
∗ each u n i t
∗
∗
∗ @author
∗/
public
class
{
basicNetMatrix , tcMatrix , orMatrix ,
agentMatrix ;
public
F i l e management
boolean
FileWriter
i n t samplesN =0;
float
sampleSales = 0;
float
itemSales = 0;
/∗ ∗
∗ the constructor
∗/
public
{
}
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
∗
∗
this
∗
unique r e c e i v e d matrix and s e t
c o m p u t a t i o n a l code increment 1 by 1 p o s i t i o n 0 , 0 o f t h e
the
status
t o done
APPENDICE
190
∗/
public
void c1901 ( )
{
i f empty
int
c o u n t e r ++;
+ " ␣ h a s ␣ been ␣ drawn " ) ;
done=t r u e ;
}
// end c1901
∗
this
∗
∗
∗/
public
void c1902 ( )
{
for
{
int
int
prediction
//Min v a l u e
if
( f o r e c a s t < 10)
forecast = 10;
//Max v a l u e
if
article
( f o r e c a s t > 25000)
f o r e c a s t = 25000;
APPENDICE
191
System . o u t . p r i n t l n ( " L i c e n s e e ␣#" + myUnit . getUnitNumber ( ) + " ␣ f o r e c a s t e d ␣ " + f o r e c a s t
+ " ␣ f o r ␣ MetaSample␣#" + j + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r ) ;
// End o f
predictions
done=t r u e ;
}
}
// end c1902
∗
this
∗
∗
∗/
public
void c1903 ( )
{
f l o a t sum = 0 ;
int
threshold = 18000;
int
articles
for ( int
j = 1 ; j <= c o u n t e r
;
j ++)
{
for ( int
t = 1 ; t < = 3 5 ; t++)
{
// Checking
if
the
for
t h i s MetaSample
{
}
}
// S t o r i n g
total
// Checking
if
{
+ " ␣ can ␣ be ␣ produced , ␣ f o r e c a s t=" + sum + " ␣ s t a t u s =1" ) ;
}
else
{
APPENDICE
192
+ " ␣ can ␣NOT␣ be ␣ produced , ␣ f o r e c a s t=" + sum + " ␣ s t a t u s =0" ) ;
}
// Waiting
for ( int
all
predictions
t = 1 ; t < = 3 5 ; t++)
{
}
if
( endForecast )
{
done=t r u e ;
}
sum = 0 ;
}
}
// end c1903
∗
∗
this
∗
∗
1 cell
∗
above
∗/
public
void c1904 ( )
{
float
val ;
int
article
status
{
{
System . o u t . p r i n t l n ( " U n i t␣#" + myUnit . getUnitNumber ( ) + " ␣ p r o d u c e d ␣ MetaSample␣#"
done=t r u e ;
}
APPENDICE
193
else
{
}
}
}
// end c1904
∗
∗ This c o m p u t a t i o n a l code d i a l s
w i t h TC o f f e r −p r i c e
∗/
public
void c1905 ( )
{
float
o f f e r P r i c e , random ;
basicNetMatrix
= ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
t c M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
//Making an o f f e r −p r i c e
for
available
articles
{
int
for ( int
i = 1 ; i <=c o u n t e r ;
i ++)
{
{
{
//The o f f e r −p r i c e
o f f e r P r i c e = ( i n t ) normal . g e t S a m p l e W i t h M e a n $ w i t h V a r i a n c e ( 7 , 1 0 ) ;
//Min v a l u e
if
( o f f e r P r i c e <1)
offerPrice = 1;
//Max v a l u e
if
( o f f e r P r i c e >20)
o f f e r P r i c e =20;
// S t o r i n g t h e o f f e r −p r i c e o f t h e TC
tcMatrix . setValue ( layer , 1 , i ,
offerPrice );
+ " ␣ o f f e r ␣ p r i c e ␣ f o r ␣ MetaSample␣#" + i + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " ␣ i s ␣ $ "
+ offerPrice );
}
else
+ " ␣ can ␣ n o t ␣make␣ an ␣ o f f e r ␣ f o r ␣ Metasample␣#" + i
}
}
+ " ␣ w i t h ␣ l a y e r ␣#" + l a y e r
);
APPENDICE
194
done=t r u e ;
}
}
// end c1905
∗ This c o m p u t a t i o n a l code d i a l
w i t h t h e b i d d i n g phase
∗/
public
void c1906 ( )
{
MemoryMatrix c h o i c e M a t r i x ;
// Checking MetaSamples
{
int
for ( int
i = 1 ; i <=c o u n t e r ;
i ++)
{
int
choice = 0;
float
o f f e r =0;
// Checking t h e
status
{
{
//Here we make t h e b i d d i n g
for ( int
t = 1 ; t < = 5 ; t++)
{
MemoryMatrix t c M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
i f ( ! t c M a t r i x . getEmpty ( l a y e r , 1 , i ) )
{
i f ( tcMatrix . getValue ( layer , 1 , i ) < o f f e r
||
o f f e r ==0)
{
o f f e r = tcMatrix . getValue ( layer , 1 , i ) ;
choice = t ;
}
}
}
// Checking t h e TC chosen
{
i f ( b a s i c N e t M a t r i x . g e t V a l u e ( l a y e r , 2 , i ) > 0 & & ( ! ( c h o i c e ==0)))
{
// G e t t i n g
its
offer
price
...
APPENDICE
195
c h o i c e M a t r i x = ( MemoryMatrix ) p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t .
getMemoryMatrixAddress ( c h o i c e ) ;
float
o f f e r P r i c e = choiceMatrix . getValue ( layer , 1 , i ) ;
// . . .
storing
it
i n b a s i c N e t Matrix
...
basicNetMatrix . setValue ( layer , 3 , i , o f f e r P r i c e ) ;
// . . . and i n t h e orMatrix
orMatrix . setValue ( layer , 1 , i , choice ) ;
System . o u t . p r i n t l n ( " T r a d i n g ␣Company␣#" + o r M a t r i x . g e t V a l u e ( l a y e r , 1 , i )
+ " ␣ h a s ␣ been ␣ c h o s e n ␣ f o r ␣ MetaSample␣#" + i + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " ␣ p r i c e ␣ "
+ basicNetMatrix . getValue ( layer , 3 , i ) ) ;
}
}
}
}
}
done=t r u e ;
}
}
// end c1906
∗
this
∗
with licensee ’ s
first
order .
∗
∗/
public
void c1907 ( )
{
{
int
if
{
//Check i f
if
the
licensee
received the
{
int
//Min v a l u e
if
( o r d e r 1 <10)
order1 = 10;
//Max v a l u e
if
( o r d e r 1 >25000)
order1 = 25000;
APPENDICE
if
196
int
System . o u t . p r i n t l n ( "The ␣1 s t ␣ o r d e r ␣ o f ␣ L i c e n s e e ␣#" + myUnit . getUnitNumber ( ) + " ␣ i s ␣ "
+ o r d e r 1 + " ␣ f o r ␣ i t e m␣#" + j + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r + " ␣ t o t O r d e r␣#"+t o t O r d e r 1 ) ;
done=t r u e ;
}
}
}
}
// end c1907
∗
this
∗
w i t h or branch c h o i c e .
∗
∗/
public
void c1908 ( )
{
{
// S w i t c h i n g t o another
int
article
i = getCounter ( orMatrix , 0 ) ;
i f ( i <= d e s i g n M a t r i x . g e t V a l u e ( l a y e r , 0 , 0 ) )
{
{
//Check i f
t h e item can be produced ( s t a t u s >1)
i f ( b a s i c N e t M a t r i x . g e t V a l u e ( l a y e r , 2 , i ) > 1 & & ! o r M a t r i x . getEmpty ( l a y e r , 1 , i ) )
{
float
branch = orMatrix . getValue ( l a y e r , 1 , i ) ;
orMatrix . s e t V a l u e ( l a y e r , 1 , 0 , branch ) ;
System . o u t . p r i n t l n ( " Branch␣␣#" + o r M a t r i x . g e t V a l u e ( l a y e r , 1 , 0 )
+ " ␣ p r o d u c e d ␣ i t e m␣#" + i + " ␣ w i t h ␣ l a y e r ␣#" + l a y e r ) ;
basicNetMatrix . setValue ( layer , 2 , i , 3 . 0 ) ;
done = t r u e ;
}
}
// The a r t i c l e can not be produced −> done=f a l s e
APPENDICE
197
}
}
}
//end c1908
∗
this
∗
∗
∗/
public
void c1909 ( )
{
int
threshold = 100;
int
if
{
if
{
// Checks
if
if
the
first
order
{
int
if
{
int
//Min v a l u e
if
( o r d e r 2 <10)
order2 = 10;
//Max v a l u e
if
( o r d e r 2 >25000)
order2 = 25000;
if
int
APPENDICE
198
+ totOrder2 ) ;
else
{
if
} //end e l s e
int
int
int
first
order )
}
}
done = t r u e ;
} // end c1909
∗
∗
∗
∗/
public
void c1910 ( )
{
try
{
report .
w r i t e ( " L a y e r ␣ | ␣ MetaSampleN ␣ | ␣ S t a t u s 0 ␣ | ␣ S t a t u s 1 ␣ | ␣ S t a t u s 2 ␣ | ␣ S t a t u s 3 ␣ | ␣ S t a t u s ␣ 4 ␣ ␣ \ n" ) ;
}
{
}
for ( int
{
l n = 1 ; l n <=16; l n ++)
APPENDICE
199
int [ ]
status ;
s t a t u s = new i n t [ 5 ] ;
for ( int
s = 0 ; s <=4; s++)
status [ s ]=0;
for ( int
i t e m = 1 ; item <=150; i t e m++)
{
item )]++;
}
String
try
{
}
{
}
}
try
{
}
{
}
done = t r u e ;
} //end c1910
∗
∗
items to the
licensees .
∗
∗/
public
void c1913 ( )
{
APPENDICE
200
int
if
{
{
//Check i f
{
+ " ␣ h a s ␣ been ␣ d e l i v e r e d " ) ;
}
}
}
done = t r u e ;
} //end c1913
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
//The c o u n t e r
private
int
article
with only a recipe
i n t row )
{
i f empty
int
c o u n t e r ++;
return
counter ;
}
private
int
numberOfMatrixes )
{
{
+ " ␣ f o u n d ␣ i n ␣ o r d e r ␣#␣" + p e n d i n g C o m p u t a t i o n a l S p e c i f i c a t i o n S e t . getOrderNumber ( ) ) ;
}
}
APPENDICE
private
201
eraseFile ,
String
fileName )
{
File
{
try
{
FileWriter
erase
false );
erase . close ( ) ;
}
{
}
}
try
{
true ) ;
;
}
{
}
}
}
§

¦
Bibliografia
[1] Avvisati F.,
(2003),
Herbert A. Simon. Una microeconomia
empiricamente fondata, Università di Pisa.
[2] Axtell R., (2000), Why agents?
On the varied motivations for
agent computing in the social sciences, Center on Social and Economic
Dynamics, Working Paper no. 17.
[3] Axtell R. L., Epstein J. M., (1994), Agent-Based Modeling: understanding our creations, The Bulletin of the Santa Fe Institute, Winter
1994, pp. 28-32.
[4] Balla A., (2004), Le decisioni delle organizzazioni e la complessità.
Applicazione al caso BasicNet, Tesi di laurea in Economia e Commercio,
Università di Torino.
[5] BasicNet, http://www.basicnet.com.
[6] BasicNet, divisione Menestrello (2004), BasicNet, (documento
ad accesso riservato).
[7] BasicNet, divisione Menestrello (2002), BasicSamples.com,
(documento ad accesso riservato).
[8] BasicPress, http://www.basicpress.com.
202
BIBLIOGRAFIA
[9] Collier N., (2003), RePast: An Extensible Framework for Agent
Simulation, Social Science Research Computing, Università di Chicago.
[10] Colombatto E., (2001), Dall’impresa dei neoclassici all’imprenditore
di Kirzner, Economia Politica, XVIII, no. 2.
[11] Conte R., (1998), Il metodo simulativo, in La Ricerca Qualitativa (a
cura di Luca Ricolfi), Roma, Carocci Editore.
[12] Edmonds B., (2003), Simulation and Complexity. How they can relate,
presentato al workshop su ‘‘Virtual Worlds of Precision − Computerbased Simulations in the Natural and Social Sciences’’, Oxford, Gennaio
2003.
[13] Egidi M., (2003), Razionalità limitata, Sistemi intelligenti, XV, no. 1,
pp. 67-72.
[14] Ferraris G., (1999), Algoritmi genetici per l’economia, Tesi di laurea
in Economia e Commercio, Università di Torino.
[15] Fraquelli G., (2001), Elementi di Economia Manageriale, Torino,
UTET.
[16] Gilbert N., Terna P. (2000), How to build and use agent-based
models in social science, Mind & Society, no. 1, pp. 57-72.
[17] Huerta De Soto J., (2003), La Scuola Austriaca. Mercato e creatività imprenditoriale (a cura di Paolo Zanotto), Soveria Mannelli (CZ),
Rubbettino.
[18] Johnson P., Lancaster A., (2000), Swarm User Guide.
[19] Kilpatrick H. E. Jr., (2001), Complexity, spontaneous order, and
Friedrich Hayek: are spontaneous order and complexity essentially the
same thing?, Complexity, vol. 6, no. 4, John Willey & Sons.
203
BIBLIOGRAFIA
204
[20] Kirzner I. M., (1997), Entrepreneurial Discovery and the Competitive
Market Process: an Austrian Approach, Journal of Economic Literature,
vol. 35, no. 1, pp. 60-85.
[21] Lamieri M. (2002), Simulazione Agent Based in contesti d’impresa. Applicazione del modello Virtual Enterprise in JavaSwarm ad un’azienda
reale, Tesi di laurea in Economia e Commercio, Università di Torino.
[22] Langton C. G., (1992), Vita Artificiale (traduzione di Maurizio
Riccucci), Sistemi intelligenti, IV, no. 2, pp. 189-246.
[23] Merlo F. (2003a), L’impresa rifatta nel computer: Applicazione del
modello jES al caso BasicNet, Tesi di laurea in Economia e Commercio,
Università di Torino.
[24] Merlo F. (2003b), BasicJes:
esperimenti finali e considerazioni,
http://web.econ.unito.it/terna/jes_files/jesframe-0.9.9.20.tar.gz.
[25] Minar N., Burkhart R., Langton C., Askenazi M., (1996),
The SWARM Simulation System: a toolkit for building multi-agent
simulations, Santa Fe Institute, Working Paper.
[26] NetLogo, Home Page: http://ccl.northwestern.edu/netlogo.
[27] Ormerod P., (2003), L’economia della farfalla: società, mercato e
comportamento, Torino, Instar Libri.
[28] Parisi D., (1999), Se laboratorio è nel computer le scienze hanno
un’arma in più, Telèma, 5, pp. 28-30.
[29] RePast, Home Page: http://repast.sourceforge.net/index.php.
[30] Rosser J. B. Jr., (1999), On the complexities of complex economic
dynamics, Journal of Economic Perspective, vol. 13, no. 4, pp. 169-192.
BIBLIOGRAFIA
205
[31] Sanders I. T., McCabe J. A., (2003), The use of Complexity Science,
Washington Center for Complexity & Public Policy.
[32] Sciabarrà M., (2003) Il libro di CorsoJava.it, Versione 2.7.
[33] Simon H. A., (1985), Causalità, razionalità, organizzazione, Bologna,
Il Mulino.
[34] Simon H. A., (1958), Il comportamento amministrativo, Bologna, Il
Mulino.
[35] Swarm, Home Page: http://www.swarm.org e http://wiki.swarm.org.
[36] Terna P., (2004b), How to Use the Java Enterprise Simulator (jES) Program, http://web.econ.unito.it/terna/jes_files/jesframe0.9.9.20.tar.gz.
[37] Terna P., (2003a), La simulazione come strumento di indagine per
l’economia, Sistemi Intelligenti, XV, no. 2, pp. 347-376.
[38] Terna
tists:
of
(1998),
P.,
Building
Artificial
Agent
Societies
Simulation
Based
and
Tools
Models
Social
for
with
Simulation
Social
SWARM,
vol.
1,
ScienJournal
no.
2,
http://www.soc.surrey.ac.uk/JASSS/1/2/4.html
[39] Terna P., (2002), Simulazione ad agenti in contesti di impresa, Sistemi
intelligenti, XIV, no. 1, pp. 33-51.
[40] Terna P., (2004a), Simulazione di scelte complesse nelle organizzazioni, Ivrea, II Convegno Nazionale (2004) dell’AISC.
[41] Terna P., (2003b), The quest for the enterprise: jES, a Java Enterprise
Simulator, http://web.econ.unito.it/terna/jes.
BIBLIOGRAFIA
[42] Tinti T., (1998), La ‘‘sfida della complessità’’ verso il Terzo Millennio,
Novecento, anno 18, no. 12, pp. 7-12.
[43] Tisue S., Wilensky U., (2004), NetLogo: Design and Implementation
of a Multi-Agent Modeling Environment, Center for Connected Learning
and Computer-Based Modeling, Northwestern University (presented at
the International Conference on Complex Systems, Boston, May 16-21).
[44] Wilensky U., (1999), NetLogo 2.0.0 User Manual, Center for Connected Learning and Computer-Based Modeling, Northwestern University,
Evanston, IL.
[45] Wooldridge M., Jennings N. R., (1995), Intelligent Agents: Theory
and Practice, Knowledge Engineering Review, vol. 10, no. 2, pp. 115-152.
206