2011-03a Pienryhmä 29.6.2011 - muistio

Elokuun kokouksen valmistelukokous

Aika: 29.6.2011 klo 9.20 - n. 12.00

Paikka: Kansalliskirjasto, Fabianian auditorio

Osallistujat:

• Esko Ala-Peijari (n. klo 11.00 asti)
• Nina Hyvönen
• Tommi Jauhiainen
• Sinikka Luokkanen (pj)
• Jarmo Saarti (etäyhteydellä)
• Lassi Lager (siht.)

MUISTIO

1. Elokuun kokouksesta

Valmisteluryhmän elokuun kokousaika on vielä sopimatta. Tällä hetkellä ma 22.8. ja pe 26.8. ovat saaneet eniten kannatusta, äänestys: http://doodle.com/92t57nvg8d2igpea. Yleisistä kirjastoista ei ole vielä vastauksia, Lassi muistuttaa kyselystä. Kokous voidaan pitää myös etäkokouksena, jos se saadaan valmisteltua hyvin (silloin kesto max 3 tuntia).

ELOKUUN KOKOUKSEN ASIALISTAA:

• varapuheenjohtajan valinta
• keskustelua wikistä ja tiedottamisesta. Esitys: wikien katseluoikeudet avataan kaikille, työskentelyyn osallistujille päivitysoikeudet (suljettu alue voidaan pitää varuilla)
• saadaanko jo sellaista tekstiä mitä tässä kohtaa voitaisiin lähettää OKM:ään?
• työryhmien toimeksiannot (muotoillaan lopullisesti elokuun kokouksessa)
• aikataulut (projektisuunnitelman ja hankkeen aikataulut)
• Kartturi-malli (toistaiseksi luonnos)
  

Työryhmien toimeksiantoja ja muita elokuun kokoukseen liittyviä asioita työstetään vielä tällä porukalla wikissä mahdollisimman valmiiksi yhdessä (Jarmolle laitetaan sähköpostissa viestiä, mitä pitäisi kommentoida)

2. Kartturi-malli

Korkeakoulusektorilla uudet järjestelmähankinnat täytyy (tai ainakin kannattaa) tehdä Kartturi-mallin mukaisesti.

Keskusteltiin Kartturi-mallissa olevasta korkeakoulujen kokonaisarkkitehtuurikehyksestä (Kartturi-kehys):

• Kartturimalli 2.0:n päädokumentin liite 1. KA-kehys (luonnos) http://raketti.csc.fi/kokoa/pilotti/Liite1_Kartturi-kehys_v2_0 (luku 2.2 Kartturi-kehys, s. 9-)

Jäsennettiin projektisuunnitelmaluonnosta tämän viitekehyksen pohjalta:

• Toiminta-arkkitehtuuri
• Tietoarkkitehtuuri
• Tietojärjestelmäarkkitehtuuri
• Teknologia-arkkitehtuuri

3. Projektisuunnitelman teko: aikataulu, resurssit, halutut tulokset, miksi tätä tehdään?

Projektisuunnitelman teko (valmisteluryhmän toimeksianto) vaatii myös oman projektisuunnitelman, josta näkyy aikataulu, tavoitteet (mitä tuloksia halutaan vuoden päästä) ja resursointi. Valmisteluryhmän työhön osallistuvien (myös "ulkoiset asiantuntijat") täytyy pystyä sopimaan työhön käytetyt resurssit myös omassa organisaatiossaan.

Projektisuunnitelmassa pitäisi näkyä, miksi tätä tehdään (miksi esim. Voyager "ei olekaan hyvä" jne), mitä palveluita tämän hankkeen ajatellaan kattavan. Siihen tulee sisällyttää järjestelmäympäristön kuvaus ja mitä tämä hanke siitä kattaa - mitä tähän kannattaa sisällyttää ja mitkä palikat hoituvat muilla järjestelmillä. Nämä asiat, ja muutenkin hankkeen strategiset tavoitteet, tulisi tehdä selväksi myös sidosryhmillle.

Sekin pitää miettiä, halutaanko kaikille yhteinen kirjastojärjestelmä, vai järjestelmä joka muokataan kaikille (sektoreille / kirjastoille) niiden tarpeiden mukaiseksi.

Uuden kirjastojärjestelmän hankinta -projekti

