Sådan får du dit team ud af helvede med procesdokumentation ved hjælp af AI og automatisering

Læs transskriptionen:

Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Galen Low: Velkommen til vores paneldiskussion om at få dit team ud af helvede med procesdokumentation ved hjælp af automatisering, AI og anden teknologi. Vi afholder arrangementer som dette en gang om måneden, så vores medlemmer og VIP-gæster kan komme i direkte kontakt med de eksperter, der bidrager til og samarbejder med os her hos The Digital Project Manager.

For dem af jer, der ikke kender mig, hedder jeg Galen Low. Jeg er medstifter af The Digital Project Manager og jeres vært i dag. Jeg har også et fantastisk trekløver af eksperter i bureauers drift med mig — Alyson Caffrey, Gray Mackenzie og Brian Kessman. Lad os komme i gang.

I dag undersøger vi de praktiske realiteter ved, om AI, automatisering og andre teknologiske værktøjer kan hjælpe med at fjerne smerten ved at dokumentere og styrke jeres processer, så jeres teams endelig kan fungere konsekvent, forudsigeligt og effektivt — alle de gode biord. Jeg vil sige, at de fleste teams i bureauer og også i andre organisationer faktisk er ret dårlige til at standardisere projekt- og driftsprocesser og til at skrive dem ned.

Måske er det, fordi de ser hvert projekt eller hver person, der udfører arbejdet, som forskellig — som en slags unik snefnug. Måske er det, fordi de ønsker at fremme en kultur, hvor man bygger flyet, mens man flyver det. Eller måske har de bare en intern allergi over for standardisering. Ofte er intentionerne gode, og blokeringen er typisk tiden. For bureauer er det ikke-fakturerbar tid, der efterlader penge på bordet.

For små virksomheder er det en alternativomkostning. For ethvert team er det besværligt, kedeligt og gentagende. Der er som regel et eller andet, ikke? Ofte er der en wiki, men måske er den ikke opdateret, eller også ligger der en bunke skærmoptagelser, som venter på at blive transskriberet, finpudset eller omdannet til et komplet dokument.

Og nogle gange er processen helt ærligt bare en mundtlig tradition, der gives videre fra person til person uden nogen skriftlig dokumentation overhovedet. Men problemet er, at uden god procesdokumentation vil jeres team fare vild, jeres interessenter blive forvirrede, og jeres organisation vil ikke kunne skalere mod sine mål.

Så det spørgsmål, jeg gerne ville diskutere og udforske i dag — ikke som en lektion, men som en samtale — er: Hvorfor findes der ikke en bedre måde i denne tidsalder med AI-drevet teknologi og al denne procesautomatisering til at gøre procesdokumentation og anvendelse mere smidig og nærmest automatisk? Er vi ikke nået dertil endnu? Jeg formoder, at svaret er både ja og nej, men jeg tænkte, at vi kunne dykke ned i det.

Lad os begynde med det store spørgsmål: Hvorfor er det så smertefuldt at skabe procesdokumentation og standardiserede arbejdsprocedurer i bureauer og andre organisationer? Aly, vil du lægge ud? Du arbejder med mange mennesker, der har problemer med deres processer.

Alyson Caffrey: Ja, vi laver meget dokumentationsarbejde hos Operations Agency. Og jeg tror, at det, folk har svært ved at forstå, er, at det ikke er et projekt, man gør én gang og så er færdig med, vel? Vi kan ikke bare tage hele projektet én gang og derefter lade være med at tænke på, at det skal opdateres, finjusteres eller udbygges over tid. Derfor er der normalt en proces i tre faser, som jeg bruger til at vurdere, om en proces er god eller ej.

Først skal vi forstå, at vi kan befinde os i disse tre faser. Og først når vi forstår, hvor vi er, kan vi effektivt skabe dokumentation eller arbejde på at komme over i den næste kategori. Cyklussen begynder med, at man tester noget. Lad os sige, at en af de vigtigste processer i enhver virksomhed er: Hvordan skaber vi kundeemner? Lad os bruge det som eksempel. Det første, vi vil gøre, er at spørge: Er vi i testfasen? Kaster vi spaghetti mod væggen for at finde ud af, hvad der giver os de bedste kundeemner og de mest kvalificerede potentielle kunder?

Den anden fase er justeringsfasen. Måske har vi fundet en ret god metode, men vi skal arbejde med teksten eller med den platform, vi lægger den på. Befinder vi os i justeringsfasen? Den tredje fase er at gøre processen operationel og derefter forstærke den. Man kan altså gøre den operationel og derefter skalere den.

Jeg tror, at mange mennesker tror, de er i den operationelle fase, og så går de i gang med dokumentationen. Derefter opdager de: Faktisk er jeg i testfasen. Derfor tænkte jeg, da jeg så nogen nævne holdbarhed i chatten: Ja, holdbarheden kommer til at lide, hvis du er i testfasen, fordi du hele tiden skal opdatere bedste praksis og de måder, du finder frem til at gøre tingene på.

Så før man sætter sig ned for at tage fat på et dokumentationsprojekt, skal man se på virksomhedens fire hovedprocesser. Hvordan skaffer vi kundeemner? Hvordan konverterer vi dem? Hvordan leverer vi det, vi har lovet kunderne, og opretholder løfterne? Og hvordan forbedrer vi os? Det er de fire store ting.

Vi behøver ikke gøre det mere kompliceret. Derefter spørger vi os selv: Tester vi vores metode til at skaffe kundeemner? Tester vi konverteringsmekanismer? Hvis svaret er ja, skal vi måske arbejde lidt mere, før vi skriver tingene ned.

Galen Low: Det elsker jeg. Og jeg ser det ske så ofte, og jeg er også selv skyldig i det.

Jeg tænker: Vi tester den her ting. Jeg må hellere skrive den ned, så vi kan — jeg ved ikke — teste hårdere. Og så vender jeg tilbage seks måneder senere og tænker: Dette dokument nåede jeg ikke engang at skrive en hel sætning i. Det var en god intention, men ikke det rigtige tidspunkt. Jeg kan godt lide, at du har opdelt det i forskellige dele af virksomheden — ikke nødvendigvis for at forsimple det, men for at mindske overvældelsen ved tanken om: Lad os dokumentere alt, hvad vi gør i virksomheden i dag.

Alyson Caffrey: Ja. Hvis du vil dokumentere stuetemperaturen under et salgsmøde, er det for meget dokumentation. Vi må skrue lidt ned. Så lad svaret opmuntre dig: Vurder først, hvor du er, og find ud af, om dokumentation faktisk bare er en urealistisk drøm, eller om du reelt kan gennemføre det. Og gå selvfølgelig ikke for langt i nogen retning.

Hvis vi er nye inden for dokumentation af processer, skal vi kunne holde os slanke og fleksible med den ressource.

Galen Low: Brian, har du noget at tilføje? Jeg ved, at du arbejder med driftsmodeller og strategi, specifikt for bureauer. Hvor kommer procesdokumentation ind, og hvordan forklarer du dine kunder, at det er vigtigt på bestemte tidspunkter, selv om det bliver besværligt — eller måske hvordan det ikke behøver at blive besværligt?

Brian Kessman: Når en kunde kontakter mig, og vi begynder at tale om processer, må jeg føre dem tilbage til strategien for hele organisationen, fordi det i sidste ende er processerne, der får strategien til at blive til virkelighed.

Der er nogle få ting, der skal være på plads, for at det overhovedet kan lade sig gøre. Hvis et bureaus forretningsstrategi er, at vi er et firma for alle slags kunder, og vi udfører alle slags arbejde, vil der aldrig være en standardiseret proces i den slags miljø.

Jeg har set det alt for mange gange. Der sker en masse genopfindelse af ydelser. Hvert projekt er anderledes, og man opfinder den dybe tallerken igen og igen. Så hvordan kan man overhovedet have en proces for det?

Selv hvis man forsøger, ændrer den sig. Og det skaber frustration, udbrændthed og alt det, du kender. Men der er også andre faktorer i spil, blandt andet bureauets forretningsmodel generelt. Den arbejder faktisk imod bureauets egen succes. Hvis bureauet stadig bruger en arbejdsbaseret forretningsmodel og sælger fakturerbare timer, vil virksomhedens kultur og prioriteter blive påvirket af faktureringsgraden.

Det kommer altid til at handle om at få arbejdet gjort, ikke om interne processer, og om at betjene kundernes behov først og fremmest. Der er også et andet element, jeg vil nævne, nemlig teamstrukturen. Den skaber også kompleksitet. Den traditionelle teamstruktur, som jeg ser hele tiden, fremmer virkelig den forkerte tankegang og adfærd.

Eksemplet er, at når nyt arbejde kommer ind, som i de fleste traditionelle firmaer, bliver folk tildelt projekter fra forskellige fagområder. Vi vælger dem, der er tilgængelige eller passer til opgaven — Hollywood-modellen, hvor man caster det rigtige talent til jobbet. Men hvert projekt, et teammedlem arbejder på, har sit eget sæt møder.

Møderne begynder derfor at formere sig, og kommunikationsarbejdet vokser. I stedet for en dedikeret teamstruktur eller pod-modellen, som andre måske kender den, hvor teamet bliver sammen fra projekt til projekt, opbygger man en fælles fornemmelse af teamet, og gruppen fokuserer på at arbejde bedre sammen.

I den situation vil der ikke være den samme modstand mod processer, som der vil være i et midlertidigt projektteam. Der er større ejerskab og interesse. Man arbejder sammen med det samme team over tid. Så hvordan finder vi ud af, hvordan vi arbejder bedre sammen? Alle er investerede i det.

Det er nogle af de vigtigste elementer, og det er den linse, jeg ser spørgsmålet igennem.

Galen Low: Det elsker jeg, fordi jeg har arbejdet i bureauer og andre organisationer af mange forskellige størrelser. En af de sværeste ting er at rulle en proces ud i hele organisationen.

Det ville man være nødt til, hvis man havde disse midlertidige teams, som hele tiden ændrer sig: Hvordan gør vi alle tingene på samme måde? Svaret er, at det gør ingen nogensinde i den konfiguration. Men hvis det er en teamproces, er det faktisk alles opgave at eje processen, levere processen og dokumentere processen.

Det er ikke noget, man skal evangelisere for og overbevise resten af organisationen om. Det er mere lokalt og derfor mindre smertefuldt at definere, tror jeg.

Brian Kessman: Ja. Jeg tror stadig, der er et grundlæggende strukturlag for firmaerne. Alle skal for eksempel bruge det samme projektstyringssystem, så vi kan arbejde på tværs af grupper og teams. Men der er også kultur og processer på teamniveau. Hvordan skaber vi det?

Galen Low: Det kan jeg godt lide.

Jeg forestiller mig, at alle tre af jer møder kunder og mennesker i jeres netværk, som bare vil kæmpe imod. De vil med næb og kløer kæmpe imod at investere i deres procesøkosystem.

Hvordan forklarer I værdien af denne investering af tid til en skeptiker? Jeg ved, at det kommer op i mine samtaler med jer, når I arbejder med kunder, der siger: Vi behøver ikke gøre det her. Gray, det virker som spild. Kan vi ikke bare sætte maskinen til, tænde den og begynde at tjene flere penge?

Hvordan forklarer I værdien af sådan et projekt?

Gray Mackenzie: Grunden til, at det føles som helvede, eller at vi ikke kan finde tid til det, er i mange tilfælde, at vi ikke får værdi ud af det. Næsten ingen ejere siger: De her salgsmøder tager så lang tid. Jeg kan simpelthen ikke finde tid til salgsmøder.

Nej, for vi har set den værdi, der kommer ud af et salgsmøde. Men de fleste har ikke oplevet den værdi, der kommer fra virkelig gode processer, hvor man faktisk kan overdrage opgaver. Aly, et spørgsmål, jeg gerne vil vende tilbage til, er: Hvad er tærsklen? Hvordan ved vi, hvornår vi er i den operationelle eller forstærkende fase? Hvilke pejlemærker gælder?

Vi har nogle tanker om, hvordan vi identificerer, om noget kan skaleres. Men det er grunden til, at det er svært for folk at se værdien eller skabe tid til det: De har ikke oplevet fordelen ved at have processer, der er nemme at sætte i drift, så teamet hurtigt kan uddelegere og spare tid.

Hvis det gøres godt, får man værdi på to forskellige områder. Det første er effektiviteten. Vi kan enten gøre ting hurtigere, eller vi gør måske tingene langsommere, men med en mere omkostningseffektiv arbejdsmodel. Det er den ene side. Den anden side er resultatet: Hvad er effekten af det, vi gør? Ikke effektiviteten, men hvor virkningsfuldt det er.

