Minimum Viable Product II – Une question d'organisation

Ce deuxième article sur le thème du Minimum Viable Product traite des aspects organisationnels du Minimum Viable Support.

Auteur / Autrice Markus Schweizer
Date 26.11.2018
Temps de lecture 4 Minutes

Dans mon dernier article, j’ai écrit qu’un Minimum Viable Product doit être accompagné d’un Minimum Viable Support. Je me suis principalement appuyée sur un projet client qui a pu être optimisé en automatisant et analysant l’assistance. Cette fois-ci, je souhaite me pencher sur les aspects organisationnels du Minimum Viable Support.

Aujourd’hui, avec des méthodes agiles, nous sommes capables de lancer rapidement sur le marché un nouveau produit avec ses fonctionnalités de base (Minimum Viable Product). C’est pourquoi nous devons aussi être capables de corriger rapidement les erreurs qui surviennent et de lancer de nouvelles fonctionnalités. Nous devons assurer notre capacité à résoudre les problèmes sur le long terme.

Pour cela, ITIL® nous a livré des méthodes de base illustrées sur l’image 1 :

minimum-viable-product

Un problème est

  • détecté au niveau de l’Event Management,
  • résolu par l’Incident Management,
  • le Problem Management cherche la cause du problème et prépare une solution,
  • cette dernière est mise en place et diffusée par le Change Management,
  • et documentée dans la base de données du Change Management.

Si ce cycle est toujours maintenu, nous observons une évolution exponentielle : les problèmes deviennent plus simples et durent moins longtemps. Les clients observent une baisse de 85 % des problèmes sur trois ans !

À l’ère de la digitalisation, trois ans restent toutefois une éternité pendant laquelle notre MVP aurait depuis longtemps été envoyé au paradis des applications. Il est prouvé que la méthode d’ITIL fonctionne, mais elle doit absolument être accélérée ! L’automatisation de toutes les étapes est pour cela nécessaire, mais reste insuffisante. Le personnel doit aussi repenser sa façon de collaborer selon la chaîne présentée ci-dessus. À la place de groupes fonctionnels, des équipes rattachées à un service doivent s’organiser les unes à la suite des autres sous forme de “bande DevOps”, comme le décrit le graphique suivant :

minimum-viable-product-2

DevOps est le mot-clé : DevOps n’est pas un cadre ou une méthode mais un “mouvement” qui s’est développé sur les 10 dernières années. Après de longues années de silence “forcé” entre le développement et les opérations, le concept d’agilité révèle à nouveau la nécessité de communiquer. Avec le cloud, la virtualisation et l’automatisation de tous les niveaux des infrastructures (Everything-as-a-Service), les entreprises vont aujourd’hui encore plus loin : l’opérateur IT “bleu” sur le graphique n’est plus qu’un rôle pris en charge par les membres de la bande DevOps. Une étude de McKinsey partage cette perspective et prévoit que les méthodes agiles seront aussi mises en place dans le secteur IT et réduiront de 35 % la charge de travail.

Ainsi, le Minimum Viable Support fera à l’avenir partie intégrante de chaque développement de produit et par conséquent de chaque Minimum Viable Product.


Auteur / Autrice

Markus Schweizer

Markus Schweizer est formateur Digicomp, expert ITIL® et Cobit ainsi que consultant en stratégie chez DXC Technology pour toutes les questions de gestion des technologies de l’informatique. Auparavant, il a travaillé pour IBM et PwC et a passé neuf ans aux États-Unis où il a conseillé des grosses entreprises dans le déploiement de concepts de gestion de services. Il est spécialisé en gestion d’entreprises informatique, en numérisation interne, en gouvernance et en SIAM.