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

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

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

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

GIS-analyysit

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

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

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

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

 

Minkä vuoksi kannattaa visualisoida tietoa kartan avulla?

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

 

Paikkatiedon sovelluskohteet

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

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

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

Smooth Sailing – Ahvenanmaan lauttaliikenteen optimoiminen paikkatietoteknologian avulla

Ahvenanmaalla oli huomattu, että saaristolautat seilasivat puolityhjinä. Oli selvinnyt, että varausten tiedonhallinta kaipasi uudenlaista ja tuoretta näkökulmaa. Codenton Team Kulho nappasi ykkössijan lauttaliikenteen optimointia teknologiaratkaisuin etsineessä hackathonissa.

Industryhack järjesti innovaatiokilpailun, jossa seitsemän ammattilaisjoukkuetta valittiin ratkomaan lauttojen tehokkaampaa hyödyntämistä muuttamatta kuitenkaan nykyisiä aikatauluja tai itse aluksia. Hackathon järjestettiin Maarianhaminassa. Tiimeille annettiin kaksi päivää ja täysin vapaat kädet sekä teknologiavalintojen että lähestymistapojen suhteen.

Codenton Team Kulhossa vaikutti kolme koodaavaa arkkitehtiä, Juuso Lehtinen, Eero Sirén ja Saara-Maija Pakarinen. Tiimin nimi Kulho juontuu kirjailija H.P. Lovecraftin Cthulhu -mytologiasta ja niihin liittyvistä kirjoista ja peleistä. Tiimin sisäisiä roolijakoja ei ollut, vaan teimme kaiken yhdessä hakemuksen laatimisesta ja ideoinnista itse toteutukseen ja visuaaliseen suunnitteluun asti.

 

Teknologia vaihtui lennosta

Oma lähtökohtamme oli Ahvenanmaalle saapuva turisti ja hänen tarpeensa käyttää saaristolauttoja. Paikan päällä juttelimme yhden laivan kapteenin sekä paikallisten lauttaliikenteen käyttäjien kanssa, ja saimme mukaan näin myös saariston asukkaiden näkökulman. Demoon nousivat tärkeimmiksi koetut haasteet eli palvelun käytettävyys, varausjono sekä reaaliaikaisen tiedon saatavuus.

Demosimme responsiivista ja intuitiivista karttapohjaista varausjärjestelmää, joka julkaistiin pilvipalvelussa. Lisäksi palvelu laski ja näytti reaaliaikaisen varaustilanteen matkustajille ja ajoneuvoille. Sovellus toteutettiin mobile first -designajattelua noudattaen moderneilla frontend-teknologioilla siten, että sen voisi helposti integroida nykyiseen taustapalveluun mahdollisimman pienin kustannuksin.

Testasimme hackathonin aikana kahta eri teknologiaa, joista valitsimme asiakkaan näkökulmasta parhaimman, eli sellaisen, jolla vältetään toimittajaloukku. Toteutuksemme pohja-ajatuksena toimi tavoite tuoda mahdollisimman paljon arvoa loppukäyttäjille mahdollisimman pienin kustannuksin.

 

Mikropalveluilla lisää toiminnallisuuksia

Demon toteutuksen ohessa myös ideoimme, kuinka vanhasta, tuotteeseen pohjaavasta taustapalvelusta puuttuvia toiminnollisuuksia voisi kehittää omina kokonaisuutta rikastavina mikropalveluinaan.

Tarpeen vaatiessa koko vanha järjestelmä olisi näin myös korvattavissa vähitellen pieninä palasina tätä strategiaa noudattaen. Tällöin välttäisimme myös kerralla täyden uudelleenkirjoittamisen tuomat riskit, ja pystyisimme takaamaan turvallisen siirtymän uuden modernimman mikropalveluarkkitehtuurin pariin.

Tämänkaltaisessa arkkitehtuurissa palaset ovat helposti korvattavissa, esimerkiksi jonkin toteutusteknologian vanhetessa, mikä tekee uudelleen kehittämisestä huomattavasti kustannustehokkaampaa perinteiseen monoliittiseen ratkaisuun verrattuna.

 

Pilotin kehittäminen jatkuu

