Sote-tietojärjestelmien evoluutio on elintärkeää sote-uudistuksen tavoitteiden saavuttamiselle. Asiakkaiden tarpeet, odotukset ja käyttäytymistavat muuttuvat. Organisaatioiden vastuut ja toimintatavat vaihtuvat. Digitalisaatio mahdollistaa täysin uudenlaiset ja tehokkaammat toimintatavat. Nämä muutosvoimat haastavat perinteiset tavat hankkia ja hallita tietojärjestelmiä. Etukäteissuunnittelulla on yhä paikkansa, mutta suunnittelu kohdistuu eri asioihin ja eri aikajänteellä. Parhaat suunnitelmat, arkkitehtuurit ja toteutukset on tehty jatkuvaa muutosta tukeviksi.
Sote-uudistuksen tavoitteena on toiminnan muutos, jonka avulla parannetaan palvelujen saatavuutta ja yhdenvertaisuutta. Sote-palveluntuottajien ja -järjestäjien toimintaa tullaan kehittämään kokeilemalla ja viemällä parhaita käytäntöjä laajempaan käyttöön. Tämä toimintatapa edellyttää tietojärjestelmiltä kyvykkyyttä tukea kokeiluja sekä mukautumiskykyä uusiin toimintatapoihin. Jatkuva evoluutio asettaa kovia vaatimuksia tietojärjestelmien arkkitehtuurille.
Arkkitehtuurin kyvykkyys jatkuvaan evoolutioon rakentuu teknisistä päätöksistä ja arkkitehtuurin hallintaan liittyvistä toiminnan tavoista. Arkkitehtuurimallit kuten mikropalveluarkkitehtuuri ja modulaarinen rakenne auttavat evoluutiokyvykkyyden rakentamisessa. Jatkuvaan oppimiseen panostavat toimintatavat auttavat ohjaamaan evoluutiota oikeaan suuntaan. Kuvassa (alla) on kuvattuna tietojärjestelmien kehityksen trendimuutoksia kohti paremmin evoluutiota tukevaa arkkitehtuurimallia ja toimintatapoja. Tässä kirjoituksessa ja sen jatko-osioissa käsitellään tapoja arkkitehtuurin vision kirkastamiseen, arkkitehtuurisuunnittelun tekemiseen, toteutuksen hallintaan ja ennen kaikkea jatkuvan evoluution edellytyksiin.

Arkkitehtuurimallien ja toimintatapojen muutos kohti parempaa evoluutiokyvykkyyttä.

Arkkitehtuurin vision pohjaksi otetaan sote-uudistuksen tavoitteet ja strategia, tuodaan mukaan ymmärrys nykytilasta ja tarkastellaan näitä tavoitteita arkkitehtuurin kannalta. Tavoitteiksi voi nousta asioita liittyen esimerkiksi tietojen siirrettävyyteen, teknologiariippumattomuuteen, muokattavuuteen, laajennettavuuteen, standardien noudattamiseen ja valittujen kansallisten palveluiden käyttöön. Tavoitteet kirjoitetaan ylös siten, että niistä käy ilmi perustelut (esim. sote-uudistuksen tavoitteista esille noussut arkkitehtuurivaatimus) ja myös se miten ne voidaan todentaa suunnitelmista ja toteutuksista (esim. tietty rajapinta tai toiminnallisuuksien partitionti).
Arkkitehtuuriin evoluutio pitää huomioida jo uusien tietojärjestelmien hankintavaiheessa – tarjouspyynnöissä, tarjouksissa ja sopimusmalleissa. Tarjouspyynnöissä kuvataan nykyinen ymmärrys tarpeesta sekä pyydetään toimittajaa kuvaamaan arkkitehtuuritavoitteet täyttävä ratkaisu. Osana toimittajan ehdottamaa ratkaisua pitää siis löytyä tuki arkkitehtuurin evoluutiolle. Evoluutiota tuetaan teknisillä päätöksillä, mutta ennen kaikkea toimittajan ja tilaajan toimintatavoilla. Sopimusteknisesti tämä edellyttää mallia, jossa työoletuksena on vaatimusten muuttuminen. Tätä tukemaan tarvitaan kyvykkyys jatkuvaan uusien versioiden toimittamiseen, koska kokeiluja tehdään useita ja tietojärjestelmien pitää tukea niitä. Näillä toimintatavoilla mahdollistetaan myös ratkaisun tarkentaminen kohti parantunutta käsitystä asiakastarpeesta.
Arkkitehtuurin visio määrittelee tavoitteen abstraktilla tasolla antaen suuntaviivoja 3-5 vuoden päähän tulevaisuuteen. Askelmerkit kohti tavoitetta luodaan arkkitehtuurisuunnitelman avulla, joka kuvaa muutokset konkreettisemmin ja sijoittaa ne aikajanalle. Suunnitelmien osalta tarkistetaan niiden yhteensopivuus arkkitehtuurin tavoitteiden kanssa. Mahdolliset poikkeamat tavoitteiden suhteen käsitellään samalla operatiivisella ryhmällä kuin missä arkkitehtuuritavoitteista sovittiin aiemmin.
Arkkitehtuuritavoitteiden toteutumista seurataan myös tietojärjestelmien kehitys- ja ylläpitovaiheissa. Jatkuva evoluutio edellyttää jatkuvaa kehitystyötä ja kaikki arkkitehtuuriset muutokset pitää tarkistaa suhteessa arkkitehtuuritavoitteisiin. Mahdolliset poikkeamat tavoitteista pitää nostaa esille samalle operatiiviselle tasolle kuin missä tavoitteista sovittin aiemmin. Tämä vaatii toimitusprojektien sisällä tietoisuutta aiemmin päätetyistä arkkitehtuuritavoitteista.
Sote-uudistuksen tavoitteet vaativat uudenlaista tapaa visioida, suunnitella ja toteuttaa tietojärjestelmien arkkitehtuuria. Miten hyvin tässä onnistutaan riippuu monesta asiasta. Seuraavassa kirjoituksessa on tarkoitus paneutua tarkemmin vision muodostamiseen ja sen arkkitehtuuriseen kuvaamiseen. Mitä haluaisit sen osalta käsiteltävän?

Avatar

Stefan Baggström

Stefan toimii terveyden ja hyvinvoinnin toimialavastaavana Goforella. Stefan on johtamisen, ketterien menetelmien ja tietojärjstelmäarkkitehtuurien asiantuntija. Työssään hän pyrkii kehittämään asiakaskeskeisiä ratkaisuja ja toimintatapoja kokonaisvaltaisesti kohti jatkuvan onnistumisen mallia.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Olen blogannut aikaisemmin DevOpsista ja ketterän kehityksen skaalaamisesta, ja tämä blogi punoo nämä aiheet yhteen. Meillä muutkin ovat aikaisemminkin bloganneet ansiokkaasti DevOps-ajattelun tehokkuudesta. Tapio Rautonen totesi ansiokkaasti jo 2013, että ”infrastruktuurin hallinnasta tulee osa sovelluskehitystä”.

