S3-kokemuksia belgialaisessa nunnaluostarissa

Ensimmäinen Sociocracy 3.0 Practitioner Course Level 2 -koulutus järjestettiin syyskuussa Belgiassa, alkuperäisten Sosiokratia 3.0 -mallin kehittäjien järjestämänä. Codentolaisille Anu Takalalle ja Karoliina Luodolle jatkotason koulutus tarjosi paitsi kauniita luostarimaisemia keskellä belgialaista maaseutua, myös välineitä S3-päätöksenteon fasilitointiin sekä tukun uusia oivalluksia. Tarjolla iltamietinnöille oli myös olutta, luostarissahan sitä oltiin.

Kaikilla koulutukseen osallistuneilla oli jo kokemusta mallin toteuttamisesta omissa organisaatioissaan, joten pelkän Sosiokratia 3.0:en liittyvien perustermien ja käytänteiden kertaamisen sijaan päästiin vaihtamaan aitoja käytännön kokemuksia ja pohtimaan ratkaisuja koettuihin haasteisiin.

Sosiokratia 3.0 -mallin alunperin kehittäneet Bernhard Bockelbrink ja James Priest olivat mukana koulutuksessa. Oli todella hienoa päästä heijastelemaan ajatuksia molempien mallin kehittäjien kanssa – perustajista Bockelbrink ei itse kouluta mallia, joten hänen osallistumisensa ylipäänsä oli harvinaista herkkua. Lisäksi kolmantena kouluttajana toimi niin ikään mallin kehittämisestä vastuussa oleva Liliana David.

Kokemuksien jakaminen tärkeä anti

Koulutukseen osallistui paljon Lean- & ketterien menetelmien parissa yleisestikin työskenteleviä konsultteja ja asiantuntijoita. Vaikka nämä menetelmät ja itseohjautuvuus ovat usein nimenomaan ohjelmistoprojektien keskiössä, koulutuksen osallistujissa ei ollut pelkästään ohjelmistoalan yrityksiä, vaan joukkoon mahtui monipuolinen kattaus eri toimialojen organisaatioita.

Kansainvälisen osallistujakunnan joukossa oli ohjelmistokehityskonkarien ja Agile-konsulttien lisäksi mm. terveydenhoitoalan edustajia sekä asukasyhdistysten kanssa työskenteleviä toimijoita. Ja kaikilla oli kuitenkin yhteinen tarve mahdollistaa osallistavaa päätöksentekoa sekä viedä toimijoita itseohjautuvampaan suuntaan.

Codentolla S3-mallia on harjoiteltu kohta jo pari vuotta, ja muiden organisaatioiden kokemusten kanssa löytyi paljonkin yhteneväisyyksiä. Workshopeissa vaihdettiin ajatuksia ja käytännön esimerkkejä erilaisten organisaatioiden Sosiokratia 3.0 -hankkeista, ja pohdittiin ratkaisuja kohtiin, joissa kompastelua tapahtuu. Lisäksi mietittiin miten vaikkapa päätöksentekoa kannattaisi fasilitoida, jotta S3-mallin peruselementeistä mm. suostumuspohjaisuus, läpinäkyvyys, jatkuva parantaminen ja tehokkuus toteutuisivat – oli kyse sitten espanjalaisesta, venäläisen tai hollantilaisesta työkulttuurista muilta osin.

S3 ei ole pelkkiä ulkoisia sääntöjä

Monet osallistujista olivat kokeneet S3-termistön hankalahkoksi omaksua ja päätöksenteon erilaiset käytännöt haasteelliseksi selittää yleisöille, jotka ovat tottuneet perinteisen mallin kokouskulttuuriin ja  valta-asetelmiin. Codentollakin ensimmäiset S3-mallin mukaiset palaverit kuluivat monesti esimerkiksi sen pohdintaan, missä järjestyksessä palaveriin kuuluva check in -kierros tulisi tehdä. Toisinaan toki kuuluu vieläkin huokauksia, kun työtuolien hankintaan paneudutaan S3-mallisella pieteetillä.

