5 minuti di lettura

Automazione dei processi aziendali con Camunda: implementazione fault-tolerant di schemi BPM

BPMN

Affari

Comunda

Spring Boot

Nell'attuale mondo guidato dalla tecnologia digitale, per mantenere un vantaggio competitivo è necessario che i processi aziendali siano snelli ed efficienti. L'automazione è una soluzione chiave per raggiungere questo obiettivo. Secondo Statista, il mercato della gestione dei processi aziendali (BPM) è previsto raggiungerà una dimensione di 14,4 miliardi di dollari entro il 2025. La crescente popolarità e la domanda di strumenti BPM come Camunda, noti per la loro flessibilità e scalabilità, testimoniano questa tendenza. Poiché le aziende cercano strumenti affidabili per ottimizzare le loro operazioni, Camunda emerge come precursore, aprendo la strada a soluzioni di automazione innovative e tolleranti ai guasti nel settore.

Che cos'è Camunda?

In parole povere, Camunda è una piattaforma open-source per l'automazione dei flussi di lavoro e delle decisioni che riunisce utenti aziendali e sviluppatori di software. Grazie a una robusta serie di strumenti e funzionalità, Camunda offre la possibilità di progettare, implementare e ottimizzare i flussi di lavoro BPMN (Business Process Model and Notation), rendendo le operazioni aziendali più fluide e trasparenti.

Camunda, Spring Boot e BPMN: comprensione dei concetti

Tre attori chiave hanno ridisegnato il panorama della gestione dei processi aziendali: Camunda, Spring Boot e BPMN. Ognuno di essi si è ritagliato la propria nicchia, offrendo funzionalità uniche che affrontano aspetti distinti della gestione dei processi. Tuttavia, quando vengono combinati, si trasformano in una potenza ineguagliabile, in grado di rivoluzionare le operazioni delle imprese digitali.

Camunda: Non si tratta di un altro strumento nella vasta gamma di strumenti BPM, ma di uno strumento di spicco. Solida piattaforma open-source, Camunda è specializzata nell'automazione dei flussi di lavoro e delle decisioni. Il suo obiettivo principale? Fondere senza soluzione di continuità il mondo degli strateghi aziendali e quello degli sviluppatori di software. In questo modo, garantisce che la concettualizzazione, la progettazione e l'implementazione dei processi aziendali siano efficienti, trasparenti e coesi.

Spring Boot: Spring Boot prende la forza della struttura a molla e li eleva. Offrendo un metodo semplificato per creare applicazioni Java standalone, è diventato il punto di riferimento per gli sviluppatori che desiderano ridurre al minimo il codice boilerplate e immergersi direttamente nel cuore delle funzionalità specifiche del progetto. Il suo potere sta nella sua flessibilità e nel suo approccio convention-over-configuration, che sostiene l'idea di default intelligenti. Questo approccio consente agli sviluppatori di creare applicazioni scalabili più velocemente, garantendo una consegna tempestiva e prestazioni coerenti.

BPMN: Se dovessimo personificare BPMN, sarebbe l'eloquente linguista del mondo aziendale. Come standard riconosciuto a livello mondiale, il BPMN fornisce un vocabolario visivo per la stesura dei processi aziendali, rendendoli facilmente comprensibili a un'ampia gamma di stakeholder. Questo linguaggio universale garantisce che le sfumature tecniche di un processo siano decifrabili sia dal codificatore esperto di tecnologia che dallo stratega aziendale, favorendo dialoghi collaborativi e un processo decisionale più informato.

La sinergia tra le capacità di automazione di Camunda, la facilità di sviluppo di Spring Boot e la notazione standardizzata di BPMN offre alle aziende una tripletta dinamica. Insieme, assicurano che gli schemi BPM passino da semplici costrutti teorici sulla carta a implementazioni reali e attuabili. L'obiettivo finale? Coltivare processi aziendali agili, resilienti e perfettamente allineati con le esigenze in evoluzione del panorama aziendale digitale contemporaneo.

Componenti di base BPMN

Per chi non ha familiarità con il BPMN, la comprensione dei suoi componenti essenziali è fondamentale. Questi componenti costituiscono la base di qualsiasi diagramma BPMN.

Eventi

Indicano qualcosa che accade durante un processo. Gli eventi possono iniziare, interrompere o terminare un flusso e sono spesso rappresentati come cerchi.

Portali

Gateways handle decision-making within the process. Based on conditions, they control the flow of the process, usually depicted as diamonds.

Attività

Le attività rappresentano il lavoro svolto. Possono essere attività o sottoprocessi e vengono visualizzate come rettangoli arrotondati.

Collegare gli oggetti

Questi elementi, tra cui flussi di sequenze, flussi di messaggi e associazioni, illustrano la sequenza dei processi e il flusso dei messaggi.

Piani di nuoto

Queste categorizzano gli elementi BPMN in base al ruolo (ad esempio, manager, contabile) o al sistema (ad esempio, un sistema ERP).

Manufatti

Offrono informazioni aggiuntive sul processo. Gli artefatti comuni includono oggetti di dati, gruppi e annotazioni.

Pro e contro di Camunda

Come ogni soluzione tecnologica, Camunda presenta un mix di vantaggi e sfide. Ecco una panoramica completa dei suoi pro e contro.

Pro:

Integrazione flessibile e semplice con le applicazioni Java tramite Spring Boot.
Un'interfaccia di modellazione intuitiva per BPMN 2.0.
Fornisce analisi dettagliate sulle metriche di processo.

Contro:

Potrebbe avere una curva di apprendimento più ripida per gli utenti non tecnici.
È un ottimo punto di partenza, ma è solo la base: Camunda è un potente motore di flusso di lavoro, ma è necessario un ulteriore sviluppo del software.

Razionalizzazione dei diagrammi BPMN sovraccarichi di lavoro

Una dura realtà

Camunda è stato progettato per far sì che sviluppatori e analisti parlino la stessa lingua, ma spesso la realtà interviene.

I microservizi falliscono, gli utenti inseriscono dati errati, tutto può accadere. In questo caso, il bel diagramma analitico inizia a essere abbellito con vari gestori di errori, logger e percorsi alternativi. L'analista progetta uno schema bello, sintetico e comprensibile. Ha pochi delegati e fornisce percorsi logici per il flusso del processo in varie circostanze. Ecco come appare uno schema provvisorio quando arriva nelle mani di uno sviluppatore:

Tuttavia, ci sono degli aspetti negativi. Un tale schema potrebbe contenere una breve descrizione del compito, come "controllare il cliente", che implica diverse fasi, il processo decisionale basato su ciascun risultato e la compilazione delle decisioni derivate in un unico risultato, eventualmente con il successivo trasferimento di questo risultato a sistemi esterni.

È chiaro che a questo punto, sul diagramma o nel codice compaiono gestori di errori, logger ed elementi di servizio tecnico. In questo modo, un compito "analitico" nell'implementazione Java diventa voluminoso e complesso, oppure aumenta il numero di passi dello schema, ognuno dei quali è accompagnato da gestori e percorsi alternativi. Di conseguenza, lo schema diventa rapidamente contorto, difficile da supportare e modificare e l'aggiunta di nuove funzionalità può comportare la ristrutturazione di una vasta area dello schema e del codice dei delegati. In sostanza, contiene un numero enorme di elementi identici.

Ecco come potrebbe apparire lo schema precedente in un'installazione reale:

È chiaro che lo schema si è ampliato ed è diventato più macchinoso. Ma ci sono dei vantaggi: tutti i compiti sono diventati atomici e sono nati dei rami di comportamento in caso di errori.

Realizzare il problema

Se cerchiamo di separare e incapsulare lo schema e la logica aziendale del codice Java, possiamo fare come segue:

Evitare di duplicare elementi simili sullo schema.
Utilizzare un'implementazione universale e riutilizzabile dei delegati nel codice Java.
Ottimizzare e accelerare il flusso del processo.
Semplificare la gestione degli errori tecnici e stabilire una logica di comportamento del processo quando si presentano, quasi senza coinvolgere il codice Java. Ciò semplificherà notevolmente il debugging e l'analisi manuale dei processi falliti che si trovano in un incidente.
Ridurre drasticamente il numero di processi che "cadono" in incidenti quando si verificano eccezioni tecniche.
Gettare solide basi per un ulteriore sviluppo.

Per facilitare il lavoro con il prodotto è meglio scomporre lo schema in task atomici, ridurre il volume totale degli elementi dello schema, diminuire il numero di gestori di servizi, ridurre il volume di codice Java di ogni delegato e riutilizzare i delegati universali, effettuando un refactoring istantaneo quando necessario. Tutto questo implica automaticamente la scrittura di test unitari per tutti i delegati e i percorsi principali del processo.

Decomposizione e atomizzazione

Se si osserva attentamente l'applicazione di processo e si analizzano i suoi nodi, si possono notare molte funzioni ripetitive: interrogazioni a sistemi esterni, registrazione, gestione degli errori, invio di callback, ecc. In altre parole, occorre valutare criticamente l'applicazione di processo, individuare gli oggetti che possono essere facilmente incapsulati... Ma in cosa? Nel codice Java? No, sarebbe illogico, perché in questo caso lo schema sarebbe strettamente legato alla sua implementazione Java. In questa situazione, ha senso considerare i pool di processi.

Un pool di processi è uno schema di un processo separato che avrà un proprio contesto. È importante notare che è conveniente estrarre pezzi atomici di funzionalità dal processo principale in tali pool, così come tutti i momenti ripetitivi: invio di notifiche, richieste a sistemi esterni, ecc.

I pool di processi possono essere numerosi e sarebbe logico raggrupparli in modo tematico. Ad esempio, le interrogazioni a un particolare microservizio, gli avvisi, l'invio di varie notifiche. L'interazione tra questi pool può essere facilmente impostata utilizzando la messaggistica di Camunda. Ogni volta che un pool viene chiamato nel motore Camunda, viene passato un determinato messaggio contenente un'intestazione condizionale e il numero del processo padre per la restituzione della risposta, oltre a una serie di dati necessari per il funzionamento di questo specifico piccolo pool.

Qui vediamo come il processo principale (in basso) invia un messaggio a cui è abbonato l'iniziatore di un altro pool. Quando si verifica l'evento, il secondo pool avvia una nuova istanza del processo, effettua una richiesta e invia una risposta al processo principale, dopo di che lo completa con successo. Durante questo periodo, il processo principale attende l'evento di risposta dal pool esterno a cui ha inviato la richiesta. Quando il messaggio arriva, il processo continua. Se non c'è risposta entro l'intervallo di tempo specificato, il processo capisce che il calcolo esterno non è disponibile o è fallito e termina.

Cosa offre:

Opportunità di riutilizzo del codice. Se è necessario chiamare lo stesso codice più volte in condizioni diverse durante il processo, è possibile creare messaggi specifici e chiamare i pool di processi atomici corrispondenti;
Incapsulamento dello schema di implementazione del software dalla sua rappresentazione aziendale. Non importa come verrà ridisegnato lo schema principale o quali percorsi prenderà il processo. Tutte le interazioni sono già state spostate in processi minori separati, il che offre una flessibilità totale: basta formulare una richiesta e attendere la risposta.
Il numero e la probabilità di arresto del processo principale sono significativamente ridotti. Prima di questa divisione, il processo si trovava in un'incertezza di 4 stati:
La risposta è arrivata.
La risposta non è arrivata perché il microservizio esterno si è bloccato.
La risposta non è arrivata perché il processo principale si è bloccato durante l'invio della richiesta.
La risposta non è arrivata perché è stato superato un timeout.

Con questa divisione, il processo si trova sempre in un unico stato: la risposta è arrivata, oppure il processo ha atteso e si è concluso. Per il business, è importante come si è concluso esattamente il processo: se si è trattato di un errore o meno. Ma questa sarà una conclusione corretta, non un incidente. Questo è importante perché un processo non bloccato in un incidente non "consuma" risorse e gli errori possono essere facilmente registrati, le statistiche raccolte, gli avvisi impostati e analizzati.

