Tuoko toiminnan keskittäminen aina tehokkutta?

Suurin osa IT toimintojen tehostamisesta ja kustannussäästöistä perustuu siihen, että tuottavat yksiköt ovat mahdollisimman suuria ja palvelevat mahdollisimman monia asiakkaita. Toinen säästämisen keino on se, että yksiköt tuottavat mahdollisimman yksinkertaista ja helposti monistettavaa palvelua jolloin on mahdollista keskittyä laadun parantamiseen prosessien avulla. Mikäli tehtävät ovat liian monipuolisia ja mitattavat suoritukset jakautuvat keskenään ristiriitaisiin mittareihin on väistämättä edessä klappia prosessiin.

Miten tämä voisi pukea esimerkkiin… mikä olisikaan parempi esimerkki kuin koko perheen suosikki mcdonals..(r)

McDonalds tunnetaan siitä, että se on vienyt prosessit äärimmäisen pitkälle. Kaikki ranskalaiset maistuvat aina samalta ja hampurilainen on aina samanlainen vaikka sen ostaisi mistä päin maailmaa tahansa *(huom. kulttuurierot ja uskonnolliset vakaumukset huomioiden toki) Jokaista pihviä paistetaan yhtämonta sekuntia ja jokaiseen hampurilaiseen tulee yhtämonta pisaraa ketsuppia jne. Eli työ on opetettavissa kenelle tahansa, joka on valmis tekemään töitä ja ottamaan ohjeita vastaan. No niin mitä voisimme oppia sitten tästä toiminnasta? Miten toimintaa voisi tehostaa entisestään? Tätä mietittiin pitkään ja huomattiin että prosessissa oli yksi ongelma. Se että sama ihminen vastasi tuotteiden pakkaamisesta ja mahdollisimman nopeasta asiakaskierrosta sekä tuotteiden myynnistä. Nämä tavoitteet ovat toisiensa kanssa ristiriidassa. Mitä enemmän hän myy, sitä pitempää ostotapahtuma kestää ja sitä pitempään asiakkas on talossa. Toisaalta, jos ei myy lisää niin myynti laskee vaikka asiakas kiertonopeus kasvaa. Miten voisi siis tehostaa oli se, että erotetaan tehtävät toisistaan, yksi ihminen vastaa siitä, että otetaan tilauksia vastaan ja toinen ottaa vastuulleen tuotteiden pakkaamisen, rahastamisen ja sitä kautta asiakaskierron nopeuden. Tämä toteutettiin niin, että kun henkilö ajaa drive in kaistalle ja puhuu tilaus “pömpeliin” niin puhelu ohjattiinkin suureen call centeriin, jossa tilaus otetaan vastaan, kirjataan ylös ja laitetaan takas pöpelin vieressä olevaan mcdonalsiin. Asiakas ei edes tiedä soittavansa tuhansien kilometrien päähän vaan kuvittelee puhuvansa viereiseen rakennukseen. No mitä tästä seurasi?

Ensinnäkin myynti kasvoi. Miksi? Nyt tilauksia vastaanottavia henkilöitä mitattiin ainoastaan keskiostoksen suuruuden mukaan, siksi he aina muistivat kysyä haluaako henkilö jälkiruokaa tai haluaako isommat ranskalaiset jne. Lisäksi myynti kokemus parani sillä tilausta vastaanottavalla ei ollut kiire minnekkään. Toiseksi: toimitusajat ja asiakaskierto nopeutui, koska henkilö joka vastasi rahastuksesta ja tavaroiden pakkaamisesta pystyi keskittymään siihen täysillä ilman kontaksia asiakkaaseen.

Seuraava kysymys onkin miten tätä voisi verrata esim. IT-puolella? Voisiko meille syntyä tarve tehdä Service Desk palvelu, jossa ei auteta teknisissä ongelmissa vaan autetaan ihmistä. Pidetään kädestä kiinni ja kannustetaan käynnistämään tietokone uudestaan. Tätä porukkaa voisi sitten mitata ainoastaan asaiakastyytyväisyydestä ja palautteiden määrästä. Toisaalta tekninen ihminen saisi keskittyä ratkaisememaan IT-ongelmia ilman asiakkaalle puhumista, mikä olisi varmaan monelle mieleen.

