SYSTEMS ENGINEERING IN FINLAND FINSE ry FINNISH ...

SYSTEMS ENGINEERING IN FINLANDFINSE ryFINNISH CHAPTER OF INCOSEMAY 2005www.finse.org

PUHEENJOHTAJALTAFINSE ry on yhdistys, jonka tavoitteena on tarjota jäsenilleen foorumiSystems Engineering aiheisen tiedon ja osaamisen levittämiseentoisilleen ja suomalaiseen yhteiskuntaan.Usein kysytään, että mitä Systems Engineering on? Yksiselitteisenvastauksen antaminen kysymykseen on vaikeaa. Mutta lyhyestitodettuna se on insinööritieteen laji, jolla tarkoitetaan järjestelmällistätoimintatapaa, jolla pyritään varmistumaan siitä, että järjestelmä taiyleisesti ottaen palvelu, jota ollaan tuottamassa vastaa sille asetettujavaatimuksia. Oleellista on ymmärtää, että suorituskykyisen järjestelmänkehittäminen edellyttää, että tiedetään mitä ollaan tekemässä, miksiollaan tekemässä ja missä toimintaympäristössä järjestelmää tullaankäyttämään. Systems Engineeringiä sovelletaan järjestelmienhankinta/toimitus- tai tuotekehitysprojekteissa projektinhallinnantyökaluna.Ylläolevan mukaisesti Systems Engineeringiä soveltavat yritykset,jotka tyyppillisesti integroivat järjestelmäratkaisuja tai näitä ratkaisujatilaavat yritykset.Systems Engineeringin avulla toimitettavasta järjestelmästä pyritään josuunnitteluvaiheessa tekemään läpinäkyvä siten, että sen toiminallisuusja suoritusparametrit tiedetään koko järjestelmän elinkaaren ajalle.Tällöin voidaan päästä tilaajan ja toimittajan kanssa pienemmälläriskillä sopimuksiin, joissa toimittaja ottaa vastuun järjestelmäntoiminnallisuudesta.Käsissäsi on nyt järjestyksessä kolmas Systems Engineering aiheinenjulkaisu, jonka FINSE on tehnyt. Tällä kertaa panostimme laajaanlevikkiin, jonka teki mahdolliseksi yhteydenotot ja keskustelutLogistiikkalehden päätoimittajan kanssa. Kiitän yhdistyksen puolestatästä mahdollisuudesta ja toivon, että lukijakunnassa herää kiinnostustaFINSE ry:tä kohtaan.Kiitän yhdistyksen jäsenten puolesta vuoden 2004 hallitustaerinomaisesta työstä, josta osoituksena INCOSE on myöntänytetukannessa olevan ”Bronze Circle Award” huomionosoituksen.Olet tervetullut sivuillemme www.finse.org ja ladata sieltä vaikkapaaikaisemmat julkaisut tai SE aiheisia esityksiä vuosien varrelta.Vesa Kainulainenpuheenjohtaja FINSE ry.hallitus@finse.orgSYSTEMS ENGINEERING KOULUTUS SUOMESSAEverstiluutnantti Pasi Pasivirtapasi.pasivirta@mil.fiJärjestelmähankkeiden kustannustehokas toteuttaminen nykyisessäglobalisoituvassa toimintaympäristössä edellyttää laaja-alaistahankkeen suunnitteluun ja toteuttamiseen liittyvää osaamista.Hankkeiden onnistuminen, ovatpa ne sitten luonteeltaan vaikkapainvestointihankkeita, suorituskyvyn kehittämisen hankkeita,julkishallinnon toimialan hankkeita tai puhtaasti yrityksenkilpailukyvyn parantamiseen tähtääviä hankkeita, muodostuu useinyrityksen tulevaisuuden kannalta kriittiseksi tekijäksi. Yhä useammattoimialat ja yritykset ovat vastanneet tähän haasteeseen ottamallakäyttöön Systems Engineering periaatteita soveltavan toimintamallin.Systems Engineeringin (suorituskyvyn hallinta) tarjoamatmahdollisuudet siis tunnistetaan ja niitä sovelletaan, mutta missä jamiten sitä opetetaan?Systems Engineering koulutustarjontaSuomessa on koulutusalalla useita toimijoita, joiden koulutustarjontaantutustuessa törmää termiin Systems Engineering. Tarjolla olevankoulutuksen laajuus vaihtelee muutamasta päivästä muutamiinopintoviikkoihin. Yhtään tutkintoon johtavaa koulutusohjelmaa eiSuomessa kuitenkaan kirjoittajan tietojen mukaan vielä ole.Koulutusohjelmien sisältö on hyvin vaihteleva ja termillä SystemsEngineering ymmärretään hyvin erilaisia asioita asiayhteydestä jatahosta riippuen. Suomalaista koulutustarjontaa tarkasteltaessa SystemsEngineering termi esiintyy yleisimmin ohjelmistoalaan liittyvänkoulutuksen yhteydessä. Muissa yhteyksissä asiaa sivutaansatunnaisesti.Systems Engineering termi liitetään usein osaksi vaatimusten hallintaavaikka itse asiassa vaatimusten hallinta on vain yksi, joskin erittäintärkeä, Systems Engineering prosessin osa-alue. Jossain yhteyksissäSystems Engineering mielletään osana tuotteen tai järjestelmäntuotetiedon ja/tai elinjakson hallintaa. Selkeä kokonaisvaltainenSystems Engineering lähestymistapa loistaa kuitenkin poissaolollaan.Voidaan tietysti väittää, ettei Suomessa tarvita omaa alaan liittyvääkoulutusohjelmaa, koska sellaisia on vapaasti tarjolla ulkomailla. Onkuitenkin perusteltua kysyä, että kuinka monella suomalaisellayrityksellä tai toimijalla on varaa taikka ylipäätänsä mahdollisuusinvestoida omiin työntekijöihinsä niin paljon, että työntekijöitälähetetään ulkomaille opiskelemaan vuoden mittaiselle kurssille. Omanhaasteensa muodostaa lisäsi tällaisten ulkomailla koulutettujentyöntekijöiden sitouttaminen organisaatioon.Ulkomailla asia on koettu tärkeäksi ja Systems Engineeringinkansainvälinen kattojärjestö INCOSE onkin listannut nettisivuilleen joyli 70 Systems Engineering tutkintoon tähtäävää koulutusta tarjoavaatahoa. Euroopastakin löytyy lukuisia yliopistoja ja vastaavia laitoksia,jotka tarjoavat mahdollisuutta jopa tohtoritasoisten opintojensuorittamiseen. FINSE ry:llä on kiinteä yhteys useaan alankansainväliseen toimijaan.Mitä osaamista tarvitaan ja miten sen voi hankkia?Systems Engineering toimintamallin perusfilosofia on, ettäymmärretään mitä ollaan tekemässä ja minkä takia. Toimintamallille onmyös luonteenomaista systemaattisuus sekä toiminnassa että toiminnandokumentoinnissa. Kaikki nämä ovat luonnollisesti tuttuja asioitamenestyville yrityksille. Mitä kaikkea sitten Systems Engineeringprosessia menestyksellisesti toteuttavan henkilön tulee osata?Perusfilosofian mukaisesti keskeisin osaaminen liittyy siihen, ettäymmärtää mitä ollaan tekemässä. Tämä edellyttää luonnollisestikyseiseen toimialaan liittyvää syvällistä osaamista, jota on hyvinvaikeaan hankkia ilman työskentelyä toimialalla ja sitä kautta hankittuakäytännön kokemusta. Kun henkilöllä on toimialaan liittyvät perusteethanskassa (teoria + käytäntö), niin toiminnan tavoitteellisuudenanalysointi huomattavasti helpompaa. Tällainen ajatusmalli johtaaluonnollisesti siihen päätelmään, että Systems Engineering koulutus eivoi olla luonteeltaan perusopintotasoista koulutusta. Miten voiharjoitella soveltamista jos ei tunne ympäristöä tai toimintamallia johonSystems Engineering toimintatapaa tulisi soveltaa. Tässä vaiheessakokeneet Systems Engineering ammattilaiset tietysti toteavat, ettäSystems Engineeringin soveltaminen ei edellytä syvällistä toimialaanliittyvää osaamista, riittää että ymmärtää Systems Engineeringprosessin perusteellisesti. Tämä on osaltaan totta, mutta kokeneilleSystems Engineering ammattilaisilla on taustallaan laaja kokemustaSystems Engineering periaatteiden soveltamisesta omalla toimialallaan.Tätä kokemusta on mahdollista soveltaa myös muiden toimialojenpiirissä - kunhan se kokemus on ensiksi hankittu.Toinen osaamisen keskeisistä kulmakivistä liittyy vaatimustenhallintaprosessiin.Vaatimustenhallintaprosessi ja itse vaatimustenymmärtäminen luo perusteet suorituskyvyn ja toimintaprosessienkehittämiselle. Vaatimuksista pitää ymmärtää niiden merkityksen(sisällön) lisäksi se, miten ne vaikuttavat kokonaisuuteen ja miten© FINSE ry 2005 - 2 -