Det handler om: Kan du huske de sidste tre gange, vi gjorde det her, hvor vi ødelagde det to gange, og en kunde forlod os på grund af det? Det er den smerte, vi forsøger at undgå.

Når man skal forklare værdien, vil det som minimum være på en af de to områder, som regel begge. Men alle mærker en forskellig del af det. Derfor forsøger jeg at bore ned i samtalen med folk og finde ud af: Hvilken del gør mest ondt, så vi kan motivere dig?

Du har en proces uanset hvad. Der findes allerede en proces; den er bare ikke dokumenteret. Alle har deres egen måde at gøre det på, men der er en proces for, hvordan tingene sker. Uanset hvad kommer du til at investere. Enten betaler du konsekvenserne af ikke at have gjort det fra starten, eller også betaler du for noget indledende arbejde, der gør tingene lettere i fremtiden.

Du kan selv vælge, hvor smerten og betalingen skal ligge, men du kommer til at betale uanset hvad. Det handler ikke nødvendigvis om, hvorvidt du skal arbejde med ZenPilot eller ej. Vi er blevet enige om, at en proces giver mening for dig, og så beslutter du, hvilken del der motiverer dig.

Jeg forsøger at hjælpe folk med at blive motiverede til at tage skridtet mod at investere i de områder, hvor vi bør investere.

Galen Low: Jeg vidste, at du ville gå til spørgsmålet om, at folk ikke ser fordelene direkte ved god procesdesign og dokumentation. Men jeg havde ikke tænkt på den anden ting: De fleste af os har endnu ikke set, hvordan noget virkelig godt ser ud. Smerten, vi har, er dog virkelig.

Smerten er virkelig, og vi kan nå frem til noget godt, der løser den. Jeg kan godt lide den målingsvinkel. Vi har alle historier om kunden, der forlod os, men måler vi fordelen ved nogle af de procesforbedringer, vi laver?

Jeg kan godt lide, at du sendte den videre til Aly, og jeg vil faktisk gerne gå videre til det, før vi dykker ned i det praktiske. Tærskelspørgsmålet er interessant: Hvornår ved man, at man er gået fra test til næste fase og fra den fase til operationalisering? Hvornår ved man, at tidspunktet er rigtigt til at begynde at skrive tingene ned?

Alyson Caffrey: Jeg synes, det er et fremragende spørgsmål, Gray. Helt ærligt bliver jeg spurgt om det ofte, og jeg vil først fortælle en historie og derefter blive lidt mere konkret.

Da jeg gik i gymnasiet, førte jeg statistik for basketball. Det lærte mig meget, fordi jeg aldrig selv var basketballspiller. Jeg er kun omkring 157 cm høj og var aldrig en god basketballspiller. Jeg ville altid gerne være det, og jeg elsker at se basketball og være involveret i sporten. Vi førte statistikkerne, og jeg så, at trænerne tog statistikkerne og justerede den måde, de ville træne på næste dag.

Det er en vigtig analogi at tage med til vores bureau. Hvis vi bevæger os fra test til at ændre og justere en proces, skal vi først måle effekten af nogle af de ting, ikke? Det kan være, at vi reducerer prisen pr. kundeemne, øger kundens livstidsværdi eller øger bruttoavancen på projekter.

Det er tre meget vigtige elementer. Hvis jeg tester noget og ændrer nogle ting, kan jeg holde de tre store tal for øje — eller de tal, som jeg håber, at implementeringen af processerne faktisk påvirker. Så kan jeg begynde at sige: Nu hvor jeg ved, at denne projektstruktur eller denne måde at håndtere kvalitetssikring eller rettelser på hjælper os med at fastholde kunder længere eller skabe højere bruttoavance på vores projekter, er det tid til at skrive det ned, fordi jeg har skabt en tilstrækkelig forbindelse mellem målingerne af forretningsforbedringerne.

Den anden ting er, at jeg tror, Kobe Bryant sagde: Bliv aldrig træt af det grundlæggende. Man er nødt til at lave gentagelserne. Mange af os tror, at vi ændrer en proces eller implementerer noget, og hvis det ikke virker med det samme, opgiver vi. Vi giver os faktisk ikke en lang nok periode til at se, om det forbedrer bureauet over tid.

Det klassiske syndrom med den skinnende nye genstand: Græsset ser altid grønnere ud på den anden side. Jeg opfordrer derfor altid bureauledere til at forbinde procesforbedring med et konkret forretningsmål, som de kan se forbedre virksomheden. For det andet skal man give sig selv tilstrækkelig tid til at sikre, at det virker.

Jeg plejer at bruge 90 dage. Det er elegant, fordi det er et kvartal. Man måler normalt ting i virksomheden med den frekvens alligevel. Så jeg er stor tilhænger af at give det 90 dage og se, hvordan det fungerer.

Galen Low: Jeg kan godt lide hele tanken om, at vi alle har processer, fordi vi alle gør noget, men at vi måske ikke skal gøre processen permanent, før vi ved, at den virker.

For at vide, om den virker, skal vi give den tilstrækkelig tid og være bevidste om, hvad vi måler, før vi smider den væk eller begynder at bruge tre dage om ugen på at skrive processen ned uden at vide, om den fungerer.

Jeg spekulerer på, om vi kan dykke ned i nogle tips og bedste praksis. Hvilke værktøjer og hvilken teknologi bruger I med jeres kunder for at fjerne smerten, når I når til det punkt, hvor procesdokumentationen skal skabes?

Og virker disse værktøjer for dem? Er der situationer, hvor de faktisk ender med at holde dem tilbage, så I siger: Nej, det her bør vi nok ikke bruge? Aly, jeg tænkte, at jeg ville begynde med dig, fordi jeg så webinaret, du deltog i sammen med Marcel i sidste uge. Du sagde noget, der sprang i øjnene: Optag din skærm.

Jeg husker, at du sagde det til mig for tre år siden. Jeg tænkte: Fint, jeg har forstået det. Og nu ændrer AI alt. Det handler ikke kun om at optage skærmen. Der er mere i det. Kan du fortælle lidt om, hvordan det fungerer for dine kunder, når de tager en skærmoptagelse og får den omdannet til en brugbar proces, som man kan slå op i?

