Analyis and optimization of the product development process

(1)

Roy Funck

TUOTEKEHITYSPROSESSIN ANALYSOINTI JA OPTIMOINTI

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa 1.9.1997.

Työn valvoja

Professori Raimo Kantola

Työn ohjaaja —

DI Harri Y

(2)

Tekijä: Roy Funck

Työn nimi: Tuotekehitysprosessin analysointi ja optimointi

Päivämäärä: 1.9.1997 Sivumäärä: 95

Osasto: Sähkötekniikan osasto

Professuuri: Teletekniikka koodi:S-38

Työn valvoja: Professori Raimo Kantola Työn ohjaaja: DI Harri Ylieskola

Diplomityön tavoitteena oli muodostaa kirjallisuuteen perustuva ohjelmiston tuotekehitysprosessin kehittämismalli, tutustua prosessikehittämis- ja kypsyysmalleihin, analysoida esimerkki yrityksen tuotekehitysprosessia sekä muodostaa analyysin perusteella toiminta- ja kehityssuunnitelma tuotekehitysprosessin kehittämiselle.

Muodostettu malli sisältää kolme itsenäistä vaihetta: prosessin analysointi, prosessin optimointi ja prosessin jäädyttäminen. Ensimmäisessä vaiheessa selvitetään kuinka prosessi todellisuudessa toimii. Toisessa vaiheessa valitaan kehityskohteet, suunnitellaan keinoja, joilla näihin voisi vaikuttaa ja käynnistetään korjaavat toimenpiteet. Kolmannessa vaiheessa prosessia mitataan ja varmistetaan, että muutokset on otettu käyttöön. Kaikki vaiheet toistuvat ja muodostavat jatkuvan prosessinkehittämisen syklin.

Tätä mallia käytettiin tuotekehitysprosessin analysoimisessa. Analyysin perusteella organisaation tuotekehityksestä löytyi neljä ongelma-aluetta: yhteistyö läpi ohjelmistoprosessin, ylläpidon ja projektoitujen työtehtävien estimointi, tuotemäärittely sekä tiedonkulku.

Analyysin perusteella muodostettiin suunnitelma tuotekehitysprosessin kehittämiseksi. Lyhyen aikavälin tehtäviä ovat tiedon kulun parantaminen, estimoinnista huolehtiminen, tiimiorganisaation lujittaminen, tarpeettoman ylläpitotyön vähentäminen ja raportointitarpeen kartoittaminen. Pitkällä aikavälillä organisaatiossa tulisi käynnistää hanke moniosavuuteen tähtäävän prosessin luomiseksi, kehittää määrittelytietokanta, kehittää reaaliaikainen raportointijärjestelmä, perustaa erillisiä ylläpitotiimejä sekä selkeästi määritellä linja / projektiorganisaation tehtävät, menetelmät ja vastuut.

Diplomityön kaikki tavoitteet saavutettiin. Tutkimuksen tärkein tulos on, että organisaatio pystyi muodostamaan laajan kuvan tuotekehitysprosessin tilasta ja sen kehityskohteista.

Avainsanat: Ohjelmistoprojektin hallinta, prosessikehitys, prosessijohtaminen, tuotekehitysprosessin optimointi

(3)

Author: Roy Funck

Name of the thesis: Analysis and optimization of the product development process

Date: 1.9.1997 Number of pages: 95

Faculty: Electrical Engineering

Professorship: Telecommunications code: S-38 Supervisor: Professor Raimo Kantola

Instructor: Harri Ylieskola, M.Sc.

The objectives of the thesis were to formulate a model of a software development improvement process based on the literature, to familiarise ourselves with the models of process improvement and maturity assessment, to analyse the product development process of the case company and to make an actions and improvement plan for the product development process based on the analysis.

The composed model consists of three independent phases: process analysing, process optimisation and process freezing. In the first phase, the process is described and analysed. In the second phase, the improvement objects are selected, improvement plans are prepared and the corrective actions are implemented. In the third phase, the process is monitored and measured to make sure that all actions are implemented. All phases are repeated to form a cycle of continuos improvement.

This model was used to analyse the product development process of the case company. Four problem areas were found in the analysis: co-operation during the software process, work estimation of maintenance and projected work tasks, product definition and the flow of information.

Based on the analysis, an action plan was formulated to improve the process further.

The short term objectives are to improve the flow of information, implement proper tools for estimation, decrease the unnecessary maintenance and investigate the real reporting needs. In the long terms, the organisation should create a process for creating of multiskilled personnel, implement a knowledge database for system design phase, create a real-time reporting environment, establish maintenance teams and define in detail the responsibilities and tasks of the line and project organisation.

All the objectives of the thesis were achieved. As the main result of the study, the organisation was able to build a view of the status and the main improvement objectives of the product development process.

Keywords: Software project management, process improvement, process management, optimisation of the product development process

(4)

Tämä diplomityö on tehty Nokia Telecommunications Oy:n Fixed Switching -yksikön tuotekehityksessä syksyllä 1996 ja alkuvuodesta 1997.

Tämän työn tutkimuskohteen valinta ja aiheen rajaaminen ei ollut helppo tehtävä, koska työn aihealueet ovat laajoja ja sisältävät monia mielenkiintoisia asiakokonaisuuksia. Työn edetessä siitä muodostui antoisa tutkimusmatka prosessikehittämisen maailmaan.

Kiitän kaikkia työtovereitani, joiden myötävaikutuksella työ on tehty. Kiitän myös Nokia Tutkimuskeskuksen henkilökuntaa arvokkaista neuvoista ja kommenteista.

Työn valvojana toimineelle professori Raimo Kantolalle tahdon osoittaa parhaimmat kiitokseni mielenkiinnosta työtäni kohtaan ja saamastani ohjauksesta.

Kiitokset ansaitsevat myös ohjaajani Harri Ylieskola hyvistä kommenteista ja joustavasti hoidetusta byrokratiasta.

Lopuksi suurkiitokset Helille, ansiokkaasta kielioppivirheiden korjaamisesta ja kallisarvoisista yhteisistä vapaahetkistä.

Hei si n eri ssä 1 9 1997

Roy Funck

(5)

Sisällysluettelo

OSA I: JOHDANTO

1 JOHDANTO...1

1.1 Tutkimusongelma... 2

1.2 Tutkimuksentavoite...2

1.3 Tutkimuksenrajoitukset...2

1.4 Tutkimusmenetelmät...2

1.5 Tutkimusraportinrakenne...3

OSA II KIRJALLISUUSTUTKIMUS 2 PROSESSIEN HALLINTA JA KEHITTÄMINEN... 4

2.1 Prosessikehitykseenkäytettäviämalleja...6

2.1.1 Total Quality Managemant... 6

2.1.2 ISO 9000...7

2.1.3 Humpreyn malli...7

2.1.4 PQMI...7

2.1.5 CMM-malli...S 2.7.6Trillium...9

3 OHJELMISTOPROSESSIN KEHITTÄMINEN SPICE-MALLIN MUKAISESTI...12

3.1 Organisaationtarpeidenkartoitus...13

3.2 Prosessikehityshankkeenaloitus...14

3.3 Prosessinnykytilankartoitus... 14

3.4 Kartoituksentulostenanalysointi...14

3.5 Prosessikehityksentoteuttaminen...15

3.6 Muutostenvarmentaminen...17

3.7 Parannustenylläpito...17

3.8 Suoritustasontarkkailu...18

4 PROSESSIN ANALYSOINTI JA OPTIMOINTI... 19

4.1 P^rosessinanalysointi...20

4.1.1 Prosessianalysointiin valmistautuminen...27

4.1.2 Prosessin arviointi...22

4.1.3 Prosessianalyysin tulosten esittäminen...23

4.2 Prosessinoptimointi...24

4.3 P^rosessinjäädyttäminen...26

4.4 PROSESSIN MUUTTAMISEN EDUT JA VAIKEUDET... 26

5 TEHOKKAAN TUOTEKEHITYKSEN LÄHTEITÄ...29

5.1 Tekijättuotekehityksentasapainottelussa...29

5.2 Tuoteportfolionhallinta...30

5.3 Tuotekehityksenorganisointi...31

5.4 Tuotekehityksenlimittäisyydenkehittäminen...35

5.5 Projektinhallinta...36

5.5.1 Projektitiimin johtaminen...38

5.5.2 Projektisuunnitelma...39

5.6 Ohjelmistojenmittaaminenjaestimointi...40

(6)

5.6.1 Ohjelman kokoa kuvaavat mittarit (size-oriented metrics)...41

5.6.2 Toiminnallisuuteen perustuvat mittarit (function oriented metrics)...42

5.6.3 Ohjelmistolaadun mittarit...43

5.6.4 Ohjelmistoprojektien estimointi...44

5.6.5 Estimointiprosessin syötteet ja tulosteet...47

5.6.6 Tunnetuimmat estimointimallit...50

5.6.7. Toimintopistemenetelmä...52

5.7 O^hjelmiston^ylläpito...57

5.8 T^eknologian^hallinta... 58

5.9 Tyypillisiävirhetekijöitä... 59

6 KIRJALLISUUSTUTKIMUKSEN YHTEENVETO...61

OSA III: TAPAUSTUTKIMUS 7 NOKIA TELECOMMUNICATIONS... 63

7.1 Tietoliikenneteollisuus... 63

7.2 NTC:N PROSESSIT...64

7.3 TUOTEPROSESSI... 65

