Un constat pour le moins mitigé

Malgré les évolutions technologiques, il reste toujours difficile d’insérer correctement une application métier dans le système d’information d’une entreprise. Cela est en partie dû au fait que les métiers souhaitent souvent aller au-delà de leur attribution en ne s’intéressant pas uniquement au « Quoi ? » mais aussi au « Comment ? ». Cet état de fait provient d’une sorte de « syndrome du métier roi », qui peut conduire à des extrêmes comme la mise en service d’applications sans que la DSI soit prévenue (le shadow IT). Cela peut notamment être le cas lorsque les règles et processus ne sont pas jugés pertinents ou trop lents par le métier.

En conséquence, de nombreuses spécificités apparaissent et ne sont pas toujours résorbées : non-respect des normes internes et réglementaires, non-utilisation des infrastructures et offres de services présentes, perpétuelle « réinvention de la roue » …

Ce phénomène implique des pertes de temps et des surcouts qui pourraient être évités. Il implique aussi des risques pour le bon fonctionnement et la sécurité du SI car la maitrise des applications est moindre.

Tout d’abord, cadrer

La mise en place d’un cadre clair et cohérent décrivant le SI est un prérequis fort de la bonne intégration des applications métiers dans le SI. Il doit être conçu pour s’appliquer également aux applications métiers basées sur des composants physiques industriels.

Ce cadre s’appuie sur la rédaction de politiques, que ce soit pour les infrastructures (positionnement des applications, gestion de la disponibilité, piles systèmes et logicielles préconisées …), pour le réseau (règles de raccordement, gestion du dimensionnement des échanges …) ou pour la sécurité (gestion de la confidentialité et de l’intégrité des données, gestion des authentifications et habilitations …), avec en particulier l’analyse des risques associés aux données et à leurs traitements. L’inclusion du cadre réglementaire et légal (réglementations informatiques et libertés, loi de programmation militaire …) est nécessaire.

De même, toutes les infrastructures et les services qu’elles rendent doivent être présentées sous forme d’offres de services, incluant les contraintes d’acceptation et dès que possible, les couts et délais associés à leurs utilisations, d’autant plus si le système s’oriente vers une approche micro-services et repose sur des API.

Tous ces éléments doivent être intégrés dans le schéma d’urbanisme du SI.

Une fois défini, le cadre est à dériver sous forme de toolkits permettant aux métiers d’identifier rapidement leurs besoins, afin d’intégrer les contraintes associées dans leurs pré-études et leurs appels d’offres.

Puis, fonctionner en mode processus

Le cadre mis en place doit s’accompagner d’un ensemble de processus facilitant la conception et la mise en place des applications métiers.

Les processus accompagnant la conception applicative sont, de loin, les plus importants, puisqu’ils amènent aux architectures applicatives à déployer. Ils doivent intégrer, dès les premières phases, l’exploitant ainsi que les équipes gérant le réseau et la sécurité du SI, qui sont amenés à faire partie de l’instance de validation des architectures applicatives.

Dans un cycle projet traditionnel, il est préférable de découper l’étude et la validation de l’architecture des applications en deux parties.

La première partie, doit traiter l’architecture fonctionnelle uniquement. Celle-ci commence par la fourniture des besoins par le métier : population cible, données utilisées et traitements associés. Une étude de ces besoins vis-à-vis du cadre défini permet alors de déterminer les contraintes imposées à l’architecture et les offres de services pouvant répondre au besoin métier. Cette étude passée, l’architecture fonctionnelle peut être définie par le métier et validée par l’instance de validation des architectures applicatives.

La seconde partie, qui s’intéresse à l’architecture technique, favorise l’utilisation des offres identifiées précédemment. L’architecture proposée peut enfin être validée en impliquant dans cette décision les responsables des offres de services retenues.

Et le plus important… faire appliquer !

La mise en application du cadre et des processus associés est à faire étape par étape.

Il convient, en premier lieu, d’identifier au moins un correspondant métier au sein de la DSI moteur et connaisseur de l’organisation, afin de tester et de rôder le cadre et les processus. Une fois ce premier test effectué, il peut être étendu au sein de la DSI, en commençant sur une base de volontariat, et ce, avec l’appui du DSI.

La dernière phase, l’extension du processus à l’ensemble des métiers, est plus complexe en ceci qu’elle nécessite un sponsor au sein de la direction générale permettant son application.

