Tietojärjestelmän kehittäminen. Survey Inc. Loppuraportti

Transkriptio

1 Tietojärjestelmän kehittäminen Ryhmätyö Survey Inc. Loppuraportti RYHMÄ C2 Turun yliopisto, Tietojenkäsittelytieteet 27. marraskuuta 2003 Laiterla, Päivi Nikkanen, Toni Windahl, Tomas Lehto, Antti

2 Survey Inc:n kehitysprojekti Tarjouksenteko- ja aikataulutusjärjestelmän kehitysprojekti Abstrakti Projektin tarkoituksena oli tutkia Survey Inc.-yrityksen ongelmia ja selvittää tapoja, joilla niitä voitaisiin ratkaista. Hahmotimme ongelmia ja nykytilannetta yhdessä asiakkaan kanssa useassa palaverissa käyttäen useita mallinnusmenetelmiä, joiden tulokset on tiivistetty tähän loppuraporttiin. Lyhyesti voidaan sanoa, että asiakkaan pääsääntöisenä ongelmana oli riittävän sujuva tietojen saanti tarjousten tekemistä ja projektien aikataulutusta varten. Yrityksen keskeisten järjestelmien, Experience Databasen ja ACE:n automaatiotaso ei ollut riittävä ja tietojen saaminen ja päivitys niistä oli joustamatonta, samoin tieto ei ollut ehyttä. Lisäksi laitteistoalusta oli kirjavaa ja osittain vanhaa. Asiakkaalla oli halukkuutta järjestelmän uusimiseen mutta ei halunnut panostaa merkittävissä määrin laitteistokannan uudistamiseen. Suunniteltiin uusi järjestelmä, jossa tiedon saanti ja päivittyminen onnistuu paremmin, ja tiedon eheys varmistetaan. Olemme käyttäneet seuraavia menetelmiä projektimme esitutkimus- ja suunnitteluvaiheissa: Rich Picture, juurimäärittelyt, käsitemallit, mittarit, elinkaarimallit, oliomallinnus, tietovuokaaviot, ER-mallit ja käyttöliittymäprototyypit. 2

3 Sisältö 1 Johdanto Kohteen esittely Projektiorganisaatio Tietojärjestelmän kehittäminen Analyysivaihe Kohdeorganisaation kuvaus Organisaatiokaavio Esitutkimus Estimoinnin suorittaminen Projektin toteutus ja koordinointi Nykyiset tietojärjestelmät Root definition -määritykset Rich picture Käsitemallit P-tason mittarit P-tason arviointia Kehitysalueen rajaus Rajausvaihtoehdot ACE-tiimin kehittäminen UUJ Rich picture uudistetusta järjestelmästä IO-tason rakenteellinen suunnittelu Elinkaarimallit Tietovuokaaviot IO-tason mittarit CO-tason suunnittelu Oliomalli ER-malli CO-tason mittarit Käyttöoikeusmatriisi Projekti Projektiorganisaatio Aikataulu Projektin riskit Projektin arviointia Ryhmätyön arviointia Lopputuloksen arviointia

4 1 Johdanto Tämän raportin rakenne on seuraavanlainen: Abstrakti Johdanto Tietojärjestelmän kehittäminen Sisältää kohteen kuvauksen, analyysin ja suunnittelun (rakenteinen suunnittelu, tietomallinnus, oliomallinnus), mittarit, käyttöliittymät. Projektin kuvaus Esittelee projektiorganisaation, projektisuunnitelman, aikataulusuunnitelman ja -toteutuman, sekä arviointia projektiorganisaation toiminnasta. 1.1 Kohteen esittely Survey Inc. on tunnettu amerikkalainen markkinointitutkimusyritys, jolla on useita toimipisteitä Yhdysvalloissa. Yrityksen asiakaskuntaan kuuluu useita tunnettuja ja suuria liikeyrityksiä. Survey Inc. tarjoaa muun muassa asiakasprofilointeja, erilaisia tyytyväisyystutkimuksia, tulosanalyyseja ja markkinoinnin kehittämisprojekteja. Organisaatioltaan Survey Inc. on jaettu toimintojen mukaan jaoksiksi, joissa toimii useita osastoja. Survey Inc. päämääriä ovat projektien tehokas toteuttaminen, tuloksen tekeminen ja asiakastyytyväisyys. Kehitysprojektissa etsittiin keinoja näiden tavoitteiden konkreettiseen toteuttamiseen ja mittaamiseen yrityksen toimintatapojen kehittämisen kautta. Projekti eteni pääpiirteittäin seuraavissa vaiheissa: Projektiorganisaation muodostaminen Materiaaliin tutustuminen Alustavan projektisuunnitelman ja aikataulun muodostaminen Esitutkimus Rich Picture, juurimäärittelyt Käsitemallit Mittarit Elinkaarimallit Oliomalli 4

5 Tietovuokaavio ER-malli Käyttöliittymäprotyypit Esitutkimuksen ja suunnittelun perusteella päädyttiin ehdottamaan asiakkaalle uuden järjestelmän UUJ toteuttamista. UUJ ratkaisisi merkittävimmät tarjouksiin ja aikataulutukseen liittyvät ongelmat ja WWW-pohjaisella käyttöliittymällä varustettuna mahdollistaisi järjestelmän käytön kaikilta yrityksessä käytössä olevilta työasemakoneilta, joita oli useita erilaisia ja eriikäisiä. 1.2 Projektiorganisaatio Projektiorganisaatio koostui seuraavista rooleista: Projektipäällikkö, projektisihteeri, myyntiedustaja/konsultti, atk-suunnittelija. Projektisuunnitelma luotiin taulukkolaskentaohjelmalla taulukkona, johon on merkitty projektin osa-alueet (esitutkimus, projektinhallinta, vaatimusmäärittely, suunnittelu, dokumentointi, implementaatio, testaus, käyttöönotto), sekä niiden arvioidut aloitus- ja valmistumisajat ja tuntitoteutumat. Alustava projektiaikataulu piti yllättävän hyvin paikkansa, vain vaatimusmäärittelyssä oli suhteellisen isoa heittoa (arvioitu työmäärä 10 tuntia, toteutuma 15). Projektiorganisaation pääasialliset toimintatavat olivat: projektikokoukset, asiakastapaamiset ja itsenäinen työskentely projektikokouksissa sovitun työnjaon mukaisesti. Lisäksi välitettiin tietoa ryhmän sisällä kättäen sähköpostia. 2 Tietojärjestelmän kehittäminen 2.1 Analyysivaihe P-tason analyysia aloitettiin tutustumalla ennalta jaettuun taustamateriaaliin. Materiaalin pohjalta pyrittiin tekemään alustavaa kohteen kuvausta ensimmäiseen väliraporttiin. Kuvauksessa keskityttiin Survey Inc.:in organisaation kuvaukseen ja yrityksen toimintaprosessien hahmottamiseen. Kohdetta mallinnettiin sanallisen kuvauksen lisäksi Rich Picturella ja Root Definition -määritelmillä. Ensimmäisen asiakastapaamisen jälkeen kohteesta saatiin runsaasti uutta informaatiota ja aikaisemmin tehtyjä malleja pystyttiin tarkentamaan toiseen väliraporttiin. Erityisesti Rich Picture tarkentui toimijoiden tehtävänkuvien osalta. Root Definition -määritelmien pohjalta tehtiin alustavia käsitemalleja yrityksestä, joita tarkennettiin myöhemmin ohjausryhmältä saadun palautteen pohjalta. 5

6 P-tasolle etsittiin mittareita, joilla pyrittiin varmistumaan järjestelmän laadusta organisatorisella tasolla. Kolmannessa asiakastapaamisessa asiakkaille esitettiin kaksi vaihtoehtoista rajausta, joista asiakkaat valitsivat laajemman. Rajauksen varmistuttua pystyttiin siirtymään P-tasolta IO-tason rakenteelliseen suunnitteluun. 2.2 Kohdeorganisaation kuvaus Survey Inc. on hyvin tunnettu ja perinteikäs amerikkalainen markkinatutkimusyritys, jolla on konttoreita Atlantassa, Bostonissa, Cincinnatissa, Dallasissa, Detroitissa, Los Angelesissa, New Yorkissa, Philidelphiassa ja San Fraciscossa. Asiakaskuntaa kuuluvat monet hyvin tunnetut ja suuret liikeyritykset. Survey Inc:in tarkoituksena on "Auttaa asiakkaita määrittelemään kohderyhmän ja seuraaman näiden tarpeita, jotta Survey Inc. voisi tarjota luotettavan perustan jatkuvalle laadun parantamiselle. Tämä tähtää asiakastyytyväisyyden parantamiseen ja säilyttämiseen". Survey Inc. tarjoaa asiakkailleen monenlaisia palveluja. Näitä ovat mm: Ulkoisten ja/tai sisäisten asiakkaiden profilointi Tulosanalyysit tavoitteiden saavuttamisesta Tuote-, palvelu- asiakastyytyväisyystutkimukset Avustus suunnittelussa, implementoinnissa sekä koulutuksessa, koskien uusien ohjelmien arviontiprosesseja. Jotta Survey Inc. voisi tarjota yllä mainittuja palveluja on sen myös tarjottava kattavia tiedonkeruu mahdollisuuksia: Puhelin- ja postikyselyt Henkilökohtaiset haastattelut ja ryhmätapaamiset Asiakaspalautekyselyt Sekä perinteiset että telekonferenssi kohderyhmä haastattelut Vertailua muihin alan parhaisiin yrityksiin Mysteeriostaja (Asiakkaaksi tekeytyminen palvelun laadun selvittämiseksi) 2.3 Organisaatiokaavio Survey Inc. on rakenteeltaan hyvin suoraviivainen, sillä se on organisoitu tehtävien perusteella jaoksiksi, joita johtaa yhtiön presidentti. Jokaisessa jaoksessa voi olla monia osastoja. Organisaatiokaavio on esitetty kuvassa 1. 6

7 Kuva 1: Survey Inc:n organisaatiokaaavio 2.4 Esitutkimus Esitutkimusvaiheessa yrityksen Account Executivet (AE) suunnittelevat yhdessä asiakkaan kanssa mahdolliset tutkimuskohteet ja niissä käytettävät tutkimusmenetelmät ja tulosanalyysit. Vaiheen tavoitteena on kerätä tulevasta projektista mahdollisimman paljon informaatiota alustavaan projektisuunnitelmaan sekä kustannus- ja kestoestimaattien tekemiseen. Näiden pohjalta AE tekee projektisuunnitelman hinta- ja kestoarvioineen, joka lähetetään asiakkaalle hyväksyttäväksi. Mitä nopeammin ja tarkemmin projektisuunnitelmaa pystytään tarjoamaan, sitä todennäköisemmin asiakas hyväksyy tarjouksen. 2.5 Estimoinnin suorittaminen Projektin kulujen ja keston arviointiin käytetään ACE-järjestelmää sekä henkilökunnan omaa asiantuntemusta. ACE-järjestelmä hyödyntää Experience Database -tietokantaa, johon on talletettu tiedot aikaisemmista projekteista, niiden kuluista ja kestoista. Tietokanta ei kuitenkaan vielä sisällä kaikkia kohteita, eikä pysty antamaan riittävän tarkkoja arvioita. Lisäksi kannan päivittyminen ei tapahdu automaattisesti, kun uutta projekti-informaatiota lisätään. Henkilökunnan omaa osaamista ja kokemuspohjaa tulee hyödyntää jatkuvasti projektien aikataulutuksessa. Tämä pidentää arvioinnin teon kestoa ja riski, että asiakas hylkää tarjouksen kasvaa. ACE-järjestelmän kehittäminen toimivammaksi nopeuttaisi huomattavasti projektien aikataulutusta. 2.6 Projektin toteutus ja koordinointi Asiakkaan hyväksyessä projektitarjouksen, työ kirjataan projektitietokantaan, johon syötetään tiedot asiakkaasta, sekä projektin sisältötiedot. Projektin käynnistyessä projektin johtoon astuu Senior Account Manager (SAM), joka vastaa projektin keskeisten toimintojen suorittamisesta. Työlle luodaan myös numero ja kirjanpidossa aletaan seurata työn etenemistä. SAM tekee 7

