Kuinka elinkaarimallit ja tiladiagrammit vaikuttavat liiketoimintaprosessien ymmärtämiseen?

David Harel laajensi von Neumannin työtä ja esitteli tilakaavioiden käsitteen, joka käyttää graafisia merkintöjä järjestelmän tilojen ja siirtymien esittämiseen. Tilakaaviot saivat merkittävää huomiota 1980- ja 1990-luvuilla, erityisesti ohjelmistotekniikassa, ja niitä alettiin laajalti hyödyntää objektisuuntautuneen ohjelmistosuunnittelun mallinnustekniikkana. Yhtenäinen mallintamiskieli (UML) sisälsi tiladiagrammeille oman merkintätavan. Nykyisin tilakaavioita käytetään monilla eri alueilla, kuten ohjelmistotekniikassa, ohjaustekniikassa ja järjestelmäsuunnittelussa. Ne tarjoavat visuaalisen tavan kuvata monimutkaista käyttäytymistä, joka auttaa suunnittelijoita ymmärtämään järjestelmän käyttäytymistä, tunnistamaan mahdollisia ongelmia ja tarkentamaan suunnitelmia.

Esimerkiksi kuvassa 3.1 esitetty objektin elinkaarimalli täydentää käsitteellistä mallia. On selvää, että kaikkien käsitteellisten objektien operaatioiden tulisi olla järjestettyjä yhdeksi algoritmiksi, joka hahmottaa kunkin operaation roolin objektin elinkaaren kokonaisprosessissa. Tämä määrittely antaa käsitteellisesti merkityksen kullekin operaatiolle. Tässä valossa monet suositut objektitoiminnot, kuten give_list tai send_status, näyttävät järjettömiltä, aivan kuten ajatus viestien lähettämisestä objektien välillä – kuten esimerkiksi tilauksella ja tavaroilla – ei vastaa käsitteellisten objektien mallinnusta. Vaikka tällainen näkökulma voi olla hyödyllinen ohjelmointijärjestelmän objektien mallinnuksessa, se ei ole sovellettavissa käsitteellisiin objekteihin.

Tämä näkökulma tuo esiin riippuvuudet erilaisten objektien operaatioiden välillä, jotka eivät perustu pelkästään objektien välisiin olemassaoloyhteyksiin (esim. toimitustapa), vaan myös niiden elinkaaren rakenteeseen. Esimerkiksi se, että tavaroita ei tarvitse tilata, tukee mahdollisuutta siirtyä luotuna olleesta objektista suoraan poikkeusvaiheeseen. Vastaavasti tavaroiden mahdollisuus uudelleen tilata vastaa tilauksen täyttämisvaiheen iteraatiota. Laajemman ymmärryksen saamiseksi rakenteellisista riippuvuuksista, jotka ovat keskeisiä objektisuuntautuneen käsitteellisen mallinnuksen määrittämisessä, voidaan tutustua Jacksonin JSD-menetelmään. Jacksonin teoriaa käsitellään myös luvussa 5, jossa käsitellään niin kutsuttua rakenteellista johdonmukaisuutta.

Vaikka tilakaavioita käytetään yleisesti teknisten järjestelmien tilojen ja siirtymien kuvaamiseen, MMABP-menetelmä käyttää niitä muutosten kausaalisuuden ilmaisemiseen todellisessa maailmassa. Tämä lähestymistapa on lähempänä ontologisen mallinnuksen näkökulmaa kuin insinööritieteellistä lähestymistapaa. Tämän vuoksi on tärkeää ymmärtää eroja objektin elinkaaren ja järjestelmän käyttäytymisen välillä. Elinkaarimalli kuvaa kausaalisuutta, kun taas käyttäytyminen liittyy tarkoituksellisiin toimiin. Tämä erottelu ei välttämättä ole ilmeinen teknologisesta näkökulmasta, ja se liittyy usein käytävään keskusteluun tilakaavioiden ja Petri-verkkojen eroista.

Vaikka tilakaavioilla ja Petri-verkoilla on eri alkuperät ja lähestymistavat, niiden rakenteessa ja käsitteissä on paljon yhtäläisyyksiä. Molemmat käyttävät graafisia merkintöjä järjestelmän käyttäytymisen kuvaamiseen, nojaten tilojen, siirtymien ja tapahtumien peruskäsitteisiin. Teknologisesti voidaan nähdä, että tilakaaviot ovat erikoistunut versio Petri-verkoista, joissa tilat ja siirtymät on selkeästi esitetty, ja rinnakkaisuus ja synkronointi ovat implisiittisiä. On myös pyritty yhdistämään tilakaavioita ja Petri-verkkoja yhdeksi mallintamiskieleksi, hyödyntäen niiden täydentäviä vahvuuksia. David Harel ehdotti tätä integraatiota tilakaavioiden käytön laajentamiseksi reaktiivisten järjestelmien käyttäytymisen mallintamiseen.

