2007-12-10 Dnr SLU ua 230-2756/07 Förstudie kravinsamling och lösningsutvärdering för en kontraktshanteringsprocess Projektledare: Marek Petryk, JEP, extern 1(23)
File: Förstudie KTM.doc Innehållsförteckning 1 Sammanfattning efter intervjufasen... 4 2 Inledning... 5 2.1 Bakgrund... 5 2.2 Mål... 5 2.3 Projektets dokumentation... 5 3 Kontraktsmodulen... 6 3.1 Kontraktsmodulens mål... 6 4 Kravinsamlingen... 6 4.1 Kravgrupper... 6 4.1.1 Kontraktsutformning... 9 4.1.2 Projekt- och kontraktsregistrering... 10 4.1.3 Framtagning av inbetalningsdokument fakturor och rekvisitioner... 10 4.1.4 Bevakning av periodiserade inbetalningar och andra händelser... 11 4.1.5 Kontraktsavslutning... 11 4.1.6 Informationsåtkomst... 12 4.1.7 Teknik, IT-miljö och säkerhetsfunktioner... 12 4.1.8 Integration för samspel med Agresso... 13 4.1.9 Integration inom SLU... 13 4.1.10 Övrigt kring KTM... 15 4.1.11 Övrigt utanför KTM... 16 4.2 Befintlig lösning - omdöme från dem som kan den... 17 4.3 Generella krav... 18 4.4 Krav från systemnära intressenter... 18 4.5 Krav från strategiska intressenter... 18 4.6 Särskilda krav kontrakt med utlandet... 19 4.7 Särskilda krav - förstärkt processtöd för de mest behövande... 19 4.8 Om Kravspecifikationen enl. resultatdokumentet A (bilaga)... 19 4.9 Summering av intervjufasen... 20 5 Lösningsutvärdering... 22 5.1 Om utvärderingsfasen enl. resultatdokumentet B (bilaga)... 22 2(23)
Resultatdokument: A Kravspecifikation för KTM.doc ( 19/nov/07) B KTM lösningar och utvärdering.doc (10/dec/07) Bilagor. Bilaga 1 Projektaktiviteter.doc Bilaga 2 Behovstabeller Kontraktsutformning.doc Bilaga 3 - Behovstabeller Projekt- och kontraktsregistrering.doc Bilaga 4 - Behovstabeller Inbetalningsdokument faktura_rekvisition.doc Bilaga 5 Behovstabeller Bevakning och signalering.doc Bilaga 6 - Behovstabeller Kontraktavslutning.doc Bilaga 7 - Behovstabeller Informationsåtkomst och rapporter.doc Bilaga 8 Behovstabeller Teknik_IT-Miljö_Säkerhet.doc Bilaga 9 - Behovstabell Integration med Agresso.doc Bilaga 10 - Behovstabeller Integration inom SLU.doc Bilaga 11 - Behovstabell Övriga krav kring KTM.doc Bilaga 12 - Behovstabeller Övrigt krav utanför KTM.doc Bilaga 13 Kravinsamling sammanfattning.ppt 3(23)
1 Sammanfattning efter intervjufasen Genomförande och omfattning På plussidan Stort antal personer intervjuades (54 individer) Stor spridning av de intervjuade vad gäller roller, organisatorisk tillhörighet, relation till kontraktshantering, position i organisatoriska hierarkier Stor volym och bredd på det insamlade materialet De nya processbilderna gav bra struktur på intervjuerna På minus sidan Lång tid för genomförande och kort för analys Del av materialet berör inte KTM Det saknades visualiseringsmedel för presentation av utvecklingsmöjligheter (ex.demo) Resultat - bedömning av nuvarande Projektmodulen På plussidan Acceptabel funktionell nivå för hantering av basuppgifter Det finns stöd för de oftast förekommande kontrakts-/projektvarianter Nära integration med Agresso ekonomisystemet är mycket uppskattat På minussidan Kritik på faktura-/rekvisistionsframställning Kritik på att det saknas signaleringssystem om kommande inbetalningar/rapporteringstillfällen Kontraktsdatabasen anses ha en låg kvalitetsnivå och inte tillfredställande innehåll Innehållet i databasen anses vara svårtåtkomlig för spontana intressenter med speciella informationsbehov Systemstödet för utländska kontrakt är minimalt Användargränssnittet upplevs ibland som svårt och det finns buggar Resultat - bedömning av nuvarande processhanteringen På plussidan Det sprids information om betydelsen och nyttan av själva processtänkandet Det finns intuitiv förståelse och många egna försök att stödja befintliga processer På minussidan Det finns ett litet intresse och förståelse för processtänkandet hos systemnära intressenter i organisationen som helhet 4(23)
Inställning till förbättringsideer På plussidan Generellt en stor acceptansvilja för förbättringar Acceptans för de presenterade möjligheterna till förbättringar På minussidan Relativt få egna förslag till förbättringar av systemstödet Fokusering på negativa aspekter vid ev. införande av förbättrat systemstöd (ex. för stor registreringsvolym, alltför sällsynta projekttyper) Resultat kravinsamling På plussidan Många och detaljerade krav Stor variation och bredd på kravbilden På minussidan Svårt att hantera blandning av viktiga och mindre viktiga krav Svårt att hantera prioritetsbild vid kravsortering och ackumulering 2 Inledning 2.1 Bakgrund Den nya projektredovisningsmodellen (efter PRIS) och den kommande uppdateringen av Agresso skapar ett lämpligt tillfälle att belysa helheten kring hanteringen av kontrakt som hanterar extern forskningsfinansiering. 2.2 Mål Att ta fram ett dokument KTM kravspecifikation, som delmål för etapp-1. Dokumentet skall sammanställa krav utformade av olika intressentgrupper på SLU och vara basen för utvärderingen av externa systemstödslösningar för hantering av kontraktshanteringsprocessen. Ett delmål för etapp-2 är framställningen av ett dokument till KTM lösningar och utvärdering. Detta dokument kommer att ge underlag för beslut på SLU vid valet på vilket sätt man skall utveckla systemstödet vidare för kontraktshanteringsprocessen. 2.3 Projektets dokumentation De ovannämnda, i kap. 2.2, måldokumenten finns som speciella bilagor (Resultatdokument) till denna Förstudie, i form av separata filer. Under rubriken Bilagor finns de övriga dokument/filer med detaljerad bakgrundsinformation. Dokumentet Projektaktiviteter, som finns med bland bilagor, fokuserar på själva projektjobbet - med tidplanen, sättet att bedriva arbete, kontrollpunkter och tabeller med statistik över intervjuade intressenter (etapp-1) och kort information om de kontaktade högskolorna (etapp-2). 5(23)
De följande bilagorna (från nr 2 till 12) består av behovstabeller, dvs. en sorterad samling av ursprungliga krav/behov som samlades under intervjuarbete och presenteras i dessa filer i originalformat, utan alltför stora korrigeringar. Sorteringen och ackumuleringen av alla samlade krav i mindre grupper med liknande behov styrdes av ambitionen att dels följa kontraktshanteringsprocessen, dels att skapa bättre överblick för läsare som är kanske bara intresserade av vissa delar av det samlade materialet. Varje dokuments krav är kort kommenterade i respektive kapitel under huvudkapitel 4.1. Sist bland bilagor ligger en liten PowerPoint fil; Kravinsamling sammanfattning, med kort presentation av resultat för bara etapp-1. 3 Kontraktsmodulen 3.1 Kontraktsmodulens mål Målet med att använda ett kontraktshanteringssystem kan sammanfattas i två punkter; Att få ett systemstöd till arbetsflödet som hanterar de parametrar i de kontrakt som har en ekonomisk betydelse för SLU. Effektivare ekonomisk hantering av ärenden, hög kvalitet på den registrerade informationen och bättre fungerande ekonomiska rutiner är det önskade resultatet av detta mål. Att få stöd till hela kontraktshanteringsprocessen som omfattar inte bara stöd till utförandet av ekonomiska operationer, men i en bredare mening stöd till alla intressenter i processen. Olika intressenternas behov måste hanteras i samverkan för att kunna uppnå hög effektivitet och kvalitet i hela processen. Som man ser leder det första målet till ett mindre kravspektrum än det andra. För att tillfredsställa det första målet skapade man den nuvarande Projektmodulen, som ger det mest nödvändiga stödet man behöver. För att höja kvaliteten på informationen i systemet och effektivisera arbetet i processen måste man ha en mera avancerad lösning som troligen kan omfatta både organisatoriska förändringar och ett bättre systemstöd. 4 Kravinsamlingen 4.1 Kravgrupper Den mest användbara sorteringen av intervjumaterialet bör vara den som tar hänsyn till kravfördelningen längs processkedjan. Ett försök att göra det skall visas i detta kapitel. Det var inte lätt att kvalificera varje behov rätt. Ganska ofta berör man i samma krav flera olika funktioner inom samma kravformulering. Och de snabba anteckningarna under 6(23)
intervjuer överförda i en excelmall inte alltid är tillräckligt exakta för att entydigt kunna placera kravet inom en viss grupp. En begränsad tid för att genomföra denna omsortering resulterade också i att vissa krav kunde hamna i en fel grupp. Men beslutet att visa det mesta av det insamlade materialet i form av separata filer med grupper av krav gör att varje läsare som är djupare intresserad i en vis del av processen kan själv granska den delen, se vad som finns där och dra egna slutsatser. Det blev 11 grupper av krav som man kan se i den följande tabellen. Inom varje grupp sker ytterligare samsortering/ackumulering av kravrader så att nästa detaljnivå kommer fram. Med hjälp av denna tabell kan man göra en generell uppskattning var fokus och intresse låg hos de intervjuade. 7(23)
Kravsammanställning - fördelning enligt kravspecifikationens behov Kravgrupper(antal undergrupper) Undergrupper Krav rader A. Kontraktsutformning (37) Kontraktsutformning - ansökan 8 Kontraktsutformning - diariet 6 Kontraktsutformning - inform. 8 Kontraktsutformning - kalkyl 10 Kontraktsutformning - övrigt 5 B. Projekt- och kontraktsregistrering (19) Kontrakt - e-dokument 5 Kontrakt - information 3 Kontrakt - OH 3 Kontrakt - regelverk 8 C. Framtagning av inbetalningsdokument (14) Faktura-rekvisition 14 D. Bevakning av periodiserade inbetalningar (16) Signal med ärendehantering 2 Signal om inbetalningsdags 11 Signal om kontraktsslut 3 E. Kontraktsavslutning (11) Kontraktsavslut 7 Kontraktsavslut disp.tid 4 F. Informationsåtkomst (24) Rapport - gränssnitt 8 Rapporttyp 7 Rapportutskick 2 Information - åtkomst 4 Information - analys 3 G. Teknik, IT-miljö och säkerhetsfunktioner (18) Teknik - IT-miljö 6 Teknik - säkerhet 3 Teknik - förvaltning 6 Teknik - dokumentation 3 H. Integration för samspel med Agresso (3) Agressokompatibilitet 3 I. Integration inom SLU (41) Nyutveckling - Agresso 5 Utveckling - integration 3 Utveckling - nya fält 24 Utveckling - inputkontroll 2 Utveckling - automatisering 3 Utveckling - budgetuppföljning 2 Utveckling - generellt 2 J. Övrigt - kring KTM (39) Buggar 4 Enkelhet 8 Sekretess 5 Särskilda projekt 7 Utland koordinatorssupport 2 Utland - support 13 K. Övrigt utanför KTM (17) OH - generellt 1 Övriga behov - sparbuffert 6 Övrigt - forskning 5 Övrigt - organisation 3 Övrigt - regelverk 2 8(23)
En statistisk sammanfattning av de samlade kraven fördelade på den grövsta nivån visas i tabellen nedan. Fördelning av antalet kravrader per kravgrupp Antal kravrader % A. Kontraktsutformning 37 15 B. Projekt- och kontraktsregistrering 19 8 C. Framtagning av inbetalningsdokument 14 6 D. Bevakning av periodiserade inbetalningar 16 7 E. Kontraktsavslutning 11 5 F. Informationsåtkomst 24 10 G. Teknik, IT-miljö och säkerhetsfunktioner 18 8 H. Integration för samspel med Agresso 3 1 I. Integration inom SLU 41 17 J. Övrigt - kring KTM 39 16 K. Övrigt utanför KTM 17 7 TOTALT 239 100 Man kan se att de grupper där kraven kom både från systemnära- och strategiintressenter har höga siffror i tabellen. Det gäller främst grupper kontraktsutformning, informationsåtkomst och integration inom SLU. Hög andel av Övrigt kring KTM kommer mest på grund av att där hamnade alla frågor kring hanteringen av utlandsfinansiering och projekt med speciella behov dvs. två områden som kräver mycket stöd. Statistiktabeller - en för varje kravgrupp - finns längre fram i detta dokument, i varje kapitel som tar hand om en funktionsgrupp. 4.1.1 Kontraktsutformning Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 2. Kravfördelning inom gruppen A. Kontraktsutformning Antal % Kontraktsutformning - ansökan 8 22 Kontraktsutformning - diariet 6 16 Kontraktsutformning - information. 8 22 Kontraktsutformning - kalkyl 10 27 Kontraktsutformning - övrigt 5 14 Totalt 37 100 9(23)
I intervjusamtalen kring den delen av processen var det mycket frågor om korrekt och begriplig information och dokumentation. Dels var det troligen en extra påverkan av det parallellt pågående PRIS-projektet, men orsaken var även de genuina behoven av klarhet kring egna arbetsuppgifter. Man undrade vad det är som egentligen gäller, hur man skall göra för att göra rätt, vad lagen säger, vad man måste göra (regelverk). Frågan om man skall lagra kalkyler och projektbeskrivningar, som är grunden till framtida avtal, eller inte lagra är inte alltför intressant för de stora grupperna av intressenter. Det är viktigt med lagring för dem som ansvarar för juridiken, uppföljning, analys och statistik, och även för dem som ser nytta av mallar och lagring som form av kvalitetssäkring av det kommande avtalet. Om alla fält är korrekt ifyllda innan kontraktet är utformat - blir det med större sannolikhet korrekt även vid tidpunkten då kontraktet är färdigt till underskrift och registrering. 4.1.2 Projekt- och kontraktsregistrering Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 3. Kravfördelning inom gruppen B. Projekt- och kontraktsregistrering Antal % Kontrakt - e-dokument 5 26 Kontrakt - information 3 16 Kontrakt - OH 3 16 Kontrakt - regelverk 8 42 Totalt 19 100 Här syns det ännu mera att regelverk och information upplevs i det här steget som bristområdena. Men egentligen är det för sent att informera och dokumentera så sent i processen. Man bör göra det innan, i det första förberedande steget och då skulle man inte uppleva problemen här. 4.1.3 Framtagning av inbetalningsdokument fakturor och rekvisitioner Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 4. Kravfördelning inom gruppen C. Framtagning av inbetalningsdokument Antal % Faktura - rekvisition 14 100 Här är det frågan om en mycket samstämmig opinion. Den nuvarande lösningen anses vara för krånglig och man vill ha ett enklare sätt att hantera dessa egentligen ganska enkla uppgifter. Även vid fortsatta användning av den befintliga lösningen inom den nya releasen måste man göra något åt denna grupp av funktioner. Att man vill ha engelskspråkiga 10(23)
fakturor/rekvisitioner och att man inte vill ha buggar i det krångliga systemstödet som finns nu känns bara som små detaljer i sammanhanget. 4.1.4 Bevakning av periodiserade inbetalningar och andra händelser Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 5. Kravfördelning inom gruppen D. Bevakning av periodiserade inbetalningar Antal % Signal med ärendehantering 2 13 Signal om inbetalningsdags 11 69 Signal om kontraktsavslut 3 19 Totalt 16 100 Att man saknar systemstöd för signaler om att det är dags för nästa inbetalning vet alla på lokalnivå och de har egna signallösningar. Att det är ett allmänt bekymmer syns tydligt genom att det finns ganska stort antal kravrader. Hur viktigt det är att göra kontroller även i slutet av projektet upplevs tydligen inte som ett lika stor bekymmer, är det bara några som efterfrågar det. Många vet inte om de nya möjligheterna att signalera med ev. samtidigt leverans av underlagsinformation via funktioner av ett ärendehanteringssystem. Därför är denna grupp av krav inte representerad här med stort antal frågor. 4.1.5 Kontraktsavslutning Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 6. Kravfördelning inom gruppen E. Kontraktsavslutning Antal % Kontraktsavslut 7 64 Kontraktsavslut - dispositionstid 4 36 Totalt 11 100 Kraven i denna tabell är ganska spridda i sin art och berör följande ämnen; behovet av forskarrapporter som en av avslutningsparametrar, behovet av regelverk, rutiner, och information just i denna fas. En liten grupp av olika krav fokuserar här begreppet dispositionstid, som blev mera känd tack vare Pris-projektet. 11(23)
4.1.6 Informationsåtkomst Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 7. Kravfördelning inom gruppen F. Informationsåtkomst Antal % Rapport - gränssnitt 8 33 Rapporttyp 7 29 Rapportutskick 2 8 Information - åtkomst 4 17 Information - analys 3 13 Totalt 24 100 Den första gruppen av krav som handlar om gränssnittet önskar man en sak enkelhet i gränssnittet. Behoven i gruppen Rapporttyp listar ut olika varianter av rapporter ex. status just nu, med forskaren som huvudnyckel, stor och överskadlig rapport för halvårsuppföljning och en rapport med information om finansieringsmedel planerade/säkrade för det kommande året. Det är några spontana förslag som visar att vid skapandet av nya standardrapporter bör man vara i direkt kontakt med potentiella användare och stämma av med dem direkt om de trivs med förslaget eller vill ha något annat. Få yttrar sig i nästa gren Rapportutskick - men man vill ha dessa utskick. D.v.s. en aktiv handling i stället för bara öppnad möjlighet att hämta information. En aktiv support i processen är en idé bakom ärendehanteringssystemet och rapportutskick kunde ingå i denna lösning. Åtkomst av informationen fokuserar på analytikers behov. De behöver alla sorter av information, inte bara kring den ekonomiska uppföljningen, men också för koppling mellan forskning och ekonomi eller bara information om forskningsinriktning. Det är inte många av den typen av intressenter på SLU, men deras behov har en stor tyngd. Även den sista gruppen av krav fokuserar på behov från samma intressentgrupp analytiker, där högre kvalitet på lagrat data pekas ut, samt vikten av samverkan mellan analytiker och forskarkåren. 4.1.7 Teknik, IT-miljö och säkerhetsfunktioner Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 8. 12(23)
Kravfördelning inom gruppen G. Teknik, IT-miljö och säkerhetsfunktioner Antal % Teknik - IT-miljö 6 67 Teknik - säkerhet 3 33 Teknik- förvaltning 6 67 Teknik - dokumentation 3 33 Totalt 9 100 I gruppen som samlar frågor kring IT-miljö har man frågor kring drift, datakommunikation och integration med övriga system på SLU där man pekar ut MOSS som stödplattform för systemutveckling i framtiden. I frågor gällande säkerhet pekar man ofta på Single SignOn, samt behovet av loggning av aktiviteter för en korrekt hantering av spåbarhet. Inom delgruppen som hanterar förvaltningsfrågor pekar man ut följande parametrar; MS SQL Server för datalagring krävs, nivån på leverantörssupport bör utvärderas, lika väl som versionshantering och behörighetslösningen. Tekniker lärda av tidigare erfarenheter har också tydliga krav på den dokumentation som de vill ha på en viss nivå (med databas och metadata beskrivningar), som ofta saknas ex. för nuvarande Agresso. 4.1.8 Integration för samspel med Agresso Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 9. Kravfördelning inom gruppen H. Integration för samspel med Agresso Antal % Agressokompatibilitet 3 100 Det är en liten men viktigt kravgrupp om man inte vill ha för mycket jobb med anpassningar i Agresso till det eventuella nya KTM. Detta krav ligger högt bland de viktigaste i kravspecifikationen och kan vara ett av de svåraste att tillfredsställa av möjliga fristående lösningar för KTM. 4.1.9 Integration inom SLU Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 10 13(23)
Kravfördelning inom gruppen I. Integration inom SLU Antal % Nyutveckling - Agresso 5 12 Utveckling - integration 3 7 Utveckling - nya fält 24 59 Utveckling - inputkontroll 2 5 Utveckling - automatisering 3 7 Utveckling - budgetuppföljning 2 5 Utveckling - generellt 2 5 Totalt 41 100 Här finns en hel del behov/krav som berör den framtida lösningen, dvs. skapande av en ny bättre kontraktsmodul. En del av behoven som finns i denna tabell kan troligen tillfredsställas med hjälp av nuvarande Agresso i ny releaseversion. Den första delgruppen Nyutveckling Agresso - fokuserar mycket på vad man kan göra bättre om man nyttjar Agressos databas i samspelet med andra system som ex. rapporteringsstöd och integration med ny KTM. Här hamnade också en fråga om utökad användning av Projektmodulen för en vanlig projektuppföljning. D.v.s. en konkurrerande användning av samma projektstödjande Agresso-funktionalitet för andra ändamål än KTM. Mera om det finns inom Tabellen Övrigt kring KTM, och där inom gruppen Särskilda projekt. I gruppen Utveckling automatisering pekas ut behovet av en enklare lösning av nuvarande KTM. Projektdel-periodiseringar bör inte kräva någon input och extra stöd för framtagning av ett kontraktsnummer enligt kravställare. Det finns även en fråga om en möjlig hantering av små kontrakt under samma KTM-paraply, där bara framtagning av faktura skulle få stöd. Det är önskat under villkoret att stödet från den nya KTM lösningen skall fungera enkelt, snabbt och ge direkt information till Agresso. Två frågor gäller möjligheten att följa upp budget. Man gör det manuellt i viss mån, men man kunde automatisera det om det skulle finnas ett tillräckligt systemstöd och rätt underlag från början av processen kalkyl som budgetunderlag och ev. möjligheter till prognoser år efter år. För stora, fleråriga projekt är det en intressant tanke. I övriga grupper finns det olika typer av idéer, där man bl.a. pekar på behov av ett webbgränssnitt, på behov av att använda nyckelfält som bör vara lika i olika system, på vikten av behörighetshantering för att skapa enkelhet i användargränssnittet genom en begränsad informationsvolym tillgänglig för varje individ. Den stora mängden av krav i raden Utveckling nya fält har mycket blandat innehåll, där den gemensamma nämnaren är behovet av nya fält, eller nya användningssätt av befintliga fält. Fält som man gärna vill se är ex. Finansiären-fältet, Kön-fältet (pga. för korta Personnummer-fälten), SCB-kodfältet, Abstrakt-fältet, Sekretsskydd-fältet, samt flera fält med information om kontraktsinbetalningar framåt i tiden år efter år, flera fält för hantering av koordinator/partner roller och dessa speciella projekt. Utöver det finns även behovet av informationsstöd på engelska här och man pekar på vikten av vissa nyckelfält vid samkörning av information från flera system. 14(23)
Denna del bör man titta extra noga på i nästa del av projektet då man analyserar lösningar. I kravspecifikationen finns inte alltid krav på så låg detaljnivå, därför denna tabell kan vara lämplig för en extra avstämning för kontroll om allt i den utvärderade lösningen finns på plats. 4.1.10 Övrigt kring KTM Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 11. Kravfördelning inom gruppen J. Övrigt - kring KTM Antal % Buggar 4 10 Enkelhet 8 21 Sekretess 5 13 Särskilda projekt 7 18 Utland - koordinatorssupport 2 5 Utland - support 13 33 Totalt 39 100 Information om buggar i nuvarande systemet och behovet av ett enklare gränssnitt och hanteringsflöde är inte något nytt. Vid arbete med en övergång till den nya releasen av Agresso bör man titta på dessa tabeller för att försäkra sig om att inget av de kända kraven missas. Flera buggar är listade i kapitel 6.2.5 i ett annat dokument framtaget på SLU, som beskriver kontraktshanteringsprocessen Slutrapport: Inbetalningar, från 26 sept 2007, framtagen av Karolina Bergström på JEP. Sekretessdelen pekar både på policy- och informationsbehovet i denna fråga, samt behov av systemstöd. Om man tar beslutet att kontrakts- och projektinformation är skyddat måste man ha möjlighet att fullfölja detta beslut och skydda materialet inom och utanför systemet. Det lägsta nivån som man bör ha - är ett sekretessfält som informerar att just detta projekt är skyddat. Men man kan utöva skydd på betydligt mera avancerade sätt med behörighetsskydd t.ex. Det är en blandning av system- och informationsbehov i denna kravtabell. Särskilda projekt är benämningen av projekt som på något sätt är annorlunda än de vanligast förekommande. Det är en motsats till typiska projekt. En annan karaktärsparameter är att särskilda projekt oftast är mera komplicerade än de typiska. I gruppen särskilda projekt ingår oftast projekt som har finansiering från utlandet, blandad inhemsk och utländsk finansiering och även sådana med bara svensk finansiering men som tillämpar koordinator/partner lösningar i hanteringen av samarbete och finansiering. Ett exempel för särskilda projekt är CBM:s hantering av SIDA:s finansiering till 3.e världen, som är ganska unik på SLU. Den typen av projekt kräver extra bra stödlösningar. De sköter en komplicerad verksamhet där administrationskostnader måste bli låga för att kunna behålla förtroende hos finansiären. 15(23)
De två sista del-tabeller samlar behoven av dessa lite udda aktiviteter, som lider av alltför svagt systemstöd och oftast också av otillräcklig informations- och organisationsstöd. När man tittar närmare på behoven av dessa projekt ser möjliga systemstödslösningar mycket lika dem, som SLU söker för stöd för typiska kontrakt. Fast för särskilda projekt är man minst lika mycket intresserad av utbetalningar och inkommande rapporter, som KTM är intresserad av inbetalningar och forskarrapporter som skickas ut. Det kan innebära att en KTM modul kunde man lätt (?) återanvända i en kopierad och lite anpassad version för ett kraftfullt hanteringsstöd till olika särskilda projekt. Den tanken kan man kanske utveckla vidare i nästa etapp då utvärderingarna av stödsystem visar om en sådan extra tillämpning kan finns bland de verkliga lösningsalternativen. 4.1.11 Övrigt utanför KTM Innehållet av de rader med behov som listas i tabellen nedan finns i sin helhet tillgängliga i ett separat dokument, Bilaga 12. Kravfördelning inom gruppen K. Övrigt - utanför KTM Antal % OH - generellt 1 6 Övriga behov - sparbuffert 6 35 Övrigt - forskning 5 29 Övrigt - organisation 3 18 Övrigt - regelverk 2 12 Totalt 17 44 Här hamnade kraven/behoven som inte har mycket att göra med KTM, men som var så angelägna för de intervjuade intressenter att man fick dem med hit. Det kan vara av intresse att veta vad forskarna är mest intresserade att diskutera just nu. Det är en stor oro bland forskarna kring de nya reglerna som gör att deras finansiella säkerhetsbuffertar med sparade pengar kommer att minska eller försvinna inom kort. Forskarna vädjar om hjälp uppifrån för att kunna hantera de situationer där man tills nyligen kunde utnyttja de buffrade beloppen. Även en del av organisatoriska förslag hamnade i denna grupp. 16(23)
4.2 Befintlig lösning - omdöme från dem som kan den En generell inblick i svaga sidor av den nuvarande Kontraktshanteringsmodulen ger följande tabell. Den var skapad efter att ca 50% av intervjuade var tillfrågade och visar den relativa tyngden av vissa frågor när den systemnära delen av intressenter lämnade sina åsikter. Sammanfattning av kravinsamlingen tom v42 Nr Område med kraven Antal krav per kravområde 1 Faktura/rekvisition 14 2 Signaleringsbehov 11 3 Agresso - kompatibilitet o.d. 9 4 Rapporter 9 5 Informationsbehov 8 6 Enkelhet 7 7 A-delen (sökning av finansiering) 6 8 IT/SLU:s miljö 6 9 Kontraktsutformning 5 10 Utland - stöd 5 11 Utveckling av nuläge 5 12 Buggar i nuvarande KTM 4 13 Diariefrågor 3 14 OH 3 15 Projektstöd via egen modul 3 16 e-dokument 1 17 Kvalitet 1 * Antal personer utfrågade för denna tabell var 26 individer ** Typiska intressenter i denna fas: "systemnära", **** Flera av kraven inom vissa områden är helt identiska! De flesta hade negativa åsikter om den delen av nuvarande Projektmodulen där man tar fram inbetalningsdokument fakturor eller rekvisitioner. Behovet av signaleringssystem för att i tid förbereda sig till hämtningen av finansieringsmedel eller rapportering från projektet till finansiären är det område där de flesta blev tvungna att hitta på egna bevakningslösningar. Och här hamnade denna grupp på andra plats bland värstingar. Dessa två första kravområdena innebär egentligen bara 2 generella krav som kan sammanfattas med gör det bättre än det är nu. De andra områdena kan innebära skilda krav på olika detaljer i processen och med ev. olika precisionsgrader vad man egentligen behöver. Flera krav berör inte direkt systemstödet, men visar bara att det finns även andra problem i processen ofta av informationskaraktär. 17(23)
4.3 Generella krav De kraven som kunde anses för att vara generella för hela systemstödet finns samlade under denna rubrik i Kravspecifikationsdokumentet (Resultatdokument A), där ytterliggare en stor del av de samlade behoven finns i en separat kravtabell som innehåller behoven inom användargränssnittet. 4.4 Krav från systemnära intressenter Dessa krav uppstår i direkt relation till den nuvarande Projektmodulen. Det är basen och från den går man vidare med ganska blygsamma förändringsbehov av vilka flera man kan säkert tillfredsställa inom den nuvarande systemlösning förstärkt med ny Agressorelease och kringliggande supportsystem för diarieföring och ärendehantering. Mera om krav från just denna intressentgrupp finns under kapitel 4.2 här. 4.5 Krav från strategiska intressenter Här är två områdena som dominerar stort kontraktsutformning och rapportering. Båda två ligger i nuläge utanför systemstödet för Projektmodulen. - Kontraktsutformningen sköts enligt bästa förmåga av de enskilda forskarna, med ganska bra kontrollförsök från prefekter och med mycket varierat stöd från institutionsekonomer. Om stödet är mindre är det oftast pga. att forskarna inte söker det och klarar sig själva. - Informationshämtning direkt och i form av rapporter görs från Agresso, eftersom oftast vill man ha en blandning av information den kommande från Projektmodulen med den från Agressos bokföring. Strategiska intressenter kan man dela upp på två grupper de som arbetar lokalt, i intervjuerna var de typiska representanter - professorer, prefekter, stödpersonal på fakultetsnivå och de som arbetar centralt SLU-staber och chefsbefattningar på JEP. Lokala strategiska intressenter var inte särskild intresserade i KTM och det typiska behovet inom detta område kan man sammanfatta som krav på en enkel och för deras behov anpassad informationsaccess direkt eller via rapporter. Men det kom många krav/behov som gäller andra områden som den gruppen oroar sig för, men dessa krav ligger utanför denna utredning. Centrala strateger fokuserar mycket på nyttan som kunde komma från KTM, om man kunde utvidga funktionaliteten genom ökning av informationsmängden som samlas i databasen. Det kunde ge bättre stöd för olika ekonomiska processer som planering & budgetering, periodiserade bokslut och bättre ordning och reda i hantering av inkommande penningströmmar från finansiärer. Ett mycket viktigt behov är kvalitetsförbättring på den information som samlas med hjälp av KTM. Men lösningen på detta problem ligger inte enbart i ett förbättrat systemstöd. Det är snarare behovet av organisatoriska förändringar med mera information och klara policybeslut 18(23)
som behövs mest och som måste göras först. Vikigt i sammanhanget är informationshanteringen i den första delen av processen där man utformar avtalen, innan de blir påskrivna. Både själva systemstödet och strategi intressenter får då kvalitetssäkrat data som underlag. 4.6 Särskilda krav kontrakt med utlandet Det är ett mycket intressant område som kommer med många krav, men utformade i ganska generella termer. Det gäller samspelet med utländska finansiärer med EU:s ramprogram och strukturfonder. Om man försöker följa behoven bättre information och fysiskt stöd - och fokusera bara på lösningar som kunde hjälpa dem, då kommer man att fokusera på de mjuka delarna organisation, information, regelverk som behövs mest och först. Sedan bör man satsa på användningen av lämpliga systemlösningar för att leverera allt nödvändigt stöd. Det känns som om det fanns mycket att göra här, men kopplingen till KTM ligger på ganska basalnivå. Ge samma stöd till hanteringen av utländska kontrakt som man ger till inhemska. Det är utgångsläget. I ett visionärt utformat krav bör man satsa på systemstödet för dessa komplexa projekt framför allt på koordinatorsdelen, där effektiv hantering med användning av ärendehanteringsfunktionalitet och e-dokument kunde minska betydligt den vardagliga stressen som är kopplat till administration av den typen av projekt. 4.7 Särskilda krav - förstärkt processtöd för de mest behövande Typiska projekt klarar sig ganska bra även nu. De stora frågorna gäller komplexa projekt, där flera parter samarbetar, flera finansiärer finansierar, arbete pågår under lång tid, det finns flera typer av avtal uppåt mot finansiärer och neråt mot partners. Pengar kan flytta åt alla håll och man menar att det inte finns någon möjlighet att stödja sådana individuellt unika och amtidigt omfattande forskningsinsatser. Det generella behovet av mera stöd är mycket vagt formulerat. Men man kan säkert förbättra varje enskilt projekt av denna karaktär genom att stödja det inte bara med extra personal, men också med att skapa regelverk hur man bör hantera typiska frågor, skapa processbeskrivningar för dessa projekt så att de blir så repetitiva som möjligt och då kommer också systemstödet tydligt att hitta sin plats. 4.8 Om Kravspecifikationen enl. resultatdokumentet A (bilaga) Kravspecifikationen är skapad i form av ett separat dokument. På detta sätt kan man formulera och samla bara krav som berör direkt systemstödet och lämna utanför alla behov som finns kring regelverk, information och organisation inom SLU, samt kritik av nuvarande lösning. Kravspecifikationen är förberedd till utvärdering av kompletta lösningar av systemstödet för effektivare hantering av kontrakt på SLU. Det finns troligen inte någon lösning som täcker hela kravspektrumet, men svar på alla frågor ger ett bra underlag för bedömning. 19(23)
4.9 Summering av intervjufasen Bedömning av den nuvarande lösningen Frekventa användare av Projektmodulen ger den ofta ett bra betyg för helheten och ger en mildare bedömning av de kända felen, som oftast är exakt samma som den andra, mera kritiska gruppen pekar ut som brister. Mindre vana användare och yngre personer bedömer nuvarande stödsystemet lite hårdare och ställer bestämda krav på förbättringar. Mindre volymer av kontrakt på en viss institution innebär inte alltid att de ansvariga på lokalnivån har sämre kunskaper i hanteringen av Kontraktsreskontran. Det är snarare personlighetstypen och troligen den allmänna belastningsgraden som avgör om man vill eller inte vill jobba själv med det nuvarande systemet, samt hur bra man kan detta system. Den mest kritiserade delen av kontraktsprocessen är arbetet med faktura- eller rekvisitionsframställningen, som beskrivs i mycket negativa termer som en klumpig och irriterande lösning. Det finns flera som hoppar över det stödet som man får för svenska fakturor eller rekvisitioner och tillverkar dem med excelmallar för att hoppa över de stödprocedurer som kontraktsreskontran erbjuder. Men de är noga med att skicka kopior till central ekonomiavdelning för korrekt hantering i Agresso. Man klagar sällan spontant på avsaknaden av stöd för hantering av utländska fakturor hos gruppen systemnära intressenter. Orsakerna är troligen låg volym av denna typ av ärenden. Gruppen strategiintressenter, som inte är så homogen som namnet kan ge sken av, visar största intresset för informationsåtkomst helst via rapporter, men ibland också direkt åtkomst. Men pga. att många i denna grupp har nu bra stöd från systemnära (ekonomiassistenter), upplevs avsaknaden av den egna informationsaccessen inte alltför stor. Det är snarare fråga om känslan av beroende. Flera är alltför mycket beroende av mellanhänder om de vill veta något som finns i systemet. En annan grupp är de som har som yrke att gräva i databaser och analysera information. Nu har det svårt att få fram det som de vet att de behöver. Dels finns det en utspridd känsla för otillräcklig kvalitet av information som nuvarande Projektmodulen skapar, dels saknar man informationen vad egentligen finns i denna databas och hur man kan komma åt denna information. Egna lösningar på lokalnivå som åtgärdar brister i nuvarande Kontraktsmodulen. Nästan alla systemnära intressenter på lokalnivån använder någon hjälplösning som kompenserar bristerna i stödet i det nuvarande kontraktssystemet. Oftast är det fråga om ett excelark, med olika typer av uppföljningsinformation ibland enkla lösningar, med det nödvändigaste och ibland riktigt avancerade systemstödapplikationer med ambition att ta hand om allt som man behöver veta. De minimala behoven som man försöker tillfredställa är: En enkel samlad lista av hela omfånget av alla kontrakt som berör individen. Det innebär oftast alla projekt per institution. Listans huvudnyckel är nästan alltid forskarnamn. Alla projekt och kontrakt är sorterade per huvudansvarig forskare 20(23)