Sovellussalkku. Thinking Portfolio White Paper SISÄLTÖ

Transkriptio

1 Thinking Portfolio White Paper Sovellussalkku SISÄLTÖ 1 Projektisalkku -strategisen tason johtamisväline 2 Salkunhallinta 4 Thinking Portfolio -päänäkymät 5 Sovellussivut ja widgetit 9 Raportointi 11 Mukauttaminen 12 Käyttöönotto ja käyttö

2 Thinking Portfolio strategisen johtamisen väline Thinking Portfolio on strategisen tason johtamisen käytännön työväline. Salkunhallintamalli tukee liiketoimintalähtöistä, kokonaiskuvaan perustuvaa suunnittelua ja päätöksentekoa. Kehitystyön lähtökohtana ovat olleet projektityön ja salkunhallinnan kansainväliset viitekehykset kuten PRINCE2 ja PMBOK. Thinking Portfolio hyödyntää lisäksi toimialariippumattomia liiketoiminnallisten hyötyjen ja kypsyyden määrittelymalleja. Ottamalla käyttöön Thinking Portfolion organisaatio saa valmiudet nopeaan päätöksentekoon, ketterään muutoshallintaan, liiketoimintalähtöisyyteen sekä riskien analysointiin. Thinking Portfolion visuaalinen esitystapa sekä selainpohjainen käyttöliittymä helpottavat sen omaksumista. Järjestelmän käyttö ei edellytä teknisiä kursseja tai käsikirjoja. Thinking Portfolio on kehitetty hyödyntämällä viimeisintä Web-teknologiaa. Selainliittymä toimii mm. Internet Explorer-, Firefox- ja Safari-selainten uusimmilla versioilla, myös tableteissa. Tekninen ratkaisu mahdollistaa erilaisten salkunhallinnan sovellusten toteuttamisen. Tässä julkaisussa esitellään uudistunut sovellussalkku, joka on tarkoitettu IT-sovellusten ja -palveluiden johtamisvälineeksi. Uudistunut käyttöliitymä S3 1

3 Salkunhallinta ideat, projektit ja omaisuus Salkkujen käyttäminen johtamisen välineenä on vielä melko uutta. Sen tarkoituksena on tuoda johtamiseen ja päätöksentekoon johdonmukaisuutta, tehokkuutta ja läpinäkyvyyttä. Miksi salkunhallintaa tarvitaan? Laajojen ja monitahoisten organisaatioiden johtamista vaikeuttavat asiakasvaatimusten ja -odotusten ristiriitaisuus, tiedonkulun ongelmat ja osaajapula. Tuloksena on päällekkäisiä ja samoista resursseista kilpailevia hankkeita, joiden ajoitusta tai sisältöä ei ole mitenkään optimoitu. Tekemisen linkki ydintoiminnon strategiaan on usein epäselvä. Salkunhallinta on toimintamalli, joka yrittää vähentää nopearytmisen ja moniulotteisen johtamisen ongelmia. Se luo toiminnalle puitteet, jotka parhaimmillaan tehostavat valmistelua, päätöksentekoa ja toteutusta (Kuva 1). Johtamissalkkuja on kolmea päätyyppiä (Kuva 2): 1 - Kehittämissalkku sisältää kuvaukset organisaation tulevaisuuteen tähtäävistä kehittämisehdotuksista, ideoista ja skenaarioista (esim. kehittämis-ohjelmat). 2 - Projektisalkku sisältää käynnistystä odottavia, käynnistyneitä ja valmistuneita hankkeita ja niihin kuuluvia projekteja. 3 - Omaisuus- tai resurssisalkku sisältää esim. sovelluksia, osaamista tai prosesseja, joita organisaatio on saanut käyttöönsä kehittämishankkeilla ja investoimalla. Salkut kytkeytyvät toisiinsa: Projektisalkkuun tulee perusteltuja projektiehdotuksia kehittämissalkusta. Projektisalkku tuottaa omaisuutta. Omaisuuden vanheneminen tai huono suorituskyky saavat aikaan kehittämistarpeita jne. Salkunhallinta koostuu tiedosta, prosesseista ja rooleista. Salkut ovat määrämuotoinen tapa kuvata resursseja ja hankkeita, joilla organisaatio toteuttaa strategiaansa. Hankesalkkujohtamisen periaatteet Kuva 1. Salkunhallinnan periaatteet Johdetaan ydintoiminnon strategian mukaisesti Johdetaan kokonaisuutta Arvotetaan yhdenmukaisin kriteerein Yhteinen liiketoimintakäsitteistö ja hallintatapa Prosessi ja viitekehys Työvälineet 2