Reaktiiviset järjestelmät, kuten Harel määrittelee, ovat järjestelmiä, jotka ovat jatkuvassa vuorovaikutuksessa ympäristönsä kanssa, aistivat ja reagoivat tapahtumiin ja muihin syötteisiin. Liiketoimintaprosessit voivat nähdä tämänlaisinä reaktiivisina järjestelminä, koska ne koostuvat toiminta- ja vuorovaikutusketjuista eri toimijoiden (esim. asiakkaat, työntekijät, järjestelmät) välillä, jotka reagoivat ympäristöstä tuleviin tapahtumiin tai syötteisiin, kuten asiakaspyyntöihin, järjestelmävikojen tai sääntelymuutosten takia. Liiketoimintaprosessin tila muuttuu näiden vuorovaikutusten ja syötteiden seurauksena, ja prosessin täytyy reagoida näihin muutoksiin saavuttaakseen omat tavoitteensa. Näin liiketoimintaprosessit voidaan nähdä reaktiivisina järjestelminä, jotka reagoivat ympäristöstään tuleviin tapahtumiin ja syötteisiin.

Liiketoimintaprosessien kuvaamista ei kuitenkaan tulisi pitää vain kausaalisuuden kuvauksena, vaan se on ennemminkin looginen osa todellista maailmaa. Tämän vuoksi on tärkeää erottaa liiketoimintaprosessi ja käsitteellisten objektien järjestelmä, joka on esitetty käsitemallissa. Tilakaavioiden käyttö käsitteellisessä mallinnuksessa ei saisi koskaan olla liiketoimintaprosessin tai sen infrastruktuurin, kuten koneiden tai IT-järjestelmien, kuvausta, vaan se on vain luonnollisen maailman logiikan ilmaisemista.

MMABP-menetelmä tukee tätä erottelua sääntöjen avulla, jotka koskevat tiladiagrammien käyttöä. Elinkaarimallin tulee kattaa objektin koko olemassaolo, ja sen tulee alkaa tapahtumalla, joka merkitsee objektin (luokkainstanssin) luomista ja kattaa kaikki mahdolliset päättymistilanteet objektin elämässä. Elinkaarimallin tulee olla algoritmisesti oikea, eli sen tulee ilmentää perusalgoritmisten ominaisuuksien, kuten yksiselitteisyyden, diskreettiyden ja äärellisyyden, periaatteita. Tilan tulee sisältää ainakin kaksi ulostulo-siirtymää, jotta tilasta saadaan erottuva ja jotta se voidaan liittää modaliteetteihin. Lisäksi objektin elinkaarimallin tulee olla yhteensopiva sen kontekstin kanssa, joka on määritelty luokkakaaviossa.

Miten mallintaa liiketoimintajärjestelmän käsitteet ja luokat

UML (Unified Modeling Language) tarjoaa työkalut, joilla voidaan mallintaa liiketoimintajärjestelmän luokat, niiden väliset yhteydet ja niihin liittyvät liiketoimintasäännöt. Yksi keskeinen käsite on monistettavuus (multiplicity), joka ilmaisee, kuinka monta objektia osallistuu tiettyyn assosiaatioon. Tämä monistettavuus määritellään usein intervallilla, jossa vasen puoli voi tarkoittaa suhteen osittaisuutta (esim. 0, * tai 1) ja oikea puoli määrittää suhteen kardinaalisuuden (esim. 1 tai *). Tämän avulla voidaan täsmällisesti määritellä, kuinka monta objektia liittyy toisiinsa ja kuinka monta objektia on pakollisia tai valinnaisia.

Assosiaatioluokat, kuten Ordered Book ja Restocked Book, voivat kuvata erillisiä liiketoimintasuhteita, joissa on omia attribuutteja ja toimintoja, jotka eivät suoraan liity kahteen pääluokkaan, vaan liittyvät muihin luokkiin tai muihin liiketoimintaprosesseihin. Esimerkiksi, kun kirjatilaukset liittyvät kirjanimikkeisiin, mutta kirjakaupan toiminta keskittyy yksittäisiin kirjan kappaleisiin, on tärkeää ymmärtää, että tilauksen ja varastonhallinnan välillä voi olla suuri ero käsitteellisesti, vaikka käytetään samoja termejä.

