CxO Mentor Oy

(1)

CxO Mentor Oy

Onnistunut

tietojärjestelmäprojekti

6.9.2011

(2)

P R O J E K T I V U O T O

PRO J E K T I VUOTO

(3)

Mitä yhteistä?

1.Inhimilliset tekijät,

viestintä 2.Kokemat-

tomuus

3.Master Data 4.Tekniset

ongelmat

(4)

(5)

9:15 - 9:45

Keynote: Projektiviestintä Kai Ruuska

9:45-10:15

Tietojärjestelmäprojektin onnistumisen Reino Myllymäki

varmistaminen - käytännön työkaluja Joonas Iivonen

10:15 - 10:45

Perustiedon merkitys ERP-projektissa Timo Seppänen

10:45 - 11:15 Kahvitauko

11:15 - 11:45

Keynote: Onnistuvan projektin tunnusmerkit Yrjö Benson 11:45 - 12:00

Päätössanat Toni Hinkka

(6)

TOIMITUSJOHTAJA KAI RUUSKA

Project Directors Oy

(7)

Project Directors Oy

Prodictor

Projektiviestintä

Kai Ruuska www.prodictor.fi

Onnistunut tietojärjestelmäprojekti

Ajankohtaisseminaari Finladiatalolla 6.9.2011

Communicare

(8)

Niin vai näin

Helsingin Sanomat 14.6.2008

Teknillisen korkeakoulun

tietoverkkotekniikan professorin Jukka Mannerin mukaan

tietojärjestelmien rakentaminen ei poikkea perustavasti talon rakentamisesta. Taloja on rakennettu kauemmin, joten niihin tarvittavat materiaalit ja työvoima ovat helpommin

arvioitavissa. Silti taloihinkin tulee virheitä.

Meillä ei ole IT-projekteja. Meillä on liiketoimintaprojekteja, joissa IT on mukana. Nostan mielelläni IT:hen mukaan sen C:n, koska se nousee usein tärkeimmäksi.

Monesti tuntuu, että

perusammattitaito pitäisi olla kommunikointi. IT-osastolla on usein vaikeuksia puhua samoista asioista samoilla nimillä edes keskenään.

VR:n CIO Sirpa Creutz TiVissä 30.4.2009

(9)

Projekti pitää nähdä lopputulostaan laajemmin

Loppu- tulos

Projektin rajaus Käyttäjätyytyväisyys

Operatiivinen toiminta Strategiset päämäärät

Viestintä ampuu tyhjiin, jos kohderyhmän odotuksia ei oteta huomioon.

Haluttu muutos

Lopputuloksen tuottamat

hyödyt

Lopputuloksen ominaisuudet Lopputuloksen

merkitys organisaatiolle

Lopputuloksen sisältö

(10)

Strategia ja perusoletukset

Operatiivinen

toiminta Tuotokset

Inkrementaalinen muutos Sopeuttaminen

Innovointi

Radikaali muutos Kyseenalaistaminen

- onko nykyinen tapamme toimia oikea - onko tehokkuus todella ainoa ongelma - onko SAP sittenkään ratkaisu

- entä, jos olemmekin erilaisia kuin muut

Muutosprosessi ja organisaation oppiminen

Puutteiden korjaaminen - se, mitä teemme on ok

- nyt vain nopeammin ja halvemmalla - SAP toimii muualla

- olemme samanlaisia kuin muut - miksei SAP siis toimisi meilläkin

Projekti on tapa sopeutua muutoksiin ja väline aikaansaada niitä.

OK

(11)

Projektiviestinnän kaksoisrooli

Mainstream project

Newstream project

Inkrementaalinen muutos

Entinen Kehittä-

minen

Entinen Kehittä-

minen

Radikaali muutos Sopeuttava projekti

- parannetaan olemassa olevaa - riskit parametrisia (input)

- vaatimusmäärittely - miten asiat ovat - learning and doing

Innovatiivinen projekti - tehdään jotain uutta

