ARENE ry:n tietohallintohanke

Transkriptio

1 ARENE ry:n tietohallintohanke Määrittelyprojekti ProAMK II-vaiheen loppuraportti

2 1. Hankkeen taustaa Hankkeen toimijat, keskeinen toiminta ja tavoitteet Keskeinen toiminta sekä hankkeen tulokset Tavoitteiden toteutuminen suhteessa projektisuunnitelmaan Projektin toteutunut kustannusarvio Etenemissuunnitelma Toimenpide-ehdotukset Projektin tulosten hyödyntäminen jatkossa Julkisuus ja tiedottaminen Liitteet...51 Orama Tuomas, projektipäällikkö, ProAMK Elsinen Eero, hallinto- ja talousjohtaja, PKAMK Harjulahti Eeva, lehtori, TUAMK Ikonen Petteri, Tutkimusjohtaja, Laurea Kailu Minka, projektisuunnittelija, ProAMK Koivukoski Pekka, tietohallintopäällikkö, OAMK Laakkonen Raijaliisa, vararehtori, VAMK Paturi Tuulikki, johtaja, Haaga-Helia Pitkäranta Timo, tietojärjestelmäpäällikkö, VAMK Puumala Tuukka, tekninen asiantuntija, ProAMK 2

3 1. Hankkeen taustaa ARENE ry:n tietohallintohankkeen määrittelyprojekti ProAMK:n loppuvaiheessa todettiin, että työtä on syytä jatkaa alkuperäisten tavoitteiden saavuttamiseksi ja tuotantovaiheen käynnistämiseksi vuoden 2008 alusta. Ensimmäisen vaiheen esiin tuomat haasteet tulisi pyrkiä ratkaisemaan, jotta voitaisiin tehdä päätöksiä tulevaisuuden suhteen. Projektin ohjausryhmä teki esityksen II-vaiheen käynnistämiseksi ARENE ry:lle ja opetusministeriölle. Kaikki ensimmäisessä vaiheessa mukana olleet ammattikorkeakoulut sekä opetusministeriö sitoutuivat osallistumaan projektin kustannuksiin. Projektin kestoksi sovittiin Hankkeen toimijat, keskeinen toiminta ja tavoitteet 2.1 Projektin toimijat Hankkeen ohjausryhmä päätti, että ensimmäisen vaiheen projektiryhmä jatkaa myös toisen vaiheen projektiryhmänä ja että projektille palkataan projektipäällikön ja suunnittelijan lisäksi tekninen asiantuntija vastaamaan teknisistä selvityksistä. Budjettiin varattiin lisäksi varoja ulkopuolisten asiantuntijapalveluiden ostamiseksi. Projektiryhmästä jäivät pois Lena Siikaniemi ja Rauno Pirinen. Petteri Ikonen nimitettiin projektiryhmän jäseneksi. 2.2 Projektin tavoitteet Projektin johtoryhmän 30.8 hyväksymässä projektisuunnitelmassa asetettiin seuraavat tavoitteet: 1. Aloitetaan ProAMK I -vaiheessa määriteltyjä toimintaprosesseja palvelevan soveltuvin osin keskitetyn, modulaarisesti ja vaiheittain toteutettavan tietojärjestelmän toteutuksen suunnittelu. 3

4 2. Johtoryhmän johdolla selvitetään tarkemmin eri ratkaisuvaihtoehtoja alla mainitun tietojärjestelmän toteuttamiseksi esitettyjen ratkaisuvaihtoehtojen pohjalta. 3. Johtoryhmän johdolla aloitetaan organisaatiomallin sekä liiketoimintaratkaisun määrittely yhdessä sidosryhmien kanssa erillisyksikkö-mallin pohjalta. 4. Selvitetään yhteistyömahdollisuuksia yliopistojen kanssa. 5. Sovitaan hankkeen vaiheistuksesta ja aloitetaan sovittavan priorisoinnin mukaisesti kuvattujen prosessien mallinnus tietojärjestelmätasolle. 6. Selvitetään mahdollisuus hyödyntää eri tahoilla tuotettuja tukisovelluksia tietojärjestelmän moduulien kehityksessä. 7. Jatketaan sanastotyötä tavoitteena sanaston ja termien vakiinnuttaminen osaksi toimintaa ja liittäminen osaksi opetusministeriön käsiterekisteriä. Lisäksi projektiryhmälle annettiin tehtäväksi laatia etenemissuunnitelma, josta käyvät ilmi ehdotus vaiheittaiseksi etenemiseksi, etenemisen organisointi, kustannukset sekä riskit. Toimenpiteitä tavoitteiden saavuttamiseksi sekä arviointia tuloksista suhteessa asetettuihin tavoitteisiin käsitellään tarkemmin kohdassa Keskeinen toiminta sekä hankkeen tulokset Tekniset selvitykset Projekti kilpailutti asiantuntijapalveluita seuraavilla osa-alueilla: 1 Asiantuntijapalvelu tukemaan yleisarkkitehtuurin suunnittelua tietojärjestelmälle, joka toteuttaa ProAMK I -projektissa kuvatut palveluprosessit. Kuvaus määritellään palvelukeskeisen arkkitehtuurin (SOA) ajatusmallin mukaan, ja siinä määritellään järjestelmän jako moduuleihin ja moduulien sisäinen ja ulkoinen vuorovaikutus rajapintojen avulla. Arkkitehtuuria suunniteltaessa huomioidaan mahdollisuudet toteuttaa tietojärjestelmä kokonaan keskitettynä, osittain keskitettynä tai eri korkeakouluihin hajautettuna. Asiantuntijapalvelun toimittajaksi valittiin Appelsiini Oy. Toimeksiannon sisältö: Arkkitehtuurisuunnitelmassa kuvataan yleisarkkitehtuuri tietojärjestelmälle, joka toteuttaa ProAMK I -projektissa kuvatut palveluprosessit. Suunnitelmassa tulisi käydä ilmi: - millaisista moduuleista järjestelmä koostuu 4

5 - miten moduulit kommunikoivat keskenään, ja miten tätä kommunikointia hallitaan (esimerkiksi miten lisätään uusia moduuleja) - mikä olisi teknisestä näkökulmasta järkevä keskittämis-/hajauttamisaste o täysin hajautettu: jokaisella AMK:lla oma asennus järjestelmästä omilla palvelimillaan o täysin keskitetty: yksi järjestelmän asennus ja tietojen säilytyspaikka yhteisellä ylläpitäjällä o välimuoto: osittain keskitetty, osittain hajautettu Tulokset: Raportissaan Appelsiini on esittänyt kolme mahdollista toteutusvaihtoehtoa: 1. Ammattikorkeakouluilla yhteinen tallennuskerros Mallissa ammattikorkeakoulut jakavat ainoastaan tallennuskerroksen. Ammattikorkeakoulut jakavat tietoa toisilleen liiketoimintakerroksen kautta, jolloin rajapintojen hallinnoinnin määrä kasvaa. Käyttökatko yhden ammattikorkeakoulun liiketoiminta- tai näkymäkerroksessa ei haittaa muiden ammattikorkeakoulujen toimintaa. Ongelmat - Riskinä hallitsematon rajapintojen käyttö ja sekava kokonaisuus - Yhteisten moduulien päivitys hankalaa - Siirtymävaiheet hankalia - Vaatii paljon koulutettua henkilökuntaa - Moduulien eri versioiden ajo rinnakkain hankalaa - Uudelleenkäytön edut menetetään - Hallinnollisuus monimutkaistuu Hyödyt - Yhden järjestelmän kaatuminen ei niin kriittistä kuin muissa malleissa - Mahdollisuus kehittää prosesseja joustavammin, koska ammattikorkeakoulut hallinnoivat omaa liiketoimintakerrosta 2. Ammattikorkeakouluilla yhteinen liiketoimintakerros Mallissa ammattikorkeakoulut jakavat tallennus- ja liiketoimintakerroksen. Rekisterit ja prosessit ovat samoja riippumatta ammattikorkeakoulusta, jolloin hallinnoinnin määrä vähenee. Ammattikorkeakoulut voivat tehdä erilaisia räätälöintejä käyttöliittymään ilman käyttökatkoja muiden ammattikorkeakoulujen toiminnassa. 5

6 Ongelmat - Käyttöliittymiin voidaan ohjelmoida liikaa liiketoimintalogiikkaa, jolloin kokonaisuudesta tulee sekava, SOA-malli rikkoutuu - Integraatiopalvelimelle tulee liikaa kuormaa, esim. huolimattoman käyttöliittymän ohjelmoinnin takia Hyödyt - Voidaan luoda uusia näkymiä suhteellisen helposti. - Trendi kehittää omia portaaleita, malli helpottaa. 3. Ammattikorkeakouluilla yhteinen asennus Mallissa ammattikorkeakouluilla on yhteinen asennus. Yhtä asennusta käyttää suuri määrä käyttäjiä, joten käyttökatkot ovat kriittisempiä kuin muissa malleissa. Järjestelmän päivitys voidaan tehdä yhdellä kertaa. Ongelmat - Uusien palveluiden kehitys voi hidastua - Häiriötilanteet vahingollisempia - Yhdellä näkymällä ei pystytä palvelemaan kaikki oppilaitoksia - Oppilaitoksilla on myös toiminnallisia eroavaisuuksia - Byrokraattinen ja jäykkä Hyödyt - Ainoastaan yksi hallittava kokonaisuus Appelsiini suosittaa toteutettavan järjestelmän perusarkkitehtuuriksi palveluarkkitehtuurin mukaista keskitettyä järjestelmää. Järjestelmän moduulit tarjoavat palveluita, joita muut moduulit voivat käyttää. Rekisterit ja prosessit ovat samoja riippumatta ammattikorkeakoulusta, jolloin asennusta ja rajapintojen käyttöä on helppo hallita keskitetysti. Ammattikorkeakouluilla saattaa olla tarvetta hakea järjestelmästä tietoa omiin järjestelmiin tai koostaa uusia näkymiä järjestelmän palveluihin. Järjestelmä tarjoaa rajapinnan liiketoimintakerrokseen, joka palvelee näitä tarpeita joustavasti. 2. Asiantuntijapalvelu tukemaan tietojärjestelmän palveluiden suunnittelua käyttäjänäkökulmasta. Palvelut suunnitellaan toteuttamaan ProAMK I -projektissa kuvatut prosessit. Asiantuntijapalvelun toimittajaksi valittiin WM-Data Oy. 6

7 Toimeksiannon sisältö: Palvelusuunnitelma on korkean tason suunnitelma siitä, millaisiin palveluihin ProAMK I - prosesseja kuvaava järjestelmä on jaettu. Suunnitelman tulisi sisältää: - järjestelmän käyttäjäryhmät ja käyttötapaukset karkealla tasolla - millaisilla palveluilla käyttötapauksia toteutetaan - missä järjestyksessä eri palveluita pitäisi alkaa toteuttaa - millä tavalla käyttötapauksien ja palveluiden määrittelyä tarkennetaan ennen toteutusvaihetta tai toteutuksen rinnalla Tulokset Projektista tai WM-Datasta riippumattomista syistä työskentely pääsi alkamaan suunniteltua myöhemmin ja tehtäväkentän laajuudesta johtuen päädyttiin ratkaisuun, jossa projektin päättymisestä huolimatta WM-Data vie sovitut tehtävät loppuun tammikuun puoleen väliin mennessä. Tässä raportissa ja sen liitteenä ovat mennessä tuotetut karkean tason käyttötapaukset ja ehdotukset palveluiden tuottamisesta ja niiden jaottelusta. Loput käyttötapaukset liitetään raporttiin niiden valmistuttua ja ne löytyvät sähköisenä samasta osoitteesta kuin loppuraportti. Vaikka osa käyttötapauksista puuttuu, tämän ei pitäisi vaikeuttaa tulosten arviointia merkittävästi. Raportissaan WM-Data on jaotellut tuotettavat palvelut ydin- ja tukiprosesseihin. Ydinprosesseja ovat: Opiskelijahaku- ja valintapalvelut: nimensä mukaisesti kattaa tuen opiskelijoiden haku- ja valintatoimintoihin Koulutusprosessipalvelut: prosessikokonaisuus sisältää koulutuksen suunnittelun ja sen toteutuksen tuen Opiskeluprosessipalvelut: prosessikokonaisuus sisältää opiskelun suunnittelun ja sen toteutuksen tuen T&K palvelut: tärkeä osa ammattikorkeakoulujen perustehtävää 7

8 Tukiprosesseja ovat: Käyttäjäpalvelut: käyttäjäpalvelut sisältävät esimerkiksi käyttäjien perustietojen luonnin ja ylläpidon Opiskelijapalvelut: toiminnoiltaan vastaa käyttäjäpalveluita, mutta prosessit on kuvattu opiskelija -käyttäjäryhmän näkökulmasta Raportointipalvelut Kuva1. Ydinprosessikaavio Proamk:n näkökulmasta WM-Data esittää kolmea mahdollista lähestymistapaa ohjelmiston tuottamisessa: Toteutusjärjestys: vaihtoehto A Vaihtoehto A:n kohdalla korostetaan sujuvaa ja loogista IT-projektinhallintaa sekä integrointeja edellyttävien välivaiheiden minimoimista. Vaihtoehdon A:n ehdotettu toteutusjärjestys: Tietokantasuunnittelu kokonaisuudelle Opiskelijahaku- ja valintapalvelut sekä käyttäjäpalvelut. Lisäksi osa opiskelijapalveluista. Koulutusprosessipalvelut ja T&K Opiskeluprosessipalvelut, lisäksi loput opiskelijapalveluista Raportointi ja tiedonsiirrot (esim. Amkota tieto) Toteutusjärjestys: vaihtoehto B Tässä kohdassa kuvatussa vaihtoehdossa lähdetään siitä, että nykyisten järjestelmien käyttö jatkuu, mutta osa operatiivisista tiedoista replikoidaan uuden järjestelmän tietokantaan. Sieltä ne välitetään edelleen järjestelmään kytkettävään tietovarastoon 8

9 raportointia varten. Tämän ratkaisun etu on se, että tiedolla johtaminen mahdollistuu vaihtoehtoa A nopeammin. Vastaavasti järjestelmien välinen integraatio lisää kustannuksia. Vaihtoehdon B ehdotettu toteutusjärjestys: Tietokantasuunnittelu kokonaisuudelle Integraation rakentaminen olemassa oleviin järjestelmiin Raportointi ja tiedonsiirrot Ensimmäinen käyttöönotto Opiskelijahaku- ja valintapalvelut sekä käyttäjäpalvelut., lisäksi osa opiskelijapalveluista Koulutusprosessipalvelut ja T&K Opiskeluprosessipalvelut, lisäksi loput opiskelijapalveluista Käytännössä tämä vaihtoehto edellyttää seuraavien rekistereiden/palveluiden luomista: opiskelijarekisteri (vrt. FunetEduPerson) opetushenkilöstörekisteri (vrt. FunetEduPerson) opinto-oikeus- ja tutkintorekisteri (vrt. M0) opetussuunnitelma- ja opintojaksorekisteri (vrt. M1) opintosuoritusrekisteri (vrt. M2) tietovarasto (vrt. OhaTv) valmistumispalaute (vrt. Opala) Toteutusjärjestys: vaihtoehto C Tässä kohdassa kuvatussa vaihtoehdossa lähdetään siitä, että nykyisten järjestelmien käyttö jatkuu, mutta raportointi ja tiedolla johtaminen mahdollistetaan kaikille ammattikorkeakouluille ja ProAMK:lle yhteisellä DW-tietovarastoratkaisulla. Yhteisessä tietovarastossa tulisi olemaan jokaiselle ammattikorkeakoululle oma osionsa, mutta ratkaisu mahdollistaisi myös alue- ja valtakuntatason raportointiratkaisut. Tämän vaihtoehdon etu on se, että uusikin järjestelmä on integroitavissa samaan tietovarastoon, jolloin tiedolla johtamiseen ei tule katkoksia järjestelmien uusimisen yhteydessä. Lisäksi käyttöönottoaikataulu on jokaisen ammattikorkeakoulun itse päätettävissä. Vaihtoehto C:n ehdotettu toteutusjärjestys: Tietokantasuunnittelu kokonaisuudelle Sekä Proamk:lle että nykyisille järjestelmille yhteisen tietovaraston suunnittelu Raportointi ja tiedonsiirrot suunnittelu ja toteutus Loput vaiheet kuten kohdassa B Asiantuntijapalvelu tukemaan toiminnan suunnittelussa, päivittäisessä toiminnassa, seurannassa ja raportoinnissa tarvittavien tietojen organisoinnin ja tallentamisen suunnittelua. Asiantuntijapalvelun toimittajaksi valittiin Ineo Oy. Toimeksiannon sisältö: 9

10 Suunnitelmassa on kuvattu korkealla tasolla se, miten järjestelmän tiedot organisoidaan ja tallennetaan siten, että ne tukevat suunnittelua, päivittäistä toimintaa, raportointia ja seurantaa. Suunnitelman tulisi sisältää: - mitkä rajoitteet vaikuttavat tietojen organisointiin (esim. viranomaisraportointi) - miten muualla tehtyjä kuvauksia voitaisiin hyödyntää (esim. M-määritykset, tietovarastohankkeet) - korkean tason suunnitelma järjestelmän tietosisällöistä ja niitä tukevista ratkaisuista kuten tietokannoista ja tietovarastoista Tulokset Alla osa Ineo Oy:n raportista. NÄKÖKULMIA ETENEMISMALLIIN Takaisinmaksun aikataulu ja riskitasot Etenemismalli tähtää takaisinmaksun tuottamiseen nopeutetusti olemassa olevien järjestelmien tietosisällön tehokkaamman hyödynnettävyyden kautta. Vaiheistuksessa myöhemmin toteutettavat osiot muodostavat loogiset kokonaisuudet. Palveluasteen säilyttämisen (ja vaiheittaisen parantamisen) näkökulma toteutuu hyvin. Ensimmäinen inkrementti muodostuu olemassa olevan tiedon harmonisointi- ja mallinnuspohjaisesta tietopalvelusta, joka sinänsä tukeutuu hyvään määrittelyaineistoon. Samassa yhteydessä toteutetaan valtakunnallisten kohdejärjestelmien vaatima käsitteellinen ja tekninen integraatio, jolloin muodostuu samalla käsitejoukko (mahdollisena tavoitteena oliokirjasto jo tietovarastomäärittelyssä), joka suoraan palvelee sovellusvaiheen tietoarkkitehtuurin suunnittelua. Tämä palvelee toisen vaiheen määrittelyn kannalta riskiä vähentävänä olosuhteena. Muutosriski Tietointegraatio voidaan toteuttaa matalammalla toiminnallisen integraation asteella kuin toiminnallinen integraatio. Täten tietopalvelun sijoittaminen ennen yhteisen operatiivisen platformin kehittämistä on perusteltua. Operatiivisten palveluiden toteuttamisessa voidaankin tähdätä yhteisiin toiminto- ja tietorajapintoihin. Toiminnan täydellinen eheyttäminen ei liene välttämätöntä. Tähän vaikutetaan myös myöhemmillä operatiivisen tiedonhallinnan automaatio- ja integraatioasteen valinnoilla. Tietopalvelu laajuus ja rajaus Yksi oleellinen riippuvuussuhde mallissa luonnostaan syntyy. Tietoarkkitehtuurin keskeiset piirteet tietovaraston tallennustasossa ovat merkittävä lähde uuden operatiivisen järjestelmän suunnittelussa. Tähän joukkoon voidaan ainakin lukea pääobjektit attribuutteineen ja transaktioiden osapuolet. Lisäksi tietovarastossa (epäsuorasti raportointivaatimusten johdosta) huomioitava pienin koontitaso organisaatioakselilla sanelee prosessien reunaehtoja. 10

11 Tiedon ja tietopalvelun laajuuden määrittämiseen on ProAMK:n tavoitteissa alustavasti otettu Amkota- ja Tilastokeskuksen vaatimukset. Tämän rinnalle voisi nostaa Aki Valkosen Tinfo työn puitteissa kuvaama kokonaisvaltainen ammattikorkeakoulun ja viranomaisten välinen tietovirta. Vaikuttaisi tarkoituksenmukaiselta tarkastella tätä kuvausta vaatimusten lähteenä. Tällöin syntyisi ilmeisen kattava luettelo ammattikorkeakoulutoiminnan ulkoisista raportointivelvoitteista päivätty Aki Valkosen kuva Ammattikorkeakoulujärjestelmän tietokanta- ja tietovirtarakenteet ja niiden suhde TINFO hankkeeseen. Osa-alue jota ei ole ennalta helppo arvioida on eri pedagogisten toimintamallien vaikutus ohjausmalliin ja sen tietosisältöön. Tämä ilmiö kuitenkin näkyy jo nykyisellään esim. vaihtelevina yksikköhintoina, joka heijastelee yleistä koulutusalakohtaista kustannusrakennetta. Mikäli korkeakoulun sisäisin päätöksiin muutetaan opetuksen toteuttamisperiaatteita niin, että tämä myös vaikuttaa kustannusmuodostukseen, on ilmeistä että tämän myös tulee näkyä ohjaustiedoissa. Sisäisten rakenteiden ja kustannuskantajien kirjaustekijöiden merkitys seurattavuuteen tulee joka tapauksessa olemaan suuri kustannuslaskennan osa-alueella. Operatiivisen ja johtamisjärjestelmän tarkoitus Uuden järjestelmän keskeisenä ominaisuutena tullee olemaan henkilökohtaisen opintosuunnitelman toteuttamisen ja toisaalta organisaation resurssiohjauksen yhdistäminen. Tähän ajavat niin toiminnan sisäiset muutokset kuin ulkoisetkin vaikuttimet. Näin ollen on ilmeistä, että järjestelmän osan muodostavan johtamisjärjestelmän tulee heijastaa samoja pääperiaatteita. Suunnitelmalähtöisyys, ennusteiden käyttö, läpäisyn sekä tuotannollinen että taloudellinen johtaminen sekä vertailukelpoinen sisäinen ja ulkoinen raportointi kuuluvat tähän. Tätä 11

12 samansuuntaisuuden tarvetta lienee mielekästä tukea vaatimusten keskitetyllä ohjaamisella. Riskinä pitää kuitenkin tunnistaa ongelmat saada toiminnallisia vaatimuksia johtamisjärjestelmälle näin varhain hankekokonaisuudessa. Lieneekin viisasta varautua iteratiiviseen vuorovaikutukseen osakokonaisuuden 2 kanssa niin operatiivisen toiminnan ohjaamisen palveluiden kuin uutta toimintamallia ohjaavan toiminnanohjauksen vaatimusten kytkemisessä tietopalveluiden tuottamiseen. Teknologia Teknisen arkkitehtuurin osalta tietovarastoinnin tekninen ulottuvuus muodostaa kohtuullisen itsellisen kokonaisuuden. Latausketjun hallinta ETL-välineellä on sinänsä suljettu kokonaisuus, johon tulee valita korkean automaatioasteen ja hallinta-asteen väline. Väline tarjoaa tyypillisesti jonkin avoimen rajapinnan järjestelmähallinnan näkökulmasta, ja on täten integroitavissa laajempaan hallittuun palvelukokonaisuuteen. Arkkitehtuurivaatimuksissa voitaneenkin keskittyä ETL-välineen erillisominaisuuksiin ja asettaa vaatimukset jonkin yleisen järjestelmähallintaprotokollan tuelle. Itse tiedonsiirto tapahtunee Funet-verkossa FTP -välitteisesti. Tämä on täysin väline- ja toteutusvaihtoehtoneutraali parametri. Tietokanta on relaatiomuotoinen, ja usein synergiassa ETL-välineen kanssa. On ilmeistä, että tietopalvelun tietokanta ja tulevan operatiivisen järjestelmän yhteys muodostuu kiinteämmäksi niin teknisessä kuin loogisessakin merkityksessä. Tietopalveluiden tietokantavalinta ei kuitenkaan muodosta rajausta tulevia vaiheita ajatellen, vaan relevantit arkkitehtuurivalinnat sisältävät rajapintatoteutukset kaikkien relevanttien tietokantavaihtoehtojen lukemiseen. Tietokannan tulee ennen kaikkea edustaa pitkäsyklistä teknologiaa, jolla on hyvä päämiestuki ja osaamissaatavuus. Harkittavaksi tullee, tehdäänkö arkkitehtuurin tarkennus ja lyödäänkö välinevalinnat lukkoon koko arkkitehtuurin osalta, vai tehdäänkö tämä vaiheittain. Käyttäjähallinta Varsinainen tietopalvelun käyttäjärajapinta muodostunee useista käyttäjätyökaluista ja palveluista. Välineiden tulee tukea hajautettua käyttömallia ja moniasiakasympäristöä. Erityisesti käyttäjäoikeudet täytyy ottaa huomioon käyttökonsepteja suunniteltaessa. Käyttäjähallinta ja autorisointi muodostaa suureen aihealueen, joka pitää käsitellä yhteismitallisesti tulevan sovelluksen suunnittelun kanssa. Tämä näkökulma voi luoda myös välineittäin vaihtelevia arkkitehtuuririippuvuuksia. Pyrkimyksenä voisi olla esimerkiksi prosessikohtaisesti dataan sidottu käyttöoikeusmalli, joka toimisi kaikissa datan käyttökonteksteissa. Käyttäjämäärä on kuitenkin suuri, ja muutoshallinta on saatava nivottua järjestelmäinstanssien normaalin pääkäyttäjätuen piiriin. Turvallisuus Turvallisuus koostuu teknisestä turvallisuudesta ja loogisesta turvallisuudesta. Uhat voidaan karkeasti ryhmitellä perusarkkitehtuuriin, palveluiden saatavuuteen (johon liittyvät myös ulkoiset uhkatekijät ja niiden torjuminen) sekä autentikointiin ja käyttöoikeuksiin liittyviksi. Osa-alueeseen eivät varsinaisesti kuulu ulkoinen turvallisuus ja siihen liittyvät päätökset. Onkin ilmeistä, että kokonaisturvallisuuteen vaikuttaa hyvin merkittävästi 12

13 palvelukeskuksen ja korkeakoulujen tietoliikenteen suojauksen taso, sekä palveluiden ulkoiset rajapinnat. Mitä avoimemmasta rakenteesta näiltä osin on kysymys, on mahdollista, että palveluita tullaan sijoittamaan eri tasoille, ja täten rajaamaan esim. korkeakoulukohtaisen tiedon haavoittuvuutta ulkoisille hyökkäyksille. Tällöin turvallisuusnäkökohdat vaikuttaisivat myös tietopalvelun sisäisen rakenteen valintoihin. Yhteenveto Alla etenemismallin visualisointi ProAMK:n etenemissuunnitelma-asiakirjasta: Kokonaisuutena voidaan vetää tiettyjä johtopäätöksiä etenemisestä: Esitetty porrastus tarjoaa etenemisen mahdollistavan hankerungon, jossa riskitaso ei vaikuta epärealistiselta. Arkkitehtuuri pitää suunnitella operatiivisen järjestelmän ja johtamisjärjestelmän toiminnallinen ja looginen kokonaisuus huomioiden. Tietorajausta pitää tulkita kaikkien ulkoisten raportointivaateiden näkökulmasta, rajauksia voidaan tehdä esim. vaiheistuksen tai manuaalisiksi jätettävien prosessien muodossa. Inkrementit ovat todennäköisesti 1 (Tietovarasto-, tiedonsiirto- ja raportointipalvelut) ja 2 (Perusrekisteripalvelut), ja ovat osittain vuorovaikutteisia. Käyttäjähallinnalle pitää muodostaa kattava toteutusmalli, jota tietopalveluosio toteuttaa ensimmäisenä. Tiettyjen ohjaustietojen ylläpito voi edellyttää hallintotyökalujen (jotka varsinaisesti kuuluisivat osioon 2) toteuttamista jo tietopalvelukokonaisuuden yhteydessä (esimerkkeinä user master, organisation master). Riippuvuudet keskittyvät o Käyttäjähallintaan o Tiedon koontitasoon (grain) o Pääobjektien attribuutteihin Muodostunut kansallinen koodisto ja tekninen esitystapa määrittävät merkittäviltä osin uuden järjestelmän masterdatan. Tallennusmallin tulisi kuvata perusobjektit, suhteet ja transaktiot perustasolla (ei laskenta- tai tilastointimuotoisena) jolloin em. käyttötarkoitusesitysmuodot muodostetaan tallennusmallin yläpuolelle. Asiantuntijapalveluiden raportit ja muu materiaali kokonaisuudessaan liitteissä. 13

14 3.1.2 Ulkomaiset referenssikohteet Ulkomaisiksi referenssikohteiksi päätettiin ottaa muissa pohjoismaissa toteutetut laajat yhteistyöhankkeet sekä saksalainen, julkisrahoitteinen HIS. Projektiryhmä kävi Saksassa tutustumassa HIS:n toimintaan ja toteutusvaiheessa olevaan uuteen opiskelija- ja opetushallinnon tietojärjestelmään. Muiden referenssikohteiden arviointi perustuu käytettävissä olleeseen materiaaliin. (Lähteenä on käytetty järjestelmien www-sivuja, Marcus Nybergh keräämää haastatteluaineistoa ja professori Ari Heiskaselta saatua materiaalia.) Tutkittavia asioita ovat olleet referenssikohteiden organisointi ja toteutustekniikka. Organisoinnin kohdalla tutkittavia asioita ovat olleet omistajuus, hallinnointi, sidosryhmät, toiminnan laajuus ja kustannukset vuositasolla. Toteutustekniikan osalta on tutkittu arkkitehtuuriratkaisuja, hajauttamisen ja keskittämisen astetta ja mahdollisuutta sekä toimittajariippumattomuutta LADOK, Ruotsi LADOK-konsortioon kuuluvat lähes kaikki Ruotsin yliopistot ja ammattikorkeakouluja vastaavat organisaatiot. Yhteensä konsortioon kuuluu 35 korkeakoulua sekä opintotukiasioiden keskuslautakunta. Konsortiohallinto ja pääosa kehitystiimistä toimivat Uumajan yliopiston erillislaitoksena. Kehitystiimissä työskentelee yli kolmekymmentä henkeä. Tuotantotapa on in-house-tyyppinen lukuun ottamatta osaa tietoturvaominaisuuksista, jotka on ulkoistettu WM-datalle. Korkeakoulut voivat kehittää LADOK-alustan päälle myös omia lisämoduuleitaan, mutta tätä ominaisuutta ei ole merkittävästi hyödynnetty. Konsortio kehittää korkeakouluille yhteistä LADOKopiskelijahallintojärjestelmää palvelemaan sekä korkeakouluja että viranomaisraportoinnin tarpeita. 14

15 Ladokin historia ulottuu aina 1960-luvulle saakka, jolloin AROS- ja FAROS- sekä myöhemmin 1970-luvulla STUDOK- nimiset järjestelmät loivat pohjan LADOKyhteistyölle. LADOK:in omistajana ja rahoittajana toimi alun perin valtiota edustanut kansallinen yliopistojen ja korkeakoulujen neuvosto. Neuvoston lakkauttamisen jälkeen Uumajan yliopiston rehtoria pyydettiin selvittämään kehityksen suuntaviivoja tulevaisuuteen. Organisointi päätettiin toteuttaa konsortiomallilla sen joustavuuden ja alhaisten perustamiskustannusten vuoksi luvun puoleen väliin asti Ruotsissa oli LADOK:in rinnalla muutamia pienempiä järjestelmiä, mutta niidenkin käyttäjät siirtyivät LADOK:iin pienempien järjestelmien ominaisuuksien puutteiden ja korkeiden ylläpitokustannusten vuoksi. Vuonna 1994 kaikki Ruotsin korkeakoulut liittyivät LADOK-konsortioon. Nykyään kaikki ruotsalaiset korkeakoulut kuuluvat konsortioon lukuun ottamatta muutamia taideopetusta antavia yksikköjä. LADOK:in kehittämiskustannukset ovat vuositasolla noin 8 miljoonaa kruunua (n ). Tuki- ja ylläpitopalveluiden budjetti on noin 20 miljoonaa kruunua (n. 2.2 milj. ). Konsortiohallinnon kustannukset ovat 1,8 miljoonaa kruunua (n ). Kokonaiskustannukset vuositasolla ovat noin 30 miljoonaa kruunua (n. 3.3 milj. ). LADOK-järjestelmä koostuu moduuleista, joista kukin korkeakoulu valitsee haluamansa käyttöön. Järjestelmää kehitetään keskitetysti, mutta kullakin organisaatiolla on siitä oma asennuksensa palvelimillaan. Konsortiossa on neljä ohjausryhmää, jotka toimivat tilaajina järjestelmälle ja joille tuloksista raportoidaan. Suurin osa LADOK-järjestelmästä toimii client-server-työkalu Unifacen avulla. LADOK:issa on erittäin paljon myös vanhoja osia, muun muassa noin 2 miljoonaa riviä Cobol-koodia ja kommentteja. Järjestelmässä on kuitenkin myös web-pohjaisia osia. Erityisesti uusimmissa osioissa on käytetty J2EE-teknologiaa. LADOK:in 15

16 tietokantajärjestelmänä on Mimer, joka on suhteellisen harvinainen. Versioiden päivitystahti on melkoinen, sillä joka toinen kuukausi julkaistaan uusi versio, joka on aiheuttanut korkeakoulujen tietokonekeskuksille ongelmia Felles Studentsystem, Norja Felles Studentsystem (FS) opiskelija- ja opetushallinnon tietojärjestelmää käyttää 19 norjalaista koulutusorganisaatiota. Norjan lainsäädäntö edellyttää opiskelijoiden opintopisteiden ja suoritusten raportointia viranomaisille ja tämän johdosta Norjan opetusministeriö on panostanut merkittävästi järjestelmän kehitystyöhön. FS:n tuottaman tiedon rooli korkeakoulujen rahoituksen määräytymisessä on merkittävä. FS:n kehitystyö on alkanut vuonna 1993 ja ensimmäiset käyttöönotot olivat vuonna Viimeisimmät käyttöönotot ovat vuodelta Norjan opetusministeriö kustansi alkuperäisen kehitystyön. Tällä hetkellä kustannuksista vastaa käyttäjäorganisaatioiden muodostama konsortio. Konsortioon on oikeus liittyä kaikilla norjalaisilla julkisrahoitteisilla koulutusorganisaatioilla. Vuosittainen kehitysbudjetti on noin 5,7 miljoonaa kruunua (n ). Tuki- ja ylläpitomaksut ovat noin 2.9 miljoonaa kruunua (n ). Sihteeristöön kulut ovat noin 1.5 miljoonaa (n ) kruunua. Koko konsortion kulut ovat noin 10.1 miljoonaa kruunua (n. 1.3 milj. ) vuodessa. Kehitys- ja ylläpitokuluista vastaavat konsortion jäsenet. Ohjelmisto on rakennettu samaan tapaan kuin valtaosa Suomessa käytössä olevista vastaavista järjestelmistä eli ns. client-server-tyyppisesti, jolloin työasemalle asennettu asiakasohjelma käyttää palvelimella olevaa tietokantaa. FS:n käyttämää 16

17 Oraclen tietokantaa ja palveluja on vuosien varrella kehitetty erilaisilla kehittimillä ja menetelmillä. Käytössä on kiinteitä moduuleita ja lisäksi ulkoisia ratkaisuja, kuten Oracle Financials. Liittymiä toteutetaan myös selainpohjaisesti. Versiosykli on noin puoli vuotta ja pienempiä päivityksiä tehdään tarvittaessa. Ohjelmistoa käytetään niin palvelukeskusten tarjoamana keskitettynä palveluna kuin oppilaitosten omana palveluna. Laajinta palvelukeskusta ylläpitää Uninett. Uninett on Norjan opetusministeriön omistama yritys ja sen alaisuudessa toimii neljä tytäryhtiötä; Uninett ABC, Uninett Norid, Uninett Sigma ja Uninett FAS. Uninettemoyhtiön toiminta vastaa pitkälti CSC:n toimintaa Suomessa. Tehtäviin kuuluu etenkin suomalaista Funet-verkkoa vastaavan, korkeakoulujen ja tutkimuslaitosten välisen tutkimukseen liittyvän tietoverkon ylläpitäminen. Uninett ABC tarjoaa koko norjalaiselle koulutusjärjestelmälle (1., 2. ja 3. aste) ITratkaisuja koskevia neuvontapalveluita ja vastaa identiteetin- ja käyttäjähallinnan keskitetystä kehittämisestä, Uninett Norid vastaa.no -domainista ja Uninett Sigma tieteellisen laskennan palveluista. Uninett FAS vastaa korkeakoulujen yhteisten hallinnollisten järjestelmien kehittämisestä. Uninett FAS:n toiminta jakautuu kolmeen pääyksikköön, joita ovat selvitysten tekeminen ja kansainvälinen yhteydenpito, kehittämistoiminta sisältäen järjestelmäintegraatioon ja tietoturvaan liittyvät asiat ja kolmantena käyttö- ja ylläpitotoiminta ja käyttäjätuki. Uninett FAS:n toiminnan tavoitteena on kehittää korkeakoulujen käyttöön järjestelmiä, jotka mahdollistavat hallinnollisten tehtävien hoitamisen mahdollisimman yksinkertaisesti ja kustannustehokkaasti. Korkeakoulujen käyttöön on toistaiseksi kehitetty muun muassa opinto-, talous-, palkka- ja henkilöstöhallinnon 17

