Le NY Times qui nous raconte comment Toyota donne du lean plutôt que de l’argent aux associations. Un retour intéressant par Kevin Meyer sur le sujet : « When your organization donates to charitable causes, are they just fueling an inefficient process, or are they actually trying to create improvements? », j’adore !
John Gruber qui tire un boulet justifié sur les analystes et leur fâcheuse tendance à choisir et adapter les faits pour qu’ils correspondent à leur vision du monde. C’est un défaut qu’on peut également retrouver chez nos utilisateurs en BI, à nous de bien dessiner les systèmes pour prévenir au maximum cet effet.
Sur SQL Server c’est le 3,103, ou 112, ou 20… en paramètre duCONVERT(Datetime,’31/01/2013′,…). Ça fait 7 ans que je le pratique, jamais bon du premier coup…
Traduction approximative:
« Rob, tu connais Unix, vient vite! »
Pour désarmer la bombe, il suffit d’entrer une commande tar valide du premier coup. Google intertdit. Vous avez 10 secondes.
Au-delà de la réponse théorique, c’est une question à laquelle il faut bien répondre dans le contexte du projet en cours.
Le cas du jour : une recette qui ne se termine pas chez un client, principalement parce que leurs applicatifs sont des sources inépuisables d’anomalies de données.
Alors ça ne rate pas, le chef de projet MOA et le sponsor s’agacent en comité de pilotage : « Y’en a marre, ça n’en finit pas, en plus vous êtes en régie et ça nous coûte trop cher ».
Certes, mais l’objectif initial du datawarehouse, ça n’était pas d’avoir une base centralisée, consolidée, propre de la comptabilité du groupe ?
Parce que la plupart des anomalies rencontrées sont bien des erreurs dans les données, qu’elles soient mal saisies dans les systèmes comptables ou résultantes de bug de ces mêmes systèmes. Chaque anomalie résolue c’est des données nettoyées, c’est une comptabilité plus propre, c’est donc bien de la valeur ajoutée !
Celui qui en a conscience c’est le futur utilisateur de la solution, responsable du contrôle de gestion qui se doutait que sa compta n’était pas bonne, qui en a enfin la preuve, et qui est enfin capable de le détecter et de le corriger.
Via Jason Kottke, cette jolie vidéo qui présente la chaîne d’assemblage de Tesla pour produire le Model S :
Prenez le temps de la regarder, elle est courte et elle vaut vraiment le coup d’œil.
Pour donner un peu de contexte, Tesla Motors est un constructeur automobile américain récent, spécialisé dans les voitures 100% électriques, lancé par Elon Musk, un Nikola Tesla moderne. Comme on le voit dans la vidéo, ils sont au somment niveau innovation.
Ce qu’on peut voir dans ces vidéos, c’est pour une chaîne de fabrication le top en termes d’organisation, de flux de production, d’automatisation, d’intégration logistique, d’amélioration continue… (de lean manufacturing en sorte) qui mènent au top en terme de qualité et de temps de construction (3 jours pour une voiture, combien de temps pour un projet décisionnel?).
Et de là on peut faire le parallèle à notre activité de développement en décisionnel, sur SQL Server ou pas. Chez nous, pas d’usine logicielle, très peu de frameworks – ou qui ne font pas franchement rêver – le tout début de la génération automatique de code (il faut que je m’y mette), surtout des Best Practices transmises via savoir tribal et quelques Design Patterns (SSIS oui, SSAS et SSRS sont bien vides).
Ça c’est sur la conception, mais côté industrialisation on est aussi à la ramasse. Entre autres: un déploiement de toute une solution en un clic c’est encore trop risqué, un build complet ça n’est pas possible et ça ne sert surtout pas à grand chose, et si les tests automatisés fonctionnent bien en SQL OLTP, c’est encore dur de comparer des données en provenance de sources hétérogènes (SQL vs MDX vs DAX, à voir si ça n’est pas en train de changer).
On présente le futur de la BI comme étant un mix de Big Data, de Data Visualisation, d’in-memory, d’analyse prédictive, de stockage verticale ou encore de Cloud. Certes, mais je crois qu’avant cela il faudrait déjà qu’on rejoigne le présent du monde du développement logiciel. Ce serait déjà pas mal.
Deux points positifs cependant : on se rattrape sur les cycles d’amélioration continue : côté plateforme (base de données des bugs, templating, reporting sur l’usage et les performances…) et côté équipe (revue de code, plan de formation, plan de carrière, suivi des objectifs…). Et également avec la verticalisation, à savoir : on construit une fois, le plus proprement possible, et on réutilise sur d’autres projets qui utilisent les mêmes applicatifs sources. Mais ça ne marche que dans les marchés où les progiciels utilisés sont toujours les mêmes (compta d’entreprise, RH, CRM…), marchés qui sont finalement assez rares.
A nous donc d’arrêter de courir après les dernières modes, et de nous concentrer sur ce qui est vraiment important pour la croissance de notre « science » (dit-il tout en préparant un article sur Azure – spoiler : le IaaS c’est trop bien ;)).