- riskit rakenteellisia (output) - asiakkaan odotukset

- miten asiat voisivat olla - learning by doing

Integroiva viestintä - nykytilaa säilyttävää - asioiden kertomista - näkyvä tieto

- jatkuvuuden tunne - tietoisuus kontrollista

Dialoginen viestintä

- nykytilaa kyseenalaistavaa - asioiden tulkintaa

- henkilökohtainen tieto - moniäänistä ideointia

- sallii poikkeavat näkemykset

Mitä radikaalimpi muutos, sitä enemmän viestintään kannattaa panostaa.

(12)

Projektin ja asiakkaan välinen suhde

Projektin tulisi olla aloitteellinen palvelun tuottaja eikä passiivinen toteuttaja.

Working

Formaali viestintä

Networking

Viestintäfoorumit

(13)

Projektin viralliset viestintäkanavat

Ohjausryhmän kokoukset Projektipalaverit

Suunnitteluistunnot

Dokumentit ja suunnitelmat Koulutusmateriaalit

Käyttöohjeet

Tilannekatsaukset Muistiot

Projektitiedotteet

Tiedotustilaisuudet Tietoiskut

Koulutustilaisuudet

Asiakaslehdet Uutiskirjeet

Henkilöstötiedotteet

Muulla viestinnällä ei ole merkitystä, ellei perusviestintä ole kunnossa.

Sähköposti Intranet

Sähköinen projektikansio

(14)

Viestintäfoorumit

 Mitä foorumeilla tapahtuu

- foorumi on avoin paikka, jossa ihmiset kohtaavat ja tapaavat muita ihmisiä - puhutaan tärkeistä ja vähemmän tärkeistäkin asioista (sosiaalinen viestintä) - tieto vaihtuu, syntyy uutta ja luovia ratkaisuja (tavoitteellinen dialogi)

 Fyysiset foorumit

- projektin työtilat

- henkilökohtaiset lähiverkot (yhteinen nimittäjä  esim. sählyporukka) - puoliviralliset kohtaamiset (käytäväkeskustelut, kahvittelut,…)

- viralliset tapaamiset (projektipalaverit, infotilaisuudet,…)

 Virtuaalifoorumit

- verkkopohjaiset työskentely-ympäristöt - sosiaalinen media

- intra, sähköposti, tekstarit

Ilman spontaania asiantuntijaviestintää projektin tehtävien hoitaminen ei onnistu.

(15)

Kanava

Lähettäjä Sanoma Vastaanottaja

Palaute Häiriöt

Prosessimalli dominoi edelleen projektiviestintää

Viestintä on paljon muutakin kuin informaation välittämistä A:lta B:lle.

A B

Viestinnän teorioiden kehittyminen:

- Matemaattinen informaatioteoria  pack and deliver (lääkeruiskumalli)

- Merkityksenantoteoriat ja semioottiset mallit  sense making (otetaan tolkkua)

- Yhteisöllistäminen ja rituaalimallit  me-henki ja yhdessä oppiminen (tiimin koheesio)

(16)

Lähettäjäkeskeisen viestinnän kömmähdyksiä

Sanoman tulkinnan määrää vastaanottaja eikä lähettäjä.

Electrolux:

”Nothing sucks like Electrolux”

(huumori on taitolaji)

Nokia 5110:

”Jedem das Seine”

(teksti Buchenwaldin keskitysleirin rautaovessa)

General Motors:

”Chevrolet Chevy Nova”

(esp. no va = ei kulje)

(17)

Viestinnän jäävuorimetafora

Tilannetekijät

Soveltaen Väliverronen, Åberg 2006

Sanomien vaihdannan taso - ”sanakirjamääritelmä”

- merkin ja kohteen suhde - lähettäjäkeskeinen

Yksilöllisen tulkinnan taso - subjektiivinen sivumerkitys - merkin ja käyttäjän suhde - vastaanottajakeskeinen

Yhteisöllisen tulkinnan taso - intersubjektiivinen sivumerkitys - merkin ja kulttuurin suhde - kontekstikeskeinen