Koulutuksen suurimmaksi anniksi nousikin oivallus siitä, että oikeaoppisten sanaston ja S3-käytäntöjen sijaan tärkeämpää on ymmärtää, miksi mallissa toimitaan sosiokratian määrittelemällä eikä ns. perinteisellä tavalla. Termien oikeellisuuden pohtimisen sijaan olisi olennaisempaa miettiä, mikä on se ongelma tai jännite päätöstarpeen taustalla, ja miksi esimerkiksi ollaan keräännytty tietyn päätöksen ääreen ja että asiaa ovat ratkaisemassa ne, joita asia koskee.

Käytännön harjoitustakin toki tarvitaan varsinkin tilanteessa, missä uusien rekryjen kautta saapuu väkeä, jotka ottavat vasta ensiaskeliaan mallin parissa. Kun S3 on ajettu osaksi organisaation normaalia arkea, on myös helpompi keskittyä niihin motiiveihin ja voimiin, joiden takia päätöksentekoa halutaan ylipäänsä tehdä S3-mallilla, sosiokratian meta-tasoon.

Sosiokraattisessa päätöksenteossa kaistaa halutaan erityisesti käyttää päätöksiin ajavien jännitteiden ja drivereiden tunnistamiseen. Käytännön fasilitoinnissa se tarkoittaa esimerkiksi sitä, että osataan tunnistaa, milloin asia on sellainen, että se oikeasti vaatii yhteistä päätöksentekoa ja milloin asian voi vain tehdä alta pois. Sama asia käytännössä: toimiston käytännönjärjestelyjen osalta on olennaista, että kaikilla on mahdollisuus olla mukana päätöksenteossa, mutta sen puhelimen varavirtalähteen voi vaikka hankkia ihan itse, sen kummemmin lupia kyselemättä. Mukava työkaveri toki kysyy siihen päälle, josko joku muukin tarvitsee samanlaista, niin hoituu sitten kerralla pelivermeet työkaverillekin.

S3 vaatii myös päätöksenteon perustyötä

Mallin omaksumisen ja toiminnan kannalta on erityisen tärkeää, että ne, jotka ovat organisaatiossa perehtyneet tarkemmin Sosiokratia 3.0 -malliin, vievät tietoa eteenpäin ja auttavat ihmisiä siinä kohtaa kun tukea kaivataan. Toinen koulutuksen tuoma tärkeä oivallus oli se, että S3-mallin päätöksenteko ei kaikesta toimivuudestaan huolimatta pelasta normaaleilta hyvän päätöksenteon arkiruutineilta.

Päätösten ja asioiden valmistelu on edelleen ja ehkä jopa entistäkin tärkeämpää. Kun yhteinen päätös tehdään esim. 40 ihmisen voimin, keskustelussa asiassa pitäytyminen on olennaista ihan puhtaan ajankäytön vinkkelistä. Jännitteiden havaitsemiseen ja analysointiin, drivereiden luontiin sekä haasteiden ratkaisuehdotuksiin pitää käyttää valmistelussa aikaa, jotta malli palvelisi tarkoitustaan ja ihmiset pääsisivät jo hyvin varhaisessa vaiheessa päätöksentekoon mukaan.

Harjoituksen tuloksena hyvin valmisteltu sosiokratian mukainen päätöksenteko voi sitten tapahtua nopeastikin. Tästä esimerkkinä vaikkapa eräs Codenton viikkopalaveri: normaalien agenda-asioiden (12 piirin kuulumiset) lisäksi päätettiin yhteisesti sekä yrityksen hallituksen uudesta organisoitumisesta, seuraavan vuoden kasvutavoitteista että Codenton mentorointimallista. Kestoa tällä koko henkilöstön palaverilla oli 49 minuuttia!

Sosiokratia 3.0 -mallia kehitetään edelleen niin kokemusten kuin organisaatioiden tarpeidenkin pohjalta. Koulutuksessa tuli uusina S3-asioina paljon sellaista, jonka avulla myös isommat organisaatiot pystyvät hyödyntämään mallia päätöksenteon välineenä. Näissä ollaan usein totuttu hierarkisiin rutiineihin, jolloin hyppääminen S3-malliin voi olla haasteellista – mutta myös varsin vapauttava kokemus kun kaikki, joilla on asioihin annettavaa ja joita päätös koskee pääsevät vaikuttamaan päätöksiin.

Koulutuksen jälkeen Codenton S3-arki jatkuu entistä turvallisemmissa puitteissa. Anu ja Karo pyrkivät osaltaan varmistamaan että ne Sosiokratia 3.0 -käytännöt, joita Codentolla käytetään, eivät lähde ilman syytä irtoamaan kehittäjien tarkoittamasta suunnasta vaan pysyvät ajan tasalla ja elinvoimaisena. Ja ensisijaisesti palvelemassa tarvetta organisoitua ihmisläheisten perusperiaatteidensa kautta.

 

Katso Codenton avoimet työpaikat

 

Teal, S3 ja itseohjautuvuus uuden työn malleina

Lajissaan ensimmäinen Woodstock of Teal -tapahtuma keräsi itseohjautuvuus- ja teal-ajattelusta kiinnostuneet kehittämisen edelläkävijät koolle – ja Codentolla oli ilo toimia yhtenä tapahtuman kummeista. IT-arkkitehtimme Joonas Iivonen kirjoittaa tapahtuman annista. Jos teal, sosiokratia 3.0 ja muut viitekehykset kiinnostavat, lue ihmeessä lisää missä Suomessa mennään näiden asioiden kanssa.

Teal-ajattelu leviää työelämän muutoksen haasteita pohtivien joukossa. Teal Suomi -osuuskunnan järjestämä open space -muotoinen Woodstock of Teal -tapahtuma veti paikalle sadan hengen edelläkävijäjoukon.

Joukossa oli niin noviiseja, kokeilijoita, teal-pessimistejä kuin asiantuntijoita monenlaisista suomalaisista organisaatioista ja muutamia ulkomaalaisia osaajiakin. Ensimmäinen suurempi avoin teal-tapahtuma onnistui hienosti, keskustelu oli hedelmällistä ja avointa ja yhdessä päätimme järjestää vastaavan tilaisuuden ensi vuonna samaan aikaan.

Lukuisten aiheiden joukosta keskityimme kuitenkin paljon transformaatioon kohti tealia organisaatiota sekä siihen kuinka itseohjautuvuus skaalautuu isoihin organisaatioihin.

Noviiseja ei toki unohdettu, vaan useammassakin sessiossa käsiteltiin tealin perusteita ja jargonia. Toisaalta puhuttiin myös henkilöstöhallinnon prosesseista, palkitsemisesta ja rahan jakautumisesta teal-organisaatioissa ja -verkostoissa.

Useat organisaatiot jakoivat kokemuksiaan erilaisista toimintamalleista kuten Sosiokratia 3.0:sta ja Holocracystä.

 

Teal eri kokoisissa organisaatiossa

Organisaatioiden transformaatio kohti tealia puhututti paljon ja keskustelu herätti hyviä ajatuksia. Pienemmissä, muutaman kymmenen hengen organisaatioissa muutoksia voidaan helposti tehdä kattavasti ja kaikki osallistaen, mutta isommissa yrityksissä on usein parempi hakea kokemuksia rajoitetummassa ympäristössä, mikä voi olla yksittäinen yksikkö, sisäinen startup tai muu selvästi rajattavissa oleva organisaatio.

Joka tapauksessa muutoksen ja itseohjautuvuuden rajat kannattaa määritellä selvästi, mikä luo turvallisuuden tunnetta henkilöstölle muutoksen sisällä. Yhdessä todettiin myös, että kannattaa edetä pienin askelin ja kokeilujen ja niistä oppimisen kautta.

Kuten kaikessa muutoksessa henkilöstöä kannattaa tukea muutoksessa. Tukena tärkeää on itse filosofian ja tarkoituksen opettaminen, mutta myös itseorganisoitumiselle tärkeiden taitojen kuten reflektion, palautteen antamisen ja vastaanottamisen sekä itsetuntemuksen kouluttaminen.

Joonas Iivonen kertoo Codenton sosiokratia 3.0 (S3) -kokemuksista.

Sosiokraattisten menetelmien kokemuksia

Olemme Codentolla käyttäneet Sosiokratia 3.0 -mallia nyt noin puolitoista vuotta ja kerroimme tästä itseohjautumisen mallista ja kokemuksistamme tapahtumassa. Schneider Electricin osallistujat puolestaan kertoivat heidän kokemuksistaan Holocracyn soveltamisesta Suomen yksikössä.

Totesimme havaintojemme olevan pitkälti samansuuntaisia. Kaikkia toimintamalleja pitää soveltaa organisaatiolle sopiviksi, mutta soveltamisessa kannattaa olla varovainen ja varmistua, että on todella ymmärtänyt mallin ajatuksen ja tarkoituksen ennen kuin menee tekemään siihen merkittäviä muutoksia.

Organisaation on myös helppo palata takaisin vanhoihin tuttuihin käytäntöihin. Uusien tapojen ylläpito tarvitsee energiaa ja sitä tuomaan sinnikkäitä ja innostuneita toimijoita. Näitä toimijoita kannattaa olla niin johdosta kuin myös asiantuntijoista ja työntekijöistä, jotta vaikutus on kattava.

Oli erittäin antoisaa kuulla kokemuksia ja esimerkkejä eri organisaatioista ja myös toisilta toimialoilta.

Sosiokratia vs Teal

Vaikka tilaisuudessa puhuttiinkin paljon erilaisista sosiokratian toteuttamisen malleista sekä muista tavoista organisoida itseohjautuva organisaatio kannattaa huomata, että tealiä organisaatiota ei välttämättä erota vihreästä ulkoisten toimintatapojen perusteella.

Sosiokratia ei ole yhtä kuin teal ja teal ei ole yhtä kuin sosiokratia. Menetelmät eivät takaa sitä, että toiminta on evolutiiviseen tarkoitukseen perustuvaa ja henkilöstö saa wholeness-tunteen. Tealissa organisaatiossa konflikteja tulee voida nostaa rakentavasti esille ja ratkaista, mikä vihreässä organisaatiossa voi olla hankalaa tai jopa mahdotonta.

Itseohjautuvuus ja palkitseminen

Tavoitteiden asettaminen ja palkitseminen ovat nousseet keskustelun aiheiksi itseohjautuvuutta soveltavissa organisaatioissa.

Henkilöstöprosessit, tavoitteiden asettaminen, palkka, palkitseminen ja bonukset olivat esillä useammassakin sessiossa. Yleisesti tunnustettiin avoimuuden olevan välttämätöntä näissäkin asioissa jotta itseohjautuvuus ja motivaatio pysyvät yllä.

Mukana olleet organisaatiot jakoivat näistäkin monenlaisia kiinnostavia esimerkkejä. Lopputulemana oli pitkälti se, että palkitsemismalleja voidaan aina pelata. Useimmissa esimerkeissä oli käytössä jonkinlainen vertaisarviointi tai -palautejärjestelmä, missä työkaverit arvioivat toisiaan tai jopa koko tiimin suoriutumista ja osaamista.

Palautetta ja arviointia kannattaa tehdä usein, esimerkiksi puolen vuodenkin syklillä. Yrityksen taloudelliseen menestykseen perustuvat bonukset voidaan maksaa jopa kuukauden tasolla, millä luodaan jälleen lisää läpinäkyvyyttä ja suoraa palautetta toiminnan toiminnasta.

Woodstock of Tealin lopputuloksena

Näyttää vahvasti siltä, että Suomessa on useita organisaatioita, niin isoja kuin pieniä, jotka haluavat aidosti muuttaa toimintatapojaan ja siten vähintään suomalaista, jos ei jopa maailman laajuista, työympäristöä. Tapahtuma synnytti paljon positiivista ja jätti osallistujille varsin innostavan ja positiivisen tunnelatauksen. Teal-pessimistikin kertoi kääntyneensä positiiviselle puolelle.

