Mikä on DevOps?

DevOps kovassa nousussa oleva muotitermi. Nimi on keksitty Belgiassa viitisen vuotta sitten. Termillä tarkoitetaan kehittäjien (Development) ja tuotannon (Operations) sujuvaa yhteistyötä. Perinteisesti sovelluskehitys ja palvelutuotanto ovat olleet kaksi eri maailmaa. Kehittäjät kehittävät ja tuotanto pyörittää järjestelmiä. Tuotantoonsiirtoa valvotaan tiukkaan. Itilissä oli alkujaan kaksi prosessia sitä varten, muutoksenhallinta ja jakelunhallinta. Iitil 2011 versiossa on niin lukuisia prosesseja hoitamassa samaa asiaa, etten viitsi niitä tässä luetella. Tuloksena on ollut jäykkä ja hidas toiminta, jota voidaan perustella riskien välttämisellä ja joka on tarpeen eteenkin perinteisissä keskitetyillä palvelimilla tai työasemilla toimivissa ympäristöissä, joissa käyttöönotto merkitsee yleensä palvelukatkoa.

Uudet toimintaympäristöt ja työkalut mahdollistavat myös toisenlaisen toiminnan. Internetsovellusta voidaan päivittää useita kertoja päivässä, ilman että käyttäjät huomaavat sitä. Ketterä kehittäminen suosii nopeata ja vaiheittaisia kehittämistä ja on luontevaa siirtää valmistuneet osat tuotantoon saman tien, eikä jäädä odottamaan viikkoja tai kuukausia seuraavaa tuotantoonsiirtoa. Kyseessä on osin sukupolvikysymys, monet tämän päivän nuorista kehittäjistä on koodannut jo lapsesta alkaen ja oppinut luontevia toimintatapoja. Vesiputousmallit ja itil jäävät historiaan.

Toisaalta DevOpsiin liittyy myös kehitystyökaluja. Palvelimia ei tarvitse asentaa fyysisesti vaan ne koodataan pilveen. Testaaminen ja tuotantoonsiirto tehdään samoin koodaamalla. Uuden version käyttöönottoon liittyy aina riskejä, mutta nopeus auttaa myös virheiden korjaamisessa.

Ehkä tärkeintä DevOpsissa on tuotannon ja kehittämisen välinen yhteistyö. Kaimar Karu sanoo että DevOps tarvitsee olutta. Kehittäjien ja tuotannon pitää tutustua ja viettää aikaa yhdessä.

DevOps on enemmänkin filosofia kuin menetelmä. On jokseenkin varmaa, että kohta ilmestyy, (jollei ole jo ilmestynytkin), DevOps kouluttajia ja konsultteja. Vaarana on, että heillä on hyvin vähän tietoa ja olematon kokemus aiheesta. Edellisessä artikkelissa kirjoitin SoMe-kouluttajasta, joka on aivan vihreä Twitter-käyttäjä.

Mielestäni DevOps on osa seuraavan sukupolven tietotekniikkaa. Vanhat mallit saavat väistyä ja toiminnan pitää olla nopeaa, tehokasta ja ennen kaikkea laadukasta. Itse asiassa Service Desk 2.0 tarvitsee taustalleen ketterän tuotannon.

Mittaamisen vaarallisuus

Reetta Räty kirjoitti helsingin Sanomissa 16.3. Valitus on kaikkialla sama: Onko tulospalkkioarvioinneista, muutosvalmiusmittareista ja laadunseurantajärjestelmistä mitään hyötyä?

Milloin ehtii tekemään töitä?

Työpaikoille pesiytynyt mittaus- ja valvontavimma turhauttaa. Kaikkea mitataan ja kaikesta pitää tehdä raportti. Tarkoitus on hyvä mutta lopputulos piinaava.

Olen samaa mieltä. Mittaamisen tärkeys on tavallinen hokema, joskus väitetään että Deming sanoi että mitä ei voi mitata, sitä ei voi ohjata. Itse asiassa Deming sanoi väitteen olevan kallis myytti. “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth”.

Miksi mittaaminen voi olla vaarallista? Olemme tottuneet käyttämään mittareita ja luottamaan niihin. Vaarallisuus syntyy siitä, että mittariin luottava henkilö ei ymmärrä mittarin antaman tiedon merkitystä.

Lämpömittari kertoo millaista ulkona on, nopeusmittari kertoo kuinka kovaa mennään jne. Mittarit antavat selkeitä tavoitteita ja raja-arvoja. Nopeusrajoitus on hyvä esimerkki mittareiden vaarallisuudesta. Autoilija saattaa kuvitella ajavansa turvallisesti ajaessaan nopeusrajoitusten mukaisesti liukkaalla tiellä, vaikka hän ehkä ajaakin kuin formulakuski, pidon äärirajoilla. Nopeusmittari kertoo auton nopeuden, mutta se ei kerro tarvittavaa jarrutusmatkaa. Hyvissä olosuhteissa jarrutusmatka riippuu jokseenkin suoraan nopeudesta (sen neliöstä), mutta huonoissa olosuhteissa tienpinnan kunto vaikuttaa hyvin paljon.

Toimivien mittareiden kehittäminen on vaikeaa ja usein käytetään mittareita, joiden tiedetään olevan epätarkkoja tai puutteellisia.

Tietotekniikan toimivuus on vaikeasti mitattava asia. On hyvin vaikea mitata tietotekniikan tuottamaa hyötyä. Sen sijaan on paljon helpompi mitata tietotekniikan komponenttien toimintaa ja ajatella, että se vaikuttaa saatuun hyötyyn. Prosessit tuottavat erilaisia mittareita, joiden avulla voimme seurata prosessien toimintaa. On helppo koota suuri joukko mittareita ja luoda mielikuva, että tilanne on hallinnassa. Ongelmia syntyy jos:

  • mittaamme vääriä asioita
  • satunnaiset tekijät vaikuttavat mittareihin
  • emme ymmärrä miten mittari toimii

On hyvin tavallista, että mitataan prosessin toimintaa. Prosesseissa on erilaisia aktiviteetteja ja niistä saa mittareita helposti. Kun prosessia käynnistetään, on tärkeää alkaa mitata sen toimintaa. Mittaukset varmistavat sen, että prosessi toimii halutulla tavalla. Tässä ei ole mitään väärää. Ongelmia syntyy jos ja kun mittareista tehdään tavoitteita ja tavoitteita asettavat henkilöt, jotka eivät niitä ymmärrä. Prosessin toiminta ei ole tavoite, prosessin toiminta on aktiviteettia, jonka tuloksena pitäisi syntyä jotain hyödyllistä.

Mittaamisen vaarallisuudesta

Re-thinking IT  on loistava John Seddonin keynote-esitys vuodelta 2010. Olen katsonut sen kaksi kertaa vaikka en juuri jaksa katsella videoituja esityksiä. Löysin linkin siihen tästä How not to use IT in service.

Joitakin kohokohtia:

  • aktiviteetti-mittareilla ei ole mitään arvoa
  • kustannusten jahtaaminen lisää niitä
  • standardointi kasvattaa kustannuksia
  • suuruuden ekonomia ei toimi palvelussa

Jokaisen it-palvelunhallinnasta kiinnostuneen tulisi katsoa se. Siinä on hyviä esimerkkejä service deskeille vaikka esityksen teeman on IT:n johtaminen.

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?

 

Hidasta edistystä edelleen

Työkalututkimuksen tulosten mukaan n. 20% on edistynyt prosessien käyttöönotossa, mutta 80% käyttää työkalua lähinnä Service Deskissä. Tämä tulos vastaa sitä yleistä käsitystä, että itilin mukaisten prosessien todellinen käyttöönotto ei ole edennyt kovin pitkälle. Perinteinen malli on, että opiskellaan itiliä, kuvataan prosessit ja hankitaan työkalu tukemaan niitä. Joskus menetelmä tuottaa hyviä tuloksia, mutta yleensä ei. On tavallista että kehitys pysähtyy ja prosessit rapistuvat.

Jos prosessit ovat kunnossa, ne näkyvät. Tässä testikysymyksiä. Prosessit ovat hallinnassa, jos teillä käydään tällaisia keskusteluja:

  • Järjestelmän X tikettien määrä on kasvanut 27% ja sen takia sitä pitää kehittää.
  • Muutosten läpivienti vie keskimäärin 14 vrk ja se halutaan pudottaa 5 vuorokauteen.

