Processus, ce terme a fait le buzz en entreprise dans les années 1990 et 2000. La démarche associée promettait de casser les silos organisationnels et y est parvenu dans bien des cas : entreprise horizontale, entreprise en réseau, etc. Aujourd’hui l’approche processus, si elle n’est pas battue complètement en brèche par les démarches agiles, trouve encore une place comme outil d’analyse et de capitalisation de l’organisation.
Les spécialistes de l’agilité portent leurs critiques non sur l’approche processus elle-même, mais surtout sur la façon dont elle est mise en œuvre. En effet c’est bien souvent une démarche centralisée qui est déployée : « nous pensons (les processus) et vous les exécutez». De fait, cela est contraire à l’état d’esprit agile qui cherche à promouvoir la responsabilisation des collaborateurs, à faire rechercher par les équipes des solutions aux problèmes qu’elles rencontrent, etc. Notons bien au passage que dans une telle démarche, le management intermédiaire aussi se trouve dépossédé d’une partie de son leadership. Son rôle est réduit au contrôle de l’exécution des processus.
Quand, dans une organisation basée sur un management par les processus, des modes de management agiles sont déployés sans adapter l’approche processus, on aboutit à des situations schizophrènes, comme l’illustre l’exemple ci-aprèsdans une société de distribution automobile :
La satisfaction client est régie par une série de processus sciemment optimisés à appliquer en fonction des cas. Conscient que c’est insuffisant, la Direction des Ventes demande aussi aux collaborateurs en contact avec les clients de prendre des initiatives lorsque c’est nécessaire. Bien entendu, ces initiatives contreviennent parfois aux consignes prescrites par les processus. Au bout du compte, quand la satisfaction client est bonne (notée par le client via un questionnaire), tout le monde en est gratifié. Cependant, si le client montre une insatisfaction il est reproché au collaborateur soit de n’avoir pas suivi le processus s’il a pris des initiatives, soit d’avoir trop servilement collé au processus …
…c’est bien ce qu’on appelle une situation absurde ! Patatra !
La situation décrite ci-dessus est fréquente et symptomatique des grandes organisations. Il faut être vigilant à ne pas mettre en place des systèmes de management à « injonctions contradictoires », qui conduisent toujours à un retour en arrière (injustice, stress au travail, démobilisation, etc.).
Pour notre part, nous préconisons un usage de la démarche processus qui soit compatible avec les démarches de management agile.
Facilitation graphique – Lean Process
OUI à l’approche processus, lorsqu’elle permet dans un atelier de travail de faire émerger des solutions pour résoudre les problèmes rencontrés par une équipe. L’élaboration du processus en équipe permet aux collaborateurs de se mettre d’accord autour d’un schéma de fonctionnement commun.
Communication
OUI à l’approche processus lorsqu’elle permet d’incarner l’organisation et de porter un message dans les entreprises de grande taille (beaucoup de salariées) ou en forte croissance (beaucoup de clients). Le schéma du processus porte la structuration des activités.
Digitalisation
OUI à l’approche processus lorsqu’elle permet d’identifier les procédures à automatiser (« si c’est processable, c’est automatisable ») tout en expliquant le rôle conservé par les opérateurs.
OUI à l’approche processus lorsqu’elle permet de bâtir le parcours client de designer l’UX (User eXperience) et de s’assurer de la pertinence de la solution, afin d’éviter de déployer des processus défectueux. In fine elle permet de faire dialoguer le Marketing, la DSI et les Directions métiers.
OUI à l’approche processus lorsqu’elle permet de capitaliser les schémas de fonctionnement implémentés (repliés) dans les outils et ainsi de faire face au turnover des équipes. Le schéma du processus est utile pour les équipes informatiques et pour les opérationnels devant résoudre les problèmes rencontrés par leurs clients.
NON à l’exécution aveugle des processus qui bloque l’innovation et bride la performance.
L’agilité redessine les contours d’une démarche processus qui soit un outil au service de la performance. Les initiatives de digitalisation sont une formidable opportunité de rebattre les cartes des modes de fonctionnement opérationnels.
L’Architecture d’Entreprise est souvent vue de manière négative par les projets : effort coûteux, dé-corrélé de leurs contraintes, etc. Pourtant « sur le papier » cette pratique est très ambitieuse et prometteuse. Examinons les conditions d’un recours efficace à l’Architecture d’Entreprise.
Management de projets : tout change, rien ne change
Dans mon parcours professionnel, j’ai croisé et continue de croiser des « maîtres » qui influencent mes approches et mes convictions. L’un d’entre eux disait « le coût de la correction d’une erreur de conception est multiplié par 10 à chaque fois que l’on franchit une étape dans un projet : 1 au moment du cadrage, 10 en conception, 100 en réalisation / test, 1000 après le déploiement (lorsque c’est une fonctionnalité inadaptée qui a été déployée auprès de centaines d’utilisateurs) ». C’était à la fin des années 1990, et on était encore à l’époque sous le règne (finissant) de la méthode Merise.
Depuis, les technologies, la culture de projet et les compétences en ingénierie informatique se sont développées. Il existe aujourd’hui un grand nombre de « briques technologiques » utilisables pour assembler un SI comme un lego, sans avoir à développer spécifiquement chacune des pièces.
Cependant, rares sont les projets qui échappent aujourd’hui encore aux difficultés d’hier. On constate toujours une série de « manques » : manque de vision, de temps, de moyens, de savoir-faire, de discipline, de dialogue, d’analyse des besoins, etc. Plus que jamais, l’adage de mes débuts continue de se vérifier. D’ailleurs l’existence de « briques technologiques » de plus en plus élaborées, ne résout pas le problème d’architecture globale. En effet, on peut construire un truc très moche avec des lego très beaux !
Architecture d’Entreprise : l’art de traiter la complexité
Parmi les pratiques qui permettent de concevoir un SI, l’Architecture d’Entreprise est aujourd’hui celle qui apporte le maximum de garantie. Elle préconise l’extension des pratiques d’architecture du SI à l’ensemble des dimensions de l’entreprise. L’objectif poursuivi est d’éviter de ne penser l’architecture qu’en termes « d’architecture de solution informatique », qui est une réflexion trop restrictive car elle réduit le questionnement à la problématique informatique.
Pour compenser cela, les DSI font parfois intervenir sur les projets des maîtres d’ouvrage connaissant les applications, afin de conjuguer réflexion sur le métier et réflexion sur la solution. Cependant cela détourne souvent le maître d’ouvrage de son rôle : étudier l’opportunité et cadrer les besoins. Il arrive encore qu’on démarre des projets sans savoir s’ils sont vraiment souhaitables et faisables, avec pour seul actif une liste de besoins.
L’Architecture d’Entreprise propose un cadre permettant d’assurer une continuité d’analyse entre les différentes phases du projet. Elle couvre aussi l’analyse d’opportunité en amont des projets. Mais alors pourquoi les problèmes ne sont-ils pas déjà résolus ? Sans doute la démarche est-elle perçue comme complexe à déployer et à s’approprier (c’est l’argument le plus souvent entendu). En effet, le déploiement d’une démarche Architecture d’Enterprise appelle une évolution de l’organisation des démarches d’étude et de projet. Elle doit être portée par une ambition managériale et par la mobilisation des équipes. A défaut on verse immédiatement du côté obscur et l’on ne retient de l’approche que ce qu’elle a de plus hermétique : la méthode … inconcevable quand on manque de temps, manque de moyens, manque de savoir-faire, manque de discipline, manque de dialogue, etc. On finit par oublier le parti qu’on pourrait tirer de cette réflexion pour l’analyse.
Ce n’est pas le marteau qui fait bouger la main, mais l’inverse
Quand cet outil d’analyse est utilisé correctement, de manière pragmatique, on en voit immédiatement la valeur-ajoutée pour les projets. Et ce, sans attendre le déploiement des applications et le verdict des utilisateurs.
Lorsque l’Architecture d’Entreprise est présente dès le point d’ignition du projet (ou avec bonheur, plus en amont encore : lors d’un schéma directeur) elle est à même de porter et fédérer toutes les dimensions de l’analyse et répondre aux attentes des acteurs de la transformation :
Comprendre les enjeux des projets, et leur intérêt par rapport à la stratégie métier, pour donner des perspectives aux projets
Identifier conjointement les impacts pour le métier et la DSI, en animant le dialogue bipartite métier/IT qui soutient la transformation
Pouvoir identifier les ressources et les capacités d’évolution qu’il faudra mobiliser, et vérifier qu’elles sont bien disponibles (à quoi servirait une cible, sans la capacité d’évolution pour l’atteindre ?)
Donner aux équipes concernées les repères communs et partagés qui sont nécessaires pour fédérer les visions personnelles (forcément partielles et partiales)
Livrer les premiers plans ré-exploitables de la cible sous forme de schémas non équivoques, ainsi que des trajectoires appropriées pour l’atteindre
Créer la mobilisation autour du projet en propageant les nouvelles représentations mentales qu’implique la cible
(liste non exhaustive)
En résumé, l’Architecture d’Entreprise fait exister le projet avant qu’il n’existe. Puis elle l’accompagne dans son cycle de vie vers sa réalisation (son accomplissement !). Disposer d’un plan de route pour conduire une transformation est tellement utile lorsque les projets sont stratégiques, transverses et complexes. Faisons-le savoir, comme monsieur Jourdain pour la prose, l’architecte d’entreprise fait du management, sans qu’on le sache ! Mais lui, il le sait.
Une architecture d’entreprise bien conçue est le fruit d’une intelligence collective. Le déploiement des pratiques d’architecture doit aussi être considéré du point de vue humain. Tentative de démonstration en ré-exploitant quelques enseignements de la mobilisation en entreprise.
Pour concevoir et faire évoluer l’architecture du système d’information d’une entreprise, il faut tenir compte de nombreuses préoccupations hétéroclites : métiers, techniques, managériales, financières, réglementaires, etc.
Par leurs efforts, les différents métiers en charge de l’architecture parviennent à définir des architectures cohérentes, alignées avec les différents besoins, à la fois pérennes et évolutives. Une architecture bien conçue est finalement le fruit d’une mobilisation, par laquelle l’intelligence collective opère correctement. Pour aider les architectes d’entreprise, il existe un ensemble de bonnes pratiques permettant de concevoir une architecture adaptée à chaque entreprise, développé depuis plusieurs années. Ces bonnes pratiques sont une extension des pratiques architecturales à l’ensemble de l’entreprise : représenter (modéliser) pour concevoir et partager ; comprendre l’existant pour savoir d’où l’on part ; établir une cible ; établir des bibliothèques d’architectures-types ré-exploitables ; etc.
L’effort d’appropriation de ces bonnes pratiques est souvent focalisé sur la définition des outils de l’architecte (modélisation, patterns, concepts, livrables, etc.). L’appropriation et l’adoption des outils est longue et on la qualifie volontiers « d’évangélisation ». Aussi pertinents ces outils soient-ils, ils ne peuvent pas provoquer la mobilisation de l’intelligence collective à eux seuls. On doit compléter leur déploiement par une série d’initiatives visant à mobiliser les acteurs de l’architecture. Il faut rappeler ce qu’est la mobilisation.
Les différentes formes de la mobilisation
La mobilisation est l’acte intentionnel d’un collaborateur le conduisant à faire des efforts dans le sens d’un travail collectif. D’après Arnaud Bichon, sociologue, on trouve trois formes de comportement de mobilisation, classés par ordre de complexité croissante :
Les conduites relationnelles : ce sont les efforts favorisant la connaissance mutuelle des acteurs et divers types de partage entre eux. C’est le fameux « esprit de corps » des gens du (même) métier qui s’apprécient. Le collaborateur mobilisé est celui qui fait l’effort de tisser des liens, de vivre des expériences avec l’autre. L’inverse, c’est l’individu isolé qui n’engage aucune relation particulière.
Les conduites coopératives : ce sont les efforts spontanés de collaboration, avec des prises d’initiatives dépassant le cadre stricte des obligations. Le collaborateur mobilisé est celui qui travaille délibérément en interaction avec ses collègues et s’implique dans les décisions, qui « partage ». L’inverse c’est la non-collaboration.
Les conduites d’intercompréhension : ce sont les efforts pour construire des représentations communes, comme référence des actions collectives et individuelles. Le collaborateur mobilisé est celui qui développe une vision globale de l’activité contribuant à « construire avec autrui ». L’inverse, c’est celui qui veut rester dans son cadre de référence.
La mobilisation est provoquée selon deux modalités de natures très différentes, qui se complètent :
Un processus managérial de mobilisation (pratiques RH, prescriptives et descendantes, sous forme d’injonctions) visant à déclencher la mobilisation.
Un ensemble de comportements individuels, « autogènes », à l’initiative du collaborateur.
Plus les formes de mobilisation sont complexes (de 1 à 3 dans la liste plus haut), plus elles sont délicates à provoquer, car elles sont discrétionnaires. L’intelligence collective fait partie de celle-ci. Elle fait parfois dire à des patrons d’entreprises que « la collaboration se constate, mais qu’elle ne se mesure pas », comme une déclaration d’impuissance.
Application à l’architecture
Lorsque l’on déploie les outils de l’architecte (modélisation, patterns, concepts, livrables, etc.) on travaille sur une série d’injonctions visant à provoquer l’utilisation de nouveaux outils. A l’opposé d’une démarche par injonctions, pour que l’intelligence opère, il faut agir sur les comportements, afin de créer des réflexes de collaboration. Il s’agit de créer un contexte favorable.
Dans cette perspective, des actions prioritaires sont à mener en parallèle :
Faire reconnaître la pratique de l’architecture dans le cadre de référence RH de l’entreprise. Il paraît difficile de demander au équipes de réaliser des effort sur une discipline qui ne serait pas reconnue comme telle. Cela nécessité une réflexion, car il n’existe pas de cadre de référence publiée sur le sujet. On trouve n variantes sur le sujet « Architecte » dans le domaine SI. C’est dans le cadre de référence RH que l’on pourra définir les fonctions des « Architectes d’Entreprise » et des points de repère pour formuler des objectifs annuels individuels.
Créer une communauté des architectes, pour provoquer les rencontres et les « conduites relationnelles » qui ensuite seront poursuivies dans le cadre des activités courantes. Cette communauté peut prendre différentes formes : petits déjeuners débats réguliers, conférences animées par des intervenants internes ou des prestataires, groupes de travail à thème, outils de partage d’information (le « wiki » des architectes), etc.
Développer l’envie de faire de l’architecture, en recherchant et en agissant systématiquement sur les appétences et les freins des acteurs de l’architecture. On doit pouvoir établir un plan d’action de changement très pragmatique, impliquant les acteurs et leurs hiérarchies, en complément des habituelles réunions d’information. sur l’architecture.
Développer un réseau favorable à l’architecture en identifiant les alliés sur lesquels on peut compter et en leur confiant des initiatives concourant au déploiement de l’architecture.
Je n’ose pas rappeler qu’un soutien, dans les paroles et les actes, de la Direction des Systèmes d’Information, est indispensable pour que l’opération réussisse.
