Artikkelit

Alakohtaisten tuotetietojen keskittäminen

ETIM ja muut alakohtaiset standardit

Yhtenäiset luokittelut tehostavat arvoketjua alusta loppuun

Tuoreen uutisen mukaan koko rakennusalaa edustavat LVI-Teknisen Kaupan liitto, Rakennustietosäätiö ja Sähköteknisen Kaupan Liitto ovat sopineet yhteistyöstä tuotetietojen tarjoamiseksi yhdestä yhteisestä kanavasta. Uudessa mallissa kaikilla rakennusalan toimijoilla on mahdollisuus saada kattavat, heidän tarpeitaan palvelevat tuotetiedot yhdenmukaisessa muodossa nopeasti, yksinkertaisesti ja kustannustehokkaasti yhdestä kanavasta.

Tämä uutinen on hyvä esimerkki yleisestä suuntauksesta, jossa alakohtaisia tuotetietoja keskitetään.

 

Miksi alakohtaisten tuotetietojen keskittäminen on tärkeää?

Yhtenäinen tapa luokitella tuotetietoja ja keskittää ne yhteen kanavaan tehostaa kaikkien alan arvoketjun toimijoiden tekemistä. Ilman yhtenäisiä käytäntöjä tuotetiedot liikkuvat arvoketjussa monissa eri muodoissa ja niiden hyödyntäminen eri toimijoiden järjestelmissä ja julkaisukanavissa vaatii manuaalista konvertointia sopivaan muotoon jokaisessa vaiheessa. Yhtenäisen toimintamallin avulla tiedot ovat suoraan hyödynnettävissä kaikkialla toimittajasta, kanavasta ja kielestä riippumatta. Jos järjestelmien rajapinnat ovat kunnossa, myös tuotetietoihin tehtävät läpi arvoketjun aina valmistajalta, maahantuojalle, suunnittelijalle ja loppukäyttäjälle saakka.

Toinen merkittävä etu luokittelusta on se, että tuotteen tietyn teknisen ominaisuuden löytäminen digitaalisesta ympäristöstä helpottuu. Esimerkiksi verkkopalveluiden fasetoidut (ominaisuustietoja hyödyntävät) haut luottavat vahvasti luokiteltuun ja eriteltyyn tuotetietoon. Tuotteet löytyvät teknisten ominaisuuksiensa ansiosta myös kansainvälisillä markkinoilla. Samalla tuotteita on myös helpompi vertailla keskenään.

Hyviä esimerkkejä tästä suuntauksesta ovat Sähkönumerot.fi-tuotetietopalvelu, joka sisältää 240.000 tuotteen tietoja sekä LVI-INFO – tuotetietorekisteri, josta löytyy noin 150 000 LVI-teknisen tuotteen tiedot.  Palveluiden tiedon oikeellisuuden ja ajantasaisuuden takaavat tiedon omistajat ja tuottajat eli valmistajat ja maahantuojat. Kaiken tämän mahdollistaa ETIM- eli European Technical Information Model –standardin käyttöönotto, joka asettaa teknisen tiedon yhteismitalliseen muotoon.

 

ETIM -standardin käyttö tukemassa liiketoimintaa

 

Adeona PIM -tuotetiedonhallinnan järjestelmä tukee alakohtaista luokittelua

Jo nyt Adeona PIM -tuotetiedonhallinnan järjestelmässä on mahdollista hyödyntää tehokkaasti ETIM -standardin mukaisesti luokiteltua tuotetietoa. Asiakkaat määrittelevät ETIM luokat, jotka heillä on käytössä, minkä pohjalta standardin mukaiset kentät muodostuvat Adeona PIM -tuotetiedonhallintaan. Adeona PIM -järjestelmästä tiedot puolestaan synkronoidaan tai julkaistaan kaikkiin tarvittaviin kanaviin.

Aivan yksiselitteistä ETIM -standardinkaan käyttöönotto ei ole. Tiedon tallennuksessa tulee ottaa huomioon lukuisia asioita liittyen mm. siihen missä tietoja käytetään ja minne niitä välitetään. Autamme asiakkaitamme mielellämme myös ETIM -standardiin liittyvien tietovirtojen suunnittelussa.

 

Meillä on jo lukuisia asiakkaita, jotka luokittelevat tietonsa ETIM -standardin mukaisesti. Tuotetiedot rikastetaan standardin mukaisessa muodossa Adeona PIM -järjestelmässä, minkä jälkeen ne ovat hyödynnettävissä kaikissa asiakkaan julkaisukanavissa sekä välitettävissä integraatioilla keskitettyihin tietopankkeihin tai esim. jälleenmyyjille.

– Janne Costiander, CTO Canter Oy

 

Jatkossa näitä luokituksia tullaan varmasti käyttämään myös muilla aloilla. Adeona PIM -järjestelmään on teknisen arkkitehtuurinsa takia helppo ottaa käyttöön myös muita alakohtaisia luokituksia.

Rajapinnat REST API

Rajapinnoista ja niiden avoimuudesta

Modernin sovelluksen elinehto on toimiva julkinen API. Ennen kuin katsotaan tarkemmin, mitä API meidän näkökulmasta tarkoittaa ja miten niistä saadaan parhaat hyödyt irti, käydään läpi vähän perusteita.

API (Application Programming Interface) tarkoittaa sovellusrajapintaa, jota kautta sovelluksen tiedot ja toiminnallisuus on saavutettavissa sekä mahdollistaa ohjelmointityön sovellukseen tai sen osaan, esimerkiksi standardikirjastoon liittyen. Nämä rajapinnat voivat olla hyvin matalalla tasolla ja liittyä järjestelmän sisäiseen toimintaan. Esimerkiksi käytettävän Open Source -kirjaston kutsuihin järjestelmän sisällä. Tässä kirjoituksessa katsotaan kuitenkin tarkemmin julkisia rajapintoja. Niitä, joiden kautta sovellus on laajennettavissa tai integroitavissa, sekä sovelluksen tieto laajasti hyödynnettävissä.

API-keskeinen arkkitehtuuri

Perinteisesti sovellusrajapinnat on nähty enimmäkseen järjestelmien sisäisinä tai lähinnä integrointiin liittyvinä. Modernit sovellukset toimivat kuitenkin enemmän palveluina, ja filosofiana on järjestelmän helppo laajentaminen ja sen sisältämän tiedon laaja hyödyntäminen. Modernit sovellukset käyttävät ja tarjoavat jopa useita sovellusrajapintoja. Esimerkiksi sosiaalisen median sovellusten, kuten Facebook ja LinkedIn, käyttö perustuu pitkälti rajapintoihin joiden ympärille on tehty erilaisia käyttöliittymiä (selain, mobiili jne.).

API-keskeisessä arkkitehtuurissa sovellukset keskustelevat näiden julkisten rajapintojen kautta. Yksittäisen sovelluksen ohjelmointikielellä tai sisäisellä rakenteella ja logiikalla ei ole merkitystä, kun rajapinnat on tehty yleisten käytäntöjen mukaan. API-keskeinen arkkitehtuuri helpottaa myös päätelaiteriippumattomien sovellusten rakentamista. Esimerkiksi eri mobiilikäyttöjärjestelmille tehdyt sovellukset voivat käyttää samaa yleistä rajapintaa.

 

Adeona_PIM_2017

RESTful API

Kun käytetään yleisiä käytäntöjä ja de facto-standardeja, on sovellusten liittäminen helppoa ja datan hyödyntäminen tulee mahdolliseksi erilaisissa sovelluksissa.

REST (Representational state transfer) on tilaa tallentamaton HTTP-protokollaan perustuva arkkitehtuurimalli sovellusrajapintojen tekemiseen. Tyypillisesti REST API tarjoaa tiedon JSON (JavaScript Object Notation)- tai XML-formaatissa.  Me käytämme REST-rajapinnassamme JSON-formaattia, joka on avoin, luettavaan tekstiin ja attribuutti-arvo-pareihin perustuva vallalla oleva formaatti.

Avoin API

Yksi API-keskeisen arkkitehtuurin perusajatuksia on, että rajapinnat on avoimesti saatavilla ja niihin löytyy avoimesti saatavilla oleva hyvä dokumentaatio. Hyväkin rajapinta jää käyttämättä, jos sitä on hankala käyttää tai dokumentaatio ei ole saatavilla. Parhaimmillaan koko järjestelmän tietomassa sekä logiikka on saavutettavissa rajapinnan kautta. Näin järjestelmän liittäminen, integrointi tai laajentaminen omilla liittyvillä sovelluksilla on joustavaa.

Avoin rajapinta ei tarkoita sitä, että kaikki järjestelmän tieto on kaikkien saatavilla. Rajapintakutsut todennetaan ja järjestelmä voi sitten rajata kullekin rajapintaa kutsuvalle ne tiedot, joihin oikeudet riittävät.

Lue lisää Adeona PIM -rajapinnoista ->

 

Lisätietoja rajapinnoista muualla:

https://en.wikipedia.org/wiki/Application_programming_interface

https://en.wikipedia.org/wiki/Representational_state_transfer

tuotetiedonhallinta excel

Tuotetiedonhallinta Excelissä

Käyn säännöllisesti konsultoimassa asiakkaita tuotetiedonhallinnan ja julkaisuautomaation osalta. Kyseessä saattaa olla asiakas, joka vasta suunnittelee PIM-järjestelmän hankintaa, tai jo prosessinsa hionut toimija. Monesti konsultointikeikoilla tai koulutuksissa minulta kysytään,

 Miten tuotetiedonhallinta on yleensä ratkaistu?

Siihen näytän  kuvan:

tuotetiedonhallinta_excel

 

Vitsissä on kuitenkin myös totuus. Valitettavan usein tuotetiedonhallinta on ratkaistu useilla rinnakkaisilla ja päällekkäisillä Excel-tiedostoilla. Välttämättä prosessia ei ole juurikaan mietitty tai paremmasta tavasta ei ole tietoa.

Excel on loistava työkalu moneen asiaan. Meidänkin PIM-tuotteessa Excel-tiedostoilla voidaan tehdä massapäivityksiä tuotetietoihin tai ottaa tuotetietoa rikastettavaksi tai raportteina ulos. Exceliä voidaan käyttää CRM-järjestelmänä, BI-työkaluna jne. Excel on varmasti myös käytetyin PIM-järjestelmä. Excelin valinta työkaluksi on myös helppo ymmärtää: se on halpa, tietomalli on joustava ja monelle jo entuudestaan tuttu. Sen avulla tietoja on myös kohtuullisen helppo välittää muihin järjestelmiin.

Excel ei kuitenkaan sovi kaikkeen. Keskitettynä tuotetietokantana se harvoin toimii edes välttävästi. Tässä muutama perustelu:

Tietoturva
Miten varmistetaan, että tuotetiedon “master” on varmistettu? Otetaanko Excel-tiedostoista varmuuskopioita? Kulkeeko koko yrityksen tuotetieto yksittäisen käyttäjän kannettavan mukana ympäri maailmaa? Jos käyttäjä tekee paikallisesti muutoksia, onko työasema varmistettu? Jos käyttäjä vahingossa poistaa koko välilehden, mitä tapahtuu?  Tallentuuko tieto, kuka muokkasi mitäkin tietoa ja milloin?

Tietomalli
Vaikka Excel-tiedostoon voidaan mallintaa hyvin erilaista tietoa, kuinka helposti se tukee seuraavaa:

  • Erilaisten tuotteiden erilaisten tietomallien mallintaminen (ja tiedonsyötön ohjaaminen sen mukaan)
  • Tuotteiden välisten relaatioiden tai linkkien määrittely
  • Tuotteisiin liittyvien kuvien ja liitetiedostojen liittäminen ja hallinta
  • Kategorioiden, ryhmien ja luokitteluiden hallinta

Myös erilaisten sääntöjen ja logiikoiden rakentaminen Exceliin on työlästä. Miten määritellään, että jokin tieto on pakollinen?

Monen käyttäjän tuki
Miten Excel-tiedosto tukee monen käyttäjän yhtäaikaista käyttöä? Onko eri roolien tarvitsemat tiedot eri tiedostoissa? Miten tiedot pysyvät ajantasalla? Onko viimeisin tieto yhteisessä Excelissä, vai onko käyttäjällä paikallinen kopio tiedostosta.

Kuvat
Miten tuotteisiin liittyvät kuvat hallitaan Excel-PIM:ssä? Luultavasti erillisessä verkkolevykansiossa? Miten kuvista tehdään sopivat versiot eri kanaviin? Automatisointi yksinkertaisissakin asioissa muodostuu joko vaikeaksi tai mahdottomaksi.

Haettavuus
Miten helposti tuotteet on haettavissa Excelistä? Jos tietomalli on hiemankaan monimutkainen, on tietoa luultavasti hajautettu useaan tiedostoon? Jos tuotteita on kymmeniä tai satoja tuhansia, ja attribuutteja vaikkapa pari sataa on Exceleissä soluja jo kymmeniä miljoonia. Ei kovin näppärää.

Integraatiot
Kuinka helppo Excelistä on tehdä aito järjestelmäintegraatio esim. verkkokaupppaan? Moderni PIM-järjestelmä tarjoaa rajapintoja, joista Exceliä käyttävät voivat vain unelmoida. Esim. JSON pohjainen REST-rajapinta tarjoaa loistavat mahdollisuudet järjestelmien helppoon integrointiin.

Käytettävyys
Onko Excel-käyttöliittymä suunniteltu tehokkaaseen tuotetiedon ylläpitoon? Tuskin.

Kanavat
Me PIM-maailmassa puhumme kanavista. Eli miten tuotetietoa käytetään erilaisissa myynnin ja markkinoinnin kanavissa. Kuinka helposti Excel-tietoa saadaan esim. sähköisiin kanaviin tai automatisoituihin printtiaineiston prosesseihin?

Ota yhteyttä, niin kerromme mielellämme lisää miten tuotetiedonhallinta kannattaa oikeasti ratkaista.