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 :

Une capacité est définie comme une compétence qu’une organisation, une personne, un système possède. Je souhaite mettre en oeuvre la comptabilité de mon entreprise pour gérer mon bilan et mon compte de résultat, traiter mes factures. Je dois donc mettre une organisation de personnes en place réalisant des tâches (ponctuelles, réglementées, récurrentes), interagissant entre elles  ainsi qu’avec des fournisseurs et des clients. J’ai donc, dans le but de mettre en place cette capacité Business, conçu une architecture Business. Celle-ci est-elle suffisante ? Tout dépend de l’aptitude de cette architecture à réaliser les travaux qui lui sont confiés, les traitements de l’information. Si ma capacité a en charge la comptabilité d’un groupe international de plusieurs milliers de personnes traitant avec un nombre important de clients et de fournisseurs, de combien de personnes ai-je besoin pour mener à bien ma mission en temps et en heure? Comment ces ressources affectent-t-elles la rentabilité de l’entreprise ?

Si l’impact est important, on arrivera sans doute à la conclusion que l’architecture Business n’est pas suffisante à elle seule pour répondre à la mission de la capacité. Il est alors nécessaire de supporter cette architecture en faisant appel à la technologie. Elle induit cependant une complexité supplémentaire liée à la traduction de l’organisation et des activités business en besoins de traitements d’informations par des logiciels et du matériel technique.

L’architecture d’entreprise repose sur l’analyse transverse des composantes horizontales (au sens domaines de l’entreprise : métiers, support) et verticales (au sens couches d’architecture : processus métiers, services applicatifs, infrastructure) d’une entreprise dans le but de décloisonner les domaines pour faire émerger les processus transverses, de mieux gérer la complexité liée à une organisation et à ses besoins.

Le but de l’EA est d’accompagner l’entreprise dans ces changements, d’en maîtriser les impacts, de les faciliter. Elle permet à l’entreprise de construire ses capacités et d’assurer leurs interdépendances.
Ces changements interviennent au niveau Métier (changement d’organisation, de processus, changement de marché…) et bien sûr au niveau Technologique (obsolescence, innovation…).
Les architectures Métier et Technologique sont par nature des architectures sans cesse remises en cause. Je souhaite externaliser ma capacité RH, je fusionne avec une autre entreprise et je souhaite homogénéiser mes process et mes systèmes d’information, rationaliser mon infrastructure pour réduire mes coûts de possession.

Comment mesurer les impacts de ces besoins sur mes architectures en place et comment les maîtriser ? Sur quelle « constante » de l’entreprise s’appuyer pour faciliter mes changements d’architecture ?

Une bonne architecture d’entreprise est centrée sur ce qui fait fonctionner le Business et ce que traite la Technologie : l’Information.
C’est la maîtrise de l’Information, de sa transformation, de son cycle de vie, de son échange qui permet à une entreprise d’opérer efficacement ses changements.
Si j’absorbe une entreprise, comment l’intégrer à mon SI ? Qu’implique le lancement d’un nouveau produit ? Mes applications peuvent-elles supporter un changement d’organisation ? Comment puis-je améliorer la collaboration entre la comptabilité et le commerce pour confronter les visions réelles et prévisionnelles des résultats de l’entreprise ?

Tout est dans la compétence à gérer l’Information en adéquation avec sa valeur pour l’entreprise. Ces informations ne se retrouvent pas uniquement dans le SI. Il est donc utile de dépasser l’analyse SI et de l’enrichir de la vision métier dans le but de déceler de nouvelles opportunités. Mon service juridique n’est pas informatisé, je ne retrouve pas mes contrats dans le SI, ils me seraient utiles pour identifier mes clients.

L’Architecture d’Entreprise doit donc accompagner le choix Technologique ayant pour but de maîtriser l’Information et son utilisation pour répondre aux exigences Métier.

Le choix d’une technologie reposera sur différentes exigences : fonctionnalités attendues, capacité d’exploitation, coûts de mise en oeuvre, coûts de possession…Ces exigences sont bien souvent liées à des process et une organisation existant ou accompagnent leurs mises en place. En cas de changement d’organisation dans l’entreprise par exemple, ces exigences peuvent évoluer. Si la solution mise en oeuvre ne repose que sur ces exigences, elle doit faire l’objet d’une refonte majeure.

Ajoutons maintenant des exigences liées aux informations que je souhaite traiter ou sur lesquelles j’identifie une opportunité future de traitement. J’ouvre le champ d’analyse pour élaborer ma solution.

Si j’externalise la capacité RH de mon entreprise en choisissant un hébergement SaaS dans le but de réduire les coûts, à quelles difficultés puis-je m’attendre? Les fonctionnalités attendues sont le traitement des recrutements et des départs, la gestion des formations, la gestion des carrières, le relevé des activités, le calcul de la paye, les déclarations réglementaires et sociales…

Pour autant, cela ne signifie pas que mon SIRH sera coupé du reste de mon SI. Le calcul de paye implique par exemple des écritures comptables dans mes SI comptabilité. Si je souhaite mener une politique de gestion d’identité dans mon entreprise, j’ai besoin d’un référentiel de ressources humaines. Mon SIRH échangera donc des informations. Les difficultés interviendront si l’entreprise est dans l’incapacité de mettre en oeuvre efficacement ces échanges par manque de maîtrise de l’information (souvent liée à l’hétérogénéité de celle-ci dans les domaines métiers et SI). On passera alors pas des transformations multiples pour interconnecter les systèmes, difficiles à maintenir, complexifiant l’architecture et diminuant les bénéfices de la politique d’externalisation. Et si j’ai construit ma solution RH hier pour ne traiter que les employés de l’entreprise mais que je souhaite demain pouvoir traiter les contractuels, ai-je conçu mon modèle de données pour qu’il réponde à cette nouvelle exigence ?

Il convient de bien mesurer ces efforts dans ce travail d’analyse car on peut se perdre dans un puits sans fond.

Mon expérience me montre qu’en ajoutant quelques attributs à une information (entre 5 et 10 selon la complexité) ou en modifiant leur nature, on simplifie le système d’information.

Un employé et un contractuel sont deux informations métiers différentes. Si je m’arrête à cette affirmation, je proposerai sans doute deux solutions distincts pour traiter ces informations. Ainsi, pour un système RH dédié aux employés, les fonctions ou services qui le compose seront sans doute fortement influencés par l’information « employé ». Si je souhaite dans une évolution future traiter l’information « contractuel », l’aptitude du système à traiter cette nouvelle information sera moindre et le refactoring nécessaire important. En revanche, si je construis mon système initial pour qu’il traite l’information « ressource RH », je me place à un niveau d’abstraction supérieur, mon système possédera une capacité à gérer les dérivés « employé » ou « contractuel ». Je pourrai ainsi prévoir de traiter dans un premier temps l’information « employé » mais ne me fermerait pas de porte pour traiter ultérieurement l’information « contractuel ».

Amazon lorsqu’a été lancée sa plateforme d’achat en ligne ne proposait que des livres. Mais la plateforme n’a pas été conçue pour la vente en ligne de livre. Il ne s’agissait que du produit jugé le plus mature pour le démarrage de l’activité. L’idée dès le départ était d’être en capacité de vendre des « produits » au sens large. Les capacités business et systèmes dont s’est dotée l’entreprise ont été pensés dans le but de supporter cette stratégie.

Aligner la stratégie IT sur la stratégie Métier, c’est avant tout comprendre la valeur de l’Information Métier et comment celle-ci doit-être représentée et traitée dans le SI pour en tirer le meilleur avantage concurrentiel. L’Information est le pivot de l’architecture d’entreprise.

En savoir plus:

 Les organismes autour de l’EA

• l’Enterprise Architecture Research Forum (EARF)
• L’Open Group (TOGAF, Archimate)
• Le Centre d’Excellence en Architecture d’Entreprise (CEISAR)

Articles et études sur l’EA

• Gartner : une étude sur les 10 pièges pour l’architecture d’entreprise (2009)
• Article autour d’une étude du Forrester : Architectes d’entreprise : snobés mais tenaces (2010)
• Session USI sur le positionnement stratégique des cellules d’architecture transverse (2008)

Suggestion d'articles :

1. Vers une supervision IT de la performance métier du SI (2/2)
2. Transactions et traitement métier en Grails
3. Vers une supervision IT de la performance métier du SI (1/2)

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

Définir le modèle de production et développement

Notre expérience des systèmes mutualisés nous a montré l’importance d’avoir un modèle de production et développement pour éviter de perdre la cohérence du système dans le temps et d’assurer la qualité et l’évolution des fonctionnalités. On propose trois modèles :

Tracer la frontière entre le cœur et le spécifique 

Lors de nos expériences dans des systèmes multi-entités, on a pu constater que la définition du périmètre fonctionnel du cœur commun induit une complexité plus forte à cause du niveau d’hétérogénéité entre entités et qu’en absence de la définition claire d’une frontière cœur-spécifique pour que chaque partie ait une évolution et une gouvernance appropriée, les entreprises se sont retrouvées avec des versions très hétérogènes de la même application. En conséquence, l’enjeu de mutualisation[1] n’est pas accompli et l’application est difficilement gouvernable et couteuse à maintenir et à faire évoluer.

Pour tracer la frontière, au moment de la conception respectant l’approche bottom-up décrit par l’article précèdent [2] il faudra catégoriser toutes les fonctionnalités dans le Cahier de Charges en « communes aux entités », « communes avec subsidiarité » et « spécifiques » tout en respectant les limites définies (ex. spécifique < 20%). Les deux premières catégories feront parti du cœur commun et la dernière sera la partie spécifique à l’entité.

Définir le niveau de mutualisation 

En complément de la gestion des fonctionnalités, on doit aussi définir le niveau de mutualisation de ressources pour l’intégration, l’adaptation et le déploiement dans les entités. En fonction de l’homogénéité et le niveau de centralisation cible, on peut définir plusieurs niveaux de mutualisation de l’application:

• Niveau 1 : Ce niveau est le niveau plus haut de mutualisation dans le quelle tous les entités utilisent la même instance du logicielle. L’hébergement et toute évolution du cœur et du spécifique par entité sont gérés en central. Ce niveau est conseillé pour des applications très homogènes à travers les filiales qui n’ont besoin que de très peu de spécifique et que la connexion des utilisateurs à l’application peut être assuré.
• Niveau 2 : Le progiciel/logicielle est packagé ou construit au niveau groupe. Il existe un « cœur commun » de l’application développé qui est maintenu en central, cependant la partie spécifique est gérée par l’entité qui devra aussi héberger et maintenir une instance locale. Ce niveau donne plus de subsidiarité à l’entité et le groupe garde la maitrise du cœur de l’application. Ce niveau de mutualisation est conseillé pour les applications qui ont besoin de plus de subsidiarité ou qui doivent être installées localement pour garantir l’accès (ex. Sites isolés).
• Niveau 3 : C’est le niveau de mutualisation le plus faible. Les différentes entités utilisent la même application mais il n’existe pas le découpage entre le cœur et la partie spécifique car l’application est déployée indépendamment dans chaque entité et son paramétrage et son cycle de vie restent complètement indépendants entre les différentes entités. Dans ce cas on ne cible pas forcement l’homogénéisation des entités mais à faire des économies d’échelle dans l’achat des licences au niveau groupe

Concevoir un produit adapté pour maitriser la part du spécifique

Le système multi-entité devra être conçu avec des principes qui permettront de préserver la cohérence du cœur entre entités en permettant la gestion facile de la part du spécifique de chaque entité. Les mécanismes qu’on a pu recenser sont :

• Faciliter l’instanciation des classes : Pour faciliter les développements et la cohérence des parties spécifiques avec le cœur du système, il faut recourir au mécanisme d’héritage et utiliser des patterns d’instanciation de classes (factory, builder…). Ces mécanismes nous permettent d’étendre et de spécialiser les services proposés par le système sans toucher son noyau dont l’« équipe produit » aura le contrôle absolu.
• Cloisonner : A fin de préserver le cœur et de maitriser son évolution, il faut absolument séparer les développements spécifiques et le cœur du produit en cloisonnant les deux typologies de code dans des packages distincts.
• Limiter le nombre de branches dans le code : Il faut faire attention à ne pas multiplier le nombre de branches dans le code. La situation extrême étant de créer une branche pour chaque entité. L’idéal serait de limiter les branches à 2 : une branche de la dernière release stable du système et une branche de développement pour la release suivante.
• Respecter un déploiement strict des versions : La discipline sur la migration est essentielle et pour éviter les écarts entre les versions des entités. Nous recommandons de ne pas dépasser la limite d’une release de décalage entre la version actuelle du cœur et celle déployés dans les entités. L’idéal étant que toutes les entités aient en production la même version.
• Définir des paramètres système : Ils facilitent la customisation de l’application sans avoir besoin de modifier le code. Ex : Pays, langue, taux d’intérêt, coût d’une prestation entre autres. Il faut être vigilant pour maitriser cet aspect en documentant tous les paramètres (fonction, impacts), en traçant les changements et en mettant en place des tests automatisés qui puissent être joués pour l’ensemble des paramètres supportés. Il devient difficile de gérer une application si le nombre de fonctionnalités paramétrables explose, particulièrement en l’absence de recette automatisée.
• Utiliser les tables de paramétrage de règles de gestion: Ces tables sont similaires aux paramètres système mais elles permettent de customiser des règles de gestion sans modifier le code.
• Prévoir des appels à des scripts externes au cœur : Dans le cœur du système on peut prévoir des appels à des méthodes implémentés toujours dans la partie spécifique du code. Ce pattern est valable pour certaines fonctionnalités identifiées comme étant toujours propres aux entités. Cependant il faut prendre des précautions en recourant à ce pattern car le code commun devient dépendant d’un code externe au système.

Assurer l’intégration dans des environnements divers

Un système qui est censé cohabiter avec des systèmes diverses dans des environnements hétérogènes, doit être conçu avant tout comme un système facilement intégrable pour assurer sa permanence et son adoption. Souvent on dépense beaucoup des efforts dans la transformation des données, la standardisation des flux et l’interdépendance entre systèmes, pour cela il faut toujours concevoir dès le début un système qui respect les principes de:

