Leivän paahtokin on prosessi – Näin arvovirtakartta fokusoi asiakkaalle tuotettavaan arvoon

Arvovirtakartta auttaa hahmottamaan, missä kohdin prosessisi pullonkaulat ja ongelmat luovat esteitä ja hukkaa sekä fokusoi toimintasi asiakkaalle tuotettavaan arvoon.

Jos asiakkaasi ei ole aivan idiootti tai taiteen keräilijä, tai jos tuotteesi ei ole aivan häikäisevä, olet kiinnostunut siitä, kuinka hyvin saat toimitettua tuotteesi asiakkaalle – tai ainakin sinun pitäisi olla kiinnostunut.

Mikäli tuotteesi ja tapasi luoda arvoa on aivan erinomainen, on mahdollista että saat yli miljoonakertaisen tuoton sijoituksellesi. Onko tuotteesi Alibaban pisuaari, vai Marcel Duchampin Fountain? Usein asiakkaalle tuotetun arvon ja asiakasarvon tuottamiseen käytettyjen resurssien arvo ovat lähempänä toisiaan. Kun marginaalit ovat pieniä, fokus kääntyy toiminnan kehittämiseen.

Toiminnan tarkastelemisen kaksi puolta

Voit tarkastella toimintaa kulujen kautta. Jokaisessa prosessin vaiheessa syntyy kuluja, jos ei muuten, niin kyseiselle toiminnan ajanjaksolle jyvitetään vuokria, henkilöstökuluja ja lisenssimaksuja. Usein nämä kulut ovat välttämättömiä toiminnan pyörittämiselle, mutta kuinka usein ja mitä kriteereitä vasten kuluja kannattaisi arvioida?

Voit tarkastella toimintaa myös asiakkaalle luodun arvon kautta. Mikä on se asia, josta asiakas on valmis maksamaan kussakin tekemisen vaiheessa? Todellisuudessa on lähes aina sellainen tilanne, että jokaisessa prosessin vaiheessa ei synny arvoa asiakkaalle. Näin ollen on lähes varmaa, että toimintasi käyttää rahaa ilman, että tällä rahalla synnytettiin lainkaan arvoa asiakkaalle. Liiketoiminnan kannattavuudessa kysymys on lähinnä siitä, mikä on tämän hukan suhde asiakkaan kokemaan arvoon nähden.

Yleensä tiedämme hyvin sen, paljonko rahaa tulee ja paljonko sitä menee. Kaikki on kivasti, kun rahaa tulee enemmän kuin sitä menee. Ja jos tuote viedään käsistä, niin ei ole kovin tarkkaa, paljonko sen tuottamiseen on käytetty rahaa – aina voi nostaa hintaa. Toinen puoli yhtälöstä nousee pintaan viimeistään silloin, kun asiakas valitsee kilpailijan tuotteen. Yhtälö ei ole tasapainossa, mistä siis voimme säästää. Ensimmäinen reaktio on suoraviivainen; raportoidaan toiminnoittain, mitkä ovat kulut, ja napataan turhat kulut pois. Toimii pari kertaa. Ihmiset ovat neuvokkaita ja tulevat toimeen vähemmälläkin.

Tämän lähteen ehdyttyä katsotaan, mitä prosessin vaiheita on ja voidaanko niitä optimoida. Mistä lisenssikuluista esimerkiksi voitaisiin päästä eroon, jos mentäisiin viimeinkin pilveen?

Kulujen karsinta on hankalaa koska

  1. ei ole itsestään selvää, miten kulut oikeastaan muodostuvat ja mikä kulunmuodostuskohta kontribuoi mitenkin asiakkaalle tehtävään arvoon
  2. kuluja optimoimalla päästään maksimissaan kulujen suuruiseen säästöön. Toki jos kulut saadaan sen alle minkä arvon asiakas kokee saavansa, niin yhtälö toimii taas.

Kohta kaksi liittyy suoraan siihen, millainen on organisaation visio ja millaisella strategialla sinne aiotaan päästä. Ollaanko selviytymismoodissa vai suunnitellaanko pitkällä tähtäimellä.

Kannattaa vilkaista tähän liittyen arvoketjukarttaa käsittelevä blogi.

Kohdan yksi osalta voidaan tiukentaa raportointia ja asettaa kaikille prosentuaalisia tavoitteita. Näissä on ilmeiset haitat – et halua vahingossa puristaa sellaista, joka toimii ja tuottaa, vaan kehittää täsmällisesti sellaista, joka ei vielä toimi.

Jos toiminta ei jo valmiiksi tuota sitä dataa, jota raportoinnilla ollaan hakemassa, niin ongelma ei ole raportoinnin puute vaan toiminnan määrämuodottomuus. Raportointivaateet vain lisäävät sitä osuutta toiminnasta, josta asiakas ei ole valmis maksamaan.

Toki laastarilla ja Buranallakin on joskus tarkoituksensa, mutta lähtökohtaisesti kipua ei kannata peittää. Juustohöyläsäästötavoitteet ovat ehkä käyttökelpoisia siihen, että herätetään organisaatio ajattelemaan kulujen suhdetta synnytettyyn arvoon – sama prosentti kaikilta on parhaimmillaan arpapeliä.

 

Mikä prosessien tarkastelussa on vialla?

Prosessit ovat usein kuvattu ideaalimalleina – mitä tapahtuu ja mikä funktio tai rooli on siitä vastuussa. Tällainen kuvaus on toimiva, jos halutaan ymmärtää pääpiirteissään, millaisesta toiminnasta on kysymys. Tämä usein laatikoina ja uimaratoina mallinnettu kuvaus harvemmin vastaa kuitenkaan seuraavaan kysymykseen: miten työ tapahtuu? Mitä ja miten on tärkeää erottaa toisistaan?

Mitä on yleensä kohtuullisen hyvin ymmärretty, mutta se ei auta vastaamaan prosessin kehittämistä tai säästöjen löytämistä koskeviin kysymyksiin.

Otetaan yksinkertaisena esimerkkinä paahtoleivän valmistus. Se mitä tapahtuu voidaan kuvata seuraavasti:

1. Ota leipä > 2. Paahda leipä > 3. Voitele leipä > 4. Vie leipä pöytään > 5. Syö leipä > 6. Siivoa

Tästä prosessista voidaan mitata esimerkiksi kestoa:

Prosessi kestää minimissään 6min 40s
Tyypillisesti aikaa kuluu 9min 80s
Hitaimmassa mitatussa tapauksessa ollaan valmiita 12min ja 50s kuluttua

Miten pitäisi edetä, jos edellä kuvattua prosessia halutaan nopeuttaa vaikka 3 minuuttia? Se, että ymmärretään mitä tapahtuu, ei riitä. Pitää ymmärtää tarkalla tasolla, miten vaiheet suoritetaan.

 

Miksi näkyvyys on ongelma?

Linjaorganisaation suunnasta saadaan usein kyllä selkeä kuva henkilöstökuluista, mutta parhaimmillaankin nämä antavat vain viitteellisen kuvan siitä mihin prosessiin kulut kohdistuvat saati siitä millaista asiakasarvon lisäystä nämä kulut edustavat. Ihmiset työskentelevät usein monissa prosesseissa eikä linjaorganisaation linssi ole optimoitu antamaan tietoa näistä nyansseista.

IT-organisaatiolta saadaan kuva niistä järjestelmistä, joita prosesseissa käytetään ja näiden hinta on yleensä tiedossa. Haaste myös tässä lähestymistavassa on siinä, etteivät kulut kohdistu täsmällisesti yhteen prosessiin tai asiakkaalle tuotettuun arvoon.

Liiketoiminta tietää yleensä, mitä tehdään ja kuinka kauan mikäkin vaihe kestää, mutta se, miten työ tarkalla tasolla tapahtuu, karkaa yleensä raportoinnin ja seurannan saavuttamattomiin myös liiketoiminnan tarkastelemisessa.

 

Miten saadaan relevantit ongelmat esiin ja ratkaistua?

Ennen kuin sännätään ratkaisemaan ongelmaa, ongelma pitää ymmärtää. Mikä ongelma on, missä se esiintyy, kuinka usein, mitä vaikutuksia ongelmalla on, mitkä asiat vaikuttavat ongelmaan ja niin edelleen. Joskus ongelman kuvauksessa yksi asia on tärkeämpi ja joskus taas joku toinen.

Riippuu kontekstista, mitä kaikkea ongelmasta kannattaa ymmärtää. Tämä kontekstin ymmärtäminen on keskeistä, kun ongelmia ratkaistaan systemaattisesti. Haluamme ratkaista ongelman ilman, että synnytämme ratkaisulla uusia ongelmia. Mielellään ratkaistaan myös se ongelma, josta ongelman aiheuttava ongelma johtuu. Ei laiteta vain laastaria, vaan ymmärretään mistä haavat tulevat ja hiotaan piikit pois.

Arvovirtakartta on kuvaustapa, jolla kuvataan askel askeleelta mitä ja miten tehdään. Jos jatkamme aikaisempaa esimerkkiä, niin jokainen prosessin vaihe – “mitä tapahtuu?” – avataan useaksi operatiiviseksi askeleeksi, jotka vastaavat kysymykseen “miten tapahtuu?”

Se mitä tapahtuu esimerkiksi prosessin vaiheessa “1. Ota leipä ” voidaan kuvata seuraavasti:

1.1. Ota leipä leipälaatikosta (0.1-0.3min)
1.2. Tarkasta onko leipä tuoretta (0.1-0.3min)
1.3. Laita leipä lautaselle (0.1min)
1.4. Leipä odottaa lautasella paahtimelle vientiä (0.2-0.7min)
1.5. Siirrä leipälautanen paahtimen viereen (0.1-0.3min)

Jos aikaisemmassa esimerkissä tiesimme kokonaisprosessin ajan, tai parhaassa tapauksessa, että “1. Ota leipä” vaihe kestää 0.6min – 1.7min, nyt voimme tarkastella miten tämä aika jakautuu leivän ottamiseen tarvittavien operaatioiden välillä.

Tämän lisäksi voimme kuvata paljon muitakin yksityiskohtia: esimerkiksi roolit, järjestelmät, ongelmat, mahdollisuudet, ja miten ongelmat liittyvät toisiinsa. Näiden lisäksi nyt operoidaan sillä tasolla, jolla voidaan erotella, tuoko operaatio asiakkaalle arvoa vai ei.

Leivän paahtokin on prosessi - arvovirtakartan avulla erotat prosessin osat.

Leivänpaahdon problematiikka

Toiminnan kuvaus arvovirtakartaksi saatetaan kokea kalliiksi ja aikaa vieväksi askarteluksi. Se on kuitenkin hyvin tehokas tapa prosessissa työskenteleville ymmärtää kokonaisuus ja tekemisen dynamiikka, mikä taas on edellytys systemaattiselle kehitykselle. Jos arvovirtakartan teko tuntuu aikaa vievältä ja kalliilta, kannattaa kokeilla kehittämistä ilman tukevaa ymmärrystä nykytilasta. Se vasta hukkaintensiivistä onkin!

Arvovirtakarttoja on erilaisia ja muutamalla eri logiikalla toimivia. Olen itse käyttänyt useampaa erilaista ja havainnut, että Shigeo Shingon tapa erottaa toisistaan se, mitä tapahtuu ja se, miten tapahtuu, toimii erittäin hyvin.

Aloitetaan SIPOC mallista; Toimittaja(Supplier), Syötteet(Inputs), Prosessi(Process steps), Tuotokset(Outputs), Asiakas(Customer). Kuka on asiakas, mitä hän tarvitsee, koska ja millaisia määriä? Mitä tarvitaan asiakkaan tarpeeseen vastaamiseen ja mistä nämä asiat tulevat?

Varsinaisessa arvovirran kuvauksessa ylärivillä kuvataan mitä tehdään – mitkä ovat ne vaiheet, joiden kautta toimittajilta tulevat syötteet muutetaan sellaisiksi lopputuotoksiksi, joita asiakas odottaa.

Jokainen prosessivaihe avataan sarjaksi operaatiota, joita tarvitaan vaiheen tekemiseksi. Värikoodaus mahdollistaa prosessin nopean arvioinnin – mikä on prosessoinnin osuus varastointiin? Tai kuinka paljon prosessissa siirrellään tietoa tai tavaroita ja missä kohdissa syntyy asiakkaalle lisäarvoa? Myös ongelmien konteksti ja juurisyyt saadaan kuvattua samassa kontekstissa, josta lasketaan prosessin tehokkuuslukuja.

Leivän paahdon prosessissa on monta vaihetta, jotka voidaan kuvata arvovirtakartan avulla.

Kun prosessi on kuvattu, voidaan käyttää yksinkertaisia kuvaajia havainnollistamaan miten prosessi käyttäytyy vaihe vaiheelta. Missä odotellaan ja kuinka paljon? Mitkä ovat ne vaiheet, joista asiakas sanoo saavansa arvoa?

Kun prosessi on kuvattu, voidaan tutkia prosessin eri vaiheita, ja mitkä niistä tuottavat arvoa asiakkaalle.

Prosessista voidaan laskea tunnuslukuja ja tavoitteita voidaan asettaa nyt tarkasti. Jos ennen mallintamista mitattiin, mitä prosessi tuottaa, ns. output-metriikkana, voidaan kartoittamisen jälkeen mitata ajonaikaisesti niitä asioita, jotka vaikuttavat output-metriikkaan.

Ajattele vaikka kalastamista – jos mittaat vain kalansaaliin määrää, toimintaa on vaikea parantaa. Haluat ymmärtää, mikä vaikutus on syötillä ja mikä kellonajalla. Milloin kannattaa kalastaa pintavesistä, milloin syvänteistä? Jos voit mitata syöttien tuoreuden vaikutusta kalastussyvyyteen ja kellonaikaan, olet paljon paremmassa asemassa ennustamassa sitä, millainen päivän saalis tulee olemaan.

 

Asiakas määrittelee arvon

Kehittäminen nojaa kahteen asiaan, visioon ja ongelmien poistamisen tasapainoon. Vision löytäminen on erillinen harjoitus, jossa toimintaympäristö pitää ymmärtää esimerkiksi arvoketjukartan kautta. Ongelmien poistamiseen arvovirtakartta sen sijaan on paras työkalu.

Ongelma on tässä kontekstissa jokin sellainen, joka vähentää asiakasarvon suhteellista osuutta prosessin läpimenoajasta. Eli jotta voit ymmärtää, miten priorisoida erilaiset kehityspotentiaalit, sinun pitää ymmärtää, mitä asiakkaasi arvostaa.

Tässä toimii sama kuin yllä mittauksen osalta – haluat ymmärtää arvon muodostumista vaihe vaiheelta läpi kaikkien prosessissa tehtävien operaatioiden.

Paljastava kysymys on: Onko asiakas valmis maksamaan siitä mitä tässä vaiheessa tehdään?

Jos asiakas ei ole valmis maksamaan tekemisestä, niin miksi ihmeessä kyseistä asiaa tehdään? Selityksiä on monia, mutta niistä huolimatta: asiakas määrittelee arvon. Jos noudatat tiukasti asiakkaan määritelmää siitä, missä vaiheissa arvo prosessissasi syntyy, pääset luultavasti tulokseen, että arvon synnyttämiseen käytetty aika on 0.5%-10% välillä. Siis yli 90% ajasta menee johonkin muuhun kuin asiakasarvon tuottamiseen.

Asiakasarvon suhde läpimenoaikaan kertoo prosessin hyödyllisyyden asiakkaalle yhdellä luvulla: Prosessitehokkuus = Asiakasarvon tuottamiseen käytetty aika / prosessin kokonaisaika.

Tämä on mainio mittari, sillä se pureutuu suoraan siihen, miten arvo luodaan asiakkaalle. Tällä mittarilla voit helposti verrata myös prosesseja toisiinsa.

 

Mikä on seuraava konkreettinen askel toiminnan kehittämiseen?

Helpoin, mutta usein vaikein askel on päättää, että toimintaa lähdetään kehittämään. Toiminnan kehittäminen eroaa siitä, että tehdään muutoksia (ne ovat helppoja.) Kehittämiseen tarvitaan suunta ja pitkäjänteisyyttä. Jotkut organisaatiot ovat luonnostaan kykeneviä säätelemään omaa toimintaansa ja myös kehittämään sitä, mutta useimmat hyötyvät sparrauksesta ja tuesta.

 

Codento on mukana Prosessipäivillä 20.-21.5.2019 – Tule ständillemme tutustumaan arvovirtakartoitukseen ja tekemään prosessisi minikartoitus paikan päällä!

Mikäli olet ilmoittautunut Prosessipäiville, voit varata ajan minikartoitukseen täällä.

“Turvallisessa työyhteisössä mukaan meneminen on helppoa”

Evgenia Lyjinasta tuli monen mutkan kautta devaaja. Hänellä onkin kokemusta monenlaisesta työyhteisöstä ja naisena toimimisesta eri aloilla.

Evgenia Lyjina, tuttavallisemmin Jenny, oli teknologian ympäröimä jo pienenä. Hänen isoäitinsä oli metallurgi ja isoisänsä insinööri, jotka työskentelivät lento- ja rakettiteknologian parissa.

“Neuvostoliitossa kaikki sellainen näkyi paljon, avaruusteknologia, raketit ja sen sellaiset. Olen aina ollut innostunut kaikista avaruusjutuista ja scifistä”, Jenny kertoo.

Kun Jenny oli 12-vuotias, tuli hän Moskovasta Suomeen. Matikat, fysiikat ja kemiat oli opeteltu neuvostostandardeilla, ja niillä opeilla mentiin puoli-ilmaiseksi Suomen peruskoulussa melkein lukioon asti.

“Neuvostoliitossa piti lukea ja osata paljon enemmän, etenkin luonnontieteissä ja teknologiaa koskevissa aineissa se oli paljon vaativampaa. Suomessa oli sitten helppoa, riitti pelkkien tehtävien tekeminen. Vasta lukiossa tuli hetki, että nyt pitää alkaa opettelemaankin jotain uutta.”

Peruskouluaikoina uskottiin, että Jennystä tulee lääkäri, mutta sen sijaan hersyvällä ja kovaäänisellä naurulla varustettu seikkailija lähtikin perustamaan Gaijan luomutilaa Ähtäriin. Luonnonvara-alan tarjoama toimeentulo oli kuitenkin varsin kapea, kun lapsiakin ilmaantui kuvioihin. Kunnallistekniikan osastolla leipä oli leveämpi, mutta siinä työssä tahti meinasi viedä lopulta voimat.

“Aviomies vinkkasi silloin mooc.fi:stä ja innostuin. Olin peruskoulussa käynyt kurssin Pascalia, siinä oli kaikki kokemukseni koodaamisesta. Mutta tein tehtäviä, ja läpäisin lopulta kokeen. Pääsin yliopistolle ja siitä se sitten lähti, aloitin heti tietokannoista ja peliohjelmoinnista. Ohjelmointi nappasi heti mukaansa, olin löytänyt sen, mitä olisi tosi makea tehdä!”

Naisena työelämässä

Teknologiaorientoituneena Jenny on solahtanut mukavasti ohjelmistoalalle. Miesvaltaisella alalla naisena oleminenkaan ei ole tuntunut mitenkään erikoiselta.

“Enemmän ehkä tuntui yliopistolla siltä, että koska kyseessä on teknologia-ala, monet tytöt tarkoituksella pyrkivät pitämään sukupuolen taka-alalla ja mahdollisimman androgyyniin ulkoasuun. Naiseus pitäisi jotenkin piilottaa ja asiantuntija ei voisi samaan aikaan olla myös naisellinen. Itse taas koen, että silloin pudottaa jotain olennaista pois. Mutta en koe, että olisin saanut jotenkin erilaista kohtelua tällä alalla, siksi että olen nainen.”

Jenny tietää mistä puhuu; vaikka it-alalla sukupuoli ei ole ollut merkittävä asia eikä Jennyllä ole naispuolisena devaajana kertoa negatiivisia kokemuksia #metoo -hengessä mitä tulee työntekijöiden kohteluun tasavertaisina asiantuntijoina, toisin on muualla. Miesvaltainen kunnan tekninen osasto tai vaikkapa rakennustyömaa, jollaisella Jenny on myös piipahtanut työurallaan, eivät ole helppoja paikkoja naisille. Sukupuolittuneet käytännöt ovat arkipäivää vuosikymmeniä vanhoissa miesvaltaisissa organisaatioissa.

“Kunnalla sain jopa jossain vaiheessa kuulla, että olin palkattu toimeeni lähinnä ulkonäköni takia. Se tuntui ihan hirveältä. Ohjelmistokehityksessä en ole koskaan kokenut mitään vastaavaa. Se johtuu varmastikin siitä, että alalla on paljon nuoria ihmisiä, maailmankuva on erilainen, ala on muutenkin nuori, ja useimmat ovat korkeasti koulutettuja. Vanhat ja ummehtuneet ajatusmallit eivät ole läsnä. Ihmisiä arvioidaan ennen kaikkea osaamisen kautta.”

 

Itseohjautuvuus kaipaa toimintamalleja

Ohjelmoinnin opinnot toivat Jennylle valmistumisen jälkeen alan työpaikan. Siinä Jenny viihtyi, jonkin aikaa.

“Pidin kyllä työstäni ja työkavereistani edellisessäkin paikassa, mutta työ oli kovin kiireistä ja organisaatio ei tuntunut omalta. Näennäisesti oltiin kyllä itseohjautuvia, esimerkiksi omat laitehankinnat sai tehdä tiettyyn summaan asti itsenäisesti, mutta varsinaisia malleja itseohjautuvuuden toteuttamiseen ei ollut.”

Itseohjautuvuuden ja vertaisoppimisen hengessä muiden tiimien toimintaan kehotettiin osallistumaan, ja periaatteessa firman virallinen tuki itseopiskeluun ja mentorointiin oli olemassa.

“Mutta sitten oltiin kuitenkin hierarkisessa organisaatiossa, jossa tuntui, että tiimien pomoja oli vaikea lähestyä. Miten siis sitten mennä sinne toiseen tiimiin tutustumaan heidän työskentelyynsä? Sinnekö tiimihuoneeseen vain kävelen keskelle ja sanon, että tässä nyt olisin sitten oppimassa uutta?”, Jenny nauraa ja toteaa, ettei siinä kiireessä olisi mitenkään ehtinyt selvittämään vielä tätäkin asiaa.

 

Codentolla heti viikkistä vetämään

Codentolla Jenny sai huomata jo ensimmäisenä päivänä, kuinka työyhteisö tempaisee mukaansa ja tukee osallistumista yhteisiin asioihin. Hän aloitti Codenton devaajana eräänä syksyisenä torstaina, ja ensimmäisenä kalenteriin oli merkattu koko toimiston yhteinen viikkokokous. Jennyllä ei ollut hajuakaan, miten koko prosedyyri toimitettaisiin.

“Sitten kyseltiin fasilitaattoria kokoukseen, ja minut tuttavallisesti tuupattiin hommaan”, Jenny hörähtää.

Niin hän otti vapaaehtoisvuoron viikkiksen vetäjänä vaikka ei ollut eläessään tehnyt mitään vastaavaa. Kokous sujui hienosti, ja Jenny jakoi puheenvuorot konkarin elkein.

“Se tuntui ihan luonnolliselta ja helpolta asialta, vaikka esiintyminen ei varsinaisesti minulle ole helppoa. Mutta oli sellainen fiilis, että kyllä ihmiset sitten auttaa ja kertoo, mitä seuraavaksi pitää tehdä. Täällä kaikki tapahtuu jotenkin niin mutkattomasti,” Jenny jatkaa.

“Olen viihtynyt Codentolla todella hyvin. Ihmiset on omia itsejään, hierarkioita ei ole ja kaikki on olleet todella mukavia. Codentolla vapaa-aikaakin vietetään paljon yhdessä, meillä on paljon yhteisiä mielenkiinnon kohteita, työkavereiden kanssa on helppo puhua ja, esimerkiksi Slackissa voi tosi avoimesti heittää kommenttia ja kysymyksiä ja aina saa vastauksia”, hän tiivistää.

 

Töihin Codentolle? Katso avoimet paikat.

“Läpinäkyvässä ja itseohjautuvassa organisaatiossa uskaltaa myös hallitusvastuuseen”

Turo Mikkonen tuli Codentolle ohjelmistokehittäjäksi puolisentoista vuotta sitten ja ryhtyi heti toimeen. Ohjelmistokehityksen ja asiakasprojektin ohella hän on ehtinyt tehdä niin Codenton myyntiä ja markkinointiakin, vetänyt kasvupiiriä ja istunut viimeiset puoli vuotta hallituksessa puheenjohtajana.

“Codentolle hain töihin niiden Cettu-mainosten perässä”, Turo naurahtaa ja toteamme, ettei hän ole ollut ainoa.

“Olin Codenton ohella rekryprosessissa myös toisen ohjelmistokehitysyrityksen kanssa samaan aikaan. Toisessa firmassa minua haastatteli yhteensä seitsemän ihmistä, Codentolla kolme”, hän kertoo ja havainnollistaa jo lähtötilanteessa ilmennyttä ketterää kulttuuria organisaatiossa.

Rekrylounaalla ja haastatteluissa osattiin myös heti puhua oikeista asioista; moderneista tavoista tehdä, jatkuvasta parantamisesta, itseohjautuvuudesta.

“Monet puhuvat pelkistä teknologioista, heitellään buzzwordeja, Node.js, Git, Kubernetes ja niin edelleen. Codentolla puhuttiin myös siitä, miten pitäisi tehdä, ja se houkutteli paljon enemmän kuin pelkät avainsanat. Miten tärkeää asioita on tehdä jatkuvalla kehityksellä, että softa ei ole valmis siinä vaiheessa kun se julkaistaan, vaan sitä kehitetään jatkuvan iteroinnin kautta, kunnes virheet on korjattu. Tokihan meidän täytyy hyväksyä jossain vaiheessa puutteetkin, kun kehittäminen ei tuota enää mitään lisäarvoa.”

 

Postinjakelusta devaajaksi

Ohjelmistokehityksen pariin Turo tuli oltuaan ensin töissä kuutisen vuotta Postilla. Aikaiset aamuherätykset, fyysisesti raskas työ ja sameat tulevaisuudennäkymät saivat hänet hakeutumaan takaisin koulun penkille. Haaga-Helian tietojenkäsittelyn tutkinnon valmistuessa toimeliaalla multitaskaajalla oli lopulta kaksikin alan työpaikkaa käsissään. Tilanne oli mahdoton, joten ensin lähti toinen pesti, ja lopulta toinenkin.

“Kummassakaan työssä minulla ei ollut sellaista oloa, että saisin tehdä kaikkia niitä juttuja, joita halusin. Hommat oli tosi hitaita toteuttaa, ja itsestäni tuntui, etten tee ihan täydellä tahdilla töitä. Siksi niitä pestejä olikin kaksi, koska en vain halunnut hengailla ja odottaa, että palkka tippuu tilille. Toisessa pestissä koitin tuoda hieman sitä, että voisin tässä tehdä jotain muutakin kuin vain toimenkuvaan kuuluvia asioita. Se ei koskaan sitten mennyt eteenpäin, joten täällä ollaan,” hän kertoo Codenton toimiston aulan yhteistilassa.

 

Itseohjautuvasti kaikkeen mukaan

Codentolla oltiin päätetty noin vuosi ennen Turon paikalle saapumista tehostaa organisaation toimintaa ja ryhtyä toteuttamaan itseohjautuvuutta. Erilaisia menetelmiä ja malleja oli tutkittu, ja kaikista mahdollisista oli päädytty Sosiokratia 3.0 -malliin. Jos Turon edellisissä töissä odoteltiin liksapäivää loputtoman pitkien sprinttien välissä, uudessa työyhteisössä oli tarttumapintaa ja tekemistä kasvuhaluiselle fullstack-kehittäjälle, jota lähtökohtaisesti kiinnostaa kaikki.

“Saavuin tavallaan sellaiseen murtumakohtaan, jossa haluttiin tuoda mallia yhä enemmän kaikkiin organisaation toimintoihin sekä lisätä itseohjautuvuutta, niin että kaikki saisivat osallistua kaikkeen. Siksi sitä sitten varmaan tulikin todella sotkeuduttua vähän kaikkeen.”

“Ensi alkuunsa minulla ei ollut asiakasprojektia, johon olisin suoraan sukeltanut, joten kokeilin sitä ja tätä. Vähitellen huomasin että olin ensimmäisen vuoden aikana tosi aktiivisessa roolissa markkinoinnissa ja myynnissä, ja osallistuin samaan aikaan myös hackathoniin ja sitten sainkin nykyisen asiakkaan projektin. Huomasin, että taas mulla on seitsemän projektia samaan aikaan käynnissä! Mutta ei minua työnnetty mihinkään, vaan kokeilin kaikkea, ja kaikki tuntui hirmu hauskalta.”

Itseohjautuvuudella onkin kaiku ja maine, että siinä pärjäävät lahjakkaasti vain ne, jotka osallistuvat kaikkeen ja ovat eturivissä puhaltamassa yhteiseen hiileen. Rauhallisesta olemuksestaan huolimatta Turokin on kokkina monessa työyhteisön keitoksessa. Voiko siis itseohjautuvassa organisaatiossa pärjätä millään muulla konstilla? Voiko itseohjautuvassa organisaatiossa upota vain omaan asiantuntemukseensa ja keskittyä yhteen asiaan?

“Asiakasprojektissa olen kollegani Jaakon kanssa, ja me kaksi olemme kuin yö ja päivä sen suhteen, miten osallistumme Codenton yhteisiin asioihin. Jaakko on todella lahjakas teknisissä asioissa ja tykkää askarrella niiden parissa pitkää päivää, mutta ei ole niin innokas kaikkien yhteisten juttujen kanssa niin kuin minä. Hän kuitenkin pitää tavasta, jolla asioita tehdään. Itseohjautuvuus sopii meille molemmille, molemmat tuomme tällaisessa organisaatiossa parhaat puolemme asiakasprojekteihin”, Turo pohtii.

 

Hallitusvastuu ei paina

Puolentoista vuoden aikana Sosiokratia 3.0 on levinnyt Codentolla yhä uusiin organisaation funktioihin. Jokaisessa viikkokokouksessa toteutetaan vertaispäätöksentekoa ja peukutetaan koko toimiston väen kesken tärkeät, kaikkia koskevat päätökset läpi.

“Kun vertaan siihen, miten aloittaessani asiat olivat, niin nyt meillä on enemmän aktiivisia osallistujia ympäri organisaatiota. Viikkokokouksiin lisättiin vähitellen lisää S3-elementtejä, ja tehtiin tuollainen Cheat Sheet -taulu, josta voi tarkistaa, miten palaverin kuuluisi mennä. Se on ollut sellaista kokeilua ja iteraatiota, mitkä tasot mallista toimivat meille parhaiten. Olemme vähitellen tuoneet S3-palaverimallit myös muihin kokouksiin, esimerkiksi jännitteiden ratkaisuun keskittyvien piirien kokoontumisiin. Se on vielä vähän hitaampi prosessi, koska kaikissa piireissä ei ole sellaisia fasilitaattoreita, jotka ymmärtäisivät miten malli toimii, eikä malli välttämättä edes sovellu niin hyvin kaikkien piirien toimintatapaan.”

Lopulta S3-malli ulotettiin myös Codenton hallintoon. Toimintaa ylhäältä käsin ohjaava johtoryhmä lakkautettiin viime keväänä, ja tilalle tuli työntekijöiden muodostama hallitus. Turo nominoitiin hallituksen puheenjohtajaksi.

“Normaalissa organisaatiossa en edes suostuisi tällaiseen vastuutehtävään, koska käytössä ei olisi läheskään tarpeeksi tietoa, eikä edes sitä, mistä saisin tarvittavaa tietoa, jotta vastuuta pystyisi realistisesti ottaen toteuttamaan ilman, että on hermorauniona. Codentolla on mahdollisuus osallistua mahdollisimman moneen aspektiin organisaatiossa, ja silloin on tosi helppo sanoa, että totta kai voin olla hallitusvastuussa. Tällaisessa organisaatiossa on riittävä näkyvyys siihen, mitä kaikkea tapahtuu ja mihin kaikkeen on otettava kantaa.”

 

Sadan hengen viikkokokous?

Tulevaisuudessa Codento kasvaa, ja ovesta tulee nyt jo viikottain uusia ihmisiä. Itseohjautuvassa organisaatiossa on helppo löytää paikkansa, vaikka hakisikin sitä ensimmäisen vuoden aikana tekemällä seitsemää eri projektia. Organisaatiolta ja sen itseohjautuvalta mallilta sen sijaan vaatii paljon kestää lavenevan työyhteisön paine. Jo pelkkä kokousten alussa pidettävä fiiliskierros venyy sitä mukaa, mitä enemmän porukkaa on paikalla.

“Erittäin hyvä kysymys on, miten S3-malli toimii sitten kun meitä on sata. Vaikka antaisin tähän minkä tahansa vastauksen nyt, se ei todennäköisesti tule pitämään paikkansa, koska olemme jatkuvan parantamisen organisaatio, ja kokeilemme erilaisia ratkaisuja kun ongelmia löydetään. Olemme jo nyt nähneet kipukohtia siinä, kun meitä on viikkiksessä 40 hengen porukka”, Turo pohtii hetken aikaa.

“Seuraavan kahden vuoden aikana todennäköisesti olemme keksineet mallin myös siihen, miten sadan henkilön viikkistä toteutetaan”, hän toteaa.

Välineitä itseohjautuvuuteen – Sosiokratia 3.0 -koulutus Helsingissä 8.-10.4.2019

Epäonnistuitko sinäkin tiedolla johtamisessa? – Organisaatioiden yleisimmät virheet ja miten niistä selvitään

Organisaatioiden toiminta tuottaa dataa, jota pyritään hyödyntämään päätöksenteossa. Halutaan tehostaa toimintaa tai säästää rahaa. Tiedolla johtaminen ei ole kuitenkaan niin helppoa kuin miltä se kuulostaa. Datan keräämiseen ja sen analysointiin voi kulua yllättävän paljon ostettuja tai omia resursseja. Analyysien luvut saattavat heittää tai olla suorastaan virheellisiä! Dataa on, mutta kukaan ei tiedä missä ja miten paljon. Tässä kohtaa tekee mieli heittää hanskat tiskiin. Muotivillityksiä! Hoidetaan tämä niinkuin aina ennenkin.

Eikö kuulostakin tutulta? Lue eteenpäin, sillä tässä blogissa nostetaan esiin viisi hyvin yleistä ja silti keskeistä ongelmien aiheuttajaa sekä ratkaisuehdotuksia niihin.

 

1. Ei tiedetä mitä tietoa kannattaisi kerätä

Yleensä organisaatiossa ei tunnisteta etukäteen mitä tietoa tarvitaan ja milloin. Keräillään varmuuden vuoksi vähän kaikkea. On kenties mallinnettu prosesseja, mutta astuttu “Näin toivoisimme, että asiat olisivat” -ansaan. Ideaalitilanteen kuvaaminen on ajan ja rahan hukkaa.

Ryhtiliike voidaan ottaa seuraamalla mitä työntekijöiden arjessa päivittäin tapahtuu. Tärkeintä on mallintaa todellinen, jopa inhorealistinen, kuva siitä millaisia työvaiheita prosessiin kuuluu ja millaista tietoa vaiheiden välillä liikkuu. Näin päästään kiinni ongelmakohtiin ja aidosti ratkomaan niitä. Mainio menetelmä näiden haasteiden ratkomiseen on arvovirtakartta. Mistä työstä todella syntyy lisäarvoa?

Tueksi kannattaa lisätä myös arvoketjukartta. Se kuvaa organisaation toimintaympäristönsä kontekstissa ja tekee ilmeiseksi miten nykytilasta päästään kohti tulevaa ja luodaan pohjaa strategialle ja investoinneille.

2. Tieto on levällään siellä sun täällä

Turhan tai päällekkäisen tiedon kerääminen aiheuttaa tilanteen, jossa organisaatio hukkaa aikaa, resursseja ja rahaa sirpaleisen ja epätäydellisen tiedon haalimiseen. Samaa dataa voi löytyä useasta eri järjestelmästä. Eri järjestelmien päällekkäiset tiedot eivät täsmää. Tietoa ei voi siirtää eri järjestelmien välillä nopeasti tai ollenkaan. Organisaatiolla on lopulta paljon tietoa, joka ei tuota lisäarvoa tai on täysin kelvotonta analyysien tuottamiseen. Tavoitteena on uskaltaa luopua turhasta ja yhdistää päällekkäisiä toimintoja. Tiedonhallinta saadaan teknisesti hanskaan kokonaisarkkitehtuuri- ja sovellusarkkitehtuurisuunnittelulla. Arvoketju- ja arvovirtakartat toimivat mainiosti myös tietovirtojen mallinnuksessa.

3. Kaikki keräävät samaa irrallista tietoa – monta kertaa ja turhaan

Raportteja varten kerättävää tietoa ei yleisesti saada suoraan päivittäisen työn tuloksena. Tiedon kerääminen ja ylläpitäminen onkin työlästä, hidasta ja kallista. Erillisiin tiedonkeruisiin kuluva aika ja raha eivät pidemmän päälle kannata, vaan ajavat organisaation tiedonhallintaa entistäkin kaoottisempaan tilaan. Laadukkaan tiedon tuottaminen vaatii rohkeutta ja uskallusta luopua hyödyttömän tiedon keräämisestä. Organisaation prosesseja tehostamalla tieto syntyy osana päivittäistä työtä. Prosesseja hiotaan esimerkiksi Toyota Kata ja Lean Change Management -menetelmillä. Ymmärretään mikä on se päätös, joka tiedon pohjalta ollaan tekemässä ja varmistetaan, että käytettävissä on juuri tämä tieto.

4. Prosessikuvaukset ja työohjeet ovat antiikkisia

Ei riitä, että prosessit on piirretty kerran. Organisaatio uudistuu, työntekijät vaihtuvat ja menetelmät muuttuvat. Vähintä mitä voidaan tehdä on aika ajoin päivittää prosessi. Tehokkaampi tapa on pyrkiä ymmärtämään etukäteen toimintaympäristöä, sen toimijoita ja lainalaisuuksia. Suunnitellaan etukenossa seuraavan sukupolven ratkaisuja. Näin voidaan varautua ajoissa tarvittavilla toimenpiteillä, joita vaaditaan myös kerättävän datan ja järjestelmien suhteen. Konkreettisena esimerkkinä siirrytään ihmisten suorittamasta maastomittauksesta ilmakuvaukseen ja tekoälyn suorittamaan hahmontunnistukseen. Ennakoimalla vältetään tilanne, jossa uudenlaista tietoa ei saada tallennettua vanhaan järjestelmään. Ennakoimalla on mahdollista olla kilpailijoita edellä, reagoimalla ei niinkään.

5. Tieto on hapantunut käyttökelvottomaksi

Usein tiedon päivittää ihminen. Ihmiset taas tekevät paljon virheitä, unohtavat tai laiminlyövät päivittämisen ja tulkitsevat asioita eri tavoin. Tiedonhallinnan ylenkatsominen johtaa kaaokseen, jossa tietoa on syötetty niin monella eri tavalla, että siitä ei voida laskea edes yksinkertaisia tilastoja. Tai jos lasketaan, saadaan vääriä tuloksia! Mittajärjestelmän arviointi, MSA(measurement system analysis), on hyvä työkalu, kun arvioidaan kuinka luotettavaa dataa ollaan keräämässä.

Nykyään koneet voivat hoitaa tiedonkeruun ja muita rutiinitöitä. Luotettavin tiedon ylläpito ja päivitys tarvitsee edelleen ihmistä, mutta käytettävät sovellukset pitäisi suunnitella niin, että ne ennaltaehkäisevät virheitä ja luovat mahdollisimman automaattisesti laadukasta tietoa. Lisäksi kaikissa järjestelmissä pitäisi olla modernit rajapinnat, joiden avulla dataa on helppo lukea, ylläpitää ja kirjoittaa.

Kuka päättää siitä mitä ja miten tietoa kerätään?