8 projektille aikataulun ja suoritusjärjestyksen. Tärkeimmät suunnitellut virstanpylväät projektissa ovat koko projektin aloitus ja lopetus, sekä kenttätutkimuksen ajankohta. Asiakkaat ovat usein halukkaita saamaan käyttöönsä pelkät tutkimustulokset ennen analyysia, joten kenttätutkimus on tärkein osa projektia. Projektisuunnitelman valmistuttua SAM lähettää sen sähköpostitse yrityksen osastoille, jotka alkavat itsenäisesti suorittaa niille annettuja tehtäviä. Tavoitteena on projektin koordinoitu suoritus useiden osastojen välillä, jolloin määritellyssä aikataulussa pysyminen on erityisen tärkeää. Aikataulun määrittelyvaikeuksien vuoksi osastot eivät aina pysy aikataulussa, jolloin osaston johtaja ja SAM joutuvat muokkaamaan aikataulua uudelleen. Tämä aiheuttaa huomattavasti lisätyötä ja kaoottisuutta projektin suorituksessa, koska tehdyt muutokset heijastuvat myös muiden osastojen toimintaan. Töiden tilausmäärät yrityksessä ovat kasvussa, jolloin nykyinen töiden aikataulutussysteemi on osoittautunut monimutkaiseksi ja aikaavieväksi. Osastojen välinen koordinointiongelmat aiheuttavat lisätyötä projektijohtoon ja projektin suorittaminen saattaa viivästyä. Keskeisiä kehityskohteita yrityksessä ovat aikataulutukseen liittyvät järjestelmät eli ACE ja Experience Database. Lisäksi yrityksen organisaatiorakenne tulee myös asettaa tarkastelun kohteeksi ja etsiä mahdollisia toimintaa helpottavia organisaatiomuutoksia. 2.7 Nykyiset tietojärjestelmät Yrityksen tietokone- ja järjestelmäkanta oli kirjavaa, ja työskentelyssä käytettiin eri sovelluksia. Niinpä eri tiedostoformaateista aiheutui ongelmia tiedonjaossa. Oma ongelmansa olivat käyttäjien itsensä tekemät huonosti suunnitellut ohjelmat. Yrityksen toimiala oli kasvanut huomattavasti ja lisääntyneiden työtehtävien vuoksi yrityksen projektien hallinta oli noussut yrityksen toiminnan kannalta tärkeämpään rooliin. Tietojärjestelmien kehittämiseksi yritys käynnisti vuonna 1993 järjestelmänkehityshankkeen tarkoituksenaan tehostaa nykyisiä toimintoja ja parantaa tulevaisuudennäkymiä. Työ annettiin ulkopuolisen tahon tehtäväksi. Järjestelmän kehittämisen aluksi toteutettiin vaatimusmäärittely. Tätä tehtävää varten yrityksen eri osastoilta koottiin johtohenkilöistä koostunut ryhmä, jota haastattelemalla saatiin tietoa yrityksen toiminnasta kehitystyön pohjaksi. Hyvin sujuneiden tutkimusten perusteella todettiin yrityksen tarvitsevan kokonaisvaltaisen tietojärjestelmän. Toteutus päätettiin aloittaa kirjanpitojärjestelmästä, joka hankittiin valmiina ohjelmistona. Kirjanpitojärjestelmä saatiin käyttöön vuonna 1995, jonka jälkeen yritys halusi jatkaa tietojärjestelmänsä kehittämistä projektinhallinnan (job scheduling) osalta. 8

9 ACE ACE on yrityksen työntekijöiden FoxPro:lla kehittämä automaattinen kulujen ja keston arvioimiseen käytetty järjestelmä. ACE on syntynyt suoraan yrityksen tarpeisiin, "ad-hoc-tyylisesti, joten järjestelmän suunnitteluun ja toteutukseen ei ole käytetty aikoinaan tarpeeksi resursseja. ACE hyödyntää Experience Database -tietokantaa arviointia suorittaessa. Arviot eivät kuitenkaan järjestelmien puutteiden vuoksi ole riittävän tarkkoja ja kattavia, joten ACE:a ei pystytä käyttämään täysipainoisesti. Experience Database Experience Database on tietokanta, johon on talletettu tiedot yrityksen aiemmin suorittamista projekteista. Projekteista on kirjattu ylös niiden kestot, kulut sekä niissä käytetyt tutkimusmenetelmät. Nykyisellään tietokanta ei kuitenkaan sisällä kaikkia projekteja eikä myöskään päivity automaattisesti uusia projekteja lisätessä. Lisäksi tietokanta kärsii tietojen redundanssista ja anomalioista. Aikaisempien projektien tietojen kerääminen on kuitenkin arvokasta, koska useat projektit sisältävät yhteisiä piirteitä. Job Order Database Job Order Database sisältää tiedot asiakkaasta ja asiakkaan projekteista sekä niiden sisällöistä. Experience Databasen tapaan Job Order Database kärsii tietojen redundanssista ja anomalioista. 2.8 Root definition -määritykset Kohteesta tehtiin seuraavia CATWOE analyysillä seuraavanlaiset Root definition -määritykset: C A T W O E Osastot SAM Töiden aikataulutus Aikataulussa pitää pysyä Survey Inc. Business SAM tekee osastoille aikataulut, joita jokaisen osaston tulee pystyä noudattamaan. Aikatauluissa pysyminen on tärkeää, jotta Survey Inc. menestyisi liiketoiminnassaan. 9

10 C A T W O E Asiakas AE Alustava projektisuunnitelma Suunnitelman tulee olla tarkka ja valmistua nopeasti Survey Inc. Suunnitelman hyväksyminen ja toteutuminen Account Executive tekee asiakkaalle alustavan projektisuunnitelman, jonka tarkkuuden tulisi olla mahdollisimman hyvä. Onnistuminen parantaa Survey Inc:in mahdollisuuksia saada projekti myydyksi ja toteutetuksi suunnitellulla tavalla. 2.9 Rich picture Kuvissa 2, 3 ja 6 (sivulla 20) on esitelty yrityksestä projektin eri vaiheissa tehdyt Rich picture kuvaukset. Ensimmäisessä kuvassa on hahmoteltu järjestelmän olemusta arvioidemme ja kirjallisen materiaalin perusteella ennen ensimmäistä asiakastapaamista. Toisessa kuvassa on asiakkaan avustuksella korjattu malli järjestelmästä ennen muutosta ja kolmannessa suunnittelemamme muutoksen jälkeen. 10

