projet datawarehouse "fusion d'entreprise"

[Joel95]

Bonjour,

Je voudrais savoir si quelqu'un à un exemple de document avec les différentes étapes de mise en place d'un datawarehouse sachant que nous allons fusionner tres prochainement avec une autre société n'ayant pas de datawarehouse mais que nous devrons intégrer dans notre datawarehouse. Le document devra donc aussi décrire cette spécificité.

en vous remerciant de votre aide

Joel

[Joel95]

quelqu'un est motivé ?

[nuke_y]

J'ai pas de doc tout faits mais un peu d'expérience. J'ai préparé un truc vite fait et je te l'améliore quand j'ai du temps.

[doc malkovich]

pas de doc non plus, mais on peut te conseiller
dis nous en un peu plus ...

Tu penses faire quoi ?
Quelle est ton infrastructure, tes outils ?
Et pour l'autre société ?

[nuke_y]

Tu pourrais répondre aux questions de doc stp ? Je pense que si tu veux qu'on t'aide il faut que tu nous donnes plus d'informations. Je dirais qu'un petit texte de 20/30 lignes avec des exemples serait pas mal.

[Joel95]

Bonjour et merci de vous interesser à mon problème.

Voilà en fait je suis plus technique que fonctionel.

En gros j'ai créé en petit datawarehouse avec les services les plus motivés de mon entreprise ... tout est resté très technique ... besoins des utilisateurs donnés oralement ...et débrouille toi bibi pour répondre à leur demande ...
Aujourd'hui nous avons fusionné avec une entreprise qui n'a pas du tou de datawarehouse ... Donc là je veux faire un document propre : un cahier des charges pour créer un datawarehouse avec entres autres l'analyse de l'existant, l'architecture technique (le mienne et celle de la nouvelle société),
les besoins utilisateurs , les problèmes techniques etc.

Ce qui me fait peur c'est que les utilisateurs ont des besoins mais qu'ils ne prennent pas le temps pour les exprimer du coup j'ai l'impression que c'est moi qui doit leur donner leur besoin ???

Est -ce que cela est déjà plus clair ?

[nuke_y]

Bon c'est le WE, la famille dort et j'ai 250 Go à défragmenter, donc je prends le temps de te répondre.

D'abord je dirais qu'un datawarehouse est LE bon outil pour assurer une fusion d'entreprise. Souvent les outils sont différents et il faut revenir à une modélisation commune des données pour pouvoir les mélanger et les comparer. Je l'ai déjà fait dans une grande entreprise française, filiale d'un très grand groupe mondial, et il s'agissait typiquement de problématiques de fusion des activités et de reporting global.

Je dirais que le point essentiel c'est de savoir si l'entreprise avec laquelle vous allez fusionner va utiliser les mêmes outils que vous : même ERP, même logiciel de finance, de RH, etc. Si oui, j'espère que vous allez fusionner vos données (avec une reprise) et donc finalement les nouvelles données seront naturellement intégrées aux anciennes. En gros il n'y aura presque rien à faire.

Si vous n'utilisez pas les mêmes outils ou si vous ne fusionnez pas vos données, alors il y aura effectivement un gros travail à faire mais ça sera intéressant (je t'envie, veinard).

Bon alors dans l'ordre:

- savoir quels sont les services qui ont une volonté de réaliser des analyses cumulées et croisées. De base je pense que tu auras au moins le service commercial et le service RH : le commerce voudra faire des analyses cumulées (pour savoir combien l'entreprise a vendu en tout) et les RH voudront faire des analyses croisées (comparer la rémunération de 2 profils équivalents dans les 2 entreprises par exemple).

- trouver comment extraire les données des différents systèmes : export en texte, ETL, etc.

- pour les services qui veulent intégrer le DWH, tu as 2 choix:

* Soit les métiers des 2 entreprises se ressemblent, et tu peux arriver à faire "rentrer" leurs données dans ta modélisation actuelle, quitte à ajouter quelques petites modifications. Dans ce cas il suffit de rajouter un champ à toutes tes données qui indique l'origine (entreprise A ou B). Dans tes analyses tu peux décider de faire l'analyse en utilisant ce champ (tu verras donc les données séparées) ou pas (tu verras donc les données cumulées). Dans ce cas on va dire que tu travailles sur les différences, cad que ce sont les différences qui vont créer tes contraintes.

* Soit les métiers sont trop différents, ou ont des spécificités trop importantes, et dans ce cas tu dois tout casser et refaire. Je te conseille de garder ton DWH existant (s'il fonctionne bien) et d'en créer un nouveau. Dans ce DWH tu vas créer des tables qui contiennent les éléments communs aux 2 entreprises. Par exemple si la 1ere vend des voitures et que la 2e loue des voitures, tu auras en commun le fait de faire du chiffre d'affaire par voiture mais c'est tout car les spécificités de la vente (% de réduction, crédit, etc.) et de la location (durée, loyer, etc.) sont différentes. Dans tous les cas tu vas devoir fortement t'appuyer sur le business des 2 côtés pour qu'ils "se mettent d'accord". Dans ce cas on va dire que tu travailles sur les ressemblances, cad que ce sont les ressemblances qui vont créer ton besoin. A noter quand même qu'il va falloir faire disparaître l'ancien à terme, en faisant en sorte que le nouveau couvre tous les besoins de l'ancien.


Do & Do Not :

Do :
- se faire soutenir à fond par la(les) direction(s). Tu n'arriveras jamais seul à obtenir validation de tes chiffres sans ça. De plus ce sont les seuls à avoir "l'autorité" pour que les domaines des 2 entreprises se mettent d'accord.
- communiquer au maximum avec les utilisateurs, ne pas hésiter à les harceler pour qu'ils valident les chiffres
- quand tu demandes à une équipe de te fournir des données, il faut absolument leur donner quelque chose en retour. Par exemple leur montrer comment leurs données s'intègrent dans l'ensemble de l'entreprise. Par exemple si tu demandes à un service commercial de te fournir ses chiffres, il n'y accordera l'attention (et donc la qualité) nécessaire que si ça lui sert à montrer qu'il travaille bien, voire mieux, voire mieux que les autres.
- pense petit au début : il faut des semaines pour arriver à mettre les services d'accord sur un chiffre aussi bête que le CA mensuel (c'est quoi le CA ? On déduit les avoirs ? Et un mois c'est quoi ? etc.)
- au maximum essaye de respecter l'état de l'art (n'hésite pas à acheter des livres, à lire des tutoriels) mais reste pragmatique. Ce qui est simple est faux, ce qui ne l'est pas est inutilisable (Paul Valéry)

Do Not :
- brusquer les utilisateurs : il faut du temps pour accepter de nouveaux chiffres, une nouvelle vision. Par exemple pour mettre en place de nouveaux indicateurs de mesure (qui servaient à calculer les primes des directeurs d'agence), nous avons commencé à les publier en juin en parallèle des anciens et nous ne les avons rendus officiels qu'en janvier de l'année suivante.
- parler uniquement avec les BPO, les experts Business, les consultants etc. Ces gens là ont souvent une grande connaissance du business dans sa globalité (90%) mais ignorent les points de détail (10%). Or c'est justement sur ces 10% que les utilisateurs vont te challenger, il faut donc travailler avec eux.
- oublier que les données s'accumulent avec le temps : si les performances sont déjà pourries au démarrage, tu vas galérer 1 an plus tard.


Bon voila en gros ma vision à chaud. N'hésite pas à te faire accompagner par des entreprises de conseil et si tu ne peux pas à continuer à poser des questions ici.

[doc malkovich]

Envoyé par nuke_y

Bon c'est le WE, la famille dort et j'ai 250 Go à défragmenter, donc je prends le temps de te répondre.

Arf moi aussi ça dort, et l'autre partie joue à la wii

Pour en revenir sur ton cahier des charges, ça va être dur si les nouveaux utilisateurs n'expriment pas leur besoin ! Non, ce n'est pas normal, tu vas droit dans le mur si tu le définis à leur place.
A mon avis, il est possible qu'ils ne comprennent pas l'intérêt du datawarehouse.
Tu devrais lancer une campagne de sensibilisation, en leur expliquant les avantages par rapport à l'existant. Et avec l'aide d'utilisateurs du DWH, c'est plus crédible

N'hésite pas à te faire accompagner par des entreprises de conseil et si tu ne peux pas à continuer à poser des questions ici.

Même le weekend avec des personnes comme nuke

Bon allez, j'éteins la wii et on fait le sapin

[Joel95]

Je pense que ce projet va prendre énormément de temps ... mais j'y crois ..
tu as raison nuke_y j'ai énormement de chance d'avoir un projet comme celui ci... bon du coup c'est aussi ce qui me fait peur du moins le côté méthode /organisation.C'est pour cela que je voudrais rédiger un super cahier des charges. Si vous avez un modèle à me filer , je suis preneur ..

Sinon vos réponses mon rebooster ... a chaque fois que j'aurai une baisse de régime je relirai vos posts. Merci

[nuke_y]

+1 Doc, il FAUT ABSOLUMENT les impliquer, leur faire comprendre l'importance du truc.

Quitte à en pendre un devant les autres pour leur faire comprendre (je sais c'est ma solution pour tout).

Sinon pour le "super cahier des charges" franchement, sans besoin, sans recul, sans aide, tu n'y arriveras pas. Donc prend confiance en toi et vas-y: interview, présentation, analyse, modélisation et go.

D'ailleurs pour en revenir à de la théorie, tu as 2 types de DWH :
- Top - Down : vision à la Inmon : le datawarehouse est un ensemble de tables de dimensions et de tables de faits, dont on peut générer un sous-ensemble pour faire les datamarts.
- Bottom - Up : vision à la Kimball : le datawarehouse est un ensemble de datamarts qui couvre un certain périmètre.

http://www.exforsys.com/tutorials/ms...-vs-inmon.html

Normalement pour être propre, tu devrais faire une approche Top - Down mais ça implique une bonne vision globale des dimensions et donc des métiers et des besoins. Je serais donc tenté de te conseiller une approche Bottom - Up qui te permettra de prendre moins de risques, de livrer des résultats plus rapidement et de rentre chaque service indépendant.

[Joel95]

C'est désespérant je n'y arrive pas. Help me !!!

[nuke_y]

Certes, mézencore ?

Qu'est-ce que tu n'arrives pas à faire? Tu as besoin d'aide pour quoi exactement?

[Joel95]

détailler les besoins utilisateurs :

je pense qu'il faut pouvoir récupérer de leur systemes les mêmes indicateurs
analysés chez nous (car à priori c'est ce vers quoi nous tendons).

et à part de nouveaux états à mettre en place mais utilisant les mêmes indicateurs .... je ne vois pa quoi mettre d'autres dans mon CDC actuellement ... ca me parait un peu limite ..

[nuke_y]

Dans ce cas prends le truc à l'envers: comment faire rentrer leurs données dans ton système.

Tu listes tes dimensions et tes indicateurs, tu écris tes règles de gestion, puis
:
- tu vas les fonctionnels et tu leurs demandes si les dimensions leur parle, les indicateurs existent et si les règles de gestion sont les mêmes.
- tu vas les voir les techos et tu leur demandes de te faire une extraction de quelques lignes pour tester chaque cas.

Si vraiment tu as du mal avec les fonctionnels, tu te concentres sur l'aspect technique pour la faisabilité et ensuite tu fais des itérations avec le métier pour valider les données. Comme je l'ai dit avant :

si tu demandes à un service commercial de te fournir ses chiffres, il n'y accordera l'attention (et donc la qualité) nécessaire que si ça lui sert à montrer qu'il travaille bien, voire mieux, voire mieux que les autres.

Autre chose: si tu es dans cette logique là, c'est normal que ton CDC soit restreint, puisque tu n'innoves pas. Tu ne fais que proposer de rentrer leurs données dans de l'existant. Ce n'est pas grave ni dévalorisant, c'est au contraire une expérience très intéressante. Il sera toujours temps, dans 3/4 ans, quand le système aura montré ses limites, de tout refondre.