Alyson Caffrey: Ja. Og Loom, hvis nogen derfra lytter, så sponsorer mig venligst. Jeg er stor fan af Loom. Loom udgav også for nylig en AI-funktion til at oprette dokumenter og den slags. Det er personligt mit foretrukne sted at begynde med procesdokumentation.

Jeg elsker det af to grunde, fordi det indrammer dokumentationsoplevelsen. Den første er, at hvis du ikke har processer og ikke har tid til at skabe dem, arbejder du sandsynligvis i selve virksomheden. Hvis du kan bruge den tid på at optage din skærm og vise en anden, hvordan du skaber disse resultater, kan vedkommende sandsynligvis bruge videoen, selv om processen ikke er perfekt.

Eller du kan få AI til at arbejde på et dokument for nogen, hvorefter de kan gentage det, selv om det ikke er perfekt eller enormt skalerbart, hvis vi stadig er i testfasen. Det er den første ende af processen. Den anden ende, som jeg synes er meget vigtig, er, at når du bruger AI til at skabe dine processer, bruger vi Scribe en hel del sammen med vores kunder.

Jeg bruger Loom og AI-funktionen, fordi det passer bedst til min arbejdsgang. Når du skriver alle dine processer, synes jeg, at AI er rigtig god til at organisere, kategorisere trin for trin og sørge for, at tingene ser pæne, læsevenlige og sammenhængende ud. Men den virkelige hemmelighed, især for bureauer, der ønsker at vokse hurtigt, er at holde kvaliteten under kontrol og i centrum.

Vi kan gennemgå en proces, men nogen kan gøre det halvhjertet. Vi skal vide, hvad Tony Robbins kalder definitionen på færdig: Hvad er det, vi skal stå tilbage med? Jeg synes, skærmoptagelser gør et fantastisk stykke arbejde med at vise: Sådan skal hjemmesidens wireframe se ud.

Hvis du har gennemført processen korrekt, kan en lang række eksempler fra det en-til-en-arbejde, du eller en kundeansvarlig eller lead builder i bureauet har udført, hjælpe med at samle flere eksempler på, hvordan kvaliteten skal se ud hos jer. Så jeg stemmer på Loom hele dagen.

Når du er i tvivl, så Loom det ud, er min holdning.

Galen Low: Skaber Loom nogensinde begrænsninger for folk? Jeg tænkte på den lammelse, der kan opstå: Vi dokumenterer ikke denne proces, før vi har en wireframe, der er god nok til at være kvalitetsstandard i Loom-videoen.

Og jeg forestiller mig også, at mange tænker: Lad være med at få mig på kamera. Jeg vil ikke optages. Jeg vil ikke dokumenteres. Lad mig bare skrive.

Alyson Caffrey: Nej, du behøver ikke blive optaget. Du behøver ikke tænde kameraet. Du kan bare vise din skærm og tale tingene igennem.

Det er vigtigt. Og hvis man zoomer 30.000 meter ud, er min holdning til drift ikke, at driften i en virksomhed eksisterer for at lægge bureaukrati over alt. Den viser os, hvordan vi kommer tilbage på sporet — hvordan vi reparerer det, vi ødelægger — så intet falder mellem to stole.

Den skaber et godt fundament. Vi bør ikke tro, at vi i et helt år eller tre år aldrig vil finde en bedre måde at gøre noget på. Det ville være absurd. Vi vil altid finde bedre måder at gøre ting på. Vores processer vil blive forbedret.

De vil ændre sig. Derfor vil jeg hellere udskifte en Loom-video med en bedre metode, jeg fandt en uge senere, end at gennemgå hele processen med at opdatere en standardiseret arbejdsprocedure, lægge den i vores vidensbase og rulle den ud til teamet.

Det er for de ting, vi allerede er nået til fase tre med — dem, vi ved, at vi vil forstærke, og som vi vil træne nogen i som bedste praksis. Jeg elsker Loom. Det er et fantastisk lille inkubationsværktøj til at dele ting, jeg arbejder på, som andre kan hjælpe mig med.

Galen Low: Det kan jeg godt lide.

Brian, er der andre værktøjer, teknikker eller teknologiske genveje, du har set dine kunder bruge, eller som du anbefaler, når det handler om at indfange den proces, de arbejder efter?

Brian Kessman: Lad mig give lidt kontekst om den rolle, jeg spiller i denne sammenhæng. Der er to måder, jeg vil hjælpe på. Den ene er først at etablere et AI-råd sammen med bureauet, så vi kan fastlægge teknologistrategi, politikker, kvalitetsforventninger, datasikkerhed og alt det andet og vælge de rigtige værktøjer.

Den anden er ikke nødvendigvis at dokumentere processen på deres vegne, men at skabe arbejdssessionerne, så vi kan få den viden fra teamene. På den måde får de ejerskab over processen. Derefter coacher jeg nogen i, hvordan de bygger den op. Der er et par værktøjer, vi kan bruge.

Men vi skal først finde ud af, om vi skriver dokumentation til mennesker eller til maskiner, der skal automatisere arbejdsgange. Det er to kategorier. Til mennesker skal den være let at anvende. Værktøjerne her er tilpassede GPT'er eller assistenter gennem OpenAI, og de er meget nemme at bruge til at udarbejde processer.

Tag det, du lærte i arbejdssessionerne eller i interviewene med teammedlemmerne, og lad den tilpassede GPT skrive dokumentationen, organisere indsigter, analyser og alt det andet som et udkast. Der findes også arbejdsflowplatforme som ClickUp, Monday.com og Notion, og alt har AI indbygget nu. Er det nok? Behøver vi virkelig introducere endnu et værktøj?

På videosiden er Loom fremragende. Jeg kender ikke Looms fulde funktionalitet, men jeg er stødt på et værktøj, der hedder Tango. Hvis du kender det, ved du, at du kan have skærmoptagelser, hvorefter det opretter kapitler og dokumentation for dig.

Du går bare igennem processen, og det tager sig af de fleste opgaver. Scribe er et andet værktøj, som nogen nævnte i chatten. Hvis du er produktchef, er ChatPRD et godt produkt til at skrive kravspecifikationer. Prøv det også til andre formål. Du vil blive overrasket over resultatet, og det kan være meget nyttigt.

