simulazione ad agenti e sistemi complessi. applicazione al ... · attività e una con˝gurazione...

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 32

2.1 Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.1.1 Sviluppo di una simulazione . . . . . . . . . . . . . . . 34

I

INDICE II

2.1.2 Caratteristiche principali . . . . . . . . . . . . . . . . . 36

2.1.3 Le ‘‘sonde’’ . . . . . . . . . . . . . . . . . . . . . . . . 38

2.1.4 Le librerie di Swarm . . . . . . . . . . . . . . . . . . . 39

2.2 NetLogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.1 Caratteristiche principali . . . . . . . . . . . . . . . . . 41

2.2.2 Obiettivi futuri . . . . . . . . . . . . . . . . . . . . . . 42

2.3 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 III

4.4.3 I batch . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.4.4 I procurement . . . . . . . . . . . . . . . . . . . . . . . 68

4.4.5 Il processo OR . . . . . . . . . . . . . . . . . . . . . . 69

4.5 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.7.1 Un semplice esempio . . . . . . . . . . . . . . . . . . . 76

4.7.2 La matrice orMemoryMatrix . . . . . . . . . . . . . . . 77

4.7.3 Le ricette che lanciano ricette . . . . . . . . . . . . . . 77

4.8 Le capacità contabili . . . . . . . . . . . . . . . . . . . . . . . 79

4.8.1 I costi . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.8.2 I ricavi . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.8.3 L’utile . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.9 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 . . . . . . . . . . . . . . . . . . . . . . . 94

5.5 Il ciclo di produzione . . . . . . . . . . . . . . . . . . . . . . . 96

5.6 Le attività di promozione . . . . . . . . . . . . . . . . . . . . . 97

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.11 Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

6.11.1 Le modifiche al modello . . . . . . . . . . . . . . . . . 140



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 . . . . . . . . . . . . . . . . . . . . . . . . . 68

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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 75

4.5 Grafico dell’andamento delle liste d’attesa . . . . . . . . . . . 83

4.6 Andamento dell’utile durante la simulazione . . . . . . . . . . 83

4.7 Rapporto totaltimetotallenght

. . . . . . . . . . . . . . . . . . . . . . . . 84

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

VII

ELENCO DELLE FIGURE VIII

6.4 Ricetta 900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.5 Ricetta 302 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.6 Primo esperimento. Tempodiesecuzione

Tempoprevistodallericette. . . . . . . . . . . . 145

6.7 Primo esperimento. Tempi d’attesa degli ordini . . . . . . . . 145

6.8 Secondo esperimento. Tempodiesecuzione

Tempoprevistodallericette. . . . . . . . . . . 148

6.9 Secondo esperimento. Tempi d’attesa degli ordini . . . . . . . 149

6.10 Terzo esperimento. Tempodiesecuzione

Tempoprevistodallericette. . . . . . . . . . . . . 150

6.11 Quarto esperimento. Tempodiesecuzione

Tempoprevistodallericette. . . . . . . . . . . . 151

6.12 Sesto esperimento. Tempodiesecuzione

Tempoprevistodallericette. . . . . . . . . . . . . 152

6.13 Licenziatari con tempo 0. Tempodiesecuzione

Tempoprevistodallericette. . . . . . . . . . 153

6.14 Approfondimento di Basicsamples. Tempodiesecuzione

Tempoprevistodallericette. . . . 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’im-

presa 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 im-

presa 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 parte-

cipa direttamente al processo produttivo, in quanto la produzione è delegata

ad imprese esterne, chiamate Sourcing Centers o Trading Company, e gli ar-

ticoli sono venduti direttamente da queste ultime ai licenziatari, che hanno

il compito di commercializzare i prodotti presso il pubblico. Il ruolo princi-

pale 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 2

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 Ba-

sicNet potrebbe adottare, cioè un’azienda di tipo tradizionale che produce

e vende direttamente i propri articoli. La differenza con il caso preceden-

te è 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 orga-

nizzativo è 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-

INTRODUZIONE 3

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 comples-

sità 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 stru-

menti 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’im-

prenditore è un semplice amministratore delle risorse interne e non ha alcuna

funzione creativa, compito che al contrario è evidenziato dagli esponenti del-

la 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’impren-

ditore introducendo i principi della razionalità limitata e della decisione più

soddisfacente anziché della migliore.

Nel quarto capitolo si descrive il modello jES (java Enterprise Simula-

tor), basato su Swarm, con il quale è possibile effettuare delle simulazioni

INTRODUZIONE 4

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 mo-

difiche hanno avuto l’obiettivo di rendere il più possibile simile all’azienda

reale quella creata all’interno del computer. Inoltre sono illustrate la co-

struzione degli altri modelli di azienda descritti precedentemente e un’analisi

finale dei costi e dei ricavi in cui si confrontano i diversi modelli organizzativi.

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 discipli-

ne, 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 que-

sto 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 6

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 precedente-

mente 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 Qua-

ranta 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 com-

plessità è 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


computazionali del sistema che si intende studiare ed osservare il suo com-

portamento; 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 riguarda-

to 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 crea-

to 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, ea-

ch occupied by a black or a white. He allowed for movement based

on local interactions and discovered that even a very slight prefe-

rence 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


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 rappresen-

tazione 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 com-

plesse 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 adatta-

mento 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


ad esempio il computer; questi sistemi possono essere adattivi e manifestare

comportamenti imprevedibili. Infine, i sistemi complessi sono sistemi adat-

tivi 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 siste-

mi 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 siste-

mi 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 siste-

ma 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 funzionamen-

to generale del motore. Il formicaio è un sistema complesso, o non lineare,


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 agen-

ti interattivi che imparano e si adattano continuamente all’ambiente circo-

stante. Questa visione è fortemente in contrasto con quella degli schemi di

pensiero tradizionali delle scienze sociali e dell’aconomia, che offrono una vi-

sione 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 verifica-

no 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 tradi-

zionale. Infatti l’osservazione del comportamento di un gruppo di formiche

si rivela di grande utilità nel momento in cui si voglia formalizzare il com-

portamento di individui che si trovano di fronte a più possibilità tra cui

scegliere.


1.3.1 Le formiche

Gli studi biologici sulle formiche hanno dato origine a risultati che sono dif-

ficili 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 di-

stribuzione 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’eco-

nomia dei modelli basati sugli agenti interattivi (Ormerod, 2003), osservando

gli studi effettuati dai biologi sulle formiche sviluppò l’idea che per compren-

dere il funzionamento di un intero sistema non è sufficiente osservare soltanto

il comportamento di un suo agente rappresentativo, che sia una formica op-

pure 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


è 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 è adot-

tabile 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


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 rela-

zione 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 tro-

vano due categorie di operatori finanziari, da un lato i fundamentalist, coloro

che ritengono che i prezzi delle attività finanziarie siano determinati dai fon-

damentali (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’atti-

vità 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 in-

fluenzato 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


si possono verificare grandi variazioni di prezzo in modo repentino ed inspie-

gabile. La volatilità dei prezzi è dunque la conseguenza della volatilità delle

scelte degli operatori.

Questo modello permette di comprendere ex post anche un comportamen-

to 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 rap-

presenta 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 comples-

sità, 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.


Un altro elemento che avvicina Hayek alla teoria della complessità è il

suo interesse per la teoria biologica evoluzionistica e per la scienza cogniti-

va, 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à mo-

strano anche alcune caratteristiche che li distinguono tra loro.

Nelle opere di Hayek sembra che sia presente l’idea di un’entità sopran-

naturale benevolente che si cela dietro l’ordine spontaneo; secondo Hayek le

persone dovrebbero impegnarsi a lasciar guidare la società all’ordine spon-

taneo 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 anti-

cipa la teoria della complessità e chi si accinge allo studio di questa disciplina

dovrebbe analizzare attentamente i lavori hayekiani. Occorre tuttavia sotto-

lineare che le teorie espresse dalle due parti sono qualitativamente differenti

(Kilpatrick, 2001).


1.5 La vita artificiale

La vita artificiale mira a sintetizzare comportamenti di tipo biologico in am-

bienti artificiali, ad esempio in un computer, e ad osservare i fenomeni com-

plessi 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 orga-

nismi 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’evoluzio-

ne, 2) usando i calcolatori, e 3) studiare qualunque cosa emerga

da questo processo, anche quando i risultati non hanno corrispet-

tivi 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


prospettiva adottata. L’intelligenza artificiale ha sempre avuto come obiet-

tivo la generazione di comportamenti intelligenti che non necessariamente

devono avere una corrispondenza con quanto avviene in natura. Al con-

trario, 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’organi-

smo 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-


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 origi-

nati comportamenti di grande complessità. In questo contesto inizialmente

si definisce il genotipo, cioè il repertorio di comportamenti, e in seguito dal-

le 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 feno-

tipo 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


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 è rappre-

sentato 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 indi-

viduo 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 pos-

sono 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.


L’opportunità di verificare le teorie non è invece disponibile per le scienze

sociali, in quanto non dispongono di un vero e proprio laboratorio. La simula-

zione 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 Ter-

na, 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 si-

mulazione, 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,


ai due strumenti di ricerca tradizionali: le teorie e gli esperimenti

di laboratorio.

Axtell (2000) osserva che la tecnica della simulazione ad agenti può esse-

re 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 compren-

sibile 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 risul-

tati 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 par-

ticolare, 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 necessa-

riamente 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 spie-

gare dei particolari fenomeni e si desideri verificare la qualità dei mo-

delli proposti. Il modello creato nel computer può essere usato in due


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 partico-

lari 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 virtua-

le”, 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


del successo che essi hanno avuto; il secondo metodo consiste nel tenta-

tivo di imitare il più possibile il processo reale ed è il più impegnativo

e difficoltoso;

• la precisione dei principi utilizzati per costruire il modello, che è mi-

surata 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 appli-

cato 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 os-

servare 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’atten-

dibilità del modello perché le previsioni sviluppate sono troppo generiche e

perciò impossibili da valutare.


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 si-

tuazioni 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 quan-

to 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 sem-

plici; 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.


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 rap-

presenta per i ricercatori un metodo più completo rispetto al laboratorio,

all’interno del quale si possono analizzare soltanto i sistemi semplici, per-

ché 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 otte-

nere particolari risposte, ad esempio conoscere quali saranno le conseguenze

originate da un particolare insieme di fattori; grazie a questo metodo gli stu-

diosi 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 multi-

disciplinare. 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;


• 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 circostan-

te;

• 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’interpreta-

zione 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 speci-

ficazione del modello o semplicemente ad uno di programmazione; dall’altro

lato, se le ipotesi sono confermate, risulta difficoltoso affermare l’adeguatez-

za 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 particolar-

mente 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


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 rap-

presenta 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 im-

portante 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 agen-

ti, determinato dalle variabili di stato di ognuno di essi, sia il comportamen-

to che emerge dalle loro interazioni a livello aggregato. In Terna (1998)

si afferma che, da un punto di vista metodologico, possono esistere due ti-

pi di emergenza: l’emergenza imprevista, ma in qualche modo prevedibile,

cioè quando all’interno del modello compare un comportamento ricorrente


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 è osser-

vabile 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 uti-

lizzano 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 quanti-

tativamente 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.


I risultati della simulazione riguardanti il comportamento collettivo po-

trebbero risultare difficili da comprendere tanto quanto la stessa realtà; que-

sto problema è simile a quello incontrato nella vita artificiale riguardante la

comprensione dei legami tra il genotipo e il suo fenotipo1. In questo ambi-

to 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 an-

che 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 di-

sattenzione 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 com-

putazionale posto in un certo ambiente dotato delle seguenti caratteristiche:

• autonomia, che gli consente di operare senza la necessità di un inter-

vento umano;

• abilità sociale, cioè capacità di interagire e comunicare con altri agenti;

• reattività, che gli permette di reagire in modo tempestivo ai cambia-

menti dell’ambiente circostante;

• capacità di prendere iniziative guidate da obiettivi interni, o pro-attività.

1vedi paragrafo 1.5.1


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 adatta-

mento e di apprendere; se gli agenti sono privi di capacità di apprendimento

sono detti ‘‘senza mente”, in caso contrario ‘‘con mente”. Inoltre si può ef-

fettuare 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 ge-

nerati indirettamente dagli agenti; in questi tipi di esperimenti si possono


notare due tipi di emergenza, quella imprevista e quella imprevedibile, illu-

strate 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 strut-

turato, 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 com-

plesse è 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 in-

contro all’emergenza di fenomeni complessi come nel secondo caso; inoltre in

questa situazione gli agenti si adattano ed imparano e sono in grado di deter-

minare risultati importanti anche a livello individuale, sviluppando strategie

che ad un osservatore esterno possono sembrare non ovvie.

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 ro-

bustezza 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 con-

sentono di comprendere come è strutturato l’ambiente di simulazione.

2.1 Swarm

Il progetto Swarm1 nasce nel 1994 dall’idea di Chris Langton ed è successi-

vamente sviluppato all’interno dell’Istituto degli Studi sulla Complessità di

Santa Fe.

Swarm è una piattaforma informatica con cui è possibile effettuare simula-

zioni di sistemi complessi adattivi; l’unità base della simulazione è lo sciame,

1Disponibile alla pagina web http://www.swarm.org e http://wiki.swarm.org

32

2. GLI STRUMENTI PER LA SIMULAZIONE 33

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 prin-

cipali motivi della nascita del progetto Swarm è l’esigenza di disporre di uno

strumento versatile per lo studio dei sistemi complessi che possa essere fa-

cilmente 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


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 interagi-

scono 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 rap-

presenta 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 ri-

sposta 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 comporta-

mento 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 simula-

zione 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:


infatti può essere composta da agenti che rappresentano, per esempio, le uni-

tà 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, forma-

to 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 por-

tare 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, descri-

vendo 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.


Dallo schema proposto risalta il fatto che la struttura di Swarm è com-

posta 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’os-

servatore, (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 Figu-

ra 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


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’eredita-

rietà, che permettono di creare software utilizzabili in più situazioni richia-

mando semplicemente la classe di una libreria che si vuole utilizzare.

Secondo il principio dell’incapsulamento i dettagli interni di un ogget-

to sono protetti e non possono essere messi a disposizione dell’utente, ad

eccezione di quei metodi che sono scritti con l’obiettivo di trasmettere infor-

mazioni 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


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 riguar-

dare il modello in generale oppure possono rappresentare le informazioni di

un semplice agente che opera all’interno del modello. Tutti i progetti co-

struiti 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


2.1.4 Le librerie di Swarm

Le librerie di Swarm hanno due funzioni principali: elencano una serie di clas-

si 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 simulazio-

ne, swarmobject, activity e simtools, dall’altro le librerie di supporto, utili per

la creazione di modelli che rispondano a particolari esigenze, defobj, collec-

tions, 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 con-

trollano 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 stan-

dard per la creazione degli oggetti, per l’archiviazione di dati e per il tratta-

mento 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-


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 al-

tre librerie che possono essere utilizzate per la costruzione di particolari mo-

delli. 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 dimensio-

ni, 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

2Disponibile alla pagina web http://ccl.northwestern.edu/netlogo


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 con-

nessioni 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 mon-

do in cui si trovano; si possono anche definire diversi tipi di tartaru-

ghe, 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,


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’intro-

duzione 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ù agen-

ti, 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 caratte-

ristica 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 con-

sente 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.


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.

3Disponibile alla pagina web http://repast.sourceforge.net/index.php


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 sta-

te 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 fun-

zionare 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,


cioè il modello. Lo stato della rappresentazione è lo stato degli agenti appar-

tenenti 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 ge-

rarchia, e da un modello che controlla che gli agenti eseguano i loro com-

portamenti 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’organiz-

zazione e del controllo di una simulazione;


• 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 simu-

lazione e della possibilità di creare delle animazioni del modello con

QuickTime;

• la libreria network contiene le classi incaricate di creare la rete del-

la 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 interna-

mente 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 ambien-

te 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.

Capitolo 3

Impresa, imprenditore e

conoscenza

In questo capitolo si presentano gli studi di diversi economisti che hanno avu-

to come oggetto l’impresa e le sue influenze sull’ambiente economico generale.

Nell’esposizione è riservata una particolare attenzione alla figura dell’impren-

ditore e al ruolo assunto dalla conoscenza, con l’obiettivo di comprendere l’im-

portanza che hanno nell’impresa e nel sistema economico secondo le diverse

teorie presentate.

La teoria neoclassica ha presentato la figura dell’imprenditore conside-

randolo 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 impor-

tante sia per l’impresa sia per il sistema economico in generale. L’impren-

ditore ha un ruolo di primo piano all’interno dell’impresa e il suo compito

è scoprire nuove opportunità di profitto nel mercato; questa funzione emer-

ge 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 48

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 decisio-

ni 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ò secon-

do 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’inter-

no 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 va-

riabili esterne all’impresa possono assumere e non il funzionamento interno

o l’attività dell’imprenditore.


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 im-

prenditori 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 pos-

sibilità 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 sceglie-

rà 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 ge-

nerato 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


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’azien-

da, 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 interval-

lo 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’e-

conomia 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,


dal momento che gli agenti operano in situazioni di incertezza e non cono-

scono tutti gli elementi dell’ambiente esterno che possono avere influenza su

di loro.

Il concetto di studio dell’economia secondo Mises, uno dei maggiori espo-

nenti 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 incer-

tezza, di allentare i vincoli tipici dell’attività economica − la scar-

sità delle risorse a disposizione dei produttori − e di accrescere la

soddisfazione dei consumatori, aumentando il loro potere d’acqui-

sto 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 uma-

na. Il significato etimologico della parola ‘‘imprenditore” illustrato nell’intro-

duzione a questo capitolo aiuta a comprendere che, secondo la Scuola Au-

striaca, 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, gra-

zie alle scoperte degli agenti che generano nuove informazioni e nuove cono-

scenze; secondo la teoria Austriaca la conoscenza ha determinate caratteri-

stiche (Huerta De Soto, 2003):

• è di tipo pratico;


• è esclusiva e dispersa nella mente di tutti gli uomini;

• è tacita e non articolabile;

• è trasmissibile.

La conoscenza imprenditoriale è definita pratica perché non è rappre-

sentabile in modo formale, ad esempio con un modello matematico; la sua

principale caratteristica è che rappresenta tutte le informazioni che un agen-

te 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 per-

sonale e varia da una persona all’altra. Perciò gli agenti che svolgono la

funzione di imprenditore lo fanno in modo assolutamente personale ed irri-

petibile, 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


mantenere l’equilibrio muovendo il manubrio verso il lato dal qua-

le sta per cadere, causando in tal modo una forza centrifuga che

tende a mantenerlo in equilibrio. Tutto ciò senza che nessun ci-

clista 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’in-

tuizione è 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 informa-

zioni sul mercato e, infine, fa sì che gli agenti imparino a comportarsi in

funzione delle necessità degli altri.


Creazione delle informazioni

Un’azione imprenditoriale consiste nella scoperta, da parte di un agente eco-

nomico, 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 Huer-

ta 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 sog-

getto 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 indipen-

dentemente. 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 coordi-

nato, modificando le loro attività in funzione dei bisogni degli altri; inoltre


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à imprendito-

riale 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 affer-

marsi 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 funzio-

ne 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’assi-

dua indagine degli errori compiuti dai rivali o delle occasioni da loro manca-


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 pro-

fitto, 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 compen-

so per le capacità organizzative, perché questi incarichi non competono al-

l’imprenditore, ma all’amministratore. Il profitto remunera la capacità del-

l’imprenditore di cogliere le opportunità di miglioramento prima ancora che

queste siano realizzate all’interno dell’azienda; anche se il guadagno si con-

cretizza 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’im-

prenditore delineata dagli Austriaci. Infatti questi ultimi sostengono che un

agente può decidere di dedicare del tempo all’attività imprenditoriale, al con-

trario Kirzner sottolinea che l’individuazione di occasioni profittevoli avviene

per caso, senza un’azione di ricerca alle spalle; se così non fosse, profitto sa-

rebbe 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.


Questa tesi tuttavia può creare alcune perplessità per due principali mo-

tivi (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 razio-

nalità 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-


rate con le scelte imprenditoriali ma con il vantaggio di essere in un contesto

maggiormente dominabile rispetto a quello dell’impresa. Il giocatore di scac-

chi 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, con-

siderando 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 nu-

mero come 1040 sarebbe meno spettacolare, ma sufficientemente

grande per avallare le nostre conclusioni.

Studi sui processi decisionali degli scacchisti indicano atten-

dibilmente che anche i giocatori forti guardano raramente ad un

centinaio di possibilità − cioè un centinaio di proseguimenti dal-

la posizione data − nella scelta di una mossa o di una strategia.

Cento è un numero ragionevolmente grande, rispetto ad altri pa-

rametri, ma è un po’ più piccolo di 10120! Gli scacchisti non pren-

dono 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 scac-

chi raggiungere la razionalità nelle decisioni, a causa del grande numero che

sarebbero necessarie. Simon conclude perciò che a maggior ragione la razio-

nalità non è raggiungibile neanche nel mondo reale, perché in questo contesto


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 comples-

sità 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 im-

portanza 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 deciso-

re è pertanto definito razionale se il suo comportamento è razionale in senso

procedurale. Il principio della razionalità procedurale è necessaria nel mo-

mento 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


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 stes-

so 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 ef-

fettuare 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 deci-

sioni 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à.

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 mo-

delli 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 risulta-

ti 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 62

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 diffe-

renti 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 av-

viene 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 gra-

do 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


Figura 4.1: Interazioni tra ordini e unità

tra ordini, ricette e unità. Per valutare come agisce l’impresa virtuale in di-

verse 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 si-

tuazioni 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 ti-

po 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 gra-

do di comunicare direttamente tra loro, ma soltanto attraverso l’ambiente;


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 algorit-

mo genetico; si potrebbe anche scegliere di far operare come Rule Master un

agente umano e ciò permetterebbe di studiare in che modo le persone prendo-

no 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


chiarezza del codice, che può essere visto come un vantaggio per l’utilizza-

tore 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 im-

presa 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 mecca-

nico, 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 jESopen-

foundation, 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-


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 Il primo formalismo: le cose da fare

4.4.1 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’in-

dicazione 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 tempo-

rale, 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 pos-

sibilità 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


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 (totalLayerNumber − 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.xls1, 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 or-

dini 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 m1

b1.

1Per maggiori chiarimenti su questo file vedere il paragrafo 4.6


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 endU-

nit si intende un magazzino nel quale vengono riposti i semilavorati quan-

do 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 approvvi-

gionamento nella quale vengono cercati semilavorati in k endUnit che han-

2Per maggiori dettagli: paragrafo 4.5.2


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 si-

mulata si trovi a dover effettuare delle scelte su come operare. Ad esempio,

potrebbe essere possibile che per l’approvvigionamento di uno stesso semila-

vorato l’impresa decida una volta di produrlo internamente e la volta succes-

siva 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 alter-

native, 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);


• 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 computazio-

nale3

4.5 Il secondo formalismo: chi fa cosa

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/unitBasicDa-

ta.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 magaz-

zino 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;

3Per maggiori dettagli: paragrafo 4.7.2


• 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


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 unitDa-

ta/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 pa-

rametro 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.


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.


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 recipe-

Data/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 compu-

tazione 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/me-

moryMatrixes.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 mo-

dificare 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 Computationa-

lAssembler 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;


• 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 computaziona-

le sarà ripetuto in ogni ciclo di simulazione, fino a quando la variabile done

sarà impostata true.


Listing 4.1: Esempio di passo computazionale¨

pub l i c void c1998 ( )

{

mm = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .

getMemoryMatrixAddress ( 0 ) ;

l a y e r = pend ingComputat iona lSpec i f i ca t ionSet .

getOrderLayer ( ) ;

mm. setValue ( layer , 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à computa-

zionali 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 co-

noscere 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 computa-

zionale 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 OrderDi-

stiller.java.

La sintassi dei passi computazionali sopra descritti è mostrata nella Ta-

bella 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.


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]× revenuePerEachStep

+ [costi]× revenuePerCostUnit

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.


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 gior-

nalieri. 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 dal-

la produzione degli ordini alla fine di uno specifico giorno.

5. in totalInventoryFinancialCosts.txt si trova il costo dei magazzini con-

tabilizzati secondo il criterio stabilito dal parametro inventoryEvalua-

tionCriterion, 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 ;


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 inventoryEvalua-

tion;

4. in dailySemimanufacturedProductRevenues.txt si ha il valore dei semi-

lavorati 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

+totalSemimanufacturedRevenues

−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.


4.9.1 I grafici di una simulazione

Durante una simulazione sono visibili i grafici che forniscono alcune infor-

mazioni 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 ciascu-

na ricetta; un eventuale ritardo rispetto ai tempi previsti potrebbe signi-

ficare 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 orizzon-

tale sono indicate le endUnit e sull’asse verticale la quantità di semilavorati

o prodotti finiti presenti in ciascuna di esse.


Figura 4.5: Grafico dell’andamento delle liste d’attesa

Figura 4.6: Andamento dell’utile durante la simulazione


Figura 4.7: Rapporto totaltimetotallenght

Figura 4.8: Liste d’attesa delle unità dell’impresa virtuale


Figura 4.9: Livello delle endUnit

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 licenzia-

tarie 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, pro-

prietario dei marchi di abbigliamento Kappa, Robe di Kappa e Jesus

Jeans.

86

5. L’AZIENDA REALE: BASICNET 87

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 que-

sta nuova società, oggi BasicItalia, è l’ottimizzazione dei processi produttivi

e la distribuzione dei prodotti in alcuni mercati esteri, nonché diventare li-

cenziatario 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 proprie-

tà 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 commer-

ciali di Football Sport Merchandise nel mercato dell’abbigliamento informale,

sportivo e per il tempo libero.

Nel 1996 il gruppo Ventuno Investimenti, guidato da Alessandro Benet-

ton, diventa nuovo partner strategico del Gruppo BasicNet. Si firmano nuovi

contratti di licenza per i principali mercati europei e si definiscono le strate-

gie 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


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 ospi-

tare, 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 giu-

gno 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 im-

prenditoriale 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 in-

dirizzata soprattutto ai negozi multimarca di articoli sportivi; per Superga è


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 rapida-

mente e, allo stesso tempo, mantenere una struttura flessibile ed efficiente.

Si presenta infatti come una grande azienda composta di tante piccole impre-

se 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 con-

sentire 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 con-

cepita e sviluppata completamente integrata al web, considerato dal Gruppo

lo strumento ideale di comunicazione fra gli elementi che costituiscono il

network.


Direttamente collegati con BasicNet vi sono i Sourcing Center, che hanno

il compito di individuare e coordinare le fabbriche a cui affidare la realizza-

zione 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 pe-

donali 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 carat-

teristica 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 licen-

ziatari; fase di acquisto del campionario da parte dei licenziatari;

2. realizzazione dei MetaSamples, scelta dei MetaSamples da realizza-

re come campionario, richiesta delle specifiche tecniche, produzione e

consegna delle merci;

3. richiesta di previsioni di vendita ai licenziatari;


Figura 5.1: Rappresentazione del business system di BasicNet


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, pre-

sidiando 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


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 Torine-

se, 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 mul-

tinazionale 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.


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 por-

tata 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 sot-

tolineare che i licenziatari non acquistano i loro articoli da BasicNet ma

direttamente dalle fabbriche asiatiche e pagano una commissione per l’inter-

mediazione (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%


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 com-

pongono la collezione. Una volta raccolti gli ordini la produzione viene lan-

ciata. 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 licenziata-

ri. 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’inter-

no dell’azienda, la fase più importante di tutto il processo produttivo. La

vendita del campionario è una delle principali fonti reddituali della divisione.


BasicSpecs.com

Determina le specifiche tecniche dei prodotti da consegnare alle Trading Com-

pany e ai Sourcing Centers. La divisione agisce in due momenti, la prima

volta prima della produzione del campionario e fornisce alla sartoria incari-

cata 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 de-

vono 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’in-

terno 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 commercia-

lizzazione del campionario. Le collezioni possono essere di due tipi: Gene-

ral Make-Up (gmu), collezioni proposte interamente da BasicNet, e Special

Make-Up (smu), proposte dai licenziatari; queste ultime sono generalmen-

te 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 inter-

net di BasicSamples e hanno la possibilità di interagire con i designers e di

inviare commenti relativi agli articoli; i licenziatari possono acquistare an-

che solo una parte della mega-collezione proposta da BasicSamples, creando

una collezione più piccola personalizzata alle esigenze del mercato in cui si


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 pro-

dotti 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 licenzia-

tari, 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.


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.

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 orga-

nizzativi 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 que-

sto 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 100

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 royal-

ties, 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’a-

zienda 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.

1Direttore Generale dei Sistemi Informativi di BasicNet


Dalle simulazioni svolte si è notato che l’andamento dei costi totali è si-

mile 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 si-

tuazione 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 Mer-

lo 2003a) riguarda l’approfondimento del confronto tra i diversi modelli di

business, inserendo valori di costo più vicini alla realtà, e in particolare l’a-

nalisi 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ù detta-

gliato della produzione, che nell’analisi di Lamieri (2002) e Merlo (2003a) è

stato solo ipotizzato.

Una seconda indicazione consiste nello studio più approfondito di due im-

portanti momenti del processo produttivo: le aste bandite da BasicNet nei

confronti delle Trading Company, necessarie per stabilire a chi sarà affida-

ta la produzione dei prodotti, e le previsioni eseguite dai licenziatari sulla

base dei MetaSamples proposti da BasicSamples. I MetaSamples sono, se-

condo 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.


Entro luglio 2004 il licenziatario italiano Kappa Italia cambierà la ragio-

ne 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: Kap-

pa, 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 licenzia-

tari; in questo modo diventerebbero direttamente responsabili del buon fine

della produzione e consegna delle collezioni.

Inoltre attualmente il processo produttivo dell’azienda segue una time-

table che specifica le fasi e i relativi tempi necessari per il percorso dei pro-

dotti 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.


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 que-

sta 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 Ba-

sicSamples, 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.


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 in-

serire 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 for-

nisce le garanzie necessarie viene iniziato lo sviluppo della nuova colle-

zione. La principale garanzia che il licenziatario deve dare è il raggiun-

gimento 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


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 del-

la collezione, per essere in grado di effettuare una prima verifica dei

prodotti.

7. BasicSample Buy: BasicSamples vende il campionario ai licenziata-

ri; 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 previsio-

ne degli acquisti per ciascun articolo della collezione. La necessità di

questa previsione è fornire immediatamente a BasicNet un’informazio-

ne 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


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 vie-

ne pubblicata sul sito www.basicfactory.com; da questo momento i li-

cenziatari 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 ag-

giornare 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).


Fase Data 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

Samples receiving at

Licensee Warehouse 16-mar-04 0 0

Final Forecast 16-mar-04 0 1

Sales Campaign 17-mar-04 15 10

Bid 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

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 La-

mieri (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 licen-

ziatari 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 si-

mulazione 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 produ-

zione.


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 com-

piere. 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 campiona-

rio di quattro collezioni diverse. Nel modello precedente si riferivano rispet-

tivamente 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 previ-

sione 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.


Con ricetta 500 BasicBiddings sceglie la vincente dell’asta: vince la Tra-

ding 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 accumu-

lano 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 previ-

sioni dei licenziatari per ciascun articolo della collezione e le quantità

richieste nel primo e nel secondo ordine, rispettivamente nella secon-

da e nella terza riga; nel modello è presente una agentMatrix per ogni

licenziatario;


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 rea-

lizzare, 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 licen-

ziatari per il primo ordine;

• la quinta contiene la quantità di ogni articolo richiesta dai licen-

ziatari 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 com-

putazionale, C1909, che permette ai licenziatari di effettuare il secondo

ordine.


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 di-

stribuzione 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¨


{

i n t th r e sho ld = 100 ;

checkMatr ixes ( 1 909 , 3 ) ;

des ignMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .


agentMatrix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .


bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .


l a y e r=pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;

i n t j = getCounter ( agentMatrix , 3 ) ;

i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )

{

i f ( j <= des ignMatr ix . getValue ( layer , 0 , 0 ) )

{

//Checks i f the l i c e n s e e has a l r eady done the f i r s t order

i f ( ! agentMatrix . getEmpty ( layer , 2 , j ) )

{

i n t s e l e c t = ( i n t )

normal . getSampleWithMean$withVariance (100 , 50000 ) ;

// dec ide to do or not another order

i f ( s e l e c t > thre sho ld )

{

i n t order2 = ( i n t )

normal . getSampleWithMean$withVariance (500 ,900000) ;

//Min va lue

i f ( order2 <10)

order2 = 10 ;


//Max va lue

i f ( order2 >25000)

order2 = 25000 ;

agentMatrix . setValue ( layer , 3 , j , order2 ) ;

i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )

bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;

i n t totOrder2 = ( i n t )

bas icNetMatr ix . getValue ( layer , 5 , j ) + order2 ;

bas icNetMatr ix . setValue ( layer , 5 , j , totOrder2 ) ;

System . out . p r i n t l n ( "The␣2nd␣ order ␣ o f ␣ L i censee␣#"

+ myUnit . getUnitNumber ( ) + "␣ i s ␣" + order2 + "␣ f o r ␣ item␣#"

+ j + "␣with␣ l ay e r␣#" + lay e r + "␣ totOrder␣#"+ totOrder2 ) ;

}//end i f ( s e l e c t )

e l s e

{

agentMatrix . setValue ( layer , 3 , j , 0 . 0 ) ;



}//end e l s e

i n t totOrder1 = ( i n t ) bas icNetMatr ix . getValue ( layer , 4 , j ) ;

i n t totOrder2 = ( i n t ) bas icNetMatr ix . getValue ( layer , 5 , j ) ;

i n t totOrder = totOrder1 + totOrder2 ;

bas icNetMatr ix . setValue ( layer , 6 , j , totOrder ) ;


}/end i f ( check ing f i r s t order )

}

}

}

done = true ;

// The a r t i c l e can not be ordered −> 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 busi-

ness 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 ca-

so 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 preceden-

temente.

6.9 Caso 1

In questa ricostruzione si presenta la BasicNet reale, che opera come descrit-

to 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 ori-

ginati 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 marke-

ting;

• 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 consegna-

no direttamente la merce ai licenziatari, perciò per ciascuna di esse ho ag-


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 pro-

duce 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;


• BasicBiddings;

• BasicFactory;

• unità rappresentative di BasicNet che si occupano della consegna del

campionario, della contabilizzazione dei ricavi e interrompono la simu-

lazione 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:

CUVBasicSamples =CV T

n◦MetaSamples=

59.806.000

6.676∼= 8.958

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

2Fonte: 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.


Divisione % costo 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 arti-

coli 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 conse-

gnato”, 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 cal-

cola 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.


6.9.4 Le modifiche al codice

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 co-

lonna 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 conse-

gnato dalla Trading Company incaricata di produrlo.



{






orMatrix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .


l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;

i n t counter = getCounter ( basicNetMatrix , 2 ) ;


{

i f ( counter <= des ignMatr ix . getValue ( layer , 0 , 0 ) )

{

//Check i f item has been produced

i f ( bas icNetMatr ix . 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␣␣#" + counter + "␣with␣ l ay e r␣#"

+ lay e r + "␣has␣been␣ d e l i v e r e d ␣by␣Trading␣Company␣" +

orMatrix . getValue ( layer , 1 , 0 ) ) ;

bas icNetMatr ix . setValue ( layer , 2 , counter , 4 . 0 ) ;

}

}

}

done = true ;

}//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


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.



{









{


{

i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , counter )

&& ! bas icNetMatr ix . getEmpty ( layer , 3 , counter )

&& ! bas icNetMatr ix . getEmpty ( layer , 6 , counter ) )

{

i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 3 .0 )

{



double i temPr ice =

basicNetMatr ix . getValue ( layer , 3 , counter ) ∗ 2 . 2 ;

double totRevenues =

itemPr ice ∗ basicNetMatr ix . getValue ( layer , 6 , counter ) ;

double i t emSa l e s = ( totRevenues ∗ 0 . 1 ) ;

System . out . p r i n t l n ( " Roya l t i e s ␣ f o r ␣ item␣␣#" +

counter + "␣with␣ l ay e r␣#" + lay e r +

"␣have␣been␣payed␣by␣ l i c e n s e e s " ) ;

S t r ing text =

Globals . env . getCurrentTime ( ) + " ␣ |␣ " +

i temSa le s + "␣\n" ;

logOpen ( f a l s e , " l og / g r o s s S a l e s . txt " ) ;

t ry

{

gro s sSa l e sLog . wr i t e ( t ex t ) ;

g ro s sSa l e sLog . f l u s h ( ) ;

}

catch ( IOException e )

{

System . out . p r i n t l n ( e ) ;

MyExit . e x i t ( 1 ) ;

}

}

}

}

}

done = true ;

}//end c1912§ ¦


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 I parametri della simulazione

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 pro-

grammazione utilizzato in questo file si chiama scheme, ed è un dialetto del

linguaggio Lisp.

Listing 6.4: jesframe.scm per il Caso 1¨

( l i s t

(

cons ’ eSFrameObserverSwarm

(

make−i n s t ance ’ ESFrameObserverSwarm

#:disp layFrequency 32

#:verboseChoice #f

#: pr in tMatr ixe s #f

#:checkMemorySize #f

#:unitHistogramXPos 1


#:unitHistogramYPos 600

#:endUnitHistogramXPos 578

#:endUnitHistogramYPos 1

)

)

(

cons ’ eSFrameModelSwarm

(

make−i n s t ance ’ ESFrameModelSwarm

#: u s eO rd e rD 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

#: revenuePerCostUnit 0

#: o rC r i t e r i o n 5

#:orMemoryMatrix 42

#: un i tC r i t e r i o n 2

)

)

)

;§ ¦

Essi significano:

useOrderDistiller: la successione delle ricette viene tratta dal file recipe-

Data/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 neces-

sita 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 magaz-

zini;

useNewses: se è impostato su true le unità si scambiano informazioni;

revenuePerEachRecipeStep e revenuePerCostUnit: metodo di calco-

lo 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 ;


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 operativi-

tà 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


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 ca-

so 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’arti-

colo 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 descrit-

te 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 cam-

pionario, eliminando l’oggetto computazionale C1911 il cui compito era cal-



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 è lan-

ciata 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).


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 pro-

duzione 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 totalMemoryMatri-

xNumber, 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 colle-

zioni ho ricavato dal bilancio consolidato di BasicNet del 2002 il valore delle

Commissioni del Sourcing, che rappresentano la remunerazione conferita ai


Sourcing Centers dai licenziatari per coprire i costi di struttura originati dal

servizio di intermediazione loro offerto. Il dato a bilancio si riferisce alle so-

cietà 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 =

=CommissionidelSourcing × 100

7=

1.588.000× 100

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

CostiTotali =22.685.714× 5

2= 56.714.286

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


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 arti-

coli 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:

CUVTradingCompany =CostiDiProduzione

n◦articoli=

56.714.286

80.000∼= 709

Per inserire i costi nel file unitData/unitBasicData.txt è necessario divi-

dere 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

4Fonte: BasicNet (2002)


modo descritto nel paragrafo precedente. Si ottiene pertanto che i costi totali

(CT ) di questa ipotetica BasicNet sono pari a:

CT = CV TBasicSamples + CFT + CV TTradingCompany =

= 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 licenzia-

tari dalle Trading Company, per ottenere il valore delle vendite (RTV endite) è

sufficiente impostare la seguente proporzione:

royalties÷ 0.1 = RTV endite ÷ 1

Inoltre occorre anche considerare tra i ricavi aziendali quelli che deriva-

no 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


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 = RTCT∼= 1, 65

Questo valore sarà inserito nel file jesframe.scm, che contiene i parametri

della simulazione.


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 diretta-

mente 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.




{









{


{



{

System . out . p r i n t l n ( " Item␣␣#" + counter + "␣with␣ l ay e r␣#"

+ lay e r + "␣has␣been␣ d e l i v e r e d " ) ;


}

}

}

done = true ;

}//end1913§ ¦



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 revenuePerCo-

stUnit, 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;


( l i s t

(


(



#:verboseChoice #f







)


)

(


(











#:useWarehouses #f

#:useNewses #f


#: revenuePerCostUnit 1 .65


)

)

)

;§ ¦

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 rappre-

sentazione 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 co-

sto 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 paragra-

fo 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 para-

grafo 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).



Rispetto alla classe ComputationalAssembler utilizzata nel caso 1, ho elimi-

nato i passi computazionali C1911 e C1912, che si occupano della contabi-

lizzazione 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.


I parametri su cui si basa la simulazione sono mostrati qui di seguito:


( l i s t

(


(



#:verboseChoice #f







)

)

(


(












#:useWarehouses #f

#:useNewses #f


#: revenuePerCostUnit 1 .65


#: o rC 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 mo-

difiche al modello. Partendo dal modello di Basic_jES presente in Lamieri

(2002) e Merlo (2003a) ho fatto nuovi esperimenti per migliorare il funzio-

namento 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 mo-

menti 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 osser-

va 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 Ba-

sic_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 realmen-

te 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


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 licen-

ziatario 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 mi-

gliorato, infatti osservando il file log/report.txt si può notare che circa il 90%

degli articoli disegnati è stato prodotto.


Figura 6.6: Primo esperimento. Tempodiesecuzione

Tempoprevistodallericette

Figura 6.7: Primo esperimento. Tempi d’attesa degli ordini


Layer MetaSamples 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/unit-

BasicData.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

5vedi paragrafo 6.5


Figura 6.8: Secondo esperimento. Tempodiesecuzione


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 preceden-

te 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 nu-

mero 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 BasicSam-

ples, 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’idea-

zione 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


Figura 6.10: Terzo esperimento. Tempodiesecuzione


i dipendenti di questa divisione sono 36. Conoscendo questo numero posso

infatti ottenere una migliore specificazione del modello e valutare con più at-

tenzione 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à (paragra-

fo 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 Focus sui licenziatari

6.14.1 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. Tempodiesecuzione


i ritardi dovuti alla formulazione delle previsioni e degli ordini sulle collezioni.

Con una nuova simulazione ho raddoppiato il numero di unità rappre-

sentative 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 tem-

pi 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 licenzia-

tari 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:


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 contem-

poraneamente le collezioni 1, 2, 3, 4;

4. intorno al tick 7.500, quando si deve disegnare la collezione 6;

Figura 6.12: Sesto esperimento. Tempodiesecuzione


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 licen-

ziatari, 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.

Figura 6.13: Licenziatari con tempo 0. Tempodiesecuzione



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 ese-

guire 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:

ArticoliPerDesigner =6676

36∼= 185

Con questi dati è possibile calcolare il numero di ore necessario ad un

designer per la creazione di un articolo nel seguente modo:6vedere paragrafo 6.57Fonte: BasicNet (2002)


h =2080

185∼= 11, 24

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, trasforman-

dole, 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

15= 45

dato che 1 tick = 15 minuti.

Perciò occorre riscrivere nel file recipeData/recipes.xls le ricette che de-

scrivono 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’anda-

mento della simulazione mostrato in Figura 6.14. Le code legate all’atti-

vità 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 Ba-

sicNet 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 as-

sunzioni fatte precedentemente, che potrebbero anche discostarsi da quanto

avviene nella realtà; infatti per eliminare i ritardi nella produzione i desi-

gners 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.


Figura 6.14: Approfondimento di Basicsamples. Tempodiesecuzione


Pertanto si può concludere che BasicSamples rappresenta un bottle neck

per BasicNet nel solo momento in cui tutte le ipotesi fatte durante la for-

mulazione 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 sol-

tanto 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à ri-

sulta 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


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 varia-

bili. 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.



Figura 6.15: Andamento di costi, ricavi e profitti totali (Caso 1)

Figura 6.16: Andamento di costi, ricavi e profitti giornalieri (Caso 1)


Le curve dei ricavi e dei profitti presentano andamenti simili e, ovviamen-

te, 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 tradizio-

nale 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 Fi-

gura 6.18, dove la curva dei costi giornalieri ha dei ‘‘picchi” in corrispondenza

dei momenti in cui le Trading Company sono chiamate ad operare.

9vedi paragrafo 6.10.210vedi paragrafo 6.10.3


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’andamen-

to 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 pubbli-

co. 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,



come nei casi precedenti, e i profitti giornalieri risultano positivi soltanto per

30 giorni, cioè in numero minore rispetto al caso precedente.

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 . java

import swarm . Globals ;

import swarm . de fob j . Zone ;

import swarm . ob j e c tbase . SwarmObjectImpl ;

import swarm . c o l l e c t i o n s . L i s t Impl ;

import swarm . c o l l e c t i o n s . L i s t Index ;

import swarm . random . NormalDistImpl ;

import java . lang . Float ;

import java . i o . ∗ ;

import java . u t i l . ∗ ;

/∗∗

∗ The ComputationalAssembler c lass instances make

∗ computational processes ; we have a computational assembler

∗ instance for each unit

∗

∗

∗ @author 

∗ Marco Lamieri<a href="mailto : lamieri@econ . unito . i t"></a>

∗ Francesco Merlo<a href="mailto :merlo@econ . unito . i t"></a>

∗ @version 0 .9 .7 .31 . b (BasicJVE 1.0)

∗/

pub l i c c l a s s ComputationalAssembler extends ComputationalAssemblerBasic

{

//Our MemoryMatrixes

MemoryMatrix designMatrix , basicNetMatrix , tcMatrix ,

orMatrix , agentMatrix ;

165

APPENDICE 166

//A normal d i s t r i bu t ion for random numbers

NormalDistImpl normal ;

//grossSales Fi le management

pub l i c boolean grossSa lesLogFi leOpen = f a l s e ;

F i l eWr i t e r g ro s sSa l e sLog=nu l l ;

i n t samplesN=0;

f l o a t sampleSales = 0 ;

f l o a t i t emSa le s = 0 ;

pub l i c MyWriter r epor t=nu l l ;

/∗∗

∗ the constructor for ComputationalAssembler

∗/

pub l i c ComputationalAssembler ( Zone aZone , O rd e rD i s t i l l e r od , ESFrameModelSwarm mo)

{

// Call the constructor for the parent c lass .

super ( aZone , od , mo) ;

normal = new NormalDistImpl ( getZone ( ) ) ;

}

//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

// BasicJES Computational codes

//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

/∗∗ computational operations with code −1901 

∗

∗ t h i s computational code increment 1 by 1 posi t ion 0 ,0 of

∗ the unique received matrix and set the status to done

∗/


{

checkMatrixes ( 1901 , 1 ) ;

des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .



// Zeroing the counter i f empty

i f ( des ignMatr ix . getEmpty ( layer , 0 , 0 ) )

des ignMatr ix . setValue ( layer , 0 , 0 , 0 . 0 ) ;

i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;

counter++;

//Here we store the number of MetaSample produced

des ignMatr ix . setValue ( layer , 0 , 0 , counter ) ;

System . out . p r i n t l n ( "MetaSample␣#" + counter + "␣with␣ l ay e r␣#" + laye r

+ "␣has␣been␣drawn" ) ;

done=true ;

}// end c1901


∗

∗ t h i s computational code d ia l with l icensee ’ s predict ions .

∗

∗/

APPENDICE 167

{




agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .



// Making predict ion for ava i lab l e MetaSample


{

//Switching to an other a r t i c l e


//The l icensee predict ion

i n t f o r e c a s t = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;

//Min value

i f ( f o r e c a s t < 10)

f o r e c a s t = 10 ;

//Max value

i f ( f o r e c a s t > 25000)

f o r e c a s t = 25000;

//Storing the predict ion

agentMatrix . setValue ( layer , 1 , j , f o r e c a s t ) ;

System . out . p r i n t l n ( " L icensee␣#" + myUnit . getUnitNumber ( ) + "␣ f o r e c a s t ed ␣"

+ f o r e c a s t + "␣ f o r ␣MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r ) ;

// End of predict ions

done=true ;

}//Waiting for some MetaSample −> done=fa l s e

}// end c1902


∗

∗ t h i s computational code sums up predict ions .

∗

∗/


{

f l o a t sum = 0;

i n t th re sho ld = 18000;

boolean endForecast = true ;




bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .

getMemoryMatrixAddress ( 3 6 ) ;

l ay e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;

// Getting the number of a r t i c l e s


f o r ( i n t j =1 ; j <=counter ; j++)

APPENDICE 168

{

f o r ( i n t t =1 ; t <=35 ; t++)

{

MemoryMatrix agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .

getMemoryMatrixAddress ( t ) ;

//Checking i f the l icensee made a predict ion for th i s MetaSample

i f ( ! ( agentMatrix . getEmpty ( layer , 1 , j ) ) )

{

sum = sum + agentMatrix . getValue ( layer , 1 , j ) ;

}

}

//Storing t o t a l predict ions in basicNet Matrix

basicNetMatr ix . setValue ( layer , 1 , j , sum ) ;

//Checking i f MetaSample can be produced

i f ( sum > thre sho ld )

{

basicNetMatr ix . setValue ( layer , 2 , j , 1 ) ;

System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r +

"␣can␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=1" ) ;

}

e l s e

{



"␣can␣NOT␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=0" ) ;

}

//Waiting a l l predict ions

f o r ( i n t t =1 ; t <=35 ; t++)

{



i f ( agentMatrix . getEmpty ( layer , 1 , j ) )

endForecast = f a l s e ;

}

i f ( endForecast )

{

System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r

+ "␣ f o r e c a s t ed ␣by␣ a l l ␣ l i c e n s e e " ) ;

done=true ;

}

sum = 0;

}

}

// end c1903


∗

∗ t h i s computational code check tresho ld and i f above

∗ set 1 to row 2 matrix in pos 1 ∗ and set done=true .

∗ 1 c e l l for each number of row read in matrix in pos 0 (0 ,0) ,

∗ whit a counter in posi t ion (0 ,1)

∗/


{

f l o a t va l ;

APPENDICE 169








i n t i = getCounter ( basicNetMatrix , 1 ) ;

//check the number of items and the status

i f ( ! des ignMatr ix . getEmpty ( layer ,0 ,0 ) && ! basicNetMatr ix . getEmpty ( layer , 2 , i ) )

{

i f ( i <= designMatr ix . getValue ( layer ,0 ,0) && basicNetMatr ix . getValue ( layer , 2 , i ) == 1)

{

System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣produced␣MetaSample␣#" + i

+ "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=2" ) ;

bas icNetMatr ix . setValue ( layer , 2 , i , 2 ) ;

done=true ;

}

e l s e

{

System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣NOT␣produced␣MetaSample␣#"

+ i + "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=1" ) ;

}

}

}

// end c1904


∗

∗ This computational code d ia l s with TC offer−price

∗/


{

f l o a t o f f e rP r i c e , random ;






tcMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .



//Making an offer−price for ava i lab l e a r t i c l e s


{


f o r ( i n t i =1; i<=counter ; i++)

{

i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )

APPENDICE 170

{

i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 0)

{

//The offer−price

o f f e r P r i c e = ( in t ) normal . getSampleWithMean$withVariance ( 7 , 1 0 ) ;

//Min value

i f ( o f f e rP r i c e <1)

o f f e r P r i c e = 1 ;

//Max value

i f ( o f f e rP r i c e >20)

o f f e r P r i c e =20;

//Storing the of fer−price of the TC

tcMatrix . setValue ( layer , 1 , i , o f f e r P r i c e ) ;

System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( )

+ "␣ o f f e r ␣ p r i c e ␣ f o r ␣MetaSample␣#" + i + "␣with␣ l ay e r␣#" + laye r + "␣ i s ␣$"

+ o f f e r P r i c e ) ;

}

e l s e


+ "␣can␣not␣make␣an␣ o f f e r ␣ f o r ␣Metasample␣#" + i + "␣with␣ l ay e r␣#" + laye r ) ;

}

}

done=true ;

}

// Waiting for some MetaSample −> done=fa l s e

}

// end c1905


∗ This computational code d ia l with the bidding phase

∗/


{

MemoryMatrix choiceMatr ix ;






orMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .



// Checking MetaSamples


{



{

in t cho i c e = 0 ;

f l o a t o f f e r =0;

//Checking the status


{

APPENDICE 171


{

//Here we make the bidding

f o r ( i n t t =1 ; t <=5 ; t++)

{

MemoryMatrix tcMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .


i f ( ! tcMatrix . getEmpty ( layer , 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 ) ;

cho i c e = t ;

}

}

}

//Checking the TC chosen


{

i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) >0 && (!( cho i c e ==0)))

{

//Getting i t s o f f e r price . . .

choiceMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .

getMemoryMatrixAddress ( cho i c e ) ;

f l o a t o f f e r P r i c e = choiceMatr ix . getValue ( layer , 1 , i ) ;

// . . . s toring i t in basicNet Matrix . . .

basicNetMatr ix . setValue ( layer , 3 , i , o f f e r P r i c e ) ;

// . . . and in the orMatrix

orMatrix . setValue ( layer , 1 , i , cho i c e ) ;

System . out . p r i n t l n ( "Trading␣Company␣#" + orMatrix . getValue ( layer , 1 , i ) +

"␣has␣been␣ chosen ␣ f o r ␣MetaSample␣#" + i + "␣with␣ l ay e r␣#" + laye r + "␣ p r i c e ␣"

+ basicNetMatr ix . getValue ( layer , 3 , i ) ) ;

}

}

}

}

}

done=true ;

}


}

// end c1906


∗

∗ t h i s computational code d ia l with l icensee ’ s f i r s t order .

∗

∗/


{

APPENDICE 172






{


i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , j ) )

{

//Check i f the l icensee received the re la ted MetaSample

i f ( bas icNetMatr ix . getValue ( layer , 2 , j )>1)

{

in t order1 = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;

//Min value

i f ( order1 <10)

order1 = 10 ;

//Max value

i f ( order1 >25000)

order1 = 25000;




i n t totOrder1 = ( in t ) basicNetMatr ix . getValue ( layer , 4 , j ) + order1 ;


System . out . p r i n t l n ( "The␣1 s t ␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( )

+ "␣ i s ␣" + order1 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r + "␣ totOrder␣#"

+totOrder1 ) ;

done=true ;

}

// The a r t i c l e can not be ordered −> done=fa l s e

}

}

}

// end c1907


∗

∗ t h i s computational code d ia l with or branch choice .

∗

∗/


{

APPENDICE 173


{

//Switching to another a r t i c l e

i n t i = getCounter ( orMatrix , 0 ) ;

i f ( i <= designMatr ix . getValue ( layer , 0 , 0 ) )

{


{

//Check i f the item can be produced ( status >1)

i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 1 && ! orMatrix . getEmpty ( layer , 1 , i ) )

{

f l o a t branch = orMatrix . getValue ( layer , 1 , i ) ;

orMatrix . setValue ( layer , 1 , 0 , branch ) ;

System . out . p r i n t l n ( "Branch␣␣#" + orMatrix . getValue ( layer ,1 ,0 ) +

"␣produced␣ item␣#" + i + "␣with␣ l ay e r␣#" + laye r ) ;

bas icNetMatr ix . setValue ( layer , 2 , i , 3 . 0 ) ;

done= true ;

}

}

// The a r t i c l e can not be produced −> done=fa l s e

}

}

}

//end c1908


∗

∗ t h i s computational code d ia l with l icensee ’ s second order .

∗

∗/


{

i n t th re sho ld = 100 ;











{

i f ( j <= designMatr ix . getValue ( layer , 0 , 0 ) )

{

//Checks i f the l icensee has already done the f i r s t order


{

i n t s e l e c t = ( in t ) normal . getSampleWithMean$withVariance (100 ,50000) ;

APPENDICE 174

//decide to do or not another order


{

i n t order2 = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;

//Min value

i f ( order2 <10)

order2 = 10 ;

//Max value

i f ( order2 >25000)

order2 = 25000;






System . out . p r i n t l n ( "The␣2nd␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( )


+ totOrder2 ) ;


e l s e

{




}//end e l se

i n t totOrder1 = ( in t ) basicNetMatr ix . getValue ( layer , 4 , j ) ;




}//end i f ( checking f i r s t order )

}

}

done = true ;


}// end c1909


∗

∗ This computational code prints the Report and stops the simulation .

∗

∗/

APPENDICE 175


{







t ry

{

repor t = new MyWriter ( " log / repor t . txt " ) ;

r epor t .

wr i t e ( "Layer ␣ |␣MetaSampleN ␣ |␣ Status0 ␣ |␣ Status1 ␣ |␣ Status2 ␣ |␣ Status3 ␣ |␣ Status ␣4␣␣\n" ) ;

}


{



}

f o r ( i n t ln =1; ln <=16; ln++)

{

in t metaSamplesN=0;

i n t [ ] s t a tu s ;

s t a tu s = new in t [ 5 ] ;

f o r ( i n t s =0; s <=4; s++)

s ta tu s [ s ]=0;

i f ( ! des ignMatr ix . getEmpty ( ln , 0 , 0 ) )

metaSamplesN= ( in t ) des ignMatr ix . getValue ( ln , 0 , 0 ) ;

f o r ( i n t item=1; item <=150; item++)

{

i f ( ! bas icNetMatr ix . getEmpty ( ln , 2 , item ) )

s t a tu s [ ( i n t ) basicNetMatr ix . getValue ( ln , 2 , item )]++;

}

St r ing text = ln + " ␣ |␣ " + metaSamplesN + " ␣ |␣ " + s ta tu s [ 0 ] + " ␣ |␣ " + s ta tu s [ 1 ]

+ " ␣ |␣ " + s ta tu s [ 2 ] + " ␣ |␣ " + s ta tu s [ 3 ] + " ␣ |␣ " + s ta tu s [ 4 ] + "␣\n" ;

t ry

{

repor t . wr i t e ( t ext ) ;

}


{



}

}

try

{

repor t . c l o s e ( ) ;

}


{

APPENDICE 176



}

System . out . p r i n t l n ( "∗∗∗∗∗␣THIS␣ IS␣THE␣END!␣∗∗∗∗∗ " ) ;

StartESFrame . eSFrameObserverSwarm . getContro lPanel ( ) . setStateStopped ( ) ;

done = true ;

}//end c1910


∗

∗ This computational code ca lcu la tes gross sa les from samples .

∗

∗/


{







f l o a t samplePrice = ( f l o a t ) normal . getSampleWithMean$withVariance ( 3 5 , 6 ) ;


logOpen ( true , " log / g r o s s Sa l e s . txt " ) ;

S t r ing text = Globals . env . getCurrentTime () + " ␣ |␣ " + samplePrice + "␣\n" ;

t ry

{

gros sSa l e sLog . wr i t e ( t ext ) ;


}


{



}

done = true ;

}//end c1911


∗

∗ This computational code ca lcu la tes the value of roya l t i e s .

∗

∗/


{




APPENDICE 177

basicNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .





{

i f ( counter <= designMatr ix . getValue ( layer , 0 , 0 ) )

{

i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , counter )

&& ! basicNetMatr ix . getEmpty ( layer , 3 , counter ) && ! basicNetMatr ix .

getEmpty ( layer , 6 , counter ) )

{

i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 3 .0 )

{

double i temPrice = basicNetMatr ix . getValue ( layer , 3 , counter ) ∗ 2 . 2 ;

double totRevenues = itemPrice ∗ basicNetMatr ix . getValue ( layer , 6 , counter ) ;

double i t emSa le s = ( totRevenues ∗ 0 . 1 ) ;

System . out . p r i n t l n ( " Roya l t i e s ␣ f o r ␣ item␣␣#" + counter + "␣with␣ l ay e r␣#" + laye r

+ "␣have␣been␣payed␣by␣ l i c e n s e e s " ) ;

S t r ing text = Globals . env . getCurrentTime () + " ␣ |␣ " + itemSa le s + "␣\n" ;

logOpen ( f a l s e , " log / g r o s s Sa l e s . txt " ) ;

t ry

{

gros sSa l e sLog . wr i t e ( t ext ) ;


}


{



}

}

}

}

}

done = true ;

}//end c1912


∗

∗ This computational code d i s t r i bu t e s items to the l i censees .

∗

∗/


{

APPENDICE 178






{


{



{

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␣␣#" + counter + "␣with␣ l ay e r␣#" + laye r

+ "␣has␣been␣ de l i v e r ed ␣by␣Trading␣Company␣" + orMatrix . getValue ( layer , 1 , 0 ) ) ;


}

}

}

done = true ;

}//end c1913

//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

// Private functions

//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

//The counter i s used in some computationl code in order to take actions

// on d i f f e r en t a r t i c l e with only a recipe

pr i va t e i n t getCounter (MemoryMatrix currentMatrix , i n t row )

{

//Zeroing the counter i f empty

i f ( currentMatr ix . getEmpty ( layer , row , 0 ) )

currentMatr ix . setValue ( layer , row , 0 , 0 . 0 ) ;

//Here we increment the counter

i n t counter = ( in t ) currentMatr ix . getValue ( layer , row , 0 ) ;

counter++;

//The counter must be l e s s than the number of MetaSample


currentMatr ix . setValue ( layer , row , 0 , counter ) ;

r e turn counter ;

}

p r i va t e void checkMatrixes ( i n t code , i n t numberOfMatrixes )

{

i f ( pend ingComputat iona lSpec i f i ca t ionSet .

getNumberOfMemoryMatrixesToBeUsed () != numberOfMatrixes )

{

System . out . p r i n t l n ( "Code␣−"+ code + "␣ r e qu i r e s ␣" + numberOfMatrixes + "␣matrix ; ␣ "

+ pend ingComputat iona lSpec i f i ca t ionSet . getNumberOfMemoryMatrixesToBeUsed ( )

+ "␣ found␣ in ␣ order␣#␣" + pend ingComputat iona lSpec i f i ca t ionSet . getOrderNumber ( ) ) ;

APPENDICE 179


}

}

p r i va t e void logOpen ( boolean e r a s eF i l e , S t r ing f i leName )

{

F i l e f i l eOut = new F i l e ( f i leName ) ;

i f ( ! t h i s . grossSa lesLogFi leOpen && e r a s eF i l e )

{

try

{

F i l eWr i t e r e ra s e = new Fi l eWr i t e r ( f i l eOut , f a l s e ) ;

e r a s e . c l o s e ( ) ;

}


{



}

}

try

{

gros sSa l e sLog = new Fi l eWr i t e r ( f i l eOut , t rue ) ;

t h i s . grossSa lesLogFi leOpen = true ;

}


{



}

}

}

§ ¦

Caso 2











/∗∗


∗ computational processes ; we have a computationa assembler instance for

∗ each unit

∗

∗

∗ @author

APPENDICE 180



∗/


{


MemoryMatrix designMatrix , basicNetMatrix , tcMatrix , orMatrix , agentMatrix ;






i n t samplesN=0;




/∗∗


∗/


{




}

//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗


//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗


∗

∗ t h i s computational code increment 1 by 1 posi t ion 0 ,0 of the

∗ unique received matrix and set the status to done

∗/


{









counter++;





done=true ;

APPENDICE 181

}

// end c1901


∗


∗

∗/


{









{





//Min value

i f ( f o r e c a s t < 10)

f o r e c a s t = 10 ;

//Max value

i f ( f o r e c a s t > 25000)

f o r e c a s t = 25000;



System . out . p r i n t l n ( " L icensee␣#" + myUnit . getUnitNumber ( ) + "␣ f o r e c a s t ed ␣"

+ f o r e c a s t + "␣ f o r ␣MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r ) ;


done=true ;

}

//Waiting for some MetaSample −> done=fa l s e

}

// end c1902


∗


∗

∗/


{

f l o a t sum = 0;

APPENDICE 182










{

f o r ( i n t t =1 ; t <=35 ; t++)

{





{


}

}





{



"␣can␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=1" ) ;

}

e l s e

{



+ "␣can␣NOT␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=0" ) ;

}


f o r ( i n t t =1 ; t <=35 ; t++)

{





}

i f ( endForecast )

{



done=true ;

}

sum = 0;

}

}

// end c1903

APPENDICE 183


∗





∗/


{

f l o a t va l ;











{


{

System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣produced␣MetaSample␣#" + i

+ "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=2" ) ;


done=true ;

}

e l s e

{



}

}

}

// end c1904


∗


∗

∗/


{







APPENDICE 184




{



{



{


//Min value

i f ( order1 <10)

order1 = 10 ;

//Max value

i f ( order1 >25000)

order1 = 25000;






System . out . p r i n t l n ( "The␣1 s t ␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( )

+ "␣ i s ␣" + order1 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r

+ "␣ totOrder␣#"+ totOrder1 ) ;

done=true ;

}


}

}

}

// end c1907


∗


∗

∗/


{

APPENDICE 185



{


{



{




{


//Min value

i f ( order2 <10)

order2 = 10 ;

//Max value

i f ( order2 >25000)

order2 = 25000;








+ totOrder2 ) ;


e l s e

{




}//end






}

}

done = true ;

APPENDICE 186

}// end c1909


∗


∗

∗/


{







t ry

{


r epor t .

wr i t e ( "Layer ␣ |␣MetaSampleN ␣ |␣ Status0 ␣ |␣ Status1 ␣ |␣ Status2 ␣ |␣ Status3 ␣ |␣ Status ␣4␣␣␣\n" ) ;

}


{



}

f o r ( i n t ln =1; ln <=16; ln++)

{

in t metaSamplesN=0;



f o r ( i n t s =0; s <=4; s++)

s ta tu s [ s ]=0;




{



}



t ry

{


}


{

APPENDICE 187

}

}

try

{


}


{



}



done = true ;

}//end c1910


∗


∗

∗/


{









{


{



{


+ "␣has␣been␣ de l i v e r ed " ) ;


}

}

}

done = true ;

}//end c1913

//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗


//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

APPENDICE 188




{






counter++;




r e turn counter ;

}


{



{





}

}

p r i va t e void logOpen ( boolean e r a s eF i l e , S t r ing f i leName )

{



{

try

{


e r a s e . c l o s e ( ) ;

}


{



}

}

try

{



}


{



}

}

}

§ ¦

APPENDICE 189

Caso 3











/∗∗


∗ computational processes ; we have a computationa assembler instance for

∗ each unit

∗

∗

∗ @author 




∗/


{


MemoryMatrix designMatrix , basicNetMatrix , tcMatrix , orMatrix , agentMatrix ;






i n t samplesN=0;




/∗∗


∗/


{




}

//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗


//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗


∗

∗ t h i s computational code increment 1 by 1 posi t ion 0 ,0 of the

∗ unique received matrix and set the status to done

APPENDICE 190

∗/


{









counter++;





done=true ;

}

// end c1901


∗


∗

∗/


{









{





//Min value

i f ( f o r e c a s t < 10)

f o r e c a s t = 10 ;

//Max value

i f ( f o r e c a s t > 25000)

f o r e c a s t = 25000;

APPENDICE 191


System . out . p r i n t l n ( " L icensee␣#" + myUnit . getUnitNumber ( ) + "␣ f o r e c a s t ed ␣" + f o r e c a s t

+ "␣ f o r ␣MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r ) ;


done=true ;

}

//Waiting for some MetaSample −> done=fa l s e

}

// end c1902


∗


∗

∗/


{

f l o a t sum = 0;












{

f o r ( i n t t =1 ; t <=35 ; t++)

{





{


}

}





{



+ "␣can␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=1" ) ;

}

e l s e

{

APPENDICE 192


+ "␣can␣NOT␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=0" ) ;

}


f o r ( i n t t =1 ; t <=35 ; t++)

{





}

i f ( endForecast )

{



done=true ;

}

sum = 0;

}

}

// end c1903


∗





∗/


{

f l o a t va l ;











{


{

System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣produced␣MetaSample␣#"



done=true ;

}

APPENDICE 193

e l s e

{



}

}

}

// end c1904


∗

∗ This computational code d ia l s with TC offer−price

∗/


{

f l o a t o f f e rP r i c e , random ;






tcMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .



//Making an offer−price for ava i lab l e a r t i c l e s


{



{


{


{

//The offer−price

o f f e r P r i c e = ( in t ) normal . getSampleWithMean$withVariance ( 7 , 1 0 ) ;

//Min value

i f ( o f f e rP r i c e <1)

o f f e r P r i c e = 1 ;

//Max value

i f ( o f f e rP r i c e >20)

o f f e r P r i c e =20;

//Storing the of fer−price of the TC

tcMatrix . setValue ( layer , 1 , i , o f f e r P r i c e ) ;


+ "␣ o f f e r ␣ p r i c e ␣ f o r ␣MetaSample␣#" + i + "␣with␣ l ay e r␣#" + laye r + "␣ i s ␣$"

+ o f f e r P r i c e ) ;

}

e l s e


+ "␣can␣not␣make␣an␣ o f f e r ␣ f o r ␣Metasample␣#" + i + "␣with␣ l ay e r␣#" + laye r ) ;

}

}

APPENDICE 194

done=true ;

}


}

// end c1905


∗ This computational code d ia l with the bidding phase

∗/


{

MemoryMatrix choiceMatr ix ;









// Checking MetaSamples


{



{

in t cho i c e = 0 ;

f l o a t o f f e r =0;

//Checking the status


{


{

//Here we make the bidding

f o r ( i n t t =1 ; t <=5 ; t++)

{

MemoryMatrix tcMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .


i f ( ! tcMatrix . getEmpty ( layer , 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 ) ;

cho i c e = t ;

}

}

}

//Checking the TC chosen


{

i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) >0 && (!( cho i c e ==0)))

{

//Getting i t s o f f e r price . . .

APPENDICE 195

choiceMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .

getMemoryMatrixAddress ( cho i c e ) ;

f l o a t o f f e r P r i c e = choiceMatr ix . getValue ( layer , 1 , i ) ;

// . . . s toring i t in basicNet Matrix . . .

basicNetMatr ix . setValue ( layer , 3 , i , o f f e r P r i c e ) ;

// . . . and in the orMatrix

orMatrix . setValue ( layer , 1 , i , cho i c e ) ;

System . out . p r i n t l n ( "Trading␣Company␣#" + orMatrix . getValue ( layer , 1 , i )

+ "␣has␣been␣ chosen ␣ f o r ␣MetaSample␣#" + i + "␣with␣ l ay e r␣#" + laye r + "␣ p r i c e ␣"

+ basicNetMatr ix . getValue ( layer , 3 , i ) ) ;

}

}

}

}

}

done=true ;

}


}

// end c1906


∗


∗

∗/


{










{



{



{


//Min value

i f ( order1 <10)

order1 = 10 ;

//Max value

i f ( order1 >25000)

order1 = 25000;

APPENDICE 196





System . out . p r i n t l n ( "The␣1 s t ␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( ) + "␣ i s ␣"

+ order1 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r + "␣ totOrder␣#"+totOrder1 ) ;

done=true ;

}


}

}

}

// end c1907


∗

∗ t h i s computational code d ia l with or branch choice .

∗

∗/


{










{

//Switching to another a r t i c l e

i n t i = getCounter ( orMatrix , 0 ) ;

i f ( i <= designMatr ix . getValue ( layer , 0 , 0 ) )

{


{

//Check i f the item can be produced ( status >1)

i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 1 && ! orMatrix . getEmpty ( layer , 1 , i ) )

{

f l o a t branch = orMatrix . getValue ( layer , 1 , i ) ;

orMatrix . setValue ( layer , 1 , 0 , branch ) ;

System . out . p r i n t l n ( "Branch␣␣#" + orMatrix . getValue ( layer , 1 , 0 )

+ "␣produced␣ item␣#" + i + "␣with␣ l ay e r␣#" + laye r ) ;

bas icNetMatr ix . setValue ( layer , 2 , i , 3 . 0 ) ;

done= true ;

}

}

// The a r t i c l e can not be produced −> done=fa l s e

APPENDICE 197

}

}

}

//end c1908


∗


∗

∗/


{












{


{



{




{


//Min value

i f ( order2 <10)

order2 = 10 ;

//Max value

i f ( order2 >25000)

order2 = 25000;

APPENDICE 198


+ totOrder2 ) ;


e l s e

{




}//end e l se






}

}

done = true ;


}// end c1909


∗


∗

∗/


{







t ry

{


r epor t .

wr i t e ( "Layer ␣ |␣MetaSampleN ␣ |␣ Status0 ␣ |␣ Status1 ␣ |␣ Status2 ␣ |␣ Status3 ␣ |␣ Status ␣4␣␣\n" ) ;

}


{



}

f o r ( i n t ln =1; ln <=16; ln++)

{

APPENDICE 199

i n t metaSamplesN=0;



f o r ( i n t s =0; s <=4; s++)

s ta tu s [ s ]=0;




{



}



t ry

{


}


{



}

}

try

{


}


{



}



done = true ;

}//end c1910


∗


∗

∗/


{

APPENDICE 200





{


{



{


+ "␣has␣been␣ de l i v e r ed " ) ;


}

}

}

done = true ;

}//end c1913

//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗


//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗




{






counter++;




r e turn counter ;

}


{



{





}

}

APPENDICE 201

pr i va t e void logOpen ( boolean e r a s eF i l e , S t r ing f i leName )

{



{

try

{


e r a s e . c l o s e ( ) ;

}


{



}

}

try

{



}


{



}

}

}

§ ¦

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: under-

standing 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 203

[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 − Computer-

based 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 creati-

vità 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.

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. Ap-

plicazione 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 Simula-

tor (jES) Program, http://web.econ.unito.it/terna/jes_files/jesframe-

0.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 P., (1998), Simulation Tools for Social Scien-

tists: Building Agent Based Models with SWARM, Journal

of Artificial Societies and Social Simulation vol. 1, 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 organizzazio-

ni, 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 206

[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 Connec-

ted 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.

simulazione ad agenti e sistemi complessi. applicazione al ... · attività e una con˝gurazione...

Documents