PLM ja ERP: missä raja kulkee

Kolme skenaariota, yksi kaava

ERP ei ole huono PLM – se on rakennettu eri tehtävää varten. Tämä paljastuu yleensä vasta silloin, kun jokin menee pieleen.

Suunnittelija vaihtaa CAD:ssa yhden komponentin. Kolme viikkoa myöhemmin tulee reklamaatio – tuotanto on valmistanut yhä vanhaa versiota.

Reseptissä korvataan raaka-aine sääntelysyistä. Auditoinnissa kukaan ei pysty sanomaan varmuudella, mikä valmistettu erä sisälsi uuden version.

Kokenut työntekijä jää eläkkeelle. Puoli vuotta myöhemmin vanhaa tuotetta pitäisi päivittää – silloisia suunnitteluperusteita ei löydä enää kukaan.

Kolme eri toimialaa, kolme eri oiretta, yksi yhteinen syy: järjestelmä, jonka halutaan hoitavan tehtävää, jota varten sitä ei ole rakennettu.

Tässä artikkelissa kuvataan ERP:n (Enterprise Resource Planning, toiminnanohjausjärjestelmä) ja PLM:n (Product Lifecycle Management, tuotetiedonhallintajärjestemä) välistä työnjakoa valmistavissa pk-yrityksissä. Ei ominaisuusvertailuna, vaan kysymysten kautta: mitä ERP ei rakenteellisesti pysty tekemään? Missä siitä syntyy todellisia kustannuksia? Ja milloin saavutetaan piste, jossa erillinen järjestelmä tuotetiedolle on liiketaloudellisesti välttämätön?

Mitä järjestelmät todella hallitsevat

ERP-järjestelmät hallitsevat yrityksen operatiivista nykytilaa: tilauksia, varastoja, kirjauksia, resursseja. Ne vastaavat kysymyksiin kuten Kuka tilasi mitä? Mitä meillä on varastossa? Mitä tuotanto maksaa? ERP on transaktiokeskeinen järjestelmä, joka pyörittää käynnissä olevaa liiketoimintaa.

PLM-järjestelmät hallitsevat tuotteen määrittelyä tavoitetilassa: vaatimuksia, suunnittelua, versioita, hyväksyntöjä, muutoksia ja todenteita – koko elinkaaren ajan. Ne vastaavat kysymyksiin kuten Miten tämä tuote on syntynyt? Mikä versio on voimassa? Kuka muutti mitä, milloin ja miksi? PLM on oliopohjainen järjestelmä, joka ylläpitää tuotteen määrittelyä.

ERP-tieto kuvaa, mitä on tapahtunut. PLM-tieto kuvaa, mikä tuote on ja miten siitä tuli sellainen. Näiden kahden näkökulman väliset aukot eivät ole konfigurointikysymyksiä – ne ovat arkkitehtuurisia.

ERP:n neljä rajaa

1. Engineering-tieto ja suunnittelukonteksti

ERP:ssä on hyväksytty osaluettelo. Mitä siellä ei ole: CAD-malli, laskelmat, materiaalispesifikaatiot, tarkastusraportit, riippuvat dokumentit. ERP tietää, että kokoonpano koostuu kolmesta osasta. ERP ei tiedä, miksi se koostuu kolmesta eikä kahdesta.

Käytännössä: kun asiakas palaa kolme vuotta toimituksen jälkeen ongelman kanssa, joku haluaa tietää, mikä versio silloin valmistettiin, mitä standardia vasten se oli mitoitettu ja mitä testejä tehtiin. ERP:stä löytyy lähete. Kaikki muu on jossakin.

2. Muutostenhallinta

ERP:ssä on tyypillisesti vanha ja uusi osaluettelo. Kuka muutoksen käynnisti, mitä vaihtoehtoja arvioitiin, mitkä testit mitätöityivät, mitä vaikutuksia sillä on muihin tuotteisiin – tätä klassiset ERP-järjestelmät eivät kuvaa.

PLM hallitsee muutoksia omina olioinaan: change request, vaikutusanalyysi, asianomaiset osat tai raaka-eineet, hyväksynnät, liittyvät dokumentit. Materiaalin korvaaminen ei silloin ole osaluettelon hiljainen päivitys, vaan jäljitettävä tapahtuma perusteluineen, tarkastuksineen ja hyväksyntöineen.

3. Jäljitettävyys määrittelytasolla

Elintarvikkeet, kosmetiikka, lääkinnälliset laitteet ja yhä enemmän elektroniikka kuuluvat tiukkojen todentamisvelvoitteiden piiriin. ERP osaa jäljittää transaktiotasolla: minkä raaka-aine-erän mihin tuote-erään on virrannut. Tämä riittää klassiseen eräjäljitykseen.

Mihin se ei pysty: yhteyteen ainesluokkien, sääntelyvaatimusten, spesifikaatioversioiden ja tuoteversioiden välillä. Kun kysytään „Mitkä tuotteet sisältävät ainetta X minkä spesifikaation minkä voimassa olevan version mukaan?”, ERP ei pysy mukana – ei siksi, että se olisi väärin konfiguroitu, vaan koska sen tietorakenne ei tunne näitä suhteita.

4. Tieto, joka ei lähde ihmisten mukana

Pk-yrityksissä huomattava osa tuotetiedosta on kokemusperäisesti ihmisten päässä. Mikä suunnitteluratkaisu tehtiin silloin ja miksi, mitä toimittajavaihtoehtoja kokeiltiin ja hylättiin, mitä erikoistyökaluja tietty versio vaatii – kaikki tämä on hiljaista tietoa.

PLM tekee tästä tiedosta eksplisiittistä ja versioituvaa. Ei lisäpakkokenttien kautta lomakkeissa, vaan jäsentämällä tuotekehityksen luonnolliset tuotokset (CAD, dokumentit, muutokset, päätökset) ja kytkemällä ne tuote-olioihin.

Mikä neljä aukkoa yhdistää: digitaalinen lanka

Nämä neljä aukkoa eivät ole neljä ongelmaa, vaan neljä oiretta samasta ongelmasta: tuotetieto on hajallaan ilman yhtenäistä identiteettiä. Suunnittelupiirustus ei tiedä kuuluvansa osaluetteloon. Osaluettelo ei tiedä, että siitä on olemassa tarkastuspöytäkirja. Tarkastuspöytäkirja ei tiedä, mitä standardia vasten se tarkasti.

Digitaalinen lanka – Digital Thread – on ajatus siitä, että jokainen tieto pysyy löydettävissä ja kontekstoituna koko tuotteen elinkaaren ajan: vaatimusmäärittelystä suunnitteluun ja valmistukseen, huoltoon asti ja lopulta seuraavaan tuotesukupolveen.

Pk-yritykselle tämä ei tarkoita „Industry 4.0 end-to-end”, vaan jotain konkreettisempaa: jokainen tuoteversio on yksiselitteisesti tunnistettavissa. Jokainen muutos on jäljitettävissä. Jokainen dokumentti on sidottu oikeaan versioon. Nämä ominaisuudet kuulostavat itsestäänselviltä, mutta useimmissa pk-yrityksissä ne eivät tänään toteudu – eikä niitä ilman PLM:ää voi saada aikaan, koska ne edellyttävät oliopohjaista, versioituvaa tietorakennetta, jota ERP:ssä ei ole.

Tietorakenne automaation ja tekoälyn edellytyksenä

Digitaalinen lanka ei ole vain inhimillisen löydettävyyden edellytys – se on myös perusta kaikelle automaatiolle, oli se tekoälypohjaista tai ei. Pullonkaula on harvoin pelkästään tekoälymallissa. Ratkaisevaa on, ovatko tuotetiedot jäsenneltyjä, versioituja ja jäljitettäviä.

Se, joka päästää tekoälyn ylläpitämättömien PDF-tiedostojen, Excel-osaluetteloiden ja tiedostopalvelimien kimppuun, ei saa automaattisesti tietoa – usein vain nopeammin tuotettua epävarmuutta. Sovellus, joka toimii jäsennellyn, versioidun ja suhdekeskeisen tuotetiedon päällä, pystyy sen sijaan antamaan jäljitettäviä vastauksia – lähteineen, versioineen ja kypsyysasteineen.