Ahvenanmaan saariston asukkaat käyttävät lauttoja päivittäin ja lisäksi niillä on suuri merkitys alueen turismille. Oli todella mielenkiintoista päästä ratkomaan aitoa ja merkittävää ongelmaa, jolla voisi samalla auttaa ihmisiä. Saimme paljon positiivista palautetta ja erityisesti pidettiin siitä, että varauksia pystyi tekemään kartalla ja, että palvelu näytti lähes reaaliaikaiset varausasteet.

Hackahthonissa syntyi toimivaa ja olosuhteet huomioiden erittäin siistiä koodia, jota lähdemme pilotissa kehittämään eteenpäin. Pitäydymme siinä mallissa joka muodostui hackhathonin aikana. Suunnitteilla on jalostaa jo toteutettuja toiminnallisuuksia eli varauslomaketta ja karttaa sekä lisätä palveluun saariston asukkaille autojen varausjono ja lauttojen henkilökunnalle oma raporttinäkymä.

Kartalle toteteutetaan yksinkertainen reititys eli käyttäjä voi varata matkan mahdollisimman helposti ja palvelu ehdottaa sopivimman reitin ja aikataulun. Lisäksi hyödynnämme Codenton palvelumuotoilun ammattilaista, joka tekee palvelusta entistäkin selkeämmän. Panostamme mahdollisimman vaivattomaan ja miellyttävään käyttäjäkokemukseen.

 

Jatkokehitykseen Ahvenanmaan “reittiopas”

Tulevaisuudessa pilotin jälkeen toivomme pääsevämme toteuttamaan monimutkaisempaa reititystä, jossa matkoja voisi varata koko Ahvenanmaan alueella eri laiva- ja bussilinjojen yhdistelminä. Lisäksi lopulliseen palveluun liitettäisiin maksujärjestelmät.

Asiakas voisi ostaa bussiliput, laivaliput ja erilaisia kausikortteja sekä kaikkien näiden yhdistelmiä helposti samasta paikasta. Käyttöasteita seurattaisiin myös kaikilla linjoilla ja niitä voisivat hyödyntää kaikki järjestelmän käyttäjät.

Muita lisäominaisuuksia olisivat ajoneuvojen varausten optimoiminen, saaristolaisten omien paikkojen erikoisvarauksien lisääminen palveluun, edistyneemmät raportointinäkymät, ruuhkahuippujen varausten ohjaaminen muille vuorokauden ajoille ja autojen lastaamisen aputyökalu. Kaikissa vaiheissa aiomme hyödyntää talon sisäistä palvelumuotoiluosaamistamme ja investoida käyttäjäkokemukseen.

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

Miksi ketterät menetelmät kannattaa päivittää?

Tiedätkö mikä on vaikein este kehitystyössä oman organisaatiosi tiimeille tai päättäjille? Oletko kartalla siitä, miten teidän tiiminne ymmärtävät agilen ja Leanin käsitteet? Tunnetaanko teillä ajanmukaisia menetelmiä, kuten ketterän ja Leanin parhaita käytäntöjä yhdistävä Modern Agile? Niinpä.

Seuraavassa kuusi syytä siihen, miksi menetelmien päivittäminen kannattaa.

 

1 Oikeat esteet esille

Monesti johdolla tai tiiminvetäjillä on hyvä käsitys siitä millaista kehitystyön arjen pulmat ovat. Mutta kun menetelmäpäivityksen aluksi selvitetään kevyellä kyselyllä ja haastattelukierroksella ajankohtainen tilanne, käykin ilmi että käsitys on vanha tai siitä puuttuu keskeinen osa. Tiimit siis painivat päivittäin ongelmien kanssa, joista heidän työtään tukevat eivät tiedä.

Työn sujuvuutta ja tuloksia ei pysty parantamaan tietämättä, mitä todelliset pullonkaulat ovat. Huikeaan tulevaisuudentilaan ei voi päästä kuvittelemalla olevansa jo siellä. Realistinen käsitys tiimien kohtaamista esteistä auttaa ratkomaan oikeasti tärkeimpiä asioita, ja etsimään sitä kautta tehokkaasti lisätehoja kehitystyöhön.

 

2 Ketterän käsitteet samalle viivalle

