ITSM.express Manual v 1.1 Finnish - suomeksi

By Ondek, 11 June, 2024

ITSM.express Manual v 1.1 Finnish

Versio 1.1, 18. huhtikuuta 2024

Tiimi
Projektipäällikkö

Štefan Ondek

Kirjoittajat

Johann Botha
Etienne Shardlow
Dolf van der Haven

Tarkastajat

Suzanne van Hove
Wim Hoving

Kääntäjät

Lari Peltoniemi
Pyry Peltoniemi

Vastuuvapauslauseke

Tunnistamme palvelujohtamisen monet näkemykset – onko kyse "IT-palvelunhallinnasta" vai pelkästä "palvelunhallinnasta"? Tai jotain muuta? Tämän asiakirjan osalta vastaus on yksinkertainen – nykyään ei ole palvelua, joka ei hyödyntäisi jonkinlaista teknologiaa tai digitaalista tietoa. Siksi, kuten nimemme viittaa, puhumme IT-palvelunhallinnasta, mutta tunnustamme, että tämän asiakirjan tiedot soveltuvat myös teknologia/digitaali-alueen ulkopuolella.

Siksi määritelmämme palvelunhallinnasta kattaa koko organisaation kyvykkyydet, prosessit ja rakenteen, jotka tukevat henkilöstön toimia palveluiden tuottamiseksi koko niiden elinkaaren ajan, tuottaakseen arvoa asiakkaille ja organisaatiolle itselleen.

IT-palvelujohtaminen (ITSM) on osa palvelujohtamista, joka keskittyy palveluihin, jotka pääosin koostuvat tietotekniikkaelementeistä.

Lukemisen (ja kirjoittamisen) helpottamiseksi käytämme termiä "palvelujohtaminen" ja esimerkkimme/keskustelumme keskittyvät tekniseen yritykseen.

Esipuhe

Tämä on minimalistinen, ilmainen käsikirja, joka kattaa palvelujohtamisen olennaiset asiat. Se on kirjoitettu erityisesti niin, että se on helppo oppia, soveltaa ja opettaa. Kohderyhmänä ovat pääasiassa henkilöt ja organisaatiot, jotka ovat aloittamassa matkaansa palvelujohtamisessa, rakentamassa uutta palvelujohtaminenjärjestelmää tai parantamassa olemassa olevaa. Ei ole viittauksia olemassa oleviin kaupallisiin viitekehyksiin – ainoat ulkoiset viittaukset ovat standardeihin. Tämä on tehty, jotta ITSM.express -ohjeistus pysyy ilmaisena ja kaikille palvelunhallinnasta kiinnostuneille saatavilla.

Sisältö, vaikka minimalistinen, on johdonmukainen ISO/IEC 20000-1:2018 kanssa. Vaikka ISO/IEC 20000-1 ja useimmat muut (IT) palvelujohtamisjärjestelmät käsittelevät palvelujohtamisen toimintoja itsenäisesti, tämä käsikirja näyttää, kuinka luoda tehokas hallintajärjestelmä neljän tärkeän palvelujohtamisen toimen kautta: Määrittele, Tuota, Tarjoa ja Vastaa.

Tämän käsikirjan ovat kirjoittaneet tämän alan veteraanit ja huipputekijät: Johann Botha, Dolf van der Haven, Etienne Shardlow ja tarkastaneet Suzanne Van Hove ja Wim Hoving. Käsikirjan toimittaja ja "aivot" sen takana on Stefan Ondek, itse veteraanikouluttaja, konsultti ja aihealueasiantuntija projektinhallinnan ja palvelujohtamisen alueilla. Nämä henkilöt tekivät kaiken työn tämän käsikirjan eteen vapaaehtoisesti ilman korvausta. Suuret kiitokset heille.

Tekijänoikeuksien omistaja on voittoa tavoittelematon organisaatio ITSM.express, joka on rekisteröity Slovakiassa. Tämä käsikirja julkaistaan Creative Commons Attribution -lisenssillä. Olet vapaa:

Jakamaan — kopioimaan ja levittämään materiaalia missä tahansa muodossa tai välineessä mihin tahansa tarkoitukseen, jopa kaupallisesti. Muokkaamaan — remixamaan, muokkaamaan ja rakentamaan materiaalin päälle mihin tahansa tarkoitukseen, jopa kaupallisesti. Lisenssinantaja ei voi peruuttaa näitä vapauksia niin kauan kuin noudatat lisenssin ehtoja. Seuraavilla ehdoilla:

Attribuutio — Sinun on annettava asianmukainen krediitti, annettava linkki lisenssiin ja ilmoitettava, jos muutoksia on tehty. Voit tehdä tämän kohtuullisella tavalla, mutta ei millään tavalla, joka viittaa siihen, että lisenssinantaja tukee sinua tai käyttöäsi.

Ei lisärajoituksia — Et saa soveltaa oikeudellisia ehtoja tai teknologisia toimenpiteitä, jotka rajoittavat muita laillisesti tekemästä mitään, mitä lisenssi sallii.

Mitään takuita ei anneta minkäänlaiseen käyttöön tai soveltamiseen liittyen. Käytä omaa harkintaasi.

Sisällysluettelo

Tiimi
Vastuuvapauslauseke
Esipuhe
Määrittele
- Hallinto
  - Tavoitteet
  - Hyödyt
  - Keskeiset käsitteet
  - Prosessi
  - Yleiset sudenkuopat
  - Lisälukemista
- Riskienhallinta
  - Tavoitteet
  - Hyödyt
  - Keskeiset käsitteet
  - Prosessi
  - Yleiset sudenkuopat
  - Lisälukemista
- Kuluttajavuorovaikutus
  - Tavoitteet
  - Hyödyt
  - Keskeiset käsitteet
  - Prosessi
  - Yleiset sudenkuopat
  - Lisälukemista
Tuota
- Rakenna
  - Palvelun suunnittelu
  - Käyttöehdot
  - Tarpeiden analyysi
  - Rakenna tai osta
  - Palvelut, jotka sisältävät useita toimittajia
  - Palvelun seuranta
  - Palvelun yhdistäminen
  - Muutoksenhallinta
    - Tavoitteet
    - Hyödyt
    - Keskeiset käsitteet
    - Prosessi
    - Yleiset sudenkuopat
  - Julkaisu ja käyttöönottohallinta
    - Tavoitteet
    - Hyödyt
    - Keskeiset käsitteet
    - Prosessi
    - Yleiset sudenkuopat
Tarjoa
- Suojaa - Tietoturva
  - Tavoitteet
  - Prosessi
- Pääsynhallinta
  - Mittaaminen
    - Tavoitteet
    - Hyödyt
    - Keskeiset käsitteet
    - Prosessi
    - Yleiset sudenkuopat
- Paranna
  - Tavoitteet
  - Prosessi
Vastaa
- Palvelupiste
  - Tavoitteet
  - Hyödyt
  - Prosessi
  - Yleiset sudenkuopat
  - Onnistuneiden tulosten mittaaminen
  - Käyttäjäkysymysten ratkaiseminen
- Vastausprosessi
  - Tavoitteet
  - Hyödyt
  - Keskeiset käsitteet
  - Prosessi
  - Yleiset sudenkuopat

Määrittele

Määrittelyvaihe kattaa palvelun suunnittelun, mukaan lukien perusorganisatoriset prosessit kuten hallinto ja riskienhallinta. Tässä luodaan pohja hallintajärjestelmälle, joka tukee palvelun elinkaarta.

Hallintotapa

Tavoitteet

Hallintotapa on organisaation toimintaa, joka tarjoaa organisaatiolle ohjausta suunnan, politiikkojen ja yleisen valvonnan muodossa. Se pitää mielessä organisaation tavoitteet liiketoiminnan tulosten, kuten kannattavuuden, asiakas- ja työntekijäkokemuksen sekä sovellettavien lakien ja säädösten noudattamisen osalta.