Og så er der Jasper til markedsføringsbehov. Det var menneskesiden. Men der er også maskinsiden. De seneste nyheder fra OpenAI og andre i branchen siger, at OpenAI vil offentliggøre eller udgive sin første agentfunktionalitet ved årets udgang eller i begyndelsen af næste år.

Agenter kan altså følge arbejdsgange. Man kan automatisere arbejdsgange med sine agenter. Hvis det er rigtigt, er det fantastisk. Jeg er spændt på at se, hvordan det bliver, men der findes allerede andre værktøjer, som kan gøre det. Det handler om at få AI til at følge de specifikke trin i arbejdsgangen og derefter kombinere alle agenterne for at gennemføre den.

Copy.ai er fantastisk til markedsintroduktion, salg og markedsføring. Der er Make.com til generelle arbejdsgange, og Writer.com kan også automatisere arbejdsgange. Det er alle meget kraftfulde værktøjer. Sådan ser jeg på det: Det er virkelig de to kategorier.

Jeg kan blive ved.

Galen Low: Jeg havde ikke nødvendigvis samlet dem i mit hoved før — processen for mennesker og processen for maskiner. Når jeg tænker automatisering, tænker jeg, at vi dokumenterer trinene. Men jeg kan godt lide ideen om at angribe det på en anden måde for at skabe en oplevelse for den, der skal udføre opgaven, eller for det, der skal udføre opgaven.

Og ideen om agenter har virkelig oversvømmet mit feed på det seneste: Agenterne kommer, de tager jeres job og så videre. Men jeg elsker tanken om, hvordan vi kan gøre os klar til succes, så vi kan give det videre til en agent.

Brian Kessman: Det gode er, at det faktisk ikke er så anderledes.

Hvis du taler til eller skriver til AI'en, som du ville gøre til et menneske, når du fastsætter forventninger, giver input og viser eksempler på den kvalitet, du forventer, er det hele naturligt. Det handler bare om, hvordan du opdeler det i specifikke agenter. Det er den sværeste del.

Der er også en brugerflade, du skal lære at navigere i. Generelt er det ret nemt. Du kan sandsynligvis finde ud af det på en halv dag.

Galen Low: Har du nogle kriterier for, at dette skal være en menneskelig proces lige nu, mens dette bør automatiseres? Hvordan ser den samtale ud?

Brian Kessman: Jeg begynder med at tænke på, hvem der skal følge processen. Er den forudsigelig? Er det en forudsigelig proces? Vil der ikke være behov for vejledning eller spørgsmål? Kan inputtene defineres meget klart? Kan du fastsætte forventningerne til outputtet?

Har du eksempler, og kan den gennemføre en opgave fra start til slut? Så lad os se, om vi kan automatisere den. Der vil stadig altid være menneskelig revision eller gennemgang, men man kan også skabe en agent, der udfører det som første trin. Derefter kan den give resultatet videre til dig.

Det er det, jeg ser efter. På menneskesiden, hvor vi kan automatisere, spørger jeg: Er der behov for større tillid? Er der behov for at trække på unikke erfaringer? Er der nuancer, vi skal tænke over eller navigere i? Når vi placerer dem i de to kategorier, kan vi begynde at finde ud af, hvad der egner sig til automatisering.

Galen Low: Jeg tænkte, at vi kunne skifte til den anden ende og tænke på Alys model — ikke kun dokumentationen, men også hvordan folk bruger processen eller dokumentationen til at udføre deres arbejde, og hvordan vi gentager og forbedrer den. Hvordan tager folk faktisk disse processer til sig? Jeg så tidligere i chatten, at nogen skrev, at modstand mod anvendelse er reel og noget, de arbejder med lige nu.

Når det handler om at finde dokumentationen, når man har brug for den, hvilke værktøjer har været effektive til at give informationen direkte til dem, der udfører arbejdet, så de ikke skal lede gennem J-drevet eller lignende? Har nogen allerede en chatbot til deres standardiserede arbejdsprocedurer?

Gray, jeg tænkte, at jeg ville give den til dig, fordi meget af det er indbygget i nogle af disse produktivitetsplatforme. Brian, som du siger, er noget af automatiseringen og AI'en indbygget. Hvordan hjælper du folk med at have processerne lige ved hånden, så de faktisk bruger dem og har lyst til at bruge dem?

Gray Mackenzie: Jeg tror, det er en af de store årsager til, at folk ikke finder værdi i det. Jeg skrev det hele i en mappe på hylden, og så blev den åbnet igen næste år. Jeg er stærk tilhænger af at gøre processen levende dér, hvor arbejdet udføres. Det er en af grundpillerne i ZenPilot-metoden. Når vi tildeler arbejde til folk, vil vi gerne have, at standardproceduren er direkte knyttet til opgaven. Hvor vi kan, skal den allerede være på plads.

Vi har måske ikke en standardprocedure, og det er fint. Der opstår ad hoc-opgaver, men der sker enormt meget gentageligt arbejde i de fleste organisationer. Derfor skal man linke direkte til den fra selve opgaven.

Den anden del er, at dette er et vaneproblem. Det meste er et vaneproblem. Vi kan tale om en tilpasset GPT, hvis vi har tid, men meget af det handler kulturelt om, at vi får det, vi tolererer, og det, vi fejrer. Det afgør, hvad vi ender med at få i alt.

Det samme gælder anvendelsen af processer. Hvis du siger: Du er god til dit arbejde, og tingene fungerer som regel, så er det ligegyldigt, om du gør tingene i forkert rækkefølge eller hele tiden skriver til folk på Slack for at få opdateringer i stedet for at tjekke projektstyringssystemet, selv om du har sagt, at alle skal holde det opdateret. Så tolererer du, at processen ikke bliver anvendt. Derfor får du mere af det.

Det sker uundgåeligt. Det er som enhver anden vane. De er alle svære at opbygge i starten, men bliver meget nemmere, når de er blevet rutine. Man skal opbygge vanen med ikke at tolerere, at processen ikke bruges.

Og en del af den manglende tolerance må være spørgsmålet: Hvad er årsagen? Vi skal være lidt introspektive og indse, om folk ikke følger processen, fordi den er dårlig, eller fordi den er for besværlig. Aly og Brian nævnte begge, at vi skal gøre den enkel og let at anvende.

