29.04.2016 / Statisticko

Kirjoitus julkaistu myös Riston omassa blogissa Statistition.com 29.4.2016

Vieläkö muistat, mikä yhteys on uima-altaaseen hukkumisella ja Nicholas Cagen elokuvaesiintymisillä? Vastaus on että eipä juuri mikään, mutta silti niiden välille on mahdollista havaita keskinäistä riippuvuussuhdetta mittaavaa korrelaatiota. Aiemmassa blogikirjoituksessa havainnollistin kuinka korrelaatioita pompsahtelee esiin vain sattumalta kun tarpeeksi montaa eri muuttujaparia kokeillaan. Seuraavassa pureudutaan yleiseen hämäävien korrelaatioiden lähteeseen; aikaan.

Korrelaatio ja aikatrendit

Otin Gapminder –datapankista tiedot Lapsikuolleisuudesta Kiinassa (alle 5v kuolevia per 1000 syntymää) ja Sähkön käytöstä Suomessa (kWh per asukas). Molemmista löytyi dataa vuosilta 1960-2011. Nämä ovat tarkoituksella haetut muuttujat, joilla ei pitäisi olla mitään tekemistä toistensa kanssa. Eihän meillä voi olla niin huono säkä, että data näyttäisi silti niiden välille korrelaatiota? Katsotaan muuttujien välistä sirontakuviota oikealla.

korrelaatiot_sironta
Suomen sähkönkulutuksen ja Kiinan lapsikuolleisuuden sirontakuvio

Vaikuttaisi kuitenkin siltä, että silloin kun Suomessa on korkea sähkönkulutus, niin Kiinassa lapsia kuolee vähemmän. Korrelaatiokerroinkin -0.84 vahvistaa saman: muuttujien välillä on vahva negatiivinen lineaarinen yhteys. Pitäisikö tästä nyt tulkita, että mikäli haluamme pelastaa kiinalaisia lapsia, niin pitää heti laittaa uuni ja sähkösauna päälle?

Tutkitaan seuraavaksi molempien muuttujien kehitystä ajassa erikseen.

korrelaatiot_trendit
Lapsikuolleisuuden ja sähkönkulutuksen aikatrendit

Nähdään, että Kiinan lapsikuolemissa on ollut selvä laskeva trendi ja suomalaisten sähkönkulutuksessa selvä nouseva trendi. Omituinen korrelaatio näiden muuttujien välillä ei selity tällä kertaa sattumalla vaan yhteisellä taustatekijällä, mikä on nyt aikatrendi. Koska trendit ovat erisuuntaiset, korrelaatiokerroin on negatiivinen.

Tutkitaan sitten alkuperäisten havaintojen sijaan muutoksia edelliseen aikapisteeseen verrattuna. Näin saadaan trendit eliminoitua havainnoista, kuten kuvaajista nähdään.

Muutosmuuttujien kehitys ajassa
Muutosmuuttujien kehitys ajassa

Näiden muutosmuuttujien välille laskettu korrelaatiokerroin on -0.03. Tämä on niin lähellä nollaa että voimme turvallisesti sanoa ettei Suomen sähkönkulutuksen muutoksella ole mitään yhteyttä saman vuoden Kiinan lapsikuolleisuuden muutokseen. Varmistetaan asia vielä piirtämällä sirontakuvio ja havaitsemalla ettei yhteistä systematiikkaa löydy.

Muutosmuuttujien sirontakuvio
Muutosmuuttujien sirontakuvio

Autokorrelaatiot

Myöskään trendittömien muuttujien aikahavaintojen tutkiminen ei ole aivan yksinkertaista. Mikäli olemme kiinnostuneita epävarmuudesta ja korrelaation tilastollisesta merkitsevyydestä, usein päävaivaksi tulee autokorrelaatio. Tällä tarkoitetaan sitä että saman muuttujan peräkkäiset havainnot korreloivat keskenään. Perusmenetelmiin liittyvä oletus riippumattomasta satunnaisotoksesta ei nyt päde ja kahden autokorreloituneen muuttujan riippuvuuden tutkimiseen on parempi käyttää esim. vektoriaikasarja-malleja.

Tilastoja tutkimaan

Lopuksi pitää vielä kehua datapankkia, josta lapsikuolleisuus ja sähkönkulutusdatat ovat haettu. Sivustolta löytyy läjäpäin muutakin terveys-, talous- ja muuta yhteiskunnallista dataa ympäri maailmaa ja niitä voi kätevästi graafisesti tutkailla tällä sivustolla. Mutta pidäthän tämän blogin opetukset mielessä ennen kuin vedät johtopäätöksiä liittyen syy-seuraus suhteisiin. Lopuksi voi vielä viihdyttää itseään käymällä tsekkaamassa vanhaa sivua, jossa on koottuna huumorikorrelaatioita. Nyt pitäisi olla valmiudet perustellusti spekuloida jokaisen kuvaajan kohdalla, johtuuko korrelaatio

  • jostain yhteisestä taustamuuttujasta
  • aikatrendistä
  • sattumasta
  • aidosta riippuvuussuhteesta
  • vai jostain edellisten yhdistelmästä.

Statistickon steesit

  • Aikatrendi on yleinen taustatekijä, joka selittää kahden muuttujan näennäisen riippuvuuden
  • Ajassa itsensä kanssa korreloituneita muuttujia tulee syvällisemmin analysoida aikasarja- tai pitkittäistutkimusmenetelmillä
  • Maailma on täynnä mielenkiintoisia tilastoja, mutta niitä on helppo ymmärtää väärin

26.04.2016 / Rickard Kallis

Bilot’s Customer Engagement consultants joined in a hackathon spirit to find out what SAP Hybris Cloud for Customer 1605 release had hidden under its hood. If you are not familiar with the product, Hybris Cloud for Customer (a.k.a C4C) is SAP’s cloud-based CRM system. The software supports sales, customer service, field service as well marketing processes. The nicest features include a modern user interface that scales out-of-the-box to practically any device. Now you might ask yourself, why we must have a hackathon for this? Well, we must not have it, but let me explain why we wanted to have it.

First of all, as it is a cloud software, there are regular updates every quarter that are automatically upgraded to every tenant, and there are usually a lot of new features released. For us working intensively with the solution the releases are significant milestones.  The release notes are in general around 200 slides long. In practice, you need to update your knowledge regarding the solution quarterly, to be able to give recommendations, not even speaking of implementing them. It is also as important to know how the new features might affect the existing solutions. Our customers expect us to be on top of these things and provide them with up-to-date recommendations. They, of course, love when we are quickly able to solve issues that might occur after an update, or even be proactive and point out potential failures in advance.

Secondly, this is a way more fun way to do it – a way that breaks the pattern of the day to day habits. The concept is generically called gamification, which has proven to be an excellent method for boosting workplace productivity and a great source of creativity. By collectively joining forces in a hackathon-like setting, we can cover more ground much faster. At the same time, there is a lot more knowledge sharing happening. A phenomenon that needs to be fostered in a world of digital knowledge work. Gatherings like these are the source of innovations where people are exchanging ideas without a formal structure. Innovation, however, is a topic that I need to come back to in another blog post.

Bilot's Customer Engagement consultans hack the 1605 release of SAP Hybris Cloud for Customer.
Bilot’s Customer Engagement consultans hack the 1605 release of SAP Hybris Cloud for Customer.

 

So the features for this release? First of all, the most noticeable change was that the product has now officially been re-branded to SAP Hybris Cloud for Customer, from previously just being SAP Cloud for Customer. This was an expected move by SAP to now be able to offer all of their products in the Commerce and Customer Engagement suite under the Hybris brand.

Secondly, another aspect that cannot go unnoticed is that SAP is investing in bringing new features that will support customers using the field service functionalities. The system now supports the “van stock”, which can be utilized to show the technicians on the field an up to date stock list. There are some new features for maintenance plans. You will now have even more options for the maintenance intervals, which are used to trigger service tickets. Time recording can now be done on an item level, and there are also rounding rules available. The resource scheduler has been improved to take service technicians’ availability time, and there is also a color coding available for different assignments, for easier work distribution.

The other areas did no remain untouched, despite the investments in the fields service. The sales area saw some improved features for merging accounts and contacts. Now you can merge accounts that belong to an account hierarchy, and as a added feature you can also merge accounts and contacts with leads and opportunities. The marketing side got a long waiting feature finally launched – dynamic target groups. This now allows users to create target groups that are automatically updated based on certain key figures.

Then there were a ton of user interface improvements. The ability to expand and restrict list lengths will for sure be a feature that will be implemented here and there. The mobile applications also got updated of course. Some new offline features were launched, the product list being one of them. Possibility to download to excel on mobile devices and also a business card scanner were released. I could go on, but these were just some examples of the new features added in the May 2016 release.

If you have questions regarding the new release or think that we could be in assistance with the new features, please feel free to contact us. See you at the next hackathon!


26.04.2016 / Mikko Mattila

Hadoop designed to solve issues impossible for the traditional commercial tools

 

In the first summary part of my blog series I opened background of the big data tools. We discussed how the different components originally born to solve issues more challenging than traditional enterprise IT architects and operators even wanted to think. Therefore I claim that Hadoop tools are extremely well designed and have excellent features for almost every company.
Before going more into the details, let’s get back to history of big data. Roughly twenty years ago internet startups found a low cost and open source software to build their services. On the high level the main difference was economics behind them and pretty much made the internet boom possible. Like I mentioned earlier, suddenly you didn’t need to have a significant funding to set-up an IT or internet company.
However, these open source tools pretty much copied the functionality of commercial tools. As examples, the Linux operating system on the low cost commodity intel servers took their place in the servers. We Finns where proud about MySql as the de facto open source database among the PostgreSQL. Similarly the Apache web server became the standard to run static html- and php-pages. If you needed a full scale java-application server Jboss was available for free etc. From the architectural and functional point of view there was not major difference between the open source and commercial tools, though.
The new era of internet and the new infrastructural components running it did not change dramatically the enterprise software sector and economic of it, either. Majority of enterprise software vendors started to use the same open source software components embedded into their products – like providing MySql as an embedded free repository database option or embedded Apache tomcat as application server instead of building their completely own ones. As 95% of added value still came from their proprietary code and professional services tightly bound to it, the business logic of enterprise software has been pretty much the same until these days.
But change is happening now. Under the shadows these new internet companies grew faster than we had ever seen. Quickly they run into overwhelming technological challenges, which the traditional software tools, commercial or open source, never needed to tackle. The new comers needed to invent how to provide almost 100% automated service 24/7/365. They needed capability to add hardware, upgrade platform software versions and develop application further without any kind of downtime ever. This means that you need 100% fault to tolerance, no single point of failures, software capable for rolling upgrades, an excellent monitoring and automated management from few servers to thousands of servers with a minimal labor. Amount of data managed can be 100 or 10000 times bigger than in a traditional large enterprise. 24/7 solutions do not have “a night time” for the batch jobs and software need to scale linearly as you add hardware. Some of the start-ups found solutions for these issues and as results we have Facebook, Yahoo, Linked-in, Twitter etc.
Let’s take a few examples how certain Hadoop tools are different from the traditional ones. For example the traditional databases can be clustered, but a cluster of dozens servers is already very large. The replication of data among the servers is done on software layer. At the same time a traditional database locks rows and even whole table at the time of updates and deletes. As the result the maximal cluster size is very limited. To resolve the issue Yahoo created a completely new kind of file system (HDFS) – way files are stored on the disk. This file system is “distributed” so the “operating system” of Hadoop already makes same data files available on multiple servers. The method is completely license free. Traditionally the same result has required an expensive hardware and still it does not scale for clusters of thousands servers like the HDFS-file system method. About at the same time Google invented a new way for going efficient parallel processing on large amount of servers – the Map Reduce language mentioned in the previous blog. Map Reduce can also do more complex processing than SQL and the processed data can be even unstructured (like text or photos). Together HDFS and Map Reduce provided way to do advanced querying and processing of extremely massive amounts of data. As Yahoo and Google where tackling with the batch processing of the data, LinkedIn had challenges to integrate all of their system in real-time and batches. They ended up moving to a completely real-time architecture and developing own messaging software for it – Kafka. The main difference is superior throughput compared to traditional messaging servers. Kafka can also store messages exceptionally long – default setting being seven days. These companies shared the code with each other. Also others joined in and the Hadoop project was born under Apache organization.
Of course Hadoop tools are not perfect from every aspect. As in case of IKEA they are not polished luxury. There is not a nice graphical UI for everything and you need to work with configuration files. In general they are performance and high availability optimized, but as compromise a traditional software for the same purpose may have more features. But the main question is, would you really use those features and are they worth of money.

But like in case of IKEA, all of your furniture is not from them. Similarly, Hadoop tools may replace only parts of your existing platforms. Merely you will extend your existing landscape with these tools. There is still room for traditional messaging servers and especially relational databases.

Read more:
Tuomas Autio: In love with Hadoop deployment automation
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 1
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 2
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 3


22.04.2016 / Mikko Mattila

Hadoop and other open source Big Data projects provide huge range of IT software for areas of data management and system integration

 

In the first part of my blog series I claimed that Hadoop offers a superior range of tools to do amazing things. The summary blog emphasized the marriage of analytical aspects and real time system integrations and messaging. The purpose of this part is to depict what those tools really are and the purpose of each.
In the terms of a traditional data warehousing and analytics tools the process of data loading and transformation in Hadoop is closer to ELT (database pushdown centric) than ETL (ETL server centric transformations). For the data extraction from relational databases we have Sqoop. For sourcing a continuously generating log files we commonly use Flume. If the source systems provide transfer files, we drop them to the Hadoop file system (HDFS) and use them directly or indirectly as the “data files” of Hive “database”. The Hive component provides a database query (SQL + odbc/jdbc) interface to Hadoop. In practice this means that the schema descriptions are defined on the top of your data files (for example csv-file) and you can use SQL to query and insert data. The transformation part of data management is done with a Latin language.
As you are ready with the things you have done years with ETL and data warehouses, with Hadoop you can move to the area of real data science. The Pig Latin language is actually a simplified way to write powerful Map Reduce language. Map Reduce is Hadoop’s programming language to do deep analysis of a huge amount of data. The drawback of Map Reduce is the need for writing code – even bit too much for simple things. If you do bother to learn the Map Reduce syntax, check Spark. Spark allows you do the same things and even more with one of the languages you probably already know: SQL, Java, Scala, Python or R. Actually you can even mix them. As the languages mentioned here may indicate Spark includes statistical libraries for even a deeper data science analysis and graph database functionalities for understanding how Social Media connections, products in market baskets and telecom subscribers form networks. The understanding of the networks is important for identifying the real influencers and you can focus your action on them. Spark also loads data under processing into memory and does all processing even 100 times faster than Map Reduce or Hive.
Spark has even move advantages. It can run in a stream mode, meaning that it processes, merges and other ways enhances and transforms your data as it flows in and pushes it out to a defined storage or a next real time process. In the traditional terms it is a component to do complex event processing. So we have arrived to the area of traditional Enterprise Application Integration (EAI) and messaging. Another bit more traditional Hadoop component for the complex event processing is Strom. In system integrations, before complex event processing, you need way to manage message flows i.e. you need a message queue system. For that purpose the Hadoop umbrella has Kafka. Kafka is fed by different streaming sources like Flume mentioned earlier, more traditional EAI tools or SOME sources like Twitter directly.
How do we then integrate results of patch analysis or stream processing to other systems like on-line web pages? The Hive and Spark components described earlier offer an odbc/jdbc interfaces for doing SQL queries to Hadoop data. However, truth is that these are not capable for the less-than-second response times. The response times are enough for analytical visualization clients like Tableau, MS PowerBI or SAP Lumira, but not enough for the on-line web shops or many mobile applications. For the fast queries for massive audience Hadoop offers Hbase noSQL database component. Queries for Hbase can be assigned either through build-in API’s or SQL/JDBC using a Phoenix extension. Developments is continuing actively and as example there is project going on to enable full Spark API access from outside of Hadoop. More about these in coming blogs.
Although the Hadoop stack does not have traditional Enterprise Service Bus (ESB), the critical parts of the system integration and advanced analytics have married together and only your imagination is the limiting what kind of services you can provide. I would recommend to spend few minutes imaging out how these tools are running behind LinkedIn, Facebook, Uber, and biggest web shops etc.
And all this you can have on your laptop for free and forever, even for production use, if you just have eight gigabytes of memory to run it. All this may sound overwhelming, but you do not need to use and master all of the components, like you never even think of buying every item from IKEA’s store.

If you want hear more about HDP Hadoop, Modern Data Architecture and Azure Marketplace you may like these blog-posts:
Tuomas Autio: In love with Hadoop deployment automation
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 1
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 2
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 4


22.04.2016 / Ville Niemijärvi

TableaulogoJuttelin tänään Tableau-asiantuntijan kanssa ja hän totesi, että Tableaun myyntistrategia on ns. land and expand.

Tämä tarkoittaa, että tärkeintä on päästä asiakkaalle sisään vaikka vain yhdellä lisenssillä. Land. Kynnys tuotteen ostamiseen on matala, Ei tavoitella heti kuuta taivaalta. Mennään pienellä sisään ja luotetaan siihen, että tuote on niin mahtava, että se löytää tiensä muunkin organisaation käyttöön. Expand.

Strategia ei ole tietenkään mikään salaisuus ja konsulttiyhtiö Gartnerkin toteaa: “Tableau’s philosophy has been proven to appeal to business buyers and has served as the foundation for the “land-and-expand” strategy that has fueled much of its impressive growth and market disruption.”  (Magic Quadrant for Business Intelligence and Analytics Platforms 2016)

Tableaun osalta tämä toimii mainiosti. Koska tuote on hyvä. Helppokäyttöinen. Käyttäjät tykkäävät siitä.

Tableau on se sympaattinen kiva kaveri, joka pyysi baarissa vain puhelinnumerosi ja jäi mieleesi. Soittaakohan se?

Lähdetäänkö panemaan?

Vastakohtana tälle on tietenkin isot IT-möhkäleet, jotka myyvät enterprisetason ratkaisua heti kärkeen. Talot, jotka joskus hyvinä päivinä naureskelivat alle 100k lisenssimyynneille.

Nämä kaverit tahtovat päästä heti ensitreffeillä sänkyyn. Ja jos sanot ei, ei haittaa, meressä on lisää kalaa. Jos taas otat vahingossa katsekontaktin ja satut vielä hymyilemään, tulkitsee hän sen että seuraavaksi mennään tapaamaan anoppia.

Näillä tyypeillä kun ei ole vaihtoehtoa. Tuotepaletista ei löydy sellaista kivaa, sympaattista, mukavaa ja kevyttä. Halpaa. Se on all-in.

Nuorena kun hairahdut niin sitten olet lätkävaimoa lopun ikää.

Kumpi sitten on parempi?

“Land and expand” -strategian tuotteet kuten Tableau ovat asiakkaalle hyviä koska tuotteeseen pääsee kiinni pienellä kustannuksella ja hyödyt realisoituu nopeasti. Ne myydään usein liiketoiminnan kautta eikä sotketa IT:tä mukaan. Ja jotta strategia toimii, pitää tuotteen olla oikeasti hyvä jotta se laajenisi muuallekin.

Pienenä vaarana näissä tuotteissa on tietenkin spagettimaiset, siilomaiset, epäammattimaiset ratkaisut kun pistemäiset toteutukset seuraavat toisiaan eikä työtä ole johdettu keskitetysti.

Kun puhutaan päätöksenteontuesta ja tietojen oikeellisuudesta ja kun mennään osastotasoa ylemmäksi, nousee metatiedon hallinta, tiedon harmonisointi ja tietoarkkitehtuuri suurempaan ja suurempaan rooliin.

Lisäksi jotta tuote olisi helppokäyttöinen, intuitiivinen, kevyt, nopea… täytyy joissain tapauksissa karsia ominaisuuksissa. Tästä Gartnerin raportissakin mainitaan:

  • “…as vendors struggle to scale to meet support demands for more complex deployments.”
  • “…buyers of Tableau have encountered some software limitations as they attempt to scale their deployments (to meet the demands of more users trying to solve more complex problems) and govern those deployments (as they continue to expand within its customer organizations).”
    (Magic Quadrant for Business Intelligence and Analytics Platforms 2016)

Isot perinteiset IT-toimittajat taas tietää miten tehdään kokonaisvaltainen BI-arkkitehtuuri. Koska tuotetta ei pysty muuten käyttämään. Heidän tuotteensa myös taipuvat mihin vain kun tarpeeksi taitava propellipää on puikoissa ja koodaustaidot on hallussa (paitsi helppokäyttöisyyteen).

Kumpi parempi?

En tiedä. Mutta sen tiedän, että Tableaun strategialle se voisi periaattessa olla jokaisen suomalaisen yrityksen BI-tuotepaletissa (ainoana tuotteena tai osana isompaa palettia). Tuotteen kypsyessä se voi rauhassa laajentua ja taklata teknisiä haasteita.

Perinteiset, isot BI-talot taas menettävät koko ajan isoja enterprisetason kauppoja. Johtuen yritysten hintatietoisuuden kasvusta (=tiukat taloudelliset ajat) ja toisaalta siksi, että yhden ainoan BI-tuotteen “one-size-fits-all-users” taktiikasta asiakasyrityksissä on alettu luopumaan. Hankitaan paras tuote kuhunkin tehtävään, on enemmänkin trendi. Kokonaisarkkitehtuurin kustannuksella.

Tällöin jos isolla BI-toimittajalla ei ole sitä kivaa sisäänheittotuotetta, sitä valloittavaa hymyä jolla saadaan puhelinnumero baarissa, ovat he ongelmissa.

Paitsi Microsoft. Sillä häntäheikillä on jokaiselle jotakin.


Seuraava Business Intelligence -työvälinekurssi yhteistyössä Ari Hovin kanssa ke 11.5.2016. Jos BI-työvälineiden hankinta on ajankohtainen, ilmoittaudu mukaan.
BUSINESS INTELLIGENCE – OHJELMISTOJEN VERTAILU JA HANKINTA

https://youtu.be/1Lmq6RDn5O8


15.04.2016 / Lasse Liukkonen

Tässä onkin mennyt jo tovi edellisestä analytiikkaan liittyvästä blogi-postauksesta, joten allekirjoittanut nakitettiin tarinoimaan. Selattuani hetken läppärin aarteita, huomasin, että on tullut tehtyä ristiinmyynnin ennustaja, kutsuttakoon sitä tästä eteenpäin ristiinmyyjättäreksi, jonka tuloksena saadaan riistiinmyynnin odotetut katteet asiakaskohtaisesti kaikille relevanteille ristiinmyytäville tuotteille. Kuullostaa melko hyvältä, en muista nähneeni vastaavaa kapistusta tarjottavan.

Seuraavassa kertaus ristiinmyynnin kysymyksistä kuvan muodossa:

Ristiinmyynti_picture2

 

Oletetaan tästä eteenpäin, että tarkastelemme liiketoimintaa, jossa saatavilla on “kattavat” asiakaskohtaiset taustatiedot ja asiakkaiden ostohistoria tuotemyyntien lisäksi.

Ristiinmyynnin ennusteiden toteutus ostoskorianalyysin avulla ottaa huomioon vain tuotteiden väliset relaatiot. Oletuksena on siis tässä tapauksessa se, että “Maija 20 vee stadist” ja “Pertsa 60 vee pohjanmaalt”  ostavat tuotteen B yhtä todennäköisesti, kun he omistavat jo tuotteen A. Tämä voi olla hyvin kaukana todellisesta tilanteesta ja ostoskorianalyysi tuottaa kieroutuneita tuloksia asiakaskohtaisesti! Hyvää ostoskorianalyysissä on kuitenkin se, että sen tulokset ovat laskettu suoraan datasta, jolloin mallin tuottamaa harhaa ei synny. Yleisellä tasolla ostoskorianalyysin tulokset ovat siis käyttökelpoisia.

Ristiinmyynti_picture4

Ristiinmyynti_picture3

Ristiinmyynnin ennusteiden toteutus luokitteluongelman näkökulmasta ottaa huomioon asiakkaiden taustatiedot, mutta koska asiakaskohtaiset ristiinmyyntiennusteet joudutaan tekemään automaattisesti tuotteittain, saattavat mallien tuottamat tulokset olla hyvin poikkeavia yleisestä tuotteiden välisestä relaatiosta. Mikäli jonkun tuotekombinaation osalta asiakkaan taustatiedot eivät selitä ostopäätöksiä, niin tämä ei haittaa sillä tällöin ostotodennäköisyydet vastaavat ostoskorianalyysin tuottamia tuloksia kyseisen tuotekombinaation osalta.

Ristiinmyynti_picture5

Kuten arvata saattaa, yhdistää raapustami ristiinmyyjätär näiden kahden mallinnustavan tulokset, jolloin ei ehkä kaikkien asiakkaiden osalta saavuteta täysin optimaalisia  ristiinmyyntiennusteita (riippuu asiakkaan taustamuuttujien selitysvoimasta), mutta ei myöskään voida mennä täysin metsään.

Ristiinmyyjätär on toteutettu R-ohjelmalla ja sen osaset ovat pähkinänkuoressa seuraavat:

  1. Suoritetaan ostoskorianalyysi, jonka avulla saamme tuotekohtaiset relaatiot, sekä saamme karsittua tuotekombinaatioita seuraavaa vaihetta varten, joka haukkaa suuren määrän laskenta-aikaa ja muistia
  2. Muodostetaan luokittelumallit jokaiselle kohdan 1. säännöissä (tuloksissa) esiintyville tuotteille ja kahden tuotteen kombinaatioille
  3. Yhdistetään tulokset käyttämällä “optimaalista” painotussuhdetta, joka perustuu mm. edellisen kohdan mallien tarkkuuskriteereihin
  4. Kootaan ristiinmyyntiennusteet yhteen tauluun ja lasketaan odotetut tuote- ja asiakaskohtaiset katteet tuotetietojen avulla (tuotteen hinta-ostohinta, eli kate)

Kohdan 2. mallien lukumäärä räjähtää helposti valtavan suureksi, joten suoritusjärjestys tulee nähdäkseni olla juuri yllä mainittu. Yllä mainitun ristiinmyynnin mallinnustavan implementointi R-koodiksi ei ole aivan ongelmatonta muistinkäytön suhteen. Tulokset tulee laskea osissa ja suuren asiakaskannan tilanteessa tulee 2. kohdan mallinnus toteuttaa useammassa erässä.

Ristiinmyynti_picture6

 

Seuraavassa todiste siitä, että ristiinmyyjätär on totta, eikä pelkkää sanahelinää powerpointissa ja blogissa

Ristiinmyynti_picture

Kuvassa on kahden eri näkökulman kannalta otettu esimerkit myyjättären tuloksista.

Kuvassa A on asiakkaalle 25874 tarjottavat potentiaaliset tuotteet ProductB-sarakkeessa ja tuotteiden odotetut katteet (kate painotettu ostotodennäköisyydellä) sarakkeessa Expected_marginB. Tässä tapauksessa asiakkaalle A voisi tarjota esimerkiksi tuotteita 486, 537, joilla on suurin odotettu kate.

Toisaalta, jos varastossa sattuu olemaan tuotetta 486 liian kanssa, voidaan tulosten avulla filtteröidä joukko asiakkaita kenelle tarjotaan kyseistä tuotetta, ts. kenen asiakkaiden osalta odotettu kate on suurin tuotteen 486 osalta.

Tulostaulut on muodostettu siten, että asiakkaat eivät ennestään omista sarakkeessa ProductB olevia tuotteita, joten tarjottavat tuotteet saadaan molemmissa tapauksissa haettua helposti esimerkiksi sql-kyselyllä.

Kuvia vertaamalla huomaa, että odotetut katteet saattavat asiakaskohtaisesti vaihdella merkittävästi, esim. tuotteen 486 estimoitu odotettu kate asiakkaalle 25874 on 2.17e, kun vastaavasti asiakkaalle 20222 se on 5.78e.

 

 

 


15.04.2016 / Mikko Mattila

Hadoop is software package at prices so low that almost every company is able to afford it already

 

In the first part of my blog series I claimed that everyone can afford Big Data tools. The summary blog emphasized the license cost aspect and depicted how it does not exist. Like mentioned then this is not the whole truth. On the high level the Total Cost of Ownership (TCO) includes the total cost of acquisition, the operating costs and the costs related to replacement or upgrades at the end of the life cycle.
Specialty of the Hadoop system is that the acquisition costs are significantly lower compared to a traditional commercial software as there is not a license cost. For developing an actual application to be run on the Hadoop platform you most probably need external help. Even though companies using Hadoop seem to have quite “do it yourself” attitude. And naturally the cost of internal resources is a cost too. In general the hourly price of an external project resource for developing a Hadoop application is comparable to the level of any other enterprise level technology.
So, what kind of operating costs you should consider. In practice you just pay for the server hosting and the maintenance/support subscription if you want to guarantee the continuity of the service you provide with it. I do not have any statistics, but the hosting costs are often lower than with a traditional software, especially if the commercial software requires a vendor specific appliances. The very natural place for a Hadoop clusters are the public clouds like Azure or AWS which are very reasonable priced. The on premise hosting by a local provider costs, for relatively small cluster (~10 servers), few thousands euros per a month which is very reasonable price. The costs increases naturally about linearly when you need more servers, but then you can expect also significant bay-back for the investment too.
As you move to the production usage, depending on the business criticality of your application, you most probably want to purchase a maintenance/support subscription. For example Hortonworks sells different SLA levels at a very reasonable price compared to a traditional commercial software. The company gets its revenue only from these services and mainly from the subscriptions. However, “Hortonworks is expected to become the fastest growing software company — reaching $100 million in annual revenue in just four years from inception”. This describes the value-add they provide and the global success of Hadoop.
As a summary the implementation of Hadoop and other open source software is not free, but TCO is very competitive. It is so competitive that almost every company is able to afford it already. Just download the software from the Hortonworks’ homepage or launch your first cluster with Azure trial account for free.
On next week in the part three I will talk about how Hadoop together with other open source big data projects provide a huge range of IT software for the areas of data management and system integration

If you want hear more about HDP Hadoop, Modern Data Architecture and Azure Marketplace you may like these blog-posts:
Tuomas Autio: In love with Hadoop deployment automation
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 1
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 3
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 4


8.04.2016 / Mikko Mattila

Summary

 

IKEA is a huge success story and has been a clear game changer in the furnishing industry. I am convinced that Hadoop and its related open source data management tools will do same for the IT industry. What we have already seen are just the early stages of a huge disruption we will witness in the coming years.
 

My faith is based on the fact that this ecosystem has the same advantages as IKEA has in its’ business idea, which is: “to offer a wide range of home furnishings with good design and function at prices so low that as many people as possible will be able to afford them.”
 

This business idea has three key components which can be translated to the IT world in the following ways.
 

“As many people as possible will be able to afford them” ➜ “Hadoop is a software package at such a low price that almost every company is able to afford it already”

 

Ikea’s idea says “…products that are affordable to the many people, not just the few”. Any average company in either the Furnishing or the IT industry tries to maximize its sales prices to as high as market competition allows. This leads to a situation where the amount of features is maximized and absolute prices are quite high. IKEA’s approach is just opposite. Features are optimized for most people and the whole value chain is aimed at lowered costs. Finally, sales price is pushed as low as possible, regardless of what the competitive situation is.
 

In the case of Hadoop and other open source products, the situation is even better. There does not exist a party trying to maximize sales margins for the initial purchase. These products do not even have sales prices. Companies like Hortonworks actively developing their own version of Hadoop do not ask for a price for the product itself – you can download the software from their website at any time, and there are no license restrictions forbidding its use in production environments. Their business model is to only charge for the services they provide. In the same sense, it would be like IKEA giving away their furniture for free and charging only for home delivery, assembly and warranty. Like in the case of IKEA furniture, Hadoop tools expect a more “Do-It-Yourself” attitude, but at the same time cost savings can be huge.
 

Naturally license costs are not the whole truth. In part two of this blog series, I will go through how you should consider things like hosting, maintenance and skill costs.
 

“A wide range of home furnishings” ➜ “Hadoop and other open source Big Data projects provide a huge range of IT software for areas of data management and system integration”

 

When you step into an IKEA store, you immediately understand that the offering is wider than in any other chain – it is huge. Similarly products under Hadoop’s umbrella cover all major aspects of traditional data warehousing and system integration. So you have a tool for almost every purpose and blueprints for how to make them communicate with each other.
 

Even more important than just availability of the tools, is the way it changes your thinking. As people start to master both the real-time system integration aspects and analytics, they start to realize that building automated decision making processes are a realistic goal. Automated decision making and real-time information are changing all industries at the moment. For example, at Uber there is no-one matching cars and passengers or informing both parties in real-time where the car is at each moment. Additionally, their system is even doing predictions about costs and arrival times. And this process is running simultaneously for millions of people.
 

In part three of this blog series, I will talk about what are some of the Hadoop and Big Data software components available and how those can do similar things for you as they are doing for Uber.
 

“Home furnishings with good design and function” ➜ “Hadoop tools are designed to solve issues impossible for traditional commercial tools”

 

For decades IT was too expensive for everyone. Roughly ten years ago internet startups started using low cost and open source software to build their services. These open source tools pretty much copied the functionalities of the commercial tools. At the high level the main difference was economics behind them. Suddenly, you didn’t need significant funding to set-up an IT company and become a millionaire.
 

In the shadows, these new internet companies grew faster than anyone realized. Quickly they ran into overwhelming technological challenges, which traditional enterprises and software vendors never needed to tackle. The newcomers needed to invent a way how to provide an almost 100 % automated service 24/7/365 for millions of users. If you have ever operated IT systems, you know how 99 % of CIOs would see these kind of requirements as totally impossible for their software landscape and infrastructure.
 

Some of the startups understood that they needed to build their own software starting from the file system, database and system integration level, in order to scale and survive. As a result, we have companies like Facebook, Yahoo, LinkedIn etc. As this software development is not their core business, they soon started to share their developments with others for free. In many ways this era of software is superior compared to traditional ones, but of course they have also some limitations.
 

In part four of this blog series, I will talk about what are the more detailed requirements Big Data tools were developed for. How they solve these issues and what kind of compromises you need to accept.
 

If you want hear more about HDP Hadoop, Modern Data Architecture and Azure Marketplace you may like these blog-posts:
Tuomas Autio: In love with Hadoop deployment automation
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 2
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 3
Mikko Mattila: Hadoop – IKEA of the IT ecosystem: Part 4


7.04.2016 / Kristiina Burtsoff

Yöpöydälläni inspiroi parhaillaan L. David Marquet:n kirja Turn the Ship Around, joka kertoo tarinan johtajuuden muutoksesta ydinaseilla varustellun sukellusveneen miehistössä. Veneen miehistö on reilun sadan hengen suuruinen, aivan kuten Bilotinkin miehistö. Molemmissa organisaatioissa sekä päätöksentekoprosessit että järjestelmät olivat turvaamassa selustaa hieman yli todellisen tarpeen.

Sukellusveneen kontrollimekanismien muuttuessa, valtasi turvattomuuden tunne miehistön. Kun tuntuu siltä, että tilanne on jonkun (kippari, esimies, johtaja, johtoryhmä) vastuulla, on helppoa ajatella, että liiketoiminta, ja näin myös oma työpaikka ovat turvassa. Kuitenkaan harva esimies, johtaja tai johtoryhmä kykenee sen enempää ihmetekoihin, kuin kukaan muukaan. Organisaation tärkeintä palaa, asiakasta, palvelee päivittäin ihan muu osa organisaatiosta kuin johtoryhmä. Tämän palan äärellä myös päivittäiset ihmeet tapahtuvat.

Johtajilta odotetaan vastuun kantamista sellaisistakin päätöksistä, joista johtajalla on hyvin vähän ensikäden tietoa. Tämä on perinteisen hierarkkisen organisaation suurin harha. Informaation vieminen johtoryhmään päätöksentekoa varten on hidas prosessi ja viesti voi muuttua matkalla. Päätöksenteon siirtäminen sinne, missä informaatio sijaitsee, oli Marquet’n johtaman sukellusveneen ja myös Bilotin ratkaisu.

Johtajia ja johtajaan henkilöityvää strategista liiketoimintaosaamista ja päätöksentekokykyä tarvitaan toki. Aina ei ole aikaa koota asiantuntevaa ryhmää kokoon, etsiä parasta mahdollista ratkaisua. On tilanteita, joissa tarvitaan päätöksentekijä. Mikä on oikeasti johtajuutta, jos se ei olekaan päätöksentekijänä toimimista omalla vastuualueella? Tämä on kysymys, jonka jokainen moderniin, jaettuun johtamiseen perustuvaan organisaatiomalliin päätyvä yritys ja sen henkilöstö kohtaavat.

Bilotilla johtoryhmän rooli on muuttunut eskalaatioita hoitavasta päätöksentekoelimestä tulevaisuutta rakentavaksi asiantuntijatiimiksi. Edelleen johtoryhmässä tehdään yhteisiä, kaikkia itseohjautuvia tiimejä, koskevia päätöksiä, mutta yksittäisen tiimin asioita ei tarvitse käsitellä. Johtoryhmä voi myös toimia hyvänä sparrausrinkinä tiimille, jolla on ongelmia ratkottavanaan. Tiimin ei kuitenkaan pidä perinteisessä mielessä eskaloida päätöksiään, ellei päätös koske yksittäistä tiimiä laajempaa osaa liiketoiminnasta.

Johdatko lentävään lähtöön vai istuvaan starttiin?

Modernissa organisaatiossa johtajan rooli on uudenlainen, mutta myös muutoksen syke on erilainen. Muutos leader-follower-johtajuudesta leader-leader-johtajuuteen tapahtuu Marquet:n mukaan toiminnan muutoksen kautta, ei selittämällä muutosta. Tämä on muutosjohtamisen oppikirjojen (nyt on tosiaankin viimeinen hetki luopua Kotterista!) vastainen ajatus, mutta käytännön tulokset selättäköön tässä teorian.

Juhla- tai pelottelupuheet eivät edistä muutosta vielä senttiäkään. Ne voivat luoda odotuksia, pelkoja ja muita tunteita, mutta mitään ei tapahdu, ennen kuin joku aloittaa. Ja ennen kuin joku aloittaa, ei nähdä mitään sellaista, mikä kertoisi muutoksen hyödyllisyydestä tai haitallisuudesta. Luonteva reaktio yksilölle onkin istua ja odottaa, kunnes jotain näkyy omassa ympäristössä. Näkyvien ja konkreettisten muutosten aikaansaaminen heti starttipistoolin lauettua on tärkeintä, jotta muutoksella on mahdollisuuksia elää.