VEDLEGG 1: Test Regnskapsseksjonen

Transkript

1 VEDLEGG 1: Test Regnskapsseksjonen Testing av Oracles PA modul i Regnskapsseksjonen høsten 2007 En stor gruppe i Regnskapsseksjonen har deltatt i forberedelsene og testingen av PA modulen i perioden frem til medio desember Testingen ble delt inn i fire temaer: - 1. Ressurs- og kompetansebehov (Ansvarlig Stein) - 2. Systemtesting (Ansvarlig Elisabeth) - 3. Regnskapstesting (Ansvarlig Tone) - 4. Formelle forhold vs regnskapsregler (Ansvarlig Aud/ Mimi) Medarbeidere i seksjonen har samlet sett benyttet 110 dagsverk til dette arbeidet i Til tross for dette betydelige ressurforbuket er utført testing begrenset. Testingen har vært konsentrert om å sannsynliggjøre at systemet kan møte de utfordringene vi ser i dag. Det er forhold som ikke er testet og det er forhold som ikke kan testes. Eksempler på det siste kan være integrasjon mot andre systemer (SAP) og rapporteringen. Det er på sin plass å understreke at gjennomført test ikke isolert er et fullgodt beslutningsgrunnlag for hvorvidt løsningen bør velges eller ikke. En eventuelle anskaffelse og implementering vil kreve helt andre testomfang enn de som er gjennomført høsten Konklusjon Til tross for en ikke fullstendig test har jeg god tro på løsningen. Den vil fungere, men vil kreve mye av oss. På kort sikt vil ressurforbruket være betydelig større enn gevinsten. På lengre sikt vil det lønne seg, og over tid vil vi neppe kunne klare oss (konkurransesituasjon om midler, DOK 1) uten et system som bidrar til mer korrekt bokføring og dokumentasjon av prosjektene. Ikke alle argumenter taler for konklusjonen over. Nedenfor er det listet noen argumenter som taler til fordel for løsningen såvel som det motsatte i form av en del utfordringer. For løsningen: - UiO skal øke andelen prosjekter med tilhørende midler i forhold til annen inntekt/ bevilgning noe som vil være drivende i forhold til å ha et system for å håndtere de nye prosjektene. Det er mye som tyder på at fremtidige prosjekter kan bli mer komplisert enn dagens og vil bli utsatt for stadig nye krav. - I dag er samtlige prosjekter beheftet med feil i bokføringen. Et system vil gi oss bedre og flere muligheter til å gjøre ting mer korrekt. - Kravene til prosjekthåndtering på alle områder vil trolig øke i tiden som kommer, fra departement/ sektor, fra prosjektfinansiører og fra Riksrevisjonen.

2 - Løsningen er oppe og går i andre store organisasjoner over hele verden med kompleksitet som antagelig overgår vår egen. Slik sett er programvaren antagelig ikke begrensningen. - Riksrevisjonen stiller høyere og høyere krav uavhengig om vi innfører et slikt system. Kravene fra Riksrevisjonen vil antagelig være vanskeligere å oppnå uten system enn med. - Gevinsten av å innføre et omfattende prosjektstyringsverktøy er høyere kvalitet. Mer korrekt måling av hva aktivitet koster vil kunne gi oss impulser til i neste omgang å prise våre bidrag/ oppdrag på et mer korrekt nivå. (les: riktigere pris er høyere pris) Utfordringer: - Programvaren har et brukergrensesnitt og et antall skjermbilder som krever tilvenning av brukeren. Her er ikke alle skjermbilder, fremdriftsvalg og kommandoer intuitive. Det er en relativt høy brukerterskel. - Løsningen er basert på time-/ tidsregistrering. Dette oppleves hos oss som en politisk beslutning som det til nå ikke har vært vilje til å ta. Mangel på beslutning vil vanskeliggjøre innføringen og effektiviteten i løsningen. - Begrensingene ligge neppe i programvaren, snarere i vår evne til å utnytte den og vår evne til å endre organisasjonen og de kulturelle aspektene. ( Forskerens frihet ) - Løsningen stiller store krav til hele organisasjonens vilje og evne til å ta den i bruk. Utfra mange erfaringer knyttet til denne evnen og viljen kan det reises spørsmål om organisasjonen vil makte det økede ressursuttaket på de mest pressede av sine egne ressurser. Det er neppe tvil om at innføringen av en prosjektmodul vil øke ressursbruken betydelig på de enheter som skal benytte systemet. - Realistisk sett er det nærliggende å tenke seg en fremdrift over minst 2-3 år, med utrulling i et tempo som tilsvarer opplæring av brukere og godkjent mestring. Det vil innebære en lang periode med to sett systemer og rutiner. Oslo, /HM Vedlagt innklippet rapportene fra de forskjelige gruppene.

3 1. Ressurs- og kompetansebehov (Ansvarlig Stein) Forutsetninger: Enhetene legger selv inn alle data på prosjektene. Omfatter bl a at de selv oppretter alle typer prosjekter, også interne. Innebærer også at alle endringer underveis forlengelser, budsjettendringer, satser mv mv legges inn av enhetene. PROSJEKTADMINISTRASJON I RS Prosjektopprettelser. Hva innebærer av saksbehandling? Trykker RS på en knapp for at det skal bli posterbart. Legge begrensninger på prosjektforlengelser? Hva innebærer av saksbehandling? Prosjektavslutninger: er det avklart hvordan dette skal skje? Autoavslutning på utløpsdato? Autokontering? NFR-fordeling. Hvordan vil dette bli besluttet håndtert i PA? Er det mulig å massefordele NFR-innbetalingene slik vi gjør i dag i PA må det evt lages en faktura per prosjekt per NFR-tildelingstidspunkt? Hvem avstemmer evt alle disse fakturaene mot NFR sine samlelisteoverføringer. Kan NFR sine betalingsrutiner avtales annerledes, evt at de mottar enkeltfakturaer? Antatt ressursbruk: som idag BRUKERSTØTTE OG OPPLÆRING Brukerstøtte. Antall henvendelser i Basware i dag opptil 20 daglig. (får PA like mange brukere)? Opplæringsbehov. Hvordan skal opplæring foregå? E-læring (UPK), Web? Hvem skal vedlikeholde læringsmateriell? Stor og viktig jobb. Hvem / hvor ofte evt kurs? Organisering av kurs ovf brukere, superbrukere ute og inne. Hvordan skal superbrukere (i RS og ute få opplæring) hos Oracle? Antas at brukerstøtte og opplæring vil være ressurskrevende. Modul er betraktelig mer kompleks enn AP og AR, dvs flere skjermbilder, flere data skal legges inn. Ikke bare transaksjoner som i AR og AP, men også verdier. Antatt ressursbruk: 1 årsverk (i stabil drift) OVERFØRING AV DATA MELLOM MODULER Overføring av data til / fra. Hvem har ansvaret for å sette i gang prosesser og postere/ sikre? Hvor komplisert er dette? Forventet ressursbruk: I dag (i stabil drift) tar oppgaven inntil en time per dag (for 1 modul). Ved feil vil det ta mer tid. Forventning PA i stabil drift: Skal integreres med 5 (?) moduler. I tillegg går datastrømmer begge veier (?). Antatt ressursbruk: 1 årsverk i stabil drift (LM) AVSTEMMING Avstemming saldi / transaksjoner mellom PA-GL (transaksjonsdata), GL-PA (verdisett som artskontoplan, tiltak?) Pols-PA (reiseregninger, oppdatering av stedkoder), PA-AR (fakturadata) (AR-PA?), AP-PA (innkjøp / investeringer), Basware- PA(?), PA-FA (utstyr) (FA-PA?). Avskrivninger? Sammenlikne med tilsvarende ressursbruk per i dag forsystemer GL. Hvilke datastrømmer er kun en vei, hvilke begge veier? Hva skal avstemmes, hvordan skal det avstemmes, gode rapporter / spørringer, Match nyttig/nødvendig? Avstemming per i dag AR/AP: inntil 1 dag per modul per mnd, kontrollmatrisepunkter 1-1,5 dag per modul per mnd. Vil dette være mer ressurskrevende i PA?

