Discussion :

[challenger84]

Salut,
Y a une petite question sur laquelle j'aimerai débattre.

D'après vous la véritable mission de l'informatique décisionnelle c'est quoi?
Si on regarde par exemple le forum de developpez.com dédié à la BI on serait tenté de dire que ça se résume au reporting. Ce que d'ailleurs beaucoup de gens pensent!!!!!

D'un côté si on regarde les cours données dans un master de business intelligence on trouve du datamining, des réseaux de neurones, de l'optimisation, de la recherche opérationnelle etc...on remarque beaucoup de mathématiques au passage comme si on allait faire de la recherche.

D'un autre côté si on jette un coup d'oeil aux offres d'emplois BI. On recherche des gars qui savent utiliser les ETL et paramétrer BO et compagnie. Et ça je trouve qu'un gars qui a une bonne connaissance en base de données et en développement pourrait très bien le faire.

Bref concrètement, en réalité dans les entreprises, en quoi consiste réellement actuellement le job d'un ingénieur BI?

[pnoel-bi]

Bonjour,

Cela n'est pas une petite question.
La BI est l'ensemble de plusieurs techno de plusieurs outils ou logiciels...
Et soit l'on est spécialisé dans une ou plusieurs partie ETL ( chargement, transformation des données ) SGBDR ( DBA, conception des bases .. ) soit dans l'extraction des données avec BO, COGNOS...
Et oui si l'on veut manier la BI dans sa globalité il y à de l'administration de bases ou de serveurs connaissance des réseaux voir une partie mathématique statistique par exemple s’il y a une demande conception de tableaux de bords.

La discussion est ouverte
Cdlt

[pnoel-bi]

Voici un exemple d'annonce il faut vraiment bosser dans toutes les matières

Description de l'annonce :
Vous contribuerez à la mise en oeuvre d'un projet d'envergure, la création du nouveau système d'information décisionnel du groupe.

Dans la phase initiale du projet, afin de vous familiariser avec l'environnement de la société, vous travaillerez principalement sur les problématiques techniques (développement des flux d'alimentation, administration de la base, restitution, maintenance de l'environnement technique). Vous serez ensuite rapidement amené(e) à concevoir et spécifier les évolutions du système en collaboration avec le Responsable du Service Décisionnel, les responsables des applications sources et les responsables opérationnels de la société. Vous participerez activement à l'ensemble des phases d'intégration du projet :

- expression des besoins,
- conception fonctionnelle et technique,
- développement,
- intégration,
- recette technique et fonctionnelle,
- mise en production.

Profil recherché :
Diplômé(e) d'une formation supérieure, vous avez participé à la mise en oeuvre de projets stratégiques et possédez une solide expérience dans le domaine de l'informatique décisionnelle / Business Intelligence. A ce titre, les concepts de datawarehouse, datamart, datamining, OLAP, tableaux de bord et portail décisionnel vous sont largement familiers. Vous justifiez d'une expérience d'au moins deux ans dans la conception et le développement de systèmes d'information décisionnels, depuis l'intégration des données jusqu'aux restitutions et aux déploiements de solutions analytiques. Vous maîtrisez impérativement le langage SQL et le développement sur Business Object (univers et rapports). Idéalement, vous maîtrisez également l'administration d'une base de données SQL SERVER et l'ETL GENIO.

Rigoureux(se) et impliqué(e), votre souci de la qualité, votre capacité d'adaptation ainsi que votre esprit d'équipe sont vos atouts pour réussir à ce poste.

Anglais technique

Cdlt

[yphilogene]

Je n'ai pas eu la chance d'avoir des cours de B.I. en école, mais je dois dire que je n'en ai pas vraiment besoin.

Comme tous les cours, les profs chercheurs poussent le bouchon très loin et orientent leurs exposés vers la recherche, les mathématiques, le futur...

C'est bien marrant tout ça, c'est comme mes cours de telecom/réseaux, hyper dur, hyper technique. Au final, tu deviens admin réseau, à mettre en place des LANs et à configurer un routeur Cisco. Je caricature, mais c'est pour dire quel décalage il y a entre les cours d'école et la grande majorité des emplois liés au secteur. C'est probablement la même chose pour la B.I.

