Kravspecifikation medarbetarportal

Transkript

1 Kravspecifikation medarbetarportal 7 maj 2015 Frida Hallén och Max Walter Hornsbruksgatan 19 SE Stockholm T: +46 (8)

2 Innehållsförteckning 1. Webbpublicering Nyheter Kalender Dokumenthantering Min sida Samarbets- och projektytor Socialt flöde Information om medarbetare Sök Integration med verksamhetssystem Användare och behörigheter Förutsättningar Utveckling av medarbetarportalen Prioriterat till en första version Vidareutveckling i ett senare skede Ordlista (20)

3 Inledning Detta dokument innehåller en kravspecifikation för Mittuniversitetets Medarbetarportal. Kravspecifikationen är utformad så att den fungerar oavsett val av webbpubliceringssystem. Kraven i dokumentet utgår från de behov som samlats in under workshops och intervjuer på Mittuniversitetet under genomförandet av en förstudie våren Behov och hur de prioriterats av medarbetarna finns beskrivna i dokumentet Behovsanalys Medarbetarportal. Varje rubrik i dokumentet motsvarar ett övergripande krav för medarbetarportalen och i tabellerna beskrivs mer detaljerade krav. Kraven ska vara på tillräckligt hög/låg nivå för att kunna användas för att planera hur koncept och detaljerad specifikation av funktioner ska tas fram. Kapitel 13, Steg för ett genomförandeprojekt, beskriver vad vi bedömer som viktigast att prioritera till en första version av medarbetarportalen och vad som kan utvecklas i senare steg. I slutet av dokumentet finns en ordlista för att definiera de begrepp som används i kravspecifikationen. 3 (20)

4 1. Webbpublicering Följande krav gäller för publicering av innehåll på webbplatsen. 1.1 Skapa sidor som ordnas i en hierarkisk struktur av redaktörer. 1.2 Mallar för olika typer av sidor ska tas fram utifrån övriga rubriker i den här kravspecifikationen. 1.3 Skapa komponenter som kan placeras ut på olika sidor av redaktörerna. Komponenter behöver inte placeras i den hierarkiska strukturen. 1.4 Mallar för olika komponenter ska tas fram utifrån övriga rubriker i den här kravspecifikationen. 1.5 I varje mall, oavsett sida eller komponent, ska huvudredaktörer (eller roller på högre behörighetsnivå) kunna redigera allt statiskt innehåll som finns och formatera dessa texter i det redaktionella gränssnittet. Statiskt innehåll är sådant som sällan ändras och som återkommer i samma mall för sidor och komponenter. Exempel: E-post och telefonnummer i sidfoten är ett exempel på statiskt innehåll. Huvudredaktörer, eller högre behörighetsnivå, ska inte behöva ta kontakt med teknikleverantören/webbyrån för att göra dessa ändringar. 1.6 Vilka sidor och komponenter som ska visas för olika typer av användare ska kunna styras av redaktörerna i det redaktionella gränssnittet. Exempel 1: Om ett meddelande endast avser verksamheten i Östersund ska det vara möjligt för redaktörerna att bestämma att meddelandet endast ska visas för användare som arbetar i Östersund. Exempel 2: Om det på sidan för Semester finns information som endast gäller en viss del av organisationen ska den informationen visas endast för de som tillhör den delen av organisationen. 1.7 Alla sidor och komponenter ska kunna skapas och redigeras av redaktörerna i webbpubliceringssystemet, utifrån vad de har för behörigheter. 1.8 Instruktioner för hur olika sidor och komponenter ska användas av redaktörer ska tas fram. 1.9 Båda språken svenska och engelska ska kunna hanteras på webbplatsen. Hornsbruksgatan 19 SE Stockholm T: +46 (8)

5 2. Nyheter Nyheter listas till skillnad från sidor som finns i en hierarkisk struktur. 2.1 Nyheter ska kunna publiceras på olika delar av webbplatsen, till exempel specifikt för en avdelning eller fakultet. 2.2 En redaktör på en avdelning ska kunna ha begränsad åtkomst för att endast kunna publicera nyheter i en viss nyhetslista. 2.3 En nyhetslista ska kunna hämta upp nyheter från en eller flera delar av webbplatsen. 2.4 Det ska vara möjligt att återpublicera en nyhet i flera nyhetslistor på webbplatsen. 2.5 En redaktör ska via det redaktionella gränssnittet kunna föreslå för en huvudredaktör att en nyhet ska publiceras på flera ställen på webbplatsen. 5 (20)

