Yritysarkkitehtuurissa pintaa syvemmälle PLM-viitekehyksestä täsmälääke

Seppo Narinen Yritysarkkitehtuurissa pintaa syvemmälle PLM-viitekehyksestä täsmälääke Jos PLM-yritysarkkitehtuurikäsite kuulostaa oudolta kerrottakoon heti, että mahdollisesti se on ensimmäistä kertaa parrasvaloissa tässä ja nyt, Valokynän sivulla! Englanniksi termi voitaneen kääntää ja lyhentää muotoon PLM Enterprise Architecture PLM EA. Tarkoittakaamme sillä kaiken kattavan yritysarkkitehtuurin harmonista osajoukkoa, joka fokusoituu tuotteen elinkaarellisten informaatiopalvelujen hallinnointiin, suunnitteluun ja rakentamiseen. Yritysarkkitehtuurikäytännöt tekevät tuloaan yrityksiin ja julkiselle puolelle. Trendi kuvastaa ICT-alan kypsyystason nousua tekeminen alkaa vakioitua ja tietojärjestelmäpalvelut saavat vihdoin oman elinkaarensa ja liiketoiminnallisen kytköksen. Kun TOGAF, yksi tunnetuimmista yritysarkkitehtuurin viitekehyksistä mainitsee arkkitehtuurityön visioksi Boundaryless Information Flow, within and between Enterprises niin sopivaksi PLM-yritysarkkitehtuurin visioksi sopisi hyvin: Boundaryless Product Information Flow within and between Enterprises. Tämä on PLM-yritysarkkitehtuurin käytäntöjä käsittelevän artikkelisarjan johdantoosa. Aihettä käsitellään myös 27.3.2012 Uusia työkaluja ja arkkitehtuureja -seminaarissa, kts. s. 7. Aiheen käsittely jatkuu seuraavassa lehdessä. 32 Valokynä 1/2012

Seppo Narinen www.nice.fi Seppo toimii PLM-konsulttina Nice-business Solution Finland Oy:ssä. Nice on Fujitsun ja Nokian omistama 400 hengen ICTpalveluyritys, jolla on toimintaa Suomessa, Englannissa ja Intiassa. Nicen suurin yksittäinen palvelu on PDM Service Management. T uotejalostus on jokaisen yrityksen primus motor - ei yritystä ilman tuotetta. Yrityksen tuotteiston jalostusprosessista itselleen ottama jakso määrittelee, millaista tietämystä ja toiminnallisuutta yrityksen kannattaa ylläpitää, mukaan lukien ulkoinen tieto, kuten kilpailijoiden edesottamukset. Kaikki toiminta ja panostus tähtäävät tuotteen jalostamiseen jopa henkilöstöhallinto osallistuu jalostustalkoisiin ylläpitämällä sopivia rooleja myyntiin, suunnitteluun, valmistukseen tai henkilöstöhallintoon lupaamalla hankkia tarvittavat resurssit erilaisiin tarpeisiin. Yritysarkkitehtuurikäytäntö Enterprise Architecture ymmärretään tyypillisesti järjestäytyneenä tapana ohjata, suunnitella, rakentaa ja monitoroida yrityksen ICT-resursseja. Ohjaukseen assosioituu hallinnointi governance, Arkkitehtuuri-sanaan eheys, kokonaisvaltaisuus ja metodologisuus. Muita arkkitehtuurikäytännön tuottamia hyötyjä voisivat olla arkkitehtuurin tarkoituksenmukaisuus, tehokkuus, ajantasaisuus ja ketteryys asiakkaan eli liiketoiminnan muutoksiin. Tuotetta painottavan johdannon jälkeen olisi halu sanoa, että yritysarkkitehtuuri ja PLMyritysarkkitehtuuri ovat sama asia. Puhtaasti kompromissisyistä kuvaan PLM-arkkitehtuurin osajoukkona yrityksen koko arkkitehtuurista kelpuuttamalla vain tuotehallinnan keskeisimpiä resursseja PLM-arkkitehtuuriin. Käytännönläheisyytensä vuoksi näin juuri kannattaa tehdä samalla kuitenkin visusti vartioiden määrittelytapojen (hallintomalli) ja tulosten (arkkitehtuuri) eheyttä yrityksen kokonaisarkkitehtuuriin. Tämä on tietoinen riski, mutta ei mielestäni ole perimmiltään ristiriidassa ortodoksien kanssa esimerkiksi TOGAF julistaa, että kukin arkkitehtuurisykli sisältää aina vain rajatun fokusalueen koko arkkitehtuurista. PLM tarvitsee oman elinkaaren ennakoidakseen liiketoiminnan ja tuotteiston muutokset. PLM:n on laajennuttava operatiiviselta alueelta tuotetiedolla johtamisen alueelle sekä PLM:n palveluhallinnan alueelle, jotta PLM:n yhdenmukaisuus ja suorituskyky vaateet täyttyisivät. Valokynä 1/2012 33