Äitiys suomalaisessa yhteiskunnassa Oma äiti

Äiti = nainen, joka on synnyttänyt lapsen

Sanakirjamääritelmän tarkentaminen ei välttämättä paranna viestinnän tehokkuutta.

Näkyvä tieto

Hiljainen tieto

(18)

Hiljainen tieto – tacit knowledge

Hiljainen tieto siirtyy ihmiseltä toiselle vain yhdessä tekemällä.

1. Matsushitan Home Bakery -leipäkone tuli markkinoille 1987

2. Edeltänyt pilottiversio paistoi reseptin mukaan, mutta tulos oli kehno 3. Tuotekehitysponnistuksista huolimatta leivästä ei saatu kelvollista 4. Osakan kansainvälinen hotelli oli tunnettu hyvästä leivästään

5. Projektista lähetettiin insinööri hotellille mestarileipurin oppiin

6. Avainasiaksi paljastui taikinan vaivaamistekniikka

(19)

Viestintä on vuorovaikutustilanne eikä tapahtuma

Viestintä alkaa, kun osapuolet haluavat ymmärtää toisiaan.

”Sellaista perinteistä saksalaista autoa…”

Idea puetaan sanomaksi

Sanoma tulkitaan Vuorovaikutus

Yhteinen näkemys Kommunikaatiokuilu

(20)

Project management is like a river…

…where the water is always moving and making different noises, and yet there is still a river, maintaining similarity of form over time...

Crawford ja Pollack, Project Management Journal 2007

…something

unexpected may also occur…

Formaali viestintä

Spontaani asiantuntijayhteistyö Viestintä poikkeustilanteissa

(21)

Vanhan toistaminen entistä paremmin ei aina auta

Itse luomiamme ongelmia emme voi ratkaista samalla ajattelulla, joka ne synnytti.

Albert Einstein

(22)

LEADING MENTOR

REINO MYLLYMÄKI

CxO Mentor Oy

(23)

CxO Mentor Oy 2011

CxO Mentor Oy

Tietojärjestelmäprojektin onnistumisen varmistaminen

6.9.2011 Reino Myllymäki

CxO Mentor Oy 2011

(24)

CxO Mentor Oy 2011

Emme jääneet laakereille lepäämään!

CxO Mentor Oy 2011

(25)

CxO Mentor Oy 2011

Huomiota projektin alkuun: 3 kohtaa

Strategialinkki Laajuus Tavoitteet

Suunnittelu

Liike- toiminnan

nykytila, tavoitetila ja

gapit

Liike- toiminnan

vaatimus- määrittelyt

Uusien toimintatapojen,

prosessien ja tieto-järjestelmien

käyttöönotto

Sopimus- neuvottelut Business Case

Riskit Mahdollisuudet

Nyky- ja tavoiteprosessit

Arkkitehtuuri- kysymykset

Järjestelmä- ja toimittajavalinnat

Riskien hallinta Vaiheistus

Organisointi Raportointi Mahdollisuudet Toimintatavat Katselmointi Alasajot

Viestintä Toimittajahallinta Muutoshallinta

Toiminnal- liset ja tekniset määrittelyt

Toteutus ja testaus

Käyttöön- oton valmistelu Toiminta-

tapa- muutosten suunnittelu

Toiminta- tapojen ja järjestelmie n yhteis-

testaus

Muutos- johtaminen

Master Data Integrointi BI/DW

G0 G1 G2 G3 G4

(26)

CxO Mentor Oy 2011

98 % kärsii valmistelun puutteista

G0 G1

Strategialinkki Laajuus Tavoitteet

Sopimus- neuvottelut Business Case

Riskit Mahdollisuu-

det

Nyky- ja tavoiteprosessit

Arkkitehtuuri- asiat

Järjestelmä- ja toimittaja-

valinnat

