Indice

Introduzione

Chi lavora in una tipografia digitale medio-grande conosce bene un paradosso che si ripete in quasi tutte le aziende del settore. Puoi avere le migliori macchine da stampa del mercato, un RIP performante, operatori esperti, ma se il flusso di prestampa è manuale, il collo di bottiglia reale non è mai la produzione. È lo smistamento dei file che arrivano da clienti, e-commerce, portali B2B e posta elettronica. Finché quel lavoro dipende dalle mani di una persona, scalare diventa impossibile: ogni nuovo ordine aggiunge attrito, ogni errore umano costa materiale e tempo, ogni picco di stagione diventa un'emergenza.

Enfocus Switch nasce per risolvere questo problema. Non è un software di prestampa nel senso classico, è un orchestratore di flussi: un motore che riceve input, li interpreta, applica regole, li processa con strumenti di terze parti e li consegna alla fase successiva. Questo articolo spiega come usarlo davvero in produzione, quali scelte progettuali fanno la differenza, e come impostare un piano di adozione che non esploda al primo flusso complesso.

Cos'è Switch e perché non è "solo automazione"

Definire Switch come "un software di automazione" è tecnicamente corretto ma operativamente fuorviante. Un automatismo fa una cosa sempre nello stesso modo, Switch fa invece qualcosa di più: applica decisioni sui file in base a regole, metadati, condizioni e stato del sistema. La differenza si vede subito quando si inizia a costruire un flusso reale. Non stai scrivendo una macro che rinomina PDF, stai progettando un sistema che decide autonomamente cosa fare di ogni file che entra, in funzione di dove arriva, da chi, cosa contiene e cosa prevede l'ordine associato.

Il cuore di Switch è un canvas visuale dove si disegnano i flussi come grafi orientati: ogni nodo è un'azione (ricezione, preflight, rinomina, spostamento, elaborazione, invio), ogni freccia è una condizione di passaggio. Il grafo può diramarsi, unirsi, mettere in coda, aspettare eventi esterni, chiamare API, eseguire script. È una programmazione visuale, ma con la profondità di un vero linguaggio di flusso.

Il consiglio operativo fondamentale è di smettere di pensare a Switch come "lo strumento che fa X" e iniziare a vederlo come "il livello di orchestrazione che decide cosa fa cosa". Prima di disegnare qualunque flusso, mappa su carta (o su una lavagna bianca) i passaggi reali che un operatore fa oggi su un tipico file cliente. Ogni passaggio diventa potenzialmente un nodo. Ogni decisione dell'operatore ("questo è un PVC, lo mando in coda 3") diventa una regola. Da quella mappa nasce il flusso Switch vero, non dai tutorial generici.

Quando Switch conviene davvero (e quando no)

Switch non è per tutti. È uno strumento potente, con una licenza annuale non banale e una curva di apprendimento non leggera. Vale la pena fare un ragionamento onesto su quando l'investimento si ripaga davvero.

Conviene in tre casi principali. Il primo è quando i volumi di ordini superano la capacità di uno o due operatori di prestampa di gestirli manualmente senza errori ricorrenti. Qui la soglia indicativa, per una tipografia grande formato, si colloca tra i 500 e i 1000 ordini al mese, ma il numero dipende molto dalla complessità dei lavori. Il secondo caso è quando i canali di ingresso dei file sono multipli e disomogenei: e-commerce, email, portali B2B, hot folder, FTP. In questa situazione la parte pesante del lavoro umano è già solo lo smistamento, e togliere quello libera molto tempo. Il terzo caso è quando l'azienda gestisce tipologie di prodotto molto diverse (carta, PVC, tessuto, rigido, sublimazione) e ognuna richiede regole di preflight e imposizione diverse: Switch permette di mantenere queste regole in un unico punto, senza che l'operatore le tenga a mente.

Dove invece non conviene. Se la tipografia fa pochi ordini al giorno, tutti molto simili tra loro, e il preflight è già gestito bene dentro il RIP, Switch diventa un overkill che porta più complessità che valore. Idem se l'azienda non ha ancora un MIS ((Management Information System) o un gestionale con cui integrarsi: Switch senza integrazioni MIS funziona, ma perde la maggior parte del suo valore reale.

 

Il consiglio pratico è di fare una stima molto concreta prima di acquistarlo. Conta quante ore al giorno i tuoi operatori di prestampa spendono in attività ripetibili (smistamento, rinomina, verifica manuale, inserimento code). Se sono meno di 6 ore cumulate al giorno, probabilmente un'automazione leggera basata su hot folder e PitStop Server standalone basta. Se sono più di 10-12 ore, Switch comincia ad avere molto senso. Nel mezzo, dipende dalla traiettoria di crescita: se i volumi stanno salendo velocemente, meglio investire prima che dopo.