Monesti kehitystiimien tilanne on, että kaikki tietävät _periaatteessa_ miten tiimin on sovittu toimivan – esim. Scrum-käytäntöjen mukaan. Ongelmana kuitenkin on, että monella tiimiläisellä on kulunut aikaa sertifikaattikurssista tai sitä ei edes tullut ikinä tehtyä. Niinpä tulee kynnys tarkistaa, mitä tuoteomistajan nyt pitikään tehdä tai miten meidän retrospektiiviemme kannattaisi mennä. Lopulta kaikki noudattavat vanhoja rituaaleja ymmärtämättä, mitä järkeä niissä juuri meille on.

Menetelmien päivittäminen antaa organisaatiolle tilaisuuden ottaa haltuun yhteisen käsitteistön samalta viivalta. Kun kaikki saavat olla mukana, ihmiset myös tietävät mitä toiset tietävät. Sitä kautta asioiden puheeksi ottamisen ja työn kehittämisen kynnys madaltuu.

 

3 Vaihtelevat käytännöt yhtenäisiksi

Toisinaan organisaatiossa voi olla melko yhtenevätkin kehitystyön menetelmät käytössä, mutta niitä on käytetty pitkään. Tällöin ne helposti alkavat elää eri tiimeissä omaa elämäänsä. Tämä on monessa suhteessa hyväkin asia, tiimikohtaista soveltamista tarvitaan. Kun vaihtelu lisääntyy, ongelmia kuitenkin alkaa helposti tulla tiimien välisen koordinoinnin tai yleisen läpinäkyvyyden tasolla.

Menetelmiä päivitettäessä pystytään päättämään se minimitaso, jota kaikilta organisaation tiimeiltä oletetaan yhteisen läpinäkyvyyden nimissä. Samalla tullaan synnyttäneeksi kehitystyön käytännöille oletusmalli, jonka uudet tiimit voivat ottaa käyttöön kehitystyötä aloittaessaan, eikä niiden tarvitse saman tien käyttää energiaa työtapojen muodostamiseen.

 

4 Jatkuvan parantamisen mahdollisuutta ei kannata hukata

Organisaatio, joka ei systemaattisesti paranna työtapojaan, on kuin autotehdas joka edelleen valmistaa mallia, joka menestyi mahtavasti 50-luvulla – sen aikaisilla työtavoilla. Ilman jatkuvaa parantamista menetetään mahdollisuuksia monella tasolla: opit asiakkaiden tarpeesta, oivallukset omien toimintatapojen ongelmista tai tehottomuuksista sekä tekijöiden takaraivosta löytyvät mahtavat ideat työtapojen parantamisesta.

Muun muassa Modern Agile -lähestymistapa menetelmien päivittämiseen varmistaa jatkuvan parantamisen vähintään kahdella tasolla. Se ohjaa panostamaan asiakkaalle tuotettavan jatkuvan arvon maksimointiin ja nopeisiin kokeiluihin.

 

5 Pullonkaula siirtyy, tiedätkö mihin?

Uusien menetelmien omaksuminen ei ole helppoa, ja parhaita tuloksia usein saadaan, kun organisaatio saa omaksua niitä pala kerrallaan. Esimerkiksi ensin muutama tiimi alkaa harjoitella ketteryyttä, sitten lisää tiimejä liittyy mukaan. Kohta huomataan tuotteiden välisen koordinoinnin tarve, josta syntyy uudenlainen portfoliojohtamistapa. Lopulta päätöksentekoa ja ihmisten johtamista aletaan tehdä leanisti. Muutos voi edetä myös päinvastoin.

Joka tapauksessa työtapojen kehittämiselle on tyypillistä, että organisaation oppiessa jatkuvan parantamisen pullonkaula siirtyy. Menetelmien päivittäminen on tapa pysytellä kärryillä tästä kehityksestä ja ottaa sen täysi potentiaali hyötykäyttöön. Megatransformaatioissa kuten SAFe-muutoksissa tällaista vaiheittaisuutta saadaan harvoin hyödynnettyä, mutta modulaarisemmat mallit kuten Modern Agile antavat siihen mahdollisuuden.

 

6 Heräävän kysynnän hyödyntäminen

Otollisin hetki tehdä muutosta on silloin, kun organisaatio tai sen osa on itse herännyt sen tarpeeseen. Kun tekijät itse pyytävät uusia välineitä, niiden myymiseen ei tarvitse käyttää energiaa vaan kaikki paukut voidaan laittaa tekijöiden valmentamiseen.

Menetelmien päivittäminen antaa loistavan tilaisuuden tällaisen muutoskysynnän luomiseen. Kun yhdessä tunnistetaan kehitystyön isoimmat haasteet ja ratkomaan niitä, muutokselle syntyy luonnollinen imu. Sen lähde on, että organisaatio saa lääkettä juuri niihin vaivoihin joihin kaipasikin.

 
Webinaari: Modern Agile - Näin päivität menetelmäsi 16.1.2019

Miten lähteä avaamaan rajapintoja?

API-rajapinnoilla voidaan rakentaa vaikka kokonaan uusia liiketoimintamalleja, ja monesti ne tuovat silkkaa säästöä. Miten rajapintojen avaamiseen kannattaa lähteä?

Rajapinta on englanniksi interface ja API tarkoittaa suomeksi käännettynä ohjelmiston kehitysrajapintaa. Käytän tässä blogipostauksissa API-rajapinta-ilmaisua, vaikka se onkin vähän tautologinen.

Klassinen ja mahdollisesti yksinkertaisin esimerkki rajapinnasta on verkkosivut. Jos organisaatiollasi on siis verkkosivut, tarjoat kömpelönä APIna html-koodia. Fiksumpi rajapinta voisi olla rakennettu hyödyntämään esimerkiksi verkkosivun tuotantojärjestelmää REST-rajapintojen pyörittämiseen.

HTML-koodi ja REST-rajapinnat ovat ohjelmisto-, käyttöjärjestelmä- ja lisenssivapaata. Voit tarjota HTML:ää linux-palvelimella ja sitä on yhtä helppo lukea iPhonella kuin Windows-tietokoneellakin. Hyvä rajapinta ei edellytä samojen laitteiden tai ohjelmistojen ostamista, joita sen toisella osapuolella on.

 

Muista tietoturva

Kaikki eivät ole aina kuitenkaan suoraan avoimien rajapintojen ystäviä. Tietoturvapuolella monella on kiusaus joko refleksinomaisesti todeta, että tosi hienoa kun kokeillaan uusia juttuja, mutta suin päin ei sellaisia pitäisi kokeilla. Tai jopa sanoa, että ei kannata kokeilla – koska emme kaikkein vaikeimpia rajapintoja osaa kuitenkaan tehdä, on ajanhukkaa puhua niistä.

Tietoturva on otettava tosissaan, mutta päätä ei kannata laittaa kuitenkaan pensaaseen. Rajapintojen turvallisesti tekeminen on mahdollista ja jopa välttämätöntä, jotta niitä osaa käyttää, kun moinen osoittautuu kaupallisesti välttämättömäksi.

Rajapinnoissa voi soveltaa sotasairaaloiden mallia ajankäytön priorisoinnille; jos ei ole pitkää kokemusta rajapinnoista, luottamuksellisille henkilötiedoille kannattaa varmasti aluksi sanoa ei. Ei aloiteta liian vaikeasta, potilas kuolee joka tapauksessa.

 

Opettele toiminnallisilla rajapinnoilla

Niin sanotuissa datarajapinnoissa on ideana, että niissä vain jaetaan tietoa, mutta niillä ei voi muuttaa tietoa. Lisäksi suoraviivaisimmissa ei varmasti ole edes henkilötietoja, jolloin niihin ei liity samoja riskejä.

Suoraviivaisen datarajapinnan tekeminen, jossa ei ole henkilötietoja, on helppoa. Neuvomme on, että kehitystiimille voi antaa varsin itsenäisen vastuun toteutuksesta, kunhan se tehdään laillisesti ja eikä se vaikuta organisaation toimintaan tai muuta tietoa missään.

Kiinnostavimpia sekä oppimisen että vaikuttavuuden kannalta ovat toiminnalliset rajapinnat, joihin ei kuitenkaan vielä liity henkilötietoja. Näihin kannattaa laittaa paukkuja, sillä ne ovat kohtuullisen haastavia, joten niiden rakentaminen antaa oppia oikeassa kontekstissa. Kun keskittyy luottamuksellisuuteen ja eheyteen, ja hoitaa ne mahdollisimman hyvin, voi edetä pikkuhiljaa myös henkilötietojen käsittelyä sisältäviin rajapintoihin.

 

Kun toimeen sitten ryhtyy, mitä pitäisi ottaa huomioon?

Kannattaa aloittaa siis avaamalla se kaikkein helpoin juttu, datarajapinnat. Tiimi voi tehdä sen itsenäisesti, ja siihen ei tarvitse laittaa aivan hirveästi paukkuja. Kannattaa kuitenkin varmistaa, ettei kukaan ole avaamassa rajapintoja yksin.

On hirveän vaikea tehdä turvallista työtä tehokkaasti. Projektissa on oltava mukana ainakin kaksi ihmistä, joista toisen tehtävä on tehdä ja toteuttaa, ja toisen työnä on tarkastaa, että laatu säilyy korkeana ja asiat tapahtuvat tietoturvallisesti ja säännösten mukaisesti. Asetelma on kuin keskushyökkääjällä ja maalivahdilla.

Datarajapintoja avatessa kannattaa varmistaa, että aikaa on vähän enemmän kuin jos sama data olisi tuotu organisaation verkkosivulle. Kun rajapintoja ollaan avaamassa ensimmäistä kertaa, opetellaan uutta. Kun rutiinit ovat ajan myötä kasassa, rajapintojen avaamisen pitäisi olla helpompaa kuin verkkosivujen avaaminen, sillä API-rajapintoihin ei liity esimerkiksi visuaalisen käyttöliittymän suunnittelua.

 

Ennen kuin etenet, suunnittele

API-rajapinnoissa hyvin suunniteltu on puoliksi tehty. Tekemisellä aloittaminen on hyvää hakkerieetosta, mutta mallilla tulee helposti avanneeksi enemmän kuin oli tarkoitus tai vääriä asioita. Sähläämällä taas voi käydä niin, että avaa dataa, joka ei kiinnosta ketään tai joka on muodossa, jossa kukaan ei voi sitä hyödyntää.

Dataan pitää myös tutustua. On täysin normaalia, että tiedossa, jossa ei pitänyt olla henkilötietoja, onkin seliteteksteihin laitettu sosiaaliturvatunnuksia, vaikka ohjeistus toisin sanoo. Varmista siis mitä rajapinnan kautta kulkeva data oikeasti sisältää.

Tietosuojalainsäädäntö on syytä tuntea huolella, varsinkin siinä vaiheessa kun rajapintaan liittyy henkilötietoja. Lakia tulee tuntea paitsi sen takia, ettei tule rikkoneeksi sitä, mutta myös siksi, että on ihan yhtä tärkeää osata perustella muille, miksi ei riko säännöksiä. Rajapintojen avaaminen voi herättää pelkoa esimerkiksi tietosuojarikkeistä, jolloin on hyvä tietää, mitä on tekemässä ja olla selkeät sävelet, jottei tärkeä työ mene hukkaan väärien pelkojen vuoksi.

 

Tunne lisenssit ja teetä uhka-analyysi

Pelkkä datan tunteminenkaan ei riitä, pitää olla myös selkeä ymmärrys siitä, mistä dataa luetaan, ja mistä siihen kirjaudutaan. Tieto pitää tuntea yhtä hyvin fyysisellä tasolla, tietojärjestelmätasolla sekä loogisella tasolla. Jos esimerkiksi osoite on väärin, on oltava kyky ymmärtää, mistä väärinkirjaus johtuu, ja kenen vastuulla on korjata se. Huonolaatuisen datan jakaminen ei kannata.

Uhka-analyysin teettäminen on myös kannattavaa kun suunnittelee rajapinnan avaamista. Se tarkoittaa sitä, että joku tietoa ja järjestelmiä ymmärtävä listaa kaikki mahdolliset kohdat, mikä rajapinnan avaamisen johdosta voi mennä pieleen. Voiko rajapintaa käyttää esimerkiksi luottamuksellisen tiedon joutumiseen vääriin käsiin?

Lisenssit kannattaa myös tuntea. Sellaiset sopimukset eivät ole harvinaisia, joissa rajapintojen käyttö on järjettömän kallista. Olisi piinallista herätä Oraclen myyntimiehen soittoon, jonka mukaan lisenssikustannukset ovat nousseet 15 000 kertaisiksi.

Katso webinaari: API-liiketoimintamallit

Sarvikuonojohtaja saa transformaatiossa köniinsä

Johtamista mitataan vaikeissa tilanteissa – muun muassa niissä, jossa organisaation tiukat luvut tuntuvat vaativan arvojen, roolin tai luonteenvastaisia toimia.

Mitä siis tehdä siinä tilanteessa, jossa itselle on otettu, tai alaiselle on annettu tehtävä, joka on vahvasti ristiriitainen, ja jossa onnistumisessa kovat tavoitteet taistelevat tekijän pehmeiden tavoitteiden kanssa?

Tällaisissa tilanteissa moni johtaja toimii vaistojen varassa ja toiminta usein noudattaa kiusallisen ennustettavia malleja ristiriidan yksityiskohdista riippumatta.

Johtaja voi olla:

Sarvikuonojohtaja vähät välittää organisaatioon muodostuvista vaikeista työyhdistelmistä, jossa onnistuminen edellyttää toisen näkökulman kokonaan jättämistä huomiotta, koska kompromisseille ei ole jäänyt tilaa. Kutsun tätä sarvikuonojohtamiseksi. Tyypillinen sarvikuonojohtajan sanonta on “ei kiinnosta, tärkeintä on, että pidät kiinni niistä tunnuslukulupauksista, jotka sovimme viime kehityskeskustelussa.”

Empaattinen johtaja tukee vaikeissa tilanteissa alaisen jaksamista, mutta sarvikuonojohtajan tavoin pitää tiukasti kiinni niistä lupauksista, jotka alaiselta on saatu puristettua. “Kyllä sä tämän jaksat. Ymmärrän, että voi olla vaikeaa, mutta kohta tää pahin vaihe on ohi.”

Kompromissijohtaja ämpyilee ja etsii vaikean tilanteen kohdalla kompromisseja, jotka vesittävät tavoitteen ja tuovat kaikille periksiannon fiiliksen. Mitään ei ole pakko tehdä kunnolla, kun aina voi pyytää luvan jättää puolitiehen.

Sumanpurkajajohtaja eli pehmeiden ja kovien arvojen välisiä ristiriitoja purkava johtaja voi parhaimmillaan yhdellä lauseella auttaa ymmärtämään ristiriidan näennäisyyden tai toisaalta tehdä rakenteellisiakin muutoksia, jotta ristiriita ei jää yhden kannettavaksi vaan se saatetaan jopa saada puretuksi.

 

Sumanpurkaja paketoi homman kasaan

Moni yritys ja tiimi käy läpi transformaatiota, harkitsee sellaista, tai pelkää moista, esimerkiksi vaikkapa ketteryyteen, asiakaslähtöisyyteen, leaniin tai itseohjautuvuuteen siirtymistä.

Transformaatiossa onnistuminen ja onnistumisen kustannukset riippuvat johtajan tavasta hallita pehmeiden ja kovien arvojen ristiriitaa. Transformaatiossa johtajan ja alaisen minäkuvan ja uuden roolin tai tiimidynamiikan hetkelliset ristiriidat voivat olla äärimmäisellä, avioeroon rinnastettavalla stressitasolla.

Transformaatiossa kompromissijohtaja epäonnistuu, sarvikuonojohtaja aiheuttaa irtisanomisten aallon ja empaattinen johtaja sairaslomien aallon. Vain sumanpurkajajohtaja voi saada homman pakettiin ilman merkittäviä taloudellisia vaurioita.

Erityisesti itseohjautuvat organisaatiot vaativat valtavan määrän ristiriitojen purkua onnistuakseen. Epäilen, että vain ristiriitoja purkamaan oppinut johtaja voi pitemmän päälle nauttia toiminnasta itseohjautuvassa organisaatiossa.

 

Mistä aloittaa?

Havainnoi omaa toimintaasi vaikeissa tilanteissa – vesitätkö muutoksen, painatko väkisin läpi tunteista välittäen tai välittämättä vai löydätkö usein viisastenkiven eli tavoitteista kiinni pitävän, mutta vaikeat emotionaaliset tai sosiaaliset tilanteet ennakkoon tai lennossa poistavan johtajan?

Muista, että pitemmän päälle et voi saada hyviä tuloksia, jos tiimissä on ahdistusta, pelkoa tai häpeää. Johtajan on mentävä kohti vaikeita tunteita ja auttaa niiden purkaminen systeemiä tai ajattelutapaa muuttamalla.

 
New call-to-action