La Business Intelligence embrasse tout un ensemble de compétences, qui va du profil très technique au profil plus commercial. Au niveau technique, il est selon moi fondamental d'avoir des connaissances en SQL, ie. comprendre de quelles façon on peut interroger des tables. Après, si on veut continuer dans la BDD, on devient carrément DBA en faisant du tuning, de partitionnement, etc... et on finit par perdre de vue la B.I.

Au dessus de la BDD, il y a les outils de modélisation: Cognos, BO, SAS, etc etc... C'est le coeur du métier, c'est là que l'Intelligence se trouve, dans la façon d'organiser les données. Construire des cubes, mettre en place des modèles en étoile. Je trouve ça passionnant. C'est tout le temps la même chose, et en même temps tout le temps différent.

Après, au bout de la chaîne, il y a le reporting. Faire du reporting n'a rien de dévalorisant, j'ai commencé par ça. Ce n'est pas rien de comprendre la finalité et l'utilisation d'un rapport. Mais ça devient vite répétitif.

Pour répondre à ta question, je te dirais que les entreprises cherchent des débutants pour réaliser des rapports, après chacun fait son chemin en fonction de sa réussite, de son application et des projets.

Mon point de vue personel et qu'il faut pour être un bon ingénieur B.I. connaitre les limites imposées physiquement par les systèmes de bases de données pour organiser l'information, pour pouvoir faire au mieux pour obtenir des données de qualité, accessibles et sécurisées.

[Benoit_Durand]

J'ai déjà eu à travaillé sur toutes les étapes de la chaîne de la conception et specs aux rapports finaux, mais en entreprise on croise souvent des personnes plus spécialisées : alimentation, reporting, conception de l'entrepôt voire dans un éditeur particulier Datastage, Cognos ...
Donc au final tu vas trouver beaucoup de profils différents et ils seront tous dans la catégorie Ingénieur BI et tous auront leur place dans une entreprise.

J'ai eu la chance de suivre quelques cours orientés décisionnel dans une université outre atlantique dont un cours d'entreposage de données où 50% du programme a été de la théorie sur le datamining. Combien d'ingénieur BI ici font du datamining et utilisent couramment les réseaux de neuronnes pour optimiser leurs recherches ? Pas des masses et je n'ai jamais touché au datamining en entreprise. Même si ces cours peuvent s'avérer très intéressants ils sont souvent loin de la réalité des entreprises, comme l'a dit yphilogene.

[Jester]

Pour l'écart entre les cours et l'entreprise c'est assez facile à expliquer (je suis dans le monde de la fac).

Les cours sont fait par des chercheurs (la plupart du temps). Ces chercheurs ont envie de faire des cours sur ce qu'ils font ou du moins connaissent.

Le problème c'est que la problématique de l'entreprise, au moins en France, c'est pas leur tasse de thé, de même qu'en général les trucs technique (mais là ça dépend). De plus, il y a très peu de recherche à faire sur le reporting ou les dashboard :-)

[ygrim]

Salut tout le monde,
J'ai eu la chance de suivre un cours ou le professeur n'étais pas un chercheur, mais un professionnel du BI. Cette personne a su nous inculquer les valeur fondamentales de l'informatique décisionnelle.
Selon lui, et je partage son opinion pour ce point, un professionnel du BI est une personne qui a une vue d'ensemble sur le processus necessaire à l'etablissement d'un environnement décisionnel. J'entends par la l'analyse des besoins, l'etude de l'existant, la conception et la mise en oeuvre. Donc oui, un ingénieur BI doit avoir des aptitudes certaines autant dans le technique (conception, mise en oeuvre, data mining, etc.), que dans le relationnel (interviews, analyse des besoins, des tendances, etc.). Un profil idéal en BI étant une personne qui a déja roulé sa bosse dans les systèmes OLTP et qui a le recul nécessaire pour voir l'utilité et la faisabilité d'un environnement BI dans une entreprise.
Je tiens cependant à vous rappeler qu'un projet d'environnement décisionnel est un gros projet impliquant plusieurs domaines de compétences : gestion de projet, adminstration des données, documentation, conception de l'ETL, étude des besoins stratégiques, OLAP, data mining, etc, etc, etc. Un professionnel du BI peut oeuvrer dans chacune de ces disciplines. Il existe des staticticiens qui se spécialisent dans la partie data minig des projets décisionnels, il existe des programmeurs analystent qui ne font que de l'ETL et il existe aussi des gestionnaires de projets qui orientent leur carrière dans le décisionnel.
Donc la vrai question qu'un nouveau venu dans le décisionnel doit se poser n'est pas quel est le profil d'un spécialiste du BI mais plutot dans quelle "spécialité" je veux me placer (ETL, gestion de projet, administration des données, OLAP, etc.), quelles entreprises je cible (PME, grosses boites) et comment aquerir l'experience nécessaire (formation, mentorat, developpez.com(trop facile))

[Antoun]

Je dirais que la BI, c'est l'ensemble des outils informatiques d'aide à la décision. Donc, tout ce qui sert à créer du reporting. Au premier rang, les outils de reporting proprement dits, avec en gros deux catégories : le reporting figé (un développeur crée des états pour des utilisateurs qui se contentent de les rafraîchir) et le reporting dynamique (le développeur crée une couche sémantique qui permet aux utilisateurs de faire eux-mêmes leurs états).

En même temps, n'importe quel reporting n'est pas décisionnel. Un bon de livraison, un relevé de notes, un rapport de caisse, etc., sont des exemples de reporting opérationnel, qui sont produits et utilisés dans la production quotidienne de l'organisation, et non pour orienter des décisions plus ou moins stratégiques. A l'inverse, ce qui est décisionnel (BI), c'est le reporting analytique, qui a pour principale caractéristique de porter sur des données agrégées. Savoir que M. Martin a commandé une Quatre Fromages pour 20h relève du reporting opérationnel ; déterminer que les Quatre Saisons sont en hausse de +10% annuels alors que les Calzone baissent de -5%, c'est du décisionnel. Techniquement, la principale différence entre les deux est que les données sont détaillées dans le premier cas, agrégées dans le second.

C'est de cette idée d'agrégation que viennent les autres éléments du système d'informations décisionnel. En effet, sur une base normalisée, les agrégations sont censées être intégralement recalculées à chaque interrogation, en vertu du principe de non-redondance. Cela conduit évidemment à des performances pitoyables, et au risque que les requêtes décisionnelles viennent gêner la production. Il apparaît donc rapidement nécessaire de copier les données sur un autre serveur, et de pré-calculer certaines agrégations. Ce qui nous amène à deux autres aspects de la BI, la construction de bases dénormalisées servant au reporting (datawarehouses, datamarts, modèles en étoile et en flocon), et les outils permettant de les alimenter à partir des bases de prod (ETL).

Une autre catégorie d'outils sont les bases de données multidimensionnelles, ou cubes OLAP. Plutôt que de répondre au problématiques de l'analyse et de l'agrégation par une dénormalisation de bases relationnelles, ces outils proposent un modèle alternatif, conçu spécifiquement pour analyser des données agrégées à tous les niveaux.

Enfin, une série de domaines (qui, historiquement, se sont développé en-dehors du décisionnel mais sur des problématiques proches) convergent aujourd'hui vers la BI : le datamining, l'analyse statistique, le targeting, le performance management, etc.

[Antoun]

Pour l'écart entre les cours et l'entreprise c'est assez facile à expliquer (je suis dans le monde de la fac).

Puisque je tiens un universitaire et qu'on parle de l'écart avec le monde de l'entreprise... pourquoi aucun des jeunes diplômés qui arrivent dans ma boîte n'est foutu de faire une jointure externe, ni même de savoir en quoi ça consiste ? Je n'ai pas fait d'études d'informatique et j'ai donc un peu du mal à comprendre comment ça se passe...

[ygrim]

