Archive

Archive for the ‘BI thoughts’ Category

BI vs Enterprise Search

October 15th, 2009 No comments

As I’ve spent more time working with ECM (Enterprise Content Management) solutions during the past months, and I still have a strong BI background, I was asked this question today:

Could you give me a quick synopsis of the major benefits one would get from a serious BI application vs a serious Enterprise Search application like Autonomy?

And here is my answer:

At first glance, these two solutions are totally different, yet from an end user standpoint they might look similar.

In a nutshell, a BI solution allows searching, digging and making sense of structured data (i.e. stored in a database of all kind: relational, multidimensional, etc…), and build reports, real time dashboards, etc.

An Enterprise Search solution allows searching and digging unstructured information (mainly text based, from various sources including managed content or external sources such as web pages or even scanned papers).

The interesting part is that a user would like to search something globally, across structured and unstructured data, as the most important part for them is what they search, not where or how it is stored. The segregation between structured and unstructured content is mostly driven by technology although the real need is for these technologies to converge.

The convergence of these two world also comes from growing links between structured and unstructured information, as a big part of what ECM and Enterprise Search solutions are doing is to “structure the unstructured” by adding structured Metadata to unstructured information.

Most of the time though, the BI applications are not yet able to leverage this Metadata, mainly because it’s written in a very proprietary way, not designed for easy reporting but rather for the ECM own performance purposes.

Crystal Reports XI and Open Text BI 8.5.1 pros and cons

April 23rd, 2009 2 comments

I’ll revise this post regularly based on my findings and experience.

Items in this list may only show my inability to perform a specific action with one solution, which at least means that there is a usability issue with it 🙂

Crystal Reports XI:

  • + Formula Editor
  • – No permanent data model: a new data model needs to be recreated each time I create a new report
  • – No ability to work on results and combine them together
  • No ability to aggregate on the server: I didn’t find for instance how to create the following statement: With the help of Paul’s comment, I was able to find how this works in Crystal: you need to turn the “Perfrom Grouping on Server”  option for both the report AND the general option. [cc lang=”sql”]select count(my_field) from my_table[/cc]

Open Text BI 8.5.1:

  • – Doesn’t support multiple outer joins with SQL ODBC connection
  • – Can’t report on a table named “users”  with SQL ODBC
  • + Can work with results and create complex “super queries”
Categories: BI thoughts, Tech tips Tags:

Poser les bonnes questions

February 6th, 2009 No comments
  • english
  • french

Faisant suite Ă  l’article sur une stratĂ©gie pragmatique, voici une liste non exhaustive de questions que l’on peut se poser durant la phase de planification d’un projet BI :

1 – Identifier les besoins des utilisateurs :

  • Quel est le mĂ©tier des utilisateurs, et quel est dans quel but ont-ils besoin d’obtenir des rapports ?
  • Quelles sortes de rapports sont nĂ©cessaires :
    • Aide dĂ©cisionnelle ?
    • Gestion de la performance ?
    • Tableaux de bords et indicateurs ?
    • Rapports sur les clients, financiers ?
    • Analyse des systèmes ?
    • Gestion de la qualitĂ© des donnĂ©es ?
    • Outil de gestion de rapports pour l’entreprise ?
    • Data Warehousing ?
    • Gestion des donnĂ©es globale ?
    • Analyses prĂ©visionnelles ?
  • Les besoins sont-ils localisĂ©s Ă  une Ă©quipe, ou plus gĂ©nĂ©raux ?
  • Les besoins sont-ils reproductibles ou les rapports seront crĂ©es Ă  la demande ?
  • Comment seront utilisĂ©s les rapports :
    • InsĂ©rĂ©s et lus dans un autre document ?
    • ImprimĂ©s et archivĂ©s pour conserver l’historique ?
    • Accessibles en ligne (Intranet ou Extranet) ?
    • Accessibles Ă  partir d’un appareil mobile ?
    • PrĂ©sentĂ©s lors d’une projection Ă  une assemblĂ©e ou dans un livre ?
    • ExĂ©cutĂ©s lors d’une planification pĂ©riodique ou en fonction d’Ă©vĂ©nements ?
    • Un mĂ©lange des options ci-dessus ?
  • Combien de temps doit-on conserver les rapports, est-ce que diffĂ©rentes versions doivent ĂŞtre conservĂ©es dans le temps ?
  • Est-il possible de dĂ©finir prĂ©cisĂ©ment chaque rapport ou groupe de rapports :
    • Quel est le but de ce rapport ?
    • Quels sont les indicateurs de ce rapport ?
    • Comment doit-on trier, classer, filtrer le rapport ?
    • Quel format devrait avoir ce rapport : tableau, graphique, tableau croisĂ©, un mĂ©lange ?
    • Doit-on inclure des calculs, mettre en avant certaines valeurs ? Quelles sont les règles Ă  appliquer dans ces cas ?
    • Quels sont les critères de sĂ©lection et filtre du rapport ? Est-ce que ces critères sont les mĂŞme pour tous les rapports ? A quel moment l’utilisateur peut choisir ces critères ?
  • Qui a accès aux rapports, qui a besoin de ceux-ci ?

2 – Quelles sont les contraintes techniques ?

  • Quel est le budget du projet BI ?
  • Quelle est la durĂ©e de ce projet ?
  • Quelles règles de sĂ©curitĂ© s’appliquent au contenu des rapports ou au système utilisĂ© pour y accĂ©der, et comment cette sĂ©curitĂ© est-elle implĂ©mentĂ©e : au niveau du système, des bases de donnĂ©es, des rapports ?
  • Ou se trouvent les donnĂ©es ?
    • Sont-elles accessible facilement ?
    • Existe-il un environnement de test ?
    • Est-ce que les rapports doivent contenir des informations en provenance de plusieurs sources de donnĂ©es ?
    • Est-ce que certaines informations nĂ©cessaires pour la crĂ©ation des rapports ne se trouvent pas dans une base de donnĂ©es ?
    • Est-ce que certains informations sont enregistrĂ©es dans des systèmes propriĂ©taires (ERP, etc…) ?
  • Quel est la qualitĂ© des donnĂ©es ? Est-ce que les donnĂ©es nĂ©cessitent un “nettoyage” prĂ©alable ?
  • Est-ce que les donnĂ©es sont conçues pour la crĂ©ation de rapports, ou est-ce qu’une transformation, prĂ©paration et transfert prĂ©alable est nĂ©cessaire et possible ?
  • Est-ce que le système opĂ©rationel est accessible, ou les donnĂ©es doivent ĂŞtre dupliquĂ©es ? A quelle frĂ©quence cette information devrait ĂŞtre mise Ă  jour ? Il y a-t-il des contraintes relatives Ă  l’accès au système opĂ©rationel ?
  • MetadonnĂ©es : sont-elles dĂ©finies, nĂ©cessaires, accessibles ?
  • Il y-a-il des informations “non structurĂ©es” Ă  prendre en compte ?
  • Il y-a-t-il une charte graphique Ă  suivre pour la mise en page des rapports (pour diffĂ©rents formats : portrait, paysage, rapports en ligne) ?
  • Il y-a-t-il des contraintes technique pour la plate-forme matĂ©rielle, le système d’exploitation (client et serveur), les navigateurs web, les bases de donnĂ©es, le rĂ©seau, la sĂ©curitĂ©, les comptes d’accès aux systèmes, les caractĂ©risques physiques des ordinateurs (RAM, CPU, etc…) ?
  • En quelles langues doivent-ĂŞtre disponible les rapports ?
  • Il y-a-t-il une formation prĂ©vue et plannifiĂ©e ?
  • Il y-a-t-il d’autres projets existants qui soient similaires Ă  ce projet, sur lesquels on peut s’inspirer afin de s’amĂ©liorer ?

question_mark

Categories: BI thoughts Tags:

Une stratégie BI pragmatique

January 21st, 2009 No comments
  • english
  • french

Planifier, implĂ©menter et maintenir un projet BI n’est pas simple.
Depuis le dĂ©but des projets dĂ©cisionnels et de “Data Warehouse” il y a 20 ans, un conseil très simple a toujours Ă©tĂ© le plus important : utiliser la règle du 80 – 20 pour la gestion du temps du projet :
80% du temps consacré au projet devrait être passé à comprendre les besoins des utilisateurs pour définir le projet, et les 20% restant devraient être alloués pour réaliser le projet.
Les Ă©checs lors de projets BI sont le plus souvent dus Ă  la rĂ©alisation d’un superbe (et coĂ»teux) outil qui ne rĂ©sous pas rĂ©ellement les attentes des utilisateurs, ce qui finalement augmente la charge de travail des utilisateurs plutĂ´t que de les aider dans leur prises de dĂ©cisions, et n’est donc pas utilisĂ©.

Et lorsque nous parlons de “besoins” ce sont les besoins rĂ©els et non pas une liste de souhaits :

Si vous demandez Ă  quelqu’un quelle voiture il souhaite possĂ©der, il vous dĂ©crira sĂ»rement la voiture de ses rĂŞves, une voiture qu’il ne possĂ©dera sans doute jamais ! Mais si vous demandez Ă  cette mĂŞme personne quelle voiture il a rĂ©ellement besoin, la voiture de rĂŞve disparaĂ®tra au profit d’un vĂ©hicule pratique, avec 4 roues, un moteur et des sièges pour toute la famille !

La mĂŞme règle s’applique aux projets BI lors de la phase de dĂ©finition. Certains utilisateurs dĂ©sirent un outil BI de rĂŞve qui sache prendre les dĂ©cisions importantes Ă  leur place de façon magique, en rĂ©conciliant automatiquement des informations hĂ©tĂ©rogènes venues de tous les horizons.
Mais leurs besoins rĂ©els ne sont peut ĂŞtre pas si extraordinaires que ça, et quelques indicateurs simples et un accès facile Ă  l’information dans les bases de donnĂ©es, avec la certitude que cette information est juste, est souvent tout ce que les utilisateurs recherchent.
C’est ce que les bons projets BI devraient fournir.

Categories: BI thoughts Tags: