Sen tekeminen on ollut niin kova ponnistus, että harva haluaa enää muutoksia – siis lisäponnistuksia. Käyttäjät ja ylläpitäjät jämähtävät täydelliseen järjestelmäänsä.

Sitäpaitsi, täydellisen metsästys maksaa niin paljon, ettei sovellus maksa itseään takaisin koskaan. Viimeisen päälle viilattu on myös syönyt resurssisi viimeisen päälle.

Jos täydellinen on järjetön tavoite, epätäydellinen on sitten järkevä!

Keikauta ajatteluasi: Päätä, millä tavalla puutteellinen järjestelmä sopii käyttöösi parhaiten.

Käyttäjäkokemuskin voi olla toimiva, vaikka sovellus on epätäydellinen. Sovellus on tietyn työtehtävän suorittamiseksi – itseisarvoa sillä ei ole.

Ensimmäisessä taulukossa on myyntiprosessi, joka edellyttää aina workshopin vetämistä.
Toisessa taulukossa on proof-of-concept -osio, joka liittyy isompaan myyntiprosessiin.
Taulukot ovat oikeasti vain pitkiä vaakarivejä, mutta tähän leikkelin ne kahdelle riville.

Taulukko 1. Esimerkki myyntiprosessistamme ja sisäisistä kustannuksista eri vaiheissa:

.

.

.

.

Taulukko 2. Proof-of-concept osana myyntiprosessia:

.

.

.

.

Vaikka taulukoita tähän yksinkertaistinkin, niin monimutkaisesta asiasta ei siis ole kysymys. Ajattelutavan ja kulttuurin muutos on kyllä sitäkin merkittävämpi.

(Lean- ja Kanban-kirjallisuutta sekä menetelmien eri variaatioita riittää. Tauluista voi lukea lisää vaikkapa tästä taulujen käyttöä koskevasta Kenji Hiranaben artikkelista.)

Mitä hyötyä näistä on ollut?

Yksi hyöty on, että saan yhdellä vilkaisulla tietää, onko meillä tarpeeksi myynticaseja putkessa vai ei.

Toinen hyöty on tapaus, jossa paljastui, että vaikka meillä oli numeroiden mukaan tarpeeksi caseja meneillään, niin meillä ei ollut mitään meneillään prosessin keskivaiheilla. Rattaat pyörivät yhtäällä tyhjää ja toisaalla muodostui liiasta tavarasta pullonkauloja.

Laajemmin: Kun ryhdyimme tarkastelemaan myyntiämme lean-oppien mukaisena tuotantoprosessina, opimme mm. että perinteinen liidilähtöinen myynninohjaus ei toimi monimutkaisia tuotteita ja palveluita myyvissä yrityksissä, kuten eCraftissa. Kun seurasimme asioita liidilähtöisesti, tungimme aina vain lisää massaa koneeseen.

“Liidit sisään ja kyllä ne hoituu” -ajattelu ei toimi. Myyntiprosessin joka vaihe ei saa eikä voi olla täynnä kamaa. Se on hidasta, kallista, ja aiheuttaa laadun heittelehtimistä. Sen sijaan pitää olla muutama konkreettinen, hyvin kvalifioitu myynticase, jotka etenevät ja joita aktiivisesti edistetään. Ne pyritään saamaan mahdollisimman oikein ja nopeasti kaupan päättämisvaiheeseen.

Me insinöörithän haluamme tekniikka, joka ainakin teoriassa pystyy ratkaisemaan kaikki ongelmamme. Kuitenkin väitämme arvostavamme yksinkertaisuutta.

Miksi siis?

Koska säästät aikaa ja hermoja. Yksinkertaistamalla järjestelmiä, kuten Ville juuri kirjoittaa, työntekijä tai johtaja tai asiakas säästää kallisarvoista aikaansa. Siis tienaa euroja.

Tai parantaa asiakaskokemusta, kuten Elina Hiltusen kolumni Talouselämässä kertoo. Uskon, että tällä on suora linkki myös asiakasuskollisuuteen. Kynnys vaihtaa helposta vaikeaan on korkea.

