Kun asiakas avaa PDF-käyttöohjeen, hän olettaa sen vastaavan hänen koneensa mallia ja ohjelmistoversiota. Jos ohje onkin tehty vanhemmalle versiolle, seuraukset näkyvät huolto-ohjeiden virhetulkintoina, turhina tukipyyntöinä ja huonoimmillaan työturvallisuusriskeinä. Syy ei yleensä ole itse tekstissä vaan siinä, miten ohje on yhdistetty oikeaan julkaisuun.
Tässä oppaassa käydään läpi, miten dokumentaation metatiedot ratkaisevat tämän ongelman. Aloitamme syistä, jatkamme käytännön kentistä ja säännöistä ja päätämme laadunvarmistukseen. Näin saat selkeän rungon oman metatietojen hallinnan arviointiin.
Mistä väärä ohje julkaisussa johtuu?
Väärä ohje päätyy julkaisuun, kun järjestelmä ei tiedä, mille tuotteelle, versiolle, markkinalle ja kielelle ohje on tarkoitettu. Sisältö voi olla täysin oikein kirjoitettu, mutta ilman riittäviä tietoja se ei löydä oikeaa paikkaansa julkaisussa.
Metatiedot ovat tietoa sisällöstä, eivät sisältöä itseään. Ne kertovat esimerkiksi, mihin tuotemalliin ohje liittyy, mikä sen versio on ja milloin se on hyväksytty. Kirjastovertaus on kirjan luettelointitiedot: sama kirja on hyödytön, jos sitä ei löydy hyllystä oikealla tunnisteella.
Tyypillisiä syitä väärään kohdistukseen ovat:
- tiedostonimeen ja kansiorakenteeseen luotetaan metatietojen sijaan
- sama ohje kopioidaan useaan versioon ja muutokset päivitetään vain osaan kopioista
- tuotteen variantit on merkitty vapaatekstinä, jolloin kirjoitusasut vaihtelevat
- hyväksyntätila ei näy julkaisuprosessille
Esimerkiksi konepajassa nosturin huolto-ohje voi olla voimassa kahdelle mallisarjalle mutta ei kolmannelle. Jos rajaus on vain kirjoittajan muistissa tai tiedoston nimessä, julkaisija ei voi varmistaa sitä.
Metatietokentät, jotka ohjaavat julkaisua
Julkaisua ohjaavat metatietokentät ovat ennalta määriteltyjä kenttiä, joiden arvoista julkaisu päättelee, mitkä sisällöt kuuluvat mihinkin tuotokseen. Kun aiemmin kuvatut syyt on ymmärretty, kenttien tehtävä on helppo hahmottaa: ne korvaavat arvailun sovituilla arvoilla.
Perustason metatietokentät
Useimmissa teollisuusyrityksissä kannattaa aloittaa pienestä, mutta selkeästä joukosta:
- Julkaisun tunniste: yksilöi ohjeen ja sen version, jolloin sama sisältö on aina jäljitettävissä
- Tuote ja malli: kertoo, mille tuotteelle tai tuoteperheelle sisältö on voimassa
- Versio ja tila: luonnos, tarkastuksessa, hyväksytty tai vanhentunut
- Kieli ja markkina-alue: ohjaa käännökset ja alueelliset erot oikeisiin julkaisuihin
- Kohderyhmä: esimerkiksi käyttäjä, huoltoteknikko tai asentaja
- Voimassaoloaika: aloitus- ja päättymispäivä
Ehdolliset ja lisäkentät
Perustason päälle voi lisätä kenttiä, jotka tukevat ohjeiden kohdistamista tarkemmin. Näitä ovat esimerkiksi optiot, ohjelmistoversio tai valmistussarjan numerovälit. Kannattaa lisätä vain kenttiä, joilla on todellinen käyttötarkoitus julkaisussa, koska jokainen ylimääräinen kenttä vaatii ylläpitoa.
Käytännössä arvot kannattaa valita valmiista luettelosta vapaatekstin sijaan. Kun tuotteen nimi on aina ”Malli X200” eikä välillä ”X-200” tai ”X 200”, järjestelmä voi suodattaa sisältöä luotettavasti.
Säännöt ja automaatio julkaisun tueksi
Julkaisusäännöt kertovat, miten metatietojen arvot vaikuttavat siihen, mitä sisältöä mihinkin julkaisuun poimitaan. Kentät ovat vasta raaka-aine. Säännöt tekevät niistä toimivan prosessin.
Yksinkertainen sääntö voisi kuulua näin: julkaisuun otetaan vain hyväksytyt sisällöt, joiden tuotemalli vastaa julkaisun mallia ja joiden voimassaolo kattaa julkaisupäivän. Sama sääntö toimii jokaisella kerralla, riippumatta siitä, kuka julkaisun kokoaa.
Esimerkki arjesta: yritys julkaisee saman käyttöohjeen suomeksi, ruotsiksi ja englanniksi. Kun kielikenttä on kunnossa, jokainen kieliversio kokoaa itsensä oikeasta sisällöstä. Jos yksi käännös on vielä tarkastuksessa, tilakenttä voi estää sen julkaisun ja nostaa asian esiin ennen kuin virheellinen ohje lähtee asiakkaalle.
Rakenteisessa sisällönhallinnassa tämä on luontevaa, koska sisältö on pilkottu pieniin, uudelleenkäytettäviin komponentteihin. Esimerkiksi DoX CMS hallitsee sisältöä juuri tällä tavalla, jolloin metatiedot voivat ohjata julkaisua komponenttitasolla koko dokumentin sijaan. Automaatio ei kuitenkaan korvaa harkintaa, vaan se toistaa sovitut säännöt tarkasti.
Metatietojen laadunvarmistus ja vastuut
Metatietojen laatu pysyy hyvänä vain, jos kentille on nimetty omistaja ja arvot tarkistetaan sovituin väliajoin. Parhaatkaan kentät ja säännöt eivät auta, jos arvot täytetään huolimattomasti tai jätetään päivittämättä.
Käytännön laadunvarmistus
Laadunvarmistuksen voi rakentaa muutamasta toistettavasta tarkistuksesta:
- Pakolliset kentät täytetään ennen kuin sisältö voidaan viedä tarkastukseen.
- Arvot valitaan sovituista luetteloista, ei kirjoiteta vapaasti.
- Ennen julkaisua tarkistetaan, että julkaisun tunniste, versio ja kieli täsmäävät.
- Vanhentuneet sisällöt arkistoidaan tilamerkinnällä, ei poisteta ilman jäljitettävyyttä.
Kuka vastaa mistä?
Selkeä vastuunjako estää sen, että kaikki olettavat jonkun toisen tarkistaneen asian. Tekninen kirjoittaja vastaa sisältökohtaisista arvoista, dokumentaatiopäällikkö kenttämalleista ja sallituista arvoista, ja tuotetiedon omistaja tuotenimien ja mallien ajantasaisuudesta. Kun tuotetieto tulee PDM- tai PLM-järjestelmästä, mallitiedot voivat siirtyä dokumentaatioon sieltä, mikä vähentää käsin tehtävää kirjaamista.
Hyvä aloitus on pieni testi: valitse yksi tuoteperhe ja tarkista, löytyykö jokaiselle julkaistulle ohjeelle tunniste, versio, tila ja kieli. Puutteet kertovat tarkasti, mistä parannus kannattaa aloittaa. Jos haluat keskustella siitä, miten metatietojen hallinta voisi tukea omaa dokumentointiasi, ota yhteyttä asiantuntijaamme.
Sisältö on yleisluonteista tietoa teknisen dokumentaation hallinnasta, eikä se korvaa tuotekohtaisten turvallisuus- tai vaatimustenmukaisuusvaatimusten asiantuntija-arviointia.