L’important pour un client n’est pas l’entreprise chez qui il achète. Mais bel et bien, ce qu’il achète (cfr Business Model Canvas d’Osterwalder). Trop souvent, j’entends : « On ne disparaîtra pas parce qu’ils ont confiance en nous ! » ou, « On les connaît trop, on a la connaissance de ce qu’ils font que d’autres n’ont pas ». Bien sûr, c’est un plus indéniable de connaître son client. Mais ce n’est pas çà qui fait qu’une entreprise ou un département IT est meilleure qu’un.e autre. Ce n’est pas çà qui va faire qu’un client va rester.

« Le plus important pour un client est l’utilité de ce qu’on lui vend ». Cette phrase résume les critères du Design Thinking : Viabilité, Désirabilité et Faisabilité (source IDEO). Et donc, une entreprise – en général – dure grâce à l’utilité dans le temps de ce qu’elle vend (cfr 7 Questions d’Osterwalder) .

Si on considère un département IT comme une entreprise, alors ce qu’il vend à ses clients (métiers de l’entreprise), ce sont des produits numériques et des services IT.

Pour plus de détails , voir les articles suivants:

• Les produits numériques (Digital products) ainsi que
• Aligner les produits numériques à la stratégie d’entreprise (via un Business Case).

Mais … attention au quiproquo : lorsqu’un progiciel est installé (service IT rendu) pour augmenter la performance d’un métier, c’est bien un produit qui est perçu par le métier, pas le service. Il est donc important de comprendre que le métier perçoit un produit final – que nous appellerons ‘produit numérique’ – qui répond à ses besoins métiers (spécifiques de son point de vue).

Cependant, derrière ce produit, il y a un ensemble de services IT (fabrication, maintenance, support, mises à jour) qui assurent la continuité et la performance de ce produit. C’est donc à travers cette combinaison produit-service que l’IT apporte une véritable valeur ajoutée au métier.

En résumé, le client (métier) se focalise sur le résultat (le produit), mais la qualité du service IT sous-jacent est là pour maintenir cette valeur.

Le schéma présenté ci-dessus montre comment l’alignement des services IT se réalisent lorsqu’un produit numérique intervient dans la proposition de valeur au « métier » (du client/bénéficiaire).

Au cœur de ce schéma, la « Valeur métier » est l’objectif principal que l’architecture d’entreprise doit viser. Le flux de valeur représente comment un service IT contribue directement à la création de cette valeur au travers du produit numérique.

Positionnement de l’AE

Le rôle de l’AE est d’être un facilitateur, ainsi qu’un garant de la cohérence de l’ensemble.

Son rôle sera de vérifier que les paramètres sont biens présents, à la bonne valeur et dans le bon intérêt. Et ce surtout pour les services IT. En termes de responsabilité, l’architecture d’entreprise se positionnera sur les décisions/intentions de la stratégie d’entreprise pour fixer les changements des fondations IT, nécessaires au maintien de la proposition de valeur et de la continuité de service. Nous verrons ceci dans un autre article qui décrira la gouvernance du changement du SI sur base du cadre fixé par la figure 1.

Revenons à ce schéma de la figure 1, même s’il est logique dans sa compréhension, il n’en reste pas moins difficilement applicable pour un département IT dès que plusieurs centaines d’applications et une centaine de produits numériques doivent être gérés. Comment alors assurer le rythme des livraisons pour satisfaire des utilisateurs de plus en plus exigeants, comment assurer les adaptations du SI pour satisfaire les dirigeants de plus en plus pressants et pressés …

Cet article va montrer : comment un département IT doit s’organiser pour assumer sa proposition de valeur aux départements et directions de son entreprise.

Ce que nous allons voir dans cet article.

1. Les lignes de produits
   1. Définition
   2. Posture de l’AE face aux lignes de produits (LP)
   3. Les catégories de ligne de produits
   4. Posture de l’AE face aux catégories
2. L’importance du modèle de maturité
   1. Allons (encore) plus loin … avec le PLC model
   2. Lien entre PLC et maturité
   3. Lien entre PLC et la satisfaction « client »
3. Conclusion

Les lignes de produits

Définition

Définition en lien avec une entreprise

Une ligne de produits d’une entreprise fait référence à un ensemble de produits liés entre eux, qui sont offerts sous une même marque ou dans une même catégorie de marché. Ces produits partagent généralement des caractéristiques similaires, visent un même segment de clientèle, ou répondent à des besoins proches. Ils peuvent différer en termes de fonctionnalités, de qualité, de prix ou d’options, mais appartiennent à une même famille (gamme) de produits.

Définition en lien avec un département IT

Une ligne de produits dans un département informatique représente un ensemble cohérent de produits numériques (PN comprenant des applications, des systèmes et des services IT) développés et gérés pour répondre aux besoins internes de l’entreprise. Ces PN sont conçues pour améliorer l’efficacité opérationnelle du métier (client), optimiser leurs processus et garantir leur continuité de services.

La différence entre ces positionnements des lignes de produits doit être comprise afin de pouvoir – par la suite – appliquer certaines théories des modèles de la stratégie et de la gestion de produits tirés de BCG, Porter, GARTNER …

L’enjeu ici va être d’accepter que le département IT ne se suffit pas à lui-même et surtout ne peut pas imposer son dicta à ses clients métiers (internes à l’entreprise). L’autre sens fonctionne aussi, le métier doit également comprendre qu’il ne suffit pas de demander pour recevoir et que contrairement aux idées reçues, l’IT ne peut pas évoluer sur un claquement de doigts 😉

Les points d’attention à prendre en compte sont au nombre de 4 : ils sont inspirées sur les pièges (pitfalls) de l’article de Mod Op – Strategic consulting

Donner la priorité à la technologie : (ou confondre besoins des utilisateurs et besoins du métier/client) Les utilisateurs de technologie aiment inclure les dernières nouveautés. Mais parfois, vouloir ces extras nuit au produit. Cela peut rendre soit le produit trop cher, trop compliqué ou tout simplement moins utilisable. La priorité doit être mise sur les désirs et les besoins du métier, et pas celui de l’utilisateur.

Point d’attention : Ne pas oublier que vous ne construisez pas le produit numérique pour vous-même.

Chaîne des produits : (ou oublier sa valeur ajoutée) Les produits numériques dans un département informatique s’appuient sur des services internes IT qui eux-mêmes peuvent s’appuyer des produits commerciaux de fournisseurs externes. Cette chaîne peut amener à ne plus voir le produit commercial mais le fournisseur (entreprise externe). Et donc de facto, ne plus percevoir la valeur ajoutée de son propre département IT et considéré que le fournisseur est le seul – voire le meilleur – à fournir le service au PN. Cette idée peut aller à ne plus vous rendre compte que cette chaîne a besoin d’être modifiée ou complètement repensée. Ou bien, il peut même être nécessaire de la supprimer.

Point d’attention : Cette chaîne des produits (proposition de valeur) ne signifie rien si elle ne mène pas à un produit que les consommateurs souhaitent.

Clientèle : (ou refuser de s’adapter) Le département informatique sert des clients internes (autres départements ou employés) plutôt que des clients externes. Ce qui signifie que les moyens de « faire pression » peuvent être plus importants pour faire bouger un département IT qu’une entreprise. Mais à contrario, la loi du marché peut impacter beaucoup plus une entreprise qu’un département IT. Nous savons tous que le secteur du numérique évolue à une vitesse fulgurante, une initiative numérique se déroule rarement comme prévu. De ce fait, l’incapacité à s’adapter aux nouvelles informations au milieu ou à la fin d’une initiative est un fléau dans le monde numérique lorsque les raisons du refus sont basées sur des conflits internes, des jeux politiques entre départements … .

Point d’attention : Être à l’écoute des raisons à l’origine d’un refus. Les bonnes raisons restent, les mauvaises sont à fuir.

Roadmap : (ou conserver la budgétisation traditionnelle) Les roadmaps doivent être alignées sur les objectifs stratégiques internes de l’entreprise, avec un accent sur la productivité, la sécurité et l’innovation. Ce qui signifie qu’une roadmap doit s’adapter en permanence aux besoins changeants du métier et de l’entreprise. L’utilisation de méthodes agiles permet de les réévaluer et les ajuster régulièrement, en tenant compte des priorités évolutives et de budgets dynamiques. Cela permet de répondre aux demandes plus rapidement, tout en évitant les prévisions rigides qui deviennent rapidement obsolètes.

Point d’attention : ne pas oublier de segmenter le budget par catégorie de ligne de produits. Ainsi, au lieu de suivre une budgétisation traditionnelle fixe, un budget flexible alloué par ligne de produits en fonction de sa catégorie permet une meilleure réactivité.

Posture de l’AE face aux lignes de produits (LP)

Dans le cadre fixé par la figure 2, l’architecture d’entreprise trouve comme appui les éléments suivants :

• La proposition de valeur et les flux de valeurs : Ils définissent la chaîne de création de valeur de l’organisation et mettent en lumière les processus clés pour la satisfaction des clients/bénéficiaires.
• Les produits et services : Ils représentent l’offre concrète de l’organisation, segmentée par type de clients/bénéficiaires.
• Les business capabilities : Ils traduisent ce que l’organisation doit être capable de faire pour délivrer sa proposition de valeur.
• Les ressources : Elles englobent les personnes et leurs profils, les aspects financiers, les technologiques et les biens mobiliers et immobiliers.

En mettant en évidence un modèle d’affaire de l’entreprise, les éléments clés ci-dessus sont plus facilement assumés par ceux qui mettent en place la stratégie d’affaire de l’entreprise.

L’architecture d’entreprise, en définissant et en maintenant la cohérence entre ces éléments clés et les LP, influence les besoins en termes de produits numériques et services IT.

Cela peut paraître perturbant au premier abord, c’est pourquoi nous allons parcourir les différents principes qui permettent de passer de la stratégie d’entreprise aux impacts et cadrages d’un département IT.

Les catégories de ligne de produits

Dans un département IT, chaque ligne de produits (LP) relève in fine de besoins métiers d’un département ou d’une direction d’une entreprise.

De par des positionnements différent au sein de l’organisation, il est nécessaire de classer ces LP en grandes catégories. Ces dernières se justifieront par un modèle opérationnel¹ adapté du département IT et de facto impacteront ses services IT, tant en termes d’utilité que de garantie.

Ces catégories imposent donc au département IT qu’il adopte une approche flexible, en alignant ses processus et son fonctionnement interne avec les exigences stratégiques de chaque ligne de produits. Et ce, en toute cohérence avec leurs catégories, au risque même – si on n’y prête pas attention – d’augmenter les coûts, de prolonger les délais de livraison …

Exemples

Les lignes de produits d’un département IT peuvent être déclinées en catégorie de cette manière :

1. Catégorie ‘Spécifiques métiers‘ :
   • Définition : Ces lignes de produits répondent à des besoins uniquement liés à un métier ou une direction spécifique au sein de l’organisation. Elles sont caractérisées par un haut degré de personnalisation et s’appuient souvent sur des PN dédiés spécifiquement au métier.
   • Gouvernance : La stratégie et la roadmap sont définies par le métier concerné, en collaboration avec l’équipe IT. La responsabilité de l’exécution et du suivi est déléguée au métier, qui peut s’appuyer sur des experts référents pour la compréhension des enjeux et l’identification de PN ou services IT.
     
2. Catégorie ‘Transversales‘ :
   • Définition : Ces lignes de produits couvrent des besoins partagés par plusieurs métiers ou directions. Elles s’appuient sur des PN communs et standardisés, favorisant l’interaction et le partage d’informations entre eux. Le bénéfice de ces lignes de produits permet une mutualisation des ressources du département IT et une simplification de l’architecture.
   • Gouvernance : La stratégie et la roadmap sont gérées par le département IT et définies conjointement par les différents métiers concernés. Des instances de coordination et de gouvernance transversales sont mises en place pour garantir la cohérence et la priorisation des actions.
     