6 3. Kalender Avser kalender som finns på webbplatsen och som beskriver händelser på hela universitetet, eller lokalt för en fakultet, avdelning eller enligt annan skärning av organisationen. Avser inte medarbetarnas personliga kalendrar. 3.1 Kalenderhändelser ska kunna publiceras på olika delar av webbplatsen, till exempel för en avdelning eller fakultet. 3.2 En redaktör på en avdelning ska kunna ha begränsad åtkomst att endast publicera kalenderhändelser i en viss kalender. 3.3 En kalender ska kunna hämta upp kalenderhändelser från en eller flera delar av webbplatsen. 3.4 Det ska vara möjligt att återpublicera en kalenderhändelse i flera kalendrar på webbplatsen. 3.5 Det ska vara möjligt för en redaktör att föreslå för en huvudredaktör att en kalenderhändelse ska publiceras på flera ställen på webbplatsen. 3.6 En informationslämnare ska kunna skapa en kalenderhändelse på webbplatsen (till exempel via ett formulär) och skicka in den för granskning. Informationslämnaren ska inte behöva gå in i det redaktionella gränssnittet. En redaktör ska kunna publicera kalenderhändelsen direkt, förutsatt att inga ändringar behöver göras. Detta ska vara möjligt att göra på olika delar av webbplatsen och utifrån detta ska olika redaktörer få kalenderhändelsen för granskning innan den publiceras. 3.7 Användare ska kunna lägga till en kalender som finns på webbplatsen till sin kalender på datorn och denna ska synkroniseras kontinuerligt. 6 (20)

7 4. Dokumenthantering I organisationen hanteras stora mängder med dokument och de behöver hanteras på ett konsekvent och effektiv sätt. Dokumenthanteringen kan både ske i webbpubliceringssystemet eller i ett externt tekniskt system. Vår bedömning är att Mittuniversitetet behöver ett separat dokumenthanteringssystem. Kraven nedan gäller oavsett om det är ett inbyggt eller externt tekniskt system för dokumenthantering. 4.1 På en sida och/eller komponent ska det vara möjligt att lista dokument som finns i dokumenthanteringssystemet baserat på ett eller flera villkor som en redaktör bestämmer. 4.2 Följande villkor ska man kunna använda sig av för att lista dokument: Katalog i dokumenthanteringssystemet. Om dokument i underkataloger ska visas. 4.3 En lista med dokument ska uppdateras dynamiskt om nya dokument som matchar villkoren läggs till i dokumenthanteringssystemet. 4.4 Om villkoret att dokument i underkataloger ska visas grupperas dokumenten med rubriker baserat på underkatalogerna. Grupperingen sorteras efter rubriken på gruppen. 4.5 Behörigheter som är satta i dokumenthanteringssystemet ska gälla även när dokumenten hämtas från webbplatsen. 4.5 Om dokumenthanteringssystemet är ett externt verktyg (molntjänst) ska följande funktioner kunna göras via API: 1. Indexera alla dokument för att kunna göra sökningar. Behörigheter och annan metadata för dokument ska följa med vid indexeringen. 2. Hämta listor med dokument baserat på ett eller flera villkor. Exempel på villkor är katalog, om underkataloger ska visas, senast uppdaterade, vem som äger dokumentet eller vem som senast redigerade dokumentet. 7 (20)

