“Miksi ylivoimainen osaaminen ei riitä?”, otsikoi Talouselämä ja jatkaa “Tällaista alusta ei olisi voitu rakentaa missään muualla, sanoo STX Finlandin toimitusjohtaja Juha Heikinheimo. Jostain kumman syystä ylivoimainen osaaminen ei kuitenkaan riitä.”

Kun tuo Allure of the Seas –risteilijä on saatu matkaan, uusia laivatilauksia ei ole. Maailmanlaajuisesti laivanrakentaminen on kuitenkin elpymässä ja tilauksia tehdään.

Voisiko olla niin yksinkertaisesti, että ylivoimaiseksi koettu osaaminen koskee aluetta, jolla on ylipäätään varsin vähän kysyntää? Osaamista puolestaan puuttuu niiden laivojen rakentamisesta, joita asiakkaat haluavat ostaa.

Sivuhuomautus: Muistan Leenamaija Otala kirjan Osaamisen etu – kilpailukykyä muutoksessa. Siinä hän nosti oppivan organisaation malliesimerkiksi englantilaisen Roverin. Muistattehan, sen edesmenneen autovalmistajan. Oppivan organisaation kulttuuri oli ajaettu firmassa sisään viimeistäkin työntekijää myöten. Kirjan kirjoittamishetkellä kaikki ehkä näyttikin hetken hienolta.

Harmi vain, että kukaan ei halunnut Rover -merkkisiä autoja.

En osta väitettä, että muut laivanrakennusmaat päihittäisivät suomalaiset halvemmilla kustannuksillaan. Selluakin on halvempi tehdä muualla kuin Suomessa, mutta ei se ole suomalaisia metsäjättejä haitannut. He ovat menneet sinne, missä tuotanto on edullista. Kyllä me kannattavan bulkkituotannon osaamme. Siihen liittyvä osaaminen on vain erilaista kuin äärimmäisen pienisarjaisten ja harvalukuisten high end –tuotteiden valmistus.

Katsotaan totuutta silmiin: Ylivoimaiseksi kokemamme osaaminen on useimpien asiakkaiden mielestä aika yhdentekevää.

Tästä yritän meitä itseämmekin aina muistuttaa, kun tuntuu, että asiakas ei tehnyt haluamaamme ostopäätöstä. Peiliin voi olla kipeä katsoa, mutta sieltä ne syyt aika usein löytyvät.

Wall Street Journal sekä MIT Sloan Management Review olivat samoilla linjoilla toukokuussa, kun he listasivat tärkeimmät alueet missä tietohallintojohdon osaamisessa on parantamisen varaa.

Kuten Kim jo tammikuussa kirjoitti Epistolassa, meidän mielestämme CIO pitäisi olla seurustelu-upseeri. Tekniikka on toki tärkeätä CIO:n työssä, mutta toissijaista. Insinöörilähtöinen tietohallintojohto uppoutuu mielellään tekniikkaan koska se on helppoa. Helppoa verrattuna liiketoimintahyötyjen miettimiseen. Helppoa verrattuna niiden myymiseen muulle yritysjohdolle.

WSJ toteaa, että yksi tärkeistä alueista missä tietohallintojohto pitää parantaa osaamistaan on vaikutstaidot, eli miten myydä hyöty muille.

Hyvässä myyjässä kiteytyy nämä kaksi asiaa: ymmärrä liiketoimintaa niin hyvin että pystyt kaivamaan hyötyjä. Esittele hyödyt johdolle puhuen heidän omaa kieltään. Jos CIO osaa toimia kuin hyvä myyjä, hänen arvo organisaatiolle on valtava. Jos hän on nippeliniilo, hän ei tuo juurikaan mitään pöytään.

Lopuksi pitää todeta että niin tietohallintojohtajia kuten muitakin johtajia löytyy laidasta laitaan. Samat asiat pätevät muihinkin johtajiin. Tietohallintojohtoa ollaan vaan syynätty viime aikoina tarkasti koska sen tärkeys liiketoiminnan ytimessä korostuu.

Holmström on sitä mieltä, että kaatamalla rahaa hankkeisiin ja antamalla täysi vapaus keksiä rahoille käyttöä, hyviä innovaatioita ei synny. Mielestäni Holmström on oikeassa, vaikka asia ei aina näin mustavalkoinen ole.

Omalta osaltamme voin kyllä sanoa että mikään ei anna paremmat eväät uusien ja innovatiivisten ratkaisujen keksimiseen kuin asetetut rajoitukset tai reunaehdot  - olkoon se sitten raha, aika, tai jokin muu projekteissa olennainen komponentti. Positiivinen paine antaa lisää virtaa.