Cette mise en application peut être facilitée par une communication régulière aux différents interlocuteurs sur les gains en termes de cout et de délais associés à l’application du cadre et des processus et par la priorisation des projets les appliquant par rapport aux projets réticents (« politique de la carotte et du bâton »).

Enfin, tout au long de cette mise en place, il est nécessaire de prendre en compte très rapidement tout retour.

Les outils clés

Afin d’assurer la réussite du processus, celui-ci doit être accompagné d’un certain nombre d’éléments.

Les offres de services doivent donner la priorité au respect des standards et contraindre le sur-mesure à des études supplémentaires. Chaque « standard » d’une offre de service est à associer à un template de configuration permettant de limiter les couts et délais de préparation des environnements des applications, ainsi que les couts d’exploitation, mais aussi de limiter le risque d’incidents par la maitrise de la configuration. La mise à disposition de modèles types de supervision des services applicatifs est également un point à ne pas négliger.

Le processus de demande de mise en place d’une architecture validée doit être le plus simple possible pour le métier, le nombre d’informations, minimisé, et la complexité sous-jacente à la demande, masquée. Au besoin, cela passe par la mise en place d’une entité chargée de traduire rapidement une demande de mise en place ou d’évolution de l’existant issue du métier en un ensemble de demandes techniques ciblant les besoins (installation de serveurs, mise en place de machines virtuelles, configuration réseau, ouverture de flux, configuration des équipements de sécurité applicative …).

L’objectif est de rendre attractif le suivi de l’offre standard en le rendant plus simple, plus rapide et moins couteux.

Il ne faut par contre pas bloquer la spécificité si elle ne remet pas en cause le bon fonctionnement ou la sécurité du SI. Elle peut en revanche être plus longue et plus couteuse à insérer, cela se justifiant par les études permettant sa bonne intégration.

Cadrer l’historique pour poser les bases du futur

La bonne gestion de l’insertion d’une application dans un SI passe par un cadre clair et partagé de tous, des processus et outils simples et acceptés, un accompagnement de proximité, facilitant la vie des responsables d’applications jouant le jeu des normes propres SI et reportant le cout de toute complexité sur le métier responsable, sans bloquer les spécificités.

Et ce mode de fonctionnement, bien adapté à une gestion classique des développements applicatifs, peut être une base pour entamer des réflexions sur le mode agile où la définition d’un cadre et la priorisation de l’utilisation des standards restent de bonnes pratiques.

Cet article De la bonne insertion d’une application métier dans le SI est apparu en premier sur RiskInsight.

Des processus définis mais rarement bien déployés

La phase de définition des processus nécessite une énergie importante. S’ils sont généralement bien définis avec par exemple des kits de communication, ces derniers ne sont en revanche que partiellement déployés. Or, la phase de déploiement mobilise une énergie au moins aussi importante que la phase de définition.

Les DSI sont aujourd’hui bien dotées d’équipes de processus transverses. Mais celles-ci n’arrivent toujours pas à gagner en légitimité et à mobiliser les équipes opérationnelles, générant ainsi des pratiques hétérogènes.

Élargir au maximum le réseau d’acteurs au sein de la DSI 

Les équipes de processus transverses ont l’habitude de définir les premières briques du processus mais sans impliquer les opérationnels. Ces mauvaises habitudes engendrent une réelle complexité à le déployer. Celui-ci peut même être parfois rejeté par les équipes.

Impliquer des représentants d’opérationnels, en ciblant les plus impactés par le processus, s’avère ainsi nécessaire dès le début du projet. L’enjeu est alors de pouvoir répondre aux interrogations suivantes : quels enjeux opérationnels se cachent derrière la mise en place ou la revue du processus ? Quels sont les bénéfices financiers attendus ? Quelle est notre ambition et quels moyens mettre à disposition des acteurs pour atteindre les objectifs définis ?

Les premiers échanges avec les acteurs sont précieux. Il s’agit là de créer le premier cercle de votre réseau de processus. Par la suite, ce premier cercle travaille sur une première conception (formalisation, identification des acteurs et des rôles / responsabilités associés, ainsi qu’une précision des outils nécessaires).

Après cette première définition, il est nécessaire de présenter cette première version à d’autres acteurs de la DSI. Cette action a un double enjeu : challenger le processus défini et réaliser une première communication autour du processus. Rester à l’écoute de tout acteur et prendre en compte les remarques pertinentes permet de concevoir un processus en phase avec les attentes et besoins des opérationnels.

Ajouter ses « amis  métiers » dans le cercle de définition… et avoir un ami proche avant de déployer

Afin de donner plus de légitimité au processus défini, des présentations régulières auprès d’acteurs métiers peuvent être réalisées. Ainsi votre cercle continue à s’élargir tout en assurant une bonne précision des travaux réalisés. A ce stade, de nouveaux ajustements peuvent être apportés suite aux retours de ce réseau. L’implication du métier est un des leviers de motivation des acteurs de la DSI dans le déploiement des processus. Il reste à vérifier que le processus est bien adapté au terrain.

Quand cela est possible, il ne faut pas hésiter à déployer sur un périmètre restreint (site pilote). Il s’agit de la dernière étape pour apporter les derniers ajustements et assurer une prise en compte des retours terrain avant le déploiement. Ce travail privilégiant un périmètre limité permet de mettre en évidence les bénéfices réels et les éventuelles difficultés rencontrées. Un bilan est à faire à l’issue du pilote et à partager avec l’ensemble du réseau de votre processus

Par cette démarche, l’ensemble des acteurs ont pris connaissance du processus, ont pu mesurer les bénéfices et éventuelles difficultés grâce au site pilote. Ils sont maintenant prêts à le mettre en œuvre. Une bonne implication des opérationnels les plus concernés dès les premières phases de définition du processus  ainsi qu’un réseau large impliquant d’autres acteurs de la DSI et Métiers facilitera et œuvra à la réussite du projet.

Insistons néanmoins sur le fait qu’une mise en place de processus ne se limite pas à son déploiement. La gouvernance associée au processus et le dispositif d’amélioration continue sont également à définir avec deux rôles clés : le process owner et le process manager. Deux rôles fondamentaux pour asseoir une relation DSI métiers de qualité.

Cet article Les processus : réseauter pour mieux déployer ? est apparu en premier sur RiskInsight.

Dans un précédent article, nous évoquions l’importance d’une bonne relation Métiers-DSI, sachant qu’un ensemble de leviers centrés autour de la valorisation du capital humain peuvent être actionnés.

Dans ce cadre, nous avons identifié sept rôles clés à installer ou à renforcer dans les organisations, tant côté Métier qu’au sein de la DSI. Ce sont la qualité et l’efficacité de leurs interactions directes au quotidien qui vont concrétiser et rendre visible l’apport de valeur de l’IT.

Deux rôles pour garantir l’apport de valeur IT

La performance opérationnelle et économique de la majorité des entreprises repose sur la bonne intégration des processus et de l’IT qui permet d’industrialiser les processus clés, tout en garantissant leur évolutivité. Dès l’émergence d’une demande métier associée à des objectifs de productivité interne et/ou un enjeu commercial, il faut évaluer quelle part de réponse peut être apportée soit par l’évolution des procédures métiers soit par l’IT. L’estimation globale des coûts et bénéfices va ensuite conduire à définir le périmètre exact d’évolution à faire porter par l’IT.

Des Business analysts pour améliorer la conception

Dans environ 2/3 des entreprises françaises, l’emploi d’« analyste métier » n’a pas été déployé suffisamment. Il est resté axé principalement sur les compétences de traduction des demandes métier en exigences, et sur celles de rédaction de spécifications fonctionnelles. Les processus métiers ne sont pris en compte que lors de la rédaction des supports de formation utilisateurs dans le cadre de la conduite du changement. Ce mode de fonctionnement montre ses limites. Aujourd’hui, le Business analyst doit être en capacité d’identifier, de clarifier, d’analyser et de documenter les besoins de l’entreprise et la valeur associée. Il travaille à traduire les besoins de l’entreprise en objectifs fonctionnels et techniques, en garantissant la valeur générée. Il participe ainsi à la recherche de solutions innovantes, tant IT que processus, afin de répondre aux besoins Métiers identifiés. Il est donc « en charge de l’efficience des organisations et de l’amélioration des processus, des services et des produits, depuis l’analyse initiale des besoins jusqu’à la conduite du changement ».

Dans cette recherche de solutions maximisant la valeur générée pour l’entreprise, les Business analysts travaillent étroitement avec les concepteurs IT et les métiers. Ces deux rôles (Business analyst et concepteur) sont même amenés à fusionner dans le cas d’équipes agiles ou de progiciels.

Des Business process owners pour garantir la performance des processus

Dans le dialogue avec les Métiers, les Business analysts doivent s’appuyer sur les Business Process Owners (BPO). Ces BPO Métiers ont la responsabilité de la performance d’un processus d’entreprise (mesurée par des KPI). Ils ont le niveau de responsabilité et les compétences pour décider et faire mettre en œuvre les changements nécessaires. Afin d’améliorer la performance opérationnelle, le BPO pourra par exemple proposer de spécialiser une équipe sur une activité, ou bien a contrario de centraliser un ensemble d’activités sur un groupe de collaborateurs. De son côté, le Business analyst missionné sur une demande métier sollicitera le BPO pour définir les changements envisageables sur les processus impactés dont ce dernier a la charge. Cette responsabilité de BPO n’est pas à date toujours clairement identifiée dans les entreprises, notamment en raison de la responsabilité transverse qu’elle implique dans le pilotage de processus impactant plusieurs directions. Dans le cas où les BPO n’existent pas, les Business analysts auront un rôle accru. C’est sur eux que reposera la constitution d’une vision transverse des besoins et des processus impactés. Ils devront être force de proposition sur le bon équilibre d’évolution en termes de processus et d’IT.

Deux rôles pour intégrer la voix des utilisateurs dans la chaîne de valeur IT

La multiplicité des offres et l’interpénétration des canaux de la relation client se traduisent par une complexité accrue des postes de travail utilisateurs, non seulement en front-office mais également en back-office.

Leur environnement évolue régulièrement suite à des demandes qui s’enchaînent et s’entrecroisent, venant des directions commerciales, marketing, juridiques, financières… Inévitablement, il devient de plus en plus difficile de garantir une ergonomie des positions de travail permettant une exécution performante des différentes procédures et activités qui sont mises en œuvre au sein de chaque équipe opérationnelle. Cet aspect global est imparfaitement pris en compte dans l’expression des demandes métiers, souvent axées sur des évolutions d’offres et de services. Cela peut parfois aller jusqu’à la dégradation de la performance de certaines équipes et même du climat social, souvent perceptible par les clients finaux. Pour y répondre, les équipes IT doivent intégrer la voix des utilisateurs dans la chaîne de valeur IT afin d’améliorer la qualité de service rendue et la piloter efficacement dans le cadre du partenariat business-IT.

L’objectif est d’aller au-delà de la vision technique du poste de travail et de renforcer la légitimité de la DSI dans la connaissance de la perception terrain des outils mis à disposition dans l’entreprise. Pour cela, il leur faut développer la mesure de la satisfaction utilisateur et les dispositifs qui vont permettre d’identifier et de mettre en œuvre les actions d’amélioration nécessaires.

Des Key users pour incarner la « voix des utilisateurs »

L’identification de Key users côté Métier, au sein des unités opérationnelles de l’entreprise (plateau de vente, agence bancaire…), est primordiale, car ce sont les utilisateurs eux-mêmes qui sont les mieux placés pour identifier ce qui peut leur apporter plus d’efficacité dans leur travail au quotidien. Le Key user, c’est la combinaison entre la vision terrain maîtrisant très bien le métier et la capacité à prendre du recul pour identifier les trucs et astuces qui font gagner du temps. Le rôle du Key user permet de détecter des « signaux faibles », ou « irritants » qui pénalisent la satisfaction utilisateur (trop de copier / coller entre écrans, mise à jour d’une donnée trop tardive pour mener à bien une procédure…). Il est donc impliqué dans des boucles d’amélioration qualité qui vont au-delà d’une sollicitation ponctuelle dans le cadre de recette et d’UAT (User Acceptance Test).

Des Representant users pour porter les attentes des utilisateurs

Le Key user dispose toutefois d’une voix trop faible au sein des équipes IT. Il est donc nécessaire que la DSI lui associe un Representant user, côté équipes IT, qui va qualifier et relayer intelligemment les demandes des utilisateurs en s’assurant qu’elles sont traitées au bon niveau.

