Kravspesifikasjon for Akershus fylkeskommunes telefoniløsning

Transkript

1 Kravspesifikasjon for Akershus fylkeskommunes telefoniløsning Dette er kravspesifikasjonen som Akershus fylkeskommune utarbeidet ifm anskaffelsen av en ny felles telefoniløsning for hele fylkeskommunen, inkl. samtlige 70 virksomheter. Kravspesifikasjonen beskriver en telefoniløsning beregnet for store virksomheter som typisk består av en rekke undervirksomheter (konsern-modell) og som har fokus på service ovenfor innringer (svartjenesten), samt brukervennlig bruk og administrasjon. Som opsjon er det tatt med elementer av «samordnet kommunikasjon» (Unified Communication). Noen krav har i ettertid vist seg å være mindre relevante, eller for spesifikke. Disse er markert med lyserødt. Pr 1. juni 2012 er ca halvparten av AFKs virksomheter migrert over til den nye løsningen. Innen sommeren 2013 skal samtlige virksomheter være over på den nye løsningen. Til grunn for anskaffelsen lå følgende policy-beslutninger: Hovedmål: Øke servicegraden ovenfor innringer (bedre svartjeneste). Derfor er følgende besluttet: 1. Alle virksomheter skal beholde sine eksisterende nummer. De fleste av virksomhetene har et innarbeidet nummer i sitt nærmiljø. Det ønsker man å beholde. Det betyr at man må ringe alle 8 sifre når man skal ringe til en abonnent utenfor egen virksomhet. Er det en abonnent i Afk, går allikevel samtalen internt. 2. Alle skal ha to linjer. Ansatte må lære seg å besvare linje 2 når man sitter opptatt på linje Ikke slå null for å ringe et eksternt nummer («bynummer»). 4. Alle ansatte skal kunne ringe med en fasttelefon. Til grunn for dette valget ligger «føre-var-prinsippet» knyttet til mobilstråling, samt at moderne telefonisystemer basert på IP gir mye bedre lyd enn både ISDN og mobiltelefoner. Vi ønsker å gi best mulig lyd til innringer. 5. Ingen ventemusikk (kun et lite pip-pip hvert 20. sekund). Vi vet ikke hva slags musikk innringer liker. Innringer kan når han står på vent høre vanlig ringelyd, eller selv velge å få det helt stille. 6. Telefonen skal ikke knyttes til brukernes kalender. Det betyr at telefonen ikke skal automatisk sperres for innkommende anrop når abonnenten markere en aktivitet/oppgave i sin kalender (som i Afk er kalenderen i Outlook). Ansatte som vil jobbe uforstyrret må selv aktivere funksjonen «Ikke Forstyrr». Sentralbordet kan oppheve denne. 7. Personlig talesvar med talemeny og talepostkasse bør benyttes. Dette øker servicegraden ovenfor innringer. Innringer hører din stemme, og du gir innringer en del valg. Du vet ikke hva innringer lurer på, derfor skal innringer gis noen 1

2 valg. 8. Standard viderekobling ved ikke svar og ved opptatt er 4 ring og rutes til virksomhetens sentralbord (hovednummeret). 9. Alle virksomheter større en ca 15 ansatte skal ha PC-sentralbord. Dette gjør det enkelt å se de ansattes kalendre. 10. Velkomsthilsen innenfor virksomhetens åpningstid skal komme først etter 4 ring. Den skal være noe à la dette: «Du har nå kommet til <virksomhetens navn>. Det er for tiden litt trafikk, vennligst vent» (Merk bruken av ordet «litt». Vi har sjeldent mye trafikk, derfor skal man ikke si «Det er for tiden stor trafikk, vennligst vent») 11. Etter åpningstid skal hilsenen komme umiddelbart, og skal være noe à la dette: «Du har nå kommet til <virksomhetens navn>. Vi har stengt for dagen. Våre åpningstider er xx til yy mandag til fredag». (Merk at det skal ikke opplyses om åpningstid innenfor åpningstiden!) For tannklinikker kan følgende ev. tilføres: «Tast 1 for å bli satt over til tannlegevakt eller tast 2 for å legge igjen en beskjed til oss. Beskjeden blir normalt hørt påfølgende morgen» For skoler kan følgende ev. tilføyes: «Tast 1 for å bli satt over til skolens vaktmester eller tast 2 for å legge igjen en beskjed til oss. Beskjeden blir normalt hørt påfølgende morgen» Sist oppdatert: 7. juni 2012 Bjørn Venn IT-rådgiver/prosjektleder Akershus fylkeskommune Kontaktinfo: Fasttelefon direkte: Mobiltelefon: E-post: bjorn.venn@akershus-fk.no 2

3 KRAVSPESIFIKASJON 4.1 Generell beskrivelse av ytelsene AFK har i dag en desentralisert telefoniløsning, fordelt på ca 87 enheter, hvor hver enhet har sin egen hussentral og egne linjer mot offentlig telenett. Dette skal nå samles i en felles telefoniløsning, hvor sentralutstyret skal være plassert i fylkeskommunens lokaler i Schweigaards gate 4, Galleriet, Oslo. I utgangspunktet skal alle enheter konfigureres tilnærmet likt med dagens konfigurasjon. I tillegg skal alle ansatte få tilgang til en Softphone fra egen PC eller tynnklient. Som tynnklient-løsning benyttes både Windows Terminalserver 2003 og Citrix XenApp ( Citrix Presentation Server 5.0 ). Det planlegges å gå over til Windows 2008 TS med Citrix XenApp. Det er kun de brukere som er knyttet til Citrix som skal tilbys softphones. Vi ser for oss at alle fysiske apparater etableres i administrasjonsnettet, mens softphone-ene etableres i både undervisnings- og administrasjonsnettet. Det er særlig blant lærerne og i sentraladministrasjonen (Galleriet) at softphones vil bli tatt i bruk. På tannklinikkene skal det utelukkende benyttes fasttelefoner (ca 250 apparater totalt). Hafslund Telecom er AFKs WAN-leverandør mot skolene, mens Ventelo (BaneTele) er leverandøren mot tannklinikkene. Løsningen skal etableres på AFKs VMware-plattform. Der det er påkrevet eller anbefalt, skal det i tillegg benyttes fysiske servere. Løsningen skal etableres som en redundant løsning, i form av et dobbel installasjon med lastbalansering. Begge installasjonene skal være i operativ drift, men den ene skal overta når den andre settes ut av drift. Migrering over til den nye løsningen skal skje gradvis gjennom rammeavtaleperioden, etter en planleggings-, test- og utprøvingsfase, illustrert som følger: Abonnenter på eksisterende løsninger Abonnenter på ny løsning År 1 År 2 År 3 Planleggingsfasen Test- og utprøvingsfasen Migreringsfasen 3

4 4.2 Rammeavtalens innhold Rammeavtalen består av: Del 1: Leveranse av sentral telefoniløsning Denne delen inkluderer følgende: detaljert design av løsningen orientere virksomhetene/enhetene om løsningen installasjon av løsning test og pilotering Del 2: Prosjekt for migrering Gjennom en periode på tre år fra rammeavtalens inngåelse, skal alle virksomhetene/enhetene i AFK migreres over til den nye telefoniløsningen. Denne delen inkluderer blant annet følgende prosjektarbeid: Detaljplanlegging av leveransen (migreringsplan, testplan og godkjenningsprosedyre). Identifisere dagens konfigurasjon og nummerplan for hver enkelt virksomhet/enhet/enhet. Avklare ny konfigurasjon med den enkelte virksomhet/enhet/enhet. Portere nummer/ta ut nye numre. Installere abonnentutstyr, konfigurere og teste for hver virksomhet/enhet. Ansvar for dialogen med WAN-leverandør og sentral IT-enhet. Nedtaking og avhending av eksisterende utstyr, samt oppsigelse av eksisterende telelinjer. Del 3: Rammeavtale på utstyr Gjennom rammeavtaleperioden vil det være et løpende behov for telekomutstyr, først og fremst abonnentutstyr som fysiske og programvarebaserte telefoner (eng: Softphones), hodesett, håndsett, samt noe kommunikasjonsutstyr. Felles for del 1, 2 og 3 For nærmere beskrivelse av kravene knyttet til de ovennevnte delene, se punkt 4.4. Disse kravene skal den enkelte tilbyder kunne levere, dvs. kravene er absolutte for den valgte leverandøren. Tilbyder kan således ikke ta forbehold mot noen av disse kravene. I dette punktet skal tilbyder krysse av i tabellens høyre kolonne om at kravet er lest og forstått. Tilbyder skal gi beskrivelser til noen av temaene for kravene. Videre skal det angis løsningsforslag tilknyttet kravene hvor det er angitt. Løsningsforslagene vedrørende nummer 1 og 11 vil vektlegges, se punkt Beskrivelser og løsningsforslag inntas under skilleark 8 med henvisning til kravnummeret. Alle løsningsbeskrivelser tilbyder oppgir i sitt tilbud er bindende for tilbyder selv om de ikke vektlegges i evalueringen. Del 4: Opsjoner Sentralløsningen skal installeres i lokalene til AFK, Schweigaards gate 4, Galleriet. AFK ønsker som en opsjon tilbud på diverse tilleggsytelser til denne installasjonen. AFK er åpen for å la tilbyder stå for både drift og administrasjon av løsningen, og vi ønsker derfor også tilbud på administrasjon og drift av løsningen. I tillegg skal tilbyder oppgi timepriser for eventuelle tilleggsarbeider. 4

5 Se punkt 4.5 for beskrivelse av opsjoner på tilleggytelser som tilbyder skal kunne levere. Ytelsene skal prises (se tilbudsskjema del 4) og vil vektlegges, se punkt Leverandør skal kunne levere disse ytelsene hvis oppdragsgiver får behov for dem i rammeavtaleperioden. Se punkt 4.6 for beskrivelse av opsjoner på andre tilleggsytelser. Tilbyder skal krysse av i tabellens midtre kolonne om ytelsen kan oppfylles/leveres. For hvert punkt som kan leveres/oppfylles oppnås poeng angitt i høyre kolonnen. Se punkt 3.13 for vektlegging av tildelingskriteriet Leveringsevne. 4.3 Rammeavtalens omfang Antall - volum pr år År 1 År 2 År 3 Antall enheter type skole, med flere enn 15 abonnenter som med stor sannsynlighet skal ha PC-basert sentralbord. Antall enheter type tannklinikk og andre mindre enheter, med mindre enn 15 abonnenter, som med stor sannsynlighet vil benytte en utvidet fasttelefon som sentralbord. Antall telefoner av enkleste type Antall telefoner av utvidet type ( sekretærapparat ) Antall softphones inkl hodesett -, håndsett eller USBtelefon Volumangivelsene er kun retningsgivende og forplikter ikke AFK. 5

6 4.4 Krav MERK: Hver beskrivelse presenteres i eget ark (og inntas under skilleark 8) der det er referert hvilket kravnummer den hører til. Husk å krysse av i tabellens høyre kolonne for hvert kravnummer som er lest og forstått. Krav vedrørende løsning 1. Krav til løsning (overordnet beskrivelse av ønsket løsning) Målet med anskaffelsen er å bedre svartjenesten for innringere. Ingen innringer skal behøve å vente mer enn 4 ring før han/hun «noe skjer». Innringer skal selv kunne velge hva som da skal skje, f.eks. få tilbud om å bli satt over til noen andre (kollega/forkontor/sekretær/sentralbord) eller legge igjen en beskjed. Kryss av for hvert kravnummer som er lest og forstått Løsningen skal etableres som en sentral installasjon med full redundans, i form av en dobbel installasjon, med full lastbalansering mellom de to installasjonene. Det betyr også redundant SIP-trunk (eget anbud). Ref. innledende tekst under punkt 4.3 Den enkelte virksomhet skal etableres som en virtuell telefoniløsning på denne sentrale installasjonen, hvor de selv kan administrere sine egne abonnenter, telefoner og ringemønstre. Det skal ikke være noe fysisk utstyr ute ved virksomhetene, annet enn brukerutstyr (telefoner, hodesett osv) og ev. analog-adaptere. Funksjonaliteten som kreves i denne kravspesifikasjonen skal implementeres utelukkende gjennom konfigurasjon av leverandørens standardprodukt. Dog kan det aksepteres at en eller flere funksjoner utvikles spesifikt for AFK, dersom dette tas inn i standardproduktet senest et halvt år etter at funksjonen ble implementert hos AFK. 1.1 Beskrivelse av løsningsforslag Basert på den overordnede beskrivelsen og kravene i denne kravspesifikasjonen, skal tilbyderen utarbeide en beskrivelse av løsningen, på minimum åtte A4-sider. Beskrivelsen bør som et minimum omhandle følgende: Overordnet beskrivelse av løsning Løsningens kapasitet Systemdesign (inkl. overordnet systemskisse) Beskrivelse av de enkelte komponentene, med begrunnelse for hvorfor den enkelte komponent er valgt, og beskrivelse av hva den gjør. Signalering og mediastrømmer Forhold knyttet til partial rerouting ("hairpinning") Sikkerhet 6

7 De vesentligste telefonitjenestene (viderekobling, talepostkasse, talesvar, køer, innhentgrupper med mer ) Sentralbord Nattstilling og krisemodus Administrasjonsverktøyet Brukerutstyr Løsningens programmeringsgrensesnitt Noen av virksomhetene/enhetene har forholdsvis nye sentraler. Det kan være at det ikke er ønskelig å migrere dem over til den nye løsningen innenfor rammeavtaleperioden. Tilbyderen skal foreslå ett eller flere alternativer som kobler den lokale hussentralen inn mot den nye løsningen. Dette skal også beskrives og tas med i løsningsbeskrivelsen. Når strømmen kommer tilbake etter strømbrudd, skal hele den sentrale sentralenheten automatisk starte opp igjen og all funksjonalitet skal etter en slik oppstart være tilgjengelig. (Dette burde vært som eget punkt) 2. Krav til maskinvareplattform Løsningen skal installeres på AFKs VMware-plattform. På de områder der det er påkrevd eller anbefalt, skal det i tillegg benyttes fysiske servere. Dette skal være standard Intel- eller AMD-baserte PC-servere. Leverandør skal ikke levere selve maskinvaren, men kun angi antall fysiske servere med nøyaktige spesifikasjoner til AFK. AFK er ansvarlig for anskaffelsen av denne maskinvaren. Tilbyder skal begrunne valg av plattform. For krav til klienter (abonnentutstyr); se krav nummer Krav til kapasitet Løsningen skal designes til å kunne håndtere ca 4500 abonnenter og ca 200 samtidige samtaler. Hver abonnent skal ha talepostkasse, hvor talemeldinger på inntil 50 Mb pr abonnent skal kunne lagres. Løsningen skal kunne håndtere inntil 130 køer, 10 samtidige telefonkonferanser med inntil 50 deltagere i hver konferanse og inntil 400 innhentgrupper. Abonnenter med fysiske telefoner skal benytte G.711 og/eller G som kodek, mens softphone-abonnenter skal benytte en lavbåndbredde-kodek (for eksempel G.729 og/eller GSM (3GPP 06.10)). 4. Krav til grensesnitt mot operatør Grensesnitt mot operatør skal være basert på SIP, i henhold til RFC Krav til protokoller og standarder (Noen av disse har vi frafallet, se egne rettelser. Kontakt undertegnede for detaljer) AFK er opptatt av å følge åpne, internasjonale standarder. Løsningen og abonnentutstyret skal støtte følgende IETF-standarder: RFC 3261: SIP version 2.0. RFC 3263: Locating SIP Servers. RFC 3550: Real-time Transport Protocol (RTP). RFC 3551: RTP Profile for Audio and Video Conferences with Minimal 7

8 Control. RFC 3487: Priority Mechanisms for SIP. RFC 2833 or 4733: DTMF signalling. RFC 4855/4856: Media Type Registration of RTP Payload Formats RFC 3611: RTP Control Protocol Extended Reports (RTCP XR) RFC 5391: RTP Payload Format for G RFC 3711: The Secure Real-time Transport Protocol (SRTP) RFC 5246: The Transport Layer Security (TLS) Protocol RFC 2475: Diffserv RFC 3268: DSCP 46 (Expedited Forwading) RFC 3246: QoS Baseline Model 6. Krav til nummerplan Alle enheter skal kunne beholde sin eksisterende nummerplan. Tilbyderen skal gå igjennom nummerplanen og foreslå endringer som kan gi en enklere nummerplan, eller lavere kostnader. En avgrenset del (for eksempel for en enkelt virksomhet/enhet) eller den komplette nummerplanen skal til enhver tid kunne hentes ut av systemet via administrasjonsverktøyet. Nummerplanen skal kunne presenteres på samme side/skjermbilde, og vise nummer, abonnentens navn, telefontype og MACadresse på apparatet. Se nummer 38, administrasjonsverktøy. Det kan bli aktuelt å anskaffe nye numre, fortrinnsvis i nærheten av den enkelte virksomhet/enhets eksisterende nummerserie. 7. Krav til tildeling av nummer Systemet skal foreslå et ledig nummer for nye abonnenter, i henhold til de nye abonnentenes arbeidssted. 8. Krav til SIP-konti Samtlige abonnenter skal tildeles en SIP-konto med en lesevennlig SIPadresse, under et eller flere av AFKs domener. Det skal være mulig å ringe inn til en abonnent via abonnentens SIPadresse. Abonnentens SIP-adresse skal være et alias, og ikke være knyttet til abonnentens SIP brukerdata. SIP-adressen skal kunne være abonnentens telefonnummer (direkte innvalgsnummer) eller fornavn.etternavn. Abonnentens SIP-brukerdata (brukernavn og passord) skal være vilkårlig generert, og skal ikke være knyttet til abonnentens navn, ansattnummer, telefonnummer el.l. Se for øvrig nummer 11, krav til sikring av løsningen. 9. Krav til visning av A-nummer (nummer til innkommende anrop) Innkommende anrops nummer (A-nummer) skal presenteres for mottaker. Dette skal også gjelde dersom et innkommende anrop er overført via sentralbord eller en annen intern abonnent. Visning av A-nummer skal også gjelde når en samtale blir satt over til mobiltelefon. Eventuell kommunikasjon/bestilling/oppfølging av dette mot 8

9 teleoperatør (leverandør) skal være inkludert i avtalen. 10. Krav til visning av eget A-nummer ut Administrator skal for den enkelte abonnent kunne spesifisere hvilket nummer som skal vises som utgående nummer. Systemet skal være levert med å vise abonnentens direkte innvalgsnummer. Der innvalgsnummer ikke finnes skal sentralbordnummeret vises. 11. Krav til sikring av løsningen Løsningen skal sikres mot: Innbrudd/hærverk (hvor resultatet er at hele eller deler av systemet stopper) Misbruk (hvor resultatet er at løsningen ikke stopper, men hvor kostnadene til trafikk øker). Identitetstyveri (hvor resultatet er at abonnenters identitet (brukerdata) stjeles) Avlytting (sikre konfidensialitet) Som et minimum skal følgende krav være oppfylt: Det skal ikke være mulig å registrere brukere fra Internett Softphone på de ansattes PC-er skal sikres, enten ved å benytte VPN (IPsec), eller SIP over TLS og SRTP (Fysiske telefoner skal i utgangspunktet kun etableres i administrasjonsnettet og vi anser det ikke som nødvendig å iverksette de samme sikkerhetsmekanismene) Det skal være tillatt å gjøre direkte anrop fra SIP-brukere på Internett til ansattes (abonnentens) SIP-adresse. Løsningen skal implementeres i henhold til best practice gitt av produsent og/eller ekstern sikkerhetsorganisasjon. AFK drifter sin egen brannmur-løsning basert på Fortigates produkter (Fortinet FortiOS 4.0 MR2). Denne har egne sikkerhetsmekanismer for SIP, og vi oppfordrer tilbyder til å sette seg inn i disse og inkludere disse i sikringen av løsningen Beskrivelse av løsningsforslag Tilbyderen skal beskrive hvordan sikringen av løsningen skal gjøres. Særlig bes forholdene rundt Partial rerouting ( hairpin) beskrives detaljert, samt sikkerheten knyttet til bruk av trådløse telefoner og ansattes bruk av telefoniløsningen fra vilkårlig lokasjon (via Internett). Tilbyder må beskrive rutinene for utsendelse og implementering av sikkerhetsoppdateringer på samtlige komponenter som inngår i løsningen. Implementering av beskrevet sikkerhet skal være inkludert i rammeavtalen. 12. Krav til nødnummerruting Leverandøren skal sørge for at riktig opprinnelsesmarkering blir ivaretatt i henhold til gjeldende lover og regler. Informasjon om den enkelte ansattes arbeidsadresse fremgår av AFKs katalogtjeneste (MS Active Directory). 13. Krav til provisjonering av apparater Det skal være et system for automatisk konfigurasjon/oppsett og vedlikehold av de tilbudte apparater (gjelder ikke trådløse apparater og softphones). Alle apparater skal ved første gangs oppkobling hente sin konfigurasjon fra et 9

10 sentralt provisjoneringssystem. Etter den automatiske provisjoneringen skal korrekt dato og tid vises, og all skriftlig informasjon som vises gjennom apparatets vindu (display) skal være på norsk (bokmål). Beskriv dette nærmere. 14. Krav til Click-to-call Med click-to-call menes følgende: Systemet skal kunne identifisere et konfigurerbart antall siffer som vises på skjermen, for eksempel nummer på 5 og 8 siffer. (Forutsetning: Teksten/nummeret må være markerbart). Når systemet, eller brukeren selv, identifiserer et slikt tall, så skal brukeren kunne høyreklikke på nummeret og velge «ring», eventuelt selv markere nummeret og trykke en funksjonstast, eller en kombinasjon av taster (f.eks. [Ctrl]+[C]+[C]). Applikasjonen skal da komme opp (synliggjøres) i nærheten av der hvor det markerte tallet er (f.eks. der musmarkøren står). Brukeren skal nå kunne se tallet for kontroll. Et klikk på et «ringe-ikon», eller Enter-tasten på tastaturet starter oppringingen. Det skal da begynne å ringe utgående ringelyd i telefonen. Telefonen skal kunne være både fysisk apparat, softphone eller mobiltelefon. Dette setter abonnenten selv på sin egen administrasjonsside (administrator velger hvorvidt mobiltelefon skal være en valgmulighet). Der det er systemet som automatisk finner tallene, skal det også kunne gjenkjenne tall hvor det er ett mellomrom mellom ett eller flere av sifrene (telefonnumre skrives normalt på formen for fastnumre og for mobilnumre). Beskriv denne funksjonen nærmere. 15. Krav til «Click-to-call» fra SIP-lenke på en webside eller i et dokument Etter hvert som SIP blir mer utbredt, vil det kunne dukke opp SIP-adresser på en nettside. Denne kan eventuelt være skjult bak et ikon. I begge tilfeller skal abonnenten kunne ringe kun ved å klikke på lenken eller ikonet. Når abonnenten klikker på lenken/ikonet, skal det begynne å ringe i fasttelefonen, softphone-en eller eventuelt mobiltelefonen. (Det siste kun hvis det er gjort tillatt av administrator, se nummer 38). 16. Krav til integrasjon Løsningen (sentralenheten og sentralbordapplikasjonen) skal være integrert mot AFKs katalog- og gruppevareløsninger som pr i dag er følgende: Microsoft Active Directory (AD). (For å hente ut brukernavn, telefonnummer, stillingsbetegnelse, fagområde, org. enhet med mer til bruk i sentralbordapplikasjonen). MS Exchange (for å vise brukers avtalebok i sentralbordapplikasjonen). MS Outlook (for at brukeren skal kunne ringe fra sine kontakter i MS Outlook og fra telefonnumre som står i en e-post. Kan sees i sammenheng med funksjonaliteten i nummer 14. Beskriv dette nærmere). Telefonkatalogen eller lignende nummeroppslagstjeneste for å kunne vise navn på innringer. (NB: AFK abonnerer i dag på web-tjenesten 10

11 Telefonkatalogen bedrift fra Eniro. Denne er integrert i intranettet til AFK, og abonnenten kan søke etter både interne og eksterne personer og sende sms til dem som har mobiltelefon). Tilbyderen bes beskrive hvordan integrasjonen er tenkt gjort og angi hvilke versjonsnumre av de ovennevnte produktene som kreves. Tilbyderen bes videre beskrive hvordan mobiltelefonene kan integreres inn i løsningen. (Andre steder i denne kravspesifikasjonen fremgår det at abonnent skal kunne viderekoble til mobiltelefon, og kunne ha parallellringing med mobiltelefon, dersom administrator har tillatt dette for den aktuelle abonnenten/virksomhet/enheten. Se også under punkt 4.6, nummer 11 visning av status på mobiltelefoner i sentralbordapplikasjonen). 17. Krav til caching av nummeroppslag Oppslåtte numre i den eksterne katalogtjenesten (se nummer 16) skal «caches» i en intern katalog (database). Nye oppslag skal alltid først sjekkes mot denne interne katalogen. Leverandøren skal sørge for at de til enhver tid gjeldende lover og regler for lagring av slike personopplysninger blir ivaretatt (se nummer 83). 18. Krav til programmeringsgrensesnitt På sikt kan det bli aktuelt å integrere mot sak-/arkivsystem (pr dd er dette ephorte (sentraladministrasjonen) og mot Vigo ( Løsningen skal ha et veldokumentert og åpent programmeringsgrensesnitt (API). Eventuelt «programmerings-/integrasjonsmoduler» og kostnader knyttet til bruken av disse skal være inkludert i rammeavtalen. Beskriv dette nærmere. 19. Krav til analoge enheter (faks, alarmer m.m.) Ute ved den enkelte virksomhet/enhet er det en del analoge enheter (telefakser, alarmer, trådløse enheter med mer). Disse skal identifiseres og dokumenteres (se eget krav under «Tjenester»). Det skal leveres en løsning for å håndtere analoge enheter. Arbeidet med disse skal være inkludert, mens prisen for påkrevet utstyr kommer som tillegg. Patching i krysskoblingsskap av disse enhetene skal være inkludert. Alarmer går utenom sentralen (på egne dedikerte linjer). Eventuelt arbeid med alarmer, ut over å identifisere og dokumentere dem, er tilleggsarbeid. 20. Krav til ENUM Løsningen skal støtte ENUM-oppslag. Ruting av utgående samtaler skal skje på grunnlag av de opplysninger som returneres fra ENUM-katalogen. Finnes nummeret i ENUM-katalogen, skal samtalen rutes via SIP, og ikke ut mot teleoperatør og offentlig nett. Rammeavtalen skal inkludere deltakelse i et pilotprosjekt på dette mot Buskerud fylkeskommune og Universitetet i Oslo, i samarbeid med Buskeruds SIP-leverandør, AFKs SIP-leverandør og Uninett/Norid. Det må påregnes ca 40 timers arbeid til dette (noe avhengig av hvor mye 11

12 kompetanse tilbyder har på området. En oversikt over teknologien finnes her og i Wikipedia) Krav vedrørende telefonitjenester 21. Krav vedrørende ringing Det skal kunne velges om man skal slå null for å ringe eksternt eller ikke. Det kan bli aktuelt å fjerne behovet for å slå null for å ringe eksternt. Beskriv hvorvidt løsningen kan benyttes uten å slå null foran eksterne anrop (eventuelt hva som må til for å kutte ut nullen) 22. Krav til ringelyd Det skal være mulig å høre forskjell på et eksternt og internt innkommende anrop. Dersom en ekstern samtale overføres, skal denne varsles med ekstern ringelyd (dette gjelder selvsagt ikke for spørreanrop). Den enkelte abonnent skal selv kunne endre ringelyden (tonen og melodien) og ringevolumet. 23. Krav til spørreanrop og sette over en samtale Abonnenten skal kunne utføre et spørreanrop, og så velge å gå tilbake til innringer, eller sette over samtalen. Abonnenten skal også kunne settes over direkte, uten å gå veien om spørreanrop. Beskriv funksjonen til disse to variantene for de tilbudte apparatene. 24. Krav til ventekobling («tilbakering») Anropes en intern abonnent, og denne sitter opptatt, skal anroper kunne slå en kode for å iverksette ventekobling. Når den interne abonnenten blir ledig, kobles sambandet automatisk opp på følgende måte: Først ringer det i anropers telefon, og først når anroper tar telefonen, begynner det å ringe hos den andre parten. Har mottageren to linjer, får den anropende part ikke opptatt, og kan komme til vedkommendes talesvar Løsningsforslag til ventekobling Beskriv om tastekoden for ventekobling kan tastes samtidig med at et talesvar leses opp (se også punkt 4.6, nummer 25). Inntasting av kode (DTMF-toner fra innringers telefon) skal også fungere for talesvar i forbindelse med kø eller en abonnents personlige talesvar. 25. Krav til innhenting av samtaler (innhentgrupper) Hver abonnent skal kunne være medlem i en eller flere innhentgrupper. Samtaler skal kunne hentes inn både fra den fysiske telefonen og fra softphone-ene. Løsningen skal kunne håndtere minimum 400 grupper. En abonnent skal kunne være medlem i flere grupper, hvorav en gruppe er abonnentens primærgruppe. Abonnent henter inn anrop som tilhører gruppen ved å slå kode på eget apparat. Anrop i primærgruppen har 1. prioritet. For apparater med «tilstedeværelseslys» for andre internabonnenter (tablåknapper), skal anrop kunne innhentes (besvares) ved å klikke på blinkende knapp. 12

13 Innleggelse og administrasjon av abonnenter i innhentgrupper skal skje i AD og skal utføres av AFKs personell. 26. Krav til viderekoblinger Ved oppstart av en installasjon ved en virksomhet/enhet, skal viderekoblingene for alle abonnenter ved denne virksomhet/enheten være satt til 4 ring og gå til sekretær/forværelse/sentralbord i henhold til den enkelte virksomhet/enhets egne ønsker. Leverandørens leveranseansvarlig er ansvarlig for å fremskaffe denne informasjonen. Den enkelte abonnent skal selv kunne kontrollere og endre sin viderekobling gjennom sin egen web-baserte administrasjonsside «Min side/min telefon», eventuelt i softphone-en. Viderekobling skal skje automatisk ved ikke svar og ved opptatt. Når viderekoblingen inntreffer, skal det fortsette å ringe i internabonnentens telefon (parallellringing). Noen abonnenter er vant til en funksjon som kalles for medflytting. Dersom løsningen opererer med denne tjenesten i tillegg til viderekobling, bes tilbyderen beskrive forskjellen mellom disse to. Direkte anrop som viderekobles til sentralbord, skal inn i sentralbordkøen på lik linje med alle innringere. 27. Krav til køer (ACD) Løsningen skal kunne støtte minimum 130 køer. Hver kø skal kunne ha to dedikerte talesvar; første talesvar skal avspilles etter et valgfritt antall ring og deretter talesvar nr to etter et nytt valgfritt antall ring eller sekunder. Talesvar to skal kunne repeteres etter et valgfritt antall ring eller sekunder. Innleggelse/administrasjon av talesvarene til køene skal skje gjennom en bestemt telefon ved virksomhet/enheten via en kode og/eller via administrasjonsverktøyet. Gjennom administrasjonsverktøyet skal administrator kunne sette opp køer, spille inn og tildele køsvar (talesvar for en kø), velge køordning (minimum fire forskjellige fordelingsordninger), plukke ut agenter (de som skal kunne betjene køen), velge hvorvidt køen skal være statisk eller dynamisk (faste agenter eller hvor agentene selv kan logge seg ut eller inn av køen, se nummer 39; administrasjons-/statusside for agenter), og sette prioritet på den enkelte agent (pri 1-3). Systemet skal kunne gi innringer informasjon om hvilket nummer han/hun er i køen. Dette skal administrator kunne sette ( enable ) individuelt for hver kø. Ringer det hos en agent, og denne ikke svarer, skal det gå videre til neste agent etter et konfigurerbart antall ring og i henhold til til valgt køfordeling. Det samme skal skje, dersom en kollega melder vedkommende ut av køen (se nummer 39, administrasjons-/statusside for agenter). Da skal det slutte å ringe hos vedkommende og inngående anrop skal gå til neste agent (et alternativ er eventuelt å benytte innhentgrupper). Beskriv om det er mulig å hente inn et køanrop, dvs. kan en agent også være en del av en innhentgruppe? 13

14 Er en abonnent agent for en kø, skal vedkommende ha inngående kø på en svarknapp og eget nummer på en annen knapp (altså ikke to linjer for eget nummer). Det skal i tillegg være mulig å skille med differensierte ringetoner og/eller ringemelodi om et inngående anrop er et køanrop, eller anrop til eget nummer. Dersom en agent logger seg av, vil vedkommende kun ha en linje. Det kan være aktuelt at han da har to linjer inn. Beskriv hvordan dette kan løses, og hvordan dette eventuelt kan tas inn i administrasjonsverktøyet, slik at administrator der kan sette dette pr agent Dersom en agent har viderekoblet sin telefon via sin administrasjonsside, eller på sitt apparat, skal det ikke innvirke på køanrop. Slike viderekoblinger skal kun gjelde for abonnentens eget nummer (ikke kønummeret). Anrop som går til en kø, skal alltid bli stående i køen, helt til en agent besvarer. Køanrop skal ikke viderekobles til for eksempel sentralbordet, selv om de er satt over fra sentralbordet. Sentralbordapplikasjonen skal ha mulighet for å se alle køer som er i systemet for sin egen virksomhet/enhet, og kunne logge agenter ut og inn. Se for øvrig under opsjoner for ønsket tilleggsfunksjonalitet (punkt 4.6, nummer 7). Eksterne abonnenter (for eksempel mobiltelefoner) skal også kunne være agenter. Beskriv prosedyren for hvordan eksterne abonnenter logger seg inn som agenter. 14

15 28. Krav til talemeldinger i systemet (taleprompter) Alle meldinger (taleprompter) som systemet presenterer for egne (interne) og eksterne abonnenter skal være på norsk bokmål. Taleprompter skal være spilt inn som hele setninger, og ikke som sammensatte ord. Unntak er når det etter en taleprompt (setning) kommer en antall-angivelse. Når en abonnent skal lytte til sine innkommende talemeldinger, skal han/hun få følgende taleprompter: «Du har x ny(e) melding(er)». Så skal det komme en lydindikasjon (pip/pling el.l.), for deretter å få opplest den første meldingen. Så skal systemet gi følgende beskjed: «Vil du slette meldingen; tast 1. Neste melding; tast 2.» Velger brukeren å slette, så skal det komme et nytt pip/pling, og melding nummer to skal leses opp. Dersom abonnenten kun har tidligere avspilte meldinger, skal følgende taleprompter benyttes: «Du har x gammel/gamle melding(er)», og deretter som over. Dersom abonnenten har både ny(e) og gamle meldinger, skal følgende taleprompter benyttes: «Du har x ny(e) melding(er) og y gammel/gamle melding(er). Tast 1 for å lytte til den/de nye meldingen(e), tast 2 for å lytte til de(n) gammel/gamle meldingen(e).» Deretter som over. Bruker skal gjennom sin egen administrasjonsside kunne styre om talemeldingene skal gå til egen telefon, til sin egen innboks i e- postprogrammet, eller til begge deler (se nummer 37). I administratorverktøyet skal det kunne settes hvor lenge meldinger i systemet skal lagres. Dette settes likt for alle abonnenter. Ved overtagelse skal dette være satt til 7 dager. Varsling av talemeldinger: se krav til standard apparat, nummer Telefonkonferanse (dedikert nummer) Systemet skal kunne betjene minimum 10 stk samtidige telefonkonferanser (kun tale). Disse konferansene skal ha et eget nummer, inkludert et eksternt nummer, slik at eksterne abonnenter også kan delta. Tilgangen til konferansene skjer ved å ringe nummeret, ev. supplert med en valgfri PINkode. Hvert konferanserom skal kunne håndtere inntil 100 samtidige abonnenter. Det må være en eller annen mekanisme for å reservere et «konferanserom». Beskriv dette nærmere. 30. Krav til telefonkonferanse (oppkobling fra eget apparat) Fra eget fysisk apparat, eller softphone, skal inntil en ekstra samtalepartner kunne kobles inn. 31. Krav til personlig talesvar Hver abonnent skal kunne lese inn sitt eget talesvar. Denne funksjonen velger den enkelte å ta i bruk gjennom sin egen administrasjonsside. Det 15

16 gjøres ved at abonnenten viderekobler innkommende anrop til sitt eget talesvar etter angitt tid. Det skal være forskjellig talesvar avhengig om abonnenten sitter opptatt i telefonen eller ikke. Tiden før de to forskjellige talesvarene inntreffer, skal kunne settes forskjellig. Talesvaret skal gi innringer tre valgmuligheter. Når abonnenten ikke er tilstede, eller av andre grunner ikke kan ta telefonen, kan dette for eksempel være: «Du har kommet til. Jeg kan ikke ta telefonen akkurat nå. Taster du 1, så blir du satt over til <en kollega/sentralbord/sekretær>, taster du 2 så kan du legge igjen en beskjed til meg, eller tast 3 for å bli satt over til min mobil.» Når abonnenten sitter opptatt i en telefonsamtale, skal innringer få følgende svar: «Du har kommet til, jeg sitter opptatt i telefonen. Vil du vente, tast 1. Vil du bli satt over til <en kollega/sentralbord/sekretær> taster du 2, taster du 3, så kan du legge igjen en beskjed til meg.» Dersom innringer velger alternativ 1 og abonnenten på sin administrasjonsside har åpnet opp for et nytt talesvar etter en angitt tid, skal det være som følger: «Jeg sitter fortsatt opptatt i telefonen. Vil du ha det stille mens du venter, tast 1. Du kan når som helst taste 2 for å bli satt over til sentralbordet, eller 3 for å legge igjen en beskjed til meg.» Innringer skal da ikke få noe nytt talesvar. «Helt stille» skal ikke være helt stille. Det skal komme en «pip-pip» ca hvert tjuende sekund, for å indikere at forbindelsen ikke er brutt. Selve talesvarene leser den enkelte abonnent inn ved å ringe ett nummer eller slå en bestemt kode fra eget apparat, og deretter følge instruksjonene som blir gitt fra systemet. Disse skal være noe à la dette: «Ønsker du å lese inn eller endre ditt talesvar: tast 1. Ønsker du å lytte til ditt talesvar tast 2». Neste valg skal deretter være: «Ønsker du å lese inn eller endre (eventuelt lytte) til ditt talesvar når du er opptatt i telefonen, tast 1. Tast 2 hvis du vil lese inn eller endre (eventuelt lytte) til ditt talesvar når du ikke har anledning til å ta telefonen. Tast 3 for å lese inn eller endre (eventuelt lytte til) ditt ventesvar.» Dette må gjerne i tillegg også kunne utføres på andre måter. Beskriv dette nærmere. Viderekobling til mobil kan administrator ha sperret for. Inn-/utkobling av talesvaret skjer ved å viderekoble til talesvaret, og gjøres via abonnentens egen administrasjonsside, eventuelt gjennom softphonen (Se punkt 4.6, nummer 16). 16

17 32. Krav til sperringer Systemet skal benytte «tillatt-lister» i stedet for sperrelister. Det betyr at administrator angir hvilke nummerserier abonnentene skal kunne ringe til. Ved overtagelse skal abonnentene ikke kunne ringe til noen andre numre enn de som er bestilt. Det er leverandørens leveranseansvarlig som er ansvarlig for å fremskaffe denne informasjonen. Abonnentene skal kunne legges i kategorier. Systemet skal leveres med noen ferdige kategorier, for eksempel alle nummer i Norge. Administrator skal kunne legge inn enkelte nummer, nummerserier og land i kategoriene. Alle land skal være representert i systemet (gjennom en drop-down-liste eller lignende). Når intern abonnent forsøker å ringe et sperret nummer, skal abonnenten få et talesvar. Beskriv dette nærmere. Sperringer av inngående anrop til egne nummer Det skal være mulig å sperre egne numre for inngående anrop. Slik sperring skal gjelde for alle, både eksterne og interne anrop. Det skal kunne gjøres unntak, slik at utvalgte nummer eller grupper, skal kunne ringe disse numrene. Når innringer ringer et sperret AFK-nummer, skal vedkommende få et talesvar. Beskriv nærmere hvordan dette gjøres. Svartelister Det skal være et system for å legge eksterne nummer i en svarteliste («blacklist»). Det skal være en felles svarteliste for hele AFK. 33. Krav til ikke tilstede/ikke forstyrr Noen abonnenter har i dag systemapparat hvor det er programmert en knapp som heter «Ikke forstyrr». Ofte fungerer denne på samme måten som en direkte viderekobling. Beskriv om det er forskjell på «ikke forstyrr» og «direkte viderekobling». 34. Krav til viderekobling til talepostkasse Dersom abonnenten velger å viderekoble til sin talepostkasse, direkte eller fast etter x antall ring, og ikke ønsker å lese inn sitt eget talesvar, skal innringer få en ferdig innlest melding (fra systemet) som følger: «Abonnenten du ringer er opptatt eller ikke tilgjengelig. Vennligst ring igjen senere, eller legg igjen en beskjed etter pipetonen.» 35. Krav til samtidig ringing på inntil tre telefoner samtidig (parallellringing) Dette kan være interne, eksterne eller mobile telefoner. Innringers A- nummer skal vises på samtlige av telefonene. 36. Talepostkasse (styring av talebeskjedene) Hver enkelt abonnent skal få sin egen talepostkasse. Abonnenten skal selv gjennom sin egen administrasjonsside kunne velge om han/hun vil ha talebeskjedene i sin innboks (som et vedlegg til en e-post), eller om de skal kunne nåes via egen telefon. Dersom abonnenten velger å la talebeskjeden komme til sin egen telefon, 17

18 skal nye beskjeder varsles med lampe (ikke blinkende) og/eller med tekstlig melding i telefonens vindu (display). Abonnenten skal kunne lese inn og lytte til sitt egeninnspilte talesvar ved å ringe et bestemt nummer, eventuelt slå en kode, se nummer 31, personlig talesvar. Krav vedrørende administrasjonsverktøy 37. Krav til administrasjonsside for den enkelte abonnent Hver abonnent skal ha sin egen web-baserte administrasjonsside. Siden skal ha unik pålogging for hver abonnent. Abonnenten skal selv kunne administrere følgende: Velge om det skal være en eller to linjer på egen telefon. (Velger abonnenten to linjer, skal innringer ikke få opptattsignal, med mindre abonnenten faktisk er opptatt på begge linjer. Velger abonnenten en linje, skal innringer nr to få opptattsignal. Forutsetter at administrator har åpnet for dette, se nummer 38 ). Sette parallellringing på inntil to andre, vilkårlige numre. (Forutsetter at administrator har åpnet for parallellringing). Egne viderekoblinger (sette tid før viderekobling og hva det skal viderekobles til). Et av valgene skal være viderekobling til eget talesvar (se pkt 31 for nærmere beskrivelse av dette). Det skal også kunne viderekobles til abonnentens talepostkasse, med ett standard (felles) talesvar (se nummer 34). Se hvilke innhentgrupper abonnenten er med i. Styre om talemeldingene skal sendes som e-post til innboksen i e- postprogrammet, spilles av på abonnentens egen telefon eller begge deler. Se vedlagte skisse for hvordan en slik administrasjonsside kan se ut. Dersom en Softphone kan ivareta disse kravene, så kan det aksepteres at ovenstående administreres gjennom softphone-en. Alle skal ikke ha softphone, så en slik administrasjonsside skal uansett tilbys. 38. Krav til administrasjonsverktøy for administrator Abonnentsdata og konfigureringer som ikke er tilgjengelig fra AD, skal autorisert IT-personell kunne administrere via et eget web-basert administrasjonsverktøy. Som et minimum skal følgende kunne administreres: Knytte telefon til abonnent Tildele fysisk telefon til nye abonnenter og endre telefon for eksisterende abonnenter. Beskriv hva som skjer når en abonnent slettes. Abonnentens personlige telefonoppsett Se og endre abonnentenes personlige telefonoppsett (administrator skal ha mulighet til å gjøre det samme som den enkelte abonnent selv 18

19 kan). Meldinger Sette hvor lenge innkommende talemeldinger skal være tilgjengelig i systemet. Ved overtagelse skal dette være satt til 7 dager. Innhentgrupper Se oversikt over innhentgruppene (selve opprettelsen og administrasjonen av disse skal skje i AD). Køer (ACD) Opprette og administrere køer, inkl. å definere kønummeret, ringemønsteret til køen (køfordelingen), opprette og velge inntil to talesvar (med variabel tid mellom dem, og tidsangivelse av når det første talesvaret skal inntreffe), definere type agenter (statiske eller dynamiske), melde inn/ut agenter, samt sette prioritet på agentene (min. tre prioritetsnivåer), samt velge om innringer skal få beskjed om sitt nummer i køen. Slike parametre skal kunne settes pr kø. Agenter til krisemodusen Opprette og melde agenter inn i krisekøen (se nummer 40, krisestilling). Talesvar (IVR) Innleggelse og administrasjon av samtlige talesvar i systemet, med unntak av abonnentenes egne talesvar som de selv leser inn gjennom egen telefon. Talesvar til køer skal kunne ha mulighet for å kombineres med menyvalg av typen Tast en for, tast to for og tast tre for eller vent på svar ). Beskriv begrensningene i dette. En eller to linjer Administrator skal innenfor en virksomhet/enhet kunne selv velge om abonnentene skal ha en eller to linjer. Hvis abonnentene gis dette valget, skal de i sin egen administrasjonsside kunne velge om de vil ha en eller to linjer. En linje som standard Dersom administrator har satt en linje som standard for alle abonnenter i en virksomhet/enhet, skal ikke abonnentene i sin egen administrasjonsside presenteres for valget mellom en eller to linjer. Innringer skal få opptattsignal når abonnenten er opptatt i telefonen. To linjer som standard Dersom administrator har satt to linjer som standard for alle abonnenter i en virksomhet/enhet, skal ikke abonnentene i sin administrasjonsside presenteres for valget mellom en eller to linjer. Innringer får ikke opptattsignal, selv om abonnenten sitter opptatt i telefonen. Gi opptattsignal for interne abonnenter Administrator skal kunne sette om interne anrop skal få opptattsignal, når en intern abonnent ringer en annen intern abonnent som er opptatt i en samtale (gjelder kun dersom tilbyder velger å besvare punkt 4.6, nummer 25). Tilbakeanrop til sentralbord Administrator skal kunne sette om tilbakeanrop skal gis prioritet i 19

20 sentralbordkøen eller ikke. Skal kunne settes pr virksomhet/enhet. «Click-to-call» Administrator skal kunne sette hvilke tallserier, antall siffer i tallet og tallkombinasjoner (tall med mellomrom mellom noen av sifrene) som skal fungere med «click-to-call»-funksjonaliteten. Dette for å begrense antall tall som gis funksjonaliteten «click-to-call» (se nummer 14). Sperrelister Opprette og administrere sperrelister («tillat-lister»). Sperringer ifm viderekobling, parallellringing og «click-to-call» Opprette og installere sperringer ifm. viderekobling, parallellringing og «click-to-call» (for eksempel om en enkelt abonnent, eller en gruppe av abonnenter, skal kunne viderekoble til en mobiltelefon eller et utenlandsnummer). Dette skal sees i sammenheng med kategoriene som angitt i nummer 32 (sperrelister). Alle sperringer skal kunne gjøres pr virksomhet/enhet. Statistikk Det skal kunne tas ut statistikk for hele nummerserier, pr virksomhet/enhet, pr kø eller for en enkelt abonnent. Statistikken skal kunne gi informasjon om hver enkelt ut- og inngående samtale (nummer, tidspunkt og varighet), totalt antall inn- og utgående samtaler, total samtaletid til forskjellige nummergrupper (for eksempel innenlands fast, innenlands mobil, Norden fast, Norden mobil, Europa fast, Europa mobil, resten av verden), totalt antall besvarte og ubesvarte, samt maksimum og gjennomsnittlig svartid. I tillegg skal det være mulig å ta ut statistikk for de lengste samtalene, og eventuelt mest kostbare dersom kostnadsdata er implementert (se punkt 4.6, nummer 12). All statistikk skal kunne periodeavgrenses. I tillegg skal det kunne tas ut statistikk på abonnentutstyr (for å se hvor mange telefoner av den og den typen som er i bruk). Statistikk skal være tilgjengelig i løsningen i en konfigurerbar tid (maksimum tre år). Deretter skal statistikkene kunne slettes eller arkiveres. Leverandøren er ansvarlig for at gjeldende lover og regler følges på dette området (ref nummer 83). Statistikken skal kunne eksporteres på et dokumentert, åpent format for å kunne behandles videre med AFKs egne verktøy (for eksempel regneark eller tilgjengeliggjøre dem på en webside for andre enn administrator). Funksjonalitet som er knyttet til installasjon av systemet skal ikke være en del av administrasjonsverktøyet. Dog kan det aksepteres at det er inkludert, men da skal det være skjult bak et menyvalg som er tydelig merket, eventuelt gjennom en separat pålogging. Beskriv verktøyet nærmere, legg ved skisser/skjermdump av de viktigste administrasjonssidene. 20

21 39. Krav til administrasjons-/statusside for agenter («kø-app») For personell som betjener en dynamisk kø (agenter), skal det startes opp en liten applikasjon samtidig med at PC-en startes opp (gjelder ikke for ekspedienter). I et vindu, med bredde piksler og høyde tilsvarende antall agenter, skal følgende kø-informasjon vises: Antall innkommende samtaler i kø, gjerne visualisert gjennom en graf, gjerne med farger (for eksempel grønt for de to første, så gult for de to neste, og så rødt for de påfølgende). Oversikt over totalt antall agenter, hvor det på samme linjen skal vises om agenten er logget inn eller ikke. Alle agenter i en gruppe skal kunne logge inn eller ut andre agenter i den samme gruppen. Prioritet skal kunne settes på agentene. Applikasjonen skal kunne fungere på Citrix terminal-serverløsning. <navn på kø> Ant. i kø: Ola Nordmann Kari Nordmann Ole Olsen Berit Hansen Fredrik Svendsen Skissen viser et eksempel på hvordan en slik applikasjon kan se ut. Over er det 6 inngående samtaler som står i kø, Ola, Kari og Ole er innlogget som agenter, hvorav alle har prioritet 1, mens Berit og Fredrik har prioritet 2 og er ikke innlogget. Hvem som helst av de fem kan melde Berit og Fredrik inn for å betjene køen, og hvem som helst kan melde Ola, Kari og Ole ut av køen. Krav vedrørende sentralbord 40. Felles krav, uavhengig av type sentralbord Det skal være en desentralisert svartjeneste hos hver enkelt virksomhet/enhet. Virksomheter med mer enn 15 ansatte skal ha PC-basert sentralbord (sentralbordapplikasjon) Alle funksjoner beskrevet her skal gjelde innenfor den aktuelle virksomhet/enhet. Nattstilling (nattmodus) Det skal være automatisert nattstilling av sentralbord, med fritt valgt tidsrom, talesvar og funksjonalitet som følger: Du har kommet til våre åpningstider er., Kjenner du internnummeret til den du søker, taster du nummeret til vedkommende nå. Endelig tekst avtales med den enkelte virksomhet/enhet, og leses inn av person ved virksomhet/enheten, eller av 21

22 leverandøren. Overstyring av automatisk nattstilling skal skje ved å trykke på en knapp ( nattstillingsknapp ) eller slå en bestemt kode. Funksjonen skal sette sentralbordet direkte i nattstilling, og oppheve den automatiske nattstillingen. Krisestilling (krisemodus) Sentralbordet skal ha en kriseknapp for å sette sentralbordet (systemet) i krisemodus for den enkelte virksomhet/enhet. Denne modusen er tenkt når en alvorlig krise oppstår ved en av våre virksomhet/enheter, og det er grunn til å anta en stor økning av innkommende samtaler. For å kunne besvare denne økte trafikkmengden, skal ekspedienten med et tastetrykk kunne koble inn flere telefoner som kan benyttes som svarsteder. Når denne kriseknappen aktiveres, skal følgende skje: En på forhånd innspilt talemelding går ut på høyttaleren på samtlige telefoner, samt at en melding kommer opp på PC-skjermen. Ekspedienten, eller annet autorisert personell ved virksomhet/enheten, skal kunne spille denne meldingen inn umiddelbart før den sendes ut (Ref. informasjonen som ropes ut fra en fly-gate. Denne blir alltid spilt inn først, for så å ropes ut umiddelbart etterpå). En på forhånd definert mengde apparater kobles inn som agenter i krisekøen. De apparater som ikke kan betjenes (fordi ingen personer er til stede), meldes automatisk ut av køen etter 4 ring (kan endres i admininstrasjonsverktøyet), før innkommende samtale går videre til neste apparat. Et på forhånd innspilt talesvar besvarer automatisk alle innkommende samtaler etter ett ring. Ved kø, skal et nytt talesvar komme etter et valgfritt antall ring etter at det første talesvaret er avsluttet. Beskriv dette nærmere 41. Krav til sentralbordapparat På skolene benyttes i dag i stor grad fysiske telefoner med tablå som sentralbord. Noen skoler ønsker trolig å fortsette med dette. Sentralbordapparatet må derfor ha mulighet til å ha programmerbare knapper, tilsvarende funksjonalitet som beskrevet for utvidet fasttelefon (nummer 56), men i tillegg må det kunne tilkobles fysiske tablåer (sidekonsoll). Som et minimum skal det kunne tilkobles to tablåer, hvorav hvert tablå skal ha minimum 8 programmerbare knapper. Angi størrelsen på tablåene og hvor mange tablåer som kan kobles til. Se for øvrig nummer Krav til PC-basert sentralbord (sentralbordapplikasjon) Skjermformatet skal være 16:9 (widescreen). 22

23 Krav til avgrensning av abonnentene Sentralbordapplikasjonen skal kun håndtere de abonnenter som hører til den aktuelle virksomhet/enheten. AFKs øvrige abonnenter skal ikke presenteres for ekspedienten ved en virksomhet/enhet (se for øvrig punkt 4.6, nummer 3 og 4). 43. Krav til betjening av sentralbordet Sentralbordet skal kunne betjenes med pekeredskap, samt at de viktigste funksjonene også skal kunne betjenes med tastaturet, fysisk telefon og knapp på hodesett. Å besvare en samtale skal kunne gjøres med Enter eller retur-tasten, og å sette over en samtale skal gjøres med samme tast og/eller pluss-tasten. Å terminere en samtale skal kunne gjøres med minus-tasten. Beskriv dette nærmere (hvilke andre hurtigtaster benyttes? Kan vi selv velge hvilke taster som skal ha hvilken funksjonalitet?) 44. Krav til betjening av sentralbord ved innkommende anrop. Når det kommer et innkommende anrop: Ekspedient svarer ved å trykke på dedikert svartast (enter-tasten) på tastaturet, trykke på knapp sentralbordapparatet eller på hodesettet. Innringer spør etter person, eller funksjon. Ekspedient søker på navn, internnummer eller funksjon (for eksempel «realfaglærer»). Resultatet vises umiddelbart (maks 0,5 sekunds responstid). Hvis flere alternativer, ekspedienten velger med piltaster eller mus. Ekspedienten overfører den markerte abonnenten med enter-tasten, eventuelt retur-tasten eller dedikert overføringsknapp på sentralbordapparatet. 45. Krav til bestilling av samtale Ekspedient skal kunne ringe de nummer vedkommende har tillatelse til (ref. nummer 32, sperrelister) og deretter overføre oppsatt samtale til intern abonnent. 46. Krav til direkte viderekobling for intern abonnent Det skal være mulig for ekspedient å sette direkte viderekobling til sentralbordet for alle abonnentene i egen virksomhet/enhet. Beskriv dette nærmere. 47. Krav til visning av kø Ekspedient skal til enhver tid se antall som er i kø og hvor lenge den enkelte innringer har stått i kø. Innringers nummer og navn skal vises (også for eksterne innringere, ref. nummer 16, integrasjon). Hvis tilbakeanrop er gitt prioritet, så skal disse komme først i køen. Ekspedienten skal se både innringers nummer, og hvilket internnummer innringer forsøkte å nå (se eget nummer 50, tilbakeanrop). 48. Krav til visning av status på abonnent i egen virksomhet/enhet 23

24 Ekspedient skal kunne se med en grafisk indikasjon (ikon/farge el.lign.) om intern abonnent i egen virksomhet/enhet er opptatt i telefonen eller ikke, samt om apparatet er ute av funksjon. Ekspedient skal kunne se slik status uten å måtte søke opp vedkommende. Feltet hvor denne oversikten vises, skal ikke dekke mer enn ca ¼ av sentralbordapplikasjonens vindu. Dersom abonnent har flere inngående linjer på sin telefon, og han/hun sitter opptatt i en samtale, mens linje to er ledig, så skal dette markeres som opptatt. Samme gjelder dersom abonnent er opptatt i samtale som kommer fra en kø. Abonnenter skal om ønskelig kunne deles i grupper, for eksempel ut i fra avdeling/organisasjonsenhet (hentes fra AD), og hver gruppe skal kunne ekspanderes med et museklikk (á la funksjonen som i en vanlig filbehandler). Til slutt i denne lista skal køene vises på tilsvarende måte. Ekspedient skal se hvilke agenter som er opptatt, hvilke som er ledige (men er innlogget) og hvilke som er avlogget. Ekspedienten skal kunne logge agenter inn/ut på den køen de er definert under. 49. Krav til parkering av samtaler Ekspedient skal kunne parkere minst ti samtaler. Ekspedient må kunne se nummeret, og eventuelt navnet, til de(n) som er parkert, for å kunne velge hvem som skal hentes inn igjen. Beskriv funksjonen nærmere. 50. Krav til tilbakeanrop Tilbakeanrop skal kunne gis prioritet foran nye innringere. Dette skal kunne settes ( enables ) via administrasjonsverktøyet. Ekspedient skal se både hvem anropet kommer fra (internabonnenten) og innringers nummer, eventuelt også navnene på begge. Internabonnentens kalenderdata (fra MS Exchange) skal komme opp med en gang anropet besvares. Maksimal forsinkelse for opphenting av kalenderdata skal være 0,5 sek. Tilbakeanropene skal ikke innvirke på varslingen som gis til de øvrige innringere som står i køen (informasjon om hvilket nummer innringer har i køen). 51. Krav til integrasjon mot Microsoft Active Directory (AD) Ekspedienten skal i sentralbordapplikasjonen kunne søke på den informasjonen man i prosjektet er blitt enige om å hente ut fra MS Active Directory. Det må tas høyde for at det kan være så mye som følgende: Navn Forværelse/sektretær Direkte innvalgsnummer Mobilnummer Organisasjonsenhet (avdeling/virksomhet/enhet/seksjon) 24

25 E-post Brukernavn Arbeids-/fagområde Telefaksnummer Tittel Geografisk arbeidssted Bygning- eller romnummer Nærmeste kolleger (som kan svare for vedkommende) Selve AD og innholdet i AD er AFKs ansvar. AFK aksepterer at ikke alle ovenstående parametere implementeres ved oppstart av migrering. Leverandøren implementerer det som er hensiktsmessig ut ifra hvilke opplysninger som pr dato er tilgjengelig i AD. 52. Krav til meldingssystem Ekspedient skal kunne sende mobiltelefon-meldinger (SMS) til alle mobilabonnenter. Har ekspedienten oppe på skjermen en av de ansatte, f.eks. pga et «tilbakering», eller fordi ekspedienten har søkt opp vedkommende, skal ekspedienten kunne skrive en beskjed i et felt og kun behøve å klikke «send beskjed» (el.l. tekst). Se for øvrig opsjoner, punkt 4.6, nummer 2, sende e-post fra sentralbordapplikasjonen. 53. Krav til fraværsmarkering Som fraværssystem skal MS Exchange benyttes. Det skal ikke være noe eget system for markering av fravær eller tilstedeværelse. System hvor abonnent markerer en aktivitet i sin kalender som automatisk medfører en direkte viderekobling til et talesvar eller sentralbord er ikke ønskelig. Vi ønsker heller å gi innringer noen valg når en abonnent er opptatt eller av andre årsaker ikke kan ta telefonen (se nummer 31, talesvar). Velger innringer å bli satt over til sentralbordet, så skal ekspedienten umiddelbart (senest innen 0,5 sek) få presentert internabonnentens kalenderdata i et vindu i sentralbordapplikasjonen. Som standard skal vinduet vise kalenderdata fra reelt tidspunkt og ut dagen (kl 16). Ekspedienten må på en eller annen måte også kunne se kalenderdata for de kommende dagene. Beskriv dette nærmere. Krav vedrørende abonnentutstyr 54. Krav til abonnentutstyret Tilbyder skal kunne levere abonnentutstyr fra minimum to forskjellige produsenter innenfor hver kategori, med unntak for softphone og kommunikasjonsbokser. Det skal legges ved en produktkatalog som viser produktene og prisene for det enkelte produkt (Det aksepteres en produktkatalog for hver av de to produsentene). Det skal gis en rabatt for hver enkelt produktkategori (kan være forskjellige for de to produsentene). Kategoriene skal være i samsvar med kravene 25

26 nummer 55 til og med 69. Fasttelefonene som tilbys skal være støttet av løsningens provisjoneringsløsning. Alle tilbudte apparater (IP-telefoner, USBtelefoner/håndsett og softphone) skal sammen med løsningen sende ut DTMF-toner, uten at abonnenten behøver å gjøre noe spesielt for at så skal skje. All funksjonalitet (gaffel og andre fysiske knapper) på USB-enhetene skal fungere sammen med den tilbudte softphone-en. Samtlige telefoner skal støtte standardene angitt i nummer 5. Samtlige produktene angitt i den vedlagte produktkatalogen skal være representert i tilbyders nettbutikk (se nummer 77; nettbutikk). Sammen med tilbudet skal det leveres vareprøver på de produktene tilbyder velger å benytte for utregning av totalprisen, se tilbudsskjemaets del Krav til standard fasttelefon Ha to linjeknapper (hvorvidt begge skal tas i bruk avhenger av innstilling gjort i administrasjonsverktøyet). Ha fast knapp for repetisjon av siste eller de x antall sist ringte nummer. Utgående anrop skal kunne skje på samtlige av følgende måter: a) Ta av røret og tast ønsket telefonnummer. b) Tast ønsket telefonnummer og ta av røret, trykke på høyttalerknappen eller hodetelefonknappen (dersom abonnenten benytter hodesett) c) Trykke på «repeter nummer»-knappen Besvare anrop skal kunne skje på samtlige av følgende måter: a) Ta av røret b) Trykke på høyttalerknappen c) Trykke på hodetelefonknappen (dersom abonnenten benytter hodesett) 2-veis høyttalende Ha «sperr-mikrofon»-knapp (eng: mute). Ha display som minimum viser klokkeslett, og nummeret/numrene til abonnenten når apparatet er i standby-modus.. Ha indikasjonslampe (eventuelt varsling i display) når det er kommet en talebeskjed. Ved innkommet talebeskjed skal denne lyse konstant (ikke blinke). Softkeys. Dersom apparatet har «softkeys» (knapper som endrer funksjon avhengig av hva apparatet antar brukeren ønsker å gjøre), skal ingen av knappene ha samme funksjon som øvrige knapper på apparatet. Det betyr at det ikke skal være softkey for «nytt anrop» eller «svare anrop». Egen knapp (eller softkey som vises når apparatet er i standbymodus) for direkte viderekobling eller ikke-forstyrr. Beskriv denne funksjonen vs den direkte viderekoblingen som kan settes på abonnentens administrasjonsside (se nummer 37). 26

27 Egen knapp (eventuelt softkey) for å se mottatte anrop. Egen knapp (eventuelt softkey) for å komme til abonnentens personlige adressebok. Egen knapp (eventuelt softkey) for å lytte til egne talemeldinger. (se krav til funksjonalitet vedr. talemeldinger under nummer 28). Mulighet for hodesett med 2,5 mm minijack-plugg, og knapp på apparatet for å besvare med hodesettet. Volumknapp som justerer ringestyrken når røret ligger på og volumet i røret når røret er av. Kunne velge andre ringelyder/melodier. Innebygd svitsjing Støtte flere VLAN (VLAN-tagging i henhold til IEEE 802.1p/Q) Skal støtte krav til prioritering, se nr 5, krav til standarder. Støtte for Power over Ethernet (PoE. Separat strømforsyning skal ikke inkluderes, men oppgis i produktkatalogen) Kryptering (TLS og SRTP. Se nummer 11, krav til sikring av løsningen) Beskriv de tilbudte apparatenes funksjoner. Angi type (Cat.) og antall tilkoblingskabler som medfølger. Angi hvilken PoE-standard som benyttes (IEEE 802.3af/IEEE 802.3at) 56. Krav til utvidet fasttelefon (type sekretærapparat ) Samme krav som over, men med minst seks programmerbare knapper. Disse skal kunne programmeres med forskjellige funksjoner. Som et minimum skal de kunne programmeres med et internnummer som skal fungere som følger (direkte linje-knapp): Abonnent med sekretærapparatet skal kunne se en blinkende lampe eller lignende varsling på display, om det ringer på det innprogrammerte nummeret. Abonnenten skal kunne besvare (hente inn) samtalen ved å kun trykke på knappen for det innprogrammerte nummeret. Abonnenten skal kunne ringe det innprogrammerte nummeret kun ved å trykke på knappen en gang. Abonnenten skal kunne sette over en samtale ved å trykke på knappen for det innprogrammerte nummeret (eventuelt i tillegg trykke på en overfør-tast). Skal kunne tilkoble et eller flere sidekonsoll (tablåer). Kan ha annet tilkobling for hodesett. Beskriv de tilbudte apparatenes funksjoner inklusive variantene og antallet av tablåer som kan kobles til. 57. Krav til trådløs telefon, med uttak for hodetelefon Trådløse enheter skal primært være basert på DECT. Pga strømforbruket har rene trådløse IP-telefoner (Wi-Fi) ikke vært aktuelle, men dette kan ha endret seg i det siste. Det skal derfor i produktkatalogen tas med Wi-Fi 27

28 telefoner med lavt strømforbruk og/eller høy batterikapasitet. Samtlige trådløse telefoner skal ha utgang for hodesett, basert på 2,5 mm minijack kontakt. Telefonene skal kunne: Vise anropslogg (besvarte og ubesvarte anrop) Indikere at det er kommet en talemelding Lytte til talemelding Sette over en samtale Parkere en samtale/sette på venting («hold») Det kan bli aktuelt for mer omfattende og helhetlig trådløsløsninger ved noen av virksomhet/enhetene. Produkter for slike helhetlige installasjoner skal fremkomme i produktkatalogen under egen kategori (med tilhørende priser og rabattsatser). 58. Krav til trådløs telefon, med mulighet for bluetooth hodesett Samme som over, men med mulighet for bluetooth hodesett. 59. Krav til USB håndsett, trådbasert, uten tastatur, med gaffelfunksjon Bruksområde: Enkelt håndsett til bruk for kontorpersonale sammen med softphone. Håndsettet må ha en lydkvalitet som minst tilsvarer ordinære håndsett brukt til ISDN- og digitale systemapparater ( Hz). For krav til gaffelfunksjonen: Se under Programvarebasert telefon (softphone). 60. Krav til trådbasert USB håndsett med tastatur og gaffelfunksjon ( USB telefon ) Bruksområde: Enkelt håndsett til bruk for kontorpersonale sammen med softphone. Skal ha «bredbåndslyd» («wideband», Hz). Standard USB-plugg. For krav til gaffelfunksjonen: Se under Programvarebasert telefon (softphone). 61. Krav til trådløst håndsett med gaffelfunksjon Bruksområde: Enkelt håndsett til bruk for kontorpersonale sammen med softphone. Baseenhet skal medfølge (USB-DECT/USB-Bluetooth-stikk). Rekkevidde inntil 5 meter. Skal kunne fungere samtidig mot mobiltelefon. For krav til gaffelfunksjonen (fjernsvarfunksjonen): Se under Programvarebasert telefon (softphone). Standard USB-tilkobling for baseenheten Beskriv gaffelfunksjonen nærmere. 62. Krav til trådløst håndsett, med tastatur og gaffelfunksjon Samme som over, men hvor enheten i tillegg har et vanlig telefontastatur. 63. Krav til trådbasert analogt hodesett, uten hodebøyle Bruksområde: Som supplement for undervisningspersonell til bruk sammen med softphone på bærbar PC. Enkelt og prisgunstig hodesett med 2,5 mm minijack-plugg. Mono eller stereo. Skal leveres med overgang til to stk 3,5 mm minijack-plugger (for tilkobling til tradisjonell lydenhet på PC) 64. Krav til trådbasert USB hodesett 28

29 Bruksområde: Daglig telefonbruk sammen med softphone for kontor- og undervisningspersonell, samt ansatte ved tannklinikkene. Skal være beregnet for IP-telefoni Mono (kun en ørepute) Metall hodebøyle Ørekrok skal følge med Kevlar- eller metallforsterket ledning Teknologi for beskyttelse mot akustisk lydsjokk (høye/skarpe lyder som er skadelig for øret) Bredbåndslyd ( wideband ) Standard USB-plugg. 65. Krav til trådløst hodesett med gaffelfunksjon (fjernsvarfunksjon), lang rekkevidde Bruksområde: Daglig telefonbruk sammen med softphone for kontor- og undervisningspersonell, samt ansatte ved tannklinikkene som ønsker lang rekkevidde. Baseenhet skal medfølge (USB-DECT/USB-Bluetooth Class1). Bæremulighet: Ørekrok, men med mulighet å kjøpe hodebøyle i tillegg. Rekkevidde: Inntil 100 meter fra baseenheten (i et normalt kontorbygg) Beskriv hvordan enheten vil fungere i et WLAN-miljø (Vil den la seg påvirke av et omfattende WLAN?). 66. Krav til trådløst hodesett med gaffelfunksjon (fjernsvarfunksjon), kort rekkevidde Bruksområde: Daglig telefonbruk sammen med softphone for kontor- og undervisningspersonell, samt ansatte ved tannklinikkene. Baseenhet skal medfølge (USB-DECT/USB-Bluetooth Class 2/3). Bæremulighet: Hodebøyle, men med mulighet å kjøpe ørekrok i tillegg. Rekkevidde: Inntil 5 meter fra baseenheten (i et normalt kontorbygg) Beskriv hvordan enheten vil fungere i et WLAN-miljø (Vil den la seg påvirke av et omfattende WLAN?). For ekspedienter vil det trolig være behov for et annet type hodesett. Aktuelle hodesett for ekspedienter skal fremkomme i produktkatalogen (med tilhørende priser og rabattsats). 67. Krav til programvarebasert telefon (softphone) Softphones skal fungere som følger: Inngående anrop: Skal ringe i den innebygde høyttaleren i PC-en eller tynnklienten (ikke i hode- eller håndsettet, med mindre USB-enheten har egen høyttaler for ringelyden). Softphone-en bringes fram som det aktive vinduet. Inngående samtale besvares ved å trykke på dedikert tast på tastaturet, eller i tillegg trykke på knapp i selve softphone-en 29

30 Dersom et USB-håndsett eller trådløst hodesett med gaffelfunksjon (fjernsvarfunksjon, EHS; Electronic Hook Switch) er tilkoblet, så skal inngående anrop kunne tas ved å utløse gaffelfunksjonen. Gaffelfunksjonen kan være automatisk (for håndsettet; bare å løfte opp røret), eller manuell (hvor abonnenten manuelt må trykke på en bryter; typisk for det trådløse hodesettet). Utgående anrop: Et klikk på softphone-ikonet, som ligger på oppgavelinjen, bringer softphone-en fram som den aktive applikasjonen. Uten å måtte klikke noe sted, skal abonnent kunne taste et nummer med tall-tastene på tastaturet, eller på soft-tastene i softphone-en. Oppringing starter ved å trykke på Carriage Return- eller Enter-tasten på tastaturet, eller knapp i selve softphone-en. Dersom et USB-håndsett med gaffelfunksjon er tilkoblet, så skal utløsning av gaffelfunksjonen bringe fram softphone-en som det aktive vinduet, summetone skal komme i håndsettet, og nummer skal kunne slås direkte, og oppringning skal starte automatisk, uten og måtte trykke på noen tast for å generere oppringningen ( å sende nummeret ). Legge på en samtale: Dersom et USB-håndsett eller hodesett med gaffelfunksjon er tilkoblet, så skal samtalen avsluttes når gaffelfunksjonen bringes til utgangsposisjonen («Legge på røret»). Annet: Det skal være en knapp for direkte viderekobling. Anropslogg skal vise ubesvarte og besvarte anrop. Det skal være en personlig avtalebok. Skal støtte kryptering basert på TLS og SRTP (Se nummer 11, krav til sikring av løsningen) Skal støtte krav til prioritering, se nr 5, krav til standarder. Skal ha multiplattformstøtte. Konkret skal den som et minimum støtte følgende operativsystemer: Windows Vista, Windows 7, OS X, Linux (RPM/DEB), samt Windows Server 2003 og 2008 (Citrix XEN App). Tilbudte softphones skal fungere med tilbudte hode- og håndsett, inklusive eventuelt gaffelfunksjon. Beskriv softphone-ens funksjonalitet. Kan abonnenten, for eksempel, legge inn nummer og koder på hurtigtast, for eksempel koden for innhent samtale og ventekobling («tilbakering»)? Beskriv muligheten for å gjøre endringer i softphone-ens programvare. Kan for eksempel AFKs logo legge inn? Beskriv hvorvidt slike endringer kommer i konflikt med oppdateringer og oppgraderinger. Dersom slike tilpasninger/endringer kommer i konflikt med produsentens oppdateringer/oppgraderinger, beskriv hvordan tilbyder vil løse dette. 30

31 Krav vedrørende annet utstyr 68. Krav til annet utstyr Det skal gis tilbud på utstyr som kan benyttes for å koble eksisterende hussentraler inn mot den nye løsningen. Denne typen utstyr skal kunne benyttes dersom dette er hensiktsmessig (for eksempel fordi en virksomhet/enhet har en forholdsvis ny hussentral, med lave drifts- og vedlikeholdskostnader, eller dersom kostnadene til å bygge ut IKT-infrastrukturen blir uforholdsmessig høy). Prisen som skal oppgis for slikt utstyr i tilbudsskjemaet skal være for ett stk ISDN UT (30 kanaler). 69. Krav til annet utstyr Det antas at hver virksomhet/enhet har noe analogt utstyr som de ønsker å beholde, og som ikke skal kobles til en egen linje. Det er derfor i tilbudsskjemaet inkludert ett stk «analog-boks» med åtte analoge linjer til hver virksomhet/enhet. Dette er bare et anslag og leverandørens leveranseansvarlig skal avklare behovet nærmere for hver enkelt virksomhet/enhet. Krav vedrørende tjenester 70. Krav til prosjektarbeid I forbindelse med prosjektarbeidet skal leverandørens personell kunne utføre følgende oppgaver: - Planlegge migreringen for samtlige virksomhet/enheter. For de virksomhet/enhetene som har forholdsvis ny telefoniløsning, med lave drifts- og vedlikeholdskostnader, skal det vurderes bruk av kommunikasjonsboks som kobler dagens løsning inn i mot den nye løsningen. Dersom dette er aktuelt, skal det gjøres en kostnadsberegning, og saken skal legges fram for sentral IT. - Innhente og analysere den enkelte virksomhet/enhets nummerplan og foreslå endringer (forenklinger). - Kartlegge lokalnett-infrastrukturen og eventuelt komme med forslag til endringer. - Innhente informasjon om hvordan den enkelte virksomhet/enhet ønsker sin del av løsningen konfigurert, samt stå for selve konfigureringen. Dette inkluderer: o Avklare dette med en eller to linjer. o Avklare sperringene ifm viderekobling, parallellringing og click-to-call (både hvor man kan ringe og med hvilket utstyr man kan ringe med og hva man kan viderekoble til). o Viderekoblingene. o Innhentgruppene. o Køene (inkl. køsvar). o Nattstillingen (inkl. innspilling av talesvar). o Krisemodusen. - Identifisere alle analoge enheter/linjer, fysisk på plint og numre, og foreslå løsninger for hvordan disse bør håndteres i den nye løsningen (Vær spesielt oppmerksom på linjer for alarm, heis og 31

32 frankeringsmaskin). - Sammen med virksomhet/enheten beslutte type telefoner, bestille disse, utplassere og sette dem i drift. - Leverandøren har ansvar for håndtering av all emballasje og tilhørende avfall. Dersom kildesortering (søppelsortering) utføres hos den aktuelle virksomhet/enhet, skal AFKs praksis for kildesortering følges. - Portere nummer, eventuelt ta ut nye numre/nummerserier. - Utarbeide anleggsdokumentasjon (se eget nummer om krav til dokumentasjon). - Demontere og avhende eksisterende utstyr. I samråd med AFK avgjøres hvorvidt utstyret skal kastes eller selges. Alt praktisk arbeid vedrørende et mulig salg skal ordnes. Denne tjenestens kostnad skal utelukkende finansieres av salget. Inntekten av salget deles likt mellom AFK og leverandøren. - Ta initiativ til og lede ENUM-pilotprosjektet. Leverandøren rapporter til AFKs IT-avdeling en gang pr måned. Dette skjer i et statusmøte i AFKs lokaler i Schweigaards gate, Galleriet, Oslo. Leverandøren orienterer om status og fremlegger oppdatert fremdriftsplan, samt at han/hun tar opp til diskusjon problemstillinger knyttet til eksisterende infrastruktur. Møtet skal vare ca en time. 71. Krav til installasjonsrutine for fasttelefon Leverandøren skal ved utsendelse av en fysisk telefon benytte provisjoneringsløsningen på en slik måte at administrator skal kunne finne igjen telefonen i administrasjonsverktøyet og tildele telefonen til den aktuelle abonnenten. Lokal IT-ansvarlig ute på en virksomhet/enhet skal kun behøve å plugge apparatet i ønsket kontakt, samt eventuelt å plugge i en strømforsyning og sette riktig VLAN på apparatet. Dersom oppkobling av kontakt (kategori 5 kablingspunkt) er påkrevet, skal leverandøren i samråd med lokal ITansvarlig diskutere hva og hvem som kobler opp punktet. Kostnader til fysisk kabling og oppkobling av punkt er ikke en del av avtalen. Beskriv rutinen nærmere. 72. Krav til installasjonsrutine for softphone-ene Tannklinikkene og administrasjonen på skolene benytter stort sett tynnklienter, mens lærere benytter for det meste bærbare PC-er. I sentraladministrasjonen (Schweigaards gate, Oslo) er det en blanding. Softphone-ene skal installeres på den sentrale Citrix terminalserveren (Citrix XenApp - Citrix Presentation Server 5.0) i samarbeid med Sentral IT. Leverandøren skal gjøre nødvendig programvare tilgjengelig for AFK. Eventuelle lisenskoder og påloggingsinfo skal også inkluderes. Selve installasjonene gjøres av AFKs eget IT-personell. 73. Krav til overordnet migreringsplan og implementeringsplan for den enkelte virksomhet/enhet Det skal, som en del av prosjektet, lages en overordnet migreringsplan hvor det fremgår når den enkelte virksomhet/enhet planlegges migrert over til ny 32

33 løsning. Leverandørens leveranseansvarlig er ansvarlig for utarbeidelse og løpende oppdatering av planen. Planen skal danne grunnlaget for statusrapportering til IT-enheten. Videre skal det lages en implementeringsplan for den enkelte virksomhet/enhet. Denne skal inneholde følgende: Overordnet systembeskrivelse med skisse Nummerplan (utvidelse av eksisterende, eller ny?) Status på IKT infrastruktur, med eventuelt forslag til tiltak Oversikt over analoge enheter (alarmer med mer) og hvordan disse er tenkt koblet opp mot ny løsning. Oversikt over nytt utstyr som skal anskaffes Oversikt over utstyr som skal gjenbrukes Plan for avhending av gammelt utstyr Omforent konfigurasjon Opplæringsplan Totale kostnader for implementering hos den aktuelle virksomhet/enhet (det skal tydelig fremgå hva som er knyttet til konfigurasjon/implementering og hva som er utstyr) Tids- og aktivitetsplan Implementeringsplanen skal godkjennes av IT-sjef og den enkelte virksomhet/enhetsleder før implementeringsarbeidet påbegynnes. 74. Krav til testplan med tilhørende testdokument Det skal som en del av prosjektet, utarbeides en testplan og et testdokument for testing av løsningen. Leverandøren skal fremlegge disse for godkjenning av AFK, i god tid før testing starter. Etter en prøvedriftsfase på tre måneder skal leverandøren ta initiativ til å gjennomføre en formell test av løsningen. Følgende skal testes: Alle telefoner som er tilbudt. Det kreves en samtalekvalitet tilsvarende MOS 4. (Med G.711, for GSM kreves MOS 2,8). De skal være koblet direkte på svitsjen som selve løsningen er tilkoblet. All funksjonalitet som angitt i denne kravspesifikasjonen. AFK skal godkjenne alle punkter i testdokumentet, før prøvedriftsfasen regnes som avsluttet og leverandøren kan starte migreringsfasen. Dersom AFK mener at det foreligger mangler av en mindre karakter, kan AFK likevel godkjenne oppstart av migreringsfasen. Testing skal også skje rutinemessig ved migrering av virksomhet/enhetene. Dersom samtalekvalitet eller tjenester ute hos en virksomhet/enhet ikke er tilfredsstillende i henhold til til kravene i denne kravspesifikasjonen, skal leverandøren etter samråd med AFKs sentrale IT-enhet starte feilsøking og foreslå tiltak. Arbeid med slik feilsøking og gjennomføring av tiltak er ikke en del av denne avtalen, og skal ikke påbegynnes før etter nærmere avtale med Sentral IT. 33

34 75. Krav til godkjenning av de enkelte installasjonene ved hver virksomhet/enhet For hver virksomhet/enhet skal det foretas en gjennomgang av at anlegget virker i henhold til virksomhet/enhetens ønsker, dog innenfor de rammer gitt i denne kravspesifikasjonen. Det skal utarbeides et enkelt overtagelsesdokument som skal godkjennes av AFK, representert ved Sentral IT og en representant for virksomhet/enheten. Ved signering av overtagelsesdokumentet regnes leveransen som avsluttet og videre ansvar for installasjonen overtas av driftsleverandøren. 76. Krav til opplæring av superbrukere Det skal utvikles og holdes inntil 10 kurs for superbrukere i sentraladministrasjonens lokaler (Schweigaards gate, Galleriet, Oslo). Kursets varighet skal være minimum 3 timer. Kursene annonseres i AFKs eget kursprogram. 77. Krav til opplæring av ekspedienter Som en del av installasjonen ved hver virksomhet/enhet, skal det gis opplæring i bruken av sentralbordet. Varighet: 4 timer, spredt over minimum to dager. 78. Krav til opplæring i administrasjon av systemet Inntil fem personer skal gis samlet opplæring i bruken av administrasjonsverktøyet for administrasjon av systemet. Varighet: En dag. 79. Krav til nettbutikk Tilbyderen skal ha en nettbutikk som autoriserte AFK-ansatte kan logge seg på og bestille abonnentutstyr som i denne avtalen er tilbudt. Elektronisk bestillingssystem skal som et minimum inneholde følgende funksjonalitet: Innlogging med valgfritt navn og passord Oversiktlig bestillingsliste, med mulighet for avkryssing av ønskede produkter Visuelt bilde av det enkelte produkt Beskrivende tekst på norsk, samt ytterligere produktinfo på engelsk, samt lenke til produsentens produktside Handlekurv med oppdateringsfunksjon og mulighet for å legge ting klare for senere, med fullføring ved midlertidig avbrudd i bestilling. Kundeservice som kan overta og hente opp ordre Oversikt over ordre, tidligere ordre og restordre. Det skal også være mulig å hente statistikk, samt gjenbruk av tidligere ordre hvor man kun oppdaterer antall produkter som ønskes kjøpt, uten å måtte legge inn all informasjon på nytt ved hver innlogging på nettbutikken Se egne priser Leverandøren skal legge inn personene som skal benytte nettbutikken. AFK fremskaffer liste over aktuelle personer (ca to personer pr. virksomhet/enhet). Det skal være en hastighet på bestillingssystemet, som medfører en positiv brukerrespons, slik at denne bestillingsmetoden foretrekkes fremfor telefon, faks og e-post. Elektronisk bestillingssystemet må ikke sette begrensninger eller kostnader 34

35 for bruker av løsningen. Når AFK har behov for opplæring vedrørende bestillingssystemet, skal leverandøren forestå opplæring hos den enkelte virksomhet/enhet kostnadsfritt. Beskriv dette nærmere, og legg ved skisser/skjermdump av nettbutikkløsning. Krav vedrørende dokumentasjon 80. Krav til systemdokumentasjon Systemdokumentasjonen skal beskrive løsningen i detalj også all konfigurering. Systemdokumentasjon skal være så detaljert at kvalifisert personell gjennom å lese denne skal forstå løsningens oppbygging og kunne starte feilsøking, endring eller utvidelser av løsningen. Dersom det oppstår en uenighet i detaljeringsnivået mellom leverandør og AFK, skal firma IP Tjenester benyttes for å avgjøre om dokumentasjonen er tilstrekkelig eller ikke. Kostnaden til dette dekkes av leverandør. 81. Krav til administratordokumentasjon Dokumentasjon til bruk for den som er administrator av systemet. Det er tilstrekkelig med elektronisk dokumentasjon i selve løsningen (forklarende tekst til felter, menyer etc.) for at systemadministrator skal kunne bruke administratorverktøyet (ref. nummer 38). 82. Krav til brukerdokumentasjon Det skal leveres brukerdokumentasjonen til hver abonnent og for enkelte type abonnentutstyr standard telefon, utvidet telefon, softphone, sentralbordapparat og det PC-baserte sentralbordet. Dokumentasjonen skal være på norsk, og skal leveres på papir og på elektronisk, redigerbart format (OpenDocument- eller DOCX-formatet). Dokumentasjonen skal produseres løpende gjennom prosjektperioden, for å kunne fange opp endringer i funksjonaliteten underveis. Dokumentasjon skal være relatert til løsningen. Det betyr at klientspesifikk funksjonalitet, som kommer i konflikt med funksjonalitet som ligger i selve løsningen, ikke må fremkomme i dokumentasjonen. Som et minimum skal brukerdokumentasjonen inkludere følgende: Hvordan man svarer en samtale (også hvis man sitter opptatt i en samtale) Hvordan man setter over en samtale Hvordan man parkerer en samtale Hvordan man gjør et spørreanrop Hvordan man ringer ut Hvordan man legger inn private kortnummer (som ligger lokalt lagret i den enkeltes telefon) Hvordan man henter fram nummer/navn i felles telefonliste Hvordan man fraværsmarkerer seg ( ikke tilstede /direkte viderekobling) Hvordan man kobler opp en konferanse 35

36 Hvordan man kommer til og benytter administrasjonssiden Krav vedrørende lover og forskrifter 83. Krav i forhold til lover og forskrifter Norske lover og forskrifter som blir berørt av denne løsningen skal være ivaretatt. Tilbyder skal blant annet beskrive hvordan dette er ivaretatt i forholdet til personopplysningsloven (blant annet i forhold til nummer 17), og Post- og Teletilsynets forskrifter til teleanlegg (blant annet i forhold til nummer 4, 11 (særlig vedr Partial rerouting «hairpinning»), 12 (nødnummerruting) og nummer 20 (ENUM)). 4.5 Opsjoner på tilleggsytelser som tilbyder skal kunne levere MERK: Tilbyder skal kunne levere og prise (se tilbudsskjema del 4) ytelsene det er snakk om her. Se ellers punkt 3.13 om tildelingskriterier. Beskrivelse av ytelse 1. Drifts-/support-/vedlikeholdsavtale AFK skal ha rett til å sette ut driften av løsningen til den valgte leverandøren. Med en drift- /support-/vedlikeholdsavtale ønsker AFK å overføre det totale driftsansvaret for løsningen til tilbyderen. Dette driftsansvaret skal også omfatte det utstyret som er levert av 3. part, slik som for eksempel SIP-trunkene, maskinvaren og nettverksutstyret. Dog skal teknisk drift og maskinvareservice utføres av AFK eller andre av AFKs partnere. Avtalen skal som et minimum inkludere følgende: Daglig overvåking av løsningen, inkl. «morgensjekk» (som inkluderer statussjekk av vesentlige komponenter, samt kontroll av at backup er kjørt. Kjøring av backup er AFKs ansvar). Tilbyderen må sørge for å installere nødvendige overvåkingsverktøy. Løpende oppdatering av løsningen, inklusive alle underliggende komponenter. 2. linje support for administrator og AFKs IKT-brukerstøtte Administrasjon/vedlikehold av de delene av løsningen som ikke kan utføres gjennom administrasjonsverktøyet. Preventivt vedlikehold (plan for vedlikehold) Foreslå og gjennomføre oppgradering av løsningen, inklusive den underliggende programvaren, linjer (SIP-trunkene) og maskinvaren. Feilretting. Dersom administrator ikke kan løse en feil gjennom administratorverktøyet, skal feil meldes til driftsleverandøren, som starter feilretting i henhold til følgende responstider: Kategori 1 feil: 1 time. Kategori 2 feil: 4 timer. Kategori 3 feil: 8 timer. Kategori 4 feil: Innen 5 virkedager. 36

37 Kategori 1 feil: Feil hvor hele eller deler av lokal installasjon er ute av drift. «Ute av drift» defineres som når flere enn halvparten av abonnentene ikke får ringt internt eller eksternt og ingen får ringt abonnentene. Feil som gjør at ingen får ringt virksomhet/enhetens hovednummer, og sentralbordet får ikke satt over samtaler, heller ikke med et fysisk apparat (biapparat). Kategori 2 feil: Feil hvor færre enn halvparten av abonnentene får ringt ut, internt og eksternt, og ingen får ringt de samme abonnentene. Feil hvor helt sentrale tjenester ikke fungerer slik de skal. Dette gjelder overføring av samtaler, samtlige køer, viderekoblinger, «click-to-call» og sentral funksjonalitet knyttet til sentralbordet som oppslag i katalog og sette over samtaler. Kategori 3 feil: Feil ved færre enn to abonnenter (ref. ovenstående). Feil hvor en eller flere tjenester ikke fungerer som de skal (for eksempel talesvar, talemeldinger, viderekoblinger, innhent anrop). Feil ved telefoner/linjer knyttet til alarmer, heis(er), telefakser o.a. analogt utstyr. Andre feil ved sentralbordet. Feil ved administrasjonsverktøyet. Kategori 4 feil: Feil som ikke er av vesentlig betydning for virksomhet/enhetens daglige drift. Dette gjelder feil ved innhentgrupper, nattstilling, krisemodus, enkeltapparater som ikke er knyttet til en eller flere abonnenter (for eksempel i møte- /klasserom).. Feil ved brukernes administrasjonsside, inn-/utlogging av køer. Under denne kategorien kommer også ønsker om endringer i systemet som er av en slik art at det må gjøres av driftsleverandøren (det kan ikke gjøres av administrator via administrasjonsverktøyet). Feil skal kunne meldes når som helst på døgnet, men responstiden regnes innenfor virkedager og normal arbeidstid (kl 8-16). Eksempel: En kategori 2 feil meldes lørdag kl 12. Arbeid påbegynnes senest påfølgende mandag kl 12. Feil skal kunne meldes av AFKs systemansvarlige, samt utvalgte personer i sentral IT. Stå som ansvarlig ovenfor andre involverte leverandører, for eksempel leverandørene av SIP-trunkene, maskinvaren og nettverksutstyret). Statens standardavtale for vedlikehold og service i mindre omfang av IT-utstyr og programmer, «Den lille vedlikeholdsavtalen (SSA-V lille)», skal benyttes for denne kontrakten innenfor rammeavtalen. Denne lastes ned fra Tilbyderen bes sette seg inn i denne og gi sitt tilbud i form av ferdig utfylte bilag. Tilbudet skal inneholde en skisse og beskrivelse av hvordan overvåkingen av løsningen kan foregå, og hvordan rutinen for melding og oppfølging av feil kan være. Arbeid knyttet til drift, support og vedlikehold av løsningen vil øke gradvis gjennom avtaleperioden. Dette må være ivaretatt i tilbyders forslag til drift-/support- /vedlikeholdsavtale. 2. Administrasjon av løsningen Det kan være aktuelt å sette ut administrasjon av løsningen. En slik tjeneste går ut på å administrere all funksjonalitet som er tilgjengelig gjennom administrasjonsverktøyet. Dette inkluderer også å være brukerstøtte for AFKs egen IT brukerstøttetjeneste (Abonnenter melder feil til AFKs IT-brukerstøtte. IT-brukerstøtte melder videre til administrator av telefoniløsningen). 37

38 Følgende responstider skal gjelde fra en henvendelse fra IT-brukerstøtte kommer, til administrator begynner å jobbe med saken.: Kategori 1 henvendelse: 1 time Kategori 2 henvendelse: 4 timer Kategori 3 henvendelse: 8 timer Kategori 4 henvendelse: Innen 5 virkedager Kategori 1 henvendelse: Håndtering av alvorlige feil. Kan feilen rettes gjennom administrasjonsverktøyet gjør administrator dette. Dersom det ikke kan rettes gjennom administratorverkøyet, meldes feilen til driftsleverandør. Feil som faller under denne kategorien er feil hvor brukeren ikke får ringt ut eller mottatt samtaler. Kategori 2 henvendelse: Håndtering av mindre alvorlige feil. Dette er feil i forbindelse med funksjonalitet i løsningen, men hvor abonnenten kan ringe ut og motta samtaler på eget nummer. Det kan være feil i forbindelse med en kø, talesvar, viderekoblinger, sperringer, talemeldinger eller brukernes administrasjonsside. Kategori 3 henvendelse: Opprette nye abonnenter og endre eksisterende konfigurasjon til en abonnent. Administrator skal kunne endre en abonnents konfigurasjon. Det kan være å legge en abonnent inn som agent til en kø, inn i en ny sperreliste, innhentgruppe og lignende. Kategori 4 henvendelse: Henvendelser som går på helt ny funksjonalitet som krever involvering av leverandøren. Ved slike henvendelser skal administrator undersøke om den ønskede funksjonen kan dekkes med den funksjonaliteten som systemet har. Dersom abonnenten ikke finner dette tilfredsstillende, skal administrator kontakte leverandøren av løsningen og diskuterer hvordan den ønskede funksjonaliteten kan utvikles. Det er vanskelig å anslå hvor mye arbeid det vil være å administrere systemet, men AFKs virksomhet/enheter er forholdsvis statiske, slik at det er grunn til å tro at når basisinstallasjonen er gjort ute ved en av virksomhet/enhetene, er det lite behov for store og hyppige endringer av konfigurasjonen. De siste årene har det vært mellom to og tre hundre nyansatte pr år. Dette gikk noe ned i 2008 og Det legges ikke opp til at administrator skal drive opplæring av nye eller eksisterende abonnenter. Dette er en oppgave som skal utføres av superbrukerne. Dog bør det påregnes noe support til superbrukerne i form av telefonstøtte og 1-2 halvdags samlinger pr år. Arbeid knyttet til administrasjon av løsningen vil øke gradvis gjennom avtaleperioden. Dette må være ivaretatt i tilbyderens forslag til avtale om administrasjon av løsningen. Dersom tilbyderen velger å tilby et forslag til drift-/support-/vedlikeholdsavtale, kan gjerne administrasjon av løsningen inkluderes i denne avtalen. Prisen for denne tjenesten skal fremgå tydelig. 38

39 4.6 Opsjoner på andre tilleggsytelser MERK: Det henvises til tilbudsskjem del 5 for prising av ytelsene her. Prisene på ytelsene vil ikke bli lagt vekt på vurderingen av tildelingskriteriet Pris, men tilbyders evne til å levere ytelsene vil bli lagt vekt på vurderingen av tildelingskriteriet Leveringsevne. Tilbyder bes om å krysse av ytelsene som kan oppfylles eller leveres. Poengscoren angitt i kolonnen Poeng oppnås hvis ytelsen er krysset av. Det gis null (0) poeng ellers.. Se punkt 3.13 om tildelingskriterier. Beskrivelse av ytelse 1. Krav til utvidet krisemodus Ved å sette sentralbordet i krisemodus, innkobles et på forhånd gitt antall apparater (internabonnenter) som agenter i sentralbordkøen (ref nummer 40, krisemodus). Det er ønskelig at sentralbordet i tillegg til den ene kriseknappen, har en ekstra kriseknapp, hvor også agenter utenfor egen virksomhet/enhet kan kobles inn. Apparater som er satt i «ikke-forstyrr» eller er direkte viderekoblet, ønskes unntatt fra innmeldelsen i «krisekøen». 2. Sende e-post fra sentralbordapplikasjonen I utgangspunktet har ekspedient tilgang til AFKs e-postsystem via en egen applikasjon (MS Outlook). Det er ønskelig med et felt i sentralbordapplikasjonen for å sende beskjeder som e-post. Løsningen må ikke benytte seg av noen eksterne e-posttjenester. All e-postkommunikasjon skal gå internt innenfor fylkeskommunens nett. Funksjonalitet tilsvarende for mobiltelefonmeldinger (se nummer 52; meldingssystem). 3. Flytting av svarfunksjonen Det er ønskelig at ekspedientfunksjonen skal kunne flyttes (viderekobles), slik at en annen ekspedient ved en annen virksomhet/enhet kan overta svarfunksjonen. Dette skal enten skje ved at ekspedient trykker/klikker på en knapp, eller automatisk før og/eller etter et visst klokkeslett. Sentralbordapplikasjonen må ha visning som indikerer at svarfunksjonen er flyttet, og det må også ha visning av køen til de(n) andre virksomhet/enheten(e), samt tydelig markering av hva ekspedient skal svare (virksomhet/enhetens navn) når samtaler besvares. Samtlige inngående samtaler, fra de forskjellige køene, skal ha rettferdig køfordeling, men bør kunne konfigureres via administrasjonsverktøyet. Kryss av for hver ytelse som kan oppfylles eller leveres Poeng

40 4. Lokasjonsuavhengig sentralbordapplikasjon Det er ikke stilt spesifikke krav til teknologien i den PC-baserte sentralbordapplikasjonen. Det er for øvrig ønskelig at sentralbordapplikasjonen er web-basert, slik at den enkelt kan startes opp med en hvilken som helst nettleser med et hvilket som helst operativsystem i fylkeskommunens nett. Det er ønskelig at den i så måte støtter åpne standarder og at det ikke benyttes proprietær nettleser- eller operativsystemavhengig teknologi. Sikkerheten ved en slik løsning må beskrives nøye. 5. Hodesett Det er en del hodesett i bruk, særlig i sentraladministrasjonen i Schweigaards gate, Galleriet. Disse er for det meste av typen: 2 Genicom, enten trådbundet (et sett med kabler og vender, RJ11-plugger) eller trådløst. Plantronics, trådbundet med 2,5 mm jack-plugg (benyttes bl.a. sammen dagens DECT-telefoner (Alcatel)). 5 Det er et ønske at flest mulig av disse hodesettene kan gjenbrukes. Tilbyderen må påse at de hodesett som AFK har, og som er av den typen hvor abonnenten kan ta og legge på en samtale, også virker i den nye løsningen (sammen med de tilbudte apparater). 6. Alternative apparater Det er ønskelig at det tilbys flere typer apparater, fra flere produsenter (ref. krav 54 hvor det er et krav om abonnentutstyr fra minimum to forskjellige produsenter) og gjerne apparater fra flere enn de forespurte produsenter. Dersom det tilbys flere typer telefoner, så skal det samtidig tilbys automatisk provisjonering av disse. 7. Varsling til køagenter når køen når terskelverdier Det er ønskelig at hver enkelt agent får et varsel når inngående kø når opp til, eller overstiger, gitte terskelverdier. Dette kan for eksempel være når køen blir større enn ett gitt antall eller når gjennomsnittlig ventetid i køen er større enn gitt antall sekunder. Når disse terskelverdiene inntreffer, skal kø-vinduet (ref nummer 39) «poppe» opp på skjermen (à la slik varsling av MS Outloook e-post eller MSNmeldinger ofte skjer). Administrator setter disse terskelverktøyene for den enkelte kø i administratorverktøyet. 8. Integrasjon mot Vigo VIGO er et system for inntak til videregående opplæring (se For Vigo kan vi tenke oss at elevene ringer et nummer, taster inn sin PIN-kode og får opplest status på sin søknad om opptak Vi oppfordrer tilbyderne til å kontakte leverandøren av VIGO og i tilbudet beskrive hvordan en integrasjon mot systemet kan gjøres. 9. Integrasjon mot IST Novachem (timeplansystem) Det er ønskelig å integrere sentralbordapplikasjonen inn mot 40

41 Novaschem, slik at ekspedienter ved skolene raskt kan se lærernes timeplaner. Vi oppfordrer tilbyderne til å kontakte leverandøren av VIGO og i tilbudet beskrive hvordan en integrasjon mot systemet kan gjøres. 10. Støtte for IAX2 IAX2 foreligger som en åpen spesifikasjon, RFC5456 ( IAX gir en del fordeler i et sikkerhetsmessig perspektiv. Det kan være at denne protokollen vinner fram både hos telekomprodusentene og telekomoperatørene. Derfor ser vi det som en fordel at denne protokollen støttes. Dersom det er noen kostnad for å støtte IAX, skal dette fremgå i tilbudsskjemaet. 11. Visning av status på mobiltelefoner i sentralbordapplikasjonen Det er ønskelig at også mobiltelefonenes status vises i statusoversikten til sentralbordapplikasjonen, slik at ekspedient ser om mobiltelefonen er opptatt i samtale eller ikke. 12. Utvidet statistikk, mottak av samtaledata fra leverandøren av SIP-trunken Det er ønskelig at systemet skal kunne motta samtaledata fra SIPtrunkleverandøren og sammenstille disse opp mot de data telefoniløsningen gir. Systemet skal kunne varsle administrator dersom det er avvik mellom de samtaledata SIP-trunkleverandøren gir og de data telefoniløsningen gir Prisinformasjon fra SIP-trunkleverandøren skal danne grunnlag for å ta ut økonomiske oversikter (statistikker). Disse skal kunne benyttes for å kontrollere faktura fra SIP-trunkleverandøren. Det må påregnes et visst samarbeide med leverandøren av SIP-trunken for å få koordinert dette. Tilbyderen bes beskrive hvordan dette løses og gi en pris for dette. 13. Telefonkonferanse automatisk generering av PIN-koder Det er ønskelig at systemet automatisk skal generere en PIN-kode når en abonnent booker et konferanserom. Videre ønskes det at PIN-koden skal sendes den som reserverer konferanserommet pr e-post. Denne bør inneholde informasjon om det å være møteleder. I tillegg er det ønskelig at det sendes en e-post som inneholder påloggingsinfo for møtedeltagerne, og som møteleder kan videresende til møtedeltagerne. Selve teksten lages i samarbeid med AFK. 14. Integrasjon med AD for autentisering Det er ønskelig at løsningen benytter AD for autentisering av abonnenter, når abonnent logger seg på sin egen administrasjonsside og softphone. 15. Bryte inn i en samtale (for ekspedient) Det er ønskelig at ekspedient skal kunne bryte inn i en eksisterende samtale fra det PC-baserte sentralbordet. Dersom en ekspedient gjør

42 dette, skal dette markeres for de samtalende parter med et gjentagende lydsignal. 16. Talesvar i en kø hvor innringer gis valg til å legge igjen en beskjed I nummer 27 (køer), er det et krav at anrop som går til en kø, alltid skal stå i køen. De skal IKKE viderekobles til for eksempel sentralbordet. Det er ønskelig at en innringer som har stått lenge i en kø, skal bli presentert et talesvar, hvor han/hun får anledning til å legge igjen en beskjed, eksempelvis: «Det er fortsatt stor trafikk, du er nummer x i køen. Vi synes du har ventet lenge nok og gir deg nå muligheten til å legge igjen en beskjed til oss. Vil du det, tast 1. Vil du fortsatt vente, så hold linjen». Dette skal kunne administreres pr kø via administrasjonsverktøyet. Meldingen som innringer legger igjen skal bli rutet til første ledige agent. Denne får beskjed om at det er kommet en talemelding til <køens navn>, og at han/hun kan taste 1 for å lytte til meldingen eller taste 2 for å sende den til en på forhånd definert e-postadresse. I administrasjonsverktøyet må man kunne velge hvilken e-post slike meldinger skal sendes til. Et av valgene skal være «til agentens egen e- post». 17. Talesvar i kø, hvor innringer gis valg om å bli ringt tilbake Pga usikkerheten vedr. kostnadene AFK pådrar seg ved å ringe opp igjen, og ressursene det kreves, så er dette trolig ikke veldig aktuelt. Men er dette enkelt å gi tilbud på, så oppfordrer vi tilbyderen til å gjøre det. 18. Video Det er et ønske at løsningen også støtter video, en-til-en, og videokonferanse. Beskriv dette nærmere. Beskriv hvorvidt de tilbudte softphones støtter video. Gi eventuelt tilbud på andre softphones, og fysiske telefoner med video-mulighet. Antall: 100 Softphones og 20 fysiske apparater av middels kvalitet (med fargeskjerm i størrelsen 3-7 tommer) 19. Opplæring i drift av systemet Dersom AFK ikke ønsker at tilbyder skal stå for driften av systemet, betyr det at AFK vil utføre dette selv. Det bes om tilbud på opplæring i drift- og vedlikehold av løsningen for inntil fem personer, i fem dager. Beskriv kort innholdet i et slikt opplæringstilbud. 20. Andel av fri programvare som inngår i løsningen Offentlig sektor i Norge er av sentrale myndigheter oppfordret til i større grad å velge løsninger som er basert på fri programvare. Beskriv hvilke deler av løsningen som benytter fri programvare og hvilke deler som ikke benytter fri programvare For de delene av løsningen som er basert på fri programvare, skal denne programvarens navn, versjonsnummer og lisensbetingelser 42

43 oppgis. Tilbyderen skal påse at det ikke benyttes fri programvare med lisensbetingelser som er uforenlige med kravene til leveransen eller som er uforenlige med lisensbetingelsene som gjelder for annen programvare som inngår i leveransen. 5 Tilbyderen skal bare benytte fri programvare som etter en forsvarlig vurdering fra tilbyders side ikke kommer i konflikt med tredjeparts rettigheter og som tilbys under alminnelig anerkjente fri programvarelisenser. Det gis poeng dersom mer en ca 2/3 av løsningen er basert på fri programvare. 21. Utvidet redundans For å øke oppetiden i løsningen, ønskes økt redundans. Vi ønsker at den ene installasjonen installeres fysisk på en annen lokasjon noen kilometer fra Schweigaards gate (Galleriet, Oslo). Dette kan f.eks. være ved en av AFKs skoler, eller et annet driftsmiljø hvor det er enkelt å føre fram en SIP-trunk for eksempel via Hafslund sitt nett. I en slik løsning er det ikke sikkert at lastbalanseringen skal være 50/50 (fordi den ene SIP-trunken kanskje blir noe dyrere enn den andre). Vi ber om en skisse og pris på en slik alternativ løsning. 22. Stillerom Et av de største ønskene til lærerne er å kunne sitte uforstyrret og føre en konfidensiell samtale. Ikke alle skoler har gode løsninger for dette. Derfor ønskes tilbud på stillerom i følgende størrelser: Lite: Plass til en person som står Mellomstort. Plass til en person som kan sitte og med et arbeidsbord. Stort: Plass til 3-4 personer I tilbudsskjemaet skal det angis pris for fire stk av hver av de ovennevnte størrelsene. 23. Prekonfigurasjon og tilpasninger av softphone-ene Det er ønskelig at softphone-ene kan prekonfigureres og tilpasses (for eksempel legge inn AFKs kommunevåpen), slik at AFKs abonnenter selv laster ned programvaren, legger inn eventuelt lisenskode og logger seg på, og telefonen er klar til bruk. Tilbyderen bes gi tilbud på ovenstående og beskrive andre endringer/tilpasninger som kan gjøres. For eksempel om konfigureringen brukerne gjør gjennom sin egen web-baserte administrasjonsside også, eller utelukkende, gjøres i et menyvalg i SoftPhon-en. 24. Integrasjon med Telefonkatalogen bedrift fra Eniro AFK abonnerer i dag på web-tjenesten Telefonkatalogen bedrift fra Eniro. Denne er integrert i intranettet til AFK, og abonnenten kan søke etter både interne og eksterne personer og sende sms til dem som har mobiltelefon. Dette gjøres ved at abonnenten holder muspekeren over nummeret. En liten meny dukker opp med valget «Send sms». Vi ønsker at det i denne menyen skal komme opp et valg til: «Ring». Det er mulig dette dekkes av «click-to-call»-funksjonaliteten (nummer

44 14/15), men vi tror dette henger sammen med funksjonalitet på selve web-siden til Eniro og oppfordrer tilbyder til å kontakte Eniro for å innfri dette ønsket i henhold til ovenstående beskrivelse. 25. Interne abonnenter skal få opptatt når de ringer til en annen intern abonnent som er opptatt i en samtale Det er ønskelig at man i administrasjonsverktøyet kan sette hvorvidt interne abonnenter skal få opptatt signal når de ringer en intern abonnent som er opptatt i en samtale. Dette får de i utgangspunktet kun dersom abonnenten det ringes til selv har valgt og kun ha en linje og at det skal gis opptattsignal når han/hun er opptatt. Det er ønskelig at de uansett om de har en eller to linjer, skal få opptattsignal. 5 Mange mener at det er mer informativt å gi et opptattsignal, og heller lære seg å bruke ventekoblingen (se nummer 24), enn at det ringer x antall ganger, før talesvar eller viderekobling inntreffer. Dette skal kunne velges pr virksomhet/enhet, eventuelt pr abonnent. 26. Videresending av talemeldinger Det er ønskelig at en abonnent skal kunne videresende en talemelding som han har lyttet på sitt apparat til sin innboks i e-postprogrammet. 27. RJ11-USB-adapter for gjenbruk av håndsett Adapter som konverterer de analoge lydsignalene fra et klassisk håndsett til digitale, slik at et eksisterende håndsett kan gjenbrukes. Dersom et slikt adapter kan fremskaffes, kan det forventes et stort volum. Eventuelle priser skal oppgis pr 1000 enheter. 28. Krav til utvidet konferanse-/fjernundervisningsmodul Telefoniplattformens konferansefunksjonalitet skal kunne utvides til å bli en løsning for mer omfattende konferanser og nettbasert undervisning (fjernundervisning). I et web-basert grensesnitt skal møtelederen (for eksempel en lærer) kunne vise en ferdig presentasjon, samtidig med sitt eget ansikt. Alle deltagerne som er påkoblet, skal kunne delta i diskusjonen, stille spørsmål o.a Møtelederen/læreren skal kunne veksle mellom å vise en ferdig presentasjon, og skrivebordet på sin egen PC (for å kunne vise andre programmer eller en nettside) Et eksempel på en løsning med slik funksjonalitet er friprogramvareprosjektet BigBlueButton (bigbluebotton.org). AFK benytter i dag e-læringsplattformen It s learning. Vi oppfordrer tilbydere til å undersøke med It s learning hvilke planer de har for slik funksjonalitet og om det eventuelt er grunnlag for et samarbeid for å få til en felles løsning (Det er ikke ønskelig med en type løsning knyttet til telefonisystemet; og en annen tilsvarende løsning i It s learning) 44

45 29. Krav til opptak av leksjoner/konferanser I forbindelse med det som er beskrevet i krav nr 30, skal konferansen eller leksjonen kunne tas opp og gjøres tilgjengelig på et dedikert nettsted. På denne måten kan for eksempel elever følge en forelesning i ettertid Funksjonalitet som ikke er etterspurt Utviklingen innenfor telefoniområdet (inkl. «Unified communication») skjer med høyt tempo. Det er krevende å følge med på denne utviklingen. Det betyr at vi muligens ikke er klar over en del funksjonalitet som finnes, og som kan være nyttig for våre virksomheter/enheter. Vi ber derfor tilbyder tenke nøye igjennom arbeidssituasjonen til våre største brukergrupper lærere, tannleger/tannpleiere og saksbehandlere i sentraladministrasjonen. Vi oppfordrer tilbyder til å komme opp med forslag til gode, nyttige og brukervennlige løsninger som passer for våre største brukergrupper. 4.8 Forholdet til eldre løsninger og annen trafikk enn tale Det er ca 80 analoge linjer i drift i AFK. De fleste av disse antas ikke å være tilknyttet noen hussentral. I utgangspunktet skal enheter som i dag ikke er koblet opp mot eksisterende hussentral, heller ikke knyttes opp mot ny løsning. Dette gjelder bl.a. videokonferanseutstyr, frankeringsmaskin, alarmlinjer (Altel), beredskapstelefon (som ofte er en dedikert analog linje). Rammeavtalen skal inkludere en kartlegging av slikt utstyr, mens eventuelt arbeid knyttet til slikt utstyr ikke skal inkluderes. Eventuelt arbeid knyttet til slikt utstyr kommer som tillegg, og skal godkjennes på forhånd av AFK. Det skal i tilbudsskjemaet gis tilbud på timepriser for denne type arbeid. Telefoner i eventuelle heiser skal kobles opp mot ny løsning, med samme funksjonalitet som de har pr i dag, vanligvis en hotline-funksjon. Dvs. at man ved å trykke på alarm-knapp i heisen (=samme som å løfte av røret), automatisk ringer til et forhåndsprogrammert nummer (typisk til en manuelt betjent alarmsentral). 45

46 VEDLEGG 4: Poengskala for evaluering av løsningsbeskrivelse knyttet opp til krav nummer 1 og 11 i punkt 4.4 Merk: Samtlige av punktene må være oppfylt for at tilbyder skal få angitt poengsum. 5 poeng Tilbyder viser gjennom sin løsningsbeskrivelse og medfølgende skisser at han har forstått AFKs behov og samtlige absolutte krav, spesielt kravene innenfor kapasitet, funksjonalitet, ytelse, sikkerhet, hva som ligger i tilbyders standardløsning og hva som må tilpasses/utvikles særskilt for AFK. Løsningsbeskrivelsen virker særdeles fornuftig, med en svært fornuftig fordeling mellom bruk av virtuelle og fysiske servere. Samtlige komponenter og deres funksjon er svært godt beskrevet. Dataflyten og ringeprosessen (hvordan oppkobling og gjennomføring av en samtale utføres) er svært godt dokumentert og forståelig. Databasens oppbygging er svært godt dokumentert og forståelig. Løsningsbesvarelsen består av 15 sider eller mer, hvorav minst 10 sider utgjør tekst. Løsningsbeskrivelsen, både innholdsmessig og språklig, bærer preg av å være lagd spesifikt for AFK, og ikke basert på standard beskrivelser fra en eller flere produsenter. Løsningsbeskrivelsen gir klare råd på viktige spørsmål vedr. nummerplan, sikkerhet, lastbalansering, redundans, mm. Tilbyder skisserer flere alternativer på hvordan en konkret detalj kan løses, og redegjør for fordelene og ulempene ved de forskjellige alternativene. Tilbyder tilkjennegir tydelig hvilket alternativ som er valgt som grunnlag for prisutregningen. De faglige utrykkene som er benyttet er identiske med de som er benyttet i konkurransegrunnlaget. Skisser og skjermdump virker gjennomtenkte og tiltalende, med gode forklarende tekster til. Språket er utelukkende på norsk og fremstår tydelig og klart, med lite rom for misforståelser. Der det er benyttet engelske fagord, er disse forklart. 46

47 4 poeng Tilbyder viser gjennom sin løsningsbeskrivelse og medfølgende skisser at han har forstått AFKs behov og samtlige absolutte krav, spesielt kravene innenfor kapasitet, funksjonalitet, ytelse, sikkerhet, men noe uklart hva som ligger i tilbyders standardløsning og hva som må tilpasses/utvikles særskilt for AFK. Løsningsbeskrivelsen virker fornuftig, med en fornuftig fordeling mellom bruk av virtuelle og fysiske servere. Samtlige komponenter og deres funksjon er godt beskrevet Dataflyten og ringeprosessen (hvordan oppkobling og gjennomføring av en samtale utføres) er godt dokumentert og forståelig. Databasens oppbygging er godt dokumentert og forståelig. Løsningsbesvarelsen består av 12 sider eller mer, hvorav minst 9 utgjør tekst. Løsningsbeskrivelsen, både innholdsmessig og språklig, bærer preg av å være lagd spesifikt for AFK, og ikke basert på standard beskrivelser fra en eller flere produsenter. Løsningsbeskrivelsen gir råd på viktige spørsmål vedr. nummerplan, sikkerhet, lastbalansering, redundans, mm. Tilbyder skisserer flere alternativer på hvordan en konkret detalj kan løses, og redegjør for fordelene og ulempene ved de forskjellige alternativene. Tilbyder tilkjennegir hvilket alternativ som er valgt som grunnlag for prisutregningen. De faglige utrykkene som er benyttet er identiske med de som er benyttet i konkurransegrunnlaget. Skisser og skjermdump virker gjennomtenkte og tiltalende, med gode forklarende tekster til. Språket er utelukkende på norsk og fremstår tydelig og klart. Der det er benyttet engelske fagord, er disse forklart. 3 poeng Tilbyder viser gjennom sin løsningsbeskrivelse og medfølgende skisser at han overordnet har forstått AFKs behov og samtlige absolutte krav, og spesielt noen av kravene innenfor kapasitet, funksjonalitet, ytelse, sikkerhet, men noe uklart hva som ligger i tilbyders standardløsning og hva som må tilpasses/utvikles særskilt for AFK. Løsningsbeskrivelsen virker fornuftig, men med en noe uklar fordeling mellom bruk av virtuelle og fysiske servere. 47

48 Samtlige komponenter og deres funksjon er forholdsvis godt beskrevet Dataflyten og ringeprosessen (hvordan oppkobling og gjennomføring av en samtale utføres) er dokumentert og forståelig. Databasens oppbygging er dokumentert og tildels forståelig. Løsningsbesvarelsen består av 10 sider eller mer, hvorav minst 8 utgjør tekst. Løsningsbeskrivelsen, både innholdsmessig og språklig, bærer preg av å være lagd spesifikt for AFK, men med et betydelig bidrag av standardtekster fra en eller flere produsenter. Løsningsbeskrivelsen gir råd på noen viktige spørsmål som for eksempel nummerplan, sikkerhet, lastbalansering, redundans, mm. Tilbyder skisserer ikke flere alternativer på hvordan en konkret detalj kan løses, og redegjør ikke for fordelene og ulempene ved de forskjellige alternativene. De faglige utrykkene som er benyttet er delvis identiske med de som er benyttet i konkurransegrunnlaget. Skisser og skjermdump virker ikke helt gjennomtenkte, er ikke tiltalende, og med mindre gode forklarende tekster til. Språket er utelukkende på norsk. Der det er benyttet engelske fagord, er disse stort sett forklart. 2 poeng Tilbyder viser gjennom sin løsningsbeskrivelse og medfølgende skisser at han knapt har forstått AFKs overordnede behov og kun få av de absolutte krav. Løsningsbeskrivelsen virker lite fornuftig, med en uklar fordeling mellom bruk av virtuelle og fysiske servere. Samtlige komponenter og deres funksjon er knapt beskrevet Dataflyten og ringeprosessen (hvordan oppkobling og gjennomføring av en samtale utføres) er knapt dokumentert og lite forståelig. Databasens oppbygging er knapt dokumentert og knapt forståelig. Løsningsbesvarelsen består av 8 sider eller mer, hvorav minst 7 sider utgjør tekst. Løsningsbeskrivelsen, både innholdsmessig og språklig, bærer preg av å være klipt sammen av standardtekster fra en eller flere produsenter. Løsningsbeskrivelsen gir ingen råd på viktige spørsmål som for eksempel nummerplan, sikkerhet, lastbalansering, redundans, mm. 48

49 Tilbyder skisserer ikke flere alternativer på hvordan en konkret detalj kan løses, og redegjør ikke for fordelene og ulempene ved de forskjellige alternativene. De faglige utrykkene som er benyttet er delvis identiske med de som er benyttet i konkurransegrunnlaget. Skisser og skjermdump virker lite gjennomtenkte, er ikke tiltalende, og med dårlige forklarende tekster til. Språket er stort sett på norsk. Det er benyttet en del engelske fagord, hvorav få av disse er forklart. 1 poeng: Tilbyder viser gjennom sin løsningsbeskrivelse og medfølgende skisser at han knapt med stor sannsynlighet ikke har forstått AFKs overordnede behov og kun få av de absolutte krav Løsningsbeskrivelsen virker svært lite fornuftig, med en merkelig fordeling mellom bruk av virtuelle og fysiske servere. Komponentene og deres funksjon er dårlig beskrevet. Dataflyten og ringeprosessen (hvordan oppkobling og gjennomføring av en samtale utføres) er dårlig dokumentert og svært lite forståelig. Databasens oppbygging er dårlig dokumentert og svært lite forståelig. Løsningsbesvarelsen består av 7 sider eller mer, hvorav minst 6 sider utgjør tekst. Løsningsbeskrivelsen, både innholdsmessig og språklig, bærer preg av å være klipt sammen av standardtekster fra en eller flere produsenter. Løsningsbeskrivelsen gir ingen råd på viktige spørsmål som for eksempel nummerplan, sikkerhet, lastbalansering, redundans, Tilbyder skisserer ikke flere alternativer på hvordan en konkret detalj kan løses, og redegjør ikke for fordelene og ulempene ved de forskjellige alternativene. De faglige utrykkene som er benyttet er ikke identiske med de som er benyttet i konkurransegrunnlaget. Skisser og skjermdump virker svært lite gjennomtenkte, er ikke tiltalende, og med elendige forklarende tekster til. Språket er på dårlig norsk. Det er benyttet en del engelske fagord, hvorav få er forklart. 49

50 0 poeng: Tilbyder viser gjennom sin løsningsbeskrivelse og medfølgende skisser at han med stor sannsynlighet ikke har forstått AFKs overordnede behov og kun få av de absolutte krav. Løsningsbeskrivelsen virker svært lite fornuftig, med en merkelig fordeling mellom bruk av virtuelle og fysiske servere. Komponentene og deres funksjon er ikke beskrevet Dataflyten og ringeprosessen (hvordan oppkobling og gjennomføring av en samtale utføres) er ikke dokumentert. Databasens oppbygging er ikke dokumentert Løsningsbesvarelsen består av 6 sider eller mer, hvorav minst 5 sider utgjør tekst (som er minimumskravet) Løsningsbeskrivelsen, både innholdsmessig og språklig, bærer preg av å være klipt sammen av standardtekster fra en eller flere produsenter. Løsningsbeskrivelsen gir ingen råd på viktige spørsmål som for eksempel nummerplan, sikkerhet, lastbalansering, redundans, Tilbyder skisserer ikke flere alternativer på hvordan en konkret detalj kan løses, og redegjør ikke for fordelene og ulempene ved de forskjellige alternativene. De faglige utrykkene som er benyttet er ikke identiske med de som er benyttet i konkurransegrunnlaget. Skisser og skjermdump virker svært lite gjennomtenkte, er ikke tiltalende, og med elendige forklarende tekster til. Språket er på dårlig norsk, iblandet engelsk. Det er benyttet en del engelske fagord, hvorav få er forklart. 50

51 VEDLEGG 6: Skisse på administrasjonsside for abonnent («Min side/min telefon») Fortsettelse neste side. 51

52 52