4 Antatt ressursbruk: 15% årsverk i stabil drift (LM) KONTROLLMATRISE Kontrollmatrise hvilke endringer / konsekvenser? Antakelig tilsvarende eller mer arbeid enn per i dag. Kompetansekrav / tilgang til modulen for å foreta kontroller lokalt og sentralt. DRIFT / ORGANISERING Hvilken enhet skal ha eierskap til modulen brukerstøtte / systemadm mv? Forutsetter at det er RS. Hvor skal de ulike oppgavene ifm drift av PA ligge i RS? Hvor mange trenger kompetanse på PA, og på hvilket nivå? Første- andre og tredjelinje: Førstelinje superbruker på enhet, deretter mailgruppe i RS. RAPPORTER Rapportregime i PA. Er det gode standardrapporter? Hvilke rapporter må evt utvikles / tilpasses? Hvem skal drive rapportvedlikehold? Hvor mye tid kan dette antas å ta? Kan man anta samme ressursbruk som i AP? Rapporter kan ikke tas ut av GL på prosjektsegmentet: hvilke utfordringer skaper dette rapportmessig? Discoverer blir hovedrapportverktøy. Vi har kompetanse på tabellstruktur generelt, trenger det som er spesielt for PA. Antatt ressursbruk: 15-30% av årsverk i stabil drift (RKL). SYSTEMVEDLIKEHOLD Testregime: oppgraderinger vil følge samme versjoner / tidspunkter som Oracles andre moduler? Går inn i samme testregime som administreres i dag av gruppe 3? Hva blir mer-ressursbruk ifm dette? (1 modul pluss) Brukeradministrasjon (mer arbeidskrevende i PA) Kryssvalideringsregler / sikkerhetsregler (sette opp på ny måte, prosjekt ikke i GL) Vedlikehold av faste data i PA (Pedit-satser, OH %-satser, timesatser, konteringsregler Tilrettelegge for rapportering, sluttbrukerlag, webrapporter Overvåke oppdateringsprosesser Antatt ressursbruk: 50% av årsverk i stabil drift (EK) DOKUMENTASJON Hva må oppbevares av regnskapsmateriale? Hvor og hvordan (skal timelister oppbevares fysisk? Prosjektdokumenter i lokale arkiv? FINANSREGNSKAP Egenkapital: ved prosjektavslutninger oppdragsprosjekter hvordan foretas disse føringene? Manuelt eller ved autojobber? Kontroller. Avregning: Avregning automatisk eller manuelt per prosjekt? Hvilke kontroller må legges inn? Skal utføres ved RS eller lokalt? Kontering av egenfinansiering. Egen rutine, oppfølging, gjøres av enhetene. ANTATT RESSURSBRUK:

5 Utfra de forutsetninger og begrensninger i informasjon nevnt over. Da er ikke inkludert mulig mer-ressursbruk ifm kontrollmatrise og finansregnskaps-punktene over. STABIL DRIFTSFASE: 3 årsverk OPPSTARTSFASE (ca ett år): 6 årsverk Det vil kreve store ressurser i innføringsfasen på alle områdene. Mht å få systemet til å virke stabilt, kompetansebehov, opplæringsbehov, avstemmings, overføringsjobber mv. Hvordan skal dette løses? Viktig at oppgavene gjennomføres og at kompetanse og rutiner opparbeides i RS og UiOs enheter. Dels gjennom innleide konsulenter, dels vikarer og med faste ansatte som opparbeider kjernekompetansen. 2. Systemtesting (Ansvarlig Elisabeth) Gruppen har bestått av Anita Siljuberg, Line Dolmseth og Elisabeth Kolstad Gruppens oppgave var å teste: 1. Følge prosess fra A til Å, og kontrollere at det ikke kommer noen feilmeldinger. 2. Kryssvalideringssjekk. 3. Behov for systemadministrasjon. Gruppen har testet prosess fra A til Å for: Case 1 - NFR prosjekt med PEDIT Case 2 - Oppdragsprosjekt med PEDIT Case 4 EU prosjekt Case 5 Interne prosjekter Vi kunne i utgangspunktet lite om både fag og system. Det hadde nok vært enklere å komme i gang dersom det var laget en kokebok for hver prosjekt type. Oppsummering +\- av testfunn: Positivt: Ingen kritiske feil er funnet. Integrasjonen mellom AP, AR og GL er standard. Etter å ha vært i gjennom et par testcaser ble vi raskt mer fortrolig med systemet. Vi mener at tidsbruken og kontrollen blir betraktelig forbedret ved å ta systemet i bruk. Negativt: Systemet virket vanskelig å ta i bruk for en fersk bruker, relativt høy brukerterskel. Det opplevdes litt tungt å legge inn kalkyler/budsjett. Det må vurderes ved en evt. utrulling om det er mulig å laste inn regneark el. tilsvarende for å lette arbeidet.

6 Det tok forholdsvis lang tid å gjennomføre en testcase. Dette må imidlertid ses opp mot tiden man bruker på de samme operasjoner uten prosjektverktøyet (opprette prosjekt, kalkulere, budsjettere, føre timer og kostnader, fakturere etc.). Vi fant noen småfeil. Disse er meldt til Oracle som vil kvalitetssikre og rette. Se side 3 for detaljer. Behov for systemadministrasjon: Det er en tyngre prosess å legge inn PA brukere enn vanlige OA brukere. Det vil bli flere ansvarsområder som skal tilrettelegges og vedlikeholdes. Dette i tillegg vanlig feilretting og annen saksbehandling. Det anslås 1 årsverk til disse oppgavene i stabil drift. Detaljer fra PV testing med svar fra Oracle 1. Generelt: Altfor mye informasjon på hver side (web). Bør renskes for unødig info. Er det mulig? Det er en mulighet i Oracle for å personalisere sidene. Dette betyr at vi kan justere skjermbilder på ulike nivåer (bruker, ansvarsområde etc). Dette bør være gjort strukturelt i forhold til oppgraderinger. Dette kan ses på som en del av nye faser/crp er. 2. Opprette prosjekt fra mal (bagatell) Skal dato angis med. som skilletegn? Eller spiller det ingen rolle? Men kan enten legge inn en dato ved å bruke kalendar-knappen og trykk på riktig dato, eller ved å bruke. som skilletegn. 3. Skal basisbudsjettet ha Plantype = Kalkyle? Eller må man opprette en Plantype = Budsjett og så kopiere kalkyle til denne? Vi er litt forvirret trenger en kokebok med step-for-step fremgangsmåte for de prosjekter hvor vi lager kalkyler før budsjett. Å lage en kalkyle er valgfritt. Kalkyle er ikke noe annet enn et søknadsbudsjett, men det er ikke nødvendig for å gjennomføre et prosjekt. Et inntektsbudsjett er imidlertid påkrevet for fakturerbare prosjekter. Både en kalkyle og budsjett må basisbudsjettereres. Man lager en arbeidsversjon som blir basisbudsjettert etterpå. Grunnen til dette er å beholde historikken. En basisbudsjettert versjon er ikke mulig å slette. 4. Er det nok å ha et basisbudsjett med plantype = Kalkyle for å starte kostnadsføring på prosjektet, eller må det være et basisbudsjett med plantype = Budsjett? Line og Anita testet prosjektnummer = (Internprosjekt). Da var det ikke nødvendig å lage et budsjett, de hadde kun en kalkyle som ble basisbudsjettert. Avtalebeløpet ble korrekt fordelt, basisbudsjettert? Trenger man ikke lage et budsjett????????? En basisbudsjett med plantype budsjett er krevet av systemet. Inntektsbeløp på budsjett skal være likt som avtalebeløp. På interne prosjekter trenger man ikke å ha et budsjett, og det er bare på fakturerbare projekter at man må registrere inntektsbudsjett og avtalebeløp. 5. PA Superbruker: Skjermbilde for å lage Avtale feltet Hard grense for fakt.. Her må HELE ledeteksten være synlig!!! Dette er ikke mulig. Det står Hard grense for fakturering. 6. Hendelse (event) hva er det? Må vi registrere en hendelse for hver faktura vi skal sende ut, eller skal vi bruke det bare når vi skal fakturere a-konto? Dersom man skal fakturere mange terminer bør man kunne kopiere. Er det mulig? Hvorfor må vi velge type Manual, og ikke Faktura?

7 Hendelse er noe som brukes for å registrere beløp for å registrere inntekts- og/eller fakturabeløp, uavhengig av påløpte transaksjoner. Hendelsesbeløp kan brukes til akontofakturering, fakturering og inntektsgenerering av fastprisbeløp, generering av inntektsnedskrivning eller oppskrivning m.m. Hendelser kan ikke kopieres, de må registreres enkeltvis manuelt. Grunnen til at vi test har brukt Manual er at vi da både kunne registrere inntekts- og fakturabeløp på hendelser, dersom det var ønskelig. 7. Timereg. Manuell Send/Frigi. Hvorfor må man både sende og frigi? Er det meningen at personer med ulike roller skal hhv sende og frigi? Denne funksjonaliteten er der for at man skal kunne skille på hvem som sender og hvem som endelig frigir en utgiftsbunke. Det er opp til den enkelte kunden om denne funksjonaliteten ønskes benyttet. 8. Fakturering: Både Frigi og Godkjenne? Samme som over? Samme tankegang som over for denne funksjonaliteten. 9. Faktura i AR: Når vi manuelt registrerer i AR oppgir vi en stedkode i Selgerfeltet. For PA fakturaer kommer prosjektleders navn i dette feltet: Tiller, Doktor Roar Alexander Selger er påkrevet i henhold til oppsett i AR for UiO. Som følge av dette må det for prosjektfakturaer fra PA sendes over informasjon om selger fra Pa til AR. I testsystemet har vi lagt opp til at det på alle maler og prosjekter alltid er Doktor tiller som overføres. Dette oppsettet er gjort for å få overført fakturaer fra PA til AR i test. Dette oppsettet må diskuteres nærmere i et evt. videre implementeringsløp. 10. Konteringer: UiO, timer bilagslønn: Ble kontert og overført GL selv om vi ikke oppga tiltaksnummer. I henhold til de definerte konteringsreglene defaultes en standard tiltaksverdi for timetransaksjoner, dersom dette ikke er blitt registrert av brukeren. (For diverse transaksjoner er det motsatt, dersom tiltakskode ikke er definert vil det ikke bli avledet noen kontering. Dette er som nevnt på tidligere møte for å vise dere hvilke muligheter som finnes). Ber om tilbakemelding derom dere ønsker å endre på dette. Debet konteringer: Tiltak IKKE angitt ved reg Tiltak angitt ved reg. Kredit konteringer: Her ble prosjektets eiersted belastet, mens ansattes eiersted ble godskrevet (152160)Det er vel riktig?

8 Dette er i henhold til de oppsatte konteringsreglene. Ber om tilbakemelding derom dere ønsker å endre på dette. 11. Konteringer internprosjekt Dahl, 09-DES Dahl, 09-DES ,00 Ufullstendige autoregnskapsr 10,00 Ufullstendige autoregnskapsr Feiler for timer reg. både med og uten tiltakskode. For å gi svar på dette er vi avhengige av å kunne se disse transaksjonene i systemet. Det får vi desverre ikke til fra der hvor vi sitter nå, så det må vi se nærmere på når vi er inne i applikasjonen. Dette prosjektet har kun en basisbudsjettert kalkyle og ikke et budsjett. Er det derfor? Nei, det er ikke grunnen. Her må vi se nærmere på de definerte autoregnskapsreglene, for å analysere årsaken til dette. 12. Fleksifeltet i PA Superbruker skjermbilde Prosjekter, Malsammendrag. Tre attributter, hva skal disse brukes til? Skal vi fylle ut noe, eller bør de skjules? 1. Feltet Konteringsregel trenger dere ikke fylle ut slik rutinene er i dag. 2. Feltet for Gml. Prosjektnummer skal ikke fylles ut. Dette er tenkt brukt som refernase til prosjektnummer i gammelt system, for prosjekter som konverteres inn i Oracle Projects. 3. Feltet for UIO Ttiltakskode Inntekt skal fylles ut med en verdi fra plukkliste for tiltakssegmentet i kontostrengen. Dette ettersom denne verdien brukes av autoregnskap ved generering av inntekter. 13. Mimi testet prosjekt nr UiO, Oppdragsprosj. Hun fikk en melding: Prosjekt- eller programstrukturen er endret. Du kan gjøre.etc. Men, hun mener selv at hun ikke har endret struktur.????? Dette skal vi se på neste gang vi er hos UiO. Vi har opplevd det samme og dette skjer hvis man endret aktivitetsstruktur på en prosjekt. Meldingen er ikke kritisk og vi mener at det er en bakgrunnprosess som man skal kjøre for å unngå denne meldingen. 14. EU prosjekt nr valutaspørsmål. Skal vi legge inn kalkyle beløp i EUR? og budsjettere i NOK eller? Benyttes valutakurs, dvs. lagres valutabeløp også i basisvaluta? Det er en mulighet for å legge inn kalkyle i EUR men budsjett kan kun være i NOK. Man kan registrere alt i NOK og se tallet etterpå i EUR hvis man vil. Når vi kalkulerer i EUR blir ny linje automatisk opprettet i NOK. EUR linjen forblir tom selv om det er denne linjen vi har knyttet kalkulerte timer til. Skal det være slik????? Nei, det skal ikke være slik. Vi skal se på dette neste gang. Basisbudsjettert kalkyle beløpene er ikke gjenkjennelige. For eksempel totale kostnader i NOK = ,- blir EUR = ,18??? Kan se ut som om Andre driftskostnader og reiser (der hvor beløp legges inn) blander NOK og EUR, beløp blir altfor høyt.

9 Nei, det skal ikke være slik. Vi skal se på dette neste gang. Fra skjermbildet: Beløpene er angitt i Prosjektvaluta: EUR. Innsatsbeløpene er fra kostnadsversjonen.hvis du vil redigere planversjonen, må du først frigi den på siden Ajourfør budsjettversjoner Får dermed ikke basisbudsjettert i EUR (selv om avtalebeløp i EUR = Inntektsbeløp i prosjektvaluta (EUR)): Feilmelding: Aktivitetsfinansieringen er ikke lik budsjettets totalsum for aktiviteten. Hvis du skal opprette et basisbudsjett for et budsjettutkast, må budsjettets totalsum være lik total finansieringssum. Det kan oppstå en avrundingsforskjell selv om både forms og web bruker en kurs som er lik 8. Vi anbefaler at dere se på testskript om å registrere avtale i EUR. Da har man en mulighet å se NOK beløp fra en EUR registrerte avtale. NOK beløpet skal være lik basisbudsjetterte NOK beløp da. Hvis den er ikke lik, må man enten justere budsjett eller avtalebeløp. Måtte legge inn avtalebeløp i NOK = Inntektsbeløp i basisvaluta (NOK), da gikk det bra: Det ble opprettet et basisbudsjett for budsjettversjonen: Versjonsnavn Budsjett 1 - ANITA og ELISABETH, versjonsnummer Visningsrekkefølge Ved innlegging av kalkyle - kalkylelinjene vises i alfabetisk rekkefølge, og IKKE i registreringsrekkefølge.. Kan man endre det? Det er mer logisk at linjene vises fortløpende etter insert, særlig når man sitter og legger inn nye linjer. For senere oppslag kan det godt vises alfabetisk. Dette skal vi se på neste gang. 16. Andre driftskostnader: Velger vi UiO, reiser.. etc. eller DK: Reiser.. etc.??? DK: Reiser etc MÅ man legge inn avtale før man kan lage et basisbudsjett på fakturerbare prosjekter? For å basisbudsjettere en budsjett må man ha en avtale. 3. Regnskapstesting ( transaksjonstest PA) (Ansvarlig Tone) Test er gjennomført av: Nina, Anita, Erik og Tone. I tillegg er det testet transaksjoner av gruppen som testet system. Transaksjonstestingen startet ved at vi hadde leid Oracle for bistand i testen og en gjennomgang av PA. Det ble ved hjelp av Oracle opprettet ett prosjekt som eksempel/test, og det ble ført kostander og inntekter mot prosjektet. Dokumentasjon av dette prosjektet inngår i testdokumentasjonen. Mål for testen: Det opprettes prosjekter i de forskjellige prosjektkategoriene. Alle transakjonstyper registrers på de enkelte prosjektene, og transaksjonene overføres og posteres i hovedbok. Alle konteringer kontrollers mot forventet konteringer definert i dokument Løsningsbeskrivelse for Autoregnskap. Det er ingen integrasjon mot lønn (POLS) eller Basware. Transaksjonstyper fra disse systmene er testet ved manuell registrering av transaksjoner.

10 Mangler i testen: Pga manglende kunnskap til systemet har det vært problemer med å få opprettet prosjekter til bruk i testen. I testperioden har deltagerne i testen hatt andre oppgaver som har blitt prioritert foran testing.enkelte prosjetkategorier er derfor ikke testet. Det er ikke testet transaksjonstype omposteringer, for omposteringer/korrigeringer av feilføringer på prosjekt og mellom prosjekter. Det er imidlertid avklart med Oracle at det er mulig å overføre trasaksjoner fra ett prosjekt til et annet og fra en aktivitet til en annen aktivitet. Prosjektavslutning er ikke testet. Avgiftshåndtering: Under testen kom det opp en problemstilling rundt føring av utgående merverdiavgift. Inntektesføringen trigges av kostnadspådraget på prosjektene, og konteringen ved inntektesføring er: kredit inntektsarten og debet balanse art Opptjente ikke fakturerte prosjektinntekter. På faktureringetidspunktet blir avgiftskoden registrert og selve avgiften blir beregnet i AR (kundemodulen) og vil ikke vises i PA. Konteringen ved faktuering blir da kredit Opptjente ikke fakturerte prosjektinntekter med avgiftskode dvs avgiftkoden ligger på en balanseart, debet reskontro(kundefordringer) og kredit avgift. Vi vil ikke kunne føre rene inntektsarter mhp avgiftskode. Hvordan avgiftsavstemming og dokumentasjon skal løses er tatt opp med Oracle. Vi venter på tilbakemelding. Resultat av test: På intern prosjekt ble det avdekket feil (ufullstendige autoregnskaper)ved produksjon av kontering for timer, registrert både med og uten tiltakskode. Kreditposteringen på reisekostnader og indirekte kostander som skal utledes automatisk ble ikke utledet ved første test. Dette skal være korrigert av Oracle. Indirekte kostnader er testet ok av systemgruppa etter korrigering. Reisekostnader er ikke testet på nytt. For de andre prosjektene som ble testet var det ikke avvik mellom konteringen på transkasjonene og kravene i Løsningsbeskrivelse for Autoregnskap. Merk: dokumentet Løsningsbeskrivelse for Autoregnskap må gjennomgås på nytt da det gjennom test ble avdekket at konteringen for enkelte transaksjoner bør endres. Andre forhold: Registrering av NFR og EU prosjekter. Det bør ikke være nødendig/mulig å velge kunde. Det ikke er overført transaksjoner fra lønnssystem og ingen avstemminger er foretatt i testen. Det ble den oversendt et notat fra Elisabeth Kolstad til daværende økonomidirektør Stein Helgesen. Notatet forsøker å beskrive funksjonalietet i dagen OA på fem sentrale områder knyttet til økonomistyring.av prosjekter. Her følger konklusjonene på de forskjellige områdene: 1.Faktureringsplan: Eksisterende funksjonalitet vil kunne benyttes for å periodisere inntekter og til å lage faktureringsplaner til enkeltfinansiører, men er ikke egnet til å automatisere fakturering etter en definert plan.

11 2.Budsjettversjoner: Budsjettversjoner i GL er ikke hensiktsmessig å opprette for enkeltprosjekter. 3.Flerårighet: Det anbefales at vi utreder videre muligheter til å rapportere PROJECT_TO_DATE verdier, og dersom kvaliteten er tilfredsstillende bør informasjonen tilgjengeliggjøres i rapportdatabasen. 4.Indirekte kostnader: Det eksisterer ingen tilfredsstillende løsning i dagen installasjon av OA for kronepåslag av indirekte kostnader. 5. Prosjektbalanse: Dagens installasjon av OA har ingen informasjon om fremdrift i et prosjekt, og er derfor uegnet til dette formålet. Punkt 1 til 5 beskriver funksjonalitet som er tilgjengelig i PA. Konklusjon: Vi har ikke avdekket noen kritiske feil. Integrasjon mellom AP, AR og GL er standard. Etter at brukerne har vært gjennomt et par testcaser ble de rakst fortrolige med systemet. Prosjektmodulen vil gi oss muligheter til løpende bokføring av egenandel på prosjekter, balanseføring av inntekter og inntektsføring på prosjektet ihht kostnadspåslag og flerårig rapportering og budsjettering. Vi mener at tidsbruken og kontrollen blir betraktelig forbedret ved å ta systemet i bruk. Alle som har testet gir uttrykk fot at modulen har en høy brukerteksel. Det tilføyes imidlertid at etter at de har opprettet noen prosjekter virker det mye greiere. Sidene (web) inneholder en del informasjon vi ikke benytter, men det er avklart med Oracle om at det er mulig å tilpasse sider (web) for å rense vekk unødig info. Det oppleves litt tungt å legge inn kalkyler/budsjett. Det tar forholdsvis lang til å gjennomføre en testcase. Dette må imidlertid ses opp mot tiden man bruker på de samme operasjoer uten prosjektverktøyet (opprette prosjekt, kalkulere, budjsettere, føre timer og konstnader, fakturere etc.) Det vil kreve store ressurser i innføringsfasen på alle områdene. Mht å få systemet til å virke stabilt, kompetansebehov, opplæringsbehov, avstemmings, overføringsjobber mv. Det er viktig at oppgavene gjennomføres og at kompetanse og rutiner opparbeides i RS og UiOs enheter. Innføring av PA vil er beregnet til å kreve 6 årsverk ekstra i en oppstart/innføringsfase og 3 årsverk i stabil drift. Åpne punkter: Omposteringer/korrigeringer (mellom prosjekter og basis) Bokføring og avstemming av utgående merverdiavgift. Konvertering Integrasjon (POLS) Avstemming Rapportering 4. Formelle forhold vs regnskapsregler (Ansvarlig Aud/ Mimi) I testperioden har tiden gått med til prosjektopprettelse, budsjettering, belastning av transaksjoner og fakturering. Det var ikke på nåværende tidspunkt mulig å få en rapport fra PA over hva som var registrert ved et institutt eller innen en bestemt prosjektkategori. Å fremskaffe en slik oversikt ville derfor være en tidkrevende, manuell oppgave. Uten en fasit ble det vanskelig å teste såvel avregning som korrekt overføring til hovedbok og påfølgende rapportering. Det vi kan konstatere er at det - ikke finnes prosjektnummer fra PA i hovedboken - er postert på klumpprosjekter i hovedboken, på relevante arter

12 Det er liten tvil om at løsningen vil være mulig å få på plass når data fra PA blir tilgjengelige i Discoverer. Bekymringen går ikke på om systemet kan løse oppgavene, men om UiO er villig til å satse så brukerne får den tid og de ressurser som vil kreves for at løsningen kommer opp og i gang på en god måte.

13 VEDLEGG 2: Testrapport fra MatNat PRE-PILOTTESTING AV ORACLE PROSJEKTMODUL NOV Deltakere: Jan E. Aldal, seksjonsleder MNF adm Aasta Engh, prosjektøkonom/førstekonsulent Biologisk institutt Kjetil Bråthen, økonomileder Inst. for Molekylær biovitenskap 1. Målsettinger. Før testen hadde vi møte med Simen Jørgensen ang. målsettinger for prepilottesten og hvilke deler av prosjektverktøyet (PA) vi skulle teste. Det ble satt ned noen hovedmålsettinger som skulle rettlede oss i hvilke kriterier testgruppen skulle vurdere systemet etter. Disse omfattet: Fokus PA (fra Simen): Kvalitetssikre prosjekttmaler, herunder test av finansiørs rapporteringskrav. Vurdere ressursbruk Vurdere opplæringsbehov og brukerstøtte Vurdere organisering og driftsregime Se på rollefordelingen på lokalt nivå, dvs fra fakultetsnivået og nedover. Inkludere roller som prosjektleder, prosjekteier, prosjektøkonom, prosjektsekretær mm Videre definerte den lokale testgruppen følgende målsettinger: Se på verktøyet både som økonomikonsulent og prosjektleder. Brukervennlighet: i form av lett å bruke for nye brukere, lettfattelige menyer/tekster på de ulike menyvinduene, standardoperasjoner skal ikke være tidkrevende, enkelt å ta ut de mest sentrale data for et prosjekt og forståelige standardrapporter i OA. Teste økonomidelen i prosjektregnskapet, dvs i forhold til det som er "riktig" økonomi for en vitenskapelig tilsatt og prosjektkonsulenten. Internregnskap, ikke eksternregnskap. Vi må f.eks med grunnlag i systemet f.eks kunne svare på spørsmål fra forsker på "hvor mye penger har jeg egentlig igjen". Ressursbruk på rollene: det må være mulig å definere presist hvilke roller som skal ligge inne i de ulike arbeidsprosessene og en må om nødvendig kunne fordele arbeidsoppgavene på 3 nivåer (sentralt-fakultet-institutt). Spesielt viktig å se på hvordan timeregistrering skal skje og hvilke roller (hvem/nivå) som ligger til det arbeidet. Rapportløsninger utenom OA: på et senere stadium må vi se på hvilke rapporter som må settes opp for å gi god info til involverte parter/interessenter. Noen av punktene som den lokale gruppen utarbeidet overlapper med punktene i den øverste listen fra Simen. 2. Generelle kommentarer etter testing. Følgende generelle kommentarer kan settes opp etter 2 dager med testing av PA. 1. Testingen i PA gikk så sent at gruppen ikke fikk fullført det program som var satt opp på forhånd. Det ble kun gjort elementære tester på a. oppsett av et kalkylebudsjett, b. opprette et prosjekt fra kalkyle c. innlegging av kostnadslinjer i budsjett, herunder driftskostnader, lønn og indirekte kostnader.

14 2. Det er klart at brukermanualene må forbedres kraftig. Verken manual i html eller word-format gir full ut den nødvendige beskrivelse på alle de operasjoner som må gjøres. Siden PA er såpass tungt å bruke og har et uttall av vinduer, menyer og undermenyer kreves det en detaljert beskrivelse av den enkelte operasjon. Videre må de innlimte skjermbildene fra PA forstørres kraftig opp slik at brukerne faktisk kan se hvilket skjermbilde manualen viser. 3. Begrepsbruken i PA er til dels uklar, delvis gal og delvis inkonsistent med den begrepsbruk som er i UiOs øvrige materiale rundt EFP (Per Heitmanns excel-maler, prosjekthåndbok og det vedtatte regelverk). Videre må tekstene i flere valgmenyer endres for å gi brukerne en mer intuitiv forståelse av hva de jobber med og hvordan bruke verktøyet. Det skal ikke være slik at brukere til enhver tid må ha en brukermanual i nærheten for å kunne utføre enkle, dagligdagse oppgaver. Det må gjøres et betydelig arbeid med å forbedre arbeidsflyten i PA. 4. Det er funnet feil i PA. F.eks vil verktøyet ikke ta med det siste året for 3-årige prosjekter som starter i løpet av et kalenderår (dvs annen oppstartsdato en xx). PA vil kun operere med rene kalenderår. Kostnader for den biten av året som kuttes flyttes frem til og fordeles over de andre årene. Dette blir regnskapsmessig galt. Videre fikk vi under testing ikke fritt lagt til det ønskete antall linjer (kostnadsposter) i budsjettet. 5. Siden vi ikke har brukerrettigheter til å legge inn inntekter eller kostnader for å simulere normal driftsforløp på prosjektet vi opprettet fikk vi ikke vurdert rapporteringsmulighetene, kontrollmulighetene for prosjektøkonom, økonomimodellen eller andre driftsrelevante oppgaver. Dette må gjøres før vi kan gi en fullgod vurdering. 6. Det ble ei heller mulighet til å teste finansiørs rapporteringskrav, av samme årsaker som over. 7. Deler av brukermanualen klarte vi ikke å koble til noen arbeidsoppgave. Det gjaldt den delen som ble kalt for Inntektsregistrering. Gjelder den registrering av avtalt inntekt fra finansiør ved opprettelsen/etablering av prosjektet (avtalebeløp) eller gjelder det inntekter (fakturerte?) underveis i prosjektets livsløp? Gitt de erfaringer som er summert opp i listen over har vi ikke funnet grunn til en å sette tilbakemeldingene inn i noe systematisert oversikt ennå. Det er dog gjort kommentarer underveis når vi arbeidet med PA, disse er satt opp i neste del. 3. Notater gjort under testing av PA 21 og 22 november Noen av kommentarene under del 3 er preget av at testgruppen som representanter for brukerne ønsker enkle, intuitive og konsistente menyer og valgmuligheter når verktøyet skal brukes. Vi setter høye krav til dette under testing. Og siden ingen av oss har brukt PA-verktøyet før burde det ikke være noen problem for oss å føle oss som den typiske bruker på UiO. 3.1 Registrering av prosjekt: Generell kommentar til denne del er at vi er usikker på hva beskriver når den omtaler registrering av prosjekt. Er det for å få tildelt prosjektnummer eller er det for etablering av et prosjektbudsjett (eller andre formål)? 1. Tungvint let etter parametre for innlegging i de ulike feltene, eks prosjektledernavn, institutt og lignende. Dette er kanskje bare et midlertidig problem i pilotutgaven. 2. Ikke naturlig at stedkoden må stå først og inkludert i navnet til prosjektenhet. Kan det stå bak tekstfeltet? Dette er dog et mindre ankepunkt. 3. Kundelisten er pt ikke tydelig nok på å definere hvilke kunder som gir hvilke prosjekttyper. Vi må her f.eks vite hvilken NFR-kundenr som følger hvilke prosjekttyper, eks. bidrag/oppdrag/bfv/efv. Med den tekst som fremkommer når du åpner valgvinduet forteller det ikke nok om hvilken (kunde) finansiør som er riktig. Vi trenger et slags merknadsfelt for den enkelte kunden som viser den nødvendige info (dvs et munimum av info tilsvarende det som står beskrevt på nettsidene som forklarer hovedgrupper av finansiører).

15 4. Et spørsmål dukket opp vedrørende ROLLE-beskrivelser: hvem skal gjøre prosjektetablering. Prosjektleder, prosjektøkonom, fakultets prosjektkontroller eller annen sentralt plassert person. Kontroll med prosjektoppretting er viktig for rett klassifisering av finansiør i rett prosjektgruppe (BFVvs EFV og bidrag vs oppdrag) og kundevalg. 5. Første forsøket på prosjekteopprettelse gikk galt da vi på et gitt tidspunkt ikke klarte å komme oss tilbake til det prosjekt vi jobbet med å etablere. Ved forsøk nr. 2 gikk vi oss vill når vi skulle opprette et helt nytt prosjekt. Dette indikerer flere mulige mangler ved PA: Først og fremst er det er for mange uklare menyer og alternative valgmuligheter som gjør at en uerfaren bruker lett blir forvirret og mister tråden. Det burde vurderes hvorvidt en kan slå av menyer, valgvinduer og valgknapper i PA. 6. Punkt 5 forteller oss også at brukermanualene må inneholde en beskrivelse av de ulike menyene som til enhver tid eksisterer i PA. Til enhver tid er det minst 3 ulike menysystemer/menylinjer å velge imellom. Ulike menysystemer i PA har ulike måter å navigere på. I noen kan du rygge i, andre ikke. En ny bruker trenger å forstå systematikken i dette. 7. Generelt hva er forskjellen på å etablere et prosjekt og det å registrere et prosjekt. Og er en kalkyle eller et budsjett nødvendig for å etablere/registrerer/opprette et budsjett? 3.2 Budsjettregistrering: 1. Hovedoverskriftene står på engelsk, project, controll med mer. Budsjett legges inn under en fane som heter Financial. Dette er ikke intuitivt og må rettes til norske begreper som er mer innlysende. 2. Gå til bruk og -valgmenyen er et annet usikkerhetsmoment når en leser brykermanualen. Hvordan vet bruker at han skal gå ned til høyre i feltet og finne undermeny der? Og det er to like felt som heter Gå til bruk og.. Oppe og nede til høyre i dette skjermvinduet. Her bør en stramme opp det aktuelle skjermbildet. 3. Huske noen steder i brukermanualen å angi at vi må rulle i vindu for å kunne se alle alternativene. Dette møte vi f.eks når vi skulle angi periodeprofil. 4. Hva er forskjell på direkte og total kostnad? En viktig konseptuelt avklaring til begrepene og bruken av disse i PA. Og hvilke følger får vi ved å endre valg her i PA? 5. Også for budsjettregistrering lett å gå vill, vi valgte feil versjon og kom ikke tilbake til siden som viste hvor vi kunne velge mellom versjonene. Og hva er den konseptuelle forskjellen på plan- og budsjettversjon? Litt for mange valgmuligheter gjør at det blir uoversiktlig og lett å ta feile valg. 6. Ikke intuitivt å vite at Rediger -knappen gir tilgang til å legge ny budsjettlinje inn når vi holder på å registrere budsjettlinjer, og som derpå åpner for å budsjettere inntekter, lønn og kostnader. 7. Er det slik at vi ALLTID må ha en AKTIVITET (dvs finansiør av en aktivitet) i prosjektet, og ikke en versjon eller kalkyle? Det burde for enkelthets skyld være slik at for de enkle NFR-prosjektene med bare èn finansiør så kom det automatisk opp et alternativ med bare èn aktivitet. NFR-prosjektene står for brorparten av prosjektporteføljen og det burde være enklere enn i nåværende versjon av PA å registrere slike prosjekter, 8. Ikke intuitivt at vi må lagre før vi får oppdatert endringene i budsjettet (pris, mengde). Hvorfor ingen KALKULER-knapp spurte vi oss, det er et mer naturlig ord/valg? 9. Hva er fleksifeltknappen for noe? Vi fant det ut etter en stund, brukermanual må dog forbedres. 10. Søkefunksjonene på deler av de små valgvinduene i budsjettregistreringe fungerer ikke alltid og feiler med å finne verdier som vi skal velge mellom.

16 11. Vi forsøkte å søke på tidligere lagret navn på budsjettversjon, uten suksess. Fikk den ikke opp slik at vi kunne bygge på den til endelig budsjett. 12. Da vi skulle overføre kalkulert budsjett/søknadsbudsjett til endelig budsjett fikk vi dette ikke til. Vi er ikke sikker på om det er en systemfeil eller brukermanualen som svikter her, uansett må dette forbedres. Vi endte med å måtte lag nytt endelig budsjett fra grunnen av for å få et endelig budsjett lagret i systemet. 3.3 Dag 2- Forsøk med endelig budsjett og oppretting av budsjettet: 1. Vi ønsker at det også må merkes av for startdato, ikke bare måned og år i valgvindu for oppstartsdato. 2. Hva innebærer alternativet med å opprette fra prosjekt? Og hva er forskjellen på det å opprette fra mal? Hente opp prosjektkladd, kategorisering, indirekte kostnader med mer? 3. Opprett likeverdig begreper må erstattes av et mer naturlig og dekkende begrep. Hva er det for noe? Trenger en å åpne flere aktiviteter når en har angitt en kunde som bare er enefinansiør. Type enkelt NFR-prosjekt. 4. Opprett underordnet aktivitet når skal dette brukes? Type INGAP der flere finansiører samfinansierer en aktivitet i et superprosjekt? 5. Hvordan komme fra formsutgaven til webutgaven var et problem for oss. Vi fant ut av det etter hvert etter en del frem og tilbake. Må f.eks slik av/pålogging gjøres i den endelige PA-utgaven? Her må brukermanualen utbedres til å vise enklere hvordan dette gjøres smartere en å logge seg helt av. 3.4 Opprette Kunde. 1. Hvorfor dette ekstravalg når vi allerede har angitt NFR som kunde under oppretting. Er dette en nødvendighet eller en options? 3.5 Opprett budsjett (endelig, ikke hentet fra kalkyle). 2. Hva betyr budsjettdetaljeringsgrad? Noe bedre dekkende begrep? 3. Hva er forskjellen på HB-periode og PA-periode? 4. Hva betyr å rapportere på direkte eller total kostnad? 5. Budsjettversjoner oppstår lett i flere nye utgaver fordi systemet er tregt og vi trykket flere ganger på opprettknappen. Det burde komme opp et spm om bruker virkelig ønsker å opprette en ny versjon. Og hvordan slettes overflødige versjoner? Kanskje burde brukermanual angi at en tar seg god tid på dette punktet fordi systemet trenger litt arbeidstid? 6. Under denne delen av arbeidet så vi igjen at budsjettet inneholdt flere begreper som vi ble usikre på. Tidligere har vi spurt oss forskjellen på direkte og total kostnad. Og hvordan beregnes de beløpene som fremkommer i inntektsfeltet. Hva betyr det at det kommer opp et beløp i inntektssegmentet før vi har lagt inn hva finnasiør faktisk skal bidra med? Hvordan jamnføre disse inntektsberegningene med tall fra Per Heitmanns budsjettmaler. En uerfaren bruker vil f.eks spørres seg om beløpet inntektsbeløpet som fremkommer for postdok. Vi vet at Inntekt for postdok henter opp NFRs rundsummer. Men er det innlysende for andre?

17 7. På linjen for indirekte kostnader kommer det opp et beløp i feltet for direkte kostnader. Dette er ikke logisk i forhold til begrepsbruk, Enten nytt felt eller annen tekst til feltet. 8. I motsetning til i brukermanualen får vi ikke opp noe felt for gjenomsnittlige fakturapris i budsjettvinduet. 9. Etter at vi la inn budsjettlinje for indirekte kostnader la PA påslag på lønn med ca 38 %. Hva er dette påslaget? 10. Hvordan er det mulig å budsjettere per måned? Ligger ingen slike egenskaper inne i dette nå. Regnskapsrapportene til prosjektleder gir kun relevant info èn gang i året, dvs ved årsavslutning. 11. FEILMELDING: Systemet forholder seg til kalenderår (3 år) og ikke prosjektår. Vi opprettet et prosjekt som startet 1 mars. Dette betyr at i prosjektets siste kalennderår er det kun i drift i januar og februar. Feilen medfører månedene jan + febr forsvinner i posjektoversikten. Kostnadene for disse månedene blir i PA automatisk fordelt på de tidligere årene, og tilsvarende med den kalkulerte inntekten for indirekte kostnader. Dette må korrigeres! 12. Å endre eller forlenge sluttdato fant vi ikke helt ut av. (NB. Vi forsøkte å endre oppstarts og avslutningsdatoene til tidligere dato. Fikk da feilmelding om at alle tilhørende aktivitetsdatoer måtte endres). En må altså også gå inn på inntektsføring og endre dato for avtalebeløp og lignende. Tungvint. Sluttdatoen må slik vi fant det korrigeres flere steder i PA. Siden en stor andel prosjekter endrer sluttdato er dette en rutine som vil bli mye brukt. Rutinen bør om mulig gjøres enklere eller brukermanual tydeligere. 13. En må både lagre og sende det endelige prosjektbudsjettet. Tungvint. 3 Legge inn avtalebeløp fra finansiør: Her brukte vi word-brukermanual for Inntektsføring da vi antok dette omtaler å legge inn avtalebeløp. Men er et korrekt? 1. Her startet brukermanualen med å lede oss inn i forms -delen av PA. Denne delen har en annen layout og annet menysystem (rubrikkbasert, ikke windowsbasert). Dette betyr enda en ny måte å bruke PA på for brukerne. Men så vidt vi har skjønt så finnes det ingen windowsversjon for denne delen av arbeidsoppgavene i PA. 2. Denne delen er tydelig det vi skulle ha gjort først, før prosjektregistrering. Men denne del kan ikke gjøres før du har opprettet prosjektet i webdelen. På den annen side stopper webdelen når vi kommer til knappen basisbudsjettering fordi vi ikke har lagt inn avtalebeløpet. Den overordnete prosessen må beskrives bedre i brukermanualen. Forøvrig syntes vi dette er en tungvint prosess å gå igjennom. 3. Hva skjer når vi trykker på knappen for basisbudsjettering? 4. Hva betyr det å generere inntektsutkast? Del 2,1 5. Manualen ber om å gå til prosessforespørsel uten å nevne at dette valgalternativ ligger i rullegardinmeny øverst i vinduet, utenfor de andre vinduene. 6. Manualen inneholder faktisk ingen beskrivelse på hvordan legge inn avtalebeløp, se dog rollebeskrivelsen som angir vindu. Hvis dette er riktig må brukermanualen skrives kraftig om. 7. Hva er forskjellen i begreper som inntektsføring, fakturering og avtalebeløp (hvis den siste finnes)? 8. Godkjenning av prosjekt til OK- status. Ligger under Oppsett, det er ikke intuitivt for nye/mindre erfarne brukere, her må heading endres fra Oppsett til noen mer dekkende begrep. 3.7 Testing av regnskapsførsel underveis i prosjektets livsløp.

18 Brukergruppen ønsket videre å få testet systemet i prosjekteets livsløp for å se på brukervennlighet fra prosjektkonsulentens ståsted og rapport- og informasjonskvaliteter fra prosjektkonsulent og eiers ståsted. Dette er dog ikke mulig inntil videre av flere grunner: a) Inntekter ikke mulig for oss å legge inn (rutine+brukerrettigheter) b) Kostnader ikke mulig for oss å legge inn (rutine+brukerrettigheter) c) Timeregistrering ei heller mulig (av samme grunn som over). En kan velge å legge denne delen til selve pilottestingen, men da risikerer en å miste verdifull til i den fasen siden det også her helt sikkert må gjøres endringer inen disse deler av systemet (rapporter med mer) før en får en pilotversjon som testbar. 3.8 Noen konklusjoner av det utførte testarbeidet. Målsettinger indikert av Simen J: Kvalitetssikre prosjekttmaler, herunder test av finansiørs rapporteringskrav. Ikke utført. Fikk testet NFR-malen, men på meget tynt grunnlag, ref til de spørsmål som er omtalt over. Vurdere ressursbruk. Ikke utført. Men da PA er et tungt verktøy er det ingen tvil om at personalressursene må økes for å kunne utføre de omtalte prosessene. Det bør vurderes hva som skal utføres i PA, der så mye som mulig bør ligge utenom. Eks søknadsbudsjettering. Vurdere opplæringsbehov og brukerstøtte Ikke utført. Men allerede nå er klart for oss at det trengs en grundig opplæring for alle som skal bruke systemet og at det dessuten må foreligge en god brukerstøtte. Vurdere organisering og driftsregime Ikke utført, bør gjøres sammen med ØPA og prosjektgruppen. Se på rollefordelingen på lokalt nivå, dvs fra fakultetsnivået og nedover. Inkludere roller som prosjektleder, prosjekteier, prosjektøkonom, prosjektsekretær mm Ikke utført. Den lokale testgruppens målsettinger: Se på verktøyet både som økonomikonsulent og prosjektleder. Vurdert, men kun på et overordnet nivå. Kan først gjøres grundig når vi får inn transaksjoner og flere regnskapsperioder inn i prosjekt. Brukervennlighet: i form av lett å bruke for nye brukere, lettfattelige menyer/tekster på de ulike menyvinduene, standardoperasjoner skal ikke være tidkrevende, enkelt å ta ut de mest sentrale data for et prosjekt og forståelige standardrapporter i OA.

19 Vurdert på et overordnet nivå. Men testingen i denne runden viser at vi har et langt stykke igjen til vi kan presentere et verktøy som er forståelig og overkommelig for brukerne Vurdere økonomidelen i prosjektregnskapet: Brukergruppen mener det er en svakhet ved systemet at en ikke kan budsjettere per måned. Nå har modellen kun budsjettering over flere år, mens innen det enkelte budsjettår blir kostnadene (og tilhørende inntektsopptjening) fordelt jevnt over årets måneder. Det gir dårlig periodiserte budsjetter og ditto svake rapporter mht over/underforbruk gjennom året på drift, investering og lønn). Ellers må mer testing til her, med transaksjoner og multiple regnskapsperioder. Vi erindrer at Oracle har opplyst at det går an å legge inn kurver for budsjettfordeling, men det er uklart hvordan dette vil fungere. Ressursbruk på rollene: det må være mulig å definere presist hvilke roller som skal ligge inne i de ulike arbeidsprosessene og en må om nødvendig kunne fordele arbeidsoppgavene på 3 nivåer (sentralt-fakultet-institutt). Spesielt viktig å se på hvordan timeregistrering skal skje og hvilke roller (hvem/nivå) som ligger til det arbeidet. Ikke utført, bortsett fra at vi ser mer personalressurser må tilføres. Rapportløsninger utenom OA: på et senere stadium må vi se på hvilke rapporter som må settes opp for å gi god info til involverte parter/interessenter. Ikke utført.

20 VEDLEGG 3: OPPSETT AV ORACLE PROJECTS LØSNINGEN VED UiO 1. IMPLEMENTERING AV PILOT VED UIO 1.1 Overordnet beskrivelse av pilotimplementering Oracle ønsker å tilby UiO en pilotimplementering av Oracle Projects slik at løsningen kan prøves ut for et begrenset antall prosjekter. Pilotimplementeringen vil bestå av funksjonaliteten som er implementert ved UiB med noen tillegg. Nedenunder er hovedpunktene som vil inngå i pilotløsningen for UiO nærmere beskrevet. Omfanget av og hovedpunktene for pilotprosjektet ble diskutert i et eget møte mellom UiO og Oracle fredag 16. mars Konkretiseringer fra dette møtet er nærmere beskrevet under relevante punkter nedenunder. Nødvendige avklaringer for registrering av et minimum av grunndata som kreves for en konferanseromspilot, vil bli fortløpende avklart i egne arbeidsmøter mellom UiO og Oracle. UiB Løsning omfatter i korte trekk følgende: 1. Ansattgrensesnitt mot Sebra. Dette grensesnittet kopierer ansattedata fra Sebra til Oracle Human Resources. Dette er data som er nødvendige for at det skal kunne registreres timer mot ansatte, ansatte skal kunne knyttes mot prosjekter m.m. Ansatte knyttes i Oracle Applications blant annet mot jobb/stilling i HR, samt mot en kostrate definert for ansatt/stilling. For UiO kan det være ønskelig å benytte kostrate med utgangspunkt i ansattes plassering i lønnsregulativ og forskningskategori. Cerebrum er det systemet som er master for registrering av ansatteopplysninger i UiO. Ved implementering av Oracle Projects er det 3 mulige måter for registrering av ansatteopplysninger i Oracle Applications: 1. Manuell registrering av ansatteopplysninger. 2. Registrering av ansatteopplysninger ved bruk av Dataload; basert på utfylt excelmal fra UiO med ansatteopplysninger. 3. Grensesnitt mot mastersystemet Cerbum for overføring av data for nyansatte, samt oppdatering av opplysninger på eksisterende ansatte. I pilotprosjektet skal det benyttes et begrenset antall ansatte og disse vil bli registrert inn manuelt i Oracle Applications. 2. Prosjektregistrering med angivelse av om det er søknad eller godkjent prosjekt, samt registrering av kontrakt med oppdragsgiver. Registrering av et prosjekt innebærer å fylle ut nøkkelinformasjon som prosjektleder, oppdragsgiver etc. i med utgangspunkt i en forhåndsdefinert prosjektmal. Dette gjøres i forbindelse med søknad om å få opprettet et nytt prosjekt. I tillegg opprettes det i forbindelse med søknaden en kalkyle hvor man kan legge inn budsjettdata for antall timer, kostnader og inntekter. Status på prosjekt endres til Søknad sendt etter at søknad er sendt til finansieringskilden. Avhengig av om søknaden blir innvilget eller ikke, oppdateres statusen til Søknad godkjent eller Avvist. Etablering av godkjente prosjekter starter, etter at kontrakt av oppdragsgiver er mottatt og signert. Etter at ulike grunndata/prosjektklassifiseringer og nøkkeldeltakere er definert, registreres finansieringkilder og