• Modularité : Les systèmes mutualisés à déployer dans les entités doivent être des systèmes avec des couplages faibles et disposant d’une autonomie d’exploitation et d’utilisation à fin de faciliter son intégration et de lui donner une étanchéité vis-à-vis des évolutions dans les environnements des entités, de limiter les déploiements des systèmes annexes nécessaires et l’usage des données externes au système.
• Cohérence : Il faudra utiliser un dictionnaire de données commun aux entités. Elles définissent ensemble et acceptent un format pivot qui doit être utilisé en priorité lors des échanges de données dans le SI.
• Compatibilité : Les échanges du système mutualisé devront se faire en priorité via une infrastructure d’échange commune. En absence de cela, le système devra être en mesure de mettre en place des échanges via de services contractualisés basés sur des standards à la fois fonctionnels et techniques.
• Décommissionnement du système remplacé : Toute projet de mise en place du système multi-entité doit porter le décommissionnement des systèmes qu’il remplace. Le non décommissionnement d’un système ne doit se justifier qu’en regard de la non reprise totale de fonctionnalités par le nouveau système.

Adopter une démarche itérative et incrémentale 

OCTO préconise toujours l’adoption d’une méthodologie agile où la construction se fait avec une démarche itérative et incrémentale[3] avec la mise en place de tests automatisés[4]. Dans le cadre des projets multi-entités, ils s’avère nécessaire pour maitriser le risque et la complexité qui est plus présente que dans de projets mono-entité, pour maitriser tous les changements de paramétrage et assurer la non régression avec les évolutions spécifiques.

En conclusion

Les systèmes multi-entités sont porteurs de bénéfices pour le business (homogénéiser les pratiques et réduire les coûts) mais ils ne devront pas être traités comme des systèmes conventionnels. Il faudra toujours considérer les risques spécifiques à ce type de démarche[5], mettre en place une gouvernance appropriée[6] inspiré des éditeurs logiciels en adoptant une démarche orientée produit  et on devra concevoir le système avec des pratiques d’architecture et de développement adaptées aux particularités d’un tel système pour qu’il puisse vraiment aider répondre aux attentes business sans bouleverser le fonctionnement de l’organisation et du systèmes d’information des entités cibles.

Suggestion d'articles :

1. Les systèmes mutualisés : enjeux et risques
2. Les systèmes mutualisés : comment réaliser une gouvernance efficace ?
3. La dette de nos systèmes d’information

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.

1. Quel modèle de gouvernance pour un système mutualisé?

Notre expérience des systèmes mutualisés nous a conduit à deux constats.

Premièrement, nous avons remarqué que les Directions des Systèmes d’Information avaient beaucoup de mal à construire des systèmes multi-entités[1]. Effectivement, beaucoup de nos clients qui se sont lancés sur cette voie ont rencontré de nombreuses difficultés et le ROI espéré n’était pas au rendez-vous. Malgré la diversité de ces clients en termes de secteurs et de tailles, ils partageaient le fait que, pour construire le système mutualisé, ils avaient adopté la même approche projet que pour les autres applicatifs de la DSI (qui ne sont pas multi-entités). Ce constat nous amène à penser que les modèles classiques de gouvernance des projets SI ne sont pas adaptés à un projet d’application multi-entités.

Deuxièmement, nous avons observé qu’un système mutualisé ressemble plus à un progiciel qu’à une application classique. En effet, comme un progiciel, un système mutualisé a vocation à être utilisé par plusieurs « clients internes »: filiales dans plusieurs pays, différentes directions métier… De plus, il doit gérer, en même temps, les fonctionnalités communes et les spécificités de chaque « client ».

Additionné au premier, ce dernier constat nous amène à la conclusion que la meilleure manière de construire un système mutualisé est d’adopter une posture d’éditeur ce que plusieurs expériences concrètes nous ont permis de vérifier.

Dans la suite de cet article, nous allons vous fournir plusieurs recommandations vous permettant d’aborder un projet de système mutualisé avec une posture éditeur. Ces recommandations sont tirées de nos retours d’expérience et des bonnes pratiques du monde de l’édition logicielle.

2. Qu’est-ce qu’une posture éditeur ?

Prendre une posture éditeur se traduit par adopter une approche « Produit » au lieu de l’approche « Ressources » habituellement appliquée dans les DSI.

En effet, avec une approche « Ressources », le premier rôle de la DSI est de mettre à disposition des ressources informatiques capables de mettre en œuvre les fonctionnalités demandées. Par conséquent, l’équipe projet possède un rôle assez « passif »  consistant à répondre de manière spécifique aux besoins exprimés du ou des clients (voir Figure 1). Par contre, dans l’approche « Produit », l’équipe projet doit avoir un rôle beaucoup plus « actif ». Ce rôle, consiste à définir elle-même des réponses cohérentes aux besoins des clients (voir Figure 2). Ces réponses peuvent prendre plusieurs formes :

• Une fonctionnalité qui répond de manière spécifique à un seul besoin exprimé
• Une fonctionnalité qui répond à plusieurs besoins similaires
• Une fonctionnalité qui répond à un besoin ressenti par l’équipe projet et non exprimé par les clients

Suggestion d'articles :

1. Les systèmes mutualisés : démarrer et ne pas se perdre
2. Les systèmes mutualisés : enjeux et risques
3. Buzz war : Alignement stratégique et gouvernance

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

Dans cette série d’articles nous partons du principe qu’un système mutualisé implémente des processus métier. Nous n’aborderons pas la problématique des briques « techniques » : par exemple, un reverse proxy commun ou un serveur d’application (ré) utilisé pour toutes les applications du SI est une brique technique mutualisée, mais pas un système mutualisé.

Enjeux des systèmes mutualisés

Pour ne pas se tromper lors de l’étude d’opportunité précédant un projet de mutualisation, il convient de définir clairement les objectifs et le périmètre d’une telle brique et de mesurer les risques de sa mise en place. Le but principal poursuivi est de réduire des coûts par la rationalisation des moyens SI et l’uniformisation des processus.

Le premier enjeu associé à la mise en place d’un système mutualisé est bien évidemment la convergence des processus et patterns métier. Ainsi nous ne préconiserons jamais le démarrage d’un projet de système mutualisé s’il n’existe pas une volonté forte de faire converger et d’unifier les processus métier ou à minima de fédérer des patterns fonctionnels.

Le but est la rationalisation et la réduction des coûts, cependant la mise en place d’un système mutualisé doit s’appuyer sur une stratégie métier et SI favorable qui ne peut se réduire à un objectif de diminution des coûts informatiques.

Par exemple, HSBC s’est appuyé sur sa stratégie métier (nous pourrons nous limiter au slogan « Votre banque, partout dans le monde » pour nous en convaincre) pour mettre en place un système multi-pays de gestion des comptes clients. Ce système mutualisé – au-delà de la simple réduction des coûts – permet à ses client d’effectuer leurs opérations bancaires dans n’importe qu’elle agence de la même façon qu’à l’agence dans laquelle ils ont ouvert leur compte.

Si la volonté de faire converger les processus métier existe et que cette convergence est réalisable, encore faut-il s’assurer d’obtenir :

• Une vision partagée du système que l’on souhaite construire. Cette vision doit permettre de comprendre pourquoi on souhaite faire ce produit, de le « vendre » aux entités et de fédérer les acteurs du projet
• Un périmètre métier clair. On pourra par exemple commencer par identifier et classer les processus et patterns fonctionnels communs, pour ensuite identifier le périmètre dans lequel la mutualisation est possible.
• Un sponsor, porteur et garant de la vision produit. Ce sponsor doit disposer d’un poids politique important au sein du groupe et auprès des entités et d’un leadership fort. Il doit posséder un réel intérêt pour le produit et l’enjeu de mutualisation des processus métier
• Une équipe compétente et stable pour définir et réaliser le cœur du système. Ce pré-requis à la réussite d’un projet de mutualisation sera détaillé dans un article à venir.
• Une gouvernance adaptée à un système multi-entité, avec notamment une capacité d’arbitrage forte. Cela fait également l’objet d’un article à paraître.
• Un système d’incitation (par exemple rémunération et bonus lié à des objectifs) aligné sur les objectifs de la mutualisation.

Risques associés aux systèmes mutualisés

Les risques afférents à un système mutualisé sont importants, nous décrivons ici les deux risques majeurs à traiter impérativement dès le démarrage et au cours du projet. Le premier est celui de non adoption ou de refus du système par les entités, lorsqu’il est avéré, il conduit en général à l’arrêt et à l’échec du projet de mutualisation (c’est à dire à l’arrêt du projet, ou à l’utilisation du système par une seule entité). Le second est celui de l’explosion des coûts afférents au système mutualisé : ce risque est – comme nous allons le voir – d’autant plus important lorsque le projet de mutualisation est en succès !

Nous vous proposons de décrire les facteurs de risques aggravants les plus importants et le plus souvent rencontrés lors de nos missions.

• Augmentation du temps et du nombre d’intervenants entre les besoins exprimés et leur concrétisation

Dans un projet de système mutualisé, et au fur et à mesure que le nombre d’entités devient important, les étapes de traitement entre l’expression des besoins par les entités et la réalisation de ceux-ci se multiplient.

Voici un schéma représentant l’organisation simplifiée rencontrée chez l’un de nos clients permettant de réaliser un système mutualisé. Ce schéma ne fait apparaître que deux entités et laisse de côté les besoins de maintenance.

fig 1. Système mutualisé - De l'expression de besoin à la mise en production

Les étapes de traitement entre expression de besoin et réalisation sont nombreuses et leur nombre s’accroisse avec le nombre d’entités utilisant le système.

Le nombre d’intervenants dans un projet de système mutualisé est important. Cela génère du risque, particulièrement si la vision produit n’est pas partagée ou si le sponsor projet manque de visibilité.

• Intervenants n’ayant pas l’habitude de communiquer/travailler ensemble

Par ailleurs, de part leur nature, les projets de système mutualisé font intervenir et travailler ensemble des intervenants d’entités différentes. Souvent ces intervenants sont de cultures et de langues différentes. Parfois ceux-ci ne réalisent pas de la même façon un projet informatique. Cela nécessite de tenter de stabiliser au maximum les équipes du projet dans les entités et en central.

• Imposition du système aux entités par le groupe

Comme pour la plupart des projets informatiques, il est nécessaire de piloter une phase de changement, particulièrement lorsque la volonté d’unifier les processus métier au niveau groupe impose de faire évoluer les processus et outils de certaines entités.

• Favorisation de l’entrée d’une entité dans le projet au détriment de la qualité du système mutualisé

Pour déclencher l’entrée d’une nouvelle entité dans le projet, particulièrement lorsque celui-ci démarre, il n’est pas rare d’observer une tendance trop importante au clientélisme. Ainsi l’équipe centrale peut, pour accélérer l’adoption du système, accepter l’entrée d’une importante part de fonctionnalités et modifications spécifiques à l’entité dans le cœur du système.

En distribution, nous sommes intervenus auprès d’un grand groupe multi-pays et multi lignes métier qui s’est doté d’une brique mutualisée d’encaissement. La solution s’est rapidement trouvée adoptée grâce à une stratégie SI favorable et à un sponsorship fort. En quelques années la solution était déployée dans une dizaine d’unités répartis dans plusieurs pays. La multiplication des entités disposant chacune de leurs processus métier, et des pays avec – notamment – leurs contraintes réglementaires propres a entrainé :

• La multiplication des versions du progiciel en production
• L’augmentation très forte de la dette technique de l’application (ex : gestion du code spécifique/ gestion du code commun)
• La multiplication des paramétrages possibles de l’application pour répondre aux différents besoins métier
• Et ainsi, l’explosion des coûts de maintenance

• Entités ayant un poids politique différents au sein de l’entreprise

Lorsqu’un système mutualisé est utilisé par plusieurs entités dont l’une est plus « puissante » que les autres au sein de l’entreprise, il n’est pas rare de constater une dérive des besoins communs vers les besoins spécifiques de cette entité.

Ce facteur de risque est réduit par la présence d’un sponsorship fort et une gouvernance adaptée.

• Cadres réglementaires différents

Ce facteurs de risque, rencontré notamment pour les systèmes multi-pays peut mener soit à la non adoption du système par l’entité à la règlementation jugée exotique, soit à l’affaiblissement de la qualité du système qui tenterait d’implémenter dans son cœur des réglementations antagonistes.

fig 2. Système mutualisé - Synthèse des facteurs de risques

Ainsi, lorsque l’on étudie la possibilité de mettre en place un système mutualisé le bénéfice financier attendu est important et les moyens d’y parvenir nombreux. Cependant les écueils possibles le sont également et beaucoup doivent être évités dès le démarrage du projet. Nous allons maintenant vous proposer nos recommandations pour démarrer et maintenir dans la durée un système mutualisé. En gardant à l’esprit que celles-ci ne sont pas adaptées à tous les environnements et tous les projets.

Suggestion d'articles :

1. Les systèmes mutualisés : démarrer et ne pas se perdre
2. Les systèmes mutualisés : comment réaliser une gouvernance efficace ?
3. La dette de nos systèmes d’information

Il y a peu, je participais à une réunion de travail impliquant une trentaine de personnes et j’ai fait une observation qui m’a intrigué. Avez-vous remarqué ce qui se produit lorsqu’un téléphone portable sonne au cours d’une réunion ?

• La personne propriétaire du portable l’éteint rapidement
• Tous ceux qui ne l’avaient pas encore fait vérifient leur portable et activent discrètement le mode silence.

Voilà un exemple de mesure préventive particulièrement efficace! Dans les entreprises où l’on respecte un certain standard de réunion, l’exception que constitue la sonnerie d’un portable ne se produit qu’une seule fois, pas deux. La première “infraction” protège le groupe de toute nouvelle occurrence. Elle agit en quelque sorte comme un “vaccin” sur le fonctionnement du groupe en réunion.

Quelles conditions faut-il réunir afin de créer d’autre vaccins de ce type au sein d’une équipe ? J’en vois au moins trois :

• Qu’il existe un standard explicite ou implicite pour le groupe
• Que l’écart au standard soit détectable rapidement par tous les membres du groupe
• Qu’une prévention des futurs écarts soit possible sans confrontation supplémentaire

Y a t’il des activités de groupe — autres que les réunions — dans lesquelles un vaccin de ce type pourrait fonctionner ? Bien sûr ! Par exemple, certaines équipes de développement utilisent un lapin Nabaztag qui “écoute” en permanence les résultats du serveur de build continu. Ici le standard est que le code déposé par chacun sur le serveur doit passer tous les tests. Lorsque ce n’est pas le cas, le lapin remue les oreilles et dénonce immédiatement l’auteur de l’infraction. Cet évènement incite ledit auteur à réparer le build, et les autres développeurs à toujours mieux vérifier le passage des tests sur leur code avant de le déposer.

Il existe d’autres moyens que le test pour détecter les défauts d’un système en cours de développement. D’après Wikipedia, une analyse faite par Capers Jones sur 12000 projets de développement à montré que le taux de découverte des défauts latents par des inspections formelles se situe entre 60% et 65%. Pour les inspections informelles, le chiffre est inférieur à 50%. Pour les tests en général, le taux de découverte des défauts latents est d’à peu près 30%.

L’inspection formelle, également appelée “revue de code” constitue une mesure de prévention particulièrement puissante pour améliorer en continu la qualité de vos développements. C’est une amélioration générique, qui fonctionne donc également comme un “vaccin” :

• Il existe un standard (correction du code, règles de codage, de lisibilité, de modularité, d’architecture, de couverture par les tests etc).
• L’écart au standard (erreur de logique ou infraction au standard) est détecté rapidement par tous les membres de la revue (le code étant rétroprojeté).
• Après la revue les autres participants peuvent rechercher et corriger rapidement des écarts similaires sur leur code, sans confrontation supplémentaire.

A court terme, la revue permet aux participants — même les plus novices — d’apprendre de nouvelles choses (sans avoir à poser des questions embarrassantes). A moyen terme, son usage régulier réduit significativement le nombre de défauts du système. A long terme la revue de code contribue à créer une culture de la qualité logicielle dans votre entreprise.

Comme dans le cas des vrais vaccins, ce type d’amélioration générique ne va pas sans quelques inconvénients ni réticences. Lorsque vous mettrez en place une stratégie de revue de code, vous rencontrerez très certainement des objections:

- “Mobiliser chaque semaine tous les développeurs va coûter cher et mettre le projet très en retard !”
- “Ici, il n’y a pas de standard de qualité du code !”
- “Ici dès qu’on échange sur le code ou le design cela finit par des débats houleux !”
- “On a déjà essayé de faire des revues et c’était vécu comme du flicage !”

Ces obstacles peuvent être surmontés. Apprenez à mener des revues de code. Mesurez le coût de la non-qualité sur votre projet; essayez des revues de code régulières pour une période de trois mois, puis mesurez le à nouveau. Si votre équipe respecte déjà le standard “pas de sonnerie intempestive en réunion” qu’est-ce qui l’empêche de respecter des standards encore plus cruciaux pour votre entreprise ?

Suggestion d'articles :

1. USI 2011 est à la recherche de ses speakers !
2. OCTO recherche un(e) assistant(e) RH: activez vos réseaux!
3. Ma lecture de l’architecture de Percolator : un composant du moteur de recherche Google

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.

Le rapport met en évidence 5 clefs pour tirer profit du concept de BigData :

• Make big data more accessible and timely. Transparency, enabled by big data, can unlock a great deal of value. In the public sector, increasing access to data across separate departments can sharply reduce search and processing times. In manufacturing, integrating data from R&D, engineering, and manufacturing units to facilitate concurrent engineering can cut time to market.
• Use data and experiments to expose variability and raise performance. As organizations create and store more transactional data in digital form, they can collect more accurate and detailed performance information on everything from product inventories to sick days.
• Segment populations to customize. Big data allow organizations to create ever-narrowing segmentations and to tailor services precisely to meet customer needs. This approach is well known in marketing and risk management but can be revolutionary in areas such as the public sector.
• Use automated algorithms to replace and support human decision making. Sophisticated analytics can substantially improve decision making, minimize risks, and unearth valuable insights that would otherwise remain hidden. Such analytics have applications from tax agencies to retailers.
• Innovate with new business models, products, and services. To improve the development of next-generation offerings and to create innovative after-sales services, manufacturers are leveraging data obtained from the use of products. The emergence of real-time location data has created a new set of location-based mobile services from navigation to people tracking.

Y aura-t-il un impact dans la manière de concevoir les SI?

Les technologies de stockage et de traitement de données sont en train de connaitre probablement une évolution aussi importante que l’apparition des serveurs d’applications. Le monde des technologies NoSQL, CEP et BI est en train de vivre sa révolution. Mon point ne porte pas tellement sur l’émergence de nouvelles technologies challengeant l’hégémonie des bases de données relationnelles traditionnelles, mais plutôt l’implication de BigData en matière d’architecture de SI.

Depuis 20 ans, nous concevons des SI alignées sur les processus métiers des organisations pour permettre l’amélioration de la productivité des entreprises par l’automatisation des processus. Ce même souhait nous a fait aboutir à des systèmes d’informations segmentés par grandes familles de processus (front, back , support, pilotage, transverse, etc.)

Sans le dire, BigData nous fait passer d’une logique de commoditisation des processus métiers à celle de l’exploitation d’un actif (mal identifié) de l’entreprise : l’Information.

Dans un précédent article, je mettais en lumière la double position du SI en tant que commodité ET actif de l’entreprise.
Le BigData met un mot pour qualifier un SI, actif stratégique, capable de faire émerger les nouvelles opportunités business, de tarifier au plus fin sur la base des comportements réels des clients, de casser les asymétries d’information qui freinent la collaboration entre les entités des organisations,etc.

Comment pouvons bâtir de tels SI en utilisant des principes d’architecture qui favorisent le cloisonnement plutôt que le partage de l’information et qui repose sur la mise en œuvre d’expression de besoin pré-identifiée?

Un SI qui maximise la valeur de l’information d’une entreprise peut-il avoir une architecture cloisonnée entre informations front office et back office? La construction à-côté d’un SI Décisionnel alimenté par le SI Opérationnel pourra-t-il permettre de réagir suffisamment vite et de prendre des décisions rapidement?

Comment définir un SI qui tire profit des BigData?

L’article suivant identifie des caractéristiques clefs de l’information en tant qu’actif de l’entreprise.

Un SI BigData devrait donc être

• Partagé : Tout le monde accède à la même source d’information
• Utilisé : Utilisé par tous – collaborateurs, clients, partenaires, fournisseurs, …
• A date : La notion de courant/historisé disparaît au profit d’une notion de date d’événement, proche de celle de la date de valeur (passée, présente et futur)
• Précis : Toutes les données brutes sont présentes et rattachées aux informations de plus haut niveaux
• Comparable/Combinable : Les informations reposent sur les mêmes données brutes pour pouvoir être comparées et combinées?
• Piloté par la valeur : le traitement de l’information (par opposition à celui des données) est consommateur en temps et énergie, il convient de choisir ses informations pour ne pas perdre en productivité
• Réutilisable : l’information doit pouvoir servir de base à une autre

Conclusion
Avec le BigData, la forme de nos systèmes d’information pourrait bien changer. Imaginez le SI d’une banque avec un immense nuage mondial de données d’événements de gestion de compte qui permettrait aux front de connaitre le comportement de chaque client, de proposer des produits totalement personnalisés, de décloisonner conseiller agence, banque en ligne, conseiller en patrimoine, etc.

Suggestion d'articles :

1. Petit-déjeuner MapReduce-La révolution dans l’analyse des BigData le 27 septembre
2. A quand de vraies architectures Stateless?
3. Architectures Web : 3 questions à Jean-François Caenen

En 2007 ITIL (IT Infrastructure Library), a lancé sa version V3 en devenant le référentiel le plus répandu de bonnes pratiques pour le management de services informatiques (ITSM). Il se focalise sur le « comment » gérer chaque phase d’un service, en contraste par rapport à des autres référentiels qui se focalisent sur le « quoi », ce qu’on doit gérer.

ITIL v3 élargit le périmètre en donnant une vue “cycle de vie” des services, par rapport à sa deuxième version (v2) qui se focalisait sur les processus pour le Soutien de Services (Service Support) et la Fourniture de Services (Service Delivery)[i],

Cet article vous présente d’une façon globale ITIL à l’égard de la version 3 en montrant son but, les bonnes pratiques proposées pour gérer chaque phase d’un service et ce dont il faut tenir compte pour l’adoption de ce référentiel.

Tout d’abord, qu’est-ce que c’est un service ?

ITIL entend par service « l’ensemble des moyens mis en œuvre pour produire de la valeur pour un client, sans que celui-ci n’en supporte ni les coûts spécifiques et supplémentaires ni les risques associés ». En conséquence, une relation client-fournisseur est établie, le fournisseur du service pouvant être interne ou externe à l’entreprise. Pour illustrer l’idée d’un service, voici une liste de services :

• Services d’hébergement (applications, bases de données, sites internet, …)
• Service de support et maintenance applicatif
• Services de messagerie (Email, chat, …)
• Service de connectivité (internet, vpn, …)
• Service de vidéo conférence et de téléphonie
• …

Pour quoi un référentiel sur le management de services informatiques ?

Les DSI et les fournisseurs de services externes doivent :

• Fournir des services à valeur ajoutée au métier
• Rendre un service de qualité en respectant les contrats de service et les coûts
• Augmenter la flexibilité et la rapidité du système pour intégrer les mises à jour des services existants et la mise en place de nouveaux services, tout en sécurisant l’existant

Pour atteindre ces objectifs il faut mettre en place une organisation horizontale de collaboration entre les différents acteurs (clients, métier, conception, développement, exploitation, qualité,…).

ITILv3 cherche à vous aider à assurer ce rôle de fournisseur de services d’une façon efficace et il vous fourni de bonnes pratiques pour savoir:

• Comment créer et gérer un portefeuille de services ?
• Comment concevoir des services qui donnent de la valeur (alignement métier-SI)?
• Comment améliorer et sécuriser les mises en production de nouveaux projets et de changements tout en préservant l’existant ?
• Comment traiter plus efficacement les incidents, événements et les problèmes dans le SI ?
• Comment gérer les changements des actifs et les configurations?
• Comment mettre en place des mesures et des indicateurs dans les processus de la DSI pour améliorer la gouvernance ?
• Comment assurer la disponibilité, la continuité, la sécurité, la capacité et la fiabilité de services ?
• Comment formaliser les compromis client-fournisseur et comment on définit des contrats de niveaux de service (SLA ou Service Level Agreements), contrats de niveaux d’exploitation (OLA ou Operational Level Agreements) et contrats de sous-traitance (UC ou Underpinning Contracts) ?
• Comment mettre en place une amélioration continue des services ?
• …

Alors ITILv3 vous propose :

• Un découpage du cycle de vie d’un service en 5 phases :

  

  Image 1.  Phases du cycle de vie

  Stratégie de services :

  Transformer le SI en un actif stratégique de l’entreprise en identifiant les besoins des clients pour définir les services qui produisent de la valeur et que respect le coût de fourniture. Il se traduit par la construction d’un portefeuille de services.

  Conception de services :

  Concevoir un service en prenant en compte tous les éléments liés au development et á l’exploitation. La solution doit réponde aux attentes du client, aux niveaux de service engagés et à ce qu’ils soient en phase avec la capacité de l’infrastructure et l’architecture du SI.

  Transition de services :

  Mettre en place de nouveaux services et de mises à jour dans un environnement de production d’une façon sécurisée et effective en préservant la bonne exploitation du système.

  Exploitation de services :

  Assurer la bonne fourniture du service aux utilisateurs en respectant les niveaux de services engagés. Assurer le monitoring du service, la bon gestion des incidents et des problèmes ainsi que le traitement de demandes de services et d’accès.

  Amélioration continue de services :

  Mesurer et suivre les différents processus de gestion de services pour aider à définir les actions correctives afin d’améliorer les services existants et son alignement avec les objectifs stratégiques.

• Une mise en place de processus standard pour chaque phase du cycle de vie et la création de 4 fonctions ou unités fonctionnelles:

Image 2.  Processus et fonctions ITIL v3

• Une définition des activités et interactions par processus

Image 3. Activités du processus de gestion des événements.

• Une définition de rôles et responsabilités par processus (Matrice RACI)

• Une définition de mesures et indicateurs par processus (KPI)

Ne pas oublier !

Si vous voulez implémenter ITIL dans votre organisation n’oubliez pas :

• De définir les objectifs organisationnels. L’objectif ne peut pas être « mettre en place ITIL », cette démarche doit répondre à un besoin d’amélioration dans l’organisation.
• De former et sensibiliser les acteurs pour que tout le monde soit familiarisé avec les termes, les objectifs et les gains qui emporte la démarche. ITIL implique un changement organisationnel et culturel au sein de l’entreprise donc il peut être difficile à implémenter si tout le monde ne partage pas la même vision.
• D’analyser votre organisation actuelle et identifiez le GAP qu’il y a par rapport aux meilleures pratiques pour identifier où ITIL peut vous aider.
• De définir une roadmap par phases en priorisant les processus qu’à la fois vous donne plus de valeur (pour atteindre les objectifs définis) et qui sont plus simples à mettre en place. Ne pas faire un « Big Bang ».
• De mesurer dès le début! La seule façon de savoir si vous atteignez les objectifs est de définir des indicateurs et mesures qui vous indiquent le progrès et la performance de vos processus.
• De mettre en place un cadre d’amélioration continue. Les processus ont besoin d’évoluer, d’être ajustés et d’être optimisés à travers le temps pour qu’ils soient bien adaptés spécifiquement à chaque organisation et qu’ils accompagnent les évolutions métier.

Complémenter ITIL

ITIL peut être complémenté et peut cohabiter avec des autres référentielles comme COBIT, ISO 27002, CMMI, etc. Des autres méthodologies comme le Lean peuvent encore améliorer les processus qui ont été mise en place (Lean-ITIL)[ii]. Un seul référentiel ne fait pas tout et même si dans sa version 3, le périmètre d’ITIL a été élargi, il ne couvre pas tous les aspects de la gestion informatique.

En conclusion

ITILv3 propose de bonnes pratiques pour comment gérer chaque phase du cycle de vie de services et pour faire collaborer d’une façon organisée tous les acteurs en mettant en place de processus et de responsabilités. D’après des études[iii] on a pu constater que cette démarche permet aux fournisseurs de services (internes ou externes) d’améliorer la qualité dans la fourniture de services et la satisfaction du client. Il permet aussi l’alignement métier avec l’identification et la mise en place de nouveaux services qui donnent de la valeur.

Le principal obstacle pour son adoption est qu’il doit faire face à la résistance aux changements organisationnels[iv]. Risque majeur des échecs qui peut être maitrisé avec la formation, la sensibilisation ou la certification[v] des acteurs au référentiel pour les aligner sur les buts et les bénéfices qu’ITIL peut apporter.

Il a été adopté par des entreprises comme NASA, HSBC, IBM, Telefonica, HP, BT entre autres et ses pratiques son le pilier pour acquérir la certification de l’organisation dans le standard ISO/IEC 20000[vi]. Ils existent beaucoup des sites web[vii] où on peut approfondir sur le contenu et le détaille de chaque phase et processus en plus des ouvrages officiels publiés par son organisme créateur l’office du commerce britannique (OGC).

Suggestion d'articles :

1. ITIL : Information Technology Infrastructure Library
2. La gestion des processus IT
3. Autres standards de gestion des processus IT

L’Agile est aujourd’hui un outil puissant d’amélioration de la qualité des produits et de la satisfaction des acteurs, utilisateurs comme artisans du système d’information.

Si la méthode commence à être connue, sa mise en œuvre peut néanmoins se heurter à des difficultés, notamment sur le volet contractuel.

Ainsi, dans les organisations où les pratiques d’achats reposent sur une définition exhaustive des besoins (i.e. cahier des charges) et une obligation de résultat portant sur un périmètre figé et qui ne peut évoluer qu’à l’aide d’avenants, il est souvent difficile voire impossible de concilier ces pratiques avec les principes fondamentaux de l’Agile à savoir : autoriser le changement, affiner et spécifier les fonctionnalités au fil de l’avancement du projet pour répondre mieux aux besoins des utilisateurs.

Alors que faire ? Comment concilier des principes d’achats bien rodés mais a priori antagonistes avec les principes de projet Agile ? Peut-on faire évoluer ces principes ? Chez OCTO, nous avons la conviction qu’il existe des moyens d’y parvenir en respectant les contraintes et les enjeux de votre entreprise.

Nous vous proposons d’échanger avec vous sur ce thème et pourquoi pas vous accompagner dans un travail en profondeur sur vos pratiques d’achats et de contractualisation.

Pour commencer nos échanges, nous offrons 2 séances de travail de 2h gratuites au 3 premières entreprises qui nous contacteront.

Contactez-moi pour cela sur ymartel@octo.com et travaillons ensemble à améliorer un peu plus votre ingénierie informatique!

Suggestion d'articles :

1. Contractualisation Agile
2. Comment mieux prioriser en projet agile
3. Quels sont les types de tests que l’on utilise sur un projet agile ?

Nos DSI pensaient avoir passé un cap en mettant en place des infrastructures de site web client, boutique en ligne, support… Ca a été difficile, notamment pour rendre disponible sur des applications Internet des services de coeur de SI, qui n’avaient pas du tout été conçus dans cette logique, mais au moins on espérait en avoir fini avec les remises en cause.

Et bien non: les tablettes tactiles arrivent, iPad, tablettes Android, etc., y compris en B2B, et elles vont changer certains des métiers, dont la vente et la distribution. Et comme les applications Internet, elles vont poser de nouvelles difficultés en nécessitant un accès selon de nouvelles modalités à des services parfois (souvent) profondément enfouis dans nos systèmes d’information.

Pourquoi?

Partons d’une autre question: Pourquoi les applications iPhone sont-elle majoritairement agréables à utiliser et ont-elles contribué notablement au succès de ces smartphones?

Si je peux avancer une réponse, ce serait parce qu’elles partagent une charte ergonomique stricte et qu’elles sont construite autour de certains modes d’interaction. Ces modes d’interaction sont intuitifs, mais limités, et les applications sont conçues autour de cette limite. Elles sont également conçues autour des cas d’utilisation spécifiques les plus courants: les use cases d’un smartphone sont différents de ceux d’un PC. On va par exemple utiliser un PC pour réserver un billet d’avion, alors que le smartphone va permettre de s’enquérir des horaires, des retards et de s’enregistrer.

La même dichotomie se retrouve sur les tablettes tactiles vs les applications pour PC, même sur des applications d’entreprise. Imaginons un système de vente, permettant de réaliser une souscription de téléphonie mobile, un upgrade de forfait, un changement de mobile… Le cas d’usage de l’application sur PC est celui d’un opérateur en centre d’appel ou en agence, qui a déjà réalisé le dialogue avec son client et passe à la phase administrative, assis à son poste, alors que le client attend. La phase intense d’échange avec le client est plus ou moins terminée, les choix sont faits.

La même application sur tablette aura une autre orientation: elle va pouvoir être utilisée dès le début de la vente, alors que les choix ne sont pas réalisés. Le vendeur est en proximité physique avec le client, il dialogue avec lui et la tablette est une aide pour ce dialogue, y compris pour le client lui-même qui la voit et interagit avec. Le vendeur peut comparer des terminaux, tester la couverture, montrer des options, choisir des offres… Il n’est pas concentré sur son interaction avec son ordinateur, mais sur celle avec son client.

Du coup, il apparaît que l’application qui justifie d’introduire une tablette tactile en distribution ne peut pas être un simple portage technique, mais demande une réécriture avec une logique d’interaction différente. Reformater les écrans d’une application Web ou d’un portail donnant accès à plusieurs applications conçues pour un PC ne suffit pas. Il faut tout repenser en partant des cas d’utilisation les plus importants, en utilisant la grammaire d’interactions de la tablette et en veillant à ne pas détourner l’utilisateur du dialogue avec son client. Ceci implique alors d’accéder aux données et aux services du système d’information d’une manière différente des application traditionnelles, parce que la logique différente de l’application tablette et les contraintes techniques de la tablette impliquent des services et modalités d’accès nouveaux.

Alors, que faire?

Nous pouvons nous inspirer des démarches mises en oeuvre pour créer des applications Internet. On considère les applications Internet comme mouvantes, multiples, parfois jetables, parfois même non issues de l’entreprise mais réalisées par des tiers. Elles doivent pouvoir être réalisées rapidement avec une expertise spécifique, mais sans devoir à chaque fois affronter la complexité du système d’information et sa dette technique.

Pour ce faire, on mettait en place des couches de services spécifiques, isolant cette galaxie d’applications légères et agiles de la complexité du coeur de système d’information. Je propose de suivre une même démarche pour les applications tablettes, en mettant en place une couche de services adaptés à leurs besoins spécifiques, intégrant des services métiers, et peut-être des services techniques partagés.

En plus des cas d’utilisation spécifiques, quelles contraintes techniques nouvelles? Nous pouvons citer:

• des protocoles légers (REST / JSON par exemple), parce que la bande passante et la capacité de traitement du terminal « tablette » sont plus limitées que sur un PC;
• un écran = un service, parce que la fluidité de l’interaction est primordiale, et que la capacité du terminal est limitée;
• des données simples, parce que l’utilisateur doit rapidement s’y retrouver et que le terminal tablette ne doit pas avoir à réaliser de conversion de données complexes (pas de modèle pivot trop riche!).

Comment créer cette couche de service?

Ne pas la créer: la faire émerger. S’inspirer de l’excellente session de l’USI 2009 de mes camarades Benoît Guillou et Dominique Jocal. L’essence est d’utiliser deux patterns de définition de service:

• au départ, un service est créé pour une application, sans préoccupation de réutilisation. Il est défini par un contrat entre un client et un fournisseur, qui repose sur sa signature et le cas d’utilisation de ce client. On a un pattern « consumer contract », ou « contrat client », où on ne se préoccupe pas de réutilisation, seulement d’adéquation avec un besoin. On respecte néanmoins les bonnes pratiques d’implémentation des services (nommage, granularité, gestion d’états…) et de développement;
• lorsque des services similaires sont nécessaires pour plusieurs clients (au moins trois!), on peut envisager une mutualisation et mettre en place un pattern « consumer-driven contract ». Le contrat de service lie un fournisseur et plusieurs clients. Il repose sur la signature de service et la somme des cas d’utilisation par les clients.

Pourquoi ces patterns? Ils rendent les services facilement testables, et transparents d’utilisation. Le service respecte le contrat s’il passe une somme de tests d’utilisation. On favorise ainsi une approche de développement et de design reposant sur les tests, cruciale pour sécuriser un service qui doit être d’autant plus fiable qu’il est utilisé en plusieurs endroits, et donc susceptible de générer plus de perturbations s’il dysfonctionne.

En synthèse?

Les tablettes arrivent, préparons-nous à en tirer partie, pour la satisfaction de nos clients et de nos salariés. Elles nous offrent l’occasion de tirer partie des enseignements collectés sur les applications Internet pour accélérer le développement d’applications utiles, performantes et agréables. Elles vont enfin nous permettre de construire des infrastructures SOA pragmatiques, dans un modèle adaptable (possibilité de réagir rapidement par rapport aux besoins nouveaux) plutôt qu’adapté (couvrant parfaitement un besoin – réel ou théorique – tel que compris à un instant donné). Ne nous en privons pas!

Suggestion d'articles :

1. SCA, quel apport pour la SOA?

Aujourd’hui les grands groupes industriels font face à une multiplication des solutions de gestion dans leurs filiales avec un constat, plus on s’éloigne du centre et plus les solutions se font hétérogènes et exotiques. Ces différentes solutions vont de SAP, leader du marché pour lequel les processus sont presque gravés dans le code jusqu’à un simple ensemble d’outils de bureautique : un tableur pour suivre les commandes et un éditeur de texte pour émettre des factures. Entre ces deux extrêmes il existe quelques acteurs majeurs : Oracle EBS, SAGE, NAVISION… et de nombreux éditeurs locaux.

Comment rationaliser un écosystème aussi diversifié ?

Au niveau du groupe les gains d’une solution uniforme sur l’ensemble des entités sont évidents :

• reporting simplifié
• économies réalisée sur la formation aux outils
• capitalisation des équipes IT
• rationalisation du SI

D’un autre coté, les filiales en devenir veulent être capables d’évoluer rapidement sans être contraintes par un outil mais en ayant la possibilité d’informatiser un processus qui émerge de leur organisation. Et cela passe donc par des choix différents de ce qui est proposé par la maison mère. Il sera souvent préféré une solution ERP intermédiaire au core model pour de nombreuses raisons dont :

• des coûts moindres
• une maîtrise du périmètre des processus implémentés
• la rapidité de mise en œuvre

Ces points se résument à un choix entre simplicité et complexité qui est proposé par le centre. Or le coeur est complexe parce qu’il est riche et cette richesse est intrinsèquement lourde, ce qui est un atout au centre mais deviendra un frein dans les jeunes filiales.

Certains éditeurs essaient de pallier à cette problématique en proposant des solutions distinctes pour des BU de tailles différentes, c’est le cas par exemple avec SAP Business One, mais ce modèle ne fonctionne pas. Les synergies entre les solutions sont détruites au fur et à mesure que l’on essaie d’adresser les besoins de l’une ou l’autre des cibles.

Alors comment faire ? Et surtout, comment bien faire ?

A l’approche top-down qui définit une cible au centre, nous allons préférer l’approche bottom-up. Construire une application qui réponde aux besoins des petites entités, puis augmenter le périmètre avec des entités plus importantes jusqu’à rejoindre le core model… peut-être.
Nous allons donc nous inspirer de la méthodologie agile, itérative, pour construire le coeur de cet ERP de façon incrémentale.

La base doit être acceptable par de toutes petites structures et solide afin de pouvoir grandir. Pour cela les critères de choix vont être les suivants :

• des coûts réduits
• une technologie éprouvée
• un périmètre fonctionnel qui couvre 80% des besoins

C’est donc naturellement que nous allons chercher des candidats du coté des projets open source matures : OpenERP, Compiere, Neogia, ERP5…. Souples et robustes, ils sont modulaires ce qui est l’empreinte d’un développement communautaire au niveau de l’architecture logicielle. Cette modularité est la garantie d’une évolutivité future. De plus, les projets open source nous apportent des technologies ouvertes et standardisées facilitant l’intégration avec d’autres systèmes.

Et c’est un point important, l’approche d’OCTO n’est pas de créer un second core model décorélé du centre, en concurrence avec le centre. Il s’agit de réaliser un système qui soit potentiellement une marche vers le système central, une marche qui rapproche du centre. Ainsi cette solution apporte de la valeur à la filiale ET au centre.

Le choix d’une approche incrémentale pour la rationalisation du SI est différenciante dans le sens où il s’agit d’accompagner la création de valeur depuis le début d’une activité. Le système qui va être implémenté doit aider l’organisation cible sur un cycle court en terme de réalisation de « business » et sur un cycle long en l’aidant à s’intégrer dans le core model du centre. Et ceci de façon progressive. La méthode agile va nous permettre de faire évoluer en douceur l’ERP retenu vers les limites fixées : couvrir X% des processus, supporter une charge maximum de X utilisateurs…

Bien que les notions d’ERP et d’agilité puissent paraître antinomiques, il s’avère possible de profiter du meilleur des deux mondes dans ces projets souvent réputés pour être très lourds à cadrer, à réaliser et à mettre en oeuvre.

Dans un prochain article, nous verrons comment aborder ce type de projet d’un point de vue organisationnel et fonctionnel. Les projets ERP forment intrinsèquement un ensemble de fonctionnalités fortement imbriquées et nous verrons comment, avec une approche agile / incrémentale, nous allons pouvoir segmenter ces projets dans des livraisons fréquentes et fonctionnelles apportant de la valeur aux métiers régulièrement.

Suggestion d'articles :

1. Agilité et SOA ?
2. Petit-déjeuner « Agilité et ERP » avec le témoignage de Danone, le 22 mars
3. Travaillons ensemble à votre contractualisation Agile