Richieste
Le decisioni dentro l'automazione
Le richieste sono il cuore di Nexus: ogni decisione che un processo automatico non può prendere diventa un lavoro con un numero, una coda, un assegnatario, una scadenza e una storia. Il tipo di richiesta lo definite voi dal portale, senza sviluppo.
Il problema
Un'automazione arriva al punto in cui serve un giudizio umano — questo ordine lo accettiamo?, a quale commessa appartiene questa fattura? — e lì si ferma. Se quel momento finisce in una email, succedono tre cose: nessuno sa quante ne sono in attesa, nessuno sa da quanto, e quando la decisione arriva bisogna ricordarsi di far ripartire il processo a mano.
Come funziona
L'operatore apre l'elenco e vede il lavoro che gli compete. Le colonne filtrano una per una, la ricerca cerca dentro tutte, e le operazioni di massa — assegna, sposta di coda, cambia priorità — stanno in cima per chi ha il permesso di usarle.

Aprendo una richiesta, a sinistra c'è il documento e a destra i campi da confermare. Il documento non viene scaricato: si legge dentro il portale, con l'archivio che lo tiene — un documentale aziendale, una cartella di rete o l'archivio nativo di Nexus.

Quando il documento non c'è, la maschera resta la stessa: gruppi di campi, aiuti sotto le voci, tabelle di righe dove servono. Tutto quello che si vede — etichette, ordine, obbligatorietà, condizioni di visibilità — arriva dalla definizione del caso, non da una pagina scritta a mano.


Prendere in carico è un gesto esplicito. Finché nessuno la prende, la richiesta resta in coda per tutti e i campi sono in sola lettura: la fascia gialla in cima lo dice. È il modo di evitare che due persone lavorino la stessa cosa — e di sapere, guardando l'elenco, che cosa è davvero in mano a qualcuno.
Lavorare una coda, non una richiesta per volta
Chi passa la mattina sulle richieste non ne apre una: ne apre trenta. Quattro cose sono fatte per quel ritmo.
La bozza si salva da sola. Si smette di scrivere e dopo quattro secondi quello che c'è nei campi è al sicuro: sotto i pulsanti compare Bozza salvata da sola alle 15:42. Il pulsante Salva bozza resta per chi vuole la conferma subito. Una bozza identica a quella già salvata non viene riscritta, così la storia della richiesta non si riempie di righe che non dicono niente.
Chiusa una, si apre la successiva. Dato un esito, il portale apre la richiesta che veniva dopo nell'elenco invece di tornare al «scegline una». Succede solo nella scheda Da fare: sulle altre non si sta lavorando una coda, si sta guardando lo storico.
Le mani restano sulla tastiera. J e K (o le frecce) passano alla richiesta successiva e precedente, Ctrl+S salva la bozza, ? apre il promemoria dei tasti. Mentre si scrive in un campo i tasti tornano a essere lettere. Gli esiti non hanno scorciatoia, ed è una scelta: chiudere una richiesta non si annulla, e un tasto premuto per sbaglio non deve poter chiudere una decisione.
E si può passare ad altri. Sotto l'intestazione di una richiesta presa in carico ci sono due gesti:
- Rimetti in coda la restituisce a tutti, e quello che era stato compilato resta: chi la riprende trova il lavoro fatto.
- Delega a... la passa a un collega scelto dalla tendina, con lo stato e la bozza come stavano. La differenza è che la richiesta si ricorda chi l'ha mandata: sulla scheda di chi la riceve compare Questa richiesta ti è stata delegata e un pulsante Restituisci. E se il collega la gira a un terzo, il Restituisci del terzo torna comunque al primo: la catena tiene il capo, non il penultimo anello.
Le code, le assenze, l'instradamento
Una coda è un gruppo di lavoro. Le richieste ci arrivano per regola — sopra i 50.000 € va alla direzione, le fatture del reparto acquisti alla contabilità fornitori — e chi è assente non le riceve.



Le scadenze contano solo le ore lavorative
Il calendario dell'azienda dice quali sono i giorni lavorativi, l'orario e le festività. Una richiesta aperta venerdì alle 18 con quattro ore di tempo scade lunedì mattina, non sabato all'alba.

Se la scadenza si avvicina e nessuno risponde, l'escalation fa quello che il caso dichiara: avvisa, riassegna, cambia coda o chiude. Le notifiche arrivano dalla campanella e per email, con i testi che si personalizzano per tipo e per lingua.

Un tipo di richiesta nuovo si configura, non si sviluppa
Non esiste una pagina, una tabella o una classe per ogni caso: esiste un caso descritto, e il portale lo costruisce. Campi, tendine che leggono dal gestionale, regole di avviso, esiti, instradamento, scadenze, traduzioni.

Le tendine leggono dal gestionale e cercano davvero: se l'anagrafica ha migliaia di righe, il campo interroga l'ERP mentre si scrive invece di filtrare i primi cinquanta valori che si è portato dietro — e quando un elenco è stato tagliato lo dichiara sotto, «l'elenco mostra solo i primi risultati: scrivi per restringerlo». Dentro le tabelle di righe una tendina può dipendere da un campo di sopra: cambiando lo stabilimento, la colonna delle commesse si ricarica invece di restare su valori che non valgono più.
Una richiesta può anche portare il riferimento a un documento dell'archivio — con il nome e da quale archivio viene — e riquadri di sola lettura con i dati che il flusso ha consegnato: servono a dare contesto alla decisione senza che nessuno debba aprire un'altra finestra.
Il percorso guidato ha otto passi — identità, campi, esiti, tendine, disposizione, traduzioni, comportamento, pubblicazione — e si riapre su una definizione già pubblicata con tutto compilato. Chi preferisce partire dalle parole lo può fare: nel primo passo si descrive il controllo che serve e si allegano i documenti che lo accompagnano — la procedura interna, una fattura d'esempio — e il portale compone la definizione intera. Poi l'anteprima legge davvero il documento allegato e mostra quali valori avrebbe estratto: è il modo di scoprire il caso d'uso valido che legge le cose sbagliate prima che lo faccia su un documento vero. Gli allegati servono a comporre la proposta e non vengono conservati.
Perché le versioni sono immutabili. Una richiesta viene fissata alla versione con cui è nata. Se domani si aggiunge un campo obbligatorio, le duecento richieste già in coda non diventano di colpo incomplete: continuano con le regole di ieri, e le nuove nascono con quelle di oggi. È la differenza fra un sistema che si può far evolvere e uno che si ha paura di toccare.
Fermare un caso d'uso, o tornare alla versione di prima
Due gesti del supervisore, sull'elenco dei casi d'uso. Metti a riposo ferma un caso d'uso: da quel momento il flusso non crea più richieste nuove — e chi ci prova riceve un errore che lo dice — mentre quelle già aperte restano lavorabili fino in fondo. Prima l'unico modo era spegnere la coda, che però fermava anche tutti gli altri casi d'uso che la usavano.
Torna alla versione rimette in servizio una versione precedente, scegliendola dalla tendina. Serve quando è proprio la versione nuova a essere il problema: prima si riapriva il designer e si rimetteva a mano quello che c'era, cioè si ricostruiva a memoria un documento che il sistema aveva già. Le richieste aperte non cambiano: ognuna resta sulla versione con cui è nata. E se nel frattempo le regole sono cambiate e quella versione oggi non sarebbe pubblicabile, Nexus non la rimette in servizio e dice quale regola non rispetta.
Quando a sbagliare è l'integrazione
Un sistema a monte si inceppa e genera venti richieste uguali. Nella griglia del supervisore, accanto ad Assegna a, Sposta in coda e Imposta priorità, c'è Annulla le richieste: il motivo resta obbligatorio — chi le ritrova fra un mese deve sapere perché sono state chiuse — ma si scrive una volta sola per tutto il lotto. La finestra dichiara prima quante ne verranno chiuse davvero: quelle che nel frattempo un collega o il flusso hanno già chiuso vengono saltate, e il numero lo dice prima di premere.
Le richieste chiuse non restano per sempre
Dopo sei mesi dalla chiusura una richiesta viene archiviata: esce dalle schede Completate e Annullate di chi lavora e resta consultabile nella griglia del supervisore. Non si perde niente — è l'elenco di chi lavora che torna a contenere solo lavoro.
Quel numero si cambia, e si può accendere anche la cancellazione degli archiviati dopo un periodo più lungo: nasce spenta, e resta spenta finché qualcuno non scrive un numero di giorni. Cancellare è irreversibile e ogni azienda ha i propri obblighi di conservazione, quindi non è una decisione che prende il prodotto al posto vostro. Quando è accesa porta via la richiesta con la sua storia, i commenti e gli allegati, ma non tocca i file nel documentale: la richiesta ne conteneva il riferimento, e togliere un documento dall'archivio aziendale non è una decisione da pulizia automatica.
Che cosa se ne ricava
- Il lavoro umano dentro i processi diventa misurabile: quante richieste, quanto tempo, quante tornano indietro.
- Le decisioni restano tracciate: chi, quando, con quali valori, attraverso quale canale — portale, email o telefono.
- L'automazione riparte da sola, senza che qualcuno debba ricordarsene.
- I casi facili possono chiudersi da soli: prima in prova, con la misura dell'accordo fra previsione e decisione umana, e solo dopo davvero.
I limiti dichiarati
- Le preferenze degli elenchi (larghezza delle colonne, colonne nascoste) non sopravvivono al ricaricamento della pagina: i filtri sì.
- La scheda azionabile dentro Teams e Outlook non c'è ancora: oggi si decide dal portale, dal telefono o dall'email con un clic.
- Le operazioni di massa restano al computer: dal telefono si lavora una richiesta per volta.