Anatomia di un flusso tipo, passo per passo

Per capire cosa significhi concretamente "progettare un flusso in Switch", è utile vedere come si costruisce un caso reale. Prendiamo l'esempio di un flusso di ricezione ordini da e-commerce per stampa di banner in PVC.

Il primo nodo è il punto di ingresso. Nel nostro caso in PRiNKO usiamo una hot folder che viene popolata da uno script del sito e-commerce: ogni volta che un cliente completa un ordine con upload file, il sito deposita nella cartella un PDF e un file XML con i metadati (numero ordine, prodotto, dimensioni, materiale, finiture, quantità). Switch intercetta l'arrivo, legge l'XML, estrae i metadati e li attacca al PDF come "job ticket" interno.

Il secondo nodo è il preflight. Qui entra in gioco PitStop Server, che applica un profilo diverso in base al tipo di prodotto letto dall'XML. Un manifesto in carta ha regole diverse da un banner in PVC, e il profilo giusto si seleziona automaticamente. Se il PDF passa il preflight, prosegue nel flusso. Se fallisce, Switch genera un report di errore, lo allega a una mail predefinita al cliente con testo contestualizzato (lingua del cliente, nome, numero ordine, errore specifico) e ferma il job in una cartella di attesa.

Il terzo nodo è la rinomina e il routing. Il file viene rinominato secondo una convenzione che include numero ordine, materiale, dimensioni e data, così che in qualunque momento sia identificabile a colpo d'occhio anche senza aprire il gestionale. Da qui viene indirizzato alla coda di stampa corretta in base al tipo di macchina richiesta, che dipende dal materiale.

Il quarto nodo è l'imposizione, tipicamente affidata a un software dedicato come Artpro Pack, Packz o moduli di imposizione del RIP stesso. Switch lancia l'imposizione con il template corretto, aspetta l'output e lo passa al nodo successivo.

Il quinto nodo è la consegna alla coda del RIP, che può essere gestita via hot folder dedicata, API o integrazione nativa con il RIP (molti produttori offrono moduli Switch ufficiali). A questo punto il file è pronto per essere stampato.

Il sesto nodo, spesso trascurato, è la notifica e la chiusura del ciclo: Switch aggiorna lo stato dell'ordine nel gestionale via API o query SQL, genera il DDT in bozza e invia una notifica interna al reparto di finitura con i dettagli del lavoro.

Il consiglio pratico che dò a chi costruisce il primo flusso è di non tentare di fare tutto insieme. Parti da un solo tipo di prodotto (quello che hai in volume maggiore) e costruisci il flusso end-to-end per quel caso, anche semplificato. Solo quando funziona bene e lo usi in produzione reale per due o tre settimane, estendilo ad altri prodotti. Il pattern "vorrei automatizzare tutto subito" è il modo più sicuro per finire con un flusso che non gira mai davvero.

Integrazione con MIS, e-commerce e preflight

La potenza vera di Switch emerge nelle integrazioni. Un flusso isolato che sposta file è utile, ma limitato. Un flusso che parla con il MIS, l'e-commerce e il preflight diventa il centro nervoso della prestampa.

L'integrazione con il MIS ((Management Information System) è quella che porta il valore più grande e anche la complessità maggiore. Switch può leggere dati dal gestionale tramite query SQL dirette, chiamate API REST o import di file XML/CSV esportati periodicamente. La scelta dipende dall'architettura del MIS: se è aperto e documentato, le API sono la strada giusta, se è un sistema proprietario chiuso, spesso si finisce a lavorare con export periodici o con query su database di sola lettura. Il consiglio è di non sottovalutare questo passaggio: prima di iniziare a progettare il flusso Switch, verifica come il tuo MIS può parlare con il mondo esterno. Molti progetti si bloccano qui.

L'integrazione con l'e-commerce dipende dalla piattaforma. Se il sito è custom (come nel nostro caso), la via più semplice è che il sito scriva file su una hot folder monitorata da Switch, con un XML di accompagnamento. Se invece l'e-commerce è una piattaforma standard (Magento, WooCommerce, Shopify), si possono usare webhook o API. In entrambi i casi, la regola aurea è: l'e-commerce deve passare a Switch tutti i metadati dell'ordine già strutturati, non il solo PDF. Qualsiasi dato che Switch dovrà chiedere altrove è un punto di fragilità in più.

L'integrazione con PitStop Server o PitStop Pro è il cuore tecnico del preflight. Switch invoca PitStop passando il file e il profilo corretto, riceve il report, lo interpreta e decide cosa fare. Il consiglio pratico qui è di costruire un set di profili PitStop specifici per tipo di prodotto, con action list che vanno oltre il semplice "check": correggi automaticamente le cose sicure (conversione colore, embedding font, flattening trasparenze controllato), lascia bloccanti solo gli errori reali. Un preflight troppo severo genera code di errori che nessuno gestisce mai, un preflight permissivo lascia passare file problematici. Il punto di equilibrio va costruito con l'esperienza, un profilo alla volta.

Gli errori che ho fatto (e che puoi evitare)

Nei primi mesi di adozione di Switch ho commesso diversi errori che vale la pena condividere, perché si ripetono quasi identici in tutte le stamperie che lo introducono.

Il primo errore è stato voler automatizzare prima di aver documentato i flussi manuali. Switch non può automatizzare un processo che non esiste su carta. Se non sai esattamente cosa fa oggi il tuo operatore per gestire un file, non puoi replicarlo in un flusso. Il tempo speso a mappare i processi manuali (anche solo con post-it su una lavagna) si ripaga dieci volte nella fase di costruzione.

Il secondo errore è stato affidare la progettazione a chi non conosceva la produzione. Switch è un tool tecnico, ma i flussi devono essere progettati da chi sa cosa succede in sala stampa. Se a progettare è un consulente esterno senza conoscenza diretta del tuo ciclo produttivo, finisce a fare flussi "da manuale" che non reggono i casi limite reali. La scelta giusta è un lavoro a coppia: consulente tecnico Switch più persona interna che conosce la produzione. Due teste, un flusso.

Il terzo errore è stato sottovalutare la gestione degli errori. Un flusso Switch robusto dedica metà del suo disegno agli happy path, l'altra metà a cosa fare quando qualcosa va storto: file corrotti, timeout, risposte del MIS mancanti, stampanti offline, code piene. Nei primi flussi ho disegnato solo il percorso felice e ho pagato caro ogni volta che qualcosa di imprevisto arrivava al sistema. Regola pratica: per ogni nodo che può fallire, deve esistere un percorso di errore definito, con logging, notifica e dove possibile retry automatico.

Il quarto errore è stato non tenere versioning dei flussi. Switch permette di esportare i flussi come file. Ogni modifica importante va esportata e salvata con nota di cosa è cambiato e quando. Senza versioning, ti troverai un giorno a cercare di ricordare "perché avevo messo quel nodo qui" senza alcuna traccia. Un semplice repository Git o anche solo una cartella con file datati risolve il problema.

Il quinto errore è stato non formare un secondo operatore sui flussi. Se solo una persona in azienda sa leggere e modificare i flussi Switch, hai creato un single point of failure umano. Appena questa persona è in ferie o cambia lavoro, il sistema diventa una scatola nera. La formazione di un secondo riferimento va pianificata dal primo mese, non quando è troppo tardi.

Come impostare la roadmap di adozione

Una roadmap di adozione di Switch sensata, per una tipografia medio-grande che parte da zero, dura tra i 6 e i 12 mesi prima di arrivare a regime.

La fase 1 (mesi 1-2) è di analisi e documentazione. Mappa tutti i flussi manuali attuali, identifica il prodotto o il canale con il volume maggiore, definisci quale sarà il flusso pilota. In parallelo, verifica l'integrazione con MIS ed e-commerce: cosa è possibile tecnicamente oggi, cosa richiede sviluppo.

La fase 2 (mesi 3-4) è di installazione e primo flusso pilota. Installa Switch, configura PitStop, costruisci il flusso del prodotto pilota in ambiente di test, simulalo con file reali. Non attivarlo ancora in produzione.

La fase 3 (mesi 5-6) è il passaggio in produzione del primo flusso, con supervisione costante. I primi giorni qualcuno deve stare accanto al sistema per intercettare problemi che in test non erano emersi. Parallelamente si raccolgono i casi limite e si aggiornano i profili di preflight.

La fase 4 (mesi 7-9) è l'estensione ad altri prodotti o canali. Adesso che il primo flusso gira stabile, si replica il pattern su un secondo e un terzo caso d'uso, riutilizzando i componenti già costruiti (profili PitStop, template rinomina, hot folder).

La fase 5 (mesi 10-12) è di consolidamento e ottimizzazione. Si misurano i tempi risparmiati rispetto al baseline manuale, si affinano i flussi più critici, si documentano le procedure di manutenzione. A questo punto Switch è parte integrante della prestampa e non ci si torna indietro.

Il consiglio pratico è di non accorciare questa roadmap per fretta. Ogni fase bruciata si ritrova sotto forma di debito tecnico nei mesi successivi, e i flussi di prestampa sono il cuore produttivo: se saltano, salta la consegna ai clienti.

Conclusione

Enfocus Switch non è un acquisto, è un cambio di modello operativo. Non compri un software, introduci un livello di orchestrazione che cambia il modo in cui la prestampa lavora: da "operatori che smistano file" a "operatori che supervisionano un sistema che smista file". Il passaggio porta con sé complessità progettuale, curva di apprendimento e un investimento economico non leggero, ma restituisce in cambio qualcosa che per una tipografia in crescita ha un valore enorme, cioè la possibilità di scalare senza proporzionalmente aumentare il numero di operatori dedicati al lavoro ripetitivo.

Il passo da fare questa settimana, se stai valutando l'adozione, è molto concreto: prendi un foglio e mappa tutti i passaggi che il tuo operatore di prestampa fa oggi dal momento in cui il file del cliente arriva al momento in cui parte la stampa. Ogni riga è un potenziale nodo, ogni decisione è una potenziale regola. Quel foglio è la vera base del progetto Switch. Senza, qualunque demo o tutorial è tempo buttato.

Le domande più comuni

Quanto costa Enfocus Switch?

Switch è venduto con licenza annuale modulare. La configurazione base (Core Engine) parte da qualche migliaio di euro all'anno, a cui si aggiungono moduli opzionali (Configurator, Database, Metadata, Scripting, Client) che possono portare il totale a 8.000-15.000 euro annui per una tipografia di medie dimensioni. Il costo reale dipende da quali moduli servono davvero: è utile chiedere un preventivo calibrato sul tuo caso d'uso, non sul listino generico.

Qual è la differenza tra Enfocus Switch e PitStop Server?

PitStop Server è lo strumento di preflight e correzione dei PDF, Switch è l'orchestratore che decide quando e come chiamare PitStop (e altri strumenti) all'interno di un flusso. PitStop può girare da solo come servizio a hot folder, ma senza Switch non decide cosa fare del file dopo il preflight. I due lavorano insieme: Switch è il direttore d'orchestra, PitStop uno degli strumenti specializzati. Entrambi sono di Enfocus, integrati nativamente.

Quando conviene adottare Switch in una tipografia?

Conviene quando gli operatori di prestampa spendono più di 10-12 ore cumulate al giorno in attività ripetitive di smistamento, rinomina e verifica manuale dei file. Sotto quella soglia, un'automazione leggera con hot folder e PitStop standalone può bastare. Altri segnali che spingono verso Switch sono: canali di ingresso multipli (e-commerce, email, portali), molte tipologie di prodotto con regole diverse, necessità di integrare il MIS nel flusso.

Come si impara a usare Enfocus Switch?

Enfocus offre formazione ufficiale e un programma di certificazione. La via realistica è partire con un corso base di uno o due giorni, poi costruire il primo flusso semplice sotto la guida di un consulente certificato per le prime settimane. La curva di apprendimento è significativa: non è un tool "plug and play", è una piattaforma di sviluppo di flussi. Metti in conto almeno due o tre mesi prima di sentirti autonomo sui flussi non banali.

Switch funziona anche senza un gestionale MIS?

Sì, ma perde gran parte del suo valore. Senza MIS, Switch può comunque automatizzare ricezione file, preflight, rinomina, routing, imposizione, invio al RIP. Quello che manca è la capacità di arricchire i job con dati dell'ordine (cliente, prodotto, dimensioni, quantità) e di aggiornare lo stato nel gestionale. Il risultato è un'automazione di prestampa isolata dal resto del business. Funzionante, ma lontana dal pieno potenziale.

Quali sono i principali concorrenti di Enfocus Switch?

Sul mercato dell'orchestrazione prestampa i principali alternativi sono Kodak Prinergy (più orientato all'offset industriale), Heidelberg Prinect (storicamente legato alle macchine Heidelberg), Tilia Griffin (focalizzato su imposizione e workflow packaging) e soluzioni custom sviluppate con strumenti generici come n8n o scripting. Switch si distingue per la flessibilità del canvas visuale, l'Appstore di app pronte e l'ecosistema Enfocus (PitStop, Connect). La scelta dipende dal tuo mix di lavoro: offset, digitale, packaging.

Come si integrano le API nei flussi Switch?

Switch permette di chiamare API REST direttamente da un flusso tramite app dedicate dell'Appstore o tramite nodi di scripting (JavaScript, Python). Il pattern tipico è: un nodo riceve un file con metadati associati, uno script fa una chiamata al gestionale per arricchire i dati, il risultato guida il routing successivo. Questa capacità rende Switch un vero integratore di sistemi, non solo un automatore di prestampa. Richiede competenze di sviluppo, tipicamente di uno sviluppatore backend.