3. Catégorie ‘Génériques / Fondations IT‘ :
   • Définition : Ces lignes de produits regroupent les PN et services IT nécessaires au fonctionnement de l’ensemble de l’organisation mais sans réel lien à des métiers. Elles concernent des fonctions « support » comme l’infrastructure, la sécurité, la gestion des postes de travail, la bureautique … ou des outils de base pouvant aller jusqu’à servir de support aux autres lignes de produits.
   • Gouvernance : La stratégie et la roadmap sont définies par l’équipe IT en tenant compte des orientations stratégiques de l’organisation. La responsabilité de l’exécution et du delivery est assumée par l’équipe IT, qui peut sous-traiter certaines prestations à des fournisseurs externes.

Posture de l’AE face aux catégories

Pour assurer la transparence et l’alignement constant des décisions opérationnelle avec les objectifs stratégiques de l’entreprise, l’AE s’appuiera – par exemple – sur un Product Backlog (outil de gestion des priorités). Ainsi, via des revues trimestrielles (ou semestrielles en fonction de la performance du département IT), la roadmap d’architecture en lien avec les PN sera ajustée pour réorienter les efforts et ressources selon de nouvelles contraintes.

Le fait de s’appuyer sur une gestion des priorités, le facteur ‘anticipation’ du département IT – et qui est de la responsabilité de l’architecture d’entreprise de le mettre en évidence – pourra trouver sa place sereinement au sein des portefeuilles de projets (partie Vision des portefeuilles – cfr SAFe)

L’importance du modèle de maturité

De manière intuitive, on peut considérer que la maturité des métiers et du département IT influence fortement le positionnement et la gestion des lignes de produits. Voici comment :

1. Maturité des métiers : Un métier avec une faible maturité numérique nécessitera des produits plus standardisés, simples à utiliser et demandera un accompagnement important. En revanche, des métiers matures pourront utiliser des produits plus complexes, personnalisés et intégrer des innovations. Dans notre exemple ci-dessus, cela affecte la catégorie spécifique métier ou transversale.
   
2. Maturité du département IT: Le département IT doit aligner sa propre maturité en termes de capacités techniques, d’exécution de la stratégie (portefeuille, programmes, projets) et d’agilité organisationnelle. S’il est en phase de montée en maturité, il se concentrera d’abord sur l’optimisation de ses fondations IT (infrastructures, sécurité …) pour offrir une base solide au métier/client avant de développer des lignes de produits plus avancées.

Ainsi, la maturité des deux parties conditionne la complexité, le type d’innovation et le niveau de personnalisation des lignes de produits, ainsi que leur classification dans les catégories. Un faible niveau de maturité d’une des deux parties pourrait également retarder l’adoption d’une gouvernance plus avancée.

En résumé, un métier peu mature nécessitera des PN plus simples et standardisés, tandis qu’un métier avancé peut bénéficier de PN plus complexes et personnalisées. Un département IT peu mature dans l’un de ses produits, se concentrera soit vers une délégation de son IT vers des fournisseurs plus mature (si le métier est mature – pas obligatoire), soit il se concentrera sur la montée en maturité de ses fondations IT impactant le PN concerné mais également le métier.

Les catégories de lignes de produits sont également influencées, voire impactées par le modèle de maturité car elles permettent de structurer les offres IT en fonction des besoins métiers des « clients » et des capacités du département IT. Voici leur influence par rapport à l’exemple ci-dessus :

1. Spécifiques métiers : Ces lignes ciblent des besoins précis/spécifiques, mais leur pertinence et leur réelle ‘valeur ajoutée’ dépendra toujours de la maturité des métiers et à leur capacité à intégrer en leur sein ces PN ‘spécifiques’.
2. Transversales : Ces LP favorisent la mutualisation entre plusieurs métiers, offrant des synergies. La maturité des métiers déterminera leur capacité à collaborer et à partager ces PN.
3. Fondations IT : Vitales pour l’ensemble, ces LP soutiennent entre autres les deux autres catégories. Leurs maturités impactent directement la fiabilité et l’évolutivité des autres services.

Ainsi, ces catégories permettent au département IT d’ajuster son approche en fonction du niveau de maturité et des priorités stratégiques des clients/bénéficiaires.

Allons (encore) plus loin … avec le PLC model

Le modèle PLC (article qui décrit le PLC model) décrit les différentes phases d’un produit durant sa vie (voire son utilité) vis-à-vis d’un client. De manière générale, voici les différentes phases comme suit :

Phase d’introduction

L’entreprise a développé et lancé un produit, mais les ventes sont encore faibles et il n’y a pas de bénéfice. Dans cette phase, la concurrence est limitée car il s’agit d’un nouveau produit. Il est essentiel de faire connaître le produit pour atteindre la phase suivante. Plus les utilisateurs découvrent le produit, plus les ventes augmenteront naturellement, menant à la phase de croissance. Une campagne de promotion peut être efficace à ce stade.

Phase de croissance

Le produit est désormais bien lancé et commence à générer des bénéfices. Les ventes augmentent, mais la concurrence s’intensifie à mesure que d’autres imitent et introduisent leur propre version sur le marché. L’accent doit être mis sur les avantages distinctifs du produit afin de conquérir le marché. À la fin de cette phase, le produit atteint son apogée. L’objectif ici est de récupérer les coûts d’introduction.

Phase de maturité

Cette phase se caractérise par un ralentissement de la croissance. L’accent se déplace vers la réduction des coûts pour prolonger la durée de vie du produit. La baisse des prix et les promotions deviennent des outils clés.

Phase de saturation

La demande pour le produit diminue légèrement. Le marché est arrivé à maturité. Les entreprises moins compétitives retirent leurs produits, tandis que les plus fortes continuent. Ici aussi, le contrôle des coûts est crucial pour prolonger le cycle de vie tant que le produit reste rentable.

Phase de déclin

La demande pour le produit diminue fortement car de meilleures alternatives apparaissent. L’entreprise peut alors décider de retirer le produit du marché.

Le PLC s’applique totalement à la situation des PN d’un département IT.

Lien entre PLC et maturité

Le modèle de maturité par définition ne perturbe pas les catégories ni les lignes de produits. Par contre, ce modèle permet d’évaluer le niveau de réponse IT et d’en justifier la pertinence vis-à-vis du métier « client ».

Car la maturité des métiers et du département IT influe directement sur les phases du cycle de vie des produits (PLC).

1. Phase d’introduction : Les métiers avec une faible maturité adoptent lentement les nouveaux produits. Une stratégie de formation et d’accompagnement est généralement nécessaire.
2. Phase de croissance : Les métiers matures peuvent adopter plus rapidement des fonctionnalités attractives et innovantes, ce qui accélère la croissance des PN.
3. Phase de maturité et de saturation : Les métiers plus avancés peuvent prolonger cette phase en intégrant des améliorations ou des services complémentaires.

Deux exemples :

Exemple 1 : Prenons une des catégories vue ci-dessus, par exemple « Spécifique métier ». Dans cette catégorie, le département IT a « l’autorisation » de l’entreprise de répondre de manière spécifique, comme il l’entend, à un et un seul métier. Disons que ce dernier n’est pas mature dans l’un de ses domaines pour lequel le département IT lui a proposé une ligne de produits (et biensûr pour lui uniquement).

Le département IT pourra alors prendre la liberté d’agir de 2 manières :

• Autoriser le métier a géré lui-même les investissements IT des PN et à en assumer les coûts à terme. Cette responsabilité pourrait même être déléguée à des fournisseurs.
• Demander au métier de réaliser un premier ‘step’ de maturité avec des développements ‘low-code’ assumés au sein par le métier, mais dont la gouvernance sera fixée par le département IT.

Exemple 2 : Prenons une autre catégorie, comme ‘Transversale’. Dans cette catégorie, le département IT a l’obligation de proposer des PN répondant à plusieurs « clients » ayant un métier ‘proche’ en termes d’attente. Toutefois, les directions pourraient avoir des métiers n’ayant pas la même maturité alors qu’ils ont les mêmes besoins. Le département IT n’aura pas d’autres choix que de proposer au sein d’un même PN des applications différentes s’adaptant à la maturité du métier.

Nous pouvons donc constater que la maturité du client influence l’approche stratégique du département IT.

Voici quelques exemples d’approche : (rmq : ces exemples ne sont pas mutuellement exclusifs)

• Via une segmentation des PN en fonction de la maturité :
  Approche : Multiplication de l’offre au sein des PN en fonction de la maturité du produit et de sa position dans son cycle de vie.
  Impact : Plusieurs application en // pour le même PN donc multiplication des coûts mais amélioration de la satisfaction. De plus, cette approche permettra de faciliter le transfert des données lors de la montée en maturité du client, et donc vers l’application « plus évoluée ».
  
• Via une Intégration des catégories en fonction de la maturité :
  Approche : Ajustement du modèle opérationnel IT en fonction de la maturité du produit et de sa position dans son cycle de vie. Voici comment les catégories interagissent avec le PLC :
  • Spécifiques métiers : Dans la phase de lancement, ces produits demandent une attention particulière et des investissements importants que seul le métier peut suivre et comprendre. La maturité des métiers influence la vitesse à répondre du département IT.
  • Transversales : Dans la phase de croissance et donc de montée en maturité, les PN mutualisés profitent des synergies entre métiers et de la circulation de l’information entre eux. La maturité des métiers est clé pour une adoption rapide et une optimisation des coûts.
  • Fondations IT : Ces produits doivent souvent être en phase de maturité ou de saturation, où la réduction des coûts et la maintenance deviennent prioritaires. La maturité du département IT joue un rôle déterminant dans la gestion efficace de ces fondations.

Il existe encore une autre approche qui tient compte de la satisfaction client, via le modèle Kano. Cette approche peut être associée à celles ci-dessus.

Lien entre PLC et la satisfaction « client »

Le modèle Kano est un outil pour analyser la (in)satisfaction du client et les 5 catégories de fonctionnalités (indispensables, attractives, proportionnelles, indifférentes et double tranchant) à mettre en place dans des produits.

Dans notre contexte IT, le modèle Kano va être un outil puissant dans l’analyse de la satisfaction des métiers par rapport aux PN et services IT fournis.

Ce modèle classe les fonctionnalités en cinq catégories :

1. Indispensables : Les fonctionnalités essentielles pour le métier, sans lesquelles le produit ne serait pas utilisable.
2. Proportionnelles : Les fonctionnalités qui augmentent directement la satisfaction du client métier en fonction de leur qualité ou de leur performance.
3. Attractives : Les fonctionnalités qui surprennent agréablement le client métier, offrant une valeur ajoutée inattendue.
4. Indifférentes : Celles qui n’ont ni impact positif ni négatif sur la satisfaction des utilisateurs.
5. Fonctionnalités de « double tranchant » : Des éléments qui peuvent satisfaire certains utilisateurs tout en en frustrant d’autres.

Le modèle Kano permet de prioriser les efforts de développement en fonction de l’impact potentiel sur la satisfaction des métiers. Par exemple, les fonctionnalités indispensables doivent être livrées en priorité, tandis que les fonctionnalités attractives peuvent être introduites progressivement pour améliorer la satisfaction globale.

En intégrant le modèle Kano dans la gestion des lignes de produits, le département IT peut s’assurer que les services IT et les PN livrés sont non seulement fonctionnels mais aussi alignés aux attentes évolutives des métiers.

Le Product Life Cycle (PLC) Model et le Kano Model se complètent pour maximiser la gestion des produits et la satisfaction des utilisateurs :

• En phase de lancement, les fonctionnalités indispensables du modèle Kano sont importantes pour satisfaire les utilisateurs de base et assurer l’adoption du produit.
• En phase de croissance, les proportionnelles et attractives deviennent essentielles pour se différencier des « concurrents ».
• Dans la phase de maturité, l’ajout de fonctionnalités attractives peut prolonger la satisfaction, même si l’accent se déplace vers la réduction des coûts (comme dans le PLC).
• En déclin, l’amélioration des fonctionnalités peut maintenir un niveau acceptable de satisfaction.

Conclusion

On peut conclure que la prise en compte du niveau de maturité des clients d’un département informatique, associé aux cycles de vie des produits numériques et à l’analyse des fonctionnalités en rapport avec la satisfaction à atteindre, permettrait de mieux structurer les lignes de produits, d’améliorer la satisfaction des métiers et d’optimiser les services IT en fonction des besoins (spécifiques) métiers.

---

1. Modèle opérationnel : comportement et fonctionnement spécifiques en réponse aux attentes d’un métier. Il est essentiel pour aligner les activités internes sur la stratégie globale de l’entreprise. ↩︎