8 5. Min sida Min sida är medarbetarnas utgångspunkt eller startsida för medarbetarportalen. På Min sida får användaren en översikt av vad som sker och har skett på medarbetarportalen, utifrån vad som berör just hen. Alla krav som listas i tabellen nedan behöver inte visas på samma sida, men ska vara lätt tillgängliga för medarbetaren. Medarbetarna lyfter i behovsanalysen fram att de vill att medarbetarportalen ska vara tidsbesparande och aktuell, samt att informationen ska vara riktad till mig i min roll och organisatoriska tillhörighet. 5.1 Användarens sociala flöde (se kapitel 7 nedan) ska visas på Min sida. Det sociala flödet kan kombineras med flödet med nyheter och kalenderhändelser, om detta är möjligt ur ett användbarhetsperspektiv. 5.2 Användaren ska se de nyheter och kalenderhändelser som berör användaren i ett flöde. Urval görs baserat på användarens roll/organisatorisk tillhörighet och ska kunna anpassas av användaren själv. 5.3 Det som är nytt på medarbetarportalen sedan användaren loggade in sist ska visas på Min sida. 5.4 Användaren ska kunna få reda på nyckeltal som berör användarens anställning och länkar för att se mer information. Exempel: Månadslön eller hur många semesterdagar som är kvar för just den personen. 5.5 Användaren ska få reda på hen behöver göra i olika verksamhetssystem. Exempel: Att det är dags att söka semester, att hen har påbörjat en resebokning som inte slutförts eller att det är dags att kontrollera kursplaner. 5.6 Lista de projektytor som användaren är deltagare i. 5.7 Lista de senaste dokumenten som användaren har öppnat i dokumenthanteringssystemet. 5.8 Lista kontaktpersoner som användaren har inom olika områden. Exempel: Vem hanterar min lön? Vem hanterar videokonferenser i Sundsvall? Vem sköter min reseadministration? 5.9 Lista de integrationer med verksamhetssystem som har gjorts och länkar till andra verksamhetssystem som inte har någon integration. 8 (20)

9 6. Samarbets- och projektytor En samarbets- och projektyta är en funktion för att en grupp av användare under en begränsad tidsperiod ska kunna samarbeta kring en viss uppgift. Den kan antingen hanteras direkt i webbpubliceringssystemet eller i ett externt system. Skillnaden mot sociala flöden (beskrivs i nästa rubrik) är att sociala flöden är kopplade till en viss användare och existerar tills användaren tas bort. 6.1 Projektytor ska kunna skapas från medarbetarportalen av alla användare. (Systemet för projektytor kan dock vara ett externt verktyg.) 6.2 Till projektytan ska andra användare och externa personer (utanför organisationen) kunna bjudas in. 6.3 I projektytan ska följande uppgifter kunna utföras: 1. Skriva inlägg 2. Ladda upp filer 3. Kalender 4. Skapa sidor (wiki) 5. Lista deltagare i projektytan 6. Uppgifter (to do-listor) 6.4 Administratörer ska kunna ta bort projektytor. 6.5 Administratörer för samtliga projektytor ska kunna få ut en lista med inaktiva projektytor för att kunna stänga ner eller informera om att de ska stängas ner. 6.6 En användare som har tillgång till webbplatsen ska inte behöva logga in på nytt för att komma åt en projektyta som hen är deltagare i. 6.7 Projektytor ska både kunna vara privata och offentliga. Privat innebär att endast inbjuda deltagare får vara med. Offentliga innebär att alla anställda kan bli deltagare i projektet. Externa användare kan endast bjudas in till privata projektytor och inte offentliga projektytor. 9 (20)

10 6.8 Om projektytan är en molntjänst ska följande funktioner kunna göras via ett API: 1. Skapa projektyta 2. Användare ska vara synkroniserat med organisationens AD 3. Hämta uppdateringar av de projektytor som en användare är deltagare i. 4. Indexera alla typer av innehåll i alla projektytor för att kunna göra sökningar av innehåll utanför projektytan. Behörigheter för innehåll ska följa med vid indexeringen. 6.9 Utifrån ett eller flera villkor ska redaktörer kunna lista projektytor på en sida och/eller komponent på webbplatsen. 7. Socialt flöde Ett socialt flöde är kopplat till en viss användare på webbplatsen och används för mer informell information. 7.1 Användare ska kunna skriva meddelanden som andra som följer användaren ser. 7.2 Användare ska kunna kommentera meddelanden som andra användare har skrivit. 7.3 Användare ska kunna länka, lägga till bilder och lägga till dokument till ett meddelande eller till en kommentar. 10 (20)

