IIR seminaarissa "Intranet julkisella sektorilla" pidetyn intensiivikoulutuspäivän materiaali. Päivämäärä: 11.12.2009. Aiheena sähköisen työpöydän suunnittelu ja hankehallinta.

1. Sähköinen työpöytä Suunnittelu, toteutus, hankehallinta Intranet julkisella sektorilla 2009-IIR seminaarin päätöspäivä Intensiivikoulutuspäivä 11.12.2009 klo 9.00-16.00 Perttu Tolvanen, konsultti, Sininen Meteoriitti

2. Kouluttaja Perttu Tolvanen, konsultti, Sininen Meteoriitti KTM, tietojärjestelmätiede, digitaalinen media Työhistoriaa mm. Sisällönhallinnan konsultti (ECM), Digia Online-tuottaja, Nelonen Media / Sanoma Projektipäällikkö, Sanoma Projektipäällikkö, Kauppa- ja teollisuusministeriö Tyypillisiä projekteja mm. informaatiopalveluiden konseptisuunnittelu (intranet / internet / extranet) intranet & kollaboraatio – palveluiden suunnittelu ja kehitystiekartat hakutoimintojen suunnittelu & konsultointi sisällönhallintajärjestelmien valinnat

3. Päivän ohjelma 9.00 Sähköinen työpöytä – käsite. Mitä tarkoitamme kun puhumme sähköisestä työpöydästä? 10.00 Sähköisen työpöydän suunnitteluprosessi Kehittämisen konseptointi, vaiheistus ja rajaaminen Sähköisen työpöydän vaatimusten määrittely 12-13 Lounas 13.00 Harjoitus: Sähköisen työpöydän konseptoinnista 14.00 Sähköisen työpöydän toteutus Ketterän kehittämisen mahdollisuudet Kehittämisprojektin hallinta 15.00 Sähköisen työpoydän teknisistä ratkaisuista Keskeisiä teknologioita Oikean ratkaisutoimittajan valinta 16.30 Koulutuspäivä päättyy

4. Käsitesekamelskaa Intranet Hyvin tunnettu termi Moniselitteinen Sanana joskus tahraantunut Portaali Portaali-termi on hyvin moniselitteinen ja täten erittäin ei-suositeltava Sähköinen työpöytä Kysymys: Kuinka moni tuntee termin ”Corporate Portal” tai ”Enterprise Portal”?

5. ”Portaali”-sanan historiaa 1990-luvun lopun hyperkilpailu verkossa (Yahoo ym.) käyttäjien aloitussivusta opetti sanan suurelle yleisölle  Sittemmin kilpailu Webissä on siirtynyt aloitussivuista hakukoneisiin 2000-luvun vaihteessa isot järjestelmätoimittajat alkoivat markkinoida tietojärjestelmätuotteitaan ”portaalijärjestelminä” (engl. ”portals”)  Käytössä edelleen terminä, mutta ei viittaa mihinkään yksiselitteisesti määriteltävään tuoteluokkaan.  ”Portaali” sana voi tarkoittaa hallintajärjestelmää tai verkkopalvelua – tai kumpaakin samaan aikaan (!).  Portaali-termiä ei voi suositella käytettäväksi sen moniselitteisyyden takia. Lisätietoa http://vierityspalkki.fi/2009/11/03/kasitesekamelskaa-julkaisujarjestelma-cms-portaali-sisallonhallintajarjestelma/ tai Googleta ”portaali vierityspalkki”

6. ”Corporate Portals” -historiaa Monia 2000-luvun alkupuolella rakennettuja ”intranetteja” kutsuttiin ”CorporatePortal” tai ”Enterprise Portal”. Usein tavoite liitettiin tietämyksenhallinnan kehittämiseen (”Knowledge management”)  aiheesta löytyy kirjallisuutta erittäin paljon, mutta aihepiiri on hyvin laaja Konsepteissa kaksi eri painopistettä: Information / Collaboration Tyypillisiä tavoitteita näissä projekteissa: Yksi sisäänkirjautuminen, välitön pääsy moneen eri tietojärjestelmään (ns. SSO = ”Single Sign-On”) Useiden eri tietojärjestelmien integrointi portaaliin ja toimintojen tuominen näkyviin ”portleteissa”. Personointitoiminnot ja hienorakenteinen profilointi Yhteinen hakutoiminto kaikkiin eri tietovarastoihin Myös organisaation ulkopuolisia käyttäjiä (extranet-ulottuvuus)

7. ”Corporate Portals” –ajanjakson opit Käyttäjien kannalta personoitava etusivu on ”kiva”, mutta ei aidosti tärkeä. Kysymys: Kuinka moni meistä järjestää työpöytänsä uuteen järjestykseen kerran viikossa?  Johtopäätös: Tiedon, ihmisten ja sovellusten löytäminen on tärkeätä. Ei kaikkien asioiden mahtuminen samaan, tyylikkäästi järjestäytyvään etusivuun.  Johtopäätös: Kaikkia asioita ei kannata yrittää tehdä yhdellä tietojärjestelmällä. Erikoistuneet sovellukset ovat usein helpompia käyttää.

8. Esimerkki: Portaalin hallintakäyttöliittymä (Sun Portal + Fatwire sisällönhallintajärjestelmä) Lähde: CMS Watch artikkeli: http://www.cmswatch.com/Feature/120-Case-Against-Portals Esimerkki on vuodelta 2005, mutta tämä todellisuus näkyy vielä 2009 vuonna monien toimittajien tuotteissa. Käytettävyys on valtava haaste.

9. Mitkä asiat liittyvät ”Sähköinen työpöytä” –sanaan? Prosessiohjattu dokumenttituotanto Hakutoiminto Pikaviestintä ja keskustelukanavat Ryhmätyötilat Tilapäivitykset ja linkkien jakaminen Puhelinluettelo Projektinhallinta Sähköinen työpöytä Wikit Blogit Asiahallinta Kommentointi ja keskustelu Uutiset Ohjeet, mallit, käsikirjat Henkilöstöhallinnon ohjeet, mallit ja lomakkeet Palveluhakemisto Dokumenttienhallinta ”Uuden työntekijän opas” Sähköposti Linkit eniten käytettyihin sovelluksiin Verkkolevyt Avoimet kalenterit ja osallistumistieto Yhteiset sähköpostikansiot

10. Määritelmä: Sähköinen työpöytä ”Yhteistyön ja tiedonhallinnan alusta” Muita ehdotuksia?

11. Esimerkki Sähköisen työpöydän määrittelystä

12. Tietotyöläisen työvälineet, nykytila (Case: suomalainen konserni) Muita tietojärjestelmiä: toiminnanohjausta, varastohallintaa, rekistereitä, jne. Verkkolevy: U-asema Dokumenttienhallintajärjestelmä + ”Asianhallinta” Viestinnällinen intranet (uutiset tärkeässä roolissa, myös tiimikohtaisia suljettuja sivustoja) Office-työvälineet: Outlook, Word, PowerPoint, Excel. (versio 2003 nyt  versio 2007 keväällä  versio 2010 syksyllä arvio) Windows-käyttöjärjestelmä tietotyöläisen tietokoneessa

13. Tietotyöläisen työvälineet, tavoite (Case: suomalainen konserni) Muita tietojärjestelmiä: toiminnanohjausta, varastohallintaa, rekistereitä, jne. SharePoint Server (versio 2010) SharePoint Server (versio 2010) SharePoint Server (versio 2010) Verkkolevy: U-asema Dokumenttienhallintajärjestelmä + ”Asianhallinta” Viestinnällinen intranet (uutiset tärkeässä roolissa, myös tiimikohtaisia suljettuja sivustoja) Pikaviestintäohjelmisto (”MOCS 2007”) + LiveMeeting Office-työvälineet: Outlook, Word, PowerPoint, Excel. (versio 2003 nyt  versio 2007 keväällä  versio 2010 syksyllä arvio) Windows-käyttöjärjestelmä tietotyöläisen tietokoneessa

14. Tietotyöläisen työvälineet, tavoite (Case: suomalainen konserni) Muita tietojärjestelmiä: toiminnanohjausta, varastohallintaa, rekistereitä, jne. SharePoint Server (versio 2010) SharePoint Server (versio 2010) SharePoint Server (versio 2010) Verkkolevy: U-asema ”Sähköinen työpöytä” Dokumenttienhallintajärjestelmä + ”Asianhallinta” Viestinnällinen intranet (uutiset tärkeässä roolissa, myös tiimikohtaisia suljettuja sivustoja) Pikaviestintäohjelmisto (”MOCS 2007”) + LiveMeeting Office-työvälineet: Outlook, Word, PowerPoint, Excel. (versio 2003 nyt  versio 2007 keväällä  versio 2010 syksyllä arvio) Windows-käyttöjärjestelmä tietotyöläisen tietokoneessa

15. Huomioita esimerkistä Sähköisen työpöydän määritelmässä on lähdetty liikkeelle tietotyöläisen nykytilasta jota hallitsevatOffice-ohjelmistot, vuosien varrella paisunut verkkolevy ja iso määrä sisäistäsähköpostiliikennettä. Konseptissa huomioidaan sähköpostikäytänteet, pikaviestintäohjelmiston käyttöönotto, ryhmätyötilat, dokumenttienhallinta ja hakutoiminto. ”Sisäisen tiedonhallinnan kehityshanke” = ”Sähköinen työpöytä”

16. Esimerkkinä Ystävä 2010 Helsingin yliopiston sähköinen työpöytä –hanke lähtee hyvin käytännönläheisestä päivittäisen tekemisen tukemisesta. Muita näkökulmia?

17. Varma intranet Esimerkki:

18. Kuva vaihtuu kuukausittain automaattisesti metatiedon Numero mukaan (1=tammikuu). Uusimmat uutiset nostoina, 6kpl. Muut uutistyypit omilla nostoalueilla, nostoja 3kpl.

19. Uutisointi

20. Uutiset-sivuston etusivulla koonti kaikista kuukauden uutisista.

21. Uutissivu. Oikealla nosto saman uutistyypin viimeisimmistä uutisista

22. Osastot

23. Osastokohtainen sivunäkymä, jolla on omat uutiset, dokumentteja ja keskusteluja.

24. Työtilat

25. Projektit voi listata tilan mukaan. Listaus käyttäjän projekteista. Listaus sisältää työtilojen metatiedot.

26. Työtilan luontisivu. Dokumentti-kirjastojen käyttöoikeuksien asettamiskentät.

27. 2 Dokumenttikirjastoa, josta toinen on suojattu käyttöoikeuksilla

28. Yhteenveto 2009 vuoden tilanteesta Verkkosivustomaisista intranet-sivustoista on siirrytty monipuolisiin intranet / sähköinen työpöytä / portaali –palveluihin Pistemäisistä ratkaisuista on siirrytty puhumaan yhä isommista kokonaisuuksista Muotitermi ”ECM” (Enterprise Content Management) hyvänä esimerkkinä. Internet-sivustojen ja organisaatioiden sisäisen tiedonhallinnan kehitys on eriytynyt yhä enemmän Intranetin julkaisujärjestelmä ei enää oletuksena ole sama järjestelmä kuin mikä on valittu internet-sivustolle SharePoint 2007 on kasvattanut asiakkaiden osaamista paljon ja odotukset ovat kasvaneet myös kilpailijoiden tuotteita kohtaan Tuotteet ovat kehittyneet merkittävästi lähemmäksi tasoa jossa räätälöinti on enemmän poikkeus kuin sääntö

29. Suunnittelun osa-alueet Sähköinen työpöytä -hankkeen

30. Suunnitteluvaiheen tehtäväkokonaisuudet Esitutkimus / ”Tiedonhallinnan nykytilaselvitys”  Visio organisaation sähköisestä työpöydästä Hankesuunnitelma  Budjetointia ja sisäistä markkinointia varten Konseptisuunnittelu ja toiminnallinen vaatimusmäärittely  Priorisoitu kuvaus tarvittavista toiminnoista Sisällönhallintajärjestelmätuotteiden arviointi ja toimittajien tarjonnasta neuvottelu Sopivimman sisällönhallintajärjestelmän valinta ja sopimusneuvottelut valitun toimittajan kanssa

31. Valmistelu ja suunnittelu Konsepti ja toiminnot Esitutkimus Hankesuunnitelma (1 kk) (1-3 kk) (2-4 kk)

32. Järjestelmä- ja toimittajavalinta Tuotteiden arviointi Toimittajan valinta (2-3 kk) (1-3 kk)

33. Esitutkimus Sähköinen työpöytä -hankkeen

34. Sisällönhallinnan viitekehys eli nk. ”timanttimalli” Lähde: Kuva on Digian konsulttien Tuomo Peltolan ja Anne Honkarannan artikkelista. Samaiset henkilöt myös julkaisseet aiheesta tieteellisiä artikkeleita. Malli perustuu aiemmin tehtyyn dokumenttienhallinnan kehityksen tutkimukseen ja organisaatioiden kommunikaatiogenrejen tutkimukseen. Googleta ”sisällönhallinnan timanttimalli” tai http://www.digia.com/C22571C5003CAD30/7998BEFB48219495C22574040024B37A/$file/OPEN_2007_2_fin.pdf

35. Esitutkimus: tiedon kerääminen 1/2 Johdon näkökulma Haastattelut / johdettu työpaja Mukana eri ryhmien edustajat (kuten HR, Viestintä, liiketoiminnot) Tietotyöläisten haastattelut 1-3 henkilöä kerrallaan suositeltava Haastateltavista kerätään samalla ryhmä jolle viestitään hankkeen etenemisestä ja kerätään palautetta jatkossakin suunnitelmista Tavoitteena jo alkuvaiheesta asti rekrytoida laajaa joukkoa ”muutosagentteja” Ryhmätilaisuudet Teematilaisuudet tiettyjen liiketoimintaryhmien kanssa voi olla yksi hyvä vaihtoehto selvittää nykytilanteen haasteita. Voi monesti olla poliittisista syistä paras tapa edetä – vaikka ei käytännössä tuottaisikaan lattiatason ymmärrystä parhaalla mahdollisella tavalla. Sisäinen verkkokysely jolla kartoitetaan nykytilannetta ja eri osa-alueiden uudistushalukkuutta henkilöstöltä Verkostojen solmukohdissa työskentelevien henkilöiden haastattelut Kaikissa organisaatioissa on ihmisiä jotka toimivat ”tietohubeina”. Nämä henkilöt voivat olla osastosihteereitä, asiakaspalveluhenkilöitä, eri yksiköiden välillä työskenteleviä kehityspäälliköitä, johdon sihteereitä tai eri tehtävissä kokemusta keränneitä näkemyksellisiä työntekijöitä.

36. Esitutkimus: tiedon kerääminen 2/2 Käyttötilastojen analysointi Nykyisen intran käyttötilastot, tärkeimpien tietojärjestelmien käyttötilastot (esim. dokumenttienhallintajärjestelmä ja asianhallinta), sähköpostiliikenteen tunnuslukuja per henkilö, verkkolevyjen sisältö ja käyttömäärät, tulostusmäärät  Pohjaluvut uudistuksen mittareille Sisäisten hakukoneiden tilastot ja hakutermit Eniten haetut termit ja näiden kohteiden analysointi Termien ryhmittely, ”pitkän hännän” analysointi Sisältöinventaariot: Intranet & verkkolevyt / muut tiedonhallintajärjestelmät, kuten DH-järjestelmä

37. Sisältöinventaarioiden merkitys Nykytilaa kuvaavien inventaarioiden työstämistä yleensä vältellään viimeiseen asti, mutta hyvät inventaariot a) parantavat ymmärrystä nykytilasta, b) vähentävät teknisen toteutuksen riskejä ja erityisesti 3) parantavat todennäköisyyttä, että loppukäyttäjille lanseeraus onnistuu!

38. Tiedonhallintatyökalujen roolien määrittely Tunnista järjestelmät. Tunnista roolit.

39. Esitutkimuksen tulokset ”Visio sähköisestä työpöydästä” tai yleisemmin ”Tiedonhallinnan nykytilaselvitys” Käyttäjätutkimuksien tulokset Raportoidaan timanttimallia käyttäen: ihmiset, roolit, prosessit, dokumentit, teknologiat Käyttötilastojen yhteenveto Sisältöinventaarioiden yhteenveto Tärkeimpien käyttäjäryhmien tunnistaminen Tärkeimpien kehitettävien toiminnallisuuskokonaisuuksien kuvaaminen Suhde muihin tiedonhallintajärjestelmiin

40. Esitutkimus: tiedon viestintä Johdolle työpaja jossa käydään läpi saadut palautteet ja haastattelutulokset Keskustelutilaisuuden järjestäminen henkilökunnalle ja palautekanavan tarjoaminen jälkikommenteille ja ideoille Sarja uutisia intrassa tai hankeblogissa esitutkimuksen tuloksista, tilastoista ja saaduista palautteista Esim. http://blogs.helsinki.fi/ystava-2010/

41. Esimerkki http://blogs.helsinki.fi/ystava-2010/

42. Hankesuunnitelma Sähköinen työpöytä -hankkeen

43. Aiheet Hyötyodotukset Intranetin kannattavuus Kannattavuuslaskelmien tekeminen Intranetin suhde muihin hankkeisiin Vinkit hankesuunnitteluun

44. Hyötyodotukset intranetin kehittämisessä Miksi intranetiä on ryhdytty kehittämään? Ongelmaprojektilla ei tyypillisesti selvää käsitystä Tietojärjestelmälle määriteltävä lopputulosten lisäksi ne muutokset, joita tietojärjestelmän odotetaan edesauttavan Valitettavan usein intranet on se järjestelmä, jota kehitetään ilman terävää tavoitteenasetantaa, ”koska sellainen pitää olla” Ilman selviä tavoitteita on priorisointien ja valintojen tekeminen projektissa vaikeata, ellei mahdotonta Miten voidaan todeta kehittämisprojektin onnistuneen, jos ei tunneta sen tavoittelemia vaikutuksia?

45. Esimerkkejä hyödyistä Tehokkuuden kasvattaminen Olemassa olevan tietopääoman parempi hyödyntäminen Tietojen nopeampi löytyminen Rutiiniluonteisten tehtävien väheneminen Hajautetun ja liikkuvan työn tukeminen Matkustamisen vähentyminen Laadulliset hyödyt Tietoturvan parantaminen Vastaaminen lainsäädännöllisiin vaatimuksiin Uusia palveluita asiakkaille/kumppaneille (extranet) Työn mielekkyyden lisääntyminen Sähköpostin määrän vähentyminen ja luonteen muuttuminen Esimerkiksi nuorempi sukupolvi odottaa jo enemmän työvälineiltään (esim. pikaviestintä tärkeä)

46. Intranetin kannattavuus? Mikä on intranet-investoinnin takaisinmaksuaika? Mitä ongelmia intranet ratkaisee? Mitä hyötyjä intranet tuottaa ja keitä ovat hyödynsaajat? Tehokkuutta/säästöjä intranetin avulla? Laadullisia hyötyjä? Jos tarkkaa kuvaa tavoiteltavista hyödyistä ei ole, sisältää investointi helposti tarpeettomia ominaisuuksia, joista jokainen maksaa

47. Kannattavuuslaskelmien sudenkuoppa Kertyykö organisaatiossa tarvittava data, vai ovatko luvut ja lupaukset hihasta ravistettuja?  Älä anna todellisia lukuja jos päädyt ravistamaan ne hihasta.

48. Kohti realistisempia hyötyodotuksia Ole tarkka intranetin esiselvityksen toimeksiannon kanssa ja varo itsensä toteuttavia toimeksiantoja Osallistu tarvittavan datan tuottamiseen ja analysointiin Älä hyväksy pseudodataa päätösten perusteluina Älä tuota pseudodataa päätösten tueksi

49. Esimerkki ”business casesta”: ”Käytän päivässä joskus jopa tunnin siihen, että haeskelen sähköpostistani dokumentteja jotka tiedän joskus vastaanottaneeni tai lähettäneeni – enkä tee tätä työtä itseni takia vaan sen takia että joku muu tarvitsee kyseisen dokumentin. … Kai tähän olisi jokin parempikin tapa?”

50. Mitkä ovat intranetin kehittämisen kokonaiskustannukset? Valmistelevat tehtävät Vaatimusmäärittelyt Resursointi Projektin osto ja käynnistäminen Tarjousten pyytäminen, toimittajan valinta, sopimusten tekeminen Projektin läpivienti Projektiin käytettävä sisäinen työ, laitteistot sekä toimittajan työ Ohjelmiston käyttöönotto ja lisenssimaksut Koulutus ja käyttöönotto ja toimittajan työn loppumaksu, lisenssimaksut Ohjelmiston ylläpito, ylläpitomaksut ja jatkokehitys Vuosittaiset ylläpitomaksut, oma ylläpitotyö sekä jatkokehitystyön kustannukset Lähde: Kettunen S. 2002. Tietojärjestelmän ostaminen – käytännön opas yrityksille. WSOY.

51. Esimerkki (sisäiset kustannukset huomioitu, kohteena perinteinen tietojärjestelmä) Lähde: Kettunen S. 2002. Tietojärjestelmän ostaminen – käytännön opas yrityksille. WSOY.

52. Intranet-hankkeen erityispiirteet resursoinnin osalta Sisältösuunnittelu (10-50 htp) Sisältöjen tuotanto (20-80 htp) Mallipohjien ja metatietomallin suunnittelu (15-40 htp) Organisatorinen käyttöönotto & hankeviestintä (10-20 htp) Jatkuvan kehittämisen budjetti (20-60 htp) per vuosi

53. Onko olemassa päällekkäisiä/kilpailevia hankkeita? Intranet-hankkeille on tyypillistä, varsinkin isoissa organisaatioissa, että ne sisältävät päällekkäisiä toiminnallisuuksia muissa hankkeissa toteutettavien tietojärjestelmien kanssa Minkä hankkeen tehtävä on ratkaista mitäkin ongelmia? Hankkeenhallinnan riskit (Elonen, 2002)! Riittämättömät projektisalkkutason aktiviteetit Päällekkäisyydet ja ristiriitaisuudet projekteissa ja projektisalkuissa Projekteille annetaan liian helposti lupa käynnistyä Projektisalkun hallinnan vastuut epäselvät Projektitasolle ei anneta palautetta Projekteja ei keskeytetä

54. Mikä on intranetin rooli tietojärjestelmien joukossa? Mitkä ovat intranetin tehtävät, jotka juuri sen pitää ratkaista? Intranet vs. ryhmätyöohjelmistot Intranet vs. dokumenttien hallinta vs. levyjaot Intranet vs. hakupalvelu Kuka on intranetin luontevin omistaja? Toiminnan kehittäminen (projektit) HR Viestintä (Tietohallinto) Omistajan löytyminen selkeyttää myös intranetin roolia Mitä prosesseja intranetin tulee tukea?

55. Vinkit hankesuunnitteluun 1/2 Tunnista kehittämistarpeen suhde muihin kehittämisaloitteisiin (salkunhallinta moniprojektiympäristössä) Määrittele selvät tavoitteet kehittämiselle omistaja ja avainprosessit ratkaistavat ongelmat hyödyt ja hyödynsaajat Määrittele alustava ratkaisumalli, jotta investoinnin järkevyys voidaan arvioida tekninen ratkaisu, projektiympäristö, käyttöympäristö huomioi sisäiset kulut ja käyttöönoton vaatimat sisäiset ponnistelut Vertaa 5-6 vuoden kokonaiskustannuksia hyötyihin, arvioi kehittämisen järkevyys ja tee valistunut aloitus- tai hylkäyspäätös

56. Vinkit hankesuunnitteluun 2/2 Johda tavoiteltavista hyödyistä alustavia vaatimuksia toteutettavalle järjestelmälle liiketoiminnan vaatimukset käyttäjien vaatimukset toiminnalliset vaatimukset Suunnittele käyttäjien osallistuminen toteutusprojektiín Mahdollista vaatimuksien tarkentaminen valitun teknisen ratkaisun näkökulmasta Hallitse vaatimuksia koko toteutuksen ajan. Hankejohtamista ei voi ulkoistaa! Testaa huolella. Valmistuotteetkin vaativat testauksen. Jätä 10-20% budjetista matkan varrella opittavia asioita varten – projekti- ja hankintamallista riippumatta!

57. Konseptisuunnittelu Sähköinen työpöytä -hankkeen

58. Tyypillisiä sähköiseen työpöytään liitettyjä odotuksia Päivittäisessä työssä tarvittava dokumentaatio, tietojärjestelmät, prosessit ja prosessiohjeet kerätään käyttäjän näytölle yhteen Työpöytä on personoitu käyttäjän roolin mukaan Käyttäjän näkemät tiedot, sovellukset ja palvelut vaihtelevat työntekijän roolin mukaan

59. Personointi ja profilointi Soveltuvat silloin kun palvelussa on ”liikaa” sisältöjä perinteisille käyttöliittymille Profilointia voidaan tehdä ainoastaan suurilla käyttäjämäärillä - ja jotta käyttäjistä saadaan muodostettua kattava ja todenmukainen kuva, tarvitaan hyvä käyttäjätilastointi & muita tiedonkeruumenetelmiä  Käytännössä Suomessa ei ole kuin kourallinen organisaatioita jotka ovat riittävän suuria tarvitakseen voimakasta personointia ja profilointia. Eriäviä mielipiteitä? (Huom. Sisältöjä voidaan korostaa, kohdentaa ja nostaa esiin perustuen käyttäjän tietoihin ilman, että tätä tehdään mitenkään automaattisesti/älykkäästi.)

60. Teknisesti tai toiminnallisesti Kokoelma linkkejä Dokumenttivarasto HTML-dokumentteja Sovellusintegraatioita Integraatio organisaation käyttäjähallintaan Raportteja taustasovelluksista Prosessisovelluksia Ryhmätyömahdollisuuksia

61. Konseptin painopiste tulee itse päättää Painopiste toiminnallisuuksissa ja sisällöissä on kiinni konseptista Konsepti on usein käytännössä sidoksissa intranetin omistajaan Viestintä tekee viestinnällisen intranetin Käytännössä konsepteja on useita, joiden selkiinnyttäminen on kaiken suunnittelun lähtökohta Esitutkimus on yleensä antanut jo suunnan.

62. Suunnittelutiimi Suunnittelutiimi: Ydinryhmän maksimi viisi (5) henkeä. Esim. konsultti, asiakkaan projektipäällikkö ja kolmen (3) eri yksikön edustajat. Loistavia intranetteja on tehty kolmenkin hengen voimin (esim. konsultti, it-projektipäällikkö ja viestintäpäällikkö). Laajempi ryhmä voi olla tukiryhmänä, mutta yli viiden hengen ydinryhmiä ei voi suositella. Tärkeintä on pitää projektin eteneminen läpinäkyvänä. tämän tavoitteen tulisi sanella ryhmän jäsenten valinnat. Jokaisen ryhmän jäsenen tulee voida esitellä projektin etenemistä yhteistilaisuuksissa ja "omille joukoilleen”.

63. Millaisia ominaisuuksia sähköiseltä työpöydältä edellytetään? ”Perinteiset” intranettien tietosisällöt: ohjeet ja mallit työsuhde- ja liiketoiminta-asioihin Verkkosisällön hallinta Henkilöhakemisto / profiilisivujen hallinta Uutiset & blogit Aloitussivutoiminnot / ”Oma sivu” Haku Ryhmätyötilat (wikit, suljetut osiot, rajattu keskustelu) Dokumenttien hallinta (tallennus, versiointi, jakaminen) Asiakirjojen hallinta (vaatimukset, käytänteet) Työnkulut / Liiketoimintaprosessien hallinta Sähköiset lomakkeet Sähköpostin hallinta ja arkistointi Sähköinen arkistointi Asianhallinta Vinkki: Kannattaa tehdä oma versio tästä listasta!

64. ”Haavekuva tiedonhallintaympäristöstä” DH/asianhallinta Ryhmätyötilat Verkkolevyt Haku Intra/hakemistot Henkilöhakemisto Uutiset Pikaviestintä

65. Sisäinen vs. kumppanit vs. ulkoinen Verkkopalvelu DH/asianhallinta Ryhmätyötilat Extranet Verkkolevyt Haku Henkilöhakemisto Uutiset Pikaviestintä Intra/hakemistot

66. Menetelmä: Toimintatarinat / Käyttäjätarinat Tarinoita todellisista käyttötapauksista. Tarinat kertovat käyttäjien tavoitteista ja syistä. Jokaisessa tarinassa on joku henkilö joka haluaa tehdä jotain jostakin syystä. Tarinassa kuvataan mitä henkilö haluaa ja miksi hän sen haluaa… Osa tarinoista on enemmän ’eeppisiä’ kertomuksia jonkun henkilön tavoitteista ja motiiveista, toiset tarinat ovat konkreettisempia.

67. 1) Tarinoiden aiheiden valinta Esitutkimus antaa yleensä jo hyvät edellytykset tunnistaa tärkeimmät ominaisuusluokat. Voi aloittaa myös tyypillisistä, eli: ”Perinteiset” intranettien tietosisällöt: ohjeet ja mallit työsuhde- ja liiketoiminta-asioihin Verkkosisällön hallinta Henkilöhakemisto / profiilisivujen hallinta Uutiset & blogit Aloitussivutoiminnot / ”Oma sivu” Haku Ryhmätyötilat (wikit, suljetut osiot, rajattu keskustelu) …

68. 2) Tarinoiden kirjoittaminen Hahmot yleensä kuvitteellisia, mutta perustuvat todellisiin henkilöihin. Usein yhdistelmiä useasta todellisesta roolista. Yksi tarina keskittyy mieluiten 1-2 ongelmakokonaisuuteen, mutta osa tarinoista voi olla myös laajempia (’eeppisiä’ tarinoita). Tarinoiden aiheiden keksimisessä kannattaa käyttää laajempaakin porukkaa ideointiapuna. Ison organisaation intranet vaatii helposti 40-50 tarinaa. (Joskus voi 10-20 riittää.)

69. Esimerkki: toimintatarina: Kalle, 27v, vastavalmistunut tohtori Kallella on useita tutkimusprojekteja pyörimässä ja projekteissa on mukana porukkaa niin organisaation sisältä kuin ulkopuolisista yrityksistä. Kalle kommunikoi pääosin sähköpostitse eri tahojen kanssa ja merkittävä osa työstä on yhteisten artikkeleiden kirjoittamista. Dokumentit lentelevät sähköpostin liitetiedostoina ympäriinsä. Projektipäällikön rooli tuo paljon velvollisuuksia hakemusten ja raporttien kirjoittamisessa. Deadlinet tahtovat välillä unohtua ja yhteisistä aikatauluista ei aina saada pidettyä kiinni. Yhdessä projektissa on tärkeä kumppani USA:sta ja videoneuvottelujen järjestäminen ja materiaalien hallinta on viikottainen ongelma. Laajan yhteistyökumppanijoukon kanssa toimiminen on tärkeä osa Kallen työtä ja henkilöhakemisto on tärkeä sovellus. Kalle toivoisikin, että henkilöhakemisto kertoisi enemmän eri henkilöiden toimenkuvista ja käynnissä olevista projekteista.

70. Esimerkki: toimintatarina: Esko, 52v, tutkimusjohtaja Esko (52v) on pitkän linjan tutkija ja yliopistotoiminnan osaaja. Esko on hiljattain vaihtanut uuteen yliopistoon ja saanut vastuulleen merkittävän kokoisen tutkimusyksikön. Uudessa tehtävässä haasteena on oppia tuntemaan organisaatiorakenteet ja kaikki henkilöt joiden kanssa tulisi tehdä yhteistyötä. Intran organisaatiorakenteet ja eri yksiköiden tieto omasta toiminnastaan on tärkeässä käytössä. Henkilöhakemisto on ollut Eskon apuna päivittäin ensimmäisten kuukausien aikana kun hakemistosta on voinut tarkistaa mitä äsken tavattu henkilö oikein tekee ja missä projekteissa hän on mukana. Ison yksikön esimiestehtävät ovat myös uusi aluevaltaus ja täten esimiestehtäviin liittyvät ohjeet ovat tärkeitä Eskolle. Esko seuraa tarkkaan organisaation uutisia ja mielellään kommentoi uutisiin myös, koska kilpailevasta yliopistosta tulleena henkilönä osaa monesti täydentää ”kolikon toisen puolen”. Raportointivastuuta on paljon joten erillissovellukset ovat osa päivittäistä työtä. Intran uutisissa Eskoa hieman harmittaa kun opetukseen liittyvät uutiset saavat paljon palstatilaa ja näillä kun ei Eskolle ole merkitystä. Intranet Erillissovellukset laitossivustot laitossivustot laitossivustot laitossivustot

71. 3) Tiivistäminen ja suhteiden tunnistaminen Tärkeimmät tarinat kannattaa tiivistää ja ryhmitellä tarinoiden painopisteiden mukaan Esim. ryhmätyötiloihin liittyvät tarinat yhteen ryhmään, työsuhdeasiat yhteen, matkalaskut ja kulukorvaukset yhteen, pikaviestintä ja sähköposti yhteen, jne.

72. Tahtoo: työvälineitä projektiensa johtamiseen, tukea hakemuksien tekemiseen, apuvälineitä liikkuvaan työhönsä, ohjeita matkustamiseen ja kulukorvausten hakemiseen, paremman henkilöhakemiston Ei välitä: koko organisaatiota koskevista uutisista Erityistä: Käyttää Mac-tietokonetta Tahtoo: työvälineitä projektien johtamiseen, tukea esimiehenä toimimiseen, parempia sisäisiä viestintävälineitä Ei välitä: yleisohjeista, henkilöhakemistosta Erityistä: Haluaisi lisää läpinäkyvyyttä organisaation projekteihin Kalle, 27v tutkija Pekka, 37v tutkija Sähköinen työpöytä Tahtoo: viestintävälineitä, tukea opintojaksojen organisointiin ja materiaalien jakamiseen,opetustoimintaa koskevia uutisia Ei välitä: tutkimukseen liittyvistä asioista, pikaviestinnästä Tahtoo: kokonaiskuvan organisaatiosta, henkilöhakemiston, esimiesohjeita, yleisiä uutisia, linkit erityissovelluksiin Ei välitä: opetukseen liittyvistä asioista Mervi, 34v , lehtori Esko, 52v, tutkimusjohtaja

73. Tutkimus-projektiwiki Tahtoo: työvälineitä projektien johtamiseen, tukea esimiehenä toimimiseen, parempia sisäisiä viestintävälineitä Ei välitä: yleisohjeista, henkilöhakemistosta Erityistä: Haluaisi lisää läpinäkyvyyttä organisaation projekteihin Kalle, 27v tutkija Pikaviestintä Pekka, 37v tutkija Sähköinen työpöytä Oppimis-ympäristö Moodle Tahtoo: kokonaiskuvan organisaatiosta, henkilöhakemiston, esimiesohjeita, yleisiä uutisia, linkit erityissovelluksiin Ei välitä: opiskeluun liittyvistä asioista Mervi, 34v , lehtori Esko, 52v, tutkimusjohtaja

74. 4) Priorisointi ja luokittelu Priorisoidaan laaditut toimintatarinat ja näiden kautta löytyneet tärkeimmät vaatimukset Luokitellaan omat vaatimukset/toiminnot esimerkiksi kolmeen kategoriaan joista ensimmäisessä kategoriassa ovat tärkeimmät toiminnot jotka tuottavat eniten arvoa ja joita ilman ei voisi uutta kokonaisuutta lanseerata Esim. jos tutkimusprojektien tiedonhallinta ja yhteistoiminta todettaisiin olevan ykkösvaatimus, niin lähdettäisiin kartoittamaan mitkä tuotteet markkinoilla vastaavat tähän vaatimukseen

75. 5) Tuotteiden evaluointi Tuotteiden evaluointi tulisi tapahtua toimintatarinoiden kuvaamien käyttötilanteiden kautta Esim. toimittajaa pyydettäisiin näyttämään kuinka Kalle perustaisi tutkimusprojektilleen työtilan ja kuinka hän muokkaisi wiki-sivua ja lisäisi blogiartikkelin projektitilaan Vaihtoehtoisesti tarinat voi itse testata jos saa/voi asentaa tuotteen itselleen testikäyttöön Evaluoinnin aikana on erittäin tärkeätä myös tarvittaessa täydentää toimintatarinoita jos suunnittelutiimi kokee oppineensa uusia asioita!

76. Sopivien tuotteiden löytäminen Pisteytyksen kaava: Annetaan esim. viisi (5) pistettä jokaisesta toiminnallisuudesta jonka toimittajan tarjoama tuote tekee "suoraan paketista" riittävän hyvin. Mikäli toiminnallisuus on omalla listalla ykkösprioriteetin toiminnallisuus, niin kerrotaan pistemäärä vielä esimerkiksi kolmella. Vähemmän tärkeiden toimintojen pisteitä ei kasvateta kertomalla.  Näin saadaan annettua enemmän pisteitä niille tuotteille jotka vastaavat parhaiten tärkeimpiin vaatimuksiin suoraan paketista.

77. Yhteenveto suunnittelusta Tee esitutkimus avoimin mielin Perustele hanke realistisesti Kirjoita kuvaavat käyttäjätarinat Valitse tuote joka ratkaisee tärkeimmät käyttäjätarinat suoraan paketista tai pienimmällä räätälöinnillä

78. Valmistelu ja suunnittelu Konsepti ja toiminnot Esitutkimus Hankesuunnitelma (1 kk) (1-3 kk) (2-4 kk)

79. Järjestelmä- ja toimittajavalinta Tuotteiden arviointi Toimittajan valinta (2-3 kk) (1-3 kk)

80. Harjoitukset Kaksi tehtävää (voi tehdä kummatkin tai valita vain toisen): 1) Laadi esitutkimussuunnitelman runko Kenet haastattelet? Miksi? Muista timanttimalli: ihmiset, roolit, prosessit, dokumentit, teknologiat Valmistaudu esittelemään niiden henkilöiden tehtävänimikkeet jotka valitsit haastateltavaksi 2) Laadi kolme (3) toimintatarinaa Millaiset roolit ja tiedonhallintaongelmat valitset käyttäjätarinoihin? Valmistaudu esittelemään yksi kirjoittamasi toimintatarina. Bonustehtävä: Miten käyttäisit blogeja organisaation sisäisessä viestinnässä? Kenet rekrytoisit kirjoittajaksi organisaatiostasi? Mitä nykyisiä organisaatiosi tehtäviä blogit korvaisivat?

81. Lukuvinkki http://www.steptwo.com.au Australialainen konsulttitoimisto jonka sivustolla intranet-suunnittelua käsitteleviä artikkeleita sadoittain. Joukossa useita kymmeniä todellisia huippuartikkeleita eri aihepiireistä. Esim. ”Seven roles of the intranet homepage”, ”Understanding staff intranet needs”, ”Conducting intranet needs analysis”, ”Selecting staff for stakeholder interviews” Hyvä lähtökohta lukemiseen: http://www.steptwo.com.au/resources/start-here-intranets

83. Haasteita Sähköinen työpöytä -hankkeiden

84. Haaste 1: Toimintakulttuuri Näkökulma tiedon avoimuuteen: Tiedon tulisi olla oletuksena koko organisaation luettavissa ja vasta erityistapauksissa vain tietyn joukon luettavissa.  Tämä näkökulmamuutos on todella suuri haaste useimmille organisaatioille (lue: ihmisille). ”Tiedon rosoistuminen” voi olla erityisesti johdolle suuri pelko joka kohdataan usein esim. blogien ja wikien kohdalla. Metatietoluokituksen määrittely dokumenttikohtaisesti - ja kuinka perustella käyttäjille työstä syntyvät hyödyt? Tiedon elinkaaren määrittely Tiedolle on annettava vanhenemispäivä. Vanheneminen voidaan määritellä dokumenttitasolla tai esimerkiksi sivustotasolla.

85. Haaste 2: Hallitsemattomuus Liian nopea ja pelkästään kokeileva eteneminen tuo paljon riskejä ja ongelmia. Liian nopean etenemisen top-3 riskit: Tiedon siiloutumisen vaara: Liian nopeasti kasvava hanke voi viedä organisaation tiedonhallintakulttuuria jopa taaksepäin. Esimerkiksi termi ”SharePoint-pusikko” ei ole tuulesta temmattu. Käyttäjät vievät vanhat toimintamallit vain uuteen ympäristöön jos koulutukseen ei panosteta riittävästi. Esimerkiksi kansioviidakkoa ja huonoja tiedostonimeämiskäytänteitä vastaan pitää taistella! Kaikki ”uudet tavat” eivät ole organisaation kannalta hyviä! Uuden toimintakulttuurin oppimista pitää seurata. Esimerkiksi ryhmätyösivustojen perustamista pitää hallita tarkasti!

86. Haaste 3: Käytettävyys Lyhyet käyttötilanteet: Haun rooli ja toimivuus korostuu. Haku on ymmärrettävä käyttöliittymänä sisältöihin, sovelluksiin ja verkostoihin. Käyttäjät eivät tule opettelemaan ”missä jokin asia sijaitsee”. Intran perinteinen navigaatio on yhä vähemmän tärkeä. Monet tuotteet on tehty tietohallintoihmisille. Googlen ja Facebookin kaltaista käyttökokemusta on vaikea saada ilman räätälöintiä. Käyttäjille on viestittävä avoimesti tästä haasteesta joka liittyy tällä hetkellä kaikkiin organisaatioiden sisäisiin it-hankkeisiin: käyttäjien odotukset organisaatioiden järjestelmiä kohtaan ovat usein epärealistisia. Lisätietoa esim. http://vierityspalkki.fi/2009/09/17/verkkopalveluprojektien-top-10-haasteet-vuonna-2009/

