BILAG 1 KRAVSPECIFIKATION ØKONOMISYSTEM

Transkript

1 BILAG 1 KRAVSPECIFIKATION ØKONOMISYSTEM

2 VEJLEDNING Denne kravspecifikation er en del af kravspecifikationen af økonomi. Den samlede kravspecifikation for økonomi udgøres af: Bilag 1 kravspecifikation A (fælles) Bilag 1 kravspecifikation C (økonomi) Denne del af den samlede kravspecifikation beskriver de forhold som er specifikke økonomi. Denne kravspecifikation beskriver opgaver, processer og arbejdsgange, som skal håndteres ved hjælp af kommunens fremtidige løsning. Dokumentet indeholder dels en række generelle forhold og ikke-funktionelle krav, dels en beskrivelse af et antal procesområder, som varetages hos kunden. Tilbudsgiver skal i løsningsbeskrivelsen redegøre detaljeret for sine og den tilbudte løsnings forudsætninger vedrørende de nævnte generelle forhold og forventninger samt ikke-funktionelle krav. Tilbudsgiver skal endvidere i løsningsbeskrivelsen redegøre detaljeret for, hvorledes den tilbudte løsning kan anvendes til at løse de opgaver og arbejdsgange som er beskrevet i kravspecifikationen. Tilbudsgiver skal tilstræbe et detaljeringsniveau, som muliggør, at kunden ved gennemgang af løsningsbeskrivelsen kan danne sig et indtryk af den tilbudte løsnings egnethed til at understøtte de beskrevne processer og arbejdsgange samt løsningen af de beskrevne opgaver.

3 INDHOLD 1. Indledning Generelt Procescases 1 2. Kunden 2 3. Udbuddets omfang 3 4. Generelle krav til tilbuddet Basiskrav Hovedtidsplan Projektledelse Opsætning og konfigurering Konvertering (option) Implementeringsbistand Test Uddannelse (option) Dokumentation Dokumentation af analysefasen Dokumentation af løsningen Brugersupport Udviklingsplaner Projektmodel Bemanding Involvering af kundens medarbejdere Kundens udviklingsprojekter Læseadgang historiske data (option) 9 5. Generelle krav til løsningen Forventninger til leverandøren Lovmæssige krav Åbne standarder Krav vedrørende økonomistyring for selvstændige virksomheder Brugervenlighed og fleksibilitet Forhold vedr. it-arkitektur, integration m.v Brugeradministration Integration i forhold til økonomisystemet 12

4 5.6.3 It-sikkerhed It-arkivering Data til ledelsesinformationssystem (option) Dataudtræk Metadata og søgbarhed Programmering af batchjobs Krav til driftsplaner Svartider, oppetider mv Beskrivelse af opgaveområder og processer Debitor Ressourcestyring Anlægsstyring og anlægsregnskab Indkøb Økonomi og regnskab, herunder årsregnskab, omkostningsregnskab Likviditetsstyring Økonomi og budget Kontoplan Betaling (bank, giro og kasse) Rapportering og analyse 40 Appendiks Appendiks C1: tidsplan

5 1. INDLEDNING 1.1 Generelt Denne del af det samlede udbud omfatter udbud af kundens økonomisystem. Dette dokument udgør den specifikke del af kravspecifikationen for udbuddet, som samlet udgøres af: Bilag 1 kravspecifikation A (fælles) Bilag 1 kravspecifikation C (økonomi) Kravspecifikationen er struktureret således, at der i starten af kapitlerne er en generel beskrivelse, hvor det er relevant. Herefter følger de specifikke krav til hvert område. Den generelle beskrivelse er ment som en baggrundsbeskrivelse, som de efterfølgende krav skal opfylde. Kravene er nummereret Krav nn og Tilbud nn, hvor Krav nn er udtryk for et krav til systemet/løsningen, og hvor Tilbud nn er udtryk for et krav til tilbuddet. Det er ud for kravene anført, hvilke krav der er mindstekrav. 1.2 Procescases Der er gjort brug af procescases til at specificere en række krav. En procescase er en struktureret tekst, som beskriver et forretningsområde eller en forretningsproces og dens krav til itunderstøttelse. Procescasene er overordnede af karakter og er udarbejdet for relevante, centrale forretningsprocesser. En procescase består af: Navn for processen Formål og overordne krav Beskrivelse af forretningsprocessen og dens kritiske processer Specifikke krav til it-løsningen Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen Procescases er ikke beskrevet i detaljer. Der er i tidsplanen indlagt en analyse- og designfase efter valget af leverandør, bl.a. med det formål at arbejde videre med og fylde detaljer i disse procescases. Det forventes, at leverandøren aktivt forholder sig til procescasene og tilbyder en løsning, der understøtter og sikrer en opfyldelse af de angivne procescases. BILAG 1 C - KRAVSPECIFIKATION SIDE 1

6 2. KUNDEN Kundens organisation er kendetegnet ved en høj grad af decentralisering. Opgaveområderne omfattet af kravspecifikationen løses således både i centrale og decentrale organisatoriske enheder. For alle brugeres vedkommende anvendes i forbindelse med den eksisterende økonomiløsning en portaladgang. Kunden anslår antallet af brugere på den nuværende økonomiløsning til at være som følger: Kategorier Brugere Administratorer Ca Superbrugere Ca Brugere* Ca. 800 (i alt) Portalbrugere Ca. 250 Indeholdt i ovenstående Brugere af indkøbsløsning Ca Brugere af ressourcestyring Ca Krav 1. Leverandøren skal afgive tilbud med udgangspunkt i det nuværende antal brugere. BILAG 1 C - KRAVSPEFICIKATION SIDE 2

7 3. UDBUDDETS OMFANG Opgaven omfatter anskaffelse, drift og vedligeholdelse af et standard økonomisystem. Det er i Bilag 1 kravspecifikation A (fælles) angivet hvilke it-løsninger kunden benytter til at løse opgaver inden for økonomi, og hvilke systemer der i dag eksisterer integrationer til. Krav 2. Udgangspunktet for nærværende udbud er alene at forbedre systemunderstøttelsen inden for de områder, der i dag systemunderstøttes. Det er derfor ikke hensigten at udvide systemunderstøttelsen til at dække nye områder, udover hvad der afspejles af kravspecifikationens procescases. BILAG 1 C - KRAVSPEFICIKATION SIDE 3

8 4. GENERELLE KRAV TIL TILBUDDET Opgaven omfatter anskaffelse, drift og vedligeholdelse af et standard økonomisystem. Systemet skal understøtte de krav, som en kommunal virksomhed som kunde bør stille til en tidssvarende økonomiløsning. Tilbud på læseadgang til historiske data, uddannelse, konvertering af data samt data til ledelsesinformation skal medtages som optioner. Hermed forstås, at leverandørens tilbud inden for disse områder skal prissættes separat, således kunden har mulighed for at fravælge områderne. 4.1 Basiskrav Krav 3. Krav 4. Krav 5. Tilbud 1. Det er et krav, at leverandøren skal levere et økonomisystem baseret på et standardsystem. Det er et krav, at løsningen i så høj grad som muligt anvender systemets standardfunktionalitet, og at der kun i begrænset omfang foretages tilretninger og specialudvikling. Det er et krav, at løsningen er integreret datamæssigt, således at ændringer og inddateringer slår øjeblikkeligt igennem i hele systemet Leverandøren skal i underbilag til bilag 2 med udgangspunkt i den i Bilag 1 kravspecifikation A (fælles) beskrivelse af de nuværende systemer og deres indbyrdes sammenhæng angive, hvilke systemer kunden fortsat skal gøre brug af. 4.2 Hovedtidsplan Krav 6. Det er et krav, at det nye økonomisystem den 15. oktober 2011 skal være klar til indberetning af budgettet for Den 1. december 2011 skal økonomisystemet være klar til at varetage samtlige opgaver af hensyn til håndtering af forsupplementsperioden. Den 1. januar 2012 skal økonomisystemet være klar til drift i hele kommunen (mindstekrav). Tilbuddet skal indeholde en analyse- og designfase, som igangsættes efter valget af leverandør. I denne fase skal løsningsbeskrivelsen viderebearbejdes i form af en endelig løsningsbeskrivelse. Tilbud 2. Tilbud 3. Tilbud 4. Leverandøren skal med udgangspunkt i ovenstående angive en hovedtidsplan med relevante aktiviteter til gennemførelse af projektet. Hovedtidsplanen angives i bilag 5. Leverandøren skal i bilag 3 angive og beskrive de relevante aktiviteter til gennemførelse af projektets analyse- og designfase. Leverandøren skal i bilag 3 redegøre for projektforløbet som helhed, herunder for relevante aktiviteter til implementering af løsningen. Følgende aktiviteter skal som minimum beskrives: Projektledelse Opsætning og konfigurering Konvertering (option) Implementeringsbistand Testplanlægning og afprøvning BILAG 1 C - KRAVSPEFICIKATION SIDE 4

9 4.3 Projektledelse Uddannelse (option) Leverandøren har det totale projektledelsesansvar for alle dele af leverancen samt for overholdelsen af tidsplanen. Leverandørens projektleder har også initiativpligt over for aktiviteter, der skal gennemføres af kunden. Leverandørens projektleder skal arbejde tæt sammen med kundens projektansvarlige. Tids- og projektplanerne skal omfatte planlægningsaktiviteter, der kan sikre systematik og sammenhæng samt god fælles forståelse af de aktuelt forestående aktiviteter. Krav 7. Det er et krav, at tilbuddet medtager samtlige den til gennemførelsen af projektet nødvendige projektledelse fra leverandørens side (mindstekrav). 4.4 Opsætning og konfigurering Krav 8. Det er et krav, at leverancen skal omfatte den til gennemførelsen af projektet nødvendige bistand fra leverandørens side til opsætning og konfigurering af løsningen (mindstekrav). 4.5 Konvertering (option) Kunden ønsker at sikre en så let overgang til det nye system som muligt. Data ønskes konverteret, således at eksisterende data tilbage til 1/ bliver tilgængelige i det nye system. Krav 9. Tilbud 5. Krav 10. Tilbud 6. Det er et krav, at leverandøren i tilbuddet medtager forslag til konvertering af data eller alternativt anden lagring af historiske data. Der kan tilbydes alternative konverteringsforslag. I det omfang datakonvertering forudsætter involvering af tredjepart, skal dette angives. Leverandøren skal i bilag 13 medtage konverteringen som option, og den konkrete konverteringsopgave fastlægges som en del af analyse- og designfasen. Data, der ikke kan konverteres og gøres tilgængelige i det tilbudte system, skal på anden vis gøres tilgængelige og søgbare i hele kontraktperioden. Leverandøren skal i underbilag til bilag 2 beskrive, hvorledes ikke konverterede data gøres tilgængelige. 4.6 Implementeringsbistand Leverancen skal omfatte den nødvendige bistand til en succesfuld implementering og ibrugtagning af systemet, bl.a. i forhold til den initiale systemopsætning, tilrettelæggelse af arbejdsgange, implementering af snitflader til de tilgrænsende systemer mv. Krav 11. Det er et krav, at tilbuddet medtager samtlige den til gennemførelsen af projektet nødvendige implementeringsbistand fra leverandørens side (mindstekrav). 4.7 Test Som en del af den samlede projektplan skal der udarbejdes en detaljeret testplan, som sikrer, at der sker en grundig afprøvning. Det forventes, at afprøvningen bl.a. omfatter en brugerafprøvning, BILAG 1 C - KRAVSPEFICIKATION SIDE 5

10 hvor repræsentanter fra kommunen deltager i arbejdet med at teste den samlede systemfunktionalitet. Krav 12. Det er et krav, at leverancen omfatter alle ydelser fra leverandørens side, der er nødvendige for realisering af testplanen, herunder også deltagelse i samtlige kontraktmæssigt fastsatte afprøvninger af systemet. 4.8 Uddannelse (option) Leverandøren skal kunne levere al brugeruddannelse, herunder uddannelse af systemadministratorer, superbrugere og brugere. Leverandøren skal ligeledes kunne levere det nødvendige uddannelsesmateriale. Kunden ønsker den størst mulige fleksibilitet i forhold til uddannelse af brugere, både i forhold til uddannelsens omfang og i forhold til den konkrete tilrettelæggelse. Uddannelse skal være indeholdt i tilbuddet. Uddannelse af brugere medtages som option, og det konkrete uddannelsesforløb aftales som en del af analyse- og designfasen. Krav 13. Krav 14. Leverandøren skal tilbyde uddannelse af kundens brugere i hele kontraktperioden. Leverandøren skal, som en del af tilbuddet, tilbyde uddannelse af følgende økonomi, debitor og indkøbsmedarbejdere: Administratorer (ca økonomisystemadministratorer): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne forestå de opgaver, der relaterer sig til at være administrator af systemet. Superbrugere (ca økonomi- og debitorkonsulenter): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne vejlede øvrige brugere og klæde superbrugerne på til at løse komplekse fagspecifikke problemer samt de basale elementer i brugerhåndtering. Uddannelsen skal give en udførlig indføring i anvendelse af økonomisystemet. Brugere (ca. 800 brugere): Uddannelsen skal være på et tilstrækkeligt niveau, der sikrer, at de kan anvende systemet i daglig brug. Der ønskes en målrettet uddannelse efter forskellige roller eller kompetenceprofiler, og forslag til roller/profiler ønskes omfattet af optionen. Decentrale, lette økonomibrugere (ca. 250 lette brugere): Uddannelsen skal sikre, at de lette brugere kan anvise og foretage lettere forespørgsler Indkøbsbrugere (ca lette brugere): Uddannelsen skal sikre, at brugerne er fortrolige med løsningen og kan foretage alle nødvendige delelementer af elektroniske indkøb. Lette ressourcestyringsbrugere (ca lette brugere): Uddannelsen skal sikre, at de lette brugere af ressourcestyrings kan udføre opgaver tilsvarende dem, som i dag udføres via webportal, primært timeregistrering Krav 15. Uddannelsen af administratorer og superbrugere skal være af ensartet kvalitet, og skal derfor forestås af leverandøren. Leverandøren skal i optionen give forslag til anvendelse af superbrugere i undervisningen af de øvrige brugere i kommunen. Leve- BILAG 1 C - KRAVSPEFICIKATION SIDE 6

11 randøren kan i undervisningen suppleres af en specialist fra kunden til at sikre den bedst mulige kobling mellem kommunens opgaveløsning og økonomisystemets muligheder, eller superbrugere kan efter undervisningen fra leverandøren - varetage den efterfølgende træning af brugerne i den daglige opgaveløsning. Krav 16. Uddannelsen af superbrugere og brugere skal foregå hos kunden, der stiller lokaler og udstyr til rådighed. Krav 17. Uddannelsen af superbrugere og brugere skal tilrettelægges, så kundens særlige forhold, konfiguration og arbejdsprocesser indgår. Krav 18. Uddannelsen af superbrugere og brugere koordineres tidsmæssigt med implementeringsforløbet, således at uddannelse i brugen af økonomisystemets moduler er koordineret med implementeringen af disse, så medarbejderne er parate til at løse opgaverne i den nye løsning på tidspunktet for dennes driftsstart. Tilbud 7. Leverandøren skal i bilag 3 afgive 3 alternative tilbud på uddannelsesaktiviteterne af brugerne - Det minimale uddannelsesforløb - Den anbefalede uddannelsesforløb - Den maksimale uddannelsesforløb. 4.9 Dokumentation Der skal leveres fuld dokumentation til det samlede system, rettet mod slutbrugerne. Dokumentationen skal løbende vedligeholdes i hele kontraktperioden (vedligeholdelsesaftalen). Dokumentationen bør foreligge i et ajourført, online, søgbart format Dokumentation af analysefasen Som en del implementeringen skal leverandøren gennemføre en analyse- og designfase, der skal give leverandøren den fornødne viden til udarbejdelse af den endelige løsningsbeskrivelse på baggrund af kravspecifikationen jf. kontraktens bestemmelser. Krav 19. Resultatet af analyse- og designfasen skal dokumenteres i en løsningsbeskrivelse, som vil indgå i kontraktens bilag 2 (mindstekrav) Dokumentation af løsningen Leverandøren skal som en del af løsningen levere: Brugerdokumentation (fx. manualer, online hjælp) Systemdokumentation (løsningsarkitektur, modulbeskrivelser, datamodel, opsætning) Vedligeholdelses- og driftsdokumentation (fx. installations- og system, fejlhåndtering) Kursusmateriale Krav 20. Krav 21. Al brugerrettet dokumentation skal foreligge på dansk. Tilbuddet skal omfatte tilstrækkeligt dokumentation til at understøtte brug af systemet. BILAG 1 C - KRAVSPEFICIKATION SIDE 7

12 Krav 22. Dokumentation skal leveres samtidigt med programmellet og godkendes som en del af overtagelsesprøven. Tilbud 8. Leverandøren skal i underbilag til bilag 2 beskrive den dokumentation, som følger med løsningen Brugersupport Den generelle leverandørservice skal indeholde dansk brugersupport/helpdesk til support af kundens medarbejdere. Et begrænset antal brugere vil blive autoriserede til at henvende sig til brugersupporten. Tilbud 9. Leverandøren skal i bilag 10 beskrive omfanget og karakteren af den tilbudte brugersupport, samt beskrive eventuelle valgmuligheder for serviceniveau i forhold til brugersupport Udviklingsplaner Tilbud 10. Leverandøren skal i bilag 10 beskrive igangværende eller planlagte udviklingsplaner for det pågældende produkt, herunder aktuelle planer om nye versioner, moduler mv. Leverandør skal endvidere angive om dele af den tilbudte løsning vil blive erstattet af nye delløsninger i kontraktperioden (vedligeholdelsesperioden). Kunden ønsker mulighed for at kunne påvirke udviklingsplaner og fremtidige initiativer i forhold til den tilbudte løsning. Tilbud 11. Leverandøren skal i bilag 10 beskrive leverandørens arbejdsgange i forhold til opsamling af viden fra kunden og prioriteringer til udviklingsplaner og fremtidige initiativer, samt hvorledes kunden vil blive inddraget i dette arbejde Projektmodel Tilbud 12. Leverandøren skal i bilag 3 beskrive den projektmodel der tænkes anvendt i forbindelse med designfase og implementering af løsningen. Projektmodellen skal indeholde kundens roller og forventninger til disse, samt beskrivelse af kontaktsnitflader mellem kunde og leverandør Bemanding Tilbud 13. Leverandøren skal i bilag 11 beskrive, hvilken bemanding leverandøren vil allokere til hhv. analyse- og designfasen og til resten af projektet i form af navngivne konsulenter med tilhørende cv er. Leverandøren skal redegøre for, hvorledes kontinuitet og kvalitet i leverancen fastholdes ved medarbejderafgang i projekt- og kontraktperioden Involvering af kundens medarbejdere Tilbud 14. Leverandøren skal i bilag 6 beskrive, hvordan kundens medarbejdere bliver involveret i analyse- og designfasen, hvilke profiler, der efterspørges, og hvilket omfang involveringen har. BILAG 1 C - KRAVSPEFICIKATION SIDE 8

13 4.15 Kundens udviklingsprojekter Tilbud 15. Leverandøren skal i underbilag til bilag 2 beskrive, hvorledes leverandøren stiller sig i forhold til løbende at indgå i kundens udviklingsprojekter og mod vederlag at stille ressourcer og kompetencer til rådighed herfor Læseadgang historiske data (option) Ved udløb af denne kontrakt skal opgaven genudbydes. Det kan indebære, at kunden skal overdrage opgaven til en ny leverandør. Kunden ved af erfaring, at det er vanskeligt at konvertere data, hvorfor det kan være nødvendigt i en periode at opretholde en spørgeadgang til historiske data. Spørgeadgangen omfatter læseadgang herunder rapportadgang - til samtlige data i system et, som de forefindes ved kontraktens udløb. Spørgeadgangen skal foregå ved brug af det benyttede system eller et system med lignende spørgefunktionalitet. Tilbud 16. Leverandøren skal som option i bilag 13 angive prisen pr. måned for at opretholde spørgeadgangen til data i 5 år efter denne kontrakts udløb. Der angives en pris for 1. År samt én pris for de næste 4 år. Det forventes, at læseadgangen i år 1 skal omfatte ca. 250 licenser, mens læseadgangen i de resterende år skal omfatte ca.50 licenser. Priserne angives som en %-sats af det ved kontraktudløb gældende faste månedlige vederlag for brugsret, drift og vedligeholdelse. BILAG 1 C - KRAVSPEFICIKATION SIDE 9

14 5. GENERELLE KRAV TIL LØSNINGEN 5.1 Forventninger til leverandøren Kunden forventer, at leverandøren har et indgående kendskab til økonomiopgaver og økonomistyring i en dansk kommune, herunder de politiske og administrative processer som kendetegner kommunale økonomiforhold. 5.2 Lovmæssige krav Krav 23. Den tilbudte løsning skal i hele kontraktperioden opfylde og overholde og understøtte administrationen af al relevant lovgivning m.v. (mindstekrav), herunder: A. Lov om behandling af personoplysninger (Persondataloven) B. Datatilsynets sikkerhedskrav C. Arkiverings- og kassationsbestemmelser D. Forvaltningsloven E. Offentlighedsloven F. Styrelsesloven G. Bogføringsloven H. Lov om offentlige betalinger I. Budget- og regnskabssystemet ( den gule mappe ) J. Årsregnskabsloven Krav 24. Tilbud 17. Systemet skal på alle områder løbende være ajour med hensyn til gældende lov og regler (mindstekrav). Leverandøren skal i bilag 10 detaljeret redegøre for løsningens egnethed i forhold til at håndtere kommunens økonomiopgaver og økonomistyring under overholdelse af aktuel, relevante lovgivning. Leverandøren forventes i kontraktperioden at holde den tilbudte løsning funktionalitetsmæssigt opdateret i forhold til ændrede lovgivningsmæssige og reguleringsmæssige rammer. 5.3 Åbne standarder Kunden skal overholde gældende lovgivning omkring anvendelse af åbne standarder for software, hvorfor tilbuddet skal opfylde gældende krav. Tilbud 18. Leverandøren skal i underbilag til bilag 2 redegøre for systemets opfyldelse for hver af nedenstående standarder, herunder skal leverandøren i fald en eller flere standarder helt eller delvist ikke opfyldes, for disse standarder beskrive baggrunden for leverandørens fravalg af at anvende standarden i leverandørens system. Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) Standarder til elektronisk sags- og dokumenthåndtering (FESD) Standarder til elektroniske indkøb i det offentlige (OIOUBL) Standarder for digital signatur (OCES) Standarder for dokumentudveksling (ODF/OOXML) For yderligere information om obligatoriske, åbne standarder henvises til vejledning om anvendelse af obligatoriske, åbne standarder for software i det offentlige, som kan rekvireres på BILAG 1 C - KRAVSPEFICIKATION SIDE 10

15 5.4 Krav vedrørende økonomistyring for selvstændige virksomheder Den nuværende løsning benyttes til økonomistyring for et antal af kommunens samarbejdspartnere (fx selvejende institutioner), der har adgang til separate virksomhedsopsætninger, som dog ikke er integreret med økonomisystemet. Tilbud 19. Tilbud 20. Leverandøren skal i underbilag til bilag 2 redegøre for løsningens evne til at håndtere multiple, uafhængige virksomheder med egen kontoplan, bankkonti etc. Omkostningerne til at håndtere flere regnskaber skal være indregnet i prisen i bilag Brugervenlighed og fleksibilitet Det er vigtigt for kunden, at systemet er brugervenligt og intuitivt. Dette betyder også, at der skal være online hjælp fx. i form af elektroniske manualer/f1-assistance eller lignende, og det skal være muligt at bruge genvejstaster i stedet for mus. Disse støttefunktioner, manualer m.v. skal foreligge på dansk. Herudover bør systemet være fleksibelt, således at det er enkelt for kunden selv at foretage ændringer fx. i rapporter, kontoplan m.v. Krav 25. Krav 26. Krav 27. Det er et krav, at systemet skal være brugervenligt og fleksibelt i forhold til kundens fremtidige behov for justeringer og tilpasninger. Der ønskes et system med en intuitiv og letforståelig brugergrænseflade, som kan tilgodese behovene for brugere på mange forskellige niveauer af viden om systemet, og som reducerer behovet for oplæring til et minimum. Den enkelte bruger skal have mulighed for samtidig at have flere sessioner/skærmbilleder åbne af systemet samtidig. 5.6 Forhold vedr. it-arkitektur, integration m.v Der efterspørges et sammenhængende og fleksibelt standardsystem. Grænseflader (API er), protokoller og formater skal i størst muligt omfang være baseret på åbne standarder (de-facto og dejure) samt overholdelse af internet- og webstandarder. It-arkitektur- og softwareplatformen skal i størst mulig omfang være åben, fleksibel og velegnet til udvikling af nye funktioner. Tilbud 21. Tilbud 22. Tilbud 23. Tilbud 24. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens opbygning og modularitet, herunder den datamæssige integration og afhængigheder mellem eventuelle delmoduler og databaser. Leverandøren skal i underbilag til bilag 2 redegøre for hvilke eksterne grænseflader løsningen tilbyder. Leverandøren skal i underbilag til bilag 02 redegøre for hvilke delfunktionaliteter der umiddelbart kan gøres tilgængelige via webbrowser, og under hvilke forudsætninger dette kan ske. Leverandøren skal i underbilag til bilag 2 redegøre for, hvordan løsningen understøtter effektive arbejdsgange for decentralt placerede brugere med behov for adgang til relevante informationer med relation til arbejdet med økonomi og økonomistyring, herunder udtræk og forespørgsler. BILAG 1 C - KRAVSPEFICIKATION SIDE 11

16 5.6.1 Brugeradministration Af hensyn til bl.a. brugervenlighed er det for kunden vigtigt at adgang til systemet medfører brug af færrest mulige brugernavne og adgangskoder for den enkelte medarbejder. Kunden benytter i dag 4-tegns initialer som brugernavn, og ønsker at mulighed for valgfrit at kunne vælge brugernavne til løsningen. Samtidigt ønskes der mulighed for i løsningen at kunne dokumentere oplysninger omkring brugeradministration, fx hvilken leder der har bestilt en brugeroprettelse eller ændring af adgangsrettigheder eller hvornår seneste ændring er foretaget. Tilbud 25. Leverandøren skal i underbilag til bilag 2 redegøre for hvordan brugeradgang til løsningen fremstår for brugeren og hvordan den administreres. Det skal beskrives hvilke muligheder kunden har for frit at tildele brugernavne i løsningen, samt hvilke muligheder for dokumentation ifm. brugeradministration som løsningen tilbyder. Kunden ønsker på sigt at overgå til Single Sign-on vha. Active Directory, og ønsker derfor en løsning der understøtter dette. Tilbud 26. Leverandøren skal i underbilag til bilag 2 redegøre for i hvilken udstrækning løsningen kan integreres i en single sign-on-løsning vha. AD og hvilke krav løsningen evt. stiller i denne sammenhæng Integration i forhold til økonomisystemet Løsningen til økonomi skal understøtte den nødvendige datamæssige integration med en række øvrige it-løsninger, som leverer data til brug for lønberegning m.v. Det er i Bilag 1 kravspecifikation A (fælles) angivet hvilke systemer og interessenter, hvorfra der i dag er etableret dataintegration til den eksisterende løsning til løn- og personaleadministration samt vagtplanlægning. Kunden forventer desuden, at der kan være behov for yderligere snitflader. Tilbud 27. Krav 28. Leverandøren skal i underbilag til bilag 2 beskrive de for løsningen nødvendige snitflader hos 3. part for dataoverførsel til kundens øvrige systemer. Kunden forestår selv købet af snitfladerne. Det er et krav, at tilbuddet omfatter prisen på samtlige nødvendige interne snitflader i leverandørens egen løsning (både etablering og løbende drift) i den tilbudte løsning It-sikkerhed Løsningen skal indeholde sikkerhedsfunktionalitet, som opfylder Datatilsynets sikkerhedskrav. Tilbud 28. Tilbud 29. Leverandøren skal i underbilag til bilag 2 redegøre for, hvordan systemet og driftsmiljøet er sikret mod uautoriseret adgang fra tredjemand samt for, hvordan kommunen sikres mod diverse vira o.l., når økonomisystemet i øvrigt anvendes. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens logningsfunktionalitet, herunder overholdelse af krav til revisionsspor. BILAG 1 C - KRAVSPEFICIKATION SIDE 12

17 5.6.4 It-arkivering De tilbudte løsninger skal leve op til arkivlovens bestemmelser omkring elektronisk aflevering. I forhold til aflevering til et offentligt arkiv gælder det, at den efterspurgte løsning skal leve op til bestemmelserne i Arkivloven og Bekendtgørelse 342 af 11. marts 2004 eller den til enhver tid gældende bekendtgørelse. Krav 29. Leverandøren skal, som en del af den elektroniske aflevering af data, levere den tekniske dokumentation af systemet der afleveres ved afleveringsforhandling. Den tekniske dokumentation bør indeholde en tabeloversigt og et struktur-diagram. Der skal fra leverandørens side foreligge et tilbud der indeholder arkivering og fremstilling af en arkiveringsversion. (forudsætning om en årlig arkivering). 5.7 Data til ledelsesinformationssystem (option) Kunden ønsker direkte adgang til alle data registreret i løsningen (ned til mindste registrerede enhed, fx cpr-nr), således at disse kan indlæses i kundens eget ledelsesinformationssystem. Overførslen kan ske enten via en fremsendelse af fil fra leverandøren, eller ved adgang til leverandørens datawarehouse, hvorfra kunden selv indlæser data. Ad Fremsendelse af datafil (option) Data leveres via en månedlig fremsendelse af datafil til indlæsning i kundens ledelsesinformationssystem. Data leveres i et format således data automatisk kan indlæses af gængse løsninger til dataanalyse og datakonsolidering. Tilbud 30. Leverandøren skal i bilag 13 som option specifik angive det månedlige faste vederlag for levering af datafil. Den oplyste pris vil samtidig udgøre vederlagsreduktionen ved eventuelt bortfald af denne opgave. Ad Adgang til datawarehouse (option) Data stilles til rådighed via datawarehouse, således at kunden herfra kan læse data til eget ledelsesinformationssystem. Adgangen skal udformes således at data automatisk kan indlæses af gængse løsninger til dataanalyse og datakonsolidering. Overførsel af aktuelle data skal ske en gang pr måned. Tilbud 31. Leverandøren skal i bilag 13 som option specifik angive det månedlige faste vederlag for systemadgang til data i datawarehouse. Den oplyste pris vil samtidig udgøre vederlagsreduktionen ved eventuelt bortfald af denne opgave. 5.8 Dataudtræk Kunden benytter i den daglige produktion høj grad ad hoc dataudtræk fra systemet til økonomi. Anvendelsen og omfanget af disse data er meget varierende og skal understøttes på flere niveauer: Niveau 1: Kunden ønsker at kunne analysere alle data i løsningen via en specialiseret brugerflade, der leveres som en del af tilbudsgivers løsning. Niveau 2: Brugere kan vælge at udtrække valgte data, eller data behandlet i trin 2 til manuel eller maskinel behandling i andre systemer, herunder til gængse regnearks- og tekstbehandlingsformater. Niveau 3: Brugere kan opstille og gemme egne standardrapporter, eller redigere i foruddefinerede standardrapporter. Rapporterne skal kunne udskrives eller eksporteres jf. trin 2. BILAG 1 C - KRAVSPEFICIKATION SIDE 13

18 Tilbud 32. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til dataudtræk på de beskrevne niveauer, samt den tilbudte validitet og aktualitet af tilgængelige data inden for hvert af de 3 trin. Kunden ønsker fra regneark at kunne foretage direkte opslag og trække data (fx budgettal) fra Økonomisystem via forprogrammerede makroer. Tilsvarende makrobaseret funktionalitet benyttes til at tilbageinddatere de i regneark bearbejdede data til Økonomisystemet. Tilbud 33. Leverandøren skal i underbilag til bilag 2 redegøre for, hvorledes løsningen fra regneark håndterer direkte opslag og datatræk (fx budgettal) fra Økonomisystem via forprogrammerede makroer. Tilsvarende skal redegøres for den tilsvarende tilbageinddateringsfunktion. Kunden ønsker at sikre uafhængighed af enkelte systempakker, hvorfor dataudtræk i gængse regnearks- og tekstbehandlingsformater skal, indbefatte formater baseret på åbne standarder. Kunden benytter i dag Microsoft Office 2003, og løsningen skal understøtte formater der kan anvendes med denne programpakke, og alle senere versioner af Microsoft Office. Kunden ønsker mulighed for at kunne anvende Open Office, hvorfor den tilbudte løsning bør understøtte formater der kan anvendes med denne programpakke. Tilbud 34. Leverandøren skal i underbilag til bilag 2 redegøre for løsningens anvendelse af filtyper i forbindelse med dataudtræk, og hvorvidt disse opfylde ovenstående ønsker til understøttelse af nævnte kontorpakker. 5.9 Metadata og søgbarhed Kunden ønsker fortsat at kunne benytte den nuværende løsnings funktionalitet i forhold til at knytte ad hoc kommentarer til poster, herunder tilknytte filer. Denne funktionalitet har stor betydning i forhold til især decentrale brugeres anvendelse af økonomisystemet. Funktionaliteten ønskes anvendt til dokumentationsformål gennem tilknytning af originaldokumenter til poster. Tilbud 35. Tilbud 36. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold hertil, herunder til hvilke typer af poster der evt. ikke kan tilknyttes kommentarer og vedhæftes filer. Leverandøren skal i underbilag til bilag 2 endvidere redegøre for den tilbudte løsnings søgefunktionalitet, herunder søgefunktionalitetens brugerinterface og resultatpræsentation, samt muligheder for at tilpasse visningen af søgeresultater gennem applikation af filtre, sorteringer etc Programmering af batchjobs Krav 30. Løsningen skal indeholde funktionalitet til at afvikle periodiske jobs (batchjobs), fx i forbindelse med inddatering via overførsel eller udskrivning af data, rapportering, ad hocanalyser eller andet. Løsningen skal kunne afvikle periodiske og tidsforskudte jobs (batchjobs), fx udenfor arbejdstiden i forbindelse med inddatering og overførsler Krav til driftsplaner Krav 31. Leverandøren skal i henhold til kontrakten udarbejde egentlige driftsplaner på baggrund af ydelsesbeskrivelserne i bilag 1 og leverandørens løsningsbeskrivelse i bilag 2. BILAG 1 C - KRAVSPEFICIKATION SIDE 14

19 Det er et krav til indholdet, at driftsplanerne beskriver rutiner, og er egnede som styringsværktøj for den daglige drift. Driftsplanen kan udgøre en detaljering af leverandørens løsningsbeskrivelse. Driftsplanerne skal sikre, at der sker en vidensoverførelse og forventningsafklaring parterne imellem, og at der identificeres præcise målepunkter og opfølgningsinstrumenter for de enkelte opgaver. Endelig skal driftsplanerne indeholde en beskrivelse af procedurer, kontaktnumre mv. i forbindelse med den daglige opgavevaretagelse. Indholdet af driftsplanerne drøftes og fastlægges endeligt efter kontraktindgåelse. Tilbud 37. Leverandøren skal i underbilag til bilag 2 medtage udkast til driftsplaner Svartider, oppetider mv. I en række af kundens opgaver og processer er tidsaspektet afgørende, og systemets oppetider og svartider er derfor vigtige. Krav 32. Systemet skal overholde de i bilag 9 aftalte svartider, oppetider mv. BILAG 1 C - KRAVSPEFICIKATION SIDE 15

20 6. BESKRIVELSE AF OPGAVEOMRÅDER OG PROCESSER Afsnittet indeholder detaljerede beskrivelser af et antal opgaveområder og processer som forventes understøttet af den udbudte løsning. For hvert opgaveområde beskrives følgende forhold: Navn for opgaveområdet/processen Formål og overordne krav til opgaveområdet/processen Beskrivelse af opgaveområdet/processen og dens kritiske delprocesser Specifikke krav (overordnet) til IT-understøttelse af opgaveområdet/processen Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen Leverandøren bedes detaljeret redegøre for, hvorledes den tilbudte løsning kan anvendes til at løse de opgaver og arbejdsgange som er beskrevet. Leverandøren skal tilstræbe et detaljeringsniveau som muliggør at udbudsgiver ved gennemgang af løsningsbeskrivelsen kan danne sig et indtryk af den tilbudte løsnings egnethed til at understøtte de beskrevne processer og arbejdsgange samt løsningen af de beskrevne opgaver. Der er beskrevet procescases inden for områderne: Debitor Ressourcestyring Anlægsstyring og anlægsaktiver Indkøb Økonomi og regnskab, herunder årsregnskab, omkostningsregnskab Likviditetsstyring Økonomi og budget Kontoplan Betaling (bank, giro og kasse) Rapportering og analyse BILAG 1 C - KRAVSPEFICIKATION SIDE 16

21 6.1 Debitor Tilbud 38. Leverandøren skal i underbilag til bilag 02 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Debitor. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Debitor Formål og overordnede krav Kunden ønsker, som en del af økonomisystemet, et debitormodul, der dels kan modtage transaktioner fra diverse modersystemer og udskrive girokort samt danne fakturaer fra kommunens øvrige fagforvaltninger og institutioner, og dels kan håndtere funktioner vedr. betalingskontrol, restancer m.v. Kundens arbejdsgange omkring udsendelsen af FIK-kort, fakturaudskrivning og betalingskontrol håndteres i dag gennem forskellige systemer. Der ønskes en fremtidig løsning hvor alle debitoropgaver løses i et og samme system. Kunden ønsker, at al registrering i systemet sker on-line, således at der til hver en tid er adgang til ajourførte data, uden at der skal ventes på særlige kørsler. Fra modersystemer ønskes en daglig opdatering. Beskrivelse af forretningsprocessen Krav oprettes i fagsystemerne, hvorefter data overføres til debitorsystemet. Faktura udskrives og udsendes til debitor. Kontering foretages samtidig Regningsdebitor-modulet anvendes til opkrævning af krav, der ikke opkræves via fagsystemer Når et krav er oprettet i regningsdebitor udskrives faktura og kravet overføres til opfølgning i KMD Debitor. Kontering foretages samtidig Tilgodehavender kan også indberettes manuelt i debitorsystemet Indbetalinger bogføres gennem kasse, bank og PBS. I forhold til betalingskontrol køres der rykkerkørsler, og rykkerskrivelser udsendes til modtagerne. Restancer, som ikke umiddelbart betales, håndteres i en særlig sagsbehandling. Der skal være mulighed for midlertidig stop af rykning. I forbindelse med rykkere pålignes gebyr og renter Fordringer sendes til CFR. Særlige forhold vedr. restancer håndteres i form af afdragsordninger samt overdragelse af restancer til SKAT. Efter 2. Rykker oversendes fordringen til inddrivelse hos SKAT. Alle hændelser skal gemmes i en journal i systemet og der skal være mulighed for manuelt at vedligeholde et notatfelt Til opkrævning af mellemkommunale refusioner og serviceydelser på sociale tilbud anvendes regnings-debitormodulet BILAG 1 C - KRAVSPEFICIKATION SIDE 17

22 Specifikke krav til it-løsning Faktura- og FIK-kort udskrivning Debitormodulet skal understøtte alle former for regninger/fik-kort som anvendes i offentlige institutioner, herunder papirbaserede regninger, PBS-regninger og e-fakturaer Fakturaer skal kunne sendes til E-boks Debitormodulet skal kunne håndtere løbende periodisk opkrævning fx for opkrævning for daginstitution Der skal være mulighed for at henlægge sagen i en periode Der skal kunne tilføjes afdragsaftaler Det er kommunens ønske selv at kunne foretage straks-udskrivning af fakturaer, herunder afgørelser om tilbagebetaling af kontanthjælp (så vi slipper for papir) Der ønskes fra debitormodulet læseadgang til: o o o Boligsikringskrav Regulering ag daginstitution Underholdsbidrag Betalingskontrol Indbetalinger udligner i vha. betalingsidenten videst muligt omfang de pålignede krav. Der skal automatisk kunne pålignes gebyrer og renter i forbindelse med rykning ved manglende indbetaling. Størrelsen af gebyret skal kunne bestemmes ud fra størrelsen på det skyldige beløb/kravstype. Der skal være adgang til en advis-funktion, der kan opsættes efter forskellige hændelser i systemet samt mulighed for individuelle advis indberetninger Der ønskes mulighed for ved opslag på debitorens saldo at se overordnet restancesaldo for hvert cpr. nr. Restancer skal kunne nedskrives/opskrives og betalingsaftaler skal kunne indgås og administreres Systemet skal indeholde en journalfunktion, hvori alle hændelser i systemet registreres i forhold til den enkelte borger. Der skal desuden være et notatfelt. Endvidere skal være mulighed for vedhæftning af filer eksempelvis notater, tilbagebetalings-afgørelser, beregninger m.v. Alle dokumenterne skal kunne tilgås fra debitormodulet. Der skal fra debitormodulet kunne dannes og udsendes valgfri skrivelser til borgeren Alternative adresser skal kunne registreres og anvendes, ligesom opkrævning skal kunne foregå til personer uden gyldigt CPR-nr. Øvrige forhold Systemet skal understøtte kundens behov for ledelsesinformation, herunder opsætning af standardudtræk og udtræk af statistiske opgørelser, eksempelvis i forhold til antal sager, kr. og arter I forhold til den daglige anvendelse af systemet skal der være udbyggede søgemuligheder og BILAG 1 C - KRAVSPEFICIKATION SIDE 18

23 udtræksmuligheder Det er et ønske fra kommunen, at bogføring kan ses med det samme efter registreret indbetaling. Dette vil mindske antallet af fejludsendte rykkere. Systemet skal kunne udskrive en log over ned-/afskrivninger. Mulighed for borgeradgang til overblik over udeståender hos kommunen via hjemmesiden (med digital signatur) Systemet skal understøtte muligheden for at kunden kan lave selvbetjeningsløsninger på kundens egen hjemmeside Der skal være mulighed for under hver restanceart at vedhæfte dokumentation for kravet feks tilbagebetalingspligterklæringer fra KMD-aktiv osv Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes PBS fakturering og indbetaling skal kunne ske via PBS NemKonto beløb skal automatisk kunne overføres til NemKonto E-indkomst ved udbetaling af visse beløb skal der ske en registrering i E-indkomst E-boks til fakturaer SKAT der skal være en snitflade for overførsel af restancer til SKAT/Rekvirent Borger.dk SKAT modregningsmodul til overskydende skat SKAT skal have læseadgang CPR Diverse fagsystemer Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 19

24 6.2 Ressourcestyring Tilbud 39. Leverandøren skal i underbilag til bilag 02 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Ressourcestyring. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Ressourcestyring Formål og overordnede krav Kunden ønsker et økonomisystem, der understøtter kommunens behov for ressourcestyring i forhold til opgaver i kommunens drift- og anlægsområde, bygningsservice mv. Kunden skal, hvor det er relevant, kunne detailstyre ressourceforbruget (fx mandetimer, maskintimer, materialer, underentreprenører etc.) på effektiv og professionel vis, og de forbrugte ressourcer skal afspejles i økonomisystemet. Ressourcestyring udgør den primære styringsmetode for en stor del af kommunens aktiviteter på det tekniske område, hvorfor en brugervenlig og fleksibel løsning som lader sig skalere/tilpasse til kommunens specifikke aktiviteter på det område er essentiel for effektive arbejdsgange. Beskrivelse af forretningsprocessen Delprocesser vedrørende ressourcestyring udgøres overordnet af: Budgettering og timeregistrering på sager, med hoved- og underaktivitets-niveau (tværgående) for ressourcer, maskiner og for værkstedspersonale. Registrering/styring af ferie, afspadsering, mer- og overarb.timer samt flex Budgettering og timeregistrering på ressourcer og maskiner. Godkendelse af timeregistrering (af formænd og administrativt personale). Automatisk overførsel til af lønbærende informationer til lønsystem. Vedligeholdelse af kost- og salgspriser på ressourcer til fakturering (styring af mandskabsog maskinpriser) Plejeplaner (vedligehold af grønne områder, græs, træer, bede mv.) Ledelsesinformation/styringsværktøj (tidsforbrug på opgaver) Rapporter over tidsforbrug pr. medarbejder eller pr. opgave mv. Div. rapporter, herunder tværgående rapporter på Hoved og Underaktiviteter. Tankanlæg (brændstof Driftsafdelingen) Lagerstyring Intern afregning (intern fakturering) Specifikke krav til it-løsning Der lægges vægt på den tilbudte løsnings understøttelse af de nævnte delopgaver og delprocesser i forbindelse med ressourcestyring. Ressourcestyringen forgår i dag i Navision. Medarbejderne tidsforbrug registreres enten via en Webportal eller mobiltelefonen (Easytime). Godkendelsen af registreret tid foregår ligeledes i Easytime. Løsningen anvendes udelukkende inden for det tekniske område, men en fremtidig løsning tænkes potentielt udbredt til yderligere områder. Der lægges vægt på brugervenligheden af registreringsflowet i forbindelse med timeregistrering m.m. da en stor andel af brugerne ikke anvender øvrig it i forbindelse med deres arbejde. Der ønskes en ressourcestyringsløsning som er integreret med økonomisystemet, således at BILAG 1 C - KRAVSPEFICIKATION SIDE 20

25 bogføring af økonomiposter sker automatisk, baseret på ressourcestyringsdata. Det er væsentligt, at der kan foretages detaljeret, tværgående rapportering på basis af de data i økonomisystemet, som hidrører fra ressourcestyringen. Der lægges vægt på, at ressourcestyringsløsningen er velegnet til håndtering af bevillingsmæssige forhold (budgetter), som de kommer til udtryk i en dansk kommune, herunder på løsningens funktionalitet i forhold til opfølgning af rapportering på sager/projekter i forhold til bevillinger, herunder krav til dokumentation af forbrug på områder/delaktiviteter. Desuden ønskes: Elektronisk rekvisition/ordrestyring med disponering (med vedhæftning af filer med kort, foto eller tegninger) Budgettering (rådighedsbeløb og bevillingsbeløb, et-årig og flerårig) Kalkulationer (sager, mandskab og på maskiner) Integration til GIS og plejeplaner Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Integration til økonomisystem, i det omfang der ikke er tale om ressourcestyring som en integreret del af dette. Integration til lønsystem Yderligere integrationer, se generelt afsnit desangående Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 21

26 6.3 Anlægsstyring og anlægsregnskab Tilbud 40. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående anlægsstyring og anlægsregnskab. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Anlægsstyring og anlægsregnskab Formål og overordnede krav Kunden skal kunne styre og udarbejde korrekte anlægsregnskaber for anlægsprojekter til brug for daglig drift samt politisk behandling m.v. Kunden ønsker mulighed for i økonomisystemet at kunne styre anlægsprojekter, og at der i forbindelse hermed sker en automatisk overførsel af oplysninger om igangværende og afsluttede anlægsprojekter til anlægskartoteket (anlægsaktiver). Til disse styringsopgaver hører: Mulighed for at kunne styre flerårige anlægsprojekter med en samlet anlægsbevilling fordelt over årlige rådighedsbeløb. Bevilling og rådighedsbeløb skal sammenholdes med forbruget. Mulighed for at synliggøre, hvordan kommunens årlige råderum og likviditet påvirkes, hvis anlægsprojekter gennemføres med en anden tidsmæssig profil end forudsat ved budgetlægningen. Mulighed for at tilgodese byrådets krav om et overskueligt anlægsregnskab (regnskaber på en side efter en fast skabelon). Registrering af anlægsaktiver i et anlægskartotek, der som minimum tilgodeser de lovmæssige krav samt mulighed for at kunne vedligeholde et kartotek over alle kommunens aktiver med beskrivelse af aktivet og dets afskrivningsprofil, samt mulighed for at kunne udarbejde regnskab over anlægsaktiver. Dannelse af anlægsnote til årsregnskabet Beskrivelse af forretningsprocessen Den overordnede proces vedrørende anlægsstyring og udarbejdelse af anlægsregnskab indeholder følgende aktiviteter: Budgettering af omkostningerne, godkendelse af anlægsprojekt, frigivelse af rådighedsbeløb, budgetjusteringer, forbrug fordelt på regnskabsår og på artsniveau, løbende opfølgning på forbrug på projektet samt afslutning og udarbejdelse af anlægsregnskab. Anlægsstyring indeholder delprocesser vedrørende: Fleksible forespørgsler og opfølgning på anlægsbevillinger, rådighedsbeløb og forbrug Rapportering på forbrug og disponering Anlægsregnskaber indeholder delprocesser vedrørende: Udarbejdelse af anlægsregnskaber ved anlægsprojekters afslutning og ved årsafslutninger, indeholdende budget, rådighedsbeløb og forbrug Udarbejdelse af anlægsoversigter Rapportering til udvalg m.fl. vedrørende anlægsregnskaber. Anlægsregnskaber på 2. Mio. kr. forelægges Byrådet til godkendelse. I dag anvender kommunen en egenudviklet anlægsregisteret til styring af - og rapportering vedr. BILAG 1 C - KRAVSPEFICIKATION SIDE 22

27 Navn for processen Anlægsstyring og anlægsregnskab anlægsprojekter, hvortil oplysninger om forbrug overføres manuelt månedligt. Fremover ønskes, at anlægsprojekter kan styres som en integreret del af økonomiløsningen. Specifikke Krav til it-løsning Der lægges vægt på den tilbudte løsnings understøttelse af de nævnte delopgaver og delprocesser i forbindelse med anlægsstyring og anlægsregnskaber. Der ønskes mulighed for at registrere forskellige baggrundsoplysninger vedr. anlægsprojekter, herunder bl.a. bevillingsdato, status, dato for regnskabsgodkendelse, samt hvem der er administrativt ansvarlig for den givne anlægsbevilling. Mulighed for at tilknytte filer eller anden dokumentation til et anlægsprojekt Anlægsprojekter skal kunne nedbrydes i delprojekter. Der skal valgfrit kunne opbygges en kontoplan pr. projekt/delprojekt Der ønskes mulighed for at anvende dispositionsbogføring, som skal indgå i opfølgningen på anlægsprojekterne. Det ønskes at bogføring af forbrug i økonomisystem og anlægsregister skal ske som en integreret proces uden dobbeltregistrering. Der ønskes mulighed for løbende at overføre oplysninger vedr. igangværende anlægsprojekter til Økonomisystemets anlægskartotek (anlægsaktiver). Der ønskes mulighed for en kobling af anlægsprojekter til finansdel (lån, deponering m.v.) samt kobling til afledte driftsudgifter/-besparelser. Der lægges vægt på, at der kan udskrives rapporter over anlægsprojekterne både detailrapporter og summariske rapporter til byrådet, hvor anlægsregnskabet vises overskueligt gerne på én side, hvis muligt. Der ønskes mulighed for fra økonomisystem at generere en standardrapport til opfølgning på anlægsudgifter, som for hvert anlægsprojekt kan vise følgende oplysninger: Bevillingsdato Samlet bevilling Årets rådighedsbeløb Vedtagne tillæg til årets rådighedsbeløb Overførsel fra foregående år Samlet rådighedsbeløb for året Forbrug før indeværende år Forbrug år til dato i indeværende år Samlet forbrug Rest til rådighed i indeværende år Resterende bevilling Evt. dato for godkendelse af anlægsregnskab Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Der ønskes etableret en sammenhæng mellem anlægsregistret og anlægskartoteket i økonomisystemet, således at anlægskartoteket automatisk kan opdateres, herunder dannelse af anlægsnote BILAG 1 C - KRAVSPEFICIKATION SIDE 23