BlogBA

L’architecture fonctionnelle en support de l’analyse métier ciblée SI

by Admin BPMS France on 20/02/2018 Commentaires fermés sur L’architecture fonctionnelle en support de l’analyse métier ciblée SI

Extrait de l’ouvrage «Maîtriser les techniques de Business Analyse: Outils et cas pratiques » publié par BPMS et disponible sur Amazon.

Dès lors que la réponse à une problématique comporte une forte composante système d’information, se pose la question de la conception de cette brique. Avec souvent un double enjeu d’évolutivité et d’intégration à l’existant. Pour parvenir à améliorer, au travers de cette refonte, l’agilité globale du système d’information, il est utile pour le Business analyste de maîtriser les principes fondateurs des techniques d’urbanisation qui ont inspiré l’approche orientée service (SOA, API) mais peuvent être également utiles pour cibler correctement les outils du marché.

Le découpage urbanisé d’un système d’information s’appuie sur les données

De la même façon qu’un référentiel des processus métier, pour être maintenable dans la durée, doit s’appuyer sur des fondations stables, il n’est pas possible de piloter l’évolution permanente du patrimoine applicatif sans référence à un fonds de carte tout aussi stable.

Ce qui, côté métier, correspond à une cartographie des processus indépendante de l’organisation trouve son pendant, côté SI, dans la carte fonctionnelle. Qui pour être pérenne doit être correctement structurée.

C’est le but de l’architecture fonctionnelle que de proposer un fonds de carte stable sur lequel on pourra plaquer les évolutions successives du patrimoine applicatif : celui-ci pourra également servir à mesurer la redondance applicative (plusieurs applications couvrant le même périmètre fonctionnel) ou à anticiper les contraintes d’intégration d’un nouveau composant.

[…]

Comment parvenir à un découpage pertinent d’un domaine fonctionnel ?

Commençons par identifier ce qui ne fonctionne pas :

–       découper selon les fonctionnalités. Rien ne ressemble plus à une fonctionnalité de contrôle de la paie qu’une fonctionnalité de reporting commercial et pourtant factoriser cette fonction aurait probablement plus d’inconvénients que d’avantages ;

–       découper selon les périmètres des outils du marché : la stratégie des éditeurs est souvent de sortir de leur cœur de métier pour étendre leur zone d’influence et aboutir à des périmètres qui sont évolutifs et ne répondent pas forcément à une logique de cohérence forte.

À l’inverse, d’où viennent généralement les causes d’échec des projets informatiques ? Rarement d’un problème de couverture fonctionnelle : il est souvent possible d’enrichir le progiciel. Plus souvent d’un problème de structure de données.

C’est donc logiquement en regroupant par « affinité » les principales données à gérer (on parle généralement d’objets métier) que l’on arrive progressivement à structurer de manière pérenne la cartographie fonctionnelle.

Prenons l’exemple du domaine Ressource Humaines qui se caractérise notamment par le caractère personnel des données gérées des salariés. On trouvera en son sein deux sous-ensembles répondant à cette logique de cohérence forte :

–       un premier ensemble de données ciblées paye (le côté administratif du domaine) : contrat – échelon – paie – cotisations – statut

–       et un second ensemble plus ciblé compétences (le côté développement des ressources humaines) : compétences, formation, certification, parcours professionnels, diplôme,…

Même s’il y a des liens entre ces deux ensembles, qui justifient d’ailleurs leur appartenance au même domaine RH, il est légitime d’attendre qu’une évolution fonctionnelle dans l’administration de la paye soit sans impact sur la « gestion des talents » et inversement. Nous avons bien identifié deux sous-ensembles en couplage faible.

La structuration normalisée d’un SI urbanisé

Appliquées au périmètre de chaque domaine ainsi identifié, les bonnes pratiques d’urbanisation imposent notamment un découpage sur 3 ou 4 niveaux (zone-quartier-îlot–bloc) et une identification systématique de certaines zones :

–       la zone Echanges externes, qui matérialise les échanges de données avec les autres domaines, est un élément essentiel pour anticiper les contraintes d’intégration ;

–       les zones Données et Référentiel qui isolent les données de base de celles qui les encadrent et nécessitent donc une gestion particulière de leur cycle de vie ;

–       une zone Pilotage qui couvrira la dimension Tableaux de bord / requêtes mais aussi les alertes ;

–       une ou plusieurs zones « Métier » (et non pas une zone d’Opération unique si on ne peut justifier de sa cohérence forte) ;

–       enfin une zone Support pour rassembler les services support que l’on retrouve au sein de chaque domaine (sécurité, ergonomie,…).

Cette carte de haut niveau normalisée est désormais prête à être utilisée par le Business analyste pour structurer la liste des exigences solution.

Elle pourra également servir à la DSI pour positionner les logiciels déjà déployés dans l’entreprise, un même outil pouvant se retrouver dans différents domaines. La même carte peut être utilisée pour positionner les outils du marché sur le périmètre fonctionnel de l’étude.

_________________

Les prochaines formations sur l’architecture fonctionnelle que j’aurai le plaisir d’animer se dérouleront les 27-28 mars et les 16-17 juillet 2018.

Admin BPMS FranceL’architecture fonctionnelle en support de l’analyse métier ciblée SI