Shit that works – Kolmen päivän kylpy S3:n ja itseohjautuvuuden parhaisiin käytäntöihin

Codentollakin käytössä olevan päätöksentekomallin kehitystiimiin kuuluvat James Priest ja Liliana David johdattivat muiden mukana neljä codentolaista syventymään Sosiokratia 3.0 -mallin käytännön harjoituksiin.

Codento ja Thrive-in Collaboration järjestivät huhtikuun alussa yhteistyössä Suomen ensimmäisen Sosiokratia 3.0 -kurssin Helsingin Allas Sea Poolilla. Itseohjautuvuudesta kiinnostuneita osallistujia Altaan kurssilla oli Suomen lisäksi muun muassa Hollannista ja Venäjältä.

Osassa organisaatioista itseohjautuvuutta vasta tunnusteltiin ja toisissa oltiin jo pitkällä viemässä päätöksentekoa organisaation jokaisen jäsenen käsiin. Kurssilla keskityttiin hyvin käytännönläheisesti S3-mallin peruspalikoihin, erilaisiin toimintamalleihin, suostumuspäätöksentekoon ja piirityöskentelyyn.

Kolmen päivän aikana opittiin yhteistoiminnan käytännöistä, suostumuspäätöksenteosta, taidokkaasta osallistumisesta ja konfliktien hallinnasta niin koko porukalla kuin pienryhmissäkin, simuloiden todellisia organisaation päätöksentekotilanteita. Vaikka kurssilla opiskeltiin perustason Sosiokratiaa, ja ohjelmassa oli tuttua asiaa itseohjautuvuudesta ja ketteristä menetelmistä paljon kokemusta omaaville codentolaisille, oli kurssi melkoisen intensiivinen kokemus.

Keskeisiä toimintamalleja käytiin läpi hyvin huolellisesti ja yksityiskohtia hioen, ja välillä pysähdyttiin pohtimaan päätöksenteon ja työtapojen haasteita ja osallistujien kysymyksiä. Valmennuksen zen-henkinen ote, joka pikemminkin haastoi osallistujat omaan ajatteluun ja pohdintaan kuin olisi tarjoillut valmiita ajatusmalleja, vaati jokaiselta ihan oikeaa ja todellista läsnäoloa joka hetki. Puhelinta tai somekanavia ei siis vilkuiltu yhtenäkään valmennuspäivänä!

Sosiokratiaa käytännön kautta

S3-käytäntöjä ja toimintamalleja opeteltiin kurssilla fiktiivisen työelämätapahtuman avulla. Tapahtuman driver eli sen tarkoitus tai haaste, mikä tapahtuman järjestämisellä ratkaistaisiin, oli jo valmiiksi annettu kurssilaisille. Tapahtuman kuvitteellisen tuotannon varjolla harjoiteltiin noin pariakymmentä S3:een kuuluvaa eri patternia eli toimintamallia. Yhteensä näitä malleja S3:ssa on yli 70 kappaletta, joten lähtötason kurssilla päästiin Sosiokratiassa vasta alkuun.

Ensin aloitettiin driver mappingista eli kartoitettiin, minkälaisten erilaisten drivereiden tarpeessa koko tapahtuman tuotanto oli. Toimintamallissa kerättiin porukalla siis ideoita siitä, mitä kaikkea tapahtuman toteuttamista varten tarvitaan.

Kun erilaiset tapahtuman järjestämiseen tarvittavat asiat oli löydetty, etsittiin sopivia kokonaisuuksia, joihin nämä driverit kuuluivat (esim. fyysisiin tiloihin liittyvät driverit, markkinointiin ja viestintään liittyvät driverit ja niin edelleen.)

Piirit työskentelevät domainien ympärillä

Piirityöskentelyä päästiin harjoittelemaan, kun kurssilaiset jakautuivat mielenkiinnon mukaan noin viiden hengen asiakokonaisuuksien domainalueiden piireiksi. Piirien sisällä harjoiteltiin lisää drivereiden tekoa, kuten domainin olemassaoloa määrittävää primary driveria ja tavallisia drivereita. Esimerkiksi fyysisten tilojen domainissa tavallisia drivereita olivat muun muassa sopivien tilojen etsiminen, osallistujien kuljettaminen tapahtumaan tai tapahtumatilojen sisustaminen.