Tarkistuslista

 Toteuttaa strategiaa

 Johto on sitoutunut projektiin

 Laajuus on sopiva

 Tavoitteet ovat järkevät

 Projekti on perusteltu

 Riskit ovat hallittavissa

 Nykyprosessit tunnetaan

 Prosessien omistajat löydetty

 Prosessien muutos tunnetaan

 Järjestelmä sopii nykyarkkitehtuuriin

 Arkkitehtuurimuutokset hallittavissa

 Järjestelmän sisäinen arkkitehtuuri on OK

 …

Iteroiva alku

(27)

CxO Mentor Oy 2011

81 % kärsi projektinhallinnan puutteista

Projektisuunnitelman puutteista 43 %, organisoinnin 41 %, toimintatapojen 34 %

• Juurisyyt

– Projektin suunnittelun puutteissa – Valmistelun puutteissa

– Organisaation johtamiskulttuurin puutteissa

• Projektisuunnitelma on tärkeä

– Hyvän projektipäällikön johdolla tehty – Aikataulun sopiminen

– Oikeat ihmiset organisaatioon: sitoutuminen, ohjaus ja päätöksentekokyky

– Yhteiset toimintatavat

CxO Mentor Oy 2011

(28)

CxO Mentor Oy 2011

Pysäytä hiipivä laajuuden kasvu

26 % kärsi muutospyyntöjen hallinnan (Change Request Management) puutteista

• Projektin aikana tapahtuva hiipivä laajuuden kasvu on

yleinen ongelma (Lienz & Larssen: Risk Management for IT Projects)

• Seurauksia:

– Aikataulun ylittyminen: takaisinmaksu siirtyy – Budjetin ylittyminen: takaisinmaksu pitkittyy – Järjestelmästä tulee vaikea

– Saadaanko koskaan valmiiksi?

• Huomiota muutospyyntöjen hallintaan

– Käyttäjät raportoivat virheinä toivotut lisäominaisuudet – Sveitsiläisen linkkuveitsen problematiikka

– Kannattaa ottaa muutospyynnöt vastaan ja päättää, mitä tehdään projektin puitteissa ja mitä myöhemmin

CxO Mentor Oy 2011

(29)

CxO Mentor Oy 2011

Kolme neuvoa siis

1. Tarkista valmistelun riittävyys viimeistään ennen siirtymistä sopimusneuvotteluvaiheeseen!

2. Varmista projektisuunnitelman sisältö ja laatu ennen

varsinaisen toteutuksen aloittamista!

3. Hallitse muutospyyntöjä

projektin aikana päättäväisesti!

CxO Mentor Oy 2011

(30)

CxO Mentor Oy 2011

Kiitos!

Kysymykset Joonas Iivosen esityksen jälkeen

CxO Mentor Oy 2011

(31)

SENIOR CONSULTANT JOONAS IIVONEN

Project-TOP Solutions Oy

(32)

Projektityökalut projektin onnistumistekijänä

Joonas Iivonen

Project-TOP Solutions Oy

(33)

Sisällys

• Miksi projektityökalu?

• Modernin projektityökalun vaatimuksia

• Hiipivän laajuuden hallinta

• Kehitystehtävien hallinta ERP-projektissa

(34)

Miksi projektityökalu?

(35)

Koko organisaation integrointi yhteen työkaluun

Hajanainen organisaatio johtaa hallitsemattomaan muutokseen.

Order

Project management

Producers

Subcontractors

Coders

Testers IT

Instructors Consultants

Project resources

Chaos

Producers

Testers Coders Subcontractors

Project managers Instructors

IT Consultants

Project resources

Information, software

Information, software Information,

software

Information, software Information,

software

Information, software

Hallitsematon muutos Hallittu muutos

Excel, Word, Sähköposti, Intranet tai verkkoasemat eivät ole projektityökaluja!

(36)

Projektityökalun vaatimuksia

Johto

PMO

PM

Käyttäjät

Strategia jalkautetaan ylhäältä alas

Toteutuminen raportoidaan alhaalta ylös Raportointi

Suunnittelu

