Fem sider het «start her» — derfor fant ingen dokumentasjonen

Vi hadde ikke for lite dokumentasjon. Vi hadde fem oversiktssider som alle het en variant av «start her», og ingen av dem visste at de andre fantes.

Konsekvensen er lettere å beskrive enn å tro på: en som skulle sette seg inn i systemet, landet på én av de fem, leste den ferdig, konkluderte med at oversikten manglet — og lagde en sjette.

Det er ikke en morsom anekdote. Det er en maskin. Hver gang noen kom inn og fant én dør, fikk vi en dør til, og hver ny dør gjorde det mindre sannsynlig at neste person fant den riktige.

---

Kort vei til svaret: hvis dere kjenner igjen at «det står jo i Confluence», men ingen finner det — ta en prat om strukturen før dere kjøper et søkeverktøy. Problemet er som regel ikke søket.

Slik vurderer vi dette

Alt i denne artikkelen er hentet fra vårt eget oppsett, ikke fra en metodebok. Vi bruker Notion som styringslag for automatiseringene våre, og problemene under er problemer vi selv har laget og selv har måttet rydde opp i.

Det vi kan stå inne for:

• Hendelsene er ekte, og datoene er hentet fra loggene der de skjedde
• Der noe er en regel og ikke en teknisk sperre, står det hvilken av delene det er
• Der noe ikke er ferdig, står det at det ikke er ferdig

Det vi ikke påstår: at dette er ferdig tenkt, eller at det er overførbart uten tilpasning. Søkelaget under det hele er halvbygget — mer om det mot slutten. Vi oppgir heller ingen tall for hvor mye tid struktureringen har spart, fordi vi ikke har målt det, og et anslag uten måling er en påstand med desimaler.

Artikkelen gjennomgås på nytt når noe av dette endrer seg. Sist gjennomgått 15. august 2026.

Skrevet av Svein Tore Olsen, daglig leder i Ebizapple, som holder til i Askim.

---

Hvorfor dette gjelder uten AI også

Problemet er gammelt og har et navn: dokumentasjon som finnes, men ikke blir brukt. Alle med en wiki kjenner det. En kollega spør om noe som er skrevet ned for to år siden, og ingen husker at det er skrevet ned.

Det som gjør det akutt hos oss, er at flere av dem som leser og skriver i systemet vårt er AI-agenter, og en agent har ingen erfaring å falle tilbake på. Et menneske som har vært i bedriften i tre år, husker at «den greia står i den gamle mappa». En agent åpner hver økt fra null. Den er som en nyansatt hver eneste dag, uten dagene før.

Det er ubehagelig, men også nyttig: agenten er et måleinstrument. Den avslører nøyaktig hvor dokumentasjonen forutsetter kunnskap den ikke selv inneholder. Hvis en agent ikke finner fram, gjør ikke en ny kollega det heller — hun spør bare en som har vært der lenge, og skjuler dermed feilen.

Kan ikke AI-en bare søke selv? Den søker. Det er ikke der det svikter. Den søker på ordene i oppgaven, og finner ikke dokumentet som bruker andre ord om det samme. Mer om det under.

---

Det som faktisk gikk galt

Fem kart, ingen hierarki

Vi hadde fem oversiktssider. Én var en historisk grunnmur fra de første førti dagene. Én var et «finn alt»-kart. Én var et kartotek. Én var en milepæl-logg. Den femte var den som til slutt ble stående.

Ingen av dem sa hva den var i forhold til de andre, og flere av dem åpnet med en variant av «start her». De ble konsolidert til én 15. juni 2026.

Det som til slutt løste det, var ikke et bedre kart. Det var en rangordning: én av dem ble utpekt som den kanoniske inngangen, og alle de andre fikk to krav på seg. De må si hvilken rolle de har — «jeg er milepælloggen», «jeg er registeret over kjørbare oppgaver» — og de må peke tilbake til inngangen øverst på siden.

Og så en regel som er viktigere enn begge: det er ikke lov å lage et nytt «finn alt»-kart. Trenger du å legge til noe, utvider du det som finnes. Uten den regelen kommer den sjette døra tilbake, fordi det alltid er lettere å lage et nytt dokument enn å finne det gamle.

Løsningen fantes. Den lå bare dobbelt begravd

Den verste enkeltforekomsten er verdt å beskrive nøyaktig, fordi den sier mer enn prinsippet gjør.

Vi hadde et spesifikasjonsarbeid på en søkemotor — vurderinger, anbefalinger, en beslutningslogg, en oppskrift på hvordan den skulle settes opp. Alt sammen ferdig skrevet. Det lå i en arkivert database under et kart som var merket som erstattet. To lag med «ikke se her» over noe som var det viktigste ubrukte arbeidet i systemet.

Konsekvensen: en blokkering vi omtalte som uløst, var i praksis opphevet 16. juni. Vi oppdaget det først den 19. Tre dager er ikke katastrofalt i seg selv, men det er bare den delen vi kan måle — spec-en hadde da ligget ubrukt siden begynnelsen av juni.

Samme mønster, tydeligere, i et annet prosjekt: to programtillegg som fikk kartet til å virke, lå ferdige i fillageret. De var aldri lastet opp. I mellomtiden bygde vi rundt fraværet av dem — altså laget vi omveier rundt et hull som ikke fantes, over flere økter, og forsket på nytt på spørsmål som allerede var avklart. Det er der «flere runder» faktisk lar seg telle.

Det er den dyreste feilen i hele denne artikkelen, og den koster ingen penger i seg selv. Den koster tid, om igjen og om igjen.

Motgiften er den samme i småskala. To av vanene vi har skrevet ned i fem feller vi selv gikk i da vi bygde i Make er «kopier modulnavnet fra et oppsett som virker» og «les typen fra et scenario som allerede kjører» — altså: se etter om det finnes, før du lager det.

Sletting som løgn

Da vi begynte å rydde, oppdaget vi den neste fellen med en gang.

Flytter du et dokument og lar pekerne til det stå, blir hver peker en løgn i det øyeblikket du forlater siden. Det er ikke et framtidig problem. Det er umiddelbart.

Vi ryddet 3. juli, og tre feilrutinger som kom fram under ryddingen hadde samme opphav: noe var endret uten at pekerne inn til det ble oppdatert i samme operasjon.

To regler kom ut av det, og de henger sammen:

Ikke slett — sett en gravstein. Et dokument som er erstattet, blir stående med et merke om at det er erstattet, og en peker til det som gjelder nå. Sletter du, får neste person et tomt søkeresultat og ingen mulighet til å forstå hva som skjedde. Gravsteinen gjør historikken lesbar uten å gjøre den gjeldende.

Oppdater pekerne inn i samme operasjon. Ikke «etterpå», ikke «på lista». Endringen er ikke ferdig før alle som peker på tingen, peker riktig.

Vi bruker det samme mønsteret på nettstedet du leser dette på. Da vi oppdaget at et notat i prosjektet vårt hadde en foreldet kopi liggende ett nivå høyere i mappetreet, slettet vi ikke kopien. Vi tømte den og la igjen en peker — nettopp fordi en foreldet kopi som ligger nærmere enn originalen, blir funnet først.

Nøkkelord er ikke emne

Denne er lettest å overse og hardest å fikse.

Et søk på «kvalitetskontroll» treffer ikke et dokument som skriver «port», «sikringstiltak» eller en intern kode om det samme. Ordet er helt rimelig; det finnes bare ikke i teksten.

Det hjelper ikke å søke bedre, og det hjelper ikke å kjøpe et bedre søkeverktøy. Ordene er ikke der.

To ting virker mot dette, og de må virke sammen. Vi har det første og er halvveis på det andre:

Et lite, kontrollert sett med emneord. Ikke fritekst-tagger — de blir til tjue varianter av det samme. Et bestemt antall tagger, og et nytt ord må legges inn i ordlisten før det kan brukes.

En ordliste som oversetter paraplyord til fagtermer. Slik at søkeordet «kvalitetskontroll» også leter etter «port» og «sikringstiltak». Det er samme mekanikk som en bibliotekstesaurus, og den er hundre år eldre enn noen av verktøyene vi bruker.

Ordlisten vår finnes, men den virker bare for de dokumentene som har fått synonymene sine lagt inn. Det arbeidet er ikke fullført, og det er verdt å vite før man tror at oversettelsen skjer av seg selv.

---

Det som virket best var å gjøre oppslag til et krav

Her er det interessante funnet, og det gjelder mennesker like mye som maskiner.

Vi hadde en regel som het «les først». Den var riktig, alle var enige i den, og den ble hoppet over hele tiden.

Grunnen er ikke slurv. En regel som må huskes, må gjennom fire ledd før den virker: du må huske at den finnes, velge å følge den, faktisk søke, og deretter tolke det du fant. Hvert ledd er et sted å falle av, og med fire ledd faller nesten alle av et sted.

Så vi sluttet å be om det, og gjorde det til struktur i stedet.

En oppgave i systemet vårt har nå et felt som heter «Eksisterende». Der skal treffene fra søket stå — en referanse til en eksisterende løsning, eller ordene «ingen funnet». Er feltet tomt, regnes ikke oppgaven som klar til bygging.

Her må jeg være presis, for dette er lett å overselge: i dag er det en regel med et felt bak seg, ikke en teknisk lås. Sperren som skal nekte å plukke opp en oppgave med tomt felt, er planlagt og ikke bygget. Vi har flyttet regelen fra hodet til skjemaet, men ikke helt inn i maskineriet.

Selv halvveis virker det, og grunnen er verdt å merke seg: den som åpner oppgaven, ser feltet. Det er ikke lenger noe man må huske at finnes. Tre av de fire leddene er borte, og det fjerde — å faktisk fylle det ut — er synlig for alle som ser på oppgaven.

Dette er det eneste grepet i artikkelen jeg ville anbefalt en bedrift uten AI i det hele tatt. Legg feltet på oppgavemalen. «Har noen gjort dette før — og hvor?» må besvares før arbeidet begynner, ikke etterpå.

Er ikke dette bare mer byråkrati? Det er ett felt, og det erstatter en jobb som ellers gjøres om igjen. Byråkrati er skjemaer som ikke endrer utfallet. Dette endrer hvilket arbeid som blir gjort.

---

To flater, to publikum

Så oppdaget vi at vi hadde løst feil problem — eller rettere, ett av to problemer.

Den kanoniske inngangen ble god til det den var laget for: å gi en fersk agent nok kontekst til å komme i gang. Men den ble lang. Den måtte være lang, for den skal svare på «hvor er jeg, hva gjelder her, hva er reglene».

For et menneske som bare skal finne én ting, var den blitt en vegg. Ordene mine egne, notert ned den dagen, var enkle nok: alt på riktig sted, lett å finne — uten å bruke AI for å forstå hva jeg har.

Løsningen var ikke å korte ned inngangen. Det var å innse at det er to publikum med hver sin oppgave:

Vi bruker samme todeling på nettstedet du leser dette på: en oversikt over hva vi bygger for den som orienterer seg, og prisoversikten for den som allerede vet hva hun skal ha.

Katalogen er en enkel tabell. Én rad per ting, med en kolonne der du kan søke på symptomet med dine egne ord — ikke på det offisielle navnet, som du sannsynligvis ikke kan. Filtrer på prosjekt, få plasseringen, ferdig. Ingen AI involvert.

Det er den samme innsikten som ligger bak at et nettsted har både en forside og et søkefelt. De gjør ikke samme jobb, og den ene erstatter ikke den andre.

Katalogen er heller ikke ferdig. Den er reist og i bruk, men ikke alle kategoriene har fått radene sine ennå — noen svarer fortsatt med en peker til en spesialindeks i stedet for med tingen selv. Det er et kjent og åpent punkt.

---

Hva det koster å holde ved like

Ærlig regnskap, for dette er ikke gratis.

Strukturen over har en løpende kostnad: hver ny ting skal registreres i katalogen, hver endring skal ha pekerne oppdatert i samme operasjon, og nye emneord skal inn i ordlisten før de brukes. Det er små jobber, men de er der hver gang.

Til gjengjeld er de små fordi de gjøres én av gangen. Alternativet vi kommer fra — å oppdage etter tre måneder at fem oversikter har vokst fra hverandre — er den samme jobben samlet opp, og da er den ikke liten lenger.

Vi har også automatisert deler av tilsynet: vakter som holder katalogen oppdatert mot det som faktisk finnes. Det er samme prinsipp som vi bygger automatisering som sier fra når den knekker etter for kunder — en kontroll som stopper og sier fra er verdt mer enn en som lykkes stille.

---

Det som ikke er ferdig

Under hele denne strukturen skulle det ligge en ordentlig søkemotor. Den er halvbygget: fundamentet står oppe og er verifisert, men det er tomt. Røret som skal dele opp dokumentene og legge dem inn, er ikke bygget, og vi har ikke bestemt om vi skal fullføre det eller kaste det.

Det er verdt å si høyt, fordi det er lett å lese en artikkel som denne og tro at forfatteren har løst saken. Vi har gjort strukturen mye bedre og søket bare litt bedre.

Det finnes også en grense vi ikke kan automatisere oss forbi: hva som er riktig prioritet, riktig omfang og riktig mål er ikke noe som kan leses ut av systemet. Systemet vet hva som finnes og hva som kjører. Det vet ikke hva som er viktig. Det må et menneske si.

