Catalogo

Come arriva un processo pronto

Un cliente non compra una piattaforma da riempire: compra un processo che funziona. Per questo esiste un catalogo — processi già costruiti, strumenti dell'assistente, specialisti pronti — e un modo unico di consegnarli, con il registro di chi ha cosa e in quale versione.

Il problema

Ogni progetto che comincia da un foglio bianco richiede settimane prima che il cliente veda qualcosa. E ogni cosa costruita per un cliente, se resta dentro quel cliente, va ricostruita per il successivo — con le stesse trappole e gli stessi tempi.

Come funziona

Tre cataloghi in un posto solo: pacchetti (un processo intero), strumenti (i gesti che l'assistente sa fare) e specialisti. I pacchetti si leggono per famiglia — a cosa servono, non che cosa contengono.

Il catalogo dell'host: ogni voce dichiara la versione, se è di serie, per quale gestionale è scritta e quante aziende ce l'hanno. La schermata è di una passata precedente e mostra meno voci di oggi: i numeri validi sono quelli scritti qui sotto.

In cima si cerca per nome, codice o descrizione e si filtra per gestionale, con una pastiglia per ERP e una per le voci neutre. La ricerca vale sui tre cataloghi insieme: il contatore sulle linguette dice dove sta quello che si sta cercando — cercando il nome di uno strumento mentre si guardano i pacchetti, è il contatore degli strumenti ad accendersi.

Le famiglie sono tre, e dicono che tipo di lavoro tolgono:

i processi (nove) prendono un lavoro che oggi qualcuno fa a mano e lo portano dentro il sistema: l'ordine che arriva per email, lo sblocco degli ordini fermi per fido, il riordino proposto, il sollecito pagamenti, la conferma d'ordine al cliente, il sollecito arrivi al fornitore, l'inventario rotativo di reparto, la checklist di chiusura del mese, la richiesta d'ordine dettata all'assistente;
le sorveglianze (diciotto) guardano di notte quello che nessuno guarda: la data in cui un articolo finisce, la promessa a rischio, lo spedito non fatturato, il margine eroso, il fornitore che scivola, il cliente che si sta perdendo, le anagrafiche da sistemare, i preventivi che si raffreddano;
le previsioni (cinque) portano i numeri che non sono ancora successi: vendite, domanda, incassi, acquisti, carico di lavoro.

Scegliendo una voce si vede chi ce l'ha: per ogni azienda lo stato, la versione rilasciata, l'etichetta aggiornamento disponibile quando il catalogo è andato avanti, e l'esito dell'ultima operazione.

Un pacchetto e le aziende che lo hanno ricevuto. Le aziende che non ce l'hanno compaiono lo stesso: un elenco che mostra solo chi funziona nasconde proprio i casi da sistemare.

Si installa fermo, si avvia quando si è pronti

Un pacchetto non è uno strumento a disposizione di chi lo chiama: lavora da solo. Order-to-Cash porta un flusso che parte ogni mattina alle otto — installarlo di pomeriggio significherebbe trovarselo al lavoro il mattino dopo, prima che qualcuno abbia creato le credenziali che gli servono.

Quindi i tempi sono due:

Installa porta dentro tutto il contenuto — tipi di richiesta, code, flussi — ma spento, e non tocca il motore dei flussi esterni. È il momento in cui si preparano i prerequisiti: credenziali, caselle di posta, parametri del gestionale.
Avvia accende, e solo allora rilascia i workflow sull'istanza del cliente.

Che cosa succede quando si disinstalla. Il pacchetto se ne va, ma ciò che è già stato usato non viene cancellato: un tipo di richiesta con richieste aperte, un flusso con esecuzioni, uno specialista con conversazioni restano — spenti — e il report lo dice riga per riga. Cancellare quelle cose vorrebbe dire cancellare il lavoro delle persone, che non appartiene al pacchetto.

Ogni voce dichiara per quale gestionale è scritta

Tutto quello che il catalogo contiene oggi è scritto per Infor SyteLine: su un gestionale diverso quegli strumenti non sono «meno utili», non funzionano. Perciò ogni voce dichiara i gestionali su cui vale, ogni azienda dichiara il proprio, e un rilascio incompatibile viene rifiutato.

I gestionali conosciuti dall'host: l'elenco si allunga quando se ne collega uno nuovo, senza aspettare un rilascio del prodotto.

Chi non dichiara niente è neutro e vale ovunque: la conoscenza documentale e le richieste umane non sanno che ERP c'è sotto.

Come nasce un pacchetto

I processi standard si costruiscono e si provano con dati veri su un'istanza di lavoro della piattaforma, poi si importano nel catalogo. Nell'importazione il flusso viene ripulito di tutto ciò che apparteneva all'ambiente di partenza, gli indirizzi e i nomi delle credenziali diventano segnaposto, e le credenziali richieste diventano righe di una checklist con il nome esatto che dovranno avere sul cliente.

L'istanza di autoria della piattaforma: da qui si importano i flussi che diventeranno pacchetti. Non è l'istanza di nessun cliente.

È il punto per cui l'importazione esiste: un flusso copiato tale e quale continuerebbe a chiamare l'ambiente di chi l'ha scritto senza dare errore.

Che cosa se ne ricava

Il primo giorno del cliente comincia da un processo che gira, non da un designer vuoto.
Quando un processo migliora, l'aggiornamento arriva a tutti i clienti che lo hanno — senza toccare le loro personalizzazioni: dal momento in cui una voce viene modificata su un cliente, resta come l'hanno lasciata.
Chi assiste sa in ogni momento chi ha cosa, e in quale versione.

I limiti dichiarati

Il documento di un pacchetto non si modifica dal portale: si importa e si pubblica.
Reimportare dentro un pacchetto esistente per aggiornarlo non si fa ancora: l'importazione crea sempre una voce nuova.
Oggi si importano i workflow del motore esterno; i tipi di richiesta e i flussi nativi entrano a catalogo con il rilascio del prodotto.
Quasi tutto il catalogo è scritto per Infor SyteLine, perché la scrittura passa dalle sue interfacce: su un altro gestionale restano le voci neutre e i pacchetti da riscrivere nel solo passo che scrive.
I cruscotti composti dall'amministratore non si consegnano ancora dal catalogo: si esportano e si importano a mano.