 |
Sagra di Cimpello
Pro Loco Cimpello 1998 |
Introduzione
Il sistema informativo sarà essenzialmente composto da tre entità; ogni
entità viene qui descritta brevemente, lasciando la descrizione delle
specifiche operazioni che ogni entità deve svolgere ai punti successivi.
- Cassa
- in cassa vengono raccolti gli ordini; occorre stampare una ``ricevuta''
che deve essere consegnata al cliente
- Cameriere
- le cameriere raccolgono gli ordini ai tavoli, raccolgono le ordinazioni
per le bevande (non presenti nell'ordine se non generalmente a categorie di
prezzo) e poi ``abilitano'' l'ordine assegnandogli un timestamp di
abilitazione, un tavolo (se piú tavoli basta metterne uno) e il proprio nome
(o identificativo); deve essere possibile ``saltare'' questo livello per gli
ordini da asporto.
- Cucina
- in cucina gli ordini si accumulano, e vengono scelti uno alla volta dai
``vassoisti'' (gli addetti alla preparazione dei vassoi) presenti; scelto un
ordine questo viene nuovamente stampato (ma con le informazioni dei
timestamps, del tavolo e delle cameriere in aggiunta)
- Amministrazione/Report
- tutta una serie di tool per la gestione del sistema, e per
l'estrapolazione di dati (statistici e non) a fine giornata.
Si può notare che da subito si è scelto di lasciare completamente fuori
dal sistema il BAR; questo è voluto, un bar è una realtà troppo dinamica, un
sistema del genere potrebbe essere una vera e propria palla al piede.
Questo non è tanto vero se il BAR è organizzato con una sezione ``staccata'' a
cui hanno accesso solo le cameriere, e in cui solo loro possono prelevare i
vassoi con le bevande per il servizio ai tavoli; a Cimpello si sta pensando a
una organizzazione del genere, e questa funzionalità è stata inserita nella
TODO list, per i prossimi anni.
Ai fini pratici non si tratta altro che di una semplice duplicazione delle
funzionalità dell'entità ``cucina'' in un contesto diverso.
È da notare anche che gli ordini piccoli (bevande, patate, panini, ...)
saranno comunque venduti a parte e singolarmente attraverso dei blocchetti di
``buoni'' numerati; questo permette di evitare di stampare degli ordini con
una voce, e d'altro canto non compromette il sistema perchè, contati quanti
biglietti sono stati strappati in quella serata dal blocchetto, si può
inserire un ordine ``fasullo'' a fine serata con tutte queste quantità per
avere i conti consistenti.
Inoltre è da notare subito che non ha quasi senso parlare di ``frequenze''
delle operazioni, visto che le operazioni sono du due tipi: quelle ``quasi
statiche'', ovvero che vengono fatte a inizio sagra e basta (come inserire i
nomi del personale e delle portate) e quelle che invece lavorano a livello
di ``ordine'' e che devono essere compiute su ogni ordine.
Note tecniche
Si sono decise le seguenti cose per quanto riguarda l'hardware e il sistema
utilizzato:
- tutto il sistema verrà basato sul DBMS MySQL ad interfaccia web,
attraverso una serie di script php e programmini C
- il server sarà una macchina low-level (486 o pentium 75) con Linux
(Debian 1.3.1r6), MySQL, PHP e Apache
- esisterà un altro computer connesso via Ethernet al server per la zona
cucine, molto probabilmente un 386sx
- i client dovrebbero essere tutto hardware di recupero connesso con
un semplice programma di emulazione terminale via seriale e il web
browser lynx; se si trovasse hardware piú buono non è escluso l'uso di
software classico di navigazione usando PPP via interfaccia
seriale;
i client sono 4 (due in cassa, uno per le cameriere, uno per le
cucine), connessi alle 4 seriali dei 2 computer in rete
- occorrono 2 stampanti; per la cassa per questioni di velocità si
opterà di sicuro verso moduli prestampati, per la cucina si vedrà...
- per il server principale ci sarà un gruppo di continuità, spero di
procurarmi per quel tempo un disco di backup per ogni evenienza...
- si è optato per la politica del ``second source''; alla sagra spesso
ci sono sovraccarichi e quindi ``salta'' la corrente: si chiederà
quindi a una delle case vicine una linea di corrente con cui
alimentare solo i computer (tutti)
- comunque verrà mantenuto in vita, come backup, il vecchio metodo
manuale (nei 6 giorni di sagra un temporale con mancanza totale della
corrente capita sempre almeno una volta... ;)
La cassa deve svolgere le seguenti funzioni:
- inserire un ordine che viene immediatamente stampato
- cancellare un ordine (non abilitato da una cameriera) che viene
immediatamente stampato, è cura del cassiere farsi dare la copia
cartacea dell'ordine cancellato e provvedere alla sua distruzione.
Considerando un ordine come un documento stle ``bolla'', si è preferito non
implementare la modifica, ma utilizzare cancellazione+reinserimento.
Questo ha permesso di semplificare l'interfaccia e di velocizzare la gestione
(gli ordini sbagliati possono essere messi da parte e cancellati assieme alla
fine o appena c'è tempo).
Inoltre, per una migiore gestione e interazione con i clienti, deve avere
queste caratteristiche aggiuntive:
- deve poter definire un ordine come ``da asporto''; questo
ordine salta la fase di abilitazione da parte delle cameriere e viene
passato direttamente in cucina
- deve visualizzare in tempo reale o quasi i tempi di attesa medi e
massimi riscontrati funo a quel momento, di modo che possano essere
comunicati ai clienti
- deve prevedere un meccanismo di ``conferma doppia'' di un ordine,
tramite una schermata di conferma con tutti i dati riassunti prima
dell'inserimento vero e proprio e quindi della stampa
- deve essere il piú semplice possibile (possibilmente usare solo i
tasti direzionali, invio e tastierino numerico)
- deve associare all'ordine inserito l'identificatore del cassiere che
lo ha inserito
- il numero d'ordine deve poter essere azzerato, non deve per forza
essere un progressivo per tutta la durata della manifestazione.
Chiaramente non è possibile cancellare e/o modificare un ordine che è
già stato abilitato (e quindi raccolto) da una cameriera; visto che l'ordine è
in mano o alla cameriera o al cassiere che lo sta correggendo non ci sono
possibilità di conflitto in questa operazione.
Inoltre l'utilità della presenza dell'ordine da asporto si sta rivelando
dubbia... nel senso che il cliente non dichiara al cassiere la richiesta di
asporto, ma alle cameriere (che a questo punto possono trattarlo come un
normalissimo ordine).
Le cameriere ritirano l'ordine ai tavoli1,
prendono le ordinazioni delle bevande (che sull'ordine sono indicate solo
come categorie di prezzo) e segnano il numero di tavolo; a questo punto si
dirigono al terminale dove inseriscono l'identificativo dell'ordine che hanno
appena raccolto, controllano che sia esatto, ci associano il loro nome o
idetificativo e un numero di tavolo, e poi passano a far altro.
Schematicamente questa applicazione deve svolgere le funzioni:
- possibilità di inserire l'identificativo di un ordine, e ottenere una
schermata in cui è presente l'ordine
- possibilità di selezionare il proprio nome/identificativo dalla lista
delle cameriere
- possibilità di inserire un valore in un campo numerico.
Anche qui sono richieste le caratteristiche aggiuntive:
- deve visualizzare in tempo reale o quasi i tempi di attesa medi e
massimi riscontrati funo a quel momento, di modo che possano essere
comunicati ai clienti
- deve essere il piú semplice possibile (possibilmente usare solo i
tasti direzionali, invio e tastierino numerico).
Con l'inserimento ``al buio'' del codice identificativo dell'ordine, e con la
schermata di conferma successiva, si evitano errori di ``scelta'' dell'ordine
con una minima perdita di tempo.
In cucina gli addetti alla preparazione dei vassoi scelgono sul monitor un
ordine, lo visualizzano e lo stampano; una volta stampato, il vassoista
raccoglie le pietanze che occorrono all'ordine, prepara il vassoio, ci
appoggia sopra la stampa e avvisa la cameriera competente dell'avvenuto
completamento dell'operazione.
In breve l'applicazione deve fornire:
- la possibilità di presentare sinteticamente a schermo gli ordini
abilitati e non evasi, in ordine di priorità (per primi quelli che
aspettano da piú tempo); il cursore è di default sull'ordine con
maggiore priorità, ma all'occorrenza può essere spostato
- la possibilità di visualizzare un ordine prima di stamparlo; questo è
utile perchè può accadere che la mancanza di una pietanza blocchi la
realizzazione di molti vassoi ma non di tutti, e il vassoista deve
essere in grado di scegliere un ordine che può portare a compimento
- la possibilità di stampare un ordine; una volta stampato l'ordine
sparisce dallo schermo e si considera evaso; nella stampa, oltre
all'ordine, devono trovare posto informazioni aggiuntive come i
timestamps (di cassa, cameriera e cucina), il tempo (cameriera - cucina
+ un forfait per il resto calcolato spannometricamente), il tavolo, i
nomi/codici degli addetti che hanno trattato l'ordine (sicuramente
cameriera, opzionalmente gli altri).
Anche qui sono richieste una serie di funzionalità aggiuntive:
- deve visualizzare in tempo reale o quasi le quantità richieste delle
principali portate (quelle critiche come le carni), informazioni che
non servono ai vassoisti ma alla cucina vera e propria; queste
quantità vanno incrementate ad ogni ordine in cassa e decrementate ad
ogni stampa dei vassoisti
- deve essere il piú semplice possibile (possibilmente usare solo i
tasti direzionali, invio)
- anche qui deve essere presente la possibilità di associare all'ordine
l'identificativo del vassoista che lo ha appena evaso.
Non sono previsti meccanismi di recupero in caso di errore; in caso
di ordine stampato ma che non può essere evaso immediatamente si è convenuto
di mantenere il vecchio sistema dello spago e delle mollette2.
Occorrerà definire tutta una serie di tool per gestire l'immissione dei dati
``quasi statici'' come i nomi del personale e delle pietanze, cosí come
procedure di backup dei dati e generatori di report/statistiche.
Mi è stata espressamente chiesta solo la realizzazione della stampa, a fine
giornata, dell'incasso derivante dagli ordini (in pratica la somma
dell'importo e della quantità di tutti gli ordini, per categoria, e somma
totale).
Questo è utile non solo per sapere quanto si è ricavato a fine serata, ma
soprattutto per sapere quante porzioni sono andate vendute.
Glossario
Tendendo ad usare diversi termini per dire le stesse cose, faccio un po' di
chiarezza.
- cassa
- in cassa gli ordini vengono creati, modificati, cancellati;
- cameriere
- la ``zona cameriere'' (solitamente oltre il bancone cucina) è il luogo
dove avviene l'interazione tra la cucina stessa e le cameriere che
raccolgono gli ordini e servono i clienti;
- cucina
- o ``zona vassoiste'' è praticamente la parte più esterna della
cucina dove vengono ``costruiti'' i vassoi; solitamente consiste di un
bancone a cui possono accedere sia i vassoisti che le cameriere;
- ordine
- in generale, senza specificazioni è inteso l'ordine appena inserito da
una cassa, ed è composto dalla quantità delle singole pietanze, un numero
d'ordine ed eventuali altre informazioni
- ordine abilitato
- è un ordine che è stato raccolto da una cameriera e quindi può essere
passato in cucina, visto che c'è un cliente che aspetta al tavolo
- ordine evaso
- è un ordine che è stato stampato da un vassoista e quindi è in corso di
evasione; si presume che un vassoista impegni un tempo pressoché costante
nella realizzazione di un ordine;
- ordine da asporto
- è un ordine che non deve passare per le cameriere; un ordine da asporto
va evaso direttamente in cucina, dove le pietanze vengono poste in sacchetti
e passate direttamente (o quasi) al cliente; gli ordini da asporto sono
praticamente solo una decina a serata, e vengono accettati prestissimo
(solitamente sempre prima delle 20:00) quindi non sono un ``caso''
statistico e non disturbano il normale flusso degli ordini.
- vassoio
- chiamato così perché fisicamente gli ordini vengono portati ai clienti
in enormi vassoi, che contengono i singoli piatti;
- pietanza
- o portata, o piatto; è quello che poi il cliente va
fisicamente a fruire, sperando che sia buono (senza immergersi nell'eterna
diatriba tra chi preferisce la costa ben cotta e chi al sangue... ;)
- tavolo
- (numero di) individua il numero del tavolo (o uni dei tavoli) in
cui è stato raccolto l'ordine, e serve per individuare poi a chi portare il
vassoio; nonostante sia preferibile che una sola cameriera segua la
vita di un ordine, è anche probabile che questo non sia possibile sempre e
questa è l'informazione minima per indirizzare il vassoio al giusto cliente.
Note
1 |
Questo è un punto controverso, e credo che la decisione verrà presa
all'ultimo momento in base alla disponibilità di stampanti, carta prestampata,
sponsor per quest'ultima... Sarebbe bello lasciare al cliente una ``ricevuta''
della consumazione su un supporto diverso dalla cartaccia usata per stampare
in cucina; d'altronde sarebbe bello che anche le cameriere avessero un
resoconto degli ordini raccolti, mi sa che alla fine si opterà per un
biglietto diviso in sezioni staccabili. Vedremo. |
2 |
L'ingegno della gente! Praticamente l'anno scorso è stata usata una coda FIFO
degli ordini realizzata con delle mollette da biancheria e uno spago su cui le
cameriere appendevano gli ordini che avevano raccolto, e da cui i vassoisti
prelevavano gli ordini, facendo man mano ruotare lo spago (per evitare che le
cameriere appendessero in testa invece che in coda, le imbroglione!). Questo
semplice accorgimento ha permesso di abbattere del 25% i tempi medi di
attesa... |
Prosegui alla Progettazione Concettuale