8 TUTKIMUS- JA KEHITYSYKSIKKÖ... 66

8.1 Organisointi...69

Kehityskohteita... 70

8.2 T^uotteen^määrittely^ja^toteutus... 70

8.2.1 Ohjelmien määrittely ja toteutus...73

8.2.2 Toimintotestaus...74

8.2.3 Järjestelmätestaus...75

8.2.4 Kehityskohteita... 75

8.3 Projektinhallinta...76

8.3.1 Kehittämiskohteita...78

8.4 Teknologianhallinta... 79

8.5 Ylläpito... 79

8.4.1 Kehittämiskohteita... 87

8.5 P^rosessit... 83

9 JOHTOPÄÄTÖKSET...84

10 SUOSITUKSET...86

OSA IV: YHTEENVETO 11 YHTEENVETO...94

11.1 Luotettavuusanalyysi... 94

11.2 Jatkotutkimuskohteita... 95

LÄHDELUETTELO

Funck Roy : Tuotekehitysprosessin analysointi ja optimointi.

Diplomityö. Teknillinen Korkeakoulu, Teletekniikan laboratorio, 1.9.1997

(7)

MÄÄRITELMÄT

Arkkitehtuuri DX 200-järjestelmä Järjestelmätestaus Julkaisu

Moduulitestaus Moni-projekti organisaatio Ominaisuus Operaattori

Prosessin omistaja T&K- projekti Toimintotestaus Tuotepäätösprosessi

LYHENTEET

CMM FPA ISO PSTN SPICE SWP T&K

TRILLIUM WB S

Järjestelmän rakenne, joka on jaettu osajärjestelmiin ja laajemmin ohjelmistoja laitteistokomponenttiin. Järjestelmän arkkitehtuuri käsittää rakenteen, käsitteet ja toimintaperiaatteet.

Nokia Telecommunications’in kehittämä vikasietoinen tietoliikennejärjestelmä.

Järjestelmäkokonaisuuden toimivuuden varmistaminen.

Joukko ominaisuuksia tai tuotteita (ohjelmisto, laitteisto, palvelut ja dokumentointi), jotka on suunnattu yhdelle tai usealle markkina- alueelle.

Yksittäisen ohjelman toteuttamisen aikana syntyneiden virheiden eliminointi.

Organisaatio, jossa useampi yhtäaikainen projekti jakaa yhteiset resurssit.

Järjestelmän tai tuotteen toiminnallinen kokonaisuus tai piirre, joka on merkittävä joko asiakkaan tai sisäisen tuotekehityksen tarpeiden kannalta.

Yritys, joka ylläpitää tietoliikenneverkkoa ja / tai tarjoaa tietoliikennepalveluja.

Henkilö, jonka vastuulla on jonkin prosessin kehittäminen yhteistyössä linjaorganisaation kanssa.

Tutkimus- ja kehitysaktiviteetti, joka tähtää asiakastarpeiden tai sisäisten kehityshankkeiden tyydyttämiseen.

Yksittäisten ominaisuuksen toiminnan varmistamista testaamalla.

Prosessi, jonka tuloksena syntyy tuotepäätös, joka toimii lähtötietona tuoteprojektille.

Capability Maturity Model.

Function Point Analysis, estimointimenetelmä, joka perustuu toiminnallisuuden määrän mittaamiseen.

Institution of Software Engineering.

Public Switched Telephone Network. Yleinen kiinteä valintainen puhelinverkko.

Software Process Improvement and Capability dEtermination.

Switching platform.

Tutkimus-ja kehitysyksikkö.

Telecom Product Development & Support Process Capability.

Work Breakdown Structure. Projektin jakaminen pienemmiksi helpommin hallittaviksi tehtäviksi.

(8)

Kuvat ja taulukot

KUVA 1: TUTKIMUSRAPORTIN RAKENNE. 3

KUVA 2: PROSESSINHALLINNAN VAIHEET. 5

KUVA 3: PROSESSIN KEHITTÄMISEEN TA RV ITT A VA AIKA. 11 KUVA 4: SPICE-MALLIN MUKAISET PROSESSINKEHITYKSEN ASKELEET. 13 KUVA 5: PARANNETTAVAN OSA-ALUEEN VALINTAAN VAIKUTTAVIA TEKIJÖITÄ. 15

KUVA 6: KOLMIVAIHEINEN PROSESSIKEHITYSMALLI. 19

KUVA 7: PROSESSIN ANALYSOINTI. 20

KUVA 8: PROSESSIN TARKASTELU. 24

KUVA 9: TYYPILLINEN OHJELMISTOKEHITYKSEN ARVOKETJU. 25 KUVA 10: TEKIJÄT TUOTEKEHITYKSEN TASAPAINOTTELUSSA. 29

KUVA 11: LAAJOJEN KEHITYSHANKKEIDEN VAIKUTUKSET. 31

KUVA 12: TOIMINNALLISUUDEN MUKAINEN ORGANISAATIO. 32

KUVA 13: ERI ORGANISAATIOMUOTOJEN RESURSSIJAKAUMA. 33

KUVA 14: PROJEKTINHALLINTA. 38

KUVA 15: PROJEKTISUUNNITELMAN LAA TIMINEN. 39

KUVA 16: MITATTAVIEN SUUREIDEN JAKO. 41

KUVA 17: YKSINKERTAINEN ESTIMOINTIPROSESS1. 47

KUVA 18: TODELLINEN ESTIMOINTIPROSESSI. 48

KUVA 19: ESTIMOINNIN TARKKUUS ERI VAIHEISSA TUOTEKEHITYSPROSESSIA. 49

KUVA 20: DELPHl-MENETELMÄN YHTEENVETORAPORTTI. 49

KUVA 21: YLLÄP1T0KATEG0RI0IDEN JAKAUMA. 57

KUVA 22: TEKNOLOGIAN HALLINTA. 58

KUVA 23: TARVITTAVA PANOSTUS SUHTEESSA RESURSSEIHIN. 60

KUVA 24: TEHOKKAAN TUOTEKEHITYKSEN LÄHTEITÄ. 61

KUVA 25: TIETOLIIKENNETEOLLISUUDESSA VAIKUTTAVAT MUUTOSVOIMAT. 63

KUVA 26: NTC:N YDINPROSESSIT. 64

KUVA 27: TUOTEPROSESSIN SYÖTTEET JA TUOTOKSET. 65

KUVA 28: PROJEKTIOGANISAATION SUHDE LINJAORGANISAATIOON. 66 KUVA 29: SIMULOINNIN TULOKSENA SAATU PROSESSIN KUVA US. 68

KUVA 30: NTC.N TUOTEPROSESSI. 68

KUVA 31: TEHTÄVIEN EST1MOINTITÄRKKUUS. 78

KUVA 32: AIHEELLISTEN JA AIHEETTOMIEN VIKAILMOITUSTEN JAKA UMA. 80

KUVA 33: YLLÄPIDON ESTIMOINTITARKKUUS. 81

KUVA 34: MUIDEN ASIANTUNTIJARESURSSIEN HYÖDYNTÄMINEN V1ANKORJA UKSISSA. 82

KUVA 35: MÄÄRITTELYPROSESSI. 89

TAULUKKO 1: CMM-MALLIN KYPSYYSTASOT. 8

TAULUKKO 2: CMM:N VAIKUTUKSET PROSESSIIN. 9

TA ULUKKO 3: TRILLIUM-MALLIN SUORITUSTASOT. 9

TA ULUKKO 4: SPICE-MALLIN SUORITUSTASOT. 12

TA ULUKKO 5: ERI ORGANISAATIOMUOTOJEN VAHVUUDET JA HEIKKOUDET. 34

TA ULUKKO 6: PROJEKTINHALLLINNAN HAASTEET. 37

TA ULUKKO 7: OHJELMIEN MITTAAMINEN OHJELMARIVIEN MUKAAN. 41 TA ULUKKO 8: OHJELMARIVIEN JA TOIMINTOPISTEIDEN SUHDE. 43 TA ULUKKO 9: TIETORAKENTEIDEN LUOKITUS ERI VAIKEUSASTEISIIN. 53 TA ULUKKO 10: TIETORAKENTEIDEN PA1NOTTAMATTOMAT TOIMINTOPISTEET. 53

TAULUKKO 11: SYÖTTÖTAPAHTUMIEN VAIKEUSASTE. 54

TA ULUKKO 12: TULOSTUSTAPAHTUM1EN VAIKEUSASTE. 54

TAULUKKO 13: TULOSTEIDEN PAIN OTT AM ATTOM AT TOIMINTOPISTEET. 55

TAULUKKO 14: KORJAUSKERTOIMET. 55

TA ULUKKO 15: KESKIMÄÄRÄINEN TOIMINTOPISTEIDEN TUOTANTO TOIMIALOITTAIN. 56 TA ULUKKO 16: TYÖMÄÄRÄN JA KA UMA ERI PROJEKTIVAIHEILLE. 57 TAULUKKO 17: ORGANISAATION LYHYEN AIKAVÄLIN TOIMINTASUUNNITELMA. 88 TA ULUKKO 18: ORGANISAATION PITKÄN AIKA VÄLIN TOIMINTASUUNNITELMA. 88

(9)

TA ULUKKO 19: MÄÄRITTELYN LYHYEN AIKA VÄLIN TOIMINTASUUNNITELMA. 90 TA ULU KKO 20: MÄÄRITTELYN PITKÄN AIKA VÄLIN TOIMINTASUUNNITELMA. 91 TAULUKKO 21: PROJEKTINHALLINNAN LYHYEN AIKAVÄLIN TOIMINTASUUNNITELMA. 92 TA ULU KKO 22: PROJEKT1NHALLINAN PITKÄN AIKA VÄLIN TOIMINTASUUNNITELMA. 92 TAULUKKO 23: YLLÄPIDON LYHYEN AIKAVÄLIN TOIMINTASUUNNITELMA. 93 TA ULU KKO 24: YLLÄPIDON PITKÄN AIKA VÄLIN TOIMINTASUUNNITELMA. 93

(10)

Johdanto

(11)

1 Johdanto

Ohjelmistoalalla toimiville yrityksille on keskeiseksi lähtökohdaksi tarpeiden tyydyttämiseksi muodostunut ohjelmistokehitysprosessien kokonaisvaltainen parantaminen. Prosessien parantamisella pyritään parantamaan ohjelmiston laatua, alentamaan kehitys- ja ylläpitokustannuksia, lyhentämään läpimenoaikoja ja lisäämään ohjelmistoprosessien ennustettavuutta ja ohjattavuutta.

Prosessien parantaminen hoidetaan syklittäisten kehitysjaksojen avulla, joiden aikana käynnistetään pienimuotoisia parannushankkeita, kuten jonkin prosessissa olemassaolevan työvaiheen / menetelmän muuttaminen / poistaminen tai uuden käyttöönotto. Tärkeätä on huolehtia luotettavan prosessitiedon saatavuudesta kehitysjakson alussa ja lopussa. Vanha kiinalainen sananlasku, “Ellet tiedä mihin olet menossa, ei kulkusuunnallasi ole merkitystä”, pätee yhä edelleen. Mikäli luotettavia mittareita ei ole käytettävissä, ei ole myöskään mitään systemaattista tapaa varmistaa, ohjasivatko kehitysjakson aikana tehdyt parannusyritykset prosesseja parempaan vaiko huonompaan suuntaan. Luotettavien prosessimittareiden lisäksi kohdeprosessien tulisi olla riittävällä kypsyystasolla (prosessit mitattavissa, toistettavissa ja ennustettavissa), jotta prosessien kehitys olisi mielekästä.

Prosessikehityshankkeiden onnistuminen mahdollistetaan, mikäli pidetään mielessä, että:

• Ohjelmistokehitysprosessin parantaminen vaatii huolellista suunnittelua, motivoitunutta henkilöstöä, johdon panostusta ja rahallista investointia.

• Prosessien kehittäminen on tiimityötä, joka vaatii osallistuvien sitoutumista kehittää toimintaa samaan suuntaan.

• Prosessien nykytilan on oltava selvillä.

• Prosessien parantaminen edellyttää toistuvia pienin askelin tehtyjä parannuksia.

Kehityshankkeet asetetaan tärkeysjärjestykseen yrityksen tarpeiden ja liikeidean vaatimusten mukaisesti. Ohjelmistoprosessin kehittämishankkeet noudattavat seuraavanlaista kaavaa:

• Ohjelmistoprosessin kehityshankkeet pohjautuvat nykyprosessin arvioinnissa saatuihin tuloksiin.

• Nykyprosessin arvioinnissa saatuja tuloksia verrataan tavoitetilaan, joka saadaan analysoimalla yrityksen tarpeita ja liikeideaa.

• Prosessin tehokkuusmittausten avulla identifioidaan ja priorisoidaan kehityshankkeet

• Ohjelmistoprosessin kehittäminen on jatkuva prosessi. Organisaation hyväksymiin tavoitteisiin pyritään pääsemään prosessinkehittämisohjelman avulla, joka muodostuu toistuvista suunnittelu-, toteutus-ja mittaustapahtumista.

• Parannushankkeet projektoidaan ja toteutetaan projektinomaisesti.

• Mittareita hyödynnetään mittaamaan saavutuksia ja ohjaamaan tarvittavia korjauksia.

• Prosessinarviointi toistetaan, jotta saadaan varmuus, että tavoite on saavutettu.

(12)

1.1 Tutkimusongelma

Tutkimus pyrki analysoimaan nykyisten prosessien käytännön toimintaa ja löytämään keinoja, joilla nykyprosesseja voidaan muokata tehokkaammiksi. Tutkimusongelma voidaan muotoilla:

Kuinka tuotekehitysprosessia voitaisiin tehostaa prosessissa olevia työvaiheita tehostamalla?

Vastaus kysymykseen pyrittiin löytämään simuloimalla ja analysoimalla prosessia laajemman yleiskuvauksen saamiseksi prosessin toiminnasta ja parannusehdotusten löytämiseksi.

1.2 Tutkimuksen tavoite

Tarve tutkimuksen tekemiselle tuli kohdeyrityksen tavoitteesta parantaa omia prosessejaan vastaamaan entistä paremmin nopeasti kehittyvien markkinoiden tarpeita.

Kohdeyrityksessä on jo käynnistetty / ollaan käynnistämässä erinäinen joukko hankkeita, joilla pyritään systemaattisesti kehittämään olemassaolevia prosesseja.

Tämän tutkimuksen tavoitteena oli:

• Analysoida yhden tuotelinjan tuotekehitysprosessia simuloinnin ja haastattelujen avulla.

• Laatia parannusehdotuksia prosessissa havaittuihin ongelmakohtiin, jotta niitä voitaisiin korjata nykyisten prosessien puitteissa.

1.3 Tutkimuksen rajoitukset

Tutkimus keskittyy yhden tuotelinjan tuoteprosessiin. Tutkimus kattaa ajanjakson tuotepäätöksestä hyväksymistesteihin. Pääpaino tutkimuksessa on varsinaisessa tuotekehityksessä, määrittelyssä, toteutuksessa, testauksessa ja ylläpidossa. Tutkimus ei käsittele tuotemarkkinoinnin ja projektiraportoinnin osuutta.

1.4 Tutkimusmenetelmät

Tutkimus tehtiin kahdessa osassa, kirjallisuustutkimus ja kohdeyrityksen tuotekehitysprosessin tutkiminen. Kirjallisuustutkimuksessa pääpaino oli selvittää yleisiä prosessikehitysmenetelmiä ja keinoja, joiden avulla prosesseja voidaan systemaattisesti kehittää. Tuotekehitysprosessin tutkiminen toteutettiin käyttämällä yrityksessä kehitettyä Nokiapoly-simulointimenetelmää1, jonka avulla pyrittiin aikaansaamaan todellinen kuva prosessin toiminnasta eri vaiheissa sekä ideoimaan parannusehdotuksia.

1 Mansikkaniemi, Tapio. 1996

(13)

1.5 Tutkimusraportin rakenne

Tutkimus jakautuu selkeästi kahteen osaan, kirjallisuustutkimukseen (luvut 2-6) ja tapaustutkimukseen (luvut 7-10).

Luvussa 1 kuvataan yleiset tavoitteet prosessin kehittämiselle, sekä määritellään ja rajataan tutkimusongelma. Luku 2 esittelee yleisiä prosessin hallintaan ja kehittämiseen tarkoitettuja malleja. Luvussa 3 keskitytään yhden mallin (SPICE) yksityiskohtaiseen esittelemiseen. Luvussa 4 kuvataan yleisistä malleista yksinkertaistettu malli, jota käytetään tämän tutkimuksen teoreettisena runkona. Luku 5 esittelee tekijöitä, jotka keskeisesti vaikuttavat tuotekehitysprosessin tehokkuuteen, ja tehokkuudesta saatavat edut. Luvussa 6 on kirjallisuusosuuden yhteenveto.

Esimerkkiyrityksen ja toimintaympäristön kuvaus on luvussa 7. Luvussa 8 esitetään esimerkkiyrityksen tuotekehitysprosessin analyysi. Analyysin perustana käytetään luvun 4 kirjallisuuteen perustuvaa prosessianalyysimallia sekä luvussa 5 olevia tehokkaan tuotekehityksen lähteitä. Työn lopuksi, luvuissa 9 ja 10, esitellään kehitys- ja toimintasuunnitelma yrityksen tuotekehitysprosessille, joka on muodostettu tutkimuksessa tehdyn analyysin tulosten perusteella.

Osa I: Johdanto

1. JOHDANTO

3. OHJELMISTOPROSESSIN KEHITTÄMINEN SPICE MALLIN MUKAISESTI

5. TEHOKKAAN TUOTEKEHITYKSEN LÄHTEITÄ 2. PROSESSIEN

HALLINTA JA KEHITTÄMINEN

Osa II:

Kirjallisuus

tutkimus

Osa IV:

Yhteenveto

4. PROSESSIEN ANALYSOINTI JA OPTIMOINTI

6. KIRJALLISTUTKIMUKSEN YHTEENVETO

11. YHTEENVETO

Osa III:

Tapaus

tutkimus

I. TUTKIMUS JA KEHITYSYKSIKKÖ 7. NOKIA

TELECOMMUNICATIONS

9. JOHTOPÄÄTÖKSET

10. SUOSITUKSET

Kuva 1: Tutkimusraportin rakenne.

(14)

Kirjallisuustutkimus

(15)

2 Prosessien hallinta ja kehittäminen

Tässä luvussa käydään lyhyesti läpi prosessiajattelun syntyhistoria, sekä esitellään yleisemmät mallit, joiden avulla prosessikehitystä voidaan tehdä systemaattisesti. Luku ei pyri olemaan mikään oppikirja prosessikehitysmenetelmistä, vaan lähinnä sen pyrkimyksenä on tuoda esille käytetyt mallit ja niiden erikoispiirteet. Mallien keskinäiset eroavaisuudet periaatteellisella tasolla ovat varsin vähäisiä. Kaikki pyrkivät parantamaan prosessia systemaattisten syklisten toimenpiteiden avulla, jolloin jokaisen syklin aikana tarkastellaan nykyprosessia, muutetaan prosessia, tarkastellaan muutosten vaikutuksia, ja tehdään päätös jatkokehityskohteista.

Valmistusteknologiat olivat keskeisin kilpailutekijä 70- ja 80-luvuilla, mikä jatkuu edelleen 90-luvulla. Tavoitteena oli tuolloin ja on edelleen valmistaa mahdollisimman paljon laadukkaita tuotteita mahdollisimman edullisesti. Tuotteilta vaadittiin suorituskykyä, laatua, luotettavuutta ja kustannustehokkuutta. Nämä vaatimukset ovat yhä voimassa, menestyäkseen yrityksen on hallittava nämä tekijät. Ennen 80-lukua painotettiin voimakkaimmin tuotteen hintaa ja suorituskykyä, 80-luvulla lisättiin laadullisia näkökulmia, jotka edellyttivät uudenlaista lähestymistapaa yrityksen hoitamiseen.

Painopiste on 90-luvulle tultaessa siirtynyt määrällisistä tavoitteista joustavuuteen, pyrkimykseen kehittää useampia, uudempia ja parempia tuotteita. Edut, jotka saavutetaan läpäisyaikojen lyhentämisellä ja jatkuvasti parempien tuotteiden kehittämisellä, ovat merkittäviä. Markkinaosuuksien uusjako suosii nopeimin sopeutuvia yrityksiä. Yritys, joka pystyy tehokkaasti julkistamaan uusia tuotteita, reagoimaan nopeimmin markkinoiden ja teknologian muutoksiin, ja kehittämään ylivoimaisia tuotteita, tulee valloittamaan markkinaosuuksia kilpailijoiltaan. Keino, jonka avulla nämä tavoitteet voidaan saavuttaa, on suunnitella, kehittää ja parantaa yrityksen tuotekehitysprosessia.

Prosessiajattelu juontaa juurensa aina teollisen vallankumouksen alkuaikoihin. 1800- luvun alkupuoliskolla Englannissa sovellettiin prosessilähtöistä valmistusta S oho Engineering Foundry:n toimesta. Tuolta ajalta löytyy tarkkoja prosessikuvauksia siitä, kuinka metallivalu suoritetaan alusta loppuun2. Charles Babbage kuvasi vuonna 1832 teoksessaan “On the Economy of Machinery and Manufactures” prosessianalyysin tärkeyttä ja prosessien suhdetta tuotteen valmistuskustannuksiin. Babbage myös osoitti, että peräkkäisten työtehtävien välillä vallitsi tarpeettomia esteitä. Frederik W. Taylor kehitti 70 vuotta myöhemmin menetelmiä, joilla peräkkäisiä työvaiheita saattoi tutkia ja analysoida3.

Käsitteenä prosessi alkaa olla jo vakiintunut. Esimerkiksi ISO-järjestön SPICE-projekti määrittelee prosessin seuraavasti: “Prosessi on joukko yhteenkuuluvia tehtäviä, joilla on selkeä alku ja loppu ja jotka muuttavat syötteet tuotoksiksi4. Melan lisää vielä

2 George, C. S. 1968, s. 28 3 Melan, Eugene. 1992, s. 13 4 Davenport, Thomas. 1993. s. 5

(16)

vaatimuksen, että tuotosten arvon tulee olla suurempi kuin panosten5. Humphrey puolestaan määrittelee ohjelmistoprosessin joukoksi työkaluja, menetelmiä ja tapoja, joiden avulla tuotetaan ohjelmistoja6.

Palkin mukaan prosessin johtamisella pyritään painottamaan sopeutumista / mukautumista asiakkaan vaatimuksiin virheettömällä tuotoksella mahdollisimman tehokkaasti ja tuottoisasti, sekä suunnittelemaan ja toteuttamaan oikeanaikaisia muutoksia, joilla vastataan tuleviin tarpeisiin7. Humphrey määrittelee ohjelmistoprosessin johtamisen tarkoitukseksi kehittää tuotteita suunnitelman mukaisesti ja samalla parantaa organisaation kykyä luoda parempia tuotteita8.

Hyvin johdetun prosessin tunnusomaisina piirteinä ovat Melanin mukaan9 :

1. Selkeästi määritelty omistajuus. Prosessin omistaja on henkilö tai ryhmä henkilöitä, joilla on valta ja vastuu seurata ja parantaa prosessia.

2. Selkeät rajat. Prosessin alku- ja loppupisteet, sekä näiden saamat panokset ja tuotokset on selkeästi määritelty.

3. Prosessi dokumentoitu. Prosessin toiminta ja työvaiheet on yksityiskohtaisesti dokumentoituja kaikkien tiedossa.

4. Prosessi sisältää tarkkailupisteitä. Prosessissa on joukko ennaltamääriteltyjä tarkkailupisteitä, joissa etenemistä valvotaan katselmointien ja varmistusten avulla.

5. Prosessia mitataan. Staattisten mittausten avulla kontrolloidaan etenemistä ja muutoksia. Mittausten avulla pyritään reagoimaan tarvittaessa muutoksiin mahdollisimman varhaisessa vaiheessa.

6. Prosessipoikkeamien hallinta. Korjaaviin toimiin ryhdytään oikea-aikaisesti staattisilta mittareita saadun tiedon perustella. Prosessin hallinnan ytimenä on jatkuva tiedon kerääminen ja ohjaus, ilman ohjausta prosessi menettää kyvyn tuottaa laadukasta tulosta.

Nämä kuusi kohtaa Melan kasaa kolmeksi prosessinhallinnan vaiheeksi10 kuvan 2 mukaisesti.

Omistajuuden määrittäminen

Rajojen määrittäminen

Prosessin dokumentointi

Tarkkailu- pisteiden asettaminen

Prosessin mittaaminen

Poikkeamien hallinta

_________ ^ --- v ame i, Alustammen--- ^

Määrittely

Kuva 2: Prosessinhallinnan vaiheet.

5 Melan, Eugene 1992. s. 15 6 Watts, Humprey. 1989. s. 3 7 Pali, Gabriel. 1987. s. 25 8 Watts, Humphrey. 1989. s. 3 9 Melan, Eugene 1992. s 21 10 Melan, Eugene 1992. s. 78

(17)

Ensimmäisessä vaiheessa määritellään prosessin omistaja, prosessin rajat ja rajapinnat.

Toisessa vaiheessa määritellään ja dokumentoidaan prosessi, jota kolmannessa vaiheessa seurataan ja mitataan, sekä käynnistetään tarvittaessa korjaavia toimenpiteitä.

2.1 Prosessikehitykseen käytettäviä malleja

Ohjelmistoprosessin kehittäminen noudattaa yleisesti jatkuvan kehittämisen periaatetta.

Tämä alkujaan Japanissa syntynyt Kaizen-toimintotapa perustuu pienten asioiden entistä parempaan hallintaan. Kaizen-menetelmän varhaisen omaksumisen katsotaan pitkälti selittävän japanilaisen teollisuuden valmistusteknologian kypsyyttä ja kykyä mukautua nopeasti markkinoilla tapahtuviin muutoksiin"

2.1.1 Total Quality Managemant

Total Quality Management (TQM) on joukko yleisiä prosessinhallintamenetelmiä, jotka kattavat organisaation kaikki toiminnot, kuten tuotekehityksen, markkinoinnin ja henkilöstön. TQM on luonut perustan usealle yleisesti hyväksytylle periaatteelle, kuten jatkuva kehittäminen, asiakastyytyväisyys ja prosessinhallinta. TQM:n keskeiset

• 12

periaatteet ovat :

1. Prosesseja tulee tarkastella asiakkaan näkökulmasta (sisäiset ja ulkoiset asiakkaat) 2. Prosessinhallinnan tulee pyrkiä kohti parempia prosesseja

3. Kaikkien tulee osallistua prosessin hallintaan ja kehittämiseen 4. Esimiesten tehtävänä on toimia valmentajana

TQM mukainen prosessin kehittäminen käsittää seitsemän eri vaihetta11 12 13, joiden avulla prosessia systemaattisesti kehitetään:

1. Prosessin valinta. Prosessin valintaan vaikuttavat monet tekijät, kuten johdon toiveet, asiakkailta saatu palaute, työntekijöiden palaute, prosessin tärkeys ja kriittisyys, koko ja kustannus sekä vaikutus asiakkaan tyytyväisyyteen.

2. Parannussuunnitelman laadinta. Parannussuunnitelma sisältää parannustiimin tehtävän ja tavoitteen, koulutustarpeiden kartoituksen, tarvittavan tuen kartoituksen, palaverikäytännön, katselmussuunnitelman, dokumentointisuunnitelman ja yleisen prosessinparannushankkeen aikataulun.

3. Prosessitiimin muodostaminen. Prosessitiimin miehitys valitaan prosessikohtaisesti, joko osastokohtaisesti tai organisaation eri osa-alueilta. Jäsenten valintaan vaikuttaa tietotaidon lisäksi jäsenten kyky kommunikoida ja tulla toimeen toistensa kanssa.