DevOps ohjaa yhteistyöhön

Johdon, tuotannon ja ylläpidon pitää toimia lähekkäin asiakkaan hyväksi, koska asiakas päättää mikä toimii

The Phoenix Project -kirjassa IT-pomo saa tehtäväkseen saattaa uuden, kriittisen ja pahasti myöhässä olevan tuotekehityshankkeen takaisin raiteille. Pääjohtaja uhkaa ulkoistaa koko IT-osaston. Tämä on arkipäivää monessa yrityksessä. Bisnes haluaa uudistua ja luoda uusia digitaalisia ratkaisuja, jotka integroivat vanhat järjestelmät osaksi uutta, älykästä tuotannonohjausta. Kirjassa tilanne pelastetaan saattamalla kehitys- ja ylläpitotiimit lähemmäs toisiaan ketteryyttä ja DevOps-ajattelua lisäämällä. Tämän myötä sekä bisnes, kehitys että ylläpito saavuttavat nopean palauteketjun. Idea viedään nopeasti tuotantoon, toteutuksesta saadaan palautetta ja päästään välittömästi hienosäätämään ideaa sekä toteutustapaa. Tähän päästään ketterällä priorisoinnilla ja automatisoinnilla. Meidän Tapio Rautonen on myös esitelmöinyt palauteketjun kriittisyydestä.
DevOps Handbook toteaa osuvasti, että tavoitteena on muodostaa positiivinen kierre, missä automatisoinnin vapauttamat resurssit hyödynnetään uuden innovointiin ja vanhan refaktorointiin. Vastakohtana on negatiivinen kierre, missä jatkuvasti vaikeutuva integrointi ja tuotantoonvienti johtaa viivästyksiin ja laadusta tinkimiseen, jolloin tekninen velka kasvaa johtaen yhä uusiin ongelmiin. Negatiivisessa kierteessä työskentely johtaa vähitellen psykologiseen avuttomuuteen, missä ei edes pyritä ratkaisemaan kohdattuja ongelmia ja pelätään seuraavaa, koko viikonlopun vievää tuotantoonvientiä. DevOps tehostaa koko organisaatiota ja organisaation yksittäisten funktioiden toimintaa (Dev, Ops, QA, Sec) sekä voimauttaa yksilöitä. Onko parempaa myyntipuhetta.
The Phoenix -kirja on fiktiivinen eikä ota kantaa kulttuurimuutokseen, jonka organisaatio todellisuudessa joutuisi käymään läpi tämän kokoluokan muutoksessa. Kirjahan on samaa sarjaa The Goal -teoksen kanssa, jossa fiktiivinen hahmo Lean konsultoi sekä tuotantolaitoksensa että avioliittonsa parempaan iskuun. Todellisuus on tarua ihmeellisempää.

DevOps nyrkkisääntöjä

State of DevOps 2017Leading the Transformation, DevOps Handbook ja Marko Leppäsen väitöskirja pyörivät yksinkertaisten ideoiden äärellä:

  1. Älä keksi tekosyitä, nopeus on mielentila
  2. Työn kehittäminen on tärkeämpää kuin työn tekeminen
  3. Tehdään vain suunniteltu työ
  4. Valmis tarkoittaa läpi organisaation, että ominaisuudelle on kehitetty testiautomaatio, ajettu koodianalyysi ja ne täyttävät tavoitellun kattavuuden
  5. Kaikki käyttävät yhteisiä työkaluja ja ympäristöjä
  6. Kaikki käyttävät samaa versionhallinnan haaraa
  7. Arkkitehtuurin tulee olla modulaarinen, tai käsissäsi on iso läjä teknistä velkaa
  8. Teknologia-valinta on arkkitehtuuri-valinta, arkkitehtuuri-valinta on automatisointi-valinta

Aikaisempi DevOps blogini on helppo ja kevyt katsaus hieman syvemmälle aiheeseen.

DevOps mahdollistaa aidon ketteryyden

Muutos on aina käynnissä oleva prosessi ja ketterästi käytettynä huima kilpailuetu

Organisaation ketteröityminen on sekä haaste että -toteutuessaan- huima kilpailuetu. Ketteryys ohjaa tiimit aktiiviseen yhteistyöhön. Lean siivoa rönsyt. DevOps koneisto tarjoaa tuotekehitykselle välittömän näkymän ohjelmistotuotannon kapasiteettiin ja laatuun. Yritysjohdon tulee ymmärtää, että ohjelmistotuotantoa ei kannata organisoida samoin kuin tuotantoa, koska:

  1. Ohjelmisto on ainutkertainen kokonaisuus, joten sen tuottaminen sisältää enemmän epävarmuustekijöitä, kuin muu tuotanto.
  2. Ohjelmistomuutosten toimivuuden ennustaminen on vaikeaa.
  3. Hyvin toteutetun ohjelmiston muuttaminen on halvempaa ja nopeampaa kuin minkään muun tuotteen, mikä tarjoaa ainutlaatuisen kyvyn reagoida markkinamuutoksiin.

Raskas etukäteen suunnittelu on ohjelmistotuotannossa turhaa ja ohjelmistojen tarjoama ainutlaatuinen joustavuus kannattaa nähdä kilpailuetuna, ei uhkana.

DevOps mahdollistaa kokeilukulttuurin

Kukaan ei osaa sanoa etukäteen miten uusi ominaisuus toimii todellisuudessa. Ei varsinkaan johto

Mitä suuremmaksi yritys kasvaa, sitä tärkeämpää on säilyttää kyky kokeilla. Hierarkkisessa organisaatioissa syntyy usein jossain vaiheessa myytti, että johtajat tietävät mitä asiakas haluaa. Tätä joukkohypnoosia vastaan pitää taistella, ellei halua firmalle käyvän kuten vaikkapa Nokialle tai Kodakille, jotka yrityksinä onnistuivat uudistumaan vasta kun kaikki hypnotisoidut oli irtisanottu.
Agile, DevOps ja Lean kaikki peräänkuuluttavat jatkuvaa kehittymistä, kurinalaisuutta ja läpinäkyvyyttä läpi organisaation. Tavoitteena on saavuttaa kyky viedä muutoksia tuotantoon nopeasti. Tällöin voidaan optimoida bisnespäätöksiä tuotannosta saavutettujen kokemusten. Tämä johtaa tiiviimpään yhteistyöhön bisneksen, kehittäjien, ylläpidon ja asiakkaan välillä. Eli toisin sanoen saavutetaan läpinäkyvyyttä ja tarkempi tehtävien priorisointi.
Uuden ominaisuuden toteuttaminen on uhkapeliä. Ronny Kohavi et al. väittävät, että enintään joka toinen uusi ominaisuus osoittautuu asiakkaan kannalta tarpeelliseksi. Olsen nimittää tätä Product-Market Fit termillä The Lean Product Playbook -kirjassaan. Ohjelmistobisneksessä tämä ei tarkoita, että pitää suunnitella tarkemmin. Sen sijaan pitää voida kokeilla, epäonnistua ja oppia nopeasti. Kukaan ei osaa sanoa etukäteen miten uusi, ainutlaatuinen ominaisuus tulee todellisuudessa palvelemaan. Saadaksemme ohjelmistokehitykseen kaadettavat rahat poikimaan, ominaisuuksien pitää jalkautua tuotantoon nopeasti. ”Valmis” käyttämätön koodi on pahinta tuhlausta. Yksi Googlen menestyksen peruskiviä on beta-kokeilukulttuuri, jonka puolesta myös Intuit perustaja Scott Cook vahvasti puhuu. Goforen juuri painosta tulleessa kulttuurioppaassa todetaan osuvasti ”Post-it, Ikean litteiden pakkausten liiketoimintamalli, Amazonin pilviliiketoiminta ja lukuisat Googlen tuotteet ovat kaikki työntekijöiden keksimiä ja kehittämiä. Nämä henkilöt katsoivat asioita laajemmin kuin mitä heidät oli alun perin yritykseen palkattu tekemään.”
Tietoisuuteemme putkahtaa jatkuvasti uusia, teknologiassa edellä käyviä ja nopeasti kasvavia yrityksiä. Asiakkaana tilannetta on helppo arvottaa:

Itse pidän ensin listattuja laadukkaampina ja helppokäyttöisempinä, vaikka kaikkia näistä käytänkin. Yksi selitys parempaan käyttökokemukseen on aktiivinen ja avoin kokeilukulttuurin kehittäminen. Ja kulttuurin tukeminen toimivalla DevOps-koneistolla.
Säännöllinen julkaiseminen vaatii kehittäjien, testaajien ja tukitoimintojen saumatonta yhteistyötä, eli DevOpsia. Tavoitteena tulee olla automatisoitu julkaisuputki. Tämän saavuttaminen on usein työlästä, mutta onnistuessaan se vapauttaa resursseja asiakkaalle ja bisnekselle tärkeisiin kehityskohteisiin tulipalojen sammuttelun, manuaalisen konfiguroinnin ja testailun sekä jatkuvan muutosten jahtaamisen sijaan.

Muutos on yhteinen tavoite

Ketteryyden skaalaaminen on helpompaa, kuin kuvitellaan

Yrityksissä tavoitellaan ohjelmistotuotannon tuottavuusloikkaa Agilen ja ketteryyden avulla. Palkataan ketteriä konsultteja ja ajetaan yksittäisiä keihäänkärkitiimejä ketteriin työtapoihin. Tiimin työtapojen kehittäminen auttaakin pienessä organisaatiossa. Laajemmassa organisaatiossa tehottomuus syntyy tiimien välisestä yhteistyöstä. Tiimien prioriteetit tai aikataulut eivät kohtaa, joten tiimit pikemmin taistelevat toisiaan vastaan. Yksittäisten tiimien ketteröittäminen ei paranna suuren organisaation tehokkuutta. Sen sijaan tulee huolehtia tiimien välisestä yhteistyöstä ja tuotosten integroinnista. Sama pätee DevOps muutoksessa. Ei auta, että yksi keihäänkärkitiimi pilotoi tai kokeilee ideologiaa. DevOps tulee olla kaikkien yhteinen tavoite, johon myös ylin johto sitoutuu.
 
Kuva: Henrik Knibergin kuuluisasta Spotify-videosta lainattu esimerkki vapaudesta ja yhdensuuntaisuudesta. Mikromanageeraus tappaa tuottavuuden (vasen yläkulma), tiimien välisen yhdensuuntaamisen puute johtaa näennäisen tuottaviin tiimeihin, jotka todellisuudessa taistelevat toisiaan vastaan (oikea alakulma). Tavoiteltava optimitila oikeassa yläkulmassa, missä tiimit toimivat yhteisen tavoitteen hyväksi, lähestyen yhteistä tavoitetta omasta näkökulmastaan.
Johdon tulee kirkastaa tavoitteita ja prioriteetteja jatkuvasti, mutta myös tarjota vapaus niiden tavoitteluun. Gary Gruver toteaa Leading the Transformation kirjassaan, että suuressa organisaatiossa ketteryyden tulee valua ylhäältä alaspäin, johdon roolin rajautuessa siihen, että johto sanelee yhteisen kellosyklin ja prioriteetit. Ei varmasti ole sattumaa, että Netflix peräänkuuluttaa vastaavia vapautta ja vastuuta kannustavia arvoja. Myös SAFe-manuaali toteaa saman, lainaten legendaarista Leading Change artikkelia, että johdon tulee asettaa pelisäännöt muutokselle organisaation laajuisesti.
SAFe esimerkit ovatkin täynnä kertomuksia, missä organisaation lävistävä kellosykli ja priorisointi ovat johtaneet huimaan tuottavuusloikkaan. Salaisuus mielestäni ei ole SAFe prosessin erinomaisuudessa, vaan koko organisaation lävistävässä käyttöönotossa. Mitä aikaisemmin tiimien väliset prioriteetti- ja integrointiongelmat ratkaistaan, niin sitä vähemmän tiimit taistelevat toisiaan vastaan. Tämä johtaa olemassa olevien hankkeiden läpimenon paranemiseen. Mikä taas vapauttaa resursseja uudiskehitykselle.
Kaikkien muutoshankkeiden ytimessä tulee olla selkeä bisnes case. Muutos ei ole koskaan helppoa, joten tavoitteen ja motiivien pitää olla vahvoja. Johdolla tulee olla selkeä näkemys siitä miksi DevOps, Agile ja Lean muutokseen lähdetään. State of DevOps –raportti listaa menestyvän muutosjohtajan ominaisuuksiksi vahvan vision ja organisaatiota valtuuttavan, sekä inspiroivan johtajuuden. Gartner taas arvioi käänteisesti, että puolet niistä tietohallintojohtajista saa potkut, jotka eivät ole ymmärtäneet modernisoida IT-tukifunktioita vuoteen 2020 mennessä.

Jari Hietaniemi

Jari Hietaniemi

Jari on yksi Goforen monilahjakkaista palveluarkkitehdeista. Hänen ydinosaamistaan on monimutkaisten sekä laajojen tietojärjestelmähankkeiden suunnittelu ja vetäminen. Jarin filosofian mukaan projektipäällikkö on tarvittaessa myös myyntiedustaja, innovaattori, laatupäällikkö, tekninen suunnittelija ja henkilöstöesimies samassa paketissa. Hänen monipuolinen kokemuksensa ja valmentava tyylinsä vievät projektit laadukkaasti maaliin sekä tuovat myös uudenlaista ajattelua ja draivia kohdeorganisaatioon.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Mitä on Business design? Miten asiakkaiden tarpeet voidaan huomioida strategisessa päätöksenteossa? Uunituore Goforen Business design booklet antaa tähän vastaukset.
Business design booklet tarjoaa kattavan johdatuksen aiheeseen. Opas kertoo, mitä business design on käytännössä sekä millaisiin liiketoiminnan haasteisiin sen avulla voidaan löytää ratkaisuja.
– Tärkeintä business designissa on ottaa mukaan sekä yrityksen asiantuntijat että asiakkaat tunnistamaan uusia liiketoiminnan mahdollisuuksia, kertoo oppaan kirjoittanut Senior Business Designer Hanna-Riikka Sundberg.
Yhteistyöllä taataan se, että kartoitetuissa liiketoimintamahdollisuuksissa huomioidaan sekä asiakkaan tarpeet että yrityksen strategiset tavoitteet.
Gofore haluaa kirkastaa asiakkailleen, mistä business designissa on kyse, ja miten asiakasyritykset voivat kehittää liiketoimintaansa asiakaslähtöisemmin. Oppaan sisältö pohjautuu osaamiseen, jota ovat kartuttaneet lukuisat business designin asiakasprojektit sekä yhteistyö alan ammattilaisten kanssa. Oppaan tarkoitus on innostaa lukijoita ajattelemaan asiakas- ja käyttäjäkokemusta uudessa valossa, erityisesti palvelumuotoilun ja strategisen päätöksenteon yhteydessä.
Opas on tarkoitettu kaikille business designista kiinnostuneille: se tarjoaa sekä nopean katsaukseen aiheeseen että tukea business designiin liittyvien asioiden kanssa painiskeleville ammattilaisille. Oppaasta hyötyvät myös ne lukijat, jotka pohtivat business designin mahdollisuuksia uuden liiketoiminnan synnyttämisessä juuri kasvavilla ja kilpailukykyisillä markkinoilla.

Lataa englanninkielinen opas tästä.

 

Lisää tietoa Goforen Business design -palveluista:
Soile Roth, puh. 0400 782 737, soile.roth@gofore.com

Hanna-Riikka Sundberg

Hanna-Riikka Sundberg

Hanna-Riikka toimii Senior Business Designerin roolissa Goforella. Hänellä on kokemusta erityisesti asiakas- ja käyttäjätutkimuksesta sekä liiketoiminnan ja palveluiden kehittämisestä lukuisilla toimialoilla. Hanna-Riikan tavoitteena on tuoda asiakkaiden ja käyttäjien tarpeet osaksi yritysten strategista päätöksentekoa.

Piditkö lukemastasi? Jaa se myös muille.

With the merger of Gofore and Leadin at the end of May, we received a lot of new opportunities and challenges and also new muscle to carry out challenging tasks of digital transformation of organizations in Finland and Europe. The recent history of Gofore has been very successful, mostly due to our work within the Finnish public sector. The language used within Gofore has traditionally been Finnish, and knowledge of the Finnish language has always been a requirement for employees also.
Many things have changed with the merger. Leadin brings in a lot of new diversity, industrially based customers and most interestingly of all, international operations with international clients. As a result of this, the company language is now moving more towards English. Gofore now has operations in the UK, Germany and three locations in Finland.
I have enjoyed my over 10-year journey with Gofore helping mainly Finnish customers with their digital transformation. However, this was a perfect time for me to change the scope a bit. In the beginning of June, I joined our team of experts that works for the most important industrial customer, the German originated Voith.

Industrie 4.0

Industrie 4.0 is a German-government-sponsored vision for advanced manufacturing and refers to what is considered to be the fourth industrial revolution, following water and steam power, mass production and automation through IT and robotics.

Picture: Christoph Roser at AllAboutLean.com

Revolution is a fundamental change of old structures and methods that takes place in a relatively short time. As with a revolution in general, industrial revolution means that some of the old successes will die and new ones will rise. Even a giant can fall if they are not keeping up with the current fast occurring changes.

Voith

Voith, which was founded around the time the first industrial revolution took place, has successfully applied changes from the industrial revolutions ever since. The global industry leader, with 150 years of history, operates, for example, in the fields of hydropower generation, paper technology and power transmission and is one of the largest family-owned companies in Europe with around 19,000 employees and sales of €4.3 billion.
I have no doubt Voith will benefit hugely from, and be at the forefront of this fourth industrial revolution. The effort invested in the development of projects such as the industrial internet as well as other completely new business models, is remarkable and it is imperative this development continues, especially when such fundamental changes are happening not only rapidly but also on such a regular basis. Simply put, Voith has unbeatable expertise within the industrial areas that they operate in and have a clear vision for the steps required to remain on the top during the fourth industrial revolution. We at Gofore are delighted to be helping Voith achieve another success story in their long history.
When I had the opportunity to join the team, it became quite clear to me that in order to be able to help the customer the best possible way, it would be very beneficial to be near them. It was also something I was more than happy to do. Without too much planning, in the beginning of July, I packed my family together with necessary things into our car and started driving towards the Voith headquarters located in Southern Germany.

Sommerski

My family had the opportunity to spend the summer in the lovely Swabian town of Heidenheim, which is where the Voith headquarters is located. Despite the town being in the beautiful countryside of Baden-Württemberg, the atmosphere and work environment in Voith Digital Solutions, where I spent my working days, is very international, with many people with a multitude of different nationalities working together to achieve a common goal, with English being used as a common working language. Sometimes the working days were long, but I still had plenty of free time to enjoy the Southern Germany and the neighbouring surroundings.
As a nature and mountain lover, I really enjoyed the hiking and mountain biking in the woods and on the hills in the region. We also went on a few weekend trips to some of the medieval towns, bigger cities and amusement parks like Legoland. Maybe the most memorable moments we had, were on a weekend trip to Austria, where we experienced skiing in the heat of July and hiking in breath-taking scenery.

hintertux.jpg

While in Germany, it would be rude not to mention the fantastic beer that is available and the environment in which to enjoy it. The nice varieties of wheat beer called Weizenbier or Hefeweizen (wheat beer) or Weißbier (white beer), were most enjoyable and available everywhere in the region.
Alas, our time in Germany was interrupted by the children’s need to return to school, and with that time approaching we had to head back to Finland. Fortunately for me, I still continue working with the wonderful people involved in the programme. I appreciate the expertise of people of Voith as well as the new colleagues I have met during the past few months. And even while writing this, I am preparing for the next trip back to Heidenheim, the flight being early tomorrow morning. This time I am not able to take my family with me and the stay will be shorter, but nevertheless, I am very much looking forward to it. I will have some free time next weekend and I am going to spend it in Munich and enjoy the beginning of Oktoberfest.

Avatar

Sami Kallio

Sami on kokenut ohjelmistoarkkitehti ja huippuasiantuntijoista koostuvan tiimin vetäjä. Hän on osallistunut lukuisten erilaisten yksityisektorin ja julkishallinnnon tietojärjestelmien kehittämiseen vakuutusjärjestelmistä mediasektorille ja joukkoliikenteestä rahastotoimintaan Suomessa ja ulkomailla.

Piditkö lukemastasi? Jaa se myös muille.

Mitä ja milloin – tietosuoja-asetus pähkinänkuoressa

Euroopan parlamentti ja neuvosto teki tietosuoja-asetuksen huhtikuussa 2016 henkilötietojen käsittelystä sekä tietojen vapaasta liikkuvuudesta. Asetus tuli voimaan 24. toukokuuta 2016 ja sitä aletaan soveltaa kahden vuoden siirtymäajan jälkeen eli 25.5.2018 alkaen.
Taustalla on EU:n tahto turvata myös digitaalinen yksityisyyden suoja henkilötietojen osalta. Tätä pidetään perusoikeutena jo aiemmin määriteltyjen perusoikeuksien rinnalla. Ihmisellä itsellään tulee olla oikeus käyttää ja päättää häneen yksilöityvästä, hänestä kerättävästä ja hänen tuottamastaan digitaalisesta tiedosta. Asetus suojaa siis erityisesti meitä luonnollisia henkilöitä, mutta samalla se avaa uusia mahdollisuuksia niin viranomaisille kuin yrityksillekin. Koko henkilökohtaiseen dataan liittyvä pelikenttä muuttuu voimakkaasti ja uudet säännöt luovat tähän pelikenttään juuri oikeansuuntaisen vipuvarren.
Mitä nämä ns. uudet säännöt sitten ovat? Niitä on mahdoton kuvata lyhyesti, mutta viestin voi kiteyttää periaatteisiin, jotka ovat listattu alla. Lisää tietoa löytyy EUR-Lex sivulta:

  • Käsittelyn lainmukaisuus, kohtuullisuus ja läpinäkyvyys
  • Käyttötarkoitussidonnaisuus
  • Tietojen minimointi
  • Tietojen täsmällisyys
  • Tietojen säilytyksen rajoittaminen
  • Tietojen eheys ja luottamuksellisuus
  • Rekisterinpitäjän osoitusvelvollisuus edellä mainittujen noudattamisesta.

Byrokraattinen ja työtä lisäävä, vai jotain muuta?

Asetus nostaa aivan uudelle tasolle yksilön oikeuden omaan dataansa ja lisää merkittävästi viranomaisten ja yrityksien vastuuta toimia asetuksen mukaisesti. Suomessa henkilötietolakimme on jo nyt velvoittanut vastuulliseen henkilötietojen käyttöön ja virastoilla on selkeät lainsäädännölliset oikeudet ja velvollisuudet henkilötietojen osalta. Nämä perusteet eivät muutu. Meillä ei siis olla asetuksen suhteen laisinkaan niin kaukana kuin joissain muissa Euroopan maissa. Mutta myös meillä on mahdollista toteuttaa asetuksen tuomat uudet vaatimukset byrokraattisesti ilman, että mietitään todellista vaikuttavuutta ja mahdollisia uusia innovatiivisia ratkaisuja. Silloin päädytään helposti tilanteeseen, jossa asetus koetaan todellakin byrokraattisena ja vain työtä lisäävänä uhkana yrityksien ja virastojen kilpailukykyä, kannattavuutta ja vaikuttavuutta ajatellen.
Yksi suurimmista kompastuskivistä asetuksen vaatimuksien toteuttamisessa on ajatella sitä pelkästään IT-järjestelmävaatimuksena. Asetuksen vaikuttava toteuttaminen edellyttää muutoksia myös johtamisen ja toiminnan tasoilla. Hyvä muutosjohtaminen tässäkin asiassa lähtee siitä, että johto ymmärtää riittävästi asetuksesta, sen mahdollisuuksista ja rajoitteista ja sitä kautta pystyy määrittämään organisaationsa tahtotilan. Tämä pitäisi tehdä jo ennen kuin sukelletaan nykytilan kartoittamiseen. Tällä tavalla saadaan tarkoituksenmukainen nykytilan kartoitus ja osataan suunnitella oikeat toimenpiteet.

EU:n tietosuoja-asetus on ennen kaikkea mahdollisuus – varsinkin meille suomalaisille

Koneluettavat rajapinnat, AI taituruutta, innovatiiviset start-upit, muutoshalukkaat virastot, läpinäkyvyys lainsäädännössä – meillä Suomessa on valtavasti elementtejä jo nyt siihen, että saamme kansallisesti vaikuttavia ja siten meidän kansalaisten elämänlaatua merkittävästi parantavan EU:n tietosuoja-asetuksen toteutuksia. Odotukset ovat korkealla!

Kaija Puranen

Kaija Puranen

Kaija toimii Goforella johdon konsulttina. Kaijan työkalupakista löytyy niin perinteisten projektimenetelmien parhaat palat kuin myös ketterät menetelmät sekä niiden isoille projekteille ja organisaatioille skaalatut versiot. Ennen Goforea Kaija teki pitkän uran Microsoftilla ja Nokialla.Juuri nyt Kaijaa eniten työllistävät asiakaslähtöisyyteen liittyvät muutosprojektit, niissä erityisenä kiinnostuksen kohteena ovat johtamiskulttuurin muutos, rikastetun datan tuomat mahdollisuudet sekä GDPR vipuvoimana.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

My previous blog post introduced MongoDB, which was one of the first ‘not only SQL’ (NoSQL) databases. The blog post explained how MongoDB became almost synonymous with the NoSQL movement and how MongoDB’s rival enemy PostgreSQL responded. This blog post clarifies more reasons regarding MongoDB’s failure and reveals a glimpse of the future of the DBMS market.
New Kids on The Data Block
When MongoDB was launched, the NoSQL ecosystem was just developing. MongoDB’s competitors were old relational databases that had been on the market for ages. However, where there is demand there will be supply.
Completely new kinds of NoSQL-databases arose in the late 2000s and early 2010s. A good example was a real-time data and performance-optimised, key-value database Redis. The column-family database Cassandra, originally designed by Facebook, was another new competitor. Cassandra focussed on massive datasets and a linear scalability, and was the rational choice for huge Big Data projects. The dramatic growth of content and data search created specialised search engines such as Elasticsearch and Solr. In addition, new time-series databases like InfluxDB  were born, and they suit IoT- and sensor-based worlds extremely well. All the new NoSQL databases were exceptional in their own area and attracted old MongoDB customers.
Cloud-computing platforms, such as Amazon Web Services (AWS) and Azure, also launched their own database services. These platforms offered an easy setup, an unlimited scaling option, and a refreshing pricing model. However, advanced competitors were not MongoDB’s only enemies.
MongoDB in the Mirror
After initial enthusiasm, the first discords arose in the MongoDB-related projects. Software developers suffered various and often unusual problems. Compared to other trendy technologies, MongoDB seemed untrustworthy for products meant for a real environment.
With MongoDB’s dynamically typed schema—or in other words, “schemaless”—the benefits are easy setup and data modelling flexibility. However, this doesn’t come without a cost. A schema guarantees that the data can be stored in a consistent format. Without a schema, the responsibility of database consistency shifts to the application. A schemaless database makes the code more error-phone, increases code duplication, and easily creates deeply-nested structures.
The number one priority all databases is to store the data and keep it safe. Rumours started to spread that MongoDB’s consistency model was broken by design and that it might lead to data loss. MongoDB was accused of a lack of the product development discipline, monetising the NoSQL-market, and a slow customer support. In the end, MongoDB, Inc.’s CTO replied to the rumours in an open letter. It remains unclear if MongoDB can really lose the data, but the scandal damaged its reputation badly.
MongoDB has also suffered multiple growing pains. Lockdown problems, complicated sharding, bugs in replications, and unsafe writing are just a few to mention. In response to a critique, MongoDB released major updates, published support blogs, and organised conferences and hackathons. Unfortunately, this did not change the general opinion.
Finally, the developer community turned against MongoDB. Blogs such as Why You Should Never Ever Ever Use MongoDBGoodbye MongoDB Hello PostgreSQL, and MongoDB Frankenstein Monster NoSQL databases strengthened the negative atmosphere. The Reddit message board even contains a huge joke thread about MongoDB’s weak points.
Reality Bites
MongoDB started to become sandwiched between traditional relational databases and new NoSQL databases. Many products still need strong relational consistency, reliability, and referential integrity. Alternatively, startups are looking for more database as service solutions.
A microservices architecture encourages developers to use multiple databases in one system. With a microservices architecture, it’s possible to use MySQL for the business data and Elasticsearch for the logging purpose. MongoDB’s ‘something for everybody’ strategy did not seem valid anymore.
The database ecosystem will fragment even more in the next years. MongoDB will remain in history as a main character of the NoSQL movement. Sadly for MongoDB, history has taught us that the first rebels are not the leaders after revolution.
Graphic Design
Esa Lahikainen
References
https://redis.io/
 http://cassandra.apache.org/
https://www.elastic.co/products/elasticsearch
 http://lucene.apache.org/solr/
https://www.influxdata.com/
https://aws.amazon.com/rds/
https://azure.microsoft.com/en-us/services/sql-database/
https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-using-a-schemaless-database/
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
https://news.ycombinator.com/item?id=3202959
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/
http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/
https://www.linkedin.com/pulse/mongodb-frankenstein-monster-nosql-databases-john-de-goes
https://www.reddit.com/r/ProgrammerHumor/comments/62mfrx/what_is_mongodb/
 

Avatar

Juhana Huotarinen

Juhana on kokenut ohjelmistoprojektien vetäjä, joka on erikoistunut Lean-ajattelun ja ketterien menetelmien käyttöönottoon suurissa julkisen sektorin tietojärjestelmähankkeissa. Viime vuosina hänet on pitänyt kiireisenä mm. Trafi, Valtori (Valtiokonttori), Opetushallitus, Kela ja Liikennevirasto. Aiemmin työurallaan Juhana on toiminut myös projektipäällikkönä ja ohjelmistosuunnittelijana. Juhanan ajatuksia voi lukea lisää hänen asiantuntijablogeistaan sekä Twitteristä.

Piditkö lukemastasi? Jaa se myös muille.

Mitä on MyData -ajattelu?


 
Osallistuin 30.8-1.9.2017 Tallinnassa ja Helsingissä järjestettyyn MyData 2017 -tapahtumaan. Myönnettäköön, että käsitteenä MyData oli minulle jokseenkin tuntematon ja oletan että monille muille myös, joten avaan tässä hieman mitä MyData oikeastaan on.

Mikä Data?

Ihmisen digitaalinen jalanjälki on tätä nykyä erittäin suuri. Viimeisen kymmenen vuoden aikana kun sosiaalisen median palvelut ja älypuhelimet ovat yleistyneet ovat myös tuottamamme datamäärät monikertaistuneet. Esityksissä tuli toistuvasti esiin, että kaikesta 90 % maailman datasta on tuotettu viimeisen 2-3 vuoden aikana. Jatkossa tuotetun datan määrä vain jatkaa kasvuaan, kun yhtälöön lisätään automaattinen tiedonkeruu erilaisten laitteiden ja sensorien toimesta. Monet tahot ovat heränneet siihen, että tämä ihmisiin liittyvä data on erittäin arvokasta. Ydinkysymyksenä onkin kuka hallitsee kaikkea tätä dataa nyt ja jatkossa? Tiedätkö sinä missä ja miten sinun henkilötietojasi tällä hetkellä käytetään? Tiedetäänkö organisaatioissa missä kaikissa järjestelmissä henkilötietoja säilytetään ja kenen saatavilla ne ovat?
MyData voidaan määritellä henkilötietoina, jotka ovat henkilön itsensä täysin saatavissa ja hallittavissa. MyData liikkeen tavoitteena onkin mahdollistaa yksilöille oman datansa käyttö omiin tarkoituksiinsa mahdollisimman jouhevasti ja turvallisesti. Lisäksi tietojen pitää olla poistettavissa ja siirrettävissä yksilön haluamaan paikkaan. Esimerkkejä MyDatasta ovat ihmisen terveystiedot, pankkitiedot, ostokset ja liikkumistiedot. Hyvä esimerkki MyData-periaatteen mukaisesta konseptista on Islannin keskitetty terveystietokanta, jossa kansalainen voi hallita omaa terveystietoansa mm. voiden ladata kaikki omat tietonsa omalle laitteellensa.

EU:n tietosuoja-asetus (GDPR) ajurina muutoksessa

Kuten arvata saattaa, oli GRPR tapahtumassa isossa roolissa. GDPR:ää voidaan pitää isona sysäyksenä MyDatalle ja se asettaa uusia vaatimuksia henkilötietojen käsittelylle eri organisaatioissa. Henkilötietojen käsittelyn pelisäännöt muuttuvat mm. niin, että asiakkailla tulee jatkossa olemaan mahdollisuus tarkistaa tietonsa sähköisesti sekä vaatia omia tietojaan siirrettäväksi toiselle taholle. Uskaltaisin väittää, että tällaiset muutokset voivat olla monelle yritykselle teknisesti, mutta myös prosessimielessä erittäin haastavia. Organisaation sisäiset vastuut näihin liittyvissä kysymyksissä voivat olla monilta osin epäselviä.
Toisaalta GDPR pitää myös nähdä suurena mahdollisuutena. Se antaa organisaatiolle hyvän ja pakottavan syyn tarkastella kriittisesti omaa datastrategiaansa. Lisäksi hyvin asiansa hoitaville tahoille on luvassa uusia liiketoimintamahdollisuuksia, koska odotettavissa on suuria kuiluja hyvin ja huonosti hoitavien yritysten välille.

Asiakkaan hallitsema järjestelmä

Olen käytännössä koko 15 vuoden työurani aikana toiminut asiakasdatan parissa – asiakastietoa sisältävien järjestelmien konsulttina sekä käyttäjänä. Monille meistä, jotka ovat tehneet myynnin parissa töitä ovat erilaiset asiakkuudenhallintajärjestelmät (CRM) tuttuja. Järjestelmiin kerätään suuret määrät asiakastietoa, mutta niiden ylläpito ja hyödyntäminen jäävät monesti puheen tasolle. MyData kääntää tätä perinteistä CRM-ajattelua päälaelleen. Käsitteellisesti yhdessä esityksessä puhuttiin ”asiakkaan hallitsemasta järjestelmästä” (Customer managed relationships, CMR). Mitä tämä käytännössä tarkoittaa? Ensinnäkin on hyvä tiedostaa että kaikista laadukkain data on saatavilla suoraan asiakkaalta. Toiseksi, jos asiakkaalta saadaan suostumus datan hyödyntämiseen, on se yritykselle selvä indikaatio siitä, että asiakas haluaa jotain sen vastineeksi.
Otetaanpa esimerkiksi polkupyörän hankinta. Jos hankkii vähänkin kalliimman polkupyörän, niin sen tulee olla ominaisuuksiltaan ja kooltaan sellainen mikä soveltuu asiakkaan tarpeisiin. Pyörävalikoimat ovat nykyään valtavia ja siten asiakkailla on paljon ja monesti jopa liikaa vaihtoehtoja. Nykymallissa asiakas kiertää eri kaupoissa (kivijalassa ja netissä) ilmaisten tarpeensa joka kerta uudelleen ja uudelleen. MyData-konseptilla tehdyssä mallissa asiakas voisi itse antaa toimittajille ne henkilötiedot, jotka liittyvät polkupyörän hankintaan esim. kehon ja kehon osien pituudet, tiedot tyypillisistä pyöräilyreiteistä ja määristä sekä budjetti polkupyörän hankintaan. Näiden tietojen pohjalta polkupyöräkauppiaat voisivat ehdottaa asiakkaalle juuri hänelle sopivia tuotteita. Vastaavia onkin sovelluksia on jo nähty vaatekaupan puolella mm. Stylescript.

Mitä seuraavaksi?

Ihmisillä on tapana yliarvioida lyhyen aikavälinen kehitys ja samalla aliarvioida pitkän aikavälin kehitystä. Näin on varmasti myös MyDatan osalta. Tässä kolme konkreettista askelta siihen, miten aloittaa paremmin hahmottamaan henkilödatan ihmeellistä maailmaa.

  1. Luo tai päivitä datastrategiasi MyData-periaatteiden mukaisiksi
  2. Ota GDPR haltuun näiden 12 askeleen avulla tai pyytämällä kumppani avuksi
  3. Lähde pohtimaan minkälaista tietoa oikeasti tarvitset asiakkaistasi esim. design-ajattelun avulla

Lue lisää MyDatasta: www.mydata.org

Avatar

Karl Nyman

Kalle on monipuolinen ja asiakaslähtöinen digitaalisen liiketoimintakonsultoinnin ammattilainen. Kalle on ollut mukana toteuttamassa useita liiketoiminnan kehittämishankkeita konsultoimalla ja toteuttamalla uusien järjestelmien ja palveluiden käyttöönottoja mm. julkishallinnon, kaupankäynnin, energian, vakuuttamisen toimialoilla. Kallen ydinosaamista ja kiinnostuksen kohteita ovat mm. liiketoimintamallien ja prosessien uudistaminen digitaalisuuden keinon, monikanavainen asiakaskohtaaminen sekä ihmisten auttaminen digitaalisessa murroksessa. Kalle suhtautuu uuteen teknologian suurella intohimolla ja kokee olevansa kutsumusammatissaan liikkeenjohdon digikonsulttina.

Piditkö lukemastasi? Jaa se myös muille.

A small tree shedding its leaves
In 2015 MongoDB, Inc. published a press release that its influence has grown more than 163% in the past two years and has overtaken PostgreSQL in the DB-Engines database ranking. In addition, 27 of the Fortune 100 companies used MongoDB in their business in 2013. However, in the database management system (DBMS) league you’re only as good as your last game.
Based on the same DB-Engines database ranking, MongoDB hasn’t gained popularity in 2017. On the contrary, its influence has started to sink in the past months. Why didn’t MongoDB win the DBMS market after all?

Not a One-Hit Wonder

MongoDB’s story started in 2007 when the team behind DoubleClick created a database for their scalability and agility needs. MongoDB was one of the first document-oriented database and quickly got the developers’ attention. MongoDB seemed fresh and exciting.
MongoDB simplified development, because documents map to object-oriented programming languages naturally and remove complex object-relational mapping (ORM) layer. MongoDB’s dynamic schema model likewise meant that a database schema can evolve with business requirements. MongoDB also scaled with no downtime and without application changes, which is a huge advantage if data volume and throughput significantly grow.
MongoDB’s popularity growth had a strong bond to the emergence of JavaScript in the late 2000s. MongoDB and JavaScript use the same JavaScript Object Notation (JSON) standard for representing data structures. For the first time, it was possible to create an enterprise web application without impedance mismatch and data conversion.
The global startup movement also gave a boost to MongoDB. Startups work with proof-of-concepts, how to decrease time-to-market, and dynamic business models. Startups often needed a software to implement their product, and MongoDB was an effortless choice with its quick deployment and dynamic schema model.
When the term NoSQL was reintroduced in early 2009, MongoDB was almost a synonym of a NoSQL-database. However, NoSQL defines all kinds of non-relational databases, not only document-oriented databases. MongoDB even established “MongoDB University” where certifications and multiple online courses are available for everybody.

Return of PostgreSQL

One of MongoDB’s rival enemies is PostgreSQL. Unlike MongoDB, PostgreSQL was a traditional relational database created in the 20th century. PostgreSQL gained popularity over the years, but it had the same weaknesses as other relational databases.
PostgreSQL released version 9.4 in the end of 2014. This version contained support for HStore and JSON, which actually turned PostgreSQL into a document-capable database. On top of that, PostgreSQL 9.4 outperforms MongoDB its own backyard —in performance tests.
This changed the game between these two competitors. In a new project, it was safer to choose PostgreSQL over MongoDB, because PostgreSQL supported relational and document databases features. For the same reason, switching from PostgreSQL to MongoDB in an existing project wasn’t a topic anymore. The result was that PostgreSQL overcame MongoDB in the DB-Engines database ranking in 2017.
My latter blog post continues analysing the reasons of MongoDB’s recession and offers a glimpse in the future of the DBMS market.

Graphic Design

Esa Lahikainen

References

https://www.mongodb.com/press/mongodb-overtakes-postgresql-4-most-popular-dbms-db-engines-ranking
https://www.mongodb.com/press/mongodb-named-database-management-system-2013
https://db-engines.com/en/ranking_trend
https://www.mongodb.com/company
http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.html
https://www.mongodb.com/compare/mongodb-mysql?jmp=docs
https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js
https://en.wikipedia.org/wiki/NoSQL#History
https://university.mongodb.com/
https://www.postgresql.org/docs/9.4/static/release-9-4.html
http://www.linuxjournal.com/content/postgresql-nosql-database
https://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

Avatar

Juhana Huotarinen

Juhana on kokenut ohjelmistoprojektien vetäjä, joka on erikoistunut Lean-ajattelun ja ketterien menetelmien käyttöönottoon suurissa julkisen sektorin tietojärjestelmähankkeissa. Viime vuosina hänet on pitänyt kiireisenä mm. Trafi, Valtori (Valtiokonttori), Opetushallitus, Kela ja Liikennevirasto. Aiemmin työurallaan Juhana on toiminut myös projektipäällikkönä ja ohjelmistosuunnittelijana. Juhanan ajatuksia voi lukea lisää hänen asiantuntijablogeistaan sekä Twitteristä.

Piditkö lukemastasi? Jaa se myös muille.

Vajaassa viidessä kuukaudessa uuden työsopimuksen Goforelle on allekirjoittanut lähes 40 henkilöä. Parannetaan yhdessä maailmaa -kampanjan myötä tämä tarkoittaa yhteensä 25 500 euron lahjoitusta kolmen erinomaisen avustuskohteen kesken jaettavaksi. Keräystavoite ylittyi 500 eurolla.
Viime viikolla päättyneen Parannetaan yhdessä maailmaa -kampanjan avainajatuksena oli lahjoittaa jokaisesta kampanja-aikana tehtävästä uudesta työsopimuksesta 500 euroa palkattavan itselleen tärkeään avustuskohteeseen. Valittavia kohteita olivat Suomen luonnonsuojeluliitto, Vesilahden yläasteen Koulu Isengeen -hanke sekä Suomen syöpäsairaita lapsia, nuoria ja heidän perheitään tukeva Sylva ry. Summan on halutessaan voinut myös jakaa useamman kohteen kesken. Julkaisemme sosiaalisen median kanavissamme lähipäivinä tietoa siitä, mitä lahjoituksilla konkreettisesti tehdään.   
Myös nykyiset goforelaiset osallistuvat kampanjaan suosittelemalla itselleen uusia työkavereita. Joka viides suosituksen perusteella rekrytoitu kasvatti kunkin avustuskohteen tukipottia 500 eurolla – tätä kautta tukipotti kasvoi 6 000 €:lla. Kampanja oli käynnissä 11.4.–31.8.2017.

Rekrytointi ei hidastu kampanjan päättyessä

Goforen rekrytoinneista vastaava Mari Wuoti kertoo, että kampanja on toiminut vahvan hakemusvirran positiivisena vauhdittajana ja että esimerkiksi elokuussa Goforella aloitti 15 uutta työntekijää. Kampanja-aikana rekrytoitujen joukossa oli niin ohjelmistokehittäjiä, UX-suunnittelijoita, palvelumuotoilijoita, palveluarkkitehteja, hallinnon tukihenkilöitä kuin hankehallinnon ammattilaisia. 
Rekrytointi ei kuitenkaan hidastu kampanjan päättymisen jälkeen, vaan tavoitteena on allekirjoittaa uusia työsopimuksia samaan tahtiin kuin kampanja-aikana. ”Uusia mielenkiintoisia uramahdollisuuksia löytyy muun muassa mobiilikehityksen parista, teollisuuden projekteista ja kansainvälisestä ympäristöstä”, Mari listaa. 

Taustalla yhteinen halu muuttaa maailmaa paremmaksi

Goforen missiona on muuttaa maailmaa paremmaksi digitalisaation keinoin ja työkulttuuria uudistamalla. Marin mukaan kampanja sopii hyvin yrityksen arvoihin ja missioon muuttaa maailmaa. 
Gofore auttaa asiakkaittaan onnistumaan muun muassa suurissa kansallisissa digitalisaation hankkeissa. Digitalisaation rinnalla maailma muuttuu jokainen työpäivä kerrallaan ja etsimällä uusia tapoja toimia, kuten kampanjassa lahjoittamalla rekrytointibonus hyväntekeväisyyskohteille. ”On ollut hienoa kuulla uusien työntekijöiden tyytyväisyydestä tehdä hyvää näin konkreettisesti heti työsuhteen alkaessa”, summaa Mari.
 
Lisätietoja: 
Gofore Oy, Gofore Crew Recruiter, Mari Wuoti, mari.wuoti@gofore.com, 044 557 7717 
Kampanjasivusto: gofore.com/parannetaan-maailmaa 
Avustuskohteet:
Suomen luonnonsuojeluliitto
Isenge club -hanke
Sylva ry 
Kampanja tuotettiin yhdessä tamperelaisen mainostoimisto Daddy Finlandin kanssa.

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.