Kumppanuus, tärkein menestyksen avain

Päivittäisessä työssä olemme tekemisissä monenlaisten kumppaneiden kanssa, niin kotona kuin työmaallakin. Luottamuksellisten yhteistyösuhteiden – kumppanuuksien – rakentaminen on jatkuvasti tärkeämpää.

Sanakirja määrittelee kumppanuuden molempia osapuolia hyödyttäväksi liikesuhteeksi. Usein kumppanuus mielletään automaattisesti ”isommaksi alennusprosentiksi”. Tällöin mielestäni ei voi puhua kumppanuudesta, koska vain toinen osapuoli hyötyy halvemmasta hinnasta, toisen kannattavuuden kustannuksella.

Oikeaa kumppanuutta on, kun yhteisesti mietitään, miten jokin tuote tai palvelu voisi olla edullisempaa toteuttaa tai voidaanko esimerkiksi tilaus-toimitusketjun vaiheita suoraviivaistaa. Tällöin kyseessä on oikea kumppanuus – molemmat osapuolet hyötyvät. Kumppanuudessa pitää siis pyrkiä yhteiseen päämäärään, jossa asioita tehdään yhteisesti suunnitellen fiksummin ja tehokkaammin kuin aiemmin. Tavoitteena löytää sellaiset toimintamallit, joiden avulla molemmat tai laajemman verkoston olessa kyseessä kaikki osapuolet hyötyvät.

Kumppanuuksien tueksi ja kumppaniverkoston helpoksi mahdollistajaksi, olemme Lemonsoftilla kehittäneet Lemonhub-palveluumme omat tilaussanomat, jotka mahdollistavat maksuttomat osto- ja myyntitilaussanomien välittämisen omassa verkostossamme, eli Lemonsoft-asiakkaiden kesken. Tällä toiminnallisuudella haluamme omalta osaltamme olla luomassa verkostoja yritysten välillä ja edistää suomalaista kilpailukykyä.

Jakke Vyyryläinen

Myynti- ja markkinointijohtaja

Lean ajattelu käytännössä – toimiiko meillä?

Lean ajattelu on lähtöisin alun perin Toyotalta. Toyota itse ei käytä Lean sanaa, vaan TPS -sanaa, eli Toyota Production System. Kyseessä on Toyotan luoma ainutlaatuinen Management kulttuuri, jota niin monet ovat yrittäneet kopioida. Meidän länsimaisten ihmisten saattaa olla vaikea ymmärtää heidän syvintä ajatteluaan.

Kun lähdemme Lean matkalle, tapaan sanoa: ”Toyota ei ole täydellinen. Pointti ei ole Toyota. Ei ole kyse Toyotasta – eikä autoista”. Vaan…kyse on siitä, miten opitaan, toimitaan ja johdetaan! Miten saadaan ihmiset ajattelemaan ja organisaatio oppimaan. Tässä Toyota on mestari.

Saatamme ottaa käyttöön erilaisia Lean työkaluja, jotka vaikuttavat aluksi helpoilta. Tunnetuin näistä lienee 5S. Siivoamme ja jonkin ajan kuluttua toiminta saattaa hyytyä. Olet ehkä kuullut sanottavan ”Lean ei toimi meillä”. Missä vika?

Rakennamme ensin ihmisiä – sitten autoja! Lause pitää sisällään yhden merkittävimmistä Toyotan ajattelumalleista – Kunnioitus! Mitä tämä tarkoittaa? Otan yhden esimerkin. Toyotalla linjatyöntekijä tekee vaiheistettua työtä, minkä kesto on 126 sekuntia, tähän hän saa 5 viikon peruskoulutuksen! Koulutus pitää sisällään toki paljon muutakin kuin pelkkää asentamista, arvojen oppimista, joka päivä kuntosalihetki, jne. Ollessani Toyotalla koulutuksessa, ryhmässämme oli Volvon tehtailta esimiestason henkilö. Toyotan sensei kysyi häneltä, kauanko teidän asentaja saa koulutusta ja kauanko kestää yksi työvaihe. Ruotsalainen vastasi 1 viikon koulutusta ja työvaihe kestää 20 minuuttia. Johon sensei vastasi: ”asetatte työntekijälle suuria paineita”. Kunnioitus tarkoittaa käytännössä, että Toyota ei aseta työntekijää sellaiseen asemaan missä hänellä ei ole onnistumisen edellytyksiä. Tässä vain yksi esimerkki Toyotan ajattelusta.

Toinen esimerkki toisesta ajattelumallista – Jatkuva parantaminen! Jos asentaja hakee tarvikkeita 10 metrin päästä ja voisi tuoda yhdellä kerralla koko päivän tarpeen, tämän ei anneta tapahtua. Asentaja ohjeistetaan hakemaan tarvikkeita useita kertoja esim tunnin aikana. Miksi? Jos hän hakisi kerralla koko ”kasan”, hän ei rupeaisi miettimään, miten tämän voisi tehdä helpommalla. Mutta kun hän hakee tarvikkeita useamman kerran, hän luonnostaan ajattelee miten tätä prosessia voisi parantaa? Tämä ajattelu tuntuu aluksi kummalliselta. Miksi Toyota ei käytä erätuotantoa vaan pyrkii yhden kappaleen virtaukseen? Tässä osasyy. Yhden kappaleen virtauksen rakentaminen on todella haasteellista, tiedät jos olet tätä yrittänyt. Yhden kappaleen virtauksen rakentamisen tarkoituksena on tuoda ongelmat esiin, eli ongelmat jotka olivat aiemmin piilossa erätuotannossa.

Kävimme erään Toyotan alihankkijan luona, joka tekee 7.000 kpl osaa päivässä, siis yli 2.000.000 kpl osaa vuodessa. Montako laatuvirhettä hyväksyisit, jos olisit tuotantojohtaja? Tältä alihankkijalta oli päässyt eteenpäin vain 1 kpl virheellistä osaa vuodessa. Miten tämä on mahdollista? Toyotan periaate on ”Laadun tarkistus lähteellä”. Jokainen työntekijä saa OnJobTraining -valmennuksen, jossa hänet opastetaan kädestä pitäen tekemään osia. Lisäksi työntekijä ottaa laadun tarkistuksen kunnia asiana. Työkaluna he käyttävät Poka-yoke menetelmää.

Tässä esimerkkejä TPS ajattelusta – miten Sinä ajattelet?

Kalervo Laaksoharju
Partner
Lean Leader ja Luontaiset Taipumukset™ esimiesvalmentaja
JTO Lean Learning Center Oy

 

Askeleet sujuvaan käyttöönottoon

Järjestelmän käyttöönotto – tyypillinen projekti?

Valtava innostus, julmettu hämminki, hitonmoinen sekaannus, järkiintyminen ja ”pelastetaan se, mikä pelastaa voidaan”. Tuo on eräänlainen malli hoitaa projekteja, oli sitten kyseessä rakennuksen peruskorjaus tai ERP-järjestelmän käyttöönotto. Onneksi tällaisiin tapauksiin törmää varsin harvoin.