Ohjelmistojen luomisessa ja käyttämisessä pätee: periaatteessa haluamme mahdollisuuden kontrolloida kaikkea, mutta käytännössä meillä on kuitenkin tärkeitä tavoitteita, joita yritämme saavuttaa, ja siksi haluamme keskittyä olennaiseen.

Juuri tuo olennaiseen keskittyminen on mielestäni koko simplicity -ajatuksen ydin. Niin elämässä kuin teknologiassakin. Vain ymmärtämällä mikä oikeasti on tärkeää pystyt karsimaan turhan pois.

Turhan karsiminen onkin paras tapa yksinkertaistaa.

John Maedan mainiossa kirjassa The Laws of Simplicity on kymmenen lakia, joista ensimmäinen on tärkein: ” Reduce. The simplest way to achieve simplicity is through thoughtful reduction.”

Itse sanoisin, että yksinkertaistamisessa on kyse kahdesta askeleesta:

1. Ymmärrä. Eli like-elämässä ja teollisuuden ohjelmistoissa kyse on siitä, että sinun pitää tietää mikä on oikeasti tärkeää. Kuten Edward de Bono sanoo kirjassaan Simplicity, saavutat yksinkertaisuuden vain ymmärtämällä yksinkertaistettavan asian syvällisesti.
2. Karsi. Poistat kaiken turhan ja piilotat loput. Käytännössä tämä tapahtuu niin, että softa on enemmän prosessiohjautunut. Näin vähennetään turhaa tietoa silloin kuin sitä ei tarvita. Käyttäjälle näytetään ainoastaan relevantteja tietoja.

Kehitämme liiketoimintaohjelmistoa OK Perinnälle. Nyt olemme toteuttaneet myyntiprosessin hallintaa kevyellä asiakastiedolla. Käytettävyydestä ei ollut aikaisemmin pidetty erityistä haloota ja tässä vaiheessa haluttiin lähinnä vähän vilkaista käyttöliittymää.

Näköjään monen IT-talon – joskus harhautuessamme myös eCraftin – ajatusmalli pitää sisällään lomakkeiden ja pop-uppien ihannointia, sillä tämän järjestelmän käyttökokemus oli kuin ihan oikeassa CRM:ssä; useasti toistettavan prosessin läpikäynti vaati kymmenen erillisen lomakkeen aukomista ja turhaa nappien painelua sekä hierarkkisia dropdowneja.

Pop-uppien käytöstä johtuva datan haku, ikkunoiden aukominen, nappien painelu ja seuraavan lomakkeen käyttöön siirtyminen vei varmasti pari sekuntia per pop-up. Onneksi kyse ei kuitenkaan ollut oikeasta CRM:stä, joten käyttöliittymälle on helppo tehdä jotakin.

Kävimme asiakkaan kanssa prosessin läpi ja yhdessä keksimme tavan vähentää lomakkeiden auonta siitä kymmenestä ainoastaan yhteen. Kaiken muun voi tehdä päänäkymässä. Teimme myös roadmappia seuraavaksi tehtäviin käytettävyysparannuksiin.

Muutaman tunnin palaverilla saimme aikaan suunnitelman joka toteutettuna maksaa suunnitteluun menneen ajan takaisin viikossa ja järjestelmää jatkuvasti työssään käyttävien henkilöiden inhimillinen kärsimys varmasti pienenee.

Tämä oli toki harvinaisen otollinen alusta, sillä sovellus oli verrattain helposti muutettavissa, asiakas ymmärsi ketterää kehitystä ja pohjalla oleva perusprosessi oli järkevä.

Se on kuitenkin hyvä esimerkki siitä miten käytettävyyden parantamisen ei tarvitse tarkoittaa mitään käytettävyysprojektia tai organisaatiolinjausta. Joskus se on vain maalaisjärjellä läpikäyty käyttötilanne

Useimpien käyttäjien työruudulla on kymmenen eri ohjelmaa, usein enemmänkin. Näitä hän joutuu käyttämään saadakseen viikottaiset työnsä tehtyä. Käyttämisen ilo on tästä järjestelmäviidakosta kaukana.

Kerromme, kuinka järkeistät ja ratkot liiketoimintahaasteitasi vähemmällä softalla.

Aiomme kirjoittaa mm. seuraavista aiheista:

• Käytettävyys – helppokäyttöisyys ja turhan karsinta.
• Keskeisten prosessien tehostaminen:
  -   Myynti on tuotantoprosessi (1, 2, 3) – lean-näkökulman tuoma muutos ja työkalut.
  -   Palveluprosessi lean-näkökulmasta – mitä uutta lean-ajattelu tuo.
  -   After-sales ja elinkaaren hallinta – mistä on fiksut ratkaisut rakennettu.
  -   Hankintaprosessi – mitä olemme oppineet tehokkaasta hankinnasta.
• Master data management (1) – vähemmän mutta fiksummin.
• Simplicity! – yksinkertaistaminen ja sujuvoittaminen.
• Sosiaaliset mediat – ohjelmistoja nekin, joten tarkastelemme niitä tuottavuuden ja yksinkertaistamisen näkökulmasta.

Jaamme niitä kokemuksia ja ajatuksia, joita meillä on tehokkuuden lisäämiseksi.
Vähemmän softaa, enemmän tuottavuutta.

Päällekkäisten ohjelmistojen ja informaation määrä aiheuttaa tehottomuutta – vaikka vuosikymmeniä on sanottu, että IT nostaa tuottavuutta. Blogissa on paljon muita kirjoituksia siitä, miten tämä tehottomuus ilmenee, mutta nostanpa esiin vielä uuden aiheen tähän liittyen.

Mitä suurempi organisaatio, sitä tavallisempi on tilanne missä muuttuva tieto – esimerkiksi asiakastieto – ei päivity kaikille sitä tarvitseville. Ihmiset toimivat erillisten järjestelmien ja ristiriitaisen tiedon varassa. Tähän apua tarjoaa Master Data Management (MDM). Näin olemme saaneet kuulla analyytikoilta.

Yksinkertaistettuna master data management on aika selvä: Yksi järjestelmä on master jollekin tiedolle, mikä tarkoittaa, että tietoa luodaan ja ylläpidetään siinä. Muissa järjestelmissä tämän tiedon muokkaaminen ei ole sallittu. Kun muutoksia tehdään master-järjestelmässä, ne kulkeutuvat edelleen muihin järjestelmiin, missä samaa tietoa käsitellään ja täydennetään. Tarkempia määritelmiä ja materiaalia on Internetissä paljon, joten ei sen enempää itse aiheesta.

Asiakkaamme puhuvat MDM-haasteesta nyt paljon. Se on selvästikin kuuma aihe.

Ongelma on, että käytännössä tämän yksinkertaiselta kuulostavan asian toteuttaminen on varsin haastavaa. Amerikkalaiset konsulttikirjoitukset puhuvat asioista, jotka ovat kaukana omien asiakkaidemme tarpeista.

Itse näen ison riskin, että jos lähdetään tekemään Master Data Management hanketta by the book, niin se karkaa käsistä ja irtautuu reaalimaailmasta. Perustamalla lisää komiteoita ja tuottamalla valtava määrä dokumentteja, joissa on paljon nuolia sinne tänne, kenenkään työ ei vielä helpotu! Tarvitaan konkreettisempaa lähestymistapaa joka tuottaa parannusta jo kuukausien kuluessa, ei vuosien.

Kirjoitan aiheesta jatkossa lisää. Onko kenelläkään blogin lukijoista omia kokemuksia tehokkaasta MDM-lähestymistavasta?

Siksi käyttäjätutkimusta tekevien parissa ja eCraftin omassakin blogissa suositellaan käyttäjien tarkkailua. Ajatus on, että seuraamalla käyttäjiä tai asiakkaita todellisissa käyttötilanteissa, saadaan selville todelliset tarpeet.

Tämä on vain osin totta.

Kun uusimme asiakkaan nykyistä tietojärjestelmää, törmään usein niin kökköihin käyttöliittymiin, että käyttötilanteen seurannasta ei ole mitään hyötyä.

Pahempaa, huonosti toteutettu nykyjärjestelmä tai manuaalinen prosessi on saastuttanut ajatukset ja käyttötottumukset niin pahoin, että käyttäjät eivät osaa esittää edes kehitystoiveita muutoin kuin nykyjärjestelmän pikkuparannuksina.

Siinä ei tarkkailu auta. Pitää opettaa.

