Kun HR-johtajista tulee rakentajia
Kokeilun oivallus: Yhteistyössä toteutetut tekoälyprojektit tarjosivat syvällisiä oivalluksia HR:n valmiuksista, jotka ulottuvat pelkkää työkalujen kehittämistä laajemmalle.
Ongelman rajaaminen: Siirtyminen tunneanalyysistä taitojen kartoittamiseen korosti selkeiden ja saavutettavissa olevien tavoitteiden määrittelyn merkitystä.
Epäluottamus tekoälyä kohtaan: HR-ammattilaiset kohtaavat merkittäviä haasteita vastuunjaossa ja läpinäkyvyydessä nykyisillä tekoälyalustoilla.
Työkalun rakenne: Tekoälyarviointityökalussa korostui yhteistyö, sillä käyttäjät voivat vahvistaa tekoälyn tuottaman palautteen tai kyseenalaistaa sen.
Vastakkainasetteleva testaus: Onnistunut työkalukehitys edellyttää perusteellista testaamista monipuolisilla syötteillä, jotta poikkeustilanteisiin voidaan vastata tehokkaasti.
Kokoukset oli suunniteltu tunnin mittaisiksi. Ne venyivät lähes aina.
Se ei ole epätavallista, kun joukko henkilöstöhallinnon ammattilaisia kokoontuu keskustelemaan tekoälystä. Epätavallista oli se, mitä heidän pyydettiin tekemään tuolla keskustelulla. Ei analysoimaan sitä, ei julkaisemaan siitä mielipidekirjoitusta, vaan rakentamaan jotain.
Syksyllä 2025 kokosin ryhmiä, joita kutsuin rakentajaryhmiksi: pienen joukon henkilöstöhallinnon ja henkilöstötoimintojen ammattilaisia, joiden olin tunnistanut tekevän jo työtä ja pohtivan jo sitä, mitä henkilöstöhallinnon ala voisi tehdä tekoälyn avulla.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Oletus oli yksinkertainen. Ongelmat parhaiten tuntevat ihmiset ovat parhaassa asemassa rakentamaan ratkaisuja. Kysymys oli, pystyisivätkö he siihen.
Kaiken kaikkiaan rakentaisin neljä ryhmää ja ymmärtäisin matkan varrella, että tavoitteiden määrittely näille tapaamisille on helpommin sanottu kuin tehty. Lopulta useimmat ryhmät hiipuivat, kun niillä oli vaikeuksia toteuttaa alkuperäistä visiota tai päätyä yhteen tavoitteeseen. Kalenterit, työmäärät ja varsinaisten töidemme vaatimukset johtivat usein keskusteluihin, jotka tuottivat loistavia ideoita, mutta eivät koskaan vieneet niitä käytäntöön.
Yksi ryhmä kuitenkin kokoontui yhteen ja pääsi parhaansa mukaan maaliin asti. Tosiasia on, että mitä syvemmälle uppoudut itse rakentamisen sokkeloon, sitä vaikeammaksi käy yhteisen vision kunnioittaminen ja tekniseen haasteeseen vastaaminen.
Tämä tarina kertoo siitä, mitä näistä tapaamisista syntyi, ja tarjoan sen teille tapaustutkimuksena omien ratkaisujenne rakentamisesta.
Ryhmä
Nämä eivät olleet tekoälyyn epäilevästi suhtautuvia, jotka olisivat tarvinneet vakuuttelua. He olivat ammattilaisia, jotka olivat jo panostaneet tähän hetkeen. Ryhmä tarjosi heille jäsennellyn tilan lopettaa neuvonantajana toimiminen ja ryhtyä tekemään.
Ensimmäinen rehellinen keskustelu
Ensimmäisessä tapaamisessa nousi esiin asia, joka harvoin päätyy julkaistuihin henkilöstöhallintoa koskeviin kommentteihin: kuinka turhautuneita nämä ammattilaiset todella ovat työkaluihin, joita heidän oletetaan käyttävän.
Turnmeyer määritti keskustelun sävyn. Hän oli yrittänyt saada teknistä dokumentaatiota siitä, miten mieliala-analyysi toimi BambooHR:n, Paycomin ja Guston sisällä — ei tyrmätäkseen työkaluja, vaan koska hänen lakitiiminsä tarvitsi ymmärtää niitä ennen niiden käytön hyväksymistä.
Myyntitiimit eivätkä lainopilliset edustajat pystyneet vastaamaan hänen kysymyksiinsä. Tekoälyominaisuudet olivat olemassa. Vastuu niiden toimintatavasta ei ollut.
Gillies käsitteli rinnakkaista jännitettä. Organisaation sisältä oli esitetty huolia tekoälyn ympäristövaikutuksista, ja jotkut kollegat halusivat yksinkertaisesti kieltää työntekijöiden tekoälyn käytön. Gillies vastusti tätä.
Tekoälyn kieltäminen kokonaan johtaa sen salaiseen käyttöön ja kasvaneisiin riskeihin. Tekoälyn hyödyntäminen suojatoimien avulla on parempi lähestymistapa.
Melina Gillies · henkilöstöjohtaja, Flex Networks
Ensimmäisen tunnin päätteeksi ryhmä oli päätynyt diagnoosiin, josta kaikki saattoivat olla samaa mieltä. Gilliesin sanoin yritysten HR-alustojen sisäänrakennetut tekoälyominaisuudet olivat "usein perustason ominaisuuksia ja niistä puuttui toiminnallisuuksia."
Toimivat työkalut ovat yleensä räätälöityjä – rakennettu tiettyjä ongelmia, asiayhteyksiä ja yrityksiä varten. Turnmeyer halusi vähemmän työkaluja, ei enemmän – ajatuksen, jonka kuulen usein henkilöstö- ja operatiivisen toiminnan johtajilta. Hän saattoi kuvitella tulevaisuuden, jossa kyvykäs tekoäly, jolle toimitetaan oikeat asiakirjat, tekisi HRIS-järjestelmän tarpeettomaksi.
He käsittelivät myös aihetta, johon harvoin paneudutaan näin suoraan: käyttäytymisen seurannan etiikkaa. Keskustelussa nousi varhain esiin ajatus käyttää kokousten hylkäysprosentteja, järjestelmään kirjautumisten aukkoja tai poikkeavia työaikoja sitoutumattomuuden sijaismittareina.
Samoin esiin nousivat tämän lähestymistavan rajoitukset. Satterfield toi esiin riskin, jonka jokainen sitoutumisen seurantaan tarkoitettu työkalu kohtaa ennemmin tai myöhemmin: toimettomuusväsymyksen. Jos keräät tietoja etkä toimi niiden perusteella näkyvästi, työntekijät lakkaavat luottamasta järjestelmään. Tiedosta tulee kohinaa ja työkalusta tekoälyteatteria.
He eivät olleet valmiita rakentamaan tunneanalyysityökalua. Aihe oli liian laaja, siihen liittyi liikaa eettisiä ongelmia ja se oli liian helppo toteuttaa katastrofaalisesti väärin. Niinpä he muuttivat suuntaa.
Oikean ongelman löytäminen
Toinen tapaaminen alkoi rehellisellä myönnytyksellä siitä, että alkuperäinen suunta oli liian kunnianhimoinen ja liian epäselvä.
"En tiedä, mittaako se sitoutumista", Turnmeyer sanoi, "vai mittaako se vain jotakin, joka edellyttää keskustelua."
Ero on merkittävämpi kuin miltä se saattaa kuulostaa. Monet HR-teknologiat tekevät sen virheen, että ne kohtelevat tietoa keskustelun korvikkeena. Ryhmä pyrki käyttämään tekoälyä tuomaan esiin hetket, jolloin keskustelu on tarpeen, ja tekemään tuosta keskustelusta paremman.
Satterfield esitteli ajatuksen, joka ohjaisi projektin loppuosaa. Aiemman työnantajan palveluksessa vallinneen rekrytointikiellon aikana hän oli laatinut osaamisen itsearvioinnin osaajahankinnan tiimilleen – tavan kartoittaa, mitä ihmiset osasivat tehdä suhteessa siihen, mitä he todella halusivat tehdä. Tämä tuotti lämpökartan, joka teki työntekijöiden uudelleensijoittamista koskevista päätöksistä inhimillisempiä ja strategisempia.
Se ei ollut tekoälypohjainen. Se oli Microsoft Forms -lomake. Taustalla oleva logiikka oli kuitenkin toimiva, käyttötapaus todellinen, ja hän oli nähnyt sen toimivan.
"Suuret toimittajat yrittävät tehdä tätä, mutta kukaan ei vielä oikeastaan tee sitä hyvin, eikä monilla yrityksillä ole varattuna budjettia tämänkaltaiselle teknologialle ydin-HRIS-järjestelmänsä lisäksi", hän sanoi.
Ryhmä näki mahdollisuuden. Mitä jos he rakentaisivat tekoälyn ehdoilla suunnitellun version? Sellaisen, joka olisi keskusteleva kliinisen sijaan, tulevaisuuteen suuntautuva vaatimustenmukaisuuden sijaan ja hinnoiteltu yksittäisille HR-johtajille sen sijaan, että se olisi lukittu yrityssopimusten taakse?
Se, miten HR puhuu HR:lle HR:stä, on perustavanlaatuisesti erilaista. Se voi olla todellinen arvo, ja useimmat työkalut eivät huomioi sitä lainkaan.
Melina Gillies · henkilöstöjohtaja, Flex Networks
Fisher kuunteli ryhmän työskentelyä ja esitti havainnon, joka muutti projektin potentiaalin näkökulmaa. Hän oli kokenut HR:n kirjon molemmat ääripäät: vaatimustenmukaisuuden ja viitekehyksen ehdoilla toimivan, transaktionaalisen mallin sekä harvinaisemman ihmislähtöisen ammattilaisen, joka puhui hänelle "kuin ihminen, joka tuntui olevan minun puolellani."
"Toisen tyypin kieli", hän sanoi, "ei koskaan tuntunut siltä, että se olisi peräisin vuosikymmeniä sitten laaditusta viitekehyksestä. Se vain tuntui hyvältä."
Gillies tarttui tähän ajatukseen. Hän perusteli, että heidän työkalunsa erottava tekijä olisi sävy ja rakenne. Entä jos se voisi jäljitellä tapaa, jolla HR-ammattilaiset todella puhuvat toisilleen konferenssissa, istuntojen välillä ja epävirallisesti? Entä jos se ymmärtäisi ilmauksen "poliittisesti taitava" ei valintaruutuna vaan moniulotteisena, kiistanalaisena ja tilanteisesti monimutkaisena asiana, josta kokeneet ammattilaiset keskustelevat keskenään?
Suunnaksi muodostui ennen palkkaamista käytettävä arviointityökalu HR- ja osaajahankinnan johtajille, jotka tarvitsevat paremman tavan arvioida rekrytoijakandidaatteja ennen heidän palkkaamistaan. Se ei olisi persoonallisuustesti tai ansioluettelon seulontatyökalu, vaan jäsennelty ja keskusteleva arviointityökalu, joka voisi kertoa rekrytoivalle esihenkilölle, osasiko hänen edessään istuva henkilö todella tehdä työn. Työkalu tuntuisi vähemmän suoritusarvioinnilta ja enemmän keskustelulta jonkun sellaisen kanssa, joka ymmärsi rekrytoinnin sisäpuolelta.
Oivalluksen hetki
Kolmanteen tapaamiseen mennessä ryhmä oli perehtynyt syvälle työkalun arkkitehtuuriin: mitä osaamisalueita arvioitaisiin, miten ne jäsenneltäisiin eri tasoille ja miten otettaisiin huomioon ero sen välillä, mitä ihmiset sanovat osaavansa ja mitä he tosiasiassa osaavat.
Gillies esitti kritiikin nykyisiä viitekehyksiä kohtaan kuvailemalla SHRM:n osaamismallia "joiltakin osin hyvin perinteiseksi ja hyvin menneisyyteen katsovaksi". Ammatti kärsi hänen ilmauksensa mukaan edelleen "jälkiteollisesta krapulasta" – se perustui vaatimustenmukaisuuteen ja hierarkiaan ja oli suunniteltu maailmaan, joka oli jo väistymässä.
Heidän työkalunsa oli suunnattava johonkin muuhun kuin siihen, mitä henkilöstöjohtajien tarvitsi tietää – siihen, mitä heidän tarvitsi osata tehdä.
Oletko valmis keskustelemaan toimitusjohtajan kanssa hänen suoriutumisestaan? Jos et ole, et ole vaikeiden keskustelujen asiantuntija.
Erin Turnmeyer · henkilöstötoimintojen varatoimitusjohtaja
Turnmeyerillä oli valaiseva esimerkki. Hän oli hiljattain suorittanut SPHR-kokeen. Asiat, jotka kokeessa edellytettiin hänen tietävän – säädökset, menettelylliset määritelmät ja luokittelusäännöt – olivat sellaisia, jotka kuka tahansa pätevä HR-ammattilainen yksinkertaisesti tarkistaisi.
Vaikeat taidot eivät olleet sertifioinnin sisältöä. Niihin kuuluivat esimerkiksi seuraavat: Pystytkö istumaan toimitusjohtajaa vastapäätä ja kertomaan hänelle jotain, mitä hän ei halua kuulla? Pystytkö puolustamaan työntekijää, kun liiketoimintaperusteet ovat epäselvät? Työehtosääntöjen ulkoa opetteleminen ei vastaa näihin kysymyksiin.
Fisher vei ajatusta pidemmälle. Hän oli työskennellyt vuosia muutosjohtamisen parissa ja huomannut, että organisaation kykyä selviytyä muutoksesta ennusti parhaiten jokin muu kuin tietty yksittäinen taito. Ratkaisevaa oli henkilön suhde epäselvyyteen.
Se, miten hyvin saat selville, kuinka mukavasti joku suhtautuu epämukavuuteen – tai muutoksen tahtiin yleensä – kertoo hyvin paljon kyvystäsi toimia tässä uudessa maailmassa.
Tim Fisher · tekoälyjohtaja , Black and White Zebra
Sitten tuli se, mitä ryhmä myöhemmin kutsui salaiseksi ainesosaksi.
Gillies esitti kysymyksen. Entä jos työkaluun rakennettaisiin ristiintarkistus? Jos joku arvioisi itsensä konfliktinhallinnan asiantuntijaksi, mutta kuvaisi jatkokysymykseen antamassaan luonnollisen kielen vastauksessa tilanteita, jotka kuulostaisivat kaikelta muulta kuin asiantuntevalta toiminnalta, voisiko tekoäly havaita sen? Voisiko se hienovaraisesti huomauttaa, että tässä saattaa olla puute?
”Tuo oli lamppu syttyi -hetki”, Turnmeyer sanoi.
Satterfield huomautti, että jokainen taitoinventaarioiden parissa työskennellyt on nähnyt tästä ongelmasta erilaisia versioita. Ihmiset arvioivat usein itsensä hyvin eri tavalla kuin heidän todellinen kokemuksensa tai käyttäytymisensä antaisi olettaa.
Työkalun arvo ei syntyisi siitä, että se tallentaisi, mitä ihmiset uskoivat itsestään. Arvo syntyisi kalibroinnista – hienovaraisesta, tietoon perustuvasta kitkasta minäkuvan ja osoitetun kyvykkyyden välillä.
Arviointi ei olisi vain peili. Se olisi enemmän ”peili, peili seinällä” kuin mihin useimmat ovat työpaikkojen arvioinneissa tottuneet.
Rakentamisen todellisuus
Mikään tästä ei ollut helppoa. Ja ryhmä tiesi sen jo alusta lähtien.
Sitkein haaste ei ollut tekninen. Se oli laajuus. Jokainen tapaaminen synnytti kymmenen uutta suuntaa, joista jokainen oli aidosti arvokas ja jokainen olisi voinut nielaista koko projektin. Turnmeyer toi asian esiin varhain ja toistuvasti.
”Varmista, että se tekee ensimmäisen asian oikein, jotta hankkeen laajuus ei karkaa niin käsistä, ettet pysty luomaan sitä”, hän sanoi.
Satterfield esitteli ryhmälle ohjaavan periaatteen: vähimmäistoimivan tuotteen ja vähimmäisarvokkaan tuotteen välisen eron. Toimiva tuote toimii. Arvokas tuote saa ihmiset palaamaan.
Arviointityökaluilla kyllästetyillä markkinoilla käyttöliittymä, joka ei tarjoa ensimmäisellä käyttökerralla jotain merkityksellistä, ei saa toista mahdollisuutta kehittyä. Kynnys ei liity toiminnallisuuteen. Se liittyy arvoon.
Jos tuote ei tarjoa riittävästi arvoa heti ensimmäisellä käyttökerralla, käyttäjät eivät todennäköisesti palaa myöhemmin katsomaan, onko se kehittynyt.
Kelly Satterfield · HR-johtaja ja konsultti
Mukana olivat myös käytännön rajoitteet, jotka jokainen kehitystiimin ulkopuolella rakentamista yrittänyt tuntee hyvin: käyttöönotto, maksujen käsittelyinfrastruktuuri, integrointi olemassa oleviin järjestelmiin sekä kesken istunnon sulkeutuvat konteksti-ikkunat, jotka pyyhkivät pois tuntikausien tuottavan työn.
Varhainen versio noudatti työkalun ydinkulkua. Rekrytoijan tehtävään hakeva henkilö lataa ansioluettelon, työkalu päättelee alustavan taitoprofiilin ja ohjaa hänet sitten läpi keskustelunomaisten kysymysten sarjan, jonka tarkoituksena on kalibroida alustavaa arviota sekä lisätä siihen kontekstia ja syvyyttä.
Lopuksi rekrytoinnista vastaava johtaja saa kuvan siitä, missä hakija todellisuudessa on suhteessa määriteltyyn pätevyyskehykseen.
Fisher perusti ensisijaisen kehitysympäristön Lovableen – koodittomaan tekoälyrakentajaan, joka luo julkisesti käytettäviä työkaluja keskustelun avulla sitomatta käyttäjiä tiettyyn LLM:ään – jotta tekninen arkkitehtuuri pysyisi ryhmän ajattelun tahdissa muodostumatta omaksi pullonkaulakseen.
Suunnitelmasta toteutukseen
Neljänteen tapaamiseen mennessä ryhmä ei enää suunnitellut abstraktia työkalua. He rakensivat sitä ja huomasivat, kuten rakentajat aina huomaavat, että idean ja toteutuksen välinen etäisyys on juuri se kohta, jossa todellinen oppiminen tapahtuu.
Fisher oli koonnut ennen puhelun alkamista perustason mukautetun GPT:n, joka sisälsi ohjeet, alustavan pätevyyskehyksen ja aiemmissa tapaamisissa kartoitetun keskustelulogiikan alkeet. Suunnitelmana oli, että kaikki pääsisivät käyttämään sitä, syöttäisivät sille kehotteita yhdessä ja alkaisivat säätää sen äänensävyä ja toimintaa reaaliajassa. Suunnitelma törmäsi heti todellisuuteen.
Jaettu linkki ei toiminut kenelläkään muulla kuin minulla. Työtilan käyttöoikeudet, alustan oikut ja tapa, jolla ChatGPT käsittelee ulkoista käyttöä, veivät istunnon ensimmäisen neljänneksen.
Kyse oli pienestä turhautumisesta, juuri sellaisesta, joka ei koskaan päätyisi tuotetiedotteeseen, ja se oli opettavainen. Työkalut, joita ammattilaiset todella käyttävät asioiden rakentamiseen, eivät toimi esittelyjen tavoin.
Tässä kuvakaappauksessa näkyy, miltä ryhmän rakentaman Talent Scout -työkalun tervetulonäyttö lopulta näyttäisi.
Kun kaikki katsoivat samaa näyttöä, tapahtui jotain kiinnostavampaa. Ryhmän vielä keskustellessa siitä, millaiseen muotoon pätevyysmääritelmät pitäisi laatia, Gillies avasi Clauden erilliseen ikkunaan ja muunsi pisteytystaulukon rakenteiseksi JSON-muodoksi – suorana puhelun aikana.
"Käytän Claudea, koska se on tähän parempi kuin ChatGPT", hän sanoi kursailematta. Hän pudotti muotoillun tiedoston ryhmäkeskusteluun muutamaa minuuttia myöhemmin. Kukaan ei pysähtynyt huomioimaan sitä. He vain jatkoivat eteenpäin.
Juuri tällainen liikkeessä tapahtuva ongelmanratkaisu – pullonkaulan muuttaminen ratkaistuksi ongelmaksi tekemättä siitä kokouksen pääasiaa – erottaa ammattilaiset, jotka ovat todella omaksuneet nämä työkalut, niistä, jotka vielä opettelevat käyttämään niitä.
Kuka saa sanoa viimeisen sanan
Satterfield esitti kysymyksen, jolla olisi merkittäviä vaikutuksia sekä työkalun arkkitehtuuriin että sen lopulliseen vastaanottoon: tuottaako tekoäly lopullisen arvion vai vahvistaako käyttäjä sen?
Ero ei ole kosmeettinen. Jos työkalu antaa tuomion, kuten "Vastaustesi perusteella olet ehdokaskeskeisyydessä tasolla 2", se asettaa tekoälyn auktoriteetin asemaan. Jos se sen sijaan esittää alustavan tulkinnan ja kutsuu käyttäjän haastamaan sen, dynamiikka muuttuu täysin. Arvioinnista tulee yhteistyöhön perustuvaa eikä arvioivaa. Käyttäjä osallistuu prosessiin, ei ole sen kohde.
"Hyväksytkö tämän palautteen?" Turnmeyer sanoi ajatuksen valjettua. "Pidän siitä tavallaan todella paljon."
Gillies rakensi logiikkaa pidemmälle. Jos käyttäjä ei hyväksy arviota, työkalu kysyy, mikä siinä tuntuu väärältä – ja käyttää sitten vastausta joko arvionsa uudelleenkalibrointiin tai sen hienovaraiseen vahvistamiseen käymällä läpi todisteet.
Tällainen keskusteleva vuoropuhelu luo psykologisen turvallisuuden, jota työkalu tarvitsee ollakseen aidosti hyödyllinen. Ihmiset eivät muutu palautteen perusteella, johon he eivät luota. Sitoutumisen saavuttaminen ei ole pehmeä ominaisuus, vaan mekanismi.
Ensimmäinen todellinen testi
He päättivät testata prototyyppiä suorana. Turnmeyer tarjoutui antamaan yhteen arviointikysymykseen tarkoituksella niukan vastauksen – sellaisen, jonka sitoutumaton ehdokas tai hajamielinen työntekijä voisi antaa.
Hän kuvaili kiistelleensä esihenkilönsä kanssa palkkaerosta, menettäneensä ehdokkaan eikä tienneensä lainkaan, mikä lopputulos oli ollut. Se oli HR:n vastine vastaukselle "Pidän vain todella paljon ihmisistä", kun kysytään, miksi haluat työskennellä HR:ssä.
Työkalu arvioi vastauksen heti. Se määritti tason. Se oli kannustava. Se oli myös väärässä – ei tosiasiallisesti, vaan ennenaikaisesti. Se oli tehnyt oletuksia siitä, mitä vastaus merkitsi, sen sijaan että olisi pyytänyt arvioinnin täsmällisyyteen tarvitsemansa lisäkontekstin.
Jos aiot antaa kenellekään muun arvosanan kuin ”odotukset täyttävä”, sinun on annettava yksityiskohtaisia esimerkkejä. Tekoälyn pitäisi vaatia itseltään samaa tasoa.
Erin Turnmeyer · henkilöstötoimintojen varajohtaja
Turnmeyer teki suoran rinnastuksen omiin suorituksen arviointikäytäntöihinsä. Hän oli jo pitkään edellyttänyt esihenkilöiltä konkreettisia todisteita ennen kuin nämä arvioivat jonkun suoriutumisen odotukset ylittäväksi tai niiden alittavaksi.
Saman kurinalaisuuden pitäisi koskea myös työkalua. Ennen tason määrittämistä sen on ansaittava oikeus tehdä niin esittämällä kysymykset, joiden avulla arvio olisi perusteltavissa. Jälleen kerran huoneessa ollut HR-asiantuntemus teki tekoälystä paremman – ei päinvastoin.
Satterfield toi esiin lisähaasteen, jonka työkalu oli sivuuttanut. Niukka vastaus saattoi heijastaa käytäntöä eikä osaamista.
Jos esihenkilö oli aidosti asettanut kiinteän palkkakaton, voimakkaampi asian ajaminen ei olisi muuttanut lopputulosta. Työkalu oli arvioinut henkilöä, vaikka sen olisi pitänyt kysyä tilanteesta. Täsmennyskysymykset eivät olleet viimeistelyä. Ne erottelisivat hyödyllisen arvioinnin perusteettoman itsevarmasta.
Turnmeyer otti ohjeiden kirjoittamisen kotitehtäväkseen: miten työkalun voi kehottaa esittämään täsmennyskysymyksiä oikeilla hetkillä ilman, että jokainen vuorovaikutustilanne tuntuu kuulustelulta?
Tässä kuvakaappauksessa näkyy esimerkki siitä, mitä lopullinen tuote tekisi: se esittäisi tarkentavia kysymyksiä ja kannustaisi ehdokasta menemään syvemmälle.
Ongelma on vaikeampi kuin miltä se kuulostaa, ja hän tiesi hyvin, että rima oli poikkeuksellisen korkealla.
"Sen on oltava parempi kuin ihminen", hän sanoi. "Se on standardi."
Testaaminen omana osaamisalueenaan
Työskentelysessiossa syntyi myös yksi koko ryhmän käytännössä hyödyllisimmistä metodologisista oivalluksista. Kun Satterfield kysyi, miten ryhmä yleensä testasi tällaisia työkaluja, sekä Turnmeyer että Gillies vastasivat tavalla, joka paljasti jotain tärkeää siitä, miltä perusteellinen testaaminen käytännössä näyttää.
Etusuositustyökalussaan, jonka piti näyttää tarkasti, kuuluivatko tietyt lääkkeet yrityksen terveyssuunnitelman piiriin, Turnmeyer testasi nimenomaan poikkeustapauksia. Ei ilmeisiä ja suosittuja lääkkeitä, joita malli oli toistuvasti kohdannut koulutuksensa aikana. Hän testasi harvinaisia lääkkeitä kategorioissa, joissa syntyi todennäköisimmin varmaääninen hallusinaatio.
"Testasin epäsuosittuja lääkkeitä", hän sanoi, "koska Claude näytti minulle, mitä se teki rakentaessaan sitä."
Tällainen vastakkainasetteluun tähtäävä tarkoituksellisuus testaamisessa on harvinaista rakentajille, jotka tulevat insinööritaustan ulkopuolelta. Juuri se kuitenkin erottaa luottamusta saavuttavat työkalut niistä, jotka hylätään vähin äänin kiusallisen epäonnistumisen jälkeen.
Jo rakennetun karsiminen
Juuri ennen lomia pidetty uudelleenkokoontuminen alkoi kysymyksellä, joka oli vaikeampi esittää kuin miltä se kuulostaa: mihin ansioluettelon lataustoimintoa oikeastaan tarvitaan?
Gillies nosti asian esiin. Arvioinnissa käyttäjiä pyydettiin pohtimaan tarkasti omia kykyjään. Toiko ansioluettelo esiin tietoa, jota käyttäjä ei olisi voinut antaa suoremmin vastaamalla kysymyksiin? Kukaan ryhmästä ei ollut varma, että näin oli. Alkuperäisenä tarkoituksena oli säästää aikaa ansioluetteloiden jäsentäjän tavoin, mutta emme enää olleet vakuuttuneita siitä, että toiminto todella täytti tarkoituksensa.
He sopivat poistavansa sen.
Tämä on tuotekehityksessä harvinaisempaa kuin miltä kuulostaa. Ryhmä oli käyttänyt lataustoimintoon paljon aikaa – rakentanut sen, testannut sitä ja seurannut, kuinka Satterfieldin ansioluettelo jäsennettiin ja pisteytettiin väärin. Sen karsiminen vaati uppoutuneiden kustannusten logiikan ohittamista – juuri tuon logiikan vuoksi tiimit jatkavat usein sellaisten asioiden lisäämistä, joihin ne ovat jo investoineet.
Aloita lopputulos mielessäsi ja määrittele, miltä hyvä lopputulos näyttää. Jos et pysty kuvailemaan, mitä varten ominaisuus on olemassa, et pysty puolustamaan sitä.
Turnmeyer esitti metodologiaan liittyvän näkemyksen. Jälkikäteen hän ajatteli, että he olisivat saattaneet edetä nopeammin määrittelemällä työkalun toiminnan täysin ennen ensimmäisenkään kehotteen kirjoittamista. He olivat käyttäneet jonkinlaista ketterää mallia – rakenna, testaa, säädä – vaikka heidän rakentamansa kokonaisuuden monimutkaisuus olisi saattanut vaatia enemmän vesiputousmallin kaltaista lähestymistapaa: määrittele tekniset vaatimukset ensin kunnolla ja rakenna vasta sitten niiden pohjalta.
Hänellä oli eräästä toisesta rakentamastaan työkalusta 130-sivuinen suunnitteluasiakirja, joka oli opettanut hänelle tämän läksyn. Täydellinen määrittely ei kerro vain, mitä pitää rakentaa. Se kertoo myös, mitä ei rakenneta, mikä osoittautuu yhtä hyödylliseksi.
Gillies täsmensi tuotteen keskeistä ongelmaa. Kaiken sen, mitä työkalu näytti ruudulla, piti viedä pidemmälle. Arviointi, joka tuo tiedot esiin, ei ole sama asia kuin työkalu, joka kertoo, mitä niiden perusteella pitäisi tehdä. Tämä tulosten ja toiminnan välinen kuilu on kohta, jossa diagnostiset työkalut lakkaavat huomaamatta olemasta hyödyllisiä – ja useimmat niistä eivät koskaan kuroo tätä kuilua umpeen.
Rakentaminen yksin
Tammikuuhun mennessä Satterfield oli tehnyt suurimman osan rakentamisesta itse, kun taas muun ryhmän oli vaikea irrottautua 9–5-työnsä vetovoimasta ja ajanvievyydestä, jotta projektille olisi jäänyt aikaa. Eihän tästä kukaan saanut palkkaa.
Hän oli poistanut ansioluettelon lataamisen, kuten ryhmä oli sopinut. Hän oli lisännyt puhesyötteen – käyttäjät pystyivät nyt vastaamaan arviointikysymyksiin puhumalla kirjoittamisen sijaan, mikä mahdollisti keskustelunomaisemman vastaustavan, jota oli vaikeampi manipuloida kuin tekstikenttää.
Hän oli käyttänyt ChatGPT:tä synteettisten testivastausten luomiseen ("Olen tässä vahva ja tässä heikko juniorirekrytoija, anna minulle vastauksia") ja siirtynyt sitten Lovableen syöttämään vastaukset sinne ja tarkkailemaan, miten työkalu pisteytti ne.
Johtajan koontinäyttö oli työkalun logiikan toinen puolisko – näkymä, jota TA-johtaja tai CHRO käyttäisi nähdäkseen, miten ehdokas oli suoriutunut, missä puutteet olivat ja miten hänen osaamisensa voisi täydentää olemassa olevan tiimin vahvuuksia ja tarpeita.
Tämä teki organisaatiorakenteesta todellisen ongelman, koska työkalun piti tietää, kuka arvioi ketä ja kenellä oli oikeus nähdä tulokset.
Satterfield oli yrittänyt ratkaista tämän pyytämällä käyttäjiä syöttämään nimensä, tehtävänimikkeensä ja esihenkilönsä nimen (koska dataintegraatiota ei ollut). Tämä logiikka kuitenkin petti yleisessä tilanteessa: henkilöstöhankinnan johtaja halusi lähettää arvioinnin laajemmalle rekrytointiorganisaatiolle, johon kuului sekä suoria että epäsuoria raportointisuhteita. Organisaation kartoituslogiikka ei ollut riittävän hienojakoinen ottamaan tällaista rakennetta huomioon.
Teoriassa nämä tiedot antaisivat työkalulle paremman käsityksen arvioinnin suorittajan roolista, mutta lisätietojen kerääminen teki asioista monimutkaisempia.
Turnmeyer oli jo ratkaissut tämän ongelman erään version toisessa yhteydessä. Hänen omalle yritykselleen rakentamansa suorituksen johtamisen työkalu toimi Google Sheetsin, Slackin ja Clauden avulla. Google Sheets tallensi tiedot. Slack oli käyttöliittymä, jonka kanssa työntekijät olivat vuorovaikutuksessa. Claude hoiti analyysin ja palautteen tuottamisen.
Arkkitehtuuri oli yksinkertaisempi kuin miltä se kuulosti: laskentataulukko, jossa oli nimi, sähköposti, tehtävätaso ja tehtävänimike. Erillinen välilehti, joka yhdisti tehtävätason osaamisvaatimuksiin.
”Yritykseni tietoturvatiimi halusi tarkistaa työkaluni”, hän kertoi ryhmälle. ”Sanoin, että se oli tallennettu Google Docsiin. He totesivat: ’Ai, se on noin yksinkertaista.’”
Yksinkertaista, mutta Turnmeyer oppi sen vasta rakentamalla. Hän ei ollut kolme viikkoa aiemmin tiennyt, että lokitus oli olemassa – toiminto, joka tallentaa käyttäjän edistymisen, jotta työkalu ei nollaudu, kun joku poistuu hetkeksi ja palaa myöhemmin.
”Kiroilin Claudelle”, hän sanoi, ”kunnes se kertoi minulle, että lokitus oli olemassa.”
Tätä rakentaminen todella opettaa. Ei sitä, mitä suunnittelit oppivasi, vaan sitä, mistä et tiennyt tarvitsevasi tietoa.
Taustalla oleva kysymys
Jossain tammikuun tapaamisen vaiheessa keskustelu päätyi kysymykseen, jota se oli kiertänyt kuukausien ajan.
Ryhmä keskusteli jatkuvasti arkkitehtuurista, käyttöoikeuksista, tallennuksesta ja koontinäytöistä – kaikki olivat todellisia ongelmia. Niiden alla oli kuitenkin vielä perustavanlaatuisempi kysymys. Mitä he oikeastaan yrittivät rakentaa ja kenelle?
Alun perin suunniteltuna työkalu oli valintadiagnostiikka – jotain, jonka TA-johtaja voisi lähettää ehdokkaalle tai sisäiselle työntekijälle arvioidakseen, vastasivatko tämän todelliset valmiudet ansioluettelossa esitettyä, ja tuodakseen tämän kokonaiskuvan esiin ennen valintapäätöksen tekemistä.
Tässä näkyy valikoima kuvakaappauksia siitä raporttityypistä, jonka työkalu tuotti haastateltavalle. Arvioijalle nykyisen tiimin vahvuuksien koontinäyttö auttaa keskittymään siihen, mitä haastateltavalta kannattaa arvioida, jotta nähdään, paikkaavatko hänen vahvuutensa TA-tiimin heikkouksia.
Tuo ydin ei ollut muuttunut. Mutta jokainen heidän tekemänsä käytännön päätös – johtajan koontinäytön lisääminen, tilausmallien pohtiminen ja kirjautumiskulun suunnittelu – veti heitä kohti jotain monimutkaisempaa.
Reaaliaikaiset koontinäytöt tarkoittivat jatkuvaa käyttöoikeutta, mikä tarkoitti tilausmaksuja ja vei heitä lähemmäs sellaisia yritystason työkaluja, joita monien organisaatioiden on vaikea hankkia tai ottaa tehokkaasti käyttöön.
”Emme yritä ryhtyä HCM-toimittajaksi”, Satterfield sanoi.
Turnmeyer oli rehellinen oman näkemyksensä suhteen.
”Tarkoitukseni oli vain oppia jotain uutta.”
Se ei ollut hankkeesta vetäytymistä. Se oli täsmällinen kuvaus siitä, mitä kokeilu oli hänelle jo tuottanut. Hän oli oppinut uusia asioita ja oli jo rakentamassa uutta suorituksen johtamisen työkalua, johon ryhmältä saadut opit oli otettu mukaan.
Hänen ei tarvinnut tuotteistaa ryhmän työkalua saadakseen siitä todellista hyötyä.
Tässä vaiheessa oma kiinnostukseni oli ennen kaikkea toimituksellinen. Halusin kertoa tarinan ja tarjota jotain, jota ihmiset voisivat tarkastella – en tilauspohjaista tuotetta, vaan esimerkin siitä, miten HR-ammattilaiset voisivat pohtia vastaavaa työkalua ja ehkä rakentaa sellaisen itse.
Tämän artikkelin kirjoittaminen oli osa sitä. Voisinko tehdä ladattavan oppaan? Entä myöhemmin live-tapahtuman, jossa ryhmä voisi keskustella tekemästään, yleisö voisi olla vuorovaikutuksessa työkalun kanssa ja keskustelu voitaisiin tallentaa podcastiksi? Minulla oli paljon ideoita, mutta aika niiden toteuttamiseen, kun uuden vuoden tavoitteet kasaantuivat meidän kaikkien eteen, kävi vähiin.
Satterfieldin kiinnostus oli kaupallisesti suuntautuneinta, ja hän ilmaisi sen selkeästi. Hän halusi lopulta tuotteistaa työkalun. Hän ei aikonut tehdä sitä yksin. Hän oli kuitenkin valmis jatkamaan rakentamista kohti jotain, joka voitaisiin jonain päivänä myydä.
Tuo tarkoitusperien jakautuminen kolmeen suuntaan — oppimiseen, tarinankerrontaan ja tuotteeseen — on luultavasti luontaista mille tahansa tällaiselle ryhmälle. Rehellinen keskustelu aiheesta tammikuussa oli hyödyllisempi kuin sen teeskenteleminen, että kaikki olisivat aina halunneet samaa asiaa.
Demo vastauksena
Kysymys siitä, miten ihmiset voisivat kokeilla työkalua, oli jäänyt ratkaisematta siitä lähtien, kun ansioluettelon lataus otettiin käyttöön. Testaaminen oikeilla käyttäjillä on arvokasta, mutta se aiheuttaa omat ongelmansa. Työkalun on toimittava johdonmukaisesti, käyttäjillä on oltava riittävästi taustatietoa ymmärtääkseen, mitä he ovat tekemässä, ja huonosta ensikokemuksesta on vaikea toipua.
Turnmeyer tarjosi yksinkertaisimman ratkaisun, jota ryhmä oli harkinnut.
Hän oli katsellut demotallenteita — lyhyitä, minuutin tai kahden mittaisia esittelyjä, joissa näytettiin, miten työkalu toimi ilman, että katsojan tarvitsi itse käyttää sitä. Hän ehdotti, että se saattaisi riittää. Ihmiset voisivat nähdä työkalun toiminnassa, ymmärtää, mitä se teki ja miksi, ja lähteä tuntien, että se oli mahdollista.
Heidän ei tarvitsisi kirjautua sisään, toimittaa organisaatiokaaviota tai jäädä jumiin, kun jokin arviointikysymys ei vastannut heidän tilannettaan.
Monista kirjoittamistani blogeista saamani palaute on, etteivät ihmiset oikeastaan halua kopioida täsmälleen samaa asiaa. He haluavat vain tietää, että he pystyvät tekemään sen.
Erin Turnmeyer · VP, henkilöstötoiminnot
Tuo havainto kertoo jostakin todellisesta siinä, miten HR-ammattilaiset suhtautuvat tekoälytyökaluihin juuri nyt. Monien heistä navigoima kuilu ei ole kuilu sen välillä, tietävätkö he jonkin olevan olemassa ja käyttävätkö he sitä. Se on kuilu sen välillä, uskovatko he ylipäätään pystyvänsä tekemään jotain tällaista.
Demo, jossa ammattilaiset rakentavat oman työkalunsa, vastaa eri kysymykseen kuin valmis tuote — ei kysymykseen ”onko tämä työkalu hyvä?” vaan kysymykseen ”olisiko joku minun kaltaiseni voinut tehdä sen?”
Ajatus otettiin hyvin vastaan. Se vastasi testaamiseen liittyviin huolenaiheisiin, vähensi tuotantovalmiiksi saattamattoman asian jakamisen monimutkaisuutta ja piti painopisteen siellä, missä ryhmä oli aina tarkoittanutkin sen olevan: prosessissa ja ajattelussa, ei vain lopputuloksessa.
Mitä kokeilu opetti: opas HR-työkalujen rakentajille
- Aloita ongelmasta, älä teknologiasta. Ryhmän varhainen innostus tunneanalyysiin oli aitoa, ja se johdatti heidät pois helpommin ratkaistavasta ja arvokkaammasta ongelmasta. Siirtyminen osaamiskartoitukseen onnistui, koska se alkoi todellisesta käyttötapauksesta, jota oli jo testattu käytännössä.
- Räätälöity päihittää yleisen. Jokainen osallistuja oli törmännyt yritysten HR-alustojen rajoituksiin. Tiettyihin tilanteisiin rakennetut työkalut — Turnmeyerin etuussuositin ja Satterfieldin lämpökartta — suoriutuivat valmiita vaihtoehtoja paremmin. Perustelu oman työkalun rakentamiselle on vahvempi kuin koskaan, ja esteet ovat matalampia.
- Ristiintarkistus ratkaisee kaiken. Itsearvioinnit ovat vain niin hyviä kuin ihmisten itsetuntemus, joka on tunnetusti epäluotettavaa. Työkalun todellinen arvo piilee sen kyvyssä selvittää, haastaa ja hienovaraisesti kalibroida uudelleen — ei vain kirjata, mitä ihmiset uskovat itsestään.
- Vähimmäisarvokas, ei vähimmäistoimiva. Jos ensimmäinen versio ei tarjoa jotakin, joka saa käyttäjän haluamaan palata, tiekartalla ei ole merkitystä. Suunnittele ensivaikutelmaa, älä viidettä käyttökertaa varten.
- Sitoutuminen on rakenteellinen, ei pehmeä asia. Kysymys siitä, tuottaako tekoäly lopullisen arvosanan vai vahvistaako käyttäjä sen, ei ole käyttöliittymän yksityiskohta. Se määrittää, onko työkalu auktoriteetti vai yhteistyökumppani, ja tämä ero muovaa kaikkea siinä, miten työkalu otetaan vastaan ja miten sitä käytetään.
- Karsi jo rakentamasi ominaisuudet. Uponneiden kustannusten logiikka saa tiimit lisäämään asioita, joihin ne ovat investoineet, vielä kauan sen jälkeen, kun kyseiset asiat ovat lakanneet ansaitsemasta paikkaansa. Jos et pysty ilmaisemaan, mitä jokin ominaisuus varten on, siinä on vastauksesi. Sen karsiminen on tuotekehityksen kurinalaisuutta, ei epäonnistumista.
- Testaa vastakkainasettelua hyödyntäen ja varhain. Etsi ihmisiä, jotka kertovat sinulle työkalun olevan huono. Anna sille pahin järkevästi kuviteltavissa oleva syöte ja katso, mitä se tekee. Rakenna poikkeustapaukset mukaan ennen tyypillisten tilanteiden hiomista. Työkalun uskottavuus riippuu siitä, miten se käsittelee hetkiä, joita varten sitä ei suunniteltu.
- Työkalun on ansaittava oikeus arvioida. Arvosanaan hyppääminen ennen riittävien kysymysten esittämistä on oletusarvoisuutta, ei tehokkuutta. Tarkentavat kysymykset tekevät arviosta perusteltavan, ja perusteltavuus saa palautteen menemään perille.
- Ole rehellinen siitä, mitä varten kaikki ovat mukana. Ryhmän sisäiset toisistaan poikkeavat tavoitteet eivät ole hallittava ongelma — ne ovat tietoa. Niiden tuominen esiin varhain säästää kaikki rakentamasta kohti tavoitetta, jonka jakavat todellisuudessa vain jotkut heistä.
- Vaikeimmat keskustelut ovat tärkeimpiä. Ryhmä rakensi työkalun HR-taitojen arviointiin ja kävi samalla yhden rehellisimmistä keskusteluista HR:n rajoituksista, jonka kukaan heistä saattoi muistaa. Tuo keskustelu — taaksepäin katsovista viitekehyksistä ja koeosaamisen sekä tilannekohtaisen harkinnan välisestä kuilusta — oli yhtä lailla tuote kuin työkalukin.
Neljästä puhelusta alkaneeksi sitoumukseksi tarkoitetut tapaamiset venyivät talveen ja siitä uuteen vuoteen. Prototyyppi kehittyi edelleen. Sen rakentaneiden ihmisten tavoitteet olivat selkiytyneet tavoilla, jotka eivät ratkenneet siististi.
Satterfield rakensi edelleen. Turnmeyer oli ottanut oppimansa ja soveltanut sitä muualla. Gillies oli kannustanut ryhmää olemaan kurinalaisempi sen suhteen, mitä työkalun oli oikeastaan tarkoitus tehdä. Minä kirjoitin kertomusta kaikesta siitä.
Turnmeyer oli sanonut prosessin alkuvaiheessa jotain, mikä piti edelleen paikkansa: hän rakensi, koska häntä ei ollut pyydetty tekemään niin, vaan koska hänen täytyi ymmärtää.
Ymmärrys siitä, mitä AI-työkalut oikeastaan tekevät, missä ne erehtyvät ja mitä niiden hyödyllisiksi tekeminen vaatii, ei ollut saatavilla missään konferenssiesityksessä tai toimittajan esittelyssä. Se syntyi ryhmän tekemistä päätöksistä, heidän karsimistaan ominaisuuksista ja hetkistä, jolloin työkalu arvioi jonkun väärin ja heidän täytyi selvittää, miksi näin kävi.
Hyödyllisimmät asiat, joita ryhmä tuotti, eivät olleet prototyypissä. Ne olivat sen taustalla olleessa päättelyssä.
