Å spore tilbake på KI: Virkelige historier fra ledere
Lærdommer om KI: Mange ledere overser de verdifulle lærdommene fra mislykkede eller satte KI-prosjekter på pause, noe som fremhever viktige innsikter.
Sett på pause fremfor å presse fremover: Virksomheter har ofte nytte av å sette KI-initiativer på pause for å etablere grunnleggende prosesser og datakvalitet.
Manuelt først: Automatisering bør først komme etter manuell gjennomføring, slik at prosessene er tydelig definert og forstått.
Mål effekten: Nøkkelen til suksess er å vurdere dagens prosesser og KIs potensielle effekt før implementeringen starter.
Betydningen av dokumentasjon: Effektiv dokumentasjon bør ikke bare beskrive prosesser, men også fange opp begrunnelsen bak beslutninger og unntak.
De fleste historiene om AI-adopsjon blir fortalt fra seierspallen. Langt færre ledere snakker om øyeblikket da de trakk i nødbremsen – automatiseringen som ble avlyst, utrullingen som ble satt på pause, piloten som måtte bygges opp fra grunnen av. Men det er ofte i disse historiene de virkelige lærdommene finnes.
Vi spurte tre eksperter som har vært gjennom dette: Hva ble gjort om, hvorfor, og hva ville du gjort annerledes? Svarene deres samler seg rundt et overraskende konsistent tema – problemet er nesten aldri selve AI-en.
Når det smarte valget er å ta en pause, ikke å presse fremover
For de fleste organisasjoner er det ikke realistisk å fjerne en AI-investering fullstendig når pengene først er brukt. Tejinder, seniorleder i Deloitte Consulting, sier rett ut at det ikke var aktuelt å fjerne løsningen helt, gitt investeringene som allerede var gjort – men en bevisst pause var mulig. Da resultatene ikke holdt mål, tok teamet hans et skritt tilbake og «så på det grunnleggende først». De spurte om de underliggende prosessene var etablert, om «datakvaliteten» var «god», og om planleggerne forsto hvilken rolle agenter hadde, sammenlignet med deres egen. «Jeg tror at reaktivering ga mening så snart disse spørsmålene var besvart», sier han.
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
Priyanka Dave, ph.d., leder for kompetanseheving og ansvarlig for læringsprosesser ved Oregon State University, har sett det samme mønsteret gjenta seg flere ganger. «Jeg har observert flere organisasjoner som bevisst har utsatt utvidelsen av AI-initiativer etter å ha innsett at de ikke var operasjonelt klare.» I disse tilfellene var tilbaketrekningen ikke en fiasko – det var en omdirigering. «I stedet for å utvide AI umiddelbart flyttet ledelsen oppmerksomheten mot å styrke organisasjonens grunnlag», forklarer Dave. Dette innebar at «organisasjonene investerte i å dokumentere forretningsprosesser, standardisere arbeidsflyter, forbedre datastyringen og bygge de ansattes kompetanse gjennom strukturert læring og endringsledelse».
I stedet for å utvide AI umiddelbart flyttet ledelsen oppmerksomheten mot å styrke organisasjonens grunnlag.
Ikke automatiser noe du ikke har gjort manuelt
Noen ganger innebærer det å gå tilbake å avlyse et prosjekt fullstendig – og oppdage at det var riktig beslutning hele tiden. Jaime Gil Martinez, grunnlegger og hovedkonsulent i Swift Ops Solutions, lærte dette på den harde måten. «Jeg bygde en gang en automatisering for å produsere markedsføringsmateriell for en kunde som aldri hadde gjennomført prosessen manuelt», forteller han. «Fordi det var nytt for dem, tenkte vi begge at det var bedre å bygge det automatisert fra grunnen av. På papiret ga det mening. I ettertid var det en nybegynnerfeil.»
Systemet fungerte teknisk sett. «Automatiseringen fungerte», sier Gil Martinez. «Problemet var at hver gang det var behov for et resultat, måtte noe vurderes på nytt eller justeres (et annet mål, et annet format, en annen layout), så jeg fortsatte å bygge det om. Etter noen runder med dette var mønsteret tydelig – jeg automatiserte en prosess som ingen ennå hadde definert.»
Etter noen runder [med justeringer] var det tydelig at jeg automatiserte en prosess som ingen ennå hadde definert.
Løsningen var å gå tilbake. «Så vi avlyste prosjektet fullstendig og gikk tilbake til å produsere materialet for hånd», sier han. «Det viste seg å være hele poenget: Hver manuelle runde ga oss det vi hadde manglet, nemlig referanseeksempler og et tydelig bilde av hva som varierte, og hva som ikke gjorde det. Senere tok vi opp automatiseringen igjen, og det manuelle resultatet ble kunnskapsbasen vi ga til AI.» Erfaringen førte til en regel han nå bruker i hele sitt eget selskap og hos kundene sine: «Ikke automatiser noe før du har gjort det manuelt minst tre ganger. Deretter kan du begynne å vurdere det.»
Steget alle hopper over: Mål før du bygger
Spør Gil Martinez hva de fleste planer for AI-implementering mangler, og svaret hans kommer umiddelbart: «Å måle før du bygger. De fleste selskaper mangler to tall når de starter: hvor god eller dårlig den nåværende prosessen faktisk er, og hvilken innvirkning AI realistisk sett kan ha på den. Uten begge deler kan du ikke vite hvor effektiv implementeringen var, eller om kostnaden var berettiget.»
Han viser til en helseklinikk som ønsket å automatisere timeplanlegging for mer enn 100 pasienter. «De visste ikke hvor lang tid det tok, bare at det var tidkrevende og frustrerende», sier han. «Og hvis du ikke vet hvor lang tid det tar, vet du heller ikke hvor mye det koster.» Før han bygde noe, var det første steget derfor å beregne hvor mange timer timeplanleggingen tok, og den økonomiske verdien av disse timene. «Det ga oss utgangspunktet: to ukers fullstendig manuelt arbeid. Automatiseringen reduserte det til én dags AI-assistert arbeid, til en kostnad som var lavere enn deres nåværende tilsvarende utgifter.» Med disse tallene på plass «ga beslutningen seg selv».
Dave ser en annen, men like kritisk, mangel: Beredskap handler ikke bare om teknologien. «Steget jeg oftest ser organisasjoner overse, er å vurdere arbeidsstyrkens kapasitet før de implementerer AI», sier hun. Og manglene viser seg sjelden å handle om opplæring i verktøy. På tvers av flere kapasitetsvurderinger «viste vurderingene konsekvent at de største kapasitetsmanglene gjaldt analytisk tenkning, kritisk tenkning, datakompetanse, rådgivende kommunikasjon og problemløsning». Hennes konklusjon er: «Teknologisk beredskap og beredskap i arbeidsstyrken er ulike utfordringer. Bærekraftig AI-implementering krever begge deler.»
Når AI legges på en prosess som ikke er klar
Hva er det egentlig som bryter sammen når AI legges oppå en umoden prosess? Tejinder så det på nært hold da «AI ble integrert i en forretningsprosess (ordrebehandling og fordeling) som ikke var moden nok» — resultatet var en løsning full av feil. Men han er tydelig på hvor feilen lå: «Jeg mener at AI ikke var problemet her», sier han, og peker i stedet på prosessmodenhet, problemer med grunndata, uavklarte krav og utilstrekkelig testing.
AI ble integrert i en forretningsprosess (ordrebehandling og fordeling) som ikke var moden nok.
Dave beskriver den samme dynamikken ut fra vurderingene sine: ulike avdelinger utfører det samme arbeidet på forskjellige måter, dokumentasjonen er ufullstendig, og unntak finnes bare i hodet til de ansatte. «Bekymringen var at AI ganske enkelt skulle gjenskape uensartet praksis på tvers av organisasjonen», sier hun. Det er en konsekvens av et prinsipp hun ofte vender tilbake til: «AI løser ikke organisatoriske problemer. Det forsterker eksisterende systemer. Hvis prosessene er uensartede eller dårlig dokumentert, vil AI ofte skalere disse uoverensstemmelsene i stedet for å forbedre dem.» Lærdommen er, med hennes ord: «Den tilbakevendende lærdommen var at organisasjoner bør forbedre prosessene før de forsøker å automatisere dem.»
Hvis prosessene er uensartede eller dårlig dokumentert, vil AI ofte skalere disse uoverensstemmelsene i stedet for å forbedre dem.
Gil Martinez har sine egne arr etter dette — en applikasjon for generering av potensielle kunder som «mislyktes dramatisk første gang». Byggingen gikk fra halvmanuell til fullstendig automatisert uten definerte krav eller tester. «Feilen min var å anta at AI ville finne ut av noe av logikken på egen hånd, fordi logikken virket åpenbar og enkel», innrømmer han. Derfra eskalerte problemene. «Koden ble uhåndterlig og fullstendig eid av AI-en, til det punktet der jeg ikke kunne gå tilbake til en trygg milepæl. Det var da jeg skjønte at den var strukturelt ødelagt, ikke bare full av feil.»
Gjenopprettingen krevde en fullstendig omstart. «Løsningen var like smertefull som den var åpenbar: begynn på nytt», sier han. «Denne gangen beskrev jeg hvert eneste krav og en test for hvert av dem, bygde trinnvis og ga AI-en tydelige instruksjoner for å loggføre feil og suksesser sammen med ordentlig versjonskontroll.» Det disiplinerte andre forsøket «tok omtrent halvparten av tiden jeg hadde sløst bort på det første forsøket, før jeg nådde en fungerende løsning av produksjonskvalitet.»
Slik ser god dokumentasjon for AI faktisk ut
Under alle de tre historiene ligger den samme løsningen: dokumentasjon som beskriver hvordan arbeidet faktisk utføres. For Dave betyr det å gå lenger enn oppgavelister. «God prosessdokumentasjon forklarer ikke bare hva folk gjør, men også hvorfor de tar bestemte beslutninger», sier hun. Og det mest verdifulle materialet er som regel det som aldri blir skrevet ned. «En av de vanligste feilene organisasjoner gjør, er å dokumentere bare standardarbeidsflyten. Den største organisasjonskunnskapen finnes ofte i unntakene, skjønnsvurderingene og kontekstuelle beslutningene som erfarne ansatte tar.»
Gil Martinez rammer det inn gjennom en linse PM-er i stadig større grad vil kjenne igjen: «God prosessdokumentasjon speiler instruksjonsutforming. De samme elementene vi har lært å gi AI i en instruksjon (rolle, kontekst, oppgave, instruksjoner, begrensninger), bør også være synlige på prosjektnivå.» Denne endringen får konsekvenser for hvordan fagfolk bruker tiden sin. «Menneskers gjennomføringstid forsvinner og overlates til AI, så fokuset vårt må flyttes til god planlegging og validering av resultater. Vi må opptre som AI-ledere.»
Konklusjon: Rekkefølgen er strategien
Ingen av disse lederne angrer på at de investerte i AI. Det de angrer på – eller har sett andre angre på – er rekkefølgen på operasjonene. Tejinder oppsummerer det slik: «Innføring av AI i virksomheter mislykkes når modellen tas i bruk før det grunnleggende driftsgrunnlaget er på plass. Den riktige rekkefølgen er først prosessmodenhet, datakvalitet og tydelige roller. Deretter AI. Når organisasjoner snur denne rekkefølgen, skylder de på AI, men det underliggende problemet er nesten alltid miljøet AI-en ble satt inn i.» Det viser seg at det å måtte gå tilbake ikke er selve fiaskoen. Det er å ta AI i bruk før man er klar.
Vil du ha flere innsikter som disse? Registrer deg for en gratis DPM-konto for å høre fra flere eksperter som disse.
