Request for Information (RFI) Mulig anskaffelse av verktøy for planlegging av releaser

Transkript

1 RFI SITS/UTV/PRO

2 Side: 2 av 19 Innholdsfortegnelse 1 Introduksjon Formål med RFI Om skatteetaten Om SITS RFIens struktur Krav til leverandørens besvarelse Datoer og fremdrift Sentrale begreper Innledende spørsmål Bakgrunn Bakgrunn for vurdering av nytt verktøy Suksessfaktorer Mål med nytt verktøy Moderniserte løsninger Generelle behov Planleggingsprosessen Releaseplanlegging Detaljplanlegging Produksjonsplanlegging Felles behov for release og produskjon Totaloversikt Rapporteringsbehov... 19

3 Side: 3 av 19 1 Introduksjon I de siste årene er det utviklet mange nye IT løsninger i Skatteetaten. Disse er utviklet av Skatteetatens IT avdeling; SITS, med bistand fra eksterne konsulenter. De nye løsningene omtales som moderniserte løsninger og består av komponenter og tjenester. Disse løsningene skal nå overleveres fra Skatteetatens utviklingsavdeling over til driftsorganisasjonen. I den forbindelse er det satt ned et prosjekt for å sikre denne overleveringen. Dette prosjektet omtales som SITS mottaksprosjektet. I forbindelse med dette prosjektet, ønsker SITS å vurdere i hvilken grad det skal investeres i et verktøy for å planlegge releaser og produksjoner på en effektiv og mer tilfredsstillende måte enn i dag. Det er derfor satt i gang en prosess for å vurdere i hvilken grad et finnes et standard system som kan brukes til disse arbeidsoppgavene. Skatteetaten har også en intern prosess for å vurdere i hvilken grad det er nødvendig eller gunstig å utvikle et slikt verktøy selv. 1.1 Formål med RFI Målet med denne RFIen er å gjøre mulig leverandører i stand til å vurdere om deres løsning vil kunne tilfredsstille Skatteetatens behov for verktøy i planleggingen av releaser og produskjoner. Denne RFIen inneholder behov som Skatteetaten har til en eventuell løsning på et overordnet nivå. Vi har et ønske om at en mulig leverandør også kan rådgi oss på hvordan SITS ved hjelp av verktøyet, kan jobbe effektiv og systematisk med planlegging. Skatteetaten har utarbeidet denne RFIen etter beste evne, og ønsker å gi et så godt bilde av våre behov som mulig. Eventuelle feil og mangler er ikke gjort med hensikt, og Skatteetaten fraskriver seg et hvert ansvar for skader eventuelle feil eller mangler i dokumentet påfører leverandør eller tredjepart. RFIen og informasjonen den inneholder er Skatteetatens eiendom og bruk av dokumentet utover intern bruk hos leverandører og involverte parter/underleverandører skal godkjennes av Skatteetaten. 1.2 Om skatteetaten Skatteetaten er underlagt Finansdepartementet og har ansvaret for et oppdatert folkeregister og at skatter og avgifter blir fastsatt og innbetalt på riktig måte. Totalt sett er det 6500 ansatte, som er fordelt på to organisatoriske enheter. Skattedirektoratets avdelinger og staber, som har den sentrale strategiske, faglige og administrative ledelsen av Skatteetaten Skatteetatens IT- og servicepartner, som er Skatteetatens leverandør innenfor IT og administrative tjenester omtalt som SITS Denne RFIen omhandler behov i SITS. RFI SITS/UTV/PRO