ISO 37000 (Organisaatioiden hallintotapa) ja ISO/IEC 38500 (IT-hallintotapa) standardien mukaan organisaation pääasiallinen ryhmä, joka suorittaa nämä toiminnot, on "hallintoelin", esimerkiksi hallitus tai muu suhteellisen itsenäinen henkilö tai ryhmä organisaation yläosassa. Käytännössä hallintotapaa voidaan ja pitäisi kuitenkin toteuttaa kaikilla organisaation tasoilla sopivan johtajuuden toimesta heidän vastuualueellaan.

Hyödyt

Hyvä hallintotapa on olennaista minkä tahansa organisaation, mukaan lukien palveluntuottajat, toiminnassa. Hyödyt ovat seuraavat:

Parempi organisaation suorituskyvyn valvonta kokonaisuutena;
Vastuu kaikilla organisaation tasoilla sen operatiivisesta ja strategisesta suorituskyvystä;
Selkeys organisaation liiketoiminnan suunnasta;
Parempi tietoisuus työntekijöiden keskuudessa heidän aktiviteettiensa merkityksestä organisaation tarkoituksen suuremmassa kontekstissa;
Parannettu päätöksenteko olennaisen tiedon havainnoinnin perusteella.

Keskeiset käsitteet

Hyvä hallintotapa perustuu useisiin periaatteisiin, jotka jokainen organisaatio voi asettaa itselleen, mutta jotka ovat todennäköisesti samankaltaisia kuin jokin tai useampi seuraavista:

Organisaation tarkoitus;
Arvon tuottaminen organisaatiolle ja sen kuluttajille;
Strategian luominen organisaatiolle;
Organisaation operatiivisen toiminnan valvonta;
Sidosryhmien, kuten kuluttajien, työntekijöiden, viranomaisten osallistaminen;
Riskien hallinta;
Yritysvastuullisuus.

Prosessi

Edellä mainitut periaatteet ja mahdollisesti muut antavat lähtökohdan hallintotavan rakentamiselle. Käytännön toimet näiden periaatteiden perusteella ovat seuraavat:

Määritä organisaation missio ja visio: mitä organisaatio haluaa saavuttaa? Miten haluat tehdä tämän?
Mitkä ovat organisaation toimintaan vaikuttavat tekijät sekä sisäisesti että ulkoisesti? Ajattele kuluttajien vaatimuksia, lainsäädäntöä ja sääntelyä, kestävyystavoitteita, resurssien saatavuutta ja organisaation yleisiä vahvuuksia ja heikkouksia tällä hetkellä.
Ketkä ovat organisaation toimintaan liittyvät sidosryhmät? Työntekijät ja johtajat organisaation sisällä, mutta myös kuluttajat, viranomaiset, mahdollisesti jopa media ja osakkeenomistajat, jotka ovat kiinnostuneita organisaation suorituskyvystä ja menestyksestä.

ISO/IEC 38500:2024

on yksinkertainen malli, joka näyttää, mitä toimintoja hallintotavan osana tulee suorittaa. Nämä ovat seuraavat, lyhennettynä EDMS (Evaluate, Direct, Monitor, Stakeholder Engagement):

Arvioi: arvioi, miten organisaatio suoriutuu edellä mainittujen periaatteiden perusteella.
Ohjaa: anna suuntaa organisaatiolle muuttaa toimintojaan tarvittaessa arvioinnin perusteella.
Seuraa: valvo, miten organisaatio suoriutuu indikaattoreiden, kuten keskeisten suorituskykyindikaattoreiden (KPI, Key Performance Indicator), keskeisten riskindikaattoreiden (KRI, Key Risk Indicator)) tai muiden perusteella.
Osallista sidosryhmiä: tarjoa riittävästi viestintää hallintotavan tavoitteista eri sisäisille ja ulkoisille sidosryhmille, jotta alempi organisaatio tietää, mitä sen on tarkoitus tehdä operatiivisesti.

Nämä neljä toimintaa on erittäin helppo toteuttaa kaikilla organisaation johtotasoilla. Keskushallintotoiminnon, kuten hallituksen, tulisi tehdä kaikki neljä toimintaa organisaation kokonaisuudelle, jotta alemmilla johtajilla on tarvittavat ohjeet toteuttaa saatu suunta organisaation toiminnassa. Mutta tiimin johtajan tulisi tehdä sama omalla tasollaan: arvioida tiimin suorituskyky, antaa suuntaa tiimille siitä, mitä tavoitteiden parantamiseksi on tehtävä, valvoa, miten tiimi suoriutuu vakiintuneiden KPI:den perusteella ja viestiä usein annetusta suunnasta ja tiimin suorituskyvystä.

Johtajilla organisaatiossa on siis kaksi roolia: toisaalta heidän on pantava käytäntöön saatu hallintasuunnitelma, ja toisaalta heidän on tarjottava hallintasuunnitelma itse heidän alaisuuteensa kuuluvalle tiimille tai organisaation osalle. Tämä jakautuminen hallinnon (EDMS-toiminnot) ja johtamisen (hallintotavan suunnan kääntäminen operatiiviseksi käytännöksi) välillä on joskus liioiteltua, mutta todellisuudessa hallintotapa ja johtaminen ovat integroitu kokonaisuus kullekin organisaation johtotasolle.

Käytännössä johtajilla on myös kolmas "rooli", joka on heidän ylöspäin johtaminen: se on hallintotavan "seuraa" toiminto, joka antaa korkeammalle johdolle näkemyksiä organisaation suorituskyvystä, jonka perusteella korkeampi johto voi arvioida organisaation suorituskykyä ja antaa tarvittaessa uutta suuntaa.

Yleiset sudenkuopat

Yleisiä hallintotavan ongelmia ovat seuraavat:

Hallintotapa on sama kuin hallinto – Hallinto ja sen hallitus on poliittinen yksikkö, joka ohjaa ihmisiä toimivaltansa piirissä ja asettaa poliittisen suunnan. Hallintotapa, vaikka siihen liittyykin samankaltaisia toimintoja, on toiminto eri tasoilla yrityksessä tai muussa organisaatiossa, mutta sillä ei ole poliittisia intressejä.
Hallintotapa on rajoitettu vain organisaation huipulla olevaan hallintoelimeen. Sitä tulisi todella toteuttaa kaikilla organisaation tasoilla.
Hallintotavan ja johtamisen toimintoja ei ole selvästi erotettu. Hallintotavan strategiset toiminnot (Arvioi, Ohjaa, Seuraa, Viesti) ja johtamisen toiminnot, joita tarvitaan saatujen ohjeiden toteuttamiseen, tulisi erottaa selkeästi.
Hallintotapaa tulkitaan väärin säännöllisinä kokouksina eri sidosryhmien välillä. Hallintotavalla on selkeät tavoitteet ja toiminnot, kuten yllä on kuvattu. Se vaatii tiettyjä kokouksia, mutta niiden tarkoitus on oltava selvä niille osallistuville, joilla on hallintovastuu.

Lisälukemista

Tutustu ITSM.express -verkkosivustoon saadaksesi lisätietoja hallintotavan syötteistä ja tuloksista.

Riskienhallinta

Tavoitteet

Riski voidaan määritellä epävarmuudeksi, joka voi vaikuttaa organisaation tavoitteisiin. Nämä epävarmuudet voivat olla joko positiivisia tai negatiivisia. Positiivinen riski on jotain, mikä voi edistää tavoitteiden saavuttamista ja sitä kutsutaan myös "mahdollisuudeksi", jota organisaatio saattaa haluta tavoitella. Negatiivinen riski on se, miten ihmiset yleensä mieltävät riskit: este, joka estää organisaation tavoitteiden saavuttamisen ja jota tulisi välttää tai ainakin minimoida. Molemmat riskityypit ovat merkityksellisiä riskienhallinnassa. Riskit ovat tärkeä osa hallinnon syötteitä kaikilla organisaation tasoilla. Siksi riskienhallintaa tulisi suorittaa kaikilla organisaation tasoilla. Riskienhallinta on osa monia muita palvelujohtamisen alueita, kuten tietoturvan hallintaa, kapasiteetin hallintaa ja muita prosesseja.

Riskienhallinnan perusstandardi on ISO 31000 (Riskienhallinta), johon tämä osio on yleisesti linjassa.

Hyödyt

Hallinnon tavoin riskienhallinta on organisaation toiminnan perusta. Riskienhallinnan suorittamisen edut ovat seuraavat:

Mahdollisten uhkien ja haavoittuvuuksien varhainen varoitus;
Mahdollisuus puuttua riskeihin, jos ne materialisoituvat, ottamalla käyttöön tehokkaita kontrollitoimenpiteitä;
Selkeä yleiskuva uhkakentästä;
Koko organisaation tietoisuus siitä, mikä voi estää liiketoiminnan tulosten saavuttamisen.

Keskeiset käsitteet

Riskit ovat tapahtumia, jotka voivat vaikuttaa organisaatioon eri tavoin: voi olla riskejä, jotka liittyvät organisaation tai sen asiakkaiden tietojen pitämiseen turvassa (tietoturvariskit), riskejä organisaation operatiiviselle suorituskyvylle (kyky täyttää KPI), riskejä ulkoisten säädösten, kuten tietosuojalakien tai muiden säädösten, noudattamatta jättämisestä (määräystenmukaisuusriskit) tai riskejä, jotka liittyvät ulkoisiin toimittajiin (kolmannen osapuolen riskit). Riskienhallinnassa kaikki käy, mutta on määritettävä, kuinka vakava riski todellisuudessa on.

Riski luokitellaan yleensä sen kahden näkökulman perusteella: todennäköisyys, että riski todellisuudessa toteutuu (esim. asteikolla 1-5) ja sen vaikutus organisaatioon, jos se toteutuu (esim. asteikolla 1-5). Kun todennäköisyys ja vaikutus määritetään, voidaan laskea riskitaso niiden tulona:

Riskitaso = Todennäköisyys x Vaikutus

Tämä riskitaso toimii kokonaisindikaattorina riskin vakavuudesta.

Prosessi

ISO 31000:nmukainen riskienhallinta sisältää useita vaiheita:

Riskinarviointi on yleinen vaihe, jossa seuraavat kolme prosessivaihetta suoritetaan:

Riskien tunnistaminen: riskienhallinnan prosessin laajuuden, organisaation kontekstin ja hyväksyttävien kriteerien perusteella riskit tunnistetaan. Tunnistaminen koostuu uhkien määrittämisestä, jotka voivat vaikuttaa organisaation haavoittuvuuksiin.
Riskien analysointi: edellisessä vaiheessa tunnistettuja uhkia ja haavoittuvuuksia analysoivat organisaation henkilöt, jotka pystyvät määrittämään riskin mahdollisen vaikutuksen, jos se toteutuu, ja riskin toteutumisen todennäköisyyden. Tämä johtaa edellä mainittuun riskitasoon.
Riskien arviointi: riskitaso, joka määritettiin riskien arvioinnin aikana, arvioidaan, mitä toimia on toteutettava. Riskien lieventämistoimet riippuvat suuresti riskin luonteesta, mutta ne voidaan jakaa kolmeen pääkategoriaan:
- Käsittele riski: tässä tapauksessa päätät ryhtyä toimiin joko riskin todennäköisyyden tai vaikutuksen vähentämiseksi tai molempien. Toimenpiteet tunnetaan kontrollitoimenpiteinä. Kontrolli on hallinnollinen (kirjoita ja toteuta prosessi tai politiikka), tekninen (implementoi palomuuri) tai fyysinen (lisää lukot oviin) toimenpide, joka vähentää riskin todennäköisyyttä tai vaikutusta.
- Hyväksy riski: voidaan päättää, että riskitaso ei ole riittävän korkea, jotta riskin käsittelyyn kannattaisi käyttää aikaa tai rahaa. Toisin sanoen, riski on hyväksyttävällä tasolla. Tämä päätöstä ei pidä ottaa kevyesti: vain asianmukaisella hallintotasolla tulisi voida hyväksyä riskejä omalla vastuualueellaan ja vain tiettyyn riskitasoon asti. Esimerkiksi, politiikkana voi olla, että vain keskitason riskit voidaan hyväksyä ja sittenkin vain sen vastuualueen hallintotaso, joka riskistä on vastuussa, voi tehdä tämän. Tämä hyväksyttävä riskitaso tunnetaan nimellä riskinottohalukkuus.
- Siirrä riski: jos riski on luonteeltaan sellainen, että toinen tiimi, toinen osa organisaatiota tai jopa ulkopuolinen taho on vastuussa riskin käsittelemisestä, riski voidaan siirtää heille. Siirto tarkoittaa toisen osapuolen kontaktoimista, riskin selittämistä ja sen arvioinnin selittämistä heille ja heidän saamistaan vastuullisiksi riskin käsittelemisestä. Toinen osapuoli voi sitten itse päättää, onko tarpeellista käsitellä riski vai ei. Joka tapauksessa, jos riski toteutuu, toinen osapuoli on vastuussa tapahtuman vaikutuksista organisaatioon. Esimerkiksi, jos tunnistat riskin, että valtuuttamattomilla henkilöillä voi olla pääsy rajoitettuun alueeseen rakennuksessa, kuten datakeskukseen, voit siirtää tämän riskin ryhmälle organisaatiossa, joka vastaa tilojen fyysisestä turvallisuudesta. Tämä fyysinen turvallisuusryhmä tunnustaa sitten riskin omistajuuden ja määrittää, tarvitseeko heidän ryhtyä toimiin rajoitetun alueen suojaamiseksi.
- Hyödynnä riski: positiivisten riskien (mahdollisuuksien) tapauksessa organisaatio saattaa haluta tavoitella sitä, eli riskin toteutumista tulisi edistää, jotta riskin positiivinen vaikutus voidaan saavuttaa. Tämä voidaan tehdä esimerkiksi silloin, kun odotetaan taloudellisten olosuhteiden, kuten verosäännösten tai energiakustannusten, paranevan, jolloin palvelujen tuottaminen tulee halvemmaksi ja siten palveluntarjoajan markkina-asema paranee.

Jos riskiä käsitellään, eli otetaan käyttöön jokin kontrollitoimenpide, riskin todennäköisyyden ja/tai vaikutuksen pitäisi olla pienempi kuin alkuperäinen todennäköisyys ja/tai vaikutus. Tämä johtaa uuteen riskitasoon, joka tunnetaan jäännösriskinä. Jäännösriski on se riski, joka jää jäljelle käsittelyn jälkeen. Kontrolli usein vähentää riskitasoa tiettyyn pisteeseen asti, mutta ei poista riskiä kokonaan. Jäännösriski on indikaattori siitä, mikä riski jää jäljelle käsittelyn jälkeen, ja sen tulisi olla hyväksyttävän riskitason (eli riskinottohalukkuuden) alapuolella. Jos se on edelleen korkeampi kuin riskinottohalukkuus, saatetaan tarvita lisäkontrollitoimenpiteitä riskitason alentamiseksi riittävästi.

Yleiset sudenkuopat

Riskienhallinta laiminlyödään. Käytännöllisen ja helpon riskienhallintakehyksen käyttöönotolla riskienhallinnan ei tarvitse olla raskasta, mutta se voidaan integroida organisaation päivittäisiin toimintoihin.
Liian monta riskiä hyväksytään käsittelemisen sijaan. Tämä on merkki laiskoista riskinomistajista – sen sijaan, että analysoitaisiin riskejä ja otettaisiin käyttöön kontrollitoimenpiteitä, he ottavat riskin ja jättävät mahdollisen vaikutuksen organisaation liiketoiminnan tuloksiin huomioimatta.
Kontrollitoimenpiteitä ei tarkasteta säännöllisesti niiden tehokkuuden osalta. Kun riskiä käsittelemään otetaan käyttöön kontrollitoimenpide, sen tehokkuutta on tarkastettava säännöllisesti, koska uhat voivat muuttua ja lopulta murtautua kontrollitoimenpiteiden läpi. Kontrollitoimenpiteitä voidaan joutua vahvistamaan tai korvaamaan muilla toimenpiteillä, jotta ne pysyvät tehokkaina.
Riskin ilmoittaja omistaa automaattisesti riskin. Riskin omistajuuden tulisi olla sillä henkilöllä, joka on parhaassa asemassa käsittelemään sen, eikä välttämättä henkilöllä, joka ilmoitti sen ensimmäisenä. Asenne "jos kosketat sitä, omistat sen" organisaatiossa estää ihmisiä ilmoittamasta riskejä tulevaisuudessa.

Lisälukemista

Tutustu ITSM.express -verkkosivustoon saadaksesi lisätietoja riskienhallinnan käsitteistä ja käytännöistä.

Kuluttajavuorovaikutus

Tavoitteet

Palvelu kehitetään, jotta sitä käyttävät loppukäyttäjät tai kuluttajat. On mahdollista kehittää palvelu ilman vuorovaikutusta kuluttajien kanssa, mutta tämä johtaa palveluun, joka ei välttämättä kiinnosta heitä ja siksi sitä ei käytetä. Vuorovaikutusta kuluttajien kanssa on oltava palvelun kehittämisen alkuhetkestä siihen hetkeen, kun se poistetaan käytöstä.

Hyödyt

Kuluttajavuorovaikutuksen hyödyt ovat seuraavat:

Parempi ymmärrys siitä, mitä palvelun kuluttajat tarvitsevat omien liiketoiminnan tulosten saavuttamiseksi;
Säännöllinen kuluttajakokemuksen ja palvelun tyytyväisyyden tarkistus, jotta palvelua voidaan parantaa tarvittaessa;
Säännöllinen raportointi kuluttajille palvelun suorituskyvystä, jotta he voivat tarkistaa, täyttääkö palvelu odotukset ja sovitut asiat;
Ohjaus palvelun kehittämiseen varmistaakseen, että palvelu täyttää kuluttajien tarpeet.

Keskeiset käsitteet

Kuluttajat ovat harvoin kiinnostuneita palvelustasi sen itsensä vuoksi: he yleensä haluavat käyttää palvelua saavuttaakseen omat tavoitteensa. Jollain tavalla kuluttajat saavat arvoa käyttämällä palveluasi saavuttaakseen omat tuloksensa. Tämä kuluttaja-arvo voi olla täysin erilainen kuin palveluntarjoajan saama arvo: palveluntarjoajan arvo voi olla tulon saaminen, tyytyväisten asiakkaiden saaminen, markkinaosuuden lisääminen tai laajemman yrityksen liiketoiminnan tukeminen. Palvelun kuluttaja näkee palvelun yleensä välineenä omien tavoitteidensa saavuttamiseksi, kuten sähköpostien lähettämisen ja vastaanottamisen, tietojen käsittelyn, taloudellisten transaktioiden käsittelyn.

Ensimmäinen askel vuorovaikutuksessa (mahdollisten tai olemassa olevien) palvelun kuluttajien kanssa on määrittää, mitä he pitävät palvelun arvona. Tämä on erittäin peruskysymys, mutta se on myös tärkein, jos haluat saada kuluttajat käyttämään palveluasi. Arvolausunnosta seuraavat palvelun vaatimukset sekä perusta suhteiden muodostamiselle kuluttajien kanssa.

Prosessi

Tästä kuluttajan arvon määritelmästä voit johtaa vaatimukset heille tarjoamallesi palvelulle.. Mitä sähköpostipalvelun osa-alueita he tarvitsevat tehdäkseen työnsä tehokkaimmin (esimerkiksi jaetut postilaatikot, ajoitettu lähettäminen jne.)? Mitä taloudellisen palvelun osa-alueita he tarvitsevat saavuttaakseen liiketoiminnan tuloksensa (esimerkiksi palkanlaskenta, kirjanpito jne.)?

Eri kuluttajilla on erilaisia vaatimuksia. On järkevää kerätä lista todellisista ja mahdollisista palvelusi vaatimuksista ja priorisoida ne sen perusteella, mitä enemmistö kuluttajista tarvitsee ja mikä on saavutettavissa tietyssä aikataulussa. Useimmilla kuluttajilla on joukko yhteisiä palveluvaatimuksia, jotka olisi katsottava osaksi peruspalvelua. Sitten on vaatimuksia, jotka ylittävät peruspalvelun ja lisäävät toiminnallisuutta, joka hyödyttää suurta osaa kuluttajista: nämä voidaan aluksi katsoa "premium" -toiminnallisuudeksi tai laittaa kehityksen tiekartalle lähitulevaisuudessa. Kolmas vaatimuskategoria ovat täysin räätälöidyt vaatimukset, jotka koskevat vain yhtä tai muutamaa kuluttajaa. Näiden osalta on harkittava, onko järkevää kehittää täysin räätälöity palvelu vain muutamalle kuluttajalle vai ei. Riippuu omasta liiketoimintamallista, keskitytäänkö ensisijaisesti standardipalveluihin vai onko joustavuutta mukauttaa niitä.

Kuluttajavaatimukset sekä omat, sisäisesti kerätyt vaatimukset syötetään palvelun kehittämisprosessiin. Tätä prosessia käsitellään myöhemmin Tuota-osiossa tässä kirjassa.

Suhteet palvelun kuluttajiin eivät pääty, kun olet kerännyt vaatimukset ja myynyt tai toimittanut palvelun heille. Kuluttajien on oltava mukana jokaisessa vaiheessa, jotta he voivat antaa palautetta tarjoamastasi palvelusta. Tämä tunnetaan kuluttajakokemuksen (CX) hallintana ja loppukäyttäjän tasolla käyttäjäkokemuksen (UX) hallintana. CX/UX kattavat koko sen, miten palvelun käyttäjät kokevat sen. Tämä sisältää käytettävyyden, toiminnallisuuden, heidän kokemuksensa palvelun hankkimisesta, laskutuksesta (jos sovellettavissa), jälkihoidosta, muutospyynnöistä, tapausten ratkaisemisesta ja kaikista heille tehdyistä parannuksista. Joka kerta, kun kuluttaja on vuorovaikutuksessa organisaatiosi tai palvelusi kanssa, syntyy kosketuspiste ja jokainen kosketuspiste johtaa siihen, että kuluttajalla on tietty kokemus. Kuluttajasuhteiden hallinnan ydin on, että voit määrittää asiakaskokemuksen näissä kosketuspisteissä, ottaa sen huomioon ja tarvittaessa toteuttaa parannuksia, jos asiakaskokemus niin kertoo.

Kuluttajien tarpeiden huomioimisen lisäksi älä unohda työntekijöidesi tarpeita: työntekijäkokemus on onnistuneiden palveluiden perusta. Työntekijät tekevät kaiken työn asiakkaille, ja siksi on tärkeää varmistaa, että he tuntevat olonsa onnelliseksi tehdessään työtään. Työntekijäkokemusta voidaan mitata samalla tavalla kuin asiakaskokemusta, tekemällä säännöllisiä kyselyjä tai saamalla palautetta yksilö- tai tiimitasolla keskusteluissa. Tämä palaute tulisi sitten viedä jatkuvan parantamisen prosessiin tehdäkseen tarvittavat muutokset palveluihin.

Viimeinen osa kuluttajavuorovaikutusta on tarjota heille raportointi heidän käyttämästään palvelusta. Tämä voi olla eri muodoissa, mutta se usein perustuu tiettyihin palvelutavoitteisiin, joista on sovittu kuluttajien kanssa. Palvelutavoitteet voivat olla seuraavanlaisia:

Palvelupyyntöjen, tapausten, muutospyyntöjen vastausajan oikea-aikaisuus;
Palvelun saatavuus;
Palvelun suorituskyky;
Palvelun luotettavuus;
Kuluttajakokemus (mukaan lukien käytön helppous, tehokas loppukäyttäjän tuki, tarkoituksenmukaiset palveluominaisuudet);
Palvelun tarkkuus jne.

Palvelutavoitteet voivat olla osa oletussopimusta tai ne voidaan mukauttaa tiettyjä kuluttajia varten. Kummassakin tapauksessa ne viitataan palvelutason sopimukseen (SLA), joka keskittyessään enemmän CX/UX:een, voi sisältää kokemustason sopimuksen (XLA).

Yleiset sudenkuopat

Yksi koko sopii kaikille -asenne. Tämä tarkoittaa, että oletetaan, että kaikki kuluttajat ovat yhtä tyytyväisiä palveluun, riippumatta heidän omista tarpeistaan. Käytännössä jokaisella kuluttajalla on erilainen mielipide siitä, mitä palvelun tulisi tehdä heille, joten mukautusta voidaan tarvita palvelun sovittamiseksi heidän yksilöllisiin tarpeisiinsa.
Kuluttajavuorovaikutusta ei tapahdu tarpeeksi usein. Riippuu kuluttajan tyypistä, tarvitaanko enemmän tai vähemmän säännöllistä vuorovaikutusta heidän kanssaan. Jotkut kuluttajat suosivat kuukausiraportointia, toiset ovat tyytyväisiä vuosittaiseen suorituskykyraporttiin. Kuluttajavuorovaikutuksen mukautusta voidaan tarvita sen taajuuden sovittamiseksi yksittäisten kuluttajien tarpeisiin.
Vuorovaikutus tapahtuu samalla tavalla kaikille kuluttajille. Kuten taajuudessa, kuluttajavuorovaikutuksen tyyppi saattaa vaatia mukauttamista heidän erityistarpeidensa ja odotustensa täyttämiseksi.
Sisäiset tavoitteet eivät ole linjassa kuluttajien SLA:n kanssa. Tämä on valitettavan yleistä: palvelua tukevien tiimien keskeiset suorituskykyindikaattorit voivat olla ristiriidassa kuluttajien SLA:n kanssa sovitun kanssa. Sisäisten ja ulkoisten tavoitteiden tulee olla linjassa ja palveluja tukevien henkilöstön tulee olla tietoisia sekä omista KPI:stään että kuluttajien SLA:sta.

Lisälukemista

Tutustu ITSM.express -verkkosivustoon saadaksesi lisätietoja asiakaskokemuksen mittaamisesta ja siitä raportoimisesta.

Tuota

Palvelunhallinnan tuota-vaihe kehittää palvelua rakentamalla, ottamalla käyttöön ja testaamalla sen. Tässä vaiheessa käytetään prosesseja, kuten muutoksenhallinta ja julkaisunhallinta, palvelun toimittamisen hallitsemiseksi käyttöympäristössä ennen kuin kuluttajat alkavat käyttää sitä.

Palvelu

Palvelu on tapa tuottaa arvoa asiakkaille täyttämällä heidän määritellyt tarpeensa. Yleensä palvelu on siten aineeton, vaikka se voidaan myös toimittaa yhdessä (aineellisen) tuotteen kanssa.

Rakenna

Ennen kuin palvelut voidaan toimittaa, ne on luotava, mikä tarkoittaa, että kaikki palvelun komponentit luodaan ja kootaan, organisaatio valmistellaan tukemaan palvelua ja palvelu rakennetaan palvelun suunnittelun perusteella. Ihannetapauksessa tämä tehdään yhteistyössä kuluttajan kanssa, jotta sekä palveluntarjoaja että kuluttaja saavat suurimman arvon palvelun luomisesta. Palvelusta saatava arvo voi olla hyvin erilainen palveluntarjoajalle ja kuluttajalle, mutta molemmat osapuolet on otettava huomioon palvelua rakennettaessa. Kuluttajan arvo voi esimerkiksi olla liiketoimintaprosessin mahdollistaminen, joka johtaa yhden heidän liiketoimintatavoitteensa saavuttamiseen; palveluntarjoajan arvo voi olla markkinaosuuden saavuttaminen tai säilyttäminen, asiakastyytyväisyyden lisääminen tai tuoton tuottaminen. Palvelun ominaisuuksien tulisi perustua asiakkaiden tarpeisiin, joita niiden on tarkoitus tyydyttää, mutta se ei riitä; myös muita panoksia on otettava huomioon:

Organisaation hallintamalli ja strategia (onko tämä palvelu, joka meidän pitäisi toimittaa?);
Organisaation kyvykkyydet tai kumppaneiden kyvykkyydet (voimmeko toimittaa tämän palvelun?);
Hyväksytty organisaation arkkitehtuuri mukaan lukien organisaation käyttämä tekninen arkkitehtuuri (voimmeko rakentaa ja ylläpitää tätä palvelua tehokkaasti?).

Kun ajatellaan asiakkaiden tarpeita, organisaation on otettava huomioon paitsi toiminnallisuus, myös palvelun takuunäkökohdat, joita ne aikovat suunnitella tai rakentaa, sekä kuinka he aikovat lisätä palvelun ja ylläpitää sitä osana palveluvalikoimaansa ja -tarjoomaansa.

Palvelumuotoilu

Käyttöolosuhteet

Palveluntuottajien on ymmärrettävä, kuinka ja missä asiakkaat käyttävät palveluita, koska nämä määrittävät palvelun takuun suunnittelun.

Takuuelementit

Takuuelementit, jotka on otettava huomioon, ovat vähintään:

Palvelun kysyntä: Tämä määrittää palvelun toimittamiseen käytettyihin resursseihin kohdistuvan kuormituksen (esimerkiksi kuinka monta sivustoa, kuinka monta käyttäjää, kuinka monta transaktiota) ja sitä tulisi käyttää palvelun suunnittelussa ja rakentamisessa siten, että asiakkaiden tarvitsema kapasiteetti on aina käytettävissä arvoa tuottaen.
Palvelun saatavuus: Tämä käsittää sen, kuinka asiakas käyttää palvelua, millä ehdoilla ja mikä asiakkaan mielestä on hyväksyttävä saatavuustaso. Milloin palvelun tulisi olla saatavilla, missä sen tulisi olla saatavilla, mitä pidetään saatavana (esimerkiksi hidas vasteaika voidaan pitää saatavuuden puutteena, joten tietokoneistetussa järjestelmässä tämä sisältää elementit, kuten transaktioiden vasteaika ja transaktiomäärä, jonka palvelun tulisi pystyä käsittelemään).
Palvelun kapasiteetti: Tämä on edellä mainittujen kahden elementin käännös palvelun perustana olevien rakennuspalikoiden teknisiin kykyihin. Jälleen kerran tietokoneistetussa järjestelmässä alimmalla tasolla tämä tarkoittaa elementtejä, kuten verkon kaistanleveys, tietokannan koko ja luku-/kirjoitusnopeus, tallennuskapasiteetti, käsittelyteho (yleensä CPU ja muistikapasiteetti).

Tarpeiden analysointi

Syvällinen asiakastarpeiden analyysi: Tämä tulisi tehdä kilpailuympäristön kontekstissa, jotta voidaan selvittää, voidaanko uusi (suunniteltu) palvelu toimittaa elinkelpoisesti asiakkaille.

Rakentaminen tai ostaminen