Konkreettisesti: kysymykset kuten „Mitä tuotteita tämän materiaalin korvaaminen koskee?”, „Laadi ensimmäinen luonnos version X-127 huoltodokumentaatiosta” tai „Mitkä tuotteet on sertifioitava uudelleen, jos standardia XYZ päivitetään?” eivät ole teknisesti mahdollisia niin kauan kuin pohjalla oleva tieto ei ole siinä muodossa, jota digitaalinen lanka kuvaa.

PLM:n lisäarvo ei siis ole tekoälykyvykkyydessä sinänsä, vaan siinä tiedon eheydessä ja jäljitettävyydessä, joka tekee jokaisen myöhemmän automaatioaskeleen ylipäätään mahdolliseksi.

Toimialakohtaiset painotukset

Kone- ja laitevalmistus.

Varianttien hallinta on hallitseva ajuri: asiakaskohtaiset konfiguraatiot, useat rinnakkaiset versiopolut, pitkäikäiset tuotteet, joiden huoltovaatimukset ulottuvat vuosikymmenten päähän. Suunnittelun osaluettelon (eBOM) ja valmistuksen osaluettelon (mBOM) välinen ero on tässä usein ensimmäinen kipupiste, jossa ERP törmää näkyvästi rajoihinsa.

Elintarvikkeet.

Reseptinhallinta allergeeni- ja ravintoarvolaskelmineen, EU 1169/2011:n mukaiset merkintävelvoitteet, EU 178/2002:n mukainen jäljitettävyys, reformulaatiot kustannussyistä tai sääntelyn vaatimuksesta. Resepti on tässä itsenäinen olio, jolla on oma versio, hyväksyntätila ja sääntelykonteksti – ei klassisessa mielessä osaluettelo.

Kosmetiikka.

INCI-deklaraatiot, markkinakohtainen sääntely (EU, UK, CH, US, GCC), CPNP-ilmoitukset, kiellettyjen tai rajoitettujen aineiden korvaaminen. Monimutkaisuus ei ole tuoterakenteessa, vaan niissä sääntelysuhteissa, joita formulaation on ylläpidettävä.

High-tech ja elektroniikka.

Komponenttien vanheneminen (komponentit poistuvat markkinoilta kesken tuotteen elinkaaren), laitteiston ja firmwaren sidonta, vaatimustenmukaisuus RoHS:ia, REACH:ia ja IEC:tä vasten. Lopputuotteen elinkaari on tässä usein pidempi kuin sen osien elinkaari – tehtävä, johon klassinen ERP ei vastaa.

Kaikille neljälle toimialalle yhteistä: tuotteen määrittely on monimutkaisempi kuin tilaus-toimitusprosessi. Se, joka pyörittää vain ERP:tä, on ratkaissut helpomman ongelmansa hyvin – ja jättänyt varsinaisen ongelmansa käsittelemättä.

Sääntelyvaatimukset: DPP ja toimialakohtaiset velvoitteet

Digitaalinen tuotepassi (DPP) ESPR:n alla.

EU:n asetus kestävien tuotteiden ekologisesta suunnittelusta tuli voimaan vuonna 2024. Se luo puitteet tuotekohtaisille ekosuunnitteluvaatimuksille ja digitaalisille tuotepasseille. Mitä tuoteryhmiä se koskee ja milloin, määritellään vaiheittain tuotekohtaisilla delegoiduilla säädöksillä. EU:n työsuunnitelma 2025–2030 priorisoi muun muassa tekstiilit, huonekalut, patjat, renkaat sekä raudan, teräksen ja alumiinin; horisontaaliset vaatimukset koskevat muun muassa korjattavuutta, kierrätettävyyttä ja kierrätysmateriaalin osuutta sähkö- ja elektroniikkatuotteissa. Elintarvikkeet, rehut ja lääkkeet on rajattu ESPR:n soveltamisalan ulkopuolelle.

Akkupassi tulee voimaan 18. helmikuuta 2027 tietyille akkukategorioille – erityisesti LMT-akuille, yli 2 kWh:n teollisuusakuille ja sähköajoneuvojen akuille. Se on siten relevantti valmistajille, jotka saattavat itse markkinoille kyseisiä akkukategorioita tai joiden on toimitettava vastaavat todenteet osana monimutkaisia toimitusketjuja.

