Liiketoimintajärjestelmä pilvestä vai paikallisesti?

22.9.2014 at 13:54

Nykypäivänä yritykset pursuavat erilaisia liiketoimintaa tukevia tietojärjestelmiä, kuten toiminnanohjausjärjestelmiä, tuotannonohjausjärjestelmiä ja asiakkuudenhallintajärjestelmiä. Perinteisesti yritykset ovat halunneet pitää järjestelmät pois pilvestä pitäen järjestelmät joko omissa tiloissaan tai hostattuna palvelutarjoajalla. Onko tälle kuitenkaan nykypäivänä perustetta, koska iso osa em. järjestelmistä tarjotaan suoraan kehittävän tahon omasta pilvestä? Jokaisen yrityksen pitää luonnollisesti pohtia tilanne omista lähtökohdistaan, mutta tässä muutama vinkki taustalla vaikuttavista asioista:

Liiketoimintajärjestelmä, pilvestä vai paikallisesti?

1) Järjestelmän saatavuus

Työntekijät ovat tavalla tai toisella kytkeytyneinä tietoverkkoon ajasta ja paikasta riippumatta. Joku on asiakaskäynnillä, toinen matkaamassa junalla tai autolla, kolmas tekee töitä etänä. Tänä päivänä on haastavaa, jos ko. henkilön työkalut eivät ole käytettävissä siellä missä hän on liikkeellä ja niillä päätelaitteilla, jotka ovat käytettävissä. Yrityksen sisäisiin järjestelmiin voidaan rakentaa eri tekniikoilla pääsy myös ulkoverkosta, mutta niiden käytettävyys ei pääse sille tasolle kuin mitä pilvimaailma tarjoaa. Pilvipalvelut ovat käytössä fyysisestä sijainnista riippumatta ja lähes kaikilla moderneilla päätelaitteilla ilman ylimääräisiä tietoturvaratkaisuja. Toisaalta pilvipalveluiden toimintavarmuus on tavanomaisesti yli 99%:n luokkaa, johon paikallisilla ratkaisuilla hyvin harvoin pystytään.

2) Järjestelmän kehitys

Hyvin harva ratkaisu sellaisenaan istuu saumattomasti yrityksen liiketoimintaan. Tarkoituksena kuitenkin on, että järjestelmä tukee liiketoimintaa eikä niin, että liiketoimintaa toteutetaan järjestelmän asettamien reunaehtojen mukaan. Suomeksi tämä tarkoittaa, että järjestelmiä räätälöidään vastaamaan yrityksen tarpeita. Moderneissa tietojärjestelmissä räätälöintiratkaisut mahdollistavat hyvin monimutkaisten toimintojen räätälöinnin ilman sovelluskehitystä. Integraatiot ympäröiviin järjestelmiin tai laajemmat kehitystyöt tehdään joko hyödyntäen valmiita komponentteja tai kehittämällä ne sovelluskehitystyökaluilla. Paikallisessa ratkaisussa tietokannat ovat saatavilla sellaisenaan, mutta pilvimaailmassa on tyydyttävä niihin rajapintoihin, joita palveluntarjoajat tarjoavat. Koko tietokantaa ei kovin helposti pilvestä saa. Tässä kohtaa pilvimaailma on ollut hieman jälkijunassa, mutta ovat kirineet tätäkin eroa kiinni. BI-ratkaisut ovat tuoneet raportointiin uusia ulottuvuuksia ja poistaneet monia raja-aitoja.

 

Pilvipalvelut3) Järjestlemän päivitykset

Kaikkien tietojärjestelmien tulee päivittyä tai muuten ne jäävät pikkuhiljaa ajasta ja liiketoiminnasta jälkeen. Paikallisesti hallinnoitava järjestelmän päivittäminen tapahtuu yleensä erilaisten päivityspakettien kautta. Käytännössä päivitystahdin sanelee ylläpitävä taho yhteistyössä liiketoiminnan kanssa. Koska on sopiva hetki päivityksen aiheuttamalle katkokselle? Muuttuuko järjestelmän käyttöliittymä tai -logiikka? Tarvitaanko koulutusta? Miten integraatiot ja muut laajennokset käyttäytyvät päivityksen kanssa? Isoja kysymyksiä, jotka käytönnössä tarkoittavat, että päivitystä ei haluta tehdä hosumalla. Toisaalta päivitystahti on jollain tavalla omassa kontrollissa.