Onko organisaatiossasi tai yrityksessäsi muita tehtäviä joissa on tosiaan tuhoavat mittarit?

Permanent link to this article: http://www.praas.org/2011/03/23/tuoko-toiminnan-keskittaminen-aina-tehokkutta/

Google Could Connect for Microsoft Office.

Pakko ottaa hetki siihen, että voin kommentoida Google Cloud Connect for Microsoft Office tuotetta. Tuote tuo hyvän lisän Google Apps pakettiin tai yrityksille, jotka eivät ole aikaisemmin Google palveluita käyttäneet, mutta mitä sen avulla itseasiassa voi tehdä?

Oleellisin lisä vanhaan Google Apps ympäristöön on se, että nyt on helppo keino lisätä Micrsoft office tiedostot Google Docseihin. Ohjelmistoa voisihin kuvata oikeastaan varmistuspalveluksi. Helppo tapa varmistaa paikalliset Office tietodostot Google pilveen. Tiedostojen jakaminen onnistuu myös yhtä helposti, kuin tavallisten Google Docs tiedostojen osalta. Palvelun julkaisun myötä tuli myös mahdolliseksi ostaa lisää tallennustilaa helposti Google Apps ylläpito sivuilta.

Muutamia puutteita uudessa ohjelmistossa on, mutta helposti ennustettavissa on se, että puutteet tullaan korjaan lähiaikoina.

Hyvää:

  • Microsoft tiedostojen tallentaminen ja varmistaminen Google pilveen automaattisesti
  • Microsoft tiedostojen jakaminen helppoa ja mahdollistaa monipuoliset yhteistyön tiedostojen tuottamisessa
  • Uuden tiedoston tallentaminen suoraan Googleen on helppoa

Huonoa:

  • Tiedostot tallentuvat aina Google Docs hakemiston “juureen” ja labeleiden määrittely suoraan Office ohjelmistoissa ei ole mahdollista. Tarkoittaa, että jokaisen dokumentin arkistointi vaatii Google Docsin puolella käymisen
  • Olemassa olevan dokumentin avaaminen ja muokkaaminen vaatii, että tiedosto on tallennettu aina jonnekkin paikallisesti tai verkkolevylle, jotta sen saa auki. Eli Google Docs ei ilmaannu verkkolevyksi koneelle, jotta sieltä voisi avata dokumentteja kuten tavalliselta verkkolevyltä. Tarkoittaa myös, että olemassa olevaa dokumenttia, joka on synkronoitu Google pilveen ei pysty muokkaamaan Officen tuotteilla ennen kuin sen lataa omalle koneelleen.

Kenen kannattaa käyttää?

Kaikki, jotka eivät ole vielä luopuneet MS Office tuotteiden käyttämisestä, ja haluvat varmistaa tiedostot jonnekkin pilveen.

Henkilöt tai yritykset jotka eivät jaksa, osaa, pysty huolehtia varmistuksista. Tämän avulla huolehtimisen voi unohtaa.

Muunlaiseen käyttämiseen vaatii vielä kolmannan osapuolen tuotteita, joilla yllämainitut ongelmat voi taklata.

Googlen tuntien nuo mainitsemani puutteet tullaan varmaan korjaamaan vielä lähiaikoina, mutta seurataan tilannetta.

Tutuustu omalla koneella lataamalla päivitys:

http://tools.google.com/dlpage/cloudconnect

Permanent link to this article: http://www.praas.org/2011/03/18/google-could-connect-for-microsoft-office/

Prosessit, järjestelmähankinnat ja ROI…

Missä vaiheessa prosessien takaisinmaksuaika pitäisi alkaa. Miten voidaan varmistaa, että se kaikki energia mikä laitetaan toimintatapojen parantamiseen ja tehostamiseen ei johtaisi ainoastaan uuden järjestelmän hankintaan, vaan voisi itsessään olla jo kannattavaa toimintaa. Eli miten mitataan parannettujen toimintatapojen tuottama hyöty.