Toteutus

Tehtävät

(37)

Projektityökalun mahdollistama johtamismalli

Projekti

Ajantasai- nen tieto tilanteesta

Reagointi ja päätösten tekeminen

Tiedon ja töiden jakaminen Tehtävien

reaaliaikai- nen seuranta

(38)

Yksittäisten muutosten hallinta

• Kaikki muutokset kirjataan

• Jokainen muutos käy läpi sovitun valintaprosessin

• Jokaisella tehtävätyypillään on oma status flow

• Hiipivää laajuutta ei ole

(39)

Kehitystehtävien hallinta ERP-projektissa

(40)

Kehitystehtävien hallinta ERP-projektissa

CR Pool

CR3 CR2 CR1

Planning

• CR1

• CR2

• CR4

Building

• CR1

• CR2

• CR4

Testing

• CR1

• CR2

• CR4

Implementation

• CR1

• CR2

• CR4

Kehitystehtävien hallinta asettaa projektityökalulle omat

vaatimuksensa.

Muutokset kulkevat koko projektin

läpi ja ERP-projektien vaiheistus luo

omat haasteensa.

(41)

(42)

Kiitos!

Joonas Iivonen

Project-TOP Solutions Oy

(43)

TOIMITUSJOHTAJA

TIMO SEPPÄNEN

Ineo

(44)

Onnistunut tietojärjestelmäprojekti:

Perustiedon periytyminen tietojärjestelmissä

Timo Seppänen

06.09.2011

(45)

Aiheet

1. Periytymisilmiö käytännössä 2. Perustiedon hallinnan haarat 3. Perustietoon liittyvät

ongelmat

4. Perustiedon hallinnan kehittäminen

5. Roolit ja vastuut

(46)

Käytännön esimerkki, Myynnin Maksuehto

MDM

Suunnittele ja aseta

Hallinnoi, lokalisoi, jukaise ja jakele

Kuluta

Mittaa Strateginen / Toiminnan suunnittelu:

1. Tavoite sisään tulevan kassavirran kierrolle

2. Johdannainen maksuehtojen arvojoukon määrittely ja ohjeistus

Perustiedonhallinta:

1. Vanhan arvon joukon historiointi

2. Uuden voimaantulevan arvojoukon kirjaaminen ja lokalisointi

3. Uuden arvojoukon julkaisu ja jakelu

kuluttaviin järjestelmiin määräaikana

4. Arvojoukon

implementoinnin ja periytyvyyden seuranta

Liiketoiminta:

1. Asiakkaiden maksuehtojen uudelleen neuvottelu

2. Uusien sopimustenmukaisten maksuehtojen kirjaaminen asiakas-, sopimus-, nimike-tietoihin HUOMIOIDEN PERIMÄJÄRJESTYS 3. Perustiedon periytyminen liiketoimintatapahtumalle

Päätöksen teon tuki:

1. Sisääntulevan kassavirran kiertonopeuden seuranta 2. Maksuehto-tavoitteen

toteutuminen

sopimusneuvotteluissa 3. Perustiedon periytymisen

toteutuminen tapahtumille

1 2

3

4

(47)

Perimän monitorointi

Mitkä ovat suurimmat haasteet?

1. Epäharmoniset perustietomääritykset eri järjestelmissä/liiketoiminnoissa/maissa 2. Realististen tavoitteiden asettaminen

huomioiden paikalliset olosuhteet 3. Periyttämisen sisäistäminen

liiketoiminnassa

(48)

On olemassa kolme perustiedon hallinnan haaraa ...

Global MDM Approach

1. Create alliances/governance 2. Make Available for processes

Process MDM Approach

1. Consume global data & Extend process data 2. Measure MD consumption in transactions

1. Laskentatiedon hallinta, joka luo johtamiskehikon

2. Yleisen perustiedon hallinta, joka kytkee liiketoiminnan toimintaympäristöön

3. Prosessitiedon hallinta joka kuluttaa ja periyttää tietoa

