Transformation d’un métier et de son si : automatisation des processus, répartition du travail des opérationnels et refonte des produits

Contexte

Dans une grande banque, lancement d’un grand programme de refonte d’un métier, de la collecte des informations (à automatiser), au calcul des ratios jusque la refonte de produits à vendre aux clients.

Solution

• Poser une vision stratégique de la refonte basée sur la stratégie métier
• Donner une vision globale de l’activité
• Collecter l’ensemble des besoins d’évolution
• Poser une vision cible du SI 
• Construire une trajectoire pluriannuelle
• Prioriser les évolutions
• Regrouper les évolutions par projet
• Estimer les projets
• Accompagner le programme dans sa mise en place, le recrutement, la gouvernance
• Cadrer les solutions projet par projet
• Suivre la mise en place des projets

Bénéfices

• Une vision stratégique métier et SI partagée
• Des priorisations prises par le métier en tout connaissance
• Des projets identifiés, cadrés et suivis
• Maitrise de la trajectoire et des évolutions

Contexte

L’ambition de la DSI du client est de répondre aux nouveaux enjeux de time-to-market et d’optimisation des coûts. Au travers d’un programme de transformation, il cherche à la fois à mettre en place une organisation Agile, à adopter une démarche DevOps et Continuous Delivery, et à étendre son panel d’hébergement aux infrastructures Cloud. Rhapsodies Conseil intervient pour l’aider à déployer ce nouveau modèle et à démontrer son efficacité opérationnelle.

Missions

Accompagnement de la transformation organisationnelle:

• Evangélisation auprès des différents départements de la DSI pour permettre l’adoption rapide du modèle
• Définition de la nouvelle organisation (processus, livrables), de la trajectoire de transformation, et validation avec l’ensemble des acteurs (architecture, opérationnels, sécurité…)
• Définition et mise en place des indicateurs permettant de formaliser les gains

Accompagnement des projets « early adopters»:

• 50+ projets à accompagner sur 2016
• Support opérationnel à l’intégration des nouveaux processus et de l’outillage permettant le Continuous Delivery
• Construction et animation des équipes DevOps
• Porteur des besoins projets vis-à-vis des cellules d’architecture DevOps, Continuous Delivery et Cloud

Architecte au sein de la cellule « DevOps et Cloud »:

• Définition de la roadmap 2016 des travaux d’architecture DevOps / Automatisation / Cloud
• Responsable des composants d’architecture Données

Bénéfices

• Une trajectoire validée pour aboutir à une organisation transformée
• Une mise en place réussie du modèle DevOps et du Continuous Delivery pour tous les projets candidats, et des gains qualitatifs et quantitatifs mesurés
• Des jalons tenus pour le delivery des composants d’architectures

Contexte

Une société en pleine évolution dans un monde en plein changement (digitalisation, nouveaux acteurs, etc.) doit faire évoluer son SI du cœur métier, de la collecte des informations et de la restitution vers ses clients.

Solutions

• Accompagnement des projets dans leur cadrage
• Expliciter la stratégie des grands projets avant de les lancer
• Suivre les projets dans leurs évolutions pour garantir l’évolutivité des solutions

Bénéfices

• Les solutions sont alignées sur la stratégie métier
• Les solutions et leurs évolutions sont partagées et maitrisées

Contexte

Le client a initié une grande transformation métier sur 6 ans. Afin d’accompagner cette transformation à l’ère du Digital, la DSI a lancé un plan d’action regroupant 9 programmes majeurs. Au sein de ce programme, une refonte de l’ensemble de la Relation Client, la mise en place d’un DataHub et la Gouvernance de données associée ont été impulsées.

Missions

Au sein de la Direction de l’Architecture, accompagnement global du portefeuille projet du Domaine Client et Marketing:

• Cadrage des projets lors des phases d’Etudes de Faisabilité et de réalisation
• Réalisation des architectures fonctionnelle, applicative et techniques
• Accompagnement des projets pour le positionnement et l’intégration des composants transverses (MDM, DataHub, CIAM)
• Reporting au Copil
• Définition des bonnes pratiques d’architecture du Domaine Client et Marketing
• Définition des bonnes pratiques de Gestion de la Données Client bout en bout (MDM, CIAM, Digital, Data Hub, Décisionnel)
• Définition des paliers stables et trajectoires d’intégration dans le SI pour les composants transverses (Data Hub, MDM)
• Collaboration avec le DataLab pour la définition des Cas D’Usages du Data Hub (Archi CQRS, V360)

Bénéfices

• Vision transverse de l’ensemble des projets du Domaine Client
• Définition de la trajectoire et des paliers stables cohérents sur le Domaine Client
• Montée en compétences des équipes MOE sur les outils et les nouveaux patterns d’architecture (Data Hub, CIAM, Architecture CQRS, API Management)

Savez-vous que démarrer un projet d’implémentation sans avoir un avis sur l’architecture fonctionnelle, c’est comme partir en voyage sans avoir regardé le trajet avant ?

Si vous voulez atteindre vos objectifs sur vos projets numériques, utilisez l’architecture fonctionnelle comme un levier de performance.

Architecture fonctionnelle et marketing, des rôles pas si différents

L’architecture fonctionnelle a le même rôle que le marketing de votre entreprise. Elle permet d’identifier et comprendre les besoins des projets, puis d’y répondre de la manière la plus pertinente avec les SI, les données et les processus disponibles. Elle identifie également les gaps à combler quand les SI en place ne peuvent y répondre ou au contraire les redondances de fonctionnalités entre les SI.

Elle garantit la transversalité de la conception fonctionnelle au niveau de l’entreprise et non avec une vision unitaire ou silotée d’un seul projet.  

Dès lors, quels sont les objectifs de l’architecture fonctionnelle?

En tant que métier, exprimez votre besoin ! N’apportez pas de solutions. Vous verrez d’ailleurs que ce n’est pas si facile d’exprimer la totalité de son besoin.

Tout l’enjeu de l’architecture fonctionnelle est donc ensuite de partir de ces besoins, de les découper en fonctions, processus et données nécessaires, puis d’identifier les SI qui les porteront. L’idée principale étant de les mutualiser au maximum et de garantir que chaque SI soit utilisé pour ce qu’il sait faire

L’architecture fonctionnelle devra aussi parler d’architecture de données et de gouvernance de données. Quelle est la responsabilité de chacun sur les données (personne et SI) ? Quelle est alors l’organisation nécessaire pour garantir la qualité de ces données ? Comment ensuite modéliser les données pour les stocker et les mettre à disposition ?

Toutes ces questions sont adressées au travers de l’architecture fonctionnelle.

L’architecture fonctionnelle : une analyse à forte valeur pour la DSI et surtout pour le métier

En tant que responsable projet, Product Owner ou Responsable SI, imposez d’avoir une étude d’architecture fonctionnelle dans tous vos projets. 

Elle décrit de manière compréhensible les fonctions et la conception de la solution en réponse aux besoins. 

En tant que métier, vous comprendrez donc facilement le rôle de chacun des SI dans la réponse aux besoins métier et si tous les besoins sont bien adressés. 

En tant que DSI, vous aurez également une vision claire de ce qui est ou de ce qui n’est pas de la responsabilité de chaque SI.

C’est particulièrement vrai lorsqu’il y a beaucoup de projets de refonte des fronts clients par exemple. Chacun des projets a besoin de données et de fonctionnalités. La multiplicité des sources et la digitalisation des fonctions génèrent de nombreux flux à développer pour acheminer les données et développer les fonctionnalités. Ces flux doivent être minutieusement étudiés pour garantir la mutualisation des fonctions, des données et des flux. De par sa connaissance fonctionnelle et des processus, l’architecture fonctionnelle permet aussi de choisir la bonne source de données pour chacun de ces besoins. Elle cartographie ainsi les besoins, les données, les processus, les fonctions et identifie pour chaque, quel SI est responsable.

L’architecture fonctionnelle doit donc être comprise de tous. Il ne s’agit pas encore d’aborder la solution technologique.

Une architecture fonctionnelle forte est nécessaire

Avoir une architecture fonctionnelle avec un pouvoir de décision fort sur la conception fonctionnelle est absolument nécessaire. Elle doit être un passage obligé pour garantir des bénéfices importants : 

