Kravspesifikasjon for Akershus fylkeskommunes ... - Bjørn Venn

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 1. 

3. 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

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 . 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 . 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: + 47 22 05 55 97 

Mobiltelefon: + 47 992 85 850 

E-post: bjorn.venn@akershus-fk.no 

2

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 

Planlegg- Test- og 

ingsfasenutprøvingsfasen Migreringsfasen 

3

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. 3.13. 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

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 3.13. 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. 

8 15 15 

Antall enheter – type tannklinikk og andre mindre enheter, 

med mindre enn 15 abonnenter, som med stor sannsynlighet 

vil benytte en utvidet fasttelefon som sentralbord. 

9 20 20 

Antall telefoner av enkleste type. 100 200 200 

Antall telefoner av utvidet type (”sekretærapparat”). 10 40 50 

Antall softphones inkl hodesett -, håndsett eller USBtelefon. 

700 1600 1600 

Volumangivelsene er kun retningsgivende og forplikter ikke AFK. 

5

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. 

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 

Kryss av for 

hvert 

kravnummer 

som er lest og 

forstått 

6

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 54 – 67. 

3. 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.711.1 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 3261. 

5. 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

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.711.1 

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

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. 

11.1 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

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 22 05 55 97 for fastnumre og 992 

85 850 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

”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 (www.vigo.no). 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. 


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

kompetanse tilbyder har på området. En oversikt over teknologien finnes her 

http://tools.ietf.org/wg/enum/ 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. 

24.1 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

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

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

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 epostprogrammet, 

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 55. 

29. 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». 


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

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 , 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 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. 


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

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 Anummer 

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

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 epostprogrammet, 

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

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

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

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 250-300 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. 

 

Ant. i kø: 

1 2 3 4 5 6 

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 

1 

1 

1 

2 

2 

21

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 56. 

42. Krav til PC-basert sentralbord (sentralbordapplikasjon) 

Skjermformatet skal være 16:9 (widescreen). 

22

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. 


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

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

� 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

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 2. 

55. 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

� 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

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 (300-3.400 Hz). For 

krav til gaffelfunksjonen: Se under ”Programvarebasert telefon (softphone)”. 

60. Krav til trådbasert USB håndsett med tastatur og gaffelfunksjon 

(”USB telefon”) 


softphone. Skal ha «bredbåndslyd» («wideband», 150-6.800 Hz). Standard 

USB-plugg. For krav til gaffelfunksjonen: Se under Programvarebasert 

telefon (softphone). 

61. Krav til trådløst håndsett med gaffelfunksjon 


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

� 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

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

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

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

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

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

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

� 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 


� 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

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 


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 www.difi.no. 

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

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 2009. 

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

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 


Kryss av for 

hver ytelse som 

kan oppfylles 

eller leveres 

Poeng 

39 

1 

5 

2

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: 

� 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)). 

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 

www.vigo.no) 

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 

2 

5 

2 

5 

3

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 (http://www.rfceditor.org/rfc/rfc5456.txt). 

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 

41 

5 

3 

4 

5 

3 

5 

3

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 

, 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 epost». 

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 

5 

1 

3 

5

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. 

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 

43 

5 

3 

3 

5 

5

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. 

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 

5 

4 

5 

5

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. 

4.7 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 

5

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

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 


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. 


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 


� 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

� Samtlige komponenter og deres funksjon er forholdsvis godt beskrevet 


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. 


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 


� 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 


utføres) er knapt dokumentert og lite forståelig. 

� Databasens oppbygging er knapt dokumentert og knapt forståelig. 


� 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



� De faglige utrykkene som er benyttet er delvis identiske med de som er benyttet i 


� 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. 


utføres) er dårlig dokumentert og svært lite forståelig. 

� Databasens oppbygging er dårlig dokumentert og svært lite forståelig. 





nummerplan, sikkerhet, lastbalansering, redundans, 



� De faglige utrykkene som er benyttet er ikke identiske med de som er benyttet i 


� 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

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 


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) 




nummerplan, sikkerhet, lastbalansering, redundans, 



� De faglige utrykkene som er benyttet er ikke identiske med de som er benyttet i 


� 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

VEDLEGG 6: Skisse på administrasjonsside for abonnent («Min 

side/Min telefon») 

Fortsettelse neste side. 

51

Kravspesifikasjon for Akershus fylkeskommunes ... - Bjørn Venn

Create successful ePaper yourself

Delete template?

Save as template?