Norsu vai gepardi?


Vapaa-ajattelijan päiväkirjasta, osa 5

TuomasLevoniemiIt-alalla on menossa kaikkien aikojen murros sitten pc:n julkaisun. Kun pc ei enää ole kukkulan kuningas, alkaa tapahtua muutakin kuin uusjakoa päätelaiterintamalla. Enkä puhu pilvistä tai seuraavasta suuresta murroksesta ”Internet of Things”, koska katson, että ne ovat alusta ja joukko uusia päätelaitteita joiden kautta me tai ympäristö kytkeytyy internetiin.

Tekniikasta on helppo kirjoittaa, mutta paljon tärkeämpää on, miten uusi tekniikka muuttaa tapaamme toimia. Tämä muutos tulee aina varkain ja jälkijunassa. Tästä ei kirjoitella vertailuja alan lehdissä eikä siitä puhuta käytävillä. Suuret toimintatapojen muutokset kuitenkin vievät yhteiskuntaa eteenpäin.

Yksilötasolla jokainen voi itse punnita muutoksen tuoman riskin, kiinnostavuuden ja hyödyn. Yritys- ja yhteisötasolla muutoksen pelko ja vähättely nousevat usein pintaan.

Syynä on pelko. On aina helpointa katsella, miten kilpailijat pärjäävät ja muuttaa omaa toimintaa vasta, kun on pakko. Miksi suuret yritykset yleensä jossain vaiheessa romahtavat juuri silloin, kun pitäisi hypätä seuraavalle tasolle? Syitä on toki monia, ja monet relevantteja. Sisäisestä näkökulmasta yksi muutoksen hitauden syy on se, että työ ja prosessit on paloiteltu pieniin osiin. Kun näitä pieniä osia mitataan, huomio keskittyy niihin eikä nähdä, mitä ympärillä tapahtuu.

Pilkkomisen takia kukaan ei tiedä

a) miksi jokin tehtävä tehdään
b) mihin osan tekeminen tai tekemättä jättäminen vaikuttaa,
c) miten tehtävää voisi kehittää ja uudistaa ja
d) myös työn tekemisen mielekkyys kärsii, kun ei nähdä kokonaisuutta.

Jos tehtävä on lisäksi hyvin monivaiheinen, sitä ei voi johtaa isossa organisaatiossa ilman massiivista mittaus- ja projektihallintakoneistoa. Tämä tuo jäykkyyttä ja hitautta pelkästään asiakkaan kanssa sovittujen tehtävien suorittamisessa. Samalla seurantaprosessit ja -organisaatio lihottavat kulurakennetta. Juuri tämän takia pieni yritys voi tuntua nopealta, ketterältä ja edulliselta.

Onko tämä oikeasti paras tapa toimittaa laadukasta palvelua asiakkaalle? Miten asian voisi tehdä tosin isossa yrityksessä?

Mieleen tulee kaksi vaihtoehtoa. Miksi vakava ongelma saadaan isossakin yrityksessä kuntoon tunneissa, kun saman määrän työtä tarvitseva projekti kestää helposti viikkoja ellei kuukausia? Mikä on ero normaalissa työssä ja vaativamman ongelman selvittämisessä? Usein työn kuitenkin tekevät samat ihmiset.

Ainoa ero lienee se, että vakavaa ongelmaa ratkottaessa asiantuntijoilla on lupa keskittyä ongelmaan ja pähkäillä yhdessä parhaiden asiantuntijoiden kanssa, kunnes ongelma on korjattu. Normaalissa it-projektissa asiat vellovat asiantuntijalta toisella useita kymmeniä kertoja edestakaisin. Jokainen vahdinvaihto tuo viiveitä. Seurauksena on kuukausien pituinen projekti.

Onko normaali it-projekti sitten tehokas ja edullinen? Harvemmin. Ehkä isommissakin firmoissa projekteja pitäisi tehdä niin kuin pienessä yrityksessä. Sulkeudutaan yhdessä huoneeseen porukan kansa, kunnes homma on valmis! Nopeuden lisääntymisen lisäksi motivaatio paranee ja asiakas on varmasti tyytyväisempi. Viedään ihminen takaisin tekemisen keskiöön Fujitsun vision ”Human Centric Intelligent Society” Mukaan, ja automatisoidaan liukuhihnaa vaativat prosessityöt. Tietotekniseen työhön ja sen kehittämiseen sopii huonosti hajuttomaksi ja mauttomaksi palasteltu prosessityö.

norsugepardi

Kuva Seagate inc.

  • Tuomas Levoniemi toimii kehityspäällikkönä Fujitsun Managed Service -yksikössä. 

2 Comments

Add yours
  1. 1
    PetteriP

    Vakavan ongelman tapauksessa on kirittäjänä maine, kunnia, SLA ja sanktiot. Projektin saa ryssiä vapaasti ilman noiden vaikutusta. Toisaalta, jos samat henkilöt ratkovat sekä akuutteja ongelmia että tekevät kehitysprojekteja, arvaat varmaan kumpi priorisoidaan.

  2. 2
    Tuomas Levoniemi

    Siitä olen eri mieltä ettei asiakkaalle tehtävässä _normi_ projektissa voisi mennä maine. Onhan näistä melkein viikoittain esimerkkejä alan julkaisuissa. Kehittäminen on vielä omat lukunsa. Tärkeys järjestys menee kutakuinkin siten, että Major Broblem (ITIL- terminä) menee kaiken ohi. Sitten tulee normaali projekti. Tästäkin on kaksi versiota tehdäänkö projekti asiakkaalle vai sisäisesti. Viimeisenä tulee sitten kehitysprojekti. Tästäkin lienee kaksi astettu. ”Roadmapattu” ja resurssoitu kehitysprojekti ja sitten sellainen joka pitää vielä myydä sisäisesti 🙂 Resurssoidusta saatetaan silti ”varastaa” resursseja tärkeämpiin projekteihin.

Comments are closed.