La French Tech tacle l’Empire

Ou : « EBX fait le buzz »

Le cabinet Gartner vient de publier son Magic Quadrant pour les solutions de Master Data Management. L’étude place la solution EBX, d’Orchestra Networks, dans la catégorie des « Leaders » (elles ne sont que deux solutions dans cette catégorie).

On s’étonnera que des noms plus prestigieux soient confinés dans la zone des acteurs de niche. Une raison probable est la spécialisation des solutions par domaine. Pour le vendeur, une telle spécialisation s’est longtemps montrée rentable :

  1. tout d’abord, elle facilite la démarche commerciale, notamment auprès des directions métier ;
  2. ensuite, elle permet de tirer davantage de profits, en proposant une solution distincte pour chaque domaine à couvrir, ce qui gonfle la facture ;
  3. enfin, elle évite au vendeur de déployer trop d’efforts pour intégrer des solutions, presque toujours issues d’acquisitions successives.

Permettez-moi de vous raconter une anecdote. Il s’agit d’un gros projet de MDM, dans une compagnie d’assurance japonaise. Tout de suite, le projet est scindé en deux sous-projets, chacun sur un domaine précis : l’un sur les données des clients, l’autre sur celles des fournisseurs. Un seul prestataire est retenu, qui propose une solution pour chacun des domaines.

En revue d’architecture, quelqu’un pose la question naïve : au fait, quand on y pense, est-ce qu’un client – individu ou organisation – ne présente pas des points communs avec un fournisseur ?

Il va de soi que, dans une approche de modélisation sémantique, « client » et « fournisseur » sont considérés comme des rôles, et que le modèle place, en son centre, le véritable objet : l’entité. C’est uniquement dans sa relation à un contrat ou à un engagement que l’entité revêt tel ou tel rôle. D’ailleurs, une même entité peut être, pour une entreprise, à la fois un client et un fournisseur, ou un client et un collaborateur, etc.

De là, l’idée toute simple qu’un seul référentiel pourrait couvrir toutes les entités, quels que soient leurs rôles, réduisant ainsi la redondance du système (donc les coûts d’investissement et de fonctionnement, la lourdeur, les risques, etc.).

Pendant cette revue d’architecture, tout le monde tombe d’accord sur cette évidence. Mais trop tard…

Faute d’avoir aperçu cette idée toute simple, on en arrive à ce paradoxe : alors que la démarche MDM a pour but d’augmenter la maîtrise du système, ce qui passe par une réduction de la redondance, le projet n’a fait que l’accroître. Passe encore que nos systèmes aient accumulé une redondance effarante au cours de leur histoire : on en connaît les raisons. Mais que, au moment de reconstruire, les mêmes erreurs se reproduisent… il n’y a pas d’excuse. Cela ressemble fort aux logiques perverses que Jacques Généreux dénonce dans « La déconnomie » à propos des politiques économiques.

Orchestra Networks, en tant que « pure player » depuis son origine, a évité cet écueil. N’étant pas inféodée à d’autres intérêts, la solution a toujours et forcément été multi-domaine. Ce n’est pas un hasard, d’ailleurs, si Orchestra Networks compte parmi les fondateurs du Praxeme Institute. D’aucuns y verront le signe d’une communauté culturelle profonde.

Une entreprise qui voudrait améliorer radicalement son système informatique, comme le prône Praxeme, trouverait dans EBX la solution parfaite. Elle lui permettrait de restaurer l’unité de ses données, et de se rapprocher de la pureté sémantique. Cette étape est nécessaire pour simplifier le système et recouvrer une créativité qui a bien déserté le domaine de l’informatique.

Dans un sens, on peut voir, dans la destinée d’Orchestra Networks, une belle illustration de la « French Tech ». Dans l’esprit : plutôt que concevoir des solutions tactiques qui traitent partiellement le sujet, penser une solution globale et pragmatique… et s’y tenir