Usein uusien järjestelmien hankintaa perustellaan säästyneellä usein ajalla. Jos otetaan tämmöinen peruskoulu esimerkki ja ei liikaa mietitä yksityiskohtia niin. Esim. jos meillä on 100 työntekijää, jotka kaikki säästävät 6 minuuttia päivässä. Keskimääräinen tuntikustannus voisi olla vaikka 30€/työntekijä.  Niin silloin uuden järjestelmän tuottamaa säästöä syntyy seuraavasti: 100*(10/30€)*21päivää= 6300€/kk ja jos järjestelmä on maksanut vaikka 50 000€ niin silloin takaisin maksu aika on n. 8kk. Tämän jälkeen kaikki on selvää tuottoa.

Tässä mallissa on muutama oleellinen ongelma…

  1. Meillä ei ole mitään keinoa mitata, että nopeutuuko suoritettu tehtävä oikeasti tuon 6 minuuttia joka kerta?
  2. Oppimiskäyrä myös hidastaa optimaalisen käytön synnyttämää aikahyötyä, eli oikean ja tehokkaan tavan oppiminen vaatii aikaa .
  3. Miten olemme mitanneet, että meillä aikaisemmin meni tehtävän tekemiseen tuo 6 minuuttia pitempään. Johtuiko viive oikeasti huonosta/vanhasta järjestelmästä vai huonoista toimintatavoista eli prosessista?
  4. Onko uusi järjestelmä hidastanut toimintaa, jossain toisaalla vastaavasti 10 minuuttia?
  5. Nämä 100 ihmistä ovat kaikki kiinteällä kuukausipalkalla, joten todellista säästöä kustannuksissa ei synny vaikka tehtävän suorittaminen nopeutuisi

Miten nämä voidaan sitten taklata?

  1. Varmistetaan, että meillä on kerättynä riittävästi tietoa omasta toiminnasta ja omista prosesseista. Emme voi uskoa ainoastaan myyjän argumentteja siitä, että heidän järjestelmänsä mahdollistaa asioiden tekemisen x minuuttia nopeammin. Mittausta voidaan tehdä muutaman päivän ajan vaikka manuaalisesti mikäli automaattista mittausta ei ole saatavilla. Tämäkin jo parantaa huomattavasti kannattavuuden laskentaa
  2. Järjestelmän testauksen yhteydessä pitäisi pystyä testaamaan todellisia käyttötarkoitusta varten ja huomioida kuinka pitkään menee saada toiminta optimoitua. Eli pienellä koeryhmällä tämä on mahdollista testata muutamissa tunneissa, muutaman päivän aikana, mikäli asia on suunniteltu oikein.
  3. Kun mittaamme toiminnan tehokkuutta, voisimme samalla arvioida itse prosessia eikä pelkkää järjestelmää. Olisiko meillä mahdollista säästää jopa enemmän kuin 6 minuuttia jos toimisimme hieman eri tavalla kuin tähän asti? Onko tarpeellista vaihtaa järjestelmää, jos vastaava aika säästö saadaan sillä, että toimintoja automatisoidaan tai pudotetaan kokonaan pois. Varmistetaan, että emme tee asioita vain vanhasta tottumuksesta.
  4. Eli pitäisi olla näkymä kaikkiin prosesseihin ja toimintoihin joita uusi järjestelmä koskettaa. Eli jos uusimme laskutusjärjestelmä sähköiseksi ja nyt laskuttajilla säästyy jokaisessa laskussa monta minuuttia, mutta toisaalla kaikki muut sata työntekijää joiden pitäisi generoida laskuaineisto projektijärjestelmästä joutuu tekemään nyt tupla-määrän työtä vanhaan verrattuna, niin säästö on syöty negatiiviseksi ennen kuin toiminta on edes kunnolla alkanut…
  5. Eli todellista rahallista säästöä tai edes tehollista hyötyä ei synny, jos noita säästyneitä minuutteja ei voida kohdentaa oikein. Joko lisääntyneeseen tuotantoon tai kasvaneeseen myyntiin. Jos kaikilla vain hommat nopeutuisi 6 minuuttia ja se vietetään tupakalla tai kahvilassa niin säästöä ei voi syntyä. Siksi suosittelen, että järjestelmähankintaa ei edes saisi mitata säästyneinä minuutteina ellei ole suoraan osoittaa tuota kasvua myynnissä tai tuotannossa.

Takaisin maksu olisikin mitattava aina kasvaneena tuotantona tai lisääntyneenä myyntinä. Eli yksi ihminen pystyy tekemään samalla ajalla ja samalla hinnalla enemmän kuin aikaisemmin ja tämä laskenta on tuo takaisinmaksun perustan.  Vaatimuksena tässä on että:

  • Tunnetaan prosessi ja tiedetään mikä vaikuttaa myyntiin ja tuotantoon. Pitäisi tietää tuottaako uusi järjestelmä jotain sellaista, mistä asiakas on valmis maksamaan enemmän kuin aikaisemmin? Eli mitataan toimintaa ja kerätään todellista aineistoa. Dokumentoidaan toimintatavat.
  • Tuoko muutos lisää  myyntiä tai tuotanto tehokkuutta. Mikäli järjestelmä hankinta ollaan tekemässä vain toiminnan tehostamiseksi, oletus on, että aika vastaava säästö voidaan saada pelkästään toimintatapoja muuttamalla, ilman järjestelmä hankintaa.

Jos tavoitellaan 6 minuutin säästöä jokaiselle työntekijällä, voisi ehdottaa hissin käyttökieltoa siirryttäessä alle kolme kerrosta kerrallaan. tällöin syntyy säästöä jo monta minuuttia päivässä, koska ei tarvitse odotella hissejä. Toisaalta voidaan laatia niin, että tupakka taukoja on käytettävissä vain x kappaletta päivässä tai kaikki tulostaminen pitää tehdä keskitettyyn paikkaan, josta se jaetaan henkilöille muun postin yhteydessä. Kenenkään ei siis tarvitse käydä hakemassa tulosteita itse. Tutkitaan prosessia ja mietitään onko siinä jotain tehtävää mikä perustuu tiedon kopioimiseen paikasta x paikkaan y ja automatisoidaan tämä… Keinoja on lukemattomia ilman järjestelmä hankintaa. Yksinkertaisilla työntekijäohjeistuksilla tai työvaiheiden automatisoinneilla päästään samaan tai jopa parempaan tulokseen kuin suurella it-projektilla, mutta täysin ilman riskejä.

Kerää siis tietoa, miksi jotain järjestelmää ollaan hankkimassa! Mitä sillä tavoitellaan ja mitkä ovat suunnitellun muutoksen vaikutukset muuhun toimintaan.

Rene Rendic

 

Permanent link to this article: http://www.praas.org/2011/03/13/prosessit-jarjestelmahankinnat-ja-roi/

Prosessien kehittäminen ja järjestelmähankinnat…

Prosesseilla ja järjestelmähankinnoilla on kieroutunut suhde. Mitä pahemmin toimintatavat ovat sekaisin, sitä monimutkaisempaa järjestelmää lähdetään etsimään ongelman ratkaisuun. Ajatus pitäisi olla juuri päinvastoin. Meidän pitäisi pystyä mallintamaan prosessia ja pilkkomaan sitä pienempiin osiin, joita voisi sitten alkaa palastelemaan yksinkertaisilla toteutuksilla. Näin voisimme varmistaa prosessimme toimivuuden jo ennen suurta järjestelmä hankintaa. Tavoitteena olisi kerätä dataa ja informaatiota järjestelmä hankinnan tueksi. Jos saamme kevyellä järjestelyillä hieman älyä toimintatapoihin sekä kerättyä tietoa olemme jo aimo harppauksen lähellä todellista prosessien kehittämistä, emmekä taas uudessa IT-järjestelmä projektissa.

Prosessien tehostaminen ei onnistu järjestelmähankinnalla. Prosessien tehostaminen tarkoittaa muutosta vanhoihin toimintatapoihin. Usein kuvitellaan, että jos jokin toiminto ei ole riittävän tehokasta tai toivotaan siihen muutosta, niin ei lähdetä kehittämään itse prosessia asiantuntijoiden kanssa vaan lähdetään etsimään hyvää ohjelmistoa ICT-asiantuntijoiden kanssa. Tämän avulla päästään helposti tilanteeseen, jossa saadaan järjestelmä, joka tukee kohtalaisesti huonosti toimivia toimintatapoja. Toinen lopputulos on, että toimintatavat muokkautuvat uuden järjestelmän mukaisiksi.

Nykyään on lähesmahdotonta saada kilpailuetua pelkän järjestelmän avulla. Aito kilpailuetu syntyy toimivista proseseista, joiden avulla järjestelmistä ja palveluista saadaan otettua kaikki tehot irti. Järjetelmän tuomat edut on kurottu umpeen muutamissa kuukausissa, jos etua edes syntyy. Aidosti tehokastoimintapa, joka kehittyy jatkuvasti voi tarjota kilpailuetua aina. Ei siis väliä minkä järjestelmän valitset ja oli se kuinka edistyksellinen tahansa, se kopioidaan aina. Aidosti toimivaa toimintatapaa eli prosessia on huomattavasti vaikeampaa kopioida. Sitä ei voi asentaa ja käntää päälle vaan se vaatii aidosti ihmisten toiminnan ohjaamista, seuraamista ja ohjeistamista.

Jos jokin asia ei toimi, muista seuraavat asiat:

  • Uusi tietojärjestelmä ei korjaa viallista toimintatapaa
  • Ei toimivan-asian ulkoistaminen ei tee tuotoksesta parempaa
  • Prosessien kehittäminen ja jalkauttaminen pitää aloittaa vaihe/tehtävä kerrallaan ilman järjestelmä sidoksia
  • Prosessien kehittäminen on jatkuva prosessi, jota uuden järjestelmän täytyy tukea
  • Parhaidenkäytäntöjen kopioiminen omien prosessien pohjaksi, esim. ITIL-prosessit, on hyvä alku, mutta ne pitää aina kohdistaa omaan ympäristöön sopivaksi

 

 

 

Permanent link to this article: http://www.praas.org/2011/03/09/prosessien-kehittaminen-ja-jarjestelmahankinnat/

Ketterä/Agile IT-projekti…

Mitä tarkoittaa ketterä-projekti. Ketterästä eli Agile ohjelmistokehityksestä on puhuttu ja toteutettu jo vuosia. Aiheesta on kirjoitettu hyllymetreittäin kirjallisuutta ja tuntuu, kuin kaikki ohjelmistokehitys tapahtuisi nykyään äärimmäisen ketterästi. Samalla innolla ketteriä menetelmiä ei olla kuitenkaan otettu vastaan perinteisessä projektihallinnassa. Tai itse järjestelmien käyttöönotoissa. Eli ihmiset ja organisaatiot kykenevät äärimmäiseen ketteryyteen, kun on puhe ohjelmoinnista ja järjestelmien kehittämisestä, mutta jos projekti onkin suunnattu palvelemaan asiakasta tai käyttäjäryhmää niin kaikki ketteryys katoaa kuin taikaiskusta.

Takaisin alkuperäiseen kysymykseen, “Mitä tarkoittaa ketterä projekti?”. Nyt ei siis ole kysymys ohjelmiston kehityksestä vaan, mistä tahansa projektista.  Projektin tunnustaa siitä, että niillä kaikilla on kolme vakiota. Niillä on alku, keskivaihe ja loppu eli aikataulu. Toinen vakio kaikissa projekteissa on Resurssit, eli rahaa, tekijöitä ja muita tarpeita. Kolmas on  Ominaisuudet, mitä yritämme projektin aikana saamaan valmiiksi. Tämä ei koske ainoastaan ohjelmisto projekteja vaan aivan kaikkea. Talon rakennuksessa ominaisuus voisi olla lasitettu terassi tai lasittamaton terassi.

Yleensä ketteryys projektissa häviää, koska projekti pyritään suunnittelemaan mahdollisimman tarkasti. Mitä tärkeämpi projekti, sitä enemmän suunnitellaan. Suunnittelu on tärkeää, mutta jos suunnittelusta tulee tärkeämpää, kuin tavoitteista tai projektin loppuunsaattamisesta niin mennään jossain vaiheessa pieleen.

Keinot millä voi varmistaa ketterän toteutuksen. Suunnitelaan siihen pisteeseen, että saadan vastaukset seuraaviin kysymyksiin:

  • Julkilausuma: Projektin tavoite yhdellä lauseella, jolla annetaan vastaus ominaisuuksiin, aikaan ja resursseihin
  • Vakioiden priorisointi: Ominaisuudet, Aika ja Resurssit eli kun tulee valinnan paikka, niin mikä antaa periksi ja mistä pidetään kiinni.
  • Omistajuus: Ketä haluaa projektin onnistuvan. Kenellä on eniten intoa nähdä projektin tulokset maalissa. Kenellä on valta tehdä päätökset projektin lopettamisesta, jatkamisesta ja rahoittamisesta.
  • Linkitys ja motiivit: Miksi projekti on käynnissä ja olemassa. Mihin tavoitteisiin projektin tuotokset liittyvät. Täytyy tietää milloin projekti pitää tai voidaan lakkauttaa.

