SSA-K Bilag 1 Kravspesifikasjon i forbindelse med Anskaffelse av system for behandling av skoleskysselever i Vestfold

Transkript

1 SSA-K Bilag 1 Kravspesifikasjon i forbindelse med Anskaffelse av system for behandling av

2 Innholdsfortegnelse: 1 Innledning Leveransen Roller Definisjoner Krav til leverandør og leveranse Krav til prosjektledelse Krav til systemets sentrale enheter/ database Krav til løsning og funksjonalitet Krav til grensesnitt Krav til dokumentasjonen Opplæring Vedlikehold og support Endringslogg Side 2 av 18

3 1 Innledning Vestfold Kollektivtrafikk AS (VKT) inviterer leverandører til tilbudskonkurranse for Anskaffelse av system for behandling av. Oppdragsgiver Vestfold Kollektivtrafikk AS ble stiftet i 1998 med ansvar for kollektivtransporten i Vestfold. I perioden 2006 til 15. August 2015 ble oppgavene håndtert av Vestviken Kollektivtrafikk AS som ble startet i 2006 for å håndtere tilsvarende oppgaver i Buskerud, Telemark og Vestfold. Fra og med den 15. August 2015 overtok Vestfold Kollektivtrafikk igjen ansvaret for kollektivtrafikken i Vestfold. Vestfold Kollektivtrafikk AS har ansvaret for transport for alle elever fra 1 til 10 klasse og videregående skole. Det er 14 kommuner som er bestillere for elevene i grunnskolen og fylkeskommunen som er bestiller for skyss for de videregående elevene. System for behandling av skoleskysselever skal omfatte grunnskoler og videregående skoler i Vestfold. Skoleskyssen i Vestfold skilles på to ulike typer transportmetoder, ordinær skoleskyss med buss og tilrettelagt skyss, som hovedsakelig er transport med Taxi og minibuss. Det er ca 6000 elever som har krav på ordinær skoleskyss i Vestfold og det er i tillegg ca 1100 personer som har krav på tilrettelagt skyss. Det er i Vestfold i dag 230 busser som frakter ordinære skoleelever på ordinære ruter eller egne skoleruter. På tilrettelagt skyss er det ca 30 minibusser og et stort antall ordinære taxi som frakter elever fra hjemsted til skole. 2 Leveransen VKT ønsker å gå til anskaffelse av programvare som kan behandle elever med behov for ordinær skoleskyss og elever med særskilte transportbehov. Løsningen skal løse følgende hovedoppgaver og egenskaper Registrering av skysselever for videregående elever, hvor elevene selv søker via digitale søknadsprosess på web o Automatisk behandling av søknader for elever i videregående skole basert på avstand mellom hjem og skole. Registrering og behandling av søknader for elever i grunnskolen Registrering og behandling av søknader for elever som har behov for tilrettelagt skyss, hvor skolene søker på vegne av elevene via internett o Transportørene skal kunne gis tilgang til å trekke ut sine transportoppdrag i systemet Eventuelle funksjoner som ikke er særskilt spesifisert av VKT i denne spesifikasjon, men som er standard i leverandørens system, skal inngå i leveransen til den pris og øvrige betingelser som ligger til grunn for tildeling av kontrakten. Side 3 av 18

4 3 Roller I dette dokumentet menes med: Oppdragsgiver: Leverandør: Tilbyder: Underleverandør: Vestfold Kollektivtrafikk AS forkortet til VKT. VKT vil være kontraktspart og oppdragsgiver for den Leverandør som tildeles kontrakt om oppdrag i VKTs Konkurranse om Elevbehandlingssystem i Vestfold Det selskap som inngår kontrakt om utførelse av oppdrag i VKTs Konkurranse om «Anskaffelse av system for behandling av skoleskysselever i Vestfold» Et selskap som deltar i Konkurranse om å komme i betraktning som Leverandør Et selskap som Leverandør benytter for å utføre deler av leveransen 4 Definisjoner Skoleskyss-systemet Systemet som spesifiseres i dette dokument. Ordinær skoleskyss Elever som skal ha skolekort og som skal benytte seg av det ordinære busstilbudet eller skolebuss Tilrettelagt Skyss Elever som av ulike grunner hovedsakelig skal ha skyss med Taxi eller minibuss som følge av permanent eller temporær bevegelseshemning, funksjonshemning, sykdom, farlig skolevei etc. Bestiller Den som registrerer en bestilling om skyss, ofte er dette en kommune. Den som bestiller kan helt eller delvis betale for transporten. Behandler En behandler er i all hovedsak en ansatt hos Oppdragsgiver og er administrator i systemet. En behandler har myndighet til å godta eller avslå en skyss-søknad. Bruker En bruker er en person som har en rettighet til å utføre en operasjon i system. Oppflytting En funksjon som gir mulighet til å flytte elever for eksempel en hel klasse opp til et nytt skoleår og klasse ved skoleårets slutt for gjenbruk neste skoleår. Side 4 av 18

5 Skolerute En oversikt over hvilke dager som er angitt som skoledager gjennom et skoleår. Skoleruten er i stor grad felles for hele Vestfold. Det finnes unntak for enkelte skoler i Vestfold. Det finnes også egne skoleruter i Buskerud og Telemark som skal kunne benyttes av systemet Trinn Angir om det er for eksempel første, andre, tredje år eleven går på skolen. Klasse Angir om det er a, b, c klasse. Klassekode med flere tegn for videregående skole. Klasse kan bestå av både nummer og tegn. Timeplan Angir skoledagens start og sluttider for de forskjellige trinn / klasser for elever med tilrettelagt skyss. En elev kan ha to ulike timeplaner, en for like uker og en for ulike uker. Timeplanen blir kun benyttet for elever for tilrettelagt skyss. Skolekort Ordinære skolekort for bruk på ordinær busstransport. Kan benyttes på skoleruter eller ordinære ruter i hele fylket. På sikt er det aktuelt og tilby skolekort på flere ulike medium. Det mest nærliggende er å tilby elevene skolekort på mobil, i tillegg til dagens plastkort. (Mifare Desfire) Billettsystem Det finnes elektroniske billettmaskiner i alle busser i Vestfold. Systemet er levert av Fara Transportør Et selskap som utøver transport på vegne av VKT Transportenhet Et kjøretøy som transportør benytter til å utføre transport til og fra skole. Side 5 av 18

6 5 Krav til leverandør og leveranse Leveransen skal inneholde løsning og tilhørende lisenser som skal gjelde for områdene Vestfold. Leveransen har følgende overordnede krav: 1. Leverandøren må vise til og ha referanser fra minst 5 tilsvarende leveranser som spesifisert i dette dokument. 2. System skal kunne håndtere alle skysselever i Vestfold, både elever med ordinære og behov for tilrettelagt skyss 3. All behandling og parametersetting av elever som skal ha ordinære skolekort skal kunne utføres i skoleskyss-systemet 4. Systemet skal inneholde modul for digital søknadsprosess for elever via WEB. Alle skoler skal ha sin egen bruker som skal kunne logge seg på registreringsløsningen og foreta registreringer og administrative operasjoner. 5. Løsningen skal kunne foreta avstandsmåling mellom hjem og skole for en elev og på bakgrunn av dette foreslå om eleven skal få godkjent skoleskyss eller ikke. 6. Transportørene skal kunne gis tilgang til sine transporter i systemet via WEB Illustrasjon 5.1: dataflyt i systemet Side 6 av 18

7 6 Krav til prosjektledelse Det stilles krav til håndtering av prosjektet 1. Leverandøren skal stille med en dedikert prosjektleder som sammen med prosjektleder i VKT skal håndtere alle tekniske, organisatoriske og merkantile forhold knyttet til prosjektet og leveransen. 2. Leverandøren skal rapportere leveransestatus hver måned i prosjektet. I tillegg til den regelmessige rapportering skal hovedleverandøren umiddelbart og uoppfordret rapportere til VKT ved enhver forsinkelse som måtte oppstå i forhold til tidsplan, herunder gi alle opplysninger som kan ha innvirkning på tidsplanen. Enhver rapportering skal skje skriftlig via e-post til prosjektleder i VKT 3. Oppdragsgiver skal på en ukes varsel kunne kalle inn til prosjektmøte med leverandøren dersom oppdragsgiver mener det er behov for dette. 7 Krav til systemets sentrale enheter/ database Med sentral enhet menes en eller flere applikasjoner som skal driftes fra VKT sitt hovedkontor (Sentralsystemet), hvor informasjon lagres på en eller flere databaser. 7.1 Generelle krav til sentrale enheter: 1. Kapasiteten til systemet skal være dimensjonert til å kunne håndtere inntil søkere/elever 2. Alle brukeroperasjoner i systemet skal foregå uten opplevd ventetid og designet skal være intuitivt og alle brukeroperasjoner skal utføres med færrest mulige tastetrykk 3. Skoleskyss-systemet skal minimum være tilgjengelig for alle typer brukere mellom og Skoleskyss-systemet skal lokaliseres hos oppdragsgiver på angitt server og VKT skal ha ansvaret for den daglige driften av server og applikasjon 5. Databasen skal være SQL-basert og kunne håndtere alle transaksjoner som genereres i systemet, fortrinnsvis MS-SQL 6. VKT skal ha tilgang til tabellverk for å kunne utnytte rapportering og effektiv drift og kontroll av systemet. 7. Alle applikasjoner skal kunne kjøres på VMWARE og/eller CITRIX 8. Tekst som vises i sentrale brukermenyer i systemet skal være på norsk bokmål. VKT skal godkjenne hver enkelt bruk av engelsk. 9. Alle applikasjoner på PC skal kunne kjøre på Windows 7 eller nyere 10. Servere skal kjøre på Windows 2008 server eller nyere Side 7 av 18

8 11. I webapplikasjonen skal det minimum kunne benyttes Internett Explorer, Chrome, Firefox, Opera og Safari. Det er foretrukket at løsningen er responsiv. 12. Felt som skal inngå i løsningen Følgende felter skal registres for en elev som søker om ordinær skoleskyss: o FaraElevId o ElevId o Etternavn o Fornavn o Fødselsnummer o Postadresse 1-2 o Adresse 1-2 o Telefon 1-2 o Mailadresse o Kortnummer o Kommunenummer/Kommunenavn o Skolenummer/Skolenavn o Kommentarfelt 12.2 Følgende felt skal kunne registreres av skolene ved søknad om tilrettelagt skyss Se eget vedlegg A 7.2 Krav til sikkerhet 1. All overføring av data mellom delsystemene skal være tilstrekkelig sikret, uten å miste data. 2. Driftsregulariteten skal opprettholdes minst 7 år. Systemets nedetid skal være max 1 % pr. måned mellom Det skal finnes en endringslogg i databasen som sier noe om når en endring har skjedd, hva og hvem som har gjort endringen. 4. Løsningen skal håndtere sensitive opplysninger og må ivareta dette i henhold til det gjeldende regelverk og ivareta sikker pålogging til applikasjonen 5. Systemets skal bestå av forskjellige rettigheter på ulike type brukere. Eksempel på ulike roller og rettigheter er: o Bruker/Søker skal kunne skrive søknad for seg selv eller på vegne av sine barn eller elever på sin skole. Disse skal kunne legges inn fortløpende og registreres i databasen. o Skoleadministrator skal ha anledning til å kunne se på elever ved sin skole o Søknadsbehandler: som har anledning til å editere alle elever i databasen og gjøre nødvendig behandling og godkjenning av skyss for eleven o Administrator skal ha alle rettigheter o Transportør skal ha rettigheter til å hente ut turer og informasjon om elever for sine turer Side 8 av 18

9 7.3 Krav til grunndata Grunndata skal kunne legges inn av utvalgte grupper/brukere og skal kunne endres/slettes. Som et minimum skal følgende grunndata håndteres i systemet. 1. Kommuner o KommuneId o Kommunenavn 2. Skoler o SkoleId o Skolenavn o SkoleKlasseId o SkoleKlasse o Skoletype (Videregående Skole/Grunnskole) o Klassetrinn (Grade) 3. Transportører o Transportører o Oppdragsgivere (Bestiller) 4. Skoleruter Systemet må håndtere flere Skoleruter hvor en elev skal være tilegnet en skolerute Som default skal verdien eleven tildeles være skoleruten for Vestfold fylke. Det skal være mulig å velge andre skoleruter Skolerute for Buskerud Skolerute for Telemark Spesifikke ruter for enkelte skoler Side 9 av 18

10 8 Krav til løsning og funksjonalitet 8.1 Søknadsprosess og behandling Eleven/bestiller skal benytte samme portalen uansett om det er en søknad på ordinær skoleskyss eller tilrettelagt skyss. Denne portalen skal lokaliseres under vkt.no/skoleskyss. Illustrasjon 8.1, søknadsprosess Krav til webportal for søknadsprosess 1. En søker kan være en elev eller noen som søker på vegne av eleven (Bruker) o Elev o Elevens foresatte o Skole o Kommune o Behandler 2. Alle som søker må først opprette en bruker i systemet. Brukeren blir først opprettet etter en sikker verifisering av mailadresse eller mobiltelefonnummer. 3. Når en kommune søker ordinær skoleskyss på vegne av en elev er hovedregelen at søknaden er ansett av behandler for å være godkjent og skal merkes spesielt slik at behandlingen videre blir forenklet. Det skal være mulig å omgjøre vedtaket. 4. Systemets modul for registrering av søknader skal være web basert og kreve sikker innlogging. En registrering av en elev forutsetter en bruker. o Ved registrering av en ny bruker må det foreligge en sikker verifisering. Side 10 av 18

11 5. En bruker må opprette en profil med minimum informasjon: o Personnummer o Fornavn o Etternavn o Mobiltelefon o E-post 6. Løsningen skal inneholde funksjonalitet for å endre passord og for å lage nytt passord dersom brukeren har glemt dette. 7. Ved hjelp av mailadresse skal det være mulig å få tilsendt brukernavn 8. Søkere skal starte søknadsprosessen med fylle ut et digitalt skjema i en og samme vindu/portal. Søkerens valg skal bestemme hvilke felter som blir tilgjengelig. o Ordinære skoleskysselever o Tilrettelagt skysselever o Ulike årsaker til behov for tilrettelagt skyss 9. En bruker skal kunne rapportere et skolekort som mistet, og bestille nytt kort via portalen. Denne muligheten må være mulig å aktivere/deaktivere for ulike typer søknader 10. Det skal være mulig å importere søknader for elever på en eller flere skoler via spesifisert filstruktur som xls, csv eller lignende Behandling av søknader 1. Det skal være muligheter for å kvalitetssikre informasjon fra søker via andre offentlige registre. o Folkeregisteret o Feide o Inntaksregister i fylket 2. Elever i den videregående skole skal automatisk få svar når søknaden er sendt basert på geografi og avstand mellom hjem og skole (6 km). (ref pkt 8.2) 3. Behandler skal godkjenne søknader om skyss og sende ut avslag eller vedtak til søker via systemet. 4. En bruker skal kunne lese vedtak i portalen. Det skal kunne sendes ut varsel om vedtak til registrert mailadresse for den enkelte søker. Det skal også være mulig å sende varsel om vedtak på SMS. 5. Det skal finnes muligheter for søker å klage på et vedtak 6. Behandlere av søknader skal ha et brukervennlig behandlingsvindu hvor mest mulig informasjon er synlig i et og samme vindu. Enhver handling skal utføres med færrest mulig tastetrykk. 7. Det skal gå tydelig frem hvilke søknader som er nye i systemet og hvilke som ikke er behandlet. Side 11 av 18

12 8. Alle elever som skal ha ordinære skolekort skal eksporteres over i billettsystemets skolekortsystem. (Levert av Fara). Feltene som skal eksporteres ut og i hvilket format det skal eksporteres i er definert i beskrivelse i pkt Systemet skal gi grunnlag for å produsere rapport for fakturagrunnlag til bestillere ut fra registrerte bestillinger. Det skal være mulig å eksportere data i xls og/eller csvformat for videre behandling. 10. Det skal være mulig å bruke inneværende års bestillinger som grunnlag for neste år ved hjelp av oppflytting. 11. Behandleren skal ha muligheten til å notere i eget felt for en elev 12. Behandleren skal ha mulighet for å importere vedlegg fra filsystem som allokeres på en enkelt søknad/elev. 13. Det skal være mulig for behandlere i systemet å endre og slette data i løpet av skoleåret 14. En elev som har krav på tilrettelagt skyss skal kunne ha ordinært skolekort. 15. Det skal være mulig å søke på felter eller deler av felt som er registrert på en elev. Minimum følgende felt: o ElevId, Etternavn, Fornavn, Adresse, Fødselsnummer 16. VKT skal utføre planlegging av ruter for tilrettelagt skyss o Det må som minimum være mulig å legge inn rutenummer pr. dag fra og til i like og ulike uker slik at dette kan eksporteres ut til xls/csv-fil for viderebehandling, planlegging av transportoppdrag og fakturering. o Et rutenummer skal allokeres til en transportenhet o Transportører skal kunne logge seg på løsningen via web-portalen og hente ut sine transportoppdrag Side 12 av 18

13 8.2 Kartfunksjon 1. Systemet skal ha kart eller kobling mot kart for geokoding av adresser og beregning av reiseavstander for den enkelte bestilling. 2. Adresser som brukes på bestillinger skal vises i kart og det skal beregnes avstand fra elevens adresse(r) til angitt skole på bestillingen. Beregningen lagres på eleven For beregning av avstand skal gang og sykkelstier kunne brukes. Oppdragsgiver benytter ArcGis fra ESRI/Geodata AS med kartgrunnlag fra Statens Kartverk ( 3. Dersom man er videregående elev skal eleven kun få godkjent skyss for ordinære skolekort dersom man har adresse innenfor et geografisk område og har over 6 km reisevei. 4. Det skal være mulig å overstyre den geografiske «beslutningen» ved at behandleren kan godkjenne skoleskyss på en elev selv om forutsetningen over ikke er innfridd. Det må kunne velges for hver elev om man skal benytte gang- og sykkelstier eller ikke 5. Systemet skal kunne legge inn nærmeste holdeplass fra bostedsadresse Holdeplassen skal kun være synlig for behandleren Det må være mulig å overstyre holdeplass på eleven Holdeplassene skal importeres inn manuelt i formatet regtopp 1.2 (Vedlegg B) 8.3 Rapporter Systemet skal levere rapporter til hjelp til behandlere i systemet. Disse skal minimum genereres en gang i døgnet. 1. Systemet skal ivareta behov for nødvendig historikk. Transportopplegg for den enkelte elev gjennom skoleåret Totale antall transporter Kostnader pr. måned for elever med tilrettelagt skyss 2. Det skal være mulighet for å få ut rapporter for nye ubehandlede søknader/bestillinger. 3. Det skal være mulighet for å få ut rapporter på Søknader/bestillinger som er stoppet 4. Det skal være mulighet for å få ut rapporter med oversikt over elever med ulike former for skoleskyss for et utvalg fra skole, trinn og klasse. 5. Det skal være mulighet for å få ut timeplaner for skoler / klasser. 6. Det skal være mulighet for å få ut rapporter på søknader/bestillinger pr skole pr skolestart og tid 7. Alle rapporter må kunne skrives ut og / eller lagres som pdf og / eller excel-fil. Side 13 av 18

14 9 Krav til grensesnitt Dette grensesnittet skal overføre data fra skoleskyss-systemet til billettsystemet for produksjon av skolekort og overføring av data tilbake til skoleskyss-systemet. Grensesnittet gjelder for elever som skal ha ordinær skoleskyss 9.1 Data fra Skoleskyss-systemet til billettsystem Bestilling av elektroniske skysskort skal gå i gjennom eksport av fil fra systemet som importeres til billettsystemet. Datafelter er spesifisert i pkt Alle nye bestillinger for nye elever dvs. de som ikke har FaraElevId og kortnummer skal tas med i eksporten 2. Samtlige endringer på elever som utføres i Skolskyss-system og som skal ha ordinær skyss, skal eksporteres til billettsystem 3. Kodesettet for Skolekort i Fara-system skal eksporteres via definerte aksjonskoder fra dette systemet. 4. Dersom en elev har skolekort fra før skal dette kortet oppdateres 5. Eksporten skal settes i gang av behandler. Om mulig skal det redegjøres for hvilke automatiserte prosesser som er mulig. 6. Alle eksporter av enkeltposter skal merkes som eksportert ved at et felt inneholder eksportdato. 9.2 Data fra billettsystemet til Skoleskyss-systemet. Etter at fil fra systemet er importert i billettsystemet og utstedelse av kort / produkt er foretatt, skal det sendes en fil tilbake til systemet fra billettsystemet med oppdatert informasjon. Tildelt kortnummer og FaraElevId skal oppdateres i Skolesystemet. Side 14 av 18

15 9.2.1 Feltbeskrivelser for grensesnitt billettsystem Følgende felter skal eksporteres til billettsystemet. Rekkefølgen på datakolonnene skal være som beskrevet i tabellen under. Det må påregnes endringer i denne spesifikasjon før eller under test/driftssetting av systemet avhengig av format som er spesifisert av Fara. Navn DataType Obligatorisk 1 Personnummer Numerisk 11 J 2 Fornavn 50 tegn J 3 Etternavn 50 tegn J 4 Fødselsdato yyyy.mm.dd J 5 TelefonNr1 15 tegn N 6 Adresse1 50 tegn J 7 Postkode1 Numerisk J 8 Holdeplass1 Numerisk N 9 TelefonNr2 15 tegn N 10 Adresse2 50 tegn N 11 Postkode2 Numerisk N 12 Holdeplass2 Numerisk N 13 KlasseID Numerisk J 14 Fakt.Kommunenr Numerisk N 15 BildeFilNavn 80 tegn N 16 ProduktTemplateNr Numerisk J 17 PT1GeoA Numerisk J 18 PT1GeoB Numerisk S 19 GyldigFraDato yyyy.mm.dd J 20 GyldigTilDato yyyy.mm.dd J 21 AntReiserPrDag Numerisk S 22 AntReiserTotalt Numerisk J 23 AntReiserMandag Numerisk J 24 AntReiserTirsdag Numerisk J 25 AntReiserOnsdag Numerisk J 26 AntReiserTorsdag Numerisk J 27 AntReiserFredag Numerisk J 28 AntReiserLørdag Numerisk J 29 AntReiserSøndag Numerisk J 30 Kortnummer Numerisk N 31 Aksjonskode Numerisk N J = Ja, obligatorisk N = Nei, kan være blankt S = Systemavhengig om det må fylles ut eller ikke. Avgjøres i hvert prosjekt. 9.3 Import av holdeplassdata Systemet skal kunne importere det holdeplassregisteret som til enhver tid benyttes av Oppdragsgiver. Oppdragsgiver benytter formatet regtopp 1.2 som eksporteres fra DGBuss. Side 15 av 18

16 10 Krav til dokumentasjonen Leveransen skal inneholde dokumentasjon av systemet Følgende krav settes til dokumentasjonen: 1. All dokumentasjon skal i tillegg til papirversjon leveres på et elektronisk format eller være tilgjengelig på Internett, slik at det er mulig for Oppdragsgiver å produsere ytterligere papirdokumentasjon på et senere tidspunkt. Dokumentasjonen skal leveres i enten Word eller Acrobat Reader 2. Oppdragsgiver skal på eget ansvar kunne gjøre de endringer, tillegg mv. i dokumentasjonen som Oppdragsgiver finner hensiktsmessig 3. All databasers tabelloppsett skal være beskrevet med minimum: Tabellnavn Relasjoner med andre tabeller Feltbeskrivelse pr. tabell Feltnavn Felttype Feltstørrelse 4. Påloggingsparamatere for ODBC tilkobling til database, eller alternative påloggingsparametere oppdragsgiver og leverandøren måtte bli enige om, skal dokumenteres og overleveres Oppdragsgiver sammen med øvrig dokumentasjon. Informasjonen skal blant annet benyttes til å produsere rapporter i datavarehuset Områder som skal være beskrevet i dokumentasjonen Følgende krav settes til hvilke områder som skal være beskrevet i dokumentasjonen, herunder: 1. Alle grensesnitt mellom de ulike delsystemene 2. Alle funksjoner i alle komponenter i systemet 3. Fremgangsmåter for periodisk vedlikehold 10.2 Hvilket språk skal benyttes Følgende krav settes til språk i forhold til dokumentasjon: 1. All brukerdokumentasjon av moduler, komponenter og programvare skal være på norsk bokmål 2. Annen teknisk dokumentasjon av moduler, komponenter og programvare skal være på norsk bokmål eller engelsk Side 16 av 18

17 11 Opplæring Leveransen skal bestå av opplæringsprogram for alle moduler og enheter i systemet. Oppdragsgiver skal selv foreta opplæring av skolene i systemet. Følgende generelle krav settes til opplæring: 1. Opplæringsprogrammet skal overleveres Oppdragsgiver senest en uke etter godkjent SAT for systemet 2. Opplæringen skal skje etter spesifisert opplæringsplan 3. Opplæringen skal foregå på norsk 4. Sentrale personer utpekt av Oppdragsgiver skal opplæres på alle deler av system. Disse skal settes i stand til å kunne gjennomføre opplæring av de som skal benytte ulike deler av systemet 5. Opplæringen skal primært avholdes på Oppdragsgiver sitt hovedkontor i Tønsberg 6. Opplæringen skal primært finne sted på dagtid mellom kl Opplæringsmateriellet skal overtas av Oppdragsgiver for å kunne benyttes til intern-opplæring 12 Vedlikehold og support Ved innføringen av Skoleskyss-systemet er det behov for å etablere et service-, vedlikehold-, garanti- og supportapparat som kan ta seg av eventuelle problemer som måtte oppstå på programvare og behov for support på bruk av systemet. Oppdragsgiver skal selv foreta det daglige ettersyn av systemet Leverandøren skal spesifisere hva som er nødvendige krav til vedlikehold for andre enheter som omfattes av vedlikeholdsavtalen Følgende generelle krav settes til service, vedlikehold, garanti og support: 1. Alle delsystemer og komponenter skal vedlikeholdes og supporteres av leverandør i henhold til Statens standardavtaler, Avtaler og veiledninger om IT-anskaffelser, Vedlikeholdsavtale 2. Leverandøren skal stille med kvalifisert personell, som skal beherske fjerndrift for å kunne feilsøke og løse problemer uten nødvendigvis sende personell til Oppdragsgiver Side 17 av 18

18 13 Endringslogg Dato Versjon Kapittel Beskrivelse Side 18 av 18