torstai 26. helmikuuta 2009

Tietotekniikan tuotantoa

Kävin mielenkiintoisen keskustelun erään TKK:n professorin kanssa alkuviikosta. Löysin jälleen yhden kiusattavan tämän IT-palvelunhallinnan koulutuksen tiimoilta, enkä tällä kertaa ollut enää edes ensimmäinen! Asia tuntuu kiinnostavan jo muitakin.

Keskustelimme siitä, pitäisikö korkeakoulutasolla opettaa tietotekniikan tuotantoa. Tietotekniikan opetushan alkoi TKK:lla vuonna 1986 ja oli aluksi hyvin pitkälti sähkötekniikan osaston ohjauksessa. Senkin takia se on suuntautunut hyvin pitkälti ohjelmointiin ja sähköteknismäiseen tarkkaan kolvaamiseen, bitin vääntelyyn.

Muutaman viime vuoden aikana on perustettu tietenkin hyviä hankkeita, SoberIT ja Software business tähtäävät menestyvän ohjelmistoliiketoiminnan perustamiseen ja johtamiseen. Kyseessä on kuitenkin aivan eri asia kuin tämä päivittäinen tuska, IT-palvelutuotanto.

Kävimme keskustelun aikana läpi muutkin TKK:n osastot. Kaikilla muilla osastoilla opetetaan tuotantoa - rakennustekniikassa, kemiassa, sähkölläkin ja erityisesti konetekniikassa. Tietotekniikasta se puuttuu.

Viittasin jo aiemmin Aalto-yliopiston tuomiin mahdollisuuksiin. Uusi rehtori astuu remmiin 1.4. ja alkaa organisoida toimintaa, varsinainen tsunami tulee sitten 2010 alussa. Kauppakorkean puolella professori Dahlbergilla on jotain IT governance -aiheita hallussaan, mutta kyllähän nyt IT-johtajilla pitää olla jonkinlainen tekninen osaaminen - siksikin pidän TKK:ta oikeana paikkana tälle koulutukselle!

No, jatketaan puskemista vaikka sitten Aallon harjalla - toivottavasti yhtä menestyksekkäästi kuin tuossa alla olevassa aallossa kävi.



Aaltolentoa purjekoneella Kebnekaisella 2007 - tällä aallolla pääsi yli 6 km korkeuteen.

torstai 12. helmikuuta 2009

Wanted: PROBLEM MANAGER

Eräässä keskustelussa tuli esiin se, millaisia haasteita ITIL-managerien nimittämisessä/valinnassa tulee vastaan. Kysymys tuli hieman yllättäen, ja ensimmäisenä mieleeni tuli vain se yleisin käsitys - ITILin myötä tarvitaan paljon uusia ihmisiä managerien paikalle. Eihän asia näin ole, vaan kyseessä on vastuutus ja roolitus - sama henkilö voi toimia monen prosessin valtiaana.

Käytännön haasteitakin on tullut vastaan. Yleisiä ominaisuuksia näille ITIL incident-problem-change-configuration-whatnot managereille kyllä löytyy:

- tuntevat hyvin organisaation ja henkilöiden kompetenssit
- voivat hierarkisen positionsa pohjalta vaikuttaa resursointiin
- ovat toimialan ja tietotekniikan ammattilaisia
- tuntevat ITIL-kehyksen ja omaan alueeseensa liittyvät prosessit

Tuo hierarkinen positio tarkoittaa myös sitä, että nimensä mukaan managerin rooli on managerointia. Yleensä se tarkoittaa töiden jakamista, resurssien nimeämistä ja hankkimista, johtamista! Olen nähnyt yrityksiä nimittää linjasta ihmisiä tekemään "tätä change managerin hommaa kun sehän nyt on vain pieni lisä.." mutta ei asiantuntijalla ole sitä resursointi- ja johtamisvaltaa, joka näihin tehtäviin tarvitaan.

Tässäpä yksi quick&dirty ehdotus siitä, miten nuo roolit voisi organisaatiossa jakaa:

Incident Manager
Yleensä Service deskin vetäjä, mutta voisi olla kokenut SD-asiantuntijakin. Vastaa prosessin sujuvuudesta, joskus myös töiden jonotuksista, priorisointien toimivuudesta ja trendiseurannasta niin, että Problem Managerillekin löytyy hommia. Vastaa monesti samalla Request Fulfillment -prosessista ja on yleensä aika hyperaktiivinen ihminen. Pohjois-Karjalasta.

Problem Manager
Kuin viilipytty, harkitseva seniorimanageri sieltä verkko/palvelin/mainframe-tiimistä joka tuntee ihmiset ja organisaation kuin omat taskunsa. Tuntee Infrastruktuurin niin, että osaa tunnistaa allokoida ongelmatutkintaa oikeisiin ryhmiin. Pystyy keskustelemaan ja viestimään kollegojen kanssa niin, että ongelmanhallinta toimii ja prioriteetit pysyvät hallussa. Juttelee Incident Managerin kanssa aktiivisesti, seuraa itsekin trendejä ja tekee perusteltuja muutospyyntöjä Change Managerille, joka joskus saattaa istua samalla tuolilla. Pohjanmaalta

Change Manager
Kova puurtaja viemään asioita läpi, osaa myös sanoa EI kun joku haluaa välttämättä jatkossa punaisia työasemia. Seuraa muutosten kulkua, allokoi niitä oikeisiin ryhmiin ja pitää huolta laadukkaasta toiminnasta. Monesti kokenut infra-yksikön päällikkö, muutokset kun vaativat resursointia nekin. Saattaa olla hyvin läheinen Problem- tai Configuration Managerin kanssa. Asikkalasta.

Configuration Manager
Järjestelmällinen ja pitkäjänteinen ihminen, kova kokemus IT-infran hallinnasta. Tähän toimeen sopii hyvin kokenut asiantuntija, IT-arkkitehti. Portinvartija ja vahtikoira, CMDB:n on pysyttävä ajan tasalla. Saksasta.

Nämä esimerkit ovat suoraan käytännöstä ja hyvin konkreettisia. Muitakin managereita ja vastuita tietenkin on.

Design-puolella on paljon alueita, joiden vastuut voivat hyvinkin löytyä infran ylläpidon tai kehityksen henkilöstöstä. Transition vastuut kolahtavat joskus jopa projekteille, vaikka prosessituki olisi syytä pitää stabiilina. Operaatioita manageroidaan valvontahuoneessa ja jatkuvaa kehitystä potkitaan kaikkien ryhmäpäälliköiden bonustavoitteilla. Strategiapuolella vastuut ovat paljon hallinnollisella puolella, CIO:lla ja talousjohtajalla/kontrollerilla.

Iso kasa hattuja, ei niille välttämättä tarvita yhtää montaa päätä. Voihan niitä hattuja vaihdella. Se vanha suomalainen sananlasku "Kahta en vaihda..." - sehän viittaa sukkiin.


Sukat

sunnuntai 8. helmikuuta 2009

Missä järjestyksessä CMDB rakentuu parhaiten?

Vaihdoimme tuossa kollegan kanssa hiljattain ajatuksia CMDB:stä. Tämä taikakaluhan on ollut ilonamme jo vuosia, kun se ITILin kakkosversiossa lanseerattiin ajatuksena. Käytäntö on ruhjonut konseptia eteenpäin ja nykyään ITILikin tietää, että yleensä näitä tietokantoja on useampia ja niistä koostuu CMS, Configuration Management System.

Mitä sinne sitten pitäisi laittaa? Mistä olisi eniten hyötyä?

Monestihan CMDB:n populointi alkaa työasemista. Hankitaan Discovery, joka syöttää tietoa pienellä vaivalla CMDB:hen. Työmäärä on melkoinen mutta työasemien ikä, malli, softat jne. löytyvät sitten helposti eri ITSM-työkaluista. Tästähän hyödytään Service Deskissä paljonkin - totta.

Kokonaisuuden kannalta hyöty jää kuitenkin aika laimeaksi. Tietenkin tällä avustetaan Incident Managementia ja ehkä jonkin verran rahojenkin laskentaa, mutta IT-palvelunhallinnan kannalta fiksumpaa olisi ajatella palveluita.

Aluksi voidaan ottaa vaikkapa vain yksi kappale liiketoiminnan kannalta kriittisiä palveluita ja mallintaa se CMDB:hen. Näin helpotetaan insidenttien ja muutosten hallintaa paljon enemmän kuin tietämällä, mikä työasema työntekijällä kulloinkin on käytössään. Toinen ja kolmas palvelu ovatkin jo paljon helpompia, jossain vaiheessa tulee jo rajakin vastaan - mitä kaikkea sinne CMDB:hen edes viedään. Tämä on syytä päättää hallitusti, kaikkea sinne ei tarvita.

Toki työasemat ja jopa matkapuhelimet - ne pikkuiset tietokoneet siellä rintataskussa - kannattaa viedä ajan mittaan CMDB:hen, mutta 80% hyödystä saavutetaan 20% vaivalla mallintamalla ensin palvelut sinne tietokantaan. Lisenssienhallinnan ja auditointien kannalta tehokkaampi tapa saattaa olla jopa käyttää sitä Discovery-työkalujen omaa raportointia sen sijaan että kaikki tieto olisi CMDB:ssä.

Silti, CMDB on hieno juttu. Aikanaan koulutin lentokenttäsimulla erään suurehkon (n. 56000 työntekijää) serveritiimiä. Yksi osallistujista - ainoita, joilta olen saanut ko. koulutuksesta negatiivista palautetta - tuli yrmeänä simulaation jälkeen antamaan palautetta. "Minä en kyllä usko lainkaan siihen, että tällaisilla leikeillä mitään oikeasti oppisi. No, ymmräsinhän kuitenkin lopultakin, mitä se CMDB käytännössä tarkoittaa!". Kaveri oli työskennellyt luolassa jo 70-luvulta lähtien ja oli kyllä muuten hyvä tyyppi, ei vaan tykännyt leikeistä!



Mainittu CMDB-tiimi työssään

perjantai 6. helmikuuta 2009

ITIL-keskustelua suomeksi Linkedinissä

Loin Linkediniin (www.linkedin.com) ryhmän suomenkieliselle ITIL-keskustelulle. Ryhmän nimi on innovatiivisesti ITIL Suomi - tervetuloa mukaan keskusteluun!

Tänään ryhmässä on jo 58 jäsentä, keskustelukin on lähtenyt käyntiin!

http://www.linkedin.com/groups?gid=1767747

tiistai 3. helmikuuta 2009

v2 hiipuu mutta hitaasti

Epätietoisuuden lopettamiseksi kirjoitin APMG:lle ja pyysin lisätietoa v2:n lopettamisaikataulusta. Muista ITIL-keskusteluista olen bongaillut tilannetta muualla maailmassa, ja kypsyystaso tosiaan on kovin erilainen. Joissain kehittyvissä maissa jopa kielisyys on merkittävä asia, koska englantia ei osata - tämä lienee tilanne varsinkin ranskankielisessä Afrikassa.

Sain APMG:tä ympäripyöreän vastauksen. Ainoa päätös tällä hetkellä on se, että tenttien lopettamisesta tiedotetaan 6 kuukautta etukäteen ja kirjojen poistamisesta 4 kuukautta ennen opetuspäivää. Foundation-tentit lopetataan ensin, sen jälkeen Practitioner- ja Service Manager -tentit. Sen jälkeen bridge-kurssien lakkauttamisaikataulut päätetään tilanteen mukaan.

Asiaan vaikuttaa paljon eri maiden itSMF:ien tekemät suositukset. Suomessahan tilanne on siinä mielessä hyvä, että lähes kaikki tunnistavat v3:n, 14% käytti sitä jo kehyksenä ja 56% aikoi kehittää prosesseja sen mukaan. Lausuntoja pyydetään varmaan lähitulevaisuudessa, Suomen valmius tässä asiassa on erinomainen.

Näen ITILv3:n antavan paljon kilpailuetua palveluntarjoajille ja -yksiköille. Palvelun elinkaariajattelu tuntuu paljon fiksummalta kuin yksittäisiin prosesseihin keskittyminen, vaikka käytännössä mennäänkin prosessi kerrallaan. Ei anneta puiden peittää metsää.

Tässä voisi nyt olla sauma käyttää tämä kilpailuetu ensilinjassa - palvelulähtöinen ajattelu auttaa keskittymään oikeisiin asioihin. Käytännössähän uusi versio näkyy vain siinä, että Incident Managementin sijaan ensimmäisenä käydäänkin Service Cataloguen kimppuun.

Keskustelimme muuten eilen kollegan kanssa pitkään mielenkiintoisesta aiheesta - "Mitä hyötyä on siitä, että työasema on CMDB:ssä". Tästä varmaan seuraavana.

Template by - Abdul Munir | Daya Earth Blogger Template