11 Cost Management. 1994. s. 189 12 Burgos-Lovece, Lain. 1996. s. 26 13 Melan, Eugene. 1992. s. 150

(18)

4. Prosessihallinnan analysointi. Analysoinnin aikana tulisi saada selkeä kuva, miksi eri työvaiheet ovat olemassa ja miksi ne hoidetaan nykyisellä tavalla. Vastausten tulisi tarvittaessa johtaa nykytapojen muuttamiseen tai poistamiseen.

5. Pitkän ja lyhyen aikavälin parannusten määrittely. Lyhyen aikavälin parannushankkeet tähtäävät jonkin nykyisen ongelman helpottamiseen tai poistamiseen ilman suurempaa taloudellista panostusta. Hankkeet tulee lisäksi voida hoitaa nopeasti. Pitkän aikavälin parannukset ovat innovatiivisia parannuksia, jotka vaativat useasti taloudellista panostusta.

6. Prosessinomistajan sitoutuminen prosessikehitykseen. Parannusten määrittelyn jälkeen parannushankkeet katselmoidaan prosessinomistajan kanssa. Hyväksytty

hanke toteutetaan.

7. Muutosten vaikutuksen arviointi. Toteuttamisen jälkeen muutosten vaikutukset arvioidaan, ja laaditaan tavoitteet uusille parannushankkeille, eli prosessikehityssykli käynnistetään uudelleen.

2.1.2 ISO 9000

ISO 9000 on laatujärjestelmän kansainvälinen standardi, joka on askel kohti TQM:n mukaista toimintaa. ISO 9000 ei takaa laatua, vaan standardi pakottaa ainoastaan dokumentoimaan nykyisen toimintatavan. Dokumentoidun mukaista toimintatapaa tulee noudattaa kaikkialla organisaatiossa. Koska koko prosessien toiminta on dokumentoitu ja kaikkien tiedossa, mahdollistaa tämä niiden hallitun muuttamisen14.

2.1.3 Humpreyn malli

Humpreyn esittämä ohjelmistoprosessien kehityshanke sisältää kuusi askelta15:

1. Prosessien nykytilanteen kartoitus 2. Vision luominen toivetilasta

3. Tarvittavien parannusten paneminen tärkeysjärjestykseen.

4. Toteutussuunnitelman laadinta

5. Parannushankkeiden tarvitsemien voimavarojen kohdistaminen.

6. Uuden kehitysjakson, aloittaen kohdasta 1.

2.1.4 PQMI

AT&T on vastaavasti luonut oman nelivaiheisen mallinsa prosessin ohjaamiseksi ja jatkuvaksi parantamiseksi (PQMI)16. AT&T:n mallin neljä vaihetta ovat :

14 Gilbert, John. 1992. s. 34 15 Watts, Humphrey. 1989, s. 4 16 Melan, Eugene. 1992. s. 160

(19)

1. Omistajuuus. Prosessinomistaja, joka pystyy hallitsemaan prosessia ylitse organisatoristen rajojen. Tähän vaiheeseen kuuluu myös prosessitiimin luominen.

2. Arviointi. Prosessin määrittäminen, mittaaminen ja arviointi.

3. Kehityskohteiden valinta. Prosessin parannuskohteiden asettaminen tärkeysjärjestykseen ja valinta. Varsinkin asiakastyytyväisyyteen ja tuotteen kustannuksiin liittyvät tekijät ovat erityistarkastelun kohteena.

4. Parantaminen. Kehittämiskohteiden toteuttaminen prosessitiimin toimesta.

2.1.5 CMM-malli

Yhdysvalloissa on suurta suosiota saavuttanut Software Engineering Institute of Carnegie Mellon Universityn (SEI) kehittämä CMM-malli (Capability Maturity Model).

CMM-mallissa määritellään viisi kypsyystasoa ohjelmistoprosessille (alustava, toistettava, määritelty, hallittuja optimoitu), niiden ominaisuudet ja minimivaatimukset.

CMM-malli painottaa prosessin hallintaa. Mallissa kuvataan asiat, joiden tulee olla hyvin hallinnassa, jotta organisaatio voisi siirtyä ylemmälle kypsyystasolle17.

Taulukko 1: CMM-mallin kypsyystasot.

Taso Tason nimi Kuvaus tasosta

1 Alustava (Initial) Kahdesta samanlaisesta projektista ei pystytä suoriutumaan

samalla tavalla. Tuotteet myöhässä ja budjetti ylittyy.

2 Toistettava (Repeatable) Johtamisperiaatteet vakiintuneet. Projektien suunnittelu ja hallinta perustuvat kokemukseen samankaltaisista projekteista.

3 Määritelty (Defined) Ohjelmistokehitys on dokumentoitu. Budjetteja, laatua ja

aikatauluja seurataan tarkasti. Organisaatiossa vallitsee laaja ymmärrys toiminnoista, rooleista ja vastuualueista.

4 Hallittu (Managed) Tuottavuutta ja laatua mitataan kaikilla prosessin osa-alueilla.

Toiminta ennakoitavissa, koska prosessi on tarkkaan määritelty.

5 Optimoitu (Optimising) Koko organisaatio on keskittynyt jatkuvaan prosessin

kehittämiseen. Tietoja prosessin tehokkuudesta käytetään uusien menetelmien löytämiseen ja entisten toimintamallien parantamiseen.

CMM-mallilla voidaan analysoida organisaation vahvuuksia ja heikkouksia, sekä tulevia yhteistyökumppaneita näiden CMM-tasojen perusteella. Ylin johto sekä tekninen henkilökunta käyttävät sitä ymmärtääkseen prosessin nykytoimintoja ja toimenpiteitä, joita tarvitaan, jotta prosessia voitaisiin parantaa.

Kypsyystason määritys helpottaa saavutettavissa olevien tulosten ennakointia. Kun organisaation kypsyystaso nousee, ero suunniteltujen ja saavutettujen tulosten välillä pienenee. Alimmalla tasolla oltaessa kahden ulkoisesti samanlaisten projektien välillä ei ole kovin suurta yhdenmukaisuutta, kun taas tasolla 3 voidaan tulokset ennakoida aikaisempien vastaavien projektien perusteella18.

17 Hagros, Kaj. 1995. s. 30 18 Curtis & Weber. 1993. s. 24

(20)

Ylemmälle kypsyystasolle siirtyminen vaatii pitkäjänteistä prosessikehitystä.

Humphreyn havaintojen mukaan esim. siirtyminen tasolta 1 tasolle 2 tai tasolta 2 tasolle 3 vie keskimäärin 1-3 vuotta19 20.

CMM-mallin vaikutuksia ohjelmistoprosessiin on tutkittu ainakin SEI:n toimesta.

CMM-mallin edut ohjelmistoprosessin kannalta on esitetty SEI-raportin'0 mukaisesti taulukossa 2.

Taulukko 2: CMM.n vaikutukset prosessiin.

Tunnusluku keskiarvo

CMM-pohjainen prosessin parannus käytössä 3,5 vuotta Kustannukset / ohjelmistosuunnittelija (USD) 1375 Vuosittainen tuottavuuden parannus 35 % Vuosittainen vikailmoitusten väheneminen 39 % Vuosittainen parannus markkina-ajoituksessa 19 % Muutosten kannattavuus (säästöt/kustannukset)5

2.1.6 Trillium

Trillium (Telecom product development process capability) on malli, joka on pyritty kehittämään tietoliikenneteollisuuden tarpeita huomioiden. Mallin kehittelyssä on hyödynnetty muiden mallien ( CMM, SPICE, jne.) toimintatapoja.

Trillium-mallia käytetään oman organisaation tuotekehitysprosessin vertaamiseen teollisuuden parhaimpiin toimintatapoihin, alihankkijan valintaan ja kehittämiskohteiden kartoittamiseen. Trillium-mallissa on viisi eri suoritustasoa:

Taulukko 3: Trillium-mallin suoritustasot.

Suoritustaso Tason kuvaus 1 Strukturoimaton

2 Toistettava ja projektiorientoitunut 3 Määritelty ja prosessiorientoitunut 4 Hallittuja integroitu

5 Täysin ohjattu

Trilliumin keskeiset osa-alueet ovat laadun hallinta, henkilöstön kehittäminen, prosessin hallinta, laatujärjestelmät, kehittämismenetelmät, kehittämisympäristö ja asiakaspalvelu21.

19 Watts, Humphrey. 1989. s. 14 20 SEI/CMU-94-TR-13. 1994

21 Trillium-Telecom Product Development Process Capability Model. 1993. s. 18

(21)

Eri malleja vertaamalla voidaan selvästi nähdä mallien muistuttavan toisiaan. Kaikki mallit sisältävät seuraavat kuusi yhteistä piirrettä22:

1. Muutostarpeille saatava ylimmän johdon sitoutuminen. Prosessissa työskentelevät henkilöt pyrkivät yleensä tekemään parhaansa käytettävissä olevien menetelmien puitteissa. Johdon kehoitukset eivät ole riittäviä, vaan saattavat jopa johtaa vastakkaissuuntaiseen toimintaan. Johdon tulee asettaa asiat tärkeysjärjestykseen, osoittaa tavoitteet, hankkia resurssit ja tarjota jatkuvaa tukea.

2. Kaikkien osallistuminen välttämätöntä. Ohjelmistoprosessin tärkein voimavara on henkilöresurssit, jotka pyrkivät hoitamaan tehtävänsä mahdollisimman hyvin.

Prosessikehityksen tulee kohdistua menetelmiin eikä henkilöihin.

3. Tehokas muutoksen läpivienti edellyttää nykyprosessin tuntemusta. Prosessit eivät välttämättä toimi käytännössä siten kuin johto kuvittelee. Jotta muutoksia voidaan tehdä, tulisi nykyprosessi tarkkaan kartoittaa. Kartoitus on oppimisprosessi, jossa prosessissa työskenteleviltä tulisi selvittää, kuinka nykyisin toimitaan ja kuinka heidän mielestään tulisi toimia. Tehtävän haltija on kyseisen työvaiheen suurin asiantuntija.

4. Muutos on jatkuva. Ihmiskeskeiset prosessit eivät ole staattisia, vaan niihin kohdistuu jatkuvia muutospaineita. Sekä resurssit että ongelmat ovat jatkuvan muutospaineen

alaisia, mikä vaatii tehtävien ja työtapojen kehittämistä.

5. Prosessien muutosten toteuttaminen vaatii jatkuvaa seurantaa. Ohjelmistojen kehittäminen on erittäin järjestelmällistä työtä, jonka suorittaminen edellyttää koordinointia ja ohjausta. Asiantuntijoiden työtä täytyy seurata, katselmoida ja tarkastella, jotta prosessin mahdolliset poikkeamat saataisiin selville.

6. Ohjelmistoprosessin parantaminen vaatii aikaa, taitoa ja rahaa. Muutokset eivät tapahdu itsestään, vaan jonkun on tehtävä työtä niiden eteen. Muutosten tekeminen ilman selkeitä suunnitelmia ei johda hyvään tulokseen. Huonosti määritellyn prosessin kehittäminen johtaa huonosti määriteltyihin tuloksiin. Muutokset tulee tehdä pienissä askeleissa. Muutosten tekeminen vaatii jatkuvaa koulutusta.

Prosessien parantaminen, millä pyritään asiakastyytyväisyyden kohottamiseen ja tehokkaamman toiminnan saavuttamiseen niin resurssi- kuin aikamielessä, ei toteudu hetkessä. Gilbertin23 mukaan prosessikehitykseen kuluva aika voidaan esittää kuvan 3 mukaisesti:

22 Watts, Humphrey. 1989. s. 19-24 23 Gilbert, John. 1992, s. 36

(22)

Kuva 3: Prosessinkehittämiseen tarvittava aika.

Gilbert jakaa muutoksen neljään vaiheeseen: tietoisuus, suunnittelu, toteutus ja vakiintuminen. Vaiheiden pituudet vaihtelevat tapauksesta toiseen, kokonaisaikatarpeen vaihdellessa 3-10 vuoteen. Tietoisuusvaiheessa keskitytään prosessiperiaatteiden ymmärtämiseen ja tiedon välittämiseen organisaatiolaajuisesti. Suunnitteluvaiheessa muodostetaan kehitystiimejä ja laaditaan priorisoituja parannussuunnitelmia.

Toteutusvaiheessa siirretään huomio päivittäisrutiineista kokonaisuuksiin ja käytännön prosessikehitykseen. Vakiintumisvaiheessa muokataan asenteet hyväksymään muutokset prosessissa ja työtavoissa.

Tämän tutkimuksen puitteissa keskityttiin läpikäymään tarkemmalla tasolla ISO- järjestön puitteissa ohjelmistoprosesseja varten määriteltyä SPICE (Software process

improvement and capability determination) -mallia.

(23)

3 Ohjelmistoprosessin kehittäminen SPICE-mallm mukaisesti

Luvussa 3 käydään läpi edellisessä kappaleessa mainittu SPICE-malli, joka on kehitetty nimenomaan ohjelmistoprosesseja silmälläpitäen. Mallin mukaisesta toiminnasta pyritään antamaan riittävän yksityiskohtainen kuva. Pääpaino on SPICE-mallin mukaisten kehitysaskeleiden pääsisällön esittelyssä.

Spice-malli on ISO-järjestön puitteissa erityisesti ohjelmistoprosesseja varten kehitetty malli, jonka tarkoituksena on toimia eurooppalaisena vastineena amerikkalaiselle CMM-mallille. SPICE-malli sisältää kuusi suoritustasoa, joista jokainen taso tarjoaa huomattavan parannuksen prosessin suoritukseen.

Taulukko 4: Spice-mallin suoritustasot.

Taso Tason nimi Kuvaus tasosta 0 Epätäydellinen

(Incomplete)

Prosessin vaihetuotteiden tai tuotosten identifiointi hankalaa.

1 Suoritettu (Performed)

Prosessin tavoite saavutetaan yleensä. Tavoitetta ei voida tarkkaan määritellä eikä prosessinkulkua seurata. Prosessi tuottaa tunnistettavia vaihetuotteita.

2 Hallittu (Managed)

Prosessi tuottaa vaihetuotteita hyväksyttävällä laadulla ja aikataulun mukaisesti. Prosessi on suunniteltuja hallittu.

3 Vakiintunut (Established)

Prosessin suoritus ja hallinta noudattaa standardoitua, määriteltyä ja hyvää käytäntöä.

4 Ennustettava (Predictable)

Prosessin tehokkuutta mitataan ja analysoidaan. Prosessi on kvantitatiivisesti ymmärrettyjä hallittu.

5 Optimoituva (Optimizing)

Prosessin tehokkuus on optimoitu vastaamaan nykyisiä ja tulevia tarpeita. Prosessia tarkkaillaan ja kehitetään jatkuvasti tarpeita vastaavaksi.

Organisaation prosessikehityshankkeet toteutetaan peräkkäisten toimenpiteiden avulla.

Toimenpiteiden jälkeen tulokset kerätään ja analysoidaan, minkä jälkeen voidaan siirtyä seuraavaan toimenpiteeseen. Prosessikehitykseen liittyvät askeleet on esitetty kuvassa 4.

(24)

• Organisaation tarpeet

•Prosessin parannustarpeet Organisaation

tarpeiden kartoitus ,

Muutokset laajennettu

Suoritustason

tarkkailu Parannusten

ylläpito Vahvistetut

parannukset

Parannus

ehdotuksia

Muutosten varmentaminen

Nykytilan uusin takartoitus

Prosessikehityksen aloitus

Parannukset suoritettu Alustava prosessi-

kehitys suunnitelma Uusin takartoituksen

tulokset

Muutosten toteuttaminen Nykytilan

kartoitus Tulosten

analysointi Hyväksytty toimintasuunnitelma Kartoituksen

tulokset

Kuva 4: Spice-mallin mukaiset prosessinkehityksen askeleet.

Laajat prosessikehityshankkeet muodostuvat useasta toimenpidesyklistä. Jokaisen syklin jälkeen analysoidaan nykytilanne, jonka tulosten perusteella, mahdollisten korjaavien

toimenpiteiden jälkeen, toistetaan toimenpidesykli.

3.1 Organisaation tarpeiden kartoitus

Prosessikehityshankkeet käynnistetään tunnistamalla ja asettamalla tärkeysjärjestykseen organisaation tarpeet ja tavoitteet johonkin keskeiseen päämäärään (esim. läpimenoaika, kustannus, laatu) pohjautuen.

Tarpeiden tunnistaminen voidaan suorittaa analysoimalla:

• Organisaation taloudellisia tavoitteita.

• Organisaation pitkän ajan kehityssuunnitelmaa.

• Organisaation nykyistä arvomaailmaa / asenteita ja käyttäytymistä.

• Organisaation valmiutta kehittää toimintatapojaan.

• Markkinoiden kehittymistä.

• Asiakkaalta saatua palautetta.

• Organisaation toimintaa suhteessa kilpailijoihin (benchmark).

• Työntekijöiden tyytyväisyyttä.

• Yhteisöltä / viranomaisilta tulleita odotuksia.

Tarpeiden tunnistamisen jälkeen voidaan prosessikehityshankkeelle asettaa selkeästi mitattavissa oleva tavoite laadun, läpimenoajan, ennustettavuuden, riskienhallinnan tai

(25)

kustannusten suhteen. Tarpeiden tunnistamisen jälkeen tulee tarpeet vielä asettaa tärkeysjärjestykseen, sekä hankkia tarvittavat resurssit ja johdon sitoutuminen kehityshankkeeseen.

3.2 Prosessikehityshankkeen aloitus

Prosessikehityshankkeet suoritetaan projekteina, joille laaditaan asianmukaiset suunnittelmat, joiden seurannasta huolehditaan, ja joita ohjataan aktiivisesti.

Suunnitelman tulee sisältää taustatietoa ja selvitys nykytilanteesta, mieluiten ilmaistuna selkeillä mittareilla, sekä kuvaus tavoitetilasta ja toimet, jotka siihen johtavat.

Vaatimukset suunnitelmalle saadaan organisaation kartoituksen tuloksena.

3.3 Prosessin nykytilan kartoitus

Prosessikartoitusvaiheen alussa nimetään takuumies (sponsor), omistaja (owner) ja kartoituksen tekijä. Prosessikartoitusvaiheen takuumieheksi nimetään henkilö, joka on sitoutunut prosessikehitykseen ja jolla on vastuu ja valta aikaansaada parannuksia prosessiin. Takuumies huolehtii, että prosessikehityksen tavoite, sisältö ja vastuut myötäilevät prosessikehityshankkeen tarpeita. Omistaja puolestaa huolehtii omalla auktoriteetillaan siitä, että kartoitus saadaan tehdyksi. Kartoituksen tekijäksi (tekijöiksi) valitaan henkilö, joka nauttii omistajan ja organisaation jäsenten luottamusta.