Non importa più cosa succede ai processi minori. Possono fare quello che vogliono: bloccarsi, correre... È importante solo il risultato: la risposta della risorsa esterna. E anche in questo caso non sempre, perché il processo principale non dovrebbe garantire la funzionalità dei sistemi esterni. Ad esempio, potrebbe non avere senso che il processo attenda una risposta dal microservizio di notifica, perché potrebbe non esserci alcuna risposta.
La complessità del processo principale è notevolmente ridotta. La logica complessa può essere distribuita in piccoli pool separati, più facili da debuggare. Ad esempio, la verifica del client potrebbe avere un aspetto simile a questo:

In questo caso, possiamo notare che nel pool esterno vengono chiamati più task contemporaneamente. Approfondiamo questo punto.

Parallelizzazione dei calcoli di processo

Camunda consente l'esecuzione concorrente di rami di processi di calcolo. A questo scopo, esiste un gateway speciale chiamato Parallel Gateway, con il quale è possibile dividere il flusso in paralleli o unire più calcoli paralleli in un unico flusso. È chiaro che per accelerare il flusso di un processo, sarebbe vantaggioso delegare alcuni compiti a thread paralleli. Se la logica è indipendente, può essere eseguita in parallelo, ad esempio facendo richieste simultanee a sistemi esterni e aspettando le risposte da tutti in una volta:

Ogni volta che si trova un gateway di questo tipo, ci saranno costi generali associati alla creazione di nuovi thread per la divisione dei compiti e all'unione dei risultati. Si possono incontrare varie eccezioni di blocco e, naturalmente, non è sempre necessario o giustificato agire sempre in questo modo, soprattutto senza test, ma i vantaggi sono evidenti.

Con l'esecuzione sequenziale, il tempo di esecuzione totale equivale alla somma dei tempi di esecuzione di ciascuna operazione. Con l'esecuzione parallela, invece, equivale al tempo di esecuzione dell'operazione più lunga. Date le condizioni di risposte non istantanee da fonti esterne, tentativi e fallimenti, questa differenza è tutt'altro che insignificante. Un altro vantaggio innegabile è la forma di "tentativi gratuiti", cioè mentre viene eseguita la richiesta più lunga, gli altri task hanno ipoteticamente la possibilità di fallire più volte e tentare di ripetere le loro azioni senza impattare sul tempo di esecuzione complessivo del task.

Eccezioni e tentativi di ripetizione

Al verde? Succede. La versione standard di Camunda ha la capacità di riprovare una transazione fallita. Per "transazione" si intende il meccanismo interno di Camunda per l'esecuzione del codice delegato. L'inizio di una transazione può essere, ad esempio, il marcatore "async before" o "async after" di un task nel modellatore. Quando il motore incontra questo marcatore, esegue il commit delle informazioni nel database e avvia un nuovo thread asincrono. Questo è importante. Per approfondire, con "transazione" si intende la sezione di esecuzione tra le chiamate al metodo .complete() di TaskService, seguita dalla registrazione delle informazioni nel database. Queste transazioni, come altre, sono atomiche.

Quando si verifica un'eccezione tecnica, cioè un errore non commerciale, ad esempio la divisione per zero e la dimenticanza di un controllo di null, la transazione esegue un rollback e tenta di ricominciare. Per impostazione predefinita, questa operazione viene eseguita per tre volte consecutive senza alcuna pausa. Il tentativo di ripetizione inizia quando si verifica un'eccezione regolare, che nel mondo BPMN è chiamata eccezione tecnica, non BpmnError. Un BpmnError che si verifica arresta il processo senza alcun tentativo di riprova. Immaginate come questo migliora la resilienza del processo.