Hvis du giver mig en seks minutter lang Loom-video, er der ingen chance for, at jeg vil se hele videoen, medmindre det er første gang, jeg gør det. Giv mig i stedet hurtigt punktlisten. At bruge Loom til at få det ud første gang giver fuldstændig mening.

At bruge Loom, når nogen gør det første gang eller gør det første gang i lang tid, giver også mening. Men kombiner det med: Her er punkterne, og her er tidsstemplet, hvor du kan hente det, du har brug for. Så taler vi. Så kan jeg gå direkte til det relevante.

Vi skal gøre det så tilgængeligt som muligt, gøre processen levende dér, hvor arbejdet udføres, og derefter ikke tolerere manglende anvendelse. Vi skal også sikre, at vi fejrer den konsekvens, som de nye processer skaber. Og som Aly siger, er bruttoavancen i de fleste af vores kunders tilfælde det centrale, som procesarbejdet påvirker. Vi skal fejre de fremskridt, vi gør der.

Galen Low: Jeg er helt sikkert også den person. Jeg føler mig virkelig ramt lige nu. Jeg tænker: Du er klog. Hvis du ikke følger processen, er det fint. Jeg fejrer dig, fordi jeg ansatte dig som et intelligent menneske. Men det betyder ikke, at det gør dig mindre intelligent at følge en proces.

Min grund til at have en proces er, at når mit lille team bliver større, skal det ikke være det vilde vesten, og vi skal kunne vokse uden kaos. Hvis jeg kan huske det, bliver det lettere for mig ikke kun at fejre det at være et professionelt menneske.

Det er fint, og jeg ved, at du får arbejdet gjort. Men den langsigtede virkning er, at når jeg senere har 27 intelligente og kompetente mennesker, der alle gør forskellige ting på 27 forskellige måder, bliver det et problem.

Kan vi dykke ned i den tilpassede GPT? Nu er jeg blevet nysgerrig. Du nævnte den.

Gray Mackenzie: Der er et par forskellige, som har været meget nyttige for os. En enkel er, at vi hjælper teams med at tage de processer, de har, og bygge et resultat ud af dem. Hvordan ser arbejdsgangen ud i ClickUp? Det betyder, at vi bruger en overordnet opgave: Her er jeres leverance, og hver enkelt handlingsopgave eller hvert handlingstrin er en underopgave under den.

Der er også en hel metode for teams, der vil se arbejdsbelastningen. Hvordan styrer vi kapacitet og den daglige taktiske fordeling af ressourcer? Hvordan beslutter vi, hvad der skal skubbes, og hvornår vi skal fortælle en kunde, at noget bliver forsinket?

Tidsestimater er vigtige. Det er vigtigt, hvilken rolle der er ansvarlig for at få det gjort. En af de tilpassede GPT'er, vi får bygget, bruger et skærmbillede af en skabelon, du har oprettet. Den giver den en karakter fra 1 til 10 og fortæller, hvad der specifikt bør se anderledes ud.

Navngivningsmetoder og konsekvens i dem er ret vigtige. Din leverance er et navneord, og hver opgave begynder med et udsagnsord. Er der et estimeret tidsforbrug? Er der angivet afhængigheder mellem opgaverne? Har vi en tidsplan, som vi normalt følger i vores arbejdsbelastning?

Den gennemgår det hele, finder problemer og peger på, hvad der ikke giver mening, eller hvad der kunne være bedre. På den måde kan mange forskellige mennesker skabe dem. Det er vigtigt, for ellers laver én person én global gennemgang, og seks måneder senere er alt forældet.

Vi skal have evnen og musklen til at opbygge det hos forskellige teammedlemmer — de mennesker, der faktisk er dygtige til deres arbejde. Men de husker ikke alt og bygger det ikke rigtigt første gang, hver gang. Derfor har den tilpassede GPT været meget nyttig for os.

Galen Low: Det kan jeg virkelig godt lide.

Jeg spekulerer på, om vi også kan dykke ned i spørgsmålet om at holde ting opdaterede. Jeg kan se nogle af spørgsmålene, og vi kommer til dem. Hvordan ser det ud for de andre i panelet? Hvordan sikrer I, at opdateringer bliver indarbejdet, så processen altid afspejler det, der faktisk sker?

Brian Kessman: Med hensyn til opdatering tror jeg, at der skal være en proces med løbende forbedringer og en kultur, der understøtter den. Hvis du har brugt Googles NotebookLM, er det virkelig godt til at uploade en stor mængde dokumentation.

Det blev vist oprindeligt præsenteret som et forskningsværktøj, men der er mange gode måder at bruge det på. Hvis du uploader alle dine forskellige procesdokumenter, kan du straks skabe gode leverancer som en indholdsfortegnelse eller endda en studieguide, hvis du vil teste dine medarbejdere i processerne.

Og endda en podcast, hvor nogen kan lytte til en podcast om alle processerne. Hvad kunne være mere spændende? Der er mange gode anvendelsesmuligheder ud over det, jeg har nævnt. Det er et RAG-system, altså retrieval-augmented generation, informationshentningsbaseret generering.

Jeg tror, nogle af de andre produkter har det samme, men Googles løsning er meget effektiv og gør det nemt at fjerne markeringen fra eller markere de dokumenter, man vil bruge som reference. Når du tilføjer et nyt dokument, kan du fjerne markeringen fra den gamle version og markere den nye. Det er et stærkt værktøj til den slags formål.

Galen Low: Aly, jeg tænkte også på Loom-videoerne, fordi vi talte om de to ender. Der er den første indsats med at skabe videoen. Er svaret på at udbygge processen at optage endnu en video, eller går man bare ind og opdaterer teksten? Hvad er kilden til sandheden og processen for at udbygge dokumentationen, når den begynder med en video?

Alyson Caffrey: Jeg synes altid, at en ny video er ideel. Og det er ikke så besværligt at skabe den, fordi nogen alligevel udfører processen på en anden måde. Det behøver ikke være dig.

Lad os sige, at du har skabt den oprindelige proces med en gennemgangsvideo, givet den videre til nogen, og at vedkommende har fundet en bedre måde at gøre det på. Det er fantastisk; det betyder, at vi har ansat de rigtige mennesker. Så siger vi: Vil du ikke bare næste gang, du skal gøre det her, optage en ny video?

