la récré du WE : 8ème épisode

Un petit quizz... le gars au-dessus est :

A - le futur James Bond
B - le chéri de Britney Spears
C - Un top model pour un parfum
D - un utilisateur de Business Object ^^

Réponse........ D of course : retrouvez le teaser du film ici  - me demande si c'est pas un peu trop pour un histogramme et un camembert ;-)

EDIT : Dans la série... la vidéo de Cognos 10, c'est pas mal aussi

Extract Transform Load... and Cry

J'ai la possibilité dans mon blog de voir si les personnes sont passées par un moteur de recherche et surtout quels mots clés utilisés dans la recherche... Il y'a une recherche qui a retenu toute mon attention dont le libellé était "dataware sans etl"...

Le schéma ci-dessus montre toutes les fonctionnalités d'un ETL... depuis les sources de données jusqu'au chargement dans votre datawarehouse... c'est une brique de votre solution BI. Il y'a un excellent article Wiki ici qui explique chacune des trois étapes que je vous détaille ci-dessous

1 - Extract
"the goal of the extraction phase is to convert the data into a single format which is appropriate for transformation processing... An intrinsic part of the extraction involves the parsing of extracted data, resulting in a check if the data meets an expected pattern or structure. If not, the data may be rejected entirely or in part."


2 - Transform
"The transform stage applies a series of rules or functions to the extracted data... Selecting only certain columns to load... Translating coded values... Encoding free-form values... Deriving a new calculated value... Sorting... Aggregation... Splitting a column into multiple columns... etc...".

3 - Load

"The load phase loads the data into the end target, usually the data warehouse (DW)... "

4 - ... and Cry

Vous pouvez commencer à pleurer : 

- sur le temps que vous allez passer à faire la recette du datawarehouse... avec tout ce que la donnée à subi, il vous sera impossible de la rapprocher avec quoi que ce soit du système d'origine. Vu et archi vu, le datawarehouse qui est censé le reflet de votre ERP ressemble à une copie déformée invérifiable.

-  sur le temps que cela va prendre à mettre à jour les données... très forte probabilité que vous n'aurez rien avant 24h !

- sur le temps que passera l'équipe d'exploitation à réparer tous les incidents sur le processus de la transformation au chargement (cf mon article sur les 10 plaies de votre dataware ici ).

Et d'évoquer deux pistes à explorer (ou en cours d'exploration) :

- le bulk copy de base à base : les solutions les plus simples... sont aussi les plus rapides. Pourquoi se prendre la tête avec une extraction, une transformation et un chargement... identifiez le/les tables qui vous intéressent dans votre ERP... et faite une violente copie de la table dans votre datawarehouse. Vous serez étonné par les temps et surtout risque d'erreur réduit à néant. Ca ne fait pas un datawarehouse me direz vous... "a subject oriented, nonvolatile, integrated, time variant collection of data in support of management's decisions"... cf article ici ... c'est encore à démontrer et une chose est sure, un datawarehouse n'est pas un truc qu'on répare tous les matins avec des utilisateurs en berne une grande majorité du temps !

- le change data capture : article wiki ici - le graphique résume à peu près l'idée qui est de s'appuyer sur des log de modification de votre base qui est en support de votre applicatif (OLTP DB)... pour alimenter ainsi votre dataware. Cela réduit fortement l'intrusion... j'y crois beaucoup à cette idée et cela nous permet d'imaginer des solutions en temps réel sans casser votre système source.

PS : j'espère ajouter d'autres pistes !

Le 50ème billet... celui qui explique les 49 premiers !

50 billets déjà... Il y'a de tout. J'avais essayé de structurer les choses sur le billet "fil rouge"... mais c'était peut être trop tôt... J'ai donc repris mes 49 billets et fait un travail de synthèse ou "best of"

Une conviction au service d'une finalité métier 
L'ouvrage de droite est le point de départ et en particulier ce passage là : "By analytics we mean the extensive use of data, statistical and quantitative analysis, explanatory and predictive models, and fact-based management to drive decision and actions". Vous avez  ici la section wikipedia de "Busines Analytics" que je trouve très bien aussi. Mais j'insiste cette conviction doit servir une finalité métier, d'où mes trois billets sur la valeur de ce type de démarche :
- "20 ans après" (ici) : la valeur de "contrôle" de votre business
- "Larry Ellison et la valeur de votre BI" (ici) : la valeur de s'intégrer dans chaque décision ou action au sein de votre logiciel de gestion d'entreprise
- "Amazon.com " (ici)  ou comment des fonctions analytiques peuvent inciter de nouvelles ventes et faire augmenter votre chiffre d'affaires !
- "Analytique" (ici) : c'est bien aussi d'entendre un chef d'entreprise en parler.
- "How it works" (ici) : un petit film tout simple sur le sujet.

Un "peu" de matériel et de logiciel... 
Pour faire cela, il vous faudra un peu de matériel... J'aime assez l'idée de la tortue de Timo Elliot (ici ). Le matériel peut être un formidable accélérateur... comme votre croix. Deux billets illustrent cela :
- "Kingston et... Small is beautiful" (ici)
- "SAP et... Big is ugly" (ici)

Du coté logiciel, il se passe beaucoup beaucoup de choses nouvelles :
- "La BI traditonnelle est-elle morte" (ici) : ou pourquoi le "search" peut tout changer
- "Visio... for BI" (ici) - où comment concilier représentation de vos processus et analyse de leur efficacité.
- " Tableau software" (ici) : certainement le meilleur logiciel à date en terme de représentation
- "BI en mémoire associative " (ici et ici) : mon préféré du moment Qlikview... vraiment étonnant !

L'usage au centre, l'interface utilisateur, l'importance de "l'écran"
C'est le thème pour lequel j'ai consacré le plus grand nombre de billets... assez en adéquation avec l'idée que la seule valeur d'un système BI, c'est son usage. La première idée pour développer l'usage... c'est comment via la "data visualisation", on peut aider l'utiliser à comprendre ses données.
- Google fait des choses remarquables sur ce sujet (ici et ici)
- On peut aussi aller chercher des idées du coté des "gourus" du slide (ici)
- et bien sur de vous recommander le travail remarquable de Stephen Few (ici)
- et dans son expression ultime, cela peut même relever de l'art (ici)
Autre élément mis en avant pour développer l'usage, ce que j'ai regroupé autour du fait que la BI doit être sous toute taille d'écran :
- Un billet qui montre l'usage de chaque taille d'écran (ici)
- et bien sur cette année aura été marquée par la tablette d'apple (ici) et ses "mobile" apps (ici)
Et enfin, ce qui est certainement le plus important, c'est comment tout cela s'intègre dans votre quotidien :
- ce qu'on appelle l'informatique ubiquitaire (ici et ici)
- mais aussi plus simplement de parler de la problématique de vos outils bureautique, que ce soit la messagerie (ici)... et l'inévitable powerpoint (ici).

Connecting people... 
C'est devenu un slogan : BI = data + people !
la BI toute seule ne peut pas s'en sortir... elle doit aussi relier les gens, ajouter des fonctionnalités nouvelles (ici)... J'ai aussi challenger cette idée de self-service BI (ici). Il faut rester prudent sur les réseaux sociaux, ne pas tomber dans un effet de mode. Mon propos est que vous pouvez avoir le plus beau graphique du monde avec le meilleur calcul dedans... il vous faudra toujours quelqu'un pour l'expliquer - que la valeur d'un chiffre tient dans son commentaire, dans son explication. L'idée est de décupler l'intelligence collective dans votre organisation (ici).

Mettre son casque de chantier ou la question du comment
Ce n'est pas une critique mais je ne travaille pas dans un département marketing d'un éditeur de logiciel BI... La matérialisation de la promesse reste totalement au coeur de mes préoccupations... Je parle sans aucun problème des échecs et des erreurs sur mes projets.
- que ce soit la tentation de faire des projets "sur mesure" (ici)
- d'avoir monter des dataware douteux (ici et ici)
- de voir dans le SaaS tous les problèmes attachés au décisionnel en interne (ici)
- de bien sur d'avoir des problèmes de qualité de données (ici)
- de m'étonner de voir comment se pratique la BI par le Cigref (ici)
- et de clairement m'interroger sur les méthodes de développement (ici et ici)

Je vais continuer à développer ces thèmes... peut être en trouver d'autres. Il reste d'autres billets non évoqués... les premiers que j'ai appelé "récré"... la BI c'est parfois drôle... les deuxièmes autour des "gourus" de la BI : Cindy Howson, Timo Elliot... pas forcément toujours d'accord avec eux mais c'est toujours brillant... la BI a pour particularité d'avoir ces "personnalités" uniques.

PS : Petite pause ces prochains jours du "haut" de ma montagne de 50 billets... à moins que le démon du blog ne me reprenne assez vite ;-)

La récré du week-end - 7ème épisode...

On trouve vraiment de tout sur YouTube... Je vous ai trouvé "AcidPreacher" qui est à la fois chanteur professionnel et fait du marketing chez SAS, l'éditeur de solutions BI (si si c'est possible)... Il nous a fait une vidéo qui explique la "Business Analytics"... c'est étonnant : ici la vidéo... et la bio du monsieur ici. Pour reprendre un de mes tics de langage... c'est assez énorme !

PS : En préparation, le 50ème post :-)

SAP... et "Big is ugly"

J'avais fait un post "Kingston... et small is beautiful". L'actualité me permet de faire l'inverse !

Le monsieur de droite, c'est Vishal Sikka - le monsieur "Technology et Innovation Platform"... Il vient d'annoncer que SAP avec sa technologie Hana a réussi à charger 460 milliards d'enregistrements en... mémoire vive... Retrouvez ici l'article de Decideo.

J'ai cherché tous les articles sur cette annonce et en particulier à quoi cela pouvait bien servir. On sait que ce serait pour une grande entreprise de biens de consommation, qu'il aura fallu que quelques secondes pour requêter dessus, que c'est lié aux points de vente... mais rien sur les motifs et l'intérêt métier. Et donc je suis revenu à la source, la vidéo de son intervention. Je me suis fait violence...

Après 1h20...on en vient au passage clé sur le "In memory Computing"... ce qui le frappe, c'est d'abord la puissance des derniers serveurs blade... 64 coeurs avec 2 To mémoire vive... pour lui c'est profondément une rupture et que l'on doit donc ré-écrire le logiciel. Il raconte qu'il a rencontré un copain CTO du coté de Berlin qui lui a dit... "chiche que tu me charges en mémoire toutes les données de ma très grosse société avec ton SAP"... Il nous explique aussi que les 45 to de données sont devenues 5 to en mémoire avec sa technologie de base de données en mémoire et que le joujou pour faire cela coûte 530K$... Cela ouvre de nouvelles portes comme faire du temps réel sur un système transactionnel sans ETL, sans extraction, sans agrégation à faire et toutes ces informations au bout des doigts pour l'analyse, l'exploration, etc... avec - je le cite - le ciel pour seule limite. La présentation s'achève avec une démo qui consiste à changer quelque chose dans un bon vieux SAP de base... et de retrouver cette modification dans votre outil de reporting quelques secondes plus tard chargée en mémoire. Tout le monde fait clap clap clap... wow... great... That is amazing.

 Alors pourquoi "Big is Ugly"...

Toute cette débauche technique finit au bout par l'écran de droite et un pauvre histogramme tout moche bleu et... orange !

C'est aussi très laid d'un point de vue intérêt business... son copain CTO avec ses 460 milliards de lignes en mémoire aurait quand même pu lui trouver un gain métier fort.. ne serait-ce que pour trouver un ROI au 530K$ dépensés pour la machine...