mardi 23 novembre 2010

Les logiciels packagés : la fin d'une époque, vive les applications sur mesure

Je rebondis sur un article publié sur le JDN : http://goo.gl/Ns0Rr
L’âge d’or du tout intégré et du PGI semble plus que jamais toucher à sa fin. En effet, après avoir voulu jouer la carte du packaging tous azimuts, les entreprises se tournent désormais vers une nouvelle approche très fortement axée vers les solutions sur-mesure ....
Cela rejoint complètement ma vision du SI dans les années à venir : il me semble que les processus standards de l'entreprise (RH, Compta, Achats, ...) doivent être couverts par des progiciels « best of breed » (le meilleur progiciel de chaque catégorie) et les processus de production (cœur de métier de l'entreprise) devraient être développés à base de composants spécifiques, pour au moins 2 raisons :
  • les besoins de l'entreprise sur ces processus sont souvent propres à son histoire, son marché, sa culture ... et ses avantages concurrentiels
  • le SI de production doit être un des moteurs de la compétitivité de l'entreprise, de ses avantages concurrentiels, et donc ne pas reposer sur des progiciels standards
De la même manière que nous produisons aujourd'hui des logiciels basés sur des frameworks techniques, il manque dans la production logicielle des frameworks de composants métier, adaptables et spécialisables en fonction de chaque entreprise.
J'ai participé il y a une dizaine d'années (déjà !) à la mise en oeuvre de cette approche avec succès, lorsque je faisais partie de la société Lyon Consultants (fondée par Jean-René Lyon), devenue depuis CGI France. Déjà à l'époque nous utilisions un framework de composants métier, basés sur des outils de développement orienté objets. Cette approche a été mise en oeuvre dans de grands groupes bancaires et d'assurance, mais également dans des entreprises de services (télécoms, distribution eléctricité ou eau).
Il me semble qu'elle représente le juste milieu entre la mise en place généralisée d'ERP dans l'entreprise et le tout spécifique, et permet de bénéficier des avantages respectifs des 2 méthodes :
  • apport d'une structure, d'une certaine rigueur au SI de l'entreprise
  • souplesse d'évolution des développements spécifiques
Le process est le suivant :
  • fabrication d'une ossature de composants génériques propres à un métier (banque, assurance, supply chain, ...), maintenue par un fournisseur externe ou par une équipe d'architecture au sein de la DSI
  • fabrication des composants spécifiques à chaque entreprise, reposant sur le framework métier, par une équipe de développement interne à la DSI ou par un prestataire externe
  • il va sans dire que tous ces composants s'appuient sur un framework de composants techniques, aujourd'hui disponibles sur toutes les plate-formes de développement
Attention de respecter les principes d'indépendance entre ces 3 couches, afin de ne pas fragiliser l'ensemble.

vendredi 19 novembre 2010

Un outil de gestion de projet idéal

Malheureusement, mon outil de gestion de projet idéal n'existe pas, du moins pas à ma connaissance.
Pas mal d'initiatives en ce moment mais rien de complet. Il faut dire que le sujet est complexe et vaste en termes de fonctionnalités.
Cet outil inclurait :
  • un social network (interne à une entreprise ou partagé entre plusieurs entreprises travaillant sur des projets communs)
    => réseau de collègues (amis ?), projets (équivalents aux groupes de discussions), membres de ces projets (avec des rôles : scrum master, développeur, utilisateurs, ...)
  • une gestion de projet scrum :
    • backlogs, sprints
    • charge (jours), budget (€, $), reste à faire
    • plannings + réunions de suivi (problèmes détectés par les membres => résolu ou pas)
    • ....
  • une gestion des demandes (=> incidents ou évolutions)
    le temps passé sur les demandes est bien sûr intégré dans la gestion du projet
    ex : une correction de bug est relié à la tâche dans le backlog et le temps passé à la correction est ajouté sur la tâche
Il aurait bien sûr une interface du type des réseaux sociaux, attrayante, web 2.0
  • inviter des membres, s'abonner à un projet
  • twitter sur les projets
    (+ twits automatiques quand on fait une release ou quand des tâches sont affectées à un membre, ou quand une nouvelle demande est créée)
  • s'abonner aux twits des membres
  • interface pour smartphones
Il fournirait des indicateurs (tableaux et graphiques), interactifs
  • charges et budgets, pour 1 projet, 1 sprint, 1 équipe, ...
  • taux de complétude d'un sprint (tâches prévues dans le backlog vs tâches réalisés, en jours) 
  • taux de résolution d'incidents (incidents déclarés, pris en compte, résolus)

Ajoutez vos idées dans les commentaires et nous pourrions ensuite créer un backlog de cet outil, ...
Et pourquoi pas, le construire ;-)

mardi 16 novembre 2010

De la bonne utilisation de Qlikview

Je rebondis sur un très bon article publié sur le site decideo.fr :
DÉCISIONNEL : VERS DE NOUVEAUX MODÈLES DE CONSTRUCTION

En synthèse, il explique pourquoi les projets décisionnels mettent en place des structures de bases de données dédiées à l'analyse et indépendantes des systèmes de production. Et il préconise à juste titre de créer 2 espaces d'analyse : un espace industrialisé et maîtrisé par la DSI, et un espace (que je qualifierais de "bac à sable") dans lequel les directions métier (les utilisateurs) vont pouvoir manipuler à leur guise les données.
Si on applique ce principe à Qlikview, on peut préconiser de mettre en place un datawarehouse (l'espace industrialisé) sur lequel vont s'appuyer les modèles Qlikview développés pour (ou par) les directions métier.

En plus de respecter les principes ci-dessus (et de fournir aux utilisateurs des données contrôlées, nettoyées, ...), cette manière de procéder possède un avantage majeur : les modèles de données construits dans le datawarehouse sont beaucoup plus simples à comprendre que les modèles de données des systèmes de production et donc facilement maîtrisables par les utilisateurs.
Or, aujourd'hui, les modèles de données construits dans Qlikview et basés sur les modèles de données de production sont incroyablement complexes à maintenir et vont à l'encontre du discours de Qlikview comme quoi il permet de laisser la main aux utilisateurs.

Quand je vois le nombre de sociétés de services proposer des offres verticales s'appuyant directement sur les modèles de données des ERP, je me dis qu'il y a péril en la demeure (pour les DSI et à terme pour les utilisateurs).
Loin de moi l'idée de dénigrer l'outil (Qlikview) qui apporte une bouffée d'air dans un domaine qui s'endormait sur ses lauriers et qui apporte un formidable outil aux utilisateurs, mais c'est plutôt la manière de l'utiliser qui me fait peur.

C'est pourquoi la solution que 6 IT commercialise (http://www.6it.fr/pack-performance.htm) utilise Qlikview comme outil de restitution mais repose sur un modèle de données de type décisionnel (tables de fait et tables de dimension) et des jobs d'alimentation (Talend) incluant contrôle et nettoyage des données.
Cela permet par ailleurs de proposer une alternative à Qlikview - Digdash - en tant qu'outil de dashboarding, basé sur le même modèle de données.

mardi 9 novembre 2010

Le web au secours des développeurs

Avec la montée en puissance des terminaux mobiles (téléphones et tablettes), la multiplication des concurrents (Apple, Google, Microsoft, RIM, Nokia) et des plate-formes techniques (iOS, Android, Windows 7, Windows Phone 7, Blackberry, Bada, webOS), il va devenir de plus en plus compliqué de développer et déployer une application compatible avec l'ensemble des plate-formes.
On va devoir soit sacrifier certaines plate-formes, soit gérer de multiples compétences et outils de développement, ce qui n'est pas à la portée de tous.
Et je ne parle pas des entreprises qui veulent vendre sur internet : elles vont devoir rendre leurs sites compatibles avec l'ensemble de ces plate-formes, avec pour certains des sites conçus pour IE6, autant dire qu'il va tout falloir reconcevoir.

La seule solution viable à mon avis est de développer des applications (ou des sites) à l'aide de frameworks web, c'est-à-dire basés sur les normes HTML, CSS et Javascript les plus avancées et capables de produire des interfaces utilisateur proches des applications dédiées aux plate-formes.
Mis à part les jeux, la majorité des applications disponibles sur les différents "markets" sont à la portée des capacités graphiques de ces frameworks.

Les développeurs du projet jQuery, l'un des frameworks web les plus populaires, ont récemment publié une version, encore en alpha mais prometteuse : http://jquerymobile.com/
L'éditeur américain Sencha publie également un framework web, payant celui-là : http://www.sencha.com/

La convergence et l'amélioration des performances des récentes versions des navigateurs milite également en faveur de cette solution, qui me semble d'avenir ...

Qu'en pensez vous ?