14. maaliskuuta 2019

Hinnoitteluvirhe voi tuhota bisneksesi




Tuotteistamisen yksi vaihe on hinnoittelu. Sehän on helppoa. Sen kun lätkäiset tuotteesi päälle hintalapun ja homma on sillä selvä. Kaksysiysi + alvi ja kauppa käy. Kovin usein kuitenkin kauppa ei käy, tai vaikka kävisikin, niin viivan alle ei tahdo jäädä katetta. Vika löytyy tällöin usein hinnoittelusta.

Kuka määrää lopulta hinnan?

Hinnan määrää aina asiakas. Asiakas yksin päättää, maksaako hän sinulle sen hinnan, mitä pyydät. Miten ihmeessä yrittäjäparka voi sitten tietää, mitä asiakkaan päässä liikkuu ja kuinka paljon asiakas on valmis maksamaan? Asiaan on mahdollista saada selvyyttä eri menetelmin, vaikka joskus hinnoittelu jääkin kokeilun varaan. Hinnoittelusta löytyy paljon tietoa eri lähteistä. 

Hinnoittelu omien kustannusten mukaan

Ensimmäinen hinnoittelun sääntö on, että älä hinnoittele omien kustannuksiesi mukaan. Toinen hinnoittelun sääntö on, että älä siltikään hinnoittele omien kustannuksiesi mukaan. Se on todellisuudessa kaikkein huonoin hinnoittelumalli, koska silloin ansaitset usein aivan liian vähän. Ja jos perustelet hintaasi omilla kustannuksillasi, voi asiakas helposti hakea sen edullisemman vaihtoehdon, kun sinulle työ on niin kallista. Ohjaa aina keskustelu ja asiakkaan ajattelu hänen saamaansa hyötyyn, koska sitä asiakkaan pitää ajatella. Järkevän asiakkaan mielessä onkin vain hänen hyötynsä, eivät sinun kustannuksesi. 

Pitäisikö kustannukset sitten unohtaa kokonaan? No ei toki. Jos myyt alle omien kustannustesi, teet jokaisen kaupan myötä tappiota ja sehän johtaa varmaan konkurssiin. Varmista aina, että saat myynnistä enemmän kuin oma kustannuksesi on. Jos et siihen pysty, käsissäsi ei ole hinnoitteluongelma vaan tuotteistamisongelma.

Hinnoittelu kilpailijoiden hintojen mukaan

Seuraavaksi mieleen saattaa juolahtaa, että hinnoittelenpa tuotteeni hieman edullisemmaksi kuin kilpailijat vastaavansa. Tällä tavallahan kaikki tulevat ostamaan minulta. Näin voi tapahtuakin, mutta vain hetken aikaa. Hetken kuluttua kilpailijat tekevät samalla tavalla ja taas olet kalliimpi kuin he. 

Hinnanalennusten kierre on valmis käynnistymään, ja siinä pelissä ei yksikään yrittäjä voita. Jos joudut jatkuvasti kuuntelemaan asiakkaan suusta lauseita, kuten "anna alennusta, koska saan tämän naapurista halvemmalla", ei sinulla ole todellisuudessa hinnoitteluongelmaa vaan tuotteistamisongelma. Tuotteesi ei silloin erotu kilpailijoiden tuotteista mitenkään ja silloin ainoa järkevä valintaperuste on hinta. Tällöin ota apuusi tuotteistamisen keinot ja kehitä omasta tuotteestasi sellainen kokonaisuus, että se on vertailukelvoton kilpailijoiden tuotteiden kanssa. Usein esim. tuotteiden ja palveluiden paketointi suuremmiksi kokonaisuuksiksi auttaa. 

Asiakkaan saama arvo hinnan perusteena

Silloin, kun asiakas kokee saavansa sinulta ostamastaan palvelusta enemmän arvoa kuin maksaa, on hänen helppo tehdä ostopäätös. Vielä helpompi se on silloin, kun pystyt selvästi osoittamaan asiakkaalle, kuinka paljon hän menettää sen seurauksena, että ei osta tuotettasi tai palveluasi. Menettämisen pelko on paljon painavampi syy raottaa lompakkoa kuin mahdollisesti saatu voitto. 

Kuinka sitten saat selville sen, paljonko asiakas saa hyötyä palvelustasi? Tämä voi olla usein haastavaa ja jos et keksi yhtään mitään, kannattaa palata vielä miettimään palvelun sisältöä, asiakaslupausta ja hyötyä. Myynti helpottuu todella paljon, kun saat asiakashyödyn selkeäksi numeroksi. Asiakkaat, varsinkin yritykset eivät kuluta, ne haluavat investoida.

Tätä menetelmää kutsutaan yleensä dollarisoinniksi, vaikka euroalueella ollaankin. Dollarisointi tarkoittaa menetelmää, jossa määritetään se konkreettinen euromäärä, minkä asiakas joko saa lisätuloja palvelullasi tai menettää ilman palveluasi. Seuraavaksi mieleesi voi tulla ajatus siitä, että asiakkaani ovat erilaisia, enkä uskalla luvata euromääriä. Lue eteenpäin ja katsotaan, miten tätä voidaan helpottaa.

Kiinteä hinta on helppo hinta

Ylivoimaisesti helpoin tapa määrätä palvelun hinta on antaa sille kiinteä hinta. Silloin asiakas tietää aina, minkä verran hänen pitää maksaa ja hän voi pohtia, onko investointi hänelle kannattava. Tässä mallissa asiakkaalle ei tule yllättäviä lisäkustannuksia ja asiakastyytyväisyys nousee. 

Myyjän kannalta hankaluus on tietysti se, että asiakkaan saama arvo hyödykkeestä voi vaihdella ja vaihteleekin asiakkaiden mukaan. Tämän vuoksi kiinteä hinta sopii parhaiten sellaiselle palvelulle, jossa pystyt sanomaan asiakkaalle hyödyn olevan vähintään X euroa, mahdollisesti jopa enemmän. Tällöin voit tehdä hinnoittelun niin, että asiakkaat saavat huomattavasti enemmän arvoa kuin mitä pyydät. Ja ne asiakkaat, jotka eivät usko väitettä tai joille itsekin tiedät, että väite ei pidä paikkaansa, eivät ole sinun asiakkaitasi. Kaikki eivät kuitenkaan osta ja se ei haittaa mitään. Jos kaikki ostaisivat, olisivat hintasi liian edulliset.

Arvopohjainen hinnoittelu laajoissa projekteissa tai asiantuntijatyössä.

Hinnoittelu on mahdollista tehdä myös ilman kiinteää hintaa, vaikka monet vannovatkin kiinteän hinnan nimeen. Kiinteän hinnan puolesta puhuu moni hyvä syy, kuten äsken jo huomattiinkin. Kiinteä hinta on helppo ja selkeä sekä se poistaa asiakkaalta riskiä, mikä on ostamisen kannalta tärkeää. 