Tätä eroa voidaan kuvata käytännön esimerkin avulla: vaikka asiakas tilaa tietyn kirjan, kirjakauppa ostaa toimituksia eri kappaleina ja varastoi niitä. Siten kirjalla voi olla monia rooleja ja se voi olla joko luettelokappale (katalogikappale) tai fyysinen kirjan kappale (Book Copy). Tämä erottelu on keskeinen, kun tarkastellaan liiketoimintaprosessien sujuvuutta ja tietojen käsittelyn oikeellisuutta. Esimerkiksi tilauksen yhteydessä määritellään kirjanimikkeiden määrä, mutta pakettien yhteydessä puhutaan nimenomaan kappalemääristä.

Kun tarkastellaan luokkien operaatioita ja niiden syötteitä ja tulosteita, on tärkeää ymmärtää, miten tiedot kulkevat prosessien ja objektien välillä. Tämä voi ilmetä esimerkiksi taulukon avulla, joka kuvaa syötteitä ja tulosteita kunkin luokan operaatiolle. Taulukon täyttämisessä on tärkeää varmistaa, että kaikki tiedot, kuten syötteet ja tulosteet, ovat olemassa objektimallissa ja että ne vastaavat liiketoimintaprosessin todellisia tarpeita.

Liiketoimintamallin kehittämisessä on tärkeää pysyä käsitteellisellä tasolla, jotta mallin rakenne on selkeä ja ymmärrettävä ilman, että tarvitaan yksityiskohtaisia tietokannan tai ohjelmointirakenteiden tietoja. Mallin kehittämisessä kannattaa edetä rinnakkain prosessikartan kanssa, sillä liiketoimintaprosessit ja objektimalli ovat erillisiä, mutta niiden täytyy tukea toisiaan. Prosessikartassa kuvataan, kuinka liiketoiminnassa halutaan toimia, kun taas käsitemallissa kuvataan, kuinka asiat ovat nykyisellään.

Käsitemallin kehittäminen on jatkuva prosessi, jota on ylläpidettävä ja kehitettävä analyysin edetessä. Prosessin aikana on tärkeää tunnistaa objektit, luokat, niiden assosiaatiot ja roolit. Tämän lisäksi on tärkeää määritellä attribuutit ja operaatiot, jotka kuvaavat luokkien käyttäytymistä ja vuorovaikutusta toistensa kanssa. Näin varmistetaan, että mallin rakenne on johdonmukainen ja vastaa liiketoiminnan todellisia tarpeita.

Käsitemallin luominen etenee vaiheittain:

• Tunnista objektit liiketoimintaprosessista

• Tunnista luokat ja niiden väliset assosiaatiot

• Määrittele roolit ja attribuutit

• Kuvittele operaatioiden syötteet ja tulosteet

• Hio ja tarkenna mallia jatkuvasti prosessikartan ja liiketoiminnan muutosten myötä

On tärkeää ymmärtää, että mallintaminen ei ole kertaluonteinen tehtävä, vaan se on jatkuvaa kehitystä, jossa objektiluokkien ja niiden roolien analyysi auttaa hahmottamaan, kuinka liiketoimintajärjestelmä toimii kokonaisuudessaan.

Miten prosessien logiikkaa voidaan kehittää ja hallita monitasoisissa liiketoimintaympäristöissä?

Teknologiatason prosessivirrat ovat olennainen osa liiketoimintaprosessien kehittämistä ja hallintaa, erityisesti monimutkaisissa ja monivaiheisissa prosessijärjestelmissä, kuten kuljetus- ja logistiikkateollisuudessa. Tällaisessa ympäristössä prosessien muutos, erityisesti paralleelisten prosessien käsittely, on keskeinen haaste, joka vaikuttaa suoraan järjestelmien tehokkuuteen ja luotettavuuteen. Prosessien, kuten kuljetusten hallinnan, invertoiminen – eli perinteisen prosessilogikan kääntäminen – tarjoaa erinomaisen tavan tutkia ja kehittää järjestelmien toimintaa käytännössä.

