Présentation de la méthode publique PRAXEME de transformation de l'entreprise
Sa motivation, son histoire
le panorama général de la méthode
PRAXEME et les autres framework d'architecture
1. PRAXEME : L’ESSENTIEL
--- --- ---
22 novembre 2013
Antoine CLAVE
Consultant en conduite de projet et architecture logicielle
1/79
2. Avertissement : sauf avis
contraire, tous les documents,
citations et schémas sont issus
du fonds public de la méthode
PRAXEME, dont le dépositaire
est le Praxeme Institute.
Ces éléments, ainsi que cette
présentation, sont protégés
par la licence Creative
Commons décrite ci-contre
Antoine CLAVE
2/79
3. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
3/79
4. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
4/79
5. PRAXEME : histoire et
motivation (1)
Les auteurs
Dominique VAUQUIER
Expert en architecture d’entreprise, intervenant comme
consultant chez des grands comptes (AXA, RATP, … )
Philippe DESFRAY
Co fondateur de SOFTEAM et directeur technique de l’outil
MODELIO, contributeur majeur à l’OMG (UML)
Pierre BONNET
Co fondateur d’ORCHESTRA NETWORKS (2000),
spécialiste SOA et Master Data Management
Antoine CLAVE
5/79
6. PRAXEME : histoire et
motivation (2)
Un vision initiale : l’entreprise lego (2002)
Construire des offres agrégeant des services existants
Issus de l’entreprise, de ses filiales, de ses partenaires
Une genèse en entreprises (2002 & sq)
SAGEM, SMABTP (Jean-Michel de TAVERNIER)
Centrée sur le cœur du métier de l’entreprise
Le modus operandi érigé en méthode : PRAXIME
Mutualisation, systématisation (2004)
PRAXEME, méthode publique d’entreprise
Livre Blanc : vers un SI durable et agile
Constitution d’un fond public par ajouts coopératifs, diffusion
Fondation du PRAXEME INSTITUTE, 2006
PAXEME V2 depuis 2013
Antoine CLAVE
6/79
7. PRAXEME : histoire et
motivation (3)
Années 80 : l’informatique oublie son héritage
méthodologique
Merise (1974), Warnier (1977), Yourdon (1979), AXIAL
(1986)
Qui s’en souvient ?
UML, l’objet ont longtemps
été pris pour une méthode
… mais des acteurs cherchent un cadre de référence
John Zachman (1987), Bertrand Meyer (1988)
Et l’urbanisation
Jacques SASSOON (1990)
Remettre de l’ordre en cartographiant
Antoine CLAVE
7/79
8. PRAXEME : histoire et
motivation (4)
Abolition de la rigueur méthodologique parallèle avec
la montée en complexité des SI
EAI, CRM, progiciellisation (1995)
Des solutions qui se veulent intégrées, mais difficiles à faire
évoluer et à faire communiquer
Le SI est débité en silos fonctionnels
L’informatique n’a pas su défendre son point de vue
Priorité aux traitements aux dépends des données
Deux préoccupations
orthogonales !
Les acteurs du métier font (registre = action)
Le SI recueille, mémorise, diffuse , ne crée pas (registre = état)
Antoine CLAVE
8/79
9. PRAXEME : histoire et
motivation (5)
Et aujourd’hui ?
Le SI = un patrimoine hétérogène complexe coûteux
« en tuyaux d’orgues »
Des besoins récurrents : l’agilité, l’alignement, la
qualité de service, l’économie
L’entreprise se dépouille de précieuses compétences
La conceptualisation, une compétence sinistrée
La SOA : un pont entre une urbanisation fonctionnelle
et la conception objet
Le Saint-Graal ?
Antoine CLAVE
9/79
10. PRAXEME : histoire et
motivation (5)
Une volonté de renouer avec la maîtrise du patrimoine informatif
de l’entreprise
Rigueur méthodologique
Développement en « pelure d’oignon » : dette technologique
Les objets du métier : au cœur de la préoccupation du Système
d’Information
Faire = volatilité, essence = pérennité
Accompagner un mouvement général de standardisation
L’analyse fonctionnelle : un
ACORD, HL7, eTom …
piège méthodologique ?
Éviter les redondances, les enfouissements de services
Fournir un cadre méthodologique pour piloter la transformation
Fonder solidement une action au long cours
Antoine CLAVE
10/79
11. PRAXEME : histoire et motivation (6)
En conclusion, PRAXEME pour :
Innover, simplifier, maîtriser les transformations en
profondeur
Doter le marché d’une vraie méthode de référence
Mutualiser des efforts disparates
Couvrir tous les aspects de l’entreprise
Articuler les expertises nécessaires à la transformation
De la stratégie au déploiement
Antoine CLAVE
11/79
12. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
12/79
13. methodeEntreprise
PRAXEME = Méthodologie d’entreprise
PRAXEME a pour ambition de couvrir tous les aspects de
l’entreprise
De la stratégie au déploiement,
Propose des procédés
Convoque des expertises
A une vision claire de sa cible
Précise et articule les contributions :
Architecture métier, architecture d’entreprise
Des partis pris structurants
En amont : la stratégie, le métier (sa sémantique)
Les « traitements » sont seconds
Interdisciplinarité, globalité
Un méta modèle puissant
Gage de qualité
Antoine CLAVE
13/79
14. methodeEntreprise
COUVRIR LES ASPECTS DE L’ENTREPRISE
Modélisation sémantique : capture les
fondamentaux du métier (les concepts).
Modélisation pragmatique : prend en charge les
aspects organisationnels (processus, fonctions).
Modélisation logique : lieu d’élaboration de
l’architecture optimale, sans considération
technique.
Modélisation géographique : localisation des
moyens physiques de l’institution
Modélisation logistique : les solutions logicielles et
matérielles
Modélisation physique : projection de l’architecture
logistique sur l’architecture physique
Aspect = Portion de la réalité,
isolée pour en faciliter l'étude,
en respectant sa logique interne
Antoine CLAVE
14/79
15. methodeEntreprise
COUVRIR LES ASPECTS DE L’ENTREPRISE
La Topologie de Système Entreprise est apte à
héberger toutes les descriptions, issues de tous
les points de vue, de l’Entreprise. Un référentiel unique !
L’entreprise est humaine
Une histoire
Des volontés qui la portent
Des valeurs incarnées
Des femmes et des hommes
« Le passé est la rampe de
lancement vers l’avenir »
Otto von Habsbourg
L’aspect intentionnel recueille ces descriptions
Il justifie tous les autres
Formalisation des modèles préconisée : UML
Lien de traçabilité entre les modèles : MDA
Antoine CLAVE
15/79
La culture de l’entreprise
16. methodeEntreprise
L’ASPECT INTENTIONNEL
Aspect amont, légitimation des 6 autres aspects
Cet aspect réunit :
Les valeurs de l’entreprise
les comportements au sein de l’entreprise doivent s’y
conformer
Les objectifs de l’entreprise
« Nous chez Renault nous fabriquons des autos et
Les métriques
nous n’avons pas l’intention de changer de
métier » (L.Schweitzer PDG Renault 1992 - 2005)
Le vocabulaire
Quid de la Responsabilité Sociale
de l’Entreprise ? (responsabilité
d’une entité juridique vs
responsabilité des hommes)
Antoine CLAVE
16/79
17. methodeEntreprise
AU SERVICE DE L’ENTREPRISE
Reculer les limites de la complexité
Une vision « système », des interactions entre composants, un réseau
social
Stimuler les synergies
Clarifier les responsabilités, articuler les expertises
Restaurer la lisibilité
Fournir une vision globale grâce à une cartographie appropriée
Outillages de modélisation
Équiper les métiers
Ingénierie des systèmes, analyse fonctionnelle, architecture,
organisation
Procédés
Et surtout : au service de sa transformation
Antoine CLAVE
17/79
19. methodeEntreprise
DÉGAGER DES SYNERGIES …
En faisant coopérer des compétences éloignées
Et peu habituées à travailler ensemble
Un cadre rigoureux et organisé
Structure de la méthode : le schéma Pro3
PRODUIT : objet de notre travail
(l’entreprise dont le modèle nourrit la TSE)
PROCESSUS : l’organisation des travaux
de l’équipe d’architecture
PROCÉDÉ : le travail individuel
Processus & procédés :
comment alimenter la TSE ?
Antoine CLAVE
19/79
20. methodeEntreprise
PROPOSER OUTILS ET PROCÉDÉS
Processus
De développement et de transformation
essentiellement
Procédés
Des modes opératoires : passer du langage à la
méthode, procédés de la modélisation sémantique,
structurer l’aspect sémantique
Et pas uniquement des guides méthodologiques
Travail en cours
Antoine CLAVE
20/79
21. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
21/79
22. methodePraxème
PRODUIT PROCESSUS et PROCÉDÉS
Le PRODUIT
De quoi parle-t-on ?
Quelle est la cible de notre action de description et de
transformation ?
Les PROCESSUS
Le processus de construction de la TSE Dimension collective
Le processus de transformation de l’entreprise
Les PROCÉDÉS
Dimension individuelle
Comment insérer la tâche de chacun dans l’œuvre de
tous ?
Antoine CLAVE
22/79
23. methodePraxème
PRODUIT : le SYSTÈME ENTREPRISE
Un objet d’étude complexe
L’appréhender sous ses facettes => la TSE est
organisée en « aspects »
Des guides méthodologiques pour chaque aspect
Px V2 : guide général, aspect sémantique, aspect
pragmatique
Px V1 : ceux de la V2 + aspect logique, aspect
géographique, aspect physique
Nous allons examiner trois aspects de la méthodologie :
aspect sémantique
aspect pragmatique
aspect logique
Antoine CLAVE
23/79
24. methodePraxème
L’ASPECT SÉMANTIQUE (1)
PxPRD-20
L’aspect sémantique isole la connaissance des
Décrit les objets au cœur de
fondamentaux du métier
l’activité. Décrit le noyau
fondamental indépendant de la
Fondamentaux du métier :
manière de mener l’activité
Tout ce qui permet à l’entreprise de se mouvoir dans
son environnement
Débarrassé de toute référence à l’organisation et aux
moyens mis en œuvre
Client, fournisseur => personne
Facture, acompte, devis, bon de livraison => pièce comptable
Antoine CLAVE
24/79
25. methodePraxème
L’ASPECT SÉMANTIQUE (2)
L’aspect sémantique est formalisé en modèles
UML est préconisé mais non obligatoire
Le diagramme de classe
UML supporte la
description structurale
CLASSE : notion ensembliste …
mais pas uniquement
CLASSE : description structurale
Antoine CLAVE
25/79
26. methodePraxème
L’ASPECT SÉMANTIQUE (3)
Et la description dynamique ?
Le diagramme états –
transitions UML
supporte la description
contractuelle
Le même événement peut générer
des transitions différentes
Antoine CLAVE
26/79
LE CYCLE DE VIE D’UNE
PIÈCE COMPTABLE
27. methodePraxème
L’ASPECT SÉMANTIQUE (4)
Puissance d’expression au service de l’aspect
sémantique
Chaque année, les étudiants s'inscrivent
dans un groupe (effectif : 4 à 25) et
suivent les modules ; pour un étudiant,
un module est enseigné par un seul
enseignant.
Un enseignant ne peut pas assurer plus de
trois modules à un groupe d’étudiants.
Possibilité de pousser
l’expression jusqu’à
la généricité
Antoine CLAVE
27/79
28. methodePraxème
L’ASPECT SÉMANTIQUE (5)
L’héritage permet d’organiser les objets du métier
Attributs structurels
Attributs transactionnels
Antoine CLAVE
28/79
La classe VÉHICULE est
abstraite
Propagation des propriétés,
méthodes, associations
29. methodePraxème
L’ASPECT SÉMANTIQUE (6)
Avantages de l’aspect sémantique
PRAXEME « tourne le dos à une représentation de l’entreprise
[commençant] par ses activités » (approche de l’aspect
sémantique p4)
La sémantique du métier s’organise autour de concepts, ou
d’objets physiques premiers sur lesquels l’acteur n’a un
pouvoir que limité
Beaucoup d’objets résultent de nos habitudes de travail
Cette discipline permet de distinguer ce qui est ontologique de
ce qui résulte de rapports à d’autres (rôles)
Qualités attendues de l’aspect sémantique
stabilité, compacité, universalité
Antoine CLAVE
29/79
30. methodePraxème
L’ASPECT SÉMANTIQUE (7)
Bien distinguer le métier de ses conjonctures
Règles métier : le sont-elles toutes ? Des règles organisationnelles
Événements : inter ou intra entreprises ?
Légitimer la représentation sémantique en adoptant
un point de vue externe
Client, usager, bénéficiaire, mandataire, titulaire … :
notions internes
La réalité sous-jacente externe : personne
Permet de rendre le modèle partageable
Antoine CLAVE
30/79
33. methodePraxème
L’ASPECT PRAGMATIQUE (1)
PxPRD-30
L’entreprise nous apparaît, d’abord et avant tout, comme
activité ; c’est son aspect pragmatique.
Activité de l’entreprise :
Des processus aux situations élémentaires de travail
Organisation et rôles, responsabilités, règles, procédures
Style de management
Objets de nature organisationnelle
Acteurs, leurs intérêts, leur comportement
Un modèle pragmatique : activités + l’organisation mise en
Réunit les choix relatifs à la manière de mener
place
l’activité : acteurs, responsabilités, actions sur les
objets, processus et les situations de travail
Antoine CLAVE
33/79
34. methodePraxème
L’ASPECT PRAGMATIQUE (2)
Positionnement
En amont : l’aspect intentionnel, l’aspect sémantique
En aval : l’aspect logique, l’aspect géographique
L’organisation et les processus métier peuvent se
décrire en référence à :
L’aspect intentionnel
L’aspect sémantique
Antoine CLAVE
34/79
35. methodePraxème
L’ASPECT PRAGMATIQUE (3)
Ses enjeux :
Amélioration des activités
Simplification, reconception des processus
Maîtrise de la qualité du service rendu (mesure)
Robustesse de l’organisation (vision de l’activité)
Adéquation avec les intentions
Les processus respectent des valeurs, réalisent les
objectifs, respectent une terminologie unifiée
Adaptation de l’entreprise
Reconfigurations organisationnelles
Chaînes de valeurs complexes (entreprise étendue)
Réactivité, agilité
Innovation !!☺Ѿ
Antoine CLAVE
35/79
36. methodePraxème
L’ASPECT PRAGMATIQUE (4)
Contenu de l’aspect pragmatique
Activités de l’entreprise
La chaîne de valeur
Variabilité, pluralité
Les représentations
Des actions aux processus : les activités
Les deux niveaux de description de toute activité : pratique (mode
opératoire), exécution (réalisation concrète mesurée)
Les relations entre activité (enchaînement, information, agrégation,
réutilisation, compensation)
Acteurs, rôles et organisation
Objets organisationnels
Événements et messages
Règles, contraintes
Antoine CLAVE
36/79
37. methodePraxème
L’ASPECT PRAGMATIQUE (5)
Un processus, c’est :
Enchaînement ordonné d'activités, aboutissant à un
résultat déterminé.
Déclenché par un événement qui lui est externe,
aboutit à un résultat qui est sa raison d'être.
Caractérisé par :
•
•
•
Un événement déclencheur, en entrée
Suite d'activités, constituant la chaîne des
valeurs ajoutées (construction du résultat)
Une fin qui se matérialise par un résultat
pour le bénéficiaire du processus (Client)
Michel RAQUIN Club des Pilotes de Processus
Antoine CLAVE
37/79
40. methodePraxème
L’ASPECT PRAGMATIQUE (8)
Les Acteurs
•
•
•
Client
Service comptable
Service livraison
Les objets organisationnels manipulés par le métier
•
•
•
Devis
Facture
Paiement
Le cycle de vie des objets
•
Antoine CLAVE
Facture : émise, réglée
40/79
Règles de cohérence entre
les descriptions sémantique
et pragmatique
42. methodePraxème
L’ASPECT PRAGMATIQUE (10)
Le processus fait parcourir son cycle de vie à l’objet
Les actions où le Système intervient seront décrits
sous forme de Cas d’Utilisation
Cas d’Utilisation : dialogue Acteur - Système
Transaction métier
Transition de l’objet organisationnel métier
Chaque traitement du dialogue = service
Référence les règles de gestion
Référence les propriétés de l’objet organisationnel
Pilote la conception des IHM
Formalisme de description des CUs
Pilote les tests unitaires
Unité livrable élémentaire si projet itératif
Antoine CLAVE
42/79
43. methodePraxème
L’ASPECT PRAGMATIQUE (11)
Un Cas d’Utilisation est une interaction
élémentaire entre un acteur et le système
Pré conditions
L’Acteur a l’initiative
Le Système répond
Post conditions
(services attendus)
Règles de gestion
Antoine CLAVE - VUE
FONCTIONNELLE
43/107
Passer à la
première page
45. methodePraxème
L’ASPECT LOGIQUE(1)
Aspect intermédiaire qui permet une
description formelle du système étudié,
indépendamment des choix techniques
PxM-40
Intermédiaire entre deux réalités :
La vue externe (cœur du métier, organisation et
géographie)
Le système informatique (choix techniques, composants,
Guide général, p15
déploiements)
Doit faciliter les décisions de structuration du système
informatique
Un mode de représentation doublement métaphorique
Urbanisation
Services
Antoine CLAVE
45/79
46. methodePraxème
L’ASPECT LOGIQUE(2)
Architecture de services
Une architecture est dite « orientée services » si elle
structure le système autour de l’unité élémentaire
du service logique
Une ambigüité : le composant, ce que
fournit le composant (cf : le Service Public)
Un service :
Composant le plus fin de l’architecture (de services)
Réponse élémentaire du système à un besoin
(d’information)
Unité de conception qui sera dérivée en constituant
logiciel
Antoine CLAVE
46/79
47. methodePraxème
L’ASPECT LOGIQUE(3)
Nature d’un service logique
Machine logique, représentée par une classe UML
Classe sémantique : dérivée en Machine Logique Métier
Cas d’Utilisation : dérivé en Machine Logique
Organisationnelle
L’aspect logique articulera deux vues :
Une vue organisation
Quels en seront les composants ?
Comment l’information circulera-t-elle ?
Une vue utilisation
Deux descriptions :
Statique
Dynamique
Comment le Système répondra-t-il aux besoins de l’utilisateur ?
Antoine CLAVE
47/79
48. methodePraxème
L’ASPECT LOGIQUE(4)
La structuration logicielle permise par l’aspect
logique est donc fondée sur
Une généricité simplicité et compacité héritée de
l’aspect sémantique
Une organisation service héritée de l’aspect
pragmatique
Sans perdre de vue l’objectif stratégique, apporté
par l’aspect intentionnel
Cette structuration optimale se fait
indépendamment des choix technologiques,
repoussés en aval
Antoine CLAVE
48/79
49. methodePraxème
L’ASPECT LOGIQUE(5)
Le modèle logique des données
L’architecture des données peut être découplée de
l’architecture des services
Architecture SOA => plan des services masque plan
des données
Architecture SOA : un style
d’architecture non obligatoire
Antoine CLAVE
49/79
50. methodePraxème
L’ASPECT LOGIQUE(6)
Stratification du Système
3 types de machines logiques
Machines logiques métier : issues des classes sémantiques
Machines logique s organisationnelles : issues des Cus et
processus
Machines logiques utilitaires : événements, codifications,
exceptions …
3 cercles
INTERFACES
Le pérenne est
protégé par le volatile
MLO
MLM
Antoine CLAVE
50/79
Une circulation polarisée
des appels de services
52. methodePraxème
L’ASPECT LOGIQUE(8)
• Actions de l’utilisateur (ou d’un autre Système)
• IHM (ou IMM)
• Invocation de la couche interactions
• Classes MVC
• Invocation de la couche organisation
• MLO
• Invocation des classes Elémentaires
• MLM
Antoine CLAVE
52/79
53. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
53/79
54. ChaîneValeur
UN CONCEPT MANAGERIAL
Michael Porter : l’avantage concurrentiel (1986)
« La chaîne de valeur représente l’activité de
l’entreprise décomposée en séquences
d’opérations élémentaires et permet d’identifier les
sources d’avantages concurrentiels potentiels »
Christian HOHMANN
www.Chohmann.free.fr
La valeur ?
Ce que les clients sont prêts à payer pour obtenir le
produit ou le services
Doit compenser les différentes activités réalisées par les
fournisseurs, l’entreprise, la commercialisation
Antoine CLAVE
54/79
56. ChaîneValeur
UNE NOUVELLE VISION DE
LA CHAÎNE DE VALEUR
L’entreprise =
réalise des opérations
s’ajuste
se transforme
Vision linéaire de la chaîne de
valeur : obsolète
Intégrer la prise d’informations,
les rétroactions, les
décisions de transformation
Vision Praxème : dépasse l’approche linéaire
Antoine CLAVE
56/79
57. ChaîneValeur
UNE VISION SYSTÉMIQUE
L’entreprise, lieu d’ajustements permanents
Le commercial capte l’accueil fait aux nouveaux produits =>
nécessité de transmettre cette information à qui peut agir
Veille : surveille la e-réputation de l’entreprise => nécessité de
transmettre et de réagir vite
Ces informations sont-elles exploitées de manière optimum ?
L’entreprise, lieu de transformations
Un système est auto adaptateur (ou disparaît)
Un système est apprenant
Un système est homéostatique
Un système est ouvert
Joël de Rosnay
Jacques-Antoine Malarewicz
Un système est finalisé
Un système est relationnel
Antoine CLAVE
57/79
58. ChaîneValeur
PRENDRE EN COMPTE LES
PRÉOCCUPATIONS DE L’ENTREPRISE
Rendre compte de la complexité de l’entreprise
exige un cadre descriptif rigoureux
Fournir un outil qui permette sa transformation en
vue de son adaptation à son environnement
exige cadre méthodologique organisé
Informations stratégiques
Informations tactiques (organisationnelles)
Informations opérationnelles
Savoir articuler l’approche analytique (cartésienne)
et l’approche systémique.
Antoine CLAVE
58/79
59. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
59/79
60. TRANSFORMER L’ENTREPRISE
Comment assurer le continuum entre les opérations
et la transformation ?
L’agilité de l’entreprise réside dans la capacité à
réaliser ce continuum
Télescopage de plusieurs nécessités :
Nécessité de la transformation
Nécessité d’une méthodologie
Nécessité de la qualité
Apprécie la production instantanée (activités
opérationnelles) , l’amélioration des pratiques (ajustement)
et l’adaptation de l’entreprise (sa transformation)
Antoine CLAVE
60/79
61. ANALYSER LES INFORMATIONS
Sur le fonctionnement actuel
Vérifier le bon fonctionnement
et ses insuffisances
Le double rôle du manager
Opérationnel
Tactique
Imaginer de nouveaux fonctionnements
Ce que PRAXEME traduit par une vision enrichie
de la roue de Deming :
Antoine CLAVE
61/79
64. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
64/79
65. PRAXEME INSTITUTE
Association loi 1901, fondée en 2006
Développement et promotion de la méthode
publique
Dépositaire du fonds public
Garant de l’ouverture et de la gratuité
Coordonne les travaux de développement
Contributeurs entreprises
Un site et un wiki
Antoine CLAVE
65/79
67. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
67/79
68. ZACHMAN
TOGAF
Stratégie de
l’entreprise,
valeurs
aligner les
processus sur les
exigences de la
stratégie
Valeurs : non
Méta modèle
Très exhaustif
Simple et
(aborde tous les formalisé
sujets et niveaux
de l’entreprise),
non décrit
formellement
Antoine CLAVE
68/79
On
commence
par la
stratégie de
l’entreprise.
Valeurs :
possible
URBANISATION
PRAXEME
Doit établir la
Fait l’objet
cohérence des
d’un
processus du SI et « aspect »
dresser la
complet
cartographie
(aspect
applicative ;
intentionnel)
valeurs : non prévu englobant les
4V
Proposition d’un
modèle générique,
définition peu
formalisée
Rigoureux,
modélise et
justifie toute
la
méthodologie.
Formalisé
(UML)
69. ZACHMAN
TOGAF
URBANISATION
PRAXEME
Procédés
Aucun
(pas à pas) document
n’est
disponible
Description
exhaustive :
comment créer
l’architecture à
travers l’ADM.
Description
simplifiée des
actions à réaliser
Des fiches
procédés
sont
proposées
dans la V2
Référentiel
L’entreprise
continuum définit
la sémantique de
référence à
utiliser
Des études de
cas ; sémantique
peu précise et
métaphorique
Topologie du
Système
Entreprise ;
forte
cohérence
entre les
aspects
Non prévue
Oui (UML, BPMN) Oui (UML,
non
obligatoire)
Aucun
modélisation Non prévue
Antoine CLAVE
69/79
70. ZACHMAN
Architecture
cible /
Change
management
Très faible en
regard du
PMI ou IPMA
Périmètre
TOGAF
Modéliser
l’architecture
cible possible
; pas de
guide de la
transition
Guides de
planification
de la migration
vers la cible ;
la conduite du
changement
Description
exhaustive
prise en
compte
4 niveaux
d’abstraction
(métier,
fonctionnel,
applicatif et
technique)
non intégrés
Antoine CLAVE
70/79
URBANISATION
Objectif : amener
plus de cohérence
dans le SI, mais
pas de démarche
formalisée pour
atteindre la cible
PRAXEME
architecture
cible = but de la
méthodologie ;
pas de
« paysage
architectural » ni
de transition
proposés
Prend en compte les Restreindre le
mêmes 4 niveaux, se périmètre : non
concentre sur les 3 prévu (a priori,
premiers et souvent vision globale de
peu impliquée dans la l’entreprise) TSE
stratégie et
très intégrée
l’organisation globale
de l’entreprise
71. ZACHMAN
Source
TOGAF
URBANISATION
PRAXEME
Le Framework
graphique est
facilement
accessible,
mais le détail
explicatif est
réservé aux
membres.
Une
documentation
exhaustive est
disponible sur
le web :
TOGAF 9.1
Informations
accessibles à travers
des livres. Accès au
détail des informations
: limité aux membres
du club urba-ea. Mais
ce club publie des
livres décrivant des
cas concrets.
Méthode
publique :
ensemble de la
documentation
accessible
librement sur
le site
Documentation
volumineuse :
certification
utile.
Partitionnement
complexe
Non-standardisation
de l’urbanisation :
champ assez libre sur
son utilisation. Plus
facile à mettre en
place
Mise en œuvre
nécessite une
formation
(prévue : voir
site)
Complexité Nécessaire
d’utilisation d’être certifié
afin de
comprendre
l’utilisation
Antoine CLAVE
71/79
72. PRAXEME : L’ESSENTIEL
HISTOIRE : initiateurs, motivation
PRAXEME, MÉTHODOLOGIE D’ENTREPRISE
LA MÉTHODE PRAXEME
LA CHAÎNE DE VALEUR
LA TRANSFORMATION DE L’ENTREPRISE
LE PRAXEME INSTITUTE
PRAXEME ET LES AUTRES …
UN EXEMPLE VÉCU
Antoine CLAVE
72/79
73. PRAXEME : RETOUR
D’EXPÉRIENCE (1)
Contexte : éditeur d’un progiciel
15 ans de développements successifs
Excellentes performances …
Interfaces obsolètes
Sont de plus en plus difficile à intégrer :
les évolutions comptabilité du métier
les nouvelles contraintes réglementaires
Antoine CLAVE
73/79
74. PRAXEME : RETOUR
D’EXPÉRIENCE (2)
Décision du ComEx de l’entreprise : refonte totale
Développements
En interne
En partenariat avec un organisme professionnel
Spécifications : autour des écrans
Métier = enchaînements d’écrans Descriptions polluées par des
considérations techniques. Les gens
RG = règles de calcul des champs du métier et l’informatique
Moteur applicatif interne, base de données : à la libre
appréciation des développeurs
De fortes disparités
Antoine CLAVE
74/79
75. PRAXEME : RETOUR
D’EXPÉRIENCE (3)
Après une première livraison décevante, volonté de
mettre en place une véritable méthode de
développement logiciel centré sur une vision
architecturale forte.
Choix : PRAXEME
Mis en place en collaboration avec la cellule qualité
En respectant certains principes de méthodes agiles
Antoine CLAVE
75/79
76. PRAXEME : RETOUR
D’EXPÉRIENCE (4)
Première action : décrire le métier de l’utilisateur du
progiciel
Quels processus ?
Quels Cas d’Utilisation
Quels objets ?
Un écart dû à la
culture de l’entreprise
Deuxième action : bâtir un véritable référentiel du
projet articulé sur trois aspects
Aspect sémantique
Aspect pragmatique
Aspect logique
Antoine CLAVE
76/79
77. PRAXEME : RETOUR
D’EXPÉRIENCE (5)
Les développements :
Sous la responsabilité d’un architecte technique,
À partir de l’aspect logique
En utilisant un framework technique
Les tests
Tests unitaires
Tests d’assemblage
Tests d’intégration
Tests utilisateurs les plus sévères (marketing)
Antoine CLAVE
77/79
78. PRAXEME : RETOUR D’EXPÉRIENCE (6)
Points positifs
L’équipe a perçu la nécessité d’une formalisation rigoureuse du métier
Séparer le registre du problème de celui de la solution
Mise au point d’un véritable processus de production
Une architecture complètement déduite des descriptions du métier
Qualité, risques gérés efficacement
Facilité déconcertante pour adapter le produit aux différents clients
Facteur de rentabilité
Difficultés
Courbe du soleil : non suivie
Gestion de la montée en compétence peu compatible avec le
calendrier
Intégration du FWK technique : des conflits de conception
Ruptures entre les décisions niveaux logique et technique
Conception de la base de données : acrobatique
Antoine CLAVE
78/79