P.S.
Sain Twitterissä hieman palautetta pitkästä kesätauosta. Kieltämättä se oli pidemmänpuoleinen joten siitä nöyrät anteeksipyyntöni. Nyt kuitenkin jatketaan kesäauringon antamalla uudella energialla postituksia. Kiitos palautteesta ja lukijoille mielenkiinnosta!
D.S.

Seth Godin puolestaan sanoo, että lisäarvoa syntyy vain tekemällä hankalia töitä, joissa otat aloitteen, tuot kaaokseen järjestystä ja raivaat polkua. Godin kiteyttää sen näin: Et pysty luomaan arvoa työssä, jossa joku (pomosi, asiakkaasi) kertoo, mitä pitää tehdä seuraavaksi.

Siis työmme on ratkaista ryhmässä hankalia ongelmia.

Mutta Umair Haque huomauttaa terävästi, että sosiaalisen median luomat suhteet ovat kovin ohuita. Kavereita riittää bittiavaruudessa, mutta ne luottosuhteet joihin on panostettu ja jotka eivät koskaan petä, ovat yhtä harvassa kuin aina ennenkin. Ehkä jopa harvemmassa.

Entä jos yksinkertaistaisimme ryhmätyötä? Kasaisimme pienemmän, mutta tiiviimmän piirin. Panostaisimme muutamiin vahvoihin yhteistyösuhteisiin nykyistä enemmän.

Saisimmeko enemmän arvoa aikaan?

Kiitos kuuluu tekniikalle.

Tuotanto on alusta loppuun tietokoneistettua, kuten asiakkaamme Apetit osoittaa. Tehokkuuden lisäksi tämä tuo laatua ja turvallisuutta, koska jokaisen ruokaerän alkuperä ja viljelymenetelmät ovat jäljitettävissä.

Apetit Pakaste Oy kehittää ja valmistaa peruna-, kasvis- ja ruokapakasteita. Yrityksen liikevaihto on viitisenkymmentä miljoonaa euroa ja kotimainen raaka-ainehankinta perustuu perustuu tarkasti valvottuun ja dokumentoituun IP sopimusviljelyyn. Saimme vastikään valmiiksi Apetitin kanssa rakennetun sopimusviljelyn sähköisen työkalun, Apetit viljelijärekisterin.

Kaikki toiminta Apetiti Pakasteen ja sopimusviljelijöiden välillä on tietokoneistettu.

”Kehittyneet järjestelmät mahdollistavat, että pellolta-pöytään -ruokaketju toimii luotettavasti ja mahdollisimman taloudellisesti. Kuluttajille tärkeitä ovat elintarvikkeiden korkea laatu, turvallisuus, jäljitettävyys ja oikea hinta-laatu suhde”, sanoo Timo Mäki, Apetit Pakaste Oy.

Viljelijärekisteri toimii verkossa prosessin alusta loppuun saakka:

• Apetit budjetoi raaka-ainetarpeen tavoitteet sopimuskaudeksi kerrallaan.
• Halukkuuskyselyt viljelijöille – mitä kasvia ja millaisia määriä sopimusviljelijä haluaa viljellä.
• Sopimusehdotukset viljelijöille.
• Sopimusehdot.
• Sopimuksen allekirjoittaminen ja sopimusten yhteenvedot.
• Kasvikohtaiset viljelyohjeet.
• Viljelytietojen dokumentointi lohkokohtaisesti: Tarkkailutiedot (havainnot) rikkakasveista, tuhoeläimistä ja kasvitaudeista
• sekä toteutetut viljelytoimenpiteet: lannoitus, kasvinsuojelu, jne.
• Raaka-aine-erän toimituksen hyväksyminen ja eräkohtainen seuranta: Jäljitettävyys.
• Kasvikohtaisten raaka-aineiden vastaanottotiedot viljelijäkohtaisesti ja kuormien punnitustiedot reaaliaikaisesti.
• Tuotannon seuranta: Valmiin pakastetun lopputuotteen punnitustiedot eräkohtaisesti ja laadun tarkkailutiedot.
• Kasvikohtaisten vastaanotto- ja tuotantotietojen yhteenvedot
• Tilitykset ja tositteet

Tästä eteenpäin pakkauslinjat, varastot ja kuljetus huolehtivat omia järjestelmiään hyödyntäen valmiit tuotteet vähittäiskauppaan ja muille asiakkaille.

En halua edes ajatella, mitä suomalainen ruoka maksaisi, jos tällaisia järjestelmiä ei olisi ja työ hoidettaisiin manuaalisesti!

