Dancy’n lait

Chris Dancy on julkaissut sarjan ohjeita sosiaalisen median käytöstä. Ne eivät ole aivan helppolukuisia, mutta niissä on ajatusta. Alkuperäiset 11 ediktiä eli ukaasia löydät täältä.

Olen muokannut niistä oman tiivistelmän, tämä ei ole käännös vaan oma tulkintani.

1) Älä julkaise täsmälleen samaa materiaalia samassa muodossa eri kanavilla. Oman viestin toistaminen rasittaa niitä harvoja, jotka ovat sinusta kiinnostuneita. Tämä on hyvä ohje, mutta monet rikkovat sitä. (Minä myös, tämä juttu näkyy Pohjoisviitan sivuilla (WordPress), LinkedInissä ja vielä Pohjoisviitan Facebook-sivuilla.)

2) Seuraajasi ovat asiakkaitasi ja sinun pitää tuottaa kullekin kanavalle sille soveltuvaa huipputasoista materiaalia. Kanavat ovat erilaisia, opettele käyttämään niitä ja tuota kiinnostavaa tietoa, vältä tyhjää meluamista.

3) Sinulla ei ole yksityistä elämää, ala käyttää Facebookia. Facebook on osa elämää ja sen pelkääminen on turhaa. Facebook soveltuu monenlaiseen käyttöön.

4) LinkedIn on ammattilaisten verkko joten käyttäydy oikein ja ylläpidä tietojasi. Kun unelmiesi työpaikka aukeaa, sinut voidaan karsia LinkedIn-profiilisi perusteella, ilman että kukaan ottaa sinuun yhteyttä.

5) Sähköpostin käsittely ei ole taito, se on joillekin päätoimi. Sähköposti on vanhanaikainen ja tuottamaton työkalu. Lähetetty liite on kuollut, jaa enemmin linkki.

6) Mittaa itsesi. Sosiaalinen media antaa lukuisia keinoja oman toiminnan mittaamiseen, esimerkiksi Klout antaa jonkinlaisen käsityksen vaikuttavuudesta. Kaikkea toimintaa voi mitata ja dokumentoida. Jos jaat linkkejä, näet kuinka moni on avannut dokumentin.

7) Varo tarttuvaa tautia. Aina välillä sosiaalinen media näyttää vievän uhrinsa arvostelukyvyn. Uhri jakaa tietoa tolkutonta vauhtia saadakseen itse huomiota. Jaetun tiedon laatu voi olla surkea, riittää että siinä on kiehtova otsikko.

8) Keskustelu omista laitteista ja niiden vaaroista on harhaa, se juna meni jo. Ihmiset käyttävät mitä haluavat ja tieto siirtyy vaivatta pilveen.

9) Sosiaalisella medialla voi kontrolloida julkisuutta. Voit rajoittaa kuka näkee tietosi ja kuka pystyy ottamaan yhteyden sinuun.

10) Sinulla on digitaalinen persoona ja sinä et ole se. Sinä voit vaikuttaa siihen millainen sinä olet digitaalisessa maailmassa.

11) Onko sinusta tullut työnantajasi äänitorvi, toistatko kaiken mitä pomosi tai yrityksesi julkaisee? Varo ettei sinusta tule kävelevä mainostaulu, se syö uskottavuuttasi.

Startup onnistui

Flowdock myytiin USAan tällä viikolla. http://www.reuters.com/article/2013/02/13/co-rally-flowdock-idUSnPnLA59590+160+PRN20130213

Tässä vähän taustoja näin omalta kannaltani:

Poikani Mikael aloitti it-uransa koodaamalla HDI Nordicin ja Yhteys-konferenssin kotisivut. Matkan varrella asiakkaita tuli lisää. Muistan hyvin kun otin Mikaelin mukaan Yhteys-konferenssin johtoryhmän kokoukseen. Tarjolla oli Indatan käyttämä mainostoimisto, eli ammattilaiset ja sitten olisiko ollut 16v nörtti. Henki oli vähän että katsotaan nyt Aalen mieliksi, mutta kyllähän tämä on ammattilaisten puuhaa. Lopputulos oli se että Mikael sai Yhteys-konferenssin lisäksi Indatankin asiakkaakseen. Ammattilaiset olivat tehneet surkeat ja järjettömän hitaat sivut, Mikael taas salamana lataantuvat ja selkeät sivut.

Opiskelun lomassa Mikaelille tarjoutui mahdollisuus lähteä osakkaaksi perustamaan uutta it-firmaa. Kannustin poikaa lähtemään yrittäjäksi. Ajattelin että vaikka siinä menisi säästöt, niin kyllä yrittämisessä oppii niin paljon, että kannattaa kokeilla. Nodeta Oy tarjosi aluksi hostingia ja teki kotisivuja, mutta myi sitten sen liiketoiminnan pois ja siirtyi it-konsultiksi ja alihankkijaksi suomalaiselle it-talolle koodaamaan lähinnä www-käyttöliittymiä. Pohjoisviittakin oli asiakkaana, kunnes Mikael opasti minut käyttämään tätä WordPressiä.

Työn ohessa kaverit kehittivät itselleen ryhmätyövälineen, josta tuli Flowdock. Välineestä tuli hyvä ja lopulta he päättivät keskittyä siihen. Flowdock on ohjelmistokehittäjille tarkoitettu tiimityöskentelyväline, joka sai käyttäjiä ja kiinnosti sijoittajia. He saivat puolen miljoonan enkelisijoituksen ja pääsivät kehittämään työkalua päätoimisesti. Viime viikolla sitten Rally Software osti Flowdockin integroidakseen sen omiin tuotteisiinsa. Samalla Rally perusti yrityksen kehityskeskuksen Helsinkiin eli toiminta jatkuu täällä.

Aika hieno alku uralle, poika on vetänyt IT-yritystä, kehittänyt hyvän oman tuotteen, ollut neuvottelemassa rahoituksen ja sitten myymässä tuloksen USA:n ja jatkaa yrityksen tuoteryhmän johtajana. Kaikki tämä alle kolmekymmpisenä.

Palveluintegrointi

It-palvelu muodostuu palveluketjuista,  joissa eri organisaatiot yhdessä rakentavat lopullisen palvelun. Asiakkaat pelkäävät, ehkä aiheellisesti, yhden toimittajan armoille joutumista. Siksi suuret ulkoistukset pyritään pilkkomaan monille toimittajille ja sisäisen it:n tehtäväksi jää palvelujen yhteensovittaminen. Ulkoistuksessa on tavallista, että osa henkilöstöä siirtyy palveluntarjoajan leipiin ja jäljelle jää vain ”jäännös it”, joka valvoo ja ohjaa palvelun tuottajia. Tehtävä ei ole helppo ja monissa tapauksissa on havaittu, että ulkoistuksen jälkeen sisäisen it:n osaaminen ja resurssit eivät riitä tehtävään. Usein on päädytty rakentamaan sisäinen it ikään kuin uudestaan, tosin niin että sen tehtävät ovat erilaiset kuin lähtötilanteessa. Tämä prosessi on pitkällä Englannissa, jossa palvelujen ulkoistus lähti liikkeelle jo 80-luvulla. Siellä puhutaan jo kolmannen sukupolven ”jäännös it:stä, 3rd generation retained IT”.

Palvelumarkkinoilla syntyy helposti epätasainen asetelma. Suuriin palveluhankkeisiin kykenee vain rajallinen määrä toimijoita. Palvelun tuottajista tulee voimakkaita ja asiakkaat ovat alakynnessä. Palvelun tuottajilla on pieni määrä avainasiakkaita, joista pidetään kiinni. Erityisvaatimuksia esittävät pienet asiakkaat ovat häiriötekijöitä, joiden menetystä ei surra. Pulmaa voidaan ratkoa eri keinoin. Yksi tapa on hakeutua avainasiakkaaksi, eli löytää riittävän pieni palveluntarjoaja. Tässäkin on omat riskinsä. Toinen keino on ottaa palveluja takaisin sisään.  Kolmas keino on ostaa palveluintegrointi palveluna.

Palveluintegrointi eli Service Integration on eri asia kuin järjestelmäintegrointi eli Systems Integration, jossa eri järjestelmät laitetaan keskustelemaan keskenään. Palveluintegrointi tarkoittaa sitä että yksi osapuoli ottaa vastuulleen muiden palvelutuottajien palvelut. Tämä voi tuntua turhan monimutkaiselta, mutta samaa mallia käytetään kaikkialla. Yksi palvelun tuottaja myy lopputuloksen asiakkaalle ja hankkii tarvittavat alihankkijat tekemään työn.

Palveluintegrointi on melko uusi asia Suomessa. Googlauksen perusteella näyttää siltä, että ainoastaan Fujitsu on oivaltanut mistä on kyse. Malli on kuitenkin tulossa hyvää vauhtia Suomeen. Englannissa se on menestynyt ja tietoni perustuvatkin englantilaisten kollegoiden kokemuksiin. Yksi tärkeä peluri alalla on TCS, TATA Consulting Services, joka toimii myös Suomessa. Ilmeisesti myös muut intialaiset suuret palvelutalot ovat palveluintegroinnin edelläkävijöitä.

TCS:n mukaan termi on vielä epämääräinen, sillä voidaan tarkoittaa vain monitorointia, operationaalista valvontaa, palvelujen yhdistämistä jne. TCSn mukaan siinä on kuitenkin kyse syvemmästä yhteistyöstä, uudesta tavasta hallita it-palveluja. Tämä liittyy läheisesti äskeiseen SLA-keskusteluun. On tavallista, että it-yksikkö neuvottelee palvelun toimittajien kanssa tekniikkalähtöiset SLAt. Liiketoiminnan tarpeet jäävät helposti taustalle. Kerran neuvoteltu palvelusopimus voi olla pahimmillaan kehityksen jarru. Palveluintegroinnin tulee lähteä liiketoiminnan tarpeista, integraattorin tulee ymmärtää liiketoiminnan tavoitteet ja sen tulee kyetä tarjoamaan innovaatioita toiminnan kehittämiselle.

Äskeisessä tutkimuksessa tuli esille tyypillisiä ongelmia asiakas-toimittajasuhteissa:

Ulkoisen palveluntuottajan heikko laatu toiminnassaan; suunnattomasti virheitä, viesteihin ei vastata,  ei tehdä mitä sovitaan vaan tehdään ihan jotain muuta,….

Ei varsinaisesti mitään uutta. Palveluntarjoajien asiakkaalle näkyvät, jäsentymättömät prosessit ja tilaajan kannalta epämääräiset toimitusajat.

Vastaavia kommentteja kuulee paljon. Yksi selitys voisi olla, että it-yksiköt ja palvelutuottajat eivät ymmärrä toisiaan. Eräs palveluntuottajan edustaja kommentoi kerran, että on onnetonta miten asiakassuhteet aina muuttuvat hyvän alun jälkeen jankkaamiseksi. Toisessa tapauksessa yritin selittää asiakkaalleni, eli sisäisen it:n edustajalle, että heidän pitäisi kytkeä oma muutoksenhallinnan prosessinsa toimittajan muutoksenhallintaan ja perustelin sitä sillä, että toimittajankin on tehtävä muutoksia heidän ympäristöönsä. Asiakkaani vastasi painokkaasti että toimittaja ei tee mitään muutoksia. Asiakas siis ajatteli että toimittajan pitää jäädyttää ympäristönsä heidän sopimuskautensa ajaksi.

