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!

Seppala_Tomi_4_2016

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

Rentouttavaa kesää!

Keskikesän juhlaa vietimme juuri menneenä viikonloppuna ja kohti intiaanikesää olemme menossa – toivottavasti!

Muutama sananen tässä vaiheessa kuluneesta alkuvuodesta. 6.2.2016 juhlistimme Lemonsoftin 10–vuotista taivalta Vanajanlinnassa henkilökuntamme ja kumppaneidemme kesken. Juhlava tilaisuus oli mukavan rento ja antoi varmasti meille kaikille uutta puhtia seuraavalle kymmenluvulle.

Kauan odotettu LemonOnline näki päivänvalon kevätauringon aikaan ja ensimmäiset asiakaskäyttöönotot ovat jo toteutuneet. Viimeistään loppukeväästä toteutettu LemonOnline ja LemonBI -roadshow osoitti sen, että kiinnostus näihin tuotteisiin niin nykyisten kuin uusienkin asiakkaiden keskuudessa on erittäin voimakasta. Olemme panostaneet vahvasti resursseja näiden tuotteiden kehittämiseen. Uusia LemonOnline tuotteita valmistuu kuukausittain ja ajantasaisinta informaatiota niistä saat kotisivuiltamme sekä omalta Lemonsoft myyntiyhteyshenkilöltäsi.

Asiakaspalvelumme toukokuussa viestimä ja 1.9.2016 voimaanastuva palveluluokkamuutos on merkittävä asiakaspalvelun laadulliseen kehittämiseen liittyvä hanke koko Lemonsoftin 10 –vuotisessa historiassa. Olemme keränneet jo pitkään palautteita asiakkailtamme liittyen asiakaspalveluun ja –kokemukseen. Muun muassa näiden pohjalta olemme toteuttaneet nyt syksyllä voimaan tulevan muutoksen, mikä varmasti vie asiakaspalveluamme laadullisesti uudelle tasolle ja samalla varmasti lisää tyytyväisyyttä entisestään.

Kuluvan vuoden viiden ensimmäisen kuukauden aikana oli 184 uutta asiakasyritystä valinnut Lemonsoftin omaksi toiminnanohjausjärjestelmäkseen. Uusien asiakkuuksien sisäänmarssi jakanee näin hyvin edellisvuoden linjaa, jolloin Lemonsoftin valitsi omakseen yli 400 uutta asiakasta. Olemmekin tällä hetkellä mukana jo yli 15000 yrityksen arjessa.

Liikevaihtomme on kehittynyt myös positiivisesti alkuvuoden ensimmäisinä kuukausina. Edellisvuoteen verrattuna liikevaihtomme on kasvanut noin 15%.

Luonnollisesti kun tuotetta ja palveluita kehitetään ja samalla uusien asiakkuuksien määrä kasvaa voimakkaasti tarvitaan siihen osaavia ammattilaisia. Olemme rekrytoineet jo kuluneen vuoden aikana 12 uutta Lemonsoftilaista. Syksyllä tulee vielä jokunen lisää.

Mutta riittäköön tuo edellä kerrottu alkuvuoden virallisemmista faktoista. Nyt on aika rentoutua ja viettää kesälomaa. Haluan toivottaa niin omasta kuin koko Lemonsoft Oy:n puolesta sinulle rentouttavaa ja virkistävää kesää!

Ja muistathan että Lemonsoft palvelee asiakkaitaan läpi Suomen suven.

Jari Rättyä
toimitusjohtaja
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

Onko kritiikki olemassa sen kohdetta varten vai onko se olemassa kehittämistä varten?

PK-yrityksen hallitustyöskentelyssä on tärkeää lähteä ajatuksesta, jossa kritiikki liittyy kehittämiseen. Mitä paremmin kritiikkiä voidaan rakentavasti käsitellä sitä antoisampia ovat lopputulokset. Hallitustyöskentely ei mielestäni kaipaa ”joojoo -miehiä”, vaan aitoa ja jopa rohkeaakin kannanottoa asioihin.

Hallituksen kokoonpano ja hallituksen jäsenten roolitukset ovat aina yrityskohtaisia, kuten myös vuosikello, jonka mukaan hallitus monessa yrityksessä työskentelee. Roolitusten ja teemoituksen lisäksi toimivan hallitustyöskentelyn avainasioita on valmistelu, arviointi, kannanotot ja päätöksen tekeminen.

