5 min lukea

Liiketoimintaprosessien automatisointi Camundalla: BPM-järjestelmien vikasietoinen toteutus

BPMN

Comunda

Nykyisessä digitaalisesti ohjatussa maailmassa kilpailuedun säilyttäminen edellyttää virtaviivaistettuja ja tehokkaita liiketoimintaprosesseja. Automaatio on keskeinen ratkaisu tämän tavoitteen saavuttamiseksi. Statistan mukaan liiketoimintaprosessien hallinnan (BPM) markkinat ovat seuraavat odotetaan saavuttaa 14,4 miljardin Yhdysvaltain dollarin suuruisen määrän vuoteen 2025 mennessä. Camundan kaltaisten, joustavuudestaan ja skaalautuvuudestaan tunnettujen BPM-työkalujen kasvava suosio ja kysyntä ovat osoitus tästä suuntauksesta. Kun yritykset etsivät luotettavia työkaluja toimintojensa optimoimiseksi, Camunda nousee edelläkävijäksi ja viitoittaa tietä alan innovatiivisille, vikasietoisille automaatioratkaisuille.

Mikä on Camunda?

Yksinkertaisesti sanottuna Camunda on avoimen lähdekoodin alusta työnkulun ja päätöksenteon automatisointiin, joka tuo yhteen liiketoiminnan käyttäjät ja ohjelmistokehittäjät. Camunda tarjoaa vankkojen työkalujensa ja ominaisuuksiensa avulla tapoja suunnitella, toteuttaa ja optimoida BPMN-työnkulkuja (Business Process Model and Notation), mikä tekee liiketoiminnasta sujuvampaa ja läpinäkyvämpää.

Camunda, Spring Boot & BPMN: käsitteiden ymmärtäminen

Kolme keskeistä toimijaa on muokannut liiketoimintaprosessien hallinnan maisemaa: Camunda, Spring Boot ja BPMN. Kukin niistä on profiloitunut omalle kapealle alueelleen tarjoamalla ainutlaatuisia toimintoja, jotka käsittelevät prosessinhallinnan eri puolia. Yhdistettyinä ne muodostavat kuitenkin vertaansa vailla olevan voimanpesän, joka kykenee mullistamaan digitaalisen yritystoiminnan.

Camunda: Tämä ei ole vain yksi työkalu laajassa BPM-työkalupakissa, vaan se erottuu edukseen. Camunda on vankka avoimen lähdekoodin alusta, joka on erikoistunut työnkulkujen ja päätösten automatisointiin. Sen ensisijainen tavoite? Yhdistää saumattomasti liiketoimintastrategien ja ohjelmistokehittäjien maailmat. Näin se varmistaa, että liiketoimintaprosessien ideointi, suunnittelu ja toteutus ovat tehokkaita, läpinäkyviä ja yhtenäisiä.

Spring Saapas: Spring Saapas hyödyntää Spring-kehyksen vahvuuksia ja nostaa niitä. Tarjoamalla virtaviivaistetun menetelmän itsenäisen Java sovelluksista, siitä on tullut ensisijainen vaihtoehto kehittäjille, jotka haluavat minimoida paisuttelukoodin ja sukeltaa suoraan projektikohtaisten toiminnallisuuksien ytimeen. Sen vahvuus on sen joustavuudessa ja konfiguroinnin sijaan sovellettavassa konventio-lähestymistavassa, joka suosii älykkäiden oletusasetusten ideaa. Tämän lähestymistavan ansiosta kehittäjät voivat rakentaa skaalautuvia sovelluksia nopeammin ja varmistaa oikea-aikaisen toimituksen ja johdonmukaisen suorituskyvyn.

BPMN: Jos BPMN:ää pitäisi personoida, se olisi yritysmaailman kaunopuheinen kielimies. Maailmanlaajuisesti tunnustettuna standardina BPMN tarjoaa visuaalisen sanaston liiketoimintaprosessien luonnosteluun, jolloin ne ovat helposti ymmärrettävissä monille sidosryhmille. Tämä yleismaailmallinen kieli varmistaa, että prosessin tekniset vivahteet ovat ymmärrettävissä sekä tekniikkaan perehtyneelle koodaajalle että liiketoimintastrategille, mikä edistää yhteistoiminnallista vuoropuhelua ja tietoon perustuvaa päätöksentekoa.

