Lean EA – toimintamalli ja viitekehys

Kuva: Lean EA ja organisaation kehittämisen osa-alueet.

Lean EA on lähestymistapa, joka tukee liiketoiminnan kokonaisvaltaista kehittämistä. Lean EA -lähestymistavassa kokonaisarkkitehtuuri on integroitu osaksi organisaation kehittämistoimintaa. Lean EA yhdistää liiketoiminnan johtamisen, kehittämisen ja operatiivisen toiminnan hallinnan kokonaisarkkitehtuurin avulla. Lean EA -lähestymistavan kohteena on organisaation kokonaisvaltainen toiminnan ja rakenteen kehittäminen. Tässä lähestymistavassa huomioidaan liiketoiminta ja IT sekä ihmiset.

Lean EA -lähestymistavassa hyödynnetään olemassa olevia menetelmiä ja välineitä sekä parhaita käytäntöjä (kuten muotoiluajattelua), mutta kokonaisuuden hallinnan kannalta tärkein menetelmä on kokonaisarkkitehtuuri (KA). Kokonaisarkkitehtuurin avulla tuetaan niin organisaation johtamista kuin operatiivisen toiminnan kehittämistä. Kuva alla havainnollistaa näiden organisaation johtamisen, kehittämisen ja hallinnan osa-alueita, joita Lean EA-lähestymistapa tukee sekä toimintamallina että käytännönläheisenä viitekehyksenä.

Kuva: Lean EA lähestymistapa (LEAD-menetelmä) – organisaation kokonaisvaltainen kehittäminen.

Huom! Tässä yhteydessä on kysmys liiketoiminnan johtamisesta, ei ihmisten johtamisesta.

Mitä on Lean? Perusidea on maksimoida asiakasarvo ja minimoida arvoa tuottamaton hukka. Päämääränä on tuottaa asiakasarvoa keskittymällä prosessin läpivirtaukseen ja tehokkuuteen. On väärinkäsitys mieltää Lean soveltuvaksi vain valmistavan teollisuuden tuotannolliseen toimintaan, ja sen prosessien virtaviivaistamiseen. Lean soveltuu kaikille toimialoille, kaikenlaiseen liiketoimintaan ja julkishallintoon. Lean soveltuu, ei ainoastaan valmistavan teollisuuden, vaan kaikenlaisen toiminnan prosesseihin. Lean ei ole vain strategis-taktisen tason tai kustannusten vähentämisen ohjelma, vaan Lean on koko organisaatioon ja kaikille sen tasoille soveltuva tapa ajatella ja toimia. [Lean Enterprise Institute]

Mikä on Lean EA? Lean EA on Lean-periaatteisiin pohjautuva kehittämisen toimintamalli, johon integroitu EA-toiminta ja -viitekehys. Siksi nimi Lean EA. Fokus on liiketoiminnan kehittämisessä.

Lean EA-toimintamalli (LEAD) on liiketoimintalähtöisen kehittämisen menetelmä, joka on hyvin käytännönläheinen. Ideana on kuvata kaikki kehittämistarpeet heti kun ne nousevat esiin. Kun ne kuvataan, ymmärretään heti alusta alkaen miten ne liittyvät olemassa olevaan organisaation liiketoimintaan. Tässä hyödynnetään Lean EA-viitekehystä (LEAF), joka on organisaation kehittämisen ns. meta-framework. Se sisältää kaikki oleelliset ylätason liiketoiminnan johtamisen ja -kehittämisen sekä operatiivisen toiminnan asiat ja käsitteet, ja kytkee ne yhteen tavalla, jota voidaan soveltaa yhdessä muiden viitekehysten ja menetelmien (kuten ITIL4, DevOps, IT4IT, Cobit, SAFe, Scrum, Lean, agile, Togaf, JHS179 jne.) kanssa.

Lean EA-toimintamalli integroi arkkitehtuurityön osaksi organisaation kehittämistoimintaa.

Lean EA-viitekehys ohjaa ja helpottaa arkkitehtuurisisällön hallintaa, ja tukee kehittämistoimintaa.

Lean EA -lähestymistapa eroaa perinteisestä tavasta tehdä kokonaisarkkitehturia

Merkittävimpiä eroja Lean EA -lähestymistavan ja perinteisen kokonaisarkkitehtuurin välillä on kuvattu alla olevassa taulukossa.