Itil buumi alkoi Alankomaissa 10 vuotta aiemmin kuin Suomessa. Silti siellä tuskaillaan saman ilmiön kanssa. Prosesseja on vaikea saada toimimaan. Jan van Bon kertoo kehittäneensä menetelmän, jolla prosessit saadaan oikeasti toimimaan. Ytimenä on  palvelunhallinnan ohjausjärjestelmä (Service Management System), jonka mm. ISO 20000 vaatii. Prosesseja on paljon vähemmän kuin itilissä, mutta ne kattavat samat alueet.

Kiinnostaisi päästä kokeilemaan Janin metodia. Siihen tarvittaisiin asiakas, joka on todennut, että kovasta yrittämisestä huolimatta itilin käyttöönotto ei etene ja että tarvitaan uusi lähestymistapa.

 

Kypsyydestä

It-organisaation tilaa voi kuvata sen kypsyystasolla. Kypsyystasot ovat usein suhteellisen helppo tunnistaa ja niistä on olemassa lukuisia malleja. Lähtökohtana on yleensä yksilöllinen toiminta, johon tulee ensin valvontaa, sitten hallintaa, ohjausta ja optimointia. On tavallista ajatella että kypsyydessä pitää pyrkiä aina korkeimmalle tasolle, mutta se ei ole välttämättä totta. Olen käyttänyt renkaiden vaihtoa esimerkkinä erilaisista kypsyystasoista.

 0-taso Sakkokuski ei vaihda renkaita kuin pakon edessä.
1-taso Yksityisautoilija tarkistaa renkaiden kunnon kesä/talvi-renkaiden vaihdon yhteydessä ja hankkii uudet kun kulutuspinta alkaa olla vähissä.
2-taso Taksiyritys uusii renkaat 50.000 km välein.
3-taso Bussiyhtiön ajomestari seuraa renkaiden kulumista ja määrää vaihtohetken puoli vuotta aikaisemmin.
4-taso Rekkayhtiö seuraa renkaiden kulumista ja maksaa kuljettajille bonuksia jos renkaat kestävät keskimääräistä paremmin.
5-taso Formula 1 talli arvioi renkaiden keston kierroksen tarkkuudella, mutta muuttaa suunnitelmia, jos olosuhteet vaihtuvat. Renkaan vaihtohetkeen vaikuttavat rata, kierrosajat, sää ja muiden kilpailijoiden toiminta. Tavoiteaika vaihtoon on 4 sek.

 Edellä kuvattu malli korostaa sitä, että tavoiteltava kypsyystaso riippuu tarpeesta, mutta toki jokainen voi toimia tarvittavaa matalammalla kypsyystasolla.

Elokuun kyselyn teemana oli KPMG:n jo vuonna 2000 julkaisema malli IT yksikön kypsyydestä. Mielestäni malli on edelleen osuva.

Mallin kypsyystasot

  1. Teknologialähtöinen. IT taistelee tekniikan kanssa, juuri mitään prosesseja ei ole käytössä. Asiakas saa sitä mitä kyetään tarjoamaan. Toiminta voi sinänsä olla melko asiakaslähtöistä, mutta sen laadun ja luotettavuuden kanssa on ongelmia.
  2. Prosessikeskeinen. Prosessit on saatu toimimaan ja IT kykenee mittaamaan toimintaansa. Prosessit ovat keskeisessä roolissa ja asiakkaan tulee mukautua niihin, muuten palvelu ei toimi.
  3. Palvelukeskeinen. IT on määritellyt palvelunsa ja kykenee tuottamaan niitä ohjaamalla prosessejaan. Palvelut ovat standardoituja. Asiakas voi tilata palveluja, mutta ei voi muokata niitä.
  4. Asiakaskeskeinen. Nyt asiakas pääsee päättämään palveluista ja IT toimii lähellä asiakasta tiiviissä yhteistyössä. Taustalla ovat toimivat prosessit ja standardoidut peruspalvelut. Niitä osataan käyttää hyvin joustavasti.
  5. Liiketoimintakeskeinen. Liiketoiminta ohjaa IT:tä täysin ja IT:n tavoitteet ovat liiketoimintatavoitteita.

