Surffasin ympäri verkkoa ja osuin hämmästyneenä lauseen äärelle, jossa mainittiin että sovellus toteutetaan toiminnallisuuden eikä suinkaan toteutuksen kautta. Jäin pohtimaan, että mitä muuta kautta järjestelmä voidaan toteuttaa kuin sen toiminnallisuuden kautta.
Lukiessani lausetta jäin pohtimaan asiaa eli mitä ihmettä lauseessa sanottiin. Eikö sovellukset toteuteta aina tarpeeseen vai luodaanko ensin tekninen sovellus jolla luodaan tarve. Lause on todellisuudessa fiksu eli siinä muistutetaan siitä, että sovelluksen tarkoitus tuoda lisäarvoa ja tukea toimintaa.
Surffasin ympäri verkkoa ja osuin hämmästyneenä lauseen äärelle, jossa mainittiin että sovellus toteutetaan toiminnallisuuden eikä suinkaan toteutuksen kautta. Jäin pohtimaan, että mitä muuta kautta järjestelmä voidaan toteuttaa kuin sen toiminnallisuuden kautta.
Lukiessani lausetta jäin pohtimaan asiaa eli mitä ihmettä lauseessa sanottiin. Eikö sovellukset toteuteta aina tarpeeseen vai luodaanko ensin tekninen sovellus jolla luodaan tarve. Lause on todellisuudessa fiksu eli siinä muistutetaan siitä, että sovelluksen tarkoitus tuoda lisäarvoa ja tukea toimintaa.
Samasta asiasta eilen juttelin yhden mukavan rouvashenkilön kanssa ja siellä pohdimme sitä, mistä tietojärjestelmän kehitys lähtee. Eli kehityksen pitää lähteä tarpeesta eikä suinkaan teknisestä toteutuksesta, johon tarve sovitetaan.
Ajatus on loppujen lopuksi aika yksinkertainen, mutta useinkin ongelmia ratkaistaan juuri tuolta takakautta eli teknologian taivuttamisen sijaan prosessi taivutetaan tukemaan teknologiaa. Ja usein prosessia ei uskalleta taivuttaa, koska me tegnologiagurut väitämme ettei sitä pystytä toteuttamaan.
Leania autotehtaalla
Joskus olen katsellut tuotteiden kokoonpanoa lattiatasolla eli kuinka syntyy jokin osakomponentti. Työpiste ja työ on suunniteltu niin, ettei virheitä voi syntyä. Ruuvien, muttereiden ja muiden komponenttien määrä on aina vakio. Työpöydällä ei ole muita työkaluja kuin tarpeelliset ja prosessin järjesteys on suunniteltu ennakkoon. Eli prosessi on suunniteltu mahdollisimman virheettömäksi. Eli asiaa voitaisiin pohtia poka yokena eli virheitä estävän järjestelmänä.
Eli tehtaan lattiatasolla pitää pyrkiä siihen, että tuote lähtee liikkeelle virheettömänä ja määrämuotoisen prosessin kautta. Eli epänormaaliudet löytyvät jo tekovaiheessa eikä suinkaan vasta pitkän ajan päästä jälkitarkastuksessa.
Eli työtehtävät suunnitellaan niin, ettei virheitä voi syntyä. Samaa ideaa voi käyttää muussakin elämässä eli kehittää tuotteita ja prosesseja niin, ettei niiden käytössä voi syntyä virheitä. Tyypillinen esimerkki samasta poka yoke- ideasta on esimerkiksi puhelimen sim- kortti, eli sitä ei voi laittaa värrin paikalle yhden kulman viistoamisen takia.
Softan vääntäminen lähtee kuitenkin liikkeelle teknologiasta
On mielenkiintoista, että uuden liiketoimintaa tukevan sovelluksen toteuttaminen lähtee kuitenkin pääsääntöisesti liikeelle teknologiasta. Eli käytetään sitä teknologiaa mitä yrityksestä löytyy.
Luen aika paljon eri blogeja ja niistä saa aika usein samankaltaisen käsityksen eli asiakas on ostamassa ohjelmistokehitystä tai ohjelmistoa, mutta harvemmin hänelle myydään ratkaisua. Eli puuhun mennään teknologia edellä eikä suinkaan liiketoimintaa tukeva ratkaisu edellä.
Eli asiakkaan liiketoimintaongelma sovitetaan jo alkuvaiheessa teknologiaan, teknologiseksi ongelmaksi ja ongelma pyritään sovittamaan oikeaan järjestelmään. Niinkin yksinkertainen asia kuin esimerkiksi matkalaskujen tehokas käsittely lähtee jo ensimmäisissä palavereissa liikkeelle siitä, että toteutetaanko mobiiliratkaisu, webbiratkaisu vai joku hybridiratkaisu. Vai olisko tehokkainta vain tehdä excelillä asiat niinkuin ennenkin. Eli teknologiaa tupataan ratkaisuun ennenkuin edes tiedetään mitä ratkaistaan eli tunnistetaan prosessia.
Miten asia muuttuisi, jos lähdettäisiin liikkelle poka yoke- ajatuksesta eli siitä, että prosessi on luotava niin varmatoimiseksi ettei virheitä voi syntyä. Prosessia ja sen yksittäisiä vaiheita voidaan valvoa yksittäisillä indikaattoreilla ja vasta prosessin määrittelyn ja testaamisen jälkeen lähdetään liikkeelle pohtimaan toteutustekniikkaa. Eli ei anneta teknologian määritellä prosessia vaan prosessi määrittelee teknologian. Ihan samalla tavalla kuin siellä yksittäisessä kokoonpanopisteessä. Jos asentajalle annetaan vasara, niin hänen on pakko toteuttaa tuote naulaamalla tai niittaamalla. Mutta jos ensin pohditaan tuoteen toteutus, niin voidaan etsiä tehokkaimmat työkalut sen toteuttamiseen.
Älä osta ohjelmistokehitystä vaan ratkaisua
Telkkaria ostettaessa myyjä yleensä myy katselunautinnon sijaan hd-telvisiota, joka on vaikkapa led-tekniikalla toteutettu ja varustettu laajoilla liitännöillä erilaisiin av- laitteisiin. Ostaja sen sijaan ostaa katselunautintoa ja laitetta, jonka saa kiinni kotiteatteriin. Eli hän ei osta teknologiaa vaan ostaa laitetta, joka varmatoimisesti esittää liikkuvaa kuvaa.
Softanostajankin pitäisi ostaa samalla tavoin ratkaisua omaan ongelmaansa kuin telkkarin ostajan. Eli hän ei osta teknologiaa ja vaan toivivaa ratkaisua, jolla hänen ongelmansa ja tarpeensa täytetään. Eli jos kyseessä on rajapinta, joka palauttaa maksukorttiososten kirjanpitotiedot määrämuotoisena, niin hän ostaa ratkaisun joke tekee sen. Tai jos tarpeena on pystyä raportoimaan kentältä omat tunnit tai muut kulut realiaikaisesti, niin hän ostaa järjestelmän jolla asia hoituu.
Mutta hän ei osta maksukorttiostosten kirjanpitotietojen toteuttavaa järjestelmää, joka ratkaistaan JavaEE- ympäristössä käyttäen MySQL/MongoDB- kantoja tai osta iPadissa toimivaaa natiiviohjelmaa, jolla on langaton yhteys pilvipalveluun. Hän ostaa ratkaisun, joka ratkaisee tarpeen. Eikä suinkaan teknistä toteutusta, joka saattaa ratkaista kyseisen tarpeen.
Lyhyesti sanottuna, määritellään mitä ratkaistaan ja miten prosessi toimii. Ja sovitetaan teknologia tukemaan ratkaisua. Eikä suinkaan soviteta prosessia teknologian mukaan.
Kuhan pohdin, Kari…
Kari Vahtolammi
Kirjoittaja on hiukan yli viisikymppinen yrittämisestä, opiskelusta (TTY) ja psykologiasta kiinnostunut it-alan ammattilainen.
www.karivahtolammi.com