4 Side: 4 av Om SITS Skatteetatens IT- og servicepartners primære fagområde og -funksjoner er knyttet opp til rollen som kunde- og serviceorientert tjenesteleverandør. Leveransene til etaten og skatteyterne er basert på kravene fra bestilleren Innovasjon og utvikling i Skattedirektoratet. Leveransene fra SITS er i henhold til inngåtte tjenesteavtaler på det enkelte område. Dessuten skal SITS være en aktiv bidragsyter til utvikling av etaten. Skatteetatens IT- og servicepartner består av 5 avdelinger som leverer IT- og servicetjenestene (Planlegging, Utvikling, Tjenester, Administrative tjenester og Brukersenter). Stabsfunksjonen Styring koordinerer SITS virksomhet og leveranser, og sikrer samlet styring og rapportering på vegne av direktøren. Stabsfunksjonen Sikkerhet sørger for sikkerhet, informasjonssikkerhet og beredskap i Skatteetaten. 1.3 RFIens struktur Dette dokumentet er ment å gi en forståelse av SITS sitt arbeid med planlegging i dag. Vi har lagt vekt på å beskrive dagens situasjon så godt som mulig som prosess. I tillegg er det noen spørsmål til løsningen som skrevet i tabeller på relevante steder i dokumentet. I kapitel 2 har vi noen spørsmål til leverandøren. I kapttel 3 gir vi et bilde av de nye løsningene som SITS skal overta viderutviklingen av. I kapitel 4 har vi tatt for oss generelle behov som ikke er knyttet til en konkret arbeidsprosess. Videre vil vi beskrive arbeidsprosessene med relelase og produksjonsplanlegging i kapitel 5, mens behov for rapportering er kort beskrevet i kapittel Krav til leverandørens besvarelse Det er satt opp en del spørsmål til leverandøren, disse er presentert i en tabell og er nummerert. Vi ønsker at mulig leverandør besvarer disse i den rekkefølge de er presentert. Spørsmålene skal ikke oppfattes som krav fra Skatteetaten. Det ligger ved et svardokument som vi ønsker at leverandøren benytter i besvarelsen. Her er kapittel innledning identisk med RFI og alle spørsmåls tabeller er tatt med, slik at riktig nr forekommer. I deler av denne RFIen har vi skissert hvordan prosesser foregår i dag, og hvilke utfordringer vi ser for oss at vi kan få i fremtiden. I besvarelsen ønsker vi at leverandøren beskriver hvordan denne prosessen kan støttes og hvilke anbefalinger leverandøren har. Vi ønsker at leverandøren skal angi i tabellen om funksjonaliteten er standard, om den krever konfigurering eller om det er funksjonalitet som må utvikles. Dette skal angis på hvert enkelt spørsmål der det er relevant, hvor leverandøren skal bruke følgende angivelse: St. standard funksjonalitet Ko. Trenger konfigurering Ut. Trenger utvikling SITS ønsker at all funksjonalitet som beskrives som standard eller konfigurerbar kun er ferdig utviklet funksjonalitet. Vi ønsker ikke beskrivelse av planlagt funksjonalitet eller beta-versjoner. Slik funksjonalitet må da beskrives tilpasninger. En mulig leverandørs arbeid med denne RFIen er ikke fakturerbar.

5 Side: 5 av Datoer og fremdrift Tidsfrister og prosess med denne RFIen er som følger: Dato Beskrivelse Utsendelse av RFI Sendt ut til utvalgte leverandører og lagt ut på Dofin Mulighet for avklaringsmøter med ansvarlige for RFI Forespørsel sendes på e-post nevnt under Kl Svarfrist på RFI Sendes på e-post til adressen under All kontakt og spørsmål om denne RFIen skal skje til: Wenche Solberg på e-post: wenche.solberg@skatteetaten.no 1.6 Sentrale begreper I dette dokumentet brukes følgende begrep Begrep SITS Leveranse Release Releaseplan Releaseplanlegging Produksjonoppfølging Produksjonsplan Komponent Felleskomponent Deploy Forklaring Skatteetatens IT og Servicepartner, som er leverandør til Skatteetaten når det gjelder IT og servicetjenester. En ferdigstilling og overlevering av en del av utviklingsaktivitet En navngitt/spesifisert pakke for bruk i test eller produksjon. En plan over releaser og når de skal produksjonsettes. Følgende kan inngå i en releaseplan avhengig av nivå: - datoer for testing - dato for overlevering fra utvikling - dato for deploy Planlegging av releaser og aktiviteter for å utføre selve deploy av ny kode i et produksjonsmiljø. Oppfølging av etatens systemer i et produksjonsmiljø Plan for gjennomføring av produksjonsoppgaver En selvstendig hardware artefakt eller software kode /applikasjon Software eller applikasjon som har funksjonalitet som benyttes av flere tjenester eller applikasjoner Produksjonssette ferdigtestet kode i et produksjonsmiljø

6 Side: 6 av 19 2 Innledende spørsmål Skatteetaten ønsker innledningsvis følgende informasjon om mulige leverandører. Nr Forklaring Spørsmål 2.1 Kontaktinformasjon Informasjon om selskapsnavn, kontaktperson og kontakt informasjon 2.2 Referanser Oppgi 3 relevante kundereferanser 2.3 Produkt, tjenester og partnere Hvilke relevante systemer inngår i deres produktportefølje Hvilke relevante tjenester tilbyr dere Har dere partnere som kan være aktuelle å involvere i den videre anbudsprosessen 2.4 Prosjekttilnærming Hvordan ser dere for dere et implementerings prosjektet hos Skatteetaten på et overordnet nivå Hva vil implementeringen kreve av interne ressurser hos Skatteetaten Hva slags ressurser er det ev ønske om å trekke inn fra Skatteetaten sin organisasjon 2.5 Prismodeller Hvilke alternative prismodeller finnes for løsningen Hva er kostnadsdrivende innen hver av dem Lisenskost på brukere og servere 2.6 Tekniske krav Servere Software versjoner osv Andre krav

7 Side: 7 av 19 3 Bakgrunn Med omfattende modernisering av systemene til SITS så har etaten nye og mer komplekse behov for verktøy i planleggingen av relelaser og produksjoner. 3.1 Bakgrunn for vurdering av nytt verktøy Med nye løsninger melder deg seg et behov for å jobbe annerledes. Det å kunne analysere når det er gunstig og mulig å utvikle på en komponent er en ny måte å jobbe på for noen. I tillegg vil følgene av endringer og justeringer i planer underveis kunne få store konsekvenser for andre og dette må analyseres og vurderes løpende. Antall grensesnitt mellom komponentene og tjenestene vil øke betydelig og analyse av konsekvenser blir mer prekære. Planlegging blir en aktivitet som må gjøres løpende utover året i motsetning til nå, når dette gjøres på visse tider av året. SITS ønsker å vurderer et nytt verktøy for å effektivisere og kvalitetssikre relelase og produksjonsplanleggingen. Planleggingsverktøyet skal benyttes av alle andre fagsystemer også. Målet for SITS er å få et felles verktøy og en helhetlig plan for alle release og produksjonsplaner. 3.2 Suksessfaktorer Det å drifte felleskomponenter innebærer nye utfordringer for SITS. Suksess kriteriene for et slikt prosjekt vil være: Med den nye plattformen og de nye komponentene og tjenestene har vi behov for å kartlegge og ha oversikt over avhengighetene mellom komponenter og tjenester. Vi ønsker oss at dette kartlegges og vedlikeholdes automatisk. Release eller produksjonsplan for en komponent eller tjeneste vil får konsekvenser både for andre komponenter, prosjekter og produksjon. Derfor er det et behov for å få en total oversikt over releaser, produksjoner og avhengigehter mellom disse. 3.3 Mål med nytt verktøy Målsetninger med å investere i et nytt verktøy er følgende: Få en samlet oversikt over planlagte og produksjoner for hele SITS Få oversikt over avhengigheter mellom releasene Få en oversikt over alle avhengigheter mellom komponenter Få en systematisk og effektiv release og produksjonsplanlegging Få en komplett oversikt over hvillke versjoner som finnes i hvilke miljøer 3.4 Moderniserte løsninger De nye løsningene som omtales som moderniserte løsninger er i hovedsak Java applikasjoner som kjører på etatens nye applikasjonsplatform. Applikasjonsplattformen er en såkalt multi tenant/delt fysisk plattform med alt av tjenester virtualisert og eksponert som infrastruktur- og plattformtjenester (IaaS og PaaS). Det benyttes BMC ADDM, CMDB og BMC TrueSight for å holde oversikt og overvåke komponentene.

8 Side: 8 av 19 Softwareløsningene består av mindre komponenter som settes sammen for å bygge tjenester (tjenesteorientert arkitektur). En tjeneste kan være av både intern og ekstern art. Mange av software komponentene er det som SITS omtaler som Felleskomponenter. Felleskomponenter leverer funksjonalitet som kan benyttes av flere tjenester. Alle komponenter kan ha avhengigheter til andre komponenter, tjenester og fagsystemer. I tillegg vil det være avhengigheter til andre eksterne systemer slik som Altinn og NAV. Figur 1 Eksempel på modernisert løsning bestående av mange komponenter Vi ser for oss at det med de nye løsningene dukker opp nye utfordringer i planleggingen, men også videre i prosessen, når ny funksjonalitet skal deployes. For å skissere en mulig konflikt kan foregå slik :

9 Side: 9 av 19 Leveranse a Leveranse b Plan 1 Avhengighet Komponent A Komponent B Komponent C Plan 2 Kjøring1 Kjøring 2 Figur 2 Mulig konflikt med moderniserte løsninger Plan 1 innebærer endringer (Leveranse a og b ) i Komponent A og Komponent B. Plan 2 skal gjøre en omfattet kjøring 1 på Komponent A og Kjøring 2 på Komponent C. Vi ser for oss at Leveranse a har en deploy dato som blir flyttet og som da ikke kan gjøres samtidig med Kjøring 1. Eller det kan tenkes at Kjøring 1 må gjøres før Leveranse a. og at en ev flytting av Leveranse a og Kjøring 1 kan få konsekvenser som begge må forholde seg til. I tillegg kan det tenkes at fordi Komponent C har en avhengigheter til Komponent B så kan dette får konsekvenser for Leveranse b i denne modellen. På bakgrunn av denne arbeidssituasjonen ser vi for oss at vi trenger følgende: Nr Spørsmål 3.1 Finnes det muligheter for å automatisk kartlegge og vedlikeholde avhengighetene mellom de forskjellige komponentene? I tilfellet ja beskriv hvordan denne funksjonaliteten fungerer 3.2 Finnes det muligheter for å vise avhengigheter på en grafisk måte? I tilfelle ja leg ved skjermbilde av hvordan dette vil kunne se ut 3.3 Hvordan kan brukere få oversikt over hvilke komponenter som blir påvirket av oppgaver på en gitt komponent? 3.4 Kan brukere få en form for varsling dersom aktiviteter påvirker andre aktiviteter på samme komponent I tilfellet ja beskriv hvordan dette vil fremstå for brukeren 3.5 Kan brukere få en varsling om at en produksjonsjobb er planlagt samtidig som en avhengig komponent har andre aktiviteter I tilfellet ja, beskriv hvordan dette vil fremstå for brukeren.

10 Side: 10 av 19 4 Generelle behov SITS har behov for å vurdere løsningen på en overordnet plan. Dette er behov som ikke er knyttet til en gitt prosess. Dette gjelder hvordan tilgangstyringen er i løsningen, hvordan søk fungerer og muligheter for eksport og utskrift. Vi har for enkel hets skyld satt disse spørsmålene inn i en tabell men her er vi ute etter bekrivelse av hvordan leverandørens løsning håndterer dette. Nr Spørsmål 4.1 Beskriv applikasjonens tilgangsstyring 4.2 Kan det være "godkjenningsmekanismer" på visse felt? Altså at dersom en hendelse skjer, at noen må kunne godkjenne dette? Viss ja, beskriv 4.3 Beskriv søkefunskjonaliteten i løsningen Legg gjerne ved skjermbilder på hvordan dette kan se ut for en bruker 4.4 Hvilke utskriftsmuligheter finnes i løsningen 4.5 Hvilke typer filer kan eksporteres og importeres i løsningen?

11 Side: 11 av 19 5 Planleggingsprosessen I dette kapittelet er arbeidsprosessen beskrevet slik den er i SITS i dag. Dette er gjort etter flere brukerintervjuer som representerer de som jobber med release- og produksjonsplanlegging i dag. Et åpenbart trekk, som har vært tydelig, er at SITS har behov for å strømlinjeforme måten det jobbes med release og produksjonsplanlegging på. Det å innføre nye rutiner blir viktig i implementeringen av den nye løsningen. Det samme kan sies om begrepsbruken i etaten. Her brukes flere forskjellige begrep om samme ting. SITS definerer seg som en prosjektorganisasjon basert ITIL. Nr Spørsmål 5.1 Kan løsningen støtte opp om ITL, Cobit eller andre standarder for prosess? I tilfellet ja, vennligst beskriv hvilken standard 5.2 Benytter løsningen det samme begrepsapparatet som dette dokumentet gjør? Beskriv eventuelle forskjeller på begrep bruk slik de vil fremstå for en bruker 5.1 Releaseplanlegging Det foregår i dag releaseplanlegging både i prosjekter og i linjen. Utgangspunktet for all releaseplanlegging er bestilling av nyutvikling eller endring av eksisterende systemer. I tillegg kan også feilretting være utgangspunkt for en release. En release består som oftest av et sett av bestillinger og leveranser, men forholdet mellom disse er ikke nødvendigvis hierarkisk. Releaseprosessen starter ved at en leder eller prosjektleder oppretter en plan for en release. Mer detaljer rundt bakgrunnen for planen er beskrevet i kap I tillegg blir alla releaseplaner sammenstilt til en totaloversikt. Dette er med beskrevet i kap 5.4 Vi har skissert den overordne arbeidsflyten prosessen slik:

12 Side: 12 av 19 Totaloversikt Releaser SITS Bestillinger Releaseplan System 1 Leveranser Oppgave Releaseplan System 2 Oppgave Releaseplan Prosjekt Oppgave Oppgave Testere og test ledelse Utviklere Utvikling Test Testmiljø Deploy Ansvarlig Produksjons miljø Prod setting Jira /Confluence Filserver/SharePoint Qualety Center Figur 3 Overordnet arbeidsprosess release En releaseplan er en sammenstilling av bestillinger og aktiviteter som skal utføres og deployes. Disse blir her omtalt som oppgaver. Oppgavene fordeles først til utviklere som utvikler i henhold til spesifikasjon. Det vil ofte være prioriteringer av oppgaver og flytting av ferdigstillelse dato i denne prosessen. Dette er det prosjektleder/leder som følger opp daglig. Justeringen av planene foregår manuelt, og det er i dag ingen sammenheng mellom en gitt releaseplan og totaloversikten. I tillegg blir fremdrift på et overordnet nivå rapportert manuelt fra utviklingsavdelingen til bestiller av endringer og andre instanser. Vi ser at det er vanskelig å begrense prosessens stoppunkt mot andre prosesser. En plan vil alltid inneholde oppgaver som går ut over planlegging/ utvikling og treffer både test - og deployprosessen. I testprosessen er det også noen utfordringer i forhold til å planlegge bruken av testmiljø og testdata på en optimal måte. I testfasen går også oppgaver mellom testere og utviklere, slik at overgangen her er ikke absolutt. Som støtte i releaseplanleggingen brukes det i dag en stor mengde forskjellige verktøy. Blant annet er Excel, Jira, PowerPoint og Quality Center i bruk.

13 Side: 13 av 19 Nr Spørsmål 5.3 Beskriv hvordan systemets arbeidsflyt er satt opp som standard 5.4 Beskriv hvordan leverandøren vil tilpasse deler eller hele løsningen til å passe til prosessen slik den er beskrevet her 5.5 Finnes det også støtte for tilstøtende arbeidsoppgaver slik som testplanlegging, booking av testmiljø og data samt deploy? 5.6. Finnes det standard integrasjoner mellom løsningen og andre verktøy slik som Jira, Quality Center og ev andre? 5.7 Hvor mange nivåer er det i en plan Her har vi plan og release, kan det være flere nivåer på en plan? 5.8 Er det muligheter å sette opp en workflow ved visse hendelser? Altså at systemet gjennomfører aktiviteter dersom feks en dato på en release endres? Detaljplanlegging Planleggingen starter som regel med en kartlegging av behovene og en utredning for nyutvikling og endringer i kommende periode. I denne inngår også en kapasitetsanalyse for å avgjøre mengden utvikling som er mulig å gjennomføre. I tillegg koordineres det mot produksjonen, for å påse at eventuell utvikling ikke kommer i konflikt med produksjonen. Når man har en prioritert oversikt over alle utviklingsaktivitetene settes det opp en releaseplan for perioden hvor man fordeler de forskjellige releasene på en viss antall hovedreleaser. Antallet varierer mellom de forskjellige prosjektene og systemene. Dette er som oftest avhengig av mengden utvikling, type utvikling, avhengigheter til andre løsninger osv. Innputt: Bestillinger Plan 1 Plan 2 Påvirkning: Ressurser Test og testdata Produksjoner Miljøer Plan n Figur 4 Påvirkningsfaktorer på planer I tillegg til å planlegge releasene blir om bruken av utvikling- og testmiljøer vurdert. Det blir satt opp en plan for hvilke miljøer som må være tilgjengelig for hvilke releaser, først og fremst for å kunne har miljøene klare til riktig tidspunkt, men også for å kunne reservere bruken. Dette for å unngå konflikter. Ikke alle utviklingsbehovene er kjente ved starten av en periode. Gjennom perioden kommer det inn nye bestillinger for utvikling, i tillegg til rettinger på feil som er blitt oppdaget i forvaltningen. Det gjøres en

14 Side: 14 av 19 fortløpende vurdering av om disse nye aktivitetene skal gjennomføres og produksjonssettes eller ikke. I disse vurderingene ligger også om aktivitetene passer inn i den eksisterende releaseplanen som er valgt. I noen tilfeller er de nye punktene såpass viktige at det planlegges ekstra releaser. Disse kan enten være ekstra hovedreleaser eller bli håndtert i såkalte hurtigreleaser. Størrelsen og kritikaliteten på aktiviteten er med på å avgjøre type release. Denne releaseplanlegging i de enkelte prosjektene og enhetene har frem til nå vært utført veldig adskilt, uten behov for å ta hensyn til andre enn prosjektet eller linjens egne behov. Dette har også påvirket både størrelsen på releasene, hyppigheten og hvilke verktøy som er brukt. Noen systemer har hatt hyppige små releaser mens andre har lagt opp til få store med mulighet for mindre hurtigreleaser innimellom. Med introduksjon av nye løsninger basert på felleskomponenter og smidig utvikling er det nå behov for en endring i denne arbeidsmåten. Enhetene må nå håndtere mange flere avhengigheter og ta hensyn til andre enheters releasesykluser. Prosessene må da inkludere steg for koordinering mellom prosjektene og systemene både på planleggingsstadiet, men også fortløpende. Det er tydelig allerede nå dette ikke lar seg gjøre uten et godt verktøy som støtte i dette arbeidet. Figur 5 Skisse på nivåer av releasplanlegging Skissen viser forholdet mellom de forskjellige nivåene i en evtuell releaseplan som brukes på overordnet nivå. Dette er ikke en reel plan slik den blir laget i dag eller slik det kan tenkes å bli, men mer en skisse for å kunne forstå oppbyggingen av dataene bedre. Første nivå i skissen er versjonsnummer av plan. Det er ønskelig å kunne lage flere versjoner av planer for å kunne vise hvordan forskjellige beslutninger påvirker innholdet. Det kan lages mange slike versjoner, men kun en versjon bør være markert som endelig.

15 Side: 15 av 19 Nivå to viser system og prosjekter som inngår i planen. Optimalt bør alle systemene og prosjektene som har egne releaseplaner være representert på dette nivået. Nivåene tre til seks er tenkt å være data hentet fra releaseplanene til de enkelte systemene, og inneholder informasjon om hvilken release som planlegges, hvile releaser som inngår og hva som inngår i de forskjellige leveransene. Skissen viser også hvordan de forskjelige leveransene kan ha avhengigheter til hverandre. 5.2 Produksjonsplanlegging De som jobber i produksjonen i SITS har ansvaret for at etatens tjenester kjører og leverer som avtalt. Produksjonen består av både teknisk og faglig personell for å kunne ivareta alle aspekter av de tjenestene som blir levert. Drifting av selve systemene gjøres av egne driftsavdelinger enten internt eller eksternt. Typiske arbeidsoppgaver i produksjonen er: Planlegge nødvendige aktiviteter i et system i løpet av et år inkludert tidspunkter for release Kjøring/bestilling av batchjobber både manuelle og automatiske Oppfølging av batchjobber Oppfølging av hendelser i systemene Koordinering av feilretting i systemene mot tekniske og faglige miljø Koordinering av ad-hoc kjøringer i systemene De moderniserte løsningene kjører kontinuerlig og automatiserer mye av denne type jobb. Det vil likevel være nødvendig å planlegge hvordan systemene skal følges opp slik at de leverer tjenestene på en god måte.. Dette kan skisseres slik:

16 Side: 16 av 19 Tjenesteansvarlig Tjenesteplan Års hjul Produksjonsplan1 Kjøreplan1 Produksjonsplan 2 Kjøreplan 2 Drift og produksjons personell Produksjonsplan n Kjøreplan n Ev ekstern leverandør Figur 6 Arbeidsflyt Produksjonsplanlegging Arbeidsoppgavene her er knyttet til å planlegge produksjonen i løpet av året på flere nivåer. På øverste nivå planlegges releasene i hvert av etatens overordnede tjenester (som f.eks. selvangivelsen eller skatteoppgjør) Dette er noe tjenesteansvarlig gjør. Dette planleggingsarbeidet tar ofte planen fra året før og lager en justert plan ofte i forhold til faste deadlinenes som er lovpålagt, slik som innleveringsfrist for selvangivelsen. Planen som brukes er ofte et Excel ark som har utviklet seg over tid. Disse tjenesteplanene blir så benyttet av de som har produksjonsansvaret for hvert av etatens systemer til å bygge opp produksjonsplaner for sine systemer slik at de tilsammen leverer i henhold til tjenesteplanen. Dette betyr at milepæler fra tjenesteplanene går igjen i produksjonsplanene. Produksjonsplanene består vanligvis av et annet Excel ark. Det er ingen automatikk mellom statuser og informasjon i disse forskjellige Excel arkene. I tillegg finnes det detaljerte kjøreplaner for sammensatte aktiviteter i produksjonsplanen (f.eks. kjøring av script og utføring av aktiviteter i et system ved feilretting eller koordinering av store hendelser så som produksjon av selvangivelsen). Kjøreplaner kan også gå på tvers av systemer. Disse detaljerte kjøreplanene lages gjerne i Excel ark eller WIKI side som inneholder en plan om hvilke jobber eller kjøringer som skal eksekveres i hvilken rekkefølge. All rapportering som at kjøringer er uført skjer manuelt. Statusrapporteringen mellom Tjeneste ansvarlig og drifts og produksjonspersonell foregår i møteaktiviteter som i travle perioder gjøres daglig.

17 Side: 17 av 19 For en avdeling så utføres selve kjøringen av en ekstern driftsleverandør som benytter verktøyet Tivoli. Dette verktøyet kan ansatte i SITS bruke for å overvåke hvilke kjøringer som har blitt kjørt osv. Men i stor grad så sendes bestillingene av kjøringene til ekstern leverandør på Excel ark. Kvitteringen for at kjøringer er gjort kommer også tilbake i form av et Excel ark. Nr Spørsmål 5.9 Produksjon har et mer detaljert sett av planer enn det release har, Beskriv hvordan Produksjonplanlegging kan fåregå i den nye løsningen 5.10 Kan løsningen eksportere kjøreplaner og kjøringer i maskinlesbare format? I tilfelle ja hvilke? 5.11 Kan en plan kopieres og være grunnlag for ny plan? 5.12 Finnes det mulighet for å lage malplaner? 5.13 Hvordan delegerer brukere ansvar for oppgaver 5.14 Kan oppgaver delegeres til personer, team eller begge deler? 5.16 Kan utførtstatus på en kjøreplan automatisk oppdateres på en produksjonsplan og en tjenesteplan? 5.17 Finnes det dashbord eller lignende funksjonalitet som vil gi en bruker oversikt over de planer og oppgaver som er delegert til seg? Vis gjerne eksmepler 5.3 Felles behov for release og produskjon Felles for både release og produksjonsplanleggingen har vi følgende spørsmål: Nr Spørsmål 5.18 Kan systemet varsle på noen typer hendelser, slik som endring av datoer osv. viss ja: Hvordan defineres det når det skal varsles? Beskriv gjerne hvordan dette fungerer På hvilket format kan det varsles: I løsningen E-post SMS Andre? 5.19 Kan brukeren selv definere hvordan og hvem som skal varsles? Viss ja beskriv funksjonaliteten 5.20 Kan det varsles dersom noe ikke skjer, altså vis en tidsfrist overskrives uten at aktiviteter blir utført? Viss ja beskriv hvordan dette settes opp og hvordan det vil fungere for brukern 5.21 Kan systemet varsle andre (ledere) dersom noe ikke blir utført etter at en tidsfrist er overskredet Viss ja beskriv hvordan dette settes opp og hvordan det vil fungere for brukern 5.22 Visse oppgaver skal altid gjenomføres, slik som test og deploy. Kan en opprette faste oppgaver som alltid skal utføres i en plan? Beskriv gjerne 5.23 Kan det opprettes maler av planer som er like? Viss ja beskriv hvordan dette settes opp og hvordan det vil fungere for brukern 5.24 En bruker må kunne flytte på en aktivitet, hvordan vises dette oppover i hierarkiet? Viss ja beskriv funksjonaliteten 5.25 Hvordan vises konflikter mellom kjøringer/releaser 5.26 Er det mulig å legge inn "låste" perioder på system. Dette gjelder særlig ved vedlikeholdsarbeid, beskriv gjerne hvordan dette gjøres

18 Side: 18 av Totaloversikt I tillegg til de enkelte prosjekters og avdelingenes release- og produksjonsplanlegging er det også behov for å kunne planlegge på tvers av SITS. Det er behov for å se hvordan de forskjellige release og produksjonsplanene påvirker hverandre, hvor det finnes avhengigheter og hvordan dette påvirker den totale kapasiteten. Med en slik oversikt kan man prioritere de releasene som påvirker kritisk linje samt planlegge å forberede produksjonssetting i rett rekkefølge. Behovet er økende ved økt bruk av felleskomponenter. Forvaltningsenhetene har også etterlyst en samlet oversikt over planlagte produksjonssettinger for å kunne prioritere og planlegge produksjonssettingen slik at forberedende aktiviteter er ferdigstilt i god tid. SITS er avhengig av å ha kjennskap til konsekvensen av en forsinket release og påvirkning av dette på andre avhengige releaser og produksjoner. På samme måte vil endringer i produksjoner få konsekvenser for releaser. Derfor er det et behov om å kunne se releaser og produksjonsplaner separat og sammenstilt. I dag lages denne type oversikter ved at ledere/ prosjektledere sender inn data om sine releaser. Utviklingsleveranser sammenstiller så disse opplysningene til en felles oversikt i Excel, som så blir publisert og gjort tilgjengelig for alle interessenter. Manuell oppdatering Plan 1 Manuell oppdatering Manuell oppdatering Plan 2 Plan n Figur 7 Manuell sammenstilling av enhetenes planer Hele prosessen er en manuell og tidskrevende operasjon som krever at både de som melder inn data og de som sammenstiller det bruker en god del tid på å holde oversikten oppdatert. Dette føles som tungvint å unødvendig å måtte kopiere og sammenstille data som allerede finnes elektronisk i de enkelte prosjekt og linjens systemer

19 Side: 19 av 19. Nr Spørsmål 5.27 Kan løsningen aggregere opp mindre planer til en sammenstilling av alle planer i hele SITS? Viss ja beskriv funksjonaliteten 5.28 Finnes det grafiske fremstillinger av planer i forhold til hverandre I forhold til en timeline eller kalender som viser alle planer og aktiviteter i SITS Vis gjerne med skjembilder hvordan dette kan se ut 5.29 Dersom endringer skjer i en plan, f.eks. at en dato endres, vil det da også oppdatere seg i en opp- aggregert oversikt? 5.30 Kan ev en slik opp- aggregert oversikt printers ut 5.31 Vil det være mulig å gå rett fra en slik opp- aggregert oversikt og til en av de planene den er aggregert av? 6 Rapporteringsbehov I SITS trengs det rapportering på flere nivåer. Det er behov for å rapportere oppover i planen på aktiviteter som er gjort og det er et behov for å ta ut månedlig status på fremdrift. Vi ser for oss at Rapporteringsbehovet er økende etter implementering av en nye løsning. Vi ønsker at leverandøren beskriver hvordan rapportering utvikles eller settes opp i løsningen. Vis gjerne skjermbilder. I tillegg ønsker vi svar på følgende konkrete spørsmål Nr Spørsmål 6.1 Beskriver hvordan rapportering utvikles eller settes opp i løsningen. Vis gjerne skjermbilder 6.2 Hvilken kompetanse må man ha for å lage og endre på rapporter 6.3 Kan rapporter eksporteres til andre format i tilfelle hvilket format?