PharmaCo-toimitusprojekti, loppuraportti
Ryhmä B2

27. marraskuuta 2003

Turun yliopisto,
Tietojenkäsittelytieteet
Jukka Laukkanen
Marko Grönroos
Pyry Liukas
Tommi Mertsalmi

Tästä asiakirjasta

Tämä asiakirja on PHARMACO-järjestelmänsuunnitteluprojektin toimittajaosapuolen loppuraportti. Raportti on tarkoitettu toimittajan ja asiakkaan väliseen viestintään, sekä myös toimittajan projekti­ryhmän sisäiseen viestintään.

Marko Grönroos, Jukka Laukkanen, Pyry Liukas, Tommi Mertsalmi, 2003

Versiohistoria:

Vuosi	Versio	Päivämäärä	Huomautuksia
2003	1	27.11.03	Asiakkaalle toimitettu versio

Tämä asiakirja on tuotettu vapaalla OpenOffice.org-ohjelmistolla.

Sisällysluettelo

1 Johdanto	4

1.1 Asiakirjan sisältö	4

1.2 Toimittajan tehtävä	4

1.3 Tietojärjestelmän kehitys	4

1.4 Asiakirjan organisaatio	5

1.5 Terminologiaa	5

2 Tietojärjestelmän kehittäminen	8

2.1 Nykyinen tietojärjestelmä	8

2.2 P-tason suunnittelu	8

2.2.1 Yleistietoa asiakkaasta	8

2.2.2 Organisaation ja toimintaprosessin analyysi	9

2.2.3 Juurimääritelmät	13

2.2.4 Käsitemalli	16

2.2.5 P-tason kriteerit	17

2.3 IO-tason suunnittelu	19

2.3.1 Elinkaarimallit	19

2.3.2 Tietovuokaavio	20

2.3.3 Käyttöliittymän prototyyppi	23

2.3.4 Arviointikriteerit	24

2.4 CO-tason suunnittelu	26

2.4.1 Oliomalli	27

2.4.2 Tietomalli	28

2.4.3 Käyttöoikeusmatriisi	31

2.4.4 Arviointikriteerit	31

2.5 Portaaliohjelmiston valinta	33

3 Toimitusprojekti	35

3.1 Projektiryhmä	35

3.2 Toimintatapa	35

3.3 Projektiaikataulu	36

4 Yhteenveto	37

4.1 Yleistä	37

4.2 Arvio saavutetuista tuloksista	37

4.3 Arvio projektista	38

4.4 Arvio opponoinnin tasosta	39

4.5 Arvio käytetyistä metodologioista	39

Johdanto

Tämä asiakirja on PHARMACO-suunnitteluprojektin toimittajaosapuolen loppuraportti. Se sisältää lopullisen koosteen tietojärjestelmän kehittämisen suunnitteluosuuden tuloksista.

Asiakirjan sisältö

Tämä loppuraportti esittää tietojärjestelmän kehittäminen kokonaisuudessaan, sisältäen tehtävänmäärityksen, kaikkien suunnitteluvaiheiden tuottamat lopulliset mallit ja vaiheiden arvioinnin. Suunnitteluosuuden lopuksi esitetään valinta tietojärjestelmän toteuttamiseen käytettävästä portaaliohjelmistosta.

Loppuraportissa on mukana myös suunnitteluprojektin organisaatiota, toimintaa ja aikatauluja koskeva kooste.

Yhteenvedossa annetaan lisäksi arvioinnit saavutetuista tuloksista, projektin kulusta, opponentti­ryhmän toiminnasta ja suunnitteluprojektissa käytetyistä metodologioista.

Toimittajan tehtävä

Toimittaja tehtävänä oli alkuperäisen tehtävänannon mukaan:

Tarjota perusteita asiakkaan nykyisen omaverkon korvaamiselle portaalitekno­logialla

Portaaliohjelmiston valinta

Tämän valinnan perustelu

Asiakirjojen hallinnassa ja linkityksessä ilmenevien haasteiden tunnistaminen

Toteutukseen vaikuttavien sosiaalisten ja käyttäytymiseen liittyvien tekijöiden tunnistaminen

Portaaliohjelmiston valinnan perustelu jätettiin tietojärjestelmän kehityksessä kuitenkin vähemmälle huomiolle ja portaalia suunniteltiin pitkälti siten, ettei erityistä portaaliohjelmistoa käytettäisi.

Tietojärjestelmän kehitys

Suunnittelussa käytettiin PIOCO-metamallia, jonka perusteella suunnittelu jaettiin kolmeen osaan: P, IO ja CO. Metamallin P-tasolla tehtiin analyysi organisaation rakenteesta ja keskeisestä toimintaprosessista. IO-tasolla analysoitiin suunniteltavan tietojärjestelmän ja sen käyttäjien välistä tiedon kulkua ja mallinnettiin tietojärjestelmää rakenteellisesti. Viimeisellä, CO-tasolla edettiin tietokeskeiseen suunnitteluun.

Kukin kolmesta suunnittelutasosta päätettiin kriteereillä, jotka seuraavan tason tulisi täyttää.

Suunnittelun eri tasoilla käytettiin seuraavia malleja ja menetelmiä:

P-taso

Rikaskuvat

CATWOE-analyysit

Juurimääritelmät

Käsitemallit

P-tason mittarit

IO-taso

Liittymäkaavio

Tietovuokaavio

Käyttöliittymän prototyyppi

IO-tason mittarit

CO-taso

Oliomalli

Tietomalli

Käyttöoikeusmatriisi

CO-tason mittarit

Lopuksi esitetään vielä projektiryhmän organisaatio ja aikataulu.

Asiakirjan organisaatio

Luku 1: Johdanto	Yleistä loppuraportin sisällöstä.
Luku 2: Tietojärjestelmän kehittäminen	Tietojärjestelmän kehittämisen kaikki vaihteet eli P, IO ja CO, lopullisine malleineen ja kriteereineen.
Luku 3: Toimitusprojekti	Tietoa toimitusprojektin organisaatiosta, aikataulusta ja aikataulun toteutumasta.
Luku 5: Yhteenveto	Yhteenveto loppuraportin sisällöstä ja

Terminologiaa

Alla on käsitelty joitain kehitettävän tietojärjestelmän kannalta oleellisia teknisiä käsitteitä, jotka eivät välttämättä ole kaikille aivan tuttuja.

Omaverkot ja vierasverkot

Omaverkolla (engl. intranet) tarkoitetaan organisaation sisäiseen tiedonvälitykseen Internet-tekniikalla toteutettua verkkojulkaisukokonaisuutta.

Vierasverkko (engl. extranet) taas on koh­distettu organisaatioiden väliselle julkaise­miselle ja tiedonsiirrolle.

Oma- ja vierasverkot voidaan toteuttaa suoraan HTML-sivuina ja WWW-ohjelmina tai käyttäen sisällönhallintajärjestelmää. Omaverkossa voi olla portaali, joka tarjoaa yrityksen työntekijöille pääsyn omaverkkoon ja Internetiin.

Portaalit

Portaalit ovat käyttäjän lähtöpisteitä Internetiin, omaverkkoon tai vierasverkkoon. Ne on yleensä helposti muokattavissa siten, että käyttäjä voi valita kaikki itselleen tärkeät asiat pääsivulle.

Kuten sisällönhallintajärjestelmät, myös portaalit rakentuvat yleensä lisäosista eli sovelmista, joiden tarkoituksena on koota käyttäjän haluamaa tietoa portaalisivulle.

Usein portaalilla tarkoitetaan myös sisällönhallintajärjestelmällä toteutettua oma­verkkoa.

Sisällönhallintajärjestelmät