Kun palvelumuotoilu on valmis, organisaatioiden on kriittisesti tarkasteltava kykyään toimittaa kaikki palvelun osa-alueet, kun palvelu on rakennettu. Usein tämä tarkoittaa, että organisaatiot valitsevat strategisia kumppanuuksia joidenkin palvelun osa-alueiden toimittamiseksi.

Arkkitehtuurin näkökulmasta organisaatiot voivat myös päättää käyttää yhtä kolmesta vaihtoehdosta palvelun komponentteja ajatellessaan:

Kehitä komponentit itse ja rakenna ne alusta alkaen;
Kehitä joitakin komponentteja ja käytä olemassa olevia rakennuspalikoita tarjonnan täydentämiseksi;
Osta tai hanki standardirakennuspalikoita, jotka voidaan koota ainutlaatuiseen kokoonpanoon ja jotka tarvitsevat vain konfigurointia (kehityksen sijaan).

Näiden vaihtoehtojen kustannukset voivat vaihdella suuresti, ja organisaation tulisi harkita paitsi omia kykyjään, myös rakentaa taloudellinen malli suunnittelun lyhyen ja pitkän aikavälin elinkelpoisuuden määrittämiseksi.

Palvelut, jotka sisältävät useita toimittajia

Jos organisaatio tuottaa palvelua, joka riippuu muista palveluntuottajista, tulee suunnittelukriteereillä varmistaa, että muut osapuolet voivat täyttää sitoumuksensa, koska palvelun kokonaisvaltainen suorituskyky riippuu kaikista sen komponenteista.

Muutoksenhallinta

Tavoitteet: Muutoksenhallinnan tarkoituksena on hallita tuotantoympäristössä toteutettavia muutoksia. Sana "hallinta" saattaa kuulostaa rajoittavalta, mutta sen ei tarvitse olla sitä käytännössä. Usein on löydettävä tasapaino palvelun parannusten nopean ja joustavan toteuttamisen ja palveluiden vakauden säilyttämisen välillä. Tämä tasapaino on se, mitä muutoksenhallinnan tulisi tarjota.

Hyödyt: Hyvin toimivalla muutoksenhallintaprosessilla on useita etuja:

Palvelun vakauden varmistaminen, kun muutoksia otetaan käyttöön;
Minimiviive muutosten toteuttamisessa;
Kaikkien asiaankuuluvien sidosryhmien tiedottaminen suunnitelluista muutoksista;
Vähemmän palvelua vaarantavien muutostyyppien priorisoinnin helpottaminen.

Keskeiset käsitteet

Muutoksenhallinta alkaa muutospyynnöstä (RFC): tämä on pyyntö, joka tulee loppukäyttäjältä, kehitystiimiltä tai muulta osapuolelta muuttaa jotain tarjoamaasi palvelussa. RFC:t voivat sisältää hyvin pieniä muutoksia, kuten verkkolaitteen portin nopeuden muuttaminen, tai paljon suurempia, kuten palvelimen laitteiston päivittäminen.

Muutoksenhallintakäytäntö tulisi luoda ohjaamaan, kuinka erilaisia muutoksia tulisi käsitellä:

Suuret, palveluun vaikuttavat muutokset voivat joutua menemään läpi projektin, jossa useat sidosryhmät työskentelevät toteuttaakseen muutoksen ilman keskeytyksiä. Tämä projekti sisältyy silti muutoksenhallintaprosessin vaadittuihin vaiheisiin;
Pienet muutokset voidaan esihyväksyä ja toteuttaa ilman lisäviivettä. Nämä lähetetään usein palvelupyyntöprosessiin, joka on itse asiassa lyhennetty versio muutoksenhallintaprosessista;
Kaikki muut muutokset käyvät läpi normaalin muutoksenhallintaprosessin.

On olemassa kategoria muutoksia, jotka ovat osa häiriön ratkaisua ja joita kutsutaan hätämuutoksiksi. Hätämuutokset on toteutettava viipymättä, jos on kiireellinen tarve korjata häiriö, kuten hajautettu palvelunestohyökkäys (DDoS) tai vakava ohjelmistovirhe, joka on korjattava välittömästi. Erillinen menettely voi olla käytössä näiden hätämuutosten käsittelemiseksi. Tämä menettely yleensä ohittaa aluksi säännöllisen muutoksenhallintaprosessin ja ottaa muutoksen käyttöön heti. Tämän jälkeen säännölliset vaiheet on silti suoritettava, jotta voidaan dokumentoida, mitä on tehty.

Prosessi

Kun palveluntuottaja vastaanottaa muutospyynnön (RFC), ensimmäinen vaihe sen kirjaamisen jälkeen on antaa sen käydä läpi luokittelu, eli arvioida muutoksen luonne sen mahdollisen vaikutuksen määrittämiseksi. Luokittelun tuloksena RFC joko lähetetään normaaliin muutoksenhallintaprosessiin, palvelupyyntöjen hallintaan tai projektiorganisaatioon käsiteltäväksi.

Jos RFC menee normaaliin muutoksenhallintaprosessiin, tiimin, joka on tarkoitettu toteuttamaan se, tulisi arvioida sen kelpoisuus. Tiimi voi joutua arvioimaan pyyntöä tarkistaakseen yksityiskohdat ja sopiakseen ajankohdasta, jolloin muutos voidaan ottaa käyttöön (muutosikkuna). Saattaa olla tarpeen luoda palautumissuunnitelma tilanteen varalta, että käyttöönotto epäonnistuu ja muutos on peruutettava.

Julkaisun- ja jakelunhallinta

Julkaisunhallinta ja jakelunhallinta hallinta ovat palvelunhallinnassa läheisesti toisiinsa liittyviä mutta erillisiä prosesseja.

Yksinkertaisesti sanottuna julkaisunhallinta koskee mitä ja milloin palvelu tai palveluelementti julkaistaan, keskittyen isompaan kuvaan ja varmistaen linjauksen liiketoimintatavoitteiden kanssa, kun taas jakelunhallinta koskee miten, käsitellen teknisiä yksityiskohtia uuden tai päivitetyn palvelun ottamisesta käyttöön ja toimintaan.

Tavoitteet

Julkaisun- ja jakelunhallinnassa hallinnan päätavoitteet ovat suunnitella, aikatauluttaa ja hallita julkaisujen siirtymistä testaus- ja tuotantoympäristöihin. Näiden ensisijainen tavoite on varmistaa, että tuotantoympäristön eheys suojataan ja että oikeat komponentit julkaistaan.

Hyödyt

Hyvin rakenteellisen julkaisun- ja jakelunhallintaprosessien toteuttamisen tärkeimmät hyödyt ovat seuraavat:

Parannettu palvelun laatu: Hallitsemalla julkaisuja tehokkaasti voidaan vähentää muutosten negatiivista vaikutusta palvelun laatuun;
Parannettu riskienhallinta: Tunnistamalla ja hallitsemalla julkaisuihin liittyviä riskejä voidaan minimoida tuotantoympäristön häiriöitä;
Lisääntynyt tehokkuus: Julkaisun ja jakelun prosessien virtaviivaistaminen johtaa resurssien tehokkaampaan käyttöön.

Prosessi

Suunnittele julkaisu: Määrittele julkaisun laajuus, aikataulu ja tarvittavat resurssit.
Rakenna ja testaa: Kehitä julkaisupaketti ja suorita perusteellinen testaus varmistaaksesi, että se täyttää toiminnalliset ja ei-toiminnalliset vaatimukset. Harkitse käyttäjien, turvallisuuden, laadun ja muiden vaatimusten testaamista.
Julkaisun valmiuden tarkistus: Varmista, että kaikki julkaisun osat ovat valmiita käyttöönottoa varten; tähän voi sisältyä käyttäjädokumentaation päivittäminen ja tukitiimien kouluttaminen tai valmistelu tukemaan julkaisua kohdeympäristössä.
Ota käyttöön: Siirrä julkaisupaketti tuotantoympäristöön jakelusuunnitelman mukaisesti.
Arvioi ja sulje: Käyttöönoton jälkeen arvioi julkaisuprosessi oppiaksesi mahdolliset opit ja sulje julkaisu virallisesti. Tämä voi sisältää ongelmatikettien tai häiriöiden sulkemisen, joita jakelun on tarkoitus ratkaista. Kaikki julkaisuun liittyvät muutokset tulisi myös päivittää.

Yleiset sudenkuopat

Viestinnän puute: Heikko viestintä tiimien välillä voi johtaa väärinkäsityksiin ja virheisiin julkaisuprosessin aikana;
Riittämätön testaus: Riittämätön testaus voi johtaa julkaisuihin, jotka aiheuttavat enemmän ongelmia kuin ratkaisevat;
Huono suunnittelu: Ilman perusteellista suunnittelua julkaisut voivat kärsiä viivästyksistä, resurssipulasta ja paisumisesta;
Riskien hallinnan laiminlyönti: Riskien tunnistamatta ja hallitsematta jättäminen voi johtaa odottamattomiin ongelmiin käyttöönoton aikana;
Riittämätön dokumentointi: Julkaisun ja sen komponenttien riittämätön dokumentointi voi johtaa sekaannukseen ja vaikeuksiin vianmäärityksessä.

Toimita

ITSM.express-lähestymistavan kolmas vaihe sisältää kattavan lähestymistavan IT-palvelujen suojaamiseen, mittaamiseen ja parantamiseen. Täällä suunnitellut, rakennetut ja toimitetut palvelut suojataan toimintaympäristön uhilta. Monet näistä uhista tunnistettaisiin ja kirjattaisiin riskirekisteriin määrittelyvaiheessa, vaikka uusia uhkia voidaan ja pitäisi tunnistaa ja hallita kaikissa vaiheissa. Tässä Toimita-vaiheessa olisi myös varmistettava, että palveluntarjoaja täyttää aiemmissa vaiheissa antamansa lupaukset mittaamalla palvelun ja palveluntuottajan suorituskykyä. Tässä vaiheessa meitä kehotetaan myös sitoutumaan kuluttajille tarjottavien palvelujen jatkuvaan parantamiseen. Parannusmahdollisuuksia voidaan tunnistaa palveluiden mittaamisen ja myös innovaatioiden kautta.

Suojaa - Tietoturvallisuus

Tavoitteet: Tietoturvallisuudessa on otettava käyttöön riskiperusteinen lähestymistapa käyttäen ohjeistusta riskienhallinnassa Määritä-vaiheessa. Jälleen kerran, tässä käytetään ISO 31000 -standardia ylätason ohjeistuksena. Tärkeä huomio tietoturvasta on, että kaikkien palveluntuottajan organisaatiossa sekä toimittajien, kumppaneiden ja kuluttajien on myönteisesti edistettävä tietoturvaa. Tietoturvallisuuden uhkakenttä kehittyy jatkuvasti, joten on tärkeää pysyä edellä säännöllisesti päivittämällä riskinarviointeja ja lieventämisstrategioita. Tämä ennakoiva lähestymistapa auttaa ylläpitämään tehokasta tietoturva-asemaa ja varmistamaan myös asianmukaisen tietoturvan ja yksityisyyden säännösten noudattamisen.

Prosessi

Tietoturvariskien tunnistamiseksi on ensin ymmärrettävä, mitä on suojattava. On tärkeää tunnistaa ja tallentaa tietoturva-omaisuudet ymmärtäen, kuinka kriittisiä tai arvokkaita nämä omaisuudet ovat palveluntarjoajalle ja kuluttajille. Tietoturvaomaisuus voi sisältää fyysisiä tietoja (esim. paperiasiakirjoja) sekä digitaalisia ja henkilökohtaisia tietoja. Tämä vaatii palveluntuottajaa soveltamaan asianmukaisia suojelutoimenpiteitä eri tietoturvaomaisuudelle.

Pääsynhallinta

Pääsynhallinta viittaa prosesseihin ja teknologioihin, joita käytetään hallitsemaan ja seuraamaan pääsyä verkon resursseihin, sovelluksiin ja tietoihin. Sen tarkoituksena on varmistaa, että vain valtuutetut käyttäjät ja järjestelmät voivat käyttää tiettyjä tietoja ja toimintoja, mikä parantaa turvallisuutta ja säädösten noudattamista. Pääsynhallinta on kriittistä tietojen luottamuksellisuuden, eheyden ja saatavuuden ylläpitämiseksi. Kontrolloimalla kuka pääsee mihin, organisaatiot voivat suojata arkaluonteisia tietoja luvattomalta pääsyltä, estää tietomurtoja ja noudattaa määräystenmukaisuusvaatimuksia.

Mittaaminen

Tavoitteet: IT-palveluiden tehokas mittaaminen on tärkeää suorituskyvyn ymmärtämiseksi, palvelun toimituksen parantamiseksi ja kuluttajien tarpeiden ja liiketoimintatavoitteiden kanssa linjaamiseksi.

Prosessi

Osana tätä prosessia tulisi määrittää, mitä tietoja kerätään ja miten näitä tietoja tulkitaan ja käytetään suorituskykymittareihin, mukaan lukien oikeiden työkalujen ja prosessien valitseminen. Esimerkiksi palveluntuottaja voi käyttää automaattisia monitorointityökaluja järjestelmän suorituskyvyn seuraamiseen tai kyselyitä kuluttajien tyytyväisyyden mittaamiseen. Mittaustoiminnot, erityisesti kun ne ovat automatisoituja, voivat tuottaa suuria määriä dataa, joten on tärkeää ymmärtää, mitä dataa kerätään ja miksi: mikä on datan arvo organisaation tavoitteiden kannalta?

Parantaminen

Tavoitteet: Kuten riskienhallinnassa ja tietoturvassa, kaikki palveluntarjoajan organisaatiossa, toimittajat, kumppanit ja kuluttajat voivat myönteisesti edistää jatkuvaa parantamista. Organisaation tulisi oppia asiakaspalautteesta sekä mitatuista, analysoiduista ja raportoiduista tiedoista ja parantaa palvelun toimitusta, saavuttaa paremmin palvelutavoitteet ja liiketoimintatarpeet tai parantaa palvelutavoitteita itseään.

Prosessi

Yksinkertainen ja suoraviivainen lähestymistapa jatkuvaan parantamiseen sisältää seuraavat vaiheet:

Tunnista parannusmahdollisuus: Tunnista alueet, joilla palvelu ei vastaa odotuksia, missä prosessit tai toimintatavat ovat tehottomia tai missä on muita parannusmahdollisuuksia.
Ymmärrä nykyinen tila: Tutki nykyistä palvelua, prosessia tai muuta parannuksen kohdetta saadaksesi oikean lähtötilan ennen parannusta ja ymmärtääksesi, mitä parannuksia voidaan tehdä.
Aseta selkeät ja realistiset tavoitteet: Kun tiedetään, mitä tarvitsee parantaa, organisaation tulisi asettaa selkeät, mitattavissa olevat tavoitteet, jotka ovat saavutettavissa.
Suunnittele parannus: Perustuen analyysiin, kehitä suunnitelma parannusten tekemiseksi. Tämä pitäisi sisältää erityiset toimet, tarvittavat resurssit ja aikataulun.
Toteuta parannus: Toteuta suunnitelma ja vie se käytäntöön. Tämä voi sisältää henkilöstön kouluttamista uusissa toimintatavoissa, laitteiston tai ohjelmiston päivittämistä, prosessivaiheiden hienosäätöä tai poistamista, kontrollien lisäämistä tai viestintätapojen muuttamista asiakkaiden kanssa.
Seuraa ja arvioi parannusta: Parannusten toteuttamisen jälkeen seuraa tarkasti palvelua nähdäksesi, toimivatko parannukset. Mittaa parannusta käyttämällä samoja mittareita ja tavoitteita, jotka asetettiin parannustavoitteiden asettamisen yhteydessä.

Vastaa

Palveluntuottajien on usein kommunikoitava kuluttajien kanssa osana palvelun tarjoamista - erityisesti palveluiden loppukäyttäjien kanssa, riippumatta siitä, aloitetaanko tämä kommunikaatio palveluntuottajan tai käyttäjän toimesta.

On tärkeää omata selkeästi määritellyt kommunikointitavat, jotka tarjoavat myös auditoitoitavuuden. Paras tapa tehdä tämä on tarjota yksi yhteyspiste, kuten palvelupiste; tätä ei kuitenkaan pidä käsittää yhtenä ainoana yhteydenottotapana.

Vastausprosesseja ohjaavat viestintä, jota yksi yhteyspiste helpottaa, ja järjestelmät, jotka on asetettu helpottamaan tätä viestintää. Nämä tarjoavat keinot eskalointiin, toiminnan ja tilan seurantaan sekä päivittäiseen mittaukseen ja hallintaan.

Palvelupiste

Tavoitteet: Palvelupisteen tavoitteet ovat:

Tarjota yksi yhteyspiste palvelun kuluttajille (ensisijaisesti käyttäjille);
Helpottaa palvelun palauttamista;
Ohjata käyttäjäpyyntöjä ja helpottaa niiden toteutumista;
Tarjota ensimmäisen tason ratkaisua häiriöille ja palvelupyynnöille mahdollisuuksien mukaan;
Kirjata ja seurata viestintää ja puuttua asiaan, jos prosessitoimet eivät täytä laatuvaatimuksia (tyypillisesti määritelty SLA:ssa);
Olla kanava tehokkaaseen asioiden käsittelyyn, kun palveluntarjoaja riippuu kolmansien osapuolten tuesta (esim. eskalointien hallinta).

Hyödyt

Käyttäjät tietävät tarkalleen, keneen ottaa yhteyttä ja kuinka ottaa yhteyttä palveluntuottajaan;
Ongelmat (ensisijaisesti häiriöt) ja palvelupyynnöt voidaan kirjata ja siten hallita palvelustandardien noudattamisen varmistamiseksi;
Kirjattua tietoa voidaan käyttää:
- palvelujen ja palvelukomponenttien parantamiseen;
- palveluntuottajan suorituskyvyn raportoimiseen;
- palvelun tilan paremman ymmärtämiseksi tulevan palveluarvon parantamiseksi.

Prosessi

Palvelupiste tyypillisesti:

Kirjaa käyttäjäpyynnöt (häiriöt ja palvelupyynnöt);
Vastaa käyttäjäpyyntöihin tarjoamalla ensimmäisen tason tukea;
Kommunikoi kolmansien osapuolten kanssa, joista palvelu riippuu;
Tarjoaa käyttäjille palautetta;
Pitää sidosryhmät ajan tasalla (esim. palvelukatkosten aikana);
Raportoi kerätyistä tiedoista keskeisille sidosryhmille.

Yleiset sudenkuopat

Liiketoiminnan (käyttäjäkontekstin) ymmärtämisen puute: Palvelupisteen henkilöstön on ymmärrettävä, kuinka kuluttajan liiketoiminta toimii ja tunnistettava välittömästi, liittyykö käyttäjän kysely liiketoiminnan kriittiseen elementtiin.
Teknisen ymmärryksen puute: Palvelupisteen henkilöstön on ymmärrettävä palvelujen suunnittelu ja palvelukomponenttien väliset riippuvuudet sekä oltava teknisesti taitavia ratkaisemaan suurin osa kyselyistä ensimmäisellä yhteydenotolla.
Oikeiden tietojen ja integroitujen työkalujen puute: Palvelupiste ei voi toimia ilman asianmukaisia tukityökaluja, ja koska palvelupistetyökaluja käytetään usein tuki- ja teknisen hallinnan toiminnoissa, tarvitaan huolellista harkintaa, valintaa ja investointeja. Integroitu palvelunhallintajärjestelmä on tarpeen tämän työn suorittamiseksi.
Viestintätaitojen ja empatian puute: Palveluntuottajien tulisi investoida koulutukseen, joka auttaa agentteja kommunikoimaan paremmin ja empaattisemmin käyttäjien kanssa.

Käyttäjien pyyntöjen ratkaiseminen

Tässä esitellään yksinkertainen prosessi kaikkien käyttäjien pyyntöjen käsittelyyn. Nämä voivat perinteisessä palvelunhallinnan terminologiassa olla häiriöitä, palvelupyyntöjä ja jopa ongelmia.

Esitetty prosessi on yksinkertainen peruslinjaus, jota voidaan aina laajentaa organisaation tarpeiden kehittyessä; kuitenkin monimutkaisuus tuo mukanaan monia lisähaasteita.

Prosessi

Kokonaisprosessi palveluihin liittyvien pyyntöjen kattavaan käsittelyyn sisältää seuraavat aktiviteetit:

Tallenna, luokittele ja aseta pyynnön prioriteetti: Kun käyttäjien pyynnöt kirjataan, palvelupisteen agenttien tulisi ymmärtää palvelut riittävän hyvin, jotta he voivat kirjata kyselyn oikein, luokitella pyynnön tyypin ja määritellä sen prioriteetin liiketoimintavaikutuksen tai -kiireellisyyden perusteella.
Palvelupiste: Palvelupisteen tulisi pystyä tehokkaasti helpottamaan käyttäjien pyyntöjä riippumatta siitä, mikä oli käyttäjän yhteydenottotapa.
Tarjoa tietoja: Organisaatiot valmistavat usein standardivastauksen usein kysyttyihin kysymyksiin (FAQ), joka on kätevä lähde käyttäjien pyyntöihin vastaamiseen.
Pääsyoikeudet: Pääsyoikeudet ovat loppukäyttäjien lupia päästä resursseihin, kuten sovellusten käyttöön tai asiakirjoihin pääsyyn.
Palvelun palautus: Epäonnistuneiden tai heikentyneiden palvelujen palauttaminen vaatii usein teknistä osaamista, mutta syvällistä teknistä tietämystä ei aina tarvita, jos aiemmat ponnistelut on asianmukaisesti kirjattu ja niitä käytetään viitetietokantana.
Juurianalyysi ja ratkaisujen toteutus: Kaikki palvelun heikentymiset ja epäonnistumiset, joilla oli merkittävä vaikutus kuluttajan liiketoimintaan, on tutkittava edelleen (palvelun palauttamisen jälkeen) niiden perimmäisten syiden selvittämiseksi.
Sulkeminen ja raportointi: Kaikki pyynnöt tulisi virallisesti arvioida ja sulkea; tämä voi usein olla niin yksinkertaista kuin kysyä käyttäjältä, joka kirjasi pyynnön, ovatko he tyytyväisiä tarjottuun vastaukseen ja ratkaisuun.

Yleiset sudenkuopat

Kirjauksen, seurannan, vastaamisen ja ratkaisemisen kurinalainen lähestymistapa: Tämä usein tarkoittaa merkittävää koulutusta asiakkaille ja palveluntarjoajan henkilöstölle. Kaikkien tulisi ymmärtää, mitä tehdään, miten se tehdään ja mitä odottaa.
Teknisesti taitamattomat palvelupisteen agentit: Palvelupisteen agenttien tulisi olla hyvin perehtyneitä prosessiin ja heillä tulisi olla oikeat taidot, tiedot ja teknologia sujuvan käyttäjäkyselyjen ratkaisemiseksi.

Lisätietoja

Lisätietoja palvelupisteen toiminnasta ja käyttäjäkyselyiden ratkaisemisesta löytyy palveluraportoinnin prosessista.