Tuntikirjaus – aika ei ole vain rahaa

Oikein ja oikea aikaisesti hyödynnetty osaaminen ja tyytyväinen työntekijä tuovat kilpailuedun. Lisäksi on muitakin hyviä syitä suunnitella ja seurata sitä, mihin tehtäviin päivän työtunnit kohdistuvat. Näin luodaan edellytykset sille, että organisaation henkilöstössä oleva pääoma saadaan hyödynnettyä kaikkien yhteiseksi eduksi ja ennen kaikkea edistetään työhyvinvointia ja työtyytyväisyyttä.

Tuntien kirjaus ilman niihin liittyvää suunnitelmatietoa palvelee tilanteessa, jossa tunnit laskutetaan, niihin liittyviä sisäisiä kustannuksia järjestellään organisaation sisällä ja/tai tuotekehitystyön kustannuksia aktivoidaan taseeseen.

Tuntien kirjaus yhdistettynä suunnitelmatietoon ja organisaation tiedossa oleviin kyvykkyyksiin kantaa jo huomattavasti pidemmälle. Tarkka työtehtävä- ja päiväkohtainen toteutumatieto tarjoaa luotettavan lähtökohdan organisaation suorituskyvystä kertovien mittareiden toteuttamiseen ja toiminnan kehittämiseen. Alla on joukko tärkeitä asioita, joissa menestyminen edellyttää luotettavaa tietoa siitä, millaiseen tekemiseen organisaation käytettävissä olevat työtunnit ja osaaminen ovat kohdistuneet.

  1. Perinteisissä projektien toimitusmalleissa suunnitteluvaiheessa täsmennetään tavoitellut tuotokset ja näiden aikaansaamisen edellyttämät työmäärät. Tuntitoteumien seuranta varmistaa sen, että poikkeamia voidaan analysoida ja niihin voidaan reagoida välittömästi.
  2. Suunnitelmallisen toteutustyön perustana on mahdollisimman realistinen aikataulu, resurssi- ja kustannussuunnitelma. Luotettavimmin tämä toteutuu, jos suunnitelmat nojaavat kokemusperäiseen tietoon. Toteutumatiedot aiemmista hankkeista ennaltaehkäisevät virheitä myynnissä ja takaa projektipäällikölle oikean määrän ja oikea aikaisesti sopivia resursseja projektin käyttöön.
  3. Tuntitoteutumat tarjoavat yksityiskohtaista tietoa organisaation laatumittareihin. Tärkeää on se, että työ kohdentuu lopputulosten saavuttamiseen, mahdollisten virheiden ennaltaehkäisyyn tai näiden korjaamiseen varhaisessa vaiheessa ja kerralla. Reagointia tarvitaan, jos virheitä korjaavan tai muu lopputuloksen saavuttamista vähän hyödyttävän työn osuus kasvaa trendinomaisesti. Sopivilla tuntikirjauskohteiden luokittelutiedoilla saadaan arvokasta analyysitietoa Lessons Learned/Retrospective tapahtumiin toiminnan kehittämiseksi ja laadun parantamiseksi.
  4. Tiimin jäsenten työkuorman seuranta kokonaisuutena on yksi tiimistä vastaavan henkilön tärkeimmistä tehtävistä. Kuormituksen ja käytettävissä olevan kapasiteetin kohtaamisen jatkuva optimointi edellyttää luotettavaa tietoa siitä, mihin käytettävissä olevat tunnit ovat kohdistuneet ja millaisia poikkeamia on verrattuna suunnitelmaan. Lähiesimiehen tulee erityisesti kiinnittää huomiota avainresurssien kuormitukseen hankkeiden ylitse sekä uusien tiimin jäsenten osaamisen kasvattamiseen sopivan haasteellisissa työtehtävissä.
  5. Projektipäällikön vahva henkilökohtainen näkemys projektinsa tilasta ei aina riitä. Viestintä projektin sidosryhmille tulee olla objektiivista, uskottavaa ja läpinäkyvää. Tämä onnistuu vain, jos viestinnän lähtökohtana oleviin tietoihin voidaan luottaa ja tiedot ovat jäljitettävissä. Luotettavin tieto syntyy niistä yksityiskohtaisesta toteutumatiedosta, jota projektin jäsenet osaltaan tuntiraportoinnin kautta kerryttävät.
  6. Hyvin toteutettu kirjausjärjestelmä tuo käyttäjälleen tarjolle ne työtehtävät, joihin hänen tulee kulloinkin keskittyä. Työt tulevat näin tehtyä kerralla, nopeammin ja laadukkaammin. Tuntikirjaus vähentää samanaikaisesti tehtävien töiden määrää ja auttaa kohdistamaan huomin oleelliseen. Työnkulkuun saadaan kaivattu imu joka kasvattaa työtehoa ja tekijöiden motivaatiota.
  7. Työmäärien vaihtelu, pitkät työpäivät, ylikuormitus, kiivas työrytmi ja muut työn hallintaan liittyvät ongelmat altistavat työuupumukselle. Tuntikirjaus nostaa tuntikirjaajan tietoisuutta siitä mihin työpäivän tunnit kuluvatkaan. Tietoisuus omasta työkuormasta ja työtehtävien prioriteeteista ovat oiva selkänoja sanoa kaikelle sellaiselle ei, joka tarpeettomasti kasvattaa päivän aikana tehtäviä tunteja sekä kyllä kaikelle tavoitteelliselle, tuottavalle ja motivoivalle tekemiselle.
  8. Hälyttävää on, jos henkilön tuntikirjausnäkymässä on paljon kirjauskohteita pienillä päivittäisillä tuntimäärillä. Usean työtehtävän samanaikainen suorittaminen ja vaihtaminen näiden välillä ei edistä tavoiteltua tuottavuuden kasvua. Tuntikirjausjärjestelmään kirjatut tiedot nostavat esiin piilossa olevan työn, töiden hallinnan ja priorisoinnin ongelmat sekä auttavat puuttumaan tilanteeseen välittömästi.
  9. Henkilöiden työtuntikertymät ovat vakioaihe viranomaisen suorittamassa työsuojelutarkastuksessa. Työtuntien seurantaa tulee tehdä jo lainsäädännön vaatimuksesta. Kattavasti käyttöön otettu tuntikirjausratkaisu täyttää tämän tarpeen. Järjestelmän on mahdollista myös tukea joustavia työn tekemisen malleja saavutettavuudellaan ja saldokertymien laskennalla.

Projektien ketteriin toimitusmalleihin liittyen esitetään, että tuntikirjaus on ainakin ei –toivottua jollei kokonaan tarpeetonta. “Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest”. Eli keskeiset seurattavat asiat ovat arvio jäljellä olevasta työmäärästä ja valmistumisajankohdasta. Merkittävää kuitenkin on, että monet edellä kuvatuista asioista ovat hyvin ajankohtaisia ja tarpeellisia myös ketterissä toimitusmalleissa.

Selvää on, että tuntien kirjauksen edut saavutetaan kattavasti vain, kun se on osa keskitettyä projektien, töiden ja kapasiteetin hallinnan tietojärjestelmää. Tarkkuutta, kattavuutta ja luotettavuutta tuntikirjaukseen on mahdollista tuoda järjestelmään toteutettavilla rajapinnoilla. Esim. henkilötietojen, lomatietojen ja käytettävissä olevien työtuntimäärien tuominen HR järjestelmästä tukee kapasiteettihallintaa. Jos organisaation kaikki työtunnit kohdistetaan ulkoisille ja/tai sisäisille asiakkaille on osoittautunut hyvin kannattavaksi tuottaa kulunvalvonnasta päiväkohtaiset läsnäolotunnit kirjaajan tiedoksi. Näin varmistetaan kaikkien asiakastuntien päätyminen kohdistettavaksi ja laskutukseen.

Ota yhteys, jos mielenkiitosi heräsi käyttäjäystävälliseen, helposti lähestyttävään ja integroituvaan tuntikirjausjärjestelmään, joka toimii myös luontevana osana kattavaa projektien-, töiden- ja resurssien hallinnan tietojärjestelmää.

Microsoft Project for the Web – visiosta kehittyväksi pilvipalveluksi

Kirjoitimme ensimmäisen kerran Microsoftin suunnitelmista tuoda markkinoille uusi vain pilvialustalla toimiva projektiohjelmisto alkuvuodesta 2019. Seuraavassa tarkastellaan mitä sen jälkeen on tapahtunut ja mihin suuntaa ohjelma kehittyy.

Lähtökohtia

Projektinhallinnan kirjo on kasvanut ja monipuolistunut. Ketterät menetelmät ovat tulleet useille toimialoille johtaviksi menetelmiksi. Toisaalta samaan aikaan useilla aloilla edelleen käytetään perinteisiä projektinjohtamisen menetelmiä, kuten vesiputousmallia, kriittisen polun menetelmää, tuloksen arvon menetelmää. Projektijohtamisesta on tullut yleisempää ja se on levinnyt uusille toimialoille. Projektipäällikkyys saattaa osua kenen tahansa työntekijän kohdalle, ei enää ainoastaan projektipäälliköiksi kouluttautuneille.

Pilvipalvelut ovat Microsoftin, kuten monen muunkin IT-alan toimijan, menestyksen avain.

Nykyaikaisten välineiden tulee olla helposti saatavilla ja käyttöönotettavia myös satunnaiselle käyttäjälle. Niiden avulla pitää saada hyötyjä nopeasti ja niiden pitää soveltua erityyppisiin projektimetodologioihin.

Laajan käyttäjäkunnan ja kumppaniverkoston kokemus MS Projectista antoi Microsoftille mahdollisuuden kerätä tiedot siitä, millainen hyvän projektihallintavälineen pitäisi olla. Project Onlinen käyttäjät ovat antaneet paljon kehitysideoita tuotteen kehittämiseksi ja paljon niitä on toteutettu Project Online / Project Server -tuotteeseen. Kuitenkin monipuolisuus saattaa joskus olla hyvän käytettävyyden vastakohta.

Edellä mainitut seikat ovat olleet lähtökohtia Project for the Webin kehitykselle.

Project for the Web

Project for the Webin ensimmäinen versio julkaistiin keväällä 2019. Nyt on hyvä hetki pysähtyä ja tarkastella mitä on tapahtunut noin kahden vuoden aikana ja mitä on tulossa.

Ensimmäinen versio keskittyi tehtävien ja niiden välisten riippuvuuksien luomiseen mm. Gantt-kaaviossa käyttämällä selainta. Ainoa keino tuottaa tehtäväluettelo oli naputella se alusta asti järjestelmään käsin. Malliprojekteja tai projektien kopiointia ei ollut, ei ollut myöskään import-toimintoa. Tehtäviin oli kolme näkymää: Gantt-, Kanban- ja luettelonäkymä. Ohjelmalla pystyi toteuttamaan aikatauluhierarkian ja tehtäville oli mahdollista allokoida resursseja, tosin ainoastaan siten, että henkilö oli varattu tehtävälle kokoaikaisena ja koko tehtävän kestolle. Projektille pystyi luomaan dokumenttityötilan samalla kertaa, kun luo projektin. Käyttöliittymän muokkaaminen ja omien kenttien lisääminen ei ollut mahdollista. Lähtötilanteesta on menty eteenpäin useita isoja kehitysaskelia.

Tällä hetkellä kaikki edellisessä kappaleessa mainitut rajoitukset ovat poistuneet, tehtäville voi allokoida resursseja osa-aikaisena, tehtävätietoihin voi lisätä omia kenttiä, projektin pohjaksi voi kopioida toisen projektin tai tuoda tiedot MS Project suunnitelmasta, tietoja voi viedä Exceliin tai tulostaa pdf-tiedostoksi, liittää dokumenttilinkin tehtävälle, aktivoida sähköpostimuistutukset tietyistä asioista ja monta muuta isompaa ja pienempää uutta toimintoa tai parannusta. Tällä hetkellä Project for the Webin voi myös liittää Teams-sovellukseen, jolloin kaikki projektihallintaan tarvittavat välineet ovat samalla työpöydällä.

Keväällä 2021 Microsoft julkaisi Power Apps -sovelluksen nimeltä Accelerator. Se laajentaa Project for the Web-sovellusta projektisalkkuihin, ohjelmiin ja riskien hallintaan. Ne käyttäjät, jotka ovat tottuneet Power Apps-sovellusten rakenteeseen oppivat käyttämään Accelerator -sovellusta nopeasti. Tästä kirjoitimme kevään 2021 blogissamme.

Mitä uutta on tulossa?

Viime viikolla Microsoft piti tilaisuuden kumppaneille, jossa se valotti suunnitelmiaan Project for the Web-tuotteen seuraavista askelista. Suunnitelmat voidaan jakaa karkeasti kahteen osaan: Lähiajan suunnitelma ja ehkä myöhemmin tulevia toimintoja.

Lähiajan suunnitelmat

Lähiaikoina Microsoftin suunnitelmissa on julkaista todella paljon pyydetty ja keskustelua herättänyt ominaisuus, jolla tiimin jäsen voi nähdä ja päivittää omia tehtäviään eri projekteista yhdessä näkymässä. Suunnitelmissa on julkaista toiminto, jolla tehtäviin voi liittää tarkastuslistoja. Vastaavan tyyppinen ominaisuus on olemassa mm. Plannerissa. Nykyinen versio tukee ainoastaan lopusta alkuun riippuvuuksia. Tämä rajoitus poistuu lähitulevaisuudessa, jolloin tuki kaikille riippuvuustyypeille tuodaan tuotteeseen. Myöhemmin on tulossa myös mahdollisuus antaa viiveitä ainakin riippuvuuksille.

 

Mitä tämän jälkeen?

Kehityslistalla on asioita, jotka kytkevät Project for the Webin tiiviimmin Teamsiin. Jossakin vaiheessa henkilön omat tehtävät ovat nähtävissä Teamsissa. Tulossa on myös tuki kooltaan isompien projektien käsittelylle. Tällä hetkellä rajoitus on 500 tehtävän kohdalla. Kehityslistalla on myös paljon pyydetty ominaisuus, jossa projektille voidaan tallettaa vertailusuunnitelma eli baseline. Tähän mennessä raportointiin on pitänyt käyttää Power BI välinettä. Tulevaisuudessa Project for the Web sisältää koko joukon graafeja, jotka päivittyvät sitä mukaa kun suunnittelu edistyy. Grafiikka sisältää myös tiimin kuormitukseen liittyviä kuvaajia.

 

Jos haluat kuulla lisää uudesta Project for the Webistä, ota yhteyttä.

 

Scientia potentia est

”Tieto on valtaa” kiteytti Sir Francis Bacon tiedon merkityksestä yli 400 vuotta sitten. Hänen mielestään päätöksenteossa merkittävää on tosiasioiden havainnointi, havainnoista saadun tiedon yleistäminen sekä tämän tiedon yhdistäminen kokemukseen. Tästä päätöksenteon periaatteesta hänet on nimetty yhdeksi empirismin eli kokemusajattelun merkittäväksi kehittäjäksi.

Kokemusajattelu on edelleen voimissaan. Menestyvä organisaatio perustaa toimintansa tietoon. Parhaat tulokset saavutetaan luotettavan havainnoinnin ja liiketoimintakokemuksen yhdistelmällä.

Käytännössä saman ajattelun ympärille kietoutuu monta viime aikoina esiin nostettua termiä: tietointensiivisyys, datakyvykkyys, Data Driven Business, Master Data Management. Kyse on kyvystä hyödyntää tietoa systemaattisesti ja ketterästi ja saada siitä kilpailuetua.

Tekniikka ei ole ongelma, sillä nykyaikaiset tietojärjestelmät ja tiedon analysoinnin alustaratkaisut pystyvät tarjoamaan tiedot helposti, luotettavasti, laadukkaasti ja käytännössä reaaliaikaisesti.

Haasteena ovat havainnoin kohteiden päättäminen, mittareiden ja tavoitteiden muodostaminen sekä organisaation johtaminen mittareiden pohjalta.

Keskeisin asia, eli havainnoin kohteet löytyvät luontevasti organisaation strategiasta. Alla on esimerkki ohjelmistoliiketoimintaa tekevän organisaation strategiasta kuusi helposti sovellettavaa kohtaa. Huomaa, että havainnoinnissa erityisen tärkeää ovat trendit, eli mihin suuntaan ollaan menossa suhteessa tavoitteisiin.

  1. Kirkasta lähtökohta. Organisaation tavoitteet ja käsitys olemassaolonsa tarkoituksesta määrittää mitä asioita tulee havainnoida. Vision ja mission määrittämisen ei ole vain henkilöstön kannustamiseen tai rahoittajien sitouttamiseen tarkoitettu julistus, vaan niihin nojautuen tulee muodostaa myös menestymistä seuraavat mittarit.
  2. Päätä ensin missä markkinassa toimit ja keitä tavoittelet asiakkaaksesi. Havainnoinnin kohteena ja mittareina voivat olla asiakastyytyväisyys ja kassavirta asiakkaittain tarkoituksenmukaisin luokittelutiedoin (tuote, alue, liiketoiminta-alue jne).
  3. Oma talous. Tämä liittyy keskeisesti asiakkaisiin. Havainnoin kohteena voivat olla kassavirta, kannattavuus ja kasvu.
  4. Toiminta ja tehokkuus. Tässä seurataan toiminnan tehokkuutta ja sitä, että päätöksenteko ja tekeminen kohdistuvat organisaation tavoitteiden kannalta oikeisiin hankkeisiin ja tuotteisiin. Havainnoin kohteena ovat tuotteet näiden elinkaaret huomioiden, käynnissä olevat ja tulevat hankkeet sovituilla mittareilla sekä henkilöresurssien suunnitellut ja toteutuneet käyttöasteet.
  5. Voimavarat ja jatkuvuus. Menestyminen edellyttää, että käytössäsi on asetettujen tavoitteiden saavuttamisen edellyttämät osaamiset. Havainnoin kohteena ovat työtyytyväisyys, mahdolliset osaamisvajeet nyt ja tulevaisuudessa sekä sovittujen urapolkujen onnistuminen.
  6. Kilpailu ja riskit. Havainnoinnin kohteena ovat myynnin onnistuminen sovituilla mittareilla sekä hankkeiden ja hankeportfolioiden riskit.

Kokemusajattelun periaatteita noudattaen ihminen pidetään toteutuksen keskiössä. Tiedon analysoija tuo tarvittavan kokemuksen ja näkemyksen organisaation kannalta merkitsevän tiedon käsittelyyn ja johtopäätösten tekoon.

Keskeisen liiketoimintatiedon hallinnan kehityshanke ei ole vain tietotekniikkahanke. Kokemuksellisen tiedon hyödyntäminen edellyttää, että omistajuus ja jatkokehittämisen vastuu on oltava liiketoimintajohdossa.

Ota yhteys, jos mielenkiitosi heräsi liiketoimintasi kannalta merkittävän tiedon muodostamisesta, keräämisestä ja sen jalostamisesta organisaatiosi menestystekijäksi.

Projektin päättämisen vinkit

Projekti on väliaikainen työponnistus määritellyn lopputuloksen aikaansaamiseksi. Kun lopputulos on saatu aikaiseksi, projekti päätetään ja projektia ei enää ole. Väliaikaisuus on niin tärkeä projektia määrittävä piirre, että projektin päättäminen pitäisi olla projektijohtamisen tavoitteena aivan projektin alusta lähtien.

Mahdollisia syitä projektin päättämisen epäonnistumiselle

Projektin päättäminen voi epäonnistua tai venyä tarpeettoman pitkälle erilaisista syistä johtuen:

  • Projektille kaadetaan lisää vaatimuksia toteutettavaksi, laajuus paisuu organisaation investointiprosessin ohi.
  • Projektin päätöspisteitä ei ole sidottu kalenteriin, aikataulu pääsee valumaan eteenpäin, kun päätöksentekijöiltä ei saada hyväksyntää lopputuloksille, muutoksille ja työn jatkamiselle.
  • Projektin lopputuloksia ”kiillotetaan”, vaikka ne ovat jo riittävän valmiita käyttöönotettaviksi.
  • Projektiin osallistuvien henkilöiden ja organisaatioiden kiinnostus laimenee ja sitoutuminen heikkenee. Sitoutumisen laimeneminen näkyy resurssien saatavuudessa, kun projektin tarvitsemat resurssit priorisoidaan muualle.
  • Jos lopputuotteen hyväksyntä jää kokonaisuudessaan projektin loppuun, saattaa hyväksynnästä muodostua suuri kertapäätös, johon ei uskalleta sitoutua. Projektilta saatetaan vaatia lisää varmistuksia ja tarkastuksia lopputuotteiden kelpoisuudesta.
  • Projektin lopputulosten siirto ylläpitoon ja käyttävän organisaation vastuulle laiminlyödään tai aloitetaan liian myöhään. Pahimmassa tapauksessa lopputulosten hyödyntäminen epäonnistuu, jos tulosten käyttöönotto jää vaillinaiseksi.

Kaikki yllä esitetyt syyt voivat viivästyttää projektin päättämistä, jolloin projektin työmäärä, aikataulu ja kustannukset kasvavat. Aikataulun viivästymisen vuoksi projektilta odotettujen hyötyjen saaminen viivästyy. Resurssit eivät vapaudu uusiin alkaviin projekteihin, jolloin myös seuraavat projektit viivästyvät. 

Päättämisen lähtökohtana selkeät tavoitteet 

Projektin päätökseen saamisen lähtökohtana ovat tarkat ja selkeät projektin tavoitteiden ja lopputulosten määrittelyt. Projektin päättämisen kriteeristö on helppo määritellä, kun ymmärretään, mitä pitää saada aikaiseksi. Työvälineitä tavoitteiden ja lopputulosten kirkastamiseen ovat esimerkiksi: Sidosryhmäanalyysi ja vaatimusmäärittely sekä lopputuotteen ositus. 

Projektin päättäminen aloitetaan ajoissa. Lopputuloksia hyväksytetään käyttäjillä ja vastaanottavalla organisaatiolla projektin elinkaaren aikana heti kun niitä syntyy. Osatulosten hyväksyntään liittyvät katselmoinnit ja päätöspisteet, varataan kalenteriin ajoissa, jotteivat ne lähde siirtymään eteenpäin vastuullisten päätöstentekijöiden kalenterien täyttymisen mukana. 

Iteratiivinen työsuunnitelma auttaa siinä, ettei projektin lopputuloksia jäädä hieromaan liikaa vaan välituloksia arvioidaan, testataan ja katselmoidaan usein. Kun laatutaso on riittävä, tulos hyväksytään. Muistetaan, että paras on hyvän vihollinen. 

Projektin johtaminen tuottaa useita hyödyllisiä tietoja ja oppeja tulevia projekteja varten. Opitut asiat, riskit, toteutuksen aikana hyväksytyt muutokset ja muut projektin johtamiseen liittyvät kokemukset kerätään projektin toteutuksen aikana projektin johtamisen lokeihin. Jos kokemusten kerääminen jää projektin loppuun, ovat ne ehkä jo unohtuneet tai niitä ei jakseta dokumentoida. 

Projektin lopputulosten siirto käyttävälle ja ylläpitävälle organisaatiolle aloitetaan aikaisin. Jo projektin alussa viestitään ylläpito-organisaatiolle tulevista vastuista. Tarvittavat ylläpidon ohjeistot, koulutukset ja osaamisen siirto valmistellaan aikaisin.

Projektin päätösvaihe

Hyvin valmisteltu, toteutuksen aikainen päättäminen jättää projektin päätösvaiheeseen projektin virallisen päättämisen tehtävät:

  • Varmistetaan että projektin tuottama dokumentaatio on päivitetty, jaeltu ja arkistoitu.
  • Projektin lopputulokset ovat virallisesti siirretty käyttävälle organisaatiolle ja ylläpitovastuut on sovittu.
  • Tarkastetaan, mitkä tehtävät vielä tehdään projektissa ja mitkä työt jäävät ylläpidon vastuulle. 
  • Muistetaan sulkea projekti tietojärjestelmissä ja päätetään hankintasopimukset, jotta projektiin ei vahingossakaan voida enää tuoda kustannuksia. 
  • Päivitetään opitut asiat, riskiloki, muutosloki ja muut projektijohtamisen dokumentit ajan tasalle 
  • Koostetaan projektin loppuraportti suunnitelmista ja projektijohtamisen dokumentaatiosta 
Päätöskokous

Projektin päätöskokous muodostaa jämäkän päätöspisteen projektille. Päätöskokouksessa katselmoidaan vielä projektin lopputulokset ja arvioidaan projektissa yhdessä kuljettu matka: Eteneminen, kohokohdat, onnistumiset, oivallukset ja haasteet.

Vähänkin isommissa projekteissa voidaan vielä organisoida päätöspeijaiset, jossa on tilaisuus juhlistaa yhdessä saavutettuja tuloksia ja henkisesti irrottautua projektista. Kannattaa kuitenkin miettiä, onko yhteiselle juhlimiselle enemmän tarvetta projektin alkuvaiheessa kuin projektin lopussa. Yhteishengen luonti ja henkilöiden verkostoituminen alkuvaiheessa on arvokkaampaa, kuin lopussa, jolloin projektiin osallistuneilla pitäisi jo olla katse seuraavissa projekteissa.

Kuinka kävi – tuottiko kehityshankkeesi tavoitellut hyödyt?

Projekti on väline hyötyjen tuottamiseksi projektin sidosryhmille. Tavoitteena voi olla toiminnan laadun parantaminen, kustannustehokkuuden nostaminen, asiakastyytyväisyyden nostaminen jne.

Hyötyjen tunnistaminen ja saavutettujen hyötyjen mittaaminen ovat keskeisiä asioita arvioitaessa projektiehdokkaita suhteessa toisiinsa sekä sitä, kuinka onnistunut projekti lopulta olikaan.

Projektin valinta toteutukseen on valinta suuresta ehdokasmäärästä ja kriteerinä ovat hyötyjen maksimointi organisaation ja sidosryhmien kannalta.  Tähän tarvitaan toimivaa strategiaprosessia, jossa projektiehdokkaita arvioidaan suhteessa organisaation tavoitteisiin ja valinta kohdistetaan vain niihin, jotka täyttävät kriteerit parhaiten ja joilla on paras mahdollisuus menestyä.

Projektin tavoiteltavien hyötyjen saavuttamista pitää seurata ja mitata projektin alusta asti. Mikäli tavoitteet eivät suunnitellusti täyty, niin asiaan on puututtava sovituilla projektin muutoshallinnan keinoilla. Muutoshallinnan tulee keskittyä ensi sijassa tavoiteltujen hyötyjen saavuttamiseen. Projektin jatkaminen tulee olla mahdollista kyseenalaistaa missä tahansa toteutuksen vaiheessa. Näin projektin varaamat kyvykkyydet vapautuvat hyötyjä paremmin tuottaviin kohteisiin.

Hyötyjä aletaan saavuttaa useasti vasta projektin toimitusvaiheessa tai sen jälkeen. Samoja hyötyjä tavoitellaan myös muissa projekteissa. Merkittävää siis on, että tavoiteltujen hyötyjen saavuttamisen seuranta ja hallinta ovat projektien ylitse tapahtuvaa toimintaa. Seuranta tulee jatkua myös projektin toteutuksen jälkeen toiminnan jatkuvan kehittämisen periaatteiden mukaisesti.

Kyse on suunnitelmallisesta hyötyjen hallinnasta. Tavoitteena on varmistaa, että toteutettavat projektit saavuttavat tavoitellut hyödyt ja että saavutetut hyödyt ovat pysyviä. Hyötyjen hallinta edellyttää suunnitelmallisuutta, mittareita, omistajuutta ja sovittuja toimintamalleja. Asiaa on osaltaan edistänyt osaltaan myös PMI – Project management Institute omassa julkaisussaan.

Alla muutama vinkki hankkeen hyötysuunnitelman tekemiseen:

– Tunnista ja kuvaa tavoiteltavat hyödyt. Huomaa lyhyen ja pitkän tähtäyksen tavoitteet sekä sidosryhmien tavoittelemien suorien hyötyjen ohella välilliset hyödyt koko organisaatiolle.

– Muodosta mittari ja vertailukohta kunkin tunnistetun hyödyn saavuttamisen arviointiin sekä miten saavuttamista seurataan ja viestitään.

– Selvitä mahdolliset hyötyjen väliset riippuvuussuhteet. Varmista, että kukin tavoiteltava hyöty liittyy organisaation strategisiin tavoitteisiin.

– Määrittele hyödyn saavuttamiseen liittyvät keskeiset oletukset, tehtävät ja mahdolliset riskit ja rajoitteet.

– Arvioi kunkin hyödyn saavuttamisen ajankohta. Huomaa, että kyse ei niinkään ole tietystä hetkestä, vaan ajanjaksosta, jonka kuluessa hyöty saavutetaan ja se voi ulottua myös projektin päättymisen jälkeiseen aikaan.

– Määritä kuka omistaa kunkin tunnistetun hyödyn ja vastaa siitä, että saavutettu hyöty on pysyvä.

Edellä kuvattua projektin hyötysuunnitelmaa voidaan näppärästi visualisoida jana-aikataulukuvaajalla, joka ryhmitellään tarkoituksenmukaisesti. Kumulatiiviset rahalliset hyödyt voidaan esittää tähän liittyvänä histogrammina. Koko organisaatiota palvelevat vastaavat esitykset, mutta projektien ylitse tuotettuna.

Aivan kaikkia tavoiteltuja hyötyjä voi olla voi olla vaikea mitata kuten parantunut yritysimago. Tällaiset aineettomatkin hyödyt ovat yhtä tavoiteltavia, kuin mitattavissa olevatkin. Huomioi siis myös nämä hyötysuunnitelmassasi.

Tarvitsetko välineitä organisaatiosi hankkeiden strategianmukaisuuden arviointiin, priorisointiin ja valintaan? Ota yhteys – merkittäviä hyötyjä on saavutettavissa!

 

 

Pilvipalvelun elinkaarihallintaa

Viisaana päätöksenä yhä useammat yritykset ottavat käyttöön tarvitsemansa ohjelmistoratkaisut palveluna.

Palveluna käytettävissä ratkaisuissa tilaajalla on käytössään tyypillisesti toimittajan perusjärjestelmäratkaisun sisällä jonkinlainen asiakassovitus, jonka sisällöstä ja laajuudesta he itse vastaavat. Asiakassovitukseen voi liittyä raportteja ja rajapintoja sekä perusjärjestelmän laajennuksena sitä muuttanutta tai korvannutta toiminnallisuutta.

Uutena ja merkittävänä asiana on, että palvelun tilaajasta tulee tällöin aktiivinen toimija palveluna hankkimansa ratkaisun elinkaaren ylläpitäjänä.

Palvelun tilaajalla on myös monta huolta vähemmän:

  • Ylläpidettävänä ei ole vaativaa IT infrastruktuuria eikä sen edellyttämää osaamista ja tiloja.
  • Palvelu on käytettävissä ajasta ja paikasta riippumatta.
  • Palvelukeskustoiminta takaa skaalautuvan, korkean suorituskyvyn, tietoturvan ja luotettavuuden.
  • Toimittaja huolehtii palveluun kuuluvana siitä, että ratkaisu on teknisesti ja toiminnallisesti moderni ja aina ajan tasalla.
  • Merkittävää kertainvestointia ja siihen vuosiksi sidottua pääomaa ei tarvita. Mikäli tietojärjestelmä tulee tarpeettomaksi, niin palvelu on koska tahansa irtisanottavissa.
  • Toimittajan asiakastuella on suora pääsy ympäristöön ja mahdolliset ongelmatilanteet saadaan ratkaistua nopeasti.

Palveluna käytettävä ratkaisu edellyttää tilaajalta vahvaa sitoutumista ja organisoitumista sekä toimivaa yhteistyötä toimittajan kanssa. Tilaajan vastuulla viimekädessä on se, miten palvelun toimittajan tarjolle tuomia uusia tai korvaavia ominaisuuksia otetaan käyttöön ja miten asiakkaan tarpeisiin sovitettua ratkaisua ylläpidetään ja jatkokehitetään.

Organisaation toiminnan kannalta keskeisen palvelun elinkaarihallinnan apuna voidaan käyttää tuttuja ohjelmiston elinkaarihallinnan malleja ja tapoja:

  • Toteutetulle ratkaisulle annetaan käyttäjiä puhutteleva oma nimi erotuksena toimittajan perustuoteratkaisusta.
  • Kulloinkin käytössä oleva ratkaisukokonaisuus yksilöidään nimeen liitetyllä versiotiedolla.
  • Ratkaisun muodostavat erilliset asiakassovitukset (raportit, integraatiot, toiminnalliset laajennukset…) yksilöidään versiotiedolla.
  • Asiakassovituksiin liittyvä lähdemateriaali ja mahdollinen lähdekoodi hallintaan keskitetysti ylläpitoa ja jatkokehitystä varten.
  • Kehitysideat kerätään ja priorisoidaan ja ratkaisulle ylläidetään kehitystiekarttaa.
  • Ratkaisu dokumentoidaan ja sille toteutetaan ohjeistus ja koulutusmateriaali.

Laajennettavuuden ohella perusjärjestelmässä tulee olla sisään rakennettuna piirteet, joilla käytössä olevien erillisten asiakassovitusten kulloinenkin tilanne (versio) on mahdollista luotettavasti selvittää.

Versiointi tuo suunnitelmallisuutta ja jäntevyyttä toteutuksen eri osien ja itse kokonaisuuden elinkaaren hallintaan. Dokumentaatio, ohjeistus, käytössä olevat toiminnallisuudet, integraatiot ja kehitysideat on selkeää liittää tiettyyn versioon. Uusia piirteitä ja toiminnollisuuksia otetaan käyttöön tarpeen mukaan ratkaisun uusissa versioissa, joiden sisältö ja toteutusaikataulu suunnitellaan etukäteen ja jotka otetaan käyttöön hallitusti.

Ota yhteys jos pohdit kokonaisratkaisua organisaatiosi toiminnan suunnitteluun ja ohjaukseen haasteisiin. Saat sen kätevästi palveluna ja olemme valmiit ottamaan vastuuta ratkaisusi asiakassovitusten versiohallinnasta ja jatkokehityksestä.

Microsoft kiihdyttää Project for the Webiä

1. Project for the Web (PftW) ja Project Power App

Microsoftin uusi Project for the Web -väline on tarjonnut suoraviivaiset toiminnot aikataulujen laatimiseen ja tehtävien vastuuttamiseen tiimin jäsenille. Projektijohtaminen vaatii kuitenkin paljon muutakin, kuin vain tehtävät ja resurssivaraukset. Microsoft ei ainakaan vielä tarjoa mahdollisuutta muokata tai räätälöidä varsinaista https://project.microsoft.com osoitteesta löytyvää Project for the Web -välinettä.

Project for the Web tarjoillaan toisenkin käyttöliittymän kautta, nimittäin aikatauluja voi muokata myös mallipohjaisen Power App:n kautta. Project Power App:ssa voi muokata aikataulujen lisäksi muitakin projektiin liittyviä tietosisältöjä. Erityisen hyödyllinen Power App käyttöliittymä on, kun halutaan lisätä omia tietokäsitteitä, muokata käyttöliittymää ja sovelluksen liiketoimintalogiikkaa vastaamaan omaa tarvetta. Power App tarjoaa valmiin alustan räätälöidyn projektiohjausjärjestelmän pohjaksi.

2. Accelerator kiihdyttää kehittämistä

Microsoft julkisti hetki sitten Project Accelerator -nimisen laajennuksen Project Power Appiin. Accelerator laajentaa mallipohjaista Project Power App toiminnallisuutta, lisäämällä viisi uutta käsitteitä Project Power App:n käsitemalliin ja käyttöliittymään.

Entuudestaan Project for the Web:n tietomalliin kuuluivat peruskäsitteet, kuten esimerkiksi: Projekti, Tehtävä, Tehtävän riippuvuus ja Tiimin jäsen.

Erikseen asennettava Accelerator laajennus tuo mukanaan käsitteet:

Projektiehdotukset – Proposals
Ohjelmat – Programs
Riskit – Risks
Ongelmat – Issuet
Muutokset – Changes
Tilanneraportit – Status reports

Välttämättä uusien käsitteiden sisältö tai käyttöliittymä ei sellaisenaan tyydytä organisaation käyttötarpeita. Näitä käsitteitä kannattaakin ajatella aihioina, joihin voidaan lisäillä organisaation tarvitsemat tietokentät. Myös tietojen esitystapa ja toiminnallisuus käyttöliittymän lomakkeilla voidaan muokata tarpeen mukaan.

Accelerator ei siis niinkään kiihdytä Project Power App sovellusta suoraan, vaan nopeuttaa tämän pohjalta tehtävän laajemman toiminnallisuuden sisältävän räätälöidyn sovelluksen tekemistä.

3. Project Power App laajennettavuus Project lisensseillä

Accelerator lisäosan tuomien uusien käsitteiden lisäksi, Project-lisenssi sallii viiden oman lisäkäsitteen luomisen Project-sovelluksen tietomalliin, ja niiden hyödyntämisen Project Power App -käyttöliittymässä. Esimerkiksi tuotekehitysorganisaatiossa saatetaan haluta lisätä käsite: Tuote ja liittää projektit tuotteeseen. Tuotteiden tietojen ylläpitoon tarvittavat käyttöliittymän lomakkeet voidaan räätälöidä tarkoituksenmukaisiksi.

4. Tuki useille ympäristöille

Project Power App -sovelluksen laajennettavuutta helpottaa myös Microsoftin hiljattain tuoma tuki useille ympäristöille. Tämä tarkoittaa mahdollisuutta luoda erilliset kehitys- ja testausympäristöt tuotantoympäristön rinnalle. Yrityksen omat räätälöidyt toiminnot kehitetään kehitysympäristössä, paketoidaan ratkaisuksi ja siirretään sieltä testattavaksi testiympäristöön ja edelleen testauksen jälkeen tuotantoympäristöön.

5. Kuvia Project Accelerator käyttöliittymästä

(pikkukuva aukeaa uuteen ikkunaan)

Kuva: Project App jossa Accelerator

 

 

Kuva: Projektiehdotukset – Proposals

 

 

Kuva: Projektiehdotus -lomake

 

 

Kuva: Ohjelmat – Programs

 

 

Kuva: Ohjelman tiedot -lomake

 

 

Kuva: Projektin riskit

 

 

 

Kuva: Projektin riski-lomake

 

 

 

Kuva: Projektilista

 

 

Kuva: Projektin tiedot

 

 

Kuva: Projektin tilanneraportti

 

 

Kuva: Raportointi

Systems Thinking – Systeemiajattelu

Ei, otsikon käsite ei liity tietojärjestelmiin tai edes tietotekniikkaan. Kyse ei ole myöskään uudesta asiasta, vaan käsite on vakiintunut viimeisen 50 vuoden aikana.

Ajattelun taustalla on johtopäätös, että edes jotenkin rajatussa kokonaisuudessa asiat ja ilmiöt eivät ole toisistaan irrallisia. Kokonaisuuksien kautta näkeminen on systeemiajattelun tärkein ominaispiirre. Tavoitteena on tehdä näkyväksi, miten asiat ja ilmiöt kytkeytyvät toisiinsa ja kuinka tästä vuorovaikutuksesta syntyy jatkuvasti muuttuvien haasteiden ja mahdollisuuksien verkosto.
Parhaimmillaan systeemiajattelu on, kun pyrkimyksenä on jäsentää kompleksisia asioita (complex). Enemmän tai vähemmän monimutkaisten asioiden (obvious, complicated) erittely onnistuu sen sijaan hyvin jo arkiajattelulla. Kaaoksen (chaotic) hallinnassa ei edes systeemiajattelulla saada välttämättä hyvää lopputulosta. (https://en.wikipedia.org/wiki/Cynefin_framework).

Yhtymäkohta tietojärjestelmätyöhön tulee siitä, että tietojärjestelmien määrittelyssä ja toteutuksessa monesti ollaan tekemisissä kompleksisten asioiden kanssa. Optimistisena tavoitteena on kokonaisuuden mallintaminen ja tuottaa ajatellusta toteutuksesta malli. Sitäkin tarvitaan, mutta parempi lopputulos saavutetaan, kun toteutus mielletään jo lähdössä systeeminä, johon vaikuttavat tarpeen (ongelma, johon haetaan ratkaisua) ohella yksilöt, yhteisö, ympäristö sekä olemassa olevat toimintamallit ja rakenteet. Itse ongelma on jäävuoren huippu, joka pilkistää veden pinnalta. Siihen vaikuttaminen edellyttää pinnan alla olevien asioiden ymmärtämistä ja hyväksymistä.

Organisaation systeemikyvykkyys tuo toiminnan kehittämiseen merkittäviä etuja:

– Itseohjautuva ja yhteistyötä vaaliva tehokas organisaatio. Ymmärretään, että oma onnistuminen riippuu myös muiden työpanoksesta. Organisaation toiminta hyväksytään kokonaisuutena, jossa asiat ja henkilöt ovat alituisessa vuorovaikutuksessa.
– Uusia ja ennakoimattomia asioita syntyy henkilöiden ja asioiden ollessa vuorovaikutuksessa keskenään. Näiden poikkeamien tunnistaminen ja hyödyntäminen palkitsevat itseohjautuvan ja innovatiivisen organisaation uusilla kilpailuvalteilla.
– Asiat eivät henkilöidy ja ongelmaratkaisu on nopeaa. Aina asiat eivät mene odotetusti, mutta juurisyyt ja ratkaisut löydetään nopeasti erittelemällä ongelmaan liittyvät asiat ja miten ne vuorovaikuttavat toisiinsa.
– Ongelmat on tehty ratkaistaviksi. Mitkä tahansa ongelma on mahdollista nähdä haasteena, johon ratkaisut ovat löydettävissä jäsentämällä taustalla olevat syyt, ylläpitävät rakenteet ja ajattelutavat.
– Vahva pohjan toiminnan jatkuvalle kehittämiselle. Asioiden syy ja seuraussuhteet ovat selvillä ja toimintaa kehitetään ja säädetään tehokkaasti kohdistamalla huomio juuri oikeisiin asioihin toivotun vaikutuksen aikaansaamiseksi.
– Luodaan parhaat edellytykset asetettujen tavoitteiden saavuttamiseen. Päätöksenteko nojaa realistiseen ja ajantasaiseen kokonaisnäkemykseen organisaation toiminnasta ja toimintaan vaikuttavista asioista ja ilmiöistä. Lähtötilanteen ollessa selvillä tavoitteeseen on jo helpompi luovia.

Systeemiajattelua tukemaan on kehitetty erilaisia visuaalisia työkaluja, joiden avulla systeemin rakenne voidaan kuvata. Vuorovaikutuskaavio (causal loop diagram, CLD) on yksi näistä (https://en.wikipedia.org/wiki/Causal_loop_diagram).

Tietojärjestelmäkehityksessä systeemiajattelu kannustaa kokonaisratkaisujen toteuttamiseen osaratkaisuiden sijaan. Toteutettavan tietojärjestelmän tulisi huomioida kattavasti kaikki asiat ja ilmiöt, jotka kiinteästi liittyvät toteutettavaan ratkaisuun.

Esimerkiksi portfoliohallinnan keinoin on mahdollista hallita toimintaympäristön sanelemaa muutosta ja organisaation itselleen asettamia tavoitteita. Portfoliohallintaa ei kuitenkaan ole ilman projekteja sekä näissä mahdollisesti kehitettäviä tuotteita ja asioita. Uskottava projektien ja töiden hallinta edellyttää suunnitelmallisuutta ja toteuttavia resursseja. Resurssien osaamisen optimaalinen hyödyntäminen edellyttää toimivaa kapasiteettihallintaa. Toiminnan kehittämiseksi ja kokonaisuuden ylitse tehtäviin tarkasteluihin tarvitaan yhteisiä mittareita kustannuksista, väli- ja lopputulosten saavuttamisesta ja henkilöstön tyytyväisyydestä.

Tietojärjestelmätyössä systeemiajattelu johtaa myös johtopäätökseen, että täsmälleen sama toteutus ei sovi kaikkiin organisaatioihin ja ympäristöihin. Lisäksi systeemi ja vaatimukset muuttuvat koko ajan. Tarvitaan joustavuutta, joka mahdollistaa tietojärjestelmän sovittamisen erilaisiin ja alati muuttuviin tarpeisiin.

Ota yhteys, jos mielenkiintosi heräsi kokonaisvaltaisen ja organisaatiosi kulloisiinkin tarpeisiin mukautuvan tietojärjestelmän toteuttamisesta.

Camako EPM versio 6 irtautuu SharePointista

Camako EPM on perustoiminnallisuuksiltaan laaja projektien- ja työnohjauksen järjestelmä. Se on myös muokattava (low-code / no-code) alusta eri sovellusalueiden ratkaisujen helppoon toteutukseen.

Camako EPM on syntynyt ja kasvanut SharePoint alustalla. Nyt sen on aika rikkoa kahleensa ja irtautua SharePointista, kokonaan itsenäiseksi järjestelmäksi.

Aikansa kutakin

Camako EPM:n tuotekehityksen alkuvaiheessa, SharePoint alusta mahdollisti nopean tuotekehityksen ja laajan toiminnallisuuden. SharePoint tarjosi valmiin käyttäjähallinnan, alustan käyttöliittymälle ja lisätoimintoja, kuten dokumenttien hallinnan. Samalla SharePoint kuitenkin myös rajoitti kehittämistä usealla tavalla.

Nyt haluamme kehittää Camako EPM järjestelmää, ilman SharePointin rajoituksia. Haluamme myös taata asiakkaillemme edullisen tavan jatkaa Camako EPM järjestelmän käyttöä, kun Ilmaisen SharePoint Foundationin käyttömahdollisuus poistuu version 2013 myötä. Ilman kolmannen osapuolen lisenssivaatimuksia järjestelmän hinta voidaan pitää kohtuullisena ja ennustettavana.

Haluamme tarjota järjestelmän, joka sisältää laajat perustoiminnallisuudet, mutta myös mukautuu asiakkaidemme muuttuviin tarpeisiin. Joustava, muokattava alusta kasvattaa järjestelmän elinkaarta, koska järjestelmä mukautuu uusiin vaatimuksiin. Se myös mahdollistaa järjestelmän hyödyntämisen muissakin käyttöskenaarioissa, kuin projektien hallinnassa.

SharePointista irrottaminen mahdollistaa modernien teknologioiden hyödyntämisen esimerkiksi käyttöliittymän toteutuksessa. Nyt voidaan hyödyntää modernia JavaScript tekniikkaa käyttöliittymässä. Tämä mahdollistaa dynaamisen, rikkaan käyttökokemuksen.

Dokumenttien hallintaa voidaan edelleen jatkaa SharePointin dokumenttikirjastoissa, mutta SharePointin ohella mikä tahansa muukin dokumenttihallintajärjestelmä voidaan kytkeä joustavasti osaksi Camako ratkaisua.

Tekninen alusta valinnaisesti pilvessä tai maan päällä

Camako EPM 6 voidaan asentaa täysin pilviympäristöön, omaan tekniseen ympäristöön, Prohan tarjoamaan SaaS ympäristöön tai tarpeen mukaan, vaikka hybridiympäristöön, jossa tietovarasto on pilvessä ja sovellus Prohan SaaS ympäristössä.

Asiakas omistaa tietonsa, tietää missä ne ovat talletettuina ja tarvittaessa voi siirtää tietonsa toiseen ympäristöön. Camako EPM, ei ole moniasiakasympäristö, jossa eri käyttäjäorganisaatioiden tiedot sijaitsisivat samassa fyysisessä tietovarastossa. Jokaiselle käyttäjäorganisaatiolle luodaan oma tietovarasto. Käyttävän organisaation kaikki tieto on omassa SQL kannassa, josta se on helposti raportoitavissa, varmistettavissa ja siirrettävissä.

SharePointista irtautuminen on vaatinut käyttäjähallinnan toteutuksen kokonaan uudelleen. Uusi versio kasvattaa tietoturvallisuutta mahdollistamalla useita erilaisia käyttäjien tunnistamisen tapoja.

Perustoiminnallisuus kehittyy, alustan joustavuus säilyy, käytettävyys paranee

Camako EPM:n perustoiminnallisuuksia ovat olleet: Projektisalkku, projektisuunnitelmat, tehtäväaikataulut, tuntien kirjaus myös mobiilissa, aikajaksotettu resurssien kuormitussuunnittelu, suunnitelmien versiointi. Uutena toiminnallisuutena on valmistunut aikajaksotettu kustannusten suunnittelu.

Paketista otettuun ratkaisuun ei kuitenkaan tarvitse tyytyä. Joustava alusta tarjoaa edelleen mahdollisuudet muokata ja laajentaa järjestelmän tietomallia ja liiketoimintalogiikkaa. Muokatun tietomallin päälle rakennetaan käyttöliittymä käyttäen konfiguroitavia taulukko- ja lomakenäkymiä, Gantt-kaavioita, Kanban-taulua ja aikajaksotettuja resurssi ja kustannusnäkymiä.

Käyttöliittymän kieli on käyttäjän itsensä valittavissa. Uusi käyttöliittymä mahdollistaa myös entistä joustavamman datan analysoinnin. Graafisten esitysten vienti Camakosta esimerkiksi Power Pointiin Gantt-kaavioina ja Kanban-tauluina onnistuu.

Tulemme kevään aikana esittelemään Camako EPM 6 versiota webinaareissa.

Low Code No Code kehittäminen

Edellisessä bloki -kirjoituksessamme esiteltiin ohjelmistokehittämisen mallia, jossa ratkaisu toteutetaan joko ilman tai vain rajoitetulla määrällä itse tehtyä ohjelmakoodia. Siinä ohjelmointityön sijaan käyttöliittymä ja liiketoimintalogiikka toteutetaan ratkaisukehitysalustan tarjoamilla palveluilla ja muokattavilla komponenteilla.

Optimistisena tavoitteena on mahdollistaa Citizen Development (’kansalaiskehittäjä’) toiminta, jossa liiketoiminnan vaatimukset hyvin sisäistänyt, mutta vähän tai ei yhtään ohjelmistokehitystä hallitseva henkilö voisi toteuttaa ohjelmistoratkaisun tietojen hallintaan ja raportointiin. Perinteisesti toimintaan on käytetty toimisto ja –työryhmäsovelluksia. Näitä täydentämään ovat tulleet monipuoliset Saas- ja pilvipalveluna tarjottavat alustat, joille tehdyt toteutukset skaalautuvat aina yritystason ratkaisuihin asti.

Jo tällä hetkellä yrityksissä hyödynnetään jo laajasti raportointi- ja tiedon analysointiratkaisuihin kehitettyjä alustoja.

Jonkin verran vaativampaa on liiketoimintaa tukevan ohjelmistoratkaisun toteutus. Ohessa askeleet miten alun perinkin ratkaisukehitysalustaan nojaavaa projektien- ja töidenhallintajärjestelmää laajennettiin riskienhallinnan toiminnallisuudella.

Toteutuksen päävaiheet olivat:

  1. Tietojen ja näiden välisten relaatioiden määrittely. Tämä on vaativin osa, jossa asiantutijan käyttäminen palkitsee.
  2. Toteutuksen ulkoasun päättäminen. Käyttöön otettiin kokeilujen jälkeen visuaalinen taulu –muotoinen käyttöliittymä. Ratkaisukehitysalusta tarjoaa tyypillisesti erilaisia ulkoasuvaihtoehtoja esim. lista-, lomake ja taulumuotoiset näkymät ja erilaiset esitysgrafiikat.
  3. Toimintojen määrittely ja toteutus. Valittu taulu –muotoinen käyttöliittymä toi mukanaan jo paljon vaadittua toiminnallisuutta. Tämän lisäksi määriteltiin laskennalliset tiedot (riskipisteiden laskenta lähtötiedoista) ja tietokenttien arvojen tarkistukset ja pakollisuudet. Poimintalistoille toteutettiin lista –muotoiset ylläpitonäkymät.
  4. Integraatioiden määrittely ja toteutus. Kokonaisuus täydennettiin riskipisteiden perusteella lähetettävillä sähköpostilähetyksillä.
  5. Merkitsevän tiedon visualisointi. Toteutuksessa hyödynnettiin alustan tarjoamia liikennevaloja ja ikoneita korostamaan ja tuomaan esiin kriittistä tietoa ja työnkulkua.
  6. Väli- ja lopputulosten testaus. Toteutus eteni iteratiivisesti ja sen aikana palattiin lukusia kertoja päävaiheissa taaksepäin tyydyttävän lopputuloksen aikaansaamiseksi.
  7. Ratkaisun siirtäminen tuotantokäyttöön. Tuotantokäyttöön siirtäminen on syytä tehdä omana kokonaisuutenaan noudattaen organisaatiossa sovittuja käytäntöjä.

Toteutuksen tietomalli löytyi melko valmiiksi mietittynä internetistä. Mallin mukaiset rakenteet on toteutettu olemassa olevan projektien- ja töidenhallintajärjestelmän tietokantaan. Taulu -muotoisessa käyttöliittymässä yksittäiset riskit esitetään kortteina riskiluokkien mukaisissa sarakkeissa. Korttien järjestys sarakkeessa visualisoi kunkin riskin merkittävyyttä luokassaan ja liikennevaloilla pyritään visualisoimaan kuhunkin riskiin liittyvää tila- ja kriittisyystietoa. Riskin tietoja pääsee ylläpitämään korttia kaksoisklikkaamalla. Korttien järjestys ja sarake vaihtuvat siirtämällä korttia hiirellä.

Kuva 1. Uusi riskienhallinnan toiminnallisuus osana projektien ja töidenhallintaa.

 

 

 

 

 

 

 

Kuva 2. Suoraviivainen riskienhallinnan tietomalli

Heräsikö mielenkiitosi? Ota yhteys https://www.proha.com/yhteystiedot ja kerromme mielellämme lisää Low Code No Code kehittämisen eduista liiketoimintasovellusten toteuttamisessa Saas palveluna.