Jeg synes faktisk, det hjælper meget med anvendelsen. Der er to store grunde til, at teams ikke følger eller opdaterer vores dokumentation. For det første minder ingen dem konsekvent om det. Jeg læste for nylig en bog af Patrick Lencioni, hvor han skrev, at man som virksomhedens administrerende direktør skal være den øverste påmindelsesansvarlige. Det er en meget vigtig funktion.

Hvis det ikke ligger hos dig som grundlægger, administrerende direktør eller leder, skal det ligge hos en anden. Udpeg en ansvarlig for standardprocedurer eller en intern vidensansvarlig, som tager ansvar for at gennemgå materialet eller minde folk om at opdatere deres skærmoptagelser eller tekst­dokumentation.

For det andet har vi ikke altid vist, hvad der er muligt. Gray talte om at forstå fordelene og effekten. Vi talte meget om data, men teamet er måske ikke særligt interesseret i bruttoavancen, fordi de ikke er knyttet til bundlinjen.

Det, de interesserer sig for, er balancen mellem arbejde og privatliv, at kunne holde ferie og ikke skulle oplære hvert eneste teammedlem, de har ansvar for, helt fra bunden en-til-en. Derfor er det meget vigtigt at kunne forklare disse fordele, når man taler om anvendelse og procesoverholdelse.

Fortæl dine medarbejdere, at der er en vej til at blive leder. Fortæl din leder, at der er en vej til at blive direktør. Det handler alt sammen om at skabe gentagelighed og opbygge et Google for virksomheden. Googles styrke er, at der er så mange bidragydere.

Det er ikke én person, der hælder alle sine meninger, tanker og fakta ud over alle andre. Din vidensbase og dine processer bliver stærkere, når mange bidrager, efterhånden som teamet vokser. Jeg plejer at sige, at indtil et team er omkring 70 personer — i hvert fald ud fra mit arbejde med bureauer gennem de sidste ti år — er drift eller procesdokumentation en lille del af alles rolle i stedet for blot én afdelings rolle.

Hvis du arbejder i et bureau og tænker: Vi er et team på 30, er det fint. Ti procent af alles jobbeskrivelse er, at man hjælper med at forbedre processer og dokumentere procedurer, der specifikt vedrører ens rolle.

Galen Low: Jeg elsker ideen om et Google for virksomheden og mange bidragydere. Lad os lade de gode ideer stige til tops.

Okay, jeg går videre til spørgsmål og svar. Det første handler om at forblive agil.

Spørgsmålet er: Hvilke løsninger har folk fundet for at forblive agile og samtidig opstille parametre og retningslinjer, så nye medarbejdere får et godt udgangspunkt? Det er et virkelig spændende spørgsmål, fordi vi taler om et Google for virksomheden, og hvordan man ved, hvilken version man skal følge. Hvordan kan det være tydeligt, hvilke løsninger vi har fundet for at være agile uden at være kaotiske?

Er der nogen, der vil tage den?

Brian Kessman: Begynd med nogle driftsprincipper. Hvordan skal vi alle arbejde sammen? Hvilke principper kan vi alle blive enige om? Man kan låne mange principper fra agil udvikling og oversætte dem til det kreative område, samtidig med at man tager hensyn til de begrænsninger, agilitet kan lægge på den kreative proces.

Vi kan også lære meget af agil udvikling og Lean. Lean handler om at fjerne spild fra processer. Hvad er jeres mindst mulige levedygtige proces? Tænk på den måde, når I definerer processerne. Fokuser kun på de vigtigste, som påvirker omsætning eller kundeoplevelse. Disse driftsprincipper vil være et godt sted at begynde.

På teamniveau kan man have et enkelt teamcharter — en mere uformel social kontrakt. Hvordan skal vi arbejde sammen som team? Man kan søge online og finde eksempler på teamchartere med omkring 20 spørgsmål, som man besvarer som team. Begynd med de fem vigtigste for teamet.

Efter den næste retrospektive evaluering kan man spørge: Er der andre spørgsmål, som vi har indset, at vi bør stille og besvare som team for at definere, hvordan vi vil arbejde sammen? Det er to hurtige måder at bevare agiliteten, fjerne forvirring og skabe større konsekvens.

Galen Low: Jeg kan godt lide den tilgang med et charter og et fællesskab. Det hænger også sammen med det, du sagde tidligere om dedikerede teams, mindre grupper af mennesker, der arbejder tæt sammen, og det, Aly sagde: Alle ejer det sammen.

Hvis du får en ny medarbejder eller onboarder nogen i teamet, kan I gennemgå charteret, værdierne og måden, I arbejder sammen på. Tingene er flydende, og vi er agile, men her er, hvordan vi ved, hvad de andre laver på ethvert tidspunkt.

Alyson Caffrey: Jeg vil hurtigt tilføje, at når jeg gennem årene har arbejdet med bureauer, er der to sæt standarder, vi kan arbejde efter for at bevare agiliteten og samtidig have et fælles slutresultat, selv om processen stadig virker lidt rodet. Jeg synes, man skal skabe produktionsstandarder.

Hvornår svarer vi kunder? Hvor hurtigt får vi dette gjort? Den slags. Tidsbaserede standarder og derefter kvalitetsstandarder: Hvordan skal det se ud, når det opfylder kvalitets- og produktionsstandarderne? Jeg kender mange bureauer, der arbejder meget Lean, og som får stor fordel af dette i stedet for at forsøge at definere den rodede midte i processen. De siger: Dette er produktionsstandarden, og dette er kvalitetsstandarden, som vi alle arbejder efter.

Galen Low: Jeg går videre til det næste spørgsmål. Det er mere værktøjsspecifikt. Spørgsmålet er: Jeg vil meget gerne høre paneldeltagernes tanker om værktøjer som Trainual eller Scribe.

Vi har talt lidt om Scribe. Jeg må indrømme, at jeg ikke kender nogen af værktøjerne særlig godt, men det er en god mulighed, hvis I eller folk i publikum har tanker eller holdninger til brugen af Trainual og Scribe.

Gray Mackenzie: Jeg tager den første. Jeg kan faktisk godt lide og kender folkene hos Trainual og Scribe.

Begge værktøjer er gode til procesdokumentation, som er nem at gentage og sende videre. Jeg synes, de er en meget forenklet version af et projektstyringsværktøj med nogle forbedrede funktioner. For de fleste teams bør man vælge mellem en af to muligheder: Enten bruger man et projektstyringsværktøj og bygger det ind i sit vidensstyringsværktøj, eller også går man den anden vej og siger, at man vil bruge vidensstyringsværktøjet.