Camundan automaatio-ominaisuuksien, Spring Bootin kehityksen helppouden ja BPMN:n standardoidun notaation synergia tarjoaa yrityksille dynaamisen kolmikannan. Yhdessä ne varmistavat, että BPM-suunnitelmat muuttuvat pelkistä teoreettisista paperikonstruktioista toimiviksi, todellisiksi toteutuksiksi. Lopputavoite? Kasvattaa liiketoimintaprosesseja, jotka ovat ketteriä, joustavia ja täydellisesti linjassa nykyaikaisen digitaalisen yritysmaailman kehittyvien vaatimusten kanssa.

Katso, mitä oheispalveluja tarjoamme

BPMN:n peruskomponentit

Niille, jotka eivät tunne BPMN:ää, sen keskeisten osien ymmärtäminen on ratkaisevan tärkeää. Nämä komponentit muodostavat kaikkien BPMN-kaavioiden perustan.

Tapahtumat

Nämä merkit tarkoittavat jotakin, joka tapahtuu prosessin aikana. Tapahtumat voivat aloittaa, keskeyttää tai lopettaa virtauksen, ja ne esitetään usein ympyröinä.

Portit

Portit hoitavat päätöksenteon prosessin sisällä. Olosuhteiden perusteella ne ohjaavat prosessin kulkua, ja ne on yleensä kuvattu timantteina.

Toiminta

Toiminnot edustavat tehtävää työtä. Ne voivat olla tehtäviä tai osaprosesseja, ja ne esitetään pyöristettyinä suorakulmioina.

Esineiden yhdistäminen

Nämä elementit, kuten sekvenssivirrat, viestivirrat ja assosioinnit, havainnollistavat prosessien järjestystä ja viestien kulkua.

Swimlanes

Nämä luokittelevat BPMN-elementit joko roolin (esim. johtaja, kirjanpitäjä) tai järjestelmän (esim. toiminnanohjausjärjestelmä) mukaan.

Esineet

Nämä tarjoavat lisätietoa prosessista. Yleisiä artefakteja ovat tieto-objektit, ryhmät ja huomautukset.

Camundan hyvät ja huonot puolet

Kuten mikä tahansa teknologinen ratkaisu, Camunda tuo mukanaan sekä etuja että haasteita. Tässä on kattava katsaus sen hyviin ja huonoihin puoliin.

Plussaa:

Joustava ja helppo integrointi Java-sovelluksiin Spring Bootin avulla.
Intuitiivinen mallinnusliittymä BPMN 2.0:lle.
Tarjoaa yksityiskohtaisia analyysejä prosessimittareista.

Miinukset:

Saattaa olla jyrkempi oppimiskäyrä ei-teknisille käyttäjille.
Se on vahva lähtökohta, mutta pidä sitä vain perustana - vaikka Camunda on tehokas työnkulkujärjestelmä, tarvitset silti lisää ohjelmistokehitystä.

Ylikuormitettujen BPMN-kaavioiden virtaviivaistaminen

Karu todellisuus

Camundan tarkoituksena on saada kehittäjät ja analyytikot puhumaan samaa kieltä, mutta usein todellisuus tulee väliin.

Mikropalvelut epäonnistuvat, käyttäjät syöttävät virheellisiä tietoja, mitä tahansa voi tapahtua. Tällöin kaunista analyyttistä kaaviota aletaan kaunistella erilaisilla virheenkäsittelijöillä, kirjaimilla ja vaihtoehtoisilla reiteillä. Analyytikko suunnittelee kauniin, ytimekkään ja ymmärrettävän kaavion. Siinä on muutama valtuutettu, ja se tarjoaa loogisia polkuja prosessin kululle eri olosuhteissa. Tältä alustava järjestelmä näyttää, kun se päätyy kehittäjän käsiin:

Sillä on kuitenkin myös haittapuolensa. Tällainen järjestelmä saattaa sisältää lyhyen tehtävänkuvauksen, kuten "tarkista asiakas", joka edellyttää useita vaiheita, päätöksentekoa kunkin tuloksen perusteella ja johdettujen päätösten kokoamista yhdeksi tulokseksi, joka mahdollisesti siirretään myöhemmin ulkoisiin järjestelmiin.