Muutokseen tarvitaan rohkeutta ja taitoa. Mutta tukea niin rohkeuteen kuin taitoihin saa useilta erilaisilta toimijoilta kouluttajina, konsultteina ja coacheina.

-Joonas Iivonen

PS. Codento valmentaa paraikaa useampaa organisaatiota muutoksessa. Käymme myös kertomassa käyttämistämme itseohjautuvuuden malleista viikoittain. Jos kiinnostuit niin ota yhteys lean-valmentajaamme Miika Kuhaan, miika.kuha (at) codento.com / 040 5524552.  

 

Katso Codenton avoimet työpaikat

Miten itseohjautuvuus viedään yrityksessä totuttua pitemmälle?

 

”Useimmille firmoille on valtavasti hyötyä siitä, että työntekijät pääsevät suoraan vaikuttamaan. Se taas vaatii, että yrityksen johto uskaltaa antaa työntekijöilleen tilaa menestyä.”

Lausuin noin Tivi-lehden haastattelussa ja uskon siihen vahvasti. Johtajuus ei silti häviä mihinkään vaikka sen antaa levitä organisaatiossa entistä tasaisemmin ja lähemmäksi asiakasta.  

Codento on mukavasti kasvanut konsultointialan yritys, jonka hallitus joutui reilun 20 hengen yrityksen koossa miettimään, miten yritys tästä kasvatetaan yli 100 hengen kokoon kentässä, jossa sekä tekijöistä että asiakkaista kilpaillaan verisesti, mutta hymyssä suin.

Totuttu tapa olisi ollut väliportaan johdon luominen, mutta me päätimme siirtyä alkavasta hierarkkisesta mallista täysin toiseen suuntaan, itseohjautuvuuteen.

Vanhat tavat istuvat sitkeässä, mutta S3 hurmasi lopulta

Alku oli vaikeaa, hierarkiset toimintatavat ovat meillä kaikilla reflekseissä eikä uudelle mallille syntynyt tilaa kun päätökset tapahtuivat kuten ennenkin.

Etsimme vaihtoehtoja ja malleja ja toivoimme löytävämme “avoimen lähdekoodin” mallin, joka näyttäisi meille sopivalta, ja ehkä jopa laajempaa suosiota saavalta. Pienen etsinnän jälkeen löysimme S3 (tai virallisesti Sosiokratia 3.0) -mallin, joka tuo uudet työkalut yhteisölliseen päätöksentekoon.

Parin S3-koulutuskerran jälkeen jätimme vanhan taakse, lopetimme johtoryhmän ja siirsimme vastuut S3-tyyppisesti piireille, eli yhden teeman ympärillä tapaaville päätöksentekoelimille.

Päätös oli pelottava…monet meistä tietotyöläisistä ovat tottuneet tehottomuuteen ja päättämättömyyteen porukassa. Juuri tämän ratkaisemiseen S3 keskittyy, eli sen ytimessä ovat palaverikonventiot, jotka tuovat kaikille tilaa ja pitävät kovaäänisimmät paremmin kurissa.

Codentolaisia S3-valmennussessiossa.

Plussia ja miinuksia

Nopeampaa, parempaa päätöksentekoa. Yksi S3:n periaatteista, “Riittävän hyvä juuri nyt, kelpaa kokeiltavaksi” (englanniksi “Good enough for now, safe enough to try”), kajahti yhdessä jos toisessakin palaverissa ja alkukankeuden jälkeen päätöksiä on syntynyt nopeammin, tehokkaammin ja tarkemmin asiakkaiden tarpeet huomioon ottaen kuin koskaan aiemmin.

Kasvua ja rekrytoinnin onnistumisia. Yritys kasvoi viime vuonna 14 uudella osaajalla, nopeammin kuin koskaan Codenton historiassa. Muutoksen hinta oli kuitenkin kova; useampi kokenut konsultti ei ollut valmis tähän muutokseen ja valitsi lähteä talosta.  

Parempaa asiakaspalvelua ja -tuntemusta. Mitä enemmän olemme siirtäneet strategisten kokeilujen päätöksentekoa niille, jotka elävät etulinjassa asiakkaiden kanssa, sitä paremmin kokeilumme ovat menneet ja sitä paremmin projektimme luistavat. Tyytyväinen asiakas on paras mittari.

Kuvassa Codenton devaajat Miili, Jukka ja Turo. Turo Mikkonen (oik.) on myös uusi hallituksemme puheenjohtaja.

Ensimmäinen S3-hallitus

Hallitus tekee monenmoista yrityksessä; seuraa, valvoo, hoitaa lakisääteiset tehtävät ja hyväksyy strategian ja tärkeät muutokset toimintatavoissa. Hallitus on osakkeenomistajien ääni yritykseen.

Ensimmäisen täyden S3-vuoden jälkeen huomasimme, että itseohjautuvuuden ja hyvän ulkopuolisista koostuvan hallituksen välillä on jännite. S3-malli korostaa jännitteiden huomaamista, nimeämistä ja ratkomista.

Ratkoimme tätä jännitettä kirjaamalla hallituksen moninaiset roolit ja mietimme tarkkaan, miten ne voisivat parhaiten toteutua itseohjautuvassa yrityksessä. Onko hallitus edes tarpeen? Voiko ilman sellaista elää?

Hallitus onkin lakisääteisesti pakollinen, ja sen on oltava aktiivinen, mutta se voi olla aivan eri tavalla miehitetty kuin tavallisesti. Suuri osa entisestä hallitusroolista on nyt jakautunut erilaisille piireille, joista parhaat hoitavat jo vastuunsa selvästi paremmin kuin hallitus parhaina päivinäkään.

Mitä sitten oikeastaan päätimme tehdä?

  1. Olemme jakaneet kaiken jaettavissa olevan tiedon kaikille työntekijöille jo vuosien ajan.
  2. Hallitusvastuun voi jakaa helpommin kun kaikki tietävät jo kaiken, minkä haluavat tietää.
  3. Valitsimme työntekijöistä 1+1 hengen hallituksen.
  4. Hallituksen tärkeät seurantavastuut toteutuvat paremmin kuin koskaan ennen: konsulttiyrityksen sisältä näkee paremmin, miten yrityksessä menee ja missä riskit ovat.
  5. Virallisia hallituksen kokouksia tulee silloin, kun tarvitaan virallinen hallituksen päätös. Molemmat hallitusvastuussa olevat tekevät tuolloin yhteistyötä ja heille on saatavilla paras rahalla ostettava lainopillinen apu, tarvittaessa.
  6. Useimmat hallituspäätökset on vastuutettu Codenton viikkokokoukselle. Teemme yhdessä parempia päätöksiä kuin vain osa meistä – ja tämä koskee myös tärkeitä strategisia päätöksiä.
  7. Ulkopuolista näkemystä tuomaan kutsumme alojensa parhaita asiantuntijoita. He tuovat päätöksentekoon ulkopuolista näkemystä ja luovat tilaa pitkäjännitteiselle keskustelulle ja päätöksenteolle.  Olemme projektiorganisaatio ja uskomme projektien voimaan niin omassa työssämme kuin asiantuntijoiden neuvoissa.
  8. Kaikkein kimuranteimpia tilanteita varten olemme varautuneet pitämään ylimääräisiä yhtiökokouksia. Osakkeenomistajien ääni on hyvä käydä hakemassa suoraan silloin, kun oikea reitti ei ole selvä.

Olen aivan fiiliksissä. Päällimmäisinä innostus, kiitollisuus ja kasvava opinhalu. Opimme yhdessä joka päivä lisää.

Petri
Twitter @aukia

Katso Codenton avoimet työpaikat

DevOps tuo yrityksellesi strategista kilpailuetua

DevOps on siitä upea termi, että harvoin löytää sanaa, jolla on eri merkitys käytännössä kaikille. Yhdelle se tarkoittaa tiettyä valikoimaa työkaluista, joilla toimintaa tehdään. Toiselle taas sitä, että koodille ajetaan välittömästi muutosten jälkeen testit, joiden onnistuttua uusi versio softasta otetaan automaattisesti käyttöön yhdessä tai useammassa ympäristössä. Nämä näkemykset eivät ole vääriä, mutta mielestämme DevOps voi kuvata laajemminkin organisaatioiden toimintaa ja tuoda strategista kilpailuetua, jonka avulla yritys voi toimia vikkelämmin ja huomioida asiakkaidensa tarpeita nopeammalla syklillä.

CALMS – DevOps viidellä kirjaimella

The DevOps Handbookin kirjoittajanakin toiminut Jez Humble loi CALMS-käsitteen kirjan muiden kirjoittajien aiemmin luoman CALMS-akronyymin pohjalta. CALMS muodostuu sanoista Culture, Automation, Lean, Measurement ja Sharing. Mallissa ei mainita ensimmäistäkään palvelua, ohjelmistoa tai työkalua, vaan nämä ovat toteutuskysymyksiä. Vaikka esimerkiksi ohjelmistokehityksen ja tuotantoonviennin automatisointi tapahtuu usein muutamalla yleisesti käytetyllä työkalulla ja järjestelmällä (Ansible, Jenkins, Docker, Kubernetes jne.) on tärkeää, ettei toimintaa suunniteltaessa takerruta liiaksi tiettyyn ratkaisuun.

“Kuka haluaa antaa devaajille rootit?”

Kulttuuri, CALMSin C eli culture, tarkoittaa DevOpsissa jaetun vastuun kulttuuria, jonka myötä perinteiset raja-aidat ohjelmistokehityksen ja järjestelmien pyörityksen väliltä kaadetaan. Itselleni tämä osa DevOps-käsitettä tuntui aikanaan erityisen vastenmieliseltä. Sysadminina olin usein tilanteessa, jossa devaajat rikkoivat muutoksilla tuotantojärjestelmiä ja omana työnäni oli ongelmien korjauksen lisäksi vastaavien tapausten ennaltaehkäisy, käytännössä käyttöoikeuksien rajaaminen. Stabiiliutta korostettiin siis merkittävästi yli muutosten.

Vastuurajojen kaatuminen on kuitenkin muuttanut pelikenttää merkittävästi. Kun aiemmin kiisteltiin, pitäisikö kehittäjillä olla pääsy tuotantoon, puhutaan nyt siitä miksi ylläpitäjänkään pitäisi kirjautua sinne. Automatisointi on kääntänyt asian päälaelleen, jolloin tuotannon testauksesta ja pystyssä pysymisestä on tullut prosessiasia, ei yksittäisten ihmisten vastuualue.

“Mä teen tän aina uuden version tullessa.”

Automatisoinnista, joka on CALMSin A eli automation, puhutaan DevOpsissa usein turhaan vain tuotantoautomaationa (Continuous Integration & Deployment), vaikka se kuuluu olennaisena kaikkeen tekemiseen. Organisaatioista löytyy usein käsin tehtäviä rutiinihommia, jotka ovat jääneet jonkun vastuulle. Yleinen perustelu on, että hommassa ei mene kuin pari minuuttia, mutta päivittäin tehtävänä tähän alkaa kulua melkoisesti aikaa. Kiireessä voi myös sattua virheitä, joista seuraa huomattavasti lisää työtä.

Hyvä alku manuaalisen työn poistamiselle on kirjoittaa asia skriptiksi, jolloin samat asiat tapahtuvat riippumatta kuka sen ajaa. Paremmaksi tilanne menee, kun skriptin ajaminen kytketään suoraan siihen toimintoon, joka sitä edellyttää. Näin asia tapahtuu aina oikea-aikaisesti ja sovitun määrän kertoja.

“En mä osaa sanoa, milloin tää on valmis.”

Lean eli CALMSin L tuo tiimin tekemää työtä näkyväksi niin tiimille kuin sen ulkopuolellekin. Työn palastelu järkeviksi kokonaisuuksiksi ja siitä vielä yksittäisiksi kehitystehtäviksi tekee suuremmankin ominaisuuden kehityksen paremmin nähtäväksi – ja tilanne aukeaa nopealla vilkaisulla myös tiimin ulkopuolisille.

Leaniin voi liittyä myös asioiden tekeminen näkyväksi esimerkiksi palvelun omalla kojelaudalla, josta löytyy yhdellä vilkaisulla sekä metriikat että ongelmatilanteet. ChatOps-käsitteellä tarkoitetaan palvelussa tapahtuvien asioiden näyttämistä ja hallintaa erilaisten integraatioiden avulla. Mikäli firma toimii muutenkin Slackissä tai Flowdockissa on luonnollista, että myös järjestelmät raportoivat tekemisistään sinne.

“Valvomme, että palvelu vastaa.”

Monitorointi, CALMSin M eli measurement, on usein palvelun saavutettavuuden tarkkailua. Kun sivuston latauksessa kestää useampi sekunti tai se ei lataudu ollenkaan, lähetetään asiasta sähköposti tai tekstiviesti. Infrapuolella valvontaan kuuluu usein myös palvelinten saavutettavuus ja kuormitus, mutta useimmiten valvonta tapahtuu noin minuutin välein ja muutaman minuutin alhaallaolon jälkeen aiheutuu hälytys. Valvonta on tällöin pakostakin reaktiivista, ja ennakointi jää usein tekemättä.

DevOps tuo monitoroinnin seuraksi mittaamisen (instrumentation), joista voi yhdistettynä puhua havaittavuutena (observability). Havaittavuus korostaa nimenomaan järjestelmien toiminnan ymmärtämistä ja sen hallintaa erilaisilla mittaristoilla. Esim. API-rajapinnan virhemäärien tarkkailu on tärkeää, mutta virheen taustalta on hyvä nähdä myös syy, mistä virheet aiheutuvat. Palvelu voi olla täysin kunnossa, vaikka APIn pyynnöistä 50 % tyssäisi virheeseen, mikäli kyse on häirintäyrityksestä. Häirintä on syytä havaita, mutta siihen on osattava reagoida eri tavoin kuin palvelun rikkinäisyyteen.

“Eihän me voida kaikille kertoa, miten nää tehdään!”

CALMSin viimeinen kirjain S eli sharing sisältää tiedon jakamisen kehityksen ja ylläpidon välillä. Vaikka työtehtävät ja vastuut sekoittuvatkin, voi tietyn tiimin pääasiallinen työ edelleen liittyä ylläpitoon. Tässä kontekstissa on äärimmäisen tärkeää, että eri asioita tekevien tiimien välillä on avoin ja toimiva keskusteluyhteys, tapahtui tämä sitten toimistolla tai jotain viestintä käyttäen. Yllättävän moni asia lakkaa hajoamasta, kun kehittäjä pääsee näkemään oman koodinsa toimintaa tuotannossa.

Jakamisen käsitettä voidaan haluttaessa laajentaa myös oman firman ulkopuolelle. Esimerkiksi Suomen OpenStack -operaattorit juttelevat kuukausittain OpenStack Finland -ryhmän myötä erilaisista ongelmista ympäristöissään. Salaisuuksien varjelun ja verisen kilpailun sijaan ratkaisuja jakamalla voidaan saavuttaa etua kaikille.

CALMS on mainio lähtökohta yritykselle, joka hakee DevOpsista parannusta ja ketteryyttä toimintaansa. Vaikka DevOpsista puhuttaessa kannattaakin sivuuttaa teknologia hetkeksi, ei tätä toki voida käytännön sovellutuksissa unohtaa. Jakamisen opit pätevät myös teknologiavalintoihin eli työkaluista ja järjestelmistä kannattaa keskustella ja kysellä. Mikäli et oikein tiedä mistä aloittaisit, kannattaa kysyä asiasta vaikka meiltä!

 

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