87. Haaste 4: Halutaan liikaa Selkein merkki strategian puutteesta on, että vaatimusmäärittely kattaa kaiken mahdollisen sosiaalisesta nettiTV:stä aina mobiilisti toimiviin ryhmätyötiloihin ja googlemaisesti toimiviin personoituviin hakutoimintoihin. Todellisuus on, että moni asia kehittyy tällä hetkellä nopeammin kuin mihin tuotteet pystyvät vastaamaan. Esimerkiksi Facebookin kaltaiset toiminnot ovat satojen ohjelmistokehittäjien yhteistyössä tekemiä – vastaavat tulevat organisaatioiden sisälle vasta vuosien päästä.  On panostettava omalle organisaatiolle aidosti tärkeisiin toimintoihin.

88. Haaste 5: Lukitut aikataulut Alustat ovat monimutkaisia ja laajoja kokonaisuuksia. Toimittaja ja asiakas oppivat aina projektin aikana uusia asioita. Paras tapa mahdollistaa oppiminen on soveltaa ketteriä projektimenetelmiä toteutusvaiheessa ja sallia aikatauluista neuvottelu. Tiivistetysti: Tiukat ja joustamattomat aikataulut tuottavat tyytymättömiä käyttäjiä ja huonoa teknistä laatua. Jos aikataulut on pakko lukita etukäteen, niin näihin seurauksiin on varauduttava. Piste.

89. Haaste 6: Osaamisen puute Isoin haaste järjestelmävalinnoissa ja toteutusprojekteissa on, että todella osaavia arkkitehtejä ja sovelluskehittäjiä on yleensä tarjolla aivan liian vähän – ja nekin harvat ovat yleensä ylikuormitettuja. Alustat ovat monimutkaisia ja laajoja kokonaisuuksia joiden oppiminen kestää – erityisesti ”oikeanlainen” räätälöinti on megahaaste. (SharePointin valinta ei ratkaise tätä haastetta.)

90. Haaste 7: Työläät sisältöprojektit Sisältöjen siirto ja uudelleenkäsittely on merkittävä alaprojekti – hyvin harvoin voidaan automaattisesti siirtää muita kuin toisarvoisia sisältöjä Sisältöjen siirto ja uustuotanto tulisi projektoida erikseen Siirrossa kannattaa aina parantaa laatua, uudelleenorganisoida ja tehostaa sisältöjä! Erityisesti jos tekee ”vain” alustan vaihdon.

91. Haaste 8: Wikit vs. intranetit Mikä on wiki? Jos SharePoint-intraan antaisi kaikille oikeudet muokata kaikkia sivuja, niin tulisiko siitä wiki? Avoin tekeminen vs. kontrolloitu tekeminen Ilman hierarkiaa oleva tallennusmalli vs. hierarkian sisältävä tallennusmalli Löysästi kontrolloitu tekeminne vs. prosessiohjattu tekeminen

92. Toteutuksen osa-alueet Sähköinen työpöytä –hankkeen

93. Toteutus, pilotointi ja käyttöönotto Käyttöönotto Toteutus Pilotointi (3-4 kk) (2 kk) (6-12 kk)

94. Toteutusvaiheen tehtäväkokonaisuudet Käyttöönottostrategian ja jatkokehitysmallin valinta Hankeviestinnän suunnittelu Koulutuksien ja käyttöönoton roolien suunnittelu Pilotin sisältö- ja toimintosuunnittelu Metatietomallin suunnittelu Ensimmäisen pilotin toteutus Testauksen suunnittelu ja toteutus Esim. esteettömyyden ja käytettävyyden varmistaminen Palautteen kerääminen ja käsittely Toteutus, osa 1

95. Käyttöönottostrategian valinta 1) Rinnakkaisstrategia Uusi järjestelmä vanhan rinnalla kunnes toimivuus on varmistettu. Haasteena kustannukset ja vaadittavat resurssit. 2) Suoran vaihdon strategia Kustannustehokkain aina, mutta riskikerroin on suuri. Ongelmatilanteissa voi aiheuttaa merkittäviä maineongelmia. 3) Pilottistrategia Joitain organisaation osia käytetään pilottiryhmänä ennen laajempaa lanseerausta. Laajempi lanseeraus tehdään yleensä suoran vaihdon strategialla tai vaiheistetulla strategialla. 4) Vaiheistettu strategia Voidaan vaiheistaa organisaation osien tai tietojärjestelmän ominaisuuksien mukaan. Vaatii paljon ennakkoviestintää.

96. Jatkokehitykseen suhtautuminen Nordheim ja Päivärinta (2006) ovat esittäneet neljä eri tapaa kuinka organisaatio voi suhtautua tietojärjestelmän kehittämiseen: 1) Tavoitekeskeinen malli (perinteinen, ylhäältä johdettu) 2) Evoluutiomainen malli (perinteinen, palautetta seuraava ja pienten parannusten kautta etenevä) 3) Vaiheistettu malli (vahva tiekartta jatkokehitykselle, vahvasti projektoitu, vähän pienkehitystä) 4) Ristiriitojen kautta etenevä malli (reagoidaan vahvasti palautteisiin ja ongelmatilanteisiin, panostuksia kohdennetaan saadun palautteen perusteella voimakkaasti) Ristiriitojen kautta etenevän mallin on esitetty olevan kaikkein kiinnostavin kun kehitetään organisaation laajuisia tiedonhallintatyökaluja. Lähde: Nordheim, S. & Päivärinta, T. 2006. Implementing enterprise content management: from evolution through strategy to contradictions out-of-the-box. European Journal of Information Systems 15(6), 648-662.

97. Hankeviestinnän suunnittelu Aikatauluista ja tavoitteista viestiminen mietittävä huolella Ei kannata viestiä tarkkoja päivämääriä asioista joita ei tiedä. Blogin tai intrauutisoinnin oltava säännöllistä Määrä ei ole niin tärkeätä kuin valitun linjan säilyttäminen Hankkeen esittelytilaisuuksien järjestäminen havaittu tehokkaaksi Kannattaa vaikka tarjoutua esittelemään hanketta eri yksiköiden/osastojen kokouksiin Viestinnässä kannattaa keskittyä nykytilan havaintojen viestintään ja tuleviin toimintatapamuutoksiin Paljon voi saada aikaan pelkällä viestinnällä ja keskustelulla! Esim. sisältöjen ennakkovalmistelu, toimintatapamuutokset, jne.

98. Koulutuksien ja käyttöönoton roolien suunnittelu Koulutuksilla ja käyttöönottovaiheella syytä olla yksi selkeä kontaktihenkilö kaikissa asioissa Erillinen tukipuhelin tarpeellinen isommissa käyttöönotoissa Koulutuksia ja avoimia tukitilaisuuksia kannattaa ketjuttaa ja tarjota silloinkin kun niitä ei erikseen kehdata pyytää Pienenkin organisaation koulutustarve yleensä aliarvioidaan! Toimintatapamuutokset, sisältöprojekti ja uuden työkalun käyttö voi vaatia 3-4 koulutusta per käyttäjä Koulutustarpeita kannattaa tiedustella etukäteen. Usein syytä järjestää täsmäkoulutusta esim. verkkokirjoittamisesta, sähköpostin hallinnasta, projektityöskentelystä, projektinhallinnasta, dokumenttien käsittelystä / tuotannosta, sisäisestä viestinnästä, esimiesviestinnästä

99. Käyttöönoton osa-alueet Sähköinen työpöytä –hankkeen

100. Käyttöönottovaiheen tehtäväkokonaisuudet Toteutus, osa 2 Pilotin kokemusten mukaiset parannukset Metatietomallin tarkentaminen Käytön laajentamisen suunnittelu / pelisääntöjen tekeminen Valmistautuminen laajamittaiseen käyttöönottoon Sisällöntuotantoprojekti Sisältöjen siirtoprojekti Itseopiskelumateriaalien tuotanto (esim. videotutoriaalit) Tukipalveluiden toteutuksen suunnittelu Laajamittainen käyttöönotto Suoralla vaihdolla tai vaiheistetulla strategialla.