Sähköinen asiakkuudenhallinta ei toimi.

Miksi? Koska koko ajatus on väärin. Voin hyväksyä, että tietoa pitää tallentaa. Mutta väite, että CRM-järjestelmän avulla saisi enemmän kauppaa, ei pidä paikkaansa.

Näen eCraftilla omat tuloksemme. Kyselemällä näen parinkymmenen asiakkaan tulokset. Lehdistä voin lukea toimialakohtaiset kokemukset. Kaikissa sama tulos: Kukaan ei ole kuullut CRM-järjestelmästä, joka kasvatti myyntiä.

Tietoa toki kertyy. Entä sitten? Asiakkuudenhallintajärjestelmät näyttävät toimivan vain yksinkertaisten tuotteiden myynnissä. Heti kun myyntiä tekee myyntitiimi ja myyntisykli on vähänkään pidempi, homma karahtaa kiville. Syynä on se, että nykymuodossaan CRM helpottaa vain liidien hankintaa.

Mutta kun monimutkaisempien tuotteiden myynnissä pullonkaula ei suinkaan ole liideissä (niitä on rajallinen määrä), vaan siinä, kuinka nopeasti ja arvoa lisäävästi pitkäsyklinen myyntiprosessi etenee. Oppia pitäisi ottaa lean manufacturing -menetelmistä. Niissä katsotaan visuaalisesti, kuinka hanke etenee yrityksen omien prosessien läpi.

Konkreettisesti: CRM-järjestelmän pitää haudata lomakkeiden täyttäminen ja listojen tuijottelu. Meneillään oleva myynticase pitää visualisoida itse tiimille ja myyntijohdolle. Järjestelmän pitää näyttää, kuinka case etenee liidivaiheesta aina tarjouksen jättämiseen saakka. Joka hetki on nähtävä, kuinka casea jalostetaan (useiden asiantuntijoiden toimesta), kuinka paljon siihen käytetään työtä ja kuinka nopeasti kalenteriajassa mitattuna homma etenee.

Silloin kaikki tajuavat, kuinka paljon aikaa hukataan pelkkään odotteluun. Omassa yrityksessäni menee helposti kuusi viikkoa aikaa, ennenkuin asiakkaalle saadaan lopullinen tarjous. Ongelmia on kaksi:

• Ensinnäkin, tarjoamme liian hitaasti ja asiat ehtivät jo sillä välin muuttua. Työ valuu osin tai kokonaan hukkaan.
• Toiseksi, usein tarjousta kohden teemme tosiasiallisesti työtä noin kolme päivää. Muu aika menee odotteluun. Asiat makaavat jonkun asiantuntijan sähköpostissa. Mutta jotenkin aikaansaadaan samalla illuusio, että koko ajan tehdään paljon töitä.

Tietysti tietoa pitää kerätä ja aggregoida. Mutta se ei tuo yhtään lisää kauppaa. Saman totesi jo vuosia sitten myynnin ylipappi Jari Sarasvuo:

”Olin aika pitkään CRM-uskovainen ja huijasin asiakkailtani rahaa myymällä CRM-kotkotusta eli yli-rationalisoitua markkinointia. Myöhemmin tulin samalle kannalle [kuin Ami Hasan] kun huomasin, ettei tietokantapohjainen teologia toimi missään.”
– Kauppalehti Optio, 4.3.2004.

Jos autonvalmistuprosessi olisi yhtä tehoton kuin nykyisillä CRM-järjestelmillä ohjattu myyntiprosessi, automme maksaisivat tuplasti sen mitä nyt. Ja ajaisimme teknisesti korkeintaan 90-luvun tasoa olevilla kaaroilla.

Kilpailukykymme tähden: CRM on turhake, joka pitää kuopata.

Tämä tuli mieleeni, kun luin Marketvision Aila Vuorion juttua toiminnanohjausjärjestelmien kehittämisestä, jossa hän sanoo näin:

”Tietotekniikan liiton IT Barometri 2009 -tutkimuksen mukaan it:n vaikutusten mittaaminen on suomalaisyrityksissä yleinen ongelma. Liiketoimintavaatimuksia ei mitata laajasti ja luotettavilla liiketoiminnan mittareilla. Tuotetut hyödyt perustuvat siis uskomuksiin.”

Totta tuokin. Mutta usein hyötyjä ei mitata, koska niitä ei ole!

Tottakai järjestelmät tuovat hyötyä. Mutta vain samaan tapaan kuin siirtyminen höyryvoimasta sähköön. Sähkö on fiksumpaa, mutta kohta se on kaikilla. Mitä sitä mittaamaan. Emmehän me mittaa internet-yhteydenkään hyötyä, koska se on perusinfraa, joka pitää vain olla.