Driverissa kuvataan nykytila ja mitä halutaan seuraavaksi. Ratkaisusta ei siis puhuta vielä tässä vaiheessa mitään, eli “Tällä hetkellä ei ole tiloja, missä tapahtuman voisi järjestää, joten tarvitaan sopiva tila”, mutta ei “Tällä hetkellä ei ole tiloja, missä tapahtuman voisi järjestää, joten vuokrataan sopiva tila taholta X”.

Välissä haluttiin myös parantaa domainalueiden piirien välistä kommunikaatiota ja päätettiin perustaa delegate circle (delegaattipiiri), johon valittiin jokaisesta domainista yksi edustaja. Edustajan valintaan käytettiin role selection- eli roolinvalinta-toimintamallia.

 

Drivereista ratkaisuehdotuksiin

Kun driverit oli saatu kasaan, ne priorisoitiin ja harjoiteltiin proposal formingia eli ratkaisuehdotuksen muodostamista, jossa tehtiin siis konkreettisia ratkaisuehdotuksia jollekin yksittäiselle driverille. Usein varsinaista ratkaisuehdotusta ei tehdä koko porukalla, vaan parin vapaaehtoisen tuunaajan toimesta. Fyysisten tilojen domainissa ratkaisuehdotuksena esimerkiksi osallistujien kuljettamiseen tapahtumaan oli tarjousten pyytäminen tietyiltä kuljetusfirmoilta ja niistä halvimman valitseminen.

Olennaista on kurssillakin painotettu asia, eli muistaa määrittää kuka on (tai ketkä ovat) vastuussa mistäkin asiasta, esimerkkitapauksessa tarjousten pyytämisestä ja halvimman valitsemisesta.

Myös ratkaisun onnistumisen arviointi on S3:ssa tärkeää, jotta tekemisestä opittaisiin jatkossa; tässä yksinkertaisessa tapauksessa evaluointikriteerinä voi olla esimerkiksi se, että halvin on valittu tiettyyn päivämäärään mennessä (eli ei jäädä vaikkapa odottelemaan tarjouksia liian pitkäksi aikaa). Jälleen on myös syytä muistaa määrittää ketkä ovat vastuussa evaluoinnin toteutumisesta.

 

Päätöksenteossa keskeistä on suostumus

Kun ratkaisuehdotus oli valmis, päästiin harjoittelemaan S3:n yhtä keskeisintä toimintamallia eli consent decision making (suostumuspäätöksenteko) -patternia, jonka tarkoituksena on etsiä mahdollisia vastalauseita sille, onko ratkaisuehdotus riittävän hyvä ja “vaaraton” eli good enough for now, safe enough to try.

Koska aikaa ratkaisuehdotusten tekemiseen oli rajallisesti, jokaisessa ryhmässä ratkaisuehdotukset olivat usein tavalla tai toisella heikkoja, jolloin mahdollisia vastalauseita myös löytyi paljon. Näin päästiin luontevasti harjoittelemaan myös resolve objections- eli vastalauseiden käsittelyn -toimintamallia, jonka tarkoituksena on lopulta parantaa ratkaisuehdotusta ja tehdä siitä mahdollisimman toimiva.

Kun vastalauseita ilmaantuu, validoidaan ensin, että kyseessä todella on vastalause, eikä esimerkiksi huoli. Validointi tehdään kysymällä muilta. Varmistamisen jälkeen ehdotusta muokataan joko vastalauseen esittäjän tai tuunaajien toimesta sellaiseksi, että vastalause on otettu huomioon. Mikäli ehdotus onnistutaan muokkaamaan samantien hyväksytysti, päästään heti äänestämään uudesta ehdotuksesta, mutta joskus muokkaus joudutaan tekemään erikseen ja päätöstä lykkäämään seuraavaan kokoukseen.

