lauantai 27. huhtikuuta 2013

Onko ITIL liian vaikea?

Muutamia vuosia ITIL-maailmaa ja erilaisia keskusteluja seuranneena olen havainnut, että ITILissä on yksi iso haittapuoli. Se on sama kuin matematiikassa - jos ei ole aikaa tai energiaa tutustua siihen kunnolla, siitä voi tulla ärsyttävää ja joistain epäoleellisista yksityiskohdista tulee vedettyä  nopeita johtopäätöksiä. Integraalit ovat ärsyttäviä, derivaatoista puhumattakaan - kuka niitä edes tarvitsee?

ITIL-kirjojen kieli on ollut koukeroista ja sitä onkin pyritty selkeyttämään aktiivisesti. Käännöstyössäkin olemme hakeneet perustarkoitusta kuvaavia lauserakenteita, mutta jotkin määritelmät vaativat oikeasti ajattelua auetakseen.

Onko palvelun määritelmä vaikea?

Otetaanpas esimerkiksi palvelun määritelmä: "A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.” Luettuani ja ajateltuani tuota satoja kertoja, on ajatus minulle täysin selvä. "Palvelu on tapa tuottaa arvoa asiakkaalle niin, ettei hänen tarvitse huolehtia yksittäisistä kustannuksista tai riskeistä". Koukeroista, mutta nyt ei puhutakaan yhteen- ja vähennyslaskusta vaan IT-tekniikoiden jalostamisesta palveluiksi. Integroidaan sovellukset, infra ja tuki niin, että esimerkiksi CRM toimii. 

Ei kiireistä liikemiestä kiinnosta, miten se Passeli asennetaan millekin palvelimelle tai onko siellä GHz vai RAM vai onko INCIDENT MANAGEMENT kunnossa. Hän haluaa palvelun, joka tuottaa hänelle arvoa. Sen pitää toimia, tukea pitää saada tarpeen mukaan eikä laskuissa kiinnosta muutoksenhallinnan kirjaustyö. Minusta tuo ajattelua vaativa palvelun ITIL-määrittely osuu tähän hyvin. Niin ja jos liikemiestä kiinnostaa jokin noista asioista, kannattaa pyrkiä IT-alalle.

Entäs anti IT-osastolle?

Hypätäänpäs sitten IT-osastolle. ITILin prosessikuvaukset ovat kuitenkin monimutkaisia ja vaikeita eikä niitä ainakaan käytäntöön voi viedä?

Hämmästyin aikanaan harakiri-varaosakaupassa kun kuulin, että 1973 Renault 6:ssa oli käytetty seitsemänlaisia (7) etujarruja yhden vuoden aikana JA tämä asia oli tiedossa siellä kellarifirmassa. Olin melkein yhtä hämmästynyt, kun aikanaan palveluoperaattori ei pystynyt kertomaan minulle, millä palvimilla eräs kriittisimmistä sovelluspalveluistamme pyöri - "jokin noista 4000 tuolla vasemmalla, kai...".

Ovatko ne ITILlit sittenkään niin monimutkaisia, testataanpas vaikka konfiguraationhallintaprosessilla. Päästäisiinkö tällä konfiguraationhallintaprosessilla autoteollisuuden konfiguraationhallinnan tasolle IT-alallakin?

Konfiguraationhallintaprosessi

Ensimmäinen askel prosessikuvauksessa on "Management and planning" - suunnittelu. Määritellään johtamismalli, organisoituminen ja roolit ja suunnitellaan datamalli, konfiguraationhallinnan laajuus ja...aika selkeää? Vähän sama kuin talonrakennuksessa, tehdään ensin piirustukset - sehän vaatisi rakennusmestarin tai muun suunnittelijan - pitäisikö IT-alalla  pystyä tekemään sama suunnittelu pystymetsästä? Asia sinänsä on ihan käytännöllinen, vaatii vain tietyn osaamisen.

Seuraava askel - identification, tunnistaminen - on aivan selkeä. Mitä meillä on tällä hetkellä, montako serveriä ja softaa ja missä. Tähänhän löytyy automatisoituja ohjelmistoratkaisujakin, siksi tästä on usein liiankin helppo aloittaa. Ilman suunnitelmaa sen vain joutuu yleensä tekemään uudestaan sitten kun on huomattu suunnitelman puuttuminen. Mutta silti, selkeä, käytännöllinen tehtävä prosessissa, tsekkaa mitä meillä nyt oikein on.

Kolmas askel control - allokoi kontrollit ja vastuut oikeisiin paikkoihin. Muutenhan konfiguraatiotieto ei pysy ajan tasalla. Jonkun valvovan mestarin pitää valvoa rakennustyömaatakin, miksei iT-konfiguraatioita? Selkeä ja käytännöllinen toimi taas.

Status accounting, infran tilatiedon ylläpito - niin, olisihan hyvä tietää, onko jokin asia tilattu, toimituksessa, asennuksessa, tuotannossa tai vaikkapa poistumassa. Arvataanko, arvotaanko vai määritellänkö tämä tehtävä ja vastuutetaan se kontrolleihin - joo! Aivan käytännön työ tämäkin.

Viimeiseksi vielä verification & audit, inventaario säännöllisesti tai satunnaisesti. Näin tiedetään, onko omaisuus- ja konfiguraatiolistaus ajan tasalla. Ei tässäkään nyt mitään rakettitiedettä ole.

Mikä siinä nyt oli niin vaikeaa?

Ei tämä minusta kuulosta liian monimutkaiselta. Kirjoista löytyy näihin kaikkiin kohtiin käytännön toimia ja roolikuvauksia, mukaanlukien prosessikuvaukset. Ei niitä kaikkia tarvitse käyttää mutta voipahan sitten tehdä tietoisen päätöksen, mitä jättää käyttämättä tai tekemättä.

Nämä kuvaukset ja mallit auttavat viemään IT-palvelunhallintaa eteenpäin. Sen sijaan, että "tehdään ATK:ta"  vanhaan kunnon käsityötyyliin - "hei, tehdään nyt vaan" - voidaan laatua ja toistettavuutta koota palveluiksi, joissa ihmisten, prosessien ja työkalujen yhdistelmänä hallitaan koko palvelun elinkaarat ideasta kehittämisen ja tuotannon kautta hamaan hautaan asti - hallitusti.

Miksi pitää tehdä palveluita, miksei vaan johdeta IT:tä? Tehdään prosesseja!

Miksi sitten halutaan puhua ITSM:stä eikä vain IT-johtamisesta? Eikös se nyt riitä että kuvataan ja toimitaan prosessien mukaan ja sitten kaikki toimii?

Mitä arvoa prosessit yksin tuovat? Ei, liikemies ei hyödy mitään incident managementista. Liikemies hyötyy paljon siitä, jos tämän prosessin tukemana tuotetaan sitä asiakashallinnan palvelua. Tämä palvelu taas auttaa liikemiehen tuote- ja myyntiprosessia jolla myydään palveluita asiakkaan prosessien tueksi. Näillä prosesseilla asiaksa tuottaa omia palveluitaan jotka ovat arvokkaita tietyn prosessin tuottamiseen...ja niin edelleen. Ärsyttävä ketju kun alat ajatella sitä loppuun asti, eikös? Katsopas alla olevaa kuvaa ja kokeile käytännössä, miten esimerkiksi prosessit ja palvelut kytkeytyvät kun ostat sen tuopposen lähibaarissa...miten pitkälle pääset? Ei, se palveluiden ja prosessien ketju ei lopu panimoon. Kokeile.

Prosessi, palvelu, prosessi, palvelu, prosessi, palvelu, pros...

Monimutkaista, sekavaa, teoreettista?

Niin - monimutkaista ja sekavaa? Matematiikkakin oli sitä minulle, mutta opin silti integroimaan ja derivoimaan. Nyt muistan vain, että integraali oli se S ja niitä voi olla monta peräkkäin. Derivaatta taas oli se D. Helppoa. Osaan siis matikkaa?

Opin myös taidealan nopeasti. Olen insinööri (joo, dipl...;) joten opin asioita nopeasti. Joidenkin ihmisten täytyy opiskella taidetta vuosia. Minä taas sain kaveriltani kirjan "Tunnissa taiteentuntijaksi". Nyt tiedän kaiken ja voin perustellusti sanoa, että Dostojevskin kirjoitustyyli oli aivan liian monimutkaista ja vaikeaa ja sitäpaitsi hän käytti minä-pronominia aivan liian paljon. Vai?

Niin - minusta ITIL on helppoa ja käytännönläheistä mutta olen avannut kirjat ja tutustunut asiaan. Jos ITIL tuntuu abstraktilta tai liian teoreettiselta, kokeilepa lukaista vähän tarkemmin. Siitä voi olla apua!





Template by - Abdul Munir | Daya Earth Blogger Template