Comme beaucoup de professionnels de mon secteur, je suis convaincu de l’intérêt de l’urbanisation du système d’information.

L’urbanisation, par le niveau de compréhension qui en ressort, est une formidable source d’information permettant de prendre des décisions éclairées et de voir le véritable lien entre le métier de l’entreprise et son système d’information.

La direction de l’entreprise s’en trouve simplifiée et les décisions métiers et IT gagnent en synergie.

La complexité des systèmes d’information est à un niveau jamais atteint, cela rend plus simple la prise de décision.

Cependant dans les projets, sur le terrain et loin des conférences et autres symposiums, les résultats obtenus sont souvent décevants.

Je vais m’attacher au lien entre le projet d’urbanisation et le projet IT de refonte ou de développement dans le système d’information de l’entreprise.

Les difficultés rencontrées :

Tout d’abord chaque projet IT doit affronter les chefs de silo (CDS). Les chefs de silo interviennent pour garantir que leur secteur (ou leur territoire) ne sera pas réduit par le projet. Que l’organisation soit notablement sous forme de silo ou non ne change pas grand chose car dans le fond, les chefs de silo trouvent toujours un moyen de recréer une organisation par silo.

Il faudra donc composer avec eux et surtout arriver à faire collaborer ces chefs entre eux. C’est d’ailleurs en bonne partie pour cela que la recommandation dans tout projet d’urbanisation est que le haut management soit acteur : pour « forcer » les chefs de silo à travailler entre eux.

Ensuite, le projet devra affronter la résistance de nombreux intervenants dont la liste n’est pas très réjouissante.

Le projet d’urbanisation peinera à atteindre des résultats satisfaisants à cause des entraves précédemment listées : les intervenants terrain ne croient pas au projet et n’en attendent rien. La conséquence logique est que l’investissement consenti pour le projet ne donnera pas de bons résultats.

Inévitablement, le projet IT qui en découle sera comme la majorité des projets IT non encadrés : il comportera trop de fonctionnalités qui ne seront basées sur aucun besoin métier et coûtera donc trop cher.

Bien sûr, le projet sera trop gros avec un planning intenable. Cerise sur le gâteau, les indicateurs permettant de mesurer la qualité du projet et sa contribution aux résultats de l’entreprise ne seront pas définis et donc non mesurés ce qui poussera l’équipe projet à livrer à tout prix sans s’attacher aux détails de la livraison (le lien vers la nouvelle application dans l’intranet suffi pour apporter satisfaction non ?).

Comment faire ?

Si l’urbanisation n’est pas la méthode miracle pour faire des projets IT une absolue réussite, sa rigueur permettra surtout de s’attacher aux résultats qu’attends l’entreprise : un changement positif qui apporte une amélioration métier.

La réalité des projets d’urbanisation n’est en fait pas très différente de celle des projets IT. Si le projet d’urbanisation doit apporter un éclairage pratique et fixer les limites des projets IT, il souffre des mêmes contraintes pour une seule raison : il évolue dans le même milieu.

Le milieu est grandement influencé par la manière dont les équipes collaborent et je pense que le type de collaboration entre projets et urbanistes est déterminant.

Il existe différentes manières d’intégrer l’urbanisation aux projets IT.

Les urbanistes sont souvent une entité isolée qui intervient sur les projets à la demande. La plupart du temps ils sont dans leur tour d’ivoire bureau et travaillent en parallèle des projets IT en essayant de produire le plus gros modèle du monde. Selon le niveau d’autorité qui leur ai accordé, ils peuvent opposer un véto au projet si jamais celui-ci ne respectait pas les pré-requis nécessaires pour garder un SI urbanisé.

On les trouve parfois dans l’équipe des business analyst qui décrit les processus métier à mettre en place. Ils bénéficient d’une place de choix puisqu’ils peuvent faire remonter les parties du SI susceptibles de couvrir les besoins métiers étudiés et ainsi concrétiser un mot sacré la réutilisation. Souvent, il s’agit d’une personne détachée de l’équipe d’urbanistes.

Parfois, ils ne sont pas tout à fait identifié et leur intervention sur les projets est mal vue. Ils restent en marge et se contentent de documenter ce qui se passe et d’emettre des « notes de recommandation »…

Je suis intimement convaincu que la position de l’urbaniste doit être dans les projets. C’est là où l’urbaniste prend sa casquette d’archiecte applicatif (si ce rôle n’existe pas) pour aider les projets à s’intégrer au SI. C’est là où le travail de cartographie apporte de la valeur et délivre son potentiel. Il n’en reste pas moins que la nature des projets IT est très diverse et cela rend toujours un peu difficile de coller à une organisation type. Cependant, posez-vous la question : est-ce que mes urbanistes contribuent aux projets IT ? Est-ce que le référentiel des applications (CMDB ou pas) est mis à contribution ? Est-ce que tous les outils à notre disposition sont utilisés pour encadrer le projet ?

Popularity: 20% [?]

Aujourd’hui, je voudrais partager une astuce que j’utilise dans les projets sur lesquels j’interviens.

Souvent, particulièrement lorsqu’il s’agit de discussions à l’oral, nous avons tendance à comparer des solutions techniques les unes aux autres de manière détachée.

Par exemple, pourquoi choisir SAP plutôt qu’Oracle sur la partie RH du système d’information ?

Pour éviter ce biais, le meilleur moyen actuellement disponible reste de décrire processus métier, les fonctions attendues du système d’information et de croiser l’ensemble pour déterminer la couverture fonctionnelle que devra avoir la solution technique. En somme, il s’agit de définir une architecture d’entreprise digne de ce nom !

Seulement il reste un critère intéressant à considérer : celui de la dette.

En effet, dans les projets informatiques, les décisions sont souvent prises par des personnes qui ne demeureront pas aussi longtemps que les solutions techniques mises en place. (Je généralise un peu pour des raisons demonstratives) et il est important de considérer la dette que créé un choix technique.

Comment évaluer cette dette ?

S’il sera difficile de donner un coût précis à cette dette, il sera plus évident de donner la potentialité et la gravité de son occurrence selon un découpage que l’on pourrait utiliser pour décrire… un risque (potentialité, conséquence).

L’idée est simple et similaire à notre système de retraite : chaque décision aujourd’hui entraine potentiellement une dette pour les générations futures. Dans le contexte du SI de l’entreprise, il est intéressant de prendre en compte la road map (si elle existe) ou à minima les évolutions métiers. Dans ces évolutions, il sera autant question des évolutions sur lesquelles l’entreprise a peut-être déjà du retard que des évolutions supposées du domaine et dont les analyses sont disponibles auprès d’organismes de recherche.

Ces évolutions nécessiteront des changements dans le système d’information et ces changements seront rendus plus ou moins faciles selon les choix effectués.

Tout cela est un peu prospectif mais cela devient une composante intéressante dans les analyses amont des solutions techniques : la stratégie de sortie.

Gardons les choses simples :

Si par hasard il y a de fortes présomptions sur la potentialité et sur la gravité (très probable + grave = analyse plus précise) de la création d’une dette, alors la solution applicative doit être analysée plus en détail. La décision, si elle est confirmée, sera alors prise de manière éclairée.

La dette peu aussi être considérée sur l’angle « coût de maintenance » dont on sait que cela a longtemps été un coût négligé alors que très important. Beaucoup d’informations sont maintenant disponibles à ce sujet et si chaque cas est particulier, cela reste un élément à prendre en compte.

Popularity: 5% [?]

J’ai découvert il y a quelques mois le PeaF qui signifie Pragmatic Enterprise Architecture Framework. (Enterprise Architecture = Urbanisation du SI)

C’est une initiative intéressante de Kevin Lee Smith, un « professionnel de la profession » avec 28 années d’expériences dans le domaine. Après avoir élaboré ce framework pendant des années, il a décidé de le publier en Novembre 2008.

Ce framework se veut résolument pragmatique (approche que l’on retrouve d’ailleurs dans l’approche Praxeme) et sans artifices.

PeaF vient se rajouter à la longue liste des frameworks déjà existants :

• TOGAF,
• Zachnman,
• TEAF
• E2AF,
• MoDAF / DoDAF
• IAF.

S’il y a un document à consulter pour avoir un aperçu de cette méthode, c’est celui-ci et aussi celui-ci.

Vous verrez que l’auteur a pris le soin de modéliser sa propre méthode, ce qui pour un architecte est la moindre des choses

Je souscris à l’approche générale et qu’une méthode comme celle-ci gagne à être diffusée, c’est pourquoi j’ai une licence qui m’a été délivré.

Les domaines

Model : l’ensemble des modèles, du méta-modèle et des outils qui constituent le cœur d’une démarche d’urbanisation du SI.

Governance : processus et principes qui permettent de garantir la qualité des travaux d’urbanisation (notamment le respect de la convention de modélisation qui est si difficile et la gestion du cycle de vie).

Foundation : la vision, l’analyse des risques et le niveau de maturité de l’organisation.

Management : définition d’indicateurs pour mesurer l’état et la contribution de l’urbanisation à l’entreprise et processus de planification des évolutions et des tâches d’urbanisation.

Communication : processus d’évangélisation autour de l’urbanisation et du framework. La communication est souvent le point noir des projets d’urbanisation ou de modélisation de processus métier.

Si une entreprise entame une démarche, ces documents sont une véritable mine d’or à condition d’en comprendre la finalité.

Ce qui est intéressant, ce que PeaF se défini également par rapport aux autres framework. Ainsi, il se veut plus concret que Zachmann qui est plutôt un méta-modèle et plus compréhensible que TOGAF dont la courbe d’apprentissage est énorme (700 pages).

Guide pour analyser un outil de modélisation qui contient une liste des caractéristiques à regarder ainsi qu’un classement de la plupart des éditeurs de solutions BPA/BPM.

Une initiative à suivre !

Popularity: 11% [?]

Le défaut de l’ingénieur et en particulier du développeur est plus répandu qu’on le souhaiterait. Mais en fait, lorsque je dis LE défaut, il conviendrait de dire LES défauts.

Parmi les écueils les plus courants, on trouve le fait de vouloir réaliser une fonction pour le défi technologique qu’elle représente et non pas pour répondre au besoin ou encore le fait de penser à son CV avant de répondre à la problématique.

Tout ceci est classique. Si vous êtes architecte logiciel, vous le savez déjà et si vous êtes chef d’équipe ou client vous le savez encore mieux

Je suis tombé sur un livre qui recense tous ces défauts. Plus qu’une collection, c’est un inventaire que je trouve exhaustif (pensez bien qu’il y a tout de même 97 défauts!) qui permettra de mieux comprendre les architectes logiciels.

Le livre est disponible sur Amazon mais il est possible de consulter gratuitement le Wiki sur lequel se trouvent une partie du contenu dont voici un extrait :

We often design over-engineered applications as a result of blindly pleasing customers to the greatest extent. We are so distracted by the details of the solutions that we offer, that we sometimes fail to see that we end up solving the wrong problems in the first place.

So here is a little suggestion: don’t just translate customer requirements into code, but strive to be a wise interpreter. In other words: design for needs, not wants.

You should challenge requirement definitions as, almost invariably, customers poorly define and understand their own actual needs.

All too often, they say they want a longer antenna when, in fact, they need a better reception. You should ask simple questions such as « why do you want this feature? » and « what is its benefit? » and you should keep inquiring until you obtain an adequate answer.

Once you have identified the underlying needs, you have the opportunity to look for alternative solutions. Don’t stop at the first good idea and don’t blindly trust your first instincts. As the French philosopher Alain (Émile Chartier) once said: « Nothing is more dangerous than an idea when it’s the only one you have. » Deliberately ask questions such as « this is a way of doing what? » and « how else can this be achieved? »

Incidentally, this is your best chance to reduce complexity in your applications: right at the source, where it matters most. Simple and elegant solutions are often incredibly hard to find and may not be there at all. But do not to give up too quickly, as you may miss tremendous opportunities.

by Claudio Perrone

Vous trouverez aussi des citations de nombreux professionnels :

• Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar)
• Chances Are, Your Biggest Problem Isn’t Technical (Mark Ramm)
• Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
• Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
• For the End User, the Interface Is the System (Vinayak Hegde)
• It’s Never Too Early to Think About Performance (Rebecca Parsons)

Si vous connaissez un architecte logiciel ou un développeur ce livre doit être en bonne place dans votre prochaine commande !

Si je parle de ceci sur un blog à priori dédié à la modélisation des processus métier et à l’urbanisation du SI, c’est que je pense que les business analyst et les urbanistes du SI ont de nombreux défauts en commun avec les développeurs… et je sais de quoi je parle !

Pour le commander :

Popularity: 4% [?]

Voilà une grande question que se pose des milliers de personnes chaque jour lorsqu’elles essaient de convaincre d’investir dans un projet informatique.

Pourtant, loin des grandes théories économiques, le système d’information est une dépense de plus en plus lourde pour l’entreprise.

Signe des temps, les investissements consacrés augmentent avec l’omniprésence de l’ordinateur. Faut-il s’en inquiéter ?

Pourquoi est-ce difficile de démontrer le ROI du système d’information ?

Poser la bonne question, c’est déjà résoudre une partie du problème. Pourquoi est-ce si compliqué d’expliquer ce que va apporter le système d’information à l’entreprise ?

Mon avis sur la question est simple : vous ne pouvez pas analyser quelque chose que vous ne mesurez pas.

C’est bien ce que racontait Peter Drucker : What gets measured gets managed.

Je suis convaincu que dans la plupart des entreprises les indicateurs n’ont pas été identifié et que par conséquent peu de gens sont capables de montrer le ROI d’un projet SI.

Avoir les bons indicateurs

Une fois que l’on a dit ceci, il faut se concentrer sur un autre point : quels sont les indicateurs ?

Je pense que certaines personnes croient encore qu’un système d’information doit justifier de son coût par rapport à l’évolution du chiffre d’affaires. Ce serait croire que l’environnement n’évolue pas et que l’informatique possède la même place qu’il y a 20 ans.

Alors si les projets informatiques sont une dépense nécessaire, il n’est pas pour autant question de ne pas mesurer ce qu’elle apporte. L’informatique est parfois moteur et parfois un coût.

Vous ne pouvez pas mesure la vitesse d’une voiture en fonction de la température extérieure. C’est pourtant ce que demande parfois des dirigeants à leurs équipes : « Montrer moi que 100 000€ d’investis feront augmenter la température » : Cela fera surtout chauffer l’atmosphère lorsque personne ne sera capable d’expliquer que le résultat attendu ne se produit pas. Si les indicateurs ne sont pas bons, le résultat ne le sera pas.

Le problème des SI, c’est qu’ils figurent autant comme système support dont on ne peux se passer (toute la maintenance applicative), que comme outil stratégique (nouveau projet) ou encore que comme levier de réduction des coûts (remplacement du personnel par des bornes, ouverture d’espace en ligne…).

Balanced Score Card du SI

Et les méthodes de mesure ne manquent pas. Tout dépend du type de projet. Les KPI doivent être alignés pour mesurer le résultat attendu. Voici quelques idées simples :

• Contribution à la réussite des objectifs stratégiques métier
• Contribution à la réussite des objectifs SI
• Contribution à la conformité SI
• Contribution à la gouvernance d’entreprise
• Contribution à la conformité réglementaire
• Contribution à l’amélioration des processus métier
• Contribution à la croissance de l’entreprise
• Contribution à l’augmentation de la marge
• Contribution à la réduction des coûts

Choisissez les vôtres !

Popularity: 1% [?]

Dans les projets de modélisation de processus ou d’urbanisation du système d’information, l’une des questions qui sera inévitablement abordées est celle des objets métiers.

De notion informatique…

Le terme d’objet métier est connoté « informatique » puisqu’on le retrouve dans plusieurs langages de développement dont notamment Java.

L’objet métier est très proche de ce qu’est une classe java (en théorie). Il s’agit simplement de regrouper des idées similaires et de définir ce qui se trouve à l’intérieur.

Typiquement, l’objet client contient tous les éléments qui permettent de décrire un client : nom, prénom, date de naissance…

L’objet métier est un concept et il est toujours un peu difficile à définir précisément (à l’agacement de certains clients!).

Cependant ce n’est pas non plus n’importe quoi ; il s’agit de suive une logique identique pour l’ensemble du découpage sans quoi la modélisation n’aura plus de sens.

…à concept métier

L’objet métier désigne un concept ayant une réalité pour le métier de l’entreprise. Pour les connaisseurs, cela est très similaire des entités de Merise mais avec une souplesse plus importante puisque leur finalité directe n’est pas d’être transformé en tables de base de données.

Un élément clé de tout référentiel métier

L’objet métier est la notion pivot par excellence entre les processus métier et le système d’information. Certain voit le processus métier comme une machine à état venant changer l’état de quelques objets métiers et le système d’information comme un ensemble de fonctions manipulant des objets métiers.

Ainsi, le processus de traitement d’une commande client viendra lire l’objet métier Client et Facture pour mettre à jour l’objet métier Commande à la fin du traitement et le système d’information associé viendra lui offrir toutes les fonctions nécessaires.

L’objet métier comme pivot est une vision pratique pour créer un modèle pertinent.

Une méthode simple

Pour modéliser des objets métiers il « suffit » de discuter avec les personnes du métier.

Selon les projets et les organisations cela peut faire intervenir tout un ensemble d’acteurs différents : de MOE à MOA en passant par les urbanistes. Cela va dépendre du projet mais les qualités requises sont :

- comprendre le métier

- savoir faire abstraction des choses

- compétences de modélisation

Il s’agit de confier cette tâche à une personne étant à mi-chemin entre la tribu des « informaticiens » et celle des « gens du métier » : un interprète qui fera en sorte que ces 2 mondes se comprennent.

Le début de tout projet ?

Selon la méthode de modélisation, les objets métiers vont apparaitre à plus ou moins long terme.

Dans les projets plutôt orienté urbanisation, ils auront tendance à apparaitre plus tôt alors que dans les projets processus, ils ne sont parfois même pas abordés.

Par exemple la méthode Praxeme met plutôt en avant l’approche « objet métier d’abord ».

Personnellement, c’est une approche que j’aime bien car elle clarifie le périmètre. A partir d’une carte d’objet métier de haut niveau, on pourra en déduire des processus mais aussi les principaux systèmes d’information de l’entreprise (un SI pour la relation client, un pour la gestion des commandes….)

Les cartes d’objet métier m’ont souvent aidé à discuter avec les personnes du métier des cas d’utilisation. Il est très facile de montrer un modèle et de poser une question sur la relation entre 2 objets : possible ou non, dans quelles conditions…

Merci à Pascal pour la suggestion du sujet !

Popularity: 100% [?]