Mais les résultats de ces démarches sont très hétérogènes. Définir des processus n’est pas une fin en soi et il faut continuellement en vanter les apports. Comment gagner en légitimité auprès des opérationnels et du management ? Quel timing adopter pour réussir les déploiements ?

Avancer pas à pas pour atteindre les objectifs

Une énergie considérable est nécessaire pour définir des pratiques idéales, conformes à l’état de l’art et aux besoins. Cet effort est souvent réalisé au détriment d’une réflexion sur l’applicabilité effective des processus. À l’inverse, chercher à adopter une démarche rapide top-down  de transformation des processus peut avoir pour effet de frustrer les opérationnels en les privant d’un temps de compréhension et d’apprentissage.

Par ailleurs, les « bibles » de référentiels de processus sont rarement consultées et souvent complexes à comprendre. Aussi, s’il faut déterminer une cible idéale, il ne faut pas perdre du temps à l’élaborer dans ses moindres détails. Progresser en « gagnant du terrain » est déjà un bon objectif.

Il est donc conseillé d’appliquer 3 règles d’or :

• Définir un socle d’exigences pour lesquelles le management doit être intransigeant.
• Laisser une marge d’adaptabilité aux besoins spécifiques et promouvoir une démarche collaborative d’amélioration continue du processus.
• S’assurer que les processus sont atteignables c’est-à-dire compris, applicables et mesurables.

Le résultat de déploiements de processus se mesure ainsi par l’atteinte d’améliorations concrètes sur le terrain.

Une gestion de projet par exemple n’est pas conçue de façon identique qu’il s’agisse d’infrastructures ou d’applications. Cependant, le socle de pratiques communes peut se limiter à la définition de l’ossature commune du processus ainsi que l’intégration de normes imposées par le contrôle interne ou encore la sécurité. L’application du processus encourage ainsi les travaux transverses et permet aux acteurs de s’assurer de respecter l’ensemble de la règlementation.

Réussir la conduite du changement, c’est aussi s’assurer que les acteurs savent et peuvent faire ce qui est leur est demandé. Aussi, il est essentiel de mener une réflexion parallèle sur le déploiement des bons outils permettant d’appliquer et de suivre le changement. Un outil de gestion de projet et de portefeuille par exemple doit non seulement offrir des opportunités d’amélioration du processus mais aussi agréger des données pour mesurer l’activité de la DSI. Les indicateurs permettent aussi de s’assurer du soutien managérial nécessaire dans la durée.

Poser la gouvernance après les premières évolutions

Cette approche des « petits pas » se fera au détriment de l’impact que peut avoir un grand projet marquant les esprits. Il faut compenser cela par une communication claire et régulière sur les objectifs et les acteurs. Pour ne pas perdre de crédibilité au gré des déploiements qui se suivent et des processus qui ne sont pas définis dans leurs moindres détails, la démarche d’amélioration continue des processus doit être partagée et admise par tous.

L’équipe processus transverse chargée de faire vivre cette transformation dans la durée doit donc affirmer son identité, animer la communauté d’un tissu de contributeurs et intégrer aux travaux les acteurs les plus influents et ceux ayant développé des « outils maison ». Il est d’ailleurs conseillé de commencer par fédérer autour d’un processus concernant plusieurs acteurs sur plusieurs sujets comme la gestion des demandes clients et d’investir dans des moyens de communication à décliner pour chaque déploiement (newsletters, outils collaboratifs, livrets synthétiques imprimés, etc.)

Avec sa montée en notoriété progressive, « l’équipe processus » devient naturellement un centre de services pour les entités ayant besoin d’un appui sur le sujet. Lorsque les premiers déploiements ont fait leurs preuves, son intervention devient naturellement indispensable pour la légitimation de l’ensemble des initiatives et la garantie de prise en compte des aspects transverses.

La démarche processus s’ancre progressivement dans les pratiques. L’élaboration d’un référentiel de processus, d’une cartographie et de normes de formalisation partagées devient alors nécessaire pour maîtriser les transformations et leurs impacts.

Le déploiement de processus communs n’est effectivement pas une fin en soi mais la mise en commun de moyens, de pratiques et d’outils de mesure permet la production d’indicateurs transverses et un pilotage plus fin de l’activité. À ne pas négliger donc.

Cet article Évolution par les processus : quelles clés pour réussir ? est apparu en premier sur RiskInsight.

 Familles d’écueils rencontrés

À cela, plusieurs raisons concomitantes.

Il n’existe en général pas un, mais plusieurs, référentiels d’architecture (les architectures applicatives et fonctionnelles dans un premier référentiel, l’architecture technique dans un second référentiel via une CMDB).

Par ailleurs, de trop nombreux acteurs sont impliqués dans la vie de ces référentiels : urbanistes, architectes SI, architectes de domaine, architectes projet, exploitants…, diluant de ce fait les responsabilités.

Enfin, les processus de mise à jour du référentiel ne font souvent pas partie du cycle de vie projet. Seul le bon vouloir des différents acteurs garantit le maintien d’une information à jour et de qualité.

 Usages d’un référentiel d’architecture d’entreprise

Cependant, disposer de référentiels à jour et exhaustifs contribue efficacement aux principaux projets SI.

Dans le cadre d’évolutions des postes de travail, connaître le parc des applications (application client léger, application client lourd, etc.) s’avère nécessaire pour définir la politique de migration.

De même, les projets d’évolution de l’infrastructure doivent forcément s’accompagner de l’étude de l’impact sur le parc applicatif.

L’utilisation de référentiels facilite également la phase d’analyse de l’existant préalable à toute étude dans le cadre d’évolutions métiers.

Il est aussi indispensable de connaitre l’impact applicatif et fonctionnel et de le présenter aux métiers concernés dans le cas de l’externalisation d’un domaine technique.

Enfin, pour garantir l’industrialisation des solutions et donc la réduction des coûts, la mise en place de standards architecturaux est un impératif.

 Un contenu bien ciblé

En termes de contenu, plusieurs éléments sont à prévoir :

• L’ensemble des cartographies du SI : fonctions SI, applications, services applicatifs, éléments techniques (tels que les services techniques, les infrastructures…). Les cartographies de l’existant constitueront une première étape, qu’il conviendra d’enrichir avec une vision plus prospective.
• Le catalogue des solutions applicatives et techniques référencées : ensemble des composants validés et recommandés par la DSI pour constituer les réponses SI aux besoins métiers ou techniques.
• Les différents patterns d’architecture : typologies d’architecture à mettre en place afin de répondre aux besoins SI.

 Facteurs clés pour une implémentation réussie

Grande question que celle du niveau de granularité des informations contenues dans ces référentiels d’architecture d’entreprise. Se noyer dans un niveau trop important de détail est préjudiciable à la pertinence du référentiel et augmente ses chances de ne pas être à jour. A contrario, un manque d’informations peut nuire aux besoins notamment des projets SI et de ce fait n’avoir plus d’utilité.

Quelques recommandations pour profiter au mieux de ces outils au service des projets SI :

Première condition, accepter d’avoir un outillage multiple… mais mettre en place des processus qui garantissent les corrélations et les mises à jour des informations.

Seconde condition, lancer les premiers chantiers sur un sous-ensemble cohérent (architectures applicative et technique ou architectures fonctionnelle et applicative).

Enfin, dernière condition de succès, travailler à l’insertion du process de définition de l’architecture dans le cycle projet (a minima prévoir les points de contrôle).

A l’heure où les DSI se targuent d’être industrielles, innovantes,… bref, à l’état de l’art, il est temps de mettre en place et faire vivre ces référentiels d’architecture d’entreprise !

Cet article Référentiel d’architecture d’entreprise : vous ne pouvez plus faire l’impasse ! est apparu en premier sur RiskInsight.