È ragionevole massimizzare questa caratteristica. Pertanto, su ogni delegato che richiede un sistema esterno, vengono impostati questi marcatori, specificando il numero di tentativi e la pausa tra di essi, e nel codice del delegato si separa la logica per quando il processo deve essere terminato e quando no. In questo modo si ha il pieno controllo sui meccanismi di gestione delle eccezioni e dei tentativi. Di conseguenza, il processo tenta di ripetere l'operazione fallita più volte e solo dopo una serie di fallimenti produce un errore.

Forse la sfida più grande è la gestione delle eccezioni tecniche e degli errori BPMN, nonché la progettazione della logica della loro gestione per un flusso continuo del processo. Abbiamo già discusso alcuni errori relativi alla gestione delle risposte da fonti esterne quando abbiamo parlato della suddivisione in pool di processi. Ricordiamo che la chiamata è stata incapsulata in un mini-processo separato e che quello principale ha ricevuto una risposta ed è andato avanti oppure, a causa di un timeout, ha seguito il percorso "Non ho ricevuto risposta".

Esaminiamo ora questo piccolo processo:

Vedete la cornice? È un sottoprocesso. Contiene compiti specifici e cattura gli errori lanciati dai compiti interni. Inoltre, su questi frame, l'esecutore del lavoro è in grado di creare un lavoro per il timer, che imposta il tempo di esecuzione per tutto ciò che si trova all'interno del sottoprocesso.

Come funziona? Il flusso di esecuzione raggiunge il sottoprocesso, crea un'elaborazione parallela del timer e attende il completamento di ciò che si trova all'interno oppure, se il timer si esaurisce per primo, segue il percorso del timer. Se durante il processo viene lanciata un'eccezione, che il frame del sottoprocesso cattura, il processo interrompe l'esecuzione sul ramo corrente e segue il ramo di errore.

È anche evidente che esiste un'opzione per creare dispacci di risposta per le richieste critiche. Si noti che la cattura degli errori funziona solo per i BpmnError con un codice specifico. Pertanto, tecnicamente, è essenziale catturare qualsiasi eccezione e lanciare un BpmnError con il codice richiesto, che funziona per l'evento ErrorBoundaryEvent.

La gestione degli errori nel processo principale funziona in modo simile. Da diversi task vengono individuate unità logiche che possono essere inserite in un frame di sottoprocesso, con un ascoltatore impostato per un codice di errore specifico. Ma qui ci sono due sfumature. La prima è che la creazione di più rami identici con gestione degli errori, che differiscono solo nel codice, è scomoda. Se la strategia di gestione degli errori cambia o, per esempio, la registrazione, molti delegati dello schema dovrebbero essere riprogettati, il che non è auspicabile. Per questo motivo, si potrebbe pensare a sottoprocessi basati su eventi.

In sostanza, si tratta di un sottoprocesso separato del pool di processi, che si avvia solo quando si verifica un determinato evento a cui è abbonato. Ad esempio, se si sottoscrive tale sottoprocesso all'evento BpmnError con un codice, ad esempio MyCustomBusinessError, quando si verifica questo evento, viene attivato il gestore e, al suo completamento, il processo si conclude correttamente. Sì, non è terminato con successo, ma è terminato correttamente. In questi sottoprocessi, si può anche implementare una logica di gestione diversa per lo stesso evento, a seconda delle condizioni esterne, ad esempio notificando facoltativamente un errore dell'applicazione quando il processo supera un punto condizionale.

La seconda sfumatura è molto più complicata. Nella vita reale, il ciclo di vita di ogni processo è probabilmente diviso in due fasi aziendali: prima della generazione di lead e dopo. Se si verificasse un errore prima che i dati vengano formattati in un lead, probabilmente il processo potrebbe essere semplicemente terminato, notificando le difficoltà incontrate. Una volta generato il lead, questo non è più possibile.

Inoltre, non consigliamo di terminare i processi se durante il processo sorgono obblighi legali, ad esempio se viene firmato un contratto. Come gestiamo gli errori? Alcuni errori tecnici, come quelli associati all'indisponibilità di servizi esterni, vengono gestiti con tentativi automatici entro un timeout prestabilito. Ma cosa succede se il processo si blocca, i tentativi sono passati, ma l'ipotetico microservizio esterno è ancora fuori uso?

