Alstom Transport (5,3 milliards d’euros de chiffre d’affaires, 26 000 salariés), spécialiste des systèmes, équipements et services pour le marché ferroviaire, a mis en œuvre une approche de développement rapide de projets. Et engagé une refonte de son « core model » système d’information, avec une démarche itérative.
BPSI. Quels sont les avantages de développer des projets courts, en moins de trois mois ?
Bertrand Petit. L’objectif principal est de réaliser des gains rapides, d’améliorer l’efficacité des processus, et le principe consiste à mettre en œuvre des outils simples avec des tableaux de bord associés tout en conservant les briques construites.
Nous avons ainsi mené deux projets, opérationnels en avril 2008, en collaboration avec la société De Gamma, spécialiste de la réalisation des applications composites : d’une part, un worflow d’approbation de délégation d’autorité (DOA), pour le contrôle interne, et, d’autre part, une application ressources humaines de gestion des effectifs et d’accueil pour les nouvels arrivants (Gesper).
Concernant le premier, historiquement, le processus reposait sur le papier, avec des classeurs qui circulaient entre plusieurs services. Pour chaque nouveau collaborateur, il est défini un montant en dessous duquel il a le droit d’engager financièrement l’entreprise. Ce document est conservé au niveau central.
Ce processus papier va désormais laisser la place à un workflow simple dans lequel le nouvel arrivant se voit signifier son niveau d’autorisation. Et l’on conserve en mémoire les résultats dans une base de données. On dispose ainsi d’une base vivante de délégations d’autorité au lieu d’un document figé stocké dans une armoire.
L’application ressources humaines de gestion des effectifs et d’accueil des nouveaux embauchés évite de ressaisir plusieurs fois une même information. L’objectif est de fluidifier le processus.
Ce workflow a été mis en place au moment où l’on déploie un système d’authentification forte de tous les employés avec des badges à puce (Pcard), indispensables pour garantir la sécurité de l’accès aux informations (projet Sesam).
Avec ce projet SESAM, en termes de sécurité, il suffit de reprendre un badge pour désactiver les droits, ce qui évite de se souvenir à quelles applications le collaborateur avait accès, y compris celles accessibles en ASP. Nous avons ainsi automatisé la gestion de nombreux paramètres.
De plus d’un point de vue administratif, l’un des avantages est qu’il facilite le processus de sortie d’un collaborateur de l’entreprise ou de changement d’entité juridique dans le groupe. Ce projet Sesam, initié par Alstom Transport, devrait d’ailleurs devenir un projet groupe ! Nous partageons nos best practices au sein du groupe.
De tels projets démontrent aussi la capacité de la DSI à réaliser rapidement des projets. Pour les clients internes, un délai potentiel de trois mois, depuis l’expression de besoins jusqu’à la mise en service, se révèle très intéressant… pourvu qu’ils soient suffisamment clairs et matures dans leurs besoins pour lancer le déploiement au bout des trois mois !
En outre, ces outils de SOA sont des outils que l’on maîtrise et qui peuvent demeurer très proches de l’expression des besoins des utilisateurs et clients internes… et nous nous organisons pour pouvoir les mener en interne dans ces délais.
BPSI. Comment réussir en moins de trois mois ?
Bertrand Petit. Rappelons une règle de base en informatique : l’expression de besoins est bien faite, stabilisée, seulement la huitième fois. C’est une grande constante de l’informatique ! C’est lié au fait qu’en informatique « seul le ciel est la limite ».
A titre d’illustration, si l’on demandait à la DSI une fois le train conçu en CAO en trois dimensions que l’on puisse appuyer sur un bouton qui déclenche tous les robots pour que le train sorte de l’usine dans des délais très courts, potentiellement, nous pourrions le réaliser… mais cela coûterait des millions d’euros et je ne pense pas que nous gagnerions de l’argent avec ce type d’approche dans notre métier.
Pour revenir à la « huitième fois », lorsqu’un client exprime un besoin, c’est le résultat d’une certaine maturation. Mais lorsque l’on retourne le voir deux mois après, ses besoins ont souvent évolué. Faites l’exercice vous-même : demandez à quelqu’un de vous concevoir une feuille de calcul sur un tableur.
Si vous êtes vraiment exigeant, vous voudrez immanquablement ajouter des colonnes, des couleurs, du gras. En moyenne, vous procéderez à des modifications de vos spécifications initiales une huitaine de fois.
C’est d’ailleurs ce qui a fait et fait la fortune de tous ceux qui vendent des projets informatiques. Dès qu’il y a un changement, on sort le carnet de commandes et le prestataire est ravi ! Il faut donc parvenir à obtenir des systèmes dans lesquels on peut changer l’expression de besoins assez facilement.
Et lorsque, par exemple, vous voulez intervenir dans les couches basses d’un ERP, qui est un système contraignant, vous n’avez pas cette flexibilité… et c’est normal car l’ERP est un outil lourd et normatif !
Historiquement, nous avions des gros blocs progiciels et des armoires Notes. Mais ces dernières s’intègrent mal aux autres applications. Avec des produits comme ceux de De Gamma ou de type SOA, on intervient sur les couches plus basses pour faire fonctionner des sous-processus afin de récupérer une partie des informations.
Cette approche est indispensable, compte tenu de l’évolution de l’informatique. En fait, il faut considérer les progiciels pour faire ce qu’ils sont capables de faire « sortie de boîte ! ». Il faut être particulièrement attentif aux sollicitations des fournisseurs et à ne pas s’emballer sur des produits dont on nous explique qu’ils sont capables de tout faire, depuis le PLM jusqu’à la GPAO en passant par la gestion financière.
Mettre une couche de SOA au-dessus permet de réaliser des interfaces conviviales au-dessus du « gros progiciel » et éviter trop de customisation dans ces progiciels. La SOA devient, de fait, une trousse à outils que le DSI peut manipuler lui-même
BPSI. Comment cela se passe-il concrètement ? Par quoi faut-il commencer ?
Bertrand Petit. Il faut aller vite, c’est l’intérêt de l’approche. Un consultant s’assied à côté du client. Ce dernier lui explique ce qu’il souhaite faire. Le consultant traduit les besoins dans un workflow. Avec une modélisation du type : « Telle action entraîne telle action qui elle-même enclenche telle autre action. »
Pour nos deux projets, De Gamma a utilisé Visio et développé des trousses à outils : une pour les mails, une autre pour l’interface SAP, une autre pour l’interface Notes, etc. On parvient ainsi à réaliser une première expression de besoins, en deux ou trois heures seulement. Ensuite, le consultant demande comment l’utilisateur souhaite visualiser les résultats : c’est la composante tableau de bord du projet.
Au total, cela représente environ une journée. Le consultant s’en va et revient deux à trois semaines plus tard avec un prototype. Bien évidemment, il arrive ce qui se passe toujours : le client a toujours oublié quelque chose, par exemple de recenser une condition supplémentaire…
Lorsque le prototype est validé, la phase suivante porte sur l’intégration technique de ce workflow dans les sous-processus qui existent, dans les ERP ou d’autres applicatifs. On obtient ainsi une version finale en moins de trois mois. Si l’expression de besoins a évolué, le workflow, qui repose sur une intégration molle par opposition à une intégration dure, est adapté.
Chez Alstom, nous avons expérimenté cette approche avec des projets peu complexes, mais j’ai vu dans d’autres grands groupes des réalisations qui concernaient deux ERP différents, pour lesquels une interface commune a été développée. C’est plus complexe que chez nous, mais cela fonctionne très bien.
BPSI. Peut-on selon vous réduire le nombre d’itérations pour mieux maîtriser l’expression des besoins des utilisateurs et n’y-t-il pas des effets pervers à proposer une telle souplesse ?
Bertrand Petit. Réduire les huit itérations ? C’est un effort incessant… mais il faut être très réaliste de ce côté-là ! La nature humaine est ainsi faite ! De multiples expressions de besoins, il y en aura toujours. Il faut simplement être capable de les accepter et de ne pas considérer qu’il s’agit d’une catastrophe.
Quant aux effets pervers, on peut en effet craindre le fait que les utilisateurs, puisqu’on leur offre la possibilité de modifier leurs expressions de besoins, en profitent. Mais, dans le groupe, on met en place des principes stricts de gouvernance : il y a des applications très contraignantes, qui gèrent le savoir de l’entreprise, avec une rigidité des processus, que l’on veut parfaitement contrôler.
En revanche, il y a des processus qui relèvent davantage de l’action quotidienne : ceux-là, nous cherchons à les automatiser, sans pour autant changer le contenu de l’information. Si l’on refuse ce fait et que l’on veut être rigide sur tous les processus, les utilisateurs détournent et développent leur propre application sur de l’Excel ou de l’Access… ce qui est pire que tout en pérennité et maintenance.
En conclusion, dès lors qu’il s’agit de travailler sur des processus qui sont liés à des workflows ou à la construction d’un tableau de bord, je privilégie l’approche SOA que nous avons utilisée pour nos deux projets de délégation de signature et de gestion des effectifs.
BPSI. Alstom Transport a également entrepris de déployer un « core model » : comment réussir l’alignement des métiers ?
Bertrand Petit. Le groupe a lancé il y a quelques années un programme ambitieux (Impact) qui a transformé l’organisation pour travailler en mode sous-systèmes/plates-formes, avec une volonté claire de définir des processus communs. La question que la DSI pose aux métiers est la suivante : « C’est votre responsabilité de sortir les produits à temps, avec une qualité optimale et des coûts maîtrisés, dites-moi à quelle vitesse vous pensez être capables de durcir votre organisation en incrustant les process dans les SI ? »
Le système d’information doit être très proche des métiers, notamment pour le support. La plupart des collaborateurs qui travaillent en support de niveaux 2 et 3 ont plus une connotation métier qu’une connotation informatique. Il faut donc être capable de remettre les « core models » aux mains des utilisateurs métiers qui avaient historiquement délaissé les systèmes d’information en laissant la main à la DSI. Un « core model » se compose en fait de trois cercles : un « core system » (ou systèmes d’information SI) du domaine de la DSI, de processus et d’une organisation.
Chez Alstom, nous différencions l’IS (Information System), qui est dans chacun des trois secteurs (Power System, Power Services, Transport), et l’IT (Information Technology) qui est centrale pour bénéficier de l’effet de masse et mieux acheter. Par ailleurs, on essaie de trouver le bon équilibre pour bénéficier des synergies au niveau corporate mais en même temps rester très près du besoin métier.
Nous restons réalistes : tout ne peut s’inscrire dans le dur du système d’information. Mais il était important d’inscrire une vision moyen terme sur ce que l’on voudrait voir mis dans le dur… et c’est au métier de nous le dire. Face à ce questionnement, les représentants de métiers ont accepté de prendre leur responsabilité et nous ont expliqué : « Nous ne voyons pas toujours ce qu’il y a dans nos systèmes et ne pouvons pas lire 500 pages de documentation ou des centaines de slides ! ».
En fait, il leur manquait une cartographie et un ensemble de méta-règles. Ce n’est pas le rôle de la DSI de les définir mais nous les accompagnons. Nous avons ainsi créé des TOM (Transport Operating Models, nos méta-règles), avec une approche itérative.
En effet, entre la vision et les processus, il manquait deux étages : des règles d’or (golden rules), qui précisent les principes d’action par rapport à la vision et les TOM, dont le rôle est de fournir des éclaircissements sur les points de friction. La cartographie et les méta-règles ont été définies par une approche itérative, avec une méthodologie qui nous a été apportée par le cabinet de conseil BelleAventure.
BPSI. Comment se déroule la démarche ?
B. P. Concrètement, nous réunissons les « sachants ». Ils ne partent pas de rien mais des règles d’or et d’un cadre de travail. Par exemple, depuis un an, nous avons modifié notre façon de travailler pour la fabrication des trains. Il a été décidé que pour améliorer la fiabilité plus rapidement, il était nécessaire de travailler avec l’ingénierie, l’industrialisation et le manufacturing, réunis en plateau au même endroit pendant trois à six mois.
Ce principe a été établi et approuvé : c’est le cadre. Ensuite, on demande aux représentants de chacune de ces entités : « Réunissez-vous, assimilez les règles d’or et dites-nous ce qui coince quand vous essayer de les appliquer ». Ainsi, les « process owners » (par exemple pour la finance, le sourcing, la logistique…) et les coordinateurs de processus des lignes de produits et des régions (ceux qui exécutent) identifient les domaines qui manquent de cohérence en fonction de la spécificité de leur métier.
Tout ceci est complexe car, pour reprendre une analogie avec l’automobile, Alstom Transport joue à la fois le rôle des sous-traitants pour les pièces critiques et d’intégrateur comme le font les constructeurs, mais nous construisons aussi les autoroutes, la signalisation et les garages. Donc, en termes informatiques, nous avons trois « core systems » : projet, produits et services.
Même si l’on souhaite développer des façons de travailler identiques au niveau des fonctions support, il faut être très clair sur le principe de subsidiarité. Il y a ainsi, d’un côté, des processus où aucun choix n’est laissé : ils s’appliquent de la même manière à tout le monde, par exemple pour le mode de calcul des marges.
Par contre, lorsque l’on descend dans l’organisation vers les métiers, il importe de laisser aux managers de lignes de produits une relative autonomie par rapport au socle commun. On ne travaille de la même façon selon que l’on fabrique des trains, des logiciels de signalisation ou des caténaires…
Sur certains processus, il y a donc obligation pour tous, pour d’autres il y a juste un chapeau commun. Si un frottement apparaît, on définit un TOM : une phrase claire, compréhensible par tout le monde, sans référence à un jargon et que le top management comprend. Exemple : « Toute modification de donnée doit être managée par le centre d’excellence produit ».
Autre exemple : « Il est interdit d’acheter en dehors de la liste des fournisseurs approuvés par la direction des achats. » Lorsque les principes sont validés, après confrontation/itération sur le terrain, l’informatique est chargée d’inscrire les méta-règles. Au total, 72 TOM ont été identifiés pour l’ERP, validés, et 92% ont été intégrés dans la nouvelle solution SAP.
BPSI. Où est la valeur de l’informatique dans ce contexte ?
B. P. In fine, la valeur de l’informatique réside toujours dans le déploiement. Quand nous déployons un « core model » dans un site, c’est le patron du site qui décide, car c’est lui qui doit être capable de faire tourner le site après le déploiement !. C’est clair en termes de gouvernance. Ce n’est pas l’IT qui décide ce que l’on déploie. Cette approche, en responsabilisant bien au bon niveau, redonne une visibilité des « core systems » à toute la hiérarchie de l’entreprise.
En septembre dernier et après le succès du premier pilote, la démarche TOM, initiée dans un premier temps pour un ERP, a été étendue à toute l’entreprise. Les TOM constituent une approche pragmatique : certes, on ne règle pas tous les problèmes et il subsiste toujours des zones d’ombre.
C’est avant tout une démarche de bon sens. Il faut toutefois éviter deux écueils : une approche trop dirigiste ou, au contraire, trop laxiste dans laquelle chacun fait ce qu’il veut. Dans tous les cas, il est indispensable de donner la vision et le contrôle aux patrons des lignes de produits pour que ceux-ci puissent pousser, à leur rythme, vers une uniformisation des processus et à un renforcement de leur organisation.
Le plus difficile est d’initier la démarche. Beaucoup s’imaginent encore qu’il suffit de déployer un système d’information identique pour tous les sites et tous les métiers, sans chercher à en comprendre les spécificités. L’outil, comme la DSI, intervient comme un « facilitateur », un révélateur, des pratiques. Petit à petit cela est compris de cette manière par tous les collaborateurs du groupe.
Les dix best practices de Bertrand Petit
- Dès lors qu’il s’agit de travailler sur des processus qui sont liés à des workflows ou à la construction d’un tableau de bord, privilégiez une approche SOA par prototypage rapide.
- Dans les grands groupes, distinguez l’IT, qui est centrale, pour bénéficier de l’effet de masse et mieux acheter, et l’IS, système d’information très proche des métiers.
- Les outils doivent être maîtrisés et demeurer très proches de l’expression des besoins des utilisateurs et clients internes.
- Toujours se souvenir d’une des règles de base en informatique : l’expression de besoins est bien faite, stabilisée, seulement la huitième fois. Soyez capable de l’accepter !
- Considérez les progiciels pour faire ce qu’ils sont capables de faire « sortie de boîte ». Rester attentif aux sollicitations des fournisseurs et ne pas s’emballer sur des produits dont on nous explique qu’ils sont capables de tout faire.
- Éviter au maximum la customisation dans le progiciel qui vous générera des problèmes de montée de version mais customiser au-dessus de l’application avec de la SOA.
- Laissez aux managers de lignes de produits une relative autonomie par rapport au socle commun mais responsabilisez-les bien sur leur core model !
- Évitez deux écueils : une approche trop dirigiste ou au contraire trop laxiste dans laquelle chacun fait ce qu’il veut. Lorsque l’on descend dans l’organisation vers les métiers, il importe de laisser aux managers de lignes de produits une relative autonomie par rapport au socle commun… et de savoir le décrire.
- Si un frottement apparaît, on définit une phrase claire, compréhensible par tout le monde, sans référence à un jargon et que le top management comprend. Ce sont les TOM qui, une fois validés, deviennent des « objectifs moyen terme sur nos processus à intégrer à l’IS »
- Même si vous souhaitez développer des façons de travailler identiques au niveau des fonctions support, il faut être très clair sur le principe de subsidiarité.
L’application de gestion administrative des nouvels arrivants chez Alstom Transport
- Gestion des paramètres : utilisateurs, boîtes mails génériques, motifs de sortie.
- Saisie d’un nouvel arrivant, accueil, gestion des besoins de l’employé selon son profil, gestion des applications informatiques autorisées.
- CDD/CDI, prestataires/intérimaires, stagiaires.
- Synchronisation avec les annuaires RH (ALPS).
- Interface avec les droits d’accés au bâtiment.
- Alerte et contrôle lors du départ du personnel - Gestion des transferts intra-sites des entrées/sorties administratives et physiques pour les différents types d’employés.
- Gestion des remplacements, renforcements, renouvellement de prestataires
- Processus de validation workflow des mouvements de personnel (administration, sécurité, RH…)
- Gestion des renouvellement de périodes d’essai et de contrats.
- Gestion des badges, des mutations, des pièces jointes (contrats).
| Les 16 étapes d’un cycle projet | ||
| Étape | Actions | Acteurs |
| 1 | • Les idées de projet sont émises par la direction métier et les utilisateurs | Direction métier |
| 2 | • Consolidation et filtrage des demandes projets | Direction métier |
| 3 | • Rédaction de l’étude d’opportunité | Assistance à maîtrise d’ouvrage |
| 4 | • Validation de l’étude d’opportunité | Direction métier |
| 5 | • Collecte et analyse des besoins | Assistance à maîtrise d’ouvrage |
| 6 | • Rédaction de l’étude préalable | Assistance à maîtrise d’ouvrage |
| 7 | • Validation de l’étude préalable | Direction métier |
| 8 | • Rédaction des dossiers de conception générale | Assistance à maîtrise d’ouvrage |
| 9 | • Validation des dossiers de conception générale | Direction métier |
| 10 | • Rédaction des dossiers de conception détaillée | Projets et exploitation informatiques |
| 11 | • Validation des dossiers de conception détaillée | Assistance à maîtrise d’ouvrage |
| 12 | • Réalisation des solutions | Projets et exploitation informatiques |
| 13 | • Rédaction des jeux de tests et des plans de tests | Assistance à maîtrise d’ouvrage |
| 14 | • Contribution à la réalisation des tests et recette | Projets et exploitation informatiques |
| 15 | • Constitution des dossiers de production et de support | Projets et exploitation informatiques |
| 16 | • Mise à disposition de la solution métier | Direction métier |
| Source : Ineum Consulting | ||
Les Best Practices du fournisseur
Les ERP sont nécessaires mais pas suffisants pour répondre aux besoins des entreprises d’optimisation de leurs processus de gestion (notamment dans les domaines où la part d’automatisation reste faible : RH, Achats-Finance, CRM…).
Ensuite se pose la problématique du « time to market » dans des organisations mouvantes, où, sur la base des applications back-office, de nouvelles fonctions front-office doivent pouvoir être mises rapidement à la disposition des utilisateurs.
Dans la gestion de tels projets, une approche par prototypage apporte une réelle valeur ajoutée : la première étape consiste à interviewer les utilisateurs clés (sur la base d’un cahier des charges s’il existe) afin de sécuriser les points clés du projet.
La seconde étape aboutit, en mode itératif avec ces mêmes utilisateurs, à la livraison d’un prototype opérationnel, constitué de processus modélisés et d’écrans prototypés de l’application cible. Ce livrable pourra aisément être critiqué par les responsables métiers, car pouvant être appréhendé par des profils non informaticiens : c’est l’avantage par rapport à un cahier des charges, qui est souvent fastidieux à réaliser et prend difficilement en compte les évolutions et omissions détectées au cours du projet.
Il est conseillé de prendre en compte les critiques des utilisateurs le plus en amont possible, cela diminue le nombre d’itérations. En général, deux à trois aller-retour sont nécessaires pour affiner les besoins des métiers, cela dépend du périmètre et du nombre d’acteurs fonctionnels impliqués dans le projet. Une telle approche est très efficace pour tous les projets front-office, proches du métier, pour lesquels les solutions progicielles répondent difficilement aux spécificités de chacun.
Les meilleures pratiques
- Aidez vos directions métiers à juger de la pertinence d’une demande et d’un cahier des charges ; identifiez les failles d’un cahier des charges : il y en a toujours.
- N’automatisez pas des processus qui ne créent pas ou peu de gains métiers : la plus-value du projet doit toujours être démontrée.
- Sécurisez une validation forte des utilisateurs, le plus en amont possible du projet, pour éviter un effet tunnel dans la phase de développement.
- Réutilisez un maximum d’éléments existants, la connaissance existe dans la DSI.
- Associez, dans le comité de pilotage, la DSI et les représentants fonctionnels.
- Ne vous privez pas d’effectuer des itérations supplémentaires, de manière à réduire les coûts.
- Ne demandez pas à votre fournisseur de redéfinir vos processus métiers. Ce n’est pas son rôle.
- Privilégiez un engagement au forfait de la part de votre fournisseur.