Palveluintegraattorin rooli on siis vaativa, integraattorin on ymmärrettävä palveluntarjoajien toiminta ja kyettävä ohjaamaan näitä. Toisaalta integraattorin on ymmärrettävä asiakkaiden tarpeet. Palveluintegraatio ei onnistu, jos osapuolet eivät luota toisiinsa. Onnistunee palveluintegraation avaintekijät ovat luottamus, keskinäinen kunnioitus  ja hyvä suhteiden hallinta.

Miten SLAt saa toimimaan

Eräs vastaaja vastasi äskeisessä pikakyselyssä näin :”minua on harmittanut epäpätevä keskustelu SLA:n hyödyistä ja sen kyvyistä ohjata prosessien priorisointia. Keskustelu on mielestäni sivuraiteella”

Vastaaja on varmasti oikeassa. SLA eli palvelutasosopimus tai -lupaus on hyvä työkalu kun sitä käytetään oikein. Väärin käytettynä siitä sen sijaan voi olla haittaa. Tässä näkemykseni siitä miten SLAt saa toimimaan oikein.

SLA toimii silloin kun:

  1. asiakas tietää tarkalleen mitä haluaa ja on valmis maksamaan siitä
  2. toimittaja kykenee säätämään palvelun halutulle tasolle

Ensimmäinen edellytys on siis, että puhutaan melko vakiintuneesta palvelusta, joka on kuvattu täsmällisesti. Esimerkiksi matkatoimiston käyttämä hotelliluokitus on aika hyvä esimerkki toimivasta SLAsta palveluissa. Viiden tähden hotelleja haluavat matkailijat ovat matkatoimiston kannalta ihanneasiakkaita, eikä heille kannata tuottaa pettymystä.

Asiakkaan vaatimukset

It-palveluissa ensimmäinen pulma tulee siitä, että asiakas ei osaa sanoa mitä tarvitsee. Tai tarkemmin sanottuna: asiakas ei osaa sanoa riittävän tarkasti mitä haluaa. Palvelusopimuksen neuvottelijat eivät ehkä itse käytä palveluja, eivätkä osaa tarkalleen määritellä vaatimuksia. Toinen pulma tulee siitä, että palvelujen sisältö muuttuu kaiken aikaa. Asiakas ei voi tietää omia tulevia tarpeitaan kun palvelun sisältö muuttuu ja it-palvelut usein muuttuvat jatkuvasti.

Huono esimerkki SLAsta on käytettävyysprosentti. Äskeisen SuperBowl ottelun aikana oli puolen tunnin sähkökatko. Jos katko oli ainoa, käytettävyys oli silti vuositasolla 99,99% ja kuukausitasollakin 99,9%. Ysien määrä ei auta, jos palvelu pettää kriittisellä hetkellä. Jotkut tarjoavat vastaukseksi 100%  palvelutasovaatimusta, mutta se voi olla usein turhaa ja kallista.

Pitäisikö palvelutaso aina mitata asiakkaan hyötyjen kautta kuten Stuart Rance esitti aiemmin. Mielestäni kyllä jos mahdollista, mutta usein se lienee mahdotonta. Lisäksi meillä Suomessa hyvin suuri osa it-palveluista on ulkoistettuja, eikä palvelun tuottajalla ole edes suoraa yhteyttä palvelua hyödyntävään liiketoimintaan.

Toimittajan kypsyys

Palvelutason säätäminen edellyttää paljon toimittajalta. Toimittajalla on oltava hyvä hallinta palveluista ja toimittajan tulee kyetä säätämään palvelutasoa. Palvelusopimusten tulee vastata täsmälleen sitä, mitä tuotetaan. Häiriötekijöiden syyt pitää tuntea ja niihin pitää voida vaikuttaa.

Priorisoinnin pitää toimia hyvin ja yli prosessirajojen. Henkilöstön pitää tietää missä järjestyksessä työt tehdään.  Osa palveluntuottajista varmasti pystyy tähän, mutta se ei tarkoita sitä, että palvelu onnistuisi sen käyttäjien kannalta. Palvelun tuottajan on hyvin vaikea tietää esimerkiksi asioiden todellisia prioriteetteja, jos he toimivat etäällä palvelun käyttäjistä.

Vaihda toimittajaa, mutta katso ensiksi peiliin  

Sanktiot koetaan tärkeiksi, koska ilman niitä palvelu ei toimi. Sanktiot ovat kuitenkin huono väline yhteistyössä. Parempi vaihtoehto olisi vaihtaa toimittajaa kunnes löytyy sellainen, joka palvelee hyvin ilmankin sanktioita.

Mikäli palvelussa on ongelmia, pitää selvittää ongelmien syyt. Palvelun tuottaja on hyvä syntipukki omille virheille. Palvelussa voi myös olla rakenteellisia ongelmia, jotka aiheuttavat ongelmia palveluntuottajasta riippumatta.

Helsingin Sanomien mielipidekirjoituksessa toivottiin VR:lle kilpailua ja kirjoittajan mukaan sanktioilla saadaan paremmin toimiva junaliikenne. Mielestäni toive on tuulesta temmattu. Helsingin aseman ohjausjärjestelmä ei tottele sanktioita sen enempää kuin lumipyrytkään. VR:n pilkkomisen seurauksena kokonaisvastuu on kadonnut ja sama pätee moniin it-palveluihin.

Kipupisteet

Pink Elephantin vetäjä David Ratcliffe esitti viime viikolla hyvän kysymyksen twitterissä ja päätin kopioida sen helmikuun pikakyselyksi:  What has been your first big ITSM pain point so far in 2013? Suomeksi kysymykseni on siis vapaasti käännettynä. Mikä asia on harmittanut eniten it-palveluhallinnassa alkaneen vuoden aikana?

Valitsin tämän kysymyksen, koska minun oli itse helppo vastata tähän. Ilmeisesti kaikilla ei ollut vastaavia kokemuksia, koska vastauksia tuli aika vähän, 28 kpl.

Yleisin aihe oli huono palvelun laatu, niitä oli melkein kolmasosa. Esimerkkejä olivat palvelun hitaus, toimimattomuus ja epämääräisyys.

Ulkoisen palveluntuottajan heikko laatu toiminnassaan; suunnattomasti virheitä, viesteihin ei vastata,  ei tehdä mitä sovitaan vaan tehdään ihan jotain muuta,….

Kakkosena tuli johto, eli johdon kyvyttömyys päättää asioista tai ohjata toimintaa.

Minua on harmittanut ylemmän johdon ymmärryksen niukkuus yhä siitä miten olennainen heidän rooli on muutoksen jalkauttamisessa.

Seuraavat aiheet olivat prosessit

Palveluprosesseja ei ole saatu kaikilta osin lanseerattua päivittäiseen toimintaan ja prosessien kehittäminen on jatkuvaa – muutokset samoin.

ja työkalut, jotka eivät toimi halutulla tavalla.

Käytössä olevan ITSM -työkalun sopimattomuus meidän prosesseihin.

Vastaukset olisi toki voinut luokitella toisinkin, työkalut, johto, palvelun laatu liittyvät monessa mielessä prosesseihin ja niiden soveltamisen vaikeuteen.

Omat vastaukseni oli tämä:

Yritän tehdä yhteistyötä muualla asuvan asiakkaan kanssa. Kokemusteni mukaan yhdistelmä Google Hangout ja Google Docs on loistava. Siinä joukko ihmisiä voi työstää samaa dokumenttia ja keskustella videoneuvottelussa yhtä aikaa. Valitettavasti yhteistyö kaatui sisäisen IT.n luomiin esteisiin. Tilalle tarjottiin työkalu, joka ei toiminut. Tietoturvan perusteella estetään tuottavuuden nostaminen. Ehkä tämäkin on palvelun laatua.

Hyvä kysymys on sitten se, mikä ei noussut esiin?

 

%d bloggers like this: