Vejledning Passager markeret med gul er vejledning til leverandøren og skal slettes før bilaget leveres tilbage til kunden. Denne side skal ligeledes slettes. 1
2 Bilag 3 Leverancebeskrivelse med specifikation og Løsningsbeskrivelse samt ændringsmuligheder (herunder Optioner)
3 Indholdsfortegnelse 1 Indledning...4 1.1 Biblioteksbeskrivelse...4 1.2 og mindstekrav...5 1.3 Leverancens omfang...5 1.3.1 Beskrivelse af leverancen...5 1.3.2 Datamængder, kapacitet og ydelse...5 1.3.3 Optioner...5 1.3.4 Udstyr...5 1.3.5 Leveringssted...5 1.3.6 Uddannelse...5 2 Generelle systemkrav...6 2.1.1 Mindstekrav...6 2.1.2...6 2.2 Systemadministration og -konfiguration...8 2.2.1 Basestruktur...8 2.2.2 Mindstekrav...8 2.2.3...8 2.3 Standarder...11 2.3.1 Mindstekrav...11 2.3.2...11 3 Funktioner/moduler...12 3.1 Overordnede elementer...12 3.1.1...12 3.2 Enkelte funktioner/moduler...13 3.2.1 Søgning...13 3.2.2 Udlån...14 3.2.3 Fjernlån...16 3.2.4 Accession og tidsskriftstyring...18 3.2.5 Katalogisering...20 3.2.6 Statistik og rapporter...23 4 Konvertering og datamigrering...28 4.1...28 5 Optioner...29 6 Appendiks...30 6.1 Eksempler på bestillingsscenarier for forskellige lånertyper...30
4 1 Indledning I rapporten: Udviklingsplan for biblioteksområdet ved Aarhus Universitet af 15. oktober 2007 hedder det: Arbejdsgruppen anbefaler, at der etableres et fælles bibliotekssystem for AUs biblioteker og Statsbiblioteket med driftsansvar placeret hos Statsbiblioteket. Et fælles system vil kunne indebære en betydelig styrkelse af bibliotekssamarbejdet ved AU og lette brugernes adgang til informationsressourcer. Ønsket om ét fælles bibliotekssystem ligger i forlængelse af [DEFF's] anbefalinger om øget konsolidering af bibliotekssystemer på forskningsbibliotekerne, som beskrevet i rapporten Vurdering af konsolideringsmulighederne af lokale IT-afdelinger (2007, udarbejdet af konsulentfirmaet Gartner Group). Det fælles bibliotekssystem skal være baseret på fleksibilitet, åbenhed og modularitet, således at der er gode muligheder for såvel individuel tilpasning af systemet som for at tilslutte eller erstatte moduler, fx alternativ brugergrænseflade, fjernlånsmodul, styring af særlige materialeflow o.l. 1.1 Biblioteksbeskrivelse Statsbiblioteket er nationalbibliotek, overbygningsbibliotek for folkebibliotekerne og hovedbibliotek for Aarhus Universitet. I 2007 blev en række tidligere selvstændige institutioner en del af Aarhus Universitet. Det medførte, at biblioteksbetjeningen nu varetages af 27 biblioteker af meget varierende størrelse. Tilsammen benytter de fem forskellige bibliotekssystemer: 3 større bibliotekssystemer, nemlig Horizon fra SirsiDynix, Aleph fra Exlibris, DDE-Libra, samt 2 små: Book- IT fra Axiell samt BiBox (lokalt udviklet system). En del biblioteker har døgnåbent, med betjening via selvbetjeningsautomater. Systemerne administrerer tilsammen ca. 5 mio. materialeenheder og har ca. 80.000 registrerede brugere. Flere af de gældende licenser giver mulighed for ubegrænset antal samtidige personalebrugere såvel som ubegrænset antal slutbrugere. I praksis anslås antallet af samtidige personalebrugere til ca. 250-300, og antallet af samtidige slutbrugere til ca. 1000 samlet for systemerne. 3 af de nuværende systemer anvendes i mindre omfang også til at servicere andre statslige biblioteker. Det drejer sig om ca. 5 institutioner, som råder over tilsammen ca. 10 samtidige personalebrugerlicenser. Biblioteker med driftopgaver for andre biblioteker: Statsbiblioteket (SB) Aarhus School of Business, biblioteket (ASB) Danmarks Pædagogiske Bibliotek (DPB)
5 1.2 og mindstekrav Nedenstående beskrivelse af krav til de enkelte moduler er opdelt i 2 typer: - Mindstekrav, dvs. krav som systemet ubetinget skal kunne opfylde. -, dvs. funktionalitet som vi forventer, er opfyldt ved ibrugtagning. Hvert afsnit indledes med mindstekrav efterfulgt af krav. Se udbudsbetingelsernes pkt. 6 Migrering og konvertering af data Opgaven er beskrevet samlet i afsnit 4 Konvertering og datamigrering og er ikke medtaget under de enkelte moduler. 1.3 Leverancens omfang 1.3.1 Beskrivelse af leverancen Leverancen omfatter anskaffelse af software, etablering og vedligeholdelse af et nyt bibliotekssystem til både Statsbiblioteket, Aarhus Universitet samt til betjening andre statslige biblioteker, der ikke er en del af Aarhus Universitet, herunder forskningsbiblioteker. Leverancen skal omfatte alle de nødvendige komponenter, ydelser og andre nødvendige aktiviteter for en succesfuld implementering og ibrugtagning af bibliotekssystemet - herunder installation og test. Statsbiblioteket ønsker selv at drifte systemet, men leverandøren skal levere den nødvendige vedligeholdelse, support og løbende opdatering af det leverede system. 1.3.2 Datamængder, kapacitet og ydelse Den samlede årlige tilvækst anslås til at blive ca. 240.000 fysiske enheder. Det samlede antal udlånstransaktioner pr. år forventes at blive ca. 2 millioner udlån og fornyelser, heraf ca. 600.000 fra lukkede magasiner. Mulighed for at øge og reducere kapaciteten i kontraktens løbetid. Priser og varsler for dette angives i bilag 12. 1.3.3 Optioner Leverandøren skal tilbyde følgende option: Forlængelse af kontraktens løbetid i 12 måneder. I givet fald vil optionen blive anvendt senest 6 måneder før kontraktens ophør eller 6 måneder før ophør af en eventuelt tidligere udnyttet option. Optionen kan anvendes tre gange. Priser herfor angives i bilag 12. En eventuel udskillelse af diverse krav som optioner skal der gøres rede for i afsnit 5. 1.3.4 Udstyr Leverancen omfatter ikke hardware i form af servere og arbejdsstationer, idet Statsbiblioteket og Aarhus Universitet allerede er i besiddelse heraf, eller vil anskaffe det nødvendige udstyr til brug for leverancen under denne kontrakt. 1.3.5 Leveringssted Statsbiblioteket Universitetsparken 8000 Århus C 1.3.6 Uddannelse Leverandøren skal levere den nødvendige uddannelse af driftsmedarbejdere hos Statsbiblioteket og Aarhus Universitet og angive eventuel certificering af medarbejderne så de kan foretage den nødvendige daglige drift.
Leverandøren skal ligeledes levere den nødvendige uddannelse, inkl. uddannelsesmateriale, af op til en snes nøglemedarbejdere, således at Statsbiblioteket og Aarhus Universitet selv efterfølgende kan uddanne brugere.uddannelsesforløb forventes afholdt på Statsbiblioteket. Beskrivelse af uddannelse og certificering samt priser herfor foretages i bilag 5. 6 2 Generelle systemkrav Vi ønsker et system, der kan integreres i et overordnet IT-system, som omfatter mange andre systemer end selve bibliotekssystemet. Bibliotekssystemet skal derfor kunne integreres med en mangfoldighed af øvrige systemer. Grænsefladerne for denne systemintegration skal foregå via standardiserede og dokumenterede grænseflader, og disse standarder skal i videst muligt omfang være udbredte internationale standarder. 2.1.1 Mindstekrav Systemintegration Leverandøren stiller veldokumenterede API er til rådighed til at løse de opgaver, som er nødvendige for, at Statsbiblioteket og Aarhus Universitet kan integrere bibliotekssystemet i det samlede IT-miljø. Som eksempler nævnes her nogle af de opgaver som Statsbiblioteket ønsker at løse: mulighed for at lave opdatering af den eksterne søgeportal med så tæt på realtidsopdatering som muligt med katalogdata og statusoplysninger. integrering til eksterne administrative systemer (økonomisystemer, matrikler, leverandørdatabaser) programmatisk at udføre specifikke operationer over for bibliotekssystemet, f.eks. oprettelse af en bestilling af et givet materiale for en given låner. 1 2.1.2 Licenser Så vidt muligt, og i det omfang det er fordelagtigt for Statsbiblioteket, ønskes tilbudt en løsning, der baseres på de licenser, som Statsbiblioteket og Aarhus Universitet allerede er i besiddelse af. Der ønskes desuden konsolideringsfordele ved at licensdimensioneringen kan udnyttes samlet for de tidligere separate systemer. Kontrakten vil give mulighed for, at kapaciteten i kontraktens løbetid kan udvides. Dette gælder både for licenser, der kan anvendes til betjening af Aarhus Universitet og Statsbiblioteket, og for licenser der kan anvendes til at betjene andre statslige biblioteker, der ikke er en del af Aarhus Universitet, herunder forskningsbiblioteker. Leverandøren bedes angive om og hvordan dette efterkommes. 2 Programmel Det leverede bibliotekssystem skal fortrinsvis være en hyldevare der understøtter den forretning og de standarder mm der bruges i den danske bibliotekssektor. Leverandøren bedes beskrive hvad der er standardprogrammel og hvad der er kundespecifikt i hht kontraktens pkt 23.1 3
7 Sikkerhed Persondataloven samt andre relevante regler fra offentlige myndigheder, herunder DS484, skal efterkommes. Leverandøren bedes angive om dette sker. 4 Offline-situationer Leverandøren bedes dokumentere at systemet kan håndtere offlinesituationer, fx. udlån og afleveringer, og hvordan. 5 Adgang til data Der ønskes en beskrivelse af, hvordan systemet giver direkte adgang til alle data, og om der tilbydes forskellige tilgangsmåder afhængig af niveau (f.eks. via SQL (primært læsning), opdatering bør håndteres ved interfaces på højere niveau). Fx skal muligheden for at eksportere alle data fra systemet være til stede. 6 Adgang Der skal være single sign-on i henholdsvis lånerorienterede og personaleorienterede klienter. Leverandøren bedes beskrive hvorledes dette kan lade sig gøre. 7 Samspil med e-læringssystemer Leverandøren bedes beskrive, hvorledes systemet gør det muligt at e-læringssystemer (fx Aula, Campusnet, First Class) skal kunne trække på biblioteksressourcer, herunder kunne linke til specifikke søgninger eller søgeresultater. 8 E-ressourcer Leverandøren bedes beskrive hvorledes integration med metadata, indhold og adgang til digitale ressourcer, herunder forskningspubliceringsdata fra PURE, understøttes. 9
8 Elektronisk betaling Leverandøren bedes beskrive om og hvordan bibliotekssystemet håndterer såvel manuel som elektronisk betaling af fx gebyrer, erstatninger mm fra lånere, herunder om det er i stand til at fordele gebyrerne i forskellige kasser (mange biblioteker, flere institutioner). Benyttelse af eksterne formidlere fx DIBS, WorldPay og PBS beskrives. 10 Kommunikation Leverandøren bedes beskrive hvordan systemet understøtter kommunikation med lånere, personalet og leverandører, fx via e-mail, sms, print m.m. og hvordan det kan konfigureres pr. bibliotek i samarbejdet. 11 2.2 Systemadministration og -konfiguration 2.2.1 Basestruktur Det forventes først afgjort i dialog med leverandøren, om man ønsker en tæt integration af bibliografiske data, hvor man samler flest mulige lokale data omkring færrest mulige bibliografiske poster i én fælles bibliografisk base eller en løsere model, med flere dubletposter i samme bibliografiske base eller en opdeling i flere bibliografiske baser. Det samme gælder beslutning vedrørende behandling af administrative data. 2.2.2 Mindstekrav Detaljeret rettighedsstyring Systemet skal give mulighed for detaljeret brugerrettighedsstyring på både låner-/personale- /systemadministratorniveau således at det bl.a. sikres at personale ikke kan rette i andre institutioners lokale data. Leverandøren bedes beskrive hvordan systemet løser dette. 12 2.2.3 Rettighedsstruktur Leverandøren bedes redegøre for hvorledes systemet tilbyder mulighed for detaljeret rettighedsstyring: Det forventes at rettighedsstrukturen er hierarkisk eller alternativt benytter et gruppebegreb, hvor grupper kan tilføjes til andre grupper. Rettigheder til oprettelse, sletning, redigering og læsning af diverse poster skal kunne defineres pr. bruger, gruppe e.l. på modulniveau, funktionsniveau, baseniveau og ved katalogisering også på feltniveau 13
9 Sikker uddelegering af systemadministration Leverandøren bedes beskrive om og hvordan det er muligt at tilrettelægge en sikkerhedsmæssigt forsvarlig uddelegering af systemadministrative opgaver, så disse kan udføres både centralt og decentralt, fx.: At differentierede brugerrettede og leverandørrettede meddelelser (beskeder i klienten, beskeder i webgrænsefladen, bonprint, hjemkaldelser, m.m.) kan oprettes og styres. At tilpasning af webgrænseflader kan ske individuelt pr. betjeningssted og samling. At standard klientudseende og klientfunktion kan konfigureres på brugerenhedsniveau. At der er mulighed for brugerdefineret opsætning pr. personalebruger (ikke pr. arbejdsstation), som genindlæses ved næste login. At automatiske jobs kan defineres, kan defineres pr. betjeningssted, og kan køres på definerede tidspunkter (klokkeslæt/dag/uge/måned/dato/opstart/intervaller mv.). At der er mulighed for genkørsel af jobs på baggrund af brugerrettigheder. At kunne definere områder i opsætningen, hvor der kan gives lokale administratorrettigheder til specifikt betjeningssted. At logning (auditing) af diverse operationer er muligt, fx operationer der relaterer til persondata eller ændringer af bibliografiske data mm. 14 Interfaces til administration Leverandøren bedes beskrive om og hvorledes nedenstående er muligt. At konfigurationsændringer kan gennemføres både via grafisk brugerinterface og ved redigering i bagvedliggende filer, tabeller e.l. At eksport/import af rettigheds- og konfigurationsdata og andre administrative data er mulig. At der er mulighed for detaljeret systemovervågning og at dette kan ske via programinterface. 15 Performance ved detaljeret regelstyring Leverandøren bedes beskrive hvordan systemet, uden væsentlig performancepåvirkning, kan understøtte mange selvstændige betjeningssteder (30-100 betjeningssteder med et antal samlinger hver) med differentierede regler for udlån, katalogisering, separate leverandørregistre m.m. Reglerne skal kunne differentieres på betjeningssted, samling, processtatus, materialestatus, materialetype, lånertype, lånerstatus m.m. 16 Sikring af data Leverandøren bedes beskrive hvorledes systemet understøtter procedurer for backup og reetablering data. 17
10 Sprog Leverandøren bedes beskrive hvorledes systemet understøtter sprogene engelsk og dansk i kommunikation med leverandører, brugere og lånere. Særligt i forhold til sidstnævnte ønsker vi at brugeren selv kan vælge. 18 Permanent testmiljø Leverandøren bedes beskrive mulighederne for at etablere et fuldt funktionsdygtigt testmiljø, som bør kunne være en spejling af driftsystemet fra en given dato. Flere sideløbende testmiljøer vil være stærkt at foretrække. 19 Eksterne værtskaber Leverandøren bedes beskrive, hvordan værtskaber for eksterne enheder kan administreres, fx ved at de lægges i særskilte siloer og i hvilket omfang det har indflydelse på prisen. 20
11 2.3 Standarder Statsbiblioteket ønsker, at systemet i videst mulig omfang anvender åbne standarder og tilbyder åbne grænseflader. Dette gælder for dataudveksling på alle niveauer, og for funktioner der muliggør adskillelse af søgefladen fra bibliotekssystemet, således at bibliotekssystemets logistikfunktioner kan anvende uafhængige søgesystemer. Vi forventer at et kommende bibliotekssystem implementerer relevante internationale og nationale standarder til at løse vores integrationsbehov, der hvor disse er relevante herunder: 2.3.1 Mindstekrav Generelle standarder Det er et krav, at bibliotekssystemet understøtter følgende: Web-service (eller tilsvarende) grænseflader til at tilgå proprietære funktioner. Unicode DanMARC2-format til udveksling af katalogposter Z39.50 til søgning mv. jf. Bath og Danzig-profilerne i både server og klient NCIP o Lånertjek o Bestillingstransaktioner jf. DBC-applikationsprofilerne o Evt. selvbetjening SIP v. 2 til selvbetjeningsautomater (evt. NCIP) ISO ILL OpenURL LDAP til autentifikation af lånere og medarbejdere SSL Email - kommunikation til lånere og leverandører Håndtering af danske sorteringsregler (http://www.kat-format.dk/ordnregistre.html). Specialkarakteren gammelt dansk å=aa 21 2.3.2 Andre standarder Leverandøren bedes beskrive i hvilket omfang nedenstående og evt. yderligere standarder understøttes: EDI, Edifact, EDItX, EDITeur SAML 2 OAI PMH XML til dataudveksling SMS CCL, SOAP 22
12 3 Funktioner/moduler 3.1 Overordnede elementer 3.1.1 Redigering af data Vi forventer at bibliotekssystemet understøtter almindelig Windows-funktionalitet, og at editering af data i alle moduler foregår på samme måde og med de samme muligheder, fx. Masserettelser Mulighed for at udføre masserettelser af såvel autoritetsdata, bibliografiske data som eksemplardata og lokale data. Mulighed for at udpege poster til masserettelse, dels ud fra en brugergenereret liste, dels ud fra en søgning. Validering Validering af postindhold i forhold til minimumskrav, fx lovligt indhold i felter med koder som dataindhold og obligatoriske felters tilstedeværelse Fejlmeldinger fra systemet, der er forståelige og detaljerede Hvis fejlbeheftede/ufærdige poster kan gemmes, skal de let kunne fremsøges til efterbehandling, med kriterier for afgrænsning (oprettet af.., oprettet i perioden, indeholder beholdning fra ). 23 Hjælpefunktioner o.l. Leverandøren bedes beskrive hvorledes systemet understøtter hjælpefunktioner som fx: Generelle, søgbare og redigerbare hjælpetekster til systembrug Hjælpetekster og opslagsmuligheder på gyldige kodeværdier af bibliografiske data og (feltnumre, delfeltkoder, indhold af felter med koder som dataindhold) Hjælpetekster og opslagsmuligheder på gyldige angivelser af lokationsbetegnelser, filialbetegnelser, samlinger, materialekoder mv. for eksemplardata, specialtegn Oprettelse af maskeposter (katalogiseringsskabeloner) Tastaturgenveje til alle funktioner 24 Print God printfunktionalitet forventes i alle moduler. Leverandøren bedes beskrive, hvorledes nedenstående opfyldes: At det er muligt at genudskrive diverse prints fra systemet også enkelte sider At det er muligt at efterbehandle printfiler, at foretage automatisk baggrundsudprintning samt fordele print til forskellige printere. 25
13 Stregkodevalidering Leverandøren bedes beskrive, hvilke muligheder systemet tilbyder for at anvende mange forskellige stregkodeformater. 26 URL er URL-check Vi forventer, at systemet tilbyder mulighed for automatisk check af URL i alle de felter, hvor URL kan anføres. Leverandøren bedes derfor beskrive hvilke muligheder systemet tilbyder. Mulighed for at åbne URL er direkte fra bibliotekssystemet via standardbrowser 27 3.2 Enkelte funktioner/moduler 3.2.1 Søgning Vi forventer at systemet tilbyder såvel en standard OPAC (rettet mod lånerne) som personalesøgning. Derudover skal det være muligt at implementere en alternativ søgegrænseflade rettet mod lånerne, fx Statsbibliotekets informationssøgningsprodukt 'Summa' (se også krav 1) 3.2.1.1 Søgning (personalesøgeflader) Vi forventer at der fra alle moduler er simpel adgang til en personalesøgeflade, der skal indeholde: Skanfunktion i registre (registeropslag) Søgning default i et antal registre og søgning specifikt i enkelte registre. Mulighed for trunkering, maskering, nærhedssøgning Vi forventer muligheder for: Afgrænsning til søgning i lokal bestand Søgning på eksemplardata og lokaldata Søgning parallelt i egne data og eksterne data, fx Danbib, LC etc. Opsætning af lokale søgemuligheder, både ordsøgning og registeropslag. Praksisregler for søgeveje http://www.bs.dk/publikationer/andre/praksisregler/index.htm ) bør kunne understøttes i fuldt omfang, derudover bør det være muligt at definere lokale søgeveje. Opsætning af bredt default søgeregister Mulighed for kombinatorisk søgning (operatorer og, eller, ikke ) Søgetegnsæt iflg. Danske katalogiseringsregler (http://www.katformat.dk/alfaregler.html ) Mulighed for at definere logiske delbaser. Logiske delbaser kan både være fast definerede afgrænsninger (f.eks. tidsskrifter) og adhoc-afgrænsninger, f.eks. defineret ved en søgning Mulighed for registeropslag også i delbaser
14 Fremvisning af tidstro låner- og materialestatus for personale og låner via brugergrænsefladen Med få klik at kunne fremsøge lånere og lave reservationer, se på enkelteksemplarer, og se udlåns- og reservationsdata 28 Søgning (lånersøgeflade) Vi forventer at systemet leveres med en standardwebgrænseflade, med mulighed for lokal tilpasning. Mulighed for at benytte den mod beholdning for en enkelt biblioteksenhed. Mulighed for simpel søgning og avanceret søgning Understøttelse af trunkering, maskering, nærhedssøgning Funktionalitet til brugerselvbetjening såsom liste over lån med mulighed for fornyelser, lister over reservationer og bestillinger med mulighed for at redigere osv. Stavekontrol, 0-fundslogik andre har lånt 29 3.2.2 Udlån 3.2.2.1 Mindstekrav Bestilling fra lukkede magasiner. Systemet skal understøtte bestilling og ekspedition fra lukkede magasiner. 1. Bestillinger skal kunne sorteres ud til forskellige fysiske magasiner ordnet efter materialets fysiske placering. 2. OBS: Systemet skal kunne differentiere mellem bestilling på disponibelt materiale og reservation af ikke-disponibelt materiale. 30 3.2.2.2 Komplekse bestillingsveje I det nye bibliotekssystem vil der være et stort antal biblioteker, som skal kunne fungere sammen, og hvorfra man skal kunne bestille materiale efter et bestemt mønster. Kan systemet fx: Sættes op til at kunne håndtere komplekse bestillingsmønstre, og route en bestilling efter de enkelte bibliotekers udlånsregler? Eksempler, se s. 30 Lave gruppereservationer (reservationer der tager først hjemkomne eksemplar fra en brugerbestemt gruppe af poster). Forudsige sandsynligt tilgængelighedstidspunkt ved såvel bestilling som reservation 31
15 Udlånsprocesser Leverandøren bedes beskrive hvorledes systemet håndterer udlånsprocesser, især mht: Fornyelser Der skal være mulighed for fornyelser af såvel enkelt- som samlede lån både for lånere og personale (på låners vegne) Fornyelsespolitik skal kunne konfigureres individuelt på lånerkategori, bibliotek, materiale fornyelsesperiode, antal fornyelser og på udestående Selvstændige hjemkaldelsesprocedurer Der skal kunne defineres selvstændige hjemkaldelsesprocedurer pr. bibliotek i samarbejdet. Mærkning RFID og stregkoder skal kunne anvendes sideløbende. SB vil ikke sætte RFID i alle bøgerne, og RFID er allerede sat i et stort antal bøger flere steder. Låner-ID Systemet skal kunne håndtere forskellige typer lånerkort samtidig (f.eks. sygesikringsbevis, årskort). Styring af karenstid Automatisk styring af karenstid på basis af oplysninger i bibliografisk post (p.t. musik) Batchjobs Det skal være muligt også for superbrugere at afvikle selvdefinerede batchjobs (f.eks. påmindelser, hjemkaldelser, bestillinger, automatisk fornyelse, rapporter, slette reservationer) pr biblioteksenhed eller for flere ad gangen 32 Særlige lån Leverandøren bedes beskrive, hvorledes følgende typer af lån håndteres i bibliotekssystemet: Læsesalslån Det skal være muligt for lånere at bestille f.eks. klausuleret materiale (vil fremgå af materialekategorien i eksemplarposten) til brug på læsesal. Ved udlån skal materialet skifte status til en særlig type, der identificerer udlånet som et læsesalslån. Ved et eventuelt hjemkaldelsesforløb skal en hjemkaldelse ikke sendes til slutbrugeren, men til læsesalen. Semesterhylder Det skal være muligt at oprette semesterhylder, dvs. det skal være muligt at lade udvalgte materialer skifte status i en periode (f.eks. et semester). Af denne status skal det fremgå, hvor materialet er placeret. Man skal kunne finde alle materialer for en enkelt hylde Nedsat lånetid Systemet skal kunne håndtere automatisk nedsat lånetid på efterspurgt (reserveret) materiale styret på antal reservationer, lånertyper, bibliotek, materiale oa. Booking Det skal være muligt at forudbestille materiale til levering på et tidspunkt ud i fremtiden. KVIK-lån af ikke-registreret materiale Det skal være muligt nemt og hurtigt at lave udlån af ikke-registreret materiale (KVIKlån) 33 Leveringsmåde og betaling
16 Leverandøren bedes beskrive, hvordan bibliotekssystemet håndterer dette: At lånerne kan angive en ønsket leveringsform (afhentning, forsendelse eller andet) i forbindelse med afgivelse af bestilling/reservation. At det skal være muligt at knytte betaling til visse typer af lån og automatisk udskrive regning. At der automatisk udskrives en følgeseddel til materialet afhængig af leveringsform 34 Selvbetjening Leverandøren bedes beskrive hvorledes bibliotekssystemet understøtter selvbetjening såvel udlån som aflevering på det enkelte bibliotek betaling, fornyelse m.m. via webgrænseflade. 35 Lånerhistorik Der skal være adgang til lånerhistorik i henhold til danske regler. 36 3.2.3 Fjernlån 3.2.3.1 Eksternt lånesamarbejde Fjernlånssystemet skal understøtte 1. Det nationale lånesamarbejde (herunder Z39.50 item order) 2. Det internationale lånesamarbejde 37 Samspil med andre systemer Leverandøren bedes beskrive, hvorledes nedenstående opfyldes i bibliotekssystemet: Modulet skal være fuldt integrerbart med udlånssystemet Fra fjernlånsmodulet skal det være muligt at dirigere en bestilling over til ekspedition i egne samlinger f.eks. til monografiekspedition, tidsskriftekspedition mfl. 38
17 Brugerkommunikation Leverandøren bedes beskrive hvorledes nedenstående opfyldes i bibliotekssystemet: Understøtte kommunikation med brugerne undervejs i bestillingsforløbet bl.a. i form af redigerbare meddelelser Understøtte adgang for brugerne til lånestatus herunder differentieret adgang for forskellige brugerkategorier (slutbrugere og personale) 39 Registre Leverandøren bedes beskrive hvorledes nedenstående opfyldes i bibliotekssystemet: 1. Leverandørregister (långivende biblioteker og andre informationsleverandører)) Skal give adgang til oprettelse, søgning og vedligehold Tilbyde grænseflade for ekstern vedligeholdelse af leverandørregister 2. Bestillingsregister Skal understøtte et bestillingsregister med fleksible søge- og opslagsmuligheder 40 Oprettelse af bestillinger Leverandøren bedes beskrive hvorledes nedenstående håndteres i bibliotekssystemet: Oprettelse af fjernlånsbestillinger: for medarbejdere oprette og redigere for slutbrugere oprette understøtte internationale standarder (eks. ISO ILL) understøtte alternative bestillingsmuligheder til leverandører, der ikke er omfattet af standard-systemer (eks. e-mail bestillinger) understøtte genbrug af eksisterende stregkoder 41 Modtagelse/aflevering/rykning Leverandøren bedes beskrive hvorledes nedenstående håndteres i bibliotekssystemet: Modtagelse af fjernlån, herunder også modtagelse og behandling af digitale dokumenter fra systemer som Ariel, Odyssey o l. Aflevering af fjernlån Automatisk rykkerfunktion Muligheden for at hente historik på bestillinger (log) Udskrivning af gamle print/bestillinger 42
18 3.2.4 Accession og tidsskriftstyring I dette afsnit er beskrevet krav vedr. accession af monografier og tidsskrifter, i såvel papir som elektronisk form. Særlige forhold: Statsbiblioteket har en lovbestemt forpligtelse til pligtafleveringskontrol af aviser, fonogrammer, videogrammer og lydbøger, idet den primære aflevering for disse materialer sker på Statsbiblioteket. I samme forbindelse håndteres en del materialer til bogbinding uden for SB. Særlige krav til disse rutiner er beskrevet sidst i afsnittet. 3.2.4.1 Accession Leverandøren bedes beskrive hvordan systemet tilbyder styring af alle almindelige processer i forbindelse med anskaffelse af materialer, dels som enkelte køb, dels som abonnement, uanset medium. 43 Særlige accessionsprocesser Leverandøren bedes beskrive hvordan systemet tilbyder styring af følgende særlige processer: opretholdelse og vedligeholdelse af et register over de afleveringspligtige (leverandørregister), med oplysninger om leverandørkategori. Forskellige leverandører skal kunne have hver deres afleveringstermin. Leverandørregisteret skal være søgbart for alle oplysninger. Af hensyn til vedligehold af registret ønskes mulighed for direkte link til TDC og KRAK. mulighed for kontrol med at aflevering finder sted inden for en nærmere fastsat periode (rykning), herunder reklamation af eventuelt manglende eksemplar 2. Der skal kunne udskrives kvitteringer og standardrykkere til leverandør, enten pr. e-mail eller pr. brev. Mulighed for indcheckning af tidsskrifter, aviser og distriktsblade, hvor eksemplardata indeholdende oplysninger om heftets datering dvs. årgang,, år udgivelsesdato osv. gemmes med og uden en egentlig eksemplarpost, men med opdatering af beholdningsoversigten. Mulighed for indcheckning af specifikke abonnementer for samme titel Mulighed for at kunne inddatere forskellige udgivelsesmønstre for samme titel, som anskaffes både ved pligtaflevering og køb Der ønskes et integreret system for hensigtsmæssig håndtering af periodiske materiale f.eks. tidsskrifter, aviser, distriktsblade til bunkeregistrering, og således at indcheckning og bogbinderrutiner gøres mulig i én arbejdsgang 44 Leverandørinfo Der ønskes en beskrivelse af hvordan systemet håndterer følgende oprettelse og vedligehold af leverandøroplysninger uanset materialetype; mulighed for flere kontaktadresser/kontaktpersoner mv. (flere biblioteker, samme leverandør) Særlige krav vedr. pligtaflevering, se nedenfor 45
19 Bestilling og betaling Der ønskes en beskrivelse af hvordan systemet håndterer følgende opgaver: Understøttelse af brugen af EDI (og dens fremtidige erstatninger, som f.eks. ONIX, EDItX, XML, SOAP baserede webservices) til elektronisk dataoverførsel. Forudfyldte felter i bestillingen (fx sagsbehandler, fagref. leverandørkode, konto, beholdningsdata, osv.) Budgetstyring efter fastsatte parametre Rykkerstyring efter fastsatte parametre Automatisk harvesting hos indholdsleverandører af udgivelsesoplysninger Automatisk bestilling hos leverandør Tabeller med dagligt opdaterede valutakurser. Indbygget mail mulighed herunder farve/lyd pop-up ved modtagelse Kontoadministration: Mulighed for check af individuelle bestillingsdata 46 Datahåndtering Mulighed for at flytte administrative data fra én bibliografisk post til en anden 47 E-ressourcestyring Der ønskes en beskrivelse af hvordan systemet håndterer styring af e-ressourcer (tidsskrifter, e-bøger og databaser), fx: - adgangsveje - passwords - IP-adresser - pakker - økonomi herunder pay-per-view 48 Cirkulation Leverandøren bedes beskrive hvordan systemet håndterer cirkulation af hefter til en fast deltagerkreds. 49 Indbindingsflow Der ønskes en beskrivelse af, hvordan systemet kan løse følgende opgaver: Tidsskrifter: vælge, gemme og rettet stamoplysninger (fx. vedr. bindfarve og -type m.m.) afsende en ordre, der senere printes ud til en liste med angivelse af de væsentligste oplysninger automatisk statusændring for materiale der er klar til udlån ( som kommaseparerede filer) automatisk oprette et nyt parti med fortløbende partinumre
20 se statusoplysninger (er tidsskriftsbindet hos bogbinder eller på plads) have mulighed for at reservere materiale, der er hos bogbinder se hvilket bibliotek tidsskriftet tilhører sortering af lister så det enkelte biblioteks ordrer samles oprette og vedligeholde bogbinderregister se hvilket bibliotek, der har sendt til indbinding samle hefterne til bind uden at de oprindelige oplysninger om hefternes historik slettes Bøger og noder: generere nummer i parti vha. stregkoden på basis af den bibliografiske post udtrække liste over enhederne i rækkefølge, med angivelse af de oplysninger, der skal trykkes på hvert bind. Oplysningerne skal kunne tilrettes manuelt efter behov 50 3.2.5 Katalogisering 3.2.5.1 Mindstekrav DanMarc2: DanMarc2-formatet skal kunne håndteres af hensyn til deltagelse i det nationale katalogsamarbejde. Formatet ses her: http://www.kat-format.dk/danmarc2/default.html Særlige punkter i danmarc2, hvor det adskiller sig væsentligt fra Marc21: Tomme delfelter skal kunne anvendes i bestemte felter det vil altid være enten delfelt 0 eller 1. delfelter med betegnelserne æ, ø, å skal kunne benyttes anvendelse af indikatorværdier i felterne 860-79 for tidsskifter, mens øvrige indikatorer er nulstillet specielle sorteringsdelfelter med store delfeltbogstaver sorteringsstart-tegn skilletegn skal genereres i fremvisning og i indekserne ud fra delfelterne (de inddateres ikke) visse steder i formatet tillades det, at man gentager et delfelt (i stedet for at gentage feltet). Dette skal kunne udtrækkes separat til et nyt langordsindeks 001-009 er ikke positionsbestemte, men med delfelter delfelter benyttes ikke altid i alfabetisk rækkefølge ved indeksering og inddatering udvekslingstegnsæt er ISO 8859-1, med tilføjelser specielt for at håndtere gammel dansk aa og Aa og andre tegn og med mulighed for indkodning af alle tegn fra ISO 10646 Leverandøren bedes markere, hvis der er punkter, som bibliotekssystemet ikke understøtter og angive alternative løsningsmuligheder. 51
21 Håndtering af flerbindsværker Søgning og registrering Det er et krav, at systemet kan håndtere såvel enkelt- som flerpoststrukturer, da de bibliografiske data er heterogene og ikke uden videre kan rettes maskinelt: 1. Flerbindsværker i ét postniveau: 530-felter med bindoplysninger 248-felter med Marc-formaterede bindoplysninger 2. Flerbindsværker i flere postniveauer: (Én bindpost svarer ikke nødvendigvis til ét fysisk bind.) Søgning af poster på flere postniveauer: Oplysninger i hovedposter og i bindposter skal kunne søges sammen. Registrering: Systemet skal kunne hjælpe med at lænke posterne korrekt. Udlån: Man skal kunne reservere et specifikt bind og få det eksemplar, der er først hjemme; Alle formularer og visningsformater skal kunne trække hovedpostoplysninger med, således at hjemkaldelser, lån, ekspeditionsformularer, hjemkomstmeddelelser mv. alle indeholder data fra både hoved- og relevant bindpost 52 Håndtering af lokale data Systemet skal gøre det muligt nemt at identificere (fx ved ejermærkning), oprette og vedligeholde lokale data i en fælles katalog. Ved lokale data forstås såvel beholdningsoplysninger som andre data, fx lokal systematik og/eller opstilling, lokale emneord o.l. 53 3.2.5.2 Autoritetsdata Vi ønsker en beskrivelse af, hvilke muligheder systemet tilbyder for at anvende autoritetsdata, fx.: Mulighed for at håndtere henvisninger separat, så alle alternative navneformer ikke skal oprettes i alle relevante bibliografiske poster Mulighed for at kontrollere indhold af bestemte felter (f.eks. DBC kontrollerede emneord) op mod en liste over valide termer Export af autoritetsdata (fx til Summa) 54
22 Dataimport og -eksport: Med henblik på maksimalt genbrug af katalogposter fra eksterne baser og tilsvarende bidrag til den nationale Danbib-base forventer vi veludbyggede import og eksport-muligheder. Leverandøren bedes beskrive hvilke muligheder systemet tilbyder, bl.a med hensyn til: 1. Dataimport: Samsøgning i egen base og en eller flere eksterne baser (fx. Danbib + LC + BNB), med mulighed for import af enkeltposter til genbrugskatalogisering i samme arbejdsgang. Batch-import, evt. incl. automatisk eksemplardannelse, af nye og rettede poster Mulighed for konvertering fra specificerede formater (specielt Marc21) til DanMarc2 on-the-fly 2. Dataeksport: Eksportmulighed i MarcXML, Linieformat og ISO2709. Udvekslingstegnsæt: se specifikation her: http://www.katformat.dk/danmarc2/danmarc2.4.htm#felt%20indl.%204 Eksportudtræk defineret ud fra et bredt antal kriterier (oprettelsesdato, slettet-status, ændringsdato, indhold i bibliografiske data, lokaldata og eksemplardata m.m.) 55 Dubletcheck Leverandøren bedes beskrive, hvilke muligheder systemet tilbyder for at undgå utilsigtede dubletter af poster, fx. Mulighed for at opsætte matchkriterier for check af utilsigtede dubletposter ved registrering Dubletcheck ved såvel grundkatalogisering som genbrugskatalogisering og ved batchimport 56 Midlertidige poster Leverandøren bedes beskrive hvordan man håndterer midlertidige poster (fx fjernlånsposter, midlertidigt registrerede poster) på en smidig måde fx ved en markering som gør, at materialet sendes til katalogisering efter aflevering, at post og eksemplar slettes automatisk efter aflevering eller at kun eksemplaret slettes automatisk efter aflevering. 57 FRBR (Functional Requirements for the Bibliographic Record) og RDA Leverandøren bedes beskrive hvorledes han er opmærksom på udviklingen inden for katalogdata og de konsekvenser den kan få for krav til fremtidig udvikling af systemet, herunder det forstærkede behov for håndtering af autoritetsdata? 58
23 3.2.6 Statistik og rapporter 3.2.6.1 Mindstekrav Statistik og rapporter Systemet skal tilbyde omfattende muligheder for at udtrække statistikker og rapporter, helst via en grafisk brugergrænseflade, men mindst med SQL eller lignende databaseforespørgselsmulighed. Statistikker, som kræves af Styrelsen for Bibliotek og Medier, med mulighed for opdeling på mindre biblioteksenheder, skal kunne udtrækkes.. 59 3.2.6.2 De krav, som er nævnt under de enkelte moduler, er statistiktyper, som systemet bør kunne levere, men generelt bør der være mulighed for at kunne udvælge og kombinere data, udvælge kriterier, definere visning i output, så at statistikker kan skræddersys efter behov. Statistik generelt Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: 1. Alle typer af data bør være tilgængelige for statistikforespørgsler. Det gælder produktionsdata, udlånsdata, lånerdata, accessionsdata, bibliografiske data, transaktioner mv. Disse data skal kunne opgøres separat for enkelte biblioteksenheder. 2. Standardstatistikforespørgsler må ikke påvirke systemets performance, og der skal kunne gives rettigheder til at udtrække disse eller nogle af disse til superbrugere. 3. Resultatet af statistik skal kunne eksporteres i standardformater til tredjepartsprodukter 4. Statistik, der ud fra indholdet i den bibliografiske post kan opgøre udlån til bestemte lånertyper (f.eks. opdeling af musikken ud fra koder i felt 039 hvilke typer udlånes til hvilken type biblioteker?). 5. Det skal være muligt at udtrække statistik på delmængder. Disse delmængder skal frit kunne defineres både ud fra bibliografiske data, specifikke data til enkeltlokationer og ud fra eksemplarer, samt ud fra administrative data om oprettelse, ændringstidspunkter mv. Forespørgsler skal kunne gemmes med henblik på genbrug og automatisk afvikling. 6. Statistik ud fra et interval af opstillingssignaturer. 7. Den periode, som en statistik skal dække, skal frit kunne angives. Såfremt statistiske data konsolideres, skal det angives efter hvilke principper dette gøres. 60
24 Statistik til accession og tidsskrifter Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: Statistik, for en valgfri tidsperiode, over: Bestillinger, delt op på biblioteksenheder, leverandører, konti, materialetyper, processtatus Tidsskrifthefter, delt op på udgivelselsestidspunkt, modtagelsestidspunkt, biblioteksenheder, leverandører, konti, materialetyper, processtatus Den samlede procestid delt op på leverandører, biblioteksenheder, materialetyper osv. Tal for: Budget, betalt, disponibelt, restbeløb fordelt på konti Betalt beløb, disponibelt beløb og antal betalte enheder fordelt på konti Betalinger fordelt på titel, afgrænset på fakturanummer, leverandør, afdeling/sagsbehandler Fakturerede materialer fordelt pr leverandør 61 Statistik til udlån Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: 1. Typer Det skal være muligt at opdele statistik på Lånerkategorier lånertyper, herunder at opgøre aktive brugere opdelt på lånertyper, kategorier, adresseoplysninger mv. materialekategorier materialetyper biblioteksenheder samlinger transaktionstyper opstillingsgrupper forsendelsestype/afhentning 2. Procestider Det skal være muligt at lave statistik over, hvor længe materialer står på ventehylde er i transit er udlånt reserveret evt. andet 3. Statistik for perioder Det skal være muligt at opdele statistik på perioder i løbet af dagen/ugen. 4. Forsendelsesstatistik Statistik for den nationale kørselsordning til Styrelsen for Bibliotek og Medier. Transitlån mellem biblioteksenhederne Forsendelser i øvrigt 62
25 Statistik til katalogisering Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: Tilvækst Antal nye titler/eksemplarer og/eller ændrede titler/eksemplarer til en given biblioteksenhed og evt. en given medarbejder i en given periode. Afgang Antal slettede titler/eksemplarer til en given biblioteksenhed og evt en given medarbejder i en given periode. Autoritetsdata Antal nye og/eller ændrede og /eller slettede henvisninger (autoritetsposter) i en given periode, evt. ved en given medarbejder. 63 Statistik til fjernlån Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: Antal bestillinger/gennemførte bestillinger/indlån/fornyelser/afleveringer/kopier i en given periode for en given biblioteksenhed og en given leverandør/type leverandør. Det skal være muligt selv at udvælge kriterier. Leverandør Rapport over hvor mange bestillinger til enkelt leverandører eller systemer (eks Bibsys, Libris mm) og hvordan bestillingerne fordeler sig? Leveringshastighed Rapporter over leveringshastighed hos de enkelte leverandører, eks fordelt på fysiske materialer og kopier? Leveringsmåde Rapporter over leveringsmåder (modtagelse af fysiske materiale, kopier og digitale dokumenter) Bestillingstyper Rapporter over fordeling af bestillinger på materialetyper, emneområder og udgivelsesår mm Lånertilhørsforhold Statistik over fjernlån opgjort på lånerkategori og -type 64
26 Rapporter: Enheder Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: For hvert modul at udtrække rapporter for hver biblioteksenhed og for systemet som helhed. Kriterier og output Det skal være muligt at udvælge og kombinere kriterier for en rapport Den skal kunne sorteres efter valgfrie kriterier Der skal kunne defineres forskellige output-formater, herunder standardformater til eksport til tredjepartsprodukter. Det skal være muligt at definere personlige lister ud fra søgninger, som kan benyttes til videre forarbejdning. Hyldelister Udtræk på eksemplarniveau med grafisk læsbare stregkoder til hylderevisioner, stregkodning, chipsning mv. Format og sorteringskriterier skal frit kunne defineres. Afgrænsning til biblioteksenheder, samlinger og dele af samlinger, samt til processtatus og materialetype skal kunne foretages. 65 Rapporter til udlån Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: Reservationer Lister over materialer med over et vist antal reservationer pr cirkulerende eksemplar Processtatus Lister over bøger, der har haft en bestemt processtatus i en vis periode. Materiale og brugertype Rapporter som opdeler udlån af bestemte materialer (liste eller søgning) på brugertyper. Lånerkategori Rapport med opdeling af lånere ud fra lånerkategori, geografi, alder, aktivitetsniveau mv. Hitlister Lister over de mest/mindst udlånte titler indenfor biblioteksenheder, samlinger, søgninger eller andre kriterier. Rapport over enkelteksemplarer med antal udlån fordelt over tidsperioder. 66 Rapporter til fjernlån Udestående Rapporter over uopfyldte fjernlånsbestillinger (til brug ved rykning). 67
27 Rapporter til accession og tidsskrifter Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: Typer Rapporter og summeringer indenfor selvdefinerede perioder, biblioteksenheder, leverandører, konti, ordrestatus, materialetype. Ordrer og rykkere Lister over ordrer indenfor selvdefinerede perioder, biblioteksenheder, leverandører, konti, ordrestatus, materialetype. Rapporter over rykkere valgfrit opdelt på leverandører mv. Cirkulationslister Det skal være muligt at definere cirkulationslister og definere formatet for dem. Løbende tidsskrifter Lister over alle løbende tidsskrifter, evt. opdelt på leverandør og biblioteksenhed. Modtagne bøger Lister over modtagne bøger med pris fordelt på konto eller fagref/sagsbehandler/andre kriterier. 68 Rapporter til katalogisering Leverandøren bedes beskrive, hvordan og i hvilket omfang systemet kan opfylde nedenstående: Produktion Lister over alle færdigprocesserede titler/eksemplarer til en given biblioteksenhed indenfor et valgfrit tidsinterval. Listen skal kunne udtrækkes i enten html eller xml og kunne sorteres efter valgfri kriterier. Formatet skal kunne tilpasses. Dataindhold Lister over alle poster, hvor et felt eller et delfelt har et bestemt indhold, eller forekommer, eller ikke forekommer. Disse lister skal kunne benyttes til viderebehandling. Lister over alle eksemplarer, som har et bestemt indhold, eller som hører til bibliografiske poster, der har et bestemt indhold. Disse lister skal kunne benyttes til viderebehandling. Ændringer, ansvar Lister over alle ændringer foretaget af en given medarbejder i et givet tidsinterval. 69
28 4 Konvertering og datamigrering Statsbiblioteket og Aarhus Universitets Biblioteker udfører forventeligt al ud-konvertering. Indkonvertering skal udføres af leverandøren. Da vi forventer at de enkelte biblioteker skifter system over en periode, vil konverteringsarbejdet tilsvarende foregå i flere tempi. 4.1 Udlån: Migrering af udlånsadministrative data Leverandøren bedes beskrive i hvilket omfang udlånsdata kan migreres og genbruges. Her tænkes på data fra alle de bibliotekssystemer, der anvendes på AU, såvel udlån, reserveringer, lånerdata, hjemkaldelser, historiske data, gebyrer, erstatninger mm. Dette gælder også for de biblioteker, som driftes af et AU-bibliotek. 70 Accession og tidsskrifter: Migrering af alle data Alle administrationsdata, fx publiceringsmønstre, cirkulationslister, ordrer, budgetoplysninger, leverandørregistre, bogbinderoplysninger o.l. Data fra sidesystemer (først og fremmest "Meridian"): 71 Katalogisering: Datamigrering Katalogdata skal kunne flyttes fra de nuværende systemer til det nye (bibliografiske data, eksemplardata, autoritetsdata), samt om muligt post- og eksemplaroprettelsestidspunkt og initialer på katalogisator. Der ønskes en beskrivelse af, i hvilket omfang leverandøren forventer at disse data kan migreres. 72
29 5 Optioner hvis ikke der er krav der udskilles som optioner, angives dette.
30 6 Appendiks 6.1 Eksempler på bestillingsscenarier for forskellige lånertyper Fra krav 31-32 Eksemplerne kan bruges fra/på alle AU-bibliotekerne: Eks. 1: Lånertype ansat En ansat fra ASB søger i AU-biblioteksbasen efter en bog, som findes på ASB, SB, AU-bib1, AU-bib2. Bogen på ASB er udlånt, og bestillingen skal dirigeres i rækkefølgen: SB, AU-bib1, AU-bib2. Bøgerne sendes med kørselsordning til den ansattes lokale bibliotek (Model= Bibliotek.dk m/ VIP base (=automatiserede fjernlån)) Eks. 2: Lånertype studerende. En studerende på ASB søger en bog, som findes på DPB, ASB, SB, AU-bib2 Bogen er udlånt på ASB og bestillingen skal dirigeres videre i prioriteret rækkefølge til først SB, derefter AU-bib2 og til sidst DPB. Hvorvidt materialet skal sendes eller er til afhentning/benyttelse på stedet er konfigureret i systemet. Dette vises i en klar tekst i bestillingsproceduren, som fortæller låneren, hvordan materialet er tilgængeligt. Eks. 3. : Lånertype: Privat låner uden tilknytning til AU En privat låner søger en bog som findes på SB, AU-bib1 Bogen er udlånt på SB, og der genereres en reservation på SB (der skal defineres en grænse for antal reservationer der kan ligge på en post førend bestilling kan videresendes i AUbibliotekssystemet). Eks 4 : Lånertype: Privat låner med tilhørsfilial DPB En privat låner søger en et materiale som findes på ASB og SB og flere andre biblioteker uden for samarbejdet. Da DPB ikke tilbyder fjernlån for denne lånertype. kan materialet kun fremskaffes mod vederlag. Eks 5 ; Lånertype: Privat låner med tilhørsfilial DPB En privat låner søger et materiale som findes på DPB og ASB. På DPB er alle eks. Udlånt og der er reserveringer på materialet mens der på ASB er ledige eks. Låneren ønsker at lave en reservering på materialet. Der må i dette tilfælde kun laves reservering på DPB s materiale eller låneren kan vælge at betale for fremskaffelse fra ASB eller andet bibliotek, som har materialet. Eks 6 : Lånertype: Biblioteker Bestillinger går direkte til DPB, ASB, SB Fra Netpunkt genererer en bestilling/reservation. Hvis et AU-eksemplar er ledigt viderestilles bestillingen efter aftale med AU-biblioteket skal kunne konfigureres i systemet. Fra bibliotek.dk generere en bestilling/reservation. Hvis et AU-eksemplar er ledigt, viderestilles bestillingen efter aftale med AU-biblioteket skal kunne konfigureres i systemet.