Olen viimeisen vuoden harjoittanut PLM-spesifisen yritysarkkitehtuurin viitekehyksen mallintamista. Kurssit käyneenä olen tullut siihen tulokseen, että arkkitehtuurimallit ainakin kurssien ja viitekehysten kautta nähtynä ovat kovin geneerisiä ei yritystyyppikohtaisia referenssimalleja, ei sanaakaan tuotehallinnan eritysipiirteistä arkkitehtuurissa, puhumattakaan tuotetiedon omistajuus- ja käyttöoikeushallinnasta tms. Vuoden ponnistelujen jälkeen on laariin kertynyt konsepti viitekehyksen struktuuriksi ja koko joukko täsmäreferenssimalleja kytkettynä liiketoimintamalliin, tuotteiston tiedonhallinnallisiin vaateisiin, tuotetiedonhallinnan prosesseihin, sovelluksiin, tietomalleihin ja ICT-infrastruktruuriin ja näiden kaikkien komponenttien konfiguroimiseksi kutakin liiketoimintamallia ja tuotetta vastaavaksi PLM palveluksi! Lopuksi neljä löydöstä, joihin liiketoimintalähtöisen PLM-arkkitehtuurin viitekehyksen pitäisi mielestäni antaa ohjenuoraa arkkitehtuurikäytännöstä kiinnostuneille ja PLM-arkkitehtuurityötä suorittaville. PLM YRITYSARKKITEHTUURIN VIITEKEHYS Nykyinen ajattelutapa 1. PLM on ratkaisu Tuotteen elinkaaren hallintaan. 2. PLM-vastuualue kattaa operatiivisten tuoteprosessin tuotetiedon elinkaarellisen tuen (ECM). 3. PLM-ratkaisu rakentuu kehitysprojektin tuloksena. 4. PLM-projekti yrittää tunnistaa päällekkäiset hankkeet ja valitsee omat käytäntönsä. Uusi ajattelutapa 1. PLM tulisi olla eri liiketoimintamallien palveluportfolio. 2. PLM vastuualueella tulisi olla myös Tuotetietojohtaminen (Engineering BI), PLM Governance ja PLM Palveluhallinta. 3. PLM-käytänne tulisi olla ajallinen ja elinkaarellinen jatkumo: Plan-Build- Operate-Monitor. 4. PLM elinkaaren hallinnan tulisi noudattaa hyvän hallinnon ja kokonaisarkkitehtuurin käytäntöjä. PLM-löydökset, nykyinen ja uusi ajattelutapa. Asiakkaiden kokema pysyvä nautinto syntyy vain laadukkailla hyödykkeillä. PLM-arkkitehtuuri, Case-tarina Aika ajoin tärkeimmäksi liiketoimintaa tehostavaksi tekijäksi nousee joko asiakkuuden hallinta, rahoituksen hallinta, jakeluverkon hallinta tai vaikkapa tiedolla johtaminen. Kuinka tärkeä tuotejalostus on yritykselle? Soitin autohuoltoon ja varasin ajan vaimoni autolle vaimo valittaa, että takapyörästä kuuluu erilaista ääntä. Pyysin myös suorittamaan seuraavan määräaikaishuollon samalla kertaa. Kotona päätin tarkastaa, kuinka ajankohtainen tuo määräaikaishuolto onkaan, ja huomasin että vastahan puolet 20.000 km huoltovälistä on mittarissa. Soitin seuraavana päivänä huoltoon ja pyysin jättämään huolto-osuuden pois. OK! Kaksi viikkoa myöhemmin huoltopäivä oli käsillä ja ilahtuneena huomasin, että merkkiliike oli panostanut asiakkuudenhallintaan. Ei enää kynsiään leikkaavia, jalkoja pöydällä makuuttavia huoltopäälliköitä vaan kiiltävät kalusteet ja pojilla sävy sävyyn kravatit. Huomasin huoltomääräyksen asiakaspalvelijan hyppysissä ja ylösalaisin tekstiä tavatessani silmiini osui tuo 20.000 huolto. Totesimme yksimielisesti, että sehän olikin sovittu peruutettavaksi. Iltapäivällä autoa hakiessani sain selonteon tehdystä työstä, ei enää avainnipun heittoa pöydälle eikä lausetta Ei siinä mittään, se tekis 2000. Kiitos korjatun asiakaspalvelun, Nyt huoltopäällikkö ilmoitti kohteliaasti: Autonne on valmis ja siihen on tehty 20.000 km huolto. Kysyin, että mitenkäs se takapyörä? Vastauksena oli empivä Eei siinä mitään Kitinä jatkui - kotona poistin kiven jarrulevyn ja satulan välistä peruuttamalla vähän ja kaikenlainen kitinä loppui siihen. Tarinan opetus: Asiakkaiden kokema pysyvä nautinto syntyy vain laadukkailla hyödykkeillä. Laadukkaat hyödykkeet syntyvät vain laadukkaalla tuotejalostustoiminnalla ja tietämyksellä. Laadukas tuotejalostus syntyy liiketoimintamalleja ja tuoteportfoliota tukevilla tuotetiedonhallinnan resursseilla. Ajantasainen, tarkoituksenmukainen ja tehokas tuotetiedonhallinnan tuki luontuu vain PLM-arkkitehtuurikäytänteillä! 36 Valokynä 1/2012

Seppo Narinen PLM-yritysarkkitehtuuri, OSA II Tämä on jatkoa Valokynässä 1/2012 (ss 32-36) käynnistyneeseen PLM-yritysarkkitehtuuria ja sen viitekehystä käsittelevään artikkelisarjaan. Artikkeleissa esitetyt ajatelmat eivät suinkaan ole kiveen hakattuja, vaan yritelmä jäsentää kokemuksen sirpaleita strukturoiduksi kokonaisuudeksi. Parasta mitä tällä voi saavuttaa on kiukku, jolloin poltteesta nousee parannettu PLM-skeema. CCY toivookin saavansa lukijoilta palautetta tai vastaavia artikkeleita julkaistavaksi! PLM-yritysarkkitehtuuria ja sen viitekehystä käsittelevän sarjan tässä osassa lohkotaan neljä viisastenkiveä osiin ja katsotaan missä mahdollinen viisaus piilee. Johdanto-osassa ehdotettiin PLM-visioksi seuraavaa: Boundaryless Product Information Flow within and between Enterprises. Tarjolla yritystasoisen PLM:n viitekehyksen perustaksi oli neljä viisastenkiveä: 1. PLM on liiketoimintamallien palveluportfolio. 2. PLM kattaa operatiivisen tuotetiedon, tuotejohtamisen, PLM hallinnoinnin ja PLM palveluhallinnan (käyttötuen). 3. PLM-käytänne on ajallinen ja elinkaarellinen jatkumo: Plan Build Operate Monitor PLM. 4. PLM on erottamaton osa hyvää hallintoa ja kokonaisarkkitehtuurin käytäntöä.

PLM kuvattiin yritysarkkitehtuurin vertikaalisena osajoukkona, jossa prosessiarkkitehtuuri, informaatiojärjestelmäarkkitehtuuri ja teknologia-arkkitehtuuri muodostavat PLM-palveluiden portfolion. PLM liiketoimintamallien palveluportfoliona Ajan henkeen kuuluu, että asioiden tulee olla liiketoimintasensitiivisiä ja hyvä niin. Harmillisesti sanoista ei ole päästy ihan tekoihin saakka. Puuttuu tiedon ja toiminnan relaatiomalli ydinliiketoiminnan ja tukitoimintojen sidosryhmien väliltä. PLM palveluportfoliolla tässä tarkoitetaan erityisesti seuraavaa. Sisältö: Portfolio on palvelunantajan kirjasto PLM-yritysarkkitehtuurin komponenteista. Aikanäkökulma: Kirjastossa on vanhentuneita, nykyisin käytössä olevia ja tulevia, palveluputkessa olevia komponentteja. Komponentti voi olla vaikkapa uusi prosessi, uusi CAD-järjestelmä, sen ominaisuus tai koulutusmoduuli. Palvelu-sana portfoliossa viittaa liiketoiminnalliseen käyttöhyötyyn. PLM:n palveluportfolio noudattaa elinkaarta. Asiakas näkee voimassa olevat palvelut (ITIL: Service Catalogue). Palveluilla olisi hyvä olla status. ITIL:iä vapaasti lainaten statukset voisivat olla: vaatimukset määritelty analysoitu hyväksytty spesifioitu suunniteltu kehitetty rakennettu testattu julkaistu käytössä eläköity. Kirjasto kuvaa ja antaa vastauksen siihen, mikä liiketoiminnallinen hyöty kustakin palvelusta on ja auttaa kehittämään palveluja. Yleisarkkitehdit suosittelevat pal- Elinkaaren mukaanotto palveluhallintaan, tilanne ennen ja jälkeen. Jälkimmäisessä kuvassa on korostettu portfolion PLMpalvelujen modulaarista luonnetta ja elinkaarta.