Lean EA -lähestymistapaPerinteinen KA (JHS179, Togaf jne.)
Liiketoimintalähtöisyys.
Fokus on organisaation liiketoiminnan kehittämisessä. Painopiste on liiketoiminnassa, ei IT:ssä. Liiketoiminta on pääasia, jota IT vain ja ainoastaan tukee. Vastaavasti kokonaisarkkitehtuuri on tukifunktio, joka tukee liiketoiminnan kehittämistä ensisijaisesti, ja IT:tä toissijaisesti.
IT-lähtöisyys.
Fokus on organisaation IT:ssä.
Tehdään erillistä “arkkitehtuuria” IT-lähtöisesti. Painopiste on IT:ssä: tietojärjestelmissä ja teknologioissa, “arkkitehtuuria arkkitehdeille” -periaatteella.
Pyritään aikaansaamaan organisaation tilannekuva. Tavoitteena on luoda pohja organisaation “digitaaliselle kaksoselle” (Digital Twin of an Organization, DTO), eli organisaation toiminnan ja rakenteen kokonaiskuvalle (asianmukaisessa välineessä. (Välinekehitys ei vastaa Gartnerin DTO visioon vielä toistaiseksi). Ylläpidetään erillisiä nykytilakuvauksia ja tavoitetilan kuvauksia, laaditaan arkkitehtuurin tiekarttoja ja visioita.
Kokonaisvaltaisuus.
Organisaatiota kuvataan kokonaisvaltaisesti, osakokonaisuus (segmentti) kerrallaan. Tällöin ei erotella kokonaisuutta näkökulmiin tai kerroksiin, jolloin kokonaisuus siiloutuu. Painopiste on asiakaslähtöisessä liiketoiminnassa ja sen kehittämisessä. Organisaatiota tarkastellaan asiakkaan näkökulmasta ulkoa-sisään (outside-in). Kuvaamista tehdään vertikaalisesti, pinona, kunkin kehittämiskohteen laajuudessa kerrallaan. Pino on jokin liiketoiminnan kannalta merkityksellinen kehittämiskohde, kokonaisuuden osa (osakokonaisuus) eli segmentti. Tällainen osakokonaisuus voidaan muodostaa esim. asiakasryhmän kannalta, palvelualue- tai palvelukohtaisesti, jolloin kyseessä on yksi siivu (slice) kokonaisuudesta. Kuitenkin aina niin, että kukin kehittämisen osa-alue, osakokonaisuus (segmentti), on liiketoiminnan kannalta merkityksellinen.
Näkökulmapohjaisuus.
Kuvaamisessa erotellaan toiminta-, tieto-, tietojärjestelmä ja teknologianäkökulmat. Tämä on TOGAF-pohjainen jaottelu BDAT-arkkitehtuurinäkökulmiin (domaineihin) Business, Data, Applications, Technology. Tämä perinteinen lähestymistapa perustuu organisaation sisäisten reurssien tarkasteluun, sisältä-ulos (inside-out). Tällöin päähuomio ei ole asiakaslähtöisessä liiketoiminnan kehittämisessä, vaan enemmänkin IT- ja järjestelmälähtöisessä, teknologioihin painottuvassa kehittämisessä.
Arkkitehtuurin kuvaamisen laatu on sisäänrakennettu kehittämisen toimintamalliin, ei tehdä katselmointeja jälkikäteenArkkitehtuurin kuvausten laatua hallitaan katselmoinnella.
Arkkitehtuurin kuvauksia laaditaan liiketoimintalähtöisesti, vain vain tarpeeseen ja vain riittävästi (just in time & just enough), silloin kun niille on liiketoiminnan “tilaus”.Arkkitehtuurin kuvauksia tehdään IT- ja järjestelmälähtöisesti.
Arkkitehtuurisisällön tekemisessä pyritään yksinkertaisuuteen ja helppouteen sekä ylläpidon vaatiman työmäärän minimoimiseen. Kaaviotyypit on tunnistettu, niiden sisältö on sovittu, ja niiden käyttötarkoitus on määritelty.Arkkitehtuurikuvaukset ovat luonteelta teknisiä, ne on kohdistettu IT:stä ja järjestelmistä vastaaville. Arkkitehtuurin kuvaamisen tarkkuustaso vaihtelee tapauskohtaisesti, on tekijänsä näköistä, osaamistason mukaan määräytyvää, usein liian tarkkaa, työlästä ylläpitää: vaikea tehdä ja ymmärtää.
Arkkitehtuuri on tukitoiminto, jonka tuotokset on tarkoitettu muillekin kuin arkkitehdeille. Arkkitehtuurilla on arvoa vain mikäli se tukee asiakasarvon ja liiketoiminta-arvon tuottamista.Arkkitehtuurin kuvaukset ovat lähinnä arkkitehdeille ja teknisille ihmisille.
Organisaation liiketoiminnan kehittämistä varten on laadittu vain muutama ylätason kehittämisen periaate. Linjauksia on vähän tai ei olleenkaan, sillä käytäntöjen, menetelmien, välineiden ja teknologioiden kehitys on niin nopeaa, ettei niistä ole mielekästä laatia ohjaavia tai rajaavia asetuksia. Lisäksi: missään organisaatiossa ei ole tahoa, jossa olisi niin paljon osaamista, että se kykenisi laatimaan tarkkoja ja ajassa kestäviä linjauksia.IT-lähtöistä kehittämistä ohjataan arkkitehtuurin periaatteilla ja -linjauksilla, jotka ovat tyypillisesti teknispainotteisia. Periaatteita ja linjauksia on paljon. (Niiden hyöty on kyseenalainen: tukevatko ne ketterää kehittämista vai ovatko ne hidaste tai peräti este.)
Arkkitehtuuri on olemassa ja sitä kehitetään vain ja ainoastaan liiketoiminnallisista lähtökohdista: liiketoiminnan tarpeiden mukaan. Liiketoiminnan vuoksi – ei itsetarkoituksellisesti.Arkkitehtuuria voidaan kehittää myös itsensä vuoksi, arkkitehdeilta arkkitehdeille, arkkitehtuurin lähtökohdista, arkkitehtuurin tarpeista johtuen. Arkkitehtuurilla on itseisarvo.
Kehitetään organisaation liiketoimintaa, liiketoiminnan palveluita ja/tai tuotteita.Kehitetään organisaation IT-arkkitehtuuria.
On vain yksi arkkitehtuuri, joka kuvaa organisaatiota.On useita arkkitehtuurin tasoja eri tarpeisiin: kokonaisarkkitehtuuri, ratkaisuarkkitehtuuri, sovellusarkkitehtuuri, tietoarkkitehtuuri, tietoturva-arkkitehtuuri, integraatioarkkitehtuuri, teknologia-arkkitehtuuri, infra-arkkitehtuuri, tietoliikennearkkitehtuuri jne. jne.
KA-kehittämisellä tähdätään kokonaiskuvan saamiseen organisaatiosta, sen toiminnasta ja rakenteesta (behavior & structure), tukemaan liiketoiminnan kehittämistä. Tämä toimii pohjana organisaation “digitaaliselle kaksoselle” (Digital Twin of an Organization, DTO). Tavoitteena on aikaansaada tilannekuva organisaatiosta, josta voidaan katsoa aina miten organisaatio toimii ja mikä on sen rakenne.KA-kehittämisessä tehdään 1) nykytila ja 2) tavoitetila 3) GAP-analyysi ja 4) siirtymäarkkitehtuureja (arkkitehtuurin tiekarttoja) siirtymisestä (transitio) nykytilasta tavoitetilaan. Näitä tehdään IT- ja järjestelmälähtöisesti, arkkitehdeille ja IT-kehittäjille.
Lean EA:n ja perinteisen KA:n eroja.

Kaikkein perustavalaatuisin ero Lean EA:n ja perinteisen tavan välillä liittyy kokonaisarkkitehtuurin rooliin ja merkitykseen organisaatiossa: Lean EA on liiketoimintalähtöinen, perinteinen KA on IT-lähtöinen. Tämä ero näkyy kaikessa, niin tekemisessä kuin arkkitehtuurin kuvaamisessa. Oleellista on lähesytmisen tulokulma, vaikka sekä liiketoiminta että IT tulee huomioida kun kokonaisuutta tarakastellaan. Toinen merkittävä ero liittyy Lean EA -lähestymistavan tavoitteeseen mahdollistaa koko organisaation tilannekuva, eli luoda pohja organisaation “digitaaliselle kaksoselle” (Digital Twin of an Organization, DTO) – jolle välineet eivät vielä ole kypsiä. Tässä kaikkein keskeisin kaaviotyyppi on kerrosnäkymä. Toinen tärkeä kaaviotyyppi onjärjestelmien vuorovaikutus -näkymä. Muita hyödyllisiä kaaviotyppejä ovat liiketoiminnan käsitemalli ja toimijoiden vuorovaukutus.