18 perusjärjestelmät sekä asiankäsittely- ja arkistointijärjestelmä. Taloushallinnon järjestelmä käsittää myös hankintatoimen ja laskujen sähköisen käsittelyn. Lisäksi Uninett FAS koordinoi ja tukee korkeakouluja hallinnon yhteisten tietojärjestelmien hankinnassa, käyttöönotossa ja kehittämisessä. Kehitystyössä on pyritty standardointiin, keskitettyyn roolipohjaiseen käyttäjähallintaan ja raportoinnin tukemiseen. Uninett FAS tarjoaa myös korkeakoulukentällä käytössä olevien ohjelmistojen ja järjestelmien kilpailutuspalvelua, jonka FS-palveluista vastaa USIT (Oslon yliopiston alaisuudessa toimiva IT-keskus). FS tuotantomallina on in-house-tyyppinen tuotantomalli. USIT:ssa 4 henkilöä työskentelee ylläpidossa, 2.5 tukipalveluissa ja 3.5 kehityksessä. Tilaajaorganisaatio muodostuu ohjausryhmästä, hallituksesta ja työryhmästä. Ohjausryhmä toimii ylimpänä valvovana elimenä. Hallitus vastaa vuosisuunnittelusta, budjetoinnista, raportoinnista ja organisoinnista. Konsortion hallinto on sijoitettu Oslon yliopiston alaisuuteen. Työryhmä vastaa kehityksen toimeenpanosta ja siinä on johdon lisäksi edustus kaikista konsortion jäsenistä. Konsortiossa on tällä hetkellä 18 jäseninstituutiota STADS, Tanska STADS käynnistyi Vue-projektina 1980-luvun lopulla Tanskan opetusministeriön toimesta ja projektin tarkoituksena oli kaikkien Tanskan yliopistojen yhteinen opiskelijahallinnon tietojärjestelmä. Yhteistyön ongelmina ovat olleet muutaman yliopiston irtautuminen yhteistyöstä ja halu käyttää omia tietojärjestelmiään. 18

19 Kustannusten kasvu huomattavasti suunnitellusta loi organisaatiolle sisäisiä ongelmia. Ensimmäiset käyttöönotot tapahtuivat vuoden 1996 alussa. VUE-keskus toimi eteenpäin vievänä voimana projektissa, mutta suuren osan kehitystyön vastuusta kantoi WM-Data. VUE-keskus lopetettiin 1999 ja järjestelmää käyttävät instituutiot perustivat STADS-konsortion. Kehitystyötä valvoo konsortion hallitus. Priorisoinneista ja uusista ominaisuuksista vastaa asiantuntijakomitea, jonka johdossa on yleensä yksi konsortiokorkeakoulujen opintoasioiden päälliköistä. Asiantuntijakomitean alaisuudessa toimivat työryhmät, jotka valmistelevat asiantuntijakomitealle esitykset. Käytännön kehitystyöstä vastaavat toimittajan (WM-Data) ja tilaajan (STADS-konsortion) ohjausryhmät ja organisaation toiminnasta vastaa sihteeristö. Vuosittainen kehitysbudjetti on noin 10 miljoonaa kruunua (n. 1.4 milj. ). vuosittainen tukimaksu on noin 9 miljoonaa kruunua (n. 1.2 milj. ) ja sihteeristön kulut noin 3 miljoonaa kruunua (n ). Koko konsortion kulut ovat noin 22 miljoonaa kruunua (n. 3 milj. ) vuodessa. Konsortion jäsenet maksavat kehitys- ja tukikustannukset sekä sihteeristön kustannukset. Valtiovalta osallistuu ainoastaan sellaisiin kustannuksiin, jotka aiheutuvat viranomaisvaatimuksista. Kehitystyön alkuvaiheessa, ennen vuotta 1999, valtion osuus oli merkittävämpi kattaen silloisen organisaation ylläpidon. Ohjelmisto on rakennettu samaan tapaan kuin valtaosa Suomessa käytössä olevista vastaavista järjestelmistä eli ns. client-server-tyyppisesti, jolloin työasemalle asennettu asiakasohjelma käyttää palvelimella olevaa tietokantaa. STADS:in tapauksessa toteutus perustuu pääasiassa Oraclen tuotteiden pohjalle ja pääosa 19

20 toiminnallisuudesta on rakennettu Oraclen työkalujen varaan (Oracle Forms, Reports, PL/SQL). Kehitys on siirtymässä enemmän selainpohjaiseen suuntaan ja teknologia-alustana käytetään Java-kehitystyökaluja. Kaikilla organisaatioilla on oma asennus ohjelmistosta. Kaikki konsortion jäsenet käyttävät ohjelmistosta samaa versiota. Versio-sykli on keskimäärin yksi vuosi ja pienempiä päivityksiä tulee noin kuusi kappaletta vuodessa. Suurin kehitykseen liittyvä tarve on opiskelijoiden edistymisen vuosiseuranta, joka on ollut myös merkittävä syy valtiovallan haluun keskittää palveluja. Ongelmat ovat olleet normaaleja ohjelmistokehityksen ongelmia liittyen testaukseen, määrittelyihin, käytettävissä oleviin resursseihin jne. Tilaajan ja toimittajan yhteistyö on sujunut jouhevasti. Toimittajalla on n. 20 täyspäiväistä työntekijää STADSryhmässään, joista 14 on kehittäjiä. Konsortiolla ei ole omaa kehityshenkilöstä, koska in-house -tuotanto ei ole ollut taloudellisesti mahdollista. Jotkut konsortion jäsenistä tuottavat itse joitain palveluja, mutta nämä kehityshankkeet eivät ole automaattisesti konsortion käytettävissä HIS, Saksa Hochschul-Informations-System GmbH (HIS) on saksalainen voittoa tavoittelematon yritys, joka kehittää liittovaltion ja osavaltioiden rahoittamana tietojärjestelmiä Saksan korkeakouluille. HIS on perustettu 1960-luvulla. HIS:n osakepääomasta omistaa liittovaltio 1/3 ja osavaltiot 2/3. Ylimpänä päättävänä elimenä on yhtiökokous. Hallituksessa on kymmenen edustajaa omistajatahoilta ja korkeakouluista. Kuratorium on 35 edustajan toimielin, jonka tehtävänä on huolehtia asiakkaiden tarpeista ja HIS:n toiminnan säännönmukaisuudesta sekä edistää yhteistyötä eri toimijoiden välillä. Kuratorium tekee myös talouspoliittiset linjaukset sekä hyväksyy HIS:n toimintasuunnitelmat. 20