ISO 9001:n prosessiajattelu kuulostaa yksinkertaiselta: tunnista prosessit, ymmärrä niiden vuorovaikutus ja ohjaa toimintaa niin, että laatu syntyy hallitusti. Käytännössä suurimmat ongelmat eivät kuitenkaan synny “prosessin sisällä”, vaan prosessien välissä – rajapinnoissa, hyväksynnöissä ja siinä hetkessä, kun tieto siirtyy ihmiseltä tai järjestelmältä toiselle.

Ja erityisen usein juurisyy on tämä: tieto on pirstaleina monessa eri paikassa. Osa on CRM:ssä, osa ERP:ssä, osa sähköposteissa, Teams-ketjuissa, Excelissä ja työntekijöiden omissa muistiinpanoissa. Silloin prosessi kyllä “pyörii”, mutta se pyörii selvittelyn voimalla.

Tässä blogissa pureudun kolmeen ISO 9001 -prosessityön ytimeen:

1. miten prosessit kannattaa kuvata niin, että niistä on hyötyä
2. mitä prosessien rajapinnat ja pullonkaulat tarkoittavat käytännössä
3. miten prosessien välinen viestintä ja tiedonhallinta saadaan toimivaksi – etenkin silloin, kun järjestelmiä on monta

1) Mitä ISO 9001 edellyttää prosessien kuvaamiselta?

ISO 9001 ei käske piirtämään tietynlaisia kaavioita, mutta se edellyttää, että organisaatio:

• tunnistaa keskeiset prosessinsa
• ymmärtää prosessien järjestyksen ja vuorovaikutuksen (miten prosessit linkittyvät toisiinsa)
• määrittelee prosessien ohjauksen kannalta olennaiset tekijät (vastuut, resurssit, tavoitteet, mittarit, riskit, ohjaus)

Hyvä prosessikuvaus ei ole “romaani” eikä työohje jokaiselle klikkaukselle. Se on yhteinen malli siitä:

• mikä käynnistää prosessin
• mitä arvoa syntyy (asiakkaalle tai seuraavalle prosessille)
• mitä tietoa ja resursseja tarvitaan
• mikä on valmiin tuotoksen laatuvaatimus
• miten onnistumista seurataan ja varmistetaan

Kun kuvaus on sopivalla tasolla, se auttaa johtamaan toimintaa, kouluttamaan uusia ihmisiä ja kehittämään työtä – ilman että kukaan kokee sitä “paperityöksi”.

2) Prosessien väliset rajapinnat: missä laatu vuotaa ja työ hidastuu

Rajapinta on kohta, jossa prosessin tuotos luovutetaan eteenpäin seuraavalle prosessille tai roolille. Rajapinta voi olla tietoa, päätös, materiaali tai vastuun siirtymä. Rajapinnat ovat kriittisiä, koska niissä yhdistyy kolme riskiä: tieto on usein epätäydellistä, omistajuus on epäselvää ja siirto tapahtuu monen kanavan ja järjestelmän kautta.

Monimutkaisten kaavioiden sijaan rajapinnalle kannattaa sopia viisi asiaa:

• Mitä luovutetaan? (tieto/dokumentti/tuote/päätös)
• Kenelle? (rooli, ei henkilönimi)
• Missä? (järjestelmä/työkalu – “yksi totuuspaikka”)
• Mihin mennessä? (vasteaika / palvelutaso)
• Millä laatukriteerillä? (tarkistuslista, hyväksyntä, validointi)

Kun tämä tehdään 5–10 tärkeimmälle rajapinnalle, prosessien toimivuus paranee usein nopeasti.

3) Pullonkaulat ja haasteet: miksi sama työ tehdään kahteen kertaan?

Pullonkaula on prosessin kohta, joka rajoittaa läpimenoa: syntyy jonoja, odottelua ja kiirettä. Haaste voi olla myös laatuun liittyvä: virheiden määrä kasvaa, reklamaatiot lisääntyvät tai työtä palautuu jatkuvasti takaisin.

Tyypillisiä pullonkauloja ovat hyväksynnät, puutteelliset lähtötiedot, priorisointiepäselvyys, resurssipiikit sekä uudelleentyö ja korjauskierrokset. Mutta hyvin usein näiden taustalla on yksi yhteinen tekijä: tieto ei ole yhdessä paikassa, eikä sen “oikeaa versiota” ole helppo löytää.

4) “Monta järjestelmää” ja pirstaleinen tieto: prosessien hiljainen tappaja

Monessa organisaatiossa järjestelmät ovat syntyneet vaiheittain: CRM, ERP, projektinhallinta, dokumenttipankki, sähköposti, Teams – ja usein vielä Excel “välissä”. Jokainen työkalu on joskus otettu käyttöön hyvällä syyllä, mutta kokonaisuus jää helposti rakentamatta.

Seurauksena syntyy pirstaleinen tiedonvirta:

• sama tieto löytyy useasta paikasta eri versiona
• kukaan ei ole varma mikä on uusin versio
• tietoa “täydennetään” matkalla, mutta päivitys ei siirry kaikkiin paikkoihin
• ihmiset varmistavat asioita kysymällä → syntyy “selvittelyprosessi”, jota ei ole kuvattu minnekään

Tässä kohtaa ongelma ei ole vain tehokkuus. Se on myös laaturiski: väärä tieto johtaa väärään toimitukseen, virheelliseen laskuun, viivästymiseen ja reklamaatioihin.

5) Miten tämä ratkaistaan ilman massiivista IT-hanketta?

Hyvä uutinen: usein iso osa hyödyistä saadaan jo pelisäännöillä – ei ostamalla uutta järjestelmää.

Ensimmäinen askel on sopia “ensisijainen tietolähde” per tietotyyppi: missä asiakastieto elää, missä tilauksen ja toimituksen faktat ovat, missä projektin status pidetään ja missä viralliset dokumentit sijaitsevat. Tieto voi näkyä monessa paikassa, mutta sen virallinen lähde pitää olla selvä.

Toinen askel on tehdä näkyväksi päivitysvastuut ja muutosviestintä. Kuka päivittää, minne päivittää ja miten muutoksesta kerrotaan niille, joita se koskee? Ilman tätä käy klassinen tilanne: tieto muuttuu yhdessä paikassa, mutta työ jatkuu vanhalla tiedolla muualla.

Kolmas askel on lisätä rajapintoihin minimitarkistuslista: mitä tietoja pitää olla kasassa ennen kuin työ siirtyy eteenpäin. Tämä ehkäisee “lähetetään sinnepäin ja selvitetään myöhemmin” -mallia, joka on monen virheen ja viiveen juurisyy.

6) Tärkeä periaate pirstaleisuuden ehkäisyyn

Älä jaa “tietoa”, jaa aina sen virallinen sijainti.

Kun lähetät liitteenä speksin, tarjouksen tai ohjeen, teet siitä samalla kopion. Ja kopioilla on huono tapa alkaa elää omaa elämäänsä: joku kommentoi yhtä versiota, toinen tallentaa uuden nimellä “final2”, kolmas lähettää vanhan eteenpäin – ja pian kukaan ei ole varma, mikä on se oikea ja uusin.

Siksi kannattaa sopia, että tietoa ei lähetetä eteenpäin kopioina, vaan aina näin:

• Linkki siihen paikkaan, jossa tieto “asuu” (järjestelmässä, dokumenttipankissa, projektityökalussa)
• ja tarvittaessa lyhyt viesti: mitä muuttui ja mitä sinulta odotetaan

Tämä on erityisen tärkeää silloin, kun tieto elää ja päivittyy – esimerkiksi speksit, toimituspäivät, piirustukset tai projektin vaatimukset. Jos speksi muuttuu, liite on heti vanha. Linkki sen sijaan vie aina viimeisimpään versioon.

Käytännön esimerkki:

Ei näin: “Tässä speksi liitteenä.”
Vaan: “Tässä speksin linkki (virallinen versio). Päivitin kohdan 3.2 – käy se läpi ja kuittaa, että muutos on ok.”

Kun tiimi toimii näin, pirstaleinen tieto vähenee nopeasti: vähemmän “mikä versio tämä on?” -kysymyksiä, vähemmän virheitä ja paljon vähemmän turhaa selvittelyä.

7) Prosessien välinen viestintä: tee siitä prosessi, ei sattumaa

Kun järjestelmiä on monta, viestintä nousee entistä tärkeämmäksi. Mutta viestintä ei toimi, jos se perustuu ihmisten muistiin ja “toivottavasti joku huomaa” -malliin.

Toimiva viestintäprosessi syntyy, kun sovitaan:

• milloin viestitään (tilaus valmis, poikkeama, muutos, hyväksyntä)
• mitä viestitään (minimitiedot + linkki totuuspaikkaan)
• missä viestitään (yksi kanava per tilanne)
• kuka vastaa (lähettäjä ja vastaanottaja rooleina)
• mikä on vasteaika (kuittaus, päätös, eskalointi)

Yksi käytännön ohjenuora kannattaa ottaa tavaksi: älä lähetä tietoa kopiona, lähetä linkki tiedon ”kotiin”.

Lopuksi: prosessit eivät ole paperia varten – vaan sujuvaa arkea varten

ISO 9001 ei ole kaavioita varten. Se on sitä varten, että laatu ja sujuvuus syntyvät hallitusti, myös silloin kun arki on kiireinen ja järjestelmiä on useita.

Kun prosessit kuvataan järkevästi, rajapinnat sovitaan konkreettisesti ja määritellään mistä uusin versio ja mistä ”tiedon koti” löytyy, työn läpimeno nopeutuu, virheet vähenevät ja ihmiset saavat keskittyä tekemiseen – eivät asioiden selvittelyyn.

Jarno Saarinen

Kehitys- ja vastuullisuusjohtaja