Continue reading »]]> Lähtötilanne

Sattuneesta syystä olen päässyt miettimään paljon non-profit (voittoatavoittelemattoman) organisaation markkinointia. Miten tuoda tälläisen organisaation sanoma esille, silti halventamatta sen kohdetta.Näihin teemoihin liittyy usein myös vahvat aatteeliset periaatteet jotka usein mielletään rahan vallan ja rahan tarpeen ulkopuolelle. Vaikka todellisuudessa nämä kaikki atteet ja toiminnot tarvitsevat aivan yhtä paljon ellei jopa enemmän rahoitusta kuin muu toiminta. Miten siis taistella näitä lähtöasetelmia vastaan.

Asenne muokkausta

Ensimmäisenä tulee mieleen tietenkin, että pitää osoittaa mihin tätä rahaa tarvitaan. Miten se on tehokkainta osoittaa? Yleensä kerrotaan mitä on aikaisemmin tehty tai saatu aikaiseksi. Esim. Kirkon ulkomaan apu (KUA) tai Punainen Risti pitää sivuilla roppakaupalla tietoa projekteista mitä ne ovat tehneet ja saaneet aikaiseksi tai mihin kriisiin ne ovat parhaillaan osallistumassa. Tähän on tullut muutos tai oikeastaan täsmennys, eli enää ei riitä todisteet siitä, että jotain on juskus saatu aikaan. Halutaan tietää mitä seuraavaksi tehdään tai vielä tarkemmin, että mihin juuri minun rahani menevät. Siksi onkin tullut mahdolliseksi erilaiset hyväntekeväisyys kaupat, joissa voi ostaa vaikka vuohia tai vastaavaa. Lahjoittajalle jää se tunne että minun rahani menivät juuri tuohon yhteen vuoheen.

Tällä pyritään vähentämään yhtä suurimmista oston esteistä eli “hyväntekeväisyyteen annetut rahat eivät oikeasti mene sinne mihin niitä annetaan vaan menee kaiken maailman palkkioihin ja hallinnon kuluihin.”…

Tuntuu kuin järjestöt olisivat tunnistaneet suurimmat esteet omien asiakkaiden osalta ja lähteneet niitä taklaamaan. Rupesin vielä miettimään mikä on se seuraava este lahjoitukselle??? Lisää tästä myöhemmin.

Continue reading »]]> Otsikko tarkoittaa sitä, että projekti johtaminen ja projektinhallinta työkalut ovat kehittyneet hurjaa vauhtia viimeisinä vuosina. Näitä työkaluja, metodeja tai prosesseja ei kuitenkaan osata käyttää tai niihin ei yksinkertaisesti ole resursseja. Aina on niin kiire saada projekti valmiiksi ettei voidan testata tai on niin pieni budjetti, että “roll back” ei ole ongelmien sattuessa ole enää mahdollinen.

Tämä tulee erityisesti eteen testauksessa, määrittelyssä ja niiden dokumentoinnissa. Ilman hallittua testaus prosessia asioita saatettiin valmiiksi nopeammin, mutta suuremmalla määrällä virheitä. Usein kuitenkin uudet palvelut ja järjestlemät toimivat, -ainakin jollain tavoin. Tuotanto oli todellinen testiympäristö. Ei edes yritetty testata kaikkia käyttötapauksia vaan katsottiin pikemminkin se, että pysyykö palvelut pystyssä. Jos pysyy niin sitten vain tuotantoon.

Ajatusleikkinä voisi miettiä, että yritys, jolla on vaikka keskimäärin 10 IT-projektia käynnissä vuosittain minimoisi näiden testauksen. En nyt tarkoita sitä, etteikö varmistettaisi perustoimivuus ennen käyttöä, mutta unohdetaan laajamittainen käyttäjätestaus ja tehdäänkin vain perus tietoturva auditoinnit ja kuormitus testit. Mikä vaikutus sillä olisi IT-budjetteihin ja tuotannon laatuun. Tässä toki vaikuttaa millaisia palveluita ollaan ottamassa käyttöön ja mikä on firman profiili.