veluportfolion hallintaan tietokantaa tai strukturoitua dokumenttia. Lukija nähnee tuoteasiantuntijana tässä valon leimahduksen: PLMpalvelu sisäisenä tuotteena, miksipä siis ei PDM-välineitä kehiin? Kuitenkin isompi kysymys on, miten PLM-palveluportfolio seuraa tai pikemminkin ennakoi innovatiivisesti aikaansa, liiketoiminnallisia muutoksia? Kysymys on tietysti ensisijaisesti eri asioista kiinnostuneiden tahojen yhteen saattamisesta ja toimintatavasta. Ennen kuin mennään hyvään hallinnointiin, katsotaan mikä tuon toiminnan kohde voisi olla, jotta meillä olisi käytettävissä puuttuvat pari tolpanväliä lankaa liiketoiminnan vaateiden ja palvelujen tuotosten välillä (kielikuva lainassa ystävältäni Timo Paleniukselta). PLM-palvelun vastuualue Toinen viisastenkivi sisälsi ajatuksen, että PLM-vastuualueen tulisi olla laajempi kuin operatiivinen tuotetiedonhallinnan PLM-palveluportfolion proaktiivinen kehittäminen liiketoiminnan nykyisten ja tulevien vaateiden mukaiseksi vaatii organisatorista yhteistyötä ja tietämyksellistä kyvykkyyttä. Vuosiluvut kuvaavat kirjoittajan käsitystä PLM-yritysarkkitehtuurista vuosien saatossa. Vuonna 1993 PLM edusti kohdealueen ICT-arkkitehtuuria ilman strukturoitua liiketoiminnallista kytköstä tai palvelunäkökulmaa. Myöskään portfoliomallia ei tällöin tunnettu, eli varautumista huomiseen. Vuonna 2011 kuva PLM-arkkitehtuurista käsitti kytköksen liikeideoiden portfolioon. Kussakin liikeideassa oli vahvana attribuuttina tuote. Nokialaisittain kuvaten Symbian 30, 40 ja 60 olisivat nykyisiä liikeideoita, OVI store, Meego, Windows aikanaan orastavia liikeideoita omine tuotteineen, ja S60 kohta eläköityvä liikeidea. Koska PLM-arkkitehtuurin kontekstissa kuitenkin tuote ja tuotteen jalostamistarpeen mukainen tuotetieto ovat kaiken primus motor, liiketoimintasensitiivinen PLM-yritysarkkitehtuuri sai vuonna 2012 liikeideoiden ja PLM-yritysarkkitehtuurin väliin tuotearkkitehtuurin. Analysoimalla ja tuntemalla kunkin liikeidean tuote pitkin sen elinkaarellista vaellusta on luotavissa tarkka ja muutoksia seuraava (oikeammin: ennakoiva) vuorovaikutuskäytäntö liikeideoiden ja niitä tukevan PLM-palvelun välille. Onko joku, jolla jo on olemassa seuraava PLM über-arkkitehtuurin eli kokonaisarkkitehtuurin viitekehyksen skeema? Itselläni kesti parikymmentä vuotta piirtää viimeinen kuva. Uskon, että nuoremmat kollegat pystyvät samaan ehkäpä jo 18 vuodessa, niin kiihtyy ajan kulku!

tuki. Oheinen taulukko kuvaa lähtökohdan ja ehdotuksen uusista aluevaltauksista. Operatiivinen tuotetiedonhallinta tarkoittaa tuoteprosessin ja tilaus-toimitusprosessin tarvitsemia muutoshallinnan prosesseja, suunnittelujärjestelmiä jne. Tuotejohtaminen olisi business intelligenssiä, tukea päätöksenteolle kun eteen ja kontekstiksi laitetaan sana Tuote. Ts. tarjolla olisi analyysipalveluja itse tuotteesta sekä tuotetiedon prosessoinnista. Mikä on nimikkeistön uudelleenkäyttöaste? Kuinka monta nimikettä on ristiin käytettävissä eri tuotelinjojen kesken? Mikä on tuotemuutosprosessin vaihteluväli? Mistä ajoittainen muutospyyntöjen ruuhkautuminen johtuu? Tämä on suuri aihealue johon liittyy metriikka, asiakkaan haluamat näkymät (ei vain ne näkymät, jotka on helppo tuottaa), data warehouset, mash-upit, some jne. PLM-vastuualueen lähtökohta ja ehdotus uusista aluevaltauksista. PLM:n elinkaari Kun loppukäyttäjä näkee PLMpalveluportfoliosta vain julkaistut eli aktiivitilassa olevat palvelut niin PLM:n kehittämisen oman kyvykkyyden kannalta tarvitaan valmistelevia ja laaduntarkkailun toimintoja ja palvelujen tiloja, joiden avulla julkaistavat palvelut ovat virheettömiä ja keskenään yhteensopivia. Kehitetty malli on sukua Demingin laatusyklille, sama joka löytyy myös esim. Cobitin viitekehyksestä. Elinkaaren vaiheiden neljä englanninkielistä nimeä on sovitettu parhaiten kuvaamaan PLM-arkkitehtuurin päävaiheita. Menemättä tarkemmin PLM Plan ja PLM Build -vaiheiden sisältöihin katsotaan hieman tarkemmin PLM Operate -vaihetta ja PLM Monitor -vaihetta. PLM Operate-vaihe sisältää liiketoimintaideakohtaisen konfiguraation PLM-palveluista, jotka ovat liiketoiminnallisessa hyötykäytössä. Kohdassa 2 jo esitettiin ehdotus uudeksi PLM-vastuualueeksi, PLM ARKKITEHTUURIN BUSINESS CASE PLM Arkkitehtuurikäytännöllä saavutettavat hyödyt Parempi liiketoiminnan tuki parempi kommunikointi IT:n kanssa - EA governance parempi strateginen ja operatiivinen tuotejohtaminen (Engineering BI) parempi palveluiden hallinta - PLM service management parempi tiedon laatu - PLM data governance Tehokkaampi IT: parempi PLM-palvelujen konfiguraatiohallinta parempi PLM-palvelujen muutoshallinta parempi PLM-palvelujen turvallisuushallinta edullisempi ohjelmistokehitys, tuki ja ylläpito joustava palvelujen hankinta; itse, ostot eri toimijoilta, ulkoistus selkeät vastuut ja koordinointi PLM viitekehyksen tehtävät kuvata PLM-informaatiojärjestelmän kytkentä liiketoimintamalleihin kuvata kattavan ja eheän PLM - informaatiojärjestelmän osaset: PLM arkkitehtuuri ohjata mitä meidän on tehtävä, jotta PLM täyttää vallitsevat yhdenmukaisuus ja tehokkuusvaatimukset: PLM Conformance Performance vaateet tarjota työn tekemistä edistäviä käsitteitä, keinoja ja hyviä käytäntöjä

joka sisältäisi seuraavat neljä osa-aluetta: Operatiivinen PLM, Tuotejohtaminen, PLM-hallinnointi ja PLM-palveluhallinta. PLM-hallinnointi vaatisi lisää mallintamista viitekehyksen täydentämiseksi. Itselleni assosioituu PLM-governanceen ainakin tuotetiedon laadun hallinnointi (kuka teillä oikeastaan omistaa tuotetiedon, tuki, business vai Joku?) PLM-tuen hallinnointi (esim. ITIL Service Management sisältää käyttötuen hyvän hallinnoinnin) ja PLM-yritysarkkitehtuurin hallinnointi. Hyvä hallinnointi onkin monipiippuinen juttu, ihan kuin tuotteen elinkaari (minkä tuotteen, mikä ihmeen elinkaari?). PLM Monitor-vaihe sisältää jatkuvan palvelujen yhdenmukaisuuden ja tehokkuuden (conformancen ja performancen) mittaamisen palvelujen edelleen kehittämiseksi. On selvää, että mittaamista suoritetaan kaiken aikaa, eikä ajallisessa mielessä Operate- Ehdotus PLM:n oman elinkaaren neljäksi päävaiheeksi. On harmillista, että sana cycle on latistunut suomennuksessa kaareksi. Elinkaarta lähinnä vastaava sana life span tarkoittanee jotain muuta, lähinnä tuotteen hengissäoloaikaa. Tähän täytynee palata tulevaisuudessa. vaiheen jälkeen. Nelivaiheisessa PLM-elinkaaressa kysymys ei siis ole puhtaasti kronologisesta elinkaarimallista vaan jonkinlaisesta kypsyyden laatuympyrästä! Samaten Plan- ja Build-vaiheita tehdään inkrementaaliperiaatteella, eli kaiken ja on eri tiloissa. Systems engineering ja release management antaisivat hyviä käytäntöjä kehityksen roadmappaamisesta ja palvelukonfiguraation hallitusta transitioista ja julkaisemisesta käyttöön. Sanottakoon vielä selvyyden vuoksi, että PLM-arkkitehtuurilla ja arkkitehtuuriprosessilla tarkoitetaan tässä kaikkien näiden vaiheiden suorittamista ja tuloksia. Arkkitehtuuri ei siis ole vain paperi, vaan sisältää omistajuusnäkökulman esim. ohjelmistoräätälöintien koodiin, joka on PLM Build -vaiheen tuotos. PLM osana hyvää hallintoa ja kokonaisarkkitehtuuria Ajatusmallin muutos PLM-palvelujen/arkkitehtuurin eri elinkaaren vaiheiden vaatimassa työssä tarkoittaa siirtymistä pois kertaluonteisista projekteista ja Liiketoimintasensitiivinen PLM-yritysarkkitehtuurin viitekehys. Oikealla reunalla on tekemisen kohteet, eli kolme yhteen nivoutuvaa arkkitehtuuria: Liiketoiminta-arkkitehtuuri, Tuotearkkitehtuuri ja PLM-yritysarkkitehtuuri. Pystyviivat kuvaavat kunkin liiketoimintaidean tuote- ja PLM-yritysarkkitehtuurin konfiguraatiota. Osa palveluista soveltuu (toivon mukaan) useille liiketoimintaideoille, osa palveluista joudutaan rakentamaan spesifisesti jollekin businekselle. Vasemmalla laidalla on prosessit, joilla tuloksia syntyy. Samoin vasemmalla on elinkaaren ympyrä PLM-yritysarkkitehtuurin päävaiheille.

Vasemmanpuoleinen kuva edustaa PLM:n kansanperinnettä. Oikeanpuoleinen kuva yhdistää edellä kuvatun PLM-palvelujen vastuualueen laajennuksen ja PLM:n sisäisen elinkaaren. Manage viittaa tuotejohtamiseen, Operate funktionaaliseen PLM:ään ja Serve viittaa käyttöpalveluihin ja PLM:n elinkelpoisuuden ylläpitämiseen. omavaltaisista metodologiavalinnoista. Vaikkakin tässä yhteydessä esitetään, että PLM tarvitsee oman viitekehyksensä, se ei tarkoita sitä, etteikö PLM:n vertikaalinen arkkitehtuurityö pitäisi sopeuttaa ja yhdistää yrityksen jo mahdollisesti käyttöön ottamaan arkkitehtuurin viitekehykseen ja arkkitehtuuriprosessiin. Kaikki kuvatut päämäärät voidaan hyvinkin suorittaa tarjolla olevilla metodologioilla ja kokonaisarkkitehtuurin viitekehyksillä. Tavoitteena on vain huolehtia siitä, että PLM saa arvoisensa paikan yrityksen kokonaisarkkitehtuurissa (EA) ja arkkitehtuurityössä, siksi tärkeä Tuote ja tuotteen jalostusprosessi viime kädessä on yrityksen hyvinvoinnille ja todelliselle asiakastyytyväisyydelle. Hyödyke-sana kuvaa parhaiten tuotteen asiakasnäkökulmaa. Hyväkään CRM (Customer Relationship Management) ei tee asiakasta onnelliseksi, jos tuote ei vastaa tai ylitä asiakkaan odotuksia. Todettakoon lopuksi, että arkkitehtuuritoiminta kannattaa jakaa kahteen pääprosessiin: PLMhallintoprosessi (Governance) ja PLM-arkkitehtuuriprosessi. Yhteenveto Paras yhteenveto lienee holistinen kuva. Ylhäällä oleva kuva esittää PLM-palvelujen vastuualueen laajennuksen ja PLM:n sisäisen elinkaaren. Toinen kuva, joka sijaitsee edellisellä sivulla liiketoimintasensitiivisen PLM-yritysarkkitehtuurin viitekehyksen. Seuraavassa numerossa: PLM-yritysarkkitehtuuria käsittelevässä osassa III esitellään mm. halpoja keinoja, joilla liiketoiminnan vaateet puretaan PLMpiirteiksi. toräätälöintien Seppo Narinen toimii PLM-konsulttina Nice Business Solutions Finland Oy:ssä. www.nice.fi Varmista itsellesi CAD/CAM/PLM/BIM-alan Suomen 30-vuotinen historiateos. Tee ennakkotilaus jo tänään! Tilaushinta 44,00 + postituskulut. Jäsentilaushinta ainostaan 24,00 + postituskulut. Tilaukset: www.cadcamyhdistys.fi

Seppo Narinen Uutiset PLM-yritysarkkitehtuuri, OSA III Valokynät 1 ja 2/2012 sisälsivät karkean mallin PLM-alueen yritysarkkitehtuurista. On selvää, että tuoteinformaation hallinnoinnin ja käyttöönoton on oltava osa yrityksen ja sen sidosryhmien kokonaisarkkitehtuuria. PLM-yritysarkkitehtuuri visio Boundaryless Product Information Flow within and between Enterprises. Valokynä 3/2012 19

Uutiset On kuitenkin hyödyllistä varjella ja kehittää PLMalueelle geneerisiä viitekehyksiä syvemmälle meneviä arkkitehtuurikäytäntöjä ja työkaluja. Yksi tällainen struktuuri on liiketoiminta-arkkitehtuurin sitominen PLM-arkkitehtuuriin tuotearkkitehtuurin kautta. Viereinen kuva, vasen reuna. Hyvä argumentaatio tarkoituksia vastaavaksi PLM-arkkitehtuuriksi edellyttää kunkin liikeidean tai liiketoimintayksikön sisältämän tuotteen tai palvelun ominaisvaateiden tunnistamisen ja pitämisen ajan tasalla. Yrityksessä voi olla liiketoimintayksikkö, joka tuottaa hyvin standardoitua laitetta ja toinen yksikkö, joka toteuttaa projektina saman oloisia tuotteita yksilöllisiin asiakastarpeisiin (mutta voi samalla hyödyntää standardiplatformista yksittäisiä moduuleita) ja kolmas yksikkö, jonka tuote on kumpaisenkin yhdistelmä sisältäen kilpailijoiden laitteiden huollon ja päivitykset. Näiden tuotteiden informaatiologistiikkaa pitää tarkastella kutakin erikseen ja yrittää löytää yhtenevät ja erilaiset tiedot ja tiedonkäsittelyt. Seuraavassa on hyvin karkea vaihejakomalli liikkeelle lähdöstä PLM-yritysarkkitehtuurin (PLM EA, PLM Enterprise Architecture) suhteen, kuva 2. Karkeasti jao- PLM-yritysarkkitehtuurin viitekehys. PLM informaatioarkkitehtuurin ja liiketoimintaarkkitehtuurin konkreettinen yhteys syntyy tuotearkkitehtuurin kautt (oikea reuna). PLM-palvelujen vaatimustenmukaisuus toteutuu PLM hallinnointi- ja arkkitehtuuriprosessilla sekä hyvällä metodologialla PLM-viitekehyksellä (vasen reuna). teltuna tarvitaan ensin sopimus PLM-arkkitehtuurin käyttöönotosta. Sen jälkeen voidaan itse arkkitehtuuritoiminta käynnistää, jossa keskeisenä PLM vaatimusten keruuinstrumenttina on tuo edellä kuvattu tuotteiden tunnistaminen ja tuotteiden analyysi. PLM-arkkitehtuurikäytännön aloittaminen. Ensin tulisi sopia käytännöistä ja omistajuuksista. Tämän jälkeen voidaan tuottaa ensimmäinen baseline PLM-arkkitehtuurista. PLM-arkkitehtuuri tarvitsee kuitenkin tuekseen ymmärrystä liiketoiminnasta ja tuotteista. 20 Valokynä 3/2012

PLMarkkitehtuurikäytäntöjen käyttöönotto VAIHE 1 /AUDIT: Tehdään PLM yritysarkkitehtuurin kypsyysarviointi suhteessa tarpeeseen. Kompleksinen yritys tai tuote isot vaateet ja päinvastoin! VAIHE 2 /GOVERNANCE: Määritellään PLM-arkkitehtuurin omistajuus ja toimintamalli. VAIHE 3 /ARKKITEHTUURI: Määritellään PLM-arkkitehtuurin tuottamisprosessi. VAIHE 4 /PLM EA VIITEKE- HYS: Valitaan ja sovitetaan PLMarkkitehtuurin viitekehys omaan toimintaympäristöön ja otetaan se käyttöön. PLM-arkkitehtuurin toteuttaminen Edellisissä artikkelisarjan osissa on jo esitetty, miten arkkitehtuurityö voisi olla jatkumo ja noudattaa nelivaiheista laatusykliä: Plan Build Operate Monitor PLM (suunnittele-rakenna-käytä-seuraa), kuva edellisen sivun alareunassa. Tyydytään tarkastelemaan Plan-vaihetta lähemmin, kuva 3. VAIHE 1/LIIKETOIMINTAMALLI: Tarvitaan kuvaus liiketoimintamallista. A4 lähes riittää, kunhan siinä on meille tarkoituksenmukaiset attribuutit: nykyiset ja tulevat liiketoimintaideat ja kunkin liiketoimintaidean ominaispiirteet, tärkeimpänä tuotteet ja kunkin liiketoimintayksikön johdon uskomukset tuotteen menestystekijöistä hinta, laatu, toimitusaika, toimitusvarmuus yms. VAIHE 2 /TUOTEANALYYSI: Kuljetaan kunkin tuotteen selässä läpi tapahtuma- ja tietovirta, jonka tuotteen eri ilmentymät käyvät läpi. Voi olla tarpeen mallintaa esimerkiksi komponenttien, kokoonpanojen, suunnittelumallin, toimitettujen yksilöiden sarjanumeroitujen osien tapahtumaketjut skenaarioina. VAIHE 3 /VISIO JA HYVÄT KÄY- TÄNNÖT: Yritetään tunnistaa maailmanluokan hyviä käytäntöjä eri tuotteiden menestystekijöiden tukemiseksi lean, massaräätälöinti, toimittajaverkko, web tms. Myös PLM-visio on hyvä kirjoittaa seinätauluksi, jotta PLM:n omaa elinvoimaisuutta ja yhteiskäyttöisten resurssien potentiaalia ei hukattaisi. VAIHE 4 /MITTARIT: Muodostetaan mittaristo, jolla johdon mielestä kriittisiä menestystekijöitä voidaan mitata. VAIHE 5 /PROSESSIKONSEP- TIT: Mittarit jyvitetään prosesseille, joissa tuotteet käyvät vaiheen 2 perusteella.prosessiomistajien kanssa sitten mietitään, millä konsepteilla prosesseista saadaan mittareiden indikoimat tuottavuudet. VAIHE 6 /RESURSSIT: Määritellään ja mitoitetaan prosessien tarvitsemat ICT- ja muut resurssit. Tämän jälkeen ryhdytään tuumasta toimeen: suunnitellaan vaateiden mukainen PLM-arkkitehtuuri, sitten toteutus, käyttö, monitorointi ja sama uudelleen! Esimerkki tuoteanalyysistä, PLM-arkkitehtuurin toteuttamisvaihe 2. Kuvassa esitetään, kuinka asiakkaan tilauspiste voi vaihdella riippuen liikeideasta. Yrityksellä voi olla esim. standardituotelinja ja projektituotelinja siis ainakin kaksi keskeisesti erilaista elinkaarta. Kumpaakin elinkaarta pitää voida tukea Valokynä 3/2012 21

mieluiten minimaalisella määrällä PLM-palvelukomponentteja - tästä yritysarkkitehtuurissa on perimmiltään juuri kysymys: kuinka tehdä konfiguroituva palvelualusta monimuotoiseen ja muuttuvaan liiketoimintaan? Yhteenveto Paljon on kuvattu, millainen PLM:n tulisi olla. Vähemmän on kuvattu, miten ennakoida ja ylläpitää muutosta, jossa tasapainoisella tavalla tuotettaisiin aidosti liiketoimintaa tukevia PLM-palveluita. Paitsi palvelujen sisällöllinen tarkoituksenmukaisuus ja tehokkuus, niin erityisesti palvelujen ennakointi ja toteuttaminen joutuisasti vaativat yrityksiin toimintamallin ja pysyviä resursseja, jotka käyvät jatkuvaa ja strukturoitua vuoropuhelua liiketoimintayksiköiden omistajien kanssa. Tarvitaan PLM:n sisäinen elinkaari tai pikemminkin sykli, jota tässä artikkelisarjassa on kutsuttu PLM EA käytännöksi. Artikkelisarjan 4. osassa kuvataan, mitä tarkoituksenmukainen PLM-yritysarkkitehtuurin viitekehys voisi sisältää. Seppo Narinen Aineisto perustuu osittain kirjoittajan tuottamaan materiaaliin Nice-business Solutions Finland Oy:ssä. Kirjoittaja on artikkelin toimittamisen jälkeen ryhtynyt riippumattomaksi tuotearkkitehdiksi. Sami Mattila ipad3:n onnellinen voittaja CAD/CAM/CAE/PLM/BIMkyselyyn vastanneiden kesken arvottiin ipad3 tablet-tietokone. Tänä vuonna palkinnon voitti Sami Mattila, 42, SAV Oy:n Tampereen toimipisteeltä. Sami on pitkän linjan suunnittelija. Hän aloitti CAD-uransa jo vanhempiensa putkiliikkeessä pari kymmentä vuotta sitten. Tietokoneista kiinnostunut Mattila otti tuolloin käyttöön CADS-ohjelmiston. Ammattiopintonsa hän aloitti putkiasentajan linjalla Pirkanmaan ammattikoulussa, Tampereella. Tämän jälkeen kiinnostus vei miehen Mikkelin teknilliseen oppilaitokseen LVI:tä opiskelemaan. Jyväskylän ammattikorkeakoulussa hän on lisäksi opiskellut teollisuusputkisto- ja paperitehdassuunnittelua. Työurastaan Mattila kertoo seuraavaa: Opintojeni jälkeen toimin jonkin aikaa LVI-suunnittelijana. Työnantajani Jyväskylässä oli Mastek, kunnes muuttui Elomaticiksi yrityskaupan myötä. Tuolloin pääasiallisesti tein töitä silloiselle Valmetille, joka muuttui Metsoksi. Putkistosuunnittelun lisäksi tein myös esim. LAY-OUT-suunnittelua, hoitosiltasuunnittelua ja levystöjen poistokanavia (viirakanavia ja Flumeja). Nykyisessä työpaikkassaan, SAV Oy:ssä, Sami on toiminut vuodesta 2007. Suunnittelu ja Asennusten Valvonta, SAV Oy, on teknisen alan palveluja tarjoava valtakunnallinen insinööritoimisto. Vuonna 1993 perustetun yhtiön palveluksessa on yli 190 teknisen suunnittelun ammattilaista. SAV Oy:n asiantuntijapalvelut kattavat kaikki projektin vaiheet esisuunnitte telusta investoinnin Sami Mattila toteutuksessa tarvittaviin suunnittelu- ja ja projektihallintapalveluihin sekä koestus- ja käyttöönottotehtäviin. Yrityksen suunnitteluosaaminen kattaa seuraavat osa-alueet: automaatio-, sähkö-, kone-, laitos- ja LVI-suunnittelu sekä projektihallinto. SAV Oy:llä on toimistot kahdeksalla paikkakunnalla: Kajaanissa, Kemissä, Kouvolassa, Lappeenrannassa, Oulussa, Porissa, Siilinjärvellä ja Tampereella. Mattila pääsee monipuolisesti hyödyntämään vuosien varrella hankittua tietämystään. Suunnittelutehtävien lisäksi hän on CADS-suunnittelujärjestelmän ylläpitäjä Tampereen toimipisteessä. Sami Mattilan sanoin: on hyvä, että pienessä työpaikassa on monipuolinen työ ja voi auttaa muita aina tarvittaessa. SAV Oy:llä on Tampereen toimipisteessä käytössä mm. AutoCAD, Autodesk Inventor ja CADS. Sovellusohjelmistoja käytetään silloin, kun ne ko. tekemiseen tuovat helpotusta. Nykyään 3D valtaa alaa ja suurin osa suunnitelmista tehdään 3D:ssä. Kolmiulotteisuus mahdollistaa todenmukaiset törmäystarkastelut ja entistä tarkemmat analyysit. Mattilan sanoin: Ennen tehtiin varman päälle. Nyt voidaan optimoida rakenteet tarkemmin. Oli yllättävä kuulla, että 3D:n vallankumous on räjähdysmäisesti tapahtunut vasta viime vuoden aikana. Ohjelmistojen kehityksestä Mattila toteaa, että erilaiset automaattiset toiminnot, kuten esim. mitoitus, ovat lisääntyneet. Myös mallinnustoiminnot ovat monipuolistuneet. Mattilan mielestä on silti erittäin tärkeää, että suunnittelija tietää, mitä on tekemässä, jotta analyysien tulokset voidaan tulkita oikein ja suunnitelmista tulee helposti toteutettavia. Käyttäjien toiveiden huomioon ottaminen ohjelmistoja kehittäessä vaihtelee toimittajan mukaan. Sami on ollut tyytyväinen kotimaiseen ohjelmistotoimittajaan: Asiakaspalaute on otettu hyvin huomioon ja toivottuja ominaisuuksia on tullut uusiin versioihin. SAV Oy toimii usealla paikkakunnalla ja projektien yhteydessä tehdään laajaa yhteistyötä eri tahojen kanssa. Yhteistyötä helpottaa selainpohjaisesti käytettävä tiedonhallintajärjestelmä. Tällä voidaan taata, että kaikilla osapuolilla on yhteneväinen käsitys projektista, ja pääsy viimeisimpään tietoon. Informaatio kulkee myös järjestelmän kautta, jolloin sähköpostien lähettämisen tarve vähenee. Verkkokokoukset eivät ole yrityksessä vielä yleistyneet, mutta niiden lisääntyminen on tulevaisuudessa odotettavaa. Lempäälässä asuva Sami Mattila on koko ikänsä harrastanut akvaarioita. Nyt uutena innostuksen kohteena on sukellus. Mukava päästä katsomaan vedenalaisia, rauhoittavia maisemia myös suuremmassa mittakaavassa, kuvailee Sami. 22 Valokynä 3/2012

Seppo Narinen Seppo Narinen Independent Inventor and Product Architect PLM-yritysarkkitehtuuri, OSA 4/4 Tietohallintomalli ja PLM EA Vuoden 2012 Valokynän numeroissa 1-3 on käsitelty PLM-yritysarkkitehtuuria (eng. PLM Enterprise Architecture EA) ja sen erityisominaisuuksia. Sarjan viimeisessä osassa tarkastellaan PLM EA:n liityntää tietohallintoon ja erityisesti ICT-kokonaisarkkitehtuuriin ja luonnostellaan arkkitehtuurin viitekehyksen PLM EA-spesifi siä tarkennuksia. 8 Valokynä 4/2012 3/2012 PLM-yritysarkkitehtuuri visio Boundaryless Product Information Flow within and between Enterprises.

