Kollega muistutti KISS-periaatteesta, kun kerroin miettiväni käyttäjälähtöisiä tiedonhallinnan ratkaisuja yrityksen tarpeisiin. Lausahdus sai muistot kiirimään menneisyyteen, jossa työtovereitteni kanssa halusimme taltuttaa täysin villiksi riistäytyneet muutosprosessit. Jokainen toimi omalla tavallaan.

Vaikuttavuutta ei arvioitu. Päätösperusteita ja toteutuspäätöksiä ei kirjattu ylös. Eikä teknistä toteutustakaan perusteltu ja kirjattu siten, että myöhemmin pystyisi jäljittämään mitä ja miksi on muutettu. Muutospyyntöjä tuli suoraan suunnittelijalle käytäväkeskusteluissa tai sähköpostiin. Joskus tarve tuli esiin palaverimuistiossa. Harvemmin tehtiin virallinen muutospyyntö.

Muutosten etenemisen seuranta oli tapauskohtaista ja jokainen toimi parhaaksi katsomallaan tavalla. Muutostarpeet ja jo suunnittelussa olevien muutosten kokonaistilanne ei ollut kenenkään hallinnassa. 

Systemaattisella muutoshallinnalla oli siis sosiaalinen tilaus.

Muutosten kirjo oli moninainen. Meneillään oli eri osapuolten aloitteesta tehtäviä tuotemuutoksia, jolloin uudet tekniset ratkaisut piti suunnitella, analysoida ja viedä tuotantoon. Näiden myötä myös valmistuksessa tapahtui muutoksia. Toisaalta valmistusmenetelmiä kehitettiin ilman tuotemuutoksia. Yksi kuormittavimmista muutosten käsittelyn kannalta olivat asiakkaalta tulleet vaatimusmuutokset. Eli velvoittavista dokumenteista tuli uusia versioita ja ne piti katselmoida nopealla aikataululla, jotta osattiin reagoida valmistamiimme tuoteisiin vaikuttaviin asioihin riittävän aikaisin. Myös toiminnan kehitys loi muutoksia toimintatapoihin. Vain joitain mainitakseni.

Alussa organisaation oli vaikea mieltää, että eri tyyppisiä muutoksia voidaan hallita yhtenäisesti ja toimia samojen periaatteiden mukaisesti. En kuitenkaan tarkoita sitä, että muutosten sisältö, dokumentaatio tai toteuttamiseen käytettävät työkalut olisivat kaikissa samoja. Myös muutosryhmien kokoonpano vaihtelee käsiteltävän asian mukaan. Riittävän yksinkertainen geneerinen muutosprosessi voidaan kuvata hakemalla eri muutostapauksista yhtenäiset piirteet ja pidetään mielessä muutosten toteuttajien tarpeet.

Toimintaa sujuvoittaa merkittävästi se, että muutokset hallitaan – muutospyynnöstä sulkemiseen asti ­– yhdessä tietojärjestelmässä. Täällä kohdistetaan muutokset vaikuttavuuden mukaan. Muutokseen liittyvä informaatio lisääntyy asian edetessä. Datat tuleekin niputtaa yhteen, jotta muuttuneet asiat pystytään jäljittämään helposti vuosienkin takaa. Ajantasaisesta muutospoolista on hyvä tehdä vaikuttavuusarvioita ja toteuttamispäätöksiä kokonaisuus huomioon ottaen. Sen kautta kaikilla osapuolilla on yhtenäinen kuva meneillään olevista ja tulevista muutoksista.

Tehokkaan ja tarkoituksenmukaisen toiminnan esteenä on valitettavan usein yritykseen pesiytynyt monimutkaisuus. Esimerkiksi yksi keskeinen asia voi liittyä muutostunnisteen muodostamiseen. Jos muutosten hallinta on pirstaloitunut eri järjestelmiin, samalle muutokselle generoidaan usein uusi tunniste. Näin voi tapahtua esimerkiksi, kun muutospyyntö muuttuu muutosmääräykseksi, ennakoivan kunnossapidon listoilla oleva työ päätetään ottaa työnalle tai muutosta hallitaan myös projektina.

Toisinaan tunnisteeseen on haluttu lisätä mukaan älykkyyttä, joka ilmaisee muutoksen tyypin, projektin koon, tekniikka-alueen tai muuta sellaista. Älykkäässä tunnisteessa on sellainen hankaluus, että se ei tue muutoksen joustavaa elämänkaarta, koska harvemmin avausvaiheessa voidaan tietää, millainen tai kuinka laaja muutos on kyseessä. Älykäs tunniste myös rämettyy helposti vuosien saatossa. Kohta kukaan ei muista mitä mikäkin asia tunnisteessa tarkoittaa. Tunniste voi olla tyhmä, koska järjestelmä kyllä pitää tiedot hallinnassa.

Tunnisteen avulla informaatio pitää voida tunnistaa ja jäljittää yksiselitteisesti kaikissa olosuhteissa. Näin ollen sitä voidaan verrata ihmisen aina samana pysyvään sosiaaliturvatunnukseen. Yksilöllisen tunnisteen muuttaminen aiheuttaa aina ylimääräistä työtä, vaarantaa jäljitettävyyden ja altistaa virheille. Tämän vuoksi tiedonhallinnan kulmakiviä ovat yksilöllinen, läpi prosessin säilyvä, tunniste ja versionhallinta. 

Yrityksessä pitää tiedostaa ydinliiketoimintaan kuuluvat tehtävät. Muiden organisaation osien tulee luoda edellytykset sujuvalle tekemiselle käyttäjälähtöisesti.  Toiminnan kehittämisen tarkoituksena on purkaa vuosien saatossa pesiytynyttä monimutkaisuutta – ei lisätä sitä. Keep it simple, stupid!

Minna Innala
CAD/CAM-yhdistys
puheenjohtaja

Julkaistu Valokynä-lehdessä 3/2017