Kun invertoitu versio kuljetusprosessista otetaan käyttöön ja siihen lisätään tapahtuma kuten "Aloita työpäivä", voidaan nähdä, kuinka järjestelmä toimii samoilla perusperiaatteilla kuin alkuperäiset prosessiversiot. Tämä mahdollistaa prosessin syvällisemmän tarkastelun ja samalla tarjoaa mahdollisuuden nähdä, kuinka sisäiset muuttujat hallitsevat kuljetusbatchien käsittelyä, mikä oli aiemmin näkyvissä Kuljetusbatchin hallinnan prosessissa. Tällainen lähestymistapa ei ainoastaan selkeytä järjestelmän toimintaa, vaan myös parantaa prosessimuutosten hallintaa ja turvallisuutta.

Erityisesti kuljetusbatchin käsittelylogiikan muuttaminen invertoidussa prosessiversiossa tuo esiin tärkeitä huomioita. Jos kuljetusbatch epäonnistuu toistamiseen, järjestelmään voidaan lisätä ihmispäätös, jossa valitaan joko batchin hylkääminen tai uusi yritys batchin kuljettamiseksi. Tämä poikkeaa alkuperäisestä automaattisesta hylkäyslogiikasta ja tuo inhimillisen elementin takaisin prosessiin. Tällainen muutos lisää joustavuutta ja varmistaa, että järjestelmä kykenee reagoimaan monenlaisiin tilanteisiin, jotka eivät ole pelkästään ennalta määriteltyjä.

Kun suoritetaan testejä, joissa useita rinnakkaisia batch-tilanteita käsitellään samanaikaisesti, järjestelmän kyky hallita niitä tehokkaasti on tärkeää. Testaamalla tilanteita, joissa päätös epäonnistuneen kuljetusbatchin käsittelyssä siirtyy ja muu prosessi etenee, voidaan arvioida, kuinka hyvin järjestelmä reagoi ja mukautuu uusiin olosuhteisiin. Tämä on kriittinen vaihe prosessimuutosten suunnittelussa, sillä se tarjoaa käytännönläheisen käsityksen siitä, miten prosessit voivat toimia monimutkaisissa ja dynaamisissa ympäristöissä.

Tällaiset kokeet ja testit vahvistavat sen, kuinka tärkeää on säilyttää alkuperäinen prosessilogiikka, kunnes muutokset on toteutettu ja testattu. Tämä lähestymistapa mahdollistaa muutosten tekemisen luonnollisesti ja turvallisesti, niin että ne ovat liiketoimintahenkilöille ymmärrettäviä ja helposti hallittavia. Prosessien monivaiheisen ympäristön ja niiden käsittelyn ymmärtäminen on elintärkeää, koska ilman tätä ymmärrystä on lähes mahdotonta tehdä tarvittavia muutoksia.

Kokeet osoittavat myös, että prosessimuutosten toteuttaminen prosessivetoisessa tietojärjestelmässä vaikuttaa vain minimaalisesti prosessimääritelmiin. Jos prosessijärjestelmän suunnittelu ja työtehtävien jakautuminen tukiprosesseille on hyvin toteutettu, muutokset vaikuttavat yleensä vain yhteen prosessimääritelmään, eikä se horjuta muiden prosessien toimintaa. Tämä puolestaan lisää muutosten turvallisuutta, koska se noudattaa tietojärjestelmäsuunnittelun perinteistä "minimaalisen kytkennän periaatetta".

Tämä kokeilun tulokset eivät ole vain teoreettisia; ne auttavat konkretisoimaan, kuinka liiketoimintaprosessien kehittämisessä ja hallinnassa voidaan parantaa turvallisuutta ja tehokkuutta ilman tarpeetonta monimutkaisuutta. Prosessimallien muuntaminen konseptitasolta teknologiatason prosessivirroiksi, kuten CAMUNDA-työkalun avulla, tarjoaa tarvittavat välineet, joiden avulla organisaatiot voivat prototyypata ja testata prosessimuutoksia ennen niiden täysimittaista käyttöönottoa. Tämä voi auttaa tunnistamaan ongelmakohtia ja optimoimaan prosessivirtoja ennen niiden laajempaa käyttöönottoa.

Tällöin on tärkeää huomioida, että teknologiatason mallien kehittäminen ei ole pelkkää ohjelmointia tai järjestelmän teknistä toteutusta. Se on myös osa liiketoimintaprosessien ymmärtämistä ja kehittämistä siten, että teknologia tukee liiketoiminnan tarpeita, ei päinvastoin. Tämä yhdistelmä liiketoimintatietoa ja teknistä osaamista on keskeinen, jos organisaatio haluaa pysyä kilpailukykyisenä ja sopeutua nopeasti muuttuviin markkinaolosuhteisiin.