Onpas sinusta kasvanut jo iso järjestelmä!

*DM-järjestelmien kanssa painiessa otsikon mukainen lausahdus tulee usein mieleen. Erilaista tietoa on runsaasti, tieto on syvästi rakenteellista ja monimutkaista. Kukaan ei liene täysin selvillä siitä mitä kaikkea yksittäinen tuoterivi saattaa sisältää. On siirtotietoa, suuretietoa, lajittelutietoa, kuvauksia jne. Tästä tuskasta kertoo myös järjestelmien tietorakenteet; Esimerkiksi SAP:n tietokanta (RDBMS) sisältää tuhansia tai kymmeniä tuhansia tietokantatauluja. ECC ja R/3 koostuu yli kolmestakymmenestä tuhannesta taulusta kun taas CRM saattaa jäädä alle kymmenen tuhannen. Vertailun vuoksi jotkin PDM-järjestelmät sisältävät tauluja vain noin 100-200. Rakenteellisuus on olennainen osa järjestelmiä, mutta samalla rakenteellisuus ainakin tietoalkiotasolla tuo mukanaan melkoisia ongelmia mitä tulee itse järjestelmien toimintaan. Viitteiden ylläpidon, tiedon reaaliaikaisuuden ja tiedon esittämisen haasteet lisääntyvät eksponentiaalisesti, mitä suuremmaksi objektien rakenne kasvaa. Tiedonhaku vaikeutuu ja järjestelmän koko ”pullistuu”.

Järjestelmädieetti

Ratkaisuna monimutkaisiin rakenteisiin ehdotan  NOSQL-tyyppisiä järjestelmiä, tuettuna relaatiokannalla metadatan tallentamista varten. Poistetaan turhat rakenteelliset attribuutit ja tuodaan rekursion sijaan peliin leveät tietueet, kuten esim. BigTable, HBase, Amazon SimpleDB, Cassandra, Lucene jne. Mitä laveampi data tarkoittaa käyttäjälle? Tietokanta-/kyselymielessä jokaiseen liitokseen voidaan liittää aikakustannus. Kustannus ei ehkä ole suuri (tyypillisesti millisekunteja keskikokoisessa järjestelmässä), mutta kun näitä kustannuksia on paljon, puhutaan helposti sekunneista tai jopa kymmenistä sekunneista.

Kuinka merkittäviä sekunnit ovat? Jos haet tietoa vaikkapa 500 kertaa päivän aikana, löydökset ovat 70% tarkkoja (lue: haet tietoa todella hyvin ja tarkasti) sekunnin kustannus on jo kohtuullisen merkittävä. Kustannus (hakutulokset ja niiden kahlaaminen huomioonottaen) kuluttaa työpäivästäsi n. 20 %. Merkittävä määrä aikaa siis menee tiedon hakemiseen. Laveassa tietomallissa liitokset ovat jo soveltuvin osin kiinni itse alkuperäisessä objektissa ja tästä suora seuraus on hakuaikojen lyheneminen, tiedonsaannin tehostuminen sekä myös hakuominaisuuksien suoraviivaistuminen.

Muistithan bonukset?

Mitä muuta etua saavutetaan? Kun mukana ei enää kuljeteta merkityksetöntä sisäistä tietoa, tilantarve palvelimella pienenee, riippuen tietorakenteesta. Lisäksi tehokkaammat ja nopeammat järjestelmät voidaan ottaa esimerkiksi data mining-käyttöön (duplikaattien poisto, tiedon eheyden tarkistus, samankaltaisuuksien poiminta, puuttuvien tietojen etsintä jne.).  Voidaan hyödyntää ”uudenlaisia” ja tehokkaampia hakutapoja, ja mikä tärkeintä, voidaan esitellä semantiikkaa, mikä taasen tarjoaa aivan uusia ja mullistavia tapoja ”* Data Managementtiin”. Semantiikasta jatkakaamme myöhemmin, tämänkertainen ajatusvirta olkoon tässä.

– Juha –

Seitsemän kuolemansyntiä

Hyllystä tarttui käteen vanha kirja ”Anti-patterns: Refactoring Software, Architectures, and Projects in Crisis”. Varsinkin ohjelmistokehityksen parissa työskentelevän kannattaa tähän perusteokseen tutustua, sieltä saattaa löytyä syitä kävellä tuijottamaan itseään vessan peilistä.

Kirjassa esitellään ongelmien perimäisiksi aiheuttajiksi seitsemän kuolemansyntiä. Voisiko näistä perisynneistä johtaa myös järjestelmähankkeiden ongelmien syitä?

7 sins

1. Kiire

Kiirehän on aina, deadline jyskyttää päälle koko ajan. Tietysti hyvin suunniteltu aikataulutus tuo projektille tarvittavaa ryhtiä. Synniksi kiire muuttuu siinä vaiheessa, kun tehtäville ei anneta niiden vaatimaa aikaa ja puristetaan hatusta vedettyyn aikatauluun taskit kohdalleen luottaen tekijöiden sankarillisiin yksilösuorituksiin. Tälläinen toimii kerran ja kaksi, ehkä kolmekin jos tekijää oikein kehutaan, mutta sitten se on siinä.

2. Välinpitämättömyys

Välinpitämättömyys voi ilmetä monellakin tavalla. Esiintuleva ongelma siirretään syrjään analysoimatta sen kriittisyyttä, koska se ei oikein tunnu osuvan kenenkään osapuolen vastuualueelle. Toimintatavoissa on ongelmakohtia, mutta muutosta ei saada aikaan , koska ’aina on tehty näin’.

3. Ahdaskatseisuus

Ahdaskatseisuus ja näköalattomuus johtuu pitkälti muutoksen pelosta. Järjestelmähankkeet, yllättäen, aiheuttavat usein muutoksia. Muutoksen pelko aiheuttaa usein tunnepohjaista vastustusta, pelkoon reagoidaan vihamielisesti. Jos jättää muutosvastarinnan huomioimatta, se potkaisee vähintään nilkkaan myöhemmin.

4. Laiskuus 

Laiskuudesta löytyy varmasti esimerkkejä. Jos projektipalaverissa joku sanoo, että ”en usko että sitä XXX tarvitsee tehdä”, ja tuo XXX asia on sinun vastuualueellasi, niin herätys! Jollain tavalla joudut tämän asian hoitamaan myöhemmin ja yleensä alkuperäistä suuremmin kustannuksin. Tässä kohdassa tuntuisi avainsanoja olevan QA, muutoksen hallinta ja lisensointikysymykset.

Usein törmää myös siihen, että jätetään ratkaisu puolitiehen. Ajatellaan, että tehdään ensi vaiheessa vain välttämätön ja loput joskus myöhemmin. Sitä myöhemmin ei koskaan tule. Samalla on kuitenkin tiedostettava, että tie helvettiin on päällystetty hyvillä aikomuksilla, kuten täydellisyyden tavoittelulla (ks 5. Ahneus).

5. Ahneus

Ahneudessa mikään ei tunnu riittävän. Ahne haluaa vain lisää, vaikka sitä ei muillakaan olisi, eikä missään nimessä luovu omastaan toisen tai yhteiseksi hyväksi.  Järjestelmähankkeiden kohdalla ahneus esiintyy keskittyminä. Toimintoja ja prosesseja keskittyy kokonaisarkkitehtuurissa järjestelmäkartassa yhteen paikkaan. Ydinprosessien ja -toimintojen kohdalla tämä saattaa olla mielekästä ja tietoinen valinta, mutta seuraukset on syytä tiedostaa.

6. Tietämättömyys

Tietämättömyys tuntuu tulevan vastaan päivittäin. Nykymaailman informaatiotulvassa ja muutosten määrässä on oma haasteensa pitää osaaminen ajan tasalla. Kerran hyväksi koettu ratkaisu saattaa olla vanhentunut ja parempaa olla jo tarjolla. Toisaalta uusin teknologia ja innovaatio ei välttämättä ole aina alkumetreillään ihan paras ratkaisu. Oman ajantasaisen ratkaisupakin hallinta on tänä päivänä onnistumisen edellytys.

7  Ylpeys

Tästä löytyy varmasti esimerkkijä ja sudenkuoppia. Kuvitellaan perusteettomasti, että kyllä osaamista löytyy, uskotaan sokeasti omiin kykyihin, kuvitellaan datan laadun ja tietomallien olevan täydellisiä ja aukottomia. On eri asia luulla tietävänsä kuin tietää tietävänsä.

Teologiassa yhtenä synnin tunnusmerkkinä pidetään tietoisuutta väärin tekemisestä. Tässä yhteydessä tiedon puute on kuitenkin nähtävä yhtenä syntinä. Toisaalta tiedon haalimisen riivaamana ajautuu helposti ahneuden syntiin, johtaa kiireen kautta välinpitämättömyyteen ja ahdaskatseisuuteen. Samoin käy jos osaamisen kehittäminen laiminlyödään kiireen välttämiseksi ja laiskuuden vuoksi – päädytään helposti ahdaskatseisuuden ja ylpeyden synteihin, joissa oma osaaminen ja toiminta nähdään ainoana olemassa olevana  ratkaisuna ja palvotaan sitä kultaisena vasarana ja kaikki ongelmat ovat nauloja.

Näiden seitsemän kuolemansynnin välttäminen näyttäisi tarkoittavan yleisesti kohtuullisuutta ja kokonaisuuden huomioimista. Osa-optimointi ja yhteen asiaan keskittyminen johtaa syntiin ja kadotukseen, näin mahtipontisesti sanottuna. Jos esimerkiksi Six-Sigma yleensä pyrkii estämään osa-optimointia, niin missähän on tapahtunut virhe, jos kuudella koitetaan korjata seitsemää. Puuttuuko Six-Sigmasta jotain vai onko seitsemässä kuolemansynnissä jotain liikaa. Palataan tähän numerologiaan tuonnempana

– Software Samurai –

Järjestelmän orjat sorron yöstä nouskaa!

The workers shall control the means of production

Yllä mainitussa sosialismin siemenessä piilee viisaus, etenkin jos tarkastellaan sitä järjestelmävinkkelistä. Yksi yleisimmistä epäonnistuneen käyttöönoton syistä on nimittäin käyttäjävastarinta. Käyttäjät, nuo järjestelmämaailman työläiset, määrittelevät onko järjestelmästä todellista hyötyä vai ei ja liian usein heidän tarpeensa jäävät kuulematta.

Se sosialistinen ajatus, että työläinen antaisi kaikkensa organisaation puolesta, taitaa olla aikaa sitten kuollut ja kuopattu.

Aika usein näkee käyttöönottoprojekteja, joissa käyttäjille kylmästi todetaan, että siirrymme nyt käyttämään tätä. Piste. Käytä! Koulutuksesta säästellään. Harva järjestelmä on kuitenkaan niin näppärä, että käyttäjä kuin käyttäjä osaa sitä siltä istumalta käyttää ja omaksuu sen välittömästi osaksi jokapäiväistä työtään. Se käyttäjiltä tuleva nurina syö hyvää työtehoa ja kallista aikaa. Pahimmassa tapauksessa tosiaan kaataa koko projektin.

Punainen systeemi

Miten kuroa luokkaerot umpeen?

Miten sitä nurinaa voi sitten vähentää? Meidän järjestelmätoimittajien osalta vastaus on tehdä vakaasti toimivia ja helppokäyttöisiä järjestelmiä ja luettavia käyttöohjeita sekä tarjota mahdollisuus kouluttautua järjestelmän käytössä. Ainakin tähän pyritään.

Organisaation sisällä käyttäjävastarintaa voi vähentää ainakin seuraavin keinoin:

  1. Viesti ajoissa ja riittävän aktiivisesti projektin etenemisestä
  2. Käyttäjien osallistuttaminen projektiin ja päätöksentekoon
  3. Kerro ja osoita hyödyt käyttäjätasolla -> Vastaa kysymykseen miksi tätä pitäisi käyttää
  4. Älä pakota

Viestintä on vaikeaa. Ei oikein viitsittäisi spämmätä sähköpostia kaikille, eikä toisaalta aika riitä kirjoittamaan projektista mitään sisäistä blogiakaan… Projektin etenemisestä viestiminen kuitenkin pitää käyttäjät ajan tasalla, eikä muutos hyökkää yllättäen niskaan. Toimiva sisäinen viestintä on kaikenlisäksi eräs suurimmista työtyytyväisyyteen vaikuttavista tekijöistä. Ihmisillä on synnynnäinen halu tietää minne ollaan menossa ja miksi.

Tulevien käyttäjien osallistuttaminen projektiin voi tuntua vaikealta, mutta kenelle sitä järjestelmää taas ollaan ottamassakaan käyttöön? Lähinnä tarkoitan nyt sitä, että käyttäjien toiveet ja esitykset tulisivat myös huomioitua järjestelmän valinnassa, eikä pääosaa näyttelisi hintalappu tai yksittäisen teknouskovaisen toiveet.

Jos et osaa perustella järjestelmän hyötyjä käyttäjälle, niin miksi kukaan alkaisi käyttää järjestelmää? Perustelut tulisi nimenomaan antaa siten, että miten järjestelmä hyödyntää käyttäjää, eikä niin, että käyttäjä kokee antavansa jotain hienoa yritykselle saamatta kuitenkaan itse mitään takaisin. Äläkä pakota ketään käyttämään järjestelmää vastentahtoisesti piiloutumalla jonkun prosessimallin taakse. Sillä saavutetaan lyhytaikainen ja vaillinainen käyttö järjestelmälle, eikä projektille asetettuja tavoitteita tulla koskaan saavuttamaan.

Manifesti loppuu tähän ja lähden käynnistelemään lokakuun vallankumousta marraskuulle.

– Kalle –