La crise économique, une opportunité à ne pas rater !
L’actualité financière et les perspectives économiques mettent sous pression les budgets des DSI. Les coups de rabot budgétaires ont le mérite de mettre en évidence les sujets perçus comme les plus importants et urgents.
Arbitrer entre maintenir à flot l’activité métier ou la transformer est un choix difficile pour chaque Direction : « run the business or change the business » ? Les investissements SI sont soumis également à ce dilemme.
Néanmoins, les entreprises qui sauront mettre à profit cette période troublée pour se transformer sauront en bénéficier plus tôt. Alors que celles, qui ne le feront pas, n’auront pas eu le temps de le faire avant la prochaine crise, qui les paralysera à nouveau.
Dans une logique de recentrage des investissements SI, la question est donc de bien identifier les sujets qui permettent d’obtenir une réduction significative des coûts opérationnels et de rentabiliser à court terme la transformation des activités. Il faut bien l’admettre, cet exercice nécessite une bonne dose de créativité et d’innovation.
(Lire la suite…)

Le BigData, une nouvelle (r)évolution pour les entreprises?

McKinsey a publié récemment un rapport sur l’avènement du BigData comme nouveau paradigme de compétition entre les entreprises.

L’analyse massive et le développement du capital informationnel (le BigData) deviendrait un nouveau levier pour la productivité, l’innovation et la croissance.

(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.

Depuis des années, nous avons toujours considéré, en France, que l’énergie électrique était une ressource disponible sans limite et à bas prix. Alors que penser du récent communiqué de presse de RTE concernant l’hiver 2009-2010 ?

En cas de baisse importante des températures en dessous des normales saisonnières (chaque 1°C en dessous de la normale saisonnière entraine une augmentation de la consommation de 2 100 MW, soit l’équivalent du double de la consommation de la ville de Marseille), RTE serait obligé d’effectuer des arbitrages dans sa distribution auprès de ses clients, notamment autour du pic de consommation vers 19h, au moment où les ménages allument leurs chauffages électriques, leurs télévisions et autres fours micro-ondes.

La limite technique d’importation d’électricité par RTE se situe à 7 à 8°C en dessous des normales saisonnières.
Aujourd’hui (Lundi 14 décembre 2009), nous sommes à 5°C en dessous et RTE importe tous les jours environ 4 000 à 5 000 MW pour couvrir la consommation des pics de 17h à 20h.

Bref, le système électrique français est sous tension.

Alors que les ménages allument leurs chauffages, vers 19h, c’est aussi le démarrage des batchs quotidiens de traitement des entreprises ou le milieu de la journée pour les opérations financières faites par les traders de New York.

Une limitation de la distribution en kWh provoquera l’activation des onduleurs et des générateurs de secours pendant quelques heures. Mais que se passera-t-il si la température baisse pendant plusieurs jours ?

Cette raréfaction du kWh ne semble pas si conjoncturelle que cela, comme le montre une étude menée par le Sénat Français . En effet, la consommation électrique a explosé en France (+11% sur les 5 dernières années) pour alimenter les systèmes de chauffage électrique et les industries, sans que les capacités de production puissent suivre (-0,2% sur les 5 dernières années). Selon le rapport d’étude du Sénat, le coût du kWh ne pourra plus être garanti à l’horizon de 2020.

A long terme, la problématique dépasse le cadre de l’optimisation des infrastructures IT, puisque la demande en énergie continue à augmenter toujours plus vite que la production. Cela devient une véritable problématique d’architecture des SI, qui doivent intégrer les limites énergétiques au même titre que les limites des débits réseaux ou de performance.

Compte tenu de l’éminence du risque (Décembre/Janvier 2010), les DSI doivent rapidement identifier une stratégie de préservation des systèmes critiques pour le métier basée sur des niveaux de baisse de températures.

Sources :

• RTE : Communiqué de presse de RTE
• Senat Français : http://www.senat.fr/rap/r06-357-1/r06-357-11.html

Depuis les années 80, de nombreux progiciels sont apparus sur le marché, sous la dénomination de Core Banking Systems (CBS), promettant de traiter de manière intégrée toutes les problématiques bancaires : de la gestion de comptes à la comptabilité, en passant par le e-banking et le CRM.

Cette proposition est alléchante en première lecture. Or, toutes les banques ne sont pas comparables. Au delà des métiers, toutes les banques n’ont pas la même taille. (Lire la suite…)

La mutualisation des back-offices est sur le papier une idée toujours assez tentante. Pourtant, dans la réalité, celle-ci peut devenir rapidement un enfer de complexité (et de coûts).

Voici quelques réflexions sur la mutualisation des back-offices bancaires et la façon d’aborder ce type de projet.

(Lire la suite…)

Chronique parue sur CIO-online.com, le 04 novembre 2008
(Lire la suite…)