Termen ”Big data” är ett utmärkt exempel på det. ”Big data” har blivit synonymt med vällustiga stön och flackande blickar. Alla pratar om det men få har egentligen nått begrepp om vad det handlar om. Varför är det så? En förklaring kanske ligger i att det inte är allt för vågat att påstå att 99,99% av sveriges företag och organisationer snarare har att hantera ”Small data” än ”Big data”.

De datavolymer som hanteras är sällan ett problem numera, framförallt tack vare utvecklingen på hårdvarufronten. För svenska bolag torde utmaningarna snarare vara hur man kan hantera ”Small data” på ett så kostnadseffektivt sätt som möjligt. Att hantera 100 miljoner rader data i en databas är oftast lika resurskrävande som att hantera 10 miljoner rader om man betänker att den största kostnaden är den utvecklare som skriver och underhåller kod för att hantera datat.

Hur skall man då göra för att effektivisera sin tillvaro utifrån paradigmet ”Small data”? Ett sätt är att använda molntjänster, dessa kommer sannolikt att bli mer och mer intressanta för ”Small data”-företag. Ett annat sätt är att driva standardisering till sin spets. Genom standardisering så kan man återvinna tidigare arbete och därmed komma snabbare framåt. Standardisering innebär avkall på den ”kreativa friheten” och ställer höga krav på att den som är ansvarig för standardisering förstår på vilket sätt man kan standardisera. I sverige finns också ett fokus på att förenkla metoder så att man inte behöver ha kostsamma experter för att göra minsta lilla grej. Fokus är på sunt förnuft och förenkling snarare än hjärnkraft och komplicerade algoritmer. Man  kan också fundera på om man verkligen behöver de allra häftigaste prylarna i alla lägen. Om Gripen är bra nog för sverige är det bra nog för schweiz som försvarsminister Ueli Maurer sa.

Kill your babies liksom.

En försäljningschef kanske vill veta hur kunder som varit med i en viss kampanj för 12 månader sedan utvecklats över tid. Eftersom kunder kan vara med i flera olika kampanjer under året så är lösningen i ett OLAP-verktyg att skapa kolumner för varje kampanj kunden varit med i. Detta är självklart väldigt opraktiskt, och då kommer QlikView’s ”ID-filtrering” till full rätt.

Skall man förklara den fantastiska framgång som QlikView har just nu så beror det på att de främst tillgodoser behov som ännu inte traditionella OLAP-verktyg kunnat hantera. Dock tornar problemen upp sig på himelen, då många aktörer nu är på väg in i samma nisch. Snart är även detta med ”ID-sökning” mainstream. Främsta tecknet att hålla utkik efter är när Microsoft hittar på en ny Sql-server-modul för ändamålet. SSCS kanske, Sql server Column services. Den som lever får se.

Åhlens har nyligen tagit ett system från Neolane i bruk. Systemet innebär att den centrala marknadsavdelningen kan använda en hel palett med kanaler som tidigare inte varit helt synkade. Till exempel så är både butik och kundtjänst integrerade i systemet vilket gör att processen att rekrytera nya medlemmar till Åhlens-kortet förbättrats radikalt. Tilltalet personaliseras och anpassas till respektive kund för att öka relevansen. Marknadsavdelningen har också fått en betydligt bättre överblick över vad som sker i kampanjerna då systemet har inbyggd rapportering av alla aktiviteter, till skillnad från förr då dyrbara programmeringsresurser krävdes för att ta reda på kampanjutfall.

 Seminariet var tydligen uppskattat då det var så trångt att de sista åhörarna fick nöja sig med ståplats längst bak. Marknaden för kampanjhanteringssystem har varit rätt trög i sverige, men på senare år så har något hänt. Intresset har ökat och kanske kommer kundklubbarna tillbaka som företagens främsta verktyg för att kommunicera med sina bästa kunder.

Ett annat problem är alla säljare och leverantörer av lösningar inom området. Det lovas guld och gröna skogar till höger och till vänster. Det är mycket snack och liten verkstad i det mesta som sägs och görs. Som affärsansvarig matas man med ständiga budskap om att man måste ha än det ena och än det andra. Jag kan tycka att säljmöten med analysleverantörer ibland är som att gå in i en klädaffär på Oxford Street i London. När man kommer in genom dörren så särskådas man – är detta en person som har stålarna redo? Om så är fallet så förföljs man vart man än går fastän man kanske bara vill titta lite. Slutligen får man känslan att att expediterna blir i det närmaste förbannade om man inte köper åtminstonde ett par häftigt överprisade designerjeans.

Så använd analys, men med förnuft. Lite som Torbjörn Nilsson sa i dokumentären ”Fotbollens sista proletärer” - jag fick ut mer kreativitet när Svennis gav mig struktur i mitt spel.

Men som alltid finns det detaljer som komplicerar bilden. Mer intressant än att bara titta på några väl valda enskilda poster i denna undersökning borde summan av allt arbete vara. Om man tittar i tabellunderlaget från undersökningen och summerar posterna förvärvsarbete, hushållsarbete och studier så visar det sig att kvinnor spenderar 458 minuter i snitt per dygn i arbete. Jämförs med männens 451 minuter. Skillnaden i arbetsbörda blir alltså 7 minuter av ett dygn på 1 440 minuter. 7 minuter, vågar jag påstå, är inte en signifikant skillnad med hänsyn till urvalsfel och mätfel i undersökningen.

Så goda nyheter. Arbetet i slott och koja är helt jämställt. Enda skillnaden är att män och kvinnor tenderar att göra lite olika saker.

De första dw-systemen drevs ofta av enskilda individer på enskilda avdelningar. Någon någonstans har ett informationsbehov och sätter igång att bygga. Detta skapar dw-silos som har överlappande funktionalitet och ofta även överlappande informationsuppdatering. Tex är det inte alltför ovanligt att SPAR-data köps in av flera avdelningar oberoende av varann därför att det är mer bekvämt att köpa var för sig snarare än att försöka komma överrens om eller ens inse hur en gemensam specifikation borde se ut.

Ett annat problem med master data är hur informationen distribueras ut till olika applikationer. Vissa leverantörer driver tex tesen att det endast skall finnas ett enda data lager som alla ”analytiska BI-applikationer” läser emot. Men skall denna tes kunna uppfyllas innebär det att alla upphandlingar av system måste innehålla krav på att applikationen eller verktyget skall kunna integrera (native helst) mot det centrala lagret. Detta är i sig en väldigt svår policy att genomdriva då de ansvariga för systeminköp sällan har den typen av krav som ”make-it-or-brake-it” villkor. Bättre då att ha en uttalad strategi om hur data hanteras, distribueras och underhålls. Genom att tillhandahålla färdiga och vettiga koncept kan MDM faktiskt vara en möjliggörare snarare än ett problem. Brasklapp: Ett sådant upplägg kräver att DW-ansvariga har en djup förståelse för hur data används i organisationen, något som kanske inte alltid är fallet.

Typiskt för de första generationerna av data warehouse och business intelligence-verktyg är att de är inriktade på rapportering. Funktionellt så stödjer dessa tidiga generationer av DW framförallt controllers, företagsledning och annan typ av personal som har behov av att följa nyckeltal.

Data skall i detta paradigm trasporteras till ett data warehouse, lagras i en lämplig form och sedan användas för rapportering av användare som accessar statistik via ett eller flera rapportverktyg, tex Cognos Powerplay, Business Objects eller Qlikview. På senare tid har applikationer även börjat dyka upp där ett ramverk inriktad för specifika funktioner adresseras. Tex finns det specifika lösninar för koncernrapportering, prognosarbete och så vidare. Dessa applikationer bygger dock fortfarande på att data residerar i ett centralt placerat warehouse.

Men framtiden för data warehouse går bortanför rapportering. Nya tillämpningar bygger mer och mer på data (historiskt och aktuellt) som genereras i en del av ett företag, transporteras och bäddas in i andra system för att användas i andra sammanhang inom företaget. Ett exempel på detta är master-data-management där tex kunders adresser uppdateras centralt från ett register kopplat till SPAR, där informationen som hämtas slår igenom i alla operativa system.

Data warehouse blir i nästa generation snarare en del av en informationsinfrastruktur som stödjer flera delar av företaget. Man pratar om Operational DW som begrepp. En fundamental skillnad med ett klassiskt DW är att ETL inte längre räcker till, då ETL endast beskriver vägen IN i DW för data. Snarare borde det heta ETL-TD -> extract, transform, load, transform, deliver. TD på slutet innebär betydande förändringar i ett traditionellt DW. Hur skall data levereras till mottagande system? Hur säkerställa konsistens med master?  Vad är master överhuvudtaget? Vilka huvudsakliga intressenter finns för dataleveranser från data warehouse? Hur undvika att integrationer byggs mellan system-system snarare än mellan system-dw-system? Konsekvensen av en för tungrodd DW-organisation är att olika system i topologin börjar integrera mellan varandra snarare än att använda hub-spoke-metoden.

Klarlagt är att ansvariga för BI/DW-funktioner på företag måste börja fundera på dessa frågor om så inte redan görs. Det gäller att lyfta blicken och ta in synpunkter från andra intressenter än ekonomichefen, som traditionellt varit mest tongivande vad gäller data warehouse. Vilken information behövs var i företaget för att optimera processer och göra affären mer lönsam? Hur skall information användas för att stödja kundupplevelsen? Hur skall information användas för att göra företaget mer lönsamt?

Håkan Borg

På den analytiska sidan så finns det nu ännu mer statistiska modeller att grotta ner sig i, om mot all förmodan det som redan finns inte skulle räcka till.

Mer detaljer: http://support.sas.com/software/93/index.html

Det känns som att i och med att information lagras i större utsträckning, och görs tillgängliga via kraftfulla verktyg desto mer suddas de moraliska gränserna kring vad som är integritet och inte ut. För ungefär 40 år sedan så kom den så kallade IB-affären ut i ljuset, där staten anklagades för att registrera känslig information. Jag kan i mitt stilla sinne tycka att IB-affären var rätt naiv i jämförelse med det avancerade underrättelsearbete som vanliga journalister på vanliga svenska tidningar ägnar sig åt idag.

Orsaken till problemen är många  – slarv med uppgraderingar,  för snävt dimensionerad hårdvara, en djungel av skript som ingen vågar göra något med för ”då kan allt rasa”. När data skall extraheras till ett data warehouse så kommer alla sådana problem upp till ytan som riskerar att skapa en konflikt mellan systemförvaltning av erp och systemförvaltning av data warehouse.

Vad kan man göra för att komma runt problemen? Min erfarenhet är att E i ETL är lösningen på många problem. Grundregeln är att belasta ERP-sidan så lite som möjligt, detta sker enklast genom att läsa ut fysiska tabeller direkt som de går och står från källan. Undvik för allt i världen att joina tabeller för att skapa ett mer färdigt resultat i källsystemet. Det är en säker väg att få prestandaproblem. Skall endast vissa kolumner ut så kan man avgränsa och även om man bara vill ha en delmängd. Avväg filtreringar mot tid det tar att spola ut hela tabeller. Om det tar längre tid att få ut tabellen vid filtrering än att plocka hela så plocka hela.

Denna tumregel gäller givetvis inte om ett mer avancerat middlware används, tex Tibco. I det fallet så sker ju uttaget på ett mer kostnadseffektivt sätt från början. Men det är inte alla som har råd att investera tid och kraft i middleware. Då kommer oftast gamla hederliga avgänsade textfiler i bruk.

Hur hanterar man affärslogik då? Det vanligaste argumentet för att låta levererande system göra mycket ”T” som i transform är att endast i källan finns affärslogik på ett vettigt sätt. Detta är ett synsätt jag inte håller med om. Oftast går det att med lämpliga avstämningar simulera affärslogik i en stageingarea. Användarna av data warehouse ser dessutom till att rättningar genomförs löpande så problemet är inte stort.