Miten GDPR pitää huomioida ohjelmistokehityksessä?  

Suomalaisten organisaatioiden, yksityisten ja julkisten, pitää toimia EU:n GDPR-tietosuojalainsäädännön mukaisesti 2018 toukokuuhun mennessä. Moni yrittää suoriutua tästä vain sopimusmuutoksin ja lakimiesten voimin.

Tällaiset hankkeet eivät juuri koskaan voi onnistua ja tulevat kalliiksi, kun helppoja ja toimivia ohjelmistotyön muutoksia yritetään vältellä kalliiden sopimusmuutosten kautta.

Voiko turhan GDPR-työn välttää?

Voi. Tietojärjestelmien pitää olla GDPR-vaatimustenmukaisia vain, jos niissä on selvästi yksittäiseen eurooppalaiseen liitettävissä olevaa henkilötietoa. Suuressa osassa tietojärjestelmiä tätä tietoa toki on.

Vanhaan tapaan on kuitenkin turha jämähtää, sillä näin ei ole pakko toimia. Monista tilastollisista järjestelmistä voidaan jättää henkilötiedot kokonaan pois. Nämä ns. anonymisoidut tiedot eivät vaadi tietosuojalainsäädännön mukaisia toimia. Esimerkiksi useimmat tilastolliset analyysit voidaan suorittaa yhtä hyvin anonymisoiduille kuin alkuperäisille tiedoille.

Osasta järjestelmiä ei kaikkea henkilöön viittaavaa voida kuitenkaan poistaa. Esimerkiksi bonuskortin tietoja käsittelevään järjestelmään voidaan jättää ne avaimet, joilla toisten järjestelmien tiedot saadaan purettua ymmärrettävään muotoon niin, että vaikka tiedot joutuisivat vääriin käsiin, ei niistä vielä voisi päätellä kenestä todellisuudessa on kyse.

Tällainen pseudonymisoitu tieto on itsessään GDPR:n tavoitteiden mukaista ja näyttäisi siltä, että useat lainsäädännön vaatimukset kuten

  • tiedon käyttö vain alkuperäiseen tarkoitukseen
  • tietoturvaloukkausten raportointivelvollisuus
  • ja joissain tilanteissa jopa oikeus tiedon siirrettävyyteen sekä poistoon
  • uusien tietoturvaratkaisujen tarve

eivät koskisi pseudonymisoitua tietoa.

Edellä kuvattu toimintatapa mahdollistaa tilanteen, jossa vain muutama järjestelmä tulee pitää GDPR-vaatimuksien tasalla ja se on paljon helpompaa kuin jos järjestelmiä on kymmeniä tai satoja.

Ripaus leaniä GDPR-hankkeisiin

Olen vuosien varrella keskittynyt avoimeen lähdekoodiin, tietoturvaan, lean-menetelmiin ja tietosuojaan, ja olin onnesta soikeana, kun huomasin, että Mozilla, kuuluisa Firefox-selaimesta vastaava avoimen lähdekoodin pohjantähti, on lähestynyt tietosuojaa lean-maailmasta tutuin konseptein.

Mozillan Lean data practices -lähestymistavassa on kolme peruspilaria:

1. Stay lean

  • Kerää vain tietoa, jota tarvitset.
  • Älä säilytä tietoa, jota et enää tarvitse sekä
  • Anonymisoi kaikki tieto, jonka voit

2. Build in security

  • Rajaa pääsy tietoon niille, jotka sen todella tarvitsevat
  • Salaa tietoa sitä siirrettäessä
  • Ole tarkkana, mihin tiedon tallennat ja miten

3. Sitouta käyttäjäsi

  • Tietosuojan pitäisi olla itsestäänselvää
  • Jos näin ei ole kerro tarkkaan, mitä teet

Lean data practices ei kata kokonaan GDPR-vaatimuksenmukaisuutta, eikä siten suoraan riitä eurooppalaisten vaatimusten täyttämiseen, mutta se on erittäin selkeä tapa kuvata mistä todella on kyse.

Lean-ajattelun käyttäjäkeskeinen lähestymistapa on lähes täydellinen kuvaus siitä, mitä vaatimuksenmukaisuuden tästä eteenpäin tulisi olla. Tietosuojan maallikoille tämä yksinkertainen jaottelu saattaa auttaa ymmärtämään GDPR:n vaikutuksia.

Lean-ajattelu auttaa tietosuojatyössä

Leanin tavoin fiksu ja laillinen tietosuojatoiminta on keskittynyt sen ympärille mitä käyttäjä tarvitsee. Tieto, jota tallennetaan, vaikka sitä ei tarvita käyttäjän palvelemiseen on hukkaa, josta pitää päästä eroon. Prosessit, jotka ovat monimutkaisia, silloin kun yksinkertainen riittää, ovat huonoja tai jopa laittomia lainsäädännön valossa.

