Keskisuuren yrityksen tiketöintijärjestelmän käyttöönoton hyödyt ITIL:n näkökulmasta. Susanna Salmi

Keskisuuren yrityksen tiketöintijärjestelmän käyttöönoton hyödyt ITIL:n näkökulmasta Susanna Salmi Opinnäytetyö Tietojenkäsittelyn koulutusohjelma 2016

Tiivistelmä 4.11.2016 Tekijä Susanna Salmi Koulutusohjelma Tietojenkäsittelyn koulutusohjelma Opinnäytetyön nimi Keskisuuren yrityksen tiketöintijärjestelmän käyttöönoton hyödyt ITIL:n näkökulmasta Sivu- ja liitesivumäärä 22 Opinnäytetyön nimi englanniksi Midsized company s implementation of ticketing system benefits by ITIL Tässä tutkimuksessa on tarkoitus selvittää tiketöintijärjestelmän käyttöönoton merkitys, kun se otetaan ensimmäistä kertaa käyttöön keskisuuren yrityksen IT-tuessa. ITIL on merkittävä kokonaisuus parhaita IT-palveluhallinnan käytäntöjä ja sen ymmärtäminen on keskeinen osa tutkimusta. Tutkimuksessa käsitellään ITIL ja sen ydinaiheet palvelustrategia, palvelusuunnittelu, palvelutransitio, palvelutuotanto sekä jatkuva palvelun parantaminen. Palvelutuotanto ja sen prosessit vaikuttavat eniten IT-tuen toiminnassa ja auttavat ohjaamaan sen toimintaa. Sen monet prosessit ovat läheisesti kytköksissä IT-tuen toimintaan ja sen kehittämisessä. Yrityksen IT-tuessa on aikaisemmin käytetty Outlook sähköpostitiliä, jonne tukipyynnöt pääosin tulevat. Muita yhteydenottotapoja olivat puhelin sekä paikalla käyminen. Sähköposti oli kuitenkin merkittävin, ja juuri sen menetelmän tilalle tiketöintijärjestelmä tulisi. Sähköpostimenetelmässä on huomattavia puutteita, jotka tiketöintijärjestelmän arvellaan paikkaavan. Ensinnäkin Outlook-sovellusta ei ole tehty palvelupyyntöjen käsittelyä varten ja on siten siksi puutteellinen IT-tuen toiminnassa. Tulevassa tiketöintijärjestelmä Efectessä on runsaasti helpottavia ja kehittäviä ominaisuuksia, jotka parantavat IT-tuen työskentelyä sekä palvelun laatua. Efectessä ratkaisevin ominaisuus on sen järjestelmä, joka tallentaa ja mahdollistaa IT-tuen toiminnan seurannan. Se avaa ovia palvelun kehittämiseen, mutta auttaa ensisijaisesti IT-tukea ja tiimiä toimimaan dynaamisesti ja tehokkaasti. Tiketöintijärjestelmä on erittäin hyödyllinen, ja yrityksen kasvutahdin huomioiden entinen sähköpostimenetelmä ei pystyisi pitämään palvelutasoa ja tehokkuutta yhtä hyvin yllä kuin nyt. Asiasanat ITIL, IT-tuki, ITIL-prosessit, palvelutuotanto, tiketöintijärjestelmä

Sisällys Lyhenteet ja sanasto... 1 1 Johdanto... 2 2 Tutkimuksen tausta... 4 2.1 Tavoite... 4 2.2 Tutkimuksen rajaus... 4 2.3 Tutkimuskysymykset... 5 2.4 Tutkimusmenetelmä... 5 3 ITIL... 6 3.1 ITIL:n historia... 6 3.2 ITIL ja ISO/IEC 20000-standardi... 7 3.3 ITIL-mallin merkitys ja asema IT-hallinnassa ja yrityksen liiketoiminnassa... 8 4 ITIL IT-palvelujen elinkaarimalli ja ydinosat... 10 4.1 Palvelustrategia... 11 4.2 Palvelusuunnittelu... 11 4.3 Palvelutransitio... 12 4.4 Palvelutuotanto... 13 4.4.1 Palvelupiste... 15 4.5 Jatkuva palvelun parantaminen... 15 5 IT-tuki... 18 5.1 IT-tuen kuvaus... 18 5.2 IT-tuen toiminta... 18 6 Hyödyt ITIL:n näkökulmasta... 20 7 Pohdintaa... 22 Lähteet... 23

Lyhenteet ja sanasto ITIL IT-tuki Tukipyyntö Tiketti Tiketöintijärjestelmä Sovellus IT ICT ISO IEC ISO/IEC 20000 COBIT Elinkaarimalli IT Infrastructure Library; kokoelma parhaiksi todettuja käytäntöjä IT-palvelunhallinnasta IT-yksikkö, joka ottaa vastaan käyttäjien tukipyyntöjä ja minne käyttäjät voivat ottaa vapaasti yhteyttä tietotekniikkaan liittyvissä asioissa Lähituen saama palvelupyyntö käyttäjältä; usein kasvotusten, puhelimella tai sähköpostilla Lähituen tukipyyntö tiketöintijärjestelmässä Sovellus, jossa käyttäjien tukipyynnöt käsitellään ja hallitaan Ohjelma Information Technology, Tietotekniikka Information and Communications Technology, Tieto- ja viestintätekniikka International Standarlization Organisation, Kansainvälinen standardoinnin organisaatio International Electoral Comission, Kansainvälinen sähköalan komissio ISO ja IEC tekemä laatustandardikokoelma Control Objectives for Information and Related Technologies, hyvän tietohallinnan viitekehys ITpalvelujohtamiseen Kaavio, joka sisältää sarjan vaiheita IT-palveluhallinnasta alusta loppuun 1

1 Johdanto ITIL on yksi suosituimmista IT-palvelunhallinnassa käytettävistä kokonaisvaltaisista viitekehyksistä, ja sen nykyisessä versiossa on viisi ydinosaa: palvelustrategia, palvelusuunnittelu, palvelutransitio, palvelutuotanto ja jatkuva palvelun parantaminen. Kokonaisuus on yhtenäinen ja tarjoaa IT-palvelujen elinkaarimallin, mutta yksittäisiä osiakin voi ottaa käyttöön yrityksen tarpeiden ja halujen mukaan. Palvelupiste eli Service Desk, on ITIL:n palvelutransition yksi avaintoiminnoista ja käytännössä siitä vastaa suurimmaksi osaksi IT-tuki. Konkreettisesti IT-tuki mielletään erittäin asiakaspalvelulähtöiseksi ja sen toimintaa yksinkertaiseksi välttämättä ajattelematta tai kyseenalaistamatta toiminnon yksittäisiä funktioita. ITIL:n palvelupiste auttaa ymmärtämään syvemmin yrityksen lähituen palvelutason ja toiminnan. Joka tapauksessa IT-tuki on hyvin paljon asiakaspalvelua, mutta se on myös paljon moniulotteisempaa. Tukipyyntöjen ratkaisujen taustalla vaikuttaa suuresti käytössä olevat menetelmät ja välineet, jotka vaihtelevat suuresti yrityskohtaisesti. Yksi ratkaisu ei toimi kaikissa, ja siksi ITIL auttaa selvittämään ja ottamaan huomioon yrityksen omat kriteerit ja yksilölliset tarpeet. Hieman case-tyyppisesti tässä tutkimuksessa tarkasteltiin erään keskisuuren yrityksen lähitukea ja sen toimintaa. Tähän mennessä yrityksessä IT-tuen tukipyynnöt vastaanotettiin ja hoidettiin puhelimitse, sähköpostilla tai kasvotusten. Yrityksessä ei ollut käytössä tiketöintijärjestelmää, vaan pääpaino oli IT-tiimin yhteisellä sähköpostilla. Tästä syystä onkin mielenkiintoista, miltä osin ITIL:n näkökulmasta lähituen toimintaa olisi syytä parantaa tai muuttaa. Kyseinen yritys aikoi ottaa käyttöön tiketöintijärjestelmän, jonka tarkoitus olisi parantaa lähituen toimintaa sekä palvelun laatua. Lisää tutkimustaustaa ja siihen liittyviä asioita käydään läpi toisessa kappaleessa. Sen jälkeen alkaa teoriaosa, jossa perehdytään tutkimuksen teoriataustan kokonaisuuteen: ITIL-palveluhallinnan viitekehykseen. ITIL on kokoelma parhaita käytäntöjä ITpalvelunhallintaan ja sen merkitys nykyään on kasvanut suuresti. Se on aihepiiriltään erittäin laaja, ja sen sisältö on runsas, joten kappaleessa käydään läpi pääkohdat ITIL:n historiasta ja sen viidestä ydinosasta IT-palveluhallinnan elinkaarimallista. Tarkemmin palvelupistettä ja sen funktiota ITIL-palveluhallinnassa käydään läpi viidennessä kappaleessa. Palvelupiste on ITIL funktio ja se osa yhdistetään yleisesti palvelu- 2