Jouant le rôle de Business analyst sur un périmètre « Environnement/position de travail », le Representant user qualifie, centralise, priorise les demandes des utilisateurs et mobilise les bons interlocuteurs afin de les insérer dans les projets/évolutions en cours. Il représente les utilisateurs en phase d’étude et s’assure de la cohérence et de la qualité des formations utilisateurs dans une vision d’ensemble des projets en cours. Il propose les objectifs chiffrés d’amélioration de la satisfaction utilisateurs pertinents sur son périmètre. Sa nomination doit être basée sur les compétences de leadership, d’intermédiation et de communication.

Trois rôles pour garder le cap de l’alignement du SI avec l’entreprise

Les rôles évoqués précédemment ont leur propre valeur. Pour en tirer pleinement parti, il est essentiel de les coordonner à différents niveaux.

Des Client managers pour renforcer la proximité avec les Métiers

Le Client manager incarne personnellement la proximité avec un ou plusieurs métiers clairement identifiés. Il est responsable de la qualité de l’animation de la relation Métiers – DSI et organise les comités opérationnels de suivi de cette relation, tant sur le suivi des investissements que sur la qualité du service rendu. Il est présent au Codir Métier. Il est le point d’entrée de toute nouvelle demande et est fortement impliqué dans le pilotage du portefeuille projet et la construction des schémas directeurs sur son périmètre.

Bien plus qu’un responsable de compte, il représente au sein de la DSI le(s) Métier(s) dont il est l’interlocuteur privilégié et s’assure de l’appropriation de leurs enjeux au sein des équipes IT, grâce à sa double compétence Métier-IT. Il est garant de la cohérence des solutions mises en place pour un Métier donné. Il est force de proposition et facilitateur en cas d’arbitrage à faire valider par le Métier, notamment pour expliquer les coûts de run impliqués par le projet. Il apporte sa vision globale des enjeux métiers aux Business analysts et aux Representant users afin de rendre leurs propositions plus pertinentes. Il s’appuie sur le(s) Service(s) Delivery Manager(s) qui pilotent opérationnellement la qualité des services récurrents et avec qui il définit les orientations à suivre en termes d’amélioration continue (évolution des engagements, plan d’action qualité sur un périmètre applicatif…). Le Client manager occupe généralement un poste de manager des équipes SI pour un domaine métier donné.

Un Chef de projet solutions pour s’engager d’une seule voix auprès des Métiers

Dans la plupart des organisations, la responsabilité d’un projet est portée par trois chefs de projet, l’un métier, le deuxième MOA et le troisième SI / MOE.

Pour autant, l’une des principales difficultés rencontrées actuellement dans le delivery des projets est la dilution des responsabilités entre les différents acteurs mobilisés dans un projet et la déresponsabilisation du ou des chefs de projet nommés côté MOA et MOE. Il est essentiel de redonner du poids à la gestion de projet en nommant un unique Chef de projet solutions, portant la responsabilité MOA et MOE en regard des Métiers et intervenant dès les phases d’étude. Il doit disposer de l’ensemble des moyens (économiques, opérationnels) pour s’engager. Il challenge les besoins et la valeur de la solution identifiée, il dispose d’un pouvoir décisionnel sur les moyens nécessaires pour délivrer la solution et est l’interlocuteur clé pour les Métiers sur le projet qu’il pilote.

Le Chef de projet est aujourd’hui un acteur incontournable dans la relation Métiers-DSI. Il porte la responsabilité de délivrer la solution, alignée avec les demandes relayées par le(s) Business analyst(s) et le(s) Representant users et avec les enjeux métiers relayés par le Client manager. Il est garant du respect des engagements réciproques Métiers et IT dans le cadre du projet et s’assure de la bonne intégration de la solution dans le SI existant et à venir (performance fonctionnelle et technique et optimisation des coûts en build et en run).

Il doit être choisi en fonction de l’enjeu, de la complexité du projet et du niveau d’impact sur le SI. Par exemple, dans le cas d’un projet dont le facteur clé de succès est essentiellement l’évolution des procédures opérationnelles métier, un acteur MOA ou venant du métier pourra être nommé Chef de projet, renforcé éventuellement avec un profil type PMO.

L’Architecte d’entreprise pour garantir l’alignement stratégique et la cohérence du SI

Il faut de plus assurer la cohérence globale des initiatives lancées par chaque Métier d’un point de vue entreprise (stratégie générale et orientations SI) grâce à un rôle clé : l’Architecte d’entreprise. Il intervient en tant que référent de l’architecture IT de l’entreprise et est garant de la cohérence globale de l’évolution du SI avec la stratégie et les processus d’entreprise. Il définit la stratégie d’évolution du SI et avalise les évolutions dans un souci d’alignement. Il est l’animateur de la communauté d’architectes qu’ils soient fonctionnels ou techniques. Il exerce son devoir de conseil en identifiant les solutions transverses pertinentes. Enfin, il est un conseiller avisé des Business analysts et des Chefs de projet solutions et les aide à optimiser leurs investissements dans le respect des orientations stratégiques.

In fine, c’est en renforçant l’ensemble de ces « nouveaux » rôles dans l’entreprise que se tissera pas à pas une relation Métiers/DSI de confiance durable à même de servir toujours mieux la stratégie globale de l’entreprise.

Cet article De nouveaux rôles pour transformer la relation Métiers – DSI est apparu en premier sur RiskInsight.

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.

Une relation MOA/MOE qui montre ses limites

Force est de constater qu’aujourd’hui, la relation MOA/MOE dans les projets n’est pas au beau fixe. Certains métiers préfèrent en effet travailler directement avec la MOE pour garantir une meilleure réactivité et éviter des fonctionnements en mode « passe-plat ». La séparation MOA/MOE entraîne finalement une dilution des responsabilités sur les projets et des difficultés de partage des priorités : un package bancal qui ne permet pas une mobilisation globale efficace. Enfin, ces dispositifs se révèlent inefficaces pour gérer la transversalité entre plusieurs contributeurs. Ils sont également sources de rupture dans les processus projets par les trop nombreux allers-retours qu’ils engendrent.

Par ailleurs, le niveau de structuration de la MOA est proportionnel au niveau d’importance du SI dans l’entreprise. La relation MOA/MOE montre ainsi ses limites dans des secteurs où le SI a une position clé tel que l’assurance ou encore la banque.

Une agilité clé du succès

La complexité de la relation MOA/MOE tient à deux éléments clés : les enjeux métiers et la nature du SI.

Au sein d’une entreprise, les métiers qui ont un enjeu de réactivité important (time to market faible), d’agilité ou d’innovation (multiplication des lancements de produits), auront besoin d’une forte proximité entre la MOE et les métiers. Limiter le nombre d’acteurs au sein des projets parait de ce fait pertinent.

La nature du SI constitue également un facteur d’influence de la relation entre métiers/MOA/MOE. En effet, la fonction MOA est indispensable pour des SI développés en mode « sur mesure » pour les métiers de façon à garantir la prise en compte des spécificités de ces derniers. Pour des SI de type web et surtout de type ERP, une forte proximité entre les métiers et la MOE sera ainsi nécessaire pour optimiser les opérations de paramétrage.

Contrairement à ce que l’on pourrait penser, le couple MOA/MOE doit se définir au niveau de chaque projet et non de la DSI dans son ensemble pour être au plus près des enjeux métiers et tenir compte des natures de SI à faire évoluer.

Réinjecter de l’innovation dans la gouvernance des projets

Au-delà de la « frontière » MOA/MOE, c’est la gouvernance des projets dans sa globalité qui doit être revue.

Il est temps de troquer les habitudes du fonctionnement en cycle en V contre de nouvelles méthodes projets et de nouveaux modes de travail. L’introduction des méthodes agiles ou de développements rapides doit venir enrichir les méthodes projets existantes et être déployée de façon pragmatique en fonction des besoins des métiers et des natures de SI considérés. Par ailleurs, des solutions « multi-canal » demandent à la fois une vision transverse du SI mais également des structures de pilotage avec des responsabilités claires.

Au sein d’un projet, les modes de fonctionnement doivent également être revus pour favoriser la collaboration entre MOA/MOE : par exemple travailler en mode « plateau projet », co-construire  des livrables clés, etc.

Le SI, à l’image du développement des ERP et des progiciels, ne serait-il finalement pas en train de structurer de plus en plus les processus métiers et d’inverser la relation entre les DSI et les métiers ? S’il n’est qu’une seule chose à retenir, c’est que la relation MOA/MOE doit l’anticiper et se réinventer : intégrer plus de flexibilité et d’agilité pour toujours mieux servir ses métiers. Gagner plus d’efficacité dans le delivery projets ne devra néanmoins pas masquer les optimisations nécessaires entre MOA et MOE sur la gestion des priorités.

Cet article MOA/MOE : un couple efficace ? est apparu en premier sur RiskInsight.