Keskeistä S3-päätöksenteossa onkin consent eli suostumus, joka on myös yksi mallin seitsemästä periaattesta. James ja Lili nostivatkin esiin sen, että consent poikkeaa konsensuksesta, sillä yhteneväiseen mielipiteeseen pyrkimisen sijaan erimielisyyksiä ja ristiriitoja jopa haetaan. Näin käsillä olevaa päätöstä tai kokonaista organisaatiota voidaan kehittää esille nousseita epäkohtia korjaamalla. Keskustelu ratkaisuehdotuksesta etenee argumentoiden, ja näin ehdotukseen liittyvät huonotkin puolet nousevat pöydälle, jolloin voidaan tehdä valistuneempia päätöksiä.

 

Seitsemällä periaatteella tuotetaan luottamusta

Yli 70:n toimintamallin patteriston kokoaminen ei ole Jamesin ja Lilin mukaan ollut helppoa, ja itse S3-malliakin parannetaan koko ajan. Joukosta löytyy myös paljon tuttuja asioita Leanistä ja muista ketteristä menetelmistä. Sosiokratia 3.0 -mallin ja patternien läpi leikkaa seitsemän periaatetta, joihin kuuluu suostumuksen lisäksi muun muassa jatkuva kehittäminen, vastuullisuus ja empiirisyys.

Vaikka luottamus on tärkeä osa S3-mallia, se ei kuitenkaan kuulu mallin seitsemään periaatteeseen. Kurssilla kysyttiinkin erikseen tästä, ja vastauksena James ja Lili totesivat, että luottamus itse asiassa kumpuaa kaikista muista periaatteista, joten niiden tarkoitus on nimenomaan tuottaa luottamusta.

Kun päätöksenteossa ja työtavoissa toteutetaan seitsemää periaatetta, luottamus lisääntyy organisaatiossa. Toisaalta toimintamallien ei ole tarkoitus olla itseisarvo; jos jokin toimintamalli ei tunnu toimivan tai istuvan oman organisaation arkeen, silloin siitä ei todennäköisesti ole hyötyä eikä se ratkaise mitään, ja Jamesin ja Lilin neuvo oli tällöin hylätä se yksin tein.

Läpinäkyvyys on yksi S3:n läpi kulkevasta seitsemästä periaatteesta ja hyvin tärkeä peruspalikka siinäkin mielessä, että jotta voidaan saada koko organisaation suostumus johonkin, päätöksentekoon osallistuvien on tiedettävä, mihin he ovat suostumassa. Ongelmia seuraakin, mikäli driverit ja proposalit ovat heikosti muotoiltuja – Codentollakin olemme saaneet kokea, kuinka paljon työtä hyvin muotoillun ehdotuksen tekeminen voi vaatia. Mikäli keskustelussa ilmenee, etteivät puoletkaan ihmisistä ymmärrä, mistä on kyse, joudutaan ehdotusta parantelemaan ja päätöstä lykkäämään.

Sosiokratia 3.0 -kurssilta saatiin myös todistukset.

Kurssilta saatiin myös todistukset.

 

Metaoivalluksia kurssilta

Suurin kurssilta mukaan saatu Sosiokratia-oivallus liittyi siihen, että Sosiokratia 3.0 ei ole mallina kokonainen viitekehys tai avaimet käteen -periaatteella toimiva hopealuoti organisaation muutoskyvykkyyden ja itseohjautuvuuden lisäämiseen. Itse asiassa S3-malliin kuuluvia patterneja eli toimintatapoja voidaan ottaa käyttöön sitä mukaa, kun ne istuvat organisaation toimintaan ja aidosti hyödyttävät ja tehostavat työtapoja ja prosesseja.

James totesikin heti kurssin alussa, että Sosiokratia 3.0 -mallissa ei ole kyse kokonaisratkaisusta, vaan kokoelmasta hyväksi havaittuja käytäntöjä, joiden avulla yhteistoiminta työyhteisössä on helpompaa ja sujuvampaa – shit that works.

Tarkoitus ei ole tehdä vallankumousta tai organisaation kokoista mullistusta vaan saada kollektiivinen älykkyys hyötykäyttöön organisaation jatkuvaan tehostamiseen ja parantamiseen. S3 voisi olla yhtä hyvin käytössä hierarkisessakin linjaorganisaatiossa, vaikkakin se toimii parhaiten silloin, kun organisaation jäsenet voivat aidosti ja tasavertaisesti osallistua päätöksentekoon.

Artikkelin kirjoitustyöhön osallistuivat S3-kurssille osallistuneet codentolaiset Markus Linnalampi, Tuomas Manninen, Evgenia Lyjina sekä Esko Niiranen.

Voit lukea codentolaisten aiempia S3-kurssikokemuksia täällä.

Välineitä itseohjautuvuuteen ja yhteiseen päätöksentekoon – Sosiokratia 3.0

Mikä ohjelmistoprojekteissa maksaa – ja miten ne kannattaisi budjetoida?

Jos markkinoilta ei jo löydy tarpeeseen sopivaa valmista ohjelmistoa tai SaaS-palvelua, tai jos olet itse tarjoamassa nimenomaan softapohjaista palvelua omille asiakkaillesi, olet todennäköisesti ohjelmistoprojektin kynnyksellä. Miksi sitten ohjelmiston tai verkkopalvelun rakentaminen ei käy samalla budjetilla, jolla viime vuonna uudistettiin firman verkkosivut? Mikä ihme sovelluksessa maksaa?

Sovelluksen tai ohjelmiston rakentamisen vertaaminen verkkosivujen tuottamiseen ontuu monella tapaa, eikä vähiten siksi, että verkkosivuihin on olemassa valmiita suunnitteluohjelmia, pohjaratkaisuja ja alustoja, joiden päälle sivut voidaan rakentaa. Verkkosivut ovat kaikki pitkälti teknisesti melko samanlaisia, eikä pyörää kannatakaan lähteä keksimään uudelleen näin geneerisen palvelun tuottamiseen.

Kun taas teet uutta softaa, se tehdään aina jollakin tapaa räätälöidysti, eikä valmiita ratkaisuja pystytä samassa mitassa hyödyntämään. Asiaa toki helpottaa, että softan tuottamiseen käytetään jotain yleisesti käytössä olevaa teknologiaa, johon löytyy paljon sellaisia komponentteja, joita pystytään hyödyntämään myös uudessa projektissa.

Tästä huolimatta ohjelmiston rakentamisessa tehdään paljon räätälöityjä ratkaisuja. Mitä enemmän niitä on, sitä enemmän kehitystyö maksaa. Yleistettynä siis, mitä monimutkaisempi järjestelmä, sitä enemmän se maksaa.

 

Softaprojektin hintaa eriteltynä

Jos järjestelmään pitää rakentaa esimerkiksi erilaisia käyttöliittymänäkymiä eri käyttäjäryhmille, esimerkiksi omanlaisensa admin-näkymä ja käyttäjänäkymä erikseen,  ja jos nämä sisältävät erilaisia toiminnallisuuksia, kyseessä ei ole pelkkä kopioimistyö. Kehittäjän aikaa menee näkymien speksaamiseen eri käyttäjäryhmille sekä niiden toteutukseen.

Edelleen kakkua kohottaa, mikäli dataa halutaan tuoda jostain muualta tai viedä sitä järjestelmästä ulos, jolloin tehtäväksi tulee integraatioiden rakentaminen. Se, paljonko integraation rakentaminen kestää, riippuu paljon siitä, minkälaisia linkitettävien järjestelmien rajapinnnat ovat. Jos vastassa on vanhaa protokollaa ja legacy-ratkaisuja, voi integroiminen olla huomattavasti monimutkaisempaa kuin modernimmalla teknologialla.

Myös käyttöliittymän ulkoasu vaikuttaa hintaan; mitä huolitellumpaa, hiotumpaa ja näyttävämpää halutaan, sitä enemmän työtunteja kuluu, ja projektiin on hyvä silloin ottaa myös käyttöliittymäsuunnittelija mukaan. Jos vaatimus on taas yksinkertainen “insinöörikäyttöliittymä”, voidaan kehittäää käyttöliittymä, jolla asiat voi järjestelmässä helposti suorittaa tinkimällä hieman ulkoasusta.

Keskeistä tässä lienee se, kenelle järjestelmä on suunniteltu – mikäli sitä käyttää harva asiantuntija, voi käyttöliittymä olla hyvinkin funktionaalinen. Kuluttajille sen sijaan tehdään aina huoliteltuja käyttöliittymiä, jolla varmistetaan sovelluksen hyvä käyttökokemus, mikä on monesti elinehtona laajan käyttäjäkunnan kuluttajasovelluksille.

Raportointi voi olla iso siivu ohjelmistoprojektin kustannuskakussa. Jos järjestelmään halutaan erilaisia raportointityökaluja, esimerkiksi sensoridatasta pdf-sivuja, kasvatetaan jälleen työmäärää.

Olennaista onkin kysyä mitkä ovat raportteja, jotka ovat sovelluksen käytön kannalta tärkeä olla mukana. Raportointimahdollisuuksia on helppo laajentaa jos sovelluksen käytön aikana huomataan jonkin olennaisen raportointimahdollisuuden puuttuvan valikoimasta.

 

Miten ohjelmistoprojekti budjetoidaan?

Useimmissa organisaatiossa tehdään vuosibudjetti tai projektibudjetti, jonka raameissa tulisi pysyä. Yksittäisen ohjelmistoprojektin budjetointia on hankala miettiä tämän kehyksen sisällä, sillä projekti taas saattaa kestää budjettikaudesta toiseen.

Suotavaa olisi tästä huolimatta varata projektiin ketterää budjettivaraa yllätyksien varalle. Kehitysprojektin ja varsinkin testauksen aikana saattaa tulla tarpeita uusille ominaisuuksille, jolloin niitä olisi harmillista jättää budjetin puutteen vuoksi pois.

Ketterän kehityksen lainalaisuuksiin kuuluu myös kehitysprosessin aikana oppiminen, jolloin on tärkeää voida tehdä nopeitakin kehityssuunnan muutoksia mikäli huomataan ominaisuuksien prioriteettijärjestyksen muuttuvan.

Kun työmääräarvioita tehdään, perustetaan ne omiin kokemuksiin. Mikään softaprojekti ei kuitenkaan ole samanlainen, jokaisessa on aina jotain uutta, jota ei voida ennakoida. Kehitystiimin vastuulla on toki osata arvioida ja ottaa aikavaraa yllätysten varalle.

Niinkin päin voi olla, että lähdettäessä tekemään projektia asiakas on osannut itse tilaajana ottaa huomioon kaikki olennaiset seikat. Useimmiten kuitenkin käy ilmi, että näin ei ole ollutkaan. Siinä kohdin kehitystyötä olisi ikävä jättää kesken, koska esimerkiksi kriittisen ominaisuuden tarvetta ei huomattu alun speksauksessa.

 

Osta kokeneelta tiimiltä

Tiimi, joka on tehnyt enemmän yhdessä hommia, osaa paremmin arvioida, kuinka nopeasti he pystyvät tuottamaan valmiita ohjelmisto-osuuksia. Tiiviisti hitsautunut tiimi osaa tehdä töitä tehokkaammin ja osaa myös arvioida paremmin työhön kuluvan ajan. He myös tuntevat toistensa vahvuudet ja heikkoudet, jolloin kehityssprintin suunnittelussa tiimi osaa valita jäsenilleen sopivimmat taskit.

Jos tehdään jotain, mitä toimittaja on tehnyt jo aiemmin, on tekeminen yleensä helpompaa. Yleensä se tuo myös lisäpotkua projektiin, kun aiemmista projekteista tuttujen komponenttien joukosta löytyy sellasia, joita voidaan hyödyntää käsillä olevassa työssä, jolloin projektille saadaan lentävä lähtö.

Mitkä ovat ohjelmistoprojektisi kustannukset? Arvioi hintalaskurilla.

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.

 

“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