11 Kuva 2: Ensimmäinen, taustamateriaalin pohjalta tehty Rich picture. 11

12 Kuva 3: Toinen, P-tason päättävä Rich picture 12

13 2.10 Käsitemallit Root definition määritelmien pohjalta tehdyt käsitemallit on esitetty kuvissa 4 ja 5. Kuva 4: AE:sta tehdyn juurimääritelmän perusteella tehty käsitemalli 13

14 Kuva 5: SAM:sta tehdyn juurimääritelmän perusteella tehty käsitemalli. 14

15 2.11 P-tason mittarit P-tason mittareiksi valittiin tarjouksen teon ja aikataulutuksen tehostaminen, koska nämä olivat keskeiset ongelmat järjestelmässä. Tarjouksen teon nopeutumisella saadaan ainakin kaksi selvästi osoitettavaa etua: itse työhön jäävä aika pitenee ja jos tarjouksen tekeminen kestää liian kauan, asiakas on jo saattanut hyväksyä kilpailijalta saamansa tarjouksen. Aikataulujen laadinnan nopeutumisella puolestaan parannetaan yrityksen sisäistä joustavuutta ja sitä kautta tehostetaan toimintaa. Tunniste Tavoitteeen nimi Prioriteetti Lähde ASGN154 ACE-tiimin toiminnan tehostaminen 1 (Korkea) Antti Tavoitteen kuvaus ACE-tiimin toiminnan tehokkuudesta riippuu pitkälti kuinka nopeasti tarjous saadaan tehtyä. Alkuehdot ACE-tiimi saa riittävät tiedot työnsä pohjaksi AE:lta Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: ACE-tiimin yhtä tarjousta kohden tekemän työn määrä ennen ja jälkeen järjestelmän käyttöönoton. ACE-tiimiltä yhtä tarjousta varten tehtävään työhön kuluttama aika ennen ja jälkeen järjestelmän käyttöönoton. Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä on parantanut ACE-tiimin toimintaa arvionti-osion mukaisesti voidaan olettaa AE:n työn tehostuvan ja tarjouksen teon nopeutuvan ja siten asiakastyytyväisyyden paranevan. 15

16 Tunniste Tavoitteeen nimi Prioriteetti Lähde HEWD511 AE:n toiminan tehostaminen 2 (Keskitaso) Antti Tavoitteen kuvaus AE:n toiminnan tehokkuudesta riippuu kuinka nopeasti tarjous saadaan tehtyä. Alkuehdot AE saa tarvitsemansa tiedot ACE-tiimiltä. Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: AE:n yhtä tarjousta kohden tekemän työn määrä ennen ja jälkeen järjestelmän käyttöönoton AE:n yhtä tarjousta yhtä tarjousta kohden kuluttama aika ennen ja jälkeen järjestelmän käyttöönoton. Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä on nopeuttanut AE:n toimintaa arvionti-osion mukaisesti voidaan olettaa asiakkaan saavan tarjouksensa nopeammin. Tunniste Tavoitteeen nimi Prioriteetti Lähde KVBH611 Projektien aikataulujen 1 (Korkea) Antti laadinnan tehostaminen Tavoitteen kuvaus Oikein ja nopeasti laadittu aikataulu parantaa yrityksen työtehoa ja tuottavuutta. Alkuehdot Työ on myyty. Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: Miten nopeasti uuden projektin saamisen jälkeen aikataulut on laadittu ennen ja jälkeen järjestelmän käyttöönoton. Miten hyvin aikataulut pitävät paikkaansa projektien todellisen etenemisen kanssa ennen ja jälkeen uuden järjestelmän käyttöönottamisen. Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä on parantanut aikataulujen laadintaa (SAM:n toimintaa) arvionti-osion mukaisesti voidaan olettaa yrityksen sisäisen joustavuuden ja kannattavuuden parantuneen. 16

17 2.12 P-tason arviointia P-tason arviointia Survey Inc:in mukaan toivottavia kehityskohteita ovat projektin hallinnan tuottavuuden ja kirjanpidon parantaminen, tiedon siirrettävyyden ja työtapojen yhteensopivuuden parantaminen, sekä nykyisten tietojärjestelmien tehokkuuden maksimointia. Lisäksi toivotaan uuden teknologian mahdollisuuksien selvittämistä. Survey Inc kirjaa päämäärikseen tavoitteen, tuloksen ja hyvän mielen. Nämä avaintavoitteet toimivat taustalla p-tasolla havaittujen parannusehdotusten merkitsevyyttä arvioitaessa. Projektisuunnitelmia tehtäessä vanhojen projektien suorittamiseen liittyvää informaatiota ei yrityksessä koeta saatavan riittävän tehokkaasti käyttöön. Ongelmia on sekä tietokantojen ja järjestelmien (Experience Database, ACE) toimivuudessa sekä paperiarkistojen hyödyntämisessä. Projektitarjousten tekemiseen tarvitaan kokeneiden työntekijöiden asiantuntemusta, joka on yrityksessä luonnollisesti korvaamaton voimavara. Toisaalta projektitarjousten suunnitteluun kuluu paljon työntekijöiden aikaa ja panos on poissa jostain muusta työtehtävästä. Työn tehokkuus ja tuottavuus saattaa kärsiä. Lisäksi firman kommunikaatiovaikeudet vaikuttavat myös suunnitteluprosessin sujuvuuteen. Tarjouksia pyritään tekemään mahdollisimman nopeasti ja tarkasti, viivästyminen ja epätarkkuus vaikuttaa kielteisesti asiakastyytyväisyyteen. Yrityksessä koetaan, että asiakkaan kanssa ei aina ehditä myöskään kommunikoimaan tarpeeksi. Vanhojen projektitietojen saatavuuden ja käytettävyyden parantaminen nopeuttaisi suunnitteluprosessia ja vapauttaisi työntekijöitä muihin tehtäviin. Kommunikaatio yrityksessä toimii pääasiassa in varassa. Kommunikaatiossa koetaan olevan puutteita eri toimijoiden välillä, jolloin työskentely ei aina ole tehokasta ja tieto ei siirry riittävän nopeasti. Myös työtavoissa on havaittu yhteensopivuusongelmia ja koordinointi ei aina onnistu. Tämä heikentää osaltaan projektinhallinnan tuottavuutta ja heijastuu projektien tehokkaaseen ja luotettavaan suorittamiseen sekä asiakastyytyväisyyteen. Tiedonkulun parantaminen ja työtapojen harmonisointi helpottaisi projektinhallintaa ja työskentelyä firmassa yleensä. Vanhojen tietojärjestelmien ja konekannan hyödyn maksimointi säästäisi yrityksen täysin uusien järjestelmien ja laitteistojen hankintojen aiheuttamilta investointikustannuksilta. Toisaalta vanhojen järjestelmien uudistaminen voi olla hankalaa, eikä tavoiteltua tehokkuutta pystytä saavuttamaan tai se vaatii kalliita muutoksia. Pitkän aikavälin tähtäimellä tutkitaan myös uuden tietotekniikan tarjoamia mahdollisuuksia yritykselle erityisesti kilpailukyvyn parantamisen näkökulmasta. 17

