Capacités métier et applications

Comprendre l’enjeu et le périmètre

Cette approche aide à comparer des investissements et à conserver une vision stable lorsque les outils ou l’organisation changent.

Définir la capacité, le résultat attendu, le niveau de performance et les ressources humaines, informationnelles et techniques nécessaires.

Passer à l’action

• Formuler la capacité sans citer de produit
• Évaluer son niveau actuel et son niveau cible
• Relier les écarts aux processus, compétences, données et applications

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

La direction métier définit le besoin, l’architecte structure la carte, et la DSI et les ressources humaines évaluent les moyens.

Chiffrer l’ensemble des moyens nécessaires au niveau cible, y compris formation, données et exploitation.

Produire et vérifier

Livrable utile

Une carte des capacités, leur importance stratégique et les initiatives qui améliorent leur niveau de maîtrise.

Preuve à rechercher

Vérifier qu’une capacité reste compréhensible si le logiciel ou le service qui la soutient est remplacé.

Indicateur à interpréter

Suivre le niveau de service métier obtenu et la fermeture des écarts, avec des critères observables plutôt qu’une note intuitive.

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

Nommer les capacités d’après les logiciels enferme la stratégie dans l’existant et masque les besoins de compétences ou d’organisation.

Une capacité peut partager des données, personnes et plateformes avec d’autres capacités, ces liens influencent les priorités.

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.