On selvää, että tässä vaiheessa virheenkäsittelijät, loggaajat ja teknisen palvelun elementit näkyvät kaaviossa tai koodissa. Näin yhdestä "analyyttisestä" tehtävästä Java-toteutuksessa tulee laaja ja monimutkainen, tai kaaviossa olevien vaiheiden määrä kasvaa, ja jokaiseen liittyy käsittelijöitä ja vaihtoehtoisia reittejä. Tämän seurauksena skeemasta tulee nopeasti monimutkainen, sitä on vaikea tukea ja muokata, ja uuden toiminnallisuuden lisääminen saattaa edellyttää laajan alueen uudelleenjärjestelyä sekä skeemassa että delegaattikoodissa. Pohjimmiltaan järjestelmä sisältää valtavan määrän identtisiä elementtejä.

Seuraavassa esitetään, miltä edellinen järjestelmä voisi näyttää todellisessa käytössä:

Järjestelmä on selvästi laajentunut ja muuttunut hankalammaksi. Mutta siitä on myös etunsa: kaikista tehtävistä on tullut atomisia, ja virheiden varalle on syntynyt käyttäytymishaaroja.

Ongelman ymmärtäminen

Jos yritämme erottaa ja kapseloida Java-koodin järjestelmän ja liiketoimintalogiikan toisistaan, voimme tehdä seuraavaa:

Vältä samankaltaisten elementtien päällekkäisyyttä järjestelmässä.
Käytä Java-koodissa universaalia ja uudelleenkäytettävää delegaattien toteutusta.
Optimoi ja nopeuta prosessin kulkua.
Yksinkertaistaa teknisten virheiden käsittelyä ja luoda prosessin käyttäytymislogiikka, kun virheitä ilmenee - lähes ilman Java-koodia. Tämä yksinkertaistaa huomattavasti häiriötilanteessa olevien epäonnistuneiden prosessien virheenkorjausta ja manuaalista analysointia.
Vähennä huomattavasti niiden prosessien määrää, jotka "kaatuvat" vaaratilanteisiin teknisten poikkeusten ilmetessä.
Luo vankka perusta jatkokehitykselle.

Jotta tuotteen kanssa työskentely olisi helpompaa, on parempi hajottaa järjestelmä atomaarisiksi tehtäviksi, vähentää järjestelmän elementtien kokonaismäärää, vähentää palvelunkäsittelijöiden määrää, vähentää kunkin delegaatin Java-koodin määrää ja käyttää uudelleen universaaleja delegaatteja ja suorittaa tarvittaessa välitöntä refaktorointia. Kaikki tämä tarkoitti automaattisesti yksikkötestien kirjoittamista kaikille delegaateille ja prosessin pääpoluille.

Hajoaminen ja atomisointi

Jos tarkastelet prosessisovellusta tarkkaan ja analysoit sen solmuja, voit havaita monia toistuvia toimintoja: kyselyt ulkoisiin järjestelmiin, kirjaaminen, virheenkäsittely, takaisinkutsujen lähettäminen jne. Toisin sanoen prosessisovellusta on arvioitava kriittisesti ja tunnistettava siitä kohteet, jotka voidaan helposti kapseloida... Mutta mihin? Java-koodiin? Ei, se olisi epäloogista, koska tässä tapauksessa järjestelmä olisi tiiviisti sidoksissa sen Java-toteutukseen. Tässä tilanteessa on järkevää harkita prosessipooleja.

Prosessipooli on erillisen prosessin järjestelmä, jolla on oma kontekstinsa. On huomionarvoista, että tällaisiin pooleihin on kätevää poimia pääprosessista atomisia toiminnallisuuden osia sekä kaikki toistuvat hetket: ilmoitusten lähettäminen, pyynnöt ulkoisiin järjestelmiin jne.

Prosessialtaita voi olla useita, ja olisi loogista ryhmitellä ne temaattisesti. Esimerkiksi kyselyt tietylle mikropalvelulle, hälytykset, erilaisten ilmoitusten lähettäminen. Vuorovaikutus tällaisten poolien välillä voidaan helposti toteuttaa Camunda-viestinvälityksen avulla. Aina kun tällaista poolia kutsutaan Camunda-moottorissa, välitetään tietty viesti, joka sisältää ehdollisen otsikon ja vanhemman prosessin numeron vastauksen palauttamista varten sekä joukon tämän tietyn pienen poolin toimintaa varten tarvittavia tietoja.