Tarvittaessa voidaan kartoituksen tekijäksi valita myös joku ulkopuolinen taho.

Ulkopuolisella kartoituksen tekijällä on yleensä puolueettomampi näkemys asioista.

Takuumiehen vastuuseen kuuluu huolehtia, että kartoituksen tekijällä on tarvittava tietoisuus kehityshankkeen tavoitteista ja tietolähteistä. Omistaja vastaa, että kaikki prosessiin liittyvät tekijät ovat tarvittaessa tavoitettavissa.

Prosessikehitysohjelma voi kohdistua kokonaisen organisaation laajuudelle, osalle organisaatiota, projektille tai yksittäiselle tehtävälle. Kartoitus puolestaan kohdistetaan siten, että kerralla kartoitetaan ainoastaan sellaista organisaation osaa, jonka prosessit ovat samankaltaisia sisällön, koon, kriittisyyden ja monimutkaisuuden suhteen. Jos prosessikehityshanke kattaa erilaisia organisaatioita, toteutetaan erillinen kartoitus kussakin yksikössä.

Kartoituksen tuloksena saadaan kuvaus prosessin nykytilasta, selvitys eri yksiköiden välisistä eroavaisuuksista ja koulutustarpeista, sekä lista mahdollisesti käynnissä olevista parannuksista.

3.4 Kartoituksen tulosten analysointi

Informaatio, joka kartoituksen yhteydessä on kerätty, analysoidaan suhteessa organisaation tarpeisiin. Tulosten perusteella tulisi voida:

• tunnistaa ja valita parannettavat osa-alueet

(26)

• asettaa laadullisia ja määrällisiä tavoitteita ohjelmistoprosessille

• laatia toimintasuunnitelma, joka liitetään osaksi prosessikehityssuunnitelmaa

Kartoituksen tuloksena saadaan informaatiota nykyprosessin vahvuuksista ja heikkouksista.

Tuottavuus / tehokkuus- mittaukset x

Organisaation tarpeet ja tavoitteet ч

Parannuskohteiden tunnistus ja asettaminen tärkeysjärjestykseen

Prosessikartoituksen

tulos Kehityskohteet

Riskitekijät

Teollisuusnormit

Kuva 5: Parannettavan osa-alueen valintaan vaikuttavia tekijöitä.

Prosessimittareita voidaan hyödyntää valintaa tehtäessä edellyttäen, että prosessimittareita on aikaisemmin säännöllisesti käytetty ja tuloksia kerätty. Hyviä prosessimittareita valintaa tehtäessä ovat tehokkuus-, tarkkuus-, luotettavuus / laatuja toistettavuusmittarit. Riskitekijöinä tulisi huomioida vaikutukset yrityksen tarpeisiin, mikäli prosessikehityshankkeen tavoitteita ei saavuteta. Tavoitteet voivat jäädä saavuttamatta johtuen mm. aikataulullisista syistä, psykologisista tai kulttuurillisista eroavaisuuksista johtuvista syistä tai yleisestä muutosvastarinnasta.

Tavoitteet prosessikehityshankkeelle asetetaan määrittelemällä laadulliset tavoitteet kehityshankkeille, kehittämällä sopivat mittarit asetetuille tavoitteille ja asettamalla tavoitearvot mittareille, mahdolliset riskitekijät huomioiden.

Toimintasuunnitelmaan kerätään ne toimet, joiden avulla tavoitteisiin pyritään. Toimet tulee valita niin, että jotkut lähiajan tavoitteet saavutetaan varmuudella. Täten aikaansaadaan uskoa prosessikehityshankkeeseen, varsinkin organisaatioissa, joilla ei ole aikaisempaa kokemusta kehityshankkeista. Jokaiselle toimelle tulee määritellä selkeä kriteeri ja mittari, joista yksiselitteisesti selviää toimen tila kussakin vaiheessa.

3.5 Prosessikehityksen toteuttaminen

Prosessikehitysohjelman toteuttamisella pyritään parantamaan yrityksen ohjelmistokehitysprosessia. Tapa, jolla kehitysohjelmaa toteutetaan, valitaan tilannekohtaisesti. Kehitysohjelma voidaan testata jossakin yksittäisessä organisaation osassa, joissakin organisaation osissa, tai koko organisaation laajuisesti.

(27)

Kehitysohjelman valintaan vaikuttavia tekijöitä ovat kustannus, aika ja riskitekijät.

Prosessikehityksen toteuttamissuunnitelmaan kirjataan tavoite, toteutustapa, vastuut, aikataulu ja resurssitiedot, seurantatapa, riskien/muutosten hallinta sekä onnistumiskriteerit.

Menestyksekäs prosessikehityksen toteuttaminen edellyttää, että inhimilliset ja kulttuuritekijät huomioidaan. Erityisesti tulisi miettiä:

• Kuinka esimiesten tuesta / sitoutumisesta voidaan varmistua.

• Mitä muutoksia arvoissa / asenteissa/käyttäytymisessä mahdollisesti tarvitaan.

• Kuinka sitoutuminen tavoitteisiin saavutetaan kaikilla tasoilla, e Kuinka edistetään avointa kommunikaatiota ja yhteistyötä.

• Tarvitaanko tunnustus- ja palkitsemisjärjestelmiin muutoksia.

• Minkälaista koulutusta tarvitaan.

Vastuu prosessikehitykseen tarvittavan ympäristön luomisesta kuuluu esimiehille, erityisesti ylimmälle johdolle. Ylimmän johdon tulisi ymmärtää, että organisaation menestyminen riippuu ohjelmiston laadusta ja organisaation kyvystä kehittää ohjelmistoprosesseja. Keskijohto saattaa muodostaa riskitekijän kehityshankkeille. Se on monesti huolissaan, kuinka saavutetaan ne tavoitteet, jotka käynnissä olevat ohjelmistoprojektit asettavat. Prosessikehityshankkeet, joiden edut näkyvät vasta pidemmällä aikavälillä, eivät aina välttämättä saavuta suurtakaan suosiota keskijohdossa. Keskijohto kokee helposti ja osittain aiheellisestikin, että kehityshankkeet, jotka työllistävät samoja resursseja, joiden tulisi huolehtia ohjelmistoprojektien onnistumisesta, vaarantavat lyhyen aikavälin tavoitteet.

Riskitekijää voidaan pienentää informoimalla ja kouluttamalla keskijohtoa ymmärtämään pitkän aikavälin tavoitteet ja niiden merkitys. Myös keskijohdon rooli saattaa vaatia muutosta auktoritäärisestä johtamisesta yhteistoimintaan pohjautuvaan johtamiseen, jossa esimiehen rooli on valmennuksellinen. Ohjelmistokehitys, joka vaatii korkeasti koulutettua henkilöstöä, tuottaa parempia tuloksia yhteistoimintaan pohjautuvassa ympäristössä.

Onnistunut prosessinkehityshanke vaatii useasti joukon uusia arvoja ja asenteita, joihin saattaa kuulua:

e Ulkoisten ja sisäisten asiakkaiden tyytyväisyyteen panostaminen.

• Henkilökunnan sitoutuminen kehityshankkeeseen voi edellyttää panostusta soveltuvaan palkitsemisjärjestelmään.

• Koko ohjelmistoketjun sisällyttämistä prosessinkehityshankkeeseen.

• Johdon sitoutumisen osoittamista hankkeeseen, kommunikoimalla tarkoitukset ja tavoitteet.

• Jokaisen kehityshankkeeseen osallistumisen merkityksen painottamista ja huolehtimista siitä, että jokainen ymmärtää oman työnsä merkityksen kehityshankkeen onnistumiselle.

• Avoimen kommunikaation edistäminen, jotta tarvittava informaatio on kaikkien saatavilla.

(28)

Sitoutuminen yhteisiin tavoitteisiin aikaansaadaan huolehtimalla, että tavoitteet ovat ymmärrettäviä, riittävän haastavia ja olennaisia. Eteneminen tulee tehdä nähtäväksi säännöllisillä mittauksilla. Tavoitteet tulisi asettaa joko menetelmäkeskeisiksi (parantaa prosessien kypsyystasoa) tai tehokkuuskeskeisiksi (läpäisyaika, tuottavuus), tai näiden kahden kombinaationa.

Tuottava ja tehokas ohjelmistoprosessi edellyttää, että kommunikaatio eri tahojen välillä on toimivaa ja vailla henkilökohtaisia tai organisatorisia esteitä. Esteetön kommunikointi edellyttää molemminpuoleista luottamusta ja taitoa. Ohjelmistotyöhön tyypillisesti kuuluva tehtävien rinnakkaisuus edellyttää tehokasta tiimimäistä työskentelytapaa. Tiimimäiseen toimintatapaan pääsemiseksi olisi huolehdittava riittävän koulutuksen järjestämisestä.

Tärkeää on myös tehdä selväksi, että kehityshankkeiden tarkoituksena ei ole syyttää ketään tehtävien laiminlyönnistä, vaan yhdessä analysoida ja kehittää prosessia.

Tulokset ja havainnot tulisi myös analysoida yhdessä ennen raportointia. Mikäli tämä laiminlyödään, saattaa jokin taho ryhtyä laiminlyömään ja vastustamaan tuloksia, vaarantaen näin koko kehityshankkeen.