tuontannon vaiheeseen, missä sen rooli on erittäin oleellinen. Tämä palveluhallinnan vaihe on suorasti sovellettavissa konkreettiseen lähituen toimintaan. Kuudes kappale valottaa yrityksen nykyistä lähituen toimintaa ja sen toimintatapoja. Yrityksen IT-tuki oli pääosin toiminut IT-tiimin sähköpostin varassa, ja kappaleessa esitellään toiminnan hyviä ja huonoja puolia. Johtopäätöskappaleessa heijastetaan lähituen nykyistä toimintaa ITIL:n toimintamalliin ja verrataan miltä osin se toteutui tai ei toteutunut. Tutkimuksen päätelmät kootaan tiivistetysti yhteenvetokappaleessa, ja se toimii ikään kuin lopputuloksen tarkasteluna. Tutkimuksen viimeisessä kappaleessa pohditaan mitä ajatuksia tutkimuksen tulokset herättivät. Lähituessa oli tarkoitus ottaa pian käyttöön tiketöintijärjestelmä, jonka potentiaalista vaikutusta käydään läpi ITIL:n näkökulmasta. Myös mahdolliset jatkotutkimusideat tuotiin tässä kappaleessa esille. 3

2 Tutkimuksen tausta Tutkimus lähti liikkeelle yritykselle tulevasta tiketöintiohjelmasta, ja aluksi oli tarkoitus tehdä tutkimus sen käyttöönotosta. Pian mielenkiinto kuitenkin siirtyi enemmän lähituen toimintaan ja tiketöintijärjestelmän vaikutuksiin lähituen arjessa. Lopulta päädyttiin tutkimaan, mitä hyötyjä tiketöintijärjestelmästä olisi yrityksen IT-tuelle. Mukaan otettiin ITIL ja etenkin palvelutuotannon osa-alueen prosessit, jotka toimivat teoriapohjana tutkimukselle. 2.1 Tavoite Tutkimuksen tavoite oli selvittää, miltä osin nykyinen IT-tuen toiminta hyötyy tiketöintijärjestelmästä ja tukeeko sen käyttöönotto ITIL:n ohjeistuksia. ITIL:n palvelutuotanto on laaja kokonaisuus, ja yksi sen toiminallisista osista ja käytännössä toteutuu lähituessa. Lähitukea voi toteuttaa monin eri tavoin ja määritelmin, mutta jos kokonaisvaltaista suunnittelua ei ole, voi sen toiminta olla huomattavan heikkoa. Tutkimuksen tavoite oli auttaa havainnollistamaan kyseisen lähituen vahvuuksia ja heikkouksia, sekä nostaa esille asioita, joihin siinä kuuluu panostaa. Apuna määrittämisessä toimi ITIL-palveluhallinnan viitekehys, joka itsessään on kokoelma parhaita käytäntöjä. Tutkimuksen tuloksena oli siis hahmottaa kokonaisvaltainen kuva toimivasta ja hyvästä lähituesta, joka helpotti sen työntekijöitä työssään ja paransi palvelun laatua. 2.2 Tutkimuksen rajaus Tutkimuksessa perehdyttiin ITIL-palveluhallinnan viitekehyksen malliin ja etenkin palvelutuotannon osaan ja sen toimintoihin. Ne olivat keskeisimpiä aihealueita, joita voidaan soveltaa lähituen toiminnassa. Koko viitekehys käytiin myös pääosilta läpi, sillä tutkimuksen kannalta oli oleellista esitellä kokonaisvaltainen kuva ITIL:stä ja selkeyttää siten lukijalle, miten erityisesti palvelutuotanto ja sen toiminnot sopivat kokonaiskuvaan. ITIL:ssä on muitakin aihealueita, kuten jatkuva palvelun parantaminen, joita voisi pohtia lähituen yhteydessä, joita ei tässä tutkimuksessa ollut tarkoitus käsitellä. ITIL:n palvelutuotannon aihealue riitti tämän tutkimuksen aihealueeksi, sillä se oli merkittävin lähituen kannalta. Tutkimus kattaa myös tarkan kuvauksen yrityksen nykyisestä lähituesta, sillä se on tutkimuksen tärkeä vertailukohta. Tutkimuksessa käydään läpi lähituen funktio yrityksessä, sen tavoitteet, välineet ja velvollisuudet. Lisäksi lopuksi tarkastellaan miten uusi tiketöintijärjestelmä olisi hypoteettisesti vaikuttanut lähituen toimintaan ja sen soveltuvuutta ITIL:n ohjeistuksiin. 4

2.3 Tutkimuskysymykset Tutkimuksen tutkimuskysymykset muovautuivat osittain tutkimusta tehdessä. Aluksi pääpaino oli hieman enemmän tiketöintijärjestelmän kannalla, mutta työn edetessä suunta ja samalla tutkimuskysymykset muovautuivat uudestaan. Lopulta tutkimuskysymykset muovautuivat seuraaviksi: miten hyvin ITIL-palveluhallinnan viitekehystä voi hyödyntää lähituen toiminnassa ja sen kehittämisessä; ja parantaako sen ohjeistukset lähituen työtä ja palvelun laatua. 2.4 Tutkimusmenetelmä Tutkimuksen menetelmä oli tiedonkeruu. Tutkimuksessa etsittiin laajasti aineistoa tukemaan tutkimustuloksia ja johtopäätöksiä. Tiedonkeruumenetelmiä olivat kirja- ja verkkolähteet, joita löytyi runsaasti. Huomattava osa tutkimuksessa kuitenkin kului verkkotuloksien läpikäynnissä, sillä monet yritykset mainostavat ITIL:llä ja siksi vaikeutti hyödyllisen ja käyttökelpoisen tiedon löytämiseen. 5

3 ITIL ITIL on kokoelma IT-palveluiden hallinnan ja johtamisen käytäntöjä. Ensimmäisen kerran ITIL kokoelman kirjoja julkaistiin vuonna 1989 ja siihen viitataan ITILv1 eli ITIL versio numero 1. Siitä lähtien ITIL:istä on julkaistu kaksi muuta versiokokoelmaa vuonna 2000 ITILv2 ja vuonna 2007 ITILv3 (ITIL Service Management 2007). 3.1 ITIL:n historia ITIL tulee sanoista IT Infrastructure Library ja viitekehityksen kehitti silloinen brittiläinen virasto Central Computer and Telecommunications Agency, nykyään Office of Government Commerce Britannian hallituksen ollessa toimeenpanijana (ITIL Certification 2008). Silloinen IT-palvelutaso ei heidän mielestään ollut riittävä, ja IT-palveluiden toimintaa haluttiin paremmin liiketoiminnan tueksi. Tästä ajatuksesta syntyi vuonna 1989 ITILviitekehys, joka on siis kokoelma parhaita käytäntöjä IT-palvelunhallintaan ja johtamiseen. (ITIL central 2005.) Kuva 1. ITIL:n kehityksen aikajana (IT Service Management 2007) Ensimmäisen ITIL-kokoelman kirjoituksia aloitettiin julkaisemaan 1989 ja erillisiä kirjoja julkaistiin yhteensä 31 kappaletta (Cartlidge, Hanna, Rudd, Windebank & Rance 2007, s. 8.). Täten ensimmäinen ITILv1 nimen mukaisesti todella oli kokoelma yksittäisiä kirjoja eri osa-alueilta, ja niitä julkaistiin vuosien 1989-1999 aikana (Kuva 1.). 6

1990-luvulla isot yritykset sekä valtion virastot Euroopassa ottivat ITIL-viitekehyksen nopeasti käyttöön ja se alkoi levitä nopeasti tavallisiin yrityksiin. Suosion laajentuessa ITpalvelut kehittyivät ja muuttuivat, joten myös ITIL-mallia täytyi päivittää. (ITIL Central 2005.) ITILv2 julkaistiin vuonna 2000 (Kuva 1.), joka myöskin koostui yksittäisistä eri kirjoista. ITILv2-kokoelma sisälsi aluksi vain käytäntöjä palvelun tuki- ja toimitus-osa-alueista, mutta myöhemmin kokoelmaan lisättiin käytäntöjä sovellushallinnasta, IT-palveluhallinnan toteuttamisen suunnittelun käyttöönotosta, ICT-infrastruktuurin hallinnasta, ohjelmiston vahvuuden hallinnasta sekä liiketoiminnan näkökulma palvelujen infrastruktuurista. Kokonaisuudessaan ITILv2 noudatti ITILv1 sisältöä muutamaa prosessin muutosta lukuun ottamatta. (ITIL Service Management 2007.) ITILv3 kehitys alkoi vuonna 2004 ja julkaistiin vuonna 2007 (Kuva 1.). ITILv3 tuplasi edelliseen versioon verrattuna aihealueet, melkein triplasi prosessit ja esitteli muutaman uuden näkökulman (ITIL Service Management 2007). Kirjojen lukumäärä myös karsiutui käytännöllisempään viiteen kappaleeseen (ITIL 2014a), jotka toimivat siis ydinkirjoina ITILv3-mallissa. Siinä ryhdyttiin tarkastelemaan IT-palvelujen elinkaarta ja esiteltiin ITpalveluprosessien elinkaarimalli, jossa viisi ydinosaa kirjoja mukaillen olivat palvelustategia, palvelusuunnittelu, palvelutransitio, palvelutuotanto ja jatkuva palvelun parantaminen. Päivitetty versio julkaistiin 2011 ja eri versioihin viitataan nimillä ITIL 2007 ja ITIL 2011. ITILv3:sta alkaen ITIL on tukenut ja täyttänyt ISO/IEC 20000 laatustandardin vaatimukset ja on siis sen kanssa yhteensopiva. (ITIL Central 2005.) 3.2 ITIL ja ISO/IEC 20000-standardi ISO/IEC 20000 standardi on kansainvälinen ja laajasti tunnettu standardi IT-palvelujen hallintaan. Sen on julkaissut ISO ja IEC yhdessä ja se on kansainvälisesti tunnettu ITpalveluhallinnan laatustandardi, joka on käytössä useissa maissa ympäri maailmaa. (20000 Academy 2015.) Standardin kehitys lähti vuonna 1995 nimellä Bristish Standard: BS 15000. Standardi kehitettiin ITIL-kokoelman pohjalta käytännön vaatimusstandardeiksi IT-palvelunhallintaan ja sen prosesseille. Varsinainen ISO/IEC 20000 nimellä kulkeva standardin ensimmäinen version julkaisu tapahtui vasta vuonna 2005 ja se uusittiin 2011 (Kuva 2.). (20000 Academy 2015.) 7

Kuva 2. ISO/IEC kehityksen aikajana (Topalovic, D. 2013.) ISO/IEC 2000 -standardi koostuu 11 luvusta, ja viimeinen luku ISO/IEC 20000-1:2011 käsittelee juuri ISO/IEC 20000 standardin ja ITIL-viitekehyksen suhdetta. Vaikka ISO/IEC 2000 standardi luotiin ITIL:n pohjalta, se ei ole sidottuna ITIL:in vaan se on yhteensopiva monen muunkin IT-palveluhallinnan viitekehyksen kanssa, kuten COBIT (itsmf 2016). 3.3 ITIL-mallin merkitys ja asema IT-hallinnassa ja yrityksen liiketoiminnassa ITIL-viitekehys todettiin pian hyödylliseksi ja tehokkaaksi, ja sen käyttöönotto levisi nopeasti muualle maailmaan (ITIL Central 2005). ITIL:ä käytetään nykyään ympäri maailmaa ja sitä pidetään yhtenä suosituimpana viitekehyksenä IT-palveluhallinnassa. ITIL:n menestystä selittää sen laaja-alaisuus ja kokonaisvaltaisuus. Etenkin 1980-luvulla sellaista ei varsinaisesti ollut olemassa, ja sai osittain siksi myös laajaa menestystä osakseen. Monet organisaation näkevät edelleen IT-palveluhallinnan valtaosin teknisenä asiana, mutta ITIL painottaa enemmän yhteistä, päästä päähän lähestymistapaa ITpalvelunhallinnassa. IT-palvelunhallinnan päähuomio on muuttunut jonkin aikaa ja tulevaisuuden IT-palvelunhallinta tulee olemaan keskittyneempi integroimaan kokonaisvaltaisten liiketoimintahallinnan ja -prosessien tarpeita, jolloin pelkkään tekniseen puoleen keskittyminen vähentyy. Uudet hallintamenetelmät kehittyvät koko ajan ja kehitys tulee myös nopeutumaan, sillä IT-palveluhallinnan hallintastandardit tulevat tarkentumaan koko ajan. Tiivistettynä hallintaprosessi tulee olemaan: - Enemmän liiketoiminnan tarpeisiin keskittymistä - lähempää integraatiota liiketoiminnan prosesseihin - vähemmän riippuvainen tietystä teknologiasta ja enemmän palvelukeskeisyyttä - enemmän toisiin hallintatyökaluihin ja prosesseihin integroitua hallintastandardien kehittyessä. (Cartlidge ym. 2007, 50.) ITIL:stä, kuten monista muistakin, on sertifiointimahdollisuuksia, jotka myös kertovat sen suosiosta. Sertifiointeja on useampia, ja niitä huomioidaan nykyään Suomessakin esimerkiksi työnhakuilmoituksissa tai ylipäätään ITIL-osaamista. ITIL:n ensimmäisen sertifikaatin taso on nimeltään Foundation, joka mahdollistaa yksilön kerryttää pisteitä ITIL V3 kurssei- 8

