Yritysarkkitehtuuri

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” -semi naarissa, kts. s. 7. Aiheen käsittely jatkuu seuraavassa lehdessä.
32
Valokynä 1/2012
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,
r a k e n t a a j a m o n i t o ro i d a y r i t y k sen ICT-resursseja. Ohjaukseen
assosioituu hallinnointi – gover nance , A r k k i t e h t u u r i - s a n a a n
eheys, kokonaisvaltaisuus ja metodologisuus.
T
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.
Muita arkkitehtuurikäytännön
tuottamia hyötyjä voisivat olla
arkkitehtuurin tarkoituksenmukaisuus, tehokkuus, ajantasaisuus ja ketteryys asiakkaan eli
liiketoiminnan muutoksiin.
Tu o t e t t a p a i n o t t a v a n j o h d a n non 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-arkkitehtuu r iin .
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 ä o n t i e t o i n e n r i s k i , m u t t a
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 referenssimalle ja, 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
Uusi ajattelutapa
1.
PLM on ratkaisu Tuotteen elinkaaren
hallintaan.
1.
PLM tulisi olla eri liiketoimintamallien palveluportfolio.
2.
PLM-vastuualue kattaa operatiivisten
tuoteprosessin tuotetiedon
elinkaarellisen tuen (ECM).
2.
3.
PLM-ratkaisu rakentuu
kehitysprojektin tuloksena.
PLM vastuualueella tulisi olla myös
Tuotetietojohtaminen (Engineering BI),
PLM Governance ja PLM Palveluhallinta.
3.
PLM-projekti yrittää tunnistaa
päällekkäiset hankkeet ja valitsee
omat käytäntönsä.
PLM-käytänne tulisi olla ajallinen ja
elinkaarellinen jatkumo: Plan-BuildOperate-Monitor.
4.
PLM elinkaaren hallinnan tulisi noudattaa
hyvän hallinnon ja kokonaisarkkitehtuurin käytäntöjä.
4.
PLM-löydökset, nykyinen ja uusi ajattelutapa.
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ä
Asiakkaiden kokema pysyvä nautinto
syntyy vain laadukkailla hyödykkeillä.
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 huolt o . ” K y s y i n , e t t ä m i t e n k ä s s e t a k a p y ö r ä ? ” Va s t a u k s e n a o l i e m p i v ä E e i s i i n ä m i t ä ä 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öä.
9DORN\Ql‡0DUNNLQDQXPHUR
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-yritys-
arkkitehtuurin 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.
0DUNNLQDQXPHUR‡9DORN\Ql
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!
9DORN\Ql‡0DUNNLQDQXPHUR
tuki. Oheinen taulukko kuvaa
lähtökohdan ja ehdotuksen uu sista aluevaltauksista.
Operatiivinen tuotetiedonhallinta tarkoittaa tuoteprosessin ja
t i l a u s - t o i m i t u s p ro s e s s i n t a r v i t semia muutoshallinnan proses seja, suunnittelujärjestelmiä jne.
Tu o t e j o h t a m i n e n o l i s i b u s i n e s s
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ä
0DUNNLQDQXPHUR‡9DORN\Ql
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-gover nanceen 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 jonkinlai sesta kypsyyden laatuympyrästä!
Samaten Plan - ja Build -vaiheita
tehdään inkrementaaliperiaat-
teella, 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
j a a r k k i t e h t u u r i p r o s e s s i l l a t a rkoitetaan 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.
9DORN\Ql‡0DUNNLQDQXPHUR
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
v i i t e k e h y k s i l l ä . Ta v o i t t e e n a o n
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 (Gover nance)
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
0DUNNLQDQXPHUR‡9DORN\Ql
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
n kuitenkin hyödyllistä
varjella ja kehittää PLMa lu e e l l e ge n e e ri si ä vi i te kehyksiä syvemmälle meneviä
arkkitehtuurikäytäntöjä ja työkaluja. Yksi tällainen struktuuri
on liiketoiminta-arkkitehtuurin
sitominen PLM-arkkitehtuuriin
tuotearkkitehtuurin kautta. V iereinen 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.
S e u ra a va ssa on h yvi n ka rke a
vaihejakomalli liikkeelle lähdöstä
PLM-yritysarkkitehtuurin (PLM
EA, PLM Enterprise Architecture)
suhteen, kuva 2. Karkeasti jao-
O
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
y r i t y s a r k k i t e h t u u r i n k y p s y y s a rviointi suhteessa tarpeeseen.
Kompleksinen yritys tai tuote –
isot vaateet ja päinvastoin!
VAIHE 2 /GOVERNANCE: Määritellään PLM-arkkitehtuurin omistajuus ja toimintamalli.
VA I H E 3 / A R K K I T E H T U U R I :
Määritellään PLM-arkkitehtuurin
tuottamisprosessi.
VA I H E 4 / P L M E A V I I T E K E 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.
VA I H E 2 / T U O T E A N A LY Y S I :
Kuljetaan kunkin tuotteen selässä
läpi tapahtuma- ja tietovirta, jonka
tuotteen eri ilmentymät käyvät
l ä p i . Vo i o l l a t a r p e e n m a l l i n t a a
esimerkiksi komponenttien, kokoonpanojen, suunnittelumallin,
toimitettujen yksilöiden sarjanumeroitujen osien tapahtumaketjut skenaarioina.
VAIHE 3 /VISIO JA HYVÄT KÄYTÄ N N Ö T: Y r i t e t ä ä n t u n n i s t a a
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 ö i s t e n re s u r s s i e n p o t e n t i a a l i a
ei hukattaisi.
VA I H E 4 / M I T TA R I T: M u o d o s tetaan mittaristo, jolla johdon
mielestä kriittisiä menestystekijöitä voidaan mitata.
VAIHE 5 /PROSESSIKONSEPT I T: M i t t a r i t j y v i t e t ä ä n p ro s e s seille, joissa tuotteet käyvät vaiheen 2 perusteella.Prosessiomistajien kanssa sitten mietitään,
m i l l ä k o n s e p t e i l l a p ro s e s s e i s t a
saadaan mittareiden indikoimat
tuottavuudet.
V A I H E 6 / R E S U R S S I T:
Määritellään ja mitoitetaan
p ro s e s s i e n t a r v i t s e m a t I C T- j a
m u u t re s u r s s i t . Tä m ä n j ä l k e e n
ryhdytään tuumasta toimeen:
suunnitellaan vaateiden mukainen PLM-arkkitehtuuri, sitten toteutus, käyttö, monitoro i n t i – j a s a m a u u d e l l e e n !
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 tarkoituk-
senmukaisuus ja tehokkuus, niin
erityisesti palvelujen ennakointi
ja toteuttaminen joutuisasti vaativat yrityksiin toimintamallin ja
pysyviä resursseja, jotka käyvät
jatkuvaa ja strukturoitua vuoro p u h e l u a l i i k e t o i m i n t a y k s i k ö i den 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
22
Valokynä 3/2012
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 suunnitel-
Sami Mattila
mista 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.
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-spesifisiä tarkennuksia.
PLM-yritysarkkitehtuuri visio
“Boundaryless Product Information Flow within and between Enterprises”.
8
Valokynä4/2012
3/2012
Valokynä
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ä
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 konfiguroitu 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
konfiguroida uudelle tuote-elinkaarelle
olemassa olevista elementeistä. Elementeillä tarkoitan informaatiota, prossseja, sovelluksia, infraa ja ihmisiä.
liiketoiminnan tarve >< tuotteen informaation käsittelyvaatimus >< tuotehallinnan palvelu
10
Valokynä 3/2012
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.
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 PRODUCT 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ökonfiguraatioita. 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-spesifisestä 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 BUSINESS 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 ENABLERS 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 ARKKITEHTUURI, joka sisältää viisi voimavaraa.
Valokynä
Valokynä4/2012
3/2012
11
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.
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
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
[email protected]
12
Valokynä
3/2012
Valokynä 4/2012