Feeds:
Artikkelit
Kommentit

Archive for the ‘Teknologia’ Category

On mielenkiintoista havaita ajan kuluessa, kuinka nuorena sitä palvoo teknologiaa varsinkin jos työskentelee ICSCT alalla. Asiakkaille ehdotellaan mitä merkillisimpiä aparaatteja ja ohjelmistoja käyttöönotettavaksi vailla mitään kosketuspohjaa todellisuuteen. Eikö joskus asioita voisi tehdä ihan maalaisjärjellä?!

Nykyaikana on tarjolla ohjelmistoja ja ratkaisuja joka lähtöön ja IT-ostaminen on vaikea laji siksikin, että saavutettavien hyötyjen laskeminen on usein jopa mahdotonta. Moniko osaa ennustaa, kuinka kauan ERPin oppiminen organisaatioissa vie, tai että mitkä ovat lopulliset kustannukset suhteessa saavutettaviin hyötyihin? Lisänä sopassa ovat lisenssointimallit jotka ovat käsittämätön viidakko josta usein ei ota selvää edes toimittaja itse. Tiedän eräällä isolla toimittajalla olevan n. 10cm paksun lisenssikirjan josta löytyy lääke ts. veloitusperuste jokaiseen tapaukseen. On olemassa liikenteeseen perustuvia maksuja, käyttäjäkohtaisia maksuja roolien mukaan jaoteltuna, ylläpitomaksuja suhteessa kokonaiskustannuksiin tai käyttäjälisenssien määrään, liikevaihtoon suhteutettuja lisenssejä jne.

Väitteilleni saa todellisuuspohjaa katsomalla monen ERPin käyttöönottaneen talon liikevaihtoa. Usein liikevaihto on ollut hyvinkin nousujohteista ennen ERP käyttöönottoa mutta sitten laskenut kuin lehmän häntä tai hädin tuskin pysynyt positiivisena. Voi tietenkin spekuloida silläkin että olisiko liikevaihto/voitto joka tapauksessa romahtanut. Mutta mistä tämä lopulta kertoo?

Oma vajavainen mielipiteeni on että näissä taloissa on tiedetty keskitetyn ratkaisun tuovan säästöjä ja sellaista halutun, mutta aliarvioitu usein ”jäykkien” prosessien vientiä käyttäjätasolle, ts. muutoshallintaa. Siinä missä aiemmin kyettiin ketterästi ja LUOVASTI ratkomaan mitä erilaisempia ongelmia, nyt on olemassa tiukat säännöt sille mitä saa ja mitä ei saa tehdä.  Ei tarvitse olla ruudinkeksijä arvatakseen mitä tästä seuraa: Käyttäjät alkavat varoa tekemisiään virheiden pelossa ja siitä syntyvän lisätyön vuoksi. Toiminta ajautuu hiljalleen prosessien mukaiseksi mutta ovatko nämä prosessit oikeasti tehokkaampia kuin esimerkiksi työntekijöiden vapaus tehdä liiketoimintaa tavalla joka heille on luonteenomaisinta? Eikö työntekijät juuri ole yrityksen voimavara joiden ideoiden ja käytännön tuntemuksen perusteella saadaan yrityksen kilpailukykyä paremmaksi?

Uskon siihen että IT on vienyt kehitystä huimasti eteenpäin – siitä ei mielestäni ole epäilystä. Olen vain ”vanhaksi” tullessani alkanut epäilemään suunnattomasti tätä IT -palvelujen ja tuotteiden tarpeellisuutta. Ala ruokkii itse itseään ja tästäkin syystä kasvaa voimakkaasti. Moni asia hoituisi yhä sähköpostilla jota useimmat osaavat käyttää mutta usein hautaudutaan edelleen IT-hypetykseen.

Esimerkki: Keskitetty hankinta

Yritys A on hankkinut tähän päivään asti kaikki tarvikkeensa toimipisteittäin riippumattomasti muista. Hankinnat on toteutettu milloin mitenkin (sähköpostilla, puhelimitse, suullisesti), mutta joka tapauksessa kaikki laskut on lähetetty pääkonttoriin jossa useampi kirjanpitäjä kirjaa laskuja taloushallinnon ohjelmistoon. Nyt joku myyntimies keksii että hei – yrityshän tarvitsee ERPin ja alkaa laatia strategiaa tämän myymiseksi, kun tosiasiassa selvittäisiin sillä että sovittaisiin perusteet hankinnoille, ts. joku sopisi vuosisopimukset tavarantoimittajien kanssa ja näillä hinnoilla mentäisiin niillä toimipisteillä joita hinnoittelu koskee. Edelleen toimipisteillä olisi oma vapautensa tehdä liiketoimintaa, mutta nyt hankintahinta on jo kiveen hakattu.

Esimerkki – Myynti

Asiakas haluaa ostaa tuotteen ABC. Tätä ei ole vielä valikoimassa, jolloin myyjä kentällä joutuu toteamaan tuotteen olevan loppu tai ei saatavilla. Tuotteen perustaminen varastoitavaksi tuotteeksi ERP prosessissa ja sen käsittely  söisi katteen monin verroin joten tätä ei yleensä tehdä (ellei tuotetta oteta pysyvästi valikoimaan). Toki voitaisiin käyttää ns. palvelutuotteita, jolloin yhtä ja samaa tuotenumeroa käytettäisiin palveluiden myyntiin, jollainen mm. suoratoimitustuotteen myynti voisi olla, mutta usein ERPiä käyttävissä taloissa myyjän vapaudet ovat todella rajatut sillä kaikki on keskitettyä.  Ilman ERPiä voisi myyjä myydä  mitä ikinä asiakas haluaisikaan ja jopa soittaa asiakkaan läsnäollessa toimittajalle joka lähettäisi tavarat heti matkaan. Onko tämä sitä long-tail kaupankäyntiä?

Alla esimerkki siitä miten oikea asenne ja toisen tilanteen syvällinen ymmärtäminen ratkaisee ja koituu lopuksi (yrityksen) omaksi eduksi!

Isossa kaupungissa oli julmetun suuri tavaratalo, josta sai aivan kaikkea, siis todellakin aivan kaikkea. Laittoivat sitten lehteen ilmoituksen myyjän paikasta ja paikkaa hakemaan ilmaantui ujohkon oloinen maalaispoika.
”Oot sitten maalta kotoisin?”
”Joo’o.”
”Ootko ennen tehnyt myyntihommia?”
”Juu, kyllä mä siellä maalla…”

Vaikka sälli olikin vähän ujon oloinen, niin myyntipäällikkö jotenkin piti hänestä, ja otti hänet hommiin.

Pitkän hikisen ensimmäisen työpäivän jälkeen päällikkö tulee siinä viiden pintaan katsomaan miten maalaispoika on pärjännyt.
”No, montakos kauppaa olet tehnyt?”
”Yhden.”

Päällikkö on vähän pettynyt, ja toteaa: ”Niin, yleensä meidän myyjät tekee sellaiset 20-30 kauppaa päivässä. Paljonkos arvoinen se ainokainen oli?”

”1,2 miljoonaa.”

”Yksi pilkku kaksi miljoonaa!! Mitä -ihmettä- sä oikein myit??”

”Niin no, mä myin tälle kaverille ensin sellaisen pienen ongenkoukun, sitten vähän isomman, seuraavaksi sellaisen Rapalan viehesarjan ja vielä perhontekovehkeet. Sitten se tietysti tartti siimaa, ja mä myin sille ensin sellaista tavallista, sitten vähän vahvempaa ja vielä sellaista kunnon barracudankestävää extrasiimaa. Tietysti siihen sitten oli myytävä kunnon vavat ja kelat. Sitten todettiin, että kyllä se venekin tarvitaan, ja niin mä vein kaverin veneosastolle ja myin sille Marino 9000:n erikoisvarustein. Seuraavaksi se totesi ettei sen vanha kuplavolkkari kyllä jaksa vetää semmoista rohjoa, joten vein sen sitte vielä auto-osastolle ja myin sille Range Roverin ja trailerin. Kaikkineen siitä tuli aika tarkkaan 1.198,160 mk.”

”Ei jumalauta, mies tulee ostamaan ongenkoukkua ja sä myyt sille kaiken tuon?”

”No ei ihan… itte asiassa se tuli ostamaan muijalleen tamponeja, ja mä sitten sanoin sille, että sun viikonloppus on joka tapauksessa pilalla, mikset lähde vaikka kalaan…”

Read Full Post »

Tuskin kukaan meistä on säästynyt viime päivien myllerrykseltä (uutisilta ainakaan) ja säästötoimenpiteet ovat olleet kuuma puheenaihe yrityksissä. Säästötoimenpiteet innoittivat pohtimaan SaaS ja avoimen lähdekoodin markkinoiden tilannetta nyt ja niiden tuomia mahdollisia säästöjä.

Ennen vanhaan oli yritykset keskittivät palvelimiaan ja niissä pyöriviä ohjelmistoja yhteen paikkaan. Internet-pohjaisten työkalujen tulemisessakaan ei siis ole tämän suhteen mitään uutta – nyt siirrytään yritysten sisäisistä konesaleista ulkopuolisiin suuriin konesaleihin, jotka tarjoavat yrityksille työkalut palveluna. Tähän perustuu mm. SaaS (Software as a Service) liiketoiminta. Siirtymä on aivan luonnollinen askel IT-alalla jossa maantieteelliset alueet eivät suuremmin merkitse mitään (mantereittain).

Viimeistään nyt loputkin tietohallinnon päättäjistä ovat heränneet pohtimaan säästöjä ja kustannustehokkuutta. Tähän huutoon vastaavat Saas ja avoin lähdekoodi. Saas ja avoimen lähdekoodin työkalujen käyttöönotolla tavoitellaan alempia käyttökustannuksia verrattuna esimerkiksi siihen että ohjelmistot ostetaan ja asennetaan yrityksen omalle palvelimelle sekä työasemille. Vanha fraasi ”Ei ne pienet tulot vaan ne suuret menot” on taas erittäin suosittu. Yritys voi koosta riippumatta ajautua ongelmiin heikentyneessä markkinatilanteessa, jossa se joutuu maksamaan edelleen samat IT-lisenssi ja ylläpitomaksut kuin nousukaudellakin – ja valitettavasti usein vielä enemmänkin. USAn uusi presidentti Obamakin on vihjannut pohtivansa avoimen lähdekoodin sovellusten hyödyntämistä valtionhallinnossa, mutta syynä voi olla myös manipulaatio suurimpia yrityksiä vastaan jonka pyrkimyksenä voisi olla varoitus suurille yrityksille irtisanomasta ko. maassa työntekijöitään.

Palvelut ovat jo olemassa – käyttäjämäärä kasvaa nopeasti

Tänä päivänä SaaS tarjontaa löytyy jo lähes joka tarpeeseen. Market-Vision mukaan 57% tietohallintopäättäjistä kertoo hyödyntävänsä SaaS mallin mukaisia ohjelmistoja 2008. Toimisto-ohjelmat kuten tekstinkäsittely, taulukkolaskenta, ”powerpoint” ovat jo verkossa ja osa ilmaisia. ERP ratkaisun saa jo mm. avoimena lähdekoodina ja/tai SaaS -ratkaisuna jolla voidaan alentaa lisenssoinnista syntyviä hankinta- ja vuosilisensointi kustannuksia. Myös PhotoShop löytyy verkon ylitse käytettävänä. ERPin osalta tosin avoimen lähdekoodin ratkaisun käyttöönotto vaatii roimasti rohkeutta sillä kyse on yrityksen ydinliiketoiminnan pyörimisestä ja mitä suurempi yritys, sen vähemmän kiinnostusta tähän on (jos putoaa korkealta, sattuu kipeämmin).

Mutupohjalta arvioituna epäilen että PK-sektorilla ollaan tämän suhteen pisimmällä jo siitäkin syystä että toimintaa voi pyörittää vaikka kaikki ei toimisikaan täydellisesti. Suuressa talossa jos automatisoidut prosessit kaatuvat, seurauksena on paskahalvaus sekä lähettäjän että vastaanottajan päässä. PK-sektorilla ei myöskään ole isoja organisaatioita ja tietohallintoja pyörittämässä IT:tä. Nuoremmat käytännön työtä tekevät IT-osaajat suosivat mielestäni avointa lähdekoodia muita enemmän koska he ovat tottuneet käyttämään vastaavia ohjelmia ja ymmärtävät että jos bugeja on, ne voidaan korjata itse tai vaihtoehtoisesti ostaa ratkaisusta virallinen versio ja tuki. Heidän ei myöskään tarvitse pohtia arkkitehtuurisia sopivuuksia tai sopivuutta 10 vuoden päähän. Tähän liittyen luin mielenkiintoisen artikkelin blogista ”Pölli Tästä”, jossa käsiteltiin juuri ihmisten kouluttautumisen ja innokkuuden välistä eroa. Artikkeli sopii hyvin tähänkin.