Projektia ei alkuinnostuksen vallassa muisteta valmistella eikä suunnitella. Sitten kun jossain vaiheessa huomataan, että metsään ollaan menossa, tehdään hätäisiä korjausliikkeitä. Kiireessä tehdyillä korjauksilla saadaan harvoin onnistunutta lopputulosta, lähinnä koetetaan minimoida vahingot.

Tyypillisimmät asiat, jotka voidaan pilata jo projektin alkuvaiheessa ovat aikataulu ja budjetti. Alkuvaiheessa ei ole lainkaan kiire, mutta viimeiset pari viikkoa tehdään yötäpäivää, jotta pysytään aikataulussa. Jos siis (realistista) aikataulua on ylipäätään tehty. Kustannuspuoli on vielä aikatauluakin mielenkiintoisempi kokonaisuus, alkupään säästö voi aiheuttaa loppupäässä merkittäviä lisäkustannuksia, mutta toimii myös toisinpäin; alkupään löyhä kustannuskuri voi aiheuttaa loppupäähän merkittäviä haasteita tai kustannusten ylityksiä. Jos siis ylipäätään on alussa aikataulutettu tai budjetoitu.

Tämän voi tehdä myös toisin

Yleinen määritelmä toteaa projektin olevan tarkasti suunniteltu, ainutkertainen hanke ennalta määritellyn tavoitteen saavuttamiseksi, asetetussa budjetissa ja aikataulussa pysyen. Oppikirjamaisesti projekti voidaan jakaa neljään päävaiheeseen; suunnittelu, käynnistäminen, toteutus ja päättäminen. Päävaiheet, erityisesti toteutus, jaetaan useampiin alivaiheisiin. Yksittäisenä kokonaisuutena toteutus on usein liian iso pala hallittavaksi, siksi se on viisasta jakaa osiin.

Pelkkä vaiheistus ei kuitenkaan riitä. Aikataulu, budjetti, roolit, vastuut ja riskienhallinta ovat myös tärkeitä huomioida. Projektipäällikön merkitys on myös erittäin tärkeä, erityisesti projektin onnistumisen ja aikataulussa pysymisen näkökulmasta. Kaikkien edellämainittujen ohi, mielestäni tärkeimmäksi asiaksi onnistuneessa projektissa nousee kuitenkin yksi asia; tavoite – mitä ylipäätään tavoitellaan ja millä ja miten mitataan, että tavoite on saavutettu.

Ensimmäinen askel – Määritellään tavoitteet

Kun muutosta tai jotain uutta lähdetään suunnittelemaan, ensimmäinen kysymys pitäisi olla miksi? Miksi tähän ryhdytään ja mitä tavoitellaan? Miksi lähdetään lenkille? Tavoitellan parempaa peruskuntoa tai pienempää lukua vaa’alla tai horisontissa siintää ajatus osallistumisesta maratonille joskus. Ok, mutta ei vielä kovin konkreettista. Kun edellä mainittuihin ajatuksiin lisätään luvut ja aikataulu, saadaan oikeat tavoitteet ja karkea suunnitelma, joka sitten aikataulutetaan ja konkretisoidaan; tavoitteena on juosta maraton heinäkuussa 2018 loppuaikaan 4:50, välitavoitteen ollessa puolimaraton Helsinki City Runissa toukokuussa 2017.

Sama ajatusmalli sopii hyvin myös toiminnanohjausjärjestelmän vaihtoon. Miksi vaihdetaan? Halutaan nykyistä uudenaikaisempi ratkaisu, halutaan karsia manuaalisia työvaiheita, halutaan parempi raportointi, tavoitellaan liikevaihdon kasvua kasvattamatta toimihenkilöiden lukumäärää. Hyviä tavoitteita, mutta se konkretia. Konkretisoidaan siis em. ajatukset tavoitteiksi:

  • järjestelmä käyttöön tilikauden 2018 alusta
  • tekninen ratkaisu sellainen, jonka käyttöikä ja tuki jatkuu 10 vuotta
  • käytettävissä ajasta, paikasta ja laitteesta riippumatta myös mobiilisti
  • x ja y raportit reaaliaikaisesti, ilman excel-jumppaa
  • kokonaisjärjestelmän avulla toimintamalli niin, että edellisen kuun tulos on selvillä kuukauden 7. päivä
  • laskutus- ja tilaus/toimitusprosessi järjestelmän avulla siten, että liikevaihdon budjetoitu 17% kasvu (oletuksena sama kasvuprosentti käsiteltävien tilausten määrässä) voidaan hoitaa nykyhenkilöstöllä -> tilauksen käsittelyn nopeutus x%
  • Toimitusvarmuuden kasvu 10%-yksikköä, tavoite 95%

Nyt on konkreettisia numeroita, tavoitteita ja lähtökohdat mittareille. Sitten vaan toteuttamaan, eikös!

Toinen askel – Aikataulutetaan, resursoidaan ja budjetoidaan

Eipäs sentään, ei toteuteta vielä. Ensimmäinen, vaikein askel on lenkille lähdössä on nyt otettu, lenkkarit on jalassa. Lämmitellään vielä hetki ja mietitään reitti valmiiksi, ennen kuin aletaan juoksemaan. Jaa niin, sykemittari myös mukaan.

Realistinen aikataulu: usein ajatellaan, kyllähän me tämä 2 viikossa otetaan omatoimisesti käyttöön. Joiltain osin voi näin ollakin ja paljon omaa työtä vaaditaan käyttöönoton aikana, mutta realismia peliin. Mielummin kannattaa varata enemmän aikaa kuin liian vähän. Käyttöönottoon liittyvät työt tulevat kuitenkin yleensä ”normitöiden” päälle, joten realisti kannattaa olla. Hyvä nyrkkisääntö on, että yhtä toimittajan pitämää käyttöönottopäivää kohden asiakkaan on hyvä varata 2,5-3 päivää omaa työtä. Käyttöönottopalveluissa ei myöskään kannata liikaa pihistellä, käyttöönottopäivien kulut maksavat itsensä takaisin lisääntyneenä tehokkuutena ja henkilöstön osaamisena nopeasti. Kun osaaminen on kohdallaan, myös mahdollinen muutosvastarinta on merkittävästi pienempää.

Kolmas askel – Toteutetaan

Sanotaan, että hyvin suunniteltu on puoliksi tehty. Vääräleuka voisi kommentoida, että hyvin suunniteltu on aloittamista vaille valmis. Niin tai näin, toteutusvaiheessa korostuu projektipäällikköjen (niin asiakkaan kuin toimittajienkin) sekä projektiryhmän osuus. Kun asiat hoidetaan säntillisesti puolin ja toisin ja raportoidaan säännöllisesti projektipalavereissa mahdolliset poikkeamat ja sovitaan kuinka ne hoidetaan, pysyy projekti aikataulussa ja kustannuksissa.

Toteutusvaihe on yleensä aikataulullisesti pisin ja toiminnallisesti laajin. Uuden järjestelmän käyttöönotto vaatii paljon työtä kaikilta, myös yrityksen johdolta – johdon sitoutumisen ja esimerkin voimaa ei voi väheksyä. Uusi järjestelmä merkitsee yleensä myös jonkinlaisia muutoksia yrityksen toimintatavoissa, nämä muutokset tulee koko henkilöstön omaksua.

Toteutusvaihetta ja vastuuta ei myöskään saa irrottaa operatiivisesta vastuusta. Avainhenkilöiden täytyy olla alusta asti vahvalla panoksella mukana ja sitoutuneita uuteen järjestelmään ja mahdollisiin toimintamallien muutoksiin.

Toteutuksen edetessä pitää myös olla realisti. Kakkosvaiheen aikatauluun voi tulla erinäisistä syistä muutoksia, jotka pitää hyväksyä. Tällöin projektin muutoksenhallinta on avainasemassa. Lähtökohtaisesti pidetään aikataulusta kiinni ja muutokset siihen tehdään vain erittäin perustelluista syistä, mutta on tilanteita, joissa on paljon fiksumpaa siirtää käyttöönottohetkeä kuukaudella kuin yrittää väkisin tehdä ”puolivillainen” lopputulos alkuperäisen aikataulun puitteissa.

Neljäs askel – Mitataan

Aikataulussa pysyttiin ja kokonaisuus saatiin määräpäivään mennessä kokonaisuudessaan käyttöön. Kun tehtiin viimeiset 2 viikkoa 14 tunnin päiviä myös viikonloppuisin. Ja silti on hankalampaa kuin ennen. Niinhän se on ensimmäisten viikkojen ajan, erityisesti jos loppuvaiheessa on tullut kiire.

Hyötyjen mittaaminen kannattaakin tehdä pidemmällä aikataululla. Pääsääntöisesti voi sanoa, että on kohtuutonta odottaa maksimitehoja ja –hyötyjä heti. Hyödyt tulevat yleensä vaiheittain, ensimmäisten kuukausien aikana nähdään tyypillisesti jotain konkretiaa, mutta isoimmin hyödyt tulevat puolen vuoden, vuoden jänteellä käyttöönotosta. Silloin on omaksuttu uudet toimintatavat ja muutenkin on saavutettu tietty rutiini toiminnassa.

Käyttöönoton onnistumisen mittaaminen kannattaakin tehdä useammassa kohtaa. Heti projektin päättämisen jälkeen mitataan projektin onnistuminen; saatiinko ensimmäisessä askeleessa kuvattu kokonaisuus käyttöön aikataulussa. Muita alkuvaiheen tavoitteita kannattaa mitata kk-tasolla – silloin nähdään, missä vaiheessa todelliset hyödyt alkavat realisoitumaan. Jos alun esimerkin toimitusvarmuus on ollut keskimäärin 85%, niin ensimmäisen kk:n aikana se voi jopa pudota. Tärkeintä on, että toisena kuukautena päästään samaan kuin aiemmin ja siitä prosentti kerrallaan eteenpäin. Jos 10%-yksikön parannus saavutetaan vaikkapa puolessa vuodessa, voi sekä projektiryhmä että koko henkilöstö onnitella itseään hyvästä suorituksesta. Ja vielä isommat tavoitteet, kuten mainittu liikevaihdon kasvutavoite henkilömäärää lisäämättä päästään mittaamaan vasta, kun tilikausi päättyy. Toki ennustetta voi, ja pitääkin seurata jo matkan varrella.

Summarum

Ohjelmiston onnistunut ja sujuva käyttöönotto on mahdollista, kun määritellään tavoitteet ja toimitaan suunnitelmallisesti. Se vaatii työtä, mutta kun työ on tehty oikein, myös onnistuminen on taattu. Kokonaisuudesta saadaan toimiva ja käyttäjät oivaltavat hyödyt ja sitoutuvat käyttöön. Ja sitten vaan mennään seuraavat 10 vuotta.

Ehkä ei sittenkään. Kun käyttöönotto on tehty ja järjestelmää on käytetty jonkin aikaa, kannattaa alkaa miettimään käyttöönoton tehostamista – jatkokehitysprojektia. Matkan varrella liiketoimintaan tai –ympäristöön tulee muutoksia, ja jotta täydet hyödyt saadaan jatkossakin, kannattaa aika ajoin herätellä ajatusta; ”tätähän kannattaa kehittää ja laajenta”. Vaihdetaanhan autoonkin uusia renkaita ja tehdään muitakin huoltotoimia säännöllisesti.

Jakke Vyyryläinen
Asiakkuusjohtaja
Lemonsoft Oy

eKuitti –helpotusta arkeen

Nouseeko tuskan hiki otsallesi, kun kuluvan kuukauden luottokorttilaskut, matkalaskut tai kululaskut ovat tekemättä ja etsit kuitteja lompakosta, laukusta tai papereiden seasta työpöydältä? Ja mitäs sitten tehdään, kun et enää muista kuka oli paikalla juuri siinä lounastapaamisessa ja kenelle asiakkaalle nämä korvapuustit olikaan viety.

Jatkuva kuittirumba aiheuttaa päänvaivaa, vie aikaa ja syö rahaa. Mitäpä jos vaadittaisiin, että jokaisen kassan vieressä tulee olla järeä kopiokone, jolla voi skannata kuitit sähköpostiin saman tien? Ei kuulosta kovin toteuttamiskelpoiselta idealta. Mutta itseasiassa sinullahan on mitä suuremmalla todennäköisyydellä skannaava laite kädessäsi, nimittäin älypuhelin. Tilastokeskuksen tutkimuksen mukaan alle 45-vuotiaista 94 prosentilla on käytössä älypuhelin.

tilasto

 

 

 

 

 

 

 

 

 

 

Lähde: Väestön tieto- ja viestintätekniikan käyttö -tutkimus 2015, Tilastokeskus

Miltä kuulostaisi, jos ottaisitkin samalta seisomalta kuitista kuvan ja lähettäisit sen sähköisesti kirjanpitoon. Helppoa ja yksinkertaista, eikö vain?

Käyttämällä Lemonsoft eKuitti älypuhelinsovellusta selviät tästä tehottomasta ja ehkä ärtymystäkin herättävästä, hitaasta ja hankalasta prosessista ilman tuskan hikeä. Käyttämällä Lemonsoft eKuitti -sovellusta tuottavuus paranee ja voit keskittyä olennaiseen.

Lemonsoft eKuitti -sovelluksen avulla skannaat, tiliöit ja toimitat kuittisi kirjanpitoon tai luottokorttilaskun liitteeksi. Voit myös skannauksen yhteydessä liittää kuittiin lounaaseen osallistujat, joten tätäkään tietoa ei tarvitse muistella jälkikäteen.

Kuitit odottavat sinua kirjanpidossa ja voit liittää ne haluamallesi laskulle, milloin tahansa ja missä tahansa. Kun kuvat ovat kirjanpidossa ne ovat myös arkistossa, joten sinun ei tarvitse säilyttää paperista kuittia.

Tuemme iOS, Android ja Windows Phone alustoja.

Lue lisää Lemonsoftin kotisivuilta: http://www.lemonsoft.fi/lemonsoft-ekuitti/

Voit testata palvelua sitoumuksetta 30 päivän ajan.
Mari Erkkilä

Talous- ja henkilöstöpäällikkö

Tietovarastomies

Kukapa ei olisi päässyt käymään ostoksilla kaupassa, jossa tuotteen saa mukaansa noutamalla sen liikkeen varastosta. Yleensä varastossa sinua tervehtii iloinen varastomies, joka antamasi tiedon perusteella häviää varaston syövereihin vain palatakseen kohta ostamasi tuote mukanaan. Varastomies tuntee varastonsa kuin omat taskunsa, tietää missä hyllypaikassa tuotteet sijaitsevat ja miten niiden luokse pääsee helpoiten. Varastomiehen tietämys, palvelualttius ja hyvin suunniteltu varasto ja muodostavat toimivan kokonaisuuden, mitä loppuasiakaskin arvostaa.

Monessa tietokoneohjelmassa, kuten Lemonsoftissa, on vastaavanlainen tietovarastomiehillä varustettu varasto, jota kutsutaan tietokannaksi. Tietokannassa tuotteiden sijaan on varastoituna yrityksen liiketoiminnan kannalta sitä tärkeintä, eli tietoa yrityksen liiketoiminnasta. Ihmisen sijaan tietovarastomiehen asiakkaana toimii sovellus tai sovelluksia, jotka pyytävät tietovarastomiestä etsimään varastostaan tietoa asiakkaista, tuotteista, laskuista jne. odottaen mahdollisimman nopeaa, luotettavaa ja tietenkin ystävällistä palvelua.

Tietokantoja ja niiden valmistajia on markkinoilla useita ja myös niiden ominaisuuksissa on paljonkin eroja. Toiset ovat hyviä tallentamaan tiedostoja ja kuvia, kun taas toiset tietokannat ovat erikoistuneet relaatiotiedon, eli  sellaisen tiedon käsittelyyn, jossa tieto on linkittynyt toiseen tietoon. Vielä vuosituhannen alussa oli vallalla käsitys, että sovelluksessa tulisi olla vain yksi kaikkivoipa tietokanta mihin sovelluksen keräämä ja tarvitsema tieto tulisi tallentaa. Tänä päivänä uskotaan enemmän malliin, jossa sovellus voi koostaa ja tallentaa tietoa eri tietolähteistä, jolloin tiedon käsittelyyn tietolähteessä voidaan valita kulloinkin parhain tapa.

Lemonsoft käyttää relaatiotiedon tallentamiseen Microsoft SQL Server tietokantaa, joka on laajalti tunnettu ja tunnustusta saanut tietokantamoottori. Microsoft julkaisi hiljattain SQL Server 2016 version tuotteestaan, jossa loppukäyttäjän näkövinkkelistä merkittävää on tiedon visualisointiin liittyvä voimakas kehitys. Liitetoimintatiedon hallinta (BI) ja raportointi (SQL Server Reporting Services, SSRS) tekniikat ovat kehittyneet aimo harppauksin eteenpäin ja samalla myös lähentyneet toisiaan. Tämä kehitys takaa sen, että jatkossa Lemonsoftin käyttäjät tulevat saamaan entistä tehokkaamman raportoinnin ja liiketoimintatiedon hallinnan osana Lemonsoft tuotetta.

Varastomieheltä edellytetään kykyä oppia uusia asioita ja tulla toimeen erilaisten asiakkaiden kanssa. Mutta, onko mahdollista, että tietokone ja tuo siellä asuva tietovarastomiehemme voisi oppia uusia asioita? Voisiko tietovarastomies itse analysoida tietovarastossa olevaa tietoa ja oppia siitä jotain? Kyllä voi! Koneoppiminen on tällä hetkellä suuressa nosteessa ja yksinkertaistettuna tarkoittaa sitä, että tietokone voi oppia ja omaksua uusia ”kykyjä”, kunhan sitä vain osataan opettaa oikealla tavalla. Opettamiseen käytetään ns. neuroverkkoja, joissa koneelle annetaan joukko tietosyötteitä ja palaute onnistumisesta. Niiden avulla neuroverkkoa sitten säädetään kohti haluttua lopputulosta.

Vielä muutama vuosi takaperin koneälyllä varustettujen sovelluksien tekeminen vaati sovelluskehitystiimiltä erittäin kovaa osaamista, eikä koneälyä juurikaan yrityssovelluksissa näkynyt. Pilvipalvelujen yleistymisen myötä on koneoppiminen kuitenkin tullut nyt sovelluksiemme käyttöön. Millaisia asioita kone voi sitten oppia? Hyvän käsityksen siitä, mitä kone voi oppia saa Microsoftin sovelluskehittäjille tarjoamien kognitiivisten palveluiden avulla. Näiden palveluiden avulla koneelle voidaan ”näyttää” kuvaa, jonka perusteella se osaa kertoa hämmästyttävän tarkalla tasolla mitä kuvassa on ja mitä siinä ollaan tekemässä. Esimerkiksi jos näytät koneelle kuvaa missä ihminen ui, osaa kone kertoa sinulle: ”a man swimming in a pool of water”. Jos kuvassa on ihmisiä, osaa tietokone kertoa lisäksi ihmisten sukupuolen, iän ja jopa ovatko ihmiset iloisia, surullisia tai kenties hämmentyneitä kuvassa.

Kuulostaa tieteiselokuvalta, eikö? Miten tämä liittyy nykyarkeen saatika toiminnanohjausjärjestelmän tietokantoihin keräämään tietoon? Kuvatiedon käyttäminen koneoppimisen esimerkkinä on helppo ymmärtää ja siksi sen kautta asiaa monesti lähestytään. Entäpä jos voisit joskus ennustaa tuotteiden menekkiä yhdistämällä tietokantaasi keräämän ostotiedon, viikonpäivät ja sääolosuhteet ja ennustaa annettujen tietojen perusteella menekin näiden muuttujien vaihdellessa? Mitä jos tuotantokoneestasi tietokantaan keräämän tiedon avulla voisit ennustaa seuraavan huoltoajankohdan, ilman että kone ennättää vikaantua ja aiheuttaa ylimääräistä harmia liiketoiminnallesi? Kaikki nämä edellä mainitut asiat ovat jo nyt mahdollista toteuttaa!

Uuden Microsoft SQL Server 2016 ja muiden teknologisten innovaatioiden myötä voitaisiin todeta, että nyt tietovarastomiehemme on saanut päivitetyn hyllyjärjestelmän lisäksi piirustuslehtiön, uudet värikynät ja kyvyn nähdä tulevaisuuteen!

 

Mika Matveinen

Ohjelmistoarkkitehti

ERP kulkee mukanasi

Joitain vuosia sitten ihmettelin lasten vimmaa pelata pelejä ja katsella videoita pienen kännykän ruudulta. ”Eikö sitä nyt kannattaisi pelata konsolilla isolta ruudulta?” ”Eikö elokuva nyt ole kivempi katsoa isolta ruudulta?” Lasten perustelut olivat selkeitä: Kännykkä on aina saatavilla aikaan ja paikkaan katsomatta. Äänetkin tulevat luurien kautta hienosti.

Voisiko sitä sitten kirjata tilaukset ja laskutkin kännykällä? Ei kyllä oikein käytettävältä ajatukselta tunnu. Tätä mieltä olin itsekin joitain vuosia sitten.

Toimme Windows-puhelimille ja -tableteille mobiilisovellukset vuonna 2013. Etenkin hyväksyntä otettiin vastaan hyvin, mutta laitealustavalikoima oli aika suppea. Tuotekehityksemme kannalta kyse oli irrallisesta sovelluksesta, jonka kehittäminen oli erilaista kuin Lemonsoftin-pääjärjestelmän.

