Teknisessä liiketoiminnassa tuotetieto on infrastruktuuria.
Sama fyysinen tuote voi näkyä suunnitteluasiakirjoissa, ERP-järjestelmässä, CPQ:ssa, tarjouspohjissa, luetteloissa, hankinnassa, logistiikkatarroissa, asennusohjeissa ja huoltoaineistossa. Jos jokainen järjestelmä kuvaa tuotetta eri tavalla, organisaatio käyttää aikaa tiedon sovittamiseen sen sijaan, että yhteinen tieto olisi valmiiksi hallittu.
Tuotetiedon valmius tarkoittaa siksi enemmän kuin tietokantaa. Se tarkoittaa päätöstä siitä, mitä tuotetieto tarkoittaa, mistä se tulee, kuka sen omistaa ja missä sitä voidaan turvallisesti käyttää uudelleen.
1. Kolme eri kerrosta
Lähdekerros
Auktoritatiivinen aineisto, josta tieto otetaan: hallittu piirustus, varmennettu tekninen dokumentti, sertifikaatti, hyväksytty ohje tai muu nimetty lähde.
Normalisoitu tietokerros
Rakenteinen esitys, jota järjestelmät ja ihmiset käyttävät. Yksiköt, nimet, optiokoodit ja ominaisuuksien määritelmät standardoidaan tässä.
Esityskerros
Tiettyä yleisöä varten käytetty sanamuoto, esimerkiksi tarjous, luettelo, verkkosivu, asennusohje tai myynnin sisäinen näkymä.
Esityskerros voi yksinkertaistaa tietoa, mutta sen ei pitäisi muuttaa sitä huomaamatta.
2. Vähimmäistason hyödyllinen tuoterekisteri
| Ryhmä | Esimerkkisisältö |
|---|---|
| Identiteetti | hallittu nimi, tuotetunnus, tuoteperhe, variantti, revisio |
| Luokitus | järjestelmärooli, tuotetyyppi, käyttökohde |
| Geometria | mitat, massa, asento, liitäntöjen sijainti |
| Rajapinnat | kiinnitys, läpiviennit, sähköiset ja mekaaniset liitännät, yhteensopivat osat |
| Materiaalit | päämateriaali, pintakäsittely, ympäristöä koskevat tiedot |
| Suorituskyky | varmennetut luokitukset, rajat ja käyttöolosuhteet |
| Dokumentaatio | piirustus, datasivu, sertifikaatti, asennus- ja huoltoviitteet |
| Elinkaari | huoltopääsy, tarkastus, vaihto ja kunnossapito |
| Logistiikka | pakkaus, käsittely, pakkausmitat, varastointirajoitukset |
| Kaupallinen käyttö | hyväksytty myyntikuvaus, optiologiikka, tilaushuomiot |
Kaikkia kenttiä ei tarvita joka järjestelmässä, mutta tärkeällä tiedolla pitää olla selkeä määritelmä ja tunnistettava lähde.
3. Vakaat tunnisteet
Nimeämisvirheet muuttuvat kalliiksi, kun ihminen ymmärtää tuotteen asiayhteydestä mutta järjestelmä ei.
Vakaan tuotetunnuksen pitäisi säilyä, vaikka markkinointisanamuoto muuttuu. Variantit pitää erottaa ilman vapaata tekstiä. Yksiköt pitää tallentaa yhdenmukaisesti ja optiologiikan olla riittävän selkeä, jotta yhteensopimattomat yhdistelmät voidaan havaita ennen tarjousta tai tilausta.
Hyvät tunnisteet yhdistävät:
teknisen tiedon ↔ kaupallisen kuvauksen ↔ hankinnan ↔ logistiikan ↔ dokumentaation
4. ERP, CPQ ja myynti tarvitsevat eri näkymiä
ERP tarvitsee operatiivisen identiteetin ja tapahtumatiedon. CPQ tarvitsee konfiguraatiologiikan ja yhteensopivuuden. Tekninen myynti tarvitsee ymmärryksen toiminnasta, rajoitteista ja avoimista vahvistuksista. Hankinta ja logistiikka tarvitsevat tilaamisen, pakkaamisen, määrän, toimituksen ja käsittelyn tiedot. Dokumentaatio tarvitsee täsmällisen revision ja asennukseen, tarkastukseen sekä huoltoon tarvittavan tiedon.
Ratkaisu ei ole viisi erillistä datasettiä, vaan yksi hallittu ydin, josta oikeat kentät julkaistaan kuhunkin käyttötarkoitukseen.
5. Lähdehierarkia ja validointi
Tiedon poiminta ei ole sama asia kuin varmennus.
OCR, AI ja automaattinen jäsentely voivat vähentää manuaalista työtä ja löytää ehdokasarvoja. Niiden ei pitäisi muodostua merkityksellisen teknisen tiedon auktoriteetiksi.
Kestävä prosessi erottaa:
poimittu arvo → tarkistettu arvo → hyväksytty arvo → julkaistu arvo
Jokaisesta tärkeästä ominaisuudesta pitäisi pystyä näkemään, missä tilassa se on.
6. Laadunhallinta
Hyödyllisiä kontrolleja ovat:
- pakolliset kentät tuotekategorioittain;
- yksikköjen normalisointi;
- nimeämiskäytännöt;
- duplikaatti- ja varianttitarkastukset;
- lähdeviite;
- revisiopäivä;
- omistaja;
- hyväksyntätila;
- poikkeusjono epävarmoille tai ristiriitaisille arvoille;
- sääntötarkastukset mahdottomille yhdistelmille.
Poikkeusjono on erityisen tärkeä. Epävarmuuden pitää muuttua näkyväksi työksi, ei tyhjäksi kentäksi tai arvaukseksi.
7. Tiedon muutoksen elinkaari
Teknistä arvoa ei pitäisi korvata ilman asiayhteyttä.
Käytännöllinen ketju on:
lähteen muutos → tarkastus → vaikutusarvio → normalisoidun tiedon päivitys → hyväksyntä → julkaisu alavirran järjestelmiin → vanhan tilan säilytys
Vaikutusarviossa tarkistetaan, missä vanhaa arvoa on jo käytetty. Pieni muutos voi vaikuttaa tarjouspohjaan, asennusohjeeseen, varaosaviitteeseen tai hankintakuvaukseen.
8. Kaupallinen arvo
Puhdas tuotetieto lyhentää matkaa teknisestä kysymyksestä luotettavaan vastaukseen. Se tekee osaamisesta uudelleenkäytettävää, vähentää selvityskierroksia ja antaa myynnille, operaatioille ja teknisille tiimeille yhteisen viitteen.
Se tekee myös tulevista digitaalisista työkaluista uskottavampia, koska automaatio toimii parhaiten silloin, kun taustalla olevalla tiedolla on määritelmät, omistajuus ja alkuperä.
Portfolion rajaus
Sivu esittää itsenäisesti kehitetyn yleisen tuotetiedon valmiusmallin. Se ei sisällä luottamuksellista aineistoa tai työnantajakohtaista tietokantarakennetta.