Lean-toiminta pakotti autotehtaat rakentamaan parempia kulkupelejä. Toyotan aloittama raikas ajattelutapa muutti koko toimialan toimintamallin.

Lean-ajattelu auttaa viemään läpi saman suuren muutoksen tietosuojatyössä.

Väitän, että hyvän tietosuojatoiminnan pitää muistuttaa enemmän lean-mentorointia kuin vanhakantaisen tietoturvaosaston tapaa toimia.

Mozillan blogiartikkeli aiheesta löytyy täältä.

 

Piirroskuva: Mozilla blog on Open Internet policy initiatives and developments

TallennaTallenna

Onko tää nyt siis piiri? – Kokemuksia Sociocracy 3.0:sta

Kaksiosaisen blogisarjan ensimmäinen postaus käsitteli lyhyesti Sociocracy 3.0:n päätöksetekokäytäntöjä. Lue aiempi blogaus täältä.

Miten Codento päätyi Sociocracy 3.0:aan?

Loppuvuodesta 2016 se alkoi olla meille selvää: Codento tarvitsee päätöksentekoonsa muita työkaluja kuin selkärangasta revityn perinteisen organisoitumistavan yhdistettynä intoon tehdä järkevästi ja ottaa kaikki mukaan (meilläkin on siis innostuttu tealistä).

Codentossa on töissä analyyttisiä ihmisiä, jotka haluavat tehdä asiat hyvin. Niinpä meillä kaivataan konkreettisia työkaluja enemmän kuin ylevää puhetta. Lähdimme hakemaan uudelleen organisoitumiseen jotakin kättä pidempää.

Tältä pohjalta teimme vuoden 2016 lopussa rivakan etsinnän valmiista menetelmästä, joka auttaisi meitä kohti yhteistä päätöksentekoa. Etsinnän tuloksena päädyimme Sociocracy 3.0 -menetelmään. Se tuntui hyvältä yhdistelmältä leanistä ja ketteryydestä tuttuja arvoja ja erityisesti yhteiseen päätöksentekoon keskittymistä.

Missä kohtaa nyt mennään?

S3-toimintatapaa on nyt harjoiteltu vajaa vuosi, ja tulokset ovat osittain hyvin konkreettisia.

Jos joku olisi tipahtanut torstain viikkokokoukseemme vuosi sitten, hän olisi nähnyt harvalukuisen joukon. Viikkokokouksessa puheenvuoroja käyttävät olivat harvassa ja loput osallistujat kiemurtelivat miettimässä, miten kokouksen asiat oikeastaan liittyvät omiin töihin, jotka mielessä polttelivat.

Nykyään viikkokokouksiin osallistuu valtaosa codentolaisista (kohtuullisen) innokkaasti. Kysymyksessä on keskeinen kokous, jossa yhdessä tehdään päätökset kaikille tärkeimmistä asioista, joita mikään yksittäinen piiri, eli tärkeitä asioita ratkova parvimainen tiimi, ei pysty yksin ratkaisemaan.

Asialista muodostuu esimerkiksi kymmenen eri ihmisen toivomista kohdista, joissa piirit nostavat esiin tekemisiään paremman Codenton hyväksi. Tärkeissä kysymyksissä kuullaan kannanotto kaikilta.

Tärkeimmältä tuntuu kuitenkin se, että codentolaiset ovat itse valitsemassa, mitä haasteita Codentossa ratkotaan ja miten. Jokaisella on velvollisuus ja oikeus nostaa esiin jännitteitä ja muodostaa niistä drivereita, joko piirien työssä tai niiden ulkopuolella. Lisäksi koko porukalla astutaan välillä askel taaksepäin ja katsotaan yhdessä, teemmekö oikeita asioita.

Codenton Sociocracy 3.0 -käytännöt

Codentossa ovat lokakuussa 2017 käytössä seuraavat S3-käytännöt:

  • Tunnistettu 10 tärkeää driveria, joita jokaista on ratkomassa piiri (organisoitumisen helpottamiseksi piireistä esillä fasilitaattorit, jäsenet ja päätösten ja työlistojen sijainti)
  • Viikkokokoukset ovat muuttuneet kaikkia koskevien päätösten foorumiksi
  • S3 on osa uusien työntekijöiden perehdytystä. Ajatuksena on, että joku edelliseen perehdytykseen osallistuneista on vuorollaan perehdyttämässä seuraavia.
  • Yhteiset drivereiden eli Codenton ratkomien asioiden valintatyöpajat käyntiin (ensimmäinen marraskuussa 2017)

