Liiketoimintaorganisaation toiminnan analysointi ja rakenteen ymmärtäminen vaatii tarkkaa lähestymistapaa, jossa erilaisten mallien käyttö on keskeistä. Yksi tehokkaimmista tavoista on käyttää neljän tason prosessien abstraktiota, joka mahdollistaa liiketoimintaprosessien ja -toimintojen selkeän jäsentämisen ja optimoinnin. Tämä lähestymistapa perustuu yksinkertaisten mutta monivaiheisten mallien hyödyntämiseen, jotka auttavat analyytikkoa saamaan kokonaiskuvan liiketoiminnan toiminnasta sekä sen sisäisistä ja ulkoisista suhteista.

Ensimmäinen tärkeä malli on liiketoiminnan funktioiden kartta, joka kuvaa yrityksen toiminnan rakenteen. Tämä malli, joka on lähellä perinteistä johtamiskäsitystä, mahdollistaa yrityksen prosessien organisoinnin ja jakamisen eri osa-alueisiin eli niin sanottuihin yrityksen alueisiin. Tällainen jäsentely tukee prosessilähtöistä ajattelua ja on keskeinen periaate, joka mahdollistaa liiketoimintajärjestelmän optimaalisten osien tunnistamisen.

Liiketoimintaprosessien kartta puolestaan kuvaa prosessien järjestelmän, joka määrittää toimijoiden käyttäytymisen tietyssä liiketoiminta-alueessa. Näissä prosessikartoissa erotellaan kaksi perusprosessityyppiä: avainprosessit ja tukiprosessit. Tämä jaottelu on tärkeä, koska se osoittaa, että jokaisessa liiketoiminta-alueessa on paikallisia avain- ja tukiprosesseja riippumatta siitä, onko alueella itsellään keskeinen vai tukeva rooli koko yrityksen järjestelmässä. Tällainen suhteellisuus tukee prosessilähtöistä ajattelua, kuten ulkoistamisen periaatetta. Liiketoimintaprosessikartalla voidaan esittää liiketoimintaprosessit ja -toiminnot joko erikseen tai toisiinsa kytkettyinä, kuten esimerkissä kirjatilauksen prosessissa.

Toinen keskeinen malli on prosessivaiheiden malli, joka kuvaa tietyn liiketoimintaprosessin algoritmista logiikkaa. Tämä malli perustuu yhteistyöhön muiden prosessien ja toimijoiden kanssa. Prosessivaiheiden jakaminen useiksi osiksi on tärkeää, sillä se mahdollistaa prosessien synkronoinnin ympäristön kanssa. Ulkoiset tekijät, kuten tietyt tapahtumat, jotka odottavat prosessin etenemistä, ovat prosessin osia, joissa tapahtuu synkronointia.

Kolmas malli, tehtävämalli, tarkentaa prosessivaiheiden sisäistä rakenteellista logiikkaa. Se määrittää yksittäisten prosessivaiheiden sisällön ja osoittaa, kuinka prosessin tehtävät ovat yhteydessä toisiinsa ja muihin liiketoiminnan objekteihin. Tehtävämalli ei pelkästään kuvasta prosessivaiheen lähempää tasoa, vaan se ottaa myös huomioon liiketoimintajärjestelmän kausaaliset yhteydet, erityisesti niin sanottujen objektin elinkaarimallien osalta.

Näiden kolmen mallin avulla analyytikko voi luoda yksityiskohtaisia prosessimalleja, jotka voivat toimia joko erillään tai osana hierarkisesti kytkettyä kokonaisuutta. Tämä neljän tason prosessimallien järjestelmä auttaa välttämään intuitiiviseen lähestymistapaan liittyviä riskejä ja virheitä, jotka voivat johtaa epäjohdonmukaisiin ja virheellisiin johtopäätöksiin. Malli on eksplisiittinen, ja se tukee johdonmukaisen prosessimallin tuottamista, jossa jokaisella tasolla on tarkasti määritelty sisältö ja merkitys.

Liiketoimintaprosessien ja -toimintojen kartoituksessa keskeistä on muistaa, että prosessikartalla ei pyritä kuvaamaan kaikkia prosessien jakamia tietoja, vaan enemmänkin prosessien välisiä synkronointikohtia ja suhteita. Prosessikartta toimii globaalina mallina, ja sen tarkoitus on antaa yleiskuva liiketoiminnan prosesseista ja niiden suhteista toisiinsa. Tähän liittyen, prosessikartan avulla voi määrittää, mikä analyysin kohde on ja minkälaista tarkempaa analyysiä vaaditaan myöhemmissä vaiheissa.

Tärkeää on myös huomata, että vaikka prosessikartta toimii yleisellä tasolla, sen soveltaminen yksityiskohtaisiin prosessianalyyseihin vaatii tarkempaa lähestymistapaa, kuten prosessivaiheiden ja tehtävien yksityiskohtaisen kuvauksen. Tällöin voidaan huomioida tarkemmin prosessien sisäiset vuorovaikutukset ja synkronointikohtia, joita perinteinen prosessikartta ei paljasta.

Lopuksi, prosessimallien kehittäminen on jatkuva ja syklinen prosessi, jossa eri tasojen ja mallien yhteensovittaminen on välttämätöntä. Täsmälliset abstraktiotason säännöt ja selkeät prosessikartat eivät ainoastaan paranna liiketoimintaprosessien ymmärtämistä, vaan myös vähentävät virheiden mahdollisuutta ja auttavat optimoimaan koko liiketoimintajärjestelmän.

Miten liittää liiketoimintaprosessit ja niiden suhteet prosessikarttaan ja mallintamiseen

Liiketoimintaprosessi on sarja toimintoja, jotka on suunniteltu tuottamaan kohdeulostulo (tuote tai palvelu), joka täyttää asiakkaan tarpeet. Tämä prosessi kattaa koko syklin tarpeen ilmaisusta sen tyydyttämiseen tuotteen tai palvelun avulla. Liiketoimintaprosessilla on selkeä alku ja loppu, ja se pyrkii saavuttamaan tietyn tavoitteen, joka ei ole itsestäänselvä. Vaikka tarve voi olla eksplisiittinen (esimerkiksi tilaus), se voi olla myös implisiittinen (esimerkiksi tapahtuma, jonka ratkaiseminen määritellään palvelutason sopimuksessa).

Liiketoimintaprosessit voidaan kuvata prosessikartassa, jossa ne esitetään kuvina, jotka auttavat hahmottamaan ja hallitsemaan prosessien monimutkaisuutta ja niiden vuorovaikutuksia. Prosessikartassa on aina määriteltävä sekä prosessia laukaisevat tapahtumat että prosessin tavoitetila. Prosessikartan tehtävä on siis keskittyä prosessin tavoitteeseen eikä niinkään syventää yksityiskohtiin, joita tarvitaan, jos prosessia ei saavuteta halutussa muodossa. Tämä lähestymistapa eroaa esimerkiksi prosessivirtojen mallinnuksesta, jossa huomioidaan myös prosessin epäonnistumiset ja mahdolliset poikkeavat lopputilat.

Liiketoimintaprosessien mallintamisessa on tärkeää huomioida, että kaikki prosessit eivät ole itsenäisiä. Usein prosessi tukee toista, ja tätä tukevaa prosessia tulee käsitellä erikseen prosessikartassa. Tukiprosessit eivät ole piilotettuja osia pääprosesseista, vaan ne on selkeästi määriteltävä. Esimerkiksi tukiprosessi saattaa käynnistyä jonkin toisen prosessin seurauksena, mutta pääprosessi voi olla siinä vaiheessa kiinnostunut vain tukiprosessin lopputuloksesta, ei sen etenemisestä.