Tässä nähdään, miten pääprosessi (alhaalla) lähettää viestin, jonka toisen poolin aloittaja on tilannut. Kun tapahtuma tapahtuu, toinen pooli käynnistää prosessin uuden instanssin, tekee pyynnön ja lähettää vastauksen takaisin pääprosessille, minkä jälkeen prosessi päättyy onnistuneesti. Tänä aikana pääprosessi odottaa vastaustapahtumaa ulkoiselta poolilta, jolle se lähetti pyynnön. Kun viesti saapuu, prosessi jatkuu. Jos vastausta ei tule määritellyn ajan kuluessa, prosessi ymmärtää, että ulkoinen laskenta ei ole käytettävissä tai se on epäonnistunut, ja lopettaa.

Mitä tämä tarjoaa:

Mahdollisuus koodin uudelleenkäyttöön. Jos samaa koodia on kutsuttava useita kertoja eri olosuhteissa prosessin aikana, voit yksinkertaisesti luoda erityisiä viestejä ja kutsua niitä vastaavia atomisia prosessipooleja;
Ohjelmiston toteutussuunnitelman kapselointi sen liiketoimintaesityksestä. Sillä ei ole merkitystä, miten pääskeema suunnitellaan uudelleen tai mitä polkuja prosessi kulkee. Kaikki vuorovaikutus on jo siirretty erillisiin pienempiin prosesseihin, mikä antaa täydellisen joustavuuden: muodostetaan vain pyyntö ja odotetaan vastausta.
Pääprosessin kaatumisten määrä ja todennäköisyys vähenevät merkittävästi. Ennen tällaista jakoa prosessi oli epävarmassa 4 tilassa:
Vastaus on saapunut.
Vastausta ei tullut, koska ulkoinen mikropalvelu kaatui.
Vastaus ei tullut, koska pääprosessi kaatui pyynnön lähettämisen aikana.
Vastausta ei tullut, koska aikakatkaisu ylittyi.

Tällä jaolla prosessi on aina tiukasti yhdessä tilassa: vastaus joko tuli tai prosessi odotti ja päättyi. Liiketoiminnan kannalta on tärkeää, miten prosessi päättyi: oliko kyseessä virhe vai ei. Mutta tämä on oikea lopputulos, ei vaaratilanne. Tämä on tärkeää, koska prosessi, joka ei ole jumissa vaaratilanteessa, ei "kuluta" resursseja, ja virheet voidaan helposti kirjata, kerätä tilastoja, asettaa hälytyksiä ja analysoida.

Sillä ei ole enää väliä, mitä pienille prosesseille tapahtuu. Ne voivat tehdä mitä haluavat: kaatua, ajaa... Vain tulos on tärkeä: ulkoisen resurssin vastaus. Ja silloinkin, ei aina, koska pääprosessin ei pitäisi taata ulkoisten järjestelmien toimivuutta. Esimerkiksi prosessin ei ehkä ole mitään järkeä odottaa vastausta ilmoitusmikropalvelusta, koska vastausta ei ehkä tule lainkaan.
Pääprosessin monimutkaisuus vähenee huomattavasti. Monimutkainen logiikka voidaan jakaa erillisiin pieniin pooliin, jotka ovat helpommin korjattavissa. Esimerkiksi asiakkaan todentaminen voi näyttää seuraavalta:

Tässä näkyy, että ulkoisessa poolista kutsutaan useita tehtäviä samanaikaisesti. Tutustutaan tähän kohtaan syvällisemmin.

Prosessilaskennan rinnakkaistaminen

Camunda mahdollistaa prosessilaskennan haarojen samanaikaisen suorittamisen. Tätä tarkoitusta varten on olemassa erityinen yhdyskäytävä nimeltä Parallel Gateway, jonka avulla virta voidaan jakaa rinnakkaisiksi tai yhdistää useita rinnakkaislaskelmia yhdeksi virraksi. On selvää, että prosessivirran nopeuttamiseksi olisi edullista delegoida tiettyjä tehtäviä rinnakkaisille säikeille. Jos logiikka on riippumaton, se voidaan suorittaa rinnakkain, esimerkiksi tekemällä samanaikaisia pyyntöjä ulkoisille järjestelmille ja odottamalla vastauksia kaikilta järjestelmiltä kerralla:

Joka kerta tällaisessa yhdyskäytävässä syntyy yleiskustannuksia, jotka liittyvät uusien säikeiden luomiseen tehtävien jakamista varten ja tulosten yhdistämiseen. Erilaisia lukituspoikkeuksia voi tulla vastaan, eikä tietenkään ole aina tarpeen tai perusteltua toimia aina näin, varsinkaan ilman testausta, mutta hyödyt ovat ilmeiset.

Kun suoritus suoritetaan peräkkäin, kokonaissuoritusaika on yhtä suuri kuin kunkin operaation suoritusaikojen summa. Rinnakkaistoteutuksessa se sen sijaan vastaa pisimmän operaation suoritusaikaa. Kun otetaan huomioon olosuhteet, joissa ulkoiset lähteet eivät vastaa välittömästi, uusintayritykset ja epäonnistumiset, tämä ero on kaikkea muuta kuin merkityksetön. Toinen kiistaton etu on "vapaat uusintayritykset", eli kun pisintä pyyntöä suoritetaan, muilla tehtävillä on hypoteettisesti mahdollisuus epäonnistua useita kertoja ja yrittää tehdä toimintonsa uudelleen ilman, että se vaikuttaa tehtävän kokonaistoteutusaikaan.

Poikkeukset ja toistamisyritykset

Varaton? Niin käy. Camundan valmiissa versiossa on mahdollisuus yrittää epäonnistunutta tapahtumaa uudelleen. Tapahtumalla tarkoitamme Camundan sisäistä mekanismia, jolla suoritetaan delegaattikoodia. Transaktion alku voi olla esimerkiksi mallintajan tehtävän "async before" tai "async after" -merkki. Kun moottori kohtaa tämän merkin, se sitouttaa tietonsa tietokantaan ja käynnistää uuden asynkronisen säikeen. Tämä on tärkeää. Syvemmälle mentäessä "transaktiolla" tarkoitetaan TaskServicen .complete()-metodin kutsujen välistä suoritusosuutta, jonka jälkeen tiedot tallennetaan tietokantaan. Nämä transaktiot, kuten muutkin, ovat atomisia.

Kun tapahtuu tekninen poikkeus, eli mikä tahansa muu kuin liiketoimintavirhe, esimerkiksi jakaminen nollalla ja nollatarkistuksen unohtaminen, tapahtuma tekee rollbackin ja yrittää aloittaa uudelleen. Oletusarvoisesti se tekee tämän kolme kertaa peräkkäin ilman taukoja. Uusintayritys alkaa, kun syntyy tavallinen poikkeus, jota BPMN-maailmassa kutsutaan tekniseksi poikkeukseksi, ei BpmnErroriksi. Syntyvä BpmnError pysäyttää prosessin ilman uusintayrityksiä. Kuvittele, miten tämä parantaa prosessin joustavuutta.

On järkevää maksimoida tämä ominaisuus. Siksi jokaiselle ulkoista järjestelmää pyytävälle delegaatille asetetaan nämä merkit, joissa määritetään uusintayritysten määrä ja niiden välinen tauko, ja delegaattikoodissa erotetaan logiikka, joka määrittää, milloin prosessi on lopetettava ja milloin ei. Se antaa täydellisen hallinnan poikkeusten käsittelyyn ja uusintayrityksiin liittyviin mekanismeihin. Tämän seurauksena prosessi yrittää suorittaa epäonnistuneen tehtävän uudelleen useita kertoja, ja vasta useiden epäonnistumisten jälkeen se tuottaa virheen.

Ehkä suurin haaste on teknisten poikkeusten ja BPMN:ään liittyvien virheiden käsittely sekä niiden käsittelylogiikan suunnittelu prosessin jatkuvaa kulkua varten. Olemme jo käsitelleet joitakin ulkoisista lähteistä tulevien vastausten käsittelyyn liittyviä virheitä, kun puhuimme prosessipooleihin jakamisesta. Muistutamme, että juuri kyseinen kutsu kapseloitiin erilliseen miniprosessiin, ja pääprosessi joko sai vastauksen ja jatkoi eteenpäin tai aikakatkaisun vuoksi seurasi "en saanut vastausta" -reittiä.

Tarkastellaanpa nyt tätä hyvin pientä prosessia:

Näetkö kehyksen? Se on aliprosessi. Se sisältää tiettyjä tehtäviä ja ottaa talteen sisäisten tehtävien aiheuttamat virheet. Lisäksi tällaisissa kehyksissä työnsuorittaja pystyy luomaan ajastimelle tehtävän, joka asettaa suorituksen ajan kaikelle aliprosessin sisällä olevalle.

Miten se toimii? Suoritusvirta saavuttaa aliprosessin, luo rinnakkaisen ajastinkäsittelyn ja odottaa joko sen loppuunsaattamista, mikä on sisällä, tai jos ajastin loppuu ensin, se seuraa ajastimen reittiä. Jos prosessin aikana heitetään poikkeus, jonka aliprosessin kehys kaappaa, prosessi pysäyttää suorituksensa nykyiseen haaraan ja seuraa virhehaaraa.

On myös selvää, että kriittisiä pyyntöjä varten on mahdollisuus luoda vastauslähetyksiä. Huomaa, että virheiden sieppaus toimii vain BpmnError-virheille, joilla on tietty koodi. Siksi teknisesti on tärkeää ottaa kiinni mikä tahansa poikkeus ja heittää BpmnError vaaditulla koodilla, joka toimii ErrorBoundaryEventille.

Pääprosessin virheenkäsittely toimii samalla tavalla. Useista tehtävistä erotetaan loogisia yksiköitä, jotka voidaan sijoittaa aliprosessikehykseen, jossa on kuuntelija, joka on perustettu tiettyä virhekoodia varten. Tässä on kuitenkin kaksi vivahdetta. Ensimmäinen on se, että useiden samanlaisten haarojen luominen virheenkäsittelyn kanssa, jotka eroavat toisistaan vain koodin osalta, on hankalaa. Jos virheenkäsittelystrategia muuttuu tai esimerkiksi kirjautuminen muuttuu, monet järjestelmän delegaatit pitäisi suunnitella uudelleen, mikä ei ole toivottavaa. Siksi voisi harkita tapahtumapohjaisten aliprosessien tarkastelua.

Pohjimmiltaan kyseessä on prosessipoolin erillinen aliprosessi, joka käynnistyy vain, kun tietty tapahtuma, jonka se on tilannut, tapahtuu. Jos esimerkiksi tilaat tällaisen aliprosessin BpmnError-tapahtumalle koodilla, esimerkiksi MyCustomBusinessError, tämän tapahtuman sattuessa käsittelijä käynnistyy, ja sen valmistuttua prosessi päättyy oikein. Kyllä, se ei päättynyt onnistuneesti, mutta se päättyi oikein. Näissä aliprosesseissa voit myös toteuttaa samalle tapahtumalle eri käsittelylogiikan ulkoisista olosuhteista riippuen, esimerkiksi ilmoittaa valinnaisesti sovellusvirheestä, kun prosessi ohittaa ehdollisen pisteen.

Toinen vivahde on paljon monimutkaisempi. Todellisessa elämässä kunkin prosessin elinkaari jakautuu todennäköisesti kahteen liiketoimintavaiheeseen: ennen liidien tuottamista ja sen jälkeen. Jos virhe tapahtuu ennen kuin tiedot on muotoiltu liidiksi, prosessi voidaan todennäköisesti vain lopettaa ja ilmoittaa kohdatuista vaikeuksista. Kun lyijy on luotu, tämä ei ole enää mahdollista.

Emme myöskään suosittele prosessien lopettamista, jos prosessin aikana syntyy oikeudellisia velvoitteita, esimerkiksi jos sopimus allekirjoitetaan. Miten käsittelemme tällaisia virheitä? Jotkin tekniset virheet, kuten ulkoisten palveluiden käyttökyvyttömyyteen liittyvät virheet, käsitellään automaattisilla uusintayrityksillä ennalta sovitun aikarajan puitteissa. Mutta entä jos prosessi kaatuu, uusintayritykset ovat menneet, mutta hypoteettinen ulkoinen mikropalvelu on edelleen poissa käytöstä?

Manuaalinen optimointi

Tullaan käsitteeseen manuaalinen resoluutio tai, joka tunnetaan myös nimellä, korvaukset.

Miten se toimii? Kaikki virheet havaitaan, valtuutetuille annetaan mahdollisuus yrittää tarvittaessa uudelleen, ja jos onni ei edelleenkään suosi heitä, prosessi siirtyy virhetilaan, mutta asianmukaisella koodilla, esimerkiksi COMPENSATION_ERROR. Tämän koodin nappaa toinen tapahtumapohjainen aliprosessi, joka käsittelee, kirjaa ja ilmoittaa, eikä se voi epäonnistua odottamatta. Ainoastaan silloin, kun se on suunniteltu, se heittää kiinniottamattoman teknisen poikkeuksen ja kaatuu tapahtumapaikalle.

Miksi tehdä se tällä tavalla? Seurantaan voit käyttää EXCAMADia - Camundan ulkoista hallintapaneelia, joka on Cockpitin analogi ja jossa on tehokkaita ominaisuuksia. Se korostaa tapahtumissa olevat prosessit punaisella. Näitä prosesseja voidaan muuttaa tai käynnistää uudelleen halutusta kohdasta. Voit esimerkiksi sijoittaa tarvittavan muuttujan arvon kontekstiin ja käynnistää prosessin uudelleen heti ongelmakohdan jälkeisestä kohdasta. Tämä on kätevää, suoraviivaista ja mahdollistaa ongelman ratkaisemisen manuaalisesti pienellä vaivalla.

Liiketoimintaprosessien automatisointi Camundan avulla: käytännön esimerkkejä

Avoimen lähdekoodin alustastaan ja käyttäjäystävällisestä käyttöliittymästään tunnettu Camunda on antanut lukuisille yrityksille mahdollisuuden optimoida työnkulkujaan. Tutustutaanpa muutamaan tosielämän esimerkkiin.

Pankkitoiminta ja rahoitus

Münchener Hypothekenbank eG, riippumaton kiinteistöpankki, siirtyi käyttämään Camunda-työnkulkujärjestelmää sisäisten prosessien tehostamiseen ja automatisointiin, erityisesti postin käsittelyyn ja osastojen väliseen lainahakemusten koordinointiin. Aiemmin heidän järjestelmänsä oli jäykkä, joustamaton ja monimutkainen, mikä lisäsi virheiden määrää.

Siirtyessään kohti Java-pohjaista mikropalveluarkkitehtuuria he valitsivat Camundan sisäisten suositusten perusteella ja tekivät tiivistä yhteistyötä WDW Consulting Groupin kanssa. Jotkin edut, jotka he saivat välittömästi Camundasta, olivat valmiita toimintoja, kun taas toiset vaativat enemmän kehittämistä. Siirtyminen johti koko henkilöstön käyttämään keskitettyyn tehtäväluetteloon ja tarjosi joustavuutta yksittäisten prosessien ylläpitämiseen vaikuttamatta muihin.

Merkittävin tulos on ollut lainahakemusten käsittelynopeuden merkittävä paraneminen. Tästä hyötyvät sekä henkilökunta että loppuasiakkaat. Menestyksen osoituksena muutkin osastot haluavat nyt ottaa Camundan käyttöön, ja pankki on jopa palkannut lisää kehittäjiä tukemaan sen käyttöönottoa.

Vakuutus

SV Informatik, SV SparkassenVersicherungin tytäryhtiö, on erikoistunut vakuutusyhtiöiden räätälöityihin IT-ratkaisuihin. He ottivat Camundan käyttöön automatisoidakseen erilaisia prosesseja eri osastoilla, mikä johti huomattaviin ajansäästöihin ja parempiin asiakaspalveluaikoihin. Yritys otti Camundan käyttöön vuonna 2018 ratkaisuna tehokkaan liiketoimintaprosessien mallinnustyökalun etsintään, jossa keskityttiin prosessien parantamiseen ja IT:n ja muiden osastojen välisen yhteistyön tehostamiseen.

Käyttöönoton jälkeen Camunda on automatisoinut tehtäviä, kuten liikennevakuutusten peruutuksia ja asiakirjapyyntöjä. Merkittävä saavutus oli 80% myrskyvahinkoraporttien automaattinen käsittely verkossa. Tämä osoittautui erityisen arvokkaaksi vuoden 2021 tulvien ja myrskyjen aikana Saksassa. Työkalut, kuten Camunda Optimize ja Camunda Cockpit, helpottavat prosessien seurantaa ja optimointia.

Vieraanvaraisuus

Vuonna 2020 SV Group, joka toimii Saksassa, Sveitsissä ja Itävallassa, lanseerasi Camundan avustuksella mullistavan digitaalisen alustan nimeltä "likeMagic". Alusta tarjosi saumattoman asiakaskokemuksen varauksesta uloskirjautumiseen, ja sen tuloksiin kuuluivat muun muassa 95%-itse sisään-/uloskirjautumisaste ja 9 pistettä 10:stä vieraiden tyytyväisyyspisteytyksessä. Innovaatio vähensi henkilöstötarvetta ja integroi Airbnb:n kaltaiset alustat saumattomasti. Tunnistaessaan sen potentiaalin SV Group tarjosi "likeMagicia" muille majoituspalvelujen tarjoajille. Vuoteen 2023 mennessä he laajensivat toimintaansa kahdesta asiakkaasta yli 30 asiakkaaseen DACH-alueella, ja suunnitelmissa on laajentaa Euroopan kattavuutta ja tavoitella 15 000 huonetta vuoden loppuun mennessä.

Pakkaaminen

Camundan mullistava potentiaali ei piile vain sen ydintoiminnoissa, vaan sen kyvyssä määritellä liiketoiminta uudelleen perustavanlaatuisella tasolla. Yhdessä Spring Bootin kanssa se avaa oven saumattomille integraatioille ja paremmalle skaalautuvuudelle. BPMN:n pähkinöiden ja pulttien ymmärtäminen on ensiarvoisen tärkeää Camundan koko potentiaalin hyödyntämiseksi. Kun yritykset kehittyvät digitaaliaikana, Camundan kaltaiset työkalut erottuvat edukseen, sillä ne tarjoavat dynaamisia ratkaisuja, jotka pystyvät kääntymään ja mukautumaan jatkuvasti muuttuviin tarpeisiin. Kyse ei ole vain prosessien automatisoinnista, vaan työnkulkujen innovoinnista, tehokkuuden parantamisesta ja konkreettisten tulosten aikaansaamisesta, joilla on merkitystä. Hyödynnä Camundan voima ja anna yrityksesi kohota uusiin ulottuvuuksiin.

Dmitri Nazarevitš CTO

Päivämäärä: tammikuu 17, 2024

Sisällysluettelo

Arvioi tämä artikkeli:

★★★★★ 4/5

4.8/5 (45 arvostelua)

Ota yhteyttä

Varaa puhelu tai täytä alla oleva lomake, niin otamme sinuun yhteyttä, kun olemme käsitelleet pyyntösi.

Nimi

Yritys

Sähköposti

Puhelin

Viesti

Lähetä meille ääniviesti

Liitä asiakirjoja

Lataa tiedosto

Voit liittää 1 enintään 2 Mt:n tiedoston. Hyväksytyt tiedostomuodot: pdf, jpg, jpeg, png.

Klikkaamalla Lähetä, annat suostumuksesi siihen, että Innowise käsittelee henkilötietojasi meidän Tietosuojakäytäntö antaa sinulle asiaankuuluvia tietoja. Antamalla puhelinnumerosi suostut siihen, että voimme ottaa sinuun yhteyttä puheluiden, tekstiviestien ja viestisovellusten kautta. Puhelu-, viesti- ja datahintoja voidaan soveltaa.

Voit myös lähettää meille pyyntösi
osoitteeseen contact@innowise.com

Mitä tapahtuu seuraavaksi?

Kun olemme vastaanottaneet ja käsitelleet pyyntösi, otamme sinuun yhteyttä ja kerromme yksityiskohtaisesti projektin tarpeet ja allekirjoitamme NDA-sopimuksen luottamuksellisuuden varmistamiseksi.

Tutkittuaan toiveesi, tarpeesi ja odotuksesi tiimimme suunnittelee projektin ehdotuksen, jossa esitetään työn laajuus, tiimin koko, aika- ja kustannusarviot.

Järjestämme kanssasi tapaamisen, jossa keskustellaan tarjouksesta ja sovitaan yksityiskohdista.

Lopuksi allekirjoitamme sopimuksen ja aloitamme projektisi toteuttamisen heti.

Liiketoimintaprosessien automatisointi Camundalla: BPM-järjestelmien vikasietoinen toteutus

Mikä on Camunda?