Lien vers l’étude de Gartner : http://www.orchestranetworks.com/gartner-mdm-magic-quadrant/.

Transformer l’assurance ?

La transformation est une des grandes préoccupations des compagnies d’assurance, grandes et petites. Souvent réduite à sa dimension technique (transformation numérique ou digital transformation), elle touche néanmoins tous les aspects de cette activité, entraînant quelques difficultés à agir et à penser.

Quelques réflexions, appuyées sur une longue expérience du secteur et prolongées par des recommandations de mise en oeuvre ont été réunies dans ce papier :

Elles feront l’objet d’une intervention lors du Symposium Praxeme.

Terminologie d’entreprise

Dans les missions de Praxademia, systématiquement, nous portons une grande attention au vocabulaire utilisé dans l’entreprise. Cette habitude a été acquise au fil des ans. L’établissement d’un dictionnaire est apparu, d’abord, comme une nécessité pratique pour préparer le travail et pour alimenter la modélisation. Puis, devant l’intérêt manifesté par les acteurs “métier”, ce dictionnaire est passé du statut de produit intermédiaire à celui de livrable, à part entière. Il faut dire, même, qu’un bon dictionnaire soulève plus d’enthousiasme qu’un modèle !

Par la suite, en exploitant les fonctionnalités disponibles dans nos outils de modélisation, le dictionnaire a pris la forme d’un thesaurus, c’est-à-dire qu’on lui a ajouté les relations entre les termes, représentées par des diagrammes terminologiques. La traçabilité entre les entrées du thesaurus et les éléments de modélisation accroît les retombées de cet effort. Elle rend possibles et instantanées les analyses d’impact, en cas d’évolution. Le thesaurus sert, alors, de “sas d’entrée” entre le langage naturel et l’expression formelle des modèles. Il augmente, donc, la valeur de l’ensemble des modèles. Le référentiel de description de l’entreprise en voit ses usages démultipliés.

Cette pratique est décrite dans les procédés terminologiques de la méthode Praxeme. Praxademia a participé à leur rédaction. Cet effort est financé par le cabinet Conix Consulting, dans le cadre de sa contribution à la méthode publique.

Ont été publiés, récemment : l’introduction et une version révisée de procédé de définition (voir le Catalogue de la méthode Praxeme). Bientôt paraîtra un tout nouveau procédé : “Élaborer un thesaurus”.

Les résultats du chantier PxData (sur la terminologie et sur la data policy) seront présentés lors du Symposium annuel, le 17 décembre 2016. Si vous êtes intéressé par ses sujets et par l’actualité méthodologique, nous vous conseillons de vite vous inscrire : l’année dernière, nous avons dû refuser du monde.

Le deuxième Petit-Déj’SI

Praxademia a convié quelques décideurs informatiques à échanger autour d’un petit-déjeuner, tenu au Pavillon Ledoyen, le 15 octobre 2015.

Le compte rendu est publié via le groupe Praxeme sous LinkedIn.

Ci-dessous, l’ordre du jour indicatif établi par Joël Bizingre (Conix Consulting) et Dominique Vauquier.

L'ordre du jour du Petit-Déj'SI

Voir aussi :

 

Les disciplines de la transformation d’entreprise

Praxeme est une méthodologie de transformation d’entreprise. La première condition est de fournir un cadre de représentation qui couvre tous les aspects de l’entreprise et qui peut donc articuler les expertises et organiser la circulation des idées.

Le positionnement de l’architecture d’entreprise par rapport aux autres disciplines

Comment se positionne l’architecture d’entreprise par rapport aux disciplines transformationnelles[1] ?

La figure ci-dessous tente une première mise en ordre. Le niveau supérieur représente celui des considérations globales, s’appliquant à l’ensemble de l’entreprise. Il s’agit, de plus en plus, d’une fédération d’entreprises, composée de nombreuses entreprises liées par des relations capitalistiques, juridiques, commerciales ou partenariales. À cet étage, un concept pivot est celui de la chaîne de valeur étendue.

Le paysage des disciplines de la transformation (en théorie)

Le paysage des disciplines de la transformation (en théorie)

Conformément à la définition donnée dans l’Enterprise Transformation Manifesto[1], l’architecture d’entreprise se situe à ce niveau, du moins si elle reste fidèle à sa première inspiration.

Stratégie et architecture : une collaboration nécessaire

À ce niveau, l’architecture d’entreprise cohabite avec l’élaboration de la stratégie d’entreprise : non seulement elle reprend les orientations stratégiques pour en déduire les implications, dans tous les aspects de l’entreprise, mais encore elle informe la stratégie sur les opportunités ou les contraintes relatives à l’entreprise ou à son environnement. On pense, bien sûr, aux innovations technologiques à domestiquer pour les mettre au service de l’entreprise. D’autres opportunités peuvent se présenter : innovation organisationnelle, style de management, reconception de l’offre, extension de la chaîne de valeur, etc. Le stratège n’est pas forcément sensible à toutes ces questions. Son regard est surtout tourné vers l’extérieur, le marché, la concurrence… Son horizon est le moyen terme (disons trois ans), voire le court terme (avec les « stratégies glissantes »). Au contraire, l’architecte connaît l’entreprise, il la modélise et la traite comme un système, avec ses finalités, ses propriétés émergentes, ses contraintes et ses possibilités d’adaptation ; il est très conscient de l’inertie de ce paquebot et sensible à la longue durée dans laquelle la transformation doit se déployer. Le dialogue doit impérativement s’établir entre ces deux compétences tout à fait complémentaires :

  • Le stratège donne la direction ; l’architecture en déduit l’esquisse du Système Entreprise à construire.
  • L’architecture identifie le potentiel de transformation ; le stratège cherche à l’employer dans le contexte du marché.

Management stratégique : le discours directionnel

Toujours au niveau de l’entreprise, l’architecture d’entreprise voisine avec le management. Tout naturellement, la relation devrait s’établir avec le management stratégique (disons le PDG), seul capable d’affirmer la vision, d’affermir les volontés et d’impulser la transformation. Qu’est l’architecte sans le prince ? On peut mobiliser Le Brun, Le Nôtre, Le Vau ; sans Louis XIV, il n’y a pas de château de Versailles.

L’architecte apporte le savoir, précise la vision et fournit les plans ; mais la volonté reste dans le management.

Il y a quelque chose d’un peu pitoyable (au sens premier du terme : qui inspire la pitié), à considérer le patron réitérant ses injonctions à innover, ses incantations sur la convergence ou l’orientation client (ou la simplification administrative), sans se montrer capable de remplir le concept. Très vite, dans l’esprit de tous, les formules se vident de substance et il ne reste que des slogans creux. Nul ne saurait reprocher au dirigeant cette situation : le « remplissement du concept » (pour reprendre une formule heideggérienne) n’est pas de son ressort. Mieux vaut voir dans cette situation une défaillance de la courroie de transmission vers les compétences dont c’est le rôle : justement celles de la conception architecturale dans toutes ses spécialités. Or, puisque l’architecture d’entreprise s’est confondue avec l’architecture informatique[2], il ne vient à l’idée de personne qu’elle puisse intervenir pour relayer le discours directionnel – précisément : le discours de la direction et le discours qui donne la direction. Pourtant, quand cette discipline se montre capable de réaliser ses potentialités à travers un exercice correct, elle étaye le discours et précise la vision en décrivant concrètement la cible à atteindre, l’entreprise future à construire.

Management opérationnel : la culture de l’entreprise « transopérationnelle »

Sur ce schéma, le management est positionné à cheval entre la transformation et les opérations. On vise ici le management opérationnel. En effet, l’idée va plus loin que le classique jeu de rôle entre le DG – pilotant les opérations – et le PDG – s’occupant de la vision de l’entreprise future (donc, de la transformation). Dans l’entreprise moderne, un nouvel équilibre doit s’instaurer entre transformation et opérations. Ces activités doivent se mêler plus intimement dans l’entreprise « transopérationnelle », pour que celle-ci s’adapte en permanence et rapidement à un environnement changeant. Ce nouvel alliage seul pourra rendre l’entreprise réellement agile.

Ainsi, même les managers opérationnels et tout le middle-management doivent avoir un pied dans la transformation. À eux de détecter les dysfonctionnements et les opportunités d’amélioration. Ceci suppose une conversion culturelle et une éducation qui contredira les tendances naturelles.

La ligne hiérarchique doit repenser son rôle et ses pratiques, se débarrasser de ses mœurs courtisanes et se penser comme le canal assurant la diffusion accélérée des idées innovantes et des initiatives de transformation, dans les deux sens.

Aujourd’hui, le constat que tout le monde partage, chacun l’exprimant dans ses propres termes, est celui d’un système bloqué, dévoyé :

  • en bas, dans la soute, des opérationnels persuadés qu’ils ne seront pas écoutés et qui ont perdu, de ce fait, la faculté de reconnaître les bonnes idées, quand elles se présentent ;
  • au sommet, des dirigeants qui font la danse de la pluie, qui assurent la représentation, mais qui se sentent impuissants à peser réellement sur le cours des choses.

Cet état s’observe, tant dans la société que dans les organisations. On pourrait y voir un état de civilisation. L’un accuse les jeux de pouvoir, un autre le court-termisme, un troisième l’influence du capital ou de la taille des empires créés par la mondialisation, etc. Les facteurs sont nombreux ; la prise de conscience, étonnamment répandue. Il ne faudrait pas omettre un autre élément, de nature plus psychologique : l’individu, coincé dans sa case, finit par la trouver confortable, il renonce assez facilement à ses velléités d’action, et ne demande qu’à échapper à ses responsabilités. Pour cela, le blocage du système lui fournit un alibi bien commode (voir, par exemple, ce que dit François Dupuy sur les silos. Cf. Lost in management).

Cette logique délétère qui bloque l’entreprise, on n’y échappera qu’en s’appuyant sur le management opérationnel et en l’impliquant fortement dans la transformation. Ceci réclame un choc culturel – électrochoc sur un monstre assoupi.

Architecture métier : le premier moment de l’architecture d’entreprise

Sur la figure, le niveau suivant concerne toujours l’entreprise prise globalement, mais il introduit une séparation entre, d’un côté, le « métier » et, de l’autre, la technique. Cette spécialisation répond à la prise en compte réaliste des limitations humaines : on ne peut pas mettre toutes les compétences dans un même cerveau. L’architecture métier, comme toute architecture, adopte un point de vue global sur le système et assume les préoccupations sur la longue durée. Elle le fait sur une partie seulement des aspects du Système Entreprise :

  • l’aspect intentionnel (les valeurs, les objectifs, les exigences, les indicateurs, les règles, la terminologie) ;
  • l’aspect sémantique (la connaissance, les fondamentaux du métier) ;
  • l’aspect pragmatique (les activités et l’organisation).

Disciplines techniques

Les aspects techniques sont laissés à d’autres disciplines, telles que l’architecture informatique. On distingue :

  • l’architecture logique, élaborant la structure souhaitée pour le système technique (informatique comprise) ;
  • l’architecture technique, explorant les possibilités technologiques et les combinant pour traduire la spécification logique en un système qui fonctionne ;
  • l’architecture physique qui s’intéresse à l’infrastructure, au déploiement et à l’exécution des moyens techniques.

Architecture et conception

Le troisième niveau de la figure correspond aux disciplines de portée locale, c’est-à-dire, presque toujours, celles qui s’investissent en mode projet. L’architecture est là pour canaliser cette énergie, de façon à avancer plus rationnellement et plus rapidement dans la construction du système. À ce niveau, du côté du métier, se situe la Business Analysis, discipline bien constituée qui dispose de ses instances représentatives et de son référentiel. Toujours par fidélité naïve à la langue, on peut se demander pourquoi il n’existe pas une discipline Business Design, pendant créatif de la Business Analysis. Cette absence entraîne des conséquences : la faible capacité à innover dans le métier.

