21761c39 (Valtiovarainministeriö), olet kirjautuneena sisään. 11. toukokuuta 29 11:8:19 Your boss is {} Kirjaudu ulos Etusivu Kyselyt Raportointi Asetukset Käyttäjätiedot Ota yhteyttä Oppaat Help Päällä P Raportointi >> Perusraportti Palautepyyntö: ICT palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen Vastaajien listaus Kopio e raporttiin Vie tulokset Exceliin Luo suodatus Kyselyn nimi Palautepyyntö:ICT palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen Kyselyn tekijä 21761c39 Kysely luotu 8.4.29 17:11:24 Vastausajankohta 8.5.29 12:5:6 Vastaajien kokonaismäärä 9 Ordered by answers 1. Organisaatio 1. Merijräven kunta (16543371) 2. Rautatievirasto (16573753) 3. Väestörekisterikeskus (16885195) 4. Puolustusvoimat (16896556) 5. Tieturi Oy (16943837) 6. Yksityishenkilö (1698517) 7. Helsingin kaupunki (176186) 8. Valtioneuvoston kanslia (1715164) 9. KELA (175183) 2. Yleiskommentit 1. Suositusluonnos on varsin hyvä, johdonmukainen ja kattava. Dokumenttitasolla prosessin työstäminen on työlästä, mutta vaiheita ja dokumentteja soveltaen saadaan hyvä ja yhdenmukainen lopputulos aikaan. Liitedokumentteihin on vaikea ottaa kantaa teoriatasolla, eli niiden käytettävyys selviää käytännön työn kautta. (16885195) 2. Puolustusvoimat on tutustunut asiakirjoihin ja toteaa ne erittäin hyvin valmistelluiksi ja eri vaihtoehdot (kehitetty vain omaan tarpeeseen, sovellusvuokraus, avoin lähdekoodi jne.) hyvin huomioon ottaviksi. Yleisesti kaikissa kolmessa dokumentissa tulisi paremmin käydä ilmi mitkä dokumentit on vähintään tehtävä ja mitkä ovat tarpeellisia mutta eivät välttämättömiä. Tämä edistäisi mm. pienten projektien läpimenoa ja isojen ohjelmistojen pienten osien parannusta. (16896556) 3. Suurin osa suosituksen asioista on esiselvityksen asioita. Tekstissä viitataankin monessa kohtaa, että tässä esiselvityksen tehtävässä... Eli miksi kehittämiskohteiden tunnistaminen on irroitettu esiselvityksestä, sehän on 1. vaihe esiselvitystä? Suurin osa suosituksen sisällöstä on muutakin kuin kehittämiskohteiden tunnistamista. Tämä outo kahtiajako ja päällekkäisyys vaikeuttaa asian hahmottamista, jos asioita ei tunne entuudestaan. (16943837) 4. Olis varmaan aikaisemmin pitänyt lukea koko homma ajatuksella... 1) dokumentti on liian tietojärjestelmäpainotteinen 2) Arkkitehtuuri sanaa viljellään liikaa (ja aika teknologiapainottesesti) (1698517) 5. Tarpeellinen ja selkeä suositus. (176186) 6. Suosituksen taustalla on ValtIT:n laatima kokonaisarkkitehtuuri menetelmä (KA) ja on huomattavaa, että KA menetelmän käytön hyödyt toteutuessaan edistävät merkittävästi yhteentoimivuutta niin organisaation sisällä kuin eri organisaatioiden välillä. KAmenetelmä on toisaalta melko raskas, joten on harkittava jokaisessa kehittämisprojektissa, mikä on oikea taso kehittämiskohteiden tunnistamiselle, tarvitaanko koko työvälinekokoelmaa vai riittäisikö suppeampi analyysi. Jos KA menetelmä jää vain tietojärjestelmien kehittämisen työkaluksi, hyötyjä ei saavuteta. (1715164)
3. Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 1 5 (5 = samaa mieltä, 1 = eri mieltä) Kysymykseen vastanneet: 8 Suositus on tarpeellinen (ka: 4,875; yht: 8) Suositus on otettavissa käyttöön ilman tukea ja koulutusta (ka: 3,125; yht: 8) Suosituksen luettavuus ja ymmärrettävyys ovat hyvällä tasolla (ka: 3,875; yht: 8) ka: 3,958; yht: 24 5 4 3 2 1 87,5% 7 12,5% 1 33,3% 8 12,5% 1 37,5% 3 62,5% 5 37,5% 9 37,5% 3 25% 2 2,8% 5 25% 2 8,3% 2 4. Suositusluonnoksen hyväksyminen Kysymykseen vastanneet: 9 (ka: 1,7) (4.1) Hyväksytään ilman muutosehdotuksia 33,3% 3 (4.2) Hyväksytään, oheisilla muutosehdotuksilla 66,7% 6 (4.3) Ei kantaa (4.4) Vastustetaan (perusteltava) 5. Vastustusperusteet 6. Yleiset muutosehdotukset 1. Kuvat pitäisi saada yhdenmukaisiksi. Onko JHS:ssä käytetty värejä? Lisää prosessikuvia (1698517) 2. Muutosehdotukset tai pyynnöt selventää tekstiä esitetään jäljempänä. (176186) 3. Vaatimusmäärittelyn paikka "ICT palvelujen kehittämisen vaiheet" prosessissa on mielenkiintoinen, kun sitä vertaa vaiheiden sisältöön. Vaiheessa "Esiselvitys" pohditaan ja kiinnitetään toteutustapa (ASP, SaaS, oma toteutus jne), ja vaiheessa vaatimusmäärittely kerätään korkean tason vaatimukset. Tämä tuntuu takaperoiselta, koska usein korkeankin tason tärkeät vaatimukset vaikuttavat ratkaisevasti toteutustapaan ja erityisesti toteutustekniikkaan. Jos aiemmin on jo päätetty että järjestelmä hankitaan ASPina, mutta yksikään järjestelmä ei täytä kriittistä vaatimusta, niin joudutaanko palaamaan takaisin esiselvitysvaiheeseen? Toisaalta, monesti vasta yksityiskohtaisessa vaatimusmäärittelyvaiheessa tulee esiin asioita, jotka merkittävästi vaikuttavat valintoihin. Toisin sanoen, miten voidaan päättää "miten" tehdään, kun ei vielä ole selvitetty "mitä" tarkkaanottaen ollaan tekemässä? (175183) 7. Muutosehdotukset kappaleeseen 1. Johdanto 1. Miten ICT palvelujen kehittämisen vaiheet prosessi (kuva 1) ja Kokonaisarkkitehtuurin suunnitteluprosessi (kuva 2) liittyvät toisiinsa? Tai paremminkin miten nämä suositukset liittyvät toisiinsa ja näihin prosesseihin? Nyt näyttäisi olevan kovasti päällekkäisyyksiä ja limittäisyyksiä eli suositus ei koske jotakin suunnitteluprosessin vaihetta, vaan suosituksia pitää lukea päällekkäin. Tämä vaikeuttaa hahmottamista, jos asia ei ole entuudestaan tuttua. (16943837) 2. Kuva erityylinen kuin muut (1698517) 8. Muutosehdotukset kappaleeseen 2. Soveltamisala
9. Muutosehdotukset kappaleeseen 3. Termit ja määritelmät 1. Arkkitehtuuri: tällä määritelmällä tarkoitetaan arkkitehtuurin kehittämismallia ei itse arkkitehtuuria (16885195) 2. Erittäin hyvä. Palvelun kuvaus puuttuu, kuitenkin se on keskeinen termi, jota käytetään runsaasti suosituksessa. Toimintaarkkitehtuuri, lisäys: Yksityissektorilla toiminta arkkitehtuurista käytetään nimitystä liiketoiminta arkkitehtuuri (business architecture). Perustelu: Ohjelmistotoimittajat ovat kuitenkin yleensä yksityiseltä sektorilta ja he käyttävät puheessaan business architecture termiä. Toimintaympäristön määritelmä puuttuu. Nyt vaikuttaa siltä, että tekstissä tuota termiä on käytetty monessa merkityksessä. Yleisesti toimintaympäristö tarkoittaa organisaation prosesseja ja toimintoja, mutta tätä termiä on käytetty myös ICT teknologia arkkitehtuuri merkityksessä. (16943837) 3. arkkitehtuuri vs kokonaisarkkitehtuuri?? Arkkitehtuuri termi pois Kaikista x arkkitehtuurin määritelmistä pois "osa alue", on vissiin vaan jäänyt aikaisemmista versioista. järjestelmäarkkitehtuuri > tietojärjestelmäarkkitehtuuri muualla on käytetty jälkimmäistä koko ajan (mikä on hyvä) kokonaisarkkitehtuuri, mistä määritelmä? vois ottaa suoraan menetelmästä: "on toiminnan, prosessien ja palvelujen, tietojen, tietojärjestelmien ja niiden tuottamien palvelujen muodostaman kokonaisuuden rakenne. teknologia arkkitehtuuri: määritelmä liian laaja > ei kuvaa toiminnan yms viitekehyksiä! menetelmästä: "Teknologia arkkitehtuurin keskeinen tavoite on linjata ja rajata käytettävät tekniset vaihtoehdot, standardit ja rakenteet siten, että kokonaisuus tukee parhaalla mahdollisella tavalla organisaation tavoitteita." Toiminta arkkitehtuuri: ydintoiminta!= ydintoimintaprosessi. ydintoimintaprosessi sana pois tietoarkkitehtuuri: tääkin kuvaa, niin kuin muutkin EI tutki. Vois vähän laajentaa > menetelmästä: "organisaation informaatiotarpeita, Tietopääomaa, tietojen välisiä suhteita, informaatioarvoketjuja, tietojen rakenteita sekä informaation organisointia ja hallintaa. Tarkoituksena on luoda organisaatiotasoinen yhteinen näkemys keskeisestä tietopääomasta ja helpottaa informaation löytämistä, välittämistä ja hallintaa. (1698517) 1. Muutosehdotukset kappaleeseen 4. Kehittämiskohteiden tunnistamisen aloittaminen 1. 4: organisaatiokaavio tuntuu jotenkin typerältä tässä. Toimintaympäristö on muutakin kuin organisaation laatikkoleikki. Tähän vois lisätä stepeistä prosessikuvan (1698517) 11. Muutosehdotukset kappaleeseen 4.1 Arkkitehtuurimenetelmän hyödyntäminen kehittämiskohteiden tunnistamisessa 1. Luku 4.1.2 otsikko pitäisi olla juuri aiemmin esitetyn vaihejaon mukainen eli Tavoitetilan hahmotus ja nykytila. Luku 4.1.2, 1. kappale:... määritellään tavoitetila SEKÄ toiminnalle ETTÄ järjestelmille, joita... Luku 4.1.3. Toimeenpanon suunnittelu: Miksi on tässä? Tämä on se kohta, josta Esiselvityksen suosituksessa sanotaan, että se kohdistuu tähän vaiheeseen. (16943837) 2. ja 4.1:stä: jos ei oo 4.2:sta, niin ei oo sitten 4.1:stäkään. 4.1.1: > 4.2. 1. kappale, vika virke joka arkkitehtuuria ei kantsi kirjoittaa > tieto, tietojärjestelmä (!Huom vrt sanasto!!) toka kappale: "silti samalla" pois, "siten" pois. 3. kappale pois "tapauskohtaisesti" ja "myös" 4. kappale: onkin > on. kokonaisarkkitehtuurinäkökulman > kokonaisarkkitehtuurin 4.1.2 > 4.3. "Tavoitetilan suunnittelun lähtökohta on ylhäältä alas", kuulostaa tyhmältä. ei nyt tuu mieleen parannusehdotusta. 4.1.3 > 4.4 (1698517) 12. Muutosehdotukset kappaleeseen 5.Nykytilan kartoitus 1. Listasta puuttuvat kumppaneiden ja sidosryhmien ICT järjestelmät, jotka liittyvät toimintaan. Myös sidosryhmien järjestelmiin ja toimintaan liittyvät projektit vaikuttavat nykytilaan. (16943837) 2. prosessikuva tähän (1698517)
13. Muutosehdotukset kappaleeseen 5.1 Kuvaa nykyarkkitehtuurit 1. Erittäin hyvä, että toiminta arkkitehtuuri on listassa ensimmäisenä! 3. luetelmapallo: lopussa ylimääräinen sulku. Analysoi nykytilan arkkitehtuurien... kappale: luetelmiin ensimmäiseksi "mahdolliset nykyprosessien muutostarpeet (aiheuttajina esim. EU säännökset, lakimuutokset, toiminnan kehittäminen). Tarkoittavatko 2. ja 3. luetelmakohta arkkitehtuurien vastaavuutta vaatimuksiin ja liittymiä vai järjestelmien vastaavuutta ja liittymiä? Eli luetelmakohdissa on sekaisin arkkitehtuuriasioita ja yksittäisiin ICT järjestelmiin liittyviä asioita. 5.1.1 Kuvaa nykyprosessit, 2. kappale: Viitataan esiselvitykseen, vaikka tässä kuvataan kehittämiskohteiden tunnistamista. Mitä tarkoitetaan prosessien kuvauksella? Tarkoittaako prosessikaaviota ja tekstiä, vai vapaamuotoista lyhyttä tekstikuvausta? Prosessikaavio tarvitaan, jotta seuraavassa kappaleessa mainittu järjestelmien tunnistaminen onnistuisi. 5.1.2 Kuvaa nykytilan palvelut ja palvelurakenne: Viittaus liitteeseen 5 puuttuu. 5.1.3 Kuvaa organisaation roolit ja vastuut: Olisi hyvä kuvata myös rooliin kuuluvien henkilöiden lukumäärä keskimäärin ja maksimissaan. Tämä helpottaa tarpeen merkittävyyden selvittämistä, vaatimusmäärittelyä sekä kustannusanalyysin tekemistä. (16943837) 2. otsikko on kuvaa nykyarkkitehtuurit, mutta ei puhuta kuin toiminta arkkitehtuurista?? osa alueet luetellaan alussa, mutta ei muuta?? ekojen bullettien jälkeen oleva kappale: Vika virke pois (Kuvauksien tarkoituksena...) liian tietojärjestelmäpainotteinen, on niitä muitakin kuvauksia. 2. bullettisetti pelkkää tj kamaa > pois vaan, tulee muualla esille. Varsinkin kun loput 5 luvusta ei puhu tietojärjestelmistä mitään. vika virke: "arkkitehtuurien"? > "Analyysin tarkoituksena on selvittää nykytilan mahdolliset ongelmat ja kehitystarpeet." 5.1.1, 5.1.2 ja 5.1.3 toiminta arkkitehtuuria, missäs muut? 5.1.1 3. kappale pelkkää tietojärjestelmäasiaa, missäs tietonäkökulma? (1698517) 14. Muutosehdotukset kappaleseen 5.2 Analysoi nykytilan toiminta 1. Viimeinen kappale pois. Se on jo 1. kappaleessa mukana. (16943837) 2. Analysoidaan VAIN toiminta arkkitehtuuria? (1698517) 15. Muutosehdotukset kappaleseen 5.3 Listaa ja analysoi kehitystarpeet 1. Mitä tarkoittaa "...käyttäjien ja hyödyntäjien TODELLISET tarpeet"? Miten todellinen tarve määritellään? Tarpeen kuvauksesta puuttuu "mihin prosessiin tarve liittyy" Olisi hyvä kirjata myös sidosryhmän edustajan yhteystiedot, jotta tiedetään, mistä voi kysyä lisätietoja tai selvennystä tarpeelle. Analysoi listatut tarpeet kappaleen luetelmat: 1. luetelmakohdassa jälleen viittaus esiselvitykseen, vaikka tämä on kehittämiskohteiden tunnistamista. (16943837) 2. 1. kappale, 3. virke > nyt taas puhutaan pelkästään tietojärjestelmästä pois koko virke. (1698517) 16. Muutosehdotukset kappaleseen 5.4 Selvitä taloudelliset tunnusluvut 17. Muutosehdotukset kappaleseen 5.5 Nykytilan kartoitus ja analysointivaiheen lopputulokset 1. Dokumentoituja osa alueita: Mitä tarkoittavat järjestelmä ja arkkitehtuurikuvaukset? Järjestelmäkuvaukset sisältyvät arkkitehtuurikuvauksiin. (16943837)
18. Muutosehdotukset kappaleeseen 6. Tavoitetilan suunnittelu ja kuvaaminen 1. Kuva 3: liian pieni fontti (16943837) 2. prosessikuva tähän. kuvassa 2, on stepit vähän eri järjestyksessä, vois tässä myötäillä sitä tai muuttaa kuvaa 2. Tavoitetilan suunnittelu ja kuvaaminen!= tavoiteltilan hahmotus, rajaaminen... (1698517) 19. Muutosehdotukset kappaleeseen 6.1 Tavoitetilan hahmotus, rajaaminen ja nykytila 1. Vaiheen tarkoituksena on luetelmat: "tunnistaa alustavasti liittymät" Toiminnan vai järjestelmien? Tehtävät: miksi 6.1.1 Määritä ja rajaa... on ensimmäinen? Ennen rajausta tarvitaan ohjaavaa tietoa eli 6.1.2 pitäisi olla 1. kohta. Rajauksen teko pitäisi olla vasta vision luomisen jälkeen. 6.1.4 Perusta projekti: Onko tämä tavoitetilan suunnitteluprojekti vai mikä? 6.1.5. viimeinen luetelmakohta: "päivitetyt vaatimukset" Mistä on päivitetty? Tähän mennessä missään ei ole kuvattu vaatimuksia. Vasta tarpeita on kerätty. (16943837) 2. Omakssi luvuksi. Tästä luku 6 ja 6.2 > 7 bulleteista: kehittämispyyntö??????????? ei mainita missään muualla dokkarissa kuin tässä kappaleessa! Täähän pitäis olla koko homman triggeri!?!? Joko pois maininnat tai sitten tästä oma luku lukuun 4. 6.1.2 2. virke pois >??? ja lisäksi itsestäänselvyyksiä 6.1.4. vika virke???? mitä tämä siis suomeksi? 6.1.5 lopputuloksena kai myös perustettu projekti tai tavoitetilan jotain vrt 6.1.4 (1698517) 2. Muutosehdotukset kappaleeseen 6.2 Tavoitetilan suunnittelu 1. 6.2.3 Kuvaa arkkitehtuuri..., numeroidun luetelman jälkeen: Teknologia arkkitehtuurinäkökulma on kuitenkin OTETTAVA HUOMIOON mahdollistavana JA RAJOITTAVANA lähtökohtana... (huomioida tarkoittaa katselemista, huomioiden tekoa) 6.2.3.1 Tee puuteanalyysi: Tämä kaipaisi esimerkin. Esimerkiksi mitä tarkoitetaan rakenneosalla: toiminta arkkitehtuurissa rooli, toiminto, aliprosessi, tietovirta. Tietoarkkitehtuurissa tietoryhmä eli käsite, yhteys jne. (16943837) 2. 6.2.4 2. kappale pois > aivan turhaa jaarittelua. Kuva 4 pois. Aivan karmee kuva. Ei auta yhtään, sekottaa vain. ei liity tekstiin. 6.2.5 vika kappale: otsikko on prosesseista ja nyt puhutaan tietojärjestelmistä??? asia tulee paremmin esitettynä myöhemmin. koko kappale pois! 6.2.7 3. bulletti "ja kokonaisarkkitehtuuri" pois (jos otetaan muut näkökulmat huomioon, niin sillon otetaan huomioon kokonaisarkkitehtuuri!) (1698517) 21. Muutosehdotukset kappaleeseen 6.3 Tavoitehyötyjen määrittely ja mittarien laadinta 1. Kuva 6 Hyötykartta: erittäin hyvä ja sopivan ylätasolla oleva kuva. Kuva 7 on hyvä, mutta mistä siihen viitataan? Kuvan hankeraportointinuolen jälkeen oleva laatikko '2. tarkennettu investointilaskelma' pitäisi olla jo ennen 'Toimittajan suunn., toteutus ja testaus' tehtävää, jotta ei tulisi yllätyksiä loppuvaiheessa. Lisäksi ennen toteutusta pitäisi tehdä myös tuo investointilaskelma. (16943837) 2. kuva 7. mistä tää on? muutenkin vähän outo kuva. liittymä tekstiin? (1698517) 22. Muutosehdotukset kappaleeseen 6.4 Tietoteknisten mahdollisuuksien ja rajoitusten määrittely 1. 1. kappale: Mitä eroa on toiminnallisilla tavoitteilla ja tavoiteprosesseilla? Eivätkö ole sama asia? Tähän asti toiminnalla on tarkoitettu prosesseja, ei järjestelmän toiminnallisuutta. 6.4.1 2. kappale: Ja taas viitataan että tämä olisi esiselvitys eikä kehittämiskohteiden tunnistaminen. Jos kahtiajako säilytetään, tämä luku kokonaisuudessaan kuuluu Esiselvitykseen. Lisäksi viitataan Tavoiteratkaisun kuvaaminen vaiheeseen, jollaista ei ole olemassakaan. Esiselvityksessä on vain Tavoiteratkaisun tarkentaminen eli toivottavasti jossain on jo tavoiteratkaisu kuvattu alustavasti. Viimeinen kappale: Onko jossain kuvauspohja olemassa ratkaisuvaihtoehtojen kuvaamiseen? (16943837) 2. 6.4.1 tokavika kappale "(virastot, kunnat)" pois. turhaa ja epätarkkaa. (1698517)
23. Muutosehdotukset kappaleeseen 6.5 Toiminnan kehittämismahdollisuuksien ja rajoitusten määrittely 1. Hyvä! (16943837) 24. Muutosehdotukset kappaleeseen 6.6 Tavoitetilan analyysit 1. 6.6.1 Tee riskianalyysi, 2. kappale: "Järjestelmäkehityksessä riskien arviointi JA TARKISTUS on tärkeää kaikissa vaiheissa." Mikä on jäännösriski? Selitys puuttuu. 6.6.2 Tee tuottavuusvaikutusanalyysi: Pitää ottaa huomioon myös ylläpidon kustannukset, jotka voivat olla 6 9 % kokonaiskustannuksista. Tuottavuusvaikutusanalyysiä olisi syytä tarkistaa pari kertaa hankkeen aikana. Muuten voi tulla isoja yllätyksiä liian myöhään: maailma on ajanut hankkeen ohi. (16943837) 2. 6.6.1.: pelkkiä tietojärjestelmäriskejä!!!! missäs muut? mitä tarkoittaa jäännösriski? 6.6.2 Tee investointilaskelma?? tai sitten toka kappale: "Huomioi tuottavuusvaikutusanalyysissa..." mitä ero tuottavuusvaikutusanalyysi vs investointilaskelma? jos eroa, niin kummasta luvussa puhutaan? 6.6.3 mitä eroa 1. ja 3. bulletilla? lopputuloksena 1) riskianalyysi 2) tuottavuusvaikutus(vai investointi) analyysi (1698517) 25. Muutosehdotukset kappaleeseen 6.7 Kehittämisvaihtoehtojen vertailu ja valinta 1. Lisäisin 2. kappaleen loppuun...(esim. laatu, teknisen ratkaisun sopivuus, YLLÄPIDON KUSTANNUKSET). 6.7.4 Valitse toteutusvaihtoehto, viimeinen kappale: "Käytä vertailuun ja valintaan tarpeeksi aikaa JA tee työ huolellisesti." 6.7.5. Vaiheen lopputulokset: Onko kuvauksille olemassa pohjia? (16943837) 2. 6.7.3 jos avataan asp, niin missä oss ja saas? kuva vs teksti. kuva 9 ihan ok asiaa, mutta kuvana aikas heikko (1698517) 3. Kuva 9: OSS:ää ei ole selitetty eikä löydy sanastosta (onko Open Source System?). Kuvan otsikko on myöskin hämäävä tarkoitetaanko tällä sovelluksen käyttöoikeusvaihtoehtoja (pysyvä, määräaikainen, vuokrattu, avoin)? lisenssin tai käyttöoikeussopimuksen lisäksi voisi luoda kuvaa 9 vastaavan mallin ylläpidon elinkaarikustannuksista, koska usein laajojen ympäristöjen ylläpitokustannukset ovat jopa suurempia kuin lisenssikustannukset vaihtoehtojen valinnassa tulisi painottaa, että tässä tehdään hyvin alustavia vaihtoehtoja ja ne tarkentuvat tai jopa vaihtuvat, kun varsinainen kehityskohde tai ratkaisu on määritelty riittävästi niin, että nähdään mitkä ratkaisut sopivat parhaiten priorisoituihin toiminnan vaatimuksiin sen lisäksi että sopivat kokonaisarkkitehtuuriin ja ovat kokonaistaloudellisia. Kokonaisarkkitehtuurin keskeisimpiä tavoitteita on luoda paremmin toiminnan tarpeita tukevia tietojärjestelmiä. (176186) 26. Muutosehdotukset kappaleeseen 7. Tavoiteratkaisun kuvaaminen 27. Muutosehdotukset kappaleeseen 7.1 Toimeenpanon suunnittelu 1. kuva 1. tällästä kuvaa myös muihin kohtiin! (1698517)
28. Muutosehdotukset kappaleeseen 8. Päätöksenteko ja dokumentointi 1. Hanke termin sisältö jää avoimeksi tässä; usein laajempi toiminnan kehittämiskokonaisuus katsotaan hankkeeksi (vrt. engl. program), johon voi sisältyä useita projekteja. Hankkeen alkuvaiheessa, ennen toteuttamisen hyväksyntää, voisi siis tehdä kehittämiskohteiden tunnistamisen projektina tai projekteina ja hankkeen toteutusvaiheessa tehdään esim. tietojärjestelmäprojektit esiselvityksineen. Nyt esitetään, että hanke käynnistetään vasta esiselvityksen jälkeen, eli onko hanke tietojärjestelmän toteutukseen tähtäävä toimintojoukko? Kuka tekee kehittämiskohteiden tunnistamisen? Jos se on kehittämisen kohteena olevasta linjaorganisaatiosta irrallaan oleva organisaatio, niin nykytilan kuvausten saaminen ja toiminnan tarpeiden kerääminen saattaa olla haasteellista, ellei ole oletuksena, että kokonaisarkkitehtuuri on kuvattu kattavasti kaikilta näkökulmilta. Linjaorganisaation tulisi olla kehittämiskohteiden tunnistamisessa ja tarpeiden asettamisessa mukana vahvasti. (176186) 29. Muutoksehdotukset kappaleeseen 8.1 Valmistuvat dokumentit 3. Muutosehdotukset liitteeseen 1 Organisaatio, sidosryhmät ja liittymät 1. Sidosryhmissä voisi olla lisäksi yhteyshenkilön tiedot. (16943837) 2. Sidosryhmäkartan esimerkki olisi hyödyllinen lisäys suositukseen. (1715164) 31. Muutosehdotukset liitteeseen 2 Tarveluettelo 1. Tarpeesta olisi hyvä kuvata myös tarpeen esittäjän yhteystiedot, jotta voidaan kysyä lisätietoja myöhemmin. (16943837) 32. Muutosehdotukset liitteeseen 3 Mittarit ja hyödyt 1. Tästä olisi hyvä olla esimerkki vaikka omalla lehdykällään. Ks. liite 4 (16943837) 33. Muutosehdotukset liitteeseen 4 Kustannyshyötyanalyysi 1. Erittäin hyvä. (16943837)
34. Muutosehdotukset liitteeseen 5 Palvelukuvaus pohja 1. 5.12 Viestintä > Viestintä ja seuranta 6 Palvelun tuottaminen (prosessit jne): Tärkeää on kuvata ns. päästä päähän prosessi, jossa näkyy sekä palvelun tuottajan, alihankkijoiden että asiakkaiden prosessit. Tämä siksi, että eniten ongelmia on ns. saumakohdissa: eri osapuolet ovat käsittäneet toimintaprosessin hieman eri tavalla. 6.5 Osaaminen: pitää kuvata paitsi palvelun tuottajan osaaminen myös palvelun tilaajan osaaminen. (16943837) 2. Muuten kattavasta palvelukuvauksesta puuttuu luku palvelun päättämisestä. Lisäksi VNK esittää luvun 5.12 otsikoksi Viestintä ja yhteistyömenettelyt ja lukuun lisättäväksi kuvaus palveluun kuuluvista yhteistyö ja seurantaryhmistä ja niiden tehtävistä yleisesti. (1715164)