Qu'est-ce qu'un portfolio de services ?

Un portfolio de services est une collection de tous les services qu'une entreprise propose à ses clients. Il comprend à la fois les services de base qui définissent le produit ou le service de l'entreprise, ainsi que les services complémentaires qui augmentent la valeur de l'offre et renforcent la fidélisation des clients.

Portfolio vs Catalogue

En se basant sur la définition du portfolio de services dans le cadre du célèbre framework ITIL, un portfolio de services se compose de trois éléments : Catalogue de services - l'offre actuelle de services, Pipeline de services - l'offre future de services, Retraite des services - l'offre historique de services. Le portfolio doit ainsi présenter une image globale des services d'une organisation sur le plan thématique, opérationnel et temporel.

Fondements théoriques

Comme c'est souvent le cas avec les cadres dans le domaine de l'informatique (ITIL, SAFe, etc.), il n'y a pas de méthode clairement correcte ou incorrecte en ce qui concerne le portfolio de services. Ce sont toujours l'organisation et ses employés qui doivent combiner les fondements théoriques avec l'approche pratique pour définir les détails. Lors de notre travail avec nos clients, nous sommes cependant en mesure de voir et d'expérimenter différentes approches et mises en œuvre à partir de différentes sources, ce qui nous permet de dégager plusieurs "bonnes pratiques" qui, de notre point de vue, se sont imposées.

Hiérarchie des services et des actifs

Lors de la définition des services d'une organisation, il est souvent rapidement évident qu'il existe des services à différents niveaux. Par exemple, différents services peuvent être combinés pour réaliser une responsabilité supérieure. Par conséquent, lors de la conception du portfolio de services, il est important de prendre en compte le fait que les services peuvent être liés hiérarchiquement les uns aux autres. Par exemple, pour représenter la combinaison de services pour la réalisation d'un service supérieur.

Dans le cadre d'un portefeuille de services, il est essentiel de prendre en compte la définition et la combinaison des services, ainsi que la différenciation et l'inclusion des actifs qui composent les services respectifs.

Selon l'ITIL, un service est défini comme suit :

"Un moyen d'apporter une valeur ajoutée aux clients en facilitant ou en favorisant l'atteinte des résultats souhaités par les clients..." (Glossaire ITIL Axelos).

De notre point de vue, il s'agit toutefois d'une étape essentielle pour développer un portefeuille de services afin de développer une compréhension commune de la chaîne de montagnes "de services" dans le contexte de l'organisation.

En utilisant l'exemple des applications Atlassian, "Atlassian" pourrait être défini comme un service composé des applications "Jira" et "Confluence". Au même niveau, les applications Microsoft sont également regroupées dans un service correspondant. Les deux peuvent être subordonnés au service "Collaboration".

La dénomination des services par fabricant ou par produit individuel est souvent évitée afin de rendre la structure conceptuelle d'un portefeuille de services indépendante du fabricant. Toutefois, cela peut également créer des ambiguïtés pour les utilisateurs qui n'associent pas des services spécifiques à des termes génériques. Ici aussi, il est important de prendre en compte les circonstances actuelles et les particularités organisationnelles.

Une hiérarchie peut être déséquilibrée

La combinaison de services et d'actifs subordonnés aboutit donc à une hiérarchie dans une sorte d'arborescence. D'après l'expérience pratique, cette structure n'a pas besoin d'être équilibrée. Cela signifie que les éléments situés en dessous d'un service éventuel peuvent avoir trois niveaux intermédiaires, tandis qu'un autre en a quatre.

Ce déséquilibre potentiel permet de cartographier de manière flexible des structures et des dépendances plus complexes résultant d'interfaces ou de responsabilités organisationnelles. Même en cas de changements futurs, de nouveaux niveaux intermédiaires peuvent être insérés selon les besoins sans avoir à redévelopper l'ensemble de la structure du portefeuille. Ainsi, non seulement les dépendances peuvent être présentées, mais les responsabilités peuvent également être documentées et communiquées plus clairement.

Des liens vers d'autres éléments de configuration proposent des options supplémentaires

Outre les liens entre les services et les actifs, il est également possible d'intégrer des liens vers d'autres éléments de configuration (CI) ou actifs tout en créant un portefeuille de services et en définissant des services. Le lien avec le matériel physique (serveurs, ordinateurs portables, scanners, etc.), les licences ou les unités organisationnelles permet de cartographier un réseau étendu. Cela permet non seulement d'afficher les dépendances entre les services ou les applications, mais également de les relier à du matériel spécifique ou à d'autres composants nécessaires à la fourniture des services.

(Jira) les Assets comme base

Développée à l'origine en tant qu'application indépendante "Insight" par Mindville, Atlassian a racheté le fabricant en novembre 2020 et a ensuite intégré l'application au produit Jira Service Management existant. Aujourd'hui, l'application est entièrement intégrée à Jira Service Management (JSM) sous le nom de "Jira Assets". Les actifs sont déjà entièrement inclus pour les licences JSM Data Center et JSM Cloud Premium.

Alors que certaines solutions se concentrent principalement sur les CI ou les actifs (et excluent donc les utilisateurs ou les unités organisationnelles, par exemple), Jira Assets offre la possibilité de définir librement les objets. Sur le plan technique, il n'y a donc aucune distinction entre les services, les actifs ou les CI.

Jira Assets fournit une plateforme permettant de définir des objets. L'utilisateur est seul responsable de la conception de l'utilisation et de l'utilisation de ces objets. Bien que cela implique également l'effort nécessaire pour définir et créer, cela se traduit également par une grande liberté et par la possibilité de relier de manière étendue des éléments qui ne sont pas traditionnellement disponibles dans le même système.

La mise en œuvre dans Jira Assets repose sur trois composants principaux.

Les schémas d'objets représentent un conteneur, une collection.

• Tout comme les tâches dans les projets Jira, tous les objets doivent être associés à un schéma d'objets.
• À l'intérieur d'un schéma d'objets, un nombre quelconque de types d'objets peut être défini.
• Un type d'objet est principalement caractérisé par les attributs définis, qui enregistrent les informations détaillées d'un objet. En plus des attributs de texte et de liste, il est également possible de définir des liens vers d'autres objets en tant qu'attributs.

Dans un exemple spécifique, les services et les applications pourraient être définis comme des types d'objets distincts dans le même schéma d'objets. Chaque objet de service possède ensuite des liens vers des services de niveau supérieur et dépendants. Sur l'objet d'application, il existe à son tour un lien vers le service de niveau supérieur et vers d'autres applications dépendantes ou connectées. (voir graphique ci-dessus)

‍

Comme les liens dans les actifs sont toujours bidirectionnels (comme dans Jira), un diagramme arborescent correspondant peut être dessiné à l'aide de liens définis et des listes peuvent être créées à l'aide de requêtes. En effet, les actifs peuvent ainsi apporter une contribution significative à la clarté et à la transparence.

La valeur principale d'un portefeuille de services dans Jira Assets réside cependant dans l'utilisation des objets disponibles dans d'autres processus (ou disciplines, selon ITIL 4) :

• Dans le cadre de l'Enablement des changements, un changement peut être automatiquement attribué au propriétaire du service pour approbation s'il est maintenu comme attribut sur le service et que ce service est disponible pour sélection lors de la création de changements sur un formulaire dans Jira.
• Les incidents peuvent être automatiquement attribués à la bonne organisation de support après que l'application concernée a été sélectionnée sur l'interface utilisateur. En arrière-plan, les liens entre l'application, le service et l'équipe de support sont résolus, et éventuellement jusqu'à la personne individuelle.
• En plus de la sélection d'applications dans la gestion des tests ou dans le domaine du développement, un cas d'utilisation particulièrement étendu se présente dans le cadre de la gestion des Service Request Management. Non seulement la définition des demandes sélectionnables, mais aussi le routage vers le bon point de support jusqu'à la sélection du bon SLA peuvent être définis et automatisés sur la base des objets correspondants dans les ressources.

Clé du succès

Un portefeuille de services clairement défini et mis en œuvre dans Jira Service Management ou Jira Assets peut être une excellente opportunité pour les organisations en phase de création, de croissance ou de transformation de cartographier leurs services dans une solution de pointe.

Avec les possibilités flexibles de définition et de liaison d'objets et leur utilisation dans Jira et Confluence, il existe de grandes possibilités de donner un nouvel élan à la gestion des services existante ou de fournir aux organisations une plateforme pour le développement de la maturité de leurs services.

Chez Swarmit, nous accompagnons nos clients de divers secteurs dans la mise en œuvre de différentes exigences et approches. Nos consultants aident dans différents domaines, du développement d'un portefeuille de services à la cartographie dans Jira Assets et/ou à l'exploitation des applications, que ce soit en installation locale ou dans le cloud, que ce soit à Zurich, Lausanne ou directement dans vos bureaux.

Contactez-nous !

Comme mentionné à plusieurs reprises, la construction d'un portefeuille de services doit toujours être considérée dans le contexte de l'organisation respective. Cela entraîne des approches et des perspectives très différentes sur les définitions de termes et les composants structurels.

Cet article n'est qu'une parmi de nombreuses possibilités.

Nous serions ravis de discuter avec vous de vos besoins spécifiques et de vous montrer comment Swarmit peut vous aider à mettre en œuvre avec succès un portefeuille de services dans Jira Assets.

Plus d'informations :

• Gestion des services Jira : https://www.atlassian.com/de/software/jira/service-management
• Jira Assets : https://www.atlassian.com/de/software/jira/service-management/features/asset-and-configuration-management
• Essaim : https://www.swarmit.ch