On kuitenkin tilanteita, missä sekä myyjä että ostaja voivat saada paremman lopputuloksen puhtaasti arvopohjaisella hinnoittelulla, joka on Suomen
markkinoilla edelleen vähän käytetty lähestymistapa hinnoitteluun ja myyntiin. Monet ajattelevat suuret ja monimutkaiset projektit valitettavan usein kustannusten kautta. Arvopohjainen hinnoittelu soveltuu parhaiten asiantuntijaprojekteihin ja sen perustana on menetelmä, missä sekä ostaja että myyjä saavat reilun osan projektin tai palvelun arvosta. 

Kerron tarkemmin arvopohjaisesta hinnoittelusta myös Tieturin Tuotteistus ja hinnoittelu -koulutuksessa. Mikäli kaipaat kunnon lisäpotkua liiketoimintaan, tule mukaan koulutukseen hakemaan konkreettiset opit, joiden avulla pystyt kehittämään omaa tuotettasi ja hinnoitteluasi.

Petri Eklund

11. maaliskuuta 2019

ITIL® 4 – Mitä uutta service desk -alueella?


No, eipä paljon, voisi äkkiseltään sanoa. Service desk nähdään edelleenkin keskeisenä palvelunhallinnan osa-alueena, jolla on tärkeä rooli arvon tuottamisessa liiketoiminnalle. Ulkoisesti erona on se, että ITIL ei enää puhu funktioista ja prosesseista vaan ’practices’, käytännöistä, toimintatavoista tai mikä tuleekin aikanaan olemaan ns. virallinen käännös tälle termille. Service desk on toisin sanoen yksi ITILin määrittelemistä 34:stä ’practices’, joihin kuuluvat myös v3:sta tutut ja joissain tapauksissa hieman modifioidut (entiset) prosessit sekä joukko uusia.

ITILhän ei ole koskaan keksinyt mitään järisyttävästi uutta, vaan se on dokumentoinut kirjoihin ja kansiin niitä hyviä käytäntöjä, joita maailmalla on jo menestyksellisesti noudatettu, ja saattanut ne siten kaikkien tietoon ja hyödynnettäviksi. Niin tässäkin tapauksessa. Käsitteet kuten AI, swarming, automaatio, robotic process automation RPA, chatbot sekä sisäiset ja julkiset keskustelufoorumit ja SOME laajassa merkityksessä ovat olleet näkyviä jo usean vuoden ajan. Nämä kaikki käsitteet liittyvät kiinteästi myös service deskiin. Robottia käytetään esimerkiksi tukipyyntöjen luokitteluun, erilaisia käsittelyketjuja kuten tilaukset on automatisoitu, chatbot antaa tukea nettisivuilla, tukitiimit viestivät chatillä, twiittauksia seurataan jne.

Ehkä vähiten hyödynnetty on ’swarming’ eli ’parveilu’. Sillähän tarkoitetaan esimerkiksi, että häiriö- tai ongelmatilanteissa mahdollisimman suuri joukko sidosryhmiä osallistuu alkuvaiheen käsittelyyn antamaan ’inputtia’, jonka jälkeen asialle löydetään tarvittaessa jatkokäsittelijä(t), ja muut palaavat omiin tehtäviinsä. Käsittely ei siis ole ainakaan alkuvaiheessa hierarkkinen ja tukitasoihin perustuva etenemismalli tai prosessi, vaan asian ympärillä parveilevat kaikki tahot, joilla on mahdollisesti näkemystä, kokemusta tai tietoa asiasta. Artikkelissani vuodelta 2017 Hierarkia vai tiimien tiimi kuvasin mm. juuri tällaista toimintamallia.

Helpommin sanottu kuin tehty. Näin varmasti, mutta kannattaa kokeilla. Organisaatiorakenne tai tiukka prosessikulttuuri voi johtaa siiloutumiseen, jolloin asiat pysyvät omissa ’putkissaan’ ja lokeroissaan ilman riittävää yhteistyötä ja tiedon vaihtoa. Kuuntelin viime vuoden  SITS18-konferenssissa case-esitystä ”NHS digital story of transformation”. NHS Digital tuottaa palveluita sekä NHS:lle eli National Health Service -organisaatiolle että myös muille terveysalan toimijoille. Organisaatio on rakennettu siten, että erillisten tukitiimien ja prosessien sijasta keskeisistä palveluista vastaavat solut, joissa on mukana henkilöitä eri prosesseista ja palvelutiimeistä. Hyötyinä raportoitiin mm. palvelujen parempi saatavuus, palvelutuotannon ja kehittämistiimien välisen kommunikaation lisääntyminen, avoimien häiriökirjausten määrän lasku paikoin jopa 50 %, ratkaisuajan puolittuminen jne.

Kaiken kehittämisen taustalla oli hyödyntää mm. ketteriä menetelmiä sekä DevOps- ja Lean-ajattelua. Nämä ovat ihan samat asiat, jotka ovat myös ITILin uuden version kantavia ajatuksia. Pihvi ei olekaan siinä, että esimerkiksi service desk olisi nyt erilainen kuin ennen. Se on ihan sama tärkeä palvelunhallinnan osa-alue, mutta asioita TEHDÄÄN eri tavalla: ITIL korostaa asiakaskokemusta, kokonaisvaltaisuutta, ketteryyttä, automaation hyödyntämistä siellä, missä siitä on hyötyä, arvon tuottamista eri toimijoiden yhteistyön ja yhteisen tekemisen kautta. Eivät nämä asiat olleet mitenkään vieraita tai poissuljettuja edellisessäkään ITILin versiossa. Ne vain peittyivät ainakin näennäisesti tiukan prosessiajattelun taakse.

Ensin meillä oli funktiot, sitten prosessit ja viimeksi elinkaarimalli. Nyt ITIL kuvaa palvelun arvojärjestelmän (SVS, service value system). Tervetuloa kursseille tutustumaan ITIL 4 Foundation:iin!

Liisa Torkkeli
--------------
Liisa Torkkeli on itsenäinen palvelunhallinnan konsultti ja valmentaja. Hän kouluttaa projektinhallintaan liittyviä erilaisia kurssikokonaisuuksia, ja on myös sertifioitu Prince2-projektimenetelmän ja ITIL-viitekehyksen kouluttaja. Konsultointitehtävät kattavat palvelunhallinnan eri osa-alueet kuten palvelut, prosessit ja service desk -toiminnon. Kaikilta koulutus- ja konsultointialueilta on myös laaja käytännön kokemus.

7. maaliskuuta 2019

Tervetuloa Knowit!


Tieturin asiakkaat pääsevät jatkossa nauttimaan myös Knowitin asiantuntijoiden osaamisesta koulutuksissamme. Knowit on konsulttiyritys, joka kiihtyvän digitalisaation aikakautena luo yksilöllistä arvoa asiakkaille kolmella eri liiketoiminta-alueella: Experience, Insight ja Solutions. Yrityksessä yhdistyy suunnittelu- ja viestintä-, liikkeenjohdon konsultointi- ja IT-osaaminen. Knowitilla työskentelee yli 2 000 työntekijää Ruotsissa, Norjassa, Suomessa, Tanskassa ja Saksassa. 

Tekoälyllä ja ohjelmistorobotiikalla on merkittävä rooli yritysten ja julkisen hallinnon digitalisaatiossa. Yhteistyömme Knowitin kanssa tuo tarjontaamme laajan kattauksen ohjelmistorobotiikan, tekoälyn ja koneoppisen koulutuksia. Yhteistyön myötä myös DevOps-tarjontamme monipuolistuu. Knowitin Jussi oli ensimmäinen sertifioitu DASA DevOps Product Owner -kouluttaja maailmassa. Hän on käynyt läpi koko DASA DevOps -koulutuspolun. DASA (DevOps Agile Skills Association) on yksi harvoja organisaatioita maailmassa, joka myöntää DevOps-sertifikaatteja.

Olen hyvin tyytyväinen, että saamme näin vahvaa osaamista mukaan jo ennestään vahvaan asiantuntijajoukkoomme. Etsimme jatkuvasti uusia koulutuskumppaneita taataksemme asiakkaillemme parhaat mahdolliset ajantasaiset koulutukset. 

Knowitin asiantuntijoiden pitkä koulutuskokemus testaus- ja laadunvarmistus-, ohjelmistorobotiikka- ja ohjelmistokehityspalveluiden valmennusohjelmista tuo loistavan lisän Tieturin kouluttajien osaamiseen. Tieturin tavoitteena on varmistaa Suomen vahva IT-osaaminen myös tulevaisuudessa. Tähän missioomme Knowitin asiantuntemus sopii enemmän kuin hyvin.

Tervetuloa siis mukaan, Knowit!

Tutustu uusiin kursseihin:

Ohjelmistorobotiikka
Keinotekoiset hermoverkot kehittäjille
Koneoppiminen data-analytiikassa


Anna Sahinoja
Tuoteryhmäpäällikkö, ICT

4. maaliskuuta 2019

Practices and capabilities in ITIL®4 - a critical view


In the new ITIL4 there is now less emphasis on processes and more on what is needed to get things done. [ITIL® is a registered trademark of Axelos Limited.] That’s a good thing. Many of the so-called ‘processes’ in ITIL V3 weren’t really processes anyway. While incident management certainly could be considered a process, many others didn’t fit within the definition.

Instead of processes and procedures, ITIL4 defines collections of abilities, skills, people, tools, etc. with specific responsibilities. We may need processes and specific procedures too, but it’s more interesting for a framework to define what needs to be done than to prescribe a particular way to do it. In a DevOps company they do things differently than in a traditional one, they will not use the same processes and procedures, but they may have the same set of capabilities.

What is a capability? For years enterprise architects have been interested in defining organizational capabilities. The “theory of the firm” sees an organization as a collection of capabilities. A capability is what a business needs to execute its strategy. Another way to put it is:

“A capability is an assembly of people, process, and technology for a specific purpose.”
 
(Ric Merrifield, Jack Calhoun and Dennis Stevens "The Next Revolution in Productivity")

ArchiMate defines it similarly and so does ASATE, adding brands and natural resource deposits to the definition.The standard Leonard-Barton view defines Capability management as identifying core capabilities that consist of physical technical systems, managerial systems, skills and knowledge, values and norms. Business capability modeling involves taking industry standard capability models as a basis for developing organization-specific capabilities, and if needed, break those down into specific processes, procedures, and activities.

In plain language: capability planning is defining the skills, resources, information, technology, culture, partners, etc. we need to accomplish whatever we are doing.

So far so good.

This is exactly what ITIL4 provides. A high-level capability model for service management, intended to be adapted to specific needs. Brilliant. Even beautiful.

For some unknown reason, the lead architects chose to call these collections of abilities, technology, etc. ‘practices.’ Not ‘capabilities.'

One wonders why.

One reason I saw in the advance material I reviewed was that the word ‘capability’ is too hard to translate and everybody will have a different view of what it means.

That’s obviously just a lot of Bravo Sierra.

Of course, it’s true that the word ‘capability’ has a lot of different meanings and may be difficult to translate, but that’s true for all words. It’s certainly true for the word ‘practice.’ So no, that is not the real reason.

Capability may for instance, depending on context, refer to only the “soft” dimension: skills, knowledge, and abilities, without the “hard” dimension: technology, systems, money and other resources. Or it may include, as in most business contexts, everything needed to be able of something. There is an easy solution - a definition. How about: “In the context of ITIL4, capability means a set of organizational resources designed for performing work or accomplishing an objective.”

Problem solved.

That would have been nicely aligned with TOGAF Capability-Based Planning and Business Capability Modeling, ASATE Business Capability Framework, and ArchiMate, to name a few.
Instead, ITIL4 chose the word ’practice,’ and created a much worse problem. What is a practice? How do you translate that?

COBIT 2019 defines a process as an organized set of practices and activities. ITIL4 now defines that processes are one of the dimensions of a practice. Merriam-Webster has a number of definitions for the noun practice. It may may refer to a usual way of doing things, as in ‘common practice’ or a systematic exercise for proficiency as in ‘practice makes perfect,’ but closest to the ITIL definition is ‘the continuous exercise of a profession,’ as in ‘a doctor’s practice.’ ITIL4 describes it this way:

“A practice is a set of organizational resources designed for performing work or accomplishing an objective. These resources are grouped into […] organizations and people, processes and value streams, information and technology, partners and suppliers.”

While I like that ITIL encourages establishing a set of practices, it’s a pity ITIL4 chose the term ‘practice’ over ‘capability.’ This would have been a perfect opportunity for ITIL to align the terminology with other business frameworks. To start talking about capabilities at the core of organizations.

To add to the conundrum, ITIL4 defines service management as “a set of organizational capabilities …” What? Wait! Suddenly we use the word ‘capabilities.’ These service management capabilities include the same four dimensions as practices (people, processes technology, partners).

Oh, well.

So, a ‘practice’ in ITIL4 is basically what everybody else in the industry calls a ‘capability.’ Except for the definition of service management where a ‘capability’ is what the rest of ITIL4 calls a ‘practice.’ In theory, according to ITIL, a practice is the same thing as a capability. In practice, it’s not. (That was intentional, haha)

OK, I can live with ‘practice.’ It would be cool, though, to know the real reason for this. Politics? Bad chemistry between lead architects? A compromise between conflicting views? Maybe there was a vote, and enterprise architects lost. We’ll probably never know.

We just have to get used to it. Adapt and adopt.

PS. Don’t get me wrong. I like the new ITIL. It has value. It’s adaptable and adoptable, as long as you take it with a grain of salt and try to understand the thoughts behind the words. Perhaps I shouldn’t complain. If ITIL were too consistent and easy to understand, there would be less demand for ITIL training. So maybe it’s in my best interest that it is what it is. But we do have a huge translation problem now.

Ben Kalland

Ben Kalland is Accrdited Trainer: ITIL4, COBIT5, TOGAF, LeanIT, Resilia. Axelos ITIL subject matter expert

28. helmikuuta 2019

Digimurros: Alustatalous muokkaa yritysstrategioita


Useat yritykset ajattelevat, että digimurros on vanhojen IT järjestelmien korvaamista uusilla pilvipalveluihin pohjautuvilla digitaalisilla ratkaisuilla. Tämä onkin osittain totta, mutta oikeastaan digimurros on paljon enemmän kuin teknologian korvaamista uusilla tehokkaammilla ratkaisuilla.

Todellinen muutos ei liity pelkästään olemassa olevien työtapojen, palveluiden tai tuotteiden tehostamiseen, vaan täysin uuden digitaalisen liiketoimintamallin käyttöönottoon. Puhumme usein tällöin liiketoimintamallista, joka perustuu alustatalouteen (engl. Platform Economy, Ref. 1).

Alustataloudessa yritysstrategiat eivät keskity yrityksen omien sisäisten ongelmien ratkomiseen, vaan oman alustatalous -ekosysteemin elinvoimaisuuden varmistamiseen. Yrityksen rooli ekosysteemissä (ks. kuva alla) muokkaa myös yrityksen liiketoimintastrategiaa. Kun tämä strategia on selvillä, se sanelee pitkälti myös miten yrityksen digimurros kannattaa laatia.

Kysymyksiä, joita kannattaa alustatalousstrategiassa asettaa:
  • Mihin alustatalouden ekosysteemeihin yritykseni kannattaa kuulua?
  • Mikä yritykseni rooli kyseisissä ekosysteemeissä olisi?
  • Kannattaako panostaa omien toimintatapojen tehostamiseen, vaiko ostaa resursseja/palvelua muilta ekosysteemin yrityksiltä?
  • Kannattaako tiettyä palvelua/tuotetta tuottaa vaiko tehdä se yhteistyössä muiden alustatalouden tekijöiden kanssa?


Kuva 1. Alustatalousekosysteemin eri roolit.

Alustatalous ilmiönä tulee muokkaamaan yritysten liiketoimintastrategioita ja siten myös sitä, miten digiteknologioita kannattaa omassa toiminnassaan hyödyntää. Ei ehkä ole järkevää ratkaista kaikkia kipupisteitä, jotka liittyvät yrityksen tämän hetkiseen toimintaympäristöön. Järkevämpää voi olla ehkä keskittyä tuottamaan vain tiettyjä palveluja ekosysteemissä tai ”liittoutua” toisen ekosysteemin yrityksen kanssa ja miettiä omaa lisäarvoa heidän toimintansa kannalta.

Tällaisen alustatalousajattelutavan sisäistäminen voi olla vaativaa, varsinkin, jos on tottunut näkemään muut yritykset pelkkinä kilpailijoinaan. Täytyy kuitenkin muistaa, että perinteiset kilpailijaympäristötkin muuttuvat parhaillaan. Uudet start-up:it, joista et ehkä tiennyt mitään viime vuonna, voivat ensi vuonna olla kovimpia kilpailijoitasi. Tai yritykset, jotka tähän asti ovat toimineet muilla palvelun tai tuotannon aloilla, ovatkin laajentaneet toimintaansa sinun toimintasektorillesi. Digimurros on siis paljon muutakin kuin teknologioiden uudistamista. Kaikki kuitenkin lähtee omasta liiketoimintastrategiastasi ja siitä minkä roolin yritys valitseen missäkin alustatalouden ekosysteemissä.

(1) Reference: Digital Transformation Model: The First Step in Reinventing Your Company, Available at: https://cioexecutivecouncil.com/resources/digital-transformation-model-the-first-step-in-reinventing-your-company-cio-executive-council-pov/

PhD Riitta Bekkhus

Kirjoittaja on toiminut 25 vuotta IT-alalla – monissa eri tehtävissä, niin IT-strategioiden kuin liiketoimintaprosessien suunnittelussa ja optimoinnissa. Tehnyt väitöskirjassaan digimurroksen hallintaan konseptin, jolla yritykset pääsevät helposti alkuun digimurroksensa systemaattisessa johtamisessa.

Osallistu myös ilmaiseen Mikä on onnistuneen digimurroksen yleisresepti? -webinaariin ja tutustu Digimurros haltuun tehopäivät -koulutukseemme.

25. helmikuuta 2019

Scrum Alliancella jo miljoona sertifikaattia

Scrum Alliance on saavuttanut tammikuussa 2019 yhden miljoonan sertifikaatin rajan. Vuoden vaihteessa Scrum Mastereita oli 717 953 ja Product Ownereita 192 929. Kasvu ja sen pitkä kesto on ollut hämmästyttävää.



 Kuva 1. CSM ja CSPO sertifikaatit 31.12.2018

En uskonut Scrumiin, kun ensimmäisen kerran törmäsin siihen jossain vuosituhannen vaihteen paikkeilla, koska he olivat myymässä lisenssejä menetelmän käytölle. Kuningasajatus, jolla tuotemerkin kasvu lähti liikkeelle, oli myydä Certified master titteleitä kahden päivän kurssin perusteella. Myi kuin häkä, sillä liiketoimintamalli sopi myös kouluttajille ja valmentajille, jotka muodostivat Scrum Alliancen.

Kun varhaisimmat omaksujat Suomessa (lue Nokia kumppaneineen) osoittivat mielenkiintoa aiheeseen, kävin USA:ssa hankkimassa CSM sertin 2006 ja sen jälkeen miestä vietiin. Tieturilla oli jo ennestään vahvaa ketteryyskoulusta, mutta yhden päivän Scrum osoittautui ilman sertifikaattiakin huippumenestykseksi. Ensimmäiset suomalaiset Scrum-kouluttajat, minä mukaan lukien, ilmestyivät markkinoille vasta 2009. Kysyntä nousi vastaamaan tarjontaa, kun paikallisia menestystarinoita alkoi kuulua puheissa ja mediassakin.

Ilman riitojakaan ei ole selvitty. Toinen Scrumin perustajista, Ken Schwaber, lähti Scrum Alliancesta ja perusti oman Scrum.org:n 2009.  Kysymys oli ja on kouluttajaksi pääsyn vaatimuksista. Allianssissa kouluttajalta vaaditaan vahvaa näyttöä Scrumin ja kouluttamisen osaamisesta ja mm. oman, itse tehdyn materiaalin käyttöä. Tässä käännepisteessä kasvu ohjautui Allianssiin, vaikka kouluttajien määrän lisääminen olikin huomattavasti vaikeampaa kuin ”kilpailijoilla”, joita alkoi syntyä markkinoille, joiden suojaaminen on käytännössä mahdotonta.

Seuraavaa uutta hypeä etsitään edelleenkin ja tuotemerkkejähän saa vapaasti perustaa. Lean ohjelmistokehitys ja Kanban olivat seuraava kiinnostuksen kohde. Ne sopivat tukiorganisaatiolle, mutta niistäkään ei syntynyt Scrumin korvaajaa, vaikka minullakin on tänä keväänä ohjelmassa Kanban käytännössä.

Kaikki ei onnistu Scrum Alliancellakaan. Ohjelmistotekniikkaan keskittyvä Certified Scrum Developer on jäänyt lapsipuolen asemaan. DevOps on aivan viime aikoina vahvemmin esiin pulpahtanut brändi, joka yhdistää Lean perusteoriaa ja pilvipalvelujen teknologiaa. Itse koen teknologian vaihtoehtojen määrän ja muutosvauhdin liialliseksi kouluttajille ja konsulteille.

Nykyään kaikki haluavat perustaa oman skaalausmallinsa. Valikoimaa löytyy ja se aiheuttaa sekaannusta. Scrum toimii luonnostaan monen tiimin tehdessä yhtä tuotetta. Pitkään ajateltiin, että se riittää. Scrum on laajennettavissa olevat kevyt viitekehys. SAFe oli pitkään Scrum Allianssin kumppani ja näkyvästi mukana Allianssin kokoontumisissa. Käytännön kokemukset raskaasta skaalauksesta johtivat pelkoon ketteryyden ja Scrum maineen menemisestä. Niinpä kevyemmät skaalausmallit, LeSS ja Scrum@Scale ovat nyt tulleet myös Scrum Allianssin listoille. 

Scrum Allianssi on siis viime aikoina laajentanut kurssivalikoimaansa. Sinne on tullut mm. ketterä johtajuus, Agile Leadership ja advanced tasot Scrum Masterille ja Product Ownerille. Ne ovat myös omassa ohjelmassani, toistaiseksi ilman sertifikaatteja.

Scrum Allianssin missio työn maailman muuttamisesta etenee vahvasti. On menty IT alan ulkopuolelle ja oikeasti kansainväliseksi. Allianssin kouluttajien hyväksyntälautakunnan (TAC) pitkäaikaisena jäsenenä koen suurimmaksi haasteeksi pätevien kouluttajien ja yritysvalmentajien löytämisen ja kouluttamisen. Scrum on yksikertainen, mutta vaikea toteuttaa oikein. 

Pentti Virtanen

PhD, Computer Science
Senior Consultant
Tieturi

Pentti on Scrum Alliancen hyväksymä kouluttaja. Tieturilla hän vetää mm. Certified ScrumMaster ja Certified Scrum Product Owner -koulutuksia.

19. helmikuuta 2019

Digimurros: Miten välttää digitaalinen umpikuja?



Digimurroksesta toitotetaan, mutta mikä on digitaalinen umpikuja (engl. Digital Deadlock)? IDC -konsulttiyrityksen tutkimus digimurrosten etenemisestä 1 500:ssa yrityksessä eri puolilta maailmaa osoitti, että 58 % yrityksistä on ns. digitaalisessa umpikujassa (ks. kuva alla). 

Tulokset ovat todennäköisesti hyvin samankaltaisia Suomessa. Useat suomalaiset yritykset ovat kyllä jo tehneet kokeiluja uusilla digitekniikoilla, mutta mitään systemaattista suunnitelmaa digiteknologioiden käyttöönotosta ei vielä ole tehty. Digimurrosta ei siis vielä osata hallita tai erityisemmin hyödyntää sitomalla se osaksi yrityksen laajempaa liiketoimintastrategiaa.















Kuva 1. Digimurroksen eri asteet.

Heikon digimurros -johtamisen vaarana on joko ns. Kaaos -efekti tai Lukkiutumis -efekti, koska digimurros ei ole osa yrityksen laajempaa liiketoimintastrategiaa.

Kaaos -efektissä digikokeiluja tehdään siellä täällä. Päällekkäiset kokeilut maksavat rahaa, eivätkä työntekijät ymmärrä, miksi kokeiluja ylipäätään tehdään. Vaarana on, että kokeilut jäävät pelkiksi kokeiluiksi, eivätkä saa suurempaa jalansijaa yrityksen sisällä. 

Lukkiutumis -efekti taas viittaa siihen, että nykyistä IT-ympäristöä kyllä ylläpidetään, mutta uusille digikokeiluille ei näytä riittävän rahoitusta, ja vielä vähemmän kiinnostusta. Vaarana tällöin onkin, että yritykset jäävät auttamattomasti jälkeen kilpailijoista, joilla on parempikatteisia ja asiakasta paremmin palvelevia tuotteita. 

Miten siis päästä eteenpäin ”digitaalisesta umpikujasta”?
Yleispäteävänä ohjeena voisi antaa: Paluun ”takaisin juurille”. Miettiä, mitä yritykseltä vaaditaan, jotta se selviäisi jatkossakin muuttuvassa kilpailijaympäristössä.

Tämä helpolta kuulostava lause sisältää paljon. On esimerkiksi mietittävä ylemmällä tasolla yrityksen roolia uusissa alustatalousyhteisöissä eli ekosysteemeissä. Ei ehkä ole järkevää panostaa omien toimintatapojensa alituiseen tehostamiseen, jos resursseja tai välituotteita voi ostaa joltain toiselta saman ekosysteemin yritykseltä. Entä yhteistyö? Kannattaisiko tiettyä palvelua tuottaa jatkossa yhteistyössä jonkun uuden start-up:in kanssa, vaiko satsata oman osaamisensa kehittämiseen. 

Vasta kun liiketoimintastrategia on selkeä ja mukautettu uuteen digitaaliseen kilpailijaympäristöön, on aika miettiä, miten uusia digiteknologioita kannattaa omassa toiminnassaan hyödyntää. Uusia digiteknologioita valittaessa (oli ne sitten pilvipalveluita, mobiilipalveluita, AI:ta, IoT:tä, data-analytiikkaa, ohjelmistorobotiikkaa jne) on kuitenkin ensin ymmärrettävä, millaisia liiketoimintaongelmia niillä voi ratkoa.

Muokatusta liiketoimintastrategiasta siis valitaan ja priorisoidaan ne tavoitteet ja kipupisteet, joita digiteknologioilla voi ylipäätään ratkoa. Lopuksi näiden valintojen pohjalta luodaan vaihe vaiheelta etenevä digimurrossuunnitelma (engl. Digital Masterplan). Digimurrossuunnitelma siis kertoo, mitä liiketoimintatavoitteita mitkäkin digiprojektit yrittävät ratkoa. Se myös kertoo, miten digimurros vaikuttaa yrityksen ei-teknisiin osa-alueisiin.

Digimurrossuunnitelmaa tehtäessä onkin kysyttävä: Tarvitaanko uusia mittareita? Entä nykyiset työroolit, pitäisikö niitä muuttaa? Työohjeet? Entä milloin kannibalisoida vanhat tuotteet uusien tieltä? Entä miten ottaa käyttöön kokeilukulttuuri? Budjetointimekanismit digikokeiluihin? Asiakkaan rooli? Työntekijöiden sitouttaminen ja motivointi? Osallisuus uusiin alustatalouden ekosysteemeihin?

Muutos ei tapahdu yhdessä yössä, mutta mitä aikaisemmin ymmärretään, että digimurros lähtee elinvoimaisesta liiketoimintastrategiasta, sitä nopeammin yritys pääsee tehokkaasti hyödyntämään uusia digiteknologioita. Sinne tänne hutkiminen tai kaikesta digikokeilusta kieltäytyminen pitää yrityksen vain tiukasti ”digitaalisessa umpikujassa”.

PhD Riitta Bekkhus 

Kirjoittaja on toiminut 25 vuotta IT-alalla – monissa eri tehtävissä, niin IT-strategioiden kuin liiketoimintaprosessien suunnittelussa ja optimoinnissa. Tehnyt väitöskirjassaan digimurroksen hallintaan konseptin, jolla yritykset pääsevät helposti alkuun digimurroksensa systemaattisessa johtamisessa. 


Katso myös Digimurros haltuun tehopäivät -koulutuksemme. 
 

14. helmikuuta 2019

Luuletko, ettet ole kyberhyökkäyksen vaarassa?




Vuosien ajan Kiina ja USA ovat olleet napit vastakkain, ensin kauppatalouden kanssa ja nyt kyberturvallisuuden. USA syyttää useita kiinalaisia yhtiöitä, erityisesti Huaweita, käyttäjiensä tiedon välittämisestä valtion haltuun.

Kiinalaisten epäily ei rajoitu vain kännyköiden turvallisuuteen. Joulukuussa USA syytti kiinalaisia “massiivisesta hakkerointikampanjasta”. Huawein perustajan tyttären Meng Renzhengin epäiltiin huijanneen pankkeja Iranissa toimimaan USAn Huawein vastaisia pakotteita vastaan.

Länsimaiden media tuntuu selkeästi puoltavan USA:a. Jopa Suomessa on alettu pelätä Huawein käyttöä.

Tämä kaikki nostaa esiin kysymykset kyberturvallisuudesta.  USA:n vastareaktio kiinalaisten hakkerointikampanjoihin on tietenkin USA:n hakkerointikampanja takaisinpäin. Jos kaksi maailmanvaltaa aloittaa hakkerointikampanjat, kuka enää on turvassa internetissä?

Kyberyhteiskunta uhkineen on vielä tuntematon suurimmalle osalle koko maailman väestöstä. Puhutaan yhteiskunnasta, johon pääsee käsiksi 3 miljardia ihmistä, eli kaikki, joilla on pääsy internetiin. Siellä tapahtuvat rikokset ovat kyberrikoksia. 

Kyberyhteiskunnassa peli on sama kuin normaalissa yhteiskunnassa – säännöt vain ovat erilaisia. Oikeastaan, niitä ei ole tarpeeksi. Lainsäädäntö on jäljessä kyberyhteiskunnan tuomiin haasteisiin, valtiot ovat jäljessä, päättäjät ovat jäljessä. Puhutaan villistä lännestä, jossa on jopa oma valuuttansa – kryptovaluutta.

Ketkä tässä yhteiskunnassa siis ovat rikollisia? Hakkerit eli kyberrikolliset. Kuka sitten on heidän takanaan? Useat tiedustelupalvelut, tietoturvapalvelut sekä valtion toimijat. Heillä on aina kohdekirjastot, joihin hyökkääminen aiheuttaa kaaosta. Kaaos taas aiheuttaa poliittista painetta, joka vaikuttaa poliittisiin päätöksiin. Puhutaan myös hybridisodasta, jossa käytetään digitaalista maailmaa, jotta oikeassa maailmassa saadaan aikaan vahinkoa.

Toki on myös yksin toimivia hakkereita – villissä lännessä ei tarvita organisaatiota tukemaan toimintaa. Yksi kybermyytti, joihin yritykset uskovat, on se, että kaikki hyökkäykset ovat kohdennettuja hakkerointikampanjan tavoitteita, vaikka todellisuudessa se voi olla yksittäisen toimijan tekosia.  

360 Cyber Academyn johtaja Pertti Jalasvirta puhuu siitä, miten teknisistä heikkouksista on tulossa heikompia ja heikompia: bluetoothin yleistyvä käyttö, wifi ja automatisaatio tuo kyberrikollisille paljon uusia mahdollisuuksia. Dronet eli suomalaisittain pienoiskopterit ovat yleistymässä. Jopa 100 eurolla voi saada tarkkoja kuvia ottavan pienoiskopterin. Pienoiskopterit voivat myös ottaa lähes millaisen muodon vain, ja näin vakoilla jopa yksittäisiä henkilöitä. Jalasvirta kehottaakin kehittämään yksilöllisen kyberturvastrategian.

Jalasvirta mainitsee myös seminaarissa, että yrityksellä kestää noin 99 päivää huomata, että heidän järjestelmiinsä on hyökätty. Kyberhyökkääjiltä taas kestää noin kolme päivää saada haltuun pääkäyttäjän oikeudet.

Ciaran Martin, Kansainvälisen Kyberturvallisuuskeskuksen johtaja sanoi Euroopan Tietoturvakokouksessa Lontoossa, että on yhä yhtiöitä, jotka uskovat, etteivät ole kyberhyökkäyksen vaarassa. Tosiasiassa kuka vain, joka toimii tietoteknologian avulla, voi joutua kohteeksi.

Ihminen on suurin kyberturvariski yrityksellesi, ja se, kuinka suuri riski hän on, riippuu hänen kyberturvatietämyksestään. Kyberyhteiskunta vaatii meitä vastaamaan sen tuomiin haasteisiin, mutta ihmiset eivät tiedä asiasta tarpeeksi. Alakouluissa opetetaan lapsia koodaamaan, mutta missä on kyberturvallisuusoppi? Henkilöstö tulisi aina kouluttaa niin, että he osaavat kyberturvan vaatimat toimintamenetelmät.

Tieturi vastaa uusiin haasteisiin lisäämällä kyberturvallisuuskursseja. Katso kurssit tästä 

Nelli Miettinen

29. tammikuuta 2019

Naiset eivät ole uusia koodausalalla



Koodausalan huutava pula osaajista ei ole enää jymyuutinen kellekään. Pelkästään Suomessa puhutaan 8 000 – 9 000 koodarin pulasta. Koodareita houkutellaan eri firmoihin rahalla, työsuhde-eduilla ja mielekkäillä työyhteisöillä. Ulkomailta toivotaan työvoimaa - muun muassa Piilaaksosta, Shanghaista ja Lontoosta tuntuisi tulevan hyviä kandidaatteja. Intialaiset koodaajat ovat myös kovassa huudossa.

Ollaan myös huomattu, että toinen puolisko maan väestöstä voisi olla kelpoisia koodausalalle.

Tutkimusten mukaan Suomen koodaajista vain joka viides, eli noin 20 % on naisia. Media uutisoi naisista, joiden unelmat tietokonealasta murskattiin jo varhain painostamalla heitä pehmeämmille aloille ”miesten alojen” sijaan. Nyt ajat ovat muuttuneet: naisia on alettu kannustaa tietokoneiden pariin. Mimmit koodaa-kampanja rohkaisee naisia ohjelmointialalle ja Linda Liukas perustaa koulun Helsinkiin. Yritetään murskata mielikuvaa pelkästään miesten alasta.

Koodaus ei kuitenkaan ollut alun perin vain miesten ala. Ensimmäisen algoritmin luoja oli 1800-luvulla elänyt englantilainen matemaatikko ja kirjailija Augusta Ada Lovelace, josta ei ole jäänyt paljoa historiankirjoihin. Lovelace on tunnettu ehkä eniten työstään Charles Babbagen, ”tietokoneiden isän”, suunnittelemaan, kuitenkin silloin toteuttamattomaan, keksintöön ”the Analytical Engine”. Tässä Analyyttisessä Moottorissa olisi ollut aritmeettinen logiikkayksikkö, se olisi ohjannut virtausta ehdollisen haarautumisen ja silmukoiden muodossa sekä siinä olisi ollut integroitu muisti. Toisin sanoen, suunnitellussa koneessa oli kaikki modernin tietokoneen elementit.

Lovelace ei kuitenkaan päässyt rakentamaan tietokonetta, sillä hän kuoli syöpään 36-vuotiaana, ja Moottorin luonnokset jätettiin syrjään, kunnes Alan Turing käytti niitä inspiraationa ensimmäisen tietokoneen luomiseen 1940-luvulla.

Naiset olivat mukana myös ensimmäisten tietokoneiden koodaamisessa. ENIACia (Electronic Numerical Integrator and Computer), yhtä maailman ensimmäisistä tietokoneista, koodasivat Kay McNulty, Betty Jennings, Betty Snyder, Marlyn Meltzer, Fran Bilas, ja Ruth Lichterman. Historioitsijat erehtyivät luulemaan heitä ensin malleiksi, jotka poseerasivat tietokoneen edessä. Suurin osa heistä ei saanut tunnustusta työstään elinaikanaan. Tuohon aikaan ohjelmoijan tai operoijan titteleitä ei oikeastaan nähty naisille sopivina, mutta toinen maailmansota oli luonut työvoimapulan, joka antoi naisille tilaa alalla. Koodausta ei silloin vielä nähty arvovaltaisena alana, joten naisten laittaminen sinne nähtiin niin, että miehille jäi siten vaativammat työt.

Ehkä se on osasyy siihen, miksi 70-80-luvulla naiset katosivat koodausskenestä kokonaan. Teknologiasta tuli merkittävämpää, ja huippuyliopistoista palkattiin matemaattisesti lahjakkaita miehiä suuriin yrityksiin viemään niitä eteenpäin kehityksessä.

Nyt, kun tasa-arvoa on ehditty ajaa eteenpäin jo vuosia ja pieneenkin sukupuolten eriarvoisuuteen yhteiskunnassa tartutaan, naiset pääsevät viimeinkin takaisin alalle. Ulkomailla koodaajissa on tasapuolisemmin molempia sukupuolia – Suomi laahaa tässä asiassa muuta maailmaa jäljessä. Perinteisiin on jälleen kerran tarrauduttu liian pitkään.  On hassua, ettei koodauksen alkuperää ole tuotu paremmin esille. Puhutaan mieluummin Bill Gatesista, Mark Zuckerbergista ja Satoshi Nakamotosta. Linda Liukas on nyt saanut kotimaassa ja maailmalla paljon positiivista huomiota. Ainut kritiikki Liukasta kohtaan tuntui vielä viime vuonna koskevan vain Hive-koulun yläikärajaa eli 30 vuotta – ja tämäkin oli positiivinen uutinen.

Mimmit koodaa-kampanjan, Liukkaan ja koodausalan kasvavien etujen luulisi houkuttelevan naisia enemmän ja enemmän alalle. Kasvava peliala ja neljäs teollinen vallankumous ovat myös omiaan saamaan naiset kiinnostumaan koodaamisesta.

Jos koodaus kiinnostaa, tsekkaa Tieturin ohjelmistokehityskoulutukset!


Nelli Miettinen

7. tammikuuta 2019

4 syytä tuotteistaa palvelu


Yhä suurempi osa yrityksistä tarjoaa asiakkailleen palveluita. Palvelut voivat muodostaa yrityksen koko liiketoiminta-ajatuksen tai täydentää olemassa olevia fyysisiä tuotteita tuoden lisäarvoa niille. Palveluliiketoiminta ei ole kovin vaikeaa. Sinun pitää vain osata ratkaista jokin asiakkaan ongelma. Lupaat asiakkaalle, että ratkaiset ongelman, teet näin ja laitat laskun perään. Helppoa, eikö!

Yllättävän monet yritykset toimivat juuri tällä periaatteella. Samaan aikaan yritykset törmäävät kuitenkin usein erilaisiin ongelmiin:

• Myynti on vaikeaa
• Asiakkaat eivät ymmärrä, mitä ovat ostamassa
• Palvelun toimitus takkuaa mm. epäselvyyksien vuoksi
• Lasku ei lähde tai rahat eivät näy tilillä

Ratkaisu näihin ja moniin muihinkin ongelmiin on palvelun tuotteistaminen. Miten tuotteistamisen avulla voidaan selättää yllä mainitut ongelmat?

Helppo myydä


Tuotteistetun palvelun myynti on helppoa, koska silloin niin toimitussisältö, myyntiesitys kuin asiakaslupaus ovat hyvin määriteltyjä. Tuotteistuksen olennainen alkupiste on määrittää, kuka on tuotteen asiakas, ja mikä on ongelma, jonka tuote ratkaisee. Tärkeää on myös selvittää, miksi kyseinen ongelma on vielä ratkaisematta.

Kun tuotteistamisprosessi on valmis, on myyjillä käytettävissä asiakaslupaus, myyntiesitys, hinnasto sekä muu tarvittava myyntimateriaali. Parhaassa tapauksessa asiakashyödyn voi esittää asiakkaalle suoraan euroina. Tämän jälkeen myyjän on helppo keskustella asiakkaan kanssa ja selvittää, kärsiikö asiakas ongelmasta, jonka voit ratkaista. Jos asiakas vastaa kyllä, on palvelun tarjoaminen suoraviivaista ja keskustelu asiakashyötyyn keskittyvää. Usein hintakeskustelut ja tinkaaminen voivat jäädä kokonaan pois. Kaupankäynti nopeutuu ja katteet nousevat, koska palvelun euromääräinen hyöty on osoitettavissa.

Helppo ostaa


Kun asiakkaalle kerrotaan selvästi, mitä hän on hankkimassa, ostaminen helpottuu. Ostaja tietää, minkä ongelman tuote ratkaisee, mikä on asiakaslupaus, paljonko tuote maksaa ja kuinka paljon hän saa hyötyä euromääräisesti tästä investoinnista.

Usein tuotteistukseen kuuluu myös takuu, joka vähentää ostamisen riskiä. Ostamisessa on viime kädessä kyse siitä, että asiakas luottaa sinuun ja arvioi hankintaan liittyvät riskit vähäisiksi tai olemattomiksi. Hyvin tuotteistettu palvelu on omiaan herättämään asiakkaassa luottamusta ja vähentämään ostamisen esteitä.

Helppo toimittaa


Palvelun toimitus voi kangerrella useasta eri syystä. Pahimmassa tapauksessa asiakas on ymmärtänyt väärin sen, mitä osti, eikä myyjä huomaa tätä. Pahimmillaan voi olla niin, että myyjä ei tajua, mitä myy. Tällaisessakin tilauksessa kauppoja syntyy silloin tällöin ja ongelmat alkavat viimeistään palvelun toimitusvaiheessa. Toimitus on epäselvä, aikataulut viivästyvät ja lopulta tilanne voi kärjistyä reklamaatioksi.

Yllättävän usein tällaisissa tilanteissa vika on yrityksen tuotteistuksessa, ei asiakkaassa. Hyvin tuotteistetun palvelun toimitusprosessi on selkeä, usein standardoitu ja sen kehittämisessä voidaan hyödyntää myös palvelumuotoilua. Tuotteistettu palvelu ja siihen liitetty jämäkkä toimitus takaavat sen, että asiakas saavuttaa parhaan arvon projektista ja myyjä saa tililleen kunnon katteen.

Helppo laskuttaa


Hyvin tuotteistettu palvelutuote on helppo laskuttaa ja asiakas maksaa laskun mielellään. Parhaassa tapauksessa asiakas maksaa osan hinnasta tai jopa koko hinnan etukäteen, jolloin laskutus nopeutuu ja kassavirta kasvaa. Hinnoitteluun ja laskutukseen on useita eri vaihtoehtoja ja ne ansaitsevat ihan oman kirjoituksensa. Tärkeintä tuotteistuksessa on laskutuksen kannalta se, että laskut lähtevät selkeästi tiettyinä ajankohtina tai palvelu maksetaan jo etukäteen esim. verkkokaupassa.

Voi siis sanoa, että hyvin tuotteistettu palvelutuote on helppo myydä, helppo ostaa, helppo toimittaa ja helppo laskuttaa.

Pidän tuotteistuksesta ja hinnoittelusta kahden päivän koulutuksen Tieturilla ensimmäisen kerran 21. - 22.3. Tule mukaan hakemaan käytännön eväät tuotteistamiseen, jotta myös sinä saat helpotusta liiketoimintaan ja täytettä tilille.

Petri Eklund

Petri Eklund on oululainen yrittäjä, joka on aikaisemmalla työurallaan tehnyt useita palvelutuotteistuksia työnantajilleen, toiminut ohjelmistoyrityksen tuotepäällikkönä ja opiskellut tuotteistamista niin suomalaisista kuin kansainvälisistä lähteistä. Nykyisin Petri toimii yrittäjänä ja tarjoaa tuotteistamisen ja hinnoittelun koulutuksia, verkkokursseja ja tuotteistamisprojekteja oman yrityksensä sekä yhteistyökumppanien kautta. Hänen koulutustensa tavoitteena on tarjota koulutukseen osallistujille mahdollisimman konkreettiset ja toimivat keinot tuotteistamiseen ja hinnoitteluun. Koulutukseen osallistujat saavat parhaat mahdolliset eväät viedä opit käytäntöön omissa yrityksissään.

3. tammikuuta 2019

Kärsitkö sinäkin teknologiapelosta?


Eduskunnan tulevaisuusvaliokunta on nostanut ”Suomen sata uutta mahdollisuutta 2018-2037, Yhteiskunnan toimintamallit uudistava radikaali teknologia” -julkaisussaan 10 tulevaisuuden megatrendiä. Yksi niistä on arvomaailman kehitys ja maailman kokemus, jonka alle kuuluu mm. näkemys, että teknologiapelot kasvavat tulevaisuudessa.

Teknologiapelolla tarkoitetaan kehittyneen teknologian tai monimutkaisten laitteiden pelkoa tai inhoa. Pelon juuret yltävät kauas teollisen vallankumoukseen alkuun, kun koneet mahdollistivat tehokkaamman ja edullisemman tuotannon ja vähensivät siten osaavien ammattilaisten tarvetta.

Teknologia on kehittynyt huimasti noista ajoista. Päivittäin käyttämämme teknologia on yhä monimutkaisempaa sekä automatisoidumpaa, ja sen ymmärtäminen vaatii syvällisempää perehtymistä. Harva meistä pystyy enää korjaamaan rikkoutunutta autoa tai ymmärtää tietokoneiden toimintaa. Iso osa teknologiapelkoa onkin kontrollin menettämisen pelko.

Uusi teknologia onkin varsin autonomista ja pystyy tekemään itsenäisesti erittäin laajoja kokonaisuuksia ja syväoppiva tekoäly pystyy etenemään kohti uusia ratkaisuja. Demonstraatioissa tekoäly kykenee mm. tunnistamaan ihmisten tauteja, pelaamaan itselleen ennestään tuntemattomia videopelejä ja jopa löytämään tieteellisiä läpimurtoja. Robotiikan kehitys etenee kohti toiminnallisten moduulien välisiä rajapintoja ja robottien sekä tekoälyn kehitys kulkevat käsikädessä.

Koneet kykenevät nopeasti ja vaivattomasti sopeutumaan uusiin tarpeisiin. Vielä voidaan kuitenkin sanoa, että ihminen oppii huomattavasti harvemmista havainnoista, sillä monimutkaisissa tehtävissä tekoäly ei ole täysin oppinut vielä miljoonankaan havainnon jälkeen. Toisaalta tekoäly käsittelee yksittäiset havainnot nopeammin ja sen osaaminen on monistettavissa.


Teknologia - uhka vai mahdollisuus


Teknologian kehitys on herättänyt keskustelua siitä, viekö robotisaatio ja tekoälyn kehitys ihmisten työpaikat. Osa suorittavasta työstä tulee vähenemään tai loppumaan teknologisen kehityksen myötä, mikä vapauttaa henkilöstön aikaa luovempiin kehitystehtäviin, joihin tekoäly ei kykene vielä pitkään aikaan. Samalla robotisaatio luo täysin uusia, robottien työn mahdollistavia tehtäviä, kuten robottiturvallisuuden tarkastaja, robottivakuutusarvioija, robottityönjohtaja, robottikouluttaja, ja robottityön suunnittelija.

Teknologinen kehitys tuo meille uskomattomia mahdollisuuksia, joita on aikaisemmin voitu vain kuvitella Sci-Fi -hengessä. Teknologian tuomat mahdollisuudet ulottuvat lähes kaikille elämän ja liiketoiminta-aloille terveydenhoidosta henkilö- ja tavaraliikenteeseen, energiataloudesta koulutukseen, teollisesta tuotannosta viihdeteollisuuteen ja palveluliiketoimintaan.

Teknologiset innovaatiot auttavat ratkomaan maailmanlaajuisia ongelmia. Niiden myötä pystytään tuottamaan puhdasta vettä alueilla, joilla siitä on huutava pula sekä hyödyntämään uusiutuvaa energiaa yhä kustannustehokkaammin ja monipuolisemmin. Ruokaa voidaan kasvattaa tiiviisti ja energiatehokkaasti sisäviljelyllä ja myös eläinsolujen viljely ja geenimanipulaatio helpottavat ruokapulaa. Terveydenhoidon saralla kehitetään laajalla skaalalla ratkaisuja ja apukeinoja aina hermostoon kytkettävistä robotisoiduista jalka- ja käsiproteeseista keinoelimiin ja Alzheimeria parantaviin ultraäänihoitoihin. Autonomisesti kulkevat robottiautot ja etäohjattavat kopterit edistävät edullista logistiikkaa, ja laajennettu ja virtuaalinen todellisuus helpottavat niin kirurgin kuin hissiasentajankin työtä sekä tuovat uuden suunnan viihdeteollisuuteen.

Teknologia tuo monia mullistuksia arkeemme yhä kiihtyvällä tahdilla. Muutoksen nopeus voi tuoda omat riskinsä, mutta kehitys mahdollistaa monien suurtenkin ongelmien ratkaisun. Työelämä ja -tehtävät muuttuvat muutoksen myötä, joten elinikäinen oppiminen on yhä tärkeämpää. Teknologiapelkoon ei liene syytä, jos katsoo avoimin mielin tulevaisuuteen ja on valmis elämään mukana muutoksessa.

Tarja Kinnunen

Suositut tekstit