Standardielämää: Kuin 50 kilometrin kilpakävely

Standardikehityksessä on hyvin tarkkaan määritelty, mitä tapahtuu missäkin vaiheessa. Tämä toimii kaikkien osapuolien eduksi, mutta nopeaa se ei ole. Ennen kuin minä nostan kehitysasian globaalille tasolle, olen jo tehnyt alkulämmittelyt ja verryttelyt.

Kun pyyntö standardin kehittämiseen tulee, teen ensimmäisenä kartoituksen, onko tieto tarpeellinen. Aina kun pyyntö pohjautuu lainsäädäntöön, ollaan aika vahvalla perustalla. Hiukan enemmän pitää venytellä, jos kyseessä on yritysten tai toimialan tarve. Näissä kuitenkin auttaa aina, jos saan heti hyvän business case -kuvauksen. Jotta voin kirjoittaa perustelut, pitää minun tietää, miksi tietoa halutaan, mihin sitä käytetään ja mitä ongelmia on, jos sitä ei ole käytettävissä.  Tämän jälkeen katson standardista, onko siellä jo vastaavaa, jota voisi käyttää ja samalla etsin, mihin kohtaan standardia lisäys tulisi. Lukijoille tiedoksi, että GDSN-standardissa (GS1 Global Data Synchronisation Network) on muutamia tuhansia tietoelementtejä, jotka on ryhmitelty yhteenliittymiksi eli moduuleiksi.  

Seuraavaksi ollaan jo lähtöviivalla lanne notkeana valmiina aloittamaan prosessi virallisesti.  Mikäli kyseessä on yksinkertainen tietoelementin, koodin tai tarkistussäännön sisältämä ehdotus, teen siitä määrämuotoisen kehityspyynnön standardin kehitysprosessiin. Tuohon tarvitaan aina kuvaus mitä halutaan, mikä sen nimi olisi ja millainen sen määrittely on. Jos pyyntö on haastava tai kompleksinen, heitän verkot vesille muiden GS1-maiden kollegoille, lähinnä Euroopan alueella, olisiko heidän markkinoilla myös tarvetta samalle asialle. Käymme sitten yhdessä ehdotusta läpi ja hiomme sen toimivaksi muillekin. Näin minulla on jo valmiiksi tukijoita kehitysprosessissa. Aina on helpompi käsitellä asioita, jos kehityspyynnön takana on useampi kuin yksi maa.   

Lähtölaukauksen tai kehityspyynnön tallentamisen jälkeen sen käsittely alkaa. Ensimmäisenä käymme pyyntöä läpi kehitysryhmän vetäjän ja muutaman avainhenkilön kanssa. Tässä vaiheessa sitä voidaan muokata tai täydentää lisätiedoin, jotta käsittely olisi jatkossa sujuvampaa.

Kerran viikossa minulla on kansainvälinen palaveri, jossa käydään läpi tulleita kehitysehdotuksia. Tämä työryhmä on kehitysprosessin seuraava vaihe. Kehitysehdotukseen voi tulla kommentteja tai siitä halutaan tarkempaa tietoa. Tässä kohdin yleensä tulee ilmi, kuinka erilaisia tietovaatimukset voivat eri markkinoilla olla. Euroopassa on suhteellisen samantyyppistä, mutta kun mennään suuren veden yli, niin eroja kyllä löytyy. Keskustellessa käydään läpi, miten pyyntö käsitetään eri markkinoiden tarpeiden mukaisesti. On hyvä, jos voi vetää taskustaan lainsäädäntökortin. Se on aina varsinainen valttikortti ja takaa läpimenoa. Keskustelun jälkeen, joka joskus on yhdellä kertaa läpi ja joskus vie useamman palaverin, äänestetään kehityspyynnön eteenpäinviemisestä. Yleensä tarvittavat äänet tulevat ja matka jatkuu seuraavalle juottopisteelle.

Nyt on päästy jo viralliselle kommenttikierrokselle eli community review -aikaan. Tämä kestää kaksi viikkoa, jolloin kaikilla työryhmän jäsenillä on mahdollisuus antaa kehityspyyntöön kirjallisia kommentteja. Kommentit voivat olla lisätietopyyntöjä, löydettyjä kirjoitusvirheitä tai ehdotuksia kuinka selitettä parannettaisiin. Työryhmän vetäjän kanssa käyn kommentit läpi ja annan vastakommentit tai hyväksyn korjaukset. Tämän kahden viikon jälkeen kehityspyyntö käydään uudestaan läpi työryhmässä, jossa äänestetään, hyväksytäänkö se viralliseen äänestykseen. Tätä äänestysaikaa on myös kaksi viikkoa, jolloin kaikilla työryhmän jäsenillä on mahdollisuus antaa joko puolto- tai kieltoääni. Voi myös käydä antamassa ’ihan sama’ -äänen eli neutraalin kantansa.  Kun kehitysehdotus on hyväksytty, ollaan matkan puolivälissä ja alkaa ne pisimmät kilometrit.  

Edellä kuvatun ensimmäisen työryhmävaiheen voi läpäistä noin neljässä viikossa. Tämä tietysti edellyttää, että pyyntö on selkeä ja perusteet hyvät. Mutta nyt voi kysyä, että mikä ihme sitten kestää, ennen kuin tuo kehitysehdotus on standardissa käytettävänä. Tässä astuvat jälleen muodollisuudet peliin. GDSN-standardiin on sovittu neljä päivitysikkunaa vuodessa. Käytännössä päivitykseen tulevat asiat on oltava hyväksyttyinä 6–12 kuukautta aikaisemmin. Vaihteluväli on pitkä, koska tietyt tiedot, esimerkiksi uusi koodi olemassa olevalle koodilistalle, voidaan tuoda päivityspakettiin nopeammin. Uudet attribuutit tai tietoelementit vievät enemmän aikaa.

Taustalla näitä kuitenkin koko ajan työstetään. Päivitykseen tulevista tiedoista tehdään paketti, jonka jokainen osa liitetään standardiin ja määritellään suhteet olemassa oleviin tietoihin. Kun päivityspaketti on kasassa, se tuodaan taas tuohon samaan työryhmään käsiteltäväksi. Ja taas voidaan antaa kommenttia ja lopuksi äänestetään, hyväksytäänkö päivityspaketti.  

Tavoitteena on, että päivityspaketti olisi hyväksytty ja kaikki sen dokumentaatio standardin puolesta valmiina noin viisi kuukautta ennen päivitystä. Valitettavasti välillä ne myöhästyvät tai niihin joudutaan tekemään korjauksia. Kun päivityspaketit viedään testiympäristöihin, saattaa tulla esiin asioita, joita joudutaan vielä muokkaamaan. Kuitenkaan päivityksen ajankohtaa ei muuteta. 

Kehitysehdotuksen viimeisillä kilometreillä se lisätään meidän omaan tuotetietomalliimme ja otetaan käyttöön standardipäivityksen yhteydessä. Ennen kuin tietomalliamme voidaan muokata, joudutaan odottamaan, että standardin puolelta saadaan dokumentaatiot valmiiksi.  

Tällainen on pääpiirteissään prosessi, miten standardin kehityspyyntöjä käsitellään. Toki tuolla voi olla koukeroita, kuten esimerkiksi se, että asioita siirretään muihin työryhmiin käsiteltäväksi ennen kuin ne voidaan hyväksyä. Koko matkan ajan pitää kuitenkin tekniikan eli prosessin pysyä kasassa. Ei voi lähteä hyppelehtimään tai juoksemaan tai tulee hylkäys.

Standardielämää-blogisarjan kirjoittaja palvelukehityspäällikkö Mirva Alatyppö kutsuu itseään standardinkehittäjäksi ja standardinvartijaksi – jopa standardihörhöksi. Hän myös tunnustautuu uutuustuotebongariksi sekä allergeenien kyttääjäksi. Mirva on työskennellyt GS1:ssä ja sen edeltäjissä vuodesta 2003, joten hän todella tietää, miten GS1:n standardit ovat vuosien aikana eläneet.