11 8. Information om medarbetare Information om varje medarbetare i organisationen hanteras i ett medarbetarsystem. Detta kan antingen vara en del av webbpubliceringssystemet eller ett separat externt tekniskt system. Mer om sökning av medarbetare finns under rubriken Sök. 8.1 På en sida och/eller komponent ska det vara möjligt att lista medarbetare som finns i medarbetarsystemet, baserat på ett eller flera villkor som bestäms av en redaktör. 8.2 Följande urval av medarbetare ska kunna listas: 1. Roll 2. Funktion 3. Inriktning (till exempel professor i maskinteknik) 4. Ansvarig för kurs, ämne och/eller program 5. Avdelning/Fakultet 8.3 I sökresultatet ska användare kunna filtrera bland medarbetarna, baserat på de punkter som listas i 8.2 ovan. 8.4 När information om en medarbetare visas ska det stå vilken status (frånvaroinformation) som medarbetaren har för tillfället. 8.5 Från information om en viss medarbetare ska det vara möjligt att gå vidare till medarbetarens sociala flöde. 8.6 Användaren ska kunna uppdatera alla uppgifter om sig själv. 8.7 Administratör ska kunna få ut listor med roller, funktioner, ansvariga (se 8.2 ovan) som saknar en person. 8.8 Om medarbetarsystemet är en molntjänst ska följande funktioner kunna göras via ett API: Indexera samtliga medarbetare för att kunna användas i en sökfunktion Hämta listor med medarbetare utifrån vissa villkor 11 (20)

12 Hämta en viss medarbetares detaljerade information Ändra medarbetarens information 9. Sök På medarbetarportalen kommer sökfunktionen att vara viktig för användarupplevelsen och avgörande för att informationen ska vara hittbar. Sökfunktionen behöver ha stöd för att söka inte bara i webbpubliceringssystemet utan även i andra tekniska system. 9.1 Alla typer av innehåll ska kunna hittas via en sökfunktion, men det ska vara möjligt att begränsa vad som visas. Detta behöver specificeras i samband med att mer detaljerade krav för medarbetarportalen tas fram. Exempel: Bilder som finns i webbpubliceringssystemet ska inte visas i sökresultatet. 9.2 Följande typer av innehåll ska indexeras i sökfunktionen: 1. Sidor 2. Nyheter 3. Kalenderhändelser 4. Anställda 5. Byggnader och salar 6. Dokument 7. Samarbets- och projektytor som är offentliga 8. Diariet 9. Information på den externa webbplatsen 12 (20)

13 9.3 Vad som visas i sökresultatet baseras på vilka behörigheter som användaren har. 9.4 I sökresultatet ska det vara möjligt att filtrera på följande: 1. Typ av innehåll (till exempel dokument, film) 2. Kategorier (taggar som definieras) Även andra sätt att filtrera på definieras för respektive verksamhetssystem. 9.5 När en sökning påbörjas ska förslag på sökord visas, så kallad autosuggest. 9.6 Det ska vara möjligt att hantera synonymer och felstavningar i sökfunktionen. 9.7 Det ska vara möjligt att välja vilken sida som ska visas högst upp för ett visst sökord. 13 (20)

14 10. Integration med verksamhetssystem På Mittuniversitetet finns många verksamhetssystem som används i olika syften. De flesta medarbetare använder endast ett fåtal funktioner i dessa system. Även om vissa funktioner är relativt enkla att använda innebär användningen av ett separat system för att utföra uppgiften en börda för medarbetarna. Den frustration och tidsåtgång detta medför har varit ett tydligt återkommande tema i behovsanalysen. Att integrera vissa funktioner med medarbetarportalen skulle således skapa stor nytta och effekt samt underlätta för många medarbetare. Nedan listas de krav som finns på att skapa integrationer med verksamhetssystem, där användarna skulle kunna utföra uppgifterna direkt från webbplatsen, istället för att gå till verksamhetssystemet. Observera för varje krav nedan behöver det utredas om det är rimligt att skapa en integration. En framgångsfaktor för att utveckla integrationer är att Mittuniversitetets så kallade integrationsmotor är klar. Integrationsmotorn syftar till att på ett hållbart sätt integrera universitetets olika verksamhetssystem Resebokning 10.2 Ansöka om semester 10.3 Registrera sjukfrånvaro 10.4 Attestera utlägg 10.5 Boka möten (teknik, lokal och så vidare) 10.6 Helpdesk 10.7 Driftinformation 10.8 Diariet 10.9 Listor med programansvariga, kursansvariga. Få information om när ett ansvarsområde byter person Se lönebesked Ansöka om föräldraledighet Hitta byggnader och salar 14 (20)

15 11. Användare och behörigheter Användare ska ha olika behörigheter för olika delar av medarbetarportalen Inloggning på webbplatsen sker automatiskt i samband med att användaren loggar in på sin dator Inloggningen för användare ska vara kopplad till organisationens AD När användarna är inloggade på webbplatsen ska de ha tillgång till alla andra verksamhetssystem utan att behöva logga in på nytt. 15 (20)

16 12. Förutsättningar Det finns ett antal tekniska och organisatoriska förutsättningar och framgångsfaktorer för framtagandet av en medarbetarportal. Vi har under förstudien identifierat följande tekniska förutsättningar och framgångsfaktorer: Integration med andra verksamhetssystem bör göras i mindre skala och endast i de fall det bedöms som enkelt, innan integrationsmotorn är redo att användas. Integrationsmotorn syftar till att på ett hållbart sätt integrera universitetets olika verksamhetssystem. Detta arbete görs av IT-avdelningen och måste prioriteras. Bestämma hur inloggningar för medarbetare på Mittuniversitetet ska fungera för verksamhetssystemen. Det/de verksamhetssystem som väljs ut för integration med medarbetarportalen behöver finnas på plats och inte stå inför att de ska bytas ut i närtid. När Mittuniversitetet köper in nya system måste det kravställas att dessa system har ett öppet API som gör att det går att integrera med EPiServer och andra system. Om de inte har ett öppet API skall det kunna integreras på annat sätt. Dessutom finns ett antal organisatoriska förutsättningar är viktiga att ta hänsyn till: Det kommer att behövas personella resurser både för projektet att utveckla en första version av medarbetarportalen och för vidareutveckling och förvaltning. Utse systemägare för medarbetarportalen. Rutiner och riktlinjer för uppdatering och publicering av innehåll på medarbetarportalen behöver definieras, inklusive en förvaltningsorganisation. Förankring av medarbetarportalen hos universitetets anställda är en viktig framgångsfaktor. Hornsbruksgatan 19 SE Stockholm T: +46 (8)

17 13. Utveckling av medarbetarportalen 13.1 Prioriterat till en första version Baserat på insamlade behov, samt utifrån de tekniska förutsättningar som råder på Mittuniversitet rekommenderar vi att nedanstående delar prioriteras i en första version av medarbetarportalen. Observera att en hel del av kraven redan finns på den externa webbplatsen miun.se och går att återanvända. Webbpublicering Min Sida med de tre första kraven: o o o 5.1: medarbetarens sociala flöde 5.2: nyheter och kalenderhändelser i ett flöde, anpassat utifrån roll/organisatorisk tillhörighet och kan anpassas av användaren. 5.3: visa det som är nytt på medarbetarportalen sedan användaren loggade in senast. Det är viktigt att konceptet tar höjd för att även övriga krav för Min Sida ska kunna mötas i interaktionsdesignen, redan i medarbetarportalens första version. En integration med verksamhetssystem som är relativt enkel att utveckla och som skapar stor effekt, det vill säga stor nytta för många användare. En sådan integration skulle kunna vara: o Att visa e-post via integration med Office 365 o o Socialt flöde Nyheter Kalender Att visa driftsinformation Att visa felanmälan/ärenden via integration med ärendehanteringssystemet Nilex (Servicecenter med flera kommer att använda Nilex i större utsträckning i höst). Information om medarbetare Sökfunktion (baseras på den som idag används på miun.se) Personalisera innehållet, dvs. att medarbetarna kan anpassa innehållet på sin sida. 17 (20)

18 13.2 Vidareutveckling i ett senare skede Följande krav och delar är lämpliga att utveckla i framtida versioner av medarbetarportalen. Samarbets- och projektytor (kan ev. prioriteras att ha med i en första version, förutsatt att en färdig lösning som Projectplace används) Utöka informationen om medarbetare Vidareutveckling av sökfunktionen Övriga relevanta krav för Min sida ( ) Dokumenthantering (behov av separat system/lösning) Fakturahantering Egenrapportering o o Palasso, Agresso och andra personalsystem där man t.ex. kan registrera sjukfrånvaro eller se lönebesked har inget öppet API och kan därför inte på ett enkelt sätt integreras med en medarbetarportal idag. Avvakta med dessa tills integrationsmotorn är i drift. Ladok3 kommer 2017 och bör tas i beaktning. Gemensam kalenderfunktion Scheman och andra saker som finns i Studentportalen bör ligga kvar och utvecklas där. 18 (20)

19 14. Ordlista Nedan förklaras de begrepp som förekommer i kravspecifikationen. Begrepp Administratör Användare Avdelning Fakultet Huvudredaktör Informationslämnare Komponent Organisation Publicerare Förklaring En användare som har tillgång till mer administrativa funktioner som sällan används och/eller som kan påverka det tekniska systemet negativt om användaren gör ett misstag. En anställd som har behörighet att använda medarbetarportalen. Kan vara avdelning inom akademin (som då tillhör någon av fakulteterna) eller övrig avdelning (t.ex. kommunikationsavdelning). Mittuniversitetet har två fakulteter. Behörighetsgrupp som idag finns på miun.se. Huvudredaktörerna är ansvariga för en större del av webbplatsen. Främst handlar det om personer på Kommunikationsavdelningen, men något undantag kan förekomma. Huvudredaktören har denna arbetsuppgift tydligt införd i sin befattningsbeskrivning. 1 Informationslämnarna ingår formellt inte i webborganisationen. Alla anställda inom Mittuniversitetet har ett informationsansvar och är potentiella informationslämnare till webbplats och medarbetarportal. Det är upp till informationslämnarna att lämna information till respektive huvudredaktör på det sätt hen finner lämpligt. 2 En komponent kan återanvändas på flera sidor och har inte en unik webbadress (URL). Organisationen som avses är Mittuniversitetet. Behörighetsgrupp som idag finns på miun.se. För att tillgodose behovet av att snabbt kunna publicera enklare information på webben finns möjligheten att bli publicerare. Det innebär att man får rätt att redigera en mycket begränsad del av webben (i praktiken för att kunna publicera nyheter, protokoll och dylikt). Publiceraren kommer ej ha behörighet att skapa eller ta 1 Webborganisation-for-miun-2013_ Webborganisation-for-miun-2013_ (20)

20 bort sidor utan införande av funktionen redaktörstöd. 3 Redaktionellt gränssnitt Redaktör Det gränssnitt som redaktörer använder för att arbeta med innehållet på webbplatsen. Behörighetsgrupp som idag finns på miun.se. Redaktören ansvarar för en tydligt begränsad del av webben, oftast en startsida med underliggande sidor. Redaktören kan redigera de sidor hen har behörighet till, i samarbete med en huvudredaktör. För att behålla sina rättigheter skall redaktören medverka på minst 1 redaktörsmöte per termin. Redaktören skall ha avsatt tid i sin tjänst för redaktörsarbetet. I dokumentet används begreppet redaktör för att beskriva behörighetsgrupperna Huvudredaktör, Redaktör och Publicerare, om inte annat anges. 4 Sida Webbkoordinator Webbplatsen Webbredaktion Digitalt råd En sida på webbplatsen som har en unik webbadress (URL). Behörighetsgrupp som idag finns på miun.se. Övergripande ansvar för miun.se. 5 Organisationens medarbetarportal (intranät). Består av webbkoordinator och huvudredaktörer. Är den grupp som håller i den dagliga skötseln av innehållet på webben och fungerar som ett stöd för andra redaktörer. Träffas var 14:e dag och diskuterar problem, status och utveckling av webben. Det digitala rådet ska vara stödjande genom att vara ett bollplank till systemägare och webbkoordinator i viktiga strategiska beslut. Syftet med att ha ett digitalt råd är att få en bred förankring i hela organisationen för webbarbetet. Rådet består av systemägare, webbkoordinator, representanter från huvudredaktörerna och IT-avdelning samt andra intressenter som t.ex. LRC, leverantörer osv. Rådet träffas 2-4 gånger per år. 6 3 Webborganisation-for-miun-2013_ Webborganisation-for-miun-2013_ Webborganisation-for-miun-2013_ Webborganisation-for-miun-2013_ (20)