Asiakkaan tyypillinen dataongelma

Millainen voisi olla tyypillinen tietotekniikan ratkaisutoimittajan asiakas? Esimerkkinä voisi olla yritys, kutsutaan tässä vaikka ’Nappaa-auto’, joka otti kesällä yhteyttä ratkaisutoimittajaan. Syynä oli, että heidän yritystoimintansa kulmakivi, vuokra-autojen varausjärjestelmä, ei toiminut toivotulla tavalla. Sovellus sakkasi, eivätkä Nappaa-auton asiakkaat voineet tehdä varauksiaan järjestelmään. Se toimi hitaasti ja kaatui useiden asiakkaiden yrittäessä tehdä varauksiaan yhtä aikaa. Tietenkin on hyvä, että on samanaikaisesti paljon asiakkaita varaamassa autoja mutta se on paha, jos he eivät onnistu tekemään sitä. Tässä tilanteessa osa asiakkaista kaikkosi ja kääntyi toisten toimittajien puoleen. Yritykselle tällainen tilanne on painajainen, rahat kun valuvat helposti toisen yrityksen laariin.

Kun Nappaa-auto otti yhteyttä, oli tilanne jo niin hankala, että ruuhkaisena aikana varauksia ei voitu tehdä lainkaan. Pelkona oli, asiakkaat päätyisivät kokonaan kilpailijoiden syliin. Yrityksen IT oli tutkinut ongelmaa, mutta syyn löytäminen oli vaikeaa. Nykyisellä valvontasysteemillään Nappaa-auto sai vain ilmoituksen, että ’asiakasjärjestelmä ei vastaa’. Syytä tähän ei systeemi tietenkään ilmoittanut. Varausohjelmiston toimittaja syytti järjestelmän toimimattomuudesta Nappaa-autoa erilaisilla verukkeilla. Nappaa-auto oli ajautunut tilanteeseen, että he eivät tienneet mitä tehdä asian korjaamiseksi. Koko yritystoiminta oli pian vaarassa.

Kuinka ongelmaa oli ensin tutkittu? Ohjelmiston toimittaja katsoi omaa dataansa, eikä vika ei ollut siellä. Vakioselitys oli: ”asiakkaan järjestelmä on vain liian hidas”. ’Outside-In’ kertoi, että on ongelma, mutta se ei kertonut missä ja miksi.

Napaa-auton kerrottua ongelmastaan, ratkaisutoimittaja lupasi selvittää asiaa. Nappaa-auton järjestelmään asennettiin uudenlainen analysointityökalu. Jo pian asentamisen jälkeen se analysoi yrityksen dataa selväkielisesti. Nykyaikainen analysointityökalu näyttää asiakkaan sovelluksen ’Inside-Out’ -näkökulmasta. Näin nähtiin järjestelmän sisälle ja missä ongelma piili ja mikä oli sen juurisyy. Työkalu näytti selkeästi, mitkä sovelluskomponentit kärsivät järjestelmäresurssien puutteesta, tai olivat muuten huonosti koodattu. Ohjelmiston toimittaja oli todella yllättynyt, kun toimimattoman järjestelmän yksityiskohdat piirtyivät suoraan tietokoneen näytölle: ”Ei voi olla totta! Noinko selkeästi virhetilanne voi tosiaan näkyä”.

Ongelma ratkaistiin korjaamalla ohjelmakoodia, lisäämällä resursseja oikeisiin paikkoihin, ajastamalla massaoperaatioita järkevämmin ja tekemällä muita pieniä parannuksia. Näin saatiin nopeita voittoja edullisesti. Nyt Napaa-auton varausjärjestelmä toimii kuten sen pitääkin ja autojen käyttöasteessa tehtiin uusi ennätys.