Prosessikartan avulla voidaan kuvata prosessien välinen synkronointi. Synkronointi voi tapahtua prosessin alussa, lopussa tai jopa rinnakkain. Esimerkiksi tukiprosessi saattaa käynnistyä, mutta pääprosessi ei ole enää kiinnostunut sen etenemisestä. Tällaisessa tapauksessa synkronointi voidaan mallintaa niin, että pääprosessi odottaa vain tukiprosessin lopputulosta. Prosessikartan tehtävänä ei ole syventyä kaikkiin mahdollisiin prosessien lopputiloihin, vaan keskittyä niiden tavoitetiloihin. Yksityiskohtaisempia poikkeamia käsitellään erillisissä prosessivirta-analyyseissä.

Kun luodaan prosessikarttaa, liiketoimintaprosessit on yleensä aloitettava keskeisistä prosesseista. Tärkeiden liiketoimintaprosessien tunnistaminen on aina ensimmäinen askel, jonka jälkeen voidaan analysoida tukevia liiketoimintafunktioita ja niiden suhteita pääprosesseihin. Liiketoimintafunktiot voidaan kuvata prosessikartassa osittain tai kokonaan, riippuen analyysin tarpeesta ja vaadittavasta yksityiskohtaisuudesta. Esimerkiksi prosessikartta voi toimia niin sanottuna kyvykkyyskarttana, jossa pääprosessi on aina keskiössä.

Liiketoimintaprosessien ja liiketoimintafunktioiden analysointi ei ole kertaluonteinen tehtävä, vaan iteratiivinen prosessi, jossa muutokset yhdessä osassa liiketoimintamallia voivat vaikuttaa muihin osiin. Mallin luominen on siis jatkuvaa tarkentamista, joka vaatii jokaisen yksityiskohdan huolellista huomioon ottamista. Tämä toimenpide ei ole vain teoreettista mallintamista vaan käytännön työkalu, joka auttaa liiketoimintaprosessien hallinnassa ja niiden tehostamisessa. Tärkeintä on, että mallinnus ei jää pelkästään teoreettiseksi, vaan se tukee organisaation toiminnallista ja strategista päätöksentekoa.

Kuinka luoda objektin elinkaarimalli ja ymmärtää sen vaiheet liiketoiminnan suunnittelussa

Objektin elinkaarimallin luominen on keskeinen osa liiketoimintaprosessien analysointia ja suunnittelua. Tämä malli kuvaa, kuinka objekti siirtyy eri tiloista toiseen sen elinkaaren aikana. On tärkeää huomata, että UML:n (Unified Modeling Language) salliessa eri tilojen haarautumisen ja yhdistämisen, tällaisia symboleja ei pitäisi käyttää siirtymien kuvaamiseen. Sen sijaan on suositeltavaa käyttää suoria siirtymiä kahden tilan välillä, sillä tämä antaa tarkempaa ja selkeämpää kuvaa objektin tilojen muutoksista.

Elinkaarimallissa siirtymät objektin tilasta toiseen eivät ole sattumanvaraisia; niiden täytyy perustua tapahtumiin. Nämä tapahtumat voivat olla joko muutoksia muissa objekteissa (esimerkiksi tilan tai olosuhteiden muutoksia) tai ajan kulumista, joka voi olla joko suhteellista tai absoluuttista. On tärkeää, että objektin elinkaarimallissa oleva siirtymäoperaatio on olemassa oleva operaatio, joka löytyy kyseisen luokan luokkamallista. Tämä operaatio liittyy yleensä luokan objektin elinkaaren aikana tapahtuvaan tilan tai ominaisuuden muutokseen.