liiketoimintatapahtumille sekä valvoo periytymistä

(49)

Yleisimmät perustieto-ongelmat

1. LASKENNAN RAKENTEIDEN HARMONISOINTITARVE, useat kymmenet sisäisen laskennan rakenteet muodostavat läpinäkyvyyden kulmakiven. Yleisin löydös on niiden eriytyminen eri järjestelmissä, erilaiset käyttötarkoitukset tai -tavat tai niiden vajaakäyttö.

2. YLEISTEN PERUSTIETOJOUKKOJEN HARMONISOINTITARVE: Asiakkaiden, Toimittajien,

Nimikkeiden, Paikkatiedon, Henkilöstön ... päällekkäisyydet , rakenne-/elinkaariongelmat tai niiden ominaistietojen tai laskentarakenne viitteiden erilaisuudet jotka estävät kokonaiskuvan muodostumisen

3. TOIMINTATAPOJEN KORJAUSTARPEET: kaatokoodien käyttö, epämääräiset tila viitteet, epäjohdonmukaiset koodaukset tai ryhmittelyt, virheelliset taseet, virheelliset avainviitteet, epäeheät avainviitteet / perimäketjut. Vaihtelevat toimintatavat estävät yhtenäisen toiminnan ja tiedonhallinnan.

4. AVOIMIEN TRANSAKTIOIDEN PUHDISTUSTARVE: Myynti-, Huolto-, Osto- ja Tuotantotilauksiin tai vaikkapa Myynti/Ostolaskuihin liittyvät keskeneräisyydet tai tilavirheet hämärtää ns.

aktiivista tapahtumakantaa joka on olennainen kaikessa raportoinnissa tai migraatioissa.

5. TIEDON RAKENTEELLISET KORJAUSTARPEET: Järjestelmistä toiseen siirtymiseen liittyy lähes aina tietorakenteiden muuttuminen. Tiedon pituudet, osittelu, säännöt, pakollisuudet, esitystavat jne. vaihtelevat ja edellyttävät konversioita ja rikastusta.

(50)

Perustiedon hallinnan kehittämisen lähtökohdat

1. ”Tieto on toiminnan jalanjälki”. Mitä liiketoimintatapahtumat kertovat

liiketoimintakulttuurista? Löydökset kertovat mitkä ilmiöt ovat toimintaan, tietoon tai järjestelmään liittyviä.

2. Perustiedon hallinnan kehittäminen on riippuvaista/vaikuttaa toiminnan ja

järjestelmän kehittämisestä/-seen. Siten etenemismallin on katettava vuorovaikutus edellä mainittuihin.

3. Perustiedon hallinnan roolit/resurssit tulisi löytää liiketoiminnasta, sen tulisi olla osa liiketoimintaa – ”suomalaisia yrityksiä johdetaan tiedolla”.

4. ”Tiedon periyttäminen” tulee olla johtava kehittämisen ohje. Pyrkimys levittää määrämuotoisia ”parhaita toimintatapoja” ja ”saavuttaa läpinäkyvyyttä” ilmenee parhaiten kykynä periyttää perustietoa liiketoimintatapahtumiin. Tällöin tiedon tulee laadullisesti olla riittävän hyvää jotta se kelpaa tapahtumiin sekä riittävän

yksilöityä/detaljoitua jotta sillä voidaan ohjata tapahtumia (vastaa käyttötarkoitusta).

5. Tiedon hallinnan kehittäminen tapahtuu kolmessa vaiheessa: 1. Sisäisen laskentatiedon hallinta, 2. Yleisen perustiedon hallinta ja 3. Prosessikohtaisen perustiedon hallinta.

6. Perustiedon hallinnan tilanteen korjaamisessa käytetään kahta menettelyä alla olevassa järjestyksessä: 1. Ongelma ratkaistaan toimintatapamuutoksella ja 2.

Ongelma ratkaistaan tiedon puhdistamisella/rikastamisella.

(51)

Tiedon hallinnan rooli kehittämisessä

