Recherche de solution pour statistiques

Bonjour à tous,

comme bons nombres de personnes travaillant dans des services IT en tant qu'analyste-programmeur dans des PME/PMI, je suis amené chaque : jours/semaines/mois à réaliser des statistiques pour divers services : compta, commerciaux, direction, etc... en plus des demandes ponctuelles.

Nous sommes équipés, depuis bientôt 6 ans, d'un ERP (JDEdwards) seulement pour éviter la surcharge reseau en terme de requêtes récurrentes ou non, tout (ou presque) passe par notre service.

Jusqu'à aujourd'hui nous récupérons toutes ou partie de nos tables de notre base Oracle 10G dans des bases ACCESS via ODBC.

Dans ces bases ACCESS nous traitons les données par le biais de requêtes et macro que nous schedulons chaque nuit.(traitements batch)
Puis chacun des traitements sont reconditionnés sous formes diverses : éditions d'Etat, pdf envoyés par Mail, analyses croisées Excel déposées sur le reseau...

Ce qui hier ne semblait pas poser de problème, est, aujourd'hui, devenu une vrai préoccupation . En effet, nous sommes face à une demande toujours plus croissante de nos collaborateurs et nous approchons des limites de ce qu'Access peut nous rendre en terme de service. (taille de base limitée à 2Go)

Aujourd'hui nous possedons quelque chose comme une 40aine de base de données et il n'est pas rare en fin d'année de rencontrer des problèmes de taille excédant la limite autorisée.
Cerise sur le gâteau, ce que je développe sur le sol français, je dois également le reproduire pour nos filiales européennes, américaines et asiatiques.

Je suis donc à la recherche d'une nouvelle solution et j'aimerai savoir enfin quelles sont celles dont vous disposez de votre côtés, ou que vous préconiseriez, qu'elles soient logicielle ou autre, je suis open à toutes suggestions pour peu qu'elles soient viable et fiables sur le long terme.

Je vous remercie par avance

ps : on m'a parlé de WinDev, que je ne connais que de nom, pensez vous que cela puisse réellement m'apporter une solution significative ?

Bonjour,

A la lecture de votre message, il semble clair que vous ayez besoin de mettre en place un Data Warehouse pour centraliser toutes vos données dans une seule et unique base orientée vers l'analyse et le reporting.

Pour transférer vos données des tables JDE vers votre futur Data Warehouse, il est préférable d'utiliser un ETL.

Pour faire de l'analyse et du reporting, une vision à long terme vous orientera vers les plateformes décisionnelles complètes, notamment pour la gestion du multilangues, la centralisation de la sécurité, etc...

Parmi les nombreux éditeurs, je ne citerais que SAS car il s'agit d'une plateforme décisionnelle plus orientée vers les analyses statistiques que la concurrence.

Merci de votre réponse.

Effectivement, j'ai omis de mentionner que nous nous sommes équipés depuis peu d'une solution Data Warehouse qui réplique notre base 10G.
Nous avons donc l'outil SQL Developer pour visualiser nos "tables" (on parle de vues et vues matérialisées), mais est-il suffisant à lui tout seul pour gérer l'ensemble de nos traitements ? (requêtes/macro)

Si oui, possède t'il une notion "organisationnelle" histoire de ne pas mettre tous mes oeufs dans le même panier ?

Si non, quelle outil supplémentaire doit on ajouter ? en même temps que je vous lis, je fais des recherches et le nom de cognos revient tres souvent. Est ce vers lui qu'il faut se tourner pour générer tous mes traitements ou est ce juste un outil qui ne fait que de l'affichage post traitements.

Il est aussi fort possible que je fasse des erreurs d'interprétation, donc n'hésitez pas à me reprendre ou me remettre dans les rails :oops:

Je travaille avec Cognos depuis maintenant un peu plus de deux ans. La suite Cognos 8 (la version 8.3 vient de sortir) propose désormais une technologie mature et complète:

- Un portail web comme unique point d'entrée pour l'ensemble des analyses et reporting

- 2 principaux outils de modélisation: Transformer pour modéliser des cubes M-OLAP (très puissants pour l'analyse de données, type rapports financiers), Framework Manager pour construire un modèle relationel mais aussi un modèle R-OLAP permettant de réaliser des rapports d'analyses de type cubes, sans contrainte de volumétrie, sans avoir à générer des cubes.

- 3 outils de reporting: Query Studio pour du listing, Analysis Studio pour des tableaux croisés et Report Studio pour réaliser des rapports très complets. De par sa grande richesse, Report Studio est à considérer comme un outil d'informaticien. Mais depuis la version 8.3, une mode Report Studio Express est apparu, mode simplifié et donc plus accessible. Enfin, un dernier outil: Cognos BI Analysis for Excel, qui permet de rappatrier des données du data warehouse directement dans un fichier Excel.


- A noter que Cognos propose aussi un ETL assez peu visible, mais que je trouve très bien: Data Manager (ex. Decision Stream). Il offre notamment des possibilités de génération automatique de modèle R-OLAP assez bluffantes.

Les avantages d'une plateforme décisionnelle comme Cognos sont:
- La centralisation de la sécurité (accessibilité des rapports, sécurité des données,...)
- La prise en charge du multilinguisme
- La génération des rapports en HTML, PDF, Excel,...
- Le scheduling
- La gestion d'évènements, etc...

Bien que je n'ai jamais eu l'occasion de travailler avec une autre plateforme, je suis persuadé que la concurrence doit faire aussi bien. Je ne souhaite pas faire ici la publicité d'un seul produit. C'est pourquoi, je vous encourage à jeter un oeil sur la concurrence avant de faire votre choix. Je vous ai déjà parlé de SAS parce que j'ai entendu dire qu'il proposait davantage de possibilités aux niveaux calculs statistiques.





Le plus important pour faire du reporting, c'est la construction de votre modèle de données. Si elle est menée à bien, le reporting ne sera alors qu'une partie de plaisir. Donc, accordez beaucoup de temps à bien définir vos schémas en étoile.

Merci pour vos réponses, je vais regarder ce qu'il nous est possible d'envisager à moyen terme.

Je vais continuer à me documenter dans ce domaine qui est totalement nouveau pour moi, en espérant trouver la solution la mieux adapter à nos besoins.

Il est évident que ma hiérarchie préfèrerait m'entendre dire qu'il est possible de continuer à travailler avec des bases Access via ODBC, car le coût est moindre, mais cela devient de plus en plus périlleux de continuer ainsi.
En tout cas, je n'entends personne m'affirmer le contraire...

Cdlt,

Salut,

Je corrobore les dires de YPhilogène, quant à votre besoin :
Attachez-vous dans un premier temps aux données que vous allez mettre en ligne (qualité, modèle conceptuel, source et origine…) et à son architecture (en bref, tout le back office). Vous aborderez ensuite sereinement la partie interrogation, sachant que votre configuration requiert -à priori- une architecture web.

Je vous proposerai plusieurs pistes à exploiter, classées en deux groupes :

1) Remarques d’ordre général :
Oubliez Windev. Il s’agit d’un environnement de développement intégré. Vous allez mettre le nez dans le cambouis, et ce, sans voir le bout du tunnel. Ceci n’est pas en adéquation avec votre besoin.

Oubliez également Access, et mettez en œuvre une base de données digne de ce nom. Si vous avez les moyens, étendez vos droits sur la licence Oracle existante. Optez sinon pour MySQL (là vous ferez le bonheur de votre direction :D ) ou si votre volumétrie le permet, une version libre de SQL server ou Oracle.

2°) Exemple de démarche pour votre projet :
Simple et concise, elle n’est bien entendu pas exhaustive mais semble adaptée à votre configuration :

• Commencez par identifier les rapports souhaités. Je gage que vous allez mettre à jour un nombre non négligeable de doublons ou de factorisations possibles…
  
• Etablissez un dictionnaire des données recensant les informations nécessaires, leur localisation, les règles de définition de vos indicateurs...
  
• Fixez la granularité nécessaire.
  
• Mettez dans un premier temps en place un environnement de développement constitué d’une ‘Copie améliorée’ de vos données de production sur un serveur annexe. Tentez d’établir un schéma en étoile simple. Effectuez intuitivement les premières pré agrégations. En d’autres termes, occupez-vous en premier lieu du contenu, vous aborderez ensuite l’aspect alimentation.
  
• Faites l’acquisition d’un outil de restitution et concentrez-vous sur un premier périmètre fonctionnel : maquettez, diffusez et surtout, observez le retour de vos utilisateurs et leurs remarques.
  
• Dans le même temps, faites évoluer votre ‘Copie améliorée’ en mettant en place des pré-agrégations, des filtres, des batchs d’alimentation … en bref, optimisez votre base d’interrogation.
  
• Ensuite seulement, envisagez (ou non) l’acquisition d’un outil d’ETL et sa mise en œuvre. Définissez la modélisation définitive de votre source de données.

Remarques subsidiaires :
La connectivité ODBC s'avère suffisament performante quand elle n'est pas associée à des sources de données 'désuètes'. ;)
Je suppose que le terme 'statistique' est utilisé au sens large Non ? ou bien s'agit-t'il réellement de statistiques avancées faisant appel à des fonctions spécifiques (type analyse de comportement client...) ?

JPP

Dans ce cas le problème est le stockage (+ de 2 Go) pas le chargement ni la diffusion des rapports alors pourquoi rechercher une solution globale avec ETL + SGBD + analyse avec BO ou Cognos, en fonction du nombre d'utilisateurs le conseil a dépassé les 100 K€.
Si la direction ne veut aucun investissement il y a des solutions open avec MySQL ensuite si du budget SQL serveur ou +, les chargements et la diffusion des informations ne changeant pas
Cdlt

Citation:

---

Envoyé par pnoel-bi

Dans ce cas le problème est le stockage (+ de 2 Go) pas le chargement ni la diffusion des rapports alors pourquoi rechercher une solution globale avec ETL + SGBD + analyse avec BO ou Cognos, en fonction du nombre d'utilisateurs le conseil a dépassé les 100 K€.
Si la direction ne veut aucun investissement il y a des solutions open avec MySQL ensuite si du budget SQL serveur ou +, les chargements et la diffusion des informations ne changeant pas
Cdlt

---

Il me parait clair que les moyens mis en oeuvre dans la configuration décrite par Orakle sont insuffisants. La volumétrie en est une des causes, mais qui reste surmontable. D'autres éléments paraissent tout aussi importants (alimentation via access, demandes de rapports qui transitent par le SI, utilisateurs qui disposent de peu de liberté et d'interactivité, multiplicité et hétérogénéïté des restitutions délivrées Excel,pdf ...)

Globalement, il me semble préférable de mettre en place un réel projet de BI, basé sur un réamménagement des ressources matérielles et applicatives.
La mise en place de MySQL ne suffira certainement pas. C'est un des éléments, mais force est de constater que malgré des choix rationnels et économiques, ce projet demandera un investissement certain (ressources humaines , matérielles et logicielles, financières...)