Sisällönhallintajärjestelmät ovat WWW-pohjainen ratkaisu organisaation informaa­tionhallinnalle. Ne tarjoavat web-pohjaisen liittymän, jonka avulla verkkojulkaisu­jen tekemiseen ei tarvita ohjelmointiosaamista. Niiden avulla voi toteuttaa sekä oma- ja vierasverkkoja että Internet-sivustoja.

Sisällönhallintajärjestelmät koostuvat yleen­sä yleisestä käyttöliittymä- ja sovellus­kehyksestä ja joukosta erikoistehtäviin tarkoi­tettuja lisäosia eli sovelmia.

Tyypillisiä sovelmia ovat:

Uutisten julkaisujärjestelmät

Sisällönhallintajärjestelmät

Sähköposti- ja postituslistajärjestelmät

Viitetietokannat

Hakukoneet

Projektinhallinta

Tietokannat

Sisällönhallintajärjestelmissä on yleensä joustava käyttöoikeuksien hallinta, mikä mahdol­listaa tiedon jakamisen kohdistetusti vain halutuille tahoille, kuten organi­saation ul­kopuolelle, esimerkiksi Internetiin.

Sisällönhallintajärjestelmät toimivat usein myös portaaleina ja ovat usein synonyymi portaaleille.

Joissain sisällönhallintajärjestelmissä/portaaleissa on tuki monikielisyydelle. Piirteitä, joissa monikielisyyttä tarvitaan, ovat

Käyttöliittymät

Järjestelmässä ylläpidettyjen asiakirjojen kielen merkitseminen

Eri kielisten asiakirjaversioiden hallinta

Tietojärjestelmän kehittäminen

Tässä luvussa esitetään tietojärjestelmän kehittäminen kokonaisuudessaan, esittäen kaikkien suunnitteluvaiheiden tuottamat lopulliset mallit.

Nykyinen tietojärjestelmä

Asiakkaan nykyinen omaverkko on yksinkertainen omaverkko, jonka tietosisällön hallintaan ei käytetä varsinaista sisällönhallintajärjestelmää. Ylläpito tapahtuu teknisen henkilöstön toimesta.

P-tason suunnittelu

P-tason suunnittelu keskittyy asiakkaan organisaation ja keskeisen toimintaprosessin analyysiin.

Suunnittelu aloitetaan organisaation ja toimintaprosessin yleisellä analyysillä, joka esitetään rikaskuvina. Samalla pyritään tunnistamaan olemassa olevat ongelmakohdat, joita kehitettävän tietojärjestelmän avulla saatettaisiin kyetä poistamaan. Organisaatioanalyysissä tunnistettujen toimijoiden näkökulmia tarkastellaan juurimääritelmien avulla, jotka muodostetaan CATWOE-analyysin perusteella. Juurimääritelmistä muodostetaan keskeisen toimintaprosessin käsitemalli.

Yleistietoa asiakkaasta

PharmaCo on suuri monikansallinen lääketutkimusyritys. Sen tärkein liiketoimin­nan muoto on tutkimus ja suunnittelu. Yrityksellä on tutkimus- ja suunnitteluosas­toja useissa maissa.

Sen pyrkimyksenä on kasvattaa markkinaosuuttaan ja päästä Tier 1 -yritykseksi. Yrityksessä uskotaan, että tehokkaampi pääsy sekä sen sisäisiin että ulkoisiin tieto­resursseihin tehostaisi liiketoimintaa.

Organisaatiorakenne

Asiakasyrityksen organisaatiorakenne on seuraavanlainen, mainiten myös kehitettävän portaalin kannalta relevantin tiedonhallintaryhmän sijoittumisen organisaatiossa.

Pääkonttori Yhdysvalloissa, Tucsonissa

Informaatioteknologian osasto (IT)

Dan Kramer, CTO

Tiedonhallintaryhmä (KM)

Henkilöstöhallinto (HR)

Lakiosasto

Markkinointiosasto

Talousosasto

Kirjanpito-osasto

Tutkimusyksiköitä eri maissa

Toiminnan erityispiirteitä

Ainakin seuraavat asiakkaan toiminnan erityispiirteet ja muut tekijät saattavat vai­kuttaa annetun tehtävän suorittamiseen.

Toiminnan tutkimuskeskeisyys

Monikansallisuus

Lääkeainetietojen käsittely

Kliiniset lääketutkimukset

Eläinkokeet

Ihmisillä tehtävät tutkimukset

Hakemukset

Yhdysvalloissa FDA:n GCP-standardin noudattaminen

21 CFR (Code of Federal Regulations)

EU:ssa CTD-hakemusrakenne

Hakemusmateriaalin koostaminen

Laatu (erit. eheys ja ajantasaisuus)

Hakemusprosessin seuranta

Koetuloksia kerätään organisaation ulkopuolelta

Tietoja täytyy välittää ulkoisille organisaatioille

Yhdysvalloissa FDA:lle

Esim. Suomessa Lääkelaitokselle

Myyntihakemukset

Lainsäädäntö eri maissa

Eri maiden lääkelaitosten käytännön määräysten muuttuminen

Tutkijoiden viestinnän erikoisluonne

Tutkijat käyttävät keskinäisessä viestinnässä myös äidinkieltään

Organisaation ja toimintaprosessin analyysi

Kuva 1: Rikaskuva yrityksen yleisestä toimintaprosessista. Asiakasyrityksen keskeinen toiminnallinen organisaatiorakenne ja toimintaprosessi on esitetty kuvassa 1. Rikaskuvan kohtia on tarkasteltu tarkemmin alla. Toimintaprosessin kuvausta on tarkennettu tutkimustoiminnan osalta kuvassa 2 alla. Eri henkilöryhmien rooleja tarkastellaan myöhemmin tarkemmin juurimäärittelyn avulla.

Toimittaja esitti asiakkaan ohjausryhmälle kolme mahdollista rajausta kehitettävälle tietojärjestelmälle:

Suppea	Mukana on vain tutkimusryhmien välinen viestintä.
Keskisuuri	Mukana on suppean rajauksen osien lisäksi kliinisiin kokeisiin liittyvä viestintä, mukaan lukien palautteen saamisen kokeita tekeviltä (yrityksen ulkopuolisilta) lääkäreiltä.
Laaja	Mukana lakiosasto, tuotanto ja viestintä lääkelaitosten kanssa.

Asiakkaan ohjausryhmä piti keskisuurta rajausta sopivimpana. Asiakas on katsonut kehitettävän tietojärjestelmän painottamisen erityisesti tutkimusryhmien väliseen viestintään tärkeimmäksi. Tämä rajaus on esitetty kuvan 1 rikaskuvassa. Järjestelmästä täysin pois rajatut tekijät on esitetty himmennettynä ja järjestelmäkehityksen keskeisintä painotusta on korostettu rengastamalla.

Organisaation ja toimintaprosessin kohdat

Yrityksen keskeinen toimintaprosessi muodostuu lääkkeiden kehitystyöstä. Kehitystyö tapahtuu tutkimus- ja tuotekehitystoimintaa harjoittavien tutkimusryhmien toimesta, joita on monissa eri maissa.

Lääkkeet käsitetään koostuvaksi tietyistä lääkeainemolekyyleistä ja niiden yhdistelmistä, sekä pakkaustavasta. Lääkkeisiin liittyvä tieto koostuu ensisijaisesti niiden ominaisuuksien ja tuotantoprosessien kuvauksista. Niihin liittyy myös ohjeistusta käytöstä ja dokumentaatiota tunnetuista vuorovaikutuksista ja sivuvaikutuksista. Lääkeaineita tuotetaan kehitysvaiheessa esikliinisiä ja kliinisiä tutkimuksia varten ja myöhemmin myyntiin.

Kliiniset tutkimukset kattavat tässä kaaviossa sekä eläinkokeet että ihmisillä tehtävät kokeet. Konkreettisella tasolla kliiniset tutkimukset tarkoittavat tutkimuksia vetävää projektiryhmää tai -ryhmiä, joiden sisäistä rakennetta ei tässä täsmennetä. Tämä projektiryhmä on, ainakin järjestelmän kannalta, eri kuin itse lääkeainetutkimusta tehnyt tutkimusryhmä. Myös eri kliinisten kokeiden vaiheissa voi olla erillisiä aliprojektiryhmiä. Kliinisiin kokeisiin sisältyy eläinkokeita ja ihmisillä tehtäviä kokeita. Eläinkokeet tehdään pääsääntöisesti sisäisesti, kun taas ihmisillä tehtävät kokeet tehdään yhteistyössä toimivien lääkärien avustuksella.

Tutkimusryhmät voivat optimoida lääkkeen parametreja edelleen kliinisistä tutkimuksista saadun palautteen perusteella. Optimointia ja jatkokehitystä voidaan tehdä lääkeainemolekyylien, niiden yhdistelmien ja pakkaustavan tasolla.

Eri maiden lääkelaitoksilla on tärkeä rooli tuotekehitysprosessissa. Eläinkokeiden ja ihmisillä tehtävien kliinisten tutkimusten lupahakemusten sekä myyntilupahakemusten toimittaminen kansallisille lääkelaitoksille on keskeinen osa lääkekehitysprosessin informaatiokulkua. Niille tehtävissä hakemuksissa käytetään tutkimusryhmien tuottamaa tietoa. Lääkelaitokset eivät kuitenkaan ole suoraan merkittävässä yhteydessä tutkimus- ja tuotekehitysryhmiin, vaan niitä kiinnostavat lähinnä kliinisten kokeiden järjestelyt ja tulokset.

Lääkelaitokset ja lait vaikuttavat tutkimusryhmien toimintaan ja erityisesti uusien lääkeaineiden markkinoille viemiseen hyvin voimakkaasti. Paikallinen lainsäädäntö voi esimerkiksi kieltää tietynlaisen tutkimuksen, jolloin tutkimusryhmien on oltava ajan tasalla tutkimustaan koskevissa lakiasioissa jo tutkimusten suunnitteluvaiheessa. Lakiosastot jalostavat tutkimusta ja lääkeaineita koskevaa paikallista lakitietämystä tutkimusryhmien käyttöön, etsivät tutkimustoiminnasta lainopillisia ongelmakohtia ja selvittävät niitä.

Lääkärit ovat yrityksen ulkopuolisia tietolähteitä, jotka antavat ihmisillä tehtävien kliinisten tutkimusten aikana palautetta lääkkeiden vaikutuksista heidän potilaisiinsa.

Tuotanto on nyt rajattu kehitettävän tietojärjestelmän ulkopuolelle, huolimatta siitä että tuotanto on osa kehitysprosessia ja tiedon vuorovaikutteinen siirtyminen tutkimusryhmien ja tuotannon välillä saattaisi nopeuttaa kehityssykliä. Tämä riippuu kuitenkin muun muassa siitä, tarvitsevatko tutkimusryhmät tuotannon palveluita, jolloin tilausten seuranta voisi olla oleellista, vai ovatko ne riippumattomia tuotannosta. Kenties tietojärjestelmää voidaan myöhemmin, tämän projektin ulkopuolella, laajentaa kattamaan myös tämä alue.

Kuva 2: Tarkennettu rikaskuva tutkimusryhmien toimintaprosessista. Tutkimusryhmien toimintaprosessi

Tutkimusryhmien organisaatiota ja toimintaprosessia on kuvattu tarkemmin kuvassa 2. Tutkimusryhmät koostuvat projektin hallinnosta, tutkijoista ja teknisestä tuesta.

Tutkimustoiminnan keskeisin rooli on lääkeainekehitystä tekevillä tutkijoilla. Osa tutkijoista on spesialisteja, joilla on usein takana pitkä historia yrityksessä ja arvokasta erityisasiantuntemusta. He voisivat käyttää asiantuntemustaan myös muiden kuin oman tutkimusryhmänsä hyödyksi.

Tuotekehitystoimintaa ohjataan pääkonttoriin keskittyneen ylimmän johdon toimesta. He tekevät lopulliset päätökset tutkimusprojektien käynnistämisestä, resurssien jakamisesta ja projektien lopettamisesta.

Tekninen tuki on otettu mukaan nykyisen tietojärjestelmän vuoksi, koska tutkimusryhmien väliseen tiedon välitykseen omaverkon kautta tarvitaan nykyisin teknistä henkilöstöä.

Ongelmatekijät

Tutkimusryhmien välinen viestintä ei toimi tehokkaasti, mikä johtaa päällekkäisyyksiin. (Tästä tarkemmin alla.)

Paikalliset lait voivat olla ristiriidassa tutkimustoiminnan tai kliinisten kokeiden kanssa, mutta tätä koskeva tieto ei välity tehokkaasti. Lakien ja niiden muuttumisen tuntemattomuus saattaa johtaa vakaviin ongelmiin.

Lääkelaitoksille tehtävien hakemusten laadussa voi olla ongelmia; tietoja saattaa puuttua tai ne voivat olla virheellisiä ja joitain paikallisten lääkelaitosten vaatimia asioita ei välttämättä ole otettu kliinisissä kokeissa huomioon. Nämä laatuongelmat voivat johtaa myyntilupien viivästymiseen.

Spesialistit haluaisivat saada mahdollisimman hyvän kuvan ryhmien toiminnasta, mutta tietoa on vaikea saada, osittain koska tutkijat eivät halua luovuttaa puolivalmista tietoa.

Lääkärien kohdalla ongelmana on potilaille tehtävistä kliinisistä kokeista saatavan tiedon välittäminen tutkimusryhmille.

Juurimääritelmät

Alla toimintaprosessin oleellisimpien tekijöiden juurimääritelmät, perustuen niiden CATWOE-analyysiin.

SPESIALISTI
(C) Asiakas	Tutkimusryhmä
(A) Toimija	Minä itse
(T) Muunnos	Tutkimuksen edistäminen ohjaamalla
(W) Maailmankuva	Mahdollisimman hyvien lääkkeiden kehittäminen
(O) Omistaja	Tutkimusryhmän johto
(E) Ympäristö	Tutkimusryhmissä

Autan omaa tutkimusryhmääni lääkkeiden kehittämisessä, sekä annan tietoa johdolle siitä miten tutkimus edistyy.

TUTKIJA
(C) Asiakas	Tutkimusryhmä
(A) Toimija	Minä itse
(T) Muunnos	Tutkimuksen edistäminen
(W) Maailmankuva	Mahdollisimman hyvän lääkkeen kehittäminen
(O) Omistaja	Tutkimusryhmän johto
(E) Ympäristö	Tutkimusryhmä

Teen tutkimustyötä omassa tutkimusryhmässäni, jonka tehtävänä on kehittää tuottavia ja turvallisia lääkkeitä PharmaColle mahdollisimman nopeasti ja tehokkaasti. Tarvitsen työssäni teknistä henkilökuntaa. Työhöni vaikuttavat paikalliset lait. Ryhmämme spesialistit ohjaavat työtäni ja vastaan työstäni ryhmäni johtajalle.

TUTKIMUSRYHMÄN JOHTO
(C) Asiakas	Tutkimusryhmä
(A) Toimija	Minä itse
(T) Muunnos	Tutkimusprojektin hallinta
(W) Maailmankuva	Tutkimusprojektin onnistuminen nopeasti ja tehokkaasti
(O) Omistaja	Ylin johto
(E) Ympäristö	Tutkimusryhmä

Hallitsemani tutkimusryhmän tarkoituksena on tehdä tuottavaa lääkekehitystä mahdollisimman hyvin ja tehokkaasti tukevaa tutkimusta. Tehtävänäni on valvoa, että tutkimusryhmä noudattaa paikallisia lakeja.