Poikkeamien

arviointi Uusi Blueprint Uudelleen konfigurointi

Testaus ja

Hyväksyntä Käyttöönotto Käytön tuki

Nykyisen perustiedon

arviointi Poisto, Puhdistus, Rikastus ja Harmonisointi Uuden tiedon

rakentaminen Tiedon migraatio

MDM Tiekartta ja Hallinnointimalli

MDM Prosessi- kehittäminen

MDM ympäristön suunnittelu

MDM:n käyttöönotto

Tietomigraation tukeminen

Jatkuva perustiedonhallinta

Nykytoiminta- tapojen korjaaminen

Toiminnan kehittämisen tavoiteasetanta

Prosessien kehittäminen

Toimintatapojen ja roolien jalkauttaminen

Toimintatapojen käyttöönotto

Käyttökoulutus ja Harjoittelu

Toimintatapojen soveltamisen tuki

(52)

Perustiedon hallinta – Yleinen MDM

MDM vetäjä: Perustiedonhallinta konseptin, työkalujen ja infrastruk- tuurin omistaja sekä integraation ja mittaamisen valvoja.

Koordinoi yleistä Perustiedonhallintaa.

Yleisten perustietojen: Hallinnoi niin laskennan kuin ympäristötietouden vastaten omistajat: perustietojoukkojen määrityksistä, hankintakanavista,

ajantasaisuudesta ja käytettävyydesta.

Tiedon ylläpitoryhmät: Keskitetyt tai hajautetut ylläpito-organisaatiot jotka toteuttavat yleisen perustiedon hallinnointia

1. Yleinen MDM jakautuu laskentaan ja toimintaympäristön liittyvään perustiedonhallintaa

• Laskentatieto; tilikartta, tuoteluokittelu, maksuehto, kustannuspaikka

• Ympäristötietous; asiakkaat, toimittajat, nimikkeet, paikkatieto ...

2. Keskeisimmät haasteet ovat

1. Liittoutuminen lähdetiedontuottajan kanssa / ylläpito lähteellä, 2. Kaikkien liiketoimintaosapuolien tarpeiden kattaminen ja

3. Liiketoimintaosapuolien käyttöön saattaminen

(53)

Perustiedon hallinta – Prosessi MDM

Prosessi omistaja: Omistaa ja vastaa liiketoimintaprosessista ja sen toimintatapojen ja tiedonhallinnan kehittämisestä.

Prosessiomistajan edustaja: Prosessiomistajan kehittämistuki joka edustaa eri prosessiskenaarioiden asiantuntemusta vastaten käytännössä toimintatapojen kehittämisestä ja implementoinnista

Prosessin tiedonomistaja: Prosessin tiedonhallinnan kehittämistuki joka edustaa eri prosessiskenaarioiden tiedontarpeen asiantuntemusta vastaten käytännössä eri käyttötapauskoh- taisten MDM skenaarioiden asetuksesta sekä periytymisprosessin toteutumista.

1. Prosessi MDM jakautuu yleisen tiedon kuluttamiseen sekä prosessi- kohtaisen tiedon laajentamiseen (MDM-skenaario)

2. Prosessi MDM:n haasteena

• kuluttaa yleistä tietoa luoden läpinäkyvyyttä,

• asettaa MDM skenaarioita vastaamaan liiketoiminnan prosessiskenaarioita ja huomioiden erilaisia käyttötapauksia sekä

• mitata perustiedon periytyvyyttä tapahtumille.

(54)

(55)

JOHTAJA

YRJÖ BENSON

Turvallisuus- ja puolustusasiain komitea, Puolustusministeriö

(56)

Lisää selkeyttä IT-projekteihin

Yrjö Benson

6.9.2011

(57)

Sisällysluettelo

IT- projektin hallinta Projektin johtoryhmä

Sitouttaminen ja kytkennät IT-projektin elinkaari

Tehtävän tilat

IT-projektin omistus Järjestelmä vai laiva?

IT-tehtävän koko

 Onnistuva IT-projekti

 IT-projektin riski lisääntyy Projekti vs. lopputulos

Onnistuneen IT-projektin tunnusmerkit

(58)

IT- projektin hallinta

Lopputulos

 Johda projektia siten, että haluttu lopputulos saavutetaan.

Ennakoitavuus

 Ennakoi tehtävät ja niiden vaatimat resurssit ajoissa.

Tilahallinta

 Ole koko ajan tietoinen projektin todellisesta tilasta.

Optimointi

 Optimoi resurssien käyttö: raha, työ, aika ja välineet.

Muutostenhallinta

 Tunnista, arvioi, kuvaa, suunnittele, tiedota ja toteuta muutokset.

(59)

Projektin johtoryhmä

K Määrittää linjaukset

 Lopputuloksen omistaja mukana

" Luo toimintaedellytykset

' Valtuuttaa

& Kannustaa

f Avustaa isoissa ongelmissa

 Tukee matkalla kohti päämäärää

 Projektipäällikön ystävä

(60)

Sitouttaminen ja kytkennät

 Bisnekseen

 Organisaatioon  Prosesseihin  Toimialaan

 Toiminnan kehittämishankkeisiin  Muihin IT-hankkeisiin

 Kumppaneihin  Toimittajiin

 Alihankkijoihin

(61)

IT-projektin elinkaari

Idea, näkemys, tarve, mahdollisuus tai pakko Projektin asetanta

Toteutus

Lopputulos Loppuraportti Luovutus tilaajalle

Lopputuloksen hyödyntäminen Ohjaus Projektisuunnitelma

Muutos- hallinta

(62)

1 2

3 4

7 6

5 ALOITUS

TEKEMINEN

LOPETUS

Tehtävän tilat

Tehtävä on nimetty

Tehtävän lopputulos on määritelty, tehtävä on resurssoitu ( 20 htp) ja aikataulutettu ( 1kk)

Tarkastus on tehty ja puutteita löydetty, palautetaan korjattavaksi

Toteuttaminen

Lopputulos on luovutettu tarkastettavaksi

Tarkastus on tehty ja puutteita löydetty, mutta hyväksytään puutteineen

Tarkastus on tehty ja puutteita ei löydetty, hyväksytään

(63)

IT-projektin omistus

IT:n mahdollis-

tama bisnes

IT omistaa projektin Bisnes

omistaa projektin

Alhaisen prioriteetin

projekti

Bisnesnäkökulma Vahva Heikko

IT-näkökulma Vahva

Heikko

(64)

Järjestelmä vai laiva?







Kokemusta järjestelmien

rakentamisesta on 50 vuotta.

Talojen ja laivojen rakentamisesta on kokemusta 5000 vuotta, siis

100 kertaa enemmän.

Onko siis mikään ihme, että

laivoja ja taloja on helpompi

rakentaa kuin järjestelmiä!

(65)

IT-tehtävän koko

Tehtävä tai projekti Työmäärä

===================================

Salasanan muutos 1 minuutti

Pieni muutos näyttöön 1 tunti Uusi helppo näyttö 1 päivä Uusi vaikea näyttö 1 viikko

50 työaseman päivitys 1 kuukausi Keskikokoinen järjestelmä 1 vuosi

ERP-projekti 10 vuotta

Ison järjestelmän uusiminen 100 vuotta

Uusi käyttöjärjestelmä 1000 vuotta

(66)

 Onnistuva IT-projekti

 Selkeä projektin asetus

 Tavoite on selvä

 Kytkentä bisnekseen on selkeä

 Projektipäällikkö on pätevä

 Resurssiverkosto on olemassa

 Seurataan tuloksia, ei pelkästään tekemistä

 Selkeät välietapit on määritelty

 Seurantayksiköt <1kk ja <1 htkk

 Tiedotussuunnitelma on tehty

 Muutoshallinta on kunnossa

 Aikaa projektinhallintaan 10-20% kokonaistyömäärästä

(67)