29.09.2016 / Terho Antila

Haluan kompata Jannen ansiokasta artikkelia siitä, kuinka pilvestä puhuttaessa tarkoitetaan edelleen varsin usein joltakin globaalilta toimijalta vuokrattavia virtuaalikoneita, joilla laajennetaan yrityksen olemassa olevaa infrastruktuuria. Järkevää tietyissä skenaarioissa tämäkin, mutta itse en ole koskaan pitänyt IaaS-palveluja todellisina pilvipalveluina. Toki infraa kun ostaa palveluna, pääsee eroon monista laitetason ongelmista ja käyttöjärjestelmään liittyvistä säädöistä, mutta edelleen täytyy itse asentaa palvelimille haluamansa sovellukset ja tehdä tarvittavat konfiguraatiot verkkotason topologioista puhumattakaan.

Sovelluskehittäjän näkökulmasta IaaS ei tuo juuri mitään uutta. Päinvastoin, se saattaa jopa hankaloittaa asioita, sillä siinä missä ennen kehitysympäristön saattoi tilata oman yrityksensä IT-palvelulta, ohjataan poloinen devaaja nyt esimerkiksi Azureen Microsoftin pakeille hankkimaan ja konfiguroimaan ympäristönsä itse.

Olisi huisin hienoa, jos kehittäjän tarvitsemat sovellusalustat saisi jostakin palveluna, eikä mitään erillisiä asennuksia tarvittaisi. Kuinkakohan monta kertaa itsekin olen asennellut SQL Serverin, SharePointin, MongoDB:n, Rediksen tai konfiguroinut palvelimelle esimerkiksi AD:n tai IIS-palvelut? Ja näitä on tietenkin täytynyt aika-ajoin myös päivitellä. Ja sitten kehitystiimiin tulee se seuraava devaaja, joka tarvitsee oman ympäristönsä, ja pahimmillaan saman rumban saa tehdä taas uudestaan…

No mutta – ne sovellusalustathan SAA palveluna pilvestä!

Azuren PaaS-palvelut kattavat kaikki tyypillisen sovelluksen tarpeet niin sovellusarkkitehtuurin näkökulmasta kuin luotettavana ajoympäristönäkin. Minuuteissa saat luotua itsellesi sovellusalustan ilman ainuttakaan asennustoimenpidettä. Helppoudesta huolimatta alusta kuitenkin tarjoaa käytettäväksesi kaiken tarpeellisen tietokannasta blobitiedon tallennukseen ja kuormantasauksesta hajautettuun välimuistiin. Kaikki pöytään tarjoiltuna ilman, että sinun tarvitsee itse käydä keittiön puolella.

Olen todella vaikuttunut siitä PaaS-palveluiden kirjosta, jota Microsoft tänä päivänä Azuren kautta tarjoilee. Niitä on niin paljon, ettei kaikkia kannata nyt lähteä esittelemään. Tässä muutamia oleellisimpia. Näitä todennäköisesti ihan ensimmäiseksi tarvitset, kun lähdet rakentamaan sovellusta Azuren PaaS-palveluita hyödyntäen:

Web Apps – IIS palveluna. Voit itse säädellä kuinka monella rinnakkaisella palvelimella sovelluksesi pyörii. Voit myös määritellä erilaisia sääntöjä, joiden mukaan palvelimia lisätään – Microsoft hoitaa kuormantasauksen.

SQL Database – Relaatiokanta palveluna. Sinun ei tarvitse huolehtia kannan varmistuksista tai levytilan riittävyydestä. Riittää, kun suunnittelet kantaskeeman ja annat palaa!

DocumentDB – Suorituskykyinen ja skaalautuva NoSQL-kanta, palveluna. Voit tallentaa minkälaisia JSON-objekteja tahansa ja kohdistaa niihin erilaisia kyselyitä attributtitasolla.

Redis Cache – Hajautettu välimuisti palveluna. Hyvin todennäköistä on, että tarvitset hajautetun välimuistin käyttöösi heti, kun verkkopalvelusi pyörii useammalla eri palvelimella. Tällöin nopea Redis Cache on oiva ratkaisu, eikä kaikkea tarvitse säilyttää esimerkiksi nopeudeltaan selkeästi hitaammassa SQL-kannassa.

Azure Storage – Terakaupalla levytilaa palveluna. Jos sovelluksesi esimerkiksi säilöö ja jakelee videoita, tarvitset datasäilön, josta ei varmasti levytila lopu kesken. (Psst, kannattaa tällöin myös tsekata CDN ja Media Services…)

Search – Haku palveluna. Saat sovellukseesi helposti käyttöön monipuoliset hakuominaisuudet ilman, että sinun täytyy itse lähteä virittelemään hakualgoritmeja tai edes indeksoimaan haettavaa sisältöä.

Hybrid Connections – Sovelluskohtainen VPN-ratkaisu palveluna. Vaikka tämä onkin pikemmin IaaS kuin PaaS, halusin sen kuitenkin nostaa esiin tässä, koska Hybrid Connections tarjoaa helpon tavan mahdollistaa liikenne Azure-sovelluksen ja on-premise -palvelun välillä.

Edellä oli vain raapaisu Azuren tarjoamista palveluista. Kun näiden päälle lisätään vielä kehityksenaikaisen tuen palvelut, erilaiset monitorointipalvelut, data-analytiikan palvelut, tietoturvaan liittyvät palvelut ja ties vaikka mitkä muut, on selvää, että moderni yritys ei voi ohittaa Azurea sovellusten kehitys- ja ajoalustana. Sovelluskehityksestä ja tuotantokäytöstä tulee yksinkertaisesti nopeampaa, ketterämpää ja riskittömämpää.

Me Bilotilla olemme ihan pilvessä ja voimme suositella juuri sinun tarpeisiisi soveltuvan arkkitehtuurin – oli se sitten pilvi, on-premise tai hybridi.

 

Haluatko kuulla lisää?

13.10.2016 pääset kuulemaan ja tapaamaan asiantuntijoitamme Integroi oikein BizTalkilla ja Azurella -aamiaistilaisuudessa. Ilmoittaudu jo tänään.


29.09.2016 / Ville Niemijärvi

Järjestin pari vuotta sitten asiakkaalle business intelligence -työvälineen kilpailutusta. Olin hankintakonsultti ja muun RFP-materiaalin ja esiselvityksen ohella hoidin kommunikoinnin toimittajien suuntaan.

Eräs BI-talon myyjä oli poikkeuksellisen aktiivinen minua kohtaan. Puhelin soi taukoamatta. Kysymykset oli hyvin suoria: ketä on mukana pelissä, onko se ja se toimittaja, mitä asiakas painottaa, mikä on budjetti, ketä pitää panna…?

 Oudoksi tilanne meni kun myyjä ehdotti minulle vähän kiertäen ja kaartaen:

Jos meidän tuote valitaan asiakkaalle, voitaisiin me järjestää jonkinlainen ulkomaan matka sulle.

Mitä ihmettä? Tällaistako on kun joku lahjoo sinua?

Hän pehmensi selvää lahjontayritystä heti perään puhumalla jotakin kumppanuusohjelmasta ja niin edespäin.

Kerroin asiasta asiakkaalleni. Heidän johtoryhmä nauroi asialle ja totesivat ihan oikein, että heitähän tässä pitäisi lahjoa eikä minua. Lopulta hankinta hoidettiin tyylipuhtaasti maaliin ja ulkomaan reissut on senkin jälkeen tehty omalla rahalla.

Eihän tämä ensimmäinen kerta ollut kun vastaavaan törmäsi. Pari työpaikkaa takaperin muistan kuinka todella isossa julkisen puolen tietovarastoprojektissa silloisen firmani toimari vei vastapuolen toimarin golffaamaan Espanjan aurinkorannikolle. Kuulemma ”seminaarimatka”. Maan tapa.

En tiedä minkälaiset provikat BI-softamyyjät saavat mutta sen tiedän, että

a.) ne eivät ole niin isot, että oma maine ja vapaus kannattaa riskeerata hölmöilemällä ja

b.) puheet Suomesta täysin puhtoisena korruptiovapaana maana ovat höpöhöpöä.

Tykkään käyttää blogeissani aina silloin tällöin musiikkivideoita kuvaamaan tunnelmaa. Jotenkin MC Hammerin ”U can’t touch me” ei sovellu tähän fiilikseen. Ehkä Ennio Morricone toimii paremmin?

 

 


28.09.2016 / Markus Kuuranta

Henry Fordin uskotaan aikanaan tokaisseen, että mikäli hän olisi kysynyt asiakkailtaan heidän tarpeistaan, olisi vastaus ollut “nopeampi hevonen”.

Vaikkakin hieman tyly, sisältää lausahdus yksinkertaisen totuuden: tuotteen käyttäjät eivät useimmiten osaa visioida tarvitsemaansa ratkaisua, mutta he ovat mestareita kertomaan omista tarpeistaan. Ja juuri nämä tarpeet ovat nitä tekijöitä, joita ymmärtämällä on mahdollista suunnitella aidosti hyödyllinen ratkaisu.

Olettamukset ongelmana

Miltei jokainen IT-alalla toiminut on joskus istunut palaverissa, jossa asiakkailta on kysytty suoraan, mitkä ominaisuudet tekisivät heidän sovelluksestaan hyödyllisen. Vastaus on miltei poikkeuksetta luokkaa “nopeus ja helppokäyttöisyys”.

Kun myyjä sitten välittää nämä terveiset toteutustiimille, on lopputulos juuri sellainen 4,58 % nopeampi hevonen – ja toisinaan yhden satulan sijaan mullistavasti kahdella satulalla.

Missään vaiheessa ei tarkennettu listattujen adjektiivien merkitystä käyttäjille, saati sitten selvitetty millaiseen työhön sovellusta ollaan rakentamassa. Vaikka briiffi olisi kuinka perusteellinen, on ymmärrys jäänyt pintapuoliselle tasolle, jossa jokainen peilaa viestiä vain oman näkökulmansa kautta ja ymmärryksen aukot paikataan olettamuksilla.

Kohti käyttäjäkeskeistä projektityötä

Entäs jos palaverissa olisi sovittu, että sovelluksen suunnittelijat tulevat tutustumaan tulevien käyttäjien työhön, ilman IT-managerien ja talousjohtajien läsnäoloa?

Muutaman hengen tiimi olisi tullut käyttäjien työympäristöön paikan päälle, huomaten välittömästi useita ympäristön asettamia haasteita, joista heillä ei ollut aikaisemmin aavistustakaan. Käyttäjille monet näistä merkityksellisistä asioista ovat niin arkipäiväisiä, etteivät he edes ajatelleet niitä. Ne eivät nouse esille palaverismoothieta siemaillessa, vaan vaativat esiintyäkseen todellisuutta vastaavan ympäristön.

Havainnoinnin edetessä toteutustiimi toteaa ettei heidän mielikuvansa sovelluksen tarpeista vastannutkaan todellisuutta, ja he huomaavat useita työvaiheita, joita voitaisiin helpottaa teknologian keinoin. Suunnittelijat siis alkavat todella ymmärtää käyttäjien tarpeita, sen sijaan että he vain pyrkisivät toteuttamaan käyttäjien toiveet sellaisenaan. Tällöin käytättäjien toimialaosaaminen ja suunnittelijoiden asiantuntemus saadaan yhdistettyä kokonaisuutta hyödyttävällä tavalla, jonka lopputulos on jotain enemmän kuin “nopeampi hevonen”.

Tällaista lähestymistapaa kutsutaan käyttäjäkeskeiseksi suunnitteluksi, ja sen ensimmäinen vaihe on juuri yllä kuvattu – käyttäjätutkimus. Näin suhteellisen pienellä panostuksella saatiin selvitettyä käyttäjien todelliset tarpeet, varmistettiin koko toteutustiimille mielekäs suunta ja vältyttiin loppuvaiheen hätäkorjausputkelta.

Käyttäjätutkimus on kannattava sijoitus

Yksinkertaistettuna käyttäjätutkimuksen tarkoitus on säästää rahaa. Kun heti alussa rakennetaan kattava ymmärrys käyttäjien tarpeista, säästytään hintavilta korjausliikkeltä ja ylipäänsä aloitetaan tekemään oikeita asioita. Käyttäjätutkimus on projektityöskentelyn sijoitus, jolla varmistetaan, että projektissa todella tehdään sitä mitä halutaankin tehdä.

Voin taata, että kun yhdessä projektissa toteuttaa käyttäjätutkimuksen vaiheen, ei voi kuin ihmetellä mikä peijakas on koskaan ajanutkaan toimimaan millään muulla tavalla.

 

Lue lisää käyttäjäkeskeisestä suunnittelusta:


26.09.2016 / Mariusz Papiernik

Cyfrowy biznes w erze klienta – co to?

Co oznaczają słowa Digital Transformation i jaki będą miały wpływ na dynamikę rozwoju firm? Z jakimi decyzjami wiąże się to dla właścicieli i Zarządów? Trzeba nauczyć się angażować Klienta po to, aby korzystać z jego doświadczeń (user experience) do realizacji sprzedaży. Niewątpliwie to czas na weryfikację strategii i podejścia do rynku i przyjrzenia mu się bliżej, czas spojrzenia na technologię wspierającą biznes.  Dlaczego nagle wszystko nabiera tempa i dlaczego konsumenci zmieniają swoje zachowania?

#1 Digital Driven Commerce – odnieśmy to do zmian pokoleniowych X, Y, Z

X, Y, Z – tak określa się urodzonych w latach 1961 – 1995, należą oni do generacji ludzi żyjących w wyjątkowo ciekawych i dynamicznie zmieniających się czasach. Nasi poprzednicy w XIX wieku byli świadkami rewolucji przemysłowej i wieku pary. Dzisiaj natomiast jesteśmy uczestnikami fenomenu Internetu, aplikacji mobilnych, rozwiązań chmurowych i aplikacji nastawionych na kontakt z klientem, takich jak CRM, Commerce, automatyzacja marketingu, czy tez analityka predykcyjna. Dzięki temu doświadczamy nieustannie kolejnych nowości technologicznych zmieniających naszą rzeczywistość. Ta dość specyficzna forma rewolucji powoduje, że funkcjonujemy w procesie zmiany technologicznej, gospodarczej, społecznej i kulturowej, który z roku na rok przyśpiesza i zaskakuje nas tempem dokonujących się zmian, mających również niewątpliwy wpływ na model biznesowy organizacji.

#2 Digitalization – niekwestionowany globalny trend dotykający wszytkich branż i zachowań

To trend, który sprawił, że świat IT i Biznesu usiadł do stołu, zaczął wspólnie planować i rozmawiać o budowaniu przewagi konkurencyjnej. Trend ten wygnerował potrzebę nowych strategicznych ról w organizacji takich jak CDO – Chief Digital Officer. Rozwiązania IT w ostatnich latach przechodziły transformację, przed którą były zrozumiałe tylko dla nielicznych z tytułem naukowym doktora informatyki, a stały się przyjazne biznesowi. Dziś CIO oraz CDO – Chief Digital Officer jest już naturalnym partnerem Zarządów w romzowach przy rozmowach o wprowadzaniu zmian organizacyjnych, oferty, strategii – można powiedzieć, że mają biura na tym samym piętrze.

#3 Customer Engagement & Commerce i Big Data
Ludzkość generuje ogromne ilości danych i gromadzi je w firmach, w mediach społecznościowych oraz w innych miejscach, które są im tylko znane. Dynamicznie zmieniająca się rzeczywistość wymaga od firm, sieci handlowych, hurtowników obecności on-line, stosowania rozwiazań mobilnych, bycia efektywniejszymi, niż kiedykolwiek dotąd. Platformy Big Data są również niezastąpionym narzędziem do gromadzenia i obróbki danych w czasie rzeczywistym, które wspierają procesy decyzyjne, gromadzenia wiedzy na temat zachowań i innych ważnych wskaźników.

Nowa rzeczywistość bywa bezlitosna wobec technologicznych śpiochów. Budujące jest, że liderzy rynku, dostawcy technologii hybris / SAP odrabiają lekcje regularnie, inwestują w R&D i mają rozwiązania biznesowe wspierające procesy Customer Engagement & Commerce.

Klienci Bilot, będący liderami w swoich branżach dzięki naszym rozwiązaniom z sukcesem budują zaangażowanie klienta wykorzystując hybris Commerce, CRM w chmurze (SAP hybris Cloud for Customer) oraz SAP HANA. Rozwiązania te zintegrowane z róznymi innymi systemami działającymi w firmie, zapewniają połączenie marketingu, sprzedaży, handlu, obsługi klienta i kanałów społecznościowych, umożliwiając pracownikom prowadzenie efektywnych, spersonalizowanych interakcji z Klientem. Planowanie inwestycji w tego typu narzędzia to przede wszystkim inwestycja w projekt integracyjny. Bilot zaprasza na wspaniałą biznesową podróż opartą na doświadczeniu zebranym podczas projektów na dojrzałych rynkach.

#4 Full Stack for Customer Engagement and Commerce
Omni-Channel rozwija się w szybkim tempie, odpowiadając na potrzebę komunikowania się z klientem we wszystkuch kanałach i punktach styku (Touchpoints). Bilot dostarcza wszystkie warstwy dla rozwiązań CEC – od frontend’u, programowania backend, bazy danych. Full Stack zapewnia pewność poprawnego działania całej platformy i przyczynia się do sprawności działania organizacji na rynku – a to właśnie to naszym zdaniem przyczyni się do osiągania celów sprzedażowych.

#5 Marketing automation
Ta grupa rozwiazań pozwala na prowadzenie działań marketingowych w sposób zautomatyzowany i na dużą skalę. Celem jest tutaj takie wyselekcjonowanie potencjalnego klienta aby uzyskać ostatecznie jak najlepszy współczynnik konwersji. Narzędzia marketing automation powinny dostarczyć bezpośrednie leady lub budować przywiązanie do marki – zależnie od naszych celów. Generowane leady mogą trafiać do systemu CRM, w którym następuje dystrybucja do handlowca i próba konwersji.

Często istotnym elementem jest również lead nurturing mający na celu systematyczne dostosowywanie oferty do potrzeb rynku, badając jego potrzeby i reakcje. Takie płynne podejście pozwala na nadążanie za szybko zmieniającymi się potrzebami klientów i ich sposobem kupowania, a często również na wyprzedzenie konkurencji. Pozwala to również na dostarczenie siłom sprzedażowym najwyższej jakości leadów.

W zakresie Marketing Automation Bilot posiada doświadczenia głównie z integracji takich rozwiazań z rozwiazaniami CRM, dla zapewnienia płynności całego procesu. Optymalnym rozwiązaniem jest również łączenie ze sobą narzędzi Marketing Automation i narzędzi analitycznych pozwalających na analizę dużych zestawów danych będących bazą do kolejnych segmentacji.

#6 Analityka predykcyjna
Próba zrozumienia prawidłowości z dużych zbiorów danych nie jest tematem nowym, z pewnością jednak zawsze była zadaniem skomplikowanym z nieprzewidywalnym możliwym wpływem na ofertę i miejsce na rynku firmy. Ten wpływ jednak uzależniony jest od poziomu inwestycji w narzędzia analityczne (Jak sprawne mamy narzędzie? Czy jest wydajne?), jakości danych, analityków, a następnie od skuteczności organizacji we wdrażaniu zaleceń wynikających z wyników analizy. Ale przecież możemy się dowiedzieć co jest powodem odejść klientów (churn) i znaleźć korelację z tym co zrobić aby tego uniknąć. Możemy dowiedzieć się jak przygotować kampanię aby osiągnąć wyższą konwersję. Możemy rozpocząć personalizowanie oferty dla klienta podpowiadając mu to co może go zainteresować (nawet online). To tylko przykłady. Ale czy nie warte rozważenia? Zapraszamy do rozmowy.


26.09.2016 / Janne Vihervuori

Yksi asia menee edelleen pieleen puhuttaessa pilvipalveluista: niistä ei osata puhua. Puhuttaessa ‘bisneksen viemisestä pilveen’, ollaan liian usein vain vaihtamassa konesalia (IaaS, infrastructure-as-a-service) tai ottamassa kevyimmän luokan SaaS (software-as-a-service), esimerkiksi toimistopaketti, käyttöön. Ei puhuta bisneksistä, vaan puhutaan pehmoisia. Joe Weinman kirjoitti vuonna 2012 kirjan nimeltään Cloudonomics. Vaikka muutama vuosi on vierähtänyt julkaisusta, kirjan viesti on edelleen ajankohtainen ja väkevä.

Cloudonomicsin lukeneet eivät puhu pehmoisia ‘liiketoiminnan viemisestä pilveen’, vaan ymmärtävät minkälaisilla erilaisten pilvipalvelujen lisäarvoilla mahdollistetaan digitaalista liiketoimintaa. Esimerkkeinä näistä palveluista ovat sovelluskehitys, integraatio, mobiili, dokumentti ja identiteetti. Palveluita, joiden hallinta olisi asiakkaalle liian työlästä ja kustannuksiltaan kallista, puhumattakaan näiden palvelujen keskinäisestä integraatiosta. Jos tämänlaisia palveluja hankkisi yksittäin, huomaisi pian olevansa naimisissa useiden eri tarjouspyyntöjen, toteutusprojektien ja ylläpitojen kanssa. Digitaalisen liiketoiminnan pilvestä ja oleellisista arvolupauksista puhuttaessa puhutaankin PaaS-pilvestä, platform-as-a-service.

Jotta asiat eivät olisi yksinkertaisia

PaaS on yleisnimitys palvelualustalle, josta käytetään usein myös sovellukseen viittaavaa termiä aPaaS (a = application). Tämän lisäksi on olemassa dedikoituihin tarpeisiin soveltuvia PaaS:ejä, esimerkiksi iPaaS, jonka ”i” viittaa integraatiopalveluihin keskittyvään palvelualustaan. Lisäksi on olemassa asioiden internetin (IoT) alustoja ja ns. nopean sovelluskehityksen alustoja (RAD), joita ei aina kutsuta PaaS-nimellä, mutta ne ovat käytännössä PaaS-tyyppisiä alustoja.

Vaikka moderneja alustoja on saatavilla, voi organisaatioiden IT-kartta näyttää monimutkaisemmalta kuin ennen. PaaS-tyyppiset alustat, IoT, Big Data ja uudet digitaaliset palvelut ylipäänsä luovat suuren kontrastin edelleen käytössä oleviin legacy-järjestelmiin ja perinteisesti toteutettuihin sovelluksiin.

Bimodal IT hyvä, 3Mode parempi

Taistelen tätä kompleksisuutta vastaan 3Mode-mallillamme, jonka pohjalta olemme auttaneet mm. Helsingin kaupunkia hahmottamaan uuden pilviaikakauden sovelluskehityksen mallin. 3Modessa on kolme kerrosta:
1. Responsive,
2. Enablement
3. Core
Keskimmäinen Enablement-kerros on kerroksista oleellisin. PaaS-tyypin alustat majailevat siellä.

Integraatio, digitaalisten palvelualustojen kuninkaallisin palvelu

IT:n historia yritysten ERP-järjestelmiä ja ihan mikropiirejä ja prosessoreita myöten noudattaa yhtä kaavaa: dedikoitut ratkaisut väistyvät aina integroitujen ratkaisujen tieltä. Yritys ei tarvitse vain kirjanpitoa, vaan myös myyntiä, logistiikkaa ja henkilöstöhallintoa – kokonaista ERP-järjestelmää. Integroitu piiri on aina syrjäyttänyt aiemmat, erilliset ratkaisut vuodesta 1959 lähtien, milloin Texas Instruments integroi samalle sirulle vastuksen ja transistorin. Jos edellä mainitusta voi johtaa analogiaa tulevaan, niin PaaS-pelin voittajiksi valikoituvat ne toimijat, jotka kykenevät niputtamaan alustoilleen tarpeelliset palvelut riittävän hyvin ja siten, että niistä on toisilleen synergiaa. Erinomainen dedikoitu (x)PaaS ei enää pärjääkään yleishyvälle PaaSille, koska dedikoidun PaaSin palvelut pitää edelleen integroida muihin palveluihin, mikä on yleis-PaaSilla jo valmiiksi sisäänrakennettua.

Jos pitää valita yksi erityinen palvelu PaaS-tyyppisille alustoille, on se integraatio. Gartner ennustaa, että vuoteen 2020 mennessä yli puolet PaaS:n avulla rakennetuista palveluista on IoT-palveluja. Mikä on oleellista IoT:ssä? Integraatio. Pelkästään IoT tulee nostamaan integraation ja integraatiopalvelut erityisen suuriin mittasuhteisiin, puhumattakaan uusien, reaaliaikaisten integraatiopalvelujen tarpeesta. Lisäksi API Management on jotain, mikä tulee löytymään vuoteen 2020 mennessä jokaisesta digitaalisia palveluja tuottavasta yrityksestä. Olen itse elänyt ja hengittänyt SAP-ekosysteemiä viime vuosituhannelta asti ja osaan arvottaa sen ekosysteemin pilvi-alustat. Seuraan kuitenkin koko markkinaa.

 

Haluatko kuulla lisää?

13.10.2016 pääset kuulemaan ja tapaamaan asiantuntijoitamme Integroi oikein BizTalkilla ja Azurella -aamiaistilaisuudessa. Ilmoittaudu jo tänään.


26.09.2016 / Karri Linnoinen

In this instalment of my “10 things about Tableau 10” blog series, I’m going to go into the Highlighter tool. The Highlighter is a great new feature in Tableau 10 that allows for quick insights into your data without losing the context of the other data on the canvas – the fact that you can see patterns quickly on the canvas makes it incredibly powerful.

The Highlighter

So how does the Highlighter work? It works similarly to a the Quick Filter tool, but instead of including/excluding data from the canvas, it will leave the other data points visible. To enable the highlighter, you will need to have a dimension on the marks card and then select the “Show highlighter” using the context menu.

tableau10highlighter

The Highlighter will appear on the right hand side of the canvas just as the Quick Filter does. To use the Highlighter, just start typing in the field. The tool will then highlight any dimension member which contains the letters in the field — this means you can search for members from your dimensions you don’t know the full name of. Handy for finds things like products.

The highlighter also works especially well with Scatter plots. With my customers plotted in relation to Sales and Profit, I can use the highlighter to see where my profitable and unprofitable customers are.

tableau10highlighter-anim2

To download a free 14 day trial of Tableau 10, go to our trial download page and discover Tableau 10 for yourself!


16.09.2016 / Ville Niemijärvi

Olen kilpailuttanut useita business intelligence -työvälinehankintoja. Usein asiakas haluaa hankkia samalla raportointi- ja analysointityövälineen lisäksi myös budjetointi- ja suunnittelusovelluksen.

Hankintojen keskittäminen on ymmärrettävää ja usein suosittelen tätä jos molemmat sovellukset on kuitenkin hankintalistalla.

Mutta onko tarpeen hankkia sovellukset samalta toimittajalta? Mitä hyötyjä ja haittoja tästä seuraa?

Käydään läpi muutamia kokemuksia ja oppeja vuosien varrelta.

 

Milloin keskittäminen kannattaa?

Kustannussäästö

Keskitetty hankinta, jossa kilpailutetaan samalla BI-työväline (raportointi, visualisointi, data discovery…) sekä budjetointi- ja suunnittelutyöväline, on usein edullisempi kuin jos tuotteet hankitaan erikseen.

Toimittajat joilta löytyy tuotepaletista molemmat komponentit, voivat niputtaa tuotteet samaan tarjoukseen ja tarjota paketin todella houkuttelevaan hintaan. Joskus toinen menee vähän niin kuin kaupan päälle.

Tällöin käy myös niin että ne BI-toimittajat, joilta ei löydy budjetointisovellusta tarjonnastaan, joutuvat ottamaan tarjoukseen mukaan jonkin 3. osapuolen budjetointisovelluksen. Koska budjetointi tulee toiselta toimittajalta, ei tähän hintaan usein voida vaikuttaa joten tinkivaraa ei jää.

Tämä tarkoittaa, että budjetointisovelluksen omaava toimittaja saa paremmat hintapisteet ja on vahvoilla kilpailutuksessa. Tätä voisi tulkita myös niin, että asiakas voisi halutessaan pelata tietyt pienemmät toimittajat kilpailutuksesta pois, ottamalla siihen mukaan molemmat komponentit.

Ajan- ja vaivansäästö

Kilpailuttaminen, varsinkaan julkishallinnon puolella, ei ole kenenkään mielipuuhaa. Yleensä yksityisellä puolella olen vetänyt RFP-prosessin läpi max. 2 kuukaudessa. Julkkaripuolella tämä venyy 3-6 kuukauteen.

Ihmisillä on muutakin tekemistä kuin miettiä hankintalain kiemuroita ja koota RFP-materiaaleja joten jos yhdellä kilpailutuksella voidaan hoitaa kaksi softaa niin miksikäs ei.

Miksi keskittäminen ei kannattaa?

Vuosien kokemus molempien (BI + budjetointi- ja suunnittelu) tuotteiden hankinnoista ja käyttöönotoista on kuitenkin opettanut, että yhteinen kilpailutus sisältää haasteita.

Tuotteet ovat itseasiassa aika kaukana toisistaan, vaikka tulisivat samalta toimittajalta

Toimittajat sanovat toista mutta todellisuudessa saman toimittajan raportointituote on aivan eri puusta veistetty kuin budjetointituote. Käytännössä monet budjetointituotteet ovat tulleet yritysoston mukana.

Esimerkiksi IBM Cognoksen budjetointituote on nimeltä TM1. Tämä ei ole kuitenkaan IBM:n kehittämä tuote vaan Cognos osti vuonna 2007 Applix:in, jonka mukana se sai TM1:n,

Toki sitä on tunkattu ja koodattu samaan sapluunaan mutta silti TM1 ja muu Cognoksen BI on kuin eri planeetalta. Kyselykieli datapoiminnoissa, käyttöliittymä, look ’n feel, teknologia konepellin alla… kaikki poikkeaa toisistaan.

Myyntimiesten puheissa tuote oli tietenkin heti ”täysin integroitu” muun Cognos BI tuoteperheen kanssa. Tämä oli tietenkin hölynpölyä. Me ketkä jouduimme taistelemaan TM1:n (tai sitä edeltävän Cognos Planningin tai sitä edeltävän Cognos Financen) kanssa ja integroimaan sitä Cognoksen BI-tuotteisiin tiedämme totuuden.

TM1 on käytännön työn kannalta yhtä lähellä Cognoksen BI palettia kuin Microsoft. Itseasiassa Microsoftin SSAS kuution saa toimimaan paremmin Cognoksen raportointituotteiden tietolähteenä kuin TM1:n. Testattu molemmat.

Vaikka kyse ei olisi yritysostolla hankitusta tuotteesta, saat silti hyvin vähän teknologista synenergiaa sillä, että tuote tulee samalta toimittajalta.

Jos budjetointidata tallentuu omaan tietokantaansa niin kuin usein tapahtuu, pystyy sitä lukemaan mikä tahansa BI-työväline.

Ja useimmiten budjetointisovelluksen datat viedään ensiksi tietovarastoon josta ne pyöräytetään raportointisoftaan. Tällöin varsinkaan ei ole mitään merkitystä miltä toimittajalta tuotteet ovat.

 

Blokkaat turhaan pois hyviä tuotteita

Tämä pätee etenkin julkisiin kilpailutuksiin. Suomen markkinoilta löytyy muutamia isoja IT-taloja, joilta löytyy sekä BI että budjetointituotteet. Näitä ovat mm. IBM Cognos, SAP ja Oracle.

Sitten on BI-toimittajia, joilta ei löydy budjetointisoftaa suoraan itseltään. Näitä on mm. Microsoft, Tableau, QlikView.

Nyt jos kilpailutat molemmat samalla ja hintaa sekä toiminnallisuutta arvioidaan kokonaisuutena, häviää jälkimmäinen porukka aika varmasti. Kuitenkin tiedon visualisoinnin ja ns. data discovery -kategoriassa juuri nämä kolme ovat markkinoiden parhaat. Ainakin Gartnerin mielestä.

Kilpailutuksissa Microsoft, Tableau, QlikView ja kumppanit joutuvat tarjoamaan jotain 3. osapuolen budjetointituotetta. Vallan hyviä vaihtoehtoja mutta kuten aiemmin sanoin, hinnan puolesta he eivät usein voi kilpailla isoja toimittajia vastaan koska he eivät usein voi vaikuttaa 3. osapuolen lisenssikustannukseen samalla tavalla.

Toisaalta myös monipuolisuudessa QlikViewn kylkeen usein tarjottavat budjetointituotteet (esim. Kliqplan) jäävät isojen toimijoiden vastaavista.

Tai sitten he häviävät suoraan jos kilpailutuksen vaatimukset asetetaan erityisen tiukaksi eikä sallita 3. osapuolen softia.

Tämä voi tietenkin olla tarkoituskin. Mene ja tiedä.

Suositus: keskitä mutta mahdollista erillinen hankinta

Itse kannatan, että tiettyyn tehtävään hankitaan aina paras tuote. Vaikka ne tulisi eri toimittajalta. Toisin sanoen tuotteen käytettävyys on avainasemassa, teknologisen yhdenmukaisuuden hieman kärsiessä (mutta oikeasti ei juurikaan kärsi koska kuten sanoin, saman toimittajankin tuotteet ovat yleensä eri maailmoista).

Suosittelenkin  siis seuraavaa BI- ja budjetointituotteita kilpailuttaessa:

  • keskitä hankinta niin säästät aikaa, rahaa ja vaivaa
  • keskittämällä saat mahdollisuuden puristaa isoilta toimittajilta hyvän nippuhinnan
  • mutta pidä ehdottomasti avoinna mahdollisuus hankkia tuotteet eri toimittajilta
  • tämä tarkoittaa oikein muodostettua RFP:tä. Pisteytys täytyy eriyttää.
  • Paras BI-tuote pitää pystyä voittamaan, ilman että sen huono/olematon budjetointiominaisuus vetää sitä alaspäin

 

Ensi kerralla aiheena: kannattaako BI ja data science -tuotteet kilpailuttaa samalla kertaa?


15.09.2016 / Anssi Falk

Here’s three simple things that you should probably understand if you’re going to do business

  1. your selling process
  2. the customer’s buying process
  3. how these two should be aligned

And here’s how much a selling process, no matter how refined, is of value if you don’t understand the buying process of the customer: near to nothing.

Now, there’s this general statistic floating around that 70% of the buyer’s journey is behind him/her before contacting any relevant, potential providers. I’d argue that this statistic is very misleading if not taking into consideration the fact that a buying process is very much dependent on various factors concerning the need, available information and the set of options. Still, this statistic conveys the important point that in today’s digitalized world being relevant to the customer is more important than ever before.

As there are notable differences between B2B and B2C selling processes, there are undoubtedly differences between B2B and B2C buying processes as well. However, the common denominator when it comes to a buying process is still the human component running through the buying process and, ultimately, making the final choice.

American psychologist Barry Schwarz coined the term “Paradox of Choice” in his 2004 book with the same name. The digital economy at that time was constantly growing in importance with regards to giving consumers seemingly unrestricted access to product information provided by, not only the suppliers but peer consumers as well. Also, in terms of digital goods, the variety of options was not bound by the restrictions of the non-digital past such as physical shelf space.

However, as Schwarz argued, this abundance of available options could mean that rather than getting the best solution available, one could end up choosing nothing at all or choosing a non-optimal solution as the consumer’s mental short list consisted only of brands familiar (consciously or subconsciously) to her/him. A seemingly unlimited amount of choices can paralyze rather than liberate.

Coming back to the meaning of being relevant, the main question is, how to be that final choice over the competition? We could dive into the details of Michael Porter’s different competitive strategies (first introduced in the 80’s) such as differentiation or price leadership. Or, we could take a few steps back and realize that in order to make use of a good winning strategy, one must first be in the group of considered options – a precedent that seems very trivial but more often than not is not the target of sufficient effort. Let’s simplify and just state that the aforementioned statistic is universally true. What are your actions in order to maximize your involvement in the first 70% of the buyer’s journey in order to be on the (mental) short list?


14.09.2016 / Markus Kuuranta

Käytettävyystestaus on menetelmä, jonka tarkoitus on arvioida suunnittelunaikaisten valintojen toimivuutta todellisissa olosuhteissa. Se on siis pitkälti käytettävyysmaailman vastike toteutusvaiheen tekniselle testaukselle. Vaikka käytettävyystestaus onkin eräs yksinkertaisimmista tavoista parantaa tuotteen käytettävyyttä, sivutetaan se ohjelmistoprojekteissa merkillisen usein. Syitä löytyy varmasti aina projektipolitiikasta lähtien, mutta yksi on ylitse muiden: käyttöliittymäsuunnittelijan rooli on helppo ymmärtää väärin.

Tässäpä shokkiuutinen: käyttöliittymäsuunnittelija ei ole sovelluksen käytön asiantuntija – se rooli kuuluu käyttäjälle!

Käyttäjä – tuo oman alansa rautainen ammattilainen – tarkastelee käyttöliittymää kymmenien vuosien kokemuksen tuomasta näkökulmasta, eikä yksikään suunnittelija voi tavoittaa sitä tiedostamattomien valintojen polkua, jonka käyttäjä tekee käyttöliittymän ääressä. Kattavalla käyttäjätutkimuksella ja toimialaymmärryksellä voidaan toki luoda puitteet järkevälle suunnittelulle, mutta kun kyse on oikean maailman oikeista työtehtävistä, vastaa yksi oikea käyttäjä tuhatta arvuuttelevaa konsulttia. Ainoa poikkeus tähän ovat ne suunnittelijat, jotka omaavat itse vuosien kenttäkokemuksen myös laborantin, kirjanpitäjän, lennonohjaajan ja kirurgin työstä.

Koska käyttäjät eivät ole suunnittelijoita, on käyttöliittymäsuunnittelijan rooli havainnoida käyttäjiä ja sorvata käyttöliittymä tätä käyttöä paremmin tukevaan muotoon.  Sovelluskehityksen kannalta olisikin parasta järjestää kevyt käytettävyystestaus heti kun se on vain mahdollista, jotta ohjausliikkeet saataisiin tehtyä ennen työlään toteutusvaiheen etenemistä.

Kaikkein kevyinkin käytettävyystestaus on parempi kuin täysin testaamatta jättäminen. Käytettävyystestauksen ohittaminen onkin verrattavissa siihen, että sovellus viedään tuotantoon ilman minkäänlaista teknistä testausta.

Toblerone ©Mondelez Schweiz GmbH

Toinen yleinen, joskin täysin inhimillinen, prosessivirhe on Toblerone-efektiksi ristimäni ilmiö (jos tälle on jokin virallinen termi, ole hyvä ja kerro se minulle).

Tuossa ylempänä on kaikille tuttu Tobleronen logo. Huomasitko, että vuoren sisälle on piilotettu karhun siluetti? Kas näin! Tästedes aina kun näet tuon logon, huomaat karhuhahmon, halusitpa sitä tai et. Toblerone-efekti tarkoittaakin juuri tätä: kerran koettua oivallusta ei ole mahdollista “oppia pois”.

Kun ryhmä eri alojen asiantuntijoita suunnittelee sovellusta yhdessä, muodostuu käyttöliittymälle usein sama Toblerone-efekti. Viikkoja kestäneen suunnittelun jälkeen käyttöpolut ja painikkeiden toiminnat ovat työryhmälle yksinkertaisesti niin tuttuja, ettei niiden käyttäytymistä ole edes mahdollista kokea toisin. Tällöin muutosehdotukset sivutetaan helposti väärinymmärrettyinä, ja käyttöliittymä oletetaan erilaiseksi kuin se projektin ulkopuolisen silmin todellisuudessa on.

Käyttäjätestaus on tehokkain tapa päästä eroon Toblerone-efektistä. Oikean käyttäjän kokemus konkretisoi ajatustenluvun mahdottomuuden ja mahdollistaa ensireaktion uudelleenkokemisen toisen käyttäjän silmin. Käyttäjätestaus tuo projektiin objektiivisen näkökulman – se pakottaa karhun pois vuoren sisältä.

 

Lue lisää käyttäjäkeskeisestä suunnittelusta: