Prestazioni del Process Mining: benchmark e suggerimenti

Che cosa determina le prestazioni del Process Mining

Le prestazioni del Process Mining dipendono da tre fattori: dalla quantità di dati caricati, dal modo in cui vengono strutturati e dal modo in cui il sistema li elabora. Questa guida li esamina tutti, con benchmark reali e metodi concreti per migliorare i risultati.

Pubblichiamo tutti i nostri numeri. Li confronti con quelli di qualsiasi strumento di Process Mining sul mercato.

La pipeline dei dati: dove si concentra il tempo

Quando carica i dati in ProcessMind, accadono tre cose. Ecco esattamente dove viene impiegato il tempo:

1. Upload (incide sulla maggior parte del tempo totale). Il Suo file viaggia attraverso Internet fino alla nostra infrastruttura cloud. Per i file di grandi dimensioni, questo è il principale collo di bottiglia. La velocità fisica della rete fa la differenza: un CSV da 50 milioni di eventi (11 GB) richiede 2 minuti su una connessione gigabit, 18 minuti a 100 Mbps o più di 3 ore a 10 Mbps. Gli stessi dati in Parquet occupano appena 1,7 GB, riducendo i tempi rispettivamente a 19 secondi, 3 minuti e 28 minuti. Questo è il motivo principale per cui conviene utilizzare formati colonnari come Parquet o ORC, oppure dataset più piccoli.

2. Preprocessing (costo una tantum, da circa 30 secondi a 2,5 minuti). Una volta completato l’upload, trasformiamo i Suoi dati in uno storage colonnare ottimizzato: indicizziamo gli eventi, precalcoliamo le transizioni delle attività, identifichiamo le varianti di processo e calcoliamo le statistiche riepilogative. Questa operazione richiede 30 secondi per i dataset più piccoli e fino a 2,5 minuti per 100 milioni di eventi. Sostiene questo costo una sola volta per ogni upload e ne beneficia per tutte le elaborazioni successive.

3. Modifiche al modello (ricalcolo parziale, 6–52 secondi). Quando modifica il modello di processo aggiungendo o rimuovendo attività oppure cambiando le mappature, vengono aggiornati solo i calcoli dipendenti dal modello. L’operazione richiede 6 secondi per i dataset più piccoli e fino a 52 secondi per 100 milioni di eventi, molto meno del preprocessing completo. Le modifiche ai filtri sono immediate.

Comprendere le prestazioni delle query

Una volta caricati i Suoi dati, diversi fattori determinano la velocità delle query. Comprenderli La aiuta a progettare export migliori e a definire aspettative realistiche.

Il numero di attività è importante. I modelli di processo con 10–20 attività distinte sono ottimali. Oltre 50 attività, il process flow richiede più tempo per essere calcolato e diventa più difficile da comprendere. Un numero eccessivo di nodi e archi crea rumore visivo. Se il Suo export contiene molte attività, valuti di raggruppare i passaggi correlati.

La varietà delle varianti influisce sui calcoli. Un processo in cui l’80% dei casi segue 5 varianti è più rapido da analizzare rispetto a uno in cui ogni caso segue un percorso diverso. Un’elevata variabilità non è necessariamente negativa e spesso segnala problemi reali, ma comporta tempi di risposta delle query leggermente più lunghi.

Più colonne significano più dati da analizzare. Ogni attributo incluso viene indicizzato e interrogato. Le colonne fondamentali, CaseId, Activity e Timestamp, sono sempre necessarie. Le colonne aggiuntive aiutano a filtrare e categorizzare i dati, ma ciascuna introduce un ulteriore carico di elaborazione.

I casi lunghi richiedono più tempo. Un caso con 50 eventi richiede più calcoli rispetto a uno con 5. Se il Suo processo comprende casi che si estendono per centinaia di eventi, le query saranno proporzionalmente più lente. È una caratteristica intrinseca del Process Mining, non una peculiarità di uno strumento specifico.

Dati di benchmark reali (marzo 2026)

Comprendere cosa aspettarsi La aiuta a pianificare. Questi benchmark vengono eseguiti su un’infrastruttura AWS di produzione, con la latenza di rete reale, e rappresentano la media di più esecuzioni di test. Abbiamo testato oltre 50 tipi di query per ogni dimensione di dataset.

Tempi di upload e preprocessing

La tabella seguente mostra aspettative realistiche per ogni dimensione di dataset. Per i file più grandi, soprattutto con connessioni lente, il tempo di upload incide maggiormente. È il singolo fattore che influisce di più sul tempo totale di attesa.

Le dimensioni dei file si riferiscono a CSV non compressi con uno schema tipico di Event Log (CaseId, Activity, Timestamp e 5–8 attributi aziendali). I Suoi file possono essere più grandi o più piccoli in base al numero e al contenuto delle colonne.

I tempi di upload a 1 Gbps sono misurati con una velocità effettiva di 88 MB/s verso AWS eu-central-1. Le altre velocità sono state estrapolate sulla base di velocità pratiche: 50 Mbps → circa 5 MB/s, 100 Mbps → circa 10 MB/s, 10 Mbps → circa 1 MB/s. La velocità effettiva dipende dalla Sua rete, dalla distanza dal data center e dal carico del momento.

Il punto chiave: il tempo di preprocessing si stabilizza tra 1 e 2,5 minuti indipendentemente dalla scala. Il tempo di upload cresce linearmente con la dimensione del file. Ridurre la dimensione del file è l’ottimizzazione con il maggiore impatto.

Scelga il formato di file più adatto

Il formato del file che carica influisce in modo significativo sulla velocità di upload e sul tempo di preprocessing. ProcessMind supporta CSV, Parquet, ORC, Excel e XES. Per i dataset di grandi dimensioni, Parquet e ORC superano nettamente CSV sia in termini di dimensione del file sia di velocità di elaborazione.

Confronto delle dimensioni dei file

I file Parquet sono più piccoli dell’85% rispetto ai CSV. I file ORC sono più piccoli dell’82%. Entrambi sono formati colonnari con compressione integrata, quindi non è necessario alcun passaggio aggiuntivo. Il Suo strumento ETL o la Sua piattaforma dati, come Spark, Databricks, dbt o BigQuery, probabilmente supporta già l’export in Parquet o ORC.

Preprocessing in base al formato

La dimensione del file racconta solo metà della storia. Dopo l’upload, i Suoi dati passano attraverso l’acquisizione e i calcoli analitici specifici del formato, inclusi l’indicizzazione degli eventi e il calcolo delle transizioni e delle varianti. La fase analitica è quella predominante ed è uguale per tutti i formati. CSV.GZ è l’unico formato che aggiunge un tempo significativo, perché i file gzip non possono essere suddivisi per la decompressione parallela.

Il tempo di preprocessing è quasi identico per Parquet, ORC e CSV perché, indipendentemente dal formato di input, a incidere maggiormente sono i calcoli analitici. Tuttavia, il preprocessing di CSV.GZ peggiora significativamente con l’aumentare della scala, passando da circa un minuto con 1 milione di eventi a oltre 4 minuti con 100 milioni. I file compressi con gzip non possono essere suddivisi ed elaborati in parallelo, quindi la decompressione aggiunge una fase sempre più lunga prima dell’avvio delle analisi.

Il quadro completo

Considerando sia il tempo di upload sia il preprocessing, la scelta del formato diventa chiara:

Su larga scala, Parquet e ORC sono i chiari vincitori perché le dimensioni dei file sono nettamente inferiori. Il tempo di upload è il principale collo di bottiglia. Il preprocessing richiede all’incirca lo stesso tempo per tutti i formati, ad eccezione di CSV.GZ, che comporta un costo di decompressione crescente.

Delta Loading: aggiunga dati senza ripetere l’upload

Dopo aver caricato un dataset di base, non è necessario ripetere l’upload completo ogni volta che arrivano nuovi dati. ProcessMind supporta il delta loading, ovvero gli upload incrementali, che consentono di aggiungere nuovi eventi a un dataset esistente.

Come funziona:

1. Carichi il dataset iniziale, ad esempio gli ordini di acquisto del primo trimestre 2026 con 2,3 milioni di eventi
2. Quando arrivano i dati del secondo trimestre, carichi soltanto i nuovi eventi in un file delta, ad esempio 800.000 nuovi eventi
3. ProcessMind unisce automaticamente i file e avvia nuovamente l’elaborazione

L’impatto sulle prestazioni è significativo. Invece di ripetere ogni volta l’upload del dataset in crescita, carica solo ciò che è nuovo:

Dopo un upload delta, il preprocessing viene eseguito nuovamente sul dataset combinato, con lo stesso costo di 1–2,5 minuti. Tuttavia, risparmia tutto il tempo di upload relativo ai dati già caricati.

Il delta loading è ideale per:

• Aggiornamenti settimanali o mensili dei dati: aggiunga le nuove transazioni non appena sono disponibili
• Monitoraggio continuo dei processi: mantenga aggiornati i Dashboard senza upload di grandi dimensioni
• Event Log in crescita: aggiunga nuovi eventi provenienti da ERP, CRM o altri sistemi sorgente

I file delta devono utilizzare lo stesso formato e la stessa struttura di colonne dell’upload originale. Per maggiori dettagli, consulti la guida al caricamento incrementale dei dati.

Utilizzare l’API per upload di grandi dimensioni o automatizzati

Per dataset superiori a pochi gigabyte o per upload ricorrenti, gli script e gli strumenti da riga di comando sono più affidabili degli upload dal browser. I browser possono interrompere la sessione per timeout, consumare una quantità eccessiva di memoria o perdere i progressi quando la rete viene interrotta.

Perché l’API è più efficace con i file di grandi dimensioni:

• Trasferimenti affidabili. Se la connessione si interrompe, può riprovare senza ricominciare da capo.
• Nessun limite di memoria del browser. I browser hanno difficoltà con file di diversi gigabyte. Gli strumenti da riga di comando li gestiscono facilmente.
• Automazione. Pianifichi gli upload notturni, integri i dati nelle pipeline ETL o attivi gli upload da CI/CD.
• Monitoraggio dell’avanzamento. Strumenti come curl mostrano l’avanzamento del trasferimento in tempo reale.
• Upload delta. Aggiunga programmaticamente nuovi dati secondo una pianificazione.

Esempio con curl:

# Upload a Parquet file directly using a presigned URL
curl -X PUT "$PRESIGNED_URL" --upload-file data.parquet

ProcessMind fornisce URL presigned che autorizzano gli upload diretti nello storage cloud. Non sono necessarie credenziali oltre alla Sua chiave API. Può inoltre copiare direttamente l’URL di upload presigned dal menu delle impostazioni del dataset nell’interfaccia utente di ProcessMind.

Consulti la documentazione dell’API per esempi completi in Bash, JavaScript e Python, inclusi quelli relativi all’ottenimento di URL presigned, al caricamento di file delta e alla gestione programmatica di dataset di grandi dimensioni.

Velocità di iterazione del modello

Quando perfeziona il modello di processo rinominando le attività, modificando le mappature o aggiungendo raggruppamenti, devono essere aggiornati solo i calcoli dipendenti dal modello. I dati di base rimangono invariati:

Le modifiche al modello sono rapide perché il caricamento iniziale dei dati, che cresce con la dimensione del dataset, è già completato. Viene eseguita nuovamente solo l’aggregazione dipendente dal modello, incluse le mappature delle attività, le transizioni e le varianti. Per dataset fino a 20 milioni di eventi, le modifiche al modello vengono completate in meno di 25 secondi. Anche con 100 milioni di eventi richiedono meno di un minuto, molto meno del preprocessing completo.

Tempi di risposta dei Dashboard

Una volta caricati i Suoi dati, questi sono i tempi di risposta che sperimenta durante l’analisi. I tempi riportati di seguito sono mediane calcolate su più esecuzioni di benchmark. Ogni componente del Dashboard esegue le proprie query in modo indipendente e viene caricato in parallelo:

Schemi da osservare:

• Le statistiche, inclusi conteggi e durate riepilogativi, rimangono intorno a 0,6 s indipendentemente dalle dimensioni. Queste query sono altamente ottimizzate.
• Il Process Flow, ovvero il diagramma di processo, cresce con la dimensione del dataset perché calcola le transizioni tra tutte le attività.
• Le varianti e le categorie crescono moderatamente. I dati preaggregati ne mantengono elevata la velocità.
• Il Data Browser rimane veloce grazie alla paginazione. Con i filtri applicati, scende sotto 1 s.
• L’animazione varia in base al numero di casi attivi visualizzati.

In sintesi: con le dimensioni di dataset consigliate, da 1 a 10 milioni di eventi, ogni componente del Dashboard risponde in meno di 3,5 secondi. Anche con 50 milioni di eventi, la maggior parte delle query restituisce risultati in 2–4 secondi con i filtri applicati. Solo i Process Flow e le viste delle categorie senza filtri, su dataset da 50 milioni di eventi in su, raggiungono 5–6 secondi.

Inizi in piccolo, cresca in grande

Questo è il consiglio più importante della guida: non inizi dal dataset più grande.

I numeri parlano da soli:

La maggior parte delle organizzazioni scopre che 1–5 milioni di eventi sono più che sufficienti per ottenere insight concreti. Il comportamento del processo si stabilizza ben prima di 10 milioni di eventi. Oltre questa soglia, si aggiungono soprattutto duplicati di pattern già osservati.

Se il Suo file Parquet da 1 milione di eventi, di 34 MB, viene caricato in 3 secondi e Le offre la stessa mappa di processo di 50 milioni di eventi, perché aspettare 18 minuti?

Strategia dei dati: trovare la dimensione giusta

I numeri riportati sopra raccontano una storia chiara: con 1–5 milioni di eventi, gli upload richiedono pochi secondi, il preprocessing meno di 2 minuti e i Dashboard rispondono in 1–2,5 secondi. Con 50 milioni di eventi, attende 20 minuti per un upload a 100 Mbps e i Dashboard rallentano fino a 3–6 secondi. L’esperienza è radicalmente diversa.

La vera domanda, quindi, non è «quanto è veloce lo strumento?», ma «di quanti dati ho effettivamente bisogno?». La risposta è quasi sempre: meno di quanto pensa.

Prima segmenti, poi aggreghi

Analizzi prima un Paese, un reparto o una linea di prodotto.

Non si tratta di una limitazione, ma di chiarezza. Un’analisi segmentata produce insight più precisi rispetto alle medie globali.

Perché la segmentazione funziona:

• I processi variano in base alla regione. Le attività operative tedesche seguono catene di approvazione diverse da quelle statunitensi. Le leggi sul lavoro francesi generano Workflow HR differenti. Analizzarle insieme crea rumore.
• Stakeholder diversi, priorità diverse. Il VP dell’EMEA si concentra sull’EMEA. Gli mostri i dati dell’EMEA. La vista globale può arrivare in un secondo momento.
• Iterazione più rapida. I dati di un singolo Paese possono comprendere 500.000 eventi invece di 10 milioni. Può iterare in pochi minuti, non in ore.
• Benchmark integrato. Dopo aver analizzato la Germania, faccia lo stesso per la Francia. A quel punto potrà confrontarle.

Esempio: un’azienda logistica europea con 42 milioni di eventi di spedizione distribuiti in 8 Paesi:

• Analizzare tutto: 42 milioni di eventi, 9,3 GB, 16 minuti di upload (100 Mbps), 2 minuti di preprocessing
• Analizzare solo la Germania: 8,5 milioni di eventi, 1,9 GB, 3 minuti di upload, 1,5 minuti di preprocessing
• Analizzare solo i Paesi Bassi: 3,1 milioni di eventi, 690 MB, 1 minuto di upload, 1 minuto di preprocessing
• Utilizzare il delta loading: caricare prima la Germania, quindi aggiungere i Paesi Bassi quando sono pronti

Escluda il percorso standard

Escluda il percorso standard prima dell’upload. Questa tecnica può ridurre i dataset del 90–95%.

La maggior parte dei processi aziendali segue la regola 80/20. La grande maggioranza dei casi segue il percorso standard e si conclude con successo. Se sta cercando eccezioni, violazioni della conformità o deviazioni di processo, non ha bisogno di quei dati.

Esempio: un processo purchase-to-pay con 1,2 milioni di ordini di acquisto (8,4 milioni di eventi):

• 1,1 milioni di ordini (92%) seguono il percorso standard: Creazione dell’ordine di acquisto → Approvazione → Ricezione della merce → Fattura → Pagamento
• 96.000 ordini (8%) presentano eccezioni: rifiuti, resi, fatture duplicate e approvazioni mancanti

Se sta analizzando problemi di conformità, esporti solo i casi con eccezioni. Si tratta di una riduzione del 92%, da 8,4 milioni di eventi (1,9 GB) a 670.000 eventi (150 MB). Il tempo di upload scende da 3 minuti a 15 secondi a 100 Mbps. Esportando in Parquet (15 MB), può completare l’upload in meno di 2 secondi.

Selezione delle colonne: meno è meglio

Ogni colonna esportata comporta costi in termini di banda, storage e tempo di elaborazione. Scegliere con attenzione le colonne è una delle ottimizzazioni con il maggiore impatto.

Cosa escludere:

• Campi di testo lunghi. Descrizioni degli ordini, commenti, note e campi a testo libero. Un campo descrittivo di 500 caratteri su 5 milioni di eventi aggiunge 2,5 GB al file.
• PII (informazioni personali identificabili). Nomi, indirizzi e-mail e numeri di telefono. Rimuovere le PII riduce la dimensione del file, elimina i rischi per la privacy e semplifica la conformità.
• Identificativi ridondanti. Se dispone di OrderId, non Le servono OrderGUID, OrderReference o LegacyOrderNumber.
• Colonne di audit. CreatedBy, ModifiedBy, CreatedDate e ModifiedDate. Se non le sta analizzando nello specifico, le escluda.
• Colonne di sistema. Flag interni, chiavi di partizione e metadati tecnici.

Esempio: un export SAP di 1,8 milioni di eventi relativi a ordini di acquisto, con 45 colonne, ridotto a 12 colonne essenziali:

• Dimensione del file: 2,1 GB → 380 MB (riduzione dell’82%)
• In Parquet: 380 MB → 58 MB (un’ulteriore riduzione dell’85%)
• Tempo di upload (100 Mbps): 3,5 min → 6 secondi
• Stesso valore analitico

Le colonne importanti: CaseId, Activity, Timestamp e alcuni attributi aziendali, come stato, importo, categoria e regione. Tutto il resto è probabilmente rumore.

Quando la scala è importante

Alcune domande analitiche richiedono realmente dataset di grandi dimensioni. Comprendere quando è necessario La aiuta a prendere la decisione giusta:

• Rilevamento di eventi rari. Per individuare casi limite che si verificano una volta ogni 100.000 occorrenze, è necessaria una popolazione abbastanza ampia da contenere campioni significativi. Se deve analizzare 50 istanze di un’eccezione rara che si verifica nello 0,01% dei casi, Le servono 500.000 casi.
• Misurazione dei percorsi a bassa frequenza. Le varianti di processo che si verificano nello 0,1% dei casi potrebbero essere invisibili in un campione da 1 milione di eventi, ma significative in una popolazione da 50 milioni.
• Conformità e audit. Alcune normative richiedono la copertura completa della popolazione. Il campionamento non è accettabile.
• Analisi delle tendenze su più anni. Confrontare il primo trimestre 2024 con il primo trimestre 2025 e il primo trimestre 2026 richiede dati relativi a tutti e tre i periodi. Utilizzi il delta loading per costruire il dataset in modo incrementale.

Se ha bisogno di oltre 50 milioni di eventi, pianifichi l’operazione: utilizzi il formato Parquet, che riduce un CSV da 11 GB a 1,7 GB e accelera il preprocessing; utilizzi l’API per trasferimenti affidabili; e, se disponibile, scelga una connessione di rete veloce. Dopo il primo caricamento, i Dashboard rimangono veloci.

Mantenere veloci il modello e l’interfaccia

Le sezioni precedenti riguardano il volume dei dati. L’altra metà della reattività dipende dal modo in cui sono costruiti il modello e le Dashboard:

• Semplifichi il modello. Suddivida i processi di grandi dimensioni in sottoprocessi modulari; una tela con mille elementi visibili è lenta da visualizzare e impossibile da leggere. Esegua il layout automatico dopo le modifiche strutturali.
• Sia selettivo con le Dashboard. Ogni grafico e riquadro deve essere calcolato. Mantenga i grafici su cui si interviene e sposti gli altri in una Dashboard dedicata, invece di accumulare tutto in un’unica vista.
• Abbini il grafico al dataset. Nei dataset di grandi dimensioni, eviti le visualizzazioni che richiedono più risorse, come grafici a torta dettagliati e suddivisioni con molte categorie, preferendo grafici di sintesi.
• Applichi i filtri con moderazione. I filtri sono poco onerosi singolarmente, ma costosi in combinazione. Mantenga l’insieme necessario a rispondere alla domanda e lo rimuova successivamente.
• Osservi l’animazione. Il costo dell’animazione cresce con il numero di casi attivi. Riduca la velocità oppure disattivi scie ed effetti quando Le serve solo il flusso; consulti Animazione del processo.
• Archivi e riveda. Sposti i dataset e i processi obsoleti fuori dall’area di lavoro attiva e utilizzi la simulazione con le metriche temporali per individuare i colli di bottiglia su cui intervenire, invece di ottimizzare tutto contemporaneamente.

Prossimi passi

Il modo migliore per comprendere le prestazioni del Process Mining è sperimentarle con i Suoi dati.

1. Inizi con un campione. Esporti 1 milione di eventi relativi a un periodo recente in formato Parquet. Li carichi. Costruisca il primo modello. Verifichi quanto rapidamente può iterare.

2. Applichi le tecniche di questa guida. Utilizzi formati colonnari. Filtri le eccezioni. Segmenti per regione. Rimuova le colonne non necessarie. Ogni ottimizzazione si basa sulla precedente.

3. Aumenti la scala in modo consapevole. Dopo aver compreso il Suo processo con 1 milione di eventi, valuti se ne servono di più. Di solito, non è necessario. Quando lo è, utilizzi il delta loading per aggiungere dati invece di ripetere l’upload.

Inizi la prova gratuita e verifichi questi benchmark direttamente. Per ricevere assistenza nel dimensionamento del Suo dataset o nell’ottimizzazione degli export, ci contatti. Abbiamo aiutato centinaia di organizzazioni a trovare il giusto equilibrio tra volume dei dati e velocità di analisi.