”Johtajalla on oikeus tulla voitetuksi, mutta ei milloinkaan yllätetyksi.”
– Napoleon Bonaparte
IT-ratkaisun tuotantovaiheen tukemisella pyritään ennakoimaan ja selvittämään jo tuotantoon siirtyneen järjestelmän ongelmia. Esimerkiksi teknologioiden ja ohjelmistoversioiden rajallisten elinkaarien aiheuttamilta yllätyksiltä voidaan välttyä ennakoimalla ja kehittämällä kokonaisarkkitehtuuria. Teknisen tiimin, loppukäyttäjien ja koko liiketoiminnan tyytyväisyyttä voidaan taas parantaa panostamalla ylläpito- ja tukityön toimintamallien jatkuvaan kehittämiseen. Kaikkia ongelmia ei voida aina ennakoida, minkä vuoksi häiriöt on pystyttävä ratkaisemaan nopeasti. Näin vähennetään merkittävästi liiketoiminnan jatkuvuudelle aiheutuvia riskejä sekä häiriöiden seurausten ja selvitystyön kustannuksia.
Tarjoamani IT-ratkaisun tuotantovaiheen tukeminen voi kohdistua esimerkiksi johonkin seuraavista osa-alueista:
Kokonaisarkkitehtuurin kehittäminen
Ylläpito- ja tukityön katselmointi
Tuotantohäiriöiden selvityksen johtaminen
Case-esimerkki
IT-ratkaisun kriittisen tuotanto-ongelman ratkaisemisen johtaminen
Logistiikkayritys oli toteuttanut IT-projektin ja ottanut käyttöön uuden asiakkuudenhallintajärjestelmän (CRM), jonka uudet toiminnallisuudet ja raportointiominaisuudet palvelivat erinomaisesti liiketoiminnan tarpeita. Kahden kuukauden kuluttua käyttöönotosta uudessa järjestelmässä alkoi esiintyä hitautta ja useamman kerran viikossa tietojärjestelmä kaatui ennakoimattomasti kokonaan, mikä aiheutti vakavaa haittaa asiakaspalvelutyöntekijöille ja operatiiviselle toiminnalle. IT-ratkaisuun liittyi useita IT-toimittajia ja useita tietojärjestelmien välisiä rajapintoja.
Asiakas pyysi Cheetah-konsultin johtamaan tietojärjestelmän suorituskykyongelmien selvitystä. Työlle sovittiin seuraavat välitavoitteet: 1) virhetilanteen ennakointi (tunnistetaan milloin virhetilanne tapahtuu/lähestyy), 2) virhetilanteen välttäminen (virheen ilmenemistodennäköisyyden pienentäminen) 3) virhetilanteesta toipumisen nopeuttaminen (nopeat korjaavat toimenpiteet), 4) juurisyyn selvittäminen ja korjaaminen. CRM-järjestelmän monitoimittajaympäristö koostui sisäisten sidosryhmien lisäksi seitsemästä ulkoisesta toimittajasta: i) ohjelmistotoimittaja, ii) projektitoimittaja, iii) sovelluspalvelutoimittaja, iv) infrastruktuuripalvelutoimittaja, v) muiden riippuvien järjestelmien ja integraatioiden palvelutoimittajat, vi) etäkäyttöpalveluiden (Citrix) toimittaja, vii) verkkopalvelutoimittaja.
Ongelmanselvitys käynnistettiin ensin toimittajien i-iv kanssa, koska ongelmien juurisyy ilmeni itse tietojärjestelmässä. Jokaiselle toimittajalle sovittiin tehtävät, jotka piti selvittää välittömästi: i) ohjemistotoimittajan tuli katselmoida sovellus- ja infrastruktuuridokumentaatio best practiseita vasten, tarkastaa ohjelmiston lokit, ehdottaa tapoja saada lisää ongelmanselvitystietoa järjestelmästä (debuggerit, monitorit, dumpit jne.), ii) projektitoimittajan tuli tarkastaa sovelluslokit ja tarpeen mukaan lisätä loggausta, tehdä arvio järjestelmään tehtyjen kustomointien vaikutuksesta suorituskykyyn, muodostaa käsitys skaalautuvuudesta datan ja käyttäjien määrän suhteen, iii) sovelluspalvelutoimittajan tuli koostaa lista muutoksista, joita järjestelmän ohjelmakoodiin tai konfiguraatioon on tehty käyttöönoton jälkeen, iv) infrastruktuuritoimittajan tuli kytkeä päälle infrastruktuurin (muisti, prosessori) monitorointi ja koostaa lista viimeaikaisista infrastruktuurimuutoksista.
Selvitystyötä tehtiin noin 15 tuntia päivässä. Jo kuuden tunnin selvitystyön jälkeen virhetilanne tunnistettiin sovelluspalvelimen lokeista siten, että se pystyttiin ennakoimaan. Virhetilanteen todennäköisyyttä pienennettiin sopimalla liiketoiminnan kanssa huoltoikkunasta, jolloin sovelluspalvelin voitiin uudelleenkäynnistää (joka päivä klo 06.00-06.15, 12.00-12.15 ja 18.00-18.15). Tämän käytännön jälkeen virhe ei enää ilmennyt, joten asiantuntijat keskittyivät juurisyyn löytämiseen. Kahden vuorokauden selvitystyön jälkeen juurisyy löytyi siitä, että kustomoitu sovelluskoodi sisälsi projektitoimittajan alunperin tekemän, mutta sovellusylläpitotoimittajan muokkaaman synkronisen tarkistuksen, joka suoritettiin noin 50 % käyttäjän toiminnoista vaikka tarkistus olisi tarvinnut suorittaa vain alle prosentille käyttäjän toiminnoista. Lisäksi tämä tarkistuslogiikka hidastui aina, kun järjestelmään tuli lisää historiadataa. Ongelma paheni, kun infrastruktuuritoimittaja oli asentanut samalle fyysiselle palvelimelle asiakkuudenhallintajärjestelmän kanssa kaksi uutta virtuaalipalvelinta kommunikoimatta tätä projekti- tai sovelluspalvelutoimittajalle. Lopuksi Cheetah-konsultti katselmoi toimittajan dokumentaation, toimintatavat ja tuotokset sekä ehdotti parannuksista liittyen toiminnan laatuun, vastuunjakoon, yhteistyömalliin muiden palvelu-, projekti- tai ohjelmistotoimittajien kanssa.
Cheetah Consulting Oy
(Y-tunnus 2442443-0)