Samaa pätee erppiin. Perus-erp on perusinfraa. Se tuo etua vasta, kun sitä sovelletaan, sovitetaan, muokataan ja taivutetaan yhdessä liiketoimintaprosessien kanssa.

Sain viime viikolla tilaisuuden jutella innovaatioista Saku Tuomisen kanssa. Saku on kansainvälisen Zodiak Entertainmentin luova johtaja ja tuoreen Idealist Groupin perustaja. Pyysin Sakua heti tarttumaan rinnuksiini ja vähän ravistelemaan:

Peter Löfgren: Saku, kenen vastuulla innovointi yrityksissä on? Kuka sitä johtaa?
Saku Tuominen: Minusta ideointi on aina esimiehen vastuulla. Ja jokaisen esimiehen – ideointia ja luovuutta ei saa rajata harvojen etuoikeudeksi.

Mistä ideointi ja innovaatioprosessi alkaa? Sysääkö joku tietty tilanne sen liikkeelle?
Korostan jälleen esimiehen roolia. Ideointiprosessi ei voi olla ainoastaan reaktiivinen tai ideoista käynnistyvä vaan sen täytyy olla uutta etsivä, proaktiivinen. Luovassa yhteisössä on jatkuvasti käynnissä useita eri prosesseja, useissa ei vaiheissa.

Mutta eikö pidä olla ensin joku ongelma, jota ratkaistaan? Mistä organisaatio tietää, että nyt tarvitaan jotain innovatiivista?
Ongelman voi tunnistaa kuka tahansa ja luova organisaatio ei ole huolissaan ongelmista vaan päinvastoin innostuu niistä. Mutta tärkeää on se, että reagointi ei rajoitu ainoastaan tilanteisiin, joissa havaitaan ongelma.

Usein suuret ideat eivät ole ratkaisuja ongelmiin vaa pinnan alla kytevien tarpeiden tunnistamista. Ei maailmassa ollut huutavaa tarvetta iPodille ja silti se muutti koko musiikkibusineksen.

Allekirjoitan kytevät tarpeet ja iPod -esimerkkiä olen itsekin käyttänyt! Kuinka porukka sitten saadaan tällaiseen kehitystyöhön mukaan?
Luovuus tarkoittaa halua tehdä eri tavalla, paremmin. Jotta ihmiset pystyvät siihen, heillä täytyy olla halua tehdä eri tavalla ja toisaalta usko omaan kykyyn haastaa olemassaoleva. Siksi luovuuden johtamisessa ollaan tekemisessä aivan perustavaa laatua olevien asioiden kanssa, kuten vaikkapa itsetunnon rohkaisemisessa.

Moni tuskailee sen kanssa, kuinka paljon aikaa ja resursseja mihinkin kohdistaa. Milloin idea tai innovaatio on valmis?
Ei milloinkaan. Vaikka idea olisi kuinka hyvä, täytyy hyväksyä että jossain olisi vielä parempi idea. Täytyy hyväksyä riittävän hyvä, vaikka se tuntuukin monesta hurjalta ajatukselta. Tämän vuoksi inhoan ajatusta perfektionismista koska se lähtee siitä, että täydellinen on olemassa. Ei ole. Uskon kunnianhimoon ja paremmin tekemiseen – en täydellisyyteen. Ja asioiden täytyy aina antaa hautua rauhassa, koska vain siten saamme apua alitajunnaltamme.

No hyvä, mutta kuinka testata sitä, onko uusi konsepti koko vaivan väärti? Mistä voin tietää, että olen menossa oikeaan suuntaan?
Riippuu kokonaan ideasta. Uskon ideoiden pitchaamiseen varhaisessa vaiheessa. Uskon prototyyppeihin. Uskon testipresentaatioihin. Uskon pilotteihin. Minulle tulee usein “etiäinen” siitä toimiiko idea vai ei silloin kun presentoin sitä, riippumatta palautteesta!

Tuon perusteella täytyy heti kysyä, mikä palaute kannattaa huomioida ja minkä voi työntää sivuun?
Jos kaikki ovat ideasta innoissaan, siinä on todennäköisesti jotain hyvää. Jos kukaan ei ole ideasta innoissaan, siinä on todennäköisesti jotain vinossa. Jos kaikki ovat laimeita, on syytä olla huolissaan.

Jos mielipiteet jakautuvat voimakkaasti, saatetaan olla jonkun suuren äärellä, koska hyvä idea haastaa usein olemassaolevan ja on siksi pelottava. Ja vaikka uskonkin palautteeseen ja aktiiviseen dialogiin, en usko liialliseen demokratiaan, koska se leikkaa usein rohkeimmat ideat pois.

Milloin uusi kokonaisuus paketoidaan tai tuotteistetaan valmiiksi? Mihin pitää kiinnittää huomiota?
Tuotteistaminen on osa ideointiprosessia ja se koostuu kymmenistä yksityiskohdista jotka voivat olla joko luovia tai ei. Siksi on tärkeää, ettei ideointia ja tuotteistamista eroteta toisistaan. Suuruus on yksityiskohdissa.

Mikä on paras tapa lanseerata uusi idea markkinoille?
Hiomalla, hiomalla ja hiomalla. Yksityiskohtia rakastamalla. Mitä rohkeampi idea, sitä enemmän täytyy käyttää luovaa ajattelua sen tuotteistamisessa ja lanseeraamisessa. Itsestäänselvä on helppo myydä, erilainen usein ei.

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.

1. 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.
2. 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.
3. Kun eteen tulee haasteita, ne on liputettava heti! Puhu asiakkaalle heti, kun kokenut projektipäällikkö alkaa aavistella muutoksia.
4. 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.
5. 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ä.

Silti erpit (itse pidän sanasta liiketoimintajärjestelmät) ovat monessa firmassa henkitoreissaan. Ne eivät tuota kilpailuetua, koska kaikilla on samat kilkkeet. Eikä niitä käytetä innolla, vaan suuri joukko ihmisiä käyttää niitä lähinnä pakon edessä.

Yksi erppien perusongelmia on tämä: DDR ei pitkän päälle toimi.

Mitä se tarkoittaa?

Toiminnanohjausjärjestelmät on pystytetty kovalla rahalla. Vähintää vuoden, mutta usein jopa lähes kolmen vuoden kestoisena valtavana määrittely-, asennus-, testaus-, koulutus-, käyttöönotto-, ja korjausprojektina.

Paineet ovat olleet niin kovat, että matkan varrella käyttäjien vikinät on nitistetty: ”Kyllä ne siihen tottuu, kunhan saadaan järjestelmä pystyyn!”

Lopputuloksena on kökkö työkalu. Käytettävyys hukkuu valikko- ja lomakemereen. Yhdellä vilkaisulla saatava, käyttökontekstiin automaattisesti liittyvä lisäinformaatio loistaa poissaolollaan. Todelliset työnkulut on korvattu idealisoidulla prosessilla. Tiedon visualisointia ei harrasteta.

Lienee selväää, ettei käyttäjä innostu järjestelmästä. Tällainen erppi on kuin DDR:n yhteiskuntajärjestelmä. Toimii kyllä, mutta vain pakottamalla.

Vasta käyttäjien kuuntelu ja heistä välittäminen saa homman todella toimimaan. Siten saadaan into mukaan.

Ideanin Santtu Toivonen kirjoittaa Tietoviikossa, kuinka käyttäjät koukutetaan verkkopalveluun. Vinkit sopivat erinomaisesti myös toiminnanohjausjärjestelmien virittämiseen. Muutamia (hieman muokattuja) otteita Santun artikkelista:

• Palvelu on kuin bileet. Ihmiset käyttäytyvät sen mukaisesti, millaiset juhlat isäntä tai emäntä järjestää.
• Raha ei toimi, vai voisitko kuvitella pyytäväsi ihmisiä juhliisi korvausta vastaan? Aika säälittävää. Hauskuus, yhteenkuuluvuuden tunne ja intohimo aihepiiriin toimii paremmin.
• Tarkkaile palvelun “väärinkäyttöä” ja muokkaa palvelua siten, että se tulee helpommaksi. Parhaimmillaan saat aitoja käyttäjäinnovaatioita.
• Hyvä design on ensiarvoisen tärkeää. Palvelusta pitää välittömästi käydä ilmi sen tarkoitus ja tärkeimmät toiminnot.
• Kaikkia käyttäjien toiveita ei tarvitse toteuttaa. On silti äärimmäisen tärkeää, että käyttäjät saavat tiedon siitä, että heitä kuunnellaan.

Vilkaise toiminnanohjausjärjestelmääsi ja kysy: onko täällä hyvät bileet? Tulevatko ihmiset tänne mielellään? Onko heillä lähtiessään hyvä fiilis? Millaiset juhlat olen järjestänyt?

DDR on kuollut. Se ei koskaan tuottanut kilpailukykyä, koska hommasta puuttui ihmisten into. Eihän omalle erpillesi ole käymässä samoin?