Mikäli elinkaaren aikana on useita objekteja eri luokista, niitä ei tulisi yrittää yhdistää yhdeksi elinkaareksi. Sen sijaan kannattaa hyödyntää rinnakkaisia tiloja, jotka voivat paljastaa uuden objektin. Tämä on erityisen tärkeää monimutkaisissa liiketoimintaprosesseissa, joissa useat objektit voivat olla vuorovaikutuksessa keskenään samanaikaisesti.

Objektin elinkaarimallin luomisessa ensimmäinen askel on tarkastella objektin tiloja, jotka on tunnistettu prosessikuvauksessa. Nämä tilat voivat olla suoraan liitettyjä tapahtumiin, jotka liittyvät esimerkiksi tehtäviin tai päätöksentekotilanteisiin. Tila-analyysi on keskeinen osa tätä prosessia, sillä monet prosessit käsittelevät samaa objektia, mikä voi johtaa siihen, että elinkaaritiedot ovat hajallaan eri osissa mallia. Tästä syystä on tärkeää koota ja järjestää nämä tiedot luokkakohtaisesti.

Seuraava askel on päättää, mitkä elinkaarimallit ovat olennaisia liiketoiminnan kannalta. Yleisesti ottaen on tarpeen mallintaa kaikki elinkaarimallit, joiden tilat on mainittu prosessimallissa, mutta joissakin tapauksissa tietyt objektit voivat olla vähemmän tärkeitä analyysin kannalta, ja niitä voidaan jättää pois. Elinkaarimallin luomisen peruskriteeri on objektiin liittyvä ei-triviaali kausaliteetti, joka on sidoksissa objektin olemassaoloon.

Kun elinkaarimallit on valittu, seuraavaksi tulee tarkastella, milloin olennainen luokka syntyy ja mitä alkuperäistä tilaa sen elinkaarelle on määritelty prosessimallissa. Jos alkuperäinen tila puuttuu, on tärkeää miettiä, onko tälle tilalle olemassa konkreettinen syy. Mikäli ei, se tulisi lisätä malliin oikean tehtävän avulla.

Lisäksi on tärkeää mieltää, kuinka objekti reagoi erilaisiin tapahtumiin. Tämä tarkoittaa sitä, että analysoidaan, mitkä tilat johtavat objektin tilan muutoksiin ja mitä operaatioita tulee suorittaa, jotta tämä siirtymä toteutuu. Tätä prosessia kutsutaan objektin tilojen ja siirtymien analyysiksi. Objektin elinkaaren mallinnuksessa on muistettava, että tilojen välisten siirtymien tulee olla selkeitä ja niiden tulee liittyä liiketoimintaprosessin kulkuun.

Kaikki objektin elinkaaren siirtymät ja niiden tapahtumat tulee dokumentoida. On tärkeää ottaa huomioon sekä ne tapahtumat, jotka aiheuttavat objektin tilan muutoksen, että ne, jotka vievät objektin saman tilan kautta eteenpäin ilman tilan muutosta. Tämä yksityiskohtainen tarkastelu auttaa varmistamaan, että objekti käyttäytyy liiketoimintaprosessissa odotetusti, eikä elinkaarimallin mukana tule yllätyksiä.

Lopuksi on olennaista ymmärtää, että vaikka elinkaarimallien luominen saattaa vaikuttaa yksinkertaiselta prosessilta, se on todella monivaiheinen ja vaatii huolellista pohdintaa. Mallin luominen ei ole vain tekninen tehtävä, vaan se liittyy tiiviisti liiketoiminnan ymmärtämiseen ja sen toiminnan tarkkaan analysointiin. Tämän takia on tärkeää, että elinkaarimallit eivät jää vain teoreettisiksi, vaan ne liitetään suoraan liiketoimintaprosesseihin ja niiden tarpeisiin.

Miten prosessivetoisen organisaation rakentaminen edistää liiketoiminnan joustavuutta ja vakautta?

