Fackartikel
Välja byggprogramvara: först processen, sedan produkten
Att jämföra funktionslistor är enkelt och leder sällan till rätt beslut. Den bättre frågan lyder: vilken av våra processer får vi anpassa till programvaran — och vilken inte?
Fackartikel från Open Experience GmbH. Status: september 2026
Hur väljer man rätt byggprogramvara?
Genom att först dela de egna processerna i två grupper. Primära värdeskapande processer — det ett företag är känt för — får inte anpassas till en programvara: den som underordnar sin kärnprocess en standardlösning arbetar därefter som konkurrenten som använder samma lösning. Stödjande processer är däremot bättre omhändertagna i standardprogramvara, eftersom det där handlar om kostnad och underhållbarhet och ingen skillnad uppstår. Först efter den indelningen lönar sig funktionsjämförelsen.
Rättsläge: Tyskland (civillagen BGB, entreprenadvillkoren VOB/B, arvodesförordningen HOAI). I andra länder gäller andra regler, och vad som avtalats i byggkontraktet går före de standardfrister som nämns här.
Primär eller stödjande — förhandsbeslutet
Samma programvara kan vara det rätta och det felaktiga valet för två företag. Skillnaden ligger inte i produkten utan i processens roll.
| Kännetecken | Primär värdeskapande process | Stödjande process |
|---|---|---|
| *Så känns den igen* | Kunden betalar just för den | Nödvändig, men utbytbar |
| *Anpassningsriktning* | Programvaran följer processen | Processen följer programvaran |
| *Beslutskriterium* | Passform, även om det tar längre tid | Kostnad, underhållbarhet, införandetid |
| *Risken med fel val* | Att tappa det som skiljer ut företaget | Bundna resurser utan motvärde |
Indelningen är företagsspecifik: för det ena kontoret är byggövervakningen kärnprocessen, för det andra en sidotjänst.
Exempel 1 — när effektiviteten är kärnprocessen
Ett projekteringskontor är känt för särskilt effektiv byggövervakning. Arbetsfördelningen är inarbetad: erfarna byggnadsingenjörer bedömer på plats och dikterar röstmeddelanden, backoffice gör uppgifter av dem. Införs nu ett ärendesystem som avlastar backoffice men belastar byggledningen ytterligare, tippar just den fördel som utmärker kontoret.
- Kalkylen går inte ihopAvlastning på det billiga stället, merarbete på det dyra — det är en förskjutning, ingen förbättring.
- Hellre vänta än förvridaFinns ingen passande lösning är det bättre att avvakta än att fatta ett beslut som skadar kärnprocessen.
- Vad passande programvara gör härRegistrera uppgift och bild i ett steg, anmärkning som röstmeddelande — analysen sköter backoffice som förut.
Exemplet är en illustration, ingen referens — det beskriver ett mönster som återkommer i upphandlingsprojekt.
Exempel 2 — när egenutveckling hamnar på fel ställe
Ett ingenjörskontor har med ett eget bibliotek av installationsmodeller inklusive geometriska beroenden byggt upp ett verkligt försprång. Ur den goda erfarenheten föds idén att också låta utveckla ett system för uppgiftsregistrering. Felet ligger inte i förmågan utan i indelningen: kontoret är känt för installationsprojektering, inte för byggövervakning.
- Resurser på fel hävstångUtvecklingskapacitet som fattas i kärnområdet skapar eftersläpning just där försprånget kommer ifrån.
- För få kunniga i husetDen som inte lever processen dagligen kan varken specificera den eller underhålla den på lång sikt.
- Rätt hade varitEtt kostnadseffektivt standardsystem för den sekundära processen — och den egna utvecklingen där den gör verkan.
Rätt flyghöjd för datahållningen
Den andra urvalsfrågan gäller inte funktioner utan data: vilken information behövs dagligen för att arbeta, och vilken ligger redo som referens? Arbetsdata måste finnas där arbetet sker — mobilt, offline, sökbart på sekunder. Referensdata hör hemma i ett ordnat arkiv, ur vilket de hämtas vid behov. Den som tvingar in båda i samma system får antingen en trög byggplatsapp eller ett arkiv som ingen hittar i.
- Aktivt använtFel, kontroller, foton från den pågående etappen, aktuella ritningar — varje dag, nåbart med få handgrepp.
- Hållet som referensAvtal, äldre ritningsversioner, avslutade etapper — spårbart arkiverade, men inte i vägen.
- Standard plus projektspecifiktEn byggakt som i kärnan är uppbyggd likadant överallt och ändå kan ta upp projektets särdrag.
Frågor som klarar ut ett val snabbare än varje demonstration
Vad betalar kunden oss för?
Svaret pekar ut de processer som inte får anpassas.
Vem matar in data?
System som flyttar registreringen nedåt fallerar på dem som ska registrera.
Fungerar det utan nät?
I stommen är det ingen bekvämlighetsfråga utan villkoret för användning.
Kommer vi ut igen?
Exportformaten avgör om data tillhör projektet eller leverantören.
Vem underhåller det om tre år?
Vid egenutveckling är det den dyraste och oftast obesvarade frågan.
Vad kostar den tionde användaren?
Prismodeller som bestraffar utrullning hindrar precis det som ger nyttan.
Specialist eller generalist
Kvar står den principiella frågan: en heltäckande leverantör som undviker gränssnittsproblem, eller flera specialiserade lösningar som kan mer i sitt segment. Båda går att försvara. Avgörande är var djupet behövs: den som driver byggskedet som kärnprocess behöver djup där och kan undvara det annanstans. Hur det ter sig i jämförelse med andra leverantörer — inklusive frågan när konkurrenten är det bättre valet — står i jämförelsesidorna.
Vad Open Experience är i det sammanhanget
Open Experience är specialisten på byggskedet: fel, foton, dagbok, checklistor och 360°-registrering i en plattform, med egen hårdvara och på fackspråket i Leistungsphase 8, det tyska skedet för byggövervakning. För projektering, kalkyl eller löneadministration svarar andra — och det är ingen lucka, utan beslutet att vara djup i kärnprocessen.
Vanliga frågor
Standard eller egenutveckling — vad är billigare?
Standard nästan alltid vid anskaffningen, egenutveckling nästan aldrig i driften. Den egentliga kostnadsfrågan är inte införandet utan underhållet över fem år.
Hur känner jag igen en primär process?
På att kunderna nämner den när de förklarar varför de arbetar med dig. Allt som är internt nödvändigt men utbytbart hör till den andra gruppen.
Hur många system är för många?
Det är inte antalet som avgör utan överlämningarna. Två system med ett rent gränssnitt är bättre än ett där hälften av arbetet löper vid sidan om.
Vad är en gemensam datamiljö?
En ordnad miljö där alla projektdeltagare kommer åt samma version — med tydlig skillnad mellan arbetsversion, frigiven version och arkiv.
Hur lång tid tar ett införande realistiskt?
Installationen är en fråga om dagar. Omställningen tar ett projekt — framför allt för att de gamla parallellvägarna måste stängas av, inte för att programvaran vore svår.
Var fallerar upphandlingsprojekt oftast?
På två saker: valet gjordes efter funktionslistor i stället för efter processer — och de som dagligen ska registrera var inte med i beslutet.
Källor och rättslig grund
De rättsliga uppgifterna i denna artikel bygger på primärkällorna nedan. Artikeln ersätter inte juridisk rådgivning i det enskilda fallet.
Titta först på dina processer, prata sedan om programvara.
45 minuter utan produktdemonstration: vi sorterar tillsammans med dig vilken process som är ditt konkurrensmedel — och vilken som tål standard.