Webbförvaltning efter lansering: vad ni ska kräva

Webben lanserades i våras. Nu vill försäljningen ändra ett prisfilter, produktteamet lägga till ett integrationsfält och ekonomichefen öppna för en ny kundgrupp. Allt fungerade vid leveransen, men ändringarna berör flera system samtidigt.

Offerten beskriver vad ni köpte. Avtalet om webbförvaltning behöver beskriva vad som händer nu, vem som bedömer ändringen och vilket arbete månadskostnaden omfattar. Annars riskerar varje justering att bli en ny diskussion om ansvar och pris.

Webbförvaltning börjar först när webben är live

Ett nytt prisfilter kan se ut som en liten ändring på skärmen. Bakom filtret finns produktattribut, kundpriser, sökindex och regler för vilka produkter kunden får se. Förvaltningen börjar med att någon bedömer hela den kedjan innan arbetet beställs.

Webbförvaltning omfattar flera arbetsströmmar som behöver hållas ihop. Drift och säkerhet kommer först, med övervakning, certifikat, säkerhetskopiering och provad återställning. Versionsuppföljningen omfattar plattformen, publiceringssystemet, kopplingen till affärssystemet och tredjepartskomponenter. Felrättning behöver sorteras efter hur verksamheten påverkas, medan vidareutveckling tillför funktioner under kontrollerade former.

Innehåll och produktdata behöver dessutom en egen plats i planeringen. Nya dokument, produktbilder och översättningar fortsätter att publiceras under hela lösningens livslängd. Ett projekt har ett överlämningsdatum. Förvaltningen fortsätter så länge kunder, redaktörer och säljare använder lösningen.

Behovet av återkommande kontroll syns i Diggs övervakning av offentlig digital service, som omfattade 1 111 offentliga webbplatser under perioden 2022 till 2024. Underlaget gäller offentlig sektor och visar varför granskningen behöver omfatta hur tjänsterna fungerar för användarna.

En praktisk förvaltningskalender börjar med veckovis uppföljning av incidenter, misslyckade synkroniseringar och publiceringsfel. Månadsvis går ni igenom versioner, återställningsprov och prioriterade ändringar. Vid varje driftsättning kontrolleras berörda användarflöden och resultatet dokumenteras. Kalendern gör arbetet möjligt att planera och ger er underlag när leverantören redovisar vad som faktiskt har utförts.

Servicenivåer och vad avtalet faktiskt lovar

En basnivå kan omfatta månatlig översyn, versionsuppföljning och hantering av inkomna fel under kontorstid. En utökad nivå kan lägga till löpande övervakning och förutbestämda tider för driftsättning. För verksamhetskritiska flöden behövs egna mål för beställningar, kassan och kundinloggningen, tillsammans med avtalad jourberedskap. Det här är möjliga avtalsupplägg, med olika krav på bemanning och kostnad.

Ett servicenivåavtal, ofta kallat SLA, behöver skilja mellan svarstid, felsökning och återställd funktion. Ett mottagningsbesked säger att ärendet har registrerats. Det säger ingenting om när kunderna kan beställa igen. Avtalet bör också ange när klockan börjar löpa, vilka öppettider som gäller och hur planerat underhåll behandlas. Ett användbart servicenivåavtal beskriver vad leverantören gör när något avviker och hur ni kan kontrollera att arbetet utfördes.

Som hypotetiskt räkneexempel motsvarar ett tillgänglighetsmål på 99,5 procent under en månad med trettio dagar högst tre timmar och trettiosex minuters avbrott. Procentsatsen behöver bedömas mot era försäljningstider och de funktioner som ingår i mätningen. Webbservern kan svara samtidigt som kunderna saknar sina avtalspriser. Därför behöver avtalet ange mätpunkt, kontrollmetod och vilka undantag som räknas bort.

Prioritetsklasserna bör beskriva verksamhetens påverkan. Kritiska fel kan stoppa köp eller dölja nödvändig orderstatus. Allvarliga fel kan ha en tillfällig lösning, medan mindre fel och förbättringar får planerade åtgärdstider. Som tumregel bör ett kritiskt fel få ett mänskligt svar samma arbetsdag och en åtgärdsplan inom någon arbetsdag. Ett avbrott som stoppar försäljningen kan kräva betydligt snabbare beredskap.

Jourberedskap kostar även när ingen ringer. Den kan vara motiverad när beställningar kommer utanför kontorstid, men ger begränsat värde om verksamheten kan vänta till nästa arbetsdag. Ert befintliga avtal ska gå att uttrycka enkelt: vad som mäts, hur ofta det mäts och vad leverantören gör vid avvikelse. Otydliga svar på något av dessa led behöver redas ut före underskrift.

Ansvaret delas mellan leverantör och kund och bör stå i avtalet

Kunden prioriterar och beställer ändringen. Leverantören bedömer omfattning, beroenden och risk. Efter testning godkänner utsedda personer hos kunden ändringen, varefter leverantören driftsätter, dokumenterar och följer upp resultatet i produktion. Ett fungerande arbetssätt gör varje överlämning tydlig och möjlig att följa.

Avtalet behöver namnge vem som äger ändringskön, godkänner driftsättningen och ansvarar för produktdata respektive redaktionellt innehåll. Ange även en ersättare när ordinarie beslutsfattare är borta. Annars kan ett färdigt arbete fastna inför lansering, eller publiceras utan verksamhetens godkännande.

En redaktör kan exempelvis byta benämning på ett produktfält som också används vid synkronisering. Den synliga textändringen kan då påverka produkturval eller informationsöverföring. För tredjepartstjänster behövs motsvarande gränsdragning: någon måste kunna förnya åtkomsten, ta emot felmeddelanden och besluta om tjänsten ska ersättas.

Det gäller särskilt när AI används för att berika produktinformationen. AI kan få föreslå beskrivningstexter, sökord och översättningar inom bestämda fält. Artikelnummer, priser, lagersaldon och orderstatus bör hämtas från utsedda källsystem och skyddas mot automatiska omskrivningar. Säkerhetsinformation och produktegenskaper behöver mänskligt godkännande före publicering. Logga ursprungsvärde, ändring, modell, instruktion och godkännare. Ett felaktigt förslag kan annars spridas samtidigt till webb, kundportal och återförsäljarkanaler, vilket gör rättningen betydligt mer omfattande.

Uppgraderingar kräver ett testpaket som körs före release

Ett lyckat anslutningstest visar att systemen kan kommunicera. När artikelstrukturen eller ett API-kontrakt ändras kan felet ändå spridas genom PIM, mellanlagring, sökindex och orderflöde. Varje koppling kan svara korrekt trots att kunden får fel pris eller att beställningen fastnar.

Testpaketet behöver därför följa affärshändelser. Synkroniseringen ska vara idempotent, vilket betyder att upprepad överföring ger samma resultat utan dubbletter. Kontrollera priser, lagersaldon, orderstatus och behörigheter för relevanta kundgrupper. Prova också vad som händer vid tidsgränser, återförsök och transaktioner som bara genomförts delvis.

Ett syntetiskt flödestest kan skapa en testorder från produktsidan till bekräftelsen i affärssystemet. Det körs i testmiljön före driftsättning och jämför utfallet med förväntade värden. Frågorna kring integration med affärssystemet behöver därför omfatta hela beställningen, inklusive avvisade order och saknade obligatoriska uppgifter.

För den tekniska förvaltningen behöver ni följa felandel per integrationsjobb, kölängd, synkfördröjning, lyckade återförsök och tid till återställning.

Versionslås API-kontrakten och prova återgång till föregående version i testmiljön. En återställningsinstruktion behöver fungera även efter att data har förändrats. Större versioner av affärssystemet och större plattformsskiften motiverar hela testpaketet. En avgränsad buggrättning kan få en mindre kontroll, om beroendena är kartlagda. Planera driftsättningen när ordervolymen är låg och lämna ett verkligt godkännandefönster för verksamheten innan ändringen släpps.

Tillgänglighet måste kontrolleras vid varje förändring

Tillgänglighet behöver finnas med när innehåll, mallar och funktioner ändras. PTS beskriver tillgänglighetslagens krav för tjänster till konsumenter, däribland e-handel, och kopplingen mellan EN 301 549 och WCAG 2.1 på nivåerna A och AA. DOS-lagen gäller offentlig digital service. Vilket regelverk er tjänst omfattas av behöver klarläggas innan ni bestämmer kontrollernas omfattning.

Kraven behöver översättas till sådant redaktörer och utvecklare kan prova. En produktbild ska förmedla relevant information även när användaren saknar möjlighet att se bilden. Kundens väg genom kassan ska fungera med tangentbord och formulärfel behöver gå att förstå och rätta.

PTS beskriver egenskaperna möjlig att uppfatta, hanterbar, begriplig och robust. Alternativtext hjälper användaren att uppfatta bildens innehåll. Tangentbordsnavigering gör gränssnittet hanterbart, tydliga felmeddelanden gör formuläret begripligt och korrekt kodstruktur hjälper olika hjälpmedel att tolka sidan.

Efter lanseringen kan en ny bild sakna alternativtext eller en ändrad kassa flytta fokus till fel ställe. Ett formulär kan visa ett fel som skärmläsaren aldrig meddelar. Inbäddade tredjepartskomponenter behöver därför ingå i samma kontroll som resten av sidan.

Kör automatiserade kontroller före publicering där det går. Lägg till manuell provning med tangentbord och skärmläsare vid större förändringar och följ kvarstående fel per driftsättning. Använd den avtalade ansvarsmatrisen för att fördela avvikelserna till rätt person. Automatiska verktyg hittar vissa fel, medan andra kräver att någon faktiskt genomför uppgiften. Även en tillgänglig kärnplattform kan få betydande brister när nya texter, dokument och komponenter publiceras.

När upplägget kräver mer än ni tror eller passar fel

Löpande förvaltning ger mest värde när lösningen används dagligen och förändras. Ett avtal som enbart omfattar serverdrift lämnar frågor om integrationer, produktdata och innehåll obesvarade. Ju fler beroenden ni har, desto mer arbete krävs för att hålla en aktuell bild av dem. Resonemanget om composable commerce och systemens beroenden är relevant när ni bedömer hur många delar som behöver samordnas.

Modellen passar inte överallt. Ta en mindre contentwebb som sällan ändras: där bör avtalet begränsas till drift, bevakning och en kanal för felanmälan, medan ändringar beställs och prissätts styckvis. En sådan avtalsrad kan lyda: "Avtalet omfattar övervakning av domän, certifikat och publiceringsmiljö, återkoppling nästa arbetsdag vid felanmälan samt en årlig genomgång av plattformsversionen. Nya sidor, malländringar och integrationer beställs separat till fast pris per funktion." Ni betalar då för det som faktiskt behöver hända.

Ett avgränsat engångsprojekt följer samma logik. Ska inget förändras efter lansering finns ingen förvaltningsmängd att fördela, och ett stort löpande åtagande blir dyrt utan att arbetet kommer framåt när ägarskapet ännu är oklart. Ett avtal som inte namnger vilka funktioner som ingår blir i praktiken timdebitering med ett extra steg. Skriv därför in både funktionerna och tjänstenivåerna.

Ett tyngre upplägg är motiverat när lösningen bär order, lager och kunddata mot affärssystemet och ändras varje vecka. Då räcker det inte med en felanmälningskanal. Avtalet behöver omfatta uppgraderingar av plattform och affärssystem samt prissatta funktioner för det som tillkommer.

Räkna förvaltningen tillsammans med bygget när ni bedömer TCO, den totala ägandekostnaden. Som kalkyltumregel kan ni jämföra över tre till fem år. Det är en vald planeringshorisont, inget uppmätt normalvärde. Ta med kundens arbetstid, tredjepartsavgifter, tester och konsekvenser av uteblivna uppdateringar. Kartlägg sedan nuläget innan ni väljer servicenivå, så att avtalet motsvarar de risker ni faktiskt har.

Tre frågor att ställa till leverantören innan ni skriver på

Vilka versioner av plattformen och affärssystemet omfattas av åtagandet, och hur länge stöds en äldre version efter att en ny har släppts? Svaret visar om det finns en planerad uppgraderingstakt och tydliga gränser för stödet. Be leverantören precisera vad som händer när en komponent når slutet av sin stödtid. Det behöver framgå om arbetet ingår och vilka beslut ni måste fatta.

Vad händer med en ny funktion när plattformen uppdateras, och vem testar den mot era integrationer före driftsättning? Svaret visar om kompatibiliteten hanteras genom en dokumenterad process med faktiska testresultat. En användbar redovisning knyter testfallen till den levererade funktionen och anger kvarstående avvikelser. Den bör även visa vilka kundgrupper och affärsflöden som provats. Be om underlag från genomfört arbete. Testrapporter och incidentloggar visar hur leverantören tillämpar avtalet när något behöver hanteras.

Hur många kritiska fel löstes inom avtalad tid under senaste kvartalet, och vem rapporterar utfallet? Svaret visar om leverantören kan följa upp sitt åtagande med en tydlig mätmetod. Om perioden saknar kritiska incidenter bör det framgå, tillsammans med hur beredskapen har kontrollerats.

Begär ett anonymiserat exempel om underlaget innehåller andra kunders uppgifter. Svaren ska kunna styrkas med testrapporter, release notes och incidentlogg. Kontrollera också att samma definitioner används i försäljningsmaterialet, avtalet och den löpande rapporteringen. Då kan ni bedöma vad leverantören faktiskt åtar sig när lösningen börjar förändras.

Bestäm vem som äger förvaltningen innan ni beställer

En beställning utan namngiven ägare för tiden efter go-live lämnar uppgraderingar, fel och förbättringar utan mottagare. När ni jämför e-handelsplattform och fortsatt förvaltning bör avtalet därför bedömas samtidigt som tekniken.

Efter lansering förvaltar vi lösningen som en produkt genom Glanser Care, ett avtalat ansvar till fast månadskostnad som omfattar versionsuppföljning, kompatibilitet genom uppgraderingar och buggrättning. Uppgraderingar kräver ingen ny offert. Gränsen mellan avtalade förbättringar och nya funktioner behöver ändå stå i klartext i beställningen.

Ta med en skriftlig ansvarsfördelning i nästa offertförfrågan. Vem beslutar om en ändring, vem testar den mot integrationerna och vem ansvarar om den bryter ett flöde. Med samma frågor till varje leverantör blir svaren jämförbara och ägarskapet tydligt innan ni skriver på.

Glanser

På sidan om Glanser Care ser ni vad som ingår i förvaltningen efter lansering och hur upplägget kan passa er webb eller portal.