Norrin

Marraskuussa 2016 Geoffrey Hinton sanoi Torontossa, että radiologien kouluttaminen kannattaa lopettaa. Viidessä vuodessa kone lukisi kuvat paremmin kuin ihminen. Kymmenen vuotta myöhemmin radiologeista on pulaa. Mayo Clinicillä heitä on yli 400, noin 55 prosenttia enemmän kuin silloin. Miksi? Kuvantamisesta tuli halvempaa, joten sitä tehdään moninkertaisesti enemmän, ja jonkun pitää yhä katsoa epäselvät tapaukset ja kantaa vastuu. Olen elänyt digitalisaation murrosta jo yli 30 vuotta. Joka kerta kun uusi teknologia on levinnyt, se on vienyt työtä ja tuonut uutta työtä. Kukaan ei ole kertaakaan osannut sanoa etukäteen, mitä tilalle tulee. Nyt tätä tapahtuu tekoälymurroksen junioreille. Alallamme kone jo vie aloittelevalta insinööriltä sen käsityön, jolla alalle on tultu. Juuri siksi uusia osaajia on vaikea kouluttaa valmiiseen tehtävään, vaan täytyy rakentaa oppimisen alusta, jossa oppiminen tapahtuu työn sisällä samaa tahtia kuin työ muuttuu. Sellainen Norrin Akatemia on. Juniori on projektissa ensimmäisestä viikosta, oma oppimispolku kulkee työn rinnalla ja mentorina on kokenut tekijä. Ensimmäinen ohjelma päättyi alkukesästä. Kuusi ihmistä jäi taloon vakituisiin tehtäviin, osa data engineerinä, osa AI-työn parissa. Jos olisin nyt uran alussa, en lukitsisi katsettani siihen, mitä nyt tehdään, tai mikä katoaa. Seuraisin, mihin kysyntä siirtyy, ja suuntaisin sinne. Työ vain muuttuu mielenkiintoisemmaksi.

How can we get children with different backgrounds to play together, and how can we get people with different backgrounds to work toward a common solution? What is the basis of a service company’s value creation? Expertise. What is the foundation of experts’ expertise? Education and experience. What determines the choice of those paths? Choices guided by personality. Whenever we build a new service offering, we break down the solution into areas of expertise. What competencies are needed to deliver the promised value together with the customer? For example, when building digital services, we identified three layers: data, application, and user interface. These are not three technical layers, but three distinct groups of experts who often even represent different personality types. Let's exaggerate it a little for the sake of the example. We recognize all the engineers who work with data, respect the process, and strive to meet the given goals: the foundation builders. Developers are curious experimenters whose work is well described by the term “agility.” Constant communication, constant development, constant tuning :) At the forefront are creative designers. They prioritize usability, humanity, and a human touch. Then you assemble a team from these individuals and ask them to work seamlessly toward a common goal. That is the most difficult task of leadership. In AI projects, the situation is exactly the same. Finland excels at engineering work. Usability is well understood, and the specifications are creative. There is broad acceptance of new tools. Even leadership is engineering-driven and thus understandable to a machine. Bringing these elements together into a single team is the point where most projects fall short. That’s why we talk about creative engineering.

“Can you prove the ROI of your organization’s AI projects with actual numbers?" We put this question to the audience at CxO Industry 2026 during our presentation. The answers: “Not yet” — 52% “In some cases” — 48% “Yes, with numbers” — 0% Where would you place yourself on this scale? In 2027, this is the question that defines the enterprise AI agenda. AI investments are expected to show real value, in numbers. Boards and leadership teams want to know what business benefit AI delivers, and the same question sits firmly on CFOs’ agendas. Measuring the ROI of AI is already a priority for more than a third of CFOs. In my view, proven ROI doesn’t come from a single clever solution. It comes from an AI portfolio that is built and managed systematically, where value is measured by the impact on the cost, quality and outcome of the whole business process. In the new NorrInsights article, I break down how to build that portfolio in practice, verify the business value and scale the solutions that work into the business. https://lnkd.in/eXVnB7Tw

Ensimmäinen asia, jonka teimme suomalaisen tehtaan tekoälyhankkeessa, oli sanakirja. Hämeen murteesta suomeksi, suomesta englanniksi. Sen päälle talon oma slangi, jota kukaan talon ulkopuolella ei ymmärrä tai ei ainakaan internetin-aineistolla koulutettu tekoäly. Sanakirjaan meni aikaa. Kehittäminen tuntui hitaalta, kunnes AI:lle saatiin kaikki tarvittava. Tekoälyhankkeet kaatuvat nykyään harvoin mallin "älykkyyteen". Yleisin syy on konteksti. Ja konteksti on tietoa, jota kukaan ei ole välttämättä kirjoittanut mihinkään. Voit testata tämän tänään. Ota yksi työtehtävä ja yritä tehdä se pelkästään sillä dokumentaatiolla, jonka teillä on. Ei omaa taustatietoa, ei oletuksia, ei sitä, mitä satut muistamaan. Jos tehtävä onnistuu, tietoa on riittävästi ja se pitää ainoastaan saada käyttöön. Jos ei onnistu, loput on jonkun päässä. Sen kaivaminen esiin on työ, joka täytyy tehdä jotta ratkaisu voi toimia. Montako kohtaa jouduit täydentämään omasta päästäsi?

Tein aikanaan väitöskirjani palveluliiketoiminnan johtamisen perusteista. Silloin nousi esiin teoria nimeltä Service-Dominant Logic ja sen ydintermi "value co-creation". Rakensimme Norrinin kulmakivet sisältä päin. Teimme kyselyt henkilöstölle ja kysyimme asiakkailta. Niistä vastauksista löytyivät ne asiat, jotka meillä oikeasti erottuvat. Yhtymäkohta johtamisen jatkumoon oli heti selvä. Value co-creation kuvasi sitä, miten Norrinissa jo tehdään töitä. Asiakkaan kanssa yhdessä, ei asiakkaalle. Siksi siitä tuli yksi kulmakivi. Teorian ydinajatus on yksinkertainen, mutta kääntää koko organisaation asetelman: tuotteet myydään, mutta palvelut ostetaan. Palveluliiketoiminnassa toimittaja on se, jonka tarjooma sovitetetaan asiakkaalle, tuoteliiketoiminnassa asiakas on se, joka joustaa. Tuotejohtamisen tehokkuus perustuu toistettavuuteen, palvelujen osaamisenhallintaan. Tuoteliiketoiminnassa arvo "työnnetään" organisaation läpi, palveluliiketoiminnassa se "vedetään" asiakkaan kanssa yhdessä jatkuvasti sovittavan määrittelyn mukaisesti. Ero näkyy käytännössä: iltaisin haet verkkokaupoista Sinua miellyttäviä tuotteita; puhelimia, kuulokkeita tai vaatteita. Mutta lääkäripalvelua tai vakuutuspalvelua hankkiessasi haet SInulle sopivimman kokonaisuuden, mieluiten vielä sovitettavan. Ja silloin minun, palvelutoimittajan, pitää olla se ketterä osapuoli. Ei asiakkaan. Tätä value co-creation tarkoittaa kauneimmillaan palvelubisneksessä. Tämä on se liima, joka sitoo toimittajan asiakkaaseen. Kun se tehdään oikein, koko organisaatio muuttuu asiakasohjautuvaksi, ei -läheiseksi. Tehdään sitä, mitä asiakas oikeasti tarvitsee, huomioiden hänen olemassa olevat osaamisensa ja kyvykkyytensä. Siitä syntyy yhteinen tapa tuottaa arvoa. Tämä vaatii laajan osaamiskirjon hallintaa, mutta mahdollistaa jatkuvan yhteiskehityksen. Paras merkki kulmakivestä on se, että henkilöstö tunnisti tavan omakseen jo ennen kuin sille löytyi nimi.

Teollisuudessa ei ole Ctrl+Z:aa. Liikaa kemikaalia prosessiin? Se ei lähde sieltä itsestään pois. Joku joutuu tekemään töitä, tai laatu on jo mennyt. Miten siis tuodaan IT-maailmasta tekoälyä tuotantoon ja luodaan siellä oikeasti arvoa? Rakennamme paperitehtaille järjestelmiä, jotka ohjaavat koneita. Avaa venttiili, sulje venttiili. Lisää vettä, hidasta. Panokset ovat tässä eri luokkaa kuin raportointiprojektissa. Tuotannon kannalta ei ole väliä, pettikö yhteys vai yskähtikö malli. Väliä on vain kokonaistoimintakyvyllä. Agile toimii, kun virheestä voi palata. Tehtaalla ei aina voi. Siksi kehitämme ratkaisuja kypsyystasojen kautta: Tunnistetaan ilmiöt datasta. Suositellaan toimenpiteitä, joita ihminen voi seurata tai olla seuraamatta – näistä opit talteen! Kun järjestelmä on todistetusti toiminut, automatisoidaan. Toistaiseksi, kielimallit ja agentit auttavat meitä käyttöliityminä, ymmärtämään dataa ja kehittämään alla olevia järjestelmiä. Ohjauslogiikan pohjalla ovat edelleen tilastot ja säännöt. Rakettia ei tehdä agilena.