Che cos’è un BPMS? La gestione dei processi aziendali

Un BPMS, o sistema di gestione dei processi aziendali, è un software che modella ed esegue processi definiti, monitorando il lavoro svolto. È pensato per gestire l’esecuzione: impone una sequenza, assegna attività e registra ciò che è accaduto. La sua visione d’insieme, però, è limitata a quella parte del lavoro che gli viene affidata.

Questa guida spiega che cosa fa un BPMS, quali sono i cinque componenti che si acquistano davvero e dove si fermano le sue funzionalità. Confronta poi il software di esecuzione con la process intelligence, che lascia intenzionalmente l’esecuzione ai numerosi sistemi che già la gestiscono bene e riunisce invece i loro dati in un unico luogo, accessibile alle persone e alla loro AI.

Che cosa significa BPMS?

BPMS sta per Business Process Management System. Alcuni fornitori usano invece l’espressione Business Process Management Suite. In entrambi i casi, questa categoria comprende software per definire un processo, instradare il lavoro al suo interno e monitorarne l’esecuzione.

Il BPM, o gestione dei processi aziendali, è la disciplina che consiste nel comprendere, progettare, misurare e migliorare il modo in cui si svolge il lavoro. Un BPMS è un tipo di software che può supportare questa disciplina. È possibile applicare il BPM senza acquistare un BPMS, e acquistare un BPMS non garantisce una buona gestione dei processi.

Nel tempo la categoria si è evoluta. È nata con i motori di flusso di lavoro, si è ampliata con suite che hanno aggiunto modellazione, moduli e monitoraggio e oggi comprende piattaforme low-code con cui i team assemblano applicazioni di processo complete. Questa varietà spiega perché i fornitori descrivono il BPMS in modi diversi. Quando valuta un software per la gestione dei processi aziendali, non si fermi all’etichetta: ponga le quattro domande che contano. Consente di modellare il processo, eseguirlo, collegarsi agli altri sistemi coinvolti e mostrare come funzionano le istanze?

Quali sono i cinque componenti di un BPMS?

I prodotti combinano queste funzionalità in modi diversi, ma un sistema di gestione dei processi aziendali comprende in genere cinque componenti:

1. Un modellatore. Consente di definire il processo, spesso in BPMN 2.0. Un modello può descrivere il flusso e, in un sistema eseguibile, fornire la base per eseguirlo. Per saperne di più sulla progettazione dei modelli di processo, consulti il modellatore BPMN.
2. Un motore di esecuzione. Crea istanze di processo, valuta le condizioni, assegna le attività, avvia i timer e inoltra le attività in ritardo ai livelli successivi.
3. Moduli, regole e ruoli. Determinano quali informazioni devono fornire le persone, quali attività visualizzano e quali regole governano la fase successiva.
4. Integrazione. Il sistema scambia dati con applicazioni come ERP e CRM, data warehouse e gateway API. Il lavoro di integrazione può incidere in modo significativo sull’implementazione.
5. Monitoraggio e archivio. Le Dashboard mostrano lo stato delle istanze in corso. Un archivio aiuta a gestire le versioni dei processi e a controllare le modifiche.

Un motore di flusso di lavoro è solo una parte del quadro. Un BPMS riunisce il motore e gli strumenti e i controlli necessari per definire, supportare e monitorare un processo più ampio.

Che cosa può fare un BPMS che un documento di processo non può fare?

Un documento di processo descrive come dovrebbe svolgersi il lavoro. Un BPMS può instradare e monitorare il lavoro secondo regole configurate. Per esempio, può:

• Inoltrare un’attività rimasta in attesa per un periodo prestabilito.
• Inviare un’istanza per l’approvazione quando raggiunge una soglia configurata.
• Registrare il percorso seguito da ogni istanza.
• ConsentirLe di aggiornare un flusso tramite configurazione, senza modificare diverse applicazioni collegate.

Queste funzionalità sono utili quando servono un instradamento coerente, responsabilità chiare e visibilità sulle istanze gestite dal sistema. Non garantiscono che ogni parte del processo reale si svolga all’interno del BPMS. Se ha soprattutto bisogno di documentare un processo o capire come funziona oggi, il software di esecuzione potrebbe non essere il primo passo giusto.

Quali sono le differenze tra BPMS, motori di flusso di lavoro, RPA, Process Mining e process intelligence?

Queste cinque tecnologie intervengono su aspetti diversi della gestione dei processi. La tabella seguente mostra che cosa fa ciascuna e a quale domanda aiuta a rispondere.

RPA e BPMS affrontano in modo diverso le modifiche ai processi. La RPA automatizza attività all’interno del processo esistente. Un BPMS esegue un processo definito dall’utente e può modificare il modo in cui viene instradato il lavoro. Prima di automatizzare un’attività, verifichi se una riprogettazione del processo potrebbe eliminarla. Per saperne di più, legga come individuare opportunità di automazione con il Process Mining.