vaatimuksiin kohdistuvien muutosten vaikutuksia voidaan arvioidakokonaisuuden kannalta. Ilman tätä ymmärrystä on mahdotontaarvioida esimerkiksi sitä, miten jostakin vaatimuksesta luopuminentarkoittaa. Vaatimustenhallintaprosessin työläin vaihe on jollain tavallakerätyn vaatimusmassan analysointi ja johdonmukainen jäsentely.Tähän on olemassa runsaasti julkisesti saatavilla olevaa ohjeistusta jaSuomesta löytyy jokunen alaan vihkiytynyt ammattilainenkin.Vaatimustenhallintaa on siis mahdollista kouluttaa ja senharjoitteleminen on helppoa vaikkakin työlästä.Kolmanneksi kulmakiveksi voidaan laskea epävarmuustekijöiden(riskit ja mahdollisuudet) hallintaan liittyvä osaaminen. Nykyinenglobalisoituva yhteiskunta elää jatkuvan muutoksen aikaa. Joillaintoimialoilla on mahdotonta tehdä luotettavia ennusteita edes kahdenvuoden päähän. Epävarmuustekijöihin on aina mahdollista varautua,mutta millainen varautumisen aste on taloudellisesti järkevää? Tällaisentoimintaympäristön ja sen tarjoamien mahdollisuuksien hallitseminenantaa yritykselle selkeän kilpailuedun. Tähän alaan liittyvää koulutustaon myös runsaasti tarjolla eri muodoissaan.Viimeiseksi joskaan ei vähäisimmäksi kulmakiveksi lasken hankkeenjohtamiseen ja projektinhallintaan liittyvän osaamisen. Projektinhallinnallaja Systems Engineeringillä on paljon yhteisiä piirteitä, muttapelkkä projektinhallinnan syvällinen osaaminen ei tee henkilöstä hyvääSystems Engineeriä. Projektinhallinnassa asioita tarkastellaan myösusein hieman suppeammasta näkökulmasta. Projektinhallintaan onolemassa paljon hyviä koulutusohjelmia ja hankkeiden johtamiseen onolemassa toimialakohtaisia koulutuspaketteja.Näiden edellä mainittujen kulmakivien lisäksi tarvitaan luonnollisestimyös liiketoimintaprosesseihin, tuotantoprosesseihin, laatu- jastandardisointitoimintaan, henkilöstöjohtamiseen, kansainväliseentoimintaan sekä moneen muuhun mainitsemattomaan alaan liittyvääosaamista. Tämän osaamisen tarpeellinen määrä ja kriittisyys riippuvatpitkälle toimialasta.Koulutusta Systems Engineeringin eri osa-alueilta on siis olemassa,mutta koulutuksen yhdistäminen mielekkääksi kokonaisuudeksi onvielä toteuttamatta. Systems Engineering prosessin kannalta onoleellista, että prosessia toteuttava henkilö osaa soveltaa kaikkea eriosa-alueisiin liittyvää osaamistaan kyseessä olevaan toimintakenttään.Tätä on mahdollista kouluttaa, mutta koulutuspaketti pitää suunnitellakokonaisuutena, siten että asiaa tarkastellaan Systems Engineeringsilmälasien läpi.Täytyy kuitenkin aina muistaa myös se, että pelkkä koulutus ei teekenestäkään mestaria, vaan aina pitää myös harjoitella asian tekemistäkäytännössä. Sen voi aloittaa esimerkiksi laatimalla aiheeseen liittyväntoteuttamissuunnitelman (Systems Engineering Management Plan).Tämän tyyppinen suunnitelma voidaan laatia vaikkapa opinnäytetyönmuotoon, jolloin koulutusohjelman tuloksia saadaan mitattua.Osaamisen ostaminenKuten jo aiemmin on tullut esille Systems Engineering alan todellisetammattilaiset kykenevät kehittämään yrityksen tai toimialan toimintaaja prosesseja vaikka heillä ei olekaan varsianista syvällistä kokemustakyseiseltä toimialalta. Joissain tapauksissa saattaakin olla perusteltuakääntyä tällaisia palveluja tarjoavan tahon (konsulttiyritykset) puoleen.Tällaisen palvelun ostaminen edellyttää kuitenkin omaa SystemsEngineering alaan liittyvää kokemusta, sillä miten voi järkevästi ostaajotakin sellaista, mistä ei ymmärrä mitään (en yritä väittää etteikö näintapahtuisi). Täten oman henkilöstön alaan liittyvä kouluttaminen tuleekaikille omasta kilpailukyvystään kiinnostuneille tahoille vastaanennemmin tai myöhemmin.YhteenvetoSystems Engineering alaan liittyvälle, suomalaiselle koulutusohjelmalleon olemassa selkeä tilaus. Systems Engineering osaamisen merkitysosana kilpailukyvyn kehittämistä kasvaa jatkuvasti. Kaikissa viimeaikoina Suomessa järjestetyissä Systems Engineering seminaareissa jatapahtumissa on tullut esille alaan liittyvän koulutustarjonnan puute.Tätä puutetta on tullut paikkaamaan muutamia lyhytkurssityyppisiäkoulutuspalveluita tarjoavia ulkomaalaisia Systems Engineering alantoimijoita. Eli bisnestä on todistettavasti olemassa. Nyt onkinmielenkiintoista seurata, kuka suomalaisista koulutusalan toimijoistatarttuu asiaan ensimmäisenä.Noin neljännes FINSE ry:n jäsenistöstä tulee tiedeyhteisön piiristä.FINSE ry onkin ottanut vuoden 2005 toiminnan keskeiseksi tavoitteeksiyhteistyön kehittämisen tiedeyhteisön kanssa. Sopii vain toivoa, ettätämä johtaa käytännössä siihen, että Suomeen saadaan aikaiseksiSystems Engineering tutkintoon johtava koulutusohjelma.Kirjoittaja on entinen FINSE ry:n puheenjohtaja ja hän työskenteleetällä hetkellä pitkän aikavälin kehittämisen erikoisasiantuntijana jakoordinaattorina Euroopan Unionin Puolustusvirastossa Brysselissä.VAATIMUSTEN MUUTOSTENHALLINTAPekka Mäkinen, SoftQApekka.makinen@softqa.fiwww.softqa.fiOngelmaMuutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää.Projektien alkaessa ensimmäiset vaatimukset kootaan jadokumentoidaan, mutta usein vaatimuksia ei ylläpidetä projektienaikana – lopputulemana on, että projektin tulos javaatimusdokumentaatio eivät vastaa toisiaan. Muutoksiin myös ainaliittyy kustannuksia, jotka saattavat olla yllättävänkin suuria.Vaatimukset muuttuvat kaikissa projekteissa ja hankkeissa. Useinvaatimukset pyritään jäädyttämään jossakin projektin vaiheessa, jonkajälkeen vaatimuksiin ei enää sallita muutoksia. Pyrkimys on hyvä,mutta käytännön elämässä usein vaatimukset muuttuvat projektinpäättymiseen ja tuotteen tai palvelun käyttöönottoon saakka ja jopatämän jälkeenkin. Vaatimusten lisääntyminen ja muuttuminen johtuumonista syistä, esimerkiksi mikä tahansa kehityshanke on aina jäljessäkäyttäjien tarpeista maailman muuttuessa (kuva 1).ToiminnallisuusVaatimusten keruu on aina2. vaiheeniteratiivinen prosessi,toiminnalli-Käyttäjien tarpeetsuusvaje lähdettäessä kehittämäänkasvavat ajan myötäuutta lähtökohtana onjokin toiminnallinen tarve,joka johtaa syventäviinkäyttäjätason vaatimuksiin.1. vaiheentoiminnallisuusvajeVaatimusten keruun aikanasyntyy uusia vaatimuksia,jotka taas tuottavatvaatimuksia eri tasoille,Aikaesimerkiksi käyttäjävaati-1. vaiheen1. vaiheen2. vaiheen2. vaiheenvaatimuksettuotevaatimuksettuotemuksista johtuu systeemivaatimuksia.Kuva 1. Toteutus jää jälkeen muuttuvista tarpeistaOlennaista muuttuvien vaatimusten kanssa toimimiseksi ja hyvändokumentaation turvaamiseksi on selkeä ja toteutettavissa olevamuutostenhallinta.Kytkennät vaatimustenhallintaanHankkeen alussa vaatimuksia kerätään, niitä tuotetaan aktiivisesti jaolemassa olevat muuttuvat useasti. Tämän vaiheen jälkeen pääosavaatimuksista on kerätty ja vaatimuskokonaisuuden pohjalta pystyytoteuttamaan alkuperäisen toiminnallisen tarpeen. Muutostenhallinta© FINSE ry 2005 - 3 -

astuu kuvaan tämän kuohuntavaiheen jälkeen, koska tällöin usein jolähdetään toteuttamaan vaatimuksia, esimerkiksi toteuttamallaprototyyppejä. Usein vaatimustenhallinnan prosessi rakennetaankaksivaiheiseksi juuri muutoshallinnan johdosta: hankkeen alunkuohuntavaiheelle prosessi asettaa vähemmän vaatimuksia.Jotta vaatimusten muutostarpeita kyetään seuraamaan täytyyvaatimustenhallinnan toiminnoissa olla vaatimuksen tilan seuranta sekäjäljitettävyys vaatimusten ja suunnittelutietojen välillä. Eri tasojenvaatimuksiin, suunnittelutietoihin sekä testaussuunnitelmiinjäljitettävyys on välttämätöntä, jotta pystytään arvioimaan mahdollisenmuutoksen vaikutuksia ja kustannuksia.Vaatimusten muutostenhallinnan prosessiYksittäisten vaatimusten pitää olla selkeitä, toteutettavissa olevia,niiden tilaa pitää seurata ja niiden toteutuksen pitää ollatodennettavissa. Jotta nämä asiat toteutuisivat myös vaatimustenmuuttuessa, pitää hyvän muutostenhallinnan prosessin toteuttaaseuraavia vaiheita:- muutostarpeet esitetään dokumentoidusti muutosehdotuksina- muutosehdotukset pitää arvioida niiden tarpeellisuuden,kustannuksien ja aikatauluvaikutuksien osalta- pitää tehdä päätös muutosehdotuksen toteuttamisesta taihylkäämisestä- jos muutos päätetään toteuttaa, pitää tämä tieto saada viestittyätoteutusta tekeville henkilöille- muutos pitää dokumentoida- ja lopuksi päätetty muutos pitää myös toteuttaa ja varmistaatoteutusSe miten nämä vaiheet toteutetaan on kiinni toteuttavastaorganisaatiosta, projektista sekä laatutavoitteista. Näiden vaiheidentoteutukseen on monia vaihtoehtoisia tapoja, voidaan edetä jokokevyellä menettelyllä tai raskaalla byrokratialla. Muutoshallinnanprosessin suunnittelussa pitää huomioida, että toiminta täytyy ainasopeuttaa nykykäytäntöön, eikä tavoitella liian korkealle. Prosessiavoidaan tukea käyttämällä ohjelmistotyökaluja tai tuottamalla valmiitadokumenttipohjia, jolloin aina käsitellään määrämuotoisiadokumentteja.Päätös muutoksen tarpeellisuudesta edellyttää tietoa mitä hyötyä taihaittaa ehdotetusta muutoksesta on, tätä varten päätöksen tekijän pitääsaada tietoonsa mikä muu muuttuisi toteutetun muutoksen johdosta.Tätä kutsutaan muutoksen vaikuttavuusanalyysiksi - varsinkinvaatimusten muutosten osalta näennäisesti pienelläkin muutoksellasaattaa olla hyvinkin suuri vaikutus toteutukseen ja kustannuksiin.Päätöksen tekemiseen muutosehdotuksesta on useita vaihtoehtoja,lähtien jonkun yksittäisen projektihenkilön vastuusta tarkistaamuutosehdotukset. Muodollisempi tapa hallinnoida muutosehdotuksiaon käydä ehdotukset lävitse erillisessä muutostenhallintaryhmässä.Vaikuttavuusanalyysissä pitää myös huomioida, että tehdyillämuutoksilla on erilaisia kustannuksia eri vaiheissa projektia. Kunhankkeen alkuvaiheissa tehdään muutoksia vain dokumentaatioon, ovatkustannukset pieniä. Toisaalta jos on jo edetty toteutusvaiheeseen,nousevat vaatimusten muutosten aiheuttamat kustannukset rajusti.MuutostyypitMuutostyyppejä voidaan luetella kolme erilaista: lisäys, muutosolevassa olevaan sekä poisto. Avuksi päätökseen muutosehdotuksestavoidaan käyttää tarkistuslistoja, joissa on esimerkiksi kysymyksiä:Uuden vaatimuksen lisäys- Onko selvitetty miksi lisäys on tarpeellinen?- Onko lisäys hankkeen vision rajaamalla alueella?- Kuinka paljon tämä vaikuttaa kustannuksiin / aikatauluun?Muutos olevassa olevaan vaatimukseen- Miksi selvitetty miksi muutos pitää tehdä?- Kuinka paljon tämä vaikuttaa kustannuksiin / aikatauluun?- Onko muutos tarpeellinen?- Onko joku muu vaatimus liittynyt tähän?- Vaikuttaako muutos joihinkin muiden vaatimusten toteutukseen?Vaatimuksen poisto tai siirto myöhempään toteutusvaiheeseen- Onko selvitetty miksi vaatimus pitää poistaa?- Onko joku muu vaatimus liittynyt tähän?- Vaikuttaako muutos joihinkin muiden vaatimusten toteutukseen?Yhteys yleiseen muutostenhallintaanVaatimusten muutos voi olla tietyn muutosprosessin alkupiste tai se voiolla seurausta jostakin muusta muutostarpeesta, esimerkiksivirheellisesti toteutetun toiminnon korjaamisesta. Muutoksentoteuttaminen ei myöskään koskaan lopu mahdolliseen vaatimuksenmuuttamiseen, vaan tämän jälkeen alkaa muutoksen tiedottaminen,toteuttaminen sekä seuranta (esim. uudelleentestaus).Vaatimusten muutostenhallinta voi siis olla osa suurempaamuutostenhallinnan kokonaisuutta (kuva 2). Jokaisen muutostarpeenosalta pitää arvioida, vaikuttaako muutos vaatimuksiin, vai kutenyleensä, myös lisäksi johonkin muuhun osaan prosessia.MuutostenhallintaMuutosehdotuksenarviointiVaatimustenhallintaMuutoksentoteutus jadokumentointiMuutoksentestaus jadokumentointiKuva 2.Vaatimusten muutokset osana yleistä muutostenhallintaaMuutostenhallinnan mittareitaOnnistuneeseen muutostenhallintaan kuuluu myös prosessin seurantamittareilla. Muutosehdotuksella on muutostenhallintaprosessin aikanaeri tiloja: se on esimerkiksi joko uusi, katselmoitavana, hyväksytty,siirretty tulevaisuuteen tai hylätty (kuva 3).UusiKatselmoitavanaHylätty Hyväksytty SiirrettyToteutettuTestattuSuljettuKuva 3.Esimerkki muutosehdotuksen eri tiloistaVaatimusten muutostenhallinnan osalta mahdollisia mittareita ovatesimerkiksi:- tehtyjen muutosehdotusten määrä kokonaisuudessaan taivaihekohtaisesti- eri tiloissa olevien muutosehdotusten osuudet- muutostiheys yksittäisissä vaatimuksissa- eri muutostyyppien osuudet- vaatimusten muutoshallintaan käytetty aika tai työMittareita voidaan hyödyntää projektien seurannassa: hankkeenedetessä pitäisi toteuttamatta tai muuten avoinna olevienmuutosehdotusten määrä laskea, tai muuten vaatimukset eivät oleoikeasti koskaan asettumassa stabiileiksi. Samoin jos yksittäisiin© FINSE ry 2005 - 4 -

