Artikkelit

    Mitkä asiantuntijaprosessit kannattaa määritellä ensin

    Yleisin kysymys ensimmäisessä tapaamisessa kuuluu: mikä olisi meille paras käyttötapaus. Se on väärä kysymys, koska se olettaa vastauksen riippuvan tekoälystä. Vastaus riippuu työstä. Kaksi organisaatiota samalla toimialalla, samankokoisina ja samoilla työkaluilla, päätyvät eri kohteisiin, koska niiden työ on eri tavalla järjestettyä. Olemme kirjoittaneet erikseen siitä, miksi yksilön promptaus ei nopeuta organisaatiota: prosessi ei ole koko yksikön prosessi vaan kymmenen ihmisen kymmenen tapaa. Tämä artikkeli vastaa siihen, mitä sille tehdään ensimmäisenä. Valinta ratkeaa kahdella akselilla ja yhdellä suodattimella. Ne voi käydä läpi itse, ilman ketään ulkopuolista, ja lopputulos on lista, jonka kanssa voi jo tehdä päätöksiä.

    Ensimmäinen akseli: toistuvuus

    Toistuvuus ei tarkoita samuutta. Tämä on se väärinkäsitys, joka pysäyttää useimmat keskustelut ensimmäisen viiden minuutin aikana, ja se kuuluu yleensä näin: meillä jokainen toimeksianto on erilainen. Yleensä se on totta ja yleensä se on merkityksetöntä. Erilaisuus on sisällössä, ei rakenteessa. Kuntokartoitus, due diligence, lupahakemus tai tarjouslaskenta tuottaa joka kerta eri lopputuloksen, mutta vaiheet ovat samat, päätöskohdat ovat samat ja hyväksymisehdot ovat samat. Juuri se tekee niistä hyviä kohteita. Testi on tämä: jos kaksi kokenutta tekijää kuvaisi työn vaiheet erikseen fläpille, kuinka samannäköiset kuvat olisivat. Jos vaiheet osuvat yhteen ja vain sisältö vaihtelee, työ on toistuvaa siinä mielessä kuin tässä tarvitaan.

    Toinen akseli: tuotteistusaste

    Toinen akseli on jana, jonka toisessa päässä on taiteilijamalli ja toisessa vakioprosessi. Taiteilijamallissa laatu asuu henkilössä. Kokenut asiantuntija tekee erinomaista työtä, mutta hän tekee sen omalla tavallaan, eikä kukaan ulkopuolinen pysty sanomaan tarkasti mitä hän tekee. Tämä on aitoa huippuosaamista. Se ei vain skaalaudu, se ei siirry uudelle tekijälle eikä se kestä eläköitymistä. Vakioprosessissa laatu asuu rakenteessa. Tekijä voi vaihtua ilman että lopputulos muuttuu. Kumpikaan pää ei ole moraalisesti parempi, ja moni organisaatio on taiteilijapäässä hyvästä syystä. Mutta vain toinen pää on määriteltävissä koneelle, ja tuotteistusaste on lähes aina päätös eikä työn ominaisuus. Useimmiten organisaatio on taiteilijapäässä siksi, ettei kukaan ole koskaan päättänyt toisin.

    Neljä ruutua ja mitä kussakin tehdään

    Kun akselit yhdistetään, syntyy nelikenttä, joka kertoo mistä aloitetaan. Korkea toistuvuus, matala tuotteistusaste: suurin tuotto. Työ toistuu jo, mutta jokainen tekee sen omalla tavallaan. Määrittely tuottaa tässä eniten, koska se ratkaisee sekä hajonnan että nopeuden. Vaatii eniten työtä asiakkaan asiantuntijoilta, koska tieto on ihmisissä. Korkea toistuvuus, korkea tuotteistusaste: nopein voitto. Prosessi on jo kuvattu ja siitä on sovittu. Määrittely on lähinnä olemassa olevan kääntämistä muotoon, jonka kone voi toteuttaa. Hyvä ensimmäinen kohde, jos halutaan tulos nopeasti. Matala toistuvuus, matala tuotteistusaste: älä aloita tästä. Ratkaise ensin liiketoimintakysymys: halutaanko tätä työtä ylipäätään toistaa. Jos vastaus on ei, automaatio ei ole ratkaisu vaan kalliimpi tapa tehdä sama päätös myöhemmin. Matala toistuvuus, korkea tuotteistusaste: määrittele, mutta odota volyymia. Kuvaus on arvokas jo itsessään, koska se säilyttää osaamisen. Automaation kannattavuus ratkeaa vasta kun volyymi kasvaa. Käytännön nyrkkisääntö: aloita ylimmältä riviltä. Kumpi ruutu valitaan, riippuu siitä kumpaa tarvitaan enemmän, nopeaa näyttöä vai suurta vaikutusta.

    Kolmas suodatin: todennettavuus

    Kun kaksi tai kolme ehdokasta on jäljellä, ne käydään läpi yhdellä kysymyksellä: onko lopputuloksen oikeellisuudella väliä, ja voiko sen tarkastaa. Jos molempiin vastaus on kyllä, prosessi kannattaa määritellä. Hyväksymisehdot ovat kirjoitettavissa, ja se on käytännössä koko määrittelyn ydin. Jos oikeellisuudella on väliä mutta sitä ei voi tarkastaa, kyseessä ei ole automaatiokysymys vaan suunnitteluongelma. Se pitää ratkaista ennen automaatiota, ei sen jälkeen. Prosessi, jonka lopputulosta kukaan ei osaa arvioida, on riski riippumatta siitä tekeekö sen ihminen vai kone. Kone vain tuottaa riskiä nopeammin. Jos oikeellisuudella ei ole väliä, kannattaa kysyä miksi työtä tehdään.

    Miksi "meillä ei ole dataa" ei ole este

    Tämä on toinen keskustelun pysäyttäjä, ja se menee useimmiten päinvastoin kuin oletetaan. Kiinnostavimmat kohteet ovat nimenomaan prosesseja, joista ei ole rakenteista dataa. Työ on tapahtunut ihmisten päässä, sähköposteissa, palavereissa ja liitetiedostoissa, eikä siitä ole jäänyt jälkeä mihinkään järjestelmään. Juuri siksi siihen ei ole päässyt käsiksi millään aiemmalla tekniikalla. Kun prosessi kuvataan, data alkaa syntyä sivutuotteena. Jokainen vaihe, päätös ja hyväksyntä jättää jäljen. Data ei siis ole määrittelyn edellytys vaan sen tulos. Kääntäen: jos prosessista on jo hyvää rakenteista dataa, se on todennäköisesti jo automatisoitu perinteisin keinoin. Silloin jäljellä oleva hyöty on pienempi kuin siellä, missä mitään ei ole.

    Milloin ei kannata määritellä

    Rehellisyyden vuoksi myös toinen suunta. Määrittely ei kannata, jos kyse on kertaluontoisesta selvityksestä, yhden ihmisen henkilökohtaisesta apuvälineestä tai muutaman käyttäjän kevyestä automaatiosta. Nämä ratkeavat valmiilla tuotteella halvemmalla ja nopeammin, eikä niistä kannata tehdä hanketta. Raja kulkee suunnilleen siinä, tarvitseeko lopputuloksen olla sama riippumatta siitä kuka sen tekee. Jos ei tarvitse, valmis työkalu riittää.

    Viiden kysymyksen itsetesti

    Vie tämä johtoryhmään ja vastatkaa ääneen. Mikä on kolme eniten toistuvaa toimeksiantotyyppiänne, ja kuinka monta niitä on vuodessa? Kuvaisivatko kaksi kokenutta tekijää niiden vaiheet samalla tavalla? Missä kohdassa joku hyväksyy jotain, ja mistä hän tietää että tulos kelpaa? Jos työ menee pieleen, huomataanko se, ja missä vaiheessa? Kuka talossa tietää tästä työstä eniten, ja kuinka monta vuotta hänellä on jäljellä? Jos kysymykseen kaksi vastaus on kyllä ja kysymykseen kolme vastaus on jokin muu kuin kokemus, teillä on kohde. Jos kysymykseen viisi vastaus on yksi nimi ja pieni luku, teillä on kiire.

    Mittakaavasta

    Yksi käytännön havainto valinnan tueksi. Kun asiantuntijaprosessi puretaan toteutuskelpoisiksi vaiheiksi, niitä tulee tyypillisesti neljästäkymmenestä kuuteenkymmeneen. Se kuulostaa paljolta, mutta valtaosa on teknisiä tehtäviä, jotka toistuvat prosessista toiseen. Laajemmassa ohjelmassa, jossa on mallinnettu useita kymmeniä työnkulkuja yli kolmensadan asiantuntijan kanssa, tämä näkyy siten että ensimmäinen prosessi on selvästi työläin ja seuraavat kevenevät. Osa määrittelystä on organisaatiokohtaista ja tehdään kerran, ei joka kerta. Siksi ensimmäisen kohteen valinta kannattaa tehdä huolella ja loput nopeammin.

    Seuraava askel

    Jos listalla on nyt yksi tai kaksi nimeä, seuraava askel on 30 minuutin kartoituskeskustelu. Käymme ehdokkaat läpi yhdessä ja arvioimme, mikä niistä tuottaa eniten ensimmäisenä. Ei toteutussitoumusta.

    Varaa keskustelu

    Usein kysytyt kysymykset

    K:Montako prosessia kannattaa ottaa ensimmäiseen erään?

    Yksi prosessi riittää, mutta se kannattaa purkaa muutamaksi työnkuluksi eikä yhdeksi. Kolme työnkulkua yhdestä prosessista on osoittautunut toimivaksi ensimmäiseksi eräksi: tarpeeksi laaja näyttääkseen kokonaisuuden, tarpeeksi rajattu valmistuakseen.

    K:Mistä tiedämme, onko meidän työmme liian vaihtelevaa?

    Kysykää kahdelta kokeneelta tekijältä erikseen, mitkä ovat työn vaiheet. Jos vastaukset ovat pääosin samat, työ ei ole liian vaihtelevaa. Jos ne poikkeavat merkittävästi, se ei sekään ole este, mutta se kertoo että ensin pitää sopia miten työ tehdään. Se on liiketoimintapäätös eikä tekninen kysymys.

    K:Pitääkö prosessi kuvata itse ennen kuin otamme yhteyttä?

    Ei. Nykyisistä kuvauksista on hyötyä, jos niitä on, mutta niiden puuttuminen ei ole este. Kuvaaminen on juuri se työ, jota ei kannata tehdä kahdesti eri tarkkuustasoilla.

    K:Entä jos prosessi muuttuu koko ajan?

    Muuttuva prosessi on tavallisempi kuin muuttumaton, eikä se ole ongelma. Määrittely on versioitu dokumentti, ei kiveen hakattu ohje. Ongelma syntyy vasta silloin, jos kukaan ei tiedä mikä nykyinen versio on, koska silloin muutos ei ole muutos vaan ajautumista.