Avtale om løpende tjenestekjøp (SSA-L)
Avtale om løpende tjenestekjøp (SSA-L)
Bilag 1:
Kundens kravspesifikasjon
Digitale politikere - rett på sak
Avtale om løpende tjenestekjøp (SSA-L) 1
1.2 Løsningsbeskrivelser og svar på kravene 4
1.2.1 Avtale om løpende tjenestekjøp (SSA-L) 5
2. Formål, rammer og omgivelser 9
2.5.1 Antall interne brukere 11
2.5.2 Antall eksterne brukere 11
3.2 Prosjekteiers virksomhetsmål 14
3.4 Resultatmål for leveransen 15
4.1 Utfordringer oppsummert: 17
4.2 Xxxx arbeider i Bystyresekretariatet 18
4.4 Hanne er 45 år og ordfører 26
6. Integrasjoner og grensesnitt mot andre systemer 33
6.1 Dagens løsning for politisk behandling 34
7.2 Moduler i “Digitale politikere” 37
I kapittel 1 blir det redegjort for oppbyggingen av dette dokumentet og hvilke vedlegg som følger med. Det redegjøres også for utfylling av kravtabellene, og hvilke svarkoder som skal benyttes. Her er også kravkodene forklart. Det samme er en del ord og begreper som benyttes hyppig i kravspesifikasjonen.
Innledningsvis (kapittel én og to) beskrives strukturen i bilaget og hvordan kunden ønsker at leverandøren besvarer kravspesifikasjonen. Videre blir formålet med prosjektet og rammer og omgivelser som leverandørene må forholde seg til beskrevet. Eksempler på dette er omfang, aktører som er involvert, overordnede prinsipper og føringer, og en oversikt over hvilke systemer som det kreves en integrasjon mot.
I kapittel tre blir det langsiktige målbildet beskrevet.
Kapittel fire beskrives dagens utfordringer, blant annet i form av brukerhistorier og brukerreiser. Dette gir et godt bilde av dagens arbeidsprosesser knyttet til den politiske beslutningsprosessen og møter i folkevalgte organer.
I kapittel fem er ønsket framtidig situasjon beskrevet.
I kapittel seks beskrives integrasjoner og grensesnitt mot andre systemer. Kapittel syv tar for seg arkitektur og teknologi.
I kapittel åtte gjengis kravene. Her gis også en forklaring på hvordan kravene er kategorisert og hvordan de skal besvares.
Til slutt, i kapittel ni og ti følger prosjekt- og framdriftsplan og betalingsplan. Følgende vedlegg følger dette dokumentet:
A. Trondheim kommunes arkitekturprinsipper
B. Trondheim kommunes sikkerhetsarkitektur
C. Statens standardavtale om løpende tjenestekjøp (SSA-L)
D. Databehandleravtale
1.2 Løsningsbeskrivelser og svar på kravene
Leverandøren har ansvaret for at løsningen dekker det overordnede behovet, selv om det overordnede behovet ikke skulle være kravstilt uttømmende gjennom konkrete krav i kravtabellene. Enhver mangel på oppfyllelse av målbilde og det overordnede behovet, må tas som
et klart og tydelig forbehold fra leverandøren når det gjelder evnen til å levere en tilfredsstillende løsning.
Leverandøren skal besvare følgende krav i Bilag 2 - Leverandørens beskrivelse av tjenesten:
● Funksjonelle krav
● Krav til produktkvalitet
● Krav til sikker utvikling
● Krav til driftstjenester
Leverandøren skal besvare følgende krav i de ulike bilagene:
● Krav til etableringsprosjektet
● Krav til tjenestenivå med standardiserte kompensasjoner
● Krav til administrative bestemmelser
● Krav til samlet pris og prisbestemmelser Dette er forklart nærmere i kap. 8.1
Svarene skal gis i tabellene. I tillegg skal leverandøren med egne ord, i bilag 2, beskrive hvordan løsningen skal bidra til måloppnåelse (jfr. kap. 3), hvordan utfordringene (jfr. kap. 4) skal løses og hvordan ønsket situasjon skal oppnås (jfr. kap.5).
1.2.1 Avtale om løpende tjenestekjøp (SSA-L)
Det kan leveres tilbud på “Avtale om løpende tjenestekjøp (SSA-L)”. Avtalen gjelder løpende levering av tjenester over internett («software-as-a-service»). Dette kan for eksempel være skytjenester/abonnementstjenester. Avtalen omfatter også drift og vedlikehold av den aktuelle tjenesten.
Under følger en forklaring og utdyping av begreper som blir brukt i dokumentet:
Sakspapirer/dokumenter:
Informasjon som presenteres i tekstform i politiske saker som leveres til politisk behandling. Disse består av et saksfremlegg og eventuelle vedlegg, som kan være kart, rapporter eller andre enkeltdokumenter. Sakspapirene kan også i enkelte tilfeller bli supplert med tilleggsnotater som inneholder tilleggsinformasjon og korrigering av eventuelle feil i opprinnelig
beslutningsgrunnlag. Saksdokumenter produseres i ESA8 og tilgjengeliggjøres for møtedeltakerne ved at de publiseres på kommunens innsynsportal.
Møtepapirer/dokumenter:
Informasjon som presenteres i tekstform til møter i folkevalgte organer. Disse består hovedsakelig av saksliste og møteprotokoll. Saksdokumenter produseres i ESA8 og tilgjengeliggjøres for møtedeltakerne ved at de publiseres på kommunens innsynsportal.
Protokoll:
Det er to typer protokoller; Møteprotokoll og saksprotokoll. Møteprotokollen er en sammenstilling av opplysninger fra et helt møte. Den inneholder type møte (for eksempel Formannskap), sted, dato, klokkeslett, hvem som er til stede og hvem som har forfall. Den inneholder også sakslisten. I
tillegg kommer alle sakene som er behandlet på rekke og rad med saksnummer, tittel, innstillingen i saken og deretter alle forslag som er fremmet, hvordan voteringen gikk og selve vedtaket.
Møteprotokollen produseres i ESA8 og arkiveres på arkivsaken som er opprettet på møtet (alle møter får et eget arkivsaksnummer)
Saksprotokollen er en sammenstilling av opplysninger om én enkelt sak. Den viser type møte (for eksempel Formannskap), sted, dato, klokkeslett. Den inneholder også innstillingen i saken, forslag som er fremmet, hvordan voteringen gikk og selve vedtaket. Saksprotokollen produseres i ESA8 og arkiveres på arkivsaken som er opprettet på selve saken. Saksprotokollen legges ved saksdokumentene til neste utvalg som skal behandle saken.
Politiske møter:
I dette dokumentet brukes begrepet “politiske møter” om Formannskapets, komiteenes, rådenes og bystyrets offisielle møter. Partimøter, og møter for partienes fraksjoner i komiteene, er ikke inkludert.
Bystyresekretariatet:
Sekretariatet administrerer og tilrettelegger for den politiske beslutningsprosessen. er også på mange måter “støtteapparatet” til politikerne. Har som oppgave å gjøre all praktisk tilrettelegging av politikernes arbeid, spesielt distribusjon av informasjon som gir grunnlag for beslutninger og praktisk tilrettelegging av politiske møter. Det er pr. dato 9 ansatte i Bystyresekretariatet.
Bystyresekretariatets kjerneoppgaver:
Begrepet ”kjerneoppgaver” brukes flere plasser i dette dokumentet. Bystyresekretariatets kjerneoppgaver er:
● Sekretariatsfunksjon for bystyret, bystyrekomiteene, formannskapet, bygningsrådet, kommunale råd, utvalg og nemnder
● Valgsekretariatsfunksjon (ansvarlig for praktisk gjennomføring av valg hvert andre år)
● Informasjon til publikum
● Tilrettelegging for representasjoner og mottakelser
● Håndtering av fritak og supplering av folkevalgte
● Arbeidsgiveransvar for folkevalgte
● Drift av ordførerens forkontor
Politikere:
Beslutningstakere. Folkevalgte i Trondheim bystyre som representerer befolkningen. Det er 10 politiske partier representert i Trondheim bystyret inneværende valgperiode. Bystyret består av 67 faste representanter. 11 av disse er heltidspolitikere. ledere og nestledere i bystyrets seks komiteer er frikjøpte i henholdsvis 40 og 20 prosent stillingsandeler.
Rådmann:
Rådmannen er kommunens øverste administrative leder. Begrepet rådmannen kan også brukes som en betegnelse på administrasjonens ansatte som opererer på vegne av han. For eksempel ansatte i rådmannens fagstab,
Ordfører:
Er valgt av bystyret som møteleder for bystyret og formannskap. Ordfører er rettslig representant for kommunen og undertegner på vegne av kommunen.
Varaordfører:
Er stedfortreder for ordfører.
Gruppeleder:
En politiker som har ansvar for sin gruppe bystyrepolitikere fra samme parti.
Fraksjonsleder:
Er partiets talsperson i for eksempel en komite.
Eventuelt:
Er betegnelsen på en post i møter som gir møtedeltakerne mulighet til å ta opp en sak/tema. Ofte sender politikerne inn ønske om å ta opp saker under eventuelt på forhånd, slik at administrasjonene kan forberede svar. Det opereres ikke med “eventuelt “ i bystyrets møter.
Votering:
Avstemning for å avklare flertall og mindretall i en sak. Resultatet av en votering ender i et vedtak som protokollføres. Gjennomføringen av voteringen protokollføres også.
Vedtak:
Er en politisk beslutning som er gjort i et folkevalgt organ.
Administrasjonen:
Rådmannen, rådmannens direktører og rådmannens stab. Disse er ansatt administrativt.
Innbygger:
Borgere i og utenfor Trondheim som blir berørt av de politiske beslutningene, samt andre innbyggere som kan ha interesse av å kjenne til innholdet i beslutningene.
Media:
Medier i og utenfor Trondheim som skriver om politikk i Trondheim. Eksempler på medier kan være radio, fjernsyn, aviser, nettaviser og annet.
Møteplan:
Er en oversikt for hele året som gir informasjon om møter i ulike folkevalgte organ. Oversikten lister opp møtene i kalenderrekkefølge. Planen har også oversikt over møtetid og sted. Det er formannskapet som vedtar møteplanen, og sekretariatet som legger den inn i møte- og utvalgsmodulen i ESA, slik at den også blir tilgjengelig på kommunens innsynsportal. Kalenderen gjør det også mulig for administrasjonen å sette opp en behandlingslinje for de ulike sakene i ESA, som skal oversendes politisk behandling.
ESA8 (Elektronisk sak og arkivsystem):
Trondheim kommunes saksbehandlingssystem. Vil bli faset ut fram mot 2019/2020 og erstattet av nytt system. EVRY, som er leverandøren av systemet, har signalisert at de ikke kommer til å videreutvikle løsningen slik den foreligger i dag. Løsningen har en egen møte- og utvalgsmodul med funksjoner som støtter administrasjonen av den politiske beslutningsprosessen. Det er besluttet at nytt framtidig saksbehandlingssystem også skal inneholde en slik modul.
Jupiter innsyn:
Kommunens nettportal der alle dokumenter knyttet til politiske saker og møter er publisert.
Begrepet “kommunens innsynsportal” benyttes også om samme. Her finnes også postliste med all korrespondanse inn og ut av Trondheim kommune, samt en søkemotor og oversikt over medlemmer i styrer, råd og utvalg. Publisering av dokumenter på innsynsportalen skjer via saksbehandlingssystemet ESA8, hvor dokumentene i utgangspunktet er produsert og arkivert.
TK Arkiv:
Trondheim kommune er i ferd med å innføre en ny frittstående arkivløsning som ikke er en del av saksbehandlersystemet i Trondheim kommune. Alle fagprogrammer som benyttes i kommunen skal i framtiden levere saker/dokumenter til dette arkivet.
Utvalg:
Med ”utvalg” menes folkevalgte organer som Bystyret, Formannskap, Bygningsråd, Klagenemnd, komiteer og kommunale råd. I dette dokumentet kan også begrepet “organer” være brukt om disse.
SRU:
Egen modul i ESA som inneholder oversikt over alle politiske utvalg og møtedatoer knyttet til disse. I tillegg registreres politiske partier og folkevalgte medlemmer i utvalgene og deres rolle i hvert utvalg. Data om utvalgene og medlemmene er grunnlaget for å presentere møtekalender og medlemmenes rolle i utvalget. Politikernes rolle er også grunnlaget for hvem som er stemmeberettiget i møte. Alle folkevalgte som legges inn i SRU-modulen i ESA blir automatisk synliggjort på kommunens innsynsportal.
2. Formål, rammer og omgivelser
I dette kapittelet beskrives bakgrunnen for at prosjektet er etablert og hva som er formålet. Her beskrives også dagens rammer og omgivelser.
Bakgrunnen for prosjektet er behovet for å automatisere og forenkle administrasjonen av
den politiske beslutningsprosessen, spesielt i forbindelse med gjennomføring av møter i folkevalgte organer. Det brukes i dag for mye ressurser på tungvinte manuelle operasjoner, opprydding og feilretting.
I konseptfasen, vinteren 2015, ble det gjennomført en forstudie, med blant annet kartlegging av dagens politiske beslutningsprosess og saksflyt. I rapporten, som ble utarbeidet av konsulentfirmaet Pricewaterhouse Coopers as, beskrives og analyseres situasjonen, og det anbefales syv innsatsområder i det videre arbeidet. De tre første ble anbefalt som såkalte
“prioriterte innsatsområder”:
1. Videreutvikle digitale verktøy og støttesystemer for politikerne
2. Digitalisere og automatisere aktiviteter knyttet til gjennomføring av møter
3. Styrke en effektiv og helhetlig saksgang og oppfølging av sakene
4. Behandling av saker i kommunale råd
5. Synliggjøring av politisk behandling for publikum
6. Teknisk publisering på Innsyn
7. Kvalitet i utforming av saksfremlegg
I rapporten fra forstudien (konseptfasen) blir det anbefalt at det opprettes et hovedprosjekt andre kvartal 2015, med målsettinger om løse de største utfordringene. Det anbefales at prosjektet ledes av Bystyresekretariatet.
Prosjekteier evaluerte rapporten fra forstudien høsten 2015, og sammenholdt disse med egne undersøkelser og erfaringer. I tillegg ble rapporten og prosjektets mulige målbilde drøftet med programledelsen i kommunens program for samordning av digitaliseringsprosjekter ”Digitalt førstevalg”. Konklusjonen ble at prosjektet skulle spisses og konsentrere seg om
innsatsområdene 1 og 2. De andre områdene er ikke prosjektorganisert men tatt inn som ordinære utviklingsoppgaver i linjeorganisasjonen.
Prosjektets formål er å inngå en avtale med en leverandør som Kunden kan samarbeide tett med for å utvikle og drifte en digital skyløsning som forenkler og automatiserer tungvinte manuelle operasjoner i forbindelse med gjennomføring av møter i folkevalgte organer.
Løsningen/-ene skal inneholde funksjoner innenfor dokument- og informasjonshåndtering, men også en rekke “møtetekniske” funksjoner, samt en “min side”- løsning for politikere. I tillegg skal
løsningen tilby brukergrensesnitt for administrator som blant annet gjør det mulig med enkel
saksbehandling samt muligheter til å ta ut rapporter og statistikk basert på data som produseres i løsningen.
Kunden har gjennom hele planleggingsfasen opplevd stor interesse fra andre kommuner og fylkeskommuner rundt prosjektet. Det er presentert for flere fylkeskommuner og på landsmøte for formannskapssekretærer i Norge. Mange kommuner og fylkeskommuner vil ha stor nytte av at det utvikles en slik løsning. Det finnes med andre ord et marked og et kommersielt potensial for et slikt produkt som bør kunne være av interesse for en leverandør.
Løsningen /-ene skal utvikles og testes i siste halvår 2018 og våren 2019. Den skal innføres fullt ut siste halvår 2019.
Hensikten med anskaffelsen er å oppnå både samfunnsmessige og ressursmessige gevinster.
Samfunnsmessige gevinster skal oppnås ved at lokaldemokratiet og den politiske styringen av kommunen blir styrket. Mer effektive og velfungerende møter i folkevalgte organer gir økt kvalitet på hele beslutningsprosessen og på de beslutningene som blir tatt.
Ressursmessige gevinster skal oppnås ved at administrasjonen av den politiske
beslutningsprosessen blir mer effektiv. Tungvinte manuelle operasjoner, ”tidstyver” og feilkilder i dagens system blir redusert. Både administrasjonen, sekretariatet og de folkevalgte får bedre arbeidsbetingelser. Prosjektet vil frigjøre tid til å styrke kvaliteten på sekretariatets kjerneoppgaver.
Det skal leveres tilbud på:
● Avtale om levering av løpende tjenester over internett («as a service» leveranser). Tjenesten omfatter også eventuell installasjon, konfiguering, samt tilpasning /og/eller integrasjoner som er spesifisert i dette bilaget.
EFFEKTER | INDIKATORER |
Møtekvaliteten har økt. Møter i folkevalgte organer er velfungerende og effektive | Positive resultater av observasjoner og analyser. Xxxxxx score på brukerundersøkelser |
Tidsbruken knyttet til administrasjon av møter er redusert | Positive resultater av observasjoner og analyser. Positive resultater fra tidsbruksanalyser |
Tidsbruken knyttet til opprydding og feilretting er betydelig redusert | Positive resultater av observasjoner og analyser. Registrert reduksjon i antall avviksmeldinger og klager |
Tidsbruken knyttet til opplæring og brukerstøtte er betydelig redusert | Positive resultater fra tidsbruksanalyser |
Det er mindre stress og slitasje blant ansatte | Redusert sykefravær. Xxxxxx score på medarbeiderundersøkelser |
Kvaliteten på sekretariatets kjerneoppgaver har økt | Xxxxxx score på bruker- og medarbeiderundersøkelser |
Tabell 3
I kommuneplanen heter det at Trondheim kommunes verdier; åpen, kompetent og modig, er veiledende i møtet med innbyggere, brukere, samarbeidspartnere og media. Prosjektet ”Digitale politikere – rett på sak” skal bidra til at kommunen framstår som kompetent og modig ved å utnytte de mulighetene som ligger i ny teknologi og ta i bruk effektive digitale verktøy i tilknytning til de politiske beslutningsprosessene.
Prosjektet er en del av kommunens program ”Digitalt førstevalg”, og har en klar forankring i ett av programmets strategiske mål:
● Nettbaserte tjenester skal komme som erstatning for manuelle og tungvinte arbeidsmetoder
Prosjektets målsettinger har også en tydelig forankring i Bystyresekretariatets visjon: ”Fremst innen rådgivning og digitalisering blant de politiske sekretariat i Norge”. Prosjektet er forankret i følgende enhetsmål:
● Bidra til politisk styring av Trondheim kommune ved å legge til rette for effektive og kvalitetssikrede arbeidsprosesser
● Utvikle sekretariatets rolle mot mer rådgivning og støtte
● Enhetens medarbeidere fremstår med faglig stolthet og representerer en offensiv kultur preget av engasjement og utvikling
Interne brukere av en ny digital løsning vil være medlemmer og varamedlemmer i alle folkevalgte organer, politiske rådgivere samt bystyresekretariat og deler av rådmannens fagstab.
Hvem | Antall personer |
Medlemmene i folkevalgte organer | 121 |
De øverste varamedlemmene i folkevalgte organer | 50 |
De politiske rådgiverne | 7 |
Bystyresekretariatet | 9 |
Rådmannens strategiske ledelse | 7 |
Rådmannens fagstab | 26 |
SUM | 220 |
Tabell 4
Det vil ikke være eksterne brukere. Innbyggere og media benytter kommunens hjemmesider, innsynsløsning og streaming av politiske møter på nett, for å følge den politiske beslutningsprosessen
Det er 121 faste medlemmer og 147 vararepresentanter fordelt på 15 folkevalgte organer (tabell 5) i Trondheim. Hvis vi kun regner med de øverste vararepresentantene (ca. 50 personer) så vil det være ca. 170 folkevalgte brukere som jevnlig skal logge seg inn på en framtidig digital løsning. I tillegg kommer politiske rådgivere, ansatte i bystyresekretariat og rådmannens fagstab.
I tabell 5 har vi tatt utgangspunkt i at hver enkelt bruker i gjennomsnitt logger seg inn fire ganger i tilknytning til et møte (forberedelser og gjennomføring). Estimert antall innlogginger til møter blir da ca. 1300 pr. mnd. eller 15 612 pr. år. På det meste (i bystyret) kan være opptil 80 samtidige brukere. Dette er et grovt estimat.
Tabell 5 viser antall medlemmer og antall møter pr. mnd i de ulike organene. Tabellen viser også estimert antall innlogginger pr. mnd i de samme organer. Formannskapet har for eksempel 11 medlemmer og 5 sekretærer og saksbehandlere som er involvert i møtet. Disse 16 personene logger inn fire ganger hver, tre ganger pr. mnd. Det gir totalt 192 innlogginger.
Organ | Faste medl. | Vara | Råd givere | Møter pr. Mnd. | Sekretærer og saksbeh. | Innlogginger pr. Mnd. |
Bystyret | 67 | 97 | 1 | 10 | 308 | |
Formannskap | (11) | (22) | 3 | 5 | 192 | |
Bygningsråd | (11) | (22) | 2 | 5 | 128 | |
Byutviklingskomiteen | (11) | (24) | 1 | 3 | 56 | |
Klagenemnd | (5 ) | (10) | 2 | 3 | 64 | |
Finans- og næringskomiteen | (9) | (22) | 1 | 3 | 21 | |
Helse og velferdskomiteen | (11) | (29) | 1 | 3 | 56 | |
Kirke, idrett- og friluftslivskomiteen | (9) | (25) | 1 | 3 | 48 | |
Oppvekstkomiteen | (11) | (23) | 1 | 3 | 56 | |
Kontrollkomiteen | (5) | (11) | 1 | 3 | 32 | |
KFU | 6+ (3) | 6+ (3) | 1 | 3 | 48 | |
Mangfoldsrådet | 6+ (3) | 6+ (3) | 1 | 3 | 48 | |
Studentrådet | 6+ (2) | 2+ (2) | 1 | 3 | 64 | |
Trondheim seniorråd | 6+ (3) | 6 + (3) | 1 | 3 | 48 | |
Ungdommens bystyre | 30 | 30 | 1 | 3 | 132 | |
SUM PR. MND. | 19 | 1301 | ||||
SUM ROLLER/VERV | 215 | 346 | 7 | 56 | ||
SUM PERSONER | 121 | 147 | 7 | 25 |
Tabell 5: Medlemmer og varamedlemmer i bystyret er samtidig medlemmer og varamedlemmer i komiteer, råd og utvalg. Derfor skil les det mellom antall roller/verv og antall personer. Tall er satt i parantes fordi disse personene også er talt med i ”Bystyret” . I kolonne “antall innlogginger” tas utgangspunkt i roller/verv og et anslag på fire innlogginger pr. person pr. møte.
I tabell 6 beskrives hvilke rolle de ulike aktørene har og hvilke type samhandling som skjer mellom aktørene.
Interessenter/ Roller | Beskrivelse | Type samhandling |
Folkevalgte og rådgivere | ● Mottar, åpner og leser saks- og møtedokumenter ● Arbeider i saks- og møtedokumentene; Blar i og mellom saker, skriver notater, lager understrekninger og uthevinger ● Xxxxxxx skriftlige forslag og spørsmål ● Mottar svar på innsendte spørsmål ● Deler og arkiverer notater, forslag, spørsmål ● Melder seg på taleliste ● Voterer ● Melder forfall ● Søker opp tidligere saker og dokumenter | Direkte dialog, E-post |
Ordfører | ● Setter opp/godkjenner saksliste til formannskap, bygningsråd og bystyret ● Kvalitetssikrer prosess/saksflyt ● Møteleder i formannskap, bygningsråd og bystyre | Koding i ESA, direkte dialog og e-post |
Bystyresekretariat | Administrerer og organiserer saksflyten (på politisk nivå) og den politiske beslutningsprosessen: - Produserer og formidler saks- og møtedokumenter - Kvalitetssikrer prosess/saksflyt - Praktisk tilrettelegging av møter - Ivaretar sekretærfunksjonen i folkevalgte organer, skriver protokoll | Koding i ESA, direkte dialog og e-post |
Rådmannens strategisk ledelse og fagstab | ● Utreder saker, skriver saksframlegg og forslag til vedtak. Legger fram saker for politisk behandling ● Svarer på innsendte spørsmål fra politikerne og legger fram tilleggsnotater til politiske møter ● Effektuerer vedtak ● Utreder saker og skriver saksframlegg | Koding i ESA, direkte dialog og e-post |
Trondheim Byarkiv | Er systemeier av ESA8, ESA Windows, Jupiter innsyn, TK Arkiv. Noe brukerstøtte. | Direkte dialog og e-post |
Tabell 6
I dette kapittelet blir det langsiktige målbildet beskrevet. Leverandøren har ansvaret for at løsningen bidrar til måloppnåelse, selv om leveransen ikke skulle være kravstilt uttømmende i kravtabellene. Leverandøren skal på selvstendig grunnlag levere løsninger som bidrar til måloppnåelse.
Enhver mangel på oppfyllelse av de overordnede målene må tas som et klart og tydelig forbehold fra leverandørens side når det gjelder evnene til å imøtekomme kundens overordnede behov.
● Prosjektet har bidratt til å styrke lokaldemokratiet og sikre sentrale demokratiske verdier som åpenhet, offentlighet og innsyn, medvirkning og deltakelse.
● Prosjektet har lagt til rette for høy kvalitet på de politiske arbeidsprosessene og beslutningene som blir tatt.
● Satsingen har bidratt til å styrke den politiske og demokratiske styringen av kommunen.
3.2 Prosjekteiers virksomhetsmål
Bystyresekretariatet skal bidra til politisk styring av Trondheim kommune ved å legge til rette for effektive og kvalitetssikrede arbeidsprosesser. Bystyresekretariatets rolle skal utvikles mot mer rådgivning og støtte.
Bystyresekretariatets visjon er å være fremst innen rådgivning og digitalisering blant de politiske sekretariat i Norge.
● Politikere, administrasjonen og publikum opplever effektive og velfungerende møter i folkevalgte organer.
● Politikerne og administrasjonen opplever rask og enkel tilgang til alle saker og møtedokumenter.
● Sekretariatet og administrasjonen opplever at den politiske beslutningsprosessen er oversiktlig og enkel å administrere.
3.4 Resultatmål for leveransen
Det er i løpet av 2019 tatt i bruk en ny digital skyløsning, som automatiserer og forenkler administrasjonen og gjennomføringen av møter i folkevalgte organer. Løsningen skal være universelt utformet, intuitiv og brukervennlig og inneholde funksjoner spesielt knyttet til
● Dokument/informasjonshåndtering
● Søking og gjenfinning
● Lagring og deling
● Håndtering av forslag og spørsmål
● Håndtering av oppmøte og forfall
● Styring av taleliste og taletid
● Elektronisk votering
● "Min side" for politikerne
● Enkel saksbehandling
● Uttak av rapporter
I dette kapittelet beskrives dagens situasjon og utfordringer både gjennom tekstlige beskrivelser og brukerfortellinger. I tillegg er brukerreisen til tre sentrale brukere illustrert, når de skal delta på et møte i et folkevalgt organ.
I forbindelse med møter i folkevalgte organer brukes alt for mye ressurser på tungvinte manuelle operasjoner, opprydding og feilretting. Det er svært mange manuelle operasjoner og veksling mellom ulike systemer/programmer i tilknytning til produksjon og publisering av møte- og saksdokumenter. Det er også mye ”klipp og lim” når det skal skrives møteprotokoll.
Administrasjonen og sekretariatet mangler også muligheter til enkelt å kunne ta ut rapporter og statistikk fra den politiske beslutningsprosessen. Det være seg oversikt over antall saker som er behandlet i de ulike organene, antall forslag som er fremmet og hvem som har fremmet dem, oversikt over hvor mange innlegg som er holdt eller totaloversikt over forfall og oppmøte.
Det er også en utfordring at mesteparten av kommunikasjon og informasjonsflyt skjer via e-post. Innkalling til møter, eller varsel om møter, skjer ved at sekretariatet sender ut e-post umiddelbart etter at alle møtedokumentene er publisert på kommunens innsynsløsning. Det finnes ikke noe system for automatisk varsling til møtedeltakerne.
Innsending av forslag og spørsmål i sakene som skal behandles skjer også via e-post. Det betyr at sekretariatet må ”overvåke” postmottaket kontinuerlig slik at videreformidling og eventuell publisering kan skje raskt. Allikevel opplever mange møtedeltakere at de forslagene som de sender inn til en sak ikke blir tilgjengelig for de andre møtedeltakerne raskt nok.
Meldinger om forfall, meldinger om ønsket om habilitetsvurdering, saksbehandling av dette og innkalling av varamedlemmer skjer også via e-post. I tillegg til at dette er et tidkrevende arbeid, er det uheldig at offentlig saksbehandling i forbindelse med forfallshåndtering og habilitetsvurderinger skjer i et e-postsystem.
I tillegg opplever folkevalgte, administrasjon og publikum at kvaliteten på møtene kunne vært bedre. Dårlige møter kan gi politikken et dårlig omdømme og tilliten til lokaldemokratiet og folkestyret kan svekkes. Beslutningenes legitimitet kan også bli svekket. Møtelederne i de ulike organene har ingen IT-støtte som kan bidra til tydelig og effektiv møteledelse. Voteringer i bystyret håndteres for eksempel gjennom et eldre nettbasert voteringssystem som det ikke er vedlikeholdsavtale på. Systemet fungerer dårlig. Svært ofte må ordfører gå over til manuell votering på grunn av feil eller fordi det elektroniske voteringssystemet ikke ”henger med” i tempoet.
Manglende integrasjon mellom voteringssystemet og saksbehandlingssystemet ESA gjør at alle vedtak det skal voteres over må legges inn manuelt to ganger.
For møteledere kan det også være utfordrende å ha oversikt over alle innsendte forslag, spørsmål og tilleggsnotater, samt lister med forfall og habilitetsvurderinger, samtidig som møtet skal ledes på en ryddig og tydelig måte.
Mange folkevalgte ønsker rask og enkel tilgang til møte- og saksdokumenter uten at de må laste
dem ned. Det finnes ingen muligheter i dag for raskt å kunne ta opp saksutredningene direkte i nettleseren og samtidig kunne filtrere informasjonen i dem slik at man bare får opp de delene av saksframlegget man ønsker å lese. Man har ingen muligheter til for eksempel å ta opp bare innstillingen og sammendraget i en sak. Det er alt eller ingen ting. Brukerne må i dag veksle mellom flere ulike systemer, programmer og digitale enheter når de forbereder seg eller deltar i møter.
Informasjon og møtetekniske funksjoner (votering, taleliste) er ikke tilgjengelig på ett sted på en oversiktlig og brukervennlig måte.
Mange opplever det som vanskelig å finne igjen tidligere saker som er behandlet, eller forslag som er fremmet i tidligere saker. Mange folkevalgte sletter sine innlegg, notater og forslag i etterkant av møtene, eller lagrer dem tilfeldig, slik at de blir vanskelige å finne tilbake til.
● Det er mange tungvinte manuelle operasjoner og mye veksling mellom ulike systemer/programmer i tilknytning til forfallshåndtering. Mye av håndteringen skjer via e- postsystemet, men i tillegg benyttes både telefon og SMS, samt at saksbehandlingen av forfallsmeldinger og habilitetsspørsmål skjer i ESA. Det oppleves som svært tungvint og tidkrevende
● Det er mange tungvinte manuelle operasjoner og veksling mellom ulike systemer/programmer i tilknytning til innsending av forslag og spørsmål samt tilgjengeliggjøring og videre håndtering av disse
● Administrasjonen og sekretariatet mangler muligheter til enkelt å kunne ta ut rapporter og statistikk fra den politiske beslutningsprosessen. Det kan for eksempel være voteringsstatistikk, forfallsoversikt, taleoversikt, forslagsoversikt ol.
● Nesten all kommunikasjon i tilknytning til administrasjon og gjennomføring av møter skjer via e-post. Det betyr blant annet at sekretariatets postmottak må ”overvåkes” kontinuerlig for rask videreformidling eller oppfølging av post.
● Kvaliteten på møtene kunne vært enda bedre. Det mangler IT-støtte for tydelig og effektiv møteledelse. Det nettbaserte voterings- og taletidsanlegget i Bystyret har betydelige svakheter og er krevende å administrere. De andre utvalgene mangler voterings- og taletidsanlegg.
● Den eneste måten å lese møte- og saksdokumenter på er å laste dem ned som pdf- dokumenter fra kommunens innsynsportal. Det finnes ingen muligheter for å for eksempel lese dem direkte i nettleseren. Det er som en følge av dette (?) heller ikke mulig for møtedeltakerne å selektere eller filtrere saksframleggene, hvis man for eksempel ønsker å kun se “sammendrag” og “konklusjon”.
● Forslag, innlegg og notater som folkevalgte sender inn til en sak eller et møte kan være vanskelig for dem å finne igjen i ettertid på en enkel måte
● Det er vanskelig å finne igjen tidligere saker og forslag, eller andre saker som kan være relevante for den saken som behandles.
● Brukerne må i dag veksle mellom flere ulike systemer, programmer og digitale enheter når de forbereder seg eller deltar i møter. Informasjon og møtetekniske funksjoner (votering, taleliste) er ikke tilgjengelig på ett sted på en oversiktlig og brukervennlig måte
● Møtedeltakerne finner ingen oppdatert oversikt digitalt over forfall, innhabiliteter og varamedlemmer som møter. Sekretariatet har ingen digitale verktøy som gjør det mulig å kunne produsere og oppdatere forfallslislister fortløpende og gjøre dem tilgjengelig for møtedeltakerne i sanntid.
Brukerfortellingene- og reisene under illustrerer hvordan arbeidsprosessene er i dag, og hva som er
utfordrende.
4.2 Xxxx arbeider i Bystyresekretariatet
Xxxx har jobbet i Bystyresekretariatet i mange år. Hun har erfaring helt tilbake fra den tid da alle dokumenter ble kopiert og sendt ut på papir. Xxxx har hele tiden vært interessert og åpen for nye måter å gjøre ting på. Hun har vært med på utviklingen der sekretariatet og politikerne har gått over til å jobbe mer digitalt.
Nå føler hun imidlertid at de tekniske løsningene hun bruker i jobben er blitt gammeldagse og lite hensiktsmessig å bruke. Avklaringer som skal gjøres i forkant av møter i formannskap og bystyret blir gjort på e-post. Det oppleves som tungvint og fører blant annet til at mange beskjeder ikke blir delt med alle som er involvert. Nesten all kommunikasjon i forbindelse med møter skjer via e-post. Derfor må hun kontinuerlig følge med i postmottaket, også utenfor arbeidstid, for å raskt kunne videreformidle eller følge opp post.
Xxxx syns også at mange av arbeidsoperasjonene som gjøres i forbindelse med innkalling til for eksempel formannskapet er tungvinte og lite rasjonelle. Selve innkallingen med saksliste lager hun som worddokument i kommunens saksbehandlersystem ESA8. Når sakslisten er ferdig skrevet må dokumentet konverteres til pdf-dokument og publiseres på kommunens innsynsportal ”Jupiter innsyn”. Deretter må hun via e-post varsle møtedeltakerne om at innkallingen er publisert.
Xxxx må også ”sy sammen” alle de forskjellige dokumentene (saksframlegg og vedlegg) som kommer fra rådmannen til et pdf samledokument. Samledokumentet inneholder alle dokumenter til et møte. Dette er politikernes viktigste dokument. Dokumentet har et ”tre” i venstre marg som gjør det lett å manøvrere i dokumentet, og de kan markere tekst, lage understrekninger, skrive notater og dele disse med andre. Noen ganger er dokumentet så stort at det må sendes til Byarkivet for å bli komprimert.
Xxxx opplever at ESA8 og Jupiter innsyn ikke alltid virker godt nok sammen, og forsinkelser på publiseringen er relativt vanlig. Xxxx føler at hun, oftere enn hun synes er greit, må jobbe etter ordinær arbeidstid for å se til at alle dokumentene vises på innsyn. Xxxx syns det er tungvint at Jupiter Innsyn oppdateres bare to ganger pr. døgn og at hun må logge seg på som publisist og oppdatere innysynsportalen manuelt for at dokumentene skal legges seg ut.
Svært ofte sender rådmannen over tilleggsnotater i dagene fram mot møtestart. Disse kommer etter at de ordinære møtedokumentene er produsert og publisert, og inneholder tilleggsinformasjon i sakene som skal behandles eller svar på spørsmål som er kommet inn fra politikere knyttet til sakene på saklista. Disse spørsmålene fra politikerne har rådmannen mottatt på epost, videreformidlet via Anne. Tilleggsnotatene kommer ofte med vedlegg som separate dokumenter.
Xxxx benytter Adobe Acrobat X - pro til å «sy sammen» slike tilleggsnotater til ett dokument pr. sak, før de lagres ii ESA og publiseres på Innsyn. Xxxx syns dette er arbeidskrevende og også sårbart, siden det er en viss risiko for at man i prosessen kan ”rote bort” et notat, og dermed mangle viktig saksinformasjon på innsyn. Risikoen for dette er størst når det er travelt på jobb, og man gjør mange ting på en gang.
Det kan også bli meldt inn spørsmål fra politikerne som ikke angår noen av sakene på sakslista, og som havner under møtets eventueltpunkt, eller spørsmålsoversikt hvis det gjelder bystyret (bystyret opererer ikke med punktet “eventuelt”). Dette kommer som e-post. Xxxx videreformidler også disse
spørsmålene til rådmannen som utarbeider et skriftlig svar. Rådmannen arkiverer sitt svar som et notat i ESA. Spørsmålene som Xxxx har mottatt limer hun inn i forslagsheftet (se under) og publiserer dette nok en gang slik at alle møtedeltakerne også kan se dem. Etter møtet mottar Xxxx svarnotatene rådmannen har laget i ESA, og sørger for at disse også blir arkivert på møtesaken i ESA.
Xxxx må også produsere og publisere forslagsheftet. Forslagheftet er et dokument som inneholder alle forslagene og spørsmålene som politikerne sender inn i forkant av et møte. Forslagene mottas på e-post. Xxxx xxxxxxx ut og limer dem inn i worddokumentet som hun har kalt forslagshefte. Hun må ofte formatere teksten slik at dokumentet blir oversiktlig og enhetlig. Deretter konverterer hun heftet til et pdf-dokument som hun til slutt publiserer på hjemmesiden til Formannskapet. Kort tid etter kan hun motta nye forslag, og må gjenta operasjonen. Politikerne forventer at deres forslag raskt blir publisert og gjort tilgjengelig for de andre møtedeltakerne. Derfor må Xxxx ”overvåke” postmottaket kontinuerlig. Det syns hun er vanskelig. Det er ikke uvanlig at forslag blir sendt inn utenfor arbeidstiden.
Xxxx mottar også meldinger om forfall til møtene. Også dette skjer via e-post. Det er fire begrunnelser for forfall: Sykdom, velferd, bortreist og presserende arbeid. Ut fra angitt forfallsgrunn vurderer Xxxx om forfallet om det er gyldig eller ikke. Om det er gyldig forfall, som det ofte er, blir det godkjent og representanten blir varslet om det via e-post. Jobben videre blir da å skaffe en vararepresentant som kan møte. Innkalling av vara skjer via e-post etter rekkefølgen representantene er valgt inn i. Det innebærer at hun må følge en bestemt rekkefølge for å få en møtende vararepresentant. Arbeidet med å skaffe vararepresentanter er et ressurskrevende arbeide. Arbeidet er regelstyrt og det er viktig at både forfallsmeldingen og tilhørende korrespondanse blir dokumentert og arkivert. Selv om det ikke skjer ofte, så hender det at Xxxx mottar innsynsbegjæringer. Xxxx syns det er dumt at håndtering av forfall og innkalling av vararepresentanter utføres uten noen form for automatisering. Det fører også til unødvendig stress opp mot møtestart, i de tilfellene representanter melder forfall veldig tett opp mot møtet. Det er mange manuelle arbeidsoppgaver som blir utført og det krever mye arbeidsressurser i tidsforløpet fram til møtestart som kunne vært brukt til mye mer fornuftig.
Under møtene fører Xxxx møteprotokoll i Microsoft Word, som åpnes via integrasjon med ESA8. Utkast til protokoll har hun laget på forhånd. ESA8 har en funksjon der det automatisk genereres protokoll som inneholder saksliste samt innstilling og forslag til vedtak i hver enkelt sak. Noe annen tekst og overskrifter er også ”ferdig utfylt” når protokollen produseres. Selv må hun legge inn navnene på møtedeltakerne, hvilke forslag som fremmes, voteringsresultat og endelig vedtak i hver sak. Hun kunne gjerne ha tenkt seg enda mer automatisk utfylling av møteprotokollen. Alle forslagene som fremmes og som det voteres over burde etter hennes mening automatisk kunne legge seg til i møteprotokollen av seg selv.
I tillegg til å følge med hva politikerne sier og vedtar under møtene, må Xxxx i tillegg overvåke postmottaket under hele møtet. Politikerne sender inn forslag også under selve møtet, og hun får ikke tid til å innarbeide disse i forslagsheftet. Men det er hennes oppgave å raskt videreformidle slike mailer til de andre deltakerne i møtet. I den senere tid har hun opprettet delingsdokument i Google, der møtedeltakerne skriver sine forslag direkte inn, slik at de kan ses av de andre i sanntid. Det er en bedre løsning syns Xxxx. Men hun syns ikke det er et fullgodt system. Spesielt i møter med mange deltakere blir det ofte kaos i et slikt delingsdokument.
Når et møte er avsluttet starter Xxxx med etterarbeidet.
Da endrer hun behandlingsstatus på hver enkelt sak i ESA, for eksempel fra S (satt på sakskartet) til B (behandlet) eller U (utsatt). Deretter ferdigstiller hun utkast til protokoll, og sender den på e-post til møteleder for godkjenning. Når møteleder har godkjent den, ferdigstiller hun møteprotokollen i ESA og publiserer den på Jupiter Innsyn. Hun må være nøye med å kontrollere alle bokmerker i møteprotokollen. Hvis bokmerkene ikke står riktig, risikerer hun at saksdokumentene til for eksempel en komité eller til bystyret som produseres to uker etterpå, ikke henter inn de nødvendige informasjonselementene fra møteprotokollen. Når hun er ferdig med dette produserer hun saksprotokoller for hver enkelt sak. Disse publiseres også på Jupiter Innsyn.
Til slutt arkiverer Xxxx svar og tilleggsnotater som rådmannen som har levert til møtet, og publiserer disse på Jupiter Innsyn. Hun publiserer også powrpointpresentasjoner som er holdt på formannskapets hjemmeside.
Illustrasjon 1 under viser Xxxxx brukerreise når hun skal forberede og gjennomføre et møte i Formannskapet. Brukerreisen er relativt lik de andre sekretærenes brukerreise når de forbereder og gjennomfører møter i andre folkevalgte organer. En del av operasjonene som er beskrevet i tabellen gjentas flere ganger.
ssa-L Bilag 1 Kundens kravspesifikasjon 21
Illustr
asjon 1
Per er 27 år og er nylig valgt inn i bystyret. Han har jobb i det private næringsliv, i litt redusert stilling da han har fått vervet som komiténestleder. Komitenestlederne er frikjøpt til å utføre sine oppgaver tilsvarende 20 % stilling. På fritida er han engasjert i bydelens idrettslag der han sitter i styret.
Per er gift og har to små barn. Han føler derfor at han må bruke tida som han har til politikk effektivt og rasjonelt. Av Trondheim kommune har han fått en pc og kommunal e-postadresse.
Utfordringen til Xxx er at det blir vanskelig å holde oversikt over innkallinger til møter, forslag som fremmes, tilleggsnotater som dukker opp, beskjeder som kommer fra Bystyresekretariatet, partiet og bystyrekolleger osv. I tillegg skal han sette seg inn i alle sakene som behandles. Det er et betydelig antall dokumenter som skal gjennomgås. Per syns det er dumt at han må gå inn på kommunens innsynsportal og laste ned alle dokumentene som pdf-fil for å få lest dem. Han kunne tenkt seg å lese sakene direkte på PC´en uten å måtte laste ned. Siden det er så mange og lange dokumenter skulle han gjerne ha sett at han kunne åpne bare deler av dokumentene for å lese dem. Han mener at han kunne ha skaffet seg bra oversikt over sakene ved å bare åpne sammendraget og konklusjonen i hver enkelt sak.
I bystyremøtene synes Per det er veldig uhensiktsmessig å bruke voteringsanlegget til voteringene. Det er tregt og ofte klarer det ikke å henge med i voteringstempoet. Da må ordføreren gå over til manuell votering. Generelt mener Xxx at voterings- og talestyreanlegget i bystyret er veldig gammeldags. Voteringsenhetene er veldig ustabile i nettverket. Det gjør at han ofte må ha hjelp for å få kobla seg på igjen.
Når det gjelder å tegne seg på talerlista, til innlegg og replikk, synes han systemet fungerer fint. Han har en egen liten enhet (pad) liggende på sin plass. Han kan bare trykke på en knapp, og navnet hans kommer raskt opp på talelista. Skjermene som henger i bystyresalen gir fin oversikt over talelisten og taletiden.
Men Per synes at det er veldig tungvint og uhensiktsmessig at det tar så lang tid fra et forslag er sendt inn til det blir tilgjengelig for de andre møtedeltakerne. Han vil gjerne at de forslagene han sender inn skal bli tilgjengelig for de andre deltakerne umiddelbart. Slik det fungerer nå må han sende inn sine forslag til Bystyresekretariatet på e-post. Det tar ofte litt tid før han finner igjen forslaget sitt i forslagshefte som blir publisert på komiteens nettside. Bystyresekretariatet må sette forslaget inn i et worddokument, som deretter blir konvertert til pdf og manuelt publisert på nettsidene. Så han skjønner at det tar tid. Men han ønsker seg et annet system. En del av arbeidet med formuleringen av forslag gjør Xxx sammen med andre, enten i dialog eller på e-post. Han syns E-post er veldig dårlig egnet verktøy til å jobbe med slikt. Det er vanskelig å styre informasjon til riktige personer og grupper. Per syns at det hadde vært fint med et mye mer hensiktsmessig arbeidsverktøy der informasjon kunne deles og bli utvekslet i sanntid.
Under selve avviklingen av møte er det de samme utfordringene med innsending og utveksling av forslag. Han syns det er krevende å holde oversikt over forslagene som er fremmet og som fremmes under debatten.
Som nestleder i en komité hender det at han må lede komitemøter. Da skulle han gjerne hatt bedre
IT-støtte som kunne ha hjulpet han til å lede møtene ryddig og effektivt. Det gjelder oversikt over forfall og oppmøte og det gjelder talelistestyring. Noen ganger kommer det inn mange forslag i en sak, under møtet, samtidig som saken behandles. De kan komme på lapper eller bare bli framført muntlig. Det syns han er krevende. Spesielt når det skal voteres over innstillingen og alle forslagene. Også her skulle han gjerne hatt en form for IT-støtte.
Når Xxx skal delta i komitemøte får han en e-post fra Bystyresekretariatet som minner om møtet og med lenke til Jupiter Innsyn der innkalling, saksframlegg og eventuelle tilleggsdokumenter er publisert som pdf-dokumenter. Det synes han er en veldig god ordning. Han har da en uke på seg til å lese og forberede seg til møte i komiteen. Som regel lagrer han alle dokumentene på sin egen PC, slik at han kan ta dem opp når har er på hytta hvor det ikke er internett. Men også her syns han det er dumt at han må laste ned alle dokumentene. Det hadde vært bedre å lese dokumentene direkte i nettleseren uten å måtte laste dem ned.
Mandag i møteuka har Per møte med sine partikollegaer (fraksjonen) i komiteen. Da kommer det ofte opp spørsmål og andre ting som må diskuteres. Ganske ofte fører det til et eller flere spørsmål til rådmannen, som de ønsker svar på før møtet. Spørsmålene sender han inn på e-post til Bystyresekretariatet, som videreformidler til rådmannen. Han forstår ikke helt hvorfor han ikke kan sende dem direkte til rådmannen, uten forsinkende mellomledd. I og med at det ”bare” er en uke mellom at innkallingen blir sendt ut og møte avholdes er det mye som må avklares på kort tid. Han har tatt opp dette med Bystyresekretariatet. De svarte at alle spørsmål som blir stilt, skal gjengis i forslagsheftet som de har ansvar for å utarbeide og publisere. Da må de få spørsmålene tilsendt.
Noen ganger må Per melde forfall til møter. Dette melder han også via e-post til Bystyresekretariatet. Sekretariatet gir tilbakemelding og bekrefter om forfallet er godkjent eller ikke. Noen ganger får han beskjed om at hans forfallsmelding ikke er godt nok begrunnet. Da utdyper han begrunnelsen og sender ny e-post. Han vet at også vararepresentantene kan melde forfall og at sekretariatet ofte kommer langt ned på varalista før de lykkes i få på plass en vararepresentant. Det blir svært mange e-poster fram og tilbake.
Illustrasjon 2 under viser Xxxx brukerreise når han skal delta på et møte i Bystyret. Xxxxxxxxxxxx er relativt lik de andre politikernes brukerreise når de skal delta på møter i andre organer. En del av operasjonene som er beskrevet i tabellen gjentas flere ganger.
2
4.4 Hanne er 45 år og ordfører
Xxxxx er 45 år og ordfører. Hun leder ukentlig møter i formannskapet/bygningsrådet og leder bystyrets møte en gang i måneden. Disse møtene må hun være godt forberedt til, og under møtene må hun kjenne alle forslag som er kommet inn i sakene som behandles, siden det er hun som skal lede voteringen i sakene. Hun må også ha god kontroll på hva som er rådmannens eller komiteens forslag til vedtak i saken, og sakenes innhold, siden hun selv også er møtedeltaker. Det er også hennes oppgave å holde orden på talelisten og styre ordskiftet.
Arbeidsdagene hennes er hektisk med mange møter og representasjonsoppdrag. Hun er mye ute av kontoret, og bruker smarttelefonen og nettbrettet sitt mye til å lese sakspapirer, forslag og annen korrespondanse og til å kommunisere med andre politikere og med sekretariatet. Hanne er derfor avhengig av å kunne nå sakspapirer også utenfor kontoret for å kunne gjøre jobben sin. Det hender også at Xxxxx må lese sakspapirer sent på kvelden og tidlig på morgen for å rekke å forberede seg så godt som hun vil. Hun rekker sjelden å lese alle saksdokumentene fra start til slutt. Men ofte scroller hun seg gjennom sidene og finner fram til kapitlene ”sammendrag” og ”konklusjon”. Ved å lese disse kapitlene får hun et bra inntrykk av hva sakene handler om.
Hanne syns det fungerer greit å laste ned møte- og saksdokumentene som pdf-dokumenter fra innsynsportalen. Men ofte er dokumentene så store og tunge at det tar lang tid å laste dem ned. I tillegg tar de opp mye lagringsplass. I mange tilfeller trenger hun heller ikke disse dokumentene etter at møtet er ferdig. I tillegg til å kunne laste ned dokumentene ved behov, skulle hun gjerne hatt muligheten til å lese gjennom saksdokumentene direkte i nettleseren, og på en enkel måte klikke seg fram til de mest interessante kapitlene i hver enkelt sak som for eksempel ”innstilling”, ”sammendrag” og ”konklusjon”.
Før møtet leser Xxxxx gjennom forslagsheftet, og planlegger voteringsorden i hver enkelt sak. I noen saker kan det være mange ulike forslag i tillegg til innstillingen. I noen tilfeller kan også
innstillingen være omfattende og bestå av mange punkter. Det hender også at forslag fremmes direkte under møtet, uten at de er sendt inn på forhånd. Det kan være utfordrende å håndtere dette på en korrekt og demokratisk måte og slik at interessene til alle forslagsstillerne og debattantene blir ivaretatt. Da er Xxxxx helt avhengig av et ryddig, oversiktlig og oppdatert forslagshefte, der også innstillingen i den enkelte sak er gjengitt. Hun er også avhengig av at sekretariatet på forhånd har lagt inn alle saker og forslag i voteringsanlegget på en like ryddig måte. Da er det lettere for henne å foreta endringer og justeringer underveis i møtet.
Rett før møtestart gjør Xxxxx klar alle dokumenter og all IT-støtte som hun trenger for å lede møtet. Det vil si
PC/Monitor 1:
● administrasjonsdelen i det nettbaserte voteringsanlegget (for å legge inn forslag, endre voteringsorden og lignende)
PC/Monitor 2:
● kjøreplanen, med oversikt over innhabiliteter (worddokument mottatt som e-post)
● bystyreheftet med saksliste og saksdokumenter (pdf lastet ned fra Innsyn)
● forslagsheftet (pdf lastet ned fra bystyrets hjemmeside)
PC/Monitor 3:
● stemmedelen av det nettbaserte voteringsanlegget (for å se om alle har stemt, eventuelt hvem som ikke har stemt)
PC/Monitor 4:
● visningsdelen av det nettbaserte voteringsanlegget (tilsvarende publikums grensesnitt, for å se voteringsresultat og kunne referere dette)
På papir:
● oppropsliste (worddokument mottatt som e-post og skrevet ut på papir, for å kunne foreta opprop)
● forfallsliste (worddokument mottatt som e-post og skrevet ut på papir, for å kunne referere den og få godkjent forfallene)
Hanne syns det er mange dokumenter og systemer å forholde seg til både før og under møter. Hun skulle gjerne sett at alle de funksjoner hun trenger som møteleder var lett tilgjengelig på ett sted mer intuitivt, oversiktlig, ryddig og logisk.
Klokken 17 åpner Hanne møtet og gjennomfører opprop. Hun sjekker om noen har innsigelser til forfallene. Hun sikrer seg at alle møtedeltakere er innlogget i tale- og voteringsanlegget. Noen ganger må enkelte representanter ha hjelp av sekretæren til å logge inn. Så foretar hun konstituering med godkjenning av innkalling og saksliste. Deretter leser hun opp de habilitetsvurderinger som er gjort i samråd med kommuneadvokaten. Hun sjekker om noen har innsigelser til disse vurderingene.
Når hun tar opp sakene til behandling kommer det raskt inn navn i tale- voteringsanlegget og talelisten kan bli lang. Hanne pleier å spørre om noen av talerne har forslag i saken som skal behandles. Hvis så er tilfelle flytter hun disse manuelt lenger opp på talelisten, for å sikre at de kan fremme sine forslag før strek blir satt. Hun gir ordet til talerne etter tur og passer på at de holder seg til den tildelte taletiden. Hun starter uret når taleren begynner å snakke. Nedtellingen vises på
monitorer i bystyresalen. Hanne er glad for at tale- og voteringsanlegget opererer med forhåndsdefinert taletid etter roller og type innlegg. Det setter hun stor pris på og det gjør det enklere å styre møtet.
Når Xxxxx har fått tilslutning til å sette strek, og talelisten er tom, foretas votering. I mange saker er det et stort antall forslag, og Xxxxx er glad for at hun har forberedt seg godt. Hun har planlagt voteringsrekkefølge på forhånd, og sammen med sekretariatet lagt dette inn i tale- og voteringsanlegget. Nå kan hun bare følge denne rekkefølgen. Litt mer komplisert blir det når det leveres forslag under selve møte på lapper el., eller når noen foreslår en annen voteringsrekkefølge. Det er ikke uvanlig at dette skjer. Det kan for eksempel være noen som ber om at et punkt i innstillingen, eller et innsendt forslag, deles opp slik at vedkommende kan votere for første del men ikke andre del. Det finnes flere slike varianter. Da hender det at hun må be om litt tid til å gjøre endringer i tale- og voteringsanlegget. Dette er helt avgjørende for at forslagsstillerens navn og voteringstemaet skal komme riktig fram på de to monitorene i salen. Dette er i neste omgang avgjørende for at voteringen gjengis korrekt på streamingen av møtet på nett. Noen ganger ser Xxxxx på sin skjerm at det er noen representanter som ikke har stemt. Det er stemmeplikt i folkevalgte organer, så Xxxxx henvender seg da direkte til disse og ber dem om å stemme. Dette har hun blitt vant til. Hun har også blitt vant til at noen ber om ordet for å si at de dessverre har stemt feil. Som hovedregel blir det da ikke foretatt ny votering, men hun gjengir verbalt de riktige stemmetallene og sikrer seg at det er disse som blir protokollført. Etter som hun går raskt over til neste sak, er det ikke tid til å rette opp voteringsresultatet i det digitale voteringsanlegget.
Kort tid etter møtet får Xxxxx en e-post fra sekretæren med møteprotokollen til gjennomlesing og kontroll. Når hun har sjekket at alt er greit, eller hun har rettet opp eventuelle feil, gir hun tilbakemelding om at protokollen er godkjent. Deretter sjekker hun at den har blitt publisert på Innsyn.
Illustrasjon 3 under viser Xxxxxx brukerreise når hun skal forberede og gjennomføre et møte i bystyret. Brukerreisen slik den her er framstilt er relativt lik andre møteledere sine brukerreiser når de skal lede møter i andre organer. Forskjellen er antall saker (volum) og at bystyret er mer formelt i formen. I tillegg benyttes et eget digitalt anlegg for styring av taleliste, taletid og votering i bystyret. Ingen andre utvalg disponerer dette anlegget.
Illustrasjon 3
Under følger en beskrivelse av ønsket situasjon, sett fra ulike brukergruppers side. Beskrivelsen er utarbeidet i nært samarbeid med brukerne.
”En ny digital løsning har ført til at møter i politiske organer forberedes, gjennomføres og følges opp på en enklere og raskere måte fordi mye skjer automatisk og i gode strukturer som preges av selvbetjening. En ny digital løsning automatiserer mye av Bystyresekretariatets administrasjon av politiske møter, og legger til rette for at bystyresekretariatet effektivt kan utføre de oppgavene som må gjøres manuelt. Det er også lett å holde oversikt, og sekretariatets oppgave er først og fremst å overvåke at prosessene går slik de skal. Automatiseringen fører til at det sjelden oppstår menneskelige feil. Mange av de e-postbaserte operasjonene er erstattet av skjemaløsninger og i noen sammenhenger automatisk eksport til kommunens saksbehandlingssystem og arkiv. Det gjelder for eksempel innsending av spørsmål, og forslag, melding om forfall og anmodninger om habilitetsvurdering.
Det gjelder også administrasjonens svar på innsendte spørsmål. Rådmannen syns det er bra at han kan skrive sine svar og notater direkte inn i løsningen, slik at de blir tilgjengelig for møtedeltakerne i sanntid. Han syns også det er praktisk at han enkelt kan klikke på en ESA-knapp og at notatene dermed eksporteres og lagres i ESA8.
Politikerne opplever rask og enkel tilgang til alle saksdokumenter, tilleggsnotater og forslag fordi all informasjon automatisk deles i sanntid, i en oversiktlig digital løsning. Politikerne kan nå all nødvendig informasjon alltid, uavhengig av hvor han/hun befinner seg, og uavhengig av hvilke digitale verktøy de benytter. Også saksdokumenter som er unntatt offentlighet og som inneholder sensitive opplysninger er tilgjengelig i løsningen. Men de er kun tilgjengelige for utvalgte personer/roller, og disse må passere minst to sikkerhetsbarrierer for å få tilgang på dem. Det gjelder primært saksframlegg i Klagenemnden og Formannskapet. Administrasjonen og sekretariatet syns det er et stort framskritt at disse dokumentene kun kan leses. Det er ikke mulig å skrive dem ut, eller kopiere dem.
Politikerne kan også legge inn egne forslag og spørsmål raskt og enkelt, og oppleve at disse automatisk blir tilgjengelige for resten av møtedeltakerne samt sekretariat og rådmannen med en gang, uten unødvendige mellomledd. De folkevalgte syns det er fint at de kan velge å dele forslag, spørsmål og innlegg som de har skrevet i løsningen med andre, og at de selv kan bestemme om de som tekstene deles med skal ha lese- eller redigeringsmuligheter. De syns også det er fint at de ved å sette en hake kan velge at forslag og spørsmål de sender inn automatisk publiseres på kommunens nettsider. De setter stor pris på at informasjon som er publisert i løsningen enkelt kan lagres på egen disk. I tillegg kan alle folkevalgte, via den nye digitale løsningen, melde inn saker til eventuelt og de kan sende inn såkalt ”komitéinitiativ. Begge deler blir automatisk gjort tilgjengelig for de andre møtedeltakerne, samtidig som de eksporteres automatisk til ESA8.
Møtene oppleves som effektive og velfungerende fordi det er lett å manøvrere og navigere i møte- og saksdokumentene, gjøre understrekninger eller uthevinger og dele notater og kommentarer i dokumentene med andre møtedeltakere. Mange politikere syns også det er bra at man kan velge mellom å åpne møte- og saksdokumentene i for eksempel pdf-format eller direkte i nettleseren.
Politikerne er spesielt tilfreds med at de kan velge å kun åpne valgte kapittel (filtrere) i et
saksframlegg, isteden for hele saksframlegget. De kan for eksempel velge at kun kapitlene ”sammendrag”, ”konklusjon” og ”innstilling” skal komme til syne når de åpner et saksframlegg.
De er også tilfredse med at de i løsningen enkelt kan generere et googlesøk eller et søk i kommunens innsynsløsning og på egen disk, og raskt finne saker som er relaterte til den saken de behandler.
Møteledere opplever at den nye digitale løsningen gir god møtelederstøtte. Det finnes et brukervennlig og effektivt nettbasert system for votering og administrasjon av taleliste og taletid. De setter stor pris på at stemmeresultatet raskt blir synlig for alle i form av både tekst og grafikk. Både møteledere og deltakere syns det er bra at forslag som kommer inn blir tilgjengelig for alle i sanntid, og at brukerne kan sortere forslagene i rekkefølge etter definerte parameter som parti, kronologi, alfabetisk eller etter kategori (forslagstype). For møteledere oppleves det også som et stort framskritt at alle notater, oversikt over forfall og oppmøte samt oversikt over hvem som har fått sin habilitet vurdert, er enkelt tilgjengelig i løsningen.
I en ønsket situasjon har alle folkevalgte i Trondheim en “Min Side”. Her finner de all nødvendig informasjon, som for eksempel forfallsstatistikk, nødvendige skjemaer og veiledninger, viktige meldinger fra administrasjonen, enkel tilgang til egne forslag, spørsmål og innlegg som de har valgt å lagre i løsningen, lenker til selvvalgte sider, samt oversikt over relevante møter.
For sekretariatet er det fint at informasjon som produseres i løsningen, på en enkel måte kan tas ut igjen i form av rapporter og statistikk. Sekretariatet kan via et oversiktlig brukergrensesnitt enkelt generere for eksempel
● Forfallsstatistikk
● Voteringsstatistikk
● Forslagsstatistikk
● Taleliste/taletids-statistikk
Sekretariatet er veldig fornøyd med at det er et brukervennlig og enkelt brukergrensesnitt også for andre funksjoner som de bruker hyppig:
● Tilgangsstyring (til løsningen, til taleliste/taletidssystemet, til voteringssystemet)
● Mottak og håndtering/saksbehandling av forfallsmeldinger
● Mottak og håndtering/saksbehandling av ønsker om habilitetsvurdering
Den nye digitale løsningen oppleves robust, intuitiv og brukervennlig. Brukerne slipper å veksle mellom mange ulike systemer og grensesnitt. I en ønsket situasjon er det sømløs integrasjon mellom den nye digitale løsningen og andre fagsystemer som ESA8, Google kontorpakke og kommunens nettsider.”
6. Integrasjoner og grensesnitt mot
andre systemer
Oppdragsgiver har i dag et sett av ulike fagsystemer og applikasjoner innen mange ulike virksomhetsområder. Noen har vært i bruk lenge, andre er nyanskaffet og noen er under utvikling eller anskaffelse.
For å realisere behov og funksjonelle krav, må det etableres grensesnitt mot eksisterende og tilgrensende randsystemer. Grad av kompleksitet og krav til informasjonsflyt vil variere for de ulike grensesnittene.
Under (6.1 dagens løsning for politisk behandling) følger en oversikt og en nærmere beskrivelse av aktuelle randsystemer som løsningen skal integreres med på kort og lang sikt. Listen er ikke uttømmende, men basert på informasjon i gjeldende avtaler, og fra leverandører av dagens systemer.
For noen av randsystemene finnes det per dato ikke ferdig definerte grensesnitt som kan benyttes fra dag én. Det pågår et fortløpende arbeid med å få etablert slike grensesnitt.
Det pågår også parallelt anskaffelser/etableringer av nye systemer i kommunen som vil komme med grensesnitt. To av disse skal “Digitale politikere - rett på sak” integreres med:
● Et nytt CMS (Content Management System) som skal benyttes ved utvikling av digitale tjenester og grensesnitt mot publikum (innbyggere og næringsliv) og arkivløsning/kommunikasjonslogg.
● Et nytt system for kontor- og saksbehandlingsstøtte som skal erstatte ESA8.
For flere fagsystemer er resultatet av saksbehandlingen (dokumenter) arkivert i kommunens saks-
/arkiv system (ESA8). Inntil nytt system for saksbehandling er på plass, skal mye av denne informasjonen tilgjengeliggjøres i den nye løsningen (Digitale politikere - rett på sak).
Det kan også være aktuelt å hente ut data som er lagret på Googledisker via den nye digitale løsningen. Motsatt skal det være mulig å lagre data som er produsert i løsningen, direkte i Googledisker.
Med unntak av det digitale tale- og voteringsanlegget i bystyret, skal ikke den nye løsningen erstatte noen av fagsystemene Trondheim kommune benytter.
Illustrasjon 4 viser hvilke systemer den nye løsningen skal hente data fra, og hvor den skal avlevere data. Dette er kun en illustrasjon, som må betraktes som veiledende. Den vil kunne forandre seg etter hvert som Trondheim kommune utvikler eller anskaffer nye systemer.
Illustrasjon 4
Produksjon av data i ny løsning | Lagres i løsningen | Arkiveres i ESA8 |
Innsending av forslag i saker på sakslista | X | |
Innsending av interpellasjoner, kortspørsmål og private forslag i bystyret | X | X |
Innsending av spørsmål til saker på sakslista | X | |
Innmelding av sak til ”eventuelt” | X | X |
Innmelding av komitéinitiativ | X | X |
Notater skrevet av rådmannen | X | X |
Innlegg og notater skrevet av brukerne | X | |
Melding om forfall | X | X |
Melding om ønsket habilitetsvurdering | X | X |
Oversikt over forfall/oppmøte med begrunnelser | X | |
Voteringer og voteringsresultat | X | |
Talelister og taletid | X |
Tabell 7
6.1 Dagens løsning for politisk behandling
Dagens måte å håndtere politisk behandling av saker på støtter seg på ulike systemer som i noen grad er integrert med hverandre. Flere av disse systemene er ikke aktuelle å bygge en ny løsning på da de av ulike årsaker fases ut eller ikke møter de kravene til funksjonalitet som stilles. Det kan likevel i en overgangsperiode være nødvendig å integrere med disse. Systemene i dagens løsning beskrives under.
ESA - EDB Sak og Arkiv
Kommunens saksbehandlings- og arkivsystem, ESA8, skal fases ut og erstattes innen 2020.
Det er ikke besluttet om det er behov for nytt system, eller om behovet lar seg dekke innen de systemer som allerede finnes i Trondheim kommune. Da ESA8 skal erstattes, anbefales det ikke å utvikle ny funksjonalitet innenfor løsningen. Derimot finnes det mye funksjonalitet i ESA8 som det for “Digitale politikere” kan være aktuelt å integrere med.
ESA8 har en egen møte/utvalgsmodul for administrasjon av politiske møter. I dette arbeidet benyttes Microsoft Office i forbindelse med utarbeidelse av dokumenter til møter. Microsoft Office erstattes nå av Google G-suite. Denne modulen gir ingen møteteknisk IT-støtte.
Saksbehandlingssystemet ESA finnes også i en Windows-versjon. Denne versjonen har en såkalt SRU-funksjon som webversjonen av ESA ikke har. SRU er forkortelse for ”styrer, råd og utvalg”. Dette er en historisk totaloversikt over medlemmene i alle folkevalgte organer i Trondheim.
Systemet er integrert med Jupiter Innsyn slik at alle registreringer i SRU i ESA automatisk publiseres på kommunens innsynsløsning (Jupiter Innsyn). På innsynsløsningen (2.8.7) får man dermed oversikt over de folkevalgte med foto, partitilhørighet, verv og kontaktinformasjon.
Jupiter Innsyn
Jupiter Innsyn er en nettportal som gir offentlig tilgang til alle møte- og saksdokumenter, kommunens postliste, byggesaker og oversikt over styrer, råd og utvalg, samt medlemmene i disse. Systemet har integrasjon både mot ESA8 og ESA Windows. Den gir fri tilgang og søkemuligheter i offentlige dokumenter. Jupiter Innsyn kom i ny oppdatert versjon våren 2017, og løsningenvidereføres. Se xxxx://xxxxxx.xxxxxxxxx.xxxxxxx.xx
Evry voterings og talelisteanlegg
Dette er et eldre nettbasert anlegg for administrasjon av taleliste, taletid og elektronisk votering i bystyresalen. Systemet gjør det mulig å votere elektronisk via en voteringspad som ligger på plassen til hver enkelt bystyremedlem. Det kan også voteres via for eksempel PC, ved å logge inn på en egen nettside. Anlegget gjør det også mulig å vise taleliste, taletid, voteringstema- og resultat på to monitorer i bystyresalen. Det er ønskelig at den nye digitale løsningen kan erstatte dette systemet.
GoToMeeting
Dette er et program/applikasjon som benyttes under bystyremøtene. Programmet gjør det mulig å vise talelliste og voteringsresultat fra voterings- og talellisteanlegget, på monitorer i bystyresalen. Systemet har integrasjon med Evry voterings- og talelisteanlegg. Det er ønskelig at den nye digitale løsningen kan erstatte dette systemet.
Trondheim kommune har etablert et sett med prinsipper for utforming og utvikling av IT-løsninger. Prinsippene skal fungere som retningslinjer som sikrer at IT-løsningene er tilpasset virksomhetens oppgaveløsning samtidig som de digitale tjenestene fra alle områdene i kommunen blir mer helhetlige.
De overordnede arkitekturskissene, integrasjonsoversikten og kvalitetsmodellen baserer seg direkte på prinsippene.
For å realisere behov og funksjonelle krav, og samtidig ta hensyn til Trondheim kommunes it- arkitektur, må det etableres flere grensesnitt mot eksisterende systemer. Grad av kompleksitet og krav til informasjonsflyt vil variere for de ulike grensesnittene.
Applikasjonslandskapet i Trondheim kommune er i konstant endring. Det pågår til enhver tid flere prosjekter som innfører, endrer eller avvikler ulike it-systemer. Dette kan også medføre nye grensesnitt mot ulike systemer. Dette betyr at et funksjonelt behov som i dag er løst på én måte, kan i neste runde måtte forholde seg til en helt andre tekniske omgivelser. Dette er tilfelle for Digital politikere - rett på sak.
For tjenestene knyttet til konseptet «Digitale politikere - rett på sak» er det utviklet en overordnet logisk applikasjonsarkitektur som vist i Illustrasjon 5. Figuren viser hvordan løsningen som etterspørres sameksisterer med resten av infrastrukturen i Trondheim Kommune.
Illustrasjon 5 Overordnet logisk applikasjonsarkitektur (uten relasjoner)
Modellen er en tilpasning av Trondheim Kommunes referansearkitekturmodeller og baserer seg i stor grad på CORA-rammeverket [2]. Modellen synliggjør noen viktige prinsipper:
● Tjenesteorientering og interoperabilitet skal realiseres gjennom å fokusere på komponenter som løser spesifikke forretningsbehov på tvers av virksomheten og dermed legge til rette for gjenbruk og samhandling
● Sikkerhet realiseres gjennom fokus på sikkerhetsprinsippene som er utarbeidet av Kommunen, samt gjenbruk av sikkerhetsstrukturer og -komponenter som allerede eksisterer.
7.2 Moduler i “Digitale politikere”
Prosjektet skal spesielt realisere en løsning innen følgende funksjonelle områder
● Dokument/informasjonshåndtering
● Søking og gjenfinning
● Lagring og deling
● Forslags- og spørsmålshåndtering
● Oppmøte- og forfallshåndtering
● Taleliste og taletidsstyring
● Elektronisk votering
● Min side
● Enkel saksbehandling
● Uttak av rapporter
Løsningen kan tenkes delt inn ulike moduler. Leverandører bes i sitt løsningsforslag å beskrive hvordan moduler i den foreslåtte løsningen ivaretar de ulike funksjonelle områdene, samt hvordan gjenbrukbare tjenester tenkes brukt for å tilgjengeliggjøre data og funksjonalitet i disse.
Det vil være naturlig at tjeneste i disse modulene tilgjengeliggjøres i ulike kanaler, men for bystyresekretariatet og politikerne vil det være naturlig at det etableres en «politikerweb» som enhetlig inngang til tjenestene.
Under følger en overordnet domenemodell som representerer entitetene som behandles av løsningen, samt relasjonen mellom disse. Ved å etablere en relevant og gjennomarbeidet modell vil både detaljert modellering, håndtering av grensesnitt og isolering av forretningsfunksjonalitet forenkles.
Figur under viser et forslag til overordnet domenemodell for området. Modellen viser de sentrale objektene og relasjonene mellom disse
Illustrasjon 6 Overordnet domenemodell med relasjoner
Helt sentralt i modellen er Sak. Denne representerer en konkret sak som er under behandling. Danning av saker, samt samling av saker i Møtedokumenter, er typiske prosesser som håndterer dette informasjonsobjektet. Hver sak fører til Vedtak som inneholder informasjon for møteprotokoll samt resultat av voteringene som representeres av Votering. Møte inneholder informasjon om sakene som behandles (dvs. møtedokumentene), deltakere, basert på Folkevalgte og Forfall, og annen administrativ informasjon nødvendig før, under og etter møtet. Utvalg fungerer som en ytre begrensning for domenemodellen, da alle objekter opptrer innenfor et utvalgs politiske behandling av en sak. Det er likevel verd å bemerke at én sak kan behandles av ulike utvalg. Behandlingslinjen beskriver en saks historikk og behandlinger i ulike utvalg. Saken beholder sin arkivreferanse på tvers av utvalg, men tildeles også interne utvalgsvise løpenummer.
En nøstet fremstilling av den samme modellen (illustrasjon 7) kan gi et bilde av i hvilken kontekst de ulike domeneobjektene opptrer i i gjennomføringen av politiske møter. Figuren under er i denne sammenhengen å anse som en illustrasjon.
XxxXxxxxxxxxxxx 0
7.4 Grensesnitt i ny løsning for politisk behandling
Et av arkitekturprinsippene i Trondheim kommune er “informasjon som sentral ressurs”. I dette ligger det blant annet at informasjon som skapes skal kunne gjenbrukes i andre sammenhenger uten at kvaliteten på informasjonen forringes. I kontekst av ny løsning for politisk behandling av saker betyr dette at løsningen må kunne lese data fra andre systemer og at det etableres programmeringsgrensesnitt som gjøre det mulig å hente ut data.
7.5 Grensesnitt mot ny løsning for saksbehandling
“Digitale politikere – rett på sak” skal i hovedsak være et verktøy i gjennomføring av politiske møter. Produksjon av saksunderlag i forkant av møtene er en oppgave som ligger til administrasjonen i kommunen. Dette innebærer at det må foregå en overlevering av dokumentene mellom Trondheim kommunes saksbehandlingssystem og “Digitale politikere - rett på sak”. Da det ennå ikke er avklart hvordan nytt saksbehandlingssystem skal være, kan man kun definere at “Digitale politikere” må ha et grensesnitt som gjør tilgjengelig funksjonalitet for å publisere dokumenter til møter og saker. Det forventes at det må etableres interim grensesnitt mot ESA8 i påvente av ny løsning.
7.6 Generelt grensesnitt for møtedata
Data som produseres i et møte, benyttes i statistikk som utarbeides av bystyresekretariatet:
● Forslag, interpellasjoner, komiteinitiativ og kortspørsmål innsendt fra politikerne
● Innlegg, spørsmål og notater skrevet av politikere og administrasjon
● Forfallsmeldinger med tilhørende kommunikasjon/saksbehandling
● Meldinger om ønsket habilitetsvurdering med tilhørende kommunikasjon/saksbehandling
● Oversikt over forfall/oppmøte med begrunnelser
● Voteringer og voteringsresultat
● Talelister og taletid
Løsningen “Digital politikere” bør derfor inneholde grensesnitt for å hente ut slike data om gjennomføringen av møter. I tillegg kan blant annet data om forslag, behandlede saker, innlegg fra folkevalgte være av offentlig interesser og egne seg for publisering som åpne data.
7.7 Kvalitetskrav (inkludert sikkerhetskrav og arkivkrav)
Trondheim Kommune har etablert en kvalitetsmodell som synliggjør kvalitetskrav (ikke-funksjonelle krav) til alle løsninger som implementeres i kommunen.
Modellen baserer seg på et sett generelle krav organisert etter ISO9126 med lokale tilpasninger (som vist i illustrasjon 7), herunder krav til felleskomponenter. Kvalitetskravene følger i kapittel 8.
Illustrasjon 7, Trondheim kommunes modell for kvalitetskrav
7.8 Data -konvertering og -migrering
Løsningen skal erstatte eksisterende voteringsanlegg og system for taleliste og taletidsstyring, men ikke noen av de andre fagsystemene kommunen benytter. Den nye løsningen må ha integrasjon opp mot relevante fagsystemer. I løpet av perioden fram til 2020 vil kommunens saksbehandlingssystem, ESA8, bli erstattet. Det er i ESA8 alle politiske saks- og møtedokumenter produseres, og det er via utvalgsmodulen i ESA8 at politisk behandling av sakene administreres.
Den nye løsningen må effektivt kunne hente saks- og møtedokumenter fra ESA8, men også fra et framtidig saksbehandlingssystem eller fagsystem for politisk behandling, når det er på plass.
Det er ikke kravstilt at saker skal produseres eller forvaltes i den nye løsningen. Den skal primært presentere saks- og møtedokumenter på en brukervennlig måte. Det er dermed ikke behov for å migrere eller konvertere inn historiske data. Derimot skal løsningen kunne gi støtte til produksjon av dokumenter ifm selve møtegjennomføringen gjennom grensesnitt for å hente ut data om forslag, forfall, voteringer med mer. Se beskrivelse av behov for grensesnitt.
Trondheim Kommunes arkitekturprinsipper: xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxx.xxxxxxx.xx/xxxxxxxxxx/xxxxxxxxxx CORA-modellen: xxxx://xxx.xxxxxxxxx.xxx
Alle krav er gjengitt i tabellene under. Leverandørens svar og løsningsbeskrivelse gis samlet i bilag 2 (Leverandørens beskrivelse av løsningen).
Kategori | Antall | Besvares hvor |
8.3 Funksjonelle krav | 55 | Bilag 2 - Leverandørens beskrivelse av tjenesten |
8.4 Krav til produktkvalitet | 46 | Bilag 2 - Leverandørens beskrivelse av tjenesten |
8.5 Krav til sikker utvikling | 8 | Bilag 2 - Leverandørens beskrivelse av tjenesten |
8.6 Krav til driftstjenester | 49 | Bilag 2 - Leverandørens beskrivelse av tjenesten |
8.7 Krav til etableringsprosjektet * | 9 | Bilag 3 - Plan for etableringsfasen |
8.8 Krav til tjenestenivå med standardiserte kompensasjoner * | 21 | Bilag 4 - Tjenestenivå med standardiserte kompensasjoner |
8.9 Krav til administrative bestemmelser * | 7 | Bilag 5 - Administrative bestemmelser |
8.10 Krav til samlet pris og prisbestemmelser * | 6 | Bilag 6 - Samlet pris og prisbestemmelser |
SUM | 199 |
* Kravene er også lagt inn i avtalens bilag, og skal besvares der (Bilag 3, 4, 5 og 6)
Kravkode | Kravkategori | Beskrivelse |
A | Må-krav | Dette er krav som leverandørens tilbudte løsning må tilfredsstille. Leverandøren skal beskrive sin løsning for å tilfredsstille kravet. |
B | Bør-krav | Dette er krav som dekker et behov som leverandørens tilbudte løsning bør tilfredsstille, men som ikke er et absolutt krav. Leverandørens eventuelle løsning må beskrives. |
C | Kan-krav | Dette er krav som dekker funksjoner som Kunden anser som ønskelig og som kan gi Kunden merverdi, men som ikke er et absolutt krav. Leverandørens eventuelle løsning må beskrives. |
Svarkode | Svarkategori | Beskrivelse |
1 | Ja, leveres | Dette er funksjonalitet som inngår som del av den tilbudte løsningen og som leverandøren forplikter seg til å levere |
2 | Nei, leveres ikke | Dette er krav til funksjonaliteten som ikke inngår som del av den tilbudte løsningen. Leverandøren trenger ikke å beskrive eller begrunne utover oppgitt kravkode |
3 | Alternativ løsning | Dette er funksjonalitet som ikke inngår som del av den tilbudte løsningen, men leverandøren mener at alternativ funksjonalitet i den tilbudte løsningen vil dekke Kundens antatte behov som ligger til grunn for kravet. Leverandøren skal beskrive sin forståelse av kundens behov, samt beskrive sin foreslåtte løsning av behovet. |
Kravene skal besvares i Bilag 2 - Leverandørens beskrivelse av tjenesten. Noen krav har uthevet skrift. Det markerer at innfrielse av disse kravene forutsetter integrasjoner mot Trondheim kommunes saksbehandlingssystem (for tiden ESA8). Dette er nærmere beskrevet i kapittel 6.
ID | Generelle funksjonelle krav | Krav- kode |
FK 1.1 | Løsningen skal kunne importere persondata på brukerne fra kommunens saksbehandlingssystem, for tiden ESA (SRU-modul oversikt over personer i styrer- råd-utvalg) slik at administrator slipper å legge inn data på alle brukere enda en gang i den nye løsningen | A |
FK 1.2 | Brukerne skal kunne redigere/endre persondata, nevnt i FK 1.1. Endringene skal automatisk oppdateres i kommunens saksbehandlingssystem, for tiden ESA8 | A |
FK 1.3 | Der løsningen skal brukes opp mot/integreres med e-post og eller kontorpakke, må løsningen ha full støtte for G Suite | A |
FK 1.4 | Sekretæren og møtelederen kan velge et “visningsbilde” som gjøres tilgjengelig på egne skjermer eller på storskjerm i møtesalen. Visningsbildene skal kunne vise oversikt over oppmøte og forfall, taleliste med nedtellingsur og voteringstemaer, voteringer og voteringsresultat. | A |
FK 1.5 | Løsningen skal ha en innebygd hjelpefunksjon og brukerveiledning | B |
ID | Dokument- og informasjonshåndtering | Krav- kode |
FK 2.1 | Brukerne skal ha tilgang til alle saksframlegg- og møtedokumenter, på det tidspunkt de er ferdigstilt og publiseres av sekretariat/administrasjon. Tilgjengeliggjøring av saksframlegg og øvrige møtedokumenter i den nye løsningen skal skje i sanntid, uten forsinkelser | A |
FK 2.2 | Brukerne skal kunne få automatisk varsel via SMS og e-post når saksframlegg og møtedokumenter er tilgjengelig i den nye digitale løsningen | A |
FK 2.3 | Brukerne skal kunne få automatisk varsel via SMS og e-post når tilleggsnotater er tilgjengelig i den nye digitale løsningen | A |
FK 2.4 | Brukerne skal kunne få automatisk varsel via SMS og e-post når ”viktige meldinger” er publisert i den nye digitale løsningen | A |
FK 2.5 | Brukerne skal kunne velge å lese saksframlegg som html-visning eller lignende | B |
direkte i nettleseren uten å måtte laste dem ned | ||
FK 2.6 | Brukerne skal også kunne laste ned møte- og saksdokumentene enkeltvis (sak for sak) som pdf-dokument eller som én pdf samlefil med alle dokumentene. (Dette tilbys politikerne allerede, gjennom kommunens innsynsportal. De kan laste ned saksdokumentene til en spesiell sak, samt de vedleggene de måtte ønske, men de kan også laste ned et "samledokument" som inneholder alle møtedokumentene og saksframleggene med vedlegg. Det er eksempler på at dette dokumentet har hatt 1700 sider. Dokumentet har et "tre" eller en innholdsfortegnelse som er klikkbar og som gjør det enkelt å manøvrere i.) | A |
FK 2.7 | Når brukerne velger å lese saksframlegg direkte i nettleseren, skal de kunne maksimere visningsvinduet, til fullskjerm visning. (Spesielt viktig for de som benytter lesebrett eller smartelefon.) | A |
FK 2.8 | Når brukerne velger å lese saksframlegg direkte i nettleseren, uten å måtte laste dem ned, skal de også kunne filtrere og selv velge hvilke deler av saksframlegget som skal vises. (Mange politikere ønsker kun å lese innstillingen i saken, samt sammendrag og konklusjon. De må selv kunne velge, for eksempel fra en nedtrekksmeny, hvilke kapittel de ønsker å se. Det er mulig at dette ikke lar seg gjøre fordi produksjon av saks- og møtedokumenter i Trondheim kommune skjer via ESA8 i formatet MS-word. I så fall ønskes tilbud på innføring av en slik funksjon i løpet av kontraktsperioden, når kunden har anskaffet et annet saksbehandlingssystem som muliggjør dette.) | B |
FK 2.9 | Når brukerne laster ned saksframlegg og møtedokumenter i pdf-format skal de kunne gjøre notater, understrekninger og uthevinger i teksten (som i dag) | A |
FK 2.10 | Brukerne skal kunne se oversikt over alle notater som er innsendt til møte og enkelt kunne åpne dem. (Det kan være mange notater til et møte, særlig til møter i bystyret, bygningsrådet og formannskapet. Det er rådmannen som utarbeider disse i kommunens saksbehandlingssystem, for tiden ESA8, og sekretariatet som publiserer dem på "Innsynsportalen" hvor de legges sammen med de andre dokumentene til et møte. Alle slike notater skal tilgjengeliggjøres i den nye løsningen, på en ryddig og oversiktlig måte. ) | A |
FK 2.11 | Sekretærene skal, fra et enkelt og oversiktlig brukergrensesnitt, kunne ta ut rapporter og statistikk på grunnlag av lagret data. Sekretæren skal kunne velge mellom standard møterapport, eller egen definert rapport ved for eksempel å hake av på en liste med rapportelementer. Rapportene må kunne eksporteres til Google docs, regneark og PDF. Eksempler på rapporter: ● Standard møterapport fra hvert møte, med oversikt over voteringsresultater, enkeltstemmer, møtedeltakere og innsendte forslag ● Forfallsstatistikk for en angitt tidsperiode ● Forslagsstatistikk for en angitt tidsperiode ● Voteringsstatistikk for en angitt tidsperiode ● Taleliste- og taletidstatistikk for en angitt tidsperiode | A |
FK 2.12 | Administrasjonen og sekretariatet skal på en rask og enkel måte kunne tilgjengeliggjøre alle dokumenter i løsningen, også dokumenter som ikke er tilknyttet en bestemt sak | A |
ID | Søking og gjenfinning | Krav- kode |
FK 3.1 | Brukerne kan enkelt finne igjen tidligere saker, som er relatert til den saken som behandles, ved at man i løsningen kan generere søk i henholdsvis Google, kommunens innsynsløsning og egen googledisk. Søk i Google, kommunens innsynsløsning og i egen googledisk skal kunne genereres via et enkelt tilgjengelig menyvalg i løsningen. Søket skal basere seg på tittelen i den saken som til enhver tid er oppe til behandling. | B |
FK 3.2 | Brukerne kan lagre egne forslag og notater i løsningen og enkelt finne dem igjen. | B |
FK 3.3 | Brukerne kan i løsningen se en klikkbar behandlingslinje som viser statusen til den saken som til enhver tid behandles, basert på behandlingslinjen som allerede ligger i kommunens saksbehandlingssystem, for tiden ESA8. Stortinget har en lignende funksjon på sine nettsider | A |
ID | Lagring og deling | Krav- kode |
FK 4.1 | Brukerne skal kunne lagre sine forslag, spørsmål og innlegg og enkelt kunne finne de igjen | B |
FK 4.2 | Brukerne kan dele sine forslag, spørsmål og innlegg med andre, før de sendes inn | A |
FK 4.3 | Brukerne kan velge om de vil gi de som man deler dokumenter med, lesetilgang eller redigeringstilgang | A |
FK 4.4 | Brukerne kan selv velge at forslag, spørsmål og innlegg som de har skrevet inn i løsningen automatisk gjøres tilgjengelig for publikum på kommunens nettsider | A |
FK 4.5 | Rådmannen og sekretariatet kan velge at svar og notater de skriver inn i løsningen automatisk gjøres tilgjengelig for publikum på kommunens nettsider | A |
ID | Forslags- og spørsmålshåndtering | Krav- kode |
FK 5.1 | Brukerne kan gjennom den nye løsningen sende inn forslag til sakene på sakslista, og få de automatisk tilgjengeliggjort for andre møtedeltakere i sanntid | A |
FK 5.2 | Brukerne kan se alle forslag som er innsendt til en sak og filtrere og sortere dem etter definerte parameter/attributter som kategori/type forslag, kronologisk, partimessig, alfabetisk. | A |
FK 5.3 | Møteledere kan slette innkommet forslag, og enkelt gjenopprette det igjen hvis det for eksempel ble slettet ved en feil | A |
FK 5.4 | Brukerne kan gjennom den nye løsningen sende inn spørsmål vedr. sakene på sakslista til rådmannen, og få de automatisk tilgjengeliggjort for andre møtedeltakere i sanntid hvis de selv ønsker det | A |
FK 5.5 | Når rådmannen mottar spørsmål fra politikerne kan han svare på disse ved å legge til et notat i løsningen | A |
FK 5.6 | Brukerne skal via løsningen kunne melde inn saker til punktet eventuelt i forkant av møtene. Meldingene overføres automatisk til rådmannen i kommunens saksbehandlingssystem, for tiden ESA8. Samtidig skal den gjøres tilgjengelig for andre møtedeltakere i sanntid i møteportalen. Politikerne melder ofte inn saker som de ønsker å få behandlet på et møte. Dette gjøres som regel i forkant av møtene, og den innmeldte saken settes opp på sakslista som en eventueltsak. Saken blir manuelt registrert med eget arkivsaksnummer i ESA8. Dette skjer i alle utvalgene bortsett fra bystyret. Bystyret opererer ikke med "eventuelt-saker". | A |
FK 5.7 | Brukerne skal via den nye løsningen kunne sende inn "interpellasjoner, kortspørsmål og private forslag" til bystyret. Meldingene overføres automatisk til rådmannen i kommunens saksbehandlingssystem, for tiden ESA8. Samtidig skal den gjøres tilgjengelig for andre møtedeltakere i sanntid i møteportalen. | A |
FK 5.8 | Brukerne skal via den nye løsningen kunne sende inn "komitéinitiativ". Meldingene overføres automatisk til rådmannen i ESA8. Samtidig skal den gjøres tilgjengelig for andre møtedeltakere i sanntid i møteportalen. | A |
ID | Oppmøte- og forfallshåndtering | Krav- kode |
FK 6.1 | Brukerne kan melde forfall ved å fylle ut enkelt skjema i løsningen | A |
FK 6.2 | Sekretariatet skal fra et enkelt og oversiktlig brukergrensesnitt kunne "saksbehandle" forfallsmeldingen i den nye løsningen og generere automatisk innkalling til vararepresentanter via e-post og sms | A |
FK 6.3 | Forfallsmeldinger, med tilhørende saksbehandling, skal kunne overføres til kommunens saksbehandlingssystem, for tiden ESA8. | A |
FK 6.4 | Brukerne kan melde ønske om hablitetsvurdering ved å fylle ut enkelt skjema i løsningen | A |
FK 6.5 | Sekretariatet skal fra et enkelt og oversiktlig brukergrensesnitt kunne "saksbehandle" melding om ønsket habilitetsvurdering i den nye løsningen og generere automatisk innkalling til vararepresentanter via e-post og sms | A |
FK 6.6 | Meldinger om ønsket habilitetsvurdering, med tilhørende saksbehandling, skal kunne eksporteres til definert arkivsak for habilitetssaker i kommunens saksbehandlingssystem, for tiden ESA8, ved for eksempel å klikke på en ESA8- knapp. | A |
FK 6.7 | Brukerne kan se liste i løsningen over hvem som har forfall og hvilke varamedlemmer som møter i det enkelte møte | A |
FK 6.8 | Brukerne kan i "Min side" se egen forfallstatistikk i form av tall og grafikk | A |
FK 6.9 | Sekretariatet kan, fra et enkelt og oversiktlig brukergrensesnitt, redigere/oppdatere liste med hvem som har forfall og hvem som møter som vara, slik at den blir tilgjengelig for møtedeltakerne i sanntid. | A |
ID | Taleliste- og taletidsstyring | Krav- kode |
FK 7.1 | Brukerne kan tegne seg på talelisten til henholdsvis innlegg, innlegg med forslag og replikk ved et enkelt klikk | A |
FK 7.2 | Brukerne kan se hele talelisten og tiden som telles ned under hvert innlegg | A |
FK 7.3 | Møteledere og sekretærer skal kunne åpne, stenge og redigere taleliste | A |
FK 7.4 | Sekretariatet kan, fra et enkelt og oversiktlig brukergrensesnitt, definere taletid for ulike roller og for type innlegg (forskjellig tid for tale, replikk, interpellasjon osv) | A |
FK 7.5 | Sekretariatet skal kunne gjøre talelisten og nedtelling av taletid tilgjengelig på to oppsatte monitorer i bystyresalen | A |
ID | Elektronisk votering | Krav- |
kode | ||
FK 8.1 | Brukerne kan votere for eller mot i sakene, ved enkle klikk i den nye digitale løsningen, motta en bekreftelse på at voteringen er registrert og se resultatene av voteringen i form av tall og grafikk. | A |
FK 8.2 | Brukerne skal kunne angre sin votering ved et å klikke på en angreknapp el. og stemme på nytt. Angreknapp skal kunne benyttes helt fram til møteleder har stengt for votering. Det skal ikke være mulig å avgi stemme flere ganger uten at den første voteringen blir slettet via bruk av angreknapp | A |
FK 8.3 | Møteledere og sekretærer kan, fra et enkelt og oversiktlig brukergrensesnitt, åpne og stenge for votering | A |
FK 8.4 | Møteledere og sekretærer kan enkelt bestemme voteringsorden (redigere listen med forslag) og gjøre dette synlig for møtedeltakerne | A |
FK 8.5 | Sekretariatet skal ved tilgangsstyring kunne administrere hvem som har stemmerett i et møte. Andre skal ikke kunne stemme | A |
FK 8.6 | Sekretariatet skal kunne gjøre “voteringsvinduet” tilgjengelig på to oppsatte monitorer i bystyresalen | |
ID | “Min side” for politikerne | Krav- kode |
FK 9.1 | Det skal være en "Min Side" knyttet til den nye digitale løsningen som minimum skal inneholde: - Mine forfall (oversikt/statistikk) - Oversiktlig arkiv med mine forslag, innlegg og notater - Mine møter (oversikt over kommende møter i organer man selv har valgt) - Meldingsboks med viktige meldinger fra administrasjonen - Viktige skjemaer som forfallsmelding, ønske om habilitetsvurdering, søknad om godtgjøring, innmelding av sak til eventuelt, innmelding av spørsmål til rådmannen, påmeldingsskjemaer og innsending av komitéinitiativ, interpellasjoner, private forslag og kortspørsmål - Lenker til selvvalgte nettsteder | A |
FK 9.2 | Sekretariatet skal, fra et enkelt og oversiktlig brukergrensesnitt, kunne gjøre endringer i innhold i "Min Side". Dette skal blant annet være mulig å definere skjemaløsninger, eller fjerne eller legge til skjemaløsninger | A |
8.4 Krav til produktkvalitet (kvalitetskrav)
Kravene skal besvares i Bilag 2 - Leverandørens beskrivelse av tjenesten
ID | Funksjonell egnethet | Krav- kode |
KK 1.1 | For datofelter skal NS-ISO 8601 følges | A |
ID | Pålitelighet | Krav- kode |
KK 2.1 | Løsningen må fortsette å tilby funksjonalitet selv i tilfeller det er feil på systemer som løsningen er integrert med. | A |
KK 2.2 | Løsningen må kunne gjenopprette data som er produsert før en ikke planlagt nedetid. | A |
KK 2.3 | Oppgraderinger eller nye versjoner av løsningen skal kunne gjenbruke tidligere innhold og konfigurasjoner. | A |
ID | Informasjonsforvaltning | Krav- kode |
KK 3.1 | Data i løsningen (eller backup) skal persistere for 4 år. | A |
ID | Brukskvalitet | Krav- kode |
KK 4.1 | Løsningen skal utformes i henhold til Forskrift om universell utforming av IKT- løsninger | A |
KK 4.2 | Det skal være mulig for 250 brukere å være pålogget løsningen samtidig. | A |
KK 4.3 | Det skal komme klart fram at Trondheim kommune er ansvarlig for løsningen. Xxxxxxxx skal være sikker på hvem som er ansvarlig for tjenesten. Informasjon om tjenesteeier er synlig og lett å finne. Det skal framgå tydelig hvilken offentlig instans som er ansvarlig for tjenesten som helhet. I sammensatte tjenester med flere virksomheter involvert, må brukeren være sikker på hvem som er ansvarlig for hva, for eksempel hvem som har behandlingsansvaret for personopplysninger. Navnet på tjenesten og ansvarlig virksomhet (eventuell logo) må være synlig. | A |
KK 4.4 | Løsningen skal utformes i tråd med Trondheim kommunes grafiske profil. Tilpasninger til profilen gjøres i samråd med Kommunikasjonsenheten. | |
ID | Sikkerhet | Krav- kode |
KK 5.1 | All kommunikasjon med Løsningen og mellom komponenter i Løsningen skal foregå over krypterte kanaler, og det skal være mulig å blokkere eventuelle usikre/ukrypterte kommunikasjonsporter. Det skal benyttes anerkjente krypteringsmekanismer uten kjente sårbarheter. | A |
KK 5.2 | Løsningen skal beskytte mot kapring av forbindelser mellom lag i løsningen (nettleser/webserver, nettleser/api, webserver/api, webserver/database osv). Autentiseringsnøkler (passord og lignende) skal overføres og lagres på sikre måter, og beskyttes mot brute force gjetting, valideres av alle lag, ikke eksponeres i URL'er, utløpe etter definerte kriterier). Kriterer som OWASP Application security verification standard skal legges til grunn. | A |
KK 5.3 | Alle tjenester som benytter SSL-sertifikater skal benytte offentlige sertifikater med god dekning i standard nettlesere, og uten kjente svakheter. Validering vha. SSL Labs minimum karakter A kan benyttes for å validere oppfyllelse. Alle tjenester som konsumerer andre SSL-baserte tjenester skal validere sertifikater mot et tiltrodd tillitsanker. | A |
KK 5.4 | Løsningen skal leveres med en default sikker konfigurasjon. Komponenter som løsningen bygger på skal ikke ha kjente sårbarheter, unødvendige funksjoner skal være avslått (porter, tjenester, kontoer, rettigheter), default kontoer og tilganger skal være deaktivert, feilmeldinger skal ikke gi unødvendig informasjon til sluttbruker, og servere og rammeverk skal være konfigurert iht. gjeldende sikkerhetsanbefalinger. | A |
KK 5.5 | For løsninger som skal sende ut epost med avsenderadresse under Trondheim kommunes domenenavn, skal utsendelsen primært foregå via Trondheim kommunes epostløsning. Om løsningen sender epost fra egen server, skal denne ha ip som kan registreres i TKs SPF-record og støtte DKIM signering. | B |
KK 5.6 | Løsningen skal levere innhold til audit-log for all bruk av løsningen. Loggen skal inneholde innslag for autentisering, autorisasjon, tildeling og bruk av tilganger, endring av konfigurasjon, systemstart/stop samt oppgraderinger. | B |
KK 5.7 | Løsningen skal levere innhold til utvidet audit-log for all bruk av løsningen. Innholdet i logg-innslaget er definert av tjenesten. Loggen skal inneholde innslag for endring eller sletting av data. | B |
KK 5.8 | Løsningen skal levere innhold til innsyn-log for all bruk av løsningen. Innholdet i logg- innslaget er definert av tjenesten. Loggen skal inneholde hvem som har fått tilgang, hvilke opplysninger som er hentet og hvilket formål innsynet har (eksempelvis hvilket fagsystem/prosess som står bak innsynet, lovhjemmel) | B |
KK 5.9 | Løsningen skal levere innhold til sikkerhetslogg for all bruk av løsningen. Loggen skal inneholde innslag for sikkerhetsrelaterte tjenester, som forøsk på innbrudd (autentiseringsfeil), valideringsfeil i baksystemer der valideringen skulle skjedd tidligere) | B |
KK 5.10 | Løsningen skal ha innebygget funksjonalitet for oppdage og varsle om forsøk på angrep, som brute force påloggingsforsøk, automatisert scanning, input som ikke skal kunne komme fra klienten, unormale bruksmønster eller tempo som tyder på automatiserte angrep. Løsningen bør kunne sperre brukertilganger, IP-adresser og lignende basert på oppdaget angrepsforsøk. | C |
KK 5.11 | Logger skal inneholde: - Id for bruker - Type hendelse - Dato og tidspunkt - Suksess eller feil - Opphav til hendelsen (system/bruker mv.) - Identitet eller navn på påvirket data, systemkomponent eller ressurs. Loggdata skal være strukturert på formater og protokoller som muliggjør innsamling til SIEM-løsning/loggkorreleringsløsninger og løsningen skal støtte overføring av loggdata til Kundens sikkerhetsovervåkningstjenester. | B |
KK 5.12 | Sesjonstimeout skal kunne konfigureres. | B |
KK 5.13 | Det skal være mulig å endre knytningen mellom roller og rettigheter i løsningen. Alle endringer i rettigheter skal kunne spores i audit-log. Det skal kreves spesielle roller for å endre roller og rettigheter. Endringer skal kunne gjøres uten at systemet restartes | B |
KK 5.14 | Løsningen skal ha støtte for standard roller som systemadministrator, brukeradministrator, system/konfigurasjonsrevisjon, revisjon av logger samt de nødvendige funksjonelle roller definert i funksjonelle krav. Det skal kunne opprettes hensiktsmessige tilgangsgrupper for brukere for å oppnå effektiv administrasjon av tilganger. | B |
KK 5.15 | Sluttbrukeridentitet og autentisert sluttbrukersesjon skal følge med kall til tjenester. Denne informasjonen skal inngå i audit-logg. API'er og bakenforliggende tjenester skal selv verifisere autentiseringen gjennom å validere sluttbrukersesjonen. | B |
KK 5.16 | Løsningen skal støtte webbaserte API'er for brukeradministrasjon og administrasjon av tilganger. API'ene skal kunne gjøre det mulig å opprette/slette brukere, flytte brukere mellom organisasjonsenheter, roller og grupper fra en ekstern IAM-løsning. | B |
KK 5.17 | ID-Porten skal benyttes for autentisering av brukere. ID-portens retningslinjer for utforming benyttes. Integrasjonen valideres iht. ID-portens krav til verifikasjon av integrasjoner xxxxx://xxx.xxxx.xx/xxxxxxxxxx-xx-xxxxxxxxx/xxxxxxxx-xxxxxxxxxxxxxxx/xx-xxxxxx | A |
KK 5.18 | Løsningen skal ha støtte for sterk autentisering/tofaktor autentisering, integrert i løsningen eller via ID-porten | C |
KK 5.19 | Løsningen skal validere tilgangsrettigheter i alle lag av applikasjonen, og validere at brukeridentiteten som aksesserer data eller tjenester har nødvendige rettigheter. Valideringen skal ikke kunne omgås av brukeren. | B |
KK 5.20 | Løsningen må være bygd opp av uavhengige komponenter som enkelt kan byttes eller oppgraderes med minimale konsekvenser for andre komponenter. | A |
KK 5.21 | Løsningen skal logge feil, transaksjoner, bruksmønster og dataflyt og gjøre logger tilgjengelig slik at analyse av løsningen for forbedring blir mulig. | A |
KK 5.22 | Løsningen skal gjøre selvanalyse og varsle om nødvendig endringsbehov før feil oppstår. | A |
24.08.2018: Kravet utgår, jf. svar på spørsmål under tilleggsinformasjon. | ||
KK 5.23 | Hvis sluttbrukere, admin/superbrukere og utviklere ønsker å legge til, fjerne, endre funksjonalitet, kapasitet, ressurs av GUI, backend, integrasjon, miljø eller server på real time/design time skal løsningen støtte endringen uten konsekvenser for operasjon, med minimal nedetid | B |
KK 5.24 | Leverandøren må tilgjengeliggjøre testverktøy slik at kunden har muligheten til å etterprøve krav til bl.a ytelse og sikkerhet. | A |
KK 5.25 | Tjenester skal som hovedregel tilbys som web services, enten som REST-API eller SOAP-basert. | A |
KK 5.26 | Meldingsstruktur skal følge standard protokokoller som JSON, XML eller ATOM. | A |
KK 5.27 | Løsningen skal benytte Geointegrasjonsgrensesnitt (GI), Noark eller andre standard webtjenester for integrasjon/kommunikasjon med Trondheim kommunes saksbehandlingssystem, for tiden ESA8. | A |
KK 5.28 | Tjenester som tilbys må versjoneres. Der det er nødvendig må det tilbys multi- versjonshåndtering i eksponerte grensesnitt. | B |
KK 5.29 | WSI-profiler - SOAP/XML tjenester skal være WSI- kompatible. | B |
KK 5.30 | Webbaserte APIer skal dokumenterEs blant annet med, men ikke begrenset til, WSDL, WADL eller Swagger. | A |
KK 5.31 | Alle deler av systemets datamodell, som berører kundens funksjonalitet, skal være tilgjengelig via et et SOAP- eller REST-API med CRUD-funksjonalitet. | B |
KK 5.32 | Alle endringer av systemets data, som berører kundens funksjonalitet, skal kunne hentes via et et SOAP- eller REST-API. APIet skal fungere slik at en sender inn et tidspunkt og APIet returnerer alle endringer på data fra forespurt tidspunkt. | C |
KK 5.33 | En skal kunne abonnere på alle endringer av systemets data (Publish–subscribe pattern), som berører kundens funksjonalitet. Systemet skal sende oppdateringer til sine abonnenter ved endringer på systemets data. Oppdateringsmeldingene skal overføres via et webgrensenitt implementert på mottakers side. | B |
KK 5.34 | I de tilfeller systemet sender fra seg en melding via et webgrensenitt (push), skal systemet logge en eventuell feilrespons. Feilloggen presenteres i et grafisk brukergrensenitt og muliggjør resending av meldinger. | B |
KK 5.35 | Systemet skal tilby en meldingskø for utgående informasjon. Hvert køelement skal ha felter som indikerere meldingens status. Som et minimum må denne statusen kunne indikere følgende; "ny", "prosessert" og "prosessering av melding feilet". | B |
KK 5.36 | All funksjonalitet skal være tilgjengelig ved bruk de vanligste nettlesere (Chrome, Firefox, Safari, Explorer, MS Edge) | A |
KK 5.37 | All funksjonalitet skal være tilgjengelig ved bruk på PC, mobil og nettbrett. | A |
Kravene skal besvares i Bilag 2 - Leverandørens beskrivelse av tjenesten
ID | Prosesskrav - sikkerhet | Krav- kode |
SU 1.1 | Leverandør skal gjennomføre sikkerhetstester i henhold til anerkjente retningslinjer for sikkerhetstesting, som OWASP Application Security Verification Standard (xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxxx:XXXXX_Xxxxxxxxxxx_Xxxxxxxx_Xxxxxxxx tion_Standard_Project) | A |
SU 1.2 | Leverandøren skal sikre og dokumentere at alle utviklere har nødvendig kunnskap om sikker programvareutvikling, og gjennomføre nødvendige bakgrunnssjekk av eget personell. | A |
SU 1.3 | Leverandøren skal benytte et kildekontrollsystem som autentiserer opphavet til og logger alle endringer i kildekoden og konfigurasjonsfiler. | A |
SU 1.4 | Leverandøren skal holde kontroll med all tredjeparts biblioteker og komponenter i løsningen for avdekkede sikkerhetssårbarheter og oppdateringer som har betydning for løsningen, og sørge for at feil i tredjepartsbibliotek som innebærer behov for feilretting av løsningen leveres under samme vilkår som feilrettinger i egenutviklede komponenter. | A |
SU 1.5 | Leverandøren skal logge alle sikkerhetsfeil/saker gjennom hele leveransens livssyklus, fra krav, design, implementasjon, testing, leveranse og drift. Risikoen knyttet til alle feil skal vurderes og rapporteres til Kunden uten ugrunnet opphold. Risiko skal i utgangspunktet vurderes ut fra CVSS v3 eller tilsvarende skala. Sårbarheter som vurderes som Høy eller kritisk skal behandles som A-feil. Medium som B-feil, Lav som C-feil. | A |
SU 1.6 | Leverandøren skal utarbeide en løsningsbeskrivelse for sikkerhet som beskriver hvordan Leveransen oppfyller krav til: - Inputvalidering - Autentisering og sesjonshåndtering - Tilgangskontroll, roller og rettigheter - Feilhåndtering - Logging - Sikring av forbindelser til eksterne system og mellom de ulike løsningskomponenter. - Kryptering og konfidensialitetssikring - Tilgjengelighet og sikring mot datatap - Sikker konfigurasjon og - Generelle sårbarheter, inkl. beskyttelse mot vanlige feil som «"OWASP Top Ten Most Critical Web Application Vulnerabilities» Der Leverandørens løsningsbeskrivelse forutsetter at sikkerhetsfunksjoner ivaretas | A |
av komponenter som ikke er en del av den leverte løsningen, skal dette dokumenteres spesifikt i løsningsbeskrivelsen. Løsningsbeskrivelsen skal godkjennes av Kunden. | ||
SU 1.7 | Hvis løsningen består av en mobilapp, skal denne ivareta kravene i OWASP Mobile AppSec verification standard. Hvis applikasjonen lagrer eller gir tilgang til sensitive personopplysninger skal kravene til L2 oppfølges. | A |
SU 1.8 | Leverandøren skal sikre at identifiserbare personopplysninger ikke benyttes i testmiljø eller verifikasjonsmiljø som ikke har tilsvarende tilganger som produksjonstjenesten. | A |
Kravene skal besvares i Bilag 2 - Leverandørens beskrivelse av tjenesten
ID | Sikkerhet | Krav- kode |
DT 1.1 | Leverandøren skal ha et styringssystem for informasjonssikkerhet basert på ISO/IEC 27001 eller tilsvarende anerkjent standard for informasjonssikkerhet. Styringssystemet skal dekke alle organisasjonsenheter og fysiske lokasjoner som inngår i leveranseprosessen. Oppdatert beskrivelse av sikkerhetspolicy, kvalitetssikrings- og styringssystemet skal til enhver tid være tilgjengelig forKunden. | B |
DT 1.2 | Leverandøren skal utpeke en tilstrekkelig kvalifisert kontaktsperson for sikkerhet med ansvar for at sikkerhetskravene i leveransen etterleves og vedlikeholdes i kontraktsperioden. | A |
DT 1.3 | Leverandøren skal iverksette egnede tekniske og organisatoriske sikkerhetstiltak for å kunne håndtere de opplysninger Xxxxxx har beskrevet at tjenesten skal behandle. Tiltakene skal gi et sikkerhetsnivå som står i forhold til risikoen for Kunden og som følger etablert beste praksis på området. | A |
DT 1.4 | Krav til databehandleravtale. Leverandøren skal inngå skriftlig databehandleravtale med Kunden. Hvis Leverandørens tjenesteleveranse omfatter overføring av personopplysninger til tredjeland som ikke har tilstrekkelig databeskyttelse iht. EUs personverndirektiv, skal databehandler inngå databehandleravtale iht. EU Commission Decision C(2010)593 Standard Contractual Clauses (processors) og implementere de sikkerhetstiltak som er nødvendige for å etterleve EUs personverndirektiv. | A |
DT 1.5 | Leverandøren skal bistå med relevant kompetanse ved tilsyn fra offentlige tilsynsmyndigheter. | A |
DT 1.6 | Leverandøren skal bistå etterforskende myndighet, når Xxxxxx som databehandleransvarlig beslutter at dette er i tråd med de lover og forskriftsmessige føringer Kunden opererer under. | A |
DT 1.7 | Leverandøren skal minst årlig gjennomføre risiko- og sårbarhetsanalyse knyttet til alt som omfatter leveransen av tjenesten. Dersom tjenesteleveransen inkluderer bruk av underleverandører skal deres leveranser også inkluderes, eller egen risikoanalyse skal være gjennomført. Risikovurderingen skal som minimum identifisere kritiske aktiva, trusler og sårbarheter og resultere i en formell dokumentert risikoanalyse. Leverandøren skal gi Kunden innsyn i risikoanalysene. Utestående tiltak som adresserer uakseptabel risiko skal dokumenteres og gjøres tilgjengelig for Kunden, uten ugrunnet opphold. | B |
DT 1.8 | Ved avhending, kassering eller gjenbruk av enheter og utstyr som har vært benyttet i forbindelse med løsningen, skal Leverandøren iverksette en sikker og forsvarlig prosess som også tar hensyn til miljømessige aspekter. Lagret informasjon og lagringsmedier skal slettes eller makuleres med mekanismer godkjent av NSM for avhending av informasjon gradert BEGRENSET eller tilsvarende. Leverandøren skal dokumentere rutiner for å ivareta sikker sletting, og evt. destruksjon, av dokumenter, informasjon og lagringsmedier. | A |
DT 1.9 | Leverandøren skal ha et dokumentert regime for personellsikkerhet, herunder rutiner for bakgrunnssjekk av ansatte. | A |
DT 1.10 | Leverandøren skal gjennomføre regelmessig opplæring i informasjonssikkerhet for alt personell - både for eget, samarbeidende og innleid personell som utfører arbeide i forbindelse med levering av tjenesten. Alt personell skal minimum ved ansettelse og årlig bekrefte at de er kjent med relevante sikkerhetspolicyer og rutiner. | A |
DT 1.11 | Leverandøren skal ha dokumenterte rutiner for dokumentasjon og rapportering av sikkerhetsrelaterte hendelser. Rutinene skal være kjent for alt personell som utfører arbeid i forbindelse med tjenesten. | A |
DT 1.12 | Hvis Leverandøren benytter mobile enheter for tilgang til eller behandling av Kundens data skal Leverandøren: ● kun benytte mobile enheter med full diskkryptering ● sikre at mobile enheter har automatisk låsing og krav om PIN eller pålogging av tilstrekkelig kvalitet ● har mekanismer for å fjernslette enheter/data ● sikre at ansatte og underleverandører er kjent med sitt ansvar for å sikre mobile enheter og varsle om mobile enheter er på avveie. | A |
DT 1.13 | Når tjenestene leveres fra Leverandørens lokaler, eller Kundens data behandles på utstyr kontrollert av Leverandøren eller oppbevares i Leverandørens lokaler, skal | A |
Leverandørens lokaler ha etablert sikkerhetsmekanismer som gir tilstrekkelig beskyttelse mot fysisk tap eller skade. | ||
DT 1.14 | Leverandøren skal dokumentere ansvar og prosedyrer for administrasjon og drift av løsningen. | |
DT 1.15 | Leverandøren skal ha dokumenterte prosedyrer for endringshåndtering, som omfatter minimum: ● Dokumentasjon av risiko og konsekvens av endringen, både ift. gjennomføring og sikkerhet ● Dokumentert godkjenning av autorisert personell ● Funksjonell testing for å verifisere at endringen ikke negativt påvirker systemet ● Oppdatering av relevant driftsdokumentasjon og beredskapsdokumentasjon ● Rollback-prosedyrer | A |
DT 1.16 | Leverandøren skal benytte antivirusprogramvare på alle systemer med risiko for ondsinnet programvare. Antivirusprogramvaren som benyttes skal være i stand til å detektere, fjerne og beskytte mot alle kjente typer ondsinnet programvare. Antivirusprogramvaren skal holdes oppdatert, gjennomføre periodiske scan og generere logger som oppbevares iht. krav om logghåndtering. Antivirusprogramvaren skal ikke kunne deaktiveres av brukere uten administrativ godkjenning. | A |
DT 1.17 | Leverandør skal sikre at alle systemkomponenter har en sikker konfigurasjon, herunder: ● Sikre at alle leverandør-default passord og unødvendige default-kontoer er deaktivert ● Ha etablerte konfigurasjonsstandarder for alle systemkomponenter som er konsistent med industri-aksepterte herdingsstandarder (som CIS, ISO, SANS, NIST etc.), som jevnlig revideres og oppdateres ● Implementerer kun en primær funksjon pr. server ● Kun tillater nødvendige tjenester, protokoller osv, som er nødvendig for systemets funksjon ● Implementerer sikkerhetsfunksjoner for alle nødvendige tjenester som regnes som usikre (ssh fremfor telnet osv.) ● Fjerner unødvendig funksjonalitet, som eksempelskript og data ● Benytter sikre protokoller for administrasjon (SSH, VPN, TLS) | B |
DT 1.18 | Leverandøren skal implementere sikkerhetslogging for å koble all tilgang til systemkomponenter og tjenester til individuelle brukere. | A |
DT 1.19 | Leverandøren skal logge forsøk på uautorisert bruk. | A |
DT 1.20 | Loggdata skal beholdes i minimum ett år | A |
DT 1.21 | Leverandøren skal kunne tilgjengeliggjøre relevant logginformasjon, som innloggingslogger, sikkerhetslogger mv., for Kundens tjeneste for sikkerhetsovervåkning. Logginformasjon skal gjøres tilgjengelig så nær sanntid som mulig, og i formater som muliggjør automatisk overføring og behandling av SIEM- verktøy. | B |
DT 1.22 | All nettverkskommunikasjon hvor det overføres sensitiv eller taushetsbelagt informasjon skal være beskyttet med kryptering. Relevant for (sikkerhetsnivå) S3, S4 | A |
DT 1.23 | Leverandøren skal ha tiltaksplaner og tekniske løsninger for å håndtere tjenestenektangrep (DoS, DDoS) som rammer Kunden, eller som påvirker Kunden pga. angrep på andre tjenester eller kunder i Leverandørens nettverk. | B |
DT 1.24 | Leverandøren skal sikre at kryptografiske nøkler beskyttes mot uautorisert tilgang. Leverandøren skal ha sikre prosesser for å generere, lagre, arkivere, hente, distribuere, sikkerhetskopiere og trekke tilbake og ødelegge kryptografiske nøkler. | A |
DT 1.25 | Leverandøren skal sikre at krypteringsmekanismer som benyttes ikke har kjente svakheter og sårbarheter, og kryptografiske nøkler har tilstrekkelig lengde/kompleksitet til å motstå kjente angrep. | A |
DT 1.26 | Tildeling av rettigheter til og i systemer som behandler Kundens data skal være dokumentert og utført av autorisert personell. Relevant for (sikkerhetsnivå) S3, S4 | A |
DT 1.27 | Leverandøren skal ha rutine for ajourhold av autorisasjon og tilganger, herunder regelmessig revisjon samt umiddelbar tilbaketrekking av autorisasjon og tilganger når en person ikke har tjenestelig behov. | A |
DT 1.28 | All fjerntilgang for administrasjon skal: ● beskyttes med sterk autentisering ● gjøres gjennom en sikker gateway som autentiserer og logger all tilgang | |
DT 1.29 | Leverandøren skal sikre at alle administrative brukerkontoer og system/applikasjonskontoer er underlagt en dokumentert passordpolicy som sikrer at: ● De har en forsvarlig lengde og kompleksitet ● Byttes iht. en regelmessig frekvens ● Ikke kan gjenbrukes | A |
DT 1.30 | Leverandøren skal ha standarder for nettverkssikkerhet som omfatter: | B |
● En formell prosess for å godkjenne og teste alle endringer i brannmur- og nettverkskonfigurasjon ● Oppdatert nettverksdiagram som identifiserer alle forbindelser mellom nettverkssoner, trådløse soner, eksterne nettverk. ● Grupper, roller og ansvar for nettverkskomponenter ● Dokumentasjon av begrunnelse for alle tjenester, protokoller og porter som er åpne. | ||
DT 1.31 | Leverandøren skal sikre at eventuelle brannmur- og ruterkonfigurasjoner som benyttes i driftsløsningen: ● Er begrenset til hva som er nødvendig for Kundens systemer og applikasjoner og spesifikt sperrer for all annen trafikk ● Beskytte konfigurasjonsfiler mot uautorisert tilgang og holde disse synkronisert ● Forhindrer uautorisert direkte tilgang (inn eller ut) mellom Internett og interne systemkomponenter som ikke er i DMZ. ● Implementerer anti-spoofing tiltak for å detektere og blokkere falske kilde- IP-adresser, samt «stateful inspection ● Ikke avslører interne IP-adresser og rutinginformasjon til uautoriserte parter ● Er i henhold til anbefalinger og veiledninger fra nasjonale sikkerhetsmyndigheter som Datatilsynet og NSM. ● At alle brannmurregelsett revideres minimum årlig. Revisjonen skal sikre at alle regelsett er i samsvar med behov, i henhold til sikkerhetskrav og kan spores tilbake til godkjente endringer, samt er dokumentert i driftsdokumentasjon for tjenestene. | B |
DT 1.32 | Alle systemkomponenter og programvare skal holdes oppdatert og beskyttes mot kjente sårbarheter med å installere sikkerhetspatcher. | A |
DT 1.33 | Leverandøren skal ha en prosess for sikkerhetspatching som sikrer: ● At alle relevante sikkerhetspatcher identifiseres ● At sikkerhetspatching er del av en styrt endringskontrollprosess ● At sikkerhetspatcher testes og valideres før produksjonssetting ● At sikkerhetspatcher for kritiske sårbarheter implementeres uten unødig opphold | A |
DT 1.34 | Leverandøren skal samarbeide med Xxxxxx og Xxxxxxx andre tjenesteleverandører og kontaktnett (CERT-organisasjoner mv.) ved håndtering av sikkerhetshendelser som berører tjenesten. | A |
DT 1.35 | Leverandøren skal ha dokumenterte prosesser og en plan for deteksjon og håndtering av sikkerhetsbrudd som kan påvirke Kundens data. Det skal eksistere dokumenterte tiltaksplaner for alle relevante sikkerhetshendelser som tjenestenektangrep, systeminntrenging, virusutbrudd, uautorisert utprøving av sårbarheter, tap og eksponering av personopplysninger mv. | A |
DT 1.36 | Leverandøren skal umiddelbart varsle Kunden ved konstaterte sikkerhetsbrudd eller | A |
andre påviste svakheter som har negativ påvirkning på tjenesten, Kunden, oppdragsgivere eller sluttbruker. Alle sikkerhetshendelser og feil skal spores i leverandørens system for hendelseshåndtering og kategoriseres iht kritikalitet. Xxxxxx skal informeres om konsekvensen av hendelsen og iverksatte tiltak | ||
DT 1.37 | Leverandøren skal sikre bevis og umiddelbart iverksette tiltak for å sikre Xxxxxxx informasjon og identifisere årsaken til hendelsen | A |
DT 1.38 | Leverandøren skal etablere og vedlikeholde en dokumentert kontinuitets- og beredskapsplan som dekker krisesituasjoner, håndtering av sikkerhetsbrudd, sikkerhetskopi- og reservedriftsløsninger for tjenestene | A |
DT 1.39 | Leverandøren skal holde kontinuitets- og beredskapsplan løpende oppdatert ved endringer og gjennom regelmessig test og øvelse. Gjenopprettingsprosedyrer skal oppdateres ved alle endringer som har betydning for gjenoppretting ved driftsstans | A |
DT 1.40 | Leverandøren skal dokumentere og vedlikeholde en backuppolicy og rutiner for backup for all informasjon i driftsløsningen, som ivaretar Kundens krav til gjenoppretting og maksimalt datatap for løsningen | A |
DT 1.41 | Sikkerhetskopiert informasjon skal gis nødvendig fysisk og miljømessig beskyttelse, og lagringsmedia behandles iht. krav til håndtering av lagringsmedia | A |
DT 1.42 | Leverandøren skal dokumentere sin etterlevelse av sikkerhetskravene i avtalen gjennom revisjon. Revisjonen skal minimum skje årlig og i tillegg ved signifikante endringer i sikkerhetsregimet. Sertifisering iht. ISO 27001 eller tilsvarende kan gi uttelling på dette området, avhengig av samsvaret mellom kravene i avtalen og i Leverandørens styringssystem. Leverandøren skal tilgjengeliggjøre avvik som avdekkes ved intern eller ekstern revisjon for kunden uten ugrunnet opphold. Avvik skal tilgjengeliggjøres for Kunden også om dette berører forhold knyttet til felles infrastruktur som berører andre kunder. | B |
DT 1.43 | Kunden, eller tredjepart utpekt av Kunden kan gjennomføre sikkerhetsrevisjoner knyttet til alle sider av driftsavtalen. Revisjonen kan omfatte gjennomgang av rutiner, stikkprøvekontroller, mer omfattende stedlige kontroller og andre egnede kontrolltiltak. Leverandøren plikter å gi nødvendig bistand til dette. | A |
DT 1.44 | Leverandøren skal gjennomføre jevnlig sårbarhetsscanning (minimum kvartalsvis) av alle interne og eksterne ip-adresser som behandler Kundens data. | |
DT 1.45 | Leverandøren skal minimum årlig gjennomføre penetrasjonstester på på alle | B |
internettnåbare tjenester. Penetrasjonstestene skal gjennomføres iht. anerkjent metodikk for penetrasjonstesting, eksempelvis NIST SP800-115, og dekke kritiske komponenter i løsningen. Testene skal dekke både interne og eksterne angrepsvektorer, og gjennomføres av kvalifisert personell. | ||
DT 1.46 | Kunden eller tredjepart utpekt av kunden skal ha rett til å gjennomføre sikkerhetstester, herunder sårbarhetstesting og inntrengningstesting, på alle systemer som benyttes for behandle Kundens data. | B |
DT 1.47 | Leverandøren skal sørge for at Driftstjenesten leveres løpende i samsvar med til enhver tid gjeldende relevant lovverk og standarder, slik som: ● Kommuneloven med tilhørende forskrifter ● Offentlegloven med tilhørende forskrift ● Forvaltningsloven med tilhørende forskrift ● eSignaturloven ● eForvaltningsforskriften ● Personopplysningsloven med tilhørende forskrift ● EUs General Data Protection Regulation (GDPR). (Regulation (EU) 2016/679) (gjeldende fra ikrafttredelse) ● Forskrift om kommunal beredskapsplikt ● EU-direktivet om sikkerhet i nettverk og informasjonssystemer (Directive (EU) 2016/1148) (gjeldende fra ikrafttredelse) ● Sikkerhetsloven med tilhørende forskrift ● Arkivlova med tilhørende forskrifter ● Relevant sektorspesifikk lovgivning | |
ID | Infrastruktur | Krav- kode |
DT 2.1 | Tjenesten skal støtte standarder for grunnleggende datakommunikasjon iht.Referansekatalogen for IT-standarder i offentlig sektor (xxxxx://xxx.xxxx.xx/xxxxxxxxxx-xx-xxxxxxxxx/xxxxxxxxxxxxxx-xx- samordning/standarder/referansekatalogen). | A |
ID | Brukerstøtte | Krav- kode |
DT 3.1 | Brukerstøtte skal være tilgjengelig som permanent andrelinjesupport pr. epost og telefon, og som øyeblikkelig assistanse til et antall superbrukere. Responstid skal være umiddelbar. Alle supporthenvendelser skal loggføres. | B |
8.7 Krav til etableringsprosjektet
Disse kravene er også lagt inn i Bilag 3 - Plan for etableringsfasen. Kravene skal besvares i Bilag 3.
Tabellen under viser ønsket prosjekt- og framdriftsplan. Det vil være naturlig å justere denne i samråd med leverandør. Milepælene i tabellen under skal brukes som utgangspunkt for leverandørens prosjekt- og fremdriftsplan, jf. krav EP 1.1 under.
Milepæl | Dato | |
1 | Kontrakt er signert | November 2018 |
2 | Kunden har godkjent overordnet prosjekt- og fremdriftsplan | |
3 | Kunden har godkjent detaljspesifikasjon og fullstendige prosjektplaner | |
4 | Kunden har mottatt skriftlig melding om at løsningen er klar for Kundens godkjenningsprøve | |
5 | Leveringsdag | 1. november 2019 |
ID | Krav til plan for etableringsfasen (jfr. avtalens pkt. 3.1) | Krav- kode |
EP 1.1 | Leverandøren skal utarbeide plan for etableringsfasen, i samarbeid med kunden. Forslag til slik plan skal være med som en del av tilbudet. Planen skal minimum inneholde: ● beskrivelse av roller og ansvar (også knyttet til eventuelle installasjoner, konfigureringer, tilpasninger og/eller integrasjoner) ● prosjekt- og fremdriftsplan ● organisering av Leverandørens og Kundens ressurser for gjennomføringen av prosjektet ● hvordan samhandling og dialog mellom Leverandør og Xxxxx skal skje ● hvilken kompetanse og kapasitet Leverandøren og Kunden skal stille med ● beskrivelser og modeller som viser hvordan Trondheim kommunes føringer og sentrale arkitektur- og sikkerhetsprinsipper skal implementeres ● kritiske suksessfaktorer for etableringsprosjektet | A |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
EP 1.2 | Leverandøren skal beskrive hvilken prosjektmetodikk som benyttes ved gjennomføring av prosjektet | A |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
ID | Krav til kompetanse og tilgjengelighet | Krav- kode |
EP 2.1 | Leverandøren skal ha tilgang på nødvendig kapasitet til å kunne gjennomføre prosjektet. Leverandøren må dokumentere at han råder over ressurser som både har rett kompetanse og tilstrekkelig tilgjengelighet til å gjennomføre prosjektet | A |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
ID | Involvering og medvirkning | Krav- kode |
EP 3.1 | Leverandøren skal sammen med Kunden sikre involvering av brukere og brukertesting samt bruk av prototyping og pilot i utviklingen av løsningen. Kunden skal ha en aktiv rolle i design og utforming av løsning og prosesser så langt det er mulig. | B |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
ID | Krav til testing og risikostyring | Krav- kode |
EP 4.1 | Leverandøren skal gjennomføre risikostyring, samt gjennomføre egen testing og utarbeide testrapport med oversikt over alle feil som har blitt funnet med status. Dette skal leveres Kunden | A |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
EP 4.2 | Leverandøren skal benytte anerkjent metodikk og praksis for gjennomføring av test og feilretting. | A |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
EP 4.3 | Leverandøren skal planlegge og gjennomføre akseptansetesten med bakgrunn i følgende oppsett. Før oppstart: ● Skaffe til veie utstyr som skal brukes i testen ● Opplæring av testerne ● Brukerdokumentasjon og annet materiale testerne trenger ● Beskrive rutiner for hvordan testerne skal dokumentere og rapportere feil ● Skaffe til veie testdata ● Lage testbeskrivelser ● Lage plan over hvilken rekkefølge testene skal gjennomføres i som tar hensyn til eventuelle avhengigheter mellom testene Gjennomføring av testen: ● Administrere gjennomføring av testrundene ● Følge opp testerne, gi brukerstøtte ved behov ● Sjekke at feil lar seg reprodusere og kvalitetssikre feilrapporter før de sendes til Leverandøren for feilretting Avslutning: ● Forsikre seg om at alt som skulle testet er blitt testet ● Reteste de siste feilrettingene ● Kjøre regresjonstest ● Sikre at nivået på utestående feil er innenfor rammen av det som er avtalt | A |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
ID | Krav til dokumentasjon og opplæring (jf. avtalens pkt. 3.4) | Krav- kode |
EP 5.1 | Leverandøren skal stille med tilstrekkelig og kompetent personell til å gjennomføre nødvendig opplæring av superbrukere/veiledere. | A |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
EP 5.2 | Følgende dokumentasjon skal følge løsningen. Leverandøren forplikter seg til å levere ny eller oppdatert dokumentasjon ved endringer i løsningen krever dette. ● Brukerdokumentasjon: Standard dokumentasjon på bruk av løsningen for de ulike rollene systemet opererer med ● Systemdokumentasjon: Standard dokumentasjon som blant annet viser løsningens virkemåte, oppbygging og arkitektur | A |
All dokumentasjon skal være på norsk og gjøres tilgjengelig både papirbasert og elektronisk. | ||
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
ID | Krav til ytterligere utvikling etter leveringsdag (jf. avtalens pkt. 3.6) | Krav- kode |
EP 6.1 | Leverandøren skal være proaktiv og løpende vurdere endringer og forbedringer i egne tjenester for Kunden. | A |
Svarkode (1,2,3): Leverandørens besvarelse/beskrivelse: | ||
8.8 Krav til tjenestenivå med standardiserte kompensasjoner
Disse kravene er også lagt inn i Bilag 4 - Tjenestenivå med standardiserte kompensasjoner. Kravene skal besvares i Bilag 4.
ID | Standards tjenestenivå Kunden vil vurdere å legge Leverandørens standard tjenestenivåavtale til grunn for tjenesten. Hvis kunden betrakter at Leverandørens standard tjenestenivåavtale ikke vil være tilstrekkelig, vil alle eller deler av krav og beskrivelser i kapittel 8.9 legges til grunn. | Krav- kode |
TN 1.1 | Leverandøren skal legge ved sin standard tjenestenivåavtale som ligger til grunn for tjenesten | A |
TN 1.2 | Leverandøren skal synliggjøre hvilke kostnader som er knyttet til en utvidelse av tjenestenivå som går ut over Leverandørens standard tjenestenivåavtale. Det vises til oppfyllelse av samtlige krav til tjenestenivå. | B |
ID | Avregningsperiode | Krav- kode |
TN 2.1 | Avregningsperiode for utførte tjenester og eventuelle standardiserte kompensasjoner skal være etterskuddsvis hver kalendermåned. | B |
ID | Måleperiode | Krav- kode |
TN 3.1 | Måleperiode for alle tjenestene skal være månedlig (pr. kalendermåned). | B |
ID | Periode for driftstjenestene (driftstid) Driftstiden er summeproduktet av servicetid og serviceperioder innenfor en avregningsperiode. | Krav- kode |
TN 4.1 | Driftstiden i en avregningsperiode skal angis i minutter. | B |
ID | Servicetid Tid på døgnet tjenestene skal være tilgjengelig med avtalt tjenestenivå | Krav- kode |
TN 5.1 | Servicetid for driftstjenestene skal være kl.07.00 – 22.00. | A |
ID | Serviceperiode Den perioden, angitt i dager pr. uke pr. år, tjenestene skal være tilgjengelig med avtalt tjenestenivå innenfor avtalt servicetid. | Krav- kode |
TN 6.1 | Serviceperiode for driftstjenestene skal være alle virkedager (mandag – fredag) unntatt helligdager. | A |
ID | Endringsvindu Endringsvindu er det avtalte tidsrommet Leverandøren kan benytte til å utføre endringer som normalt vil gjøre tjenesten utilgjengelig. | Krav- kode |
TN 7.1 | Endringer skal være godkjente og begrunnet i nødvendig vedlikehold for å sikre kvaliteten på tjenesten. | B |
TN 7.2 | Leverandøren skal tilby Kunden endringsvinduer utenfor avtalt servicetid og serviceperiode | B |
ID | Avvik fra endringsvindu Haste endringer (Emergency Changes) som skal utføres så fort som mulig for å løse en Major Incident eller implementere en sikkerhetspatch. | Krav- kode |
TN 8.1 | Hasteendringer skal varsles øyeblikkelig til brukerne via Kundens Service Desk | B |
TN 8.2 | Hasteendringer som blir utført i tjenestens driftstid og som påvirker tjenesten tilgjengelighet vil normalt bli betraktet som nedetid. SLA kan fravikes i samråd med Kunden. | B |
ID | Feilrettings- og gjenopprettingstid. | Krav- kode |
TN 9.1 | Feil skal være rettet innen 1 time i tjenestens serviceperiode og servicetid | B |
ID | Gjennomføring av tjenestemåling | Krav- kode |
TN 10.1 | Alle måleresultater i forbindelse med tjenestenivåene som er beskrevet i dette Bilag, skal tilgjengeliggjøres for Kunden. Slik informasjon skal gjøres tilgjengelig for Kunden gjennom at informasjonen tilgjengeliggjøres online for Kunden og rapporteres akkumulert i månedlig tjenesterapport. | B |
ID | Målemetoder | Krav- kode |
TN 11.1 | Leverandørens skal beskrive hvordan beregning av brukeropplevd tilgjengelighet skal gjøres (målemetode) | B |
TN 11.2 | Leverandørens skal beskrive hvordan beregning av brukeropplevd responstid skal gjøres (målemetode) | B |
TN 11.3 | Leverandørens skal beskrive hvordan måling av øvrige tjenestenivå skal gjøres | B |
ID | Tjenestenivå Under dette punktet er tjenestenivå definert. Disse tjenestenivåene gjelder for alle tjenester dersom annet ikke er avtalt i tilknytning til den enkelte tjeneste | Krav- kode |
TN 12.1 | Tjenesten skal har en tilgjengelighet på 99,9 % | B |
ID | Standardiserte kompensasjoner | Krav- kode |
TN 13.1 | Standardisert kompensasjon knyttet til tilgjengelighet for og feilrettingstid skal beregnes av 100 % av månedlig kostnad for løpende levering av tjenesten, jf. Bilag 6 Krav til Samlet pris og prisbestemmelser. Samlet total kompensasjon for en periode er oppad begrenset til 100 % av fast månedlig kostnad for løpende levering av tjenesten. | B |
TN 13.2 | Leverandøren skal utarbeide grunnlaget for kompensasjonsberegningen. Kunden skal ha muligheter for kontrollere grunnlaget og beregning | B |
ID | Leveringstider | Krav- kode |
TN 14.1 | Standardisert kompensasjon knyttet til forsinkelse av leveranser bestilt etter at avtale er inngått beregnes ut fra totalpris gitt i tilbud. Se for øvrig tabell i kapittel 8.4. | A |
8.9 Krav til administrative bestemmelser
Disse kravene er også lagt inn i Bilag 5 - Administrative bestemmelser. Kravene skal besvares i Bilag 5.
ID | Partenes representanter (jf. avtalen pkt. 1.5 og 6.2) | Krav- kode |
AB 1.1 | Partene skal i god tid gjensidig orientere hverandre skriftlig om endring av kontakt- og nøkkelpersoner. | A |
AB 1.2 | Leverandøren skal opplyse om de underleverandører Leverandører vil benytte seg av i kontraktsperioden | A |
AB 1.3 | Leverandøren skal beskrive hvordan samhandling og dialog mellom partenes representanter skal skje | A |
AB 1.4 | Leverandøren skal legge ved CVer for nøkkelpersonell som vil bli benyttet til gjennomføring av kontrakten (kan legges ved som egne filer merket med CV og navn) | A |
ID | Samhandling | Krav- kode |
AB 2.1 | Det skal være tett dialog og samarbeid mellom Leverandør og Kunde både i utviklings- og innføringsfasen. Terskelen for å henvende seg til hverandre skal være lav. Begge parter skal være lett tilgjengelig for hverandre. | A |
ID | Varighet ( jf. avtalens pkt. 5.1) | Krav- kode |
AB 3.1 | Avtalens varighet skal være fra dato for kontraktsignering til 31.12.2024. Avtalen fornyes deretter automatisk for 1 (ett) år om gangen med mindre den sies opp av Kunden med 3 (tre) måneders varsel før fornyelsestidspunktet. Leverandøren kan si opp avtalen med 12 (tolv) måneders varsel før fornyelsestidspunktet. | A |
8.10 Krav til samlet pris og prisbestemmelser
Disse kravene er også lagt inn i Bilag 6 - Pris og prisbestemmelser. Xxxxxxx skal besvares i Bilag 6 og Bilag 6 – Vedlegg 1 Prismatrise digitale politikere
ID | Dokumentasjon og opplæring (jf. avtalens pkt. 3.4) | Krav- kode |
PB 1.1 | Alle kostnader forbundet med krav om dokumentasjon i bilag 1 skal synliggjøres ved at Leverandøren angir vederlag for etableringsfasen spesifikt | A |
ID | Generelle prisbestemmelser | Krav- kode |
PB 2.1 | Alle tjenester/funksjoner/prosesser som er beskrevet i bilag 1 dekkes av Leverandørens faste vederlag for drift og forvaltning, heretter omtalt som årlig drifts- og forvaltningskostnad | A |
PB 2.2 | Brukerstøtte og support skal inngå i leverandørens faste vederlag for løpende levering av tjenesten. | A |
ID | Oppgradering av tjenesten etter leveringsdag (jf. avtalens pkt. 3.5) | Krav- kode |
PB 3.1 | Alle typer endringer som Leverandøren trenger å gjennomføre for driftstjenesten for å ivareta ansvaret for driftsmessig kvalitet (tilgjengelighet, responstider, sikkerhet osv.) og avtalt tjenestenivå, skal være dekket av den årlige kostnaden for løpende levering av tjenesten | A |
Etableringsprosjekt | ||
PB 4.1 | Alle kostnader forbundet med etablering av leveranser og tjenester omfattet av denne avtalen skal synliggjøres ved at Leverandøren skal angi vederlag for etableringsfasen i prismatrisen. Vederlaget skal inkludere kostnader for reising, møter, opplæring mm. samt alle krav stilt til etableringsprosjektet i bilag 1 | A |
ID | Ytterligere utvikling etter leveringsdag (jf. avtalens pkt. 3.6) | Krav- kode |
PB 5.1 | Eventuelle tilleggstjenester utover det som er kravstilt i bilag 1 skal synliggjøres i tilbudet og oppføres i prismatrisen | A |
Milepæl | Prosentvis andel som skal betales ved milepelsoppnåelse | |
1 | Kontrakt er signert | 25% |
2 | Kunden har gjennomført leveranseprøve og har sendt leverandøren melding om at prøven er godkjent | 25% |
3 | Godkjenningsperioden er utløpt og kunden har sendt melding om at leveransen er godkjent (leveringsdag) | 40% |
4 | Utløp av garantiperioden | 10% |
Total | 100% |
Tabell 8