”Ripitystä riitti. Eikä tämä ollut ensimmäinen kerta”, huokaisi myyntijohtajamme Tapio Mustonen palatessaan Teklan luota.
Olimme täällä eCraftilla myyneet hankkeen, jossa tehtävämme oli luoda järjestelmä Teklan lisenssimyynnin automatisoimiseksi. Kuten elämässä yleensä, aivan kaikki ei sujunut suunnitelmien mukaan.
Tämä tarina on tosi ja sen opetukset istuvat nyt meissä tiukasti.
Alkusykäys
Muutama vuosi sitten Teklan IT-johtaja Harald Lundberg löysi eCraftin tiedot Microsoftin partnerisivuilta. Hänellä oli ongelma, johon BizTalk Server -integraatioalusta olisi sopiva ratkaisu. Hän tarvitsi pätevät tekijät.
Saimme tilauksen. Selvitimme, kuinka rakennusteollisuuden ohjelmistoja tuottava Tekla myi ohjelmistojensa lisenssejä ja piti niitä yllä. Tutkimme, kuinka prosessia voitaisiin parantaa automatisoinnilla. Samalla pitäisi hankkiutua eroon fyysisistä varmennusavaimista (donglet).
Ilmeinen tarve
Teklalla on asiakkaita yhdeksässäkymmenessä maassa. Teklan tapauksessa ohjelmistolisenssit ovat käytännössä käyttäjäkohtaisia tunnuksia. Käyttöoikeuksien tilauksia ja ylläpitosopimuksia putoilee sisään ympäri vuoden. Samaan aikaan niitä vanhenee ja ne pitäisi maksua vastaan uusia.
Koko hommaa pyöritettiin käsityönä. Jokaisella maayhtiöllä tuntui olevan hieman oma tapansa tehdä tätä. Osin tietoja läheteltiin sähköpostina maayhtiöiden ja pääkonttorin välillä.
Homma kyllä toimi. Mutta ei niin kuin pitäisi.
Osa asiakkaista valitteli, että uuden käyttäjätunnuksen saaminen kestää vuorokauden. Se tuntui pitkältä.
Teklan pääkonttori puolestaan tiesi, että osa asiakkaista sai ylläpitotukea, vaikka sopimus oli umpeutunut. Tämä ei ollut asiakkaiden syy. Tekla ylipalveli.
Jos sopimusjakso oli juuri päättynyt, eikä uusimisesta ollut varmaa tietoa, Tekla antoi tukea kaiken varalta. Asiakas sai ilmaisia päiviä tai viikkoja kahden ylläpitojakson välissä. Tämä tietysti johti siihen, että maksut tuloutuivat hitaammin tai pienempinä.
Käyttäjäkohtaisia tunnuksia – ja sitä myöten tukea saavia käyttäjiä – oli yhteensä tuollaiset 15 000 kappaletta. Ei ihme, että Tekla halusi virtaviivaistaa prosessinsa.
Selvät tavoitteet ja toteutus
Tekla halusi tehostaa toimintaa ja nostaa palvelutasoa. Asiakas saisi tilattua lisenssinsä ja ylläpitonsa verkosta minuuteissa. Dongleista luovuttaisiin.
Kustannussäästöt olivat tavoitteena, mutta eivät pääasia. Kilpailijoilla oli jo vastaava järjestelmä, mutta Teklalla ei. Nopea, automatisoitu järjestelmä oli pakollinen pääsylippu kisaan, ei vielä kilpailuedun lähde sinänsä.
Teknisesti homma hoituisi, kun BizTalk Server yhdistäisi toisiinsa tunnusten luomiseen käytettävän ohjelmiston sekä Teklan käyttämät SAP-toiminnanohjausjärjestelmän ja Microsoftin asiakkuudenhallintajärjestelmän. Oli siis kyse melko suoraviivaisesta järjestelmäintegroinnista.
Vai onko sittenkään?
Kulttuurierot: Pääkonttori halusi yhtenäistää kirjavia käytäntöjä. Tämä ei ollutkaan maayhtiöissä mikään läpihuutojuttu. Jännitteet aisti. Ja me olimme siinä välissä. Roolimme olikin saada osapuolet päättämään asioista niin, että kaikki saivat vaikuttaa.
Esityöt: Asiakas halusi selkiyttää myös hinnoittelumallinsa. Odotimme siis jotakin yksinkertaista. Mutta kun pääsimme ohjelmistolisensointiin sisään, se osoittautui luultua monimutkaisemmaksi. Poikkeuksia – ja niistä aiheutuvaa lisätyötä – jäi enemmän kuin hanketta suunniteltaessa oli arvioitu. Tähän piikkilankaan revimme pelihousumme monta kertaa.
Tekniset haasteet: En tylsistytä kuvailemalla teknistä toteutusta. Riittää, kun sanon, että se osoittautui ajateltua työläämmäksi.
Näin kertoo projektipäällikkömme Inka Veriö: ”Esimerkkinä olkoon asiakkuudenhallintajärjestelmän antama mystinen virheilmoitus. Kun se ilmaantui, en pitänyt ongelmaa kummoisena. Mutta onneksi tein siitä uuden kohdan työajan seurantaamme. Sille kohdistui lopulta 24 työpäivää työtä. Budjetoitu oli nolla.”
Selvisi että kauan käytössä ollut päivämäärän esitysmuoto aiheutti epäyhteensopivuuden. Painajaismaista selvittelyä kesti kuitenkin koko kevään – ja taas Tapiota vietiin asiakkaan kuultavaksi.
Tämä kaikki tarkoitti, että aikataulut paukkuivat. Kaiken kaikkiaan olimme budjetoineet koko projektiin 177 konsulttipäivää. Todellisuudessa työmäärä yli tuplaantui!
Mitä opimme
On vissi ero tietää asiat teoriassa ja todella sisäistää ne. Omakohtaista kokemusta ei korvaa mikään. Tämäkin projekti muistutti meitä tärkeistä projektinhallinnan lainalaisuuksista.
- Projekteihin sisältyy väistämättä julkilausumattomia odotuksia ja rajoitteita. Ne pitää kaivaa esiin heti aluksi. Hyvä palveluntarjoaja osaa rakentavasti kyseenalaistaa sen, mitä asiakas sanoo. Älä ota asioita annettuna, vaan tarkista, tarkista ja tarkista.
- Projektipäällikön on oltava päällikkö, ei assistentti. Kaikesta ei voida neuvotella kaikkien kanssa, eikä kompromissia aina löydy. Onneksi hankkeen projektipäälliköt tiesivät, milloin pitää käyttää valistunutta yksinvaltaa. Se säästi kuukausia työajassa.
- Kun eteen tulee haasteita, ne on liputettava heti! Puhu asiakkaalle heti, kun kokenut projektipäällikkö alkaa aavistella muutoksia.
- Asiakkaan prosessien muuttaminen on vaikeaa. Varsinkin, kun oma roolimme on integrointi- ja ohjelmointityö, ei muutosjohtaminen. Toki asiat, joihin puututaan ja joista kiinnostutaan, paranevat. Työtä pitää vain jaksaa tehdä kuukausi toisensa jälkeen.
- Lukuisten osapuolten koordinointiin menee aikaa aina enemmän kuin uskoisi. Etenkin, jos hankkeessa tulee odottamattomia ongelmia. Siksi on tärkeää, että meillä on hankkeesta kokonaisvastuu. Vaadimme vastuun itsellemme, koska tänne se viime kädessä kaatuu kuitenkin.
Tuottoisa lopputulos
Lisätyöstä ja venyneestä aikataulusta huolimatta hanke onnistui.
Kun järjestelmä oli toiminnassa, ylläpitoa saatiin kaupaksi selvästi aiempaa tehokkaammin. Prosessi selkiytyi ja yhtenäistyi. Teklan myyntiin toki iski sama 2008 alkanut lama kuin muihinkin yrityksiin. Mutta projektin ansiosta Tekla on tehokkaampi, kun uusi nousu alkaa. Hankkeen kustannukset tulivat pikaisesti katetuksi. Sen jälkeen uudistus on jauhanut lisäsäästöjä.
Erinomainen yhteenveto projektista, jonka osalliseksi oli kunnia päästä muutama kuukausi ennen ekan vaiheen go-livea.
Jopa nykyistä järjestelmäintegraatiota merkittävämpänä hyötynä pitäisin itse sitä, että organisaatiolle tuli oikeasti läpinäkyväksi se, millaista prosessia se todellisuudessa toteuttaakaan. Ihmiset kyllä kykenevät punomaan yhteen toistensa yksilöllisiä manuaaliprosesseja, autuaan tietämättöminä siitä miltä maailma näyttää toisen osapuolen silmistä katsottuna. Järjestelmät taas ovat siitä pirullisia keksintöjä, että ne nostavat pienimmätkin prosessierot päivänvaloon ja pakottavat kaikki leikkimään lopulta samassa hiekkalaatikossa. Tämä on se pohja, jolle tulevaisuuden prosessi-innovaatiota ja muita hiekkalinnoja on vasta mahdollista rakentaa.
Active Directoryn päivämääräkonffausten vaikutus yksittäiseen mutta keskeiseen käyttötapaukseen CRM-testiympäristöstä on hyvä esimerkki fataalista bugista, jollaista ei voi mitenkään ennakoida tai budjetoida, ja joka tekee kalleutensa hyvin selväksi 24 htp:n kulurivinä. Toisesta kategoriasta löytyvät sitten non-fatal bugit, jotka aiheuttavat prosessin käytössä toistuvaa kitkaa ja joita ratkotaan pitkällä aikajänteellä toistuvasti, ilman vastaavaa pakottavuuden tarvetta ja siten selvästi matalammalla tehokkuudella (projektisisäpiirille esimerkkinä “disappearing javascript buttons”, joka on taas IE8:n myötä tapetilla). Asiakkaan kannalta kokonaiskustannusvaikutukset voivat lopulta olla samaa luokkaa tai pahempiakin, mutta seurattavuus taas ihan eri tasoa.
Kiitos Jukka hyvästä kommentista! Tämä yksilöiden punoma manuaaliprosessiviidakko on kaikisa järjestelmähankkeissa erittäin tärkeä asia, jota harvoin osataan ottaa huomioon tarpeeksi.
Lukijoille vinkkinä, jos MSCRM yhtään kiinnostaa, kannattaa lukea Jukan osuvasti nimettyä blogia “Surviving CRM”. Pääsette siihen klikkaamalla Jukan nimeä yllä.