Det är komplicerat! – systemutveckling
på en internationell arena
Marie Wenander och Marie Widigson
Först i världen med ett halvfärdigt biblioteksdatasystem som är utvecklat av ideella entusiaster tillsammans med kommersiella företag. Utan OPAC, utan dokumentation och utan alla nödvändiga funktioner. Det verkar ju helt galet. Och det kanske det är också? Men hur ska vi kunna veta om vi inte provar, det kanske blir alldeles, alldeles underbart? Här får vi följa utvecklingen av FOLIO på Chalmers bibliotek.
Ett samarbete med många roller
Vi vill berätta om hur det är att vara kund hos ett stort före- tag samtidigt som vi är samarbetspartner i en internationell community. Hur det är att utveckla och vara testpartner när de som samarbetar i projektet representerar så olika intressen. Våra partner besitter en massa bra kunskaper och har många goda föresatser, men stämmer de med hur vi vill ha det? Vi har insett att det amerikanska sammanhanget är ganska väsensskilt från det svenska. Hur fungerar det då i praktiken när man ska få systemet att fungera ihop med Libris och det svenska sättet att organisera bibliotek? Till syvende och sist måste vi ju få till ett bibliotekssystem som går att använda i praktiken, och helst också uppnå våra mål om att förbättra och förenkla för alla. Vi har fått kompromissa och ta smällar och gått på minor men vi har lärt oss mycket. Hur det kommer bli framöver vet vi inte. Ja, nog är det kluvet och komplicerat. Men spännande är det.
I november 2017 beslutade vi oss för att ta oss an FOLIO- äventyret och hösten 2019 gick vi äntligen live. Det har varit intensivt och en tid fylld av överraskningar trots alla försök att vara planerade och ha kontroll. Det här är historien om vår resa och hur vi försökt förhålla oss till våra olika samarbetspartner, vilka strategier vi valt och hur de har fungerat.
Vad är FOLIO?
FOLIO är en akronym för ”The Future of Libraries Is Open” och är ett ILS (Integrated Library System), eller en LSP (Library Ser- vices Platform) som det lite modernare kallas. Det är ett verktyg
för att hantera det som man behöver göra på ett bibliotek, det vill säga. samla information om böcker och annat material, hålla koll på boklån och administrera e-resurser. Och förstås annat runtomkring, såsom statistik, låntagare, förseningsavgifter och fakturor. FOLIO bygger på öppen källkod och är ett frivilligt sam- arbete mellan bibliotek, IT-utvecklare och företag som erbjuder bibliotekstjänster på olika sätt.
Redan för drygt tio år sedan började ett gäng amerikanska akademiska bibliotek samarbeta för att skapa ett biblioteks- system med öppen källkod. Open Source-företaget Kuali gick samman med organisationen Open Library Environment (OLE) och utvecklade ett nytt bibliotekssystem, Kuali OLE. Trots höga ambitioner tog projektet aldrig riktigt fart och utvecklingen av- stannade. Någon gång där började företaget EBSCO Information Services att se sig om efter partner för att utveckla ett biblio- tekssystem som skulle kunna fungera med deras kommersiella tjänster. De slog sig ihop med det dansk-amerikanska IT-företa- get IndexData och de luttrade och antagligen ganska besvikna Kuali OLE-biblioteken.
Denna gång måste det bli bättre! EBSCO gick in med kapital och utvecklarresurser tillsammans med flera andra företag med open source-erfarenhet. Man bedömde dock att existerande plattformar inte var värda att bygga vidare på, så i stället började man från början, men med bättre förutsättningar. OLE-biblio- teken hade redan arbetat med att utveckla ett bibliotekssystem tillsammans och mycket av det borde gå att dra nytta av på olika sätt.
FOLIO är uppbyggt av moduler, eller ”appar” som har olika produktägare. I många fall är det personer som är anställda av företag, men det kan även vara någon bibliotekarie eller IT-ut- vecklare som är villig att samla på sig önskemål och buggar och prioritera utvecklingsteamens arbetsuppgifter. Teamen finan- sieras på olika sätt, mest av de involverade företagen men även av bibliotekssammanslutningar.
Grundtanken var att utveckla ett bibliotekssystem som an- vändarna vill ha, men då måste man förstås ta reda på vad det är. Ett antal arbetsgrupper bildades bestående av ämnesspecialister (det vill säga vanliga bibliotekarier, vi är ju experter på det vi gör) inom olika områden. Ambitionen var att tänka utanför boxen
och organisera grupperna på ett sätt som skulle gå över gränser- na mellan elektroniskt och tryckt material, men man trillade ganska snabbt tillbaka till välkända strukturer. Kanske av en anledning, det är faktiskt så det fungerar …
Öppenheten är slående i communityn och har varit så från allra första början. Arbetsgrupperna har täta möten som ofta spelas in och minnesanteckningarna är fritt tillgängliga. Det finns också chattkanaler där man kan kasta ur sig detaljer såväl som ta upp filosofiska frågor. Nya grupper bildas hela tiden och intresserade är välkomna att engagera sig så mycket de vill och förmår. Man behöver inte ha tänkt sig att faktiskt implementera FOLIO för att få vara med.
Varför valde vi att göra detta?
Listan över vad ett bibliotek behöver och skulle vilja hantera och integrera på ett enkelt och smart sätt blir längre och längre för varje år, men bibliotekssystemen hänger inte riktigt med i utvecklingen. Samtidigt har vi svårt att välja ut bara de delar av systemen som vi verkligen behöver och betalar ofta för en större kostym än vad som passar oss.
Risken för inlåsning är också värd att reflektera kring. Många finner att man hamnat i en situation där man i praktiken mås- te ”välja” ett paket av system från en leverantör och att det är väldigt svårt att kombinera det med tjänster från andra leveran- törer, gratisprogram eller programvara som man utvecklat själv. Att byta system är heller inte snabbt, enkelt eller billigt, särskilt inte om det samtidigt innebär att man byter leverantör. Det blir lätt att man i stället uppgraderar till nästa generation och köper de kringprodukter som just den leverantören erbjuder, vilket ytterligare cementerar inlåsningen.
Vi bestämde oss för att kartlägga våra behov. Bibliotekssys- temet Sierra från Innovative var väl inarbetat och rullade på. Som söktjänst använde vi Summon från företaget ProQuest. Bakom det låg Intota för att administrera e-resurser samt ett egenutvecklat system för fjärrlån och inköpsförslag. Men den totala kostnaden för detta var hög och systemen utvecklades inte i den riktning som vi önskade. Vi ville dessutom ha möjligheten att göra arbetet effektivare för personalen och söktjänsten mer lättanvänd för Chalmers studenter och forskare som nu skicka- des mellan olika gränssnitt och ofta gick vilse. På grund av
begränsad tillgång till helt öppna API:er kunde vi inte heller byg- ga de integrationer som vi ville ha.
Vi kikade en hel del på Koha och Coral, andra bibliotekssystem med öppen källkod som flera svenska bibliotek nyligen imple- menterat. Det har främst varit folkbibliotek som använt Koha tidigare, men på senare år har även en hel del akademiska biblio- tek valt att använda och vidareutveckla systemet. Open sour- ce-tanken var onekligen lockande, likaså att ingå i en gemenskap med andra engagerade bibliotek som inte bara såg sig som kunder utan även som partner. Men att själva stå för ”tråkig” IT-admi- nistration var inget vi ville lägga våra begränsade personalresur- ser på. Vi kastade ut frågor till olika företag om vad de skulle ta betalt för hosting. En hel del visade det sig.
Dags för upphandling alltså. Vi gav oss in i det med hull och hår, men inget av de alternativ som vi förväntade oss bli erbjudna kändes särskilt lockande. Vi ville ha en långsiktigt hållbar men flexibel systemkombination som skulle ge oss öppningar och inte låsa oss till en leverantör. Vi ville ha kontroll över vår egen data och kunna använda API:er för förutsedda och oförutsedda behov av integrationer med andra system och tjänster. Att vara en aktiv utvecklingspartner och få ett system som passar våra förhållan- den var också högt prioriterat. Men vi ville samtidigt vara kunder och låta någon annan ta hand om drift, backup och uppgradering- ar.
Precis innan upphandlingsunderlaget skulle publiceras sommaren 2017 fick vi ett erbjudande som vi inte kunde motstå. EBSCO frågade oss om vi, som första bibliotek i världen, ville implementera FOLIO som då ännu i princip bara var en pappers- produkt. Vår uppgift skulle vara att testa såväl systemet i sig som integrationer med befintliga produkter samt deras tänkta supporttjänster.
Vi hade många frågor att ta ställning till, det var ju ett strate- giskt val vi skulle göra. Här kom vårt upphandlingsunderlag till god nytta och vi såg att många pusselbitar föll på plats.
På det mer altruistiska planet fick vi en möjlighet att bidra till att bredda den låsta marknaden och skapa ett nytt open source- alternativ. Naturligtvis såg vi också möjligheten att i slutändan spara pengar när den personalintensiva utvecklingsfasen var över och också få möjlighet till kompetensutveckling.
med kunskaper och erfarenheter från olika delar av verksam- heten. Någon var särskilt inne på cirkulation, en annan gav sig entusiastiskt i kast med att djupdyka ned i metadata och bakom- liggande tekniska strukturer medan andra hade e-resurserna i fokus. Kollegor med stor kunskap inom UX (User experience) samt systemutvecklare har också involverats allt eftersom.
Så vi gav oss ut på en okänd väg för att förhoppningsvis berika marknaden med något nytt och annorlunda, ett alternativ som vi hade velat se bland de erbjudanden som vi fått om vi lagt ut vårt upphandlingsunderlag. Att det var open source var bra, men inte avgörande. Däremot var öppenhet och delaktighet viktigt. Transparens är ett av de vackraste orden som finns, och utveck- lingen av FOLIO skulle vara helt transparent och bygga på att alla involverade parter var delaktiga och öppna mot varandra.
Det var en stor risk, ja, men vi visste också att alla vill att vi ska lyckas eftersom vi är först ut. Och om vi inte gör det har vi vår nödutgång: att ta vår data och gå vidare till något annat, men förhoppningsvis vara klokare och kunnigare.
Att flytta till en byggarbetsplats utan tydlig ritning
Att byta datasystem kräver tid och en massa ställningstaganden. Ambitionsnivån och utgångspunkten varierar förstås, men ofta har man en leverantör som guidar genom processen med mäng- der av dokumentation och goda råd. Det system som vi skulle flytta vår katalog, våra e-resurser och våra användare till var rudimentärt och föränderligt. Därför var det extra värdefullt att en svensk implementationskonsult från EBSCO blev vår reskam- rat. Konsulten hade stor bibliotekserfarenhet, visste mycket om Libris och kunde dessutom förstå tekniken bakom systemen.
Vi hade använt vårt förra bibliotekssystem i många år och det fanns gamla rutiner som vi glömt varför de valts, komplicerade låneregler, märkliga inställningar och årsringar av olika policyer för hantering av metadata. Även om vi inte visste exakt hur sys- temet dit vår data skulle migreras var tänkt att struktureras be- hövde vi städa. Ju mer vi städade, desto mer stök såg vi. Vi visste dessutom att våra möjligheter att masshantera data, skapa listor och städa i gränssnittet skulle vara väldigt små under den första tiden efter migreringen. Skulle det göras så skulle det göras nu!
Idén var att vi skulle testa att använda FOLIO tillsammans med EBSCO:s andra bibliotekstjänster, det vill säga EBSCO
Discovery System (EDS), knowledgebas och länkserver. Migre- ring till detta ingick också. Eftersom vi sade upp de gamla syste- men hade vi ingenstans att göra av det ERM-data som vi behövde spara, och vår lösning för att visa licensvillkor skulle inte heller längre fungera, så vi fick snabbt bygga tillfälliga abrovinker.
Under den här tiden hände livet. Trots storslagen planering fann vi i Chalmersteamet oss minimerade till ett par personer under större delen av 2018. Vi kunde inte vara med överallt, i de arbetsgrupper som vi ville delta i, och samtidigt förbereda oss på migreringen och dataflytten.
Dessutom skulle vi prioritera det som var viktigast för oss att få med i den första versionen, den som vi skulle gå live med. Självklart skulle allt inte ha hunnit utvecklas ännu, och mycket av den funktionalitet som vi tagit för given i tidigare system skul- le saknas, åtminstone till en början. Nu hade vi ett väldigt stort inflytande, och det vi inte kunde klara oss utan var det som skulle utvecklas först.
För att ranka önskemål och ta hand om buggar används ett system som heter JIRA. Här har de bibliotek som tänkt sig im- plementera FOLIO en möjlighet att säga hur viktig en funktion är. Allt detta vägs sedan in för att skapa en roadmap och tilldela utvecklarteamen uppgifter.
Det var många önskemål att ranka, och nya tillkom i en rasan- de fart. Att säga ”not needed” till funktioner som vi visste att vi inte alls var intresserade av var enkelt. Vi har till exempel inte förseningsavgifter och har inget behov av att hantera leveran- törsfakturor i bibliotekssystemet, men hur i hela friden priorite- rar man mellan ”självklara” funktioner? Allt det som var med i vårt opublicerade upphandlingsunderlag kunde omöjligt hinnas med och vi behövde se vad som verkligen var nödvändigt för oss.
Det är inte heller lätt att snabbt sätta sig in i komplicerade reso- nemang och förstå vad önskemålet innebär och vad det skulle få för konsekvenser om funktionen inte finns. Det var en väldigt nyt- tig och ganska läskig övning. Tänk om vi tänkte helt fel och står där med ett oanvändbart system, och att vi ödslat gemensamma utvecklarresurser på fel saker. Det är ett stort ansvar. Kan man lita på att andra som rankar önskad funktionalitet förstår?
Vår strategi blev att fokusera på det som vi upplevde som viktigast och ställa frågor när vi inte förstod. En hel del missupp- fattningar reddes upp på det viset. Men som ni snart kommer se
så missade vi ändå en del stora saker. Vi valde också att fokusera mycket på funktioner för administration av elektroniska resur- ser eftersom en mycket stor del av Chalmers mediabudget går dit.
Relationen med vår implementationskonsult blev allt tajtare och det blev allt svårare att skilja mellan ”vi” (alla som var invol- verade i implementationen) och ”vi” (Chalmersteamet). Och det ”vi” (Chalmers) gjorde skulle komma hela ”oss” (FOLIO-commu- nityn) och ”oss” (Sverige) till godo. Gränsen mellan att vara kund och utvecklingspartner suddades ut. Samtidigt började företa- gets driftsmiljö och supporttjänster utkristallisera sig allt mer, där vi hade en tydlig kundrelation.
Så kom den dagen då vi äntligen kunde testa systemet! Chalmers data (inte låntagare förstås, de var fejkade) fördes över och vi kunde faktiskt börja fundera över hur vi skulle migrera data och testa arbetsflöden. Det var återigen en väldigt nyttig övning. Vad behöver vi för att till exempel köpa en bok? Varifrån ska vi hämta datat? Kan vi tänka om och förvärva fiffigare än tidigare trots att alla bitar inte är på plats? Fungerar det flöde som skissats på pap- per? Nej, såklart inte, i alla fall inte fullt ut. Att sitta tillsammans med produktägare och steg för steg gå igenom vad vi tänkt var väldigt givande för alla parter. Här var det skönt att ha rollen som krävande ”kund”. Vi behövde få våra behov tillgodosedda, men de hade dessutom resten av världen att ta hänsyn till.
Samarbete, kompromisser och svalda kameler
Som frontfigurer får vi massor av uppmärksamhet och våra öns- kemål prioriteras. Vi får vissa fördelar som kan sticka i ögonen men får också ta smällar som andra inte märker.
Att kunna reservera böcker är nog alla överens om är viktigt. Vi är vana vid att det är den först återlämnade boken som ska gå till den person som står först i kö och prioriterade funktionen ”Title level requests” högt. Och som vi hade förstått, läs antagit, skulle det bli så. Men när vi grävde lite visade det sig att det vi menade med reservation på titelnivå inte alls var detsamma som andra i communityn menade. Varken behov eller önskemål såg likadana ut. De amerikanska bibliotek som vi hade kontakt med hade sällan många exemplar av samma titel men däremot flera volymer på samma post, och många tyckte därför att det var mycket viktigare att kunna reservera på exemplarnivå. När detta gick upp för oss och produktägarna var det svårt att backa.
För att bygga om reservationshanteringen enligt våra önskemål hade andra delar av utvecklingen fått stanna upp, till nackdel för både oss och resten av communityn. Vi hade nu valet mellan att vänta med migreringen, eller att acceptera en lösning som vi inte alls gillade. Vi valde det senare. Men vi ger oss inte. En del av att samarbeta är att förstå varandras behov och bygga in en flexibilitet som fungerar för flera. Att jobba i en community handlar mycket om att argumentera och hitta nya vägar framåt. Man kan inte vara tyst och bara hoppas på att det löser sig eller att någon annan tar hand om det som är viktigt. Men man kan samtidigt inte ha koll på allt, och just den här kamelen slank igenom när vi silade myggen.
En anledning till systembytet var att hålla det enkelt, att kun- na dölja de delar av systemet som vi inte är intresserade av. Men i ett jämlikt samarbete ska man ju lyssna på alla, och alla har olika favoritfunktioner och särskilda förutsättningar som nu, i detta nya, vill behållas eller äntligen bli verklighet. Kan man tillgodose allas behov? När det inte finns en tydlig högsta ansvarig, vem bevakar då helheten? Stigar trampas upp åt alla håll. Det är dyna- miskt och oerhört spännande, men ingen reseledare säger ”Nej, nu är vi på fel spår, det är hit vi är på väg”.
Kund eller säljare? Att vara en betapartner
”You will be superheroes!” Så sa EBSCO till oss när de erbjöd oss att vara betapartner i projektet. Vi är föregångare, djärva, inno- vatörer. Vårt namn syns och nämns i en massa sammanhang. Vi har säkerligen många olika personliga bevekelsegrunder till att delta, förutom att skapa det perfekta systemet, till exempel att få skriva kapitel i antologier och få en fin meritlista eller personliga utmaningar. Men för Chalmers bibliotek är det inte detta som det handlar om. Vi vill varken vara superhjältar eller galjonsfigurer, vi vill ha ett biblioteksdatasystem som fungerar för oss i ett lång- siktigt perspektiv.
Vad innebär det då att vara betatestpartner? På det praktiska planet ska vi utifrån vår ämnesexpertis bidra med att beskriva våra behov och arbetsflöden. Vi ska testa och ge återkoppling och slutligen fullt ut använda FOLIO och visa att det är ett system som fungerar i daglig verksamhet, att det inte är en utopi. ”What we need is not a proof of concept, but a proof of life”, som någon i FOLIO:s produktråd sa. Vi ska också demonstrera och berätta om systemets funktioner i olika sammanhang.
Det finns också i partnerskapets anda en delad vision. Vi ska vara föregångare och en inspirationskälla i FOLIO-communityn. Vi ska medverka till ett nytt ekosystem för bibliotekssystem, kultivera intressegrupper, bilda partnerskap och väcka intresse för att skapa nya tjänster och teknologier.
I betapartneravtalet var det viktigt för oss att det klart ut- trycktes att vi var fria att prata ärligt om våra erfarenheter. Vi vill inte behöva försköna eller dölja någonting. Vi har åtagit oss att tala på konferenser och möten som vi tillsammans med EB-