Anche il Process Mining e un BPMS rispondono a domande diverse. Il Process Mining analizza i dati degli eventi per mostrare come il lavoro si sposta realmente tra i sistemi. Un BPMS esegue un flusso progettato e fornisce informazioni sulle istanze che gestisce. Questa distinzione è importante quando occorre verificare se il modello corrisponde al lavoro effettivo.

La process intelligence occupa l’ultima riga ed è la soluzione che collega le altre. Lascia l’esecuzione al sistema più adatto, legge le registrazioni di ogni sistema e mantiene un unico modello del processo con cui confrontarli. Un BPMS fornisce informazioni sulle proprie istanze; la process intelligence riguarda il processo nel suo insieme, compreso il lavoro che nessuna singola piattaforma gestisce.

Perché un solo BPMS non può gestire ogni processo?

Un BPMS sembra la risposta alla gestione dei processi, finché non si considerano i sistemi che non controlla. Un processo reale coinvolge un ERP, un CRM, uno strumento per la gestione dei ticket, un portale fornitori, un foglio di calcolo e alcune caselle di posta. La piattaforma esegue la parte modellata al suo interno; il resto del lavoro prosegue altrove.

Prima di acquistare, è utile conoscere tre conseguenze di questa lacuna.

Si creano flussi di lavoro personalizzati invece di riutilizzare standard. Un BPMS è una cassetta degli attrezzi, quindi ogni processo diventa un progetto: si modella una variante specifica, si assegnano nomi alle fasi e si mantiene una propria versione di un flusso che migliaia di altre organizzazioni gestiscono già. I modelli di riferimento standard di settore per i processi dall’ordine all’incasso, dall’acquisto al pagamento o per la gestione degli incidenti vengono ricreati in ogni piattaforma anziché riutilizzati. Di conseguenza, due reparti che usano lo stesso sistema possono finire per gestire versioni diverse dello stesso processo.

Le piattaforme incentrate sull’esecuzione perdono di vista il quadro complessivo. Un BPMS viene valutato in base a ciò che esegue, quindi l’attenzione e il budget si concentrano sui flussi gestiti al suo interno. Spesso i processi che non esegue, quelli che attraversano team, sistemi e paesi, sono proprio quelli di cui nessuno è responsabile. Rendere più veloce ciò che viene eseguito non equivale a capire come funziona l’organizzazione.

Anche un BPMS ha i suoi limiti e genera eccezioni proprie. Ogni processo presenta eccezioni: l’ordine urgente, il cliente VIP, il fornitore che accetta soltanto le e-mail. In un BPMS, ogni eccezione diventa un altro ramo configurato, un altro modulo, un’altra integrazione e un altro flusso di lavoro da mantenere. La piattaforma, nata per standardizzare il lavoro, si riempie lentamente di casi particolari che solo il team che la gestisce riesce a comprendere.

Questo non significa che un BPMS sia uno strumento inadeguato. Significa che non è la fonte unica e affidabile per conoscere i Suoi processi.

La gestione dei processi aziendali in ambito IT e quella nelle funzioni aziendali

La differenza è più evidente nella gestione dei processi aziendali in ambito IT, dove una singola attività può coinvolgere una coda di ticket, un calendario delle modifiche, diverse applicazioni e le relative approvazioni. Nessun software per la gestione dei processi aziendali offre una visione completa di tutti e quattro gli elementi.

Anche nelle funzioni aziendali si presenta una lacuna analoga, seppure in forma diversa. I processi dall’ordine all’incasso, dall’acquisto al pagamento o di onboarding dei dipendenti attraversano più sistemi, ma le relative attività fanno capo alle operations, non a un Service Desk. Le attese si misurano quindi in giorni, non in ticket, e raramente il percorso tra i sistemi è documentato dall’inizio alla fine.

Questa differenza cambia ciò che acquista. Una piattaforma per la gestione dei servizi viene valutata in base ai ticket che gestisce, quindi il tempo che misura si ferma ai confini del sistema: le fasi del processo che avvengono al di fuori, come la risposta di un fornitore, una verifica del credito o un’approvazione via e-mail, non sono visibili dall’interno. A prescindere da chi è responsabile del processo, il metodo non cambia: ricostruire il percorso usando i dati degli eventi registrati da ogni sistema e confrontarlo con il flusso documentato.

Ha senso mantenere un BPMS che usa a malapena?

Molte organizzazioni hanno acquistato un BPMS per il suo motore di esecuzione, senza poi utilizzarlo. L’avvio ha richiesto più tempo del previsto, i primi flussi sono stati configurati da un partner e l’azienda ha continuato a lavorare con i sistemi che già utilizzava. Spesso resta uno strumento di modellazione aperto da poche persone e una fattura di manutenzione per un ambiente di esecuzione che nessuno avvia.

A questo punto conviene distinguere i due compiti riuniti nella piattaforma. Il motore del flusso di lavoro doveva eseguire le attività; il repository dei modelli doveva conservare la conoscenza dei processi. Se viene svolto solo il secondo compito, si paga una piattaforma di esecuzione per usarla come strumento di documentazione: una soluzione complessa, tecnica e costosa.

Se la maggior parte di queste affermazioni corrisponde alla realtà, alla piattaforma di esecuzione si sta chiedendo di gestire la conoscenza, un compito per cui non è stata progettata. La soluzione non è aggiungere un ambiente di esecuzione, ma trasferire le informazioni in uno strumento pensato per fungere da punto di riferimento: un unico luogo per tutti i processi, collegato ai dati di ogni sistema e accessibile alle persone e agli assistenti AI che ne hanno bisogno, senza alcun ambiente di esecuzione da gestire.

Mantenga il BPMS per i processi che esegue davvero. Sposti la conoscenza dei processi in uno spazio in cui possa evolvere senza dipendere da un ciclo di rilascio.

In che cosa la Process Intelligence si differenzia da un BPMS?

La differenza è intenzionale, non dipende da una funzionalità mancante. La Process Intelligence non si occupa dell’esecuzione, perché esistono molti strumenti in grado di svolgerla e la piattaforma già in uso raramente è la scelta migliore. RPA, agenti AI, un sistema di gestione dei flussi di lavoro, i flussi di lavoro dell’ERP e i team che svolgono direttamente le attività sono adatti a contesti diversi. Lo strumento che esegue il lavoro va scelto in base a quel compito specifico.

La conoscenza, invece, non può essere lasciata in mano a cinque sistemi diversi. Se ogni strumento di esecuzione conserva una propria mappa del processo, nessuno può stabilire con chiarezza in cosa consista il processo, quale variante abbia seguito un cliente o quale passaggio convenga automatizzare. Centralizzare la conoscenza dei processi, per chi svolge le attività e per gli assistenti AI che iniziano a utilizzarla, è più importante che eseguire il lavoro.

È qui che si trova il vantaggio dei dati. Un BPMS fornisce informazioni sulle proprie istanze; una piattaforma di Process Intelligence collega i dati degli eventi provenienti da tutti i sistemi, includendo così anche le attività che il BPMS non ha mai rilevato. Può quindi conservare un unico modello di riferimento per il BPMS, l’ERP e gli strumenti di automazione.

Perché serve il Process Mining per ancorare il modello alla realtà?

Un BPMS può fornire informazioni sulle istanze eseguite al suo interno, ma questo non significa che rilevi tutti i percorsi seguiti dalle persone per completare il processo. Possono verificarsi tre situazioni comuni:

• Il lavoro si svolge al di fuori del motore. Un’eccezione viene gestita via e-mail e registrata nel sistema in un secondo momento. L’istanza può sembrare conforme anche se il lavoro ha richiesto più tempo di quanto indicato dal modello.
• Lo stesso risultato si ottiene usando altri sistemi. I team possono ricorrere a un ERP, a un foglio di calcolo o al portale di un fornitore. Se queste attività non vengono registrate nel BPMS, le sue Dashboard non possono mostrare l’intero processo.
• Il modello non viene aggiornato. Un processo può essere corretto al momento della pubblicazione, ma discostarsi gradualmente dalla realtà quando i team adottano varianti locali. Se aggiornare il modello richiede tempo, queste varianti possono consolidarsi.

Il risultato è un modello gestito con cura, ma che non rispecchia più il modo in cui le persone lavorano. Il Process Mining permette di riallinearlo alla realtà: legge i dati degli eventi già registrati dai sistemi e ricostruisce i percorsi effettivamente seguiti, compresi quelli mai modellati.

Il controllo di conformità confronta un modello di processo con i dati degli eventi per mostrare dove l’esecuzione diverge dalla progettazione, mentre il Process Mining mette in luce le varianti, i ritardi e le rilavorazioni presenti nei Suoi dati. Perché la modellazione dei processi e il Process Mining vanno di pari passo spiega perché le due prospettive, ciò che si intende fare e ciò che è accaduto, non dovrebbero mai essere separate.

Perché abbiamo deciso di non sviluppare funzionalità di esecuzione?

È una domanda legittima per una piattaforma di processo: se permette di modellare un processo e vedere come si svolge, perché non dovrebbe anche eseguirlo? Un BPMS esiste proprio perché la risposta più ovvia è sì. Noi abbiamo scelto una strada diversa: è stata una decisione precisa, non una funzionalità trascurata.

In pratica, ProcessMind non chiede mai le chiavi del flusso di lavoro. I sistemi già in uso continuano a eseguire le attività, mentre le informazioni su ciò che fanno vengono centralizzate e aggiornate. Se in seguito sostituisce uno strumento di esecuzione, per esempio un bot RPA con un agente AI o un flusso di lavoro obsoleto con uno nuovo, il modello, lo storico e le misurazioni restano al loro posto. Perché abbiamo creato ProcessMind approfondisce le ragioni di questa scelta.

Come si integra ProcessMind con un BPMS?

ProcessMind non è un BPMS e non esegue attività. Il BPMS, l’ERP o la piattaforma di automazione continuano a gestire l’esecuzione dei processi: è proprio questo il punto. Si mantiene lo strumento più adatto per eseguire ciascun processo e si raccolgono in un unico luogo le informazioni che li riguardano tutti.

È questo che la Process Intelligence consente di fare:

• Prima di sviluppare: analizzi i dati degli eventi dei sistemi coinvolti per individuare i percorsi effettivi, le varianti e le eccezioni. Modelli il processo desiderato in BPMN 2.0, quindi utilizzi la simulazione dei processi per verificare una modifica prima che qualcuno configuri un flusso di lavoro.
• Dopo lo sviluppo: continui ad analizzare i dati per verificare se l’esecuzione corrisponde ancora al progetto e individuare i casi in cui una soluzione alternativa locale è diventata, senza che nessuno se ne accorgesse, la prassi seguita da tutti.

Il BPMS esegue il lavoro. La Process Intelligence aiuta a decidere quali attività vale la pena eseguire e verifica se il risultato corrisponde al processo seguito dalle persone.

Quando scegliere un BPMS, l’RPA o la Process Intelligence?

Il punto di partenza più adatto dipende da ciò che già conosce e dal problema che vuole risolvere.

Parta dalla Process Intelligence se:

• Le persone non concordano su come si svolge oggi il processo.
• Il processo coinvolge diversi sistemi e una parte del lavoro potrebbe svolgersi al di fuori del flusso di lavoro principale.
• Sa che il processo è lento, ma non ne conosce il motivo.
• Ha un BPMS il cui motore del flusso di lavoro è inattivo e vuole conservare le informazioni sul processo in uno spazio utile.

Valuti un BPMS se:

• Il processo è sufficientemente chiaro e stabile da poter essere standardizzato.
• Il lavoro coinvolge più team e occorre definire meglio l’instradamento o le responsabilità nei passaggi di consegne.
• Deve applicare regole e gestire le modifiche senza intervenire contemporaneamente su diverse applicazioni.

Valuti l’RPA se:

• Il processo è stabile e ripetitivo.
• L’attività si ripete abbastanza spesso da giustificare l’automazione.
• Non è possibile modificare le applicazioni e il passaggio può essere automatizzato tramite le relative interfacce.

Due buone abitudini aiutano a seguire l’ordine giusto: misurare il processo prima di acquistare un software di esecuzione e verificare se una riprogettazione può eliminare l’attività prima di automatizzarla.

Come valutare un BPMS prima di acquistarlo?

Parta da un processo con un nome chiaro e un responsabile: dal ricevimento dell’ordine all’incasso, dal pagamento all’acquisto, dall’inserimento del personale alla gestione degli incidenti. Eviti di valutare un’area generica come le «operations» senza specificare a quale processo si riferisce. Proceda quindi in quattro passaggi.

1. Individui i dati degli eventi

   Verifichi quali sistemi registrano il processo e se i dati includono un identificativo del caso, un’attività e una data e ora. Gli strumenti di gestione dei processi aziendali descrivono il flusso previsto; l’Event Log dimostra che cosa è stato eseguito.

2. Confronti il progetto con ciò che è stato eseguito

   Individui i percorsi, i ritardi e le eccezioni che il modello non mostra. Provare il BPMS candidato più adatto sui propri dati è più utile che consultare una tabella delle funzionalità, perché permette di capire quali parti del processo gestirebbe davvero.

3. Decida quale soluzione indicano i dati

   La soluzione potrebbe essere un BPMS, una riprogettazione del processo, la modifica di un singolo passaggio o nessun intervento. Lasci che siano i risultati a indicare lo strumento, non il contrario.

4. Continui a misurare dopo lo sviluppo

   La piattaforma può fornire informazioni sulle attività che esegue. I dati degli eventi raccolti nei diversi sistemi mostrano se, una volta attivato il flusso di lavoro, il processo continua a corrispondere alle attività effettive.

Se il processo coinvolge sistemi a cui il BPMS non è collegato, le prime misurazioni lo metteranno in evidenza. È su questa base che vale la pena decidere se acquistare una soluzione di esecuzione.