Praxeme : à propos de la méthode publique

Soigner la sous-France

La méthodologie se met au service de l'entreprise, donc de la société.

Certes, dans sa composante "méthode", c'est une technique, mais comme toute technique, son application la projette dans la réalité humaine, sociale, politique. Qui plus est, la méthodologie déborde de la technique et comporte une dimension réflexive et nécessairement philosophique. Pour élaborer la méthode, il est nécessaire de prendre la distance suffisante pour découvrir tout le système des interactions, conditionnements, déterminations. Dans cette dimension, la méthodologie rencontre obligatoirement les préoccupations que nous partageons tous quant à la société et à l'avenir.

Illustration :

<<<

Madame, Monsieur,

Je suis actuellement en contentieux avec votre entreprise. Mais ce n’est pas en tant que client que je m’adresse à vous. Je laisse cette affaire, décrite dans le courrier joint en annexe, suivre son cours, et j’attends, avec curiosité, la suite qui lui sera donnée.

Je me permets de vous interpeller en mes qualités de citoyen et de consultant.

En tant que citoyen, je déplore les dysfonctionnements si fréquents dont souffrent nos entreprises et nos administrations : non seulement ils obèrent une économie déjà bien mal en point, mais aussi ils révèlent un état d’esprit et une incapacité collective qui nous entraînent doucement et irrémédiablement dans une sous-France. Je m’en désole pour mes enfants, amenés à vivre dans une société qui s’est privée de toutes ses chances d’adaptation et d’évolution.

En tant que consultant, rompu aux techniques de modélisation et de conception des organisations, je ne résiste pas à l’impulsion de vous proposer un audit de vos processus. Il me semble que des améliorations rapides peuvent être mises en place. J’en donne pour preuves trois exemples :

·        Il a fallu 21 jours entre notre commande et la première réception.

·        Un courrier de notre part à destination du Service Client, posté le 2 janvier, est resté sans réponse pendant presque un mois.

·        Entre l’édition d’un courrier du Service Relation Clientèle et le compostage de l’enveloppe, il s’est écoulé dix jours.

Ces métriques révèlent des ratés qui, hélas, ne sont pas exceptionnels. Plusieurs de mes amis s’en plaignent et nous en venons à commander plus facilement sur des sites anglo-saxons plutôt qu’auprès de marques qui, pourtant, disposaient d’un grand capital de sympathie. Cette tendance du marché ne cessera de se renforcer, au détriment de nos économies.

Nous devons réagir. L’adaptation doit se concevoir tant dans la culture de service qu’au niveau du détail opérationnel.

Me tenant à votre disposition pour approfondir ce sujet, je vous prie de croire, Madame, Monsieur, en l’expression de ma considération distinguée.

>>>

Je vous invite à adresser de tels courriers (peut-être moins arrogants et moins présomptueux) aux directions des entreprises avec lesquels vous rencontrez des problèmes. Faites-nous savoir :

1. si on vous répond ;

2. le cas échéant, le délai et la qualité de la réponse.

L'idée est de lancer une campagne de sensibilisation sur ces questions. Les éléments concrets d'observation permettront :

• d'établir un benchmarking (notamment en comparant le comportement de nos entreprises avec celui observé à l'étranger) ;

• de renforcer et d'illustrer certains des procédés de la méthode Praxeme.

Campagne "Soigner la sous-France"

Une synthèse pour les décideurs

Praxeme est une méthodologie d'entreprise.

Elle intéresse, au premier chef, les dirigeants d'entreprise, DG, directeurs... qui y trouveront l'instrument pour une meilleure lisibilité des compétences et pour articuler les expertises que la transformation des entreprises requiert.

Voici une synthèse de  direction qui s'adresse aux décideurs et leur présente le cadre de référence offert par la méthode publique Praxeme.

Télécharger SLB10-synthese.pdf (283.5K)

Stratégie

La stratégie n’est pas un aspect à part dans la Topologie du Système.

C’est tout à fait volontaire (cf. le Guide général).

Une stratégie rassemble des décisions ordonnées et dirigées par rapport à un petit nombre de finalités (trop souvent, une seule).

Ces décisions, selon leur nature, peuvent se distribuer sur tous les aspects du système.

C’est donc en fonction de la nature de la décision stratégique, nature qui la situe dans la topologie, que l’urbaniste pourra analyser son impact sur les modèles et le système. Pour aider cette analyse, la méthode propose une typologie des choix stratégiques.

Malaise dans la modélisation

Les entreprises sont confrontées à un sacré problème !

Pour décider en toute rationalité, les dirigeants ont besoin de représentations précises de la réalité de l’entreprise.

En l’absence de cette connaissance, la décision ne repose que sur l’intuition, la perception synthétique que peut se faire l’individu. Dans cette perception se glissent beaucoup d’idées préconçues.

Les représentations rigoureuses qui pourront éclairer la décision, nous les nommons des modèles. Quand il s’agit de stratégie, d’organisation, de gestion des compétences… les modèles sont ceux définis par Praxeme comme modèles « amont ». Si nous évoquons la gouvernance de SI, l’automatisation des tâches, l’ouverture vers des partenaires, alors nous nous intéressons aux modèles du système informatique.

Revenons aux modèles « métier » (ou « amont ») ! Les propriétaires naturels de ces modèles sont les directions « métier ». Elles possèdent l’expertise. Ces modèles ont pour but de formaliser et capitaliser cette expertise. Les modèles permettent, d’abord, de préserver le savoir, ensuite, de faire comprendre, aux informaticiens, ce savoir et les besoins qui en découlent.

Si le propriétaire du modèle « métier » est la direction métier en tant que maître d’ouvrage, a-t-elle la compétence pour l’élaborer ? En plus de la connaissance fonctionnelle, il y faut une compétence formelle, celle du modélisateur. Généralement, on ne trouve pas cette compétence dans les directions « métier ». Quand elle existe, la direction de l’organisation peut fournir une partie seulement des procédés de modélisation, ceux portant sur les processus.

Dans cette situation, pour élaborer les modèles « métier », on va chercher les compétences de modélisation là où elles ont à peu près survécu : la direction informatique. Il se trouve que la nécessité de représenter les logiciels a conduit à maintenir, plus ou moins, quelques pratiques de modélisation. Le mot clef « UML » permet d’étiqueter ces pratiques et de légitimer les dessins.

Ainsi, la modélisation « métier » est souvent confiée à des informaticiens. Ce phénomène n’est pas neutre : il introduit un biais dans la représentation. Les modèles sont, au mieux, plus compliqués que nécessaires, au pire, dénaturés par des préoccupations techniques qui n’ont rien à voir avec le métier.

Par exemple, dans une expérience récente, là où l’acteur métier voir un événement, l’informaticien perçoit un throw et un catch et ajoute deux symboles sur le dessin des processus. Il justifie cette complication en évoquant le BAM ou tout autre solution technique qui permettra d’outiller le processus. Il a raison dans son champ de compétence. Le problème est qu’il transporte ses préoccupations dans un domaine qui n’est pas le sien.

Les entreprises se retrouvent ainsi avec des modèles de leur métier, inutilement compliqués. Pire, sous ces complications, l’essentiel a été brouillé, voire perdu et on a bien du mal à appuyer sur ces modèles une réflexion pour améliorer les pratiques.

C’est le malaise dans la modélisation – pour paraphraser un titre de Sigmund Freud (« Malaise dans la civilisation »).

Le remède à la régression des compétences de modélisation passe par la formation, on s’en doute. Mais un pré-requis est l’adoption d’une méthode de modélisation rigoureuse et la clarification des compétences. Praxeme apporte la cartographie des compétences. Celle-ci permet, au moins, de remettre chaque expertise à sa place.

Évidemment, l’état général de la culture ne joue pas en faveur de la restauration des compétences de modélisation. Comment produire de bons modèles quand on ne maîtrise qu’imparfaitement le premier outil de modélisation à notre disposition : le langage ? Des études récentes montrent un effondrement des compétences fondamentales, grammaire et orthographe (voir, par exemple, un rapport récent "Rapport de mission sur l'enseignement de la grammaire", par Alain Bentolila, en collaboration avec Dominique Desmarchelier et Erick Orsenna). Nous en voyons les signes, depuis longtemps, dans l’entreprise.

Cette situation rendra de plus en plus difficiles le recrutement et la formation des véritables modélisateurs dont les entreprises ont besoin.

L'aspect géographique

Un nouveau guide à disposition : le Guide de l'aspect géographique (PxM-30).

Comme les précédents (PxM-10 et PxM-20), il s'agit d'un guide méthodologique, c'est-à-dire de l'exposé raisonné de la méthode. Il est plus destiné à des méthodologues ou des experts en modélisation désireux de s'approprier la logique interne, plutôt qu'à la majorité des praticiens. Pour ceux-ci, il sera nécessaire de rédiger des guides méthodes ou des fiches pratiques.

