I augusti 2026 rapporterade Nordiska Projekt att 85 % av svenska industriföretag ännu inte har tagit AI bortom pilotstadiet.
Läs det som en siffra om pilotprojekt snarare än om AI. Att komma till ett pilotprojekt är inte det svåra. Någon hittade ett användningsområde, någon hittade en budgetpost, någon körde det, och sedan tog det stopp. I fem fall av sex tog det stopp.
Något händer mellan pilotprojektet och utrullningen, så regelbundet att det är ett mönster och inte otur. Det är värt att fråga vad.
Ett projekt som aldrig blir klart
Fråga de flesta tillverkande företag vad som står mellan pilotprojektet och utrullningen när det gäller AI i underhåll, så får du någon variant av samma svar: datan är inte redo.
Fråga vad som skulle göra den redo, så slutar svaret vara konkret.
Det är själva problemet. ”Få ordning på datan först” är det vanligaste rådet om AI i industrin, och det är ingen uppgift. Det finns ingen definition av klart, ingen som kan förklara det avslutat och inget test du kan göra en vanlig tisdag för att se om du är framme. Varje ärligt försök att avgränsa det ger ett större projekt än det som det skulle bana väg för: först ett datalager, sedan nya felkoder, sedan en rensning av historik som inte passar de nya felkoderna.
Ett pilotprojekt är litet nog att slippa undan det. Det körs på en linje, med data som någon har rensat för hand inför tillfället. Det gränslösa projektet väntar vid utrullningen, och det är precis där de 85 procenten står.
Rådet hjälper alltså inte bara inte. Det är en rimlig förklaring till att siffran ser ut som den gör: en organisation som ska slutföra en oändlig uppgift innan den börjar på en ändlig gör ingen av dem.
Ingen vägrar
Det är värt att vara tydlig med att det här inte är ett disciplinproblem, eftersom det oftast diagnostiseras som ett.
Nästan varje underhållssystem som byggts de senaste tjugo åren ber om samma sak när en arbetsorder avslutas: klassificera den. Vilken typ av fel, vilken komponent, vilken orsak. Leonard Lin, som ansvarar för Manufacturing Intelligence på Maintmaster, sammanfattar vad det ledde till: ”Ingen gör det, det är alldeles för mycket jobb.”
Titta på vad som begärdes. Några sekunders klassificeringsarbete, flera hundra gånger i veckan, av någon vars skift just har tagit slut. Korrekt, i all oändlighet och utan att någon någonsin berättar om det blev rätt. Det klarar ingen personalstyrka, och ingen har någonsin gjort det. Kravet var orimligt, och det var orimligt på ett sätt som inte syntes från kontoret.
Därför är varje plan vars första steg är den här gången fyller alla i fälten ordentligt samma plan som gav dig den data du redan har.
Det finns en andra halva av det här, och den går åt andra hållet. Leonards förklaring till att så lite underhållshistorik är värd att läsa är inte att folk skrev dåligt, utan att ingen någonsin läste den. En registrering som ingen tittar på har ingen haft skäl att skriva ordentligt. Kvaliteten kommer av användningen. Den kommer inte före.
Lägg ihop de två halvorna, så är ”få ordning på datan först” inte bara gränslöst. Det motverkar sig självt. Rådet ordinerar väntan, och väntan är själva mekanismen. En organisation som väntar med att läsa sina registreringar tills de är värda att läsa håller igång just den process som hindrar dem från att bli det.
Vad pilotprojektet faktiskt bevisade
Här är det värt att stanna upp. Ett pilotprojekt som fungerade, på data som du nu beskriver som inte redo, har redan sagt dig något: datan var tillräckligt bra för det.
Det går eftersom kravet på struktur har sjunkit. Fritext går att läsa nu. Klassificeringen behöver inte vara fullständig eller konsekvent, eftersom analysen inte längre är beroende av den för att förstå innehållet. Det är en verklig förändring, och de flesta råd på marknaden skrevs innan den kom.
Det som inte har förändrats är att händelsen måste vara registrerad över huvud taget. Det är ett annat krav än ren data, och ett mycket lägre. Men det är inte noll, och det är det kravet som är värt att mäta mot.
Vilka av dina registreringar som klarar det är en fråga med ett verkligt svar, och det tar en eftermiddag att ta reda på, inte ett storprojekt: vad AI kan förlåta i din underhållsdata, och vad den inte kan är testet.
Ett avgränsat första steg
Det vettiga draget här är inte ett större dataprojekt. Det är ett mindre, med ett slut.
Vad ditt pilotprojekt än bevisade, så bevisade det det på ett avgränsat urval av data. Avgränsa alltså nästa urval. En linje, en typ av utrustning, en fabrik: ett omfång där du kan säga vad ”registrerat” betyder och kontrollera om det stämmer. Inte ett program där målet är att ett problem ska vara borta.
Det är ett beslut som en produktionschef kan fatta och genomföra. ”Få ordning på datan” är det inte, och efter två år utan att bli klar med det är de 85 procenten inte förvånande.
Det omfånget lämnar en fråga öppen: hur komplett urvalet måste vara innan det säger dig något att läsa det. Ribban ligger lägre än de flesta team tror. Enligt Leonard kan du börja med mellanbra data. Säg att 50 % av de avslutade arbetsordrarna innehåller både felet och vad som gjordes åt det, eller att alla anger felet men ingen anger åtgärden. Ingen skulle försvara något av dem som ren data, och i båda syns ändå de problem som är värda att åtgärda. Det är nämligen de problem som återkommer, och upprepning överlever ett ofullständigt urval. Det du får är en riktning: vilka maskiner och vilka återkommande fel som förtjänar uppmärksamhet, inte hur stora de är. För att bestämma var du ska titta härnäst är det allt som krävs.
Det är argumentet för att läsa tidigt i stället för sent. Börja halvvägs och låt det som läsningen visar styra hur registreringen blir bättre. Manufacturing Intelligence finns till för att korta den resan, och kräver ingen nivå som du måste nå innan det är till nytta.
Att avgränsa det handlar mest om att skriva ner tre saker innan du börjar. Ingen av dem kräver ett beslut om plattform:
- Var. En linje, en typ av utrustning, en fabrik. Inte ”underhållet”.
- Vad som räknas som registrerat. En mening du kan ge till en tekniker och en arbetsledare och som båda håller med om. Kan du inte skriva den är omfånget fortfarande för stort.
- När du ska titta. Ett datum i kalendern då du läser ett urval och ser om svaret har förändrats. Inte en milstolpe, utan en genomläsning.
Det tredje är det som brukar falla bort, och det är det som gör det här till ett projekt med ett slut. Utan det finns inget ögonblick då någon kan säga att det fungerade, så omfånget växer i det tysta för att fylla tomrummet. Det är samma misstag som ”få ordning på datan först”, bara i mindre skala.
Inget av detta är ett AI-beslut. Det är den vanliga disciplinen att avgränsa en förändring på golvet, tillämpad på registrering i stället för på en maskin. Skälet att skriva ut det är att AI-perspektivet gärna sätter den disciplinen ur spel: team som aldrig skulle godkänna ett gränslöst underhållsprojekt godkänner ett gränslöst dataprojekt, eftersom dataprojektet låter som förberedelse och inte som arbete.
Om det ärliga svaret på frågan registreras händelsen i ett system när den inträffar? är nej, om den finns i en skiftbok, ett Excelark eller ett samtal, då är det just det som är det avgränsade projektet. Och det är mindre än det du var på väg att planera. Maintmaster CMMS är ett sätt att registrera vad som hände och vad som gjordes åt det, direkt där arbetet görs. Det är den informationen som varje senare analys bygger på.
Börja där. Det har ett slut, och det är hela skillnaden.