Teemoituksissa on melkoisia eroja ja taitaa myös olla niin että teemoituksia ei välttämättä monessa tapauksessa etukäteen tehdä, vaan toimitaan sen mukaan mitä asioita kulloinkin nousee käsiteltäväksi kokouksiin. Näkisin kuitenkin että joitakin teemoja, kuten esimerkiksi riskit, budjetin käsittely, myyntistrategia ja mittaaminen voisivat ainakin olla aikataulutettuja asioita.

Miten syvälle hallitustasolla sitten vaikka mittaamisessa voidaan mennä, riippuu pitkälti organisaation rakenteesta ja tietysti myös järjestelmästä, joka toiminnanohjauksessa on käytössä. Jokainen tietää että ”sitä saat mitä mittaat!”

Mittaamisessa asiat ovat menossa yhä enemmän reaaliaikaisuuteen ja sitä kautta toiminnanohjausjärjestelmän rooli korostuu arjessa. Uudet online-tyyppiset ratkaisut työnohjauksessa ja kirjauksessa ovat monessa tapauksessa välttämättömiä jos halutaan tietää projektin edistymistä ja vaadittavien resurssien kohdistamisesta ja tietysti samalla saadaan seurattua kannattavuutta.

Hyvän johtoryhmän apu on korvaamaton kun määritellään arjen mittareita, joista on hyötyä myös hallitukselle päätöksen tueksi. Hallituksen tekemät päätökset ovat kuitenkin hyvin usein muuta kuin reaaliaikaisia, pikemminkin kauaskantoisia yltäen jopa usean vuoden päähän.

Kun hallituksen kokouksen pöytäkirjassa lukee ”päätettiin” eikä vain todeta asia käydyn läpi, niin silloin päätöksellä on mielestäni enemmän vaikuttavuutta ja se ohjaa ja vaatii myös toimitusjohtajaa toimimaan.

Hallituksen tulisi ja tulee vaatia itseltään päätöksiä. Hallituksen täytyy pyrkiä toteuttamaan omistajien tahtotilan mukaista strategiaa niin, että se on päätöksissä tunnistettavissa ja jalkautettavissa yrityksen toimintaan.

Harri Karttunen
Hallituksen puheenjohtaja
Lemonsoft Oy

Henry Laurence Gantt (1861-1919)

GANTT-kaavio. Olet todennäköisesti törmännyt tuohon termiin vaikkapa tuotannonsuunnittelun tai projektinhallinnan yhteydessä.

Itse pohdiskelin aikoinani, mistä GANTT-kaavion nimi tulee, mitä se tarkoittaa? Onko se kryptinen lyhenne (amerikkalaiseen tyyliin) jostakin monimutkaisesta sanajoukosta? Selitys on yksinkertainen.

Henry Laurence Gantt oli amerikkalainen koneinsinööri ja johdon konsultti, jonka saavutuksiin kuuluu mm. GANTT kaavion kehittäminen (1910-1915). GANTT-kaavion nimi juontaakin juurensa sen kehittäjään. Tai jos ollaan aivan tarkkoja, samankaltaisen mallin kehitti jo aikaisemmin (1896) puolalainen ekonomisti ja insinööri Karol Adamiecki, mutta se ei tullut tunnetuksi länsimaissa kieliongelmien vuoksi.

GANTT-kaavio syntyi, kun Gantt työskenteli laivanrakennusteollisuudessa ensimmäisen maailmansodan aikana. Se muutti tavan, jolla työtä johdettiin. GANTT-kaavio pääsikin tositoimiin todella isoissa hankkeissa, kuten Hooverin padon rakentamisessa (1931).

Kaaviota on ajan saatossa kehitetty edelleen ja siitä onkin tullut tehokas graafinen työkalu kuvantamaan tuotanto- ja projektiaikatauluja ja niiden edistymistä.

Visuaalisuus vs. listaukset

Visuaalinen merkitsee näköaistia koskevaa, siihen perustuvaa, näkyvää.  Puhutaan visuaalisesta hahmottamisesta ja havainnoinnista. Käytätkö jotakin kalenteriohjelmaa, kuten vaikka Outlookia?
Jos katsot alla olevia kuvia, kumpi puoli vastaa parhaiten näkymää, jota käytät?

cal-1  cal-2

 

 

 

Uskoisin, että vastaat ”oikea puoli”. Uskon näin siksi, että pystyt hahmottamaan heti yhdellä silmäyksellä viikon ohjelmasi katsomalla oikeanpuoleista näkymää.

Vasemmalla puolella on listamuotoinen näkymä, joka kyllä sisältää täsmälleen samat tiedot, mutta joudut käyttämään paljon enemmän aikaa hahmottaaksesi aikataulusi ja minkä verran kukin tehtävä kalenterissa vie aikaa päivästä. Tai mihin ajankohtaan päivää se osuu? Onko se koko päivän kestävä tapahtuma?

Entä jos sinun pitää siirtää kalenterimerkintää tai muuttaa sen kestoa? Oikean puoleisessa näkymässä voi raahata tapahtuman toiseen ajankohtaan, voit muuttaa kestoa alusta tai lopusta. Kaksoisklikkaamalla voit porautua tarkempiin tietoihin.

Ihminen hahmottaa paremmin, kun asiat esitetään graafisesti. Herra Gantt olisi voinut jatkaa pelkästään listojen tutkailua ja yrittää hahmottaa päässään päivämääriä pyöritellen, milloin laivatuotannossa minkäkin asian pitäisi tapahtua. Sen sijaan hän meidänkin hyödyksemme kehitti graafisen näkymän, jonka avulla voimme visuaalisesti hahmottaa tuotannon tai projektin tilanteen.

Tuotannonsuunnittelu GANTT

Tuotannonsuunnittelussa voi olla monesti vaikeuksia hahmottaa tuotannon tilanne, jos tarkastellaan sitä vain listamuotoisena näkymänä. Meneekö kaikki aikataulun mukaan vai ollaanko jäljessä? Sama ongelma on projektien kanssa.

Tarvitaan työkalu, josta voisi nopeasti nähdä ajankäytön visuaalisesti.

Verrataan tuotannon kautta tuota aikaisempaa kalenteriesimerkkiä. Jos katsot alla olevia kuvia, kumpi puoli vastaa paremmin kysymykseen, onko tuotanto ajallisesti tarkasteltuna kohdallaan?
gantt

 

 
Uskoisin, että vastauksesi on etualalla oleva kuva.
Samoin kuin kalenteriesimerkissä, listamuotoinen näkymä kyllä kertoo kaikki tiedot, mutta joudut tarkastelemaan tuotantoajankohtia riveiltä ja yrittää hahmottaa, mihin ajankohtaan työt sijoittuvat. Ja astetta vaikeampaa siitä tulee, kun yrität hahmottaa resurssien käyttöastetta.

Lemonsoftin Tuotannonsuunnittelu GANTT tekee tuotannon suunnittelusta helpompaa juuri sen tuoman visuaalisen näkökulman vuoksi. Mutta ei se ole vain kiva näkymä tuotantoon, josta on mukava (Kanarian saarilla) jalat pöydällä leväten seurata, kuinka työt valmistuvat yksi kerrallaan juuri niin kuin oli suunniteltukin.

Se on kyllä näkymä ja sitä voi käyttää vaikka tuotannon näyttönä sellaisenaankin. Mutta se on paljon enemmän. Se on työkalu tuotannon suunnitteluun. Visuaalinen näkymä kertoo nopeasti tilanteen ja sen toiminnoilla voit tehdä tarvittavat muutokset. Hiiri vain käteen ja voit siirtää tuotantotöitä suoraan GANTT näytössä, voit muuttaa niiden kestoa ja voit tarkastella töiden tarkempia tietoja.

Jos olet samaa mieltä kanssani siitä, että visuaalinen havainnointi helpottaa elämää – tai tuotannonohjausta, ota yhteyttä! Jutellaan asiasta lisää!

Juha Kalliola
ERP-konsultti

juha.kalliola@lemonsoft.fi

ERP-projektin haasteet – Aika

Usein kuultua: ”Kuinka kauan toiminnanohjausjärjestelmän käyttöönotto yleensä
kestää – tällaisessa samankaltaisessa projektissa kuin tämä meidän on?”

On mahdotonta antaa tyydyttävää vastausta – ehkä rauhoittava korkeintaan.
Aika ei ole ainoa tekijä projektin onnistumisessa, mutta merkittävässä roolissa.

Jos kyseessä on vähänkään laajempi tai jopa kaikki yrityksen toiminnot kattava
käyttöönotto, saa unohtaa haaveet kolmen kuukauden aikataulusta. Tai toki se
voi jollakin tasolla onnistua, mutta valmista ei siinä ajassa saada. Koko yrityksen
kattava ERP-projekti ottaa varmasti vähintään vuoden, että kaikki toiminnot
ovat käytössä tyydyttävästi. Harva yritys on onnistunut laajamittaisessa
käyttöönotossa alle vuoden aikataululla. Harva.

Käyttöönotto eilen…

”Mikä siinä niin kauan kestää?! Softa koneeseen ja aletaan käyttää – me
ollaan käytetty näitä Windows-ohjelmia jo pitkään. Näähän on samanlaisia
suurin piirtein kaikki.”

Hyvä lukija, älä loukkaannu yllä olevasta kommentista, jos se tuntui olevan kuin
omasta suustasi. Se on tullut useammasta suusta kuin arvaatkaan. Ja se on ihan
ok. Mutta ei ole ok tarttua siihen ajatukseen.

Paljon on tehtävää: koulutuksia, tietojen siirtoa ja tarkistuksia, toimintatapojen
muuttamista. Ja samalla pitäisi vielä pyörittää liiketoimintaa.

Ei tässä mitään kiirettä…

Jos lähdetään liikkeelle siitä, että kannattaa varata vuosi aikaa tyydyttävän
tuloksen saavuttamiseksi, onko olemassa ylärajaa projektin kestolle?

On.

No, voihan sitä tietysti venyttää ihan loputtomiin asti, mutta jos aikaa alkaa olla
mennyt jo yli kaksi vuotta, jotain on todennäköisesti tehty väärin.

Lisäksi on vaikeaa enää saavuttaa terävintä hyötyä, jos aikaa kuluu yli kaksi
vuotta. Mielenkiinto ja innostus alkavat hiipua. Ei löydy enää tarpeellista draivia ja
omistautumista. On vaikea pitää projektia korkealla prioriteeteissa. Maailma
muuttuu.

Ehkä voitaisiin sanoa, että tavoiteltava aika on jossain vuoden ja kahden
puolessavälissä. Mutta ei siihenkään kannata tuudittautua – on hyvä pyrkiä
tuloksiin jo alkuvaiheessa projektia. Hyvät tulokset joillakin osa-alueilla antaa
rutkasti potkua jatkolle.

Jos puolitoista vuotta kuulostaa kovalta aikataululta, niin ei se oikeasti ole –
isossakaan projektissa.

Nopea aikataulu on välttämätöntä – miksi?

Jos hiilet loppuvat, juna pysähtyy.

Uuden toiminnanohjausjärjestelmän ottaa käyttöön ihmiset, jotka pyörittävät
yrityksen toimintaa, joka on prioriteetti ykkönen – ja kokopäivätyötä jo
itsessään. Käyttöönotto on siis ylimääräistä työtä kaiken tämän lisäksi.

Jos projekti jatkuu liian pitkään, alkaa into hiipua. Tulokset näyttävät kaukaisilta,
ei näy valoa tunnelin päässä. Mutta jos käyttöönoton aikataulu tehdään tiukaksi,
nähdään tuloksia nopeammin.

”It’s all about priorities”

Olisi epärealistista kuvitella, että ERP-projekti voisi olla korkealla prioriteetilla
kovin pitkään, kahta tai kolmea vuotta. Ja kun prioriteetti alkaa tippua, alkaa
myös onnistumisen mahdollisuudet tippua.

Paras lopputulos saadaan, kun projekti on korkealla prioriteetilla ja viedään läpi
nopeasti. Sen jälkeen on aika ottaa uudesta toiminnanohjausjärjestelmästä täysi
hyöty, rakentaa liiketoiminta sen päälle – koko ajan paremmin ja paremmin.

Odottamattomat muutokset

Odottamattomia muutoksia voi olla kahdenlaisia; muutokset henkilöstössä tai
muutokset toimintaympäristössä. Näistä voi muodostua myös uhka ERP-
projektille.

Muutokset henkilöstössä:

Projektia vetää taitava, innostunut henkilö. Eräänä päivänä hän ilmoittaakin
lähtevänsä ”uusiin haasteisiin”. Tilalle tulee uusi henkilö, joka on projektin
kannalta arvoitus. Tämän henkilön suhtautumisella projektiin on ratkaiseva
merkitys sen onnistumisen kannalta. Voi olla, että tätä henkilöä ei paljoa
kiinnosta koko ERP, joka voi johtua siitä, että hän ei ymmärrä mitä ollaan
tekemässä ja miksi.