Suomi synnyttämässä yhtenäistä arkkitehtuurikäytäntöä ICT Standard Forum julkaisi 15.11. version 2.0 Tietohallintomallista. Sen konseptoinnin ja kehitystyön takana on useita tietohallinto- ja talousjohtajia, asiantuntijoita ja yhteistyökumppaneita. Advisory Boardin puheenjohtajana on toiminut Ismo Platan, Ruukki. Muita mukana olleita yrityksiä ovat mm. Mandatum Life, Fortum, Outokumpu, Espoon kaupunki, Metsä Group, Kesko,UPM, Wärtsilä, Konecranes, Nokia, Puolustusministeriö, Patria, Enfo, Fujitsu, Logica, Sofigate, Tieto ja Ineo. Tommi Kanto on ICT Standard Forumin toimitusjohtaja ja Juha Huovinen hallituksen puheenjohtaja. Saatavilla on Tietohallintomalli -ohjekirja joka mahtuu povitaskuun ja jonka talousjohtajakin ymmärtää. Tietohallintamallia tehtäessä eri ICT-osa-alueille rakennettujen viitekehysten, kuten COBITin, ITILn ja TOGAFin osioita on koottu yhteen ja rajusti yksinkertaistettu. Hyvä näin! Tietohallintomallilla tavoitellaan tietohallinnon johtamisen de-facto-standardia, niin yritysten kuin julkishallinnonkin avuksi, eikä vain Suomessa vaan koko EU:alueella! Kuva 1. ICT Standard Forumin julkaisema Tietohallintomalli. Lähde: www.tietohallintomalli.fi / Tekijänoikeudet ICT Standard Forum Seuraavassa yritän muutamalla sanalla kuvata Tietohallintomallin julkistustilaisuudessa pidettyjen puheiden pohjalta syntyneitä ajatuksia. Tiedetään, että maailmanmeno monimutkaistuu ja kaikkein monimutkaisinta taitaa olla ohjelmistoteollisuudessa, kannattaa siis seurata sen esimerkkiä! Päivän trendejä ovat nopeus, skaalautuvuus ja ketteryys. On huomattu, että vesiputousperusteinen järjestelmähankinta on aikansa elänyt, koska matkan varrella opitaan ja vaatimukset muuttuvat alati. Mikael Jungerin mukaan perinteinen markkinatutkimusperusteinen innovointi ja sitä seuraava tuotanto myöhästyy markkinoilta. Tarvitaan koepaloja, joita laitetaan ulos ja katsotaan, mikä vetää. - Vaimo meni, mutta puhelinta en vaihda. ICT-arkkitehtuurissa uusimpia haasteita ovat BYOD (BringYourOwnDevice), BigData, mobiliteetti, pilvet, sosiaalinen media ja Master Data. Tietohallintojohtajien kauhuksi työntekijät ovat valmiita mieluummin ostamaan oman kännykän, kuin käyttämään ilmaista yritysstandardin mukaista 6XXX-tuotetta. Nuorissa ohjelmistotaloissa jopa palkasta ollaan valmiita tinkimään, jos vain saa käyttää omia vermeitä! Toki omat laitteet asettavat haasteita vaikkapa tietoturvalle. Mutta esim. Ciscolla säästettiin käyttötuessa, kun omille laitteille ei voitu luvata käyttötukea vaan se perustui käyttäjien keskinäiseen sosiaaliseen mediaan. BYOD:ssa puhutaan kuluttajistuneesta IT:stä. BigData avaa valtavat mahdollisuudet tietoperusteiselle johtamiselle, datan käsittely vain on aikamoinen haaste. Sosiaalinen media muokkaa kovalla kädellä prosesseja, nämä uudet ilmiöt pitääkin ottaa vakavasti arkkitehtuurityöhön mukaan, myös PLM-alueella! Valokynä 4/2012 3/2012 9

PLM-täsmälääkkeet PLM on tietenkin osa tietohallintomallin vastuualuetta ja esim. kaikki vasta julkaistussa Tietohallintomalli, Versio 2:ssa esitetyt hallinnan toiminnot ovat relevantteja rakennettaessa, toteutettaessa palvelutuotantoa ja mitattaessa PLM-ratkaisuja. Tietohallintotyön tehokkuuden ja laadun kohottamiseksi näyttäisi olevan kannattavaa tuoda lisää PLM -lihaa yleistasoiseen tietojohtamisen hallintomalliin ja erityisesti ICT-arkkitehtuurin viitekehykseen. Tämä tarkoittaa vaikkapa valmiita käsitemallipohjia, kysymysluetteloita, eri PLM-osioiden ominaisuusluetteloita ja viiteluetteloa saatavilla oleviin PLMtietämyksiin ja yhteisöihin. Olisihan aika hölmöä luoda esimerkiksi tuotemuutosprosessia tyhjästä tai vaikka nimikkeiden versiointikonseptia, kun nämä ovat jo hioutuneet käytössä hyviksi, puhumattakaan omatekoisesta CAD-ohjelmasta (ai eikö olinko kuulevinani?). PLM EA -täsmälääkkeistä strategisimpana haluan nostaa esiin kolmiportaisen arkkitehtuurikomposition: liiketoimintapohjaisen PLM-arkkitehtuurin kehittämiseen tuotearkkitehtuurin avulla (Valokynä 3/2012). Tarkennettuna tämä tarkoittaisi kolmen arkkitehtuurin saumaton nivominen mallinnettujen koukkujen avulla: Yrityksen hyvinvoinnille on olennaisen tärkeää, että sen ainoa tuottava toiminta tuotejalostus on tuettu parhaimmalla mahdollisella tavalla. Väitän, että esim. CRM ei viime kädessä tee ainakaan tuoteintensiivisessä kontekstissa kuningaskuluttajaa onnelliseksi, jos itse tuotteeseen ei panosteta. Jos kauniilla hymyllä varustettu tuote osoittautuu laaduttomaksi, syntyy vain kiukkua ja putoaminen korkealta. Jos taas tuote osoittautuu kerrassaan verrattomaksi, siitä nauttii koko ekosysteemi. Kunkin hyvän tuotteen takana on varta vasten sitä tukemaan konfi guroitu tuotehallinnan palvelutarjonta. Valokynässä 3 oli myös esimerkki, kuinka liiketoimintamalleihin ja edelleen tuotearkkitehtuuriin kuvattavat eri tuotteiden tilauspisteet varioivat toimitusprosessia. Tämäkin esimerkki osoittaa sen, että tuotetiedonhallinta on ainakin joiltakin osin erilaista erilaisille tuote-elinkaarille. Ideaalisesti modulaarinen PLM-arkkitehtuuri voidaan konfi guroida uudelle tuote-elinkaarelle olemassa olevista elementeistä. Elementeillä tarkoitan informaatiota, prossseja, sovelluksia, infraa ja ihmisiä. liiketoiminnan tarve >< tuotteen informaation käsittelyvaatimus >< tuotehallinnan palvelu Tarve! Vaateet! Palvelut! Kuva 2. Liiketoimintaa aidosti tukevan ja siihen ennakoivasti mukautuvan PLM:n arkkitehtuurikehikko Kolmiportainen arkkitehtuurikompositio muodostaa asiakas-toimittajasuhteen yrityksen jokaisen liiketoimintaidean (eng. business model) ja PLM-palvelukonfiguraatioiden välille. Tuotearkkitehtuuri keskellä mahdollistaa analyyttisen PLM- vaatimustenhallinnan. 10 Valokynä 3/2012