Sopivan palkitsemisjärjestelmän avulla voidaan auttaa ja rohkaista tekemään niitä asenne ja käyttäytymismuutoksia, joita tarvitaan, jotta prosessinkehitys onnistuisi.

Palkitsemisjärjestelmä tulisi suunnitella siten, että se tunnistaa ja palkitsee ryhmäsuorituksia, estäen samalla sisäisen kilpailun syntyä.

3.6 Muutosten varmentaminen

Muutosten toteuttamisen jälkeen organisaation johdon tulisi:

• Varmistaa prosessin tehokkuusmittareilla, että suunnitellut tavoitteet ja edut on saavutettu.

e Varmistaa, että on luotu tarvittava yrityskulttuuri ilman epätoivottuja sivuvaikutuksia.

• Arvioida uudelleen parannettuun prosessiin liittyvät riskitekijät ja varmistaa, että ne ovat hyväksyttävällä tasolla.

• Uudelleenarvioida kustannukset ja edut.

Jos muutosten vaikutus ei ole ollut odotusten mukainen, tulisi prosessikekitysprojekti määritellä uudelleen ja palata aikaisempaan vaiheeseen.

3.7 Parannusten ylläpito

Prosessikehityksen tuomien muutosten varmentamisen jälkeen tulisi varmistua siitä, että muutokset varmasti otetaan käyttöön kaikkien niiden joukossa, joita muutos koskettaa.

Tämä edellyttää suoritustason tarkkailua ja tarvittaessa kannustusta. Suoritusten tarkkailusta vastaava taho tulisi nimetä, ja määritellä, kuinka tarkkailu tulee suorittaa.

Jos prosessikehitystä on kokeiltu jonkin yksittäisen projektin tai organisaatiohaaran

(29)

puitteissa, tulisi muutos levittää koko organisaation laajuiseksi. Laajentaminen tulee suorittaa suunnitellusti ja sille tulee nimetä tarvittavat resurssit. Suunnittelussa tulisi huomioida erityisesti:

• Keitä kaikkia muutos koskettaa.

• Kuinka muutokset ja niiden vaikutukset esitetään.

• Koulutustarpeiden kartoitus.

• Muutosten ajoitus, huomioiden liiketaloudelliset tarpeet.

• Kuinka varmistetaan, että muutokset otetaan käyttöön.

• Kuinka varmistetaan, että muutokset toimivat odotetusti.

3.8 Suoritustason tarkkailu

Ohjelmistoprosessin suoritustasoa tulisi jatkuvasti tarkkailla ja uusia kehitysprojekteja käynnistää jatkuvana prosessina. Prosessien tarkkailuun käytettävät mittarit ja menetelmät tulisi valita siten, että ne vastaavat organisaation tarpeita ja tavoitteita.

(30)

4 Prosessin analysointi ja optimointi

Luvussa 4 pyritään yhteenvetämään luvuissa 2 ja 3 esitettyjen mallien keskeiset piirteet, ja luomaan yksinkertaistettu malli, joka palvelee tämän tutkimuksen tarpeita paremmin kuin varsinaiset prosessioptimointimallit. Esitetty malli on kevennetty versio aikaisemmista, ja sen käyttötarkoitus on palvella pienimuotoisia prosessioptimointiin tähtääviä kehityshankkeita.

Tämän tutkimuksen puitteissa pyrittiin tutkimusongelman mukaisesti tarkastelemaan nykyistä tuotekehitysprosessia, kajoamatta itse prosessiin. Näin ollen ylläolevia malleja ei suoraan voida soveltaa, vaan näistä laadittiin kuvan 6 mukainen yksinkertaistettu kolmivaiheinen malli, jota käytetään tämän tutkimuksen teoreettisena runkona.

1. Prosessin analysointi 2. Prosessin optimointi 3. Prosessin jäädyttäminen

Odotukset tavoitteet

Resurssit Ympäristö

Analysointi Resurssien

kohdistus

Menetelmät Jäädytys

Optimointi

Ihmiset ja järjestelmät

Mittaus irganisaation’

rakenne , ^Motivointi

Kuva 6: Kolmivaiheinen prosessikehitysmalli.

Tutkimuksen kappaleissa 4.1-4.3 esitetään kunkin kohdan sisältö. Sisältö noudattelee prosessikehityskirjallisuudessa esitettyjä suuntaviivoja. Tutkimusongelman rajausta noudattaen keskitytään tuotekehitysprosessin kehittämiseen. Esitetyt menetelmät ovat kuitenkin yleiskäyttöisiä, soveltuen myös muiden liiketaloudellisten prosessien

(31)

analysointiin ja optimointiin. Menetelmät olettavat, että organisaatiossa on olemassa vakiintuneet prosessit, joita halutaan parantaa.

4.1 Prosessin analysointi

Prosessin analysoinnilla pyritään arvioimaan ja ymmärtämään prosessissa vallitsevat todelliset ongelmat ja keräämäään tietoa muutosmahdollisuuksista24 kuvan 7 mukaisesti.

Prosessi

Tutkimuksen

y suorittaa Ilmaisee kyvykkyyden ja riskit

Identifioi

muutokset

Prosessin analysointi

Johtaa

Prosessin kehittäminen

Kyvykkyyden määrittely Motivoi

Kuva 7: Prosessin analysointi.

Prosessin analysoinnin tavoitteena on

e Oppia, kuinka prosessi todellisuudessa toimii.

• Tunnistaa vakavimmat ongelmat prosessissa.

Prosessin analysoinnissa tulee keskittyä sekä prosessin tehoon (effectiveness), että sen suorituskykyyn (efficiency). Prosessin teholla tarkoitetaan prosessin kykyä vastata asiakkaan tarpeisiin, todellista tuotosta suhteessa odotettuun tuotokseen. Prosessin suorituskyky puolestaan kuvaa, kuinka hyvin prosessin eri osa-alueet toimivat yhteen eli tuotosten määrää suhteessa käytettyihin resursseihin. Tehokkuuden saavuttamisen jälkeen huomio tulisi keskittää suorituskyvyn parantamiseen. Tehottoman prosessin

tunnusmerkkejä ovat25:

• Asiakkaiden valitukset.

• Laadun vaihtelut tuotoksessa.

24 Watts, Humphrey. 1989. s. 31 25 Melan, Eugene. 1992, s. 112

(32)

• Epätietoisuus tuotoksen laadusta.

• Korjaavien toimien puuttuminen.

• Asiakastarpeita ei tunneta.

• Pitkät vasteajat ongelmiin.

Prosessin tehokkuutta ja suorituskykyä arvioidaan parhaiten sisäisten ja ulkoisten mittausten avulla. Tehokkuus ja suorituskyky voivat olla toistensa vastakohtia.

Esimerkiksi, jos tehokkuusvaatimukseksi asetetaan tasainen laatuja tähän pääsemiseksi lisätään uusia laaduntarkistuspisteitä prosessiin, voidaan kyllä saavuttaa parempi tehokkuus, mutta suorituskyky heikkenee uusien resurssitarpeiden myötä.

Suorituskyvyttömän prosessin tunnusmerkkejä ovat mm:

• Lukuisten tarkistus- ja valvontavaiheiden olemassaolo.

• Tarpeettomien tai lisäarvoa tuottamattomien aktiviteettien olemassaolo.

• Lukuisten korjaavien toimenpiteiden olemassaolo.

• Jatkuvat ongelmat eri työvaiheiden yhteensovittamisessa.

Prosessin analysointiin kuuluu tyypillisesti kolme vaihetta: valmistautuminen, arviointi ja tulosten esittäminen. Kunkin vaiheen keskeiset periaatteet esitetään tarkemmin kohdissa 4.1.1-4.1.3.

4.1.1 Prosessianalysointiin valmistautuminen

Analysoinnin onnistuminen edellyttää sitoutumista, motivointia, luottamuksellisuutta, merkityksellisyyttä ja uskottavuutta.

Sitoutumisen tarkoituksena on varmistaa, että tarvittavat resurssit, aika ja henkilöstö ovat käytettävissä. Ylimmän johdon sitoutuminen on ensiarvoisen tärkeää, jotta konkreettiset parannukset prosessiin olisivat mahdollisia. Ilman ylimmän johdon sitoutumista alemmilla portailla on varsin vähän liikkumatilaa. Tehokkaalla projektinhallinnalla ja toiminnallisten osastojen välisellä yhteistyöllä voidaan suorituskykyä selvästi parantaa, mutta ilman ylimmän johdon sitoutumista muutosten teho on rajallinen. Johdon tulee omien tekojen avulla selkeästi viestittää tehokkuuden ja suorituskyvyn merkitystä. Viestin on levittävä ja tultava ymmärretyksi koko organisaation laajuisesti26.

Analyysin tulokseen vaikuttaa ratkaisevasti menetelmä, jolla arviointi suoritetaan, sekä johdon asenne arviointiin. Johdon tulisi motivoida osallistujia avoimeen ja rakentavaan arviointiin. Analyysin tulee kohdistua prosessien arviointiin, ei henkilöstön arviointiin.

Tarkoitus on kehittää prosessia paremmin tarpeita vastaavaksi, eikä syyllistää ketään.

Kartoituksen aikana tehdyistä havainnoista tulee antaa palautetta avoimen ilmapiirin ylläpitämiseksi ja laadukkaan lopputuloksen varmistamiseksi. Kartoituksessa saatuja tietoja tulee käsitellä luottamuksellisesti. Osallistujat tulee saada vakuuttuneiksi siitä,

26 Preston & Reinertsen. 1991. s. 242