YLEMPI JOHTO
(C) Asiakas	Koko yritys
(A) Toimija	Minä itse
(T) Muunnos	Projektien hallinta
(W) Maailmankuva	Tuoton maksimointi
(O) Omistaja	Rahoittajat
(E) Ympäristö	Yritys

Yritän ohjata tutkimusryhmien resursseja tuoton kannalta mahdollisimman lupaaviin projekteihin. Tarvitsen siksi selkeän kuvan ryhmien toiminnasta ja projekteihin liittyvistä ongelmista, jotta voisin nähdä resurssitarpeet, nopeuttaa tärkeiden projektien aikatauluja, lopettaa epävarmat projektit ja välttää päällekkäisyyksiä.

KANSALLISET LÄÄKELAITOKSET
(C) Asiakas	Lääkkeiden käyttäjät
(A) Toimija	Me
(T) Muunnos	Lääkkeiden valvominen
(W) Maailmankuva	Turvallisia lääkkeitä markkinoille
(O) Omistaja	Valtio
(E) Ympäristö	Valtio

Valtio on velvoittanut meidät valvomaan tarkasti, että lääkeyritykset tuottavat mahdollisimman turvallisia lääkkeitä niiden käyttäjille.

HENKILÖSTÖOSASTO
(C) Asiakas	Organisaatio
(A) Toimija	Itse
(T) Muunnos	Henkilöstön hallinta
(W) Maailmankuva	Osaajien löytäminen ja hyödyntäminen
(O) Omistaja	Ylempi johto
(E) Ympäristö	Organisaatio

Etsimme osaajia ja pyrimme pitämään ne organisaatiossa. Edistämme koko organisaation toimintaa.

LÄÄKÄRIT
(C) Asiakas	Potilaat
(A) Toimija	Minä
(T) Muunnos	Potilaiden hoito (myös lääkkeiden avulla)
(W) Maailmankuva	Mahdollisimman monen potilaan parantaminen ja oman taloudellisen tilan turvaaminen
(O) Omistaja	Sairaalan johto / yksityinen klinikka
(E) Ympäristö	Sairaala, yksityiselämä

Tavoitteeni on hoitaa mahdollisimman monta potilasta ja parantaa sairauksia. Apunani käytän eri työvälineitä, joista eräs on lääkkeet. Lääkkeiden toimivuudesta ja vioista annan palautetta lääkeyhtiölle. Tavoittelen taloudellista hyvinvointia ja hyvää mainetta lääkäreiden keskuudessa.

KEHITYSPROJEKTIT (LÄÄKETUTKIMUS)
(C) Asiakas	Yritys
(A) Toimija	Yksi tai useampia tutkimusryhmiä
(T) Muunnos	Uuden lääkeaineen kehittämistä tukeva tutkimus
(W) Maailmankuva	Kehittää PharmaColle uusi, tuottava ja turvallinen lääke
(O) Omistaja	Ylin johto
(E) Ympäristö	Yritys

Yrityksen kehitysprojektien puitteissa tehdään tutkimusta, joka edistää uuden, tuottavan ja turvallisen lääkeaineen kehittämistä mahdollisimman nopeasti. Tutkimusprojektiin osallistuu yksi tai useampi tutkijoista, johdosta ja spesialisteista koostuva tutkimusryhmä.

Tämä viimeinen juurimääritelmä havaittiin yrityksen kehitystoiminnan kannalta keskeisimmäksi ja valittiin käsitemallien laadinnan pohjaksi.

Käsitemalli

Käsitemallin ylin taso on esitetty alla kuvassa 3. Ylimmän tason kutakin osaa on tarkennettu edelleen kuvissa 4, 6 ja 5.

Kuva 3: Korkeimman tason käsitemalli lääketutkimuksesta. Kuva 4: 2. tason käsitemalli tutkimusryhmän perustamisesta.

Kuva 6: 2. tason käsitemalli tutkimustoiminnasta. Kuva 5: 2. tason käsitemalli kliinisistä testeistä.

P-tason kriteerit

Nämä mittarit toimivat kriteereinä rakenteisen suunnittelun tuloksille.

Alla on listattu oleellisimpia kriteereitä, joista tärkeimpiä myöhemmin tarkennetaan mitattavalle tasolle.

Myyntihakemusten läpimenoajan nopeutuminen

Päällekkäisyyksien väheneminen

Tutkimusryhmien työmäärän väheneminen

Päällekkäisyyksien parempi havainnointi

Informaatiokulun parantaminen

Ryhmän jäsenten välillä

Tutkimusryhmien välillä

Informaation lisääntyminen ylimmälle johdolle

Kustannustehokkuus

Tutkimusryhmien kustannusten väheneminen

Lääkekehityksen kokonaiskustannusten väheneminen

Oikeudellisten riskien väheneminen

Alla olevassa taulukossa on esitetty P-tason tärkein mittari.

Taso	Tavoitteen nimi	Prioriteetti	
P	Päällekkäisyyksien vähentäminen	1 (korkea)	
Tavoitteen kuvaus
Tietojärjestelmän tulee vähentää päällekkäisyyksiä eri tutkimusprojekteissa.
Alkuehdot
Tutkimusryhmien jäsenten (tutkijoiden, mutta myös projektijohdon ja teknisen henkilökunnan) tulee kyetä tallentamaan järjestelmään yleistä tietoa siitä, mitä pieniäkin aliprojekteja he tekevät, ovat tehneet tai ovat aikeissa tehdä. Järjestelmän tulee rohkaista tietojen tallentamiseen. Käyttäjien tulee, uusia aliprojekteja suunniteltaessa, kyetä helposti löytää päällekkäisyyksiä, eli tietoa siitä mitä toiset tutkimusryhmät tekevät.
Arviointi
Tavoitteen arviointia suoritetaan ensin melko nopeasti järjestelmän käyttöönoton jälkeen ja sen jälkeen vuoden välein. Löytyneiden päällekkäisten toimintojen lukumäärä Löytyneiden päällekkäisten toimintojen arvioitu tuntimäärä Järjestelmään kirjattujen projektien tuntimäärä Tutkimusprojektien kokonaiskesto
Johtopäätökset
Mikäli voidaan osoittaa, että implementoitu järjestelmä on vähentänyt eri tutkimusprojekteissa esiintyviä päällekkäisyyksiä arviointiosion mukaisesti, voidaan todeta että järjestelmä on täyttänyt tämän sille asetetun kriteerin.

IO-tason suunnittelu

IO-tason rakenteisessa suunnittelussa käytetään olioiden elinkaarimallia ja tietovuokaavioita. Lopuksi esitetään PIOCO-mallin mukaiset IO-tason kriteerit.

Elinkaarimallit

Kuvassa 7 on esitetty lääkeaineen elinkaarimalli, joka perustuu lääkekehityksen vaiheiden yleiseen ajoituskaavioon.

Kuva 7: Lääkeaineen elinkaarimalli. Tutkimusryhmää koskeva vaihe ulottuu puhtaasta tutkimusvaiheesta esikliiniseen tutkimusvaiheeseen, jossa tutkimustyötä tehdään rinnakkain esikliinisten tutkimusten kanssa.

Mikäli kliinisissä testeissä havaitaan ongelmia, palautuu lääkeaineen kehitys tutkimustyöhön, jonka jälkeen se hyvin mahdollisesti keskeytetään (lääkeaineita on usein vaikea korjata) ja lopetetaan. Keskeytys voidaan tehdä missä tahansa vaiheessa myös muista syistä, kuten liiketaloudellisten tekijöiden perusteella.

Myynti jatkuu, kunnes lääkeaine halutaan vetää pois markkinoilta joko liiketaloudellisiin perustein tai jos lääkeaineen käytössä on ilmentynyt odottamattomia sivuvaikutuksia.

