C'est quoi ta valeur métier ?

Comme j'ai terminé un bouquin super mignon plus tôt que prévu dans le train ce soir, j'ai réfléchi à une question qui me turlupine depuis quelques temps. Lors d'une revue de design, on m'a posé la question qui tue :

Qu'est-ce qu'il apporte ton design en valeur métier ?

Inspiré par l'approche domain driven design, j'avais commencé à séparer des contextes entre notre système et le progiciel que nous devons intégrer, avec une couche d'adaptation entre les deux. Bref, un desing qui déchire. Mais j'ai été bien incapable d'inscrire ce design dans une notion de valeur métier. Et d'abord, la valeur métier, c'est quoi ?

Définition

Intuitivement, j'ai essayé définir pour moi ce que signifiait cette valeur métier. J'ai isolé deux pistes :

• Une métrique' définissant la part de ce qu'apporte un développement dans la réalisation de l'activité métier dans le contexte de l'entreprise. Par exemple, un système de billing sur le trafic prépayé pour un telco dans un pays émergeant peut avoir une valeur métier de 80% mais beaucoup moins dans nos contrées adeptes du modèle illimité / smartphone. C'est un joli point de vue mais il me semble difficile d'établir un tel barème pour l'ensemble des activités de l'entreprise (à moins de faire intervenir une armée de consultants).
• Plus simplement, la part que prend un développement dans la réalisation des objectifs métier, définis dans le cadre d'une étude d'architecture. Par exemple, remplir l'objectif de réduire de 20% les coûts de licences logicielles payées par l'entreprise d'ici 2015 implique de passer sur de l'open source ou du Saas pour son ERP. Évidemment, ça implique des objectifs SMART (j'aime bien ce concept, je vais y revenir).

Ce soir, j'ai pu en trouver une définition ayant l'air officielle ici. Ces mecs doivent savoir de quoi ils parlent. Moi moins car ça ressemble foutrement à du jargon managerial (nan, les gars, c'est vrai quoi…).

[la valeur métier] peut être définie comme intégrant :

• le fait que le modèle de données soit complet, (balivernes... c'est quoi un modèle de données complet ? Je comprend : adapté)
• le fait que les données soient exactes, (j'espère comme eux qu'un DSI aspire à ne pas avoir des données fausses dans ses référentiels)
• le fait que les règles et les processus métier soient complets et exacts, (meh)
• le fait que les processus mis en place contribuent à l’efficacité de l’entreprise : apport sur la réduction des coûts, la productivité, la satisfaction du client, les possibilités de suivi métier, le reporting, la business intelligence, … (OK, là c'est intéressant)

La valeur métier est utilisée pour définir la pertinence ou la priorité d’une fonctionnalité à développer durant la phase de Développement Produit, ou de manière plus macro de la Vision Produit.

Selon cette définition, la valeur métier m'apparait comme très technique. Je retiens notamment que la partie exploitation et maintenabilité représentent de la valeur métier.

Utilisation d'objectifs SMART

Ce qui me dérange dans cette définition, c'est qu'elle nécessite d'être contextualisée pour pouvoir permettre de prendre de décision pendant nos développements. C'est là, il me semble, qu'interviennent les objectifs métier. Ceux-ci doivent être mesurables, atteignables et bornés dans le temps. Cela permet d'estimer dans quelle mesure nos propositions vont contribuer à ces objectifs et de pouvoir les pondérer, estimer si certains sont plus importants que d'autres.

L'objectif ci-dessous est inexploitable :

Je veux diminuer mes coûts de maintenabilité

OK, mais dans quelle mesure ? De moitié ? De 10 000 € ? Et à quel horizon ? Dans 6 mois, 3 ans ? Celui-ci est mieux :

Je veux augmenter ma marge opérationnelle de un million d'euros à S2 2015.

Une étude architecture estime également des principes directeurs à observer dans la poursuite de ces objectifs ainsi que les contraintes à prendre en compte. Pour moi, la valeur métier d'un développement est donc la quantification de sa contribution aux objectifs métier de l'entreprise dans le respect des contraintes et des principes directeurs du programme (ou du SI). Ça claque tellement que j'ai envie de la proposer à l'APMF.

On en est où en ce qui concerne mes choix techniques ?

Avec des objectifs SMART et des principes pondérés, il devient réaliste de savoir mesurer la contribution de tel ou tel choix en terme de valeur métier. Cela vaut pour les choix fonctionnels (intégrer telle ou telle story…) comme les choix techniques (utiliser un composant soumis à licence, respecter des standards de dev ou des motifs d'architecture spécifiques, Java, .Net,…). Le plus important étant de se rappeler que ces notions dépendent du contexte dans lequel nous travaillons.

Vouloir favoriser la maintenabilité en estimant le cout de changement d'un composant peut apporter de la valeur métier… sauf si le business model du client est changeant et qu'il estime qu'il mettra votre appli à la poubelle dans 6 mois.

Accepter de perdre des données de log dans le cadre de l'indisponibilité d'une plateforme peut être acceptable… sauf si ces données font l'objet de réquisitions judiciaires et que le client est légalement contraint de les fournir.

La valeur métier, ce n'est pas si compliqué quand on prend le temps de poser les choses et d'expliquer ce qu'il y a derrière. Il n'y a pas de bonne réponse sans une connaissance claire des composantes de cette valeur métier

• la mission de l'entreprise,
• les objectifs poursuivis,
• les contraintes,
• les principes…

Quant à moi, je vais essayer de ne plus sécher sur cette question pénible.