Användarstöd

Med användarstöd och utbildning avses här när användarstödsaktiviteter genomförs utan att det har direkt samband med ändringar. Användarstöd, eller support som många väljer att kalla det, är ofta en dold aktivitet i förvaltnings- arbetet som kan kräva stora resurser som inte synliggörs.

Planerna visar att användarstödsuppdrag kan ini- tieras på följande sätt;

– användare efterfrågar hjälp att använda IT-

systemet, eller efterfrågar hur objektverksamheten och IT-systemet fungerar tillsammans

– aktör i förvaltningsorganisationen efterfrågar

hjälp gällande tekniskt problem

– behov av att ändra användardokumentation

– behov av utbildning

– behov av att informera användarna om objektets

status.

Med användarstöd avses ofta stödet till slutanvändarna. Jag vill dock vidga definitionen eftersom det visat sig att användarstöd kan uppstå i flera led i förvaltningsarbetet. Det kan tex vara en IT-drifttekniker som ger stöd till stödverksamheten eller en regelverksexpert som ger stöd till affärs/uppdragsverksamheten

Tabell 5.3 Aktiviteter och aktörer i systemförvaltning. Part Aktivitet Objektspart IT-system- förvaltningspart IT-driftspart Användarstöd X X Ändringshantering X X Förvaltningsstyrning X X IT-drift X

Tabell 5.4 Förvaltningsverksamhetens huvudaktiviteter och delaktiviteter.

Huvudaktivitet Delaktivitet

Användarstöd Besvara frågor

Informera Utbilda Ändringshantering Initiera Prioritera Bereda Genomföra Testa Införa

Förvaltningsstyrning Strategisk styrning

Operativ styrning

Daglig IT-drift och underhåll Övervaka

Köra Filöverföra Ge preventiv service Ta backuper Problemhantera Bilaga 5.1 Avsnitt 7.1 Avsnitt 7.1.5 Tabell 5.4

(se figur 4.6). Huvudansvarig producent av användarstöd är för- valtningsorganisationen. Användarstödet kan brytas ned i ett antal delaktiviteter. Jag har använt mig av följande kategorier;

– besvara frågor

– utbilda och informera.

För att utföra ovanstående aktiviteter behöver producenterna underlag i form av information om IT-systemet från IT-leverantö- ren samt information från objektsparten om hur objektverksam- heten fungerar. Resultatet är stöd till klienterna, dvs. användarna, i syfte att få dem att utnyttja IT-systemet på fungerande sätt.

Besvara frågor

Förvaltningsplanerna visar att det är vanligt att organisationer bygger användarstödet i flera nivåer, där första nivån (generalister) hanterar de enklaste och mest frekventa användarstödsfrågorna. IT-driftleverantören har en viktig roll här, eftersom de vanligen ansvarar för denna första nivå, supporten. I de fall nivå 1 inte kan besvara frågan, eskaleras ärendet till nivå 2 (specialister). För komplexa och omfattande förvaltningsobjekt kan det finnas behov av ytterligare specialist- nivåer. På detta sätt är supportorganisationen och förvaltnings- organisationen ofta överlappande, där nivå 2 utgörs av repre- sentanter från förvaltningsorganisationen.

Användarstödet handlar för IT-driftpartens del, dock inte bara om frågor och svar – vanligen finns inom suppor- ten eller helpdesken en organisation (eller kundstödsprocess, beroende på hur man organiserat sig) som även tar hand om allt från felavhjälpning till enskilda materialbeställningar med mera. En av intervjupersonerna drog parallellen att de åtgär- der som görs på servrar och infrastruktur inom daglig IT-drift och underhåll, görs med motsvarande syften på klientdatorerna av supporten. Här kan det dock uppstå ”gnissel” i mötet mel- lan objektverksamhet och IT-drift i de fall IT-driften och sup- porten är utkontrakterad och IT-driftsleverantören har rela- tivt låg kännedom om objektverksamheten. I intervjuerna har också framkommit att problemet med utkontraktering är att kostnadsmedvetenheten visserligen ofta är hög hos de externa

Figur 4.6 leverantörerna, vilket anses bra, men kunskapen om objektverk-

samheten för låg. Förvaltningsplanerna visar att hos interna IT- driftsorganisationer är problemet vanligen det omvända; man kan sin verksamhet men är inte alltid lika kostnadsmedveten.