hin, jotka lopulta johtavat ITIL Diplomiin, kun pisteitä on kertynyt tarpeeksi. Aiempien ITILversioiden sertifikaatteja on myös ollut, ja nykyisen ITIL V3 sertifikaatin saamiseksi edellisistä sertifikaateista saa pisteitä ITIL Diplomia varten. (Cartlidge ym. 2007, 43-44.) 9

4 ITIL IT-palvelujen elinkaarimalli ja ydinosat ITIL 2011 esittelee IT-palvelujen elinkaarimallin, joka sisältää kattavasti ITpalveluhallinnan alusta loppuun. Se koostuu viidestä osa-alueesta, jotka artikkelinimiltään ovat samat kuin ITIL 2007 mallissa. Erona ITIL 2007 malliin ITIL 20011 mallissa on osa-alueiden sisältämiä elinkaarimallin prosesseja (kuva 3.) on lisätty, nimeä muutettu tai vaihdettu toiseen. Käytännössä muutokset ovat siis pieniä täsmennyksiä ja oikaisuja. Sisällön samankaltaisuudesta kertonee sekin, ettei uutta ITIL 2011 -versiota nimetty ITILv4. ITIL:n IT-palveluhallinnan elämänkaarimallia kuvataan tyypillisesti alla olevan mallin tyyliin. Siinä viisi ydinosaa näkyvät selkeästi, ja ne havainnollistavat prosessien kulkua ja niiden yhteyksiä. Kuva 3. ITIL IT-palvelujen elinkaarimalli (ITIL 2014a.) 10

4.1 Palvelustrategia Palvelustrategia (Service Strategy) on elinkaarimallin mukaisesti (kuva 3) prosessien ydin. Tässä osassa neuvotaan miten määritellä yleisimmät strategiat ja lähtökohtana on ajatella asiakkaan näkökulmasta palvelustrategiaa rakentaessa. ITIL:n ajatuksena on, että asiakkaat eivät osta yrityksen tuotteita vaan tiettyjen tarpeiden tyydytystä. Tämän oivallettuaan yrityksen on onnistuakseen nostettava tuotteensa arvoa, jotta asiakas haluaa tavoitella sitä. Tärkeää on myös asiakkaan tarpeiden ymmärtäminen; mitä ne ovat, miksi niitä on ja missä tilanteissa ne syntyvät. Lisäksi täytyy olla myös täsmällinen ja selkeä kuva potentiaalisia tai olemassa olevia asiakkaita. Palveluntarjoajalta vaaditaan myös nykyisisten ja potentiaalisten liiketoiminnan markkinapaikkoihin perehtymistä. (Cartlidge ym 2007, 12.) Palvelustrategian perimmäinen ajatus on siis kehittää strategia, jolla palvella asiakkaita. Palvelustrategia määrittää ohjeistuksen kaikille IT-palvelun tarjoajille ja asiakkaille helpottaakseen niiden toimintaa, ja suuntaa pitkällä aikavälillä rakentamalla selkeä palvelustrategia. Palvelustrategian osion avainprosessit ja toiminnot ovat taloushallinto (Financial Management), palveluportfolion hallinta (Service Portfolio Management) sekä kysynnän hallinta (Demand Management). (Cartlidge ym 2007, 12-17.) Taloushallinnan prosessilla pyritään saamaan taloudellista lähtökohtaa kaikkiin prosesseihin sekä apua investointien hallintaan ja monitorointiin. Palveluportfolion tavoitteena on taas maksimoida liikevaihto minimoimalla liiketoiminnan riskejä IT-palveluhallinnan avulla. Kysynnän hallinnan avulla on tarkoitus määrittää yrityksen tarpeet työskentelemällä läheisesti liiketalouden yksikön kanssa. (ITIL 2014a.) 4.2 Palvelusuunnittelu Palvelusuunnittelu (Service Design) on yksi osa kokonaisvaltaista palvelun elinkaarta ja tärkeä elementti liiketoiminnan muutosprosessissa ja se on vahvasti yhteydessä palvelusuunnittelussa (ITIL 2014a). Palvelusuunnittelun päätavoitteita ovat - suunnitella palveluita, jotka vastaavat hyväksyttyjä liiketoiminta tuloksia - suunnitella prosesseja, jotka tukevat palvelun elinkaarta - tunnistaa ja hallita riskejä - suunnitella turvallinen IT infrastruktuureja, ympäristöjä, ohjelmien ja datan resursseja sekä pystyvyyttä - suunnitella mittausmetodeja ja yksikköjä 11

- tuottaa ja ylläpitää suunnitelmia, prosesseja, käytäntöjä, standardeja, arkkitehtuureja, viitekehyksiä ja dokumentteja tukemaan IT-ratkaisujen laatusuunnittelua - kehittää kykyjä ja mahdollisuuksia IT:n alalla - edistää kokonaisvaltaista parannusta IT-palvelun laadussa. Kokonaisvaltainen näkökulma pitäisi sisällyttää palvelusuunnitteluun varmistaakseen yhtenäisyyden ja integraation kaikissa IT-tapahtumissa ja prosesseissa. (Cartlidge ym. 2007, 18-19.) Palvelusuunnittelun pääprosesseja ovat palveluluettelonhallinta (Service Catalogue Management), palvelutasonhallinta (Service Level Management), kapasiteetinhallinta (Capacity Management), saatavuudenhallinta (Availability Management), IT-palvelun jatkuvuudenhallinta (IT Service Continuity Management), tietoturvan hallinta (Information Security Management) sekä toimittajahallinta (Supplier Management) (Kuva 3.). Palveluluettelohallinnalla varmistetaan, että palveluluettelo luodaan. Prosessilla huolehditaan myös, että palveluluetteloa ylläpidetään ja kaikki siihen liittyvä tieto on täsmällistä ja päivitettyä, jotta palvelu saadaan toimitettua onnistuneesti. Palvelutasonhallinnalla huolehditaan, että palvelujen taso täyttää vaatimukset ja sitä seurataan aktiivisesti, jotta voidaan tarjota aina parempaa palvelua. Kapasiteetinhallinnan avulla optimoidaan ja minimoidaan liiketoiminnan kuluja olemassa olevien resurssien kartoittamisen ja hyödyntämisen avulla (Cartlidge ym. 2007, 20). Saatavuudenhallinnan tarkoituksena on kohdistaa huomiota kaikkeen saatavuuteen ja sen hallintaan. IT-palvelujen jatkuvuudenhallinnan prosessin tavoitteena on ylläpitää IT-palvelujen vikasietoisuutta, jotta sovitut tarpeet, vaatimukset ja aikarajoitukset täyttyvät. Etenkin vikatilanteisiin ja ongelmiin tulisi varautua ennalta. Tietoturvan hallinnan avulla kontrolloidaan tietoturvaa ja varmistetaan, että se kattaa tehokkaasti kaikki prosessit ja palvelut. Toimittajahallinta sisältää kattavasti kaikki toimittajan ja sopimukset, joita tarvitaan palvelun toimeenpanossa. (ITIL 2014a.) Palvelusuunnittelun prosesseja hyödyntämällä lopputuloksena syntyy innovatiivisia ja kunnollisia IT-palveluita, jotka täsmäävät nykyisiin ja tuleviin liiketoiminnan vaatimuksiin (Cartlidge ym. 2007, 18). 4.3 Palvelutransitio Palvelutransition (Service Transition) päätehtävä on aktivoida palvelu eli toimittaa palvelu operatiiviseen käyttöön liiketoiminnan määritelmien mukaisesti. Toimitus tapahtuu vastaanottamalla palvelusuunnittelupaketti palvelusuunnittelun tasolta ja toimittamalla se operatiiviselle tasolle. Mikäli liiketoiminnan olosuhteet, olettamukset tai vaatimukset ovat 12

muuttuneet edellisen suunnitelman jälkeen, palvelutransition tasolla täytyy tehdä muutoksia, jotta vaadittu palvelu voidaan toimittaa. (Cartlidge ym. 2007, 24.) Palvelutransitio keskittyy toteuttamaan kaikkia palvelun osa-alueita kaikissa tilanteissa ja sen täytyy varmistaa, että palvelu voi operoida mahdollisissa epänormaaleissa ja äärimmäisissä tilanteissa. Palvelutransition täytyy pitää huolta, että virheiden tai epäonnistumisien tapahtuessakin palvelua voidaan tukea ja se on siten erittäin vikasietoinen. (Cartlidge ym. 24.) Palvelutransition avainprosesseja ovat muutoksenhallinta (Change Management), palveluomaisuuden- ja konfiguraationhallinta (Service Asset and Configuration Management) sekä tietohallinta (Knowledge Management) (Kuva 3.). Sen lisäksi muita palvelutransition prosesseja ovat transition suunnittelu ja tuki (Transitio Planning and Support), jakelun- ja käyttöönoton hallinta (Release and Deployment Management), palveluiden validointi ja testaus (Service Validation and Testing) sekä evaluointi (Evaluation). (Cartlidge ym. 2007, 25.) Muutoksenhallinnalla varmistetaan, että muutoksiin reagoidaan vaatimusten mukaisesti. Muutoksia luokitellaan kolmeen eri ryhmään: normaali, standardi- ja hätämuutos. Muutoksenhallinnan avulla toimitetaan virheettömämpiä muuttuneita palveluita, kun muutokset saadaan toteutettua nopeammin ja täsmällisemmin. Palveluomaisuuden- ja konfiguraationhallinnan avulla taas huolehditaan, että palvelujen tuottamiseen tarvittavaa palveluomaisuutta hallitaan oikealla tavalla. Tietohallinnan prosessin päämäärä on saada oikealle henkilölle oikea tieto oikealla hetkellä, jotta palvelu olisi tehokkaampaa ja parempaa ja olennainen tieto olisi aina saatavilla. (Cartlidge ym. 2007, 25-27.) 4.4 Palvelutuotanto Palvelutuotannon (Service Operation) tarkoituksena on toimittaa palvelut sopimuksen mukaisella tasolla käyttäjille ja asiakkaille. Sen lisäksi palvelutuotanto hallitsee ohjelmia, teknologiaa ja infrastruktuuria, mitkä tukevat palvelujen toimitusta. Tällä palvelujen elinkaaritasolla vasta palveluiden arvo saatetaan liiketoimintaan ja palvelutuotannosta vastaavien tehtävä on varmistaa, että tämä arvo saadaan toimitettua sinne. Palvelutuotannossa on tärkeää tasapainottaa ristiriitaisia tavoitteita, kuten palvelun laatu vastaan sen hinta tai vakaus vastaan muokkautuvuus. Prosessiin kuuluu myös muutostilojen palautus niin nopeasti kuin mahdollista, jotta voidaan minimoida vaikutukset liiketoiminnassa (ITIL 2004a). Jokaisessa konfliktissa työntekijöiden täytyy ylläpitää tasapainoinen tila, sillä jokaisen osan ylitarkastelu voi johtaa huonoon palveluun. (Cartlidge ym. 2007, 29.) 13

Palvelutuotannon avainprosesseja ovat herätteidenhallinta (Event Management), häiriöhallinta (Incident Management), palvelupyyntöprosessi (Request Fullfilment), pääsyhallinta (Access Management), ongelmahallinta (Problem Management) ja (Kuva 3.). Herätteidenhallinnan prosessi vastaa herätteiden hallinnasta niiden elinkaaren ajan ja on yksi IT-käyttöpalvelun päätoiminnoista. Heräte voi olla määritelty mitattavaksi tai tunnistettavaksi tapahtumaksi, joka on oleellinen IT-infrastruktuurin hallinnan kannalta (ITIL 2014a). Häiriö on suunnittelematon IT-palvelun keskeyttäjä tai IT-palvelun laadun huonontuminen, ja häiriöhallinnalla pyritään palauttamaan normaali palvelun tila niin nopeasti kuin mahdollista, jotta se ei eskaloidu (Cartlidge ym. 2007, 29). IT-tuessa häiriö voisi olla jonkun käyttösovelluksen kaatuminen. Tällöin päätavoite on saada sovellus takaisin toimintaa, ja silloin hyödyllisiä ja vikatilannetta korjaavia toimenpideitä olisi vaikkapa ohjelman uudelleen käynnistys tai vaihtoehtoisen ohjelman asennus. Mikäli tilannetta ei korjata heti, voi asiakkaalle koitua mittavia taloudellisia vahinkoja, jos hänellä on esimerkiksi kiireellinen aikataulu. Ongelma on yhden tai useamman häiriön seuraus, ja usein sen syntymän syytä ei tiedetä, kun se huomataan. Ongelmahallinnan prosessissa tärkeää on ehkäistä ja vähentää häiriöitä eliminoimalla uudelleen esiintyviä häiriöitä sekä minimoimalla ehkäisemättömien häiriöiden vaikutuksia (Cartlidge ym. 2007, 30). Ongelma voisi olla esimerkiksi sovelluksen toimimattomuus usealla henkilöllä ja työalustalla, jolloin usealla asiakkaalla on sama ongelma. Tällöin on tärkeää saada sovellus toimimaan ensin työalustalla, jota suurin osa ongelmallisista käyttäjistä tarvitsee, ja sen jälkeen saada toimimaan muissa. Tärkeysjärjestys on erittäin tärkeää määritellä ja huomata ongelmien syntyessä, jotta vahingot voidaan minimoida. Palvelupyyntö on käyttäjän tekemä pyyntö, ja palvelupyyntöprosessin tarkoitus on mahdollistaa käyttäjälle niiden tekeminen ja avustaa yleisesti, ottaa vastaan valituksia ja kommentteja (Cartldge ym. 2007, 31). Palvelupyynnön ottaa vastaan usein helpdesk eli ITtuen piste ja käytännössä se olisi tiketöintijärjestelmä tai muu vastaava prosessin käsittelijä. Pääsyhallinnan tavoitteena on huolehtia, että tarvittava asia tai tieto on aina saatavilla siihen oikeutetulle käyttäjälle. Samalla se huolehtii, että siihen pääsee käsiksi vain siihen 14