Olen oppinut, että kaavoihin kangistuneiden käyttäjien kuuntelu tai seuraaminen johtaa vain harhaan. On ymmärrettävä asiakkaan prosessi, ajateltava uudella tavalla ja vakuutettava asiakas uudesta tavasta. Opetettava uusille tavoille.

Siis järjestelmän uusimisprojektissa tai työprosessin siirtämisessä uuteen IT-järjestelmään älä aina seuraa käyttäjien nykytilaa, vaan luo heille järkevä, uusi toimintatapa ja opeta ajattelemaan sen mukaan.

Varsinkaan pienissä projekteissa ei ole tarvetta eikä työpäiviä ryhtyä kikkailemaan käytettävyydellä.

En seuraa jotakin käytettävyysteoriaa. En tee ihmisille testejä. En tarkkaile heitä tekemässä työtään, ellei siihen ole painavaa syytä.

Olen tehnyt ja nähnyt käyttöliittymiä tarpeeksi, jotta tiedän, mikä toimii. Uskon, että sellaisen asiantuntijan asiakaskin haluaa.

Kyllähän näitä norsunluutorneistaan paasaavia user interface experience höpö löpö vuorovaikutussuunnitelma horina jorina -guruja maailmalla riittää. Olen oppinut, että useimmiten kuitenkin riittää, että oma ajatus kulkee ja on nähnyt riittävästi huonoja ratkaisuja, että osaa automaattisesti tehdä järkevän ehdotuksen.

UI-teorioiden taakse on helppo piiloutua. Eikös se vanha sanonta näin mennyt:
Ne tekevät, jotka osaavat. Ne, jotka eivät osaa, opettavat.

Mutta kuinka motivoit myyjät tämän uuden ajattelutavan taakse? Miksi he haluaisivat käyttää aikaansa tuon prosessin kehittämiseen?

Koska myyjät saavat lean-ajattelusta heti hyötyä! Sen sijaan CRM-järjestelmän käyttö – jota aika moni myyjä pitää kyttäämisenä – sisältää vain lupauksen, että tietojen näpyttelyyn pakotettu myyjä saa joskus tulevaisuudessa jotain hyötyä.

Mihin tuo perustuu?

Yksinkertaista: Asetat lean-tuotantoprosessisi ensimmäiseksi kehityskohteeksi saada muut ihmiset tukemaan myyntiä paremmin!

Keskityt siis aluksi niihin vaiheisiin, joiden eteneminen riippuu muista ihmisistä kuin myyjistä. Tämä tarkoittaa tarjouksen tuottamiseen osallistuvien asiantuntijoiden tuomista myyjän käyttöön ennakoitavasti, nopeasti ja helposti. Voit uskoa, että myyjilläsi on tähän paljon sanottavaa.

Tämä ei tarkoita, että unohtaisit myyjien itsensä toteuttamat vaiheet. Huomio siirtyy niihin ihan luonnostaan, kunhan vain saat prosessin järkeistyksen liikkeelle. Kun kaikki vaiheet ovat kaikkien näkyvissä, ne tulevat myös kaikki ennen pitkää käsiteltyä.

Mutta aloita niin, että myyjillä on kannuste osallistua. Aloita myyjiä tukevista vaiheista.

Se tuottaa kauppoja liian kalliisti, koska:

1. Tarjousten tuottaminen kestää liian kauan ja kuluttaa liikaa resursseja.
2. Tuotettujen tarjousten laatu vaihtelee tarpeettomasti ja hallitsemattomasti.
3. Prosessi ei sisällä itsekorjaavaa mekanismia, vaan samat juuriongelmat toistuvat jatkuvasti.

Uuden näkökulman ongelman ratkaisemiseen tarjoaa lean manufacturing. Lean -näkökulmasta myyntiprosessin voi nähdä tuotantoprosessina, joka valmistaa Deal -nimisiä tuotteita.

Diilien valmistuksessa on käytettävä mahdollisimman vähän resursseja, tuotettava vähän hukkaa ja saatava laadukas lopputulos. Aivan samoin autotehtaassa valmistusaika on minimoitu, resursseja käytetään vain tarvittava määrä, hukkapaloja syntyy vähän ja tuote on tasalaatuinen – silti tuote on asiakkaan tarpeisiin varusteltu.

Millainen sitten mahtaisi olla lean-myyntiprosessi?

Tavoite: Myyntiprosessi on koneisto, joka tuottaa diili -nimisiä tuotteita. Tuo koneisto kuluttaa liidejä sekä tiettyjä muita resursseja, kuten myyjien, asiantuntijoiden ja asiakkaiden aikaa. Keskeiset tuotantopanokset ovat eri ihmisiltä saatu tieto, huomio ja päätökset.

Koneiston tavoitteena on tuottaa mahdollisimman hyvä diili.

Ihanne on, että 1) ostava asiakas saa tuotteen heti, juuri sellaisena kuin haluaa ja 2) myyjä saa kaupan heti, juuri kuten haluaa. Myyjä siis saisi diilin aikaiseksi juuri nyt vapaana olevilla resursseilla.

Tietenkään tämä ei toteudu. Mutta tarkoitus onkin päästä lähelle tätä ideaalia.

Keinot: Kaksi keskeistä lean-työkalua:

Value stream mapping – tunnistat kaikki tarvittavat vaiheet, jotka johtavat onnistuneeseen deal-tuotteeseen. Teet tämän usein käymällä ketjua taaksepäin läpi ja tunnistamalla kunkin vaiheen, tarvitut resurssit, odotteluajan ja tuotetun syötteen seuraavaan vaiheeseen. Visualisoit nämä.

Kanban – taulu, jossa esität prosessin kulun visuaalisessa muodossa. Tavoitteenasi on eliminoida kaikki turha tekeminen ja tunnistaa pullonkaulat. Teet vain tarvittavan, jotta seuraava vaihe pääsee eteenpäin. Tiimi käsittelee taulun avulla yhdessä kehitysehdotuksia ja seuraa jatkuvasti operatiivisen prosessin etenemistä. Keskeistä on työvaiheiden pilkkominen niin, että yhdessä vaiheessa ei ole liikaa tekemistä. Tehdään vain tarvittava syöte seuraavaa vaihetta varten.

Oma kokemuksemme eCraftilla on, ettei pidä väkisin puskea asioita eteenpäin, vaan katsoa kokonaisuutta ja sitä, missä on tilaa ja tarvittavat syötteet tehdä jokin vaihe valmiiksi.

Laaduntarkkailu: Huonot liidit kannattaa tappaa mahdollisimman ajoissa! Jokainen tarjousta kohti etenevä valmisteluvaihe maksaa. Diili, joka kuolee viime metreillä, on deal-tuotteen tuotantoprosessin epäonnistuminen. Se tulee aina kalliiksi.

Paitsi lopputuotteen laatu (onnistunut diili), myös itse prosessin laatu on tärkeä. Lean-myyntiprosessi on laadukas, kun se sisältää vähemmän työtä, odottelua ja resurssien hukkaamista.

Mikä muuttuu? Saat hallittavuutta ja käynnistät itsekorjaavan mekanismin.

Kun on kyse monimutkaisten palvelujen ja tuotteiden kauppaamisesta, nykyisillä myynninohjauksen menetelmillä et pysty aidosti mittaamaan myyntiprosessisi tehoa. Näet kyllä, kuinka moni liidi johtaa kauppaan (lead conversion rate). Mutta silloin vertaat keskenään hyvin erityyppisiä projekteja. Teet niin isoja yksinkertaistuksia, että menetät otteen projektien todelliseen sisältöön. Saat käteesi pelkkiä numeroita, jotka kertovat lopputuleman, mutta eivät auta kehittämään prosessia.

Lean-ajattelua seuraava myyntiprosessi mahdollistaa itse prosessin mittaamisen, ei vain lopputulemien. Näet, kuinka voit parantaa prosessia, koska resurssitörsääjät ja aikasyöpöt vaiheet tulevat näkyviksi. Ensimmäiset harjoitukset voit hyvin tehdä kynällä, whiteboardilla ja post-it lapuilla. Itse asiassa, koko homman voi hoitaa ilman it-projektia.

Olemme kokeilleet tätä ja saaneet myönteisiä ensikokemuksia. Toivon, että saamme tätä kautta tehtyä enemmän tarjouksia kuukaudessa, vähemmän rukkasia kuukaudessa ja tätä kautta liikevaihtoa ylös.