BILAG 1 KRAVSPECIFIKATION ØKONOMISYSTEM
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 i Gladsaxe Kommune. 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.
INDHOLD 1. Indledning 1 1.1 Generelt 1 1.2 Procescases 1 2. Kunden 2 3. Udbuddets omfang 3 4. Generelle krav til tilbuddet 4 4.1 Basiskrav 4 4.2 Hovedtidsplan 4 4.3 Projektledelse 5 4.4 Opsætning og konfigurering 5 4.5 Konvertering (option) 5 4.6 Implementeringsbistand 5 4.7 Test 6 4.8 Uddannelse (option) 6 4.9 Dokumentation 7 4.9.1 Dokumentation af analysefasen 7 4.9.2 Dokumentation af løsningen 7 4.10 Brugersupport 8 4.11 Udviklingsplaner 8 4.12 Projektmodel 8 4.13 Bemanding 8 4.14 Involvering af kundens medarbejdere 8 4.15 Kundens udviklingsprojekter 9 4.16 Læseadgang historiske data (option) 9 5. Generelle krav til løsningen 10 5.1 Forventninger til leverandøren 10 5.2 Lovmæssige krav 10 5.3 Krav vedrørende økonomistyring for selvstændige virksomheder 10 5.4 Brugervenlighed og fleksibilitet 10 5.5 Forhold vedr. it-arkitektur, integration m.v 11 5.5.1 Integration i forhold til økonomisystemet 11 5.5.2 It-sikkerhed 12 5.5.3 It-arkivering 13
5.5.4 Bygningsvedligehold 13 5.6 Dataudtræk 13 5.7 Metadata og søgbarhed 14 5.8 Programmering af batchjobs 14 5.9 Krav til driftsplaner 14 5.10 Svartider, oppetider mv. 14 6. Beskrivelse af opgaveområder og processer 15 6.1 Opbygning og vedligeholdelse af Kontoplan 16 6.2 Bank og kasse 19 6.3 Brugeradministration 20 6.4 Rapportering og analyser 22 6.5 Budgetlægning og -opfølgning 26 6.6 Årsafslutning 29 6.7 Anlægsstyring og anlægsregnskab 31 6.8 Ressourcestyring (option) 33 6.9 Debitorområdet 35 6.10 Indkøb og e-handel (option) 38 Appendiks Appendiks 1: Budget- og regnskabsregulativ Appendiks 2: Behandling af OIO-faktura i godkendt eksternt system.
1. INDLEDNING 1.1 Generelt Denne del af det samlede udbud omfatter udbud af Gladsaxe Kommunes ø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
2. KUNDEN Gladsaxe Kommunes 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. Gladsaxe Kommune anslår antallet af brugere på den nuværende økonomiløsning til at være som følger: Kategorier Brugere Superbrugere Ca. 25 Brugere* Ca. 1.000 Portalbrugere Ca. 1.000 Brugere af indkøbsløsning Ca. 500 Brugere af webportal til ressourcestyring Ca. 125 * Ekskl. systemtekniske bruger, såsom kasser, og fiktive brugere til brug for administration og undervisning. Krav 1. Leverandøren skal afgive tilbud med udgangspunkt i det nuværende antal brugere. BILAG 1 C - KRAVSPEFICIKATION SIDE 2
3. UDBUDDETS OMFANG Opgaven omfatter anskaffelse, drift og vedligeholdelse af et standard økonomisystem. Gladsaxe Kommune anvender i dag følgende it-løsninger til at løse opgaver inden økonomi og økonomistyring: EG ØS Indsigt med tilhørende moduler Brugerdata - Ressourcestyring KMD - KMD Debitor Truelink - Tradebuilder (e-indkøb) Herudover ønsker Gladsaxe tilbud på et system til håndtering af anlægsregisteret. Et system som Gladsaxe Kommune ikke råder over i dag. Krav 2. Det er et krav, at leverandøren i sit tilbud tager udgangspunkt i den nuværende systemunderstøttelse, idet der ikke med dette udbud er formuleret ønsker om udvidelse af systemunderstøttelse inden for de omfattede proces- og arbejdsområder. BILAG 1 C - KRAVSPEFICIKATION SIDE 3
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, indkøbsløsning, ressourcestyring, uddannelse og konvertering af data skal medtages som optioner. Hermed forstås, at leverandørens tilbud inden for disse områder skal prissættes separat, således Gladsaxe 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 Gladsaxe Kommune fortsat skal gøre brug af. 4.2 Hovedtidsplan Krav 6. Det er et krav, at det nye økonomisystem er klar til drift i hele kommunen den 15. oktober 2011. På dette tidspunkt skal systemet være klar til indberetninger af budgetterne for 2012. Den 1. december 2011 skal økonomisystemet være klar til at varetage samtlige opgaver. (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 Uddannelse (option) BILAG 1 C - KRAVSPEFICIKATION SIDE 4
4.3 Projektledelse 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/1 2007 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). BILAG 1 C - KRAVSPEFICIKATION SIDE 5
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, 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. 8-10 ø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. 30 ø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. 1.000 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. 150 lette brugere): Uddannelsen skal sikre, at de lette brugere kan anvise og foretage lettere forespørgsler Indkøbsbrugere (ca. 500 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. 125 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 BILAG 1 C - KRAVSPEFICIKATION SIDE 6
Krav 15. Krav 16. Krav 17. Krav 18. Krav 19. 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. Leverandø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. Uddannelsen af superbrugere og brugere skal foregå hos kunden, der stiller lokaler og udstyr til rådighed. Uddannelsen af superbrugere og brugere skal tilrettelægges, så kundens særlige forhold, konfiguration og arbejdsprocesser indgår. 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. 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. 4.9.1 Dokumentation af analysefasen Krav 20. Resultatet af analyse- og designfasen skal dokumenteres i en løsningsbeskrivelse, som vil indgå i kontraktens bilag 2 (mindstekrav). 4.9.2 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 21. Krav 22. 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
Krav 23. Tilbud 7. Dokumentation skal leveres samtidigt med programmellet og godkendes som en del af overtagelsesprøven. Leverandøren skal i underbilag til bilag 2 beskrive den dokumentation, som følger med løsningen. 4.10 Brugersupport Den generelle leverandørservice skal indeholde brugersupport/helpdesk, som opfylder: At leverandøren er forpligtet til at besvare alle forespørgsler vedrørende anvendelse af systemet. At der skal ydes hjælp til udredning af konkrete problemsager/ problemstillinger. At der skal kunne afgives fejlmeldinger, både i forhold til systemanvendelse og driftsafvikling. At der skal afgives en tidsramme for tilbagemelding vedrørende løsning af problemet. Et begrænset antal brugere vil blive autoriserede til at henvende sig til brugersupporten. Tilbud 8. Leverandøren skal i bilag 10 beskrive omfanget at den tilbudte brugersupport. Omfanget af den tilbudte brugersupport skal som minimum inkludere de fire nævnte forhold. 4.11 Udviklingsplaner Tilbud 9. 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) 4.12 Projektmodel Tilbud 10. 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. 4.13 Bemanding Tilbud 11. 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. 4.14 Involvering af kundens medarbejdere Tilbud 12. 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
4.15 Kundens udviklingsprojekter Tilbud 13. 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. 4.16 Læseadgang historiske data (option) Ved udløb af denne kontrakt skal opgaven genudbydes. Det kan indebære, at Gladsaxe Kommune skal overdrage opgaven til en ny leverandør. Gladsaxe Kommune 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 systemet, som de forefindes ved kontraktens udløb. Spørgeadgangen skal foregå ved brug af det benyttede system eller et system med lignende spørgefunktionalitet. Krav 24. Leverandøren skal som option i bilag 13 angive prisen pr. måned for at opretholde spørgeadgangen til data i 1 år efter kontraktens udløb. Prisen kan angives som en %- sats af den ved kontraktudløb gældende månedlige afgift. BILAG 1 C - KRAVSPEFICIKATION SIDE 9
5. GENERELLE KRAV TIL LØSNINGEN 5.1 Forventninger til leverandøren Gladsaxe Kommune 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 25. 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 26. Tilbud 14. Tilbud 15. 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. Leverandøren skal i underbilag til bilag 2 redegøre for, hvordan systemet lever op til kravene i Aftale om anvendelse af åbne standarder for software i det offentlige (B103). 5.3 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 16. Tilbud 17. 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 13. 5.4 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æ- BILAG 1 C - KRAVSPEFICIKATION SIDE 10
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 27. Krav 28. Krav 29. Tilbud 18. 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. Leverandøren skal i underbilag til bilag 2 redegøre detaljeret for den tilbudte løsnings funktionalitet i forhold til fleksibel tilpasning af opsætningen, herunder brugerinterface, rapporter, søgeresultater, kontoplan m.m.) 5.5 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 19. Tilbud 20. Tilbud 21. 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 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. 5.5.1 Integration i forhold til økonomisystemet Økonomisystemet skal understøtte den nødvendige datamæssige integration med en række øvrige it-løsninger, som leverer og trækker økonomidata. Gladsaxe Kommune kan umiddelbart pege på følgende systemer og parter, hvorfra der i dag er etableret dataintegration til den eksisterende økonomiløsning: Integrationer i forhold til økonomi og debitor: KMD Underholdsbidrag - Debitor KMD Underholdsbidrag Kreditor KMD Daginstitutionsbetaling KMD ESR (ejendomsskat) KMD Pension KMD KMD Aktiv BILAG 1 C - KRAVSPEFICIKATION SIDE 11
KMD KMD Boligstøtte KMD KMD Udbetaling KMD KMD Børnetilskud KMD KMD-Debitorsystemet KMD - Boliglånesystemet KMD S&A KMD Ejendom KMD Lønsystem KMD Sygedagpenge Rambøll EKJ PBS BS-Basis, BS-Total og BS-Plus KMD Booking Web Booking Brugerdata - Ressourcestyring Digital Bygnings Data - DBD SKAT - E-indkomst KMD Modregningssystemet KMD On Demand (udskiftes pr. 1.10.2010 til doc2archive fra KMD) KMD FAS c/s KMD Feriemodul P-data Nemkonto SKAT Virk.dk DIBS De Centrale Pas og Kørekort Lotus Notes Rambøll Care Geo-Environ BOSSINF (socialt boligbyggeri) KMD Opera Gladsaxe Kommune forventer, at der kan være behov for yderligere snitflader. Tilbud 22. Krav 30. 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. 5.5.2 It-sikkerhed Løsningen skal indeholde sikkerhedsfunktionalitet, som opfylder Datatilsynets sikkerhedskrav. Tilbud 23. Tilbud 24. 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
5.5.3 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 31. 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.5.4 Bygningsvedligehold Gladsaxe Kommune anvender et særligt system til styring af bygningsvedligehold, og forventer fortsat at skulle anvende dette system. Til bygningsvedligehold anvendes i dag systemet DBD. Kommunens bygningsmasse er registreret i DBD, hvortil der er koblet oplysninger om vedligeholdelse. Ved modtagelse af leverandørfakturaer sker der en spejling af omkostningen over i DBD. Tilsvarende styres attestationen af fakturaen i dette system med virkning i forhold til økonomisystemet. Der ønskes endvidere mulighed at overføre oplysninger fra DBD om periodiseret forventet forbrug (betalingsplaner) til anlægsregisteret /økonomisystemet, så oplysningerne kan indgå som ledelsesinformation i rapporter til brug for styring af flerårige anlægsprojekter. Se nærmere beskrivelse i appendix 2. Tilbud 25. 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 bygningsvedligehold. 5.6 Dataudtræk Gladsaxe Kommune benytter i høj grad ad hoc dataudtræk fra økonomisystemet i den daglige produktion. Løsningen skal derfor have omfattende muligheder for at udtrække data til manuel eller maskinel behandling, herunder til gængse regneark- og tekstbehandlingsformater. Gladsaxe Kommune ø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 26. Tilbud 27. Tilbud 28. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionaliteter i forhold til dataudtræk, herunder muligheden for at tilpasse standardrapporter og etablere nye rapporter til specifikke formål. Leverandøren skal i underbilag til bilag 2 redegøre for systemets mulighed for at overføre data og rapporter fra systemet til almindelige filtyper, herunder Word, Excel, HTML og PDF. 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 for- BILAG 1 C - KRAVSPEFICIKATION SIDE 13
programmerede makroer. Tilsvarende skal redegøres for den tilsvarende tilbageinddateringsfunktion. 5.7 Metadata og søgbarhed Gladsaxe Kommune ø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 29. Tilbud 30. 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. 5.8 Programmering af batchjobs Krav 32. 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. 5.9 Krav til driftsplaner Krav 33. 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. 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 31. Leverandøren skal i underbilag til bilag 2 medtage udkast til driftsplaner. 5.10 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 34. Systemet skal overholde de i bilag 9 aftalte svartider, oppetider mv. BILAG 1 C - KRAVSPEFICIKATION SIDE 14
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. For yderligere dokumentation af forhold i Gladsaxe Kommune, som forventes understøttet af en fremtidig løsning henvises i øvrigt til følgende appendiks: Appendiks 01: Budget- og regnskabsregulativ Der er beskrevet procescases inden for områderne: Kontoplan Bank og kasse Brugeradministration Budget og budgetopfølgning Årsregnskab m.v. Anlægsstyring og anlægsregnskaber Debitorstyring Ressourcestyring (option) Indkøb (option) Rapportering og analyser BILAG 1 C - KRAVSPEFICIKATION SIDE 15
6.1 Opbygning og vedligeholdelse af Kontoplan Tilbud 32. 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 kontoplan. Navn for processen Opbygning og vedligeholdelse af Kontoplan Formål og overordnede krav Overordnet ønsker Gladsaxe Kommune at kunne opbygge og vedligeholde en standardkontoplan, der understøtter kommunens krav til økonomistyring og rapportering. Der lægges vægt på en løsning som både tilgodeser krav fra det politiske niveau, de administrative behov for økonomistyring samt behov i forhold til styring af anlægsprojekter. Kontoplanen skal indebære mulighed for en tværgående økonomistyring i hele kommunen med gennemgående registreringsdimensioner på tværs. Desuden skal der være mulighed for at understøtte forskellige decentrale styringsbehov med valgfri opbygning af registreringsdimensioner i forhold til specifikke styringsbehov lokalt. Kontoplanen skal afspejle Den politiske kontoplan der fastlægger, hvem der er ansvarlig for bevillingerne og Den administrative kontoplan, der angiver hvem der har ret til at anvise. I forhold til styringsbehovene i forvaltningerne og på institutionsniveau er det målet, at økonomisystemet kan dække alle behovene bl.a. også til styring af disponeringer, således at behovet for regnearksløsninger kan elimineres. Kontoplanen skal opbygges i overensstemmelse med den autoriserede kommunale kontoplan. Leverandøren skal sikre at kontoplanen løbende lever op til de gældende regler i forhold til den autoriserede kontoplan. Beskrivelse af forretningsprocessen og dens kritiske processer Kontoplanen vedligeholdes centralt. Ved behov for nye konti, udfylder kommunens enkelte enheder en elektronisk formular, som indeholder alle nødvendige oplysninger. Den kontoplanansvarlige validerer oplysningerne inden konti oprettes. Systemet skal understøtte organisatoriske ændringer og flytning af opgaver og budgetansvar til andre enheder, herunder Oprettelse af helt nye organisatoriske enheder Flytning af eksisterende enheder til anden del af organisationen Oprettelse af enheder (fx daginstitutioner), hvor der i forvejen findes tilsvarende enheder Specifikke krav til it-løsning Kontoplanen skal opbygges som en multidimensional kontoplan. Brugen af registreringsdimensionerne skal kunne styres på 3 niveauer: Nogle af dimensionerne skal være gennemgående for hele kommunen, således at der på tværs kan foretages økonomianalyser af bestemte omkostningsarter. Nogle registreringsdimensioner skal kunne fastlægges for en gruppen af enheder/institutioner (fx for skoler) BILAG 1 C - KRAVSPEFICIKATION SIDE 16
Navn for processen Opbygning og vedligeholdelse af Kontoplan Andre dimensioner skal frit kunne benyttes decentralt til særlige styringsformål. Det skal være muligt at opsætte systemet, så det er krævet at udfylde udvalgte registreringsdimensioner. Tekster på dimensioner skal kunne låses i forhold til den værdi der registreres på en dimension. Der skal automatisk kunne foretages omkontering af posteringer fra en konto, eller interval af konti til en anden konto. Systemet skal kunne give advis (via e-mail) til udvalgte medarbejdere i forvaltninger og decentrale institutioner, hvis der oprettes nye konti eller foretages budget- eller udgifts- /indtægtsændringer. Systemet skal gennem validering sikre, at der er en entydig sammenhæng mellem kontoplan i økonomisystem og lønsystem. Øvrige forhold vedrørende kontoplan Kunden har i øvrigt i forbindelse med kontoplanen fokus på: At kontoplanen er logisk og intuitivt opbygget med genkendelige termer At de autoriserede regler knyttet til kontering i en kommune, herunder sammenhæng mellem forskellige kontotyper understøttes ved fejlmelding At der kan tildeles koder til udvalgte konti på tværs af kontoplanen til tværgående områder fx. bygningsvedligehold så der for delområder oprettes en autoriseret kontoplan Systemet skal understøtte en kontrol af, at decentrale konti peger korrekt på centrale konti, bl.a. med henblik på korrekt momsafløftning At der kan foretages omplaceringer decentralt, og at disse automatisk henføres til den overordnede, centrale kontoplan At det er muligt at ændre kontotekst uden, at kontoen opfattes som nyoprettet At konti kan styres på dato og år At det fremgår, når en konto er lukket. Det skal dog ikke være muligt at lukke en konto, som der er budget og/eller forbrug på. At der kan søges uafhængigt på alle dimensioner i kontoplanen At kontoplanen benytter genkendelig og let forståelig terminologi At kontotekster har en længde, der kan rumme tekstlængden i den autoriserede kontoplan At systemet giver et visuelt billede af kontoplanen, hvor man befinder sig på et givent tidspunkt, og mulighed for fleksibelt at bevæge sig rundt i kontoplanen At kontoplanen kan skrives ud og overføres til regneark. BILAG 1 C - KRAVSPEFICIKATION SIDE 17
Navn for processen Opbygning og vedligeholdelse af Kontoplan Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kontoplanen har snitflader og berøring til en lang række øvrige systemer, hvoraf lønsystemet må karakteriseres som det mest kritiske. Når der fra andre systemer dannes bogføringsposteringer til økonomisystemet, skal der fra disse systemer kunne ske en automatisk validering af den konto, som anvendes Det skal være muligt at udtrække hele eller dele af kontoplanen til regneark. Kvantitative forhold ved processen Kommunen har i dag ca. 20.000 konti. Kunden ønsker at kontohistorik kan ses i det nye system fra 2007 til 2011. Kommunen har i det nuværende økonomisystem godt 1.000 brugere oprettet, hvortil kommer systemtekniske brugere, såsom kasser, og fiktive brugere til brug for systemadministration og undervisning. BILAG 1 C - KRAVSPEFICIKATION SIDE 18
6.2 Bank og kasse Tilbud 33. 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 bank og kasse. Navn for processen Bank og kasse Formål og overordnede krav Gladsaxe Kommune ønsker et økonomisystem der fuldt ud understøtter opgaver i forbindelse med kommunens kassefunktion og afstemning i forhold til bank, herunder elektroniske kasserapporter. Beskrivelse af forretningsprocessen og dens kritiske processer Kommunen har en hovedkasse, hvor der dagligt modtages indbetalinger fra borgere enten kontant eller via dankort. Kassen optælles dagligt, dankortterminalerne afsluttes dagligt. Kassen afstemmes med bilagene. Betaling for pas og kørekort, skal ligeledes understøttes af økonomisystemet. Dette ønskes, således at der løbende kan bogføres. Dette foregår via daglige kasserapporter, der bogføres i økonomisystemet. Det skal være muligt for kommunen at have flere kontantkasser. Decentralt i kommunens institutioner er der ofte også kontantkasser til mindre kontante betalinger (opgøres nogen steder kun ugentligt). Disse skal også kunne håndteres systemmæssigt. Kommunens hovedkonti bliver afstemt ugentligt. De øvrige 18 centrale konti bliver månedligt afstemt. Institutionerne er ansvarlig for afstemning af egne bankkonti. Specifikke krav til it-løsning Det skal være muligt for kommunen at have flere kontantkasser. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen Kundens bank er Danske Bank og Nordea. Kunden har 2 hovedkonti og 18 andre centrale konti. BILAG 1 C - KRAVSPEFICIKATION SIDE 19
6.3 Brugeradministration Tilbud 34. 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 brugeradministration. Navn for processen Brugeradministration Formål og overordnede krav Brugeradministrationen skal sikre en let og sikker håndtering af brugeroprettelse og ændringer og sikre at kun brugere der er autoriseret hertil skal have adgang til økonomisystemet. Der skal i økonomisystemet sikres, at brugere af systemet er autoriseret til at have adgang til systemets data og funktioner, såvel gennem adgang til skærmbilleder, ved rapportering og ved udtræk af data til andre systemer. For den enkelte bruger skal der kunne ske en detaljeret og fintmasket styring af, hvilke adgange til data og funktioner, den enkelte bruger har. Systemet skal sikre, at brugerrettigheder, adgang til systemet og brugen af systemet bliver dokumenteret og logget, så registreringer og ændringer i systemet kan henføres til den medarbejder, der har foretaget ændringen, og så systemet lever op til Datatilsynets krav. Beskrivelse af forretningsprocessen Oprettelse og vedligeholdelse af brugernes rettigheder og adgangsforhold til økonomisystemet sker i en central funktion. Kommunen anvender en web-skabelon til understøttelse af brugeradministration. Skabelonen sikrer at de nødvendige oplysninger bliver indberettet elektronisk til den funktion, der forestår brugeradministration, og sikrer at godkendelse finder sted. Når brugeroprettelse er sket sendes en kvittering/mail herom til den pågældende medarbejder. Brugerrettigheder styres ud fra foruddefinerede standardprofiler. Krav til it-løsning Økonomisystemet skal indeholde funktioner, der gør det muligt at foretage en sikker og veldokumenteret registrering og styring af brugernes adgange og rettigheder. Der skal kunne opbygges en række standardprofiler/adgangsgrupper, som den enkelte bruger kan tilknyttes. Der skal desuden kunne foretages individuelle ændringer i den enkelte brugers rettigheder. En given brugers rettigheder skal kunne kopieres over til en anden medarbejder fx ved fratrædelser. Der skal kunne udsendes en kvittering til brugeren, når der er sket oprettelse/ændring af brugerrettigheder med information om rettigheder og ændringer. Det ønskes, at kvittering samt vedhæftet brugervejledning til nye brugere skal kunne udsendes via en e-mail, som genereres direkte fra økonomisystemet. Systemet skal automatisk kunne sende en e-mail med en ny adgangskode til de brugere som BILAG 1 C - KRAVSPEFICIKATION SIDE 20
har glemt deres kode, hvis brugeren ønsker dette. Brugeren skal selv via systemet kunne anmode om en ny kode. Det skal være muligt at opsætte detaljerede regler for, hvilke medarbejdere der må kontere på hvilke konti/dimensioner. Medarbejdere har normalt kun ret til at bogføre inden for eget område. Institutioner der anvender decentral kontoplan skal have adgang til selv at oprette konti efter behov. Der skal kunne opsættes regler for, hvilke konti/registreringsdimensioner, der må oprettes/ændres lokalt. Det skal være muligt at begrænse adgangen til kontoplanen efter brugerens behov, idet det fortsat skal være muligt for brugeren at udtrække data fra en større del af kontoplanen. Kommunens regler for anvisning af betalinger skal kunne afspejles og håndteres. Budget- og regnskabsregulativ for Gladsaxe Kommune vedlægges som bilag. Der ønskes mulighed for i systemet at indbygge kontroller, så brugeren i forbindelse med betaling/anvisning, ikke har mulighed for at lave bilag til sig selv, og så anvisningsberettigede ikke kan anvise til sig selv. Der ønskes mulighed for at spærre fratrådte medarbejdere i systemet uden at fjerne dem, så logning og historik fortsat kan ses i systemet. Om muligt ønskes brugerrettigheder i lønsystem og økonomisystem baseret på en centralt vedligeholdt fælles ledelses- og organisationsstruktur. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Oplysninger om brugerrettigheder og log over registreringer i systemet skal kunne overføres til regneark. Gladsaxe Kommune anvender Lotus Notes som postsystem. Kvantitative forhold ved processen Kommunen har i det nuværende økonomisystem godt 1.000 brugere oprettet. I dag anvender kommunen i størrelsesordenen 30 forskellige brugerprofiler. BILAG 1 C - KRAVSPEFICIKATION SIDE 21
6.4 Rapportering og analyser Tilbud 35. 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 rapportering og analyse. Navn for processen Rapportering og analyser Formål og overordnede krav Brugerne af økonomisystemet skal have nem adgang til alle relevante informationer i form af rapporter og velstruktureret ledelsesinformation, som kan sikre det bedst mulige styringsgrundlag. Gladsaxe Kommune stiller krav om, at systemet giver brugerne adgang til information om alle relevante økonomiske forhold samt forhold vedr. løn og personale. Rapportering skal sikre at budgetkontrol og årsafslutning kan foretages på et præcist, sikkert og overskueligt grundlag. Der ønskes fra alle forvaltninger fleksibel mulighed for rapportering direkte fra økonomisystemet. Der lægges vægt på både at have faste skabeloner/rapporter, der kan genbruges og mulighed for selv at definere rapporter og udtræk. Dette inkluderer kodning af udvalgte konti og posteringer, så der kan følges op på specifikke områder på tværs af kontoplanen og bogføringselementer. Informationerne skal kunne hentes online med fleksible og valgfri muligheder for afgrænsninger på alle dimensioner, konti, baggrundsdata (fx leverandørnavn, -adresse, cvr-nr,) med mulighed for periodeafgrænsninger, valg af dimensioner samt rækkefølge deraf, sortering og sumangivelser. På grund af lønomkostningernes store andel af kommunens samlede budget er der særlig fokus på, at sikre en ledelsesinformation, der giver en sammenhængende information og analysemulighed fra økonomi- og lønsystemet. Der ønskes at man kan starte analysen på et aggregeret niveau og slutte med oplysninger om, hvilke medarbejderes lønandele, der ligger bag det aggregerede tal. Der ønskes en rollebaseret rapportering, så systemet foreslår en rapporteringsform efter hvilken rolle, som brugeren indtager. Beskrivelse af forretningsprocessen Budgetopfølgning foretages normalt månedsvis af de enkelte budgetansvarlige. Tilsvarende foretages i kommunens enheder opfølgning på fravær og øvrige personaleforhold. Ud over den faste budgetopfølgning er der løbende behov for at foretage ad hoc prægede analyser af økonomi og af forhold vedr. løn og personale. I sådanne analyser starter man typisk analysen på et overordnet niveau og har derefter brug for at gå i yderligere detaljer og at foretage filtreringer og sorteringer i forhold til kontoplanens dimensioner. Likviditeten overvåges løbende med behov for dag-til-dag styring. Ved analyser skal systemet understøtte, at der kan udtrækkes og overføres informationer fra økonomisystemet til regneark for videre bearbejdning her. BILAG 1 C - KRAVSPEFICIKATION SIDE 22
Navn for processen Rapportering og analyser Specifikke krav til it-løsning Den faste, periodiske økonomirapportering til brug ved budgetopfølgning skal kunne udformes efter en fælles skabelon. Der skal desuden kunne udformes særlige rapporter til understøttelse af de enkelte områder og enheders særlige styringsbehov. Brugergrænsefladen for rapportering og analyse skal være intuitiv og let anvendelig for forskellige brugergrupper med forskellige forudsætninger. Til brug ved ad hoc prægede analyser ønskes adgang til en overskuelig brugergrænseflade, hvorfra man kan udvælge informationer i forhold til enkelte dimensioner eller til intervaller af dimensioner. Der ønskes mulighed for at kunne foretage drill down i rapporterne online, så analyser på et mere konkret niveau kan foretages straks uden at man skal afvente at rapporter genereres. På rapporterne skal man samtidig kunne få vist budgetbeløb og bogførte beløb. I forlængelse af analyserne skal man kunne foretage simuleringer/estimeringer fx af, hvordan årsresultatet forventes at blive for det udvalgte område. De faste rapporter, som kommunen skal aflevere til eksterne myndigheder. Som fx DS, KL og Ministeriet skal kunne dannes og overføres elektronisk til modtageren. Der skal kunne foretages pengestrømsanalyser og opgørelse af kommunens likviditets på dag-basis, der tager højde for kassekreditter og byggekreditter. Det skal sikres, at medarbejdere kun kan anfordre rapporter med data, som de har adgangsrettigheder til. For oplysninger om løn og personale vil lederen som udgangspunkt kun skulle gives adgang til oplysninger om egne medarbejdere. Der skal i rapporteringen generelt være sporbarhed, således at det på enkel vis er muligt at få vist, hvilke posteringer, der ligger til grund for de tal, der vises i rapporterne. Dette gælder også når specifikation af tallene i økonomisystemet skal findes i andre systemer. Som eksempel på dette ønskes der i rapporteringen en let adgang til den fulde specifikation for de posteringer i økonomisystemet, der dannes på baggrund af lønkørsler. Specifikationen ønskes her i forhold til de medarbejdere, som lønkørslen har omfattet og i forhold til lønnens enkelte bestanddele/de enkelte lønlinjer. Tilsvarende ønskes der nem adgang til den fulde specifikation vedr. personaleforhold som fx fravær/ og sygdom, personalesammensætning (på køn og alder). Mediet for rapportering skal som minimum kunne vælges mellem følgende muligheder: Udtræk til skærm, papir, pdf, regneark og flade filer Rapporter skal kunne trækkes på tværs af regnskabsår, og der skal være adgang til rapportering vedr. det p.t. gældende budget for kommende år. Der skal i rapporteringen kunne skelnes mellem vedtaget budget, tillægsbevillinger, omplaceringer, overførsler og korrigeret budget. Det skal være muligt frit at periodeafgrænse både budget og forbrug i rapporter. Der ønskes mulighed for at udsøge alle bogførte fakturaer pr. leverandør og kunne åbne ori- BILAG 1 C - KRAVSPEFICIKATION SIDE 23
Navn for processen Rapportering og analyser ginalfaktura Systemet skal kunne generere en rapport som svarer til den autoriserede rapportering ved årsafslutning, herunder indeholdende både udgiftsregnskab, omkostningsregnskab mv.. Generelt skal systemet understøtte de obligatoriske økonomirapporter i forbindelse med regnskabsaflæggelse og øvrig rapportering til ministeriet og andre offentlige myndigheder. Understøttelse af obligatoriske indberetninger til myndigheder og KL via standardrapporter bl.a. på følgende områder: Ligestillingsrapport med data fra lønsystemet Serviceudgifter Overførselsudgifter Gennemsnitslikviditet (til Indenrigs- og Socialministeriet) M.fl. Øvrige forhold i relation til rapportering I forhold til rapportering lægger kunden desuden vægt på: At rapporteringen understøtter både den autoriserede kontoplan, kommunens politiske organisation og den organisatoriske opbygning At kunne søge på alle kontoplan- og bogføringselementer At rapportere både på indtægter og udgifter ikke kun nettobeløb At benytte foruddefinerede rapporter til standardopgørelser fx. af refusion, moms m.v. At udarbejde skabeloner til standardrapporter til brug bredt i kommunen, men at brugerne også selv på fleksibelt vis kan definere udtræk og rapporter At gemme brugte rapportafgrænsninger til senere brug At foruddefinere nøgletal til udtræk af økonomisystemet At der kan udregnes forbrugsprocenter At kunne genere automatiske rapporteringer, der tilgår modtageren pr. mail At foruddefinerede rapporter har genkendelige og letforståelige navne At kunne lave en opgørelse over regninger pr. EAN-nr, som mangler at blive bogført Tid, dato og afgrænsninger skal fremgå af alle rapporter. Ved søgning på kreditor inden for et område skal kun egne posteringer fremgå. Rapporter på budget/forbrug skal der være mulighed for at kunne nøjes med en totallinie for hver decentral konto. Rapporter på budget/forbrug skal der være mulighed for at kunne nøjes med en totallinie for hver decentral konto. BILAG 1 C - KRAVSPEFICIKATION SIDE 24
Navn for processen Rapportering og analyser Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Det ønskes oplyst, hvordan de tilbudte systemer kan levere data til Datawarehouse-løsninger og Business Intelligens-værktøjer. Gladsaxe Kommune anvender Lotus Notes som postsystem. Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 25
6.5 Budgetlægning og -opfølgning Tilbud 36. 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 budgetlægning og opfølgning. Navn for processen Budgetlægning og -opfølgning Formål og overordnede krav Gladsaxe Kommune skal kunne udarbejde budgetter, der kan anvendes til styring i forhold til det politiske niveau - de 8 politiske udvalg og de ca. 20 bevillingsområder, samt i forhold til de administrative behov på forskellige niveauer. Generelt skal der være let adgang til information om budgetstatus og relevante budgetposteringer for brugere på alle niveauer af organisationen Der skal ved udarbejdelse af budget klart kunne skelnes mellem følgende status for budgetter: Budgetønsker, Midlertidig godkendt budget, Vedtaget budget. I Vedtaget budget skal der kunne indberettes, tillægsbevillinger, omplaceringer og overførsler. Budgettyperne Budgetønsker og Midlertidig budget skal kunne findes i flere versioner. I forbindelse med udarbejdelse af budgettet stilles der krav til økonomisystemet, at det indeholder funktioner til budgetsimulering og op- og nedskrivninger af budgettal både i forhold til den centrale budgetfunktion og til forvaltninger, der kun skal arbejde på et udsnit af budgetterne. Der ønskes mulighed for at gemme tidligere simuleringer af fx LBU (Langsigtet BudgetUdsigt) og Endeligt Skøn i budgetversioner, således at der er mulighed for at sammenligne forudsætningerne i tidligere skøn med det faktisk vedtagne budget. Beskrivelse af forretningsprocessen Den årlige budgetlægning i kommunen udgøres overordnet af følgende aktiviteter: Tidsplanlægning af budgetprocessen Langsigtet budgetskøn (LBU). Der indarbejdes konsekvenser af demografi og kendte lovændringer i et 10-årigt perspektiv. Udarbejdes p.t. uden for økonomisystemet. Budgetfremskrivning baseret på tidligere budgetter påført diverse reguleringer og fremskrivninger (pris- og lønfremskrivninger etc.) Rammeudmelding 1 (Budgetcirkulære) inkl. fremskrivning og tidligere vedtagne tekniske korrektioner med efterfølgende decentral udmøntning Rammeudmelding 2 (udvalgenes budgetbidrag) med efterfølgende decentral udmøntning Rammeudmelding 3 (1. behandling af budgettet) med efterfølgende decentral udmøntning Rammeudmelding 4 (vedtaget budget) med efterfølgende decentral udmøntning, låses herefter i økonomisystemet som det Vedtagne Budget. BILAG 1 C - KRAVSPEFICIKATION SIDE 26
Navn for processen Budgetlægning og -opfølgning Central budgetbearbejdelse inkl. simulering og indarbejdelse af affødte ændringsønsker / ændringer Løbende (synkront) arbejde med forskellige budgetversioner, herunder simulering og skyggebudgetter Understøttelse af den politiske bevillingsproces (fx investeringsoversigter, bevillingsoversigter) Løbende kommunikation og formidling af budgetbilleder på alle niveauer samt ændringsoversigter på alle niveauer Budgetopfølgningens delprocesser udgøres af: Løbende budgetopfølgninger med detaljeret rapportering på alle niveauer Løbende kommunikation og formidling af budgetstatus på alle niveauer og for alle perioder Håndtering af dokumentation og bemærkninger til budgetopfølgning Omplacering af budgetposter, herunder detaljeret udmøntning Håndtering af tillægsbevillinger, herunder detaljeret decentral udmøntning Specifikke Krav til it-løsning Hver budgetversion skal kunne påføres et versionsnummer og en dato for dets dannelse. Desuden skal det til hver version kunne knyttes en tekst med forklaring til budgetversionen. Ordinære budgetposter samt tillægsbevillinger, omposteringer og overførsler skal hver registreres med en særlig type og en posteringsdato. Der skal ske logning af hvem der har indtastet budgetposter og af tidspunkt for posteringen. Desuden skal der kunne tilknyttes en forklarende tekst. Der skal til hver budgetpost endvidere kunne linkes til et dokument med uddybende tekst. I forbindelse med standardrapporter vedr. forbrug og budget skal systemet anvende gældende budgetversion. Der skal være mulighed for i forbindelse med ad hoc rapporter at kunne vælge, hvilken budgettype og version, der skal anvendes. I den almindelige rapportering skal man kunne angive, om man ønsker overførsler, omplaceringer og tillægsbevillinger medtaget eller ej, og der skal være mulighed for at se alle i samme rapport. Desuden skal man kunne anføre en dato for, hvilke tillægsbevillinger og omplaceringer, der skal tages med i budgettet. De nævnte valg skal fremgå at rapporteringen. Der ønskes mulighed for at sammenkoble relaterede budgetposter, fx relaterede tillægsbevillinger eller relaterede omplaceringer, så det bl.a. er let at finde eventuelle modposteringer til en given budgetpost. Sammenkædningen kan fx ske ved at sammenkoble relaterede budgetposter med ét bilagsnummer. Periodisering af budgettet skal kunne understøttes både centralt og decentralt. BILAG 1 C - KRAVSPEFICIKATION SIDE 27
Navn for processen Budgetlægning og -opfølgning Der ønskes mulighed for at vedhæfte diverse dokumenter til budgetter og budgetposter. Fx ønskes mulighed for at vedhæfte/linke til dokumentation af takstmodeller, BUM, demografimodeller osv. på en let måde. Der ønskes i forbindelse med budgetfunktionen en mulighed for via systemet at sende ADVIS til udvalgte nøglebrugere, fx hvis der centralt indtastes budgetposter med decentral virkning, eller hvis en given budgetændring betyder, at den samlede ramme overskrides. Tillægsbevillinger og omplaceringer skal registreres med en valørdato, så man kan opgøre det korrigerede budget pr. en given dato Efter at alle korrektioner er indarbejdet, skal det være muligt at lave et udtræk over de korrektioner, der er foretaget. Eventuelt skal der indarbejdes en automatisk kontrol for godkendelse af korrektioner inden korrektionerne får effekt. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 28
6.6 Årsafslutning Tilbud 37. 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 årsafslutning. Navn for processen Årsafslutning og aflæggelse af regnskab Formål og overordnede krav Kommunen skal hurtigst muligt efter årsskiftet effektivt kunne producere et retvisende årsregnskab såvel et udgiftsregnskab som et omkostningsregnskab, under overholdelse af gældende regler. Kommunen aktiverer anlægsaktiver til værdi af over 100.000 kr., og vedligeholder et anlægskartoteket med værdiansættelse, afskrivningsprofiler, kategoriseringer m.v. Beskrivelse af forretningsprocessen Processen vedrørende årsregnskab udgøres overordnet af: Pr. 1/12 åbnes for postering i forsupplementsperiode og eftersupplementsperiode I januar lukkes for generel bogføring i systemet, men omkontering er mulig I januar udsendes delregnskaber/budgetopfølgningsrapporter til budgetansvarlige for kommentering Der sker en inddatering af summariske regnskabstal fra selvejende institutioner Udgiftsregnskab udarbejdes herefter. I forbindelse med at omkostningsregnskabet foretages følgende: Anlægskartoteket (i økonomisystemets aktivmodul) ajourføres med årets til- og afgang, og der foretages afskrivninger Der håndteres skyldige feriepenge og hensættelser til tjenestemandspensioner mm. Omkostningsregnskab udarbejdes herefter. Herefter forestår revisionen af regnskab samt fremsendelse af rapporter til DS og Ministeriet. Specifikke Krav til it-løsning Der lægges vægt på den tilbudte løsning understøttelser de nævnte delopgaver og processer i forbindelse med årsregnskab. Der lægges vægt på følgende specifikke forhold vedrørende løsningen: At der kan ske en differentieret lukning for bogføring og posteringer, som kun gælder visse brugergrupper og visse posteringstyper (bogføring, omplaceringer, debitorposter). - Regnskabskommentarer skal kunne indsættes på kontoen eller kunne vedhæftes i dokument Der ønskes en advarsel ved bogføring omkring årsskiftet, så medarbejderen tager aktivt stilling til, hvilket regnskabsår, der skal bogføres i Der skal automatisk kunne udarbejdes samlede regnskabsrapporter med diverse bilag i henhold til myndighedskravene herunder anlægsoversigt, skyldige feriepenge og pension m.v. Rapporter til DS og ministeriet skal automatisk kunne udtrækkes ( flade filer ). Rapporterne ønskes opdateret løbende af leverandøren, så de er ajourført mht. ændringer i den BILAG 1 C - KRAVSPEFICIKATION SIDE 29
Navn for processen Årsafslutning og aflæggelse af regnskab autoriserede kontoplan Der skal kunne foretages et samlet udtræk af regnskabsdatabasen til kommunens revision. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Rapportudtræk til DS, KL og Ministeriet Regnskabsudtræk til kommunens revision Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 30
6.7 Anlægsstyring og anlægsregnskab Tilbud 38. 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. Navn for processen Anlægsstyring og anlægsregnskab Formål og overordnede krav Gladsaxe Kommune ø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 projekter 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 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. Opgaven er beskrevet i procescase vedr. Årsafslutning, omkostningsbaseret regnskab. Beskrivelse af forretningsprocessen Byrådet vedtager flerårige bevillinger for anlægsprojekter samt årlige rådighedsbeløb for disse. Rådighedsbeløb registreres i dag i økonomisystemet samt i kommunens database (anlægsregister). Bevillingerne registreres alene i anlægsregisteret. Større anlægsprojekter nedbrydes i delprojekter. Bevilling og rådighedsbeløb nedbrydes i detailbudgetter i henhold til anlægskontoplanen. Anlægsprojekterne tildeles en status efter hvor langt i processen de er: Under planlægning, Igangværende og Afsluttet Forbruget bogføres løbende i økonomisystemet på et projektnummer for hvert anlægsprojekt. I dag anvender kommunen en egenudviklet database (anlægsregisteret) til styring af - og rapportering vedr. 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. BILAG 1 C - KRAVSPEFICIKATION SIDE 31
Navn for processen Anlægsstyring og anlægsregnskab Specifikke Krav til it-løsning Anlægsprojekter skal kunne nedbrydes i delprojekter. Der skal valgfrit kunne opbygges en kontoplan pr. projekt/delprojekt 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 på en side. 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 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. Der ønskes mulighed for at kunne overføre oplysninger fra bygningsvedligeholdelsessystemet DBD om periodiseret forventet forbrug (betalingsplaner) til anlægsregisteret /økonomisystemet, så oplysningerne kan indgå som ledelsesinformation i rapporter til brug for styring af flerårige anlægsprojekter. 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. Kvantitative forhold ved processen Årligt afsættes der i kommunen i størrelsesordenen 250 mio. kr. til anlægsprojekter, og der findes p.t. ca. 200 aktive/igangværende sager, hvoraf mange er flerårige. BILAG 1 C - KRAVSPEFICIKATION SIDE 32
6.8 Ressourcestyring (option) Tilbud 39. 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 ressourcestyring. Navn for processen Ressourcestyring Formål og overordnede krav Gladsaxe Kommune ønsker et økonomisystem, der fuldt ud understøtter kommunens behov for ressourcestyring i forhold til driftsopgaver i kommunens By- og Miljøforvaltning. Ressourcestyring indebærer at der kan oprettes en række driftsopgaver som sager i ressourcestyrings-modulet, og hertil registreres budgetter og forbrug. Forbruget af primært medarbejdernes timer, men også eksterne udgifter, skal kunne registreres på sagerne. Ressourcestyringen indebærer endvidere at der kan foretages fakturering fra systemet af forbruget på driftsopgaver. Beskrivelse af forretningsprocessen Når en ny opgave modtages oprettes en sag i ressourcestyringssystemet. Medarbejderne begynder herefter at foretage registrering af timer på sagen. Dette sker enten via en web-baseret indberetningsformular eller timer inddateres via trykfølsom på stationære arbejdsstationer. Ved modtagelse af leverandørfakturaer sker der i dag en spejling af fakturaen over i det nuværende system (Brugerdata). Til svarende styres attestation af fakturaen i dette system med virkning i forhold til økonomisystemet. Løsningen er nærmere beskrevet i appendiks 2. Fakturering af driftssager sker via økonomisystemets regningsdebitormodul Krav til it-løsning Der ønskes en integreret løsning for ressourcestyring, der muliggør følgende: At fakturamodtagelse sker i et integreret workflow samlet for ressourcestyring og økonomistyring At bogføring af leverandørfakturaer sker med opdatering både i ressourcestyringsmodulet og i økonomisystemet i en integreret proces At timeregistrering, som foretages i ressourcestyringsmodulet også anvendes i lønsystemet til registrering af overtid, fravær m.v. At der enkelt kan foretages rapportering over status på den enkelte sag og samlet på udvalgte sager At der er mulighed for at overføre budgetoplysninger fra økonomisystemet til ressourcestyringssystemet Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kommunen anvender i dag et ressourcestyringssystem fra Brugerdata. Der ønskes fra løn- og økonomisystemet mulighed for at implementere snitflader til ressourcestyring som i dag med fælles workflow og integreret attestation samt bogføring af forbrug. BILAG 1 C - KRAVSPEFICIKATION SIDE 33
Navn for processen Ressourcestyring De bestående løsninger for tidsregistrering ønsket bibeholdt såvel web-formularen som den trykfølsomme skærm Der foretages en registrering af køretøjer o.l. anlæg i ressourcestyringsmodulet. Her ønskes stamoplysninger at kunne overføres automatisk til økonomisystemets anlægskartotek (aktiver), så anlæg som registreres i ressourcestyringsmodulet også registreres i anlægskartoteket. Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 34
6.9 Debitorområdet 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 debitorstyring. Navn for processen Debitorområdet Formål og overordnede krav Gladsaxe Kommune ønsker, som en del af økonomisystemet, et debitormodul, der dels kan modtage transaktioner fra diverse modersystemer og udskrive girokort samt danne fakturaer fra Gladsaxe Kommunes øvrige fagforvaltninger og institutioner, og dels kan håndtere funktioner vedr. betalingskontrol, restancer m.v. Kommunens 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 samme system. Det er forventningen 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. Regningsdebitor-modulet anvendes herudover til mellemkommunal afregning samt til krav, der ikke opkræves via fagsystemer Når et krav er oprettet i regningsdebitor udskrives faktura og posteringerne overføres til opfølgning i KMD Debitor. 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. I forbindelse med rykkere pålignes gebyr Særlige forhold vedr. restancer håndteres i form af afdragsordninger samt overdragelse af restancer til 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 fagsystemet EKJ. Systemet har p.t. snitflade til regningsdebitormodulet i økonomisystemet. BILAG 1 C - KRAVSPEFICIKATION SIDE 35
Navn for processen Debitorområdet 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 Det er kommunens ønske selv at kunne udskrive fakturaer, da det giver en forlænget arbejdsgang, når printet foregår hos KMD. Betalingskontrol Der skal automatisk kunne pålignes gebyrer og renter i forbindelse med rykning. 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 samt Notatfelt til journalisering af manuel sagbemærkninger på sagen 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. 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. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Snitflade til en lang række fagsystemer herunder til EKJ (Elektronisk Klient Journal) leveret af Rambøll PBS fakturering og indbetaling skal kunne ske via PBS NemKonto beløb skal automatisk kunne overføres vil 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 Kloaksystemet (en oversigt over modersystemer der leverer data til KMD Debitor) SKAT modregningsmodul til overskydende skat BILAG 1 C - KRAVSPEFICIKATION SIDE 36
Navn for processen Debitorområdet Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 37
6.10 Indkøb og e-handel (option) Tilbud 41. 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 indkøb og e-handel. Navn for processen Indkøb og e-handel Formål og overordnede krav Det overordnede mål for Gladsaxe Kommune er at sikre, at indkøb sker økonomisk mest fordelagtigt. Dette kræver adgang til et system, som understøtter indkøbsprocessen fuldt ud gennem alle dens aktiviteter Gladsaxe Kommune bestræber sig på, at en så stor del af indkøbene som muligt foretages gennem indkøbssystemet. De indkøbsansvarlige i Gladsaxe Kommune skal nemt og effektivt kunne orientere sig om kommunens indkøbsaftaler for varer og tjenesteydelser, merkantile forhold samt foretage deres indkøb af varer elektronisk. Arbejdsflow omkring bestilling af varer, varemodtagelse, godkendelse, fakturagodkendelse og kontering skal køre effektivt og digitaliseres i størst muligt omfang. Der lægges vægt på at indkøbssystemet er fuldt integreret i økonomisystemet, så dobbeltregistreringer undgås og så der er fuld overblik fra økonomisystemet over igangværende og afsluttede indkøb. Beskrivelse af forretningsprocessen Indkøb foretages elektronisk gennem indkøbssystemet eller ved direkte bestilling hos leverandørerne. Indkøb af varer som ikke findes i indkøbssystemets varekatalog kan håndteres i indkøbssystemet som Fri-tekst-ordrer. Delprocesser vedr. indkøb inkl. kontering udgøres overordnet af: Etablering og vedligeholdelse af indkøbsaftaler Opdatering og administration af elektroniske varekataloger, herunder automatisk fjernelse af overflødige varer samt priskontrol Ved indlæsning af elektronisk varekatalog, skal der være mulighed for et pristjek, udgåede og nye varer inden varekataloget indlæses. Favoritsider og standardordrer Nyhedsformidling vedr. indkøb og indkøbsaftaler Ad hoc opfølgning på indkøb (Statistikker på brugerniveau, institutionsniveau med mulighed for udtræk til Excel) Det enkelte elektroniske indkøb forløber ved: Søgning og visning af varer eller søgning efter indkøbsaftale Bestilling af varer Varemodtagelse, afstemning af leverancer og følgesedler og håndtering af restordrer Fakturamodtagelse, anvisning, attestering og kontering af fakturaer og automatisk betaling ved match af ordre og faktura Ad hoc opfølgning på indkøb (statistikker m.v. på brugerniveau, institutionsniveau, kommuneniveau) Kommunen anvender i dag indkøbssystemet TrueLink i samspil med det nuværende økonomi- BILAG 1 C - KRAVSPEFICIKATION SIDE 38
Navn for processen Indkøb og e-handel system. Krav til it-løsning Krav til it-løsning Der skal være oversigt over indlæste kataloger med mulighed for at bladre igennem et varekatalog Der skal være mulighed for at søge på bestemte typer oplysninger og foretage tværgående søgning på alle oplysninger Ved visning af varer, skal visning ske med en linje pr. vare i et oversigtsbillede. Liste over udsøgte varer skal kunne udskrives Ud fra listen over varer skal man kunne få adgang til mere detaljerede oplysninger om den enkelte vare fx ved klik på varelinjen Beskrivelse af varen skal indeholde billede og mulighed for mærkning, f.eks. miljømærke og energimærke Mulighed for oprettelse af favoritliste pr. bruger Ved bestilling af varer skal der være mulighed for at slette eller tilføje varelinjer Der ønskes mulighed for at EAN-nr, leverings- og faktureringsadresse er tilknyttet den enkelte bruger som default værdi Det skal være muligt at lægge de oftest anvendte konteringsoplysninger ind for hver bruger, således at disse foreslås på bestillingsoversigten når der bestilles Det skal være muligt at genere statistik på alle data på baggrund af såvel afsluttede som ikke afsluttede ordrer Øvrige krav: Mulighed for et aftalemodul, hvor samtlige indkøbsaftaler lægges ind og som minimum giver automatisk besked ved aftaleudløb Mulighed for udsøgning af indkøbsaftaler alfabetisk og efter produktgruppe Mulighed for et modul hvor der kan lægges indkøbstekniske oplysninger, nyheder, brugervejledninger ind Der skal være mulighed for at opdatere leverandørregistret ud fra oplysninger i CVRregistret Der skal være mulighed for konteringsoplysninger i form af kontonummer og egen posteringstekst på varelineniveau Der skal være mulighed for ved fakturabehandlingen at fordele fakturabeløb på flere konti Der skal på en leverandør kunne indsættes oplysninger om forskellige betalingsformer og betalingsvilkår. Betalingsvilkår fra leverandørregistret skal automatisk anvendes ved indløb BILAG 1 C - KRAVSPEFICIKATION SIDE 39
Navn for processen Indkøb og e-handel Afgivne ordre bør i økonomisystemet medtages som disponeringer ved beregning af råderum. Ved betaling skal disponeringen modregnes. Forud for betaling af en faktura ønskes at systemet foretager en søgning efter eventuelle kreditfakturaer på samme ordrenummer. I givet fald ønskes en bemærkning om, at udligning af de to fakturaer skal ske Økonomisystemet skal kunne udskrive anmærkningslister over udeståender, der ikke kan udlignes Økonomisystemet skal kunne udskrive betalingsoversigt og diverse statistik. Det skal være muligt at lave intern elektronisk afregning via e-bilag Til brug ved indkøbskontrol, skal der kunne udskrives afdelingsrapporter over indkøb samt en rapport til brug ved stikprøvekontrol af indkøb, hvor der udtrækkes alle indkøb til kontrol på tilfældige datoer. Indtastning af posteringstekst skal kunne gøres obligatorisk Der skal foregå automatisk opdatering af oplysninger mellem indkøbssystem og økonomisystem, herunder også ved opdatering af kontoplanen. Der ønskes øjeblikkelig virkning i økonomisystemet ved bogføring af blandt andet e- fakturaer. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 40
BILAG 1 C - KRAVSPEFICIKATION SIDE 41