Kun lista on valmiina, niin päästetään projektisuunnitelmista irti. Kun ongelmia tulee vastaan, niin oheisen listan avulla osataan arvioida mitä pitää muuttaa. Mitkä ovat prioriteetit, kun on valinnan paikka. Listaa tarvitaan siksi, koska kaikissa projekteissa tapahtuu jotain yllättävää. Vaikka olisi kuinka hieno projekti prosessi, aina tulee poikkeuksia tai yllätyksiä. Vaikka olisi kaikkiin poikkeuksiin olemassa keinot ja metodit niin niiden käyttäminen vaikuttaa suoraan suunnitelmiin.  On mahdollista toimittaa laatua jokaisessa projektissa, mutta se edellyttää ketteryyttä.  Se edellyttää, että on metodit joilla taistella poikkeamia vastaan ja riittävä luottamus projektijohtoon, että se osaa kiireen ja paineen alla olla valita oikein.

Project timeline

Projektiaikataulu

 

Permanent link to this article: http://www.praas.org/2011/03/03/ketteraagile-it-projekti/

Prosessit ja Arvot, mitä tekemistä niillä on toistensa kanssa?

Lähes kaikilla yrityksillä löytyy nykyään Arvot, joita ainakin julkisesti esitellään yrityksen kotisivuilla ja erilaisissa firman tilaisuuksissa. Monet yritykset puhuvat myös omista prosesseistaan. Mikä yhdistää arvoja ja prosesseja?

Toimintaohjeet muuttuvat prosessiksi siinä vaiheessa, kun käytössä on keinot mitata suorituksia ja tulosten avulla voidaan ohjata tuotoksen maaliin. Prosessi ilman mittareita ei ole prosessi, vaan pelkkä kasa dokumentteja tai vielä pahempaa, kuten diplomi yrityksen seinällä.



Arvoista voisi taas sanoa, että yriksen todelliset arvot näkyvät yrityksen valinnoissa ja toiminnan suunnittelussa. Jos arvot ovat vain klassista sanahelinää, mitä täytyy jokaisella yrityksellä olla, koska kaikilla muillakin on arvot, niin silloin ei ole kyse todellisista arvoista. Arvot syntyvät organisaation sisästä.

Sekä prosessit ja Arvot saa toimimaan halutulla tavalla, eli suuntaamaan yrityksen toimintaa ja valintoja haluttuun suuntaan. Täytyy vain olla keinot seurata ja mitata molempia. Helpoiten se onnistuu valitsemalla mittarit, jotka ohjaavat tekijät ja asiantuntijat valitsemaan oikein.  Ei saa siis mitata asiaa, joka halutaan tapahtuvaksi, vaan usein meidän täytyy mitata sitä asiaa jokanka tekeminen johtaa haluttuun tulokseen. Yksinkertaisella esimerkillä voisi sanoa, että jos halutaan, että jalkapallojoukkue tekee maaleja, ei pitäisi laskea pelkkiä maaleja. Pitäisi mitata pallonhallinta aikaa, syöttöjen määrää ja niiden onnistumis prosenttia, laukauksia maalia kohtia jne. Eli usein mittarina on maalimäärä ja ihmetellään, että emme saa prosessin tuotosta maaliin tai ihmisiä toimimaan yrityksen arvojen mukaan. Eli rupeamme mittaamaan maaliin johtavia asioita. Mitataan ja seurataan niitä valintoja, ei ainoastaan lopputuloksia. Jos Arvot ovat jotain, mitä voidaan mitata ja jos yksittäisiä prosessi toteutuksia voidaan arvioida suoraan mittareista niin toiminta ja valinnat kääntyvät kuin itsestään maalia kohti. Tämä kuitenkin edellyttää, että mittarit ovat tekijöiden tiedossa ja tavoitteiden laatijat tietävät mikä toiminta tai valinta johtaa arvojen mukaiseen toimintaan, jotta mittarit osataan valita oikein.

Permanent link to this article: http://www.praas.org/2011/02/28/prosessit-ja-arvot-mita-tekemista-niilla-on-toistensa-kanssa/

IT-päällikkö ostoksilla…

Kun yrityksssä mietitään uutta tuotannonohjausjärjestelmää (ERP), asiakkuudenhallintajärjestelmää (CRM), projektihallintajärjestelmää tai vastaavaa niin, jossain vaiheessa pallo lentää IT-päällikön nurkkaan.

Miksi tilanne on näin. Yksi syy on tästä saattaa olla siinä, että liiketoimintajohdon on helpompi päästä vastuusta, jos hankinta laitetaan jonkun toisen tehtäväksi. Tätä enemmän uskon kuitenkin siihen, että järjestelmä hankintaa ei ole mahdollista tehdä ilman laajaa teknistä osaamista. Sinänsä asia on kummallinen, sillä ollaan kuitenkin tehostamassa liiketointaa, mutta ostaja ei itse tiedä tapahtuuko niin. Voisiko mitenkään olla mahdollista myydä ominaisuuksien tilasta tuloksia?

IT-päällikkön ostoksille lähtemisessä ei sinänsä ole mitään pahaa, mutta mikäli IT-päällikkö pääsee lähtemään sinne yksin niin silloin ostoksen tavoitteet ja prioriteetit tod. näk. muuttuvat hyvin radikaalisti. Eli IT-päällikkön tärkein tehtävä on yleensä pitää koneet käynnissä, varmistaa ettei virheitä tapahdu ja muutenkin toiminta pysyy vakaana. Ei näillä eväillä lähdetä mitään kovin erilaista hankintaa miettimään.

  1. Halutaan, että järjestelmä on mahdollisimman pienellä vaivalla integroitavissa olemassa oleviin järjestelmiin.
  2. Halutaan, että vastaavista toteutuksista on olemassa referenssit vastaavilla toimialoilla
  3. Halutaan, että IT-budjetti ei räjähdä käsiin heti hankinnan yhteydessä

Sinänsä nämä kolme toivomusta ovat ihan hyödyllisiä, mutta sillä myös tapahtuu seuraavaa:

  1. Rajataan teknologiset vaihtoehdot minimiin. Pysytyään tutussa ympäristössä, eikä liikaa vilkuilla mitä sivulta on tulossa
  2. Varmistetaan, että osa kilpailijoista on jo tehnyt saman virheen. Tämän avulla on mahdollista perustella päätöstä myös jatkossa. Ei ole mahdollista myöskään saada kilpailuetua tätä kautta jos jo muutamat tärkeimmät kilpailijat ovat valinneet saman polun.
  3. Budjetoinnissa lasketaan vain hintaa eikä osata ottaa huomioon uusien ominaisuuksien/prosessien tuomaa kustannus säästöä tai tuotannon lisäystä. Ei siis lasketa todellista ROI arvoa vaan mietitään mitä itse järjstelmä maksaa. Rajaa teknisesti edistyneemmät vaihtoehdot pois ja pakottaa usein myös toimittajat hinnoittelemaan omat tuotteensa kovin innovatiivisesti.

Ehdotankin, että IT-päällikköä ei saisi päästää yksin kauppaan lainkaan, tai vielä parempaa jos voisi jättää IT-päällikön kokonaan vahtimaan olemassa olevaa ympäristöä. Eli palvelu, joka ollaan ostamassa olisi verifioitavissa tuloksien mukaan eikä teknisten ominaisuuksien mukaan. Jos hankitaan CRM järjestelmää/palvelua pitäisi sopimuksessa olla ehto, että myynti kasvaa 5% tietyllä aika välillä tai jätettyjen tarjousten hitrate kasvaa x% jne. Tällöin valinnan voisi tehdä vain ja ainoastaan liiketoimintajohto. Valinnan jälkeen sitten IT-päällikkö tulee mukaan toteutukseen.

Pisteet kotiin sille, joka tunnistaa ensimmäisen riskin tässä mallissa…

Permanent link to this article: http://www.praas.org/2011/02/21/it-paallikko-ostoksilla/

CRM vai enemmän myyntiä?

Jos myyntijohtajalta kysyy edellä mainitun kysymyksen: “Haluatko hankkia uuden CRM-järjestelmän vai kasvattaa myyntiä?”, niin käytännössä myyntijohtaja aina haluaa lisää myyntiä, mutta silti tuntuu kovin usein ostavan CRM järjestelmän.

Mikä on CRM? Customer Relationship Management. Suomeksi siis Asiakkuudenhallintajärjestelmä.

Kovin usein yritykset miettivät keinoja tehostaa myyntiä tai ainakin seurata sitä paremmin. Tämä tietenkin tarkoittaa sitä, että hankitaan asiakkuudenhallintajärjstelmä. Nykyiset asiakkuudenhallintajärjestelmät ovat vain tyypillisesti tekemässä kaikkea muutakin käyttäjän puolestaa.

Mitä, jos et tarvitsekkaan asiakkuudenhallintajärjestelmää vaan pitäisi saada seurattua myyjien aktiviteetteja. CRM ei tuo autuutta, sillä sinne pitäisi jotenkin taianomaisesti saada tiedot tuotua myyjien päästä. Siihen kun vielä lisätään järjestelmä, joka ei vastaa odotuksia tai tarpeita CRM alkaa olla valmiina käyttöön… vanha klassinen sarjakuva järjestelmän speksausta  aina piristää mieltä.

Tuossa sarjakuvassa paras kohta on mielestäni tuo viimeinen kuva. Eli Asiakas olisi tarvinnut aivan jotain muuta mitä itse pyysi toimittamaan. Miksi siis pitäisi järjestelmätoimitusten yhteydessä keskustella asiakkaan kanssa? Mitäs jos toimitettaisiin vain keinu jota pääsee käyttämään muutamassa päivässä, ja asiakas voi keinua siinä ensimmäiset kuukaudet ilmaiseksi. Sitten asiakas oikeasti näkisi mitä järjestelmä tekee ja mitä itse oikeasti tarvitsee. Tätä yritetään erilaisilla try&buy ja ilmaisilla ensimmäisillä kuukausilla. Ongelmana näissä on se, että ilmainen koeaika menee siihen että palvelun saa konffattua valmiiksi. Mitä pitäisi sanoa, jotta ihminen olisi valmis kokeilemaan valmista toimivaa prosessia? Tässä voissi olla mukava kokeilla PraaS mallilla toimivaa myyntiprosessia. Soisi suoraan käyttöön hyväksi havaitun tavan seurata myyntiprosessia ja se on käyttöönotettavissa muutamassa päivässä. Ja jos ei kelpaa voi lakata käyttämässä.

Rene

Permanent link to this article: http://www.praas.org/2011/02/18/crm-vai-enemman-myyntia/

Mitä on Process as a Service eli PraaS

Process as a Service on evoluution seuraava vaihe kaiken maailman XaaS ajattelussa. Vaihe, jossa “pilvestä” voidaan hankkia tuloksia ominaisuuksien sijaan. Voidaan hankkia haluttu lopputulos version sijaan.

PraaS on verrattavissa klassiseen porakone vertaukseen. Sanotaan, että henkilö, joka on ostamassa kaupasta porakonetta ei tarvitse poraa vaan aukon seinään. Tässä vaiheessa meille ilmeisty erilaiset vuokrauspalvelut, kuten Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS),  jne… Sanoisin kuitenkin, että henkilö ei halua edes aukkoa seinään, vaan haluaa saada vietyä johdon toisenpään makuuhuoneen telkkariin, jotta kaapeli lähetys näkyisi myös siellä. Eli henkilö ei halua poraa, ei halua aukkoa seinään vaan haluaa katsoa telkkaria makuuhuoneessa. Tätä on PraaS. Voit ostaa eri televisio kanavia näkyviin suoraan makuuhuoneeseen ilman, että tarvitsee miettiä mitä kautta kuva sinne tuodaan. Ja siinä vaiheessa kun ei enää kiinnosta katsoa niin ilmoitus vain ja kuva katoaa, ilman jälkiä rakenteisiin.

Yritämme tuoda esimerkkejä toteutuksista ja ajatuksia nykyaikaisesta prosessikehityksestä, -seurannasta ja ohjauksesta, jota voidaan tehdä Pilvessä.

Permanent link to this article: http://www.praas.org/2011/02/15/mita-on-process-as-a-service-eli-praas/

» Newer posts