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: 17% [?]

Lorsqu’il s’agit de modéliser des processus, la plupart des clients vont chercher un outil avec cette question en tête : « quel est le meilleur outil pour faire ce que je dois faire ? ».

Cette question dérive bien souvent vers : « quel est le meilleur outil ? » qui veut bien entendu dire « quel est le plus cher ? ».

Outil ?

Cette tendance très humaine ne doit jamais faire oublier que modéliser n’est pas une question d’outil. Autant la question était primordiale il y a 3 ou 5 ans lorsque le marché était « sous-outillé » et qu’une décision sur ce point pouvait conditionner le succès ou non d’un projet mais désormais de nombreux outils sont très qualifiés.

J’ai pu tester et travailler avec de nombreux outils BPM ou outils de modélisation de processus métier.

Ce que je sais, c’est que les différences sont minimes entre les plus gros outils à tel point que les critéres d’évalutions doivent être très affinés.

L’outil n’est donc plus déterminant (sauf projet technologique particulier, une minorité). Ce constat est aussi valable pour la modélisation de systèmes d’information et l’urbanisation du SI.

L’outil sera quand même la garantie de la pérennité d’un référentiel d’entreprise. On ne compte plus les projets de modélisation basés sur Excel qui n’ont presque jamais servi…

Un outil est donc nécessaire mais pas déterminant.

Conceptualisation

L’une des qualités importantes que doit posséder un modélisateur, c’est donc de conceptualiser. C’est à dire, intégrer de nombreuses informations et arriver à organiser, reconnaître des patterns , et prioriser des idées.

Cette capacité, directement liée à l’hémisphère droit du cerveau, n’est pas à mon sens quelque chose qui se travaille. C’est quelque chose que l’on possède ou non.

C’est ce qui va faire la différence entre quelqu’un qui nécessite 20 minutes d’exposés et de prise de notes et quelqu’un qui reconnait les éléments clés et leurs relations en 5 minutes.

Bien sûr, je caricature un peu la chose, mais vous voyez ce que je veux dire.

Méthodologie

Un modélisateur doit être méthodique. La méthode définie les choses autorisées et interdites dans une modélisation. Elle définie ce que pourront faire les modélisateurs. Son objectif est de garantir une homogénéité dans les modèles et d’assurer un niveau de qualité minimum (en terme de détails de description).

C’est un point bien souvent négligé.

Le modélisateur doit :

- savoir suivre une méthode qu’il n’a pas créé,

- savoir mettre au point une méthode,

- trouver les points faibles et faire évoluer une méthode existante,

- savoir expliquer le point précédent à un client !

Restitution

Si conceptualiser est la première étape, restituer est l’étape finale. Restituer de manière cohérente avec ce qu’il a précédemment fait est une qualité qui ne se trouve pas chez tout le monde.

C’est là où la méthode intervient.

Malgré la méthode, il arrive très souvent qu’une marge de manoeuvre existe. Si le modélisateur est bon, cette marge sera utilisée pour faire du modèle quelque chose de mieux que prévu, sinon ce sera un résultat décevant.

C’est aussi simple que ça. Vous constaterez tout de suite si un modèle « parle » ou s’il nécessite 5 minutes d’explication. Vous verrez la différence entre un modèle « auto-descriptif » et un modèle qui nécessite la présence de son réalisateur pour être compris…

Conclusion

Voici donc un petit aperçu rapide des qualités « techniques » d’un bon modélisateur de processus d’entreprise ou de systèmes d’information. Au-delà de ça, il ne faut pas oublier qu’un modèlisateur sera amené à discuter et échanger avec de nombreuses personnes et que ses qualités humaines sont très importantes.

Il me semble que les modélisateurs sont plutôt des gens qui fonctionne de manière visuelle. Ils privilégient ce canal au lieu du son qui naturellement est moins utile dans ce type de travaux.

Popularity: 4% [?]

SaaS (Software as a Service), tout le monde connait non ?

SaaS c’est le côté business du SOA. C’est la version commerciale packagée pour le marché. En quoi consiste SaaS ?

Le SaaS est un mode de fonctionnement qui dit qu’un prestataire de service va mettre à disposition de son client une application. Si je m’arrête là, j’obtiens de l’ASP (Application Service Provider). L’ASP, bien qu’encore présent, n’est plus développé puisque son succésseur, SaaS promet beaucoup plus de choses.

Saas ajoute une dimension intéressante à l’hébergement d’application. Il permet au client de personnaliser l’application mise à sa disposition. Le client est donc en mesure de bénéficier d’un environnement qui n’est plus standard comme avec l’ASP mais bien d’une plateforme personnalisée, adaptée à son besoin.

Là où le BPM entre en jeu, c’est que l’organisation de processus et la gestion de workflow sont 2 très bons candidats à la mise à disposition sous forme de services. L’idée c’est que beaucoup d’entreprise de type TPE/PME ne disposent pas d’outils de BPM. Souvent dimensionnés pour les grands comptes, les outils de BPM pennent à entrer sur ce secteur (même si des offres comme Windesign sont très intéressantes). Avec le BPM en SaaS, une PME peut bénéficier d’un outil complet facilement.

Elle n’a pas à l’installer, gérer la relation commerciale avec l’éditeur, gérer les machines nécessaires à son exécution. Bien sur, il y a quand même des choses à faire pour mettre en oeuvre un outil de BPM mais l’accès est vraiment simplifié.

SaaS et sa souplesse pourrait donc être un très bon moyen pour une entreprise de mettre en place un projet pilote en automatisant un processus métier. Les limites de l’exercice avec cette approche résident dans le plus gros inconvénients de la solution : la grande difficulté pour s’intégrer avec des applications existantes en local chez le client.

Des solutions de contournement existent mais la mise en oeuvre d’un processus déconnecté du patrimoine applicatif de l’entreprise sera beaucoup plus facile que d’essayer tout de suite d’intégrer l’application de paie historique installée sur le serveur interne de l’entreprise avec le suivi des plannings sous google apps.

Popularity: 4% [?]