perjantai 14. kesäkuuta 2013

Keskittäisinkö service deskin?

"Tervetuloa service deskiin. Puhelunne on meille hyvin tärkeä. Jos asianne koskee liiketoimintasovelluksia, valitkaa yksi. Jos asianne koskee tietoliikenneyhteyksiä, valitkaa kaksi. Jos asianne koskee työasemaa, valitkaa kolme. Jos puhelimenne on rikki, valitkaa neljä. Voitte myös käyttää itsepalveluportaaliamme osoitteessa veeveevee..." ARRGHH!!

Mihin mää nyt sit soitan?!

Eipä tuo nyt niin kaukaa haettu tilanne ole, puhelinvalikot auttavat tehostamaan ja automatisoimaan tukea. Tärkeämpi asia on, miten koko juttu pidetään kasassa - miten se vika oikeasti selvitetään ja syy löydetään pompottelematta käyttäjää pitkin poikin. Alla on ihan oikea esimerkki elävästä elämästä, miten lopulta kävi ilmi että yhden sovelluksen salasanan muutos kännykässä esti ERPin käytön. Ja voi voi kun ne tukipalvelut oli hajautettu hallitsematta...

"Ottakaa yhteyttä luukulle 42"

Mutta kun....

sehän kuuluu jo sen ostetun palvelun hintaan. Työasematoimittajalle maksetaan jo Service Desk ja sehän reitittää kyllä kaikki oikeaan paikkaan. Vaatii tietenkin ohjeistuksen ja vastuurajapintojen sopimisen - mihin sovellusviat osoitetaan, mihin mobiiliviat, mihin...tai jos puhelut ohjataan valikosta eri toimittajille, pitäisikö siitä saada jotenkin kokonaisuus kiinni? Ja mitäs se nyt maksaakaan kun perussopimuksen päälle lähdetään rakentamaan reitityksiä eri paikkoihin?

Pitäisikö hankkia kuitenkin oma

Huonosti toimiva tukipalvelu on yleisimpiä syitä IT:n asiakastyytymättömyyteen ja CIOn imagoon. Tarjoamalla asiantuntevaa käyttäjäpalvelua yhdestä pisteestä voi pelastaa paljon: käyttäjien työaikaa säästyy, perussyy löytyy helpommin, keikka pysyy kasassa ja tieto kumuloituu, tutkinta ei aina ala alusta. Oma service desk on sitoutunut yrityksen toimintaan, sen kehittämiseen ja tuntee liiketoiminnan yleensä hyvin. Tai siis sen täytyy tuntea, muuten arvoa ei tule

Entäs jos asiakastuki ei kuulu yrityksen tai IT:n ytimeen?

Ei ole varaa resursoida ja liiketoiminta ei tykkää että olisi ihmisiä tekemässä tällaista työtä? Voihan sen ostaa ulkoakin.

Yksi parhaista näkemistäni ulkoisista järjestelyistä on ammattitaitoinen, globaali (= kielituki) yhtenäisenä ulkoistettu, korporaatiolle dedikoitu service desk. Follow-the-sun, resursointi- ja liiketoimintaympäristön koulutus ulkoistettu, SD koordinoi käytännön operaatiot eri toimittajien välillä. Tässä tapauksessa konserniin jäi kuusi incident manageria (2 / manner) ja yksi Service Desk -manageri, joka vastasi kokonaisuuden toiminnasta. Yhtenäiset prosessit ja työkalut, eskalaatiopisteet aina tavoitettavissa. Fine.

Tärkeää

Paras vaihtoehto riippuu hyvin paljon yrityksen koosta ja tarvittavan tuen mittakaavasta. Hyvin standardoidussa ympäristössä edellinen esimerkki saadaan toimimaan nopeasti. Jos palveluita ja sovelluksia ei ole listattu, haetaan oppi siirtovaiheessa mutakuopan kautta. Kuten vanha kollega totesi kokemuksestaan - ensimmäiset 1,5 vuotta tietohallinto oli liiketoiminnan kynnysmatto.

Yhtenäinen työkalu tai integraatio kaikkien välillä ovat pakollisia. Tiketin täytyy kulkea yhtenäisenä ja pysyä ajan tasalla. Muuten pyöritellään päiden lisäksi peukaloita, kun yhtenäistä kuvaa tilanteeseen ei ole. Joillain aloilla viranomaisetkin asettavat tiettyjä vaatimuksia seurattavuudelle - kuka käski ketä ja miksi toissa vuoden tammikuussa, kun tunnukset varastettiin?

Työkaluja on nykyään niin paljon, että hinnan voi valita nollasta sataan. Nollavaihtoehtoja löytyi googlella heti -  http://www.spiceworks.com/free-help-desk-software/http://www.webhelpdesk.com/free-help-desk-software/http://www.hesk.com/http://www.otrs.com/en/http://help-desk-software.venturebeat.com/l/16/SimpleDesk.

Käyttöönotto kaikilla näillä vaatii sen palveluiden määrittelemisen, että voidaan osoittaa tiketit oikein ja automatisoida FLOW eri toimittajille. Asiakkaana voi olla jopa paras vaihtoehto edellyttää palvelutoimittajia käyttämään asiakkaan omaa järjestelmää. Näin homma pysyy omassa hallussa ja palvelutoimittajia voi joskus vaihtaakin.

Ulkoistaa, aih!

Niin, voi sen tuenkin ulkoistaa. Kannattaa vain harkita miten ja minkä osan tai palvelun, miten ja kenelle. Tein tällaisen kuvan hiljattain - kannattaa ensin suunnitella ja miettiä hallintamalli, sen jälkeen se ulkoistus voi käydä näppärästikin.

Moderni ulkoistus tehdään hallitusti

Service desk on tärkeä ja voi pelastaa paljon. Kannattaa uhrata ajatus jos toinenkin, mikä ero on toiminnallisesti jos käytössä on työasematuki, helpdesk tai oikea service desk.

lauantai 27. huhtikuuta 2013

Onko ITIL liian vaikea?

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

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

Onko palvelun määritelmä vaikea?

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

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

Entäs anti IT-osastolle?

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

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

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

Konfiguraationhallintaprosessi

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

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

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

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

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

Mikä siinä nyt oli niin vaikeaa?

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

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

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

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

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

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

Monimutkaista, sekavaa, teoreettista?

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

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

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





lauantai 9. helmikuuta 2013

Business solutions - liiketoiminnan IT-palvelut?

Eilen pidimme todella mielenkiintoista workshopia palveluiden määrittämisestä palveluportfolion ja –katalogin rakentamiseksi. Workshopin keskustelut jäivät pyörimään päähän ja tulostan nyt tämän hyörinän tähän.

Helpot ensin

Palveluiden määrittäminen oli aluksi helppoa: IT:n tuottamat loppukäyttäjäpalvelut(* ovat aika selkeitä, samoin tekniset palvelut. Muutama yleinen esimerkki, näihin niissä yleensä päädytään

Loppukäyttäjäpalveluita
  •  työasemapalvelu – laite, käyttis, office
  • viestintäpalvelut – email, pikaviestintä, videoneuvottelut,
  • service desk – neuvonta, tuki, häiriöilmoitukset
  • mobiililaitteet – kännykät, tabletit
  • etäyhteydet – mobiiliyhteydet tietokoneisiin, kotiyhteydet, vpn-ratkaisut


Tekniset palvelut
  • datacenter & palvelimet
  • tallennus
  • tietokannat
  • tietoverkot
  • alustat (middleware, sovellusalustat)

Business IT

Mutta sitten päästiin vaikeampaan asiaan. Miten kuvata ja nimetä IT:n liiketoiminnalle tuottamat palvelut? Miten ne voisi nimetä niin, että liiketoiminta ja IT ymmärtävät ne yhtenäisesti?

Liiiketoiminnan IT-palvelut ovat siis niitä palveluita, joilla tuetaan liiketoiminnan prosessien toteuttamista. Tietenkin näitäkin palveluita tuotetaan prosesseissa (esim. ITIL on ihan ok malli rakentaa nämä IT-prosessit!). Liiketoiminnan IT-palvelu koostuu teknologioista, ihmisten kompetenssista ja näistä prosesseista.

Loppukäyttäjäpalvelut ovat tietenkin myös liiketoiminnan IT-palveluita. Loppukäyttäjäpalveluita yrityksen työntekijät käyttävät päivittäisessä työnteossaan varsinaisten liiketoimintapalveluiden toteuttamiseen. Loppukäyttäjäpalveluidenkin palvelutasoista on syytä tehdä sopimus liiketoiminnan edustajien kanssa (esim. työasemien toimitusaika) mutta varsinainen käyttö ja tilaukset ovat yksittäisen käyttäjän tasolla.

Liiketoimintapalveluista sovitaan kokonaisuutena liiketoiminnan kanssa. Palveluiden sopiminen riittävän korkealla tasolla on oleellista yhtenäisen palvelu- ja odotustason saavuttamiseksi. Päätös tästä tasosta pitää tehdä yrityksen liiketoiminnan tarpeiden mukaan. Tästä se hyvä keskustelu lähtikin

Sovelluspalveluita

Käyttökielessä liiketoiminnan IT-palveluihin viitataan useimmiten sovelluksen nimellä. Käytetään SAPpia tai Kopaa,tai ehkäpä Claritya. Pitäisikö nämä palvelut siis kuvata näillä nimillä? Vai mieluummin käyttötarkoitusta kuvaavilla? Itse taipuisin käyttötarkoitukseen, ja se on toiminutkin.  IT-palveluita voivat siis olla esimerkiksi Myyntireskontra, korvauspalvelut tai resurssienhallinta.

Tämä sotkeutuu helposti liiketoimintaprosesseihin. Eihän IT hoida myyntireskontraa, korvauspalveluita tai resurssienhallintaa, sitähän tekee liiketoiminta. Nämä ovat kuitenkin selkeitä IT:n tuottamia sovelluspalveluita. Sovelluspalveluita…olisiko se sittenkin hyvä taso kuvata tämä osa IT:n palveluista liiketoiminnalle?

Sovelluspalvelun sisällön voisikin kuvata ylätasolla yhtenäisiksi. Mikä on se palvelu, jota IT antaa liiketoimintasovellusten tuottamiseen? Mitä palvelu sisältää? Kuvaus voisi olla vaikkapa tällainen:

Liiketoimintasovelluspalvelut – Business solution services
  • -          sovellustuotanto sovituilla palveluajoilla ja –tasoilla
  • -          sovellustuki
  • -          sovellusylläpito sisältäen pienkehityksen (tämä on syytä määritellä tarkkaan)
  • -         

Palvelua tuotetaan seuraaville liiketoimintasovelluksille:
  • -          myyntireskontra
  • -          korvauspalvelut
  • -          resurssienhallinta

tai
  • -          SAP
  • -          Kopa
  • -          Clarity

Kumpi avautuisi paremmin?

Rakennetaan liiketoimintaratkaisuille oma katalogi?

Kuvaamalla sovelluspalvelut yhtenä kokonaisuutena saadaan liiketoiminnan palvelukatalogi pidettyä järjellisen kokoisena. Sovelluspalvelu on yleensä (ja sen pitäisikin olla) suhteellisen samanlaista kaikille eri sovelluksille. Tietenkin on sovelluskohtaisia eroja ainakin palveluajoissa mutta myös teknisessä ylläpidossa, resursoinnissa jne.  Tästä voi rakentaa oman dokumenttinsa – Liiketoiminnan IT-sovelluspalvelut.

Minkä takia näitä palveluita sitten pitää kuvata?

IT:n pitää pystyä kertomaan liiketoiminnalle selkeästi, millaisia palveluita heiltä voi odottaa. Riippumatta sourcing-mallista, jokin taho yrityksessä vastaa tietotekniikasta. Vaikka IT:n toimittaisi Tietologicaenfocapgemini, on sen vastuu (accountability) yrityksessä. Toimittajat tuottavat pienempiä tai suurempia osia palvelusta sovituilla palvelutasoilla.

Palveluiden kuvaus tukee budjetointia ja kustannusten osoittamista oikein yrityksen sisällä. Myös sisäisen IT:n on syytä tuntea ja kuvata palveluidensa kustannusrakenne, koska niistä veloittamisen tulee perustua todennettuihin faktoihin. Kun palvelukokonaisuus ja palvelun rakenne on kuvattu, voidaan lähteä miettimään sen toteuttajaa: pitäisikö tehdä itse vai ostetaanko nuo kolme osaa joltain muulta palveluntarjoajalta? 

Selkeyttä ja logiikkaa luvassa, sano inssinööri!

(* loppukäyttäjä on ihan karmea termi. Mikä olisi parempi kuvaus käyttäjälle, end userille, työntekijälle?

keskiviikko 9. tammikuuta 2013

TIPA - lopultakin arviointimalli ITIL-kypsyydelle

Luxemburgista kuuluu kummia. Paikallinen tutkimuskeskus on panostanut jo vuosia prosessitutkimukseen ja koonnut ISO15504:n perustuvan prosessiarviointimallin ITILille.

ISO15504 eli SPICE - software process improvement and capability determination - on jo vakiintunut ohjelmistotuotannon prosessiarviointimalli. Se on oikeastaan aika siisti, koska se arvioi puolueettomasti ja moniulotteisesti prosessien kyvykkyyttä. Vähän niin kuin CMMI mutta kuitenkin erilailla.

Sertifioiduin aikanaan SPICE-assessoriksi ja käytimme sitä Sonera-aikana uuden liiketoiminnan kehittämisen tukena. Näin saatiin uusien hankkeiden mallit suoraan korkeammalle - ei korkeimmalle - lähtötasolle. Ainakin SPICE osoitti suorastaan sormella ne kehityskohdat, jotka estivät kyvykkyyden kasvun.

En ole vielä itse ehtinyt tutustua TIPAan mutta yritän, vaikka jotkut puhuvatkin TIPAttomasta tammikuusta. Tsekkaa itsekin, http://www.tipaonline.org/


Template by - Abdul Munir | Daya Earth Blogger Template