Assistent för överlämning Projekt till Objekt är ett fristående verktyg för dig i projektet – inte för mottagande objekt. Det hjälper dig samla ihop allt mottagande objekt (Objektledare, Objektledare IT, specialister) behöver för att ta över projektets leveranser i löpande basförvaltning: vad som levererats, vilka som ska förvalta det, en grov uppskattning av återkommande arbete, och vad som eventuellt inte är klart.
Vem är verktyget till för?
Vad verktyget INTE gör
- Det ersätter inte dialogen mellan projekt och objekt – det strukturerar underlaget för den dialogen.
- Det gör ingen detaljerad, exakt tidsuppskattning – bara en grov, vägledande t-shirt-uppskattning. Den riktiga, löpande uppskattningen görs av mottagande objekt i Assistent UFM Basförvaltning.
- Det sparar ingenting på en server. All data finns bara i din webbläsare tills du själv laddar ner en fil (se 🔒 Säkerhet & autospar).
Verktyget har sex flikar som fylls i i valfri ordning, men det är enklast att börja från vänster och arbeta sig genom dem i tur och ordning första gången:
Kärn-/stödobjekt eller IT-objekt?
Direkt i Grunduppgifter väljer du objekttyp. Valet styr vilken terminologi och vilken uppskattningsmodell som används resten av verktyget:
| 📦 Kärn-/stödobjekt | 🖥️ IT-objekt | |
|---|---|---|
| Mottagande enhet kallas | Objektprodukt | IT-tjänst |
| Projektets leverans kallas | Digitalt stöd | Teknisk komponent |
| Uppskattningsmodell | En uppsättning uppgifter per digitalt stöd | Tjänst med delområden, se egen sektion |
| Roller | Objektledare + Objektledare IT | Bara Objektledare IT ("enbent") |
Fliken där allt annat utgår ifrån. Fyll i i den här ordningen:
Vet du inte det exakta namnet?
Det är vanligt att projektet inte känner till exakt vilket namn mottagande objekt använder internt för en enhet, ett digitalt stöd eller en person. Skriv in ditt bästa förslag och markera fältet med ❓ Osäkert – se ❓ Osäkra namn för hur det hjälper mottagande objekt vid import.
Namngivning som gör skillnad
En grov, vägledande uppskattning av hur mycket återkommande arbete varje leverans kommer kräva av mottagande objekt efter övergången – inte en exakt tidmätning. Modellen skiljer sig åt mellan kärn-/stödobjekt och IT-objekt.
T-shirt-modellen
Alla uppgifter uppskattas på samma enkla skala, oavsett objekttyp:
Kärn-/stödobjekt: en uppgiftslista per digitalt stöd
Har du flera digitala stöd namngivna i Grunduppgifter väljer du vilket du fyller i via flikarna högst upp i sektionen. Varje stöd får sin egen, helt fristående uppsättning uppgifter grupperade under Samverkan, Användarstöd, Ändringshantering och Drift & underhåll.
- Namngiven specialist eller "Ej utsedd" – kryssa i "Ej utsedd" om ni vet att uppgiften behöver en specialist men inte vem än.
- Flera specialister på samma uppgift? Lägg till fler rader – var och en får då sin egen storlek istället för en delad.
- Bor stödet i flera objektprodukter? Koppla varje specialist till rätt objektprodukt så ansvarsbadgen (⭐ Huvudansvar / 🤝 Delat ansvar / 👁️ Kännedom) visas korrekt.
IT-objekt: tjänst med delområden
IT-tjänster uppskattas annorlunda – se hela genomgången i 🖥️ IT-tjänster – delområden nedan.
För IT-objekt uppskattas en tjänst som en helhet, och delas sedan upp i delområden – samma modell som Assistent UFM Basförvaltning använder löpande, så uppskattningen går rakt in utan omräkning vid import.
Vad är ett delområde?
Ett delområde är ett ansvarsområde inom tjänstens basförvaltning – till exempel "Wi-Fi-drift" eller "Behörighetshantering". Det är inte nödvändigtvis samma sak som en teknisk komponent i Grunduppgifter, även om de ofta råkar likna varandra. Har tjänsten bara en sammanhållen leverans behövs inga delområden alls.
Tre steg – så räknas tiden ut
Specialister kopplas till delområdet – inte till varje uppgift
Det här är den viktigaste skillnaden mot att fylla i en specialist på varje enskild uppgiftsrad: lägger du till en specialist på ett delområde räknas hen automatiskt med på alla uppgifter det delområdet deltar i. Du behöver aldrig skriva in samma namn flera gånger.
Exkludera delar från en enskild uppgift
Ibland gäller en uppgift bara vissa delområden – t.ex. är "Licenshantering" kanske bara relevant för ett av två delområden. Klicka "🚫 Exkludera delar" under uppgiften och kryssa i de delområden som inte ska räknas in. De kvarvarande delarna delar då på hela uppgiftens tid.
Det är vanligt att projektet inte vet exakt vad en mottagande enhet, ett digitalt stöd, ett delområde eller en specialist officiellt heter i mottagande objekts egna system. Istället för att gissa eller skriva en platshållartext som "TBD" rakt i namnfältet, kan du markera fältet med badgen ❓ Osäkert.
Var finns markeringen?
Bredvid varje namnfält som faktiskt förs vidare till Assistent UFM Basförvaltning: mottagande enhet, digitalt stöd/teknisk komponent, delområde (IT) och specialister. Klicka på ❓ för att slå på/av markeringen.
Vad händer sedan?
När mottagande objekt importerar din fil i Assistent UFM Basförvaltning visas en granskningsvy innan något läggs till. Allt du markerat som osäkert visas där med en tydlig varningstext, så objektledaren vet exakt vilka poster som bör dubbelkollas eller mappas om till rätt befintlig post – istället för att en felstavning eller ett preliminärt namn tyst skapar en dubblett.
En färdig checklista över vad ett projekt normalt förväntas leverera till förvaltning, uppdelad i fyra grupper: Verksamhetsnära Basförvaltning, IT-nära Basförvaltning, Påverkan på Basförvaltning, samt Avtal och övriga dokument.
- Status – Ej påbörjad / Pågår / Klar, per post.
- Markera "Ej aktuellt" för poster som inte gäller det här projektet – de räknas då bort från klar-andelen istället för att stå kvar som "ej klara".
- Ansvarig, kommentar och dokumentation går att fylla i per post.
En genomgång av vad varje post i Leveranschecklistan normalt innehåller och varför mottagande objekt behöver den. Använd som stöd när ni går igenom checklistan tillsammans - länkad direkt från fliken Leveranschecklista i verktyget.
🧑🏫 Verksamhetsnära Basförvaltning
| Leverans | Innehåller normalt | Varför det behövs |
|---|---|---|
| Beskrivningar av verksamhetsprocesser | Hur arbetet faktiskt görs steg för steg efter förändringen - gärna som flödesschema. | Så mottagande verksamhet vet vad som förväntas av dem i vardagen, inte bara vad systemet tekniskt gör. |
| Kunskapsstöd (användarmanualer m.m.) | Instruktioner för hur användare hanterar systemet/tjänsten i sin vardag. | Nya medarbetare kan lära sig själva utan att behöva fråga projektet, som snart inte längre finns kvar. |
| Utbildningsmaterial till användare | Presentationer, övningar och snabbguider som användes vid införandet. | Kan återanvändas av förvaltningen vid t.ex. nyanställning, utan att behöva tas fram från grunden. |
| Begrepps- och informationsmodeller | Definitioner av centrala begrepp och hur information hänger ihop. | Så alla pratar om samma sak, och förvaltningen vet var olika information hör hemma. |
| Mallar och formulär | Standardiserade dokument/blanketter som används i det dagliga arbetet. | Verksamheten slipper återuppfinna dem, och de förblir konsekventa över tid. |
| Kravspecifikationer | De ursprungliga kraven som styrde vad som byggdes eller upphandlades. | Ger svaret på VARFÖR lösningen ser ut som den gör - avgörande när framtida ändringsbehov ska bedömas. |
| Uppgifter kopplade till nyttorealiseringsplanen | Vilka effekter/nyttor som ska följas upp, ofta en rapportbeställning till leverantören. | Så nyttan av investeringen faktiskt går att mäta i efterhand, inte bara antas. |
| Testfall och protokoll från acceptanstester | Vad som testades och resultatet, godkänt av verksamheten. | Bevis på att lösningen fungerar som avsett innan förvaltningen tar över ansvaret för den. |
| Säkerhetsdokumentation | Informationsklassning och behörighetsmatris/-rutin. | Krävs för att förvaltningen ska kunna hantera behörigheter korrekt även långt efter införandet. |
| Presentation för användargrupper | Materialet som visades för slutanvändarna vid lansering. | Kan återanvändas vid introduktion av nya användare, eller som repetition. |
| Information om ändringar till målgrupper | Vad som kommunicerats till t.ex. användare/helpdesk om förändringen. | Förvaltningen vet vad målgrupperna redan informerats om, och undviker att motsäga det. |
| Tillgänglighetsredogörelse | Lagstadgat dokument (DOS-lagen) om hur digital tillgänglighet uppfylls. | Krävs enligt lag för digitala tjänster riktade till allmänheten, och måste hållas uppdaterad löpande. |
🖥️ IT-nära Basförvaltning
| Leverans | Innehåller normalt | Varför det behövs |
|---|---|---|
| High level design (arkitekturöversikt) | En pratbar, visuell systemöversikt: teknikval, masterdata, integrationer, säkerhetsåtgärder, drift och nätverkszoner. Se C4-modellen (c4model.com) för ett lättillgängligt sätt att bygga en. | Ger förvaltningen en helhetsbild utan att behöva läsa all detaljdokumentation - den bild man visar när någon frågar "hur hänger det här ihop?". |
| Funktions- eller systemdokumentation | Detaljerad beskrivning av hur systemet fungerar tekniskt: funktioner, dataflöden, komponenter. | Den tekniska källan till sanning som drift och utveckling behöver för att felsöka och vidareutveckla. |
| Beskrivningar av integrationer | Vilka system som pratar med vilka, via vilket gränssnitt/protokoll, och vilken data som utbyts. | Utan detta blir varje integrationsstörning ett detektivarbete istället för snabb felsökning. |
| Säkerhetsdokument | Genomförda säkerhetsanalyser, penetrationstester och sårbarhetsbedömningar. | Underlag för att bedöma och hantera kvarvarande risker, och veta vad som redan är kontrollerat. |
| Tekniska kravspecifikationer | De tekniska (icke-funktionella) kraven: prestanda, skalbarhet, drifttider m.m. | Referenspunkt för att avgöra om systemet fortfarande presterar som avsett över tid. |
| Testrapporter och testfall | Genomförda tekniska tester (funktions-, prestanda-, säkerhetstester) och resultat. | Bevis på teknisk kvalitet vid överlämningen, och underlag för regressionstestning vid framtida ändringar. |
| Driftdokumentation | Hur systemet faktiskt drivs i vardagen: övervakning, backup, återstart, larmhantering. | Den operativa handbok driftpersonal behöver för att hålla systemet igång. |
| Installationsdokumentation | Steg-för-steg för att installera/konfigurera systemet från grunden. | Kritiskt vid katastrofåterställning, eller om systemet behöver sättas upp på nytt. |
| IT-komponenter | De faktiska tekniska artefakterna: kod, konfigurationsfiler, licensnycklar, källkodsrepon. | Så förvaltningen faktiskt FÅR det som byggdes - inte bara dokumentation om det. |
| Presentation av nya/vidareutvecklade komponenter | Teknisk genomgång riktad mot mottagande IT-personal. | Ger driftteamet en snabb överblick utan att behöva läsa all dokumentation från noll. |
| Avvecklingsplan | Hur systemet/komponenten avvecklas den dag den tas ur bruk, inklusive dataarkivering. | Säkerställer att avveckling inte blir ett improviserat projekt långt senare, utan historik. |
⚖️ Påverkan på Basförvaltning
| Leverans | Innehåller normalt | Varför det behövs |
|---|---|---|
| Specifika krav på förvaltningsuppdraget | Konkreta förändringar i vad förvaltningen behöver göra löpande, t.ex. mer manuell hantering. | Bemanning och rutiner kan anpassas INNAN problemet uppstår, inte efteråt. |
| Förväntat behov av användarstöd | Uppskattning av support-/utbildningsinsatser initialt och löpande. | Underlag för att dimensionera supportfunktionen rätt från start. |
| Förväntade volymer (lagring) | Hur mycket data/lagringsutrymme lösningen förväntas kräva, och hur det växer. | Så infrastrukturen inte blir underdimensionerad efter några månaders drift. |
| Påverkan på licenser | Nya eller förändrade licensbehov (kostnad, antal, typ). | Förvaltningen budgeterar rätt och upptäcker inte en licensbrist i efterhand. |
| Loggade incidenter under interimsperiod | Problem som redan inträffat under en eventuell övergångsperiod, och hur de löstes. | Samma problem "upptäcks" inte på nytt och löses annorlunda andra gången. |
| Införandeplan för kvarvarande installationer | Om utrullningen inte är helt klar: plan för resterande installationer/platser. | Förvaltningen vet vad som återstår, istället för att anta att allt redan är klart. |
📄 Avtal och övriga dokument
| Leverans | Innehåller normalt | Varför det behövs |
|---|---|---|
| Service level agreement (SLA) | Avtalade svarstider, tillgänglighet och kvalitetsnivåer med leverantör/driftpart. | Grunden för att kunna ställa krav på och följa upp leverantörens prestation. |
| Avtal med supportorganisation | Vem som svarar på användarfrågor, hur, och inom vilken tid. | Förvaltningen vet vart ärenden ska eskaleras. |
| Avtal med driftpart/-er | Vem som ansvarar för att systemet faktiskt är igång, och för vad. | Tydliggör ansvarsgränsen mellan kommunen och driftleverantören. |
| Avtal med leverantörer av applikation | Licens-, underhålls- och supportavtal med den som levererat applikationen. | Grund för att veta vilka rättigheter/skyldigheter som gäller vid t.ex. buggar eller vidareutveckling. |
| Projektdirektiv och projektplan | Projektets ursprungliga uppdrag, mål och avgränsningar. | Historisk kontext för VARFÖR projektet gjordes - användbart vid framtida beslut om vidareutveckling. |
| Kvalitetsgranskningsrapporter/revisioner | Genomförda granskningar av projektets leveranser eller arbetssätt. | Visar vad som redan kontrollerats och inte behöver granskas igen. |
| Systemöversikt (digitala stöd i objektet) | Den kommunövergripande Excel-listan över digitala stöd - fylls i av objektledare IT. | Håller kommunens samlade systemkarta uppdaterad när något nytt tillkommer. |
| Dokumentation av AI-användning i leveransen | Var AI-funktionalitet ingår, i vilket syfte, och ev. riskklassificering. | Krävs av EU:s AI-förordning för öppenhet mot slutanvändare, se separat sektion om osäkra namn. |
En lista över personer mottagande objekt kan behöva kontakta efter övergången – superusers, projektets tekniska kontaktperson, leverantörskontakter och liknande. Ange roll, vad personen är kopplad till, kontaktuppgifter och vad som förväntas av dem.
Sådant som inte är klart hanterat vid överlämningen – ofullständiga leveranser, kända begränsningar eller uppskjutna frågor. En avgränsning i taget: vad den gäller, risker om den inte hanteras i tid, och vem som driver frågan vidare.
- Deadline och ägare – vem äger uppföljningen och till när.
- Risk (Sannolikhet × Konsekvens) – ger ett riskvärde som hjälper till att prioritera.
- Resursbehov – poängsätts och beskrivs i fritext.
- Leverantörsåtagande – om något ligger kvar hos en extern leverantör att lösa.
Den sista fliken, där allt ni fyllt i knyts ihop till konkreta leveranser: ett beslutsunderlag, en sammanfattning, och själva importfilen till mottagande objekt.
AI-genererat utkast
Fliken kan generera ett textutkast till rapportens fritextavsnitt (sammanfattning, målgrupper, funktionalitet, förväntade resultat med mera) baserat på det ni redan fyllt i. Alla namn pseudonymiseras innan något skickas – se 🤖 AI-coacherna för hur det går till. Utkastet är ett förslag att redigera vidare, inte ett färdigt beslutsunderlag.
Innan du exporterar
- Kontrollera att alla mottagande enheter faktiskt är namngivna – onamngivna enheter tas inte med.
- Gå igenom ❓-markeringarna en sista gång – ju färre osäkra namn desto smidigare import.
- Stäm av med objektledaren att övergångsdatumet och grunduppgifterna stämmer.
På fliken Uppskattning finns en flytande knapp för att fråga en AI-coach – IT-driftcoachen för IT-objekt, basförvaltningscoachen för kärn-/stödobjekt. Samma två coacher som finns i Assistent UFM Basförvaltning, med samma kunskap om UFM-modellen, roller och (för IT) hur delområden räknas.
Coachen hjälper dig resonera dig fram till rätt t-shirt-storlek genom att ställa följdfrågor om vad som brukar hända en vanlig månad – istället för att du ska gissa en siffra rakt av.
🔗 Coacherna känner till båda verktygen och båda guiderna
Coacherna vet att det finns två verktyg och två användarguider – det här överlämningsverktyget och Assistent UFM Basförvaltning (huvudassistenten) – och hur de hänger ihop. Frågar du t.ex. “Hur tar mottagande objekt emot filen?” eller “Var läser jag om resurslistan?” får du ett kort svar med klickbara länkar (öppnas i ny flik) till rätt verktyg eller rätt avsnitt i rätt guide.
🔒 Integritetsskydd – pseudonymisering
Tjänsten pseudonymiserar automatiskt alla namn innan de skickas till AI-tjänsten. "Anna Larsson" blir "Specialist 1" i kommunikationen med AI:n – verkliga namn stannar enbart i din webbläsare.
När AI-coachen används första gången aktiveras en grön indikator 🔒 X namn skyddade. Klicka på den för att öppna integritetspanelen med en förteckning över vilka namn som skyddas och vad de ersatts med.
🛡️ Inbyggda begränsningar och skydd
Det här verktyget slutar där exportfilen tar vid. Så fortsätter arbetet i Assistent UFM Basförvaltning (huvudassistenten) – bra att känna till så att projektet förbereder rätt saker. Huvudassistenten har egen användarguide: ufm-userguide.pages.dev.
Vad följer med – och vad gör inte det?
| Följer med in i huvudassistenten (.json) | Följer bara med i Word-dokumenten |
|---|---|
| Mottagande enheter (objektprodukter/IT-tjänster), digitala stöd/tekniska komponenter, delområden (IT), specialister, uppskattning och ansvarsfördelning. | Kontaktpersoner, avgränsningar, verksamhetsansvarig, leveranschecklistan och beslutsunderlaget. |
Läs mer i huvudassistentens guide
- Importera överlämnat projekt – granskningsvyn och vad som händer vid matchning, steg för steg.
- Objektets resurser – hur namn samlas och rättas på ett ställe.
- Överlämning från projekt – samma sammanhang sett från mottagande objekts håll.
Knappen 👓 Tillgänglighet finns i den blå raden högst upp, till vänster om 📖 Användarguide. Där ställer du in hur verktyget ska se ut och bete sig för just dig. Ändringarna syns direkt, du behöver inte ladda om något.
Färdiga lägen
| Läge | Passar dig som … |
|---|---|
| ↺ Original | vill ha verktygets vanliga utseende. Används också för att återställa. |
| 🔠 Stor text | behöver större text men vill behålla färgerna. |
| ◻️ Hög kontrast – ljus | ser nedsatt och vill ha svart text på vitt, kraftiga kanter och tydlig fokusmarkering. |
| ◼️ Hög kontrast – mörk | är ljuskänslig eller läser bäst med ljus text på mörk botten. |
| 🔠 Stor text – hög kontrast ljus | behöver både stor text och hög kontrast – svart text på vitt, 150 % textstorlek och luftiga rader. |
| 🔠 Stor text – hög kontrast mörk | behöver både stor text och ljus text på mörk botten – 150 % textstorlek och luftiga rader. |
| 📖 Lässtöd | läser mycket eller har läs- och skrivsvårigheter – krämvit bakgrund, lättläst typsnitt och mer luft. |
| 🍃 Lugnt läge | lätt blir distraherad eller störs av rörelse – inga animationer och dämpade färger. |
| 🎨 Egen | vill ställa in själv. Ändrar du något i ett färdigt läge blir profilen automatiskt Egen. |
Det här kan du ställa in
- Textstorlek 80–200 %, typsnitt (bl.a. Atkinson Hyperlegible som är framtaget för synsvaga, och Lexend), radavstånd och luftigare text.
- Färger: bakgrund, förgrund (kort och paneler), zebrarader, text, dämpad text, rubriker och länkar, kantlinjer, sidhuvud, text på sidhuvud och fokusmarkering.
- Kontrastkontroll: fönstret räknar ut kontrasten mellan dina färger och visar ✅ eller ⚠️ mot kraven i webbriktlinjerna (WCAG 2.1 AA, som lagen om tillgänglighet till digital offentlig service – DOS-lagen – hänvisar till): minst 4,5:1 för text och 3:1 för fokusmarkering. Alla färdiga lägen klarar kraven.
- Understrukna länkar, tydlig fokusmarkering för dig som använder tangentbordet, större klickytor och minska rörelse.
- Coachen svarar på klarspråk: kortare meningar, färre facktermer och det viktigaste först (se 🤖 AI-coacherna).
💾 Spara och läsa in din profil
Inställningarna sparas inte i överlämningsfilen. De sparas i en egen liten fil – en tillgänglighetsprofil – som bara innehåller dina visningsinställningar. Därför får andra som öppnar samma överlämningsfil sitt eget utseende, och underlaget påverkas inte.
Verktyget skickar aldrig data till någon server förutom vid AI-anrop (pseudonymiserat, se ovan) och vid export (då du själv laddar ner filen).
Autospar
Ett automatiskt utkast sparas i webbläsarens sessionStorage – inte på disk – med jämna mellanrum. Det ersätter inte att du själv sparar en .json-fil (knappen "Spara"), utan skyddar bara mot att arbete går förlorat om fliken stängs eller webbläsaren kraschar av misstag inom samma flik-session. sessionStorage töms automatiskt när fliken stängs.
Öppnar du verktyget igen och ett autosparat utkast hittas erbjuds du att återställa det, eller ignorera det och börja om.
Spara och fortsätta senare
Klicka "Spara" för att ladda ner en .json-fil med allt du fyllt i. Ladda upp samma fil igen (i det här verktyget, inte i Assistent UFM Basförvaltning) för att fortsätta där du slutade – även i en annan webbläsare eller på en annan dator.