Merci merci pour toutes ces définission, tu as mis dans le mil !
J'ai parcontre deux petites remarques à faire :
- L'informatique décisionnel n'est pas seulement le rerporting analytique ou les entrepôts de données. C'est vrai, ces deux éléments sont une grande partie de la définition du BI. Mai le BI est, par définition, tout ce qui peut créer de la connaissance en entreprise, ça peut même ne pas être informatique. S'interresser aux processus métier de l'entreprise c'est faire du BI. Un livre que j'ai lu (Data Warehousing Fundamentals) résume très bien ce qu'est le BI: faire du décisionnel c'est voir l'entreprise rouler, et faire de l'opérationnel c'est faire rouler l'entreprise. Le but ultime étant de la faire rouler plus vite grâce aux observations que l'on fait.
Je citerais, cependant, un contre exemple qui montre que le décisionnel ne se résume pas qu'au reporting : les ODS (Operational Data Store). C'est une structure de données qui utilise les informations compilées dans un entrepôt de données pour les ré-injecter dans le système opérationnel (pour corriger des erreurs de facturation par exemple). On est loin du reporting, mais sa reste du BI.
- Une base de données multi dimensionnelle est une base conçue selon le modèle dimensionnel (dimensions, faits). La pluparts (pour ne pas dire) tous les entrepots de données sont construits selon ce modèle. OLAP représente la manière dont ces modèles sont exploités. Dans ce cas, c'est vrai que nous trouverons du ROLAP, MOLAP, ou HOLAP. Mais tous ces modèles dénormalisent les données opérationnelles pour en faire des données analytiques, la différence étant comment cette dénormalisation se fait et comment les agrégations sont calculées.

[nuke_y]

Je dirais que je suis tout à fait d'accord avec ygrim et plus ou moins avec Antoun et pnoel-bi. Disons que pour les 2 derniers, pour moi la BI ne doit surtout pas être définie par les logiciels et/ou technologies qui la rendent possible mais par ses concepts, concepts qui ont besoin des logiciels/technologies pour être mis en oeuvre bien évidemment.

Je suis tout à fait d'accord avec Antoun sur ce point là :

Enfin, une série de domaines (qui, historiquement, se sont développé en-dehors du décisionnel mais sur des problématiques proches) convergent aujourd'hui vers la BI : le datamining, l'analyse statistique, le targeting, le performance management, etc.

J'adore cette définition ygrim :

faire du décisionnel c'est voir l'entreprise rouler, et faire de l'opérationnel c'est faire rouler l'entreprise. Le but ultime étant de la faire rouler plus vite grâce aux observations que l'on fait.

Je ne suis pas d'accord sur ta définition de l'ODS par contre :

Je citerais, cependant, un contre exemple qui montre que le décisionnel ne se résume pas qu'au reporting : les ODS (Operational Data Store). C'est une structure de données qui utilise les informations compilées dans un entrepôt de données pour les ré-injecter dans le système opérationnel (pour corriger des erreurs de facturation par exemple). On est loin du reporting, mais sa reste du BI.

Un ODS, pour moi, c'est un espace dédié au stockage des données opérationnelles (fraîchement descendues des bases opérationnelles) et à leurs transformations avant la descente dans les datamarts. En (très) gros pour moi le contenu d'un ODS c'est les tables de travail qu'on peut vider à chaque traitement. Alors effectivement on peut remonter leur contenu vers les bases opérationnelles mais même si ça se fait, c'est globalement assez mal vu comme processus, encore plus pour de la "correction d'erreurs". Ce qui se fait pas trop mal par contre c'est de remonter des indicateurs dans le système opérationnel pour aider à la décision "opérationnelle", par exemple remonter l'information "client pourri, à surveiller" dans l'écran des télé-conseillers qui n'ont pas le temps de consulter des listings de clients pourris pour vérifier si le mec qu'ils ont en ligne s'y trouve.


Pour apporter ma pierre à cette intéressante question que je me suis moi-même posé il y a quelques jours pour préparer une petite introduction à la BI à des étudiants, je dirais que la BI et le décisionnel ... ce n'est pas tout à fait pareil !
Dans ma reflexion actuelle je reviens aux termes de base de Business Intelligence : l'intelligence / la reflexion / l'analyse / le renseignement sur le métier / les affaires / l'entreprise.

Donc pour moi, et je rejoins Antoun, la Business Intelligence :

englobe :
- le reporting : savoir ce qui se passe dans l'entreprise (le reporting opérationnel est directement géré par les applications opérationnelles)
- le décisionnel : les outils (au sens large, pas seulement les logiciels) pour aider à la prise de décision : indicateurs, axes d'analyse, tableaux de bords les représentants, etc.
- le data mining : des analyses poussées pour "chercher la pépite" dans la "boue" des données opérationnelles mais aussi résoudre des problèmes/analyses trop vastes/compliqués pour du décisionnel. Pour le décisionnel on sait à peu près ce qu'on cherche mais on veut une vue synthétique, dans le datamining on peut chercher sans forcément savoir.

facilite, touche ou passe pas loin de :
- la recherche opérationnelle : aider à l'optimisation des processus opérationnels
- la stratégie d'entreprise : stratégie à moyen et long terme, nécessite du décisionnel pour valider les choix


Evidemment on retrouve du reporting dans le décisionnel, du décisionnel dans la stratégie, etc.

Ensuite, pour mettre en oeuvre ces principes, on utilise des outils/technologies (des fois on peut s'en passer bien sûr) :
- le reporting : outils de reporting + architecture dédiée
- le décisionnel : datawarehouse + ETL (pour alimenter les datamarts)
- le data mining : logiciels de data mining, des algorithmes évolués
- la recherche opérationnelle : logiciels et alogrithmes de recherche opérationnelle
- la stratégie d'entreprise : cerveau + flair + chance


Et comme le disait pnoel-bi, pour chaque outil/technologie il faudra peut-être développer ses compétences en administration système, en BDD, en réseaux, en scripts, etc.

[ygrim]

Merci pour ton feed back !!
Je pense que tu confond entre ODS et Data Staging : Wikipedia

La principale fonction d'un ODS est de "recompiler" les données opérationnelles après les avoir fait passer au jugement décisionnel

En ce qui concerne la différence entre entre BI et décisionnel, et bien le mot décisionnel n'est qu'un "françicisme" innaproprié au BI. Mais c'est de la même chose qu'on parle. Certains l'appelent même intelligence d'affaire (quebec). Ce sont des petits abus de langage que les gens se permettent (moins grave que de mélanger cube, entrepot et data mining)
Et pour revenir à l'ODS, nous avons étudié ç la fac un cas pratique (videotron, une entreprise de telecom) ou les informations du système de facturation et les informations sur les émissions aux abonnés étaient collectées dans un entrepôt de données pour être recrachées dans un ODS pour détecter les personnes qui ne payent pas pour avoir leur abonnement ou qui payent un abonnement de base mais reçoivent des options en plus. Je suis certain de ma définition

[nuke_y]

mhhhmm, effectivement j'ai toujours considéré l'ODS comme un espace de travail permettant de rassembler les données des plusieurs sources opérationnelles hétérogènes et de les retravailler pour ensuite alimenter les datamarts, mais c'était un peu réducteur et j'ai fait un abus de language en parlant d'ODS au lieu de data staging. La définition wiki est sûrement plus juste. Pour moi ODS voulait dire "Operational Data Staging" soit "Stockage temporaire des données opérationnelles", ce qui collait plutôt bien avec l'utilisation que j'en faisais. Dorénavant je parlerai de "Data Staging".

Par contre je ne suis pas d'accord pour le fait que son but soit de remonter les informations dans les bases opérationnelles. Ca me parait autant voire plus réducteur et la définition wiki ne parle pas de ça :

Un ODS (ou "Operational data store") est une base de donnée conçue pour centraliser les données issues de sources hétérogènes afin de faciliter les opérations d'analyse et de reporting. L'intégration de ces données implique souvent une purge des informations redondantes. Un ODS est généralement destiné à contenir des données de niveau fin comme par exemple un prix ou le montant d'une vente, en opposition aux données agrégées tel que le montant total des ventes. Les données agregées sont stockées dans un entrepôt de données (datawarehouse).

ici aussi on ne parle pas de remonter les données au système opérationnel : http://searchoracle.techtarget.com

Ici on trouve la même définition que celle que j'avais avant : http://www.informatica.com

Un article où on parle de la complexité de la construction d'un ODS : http://www.dmreview.com

Tu aurais un endroit où la définition que tu donnes est développée ?

[ygrim]

http://enterprisearchitecture.nih.go...usePattern.htm

et cet excellent article que je viens de trouver :
http://www.dmreview.com/issues/19980701/470-1.html

Je vais le relire tout à l'heure pour la peine

[nuke_y]

Euh mais... nulle part on parle de remonter des informations dans le système opérationnel là C'est ce point là qui me pose problème dans ta définition, pas le fait que l'ODS serve à des reportings/analyses opérationnels.

[yphilogene]

Je crois qu'on peut tourner longtemps en rond en essayant d'éclaircir les habituels abus de langage présent dans l'informatique en général. La B.I. n'est pas épargnée. On aura beau trouver une définition d'un ODS qui mettra tout le monde d'accord sur ce forum, il suffit d'intervenir chez un client qui a lu Decision magazine pour entendre ce terme employé n'importe comment...

Je me colle au nom: Operational Data Stage. En gros, un espace pour stocker des données opérationnelles. Après, on en fait ce qu'on veut. La question est de savoir pourquoi il a été nécessaire d'y transférer les données de production et donc de développer des interfaces.

Et ça, l'ingénieur B.I. doit pouvoir l'expliquer, le justifier, parce que tout ça a un coût.

[nuke_y]

L'article est pas mal ygrim mais par contre cette application d'un ODS me dépasse là :

Good Application of an ODS #2: Functional integration. "We could really increase sub-component inventory turnover at the Dallas final assembly plant if we just could synchronize the Charlotte production line with the one in Atlanta." Again, the solution will require subject-oriented, integrated, current and detailed information, which will require a transaction-based update mechanism in order to retain integrity and currency.

J'ai rien compris au texte ou ça a plus rien à voir avec de la BI là ?

D'accord avec toi yphilogene, on mettra pas le monde entier d'accord en discutant à 4 sur ce forum, mais si déjà on arrive à se mettre d'accord tous les 4 ça sera pas mal...

[ygrim]

Oui, c'est pas dit texto ! ça entre dans le cadre de l'analyse et de la prise de décision stratégique. Mais dans l'exemple que je t'ai donné plus haut, l'entreprise utilise l'ODS pour valider (et corriger si necessaire) les données des différents systemes, qui ne se parle pas forcément. C'est ça la valeur ajoutée : intégrer des données qui ne se parlent pas pendant la production pour détécter des erreurs.
edit : désolé, j'ai deux posts de retard !! +1 pour Yphilogene

[yphilogene]

Je crois qu'un ODS permet d'implémenter de la B.I. opérationnelle. Il n'a pas la prétention de calculer des Key Performance Indicators mais basiquement de réaliser un reporting opérationnel sur des données qui potentiellement peuvent avoir plusieurs sources.

Le cas typique et moderne, ce sont les outils ERP et CRM qui permettent de saisir de la données dans une base qui ne peut cependant pas être utilisée pour réaliser du reporting un tant soit peu sophystiqué. On utilise alors un ODS comme base de réplication dédié au reporting B.I.

Inévitablement, l'ODS est amené à évoluer pour intégrer d'autres sources de données, des calculs prédéfinis, un référentiel, etc... et il finit par se transformer en data warehouse.

[Antoun]

Je me colle au nom: Operational Data Stage. En gros, un espace pour stocker des données opérationnelles.

petite correction : il s'agit de Operational Data Store => stockage de données opérationnelles.

La fonction normale d'un ODS est de servir de tampon d'alimentation entre les bases opérationnelles et le datawarehouse. En effet, on ne met dans un DW que des données intégrées, càd qu'on a effectué une série de transformations telles que des rapprochements, des dé-doublonnages, des conversions, etc. Comme tous ces traitements peuvent être lourds, il est risqué de les faire faire par le serveur de prod.
on conseille donc de copier telles quelles les données de la prod sur un ODS, oú on effectuera les transformations lourdes, avant passage dans le DW.