Tiivistäen voisi todeta, että nyt meillä on olemassa se peruskehikko, joka tekee yhteisen päätöksenteon näkyväksi niin, että kuka tahansa voi osallistua. Kasvokkainen työskentely ei ole ainoa tapamme tehdä sosiokratiaa, vaan työtavat on etsitty myös pikaviestiväline Slackiin.

Tällä hetkellä työskentelemme sen hyväksi, että meillä olisi parempi läpinäkyvyys firman tilanteeseen päätöksenteon pohjaksi. Tavoitteena on, että jokaiselle tiimille ja yksilölle olisi mahdollista hahmottaa, mikä oman panoksen vaikutus on kokonaisuuteen. Myös drivereiden eli ratkottavien asioiden taustatarpeen kommunikointi ja niiden onnistumisen jatkuva arviointi vaatii vielä lisää työtä.

Silti tuntuu hyvältä, että olemme jo tässä kohtaa menossa ja teemme tätä yhdessä. Näinä kuukausina on ollut erityisen kivaa olla codentolainen.

Kenelle Sociocracy 3.0 voisi sopia?

S3-päätöksentekokäytännöissä keskitytään erityisesti haasteiden muotoiluun ja ymmärtämiseen, ennen kuin hypätään ideoimaan ja kokeilemaan ratkaisuja. Niinpä se sopii mahtavasti yhteisen ymmärryksen lisäämiseen.

S3 varmistaa tiukasti, että tärkeissä päätöksenteon hetkissä kuullaan kaikkia, joita asia koskee eikä luoteta satunnaisesta kommentoinnista saatavaan yleiskuvaan, joka usein johtaa harhaan. Näin ollen se on loistava menetelmä ympäristöissä, joissa halutaan lisätä hiljaisempien vaikutusvaltaa ja tuoda kaikki päätöksentekijöinä samalle viivalle.

Sociocracy 3.0 ohjaa arvioimaan säännöllisesti niiden asioiden relevanttiutta, joiden eteen työskennellään. Tämä tekee siitä hyvän käytännön ketterän strategian välineen: saadaan varmistettua, että tavoitteet eivät vanhene suhteessa organisaation kokemaan.

Karoliina Luoto
Twitter @totoroki

—-

Mikäli haluat apua S3-päätöksenteon välineiden käyttöönottoon omassa organisaatiossasi, Codenton konsultit ovat mielellään käytettävissäsi. Ole ystävällisesti yhteydessä joko allekirjoittaneeseen, karoliina.luoto(a)codento.com tai kollegaani miika.kuha(a)codento.com.

Presentaatio tämän blogin sisällöistä Slidesharessa: https://www.slideshare.net/codento/sosiokratia-30-codentossa-80728441.

Katso Codenton avoimet työpaikat

Mitä Hackathonista voi oppia? Case StreetReboot  

StreetReboot: mikä, miksi, mitä ja miten?

Osallistuimme IndustryHackin järjestämään StreetReboot Hackathoniin. Hackathon on muutaman viikon ja loppurutistuspäivien kuumeinen ohjelmointisessio, jonka järjestäjä tai sen rahoittaja on laittanut aluille, ja jonka toiveena ratkaista jokin iso ongelma tuomalla pöytään monenlaisia näkökulmia.

Tyypillisesti järjestämisvaiheessa tuohon ongelmaan ei vielä ole pienintäkään ratkaisuideaa, kun perimmäinen syykin on erittäin suuri kysymysmerkki. Hackathonissa on siis tarkoitus saada iso joukko kehittäjiä eri ryhmissä toimien ja ratkaisten eri näkökulmia annettuun haasteeseen liittyen. IndustryHack on Hackathon tapahtumien järjestämiseen erikoistunut Startup. Heidän tehtävänsä on toimia kokeneena fasilitaattorina hackathonin aikana.

StreetReboot järjestettiin digitalisoimaan Staran toimintaa. Stara lienee monelle tuttu Helsingin kaupungin katujen ja viheralueiden ylläpidosta vastaava yritys. Heidän vastuullaan on lähes 70% Helsingin katu- ja viheralueista.

Miten homma eteni?

Codenton Team Cityketut – eli devaajat Turo Mikkonen, Miili Halkka ja Jukka Purma – osallistui Staran haasteiden ratkomiseen. Alla Turon yhteenveto projektin etenemisestä ja  tiimin kokemuksista.  

Hakemus ja hyväksyntä

Staran haaste innosti heti ja kaihot äänet kehittäjien keskuudessa antoivat ymmärtää kiinnostuksensa. Ideoita heräsi tiimin kesken ja puhetta riitti muun muassa muurahaisalgoritmeista, machine learning -tekniikasta sekä datan visualisoinnista. Tiimin kesken tehtiin omat profiilit, sekä tietysti itse hakemus järjestäjälle eli IndustryHackille.