• Projektin aikataulu piirretään kaaviona (Kartturi-malli viitekehyksenä)
• Tämän hankkeen tiimoilta sektorien ja erilaisten kirjastojen pitäisi joka tapauksessa tehdä yhdessä ohjelmistoselvitystä.
• Haaste: tehdä yksi yhteinen järjestelmä jota räätälöidään eri tarpeisiin ja pystytään yhdistämään myös olemassa oleviin palikoihin (standardien) rajapintojen avulla.
• Projektiin (valmistelutyöhön) tarvitaan inputia laajasti eri kirjastoilta (kyselylomake?)
• Esko: IT-puolella on tehty benchmarking-projekti jota voidaan ehkä hyödyntää.
• Toimeksiantoa ei välttämättä tarvitse muokata

• JUREa ja uutta kirjastojärjestelmää pitää katso vähän yhteen. 
• kirjastojärjestelmän kehittäminen myös JUREn tarpeita varten?

 Projektisuunnitelman aikataulusta

• Jos seuraava laaja kokous pidetään tammikuussa, marraskuussa pitäisi olla valmiina jonkinlainen toimintaympäristökuvaus.
• Swot-analyysi nykyisistä järjestelmistä: Linnea-työryhmille toimeksianto elokuun kokouksessa
• Nykytilan kuvaus, IT-puolen benchmarkin-tavalla, valmiiiksi syksyn aikana, jolloin olisi tammikuun kokouksessa valmiina
  • Jure-hankkeessa jo tehty kuvauksia, voi käyttää mallina
• Aikataulu työryhmille: syyskuu - maaliskuu. Huhti-toukokuussa valmisteluryhmä kokoaa kaiken kasaan.

Tiedottaminen / wikit

• Elokuun kokouksessa voisi avata katseluoikeudet kaikille.
• Päivitysoikeudet työhön osallistuville.
• Työryhmät voivat muokata toimeksiantoaan ja muutkin näkevät, samalla siellä määritellään kuka hoitaa minkäkin osuuden

Kustannuslaskenta

• kirjastoissa ei ole tehty kattavasti, mutta selvitetään jos jotain lukuja saisi, esim. järjestelmiin liittyvään työhön käytettyjä henkilötyövuosia.
• esim. julkaisuviitetiedon tai luetteloidun tietueen hinta?

4. Toiminta-arkkitehtuurista

• Jarmo: lainaus on erilaista korkeakoulu- ja yliopistokirjastoissa, luettelointi toivottavasti ei
• Jos prosessit ovat yhteisiä (niistä saadaan jonkinlainen konsensus aikaiseksi), yhteinen järjestelmä on mahdollinen.
• Mitä järjestelmällä halutaan tehdä? Prosessit ja tuotteet, esim. Linnea-työryhmät mukaan
• Erikoiskirjastojen ja yleisten neuvostojen kanssa pitäisi keskustella, miten he ovat mukana.
• Käyttötapaukset, esim. asiakastietojen syöttäminen tietokantaa: mitä tehdään käsin, saadaanko jotain valmiiksi jostain.
• Kirjastoilla jo on tehtykin prosessikuvauksia (taustaksi). Prosessikuvaukset usein riippuvaisia käytössä olevasta ohjelmasta.
• Yliopistokirjastojen prosessikuvauksia (voidaan hyödyntää tässä): http://www.kansalliskirjasto.fi/kirjastoala/neuvosto/hankkeet/laatujavaikuttavuus.html
  

Prosessit

• Esim. hankinta: ketkä sitä käyttävät ja miten: pitäisi muokata yksi näkemys, vaikka tapauksia onkin erilaisia.
  
• Eri prosessien (esim. kirjastoauto) tarve nyt ja tulevaisuudessa? Nykyistä järjestelmää ja sen prosesseja ei pitäisi liikaa ajatella.
• Painetun aineiston lainaus: jossain muutama päivässä, jossain yksi minuutissa.
• Sisällönkuvailu: e-kirjoissa ym. ei yleensä saadaan valmiina, käyttäjätkin kuvailemaan. Ei pidä hankkia päällekkäisiä järjestelmiä huolehtimaan samoista toimenpiteistä

Käsitteet