Teknisesti DPP on tietoarkkitehtuurivaatimus. Todennettua, jäsenneltyä tietoa materiaaleista, alkuperästä, korjattavuudesta, kierrätettävyydestä ja monesta muusta on ylläpidettävä johdonmukaisesti tuotteen määrittelytasolla ja pidettävä ajan tasalla koko elinkaaren ajan. Klassiset ERP-järjestelmät vastaavat transaktiotasoon; tätä tietorakennetta ne eivät pysty kuvaamaan. Toimialan asiantuntijoiden arvioiden mukaan DPP-valmiin tietopohjan rakentaminen vaatii 12–18 kuukauden valmisteluajan – mukaan lukien toimittajatiedon keruu ja skeeman määrittely.

Toimialakohtaiset velvoitteet säilyvät relevantteina.

REACH ja RoHS high-techissä, EU 1169/2011 ja 178/2002 elintarvikkeissa, CPNP kosmetiikassa. Riippumatta kestävyysraportoinnin yksinkertaistuksista monet tuotekohtaiset todentamisvelvoitteet säilyvät – ainesosista, spesifikaatioista, jäljitettävyydestä, merkinnöistä ja teknisestä dokumentaatiosta.

Asiakaslähtöiset vaatimukset.

Myös pk-yritykset, jotka eivät itse ole raportointivelvollisia, saavat yhä useammin suurasiakkailta pyyntöjä tuotekohtaisesta kestävyystiedosta. Vapaaehtoinen VSME-standardi muodostuu tässä käytännön vähimmäisvaatimukseksi. Juuri se tieto, jolla tällaisiin pyyntöihin vastataan, on sitä tietoa, jota PLM pitää natiivisti jäsenneltynä.

Missä ERP ja PLM toimivat yhdessä

PLM ei korvaa ERP:tä. Nämä kaksi järjestelmää palvelevat eri vaiheita eri vaatimuksin, ja järkevästi käytettyinä ne toimivat yhdessä.

Tyypillinen luovutuspiste on tuotteen hyväksyntä. PLM määrittää, mikä tuote on, missä versiossa, millä dokumenteilla ja mitä vaatimuksia vasten tarkastettuna. Hyväksynnän yhteydessä operatiivisesti relevantit osat – nimikkeet, osaluettelot, reititykset – siirtyvät ERP:hen, joka tämän pohjalta ohjaa hankintaa, valmistusta ja toimitusta. Muutokset hyväksyttyyn tuotteeseen kulkevat taas PLM:n kautta ja synkronoidaan uudelleenhyväksynnän yhteydessä.

Tämä työnjako ei ole tiedon kaksinkertaista ylläpitoa, vaan tehtävien jakoa. ERP:n ei kuulu osata sitä, mitä PLM osaa – ja päinvastoin. Se, joka yrittää kattaa toisen toisella, saa joko hitaan, erikoiskenttiä täynnä olevan ERP:n tai PLM:n, joka kompastuu kirjanpitotositteeseen.

Piilokustannukset ilman PLM:ää

Puuttuvan PLM:n kustannukset jakautuvat muille tileille ja jäävät siellä useimmiten näkymättömiin:

• Uudelleentyö ja hylky vanhentuneiden spesifikaatioiden, väärien osaluetteloversioiden tai puutteellisesti viestittyjen muutosten vuoksi.
• Viivästynyt time-to-market epäselvien vastuiden vuoksi hyväksyntäprosesseissa ja manuaalisen tiedon ylläpidon vuoksi useissa järjestelmissä.
• Auditointi- ja compliance-työ, kun jokainen viranomaisen tai suurasiakkaan pyyntö maksaa viikkoja selvitystyötä, koska tiedot on koottava kasaan.
• Takaisinvetokustannukset pahimmassa tapauksessa – ei siksi, että tuote olisi ollut viallinen, vaan koska jäljitettävyys ei riittänyt erottamaan rajattua takaisinvetoa kattavasta.
• Tiedon menetys henkilövaihdoksissa, jota ei voi laskea euroina ennen kuin ensimmäistä vanhaa tuotetta pitäisi päivittää eikä kukaan tiedä, miksi se on suunniteltu niin kuin on.
• Varjo-IT Excel-osaluetteloiden, SharePoint-rakenteiden ja tiedostopalvelinten kansiomaailmojen muodossa, jotka jokainen pk-suunnittelutoimisto tuntee.

Yksikään näistä kustannuslajeista ei ole yksinään katastrofaalinen. Yhteenlaskettuna ne sitovat usein tuntuvasti suunnittelun, laadun ja IT:n kapasiteettia – ilman että nämä kustannukset tulevat näkyviksi siististi tuotetieto-ongelmana.

Kasvun kipupisteet: milloin pk-yritys tarvitsee PLM:n?

Lyhyt tarkistuslista itsearviointiin. Jos kolme tai useampi kohta täsmää, keskustelu PLM:stä on jo myöhässä:

• Osaluetteloita ylläpidetään Excelissä tai suoraan CAD-järjestelmässä – ilman erillistä järjestelmää versioinnille ja hyväksynnälle.
• On useita tuoteversioita, joita on hoidettava rinnakkain.
• Muutoksista viestitään sähköpostilla tai chatissa.
• Suunnittelu ja hankinta työskentelevät eri „oikeilla” osaluetteloilla.
• Yksi auditointi maksaa säännöllisesti useita henkilötyöviikkoja.
• Vähintään yksi työntekijä on joskus ollut roolissa „ainoa, joka löytää tiedot”.
• Asiakkaiden kysymyksiin compliancesta, ainesosista tai spesifikaatioista vastataan tapauskohtaisesti.
• Samaa tietoa ylläpidetään useammassa kuin yhdessä paikassa – epäjohdonmukaisuuden riskillä.

Miten käyttöönotto tehdään – ei kaikkea kerralla

PLM-käyttöönotot kaatuvat harvoin ohjelmistoon. Ne kaatuvat big bang -lähestymistapaan: 18 kuukauden projekti, joka yrittää kattaa kaiken kerralla ja täyttää lopulta tuskin alun perin määritellyt vaatimukset eikä myöskään niitä, joita on syntynyt väliaikana.

Realistinen tie näyttää erilaiselta. Ensin perusta: perustiedot, osaluettelot, dokumentit, CAD-integraatio. Tämä vaihe tuottaa mitattavaa arvoa – siisti tietopohja, vähemmän etsimistä, määritelty hyväksyntäprosessi – ja on tuotannossa muutamassa kuukaudessa. Vasta sen jälkeen tulevat seuraavat tasot: jäsennelty muutostenhallinta, varianttien ja konfiguraatioiden hallinta, laatu- ja compliance-prosessit, integraatio ERP:hen ja jälkijärjestelmiin.

Tällä vaiheittaisella lähestymistavalla on kaksi etua big bangiin verrattuna. Ensinnäkin hyöty on jokaisen vaiheen jälkeen organisaatiolle tuntuva – se pitää hyväksynnän korkealla. Toiseksi ensimmäisen vaiheen jälkeen pystyy arvioimaan selvästi paremmin, mitä seuraava todella maksaa, koska yritys tietää siihen mennessä, miten järjestelmän kanssa työskennellään.

Lopuksi

Kysymys ei ole „ERP vai PLM”.

ERP ohjaa tilauksia, varastoja, hankintaa, valmistusta ja kustannuksia. PLM pitää tuotteen määrittelyn koossa: versiot, dokumentit, hyväksynnät, muutokset ja todenteet.

Yksinkertaisille tuotteille ja vakaille prosesseille ERP voi riittää pitkään. Kriittiseksi tilanne muuttuu, kun mukaan tulevat variantit, sääntelyvaatimukset, tiheät muutokset tai pitkäikäiset tuotteet. Silloin kustannuksia ei synny siksi, että ERP olisi huono – vaan koska sen halutaan hoitavan tehtävää, jota varten sitä ei ole rakennettu.

Järkevä aloitus ei siksi ole big bang -projekti. Se alkaa selkeästä kysymyksestä: minkä tuotetiedon on jatkossa oltava yksiselitteistä, versioitua ja jäljitettävää?