Man ved, at man ofrer nogle projektstyringsfunktioner. Men at køre dem parallelt har skabt mange udfordringer for teams. Der er teams, som bruger det og elsker det. De siger: Vi har ting i vores projektstyringssystem og linker til det derfra. Det giver mening. Jeg forstår, at der er tilfælde, hvor begge dele giver mening, men på tværs af de tusindvis af teams, vi har set og arbejdet med, forbedres resultaterne for bruttoavance, effektivitet og virkning langt oftere, når de vælger det ene eller det andet.

Galen Low: Jeg får selv værktøjssyndromet med for mange værktøjer. Som du siger, er det ikke sikkert, at nogen, der ser på det, forstår, at et projektstyringsværktøj kan gøre nogle af de samme ting. Man har ikke nødvendigvis brug for begge. Det ser ud, som om man har brug for begge, men det er måske ikke den rigtige løsning. Brian, Aly, har I tanker om Trainual og Scribe?

Alyson Caffrey: Jeg er partner hos Trainual, så jeg må råbe det fra hustagene: Jeg er helt vild med Trainual. Vi var faktisk blandt deres første certificerede partnere. Jeg har arbejdet i Trainual i de sidste seks år. For virksomheder i kraftig vækst, som ved, at de snart går ind i en periode med ansættelser, eller bureauer med en vækstmodel baseret på opkøb, har vi set stor succes med Trainual.

En af Trainuals kerneværdier er at få folk hurtigt op i fart. Det er hele pointen. Når en ny person kommer ind i organisationen, eller når organisationer fusionerer, er der behov for en periode med tilvænning. At komme i gang med Trainual ved hjælp af standardprocedurer og samle alle oplysninger ét sted er meget brugervenligt.

Men fra et rent AI-dokumentationsperspektiv er Loom og Scribe fantastiske værktøjer. Hvis du ikke står foran en stor ansættelsesperiode eller ikke har en model baseret på opkøb, synes jeg, at Scribe er et godt værktøj til at holde alle på samme side. Scribe kan indlejres i projektstyringsværktøjer, som Gray sagde.

Jeg er også stor fan af at holde informationen dér, hvor arbejdet udføres. Jeg siger altid, at du bør være én eller to klik fra alt, hvad du måtte have brug for i organisationen. Hvis arbejdet foregår på denne platform, og den nemt linker til viden og alt det andet, er det fantastisk.

Jeg er enig i, at projektstyringsværktøjet bør bruges til projektstyring, og dokumentationsværktøjet til dokumentation. Mange virksomheder har fordel af at have begge dele, men integration og klare spilleregler er meget vigtigt.

Det er afgørende at vide, hvad der hører hjemme i hvilket værktøj.

Galen Low: Det går også tilbage til charteret, ikke? Jeg har to spørgsmål i køen, og jeg vil se, om jeg kan nå begge på tre minutter. Jeg prøver.

Et af spørgsmålene er: Har I nogle tips til prompter, som folk har brugt til at få AI til at hjælpe med at opbygge processer? Er der nogle prompter, I har eksperimenteret med?

Gray Mackenzie: Jeg gør det meget kort. Jeg har bedt den tilpasse dokumentationen til det niveau, den person har, som skal læse den. Jeg tager noget af den dokumentation, vi har, og beder den sige: Hvis jeg var nyansat i denne virksomhed, der gør dette, hvad ville du så ændre ved dokumentationen? Derefter indsætter jeg det, vi har. Det har været nyttigt til onboarding.

Galen Low: Det kan jeg godt lide. Brian, har du nogle gode prompter? Du er gået ret dybt ind i det.

Brian Kessman: Det er svært at sige: Her er en prompt, der fungerer for dig. Alles situation og målgruppe er forskellig, som Gray siger.

Det handler mere om principperne. Det er ligesom at lede nogen eller hjælpe en ny medarbejder på kontoret. Vær meget specifik om, hvad du leder efter, hvem det udvikles til, og hvad resultatet skal være. Giv derefter yderligere kontekst og den præcise opgave.

Angiv også det format, du har brug for. Hvis du har en skabelon, selv uden informationen, men med overskrifter og alt det andet, får du bedre resultater, jo mere specifik du er.

Galen Low: Det kan jeg godt lide. Jeg kunne også godt lide, at svaret ikke var: Her er en prompt, der fra bunden kan skabe en proces, du ikke har nu.

Generér en proces for mig. Optræd som et bureau, der vil vokse meget hurtigt.

Brian Kessman: Det ville være nyttigt at have en prompt, der hjælper dig med at skrive en prompt til en ny proces. Det kan man sagtens udvikle. Endnu mere nyttigt ville være en prompt, der stiller dig de rigtige spørgsmål, som den skal bruge for at skabe den rigtige type output, så den i det mindste styrer din tankeproces.

Jeg har udviklet noget i den retning. Det var en virtuel chef for prisfastsættelse. Den hjalp bureauer med at prissætte deres arbejde i tre forskellige muligheder og forstå, om de stod over for en prisdrevet eller værdidrevet køber. Den gav prisstrategier og alt det andet.

Men den gør det samme: Den stiller dig de spørgsmål, den har brug for, for at udføre opgaven. Sigt efter noget i den retning.

Galen Low: Bum. Det elsker jeg. Jeg tror, jeg runder af her. En stor tak til vores paneldeltagere for at stille deres tid og viden til rådighed i dag. Gray, Brian, Aly, det var virkelig sjovt. Jeg elsker altid at tale med jer hver især. Jeg er glad for, at vi fik mulighed for at samle jer alle tre i samme rum. Det her har været en fornøjelse.

Brian Kessman: Tak, fordi vi måtte være med.

Alyson Caffrey: Tak, Galen. Det sætter jeg pris på.

Galen Low: Så er det jer, folkens. Som altid kan I deltage i samtalen med over tusind ligesindede forkæmpere for projektledelse ved at slutte jer til vores fællesskab. Gå ind på thedigitalprojectmanager.com/membership for at læse mere. Hvis I kunne lide det, I hørte i dag, så abonnér og hold kontakten på thedigitalprojectmanager.com. Indtil næste gang: Tak, fordi I lyttede.