J’entends souvent la question suivante : L’architecture d’entreprise (EA) doit-elle être centrée sur la vision Métier ou Technologique ?

On parle aujourd’hui de plus en plus régulièrement d’architecture Business et on réalise facilement l’amalgame avec l’EA.

L’architecture Business n’est qu’un domaine de l’architecture d’entreprise qui, pour reprendre la définition donnée par TOGAF, en comporte quatre (Business, data, application, technology). Elle adresse la stratégie Business, l’organisation, les Business process clés et les interactions entre ces éléments. L’architecture d’entreprise adresse également la couche technologique permettant de supporter l’architecture Business.

La notion de capacité (capability) que l’on retrouve dans TOGAF est ici intéressante :
(Lire la suite…)

Cet article fait partie d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.

• Les systèmes mutualisés : enjeux et risques
• Les systèmes mutualisés : comment réaliser une gouvernance efficace
• Les systèmes mutualisés : démarrer et ne pas se perdre

Evaluer l’opportunité de lancer un projet de mutualisation et définir le périmètre d’un tel système n’est pas simple et doit faire l’objet d’une analyse en amont qui prend en compte plusieurs variables comme la valeur métier/sectorielle, l’homogénéité des processus dans les entités, etc. Dans ce contexte, l’article part de l’hypothèse que l’opportunité de mutualiser les processus de plusieurs entités de l’entreprise a été identifiée et que la décision de construire un système mutualisé est prise.

Pour réussir à mettre en place un système mutualisé, il faut non seulement réfléchir aux contraintes intrinsèques de la solution mutualisé mais aussi à celles liées au contexte de l’entreprise et à son organisation. Ceci dans le but de concevoir une solution unique faisant converger les processus tout en offrant suffisamment de souplesse pour permettre la subsidiarité nécessaire à chaque entité.

La construction d’un tel système représente un vrai challenge et un jeu de forces qui n’est pas simple à gérer. Néanmoins le projet peut être mieux maitrisé si dès le démarrage nous prenons en compte les éléments suivants :

• Définir le modèle de production et développement
• Définir la frontière entre le cœur et le spécifique
• Définir le niveau de mutualisation
• Concevoir un produit adapté pour maitriser la part du spécifique
• Assurer l’intégration dans des environnements divers
• Adopter une démarche itérative et incrémentale

(Lire la suite…)

Introduction

Cet article est le deuxième d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.

(Lire la suite…)

Cet article est le premier d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé et les enjeux d’un tel système, donner nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance.

Les systèmes mutualisés : définition

Un système mutualisé est un système implémentant des processus et des fonctions communes à plusieurs entités. Ainsi, des systèmes multi-entité, multi-pays, multicanal de distribution à destination de populations d’utilisateurs différentes et multi-ligne de marché sont des systèmes mutualisés. Par exemple, les systèmes suivants sont des systèmes mutualisés :

• En assurance : un système multi-ligne de marché de gestion des remboursements santé pour les assurances individuelles et les assurances collectives
• En banque : un système multi-pays de gestion des contrats commun à la France, l’Espagne et la Pologne
• En distribution : un système multi-ligne de marché et multi-pays d’encaissement, commun à des petites, grandes surfaces et magasins discount et installés sur l’ensemble de l’Europe
• En télécommunication : un système multicanal de souscription de contrat utilisé en boutiques, par les conseillers téléphoniques et par les internautes
• En industrie : un portail client multi-ligne de marché et multi-pays, commun à l’ensemble des divisions d’un grand groupe industriel

La problématique des systèmes mutualisés a déjà été abordée par OCTO lors de l’Université du SI : Les SI multi-entité.

(Lire la suite…)

Description

Un Minimum Viable Product (Produit minimal viable), abrégé en MVP, est une stratégie de développement de produit. Eric Ries, qui a fortement contribué à développer cette approche ainsi que le Lean Startup, nous en donne la définition suivante : «  le MVP est la version d’un nouveau produit qui permet à une équipe de collecter sur les clients  early adopters le maximum d’enseignements validés, et ce avec un minimum  d’effort »[1] .

En résumé il s’agit de réaliser rapidement un prototype de produit minimal, afin de vérifier l’existence d’un besoin, d’identifier le marché associé, et de valider les hypothèses business telles que la rentabilité.
(Lire la suite…)

C’est drôle, on sait tous qu’il n’y a pas, en informatique, de « silver bullet ». L’idée qu’une solution technique va tomber du ciel — ou du carquois d’un consultant — relève du voeu pieu, du deus ex machina, voire de la pensée magique.

Vous n’avez probablement pas obtenu vos diplômes parce que soudain quelques jours avant l’épreuve, vous avez trouvé LA technique idéale de mémorisation.

Vous savez que, statistiquement, l’EuroMillion n’enrichit pas ses clients (sinon les riches joueraient à l’EuroMillion).

Mais si vous êtes développeur, chef de projet, directeur d’études ou DSI, en revanche, vous êtes déjà probablement tombé dans le piège d’un nouvel outil ou d’une nouvelle technologie en vous disant : « Cette solution innovante va probablement marcher; en tout cas il le faut absolument (ou: en tout cas j’en ai vraiment envie). Je signe. »
(Lire la suite…)

Agile comme Lean partagent un objectif : réduire les temps de cycle. Or, livrer une version en production est souvent une opération chère. L’objectif de la livraison continue est de réduire au maximum ce coût. Jez Humble, de ThoughtWorks, a donné une formation jeudi 30 juin sur le sujet de la livraison continue. En voici les points clés.

(Lire la suite…)

Nous vous proposons ici de découvrir quelques aspects du lean en citations. Ces citations sont importantes, car pendant une expérimentation lean, elles amélioreront la compréhension et l’apprentissage des pratiques et outils lean. Elles agiront comme des moyens mnémotechniques en plaçant des refrains à nos chansons lean du quotidien.

Pour une présentation du lean, je vous conseille la lecture de cet article introductif : « Qu’est-ce que le Lean? ». J’aborde ici les principes et outils lean suivants :

• Le respect des gens
• L’élimination du gaspillage sur le flux de valeur
• L’amélioration continue

(Lire la suite…)

La performance des SI : une notion encore floue

Le CIGREF a publié le 6ieme opus de son cahier de recherche en faisant un retour sur la perception et les pratiques de 16 entreprises françaises en matière de performance et de valeur du SI.

L’une des premières observations est l’amalgame entre performance du SI et performance de la DSI. La frontière entre le système d’information en tant qu’actif de l’entreprise et l’organisation qui le maintient et le transforme est floue. Cela montre que le SI serait encore perçu comme étant la propriété de la DSI.

La seconde observation est que tous s’accordent sur le caractère critique et stratégique du SI pour les directions métiers dans l’exercice de leurs opérations. La performance du SI est devenue une nécessité pour le fonctionnement de l’entreprise mais également comme différenciant stratégique. Le SI contribue à la chaine de création de valeur via sa valeur d’usage par les directions métiers.

Ces deux points m’amènent à souligner le paradoxe de la perception de la propriété du SI. Si la valeur du SI tient à son usage, comment peut-il être la propriété de la DSI?

Les approches de la performance du SI

Progressivement, la DSI se déplace du rôle de bâtisseur à celui de gestionnaire d’actifs (et de son passif). Les méthodes d’évaluation de la performance doivent tenir compte de ce déplacement.

De nombreuses approches de la performance existent :

• Approche centrée sur les coûts (ratio, ABC, direct costing, feature costing, …) permettent une décomposition des coûts par service, processus et activité de la DSI
• Approche centrée sur les ressources stratégiques (balanced scorecard, Resource-based view, iC-dVal, …) permettent une analyse plus large que l’unique perspective comptable
• Approche centrée sur la valeur du SI (valeur destructive, coût d’opportunité, …) permettent une analyse intégrant la valeur d’usage du SI

L’ascendant du contrôle de gestion sur la valorisation de la performance imposerait à la DSI d’inclure dans son périmètre l’évaluation de la contribution du SI à la valorisation du capital immatériel de l’entreprise en tant que survaleur comptable et de se positionner comme un gérant d’actifs stratégiques.

Conclusion

En 40 ans de développement informatique dans les entreprises, la DSI est devenue progressivement plus un asset manager du capital immatériel plutôt qu’un industriel du logiciel. Les indicateurs de sa performance doivent évoluer vers une perception plus claire de la valeur du SI et de sa dette.

L’endettement de nos systèmes d’information

Ward Cunningham introduisait en 1992 la métaphore de la dette technique faisant une analogie entre les coûts futurs liés aux choix de conception logicielle et une dette financière. Celle-ci introduisait la nécessité de mettre en application des Design Patterns permettant de mieux maitriser la dette technique.

En 2009, Ward Cunningham revenait lors d’une interview sur le fait que l’objectif premier n’était pas d’apurer totalement la dette technique mais de s’attacher à la maitriser dans le temps.

Pour illustration, l’éditeur CAST Software a publié un rapport qui évalue le montant moyen de la dette technique à 2,82$ par ligne de code. Le sujet de la dette technique n’est pas tant le montant que son échéance – date à laquelle il devient nécessaire d’apurer la dette technique – et ses intérêts – surcoûts liés à une conception technique peu flexible.

Dette technique versus dette du SI

La dette technique désigne l’inadéquation technique d’un logiciel, qui peut être exigée par des demandes d’évolution futures. La nécessité de financer des évolutions de nos systèmes d’information peut provenir de bien d’autres sources :

• Evolutions fonctionnelles demandées par les utilisateurs
• IT refresh demandés par les éditeurs et les évolutions technologiques
• Evolutions organisationnelles (fusion, acquisition, externalisation, …)
• Evolution des paradigmes business (rollover market, multi-canal, servicing, …)
• Evolutions réglementaires (comptable, autorité de supervision, …)

La dette technique n’est finalement qu’une partie de la dette du système d’information.

Dans un autre article, je tentais d’approximer le montant minimum de la dette du SI à 55% du montant initial du projet sur 3 ans.

Rationalisation du SI

La rationalisation du SI a été successivement associée à une réduction des coûts, puis à de la ré-urbanisation du SI et de plus en plus à du downsizing du SI. A ce titre, le principal levier de la maitrise de la dette du SI est la réduction de la taille du SI.

Les outils de la rationalisation du SI sont multiples :

• Faire plus avec moins de lignes de code. Le rapport entre les technologies diffère fortement entre COBOL, C, Java, Ruby et .NET
• Zone rationalisée/Zone Sandbox métier. Dans une UPSI, nous évoquions l’intérêt d’une zone du SI non rationalisée permettant le prototypage permanent
• Minimiser les tailles des « socles » techniques plus difficiles à faire évoluer
• Maximiser les investissements SI « rentables », c’est-à-dire à forte valeur d’usage

Conclusion

Pour maitriser la dette de nos systèmes d’information, il est nécessaire de rompre avec nos réflexes qui nous incitent à glorifier la complexité et l’optimisation des coûts passés. Mon intime conviction est que la maitrise de nos systèmes d’information passe par le développement d’une compétence « d’asset manager de l’information » permettant de reconnecter la valeur d’usage aux investissements.