Prosessin yleiskatsaus: Häiriönhallinta
Prosessin yleiskatsaus: Häiriönhallinta
Prosessin yleiskatsaus: Häiriönhallinta
Yhteenveto
Häiriönhallinta on IT-palveluhallinnan (ITSM) prosessi, joka keskittyy ensisijaisesti häiriöiden aiheuttamien IT-palveluiden nopeaan palauttamiseen. Näihin häiriöihin voi kuulua mikä tahansa suunnittelematon keskeytys tai IT-palveluiden laadun heikkeneminen, joka voi vaikuttaa yrityksen päivittäiseen toimintaan.
Häiriönhallinnalla on keskeinen rooli käyttökatkojen minimoimisessa ja IT-palveluiden luotettavuuden ylläpitämisessä. Jäsennellyn ja tehokkaan häiriönhallintaprosessin avulla yritykset voivat varmistaa toimintansa mahdollisimman vähäisen häiriintymisen ja ylläpitää korkeaa palvelun laatua asiakkailleen. Se auttaa myös ymmärtämään IT-infrastruktuuria paremmin, mikä auttaa tunnistamaan malleja ja trendejä, jotka voivat johtaa ennakoivampaan hallintaan tulevaisuudessa.
Käyttötapaukset
Prosessi sisältää seuraavat ylätason käyttötapaukset. Näiden käyttötapausten kuvaukset löytyvät niiden omilta sivuiltaan, joihin pääsee alla olevien linkkien kautta. Nämä omat sivut käsittelevät syvällisemmin kunkin käyttötapauksen esimerkkiskenaarioita, työnkulkuja, tuloksia ja hyötyjä, tarjoten yksityiskohtaisemman kuvan niiden roolista häiriönhallinnan elinkaaressa.
Käyttötapauskaavio
Syöttökanavat
Oletusarvoisesti järjestelmä luo tikettikortteja häiriöille seuraavien ensisijaisten menetelmien kautta:
- Itsepalvelu: Loppukäyttäjät voivat luoda häiriöitä itsepalvelun kautta täyttämällä häiriölomakkeen.
- Sähköpostipohjainen: Loppukäyttäjät voivat luoda häiriöitä lähettämällä sähköpostia palvelupisteen sähköpostiosoitteeseen. Sähköpostin sisältö, mukaan lukien liitteet, täytetään tikettikortille.
- Manuaalinen ilmoittaminen: Puhelimitse tai paikan päällä palvelupisteellä ilmoitetuille häiriöille palvelupisteemme henkilöstö luo tikettikortit manuaalisesti tarkan dokumentoinnin varmistamiseksi.
- Chat-integraatio: Integroitujen chat-alustojen kautta ilmoitetut häiriöt muunnetaan automaattisesti tikettikorteiksi. Tämä sisältää olennaisten tietojen poimimisen chat-keskustelusta, mikä luo saumattoman häiriöiden ilmoitusprosessin. Ei sisälly oletustoimitukseen.
- Teams-integraatio: Microsoft Teamsin kautta ilmoitetuille häiriöille järjestelmämme hyödyntää integraatio-ominaisuuksia luodakseen automaattisesti tikettikortin ilmoitetusta ongelmasta, varmistaen kattavan häiriöiden kirjaamisen. Ei sisälly oletustoimitukseen.
Prosessin aikajana
Häiriönhallintaprosessin aikajana on kuvattu alla olevassa kuvassa. Prosessi mittaa ja tallentaa useita tilastoja kullekin häiriölle, mikä on kriittistä palveluidemme suorituskyvyn arvioinnissa ja kehityskohteiden tunnistamisessa. Näistä tilastoista keskeisimpiä ovat:
Vasteaika: Tämä on aika häiriön ilmoittamisen tai havaitsemisen ja tukihenkilöstön kuittauksen välillä. Tämä mittari auttaa arvioimaan palvelupisteemme ketteryyttä ja tehokkuuttamme häiriönhallintaprosessin käynnistämisessä.
Ratkaisuaika: Tämä mittari tallentaa ajan, joka kuluu häiriön kuittaamisesta sen ratkaisemiseen, pois lukien mahdollinen tauolla oloaika. Se arvioi tukihenkilöstömme tehokkuutta häiriöiden vianmäärityksessä ja ratkaisemisessa.
Kokonaisratkaisuaika: Tämä on aika häiriön ilmoittamisesta sen ratkaisemiseen, mukaan lukien mahdollinen tauolla oloaika. Se antaa kokonaiskuvan siitä, kuinka kauan häiriön täydellinen ratkaiseminen kestää käyttäjän näkökulmasta.
Kokonaiskäsittelyaika: Tämä tarkoittaa tukihenkilöstön häiriön parissa käyttämää todellista työaikaa. Se on keskeinen mittari häiriön ratkaisemiseen tarvittavasta työvoimasta ja auttaa resurssien kohdentamisessa.
Automaattiset sähköposti-ilmoitukset
Ratkaisu lähettää ennalta määriteltyjä sähköposti-ilmoituksia. Pääkäyttäjä voi muuttaa sähköposti-ilmoitusten sisältöä. Tarvittaessa tiketin vastuuhenkilöt voivat poistaa käytöstä heille lähetettävät sähköposti-ilmoitukset muokkaamalla henkilökorttiaan. Seuraavassa taulukossa esitellään häiriönhallintaprosessiin liittyvät automaattiset sähköposti-ilmoitukset.
Automaattiset sähköposti-ilmoitukset lähetetään käyttäen Efecte Service Management Toolin tapahtumia (Events). Sähköpostien sisältö kuitenkin määritellään E-mail notification -tietokorteilla. Sähköpostit lähetetään lyhyellä viiveellä (~1 minuutti) tapahtuman jälkeen.
| # | Ilmoituksen nimi | Lähettäjän osoite | Vastaanottaja | Lähetetään, kun |
|---|---|---|---|---|
| 1 | Tiketti luotu | [asiakkaan määrittämä] | Asiakas | Kun tiketti on luotu |
| 2 | Tiketin tiimi vaihdettu | [asiakkaan määrittämä] | Tiimin jäsenet, joille tiketti osoitettiin | Kun tiimi on vaihdettu |
| 3 | Tiketin SLA-määräaika lähestyy | [asiakkaan määrittämä] | Tiimin jonon vastuuhenkilö | Viisi tuntia ennen tavoiteratkaisuaikaa |
| 4 | Uusi sähköposti saapunut tikettiin | [asiakkaan määrittämä] | Vastuuhenkilö | Kun uusi sähköposti on saapunut tikettiin |
| 5 | Asiakas lisää kommentin itsepalvelusta | [asiakkaan määrittämä] | Vastuuhenkilö | Kun asiakas on lisännyt kommentin |
| 6 | Tiketin vastuuhenkilö vaihdettu | [asiakkaan määrittämä] | Uusi vastuuhenkilö | Kun vastuuhenkilö on vaihdettu |
| 7 | Vastuuhenkilö lisää kommentin itsepalveluun | [asiakkaan määrittämä] | Asiakas | Kun kommentti on lisätty |
| 8 | Tehtävä osoitettu | [asiakkaan määrittämä] | Vastuuhenkilö | Kun tehtävä on osoitettu |
| 9 | Tiketti on ratkaistu | [asiakkaan määrittämä] | Asiakas | Kun tiketti on ratkaistu |
Sanasto
| Termi | Selitys |
| Eskalointi | Prosessi, jossa häiriö tai palvelupyyntö ohjataan korkeamman tason tukeen, kun ensimmäisen tason tuki ei pysty ratkaisemaan ongelmaa määrätyssä ajassa tai sillä ei ole tarvittavaa asiantuntemusta tai resursseja ongelman ratkaisemiseksi. |
| Häiriönhallinta | Häiriönhallinnan tarkoituksena on minimoida häiriöiden negatiivinen vaikutus palauttamalla normaali palvelutoiminta mahdollisimman nopeasti. |
| Häiriö | Suunnittelematon palvelun keskeytys tai palvelun laadun heikkeneminen. |
| Tavoitevasteaika | Enimmäisaika, jonka kuluessa tukitiimi pyrkii vastaamaan häiriöön tai palvelupyyntöön sen jälkeen, kun käyttäjä on ilmoittanut siitä. |
| Tavoiteratkaisuaika | Enimmäisaika, jonka kuluessa tukitiimi pyrkii ratkaisemaan häiriön tai palvelupyynnön sen jälkeen, kun käyttäjä on ilmoittanut siitä. |
| Tiketti | Palveluhallintatyökalun tietokortti, joka edustaa häiriötä, palvelutilausta tai tietopyyntöä. |
| Prioriteetti | Häiriölle tai palvelupyynnölle annettu tärkeys- ja kiireellisyystaso, joka perustuu sen vaikutukseen liiketoimintaan ja vaadittuun ratkaisuaikaan. |
| Quickfill | Ominaisuus, jonka avulla käyttäjät voivat täyttää nopeasti ja helposti yleisiä tai usein käytettyjä kenttiä luodessaan uutta tikettiä, häiriötä tai palvelupyyntöä. |
| Palvelutasosopimus | Palvelutasosopimus (SLA) on virallisesti sovittu suorituskyvyn tai palvelun laadun taso. SLA:ta edustaa Service level -tietokortti palveluhallintatyökalussa. |
| Tietämyskannan artikkeli | Dokumentaatioresurssi, joka tarjoaa tietoa yleisten häiriöiden tai palvelupyyntöjen ratkaisemisesta. Artikkelit sisältävät vaiheittaisia ohjeita, kuvakaappauksia ja muuta olennaista tietoa, jotka voivat auttaa käyttäjiä ratkaisemaan ongelmansa itsenäisesti ilman tukitiimin lisäapua. |
Edellytykset
-
Viestintäkanavat
- Pakollinen: Sähköpostiintegraatio sähköpostien vastaanottamiseksi tiketteinä ja sähköpostien lähettämiseksi asiakkaille.
- Lisäosat: Efecte Chat, Teams-integraatio
-
Tukimalli
- Tukimalli ja tukiryhmärakenne, mukaan lukien kunkin tukiryhmän jäsenet, tulee määritellä.
-
Perustiedot
- Luokittelujärjestelmä häiriöiden luokitteluun. Luokittelun tulee perustua palveluluetteloon.
- Palvelutasosopimukset
- Valmiina saatavilla olevaa oletuspalvelutasosopimuksen tietokorttia voidaan käyttää, jos palvelutasomäärityksiä ei ole. On aina suositeltavaa käyttää vähintään oletuspalvelutasoa, koska se auttaa keräämään arvokasta tilastotietoa tuen suorituskyvystä suhteessa palvelutasosopimukseen.
- Organisaatiotiedot
- Henkilöt
-
Häiriönhallintakäytäntö
- Organisaatiolla tulee olla hyvin määritelty häiriönhallintakäytäntö. Tämä käytäntö kuvaa organisaation häiriönhallintaan liittyvät tavoitteet, laajuuden, roolit ja vastuut. Se muodostaa perustan häiriönhallintaprosessille
Hyödyt
-
Minimoitu käyttökatko
- Yksi häiriönhallintaprosessin tärkeimmistä hyödyistä on käyttökatkojen minimointi. Tunnistamalla, luokittelemalla ja ratkaisemalla häiriöt nopeasti organisaatiot voivat vähentää vaikutusta liiketoimintaan ja varmistaa, että kriittiset IT-palvelut ovat loppukäyttäjien saatavilla. Minimoidut käyttökatkot parantavat tuottavuutta, asiakastyytyväisyyttä ja liiketoiminnan jatkuvuutta kokonaisuudessaan.
-
Parempi palvelun laatu
- Häiriönhallintaprosessilla on tärkeä rooli palvelun laadun parantamisessa. Noudattamalla ennalta määriteltyjä häiriönhallintamenettelyjä ja palvelutasosopimuksia (SLA) organisaatiot voivat johdonmukaisesti täyttää tai ylittää asiakkaiden odotukset. Tehokas häiriöiden ratkaiseminen ja palvelun palauttaminen parantavat käyttäjäkokemusta, asiakastyytyväisyyttä ja luottamusta IT-palveluihin.
-
Parempi IT-henkilöstön tehokkuus
- Tehokas häiriönhallintaprosessi virtaviivaistaa IT-henkilöstön toimintaa ja edistää tehokasta yhteistyötä. Selkeät roolit, vastuut ja menettelyt varmistavat, että häiriöt käsitellään viipymättä ja oikeiden henkilöiden tai tiimien toimesta. Tämä parantaa tehokkuutta, lyhentää vasteaikoja ja optimoi resurssien käyttöä, jolloin IT-henkilöstö voi keskittyä kriittisiin tehtäviin ja tarjota loppukäyttäjille oikea-aikaista tukea.
Toimijat ja roolit
| Toimija | Kuvaus | Roolit Efecte Service Management Toolissa (ESM) |
| Loppukäyttäjä | Henkilö, joka käyttää yrityksen tarjoamia tuotteita tai palveluita. | N/A |
| Palvelupisteen agentti | Tarjoaa asiakastukea loppukäyttäjille. Palvelupisteen agentti kuuluu tukiryhmään, joka toimii loppukäyttäjien ensimmäisenä yhteyspisteenä. |
Service Desk Agent
|
| Kolmannen osapuolen toimijat | Kolmannen osapuolen toimijat ovat usein toimittajia, jotka tarjoavat yritykselle IT-palveluita. | N/A |
Paras käytäntö tikettityyppien vaihtamiseen
Häiriöt, palvelutilaukset ja tietopyyntötiketit käsitellään Tiketti-mallilla. Ticket type -attribuuttia käytetään tikettityypin määrittämiseen. Loppukäyttäjiä suositellaan ohjeistamaan käyttämään oikeita lomakkeita itsepalveluportaalissa, jotta loppukäyttäjän kokemus on sujuva. Joskus pyyntöjä kuitenkin lähetetään väärän lomakkeen kautta. Tällaisissa tilanteissa tikettityyppiä voidaan vaihtaa tietyin rajoituksin. Sallitut ja ei-sallitut tikettityypin vaihdot on lueteltu alla.
Sallitut tikettityypin vaihdot
- Palvelutilaus → Häiriö
- Palvelutilaus → Tietopyyntö
- Häiriö → Tietopyyntö
- Tietopyyntö → Häiriö
Ei-sallitut tikettityypin vaihdot
- Häiriö → Palvelutilaus
- Tikettityyppiä ei voida vaihtaa häiriöstä palvelutilaukseksi, koska palvelutilaukset (palvelupyynnöt) edellyttävät yleensä hyväksyntää. Tilaukset on lähetettävä itsepalveluportaalin kautta, jotta ne noudattavat ennalta määriteltyjä hyväksymiskäytäntöjä.
- Tietopyyntö → Palvelutilaus
Usein kysytyt kysymykset
- Entä jos loppukäyttäjä yrittää tilata jotain lähettämällä häiriön?
- Suositus on pyytää asiakasta lähettämään tilaus oikean lomakkeen kautta itsepalveluportaalissa. Asianmukainen hyväksymisprosessi, joka jättää jäljen auditointia varten, on mahdollinen vain itsepalveluportaalin kautta lähetetyille tilauksille.
- Jos tällaisia tapauksia esiintyy usein, suositellaan luomaan Quickfill, jonka avulla palvelupisteen agentit voivat ohjeistaa loppukäyttäjiä. Myös ennalta määritellyn sähköpostimallin käyttöä suositellaan.
- Entä jos loppukäyttäjät pyytävät usein häiriölomakkeen kautta jotain, mitä ei ole palveluluettelossa?
- Suositus on tunnistaa usein pyydetyt nimikkeet ja lisätä ne palveluluetteloon, jotta loppukäyttäjät voivat lähettää pyynnöt palvelutilauksena itsepalvelun kautta. Tämä mahdollistaa standardoidun prosessin, jossa on ennalta määritellyt tehtävät ja joka noudattaa myös hyväksymiskäytäntöjä.
- Mikä on oletusarvoinen tikettityyppi, kun tiketit luodaan manuaalisesti tai sähköpostitse?
- Manuaalisesti luotujen tai sähköpostitse saapuneiden tikettien tikettityypiksi asetetaan oletuksena Häiriö. Yllä luetellut säännöt pätevät riippumatta siitä, minkä kanavan kautta tiketti vastaanotettiin.
Table of Contents