101. Sisältösuunnittelu Kolme tyypillistä perusnäkökulmaa sisältöihin: 1) Uusi työntekijä Käytännön asiat, yleinen perehdytys, ongelmatilanteet – usein olemassa jo HR:n toimesta valmis opas jota voidaan käyttää opaskirjana sisältöjen muotoilussa 2) Yksittäiset työsuhdeasiat joissa työntekijä menee intraan ja kirjoittaa hakukoneeseen kysymyksen Esim. ohjeet matkalaskun tekemiseen, vuorotteluvapaan hakemiseen, ylityökäytännöt Esimiehet tyypillinen erityisryhmä joka huomioitava erikseen 3) Liiketoimintatehtäviin liittyvä ohjeistus Esim. projektin perustaminen, reklamaatioiden käsittely, median kanssa toimiminen, lausunnon antaminen, jne. Nämä selvitettävä aina organisaatio- ja toimialakohtaisesti.

103. Opas

104. Palaute

105. HakuOrganisaatio Tietotekniikka Liiketoimintaryhmät Työterveys Johto Matkustaminen Lomat Päätöksenteko Turvallisuus Myynti Virkistys ja liikunta Toimintajärjestelmä Esittelymateriaalit Lomakkeet Dokumenttimallit Matkalaskut Esimiehelle: Rekrytointi Liiketoimintakohtaiset ohjeet Koulutus Esimiehelle: Kriisiviestintä Tyypillisiä sisältöjä Hankinta Ruokalistat Tuotanto

106. Yhteenveto toteutuksesta Paljon erilaisia tehtäviä joista viestintä, koulutukset ja metatietomalli muodostavat tärkeimmät asiakkaan kannalta. Muistettavaa: Toteutusvastuukin on lopulta asiakkaan. Vesiputoushanke on musta laatikko – vaikka vastuu olisi asiakkaalla. Ketterät menetelmät tarjoavat näkyvyyttä ja hallittavuutta.

107. Toteutus, pilotointi ja käyttöönotto Käyttöönotto Toteutus Pilotointi (3-4 kk) (2 kk) (6-12 kk)

108. Ketterän kehittämismallin mahdollisuudet Sähköinen työpöytä -hankkeessa

109. Vaikutukset tekemiseen Ei vaikutuksia vaatimusmäärittelyyn ja konseptisuunnitteluun Myös käyttöliittymäsuunnittelu voi tapahtua ”perinteisesti” Toteutusmalli muuttuu iteratiiviseksi ja ominaisuudet eivät ole lukittuja. Toteutus menee riskit ja arvo edellä.

110. Ketteryyden lähtökohtia Kun ympäristö ja organisaatio muuttuu jatkuvasti, niin isojen hankkeiden toimintoja ja toteutusaikatauluja ei voida lukita useiksi kuukausiksi/vuosiksi (ns. "musta laatikko" -projekti). IT-projektien isoin haaste on edelleen oikeanlaisten tietojärjestelmien toteutuksessa. Projektit epäonnistuvat, koska panoksia ei osata ohjata eniten arvoa tuottaviin kohteisiin. Ketterä kehittäminen antaa näkyvyyttä projektiin ja mahdollisuuksia suunnata kehityspanostuksia asioihin joilla on eniten merkitystä. Ketterä kehittämismalli ei kerro mihin panostukset pitää laittaa, mutta se antaa mahdollisuuden ohjata panoksia parhaan ymmärryksen mukaan.

111. Ketteryyden haasteita Suomessa kourallinen toimittajia jotka osaavat tehdä projekteja ketterästi. Silti kymmenet toimittajat myyvät ketteriä projekteja… Ketteristä prosesseista ei voi ottaa rusinoita pullasta Asiakas ei voi vaatia näkyvyyttä ja vaikutusvaltaa – ja silti lukita ominaisuudet ja aikataulu. Toimittaja ei voi toimia ketterästi ilman jatkuvaa testausta ja integrointia.  Joka on megahaaste isojen, valmiiden tuotteiden kanssa.  Ketteryys vaatii yhtä paljon opiskelua toimittajalta kuin asiakkaalta. Esim. Scrumin perusteet on syytä asiakkaan osata.

112. Sopivimmat kohteet Yli 150 htp:n toteutusprojektit. (?) Mieluiten yli 300 htp kokonaisuudet. Muita kokemuksia? Paljon räätälöintiä. Paljon integraatioita. Paljon asioita joita ei voida tietää etukäteen. Kuulostaako normaalilta it-projektilta? Toisaalta – myös tuotteet, kuten SharePoint, tuovat erittäin paljon asioita joita ei voida tietää etukäteen. Tällöin ketterä toteutusmalli mahdollistaa oppimisen ja reagoinnin.

113. Ketteryyden vaihtoehto? ”Muutospyyntöhelvetti”? … tai tietojärjestelmä joka tekee parhaiten asioita jotka eivät ole kovin merkityksellisiä käyttäjille.

114. Sopimusasiat Toimittajavalinta neuvottelumenettelyn kautta Älä lukitse ominaisuuksia sopimuksessa – vaikka lukitsisitkin kustannukset ja aikataulun. Mahdollista muutokset ja sopimuksen päättäminen aikaisessa vaiheessa mikäli yhteistyö ei suju.

115. Kaksi tapaa ostaa ketterä toteutus 1) Aika & materiaalit Maksetaan tekemisestä suoraan Voidaan ostaa esim. 3kk palasissa Ei motivaatiota toimittajalla parantaa suorituskykyä 2) Tavoitehinta Kummallakin puolella motivaatio parantaa Voidaan myös aloittaa ilman tavoitehintaa ja vaihtaa esimerkiksi 3kk kohdalla tavoitehintaan kun aletaan ymmärtää laajuus

116. Järjestelmävalinta Sähköinen työpöytä -hankkeen

117. Esimerkki Helsingin Kaupunki valitsi SharePoint 2007 alustan. ”Helsingillä on käytössä Microsoftin ea-lisensointi, ja siihen kuuluu näiden ohjelmistojen käyttöoikeus. Tässä vaiheessa tämä on kustannussäästöä verrattuna siihen, että lähdettäisiin johonkin uuteen ohjelmistoon, joka vaatisi ainakin laajempaa koulutusta ja erilaisia tukitoimia.” Lähde: http://www.tietoviikko.fi/kaikki_uutiset/article326004.ece Kuvakaappauksen lähde: Logican sivusto. Googleta esim. ” Logica uudistaa Helsingin kaupungin intranetin”

118. SharePoint 2007 –caseja löytyy verkosta helposti, muutamia poimintoja: Eduskunnan kirjasto http://parlamenttikirjasto.blogspot.com/2009/10/sosiaalinen-media-muuttaa-tyota.html Destian intranet (Digia) ”Google: ”destia intranet digia” Varma intranet (Sininen Meteoriitti) http://www.microsoft.com/finland/business/casestudies/varma09.mspx Keva (Affecto) http://www.itviikko.fi/ratkaisut/2008/06/09/affecto-vie-kevan-verkkopalvelut-sharepoint-pohjalle/200815564/7 VR, Metsäliitto (Tieto) http://www.tieto.fi/default.asp?path=408,410,16094,32517

119. Esimerkki: Työministeriön työhallinto toteuttaa sähköisen työpöydän Liferay+Alfresco –yhdistelmällä. Toteuttajana Ixonos. http://www.ixonos.com/easydata/customers/ixonos/files/pdf_cases/Ixonos_case_Sahkoinen_tyopoyta.pdf

120. Esimerkki Helsingin yliopisto valitsi Oracle WebCenter -kokonaisuuden. Tarkemmin UCM+WebLogic. Toteutus Digia. Lähde: http://blogs.helsinki.fi/ystava-2010/2009/08/28/sahkoinen-tyopoyta-siirtyy-toteutusvaiheeseen/

121. Esimerkki Aalto-yliopiston uusi intranet-alusta tulee olemaan Confluence-wiki. Yksikkökohtaiset intranetit säilyvät toistaiseksi, mutta Confluence tulee yhteisen intranetin alustaksi. Lähde: http://www.hankintailmoitukset.fi/fi/notice/view/2009-024103/

122. Esimerkki Konecranes rakensi sähköisen työpöytänsä IBM:n WebSphere –kokonaisuudella Lähde: http://www-05.ibm.com/fi/solutions/oneball/pdf/Konecranes_Business_Portal_liiketoiminnan_tukena.pdf