Utöver förvaltningsobjektets användare kan andra funktioner vara i behov av stöd vid problemsituationer. Det gäller framförallt när förvaltningsobjektet riktar sig mot en extern marknad och där det exempelvis finns ett behov av hjälp med blanketter, tolkning av information eller lokala installa- tioner. Oavsett till vilka användarkategorier rutinen vänder sig visar källstudierna att det är viktigt att tydliggöra hur (telefon eller e-post) och när (dygnet runt eller avgränsat) frågor kan initieras från de olika parterna. I figur 5.4 presenteras en rutin för att besvara frågor i form av en handlingsgraf (Goldkuhl och Röstlinger, 1988). Rutinen är hämtad från en förvaltningsplan inom en svensk myndighet, och är ett exempel på hur fråge- hantering kan gå till. Ett ärende som initieras såsom användar- stöd kan i förlängningen även leda till en aktivitet inom ramen för ändringshantering, tex om en felaktighet upptäcks eller om flera användare ställer frågor om samma funktion så att en för- bättringsåtgärd blir aktuell.

Utbilda och informera

Som ett komplement till användarstöd kan pro- blemsituationer förebyggas med aktiviteter såsom tex utbild- ning, upprätthållande och förbättring av användarmanual och informationskampanjer i syfte att öka kunskapen om förvalt- ningsobjektet, vilket i sin tur minskar antalet användarstödsä- renden. Av förvaltningsplanernas behovsbeskrivningar fram- går att utbildning är en aktivitet som ofta är eftersatt och som därmed blir ett problem för förvaltningsorganisationen. Inter- vjuer med förvaltningsplanernas framtagare visar att många förvaltningsorganisationer menar att antalet frågor kan minska väsentligt om nyttjarna hade en högre kunskapsnivå. Det gäller såväl IT-systemet som processer i den aktuella objektverksam- heten. I objektverksamheten handlar det ofta om ett kontinuer- ligt behov av utbildning som är en direkt följd av omfattningen av personalomsättning som råder i organisationen. Intervjuerna visar vidare att utbildningsinsatser av den här typen har man

dock sällan tid till, och den vanligaste utbildningen är den som följer av en omfattande ändring.

5.2.2 Ändringshantering

Resursberäkningarna, där resurser beräknas för de olika delaktiviteterna i förvaltningsplanerna visar att änd- ringshantering är den mest frekvent förekommande förvalt- ningsåtgärden. Med ändringshantering avses här åtgärder från det att ett ändringsbehov uppstår till dess ändringen är införd. Analysen av systemförvaltningens aktiviteter har vidareut- vecklat begreppsategorierna från licentiatavhandlingen (Berg- vall, 1995). För ändringshanteringen är dessa ursprungskate- gorier; ändringstyp, ändringsgrund och ändringsstrategi. De presenteras i tabell 5.5. I analysen har typerna ändringsobjekt och ändringshantering tillkommit. Tillägget med kategorin ändringshantering även som huvudkategori skapar en viss oba- lans i begreppen eftersom en av huvudkategorierna är syno- nym med hela aktivitetsgruppen ändringshantering. Då denna benämning är mycket tydlig på det som görs i en förvaltnings- verksamhet (handlingarna) väljer jag ändå att använda denna benämning även om den kan kritiseras ur ett strukturperspektiv.

Tabell 5.5

Tabell 5.5 Begreppskategorier för ändringshantering.

Huvudkategori Beskrivning Underkategori

Ändringsgrund Bakomliggande orsak till ändringsbehov. Upptäckt av fel

Upptäckt av att behov har upphört Behov av förändring

Ändringsobjekt Det objekt som behöver ändras för att rätta,

förändra eller sanera. Process/delprocessIT-system

Produkt

Ändringstyp Kategorisering av ändringar utifrån

ändringsgrunden.

Rättning Anpassning Förbättring Sanering

Ändringsstrategi Handlingsalternativ i samband ändringar. Genomföra ändringar

Avvisa och ej genomföra ändringar Anpassa objektverksamheten efter IT-systemet Använda IT-systemet till annat än

ursprungssyftet Ändringshantering Åtgärder från det att ett ändringsbehov

uppstår till dess ändringen är införd. Initiera Bereda

Prioritera Genomföra Testa Införa Figur 5.4 Exempel på hantering av frågor.

Kunskaps- behov Problem- beskrivning Lösnings- beskrivning Lösnings- beskrivning Uppföljnings- rapport

Loggning (supportaktörer på nivå 1, generalister)

Lösning (supportaktörer på nivå 1, generalister)

Uppföljning (supportaktörer på nivå 1, generalister)

Uppföljning (supportaktörer på nivå 2, specialister)

Initiering till ändringshantering (supportaktörer)

Lösning (supportaktörer på nivå 2, specialister) Återkoppling (supportaktörer på nivå 1,

generalister samt ändringsinitierare)

Återkoppling (supportaktörer på nivå 2, specialister samt ändringsinitierare) Fördelning (supportaktörer på nivå 1, generalister samt supportaktörer på nivå 2,specialister)

