Hoppa till innehållet

Fråga om projektet

Du är på Vägval. Ställ en fråga med egna ord, så förklarar stödet utifrån projektets öppna sidor.

Vägval

Vägen vi har valt och det som är öppet

Varje vägval, riktning och öppen fråga i projektet, med mötet där den togs upp. Ett vägval är det vi går efter nu och kan ändras längre fram i arbetet. Läget visar hur det står nu; här står allt, och varje post har en fast adress som går att länka till.

  1. Beslutat5Gäller tills vi ändrar det. Ändras ett beslut skrivs det nya in, och det gamla står kvar i historiken.
  2. Riktningar9Det vi lutar åt. Vi arbetar efter det, men det är inte låst.
  3. Öppna frågor16Inte avgjort. Har frågan ett förslag står det med, så att det går att säga emot.

Beslutat 5

Gäller tills vi ändrar det. Ändras ett beslut skrivs det nya in, och det gamla står kvar i historiken.

  1. Allt byggs AI-native.

    AI är första valet i design, utveckling och tjänster. Andra team får krav på API:er som en agent förstår.

  2. Visionen och målbilden är vår riktning.

    Det första utkastet av visionen gäller. Läs visionen →

  3. Externa system ansluter via adaptrar som kommuner delar.

    En adapter per system. Kommun X bygger adapter Y och delar den. Vi bygger mönstret först, inte alla adaptrar.

  4. Byggt för att delas.

    Ingen kommun ska behöva Sundsvalls mikrotjänster, namn eller grafiska profil.

  5. Chefsportalen byggs inom Startsidan.

    Den blir inte en egen portal.

    Togs upp på

Riktningar 9

Det vi lutar åt. Vi arbetar efter det, men det är inte låst.

  • Ett nytt behov blir en modul.

    Vi bygger inte nya HR- eller ekonomisystem.

    Togs upp på
  • Det som berör flest kommer först.

    En HR-process för 800 slår en funktion för 10.

  • Kommunen skickar in användare och organisation med SCIM.

    Ingen app läser metakatalogen direkt.

  • Grundtjänster nås via en adapter.

    Varje kommun kopplar in sin egen tjänst för post, SMS och signering.

  • Vi prototypar först och väljer tekniken sen.

    Det är billigt att göra fel med AI. Den svåra delen är att validera.

  • Allt material hittills är hypoteser.

    Visionen och målbilden kan ändras när vi lär oss mer.

  • Den första prototypen görs från ett blankt papper.

    Befintliga regler prövas först när det finns en målbild.

  • Hassan är testpersonen.

    Fungerar det för honom i mobilen fungerar det för den som sitter vid en dator.

  • Det som kan vara öppet ska vara tillgängligt utan inloggning.

Öppna frågor 16

Inte avgjort. Har frågan ett förslag står det med, så att det går att säga emot.

Frågorna som styr vad vi bygger först

  • Vilket behov prövar vi först?

    Avgörs efter workshopen 8 okt. Regeln: det som berör flest först.

    FörslagUtvecklingssamtal – berör alla chefer och medarbetare; prototyp finns

    Andra svar: Dialogstöd för chef · IT-ingången

  • Vilken väg prövar vi först för intranätet?

    Väckt 6 okt. Vi testar i testmiljön och frågar en Sitevision-specialist.

    FörslagSkript och länk – delbart; fungerar även med andra CMS

    Andra svar: REST i startsidans gränssnitt · Båda i testmiljön först

  • Hur väljer vi lagring för en datamängd?

    Väckt 18 sep. Känsliga personaluppgifter kopieras hellre inte.

    FörslagPer dataklass – live, senast hämtad, länk eller aldrig kopia

    Andra svar: Alltid live · Alltid mellanlagring

  • Hur kopplar vi in AI-motorn?

    Väckt 18 sep. Riktningen 6 okt är Eneo först via öppen standard.

    FörslagEneo först, via öppen standard – OpenAI-kompatibelt och MCP; annan AI ger grundchatt

    Andra svar: Eneo krävs · Fritt val av AI-tjänst

  • Får en prototyp använda verkliga data?

    Väckt 18 sep. Krockar med visionen och måste redas ut.

    FörslagNej, alltid syntetisk data – visionens regel

    Andra svar: Ja, efter beslut om behörighet och säkerhet · Ja, när verksamheten vill

  • Vilken teknik bygger vi med?

    Väljs efter de första testerna. AI-native är urvalsregeln. En kollegas prototyp prövar redan en stack.

Mindre frågor som också är öppna

  • data

    Vilken minsta information behöver en uppgift?

    Ett förslag finns: kontraktet uppgift@1.

  • delning

    Vem äger och förvaltar en delad adapter?

    Delningen är beslutad. Ägarskapet är inte det.

  • säkerhet

    Hur fungerar identitet på en delad enhet?

    Många i omsorgen saknar egen dator.

  • AI

    Vilka data får AI använda i varje roll?

    Och vad loggas?

  • förvaltning

    Vem har drift, support och förvaltning?

    Gäller både startsidan och delade delar.

  • nytta

    Hur mäter vi att det ger nytta?

    Vi behöver en baslinje innan vi börjar.

  • idé

    Behövs en egen masterkalender?

    En idé för nämndprocesser. Behovet är inte prövat.

  • intranätet

    Hur hänger version 1.0 ihop med intranätet?

    Startsidans första version ska vara klar till årsskiftet, intranätet lanseras i maj. De får inte uppfattas som två olika saker. En tanke: börja med chefen och testgrupper med chefer.

  • chefsportalen

    Vad ska chefsportalen innehålla?

    Kommunstyrelsen har beslutat att den ska genomföras, men inte vad den ska innehålla. Dialogstödet för chef ska in – vad mer?

  • kommunikation

    Hur ser kommunikationsplanen ut?

    Projektet prövar nya vägar, och olika verksamheter behöver olika insatser.

Arkitekturbeslut 40

De tekniska besluten för den som bygger, skrivna som korta ADR:er. Hela texten och skälen står i devportalens beslutsregister.

  1. ADR-040Projektportalen och startsideportalen är två applikationer på en domänAntagen
  2. ADR-039Konton för projektgruppen – användarnamn och lösenord, först för att göra-listanAntagen
  3. ADR-038Funktionerna läggs till på sidan och via API, och bor i databasenAntagen
  4. ADR-037En ändringslogg i startsidans databasAntagen
  5. ADR-036Att göra-listan redigeras på sidan och bor i en SQLite-filAntagen
  6. ADR-035Notiser till teamschatten via ett flöde i Power Automate, avstängda tills de slås påAntagen
  7. ADR-034Projektstödet svarar bara utifrån projektets öppna sidorAntagen
  8. ADR-033Projektets meny är en klassisk huvudmeny enligt WCAG 2.2 AAAntagen
  9. ADR-032Projektet är roten, med statusrapporter och funktionernaAntagen
  10. ADR-031Projektboken ordnas efter typ, inte efter tillfälleAntagen
  11. ADR-030Kompetens är ett register, inte ett LMSAntagen
  12. ADR-029Projektets sida på roten, prototypen på /portalAntagen
  13. ADR-028Workshoprösten – röstkoder utanför spärren, prickar i en filAntagen
  14. ADR-027Målgruppsingång – Verktygslådan under Digitalisering, IT och AIAntagen
  15. ADR-026AI tonas i blått, inte grönt – grönt är bara statusAntagen
  16. ADR-025Modulvyer över hela arbetsytan, och genvägar bredvid hälsningenAntagen
  17. ADR-024Verktyg, skills och MCP-tjänster i Min AIAntagen
  18. ADR-023Min AI – en personlig assistent med Eneos sessionskontraktAntagen
  19. ADR-022Ingångens egna kort och hopfällbara block – IT-support som första sidaAntagen
  20. ADR-021Fokusytan under AI-fältet på startsidanAntagen
  21. ADR-020Notiserna kommer från modulerna och leder till funktionerAntagen
  22. ADR-019Modulvyer med skalets krom och vägparametrarAntagen
  23. ADR-018Användaren ordnar korten på startsidanAntagen
  24. ADR-017En Sitevision-webbplats inramad i skaletAntagen
  25. ADR-016PageManifest med källoberoende innehållAntagen
  26. ADR-015Dokumentflöden definieras som data i modulenAntagen
  27. ADR-014Portalens påståenden verifierasAntagen
  28. ADR-013Signerad fältförankring mellan turerAntagen
  29. ADR-012Åtkomstkod som demospärrAntagen
  30. ADR-011Dokumentation som leveransvillkorAntagen
  31. ADR-010Devportalen som ingång för människa och agentAntagen
  32. ADR-009Designsystemet som dataAntagen
  33. ADR-008shadcn/ui som komponentgrundAntagen
  34. ADR-007Aggregerande modulerAntagen
  35. ADR-006Rollen i cookie; moduler hämtar egen dataAntagen
  36. ADR-004routes + fokusläge i ModuleManifestAntagen
  37. ADR-003"Sidor" är en egen sidtypAntagen
  38. ADR-002Egen designgrund istället för @sk-web-guiErsatt
  39. ADR-001App Router istället för Pages RouterAntagen
  40. ADR-005Flödesmotorns kontraktSkrivs
Hela beslutsregistret i devportalen →
Besluten och frågorna skrivs in i samma commit som mötet läggs i tidslinjen. Ändras ett beslut läggs mötet där det ändrades till på posten.