Esko totesi, että Raketti-hankkeessa on tavoitteena mm. saada korkeakoulujen yhteinen käsitteistö mahdollisimman kattavasti. Keskeiset käsitteet täytyy määritellä yhdessä, esim. niin että "lainaus" tarkoittaisi kaikille samaa, konsensus täytyy saavuttaa.

Käsitemalli, esim. asiakastiedot: ei välttämättä tarkoita, että tiedot naputellaan tietokantaan vaan ne voidaan myös hakea valmiina jostain (jatkossa opiskelijatiedot suoraan väestörekisteristä - tiedot käytettävissä maksutta julkishallinnon sisällä.). Henkilöiden erilaiset identiteetit aiheuttavat haasteita: samalla asiakkaalla voi olla monta erilaista henkilökuntastatusta (eri korkeakouluissa), opiskelijastatus, yleisen kirjaston asiakas -status jne. Erilaiset roolit pitäisi hallita.

Yksi työryhmä voisi miettiä pelkästään käsitteitä. Tarkoituksena  on saavuttaa yksimielisyys siitä, mitä mikäkin tarkoittaa. Käsitteitä miettivää ryhmää ei ehkä tarvitse määritellä vielä elokuun kokouksessa. Hyödynnetään jo olemassa olevia kirjasto- ja it-alan käsitteitä. Kansalliskirjasto (Ninan putiikki) voi kartoittaa kirjastoalan käsitteitä. Kirjasto- ja atk-puoli hyvin standardoitu, eikä olemassa olevia käsitteitä kannata keksiä uudelleen.

Toimeksiannot Linnea- ym. työryhmille: toiminnallisen ympäristön kuvaukset

• Analyysi nykyisyydestä sillä logiikalla, mikä toimii ja mikä ei, ja tulevaisuuden mallintaminen. Työssä tarvitaan riittävän erilaisia ihmisiä riittävän erilaisia järjestelmiä käyttävistä kirjastoista.
• Minkä muotoisena halutaan vastaus? Swotia nykyisestä + tulevaisuus eri käyttötapauksittain?
• Mieluummin ytimekkäitä kuvauksia kuin pitkiä selvityksiä nykytilanteesta eri kirjastoissa.
• Ei niinkään prosessikaavioita kaikenlaisista eri tilanteista, vaan käyttötapauskuvauksia. Helpottaisivat esim. uuden järjestelmän arvioinnissa ja kilpailutuksessa.
• Jossain vaiheessa muitakin sektoreita mukaan. Ehdotettiin, että Linnea-työryhmiin voitaisiin kysyä tähän työhön jo syksyn aikana myös yleisten (ja erikois-) kirjastojen edustajia mukaan. Voisivat halutessaan osallistua.
• Toimeksiantoon kaikille ryhmille myös tarvittavia rajapintoja esimerkinomaisesti ja kuhunkin toiminnalliseen ympäristöön liittyvät tilastointiasiat
• Elokuun kokouksessa nimetään henkilöt, jotka vetävät/joiden vastuulla nämä toimeksiannot (toimeksiannot eivät noudata täysin työryhmien rajoja) 

Ryhmät ja niiden käsittelemät toimintaympäristöt:

• Luettelointi: Hankinta- ja luettelointiryhmän luetteloijat (pj Maria Kovero)+ Kirjastoaineistojen kuvailun ohjausryhmä (pj Tuula Haapamäki)
  • valmistelu tehtäisiin näiden ryhmien vetäjien vetovastuulla, mukaan nykytilanteen lisäksi tulevaisuus: RDA-malli, tunnisteet, ontologiat yms. - pelkästään vanhan pohjalta ei voida lähteä.
  • jo tätä ennen Kansalliskirjastossa voitaisiin pohjustaa näkemystä, minne ollaan menossa (luetteloinnin tulevaisuuden näkökulmat). Ideaalimalli: kaikista Kansalliskirjastoista saadaan lähitulevaisuudessa valmista FRBR/RDA-mukaista dataa. Todellisuudessa näin ei ehkä kuitenkaan ole. Luettelointiin kokonaisuudessa käytetään todella paljon henkilötyövuosia, mikä kannattaa huomioida toiminta-arkkitehtuurissa. Tässä voisi myös säästää (perusteena hankkeelle). 
  • Lindan laaturyhmälläkin voisi tarvittaessa olla tässä rooli (laaturyhmää täytyy täydentää syksyllä eläköitymisten vuoksi). 
• Lainaus ja kaukopalvelu (mietitään molempia yhdessä). Lainauksessa esim. rajapinnat kassajärjestelmiin?
• Hankinta (luetteloiryhmästä erotettuna).Tässä lähinnä painetun aineiston yms. hankinta. Jarmo Saarti halusi, että uudella järjestelmällä saadaan hoidettua sekä painetut että sähköiset kausijulkaisut. Tarvetta hyvälle työkalulle on (Halti ei pysty hoitamaan nyt kaikkea)
• Kausijulkaisujen hankinta (erikseen): painetut ja e-kausijulkaisut, Halti-kuviot ym., FinElib-edustus mukana. Myös talous ja saapumisvalvonta.
• OPAC- ja systeemiryhmä
  • hyödynnetään teknologian kuvauksessa
  • muiden ryhmien työn kommentoiminen, katsovat vähän kokonaisuutta
  • asiakaskäyttöliittymää ja tiedonhaku ei käsitellä tässä toimeksiannossa

• Hallinnolliset järjestelmät
  • Opetus- ja taloushallinto? kuka katsoo näitä?
• Kaikissa ryhmissä mietitään rajapintoja muihin järjestelmiin ja tilastointia 

Tilastointi (kaikilla ryhmillä)

• standardit
• pitää pystyä hoitamaan myös paikallisten kirjastojen paikalliset tilastointitarpeet, jotka eivät välttämättä aina standardien mukaisia
• Markku Laitista hyödynnetään tarvittaessa, mutta ym. ryhmillä kuitenkin päävastuu näiden miettimisessä.
• Järjestelmästä pitäisi saada tilastoa myös toisten mielestä epärelevanteista asioista

5. Aikataulu (projektisuunnitelmaan)

Hankkeen kuvaus Kartturi-mallin pohjalta ja vaiheistus (aikataulujana): Tästä pääluvut, lisäksi alavaiheet/alakohda, myös mitä osia tähän kuuluu

Päävaiheet (aikataulujanaan 2011 ... 2014)

Toiminta-arkkitehtuuri

• palvelut, prosessit. Aikataulujanassa 5 v. visio -->
• tässä voisi kuvailla myös asioita joita ei nyt hoideta automaattisesti
• strategia, toiminnan haasteet & tavoitteet, palvelut, sidosryhmät & roolit:
  • kuka näitä miettii?. Alkuvuoteen keskustelutilaisuus? Sitoutuminen tärkeää, koko kenttä pitäisi saada keskustelemaan yhdessä
  • tammikuussa työvaliokuntia yms.
  • raportin valmistuttua voisi kutsua johtajia laajemmin koolle
  • wikiin ideoita, millä porukalla tätä?
    

Tietoarkkitehtuuri

• kootaan käsitteet -> analyysi -> sovitaan yhteiset käsitteet -->

Tietojärjestelmäarkkitehtuuri

• kartoitus ohjelmista -> analyysi -> ratkaisuvaihtoehdot -->

1. analyysi: minkälainen toimintaympäristö on 3-5 vuoden päästä, mitä tarvitaan? Pitääkö tehdä itse vai onko olemassa jotain? (Mitkä tuotteet on hyviä?)
2. swot-analyysi nykyisestä järjestelmä(kokonaisuude)sta, mikä toimii, mikä ei (tämä voisi olla työryhmien toimeksianto). (Tämä on vähän kirjastokohtaista, vaikka korkeakoulukirjastoilla on Voyager, käyttävät vähän eri tavalla: mitkä palvelut missäkin käytössä, jne.

Teknologia-arkkitehtuuri

• Valmistellaan pienemmällä porukalla, tätä työstämään Kansalliskirjasto (Tommin porukat) + valmisteluryhmän  it-puoli
• nykytila, laitteiden (ja ohjelmistojen) elinkaari -> analyysi  -> 2013? -->
• milloin nykyiset järjestelmät "kuoleentuvat", milloin on pakko hankkia uusia järjestelmiä (eri kirjastoissa)? Milloin palvelimet vanhenevat
• Asiakasliittymä lähtökohtaisesti KDK-asiakasliittymä. 2012 alussa tarkistetaan tilanne.