• Le premier bénéfice direct est une diminution des coûts des SI et une accélération des projets. En effet, l’architecture fonctionnelle va garantir que les SI vont être utilisés pour leur cœur de fonctionnalités. Sinon, la facilité mais aussi les plannings font que naturellement, sans garant, les choix sont faits sans une étude approfondie et transverse. Les solutions coûtent de plus en plus chères avec le temps ou deviennent bloquantes pour les futurs besoins à adresser. Par exemple, un référentiel client n’est pas un outil de gestion. Le détourner de sa fonction originelle à savoir la qualité des données client, va impliquer d’implémenter des règles de gestion propres au métier. Cela va créer des contraintes fortes qui peuvent coûter très chères pour de besoins futurs.
• Le deuxième bénéfice est que les coûts de maintenance, de développements et d’achats de données externes sont optimisés. En effet, dans des contextes où il y a de très nombreux systèmes, l’architecture fonctionnelle garantit la non-redondance de fonctions, voire de SI pour répondre aux mêmes besoins. Il n’est en effet pas rare de constater que par exemple la mise en qualité de l’adresse postale soit faite dans plusieurs systèmes différents. Il se peut même que cette donnée soit achetée plusieurs fois dans votre entreprise.
• Enfin le troisième bénéfice majeur est la satisfaction des métiers qui expriment les besoins. L’architecture fonctionnelle a en effet aussi la responsabilité de garantir l’intégration des SI dans les processus fonctionnels et de soulever les changements d’organisation nécessaires. Ce dernier impact n’est pas des moindres. Bien souvent, il permet de garantir le succès d’une implémentation par l’adoption de la solution proposée car elle est parfaitement intégrée au quotidien des métiers. 

L’architecture fonctionnelle : tout un art !

L’architecture fonctionnelle impose des compétences spécifiques. Elle nécessite un juste équilibre entre la compréhension fine des besoins et la conceptualisation de ces besoins en processus, fonctions et données. 

Il s’agit de challenger juste assez le besoin pour obtenir tous les éléments nécessaires à sa compréhension d’un point de vue de l’entreprise. Il faut cependant ne pas trop le challenger et rester dans la pro-activité et la co-construction. 

On parle aussi d’être pragmatique dans la conception pour être en mesure de livrer rapidement et ne pas promettre la lune. Les aller-retours sont nombreux, les questions aussi. Le tout entre de nombreuses parties prenantes (le métier, les études, les architectes solution et techniques, la production, la sécurité, etc.) qui contribuent au succès de la solution grâce à la valeur ajoutée de ce qui aura été livré. 

L’architecture fonctionnelle est indispensable. Elle garantit la pérennité et la flexibilité de vos SI et processus, face à la multiplication des besoins générés par des habitudes client en perpétuelle évolution.

Contexte

Au printemps 2017, le client a réorienté sa stratégie IT vers le Cloud et les architectures microservices. Après la mise en place durant une année d’un socle Cloud, une réécriture progressive en microservices de ses principales applications Legacy a été entamée. Les apports attendus sont une meilleure réactivité face aux évolutions du métier, la levée de limitations fonctionnelles et techniques ainsi qu’une baisse des coûts opérationnels.

Missions

Dans le cadre du revamping du progiciel IRP (application majeure d’évaluation des risques) :

• Cadrage (recueil et analyse) et formalisation des besoins métiers face aux limitations du Legacy,
• Réalisation des dossiers d’architecture (DA) pour les différents comités récurrents (board, investissements, steering, architecture centrale…),
• Conception d’une architecture applicative urbanisée & event-driven, basée sur des microservices,
• Modélisation des objets métier afin de formaliser les contrats d’échange (API REST),
• Définition d’une stratégie de migration continue pour maintenir la cohérence entre Legacy et microservices afin de faciliter les bascules de responsabilité,
• Validation des solutions d’implémentation (y compris l’Infrastructure as a Code) sur AWS, conçues avec les architectes techniques,
• Evangélisation des principes d’architecture concernant la résilience, la robustesse, l’élasticité, la performance, la sécurité et l’observabilité,
• Conception détaillée d’un module de mapping user-friendly des données métier (DaShifter) pour répondre au problème central de la disparité des sources d’information.

Bénéfices

• Première livraison en 4 mois de fonctionnalités initialement prévues pour l’année suivante,
• Levée de limitations techniques (volumes de données et traitements en masse),
• Décorrélation des cycles métiers et des cycles de développement.