Elinkaari Jotta tuotetiedonhallintaa voidaan kehittää, pitää uskaltaa tehdä yksinkertaisia kysymyksiä. Ei riitä, että meillä on Tuote ja Tuotteen elinkaari. Montako tuotetta, montako erilaista elinkaarta? Kuvassa 3 yksi harjoitelma eritellä erilaisia elinkaaria, elinkaaren lajeja ja tuotteen alalajeja. On syytä muistaa, että kaiken lisäksi yrityksellä voi olla montakin tuotelinjaa monta erilailla elinkaartaan kulkevaa tuotetta! Kuvan 3 keskialueella, otsikon PRO- DUCT MODEL oikealla puolella on yhden päätuotteen tuotemalli. Sininen kumpu kuvaa tuotteiston markkinoillaoloajan nousun ja laskun. Esim. Citroen 2CV on ollut markkinoilla ja käytössä edelleen, yhteensä useita kymmeniä vuosia. Tätä aikaa en kutsuisi tuotteen elinkaareksi vaan vaikkapa tuoteperheen elonjaksoksi (eng. life span), jolla on mm. käsitteet ramp-up ja ramp-down. Sätkän elinkaaria on kuvattu punaisilla evoluutiorinkuloilla. Ne voisivat olla vuosimalleja, eli yksi päätuotteen muutossykli tuottaa aina uuden mallin. Kuvassa on siten esitetty neljä vuosimallia. Tällä tavalla määriteltynä elinkaari-käsitteestä on se hyöty, että se kuvaa tuotteen jalostumisen vaatimuksista konsepteiksi, suunnitelmiksi ja edelleen tuotannon rakenteiksi evoluutiosyklikohtaisena tapahtumasarjana Tällaisen toimintojen ja informaation jäljittäminen antaa hyvät eväät tarkoituksenmukaisen tuotetiedonhallinnan rakentamiseen, käyttöön ja mittaamiseen. Jos taas elinkaarella tarkoitetaan kuvan elonjaksoa (life span), eväät ovat kovin hempuloita. Alimpana on toimittajan komponentti C100, vaikkapa iskunvaimennin. Siitä on toimittajatehtaan neljä versiota, joista vain 3. ja 4. ovat olleet käytössä sätkän vuosimalliversioissa 1 ja 2. Toimittajan komponentti C200, versio 3 on alkanut korvata komponentin C100 sätkän vuosimallista 3 alkaen. Ylärivissä on yleisestä sätkän tuotemallista johdettuja, tiellä kulkevia yksilökonfi - guraatioita. Korjausten myötä niissä käytetyt komponentit ovat vaihtokelpoisuuden puitteissa satunnaisia toimittajien tai piraattitoimittajien versioita. Kun yrityksillä on tämänkaltaisia rakennelmia, tehdään kohtuuton yksinkertaistus käyttämällä termejä elinkaari ja tuotehallinta niin kuin olisi vain yksi tuote, yksi elinkaari ja vaikkapa yksi CAD-käytäntö. Kuva 3. Skenaario elinkaari-käsitteestä Kuva 4. Harjoitelma PLM-spesifi sestä PLM EA viitekehyksestä Kuvassa 4oleva raitiotie vastaa Valokynä 3/2012 lehdessä esitettyä liikeidealähtöistä PLM-arkkitehtuurin kehittämis-,käyttö- ja mittausprosessia. Keskellä oleva PLM LIFECYCLE PROCESSES-ympyrä kuvaa PLM:n oman elinkaaren. On huomattava, että PLM:llä on kaksi pääroolia: kehittäminen ja käyttöpalvelu. Pienet siniset nuolet eri elinkaaren vaiheissa kuvaavat vaiheen aliprosesseja. Tässä harjoituksessa niitä syntyi yhteensä 35! Vasemmalla oleva BU- SINESS MODELING on apukeino tunnistaa yrityksen eri päätuotteiden prosessilliset ja asiakasperusteiset ominaispiirteet. Kuhunkin segmenttiin voitaisiin ajatella hyvän viitemallin tarjoavan täsmäytetyt PLM-vaatimukset. Oikealla on esitetty PLM KEY ENAB- LERS REPOSITORY, eli valmis piirrekirjasto (eng. features), joilla tuotteen jokin elinkaaren käsittelytapahtuma tai muu PLM-alueen kyvykkyyteen liittyvä vaatimus voidaan toteuttaa. Alarivissä on BALANCED SCORECARD kuvaamassa mittausmallin tarvetta, johon PLMviitekehyksessä voisi olla aihiot PLMmittareista. Alhaalla edelleen on esitetty valmis kirjasto liiketoiminnan tavoitteista, joihin on edelleen linkitetty PLM-tavoitteita ja edelleen tavoitekohtaiset kriteerit tuotetiedolle. Äärimmäisenä alhaalla oikealla on lopuksi PLM ARKKITEHTUU- RI, joka sisältää viisi voimavaraa. Valokynä 4/2012 3/2012 11

Kuva 5. Esimerkki PLMA EA viitekehyksen soveltamisesta On oleellista, että eri PLM EA -viitekehyksen osioiden välillä on mahdollisuus kaksisuuntaiseen tarkasteluun. Toisin sanoen, voit aina tarkistaa vaikkapa määrätyn PLM-elinkaaren osan kautta tarkistaa sen kytköksen tuoteinformaationkriteereihin ja edelleen määrätyn kriteerin kytkökset PLM-resursseihin ja sama takaperin. Kuvassa 5 PLM-elinkaaren neljä vaihetta on ositettu hieman tarkemmin kohdealueisiin (process scopes). Tarkimmillaan PLM-elinkaari sisältää tässä harjoituksessa 35 prosessia. Tietopalvelu tuotteena Marraskuisessa ICT Forumin Tietohallintomallin julkistustilaisuudessa herätin analogian tietohallintomallista tuotteena. Yritin selvittää, onko mallia työstettäessä ollut mukana tuoteasiantuntijoita ja tuotenäkökulma. Oma ehdotukseni oli, että jos tietohallintomallia käsiteltäisiin kuin tuotetta, sen kehittymiseen sovellettaisiin kypsiä R&D-käytäntöjä: roadmappausta, muutoshallintaa, katselmointia, testausta, release-käytäntöjä, konfiguraatiohallintaa jne. Eri määrittelyt ja palvelut olisivat keskenään yhteen kytkettävissä standardoitujen rajapintojen avulla (tässä: moduulin inputit ja outputit). Tuotokset olisivat palvelunimikkeitä ja niihin assosioituisi tuotedokumentteja. EA-palvelutuotteella olisi myös hinta, laatu ja asiakkuudet. EA-palvelut voitaisiinkin lisätä yrityksen sisäiseksi tuotteeksi tuotearkkitehtuuriin ja uusi tuotehan tarvitsee myös tuotehallintatukea (vai haluatko ylläpitää esim. tietomallia PowerPointilla?). Tämä näkökulma kuitenkin meni joidenkin julkistustilaisuudessa läsnä olleiden CIO:jen ohi päätelleen seuraavasta puheenvuorosta, jossa huolella konstruoitua tietohallintomallia voi puhujan mukaan vapaasti soveltaa ottamalla palan sieltä, toisen täältä. Näyttäisi olevan niin, että kun ollaan yhden osaamisalueen asialla, silloin ei samaan kyytiin mahdu toisen alan ammattilaisia. Tämän suuntaista tarvetta on kuitenkin päättäjien puolelta hehkutettu ja todettu, että eri osaamisalueiden kohtaamisessa piilee innovaatio. Pyrkimys näkyy yliopisto-, teknillisen- ja taideteollisen korkeakoululaitoksen fissiossa. Valokynän vuoden 2012 kaikki neljä numeroa ovat raottaneet PLM-viitekehyksen mahdollisuuksia ja vaatimuksia. Teksti on varmasti ollut vaikeaselkoista, terminologialtaan hapuilevaa ja ylimalkaista. Tämä kaikki on osittain tietoinen valinta, jotta kirjoitelmat eivät antaisi kuvaa siitä, että näin juuri tulisi olla ja jatkokehittämistä ei tarvita. Ken kiinnostuikin aiheesta ja aiheen keskeneräisyydestä voi kirjoittaa Valokynään tai ottaa kirjoittajaminään yhteyttä esim. LinkedInillä. PLM-yritysarkkitehtuurin kirjoitussarja tässä muodossaan päättyy tähän! Katso Lisää: www.tietohallintomalli.fi ja www.ictstandard.org Suosittele! Onko sinulla kaveri, joka ei vielä ole CCY:n jäsen? Suosittele yhdistyksen jäsennyyttä kaverillesi. Mikäli hän liittyy jäseneksi, saat itse seuraavanvuoden jäsenyyden ilmaiseksi! Lähetä kaverin nimi osoitteeseen sihteeri@cadcamyhdistys.fi 12 Valokynä 3/2012 Valokynä 4/2012