Aloitimme vuonna 2014 LemonOnline-projektin, jonka päämääränä oli tuoda markkinoille selainpohjainen toiminnanohjausjärjestelmä, joka toimii kaikilla laitealustoilla. Projekti onnistui hyvin ja LemonOnline tuli markkinoille tänä vuonna. Bisneslogiikka on yhteistä Lemonsoft-työasemaversion kanssa ja ohjelmia voi käyttää rinnakkain. Tämä mahdollistaa parhaan mahdollisen käyttöliittymän valitsemisen omiin tarpeisiin.

Luonnollisia mobiilisti käytettäviä sovelluksia ovat mm. hyväksynnät, työajan leimaaminen, töiden käsittely, matkalaskut ja CRM. Työajan leimauksessa mukaan tulee paikkatietokin, joka tuo jo lisäarvoa verrattuna toimistolla tehtäviin leimauksiin.

Entäs ne tilausten ja laskujen kirjaamiset? Lasku syntyy aina jonkun muun toiminnon seurauksena, joten varsinainen laskun kirjaaminen onkin sitten jo ihan turhaa. Lasku vain syntyy automaattisesti ja LemonHub hoitaa toimituksen asiakkaalle. Yksittäisen tilauksen tallentaminen onnistuu hyvin älypuhelimellakin.

LemonOnline kulkee mukanasi kaikkialla. Pääset käyttämään kaikkia ohjelmia mobiilisti. Tähän voit vielä yhdistää LemonBI:n, jolloin liiketoimintasi tärkeät mittarit ovat jatkuvasti saatavilla reaaliaikaisesti.

Tutustu LemonOnlineen tarkemmin tästä. Seuraa myös LemonOnline-webinaarejamme ja osallistu niihin.

Kari Joki-Hollanti
Kehitysjohtaja

Myyntimies – perävalotakuun tarjoava huijari vai yrityksesi paras kaveri?

Yhteistyö.

Siihen perustuu onnistutunut projekti, oli sitten kyse talon rakentamisesta tai toiminnanohjausjärjestelmän vaihdosta. Hyvä yhteistyö puolestaan perustuu avoimuuteen, luottamukseen ja asiantuntijuuteen.

Blogikirjoituksen otsikko on tarkoituksella raflaava. Lehdistä saa välillä lukea isoista epäonnistuneista IT-järjestelmien käyttöönotoista, joissa on hukattu pahimmillaan vuosia aikaa ja miljoonia rahaa. Toki myös muissa projekteissa tössitään, räikeimpanä esimerkkinä varmasti Olkiluodon kolmosreaktori – alkuperäinen kustannusarvio on kolminkertaistunut ja toteutusaikataulu venynyt alkuperäisestä 4 vuodesta 13 vuoteen. Lisäksi hankkeessa on nostettu oikeusjuttuja puolin ja toisin.

Mistä onnistunut yhteistyö sitten lähtee liikkeelle?

Tätä voidaan lähestyä kahdesta kulmasta; projektin taustatietojen ja tavoitteiden selvittämiseen liittyvä kartoitus sekä Asiakkaan ja toimittajaehdokkaan välinen avoimuus. Avoimuus on sitä, että avataan yrityksen prosesseja, toimintamalleja ja myös haasteita ja tavoiteita laajasti. Omien prosessien kuvaaminen ja piirtäminen valmiiksi ennen ensimmäistä tapaamista helpottaa ja nopeuttaa asioiden ymmärtämistä. Vaikka monissa yrityksissä asioita hoidetaan samankaltaisesti, on jokaisessa yrityksessä omia vakiintuneita tapoja ja toimintamalleja, jotka on syytä tuoda esiin.  Osaava, asiantunteva myyjä ymmärtää näiden perusteella tehdä toimivan ratkaisuehdotuksen. Onnistuneen projektin ensimmäinen askel on siis asiantuntevan myyjän tekemä kartoitus.

Mitä kartoituksella sitten tarkoitetaan?

Kartoituksessa käydään yrityksen toimintamallit ja prosessit laajasti läpi ja peilataan niitä tarjottavan järjestelmän toimintamalleihin. Tämä on asiakkaalle ilmaista konsultointia – se kannattaa hyödyntää! Ennen kartoitusta asiansa osaava ja konsultoiva myyjä on tutustunut yritykseen ja kerännyt kattavat perustiedot. Kartoituksessa yritys saa parhaimmillaan vinkkejä oman busineksen kehittämiseen ja ainakin prosessien kehittämiseen. Ympäripyöreä, pintapuolinen kartoitus tuo ympäripyöreän ja pintapuolisen lopputuloksen. Tästä syystä tämäkin vaihe tulee hoitaa asiantuntevasti ja kunnolla. Tapaamiseen on syytä varata aikaa ja pyytää paikalle eri osastojen tai toimintojen vastuuhenkilöt.

Onnistunut kartoitus antaa myös hyvän pohjan alkavalle käyttöönotolle, tällöin aiemmin mainitun kaltaiset aikataulu- tai budjettiongelmat vältetään – heti alussa tiedetään, mihin ollaan menossa, mitä reittiä ja millä vauhdilla. Toki jokaisessa projektissa tulee pieniä yllätyksiä, mutta näihinkin on onnistuneella kartoituksella ja suunnittelulla jo osattu varautua. Kaikki myyjät toki eivät ole tällä osaamisen tasolla, mutta sen kyllä huomaa usein heti alkuvaiheessa. Silloin kannattaa miettiä, onko tällaisen myyjän tai toimittajaehdokkaan kanssa järkevää jatkaa keskustelua.

Kotiläksyt – tekemistä puolin ja toisin

Jo alussa mainittiin yhteistyö. Tämä tarkoittaa sitä, että jo järjestelmän hankintavaiheessa kartoituksen perusteella myös asiakkaalle tulee mietittäviä, selvitettäviä ja myös tehtäviä asioita. Tämä sitouttaa henkilöstön alkavaan projektiin jo hankintavaiheessa ja edelleen, asiantunteva myyjä on paras pelikaveri tässä asiassa. Parhaimmillaan aiemmin kuvattuja prosesseja voidaan virtaviivaistaa ja tätä kautta kehittää koko yrityksen toimintaa.

Kohti onnistunutta käyttöönottoa

Avoimuudella omien prosessien ja tavoitteiden suhteen, osaavan asiantuntijamyyjän tuella ja luottamuksella puolin ja toisin luodaan onnistunut aloitus uudelle järjestelmälle ja sen käyttöönotolle. Käyttöönotto ja siihen valmistautuminen on oman blogitekstin aihe, siitä lisää tuonnempana.

Me Lemonsoftilla haluamme osaltamme olla varmistamassa suomalaisten yritysten kilpailykyvyn globaalilla pelikentällä. Kaipaako Sinun yrityksesi kehitysaskelta? Heitä haaste meille!

 

 

jakke

 

 

Jakke Vyyryläinen
Myynti- ja asiakkuusjohtaja
010 328 1019

Försäljaren är en viktig aktör då du funderar på byte av affärssystem

Samarbete

För att ett projekt skall lyckas krävs det samarbete, oavsett om det handlar om att bygga ett hus eller byte av affärssystem. Ett bra samarbete grundar sig  i sin tur på öppenhet, förtroende och expertis.

Med jämna mellanrum skrivs det i tidningar om stora IT-projekt som misslyckas och där det i värsta fall har kastats bort flera års arbete och miljontals euro. Vi får höra om skräckexempel såsom Olkiluoto 3, där man misslyckats totalt. Budgeten tredubblades och projektet drog ut på tiden, från de planerade 4 åren, till 13 år! Att inte nämna de många åtal vi fått läsa om i löpsedlarna angående detta misslyckade projekt.

Vad baserar sig ett bra samarbete på då?

För det första bör man tänka på att noggrant kartlägga projektets bakgrund och mål. För det andra handlar det om att sträva till öppenhet mellan kund och leverantör. Öppenhet betyder i praktiken att man tillsammans går igenom företagets processer, rutiner, utmaningar och mål. Om företags processer finns till pappers redan vid första mötet, så underlättar detta betydligt förståelsen för hur man jobbar inom företaget och på sätt sparar man mycket tid. Även om man i de flesta företag gör saker på ungefär samma sätt, så finns det alltid företagsspecifika rutiner som skiljer sig från massan, och dessa är viktiga att lyfta fram. På basen av den tillgängliga informationen kan en sakkunnig försäljare ta fram en fungerande helhetslösning. Första steget i ett lyckat projekt är alltså kartläggningen som görs av försäljaren.

Vad menas då med kartläggning?

Kartläggningen innebär att man går igenom företagets procedurer och processer, och speglar dessa mot programvarans funktioner. Konsulteringen är gratis för kunden, så det löns att utnyttja den! Före kartläggningen har en sakkunnig försäljare samlat åt sig så mycket information som möjligt om företaget. I bästa fall, kan företaget få tips på hur man kan utveckla businessen och finslipa processerna. En kartläggning som görs bara “ditåt”, kommer även att resultera i nånting som också bara är ”ditåt”. Därför är det viktigt att det här skedet görs sakkunnigt och grundligt. Det lönar sig att satsa tid på mötet, samt att se till att de ansvariga för företagets olika avdelningar finns på plats.

En lyckad kartläggning ger också en bra grund till Startprojektet, så att man kan undvika problem med tidtabeller och budgeter. Det är klart att alla projekt råkar ut för överraskningar, men med en välgjord kartläggning och planering så kan man förbereda sig på sådana saker. Alla försäljare har dock inte den expertis som krävs för att klara av detta, men det brukar man nog märka ganska snart. Då lönar det sig att ta sig en funderare, vill man gå vidare med en sådan leverantör?

Hemläxa – något båda måste göra

Redan i början skrev vi om samarbete. Det innebär att även kunden måste fundera och ta reda på saker, redan i upphandlingsskedet. Detta i sin tur bidrar till att personalen engageras i det kommande projektet redan från början. Expertisen  som försäljaren har att erbjuda är något oerhört viktigt, även i detta skede. I allra bästa fall finner man möjligheter att förenkla processer och utveckla hela företagets verksamhet.

Vägen till ett lyckat Startprojekt

Genom att vara öppen om sina processer och mål, få stöd av kunniga människor, bygger man en bra grund för att ta i bruk ett nytt affärssystem. Saker man bör tänka på då man tar i bruk ett nytt affärssystem, kommer vi att behandla i ett senare blogginlägg.

Vi på Lemonsoft vill vara med och trygga konkurrenskraften för finländska företag, i en global och hårt konkurrensutsatt miljö. Är ni i behov av nästa steg i utvecklingen? Vi tar gärna emot utmaningen!

Tomi Seppälä
Försäljningschef
010 328 1023

Täyden palvelun konesali

Ohjelmistoa hankittaessa tulee vastaan päätös myös ohjelmiston teknisestä ympäristöstä, eli ohjelman ja tietokannan sijoituspaikasta. Ympäristö voi olla yrityksen omissa tiloissa sijaitseva fyysinen palvelin, kumppanilta hankittu palvelu tai täyden ylläpidon pilvipalvelu. Palvelinratkaisua valittaessa on tärkeää ottaa huomioon myös ympäristön palvelutaso, päivityksien saatavuus, sekä ylläpidon aiheuttamat kustannukset. Hyvän palvelutason ympäristö varmistaa ohjelmistojen käytettävyyden ajasta ja paikasta riippumatta. Oikean ratkaisun etsiminen ja käyttöönotto voi olla haastavaa, kun tarjolla on vähintäänkin kymmeniä toteutustapoja ja vielä suurempi määrä palveluntarjoajia.

Lemonsoft tarjoaa ratkaisuksi täysin Lemonsoftin omassa konesalissa tuotettua nykyaikaista palvelua. Konesaliratkaisu on rakennettu nimenomaan Lemonsoft –ohjelmiston käytettävyyttä silmälläpitäen. Oma konesali takaa aina Lemonsoft -ohjelmistoasiantuntijoiden ylläpitämän ympäristön, joka on myös ajantasaisesti päivitetty uusimpiin versioihin. Ohjelmisto ja ympäristö kulkevat konesaliratkaisussa rinnakkain, voit siis aina luottaa että niin palvelinympäristö kuin ohjelmakin on ajantasalla. Ongelmatilanteissa käyttäjiä palvellaan saman tutun Lemonsoftin Servicedeskin kautta ohjelmistoon ja ympäristöön liittyvissä asioissa, eikä yhteydenottoja tarvitse tehdä useaan eri osoitteeseen. Ympäristö ei vaadi asennuksia tai ylläpitoa käyttäjiltä, jolloin käyttäjät voivat keskittyä täysin omaan työhönsä.

Konesaliratkaisu tarjoaa mahdollisuuden käyttää kaikkia Lemonsoft –tuotteita rajoituksetta. Yhteydet muihin ohjelmistoihin, tiedostojen tallentaminen ja siirtäminen, sekä tarvittaessa myös omien ohjelmien asentaminen onnistuvat normaalisti. Uusi LemonOnline –ratkaisu on toteutettu ympäristöön automaattisesti skaalautuvaksi. Käyttäjille tämä tarkoittaa rajoittamatonta LemonOnline kapasiteettia, jolloin ympäristön käyttö ei hidastu käyttäjämäärästä riippumatta. Voit käyttää LemonOnline –tuotetta verkkoyhteyden yli miltä päätelaitteelta tahansa, ajasta tai paikasta riippumatta.

 

Lataa Lemonsoftin asennusvaihtoehdoista kertova opas tästä.

Tuukka Karttunen
Tietohallintopäällikkö
Lemonsoft Oy

Scrum Lemonsoftilla