Pian saimme tietää, että pääsimme valittuun timanttiseen kahdeksan tiimin joukkoon. Itselläni oli loistava fiilis ja erittäin positiivinen asenne eteenpäin mentäessä.

StreetReboot Kickoff 22.9.2017

Ensimmäinen virallinen työpäivä StreetReboot -hankkeessa. Suuntasimme Staran varikolle, jossa meille tarjottiin kahvia, leipää ja aimo annos tietoa käytettävistä API-pisteistä, lisätietoa Staran pääasiallisesta työstä, sekä hiukan lisää tietoa koko tapahtumasta ja sen järjestäjistä.

Jokaiselle tiimille osoitettiin Staralta mentori, jolla siis on kokemusta itse työstä ja sen tarpeista. Meidän tiimimme mentoriksi tuli Staran hoitopäällikkö Juha-Pekka Tissari.

Juha-Pekka kertoi meille monista hankalista työtehtävistä, mitä voisi korjata tai muuttaa heidän tarpeisiinsa sopivimmiksi. Lisäksi kaikille tiimeille demonstroitiin Staran hoitokalustoa. Kävimme katsomassa tarkemmin koneiden sisältöä, työkaluja, sekä työtehtävien raportointiapplikaatiota. Aikataulut venyivät iltaan, mutta paljon informaatiota sulattaneena ideoimme vielä vähän samana päivänä työtapoja sekä lopullista demoa.

StreetReboot Hackathon 6.-7.10.2017

Ennen itse Hackathon tapahtumaa olimme sopineet työmme aiheen, data-pisteet, työkalut sekä vastuualueet. Testiympäristönä käytimme Lego Technic -sarjan aura-autoa, jonka auraa tarkkailemme Arduinolla. Datan käsittely, tutkimus ja esittely taas hoidettiin Pythonilla ja JavaScriptillä.

Hackathon järjestettiin Elisa HQ:ssa, eli Pasilan pääkonttorilla. Saavuimme paikalle, ja meille ojennettiin vihreät StreetReboot -hupparit sekä nimikyltit. Päivä alkoi käytännön asioilla, jonka jälkeen ryhdyttiin hommiin.

Aluksi sovimme tarkemmin mitä kukakin tekee, sillä osa datasta kerrottiin vasta äskettäin. Teimme Kanban-boardin ja tiketit, sekä ryhdyimme hommiin. Tapahtuma oli erittäin hyvin järjestetty, saimme ruokaa ja välipaloja työn äärellä ja tiimin omat työhuoneet auttoivat keskittymisessä erittäin paljon.

Ensimmäinen päivä menikin vauhdikkaasti ja saimme paljon aikaan. Oli kunnon tekemisen meininki! Toisena päivänä tavoitteena oli saada demoesitys kuntoon. Rajoitetun ajan takia kuitenkin emme päässeet haluttuun lopputulokseen, mutta meillä oli back-up -suunnitelmana auran statuksen muuttavaa dataa. Saimme kuitenkin itse Demo Fair -osuuden aikana asiat toimimaan halutulla tavalla. Vaikka haluttuun lopputulokseen ei ihan päästy, en usko sen vaikuttaneen tuomarien päätöksiin.

Emme yltäneet voittoon, mutta kokemus oli mainio! Pidin erityisesti tiimini yhteistyöstä, toimimme erittäin hyvin yhteen ja vastuut jakautuivat oman osaamisen mukaisesti. Emme ole Miilin ja Jukan kanssa samoissa projekteissa olleet, mutta tämä kokemus antoi minulle erittäin positiivisen kuvan heidän kanssaan työskentelystä.

Jos jotain olisin tehnyt vielä paremmin, niin omaan tiimiin olisin ottanut vielä yhden henkilön lisää, jolloin joko minä tai tuo kuvitteellinen neljäs tiimiläinen olisi keskittynyt enemmän idean esitelmöintiin, dokumentointiin sekä myymiseen. Näillä eväillä olisi hackathon voitettu vuoren varmasti!

Turon vinkit Hackathon-tapahtumiin osallistuville

Olen jo muutamaan ‘hackathonmaiseen’ tapahtumaan osallistunut, ja näistä kokemuksista oppineena haluan suositella Hackathoniin osallistujille muutamaa hyväksi todettua tapaa.

  1. Ensiksikin teknologioista ja tekniikoista. Suosittelen, että käytätte teille tuttuja tekniikoita suurimmassa osassa työtänne, tämä mahdollistaa nopean ja toimivan tuotoksen, joka valmistuu ainakin suurimmaksi osaksi jo tapahtuman aikana. Tiimille tuntemattomia teknologioita kannattaa ottaa vain muutama, joita sitten tutkitaan ja testataan jo ennen tapahtumaa.
  2. Toiseksi markkinointi ja dokumentointi. Tärkein osuus, niin hyvässä asiakas projektissa, kuin voittavassa Hackathon tiimissä on dokumentointi ja asiakkaalle idean kommunikointi. Hackathon tapahtumissa usein vain aika määrittelee sen miten paljon voidaan pistää tykkejä kunnon markkinointiin ja viestin edustamiseen, siksi olisi erittäin tärkeää yhden tiimin jäsenen keskittyä viestin suunnitteluun ja toteutukseen.
  3. Kolmas, mutta ehdottomasti tärkein pointti, on pitää hauskaa ja oppia jokaisesta pienestäkin virheestä tai odottamattomasta käänteestä projektin osalta. Hyvin usein tämän kaltaisiin tapahtumiin tulee ns. “Suorittaja-tiimi”, jonka pääasiallinen tavoite on saada voitto ja murehtia muista asioista, sitten tapahtuman jälkeen. Harvoin nämä tiimit voittavat, sillä ajatukset hyvin usein pyörivät vanhojen “hyväksi”-todettujen ratkaisujen ympärillä, eikä asiakas välttämättä ole etsimässä niitä vanhoja ratkaisuja vaan pussillisen uusia.

Projektimme tuotos ja käytetyt teknologiat

Teknologia ja tekniikat, osuuden sanoisin meidän tiimissämme onnistuneen erittäin hyvin. Meille Python ja JavaScript ovat erittäin tuttuja kieliä, sekä niiden avulla datan käsittely ja esittely olivat helppoja nakkeja, mutta tietysti suurin osa työstä tehtiin näiden teknologioiden päälle, joten niiden pyörittelyyn varattiin aikaa.

Meille tuntemattomampi osuus oli Arduino- ja C++ -ohjelmointi, mutta niistä taas minulla oli jo jonkin verran kokemusta, joten hoidin sen puolen työstämme. Markkinointi ja dokumentointi osuus, oli meidän tiimimme heikkous. Ei niinkään ettemme olisi niitä tehneet, mutta tiimin koko ja aikataulut, eivät antaneet periksi sen vertaa, että kunnon esitelmää olisi saatu luonnehdittua tuomariston esitystä varten. Tämä harmittaa itseäni erityisesti, sillä aikaisemmissa samankaltaisissa tapahtumissa olen korostanut esitelmöinnin tärkeyttä, mutta Hackathon tapahtumien luonne ei anna tarpeeksi aikaa, jotta jokainen aspekti työstä olisi varmasti valmis tulosten esitelmöinti vaiheessa.

Jatkossa otan itse opiksi, sekä varaan aikaa omasta työstäni esityksen hiomiseen. Kolmas aspekti ainakin omasta mielestäni onnistui tiimiltä erinomaisesti! Olimme sopivasti uusien aspektien kanssa tekemisissä. Omasta mielestäni koko tapahtuman ajan oli kunnon tekemisen meininki. Pidin myös erityisesti Miilin ja Jukan kanssa työskentelystä, osaamisemme sivusivat sopivasti toistemme osaamisia, joten keskustelu projektista, etenemiseen tarvittavista asioista ja työn kulusta oli helppoa ja mukavaa. Päällekkäinen, toisiaan täydentävä osaaminen oli vahvuutemme!

Vielä pari sanaa tuotoksestamme. Codenton – ja CityKettujen – it-arkkitehti Jukka Purma luonnehti projektiamme seuraavanlaisesti:

“Kalliita työkoneita käyttävissä yrityksissä sensoreiden mahdollistamaa digitalisaatiota (mennee IoT:n alle) ei kannata tehdä projekteissa tai isoissa harppauksissa: täytyy kehittää toimintamenetelmät, joilla varikot, IT, hallinto, työntekijät ja ‘älykkäät järjestelmät’ kaikki *sietävät* sen, että sensorit muuttuvat, katoavat, vaihdetaan toisenlaiseksi, lisätään ad hoc -tarpeeseen ym. Nopean muutoksen kausi tällä saralla tulee jatkumaan vielä seuraavat kymmenen vuotta, mutta työkoneita ei kannata uusia sen ehdoilla: pitää olla tottumus ja käytännöt kuinka ‘lisätä älyä’ vanhoihin koneisiin.