Tässä mallissa palvelukeskeisyyden ja asiakaskeskeisyyden välillä on merkittävä kynnys. Alemmilla tasoilla IT päättää ja asiakas saa mitä IT toimittaa, ylemmillä tasoilla vastuu on siirtynyt asiakkaille. Kyse ei ole siis pelkästään IT:n kypsyydestä, vaan myös asiakkaan on kypsyttävä tähän rooliin.

Tämän pohjalta yritin kuvata tilanteita, joissa kukin taso olisi saavutettu.

 
a) Teknologia on hallussa. IT laitteet ja järjestelmät toimivat ja mahdolliset vikatilanteet kyetään korjaamaan.
b) Prosessit toimivat tehokkaasti. Kaikki häiriöt, ongelmat, muutokset jne. kirjataan. Häiriöiden ratkaisuajat tiedetään ja muutosten riskit osataan arvioida.
c) Palvelut pelaavat. Osataan tuottaa pitkälle standardoituja IT palveluja asiakkaan tilausten mukaan. Muutosten vaikutukset tunnetaan ja palvelujen laatu on hallinnassa.
d) Asiakas määrää. Asiakas ohjaa toimintaa ja päättää mitä IT palveluja tuotetaan. IT-organisaatio kykenee mukautumaan joustavasti muuttuviin tarpeisiin.
e) Liiketoiminta ohjaa.  IT on sulautunut liiketoimintaan ja sitä johdetaan liiketoiminnan näkökulmasta. IT pystyy luomaan uusia mahdollisuuksia liiketoiminnalle. 

Pyysin kertomaan miten hyvin vastaajan organisaation nykyinen tila vastaa näitä kuvauksia asteikolla: 1 -5. 1 ei lainkaan, 2 vain vähäisesti, 3 osittain, 4 aika hyvin ja 5 täydellisesti.

Lisäksi pyysin vielä kertomaan mikä näistä kuvauksista vastaa nykyistä tilaa ja mikä on tavoitteena. Tämä kysymys oli ilmeisesti vaikeasti muotoiltu, sillä n. kolmasosa jätti vastaamatta siihen tai vastasi väärin. Oikea vastaus olisi siis ollut jokin kirjain, esim. nyt A ja tavoitteena B. Näin muuten ei yksikään vastannut, vaikka se olisi oikea vaihtoehto aika monelle.

Valtaosassa vastauksissa oltiin tasoilla 4 tai 3 eli aika hyvin tai osittain. Ainoastaan teknologia -tasolla löytyi merkittävä määrä täydellisesti -vastauksia.

Kynnys palvelu- ja asiakastasojen välillä näkyy selvästi, vain alle 20 % arvioi olevansa niillä tasoilla.

Oman tason ja tavoitetason välillä on mielenkiintoinen korrelaatio. Jos omaksi tasoksi arvioitiin teknologia, tavoittetasona oli yleensä palvelu. Jos taas oma taso oli jokin muu, tavoitteeksi tuli asiakas- tai liiketoimintakeskeisyys.

Tein oman tulkinnan kypsyystasoista vastausten perusteella.

Jos vastaaja oli jonkun kypsyystason kuvaavan täydellisesti, hyväksyin sen. Jos vastaaja ei sanonut yhdenkään tason toteutuvan täydellisesti, mutta sanoi useamman toteutuvan aika hyvin, valitsin näistä toiseksi ylimmän. Näin laskin jokaiselle vastaajalle tämän hetken kypsyystason. Periaatteena oli, että alempien kypsyystasojen täytyy toteutua eli kypsyystasoarvioiden piti pysyä samana tai pudota.

Oman tulkintani mukaan vajaa puolet jäi tasolle nolla, eli teknologia ei ole täysin hallussa. Vajaa neljännes on saavuttanut sen tason. Joka viidennes on saavuttanut prosessitason ja yksi kymmenestä palvelutason. Yksi henkilö vastasi 5 joka tasolle.

Johtopäätökset

Tulos on mielenkiintoinen monella tavalla. Tämän mukaan noin puolet it-yksiköistä ei ole päässyt yli teknologiakeskeisyydestä. Mielestäni monet havainnot tukevat tätä tulkintaa.

Teknologian hallinnan tasolle on päässyt joka neljäs ja heillä on edellytykset saada prosessit toimimaan. Joka viides on prosessitasolla ja joka kymmenes päässyt yli seuraavan kynnyksen. ITIL termein 20 % on V2-tasolla ja 10 % V3-tasolla ja lähes 70 % ei ole vielä saavuttanut ITIL V2 -tasoa.

Näyttää siltä että tasoeroja ei tunnisteta. Prosessikeskeisyys ei ole sama asia kuin palvelukeskeisyys. Tämä on mielestäni ITILin kolmosversion ongelma, siitä ei käy ilmi että se kuvaa kaksi kypsyystasoa ikään kuin yhdessä. Asiakaskeskeisyyden haaste sen sijaan tunnistetaan ja valtaosa vastaajista näkee että sinne on vielä matkaa.

Tavoitteiden asetanta on vielä optimistista. Realistinen tavoite on seuraava kypsyystaso. Liiketoimintakeskeisyys tuntuu houkuttelevalta, mutta silloin tosiaankin it:n toimivuutta mitataan samalla tavalla kuin itse liiketoimintaa, siis myyntinä, kannattavuutena jne.

Jokaisen it-yksikön pitäisi tunnistaa oma kypsyystasonsa ja ulkopuolinen tarkkailija voi olla avuksi tässä. Sitten on arvioitava mikä on tarvittava kypsyys ja sen määrää asiakkaan tila. Ei ole lainkaan selvää, että liiketoimintakeskeinen kypsyystaso on oikea tavoite kaikille. Se edellyttää että it:llä on aidosti merkittävä rooli liiketoiminnassa ja näin ei ole läheskään kaikilla aloilla.

Asiakaskeskeisyys edellyttää että asiakas on halukas ottamaan merkittävän roolin it:n ohjaamisessa. Näin ei suinkaan ole aina. Palvelukeskeisyys luo myös raja-aidan asiakkaan ja palveluorganisaation välille, kuten jokainen palvelun ulkoistanut on varmasti havainnut. Voi myös pohtia riittääkö teknologian hyvä hallinta joissakin tapauksissa eli tarvitsevatko kaikki prosesseja?

Oma kypsyystaso määrittää sen, mitä pitää kehittää ja miten palvelua voi mitata. Esimerkiksi prosessien käyttöönotto takeltelee, jos ollaan edelleen vaikeuksissa teknologian kanssa. Palvelujen tason mittaaminen on vaikeaa, jos prosessit eivät toimi jne. Johtamisen täytyy myös olla vastaavalla kypsyystasolla. Kaikki tämä on helpompi sanoa kuin tehdä.

20 miljonaa käyttäjää, 50.000 tukipyyntöä kuukaudessa ja 10 henkeä tuessa.

Vanhassa maailmassa yritys osti tietokoneen ja palkkasi ihmisiä hoitamaan ja ohjelmoimaan sitä. Kun koneiden ja niitä hoitavien ihmisten määrä kasvoi, tarvittiin prosessimalli palvelujen tuottamiseen. Syntyi ITIL,  parhaat käytännöt. Vanha maailma on toki muuttunut, enää ei käytetä reikäkortteja mutta samat vanhat periaatteet pätevät.Lähde Flickr

Uudessa maailmassa yritykset tuottavat palveluja verkossa. Yritykset ostavat toisten yritysten palveluja ja jalostavat niitä edelleen asiakkailleen. Olen yrittänyt selvittää, miten nämä uuden maailman yritykset tuottavat ja tukevat palvelujaan. Olen haastatellut kahta yritystä huhtikuussa 2012. Toinen on Automattic , jonka palvelua sinäkin käytät juuri nyt lukiessasi tätä tekstiä. Nämä sivut on tuotettu WordPress.com:in avulla, joka on Automatticin palvelu. Toinen on Flowdock, suomalainen startup, joka on juuri saanut ensimmäisen kansainvälisen rahoituksen.

Automattic on hauska yritys, sillä on 108 työntekijää 24 maassa ja 26 USAn osavaltiossa, mukana yksi suomalainenkin, Systems Wrangler Pyry Hakulinen. Toimitusjohtajan titteli on Band Manager, perustajan titteli taas on CBBQT, Chief BBQ Taste Tester.  Asiakastuen henkilöstön tittelinä on samaan tyyliin Happiness Engineer. Haastateltavana oli Happiness Engineer Andrew Spittle, joka toimii tiimin vetäjänä. WordPress on heidän suurin palvelunsa, jolla on yli 20 miljoonaa käyttäjää maailmassa.

Automattic perustettiin 2005, aloin itse käyttää WP:tä 2008. Palvelu on laaja ja monipuolinen, eikä maksa paljoa, vuosimaksu mainosten poistamisesta on 30 $. WP:n tuki on erinomainen, minulla on ollut pari pulmaa ja niihin on tullut vastaus hämmästyttävän nopeasti. Olen myös saanut läpi yhden pienen muutoksen, ehdotin että teksti : ”ei kommenteja” vaihdettaisiin tekstiksi ”jätä kommentti”. En tosin tiedä tehtiinkö muutos juuri minun pyyntöni seurauksena, mutta joka tapauksessa se tehtiin pian sen jälkeen kun olin pyynnön esittänyt.  Haastatteluni sain myös esittämällä pyynnön tukipyyntölomakkeen kautta. Alustava kielteinen vastaus tuli aika nopeasti, mutta sitten se pienen harkinnan jälkeen vaihtui myönteiseksi. Aiemmin kotisivuni tuotti Nodeta Oy, jonka vetäjä on poikani Mikael Roos. Flowdock syntyi Nodetan suojissa, linkin takana yrityksen tarinaa. Löysin WordPressin itse asiassa poikani neuvoilla, kun hän kyllästyi kotisivujeni väkertämiseen.

Seuraavassa joitakin havaintoja molemmista haastatteluista.

Molemmissa tapauksissa yhteydenotto tapahtuu suoraan itse tuotteen kautta. WP:n tuen lähestyminen on helppoa ja siksi tukipyyntöjä tulee lähes 50.000 kuukaudessa. Puolet näistä hoitavat WP:n julkiset foorumit, joissa tukea tarjoavat toiset käyttäjät. Tässä pyynnöllä tarkoitetaan uuden keskustelun avausta. Vanhoista keskusteluista myös varmasti löytyy apu suurelle joukolle, mutta sitä ei rekisteröidä. Varsinaisia tukipyyntöjä tulee 24.000 kuukaudessa ja niitä käsittelee 10 henkeä ympäri maailmaa. Lisäksi tukiryhmä seuraa foorumien keskusteluja ja puuttuu niihin tarvittaessa. Flowdock ei halua julkaista volyymejään ollessaan herkässä kasvuvaiheessa, mutta tuhansia yhteydenottoja alkoi tulla kun tuote löysi markkinansa ja niitä tulee jatkuvasti.

Kirjausvälinettä ei käytetä, vaan tiketit kirjautuvat omaan tuotteeseen. Osaa Flowdockin ”tiketeistä” voi seurata Twitterissä. WordPressillä on taas useita blogeja, joissa käsitellään pulmia ja ehdotuksia.

Molemmat päivittävät tuotettaan huimaa tahtia. WordPressillä on menossa n. 40.000 versio ja päivässä julkaistaan n. 16 uutta päivitystä. Flowdock tekee samoin useita päivityksiä joka päivä. Käyttäjien todelliset pulmat ratkotaan minuuteissa. Flowdockin muutoksista keskustellaan chatissa, WordPressin taas blogeissa. WordPressin henkilöstö toimii hyvin itsenäisesti, jos joku haluaa tehdä jotain niin saa tehdä, omaan harkintakykyyn luotetaan.

Kumpikaan ei sovella ITILiä. Kommentit ovat tiukkoja: ”Emme halua käyttää jäykkiä frameworkkeja.” ”Meillä ei ole prosesseihin prosessin vuoksi”. ”Emme käytä prosessia, koska se on prosessi”. ”Meillä ei ole hierarkiaa tai eskalointia.” Tässä tulee mieleen TietoTapiolan Timo Hyvösen kommentti ITILin käyttöönotosta: ”Koko organisaatio ei varmasti ole koskaan samaa mieltä muutosten tarpeellisuudesta, mutta siksi organisaatiot ovat hierarkisia. ”

Niin, kummassa haluaisit olla töissä tai asiakkaana. Tiukassa, kurinalaisessa prosessiorganisaatiossa, jossa marssitaan johdon komentamana ITILin tahdissa, vai nopeassa, joustavassa organisaatiossa, joka luottaa yksilöihin?

%d bloggers like this: