Tips vid extern leverantör

Att köpa Koha-support

Koha gör det möjligt att göra precis så mycket eller lite själv som man vill. Den som vill och har kunskapen kan göra allt själv medan de som vill eller behöver kan leja bort delar till en eller flera externa firmor. Globalt finns det på koha-community under “paid support” över 60 listade företag[1] som säljer olika tjänster kring Koha. Notera dock att listningen inte innebär någon kvalitetssäkring utan bara listar vilka företag som anmält att de jobbar med Koha. Som ny med Koha kan det vara lite okänd mark att jobba med ett system som inte ägs av någon enskild leverantör med utsända försäljare som tar hand om allting - därför kommer här några tips på vägen:

Se till att alla är överens om vem som skall göra vad och hur. En kartläggning av systemlandskapet och processerna är aldrig fel och även om det är aktuellt att leja bort allt arbete behöver ni veta vad ni skall skriva avtal om.

Import - har ni återkommande importer av t.ex. bibliografiska poster, ändringar av poster, låntagare osv behöver ni titta på vilka alternativ som passar ert bibliotek. Koha sväljer glatt importer av MARC-poster kodade i UTF-8 via importverktygen som finns i systemet, men kan även importera utanför det synliga systemet eller importera enskilda poster via Z39.50. Det finns även importmöjligheter för låntagare om det exempelvis finns skolklasser eller andra låntagare som skall läggas in större antal samtidigt, där ni inte vill manuellt skapa en mängd konton. (Det går också koppla Koha till exempelvis ett AD men det är en separat diskussion.) Det skall noteras att Stockholms universitetsbibliotek med medel från Kungliga biblioteket har genomfört omfattande utveckling för att skapa import via OAI-PMH protokollet, som förhoppningsvis kommer finnas tillgängligt i kommande versioner av Koha.

Export - Vilken data skall ut ur systemet - hur och när? Det kan t.ex. vara fakturor som skall till ett ekonomisystem. Det finns exportfunktioner färdiga för vissa saker i systemet och för övriga saker kan du naturligtvis med hjälp av en SQL-rapport ta ut övrig information som behövs. Det går också att göra SQL-rapporter publika varpå de exponerar JSON-data som kan användas i t.ex. widgets eller visualiseringar av saker i exempelvis Opac.

Backup - Hur ofta skall backup tas, hur länge skall den sparas (här finns regler från datainspektionen att följa - det måste vara en tid baserad på verksamhetens behov och får inte spara “tills disken är full” eller liknande). Se också till att skilja på backup som en ev. konsult gör för att sköta driften enligt kontraktet och backup som ni kanske vill göra för att själva ha kontroll på er data. Se också till att kontrollera att backup-filerna faktiskt är ok och fungerar med jämna mellanrum. Kunden skall i alla händelser ha kostnadsfri tillgång till sin data på begäran. Enklast för leverantören är en databasdump som kan importeras direkt in i en annan installation, men är också tänkbart att exportera databasen eller delar av den till andra format som .csv o dyl. Exempel: Hylte låter leverantören sköta den backup som behövs för driften men får varje natt backup på databasen levererad till en kommunal filserver så att man oavsett vad som händer kan sätta upp en egen Koha-installation utan att tappa någon data om man får problem med leverantören.

Redundans - Vilken extra kapacitet vill ni ha standby. Det tål att fundera på hur pass kraftfull server som behövs för driften och om ni har en verksamhet som kräver att en backupserver kommer upp snabbt vid eventuella problem. Exempel: För Hyltes del blev det för dyrt med automatiserade system för att t.ex. starta en backupserver. Istället avtalades att problem åtgärdas manuellt och leverantören skall titta på automatisering vid återkommande problem.

Brandvägg - Varje server har ett program (eller en specialiserad fysisk burk som kör ett program) som kan övervaka och sortera i nätverkstrafiken. Här kanske ni t.ex. vill spärra vissa beteenden som kan överbelasta servern. En avsiktlig och uthållig attack är alltid lite svårt/dyrt att skydda sig mot ordentligt, men även sådant som en överentusiastisk indexerare kan orsaka problem med prestandan för andra användare. Ett tips kan vara att spärra snabbt återkommande identiska anrop (om någon t.ex. står och tänker med fingret på refresh-knappen vilket mycket snabbt ger väldigt många förfrågningar till servern).

Anpassningar av installationen - Kan ni ställa krav att få anpassningar gjorda på kodnivå i er installation körs standard-koha? Det bästa tipset är att så långt det är möjligt göra alla anpassningar med hjälp av befintliga systemparametrar, CSS, javascript (jQuery), med pluginsystemet osv. När det börjar ske ändringar på kodnivå ökar snabbt problemen med uppgraderingar. Att få in ändringar i koden bör så långt det alls är möjligt göras “uppströms”, dvs. genom att få ändringarna att bli en del av den officiella Koha-koden (vilket det går att läsa mer om på wikisidan Utveckling). Den processen kan ta tid så det är möjligt att avtala att nya patchar kan installeras på er server när de t.ex. uppfyller kravet “passed QA” (Quality Assurance) vilket betyder att de passerat den officiella kvalitetsgranskningen i Koha. Att installera sådana patchar kräver att er installation omvandlas till att använda systemet Git vilket kanske normalt inte utförs på en driftserver, men det är heller ingen stor sak. Behövs Git till er produktionsmiljö behöver det dock såklart avtalas med leverantören.

Tillgång till driftsmiljö - Skall ni ha tillgång till driftsmiljön? Koden ni kör finns tillgänglig publikt direkt genom koha-community.org (och eventuella ändringar bör ni också ha tillgång till från er leverantör) men skall ni ha tillgång direkt till servern? Stalltipset är att om organisationen inte har kunskapen att själva sköta sin drift och utveckling, behöver ni antagligen inte heller ha tillgång till driftsservern. Risken är för stor att man ställer till problem. Däremot kan det i vissa fall vara önskvärt, eller nödvändigt, att ha tillgång till driftservern för vissa saker, exempelvis om import eller exportfiler sparas direkt på servern. Där kan det dock räcka med tillgång till en filarea på driftservern, och inte full access. Fundera över vilka era behov är, och avtala därefter.

Testmiljö - Det är lämpligt att ha åtminstone en server för internt testbruk. Den kan gott ha lägre prestanda (om ni inte tänker göra just lasttester på den). Där kan ni labba med alla inställningar, testa ny jQuery-kod, ny CSS osv. Det också att labba med nya delar av systemet som ni tänker ta i bruk och kolla hur ändringar ser ut för användarna innan det går ut skarpt. När det är dags att uppgradera till en ny huvudversion är det lämpligt att testa koden på testservern först under en vecka eller två för att kontrollera att allt fungerar som avsett.

Kontroll över domännamnet - Sköts driften hos leverantören är det inte osannolikt att leverantören också erbjuder en adress enligt modellen bibliotekets-namn.leverantören.se eller liknande. Ett varningens finger kan höjas här. Det är bättre att ha ett domännamn som är unikt för kunden som t.ex. www.bibliotekets-namn.se. Då kan ni enklare byta leverantör utan att behöva byta adress. Naturligtvis kan leverantören hjälpa till med domännamnet, så länge ni själva är ägare av själva domännamnet och behåller kontrollen över det.

Plack - Det finns en teknik för servercachning som kallas Plack som ger avsevärt mycket bättre prestanda i Koha. Möjligen vill ni avtala om att testa/använda denna så att leverantören vet om det från början då den kan kräva viss extra insats och övervakning av servern.

Servicefönster - När får insatser som påverkar driften göras av leverantören och behöver denne säga till en viss tid i förväg? Det kan vara bra att t.ex. avtala att störningar skall anmälas av leverantören en vecka i förväg och förläggas till kvällstid.

Uppgraderingar - Kostnadsfria uppgraderingar är en rimlig policy då Koha i sig är gratis. Men vad som är värt mer diskussion är vem som styr vilken version som används. Är det verksamheten som skall be om uppgraderingar eller skall leverantören se till att installera senaste stabila version vartefter de kommer? Ett tips är att aldrig driftsätta första versionen en ett nytt Koha-släpp utan vänta en månad till första buggfixarna släppts. Exempelvis släpptes i november 16.11 och nyligen kom 16.11.1 som rättar en del viktiga buggar som smugit sig igenom

Uthållighet vid utveckling - Att utveckla nya funktioner i Koha eller rätta buggar bör som nämnts alltid göras “uppströms” om det är möjligt. Den processen beskrivs som sagt under Utveckling men det kan sägas att uthållighet är att rekommendera. Att få koden skriven är bara starten på resan. Sedan skall någon annan testa och godkänna den, den skall igenom den officiella kvalitetsgranskningen och sedan skall den pushas av release manager för nästa version. Har det gjorts ändringar som triggar mycket diskussion kan processen dra ut på tiden. För egenutförd utveckling finns risken att ni behöver korrigera koden flera gånger utifrån feedback och även få skriva om er kod för att passa nya ändringar i koden som hunnit släppas fram under tiden. När allt är klart och koden godkänd är det bara att vänta tills nästa halvårsversion, när nya funktioner släpps. Bugfixar däremot släpps på månadsbasis.

Det globala samarbetet har många fördelar men något att vara aktsam på är att göra sig beroende av programmerar som är t.ex. projektanställda, examensarbetare och liknande som inte har möjlighet att göra de relativt små insatserna en tid efter själva kodandet som kvalitetsgranskningen kräver för att faktiskt få utvecklingen i mål. Det är också svårt att avtala med befintliga leverantörer att någonting faktiskt skall in i Koha då de inte styr över detta.

Har ni inte egna anställda som gör utveckling är kanske den bästa kompromissen därför att istället diskutera hur man gör med community-processen direkt när ni beställer utveckling. Kanske kan ni avtala att leverantören ansvarar för att koden skall hålla kvaliteten att den passerar QA, men att ni diskuterar från fall till fall och använder löpande timmar om det visar sig att en patch fastnar i orimligt mycket diskussioner på Bugzilla eller behöver skrivas om flertalet gånger efter input från communityt eller kvalitetsgranskningen.

Mest farbart har det genom åren visat sig att vara en kunnig och engagerad kund som tillsammans med leverantören sätter en kravspec och ett tidsestimat för att färdigställa kod + sköta interaktionen med Koha:s community. Om någon märker att det kommer bli en större avvikelse i tidsåtgången drar man i bromsen och tar en diskussion kring om och i så fall hur man går vidare. Mindre fruktbart är ett fast pris då leverantören kommer att behöva ta överpris för att gardera sig för oförutsägbarheten som är inbyggd i all utveckling och distribuerade projekt i synnerhet.

Ärendehanteringssystem - Hur kommunicerar ni med leverantören? Vid akuta situationer bör direktkontakt kunna etableras via t.ex. telefon, men troligen vill ni att ärenden skall loggas i något mer formellt system. Epost är antagligen det sämsta alternativet då det fort blir rörigt. Bättre är då system som Pivotal tracker, Trello m.fl. som är byggda för att hålla det överskådligt vem som ansvarar för vad och vad statusen är på olika ärenden. Som kuriosa kan nämnas att eftersom Koha har en aktiv internationell chatkanal på IRC så kan man vänta sig att många leverantörer som jobbar heltid med Koha är lättast att nå med ett privat meddelande där vid akuta situationer.

Ansvar för felaktigheter - Att reda ut vilken typ av fel som faller under leverantörens ansvar (och inte) är viktigt. En rimlig hållning kan vara att leverantören inte har ansvar för buggar i koden eller felaktigheter i t.ex. översättning (då leverantören inte gärna kan ta ansvar för andras kod). Däremot bör leverantören ansvara för kvaliteten på de tjänster de själva säljer. Ansvarar leverantören för drift skall det finnas krav på kvaliteten i denna. Finns det supportansvar bör det finnas specificerat t.ex. hur snabbt de börjar jobba med ett nytt ärende osv. Det ni kan göra är också att specificera att leverantören har ansvar för att reda ut om det är leverantören som är ansvarig för ett problem eller om det är en befintlig bugg i Koha (leverantören bör då antingen kunna ge en länk till eller själva dokumentera en i Koha:s Bugzilla-installation)

Skadestånd - När kvaliteten på tjänsterna ni köper inte håller vad som utlovats i kontraktet är det rimligt att ni får någon form av ersättning. Här avses inte eventuella skadestånd vid en rättslig tvist vid kontraktsbrott utan lite mer vardagliga situationer som t.ex. nedsättning av årsavgiften med en viss procent om det varit vissa typer av störningar/eller viss omfattning på dem. Det kan dock vara klurigt att utforma de här reglerna på ett fruktbart sätt då t.ex. 99,9% upptid på servern låter bra på papper men en tiondels procent av ett år fortfarande är 8,76 timmars nedtid vilket kan vara mycket olägligt. Har ni avtalat en regel som innefattar hur lång en störning är, löper det vanligen från den tidpunkt kunden anmäler störningen tills dess att leverantören (korrekt) meddelar att störningen är avhjälpt. Gäller det regelrätt nedtid så kan ni också använda övervakning av servern som opartisk “skiljedomare” - det är ju en olägenhet för allmänheten om Opac ligger nere hela kvällen och natten även om bibliotekspersonalen inte upptäcker och anmäler förens på morgonen.

Integritetsskydd - Er leverantör kommer sannolikt vara PUL-ombud och ni bör reglera detta enligt gällande regler. Inom EU/Schengen är det oproblematiskt att lägga ut driften då det finns befintliga regler kring skyddet för personuppgifter att haka i. Men vänder ni er till en leverantör utanför EU/Schengen så är det mer komplicerat då ni själva behöver utreda att det finns skydd som är förenligt med våra lagar. Notera dock att det går utmärkt att lägga ren utveckling i vilken världsdel som helst då det är just personuppgifter man behöver skydda - att någon utvecklar kod med hjälp av exempeldata i en annan världsdel är mindre knivigt.

Valuta - En rent praktisk fråga är vilken valuta priserna skall räknas i. De flesta leverantörer torde vilja ha betalt i sitt eget lands valuta.

Uppsägning - Vad som gäller vid uppsägning behöver naturligtvis regleras. En uppsägningstid på 3 månader vid uppsägning av kund och på 6 månader vid uppsägning av leverantör kan vara en utgångspunkt för diskussion. Naturligtvis skall all kundens data ägas av kunden och exporteras kostnadsfritt åt kunden vid avslut av kontraktet. Likaså skall alla speciella anpassningar som gjorts åt kunden ha dokumenterats och denna dokumentation vara tillgänglig för att underlätta vid byte av leverantör. Att leverantören skall samarbeta vid överlämning till en ev. ny leverantör är också rimligt att skriva in i kontraktet.

Kringtjänster - När det gäller tjänster som t.ex. SMS eller betallösningar som kräver extra avtal med andra aktörer, vilket ansvar vill ni att leverantören skall ha att hjälpa er med detta? Här varierar hur leverantörerna gör. Vissa erbjuder sig att sköta sådana avtal åt er och fakturerar vidare medan andra helst vill att ni själva avtalar med tredjepart. Här kan vara läge att samråda med den egna juristen/upphandlingsenheten och se vad som är möjligt.

Möjlighet att använda andra konsulter - I standardkontrakt förekommer klausuler som reglerar kundens möjlighet att ta in andra kompetenser. En rimlig hållning är att man som kund skall vara fri att ta in vilka firmor man vill för att t.ex. utveckla nya funktioner i Koha men att koden inte driftsätts på huvudleverantörens server innan koden åtminstone passerat Koha:s QA-team. Vidare är det rimligt att man inte släpper in externa företag på leverantörens server hur som helst utan att man kommer överens om att ta in externa krafter för specifika uppgifter.

Prismodell - Vad man tar betalt för och hur varierar mellan olika firmor. Gemensamt är att det inte är Koha per se som ni betalar för utan leverantörens tid och kunskap. För folkbiblioteken i Norden är det inte ovanligt att man har avtal med en leverantör som har modellen att drift + fria uppgraderingar är en baskostnad som står i proportion till antalet exemplar i katalogen. När fel uppstår ingår all kommunikation kring detta i den fasta kostnaden och räknas inte mot ev. timbank med supporttimmar. Utöver detta kan sedan konsulttimmar bokas upp i förväg på årsbasis, ofta till ett starkt rabatterat pris, för att sköta användarsupport och/eller utveckling. I regel är det i början som man behöver support medan man följande år kan lägga sådana timmar på utveckling.

Utbildning - Hur gör ni med grundträning av personalen? Det går att komma långt med att ha återkommande korta workshops under tiden som implementation av Koha sker där det är möjligt att gå igenom systemets funktioner med personalen. Då hinner de bli bekanta med systemet och repetera. En del bibliotek har haft leverantören eller någon tredje part som varit och utbildat antingen hela eller delar av personalen, exempelvis en projektgrupp.

I vilket land skall tvister avgöras - En inte särskilt uppenbar men ändå viktig fråga om företag utanför Sverige ska användas är att reglera i kontraktet i vilket lands domstolar eventuella tvister skall avgöras. Här kan vara läge att prata med jurist då det inte är uppenbart vad som faktiskt kan avtalas, men i de flesta standardavtal anges att svenska lag ska råda (och godtas också av många leverantörer).