Lean EA-toimintamalli

Lean Enterprise Architecture Development (LEAD).

Kyseessä on organisaation kehittämistoiminnan toimintamalli (kehittämisen toimintamalli / kehittämismalli), jossa päähuomio on organisaation kehittämistoiminnassa – ei kokonaisarkkitehtuurissa. Vaikka kutsumanimi Lean EA viittaa kokonaisarkkitehtuuriin (Enterprise Architecture), ja sen kehittämiseen (Lean Enterprise Architecture Development, LEAD), kysymyksessä on organisaation ylätason kehittämismalli. Koska organisaation kehittämistoiminnan tueksi tarvitaan ymmärrys organisaation toiminnasta ja rakenteesta, eli kokonaisarkkitehtuurista, on mielekästä tarkastella näitä asioita yhdessä. Tällainen organisaation kokonaisvaltainen tarkastelu käsittää kaikki oleelliset asiat kuten strategia, organisaation liiketoiminnan jäsentely asiakaslähtöisesti, organisaation liiketoiminnan- ja operatiivisen toiminnan kehittäminen, organisaation operatiivinen toiminta. Näitä kaikkia voidaan kattavimmin kuvata ja mallintaa kokonaisarkkitehtuurin avulla. Lean EA määrittelee uudella tavalla mitä kokonaisarkkitehtuuri on ja mitä se ei ole. Ollakseen hyödyllistä kokonaisarkkitehtuurin on oltava yksinkertaista ja ymmärrettävää sekä vaikuttavaa.

Kuva: Lean EA -toimintamalli nivoo yhteen organisaation liiketoiminnan johtamisen ja -kehittämisen sekä operatiivisen toiminnan, kokonaisarkkitehtuurin avulla. Kokonaisarkkitehtuurin sisältö kasvaa Tetris-palikoiden tapaan osana jatkuvaa kehittämistoimintaa.

Lean EA -toimintamallin vaiheet

Kuva: Kehittämisen arvoketjun vaiheet: Suunnittelu, kehittäminen ja palvelutuotanto (Plan -> Build -> Run).
Analyze – Build – Consume.

Lean EA -kehittämismallin vaihejako perustuu tyypilliseen Plan-Build-Run elinkaarimalliin, joka toistuu useissa eri viitekehyksissä jossain muodossa (kuten Cobit, IT4IT). Kehittämismalli voidaan käsittää myös A-B-C -mallina: Analyze, Build, Consume (analysoi, kehitä, käytä).

Suunnittelu

Suunnitteluvaiheessa selvitetään mikä on tarve ja mikä on se muutos, joka halutaan saada aikaan. Tarpeet voivat olla esim. liiketoimintalähtöisiä tai strategialähtöisiä tai ne voivat olla vaikkapa lakimuutoksia. Aina kun mahdollista, pyritään huomioimaan asiakkaan tarve. Kaikki kehittämistarpeet vastaanotetaan keskitetysti tarpeiden käsittely (Demand Management) -toiminnon kautta. Se on moniammatillinen ryhmä asiantuntijoita, jotka yhdessä käsittelevät tarpeet ja konseptoivat ne kehittämiskohteiksi kehitysportfolioon. Arkkitehtuuria kuvataan heti alkuvaiheessa, kun tarpeita tarkastellaan asiakkaan ja liiketoiminnan kannalta. Vaiheen lopputuloksena syntyy kehittämiskelpoisia konsepteja (kehittämiskohteita) kehitysportfolioon priorisoitaviksi (KKK).

Huom! “suunnittelu” termi on tässä ymmärrettävä laajasti, se on suunnittelua, muotoilua (Design) ja konseptointia. Kaikkea sitä, jossa kirkastetaan, mikä on se ongelma jota pyritään ratkaisemaan: mikä on asiakas- ja liiketoimintalähtöinen kehittämistarve, jonka vuoksi jokin muutos tarvitaan toteuttaa organisaatiossa.

Kehittäminen

Kehitysportfoliosta priorisoidut kehittämiskohteet etenevät kehittämiseen, jossa ne toteutetaan. Kehittäminen voi käsittää erilaisia kehittämisputkia, kuten esimerkiksi hankinta, sovelluskehitys, prosessimuutos tai kokeilu. Kehittämisvaihe sisältää siis paljon muuta kuin yksinomaan ketterää ohjelmistokehitystä – organisaation toimialasta riippuen. Kehittämisellä tarkoitetaan tässä laajassa merkityksessä kaikkea sitä toimintaa, jolla jokin muutos toteutetaan organisaatioon. Kysehän on operatiivisen toiminnan kehittämisestä.

Huom! “Kehittäminen” on käännös sanasta Development, joka on vakiintunut termi, vaikka itse asiassa oikeampi termi olisi on “toteutus” (Implementation), sillä kyse on muutosten toteuttamisesta. Muutos voi olla liiketoimintaan vaikuttava prosessimuutos, palvelutarjoomaan uudelleen jäsentely, palvelun muotoilu, innovaatiokokeilu tai vaikkapa vain selvitys jostain asiasta (myöhempää toteutusta vartan) – siis paljon muutakin kuin IT-kehittämistä (tuotteen kehittämistä). “Kehittäminen” on kuitenkin vakiintunut termi, vaikka kyse onkin muutoksen toteuttamisesta – tässä yhteydessä.

Palvelutuotanto

Valmiit kehittämiskohteet siirtyvät lopulta tuotantoon, jossa konkreettisia IT-palveluita hallitaan palvelunhallinnan (ITIL4) prosesseilla. Muissa tapauksissa (kuten prosessimuutos) on kyse valmiin muutoksen käyttöönotosta. Palvelutuotanto-vaihe tuo kehittämismalliin mukaan perinteisen palveluhallinnan (ITSM), jolloin kehittämismalli kattaa kokonaan palveluiden elinkaareen.

Huom! “Palvelutotanto” viittaa ensisijaisesti palvelunhallintaan ja tuotannossa oleviin IT-palveluihin, sillä Lean EA -viitekehys on ns. meta-framework, eli sen voidaan ajatella olevan organisaation käyttämien viitekehysten (kuten SAFe, IT4IT ja ITIL4) päällä oleva kokoava kehikko. Käytännössä palveluportfolio voi kattaa organisaation IT-palvelut, eli Lean EA -kehikosta päästään näkemään mitä IT-palvelut ovat syöneet, mistä ne koostuvat. Palveluportfolio voidaan jakaa myös muihin palveluihin, kuten asiantuntijapalveluihin.