Tässä kirjoitelmassa kerron Scrumin käytöstä Lemonsoftilla. Tarkoitukseni ei ole tehdä syväluotaavaa pohdintaa joka tarraa syvälle scrumin teorioihin, vaan kertoa enemmän käytännönläheisesti eri vaiheistamme Scrumin käyttöönotossa. Scrumissa on harvoja hyvin tarkasti kirjoitettuja sääntöjä ja parhaista Scrumin käyttötavoista käydäänkin jatkuvasti kiivasta keskustelua. Scrum muokkautuu yleensä jonkin verran sitä käyttävän organisaation mukaiseksi, mutta liikaa se ei saa karata perusteoriasta tai silloin ei voida ainakaan puhtaalla omallatunnolla sanoa Scrumin olevan käytössä organisaatiossa. Jos haluat tarkentaa nopealla ja kevyellä tavalla omaa Scrum tietämystäsi suosittelen lukemaan Ken Schwaberin ja Jeff Sutherlandin kirjoittaman oppaan The Scrum Guide. The Scrum Guide löytyy helposti internetin hakupalveluja käyttämällä. Teoksesta löytyy myös tarkasti Scrum-ammattilaisten kanssa suomennettu versio.

Itse sain scrumiin ensikontaktini hyvin suppeasti ammattikorkeakoulussa yleisiä ohjelmistokehitystekniikoita läpi käytäessä. Sittemmin tutustuin aiheeseen silloisen esimieheni lyhyen esittelyn perusteella ja lähdin hänen kannustamanaan tutustumaan aiheeseen tarkemmin ScrumMaster -sertifikaatin muodossa. Jo tätä ennen olimme valmiiksi kuitenkin tutustuneet aiheeseen ja päättäneet kokeilla scrumin käyttöä.

Itse scrumin teoria on melko selkeää ja helposti ymmärrettävää, mutta sen käyttöönotto ja käytäntöön sovittaminen ei mennytkään ihan niin helposti. Otimme teoriasta aina pieniä osia kerrallaan käyttöön, kuten koko scrumin teoriassakin kehotetaan toimimaan. Paransimme tekemistä jokaisen kehityssyklin aikana, aina palanen kerrallaan, jokaisessa sprintissä kohti parempaa laatua ja mielekkäämpää tekemistä. Alussa meilläkin esiintyi pientä muutosvastarintaa, joka sitten ajan myötä karsiutui pois. Nyt kukaan meistä ei enää haluaisi palata menneeseen.

Ensimmäinen konkreettien asia Scrumin käyttöönoton kanssa oli tarkempi lyhyen tähtäimen ennakoiva suunnittelu. Scrumissa työt toteutetaan saman mittaisina toistuvien sprinttien sisällä. Sprintit ovat suojeltuja ulkopuoliselta häirinnältä työn etenemisen ja sen laadukkuuden varmistamiseksi. Lemonsoftilla työt eivät koskaan lopu, aina on tarjolla uusia ajatuksia ja aina löytyy jotain parannettavaa. Tällöin työlistan suunnittelu on suurelta osin asioiden priorisointia. Sprintin suunnittelu sen ensimmäisenä päivänä realisoi kuitenkin sen tarpeen, että koko tiimille tulee olla valmiiksi suunniteltua työtä.

Käytämme töiden seurantaan Microsoftin Team Foundation Serveriä, jossa on mahdollista käyttää myös Scrum projektinhallinnan viitekehykseen liittyviä prosessimalleja. Näin saamme suunnitellut työt ja niille arvioidut toteutusajat näkyviin helposti tiimin tai niin haluttaessa myös henkilön tai vaikka koko tuotekehityksenkin tasolta. Scrum keskittyy kuitenkin tiimiajatteluun.

tiimien kuormitustilanne

 

 

 

 

 

Kuva: Tiimien kuormitustilanne

Töiden etenemistä sprintin kestoon nähden seurataan ns. Burndown -kaaviolla, jonka ajatus on seurata mahdollisimman realistisesti aina parhaan sen hetkisen arvion mukaista sprintillä jäljellä olevan työn määrää.

burntown chart

Kuva: Burndown-chart 

Töiden etenemistä seurataan päivittäisellä tasolla ns. daily scrum -palavereissa. Palavereiden ideana on synkronoida tiimin tekeminen sekä varmistaa, että kaikki pääsevät töissään eteenpäin. Palaveri kestää maksimissaan 15 minuuttia. Mikäli daily scrumin aikana selviää, että jollain tiimin jäsenellä on ongelmia tai este töiden etenemisen suhteen, sovitaan asian ratkaisemiseksi daily scrum palaverin ulkopuolinen hetki vain asian ratkaisemiseen tarvittavien henkilöiden kanssa. Daily scrumin tarkoituksena on myös vähentää päällekkäisten toisiinsa vaikuttavien töiden yhtäaikaista tekemistä, ilman että kehittäjät olisivat edes tietoisia asiasta.

Lemonsoftilla daily scrumeissa seurataan henkilötasolla noin työpäivän mittaisiksi pilkottuja, sprintissä kehitettävien ominaisuuksien valmistumiseen liittyviä töitä. Näitä tavallisimmin ovat ”konepellin alla olevat” kenties arkkitehtuurisetkin muutokset ja niiden suunnittelu, itse ominaisuuksien koodaus ja näyttöjen suunnittelu, testaus ja tulevan testauksen suunnittelu sekä sisäinen ja ulkoinen dokumentointi. Sprintin sisäisillä pienemmiksi kokonaisuuksiksi pilkotuilla töillä eli taskeilla on vain kolme tilaa ”To do”,”In progress” ja ”Done”. Eli näkökulmana kiinnostaa ainoastaan onko taski vielä aloittamatta, parhaillaan käynnissä vai jo valmis. Taskin tilanmuutos tai jäljellä olevan arvioidun työmäärän muutos vaikuttaa suoraan aikaisemmin esiteltyyn Burndown -kaavioon. Taskit tulisi myös suunnitella niin pieniksi, että niiden tilan vaihtumisia pitäisi tapahtua daily scrumien välillä, jolloin myös paikoilleen jumiutuminen havaitaan helpommin.

sprint board

Kuva: Sprint board

Töiden seurattavuus on parantunut Lemonsoftilla scrumin käyttöönoton myötä, sillä nyt näemme nopeasti mitä tietyille töille kuuluu tai mikä on tiimin sen hetkinen kuormitusaste.

Teoriassa tiimi on itse sitoutunut sprintin töihin, jotka se aikoo saada valmiiksi sprintin aikana. Töihin tulee sitoutua, mutta käytännössä joskus käsitys työn sisällöstä muuttuu aloitetun työn myötä sen verran paljon, ettei työtä saadakaan suunnitellussa ajassa valmiiksi. Myös sairastapaukset ja muut vastaavat yllätykset vaikuttavat tiimin työtehoon. Scrumin tarjoamien seurantatyökalujen ansioista asioihin pystytään reagoimaan nopeasti. Tarkoitus ei ole yrittää lakaista ongelmia maton alle, vaan koko Scrumin idea on nostaa erilaiset, välillä kivuliaatkin ongelmat esiin. Scrum ei kerro mitä niille tehdään, mutta se pakottaa tekemään asioille jotain.

Asioihin ja ongelmakohtiin voidaan reagoida usein jo sprintin aikana. Jos ongelmaan ei voida kesken sprintin vaikuttaa, se siirtyy seuraavalle. Retrospektiivipalaverissa, joka pidetään sprintin lopussa, käydään läpi hyvin menneet sekä kehitystä kaipaavat asiat ja laaditaan suunnitelma kehitysten jalkauttamiselle.

Sprintin aikana tehdyt toteutukset tai muutokset käydään läpi sprinttikatselmuksessa. Sprinttikatselmukseen on kutsuttu asiaankuuluvat sidosryhmät tai heidän edustajansa. Sprinttikatselmuksessa tarjotaan myös paikka kehitystiimin ulkopuoliselle palautteelle, jonka perusteella esimerkiksi sprintissä valmistunutta ominaisuutta voidaan kehittää edelleen. Asiakkaamme antavat normaalisti palautteensa helpdesk-järjestelmämme kautta kehitysideoiden muodossa.

Asiakkaamme kirjaavat satoja kehitysideoita. Viime vuonna niitä kirjattiin 1524 kappaletta. Tämä tarkoittaa keskiarvollisesti 29 kehitysideaa joka viikko. Lemonsoftin tuoteomistajat käsittelevät kehitysideat normaalisti viikoittain ja koostavat tehtyjen kehitysideoiden pohjalta töitä tuotekehityksen työlistalle.

Hyväksytyt kehitysideat, pakolliset työt sekä ennen kaikkea tuotteen visio on product backlogissa, joka sisältää ideaalitilanteessa tarvittavan tarkalle tasolle määriteltyjä töitä noin kahdelle seuraavalle sprintille. Liian suuri product backlog johtaa hallittavuudelta raskaaseen kokonaisuuteen. Product backlogin tulee kuitenkin sisältää aina sen verran työtä, ettei työlista pääse loppumaan kesken, myöskään siinä tapauksessa jos sprintin tavoitteet täyttyvätkin ennalta arvioitua nopeammin.

Koostetaan lyhyesti Scrum -prosessin pääpiirteet vielä kasaan. Kaikki tekeminen pyörii sprinttien aikataulutuksen mukaan. Sprintit toistuvat samankokoisina paloina luoden rytmiä sekä kiinnekohtia muuten usein hyvin erilaisiin ja välillä hajanaisenkin tuntuisiin ohjelmistokehitystehtäviin.

Kaikki alkaa sprintin suunnittelussa, jossa kehittäjille esitetään tuotepäälliköiden priorisoima lista ohjelmaan halutuista ominaisuuksista. Tiimit hyväksyvät itse oikean määrän työtä sprinttiin, tarkoittaen sitä minkä määrän työtä he arvioivat kykenevänsä saamaan valmiiksi sprintin aikana yhdessä sovitun määritelmän mukaisesti. Sprintin työt kerätään siis product backlogista, niille asetetun prioriteetin mukaisesti, sekä sen mukaan mitä tiimi kokee järkeväksi toteuttaa seuraavaksi ja mitä se arvioi saavansa valmiiksi sprintin aikana. Kehittäjä antaa työlle viimeisen työmääräarvion. Sprintin ajaksi työlista suljetaan ja uusia töitä ei oteta vastaan. Työn edistymistä tarkkaillaan päivittäin, jotta mahdolliset esteet työn etenemiselle saataisiin raivattua nopeasti pois tieltä. Sprintin lopussa syntyy potentiaalisesti julkaisukelpoinen ohjelmaversio. Versioon tulleet muutokset käydään sitten läpi yrityksen sisäisessä sprinttikatselmuksessa, jossa kerätään vielä sidosryhmiltä palautetta uusista ominaisuuksista ja tämän perusteella mahdollisesti päivitetään tuotteen kehitysjonoa eli product backlogia. Sprintin retrospektiivissa kerätään palautetta, miten sprintin tai koko Scrum-prosessin kulku on sujunut. Jokaisella kierroksella pyritään tekemään aina pieni parannus, miten seuraavasta sprintistä saataisiin taas hieman edellistä mielekkäämpi ja tuottavampi, parempi sprintti.

scrum prosessi

Kuva: Scrum-prosessi yksinkertaistettuna

Mainitsin Scrumin parantaneen töiden seurattavuutta käynnissä olevan sprintin suhteen. Tämän lisäksi Scrum yhdistettynä Team Foundation Serveriin (TFS) luo meille taas uusia mahdollisuuksia. TFS:sään kirjataan alkuperäinen työn tarve, jolloin myöhemmin voidaan ominaisuutta muokattaessa palata helpommin siihen, mikä itseasiassa oli aikaisemmin toteutetun ominaisuuden alkuperäinen tarve. Töihin voidaan liittää siis määrittely, ohjeet, testit ja suora viittaus työn johdosta tehtyihin koodimuutoksiin. Näin muutosten tai mahdollisesti tehtyjen virheiden alkuperä on helpompi selvittää ja suunnitella tulevia muutoksia.

scrumblogi1

 

 

 

 

 

 

scrumblogi1

 

 

 

 

 

Siitä lähtien kun TFS on ollut käytössämme töiden seurantaan, olemme pystyneet jäljittämään helpommin myös yksittäisten kehitysideoiden kulun. Tulevaisuuden haaveet vievät meillä yhä täsmällisempään ja parempaan suuntaan myös asiakkaidemme informoimisen suhteen. Kaikki kehitys kuitenkin vaatii aikansa.

Tänä vuonna kirjatuista hyväksytyistä kehitysideoista jokaisen voi paikantaa esimerkiksi suoraan tuotekehityksen työlistalta kehitysidean numeron perusteella.

kustannuspaikat

 

 

 

 

 

 

 

 

 

 

 

Scrum on luonut meille mallin, jonka perusteella näemme selkeästi missä kohtaa tuotekehitysprosesseja meillä on suurimmat haasteet. Näihin haasteisiin olemme vastanneet yksi kerrallaan. Suurimmat jo tehdyt muutokset liittyvät organisaation rakenteeseen. Seuraavat haasteet liittyvät julkaisujärjestelmään, versionhallintaan sekä uuteen selainpohjaiseen tuotteeseemme LemonOnlineen.

Ehkä nämä tulevat muutostarpeet olisi tiedostettu ilman Scrumiakin, mutta sen ansiosta meillä on selkeämpi malli ja tapa selvittää tiemme maaliin muutosten läpi. Scrum keskittyy enemmän ketterään tekemiseen ja lyhyen tähtäimen suunnitteluun, mutta myös pitkäntähtäimen suunnitelmat tulee olla tehtynä, varsinkin Lemonsoftin kaltaisessa elinkaarettomassa tuotteessa. Suurien asioiden tekeminen vaatii useita sprinttejä ja lopullinen visio tulee olla kaikille kehittäjille selvillä.

Informaatioteknologian, materiaalinhallinnan ja taloushallinnon maailmaan liittyy paljon lyhenteitä ja hienoja sanoja, joten lopuksi nippelitietona, mistä termi Scrum itseasiassa tulee. Scrum viittaa rugbyn aloitusryhmitykseen, josta joukkueen jäsenet reagoivat tilanteeseen hyvin nopeasti ja itseohjautuvasti. Suomalaiselle rugby on lajina melko tuntematon, mutta jos jaksoit lukea kirjoituksen loppuun, etsi käsiisi video tuosta aloituskuviosta, niin ymmärrät vertauksen paremmin.

Juha-Matti Lehtimäki
Tuotekehityspäällikkö
Lemonsoft Oy

rugby