Muutokset toimintaympäristössä:

Yrityksen toiminta kasvaa äkisti; ”Nyt on liian kiire käyttöönotolle”. Tai yrityksen
toiminta hiipuu äkisti; ”Meillä ei ole varaa tähän”.

Tällaiset muutokset vaikuttavat varmasti nopeankin aikataulun projektiin, mutta
sitä varmemmin pitkäksi venyvään projektiin.

Aikataulusta lipsuminen

ERP-projektien kaltaisissa isoissa projekteissa aikataulut helposti lipsuvat.
Aikatauluun vaikuttaa tietysti moni tekijä; suunnittelu, asennukset, tietojen
siirrot, koulutukset jne. Eikä pelkästään yrityksen omasta toiminnasta johtuvat,
vaan yhtä lailla toimittaja tai kolmannet osapuolet voi omalla toiminnallaan
aiheuttaa aikataulun lipsumista.

Kokemukset kuitenkin osoittavat, että tiukka ja aggressiivinen aikataulu lipsuu
epätodennäköisemmin kuin mukavan väljä, kiireetön aikataulu.
Liberty

Hyödyt

Mitä pidempi aika kuluu, sitä pidemmälle lykkääntyvät saatavat hyödyt.

Jos jokainen ylimääräinen kuukausi projektissa voi tuoda suuriakin
lisäkustannuksia, mieti mitä vuoden tai vuosien venyminen maksaa. Nopea
käyttöönoton aikataulu on tästäkin syystä erittäin toivottavaa.

Onko se mahdollista? Lähes aina on.

”The Three Knobs”

Nyt otetaan lyhyesti käsittelyyn ”kolme säädintä” Thomas F. Wallacen
innoittamana.

Projektinhallinnassa on kolme määrällistä muuttujaa; työmäärä, aikamäärä ja
resurssien määrä työn suorittamiseksi. Ajattele näitä kolmena säätimenä.

Kaksi näistä säätimistä voidaan asettaa vakioksi ja kolmatta liikutellaan.

1. Työmäärän voidaan ajatella olevan vakio. ERP-projektissa on tietty määrä työtä, joka yksinkertaisesti on tehtävä.
2. Aikamäärän voidaan myös ajatella olevan vakio. Päätetään, että käyttöönotto tehdään 18kk kuluessa.
3. Resurssien määrä on näin ollen muuttuva. Kun resurssien määrä säädetään oikealle tasolle, tarvittava työmäärä saadaan tehtyä määritellyssä ajassa.

Entä jos resurssien määrää ei pystytä lisäämään?

Joskus näin on. Voi olla, että ei ole tarpeeksi rahaa tai organisaatio on niin ohut,
että työvoimaa ei vain voi irrottaa tarpeeksi käyttöönottoprojektiin.

Se oli siinä sitten? Ei välttämättä.

Ratkaisu voi olla tällöin ns. Quick-Slice käyttöönotto; otetaan ensin käyttöön
tärkeimmät osat, jotka vaikuttavat toimintaan tai auttavat parantamaan sitä.
Tämä voidaan yleensä tehdä todella nopeasti, ehkä kolmesta kuuteen kuukautta
kestävänä projektina.

Kun ensimmäinen Quick-Slice on tehty onnistuneesti, siirrytään seuraavaan.

Summarum.

Tehdäänpä ERP-käyttöönotto koko yritystoiminnan laajuisesti tai pienemmissä
osissa, agressiivinen aikataulu on lähes aina avain onnistuneeseen
käyttöönottoon.

– Juha Kalliola, ERP-konsultti

LemonBI tarjoaa mobiiliystävällisen tiedon jakamisen ilon

Tiedon jakamiseen ei liiketoiminnassa useinkaan panosteta. Tämä johtuu osaltaan siitä, että tiedon jakamisen hyöty ei ole helposti mitattavissa. Tiedon jakamisella on kuitenkin saavutettavissa monia etuja. Tulisikin muistaa, että tiedon jakaminen edesauttaa tiedon jalostumista. Yhden ihmisen tuntuma liiketoiminnasta voi poiketa hyvinkin paljon siitä, mitä se olisi reaaliaikaisen tiedon, sen jakamisen ja jalostamisen myötä. Tieto tuo siis ymmärrystä arvailujen rinnalle, parhaimmillaan jopa oivalluksia.