A eux trois, ces guides fournissent les clefs pour les procédés de modélisation "amont" ou "métier". Des travaux sont en cours pour terminer le guide de l'aspect logique. Celui-ci expose les procédés d'architecture logique et de conception logique, dans le style SOA.

Télécharger PxM30-gGq.zip (784.0K)

Les autres guides ont été présentés au fil de leur publication. Vous pouvez y accéder par la liste des documents, située à gauche de cette page.

Cadrage méthodologique pour l'Armée de Terre

Depuis plusieurs années, l’Armée de Terre forme ses informaticiens au langage UML. La section Méthodes-Qualité du Bureau Architecture et Études (BAE) accompagne ce mouvement, en assurant un monitorat auprès des projets. Elle a, également, investi sur un monitorat dont le titre dit bien l’intention : « UML, mode d’emploi ». Ce monitorat présuppose la connaissance d’UML, connaissance superficielle acquise dans les présentations classiques. Au-delà de ce premier niveau, elle pose les questions de pratique : quels sont les modèles à produire ? Comment choisir les diagrammes ? Qu’est-ce qu’un « bon » modèle ? Comment traiter les règles de gestion ? Etc.

Ces efforts portent sur la modélisation, technique de représentation indispensable à la formulation du besoin, à la compréhension entre les différents acteurs des projets et à la conception de la solution. Dans les termes de Praxeme, ceci concerne deux des dimensions de la méthodologie : le Produit (définition des modèles et des critères d’acceptation) et les Procédés (modes opératoires). Les projets rencontrent d’autres difficultés, situées dans la dimension Processus : organisation des travaux, définition des profils et responsabilités, démarche, phasage, maîtrise des itérations, relations avec la maîtrise d’ouvrage, insertion dans le plan d’urbanisation et la politique informatique…

Sur ces sujets, l’Armée de Terre s’appuyait, depuis les années 80, sur un corpus méthodologique qui a rendu de fiers services : la méthode SMD/S. Comme dans d’autres administrations et dans beaucoup de grands comptes du secteur privé, cette méthodologie a fourni les bases de la conduite des projets. Au fil des ans, sa pratique s’est cependant effacée. Elle subsiste mais se heurte à des difficultés liées aux nouvelles conditions des projets : importance des aspects techniques, itérations, évolution des pratiques de modélisation, nouvelle situation dans la gestion des compétences…

Aujourd’hui, une des références pour le processus de développement logiciel est le « processus unifié » (UP pour Unified Process), conçu dans la mouvance d’UML. Ce processus, contrairement à UML, n’est pas un standard. Les créateurs d’UML ont, en effet, renoncé à leur ambition initiale de normaliser cet aspect de la méthode. En cette matière, les pratiques sont tellement liées à la culture, au mode d’organisation, à la gestion des hommes… que toute normalisation est illusoire.

C’est ainsi que naît l’idée de remplacer SDM/S par une méthodologie inspirée de UP mais adaptée au contexte de l’Armée de Terre. Le BAE a donc lancé un chantier « Adaptation UP »

Afin d’assurer la pertinence de la réponse et l’adhésion des ressources concernées, le Lieutenant-colonel CHEREL et le Lieutenant-colonel DEMANET ont diligenté une étude préparatoire. La mission de « Cadrage méthodologique », menée par Dominique VAUQUIER, vient de se conclure avec la restitution des résultats auprès de la hiérarchie.

Cette mission a été conduite en appliquant la démarche « DemInno », mise au point pour ce type de travaux et, de façon générale, pour les projets innovants ou à forte incertitude. Les temps forts ont été :

1.     Dans la phase « Impulsion » : les entretiens d’orientation et la « Déclaration ».

2.     Dans la phase « Exploration » : les entretiens d’observation, l’enquête à base de questionnaire auprès de toutes les instances impliquées dans les développements (BOSI pour les études et BDI pour le développement), un atelier d’exploration.

3.     Dans la phase « Cristallisation » : un atelier de cristallisation, le développement d’une maquette du futur référentiel méthodologique, un atelier de conclusion.

Les principales conclusions du cadrage sont :

·        la confirmation de l’orientation « Adaptation UP » et la démonstration des attentes ;

·        l’expression des exigences de contenu et de forme que devra satisfaire le futur référentiel méthodologique ;

·        l’adoption du standard MDA comme ligne guide et la prise en compte du standard SPEM pour la formulation du référentiel ;

·        l’adhésion à l’initiative Praxime de façon à construire sur les fondations déjà établies de la méthodologie Praxeme (la Topologie du Système Entreprise a été présentée plusieurs fois et a entraîné l’adhésion, tous profils confondus) ;

·        le dimensionnement du plan de transition méthodologique.

Des concertations se poursuivent avec des acteurs tels que le pôle Urbanisation SI, le chantier PDU (plate-forme de développement unique) et l’ESAT (pour la formation). Bref, le cadrage méthodologique a été l’occasion de brasser les cultures et de mettre en résonance des préoccupations venant de champs différents. Les travaux menés en convergence conduisent à repenser de fond en comble la chaîne de production du système d’information. C’est une nouvelle façon de travailler qui se profile, pour « produire mieux, plus vite et pour plus longtemps » (sic).

Dans cette perspective, Praxeme apporte le cadre nécessaire pour harmoniser les pratiques, ajuster les outils et mobiliser les hommes.

Le Livre blanc

La nouvelle version du Livre blanc vient de paraître. C'est la version définitive.

Le Livre blanc expose les intentions de l'initiative Praxime et fixe les principes qui fondent la méthodologie Praxeme.

La version 2 rend compte des évolutions du chantier en ce qui concerne l'organisation, à savoir la création d'une association de loi 1901, garante de l'esprit d'ouverture et dépositaire de la méthode publique.

Télécharger Praxime-LivreBlanc_v2.zip (645.0K)

Cadrage méthodologique

Par les nécessités et les ambitions de leurs entreprises, les DSI sont entraînées dans des projets de plus en plus exigeants. Dans le même temps, elles subissent des pressions pour réduire leurs coûts et sécuriser les systèmes. Leur devoir est de dompter les technologies pour les mettre au service de l’entreprise

Or, nous ne disposons plus des méthodes de référence qui nous aidaient, il y a vingt ans, à conduire nos projets.

La disparition ou l’obsolescence des méthodes comme SDM/S et Merise a provoqué une dégradation des compétences en modélisation.

L’offre actuelle en la matière – UML, Unified Process et ses dérivés, TOGAF, ITIL, etc. – privilégie la dimension du processus mais laisse l’opérationnel démuni quand il s’agit de détailler le mode opératoire.

Qui plus est, plusieurs discours spécialisés se présentent – par exemple, l’urbanisation de SI, la modélisation des processus, les architectures SOA… – mais il manque souvent le cadre général pour mettre toutes ses expertises en synergie.

Le cadrage méthodologique est un chantier de courte durée par lequel un organisme réfléchit sur ses pratiques. À titre d’exemple, l’Armée de terre s’interrogeait sur l’évolution des compétences de son personnel informatique et sur le changement de méthode. Le besoin s’en faisait sentir tant sur le terrain qu’au sommet de la hiérarchie, pressée par des exigences telles que l’urbanisation de SI et la LOLF.

Le cadrage méthodologique implique la hiérarchie et crée l’occasion d’une vaste concertation, avec le souci constant de la réceptivité. Ainsi, les orientations sont prises en commun et préparent la phase suivante de transition méthodologique.

D'autres missions opérationnelles requièrent une assise méthodologique solide :

·         La convergence de SI partenaires, convergence assurée par un référentiel « métier » issu de la modélisation sémantique.

·         L’architecture SOA, qui pose la question : « comment trouver les « bons » services ? ».

·         L’innovation en matière d’organisation et de processus.

Tous ces défis font ressortir vivement le besoin en procédés de modélisation.

Nous y répondons toujours en nous appuyant sur une méthodologie déjà constituée et… publique.

La méthode PRAXEME est élaborée selon un principe d’ouverture et de mutualisation des investissements. Plusieurs sociétés et organismes soutiennent l'intiative, dans différents secteurs d’activité.

Entre autres avantages :

• la disponibilité immédiate,
• la possibilité de bâtir une méthode adaptée au contexte mais profitant d'un corpus reconnu et entretenu,
• un socle partagé qui intègre tous les aspects de l’entreprise.

C’est donc une base indispensable pour articuler les expertises et maîtriser les projets.

Pour en savoir plus : OCAM (Offre Cadrage Méthodologique)

« Entia non sunt multiplicanda praeter necessitatem. »

Il ne faut pas multiplier les êtres sans nécessité.

Guillaume d’Occam

Publication

Un article à paraître dans la revue "Information & Système" :

Download is_04_28_32.pdf

Présentation générale du chantier, pour une cible de décideurs DSI.

Application de Praxeme à la SMABTP

La SMABTP est une compagnie d’assurance, spécialisée dans le BTP. Comme beaucoup de ses concurrentes, elle est engagée dans une politique de partenariats et d’ajustements stratégiques qui ont un impact direct sur son système d’information. Pour accompagner ce mouvement, la direction informatique a adopté résolument l’approche SOA, élargie à la visée de l’urbanisation du SI.

Cette approche a commencé à être expérimentée à travers un projet pilote, projet de grande ampleur tout de même puisqu’il s’agit de rien moins que de refondre le domaine de la gestion des sinistres. Les premiers travaux de ce projet ont été douloureux, l’équipe ne disposant, en matière de méthode, que de la notation UML. En 2004, le directeur informatique adjoint, Jean-Michel DETAVERNIER, a mis fin aux tâtonnements et opté pour une méthodologie systématique : Praxeme. Cette méthodologie générale propose des procédés de modélisation adaptés à chaque « aspect » de l’entreprise. De prime abord, elle semblait excéder le propos puisqu’elle situe l’approche SOA dans seulement deux des huit aspects qu’elle identifie. En réalité, elle a aidé à prendre la distance suffisante pour aboutir à la conception rigoureuse de services à forte valeur sémantique.

Praxeme repose sur un socle théorique comprenant la « Topologie du Système Entreprise ». Ce schéma identifie et articule huit aspects par lesquels le modélisateur peut décrire complètement un organisme, de sa stratégie à son infrastructure informatique. SOA suppose des décisions sur deux de ces aspects : l’architecture technique, d’une part ; l’architecture logique, d’autre part. L’architecture technique fixe les dispositifs de composition et de communication qui permettront de restructurer le système en termes de services. Elle donne les règles de développement que devra respecter la réalisation, en tenant compte des outils retenus (langage, midleware, atelier, SGBD, moteur de règles, etc.). L’architecture technique explique, donc, ce que sera le service en tant que composant logiciel.

Reste une question à considérer : comment trouver les services ? Et même : comment trouver les « bons » services ? Sachant que l’on cherche autre chose que de simples accesseurs. À cette question, Praxeme répond avec des préceptes simples :

1.      Le « service » est une notion située dans l’aspect logique. Comme métaphore appliquée à la structuration du système informatique, elle rejoint celle de l’urbanisation de SI. Praxeme inscrit l’architecture de services – un des styles d’architecture logique – dans le prolongement du travail d’urbanisation de SI. Nous parlerons, ainsi, de « service logique », pour dissiper toute confusion avec d’autres acceptions du terme « service ».

2.      Le service logique est le grain élémentaire qui compose le système informatique. Tout besoin d’information ou de transformation est satisfait sous la forme d’un service.

3.      Les services s’ordonnent dans des agrégats logiques. Les niveaux d’agrégation sont en nombre limité. Les plus larges se confondent avec les termes de l’urbanisation de SI. Le graphe d’architecture logique représente exactement ces agrégats logiques ainsi que leurs relations. Il permet de mesurer le taux de couplage dans le système.

4.      La majorité des services logiques se déduit des modèles amont. Cette idée est celle du standard MDA (model driven architecture). La Topologie inscrit deux aspects en amont de l’aspect logique : sémantique et pragmatique. Le modèle sémantique exprime le « cœur de métier », c’est-à-dire les fondamentaux du métier, indépendamment de l’organisation et des choix techniques. Le modèle pragmatique décrit l’organisation et les pratiques : processus, cas d’utilisation, règles d’organisation, etc. Praxeme indique les règles de dérivation qui, appliquées à ces modèles, produisent les services logiques et une partie de la structure.

5.      Un pseudo-langage permet de spécifier rigoureusement les services logiques. Ce travail est dévolu au « concepteur logique ». Le développeur n’a plus qu’à traduire ces spécifications formelles, en suivant les consignes imposées par l’architecture technique.

Dans le cas de la SMABTP, cette méthodologie a permis d’élaborer un modèle sémantique à vocation universelle pour les métiers d’assurance : ceci constitue un atout considérable dans les échanges avec des partenaires. Elle a conduit, également, à en dissocier nettement les règles d’organisation et habitudes de travail. Cette distinction est reprise dans l’architecture logique sous la notion de « strate » ; elle augmente l’agilité du système.

Enfin, la Topologie sert de guide pour l’identification des compétences requises et pour une meilleure gestion des profils RH. Après cette première expérience, la SMABTP a décidé de généraliser la méthode à l’ensemble de ses projets et élabore une offre de formation, à cette fin.