Browsing: Johtaminen

Digitalisaation kolme muotoa

Digitalisaatio on päivän sana. Siitä puhutaan jo kaikkialla. Sen tarjoamat välineet mahdollistavat uuden liiketoiminnan luomisen, tekniikan kehittyessä syntyy myös keinoja kyseenalaistaa vanhat prosessit. Iso osa digitalisaatiota on kuitenkin kategoriaa ‘kiva juttu’. Se, että onko kivoista jutuista hyötyä onkin jo toinen asia. On, mutta..

Digitalisointi on liiketoiminnan uudistamista. Sitä voidaan lähestyä kolmella kulmalla. Tehostaminen, ehostaminen ja uuden luominen. Useimmiten lopputulema on sekoitus kahta ensimmäistä ja joskus harvoin näkee uuden luomista.

1. Tehostaminen

Tämä on digitalisoinnin muoto, jossa teknologia tarjoaa uuden tavan tehostaa olemassaolevaa prosessia. Useimmiten kustannukset menevät murto-osaan ja prosessi nopeutuu huikeasti. Esimerkkejä voisi olla ajan varaaminen tai tuotteen ostaminen verkossa. Tämä on riskittömin ja useimmiten nopein tapa toimia. Välistä tuntuu, että kaikki Suomessa tehdyt digitalisointiprojektit keskittyvät tehostamiseen. Mutta jos kerran tehostaminen toimii, niin miksi sitten tehdä muuta? No, siksi. Muista kuitenkin tämä & tämä.

2. Ehostaminen

Tässä tehdään koristeita olemassaolevan toiminnan ympärille. Usein puhutaan visualisoinnista, jonkun prosessin tekemisestä näkyväksi ja usein vain saadaan ruudut vilkkumaan. Joskus nämä ovat järjettömiä, joskus todella hienoja. Näitäkin pitää olla, koska ne tarjoavat uuden tavan lähestyä vanhoja rakenteita. Ja usein näillä on vahva markkinoinnillinen arvo. Lisäksi, organisaatio, jonka uudistuminen junnaa tarvitsee vähintään pari tällaista, jotta syntyy jotain uutta. Riskinhallinnan kannalta ehostus on ongelmallinen. Rahaa palaa ja todennäköisesti sitä ei saa takaisin. Ainakaan heti.

3. Uuden luominen

Digitalisoinnin jaloin muoto ei oikeastaan ole digitalisointia. Se on koko liiketoiminnan uudelleenluominen, käyttäen teknologiaa vahvana vipuvartena. Ei siis digitalisoida vanhaa prosessia. Vaikka useat väittävät toisin, korostuu tässä nörttien rooli (kts. ps2). Nörtit eivät yleensä ymmärrä vanhaa liiketoimintamallia. Varsinkin, jos se perustuu aikansa eläneisiin uskomuksiin.

Ikävä kyllä usein näissä unohtuu se, että kun idea on valmis tarvitsee se myydä ja markkinoida. Keinolla tai toisella. Tätä ei yleensä saa tehtyä yksin. Tiimissä on oltava hyvä sekoitus myynnillistä, markkinoinnin ja teknistä ymmärrystä. Epäonnistuminen on melkein varmaa jos joku näistä puuttuu. Se, että asiakkaat haluavat maksaa palvelusta on lopullinen testi idealle. Jos eivät, on idea susi.

Riskinhallinnan kannalta uuden luominen on kaikista vaikein. Onnistuminen voi olla todella komeaa ja epäonnistuminen vielä komeampaa. Välimuotoja tapaa harvoin. Forbesin mukaan 90% startupeista epäonnistuu. Todennäköisesti enemmän.

Digitalisaatiota pitää uskaltaa johtaa

Oma kokemukseni on, että liiketoiminnan kehittäminen kulkee useimmiten polkua jossa aluksi tehostetaan ja ehostetaan ja sitten (ainakin yritetään) luoda liiketoiminta uudelleen. Klassinen liikkeenjohto ei ole parhaimmillaan uuden luomisessa ja siksi nämä lähdöt tulevat usein perinteisten yrityksien ulkopuolelta. Jo senkin takia, että uuden luominen kannibalisoi vanhan. Tyhjän päälle astuminen pelottaa. Eri muodot eivät kuitenkaan ole ristiriidassa keskenään. Isompi yritys tarvitsee uudistuakseen kaikkia näitä. Ja työtä pitää johtaa. Varsinkin, jos kaikki ei suju kuin elokuvissa.

Digitalisaatio edellyttää uudenlaista johtamista. Innovatiivisuus, riskien järkevä hallitseminen ja erilaisuuden hyväksyminen ovat asioita, jotka ei vaan onnistu kaikilta.

Kaikki palaa erilaisten yksilöiden muodostamaan tiimiin

Lopuksi vielä tärkeä juttu. Tarvitset tiimin, jossa on erilaisia ihmisiä. Sinulla pitää olla pedantteja tehostajia, introverttejä nörttejä, innostavia viestijöitä ja lopuksi muutama puolihullu, jotka kiistävät kaiken olemassaolevan ja, jos onni on myötä keksivät sen uudelleen.

Jos ympäröit itsesi muoviklooneilla saat aikaiseksi korkeintaan keskinkertaista, jos sitäkään. Onnistuminen edellyttää erilaisten ideoiden hyvää synteesiä. Ja tehokasta toteutusta. Onnistumista ei ole ilman intohimoa uudistua.

Villakoira?

  1. Älä jää odottamaan ideaa joka ‘muuttaa kaiken’, pienikin askel vie eteenpäin
  2. Muista mitata onnistumista. Mittaamalla saat välineen johtaa. Muista eurot.
  3. Jos homma ei rokkaa reagoi nopeasti. Hyvän kuuloinen idea voi olla oikeasti susi, eikä sudet yleensä parane vanhetessaan.
  4. Onnistuvassa tiimissä on erilaisia ihmisiä. Älä potki päähän tarkkoja tuunaajia. Arvosta nörttiä. Älä järkyty kun liehuva liekinvarsi kertoo sinulle että kaikki aikaisempi on roskaa ja hänellä on aivan uusi idea.

Lopuksi : Eurot on todella hyvä keino mitata liiketoiminnan onnistumista. Monetisaatio on kuningas. Aina. No money, no honey.

Näihin kuviin ja tunnelmiin, iloista ja uudistavaa kesää.

ps1 : kaiken digitalisoinnin voi sössiä komeasti, jos sinulla ei ole riittävän vankkaa teknistä pohjaa.

ps2 : Nörttien roolista asiassa voi kiistellä pitkään, jätän se johonkin toiseen kertaan, mutta sitä odottaessa voit googlata vaikka seuraavia nimiä : Mark Zuckerberg, Sergey Brin, Bill Gates, Sir Tim Berners-Lee, Ralph H. Baer, Bram Cohen, Shawn Fanning, Linus Torvalds ja satoja muita. Tuo joukko on tuhonnut enemmän vanhoja yritysrakenteita kuin useimmat sodat. Vaikkapa Shawn Fanning, joka loi Napsterin, hänen aloittamansa kehitys murskasi lopulta fyysisiin levyihin ja kasetteihin perustuvan musiikkiteollisuuden ja pakotti toimialan uudistumaan. Kaveri ei tehnyt itse kaikkea, mutta potkaisi ensimmäisen pallon kentälle. Muut pelasivat eteenpäin. Btw – uuden luomisen yleensä tunnistaa siitä, että lopputuloksena on iso liuta käräjäkäyntejä, kun vanhojen liiketoimintamallien omistajat hirttäytyvät historiaansa. Oikeasti me nörtit johdetaan salaa maailmaa. Te ette vain tiedä sitä.

{ Add a Comment }

ProjektiNatsi kuolee yksin

Edellinen kirjoitus käsitteli Velttoa projektipäällikköä (VPP). Tämän oman elämänsä sankarin vastakohta on ProjektiNatsi (PN). Jos VPP:n ongelma oli epämääräinen ja löysä toiminta on PN toista puuta. Ihan oikeasti. Yllättävää kyllä kumpikin on saman ongelman äärellä…

Olen hyvin tietoinen siitä, että tämä kirjoitus on vähän turhankin synkkä. Mielestäni se on kuitenkin tarpeen siksi, että olen urani aikana nähnyt useita loppuunpalamisia. Toimin kauan sitten projektiauditoijana. Joka yleensä kutsuttiin paikalle kun onnettomuus on sattunut, rauniot savuavat ja ihmisiä kärrätään pois paikalta. Ennen näitä projektikolareita oli aika paljon, nykyään vähemmän. Ne ehkä saavat enemmän julkisuutta. Erikoista on se, että aiheesta ei ole pahemmin kirjoitettu.

Kaikki ei mene kuin elokuvissa

On tärkeää tunnustaa avoimesti se, että IT-projektitoiminta on vaativaa ja joskus raskasta. Jos kaikki projektit menisivät kuin Strömsössä ei tätäkään kirjoitusta tarvittaisi.

ProjektiNatseja näkee aika usein nuorissa projektipäälliköissä. Ikä tuo tässä asiassa viisautta ja Siperia opettaa.  PN:n tunnistaminen on helppoa. Hän aiheuttaa ahdistusta. Projektipäällikön pitää tehtävässään saada tuloksia ja niitä ei synny jos projektiin osalliset eivät voi hyvin. Ahdistuksen aiheuttamiseen riittää ihan seuraavat temput:

  • Täydellinen piittaamattomuus ihmisen yksityiselämästä
  • Ihmisen esineellistäminen malliin ‘resurssini sairastui, mitä teen?’
  • Kiusaaminen järjettömillä raportointipyynnöillä
  • Absurdit venymisvaatimukset
  • Raportoinnin kaunistelu

Edelleenkin, asiakkaan kannalta projekti on onnistunut jos se toteuttaa tehtävänsä aikataulussaan ja sille varatuin resurssein. Olivat ne sitten rahaa tai tekijöitä. Mutta projektipäällikön (ja yrityksen) kannalta on vielä toinenkin ulottuvuus. Projektin pitää onnistua niin, että sen tekijät puhuvat toisillensa projektin jälkeenkin. Ja tätä PN:t eivät yleensä ymmärrä. He ajattelevat projektia yksittäisenä tapahtumana. Kun oikeasti sitä pitäisi ajatella jatkumona. Eli … projektipäällikön pitää menestyäkseen vetää projekti niin, että hän voi vetää sen jälkeen seuraavan projektin. Ja niiden asiantuntijoiden pitää pystyä työskentelemään vielä raskaan projektin jälkeen.

Ja tämän takia PN:t kuolevat yksin. He eivät nimittäin ymmärrä ihmisiä. He eivät ole kivoja kavereita.

Rohkeus ja ymmärrys

Projektipäällikön työ vaatii rohkeutta. PN:n ongelma on siinä, että hänellä on haaste edessään, joka vaatii ymmärrystä. Ja hän hyökkää haastetta kohti ajatellen että ongelmana ovat ne resurssit. Jolloin ratkaisu on ruoskia kaikki irti niistä. Ja esineellistämällä ihmisen resurssiksi saat voideltua omantunnon.

Ratkaisuja yleensä löytyy. Ja joskus yksi keinoista on jaksamisen venyttäminen. Mutta vain joskus, ja silloinkin oikein säännösteltynä.

Ja joskus pitää vaan kohdata haaste ja rehellisesti kertoa projektin ohjausryhmälle että meillä on ongelma, jota ei ratkaista ylittämällä inhimilliset rajat. Tässä kohden PN kohtaa VPP:n. ProjektiNatsi välttää ongelman rehellistä tunnustamista ja Veltto ei osaa sitä nähdä. Ongelma on sama. Pätevän tilannekuva ja sen ylläpitäminen auttaa huomaamaan ongelmat ajoissa. Ennenkuin kaikki on päreinä.

Ammattitaitoinen projektinjohto on nimenomaan työtä, jossa hyvän tilannekuvan avulla, tuntien projektin tavoitteet edetään systemaattisesti kohti maalia. Se on intohimoa onnistumisesta, rakkautta tavoitteisiin ja asiallista, kannustavaa johtamista. Ihan niinkuin kaikki muukin johtaminen.

Muutama pallo arkeesi

  • MUISTA että ne ‘resurssit’ ovat yleensä IHMISIÄ. HEILLÄ ON TUNTEET JA OMA ELÄMÄ. Prkl.
  • Projektipäällikön työ on esimiesrooli. Olet vastuussa projektin ihmisistä.
  • Ensimmäinen askel ongelman ratkaisuun on sen tunnustaminen
  • Rehellisyys, rehellisyys ja rehellisyys
  • Tarkka ja täsmällinen tilannekuva auttaa ymmärtämään

ps1 : Kuten lähes kaikki tuttuni tietävät minulla on fiksaatio ‘resurssi’-sanaan. En voi sietää sitä, että ihmistä kutsutaan resurssiksi. Sanakirjan mukaan resurssi voi olla muutakin. Vaikka työstökone. Älä kutsu ihmistä työstökoneeksi. You have been warned.

ps2 : jep. Näitäkin on ohjattu ulos projekteista. Tee vain sellaista työtä, josta olet ylpeä. Jos tilanne vaatii, suojele ihmisiä.

{ 4 Comments }

Tietohallintoa vessaviisaudella

Katrin-2-wMuutama vuosi sitten silmään osui wc-paperiteline, jossa luki Katrin “Less is More”. Nopeasti ajatellen tuo tuntuu samanlaiselta heitolta kuin tyypillinen postaus Linkedinissä. Eli otetaan jonkun ajatuksen tiivistys, teipataan se valokuvan päälle ja julkaistaan. Sitten se pyörii ruudussa muutaman kuukauden ja iso joukko ihmisiä peukuttaa sitä. Minäkin olisin voinut julkaista kuvan vessasta.

Todistus

Tässä on enemmän. Tässä on kyseessä oikeasti suuri viisaus, nimenomaan tietotekniikan ja digitalisoinnin johtamisessa. Viimeisimässä McKinsey on Business Technology-lehdessä (36-2014) oli artikkeli ’How winning banks refocus their IT budgets for digital’. Siinä vertailtiin pankkeja käyttäen IT-budjetteja, panostuksia eri alueisiin ja näistä syntyneitä tuloksia.  Näitä oli verrattu toisiinsa ja rakennettu malli, jossa palveluissaan onnistuneet pankit oli peilattu siihen miten ne käyttävät IT:tä. Sekä haettu näiden välisiä selittäviä tekijöitä.

Tulokset olivat täsmälleen vessaviisauden mukaisia. Digitalisoinnissaan tehokkaat, onnistuneet pankit käyttivät tietotekniikkapalvelujen tuottamiseen vähemmän resursseja. Ja vastaavasti huonommin onnistuneet pankit käyttivät enemmän resursseja. ‘IT-tehokkaat’ pankit saivat myös aikaisemmaksi korkeamman kate%:n. Ero oli 53% verrattuna tehottomien 26% katteeseen. Huonosti menestyvät pankit kuluttivat IT-operaatioihin (day-to-day) 17% kokonaiskustannuksista. Ja hyvin menestyvät kuluttivat 10%. Pankeista puhuttaessa tämä on aika paljon rahaa.

Ja se varsinainen pihvi oli siinä, että selittäväksi tekijöiksi oli löydetty seuraavat toiminnalliset panostukset:

  • Tiukka kustannuskuri
  • Hankinnan kyvykkyys
  • Standardointi

Ei siis perinteinen ‘meillä on enemmän leluja kuin teillä’-kilpailu. Itseasiassa artikkeli täysin vastoin yleistä digiviisautta toteaa, että esimerkiksi panostukset monikanavaiseen integraatioon ja asiakasdialogin kehittämiseen eivät juurikaan tuota. Aivan hulvattomaksi artikkelin tekee se, että siinä todettiin vähemmän vaikuttaviksi tekijöiksi seuraavat kyvykkyydet:

  • Testauksen automatisointi
  • Formalisoitu prosessi liiketoiminnan kanssa työskentelyyn
  • Liiketoiminnan tarpeiden dokumentointi

Näihin tehdyt panostukset eivät korreloi varsinkaan sovelluskehityksen kustannuksiin. Ymmärrän, että osalle IT-teollisuuden väkeä tämä saattaa synnyttää ristiriitaisia tunteita. Jos haluat kinata asiasta kannattaa se tehdä McKinseyn tutkimustiimin kanssa, minäkin ihmettelin muutamaa artikkelin havaintoa.

Reaalimaailma

Kaikkea tätä voisi selittää monella tavalla, mutta ehkä yksinkertaisin selitys voisi olla, että normaali maalaisjärki auttaa monessa asiassa. Formaalit prosessit ovat välttämättömiä toiminnan sujuvoittamiseksi. Monimuotoiset palvelut ovat tärkeitä. Mutta mikään näistä ei tee kesää. Formaalien prosessien iso ongelma on se, että niiden ympärille pesiytyy uskovaisia, jotka saarnaavat niiden ratkaisevan kaikki ongelmat. Jep, mutta se ongelma vaan on jossain muualla.

Viisaus

Lopultakin kaikki palaa siihen, että tekemällä ne tärkeät asiat hyvin ja jättämällä vähemmän tärkeät tekemättä saat enemmän aikaan. Se tärkein taito on valita ne merkitykselliset asiat. Sitä kutsutaan joskus priorisoinniksi.  Senkin voi sössiä helposti jos kuluttaa aikaa priorisointiin enemmän kun tekemiseen. Yksi suurimmista viisauksista on myös sekin, että tekemätön päätös on myös päätös. Se on päätös hyväksyä nykytila, olla etenemättä. Aika on ainoa täydellisen rajallinen luonnonvara. Ajan varastoa ei ole.

Asiakas on aina kingi. Ne tärkeät palvelut ovat sellaisia, että niillä on merkitystä asiakkaalle. Ja silloin niillä on merkitystä liiketoiminnalle. Ja se on ainoa millä on merkitystä. Ihan oikeasti. CIO ei saa harrastaa IT:tä, hänen pitää rakastaa liiketoimintaa.

Artikkeli loppuu lakonisesti ’To meet IT budget pressures, CIOs have many opportunities to fund investments by cutting the costs of day-to-day operations and application development’. Aika hyvin sanottu.

Muutama pallo päiväsi parantamiseksi

  • Keskity liiketoiminnan kannalta olennaiseen
  • Tee tärkeät asiat valmiiksi
  • Älä hajota keskittymistä merkityksettömillä asioilla
  • Less is more. Really.

Ja käy vessasssa. Se on opettavaista ja terveellistä.

Ps1: Artikkeli listaa ison joukon tuottoisia investointikohteita, niitä voit lukea varsinaisesta jutusta.

{ 1 Comment }

Rakkaus ja CIO

Kevät on aikaa rakkauden. On siis hyvä hetki kirjoittaa muutama sana rakkaudesta. Ja nimenomaan CIO:n rakkaudesta. Tuntuuko ristiriitaiselta? Eikös se ollut niin, että CIO on se ’IT-hemmo jonka rakastaa tietotekniikkaa’. Tämä on aika jännä ajatus. Miksi CIO:n pitäisi rakastaa tietotekniikkaa? Kokeile joskus työssäsi sanoa ääneen, että et rakasta tietotekniikkaa…

Olen käynyt tästä aika monta keskustelua ja yleensä juttu menee niin, että ’kun sä teet IT-juttuja niin kai sun pitää rakastaa IT-juttuja’. Tämä analogia on suunnilleen samaa tasoa kuin ’CFO tekee numeroita joten CFO varmaan rakastaa exceliä’. Tai ’Sihteeri tekee kalenterivarauksen joten hän varmaan rakastaa kalenteriansa’. On ihan oikeasti omituista ajatella, että lankkumaalari rakastaa lankkujen maalaamista niin, että tekee sitä varmasti vapaa-ajallaankin.

Väitän, että CIO:n kuuluu vihata tietotekniikkaa. Tai vähintään suhde pitää olla platoninen. CIO:n keskeisimmät tehtävät ovat:

  1. pitää huoli, että tietotekniikkaan nojaavat prosessit toimivat riittävän hyvin.
  2. pitää huoli, että tietotekniikan kustannukset ovat mahdollisimman alhaiset.
  3. pitää huoli, että erilaisten käyttäjien tarpeet tulevat toteutettua niin että edelliset toteutuvat.
  4. pitää huoli, että tietotekniikka on renki. Ei isäntä.

Avainsanat tässä ovat riittävän & mahdollisimman. Kaikki turha on tarpeetonta. Asiat, jotka eivät toteuta yrityksen strategisia tavoitteita ovat tarpeettomia. Niitä ei saa olla, eikä niitä saa tehdä. Ja ne eivät saa maksaa senttiäkään.

Tämä ei ole kuitenkaan niin yksioikoista kuin edellä lukee. CIO:n kuuluu myös olla intohimoisen kiinnostunut asioista, jotka mahdollistavat uusia asioita. Ja olla palavan innostunut siitä, miten näitä voitaisiin hyödyntää. Mutta CIO ei saa ikinä, milloinkaan, koskaan ryhtyä jonkun tekniikan / menetelmän / toimittajan / välineen matkasaarnaajaksi. Ja tästä tulee se, ettei CIO saa koskaan rakastua tietotekniikkaan.

  • CIO:n kuuluu rakastua tyytyväisiin palvelujen käyttäjiin.
  • CIO:n pitää innostua ratkaisusta, joka toteuttaa yrityksen strategiset tavoitteet entistä paremmin.
  • CIO:n pitää saada hurjia viboja siitä, että liiketoiminta ylittää tavoitteensa.
  • CIO:n kuuluu haltioitua siitä, että toiminta uusiutuu ja kehittyy

Ja kaikki tämä korostuu jos liiketoiminta on tietointensiivistä. Jolloin tietotekniikka voi mahdollistaa sellaisia asioita, jotka muuten eivät olisi mahdollisia.

Muutama teesi CIO:lle vuoden aluksi:

  1. Tietotekniikka pitää olla renki, ei isäntä
  2. Teknologia mahdollistaa (joskus) muutoksen
  3. Muutos syntyy johtamalla toimintaa, hyödyntäen (joskus) tietotekniikkaa
  4. Pyri aktiivisesti hävittämään kaikki turha, kallis ja tarpeeton tietotekninen puuhastelu.
  5. Rakasta työtäsi, vihaa (turhaa) tietotekniikkaa

{ Add a Comment }

Ja mikä olikaan projektisi rasvaprosentti?

Näin vapun kunniaksi voisi paneutua työn jakautumiseen järkevästi. Tarkemmin projektin johtamiseen ja siihen liittyvään tekemisen & johtamisen jakautumiseen. Oletko koskaan ihmetellyt, mitä kaikki projektin johtoryhmässä olevat ihmiset tekevät? Tai miksi?

Kävelet tavallisen projektin tavalliseen johtoryhmään. Tavallisesti tupa on täynnä. On toimittajan projektipäällikkö, hänen esimiehensä, salkkuvastaava, laatuvastaava, myyjä ja hyvällä tuurilla vielä erillinen account manager ja hänen kaverinaan joku soveltuva Suuri Johtaja. Asiakkaan puolelta on myös väkeä. Yleensä vähemmän.

Sitten mennään projektin sisällön läpikäyntiin. Yleensä yksi puhuu ja loput haaveilevat. Jostain. Projektipäällikkö kertoo, että miten se onneton ihminen Krakovassa on sairastunut. Ja että projektin tilanne on epäselvä koska tekijä saikuttaa.

Jos vaikka tässä kohdassa pysähdyttäisiin ja kysyttäisiin, että ’mitä te täällä teette?’. Useimmat eivät osaa vastata. Osa sanoo jotain siihen malliin, että ’haluan seurata projektia jotta voin arvioida… jotain’. Tai sitten selittää jotain epäselvää tyyliin ’mä tässä manageroin’. Osa rehellisesti sanoo, että ei ole hajuakaan.

Useimmiten tilanne on juuri näin. Projektit ovat nykyään aika pieniä, siis tekijämielessä. Ja projektien johtaminen on aika isoa. Koska ’niin vaan kuuluu toimia’. Tai sitten ’menetelmämme edellyttää’. Tai ’raportoimme johdolle’.

Tämä on ongelma

Asian havainnollistamiseksi voisi soveltaa jo pahasti kulunutta käsitettä organisaatioläski ja laskea projektille sen rasvaprosentti. Se on hulvattoman helppoa ja tapahtuu seuraavasti. Laske ne nupit jotka osallistuvat projektin johtamiseen. Käytännössä vaikkapa johtoryhmän jäsenet. Ja sitten laske ne nupit jotka tekevät sen oikean työn. Näiden suhteesta syntyy projektin rasvaprosentti. Jossa läskiä ovat ne ihmiset jotka ’johtavat’ projektia ja lihasta on he jotka tekevät projektin varsinaisen sisällön. Kuten ihmisilläkin rasvaprosentti ei saa olla liian suuri. Hyvä on jossain 15-20% tienoilla. Projektille se pitäisi olla vielä pienempi.

Miksi?

Minä en asiakkaana ole kiinnostunut siitä, miten projektia ’manageroidaan’. Kunhan lopputulos ja keinot ovat odotusten mukaiset. Onnellisuuteni ei kasva jos projektia johtaa yhden sijasta viisi ihmistä. Jos projektin rasvaprosentti on korkea kertoo se siitä, että ketju tavoitteen ja tekijän välillä on pitkä. Ja että projekti on yliorganisoitu. Ja että se maksaa liikaa.

Kaikki ylimitoitettu johtaminen kuluttaa voimavaroja. Tarkoittaen sitä, että yksikin tarpeeton raportointia vaativa ihminen ylikuormittaa työtä tekeviä ihmisiä. Ja jos näitä parasiitteja on riittävästi tarvitaan lisäksi ihminen tekemään pelkästään niitä raportteja. Koneisto ruokkii siis itseään. Johtamisen määrällä ja tuloksilla on tietyn rajan jälkeen käänteinen korrelaatio.

Korkea rasvaprosentti kääntää perinteisen organisaatiopyramidin väärin päin. ’Manageeraajia’ on enemmän kuin tekijöitä. Tähän ei kannata sotkea sitä, että projektia ihan oikeasti pitää johtaa. Kyseessä on tilanne jossa sitä ylijohdetaan ja roolit & vastuut ovat menneet sekaisin.

Ihmiset sen työn tekevät, eivät organisaatiot tai prosessit

Olen nähnyt tilanteita joissa puolikkaan ihmisen työpanosta on pohtimassa kahdeksan johtajaa. Tässä ei todellakaan ole mitään järkeä. Lisäksi yliohjaaminen loukkaa, ihan sananmukaisesti, tekijöitä. Jokainen tekijä tietää, että se työ, jonka he tekevät maksaa myös näiden kuhnureiden palkan. Kannattaa avoimesti tunnustaa, että usein kehittäjät ovat organisaatiosi fiksuimpia ihmisiä. He kyllä näkevät ‘resurssit ovat organisaatiomme tärkein voimavara’-huuhaan läpi vaikka itse siihen uskoisit.

Juttelin erään konsulttiyhtiön maajohtajan kanssa. Hän kertoi, että he olivat laskeneet, että heidän menetelmillään ei kannata käynnistää projekteja ellei niissä ole vähintään 10 tekijää. Muuten rasvaprosentti kasvaa liian suureksi. Jo siksikin pienemmissä projekteissa kannattaa käyttää pienempiä taloja jotka eivät vielä ole kangistuneet -60-luvun projektimalleihin. Itseasiassa kaikkien projektitalojen kannattaisi laskea, että mikä on heidän minimiprojektin koko ja kustannus. Tarkoittaen siis sitä, että jos menetelmät ja organistointi edellyttää tiettyä prosessia saa siitä helposti laskettua mikä on pienin mahdollinen projektikustannus. Erittäin opettavainen harjoitus…

Projekti on väliaikainen organisaatio jolla on määritelty tavoite ja keinot päästä niihin. Projektista ei saa tehdä byrokratiamyllyä ja unohtaa miksi se on olemassa.

Bottomline

Asiakasta kiinnostavat tulokset. Ei se, kuinka monta ihmistä kuluttaa aikaansa kokouksissa. Johtamisen määrä ei yleensä korreloi laatuun. Saatikka tehokkuuteen. Mennessäsi seuraavaan projektin johtoryhmään laske sille rasvaprosentti ja ohjaa tarpeettomat ihmiset ulos huoneesta. Nyt on hyvä hetki saada projektisi rantakuntoon, onhan kesäkin tulossa. Rasvaa voi polttaa kuntoilemalla.

Ja käytä sitä maalaisjärkeä.

jk. Tämä on ensimmäinen kirjoitus projektitoiminnasta. Jatkoa on tulossa, kannattaa painaa oikealla olevaa subscribe-nappulaa jos haluat kuulla seuraavista episodeista. Seuraavaksi voisi paneutua vaikkapa velton projektipäällikön toimintaan .. vai olisiko kiinnostavampaa keinot tunnistaa valennörtit? Entäpä …

{ Add a Comment }

Tietotekniikka muuttaa liiketoimintasi?

Miksi fiksutkin ihmiset vaikuttavat joskus … ei niin fiksuilta? Pohdin tätä eräänä päivänä kuunnellessani esityksiä eräässä seminaarissa. Tarina meni sitä tavallista rataa, ’Meille tulee tämä CRM-järjestelmä ja sen myötä myyntimme räjähtää’ ja ’meille tulee OLAP-raportointityökalu joka antaa meille ymmärryksen liiketoiminnasta’. Aivan kuin järjestelmällä olisi näissä mitään tekemistä.  Esittäjät kertoivat, että ’odottelemme sitä ja tätä ja sitten aurinko nousee ja kesä tulee’. Ei muuten tule. Jos odotat, että IT muuttaa liiketoimintasi sataa räntää vielä juhannuksena.

Otetaan pari faktaa vasaroista

  1. vasara on työkalu
  2. kun sen laittaa maahan ei se rakenna taloa
  3. vaikka vetäisit ripaskaa vieressä

Laudoista

Otetaanpa laajempi versio noista edellisistä faktoista:

  1. jep, se vasara tarvitaan
  2. mutta tarvitset myös piirustukset siitä, mihin ajattelit sitä käyttää
  3. ja lautoja & nauloja
  4. sen lisäksi sinun pitää osata käyttää sitä vasaraa sekä myös lukea niitä piirustuksia
  5. sitten tarvitaan naulaamista, mielellään osuvaa, muuten sattuu ja kovasti
  6. ja sitten katsoa sitä mihin tuli iskettyä ne naula

Tietotekniikasta

Sovelletaanpa tätä yrityksen sisäisin tietojärjestelmäprojekteihin:

  1. Kaiken aloittaa tarve muutokseen ja sen tavoitteet
  2. Sitten tarvitaan jonkinasteinen prosessi jonka mukaan toimitaan
  3. jep, se järjestelmä saatetaan tarvita
  4. Perustiedot ja lähtöaineistot pitää olla kohdallaan
  5. Ja sitten olisi aika hyvä jos käyttäjät osaisivat käyttää järjestelmää
  6. sitten kovaa pauketta
  7. tuloksien mittaamista ja reagointia niiden perusteella

Kaikkea tätä ohjaa johtaminen. Se on kaikista tärkeintä muutoksen tavoittelemisessa. Enkä tarkoita tässä naivia ajatusta siitä, että johdon pitää sitoutua järjestelmään. Järjestelmiä ei saa rakentaa jos niillä ei ole käyttötarkoitusta. Kukaan ei ole niin hullu että sitoutuisi tarpeettomaan järjestelmään.

Muutos?

Halutessasi muutoksen on järjestelmä vain työkalu. Se varsinainen muutos lähtee johtamisesta. Toimintaa pitää johtaa tuloksellisesti kohti niitä tavoitteita joita organisaatiolla on. Työkalut ovat työkaluja, organisaation voima on ihmiset.

Siis haluat muutosta? Ihan simppelisti, vaikkapa haluat automatisoida jonkun prosessin, tai vaikkapa tehostaa varastonhallintaa. Koko homma lähtee siitä, että sinun pitää tietää mitä haluat. Ihan ensimmäisenä aseta ne tavoitteet.  Ja jos et osaa asettaa liiketoiminnallisia tavoitteita niin sitten unohda koko juttu.

Tavoitteiden jälkeen olisi hyvä keksiä ne keinot miten niihin päästään. Tarkoitan siis tavoitetilan prosessia ja niitä askelia joilla siihen tavoitetilaan päästään. Samalla määritetään ne tahot jotka prosessissa toimivat. Ja ne joukot jotka sitä prosessia johtavat sekä tukevat.

Vasta nyt aloitetaan sen järjestelmän pohtiminen. Ja tässä vaiheessa alkaa se IT-projekti ja homma menee normisti eteenpäin. Olettaen, että et aja projektia seinään ’tarpeellisilla’ muutoksilla. Kannattaa yleensä tavoitella yhtä juttua kerrallaan. Lisäksi järjestelmän pitää toimia riittävän hyvin jotteivat käyttäjät voisi pahoin sitä käyttäessään.

Sitten alkaa se vaikea osuus. Se uusi prosessi otetaan käyttöön ja parempi olisi että se toimisi. Myös se järjestelmä. Tästä eteenpäin ainoa mikä merkitsee on toiminnan johtaminen.  Ja mittaaminen. Ja johtaminen. Ja mittaaminen.  Ja vasta nyt ollaan siinä muutoksessa. Kaikki ennen tätä on ollut jotain muuta.

Bottomline

On perverssiä sanoa että tietotekniikka itsessään tekisi muutoksen. Tietotekniikka mahdollistaa asioita, mutta johtaminen tekee sen muutoksen. Sinun pitää tietää mitä haluat, ihan konkreettisesti. Turha luulla että löydät perille jos et tiedä minne olet menossa.

Vielä yksi juttu : paras muutos on sellainen jonka saa aikaiseksi ilman tietojärjestelmää.

ps : IT-alalla toimivat ihmiset eivät yleensä tunne talojen rakentamista ja vasaroita. Mäpäs olen rakentanut 2+ taloa, tunnen vasarat 🙂

{ 3 Comments }

Osa 2. Prosesseihin sitouttaminen on ….

Ensinnäkin, kiitokset kaikille heille jotka kommentoivat kirjoitustani ihmisten sitouttamisesta. Palautteen määrä sai nöyräksi. Ja todisti väitteeni siitä, että IT-teollisuudella on opittavaa. Kuten edellisessä osassa väitin, ihmiset ovat älykkäitä ja osaavat vaatia. On aika kasaria olettaa, että ihmiset ovat vaan … käyttäjiä. Käyttäjät tekevät valintoja ja päätöksiä. Ja heitä pitää arvostaa. Jos et tätä usko tai ymmärrä niin ei se mitään. Muut ymmärtävät ja sinä voit muuttaa jurassic parkkiin, siellä on tilaa.

Kirjoituksessa keskityin käyttöliittymän merkitykseen käyttäjälle. Ja muutamissa kommenteissa kysyttiin prosessien merkitystä. Siis, palvelu/sovellus on osa prosessia. Väite joka minulle esitettiin on, että prosessiin sitouttaminen on jaloa, vaikka sovellus olisikin kökkö. Hmmm… Kiehtovaa, tätähän pitää pohtia.

Väitän, että sovelluksilla, palveluilla ja prosesseilla ei ole suuremmin eroa. Käyttäjät ovat fiksuja, jos kokonaisuus on kökkö niin se on kökkö. Se, että tavoitellaanko sillä korkeampia asioita ei juurikaan muuta tilannetta.

Ulkoilutetaanko vähän ajatuksia?

Tähän sopii historiallinen tarina. Kauan aikaa sitten minulla oli kunnia työskennellä suomalaisen IT-teollisuuden grand old manin, Esa Korvenmaan kanssa. Olimme ottamassa käyttöön uutta myyntiprosessia ja CRM-järjestelmää. Esa ällistytti kaikki toteamalla että prosessidokumentaatio on sitten salainen, eikä sitä näytetä myyjille. Ei siis paperilla, tiedostona eikä Intrassa. Erittäin tiivis viestinnällinen peruspaketti kylläkin, mutta varsinainen dokumentaatio pidettiin piilossa.

Aika erikoista?

Jep, niinpä. Minulla kesti muutaman hetken ennenkuin ymmärsin perustelut. Jos prosessidokumentaatio jaetaan:

  1. Saavat organisaation kyynikot siitä keppihevosen jolla perustelevat sen jättämisen noudattamatta
  2. Ja ne, jotka muutenkin toimivat ’kiltisti’ kahlaavat prosessipaperit läpi ja tuhertavat niiden kanssa loputtomiin

Eli pitämällä prosessipahvit kaapissa pakotetaan käyttäjät toimimaan sen varassa mikä on näkyvää. ts. noudattamaan järjestelmää joka ohjaa prosessin mukaiseen toimintaan. Eikä puuttumaan prosessipapereihin. Ja idean toteutus pakottaa tekemään CRM:n sellaiseksi, että se toimii ohjaavasti.

Mikä on myyjälle olennaista? Kaupan saaminen. CRM on apuväline tiedon jakamiseen ja myyntikoneiston ohjaamiseen ja seurantaan.  Mutta vain apuväline. Prosessi ja sen jalkauttaminen on toissijaista, kauppa on ensisijaista. Aikuisten oikeasti, ei myyjää pidä kiinnostaa myyntiprosessi. Myyjän pitää innostua asiakkaan tapaamisesta ja liidien jalostamisesta kaupaksi. Jokainen paperi myyjän ja asiakkaan välissä on pahasta.

Esan idea on nerokas. Ja Esan tapa lähestyä ongelmaa on nerokas. Eli sen sijaan, että pähkitään sitä miten prosessi saadaan viestittyä rakennetaan koneisto niin ettei sitä tarvitse viestiä.

Kökköjen prosessien sitouttaminen on ….

Edelleenkin, aivan kuten palveluissa. Jos prosessi on kökkö on työntekijöiden sitouttaminen siihen kiusantekoa. Prosesseihin pätevät aivan samat lainalaisuudet kuin palveluihin. Kökkö on kökkö, eikä ihmisten suhtautuminen muutu mitenkään vaikka siihen leipoisi millaisen ’juurruttamisprojektin’ päälle. Paraskaan ’muutosvastarinnan käsittelymalli’ ei saa ihmistä ymmärtämään järkyttävää prosessia. Jos otetaan käyttöön kökköä prosessia tukevaa kökköä palvelua on lopputulos jotain … joskus sanat eivät riitä.

Joskus auttaa kun rehellisesti kertoo sen, miksi prosessissa on kömpelyyksiä. Vaikkapa, aiempaan matkalaskujärjestelmän prosessiin liittyen, kerrotaan rehellisesti työntekijöille, että verottaja edellyttää taksikuittiin kirjattavaksi että se on taksikuitti. Vaikka järjestelmä sen muutenkin tietäisi. Mutta silloin joku saattaa kysyä että miksi sama tieto pitää kirjoittaa useaan kertaan… Ja miksi käyttäjän pitää kirjoittaa?

Prosessien ja niitä tukevien palvelujen pitää tuottaa jotain, ei olla musta aukko johon organisaation ilo ja into toimia varsinaisen tavoitteen vuoksi uppoaa. Aivan sama idea kuin palvelutaseessa.

Muutama vinkki joilla pääsee pitkälle:

  • Kuuntele ihmisiä. He ovat fiksuja, heillä on usein hyviä ideoita
  • Ole rehellinen. Jos prosessiin on ihan pakko iskeä joku älyttömyys kerro ihmisille syy siihen.
  • Tee prosesseista mahdollisimman yksinkertaisia ja lyhyitä
  • Vältä sitä, että mallinnat prosessin organisaation kautta. Varsinkin sellaiset lauseet, joissa sanotaan ’tässä prosessi koukkaan sille-ja-sille, jotta he pysyvät tietoisina’ ovat ääliömäisiä
  • Jos teet virheen niin tunnusta ja korjaa se

Sanoinko jo, että kuuntele ihmisiä? Hyvä. Kuuntelua ei ole koskaan liikaa.

Bottomline

Käytä omia aivojasi. Ajattele itse ja käytä niitä korvia. Voit kuulla hyviä ideoita. Kököt prosessit ovat kökköjä prosesseja eikä ketään ei saisi sitouttaa tyhmyyteen. Prosesseissa korostuu se, että pitää keskittyä olennaiseen. Kaiken pitää palvella ihmistä, eikä koneistoa. Ja lopuksi – älä ole jotain ismiä toittovan konsultin keppihevonen.

Jk. Oletko koskaan ajatellut, että prosessin/palvelun suunnitteleminen ei saa lähteä siitä olettamasta että suunnittelija käyttää valta-asemaa työn tekijää kohtaan? Työn tekijä on prosessin ‘asiakas’. Asiakas on aina oikeassa. Aina.

{ Comments are closed }

Miten välttää ’johdon tuen hakemisen’ projektillesi? Ja miksi?

Eräs IT-teollisuuden ristiriitaisimpia ilmiöitä on käsite ’johdon tuen varmistaminen’. Tähän käsitteeseen törmää usein konsulttien puheenvuoroissa. Varsinkin jos esitellään jotain aloitetta jonka toivotaan menevän läpi päätöksenteossa ilman että sille on mitään näkyvää perustetta. Käsitteellä on myös toinen ilmenemismuoto, saada jotain ’johdon agendalle’. Käytännössä kummatkin käsitteet ovat osoitus siitä, että niitä käyttävät ihmiset eivät ymmärrä yritysmaailmaa ja sen lainalaisuuksia. Olen tähän kirjoitelmaan yksinkertaistanut kuviota jotta saisin siitä näkyväksi sen miksi on tärkeää välttää Johdon tuen hakemista.

Itse heräsin miettimään käsitteen omituisuutta istuessani kauan sitten raportointiratkaisuita käsittelleessä seminaarissa. Siellä oli esitys jossa pari konsulttia kertoi johdon raportointijärjestelmän rakentamisprojektista. Avaintehtävänä mainittiin kolme kertaa ’johdon sitoutumisen varmistaminen’. Siis hetkinen… johdon raportointijärjestelmään johdon sitoutuminen? Kuka ryhtyy tekemään johdon raportointijärjestelmää johdolle ilman että johto nimenomaisesti edellyttää sitä? Kenen aloitteesta projektia vietiin läpi?

Reaalimaailma

Yritykset koostuvat ihmisistä. Useimmiten joku näistä ihmisistä on Johtaja. Ja Johtajan tehtävä on johtaa. Johdon tuki ja sen hakeminen on ilmaisu, jota käytetään kun halutaan sanoa, että joku ei-johtaja haluaa johtajan tuen jollekin asialle, vaikkapa projektille. Lähtötilanne on ilmeisesti sellainen, jossa Johtaja ei tue projektia.

Niinpä

Jostain omituisesta syystä olen törmännyt toistuvasti tilanteisiin joissa hankkeita ajetaan läpi ja toisessa päässä johtoryhmässä pyritään prioirisoimaan niitä pois. Tilanne jossa kumpikin pääty pyrkii ohjaamaan toisiaan kertoo yrityksestä jossa on jotain kehitettävää.

Selvyyden vuoksi – tilanne jossa luova organisaatio kehittää uusia ratkaisuja ja käsittelee prosessin mukaisesti uusia ideoita on aivan toinen. Silloin koneisto toimii toivotulla tavalla.

Itse asiassa jo se, että johdon tukea varmistetaan vain IT-teollisuudessa pitäisi kertoa kaiken olennaisen. Oletko koskaan kuullut kiinteistön rakennusprojektista jossa varmistettaisiin johdon tuki? Eikö homma olisi paljon yksinkertaisempaa jos tehtäisiin vain projekteja joilla on merkitystä?

Oma lukunsa on järjestelmät tai palvelut joita rakennetaan jonkun osaston pönkittämiseksi. Nämä tuntee yleensä siitä, että jostain syystä käyttäjät eivät tunnu sitoutuvan niiden käyttöön. vrt. edellinen kirjoitus.

Älä koskaan hae johdon tukea, tärkeällä asialla on se jo

Oikeassa elämässä on tärkeää keskittyä asioihin joilla on merkitystä. Jos kohdallesi osuu hanke jonka kannessa sanotaan että ’sille pitää varmistaa johdon tuki’ on hanke todennäköisesti merkityksetön. Siispä on tavoitteellista välttää ’johdon tuen hakemista’. Merkittävä hanke, siis sellainen joka on tärkeä, on jo valmiiksi tärkeä. Tarve hankkeeseen on syntynyt Johdon toiminnan tuloksena, viimeistään vietäessä päätöksiä toimintaan.

Ja kääntäen, mikäli hankkeen etenemisen kuluessa tulee sellainen tunne, että ’Johto ei tue’ sinua mieti huolellisesti että onko hanke perusteltu. Ihan vakavissaan. Suuren sankarin paikka on vapaana sellaiselle ihmiselle jolla on rohkeutta ehdottaa oman hankkeensa lopettamista tarpeettomana. Tunnen erään konsulttijohtajan joka aloitti tuotepäällikkönä. Ensi töikseen esitti oman tuotteensa lakkauttamista. Hän oli kaikkien meidän muiden sankari (Jep, Panu – tiedät kyllä ketä tarkoitan…).

Kaikkein surkein on se tilanne jossa tapaat ihmisen joka kertoo että projekti epäonnistui koska johto ei häntä tukenut. Oliko vika sittenkään johdossa? Vai oliko projektissa, tavoitteissa, … tai sitten projektin vetäjässä?

Bottomline

Vältä sellaista asioiden tekemistä joilla ei ole merkitystä yrityksellesi. Ihan oikeasti, merkityksettömiä juttuja pitää väistää kuin ruttoa. Vältä kaikkea sellaista, jota joku, joka ei ymmärrä asiasta haluaa selittää tärkeäksi. Se ei yleensä ole tärkeää. Jos joku ehdottaa projektillesi ’johdon tuen varmistamista’ ehdota projektin peruuttamista. Se on useimmiten ainoa järkevä teko. Ja käytä sitä maalaisjärkeä. Jos et pysty itsellesi selittämään mikä on hankkeen liiketoimintahyöty jätä se väliin. Älä ole konsultin keppihevonen.

{ Comments are closed }

Käyttäjien sitouttaminen on sairasta

Kuluttajistuminen on vinkeä juttu. Se on tuonut keskusteluihin uusia asioita, kuten BYOD, BYOA jne. Keskusteluissa on kuitenkin keskitytty toissijaisiin juttuihin, kuten kännyköihin ja läppäreihin. Niitä tulee ja menee, ne eivät oikeasti ole kiinnostavia. Se mikä on ja pysyy on käsitteelliset omituisuudet. Ja tällä kertaa kommentoin käsitettä ’käyttäjien sitouttaminen’, puhuttaessa yritysohjelmistoista. Joku voi kysyä tässä kohden, että mitä yhteistä näillä asioilla on? Paljonkin.

Sitouttaminen?

Minua on pitkään vaivannut eräs IT-teollisuuden synkimmistä käsitteistä : käyttäjien sitouttaminen. Google löytää sille 541.000 osumaa. Joka on jonkinlainen saavutus, kun ajattelee mitä se tarkoittaa. Tämä käsite esiintyy usein käsitteiden muutosvastarinta ja käytön juurruttaminen yhteydessä. Olen sitä mieltä, että he, jotka käyttävät näitä käsitteitä ovat pahasti hakoteillä. Perustelen sen esittelemällä kätevän laskentamallin.

Asian hahmottamiseksi kannattaa ajatella seuraavalla tavalla. Otetaan mikä tahansa yritysohjelmisto. Vaikkapa matkalaskujärjestelmä. Kirjataan ylös ne asiat jotka aiheuttavat tuskaa. Vaikkapa ääliömäiset, ylimääräiset tunnus-salasana-viritelmät, hitaat vasteajat, monimutkaiset komennot, typerryttävä kolmeen kertaan kirjoitettava perustelu kuitille, järkyttävät klikkailuhelvetit jne. Kaikki se paha mikä sovelluksessa ahdistaa käyttäjiä. Ja toiselle puolelle kirjataan ne asiat jotka aiheuttavat iloa. Esimerkiksi työtä tehostavat toiminnot, nopea reagointi, tarpeettomien vaiheiden eliminointi, helppo käyttöliittymä ja niin edelleen. Ja matkalaskujärjestelmän tapauksessa tilille tuleva matkakorvaus.

Seuraavaksi arvotetaan sekä tuskan että ilon elementit vaikkapa asteikolla 1-5. Kummankin puolen elementit lasketaan yhteen ja lopulta otetaan ilo ja vähennetään siitä tuska. Tulokseksi saat palvelutaseen.

Tämä palvelutase on jännä numero. Jos se on positiivinen tarkoittaa se sitä, että palvelu tuottaa iloa käyttäjilleen. Se on miellyttävä, nopea, toimii tehokkaasti jne. Jos taas palvelutase on negatiivinen on palvelu sellainen että sen käyttäminen aiheuttaa enemmän tuskaa kuin iloa. Kaikille palveluille voi laskea tämän taseen.

Sitten paikalla tulee innostunut ihminen joka sanoo, että palvelu jonka palvelutase on negatiivinen toimii teknisesti hyvin ja käyttäjät eivät pidä siitä sen takia, että heitä ei ole sitoutettu palveluun. Tai että heillä on muutosvastarintaa. Tai että käyttöä ei ole aktivoitu…

Voi pyhä sylvi

Erittäin usein palvelut joista sanotaan, että niiden käyttäjillä on muutosvastarintaa ovat oikeasti kökköjä. Ne eivät yksinkertaisesti toimi, tai sitten ne toimivat niin huonosti että tekee kipeää käyttää niitä. Olen törmännyt jopa matkalaskujärjestelmään jonka käyttäjät ovat lopulta kieltäytyneet matkustamasta välttääkseen matkalaskun tekemistä. Ja ihan varmasti joku onneton on kirjoittanut suunnitelman sovelluksen ’käytön juurruttamisesta’.  Ihmiset käyttävät näitä sovelluksia vain (ja ainoastaan) koska se on pakko. Ja pakko on aina huono motivaattori. Ihminen joka ajaa käyttöön tuskaa tuottavia palveluita on pahan palveluksessa. Ihmisten sitouttaminen tuskaan on sairasta.

Yritykset jotka näitä kökköjä järjestelmiä rakentavat unohtavat yhden totuuden. Ihmiset ovat yleensä fiksuja. Jos muutosvastarintaa esiintyy on siihen syynsä. Jolloin pitäisi miettiä mikä on se oikea syy, eikä keskittyä nujertamaan ihmisten terveitä puolustusreaktiota.

Miten sitten kuluttajistuminen liittyy tähän?

Paljonkin. Verkko ja pilvi ovat aika tylsiä käsitteitä. Mutta niiden leviäminen laajalle yhteiskuntaan on tuonut koko joukon uusia palveluita käyttäjien käytettäväksi. Ja useat niistä ovat helppoja ja niiden käyttäminen tuo ihmisille jotain iloa. Sanotaan sitten vaikka, että niiden palvelutase on positiivinen. Otetaan vaikkapa esimerkiksi google, facebook, twitter jne. Tai sitten linkedin. Tai ääriesimerkkinä Angry Birds. Käytätkö sinä näitä palveluita koska sinut on ’sitoutettu niihin’?. Oletko esittänyt muutosvastarintaa Angry Birdsiin?  Alunperin kuluttajille suunnatut palvelut tulevat aivan varmasti leviämään yritysmaailmaan. Ja tärkeintä tässä on se, että niiden suunnitteluideologia leviää yrityksiin. Ideologia siitä, että palveluiden käyttö pitää olla niin palkitsevaa että niitä käytetään vapaaehtoisesti. Suosittelisin jatkossa miettimään kaikkien yrityssovelluksien ratkaisut niin, että käyttäjät haluavat käyttää niitä. Ja silloin se palvelutase on positiivinen. Tähän ilmiöön liittyy löyhästi käsite BYOA, mutta siitä joskus enemmän.

Verkossa tarjottavat palvelut joutuvat ihan oikeasti taistelemaan käyttäjiensä suosiosta. Ihan oikeasti 20  miljoonaa kärpästä on oikeassa, vaikka kyynikot muuta väittävät. Jos palvelusta pidetään on siinä jotain hyvää. Vapaaehtoinen käyttäjä on loistava mittari palvelun laadulle.

Bottomline

Aina kun kuulet käsitteen ’käyttäjien sitouttaminen’ poista varmistin. Jos sama puhuja kertoo sinulle muutosvastarinnan nujertamisesta mieti miten saat puhujan nujerrettua. Yleensäkin käytä omia aivojasi sekä maalaisjärkeä. Kyseenalaista asiat jotka ovat järjenvastaisia, älä usko ihmisiä jotka saavat kicksejä tuskan levittämisestä. Tule hyvän puolelle. Nykyään on jo vaihtoehtoja.

Jk. Lähiaikoina palaan tähän teemaan pureksimalla käsitettä ’johdon tuki’. Stay tuned tai paina subscribe-nappulaa oikeassa reunassa. (edit – kts. täältä)

Jk2. Eikö ole mielenkiintoista, että ‘hyvä käyttöliittymä‘ saa 199.000 osumaa ja ‘käyttäjien sitouttaminen‘ saa 541.000 osumaa. It makes you wonder…

Jk3. Tähän kirjoitelmaan on ilmestynyt jatko-osa: Prosesseihin sitouttaminen…

{ Comments are closed }

IT ei ole saari

Verkon mahdollistama muutos on ravistamassa yrityksiä tavalla jota ei ole aiemmin nähty. Se vaikuttaa kaikkiin tasoihin ja toimintoihin. Yhteiskunta on jo siirtynyt ‘verkko mahdollistaa’ ilmaisusta ‘asiakkaat edellyttävät’ maailmaan. Tällä kertaa kommentoin tapaa jolla muutos vaikuttaa IT:n rooliin yrityksessä. 

Kun seuraa alan kirjoittelua huomaa aika nopeasti että maailma on muuttunut ja useimmat yritykset toimivat aivan toisenlaisessa ympäristössä kuin, sanotaan vaikka 10v sitten. Aika ei ole olennainen, muutos on. Muutos liittyy tapaan jolla tyypillinen yritys kohtaa asiakkaansa. Asiakaskohtaaminen on nykyään yhä useammin sähköinen. Ja tästä ei varmaan tarvitse kirjoittaa, tämän tietävät kaikki.

Ne ajat jolloin tietotekniikka oli minikone salissa tai PC-verkko toimistossa ovat menneet. Ja entisenlainen tietohallinto mennyt sen mukana. Nykyään tietotekniikka on mukana kaikessa ja kaikkialla. Vähän niinkuin Elisan mainos muutama vuosi sitten. Jos puhutaan vähänkään isommasta yrityksestä ei asiakasrajapinta (tai muukaan) toimi minuuttiakaan ilman tietotekniikkaa. Asiakkaat vaativat aivan eri tavalla palveluita ja reagointia tarpeisiin. Ja jos et ole mukana et ole … mukana.

No, kaikki tämä kuullostaa tietotekniikan taitajien kannalta kivalta. Ainakin aluksi. Siis ihan oikeasti hienoa, vihdoinkin joku ymmärtää IT:n merkityksen. Ja … niin edelleen. Btw – olen henkilökohtaisesti täysin allerginen ilmaisuille ‘johdon tuki’, ‘ymmärtää IT:n merkityksen’ jne. Asiat joilla on merkitystä ovat tärkeitä. Piste. Ja tärkeille asioille on aina aikaa. Kaikki lauseet joissa kysytään ‘miten IT:n saa johdon agendalle’ saavat minut poistamaan varmistimen.

Joka tapauksessa sähköiset palvelukanavat ja prosessit ovat nostaneet tietotekniikan merkityksen aivan uudelle tasolle. Ja laskeneet organisaationa tietohallinnon merkityksen alemmas kuin koskaan aiemmin.

Täh? Mites tässä nyt näin kävi?

Tässä on se jännä ilmiö. Kun sähköiset kanavat ovat nykyään täysin välttämättömiä ovat ne muodostuneet yritykselle elämän ja kuoleman kysymykseksi. Jos sähköisen ajanvarauksen kautta tulee 50% asiakkaista on todella tärkeää että se toimii. Ja silloin sitä soppaa sekoittamaan ilmaantuu koko yrityksen väki.

Tietohallinnon monopoli katosi

Kuka vei tietohallinnon juuston? Lopulta kaikki on aivan johdonmukaista. Koska IT:llä on vihdoinkin ‘merkitystä’ osallistuvat kaikki säätämiseen. Kukin oman alueensa ja osaamisensa mukaan. Tämä on luonut aivan uuden maailman. Jossa:

  • Tietotekniikka ei enää ole Tietohallinnon omaisuutta
  • Tietotekniikkaa on kaikessa
  • Yritys joka tuottaa IT-perustaisia palveluita on IT-yritys
  • koko henkilökunta on töissä ‘Tietohallinnossa’

Pelottavaa, vai mitä? Tiesitkö sinä olevasi töissä ‘tietohallinnossa’? Et välttämättä halunnut sitä, mutta elämä on. Et ehkä ole töissä tietohallinnossa, mutta olet speksaamassa IT-juttuja.

Mutta ei tässä kaikki…

Kaikessa tässä on pieni pulma. Tyypillisen konttorinkuluttajan osaaminen tietotekniikasta ja sen nivomisesta palveluprosesseihin (kutsutaan sitä vaikka muoti-ilmaisulla palvelumuotoilu..) on aika kapeaa. Ja se näkyy. Useamman kerran olen päässyt näkemään aivan hämmentäviä sohlauksia. Varsinkin jos ihminen jonka työelämän parasta-ennen-leima on mennyt vanhaksi ryhtyy teutaroimaan sellaisten asioiden kanssa joista hänellä ei ole mitään hajuakaan. Epämukavuusalueelle meneminen aiheuttaa epävarmuutta jota kompensoidaan primitiivireaktioilla. Jokainen projekti kaipaa peukalonjäljen jättäjän. Todennäköisesti kaikki IT/DIGI-toimijat tuntevat tämän ilmiön.

Käytännössä ei ole reilua, eikä perusteltua vaatia kaikilta työntekijöiltä korkeaa osaamista. Mutta perustaso on pakko olla. Rekryperusteina pitää olla oman alueen osaamisen lisäksi perustiedot sähköisten palveluiden ja prosessien maailmasta. Eikä haittaa osata ihan konttoritekniikan perusjuttuja. Pari päivää sitten autoin jälleen yhden keski-ikäisen johtajan liittämään läppärin tykkiin. Jep…. joskus ne IT-jutut on vaikeita.

Ja aivan samalla tavalla tietohallinnon väen on osattava sen palvelumuotoilun perusteet sähköisten palvelujen perspektiivistä. Ja vähän enemmän.

Kaikki palaa kommunikointiin

Jotta homma rokkaisi tarvitaan yrityksessä ainakin pari juttua:

  1. Palveluiden kehittämisen, jakelun, myymisen ja markkinoinnin syvällistä osaamista
  2. Tietotekniikan syvällistä osaamista
  3. Em. joukkioiden on osattava kommunikoida keskenään

Tuo kommunikointi on se olennainen juttu. Auttaa jos kummallakin se perusymmärrys toisesta. Ja kommunikoinnin kautta ymmärretään ne yhteiset tavoitteet. Ja päästään niihin. Ei tämäkään juttu ole sen vaikeampaa. Kummankin osapuolen pitää osata toisen kieltä. On ihan aikuisten oikeasti tärkeää hankkia syvällistä osaamista, keskiarvo saa aikaiseksi keskiarvon. Tuntuu kivalta, mutta ikävä kyllä keskiarvolla päästään hyvälle pronssitilalle.

Bottomline

Älä palkkaa nörttiä joka ei osaa kertoa mitä tekee ja markkinointihemmoa joka ei osaa kytkeä tykkiä läppäriin. Ja kummankin pitää osata jutella kaverinsa kanssa. Käytä tässäkin maalaisjärkeä. Älä etsi keskiarvoa, etsi kovaa osaamista joka osaa kommunikoida.

{ Comments are closed }