Millaisia palveluja voisi hankkia?

Pikaisesti ajatellen PK-sektorilla seuraavista palveluista voisi olla hyötyä:

  • Laskutuspalvelu jonne syötetään tilaukset/laskut tai joka noutaa laskutusaineiston halutusta osoitteesta (laskutus kokonaan ulkoistettu perintää myöten taholle joka lähettää laskut sähköisenä eteenpäin).
  • Tilitoimistopalvelut. Syötetään itse kirjanpitoon tulot ja menot tai on olemassa palvelu, johon voidaan lähettää yrityksen sähköiset tiliotteet suoraan pankista (patukey-tunnusten avulla tilitoimisto hakee tilitapahtumat per asiakasyritys)
  • Asiakkuudenhallinta (esimerkiksi SugarCRM tai Salesforce). Integraatiot sähköposteihin.
  • Sähköposti ja web-palvelut. Hyvä ratkaisu sähköpostitileihin on mm. Kerio.
  • (IT-ala) Projektinhallintapalvelu. Näitä löytyy paljon sekä avoimena lähdekoodina maksutta tai palveluna.

Hypetystä vai ei?

Internetpohjaisissa työkaluissa on monia etuisuuksia; Lisenssoinnin ja asennusten hallinta helpottuu, paikallisen it- ja sovellustuen tarve vähenee (ei asennuksia, ei käyttäjien luomia sovellusvirheitä, päivityksiä), yrityksen työntekijöille voidaan hankkia tietty määrä koneita käytettäväksi mutta ei välttämättä nimikkokoneita (vrt. kelluva lisenssointi), jne. Eräs merkittävä asia on myös investointien poistuminen ts. SaaS mallissa kirjataan kustannukset muuttuviin kuluihin eikä investointeihin.

Jos kaikki työkalut olisivat enemmän tai vähemmän selainpohjaisia tai toimisivat millä tahansa käyttöjärjestelmällä (Java), ei käyttäjän koneella tarvitsisi olla yhtään ohjelmaa. Käyttäjälle pitäisi riittää että hän kirjautuu yrityksen aloitussivustolla sisään (SSO – Single Sign On) jonka jälkeen näkee kaikki ne työkalut, jotka hänelle olisi annettu käyttöön. Enää ei ehkä myöskään kannattaisi tallentaa dokumentteja työasemalle vaan ne voitaisiin tallentaa verkkoon jolloin vaikka kone vaihtuisi/hajoaisi/varastettaisiin, ei mitään arvokasta koneen mukana voisi mennä. Tämä on tosin nykypäivää monessakin yrityksessä – jos ei muuten niin varmuuskopioiden muodossa.

Mitä tapahtuu seuraavaksi SaaS -markkinoilla?

Seuraava vaihe SaaS verkostossa on varmaankin että suurimmat SaaS palvelua tarjoavat tahot integroituvat toisiinsa ja näin voivat tarjota käyttäjilleen entistä parempaa SaaS palvelua (esim. sähköinen laskutus, tilitoimistopalvelut, jne). Jonkinlaista komissiointia tulee varmasti myös tapahtumaan koska tällöin jokainen SaaS palvelua myyvä yritys voi ehkä myydä toisten SaaS-yritysten palveluja integraatioiden kautta.

Aiheesta muualla:
SaaS-tuotteiden käyttö yrityksissä lisääntyy vauhdilla
Open Source rynnii SaaS jakeluun
Software as a Service – ohjelmistot palveluna: Mirva Anttila, IBM Ohjelmistot
SaaS Nähdä: PasiM
www.saas.com

Read Full Post »

SAP SD opas

SAPin oppaita löytyy jo paljon muualtakin kuin SAPin SDN, Help tai Notes sivuilta. Yksi tällainen on mm. http://www.scribd.com josta löytyy paljon käytännön läheistäkin dokumentaatiota PDF muodossa ladattavaksi. Tässä esimerkki SD, eli myynnin ja toimitusten moduulista. Sisältö: Master Data in Sales & Distribution, Pricing and Conditions, Availability Check and Requirements in Sales and Distribution prosessing, ATP in shipping, Delivery blocks, Shortage checks, Credit and Risk management, Output determination, Message determination, Rush order, Complaints, Free-of-Charge delivery, Credit memo Request, Invoice correction, User-Exits, Transportation…

Sap Sd Tutorial

Read Full Post »

Globaalien, standardien tuote- ja tavararyhmähierarkioiden avulla yritys joka hankkii tai myy tuotteita ja palveluitaan globaalisti, kykenee tehostamaan ja parantamaan prosessejaan läpi organisaation. GS1 on voittoa tuottamaton organisaatio on toiminut 30 vuotta keskittyen globaalien standardien suunnitteluun ja kehittämiseen toimitusketjussa. GS1 aikaansaamat menetelmät ja standardit helpottavat merkittävästi pk-sektorinkin yritysten liiketoimintaa ja me kerromme tässä artikkelissa vinkkejä kuinka tämä tapahtuu.

GS1:n päätoimialueet ovat viivakoodit (numerointi ja viivakoodit yrityksittäin), eCom (EDI eli sähköisten sanomien välitykseen standardit), GDSN eli data synkronointi ja EPCglobal eli RFID standardit. Tässä keskitymme lähinnä EDI ja GDSN standardien hyötyjen löytämiseen.

Yritykset voivat tehostaa prosessejaan huomattavasti

Hankittaessa tavaraa toiselta osapuolelta vaikeimmaksi asiaksi nousee usein tuotteiden perustaminen järjestelmiin ja halutulla laadullisella tasolla. Tavarantoimittajilta saadaan tietoa vaihtelevasti toimittajasta riippuen, eikä varsinkaan pk-yrityksellä ole suurtakaan sananvaltaa tiedon suhteen. 3 miljoonan euron liikevaihtoa pyörittävän kaupan on hyvin vaikea vaatia suurta 400 miljoonaa euron vuotuisella liikevaihdolla toimivaa tavarantoimittajaa lähettämään tuotteisiin liittyvät tiedot muussa kuin paperimuodossa. Ymmärrän hyvin, jos pienet kaupat haluavat toimia yhä paperin kanssa, mutta että isotkin toimittajat toimivat vielä nykypäivänä valitettavan usein näin. On käsittämätöntä havaita että tavarantoimittajat eivät kykene lähettämään tuotedataansa sähköisessä muodossa vaikka Microsoftin excel ja muut ratkaisut ovat todennäköisesti kaikilla käytössä ja sähköpostia kaikki osaavat riittävästi käyttää.

Tavarantoimittajalle sähköiset ratkaisut voivat olla merkittävä kilpailuetu

Jos tavarantoimittaja kykenee lähettämään tietoja sähköisessä muodossa vaikka edes excelillä ja jälleenmyyjä kykenee tämän viemään omaan järjestelmäänsä riittävän tiedon kera, ollaan otettu jo hyvä askel tehokkuudessa suhteessa tuotteiden perustamiseen käsin. Jos lisäksi tuotetieto ja rakenteet ovat laadullisesti hyvällä tasolla tämä vähentää myöhemmässä vaiheessa paljon lisätyötä (mm. verkkokauppaan tuotetiedot ja markkinointitekstit).

Tässä tavarantoimittajille mietinnän arvoinen asia: Jos jälleenmyyjä kykenee vähentämään tuoteperustamiseen liittyvää työtä esimerkiksi 20htp/kk, jälleenmyyjähän tekee parempaa tulosta säästöjen kautta ja voi tätä kautta ostaa enemmän tms. Tämä on mielestäni todellinen kilpailuvaltti tavarantoimittajille ja mitä enemmän tavarantoimittaja kykenee tarjoamaan automatiikkaa jälleenmyyjälle tuotteen myyntiin saattamiseen, sen vähemmillä kustannuksilla jälleenmyyjä pääsee ja molemmat hyötyvät. EDI-, tuotedata, laskutusrajapinnat ovat tätä nykyä arkipäivää eikä näiden toteuttaminen vaadi suuria investointeja olipa ERPinä sitten vaikka SAP. Enemmän on kyse tahtotilasta ja halusta tehostaa prosesseja. Jos tavarantoimittaja tukee standardimalleja ja hyödyntää niitä liiketoiminnassaan, on kyse enemmän siitä, kuka jälleenmyyjä on riittävän edistyksellinen vastaanottamaan tarjottua dataa (usein hyvin pienet kaupat toimivat vielä paperilehtiön ja yksinkertaisen kassakoneen avulla ilman ERP tai muitakaan järjestelmiä).

Manuaalisen tuotedatan ylläpidosta syntyvät virheet työllistävät läpi prosessin

Manuaalisesti syötettävän tuotetiedon osalta ongelmaksi muodostuvat inhimilliset virheet. Jos ei ole käytössä minkäänlaista validointia sen suhteen onko kaikki kentät täytetty (ja oikeellisella datalla) on hyvin vaikea poistaa inhimillisistä virheistä johtuvia ongelmia. Ongelmat eivät yleensä tule heti esiin vaan tilanne kärjistyy siinä vaiheessa kun tuotetta yritetään hankkia, ottaa varastoon, myydä tai laskuttaa. Tässä vaiheessa aletaan metsästämään tuotteen muutoshistoriasta, mitä tuotteelle on tehty ja milloin ja yritetään katsoa onko kaikki tarvittavat kentät täytetty asianmukaisesti. Jonkinlaisilla validointiraporteilla voidaan ongelmia löytää ja korjata nopeammin, mutta siltikin tämä vaatii käsityötä joka voitaisiin välttää. Pahimmat virheet vääristävät jopa katelaskenntaa tai liikevaihtoa käsittelevien raporttien sisällön jolloin luottamus koko järjestelmään huojuu. Näitä ongelmia löytyy jokaiselta ERP talolta, toisilta vain huomattavasti enemmän kuin toisilta.

Hintojenkaan muutokset eivät välttämättä tarvitse olla manuaalisia

Hinnoittelunkaan osalta työn ei tarvitse kokonaan olla manuaalista. Esimerkiksi SAPissa on olemassa ns. PRICAT sanoma (joka kai käytössä yleisestikin), jolla tavarantoimittajat voivat ilmoittaa ostohintojensa muutoksista jälleenmyyjille ja jälleenmyyjät tällä tavalla päivittävät ostohinnat ajantasalle. Tällä tavalla jälleenmyyjillä olisi aina käytössä oikeellinen ostohinta eikä tarvittaisi lisäyhteydenpitoa ja manuaalista työtä varmistamaan nykyhetken hinta puhumattakaan ongelmista joita väärä ostohinta jälleenmyyjän toiminnassa saattaa aiheuttaa (tilataan väärillä ostohinnoilla, otetaan tavarat vastaan ja varastoidaan jolloin varastoarvostus vääristyy,..). Tämä formaatti ymmärrykseni mukaan on myös otettu osaksi GS1 standardeja ja määrityksiä.

Sähköisen kaupankäynnin edellytyksenä tiedon saatavuuden ”helppous” ja rajapinnat muihin järjestelmiin

Tavararyhmärakenteen toteuttaminen oman mallin mukaiseksi ei usein ole kovinkaan järkevää varsinkaan kun tähän on olemassa valmiita rakenteita joita käytetään yleisesti tavarantoimittajien toimesta. Tällaisia ovat mm. Kaukeva ja globaali malli GDSN. Kaukevaa käytetään Suomessa mm. Sinfoksessa, mutta kansainvälistä liiketoimintaa suunnittelevan kannattaa siirtyä heti käyttämään GDSN rakenteita. Rakenne ei ole pelkästään tavararyhmittely vaan se sisältää riippuvuuksia jotka auttavat huomattavasti mm. verkkokaupassa.

Mielenkiinnosta latasin GDSN zip-paketin, joka sisälsi Camping osa-alueen rakenteen ja täältä erityisesti telttoja katsoessani huomasin, että tavararyhmien riippuvuudet on määritelty myös tavararyhmätasolla. Myytäessä verkkokaupasta esimerkiksi telttaa voidaan siis helposti samalla näyttää telttaan kuuluvat laajennukset ja lisävarusteet koska kategoriat on GDSN mallissa jo huomioitu. Tämä helpottaa huomattavasti tuotetiedon ylläpitoa. Joidenkin tuotteiden kuten puhelinten osalta lisälaajennukset ovat tarkasti rajattuja ja sopivat yhteen vain tietyn merkkisen puhelimen kanssa ja näiden osalta riippuvuudet voidaan joutua määrittämään tuotetasolla, ellei käytetä tavararyhmä + brändi/ominaisuus yhdistelyä, jossa haetaan ensin riippuvuudet tavararyhmätasolla ja vielä nämä rajataan esitettävän tuotteen brändin tai ominaisuuden mukaan. Tällöin edelleenkään ei tarvitse tuotetasolla luoda riippuvuuksia joka olisi manuaalisesti suoritettuna iso työ varsinkin verkkokaupassa, jossa on kymmeniä tai satoja tuhansia tuotteita.

Read Full Post »

Niin keskisuuret kuin isotkin yritykset tarvitsevat toiminnassaan luotettavan masterdataratkaisun tuotteiden, asiakkaiden (ja toimittajien) hallintaan. Useat yritykset ovatkin kuumeisesti etsimässä jonkinlaista keskitettyä masterdatan hallintaratkaisua palvelemaan yrityksen kaikkia liiketoiminta-alueita eikä valinta ole helppo. Tämän on huomannut myös Sun Microsystems, joka julkaisi toukokuun 1. päivä tiedotteen, jossa he ilmoittivat perustaneensa yhteisön joka yhteistyössä voisi kehittää avoimiin standardeihin ja määrityksiin perustuvaa Mural MDM ratkaisua.

Masterdatan keskitetty ylläpito on viime vuosina nostanut päätään yhä enemmän, mutta pk-sektorille tilanne on haastavampi; Usealla pk-sektorin yrityksellä on tarve saada ratkaisu käyttöön, mutta käyttöönottokustannukset nousevat usein korkeiksi. Pelkän lisenssin hankkiminen voi maksaa kuusinumeroisen summan ja isoimmille yrityksille vielä enemmän. Ratkaisun pitäisi tukea yrityksen koko liiketoimintaa ja usein käyttöönoton myötä tapahtuu myös organisaatiollisia muutoksia; On perustettava masterdatan hallintatiimi joka keskitetysti vastaa datan oikeellisuudesta ja ajantasaisuudesta.

Lähtökohta: Eri järjestelmät tarvitsevat erilaista tietoa

Mitä enemmän yrityksellä on käytössään erilaisia järjestelmiä, sitä tarpeellisempaa keskitetty masterdatan hallinta on. Jos on useita ERP järjestelmiä, verkkokauppaa, portaalia jne. nämä kaikki pitää saada toimimaan keskitetyn masterdataratkaisun kanssa saumattomasti yhteen.

Usein ERPiin viedään vain toiminnanohjauksessa tarvittava data kuten tieto mistä maista ja toimipisteistä tuotetta myydään, missä sitä varastoidaan, keneltä ostetaan jne. Verkkokaupan data on hieman erilaista. Siellä tarvitaan markkinointitekstejä, tuotekuvia ja muita tuotteeseen liittyviä lisädokumentteja kuten PDF:iä. Mainoksiin tarvitaan tuotteen nimiä, hintaa, kuvaa jne. Pakkaan jos lisätään vielä tuotteen valmistuksen tarvitsemat tiedot, voi hyvin ymmärtää sen problematiikan, jonka kanssa tietohallinto painii.

Ensimmäinen etappi, olipa kyse mistä tahansa MDM ratkaisusta on yleensä tarve muodostaa globaali malli (rakenteellinen kuvaus) tuotteille, asiakkaille, toimittajille. Tämä globaali malli pitää sisällään kaiken mm. tuotteeseen liittyvän tiedon mitä yritys liiketoiminnassaan tarvitsee. Tästä mallista luodaan sittemmin tietorakenne MDM:n sisälle. Rakenteeseen voidaan myös määritellä, mitkä tiedot ovat pakollisia ja mitkä eivät. MDM ratkaisuissa näitä rakenteita voidaan ketjuttaa ja luoda useitakin malleja jossa mm. tuotteelle esimerkiksi talopaketti tai lipasto, voidaan luoda rakenteellinen kuvaus joka sisältää kaikki pakettiin kuuluvat osaset. Se voi pitää sisällään myös pienimmät osaset kuten ruuvien ja naulojen määrät sekä kokoamisohjeet.

Integroitavuus

Masterdatan käyttöönotossa ensimmäisenä tulee antaa vastaus siihen, millä skenaariolla MDM toimii. Toimiiko se kaksisuuntaisesti järjestelmien välillä vaiko halutaanko todellista keskitettyä masterdatan hallintaa ja estetään muutosten tekeminen muissa järjestelmissä. Tämä vaikuttaa myös olennaisesti tehtäviin integraatioihin.

Mural MDM yhden yön testaamisen jälkeen vaikuttaa mielenkiintoiselta työkalulta ja varsinkin integroitavuuden suhteen siinä on potentiaalia. Integroinnissa varsinkin ERP järjestelmiin törmätään usein tilanteeseen jossa toimintaa ohjaavia parametrejä täytyy ylläpitää tavalla tai toisella ja jos konfiguraatiota muutetaan ERPissä pitäisi myös MDM:ssä vastaavasti muuttua näiden attribuuttien mahdolliset arvot.

Jos halutaan integroida esimerkiksi tuotteet verkkokauppaan siten että keskitetysti julkaistaan MDM:stä tuotetietoa, jossakin on tehtävä tuotemäppäys globaalista mallista kohdejärjestelmän ymmärtämään muotoon ja suoritettava lähetys, joka onnistuu helposti Web Services rajapinnoin. Mural MDM:ssä näytti olevan valmiina rajapinnat: Amazon, Delicious, Facebook, Flickr, Google, Twitter, WeatherBug, Yahoo, Zillow ja Zvents. Voisi nopeasti kuvitella, että uusien Web Services rajapintojen käyttöönotto ei mikään kovin suuri koodaus-sessio ole ja usein kohdejärjestelmästä on ladattavissa suoraan tarvittavat kuvaukset joka edelleen nopeuttaa rajapintojen toteuttamista.

Integraatioissa olennaista on saada myös välittömästi tieto tiedon lähettämisen onnistumisesta – mieluiten keskitettyyn valvontaohjelmistoon. Tällä tavoin voidaan nopeasti puuttua ongelmatilanteisiin ja seuranta on vaivattomampaa.

Mural MDM

Pikaisesti silmäiltynä ja testattuna Mural MDM käyttöönotto itsessään ei vie paljoa aikaa eikä integraatioiden toteutuksestakaan luultavimmin muodostu järjetöntä työmäärää avointen standardien vuoksi. Suurin hyöty Mural MDM:n käyttöönotolle lieneekin sen lisenssoinnissa ja avointen standardien tuessa. Muralista on saatavana kaupallinenkin versio.

Ratkaisuun löytyy yksinkertainen asennusskripti jolla järjestelmän saa osittain käyttöönsä joka vie tunnin pari aikaa. Pätevältä Java-osaajalta järjestelmän pystytys ja perustoimintojen opettelu vie muutamia päiviä, joten MDM ratkaisua valittaessa kannattaa myös tämä ratkaisu ottaa huomioon varsinkin jos kilpailevat tuotteet ja ratkaisut maksavat kuusinumeroisia summia.

Tästä ratkaisusta saattaa hyvinkin tulla kova kilpailija IBM:n Product Centerille, SAPin MDM:lle ja lukuisille muille isojen talojen masterdataratkaisuille kunhan saavat muutaman asiakascasen taakseen tai julkisuuteen.

Lue myös:

MDM -ratkaisun valinnan 10 yleisintä virhettä

Mural: Open Master Data Management Community

Sun Microsystems Announces Mural: Open Master Data Management

Hands On Tutorial: Building Single Entity Views Using Mural Projects

Sun CAPS 6 Has the right vision

From Author: Reliable Open-source Master data solution

Read Full Post »

Nykyiset tietovarastointimallit ja ratkaisut eivät pidä useinkaan sisällään niitä tekijöitä, mitkä menekin ennustamiseen todella vaikuttavat. Yksi tällainen tekijä on mm. sää. Tämä artikkeli esittelee idean, kuinka järjestelmä voisi automaattisesti tehdä ennusteita ottamalla huomioon halutut muuttujat. Menetelmä on sama, jolla ennustetaan mm. pörssikursseja, tunnistetaan lääketieteessä syöpäsoluja ja jota käytetään mm. kunnossapidon puolella ennustamassa laitteiden vikaantumista. Ennustamisen tarkkuus paranee ajan myötä ja kerätty data tarvitsee ajaa vain kerran verkon läpi, jonka jälkeen alkuperäistä dataa ei enää tarvita!

Tutkijat pitävät neuroverkkoja oikeana tapana luoda ennustusmalleja, koska se perustuu luonnonmukaiseen tietojenkäsittelyyn. Tällä nimellä itse asiassa kulki aikoinaan ammattikorkeakoulussa myös ko. opintosuuntaus, jonka jälkeen se vaihdettiin tietämystekniikaksi. Neuroverkkoja (varsinkin SOM-verkkoa) käytetään yleensä sellaisten ongelmien ratkaisemisessa, joille ei ole voida muodostaa matemaattista kaavaa. Tällaisia ongelma-alueita ovat mm. erilaiset tunnistamisongelmat kuten hahmontunnistus, syöpäsolujen tunnistaminen, pörssikurssien ennustaminen, shakkipelit jne.

Mitä ovat neuroverkot?

Neuroverkkoja on tutkittu vahvasti viime vuosina Suomessa sekä maailmalla ja saatujen tulosten avulla on luotu merkittäviä teknologisia sovellutuksia eri teknologia-alueilla, kuten lääketieteessä ja peliteollisuudessa. Teuvo Kohonen on yksi ansioituneimmista tutkijoista neuraalilaskennan parissa ja hänen keksimänsä itseorganisoituvan kartan sovellutukset ulottuvat hyvinkin laajasti liiketoiminnan eri osa-alueille. Itseorganisoituva kartta onkin eräs tunnetuimmista neurolaskenta-algoritmeista.

Itseorganisoituva kartta (Self Organizing Map) on Kohosen luoma verkkomalli, jolle ei opetusvaiheessa kerrota lähtötietoa. Verkko muodostaa itse lähtötiedon eli tällöin voidaan sanoa verkon oppivan ohjaamattomasti, toisin kuin backpropagation –verkoissa, jossa opetus tapahtuu vertaamalla tulosta ilmoitettuun tulokseen, eli referenssivektoreihin. SOM –verkko oppii kilpailemalla, jossa voimakkaimmin aktivoituneiden neuronien aktivointitasoa voimistetaan ja muiden neuronien aktivointitasoa vastaavasti heikennetään. Näin syntyy verkkoon erilaisia ”alueita”, joilla kuvataan materiaalissa olevia luokkia.

Seppo Karjalaisen kirjoittamassa kirjassa Neurotietokonetekniikka kerrotaan itseorganisoituvasta verkosta näin: ”Aivojen toiminnassa on keskeistä datan esittäminen mahdollisimman tehokkaasti säilyttäen datan väliset suhteet. Älykkäässä informaation käsittelyssä muodostetaan monimutkaisesta mittausdatasta yksinkertaistettuja kuvauksia. Nämä kuvaukset projisoituvat ihmisellä eri alueille aivokuorella riippuen alkuperäisen mittausdatan luonteesta”.

Lisäksi hän kirjoittaa: ”On viitteitä siitä että hermosolut muodostavat kaksiulotteisia karttoja opituista asioista.” Ja juuri tätä SOM -verkko tekee, muodostaa piirrekarttoja opituista asioista!

Idea ja verkon toteutus

Idea olisi siis toteuttaa järjestelmä, joka oppii itsenäisesti myyntiaineiston yms. datan perusteella jatkuvasti lisää tarkentaen näin ennustusten tarkkuutta.

Olennaisin asia neuroverkon toteutuksessa on määritellä itse verkko ja sisääntuloparametrit. Parametrejä voi olla satojakin, mutta tässä täytyy ottaa huomioon suorituskyky. Mitä suurempi verkko, sitä hitaampi sen ajo on. Usealla pienemmällä verkolla saavutetaan parempi suorituskyky kuin yhdellä isolla.

Verkon sisääntuloparametreja voisi olla mm. Lämpötila, lumi/sademäärä, vuodenaika, myyntihinta, tuotekategoria, myyntikanava, kampanja jne… Nämä parametrit täytyy tulla ammattilaisilta jotka tietävät, mitkä tekijät esimerkiksi myyntiin vaikuttavat. Nämä tiedot täytyy myös kyetä keräämään päiväkohtaisesti, jos menekkiä halutaan päivätasolla ennustaa. Jos ennustaminen tapahtuu tavararyhmätasolla, pitää myynti pystyä tuomaan tällä tasolla sisään. Siihen voidaan käyttää esikäsittelyä ts. kerätä myynti tavararyhmätasolla yhteen ja viedä esimerkiksi aputauluun tai suoraan neuroverkolle.

Kun parametrit on löydetty, alkaa verkon luonti. Tästä en tiedä itse paljoa, mutta verkossa voi olla useita solmutasoja ja kolmitasoinen verkko taitaa olla yleisesti käytetty malli. Internetistä löytyy neuroverkkosovelluksiaa (kuten Nenet) joilla verkon voi rakentaa ja testata, mutta jos aikoo tuotteistaa idean, kannattaa kääntyä ammattilaisten puoleen. Neuroverkkotutkimuksen osalta ainakin Kuopion yliopistolla oli aikoinaan kaksikin tohtoria.

Neuroverkko-ohjelmat, mm. MathLab voivat muodostaa itse verkot. C-kielellä (tehokkuus ja nopeus) voitaisiin sitten toteuttaa ohjelmat, joilla kutsutaan neuroverkkoa ja jolla ajetaan dataa verkon läpi.

Ajo eli itse opetus voisi tapahtua öisin, jolloin seuraavana päivänä raportit olisivat luettavissa, taikka reaaliaikaisesti kutsua tietoja suoraan neuroverkosta, mutta uskoisin ensimmäisen vaihtoehdon olevan sopivin useimmille. SOM-verkon opetus pelkistettynä tapahtuu siten, että SOM-verkko luokittelee datan eri alueisiin ja tämän perusteella voidaan analysoida dataa. Olennaista on tunnistaa nämä alueet ja saada tätä kautta ulos järkevä tieto.

Ammattikorkeassa harjoiteltiin aikoinaan neuroverkko-ohjelmilla vastaavanlaisia asioita, jossa mm. luokiteltiin kivilajeja niiden koostumuksen mukaan. Tämä harjoitus oli nopea ja riitti että sisään ladattiin csv tiedosto joka esitti perustietoa. Sitten painettiin paria nappia ja ohjelma opetti verkon ja näytti graafisen esityksen opetustapahtumasta josta nähtiin ettei syntynyt hillclimbing tms. virheitä ajon aikana. Tästä voi vetää johtopäätöksen, että demon tekeminen ei kestäisi kauaa – viikon, pari korkeintaan.

Rajapinnat

Sään osalta toteutus on helppo. Solmitaan sopimus säätietoa tarjoavan yrityksen kanssa, jolloin saadaan käyttöön myös API-rajapinta, jonka kautta voidaan tiedot noutaa järjestelmään esimerkiksi joka yö tai kerran viikossa. Tätä kautta itseasiassa voitaisiin hakea myös ennustettu sääkin ja vaikuttaa näin lähimpien tulevien päivien myyntiin markkinoinnin kautta.

SAP BI -ratkaisua en tunne syvällisesti, mutta toisin kuin BI-raporteilla (ja kuutioinnilla), neuroverkolle tuodaan tarvittavien parametrien mukainen sisältö muokkaamattomana. Tämän voisi toteuttaa niin, että laaditaan API, jonka kautta haetaan päivittäin päivän tiedot eräajona. Vastaava toteutus toimisi millä tahansa raportointijärjestelmällä.

Käyttöliittymä voi olla esimerkiksi selainpohjainen ratkaisu, ts. siitä voidaan tehdä ns. portletti tai SAPin slangin mukaisesti iView jossa näytetään menekki käyttäjän ymmärtämässä muodossa. Tähän portlettiin haetaan tiedot tietokannasta jonne on tallennettu yöllä ajettu menekin ennustaminen.

Jos haluttaisiin tuotteistaa ko. ratkaisu, kannattaisi toteuttaa erilaisia plugin-rajapintoja eri raportointijärjestelmiä varten, jolloin myynti useimmille yrityksille olisi mahdollista.

Kustannukset?

Vaikka koko juttu saattaa nopeasti kuulostaa hypetykseltä – trust me, se on tehtävissä. Neuroverkon ja parametrien sekä ulostuloalgoritmien toteutus on suurin työ koko prosessissa. Tällainen projekti olisi myös sen verran uutta, että todennäköisesti tähän löytyisi tutkimusrahaakin ja halukkaita rahoittajia. Projektin kustannusarvio vaihtelee laajuudesta riippuen, mutta arvioisin sen kokonaiskustannuksiksi kuitenkin vähemmän kuin 500 000 euroa ja jos projekti olisi tutkimusprojekti, omat kustannukset olisivat 20..50% tästä.

Hyödyt?

Perinteisesti järjestelmät ennustavat menekkiä matemaattisten mallien mukaan josta on unohdettu pois mm. säätiedot ja moni muu myyntiin erittäin voimakkaasti vaikuttava asia. Lisäksi järjestelmät eivät todennäköisesti opi (eivät ainakaan samalla tavalla kuin SOM-verkko) historiadatasta mitään vaan suorittavat tiettyjen (kehittäjien ideoimien) mallien mukaisesti ajonsa ja tulostavat ulos ehdotuksen. Näihin järjestelmiin täytyy yleensä syöttää myös merkittävästi lisätietoa jotta ennustaminen olisi ylipäätään mahdollista.

Kuinka moni yritys olisikaan valmis maksamaan tuotteesta, joka ottaa huomioon myös luonnon muutokset. Mikä lisäarvo olisikaan tuotteesta, joka osaa paikkakuntakohtaisesti sanoa, mitkä tuotteet tänään ja huomenna myyvät koska sää tulee olemaan esimerkiksi sateinen koko päivän?

Voin antaa tästä tarpeellista lisätietoa tarvittaessa sähköpostitse.

Lue lisää aiheesta muualta:

18.03.2004, Tekniikka&Talous: Neuroverkko kertoo, kenelle myydä

Kevät 2008: (PDF) Antti Järvelin, Neurolaskenta

6/1996: Neurolaskenta uusinta uutta ilmanlaadun arvioinnissa

MikroPC: nro 12, 2000: (PDF) Kännykkä ymmärtää puhetta ja pc tunnistaa kasvoja

12/2000: (PDF) Neuraalilaskenta ja epälineaarinen dynamiikka komponenttien kulutus- ja myyntiennusteiden laatimisessa

Read Full Post »

Case: Tennesseen osavaltion oikeuskäsittelyjen datan analysointi

Oikeuslaitosta hallinnoiva virasto Nashvillessä kerää oikeuskäsittelyistä tietoa jonka konsolidointi ja käsittelyon vaikeaa monestakin syystä. He laativat suosituksia mm. resurssien käytöstä jotta osavaltion oikeuslaitos toimisi tehokkaasti eri kriteereillä mitattuna (oikeustalo, tuomari, käsittelyn tyyppi jne..)

Tennesseen oikeuslaitos käyttää useita eri järjestelmä eri toimittajilta. Yksi näistä on Tennessee Information System josta käytetään nimitystä TENSIS. Se on OLTP järjestelmä, joka pyörii Microsoft SQL 2005 alustalla ja tämä videon pätkä esitteleekin pitkälti MS SQL 2005 ja siihen liittyviä ominaisuuksia.

Read Full Post »

SAPin strategia siirtyä pois suurista versiopäivityksistä ja alkaa tarjoamaan laajennuspaketteja ”enhancement packages” alkaa versiosta ERP 6.0 ja on kantamassa hedelmää Forresterin tutkijan mukaan. 6700 asiakkaasta arviolta 20% on jo siirtynyt ERP 6.0 ympäristöön sanoo Philip Say, SAP ERP ratkaisun markkinoinnin varapääjohtaja. Siirtymistä vauhdittaa myös SAP R/3 4.6C tuen loppuminen.

Uudenlaisella strategialla yritetään vähentää massiivisia ja usein erittäin kalliita versionvaihtoprojekteja sekä helpottaa erityisesti suurten asiakkaiden toimintaa. Ne jotka ovat jo siirtyneet 6.0 versioon, voivat jatkossa valita pienempiä ns. laajennuspaketteja käyttöönsä joka yksinkertaistaa päivitysprosessia ja samalla minimoi mm. käyttökatkoksia. Asiakkaat ehkä arvostavat sitä, että he voivat valita haluamansa toiminnallisuudet ja testata vain ne paketit, jotka ottavat käyttöönsä. Tämä vähentää testausaikaa ja säästää paljon rahaa, joka houkuttaa asiakkaita kovasti. Paketteja on tarkoitus julkaista puolivuosittain aiemman 2-3 vuoden ison versioinnin sijasta.

Kolikon kääntöpuolena tämä tarkoittaa myös sitä, että kehityksen aallonharjalla pysyminen vaatii vielä enemmän ponnisteluja, varsinkin teknologia-osaajilta. Jos aiemmin tuntui, että ei millään ehdi opiskella tarvittavaa tietomäärää edes omasta osa-alueesta, ei tilanne ainakaan helpotu jatkossa. Nykyäänkin on jo niin paljon lisätoiminnallisuuksia ja -ratkaisuja, että näiden seuraaminen ei onnistu yksittäiseltä konsultilla millään konstilla ellei vuorokauteen joku keksi lisätunteja.

SAPia käyttävistä yrityksistä 80% prosentilla on kuitenkin vielä pitkä matka tähän eikä asiaa auta lainkaan kaikkien asiakkaiden yhtäaikainen halu vaihtaa versiota.

Osaajista tulee olemaan vielä suurempi pula

Jos Forresterin luvut pitävät paikkaansa, Suomessa karkeasti 4/5 osaa asiakkaista ei ole vielä siirtynyt käyttämään uutta SAP ERP 6.0 versiota (olettaen että tehdyt versionvaihdot ovat jakautuneet tasaisesti eri maiden kesken). Suomessa SAPin markkinaosuus on 70% isojen yritysten toiminnanohjausjärjestelmänä josta voi vetää johtopäätöksiä osaaja-tarpeelle.

Tällä hetkellä varsin suosittuja osa- alueita ovat Business Intelligence alueen ratkaisuosaaminen (sisältää myös vastikään SAPin ostaman Business Objectsin) sekä HR (human resources) -osaaminen. SAP:n pohjoismaiden toimitusjohtaja Henrik Rasmussenin mukaan pohjoismaissa tarvittaisiin 800 SAP-konsulttia lisää. Projekteista 13% tekee SAP itse ja loput tekevät SAPin kumppanit.

Vajauksen täyttöön osaajia on haettu Intiasta. Näiden resurssien käytön esteenä on kuitenkin usein kommunikointivaikeudet ja aikaerot, eikä olettamukseni mukaan tämä enää olekaan niin houkuttavaa ja kustannustehokasta kuin ehkä oletetaan.

Versionvaihdon ongelmat

Versioiden vaihtoa jarruttaa monessa talossa tehdyt räätälöidyt toiminnot. Joissakin yrityksissä SAPia on vuosien aikana modattu yhä enemmän ja tehty muutoksia SAPin toimittamiin toiminnallisuuksiin myös muuten kuin User-Exitien kautta. Nämä talot ovat pahimmassa tilanteessa. Jos talot ottavat käyttöönsä myös uutta toiminnallisuutta samalla kertaa, kipuilu tulee pahenemaan entisestään. Rikkana rokassa saattaa olla myös siirtyminen 64-bittisyyteen aiemmasta 32-bittisestä maailmasta.

Parhaassa tilanteessa ovat yritykset, jotka ovat ottaneet SAPin toiminnanohjausjärjestelmän vastikään käyttöön ja esimerkiksi versiosta 4.7 alkaen. Oman kokemukseni perusteella tästä päivitys versioon 6.0 on suoraviivainen ja nopea – olettaen että suurempia räätälöintejä ei ole tehty matkan varrella.

Sinänsä 4.6C tuen loppuminen ja uudenlaisen päivitysstrategian toteutus osuu kohdalleen nappiin. Näiden asiakkaiden kohdalla tekipä niin tai näin, lisälasku on edessä. Se maksetaan joko 4.6C asiakaskohtaisen tuen pidentämisestä (jos edes mahdollista) tai 6.0 versioon siirtymisen myötä syntyvistä projektikustannuksista sekä versiovaihdon jälkeisistä mahdollisista lisälisensseistä joita 6.0 voi tuoda mukaan.

Read Full Post »

06/2008: Maaliskuussa Suomeen rantautunut englantilainen luonnonkosmetiikkayritys Lush Finland valitsi IT-kumppanikseen Solteqin. Solteq toimittaa Lushille myymälä- ja verkkopalvelujärjestelmän sekä tietoliikenneyhteyspalvelut. Lush avasi Espoon Isoon Omenaan ensimmäisen myymälänsä sekä Suomen verkkokaupan maaliskuussa.

Read Full Post »