Toisaalta tiedon jakamiseen ei ole ollut sopivia teknisia ratkaisuja. Liiketoimintatiedon hallinnan ratkaisuja on moitittu tiedon jakamisen puutteista. Gartner (2/2016, BI and Analytics Platforms) nosti tutkimuksessaan yhdeksi merkittäväksi BI- ja analytiikka-alustojen ominaisuudeksi tiedon jakamisen mahdollisuudet. Nämä onkin mietitty uudella tavalla Microsoftin uusissa teknologioissa ja näin voimme tarjota saman hienouden LemonBI:n avulla.

LemonBI on ratkaisumme, jolla voimme tarjota lähes laitteesta riippumatonta tiedon jakamista. Microsoftin teknologia mahdollistaa sen. Tieto voidaan helposti jakaa esimerkiksi käyttäjäryhmittäin tai jopa käyttäjittäin. LemonBI:ssä tiedon jakaminen pohjautuu erityisesti raportteihin ja niistä rakennettuihin koontinäyttöihin. Ohessa yksinkertaistettu kuvaus siitä, miten tietomalli tarjoaa vahvat perustukset raporteille, jotka edelleen toimivat pohjana koontinäytöille ja lopulta niiden jakamiselle mobiilikäyttöä varten.

biblogiin

 

Kuva: esimerkkimalli kuinka raporteista tehdään koontinäyttöjä ja kuinka ne skaalautuvat mobiilikäyttöä varten

Raporttien taustalla on tekemämme tietomalli, mikä mahdollistaa asiakkaille raporttien tekemisen tarvittaessa myös itse, kun käytössä on drag-and-drop -toiminnallisuus. Ei siis vaadita erityistä tietotaitoa, vaan riittää kun ymmärtää mitä tiedolla voi tehdä. Raporteista voidaan itse myös tehdä koontinäyttöjä hyvin nopeasti. Oli raportit ja koontinäytöt sitten meidän tai asiakkaan tekemiä, niin oleellista on, että niitä voidaan tehdä eri käyttäjätarpeisiin. Tällöin esimerkiksi myynnillä voi olla omat koontinäyttönsä ja johdolla omansa. Nämä rakennetaan aina käyttötarpeiden mukaan.

Koontinäyttöjen käyttöoikeuksien jakelu onnistuu selainkäyttöliittymästä lähettämällä sähköpostikutsu. Tällöin vain tiettyä tunnusta vasten onnistuu kirjautuminen. Vastaavasti selainkäyttöliittymästä voidaan poistaa käyttöoikeudet. Nämä muutokset vaikuttavat välittömästi kaikkialla, joten myös mobiilissa nämä muutokset näkyvät heti.

Koontinäyttöjä voidaan katsella suoraan selaimen kautta tai mobiililaitteiden avulla. Taustalla oleva teknologia tukee kaikkia uusimpia käyttöjärjestelmiä ja laitteita, joten olipa laitteesi Windows-, iOS- tai Android-pohjainen, niin pääset kyllä katsomaan yrityksesi tietoja, jos käytössäsi on LemonBI.

Mobiilikäyttäminen on tehty mahdollisimman yksinkertaiseksi. Ensin lataat vain ilmaisen sovelluksen sovelluskaupasta ja kirjaudut ratkaisuun kytketyillä tunnuksilla sisään, jolloin käyttäjälle tarjotaan ne koontinäytöt, joihin käyttöoikeus löytyy. Tarvittaessa käyttäjälle voidaan tarjota myös mobiiliin oikeudet, jotta muita käyttäjiä voidaan kutsua mukaan. Mobiilissa kätevintä on kuitenkin tehdä merkintöjä sisältöön ja jakaa edelleen kuvana kollegan sähköpostiin.

LemonBI mobiilikäytön parhaita puolia ovat sen skaalautuvuus eri laitteille, tietojen ajantasaisuus ja saavutettavuus paikasta riippumatta, sovelluksen käytettävyys ja tiedon helppo jakaminen. Mobiiliratkaisu on tehty tiedon esittämistä varten, joten näkymien ja tietojen muokkaaminen ei ole osa mobiiliympäristöä. Tärkeintä mobiilissa on, että tieto saavuttaa käyttäjänsä – tarvittaessa jopa mobiiliverkon puuttuessa tarjotaan viimeksi ladatut tiedot.

Koska yritysten tietojärjestelmät kerryttävät valtavasti tietoa, miksi et jakaisi sitä tehokkaasti ja tekisi siitä merkityksellistä ja jopa kilpailuetua? Mikäli tiedon jaettavuus, mobiilikäyttö ja muut LemonBI:n hyödyt kiinnostavat, suosittelen katsomaan tuoreen videomme aiheesta ja ottamaan yhteyttä!  Lue lisää aiheesta

Katso LemonBI video tästä.

Gartnerin (2/2016) BI and Analytics Platforms -tutkimus ladattavissa täältä.

Ari Karvola

Tuotepäällikkö

LemonBI tulee – helpotusta tiedonhallintaan

Asiakkaidemme tieto- ja raportointitarpeet ovat kasvaneet, mikä näkyy muun muassa kehitysideoissa raportointiin liittyen. Yleisesti myös toimittajalta vaaditaan entistä pidemmälle vietyjä ratkaisuja. Haluamme vastata yhä kasvaviin tarpeisiin ja toimia edelläkävijänä tarjoamalla monipuolisempaa liiketoimintatiedon hallinnan ympäristöä, jonka perustana toimii Microsoftin uusimmat teknologiat.

Tarjouskanta

 

 

 

 

 

 

 

 

 

Kuva: raporttiesimerkki LemonBI selainkäyttöisestä sovelluksesta

LemonBI on liiketoimintatiedon hallinnan (BI – Business Intelligence) ympäristö, joka on muokattavissa liiketoimintaasi sopivaksi kokonaisuudeksi. Siinä, missä vakioratkaisumme Dynaaminen raportointi tarjoaa vakioraportteja eri tarpeisiin, LemonBI yhdistää tietoja asiakkaan toiveiden mukaisesti. Usein asiakkaiden lopulliset tietotarpeet ovat hyvinkin yrityskohtaisia ja on mahdotonta tarjota kaikille sopivaa vakioraportointia, joten LemonBI tuo mahdollisuuden yksilöllisille ratkaisuille.

LemonBI tuotteena

LemonBI-ratkaisumme sydämenä toimii Lemonsoftin kerryttämä liiketoimintatieto, mitä voidaan tarvittaessa rikastuttaa muulla yrityksen johtamisessa ja kehittämisessä tarvittavalla tiedolla. Meille tutun Lemonsoftin tietokannan ansiosta olemme voineet mallintaa asioita valmiiksi, jolloin LemonBI:n käyttöönottaminen on nopeaa ja sujuvaa.

LemonBI tehdään asiakkaan toivomusten mukaan, jolloin mitataan oikeita asioita. Lähtötilanteena on aina asiakkaan tarpeet ja tätä pyrimme jalostamaan yhteistyössä asiakkaan kanssa tuomalla ajatukset yhteen. Ratkaisu koostuu raporteista ja koontinäytöistä, joihin voimme koota juuri ne tiedot, joita tarvitaan liiketoiminnan seurantaan ja ohjaamiseen. Microsoftin teknologia puolestaan huolehtii siitä, että nämä tiedot pysyvät ajan tasalla halutulla päivityssyklillä, jolloin avatessasi eri näkymiä tieto on jo haettu muistiin.

Raportteja ja koontinäyttöjä voidaan katsoa niin työpöytäsovelluksella, selainsovelluksella kuin myös mobiilisovelluksella. Ratkaisumme tukee lähes kaikkia uusimpia laitteita ja selaimia, joten olipa tietokoneesi, puhelimesi tai tablettisi Windows-, iOS- tai Android-pohjainen, niin tieto saavuttaa käyttäjänsä.

LemonBI on tiedon hallinnan ympäristö, joten tärkeä osa sitä on myös tiedon jakaminen. Tiedon jakaminen on helppoa ja hallittua. Voit esimerkiksi koostaa näkymiä tiettyä käyttäjäryhmää varten, jolloin he saavat tarvitsemansa tiedot. Pääsy hallinnoidaan LemonBI:stä suoraan, joten voit kutsua sähköpostilla kollegoja mukaan kuin myös myöhemmin poistaa katseluoikeudet. Tiedon jaettavuudella pyritään parantamaan liiketoimintaymmärrystä yrityksen kaikilla tasoilla, kun käytössä on ajantasaiset ja yhtenevät tiedot.

Teknologia – johtava ratkaisu Microsoftilta

Sovellusalustana toimii Microsoftin Power BI, joka on Microsoftin uusinta teknologiaa liiketoimintatiedon hallintaan ja analytiikkaan. Tähän teknologiaan Microsoft panostaa vahvasti, minkä huomaa muun muassa uusien ominaisuuksien määrästä. Power BI on osa Microsoftin Office 365 ympäristöä, joten sen voi liittää joko osaksi nykyistä ratkaisua tai käyttää itsenäisenä sovelluksena.

Power BI on muistinvaraista nopeaa tiedon pyörittelyä, kun taas Lemonsoftin vakioraportointiratkaisun käyttämä Microsoftin SSRS-tekniikka tekee kyselyt tietokannasta halutuilla parametreillä. Molemmat tekniikat edustavat alansa parhaimmistoa, ne vain on tehty eri tarkoitusta varten – näin myös Lemonsoftilla.

Tuleeko LemonBI todella helpottamaan tiedonhallintaa?

Vastaus on helppo, koska kaikki riippuu asiakastarpeista. Osalle riittää, että Lemonsoftista saadaan listamuotoinen raportti, joka antaa riittävät vastaukset yksittäisiin kysymyksiin. Osa alkaa jo vaatia ajantasaiset ja kattavat tiedot ajasta, paikasta ja laitteesta riippumatta. Näin ollen LemonBI tulee helpottamaan tietotarpeita, mikäli vakioraportointiratkaisumme ei joissain tilanteissa riitä.

Jos vaaditaan vain yksi tietty vakioraportti kerran viikossa, ei silloin välttämättä tarvita LemonBI:tä. Mutta jos tarvitaan useamman eri vakioraportin sisältämää tietoa, halutaan tiedot yhteen näkymään ja toiveena on vielä suodattaa ja pilkkoa tietoa mielekkäällä tavalla, niin silloin on kannattavaa siirtyä seuraavalle tehokkuuden tasolle.

Olemme itse havahtuneet, että todellisuudessa uusi ratkaisumme menee pidemmälle kuin olisi osattu ajatellakaan. Mikäli teillä on tarpeita kokonaisvaltaiselle liiketoimintatiedon hallinnan ympäristölle, ottakaa yhteyttä. Aiheesta lisää nettisivuillamme: LemonBI

Ari Karvola

Tuotepäällikkö

 

Lemonsoft syntyi kymmenen vuotta sitten

Lemonsoft perustettiin helmikuun toisena päivänä vuonna 2006. Taustalla oli visio täydellisestä toiminnanohjausjärjestelmästä.

Lemonsoft yritysohjelmien kehittämistä ohjasi vahva näkemys yrityksen prosessien kehittämisestä ja ohjaamisesta ohjelman avulla. Myös rutiinien automatisointi oli vahvasti mukana alusta saakka.

Toiminnanohjausjärjestelmän kehittäminen puhtaalta pöydältä ilman historian painolastia on harvinainen ja ainutlaatuinen tilaisuus. Pystyimme ohjelmoimaan tuotteen alusta lähtien tukemaan visiotamme ja hyödyntämään tekijöiden aiempaa vankkaa kokemusta toiminnanohjausjärjestelmien tekemisestä.

Alkuperäistä arkkitehtuuria on toki uudistettu, mutta hienosti se on aikaa kestänyt. Emme Lemonsoftissa ajattelekaan elinkaarta, pidämme tuotteen raikkaana jatkuvasti.

Alkuperäisellä tiellä olemme edelleen. Lemonsoft on tänä päivänä arvostettu ja tunnettu toiminnanohjauksen kokonaisjärjestelmä. Kaikki osa-alueet samassa järjestelmässä onkin yksi menestyksemme avaintekijöistä.

Ennenkaikkea saamme kuitenkin kiittää asiakkaitamme, jotka ohjaavat meitä oikeaan suuntaan. Olemme mukana yli 15.000 kotimaisen yrityksen arjessa ja heiltä saamme hyvin palautetta mitä ohjelmaan kannattaa kehittää. Vielä on matkaa täydelliseen toiminnanohjausjärjestelmään, mutta suunta on palautteenkin mukaan oikea.

Parhaillaan tuomme markkinoille LemonOnline tuotetta, joka on selainpohjainen toiminnanohjausjärjestelmä uudelleen mietittynä.

Katso Lemonsoftin 10v video tästä.

Menestystä liiketoimintaasi!

Kari Joki-Hollanti