4 Liiketoimintastrategia Kuva 2. Salkut Kehittämissalkku Omaisuussalkku Projektisalkku (Hankesalkku) Toiminnan kehittämisen ja investointiprojektit Tutkimukset, ideat, skenaariot Infrastruktuuri, sovellukset, data, ihmiset, prosessit Nykyhetki Lähitulevaisuus Operatiivinen toiminta Pitkä tähtäin Salkkujohtamisen periaate Salkkujohtamisessa on yksinkertaisimmillaan kysymys tuoton, panostusten ja riskien hallinnasta ja tasapainottamisesta. Tuotto voi olla esim. kustannus-säästöä, tuottavuuden kasvua, uusien asiakkuuksien syntymistä tai liikevaihdon kasvua. Panostuksia ovat paitsi investoinnit, myös ajan ja rahan käyttämistä mm. projektityöhön, koulutukseen, käyttöönottoon ja ylläpitoon. Projektiriskejä on monia, mutta myös olemassa olevaan omaisuuteen liittyy riskejä, esim. ICT-sovellusten tai järjestelmien skaalautuvuus liiketoiminnan kasvussa tai supistumisessa. Salkkujen kytkentä strategiaan ja arkkitehtuuriin Salkut kytkeytyvät organisaation strategiaan kriteerien ja luokitusten kautta. Johto määrittää strategian menestystekijät ja avaintulokset, jotka se kuvaa salkkuihin erilaisina kriteereinä. Kriteerit arvottavat idean, projektin tai sovelluksen strategiasta käsin. asiakkuustietojärjestelmä voisi tukea hyvin organisaation strategiaa, mutta se saattaisi olla ristiriidassa nykyisen sovellus- ja teknologia-arkkitehtuurin kanssa. Salkunhallinnan menestystekijät Salkunhallinnan käyttöönotto voi olla projekti, mutta sen saaminen osaksi organisaation arkea vaatii määrätietoista sitoutumista ja omaa esimerkkiä johdolta. Salkunhallinta on liitettävä osaksi organisaation johtamista, esim. johtoryhmätyöskentelyä. Organisaation kypsyystasolla on merkitystä salkunhallinnan onnistumiselle. Jos johtamisessa tai projektitoiminnassa on merkittäviä puutteita, salkunhallinta jää ilman perustaa. Salkuista ei ole hyötyä, jos organisaatiolta puuttuu kyky toimia niiden edellyttämällä tavalla. Salkunhallinta vaatii tuekseen työvälineitä. Välineet eivät tässäkään tapauksessa ole ratkaisu, vaan ne tukevat ajattelutavan muutosta. Salkuissa on tärkeää tunnistaa hankkeen tai omaisuuden vastaavuus liiketoiminta-, tieto-, sovellus- ja teknologia-arkkitehtuuriin. Esim. tietty uusi 3

5 Thinking Portfolio päänäkymät Sovellusluettelo Sovellusluettelo on yleisnäkymä salkkuun (Kuva 3). Se näyttää sovellukset, joiden tietoihin käyttäjällä on katselu- tai muokkaus-oikeus. Värikoodatut kentät osoittavat yhdellä silmäyksellä esim. sovellusten SLAluokan ja prioriteetin tai kriittisyyden. Otsikkorivi mahdollistaa luettelon järjestelyn tai suodatuksen valittujen kriteerien mukaisesti. Sovellukset järjestyvät esimerkiksi kriittisyyden tai omistajan mukaan yhdellä klikkauksella. Käyttäjä pystyy lisäksi suodattamaan näkyviin vain häntä kiinnostavat sovellukset usean yhtäaikaisen kriteerin mukaisesti. Tehdyt valinnat ovat voimassa vaikka käyttäjä poistuisi välillä sovelluksesta. Aika Aikanäkymä visualisoi sovellusten elinkaaren tärkeät päivämäärät, esim. versiopäivitykset ja erilaiset auditoinnit. Laatu Thinking Portfolion laatusivu kuvaa värikoodien avulla kuinka kattavaa ja ajantasaista tietoa salkussa olevista sovelluksista on saatavana. Kuva 3. Salkun päänäkymät: sovellusluettelo, aika- ja laatunäkymät 4

6 Sovellussivut ja widgetit esimerkkejä Kuva 4. Sovelluskortti Sovelluskortti ja widgetit Jokaista sovellusta tai palvelua koskevaa tietoa ylläpidetään ns. sovelluskortilla (kuva 4). Se koostuu välilehdistä, jotka jäsentävät tiedon eri näkökulmiin. Välilehdet sisältävät widget-paneeleja, jotka ryhmittelevät tiedon visuaalisesti ja loogisesti. Seuraavassa on esimerkkejä tyypillisistä widgeteistä. Liiketoiminnallinen asemointi Sovelluksen asemointi määrittää sovelluksen liiketoiminnallisen merkityksen. Asemointiin käytetään nelikenttää (kuva 5): Tukisovellukset tuottavat liiketoiminnallista arvoa välillisesti. Ne eivät ole kriittisiä toiminnan jatkuvuuden kannalta. Niiden määrää ja niiden tuottamia kustannuksia on pyrittävä minimoimaan. Liiketoimintakriittiset sovellukset ovat operativiisia välttämättömyyksiä, joiden jatkuvuus ja toimintavarmuus ovat tärkeitä. Kuva 5. Liiketoiminnallinen asemointi 5

7 Strategiset sovellukset ovat niitä, jotka tuottavat yritykselle kilpailuetua nyt ja lähitulevaisuudessa. Niitä on pyrittävä vahvistamaan ja kehittämään edelleen, jotta etumatka säilyisi. Potentiaaliset sovellukset ovat mahdollisia tulevia kilpailuvaltteja, mutta eivät ole vielä laajamittaisessa käytössä. Sovelluksen asema palveluarkkitehtuurissa Widget (kuva 6) kuvaa miten sovellus tukee organisaation palveluita (rivit) ja yksiköitä (palstat; esim. konserni ja eri liiketoimintayksiköt). Käyttäjä klikkaa matriisissa olevia valintaruutuja, jolloin syntyy linkki ao. palveluun ja organisaatioon. Kuva 6. Sovelluksen asema palveluarkkitehtuurissa Kuva 7. Sovelluksen kriittisyys ja riskianalyysi Palvelu- ja organisaationimikkeet määrittelemme aina asiakaskohtaisesti. Kriittisyys ja riskit Sovelluksen riskinhallinnan kannalta on tärkeää hahmottaa sovelluksen kriittisyys ja riskilähteet. Tämä widget esittää graafisesti kuinka hyvin sovellukseen liittyvät riskit on hallittu suhteessa kriittisyyteen (kuva 7). Riskitason määritys sisältää oletusarvoina seuraavat kuusi näkökulmaa: 1. Käytön henkilöriskit 2. ICT-henkilöriskit 3. Informaatioriskit 4. Tekniset riskit 5. Toimittajariskit 6. Jatkuvuusriskit Käyttäjä määrittää niiden tasot omaan ikkunaansa avautuvalla lomakkeella, joka sisältää arviointiväittämät. Widget määrittää kriittisyystason automaattisesti Liiketoiminnallinen asemointi -widgetin tiedoista. 6

8 Vaatimustenmukaisuus Sovellusten ja palveluiden kyky vastata liiketoiminnan, käyttäjien ja teknisiin vaatimuksiin muuttuu ajan kuluessa. Koska eri osapuolilla voi olla erilaiset käsitykset vaatimusten täyttymisestä sama widget on esitetty sovelluskortissa kunkin osapuolen omalla välilehdellä (kuva 8). Widgetin asteikko on neliportainen. Lisäksi tässä, kuten muissakin widgeteissä, käyttäjä voi tarkentaa arviotaan kirjoittamalla lyhyen kommentin widgetin muistiinpano-kortille. Se avautuu klikkaalla oikeassa alanurkassa olevaa nuoli-ikonia. Jos widgetiin liittyy muistiinpano, ikonin nuoli muuttuu huutomerkiksi, kuten esimerkkikuvassa. Muutostarve Edellä kuvattujen widgetien tieto auttaa hahmottamaan sovelluksen tai palvelun muutostarvetta. Sen viestintään on tarkoitettu Muutostarve-widget (kuva 9). Widget muodostuu nelikentästä, jonka ulottuvuuksia ovat Liiketoiminta-arvo ja Toiminnallinen/tekninen laatu. Käyttäjä arvioi sovelluksen nykytilan näistä näkökulmista ja sijoittaa punaisen indikaattorin oikealle kohdalleen. Tämä sinänsä yksinkertainen arvio tuottaa mielenkiintoisen yhteenvedon kun kaikkien sovellusten tilanne raportoidaan. Kuva 8. Sovelluksen vaatimustenmukaisuus Kuva 9. Sovelluksen muutostarve Kuva 10. Sovelluksen liittymät ja niiden kriittisyys 7

9 Liittymät ja niiden kriittisyys Harvat tietojärjestelmät ovat enää saarekkeita. Liittymät-widget (kuva 10 edellisellä sivulla) auttaa kuvaamaan tietyn sovelluksen liittymät toisiin järjestelmiin. Liittymää kuvaavaa tietoa on mm. onko liittyvä järjestelmä sisäinen vai ulkoinen, mikä liittymän kriittisyys on, ja mihin suuntaan data liitoksessa siirtyy. Aikataulut Sovellukseen liittyy erilaista aikasidottua tietoa. Aikatiedon kirjaamiseen on oma widgetinsä (kuva 11). Sen avulla käyttäjä voi määritellä erilaisia tapahtumia, kuten versio-päivityksiä tai kehityskeskusteluja, joita tietohallinto käy sovelluksen omistajan kanssa. Päivämäärät ja tapahtumakuvaukset tallentuvat päiväkirjaan (kuva 12). Taloustiedot Menovirta-widget (kuva 13) kuvaa sovelluksen elinkaaritaloutta. Näkymässä on eritelty viiden vuoden kulutiedot, mutta widget pystyy tallentamaan tiedot pidemmältäkin jaksolta. Muita widgettejä Muilla widgeteillä hallitaan mm. käyttäjä- ja ylläpitäjätietoja, sopimustietoja ja sovelluksen palvelimien tietoja (kuva 16). Kuva 11. Tapahtumien tallennus Kuva 12. Päiväkirja Kuva 13. Sovelluksen tai palvelun menovirta 8

10 Raportointi - näkymät salkkuun Thinking Portfolio -raportit kiteyttävät johdolle salkun nykytilanteen ja tulevaisuuden. Jokaisesta sovelluksesta on tulostettavissa ns. Järjestelmäkirja (kuva 14). Se sisältää yhdessä raportissa kaikki sovelluksesta tallennetut tiedot. Raporttien sisältö ja esitystapa riippuvat käyttötarkoituksesta, ja siksi määrittelemme raportit aina asiakaskohtaisesti. Esimerkkeinä salkunhallinnan muista mahdollista raporteista ovat mm. Sovelluskartta (kuva 15) Vaatimustenmukaisuus (kuva 16) Vastuuhenkilöt ja roolit (kuva 17) Toiminta- järjestelmäarkkitehtuurikartta (kuva 18) Päiväkirja (toimenpiteet ja tapahtumat salkkutasolla) Kuva 14. Järjestelmäkirja, ote 9

11 Raportointiesimerkkejä Kuva 15. Sovelluskartta, joka kuvaa valitun sovelluksen liittymät, niiden tyypit ja kriittisyyden Kuva 16. Sovellusten suorituskykyarviot Kuva 17. Vastuuhenkilöt ja roolit eri sovelluksissa Kuva 18. Toiminta- ja järjestelmäarkkitehtuurikartta 10

12 Mukauttaminen - asiakaskohtainen tietomalli Mukauttaminen Thinking Portfolio mukautuu asiakkaan salkunhallinta-prosesseihin ja -käsitteistöihin. Käyttöliittymä voi olla suomentai englanninkielinen. Thinking Portfolio tietokanta-rakenne on käsiteriippumaton ja parametroitava. Erilaisten käyttöliittymässä näkyvien luettelo-kenttien ylläpitoon on työkalu, jolla asiakas voi muokata niitä itse (kuva 19). Eri salkkumallit Sovelluksen tietokantaratkaisu on tehty joustavaksi. Asiakaskohtainen räätälöinti tai uusien widgetien käyttöönotto ei edellytä tietokannan rakenteen muuttamista. Rakenneratkaisunsa ansiosta sovelluksen asiakaskohtainen mukauttaminen Proof of Concept -projektissa on nopeaa. Kuva 19. Valintalistojen arvojen muokkaus ja väritys Kuva 20. Esimerkki sovellussalkun ICT-välilehdestä 11

13 Käyttöönotto ja käyttö Käyttöliittymä Thinking Portfolio on täysin selainkäyttöinen sovellus. Se toimii uusimmilla IE- (6 tai uudempi), Firefox- ja Safari-selaimilla sekä ipad- ja iphone-safarilla. Käyttäjähallinta Thinking Portfolion käyttöoikeudet määritellään roolipohjaisesti (Kuva 21). Rooleja voivat olla esim. CIO, pääkäyttäjä, järjestelmävastaava jne. Roolinimikkeistö määritellään asiakaskohtaisesti. Salkulla on yksi tai useampi ylläpitokäyttäjä, jolla on laajimmat oikeudet esim. uusien sovellusten perustamisoikeus. Ylläpitokäyttäjä voidaan nimetä koko salkulle tai esim. tietyn liiketoimintayksikön salkulle. Kirjauduttuaan järjestelmään käyttäjä saa roolinsa mukaan joko vain selata ja raportoida tai muokata tiettyjä sovelluksen tietoja. Käyttäjätunnistus Sovellus tukee kahta eri käyttäjien tunnistustapaa: Windows-tunnistusta ja sisäistä käyttäjätunnus-salasana -tunnistusta. Windows-tunnistuksessa järjestelmän käyttäjänimi on sama kuin ActiveDirectoryssä. Perinteisiä käyttäjätunnuksia voidaan käyttää esim. silloin, kun sovelluksella on ulkopuolisia Internet-käyttäjiä. Liittymät ulkoisiin järjestelmiin ThinkLink Thinking Portfolioon on rakennettavissa liittymiä ulkoisiin järjestelmiin, esimerkiksi laitteistojen hallinnan tai dokumenttienhallintajärjestelmiin. Ratkaisut toteutetaan Web Services-teknologialla (SOAP Interface). Sovelluksen tekstialuekenttiin kirjoitetut URL-osoitteet esim. dokumentteihin muuttuvat automaattisesti hyperlinkeiksi. Palvelumallimme Thinking Portfolio tarjoaa vaivatonta hosting-ratkaisua yhteistyössä Crescom Oy:n kanssa. Tällöin asiakkaan ei tarvitse asentaa mitään sovelluksen osia omaan ympäristöönsä ja käytössä on aina tuorein versio sovelluksesta. Käyttö ja ylläpito hoituvat selaimella SSL-suojattua yhteyttä pitkin. Myös Kuva 21. Roolikohtaistan käyttöoikeuksien hallinta 12

14 käytön rajaaminen vain tiettyihin IP-osoitteisiin on mahdollista. Palvelumalliin sisältyy puhelin- ja sähköpostituki asiakkaan pääkäyttäjälle. Proof of Concept Suosittelemme asiakkaille nopean Proof of Concept -projektin (PoC) toteuttamista kanssamme. Muutaman työpalaverin jälkeen toteutamme asiakaskohtaisesti mukautetun sovelluksen, joka on käytettävissä palvelimeltamme yhden kuukauden koekäytön ajan. Yhteystiedot Esa Toivonen Puh esa.toivonen(at)thinkingportfolio.com Aarni Heiskanen Puh aarni.heiskanen(at)thinkingportfolio.com Thinking Portfolio Aleksanterinkatu 15 B Helsinki 13

15