torstai 13. tammikuuta 2011

Palvelun omistaja - mmmmikä??

Teknisessä IT-maailmassa palvelu on joskus käsitteenä tuntematon. Nyt kun yrityksissä - meilläkin - rakennetaan palvelukatalogeja kiihtyvällä tahdilla, on hyvä selkeyttää "Palvelun omistajan" roolia.

Kuka siis omistaa palvelun? Olen kuullut vaihtoehtoja teknisen tiimin vetäjästä (mikä voikin olla totta) tietohallintojohtajaan - hänhän vastaa kaikista palveluista. ITIL kuvaa palvelun omistajan vastuun aika näppärästi ja vähän laventaen palvelun omistajan roolia voisi kuvata seuraavalla tavalla.

Accountability

Varsinkin useasta teknisestä palasesta koostuvan palvelun toimitus saattaa hiipua palvelun omistajan puuttuessa. Ketään ei kiinnosta, toimiiko kokonaispalvelu - kunhan oma osio toimii. Sähköposti on palveluna helppo esimerkki: palvelintiimi vastaa mailialustasta, työasematiimi pitää huolta mailiclientin asennuksesta ja helppari opastaa palvelun käytössä. Kuka sitten sopii asiakkaan kanssa käytettävät levytilat, palveluajat, käyttörajoitukset? Palvelun omistaja tietenkin. Tilivelvollisuus - accountability - täytyy osoittaa jollekin, muuten palvelu saattaa hiipua huonoksi. Toki se yleensä toimii, mutta kuinka hyvin?

Palvelun omistaja - Service Owner

Palvelun omistaja vastaa palvelusta kokonaisuutena: siitä, että palvelun vaatima infrastruktuuri, sovellukset, tuki, neuvonta ja muut tarvittavat osat toimivat. Palvelun omistaja vastaa tästä läpi organisaation riippumatta siitä, kuka näitä osia tuottaa tai missä organisaation osassa tarvittavat kyvykkyydet sijaitsevat. Tämän vastuun osoittaminen on välttämätöntä, jos halutaan varmistaa liiketoiminnan tarpeiden täyttyminen ja uusien tarpeiden huomioiminen organisaatiossa.

Palvelun omistaja vastaa palvelun jatkuvasta kehittämisestä ja siihen kohdistuvien muutosten hallinnasta (kuten prosessin omistaja vastaa prosessin jatkuvasta kehittämisestä). Tämä vaatii organisatorisen valtuutuksen onnistuakseen, sillä yleensä osia tuotetaan monilla organisaation tasoilla ja varsinkin monissa osissa. Palvelun omistaja on päätekijä kaikissa palvelun tuotamiseen liittyvissä prosesseissa. Esimerkkejä:

Häiriönhallinta(* - vakavien häiriöiden haltunotto, korjauksen koordinointi
Ongelmanhallinta -  tärkeä vastuu perussyiden etsimisessä ja ongelmanhallinnan ylläpitämisessä
Jakelun- ja käyttöönoton hall. - palvelun omistajana päätekijä päätettäessä siitä, onko palvelun uusi versio valmis käyttöönottoon
Muutoshallinta - edustaa palvelua CAB:ssa, esittelee ja päättää muutoksista
Konfiguraationhallinta - varmistaa, että palvelua tuottavat ryhmät ylläpitävät konfiguraatiotietoa ja -suhteita riittävällä tasolla
Palvelutasonhallinta - on keskitetty yhteyspiste palvelutasoasioissa ja varmistaa, että palvelukatalogi on aina ajan tasalla
Saatavuus ja kapasiteetti - tarkastelee kokonaisuutta ja varmistaa, että sovitut palvelutasot ja asiakastarpeet täyttyvät
Jatkuvuuden hallinta - Ymmärtää, vastaa ja varmistaa että kaikki palvelun palauttamiseen tarvittavat osat ovat olemassa ja tiedossa palvelun palauttamiseen kriisitilanteessa
IT-taloushallinta - tuntee palvelun kustannskomponentit ja osaa hinnoitella palvelun niiden perusteella.

Vaikka organisaatio toimii tuotannollisissa prosesseissa hyvinkin tehokkaasti, voi palvelun omistajan puute olla vakava este palvelun onnistuneelle tuottamiselle.

Puuttuuko tämä rooli organisaatiostasi? Toivottavasti tämä roolikuvaus auttaa perustamaan omistajuuden ainakin kriittisille palveluille!

(*  pahoittelen epäkorrektia termiä. Tämähän on vain lobbausta sille, että häiriönhallinta otettaisiin viralliseen sanastoonkin, koska vakuutusalalla tapahtuma on aivan muuta kuin IT(IL):ssä.

keskiviikko 5. tammikuuta 2011

Huippuvisionääri vai teiden tukko?

Haluaisitko mieluummin olla huippuvisionääri vai turhauttava teiden tukko? Esitteletkö mieluummin uusia mobiilipohjaisia sosialistisen median sankaritekoja vai selitteletkö häiriö- ja muutosraportteja? Haluaisitko olla mieluummin teknologiajohtaja (CTO) vai tuotantopäällikkö?

 Osallistutko mieluummin tähän kilpailuun voittajaehdokkaana....

 Vai oletko hidas, raivostuttava, kaikkien kaveri mutta TEIDEN TUKKO

Totta se on: IT-tuotanto on tylsää. Innovaatio ja uudet ratkaisut antavat mainetta ja kunniaa ja tuottavat lisäarvoa - joskus. Sovelluskehitys on scrumukavaa ja uudet ominaisuudet voidaan viedä agiilisti suoraan tuotantoon jo tänään.

Tuotannosta taas on vain harmia. Siellähän tuotetaan häiriöitä ja estetään muutoksia, toimitetaan palvelimet kaksi viikkoa myöhässä (vaikka tilasin jo eilen) ja vaaditaan täyttämään jotain typeriä planketteja. Lisäksi se tuotannossa oleva teknologia on vanhentunutta eikä se edes tue kohta julkaistavaa xPhonea.Vuoden IT-vaikuttaja ei voi tulla tuotantopuolelta.

Jonkun se tuotanto kuitenkin on tehtävä. IT-kuluista keskimäärin 60-80% kohdistuu palveluiden tuottamiseen. Tämä asia unohtuu usein. Tuotanto on yksitoikkoista, raskasta, jopa ympärivuorokautista työtä.


Onneksi löytyy vielä meitä hyväuskoisia hölmöjä, jotka pitävät tätä aluetta kiinnostavana.

Tuotannon täytyy toimia joustavasti. Asiakkaan - ja käyttäjienkin - toive- ja tarvetilat pitää tietää ja ennakoida ja tehdä muutokset tehokkaasti. Tähän tehokkuuteen liittyy selkeä ja varma muutoshallinta, joka vaatii järjestelmällisyyttä. Mitä formaalimpia toiminta on, sitä joustavammin ja nopeammin tuotanto mukautuu muuttuviin tarpeisiin. Siksi niitä plankettejakin pitää täyttää.

Ei tuotannossa oikeasti generoida häiriöitä tahallaan. Häiriöt johtuvat yleensä muutoksista, ylivoimaisesti useimmin. Myös palvelusuunnittelu saattaa olla puuteellista, järjestelmäarkkitehtuuri liian monimutkainen tai sitten on vain huono tuuri. Tuotannossa kun ei olisi sijaa sattumalle.

Ymmärrys tuotannon prosessien ja suunnitelmallisen toiminnan tärkeydestä tuntuu kasvavan nopeasti yrityksissä. ITIL-mouhotus ei ole mennyt hukkaan, mutta työmäärä on suuri ja työ jatkuu pitkään. Tuotannosta ei pääse eroon idean keksimisen jälkeen vaan sitä täytyy kehittää jatkuvasti, iteroida, palata aina uudestaan miettimään mikä toimii ja mikä ei.

ITIL-mallit toimivat hyvin käytännössä. Varsinkin yllä mainittuihin häiriö- ja muutosprosesseihin löytyy kirjoista paljon suoraa sovellettavaa. Ne ovat kuitenkin reaktiivisia prosesseja, ja jatko palvelusuunnittelun prosesseihin laskee varmasti tuotantoon käytettyä rahasummaa - siis vähentää häiriöitä.

Pääsin syksyllä parhaalle mahdolliselle näköalapaikalle kehittämään teknologia- ja tuotantotoimintaa. Häiriö- ja muutosprosessien prosessit ja työkalut on nyt otettu käyttöön (v0,9) ja palvelut on kuvattu - ensimmäinen palvelukatalogin versio on valmis! Seuraavaksi olemme siirtyneet ongelman- ja konfiguraationhallinnan kimppuun. Palvelupyynnöt automatisoituvat vielä tämän tammikuun aikana ja ITIL-koulutettuja on jo yli 42 kpl. Tahto järjestelmälliseen toimintaan vaihtelee, mutta hyödyt näkyvät jo nyt ja ne on ymmärretty varsinkin asiakkaan päässä.

Seuraavaksi keskustellaan varmaankin syvällisesti aiheesta "miksi kaikki palvelupyynnöt ja häiriökorjaukset pitää kirjata, eihän tässä muuta ehdi tekemäänkään jos...".

Uudet prosessit ja tehtävät täytyy pystyä perustelemaan, totta. Tämäkin asia selvenee kevään aikana, kun niitä kirjauksia tulee aina vain vähemmän ja vähemmän ja vähemmän ja vähemmän...

Lopuksi vielä hyvin varjeltu ITSM(*-ihmisten salaisuus:

ITIL, IT-tuotannon kehittäminen ja vieläpä se tuotantokin voi olla mielenkiintoista. Todella mielenkiintoista!

(* IT Service Management

Template by - Abdul Munir | Daya Earth Blogger Template