Il y a 2 grandes fonctions d’encadrement et de support qui me passionnent particulièrement et dont je parle dans ce blog : l’urbanisation du système d’information et l’approche processus.

Il est intéressant de voir que chaque entreprise possède sa propre manière de combiner ces 2 fonctions.

L’urbanisation du système d’information s’attache à définir, mettre à jour et faire respecter les choix de structuration du système d’information. Ainsi, les équipes d’urbanistes interviennent dans les projets liés au système d’information pour contraindre au respect des éléments définis mais aussi pour apporter de l’aide sur l’intégration au reste du système d’information. Bien entendu, la plupart du temps ce rôle sera vécu comme une contrainte par les équipes projets. Pour un urbaniste, tout est système.

L’approche processus consiste à modéliser, analyser et organiser l’entreprise sous forme de processus. Bien moins contraignant qu’il n’y parait, cette approche est le saint graal de bien des services/départements car elle rend l’activité régulière, compréhensible et prévisible. Pour un business analyst, tout est processus.

Ces 2 approches ont pour objectif commun d’apporter de la valeur à l’entreprise (avec valeur signifiant quelque chose pour le métier : time to market, taux de défaillance…) et d’en simplifier le pilotage (moins d’applications, moins d’interlocuteur, moins d’intervention humaine redondante) et c’est pour cela que l’urbanisation du SI et l’approche processus s’accordent particulièrement bien. Cela consiste à définir les processus des « systèmes de l’organisation ».

Alors, comment faire travailler harmonieusement ces 2 cellules ensemble et avec le reste de l’entreprise ?

Organisation

Dans une organisation orientée projet, chaque projet devrait être dirigé par un chef de projet dont le cadre de travail découle de l’entente entre l’urbaniste (SI) et le business analyst (métier). Si le métier évolue, il est analysé par les business analyst qui déterminent le processus métier à mettre en place/modifier (QUOI / POURQUOI).

L’urbaniste intervient dans la concrétisation du projet et son intégration pratique avec l’existant (COMMENT). Pour moi, il joue aussi le rôle d’architecte d’entreprise. Il n’est pas seulement plongé sur les interfaces SI entre applications mais aussi sur l’implication métier de ses choix.

Tout projet faisant intervenir une modification du système d’information doit impliquer l’urbaniste et son acolyte le business analyst pour qu’ils définissent les conditions et le contexte futur de fonctionnement.

Métier

La fonction de l’urbaniste et du business analyst pourrait se résumé à « Traduire les objectifs stratégiques en actions concrètes dans les projets ». Ces rôles devraient donc être permanent dans l’entreprise – ils ne naissent pas avec un projet et meurent à la fin avec lui.

Je recommande vraiment d’avoir 2 personnes qui se comprennent et qui s’entendent bien.

Je ne pense pas qu’avoir une expérience dans le métier même de l’entreprise soit important : prenez un fabricant de meuble, une expérience opérationnelle dans le métier n’est absolument pas une garantie que le business analyst comprendra mieux le métier. Je pense qu’il veut mieux regarder du côté de la capacité/volonté d’apprendre et de comprendre le véritable métier. L’idéal étant d’avoir identifié un référent métier (le futur propriétaire du processus « business process owner ») qui sera en mesure d’expliquer l’histoire du métier dans l’entreprise.

Personnes

Il est évident qu’il faut les « bonnes » personnes dans chacune des fonctions. Il y a des caractéristiques essentielles qu’il faudra retrouver :

• capacité à manipuler des concepts abstraits
• capacité à communiquer (informer, discuter et convaincre)
• capacité à naviguer dans l’organisation et à comprendre le « véritable » métier (être aussi à l’aise avec le DSI qu’avec un conseiller client et pourvoir apporter à chaque fois des réponses adaptées aux inquiétudes des gens)

La plupart du temps, il n’est pas nécessaire d’avoir de grosses équipes pour occuper ces rôles. Parfois, une seule et même personne peut jouer l’urbaniste et le business analyst dans le cadre d’un projet. C’est quelque chose qui ne me choque pas et pour les raisons que j’ai évoqué, c’est assez naturel.

L’urbanisation du SI devrait donc être une activité permanente et son pendant métier, le business analyst, également. Ces 2 rôles ont une capacité qui devient de plus en plus importante dans les entreprises : celle de rendre simple et compréhensible une organisation en un mot « lisible ». Ils rencontreront des difficultés pour s’intégrer aux projets si la nouvelle donne n’est pas imposée. On préfèrera ainsi avoir le business analyst qui travaille « en parallèle » du projet mais ce type de choix ne donnera pratiquement aucun résultat concret (confirmant ainsi par la même occasion que la plupart des projets SI échouent…).

Vers un meilleur résultat des projets de changement des organisations !

Popularity: 35% [?]

Comme beaucoup de professionnels de mon secteur, je suis convaincu de l’intérêt de l’urbanisation du système d’information.