123. Sisällönhallintajärjestelmämarkkina Tietojärjestelmätalot lähestyvät sähköistä työpöytää erilaisista kulmista: Dokumenttienhallintalähtöinen näkökulma Yleisin, koska useimmilla järjestelmillä tausta dokumenttienhallintajärjestelmänä. Esim. Documentum, Oracle Universal Content Management System, Microsoft SharePoint, Alfresco Web-sisällönhallintalähtöinen näkökulma Monet kotimaiset julkaisujärjestelmätuotteet, esim. InnofactorPrime, Sinisen Meteoriitin Meteor, Poutapilven P4, CrasmaninCrasManager tai Ch5 Finlandin Navigo. Myös lähes kaikki avoimen koodin julkaisujärjestelmät sijoittuvat tähän sarjaan. Esimerkiksi Drupal, Joomla, eZPublish, LifeRay. Ryhmätyötila- ja yhteistyölähtöinen näkökulma Esim. SharePoint jossa ryhmätyötilat ovat hiottu ja valmis kokonaisuus. Tyypillisimpiä haastajia mm. Alfresco ja Oraclen WebCenterSpaces. Portaalikulma (integraatioalustoja usein käytännössä) Esim. monet Oraclen portaalituotteet (esim. BEAlta ostettu WebLogic), IBM:n WebSphere ja LifeRay. Sosiaalisen vuorovaikutuksen näkökulma Pienemmillä toimijoilla ja wiki-tyyppisillä alustoilla yleinen tulokulma. Esim. Confluence-wiki. Hakutoimintolähtöinen kulma (tulossa)

124. Erottelevia tekijöitä Alusta vs. tuote Alustat: Usein myös ns. perusominaisuudet saattavat vaatia jopa viikkojen koodaustyötä. Mitä enemmän alusta, niin sitä enemmän työtä jokaisen toiminnon käyttöönotto vaatii (vaikka se olisikin ruksattu ns. ”perustoiminnoksi” joka löytyy ”valmiina paketista”). Tuotteet: Pitkälle kehitetyt tuotteet taas yleensä lupailevat liian ruusuisia mahdollisuuksia räätälöintiin. Horisontaalijärjestelmä vs. vertikaalijärjestelmä Sana ECM viittaa usein horisontaalijärjestelmään. Esim. tuotetietojenhallintajärjestelmä tai prosessiohjattu lausunnon laatiminen saattaa taas olla vertikaalijärjestelmä. Rajat hämärtyvät. Pikselintarkka käyttöliittymämuokkaus vs. vahvat käyttöliittymäkäytänteet Esim. SharePoint ja Confluence eivät ole käyttöliittymältään suositeltavia räätälöitäviä. Valmis vs. joustava käyttöoikeusmalli tietosisältöihin ja käyttäjärooleihin Vain isommat ”repository” –tyyppiset tietovarastotuotteet tarjoavat korkeamman tietoturvan ja mahdollisuuden räätälöidä hyvinkin hienojakoisia käyttöoikeuksia. Harvalla organisaatiolla on tarvetta ja rahaa panostaa tällaisiin, mutta eri tuotteiden käyttöoikeusmalleihin kannattaa tutustua, koska eroja löytyy varsin paljon ja näiden asioiden räätälöinti ei yleensä kannata.

125. Esimerkki: SharePoint ja Ribbon-käyttöliittymä

126. Esimerkki: SharePoint Workspace

127. http://download.oracle.com/otndocs/tech/webcenter/files/owcs_r11_spaces_viewlet_swf.html(Oracle WebCenter Spaces, demo)

128. Hankinnassa huomioitava Ekosysteemi maailmanlaajuisesti Millaisia laajennuksia, lisäosia ja valmiita integraatiokappaleita tuotteeseen on saatavilla? Osaajien määrä Suomessa Montako toimittajavaihtoehtoa on Suomessa? Kuinka monta todella osaavaa ohjelmistokehittäjää Suomessa on ko. järjestelmällä? Tuotteen elinkaari Mikä on tuotteen asema markkinoilla? Miten vahva tekijä ko. tuote on sitä toimittavien yrityksien liiketoiminnassa?

129. Esimerkki: SharePoint-kokonaisuus

130. Kolme (3) erilaista ratkaisumallia sähköisen työpöydän alustaksi 1) Yhden toimittajan kaupallinen tietojärjestelmäratkaisu Suomessa vaihtoehtoina mm. Microsoft, Oracle, IBM, Atlassian, (OpenText) ja kotimaiset Googleta ”julkaisujärjestelmät” tai mene suoraan: http://vierityspalkki.fi/2008/03/31/julkaisujarjestelmat-suomessa-markkinakatsaus-2008/ 2) Yhdistelmä/avoin tietojärjestelmäratkaisu Suomessa esim. LifeRay, Alfresco, Drupal (Open Atrium variaatio), eZ Publish, (Joomla), (Plone), (Nuxeo) Avoimen koodin tuotteita voi yhdistää kaupallisiin 3) Räätälöity ratkaisu Esim. perustuen Ruby On Rails tai Django tai Zend –tyyppisiin frameworkkeihin jotka tarjoavat paljon valmiita komponentteja

131. 1) Yhden toimittajan ratkaisu Edut Vähemmän virheitä Referenssejä Tukipalvelut Takuut ja vastuut Valmiit rajapinnat Dokumentaatio Jatkuva tuotekehitys Käyttöönoton nopeus Yleensä halvin vaihtoehto Haitat Jäykkä muutoksille Organisaatio sopeutuu tietojärjestelmään Räätälöinti voi olla jopa mahdotonta Järjestelmä ei välttämättä kehity ”oikeaan suuntaan” Jatkuvat kustannukset päivityksistä Tukipalvelut voivat loppua

132. 2) Yhdistelmä/avoin ratkaisu Edut Yksilöllinen ja vaikea kopioida Voi olla helpompi räätälöidä Toimittajan vaihtaminen yleensä helpompaa Edullista osaamista saattaa olla enemmän tarjolla Valmiita komponentteja saattaa saada verkosta Haitat Jäykkä muutoksille Organisaatio sopeutuu tietojärjestelmään Räätälöinti voi olla vaikeaa Järjestelmä ei välttämättä kehity ”oikeaan suuntaan” Ei virallista tukia (yleensä) Järjestelmän kehitys voi loppua

133. 3) Räätälöity ratkaisu Edut Yksilöllinen ja vaikea kopioida Joustava ja täsmälleen yrityksen tarpeisiin soveltuva Uusien toimintamallien ja prosessien mahdollistaja Haitat Onko saatavilla riittävät tukipalvelut? Hidas rakentaa Integroiminen muihin järjestelmiin voi olla vaikeaa Testaus vaatii erityispanostuksia Dokumentoinnin taso voi olla puutteellinen Jatkokehitystyö kohtuullisen kallista

134. Yleiset vaatimukset Tietohallinnon kannalta usein tärkeitä selvitettäviä ovat myös tekniset vaatimukset, kuten palvelinvaatimukset, tuotteen tietokantaratkaisu, tuotteen räätälöitävyys ja liitettävyys muihin järjestelmiin. Viimeisimpänä kategoriana yleensä tarkastellaan kokonaiskustannuksia esimerkiksi seuraavien näkökulmien kautta: Yleiset hinnoittelu- ja lisensointiperusteet Lisenssimaksu per käyttäjä Lisenssimaksu per palvelin Arvioidut projektikustannukset määritellylle palvelulle mikäli määrittely/konsepti jo tiedossa Muut käyttöönottokustannukset (ulkopuoliset lisenssit ym. palvelinvaatimukset) Ylläpitomaksu per käyttäjä per vuosi Ylläpitomaksu per palvelin per vuosi Muut toistuvat kustannukset

135. Yhteenveto teknologioista SharePoint hallitsee, koska pystyy yhdistämään suljettujen ja avointen tuotteiden etuja Toisaalta kilpailu on veristä ja ostajan kannalta markkina on kiinnostava Isoin haaste on, että tulevaisuutta on vaikea ennustaa. Täten valinta kannattaa tehdä vahvasti oman nykytilanteen vaatimuksilla!

136. Loppusanat Tee esitutkimus avoimin mielin Kirjoita kuvaavat käyttäjätarinat Valitse tuote joka ratkaisee tärkeimmät käyttäjätarinat suoraan paketista tai pienimmällä räätälöinnillä Toteuta iteratiivisesti tuotteen ominaisuuksia testaten ja arvioiden Panosta metatietomallin suunnitteluun Laajenna käyttöä hallitusti Panosta koulutukseen ja viestintään