Du côté technique, l’arbre des disciplines se ramifie bien plus, du fait de la complexité des sujets et de la variété des expertises.

Architecture d’entreprise : par voie de conséquence

Après ce petit essai de mise en ordre des disciplines, l’architecture d’entreprise apparaît sous un jour nouveau. Nous la découvrons comme le lieu où tout converge. Plutôt qu’une spécialité pointue investissant tel ou tel aspect, elle est la capacité à concilier les différents points de vue et à garantir l’unité de la vision. Elle doit tenir, d’une même main, les rênes des disciplines de conception du Système Entreprise. Elle doit guider l’attelage, dans la direction fixée par le stratège. Sa responsabilité consiste à assurer la cohérence du projet de transformation.

Sans cette fonction, beaucoup d’énergie et de talents seront gaspillés ; beaucoup d’opportunités manquées.

L’architecture d’entreprise doit assurer la circulation des idées, en mettant en œuvre une approche holistique de l’entreprise.

Évidemment – l’expérience le montre assez –, la position centrale, de surplomb, présente des risques, dont celui de la tour d’ivoire. Il importe que le travail d’architecture d’entreprise ne s’arrête pas à quelques généralités, assorties de vagues schémas ou de présentations simplistes et démagogiques. Le mot « architecture » doit être pris dans son sens fort : le travail commence par une esquisse, certes, mais à la fin, le bâtiment doit tenir debout et se prêter à tous les usages prévus. On ne peut atteindre cet objectif qu’avec le secours des techniques de modélisation, car elles apportent le niveau de précision nécessaire ainsi que les règles formelles par lesquelles l’architecte peut vérifier la validité de sa conception. Avant cela, le premier instrument est le cadre de représentation : il donne la topologie de l’entreprise, nécessaire pour ordonner les sujets à traiter et pour distribuer les responsabilités, toutes disciplines confondues.

Article en format pdf : PositionnementEA

[1] Cf. www.enterprisetransformationmanifesto.org.

[2] Voir le billet « Le PDG est le premier client de l’architecture d’entreprise…(en théorie) » sur LinkedIn ou sa version étendue « Comment promouvoir une démarche d’architecture d’entreprise ? », sur le site web de Praxademia.

[1] Nous nommons « transformationnelles » les disciplines impliquées dans la transformation des entreprises.

Comment promouvoir une démarche d’architecture d’entreprise ?

Comment promouvoir une démarche d’architecture d’entreprise ?

La question a été posée par les décideurs informatiques réunis à l’occasion du Petit-Déj’SI®, au mois de mai. Elle a été retenue comme thème de la prochaine séance qui se tiendra le 15 octobre.

Le fait que la question se pose et qu’elle soit posée par des décideurs informatiques révèle déjà beaucoup de choses :

  • tout d’abord, que la discipline d’architecture d’entreprise est interprétée comme ressortissant à la fonction informatique ;
  • ensuite, que sa valeur ne semble pas immédiatement perçue par le reste de l’entreprise (sans doute une conséquence du premier point) ;
  • enfin, qu’il s’agirait de faire un effort – de communication, j’imagine – pour la légitimer, la vendre, la justifier aux yeux du monde.

En tout premier lieu, il convient de préciser de quoi nous parlons. Qu’est-ce que l’architecture d’entreprise ? Je suis désolé de revenir sur cette question que l’on voit fleurir chaque mois sur les forums et qui déclenche, à chaque fois, une avalanche de réactions. Néanmoins, nous ne pourrons pas répondre à la question posée avant d’avoir clarifié son concept central. Pour définir un tel objet, nous devrons d’abord en retrouver l’inspiration originelle, puis le positionner par rapport aux autres disciplines. Armés de la définition, nous pourrons reprendre la question.

L’architecture d’entreprise, en théorie

Personnellement, j’aurais tendance à faire confiance au langage (plus qu’aux Hommes, et tant que les Hommes n’auront pas trop abîmé le langage). Dans l’expression « architecture d’entreprise », il me semble reconnaître le mot « entreprise ». S’il s’agit d’une discipline, son objet doit donc être l’entreprise, dans son entier. Certes, le besoin est patent d’une discipline qui soit capable d’embrasser toutes les composantes de l’entreprise, tous ses aspects, afin de les articuler et de faire circuler les idées entre les silos d’expertise. Ce qui est en jeu n’est rien moins que la capacité à innover et à transformer l’entreprise.

Ensuite, nous avons le mot « architecture ». Bien sûr, il apparaît ici dans un usage métaphorique. La métaphore de l’architecture n’est pas nouvelle : nous la convoquons à chaque fois que nous voulons mettre en avant la maîtrise et la conception consciente de la structure. Elle a cours, depuis toujours, dans le milieu de l’informatique. Elle y prolifère même : architecture matérielle, architecture logique, fonctionnelle, applicative, logicielle… architecture d’un compilateur, etc. Une vache y perdrait son veau, et un curé son latin ! (NB : il y a beaucoup de grec, là-dedans)

Faisons simple :

L’architecture d’entreprise est la discipline qui prend l’entreprise comme un tout, et qui élabore, consciemment, consciencieusement, sa structure.

L’architecture d’une entreprise en est le résultat. Ne confondons pas le livrable « dossier d’architecture de l’entreprise » avec ce résultat : l’entreprise même, construite, transformée, régénérée, selon la structure qui a été conçue et qui devient sienne. Les plans de l’architecte ne sont pas le bâtiment (la carte n’est pas le territoire, ceci n’est pas une pipe, les médias ne sont pas le monde, etc.). En tout cas, l’analyse de l’expression nous conduit à cette conclusion : l’architecte d’entreprise s’occupe… de l’entreprise !

L’architecture d’entreprise, en pratique

Qu’en est-il en réalité ? Qui se parfume de ce beau titre d’architecte d’entreprise ? Quelle est sa formation ? sa position dans l’organigramme ? sa pratique ?

Il est facile de répondre à ces questions puisqu’une puissante machine de guerre a été mise en place sous la bannière de l’Enterprise Architecture. J’ai nommé : l’Open Group et la certification TOGAF (The Open Group Architecture Framework). On nous dit que quelque 38.000 architectes sont certifiés TOGAF à travers le monde, ceci sans compter les personnes qui ont obtenu leur certificat à partir de versions antérieures, ni celles qui, sans être certifiées, sont fortement exposées au sujet ou y font constamment référence. Même les administrations françaises sont touchées par le phénomène ; on les avait connues plus résistantes à la culture méthodologique américaine.

Donc, la population des « architectes d’entreprise » est facile à identifier, d’autant qu’elle ne manque pas de dispositifs pour s’exprimer : un réseau d’associations dans tous les pays, des centaines de forums dans toutes les langues.

Où les trouve-t-on ? Réponse : sans exception aucune, dans les directions informatiques. Est-ce la meilleure position pour aborder tous les aspects de l’entreprise ? Est-ce que la pratique informatique prédispose à la transformation et à l’ouverture sur les réalités de l’entreprise ?

Concédons que l’on peut se trouver à un endroit de l’organisation et agir ailleurs. Est-ce le cas de l’architecte d’entreprise ? Pas sûr. Nous pouvons aventurer ce constat : l’architecture d’entreprise, en pratique, est l’architecture informatique à l’échelle de l’entreprise. Encore est-ce là le meilleur des cas. Le plus souvent, la dimension « entreprise » n’y est pas. Il n’est, pour s’en convaincre, que de jeter un œil sur les offres de postes. Elles recensent des compétences et connaissances informatiques, voire strictement techniques, et font fi des autres aspects de l’entreprise. Elles décrivent, le plus souvent, une fonction d’expert technique plutôt que d’architecte technique : la maîtrise d’une technique, pas la capacité à assembler plusieurs techniques pour concevoir un système technique.

Pourquoi, alors, ne pas se contenter de parler d’architecture informatique ? Les raisons sont multiples et nous ne les examinerons pas ici (il faudrait aborder l’histoire des termes, le glissement sémantique constant, les stratégies des acteurs, etc.). L’expression « architecte d’entreprise » s’est simplement substituée à celle d’« architecte informatique ». De même, on n’entend plus parler que du « système d’information » et quasiment plus du « système informatique ».

Il est toujours plus facile de changer les termes que les pratiques.

Quand il s’agit des dénominations professionnelles, c’est pire : dans la foire aux vanités, les titres tournent, ronflent et se galvaudent à une vitesse accélérée.

Ces manipulations langagières ne seraient pas si graves si leurs effets se cantonnaient aux éternels et minables calculs d’intérêt et luttes corporatistes. Mais ce phénomène d’érosion sémantique met en danger le langage, comme outil de représentation et de communication. Parfois, il menace l’avenir des concepts. C’est tout à fait le cas avec l’architecture d’entreprise. Qui aperçoit encore, sous cette appellation, le concept décrit ci-dessus ? Certes pas les dirigeants. En effet, tentons un rapide sondage : demandons aux dirigeants ce que leur évoque l’expression « architecture d’entreprise ». Combien imagineront que cela puisse être autre chose que de l’informatique ? Lesquels, parmi eux, se diront que cela les concerne ? Alors que, justement, le concept initial est une réponse à la situation d’urgence des entreprises et un puissant levier pour leur transformation.

Les entreprises réclament – de toute urgence – une approche holistique, sans laquelle la transformation n’est qu’un vain mot, un songe creux.

Les dirigeants en sont les premiers demandeurs. L’architecture d’entreprise, prise au sens fort, répond justement à cette attente. Comment donc la nommer, maintenant que l’expression « architecture d’entreprise » a été saccagée ?

Faute de mieux, nous continuerons à utiliser cette expression, en l’entendant dans son sens fort. L’ Enterprise Transformation Manifesto repose entièrement sur cette notion et cherche à déployer son ambition et à illustrer son potentiel, dans les termes des décideurs : transformation, valeurs, politique, innovation, responsabilité… Il n’omet pas la technologie, dont l’importance dans la transformation ne saurait être minorée, mais il l’associe aux autres contributions nécessaires pour élaborer une vision complète.

Synopsis of the Enterprise Transformation Manifesto

Synopsis of the Enterprise Transformation Manifesto

En conclusion, j’adopte cette définition, due à Thierry Biard :

« L’Architecture d’Entreprise permet de concevoir, du métier à la technique, l’Entreprise dans tous ses aspects. »

Le terme « aspect » a, ici, un sens très fort. Il renvoie au cadre de représentation proposé par Praxeme, la Topologie du Système Entreprise.

Article plus complet : PromouvoirDemarcheAE (pdf)

Lancement de la certification Praxeme “Fondations”

Praxademia a animé une session de sa formation “Compétences Praxeme”, du 15 au 17 septembre. Les supports avaient été révisés pour assurer la conformité avec l’examen pour l’obtention du certificat “Fondations”.

Tous les participants ont passé l’examen avec succès.

Voir sur le site du Praxeme Institute.

 

 

La Senior-Team pour vous aider dans vos transformations

La Senior Team (ou S-Team) est une équipe coordonnant les expertises pointues dont vous avez besoin pour maîtriser vos transformations d’entreprise.

Elle rassemble des personnes expérimentées, capables de mettre en synergie leurs expertises grâce au cadre méthodologique Praxeme.

L’expérience coordonnée, mise à votre service…

Voir: