Udbudslæseren: 300 siders udbudsmateriale, ét overblik
I sidste indlæg skrev jeg lidt om, hvordan jeg mener, AI bør bruges i en arbejdsgang: som en afgrænset komponent med fast output og et rigtigt menneske i enden. Sådan et værktøj har jeg forsøgt at bygge. Det er blevet til "Udbudslæseren", og det læser dansk udbudsmateriale for mindre bygge- og håndværksvirksomheder.
Problemet
Et offentligt udbud kommer med en masse materiale, man skal forholde sig til, inden man kan vudere, om man vil komme med et tilbud. Det er: udbudsbetingelser, særlige betingelser, arbejdsbeskrivelser, tilbudslister og bilag, som ofte løber op i flere hundrede sider tilsammen.
Et sted i de sider kan der stå ting, der afgør, om en opgave er værd at byde på eller ej. Betalingsbetingelser, der afviger fra det normale. Dagbøder. Garantikrav. Frister, der ikke må overses. Og næsten altid en sætning i stil med "AB18 er gældende med de ændringer og præciseringer, der fremgår af nærværende betingelser" — efterfulgt af netop de ændringer, fordelt ud over dokumentet.
En stor entreprenørvirksomhed har naturligvis folk til at læse det, men i en virksomhed med 15 ansatte er det ofte indehaveren, der læser det om aftenen. Jeg har bygget det her værktøj med forhåbning om, at det vil kunne gøre hans arbejde nemmere og hurtigere.
Hvad værktøjet gør
Udbudslæseren læser det samlede materiale og leverer en kort rapport med fast struktur. Den fremhæver:
- Afvigelser fra AB18 — de steder, hvor betingelserne fraviger standardvilkårene, markeret efter alvorlighed, så det kritiske står øverst
- Frister — spørgefrist, tilbudsfrist, vedståelsesfrist, opstart
- Økonomiske vilkår — betalingsbetingelser, sikkerhedsstillelse, dagbøder
- Krav til tilbuddet — hvad der skal vedlægges, og hvordan der afleveres
Rapporten er den samme struktur hver gang, uanset hvem der har skrevet udbuddet, og hvordan materialet er skruet sammen. Det er nemlig pointen: man skal kunne slå op de samme steder i hvert udbud og sammenligne på tværs.
Hvad værktøjet ikke gør
Det afgør ikke, om man skal byde. Det regner ikke priser. Det kender ikke ens ordrebog, kapacitet eller forhold til bygherren.
Og det er med vilje. Beslutningen om at byde er præcis den type beslutning, jeg i de to forrige indlæg skrev, at man ikke bør automatisere. Værktøjet læser bare de 300 sider og peger på de ti steder, der kræver opmærksomhed. Vurderingen er ikke op til værktøjet, men derimod den, der bruger det.
Jeg vil lige påpege, at jeg altså ikke har nogen byggefaglig baggrund eller lignende. Det, jeg har bygget, er et systematisk værktøj, der læser materiale igennem og leverer et resultat, der giver samme resultat, hvis du kører det over samme udbud flere gange. Det hallucinerer altså ikke noget nyt hver gang, som det kan ske, hvis man bruger ChatGPT. Så husk: fagligheden — altså om en afvigelse er acceptabel i den bestemte situation — er op til den, der bruger værktøjet.
Hvad med dokumenterne?
Udbudsmateriale er offentligt i sin natur, så der er altså ingen fortrolige data på spil. Men jeg har alligevel valgt, at al behandling sker i Europa under GDPR, hos en europæisk leverandør. Ikke fordi det er nødvendigt her, men fordi det er sådan, jeg gerne vil bygge ting. Det princip bliver vigtigere den dag, et værktøj skal læse noget, der ikke er offentligt.
Prøv det
Hvis, der skulle sidde nogen og læse det her, og som kunne tænke sig at prøve det af, så kontakt mig gerne.
Find et gammelt udbud, I selv har regnet på. Ét, hvor I kender materialet og ved, hvad der stod i det. Send det til mig, så får I en rapport retur. Så kan I selv se, om værktøjet fandt det, I fandt, og om det fandt noget, I ikke gjorde. Den kørsel koster ikke noget.
Rammer rapporten skævt, så har I kun brugt ti minutter, og jeg kan efterfølgende bygge videre på værktøjet og gøre det bedre. Men rammer den rigtigt, så kan vi tale om at køre den på det næste levende udbud, før I afgiver tilbud.
Byder I på offentlige opgaver, eller overvejer I at begynde? Skriv til mig med et udbud, I kender, så får I en rapport retur, som I kan vurdere mig på.