oikeutetut, ja muilta tahoilta estetään (Cartlidge ym. 2007, 32). Käytännössä kuuluu siis huolehtia siitä, että tietoturva ja pääsyoikeudet ovat oikein. 4.4.1 Palvelupiste Palvelutuotannon yksi avainrooleista on palvelupiste (Service Desk), jonne yleensä käyttäjät ottavat yhteyttä häiriöiden sattuessa. Palvelupisteen ratkaiseva käytännön operatiivinen toimija on IT-tukipiste, joka useissa yrityksissä on lähitukea, etätukea tai niiden sekoitusta. Se on merkittävä yrityksen toiminnan kannalta, sillä asiakkaiden vaatimukset ja tarpeet suurenevat koko ajan vaatien myös parempaa asiakaspalvelua. Hyvä asiakaspalvelu on myös ratkaiseva kilpailuetu, ja moni yritys soveltaa ITIL:n palvelupisteen toimintaa. Ilman yhteydenottopistettä, yritys voisi saada suuria taloudellisia tappioita, jos se ei ole tietoinen palveluidensa ongelmista ja valmiuksia korjata niitä (ITIL 2014b). (ITIL News 2016.) Palvelupiste on yhteydenottopiste palvelun loppukäyttäjille, ja sen tarkoitus on pitää lokia, seurata ja hallita kaikkia asioita, joita sinne tulee (ITIL News 2016). 4.5 Jatkuva palvelun parantaminen Jatkuvan palvelun parantamisessa (Continual Service Improvement) on pääkohtana ylläpitää palvelun arvoa asiakkaille jatkuvan kehityksen ohessa ja parantaa palvelujen laatua. Jatkuva palvelun parantaminen yhdistää toimintaperiaatteita, käytäntöjä sekä metodeja laadun sekä muutoksen hallinnasta, jotta tavoitteisiin päästään. Jatkuvan palvelun parantaminen ei ole uusi konsepti, mutta useissa organisaatioissa se jää toteuttamatta, vaikka siitä keskusteltaisiin. Usein aihe tulee ajankohtaiseksi, kun jokin asia on epäonnistunut ja vakavasti vaikuttanut yrityksen liiketoimintaan, mutta unohtuu taas pian, kun asiat on saatu selvitettyä. Yksittäiset ajankohtaiset projektit ovat ymmärrettäviä, mutta tavoitteen saavuttamiseksi jatkuva palvelun parantaminen pitäisi saada osaksi organisaation kulttuuria ja tehdä siitä rutiininomainen tapahtuma. (Cartlidge ym. 2007, 35.) Jatkuvan palvelun parantamisen prosesseja ovat palveluraportointi (Service Reporting) ja 7 vaiheen parannusprosessi (7 Stage Improvement Process). Palveluraportointi 7 vaiheen parannusprosessissa esitellään tarvittavat vaiheet, joilla saadaan kerättyä merkitsevää dataa, analysoitua tuo data ja määritellä siitä trendit ja tapahtumat. Sen jälkeen esitellä tieto hallitukselle heidän hyväksyntää varten ja toteuttaa parannukset (Kuva 4.). (Cartlidge ym. 2007, 36.) 15

Kuva 4. 7 vaiheen parannusprosessi (ITIL 2004a.) Jokaista askelta ajavat strateginen, taktinen ja operatiivinen tavoite, jotka määritellään palvelustrategian ja suunnittelun tasoilla (Cartlidge ym. 2007, 36). Ensimmäisessä vaiheessa määritellään mitä asioita ja määreitä pitäisi mitata, ja ne pitäisi määritellä kokonaisuudessaan tukemaan organisaation tavoitteita. Päähuomio tulisi olla tavoitteiden tyydyttämiseen selvittäminen ja mitä siihen vaaditaan, välittämättä siitä olisiko tarvittavaa resurssia saatavilla. (Cartlidge ym. 2007, 36.) Toisessa vaiheessa tulisi pohtia mitä pystytään mittaamaan, jolloin organisaation täytyy ottaa huomioon sen rajat. Olisi myös hyödyllistä tunnistaa mahdolliset aukot ja riskit, joita voi syntyä lopputuloksen myötä. (Cartlidge ym. 2007, 37.) Kolmannessa vaiheessa kerätään ja seurataan dataa. Tarkoituksena on selvittää tarkkailemalla esimerkiksi miten hyödyllisiä palvelut tai prosessit ovat. Parannuksia voidaan tehdä vasta, kun tiedetään nykyinen palvelun taso, ja siksi tiedon kartuttaminen on tärkeää. Pääpaino on ottaa selvää, mitä asiaa tulee parantaa nykyisessä palvelutasossa tai IT:n toiminnassa. Usein tavoitteen saavuttamiseksi etsitään 16

poikkeavuuksia ja ratkaisuja, mutta niiden tarkkailun lisäksi tulisi huomioida myös sellaisia tilanteita, joissa sovittu palvelutaso on jo saavutettu. Näissä tilanteissa voi miettiä, miten samaa palvelutehoa voitaisiin ylläpitää pienemmillä taloudellisilla kustannuksilla tai milloin se tarvitsee päivityksen jopa uudelle paremmalle tasolle. (Cartlidge ym. 2007, 37.) Neljäs vaihe sisältää datan käsittelyn. Raakadata täytyy muuttaa haluttuun muotoon, ja se on tärkeä vaihe, jota usein vähätellään. Vaikka monitorointi ja datan kerääminen ovat itsessään tärkeitä, datan prosessointi nimenomaan mahdollistaa sen käytön ja näkemään sen vaikutuksen isommassa infrastruktuurissa ja IT-palvelussa. Tässä vaiheessa siis saadaan data hyödynnettävään muotoon, jotta sitä voisi konkreettisesti käyttää. (Cartlidge ym. 2007, 37.) Viidennessä vaiheessa data analysoidaan ja tieto muutetaan käytännölliseen muotoon ja se voidaan ottaa käyttöön tapahtumissa, jotka vaikuttavat organisaatioon. Analysointivaiheessa on hyödyllistä käyttää ohjaavia kysymyksiä, kuten esimerkiksi ollaanko tavoite saavuttamassa tai onko selkeää kausaalista mallia havaittavissa (Kuva 4.). (Cartlidge ym. 2007, 38.) Kuudennessa vaiheessa esitellään ja otetaan käyttöön saatu tieto. Tarkoituksena on esittää se ymmärrettävässä muodossa, jotta sitä hyödyntävät voivat tehdä sen pohjalta strategisia, taktisia ja operatiivisia päätöksiä. On tärkeää, että tuo tieto esitellään oikealla tavalla ja tasolla, jotta vastaanottava taho sen ymmärtää samoin. Etenkin IT-hallinnon tulisi panostaa asiansa konkretisointiin ja selkokielisyyteen esitellessään liiketoiminnan tavoitteita tukevia IT-toiminnallisuuksien tuloksia. Usein liiketoiminnan johto ja IT-hallinto näkevät IT-raporttien eri asiat tärkeinä ja saattavat olla eri mieltä merkitsevistä asioista. IT:n kannattaisi ottaa myös huomioon, että vaikka raportit yleensä painottuvat parannettaviin asioihin ja puutteisiin, kannattaisi myös hyvät uutiset sisällyttää ja kertoa, mitkä asiat ovat onnituneet. (Cartlidge ym. 2007, 38.) Viimeisessä ja seitsemännessä kohdassa otetaan käyttöön parantavat toimenpiteet. Saatua tietoa käytetään optimoimiseen, parantamiseen sekä oikaisemaan palveluita, proseseja ja kaikkia muita teknologiaa tukevia tapahtumia. Nämä palvelua parantavat toimenpiteet täytyy olla määriteltynä ja tiedostettuna koko organisaatiossa. Jatkuva palvelun kehitys prosessin myötä huomataan useita parannuskohtia ja ne täytyy priorisoida yrityksen tavoitteiden, resurssien ja rahoituksen pohjalta. Tämä seitsemän vaiheen prosessi on jatkumo, joka palaa vaiheeseen yksi aina saavutettuaan viimeisen vaiheen loppuun. (Cartlidge ym. 2007, 38.) 17

5 IT-tuki Kappaleessa perehdytään keskisuuren yrityksen nykyiseen IT-tuen toimintaan ja tarkastellaan sen kokonaisuutta. IT-tuen nykyisen järjestelmän ja toiminnan toimivuutta ja heikkouksia arvioitiin lähituen näkökulmasta. 5.1 IT-tuen kuvaus Yrityksen IT-tuki toimi yrityksen sisäisenä IT-tukena yrityksen muille työntekijöille. IT-tukea hoiti pääsääntöisesti kaksi työntekijää täyspäiväisesti ja kolmas IT-tiimin jäsen toimi tarvittaessa tukena. IT-tiimi koostui yhteensä viidestä henkilöstä, jotka kaikki työskentelivät lähituen parissa tarpeen tullen. Yrityksen IT-tuki perustui suuresti IT-tiimin yhteisen Outlook-sähköpostitilin ympärille, joka jaettiin kaikkien ryhmän jäsenten kesken. Sähköpostin lisäksi yhteydenottoja käyttäjiltä tuli puhelimitse ja kasvotusten. Sähköposti oli merkittävin yhteydenottotapa, jonne käyttäjät pystyivät lähettämään kysymyksiä, ongelmia ja pyyntöjä tietotekniikkaan liittyen. IT-tuen puhelinnumeron lisäksi kaikki IT-tiimin jäsenet sai kiinni heidän yksityisistä työnumeroistaan. Tämän lisäksi tiettyinä päivystys aikoina sovittiin ja määriteltiin erikseen kelle tukipyyntöpuhelut ohjautuvat. IT-tuen toimisto sijaitsi samalla alueella muun IT-tiimin kanssa. IT-tuen työntekijät jakoivat yhteisen huoneen, jossa olivat heidän kiinteän työpisteet. Kaikki yrityksen työntekijät pystyivät tavoittamaan IT-tukihenkilöitä käymällä paikan päällä tarvitessaan apua tietoteknisten ongelmien kanssa. IT-tukea tarjottiin pääosin arkisin aamu kahdeksasta ilta viiteen. Tästä syystä täytyi huolehtia, että aina joku IT-tiimin jäsenistä oli toimistolla tavoitettavissa sovittuina aikoina. Tämän lisäksi oli niin sanotusti päivystys aikoja, kun tietty IT-tiimin henkilö oli ennalta sovitusti päätetty vastaanottamaan tukipyyntöjä puhelimitse työajan ulkopuolella. IT-tuen tehtäviin kuului tukipyyntöjen hoitaminen, IT-tarvikkeiden ja laitteiston hankkiminen ja ylläpito sekä käyttäjien ohjeistus ja neuvonta. 5.2 IT-tuen toiminta IT-tuen prosessivaiheet kulkivat yksinkertaisella menetelmällä. Tukipyynnöt otettiin vastaan, selvitettiin ja tarvittaessa eskaloitiin muille IT-tiimin jäsenille. IT-tuessa ei käytetty mitään IT-tuenhallinnan sovellusta, kuten tiketöintijärjestelmää, vaan ainoat dataa kerryt- 18

tävä tapa oli sähköposti. Käyttäjiä eli asiakkaita oli arviolta 270 henkilöä, joten kaksi ITtukihenkilöä pystyi melko hyvin pitämään huolta IT-tuesta, ilman mittavia työkuormia. Toki työn luonne on sellaista, että ongelma ja tukipyyntöjen määriä ei voi etukäteen määritellä ja niiden lukumäärät vaihtelet. Pääosin kaksikon voimavarat riittivät hyvin IT-tuen pyörittämiseen. Sähköpostijärjestelmä toimi melko hyvin, mutta parannettavan varaa oli. Yhteinen postilaatikko aiheutti välillä tilanteita, kun viestejä ja tukipyyntöjä saatettiin poistaa tai siirtää toisen tietämättä tai vahingossa. Sinänsä mitään mittavaa ei välttämättä tuollaisesta seuraa, mutta Outlookin hakutoiminto oli hidas, joten viestien hakemisessa eli tiedonsaannissa saattoi mennä aikansa. Lisäksi jotkut tukipyynnöt saattoivat hautautua muiden alle, jos niitä tuli kerralla runsaasti tai ylipäätään saattoi jäädä huomaamatta. Sähköpostiosoitetta käytettiin yrityksen sisäisen yhteydenotto-osoitteen lisäksi monissa muissa paikoissa, kuten kirjautumissivuilla ja palveluissa. Se toi ylimääräistä ja osittain tarpeetonta viestintää sähköpostitilille. Toki joihinkin viesteihin vaadittiin IT-tuen reagointia, mutta niiden joukossa oli suuresti muuta tarpeetonta tai muulle IT-ryhmäläisille kuuluvaa. IT-tuen yhteisessä sähköpostitilissä oli käytäntö, jossa jokaiselle tiimin jäsenelle oli oma kategoria väri. Tällöin pystyttiin osittain erottamaan omat ja toisten meneillään olevat tehtävät sekä määrittämään kenelle mikäkin tukipyyntö kuului. Tämä järjestely oli käytännössä toimiva, mutta parantamisen varaakin löytyi. Vaarana oli, että viestejä saatettiin merkata väärälle henkilölle tai että väärien merkkausten johdosta niitä ei merkattu kenellekään tai henkilö ei itse huomannut, että olisi tukipyyntö selvitettävänä. Lisäksi yksittäinen kategorisointi saattoi aiheuttaa turhaa selvitysten viivästymistä, koska tiimin jäsenten täytyi aktiivisesti tarkkailla, oliko juuri heille merkattu työpyyntö. Tällöin vasteaika suureni mikä merkitsi huonompaa palvelulaatua. IT-tuessa oli käytössä pienimuotoinen tietopankki, tai kokoelma joistakin tietoteknisten ongelmien ratkaisuista tai menetelmistä. Sinne lisättiin ja päivitettiin ohjeita sitä mukaan, kun niitä päätettiin tehdä, eli systemaattista ylläpitoa ei ollut. Kaikki ohjetiedostot löytyivät yrityksen yhteisestä tietokannasta, minne koko IT-tiimillä oli vapaa pääsy. Samaa sijaintia käytettiin myös muiden IT-asioiden tiedostojen säilytyspaikkana, joten se sisälsi myös sopimuksia, strategiasuunnitelmia ja muuta IT-palvelunhallintaan liittyvää. 19

6 Hyödyt ITIL:n näkökulmasta Yritykseen ollaan ottamassa käyttöön Efecten tiketöintijärjestelmä, joka on ensimmäinen, mitä IT-tuessa on käytetty. IT-tuen asiakasmäärä on kasvanut vasta muutaman vuoden sisällä huomattavalla vauhdilla, joten varsinainen tarve järjestelmälle on tullut vasta viime vuosina. Efecten rooli tulee olemaan merkittävin häiriönhallinnan-prosessissa, koska sen tehtävänä on saada palvelu takaisin toimintaan käyttäjille niin nopeasti kuin mahdollista. Tässä tilanteessa tavoite olisi siis selvittää ongelmatilanteet nopeasti, jotta yrityksen työntekijät pääsevät jatkamaan töitään niin nopeasti kuin mahdollista. ITIL painottaa, että palveluhallinnan lähtökohta on ymmärtää asiakasta ja sen tarpeita. Ja muutenkin korostaa asiakkaan tärkeyttä. Käytännössä Efecten kaltainen tiketöintijärjestelmä otetaan käyttöön juuri sitä ajatellen sekä helpottamaan ja tehostamaan IT-tuen toimintaa. IT-tuessa tulisi olemaan helposti saatavilla tietoa käyttäjistä, edelliset tukipyynnöt sekä vastaavien ongelmatilanteiden ratkaisuja järjestelmän avulla. Efecten myötä tukipyyntöjen seuranta olisi mahdollista ja kaikki lokitietojen ja muiden tietokantojen ylläpito tulisi olemaan helpompaa. Sähköpostinkautta tulevat tukipyynnöt tallentuisivat järjestelmään automaattisesti, ja puheluiden sekä paikalla käynnit voitaisiin itse luoda tarpeen mukaan. Efectessä olisi mahdollista kirjata tukipyynnöt ja niiden selvitysvaiheet yksityiskohtaisesti, jolloin tieto tulisi olemaan jatkossakin saatavilla tarvittaessa. Onnistunut kirjanpito auttaisi merkittävästi hiljaisen tiedon vähentämisessä ja mahdollisesti korvaisi osittain ohjekirjojen merkityksen positiivisessa mielessä. Toistuvien häiriötilanteiden kohdalla tämä ominaisuus olisi erityisen tärkeää, sillä se pienentää merkittävästi IT-tuen työn määrää tapausten kohdalla. Mitä paremmin pystyttäisiin hyödyntämään aiemmin todettuja häiriöitä ja niiden ratkaisuja, sitä paremmin saavutettaisiin asiakkaan tyytyväisyys. IT-tuessa se merkitsisi dynaamista, tehokasta ja nopeaa tukipyyntöjen ratkaisua. Tiketöintijärjestelmän avulla toistuvat häiriöt eli ongelmat ovat myös helpommin havaittavissa. Lisäksi se auttaa työmäärien kehityksen seuraamista ja resurssien hallinnointia. Sen mukaan IT-tuelle voitaisiin määritellä esimerkiksi uudet palveluajat vastaamaan paremmin kysyntää, jos tukipyyntöjä olisi enemmän tiettyyn aikaan pitkäaikaisseurannassa. Osittain pystyttäisiin myös ennakoimaan häiriötilanteita, kun vanhaa tietoa voidaan käyttää hyväksi ja on mahdollista tehdä johtopäätöksiä eri tapauksista. Kaikki tämä olisi tike- 20

töintijärjestelmän edellyttämää, sillä nykyisellä sähköpostipohjaisella menetelmällä se on mahdotonta. Toki viestejä voisi tallentaa ja lajitella paremmin tapausten mukaan, mutta hakuominaisuudet ovat surkeat ja tekisivät menetelmästä hitaan ja käytännössä hyödyttömän. Lisäksi sähköpostilaatikon tila toisi omat haastavuutensa menetelmän hyödyntämiseen. Tilin kokoa on mahdollista kasvattaa, mutta käytännössä se kasvaisi vuosien mittaan monen gigatavun kokoiseksi. Silloinkin sen datamäärä olisi hyvin haastava ohjelman toiminnalle, koska sitä ei ensikädessä ole kyseiseen tarkoitukseen luotu. Efectellä on myös mahdollista luoda tallennetusta datasta taulukoita ja osoittaa konkreettisesti IT-tuen toiminnan merkitystä yrityksen johtoryhmälle. Tällöin IT-tiimin on mahdollista saada tarvittavia resursseja paremmin käyttöönsä, mikä puolestaan taas kehittää ja parantaa palvelunlaatua. 21

7 Pohdintaa Efecte auttaa parantamaan palveluntasoa ja laatua, jolloin asiakkaat ovat myös tyytyväisempiä. Sen lisäksi se tuo uusia hyviä ominaisuuksia IT-tuen työskentelyyn ja toimii työskentelyn apuvälineenä. Merkittävin tulos lienee paremmin organisoitu ja dynaaminen ITtuen toiminta, jota ei ennen ohjelman käyttöönottoa ollut. Efecten myötä moni IT-tuen toiminta helpottuu ja täten vaikuttaa positiivisesti niin tuen toimintaan kuin asiakkaiden palvelukokemukseen. Efecten myötä on mahdollista kehittää IT-tukea ja sen palveluita, kun tietoa ja dataa tallentuu jatkuvasti. Efecten huono puoli verrattuna Outlook-sähköpostiin on sen hinta ja totuttelu. Selvää silti on, ettei sähköpostimenetelmä tule riittämään pidemmällä aikavälillä, jos yritys jatkaa kasvuaan. Siksi tiketöintijärjestelmä tulisi olemaan jossain vaiheessa pakollinen kokonaisvaltaisen IT-strategian ja palveluhallinnan kannalta, ja mitä aiemmin järjestelmään totutaan, sitä helpommin se sulautuu käyttöön. Efecte valikoitui myös yrityksen kilpailutuksen perusteella hinta-laatusuhteiltaan käyttöönotettavaksi järjestelmäksi, joten se ei ole markkinoiden kalleimpia. Toki kustannukset ovat suuremmat sähköpostimenetelmää ajatellen, mutta pitkällä aikavälillä Efecten tukipyyntöjen ja tapahtumien seurantaominaisuus voivat auttaa huomaamaan kustannuksien säästöpaikkoja ja kehitysmahdollisuuksia. Totta kai tehokkaampi järjestelmä kuormittaa vähemmän IT-tukihenkilöä, jolloin on mahdollista pärjätä pienemmällä määrällä työntekijöitä, vaikka asiakkaita tulisi lisää. Efecten avulla IT-tuki toimii dynaamisemmin ja mahdollistaa siten parempaa palvelua ja asiakkaiden tyytyväisyyttä. Hyvin toimiva ja tehokas helpdesk pitää organisaation ITinfrastruktuurin sujuvana, antaen henkilöstön keskittyä olennaisiin työtehtäviin palveluiden toimiessa odotusten mukaisesti. Efecten tiketöintijärjestelmä ei ainoastaan toimisi työkaluna, joka mahdollistaa IT-tuelle tehokkaan toiminnan, vaan se tukisi myös positiivisen palvelukulttuurin kehittämistä. 22

Lähteet 20000 Academy 2016. Difference from ITIL. Saatavissa: http://advisera.com/20000academy/what-is-iso-20000/?icn=free-what-is-iso- 20000&ici=top-iso-20000-txt Luettu 10.11.2016 Cartlidge, A., Hanna, A., Rudd, C., Windebank, J. & Rance, S. 2007. An Introductory Overview of ITIL V3. The UK Chapter of the itsmf. UK. Luettu 7.11.2016 ITIL 2014a. ITILv3. Saatavissa: https://itil2014.wordpress.com/2014/05/08/itil-v3/ Luettu 26.11.2016 ITIL 2014b. ITIL. Saatavissa: http://www.itil.org.uk/sm-why.htm Luettu 29.11.2016 ITIL Central 2005. In a Nutshell: A Short History of ITIL. Saatavissa: http://itsm.fwtk.org/history.htm Luettu 7.11.2016 ITIL Certification 2008. ITIL Overview. Saatavissa: http://www.itilcertification.org/ Luettu 7.11.2016 ITIL News 2016. Service Desk Overview. Saatavissa: http://www.itilnews.com/index.php?pagename=service_support_service_desk Luettu: 29.11.2016 ITIL Service Management 2007. A Brief History of ITIL. Saatavissa: http://itservicemngmt.blogspot.fi/2007/09/brief-history-of-itil.html Luettu 7.11.2016 itsmf 2016. COBIT. Saatavissa: http://vanha.itsmf.fi/cobit Luettu: 26.11.2016 Major-Goldsmith, M. 2016. Choosing the best Service Management framework for the Business. Saatavissa: http://allthingsitsm.com/choosing-the-best-service-management-framework/ Luettu 11.11.2016 Topalovic, D. 2013. ITIL and ISO/IEC 20000 History: Parellel Worlds. Saatavissa 23

http://advisera.com/20000academy/blog/2013/05/01/itil-isoiec-20000-history-parallelworlds/ Luettu 9.11.2016 24