Ändringsgrunder, ändringsobjekt och ändringstyper

Planerna visar att det ofta finns bakomliggande orsaker till ett ändringsbehov hos någon av objektets intres- senter. Jag har valt att kalla detta ändringsgrund. Jag har också vidareutvecklat resultatet från licentiatavhandlingen (Bergvall, 1995) med ytterligare en kategori – ändringsobjektet. Ändrings- objektet är det objekt där ändringen har sitt ursprung. Katego- rin ändringsobjekt används senare som grund för besvarandet av frågeställningarna kring förvaltningsobjektet (se avsnitt 5.4 och kapitel 6). Ändringsgrunder och ändringsobjekt som jag funnit i de studerade förvaltningsplanerna presenteras i tabell 5.6.

Upptäckt av fel innebär att man hittar ett fel som, direkt eller indirekt, påverkar objektverksamheten. Den här typen av fel är vanligast när IT-system är relativt nya och nyinstallerade. I takt med att IT-systemen används brukar antalet direkta fel minska, visar en uppföljning av de planer som genomgått en årlig förnyelse. Det behöver dock inte nöd- vändigtvis vara tekniska fel, utan kan lika gärna vara ett fel i objektverksamhetens processer/delprocesser eller objektverk- samhetens produkter.

När det föreligger ett behov av förändring innebär det att man upptäcker att någonting kan göras på ett annat sätt. Vid analys av förvaltningsplanerna visade sig följande exempel på vad som kan initiera ett förändringsbehov. Ibland kan för- ändringar vara tvingande såsom förändringar i vissa normer tex regelverk och skattesatser. Förändringsarbete genereras ofta från marknadens behov/krav på organisationen. Något som i sin tur ställer krav på interna processer/delprocesser och produkt-

utbud. Förändringar i organisationen, tex uppköp, fusioner eller omorganisationer kan leda till förändringar i ändringsobjekt. Förändringar i närliggande objekt, alternativt pågående utveck- lingsprojekt (IT- eller annan verksamhetsutveckling) kan också initiera ändringar i något av ändringsobjekten. Förvaltningspla- nerna visar att den här typen av förändringar blir allt vanligare i takt med att den tekniska arkitekturen blir alltmer komplex och objektverksamheter ställer höga krav på förändringstakten. Ibland kan det även vara nödvändigt med förändringar som ini- tieras av IT-parter. Det kan tex vara på grund av att en ny ver- sion av operativsystem måste införas.

Upptäckt av att behov upphört innebär att det över tiden har skett en förändring i objektverksamheten och att IT-systemet därmed har funktionalitet som inte längre används. Det kan tex vara initierat av en normförändring, nedläggning av en olönsam produkt, förändring av en process/delprocess eller avyttring av en objektverksamhet.

Det innebär att förvaltningsplanerna visar behov av tre olika ändringstyper; rättning, förändring och sanering. Den största omfattningen har förändringskategorin som utgör en sammanslagning av Riksdataförbundets kategorier för- bättring och anpassning (RDF, 1987). Sanering nämns i de flesta planer, som brutit ned ändringsarbetet i olika typer, men resursplaneras inte i någon större omfattning. Det kan tyda på att sanering inte är någon omfattande aktivitet i förvaltnings- verksamheter. Detta bekräftas av en aktör från en IT-part som vid framtagandet av en förvaltningsplan sa; ”Vi behöver sanera i IT-systemet, men det är svårt att få resurser till det. Beställarna (objektsparten) är mer intresserade av få föränd- rad funktionalitet. Jag är dock orolig för prestandan när vi har så mycket skräpkod i IT-systemet.” Förvaltningsplanerna visar således på ett behov av tre av de fyra ändringstyper som finns i teorin (ibid). Denna slutsats analyseras vidare i avsnitt 7.1.5.

Ändringsobjekt utgör grunden för förvaltningsob- jektet som ett av avhandlingens kunskapsbidrag. Resultatet av analysen av förvaltningsplanerna avseende förvaltningsobjekt finns i avsnitt 7.2.

Tabell 5.6 Ändringsgrunder och ändringsobjekt.

Ändringsgrund Ändringsobjekt

Upptäckt av fel Process/delprocess

IT-system Produkt

Behov av förändringar Process/delprocess

IT-system Produkter

Upptäckt att behov har upphört Process/delprocess

IT-system Produkt Avsnitt 5.4 Kapitel 6 Tabell 5.6 Avsnitt 7.1.5 Avsnitt 7.2

Ändringsstrategi

De ändringsgrunder som beskrivs i ovanstående avsnitt kan alla generera ett förslag om ändring. I planerna beskrivs dessutom olika handlingsalternativ i samband med