Prosessivetoisen organisaation toteuttaminen vaatii tarkkaa tasapainon hakemista dynaamisten keskeisten prosessien ja vakautta ylläpitävien tukiprosessien välillä. Tämä tasapaino on keskeinen elementti organisaation kyvykkyyden ja resilienssin rakentamisessa. Resilienssi puolestaan edellyttää, että keskeiset prosessit ovat joustavia ja mukautuvat nopeasti asiakkaiden tarpeisiin ja teknologian kehitykseen. Toisaalta vakaus vaatii liiketoiminta-alueen täsmällistä ontologista mallia, joka mahdollistaa organisaation johdonmukaisen toiminnan muuttuvassa ympäristössä.

Prosessivetoisen liiketoimintajärjestelmän rakentamisessa tietojärjestelmillä on tärkeä rooli. Erityisesti se, kuinka keskeiset ja tukiprosessit käsitellään ja miten nämä prosessit integroidaan organisaation tieto- ja toimintajärjestelmiin, määrittelee organisaation toiminnan tehokkuuden ja kyvyn sopeutua muuttuviin tarpeisiin. Keskeisten prosessien hallinta vaatii erityistä huomiota ja erilaista lähestymistapaa kuin tukiprosessit. Tukiprosessit voidaan usein määritellä vakioiduiksi palveluiksi, mutta keskeiset prosessit, jotka ovat elintärkeitä organisaation joustavuuden kannalta, vaativat jatkuvaa kehittämistä ja teknologista sopeutumista.

Prosessivetoisten liiketoimintajärjestelmien tärkein haaste on, miten yhdistää vakioitu ERP-järjestelmä, joka huolehtii perustoimintojen hallinnasta, ja dynaamiset työkulun hallintajärjestelmät, jotka seuraavat reaaliaikaisia prosesseja. Tämän yhdistelmän avulla voidaan saavuttaa sekä vakautta että joustavuutta, jossa keskeiset prosessit säilyttävät jatkuvan kehittämisen ja mukautuvat organisaation ja markkinoiden muutoksiin.

Kun rakennetaan prosessivetoista organisaatiota, keskeinen haaste on myös se, miten määritellään ja rakennetaan itse liiketoimintaprosessit. Tämä vaihe alkaa liiketoiminnan luonteen ymmärtämisellä ja keskeisten prosessien tunnistamisella. Tukitoimintojen, jotka eivät ole suoraan yhteydessä liiketoiminnan ytimeen, rooli voidaan minimoida, jolloin organisaation prosessit keskittyvät enemmän asiakasarvon tuottamiseen. Prosessien selkeä erottelu ja mallintaminen on tärkeää myös liiketoiminnan optimoinnin kannalta. Tässä vaiheessa palvelutasosopimusten (SLA) käyttö on keskeistä, sillä ne auttavat määrittelemään, miten sisäiset ja ulkoistetut prosessit integroidaan osaksi organisaation kokonaisprosessia.

Prosessivetoisen organisaation kehittäminen ei ole vain prosessien mallintamista, vaan se edellyttää myös organisaation kyvykkyyksien ja rakenteiden kehittämistä. Prosessien optimointi, työnkulkujen tarkka hallinta ja prosessien jatkuva parantaminen ovat avainasemassa, kun siirrytään perinteisestä organisaatiomallista kohti prosessivetoista mallia. Näiden prosessien hallinta edellyttää kykyä sopeutua markkinan ja asiakkaiden tarpeisiin sekä samalla varmistaa, että organisaatio pystyy säilyttämään sisäisen vakauden ja tehokkuuden.

Organisaation kypsyysmallit, kuten M. Hammerin prosessien kypsyysmalli (PEMM), tarjoavat tavan arvioida organisaation valmiuksia ja kyvykkyyksiä prosessivetoisen muutoksen läpiviemiseksi. Kypsyysmalli, joka etenee perinteisestä johtamisesta kohti prosessivetoista toimintaa, auttaa määrittämään, millä tasolla organisaatio on ja mitä toimenpiteitä tarvitaan seuraavalle tasolle siirtymistä varten. Kypsyysmallin korkeimmalla tasolla prosessit ovat jo linjassa asiakkaiden tarpeiden kanssa, ja organisaatio toimii markkinoiden osana, eikä vain sisäisesti itsenäisenä yksikkönä. Tämä malli auttaa organisaatioita kehittämään jatkuvasti prosessien hallintaa ja mukautumaan kilpailukykyisellä tavalla.

