Search:

KATSE PROJEKTITOIMITUSTEN YLI

Jatkuvuus on uusi musta!

Katse projektitoimitusten yli

Tässä HiQ:n palvelunhallinnan kolmiosaisessa blogisarjassa käsitellään tietojärjestelmäprojektien ja asiantuntijapalvelujen toimittamiseen liittyviä haasteita. Ratkaisuja haasteisiin löydetään jatkuvuudenhallinnan ja modernin palvelunhallinnan kautta.

Blogista on jo aiemmin julkaistu osat: Projektikeskeinen toimintatapa ja Tietotaito kertyy tekemisen kautta 

Jatkuvan palvelun sopimus luo edellytykset kestävälle yhteistoiminnalle

Projektikeskeisen toimintamallin ongelmia voidaan ratkaista tarkastelemalla asioita yksittäisten työtilausten sijaan koko tietojärjestelmän elinkaaren perspektiivistä. Fokus ei silloin ole vain yksittäisessä työtilauksessa tai projektissa, ja niiden resursoinnissa, vaan katse kantaa kaikkien näiden toimitusten yli. Tällöin voidaan tehdä päätöksiä, jotka ovat hyviä nimenomaan jatkuvuuden ja riskinhallinnan kannalta. Käytännössä esim. kun valitaan asiantuntijoita uuteen toimitusprojektiin, niin jo siinä vaiheessa huomioidaan se miten töitä jatketaan kyseisen projektin jälkeen.  Näin löydetään kestäviä ratkaisuja, joilla toimituskyky ei kärsi asiantuntijoiden vaihtuessa.

HiQ solmii asiakkaidensa kanssa erillisen Jatkuvan palvelun sopimuksen, johon siirrytään projektin päätyttyä. Askelmerkit sille mitä tapahtuu, kun tietojärjestelmä otetaan käyttöön, on käyty asiakkaan kanssa läpi jo projektia aloittaessa. Kaikille osapuolille on silloin selvää, miten töitä jatketaan käyttöönoton jälkeen. Jatkuvan palvelun sopimuksessa kuvataan tietojärjestelmän koko elinkaaren aikana tarvittavat eri palvelut, toiminnot ja toimintatavat. Kuvattavia asioita on mm. se miten tietojärjestelmää valvontaan, miten häiriöitilanteita raportoidaan ja selvitetään, tai miten muutostöitä töitä tilataan, tehdään, ja seurataan.

Käytännössä Jatkuva palvelun sopimus ottaa kantaa mm. seuraaviin asioihin:

1) Järjestelmien toimintakyky, valvonta ja häiriönhallinta

2) Haltuunotto projektitoimituksista ylläpitoon

3) Asiantuntijapalveluiden toimituskyky asiakkaalle

4) Osaamisen ja työkuorman hallinta

5) Riskienhallinta

6) Asiakastyytyväisyys ja -palautteeseen perustuva jatkuva parantaminen.

Tyypillisiä jatkuvan palvelun komponentteja ovat ylläpitotoiminnot, kuten Service Desk -toiminnot ja häiriönhallinnan palvelulupaus, sekä palvelutasojen seuranta kuukausittain. Mitä tapahtui viime kuussa ja miten töistä suoriuduttiin? Mitä voitaisiin tehdä jatkossa paremmin? 

Haltuunotto varmistaa tietotaidon siirtymisen DevOps -tiimille

Ylläpitotoimintoja tuottavat toimittajilla yleensä eri asiantuntijat kuin alkuperäinen projektiorganisaatio. Puhutaan ”Operations” toiminnoista.  Ylläpidon tehtävien kautta osaaminen pikkuhiljaa kasvaa tähän ylläpitotiimiin. Kun ensimmäinen tietojärjestelmän muutospyyntö vastaanotetaan, huomataan, että operointiosaamisen lisäksi tarvitaan syvällistä ohjelmistokehitysosaamista, jota tällä tiimillä ei ole. On huomattavasti helpompaa operoida järjestelmää, ja esim. palauttaa sitä toimintakuntoon, kun se on joskus ollut toimiva, kuin esim. toteuttaa uusia muutoksia koko tuohon järjestelmään.

HiQ käyttääkin nykyään yhä enemmän ns. DevOps -tiimejä, jotka hallitsevat häiriönhallinnan ja operoinnin (Operations) lisäksi myös ohjelmistokehitystehtävät (Development). DevOps -tiimeihin organisoitumalla päästään tilanteeseen, jossa kaikki tarvittava ydinosaaminen on samassa hyvin skaalautuvassa tiimissä ja josta osaamista voidaan tuottaa useammalle asiakkaalle. Tämä vähentää asian pallottelua eri organisaation tiimien välillä ja tehostaa muutosten hallintaa.

Jatkuvuus otetaan huomioon jo projektin perustamisvaiheessa ottamalla DevOps tiimin jäseniä mukaan toteutusprojektiin. Tämä mahdollistaa tietotaidon säilymisen projektien yli. Lisäksi projektit päätetään aina huolelliseen haltuunottoon, jossa projektiorganisaatio luovuttaa ratkaisukokonaisuuden DevOps -tiimille. Haltuunottoa käsittelee Minna Peltokukka-Karhu ansiokkaasti aikaisemmassa blogikirjoituksessamme. 