vaatimuksiin tai alueisiin kohdistuu useita peräkkäisiämuutosehdotuksia, on näiden vaatimusten oikeellisuus tarkistettava.YhteenvetoJos vaatimukset ovat dokumentoituja, kannattaa dokumentaatiota myösylläpitää. Muutosten pitää heijastua sekä toteutukseen ettädokumentaatioon. Tapa jolla tähän päästään on suunnitella tarvittavanlaatutason täyttävä muutostenhallintaprosessi, joka minimissään ainakinhuolehtii siitä, että myös vaatimusdokumentaatio vastaa lopullistatoteutunutta hankkeen tulosta. Muutoksia vaatimuksiin on helppoehdottaa, mutta hyvä prosessi myös takaa sen, että muutoksenaiheuttamat kustannukset tulevat näkyviin.MAKING THE MOST OF MODERN PROCUREMENTJohn Thompson, CEO Commerce Decisions Ltdjohn.thompson@commercedecisions.comThe potential of strategic procurement projects to materially impact thefinancial performance of a business is well understood by most FinanceDirectors. An organisation’s most expensive purchases, whether ITsystems, outsourcing agreements, or investments in infrastructure, willbe subject to intense scrutiny prior to the commitment of budget.In order to secure the FD’s signature, the project team will agree a returnon investment objective and justify this in a business case. Giventhe execution risk involved, the return on investment the project teamwill promise will be many times the return achievable at the bank.Sadly many FD’s have become used to broken promises. The StandishGroup’s landmark CHAOS report identified that, for software relatedprojects, only 9% of projects commissioned by large companies weresuccessful. Further, 52% of projects exceeded their budgeted costs by atleast 189% of the original estimates, and 31% of projects had to becancelled before delivering any benefits. Finance Directors commisioingpurchases of construction projects, outsourcing and infrastructureare often subjected to similar delays and disappointments.Such disappointments have a material impact on the bottom line. Forexample imagine a company commits to a £50m programme of highvalue purchases of infrastructure and outsourced processes. Each projectin this programme averages £10m in value, takes one year to deploybefore it starts delivering benefit, and then has a return on investmentobjective to breakeven in a further two years and then deliverbenefits at the same rate over 10 years. The £10m investment oncesuccessfully deployed will therefore return £5m per annum. If eachproject, on average, suffers a one year delay in going live and thendelivers benefit at half of the anticipated rate, the benefit for eachproject would be 9 years x £2.5m or £22.5m vs 10 x £5m or £50m if theoriginal ROI and time-scale was achieved. Across the £50m investmentprogramme the cost over ten years of the projects failing to liveup to their original promises would be £275m. Clearly any systematicimprovement in the delivery of major procurements will leverage significantbenefits to the company’s results.It is therefore in the Finance Director’s interests to understand some ofthe principal reasons for the failure of procurement projects, and challengethe project team about these issues ahead of the commitment ofbudget. Clearly the Finance Director cannot be an expert on the technicalrisks involved in the diversity of major procurements, but researchand experience shows that many of the reasons for failure are not technicalbut relate to issues of business process. Some of these issues aresurprisingly simple. Two issues which the author has seen contributerepeatedly to the failure of procurement projects as discussed below.They have both been highlighted by the UK National Audit Office ascommon reasons for the failure of acquisition projects.Lack of effective engagement with stakeholdersAny significant project will have diverse stakeholders. These includeend-users, budget holders, and staff on related projects. The stakeholderswill often be geographically dispersed. Individuals will bequalified to pass judgement on widely different issues, and will be extremelybusy with their day jobs. The opinions and knowledge theyhave is relevant throughout the procurement process. They are neededto state and review requirements, review and score responses frombidders, analyse the value of competing approaches and identify theimportant issues during negotiations. Getting the right people engagedat the right times is very hard, especially when many of thestakeholders do not report to the project manager. The project managerwill often have make decisions without all the inputs to move the projectforward. This can have two painful consequences.Firstly key knowledge may be missed. An approach which a stakeholderknew for fact would not work could end up have significantfunds committed to it, simply because the relevant fact did not becomeknown to the project manager until the problem presented itself in thepurchased product or system. The costs of fixing issues at thespecification or proposal stages are many times less than fixing themafter deployment, so deploying expertise at these early stages isessential. Secondly, even if no mistakes are made by not deploying thestakeholders’ expertise, a lack of consultation can create a lack of buyingto the objectives and approach of the project. This can result inresistance to or even rejection of the project’s results and hence damagingROI for purely political reasons.So how can stakeholder engagement be improved? The good news isthat modern technology can help dramatically. eSourcing has broughtthe process of creating requirements, issuing these to potential bidders,capturing responses and negotiating the best possible deal into an onlinecollaborative environment, where stakeholders can participate inthe appropriate aspects of the procurement from their own desks.However until recently eSourcing technology has only been matureenough to support commodity purchases. However more recently a newgeneration of eSourcing solutions has come to market which can copewith the diversity of stakeholder roles and interactions needed duringthe requirements, proposal evaluation and negotiation stages of majorprocurement projects. Our own product AWARD is an example of sucha system; it has been successfully used to enhance stakeholder collaborationon procurement projects worth £16bn.Evaluation of proposals is driven by initial price rather thanlong-term value for moneyIt is easy to measure price in a proposal, and easy to negotiate priceswith suppliers, and measure the improvement. In reality value, ratherthan price, often has a bigger impact on return on investment. With our£10m procurement project detailed above, a 10% improvement in pricewould deliver savings of £1m. A 10% increase in the value of theprocurement would amount to £0.5m a year over 10 years or £5m.Suppliers are often more sensitive to the price than the value of whatthey are delivering. Negotiation of value, as well as being more importantcan therefore also be a fertile ground for extracting concessionsfrom suppliers. Evaluating and negotiating value is neglected because itis difficult. However best practice is emerging for this importantdiscipline.In order to make decisions based on value for money what is meant by'value' in the context of the particular project must be understood. Thevalue of a missile will be measured in quite different terms to the valueof an IT outsourcing project.Recent developments in best practice have emphasised the importanceof having a preplanned and transparent model of value for money. Avalue for money model includes a number of key concepts. These arecriteria, weightings, and measurement schemes.© FINSE ry 2005 - 5 -

Criteria describe the key success factors that must be measured. Criterianeed to be organised into a hierarchy, as it is nearly impossible to determinethe completeness, consistency or relative importance of a flatlist of criteria.A hierarchy of criteria allows scores to be entered at the leaves of thecriteria tree where it is possible to make objective assessments, forexample, on the fuel economy of a car, or the security of an IT system.Not all criteria are created equal. They differ in relative importance.Mathematically rigorous techniques such as refined pairwise comparisoncan be used to determine a set of weightings based on responsesfrom the project's stakeholders.Once weightings have been determined, a measurement scheme mustbe determined for measuring each criterion. The actual score (forexample, fuel consumption in mpg) needs to be mapped on to anormalised scale (for example, 0-100) so comparisons of dissimilarcriteria and an overall assessment of value for competing proposals canbe made.Once again the process of evaluating and negotiating value, which isoften attempted using rudimentary home grown spreadsheets, can bemade dramatically easier using modern purpose built sourcing solutionssuch as AWARD.SummaryThe performance of an organisation’s most significant procurementprojects materially impacts its financial results. Two establishedreasons for underperformance of these projects are a lack of stakeholderinvolvement, and the failure to evaluate and negotiate value as well asprice. Modern best practice methods and webbased sourcing technologycan address these issues and secure enhanced value for money forstrategy procurements.John Thompson is CEO and co-founder of Commerce Decisions Ltd.Commerce Decisions' AWARD software has supported private andpublic-sector procurement projects worth over £16 billion, including£4 billion of PFI in the defence, education and leisure sectors. Contactin Nordic is Hannu Snellman; hannu.snellman@middleware.fiMore: www.commercedecisions.comCHANGE MANAGEMENT, TEAM COLLABORATION& PROJECT VISIBILITY ACROSS THEDEVELOPMENT LIFECYCLEDominic Tavassoli, Director of Product Marketingdominic.tavassoli@telelogic.comExecutive SummaryLifecycle Change Management solutions can help solve some of themost critical challenges organizations have today, by enabling completeimpact assessment of a change, providing the project team with « asingle version of the truth », and enhancing visibility and predictabilityfor project management. Telelogic has recently introduced its LifecycleChange Management solution addressing these challenges.Lifecycle Change ManagementChallenges that organizations are up against include:- The increasing criticality of software, both safety-critical andbusiness-critical,- The increasing complexity of software and systems, technologicallyand organizationally,- The increasing objectives & pressure (cost, schedule, quality,content, regulations)Meeting these challenges is driving the need for Automated LifecycleManagement (ALM) solutions, following the near- Darwinian evolutionof competitive business survival.These high-level challenges lead to many individual issues:- “We’re customer-focused, but it’s hard to keep track of customerfeedback and relate it to our activities!”- “How can we be Agile when it’s so hard to manage change acrossthe organization – so many stakeholders, so much paperwork?”- “Changes to our requirements are critical –how do view the impact?Has development already started working on this?”- “How can I ensure my requirements are clearly transmitted to thedevelopment team?"- “Our Managers either can’t see what’s going on, or are drowning indetails!”Leading IT market research and advisory firm IDC confirmed thatwhile change request tracking is an important issue, managing changingrequirements and specifications is critical for organizations (IDC 2004Executive Brief: “Improving Collaboration and Visibility in the SoftwareDevelopment Process”).“Integrated ALM solutions that combine strong process and changemanagement capabilities with the visibility and collaboration affordedby dashboards are the foundation for organizations seeking tangibledevelopment process improvement. Companies that successfully implementthese solutions will benefit from fewer surprises, improvedteam collaboration, shorter time-to-market, and higher-quality products,”wrote Melissa Webster, research director, application lifecyclemanagement at IDC.Lifecycle Change Management is the integrated solution addressingthese issues.Capturing “the Voice of the Customer”Lifecycle Change Management allows organizations to capture “thevoice of the customer”, requests that are too often lost, badly processed,untraceable. It provides a highly accessible, consistent, repeatable processfor preliminary requirement capture and analysis by all relevantstakeholders. Requests are easily captured through personalized Webforms. The review process identifies requirements that are traceableback to the initial customer enhancement requests, while change requestsare processed accordingly.This captures the original “voice” of the customer as well as the “sparkof innovation” from internal teams. As teams follow the standard approvedprocess to ensure efficient analysis, organizations avoid lostrequests or communication breakdowns. This first component of LifecycleChange Management builds the traceability that finally makes“customer-focus” a reality.Managing Change across the LifecycleAll projects are subject to change, a frequent source of errors and rework.Teams need to record and manage change impacting all projectartifacts (beyond just source code), involving an increasing number ofcontributors or stakeholders. Lifecycle Change Management enables acentral, consistent, repeatable change process across systems and softwareprojects, encompassing all areas of engineering.As above, organizations that follow a Web-enabled standard approvedprocess ensure efficient analysis, avoiding lost requests or communicationbreakdowns.This consistent and integrated approach is crucial when change impactsthe agreed baseline of requirements and specifications (the foundationof the project), implying a scalable and flexible change process. Re-© FINSE ry 2005 - 6 -