Vi har skrevet mer om den grensen i artikkelen om hvor AI-en møtte en vegg og et menneske måtte legge brikken, og om hva som skjer når to modeller er uenige om det samme svaret.

---

Hvis du skal gjøre dette selv

Fem grep, i rekkefølge. De første to koster nesten ingenting.

1. Tell oversiktssidene dine. Hvor mange dokumenter i bedriften begynner med en variant av «start her» eller «oversikt»? Er svaret mer enn én, er det din struktur, ikke søket ditt, som er problemet.

2. Pek ut én av dem som den kanoniske. Ikke lag en ny. Velg den beste av dem du har, og gi de andre en rolle-etikett og en lenke tilbake.

3. Innfør gravstein i stedet for sletting. Og gjør det til et krav at pekerne inn oppdateres i samme operasjon som flyttingen. Dette er den regelen som sparer mest framtidig forvirring per minutt brukt.

4. Legg et «Eksisterende»-felt på oppgavemalen. Tomt felt = ikke klar. Det er dette grepet som faktisk endrer atferd, fordi det ikke ber noen om å huske noe.

5. Bestem et lite sett emneord, og hold det lite. Nye ord skal godkjennes inn. Fritekst-tagger blir til støy raskere enn du tror.

Legg merke til at ingen av de fem krever ny programvare. Det er poenget. Vi kom hit ved å endre reglene rundt verktøyet, ikke ved å bytte verktøy.

Er dere usikre på hvor dere skal begynne, gjør vi gjerne punkt 1 og 2 sammen med dere som en kort gjennomgang. Ta kontakt, så teller vi dørene.

Spør noen oss hvordan man organiserer en intern kunnskapsbase, er dette svaret i kortform: én inngang, roller på resten, gravstein i stedet for sletting, oppslag som krav, og et lite kontrollert vokabular. Verktøyet kommer sist, ikke først. Det er den samme rekkefølgen vi følger når vi bygger nettsteder på komponenter før sider — strukturen bestemmes før det som skal fylles inn i den.

---

Spørsmål om intern dokumentasjon

Hvorfor blir dokumentasjonen vår ikke brukt?

Som regel ikke fordi den er dårlig, men fordi oppslag er frivillig. En regel om å «lese først» krever at noen husker den, velger å følge den, søker, og tolker svaret — fire ledd der man kan falle av. Gjør oppslaget til et krav i arbeidsflyten i stedet: et felt som må fylles før oppgaven er klar. Det andre vanlige svaret er at ordene ikke stemmer — den som leter bruker paraplyord, dokumentet bruker fagtermer.

Hvor mange oversiktssider bør vi ha?

Én kanonisk inngang. Spesialiserte oversikter er greit og ofte nødvendig, men hver av dem må si hvilken rolle den har og peke tilbake til inngangen. Har du flere sider som alle presenterer seg som «start her», har du ingen inngang — du har et lotteri.

Hva gjør vi med gammel dokumentasjon?

Ikke slett den. Merk den som erstattet, og legg inn en peker til det som gjelder nå. Et tomt søkeresultat forteller ikke leseren hva som skjedde; en gravstein gjør det. Og oppdater alltid pekerne inn til dokumentet i samme operasjon som du flytter det — ellers er de løgn fra det sekundet du lukker fanen.

Trenger vi et søkeverktøy, eller er det strukturen?

Test det billig først: søk på tre ting du vet finnes, med ordene en ny kollega ville brukt. Finner du dem ikke, se på hvilke ord dokumentene faktisk bruker. Er de andre ord enn du søkte på, er en ordliste som oversetter mellom dem billigere og virker fortere enn et nytt verktøy. Et søkeverktøy hjelper når innholdet er for stort til å bla i — ikke når det er feil merket.

Skal dere rydde i dette? Vi tar gjerne en gjennomgang av hvordan arbeidsflyten deres henger sammen før dere kjøper et verktøy for å løse det. Send oss en melding — det er som regel strukturen, ikke søket, og det er billigere å rette.

Gjelder dette bare for bedrifter som bruker AI?

Nei. AI-agenter gjør problemet synlig fordi de ikke har erfaring å kompensere med — de finner ikke fram der en erfaren kollega bare «vet hvor det ligger». Men mekanismen er den samme, og løsningen er den samme. Bruker dere AI-agenter i arbeidsflyten, blir det bare fortere åpenbart at strukturen ikke holder.