Hoppa till innehållet
Sundsvalls kommunMin startsida, till första sidanLogga in

Fråga om projektet

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

En ingång till hela arbetsdagen

Visionen är en digital vardag där medarbetare och chefer i Sundsvalls kommun möter en enda, personlig ingång: en startsida som vet vem du är, bevakar det som väntar och förbereder det som behövs. Så att mer av arbetsdagen går till kärnuppdraget.

Syftet

En väg in till rätt stöd när det behövs, för varje medarbetare.

Min startsida ska vara den enda ingång medarbetare och chefer behöver för att hitta, förstå och göra det som hör till deras arbete, utan att behöva känna till systemen bakom. Startsidan ska själv påminna om, visa och förbereda det personen behöver, så att ingen ska behöva minnas, bevaka eller leta på egen hand.

Samma innehåll som den här sidan, i helskärm. Piltangenterna bläddrar.

Nuläge

Många system, och du håller ihop dem

  • Den digitala vardagen är utspridd över ett stort antal system, gränssnitt och inloggningar.
  • Ett vanligt arbetsmoment, som att hitta rätt rutin vid rätt tidpunkt, kräver navigering mellan flera system och många klick.
  • Medarbetaren bär själv ansvaret att komma ihåg, bevaka och hitta rätt.
  • Stödet är generellt, inte anpassat till roll och situation.

Problembild

Det kostar tid, och det kostar kvalitet

  • Tid går till att leta, logga in och sammanställa i stället för till verksamhetens kärna.
  • Tidsgränser hänger på den enskildes minne. Missas de blir det fel i rehabilitering, attester och uppföljning.
  • Underlag letas fram och sammanställs för hand, olika beroende på vem som gör det.
  • Varje nytt verksamhetsbehov har mötts med ett upphandlat standardsystem: månader eller år senare finns ännu ett gränssnitt att lära sig, och verksamheten anpassar sig efter verktyget.
  • AI är en ambition, men det finns ingen plats i vardagen där den används säkert och styrt.

Mål

Förenkla vardagen och frigöra tid för medarbetare och chefer, så att mer av arbetsdagen går till kärnuppdraget.
  • Färre moment, färre system, mindre letande
  • Färre missade frister och mer likvärdig hantering
  • Kortare väg från behov till driftsatt tjänst
Det övergripande målet för initiativet Startsida för medarbetare och chef, inom fokusområdet Effektivare och smartare verksamhet.

Varför nu? Kommunkoncernen tog redan 2022 fram en målbild där allt var samlat för medarbetaren och chefen, men den bedömdes inte gå att genomföra: tekniken räckte inte och kostnaden var för hög. Det som förändrats är AI. Med den går det att bygga en rollbaserad, interaktiv och förenklande startsida, och att bygga den själva, i egen takt.

Från nuläge till önskat läge

Fyra förflyttningar

Förflyttningen initiativet ska skapa går att beskriva som fyra lägen. De är samtidigt måttet på om startsidan lyckas.

Från

Många system, gränssnitt och inloggningar. Den som ska utföra ett vanligt arbetsmoment navigerar själv mellan dem.

Till

En ingång

En personaliserad, rollbaserad ingång där bakomliggande system inte behöver kännas till.

Från

Individen minns, bevakar och letar. Tidsgränser hänger på den enskildes minne och underlag sammanställs för hand.

Till

Proaktivt stöd

Systemet flaggar tidsgränser, förbereder underlag och föreslår nästa steg.

Från

Ett verksamhetsbehov leder till upphandling av ett standardsystem. Månader eller år senare får verksamheten anpassa sig efter verktyget.

Till

Egen utvecklingsförmåga

Ledtiden från identifierat behov till lanserad tjänst mäts i dagar och veckor.

Från

AI som ambition: pilotprojekt vid sidan av arbetet, och en förmåga få bygger upp.

Till

AI i vardagen

En plattform där AI används säkert och styrt, och där medarbetarna bygger AI-förmåga genom daglig användning.

Lösningen

En yta att möta, en plattform att bygga i

Det användaren möter är en startsida. Det kommunen får är ett ekosystem där nästa tjänst byggs in i samma yta. De två hänger ihop: ytan är det ekosystemet visar, och ekosystemet är det som gör att ytan kan växa utan att bli ett system till.

Ytan

Startsidan

Helt personaliserad och rollbaserad, med AI-först som bärande princip. Den visar inte allt som finns, utan det som gäller dig i dag. Den sätts som standardstartsida, inte som ett bokmärke bland andra.

Det du möter

  • Nyckeltal

    Det som gäller din roll: saldon för medarbetaren, budget och sjukfrånvaro för chefen.

  • Att agera på

    Allt som väntar, med status och tidsgräns, samlat från alla delar.

  • AI-fältet

    Fråga, be om hjälp eller starta ett ärende i klartext. Förslagen är dagsaktuella.

  • Ärenden som samtal

    Du berättar, systemet fyller i, du bekräftar. Formuläret är kvittot.

  • Sidor

    Redaktionellt innehåll från intranätet, i samma yta och med samma AI-fält.

visarbyggs av

Plattformen

Ekosystemet

Under ytan är startsidan en plattform att utveckla och lansera tjänster i. Bestämmer koncernen sig för ett bättre stöd kring utvecklingssamtal byggs det här, helt integrerat, i stället för som ännu ett gränssnitt. Med förmåga att automatisera flöden och stötta direkt med AI, i kommunens egen infrastruktur.

Det som bygger

  • Skalet

    Layout, sidopanel, AI-fält, identitet och roll. Vet vilka platser som finns, aldrig vad som står i dem.

  • Modulerna

    Varje funktion är ett fristående paket med ett manifest. En ny funktion är en ny modul; skalet rörs inte.

  • Flödesmotorn

    Samtals- och dokumentflöden som data. Nästa flöde är en definition, inte ny kod.

  • AI-lagret

    Leverantörsoberoende adapter på servern, strukturerade svar, och servern som fattar besluten.

  • Designsystemet

    Tokens och primitiver ur en källa. Blått är identitet, avvikande färg är status, och AI märks alltid ✦.

  • Devportalen

    Ekosystemets beskrivning av sig självt, för människa och agent. Dokumentation är ett leveransvillkor.

  • Integrationerna

    Tunna kopplingar till grundtjänster som grunddata, e-post och SMS. Intranätet som producent av innehåll.

Så hänger de ihop

  • Ett nytt behov blir en modul, ett flöde eller en sida i ekosystemet, aldrig ett nytt system med egen inloggning.
  • Intranätet ersätts inte. Det blir en viktig producent av nyheter och faktainnehåll som startsidan visar.
  • Allt som byggs i ekosystemet dyker upp på samma yta, för rätt roll, med samma formspråk och samma AI-märkning.

Strategisk betydelse

Formgivande för allt vi bygger härnäst

Startsidan och dess ekosystem är inte ett projekt bland andra. Det är det första vi bygger AI-native, och det arbetssätt, den plattform och det formspråk som växer fram här blir normen för kommunkoncernens utveckling framåt.

  1. Från AI i det gamla till AI-native

    Hittills har AI mest använts inom projekt och tekniska lösningar som redan fanns. Startsidan byggs med AI i grunden: arkitektur, flöden, data och gränssnitt är utformade för att en modell ska kunna arbeta i dem, inte anpassade i efterhand.

    Från AI i det gamla till AI-native

    AI som hjälpreda, eller AI som bär arbetet

    Skillnaden syns inte i om AI används, utan i vem som driver arbetet och vad tekniken är byggd för. I det gamla läggs AI ovanpå en struktur som gjordes för människor som klickar. AI-native är tekniken byggd så att AI kan sköta flödet, och människan leder, bekräftar och beslutar.

    AI i det gamla · hjälpredaAI-native · bär arbetet
    Vem driverMänniskan navigerar, AI svarar när den blir tillfrågad.AI driver flödet framåt och ber människan om det som kräver ett beslut.
    StrukturenMenyer, formulär och system som byggdes för klick. AI får anpassa sig.Data, flöden och gränssnitt byggda för att en modell ska kunna arbeta i dem.
    Människans rollGör jobbet, med lite hjälp på vägen.Leder, granskar och beslutar. Själva arbetet görs av systemet.

    Samma arbetsmoment, två sätt

    1. Anmäla ett fel

      AI som hjälpreda

      Ärendesystemets formulär med tjugo fält finns kvar. En chattbot i hörnet svarar på frågor om vilken kategori man ska välja, men det är fortfarande medarbetaren som fyller i, klassar och skickar.

      AI-native

      Medarbetaren berättar vad som hänt. AI ställer följdfrågorna, fyller i formuläret, klassar och prioriterar. Formuläret är kvittot att kontrollera, och servern skapar ärendet först när allt obligatoriskt finns och medarbetaren bekräftat.

    2. Bevaka en rehabilitering

      AI som hjälpreda

      HR-systemet har fått en AI-assistent som kan sammanfatta ärendet, när chefen väl loggat in och hittat det. Att komma ihåg dag 14, dag 90 och dag 180 hänger fortfarande på chefens minne.

      AI-native

      Systemet bevakar tidsgränserna, sammanställer underlaget och lägger nästa steg under Att agera på innan fristen. Chefen möter en förberedd uppgift och beslutar.

    3. Hitta rätt rutin

      AI som hjälpreda

      Intranätets menyträd och sökruta är kvar, med en AI-sammanfattning av sökträffarna överst. Man måste fortfarande veta ungefär vad man letar efter och var det kan ligga.

      AI-native

      Man frågar i klartext och får svaret med källa, giltighet och sidansvarig. Innehållet är märkt med målgrupp och roll, så att AI kan välja rätt utan att gissa, och det som gäller dig visas innan du frågar.

    4. Bygga en ny tjänst

      AI som hjälpreda

      AI skriver en stor del av koden, men i en lösning som varken är byggd eller dokumenterad för det. Kunskapen om varför saker är som de är finns i människors huvuden och spridda dokument, inte där agenten kan läsa den. AI saknar kontext: den gissar på konventioner, missar beroenden och bygger om det som redan finns. Utvecklaren får mata in sammanhanget för hand, varje gång, och rätta i efterhand.

      AI-native

      Kontexten är en del av lösningen. Arkitektur, modulkontrakt, designsystem och beslut är skrivna för att en agent ska kunna läsa dem, samlade i devportalen, och lösningen är uppdelad i moduler som ryms i en agents sammanhang. Agenten bygger rätt från början, och människan formar vad som ska byggas och granskar det som byggts.

    Det som inte ändras. Att AI styr och ställer i flödet betyder inte att den fattar besluten. Allt som skapas, skickas eller ändras bekräftas av en människa, och servern kontrollerar själv att det som krävs finns.

  2. Mindre kod, mer värde

    Människans insats flyttar till planering, prioritering, granskning och beslut. Utvecklare bidrar med mindre kod men mer värde: de formar vad som ska byggas, prövar det som byggts och tar ansvar för att det håller.

  3. Ett designsystem som är AI-native

    Det gäller inte bara tekniken. Även UX och design ska utgå från AI: samtal som inmatning, märkning av det maskinskrivna, ytor som visar vad modellen uppfattat. Vi tar fram eller uppdaterar ett designsystem för kommunkoncernen på de villkoren, utan krav på att det gamla måste anpassas.

  4. Nästa projekt avgör, inte arvet

    Varje val prövas mot vad som fungerar bäst för nästa projekt som byggs på det här sättet, inte mot vad som passar lösningar vi utvecklat tidigare och som nu blivit ett arv.

Testet för varje val

Frågan vi alltid ställer

Vad fungerar bäst för nästa projekt som byggs så här?

Frågan vi aldrig ställer

Vad passar det vi redan har?

Utgångspunkt 1 · AI för allt