18 3 Kehitysalueen rajaus 3.1 Rajausvaihtoehdot Asiakkaalle tarjottiin kahta erilaajuista rajausvaihtoehtoa: Suppea rajaus: ACE-järjestelmän ja ACE-tiimin toiminnan tehostaminen. Vanhojen projektitietojen saatavuuden parantaminen siirtämällä paperitiedostot koneelle ja järjestelmän käytettävyyden parantaminen. Tällöin myös AE:n tekemien projektitarjousten nopeus ja tarkkuus paranee. Laajempi rajaus: ACEn toiminnan lisäksi kehitetään yrityksen käynnissä olevien projektien aikataulutuksen tehokkuutta. Job Order Database yhdistetään Experience Databasen ja ACE-järjestelmän kanssa.yrityksen kaikille toimijoille eli AE:lle, SAM:lle sekä osastoille lisätään uudistetun järjestelmän käyttömahdollisuus. Molemmissa vaihtoehdoissa varsinainen laitteiston kehittäminen jätetään ulkopuolelle ja laitteistoa hankitaan tai uudistetaan vain niiltä osin kun uusi järjestelmä sitä vaatii. Valittu rajaus Valituista rajauksista asiakkaat valitsivat laajemman sekä ACE-tiimin toiminnan tehostamisen että käynnissä olevien projektien aikataulutuksen parantamisen kattavan vaihtoehdon. Tarjotun vaihtoehdon katsottiin kehittävän yrityksen toimintaa kokonaisvaltaisesti eikä vain tiettyyn osa-alueeseen (ACE-tiimi) keskittyen. Projektitarjousten teon nopeuttaminen on tärkeä osa kehitysprojektia ja ACE-järjestelmän toimimattomuus nykytilassa on pystytty osoittamaan. Käynnissä olevien projektien aikataulutus ja seuranta ei kuitenkaan riittävästi helpotu vain ACE-tiimin toimintaa parantamalla vaan vaatii kokonaisvaltaisempaa muutosta ja koko yrityksen kattavan järjestelmän suunnittelemista. Asiakas toivoo uudistusten voivan tapahtua niin, että olemassa olevaa laitteistokantaa ei jouduta uusimaan kokonaisuudessaan. Jos järjestelmän toimivuus vaatii laitteistouudistuksia, yrityksessä ollaan valmiita niihin minimikustannuksin. Toimittajayritys hoitaa järjestelmän käyttöönoton vaatiman koulutuksen Survey Inc.:ssä. Suppeampi rajaus hylättiin koska haluttiin kokonaisvaltaisempi uudistus, eikä ainoastaan vanhojen järjestelmien uudelleenkuorrutusta. 3.2 ACE-tiimin kehittäminen Projektitarjouksen tekemisen nopeutta ja tarkkuutta pyritään parantamaan ACE-tiimin toiminnan tehokkuutta parantamalla. Nykyään paperiarkistois- 18

19 sa olevat vanhat projektitiedot siirretään tietokoneelle ja Experience Databasea ja ACE-järjestelmää muokataan käytettävämmäksi ja tarkemmaksi. Tällöin ACE-tiimi pystyy tuottamaan kulu- ja kestoarvioita nopeammin AE:n käyttöön, jolloin AE:n toimintaedellytyksen paranevat. 3.3 UUJ Käynnissä olevien projektien tietokanta Job Order Database yhdistetään Experience Databasen ja ACE:n kanssa. Uuden järjestelmän nimeksi tulee UUJ. JOD:iin kirjataan käynnissä olevien projektien tiedot ja työvaiheet sekä viittaukset aikaisempiin projektitietoihin Experience Databasessa. Uuteen järjestelmään on pääsy kaikilla yrityksen toimijoilla. Töiden eteneminen kirjataan järjestelmään, josta yrityksen toimijat saavat tiedot käyttöönsä reaaliaikaisina. Etenemistä voidaan verrata suoraan myös tehtyyn projektiaikatauluun. Tämä helpottaa projektin etenemisen seuraamista ja aikataulujen päivittämistä. Asiakas haluaa järjestelmän tietojen olevan saatavissa työntekijän olinpaikasta riippumatta, joten varteenotettavin käyttöliittymävaihtoehto on internet-pohjainen liittymä. Asiakas haluaa järjestelmän tietojen olevan saatavissa työntekijän olinpaikasta riippumatta, joten tarjoamme asiakkaalle ensisijaisesti internetselainpohjaista käyttöliittymää järjestelmään. Tarjottava ratkaisu on tässä tilanteessa mielestämme sopivin senkin vuoksi, että asiakkaan laitteistokanta on kirjavaa. 3.4 Rich picture uudistetusta järjestelmästä Rich picture (kuva 6) esittää Survey Inc.:in toimintaa suunnitellun järjestelmäkehityksen toteutumisen jälkeen. Vanhat tietojärjestelmät ja tietokannat ACE, Experience Database ja Job Order Database on yhdistetty uuteen tietojärjestelmään UUJ. Järjestelmä sisältää vanhat projektitiedot, joita hyödynnetään projektitarjousten tekemisessä sekä käynnissä olevien projektien aikataulutuksessa. Lisäksi järjestelmään kirjataan käynnissä olevien projektien eteneminen. Käyttöoikeus järjestelmään on ACE-tiimin lisäksi yrityksen muillakin toimijoilla, AE:lla, SAM:lla ja osastojen päälliköillä. ACE-tiimi tuottaa AE:n työstämien projektien pohjalta laskentamateriaalia projektien kestoista ja kuluista ACE-järjestelmän tarjoamien vanhoja projektitietoja hyödyntäen. Näiden avulla AE tekee asiakkaalle tarjottavat projektitarjoukset. Hyväksytyn projektitarjouksen pohjalta SAM tekee toteutettavan projektin aikataulut ja jakaa työt osastoille. Osastot kirjaavat töiden etenemistä tietojärjestelmään, jonka kautta SAM voi valvoa projektien etenemistä. Tarvittaessa aikatauluja muokataan uudelleen. 19

20 Kuva 6: Valittua rajausta esittelevä Rich picture. 20

21 4 IO-tason rakenteellinen suunnittelu IO-tason rakenteellista suunnittelua käynnistettiin tekemällä järjestelmän keskeisistä entiteeteistä elinkaarimalleja. Tietovuokaavioilla mallinnettiin järjestelmän tietorakenteita ja tiedonkulkuprosesseja. IO-tasolle kiinnitettiin omia järjestelmän toimivuutta käyttäjän kannalta mittaavia mittareita. 4.1 Elinkaarimallit Järjestelmästä löydettyjen entiteettien olemassaoloa kuvaavat elikaarimallit on esitetty kuvissa 7 js 8. Kuva 7: Projektin elinkaarimalli 21

22 Kuva 8: Aikataulun elinkaarimalli 4.2 Tietovuokaaviot Liittymäkaavio ja 1. tason tietovuokaavio on esitelty kuvissa 9 ja

23 Kuva 9: Liittymäkaavio 23

24 Kuva 10: 1. tason tietovuokaavio 24

25 4.3 IO-tason mittarit IO-tason mittareiksi valittiin asioita, jotka kuvaavat tiedon käytettävyyttä ja saatavuutta. Vanhojen projektitietojen käytettävyys parantaa ainakin tarjousten tekoprosessia ja saattaa jopa säästää saman työn uudelleen tekemiseltä. Samoin tiedon reaaliaikaisuus eri osastojen välillä vähentää päällekkäisen työn määrää; samoja tietoja voidaankäyttää mahdollisesti useammassa projektissa. Aikataulujen laadinta koettiin tärkeäksi myös tällä tasolla. Tunniste Tavoitteeen nimi Prioriteetti Lähde FGH74G Vanhan projektin hakeminen 1 (Korkea) Tomas Tavoitteen kuvaus Vanhojen projektien tietojen löytymisen ja hakemisen nopeuttaminen tehostaa vanhojen tietojen käyttöä. Alkuehdot Tiedetään, että vastaava projekti on toteutettu aiemminkin. Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: Kuinka kauan tiedon hakijalla menee aikaa halutun projektin löytämiseen ennen ja jälkeen järjestelmän käyttöönoton. Kuinka kauan tiedon hakijalla menee aikaa löydetyn projektin tietojen hakemiseen ennen ja jälkeen järjestelmän käyttöönoton. Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä parantaa vanhojen raporttien saatavuutta niin yrityksen kokemusperäisen tiedon käytettävyys ja sitä kautta uusien töiden arviointi ja tekeminen helpottuu. 25

26 Tunniste Tavoitteeen nimi Prioriteetti Lähde JT86KL Järjestelmän käyttäjien tyytyväisyys 1 (Korkea) Päivi Tavoitteen kuvaus Käyttäjien tyytyväisyys heijastuu suoraan työtehoon. Alkuehdot Järjestelmä toimii määrittelyjen mukaan. Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: Käyttäjille järjestetään järjestelmään liittyvä työtyytyväisyyskysely ennen ja jälkeen järjestelmän käyttöönoton. Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä parantaa työtekijöiden tyytyväisyyttä heijastuu se suoraan yleiseen työilmapiiriin ja yrityksen työteho ja sitä kautta tulos paranee. Työtyytyväisyyden voidaan myös katsoa vähentävän yrityksen kuluja stressistä johtuvien sairaspoissaolojen vähenemisen muodossa. Tunniste Tavoitteeen nimi Prioriteetti Lähde LT12BC Aikataulujen paikkansapitävyys 1 (Korkea) Päivi Tavoitteen kuvaus Heti alussa oikein laadittu aikataulu tehostaa osastojen työtehoa. Alkuehdot Projektin vaatimat resurssit on määritelty. Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: Miten tarkasti uuden projektin aikataulut saadaan laadittua ennen ja jälkeen järjestelmän käyttöönoton. Miten hyvin aikataulut pitävät paikkaansa projektien todellisen etenemisen kanssa ennen ja jälkeen uuden järjestelmän käyttöönottamisen. Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä on parantanut aikataulujen laadintaa voidaan olettaa yrityksen tyhjäkäynnin vähenevän ja tuloksen paranevan. 26

27 Tunniste Tavoitteeen nimi Prioriteetti Lähde DFKL55 Järjestelmän reaaliaikaisuus 1 (Korkea) Antti Tavoitteen kuvaus Miten nopeasti järjestelmään tallennetut tiedot ovat muiden käyttäjien käytettävissä. Alkuehdot Tieto on syötetty järjestelmään. Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: Mitataan aika, joka jonkin osasuorituksen tallentamisesta järjestelmään kuluu siihen että tiedot ovat muiden käyttäjien käytettävissä. Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä nopeutaa tiedon käytettävyyttä voidaan katsoa toiminnan tehostuvan turhan odottelun poistuessa. Samalla vältytään päällekkäisiltä toiminnoilta kun voidaan nopeammin nähdä mitä muut osastot ovat jo tehneet. 5 CO-tason suunnittelu CO-tasolla syvennyttiin uuden järjestelmän teknisiin ominaisuuksiin. Järjestelmän toimintaa mallinnettiin oliomallin ja ER-mallin avulla. Lisäksi COtasolle kiinnitettiin järjestelmän teknisiä ominaisuuksia mittaavia CO-tason mittareita. Järjestelmän tulevia käyttöoikeuksia rajattiin käyttöoikeusmatriisin avulla. 5.1 Oliomalli Oliomalli (ks. kuva 11) kuvaa järjestelmän alustavaa toteutusmallia ja luokkatason ratkaisuja. Asiakkaalle tehdään yksi tai useampia projektitarjouksia ja asiakkaan hyväksymän tarjouksen pohjalta tehdään sopimus, jonka pohjalta käynnistetään uusi projekti. Projekti koostuu osaprojekteista. Projektilla on projektipäällikkö ja yleisaikataulu. Osaprojektilla on osaprojektipäällikkö ja osaprojektikohtainen aikataulu. Osaprojekti koostuu tapahtumista, joita työstävät työntekijät. 27

28 Kuva 11: Uutta järjestelmää kuvaava oliomalli. 28

29 5.2 ER-malli ER-malli kuvaa UUJ-järjestelmän toimintaa tietorakenteellisella tasolla. Asiakkaalle tehdään yksi tai useampia projektitarjouksia ja asiakkaan hyväksymän tarjouksen pohjalta tehdään sopimus, jonka pohjalta käynnistetään uusi projekti. Projektissa työskentelee työntekijöitä ja lisäksi projektilla on yksi johtaja. Työntekijät kuuluvat yhteen osastoon ja osastolla voi olla useita työntekijöitä. Projektiin liittyy yksi yleisaikataulu ja lisäksi projekti koostuu osaprojekteista, joille voidaan tehdä oma, tarkempi aikataulu. Työntekijä työstää osaprojekteihin kuuluvia tapahtumia. Kuva 12: Järjestelmää kuvaava ER malli. 29

30 5.3 CO-tason mittarit CO-tason mittareita tuli loppujen lopuksi vain kaksi. Järjestelmän toimivuus vanhoillakin laitteilla koettiin asiakkaan taholta tärkeäksi asiaksi ja lisäksi järjestelmän yleisen toimivuuden kannalta yhtenä avainkysymyksenä nähtiin tietokantojen eheys. Kolmanneksi mitatariksi esitimme päällekkäiskirjauksen välttämistä, mutta koska em. tapahtumaa ei missään oloissa saisi lainkaan sattua, mittari oli enemmänkin vaatimus järjestelmälle kuin mittari. Tunniste Tavoitteeen nimi Prioriteetti Lähde JTUL17 Tietokantojen laatu 1 (Korkea) Antti Tavoitteen kuvaus Tietokantojen on oltava luotettaviua ja laadukkaita. Alkuehdot Tiedot on syötetty järjestelmään. Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: Tietokannassa esiintyvien anomalioiden ja redundanssin määrä. Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä parantaa tietokantojen laatua voidaan katsoa tiedon luotettavuuden ja saatavuuden parantuvan. Tunniste Tavoitteeen nimi Prioriteetti Lähde JFRT18 Laitteistokanta 1 (Korkea) Antti Tavoitteen kuvaus Parametristen käyttäjien on voitava käyttää järjestelmää vanhemmallakin laitteistolla. Alkuehdot Tarvittavat ohjelmat on asennettu ja laitteisto on oikein konfiguroitu. Arviointi Tavoitteen arviointi suoritetaan, kun järjestelmä on ollut yhden vuoden käytössä. Arviointikriteereinä käytetään seuraavia asioita: Mitataan tiettyyn suoritukseen (esim. tiedon haku, aikataulun päivitys) kuluva aika, vertailukohtana nykyaikainen tietokone Johtopäätökset Mikäli voidaan osoittaa, että implementoitu järjestelmä toimii tehokkaasti vanhemmallakin laitteistokannalla voidaan katsoa yrityksen säästävän laitteistokuluissa. 30

31 5.4 Käyttöoikeusmatriisi Uuden järjestelmän eri osiin annettiin eri käyttäjäryhmille seuraavassa esitetyt oikeudet. Yleisesti ottaen järjestelmästä tehdään sellainen että tietoihin kohdistuvat muutokset ovat myöhemmin nähtävssä, siis vanhatkin tiedot ovat edelleen luettavissa ja muutokset tekijöineen siten jäljitettävissä. Osastoille uuden järjestelmän osiin annettiin lukuoikeus sekä tietysti aikataulujensa osalta edistymisen päivitysmahdollisuus. Käyttöoikeusmatriisi on esitetty kuvassa 13. Kuva 13: Käyttöoikeusmatriisi 6 Projekti 6.1 Projektiorganisaatio Projektiorganisaation koostumus: Projektipäällikkö on vetovastuussa projektitiimistä ja vastaa projektin edistymisestä toimittajayrityksen johdolle Projektisihteeri on vastuussa dokumentoinnista ja muistiinpanoista kokouksissa sekä toimii asiantuntijana järjestelmäkehityksessä Atk-suunnittelija on vastuussa järjestelmätason toimivuudesta ja teknisestä suunnittelusta Myyntiedustaja/konsultti vastaa projektin myyminesestä asiakkaalle, toimii yhteysrajapintana asiakkaan suuntaan ja vetää asiakasneuvottelut (yhdessä muun tiimin kanssa). Projektiryhmä toimii kokoontumalla projektipalaveriin. Projektipalaverissa vaihdetaan tietoa projektin tilanteesta, ilmenneistä ongelmista, esitetään kysymyksiä, ja sovitaan kunkin ryhmän jäsenen tehtävät ja vastuut seuraavaan 31

32 projekti- tai asiakastapaamiseen asti. Projektiryhmän jäsenet tekevät työtään itsenäisesti, kysyen muilta neuvoja tarpeen vaatiessa. Mikäli tarvitaan asiakkaalta jotakin tietoa, toimii konsultti Tomas Windahl pääasiallisena yhteysrajapintana asiakkaan suuntaan. Kun projekti on saatu päätökseen, puretaan projektiorganisaatio ja nimitetään Antti Lehto vastaamaan mahdollisista järjestelmään tehtävistä vikakorjauksista kuten asiakkaan kanssa myöhemmin sovitaan. Projektisuunnitelma tehtäessä merkittiin taulukkoon osatehtävät, niiden arvioidut työmäärät sekä aloitus- ja valmistumisaika. Tehtävän valmistuttua merkittiinn ylös valmistumisaika ja toteutunut työmäärä, josta laskettiin arvioidun ja toteutuneen työmäärän erotus sekä ennustetun ja toteutuneen valmistumisaikojen erotus. Suunnitelmaa päivitettiin toteutuneiden työmäärien ja valmistumisprosentin osalta kuhunkin asiakastapaamiseen mennessä, jotta asiakkailla oli mahdollista seurata työn edistymistä. Jos jossakin osatehtävässä oli ilmennyt odottamattomia ongelmia, se ilmoitettiin väliraportissa heti, kun sellainen on havaittu. Aikataulussa esitutkimukseen on sisällytetty asiakastapaamiset. Dokumentointi on hyvän tavan mukaan eriytetty omaksi osaprojektikseen, jolla korostetaan dokumentoinnin valmistumisen merkitystä. 6.2 Aikataulu Kuvassa 14 on esitetty projektin aikataulu ja arvioidut sekä toteutuneet työmäärät. Kuvissa 15 ja 16 puolestaan näkyy graafisena esityksenä aikataulun ja arvioitujen työmäärien toteutuminen. Kuva 14: Projektin aikataulu 32

33 Kuva 15: Projektin alussa määritellyt ja toteutuneet työtunnit Kuva 16: Projektin alussa määritellyt ja toteutuneet päivämäärät 33

34 6.3 Projektin riskit Projektin alussa määriteltiin sen riskit seuraavasti: Asiakkaalta saatu tieto on puutteellista tai se on ymmärretty väärin. Mitä myöhemmässä vaiheessa tämä käy ilmi, sitä suuremmat haitat, sillä sitä enemmän joudutaan tekemään jo kertaalleen tehtyjä töitä uudelleen. Pyritään varmistamaan asiakkaalta saatu tieto oikeaksi ja riittäväksi mm. tekemällä esitutkimusvaiheessa kaavioita ja näyttämällä niitä asiakkaalle, joka voi siten helposti varmistaa, ettei siinä ole vikaa tai puutteita. Tekniset riskit Toteuttamiseen valitut välineet, tekniikat ja laitteet osoittautuvat vääränlaisiksi tai riittämättömiksi. Yleensä pyritään valitsemaan ennemminkin ylimitoitetut kuin alimitoitetut laitteet ja välineet, sillä valittaessa halvempi vaihtoehto, hintasäästö on yleensä pienempi kuin riskin toteutumisesta aiheutuvat kustannukset. Henkilöstöriskit Projektiryhmä on pieni, yhdenkin henkilön pitkät sairaus- yms. poissaolot voivat vaarantaa koko projektin. Osittain tätä riskiä heikentää se, että kuka tahansa ryhmän jäsen pystyy tarvittaessa tekemään toisen työt (oman aikataulunsa kustannuksella). 6.4 Projektin arviointia Suunnittelussa päästiin CO-tasolle toteutettavan järjestelmän oliomallinnukseen, jota projektin jatkuessa olisi tarkennettu toteuttamiskelpoiseksi ja edelleen toteutettu. Projektin tulos on hyvä, vaikka suunnittelu ei annetun ajan puitteissa edennyt aivan toteuttamisasteelle. Kehittämisprojekti sujui ilman suurempia takaiskuja, vaikka malleihin tulikin muutoksia demojen edetessä. P-tasolla suunnitellut rajaukset ja kehittämiskohteet kuitenkin pysyivät seuraavien tasojen ratkaisujen kanssa sopusoinnussa, eikä aikaisemmille tasoille jouduttu palaamaan. PIOCO-mallin soveltaminen sujui hyvin ja eri tasojen painotukset pystyttiin tunnistamaan ja soveltamaan omaan suunnitteluun. Malli sinänsä vaikutti käyttökelpoiselta tietojärjestelmien kehittämisprojekteihin. 6.5 Ryhmätyön arviointia Alun epätietoisuuden ( mitähän oikein pitäisi tehdä, onpa niukasti pohjatietoa ) jälkeen projekti eteni ikäänkuin omalla painollaan. Asiakastapaamisten jälkeen kokoonnuimme aina projektikokoukseen jossa keskustelimme tehtävistä muutoksista ja sovimme vastuualueet ja niihin vastuuhenkilöt. 34

35 Malleja mietimme pitkälti yhdessä, mutta tekniset viimeistelyt sekä tekstiosuudet tehtiin erillään sähköpostia avuksi käyttäen. Ryhmätyöskentely sujui yleisesti ottaen hyvin. Ryhmän jäsenten erilaiset aikataulut vaikeuttivat hieman tapaamisia, mutta viikottaiseen palaveriin löydettiin yleensä yhteinen aika. Sähköposti oli myös tärkeä kommunikaatioväline projektin onnistumisen kannalta. Kaikki ryhmän jäsenet osallistuivat kehittämisprojektiin hyvin ja jaetut tehtävät hoidettiin sovitusti. 6.6 Lopputuloksen arviointia Seuraavassa ovat ryhmämme arviot asteikolla 1-3 projektin tulokselle, itse projektille ja opponoijille. a) projektin tulos 2 b) itse projektille 2 c) opponoijille 2,5 Opponoijat osasivat pysyä rooleissaan mallikkaasti. Myös kysymyksiin osattiin vastata kiitettävästi. Opponoijien hieman parempi tutustuminen toimittajien väliraportteihin olisi tosin ollut suotavaa. 35