Gli elementi fondamentali di un Management Game

Come è stato anticipato, le simulazioni manageriali hanno molte sfaccettature e prima di tutto si possono interpretare come l’insieme di tre attività: la simulazione, il gioco e la competizione.

All’interno dell’area comune a questi tre elementi, ovvero all’interno di un vero Business Game, per Teach (1990) sembrano esserci almeno quattro elementi condivisi: lo scenario, i ruoli, il sistema di registrazione dei dati e l’algoritmo che sottende il modello di simulazione.

Lo scenario può essere inteso come la descrizione dell’impresa che viene simulata e delle altre che competono con questa. Solitamente questo contiene riferimenti alle variabili interne o esterne che condizionano il gioco e descrive il grado di competitività delle interazioni, quindi rappresenta la storia che delinea il mercato in cui operano le aziende e il loro effetto, così come il potenziale di crescita, la variabilità del tasso di inflazione e tutto ciò potrebbe influenzare l’economia.

Questi fondamenti sono importanti e dovrebbero essere conosciuti in qualche misura da tutti i partecipanti se vogliono prendere decisioni appropriate. Un dibattito rimane comunque sulla quantità di informazioni necessaria da fornire ai partecipanti, in quanto un numero insufficiente di dati potrebbe portare a troppe congetture, mentre troppe notizie potrebbero sopraffare i giocatori e portarli ad una “paralisi” nella capacità di analisi o addirittura all’arresa di tutta la squadra. In realtà parte della risposta sulla quantità di informazioni da fornire risulta dal livello atteso di preparazione dei partecipanti e dai ruoli che chi progetta la simulazione si aspetta che i partecipanti sappiano svolgere, dal momento che ogni ruolo richiede ad una simulazione differenti quantità di dettagli (Teach, 1990).

Le decisioni di ogni team vengono poi registrate dal sistema di contabilità, che riporta i risultati del round di gioco nella simulazione di solito attraverso una serie di dichiarazioni dei redditi, bilanci e rapporti operativi. I sistemi contabili nelle imprese simulate sono considerati aggregazioni delle operazioni finanziarie e fisiche che si verificano durante il periodo di gioco. Tuttavia, le informazioni non sono sempre precise, ad esempio le fatture non possono essere rintracciate, i singoli colli di bottiglia nel processo di produzione non possono essere rilevati, né le prestazioni dei componenti specifici del canale di distribuzione da controllare. Questa mancanza di informazioni specifiche e conoscenze di solito è respinta perché la maggior parte dei Business Games si focalizzano sulla strategia piuttosto che sul livello tattico, ma ciò non implica che alcune registrazioni più dettagliate non potrebbero essere incluse (Teach, 1990).

Ogni simulazione è inoltre formata da algoritmi, procedure operative o equazioni che tengono conto delle decisioni (variabili endogene) e delle condizioni economiche simulate (variabili esogene) come input, le combinano con i fatti storici e ne calcolano gli esiti. Tali procedure quindi prendono in considerazione la cronologia delle decisioni passate di ciascuna delle imprese in gioco, determinano i risultati e aggiornano il file della storia di ogni impresa.

Sulla base di queste caratteristiche, Teach (1990) afferma che i giochi con ruoli forti, ma deboli scenari e deboli sistemi contabili possono essere chiamati esercizi di “role playing”; giochi con un forte

158 scenario sono molto simili ad un caso di studio; mentre giochi con una forte procedura contabile possono essere definiti simulazioni.

Una delle nozioni che risulta essenziale inoltre per una simulazione di business, soprattutto se utilizzata a scopo formativo, per l’autore è sicuramente il coinvolgimento simultaneo e attivo dei partecipanti.

La creazione di gruppi che interagiscono come mezzo per risolvere i problemi, dal lato dei partecipanti rappresenta un grande vantaggio per un BG, in quanto sembra che il lavoro di squadra dia risultati migliori di quello individuale. I gruppi o le squadre sembrano infatti generare una serie di approcci, mentre i singoli individui tendono a fermarsi su certe posizioni; i membri del team sembrano in aggiunta comprendere meglio i problemi su larga scala e di conseguenza trovare soluzioni più adeguate rispetto ai singoli individui (Teach, 1990).

Anche se queste interazioni sono intuitivamente sentite come una componente importante del BG, la loro sostanza è difficile da rappresentare; esistono infatti almeno quattro tipi di interazioni che hanno luogo quando viene eseguita una di queste simulazioni di gestione: all’interno dei team; tra le squadre; tra le squadre e l’amministratore del sistema; tra ciascuna squadra e la struttura del gioco. Sebbene esistano differenze di opinione circa l’importanza di queste interazioni da parte degli utenti, un ragionevole accordo sembra esistere sul fatto che queste relazioni sono al centro di tutti i giochi.

La tesi secondo cui le dinamiche del contesto economico richiedono il coinvolgimento di altri nel processo decisionale, è ciò che dà credibilità all’importanza delle interazioni all’interno della squadra. In numerose situazioni, squadre con una forte dinamica di gruppo sono risultate superiori nelle performance a squadre composte da chi aveva la tendenza ad agire da solo. Le simulazioni in realtà possono essere progettate per incoraggiare o scoraggiare le interazioni tra i componenti di una squadra; se i risultati sono semplici e consolidati, può essere favorita una leadership centrale che guida l’intero gruppo; se al contrario gli output sono complessi e richiedono un notevole impiego del computer, allora ciò può far prendere al computer il ruolo di leader; o ancora se la simulazione riguarda più prodotti e il risultato prevede di risolvere questioni che rispecchiano decisioni orientate al prodotto, il gioco può incoraggiare un’interazione volta alla gestione della marca (Teach, 1990).

Il disegno dei risultati della simulazione inoltre può determinare la struttura organizzativa e quella delle interazioni. Le simulazioni con forti bilanci ad esempio tendono ad incoraggiare le persone che hanno un background finanziario o contabile a diventare dei leader; i giochi che forniscono dettagli sul processo produttivo invece incoraggiano gli studenti provenienti da quell’area funzionale. Affermazioni analoghe possono quindi essere fatte per qualsiasi altra area di gestione in cui gli studenti tendono a concentrare i loro studi; ciò non significa che le simulazioni debbano evitare questo tipo di inclinazioni, ma che i progettisti o i docenti, dovrebbero essere in grado di riconoscere l’implicazione del design del gioco sulle interazioni all’interno della squadra.

Per quanto riguarda le relazioni tra i vari team, Teach (1990) afferma che esse differiscono a seconda dell’uso di simulazioni in cui le imprese sono indipendenti o dipendenti tra loro e a seconda dei metodi

159 per valutare i membri della squadra e le loro prestazioni. Nel caso di una dipendenza tra le squadre, la concorrenza limiterebbe le interazioni; i giocatori vedrebbero le loro strategie aziendali come fondamento dei profitti dell’impresa e per questo sentirebbero il bisogno di tenerle completamente segrete. In queste simulazioni, potrebbe comunque verificarsi anche una qualche forma di cooperazione o collusione, se ad esempio la simulazione è altamente elastica nella sua funzione di marketing a livello di impresa, ma altamente anelastica a livello di settore, la collusione potrebbe essere redditizia.

Le simulazioni possono poi essere progettate per richiedere una grande quantità di sostegno dall’amministratore del gioco, sia esso un progettista o un docente; i modelli possono infatti includere una clausola per fornire comunicati stampa o bollettini da rendere noti a tutte le squadre o in alcuni casi messaggi speciali da inviare a squadre selezionate. Le interazioni in questi casi sono talvolta necessarie, ma va prestata attenzione a non sovraccaricare l’amministratore del gioco.

La maggior parte delle interazioni che avvengono tra i membri del team e la simulazione si sono invece limitate principalmente a due aspetti: l’interfaccia software e l’interfaccia strutturale del gioco. L’interfaccia software sembra la più facile da spiegare, in quanto la maggior parte dei BG utilizza dispositivi di input e di output solo come mezzo per registrare la decisione di un team e per visualizzarne i risultati. Due sono i metodi principali di ingresso nella registrazione delle scelte: originariamente, tutte le decisioni venivano scritte su carta e poi digitate da un assistente, mentre di recente programmi computerizzati sono stati sviluppati per sostituire quei moduli cartacei.

In particolar modo per le simulazioni che forniscono software per la registrazione delle decisioni, il design è molto importante. Scritti in linguaggi più semplici, questi programmi includono spesso una sequenza di domande e se si commette un errore questo viene immediatamente riconosciuto. Proprio perché il design e il layout dello schermo sono importanti, alcuni programmi sono progettati per ri- visualizzare le risposte e fornire ai partecipanti una maggiore opportunità di controllo delle scelte prima di salvare i file di dati, così come la possibilità di visualizzare le decisioni del periodo precedente.

I display in grado di dimostrare tutti i nomi delle imprese, dei giocatori e delle decisioni obbligatorie potrebbero migliorare l’interfaccia tra il partecipante e il gioco e di conseguenza contribuire in qualche modo all’apprendimento. Sezioni specifiche potrebbero ad esempio essere progettate per inoltrare domande dopo che una decisione è stata inserita, oppure il programma stesso potrebbe inviare domande ai partecipanti sulle decisioni prese o informarli di futuri cambiamenti di mercato che potrebbero influire sulle scelte del periodo. Allo stesso modo interfacce “intelligenti” potrebbero essere progettate per arrestare le decisioni talmente sbagliate che potrebbero compromettere l’esclusione di una squadra, oppure incoraggiare i giocatori a sviluppare delle regole per la sequenza di decisioni.

Questi aspetti sembrano tuttavia meno rilevanti rispetto a ciò che riguarda le questioni sulla struttura della simulazioni, dato che alcuni problemi si potrebbero verificare quando la struttura, la natura della competizione o gli obiettivi della simulazione non sono chiaramente compresi dai giocatori. Talvolta possono sussistere performance non di successo, non tanto a causa delle decisioni prese, quanto piuttosto per colpa di fraintendimenti della stessa simulazione (Teach, 1990).

160