AI för allt, som utgångspunkt

AI används i allt vi gör tills vi stöter på en gräns. Vi ska hellre få problem för att vi använt AI för mycket än för att vi varit för försiktiga.

Det här projektet blir normgivande och standardsättande för all utveckling framåt i kommunens digitalisering. Då måste vi vara föregångare och sätta arbetssätt som ska skalas, inte återanvända de gamla. Frågan är därför aldrig om AI ska användas i ett moment, utan hur, och vad vi lärde oss när det inte räckte.

✦ Vi firar begränsningarEn gräns vi stöter på är ett resultat, inte ett misslyckande. Den visar att vi verkligen försökt flytta den. Vi dokumenterar den, delar den och går vidare.

Det betyder

  1. Varje moment börjar med AI: analys, design, kod, test, dokumentation, innehåll och uppföljning.
  2. Att vara defensiv är den risk vi inte tar. Den som väljer bort AI i ett moment ska kunna säga varför.
  3. Det vi lär oss om var gränserna går blir arbetssätt som nästa projekt ärver.
  4. Människan behåller kontrollen: granskning, kvalitetsgrindar och beslut ligger kvar hos oss.

Utgångspunkt 2 · Delningsbarhet

Byggt för att delas

Vi bygger en produkt som andra kommuner och organisationer kan installera och använda, inte en lösning för oss själva.

Startsidan och dess ekosystem tänks som en produkt från första dagen. Det som byggs här ska kunna tas emot av en annan kommun utan att den behöver vår infrastruktur eller våra särlösningar. Det styr arkitekturen, beroendena, dokumentationen och licensen, och det gör oss ärligare i varje val: skulle det här hålla hos någon annan?

✦ Öppen källkodKoden är öppen under MIT-licens. Kommunens namn och grafiska profil följer inte med; allt annat gör det, inklusive dokumentationen.

Det betyder

  1. Installerbar av en annan part utan tunga kringberoenden. Det ska gå att sätta upp som en lösning, med egen konfiguration, utan att först bygga om sin infrastruktur.
  2. Grundtjänster som e-post, SMS och grunddata får vara externa beroenden, för dem har alla. Tjänster med mycket egen logik får det inte.
  3. Ekosystemet sätter standarden andra integrerar mot, och använder öppna standarder så långt det går.
  4. Dokumentationen skrivs för någon som inte sitter i vårt hus. Devportalen är produktens manual, för människa och agent.

Utgångspunkterna säger hur vi ställer oss till AI i varje moment, och till alla andra som vill använda det vi bygger. Vad som byggs, och hur, står i devportalen.

Arbetssätt

Prototypdriven utveckling

Vi arbetar extremt nära verksamheten. En idé blir en fullt fungerande prototyp på som mest någon timme, så att vi kan börja testa samma dag. Prototypen itereras löpande med verksamheten tills den känns rätt, och först då byggs den långsiktiga funktionen, med prototypen som förlaga.

  1. Start

    Idé, vid samma bord

    Behovet formuleras tillsammans med verksamheten. Den är bra på sin vardag men dålig på att skriva abstrakta krav, så vi börjar inte med ett kravdokument utan med något att reagera på.

  2. Inom en timme

    Fungerande prototyp

    En fullt fungerande prototyp byggs på ekosystemets mall, med syntetisk data. Den går att klicka i och pröva på riktigt, inte bara titta på.

  3. Dagar

    Iterera tills det känns rätt

    Verksamheten reagerar på något konkret, vi ändrar och visar igen. Flera varianter kan byggas parallellt och jämföras. Det är billigt att slänga det mesta; framgång mäts i insikt, inte i bevarad kod.

  4. När det sitter

    Bygg det långsiktiga

    Ur prototypen och återkopplingen skördas en spec med acceptanskriterier. Sedan byggs den långsiktiga funktionen: prototypens kod härdas om den håller, eller regenereras från specen om den muterat. Vägen till produktion går alltid genom lint, test och mänsklig granskning.

Spelregler

  • Prototypen är tydligt märkt som prototyp och kan aldrig nå produktion av misstag.
  • Syntetisk data i prototypfasen, aldrig produktionsdata.
  • Verksamheten vet att det den ser är en skiss, så att steget till produktion inte uppfattas som obegripligt långsamt.
  • Specen och testerna är det som överlever. Koden kan behållas eller regenereras.

Så gjorde vi här

Startsidan är byggd så. Varje del hade ett klickbart HTML-facit innan koden skrevs, flödena prövades som prototyper innan de blev moduler, och principerna på den här sidan skördades ur det som visade sig hålla.

Arbetssättet är kommunens AI-drivna utvecklingsprocess i den form startsidan tillämpar den: idé, utforskning, skörd, härdning, produktion.

Konsekvenser

Det här påverkar mer än startsidan

Att bygga AI-native och delbart får konsekvenser för det som finns runt omkring: designsystemet, ramverken och integrationerna. Grunderna gäller inte bara ekosystemets egna moduler. Även lösningar som byggs helt utanför ekosystemet ska bygga på samma designsystem, samma stack och samma utvecklingsprocess, så att de kan utvecklas och livscykelhanteras på samma sätt. Tre områden behöver ses över, och allt ska till slut landa på ett ställe, en gemensam devportal.

  1. Designsystemet och UX-processerna

    Ska det befintliga designsystemet göras AI-native, eller tas ett nytt fram?

    Behöver ses över

    • Prototypen har en egen designgrund och koncernen ett befintligt designsystem. De behöver bli ett, och valet ska styras av vad som fungerar bäst för nästa projekt.
    • Designsystemet behöver vara läsbart för agenter, inte bara för människor.
    • UX-processen får nya mönster när samtalet är inmatning och allt AI-genererat ska märkas.

    PåverkanEtt designsystem för kommunkoncernen som är AI-native, tillgängligt i devportalen.

  2. Tekniska ramverk

    Vilken grund startar nästa tjänst från, och vilka grindar gäller?

    Behöver ses över

    • Ekosystemets mall och kommunens nuvarande starter behöver bli en gemensam utgångspunkt, inte två parallella spår.
    • Grundtjänster förblir tunna beroenden; logiken bor i ekosystemet.
    • Samma kvalitetsgrindar för prototyp och produktion, och delbarhet som krav från början.

    PåverkanEn förvaltad golden path i devportalen som nästa projekt startar från.

  3. AI-native integrationsmöjligheter

    Hur når en modul, och en agent, kommunens data och tjänster på ett säkert sätt?

    Behöver ses över

    • Data och tjänster behöver beskrivas maskinläsbart: vad som finns, vem som äger det och hur det hämtas.
    • Agenter får smala, spårbara förmågor med användarens identitet och minsta behörighet, aldrig fri åtkomst.
    • Integrationer beskrivs som standardkontrakt som en annan kommun kan uppfylla med sina egna grundtjänster.

    PåverkanIntegrationer byggs en gång, beskrivs maskinläsbart och återanvänds av varje modul.

Landningen

Allt landar i en gemensam devportal

Devportalen är inte en av konsekvenserna, den är dit de andra leder. Designsystemet, ramverken och integrationerna är värda något först när de går att hitta, läsa och följa från ett ställe, av människor och agenter, utan att fråga en kollega.

✦ Testet

Testet är enkelt: peka en agent på devportalen och be den bygga en modul. Klarar den det utan att fråga en människa är portalen komplett. Frågar den, saknas något i portalen, inte i agenten.

Portalen ska svara på

  1. Hur man bygger: arkitektur, modulkontrakt, mallar och recept
  2. Hur man designar: tokens, primitiver, mönster, regler och felindex
  3. Vilken data som finns: katalog med ägare, klassning och kontrakt
  4. Hur man hämtar den: API-beskrivningar, förmågor och behörighetsregler
  5. Vad som är beslutat: ADR:er, status och vad som återstår

Läs vidare

Bakom principerna