Vaihtuvuuden minimointi ja Learning by Doing

Ohjelmistokehityksessä on niin monimutkaisia asioita käsiteltävänä, että tietotaito henkilöltä toisella ei välity vain dokumentaatiota lukemalla tai pikaisen haltuunottoprojektin kautta. Syvällinen perehtyminen tapahtuu töitä itse tekemällä (learning by doing). On ensiarvoisen tärkeää, että DevOps -tiimissä on tarpeeksi monta asiantuntijaa heti alusta asti jakamassa asiakkuuden töitä keskenään. Tällöin ratkaisuosaamisen henkilöitymisriski minimoidaan ja varaudutaan siihen, että tiimin kokoonpano voi jatkossa hieman elää.

Jokainen asiantuntija, joka ei ole ollut asiakkuudessa mukana viimeisenä kolmena kuukautena joutuu työtehtävissään helposti ns. ”perehdytyslimboon”, jossa hän perehtyy asioihin uudestaan ja uudestaan, vain hetken päästä unohtaakseen nämä asiat kun hänet allokoidaan muihin tehtäviin. Tämä jatkuva perehtyminen laskee tehokkuutta ja luo kustannuksia asiakkaalle. Myös jokainen uusi asiantuntija aiheuttaa lisää hallintotyötä - esim. haetaan käyttäjätunnuksia ja käyttöoikeuksia eri resursseihin. Vastaavasti myös asiakkuudesta pois lähtevät asiantuntijat aiheuttavat hallintotyötä kun käyttäjätunnuksia poistellaan tai deaktivoidaan.

Vaihtuvuutta ei voida kokonaan estää, mutta se voidaan minimoida ja siihen voidaan valmistautua niin, että jatkuva perehtymisen tarve ja turhien hallintokulujen synty estetään.

Tasainen työvirta mahdollistaa osaamisen säilymisen

Tehtiin töitä millä mallilla tahansa, niin osaaminen ja hyvä toimituskyky eivät säily, jos töitä ei tehdä. Töitä pitää siis olla jatkuvasti. Jos tekemistä on liian vähän, niin työtehtäviä ei ole mahdollista jakaa DevOps -tiimin jäsenille vaan ne ohjautuvat yksittäisille ohjelmistokehittäjille, ja tällöin riski henkilöitymisestä kasvaa. Jos työt taas jakautuvat epätasaisesti ajan suhteen (kuukausittain), niin se vaikeuttaa merkittävästi toimittajan varautumista näihin töihin ja heikentää jatkuvuuden hallintaa.

Työvirta saadaan tasaiseksi tehokkaalla backlog hallinnalla ja hajauttamalla muutostöitä kalenteriajallisesti sen mitä töiden kiireellisyydet antavat periksi. Tasainen työvirta mahdollistaa myös paremman kustannusten ennustettavuuden asiakkaalle.

Palvelupäällikkö vastaa palvelun seurannasta

Palvelun jatkuvuutta, toimintamenetelmiä, sekä kokonaistoimitusta koordinoi toimittajan palvelupäällikkö. Palvelupäällikön tehtäviin kuuluu mm. raportoida asiakkaalle, miten palvelulupaus toteutuu, käynnistää tarvittavat toimet häiriötilanteiden vähentämiseksi, ja kertoa mitä toimituksissa tapahtuu seuraavaksi. Palvelupäällikkö myös seuraa asiakastyytyväisyyttä ja kehittää sen perusteella palvelua jatkuvasti paremmaksi.

Palvelupäällikkö myös huolehtii siitä, että DevOps asiantuntijapooliin välittyy arvio kapasiteettitarpeesta, jonka perusteella linjaesimiehet voivat tiimeistään tuottaa tämän tarvittavan kapasiteetin. Palvelupäällikkö ei korvaa projektipäällikköä, vaan projekteihin edelleen nimetään erillinen projektipäällikkö He tietenkin tekevät yhteistyötä. Tietyissä tilanteissa palvelupäällikkö voi kuitenkin huolehtia esim. pienkehitystehtävien ohjauksesta, tai pienen projektin läpiviennistä.

Lisää palvelupäällikön tehtävistä voi lukea Nea Tammisen blogikirjoituksesta Palvelupäällikön päivä

 Kiinnostuitko? 

Ota yhteyttä!  

Kuulostiko projektin päättymiseen, osaamisen hallintaan ja vaihtuvuuteen liittyvät haasteet tutuilta?

Lue asiasta lisää Jatkuvista palveluistamme ja laita viestiä niin tulemme sparrailemaan aiheesta lisää! 

 

Sami Merovuo

sami.merovuo@hiq.fi
Sami Merovuo toimii palvelupäällikkönä HiQ:n avainasiakkuuksissa.

Haluatko meille töihin?

Olemme digitaalisen ajan käsityölaisiä ja suhtaudumme työhömme intohimolla. Meillä pääset toteuttamaan upeita projekteja Suomen suurimmille yrityksille sekä luomaan kokonaan uusia, markkinoita muuttavia palveluita. Töihin HiQ:lle? HiQ kasvaa ja etsimme aktiivisesti joukkoomme uusia osaajia!

Ota yhteyttä!