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 har någon enskild firma 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 man lejer bort allt arbete behöver man veta vad man skall avtala om.

Import - har man återkommande importer av t.ex. bibliografiska poster, ändringar av poster, låntagare osv. 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 man t.ex. Skolklasser eller andra låntagare som skall läggas in större antal samtidigt och man inte vill manuellt skapa konton. (Man kan också koppla Koha till exempelvis ett AD men det är en separat diskussion). Det skall noteras att SUB har genomfört omfattande utveckling för att skapa import från OAI-PMHservrar.

Export - Vilken data skall ut ur systemet - hur och när? Kan vara t.ex. fakturor som skall till ekonomisystem. Det finns exportfunktioner färdiga för vissa saker i systemet och för övriga saker kan man naturligtvis med hjälp av en SQL-rapport ta ut övrig information man behöver. 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 t.ex. Opac.

Backup - Hur ofta skall backup tas, hur länge skall den sparas (här finns regler från datainspektionen att följa - man måste ha 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 man kan också tänka sig att man exporterar 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 man ha standby. Det tål att fundera på hur pass kraftfull server man vill drifta på och om man 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 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 man vill t.ex. 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 eller kör man 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 man börjar göra ändringar på kodnivå ökar man 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 är en separat artikel). Den processen kan ta tid så man kan t.ex. avtala att nya patchar kan installeras på er server när de t.ex uppfyller kravet “passed QA” 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 man kanske normalt inte gör på en driftserver, men det är heller ingen stor sak.

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 man inte har kunskapen att lika gärna sköta sin drift och utveckling själv skall man heller inte ha tillgång till driftsservern. Risken är för stor att man ställer till problem. Å andra sidan betyder det att ni behöver avtala om tillgång till vissa saker som om någon exportfil sparas direkt på servern och liknande. Vi vet att det finns vissa sådana fall men kan tyvärr inte lista dem direkt ur huvudet.

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

Kontroll över domännamnet - Driftar man 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 man enklare byta leverantör utan att behöva byta adress. Naturligtvis kan leverantören hjälpa till med domännamnet så länge man ser till att man själv ä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 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 man kör. Ä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 går. Den processen är som också sagts värd en artikel i sig 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 QA och sedan skall den pushas av release manager för nästa version. Har man gjort ändringar som triggar mycket diskussion eller om man är ovan och behöver korrigera koden flera gånger kan processen dra ut på tiden och man riskerar att få skriva om sin 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 får man vänta tills nästa halvårsversion innan nya funktioner släpps. Bugfixar däremot släpps på månadsbasis.

Det globala samarbetet har många fördelar men skall man nämna saker att vara aktsam på så är det 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 faktiskt får 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 man 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 man beställer utveckling. Kanske kan man avtala att leverantören ansvarar för att koden skall hålla kvaliteten att den passerar QA men att man 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 kring sådant som är andra utvecklare personliga preferenser, eller om man t.ex. har ändrat riktlinjerna för hur man kodar eller bytt något tredjepartsbibliotek centralt i Koha-projektet som leverantören inte kunde förutse när man började utvecklingen.

Mest farbart har det genom åren visat sig att vara med 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 communityt. 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 man själv säljer. Ansvarar man för drift skall det finnas krav på kvaliteten i denna. Har man supportansvar bör det finnas specificerat t.ex. Hur snabbt man börjar jobba med ett nytt ärende osv. Det man 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 (denna bör man då antingen kunna ge en länk till eller kräva att leverantören dokumenterar i Kohas Bugzilla-installation)

Skadestånd - När kvaliteten på tjänsterna man köper inte håller vad som utlovats i kontraktet är det rimligt att man 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 när man haft 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 man en regel som innefattar hur lång en störning är räknar man lämpligen störningen 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 man 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 man sig utanför EU/Schengen så är det mer komplicerat då man själv 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ärdsdel man vill då det är just personuppgifter man behöver skydda - att någon utvecklar kod med hjälp av exempeldata i en annan värdsdel ä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 om man byter 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 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. 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 Kohas 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 man 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 man köpt. Utöver detta kan man sedan boka upp konsulttimmar i förväg på årsbasis 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? Man kommer långt med att ha återkommande korta workshops under tiden man förbereder för övergången där man går igenom systemets funktioner. Då hinner personalen bli lite bekant med systemet och repetera. En del har haft leverantören eller någon tredje part som varit och utbildat antingen hela personalen eller en projektgrupp.

I vilket land skall tvister avgöras - En inte särskilt uppenbar men ändå viktig fråga om man använder företag utanför Sverige ä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.

[1] https://koha-community.org/support/paid-support/continent/ [2016-12-29]