Lean EA-viitekehys

Lean Enterprise Architecture Framework (LEAF).

Lean EA-viitekehys (Lean Enterprise Architecture Framework, LEAF) on arkkitehtuurisisällön hallinnan apuväline. Samalla se auttaa ymmärtämään organisaation kehittämistoiminnan oleelliset asiat ja kytkemään ne yhteen kokonaisuudeksi. Lean EA-viitekehys toimii siis myös kehittämisen apuvälineenä, ja Lean EA-toimintamallin tukena. Mutta paras hyöty siitä saadaan, kun se implementoidaan organisaation kokonaisarkkitehtuurin hallintavälineeseen, ja arkkitehtuurisisältöä tuotetaan sen sisältörakenteisiin. Tällöin arkkitehtuurisisältö on sekä tuotettavissa että löydettävissä paremmin. Kehikko voidaan soveltaa, esim. sen yksikkökohtaisia alasivuja voidaan muokata tarkoituksenmukaisemmiksi.

Lean EA-viitekehyksestä on kaksi versiota: 1-tasoinen ja 2-tasoinen. 1-tasoisessa versiossa kaikki sisälätörakenteet avautuvat etusivulta (landing page).

LEAF versio 1: Keskitetty malli

Jos organisaation kokonaisarkkitehtuurin hallinta on keskitetty, eikä erillisiin domaineihin ole tarvetta. Tällöin Lean EA -kehikko on vastaavasti yksinkertaisempi kokonaisuudessaan: on vain yksi taso (kuva alla).

Kuva: LEAF – Kartat ja näkymät (Maps & Views) – keskitetty malli (ilman domaineja).

Referenssimallit:

LEAF versio 2: Domain malli (yksikkökohtaiset alasivut)

LEAF-kehikon 2-tasoinen versio jakaantuu kahteen tasoon seuraavasti:

  1. Lean EA Taso-1 (etusivu, landing page)
    • Organisaatiotason asioita: a) liiketoiminnan johtaminen, b) liiketoiminnan kehittäminen ja c) operatiivinen toiminta
    • Tällä tasolla organisaatiota tarkastellaan ylätasolla
    • Pyritään tunnistamaan liiketoiminnan johtamisen kannalta oleelliset asiat (kuten strategiset tavoitteet, arvovirrat ja kyvykkyydet sekä toiminnan kehittämistä ohjaavat kehittämisen periaatteet)
  2. Lean EA Taso-2 (alasivu, n kpl)
    • Domain-tasoiset arkkitehtuurisisällöt (yksikkökohtaiset alasivut)
    • Tällä tasolla tarkastellaan liiketoiminnan kannalta merkityksellisten osa-alueiden (kuten liiketoimintayksiköiden) toimintaa ja rakennetta
    • Pyritään tunnistamaan ja inventoimaan keskeiset elementit kuten palvelut, tuotteet, toimijat ja järjestelmät, sekä näiden väliset riippuvuussuhteet. Tällä tasolla yhdistyvät eri arkkitehtuuritasojen (kokonaisarkkitehtuuri ja ratkaisuarkkitehtuuri) kuvaukset
Kuva: LEAF taso-1 (etusivu, navigoinnin pääsivu “landing page”).

Yllä olevan taso-1 kaavion alaosan “Arkkitehtuuri” sisältörakenne-elementeistä (Domain 1-n) aukeaa alla oleva taso-2, eli domain-kohtainen arkkitehtuurisisältö (organisaatioissa, joissa kokonaisarkkitehtuurilla hallitaan useiden yksiöiden kuvauksia).

Kuva: LEAF taso-2, arkkitehtuurisisältö.

Yllä oleva versio perustuu kartat ja näkymät jaotteluun, joka perustuu havaintoon, että kokonaisarkkitehtuurin kuvauksia on kahden tyyppisiä: 1) karttoja elementeistä ja 2) näkymiä elementeistä ja niiden elementtien suhteista.

Alla oleva vaihtoehtoinen versio tason-2 sisältörakenteesta perustuu ArchiMate core frameworkiin, jossa on seuraavat kerrokset (layers): liiketoiminta- (business), sovellus- (application) ja teknologia-kerros (technology).

Kuva: LEAF taso-2, arkkitehtuurisisältö, vaihtoehto 2.

Yllä olevassa kuvassa sisältörakenne “Liiketoiminta-analyysit” sisältää ns. motivaationäkymiä, joita voidaan tehdä ArchiMate Motivation-elementeillä, kuten tavoitteet (Goals), lopputulokset (Outcomes) jne.

Huom! Taso-2 sisältörakenne voidaan muotoilla yksikkökohtaisesti, jolloin siellä on vain niitä sisältörakenteita jotka ovat ko. yksikön toiminnan kehittämisen kannalta oleellisia. Esim. jos jokin yksikkö on teknologiapainotteisempi, voidaan lisätä sisältörakenteita kuten Teknologiapalvelut ja Teknologia-alustat jne., ja poistaa sisältörakenteita kuten Käsitteet, Prosessien vuorovaikutukset jne. Taso-2 voi perustua esim. kartat ja näkymät -tyypiseen rakenteeseen, tai perinteisempään rakenteeseen, jossa näkyvät arkkitehtuurikerrokset.

Lean EA -viitekehyksen sisältörakenteet ja kaaviotyypit

Tässä uudistetussa Lean EA-kehikon versiossa on tarkoitus yksinkertaistaa ja helpottaa arkkitehtuurisisällön hallintaa. Uusi tarkastelu perustuu käytännön arkkitehtuurityön havaintoihin ja kokemuksiin. Lean EA -kehikon taso-1 on pysynyt jokseenkin ennallaan, mutta taso-2 on muotoiltu paremmin käytännön arkkitehtuurityötä tukevaksi.

Alla olevissa kuvissa on esitetty LeanEA-viitekehyksen tasot 1 ja 2 sisältörakenteineen, sekä niihin kuuluvine kaaviotyyppeineen.

Lean EA taso-1

Taso-1 on navigaation pääsivu (landing page), joka käsittää organisaatiotasoiset asiat:

  • liiketoiminnan johtaminen,
  • liiketoiminnan kehittäminen (operatiivisen toiminnan kehittäminen) ja
  • arkkitehtuurisisältö (operatiivinen toiminta).

Alla olevissa kuvissa on eritelty kunkin sisältörakenteen kaaviotyypit.

Kuva: LEAF taso-1 kaaviotyypit.

Taso-1 tarkastelee organisaatiotasolla johtamista, kehittämistä ja operatiivista toimintaa. Näistä muodostuu ns. kokonaisvaltainen kehittäminen, joka Lean EA:n taustalla oleva idea: organisaatiota, ja kaikkia sen osia, sekä niihin kohdistuvia muutoksia, tulisi tarkastella kokonaisvaltaisesti.

Yläosan sisältöalueella “Toiminnan johtaminen” on sisältörakenteita esim. tavoitteille ja toimenpiteille, sekä kyvykkyyskartoille. Keskimmäinen sisältöalue, “Toiminnan kehittäminen”, käsittää organisaation kehittämistoiminan arvoketjun (“tarpeesta-toteutukseksi”), sekä kehittämistoiminnan kannalta oleelliset portfoliot ja tiekartat. Sisältöalueen “Operatiivinen toiminta” varsinaiset sisältörakenteet ovat tasolla-2, mutta tällä tasolla näkyy, kuinka organisaatio on jäsennelty liiketoiminnan kannalta merkityksellisiin osa-alueisiin eli domaineihin. Domain on tyypillisesti organisaatioyksikkö, mutta se voi olla esim. palvelualue tai arvovirta (jonka ympärille kehittäminen on organisoitunut – Spotify Tribe-mallin mukaisesti). Tyypillisesti tällainen domain-jaottelu on perusteltua arkkitehtuurisisällön hallinnan kannalta, jos organisaatiossa on käytössä hajautettu kokonaisarkkitehtuurin hallintamalli. Jos taas kyseessä on keskitetty malli, domain-jaottelu on tarpeeton, ja kehikko on vastaavasti yksinkertaisempi: siinä on vain 1-taso (kts. jäljempänä kappale “Keskitetty malli”).

Huom! Lean EA “talomalli” on asiakasnäkymä organisaation: ulkoa-sisään (outside-in) tarkastelu, ennemmin kuin arkkitehtien sisältä-ulos (inside-out) näkymä, joka ei avaudu muille kuin arkkitehdeille. Lean EA “talo” kuvaa organisaatiota, koska tavoitteena on aikaansaada organisaation “digitaalinen kaksonen” (Digital Twin of an Organization, DTO). Talomallin etusivu ja alasivut ovat mahdollisimman intutiivisesti ymmärrettäviä tasoja tarkastella organisaatiota. Tavoitteena on luoda pohja organisaation “digitaaliselle kaksoselle” (DTO:lle), joka on tilannekuva organisaatiosta: miten se toimii ja mistä se koostuu.

Lean EA taso-2

Tason-2 periaatteina ovat yksinkertaisuus ja helppous, jotta arkkitehtuurisisällön tuottaminen olisi käytännössä tehokkaampaa ja tuottavampaa, ja kuvausten löydettävyys olisi mahdollisimman helppoa. Tason-2 sisältörakenteissa huomioidaan kaikki arkkitehtuurin tasot kokonaisvaltaisesti – riippumatta siitä, mielletäänkö joitakin asioita kuuluvan yksinomaan joko kokonaisarkkitehtuurin tai ratkaisuarkkitehtuuriin. Lean EA kannustaa ajattelemaan ja tarkastelemaan organisaation arkkitehtuuria kokonaisuutena, ei erillisinä osa-alueina. Tällöin kyse on arkkitehtuurista yleensä, ei joko kokonaisarkkitehtuurista tai ratkaisuarkkitehtuurista. Ei myöskään toiminta-, tieto-, järjestelmä- tai teknologia-arkkitehtuureista erikseen, vaan näistä kaikista yhdessä.

Kuva: LEAF taso-2 kaaviotyypit.

Kokonaisarkkitehtuurin hallinnan (Enterprise Architecture Management, EAM) perusta luodaan inventoimalla organisaation kokonaisarkkitehtuurin elementit. Näitä ovat esim. palvelut, prosessit, tiedot ja järjestelmät. Lean EA -kehikossa nämä elementit sijoitetaan sisältöalueelle Kartat (Maps). Tämä sisältöalue noudattaa ArchiMate Frameworkistä tuttua jaottelua toimintaan (behavior) ja rakenteeseen (structure). Sinällään Lean EA -viitekehys on mallinnuskieliriippumaton.

Ratkaisuarkkitehtuurin kuvauksia syntyy käytännön arkkitehtuurityössä määrällisesti eniten. Nämä sijaitsevat kehikon oikean reunan sisältöalueella Näkymät (Views). Nämä näkymät ovat lopulta arkkitehtuurikuvauksia, riippumatta arkkitehtuurin tasosta (KA, ratkaisuarkkitehtuuri..). Arkkitehtuurin näkymiä luodaan niin kokonaisarkkitehtuurityössä kuin ratkaisuarkkitehtuurityössä. Kysymys on lopulta vain arkkitehtuurista. Ilman raja-aitoja. Arkkitehtuuria kaikki tyynni!

Tason-2 tavoitteena on muodostaa sisällön jäsennyskehikosta sellainen, että sen avulla paremmin ymmärretään mitkä asiat ovat keskeisiä organisaation kehittämisen kannalta. Tavoitteena on myös erottaa sisällöstä selkeämmin kokonaisarkkitehtuurin peruskuvaukset ja ratkaisuarkkitehtuurin kuvaukset. Tason-2 sisältö voidaan muotoilla yksikkökohtaisesti, tai se voi olla kaikilla yksiköillä samanlainen. Tässä yhteydessä on esitelty yleiskäyttöinen malli, jota voi soveltaa sellaisenaan tai sitä voi muokata tarkoituksenmukaisemmaksi.

Huom! “Järjestelmä” on ylätason käsite, jota mallinnetaan ArchiMate -notaatiossa Application Component -elementillä. Vastaavasti “Järjestelmäpalvelut” on tässä yksinkertaistus, jolla tarkoitetaan järjestelmien ulospäin tarjoamia palveluita eli toiminnallisuuksia. ArchiMate-notaatiossa niitä mallinnetaan Application Service -elementillä. Järjestelmäpalveluista voidaan käyttää myös nimeä “Sovelluspalvelu”. Terminologia valitaan organisaatiossa vakiintuneen termistön mukaan tarkoituksenmukaiseksi. Järjestelmäpalveluihin voidaan katsoa luettavan myös organisaation IT-palvelut (ITSM, ITIL). Järjestelmien tarjoamat järjestelmäpalvelut (tai sovelluspalvelut) erotetaan IT-palveluista mallinnusvälineessä esim. elementin visuaalisen ulkoasun tai sisäisen attribuutin perusteella.

Kartat ja näkymät (Maps & Views)

Organisaation arkkitehtuurin (toiminnan ja rakenteen) kannalta on olemassa kahdenlaista sisältöä, ja vastaavasti kahdenlaisia kaavioita:

  1. Karttoja (Maps), jotka kuvaavat organisaation elementtilistoja, organisaation staattista tilaa (organisaatiota “levossa”, organization at rest) ja
  2. Näkymiä (Views), jotka kuvaavat organisaation dynamiikkaa, elementtien vuorovaikutuksia ja riippuvuuksia (organisaatiota “liikkeessä”, organization in motion).

Näiden avulla kaikki käytettävät kaaviot voidaan jaotella määrättyihin kaaviotyyppeihin, joista osa on karttoja ja osa muita kaavioita. (Mallintamisen kannalta kaikki ovat kaavioita, kokonaisarkkitehtuurin kannalta kaikki ovat näkymiä). Kun kokonaisarkkitehtuurin kaaviot jaotellaan joko karttoihin tai muihin kaaviotyyppeihin, on kokonaisarkkitehtuurin hallinta helpompaa: kaaviot on helpompi löytää kuvausvälineestä, ja kaavioita on helpompi laatia. Tässä mielessä kokonaisarkkitehtuurin hallinnan kannalta kartat (Maps) ja näkymät (Views) on syytä erottaa toisistaan.

Kartat (Maps) – organisaatio “levossa” (Organization at rest)

Kuva: Kartta (Map) on elementtien listaus / visualisointi.

Kartat (Maps) ovat kokoelmia niistä kokonaisarkkitehtuurin elementeistä, jotka ovat organisaation operatiivisen toiminnan kannalta merkityksellisiä. Karttoja ovat esim. kyvykkyyskartat, palvelukartat, prosessikartat ja järjestelmäkartat. Näiden avulla inventoidaan ja hallitaan organisaation keskeisiä toiminnallisia ja rakenteellisia elementtejä.

Kukin kartta voidaan ryhmitellä sopivalla tavalla, esimerkiksi palvelukartta tai järjestelmäkartta voidaan ryhmitellä liiketoiminnan jäsentelyn kannalta merkityksellisiin osa-alueisiin. Organisaation johtamisen ja liiketoiminnan kehittämisen kannalta ensisijainen kartta on kyvykkyyskartta, jonka avulla tunnistetaan ne asiat, jotka ovat organisaation olemassaolon kannalta kaikkein oleellisimmat. Johdon tulee tunnistaa ja ymmärtää ainakin nämä asiat, eli kyvykkyydet, jotta ollaan “kartalla” mitä johdetaan.

Huom! On huomattava kuitenkin, että kyvykkyyskartta (kuten muutkin kartat) ovat vain listauksia, parhaimmillaankin ryhmiteltyjä listauksia eli jäsentelyjä. Kartoissa olevat elementit (kuten kyvykkyydet) on kytkettävä kokonaisuuteen: esimerkiksi kyvykkyydet on kytkettävä arvovirtaan, jotta ymmärretään miksi kyseiset kyvykkyydet tarvitaan. Siksi tarvitaan näkymiä (Views), eli kaavioita, joiden avulla havainnollistetaan kartoissa esiintyvien elementtien suhteita muuhun kokonaisuuteen…

Näkymät (Views) – organisaatio “liikkeessä” (Organization in motion)

Kuva: Näkymä (View) on elementtien ja niiden suhteiden visualisointi, määrätyssä kontekstissa (rajatussa kokonaisuuden osassa).

Näkymät (Views) ovat organisaation operatiivisen toiminnan ja sen kehittämisen kannalta mielenkiintoisten, rajattujen osa-alueiden kuvauksia. Näkymissä käytettävät elementit ovat karttoihin kartoitettuja elementtejä, mutta näkymissä kuvataan näiden elementtien välisiä suhteita. Suhteilla kuvataan elementtien välisiä rakenteellisia suhteita, riippuvuussuhteita ja dynamiikkaa (kuten tietovirtoja).

Näkymiä ovat kaikki muut kaaviot jotka eivät ole karttoja eli elementtien kokoelmia. Näkymissä yhdistellään kartoitettuja elementtejä, kuvaamalla elementtien välisiä suhteita. Näkymät liittyvät tyypillisesti johonkin rajattuun osa-alueeseen, jonka kehittämisestä ollaan kiinnostuneita, kun tähän osa-alueeseen kohdistuu jokin muutos.

Kartat (Maps) ja Näkymät (Views) Lean EA -kehikossa

Kartat (Maps) ja näkymät (Views) -sisältöalueet ovat kooltaan yhtä suuria (visuaalisesti), koska ne ovat merkityksiltään yhtä suuria. Mutta niillä on eri käyttötarkoitus.

Kuva: Kartat (Maps) ja Näkymät (Views) sisältöalueet LEAF-kehikossa.

Kartat ovat kokonaisarkkitehtuurin hallinnan kannalta oleellisia, sillä niiden avulla hallitaan organisaation kokonaisuutta ja/tai sen osakokonaisuuksia.

Näkymiä syntyy kuitenkin määrällisesti eniten. Niitä syntyy jatkuvasti kehittämistoiminnan yhteydessä, kun erilaisia kuvauksia laaditaan eri kehittämiskohteista päivittäisen kehittämistoiminnan yhteydessä.

Tällaisen 1-tasoisen kehikon hallinta mallinnusvälineessä on niin ikään yksinkertaisempi ja helpompi. Kuvassa alla mallin hakemistorakenne (Sparx EA -välineessä).

Kuva: Mallin kansiorakenne mallinnusvälineessä (Sparx EA).

Lean EA-viitekehyksen kartat (Maps) ja näkymät (Views) -jaottelun avulla voidaan tunnistaa keskeisimmät kaaviotyypit, jotka riittävät käytännössä lähes kaikkiin kuvaustarpeisiin. Kaikista kaaviotyypeistä löytyy malleja (patterns) ja esimerkkejä LEAF-kehikosta: Johtaminen (Management), Periaatteet (Principles) -sisältörakenteesta. Kaikista kaavioista käytettävistä elementistä ja niiden suhteista kannattaa laatia organisaatiospesifi metamalli, joka kuvaa käytettävän mallinnustavan elementteineen. LEAF-kehikosta löytyy valmis metamalli, jota voidaan soveltaa sellaisenaan tai muokata omiin tarpeisiin.

Yhteisesti käytettävät kokonaisarkkitehtuurin elementit (kuten palvelut, prosessit, järjestelmät jne.) kannattaa sijoittaa Kartat (Maps) -kansion sisältämiin alikansioihin, jolloin elementit ovat paremmin hallittavissa ja löydettävissä. Erityisesti Sparx EA -välineessä näin kannattaa menetellä, koska muuten elementit jäävät siihen kansioon johon ne luodaan. Näin tapahtuu esim. kun laaditaan uusi kaavio, sen elementit sijoittuvat samaan kansioon kuin kaavio, ellei elementtejä erikseen siirretä. Archi-välineessä taas elementit sijoittuvat automaattisesti ArchiMate-kerrosten mukaisiin kansioihin, mutta niistä koostetut kartat kannattaa sijoittaa elementtityypin mukaiseen kansioon (kuten Business Services).

Erilaiset arkkitehtuurin näkymät (kuten kerrosnäkymä, toimijoiden vuorovaikutus jne.) sijoitetaan Näkymät (Views) -kansion alikansioihin, jotka on ryhmitelty kaaviotyyppien mukaan. Tällöin samat kaaviotyypit löytyvät samasta paikasta, ja kokonaisuuden hallinta on helpompaa.

Organisaatiossa käytettävät kartat ja näkymät ovat tapauskohtaisia, ja kaaviotyypit valitaan sen perusteella mikä on tarkoituksenmukaista. LEAF-viitekehyksen sisältörakennetta voidaan muokata tarpeen mukaan. Tässä esitetty referenssitoteutus on laadittu yleisimpien kuvaustarpeiden mukaan, käytännön arkkitehtuurityön kokemusten perusteella. Tässä esitetyt kaaviotyypit soveltuvat tyypillisiin arkkitehtuurin kuvaamisen tarpeisiin, olipa kyse kokonaisarkkitehtuurista tai ratkaisuarkkitehtuurista.

Hyvä tavoite on pyrkiä yksinkertaisuuteen ja helppouteen. Tärkeintä olisi että arkkitehtuurin kuvauksia tulisi ylipäätään tehdyksi. Mitä enemmän tehdään, ja mitä useampi mallintaja tekee, sitä enemmän opitaan. Yhdessä tekeminen ja läpikäyminen on kaikkein opettavaisinta. Siksi kuvausten tulisi mielellään olla yhdenmukaisia tarkkuudeltaan ja laajuudeltaan, ja ne tulisi olla helppo laatia ja olla helposti löydettävissä – ja helposti ymmärrettävissä. Tässä mielessä arkkitehtuurisisällön viitekehys on syytä pitää mieluummin mahdollisimman yksinkertaisena ja selkeänä, ennemmin kuin pyrkiä täyttämään kaikki pienimmätkin ja harvinaisimmatkin kuvaustarpeet. Mieluummin tulisi poistaa kaikki tarpeeton ja/tai vähemmän käytetyt erikoispiirteet, kuin lisätä sinne kaikki mahdolliset erikoistapaukset joille on kuviteltavissa jokin tarve joskus ehkä. Kaikkia asioita, joille koetaan aidosti tarvetta, voidaan myöhemmin lisätä, ja vastaavasti tarpeettomia asioita voidaan poistaa tai muuttaa. Kannattaa aloittaa pienesti, mutta tavoitella kunnianhimoisesti suurta. Ei kannata aloittaa liian isosti ja tukahduttaa innostusta suuruudenhulluuteen ja turhaan vaikeaselkoisuuteen… Kannattaa asettaa tavoitteet, sitouttaa ihmisiä, seurata kehittymistä ja oppia matkalla.

Lean EA referenssitoteutus

Lean EA-viitekehys voidaan toteuttaa useimpiin mallinnusvälineisiin (kuten Sparx EA ja Archi ja QPR EA). Periaatteessa Lean EA -viitekehys on mallinnuskieliriippumaton, mutta suositeltavin mallinnusnotaation on ArchiMate. ArchiMate on monipuolisin ja kattavin arkkitehtuurin mallintamisen notaatio, ja erityisen soveltuva se on kokonaisarkkitehtuurin mallintamiseen (kts. ArchiMate käsikirja). Tässä yhteydessä esitellyt referenssitoteutukset perustuvat ArchiMate-notaatiolla tehtyihin kaavioihin.

Referenssitoteutus on tehty Sparx EA (v.15.x) -välineellä, josta se on siirretty MEFF -siirtoformaatilla *) Archi-välineeseen. Periaatteessa Lean EA-viitekehys on mallinnuskieliriippumaton, mutta ArchiMate on valittu kieleksi, koska se on kattavin kokonaisarkkitehtuurin kuvaustarpeisiin soveltuva notaatio.

*) The Open Group ArchiMate Model Exchange File Format

Sparx EA ja Lean EA 1-tasoinen versio

Tässä yksinkertainen 1-tasoinen LEAF-viitekehys, jossa on vain etusivu (landing page). Etusivulla on kaikki osa-alueet: johtaminen, toiminann kehittäminen ja arkkitehtuurin tilannekuva. Vastaavasti kansiorakenne on yksinkertainen.

Kuva: 1-tasoinen LEAF-kehikko, Sparx EA HTML julkaisun snapshot (linkki).

Sparx EA ja Lean EA versio jossa yksikkökohtaiset (domain) alasivut

  • Sparx EA-välineen LEAF referenssitoteutus
  • Sparx EA -välineen toteutus ilman domaineja: LEAF (Maps & Views, ei domaineja)
Kuva: Sparx EA HTML -julkaisun etusivu (linkki).

Sparx EA -referenssitotetuksessa, “Arkkitehtuuri” -sisältöalueen (alaosa) domain-sisältörakenteiden osalta seuraavaa:

  • Kokonaiskuva (Domain 0) ja domainit 2-5 perustuvat kartat ja näkymät rakenteeseen.
  • Domain 1 taso-2 perustuu vaihtoehtoiseen ja perinteisempään rakenteeseen, jossa on mukana kerrokset business, application ja technology.

Archi

Ilmainen open-source Archi-väline.
  • Archi -välineen LEAF referenssitoteutus (Maps & Views, ei domaineja)
Kuva: Archi HTML-julkaisun etusivu (linkki).

Archi-välineellä tehdyn LEAF-referenssitoteutuksen (linkki) LEAF-etusivu löytyy paikasta Views (kuva alla).

Kuva: Archi-välineellä tehdyn LEAF-referenssitoteutuksen LEAF-etusivu löytyy paikasta Views.

LEAF-mallin sisältö

LEAF-malli sisältää valmiin hakemistorakenteen kansioineen. Näihin kansioihin luodaan varsinaiset kaaviot. LEAF-mallin visuaalinen ulkoasu on rakennettu käyttäen mallinnusvälineen ominaisuutta viitata kaavioihin. Kun varsinainen kaavio sisältää mallinnusnotaation standardielementtejä, niin malli itse sisältää viittauksia näihin kaavioihin. Tämä on mahdollista ns. viittauselementin avulla. Tällaisesta viittauselementistä voidaan navigoida eli “porautua” (drill down) varsinaiselle kaaviolle. Viittauselementti on siis mallinnusvälineen oma tapa esittää ja abstraktoida kaavio. Viittauselementtien käyttämisen myötä koko malli itse on modulaarinen ja helposti muokattavissa. Viittauselementin ulkoasua (kokoa, väriä, fonttia) voidaan muokata.

Kuva: Viittauselementti on elementti joka viittaa kaavioon.

Oheisessa kuvassa näkyy viittauselementit Sparx EA ja Archi-välineissä, jotka viittaavat samaan ArchiMate-kaavioon.

Kaavioon viittaava elementti on Sparx EA-välineessä nimeltään “Navigation Cell. Se luodaan yksinkertaisesti vetämällä määrätty kaavio hakemistorakenteesta jollekin kaaviolle (drag and drop). Sparx EA pyytää valitsemaan kaavion viittaustyypin, joista valitaan Navigation Cell (kuvassa vasemmalla). Archi-välineessä sama toiminnallisuus tekee automaattisesti ns. view-elementin kaaviolle (kuvassa oikealla).

LEAF -tiedosto

Lean EA -viitekehyksen (LEAF) pohja on saatavissa mallinnusvälineisiin Sparx EA ja Archi. Näihin välineisiin tehdyt pohjamallit sisältävät LEAF-viitekehyksen, jossa on mukana ArchiMate malleja ja esimerkkejä. LEAF-pohjamallien HTML-versiot ovat näkyvissä tämän kirjoituksen linkkien kautta. Jos LEAF-viitekehys kiinnostaa käytännössä, LEAF-tiedoston pohjamalli on saatavissa (Sparx EA- ja Archi -tiedostoversiona). Pyörää ei tarvitse keksiä uudelleen – voi ottaa pohjaksi yleisen valmiin mallin ja soveltaa sitä oman organisaation tarpeisiin. Valmis malli käsittää sisältörakenteen sekä esimerkkikaavioita, käyttöönotto on nopeaa.

Lean EA ja liiketoiminnan johtaminen ja kehittäminen

Lean EA:ssa fokus on ensisijaisesti oikeiden asioiden tekemisessä liiketoiminnan ja asiakkaiden kannalta, on vasta seuraavalla sijalla kyse asioiden tekemisestä oikein. Ensin on selvitettävä mikä on liiketoimintarve ja miksi jokin muutos tarvitaan, vasta sen jälkeen ratkaistaan, miten tämä muutos toteutetaan – vai toteutetaanko ollenkaan. Jos toteutetaan, se voi tapahtua joko a) itse tekemällä (tai teettämällä) tai b) hankkimalla jotakin.

Lean EA-lähestymistapa on ensisijaisesti ylätason ajattelutapa ja kehittämistoiminnan malli. Organisaatiotason liiketoiminta- ja asiakaslähtöinen ajattelutapa. Ja vielä tarkemmin, Lean EA on organisaation kehittämistoiminnan toteuttaminen tuotannolliseen toimintaan verrattavissa olevana mallina. Näin voidaan soveltaa Lean-filosofian mukaisia periaatteita ja käytänteitä. Rinnastaminen tuotannolliseen toimintaan on luontevaa, koska tuotetaanhan uusia palveluita ja/tai tuotteita (tai muutetaan olemassa olevia) jatkuvasti, kun muutoksia tapahtuu organisaation toimintaympäristössä. Organisaatio ei ole koskaan valmis, se on jatkuvassa muutoksessa. Sen olosuhteet muuttuvat, vaatimukset muuttuvat, ja se muuttuu myös sisältäpäin – jatkuvasti.

Lean EA-lähestymistavan periaatteista tarkemmin lisätietoa täällä : linkki.

Kuva: Lean EA lähestymistapa (LEAD-menetelmä) – organisaation kokonaisvaltainen kehittäminen.

Huom! Erotetaan johtamisen ulottuvuudet: liiketoiminnan johtaminen ja ihmisten johtaminen. Tässä yhteydessä kyse on ensisijaisesti liiketoiminnan johtamisesta.

Liiketoiminnan johtaminen on organisaation olemassaoloon liittyvää:
– mikä on se liiketoiminta jossa organisaatio on mukana?
– miten organisaatio tuottaa arvoa asiakkaille?
– mille asiakasryhmille organisaatio tarjoaa mitäkin palveluita ja/tai tuotteita?
– miten organisaatio tuottaa palveluita ja/tai tuotteita?
– miten organisaatio toimii?

Ihmisten johtaminen liittyy sisäisten toimijoiden eli organisatoristen rakenteiden hallintaan:
– millä organisaatiorakenteilla suorittaa toimintaansa.
– miten ihmisten välinen vuorovaikutus toimii, millainen organisaatiokulttuuri vallitsee

Liiketoiminnan jäsentely “toiminnallisin perustein”. Ensin tulee jäsennellä mikä on se organisaation toiminta, jota määrätyillä rakenteilla toteutetaan. Tämä liiketoiminnan jäsentely on organisaation johdon tärkein tehtävä. Eli erotetaan organisaation toiminta ja rakenne myös johtamisen tasolla: Toiminalliset elementit liittyvät organisaation tehtävään ja liiketoiminallisiin syihin olla olemassa. Rakenteelliset elementit liittyvät em. toiminnan suorittamiseen. Liiketoiminta on syy miksi organisaatio on olemassa. Rakenne on seurausta tämän liiketoiminnan suorittamisesta käytännössä. Tässä mielessä organisaation liiketoiminnan johtamisen ja kehittämisen kannalta on oleellista jäsennellä liiketoiminta “toiminnallisin perustein” (jolloin liiketoiminnan ), ei “rakenteellisin perustein” (jolloin ensin organisoidutaan valtarakenteisiin). Liiketoiminnan jäsentely on syytä aloittaa ylätasolta, organisaation operatiivisista arvovirroista (Value Streams). Niiden vaiheisiin (Value Stages) kytketään tarvittavat kyvykkyydet, eli toiminnalliset osa-alueet

Lean EA-periaatteista lisätietoa täällä: linkki.

– Eero Hosiaisluoma