Prosessien hallinta ja organisaation kyvykkyyksien kehittäminen eivät ole vain teoriassa tärkeitä. Ne vaikuttavat suoraan siihen, miten organisaatio reagoi markkinoiden muutoksiin ja teknologian kehitykseen. Hyvin suunniteltu ja toteutettu prosessivetoisen organisaation malli voi tuottaa merkittävää kilpailuetua, joka pohjautuu joustavaan ja tehokkaaseen prosessien hallintaan. Samalla se edistää organisaation sisäistä vakautta, joka on elintärkeää pitkän aikavälin menestykselle.

Miten liiketoiminta-arkkitehtuurin mallinnus voi tukea prosessien hallintaa ja strategista suunnittelua?

Liiketoiminta-arkkitehtuurin mallintamisen kenttä on kehittynyt jatkuvasti, mutta perinteiset liiketoimintaprosessien hallinnan työkalut eivät enää riitä tukemaan strategista (prosessien yksityiskohtia abstrahoivaa) lähestymistapaa. Tämä ilmenee selkeästi prosessikartasta. Ei voida väittää, että olisi olemassa yksi standardi, yleisesti hyväksytty menettely tapa mallintaa prosessien välisiä suhteita ilman yksityiskohtien tarkastelua. Vaikka prosessikartat, prosessimaisemat ja arvovirrat ovat olleet laajalti käytössä, mikään niistä ei ole virallinen standardi. Standardit kuten BPMN ja UML eivät tarjoa vastaavaa prosessikarttaa, kun taas ARIS tarjoaa omat arvovirta- ja prosessikarttansa. Tämä voi antaa vaikutelman, että strategisen ja liiketoimintaprosessinhallinnan lähestymistavat olisivat erillisiä, mutta päinvastoin, molemmat käyttävät samaa prosessimallia. Tästä syystä ei pelkästään prosessien yksityiskohtien tarvitse olla linjassa prosessikartan piirteiden kanssa, vaan myös prosessikartan (arkkitehtuurin) tulee olla linjassa prosessien yksityiskohtien kanssa.

Liiketoimintaprosessien hallinta tarjoaa menetelmiä, joiden avulla voidaan tunnistaa ja mallintaa prosesseja yksityiskohtaisesti sekä mitata niiden suorituskykyä. Usein tämä ei ole mahdollista ilman prosessien yksityiskohtien tuntemusta. Se tarjoaa myös parhaat käytännöt, kuten APQC:n prosessiluokituskehyksen, linkitykset tasapainotettuun mittaristoon ja kypsyysmallit, jotka integroivat kaiken, mikä liittyy prosessinhallintaan. Kuitenkin liiketoimintaprosessien hallinta jättää analysoitavaksi maailman rakenteen, eli ne objektit, joiden kanssa prosessit työskentelevät. Vaikka liiketoimintaobjekteista voi löytyä mainintoja, yksityiskohtaiset analyysit jätetään usein muiden tehtäväksi.

Liiketoimintaprosessien mallintamisen ja analysoinnin menetelmä (MMABP) on hyvä esimerkki lähestymistavasta, joka tarjoaa erillisen metodologian, joka ei ole liian raskas pienille ongelmille, mutta on silti riittävän joustava laajennettavaksi. Hyvin jäsennelty analyysi voi olla toistettavissa ja laajennettavissa, mikä tarkoittaa, että ei tarvitse mallintaa koko yrityksen liiketoimintajärjestelmää, vaan voidaan keskittyä vain kyseiseen ongelmaan ja sen ratkaisuihin. MMABP ei pyri kilpailemaan olemassa olevien standardien kanssa, vaan sen tavoitteena on tuoda esiin se, mikä on oleellista liiketoiminta-arkkitehtuurissa nykyisten diagrammien ja elementtien tulvassa. MMABP tarjoaa perusperiaatteet ja käytännöt liiketoiminta-arkkitehtuurin ytimeen tarttumiseksi, jolloin mallit pysyvät täydellisinä ja johdonmukaisina, mutta ne ovat minimissään.

MMABP ei ole pelkästään muiden metodologioiden koostumus, vaan se on itsenäinen lähestymistapa, joka pohjautuu selkeisiin periaatteisiin. MMABP:n avulla voidaan kehittää liiketoimintajärjestelmän malli vaiheittain ja keskittyä vain olennaisiin ongelmiin ja niiden ratkaisuihin, unohtamatta mahdollisuutta hyödyntää muita relevantteja kaavioita ja symboleita, joita olemassa olevat standardit tarjoavat. MMABP on integroitavissa käytettyihin standardeihin ja se kunnioittaa TOGAFia, joka on keskeinen yritysarkkitehtuurin viitekehys, sekä käyttää Event Diagramia prosessikartan luomiseen.

Lisäksi MMABP jakaa liiketoimintaprosessinhallinnan ja EE:n (Enterprise Engineering) ajatuksen siitä, että liiketoimintaprosessien yksityiskohtaiset mallit ovat olennainen osa liiketoiminta-arkkitehtuuria. MMABP:n näkökulma yhdistää ontologisen mallintamisen, joka voi olla liian monimutkainen tavalliselle analyytikolle, mutta silti tarjoaa mahdollisuuden mallintaa liiketoimintaprosessien ja liiketoimintaobjektien todellisuuden jäsennellysti ja ymmärrettävästi. Erityistä huomiota kiinnitetään objektien elinkaaren mallintamiseen, joka on pääasiassa esitetty tilanmuutospiirroksissa (tilakoneen kaavio UML:ssä).

Liiketoiminta-arkkitehtuurin mallintamiseen liittyy monia erilaisia standardeja ja viitekehyksiä. Yleisesti ottaen nämä standardit ja viitekehykset on suunniteltu itsenäisiksi, mutta usein ne viittaavat metodologisiin kehyksiin, jotka tukevat niiden käyttöä. Esimerkiksi ArchiMate on itsenäinen standardi, joka liittyy yritysarkkitehtuurin mallintamiseen, mutta se viittaa TOGAFiin filosofisena pohjana. TOGAF puolestaan listaa ArchiMaten yhtenä sopivana standardina, mutta ei ainoana.

ARIS (Integrated Information Systems) on pitkään kehitetty arkkitehtuurin mallintamiskehys, joka alun perin keskittyi informaatioteknologian järjestelmiin, mutta laajeni kattamaan koko yrityksen arkkitehtuurin. ARIS:n lähestymistapa arkkitehtuurin mallintamiseen on monivaiheinen ja moninäkökulmainen. Se jakaa arkkitehtuurin viitekehykseensä viisi erilaista näkökulmaa: organisaatio, data, tuote/palvelu, toiminto ja ohjaus, jotka auttavat purkamaan arkkitehtuurin monimutkaisuutta ja tarjoavat kattavan ymmärryksen arkkitehtuurista eri näkökulmista.

Kuinka valita oikea revolveri ja ladata siihen sopivat patruunat
Mikä on Trumpin psykologinen ja sosiaalinen kehitys, ja miksi hänen käyttäytymisensä on vaarallinen?
Miten säilyttää ja optimoida rajapintaehtojen laskentateho SPH-simulaatioissa?
Miksi Kana ei voi olla osa maapallon yhteiskuntaa?