Category: La fonction informatique

Les transformations Solvency II en voie de réussite ont ouvert la porte à l’Architecture d’Entreprise

Posted on by admin

forces[1]A travers l’initiative Solvabilité II, le régulateur manifeste son intention de normaliser la manière dont les compagnies d’assurance doivent mesurer leurs risques, gérer leur portefeuille en conséquence et reporter leurs résultats en la matière à l’autorité de contrôle.

Un tel changement va conduire les entreprises à réorganiser leurs processus de pilotage: certaines tirées par une dynamique interne et désireuses d’obtenir des différentiateurs de marché, d’autres tirées principalement par les contraintes  réglementaires. Quel que soit le point de vue adopté, il va entrainer des transformations métier majeures et, pour certaines entreprises, une recombinaison via fusions/acquisitions afin d’optimiser leurs portefeuilles.

Heureusement, la plupart des acteurs ont lancé des programmes de transformation et, comme le précise l’enquête de Deloitte de 2011, plus de 52% des companies britanniques en étaient à la phase de mise en œuvre en 2011 avec 75% chez les plus grandes. Par ailleurs le même rapport indique que les budgets devraient être compris entre 1,2 m et 12m d’euros, les montants plus élevés étant le fait des très grandes organisations.

Mais, si les comités exécutifs semblent être conscients des nouvelles responsabilités et opportunités, les projets et programmes ont encore beaucoup d’incertitudes et de questions:

  • sur les méthodes de calcul du capital qui doivent encore être affinées et, pour certaines complètement spécifiées
  • sur les données qui doivent être collectées, traitées, vérifiées et validées pour chaque méthode de calcul
  • sur l’organisation qui doit définir les responsabilités pour chaque sous-processus et définir comment ils entendent les assurer
  • sur le management qui doit préparer les collaborateurs et demander les investissements pour les ressources

Au final, les transformations subissent deux forces opposées: les dépendances entre les différents aspects de Solvabilité II et les forces de la fragmentation engendrées par la démarche de projet adoptée pour faire face à la complexité  : d’ordre technique (actuaire, informatique, affaires, …) et sociale (acteurs, la gouvernance, l’influence, … ). La fragmentation technique provient de la nécessité d’adopter, même partiellement, une approche analytique. La fragmentation sociale vient du climat relationnel, de la culture business et de la compétition interne.

[…]

Pourquoi mes amis DSI ont besoin des meilleurs voeux possibles pour 2012.

Posted on by admin

Riskprojects1[1]Les DSI n’ont pas eu besoin de lire les rapports du Chaos Manor pour savoir que les projets sont toujours livrés en retard et jamais ou rarement en avance. Il sont en cela semblables aux voyages en avion ou en train pour lesquels l’expérience ne cesse de témoigner. C’est la conséquence d’une assymétrie des événements. Si nous mesurions ce retard, nous constaterions qu’un portefeuille de projets affichant deux mois de retard en moyenne, ne contiendrait pas ou peu de projets ayant un retard supérieur à 10 mois, mais contiendrait 30 projets avec un retard supérieur à 2 mois s’il avait une taille d’une centaine de projets.

De même, on constate que les budgets informatiques ont tendance à augmenter année après année. C’est inexorable tant que de nouveaux projets développeront de nouvelles fonctions qui devront être maintenues. Pour faire face à cette situation, les DSI ont installé un processus de gestion de portefeuille de projets : ils évaluent les projets selon plusieurs points de vue – technique, métier, risques, stratégie … – et établissent des priorités. Il en résulte que les projets de priorité basse sont reportés.

Passé quelque temps, les projets reportés s’empilent comme du sable et deviennent prioritaires. Ainsi, les budgets informatiques contiennent aussi des projets de faible priorité qui sont devenus prioritaires pour l’année budgétaire.

Finallement, les Directions métier considérent le processus de portefeuille de projets  comme un moyen de report au bénéfice de la Division IT. Celles-ci ne tiennent pas compte du fait qu’elles sont les principales sources des projets qui occasionnent la croissance du budget IT. En outre, si elles se plaingnent des coûts informatiques supplémentaires, si elles ne sont pas questionnés sur les gains espérés des projets pourtant mis sous leur responsabilité par les business case.

Quand un projet est retardé, les coûts augmentent généralement en proportion du temps. Ainsi le budget courant contient les dépenses en capital des projets passés en retard mais aussi leurs dépenses opérationnelles car ils ont déjà déployé des plates-formes.

Comme le budget courant contient le flot de projets passés retardés, il reste de moins en moins de place pour les nouveaux projets. Michel Volle a montré que la croissance est exponentielle. Les négociations avec les Directions métier deviennent alors de plus en plus difficiles. Les projets techniques sont examinés et souvent reportés ou refusés si ils ne présentent pas une forte économie de coûts ou une forte rentabilité. Il en va de même pour les composants techniques de projets métier qui ne semblent pas être nécessaire, même s’ils sont hautement souhaitables. Comment dans ces conditions construire une architecture ?

[…]

CESAMES ? Beaucoup mieux qu’Ali Baba

Posted on by admin

Qui n’a pas assisté à la conférence CESAMES qui s’est tenue “La Maison des Arts et Métiers”? Selon moi, tout le gratin de l’Architecture des systèmes et de l’Architecture d’entreprise était présent, tant l’endroit était bondé et a mobilisé plus de sièges que prévus. Pourquoi un tel succès? CESAMES est une association qui promeut une vision originale de Read more about CESAMES ? Beaucoup mieux qu’Ali Baba[…]

Votre métier a-t-il réellement changé ? Non ? Alors essayez l’architecture d’entreprise !

Posted on by admin

 

  • La plupart des front-office des grandes entreprises françaises sont des machines : sites internet, serveurs vocaux interactifs. Et quand ils ne sont pas automatisés, les opérateurs des centres d’appels sont difficiles à jondre, ils n’ont pas le bon niveau de compétence pour répondre aux questions des clients, et les clients doivent payer un surcoût par appel. Dans d’autres cas, la livraison est effectuée par des employés ou des sous-traitants qui ne sont pas en mesure d’endosser le point de vue de leur entreprise.
  • .
  • L’équilibre recherché se trouve entre l’augmentation du nombre des services offerts aux clients et la maîtrise des coûts de front-end. Toutes les opérations sont des processus exécutables et exécutés à moins qu’un grain de sable ne nécessité l’intervention d’un acteur humain pour rétablir une situtation imprévue qui peut devenir pesante pour un client. (Cf conférence comte de Bougainville )
  • .
  • Cette situation est souvent rencontrée chez les opérateurs télécoms, les opérateurs ferroviaires et les compagnies arériennes.
  • […]

L’Architecture d’Entreprise contre les silos d’information

Posted on by admin
Architecture d'Entreprise

Démarche d'Architecture d'Entreprise

Papier publié sur le Hub “Solutions Logicielles” en tant que membre de  l’équipe d’experts

Des unités d’affaires compétentes, hautement spécialisées, qui se développent chacune en suivant les orientations stratégiques de l’entreprise : n’est-ce pas une description parfaite des entreprises que nous connaissons ? Précisément. Car chaque unité d’affaire ou métier vérifie soigneusement les documents ou les informations qu’on lui transmet, les corrige, sans se soucier de savoir si une autre unité d’affaire l’a déjà fait. Elle exécute ses opérations, en contrôle la qualité avec des exigences élevées, et transmets le résultat sous une forme qu’elle estime la plus adaptée. Les systèmes d’information automatisent cette logique.

Au sein de ces organisations, dites en silos, la facture ne suit pas automatiquement la fourniture d’un service au client, on continue de vendre des services à des clients qui engloutissent la marge et on a du mal à établir une vision partagée du chiffre d’affaires.

Pourtant, avec le management par les processus et le Web, nous sommes dans l’ère de l’intégration : les opérations se font en temps réel, la production est tirée par la demande client. L’optimum global n’est plus la somme des optimums locaux.

[…]

Voulez-vous accroître les compétences de votre organisation sur l’Architecture d’Entreprise ?

Posted on by admin

La plupart des DSI, comme les managers en général, tiennent comme fondamental d’avoir accru les compétences de leur organisation. Ils ont davantage de chances d’atteindre, voire de dépasser, leurs objectifs et sont plus forts pour résister aux périodes difficiles. De plus, les collaborateurs qui ont progressé, font preuve d’une plus grande loyauté à leur égard et à celui de l’entreprise. Ces managers voient leur taux d’attrition baisser.

Pourtant,  l’architecture et l’architecture d’entreprise pourraient vous surprendre. Bien que vous ayez formé tous vos architectes, vous ne parvenez pas à accélérer le rythme des changements de l’architecture de votre système d’information. Cela parce que les architectes ne réalisent qu’une partie de l’architecture, les choix de conception et les décisions sont faits par les chefs de projet. Certaines entreprises ont même inventé le nom “Les chefs de projet technique” afin de promouvoir leurs architectes à la position de manager. Cela signifie que si vous avez investi pour le déploiement d’un framework comme TOGAF parmi vos architectes, vous pouvez sans doute, manquez votre retour sur investissement.

[…]

Quelles sont les nouvelles de la ligne de front des exigences ?

Posted on by admin

Lorsque l’IEEE s’est intéressée à l’ingénierie des exigences, elle a publié la définition suivante dans son standard IEEE Std 610.12.-1990: «Une exigence est : (1) Une condition ou une aptitude nécessaire à un utilisateur pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées.(3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).

RUP et les autres approches de développement de logiciels utilisent cette définition.

l’IIBA dans le BABOK 2,0 prend un court-circuit et élargit le périmètre de la définition de l’IEEE grâce au mot partie-prenante : “une exigence est (1) Une condition ou une aptitude nécessaire à une partie prenante pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées. (3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).

(1) concerne les exigences organisationnelles et métier tandis que (2) concerne les exigences de solution.

Pour le BABOK 2.0 (1) est découpé entre exigences d’entreprises classifient les objectifs globaux d’une organisation et les exigences des parties prenantes qui classifient les besoins des intervenants en particulier. (2) concerne les exigences fonctionnelles et non fonctionnelles.

Il est étonnant de voir comment l’IIBA a ignoré les initiatives d’Architecture d’Entreprise qui visent à renouveler la gestion des exigences au sein du cycle de vie de la transformation de l’entreprise.

Malgré tout, les exigences continuent à être collectées au travers des modèles que nous connaissons depuis les temps immémoriaux: IDEF0 , SADT , UML , BPMN , … avec quelques améliorations sur les exigences non fonctionnelles.

Alors qu’il y -t-il à la table de jeu?
[…]

Les systèmes d’information peuvent-ils vraiments être comparés à une ville ?

Posted on by admin

En classant ma documentation sur l’urbanisme des systèmes d’information, pourquoi tombé-je sans arrêt sur des articles ou des billets qui expliquent la pertinence de l’analogie entre le modèle urbain et les systèmes d’information ? En voilà quelques exemples : “Urbanisme des villes et urbanisme des systèmes d’information”, “L’apport historique de l’urbanisme des villes pour l’urbanisme des systèmes d’information” de Véronique Levasseur, ou bien l’Article de Wikipédia sur le même sujet.
[…]

Facteurs clés de succès de la transformation

Posted on by admin

La revue de l’AFAI a publié un article sur la gouvernance des SI et l’Architecture d’entreprise co-signé par votre serviteur. Dans sa conclusion, l’article propose les facteurs de succès de la transformation de l’entreprise : Une cible et une trajectoire partagées en cohérence avec la vision stratégique de l’Entreprise. C’est un objectif habituellement difficile, notamment Read more about Facteurs clés de succès de la transformation[…]