Aika harva organisaatio saa kiitettävää arvosanaa tiedonhallinnassa. Mieti vastauksia seuraaviin kysymyksiin ja vertaa niitä aiemmin lueteltuihin kipukohtiin. Miten teidän työpaikallanne on järjestetty seuraavat asiat?

  • Kuka päättää millaisia analyysejä ja raportteja organisaatiossa tarvitaan?
  • Millä perusteella päätetään, että raportti on tärkeä?
  • Onko raportointi koordinoitua ja keskitettyä vai tekevätkö kaikki yksiköt ja osastot omia tilastojaan siilomaisesti?
  • Onko raporteille laskusäännöt ja lasketaanko tilastot vuosittain samalla tavalla?
  • Voiko eri vuosien tuloksia vertailla suoraan keskenään?
  • Miten aineisto kerätään? Kerätäänkö aineistoa systemaattisesti joka vuosi vai tarpeen mukaan ad-hoc?
  • Osallistuuko koko organisaatio tiedon keruuseen vai onko se tietyn yksikön tehtävä?
  • Tallennetaanko kerätty aineisto aina johonkin samaan paikkaan?
  • Onko aineiston keräämiselle ohjeet?
  • Onko tiedonkeruu ulkoistettu?
  • Miten eri toimittajia ohjeistetaan tiedonkeruussa?
  • Onko haluttua aineistoa mahdollista edes kerätä?
  • Miten kerättyä tietoa ylläpidetään?
  • Syntyykö tietoa automaattisesti prosesseista?

Laadukas tieto pähkinänkuoressa

  • Laadukkaan päätöksenteon tueksi tarvitaan tuoretta, vakioitua ja virheettömästi ylläpidettyä dataa.
  • Kerätään vain päätöksentekoa ja päivittäistä työtä tukevaa tietoa
  • Yhtä tietolajia kerätään vain yhteen paikkaan
  • Tunnistetaan turha tieto ja uskalletaan luopua siitä
  • Tieto muodostuu osana päivittäisiä työprosesseja
  • Tieto on sidottu aikaan
  • Automatisoidaan keruuprosesseja mahdollisimman paljon
  • Standardoidaan tieto

 

Blogitekstin kirjoituksessa on konsultoitu myös Lean Six Sigma Belt Sensei Miika Kuhaa.

Kato webinaari: Paikkatietoteknologian hyödyntäminen

Mitä on GIS? – paikkatietoteknologiaa voidaan hyödyntää melkein alalla kuin alalla

Aika moni luulee, että GIS tarkoittaa karttojen tekemistä. Kartat ovat kyllä yksi tärkeä tiedon esitystapa, mutta kokonaisuudesta vain se korkein jäävuoren huippu. Paikkatietoa keräämällä ja analysoimalla tuetaan päätöksentekoa – GIS on myös tiedolla johtamista.

GIS on akronyymi sanoista Geographic Information System ja tarkoittaa suomeksi paikkatietojärjestelmää. Järjestelmällä voidaan hallita paikkaan sidottua tietoa. Paikkatietoasiantuntijoina työskentelevät ovat yleensä opiskelleet geoinformatiikkaa ja jotain muuta tieteenalaa, jossa GIS:iä sovelletaan paljon.

Geoinformatiikka edistää ja kehittää paikkatietojärjestelmiä ja -analyyseja. Geoinformatiikka on poikkitiede, johon kuuluu mm. maantietoa, tietojenkäsittelytiedettä sekä tilastotiedettä.

GIS-analyysit

GIS -analyysit ovat tilastoanalyyseja tai tiedonlouhinnan menetelmiä, joissa lisämausteena on sijaintitieto. Algoritmeja ovat mm. klusteroinnit, korrelaatiot ja erilaiset verkot. Yksinkertaisimmillaan ne ovat tilastollisia summia tai keskiarvoja sidottuina sijaintiin.

Vaikeampia analyyseja ovat esimerkiksi lyhimmän reitin etsintä katuverkolla, hahmontunnistus ilmakuvan pikseleiden sävyarvoja luokittelemalla tai ennusteiden luominen ja visualisointi aikasarjojen avulla. Sijainnin avulla kaikki tieto voidaan visualisoida myös kartalla.

GIS -analyysit jaetaan perinteisesti vektori- ja rasterianalyyseihin. Vektoridata on viivoja, pisteitä ja alueita. Rasteridata taas on kuvia, joiden pikseleillä on sijaintitieto. Aineisto voi olla kaksiulotteista tai kolmiulotteista.

Maailman tunnetuin GIS -palvelu lienee Google Maps, mutta mikä tahansa digitaalinen palvelu, johon liittyy kartta on samalla myös GIS -palvelu. Esimerkiksi monet kaupat hyödyntävät paikkatietoa ilmoittamalla karttapalvelussa tuotteiden myymäläkohtaisia saatavuustietoja tai aukioloaikoja. Pihvi on kuitenkin järjestelmän kyvyssä yhdistää tietoa myymälöiden keskimääräisestä asiakasprofiilista ja niiden aukioloajoista esimerkiksi julkisen liikenteen dataan tai tietoon parkkipaikoista.

 

Minkä vuoksi kannattaa visualisoida tietoa kartan avulla?

  1. Ihmisen aivot ymmärtävät kuvamuotoisen esityksen nopeammin
  2. Kuva on yksinkertainen ja havainnollinen ja sillä voi esittää helpommin monimutkaista tietoa
  3. Visuaalisen esityksen muistaa pitempään
  4. Kuvilla voi kertoa tarinoita, kartoilla erityisen hyviä sellaisia
  5. Visualisointien avulla huomataan helpommin trendejä, jotka hukkuisivat numeromuotoiseen dataesitykseen

 

Paikkatiedon sovelluskohteet

Paikkatietoa hyödynnetään muun muassa maa- ja metsätaloudessa, rakennetun ympäristön suunnittelussa ja omaisuudenhallinnassa, sääolosuhteiden -ja luonnonkatastrofien tutkimuksessa, ilmailussa, maanpuolustuksessa, energiateollisuudessa, historian tutkimuksessa sekä tietokone- ja konsolipeleissä. Listassa on lueteltu vain muutamia sovelluskohteita.

Paikkatietoa voidaan käyttää hyvin monipuolisesti. Vain mielikuvitus on rajana sen soveltamisessa.

Ilmoittaudu webinaariin: Paikkatietoteknologian hyödyntäminen 1.2.2019 klo 9.00.