quirement change control must be user-friendly, provide easy crossdomainvisibility to the Change Control Board, and enable immediatecommunication of change decisions.Lifecycle Change Management brings change management to the analystswho are in charge of requirements and specifications, and providesa flexible, consistent and repeatable process for managingchanges of the requirements base. The preferred approach is to allowanalysts to simply indicate what requirement change request they areworking on, so all changes submitted are automatically tracked, packagedand linked to it. The review and approval team can then be notifiedof the proposed change, participate from across the organizationvia the Web and view the status of specifications and changes.Lifecycle Dashboards are a new, intuitive approach to improve managementvisibility and predictability.Bringing it all togetherLifecycle Change Management brings together all these processes, in aready-to-use, integrated, efficient solution. This enables unique impactanalysis capabilities, analysts can check if development is already underway before taking any change or implementation decisions. Theycan also check to see how important the impacted feature is for thecustomer. Reporting the potential effects of change is a key initiative ofSarbanes-Oxley compliance.Before starting work on a change, a developer is aware of the importanceof a request and can see the big picture and is notified of anypending change. As the process records discussions and decisions, itautomatically builds an organization knowledgebase that is invaluablefor future reference.Lifecycle Change Management facilitates controlled response tochange, rapidly, efficiently and with reduced risk.The Competitive EdgeFigure 1. Managing Change and its impact to requirementsEfficient ImplementationAnother critical issue is that development activities are too often poorlyrelated to the original requirements, let alone change management decisions.Developers might not be working on the latest version of thespecifications and often have poor visibility of context and businessvalue. This may lead to unnecessary, unfocused development andcostly rework.Lifecycle Change Management enables control of the implementationof changes, with an efficient requirements-driven development process,tracing each development task and impacted object to an original customerneed or change request. An analyst can create implementationrequests from requirements or specification elements. The implementationtasks appear in the development teams’ to-do list, displaying keyattributes (priority, deadline…) and business data. Automatic establishmentand real-time visibility of the relationships between requirementsand related development activities helps project managersstreamline development and monitor project progress, making surethey’re “doing the right thing” (cf. DO178B requirement to code traceability).When combined with Configuration Management, they canview the actual business features delivered by each release or baseline.Clearly defined and communicated requirements improve the focus ofsoftware developers, thereby reducing rework and improving productivity.Lifecycle Change Management helps organizations align developmentactivities with customer needs & business objectives (cf. Sarbanes-Oxley),around “a single version of the truth”.Improving visibility and predictabilityProject progress is hard to control without an overview. LifecycleChange Management solutions should include Dashboards, whichautomatically collect and analyze Lifecycle data and produce reportingon metrics and trends. Web-based display and navigation facilitatemanagement decisions, helping project managers be more efficient,producing accurate estimates and make faster and better informed managementdecisions.Some of the major benefits of the Lifecycle Management are:- Increased customer satisfaction, by capturing all enhancement requests& issues, and ensuring they are acted upon;- Improved predictability, by providing an integrated view of projectphases and activities involved, and early impact analysis;- Reduced development costs, minimized delays and improvedquality, by consistently managing change across all projectartifacts, ensuring implementation is continuously aligned with thelatest requirements, and accelerating issue identification;- Providing the means to reach higher levels of process maturity(CMMI, SPICE, ISO 9000) and meet corporate governanceregulations (Sarbanes-Oxley), by providing automated visibility,support and repeatable procedures in key process areas andintroducing lifecycle change assessment, control and reporting.These benefits provide organizations with a clear competitive edge andequip them with a process framework that can help them address tomorrow’schallenges.Lifecycle Change Management and TelelogicTelelogic’s Lifecycle Change Management solution introduces new andextended capabilities to manage change and provide visibility throughoutthe product, systems or software development lifecycle. It is builtfrom individually highly successful components: Telelogic SYNERGYis the industry’s award-winning Change Management solution, andTelelogic DOORS is the world’s leading Requirements Managementsolution. It also includes the new Telelogic Dashboard, for projectmanagement visibility and enhanced lifecycle processes to that keep theproject teams in step.It brings the following unique benefits to development organizationsand their enterprises:- Complete impact assessment of a change, enabling and recordingcomplete impact analysis of a change request before any implementationdecision is made.- ‘A single version of the truth’, synchronizing of all the project teammembers with the latest change management decisions.- Better visibility and predictability for management, providing managementwith visibility of project performance against key businessobjectives, based on the latest data extracted from the change managementrepository.For more information, please visit www.telelogic.com© FINSE ry 2005 - 7 -

© FINSE ry 2005 - 8 -