Pilvimaailmassa päivitykset tulevat tavanomaisesti ”pakotettuna”, sen aikataulun mukaan, jonka palveluntarjoaja on määritellyt. Jossain tapauksissa päivitysaikatauluun voi myös itse vaikuttaa, mutta siinäkin tapauksessa puhutaan viikoista tai maksimissaan parista kuukaudesta. Toisaalta järjestelmä kehittyy jatkuvasti ja yleensä tiuhemmissa sykleissä. Tämä asettaa järjestelmän käyttäjät hyvin samojen haasteiden eteen. Miten toimitaan päivitysten yhteydessä, jotka aiheuttavat muutoksia järjestelmään? Miten toimitaan uusien ominaisuuksien hyödyntämisen kanssa? Jos asiaa mietitään negatiivisesti, olet sidoksissa palveluntarjoajan aikatauluun, mutta toisaalta säästyt ylläpidollisilta toimenpiteiltä.

Esimerkiksi Microsoft Dynamics CRM -järjestelmän kanssa paikalliset (onpremise) käyttäjät ovat eriarvoisessa asemassa pilvipalvelun (crmonline) käyttäjien kanssa. Microsoftin panostukset ovat selkeästi pilvessä, jolloin päivitykset tulevat lähes aina ensin sinne ja vasta sen jälkeen paikalliseen jakeluun, jos ollenkaan.

Käytännössä pilvipalvelun päivittymisen ja kehittymisen seuraaminen vaatii resursseja, jotta asiat eivät tule yllätyksenä. Esimerkiksi käyttöliittymän yllättävä muutos voi aiheuttaa käyttäjille suuriakin ongelmia. Jonkun on siis pysyttävä ajantasalla muutoksista. Se, onko yrityksillä tällaista resurssia käytössään, on sitten toinen asia.

Yhteenveto

Maailma on vääjäämättä muuttunut ja yrityksien on pystyttävä sopeuttamaan toimintatapojaan sen mukaiseksi. Työntekijät tekevät työnsä hyvin eri lailla kuin 5 vuotta sitten ja uusia toimintatapoja on pystyttävä tukemaan. Toisaalta tietojärjestelmähankkeet eivät enää ole lähellekään niin massiivisia kuin ennen (pl. julkisen sektorin megalomaaniset hankkeet). Siinä missä aiemmin investointi tehtiin lähes täysin etupainotteisesti, eli hankittiin rauta, softa ja vietiin läpi itse hanke, niin nykypäivänä laitteet ovat jo olemassa, softan saa pilvestä ja hanke on yhä enenemässä määrin räätälöintiä eikä sovelluskehitystä. Avainasemassa on oikeiden kumppanien valinta. Ensinnäkin pitää valita järjestelmäalusta oikein esim. CRM-järjestelmien osalta vaikka Microsoft Dynamics CRM:n, SalesForce, SugarCRM:n tai muiden vastaavien joukosta. Tämän jälkeen on vielä valittava sopiva kumppani, jolla on järjestelmäosaamista sekä liiketoimintaymmärrystä. Oikean kumppanin kanssa asioita saadaan vietyä kustannustehokkaasti eteenpäin, kohti liiketoiminnallisia tavoitetiloja. Oikeanlainen kumppani tarjoaa asiakkailleen tietoa, informoi ja opastaa, silloinkin, kun tilanteeseen ei liity mitään myytävää.

Pilvipalvelut kehittyvät vielä kovaa vauhtia, eikä optimaalista tilannetta olla vielä nähty. Tulevaisuuden visio on kuitenkin vahvasti pilvipanotteinen, enkä usko, että jatkossa kovinkaan moni esim. pk-sektorin yritys voi perustella paikallisia järjestelmiä kustannustehokkuudella tai laadukkuudella.

Tyhjän inboxin taktiikka

16.9.2014 at 12:59

Vaihdoin hiljattain työpaikkaa. Ensimmäisenä työpäivänä tuijotin tyhjää Outlookin inboxia ja vedin syvään henkeä. Hetken mielessäni ajattelin, että tämä tilanne ei tule enää koskaan toistumaan. Tarpeellista sähköpostia, markkinointispämmiä, varmuuden vuoksi cc:nä tullutta ja kaikkea siltä väliltä alkaa pian tippumaan taivaalta pyydettynä ja pyytämättä. Kiduttava lopputulos on se, että inbox alkaa täyttymään laadultaan vaihtelevalla sisällöllä, joka pitäisi jollain tavalla hallita. En halua unohtaa mitään, vaikka työkiireet estäisivät asian välittömän hoitamisen. Täyteen pursuava inbox saa kuitenkin mielen ahdistumaan ja kiireen tuntumaan vielä todellisuutta pahemmalta.

Näistä lähtökohdista aloin miettimään optimaalista työtapaa, joka kiteytyy siihen, että päivän päätteeksi inbox on tyhjä. Englanninkielessä asiaa kuvataan yleensä empty inbox tai zero inbox termeillä, joissa idea on hyvin pitkälle sama.

Taustalle loin kolme kategoriaa:

  1. ASAP. Tänne ohjataan kaikki viestit, joiden seurauksena minun pitää tehdä jotain asap, mutta joiden suorittaminen ei ole juuri nyt mahdollista.
  2. Lue myöhemmin. Tänne laitetaan kaikki ne viestit, jotka haluan joskus lukea. Nämä eivät ole kiireisiä eivätkä vaadi reagointia.
  3. Arkisto. Tänne laitetaan ne viestit, joita saatan joskus tarvita, mutta joiden lukeminen myöhemmin ilman eri syytä ei ole tarpeellista.

Viestit ohjataan oikeisiin paikkoihin pikatoimintojen avulla. Viestin siirtäminen oikeaan paikkaan vaatii siis tasan yhden klikkauksen. Pikatoiminnon taustalla viesti liputetaan (siitä tulee tehtävä) ja se siirretään ko. kansioon. Esim. ASAP kansioon menevät viestit liputetaan niin, että niihin pitää reagoida saman viikon aikana.

Outlook 2013 pikatoiminnot

Outlook 2013 pikatoiminnot

Eli otetaanpa muutama esimerkki arjesta:

  1. Jos saan hoidettua asian minuutissa, hoidan sen pois. Jos saapuneella viestillä ei ole tämän jälkeen arvoa -> Roskakori. Jos tiedän, että haluan palata viestiin tai tarvitsen sitä myöhemmin -> Arkisto.
  2. Jos viesti vaatii asap reagointia, mutta vie aikaa -> ASAP. Jos viesti on niin tärkeä, että sille täytyy varata aika kalenterista (esim. tarjouspyyntö), nappaan otsikosta kiinni ja raahaan sen toimintovalikkoon kohtaan Kalenteri, jolloin saan tehtyä samalla kalenterimerkinnän. Aikatauluavustajalla voin katsoa ensimmäisen vapaan ajan ja voilá, asialle on varattu aika kalenterista ja kaikki ko. viestiin kuuluvat dokumentit kalenterimerkinnässä mukana.
  3. Jos viesti vaatii reagointia, mutta reagointi vaatii jonkin asian selvittämistä tai muun henkilön työpanosta. Laitan prosessin käyntiin ja sen jälkeen -> ASAP.

Eli jokainen viesti luetaan läpi ja joko: a) suoritetaan siltä istumalta tai b) merkitään sopivalla luokitteella. Sitä vaihtoehtoa ei ole, että viesti vain jää makaamaan inboxiin ilman eri syytä.

Ja lopputulos näyttääkin sitten tältä:

Outlook 2013 tyhjänä kuten aina

Outlook 2013 tyhjänä kuten aina

Toinen tähän samaan asiaan liittyvä käytäntö on se, että pyrin lukemaan sähköposteja vain ennalta määriteltyinä ajankohtina. Itse olen huomannut, että aamulla ennen muiden töiden aloittamista on hyvä hetki. Samaten ruokatunnin jälkeen (ei ennen, koska silloin ruokatunti voi jäädä väliin jonkun ”tärkeän” asian takia). Lopuksi vielä päivän päätteeksi pieni lukupyrähdys. En vilkuile sähköposteja jatkuvasti, koska se estää tehokkaan työnteon. Lisäksi olen poistanut hälytyksen saapuneista viesteistä. Saattaa tuntua oudolta, mutta tässä informaatioähkyssä se on pakollista, koska muuten aikarosvot alkavat viemään aikataulua sivuraiteille. Loppujen lopuksi mikään sähköposti ei ole niin tärkeä, että käynnissä oleva työ pitäisi keskeyttää. Ja jos näin olisi, on sähköposti aivan väärä viestintäkanava moisen viestin välittämiseen. Välitön palaute saadaan Lyncillä, puhelimella tai nappaamalla kiinni hihasta.