Turvallinen konesali toiminnanohjausjärjestelmälle

Tietoviikko on kirjoittanut Jouluaattona 24.12.2011 Tiedon marraskuisista konesaliongelmista. Tällä kertaa toimittaja on ollut joulumielellä ja vähätellyt ongelmia.

Täysin vastaavaan vikaan ei Tiedon Suomen-konesaleissa voida törmätä. Täällä ei ole käytössä Ruotsissa rikkoutunutta laitetyyppiä ja -merkkiä tai muunmerkkisiä kyseistä välimuistin käyttötapaa hyödyntäviä laitteita.

Toiminnanohjausjärjestelmän lamautuminen saattaa laumauttaa koko yrityksen toiminnan. Tämä riski on otettava huomioon tehtäessä päätöstä konesalista.

Tiedon Suomen ja Baltian liiketoiminnasta vastaavan johtajan Ari Järvelän mukaan konesalivikoja ei tarvitse muutenkaan pelätä.

”Tällaisten moninkertaisten, päällekkäisten laitevirheiden ketju on äärimmäisen harvinainen”, Järvelä sanoo.

Koska äärimmäisen harvinainen on subjektiivinen käsite, päädyin etsimään tietoa konesaliongelmista Suomessa. Löysin seuraavat uutiset:

Uusi Suomi 5.2.2011, Elisan kännykkäverkko romahti 

Elisan mukaan vikaa etsitään parhaillaan. Ilmeisesti kyse on runkoverkossa oleva ongelma. Yhtiö kertoo, että tällaisen vian aiheuttaa sähkövika tai tulipalo konesalissa.

It-viikko 25.1.2011, OP-Pankin viat johtuivat Tiedon konesalista 

Tietoliikennehäiriön perimmäistä syytä ei Halénin mukaan vieläkään tiedetä.

Helsingin Sanomat 27.12.2010, Palveluntarjoajan vika haittasi VR:n ja Finnkinon lipunmyyntiä

Syynä häiriöihin oli palveluntarjoaja Logican konesalin remontista aiheutunut sähkövika, joka esti myös varageneraattorin toiminnan.

Digitoday 18.8.2008, 1500 palvelinta kärsi Nebulan katkoksista 

Nebulan Lauttasaaren konesalissa ups-järjestelmiä syöttävä pääkeskus vaurioitui sunnuntaina illansuussa. Valmistusvian takia ylikuumentunut pääkytkin suli ja katkaisi yhden vaiheen sähkönsyötön.

Digitoday 16.5.2005, Upsin kärähtäminen toi palokunnan Elisan luolaan

Ups- ja konesalitiloissa on automaattinen sammutusjärjestelmä. Se ei kuitenkaan lauennut, sillä lämpötila ei kohonnut kriittiseen pisteeseen, Aromaa sanoi.

Tietokone 11.5.2006, Räjähdys konesalissa hajotti taideteollisen it-laitteet 

Tapaus on havahduttava esimerkki turhan vähälle huomiolle jääneestä ongelmasta, joka voi aiheuttaa suuria ongelmia tietojärjestelmissä.

Edellisen vuoden sisällä on sattunut kolme äärimmäisen harvinaista tapausta. Tomi Dahlberg kertoo oman mielipiteensä asiasta:

Turun kauppakorkeakoulun erikoistutkija Tomi Dahlberg on Järvelän kanssa samaa mieltä siitä, että tämänkaltaiset ”mahdottomuudet” ovat konesaleissa hyvin harvinaisia

Minä olen sitä mieltä, että tämänkaltaisia tapauksia ei tule kutsua mahdottomuuksiksi, eivätkä ne ole hyvin harvinaisia.

Lisäksi tällaiset ongelmat yritetään, ja osin onnistutaankin, pitämään piilossa.

Julkisuuteen tulleiden ongelmien määrä jo itsessään on niin suuri, että konesalin vikaantuminen on otettava huomioon riskejä kartoitettaessa. Elintärkeän tiedon hajauttaminen useaan konesaliin pienentää riskiä tiedon menettämisestä. 

Palkkapussi toiminnanohjauksen pyörteissä

Vuoden 2011 aikana puolustusvoimien palkanmaksuongelmat ovat olleet esillä useaan kertaan, mutta tuskin ne kiinnostavat muita kuin asianosaisia eli puolustusvoimia ja järjestelmän toimittanutta konsulttitaloa. Yksilön kannalta palkka on hyvinkin merkittävä asia. Suurin osa palkasta kuluu asumis- ja ruokamenoihin. 

Työsopimuslain 2 luvun 13 § säätelee palkan maksuaikaa ja -kautta seuraavasti:

Palkka on maksettava palkanmaksukauden viimeisenä päivänä, jollei toisin sovita. Jos aikapalkan perusteena on viikkoa lyhyempi aika, palkka on maksettava vähintään kaksi kertaa kuukaudessa ja muussa tapauksessa kerran kuukaudessa.

Onko puolustusvoimat rikkonut lakia epäonnistuneen tietojärjestelmähankkeen seurauksena? Kenet haastetaan oikeuteen siinä tapauksessa? Mikäli kyseessä olisi yritys, olettaisin toimitusjohtajan istuvan syytetyn paikalla. Puolustusvoimien ylipäällikkö on Tarja Halonen. Mielenkiintoinen ajatus. 

Tietoviikko uutisoi palkanmaksuongelmista 20.12.2011 otsikolla Puolustusvoimien palkanmaksuongelmat jatkuvat ensi vuoden puolelle. Jutussa kerrotaan ongelmien taustoista:

Uuteen järjestelmään siirryttäessä laiminlyötiin työntekijöiden perehdytystä. Lisäksi siirtymäkauden työsumaa hoidettiin liian harvojen käsiparien voimin.

Mustaniemi ei halua spekuloida, onko syy ollut puolustusvoimissa, vai esimerkiksi toiminnanohjausjärjestelmän laajennuksen toimittaneessa Accenturessa.

”Puutteita oli ainakin resursoinnissa ja osaamisessa. Lisäksi järjestelmästä löytyi teknisiä vikoja. Kyllä tässä on ainakin meillä itsellämme peiliin katsomisen paikka”, Mustaniemi huokaa.

Jokaisessa suuremmassa järjestelmähankkeessa käyttäjien koulutus on otettava huomioon projektisuunnitelmassa. Menestyvillä toimittajilla projektityömalli huomioi koulutuksen luonnollisena osana projektia. Toimittajan projektipäällikön vastuulla on seurata projektisuunnitelman toteutumista ja vastuun kantaja pitäisi löytyä helposti.

Molemmat osapuolet toivovat molempien kannalta epämiellyttävän tilanteen ratkeavan mahdollisimman nopeasti. 

Takarajaksi palkanmaksuongelmien selvittämiseksi on nyt asetettu 1.3.2012, jolloin uusista palkankorotuksista ja -korjauksista sovitaan. Mustaniemi toivoo, että neuvottelut voitaisiin silloin aloittaa ”puhtaalta pöydältä”.

Mahdollisimman nopea ja kvarttaalin päähän sijoitettu takaraja ongelmien selvittämiseksi eivät ole näköjään mahtuneet samaan kappaleeseen. Ei niiden pitäisikään.

Erppiä ei rakenneta kuin taloa

Toiminnanohjausjärjestelmähankkeen vertaaminen talonrakennukseen saattaa olla mielekästä. En ymmärrä miksi, mutta monet päätyvät tähän vertaukseen. Viimeksi törmäsin tähän Tietoviikon CIO-osiossa, jonne Menno Huijben oli 1.9.2011 kirjoittanut artikkelin otsikolla Erppiä ei voi rakentaa kuten taloa.

LinkedIn-profiilin perusteella Menno on it-ammattilainen, mutta rakentamisesta hän ei näytä tietävän mitään:

Jos rakennat talon, teet ensin piirustukset, kustannusarvion, hankit urakoitsijan, tilaat raaka-aineet ja sitten aloitat rakennustyöt. Ensin perustukset, sitten seinät, katto ja niin edelleen. Yksinkertaista kuin mikä.

Yksinkertaista kuin mikä. Aloitetaan piirustuksista. Ensin pitää kuitenkin olla tontti, jolle rakentaa. Tontille rakentamista säätelee asemakaava ja rakentamistapaohjeet. Lisäksi pitää ottaa huomioon rakentamista koskeva lainsäädäntö. Kaupungilla on myös asiansa sanottavana. Rakennusvalvonta on se instanssi, joka kaupungin puolesta valvoo rakentamista ja myöntää rakennusluvan. 

Niin ne piirustukset,

Rakennuslupaa haetaan rakennusvalvonnasta. Rakennuslupaa haettaessa on nimettävä rakennuksen arkkitehtisuunnittelija, rakennesuunnittelija ja LVI-suunnittelija. Riittävän pätevyyden omaava hakijan edustaja nimetään lain tarkoittamaksi pääsuunnittelijaksi, yleensä arkkitehtisuunnittelija. Pääsuunnittelija vastaa rakennuksen suunnittelun kokonaisuudesta ja laadusta ja myös siitä, että lupahakemus liitteineen on kunnossa silloin kun se jätetään rakennusvalvontaan.

Eli meillä tulee olla pätevä valvoja koko projektille. Tämän lisäksi tarvitsemme seuraavat piirustukset / kuvat:

• asemapiirros
• pohjakuvat
• julkisivukuvat
• leikkauskuvat
• rakenneleikkaukset
• LVI-suunnitelmat
• sähkösuunnitelmat
• virallinen tonttikartta
• pintavaaituskartta
• pohjatutkimus (perustamis- ja pohjaolosuhteet, terveellisyys, jne.)
• selvitys julkisivuväreistä
• rakennushankeilmoitus
• energiatodistus- ja selvitys
• kolme erillistä asemapiirrosta verkostojen pitämiseksi ajantasalla (puhelin-, sähkö- ja katuverkot)

Eli joitakin suunnitelmia näin alkuun. Pirun yksinkertaista. Rakennushankkeesta ovat siis kiinnostuneet rakennusvalvonnan lisäksi lainsäätäjä, teleoperaattori, sähkölaitos ja vesilaitos. Rakennuksen paikan tulee mittaamaan kaupunkimittausyksikkö. Suunnittelijoilta vaaditaan riittävä koulutus ja naapureita tulee kuulla.

Näin tietotekniikan ammattilaisena voisin sanoa, että toiminnanohjausjärjestelmä pitäisi ottaa käyttöön samalla tarkkuudella kuin talo rakennetaan. Meillä tietotyöntekijöillä on paljon opittavaa rakentamisen ammattilaisilta. Eräs mielenkiintoinen opas on Rakennustiedon kustantama Pientalotyömaan valvonta ja tarkastusasiakirja.

Arvokasta tietoa

Tietoviikko jatkaa uutisointiaan Tiedon konesalia koetelleista ongelmista. Maanantaina 5.12.  otsikkona oli

Tiedon it-katastrofissa katosi dataa Ruotsissa

Olisiko kyseessä edes katastrofi, jos kaikki data olisi säilynyt? Tällaisiin tilanteisiin varauduttaessa on hyvä kaivaa ITIL-käsikirjat esille.

ITIL on laaja kokoelma parhaita käytäntöjä (Best Practices) it-palveluiden suunnitteluun, niiden toimittamiseen, it-infrastruktuurin tehokkaaseen hallintaan ja johtamiseen. ITIL-mallin määrittelemät palveluprosessit ovat käytännössä testattuja ja toimiviksi havaittuja lukuisissa organisaatioissa maailmanlaajuisesti. Jokainen organisaatio voi poimia itselleen sopivat osat ja täydentää niitä omilla parhailla käytännöillään. ITIL soveltuu kaikenkokoisten yritysten it-prosessikehykseksi. 

Sovellusten varmuuskopiointeihin ja ongelmista palautumiseen ITIL tarjoaa hyvän lähtökohdan.

Ensiksi ITIL kehoittaa käymään läpi palautusvaihtoehdot (recovery options) ja listaa niistä tyypillisimmät:


1. Cold Standby (Gradual Recovery): Servers need to be reconfigured and applications deployed, and this can take days or weeks.


2. Warm Standby (Intermediate Recovery): From minutes to a few hours, this option requires servers and applications already configured and deployed, that need to be connected to the production infrastructure (using network or other techniques. By engaging a third party to host alternate hardware, this technique can also be used for disaster recovery.


3. Hot Standby (Immediate or Fast Recovery): This option requires redundant hardware and applications that may or may not be at the same physical location, which automatically take over, without minimal interruption to IT services.


Tämän jälkeen tulisi määrittää vaaditun järjestelmävasteen mukainen varmuuskopiointistrategia.

Yksi ITIL:n sisältämistä parhaista käytännöistä on palvelinympäristön ulkopuolinen tallennustila. Tallenteiden sijoittaminen muusta palvelinympäristöstä erilliseen tilaan antaa suojan fyysisiä uhkia kohtaan.

Cold ja Warm Standby vaihtoehtoja yhdistävä strategia voisi olla seuraavanlainen:

Tuotantoympäristöstä otetaan joka yö varmuuskopiot identtiseen testiympäristöön. Testiympäristö on valmiiksi konfiguroitu ja se voidaan ottaa tuotantokäyttöön viiveettä (Warm Standby), mikäli tuotantoympäristö putoaa pois pelistä.

Ulkopuolinen tallennustila antaa suojaa fyysisiä uhkia vastaan ja toimii vaihtoehtoisena sijoituspaikkana tallenteille, mikäli testiympäristö vikaantuu. Ulkopuolisesta tallennustilasta voidaan palauttaa data, mutta ei välttämättä itse sovelluksen asetuksia tai asennusta, eli se on ITIL:n mukainen Cold Standby -vaihtoehto.

Kun ympäristö on suojattu, ITIL:ssä kehoitetaan vielä rakentamaan käytännöt ratkaisun testaamiseksi säännöllisin aikavälein.

Paloharjoitus tänään kello 12:00

Tiedon ongelmat Ruotsissa eivät ole vielä ohi. Dagens Industri uutisoi 1.12. ettei ole varmuutta, koska ongelmat saadaan ratkaistua:

Oklart när Tieto kan lösa dataproblem

Tietoviikko kirjoitti vielä perjantaina 2.12. datastrofista:

Tieto törmäsi Ruotsissa "siniseen kuolemanruutuun"

Tämä on jo kolmas ongelma. Sininen kuolemanruutu (engl. blue screen of death, bsod) on Windows käyttäjien riesa, järjestelmävirhe. Nimi juontaa juurensa siitä, että koko kuvaruudun täyttävä virheilmoitus näytetään sinisellä taustalla ja virhe on vakava.

Koska virtuaalikoneista otetun varmuuskopion palauttaminen ei onnistunut, Tieto yritti palauttaa viimeisimmän kopion nauhavarmennusjärjestelmästä. Tällöin ongelmaksi muodostui kuitenkin se, ettei Tiedolle varmuuskopiointiohjelman toimittaneen Legato Networkerin asiakasohjelmisto ole yhteensopiva Windows 2008 R2 -version kanssa.

Näillä ongelmilla voisi herkutella pitkään, mutta kuinka niiltä voidaan välttyä? Kuinka voimme minimoida riskit kun datastrofi osuu omalle kohdalle?

Me kaikki tunnistamme palohälytyksen äänen. Se on vellikelloa korkeampi ääni ja soi yhtäjaksoisesti kunnes joku sulkee sen. Useimmat meistä ovat osallistuneet paloharjoitukseen. Kun kuulemme palohälytyksen ensimmäinen ajatus on usein: "väärä hälytys tai harjoitus". Kuitenkin kun tosipaikka on kyseessä, osaamme poistua rakennuksesta rauhallisesti odottamaan palokunnan tuloa. Miksi näin? Koska vakava riski on tiedostettu ja ongelmaan on varauduttu. Tärkeät tiedot ovat paloturvallisessa kaapissa, poistumistiet on merkitty, asunnoissa on palohälyttimet ja julkisissa tiloissa sprinklerit.

Yrityksenne riskisuunnitelmassa on kohta tietoriskit. Tässähän kohdassa on lueteltu kaikki kuviteltavissa olevat asiat ja tilanteet, jotka voivat aiheuttaa häiriöitä tietohallinnossa. Muistellaanpa Tiedon tapausta ja rikkoutunutta levyjärjestelmää. Yhdistetään tähän paloharjoitus. Vedetään tietoliikennekaapeli irti toiminnanohjausjärjestelmästä ja katsotaan mitä tapahtuu seuraavan 48 tunnin aikana.

Toiminnanohjaukselle tehtävä paloharjoitus voisi sisältää esimerkiksi uuden laitteistoympäristön pystyttämisen varmuuskopioista. Kauanko tähän menee aikaa? Mitä tietoja olemme menettäneet?

Paloharjoitus tänään kello 12:00. ERP-palveliympäristömme on tuhoutunut räjähdyksessä. Hankimme uudet laitteet ja rakennamme järjestelmäympäristömme uudestaan mikäli varmuuskopiot saadaan palautettua. Laskennalliset myyntitappiot 125 000 euroa päivässä. Aikaa on 72 tuntia ennen kuin ensimmäinen merkittävistä asiakkaistamme sanoo yhteistyösopimuksen irti.

Tieto vauhdittaa rautakauppaa

Digitoday uutisoi 28.11.2011 ja 30.11.2011 tietotekniikan palvelutalon ongelmista Ruotsissa. Internetin aikakaudella Tieto leviää nopeasti. Tällä kertaa uutiskynnys on ylittänyt maan rajat.

Tiedon Ruotsissa sijaitseva konesali on kärsinyt toimintahäiriöstä perjantaista lähtien. Vika on Tiedon mukaan levyjärjestelmässä. Toimintojen korjaamista haittaa se, että samaan aikaan levyjärjestelmän rikkoutumisen kanssa meni rikki järjestelmän peilikopio.

Veikkaan että, myyntimiesten myydessä kyseisen konesalin palveluita he ovat vakuuttaneet sen kestävän ydinpomminkin. Mutta ilmeisesti ei sitten vikaa levyjärjestelmässä. Kyseisen konesalin ongelmista kärsii viitisenkymmentä asiakasta mukaanlukien rahoituslaitos SBAB, apteekkikonserni Apoteket, autokatsastus, valtionhallinto, Tukholman kaupunki ja Nackan kunta. Kyse ei ole mistään ihan pienestä konesalista.

Ostaisitko tämän jälkeen toiminnanohjausjärjestelmäsi pilvestä? Kuinka kauan organisaationne pärjää ilman ERP:n tukea?

Katastrofiin tarvitaan yleensä kaksi yhtäaikaista ongelmaa. Tiedon tapauksessa levyjärjestelmän lisäksi peilikopio oli mennyt rikki. 

Oletetaan, että yrityksenne tuotantolaitoksen tai päävaraston viereen rakennetaan omakotitaloaluetta. Kaivinkoneenkuljettaja osuu huomaamattaan tietoliikennekaapeleihin kauhalla ja katkaisee ne. Nyt tarvitaan vielä toinen ongelma, jotta katastrofi on valmis. Oletetaan, että paikallisen tietoliikenneoperaattorin verkkolaitteeseen tulee fyysinen vika. 

Kun ongelma havaitaan ensimmäisen kerran, yrityksenne it-päällikkö on yhteydessä operaattoriin. Operaattori kertoo tutkivansa ongelmaa. Syyllinen on löytynyt. Operaattori korjaa ongelman kahden vuorokauden kuluessa, mutta yrityksenne ei pääse edelleenkään internetiin. Mikä neuvoksi? Kauanko kestää, että toinen ongelma on havaittu ja korjattu?

Tiedon ongelmat saavat varmasti monen yrityksen miettimään palvelinten ulkoistamista. Rautakauppias kiittää.

Ohjelmiston jakelutie kilpailuvalttina

Tietoviikon tuore uutinen saksalaisen ohjelmistojätin aikeista myydä puolet kumppaneiden kautta sai minut pohtimaan jakelutien merkitystä asiakkaan näkökulmasta.

Vaihtoehdot yksinkertaisimmillaan ovat:

1. valmistaja myy itse
2. kumppanit myyvät
3. valmistaja ja kumppanit myyvät

SAP:n uutinen koski kanavan (engl. channel) eli kumppaneiden kautta myytävien lisenssien määrän kasvattamista. He kokevat sen olevan oikea tie. SAP:n tavoite on myydä puolet kumppaneiden kautta, mitä kutsutaan niin sanotuksi hybridimalliksi.

Mikäli valmistaja myy ainoastaan itse ei asiakkaalla ole mahdollisuutta kilpailuttaa toimittajaa. Toisaalta hyvä puoli on se, että valmistaja on usein lähellä tuotekehitystä. Mikäli ohjelmistotalossa on tuhansia työntekijöitä ja tuotekehitys valtameren takana, on tuo läheisyys kaukana todellisuudesta.

Kumppaneiden myydessä asiakkaalla on mahdollisuus kilpailuttaa valitun ohjelmiston toimittaja. Mikäli edustus toimii ainoastaan kumppaneiden kautta, ovat kumppanit tasaväkisessä asemassa ja valmistaja sitoutunut kanavan kehittämiseen.

Hybridimalli hyödyttää varmimmin valmistajaa. Valmistajalla on maakohtaisesti mahdollisuus luoda strategia, jolla kyseiselle markkinalle mennään. Mikäli samassa maassa on valmistajan lisäksi myös muita toimittajia, poimii valmistaja yleensä suurimmat asiakkuudet itse. Valmistajan läsnäolo edistää paikallista markkinointia ja tukee siten myyntiä. Valmistajat usein myös tukevat paikallisia kumppaneita ja läsnäolo kyseisellä markkina-alueella vahvistaa kumppaneita.

Asiakkaan näkökulmasta mahdollisuus toimittajan kilpailuttamiseen on tärkeää. Puhdasta kumppanuusmallia ja hybridimallia vertailtaessa oleellista on valmistajan ja kumppaneiden välinen kommunikaatio ja kanavaviestinnän onnistuminen.

Panostajan tytäryhtiön Lämpö-Tukku Oy:n TJ vaihtuu

Kauppalehden paperiversiossa kirjoitettiin 10.11.2011 Lämpö-Tukun toimitusjohtajan vaihtumisesta. Panostajan on julkaissut myös pörssitiedotteen asiasta:

...Lämpö-Tukku Oy:n liiketoiminnan myynti peruuntui kaupan toteuttamista edeltäneessä varaston inventaarissa ilmenneiden virheellisyyksien vuoksi. Virheellisyyksien kokonaismäärä on noin 2 milj. euroa...

...Panostaja Oyj:n tytäryhtiön Lämpö-Tukku Oy:n toimitusjohtaja Jouko Tyrkkö
vapautetaan välittömästi tehtävistään ja hänen toimitusjohtajasopimuksensa on
päättynyt tänään...

Lämpö-Tukun liikevaihto on ollut 12 miljoonan euron luokkaa vuonna 2010. Kahden miljoonan euron epäselvyyksistä voi vetää vain yhden johtopäätöksen: ajantasalla olevasta toiminnanohjausjärjestelmästä asia olisi selvinnyt jo aikaisemmin.Onkohan nyt säästetty oikeista asioista?

SAP avasi sovelluskaupan mobiilisovelluksille

Nyt jo toinen ERP-toimittaja on avannut oman sovelluskauppansa Applen AppStoren jalan jäljillä, kertoo Tietoviikko.

Ruotsalainen Jeeves avasi oman kauppansa Jeeves Apps Marketin aikaisemmin tänä vuonna, lokakuun alussa. Molemmilla on samankaltainen idea. SAP on rajannut sovelluskauppansa ainoastaan mobiilisovelluksille, Jeeves sen sijaan tarjoaa kaikenlaisia sovelluksia räätälöinneistä lisäarvosovelluksiin.

Toisen pelurin ilmaannuttua markkinoille tätä voi kutsua jo suuntaukseksi ERP-markkinoilla. Ennustan, että vuonna 2012 Microsoft avaa oman kauppansa.

Ostaisitko kiinalaisen ERP:n ?

Eurooppalaista teollisuutta siirtyy Kiinaan halvemman työvoiman perässä. Nyt saksalaiset ovat huomanneet, että työvoiman lisäksi rahat karkasivat Kiinaan ja ne on haettava sieltä pois. SAP aikoo investoida Kiinan markkinoille, lue juttu Tietoviikosta.

Ennuste: kiinalaiset toteuttavat globaaleilla markkinoilla pärjäävän ERP:n.

Kirkko ostaa 5,1 miljoonan euron SAP-järjestelmän

Tietoviikko uutisoi Fujitsun tekemästä kaupasta Suomen evankelilaisluterilaisen kirkon kanssa. Onhan tuo hienoa nostaa 5,1 miljoonan euron summa otsikkoon. Uutinen olisi jäänyt paljon vaisummaksi, mikäli otsikko olisi ollut yksinkertaisesti:

Uusi SAP-järjestelmä tuo kirkolle 7 miljoonan euron vuosisäästöt

Järjestelmän hinta ei sykähdyttänyt, mutta minua jäi kiinnostamaan mistä mittavat säästöt tulevat? Mikäli tehokkuutta parannetaan, miksi tätä ei ole tehty jo aikaisemmin? Eivätkö kirkko ja julkispuolen organisaatiot mittaa omaa tehokkuuttaan jatkuvasti?

Mittavien säästöjen lisäksi kirkon hankkeessa on toinenkin positiivinen piirre. Aikataulu nimittäin. Se näyttää realistiselta. Hankkeen koko tuo tosin omat haasteensa. Jumalan siunausta projektipäälliköille.

Toiminnanohjausjärjestelmän käytettävyys valintakriteerinä

Käytettävyysasiantuntija Aapo Puskala oli tehnyt VR:n verkkokaupasta käytettävyysarvion. Poikkeuksellista tässä on se, että Puskala on käyttänyt viikon omaa aikaansa 55-sivuisen arvion tekemiseen ja tehnyt sen pyytämättä. Toistaiseksi VR ei ole kommentoinut käytettävyysarviota, eikä tehnyt korjauksia verkkokauppaansa.

Toiminnanohjausjärjestelmää hankittaessa yksi valintakriteeri on usein käytettävyys. Tarjouspyynnössä tai vaatimusmäärittelyssä saattaa olla yksinkertaisesti ilmaistu: "järjestelmän tulee olla helppokäyttöinen". Mitä jos yksi evaluoitavista järjestelmistä ei olekaan helppokäyttöinen? Kuinka tämä helppokäyttöisyys arvioidaan? Tuollaiseen vaatimukseen on helppo vastata yhdellä sanalla kyllä tai ei.

Onneksi monessa järjestelmässä käyttöliittymää voi muokata joustavasti koskematta ohjelmakoodiin. ERP:n toiminnallisuudet on usein ryhmitelty parhaiden käytäntöjen ympärille ja mikäli oman yrityksen prosessit poikkeavat jossakin kohtaa totutusta, voidaan käyttöliittymää mukauttaa vastaamaan haluttua toimintatapaa.

Uutena suuntauksena voi selkeästi nähdä, että kansainväliset toimijat ovat kehittäneet järjestelmiään ja huomioineet ERP:n käytettävyyden. Huippumodernit käyttöliittymät Rich Clientteineen ja vektorigrafiikkoineen ovat jo arkipäivää. Lawson on ollut edelläkävijä ja julkaissut vuonna 2007 Lawson M3 järjestelmän Smart Office käyttöliittymän, joka perustuu .net3 -teknologiaan. Epicor 9 on julkaistu vuonna 2009, IFS Enterprise Explorer vuonna 2011, Jeeves julkaisee uuden Insight käyttöliittymän vuonna 2012 ja Microsoft julkaisee AX:stä uuden version vuonna 2012. Oletan, että myös SAP:lta tulee uusi käyttöliittymä 2012.

Suomen kunnat saavat yhteisen ERPin

Julkishallinnon massiiviset tietojärjestelmäprojektit ovat epäonnistuneet poikkeuksetta. Tietoviikon kirjoitus Suomen kuntien yhteisestä erpistä saa ihokarvat nousemaan pystyyn. Vaikka hankintaprosessi on kesken, ei ole vaikea arvata teknologia-alustaa ja toimittajaa.

Miten tuollainen jättimäinen hanke saadaan onnistumaan? Turhankin yksinkertaista olisi katsoa suuria hankkeita; välttää epäonnistuneissa projekteissa tehtyjä ratkaisuja ja kopioida onnistuneita projekteja. Yksi esimerkki onnistuneesta jättimäisestä (tai jättimäiseksi kasvaneesta) hankkeesta on LinkedIn. Heidän arkkitehtuurinsa on ainakin suhteellisen helppo kopioida.

Olisipa pirteää lukea joskus julkishallinnon puolella käytettävän ketteriä menetelmiä.

IFS tuo ERP:n älypuhelimiin

Tekniikka & Talous on julkaissut uutisen IFS:n toiminnanohjausjärjestelmän uudesta älypuhelinsovelluksesta. Tämä on nykypäivää. Yhteen tietojärjestelmään tarjotaan useita vaihtoehtoisia käyttöliittymiä ja käyttötapoja. Myyntiedustajien ja huoltomiesten liikkuvassa työssä mobiilikäyttöliittymälle on selkeä tilaus.

Myyntimies voi asiakaskäynnillä tarkistaa tuotteen varastosaldon ja syöttää tilauksen suoraan keskitettyyn tietojärjestelmään. Vastaavasti huoltomies saa huoltokutsun suoraan älypuhelimeen. Suoritettuaan työtehtävänsä hän raportoi  käytetyt materiaalit ja kuluneen työajan, joiden perusteella asiakkaalle lähtee lasku.

Tämä on monessa yrityksessä arkipäivää. Kaiken taustalla on tietysti toimiva ERP.

Uutinen ei sinänsä kerro mistään uudesta tai erikoisesta, sillä tämän kaltaisia sovelluksia on ollut saatavilla jo vuosia. Mielenkiinto kannattaa kohdistaa sovelluksen jakelutiehen:

lisäksi sovelluksen pystyy ottamaan käyttöönsä pilvipalvelun kautta

Tulevaisuudessa toiminnanohjausjärjestelmiä pystyy laajentamaan internetistä ostettavilla lisäosilla. Jakelutien sai ensimmäisenä isosti läpi Apple omalla AppStorellaan. Toiminnanohjausjärjestelmien osalta edelläkävijä on ruotsalainen Jeeves Apps Marketillaan. Ainakaan minun eteeni ei ole tullut toista vastaavaa.

Keitä ovat Tietoviikon artikkelissa mainitut SAP:n käytäjät?

Tietoviikossa on mielenkiintoinen artikkeli SAP:n hidastelusta. Tiedot perustuvat kansainväliseen tutkimukseen, jonka mukaan 43 prosenttia käyttäjistä on tyytymättömiä järjestelmän vasteaikoihin. Mikä sitten on hyväksyttävä vasteaika?

Käytettävyysguru Jakob Nielsenin useit.com -sivustolla on kirjoitus vasteajoista käytettävyyden näkökulmasta. Kyseissä kirjoituksessa viitataan Millerin 30 vuotta vanhaan tutkimukseen, jonka mukaan vasteajan tulisi olla maksimissaan 1 sekunti.

1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay

Tietoviikon artikkeli on kirvoittanut keskustelua, ja monilla tuntuu olevan omakohtaista kokemusta SAP:n hidastelusta. Onneksi lehti on antanut SAP Finlandin toimitusjohtajalle Marika Auramolle mahdollisuuden kommentoida väitettä. Itseäni jäi vaivaamaan keitä ovat tyytymättömät yritykset? Artikkelin poikimassa keskustelussa kirjoittajat ovat piiloutuneet nimimerkkien taakse.