Vedlegg 6. Litt om relevante administrative utviklingsprosjekter i sentral regi ved UiB. Rapport Kartlegging del 2. Mai 2005

Rapport Kartlegging del 2 Vedlegg 6 Litt om relevante administrative utviklingsprosjekter i sentral regi ved UiB Mai 2005 Kartlegging del 2 - Vedlegg 6, side 1 av 27

Bakgrunn for dette vedlegget Sentralt ved universitet pågår det stadig nye viktige prosesser som direkte påvirker vårt eget utviklingsarbeid. Vi håper at dette vedlegget kan være til hjelp for undergruppene i sitt videre arbeid, da det gir informasjon om en del sentrale prosesser som er i gang, under utprøving eller på trappene. Kartlegging del 2 - Vedlegg 6, side 2 av 27

Innhold A Elektronisk søknadshåndtering... 4 B Elektronisk saksbehandlingssystem... 5 C Elektronisk innkjøpssystem... 7 D Arbeidsgruppen som ser på organiseringen av SFF-ene... 17 E Harmoniseringsarbeidet Unifob-UiB... 18 F Innføring av prosjektstyringssystem, Unifob... 19 G Gjennomgang av endringer i gjeldende lovverk, med tilhørende tilpasning av UiBs dokumentasjon... 26 H Notat angående eventuell innføring av kortlesere ved alle dører... 27 Foreløpig mangler E og G, men de kommer etter hvert, og legges ut på: http://www.uib.no/mnfa/strategi_omstilling/organisasjon/adm/styring/ Kartlegging del 2 - Vedlegg 6, side 3 av 27

A Elektronisk søknadshåndtering Informasjon fra Kari Lønøy, PØA, etter henvendelse fra fakultetet 27. april 2005 JobbAdmin tilbyr arbeidsgivere elektronisk søknadsbehandling. De elektroniske søknadsskjemaene fra Jobbnor.no styres direkte mot JobbAdmin som oppretter søkelister dynamisk (kort og utvidet form). Hele tilsettingsprosessen foretas elektronisk - også kommunikasjonen med søkere. Søknadsbehandlerne har hele tiden en unik oversikt over hvor langt i tilsettingsprosessen de ulike utlysingene er kommet. Du kan selvsagt også legge inn søknader manuelt. JobbAdmin kan tas i bruk uten særlig opplæring og systemet er klart til bruk: Ingen innkjøp av programvare eller etableringskostnader, åpent system som er integrerbart med kundenes egne systemer og søknadsbehandlere får redusert sitt tidsforbruk med 20-30 minutter pr. søknad. Jobbnor og JobbAdmin er utviklet og eid av Cicero annonsebyrå as. Ovennevnte er klippet fra JobbAdmin. UiB har tatt dette i bruk som en prøveordning ved Det samfunnvitenskapelige fakultet, Det odontologiske fakultet samt Det psykologiske fakultet. Disse tre fakultetene er blitt forespurt som følge av at de har sentralt søknadsmottak. Vi har imidlertid sørget for et minst en person knyttet til de øvrige fakultetene og adminsitrasjonsavdelingene har fått opplæring av Cicero i systemet slik at det kan tas i bruk på en enkel måte når vi anser oss ferdig med prøvetiden. Fakultetsdirektørene har bestemt at systemet i første omgang kun skal tas i bruk for tekniske og administrative stillinger. Kartlegging del 2 - Vedlegg 6, side 4 av 27

B Elektronisk saksbehandlingssystem Informasjon fra Cecilie Ohm, PØA, etter henvendelse fra fakultetet Dato: 29.04.05 Sak: Elektronisk saksbehandlingssystem skisse for forprosjektet Bakgrunn Det er bestemt at PØA skal igangsette arbeidet med å vurdere innføring av et elektronisk saksbehandlingssystem ved UiB. I første omgang iverksettes et forprosjekt. I dette notatet skisseres rammer for forprosjektet, samt bemanningsplaner for dette. Det blir også gjort noen vurderinger knyttet til hvilke elementer som vil inngå i prosjektet som sådan, og hvordan man bør organisere dette. Prosjektbeskrivelse for forprosjekt elektronisk saksbehandlingssystem Forprosjekt for elektronisk saksbehandlingssystem ved UiB har som mål å kartlegge dagens situasjon vedrørende arkiv-, dokument- og saksbehandlingssystemer komme med forslag til hvordan UiB kan håndtere sin saksbehandling (arkiv og dokumenthåndtering) på en kostnadseffektiv og kvalitetsmessig god måte. I forprosjektet skal inngå vurderinger knyttet til hvilke arbeidsprosesser og oppgaver et elektronisk saksbehandlingssystem skal omfatte hvilke organisasjonsmessige endringer det er naturlig at dette medfører ved UiB integrasjon mot andre systemer og brukertilgang Forprosjektet skal anbefale en prosjektorganisasjon for prosjektet. Forprosjektet skal utarbeide en kravspesifikasjon for anskaffelse av et elektronisk saksbehandlingssystem. Det skal videre skisseres en tidsplan for prosjektet. Prosjektorganisering For å allerede nå skissere omfanget av personer som vil være direkte involvert i anskaffelsen og innføringen av elektronisk saksbehandlingssystem, kan man tenke seg følgende prosjektorganisering. Det oppnevnes en prosjektgruppe der kompetanse knyttet til arkiv, personal, IT og innkjøp er dekket. I anskaffelses- og innføringsfasen vil det være naturlig at prosjektgruppen, avhengig av arbeidets karakter, arbeider i mindre grupper som får ansvaret for ulike elementer av prosjektet. Ved behov bør det også trekkes inn personer med spesiell kompetanse. Slike delprosjektgrupper kan eksempelvis få ansvar for følgende oppgaver: - anskaffelse - innføring på enhetene - IT-infrastruktur - IT-brukeradministrasjon Kartlegging del 2 - Vedlegg 6, side 5 av 27

I et såpass stort prosjekt er det viktig å holde hele organisasjonen informert. Dette bør være et lederansvar på de enkelte enhetene. For å sikre direkte dialog med brukere bør det opprettes en referansegruppe der det inngår representanter fra fakultets- og instituttnivå. I tillegg bør man bruke de allerede kjente møteplassene (postmøte, stabsmøte) til å orientere om prosjektet. Prosjektgruppen rapporterer til personal- og økonomidirektør, som er eier for prosjektet. Referansegruppen bør trekkes inn i arbeidet tidlig i prosessen, i første omgang for ren informasjon, men også for å få nyttige innspill i startfasen. Personal- og økonomidirektør er leder for referansegruppen. Saksgang og tidsfrister Det foreslås at forprosjektet danner grunnlaget for en orienteringssak som presenteres for styret i september. Parallelt med arbeidet med styresaken startes utarbeidelsen av en kravspesifikasjon for anskaffelsen av systemet. I tillegg bør det brukes noe tid på å undersøke aktuelle systemløsninger, både gjennom direkte kontakt med leverandører, men også gjennom kontakt med miljøer som har innført elektronisk saksbehandling (eks. Bergen kommune, NTNU). Vi forslår fremdrift der en kravspesifikasjon er klar ca. 1. november 2005. I forhold til et slikt delmål kan følgende tidsrammer skisseres for forprosjektet: Aktivitet Frist Kravspesifikasjon ferdig 01.11.2005 Anbud levert 22.12.2005 Vurdere anbud og inngå avtale med leverandør 01.03.2006 Oppsett testversjon og test av pilot 01.06.2006 Lage opplæringsprogram 01.06.2006 Starte innføring 01.09.2006 En tentativ fremdriftsplan for hele prosjektet kan skisseres slik: Start Ferdig Hele systemet tatt i bruk apr. 2008 5. Dokumenthåndtering (ikke-arkivverdig materiale) jan. 2008 apr. 2008 4. Elektronisk saksbehandling mai 2007 des. 2007 3. Søking og gjenfinning, innsyn i dokumenter des. 2006 apr. 2007 2. Innføre arkiv/journal/scanning sep. 2006 nov. 2006 1. Anskaffe et system for arkiv, saks- og dokumentbehandling apr. 2005 juni 2006 Sentrale elementer i første og andre fase vil være informasjon og opplæring, uttesting ved pilotenheter, og innføring ved enhetene. Kartlegging del 2 - Vedlegg 6, side 6 av 27

C Elektronisk innkjøpssystem Informasjon fra Kut Lohne, PØA, på forespørsel fra fakultetet Beslutningsgrunnlag for e-handels basert innkjøpsløsning ved Universitetet i Bergen Innledning Universitetene i Oslo, Bergen og NTNU i Trondheim, begynte allerede i 1998 å arbeide mot en felles innkjøpsmodul. Det grunnleggende arbeid ble utført ved UiO som koordinerte arbeidet med å komme frem til felles prosedyrer og rutiner for et fremtidig innkjøpssystem. Det falt den gang naturlig å benytte OF s innkjøpsmodul (PO-modulen) til formålet. Denne ble tilpasset og implementert først ved UiO, der den var operativ fra 1.1.2000. UiB kopierte oppsettet fra UiO og testet ut nødvendige tilpasninger i hovedsak knyttet til muliorg-løsningen en der benyttet. Brukerterskelen for PO-modulen viste seg snart å bli uhensiktsmessig for et desentralisert innkjøpsregime som det var ved samtlige av universitetene. NTNU hadde av forskjellige årsaker vært avventende til PO-modulen i utgangspunktet. Da UiO, og senere UiB, strevde med anvendbarheten av modulen, samtidig som den statlige markedsplassen tilbød interesserte brukere å delta som piloter til e-handelsprosjektet, besluttet NTNU å melde sin interesse for dette. Det ble den gang uttrykt at UiB skulle holde PO-modulen intakt som et alternativ, mens NTNU på vegne av de øvrige innkjøpsenheter testet ut e-handel gjennom den statlige markedsplassen. Målet var likevel at samtlige av de tre samarbeidende universitetene fortsatt skulle ende opp med samme type innkjøpsløsning. NTNUs utprøving kunne være en komponent i en slik felles løsning. Mens NTNU fulgte det statlige programmet for elektronisk handel, har en ved UiB forsøkt å se hvordan den nye e-handels-modulen til Oracle, iprocurement, kunne bli som en integrert del av OF. Hittil har en ikke funnet det tilstrekkelig dokumentert at denne modulen gir en funksjonell og økonomisk tilfredsstillende løsning for handel mot den offentlige markedsplass. Alternative innkjøpsløsninger I diskusjonen rundt valg av e-handels applikasjon, har en sett på vurdert følgende alternative løsninger: Spesialiserte innkjøpssystemer IoCore ADB systemer (Vinmonopolet) Oracle iprocurement (best-of-suite) Atento (basert på Oracle iprocurement) IBX markedsplassen sluttbrukerapplikasjonen marketplace catalog Løsningene fra Atento og IBX synes å være de som best dekker universitetenes behov. Behovet og muligheten for økonomisk gevinst ved en løsning sees i lys av en rekke faktorer. De som har vært vurdert som viktigst er; Kartlegging del 2 - Vedlegg 6, side 7 av 27

Kostnader og tid for å komme i gang Tid for gevinstrealisering Gjenbruk av NTNUs erfaringer og arbeid nedlagt i systemløsning. Ressursinnsats fra UiBs side Knytning mot løsninger for fakturabehandling og økonomi Tilgang til en etablert elektronisk markedsplass Gjennomføringsrisiko Både løsningen fra Atento og fra IBX kan knyttes opp til den offentlige markedsplassen. Løsningen fra IBX kan anskaffes ved avrop på rammeavtale mellom Statens Forvaltningstjeneste og IBX, Dette vil derfor gi en vesentlig tidsbesparelse for å komme i gang. Videre vil det i alle tilfeller være en fordel å benytte et utprøvet og integrert bestillingssystem mot den offentlige markedsplassen der de fleste av våre rammeavtale-leverandører allerede er aktører. Den offentlige markedsplassen Program for elektronisk handel i det offentlige (Programmet) har etablert en Elektronisk markedsplass for det offentlige (Markedsplassen). Markedsplassen skal være tilgjengelig som en tjeneste for alle virksomheter i statlig, kommunal og fylkeskommunal sektor. Markedsplassen sikrer offentlige virksomheter enkel tilgang til relevant verktøy for implementering av elektroniske handel i sine innkjøpsprosesser. Markedsplassen er Internettbasert, brukerfinansiert og dekker i dag avrop og driftskjøp på inngåtte rammeavtaler (sentrale, etatspesifikke, regionale og lokal) mellom kjøpere og leverandører. Senere planlegges støtte for ad hoc kjøp, prosjektkjøp og investeringskjøp. Elektronisk markedsplass for det offentlige er et hjelpemiddel for den enkelte virksomhet til å implementere egen forsyningsstrategi, samt et hjelpemiddel for å realisere kostnadsbesparelser knyttet til innkjøpsfunksjonen. Den enkelte virksomhet i det offentlige kan kjøpe seg tilgang til Markedsplassen ved å tegne abonnementsavtale med operatøren IBX AS. Avtalen med operatøren er inngått etter konkurranse i henhold til lov om offentlige anskaffelser på vegne av alle virksomheter underlagt denne loven. Det er derfor ikke nødvendig å gjennomføre konkurranse i egen regi om levering av løsninger og tjenester for å implementere elektronisk handel. Dette er gjort for å forenkle etableringsprosessen og bidra til at det offentlige stiller ensartede krav til de elektroniske forretningsprosessene. Prosjektet Elektronisk Markedsplass går i hovedsak ut på å utvikle en felles løsning for det offentliges innkjøpsvirksomhet gjennom å velge en eller flere operatører som kan levere følgende applikasjoner: 1. E-handelsplattform, som inneholder bl.a. leverandørenes varekataloger, avtaler, database for transaksjonshåndtering mellom kjøper og leverandør og div. hjelpeverktøy. 2. Sluttbrukerapplikasjon, som vil bli kjøpernes portal mot E-handelsplattformen, dvs. innkjøpssystemet Dette verktøyet skal være internettbasert og brukerfinansiert, og skal dekke følgende bruksområder:? Fase 1; Avrop på inngåtte rammeavtaler (sentrale, etatsspesifikke, regionale og lokale), leverandørregister Kartlegging del 2 - Vedlegg 6, side 8 av 27

? Fase 2-3; Ad hoc kjøp, prosjektkjøp/investeringskjøp De forventede gevinster som skal oppnås gjennom Markedsplassen kan deles inn i direkte gevinster og indirekte gevinster. Direkte gevinster er knyttet til forbedrede kommersielle avtalevilkår samt mulighet for reduserte logistikk-kostnader. De indirekte gevinstene oppstår som følge av reduserte administrative kostnader og forbedret økonomistyring. NTNU har som én av 14 pilotvirksomheter deltatt i etableringsperioden for prosjektet Elektronisk markedsplass for det offentlige (EMBLA). Etter at løsningen ble satt i drift, 21. februar 2002, har NTNU høstet erfaringer ved bruk av løsningen og tegnet abonnement på løsningen, samt rullet løsningen ut i store deler av sin organisasjon (p.t. ca 300 brukere). Universitetet i Bergen sammenlignet med NTNU NTNU gjennomførte et forprosjekt som er nøye studert ved UiB`s innkjøpskontor. De forhold og analyser som i dette prosjekt har ledet frem til beslutningen om e-handel synes i hovedsak å være så parallelle som det er praktisk mulig. Forprosjektet ved NTNU (rapporten vedlagt), konkluderte med følgende forventede gevinster for fase 1 i prosjektet på: Direkte besparelser gjennom økt lojalitet og bedre betingelser ved rammeavtaler på noe over 6 mill. kr./år Indirekte besparelser gjennom forbedringer av hele den operasjonelle innkjøpsprosessen på vel ca. 3 mill. kr./år, senere tonet ned til 1,8 mill kr./år. Total besparelse var dermed anslått til noe over 7,8 mill. kr./år. De direkte besparelsene ville kunne taes ut i form av direkte reduserte kostnader, mens for de indirekte besparelsene ville de først og fremst bety frigitt tid for andre kvalifiserte oppgaver ved de forskjellige enheter ved hele NTNU. Gevinster for fase 2-3 ble ikke forsøkt beregnet fordi de framtidige løsningene ennå ikke er fastlagt, men de bør også bli vesentlige. Disse gevinstene ble gjort ut fra vurderinger med basis i dagens løsninger. Konklusjonene av disse vurderingene tilsier at potensielle gevinster bør være tilnærmet tilsvarende for UiB. En ønsker likevel å dempe forventningene en smule ettersom de fleste dataløsningene viser en relativ lang modningstid før effekten bli merkbar. For UiB kan en derfor anslå gevinster for året 2007 som følger; Direkte besparelser som nevnt ovenfor på ca. 4 mill. kr/år Indirekte besparelser etter forbedring av de operasjonelle prosesser på ca. 1 mill. kr/år. Dette vil i så fall gi en total besparelse på 5 mill. kr/år, som fullt ut vil kunne forsvare investeringen. E-handel ved UiB Målsettingen for UiB, som for NTNUs del, må være at Markedsplassen på lang sikt skal bli den eneste kanalen for registrering av innkjøpstransaksjoner. I tillegg til de tidligere nevnte gevinster Kartlegging del 2 - Vedlegg 6, side 9 av 27

vil det også sikre at alle kjøp blir styrt gjennom vårt definerte godkjenningshierarki. Det vil i tillegg kunne gi en komplett disposisjonsoversikt, som skal vise verdien av alle inngåtte forpliktelser i form av bestillinger. I en overgangsfase vil integrering med elektronisk fakturabehandling gjennom prosjekt for elektronisk fakturabehandling komplettere innkjøpssystemet. Særlig vil dette være tilfelle for oppbygging av godkjenningshierarkiet. På kort og mellomlang sikt vil mye fokus være på tilpasning av rutiner, system og avtaler. Det foreslåtte prosjektet skal derfor ha hovedfokus på de muligheter som finnes innen kort- og mellomlang sikt (1-5 år). Beslutningsgrunnlag Beslutningen om innføring av e-handelsløsning ved UiB må bygge på følgende forhold:? E-handel og applikasjonsleverandøren oppfyller et sett med forutsetninger? Det forventes betydelige kvantitative gevinster ved innføring av E-handel? Det forventes betydelige kvalitative gevinster ved innføring av E-handel? Det forventes på sikt betydelige besparelser knyttet til UiB`s innkjøpsprosess ved innføring av E-handel Forutsetninger Det forutsettes at UiB velger å knytte seg til den offentlige markedsplassen, og i alle fall i en pilotfase benytte samme applikasjonsleverandør som ved NTNU (IBX). Pilotprosjektet ved NTNU og deres valg av applikasjonsleverandør har vist at følgende forutsetninger er oppfylt:? E-handel støtter opp under vedtatt IT-strategi.? E-handel (sluttbrukerapplikasjon) støtter effektivt rekvirenter og godkjennere i deres sentrale arbeidsoppgaver: søke etter varer, lage rekvisisjon, godkjenne rekvisisjon, lage bestilling, foreta kontering av ordre, følge status på ordre, foreta avvikshåndtering på ordre (kansellering, endringer), og gjennomføre varemottak.? E-handel har en tilfredsstillende teknisk stabilitet, ytelse og tilgjengelighet i henhold til de serviceavtaler som er inngått med leverandør (IBX).? IBX har vist seg å være i stand til å yte tilstrekkelig brukerstøtte igjen i henhold til inngåtte serviceavtaler.? IBX har indikert å være i stand til å utvike ny funksjonalitet og jevnlig levere oppgraderinger av E-handel. Kostnadene ved oppgraderinger skal være dekket av abonnementsavtalen.? IBX har vist seg å effektivt kunne bistå i rekruttering, aktivering og forvaltning av nye og eksisterende leverandører og deres varekataloger. I tillegg forutsettes for UiB at:? E-handel kan integrere seg mot OF ved hjelp av BasWare som nyttes ved fakturaskanning. Kvantitative gevinster Et ehandelsprosjekt forventes å ha et betydelig gevinstpotensial innenfor rammebetingelsene gitt innledningsvis: Kartlegging del 2 - Vedlegg 6, side 10 av 27

Direkte kostnader kan reduseres med ca 4 mill. NOK gjennom betydelig økt avtalelojalitet og forbedring av eksisterende avtaler. Indirekte kostnader kan reduseres med ca 1 mill. NOK gjennom betydelig prosesseffektivisering Det er verdt å knytte følgende kommentarer til beløpet på indirekte kostnader: Da store deler av bestilling- og fakturaprosessen er desentral, vil gevinsten finfordeles på et stort antall personer på mange institutter og fakulteter. Gevinstene er derfor vanskelig å hente ut som reduksjon i antall årsverk. De deler av prosessen hvor arbeidstrinnene utføres desentralt, vil det kanskje være riktigere å anvende frigjort tid på virksomhetens primæroppgaver: forskning og utdanning. For mer sentraliserte arbeidstrinn, er det naturlig å vurdere om det er hensiktsmessig å bygge ned kapasiteten tilsvarende et visst antall årsverk. Vi antar derfor i oppsettet at det vil være mulig å hente ut ca. 50% av beløpet i faktisk kostnadsreduksjon. Dette må likevel ses i sammenheng med pågående omorganisering av administrative funksjoner på institutt og fakultetsnivå I NTNUs beregninger av besparelse, som vi antar kan være tilsvarende ved UiB, ble det lagt til grunn 20 000 fakturaer. Dette representerte 1/3 av NTNU totale fakturamengde og knyttet seg utelukkende til de leverandørene som man ønsket å aktivere i Fase 1. Senere planla de å aktivere ytterlige leverandører for å skape et innkjøpsvolum over markedsplassen som tilsvarer en betydelig mengde av de resterende 2/3 (40 000 fakturaer). Gevinstpotensialet på sikt antas derfor å være enda større enn det potensialet som er beregnet for Fase 1. Selv om en stor del av prosesseffektiviteten vil være knyttet opp mot en integrasjon mellom Sluttbrukerapplikasjonen og økonomisystemet, forventes det betydelige prosessgevinster også uten integrasjon. IBX sluttbrukerapplikasjon gjør det mulig å knytte korrekt kontering til bestillingen før den sendes til leverandøren. Ved å sikre at bestillingen er godkjent og kontert før varen sendes til bestilling, har man tidlig i prosessen ivaretatt kravene til attestasjon og anvisning. Og dersom varemottaket også er registrert, vil fakturabehandlingen etter skanning og matching mot bestilling og varemottak, kunne utføres raskt og effektivt. Ytterligere attestasjon og anvisning på dette tidspunkt anses som overflødig. Kvalitative gevinster: Utover gevinstene ovenfor forventes det at innføringen av løsningen vil gi betydelige kvalitative gevinster: Muliggjøre frigjøring av tid fra administrative oppgaver til virksomhetens primæroppgaver. Bedre økonomistyring bl.a. gjennom etablering av disposisjonsregnskap for innkjøp av varegrupper som egner seg for e-handel. Økt kvalitet ved innkjøpsprosessen gjennom aktivisert fullmaktstruktur og ved reduksjon av feilleveranser. Bedre vurderingsgrunnlag ved kontraktsoppfyllelse, revisjon og inngåelse av nye rammeavtaler, basert på innhentet statistikk på leveringspresisjon og leveringskvalitet. Forventede besparelser Kartlegging del 2 - Vedlegg 6, side 11 av 27

Med basis i gevinstpotensialet ovenfor og en kalkyle over kostnadene, er forventede besparelser frem tom. år 2007 gitt i tabellen nedenfor. 2004 2005 2006 2007 Investeringskostnader Tilknytning Markedsplassen kr 125 000 Tilknytning Sluttbrukerapplikasjon kr 125 000 Opplæringskostnader kr 185 000 kr 40 000 kr - kr - Ekstern prosjektbistand kr 250 000 kr 600 000 kr - kr - Integrasjonsløsning kr 125 000 kr 250 000 kr - kr - Reise- og møtekostnader kr 100 000 kr 50 000 kr 20 000 kr 20 000 Reserve/ uforutsett kr 100 000 kr 100 000 kr - kr - Driftskostnader Abonnement Markedsplassen kr 280 000 kr 465 000 kr 465 000 kr 465 000 Abonnement Sluttbrukerapplikasjon kr 225 000 kr 225 000 kr 225 000 Sum kostnader kr 1 290 000 kr 1 730 000 kr 710 000 kr 710 000 Gevinster Økt avtalelojalitet kr - kr 800 000 kr 2 000 000 kr 4 000 000 Prossesseffektivitet kr - kr 400 000 kr 600 000 kr 1 000 000 Sum gevinster kr - kr 1 200 000 kr 2 600 000 kr 5 000 000 Besparelse kr -1 290 000 kr -530 000 kr 1 890 000 kr 4 290 000 Tabellen er bygget opp rundt de kostnader som NTNU satte som grunnlag for sin beslutning med en dempning av forventninger som er omtalt tidligere. Interne ressurser Total ressursbruk for utrullingsprosjektet ved NTNU ble estimert til 6100 timer. Disse ressursene var hovedsakelig interne. Kostnader forbundet med intern ressursbruk er ikke tatt med i regnestykket. Ekstern bistand vurderes aktuelt innenfor bl.a. følgende hovedområder: gevinstrealisering, prosjektledelses - støtte og leverandørintegrasjon. Kostnader forbundet med ekstern bistand er tatt med i tabellen. Kostnadene ved integrasjon er ikke gjennomgått i detalj. De kvalitative gevinstene er ikke vurdert, men forventes å kunne ha gitt et betydelig bidrag dersom de hadde blitt kvantifisert. Basert på beregningen kan vi si at: Investeringen vil være tilbakebetalt i løpet av år 2006. Årlige besparelser knyttet til omfanget på utrullingen vil fom. 2007 være over 4,3 mill. NOK. Anbefaling Dette dokumentet er ment som grunnlag for beslutning om å iverksette et prosjektarbeid med sikte på innføring av ehandel ved UiB. Oppstart er ønskelig i juni 2004 av hensyn til bla. Kartlegging del 2 - Vedlegg 6, side 12 av 27

gevinsten av å komme i gang parallelt med at NTNU starter prosjekt for elektronisk fakturabehandling. Vi mener forholdene ved UiB skiller seg lite fra NTNU og har i dokumentet lagt vesentlig vekt på vurderinger gjort i forprosjektet i Trondheim som vedlegges. Det foreligger også en mer omfattende beskrivelse av e-handelsløsningen på www.ehandel.no og ved NTNU der erfaringer av integreringsløsningen bør kunne overføres til UiB Vi mener derfor at dokumentet gir tilstrekkelig grunnlag for å kunne ta en beslutning om å starte arbeide med å legge til rette for et implementeringprosjekt for et ehandels innkjøpssystem knyttet til den offentlige markedsplassen. Det vil utarbeides en prosjektplan for bruk av interne ressurser som del av første fase av prosjektet. På bakgrunn av beslutningsgrunnlaget ovenfor anbefales det derfor at UiB inngår abonnementsavtale med Markedsplassen og IBX og starter et prosjektarbeid for utrulling av ehandels løsningen. Kartlegging del 2 - Vedlegg 6, side 13 av 27

NOTAT E-handel - Status Til: Personal og økonomidirektør Kjell Bernstrøm Kopi til: Kjetil Skog, Fra: Knut Ivar Lohne Dato: 4. jan. 2005 Viser til tidligere notat om bakgrunn og mål for prosjektet. Status for delmål 1: Etablering av pilot - applikasjon Pilot-brukerenheter: Følgende enheter er utpekt til pilot-brukere: Institutt for biomedisin Institutt for biologi Personal- og økonomiavdelingen Brukere: Det er satt opp lister av brukere i ulike roller for hver av brukerenhetene. Institutt for biologi 11 4 Institutt for biomedisin 8 7 4 Personal- og 3 økonomiavdelingen 2 (5 Bestillere Godkjennere Rekvirenter/varemottakere Bestillere Godkjennere Bestillere Godkjennere Superbrukere) Leverandører: Dell Norge AS NDS-Norsk Data Senter ANDVORD F. Beyer Engros VWR International AS Sigma-Aldrich Norway AS Dataleverandør Dataleverandør Kontorrekvisita m.m. Kjemikalier/lab utstyr Kjemikalier/lab utstyr Rolleavklaring: Applikasjonen settes i pilot opp med 3 mulige rolle-nivåer: Rekvirent (til sammen 8 brukere) Bestiller (til sammen 21 brukere) Kartlegging del 2 - Vedlegg 6, side 14 av 27

Godkjenner (til sammen 10 brukere) Rekvirentrollen kan være manuell eller tilordnet i applikasjonen for kladding av bestillinger (kun sistnevnte er definert som bruker i innkjøpssystemet. I slike tilfeller kvalitetssikres bestillingen av bestiller før den sendes til godkjenning. Bestiller kvalitetsikrer alle bestillinger, konterer kostnaden på forhånd og forelegger disse til godkjenning i systemet. Godkjenner aksepterer innkjøpet ved avkryssing i systemet. Dette utløser bestillingstransaksjonen mot leverandør. Samtlige av de nevnte leverandører har akseptert at de vil tilrettelegge sine kataloger for bruk i pilot-versjonen til 1. februar 2005. Status for delmål 2: Videre utrulling Avhengig av integrasjonsløsningen mot BasWare, legges det opp til videre utrulling primo april 2005. Dette avhenger selvsagt av hvordan systemet fungerer i pilot-perioden. Det legges opp til et orienteringsmøte for potensielle leverandører ca 20. januar der vi sammen med IBX vil orientere om hva som må tilrettelegges fra leveransørenes side for at de skal bli aktører i vår innkjøpsløsning fra starten, dvs. tilrettelegging av kataloger, priser m.v. Det er listet opp følgende utrullingsplan: Perioder Produktområder Bruker-enheter 1. runde Administrative kjøp Bøker Kjemikalier Generelt lab-utstyr Jus HF SV Fak.sekretariater/Admin. (- EIA) Mat/nat (- Fysikk/teknol. og Geofysikk) Biomedisin Psykologi 2. runde Byggteknisk utstyr Medisin & medisinsk utstyr Tjenester Fritekst bestillinger Eiendomsavdelingen Medisin (resten - Vivariet) Runde 3 Runde 4 Elektronikk Annet spesialutstyr for fysikk/teknologi, oceanografi og odontologi Spesialutstyr for museer og dyrestaller Abonnementer Faste regelmessige kjøp Institutt for fysikk og teknologi Geofysiks institutt Odontologi Vivariet Kartlegging del 2 - Vedlegg 6, side 15 av 27

Følgende leverandører vil bli invitert til runde 1- implementering: Lab-utstyr / Kjemikalier Bøker Adm-kjøp VWR* Sigma Aldrich* Tamro med.lab. Amersham Bioscience AH-Diagnostics MedProbe BioRad laboratories Yara industial Studia Swets Gnist Rich. Andvord* Dell* Richard Juuhl Blomster Citius Data Studentsamskipnaden (kantine) Office line EDBergen Bergen kontorsenter NDS* Allkopi (visittkort) Ementor EFG-HovDokka Det er på nåværende tidspunkt ikke fastsatt datoer for 2.-3. og 4. runde. Kartlegging del 2 - Vedlegg 6, side 16 av 27

D Arbeidsgruppen som ser på organiseringen av SFF-ene Oppnevningsbrevet kan lastes ned fra: http://www.uib.no/mnfa/strategi_omstilling/organisasjon/adm/styring/vedlegg%206d.pdf (kvaliteten ble dessverre for dårlig til å lime inn her, da brevet er scannet) Kartlegging del 2 - Vedlegg 6, side 17 av 27

E Harmoniseringsarbeidet Unifob-UiB kommer. Kartlegging del 2 - Vedlegg 6, side 18 av 27

F Innføring av prosjektstyringssystem, Unifob Informasjon fra Nora-Lise Kristiansen, Økonomisjef Unifob 1. mai 2005 Innledning Vi har siden januar 2003 jobbet med planlegging og løsningsforslag til en elektronisk prosjektapplikasjon til bruk i Unifob og UiB. Bakgrunnen for arbeidet med et nytt verktøy for administrasjon av eksternfinansierte prosjekter er flere. Bl.a. o Behov for bedret kvalitet på økonomisk informasjon vedr eksternfinansierte prosjekter o Bedre økonomisk kontroll over eksternt finansierte prosjekter mht o Budsjett o Forbruk o Avvik budsjett mot forbruk o Restmidler o Hindre overskridelser o Bedre informasjon om ressurser, som vil gi o bedre grunnlag for planlegging av aktiviteter/prosjekter i avdelingene o riktigere registrering av utført arbeid i prosjektregnskapene Rammebetingelser Vi utarbeidet noen rammer for hva applikasjonen skulle inneholde og la dette ut på offentlig utlysning i februar 2003. I rammebetingelsene for systemet ligger følgende forutsetninger: o Systemet må inneholde en kalkylemulighet så vel som en budsjettfunksjonalitet o Målet med dette er at systemet skal kunne bidra med kvalitetssikring av kalkyler til bruk i søknadsprosesser o Gi lett tilg jengelige oversikter over prosjektbudsjettene knyttet opp mot faktisk forbruk og utført arbeid i prosjektet o Redusere bruk av regneark på en slik måte at kalkyler og budsjett ligger tilgjengelig i samme applikasjon som all annen økonomisk informasjon om prosjektet o Systemet må inneholde en ressurspool, det vil si en mulighet til å registrere de ansatte ved avdelingene slik at man kan o få oversikt over tilgjengelig arbeidskraft ved avdelingen o få oversikt over underdekkede ressurser o kunne dra ut informasjon vedrørende ressurser på en slik måte at en kan planlegge ressurser på en kvalitetssikker måte o Systemet må kunne tilby en målestokk for arbeidsinnsats som erstatter personlig lønn registrert direkte forskningsprosjektet. En slik målestokk er vanligvis timer. Dette var vi kjent med, og allerede i rammebetingelsene for prosjektet gjorde vi det klart at det var avdelinger ved Unifob og miljøer ved UiB som IKKE ser for seg å ville føre ukentlige timelister. Vi etterspurte derfor allerede i 2003 en løsning for å kunne takle dette. o Systemet må kunne tilby en løsning for at de prosjektansvarlige ved alle avdelinger og institutter godkjenner prosjektenes økonomiske status hver måned. Dette forutsetter at prosjektene er oppdaterte mht kostnader og inntekter og kan vise prosjektenes budsjett både totalt, pr dato etc. Årsaken til at vi ønsker denne kontrollen er for å avdekke muligheter for tap på et tidlig tidspunkt og for eventuelt å kunne unngå en slik situasjon ved tidlig å kunne gå inn med ekstraressurser eller andre tiltak. Det forutsettes at en slik statusbekreftelse skal kunne gis på en funksjonell måte. o Systemet skal kunne inneholde funksjonalitet som kan administrere og gi informasjon om ulike rapporteringsbehov for de ulike prosjektene, både økonomiske, men også ulike faglige rapporteringsoppgaver eller milepæler. o Systemet skal kunne lagre ulike dokumenter (søknader, prosjektbeskrivelser etc) linket til det enkelte prosjekt i applikasjonen. o Systemet skal inneholde funksjonalitet for å lagre statusrapporter om gjennomføring, fremdrift og lignende. Kartlegging del 2 - Vedlegg 6, side 19 av 27

Prosessen så langt Det ble inngått en avtale mellom Unifob og UiB om samarbeid mht planlegging, tilpasning og ev. implementasjon av det nye systemet. Unifob skal være pilotorganisasjon med hensyn til å ta det nye prosjektverktøyet i bruk. Derfor var det også naturlig at prosjektorganiseringen ble ledet fra Unifob og at det i størst mulig grad var denne organisasjonen som fikk delta med personer i de ulike prosjekt, arbeids og referansegruppene. Likevel har vi hele tiden hat for øye at verktøyet også skal kunne anvendes ved UiB. Vi ønsket å kunne knytte til oss representanter fra både ulike arbeidsområder så vel som fra ulike miljø og avdelinger. Prosjektet ble delt inn i ulike gruppe med ulikt ansvar og arbeidsoppgaver. Det ble opprettet: o Styringsgruppe bestående av o Arne Svindland, VAD Unifob o Kjell Bernstrøm, Øk. og Pers. dir UiB o Tor Bu, IT-dir UiB Styringsgruppen har det overordnede ansvar for prosjektet og har avgjørende myndighet mht viktige beslutninger i prosjektet. Styringsgruppen signerer kontrakt om leveranse av system o Prosjektgruppe o Nora-Lise Kristiansen, Øk.sjef Unifob Prosjektleder o Kirsti Aarøen, Regnskapssjef UiB o Kjetil Skog, tidl. Dir ved Avd for Naturvitenskap Prosjektgruppen er den som styrer prosjektgjennomføringen og vurderer løsningene for verktøyet ut ifra innspill og resultater fra arbeidsgruppen. o o Arbeidsgruppe bestående av o Kari Fuglseth, Adm.sjef Rokkansenteret o Anita Vangen, Prosjektøkonom Avd for Beregningsvitenskap og SARS o Trine Knudsen, Prosjektøkonom Halos o Berit Larsen, Konsulent Seksjon for Arbeidsmedisin Arbeidsgruppen gjennomfører tester, deltar på presentasjoner av de ulike stadiene av gjennomganger av systemet. De er med i planleggingen av arbeidsprosessene og gir uvurderlige kommentarer, innspill og kritikk av de ulike stadiene i prosjektgjennomføringen. Referansegruppe bestående av representanter fra o forskningsdirektørene/forskere, o representanter fra Personal- og økonomiavdelingen, PØA (Lønn og budsjett), o IT-avdelingen o Representanter fra Forskningsavdelingen o personaladministrasjonen ved Unifob Etter utlysningen av prosjektet mottok vi 13 tilbud. Prosjektgruppen evaluerte og karaktersatte tilbudene etter retningslinjer tidligere anvendt ved UiB for administrative systemer. Forhold som kvalitet og kvalifikasjoner, gjennomføringsbeskrivelse, pris, produktkvalitet, funksjonalitet, leveringstid, underleverandør, kompetanse, service, leverandørens økonomi, referanser og krav til UiB/Unifobs ytelser ble vurdert og karaktersatt. På grunnlag av gjennomførte presentasjoner, evalueringer og spissede møter ble det i styringsgruppemøte 13/6 2003 besluttet å begynne kontraktsforhandlinger med Oracle vedr Oracle Project. Forprosjekt Før vi kunne vurdere kontraktsinngåelse ville vi vite atskillig mer om Oracles prosjektmodul. Vi inngikk derfor en avtale om gjennomføring av et forprosjekt som skulle ende opp med en demo -versjon installert på universitetets egen server og i et reelt Unifob/UiB miljø. Forprosjektet var ment å vare frem til november 2003. På grunn av ulike hendelser ble dette forlenget med et helt år: Ut fra resultatene i første fase av forprosjektet så vi konturene av et system vi kunne bruke, men vurderte også noen kritiske løsningsforslag som for dårlige. Ny testversjon ble satt opp i august 2004 og ny test gjennomført i september 2004. Løsningen fungerte nå bedre på flere områder, spesielt de to kritiske områdene for budsjett/kalkyle og prosjektgodkjenning. Kartlegging del 2 - Vedlegg 6, side 20 av 27

Etter septembertesten ble så alle deltagere i referansegruppene invitert til en gjennomgang av premissene for prosjektet. Prosessene som systemet dekker ble gjennomgått, samt nye prinsipper, produktoppbygging og lay-out. Dette orienteringsmøtet ble holdt 15. november 2004. Prosjektgruppens innstilling til styringsgruppemøte i november gikk ut på at man anbefalte anskaffelse av verktøyet basert på de evalueringer og tester som var gjennomført. Styringsgruppemøtet i november vedtok derfor å inngå kontrakt med Oracle om anskaffelse av produktet. Pilot Vi prøvde så ut den Unifob-tilpassede versjonen av Oracle Project i fire pilotprosjekt. Fire ordentlige prosjekter behandles i systemet og der vi registrerer alle budsjetter, avtaler, ansatte som jobber i prosjektene, inntekter og kostnader der. Videre har vi logget arbeid (rapporter faglige og økonomiske) som skal gjøres i prosjektene slik at vi får testet varslingsfunksjonaliteten i et virkelig prosjekt. Vi vil også linke dokumenter, søknader etc, som relaterer seg til prosjektene slik at vi får se funksjonaliteten av å ha alt materiell rundt et prosjekt tilgjengelig i samme applikasjon. Det er to prosjekter ved HALOS og to ved SARS som inngår i den første pilotfasen. Hvis pilotfasen blir vellykket med eventuelle tilpasninger som vil måtte komme fra de ulike rollene som skal bli kjent med applikasjonen, planlegger vi å rulle ut systemet til bruk ved alle eksterne prosjekter i Unifob fra 1. juni 2005. Dersom denne fasen også går etter planen vil UiB starte et pilotprosjekt til høsten 2005 der man anvender Oracle Project på noen eksternfinansierte prosjekter ved UiB. Jeg vil nedenfor presentere hvorledes vi har jobbet, systematisert og kartlagt arbeidsoppgavene rundt prosjektadministrasjon og hvorledes den nye applikasjonen etter vår mening, med visse endringer i administrativ håndtering, vil gi en bedret informasjonen om prosjektene. Prosessene Oracles prosjektmodul skal brukes innenfor følgende prosesser: Røde områder viser manuelle rutiner, eller rutiner som ligger utenfor Oracle prosjektmodul. Det grønne området relaterer seg til oppgaver som løses i Oracle Human Recources (Oracle HR), som er Oracles personalmodul. De gule områdene viser prosesser som bli løst eller gjennomført ved hjelp av Oracles prosjektmodul. Oracle HR er ikke en modul vi har fra før, vi går heller ikke til innkjøp av enda et produkt. En begrenset del av funksjonaliteten fra Oracles personalmodul følger med installasjon av Oracle Project. Dette fordi man ikke kan kjøre prosjektmodulen uten å kunne gå til et sted og finne personene som skal arbeide i prosjektet. Dette kan anses som et bonusmateriale som følger med prosjektmodulen men som også vil gi bedret informasjon på det Kartlegging del 2 - Vedlegg 6, side 21 av 27

personaladministrative området ved avdelingene. Likevel må vi presisere at vi ikke går til anskaffelse av Oracle HRmodul, men får altså tilgang til deler av den. Rollene Vi definerte også svært tidlig hvilke roller som ville ha arbeidsoppgaver i forbindelse med applikasjonen. Kart over rollene finnes nedenfor. Rollen for prosjektsekretær er en stillingsbetegnelse som vi ikke bruker i Unifob, men er her ment som en funksjonsbeskrivelse for de arbeidsoppgaver som sekretærer og konsulenter gjennomfører rundt om på seksjoner og avdelinger i Unifob. Oppgavene som gjøres av denne rollen er f.eks registrering (attestering) av inngående fakturaer, kontroll og utsending av utgående faktura etc. Rollene for prosjektdeltager, prosjektleder og administrativ leder er valgfrie. Prosesskart De aller første møtene vi hadde samlet med prosjekt- og arbeidsgruppen i september 2003 gikk ut på å sette opp oversikter over alle arbeidsoppgavene som ble utført i forbindelse med prosjektadministrasjon og styring, dele dem inn i prosesser og merke dem med hvilke roller som utførte de ulike arbeidsoppgavene. Denne kartleggingen ble så justert når vi ble kjent med applikasjonen ved at arbeidsoppgaver ble tilført og fjernet etter hvert som vi ble bedre kjent med mulighetene i Oracles prosjektmodul som vi hadde innledet forprosjektet med (se ovenfor). Dette levende prosesskartet har vi hatt med oss og justert på gjennom hele prosjektet og vil nå gi et godt grunnlag for brukerdokumentasjonen av systemet. Eksempel på en prosess, Registrering av ansatte er vist nedenfor. Brukergrensesnitt Oracle Applications har tidligere hatt et relativt vanskelig tilgjengelig brukergrensesnitt i form av menybaserte skjermbilder. Trenden både fra denne leverandøren, og selvsagt også fra mange andre, er å legge grensesnittet over til web-baserte skjermbilder tilgjengelig fra nettleseren Microsoft Explorer. For en del brukere vil begge grensesnitt anvensdes. Rutineforbedringer Kartlegging del 2 - Vedlegg 6, side 22 av 27

I forbindelse med forprosjektet har vi arbeidet oss frem til en del forbedringer av den administrative prosjekthåndteringen. Vi deler dette inn i tre deler: o o o Ressursregistrering Prosjektøkonomi Godkjenning av prosjektstatus Ressursregistrering Alle personer som skal delta i et eksternt finansiert prosjekt vil måtte være registrert som en ressurs i systemet. Vi kunne selvsagt overført data fra lønnssystemet med hensyn til hvem som er ansatt i de forskjellige avdelingene og fått overført annen personalinformasjon derfra også. Imidlertid var det ganske klart for oss på et tidlig stadium i prosjektet at vi ville ha færrest mulig linker mot lønnssystemet, blant annet fordi vi i utgangspunktet tenkte oss et prosjektsystem som skulle være lite og enkelt med minst mulig kompliserende linker frem og tilbake mellom moduler og systemer, med de driftmessige utfordringer dette ville medføre. Ikke minst ønsket vi å unngå link mot SLP fordi vi vet at det er en del kriterier som formelt skal på plass før en person skal registreres i lønnssystemet, og som det gjerne tar noe tid å få frembrakt. Dette gjør at en del personer starter å jobbe ved avdelingene før de en formelt registrert i lønnssystemet. I et prosjektsystem er det derimot viktig å få registrert en person som deltager på et prosjekt fra første arbeidsdag, for så vidt uavhengig av om vedkommende er registrert i lønnssystemet. Dette fordi man kanskje vil inkludere ressursen i spesifiserte prosjektbudsjetter eller skal registrere arbeid utført for vedkommende i prosjektregnskapet. Fordelen med å få tilgang til ressurspoolen er at hver avdeling gjennom sine personalkonsulenter får revidere og liste ut en meget mer fleksibel rapportering om sine ansatte enn hva muligheten er i dag. I dag er det kun excel lister fra SLP som er tilgjengelig personalinformasjon. Avdelingene kan ikke ta dette ut selv, men må vente på standardiserte lister som oversendes med jevne mellomrom. Ved bruk av ressurspoolen vil man hente ut informasjon om medarbeidere selv og kunne legge inn informasjon om dem som ikke er tilgjengelig fra SLP, for eksempel fagtilknytning, ansattstatus, alder, kjønn, kontorsted etc. Rapporter over ansatte er også tilgjengelig fra rapporteringsverktøyet Oracle Discoverer, som vil være tilgjengelig for alle brukere av systemet. Om ønskelig kan rapporter om ansatte avgrenses til kun å være tilgjengelig for personalkonsulenter. Det må her presiseres at de ansattes lønn ikke registreres i Oracle HR, heller ikke personnummer. Det er personalopplysninger, ikke lønnsinformasjon, som vedlikeholdes der. Registrering av medgått tid Pr i dag blir de ansattes lønn belastet direkte i prosjektregnskapene. Dette medfører svært mye regnskapsmessig omregistrering når prosjektmedarbeidere deltar i mer enn ett prosjekt. Videre er lønn en personlig avtale mellom ansatt og arbeidsgiver som ikke bør fremkomme i prosjektregnskapene For å registrere en økonomisk verdi som ikke er lønn i prosjektregnskapene har man mulighet for at alle prosjektdeltagere skriver timelister hver uke som godkjennes av overordnet og der timer multiplisert med timepris overføres som den økonomiske enhet som reflekterer medgått tid. Timerlistene er tilgjengelig elektronisk gjennom tilgang til Oracles Time&Labour-modul. Gjennom denne metoden vil man få det mest korrekte prosjektregnskapene som mest nøyaktig vil reflektere antall timer brukt på prosjektene til enhver tid. Det er ikke nødvendig å gjøre bruk av denne funksjonaliteten med timelister, det er kun et tilbud til de avdelinger som velger å benytte seg av den. Som nevnt innledningsvis har vi helt fra starten i prosjektutlysningen svært klart presisert at vi har avdelinger og miljøer der denne type registrering av tid ikke er ønskelig. Derfor har vi utarbeidet et registreringsskjema som vi ser for oss at prosjektøkonomene er ansvarlige for, der alle prosjektansatte er registrert og hvor man hver måned angir hvor stor prosent av et månedsverk ansatte har jobbet på de ulike eksterne prosjektene ved avdelingen. Informasjonen innhentes og registreres av prosjektøkonom og anvises av forskningsdirektør eventuelt stedfortreder. Denne informasjonen lastes så opp i prosjektmodulen en gang pr måned. Andelen/prosenten av et fullt månedsverk vil så kalkuleres om til kostnadstypen Medgått tid ved å multiplisere med den ansattes lønnskostnad (inkl alle sosiale kostnader etc). Dette vil utgjøre det den ansatte vil koste i prosjektet. Dersom en avtale i et prosjekt muliggjør en individuell timepris som overgår lønnskostnad vil denne registreres i inntekten i prosjektet. Ved prosjekter der vi kun får refundert kostnadene pluss overheadpåslag er det medgått tid pluss overhead ifølge avtalen som reflekteres som inntekt og som det sendes faktura/rapport på til oppdragsgiver. Kartlegging del 2 - Vedlegg 6, side 23 av 27

Prosjektøkonomi Vi vil her ikke gjennomgå alle detaljer rundt oppsettet av økonomistyringen i systemet, men kun nevne det vi tror er av interesse. Prosjektmodulen er en elektronisk applikasjon som vil inneholde informasjon om alle våre eksternt finansierte (forskning) prosjekter. I denne modulen skal man kunne samle all administrativ informasjon om prosjektene, holde orden på oppgaver som skal gjøres og knytte til dokumenter/søknader etc om ønskelig. Alle eksternt finansierte prosjekter skal registreres med et budsjett. Eksterne og interne prosjekter I dag opererer vi med både interne og eksterne prosjekter. Interne prosjekter består ofte av regnskapstransaksjoner som man ønsker å se samlet på og ta ut rapporter over, men som ikke finansieres av eksterne oppdragsgivere, men av interne midler, slik som interne overheadmidler eller interne overføringer fra andre prosjekter. Eksterne prosjekter er prosjekter der vi mottar midler fra eksterne kilder regulert gjennom bevilgningsbrev, inngått kontrakt eller annen skriftlig, bindende dokumentasjon. Eksterne prosjekter har jo også som kjent visse kriterier knyttet til seg som må oppfylles for at finansieringen opprettholdes. Det er de eksterne prosjektene som skal registreres i prosjektmodulen, og der all den økonomiske informasjonen om disse prosjektene skal registreres. Interne prosjekter behandles og bokføres på samme måte som i dag gjennom interne prosjekter i finansmodulen. Data fra prosjektmodulen overføres til finansmodulen daglig, men det er fra prosjektmodulen informasjon om eksterne prosjekter vil hentes. Rapporter over prosjektene vil, slik som i dag, hentes fra Discoverer rapporteringsverktøy. Det utarbeides nye rapporter basert på informasjon fra Oracle Projects. Midlertidige prosjekter Den nye prosjektmodulen gir adgang til å opprette midlertidige prosjekter der det kan opprettes kalkyler til bruk i søknader. Prosjektet vil merkes med at det er midlertidig, eventuelt at søknad er sendt, at søknad avvist, godkjent etc. Når bevilgningen er på plass og ressurser knyttes til prosjektet, endres prosjektstatus til Godkjent, og det vil fremkomme som et aktivt prosjekt som skal inkluderes i den økonomiske informasjonen ved avdelingen. Overhead Alle prosjekter merkes selvsagt med en overhead-prosentsats som korresponderer med det som er avtalt med kunden/oppdragsgiver. Derimot vil vi forsøke å endre litt på rutinene slik at overhead i prosjektets inntekt, det som skal faktureres eller sendes rapport på til kunden, vil inneholde det påslag som er avtalt. Prosjektets kostnadspåslag vil derimot kalkuleres til en prosent som er lik den avdelingen må ha fra alle sine eksterne prosjekter for å kunne gå i balanse, eventuelt nå sitt økonomiske mål. Disse to satsene kan være ulike, og forskjellene vil reflekteres i prosjektets resultat. Eksempel: Dersom et prosjekt er avtalt et påslag/overhead på 25% med oppdragsgiver, er det dette man vil rapportere / fakturere oppdragsgiver. Er behovet for gjennomsnittlig overhead fra alle eksterne prosjekt i avdelingen kalkulert til 35%, er det dette som vil være påslaget i overheadkostnad i prosjektet. Prosjektet vil da gå med et underskudd, noe som vil vise avdelingen at prosjektet er underfinansiert i forhold til behovet for dekning av administrative kostnader i avdelingen. Dette underskuddet vil være til intern orientering og vil ikke rapporteres til oppdragsgiver. Dette opplegget vil signalisere for hvert eneste prosjekt om det bringer inn nok midler til at avdelingen kan drives i balanse. Dette forutsetter selvsagt at den kalkulerte overhead som belastes prosjektene er kalkulert på en måte som reflekterer behovet ved avdelingen. Overheadkostnaden ved avdelingene kan endres. Overheadkostnad kan selvsagt være ulik ved de ulike avdelinger og seksjoner/forskergrupper. Rapporter Rapporter over prosjektøkonomien gjøres tilgjengelig gjennom rapporteringsverktøyet Discoverer. On-line rapporter og prosjektstatus, rapporter over grupper av prosjekter etc hendtes fra skjermbildene i prosjektmodulen. Dataene fra prosjektmodulen som overføres til regnskapssystemet daglig mister derimot sin prosjektreferanse i regnskapssystemet/finansmodulen. Fra finansmodulen hentes data vedr inntekter og kostnader ved avdelinger, seksjoner og forskningsgrupper, inkludert både eksterne og interne prosjekter. Man vil her se hvor mye inntekter, kostnader, overhead etc som genereres fra eksternfinansiert aktivitet, men man kan ikke lenger rapportere de eksterne prosjektene fra denne modulen. Dette er gjort bevisst. Avdelingens økonomi vil hentes fra finansmodulen/regnskapssystemet. Økonomisk informasjon om prosjektene helt fra oppstart frem til dato vi hentes i prosjektmodulen. Skillet er gjort fordi man i regnskapssystemet kun vi kunne se informasjon innenfor regnskapsårets varighet, nemlig fra 1/1 til 31/12 hvert år. Dette er perioden som avdelingene og organisasjonen for øvrig skal rapportere over. Økonomisk informasjon om hele prosjektperioden for de ulike prosjektene som ofte går på tvers av regnskapsårene vil nå bli tilgjengelig fra prosjektmodulen. Kartlegging del 2 - Vedlegg 6, side 24 av 27

Godkjenning av prosjektstatus Som nevnt overfor overføres data mellom de ulike modulene i Oracle daglig. Periodisert inntekt, dvs den inntekten man opptjener i løpet av en måneds arbeid, genereres /kalkuleres derimot kun én gang pr måned. Dette gjøres etter at tiden som de ansatte er allokert til er blitt lastet opp i prosjektregnskapene. Vi ser for oss at prosjektøkonomene laster opp de anviste arbeids-bilagene tre til fem dager etter en kalendermåneds slutt. Når dette er gjort er også månedens driftskostnader og eventuelle reisekostnader ført på prosjektet og Oracle Project genererer så en kalkulert inntekt for foregående kalendermåned basert på kostnadene som er belastet prosjektet inkludert den overhead-% som er avtalt med oppdragsgiver. Før denne inntekten blir overført til Oracle financials/regnskapssystemet som avdelingens inntekt for foregående måned for eksterne prosjekter, ønsker vi at eierne av prosjektene, det være seg forskningsdirektører eller dem dere ønsker å delegere ansvaret til, skal sjekke prosjektenes status før denne overføringen skjer. Dette er gjort for å kunne kvalitetssikre den økonomiske informasjonen i regnskapssystemet bedre enn det vi klarer i dag. Videre tror vi det kan hindre overraskende underskudd/overskridelse i prosjektene dersom dere på månedlig basis får fremlagt rapporter over prosjektenes status. Meningen er at man på et tidlig tidspunkt skal kunne avdekke merforbruk eller lignende og eventuelt omdisponere ressurser, redusere kostnader, tilføre andre midler eller søke om tilleggsmidler dersom tilfellene inviterer til det. Vi har jobbet svært mye med leverandøren rundt denne prosessen. Vi tror nå vi har kommet frem til en funksjonell statusrapportering som raskt vil oppgi den informasjon dere trenger for å kvittere for de prosjektene prosjektene som er i rute. Vi vil sette opp retningslinjer for hvorledes korreksjon og endring av kostnader og inntekter mellom prosjekter kan gjøres for å regulere eller endre prosjektenes status slik at de kan godkjennes. Prosjektøkonomene kan gjøre en slik endring med autorisering fra prosjekteier. Skjermbildet for godkjenning av prosjektstatus er svært fleksibelt mht kolonnevalg av ønsket økonomisk informasjon og kan tilpasses individuelt. Til slutt Vi har nedlagt svært mange timer i utvelging og planlegging og oppsett av den elektroniske prosjektmodulen. Som tidligere nevnt har gruppene jobbet svært godt sammen. Vi tror at vi har funnet en løsning på et prosjektsystem som vi håper vi vil bli fornøyde med. En vellykket implementering avhenger også av god informasjon om systemet inn i organisasjonen samt at brukerdokumentasjon og opplæring gjøres på en skikkelig måte. Kartlegging del 2 - Vedlegg 6, side 25 av 27