Menetelmien suunnittelu, koodaaminen tai kiveen hakkaaminen olisi kuin DevOps, mutta työalue on isompi: pitää voida sanoa johdolle että vain käyttämällä näitä menetelmiä, voitte hyötyä näistä uusista tietokanavista, IT-porukalle että on päästettävä tällaista tietoa sisään ja ulos, ja juteltava työntekijöiden kanssa missä on pullonkauloja joissa IoT voisi auttaa. Käytännössä tämä olisi vaativa työrooli monipuoliselle osaajalle, mutta niin kauan kuin sellaista tehtävää ei ole eikä täyttä ymmärrystä miten sen roolin täyttäjään pitäisi suhtautua, se on parempi toteuttaa konsulttien avulla: monta henkilöä yhdistää osaamisensa ja keskittyy joksikin aikaa ratkomaan tuota ongelmaketjua, tavoitteena luoda alustavat (turvalliset) käytännöt joita sitten joku asiakasyrityksestä nousee jatkamaan.”

 

IndustryHackin järjestämään Street Reboot -tapahtumaan osallistuneet CityKetut ovat:

Turo Mikkonen: “Tiimini kanssa tekeminen oli erityisen palkitsevaa näiden ihmisten kanssa ja pidin tästä kunnon tekemisen meiningistä”

Jukka Purma: “Tekeminen oli hauskaa ja jännää, enemmän alamäkijuoksua kuin maratonia: koska tahansa saattoi askelvalinta osoittautua vääräksi ja homma mennä turvalleen, mutta selvittiin ehjänä maaliin suunnilleen sitä reittiä mitä lähdettiin yrittämään.“

Miili Halkka: “Kokonaisuutena hackahton oli hieno kokemus, oman tiimin mutkaton toiminta, muiden tiimien tuotoksien näkeminen ja verkostoituminen monenlaisten osaajien kanssa antoi elämyksen, jonka kaltaista normaalissa työprojektissa on mahdoton saavuttaa muutamassa päivässä. Nopea palaute tehdystä työstä palkitsee aina.”

Codenton CityKettujen tuotokseen voi tutustua Githubissa: https://github.com/codento/snowplow_sense

Lisätietoja hankkeesta myös täällä:
https://6aika.fi/in-english/
http://rebootthecity.fi/

Sociocracy 3.0 tuo välineitä yhteiseen päätöksentekoon

Sociocracy 3.0 on James Priestin ja Bernhard Bockelbrinkin muotoilema kokoelma sosiokratiasta sekä ketterästä ja leanistä perinteestä nousevia käytäntöjä. Sociocracy 3.0 tai suomeksi Sosiokratia 3.0 – ja kavereiden kesken S3 – tähtää tasa-arvoiseen organisaatioon, joka keskittyy yhdessä päättämään ja tekemään sen, mikä on kulloinkin organisaatiolle ja sen tavoitteille oleellista.

Nostan tässä blogipostauksessa esiin erityisesti Sosiokratia 3.0:n päätöksentekokäytäntöjä. Päätöksenteon lisäksi S3 sisältää työn tekemistä ja organisoitumista koskevia käytäntöjä, jotka muistuttavat läheisesti yleisesti käytössä olevia leanejä ja ketteriä käytäntöjä.

Sociocracy 3.0 – arvot

Sosiokratia 3.0 perustuu seitsemään keskeiseen arvoon:  

  1. Suostumus (consent) tarkoittaa, että kaikki päätöksenteossa mukana olevat ajattelevat, että päätös on riittävän turvallinen toteutettavaksi.
  2. Tasapainolla (equivalence) viitataan siihen, että päätöksiä ovat tekemässä ihmiset joihin ne vaikuttavat.
  3. Vastuullisuus (accountability) tarkoittaa vastuun kantamista niistä tehtävistä, jotka kukin on ottanut tehdäkseen.
  4. Jatkuvalla kehityksellä (continuous improvement) etsitään jatkuvasti tapoja fokusoida enemmän energiasta siihen, mikä on tärkeää.
  5. Läpinäkyvyydellä (transparency) varmistetaan, että ihmisillä on aina käytössä tieto, jota he työhön ja päätöksentekoon tarvitsevat.
  6. Teho ja vaikuttavuus (effectiveness) vaatii turhasta luopumista ja olennaiseen keskittymistä.
  7. Empiirisyydellä (empiricism) tarkoitetaan ympäristön jatkuvaa havainnointia ja indikaattoreiden asettamista onnistumiselle.  

Perustana taidokas osallistuminen

Sosiokratia 3.0 nojaa vahvasti sen oletuksen varaan, että työyhteisössä kaikki muut ovat yhtä luotettavia päätöksentekijöitä kuin minä itse. Tämä tekee menetelmästä ainakin asiantuntijaorganisaatiossa jossain määrin radikaalin.

Niinpä Sosiokratia 3.0:n tärkeä peruskivi on taidokas osallistuminen (artful participation). Kysymys, jonka pohjalta kaikkien organisaation jäsenten oletetaan S3:ssa toimivan on:

Onko tämänhetkinen toimintani paras panos, jonka voin antaa tämän ryhmätyön tehokkuuteen?

Käytännössä S3:n mukaan toimivat ihmiset tasapainoilevat kahden ulottuvuuden välillä: Mitä minä tarvitsen tässä tilanteessa? Mikä on minua kohtaan oikein? Ja toisaalta: Mitä se mitä olemme tekemässä tarvitsee? Miten voin parhaiten hyödyttää tätä yhteistyötä?

 

Jännitteistä pyrkimyksiin eli drivereihin

Sosiokratia 3.0 ajattelee, että kaikki uusi syntyy jännitteistä. Joku huomaa, että tarvitaan jotakin uutta, tai että sen mikä oli eilen hyvä ei toimi enää. Tämä aiheuttaa monesti epämukavuutta ja ristiriitojakin.

Jotta jännitteistä syntyisi helpommin rakentavaa toimintaa, S3 neuvoo muotoilemaan ne drivereiksi: Mitä tapahtuu? Mitä siksi tarvitaan?

Näiden kysymysten pohjalta driverin ratkaisemiseksi voidaan tehdä ehdotus, jota taas voidaan kokeilla. Ja näin saadaan konkreettisia tuloksia, joihin jatkokeskustelun voi kytkeä.

Sosiokratia 3.0 olettaa myös, että tämäntyyppisiä drivereita arvioidaan jatkuvasti sekä yksilöiden ajattelussa että yhteisessä keskustelussa. Sillä tavoin varmistetaan jatkuvasti, että organisaatio toimii kaikkein tärkeimpien asioiden eteen eikä hukkaa aikaa epäolennaisuuksiin.

 

Piiri, rooli ja sopimus

Sosiokratia 3.0:n ratkaisu esille nousseeseen jännitteeseen ja sitä kautta syntyneeseen driveriin on aivan ensimmäkseksi toiminta. Jos asia on sellainen, jonka pystyy tekemään nopeasti, kysäise niiltä joita asia koskee, tee tarvittavat päätökset ja hoida homma pois alta. Jos asia vaatii paneutuneempaa työstämistä, ratkaisuina toimivat piiri, rooli tai sopimus.

Piiri on sosiokratia 3.0:ssa organisoitumisen perusyksikkö. Piirit muodostuvat ratkomaan drivereita ja niillä on päätöksenteko-oikeus driverin sisällä, kunhan ne kuulevat asiassa myös niitä, joihin asia vaikuttaa. Piirit syntyvät ja purkautuvat drivereiden mukana.

Driver voidaan antaa ratkaistavaksi myös jonkin roolin haltijalle, tai sen pohjalta voidaan muodostaa uusi sopimus siitä miten toimitaan.

Suostumuspäätöksenteko

Päätöksenteossa sosiokratia 3.0 käyttää paljon aikaa ongelman määrittelemiseen ennen kuin lähdetään edes ideoimaan ratkaisuja. Ideana tässä on ehkäistä hätäisiä johtopäätöksiä ja sitä myötä energian suuntautumista vääriin paikkoihin.

Tärkeillä päätöksenteon hetkillä kuullaan jokaista piirin jäsentä – vähintään visuaalisesti kokouskäsimerkeillä, joilla osallistuja kertoo suostumuksensa ehdotukseen tai vaihtoehtoisesti sen, että hänellä on huoli tai mahdollisesti vastalause.

Jotta päätöksiä kuitenkin syntyisi, sosiokratia 3.0:ssa pyritään huolellisesti erottamaan aidot vastalauseet ja pelkät huolenaiheet toisistaan. Vastalauseen muodostaa vasta se, jos joku kokee ehdotuksen kanssa etenemisen vaaralliseksi pyrkimyksen tai organisaation kannalta. Kaikki vähäisemmät pohdinnat luokitellaan huoliksi. Sekä vastalauseet että huolenaiheet ratkaistaan useimmiten muokkaamalla ehdotusta niiden pohjalta, jonka jälkeen katsotaan uudelleen, päästäänkö etenemään.

Tätä prosessia kutsutaan yhteensä suostumuspäätöksenteoksi (consent decision making).

 

Sociocracy 3.0:n käyttöönotto

S3 suosittelee, että Sociocracy 3.0 -työkaluja otetaan käyttöön sitä mukaa kuin organisaation tavoitteet ja konteksti niin vaatii. Ideana ei siis ole rymäyttää uutta järjestelmää käyttöön kerralla, vaan ammentaa käytäntöjä sinne, missä homma on pahiten rikki tai toimintatavat puuttuvat.

Karoliina Luoto

Presentaatio tämän blogin sisällöistä löytyy myös Slideshare-palvelusta: Sosiokratia 3.0 Codentossa.

Tämä blogaus on keskittynyt S3:n niihin päätöksentekokäytäntöihin, jotka ovat olleet Codentossa relevanteimpia. Koko S3-menetelmän tarkka kuvaus löytyy Sociocracy 3.0 -verkkosivuilta http://sociocracy30.org.

Lue myös toinen kirjoitukseni sosiokratia-aiheesta, avaan käytännön kokemuksiamme

 

Mikäli haluat apua S3-päätöksenteon välineiden käyttöönottoon omassa organisaatiossasi, Codenton konsultit ovat mielellään käytettävissäsi. Ole ystävällisesti yhteydessä joko allekirjoittaneeseen, karoliina.luoto(a)codento.com tai kollegaani miika.kuha(a)codento.com.

 

Kuvat © 2014-2017 by Bernhard Bockelbrink and James Priest (käyttöoikeus CC SA 4.0 -lisenssillä).

Lean-projektikartta – miten saan ensi vuoden projekteihin järkeä?

Budjetointirumbaan liittyy paljon kimurantteja haasteita ja vankkoja perinteitä: näin on tehty ennenkin -mallista rahanjako pärstäkertoimen mukaan -malliin. Perinteiset mallit voivat olla epäreiluja ja ne eivät aina kannusta osastoja etsimään optimaalista tasapainoa uuden kehittämisen ja vanhan ylläpitäminen välille.

Käytän termiä lean-budjetointi, mutta oikeastaan malli soveltuu kaikille – vaikka et tuntisi leaniä omaksesi, tämä on fiksu tapa tehdä budjetointia.

Perinteisellä tavalla budjetointi on myös loukku – siinä budjetti rakentaa raja-aidat, jonka takaa voi olla vaikea vapautua. Fiksumpi tapa budjetoida vapauttaa ja tekee todellisen kehittämisen ja mullistukset mahdolliseksi.

Ensi vuosi suunnitellaan todellisuudessa jo budjettia laadittaessa ja Codenton lean-projektikartta on työkalu, jolla teet tilaa niille parannuksille, joita organisaatiosi tarvitsee.

Minkätasoinen lean-budjetointi sopii teille?

Organisaatioilla on erilaisia valmiuksia ohjata toimintaansa ja kehitystä vauhdilla muuttuvassa toimintaympäristössä. Tätä kyvykkyyttä jatkuvaan kehitykseen kuvataan myös lean-kypsyystasoksi – eli tasoksi, jolla organisaatio on menossa kohti nopeampaa reagointikykyä, läpinäkyvyyttä ja kokeilukulttuuria. Startupin ketteryysihanne on luonnollisesti eri kuin suuren korporaation tai julkishallinnon organisaation, ja niin pitääkin olla.

Monesti käytännön kehittämismalli on jonkinlainen yhdistelmä toisaalta vuosikellon mukaan pyörivää päätöksentekoa ja budjetointia, toisaalta tiheämpi syklistä, muuttuvampaa ja läpinäkyvämpää kehittämistyötä.

Ketteryyden saavutetusta tasosta riippumatta asettaa budjettikehyksen kehitystyölle. Jos päädytään ultraketterään toimintamalliin, käytössä on täysin lean budjetointi. Siinä koko toiminta on havainnoitavissa mittareiden avulla, ja panoksia pystytään lyhyissä sykleissä laittamaan niihin kohtiin systeemiä, jotka juuri nyt ovat merkittäviä tavoitteiden saavuttamisen hidasteita tai mahdollistajia.

Perinteisemmissä päätöksentekomalleissa leanissä budjetoinnissa lähdetään usein liikkeelle varmistamalla, että budjetointi mahdollistaa kehityksen kohti läpinäkyvyyttä ja jatkuvaa kehitystä, ja että budjetissa löytyy tilaa tehdä kokeiluja.

Kokeilut ovat usein pitkäjänteiselle menestykselle elintärkeitä – ja monesti ajatellaankin, että budjetista pitäisi käyttää jopa 25 % mullistavaan kehittämiseen.

Lean-projektikartta tukenasi

Laatimamme lean-projektikartta on konkreettinen leanin budjetoinnin ensiaskel. Sillä varmistat, että lean-kehityksen pohja ja kokeilut tulevat budjetoinnissa – ja sen myötä projekteissa – huomioiduiksi.

Lean-projektikartassa tasapainotetaan asiakkaan, ympäristön ja toiminnan kehittämisen osa-alueet. Ja on tärkeää, että jokaisella osa-alueella haetaan oikea fokus strategisen kehittämisen, ylläpidon ja kilpailijoita nopeampaan uudistumiseen vaadittavien mullistavien kehityshankkeiden kautta.

Lataa lean-projektikartta täältä >>