Kuva 8: Tutkimusryhmän elinkaarimalli. Kuvassa 8 on esitetty tutkimusryhmän elinkaarimalli. Tutkimusryhmä on odotustilassa lääkeaineen kliinisten testien aikana. Huomaa, että "tutkimusryhmä" käsitetään tässä tiettyä lääkeainetta kehittävänä loogisena yksikkönä; käytännössä ryhmä tai sen työntekijät voivat osallistua muidenkin lääkeaineiden kehitykseen, eivätkä siten ole joutilaina ollessaan tässä odotustilassa.

Tietovuokaavio

Kuvassa 9 on esitetty tietojärjestelmän liittymäkaavio ja kuvassa 10 ylimmän tason tietovuokaavio.

Kuva 9: Tietojärjestelmän liittymäkaavio.

Kuva 10: Ylimmän tason tietovuokaavio. Projektitietoihin katsotaan kuuluvaksi myös tutkimustulokset; projektin ylläpitoon sisältyy tällöin tutkimustulosten vieminen järjestelmään tutkijoiden toimesta.

Kliinisiä kokeita voidaan tehdä sisäisesti kliinisen tutkimusryhmän ("testaajien") toimesta ja ulkoisesti lääkärien toimesta.

Kohtia 1 (perusta projekti) ja 2 (ylläpidä projektia) on tarkennettu alla kuvissa 11 ja 12.

Kuva 11: 2. tason tietovuokaavio, (1) Perusta projekti.

Kuva 12: 2. tason tietovuokaavio, (2.) Ylläpidä projektia.

Käyttöliittymän prototyyppi

Alla on esitetty käyttöliittymän prototyyppi. Jaottelu on seuraavanlainen:

Pääsivu, projektit-välilehti (kuva 14)

Projektitiedot (kuva 13)

Projektin tutkimustiedot (kuva 16)

Projektiryhmätiedot (kuva 15)

Viestintävälilehti (kuva 18)

Ilmoitukset-välilehti (kuva 17)

Hakuvälilehti (kuva 19)

Kuva 14: Pääsivu, projektit-välilehti. Kuva 13: Projektitiedot.

Kuva 17: Ilmoitukset-välilehti. Kuva 16: Projektin tutkimustiedot. Kuva 15: Projektiryhmätiedot. Kuva 18: Viestintävälilehti.

Kuva 19: Hakuvälilehti.

Arviointikriteerit

Alla on esitetty IO-tason arviointikriteerit, PIOCO-mallin käyttäjien tyytyväisyyden kriteerien hierarkian mukaisesti.

Käytettävyys

Mielekkyys käyttää järjestelmää

Vaste

Käytön nopeus (huom. toimintaa on maailmanlaajuisesti)

Tulkittavuus

Yhdenmukaisuus

Mahdollisuus käyttää omalla kielellä

Informatiivisuus

Asiakirjojen luokittelu

Sisällön reaaliaikaisuus

Asiakirjapohjien saatavuus

Tietojen luotettavuus

Muutoshistorian tallentuminen, helppo saanti ja mahdollisuudet eheyden tarkistamiseen

Tietoturva

Käyttäjätasot (pääkäyttäjä, tutkija, harjoittelija, jne.)

Tiedon omistajuus (tietyt käyttäjät pääsevät tiettyihin tietoihin)

Huomioon ottaminen myös hakukoneessa

Mukautettavuus

Järjestelmä tulee olla mukautettavissa uusien vaatimuksien mukaan

Alla olevissa taulukoissa on täsmennetty kolmea mittaria.

Taso	Tavoitteen nimi	Prioriteetti	
IO	Mielekkyys käyttää järjestelmää	1 (korkea)	
Tavoitteen kuvaus
Järjestelmän käytön on oltava mielekästä
Alkuehdot
Järjestelmän käytön on oltava niin mielekästä, että tutkijoiden ja spesialistien on mielekästä etsiä muiden ryhmien tuottamia tietoja, eri tahot syöttävät sinne projekti- ja tutkimustietonsa säntillisesti ja lääkärit syöttävät kliinisten kokeiden tulokset säntillisesti.
Arviointi
Tavoitteen arviointia varten kerätään järjestelmän lokeista tilastotietoja kuukauden välein ja arvioidaan seuraavien tekijöiden kehitystä: Käyttäjäkysely, jossa pyydetään arvioimaan järjestelmän käytön mielekkyyttä seuraavin kriteerein: Helppokäyttöisyys Kokemus järjestelmään syötettyjen tietojen tarpeellisuudesta Kokemus järjestelmästä saatavien tietojen tarpeellisuudesta Tehtyjen hakujen määrä Luettujen asiakirjojen lukumäärä ja sanamäärä Järjestelmään syötetyn tekstin määrä asiakirjojen lukumääränä ja sanoina

Taso	Tavoitteen nimi	Prioriteetti	
IO	Asiakirjojen luokittelu	1 (korkea)	
Tavoitteen kuvaus
Asiakirjoja on voitava luokitella monipuolisesti niiden sisällön perusteella
Alkuehdot
Tietojärjestelmän on tarjottava mahdollisuuksia asiakirjojen hierarkkiseen ja epähierarkkiseen luokitteluun.
Arviointi
Tavoitteen arviointia suoritetaan ensin melko nopeasti järjestelmän käyttöönoton jälkeen ja sen jälkeen vuoden välein. Käyttäjien kokemus (kyselyn perusteella) siitä kuinka helpoksi ja joustavaksi he kokevat asiakirjojen luokittelun järjestelmässä kuinka hyvin he kokevat asiakirjojen etsinnän luokittelun perusteella kuinka helppoa luokittelun muuttaminen (transformaatio) on Luokittelujärjestelmän käyttöaste Asiakirjojen vaihtoehtoisten luokittelujen keskimääräinen lukumäärä Arvioinnissa on huomattavaa, että tietojärjestelmän suunnitteluun ei sisälly varsinainen luokittelu, vaan vain tuki luokittelun rakentamiselle.

Taso	Tavoitteen nimi	Prioriteetti	
IO	Kielituki	2 (normaali)	
Tavoitteen kuvaus
Järjestelmän tulee olla käytettävissä paikallisilla kielillä.
Alkuehdot
Järjestelmän tulee täyttää seuraavat monikielisyyden ehdot: Järjestelmän käyttöliittymän tulee olla internationalisoitu siten, se on lokalisoitavissa paikallisille kielille Asiakirjojen kieli pitää voida tallentaa järjestelmään* Samasta asiakirjasta pitää voida olla olemassa useita kieliversioita*
Arviointi
Arviointi tapahtuu seuraamalla käyttöönoton jälkeen, mitä vaikeuksia eri kielisillä käyttäjillä ilmenee. Käyttäjien kokemus siitä, kuinka hyvin järjestelmä palvelee heitä heidän omalla kielellään (silloin kun se todella on tarpeellista) Käyttöliittymien lokalisoinnissa ilmenevien ongelmien määrä Eri kielisten asiakirjojen hallinnassa ilmenevien ongelmien määrä Arvioinnissa tulee kuitenkin arvioida vain järjestelmän itsensä kielitukea; koska järjestelmän ei ole tarkoitus tukea asiakirjojen käännösprosessia (kuten asiakirjakohtaisten käännösten tarpeen määrittelyä), täytyy huomiotta jättää ne ongelmat, jotka aiheutuvat oman kielisten asiakirjaversioiden puutteesta.

*Kannattaa huomata, että asiakirjojen luokittelu niiden kielen perusteella on erikoistapaus asiakirjojen luokittelusta.

CO-tason suunnittelu

Tässä luvussa esitetään CO-tason analyysiin perustuvat mallit kehitettävästä tietojärjestelmästä.

Oliomalli

Tietojärjestelmän oliomalli on esitetty kuvassa 20.

Kuva 20: Oliomalli. Yllä annetun oliomallin avulla tarkastellaan perusluokkia, joita kehitettävässä tietojärjestelmässä käsitellään käyttöliittymä- ja liiketoimintaluokkien kautta. Perusluokista syntyneet oliot ovat tietojärjestelmän keskeisiä kokonaisuuksia, jotka ovat välttämättömiä järjestelmän toimivuuden kannalta. Perusluokista syntyneet oliot tallennetaan (sarjallistetaan) tiedostoihin tai tietokantoihin, jolloin ne ovat pysyviä. Perusluokkiin liittyvissä Anna- ja Aseta-palveluissa kuvassa 5. tarkoitetaan mahdollisuutta ylläpitää/havainnoida luokan attribuutteja.

Luokat ja niiden tarkoitus

Luokka	Kuvaus
Yritys	voidaan hakea yrityksen tiedot suoraan tietojärjestelmään voidaan ylläpitää yrityksen tietoja
Osasto	voidaan poistaa tai lisätä uusi osasto voidaan ylläpitää osaston tietoja
Käyttäjä	voidaan hallinnoida käyttäjien pääsyä tietojärjestelmään voidaan ylläpitää käyttäjän tietoja
Rooli	voidaan hallinnoida käyttäjien rooleja (esim. lääkäri, tutkija)
Ansioluettelo	voidaan ylläpitää käyttäjien ansioluetteloita
Projekti	voidaan ylläpitää projektin tietoja
Tutkimusryhmä	voidaan ylläpitää tutkimusryhmän tietoja
Asiakirja	voidaan ylläpitää tietojärjestelmään kuuluvia asiakirjoja
Tyyppi	voidaan ylläpitää asiakirjojen tyyppejä, jotta asiakirjojen hakeminen tietojärjestelmästä yksinkertaistuu

Luokkien väliset assosiaatiot ja koosteet

YRITYS koostuu OSASTOISTA (vähintään pääkonttori oltava olemassa)

OSASTO koostuu KÄYTTÄJISTÄ

KÄYTTÄJILLÄ voi olla ANSIOLUETTELO

PROJEKTI koostuu TUTKIMUSRYHMISTÄ

TUTKIMUSRYHMÄ koostuu KÄYTTÄJISTÄ

PROJEKTILLA voi olla ASIAKIRJOJA

ASIAKIRJOJA hallinnoi KÄYTTÄJÄT

ASIAKIRJALLA on TYYPPI

Tietomalli

Käytimme tietojärjestelmän tietomallina ER-mallia. ER-mallin tarkoituksena on hahmottaa kokonaisuuksien välisiä suhteita. Tietojärjestelmän ER-kaavio on esitetty kuvassa 21.

Kuva 21: Tietojärjestelmän ER-kaavio.

Entiteetit ja attribuutit

Ansioluettelo-entiteetti sisältää työntekijöiden osaamisalueita

Käyttäjä-entiteetti sisältää työntekijän käyttäjätunnuksen ja salasanan järjestelmään. Lisäksi entiteetti sisältää työntekijän henkilötiedot

Rooli-entiteetti sisältää työntekijän roolitunnukset esim. Lääkäri=1, Tutkija=2, Spesialisti=3, Projektipäällikkö=3, Johtaja=4, Ylläpitäjä=5

Samalla roolitunnukset toimivat käyttäjäoikeuksina järjestelmässä.

Yritys-entiteetti sisältää yrityksen tietoja

Osasto-entiteetti sisältää osaston tietoja

Tutkimusryhmä-entiteetti sisältää tutkimusryhmän tietoja

Projekti-entiteetti sisältää projektin tietoja

Asiakirja-entiteetti sisältää asiakirjan tunnuksen, luomispäivämäärän, muutospäivämäärän, kielen, datan, prioriteetin (asiakirjan tärkeys). Lisäksi Asiakirja-entiteetti sisältää salaisuusluokituksen, josta nähdään onko asiakirja projektille kuuluvaa tietoa vai julkista tietoa.

Tyyppi-entiteetti sisältää asiakirjan tyypin tunnukset esim. Lääkeaine=1, Testitulos=2 jne. Tyyppi-entiteetillä tehdään helpommaksi asiakirjoihin kohdistuvat kyselyt.

Relaatiot

PharmaCo yrityksellä on monta osastoa. Yhdessä osastossa on kirjoilla monia työntekijöitä. Käyttäjä voi kuulua moneen tutkimusryhmään, joissa hänellä voi olla yksi tai useampi rooli (esim. Tutkija, spesialisti, projektipäällikkö, johtaja, lääkäri, ylläpitäjä), projektista riippuen. Käyttäjällä on roolien mukaiset käyttöoikeudet eri tutkimusprojektien aineistoihin. Lisäksi työntekijällä voi olla ansioluettelo.

Projektia johtaa yksi työntekijä (rooli: projektipäällikkö) ja projektiin kuuluu monta tutkimusryhmää. Lisäksi eri projektit voivat käyttää samoja tutkimusryhmiä.

Projekteihin kuuluu monta asiakirjaa, josta vastaa/luo työntekijä. Lisäksi asiakirja on tietyn tyyppinen.

Käyttöoikeusmatriisi

Tietojärjestelmän käyttöoikeusmatriisi on esitetty kuvassa 22.

Kuva 22: Käyttöoikeusmatriisi.

Arviointikriteerit

Alla on esitetty CO-tason arviointikriteerit, PIOCO-mallin tehokkuus kriteerien hierarkian mukaisesti.

Järjestelmän tuoma käytännön hyöty organisaatioon.

Toiminnalliset kustannukset

Normaalien toimintojen kustannukset

Käyttäjien tehokkuus järjestelmässä

Järjestelmä vähentää työn määrää

Työn teko nopeutuu

Tekninen tehokkuus ja vakaus

Tiedonsiirron määrät kasvavat

Järjestelmää käytetään aktiivisesti

Järjestelmän resurssit riittävät käytössä

Erikoistilanteiden ilmeneminen

Järjestelmän luotettavuus

Teknisten laitteiden toimivuus ja luotettavuus

Ohjelmistojen toimivuus ja luotettavuus

Järjestelmän palautus ongelmatilanteiden jälkeen.

Järjestelmä on helppo ottaa käyttöön uudelleen ongelmatilanteiden tapahtuessa.

Virheraportoinnin kattavuus

Käyttöönottokustannukset

Käyttöönoton aikataulun toteutuminen

Kustannukset

Laitteistokustannukset

Ohjelmistokustannukset

Henkilöstön koulutuskustannukset

Implementointikustannukset

Ylläpidon kustannukset

Ylläpidon helppous

Järjestelmän päivitettävyys

Alla olevissa taulukoissa on esitetty kaksi tärkeintä mittaria.

Taso	Tavoitteen nimi	Prioriteetti	
C/O	Tiedonsiirron määrä kasvaa	2 (keskitaso)	
Tavoitteen kuvaus
Järjestelmän tulee lisätä tiedonkulkua ja tiedonsiirtoa eri käyttäjien välillä. Käytännössä voidaan todeta että tiedonsiirron määrä käyttäjien välillä vaikuttaa suoraan siihen, kuinka paljon käyttäjät vastaanottavat informaatiota projektien ja tutkimusten etenemisestä.
Alkuehdot
Järjestelmään kirjataan tietoa projektien etenemisestä sekä tutkimustiedoista jatkuvasti, sekä tietoa julkistetaan myös organisaation sisällä sekä ulkopuolella.
Arviointi
Tavoitteen arviointia suoritetaan käyttöönoton ja riittävän henkilöstö-koulutuksen jälkeen ja sen jälkeen vuoden välein. Tiedonsiirron datamäärät Henkilöstön tietoisuus projektien sisällöstä ja aikatauluista Organisaation sisäisen informaatiokulun paraneminen
Johtopäätökset
Mikäli voidaan todeta että järjestelmä on lisännyt henkilöstön tietoisuutta projektien sisällöstä sekä aikatauluista, voidaan todeta että järjestelmä on täyttänyt tämän asetetun kriteerin.

Taso	Tavoitteen nimi	Prioriteetti	
C/O	Järjestelmä vähentää työn määrää	1 (korkea)	
Tavoitteen kuvaus
Järjestelmän tulee vähentää käytännön fyysisen työn määrää ja edesauttaa työskentelyprosessin nopeutumista. Käytännössä järjestelmän tiedon välityksen avulla vältetään ylimääräistä ja päällekkäistä työtä.
Alkuehdot
Järjestelmään kirjataan tietoa projektien etenemisestä sekä tutkimustiedoista jatkuvasti, sekä tietoa julkistetaan myös organisaation sisällä sekä ulkopuolella.
Arviointi
Tavoitteen arviointia suoritetaan käyttöönoton ja riittävän henkilöstö-koulutuksen jälkeen ja sen jälkeen vuoden välein. Löytyneiden päällekkäisten toimintojen lukumäärä Löytyneiden päällekkäisten toimintojen arvioitu tuntimäärä Järjestelmään kirjattujen projektien tuntimäärä Tutkimusprojektien kokonaiskesto
Johtopäätökset
Mikäli voidaan todeta että järjestelmä on vähentänyt kokonaistyön määrää organisaatiossa ja edesauttanut toiminnanohjauksen kehittymisessä, voidaan todeta että järjestelmä on täyttänyt tämän asetetun kriteerin.

Portaaliohjelmiston valinta

Kuten alkuperäisessä tehtävänannossa määriteltiin, oli toimittajan tehtävänä valita tietojärjestelmän toteuttamisessa käytettävä portaaliohjelmisto.

Valinnassa arvioitiin seuraavien kolmen portaali- tai sisällönhallintajärjestelmän soveltuvuutta tietojärjestelmän alustaksi.

Plone (http://www.plone.org/)

Python-pohjainen

Helppo laajennettavuus

(Puutteena) Suhteellinen hitaus verrattuna Java-ratkaisuihin

Perustana

Zope, Python-pohjainen sovelluspalvelin (http://www.zope.org/)

CMF-sisällönhallintakehys (http://cmf.zope.org/)

Avointa lähdekoodia

Paljon valmiita ominaisuuksia

Tuki internationalisoinnille ja lokalisoinnille

Sisällön kehittynyt luokittelu, indeksointi ja haku (Zope)

Kehittynyt ja laajennettava käyttöoikeuksien määrittely ja hallinta (Zope)

Säilyvyys - riippumaton kaupallisista toimittajista

(Puutteena) Ei keskitettyä tuotetukea

Tuotetuki ostettavissa paikallisesti maasta riippumattomasti

Gluecode (http://www.gluecode.com/)

Java-pohjainen, JBoss, Tomcat

Avointa lähdekoodia

Hienorakenteinen käyttöoikeuksien määrittely

Hyvä tuotetuki Yhdysvalloissa

Jatkuvuudesta ei takeita

Crasmanager (http://www.crasmanager.fi/)

PHP

Sivujen määrittely edelleen teknisesti haastavaa

Käyttöoikeuksien määrittely karkeaa

Hyvä tuotetuki

Jatkuvuudesta ei takeita

Näistä Plone todettiin perusominaisuuksiltaan monipuolisimmaksi ja tietojärjestelmän erikoistarpeisiin parhaiten soveltuvimmaksi. Oleellista sen valinnassa olivat ohjelmiston tarjoamat valmiit ominaisuudet, erityisesti internationalisointi- ja lokalisointituki ja pääsyoikeuksien monipuolinen hallinta. Avoin lähdekoodi ja ilmaisuvoimainen oliosuuntautunut rakenne mahdollistavat syvällisen räätälöinnin omaan tarkoitukseen. Tämä on oleellista erityisesti, jos tietojärjestelmä halutaan hajauttaa tehokkaasti eri maissa oleviin, paikallisia tutkimusryhmiä palveleviin palvelimiin, mitä vaaditaan erityisesti käytön nopeuden takaamiseksi.

Toimitusprojekti

Projektiryhmä

Toimittajan projektiryhmän kokoonpano rooleineen on seuraava:

Tommi Mertsalmi, projektipäällikkö

Pyry Liukas, myyntiedustaja

Jukka Laukkanen, järjestelmäsuunnittelija

Marko Grönroos, järjestelmäsuunnittelija, projektisihteeri

Toimintatapa

Toimittajan projektiryhmällä oli kokous asiakkaan ohjausryhmän kanssa yleensä joka viikon perjantaina. Projektiryhmä esitteli asiakastapaamisissa kehittämänsä mallin, jota ohjausryhmän ohjaamana korjattiin ja kehitettiin eteenpäin. Kehitetyt mallit esitettiin viikoittaisessa väliraportissa, joka toimitettiin asiakkaalle kokouskutsun ohella aina asiakastapaamista edeltävänä keskiviikkona.

Toimittajan projektiryhmä teki asiakastapaamisista muistiinpanot ja toimitti ne ohjausryhmälle viimeistään seuraavan väliraportin ohessa.

Toimittajan projektiryhmä toimi pääsääntöisesti siten, että sillä oli viikoittainen projektipalaveri, jossa ryhmä kehitti seuraavassa väliraportissa esitettävät mallit. Joissain tapauksissa mallien kehitys annettiin eri suunnittelijoiden vastuulle, jotka toimittivat mallien luonnokset projektisihteerille väliraporttiin sisällytettäviksi. Sihteeri koosti väliraportin kehitetyistä malleista ja muista esille tulleista seikoista.

Projektiaikataulu

Alla projektiaikataulu ja tuntimäärien toteutuma.

Päävaihe	Tapahtuma	Päivämäärä	Aika-arvio	Toteutuma
P-mallin kehitys	1. väliraportti 15.10.03 45h 73h I asiakaskokous 17.10.03 2. väliraportti 22.10.03 45h 36h II asiakaskokous 24.10.03 Korj. 2. väliraportti 29.10.03 - 22h Projektikokous 31.10.03
IO-mallin kehitys	3. väliraportti 05.11.03 45h 17h III asiakaskokous 07.11.03
CO-mallin kehitys	4. väliraportti 12.11.03 45h 22h IV asiakaskokous 14.11.03 5. väliraportti 19.11.03 45h 35h V asiakaskokous 21.11.03
Loppuraportti	27.11.03	45h	20h
	Yhteensä	270h	225h

Tuntimäärät ovat projektiryhmän kokonaistuntimääriä. Mukana on asiakastapaamisten (1h/viikko/henkilö) ja sisäisten projektikokousten (n. 1-4h / viikko / henkilö) tunnit.

Aika-arvio alittui, koska tuntiarviot oli tehty pitkälti ensimmäisten viikkojen perusteella, jolloin aikaa kului paljon tehtävään tutustumiseen ja asiakirjamallien, web-sivuston ja muiden perusasioiden tekemiseen.

Yhteenveto

Yleistä

Toimittaja on tässä loppuraportissa esittänyt tietojärjestelmän kehittäminen kokonaisuudessaan, sisältäen tehtävänmäärityksen, kaikkien suunnitteluvaiheiden tuottamat lopulliset mallit ja vaiheiden arvioinnin. Suunnitteluosuuden lopuksi esitettiin valinta tietojärjestelmän toteuttamiseen käytettävästä portaaliohjelmistosta.

Toimittaja esitti myös suunnitteluprojektin organisaatiota, toimintaa ja aikatauluja koskevan koosteen.

Arvioimme lopputuloksia seuraavasti arvosana-asteikolla 1-3:

Projektin tulos:	2+

Itse projekti:	2

Opponoijat:	2

Arviot ovat melko konservatiivisia. Perustelut alla.

Arvio saavutetuista tuloksista

Projektissa saatiin toteutettua kaikki vaaditut analyysin ja suunnittelun vaiheet kaikilla vaadituilla menetelmillä.

Asiakasorganisaation ja toimintaprosessin mallintaminen jäi kuitenkin äärimmäisen karkealle tasolle verrattuna kuviteltavaan todelliseen monikansallisen lääkeyrityksen tuotekehityksen tietojärjestelmän kehitykseen. Lopputulos oli siten puhdasta roskaa (jos sitä vertaa todellisen maailman vaatimustasoon). Tämä on kuitenkin melko selvää, koska organisaatio ja toimintaprosessi olisivat todellisuudessa niin monimutkaiset ja huomioon otettavia tekijöitä olisi niin paljon, ettei niitä ole näissä aikarajoissa mitenkään mahdollista käsitellä, eikä opponenttienkaan voida odottaa tuntevan niitä edes pääpiirteittäin.

PIOCO-metamallin mukaisista kriteereistä vain tärkeimpiä saatiin täsmennettyä merkittävällä tarkkuudella. Aiemmissa vaiheissa määritellyt kriteerit saatiin pääosin täytettyä. Käsitemalli saatiin tehtyä vain yhdestä näkökulmasta; ehkä useammasta olisi ollut parempi.

Eri mallien välinen yhteys jäi osittain hieman huteraksi, mikä johtui paljolti liian tiukoista aikarajoitteista. Eri suunnittelijoiden oli pakko tehdä suunnittelutyötä osittain rinnakkain ilman riittävää aikaa kommunikoida yhden mallin sisältöä tai muutoksia sitä loogisesti seuraavan mallin suunnittelijalle. Mallien validiutta ei myöskään aina ehditty verifioimaan tarkasti koko kehitysryhmän toimesta ja asiakastapaamisissa oli liian vähän aikaa verifioida ne opponenteilla.

Kehityksen aikana jäi hieman epäselväksi, mitä merkitystä alkuperäisessä tehtävänannossa (toimittajaosapuolelle annetussa paperissa) olleella portaaliohjelmiston valintatehtävällä oli. Ymmärsimme, ettei siihen tarvitse kiinnittää huomiota. Kuitenkin, varsinkin CO-tasolle siirryttäessä oli selvää, että portaaliohjelmiston omat ominaisuudet vaikuttaisivat paljon, sillä useimmissa portaaliohjelmistoissa tai sisällönhallintajärjestelmissä on jo lähes kaikki ne ominaisuudet, joita CO-tasolla suunniteltiin olioiden attribuuteiksi. Nythän asiakkaan omaverkkoa suunniteltiin ikään kuin mitään valmista portaaliohjelmistoa ei olisi käytettykään. Siksi tietokeskeistä suunnittelua oli melko turhaa tehdä riippumatta portaaliohjelmistosta. Sen valinta ja siihen tutustuminen CO-tasolle siirryttäessä olisi kuitenkin ollut niin työlästä, ettei siihen ollut mitään mahdollisuuksia, joten tämä puute on lähinnä teoreettinen.

Tietojärjestelmästä aikaansaatu suunnitelma vaikuttaa kuitenkin pääpiirteittäin riittävältä asiakkaan tarpeisiin ja toteuttaa keskeisimmät vaatimukset.

Arvio projektista

Projektissa pysyttiin aikataulussa melko hyvin ja kaikki mitä piti tehdä saatiin lopulta tehtyä, joskin tämä ehkä tapahtui laadun kustannuksella.

Projektiryhmän toiminta oli pääasiassa tiimityöskentelyä, projektipäällikön hallinnollisen roolin jäädessä pieneksi. Etuna tässä kenties oli, että kukin sai keskittyä itseään kiinnostavaan suuntaan. Heikkoutena kuitenkin oli, että toiminnan koordinointi jäi kunkin omalle vastuulle. Kun ei ollut varmuutta omista tehtävistä, ei välttämättä tehty niin paljoa kuin olisi voitu ja työtehtävät eivät ehkä jakautuneet aivan maksimaalisen tehokkaasti.

Toimintaa olisi kenties voitu tehostaa paremmalla koordinoinnilla. Esimerkiksi, suunnittelutyön tekeminen keskittyi nyt pääasiassa (vaikkei suinkaan täysin!) projektikokouksiin. On ajateltavissa, että niissä nopeasti laaditut mallit eivät välttämättä olleet niin laadukkaita kuin mitä ne olisivat voineet olla, jos tekijät olisivat tehneet ne itsenäisesti rauhassa miettien, kuten demotehtävät tavallisesti tehdään. Tätä on kuitenkin vaikea arvioida - voi olla että projektikokousten olisi pitänyt riittää, pärjäsiväthän muut ryhmät ilmeisesti aivan hyvin pienemmälläkin tuntimäärällä.

Sisällön ja erityisesti täytemateriaalin tuottaminen jäi turhan paljon projektisihteerin vastuulle. Yhdessä kyllä saatiin tehtyä oleellisimmat mallit piirroksina, mutta niiden varsinainen konepiirtäminen, viimeisteleminen ja selitysten kirjoittaminen jäivät usein (muttei toki aina) hieman puutteellisiksi ja sihteerin harteille, samoin kuin viime hetkellä huomattujen puutteiden korjaaminen. Esimerkiksi, tätäkään tekstiä ei sihteerin olisi kuulunut tarvita kirjoittaa itse viimeisen päivän pikkutunneilla.

Osallistujien läsnäolo asiakastapaamisissa oli kiitettävä, poissaoloja oli vain yksi. Myöhästymisiä oli kuitenkin turhan paljon. Osanotto projektikokouksiin (ja siten viikoittaiseen työpanokseen) oli jossain määrin vaisumpaa.

Arvio opponoinnin tasosta

Toimittajan projektiryhmä sai asiakkaan ohjausryhmältä kohtuullisen selkeää palautetta ainakin keskeisimmistä vaatimuksista. Kuitenkin yksityiskohtien kritiikki jäi hieman heikoksi, varsinkin loppupuolella.

Opponoijilla olisi tietysti ollut hyvä olla enemmän todellista tietoa lääkekehityksen yksityiskohdista, mutta se lienee epärealistinen vaatimus. Lääkekehitys on kuitenkin varmasti vieraampi ja kauempana yleistiedosta kuin esimerkiksi autopaikoituksen käytännöt, jotka ovat useimmille arkipäivää.

Arvio käytetyistä metodologioista

PIOCO-metamallin käyttäminen tarjosi hyvän korkean tason jäsennyksen tietojärjestelmän kehityksen etenemiselle. Eri vaiheiden arviointikriteerien soveltaminen osoittautui melko vaikeaksi tehtäväksi, johtuen pääasiassa hyvien esimerkkien puutteesta. PIOCO-malli jää Iivari-Koskelan artikkelin perusteella muutenkin melko vaikeaselkoiseksi, mikä aiheutti paljon epätietoisuutta varsinkin alkuvaiheessa.

Varsinaisista analyysi- ja suunnittelumenetelmistä kaikki vaikuttivat järjestelmän kehittämisen kannalta mielekkäiltä ja niiden käyttö eteni loogisessa järjestyksessä. Todellisessa tapauksessa asiakkaan ohjausryhmän tietotaso ei välttämättä riittäisi muiden kuin P-tason mallien helpolle ymmärtämiselle.

PharmaCo-toimitusprojekti, loppuraportti

Yhteenveto

Sivu 39/39

PharmaCo-toimitusprojekti, loppuraportti

Marko Grönroos

2003-05-24T04:33:50

Marko Grönroos