• Est-ce qu'on utilise des terminaux de type BlackBerry, toujours connectés, avec les données "fraiches" livrées automatiquement sur le terminal en mode Push.  Intéressant lorsque l'utilisateur est dans son pays d'origine - mais comment maîtriser les coûts lorsqu'on est en déplacement?
• Est-ce qu'on utilise des terminaux de type Windows Mobile, une connexion en 3G (donc d'une vitesse respectable), mais avec un browser web d'une qualité somme toute juste acceptable
• Est-ce qu'on utilise un terminal type iPhone, avec un bon browser Web qui fait croire au serveur que c'est un browser "normal" de desktop, et on laisse l'utilisateur zoomer/dézoomer, scroller à volonté sur une page - globalement est-ce qu'on ne fait rien de spécial pour le mobile.  Microstrategy met en avant cette possibilité - sauf qu'avec cette plateforme, c'est le serveur qui donne des pages adaptées au terminal, et non le terminal lui-même qui s'en occupe - un gain certain d'utilisation, surtout si le processeur du terminal n'est pas très puissant)
• Est-ce qu'on développe des applications pour les terminaux (le chemin favorisé par BO), ce qui permet  d'adapter les requêtes existantes aux contraintes de l'écran, et en plus qui permet une gestion des données "en cache", afin de pouvoir accèder aux informations même quand le terminal n'est pas connecté au serveur.  Dans ce cas de figure, il faut aussi se poser la question des mises à jour des applications - comment gère-t-on des bugs dans les applications, de nouveaux cubes d'analyse, etc?  (surtout lorsque l'application a été déployée sur des centaines de terminaux)
• Est-ce qu'on a besoin de plus que de la présentation pure de données?  Par exemple, SAP propose une solution d'application sur écran mobile avec Webdynpro mobile.  Cette option est très séduisante pour des applications de type CRM, où saisir des informations en temps réel peut être très utile, mais là encore, il faut bien gérer les cas où le terminal n'est pas connecté (mettre les informations en cache jusqu'à la prochaine conenxion, par exemple)

• les coûts de connexion
• la sécurité des informations - que ce soit sur le réseau ou sur le terminal
• les mises à jour d'applications mobiles - comment allez-vous gérer ça?
• la notion de "single truth" partout sur le paysage
• l'ergonomie de votre application BI - est-ce qu'elle arrivera a capter l'attention de vos utilisateurs?
• la fraicheur des données vs. la sécurité vs. les coûts

Le coté législatif de la lutte contre le carbone se précise... le seul problème, c'est que les gouvernements sont nationaux mais que les entreprises sont globales, et devront faire face à de diverses obligations d'informations. Dans le même temps, les clients et actionnaires sont de plus en plus friands de chiffres précis et fiables sur le sujet (certains clients commencent à exiger un impact CO2 sur les factures fournisseurs

Pour ce faire, les entreprises se dotent d'outils, qui ont dans un premier temps pour but de mesurer pour chaque étape des process de l'entreprise l'impact en terme de CO2, puis dans un second temps améliorer cette trace...

Et c'est la qu'interviennent les outils de BI... collecter, transformer, 'budgéter', agréger les données pour permettre une analyse pertinente (comparer impact carbone VS rentabilité des produits par exemple, émission de carbone par site de prod, par technologie...)

Le marché est énorme, certains analystes anticipent un marché de plus 10 milliards de US$ en 2012.

Quoi de mieux d'un bon outil de BI pour collecter puis analyser les données ! SAP avec Business Objects est sur les rang, entre autre en fournissant une solution de portail déclaratif et analytique CO2 au CDP (Carbon Disclosure Project), une ONG Américaine qui collecte les déclarations d'émissions de CO2 d'un nombre important de sociétés Américaines

Voici parmi tant d'autres quelques affirmations qui tuent, et qui sont souvent à l'origine d'échecs et de problèmes sur les projets :

1 – « si on le construit, ils vont venir »

2 – « la qualité des données : pas un problème chez nous »

3 – « les managers doivent savoir jongler avec les chiffres. »

4 – « Darwin raconte n’importe quoi, notre solution BI n’a pas besoin d’évoluer »

5 – « je veux juste un dashboard »

6 – « nous pouvons outsourcer la maintenance de notre BI »

1 – Si on le construit, ils vont venir…

Dans de nombreux projet BI, seule la DSI est moteur… les utilisateurs sont au mieux peu intéressés par la solution en devenir... on entend souvent dire « lorsque la solution sera la, ils vont venir l’utiliser »

C’est une grossière erreur, et bien souvent, une perte monumentale d’argent pour les sociétés… la DSI, malgré ses qualités, ne peut définir quels sont les indicateurs de performances du contrôle de gestion ou des ventes…

On en arrive alors au rôle crucial de la MOA… ils doivent être le lien entre les équipes métier et les équipes outil, piloter le changement quand cela est nécessaire, savoir écouter les utilisateurs, comprendre les enjeux futurs pour la société, mais aussi proposer…

Comment ne pas se « planter » ?

• Avoir une solution qui respecte les principes RACT :

Relevant : insight appropriate ffor important business questions                                                                                                                                                       Accurate: Correct, precise. Consistent: Same results across multiple tools and applications. Timely: Answers and insight available when needed.

• Avoir un centre de compétence BI
• Passer autant de temps à vendre la solution qu’à la développer

2 – la qualité des données : pas de problèmes chez nous

Moins c’est un problème, plus le problème est vaste… la qualité de votre solution BI dépend entièrement de la qualité de vos données (‘Garbage in -> Garbage out’)

Si vos données en entrée ne sont pas propres, la solution donnera des résultats faux, les utilisateurs s’en détourneront rapidement…

• La qualité des données dépend du Business… et surtout pas de la DSI… l’idéal étant de nommer dans chaque service un ambassadeur de la qualité des données.
• Identifier les points noirs et se concentrer sur ceux-ci
• Mettre en place des indicateurs permettant de mesurer cette qualité des données

3 – les managers doivent avoir la possibilité de jongler avec les chiffres.

Un danger classique de certaines cultures d’entreprises… les chiffres doivent souvent être travaillés avant d’être présentés.

C’est alors le royaume des tableurs Excel et autres Access qui donnent chacun une vérité différente. (Faites le test, et demandez à chaque intervenant le C.A. de la société, vous serez surpris de l’importance des écarts constatés)

Comment ne pas se « planter » ?

• Utiliser des standards du type Sox pour mettre en place une culture plus orienté traçabilité et sureté des données
• Comprendre que le management intermédiaire n’est pas toujours intéressé par la version unique de la vérité
• Comprendre et mettre en lumière les agendas cachés !

4 – Darwin raconte n’importe quoi, notre solution BI n’a pas besoin d’évoluer

La solution BI doit refléter l’entreprise et ses évolutions… penser qu’un projet BI s’arrête un jour et que les équipes de développement pourront rentrer chez elles est une utopie…

Le monde change, les concurrents évoluent, les contextes économiques changent, bref tout change de plus en plus rapidement. Dans ce contexte, croire que les indicateurs de performances peuvent rester figés relève du suicide économique.

Bien souvent, la fin d’un projet BI marque le retour des outils ‘maison’ tel que Excel et Access que les utilisateurs sont obligé de monter pour avoir leurs indicateurs pertinents, avec la non garantie de cohérence des résultats (alors que bien souvent, une des motivations pour un projet BI est d’avoir une seule vérité et ce faisant de tuer ces outils incontrôlés et incontrôlables)

Comment ne pas se « planter » ?

• Il faut voir la BI comme une activité et non comme un projet. Il est donc conseillé de ne pas dissoudre le projet initial, mais de l’intégrer dans un centre de compétence, qui regroupe les compétences métier et technique pour faire vivre la solution.
• Planifier régulièrement un point sur la pertinence des indicateurs en place et une livraison de nouveaux indicateurs.

5 – je veux juste un dashboard

C’est une phrase que l’on entend souvent, mais qui peut être dangereuse… puisqu’elle peut mener à une nouvelle version de la vérité…

De plus, si on travaille sur un tableau de bord seul, on perd la capacité d’analyser en détail les chiffres et donc à comprendre et analyser.

Comment ne pas se « planter » ?

• Le dashboard doit être vu comme la cerise sur le gâteau, et donc il faut un gâteau en dessous avec les bons indicateurs, partagés et validés par tous.
• Si la plateforme BI est de bonne qualité, le dashboard est quasi gratuit
• Il est nécessaire de travailler avec une cartographie des indicateurs

6 - nous pouvons outsourcer la maintenance de notre BI

Dans la lignée de « notre BI n’a pas besoin d’évoluer », outsourcer la BI, c’est l’éloigner des utilisateurs et donc prendre un très grand risque de le voir devenir complètement caduque…

La BI est le reflet de la stratégie, en tant que telle est doit rester au cœur de l’entreprise....