L’urbanisation, par le niveau de compréhension qui en ressort, est une formidable source d’information permettant de prendre des décisions éclairées et de voir le véritable lien entre le métier de l’entreprise et son système d’information.

La direction de l’entreprise s’en trouve simplifiée et les décisions métiers et IT gagnent en synergie.

La complexité des systèmes d’information est à un niveau jamais atteint, cela rend plus simple la prise de décision.

Cependant dans les projets, sur le terrain et loin des conférences et autres symposiums, les résultats obtenus sont souvent décevants.

Je vais m’attacher au lien entre le projet d’urbanisation et le projet IT de refonte ou de développement dans le système d’information de l’entreprise.

Les difficultés rencontrées :

Tout d’abord chaque projet IT doit affronter les chefs de silo (CDS). Les chefs de silo interviennent pour garantir que leur secteur (ou leur territoire) ne sera pas réduit par le projet. Que l’organisation soit notablement sous forme de silo ou non ne change pas grand chose car dans le fond, les chefs de silo trouvent toujours un moyen de recréer une organisation par silo.

Il faudra donc composer avec eux et surtout arriver à faire collaborer ces chefs entre eux. C’est d’ailleurs en bonne partie pour cela que la recommandation dans tout projet d’urbanisation est que le haut management soit acteur : pour « forcer » les chefs de silo à travailler entre eux.

Ensuite, le projet devra affronter la résistance de nombreux intervenants dont la liste n’est pas très réjouissante.

Le projet d’urbanisation peinera à atteindre des résultats satisfaisants à cause des entraves précédemment listées : les intervenants terrain ne croient pas au projet et n’en attendent rien. La conséquence logique est que l’investissement consenti pour le projet ne donnera pas de bons résultats.

Inévitablement, le projet IT qui en découle sera comme la majorité des projets IT non encadrés : il comportera trop de fonctionnalités qui ne seront basées sur aucun besoin métier et coûtera donc trop cher.

Bien sûr, le projet sera trop gros avec un planning intenable. Cerise sur le gâteau, les indicateurs permettant de mesurer la qualité du projet et sa contribution aux résultats de l’entreprise ne seront pas définis et donc non mesurés ce qui poussera l’équipe projet à livrer à tout prix sans s’attacher aux détails de la livraison (le lien vers la nouvelle application dans l’intranet suffi pour apporter satisfaction non ?).

Comment faire ?

Si l’urbanisation n’est pas la méthode miracle pour faire des projets IT une absolue réussite, sa rigueur permettra surtout de s’attacher aux résultats qu’attends l’entreprise : un changement positif qui apporte une amélioration métier.

La réalité des projets d’urbanisation n’est en fait pas très différente de celle des projets IT. Si le projet d’urbanisation doit apporter un éclairage pratique et fixer les limites des projets IT, il souffre des mêmes contraintes pour une seule raison : il évolue dans le même milieu.

Le milieu est grandement influencé par la manière dont les équipes collaborent et je pense que le type de collaboration entre projets et urbanistes est déterminant.

Il existe différentes manières d’intégrer l’urbanisation aux projets IT.

Les urbanistes sont souvent une entité isolée qui intervient sur les projets à la demande. La plupart du temps ils sont dans leur tour d’ivoire bureau et travaillent en parallèle des projets IT en essayant de produire le plus gros modèle du monde. Selon le niveau d’autorité qui leur ai accordé, ils peuvent opposer un véto au projet si jamais celui-ci ne respectait pas les pré-requis nécessaires pour garder un SI urbanisé.

On les trouve parfois dans l’équipe des business analyst qui décrit les processus métier à mettre en place. Ils bénéficient d’une place de choix puisqu’ils peuvent faire remonter les parties du SI susceptibles de couvrir les besoins métiers étudiés et ainsi concrétiser un mot sacré la réutilisation. Souvent, il s’agit d’une personne détachée de l’équipe d’urbanistes.

Parfois, ils ne sont pas tout à fait identifié et leur intervention sur les projets est mal vue. Ils restent en marge et se contentent de documenter ce qui se passe et d’emettre des « notes de recommandation »…

Je suis intimement convaincu que la position de l’urbaniste doit être dans les projets. C’est là où l’urbaniste prend sa casquette d’archiecte applicatif (si ce rôle n’existe pas) pour aider les projets à s’intégrer au SI. C’est là où le travail de cartographie apporte de la valeur et délivre son potentiel. Il n’en reste pas moins que la nature des projets IT est très diverse et cela rend toujours un peu difficile de coller à une organisation type. Cependant, posez-vous la question : est-ce que mes urbanistes contribuent aux projets IT ? Est-ce que le référentiel des applications (CMDB ou pas) est mis à contribution ? Est-ce que tous les outils à notre disposition sont utilisés pour encadrer le projet ?

Popularity: 20% [?]