Ottimizzazione manuale

Arriviamo al concetto di risoluzione manuale o, anche detto, di compensazione.

Come funziona? Qualsiasi errore viene rilevato, i delegati hanno la possibilità di riprovare, se necessario, e se la fortuna non li assiste, il processo passa in uno stato di errore, ma con il codice appropriato, ad esempio COMPENSATION_ERROR. Questo codice viene catturato da un altro sottoprocesso basato sugli eventi, che elabora, registra, notifica e, soprattutto, non può fallire inaspettatamente. Solo dove è stato progettato, lancia un'eccezione tecnica non catturabile e si blocca in un incidente.

Perché farlo in questo modo? Per il monitoraggio, è possibile utilizzare EXCAMAD, un pannello di amministrazione esterno per Camunda, analogo a Cockpit, con potenti funzioni. Evidenzia in rosso i processi in corso. Questi processi possono essere modificati o riavviati dal punto desiderato. Ad esempio, è possibile inserire il valore della variabile necessaria nel contesto e riavviare il processo dal punto immediatamente successivo a quello problematico. Si tratta di una soluzione comoda e semplice, che consente di risolvere manualmente i problemi con il minimo sforzo.

Automazione dei processi aziendali con Camunda: esempi di vita reale

Rinomata per la sua piattaforma open-source e l'interfaccia user-friendly, Camunda ha permesso a numerose aziende di ottimizzare i propri flussi di lavoro. Esploriamo alcuni esempi reali.

Banche e finanza

Münchener Hypothekenbank eG, una banca immobiliare indipendente ha deciso di utilizzare il motore di flusso di lavoro Camunda per migliorare e automatizzare i processi interni, in particolare la gestione della posta e il coordinamento interdipartimentale delle richieste di prestito. In precedenza, il sistema era rigido, poco flessibile e comportava complessità che aumentavano i tassi di errore.

Nel passaggio a un'architettura di microservizi basata su Java, l'azienda ha scelto Camunda sulla base di raccomandazioni interne e ha lavorato a stretto contatto con WDW Consulting Group. Alcuni vantaggi ottenuti immediatamente da Camunda erano funzioni già pronte, mentre altri richiedevano un maggiore sviluppo. Questa transizione ha portato a un elenco di attività centralizzato utilizzato da tutto il personale e ha fornito la flessibilità necessaria per mantenere i singoli processi senza influenzarne altri.

Il risultato più evidente è stato un significativo miglioramento della velocità di elaborazione delle richieste di prestito. Ne hanno beneficiato sia il personale che i clienti finali. A testimonianza del suo successo, altri dipartimenti stanno cercando di adottare Camunda e la banca ha persino assunto altri sviluppatori per supportare ulteriormente la sua implementazione.

Assicurazione

SV Informatik, una filiale di SV SparkassenVersicherung, è specializzata in soluzioni informatiche personalizzate per le compagnie di assicurazione. L'azienda ha incorporato Camunda per automatizzare diversi processi tra i vari reparti, ottenendo notevoli risparmi di tempo e migliorando i tempi di risposta ai clienti. L'azienda ha adottato Camunda nel 2018 come soluzione alla ricerca di un efficace strumento di modellazione dei processi aziendali, con l'obiettivo di migliorare i processi e incrementare la collaborazione tra l'IT e gli altri reparti.

Da quando è stato implementato, Camunda ha automatizzato attività come la cancellazione di polizze assicurative per autoveicoli e la richiesta di documenti di polizza. Un risultato degno di nota è stata l'elaborazione automatizzata 80% delle segnalazioni online dei danni causati dalle tempeste. Ciò si è rivelato particolarmente utile durante le inondazioni e le tempeste del 2021 in Germania. Strumenti come Camunda Optimize e Camunda Cockpit facilitano il monitoraggio e l'ottimizzazione dei processi.

Ospitalità

Nel 2020, il Gruppo SV, che opera in Germania, Svizzera e Austria, ha lanciato una piattaforma digitale dirompente chiamata "likeMagic" con l'assistenza di Camunda. Questa piattaforma ha fornito un'esperienza senza soluzione di continuità agli ospiti, dalla prenotazione al check-out, con risultati quali un tasso di auto-check-in/out del 95% e un punteggio di felicità degli ospiti pari a 9 su 10. L'innovazione ha ridotto le esigenze di personale e integrato piattaforme come Airbnb senza soluzione di continuità. L'innovazione ha ridotto il fabbisogno di personale e ha integrato perfettamente piattaforme come Airbnb. Riconoscendone il potenziale, SV Group ha offerto "likeMagic" ad altri fornitori di ospitalità. Entro il 2023, l'azienda è passata da 2 a oltre 30 clienti nella regione DACH, con l'obiettivo di ampliare la portata europea e di raggiungere 15.000 camere entro la fine dell'anno.

Conclusione

Il potenziale di trasformazione di Camunda non risiede solo nelle sue funzionalità principali, ma anche nella sua capacità di ridefinire le operazioni aziendali a livello fondamentale. In combinazione con Spring Boot, apre la strada a integrazioni senza soluzione di continuità e a una maggiore scalabilità. Per sfruttare appieno il potenziale di Camunda è fondamentale comprendere i dettagli di BPMN. Con l'evoluzione delle aziende nell'era digitale, gli strumenti come Camunda si distinguono per l'offerta di soluzioni dinamiche in grado di cambiare e adattarsi a esigenze in continua evoluzione. Non si tratta solo di automatizzare i processi, ma di innovare i flussi di lavoro, migliorare l'efficienza e ottenere risultati tangibili che fanno la differenza. Abbracciate la potenza di Camunda e lasciate che la vostra azienda si elevi verso nuovi orizzonti.

Dmitry Nazarevich CTO

Data: 17 gennaio 2024

Indice dei contenuti

Valuta questo articolo:

★★★★★ 4/5

4.8/5 (45 recensioni)

Contenuti correlati

Blog

Looker vs Power BI - Rivoluzionare l'industria delle piccole coperture

Confronto tra Looker e Power BI: svelare lo strumento di BI

Blog

Perché assumere sviluppatori software junior per i vostri progetti

Blog

Scegliere il giusto partner di nearshoring IT: consigli per i consulenti IT in Europa

Blog

Perché il vostro progetto rischia di fallire senza BA

Perché il vostro progetto rischia di fallire senza uno specialista BA

Blog

Perché i progetti IT falliscono

Contattateci

Nome

Azienda

Telefono

Messaggio Si prega di includere i dettagli del progetto, la durata, lo stack tecnologico, i professionisti IT necessari e altre informazioni pertinenti

Registra un messaggio vocale sul tuo
progetto per aiutarci a capirlo meglio

Allega ulteriori documenti se necessario

Caricare il file

È possibile allegare fino a 1 file di 2 MB complessivi. File validi: pdf, jpg, jpeg, png

Vi informiamo che cliccando sul pulsante Invia, Innowise tratterà i vostri dati personali in conformità con la nostra Informativa sulla privacy allo scopo di fornirvi informazioni adeguate.

Cosa succede dopo?

Dopo aver ricevuto ed elaborato la vostra richiesta, vi ricontatteremo a breve per illustrare le esigenze del progetto e firmare un NDA per garantire la riservatezza delle informazioni.

Dopo aver esaminato i requisiti, i nostri analisti e sviluppatori elaborano una proposta di progetto con l'ambito di lavoro, le dimensioni del team, i tempi e i costi stimati.

Organizziamo un incontro con voi per discutere l'offerta e giungere a un accordo.

Firmiamo un contratto e iniziamo a lavorare sul vostro progetto il prima possibile.

Automazione dei processi aziendali con Camunda: implementazione fault-tolerant di schemi BPM

Che cos'è Camunda?

Camunda, Spring Boot e BPMN: comprensione dei concetti