Service métier et service informatique

Comprendre l’enjeu et le périmètre

Cette distinction aide à choisir des engagements utiles, à définir les priorités de support et à expliquer les investissements techniques.

Décrire le bénéficiaire, le résultat attendu, les horaires utiles, les conditions d’accès et les exclusions, puis les composants qui contribuent au service.

Passer à l’action

• Définir le résultat attendu avec le bénéficiaire
• Décomposer les dépendances nécessaires à sa réalisation
• Fixer les critères d’acceptation et les modalités d’escalade

Suivez une information plutôt qu'un organigramme : qui la crée, qui la transforme, qui la valide et qui s'en sert pour agir ? Les ruptures apparaissent souvent entre deux services, alors que chaque application semble fonctionner correctement prise isolément.

Responsabilités et moyens

Le propriétaire du service métier accepte le résultat, le responsable du service informatique coordonne les composants et fournisseurs.

Intégrer exploitation, support, interfaces, formation et traitement des exceptions dans le coût du service.

Produire et vérifier

Livrable utile

Une fiche de service comportant bénéficiaires, responsable, dépendances, engagements, canaux de demande et limites.

Preuve à rechercher

Vérifier qu’un utilisateur peut obtenir le résultat de bout en bout, et non seulement se connecter à l’application.

Indicateur à interpréter

Mesurer la proportion de demandes abouties dans le délai convenu, en précisant les cas exclus et la population observée.

Un schéma est une hypothèse de fonctionnement. Demandez à un utilisateur de raconter un dossier réel, y compris une exception et un retour en arrière. Notez les outils informels et les personnes indispensables plutôt que de les faire disparaître du dessin.

Arbitrages et dépendances

Un engagement purement technique peut être respecté alors que les utilisateurs ne peuvent pas travailler.

Un service peut dépendre de plusieurs applications, du réseau, de l’identité numérique, de données disponibles et d’une validation humaine.

La bonne unité de raisonnement est le service rendu. Remplacer un logiciel sans traiter une validation ambiguë ou une information manquante peut déplacer le problème. Distinguez donc ce qui relève de l'organisation, de la donnée et de la technique avant de choisir une réponse.