24 september 2026
Att sätta upp ett uppdrag innebär en rad korta beslut som känns oviktiga just när man fattar dem: vad projektet ska heta, vilka mappar som ska skapas, var anbudsritningarna ska placeras i förhållande till den reviderade versionen som kom in i fredags. Besluten känns oviktiga eftersom uppdraget ännu inte har påbörjats. De slutar kännas oviktiga sex månader senare, när någon behöver den ritning som priset baserades på och hittar fyra filer med liknande namn.
En projektmall från Takeoff tar bort dessa beslut från det enskilda uppdraget. Man fastställer strukturen en gång, och varje projekt som skapas utifrån den börjar på samma sätt.
Ett projekt i Planmetry innehåller de ritningar du mäter och de filer som hör till dem – foton, anteckningar, scheman – antingen direkt i projektet eller sorterade i mappar inom projektet.
Hierarkin är medvetet platt: ett projekt innehåller mappar, och mappar innehåller ritningar och filer. En mapp innehåller inte en annan mapp. Det är bra att veta innan du utformar en struktur, eftersom den hierarkiska nivåindelning som du kanske skulle vilja använda i ett stort projekt inte finns här. Vid ett projekt som är för stort för en enda mappnivå måste du välja mellan längre mappnamn som ersätter den saknade nivån och flera projekt – och flera projekt innebär att projektet inte längre framträder som en enda post i listan, så gör det valet medvetet istället för att upptäcka det halvvägs in i arbetet.
En mall innehåller ett namn, en beskrivning, en färg, en ordnad lista med mappnamn och en uppsättning fältdefinitioner. När man skapar ett projekt utifrån mallen skapas dessa mappar och fälten kopieras över.
Det är allt, och det är värt att påpeka gränserna: en mall innehåller inga ritningar, filer, anteckningar eller något annat innehåll. Den återger en tom struktur och en rad frågor som ska fyllas i. Värdet ligger i att man slipper fatta nya beslut, inte i att man fyller i uppgifterna i förväg.
Vad som ska ingå i listan beror på hur ditt arbete är uppdelat, och det finns tre vanliga svar:
Det rätta valet är det som stämmer överens med den fråga du oftast ställer när du letar efter något. Om du blandar två av dem på samma nivå skapas mappar vars innehåll ingen kan förutse. Om du verkligen behöver båda, placera dem i mappnamnet i en fast ordning – ”L2 – El”, ”L2 – Gips” – så att listan fortfarande sorteras på ett överskådligt sätt.
Håll listan kort. En mall som skapar nio mappar för ett uppdrag som bara kräver tre lämnar sex tomma mappar, och tomma mappar gör att folk slutar läsa mappnamnen.
Ett ord om versionen ”per steg”, eftersom det är den som man lättast läser för mycket i: att förvara ersatta ritningar i en annan mapp än de aktuella är en arkiveringsrutin, och en användbar sådan – det minskar risken för att man mäter fel version. Det är inte versionshantering: ingenting jämför två versioner av en ritning eller visar vad som har ändrats, och ingenting hindrar att en ersatt ritning mäts. Att flytta den när en ny anländer är en rutin, och den fungerar bara om det är en rutin som du faktiskt följer.
En ritning ger information om en byggnad. Den avslöjar inte vems uppdrag det handlar om, vad man kallade det internt eller när priset ska lämnas in. Den informationen finns oftast i ett e-postmeddelande, vilket innebär att den egentligen inte finns någonstans.
Projektfälten används för att registrera uppgifterna i projektet. Ett fält har en etikett och en typ – text, tal, datum eller en lista med alternativ att välja mellan – så att de uppgifter du registrerar för varje uppdrag dokumenteras på samma sätt varje gång:
Fältvärdena visas på en rad högst upp i projektet på en datorskärm, och det är där de läses av; på en mobil går utrymmet istället till filerna. Ett fält kan ha ett standardvärde i mallen, vilket blir projektets värde när det skapas. Det är bra att använda detta för sådant som oftast är detsamma men ibland inte: en standardstatus som ”prissättning”, en standardberäknare.
Den vana som gör fälten användbara är att fylla i dem redan när du skapar meddelandet, medan du fortfarande har e-postmeddelandet öppet. Ett fält som fylls i senare blir oftast ett fält som aldrig fylls i, och en halvfylld lista över uppgifter är värre än ingen alls, eftersom du inte kan lita på den tillräckligt för att förlita dig på den.
En sak som är viktigt att förstå innan du skapar mallar: ett projekt hämtar sina fält från mallen i det ögonblick det skapas, som en kopia. Om du redigerar mallen i efterhand påverkar det vilka fält framtida projekt får. Ändringarna påverkar inte projekt som redan finns.
Det är rätt tillvägagångssätt – ett uppdrag som prissattes förra våren bör behålla den struktur som låg till grund för prissättningen, istället för att i tysthet lägga till ett fält som inte fanns vid den tidpunkten – men det får en konsekvens. Att ändra en mall är inte rätt sätt att åtgärda uppdrag som redan är igång. Ett fält som du inser att du behöver i ett pågående projekt måste läggas till i vart och ett av dessa projekt, ett i taget.
Det lönar sig alltså att ägna tio minuter åt fältlistan innan man skapar tjugo projekt utifrån en mall, och det är inte värt att grubbla över saken: kostnaden för ett sent tillägg är verklig men begränsad, och den betalas per projekt istället för i en enda omgång.
Det är här det avgörs om en struktur fungerar eller inte, så det lönar sig att vara noggrann med vad sökningen gör.
Sökningen omfattar ritningarna och filerna i ett projekt: deras namn, en ritnings adress, byggnad och identifierad typ, filtypen samt inledningen i anteckningarna. Sökningen omfattar inte projektnamn, mappnamn eller värdena i projektfälten.
Det förändrar syftet med namn. Projektfält är det som gör informationen enhetlig och lättöverskådlig när du öppnar ett projekt – de är inte ett sökindex. Det som går att söka efter i ett projekt är namnen på de objekt som ingår i det, vilket talar för att man bör namnge ritningarna på rätt sätt redan när de läggs in: ett ark som är namngivet efter sitt nummer och vad det visar går att söka efter; ett ark som fortfarande har det namn det exporterades med går inte att söka efter.
Ritningskorten visar en förhandsgranskning av ritningen tillsammans med den angivna ritningstypen och skalan, vilket oftast räcker för att identifiera ritningen utan att behöva öppna den. Ett dokument innehåller en ritningssida, så en flersidig uppsättning hanteras sida för sida och det är namnen som gör det möjligt att skilja dem åt.
Avslutade uppdrag behöver sällan raderas. Ett projekt kan arkiveras, vilket innebär att det tas bort från arbetslistan samtidigt som allt innehåll bevaras, och återställas om det visar sig att uppdraget inte är så färdigt som det verkade. Radering kan göras från arkivet som ett medvetet andra steg, snarare än något som sker av misstag en fredagseftermiddag.
En bra vana är att arkivera utifrån fasta tillfällen snarare än på impuls – när ett uppdrag faktureras, när ett anbud går förlorat – så att arbetslistan förblir tillräckligt kort för att man ska kunna överblicka den. En arbetslista som man kan överblicka med ett ögonkast är ett verktyg. En lista där de flesta posterna avslutades för två år sedan är ett arkivskåp.
Ett bra sätt att ta reda på om en struktur är lämplig: titta på det senaste jobbet du slutförde, notera vilka mappar som faktiskt användes – inte vilka du själv skapade – och använd dem som mall. Kör sedan nästa jobb genom den mallen och se vad du till slut skapar manuellt.
Filerna som placeras i dessa mappar utgör den andra halvan av dokumentationen – fotodokumentationen från byggarbetet visar vad som är värt att spara och varför. När det gäller mätningsdelen av processen beskriver arbetsflödet för mängdberäkning i PDF-format hur helheten hänger ihop.