Vielä vuosia takaperin muistan, että oli normaalia siirtää tuotantoon palveluita jotka oli vain “saatu toimimaan”. Kyllähän niissä virheitä sitten ilmeistyi, mutta ilmeisesti onnekkaasti saimme aina kaikki korjattua lennossa ja ilman suurempia vahinkoja. Nykyään tuntuu taas, että mitään ei voi siirtää tuotantoon ennen kuin viimeinenkin riski on testattu ja eliminoitu pois. Tässä ei sinänsä ole mitään pahaa, mutta mikä sen panostus vs. hyöty on? Olisiko mahdollista vielä nykypäivänä tehdä IT-projekteja vanhan koulukunnan mallin mukaan? Eli laitetaan palvelu toimimaan niin, että pysyy pystyssä ja sitten aktiivisesti seurataan palvelun käyttöä.

Nyt kun erilaiset Google Apps marketit ja vastaavat yleistyvät, niin on kiva huomata kuinka sovellukset syntyvät juuri tähän tyyliin. Epäonnistutaan nopeasti ja halvalla. Uusia versioita tulee ensimmäisten viikkojen aikana nopeaan tahtia. Sovelluksia ei ole testattu lainkaan, se on vain saatu toimimaan…

Continue reading »]]> Projektipäällikkö ja roskapostittaja ovat usein samassa kategoriassa, siis projektipäällikön viestien vastaanottajien mielissä. Jokainen projektipäällikkön viesti on vain ärsyttävä muistutus jostain asiasta, jolla ei ole tekemistä “minun” elämäni kanssa.

Miten sitten pp voisi varmistaa viestinsä perille menemisen ja lukemisen? Tietenkin samoilla keinoilla kuin roskapostittajakin. Seuraamalla mikä viesti toimii ja millainen sanamuoto saa vastaanottajan lukemaan viestin. Seurataan ketä avaa viestin. Ketä lukee liitteen ja ketä seuraa linkkejä eteenpäin. Kuinka moni kuittaa ennakko tehtävät tehdyiksi, jne…

Roskapostittaja tai “markkinoija” tekee tätä työtä erittäin tehokkaasti ja kehittyneiden työvälineiden avulla. Samat työkalut olisi saatavilla myös Projektipäällikkön käyttöön pienellä vaivalla. Mitä se vaatii. Jatkossa kun toimit projektipäällikkönä ja tuntuu, että projekti ryhmä alkaa paisumaan liian suureksi. Ota käyttöösi joku edullinen tai ilmainen massapostitus palvelu. esim. mailchimp. Sitä on mahdollista käyttää lähes maksutta. Sen avulla on helppo seurata mitkä viestit luetaan ja ketä ei avaa viestejä. tämä antaa todellisen kuvan siitä ketä projekti oikeasti kiinnostaa ja ketä kannattaa kutsua mukaan.

Pientä viilausta projektiryhmään ja viestin sisältöön niin tehokkuus kasvaa. Lisäksi jos projektiin liittyy vielä suuremman väen tiedottaminen ja kouluttaminen ovat nämä työkalut aivan ehdottoman hyviä varmistamaan tiedon perille menoa ja seuraaman sitä missä yksiköissä täytyy vielä tietoisuutta lisätä.

Lisäksi viesteihin on hyvä lisätä manuaalisia kuittauksia siitä että on ymmärtänyt ohjeet tai muistutus siitä, että mikäli ei ilmoita puutteista pöytäkirjassa tiettyyn kellonlyömään mennessä tarkoittaa se asiakirjan hyväksymistä jne.

Kun projekti lähtee hallitsemattomasti liikkeelle täytyy liike pysäyttää. Paras keino siihen on tiedon jakaminen ja sen varmistaminen, että tieto menee perille.

Roskapostittaja on kaikkien kaveri,
Rene

Continue reading »]]> Miksi meidän on niin kovin vaikea ottaa apua vastaan asioiden tekemisessä. Erityisesti tehtävät, jotka voisimme ja osaisimme tehdä itse. Jos meillä vain olisi joskus aikaa tehdä ne.

Olemme perheenä rakentaneet omakotitalon vuonn 2004 ja asuneet täällä jo kohta seitsemän vuotta. Kuten jokainen “omakotirakentaja” tietää, niin listoja ja pikku koloja tuppaa aina olemaan. Kun tarpeeksi pitkää asuu talossa, niin kaikkien noiden pikku viilauksien kanssa oppii elämään. Sitten jossain vaiheessa tulee kuitenkin totuuden hetki ja pitäisi muuttaa. Tämä tietenkin tarkoittaa, että vanha koti pitäisi saada myytyä.

Aina kun mennään katsomaan uutta kotia, niin uuden kodin toivoo herättävän tunteen, että tämä on valmis ja täällä minä voin nauttia huolettomista päivistä. Silloin jokainen kolo, rako ja maaliläikkä tuntuu suuremmalta kuin yksikään mitä on ikinä nähnyt. Tästä syystä piti ottaa itseä niskasta kiinni. Piti ottaa naulapyssy kauniiseen käteen ja pistää viimeiset listat paikalleen.

Kuinkas kävikään… Listojen valinta kaupassa kesti tunteja, mittaaminen toisia tunteja ja sitten vielä sahaaminen ja paikalleen laittaminen. Työkalut hukassa ja vääränlaiset naulat. Liian lyhyt vatupassi jne. useita viikonloppuja ja kymmeniä työtunteja myöhemmin oli ensimmäinen listan palanen nauluttu vinoon. Tässä vaiheessa kuulin jo vaimoni sanat, joita oli toistettu useamman kerran vuosien kuluessa: “Palkataan, joku ammattilainen tekemään tämä. Hänellä menee siihen vain muutama päivä ja sitten homma on kunnossa”. Itsepäisesti olin sitä mieltä, että minä säästän ja minä osaan itsekkin tämän tehdä. Molemmissa asioissa varmaan totta. Jos minulla olisi aikaa niin osaisin tehdä. Jos minulla olisi tarvittavat työkalut niin pystyisin tekemään. Unohdin, että itselläni oli kuitenkin aina tuhat muuta asia joissa olen vielä parempi. Siksi asia aina vain jäi. Vaikka vastineeni vaimolle oli: “minä teen tämän itse, ei tämä niin vaikeaa ole. Heti, kun annat minulle aikaa niin hoidan homman kuntoon”. Vastineeseeni oli piilotettu oma alibini. Kiire, eli ajanpuute, jonka vaimo voisi korjata antamalla minulle rauhallista ajattellu aikaa asioiden tekemiseen. Tiesin, että saisin ajan jos sitä oikeasti haluaisin, mutta koin aina muut asiat tärkeämmäksi, joten en sitä ottanut tai vaatinut, mutta se toimi hyvänä alibina. No, lopulta oli sitten pakko soittaa tutulle rakennusmiehelle, joka on hoitanut meillä muutkin vastaavat hommat todella nopeasti ja laadukkaasti kuntoon. Tässä kotoa työskennellessäni katselen kuinka listojen alle katoaa “kolonen” toisensa jälkeen ja talo muuttuu hetki hetkeltä valmiimmaksi. Itse voin samalla keskittyä asioihin, joita osaan tehdä hyvin ja jotka oikeasti tuottavat tulosta yritykselleni.

Asia tuli talossani nyt korjattua, mutta tilanne jäi kuitenkin mietityttämään niin paljon, että oli pakko kirjoittaa siitä muutama rivi. Miksi meidän on niin vaikea ostaa palvelua tilanteessa, jossa voisimme itse tehdä asian? Tämä tulee vastaan prosessien ja toimintatapojen dokumentoinnissa. Tottakai jokainen sen osaa tehdä, jos vain on luku- ja kirjoitustaitoinen. Mutta sille ei ole koskaan aikaa kun on aina jotain parempaa ja tärkeämpää tekemistä. Kuten asioita joita osaa todella hyviin. Jos olen IT-päällikkö niin haluan mittiä strategiaa ja tutkia mistä johtuu notkahdus palvelupyyntöjen määrässä tai mikä on “pilven” vaikutus yrityksen tuleviin tietoteknisiin valintoihin. Lista on lähes loputun. Miksi en siis maksaisi jollekkin, joka dokumentoi meidän toimintapamme? Etsii niistä pahimmat puutteet ja antaaa korjaavat toimenpiteet. Pelkäämmekö antaa kuvan, että emme osaa hoitaa työtämme? Voisi kuitenkin olettaa, että jokaisen päällikkön tehtävä on tuottaa mahdollisimman hyvää jälkeä mahdollisimman tehokkaasti. Jos tämä tarkoittaa, että välillä pitää ostaa palvelua ulkopuolella, niin sitten täytyy vain tehdä niin.

Mikä on SE asia sinun yrityksessäsi, minkä tiedät olevan tärkeää, mutta et ole vain “ehtinyt” sitä tehdä? Onko asioita, joita et kehtaa tilata talon ulkopuolelta? Mikä on se asia minkä tekisit heti ensimmäiseksi kun tämä kiire vain vähän helpottaisi? Lopputulos kuitenkin helpottaisi omaa elämääsi paljon. Miksi et siis helpottaisi tuskaasi ja maksaisi jollekin, että hän hoitaa asian kuntoon.

Vuosia meni tilausta pantatessa, mutta toteutukseen meni ammattilaiselta päivä! Ei enää itkua kun ei tule valmista. Kiire on, mutta sitä varten on olemassa palvelun tarjoajat.

NIM. Iloinen listoitetun talon omistaja

Continue reading »]]> Tämän päivän Helsinginsanomissa,  29.3.2011, oli juttu tutkimusta, jossa oli tutkittu ihmisten halukkuutta auttaa hätää kärsiviä.

Juttu Helsinginsanomissa

Jutussa oli tutkittu mikä vaikutus erilaisilla tiedoilla oli ihmisten halukkuuteen auttaa hätää kärsiviä.

Onko liian raadollista ajatella tätä yrityksen markkinoinnin kanalta niin, että ei kannata näyttää hienoja tilastoja käyttäjämäärien kasvusta tai uusista markkinaosuustilastoista. Kertoo vain yhden sydäntä koskettavan tarinan onnistuneesta projektista tai palvelun käyttöönotosta. Nimineen ja kuvineen kaikkineen. Antaako se parammat mahdollisuudet samaistua. Olisiko tätä myös ollut Nokian tuska.. ? Nokia näytti joka vuosi kuinka hieno heidän markkinaosuutensa oli, vaikka todellisuudessa puhelimien keskihinnat ja katteet laskivat tasaiseen tahtiin. iPhone tuli markkinoille tarinan kanssa, jossa köyhä opiskelija poika oli koodannut sovelluksen jolla nyt tienasi miljoonia tai yksittäinen kaveri joka ei osannut käyttää tietokonetta olikin nyt onnistunut synkronoimaan musiikkitiedostonsa puhelimen ja tietokoneen välillä.

Mikä on sinun todistuksesi? Google tulee Adroid puhelimillaan ja Chrome käyttöjärjestlemillään hirveää vauhtia joka puolelta. Heidän tarinansa on se, että sinä päätät mitä se tekee. Kaikki on avointa ja kaikki on yhteydessä toisiinsa. Menestystarinoita tulee jatkuvasti. Tarinoita kertovat yksittäiset ihmiset ja yritykset.

Pilvipalvelut alkavat olla kohta kaikki tuolla Gartnerin ja muiden tutkimusten ryöpytyksissä, mistä kävisi ilmi todellisia tarinoita aidoista ratkaisuista ja todellisista kohtaloista. Jos sinulla on pilvipalveluita, niin mitä niillä on saatu aikaan? Ketä on yrityksesti nälkäinen ja hätää kärsivä toimitusjohtaja, jonka ratkaisusi on pelastanut? Vai ovatko kaikki tarinat ainoastaan osa tilastoja?

Continue reading »]]> 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?

Continue reading »]]> 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

Continue reading »]]> 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

Continue reading »]]> 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

Continue reading »]]> 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.

Projektiaikataulu