Nous le constatons encore aujourd’hui, certains projets n’aboutissent jamais, ou alors après des mois voire des années de mise en œuvre et sont boudés par les utilisateurs.
Malgré une gestion des changements, la plateforme n’est jamais utilisée et l’application meurt (on l’espère rapidement) sans jamais rencontrer ses utilisateurs.
Dans certains cas, le projet “stratégique” a été validé par la Direction, la technologie en haut à droite du cadran du Gartner a bien été déployée, mais au final les cas d’usage sont beaucoup trop compliqués à intégrer sur la plateforme. Ces projets finissent souvent en échec, les ressources ont été gaspillées et l’image de la DSI en pâtit.
Enfin, dans d’autres cas, l’étude s’éternise pour concevoir, et planifier l’architecture qui répondra à l’ensemble des cas d’usages et qui permettra de résorber la dette technologique. Ces cas de figure trop fréquents partent malheureusement de bonnes intentions. Il s’agissait de couvrir l’ensemble des besoins existants et d’absorber les besoins qui ne manqueront pas d’arriver à court et moyen terme.
Une approche frugale
La meilleure solution consiste à se concentrer sur quelques utilisateurs clés pour prendre en compte des fonctionnalités précises qui peuvent être implémentés sous forme de MVP en quelques sprints et le faire évoluer pour prendre en compte les nouveaux besoins.
L’architecture de la solution devra rester souple et prévoir “by design” de pouvoir intégrer de nouveaux composants et technologies qui répondront demain à des nouveaux besoins.
Pour réussir cette mise en œuvre, il faut donc réunir une équipe pluridisciplinaire qui sera en charge de :
Collecter et analyser les besoins des utilisateurs
Définir l’architecture fonctionnelle et de données
Définir l’architecture technique
Constituer et suivre la backlog
Concevoir et mettre en œuvre les développements
Déployer l’architecture technique
Au démarrage du projet il faudra donc :
un Product Owner
un architecte en charge des aspects fonctionnel, applicatifs et data
un architecte technique
un scrum master
un ou plusieurs développeurs spécialisés sur les stacks à mettre en oeuvre
un cloud-ops
Un Business Analyste
Une organisation efficiente
Cette organisation s’inspire des Pizza Teams (l’ensemble des membres d’une équipe doit pouvoir se nourrir sur une Pizza Américaine). Elle vise à simplifier la communication au sein d’une équipe. En effet, le nombre de liens entre les personnes d’une équipe peut être calculé avec la formule suivante (1) :
( N x (N -1 ) )/ 2
Où N est égale au nombre de personnes dans l’équipe.
Plus le nombre de personnes est important plus les échanges sont importants et les risques et le temps consacrés aux échanges sont importants.
La mobilisation de l’équipe permettra de produire au fil des sprints des versions de plus en plus abouties, revues régulièrement par les utilisateurs.
En quelques semaines, une première version pourra être déployée en production sur le périmètre jugé prioritaire par les utilisateurs.
L’adoption ne sera plus un problème, car les utilisateurs auront participé à la conception de leur outil et remonteront directement les fonctionnalités prioritaires.
Au fil des évolutions, l’équipe pourra être élargie pour prendre en compte des besoins impliquant des nouvelles briques d’architecture et de nouvelles technologies. Il faudra toutefois rester vigilant afin de ne pas dépasser le nombre critique de membres dans l’équipe.
Une dynamique dès le cadrage
Un cadrage initial est indispensable avant de lancer le projet. Certes l’organisation projet et le user-centrisme sont des facilitateurs, mais la clef dans le succès de la démarche se trouve en amont. Si au lieu de demander aux utilisateurs quels sont leurs besoins et de les hiérarchiser par priorités, nous leur demandions leurs envies ?
Les utilisateurs vont être concentrés sur ce qui est vraiment important dans leur travail et ce qui va leur simplifier la vie. Si l’application a de multiples utilisateurs, il faudra les amener à trouver un consensus et à présenter une liste commune. Cette liste sera la base de la backlog projet et devra être affinée afin de la rendre implémentable.
Faire adhérer les décideurs
Cette approche projet nécessite de rassurer les décideurs. En cela la méthode agile est insuffisante. Le burn out chart ou les autres indicateurs sont utiles au pilotage agile des projets, mais suffisent rarement à rassurer les décideurs sur les aspects coûts / délais / valeur ajoutée des projets.
Il faut donc trouver des indicateurs complémentaires, aptes à rendre compte de l’avancement des sprints, mais qui permettent aussi d’apporter de la visibilité aux décideurs qui n’ont que faire des points de complexités et autres idiomes agiles.
Revoir la méthode
La réussite des projets passe par une remise en question profonde de nos méthodes d’architecture. Le framework TOGAF nous donne de bonnes bases, mais elles sont loin d’être suffisantes pour aller vers de l’architecture SI agile.
Les évolutions de l’architecture découlant des besoins métiers et non plus d’une planification détaillée réalisée en début de projet et implémentée dans un cycle de plusieurs mois ou années, cela nous amène à adresser des problématiques qui remettent en cause nos méthodes de travail :
Les projets font de plus en plus souvent appel à de l’expérimentation. Les composants sont testés sur des calendriers resserrés et suivant l’adéquation par rapport au besoin, sont adoptés ou abandonnés.
Les schémas d’architecture initiaux sont vite obsolètes et ne seront maintenus qu’en contrepartie d’un investissement conséquent à faible valeur ajoutée pour l’utilisateur.
Les technologies évoluent (trop) vite, la maîtrise des technologies par les équipes de support et d’exploitation prend beaucoup plus de temps.
Les utilisateurs ne comprennent plus que l’informatique professionnelle soit décorrélées des technologies mises à dispositions par les GAFA.
Les projets sur plusieurs années sont obsolètes avant d’être ouverts aux utilisateurs.
Pourtant des méthodes et outils inspirés du design thinking, du Lean ou du manifeste agile sont là pour nous aider avec par exemple :
La méthode sprint pour l’expérimentation ;
Des outils de documentation automatique des architectures qui garantissent des schémas toujours à jour (2) ;
Une organisation devops et une automatisation du traitement des incidents ;
Une approche itérative des projets, pour apporter de la valeur aux utilisateurs de manière linéaire sans sacrifier la qualité.
Certains argumentent que ces transformations sont réalisables à l’échelle des startups ou de compagnies digital natives, mais c’est oublier que le dev-ops tire son origine du monde industriel, certes beaucoup moins souple que l’IT, mais où la transformation vers le lean a été une condition de survie. The phoenix project (3) illustre très bien les parallèles entre le monde industriel et l’agilité , plus proche de notre quotidien, la gestion des maintenances des TGV est opérée par la SNCF via des tableaux agiles où l’ensemble des bonnes pratiques sont respectées.
Se transformer pour survivre
Les architectes n’auront bientôt plus le choix, les projets planifiés à plusieurs années induisent trop de risques :
tant sur le budget (il est de plus en plus difficile d’obtenir un budget pluriannuel pour un projet qui délivrera dans un futur éloigné)
que sur l’adoption utilisateur : la solution prévue ne correspondra plus aux priorités du business lorsqu’elle aboutira.
L’architecte doit donc à la fois porter une vision à long terme permettant de respecter les règles de l’entreprise, garantissant l’exploitabilité de l’application et être capable de faire opérer des changements d’architecture pour répondre aux priorités métier à court terme.
Un changement de paradigme est nécessaire pour passer d’une organisation ou les technologies sont des capacités de soutien qui fournissent des services, des plates-formes ou des outils spécifiques au reste de l’organisation, tels que définis par les priorités, les ressources et le budget, à une organisation ou les technologies sont parfaitement intégrées et au cœur de tous les aspects de l’organisation en tant que moyen de libérer de la valeur et de permettre des réactions rapides aux besoins des entreprises et des parties prenantes (4).
Il nous faut nous habituer à la distribution de valeur dès le début du projet et nous préparer à prendre en compte les nouveaux besoins à chaque nouveaux sprints.
Les utilisateurs doivent se sentir impliqués, considérés. Leurs remarques doivent être valorisées afin de rentrer dans un cercle vertueux qui permettra de délivrer de l’expérience utilisateur de qualité en continu.
Le succès des projets dépend maintenant de la capacité des architectes à prendre en compte les besoins des utilisateurs, afin de toujours pouvoir s’adapter aux priorités métier et délivrer de la valeur au plus près des enjeux business. Ces changements bousculent certainement les habitudes ancrées dans la DSI, mais la valeur dispensée aux utilisateurs justifiera l’investissement à apporter dans ces changements.
La question est légitime, car le CRM doit contenir l’ensemble des Clients / Prospects et l’information peut être tenue à jour par les commerciaux qui les rencontrent régulièrement. Mais avant de faire ce choix, quelques interrogations méritent d’être levées.
La gouvernance à mettre en place est-elle compatible avec mon CRM ?
Le CRM n’est pas le seul système à pouvoir créer, compléter ou mettre à jour des données Clients. Les systèmes de gestion, de facturation ou autres frontaux Clients influent également sur la vie de ces données. Appliquer au CRM l’étiquette de référentiel n’est donc pas suffisant. Il faut mettre en place l’ensemble de la gouvernance des données de référence Client (ou plus généralement concernant les Tiers) associées au principe de référentiel :
Définir le cycle de vie des Clients,
Définir un modèle objet exhaustif (qui ne soit pas limité aux seuls besoins du service commercial),
Pour chaque attribut, définir quels utilisateurs seront en capacité de le mettre à jour, à partir de quel outil, le tout en fonction du statut ou de l’état du Client,
Mettre en place une couche pour assurer la qualité de la donnée (formatage, dédoublonnage, contrôle de cohérence, complétion via des bases externes, …),
Prévoir les mécanismes et processus de validation des données,
Construire les interfaces nécessaires afin de consolider et de diffuser la donnée,
Définir les droits/politiques d’accès à la donnée,
Anticiper les impacts sur le pilotage, le reporting, la traçabilité, le versionning des données, la gestion des données à date, …
Quel modèle de donnée client dans le référentiel ?
Il faut également garder en mémoire que les CRM se concentrent par nature sur les éléments ayant trait à la relation commerciale avec les Clients. Or l’ensemble des données du CRM ne sont pas forcément à porter dans un référentiel. Inversement, dans bien des cas un CRM ne contient pas l’ensemble des données référentielles d’un Client (rôles du Client [payeur / commanditaire / bénéficiaire…], données techniques liées à la mise en place d’un service pour le Client…).
Construire le référentiel Client au sein du CRM implique donc de s’assurer que ce dernier contienne bien l’ensemble des données référentielles et de pouvoir aisément distinguer celles-ci des données à caractère opérationnel.
De plus, dans de nombreux cas cela implique également que des acteurs non commerciaux aient accès au CRM afin de maintenir ces données Client. La Direction Commerciale et Marketing souhaitera-t-elle ouvrir son outil à ces acteurs ? Ceux-ci accepteront-ils d’utiliser le CRM, outil qui n’est pas fait pour répondre à leurs propres besoins ?
Quel périmètre de données est concerné ?
Lorsque les clients sont des personnes morales, il peut être intéressant de croiser les données afin de savoir quels sont les clients qui sont également fournisseurs, quel est le chiffre d’affaire généré par un Client/Fournisseur vs la charge que représente ses prestations. Toute consolidation risque d’être complexe si les référentiels Client et Fournisseur sont distincts. Il s’agit pourtant dans les deux cas de personnes morales mais gérer ses Fournisseurs dans un CRM ne fait pas forcement sens. Dans ce cas, un référentiel ad hoc permettrait de pallier le problème. La problématique sera identique pour tout autre tiers d’intérêt comme les apporteurs d’affaire, les sous-traitants, les cautions / garants…).
Et la technique dans tout ça ?
Point inhérent aux précédents, le CRM a-t-il les capacités techniques pour assurer le rôle de référentiel ? Est-il capable de faire de la gestion de la qualité des données ? Ou alors s’intégrer avec un outil de DQM (Data Quality Management) spécifique ? Est-ce que le modèle de données du CRM est compatible ou suffisamment personnalisable afin d’intégrer le modèle de données de l’entreprise ? L’outil aura-t-il les capacités techniques pour diffuser l’information au sein du SI ? Supportera-t-il des dizaines de milliers de requête par jour ? Est-ce que le contrat de service associé à ce CRM est suffisant pour permettre à l’ensemble des applications qui en dépendent de fonctionner correctement ?
Est-ce que je fais un bon investissement ?
Les aspects financiers sont également un élément-clé de la décision. Certes, de prime abord, utiliser le CRM comme référentiel Client permet d’éviter un investissement dans un nouveau système, mais à quel prix ? Combien coûte la mise en place (et l’exploitation) des fonctionnalités de référentiel au sein d’un CRM ? Combien coûtent la haute disponibilité, la qualité de service, les SLA qui n’étaient peut-être pas nécessaires pour le simple usage des commerciaux ? Combien coûtent les licences supplémentaires attribuées aux utilisateurs qui n’étaient pas dans le périmètre initial ? Le modèle de facturation du fournisseur est-il en cohérence avec l’usage que l’on souhaite en faire (un coût à l’usage peut s’avérer rapidement très onéreux) ? Est-ce que l’économie est réelle lorsque l’on compare cette option à la mise en place d’un référentiel dédié ?
Quelles sont les autres solutions possibles ?
Si le CRM n’est pas l’outil le plus adapté à votre cas, quelles sont les autres possibilités ?
Les MDM (Master Data Management) sont a priori plus aptes à traiter les problématiques de référentiel de données puisqu’ils ont été développés dans cette optique. Ils possèdent des fonctionnalités pour traiter la saisie, la consolidation et la diffusion des données et intègrent généralement une couche de DQM permettant d’en assurer la qualité.
Toutefois, la prudence s’impose car tous les outils n’ont pas forcement la même maturité et tous proposent des fonctionnalités qui répondent à des besoins qui ne sont peut-être pas les vôtres. Pourquoi payer les fonctionnalités d’un progiciel si c’est pour ne pas les utiliser ?
Pour répondre à des besoins relativement simples, le développement d’une solution spécifique pourrait être considéré.
Quelle est la meilleure solution pour mon référentiel client ?
CRM, MDM ou développement spécifique, il n’y a pas de réponse générique, mais il peut y avoir des conséquences sur l’ensemble du système d’information.
Bien que tous les éditeurs (de CRM) soutiennent que leur solution peut être utilisée en tant que référentiel Client, ils sont beaucoup plus tempérés une fois les besoins et contraintes à traiter exprimés.
Par ailleurs, et non des moindres, il faut noter que ce n’est pas uniquement le réceptacle qui fait le référentiel. C’est bien la gouvernance qui encadre la donnée qui permet de maintenir le point de vérité. Il est nécessaire de mettre en place une organisation avec des rôles et responsabilités définis ainsi que des outils adaptés respectant l’urbanisation et l’architecture du système d’information.
Mais n’en sommes nous pas à la vision 360° client désormais ?
Encore une fois, malgré des éditeurs de CRM et de MDM qui promettent la Vision 360° Client, il faut replacer ces solutions à leurs « justes » fonctionnalités et regarder vers de nouveaux outils autour du Big Data qui permettent effectivement la mise en place d’une « vraie » Vision 360° Client sans pour autant remplacer le CRM ni le Référentiel Client. Ces visions consolidées et cross-business sont généralement utiles aux clients eux-mêmes mais aussi et surtout aux commerciaux ou gestionnaires pour leur permettre d’être encore plus efficient dans leur travail au quotidien.
Notons surtout que ces nouveaux outils ne font que renforcer l’intérêt d’un Référentiel Client qui soit partagé au sein du SI car construire une vision 360° Client nécessite d’agréger en un point unique des données venant de l’ensemble du SI.
De nouveaux types d’architecture, incluant la mise en place de Data Lake, d’API, de frontaux digitaux permettent la construction et l’utilisation de cette vision 360° mais elle ne restera possible que si les données peuvent être corrélées les unes avec les autres. Cette corrélation est grandement facilitée lorsqu’un référentiel Client a été mis en place au cœur du système d’information. La vision 360° n’a alors plus qu’à relier tous les éléments métier autour du « golden record » Client unique.
Le marché français était en léger retard depuis quelques années sur l’adoption du Cloud. Les entreprises américaines étant les premières à avoir fait le saut dans l’informatique en nuage. Pourtant les derniers chiffres issus du baromètre Markess indiquent une très forte hausse d’adoption depuis 2 ans avec une évolution annuelle tournant autour des 25-30%.
Nous avons pu confirmer ce changement lors de notre dernière visite au Salon Cloud Computing World Expo qui s’est tenu Porte de Versailles à Paris.
La première raison de ce changement est que pour certains domaines professionnels, les nouveaux standards du marché sont parfois uniquement disponibles à la demande (i.e. Office365 ou G-Suite). De nombreuses entreprises ont fait le choix de migrer leur messagerie et outils bureautiques devenus obsolètes vers des outils de collaboration plus adaptés au monde digital. A ce sujet, les collaborateurs en entreprise sont de plus en plus demandeurs de retrouver le même confort qu’ils ont à la maison : avoir accès à leurs applications depuis internet via différents devices (PC, tablette, portable).
Autre exemple, les solutions CRM étaient auparavant dominées par des socles logiciels très lourds à déployer et à maintenir. Beaucoup de sociétés veulent gagner en agilité et souhaitent limiter leurs investissements (CAPEX) en migrant vers des solutions Saas (i. e SalesForce.com). Ceci leur permet de déployer rapidement aux métiers des solutions tout à fait adéquates sans avoir besoin de développer des fonctions spécifiques sur mesure.
Comme l’a exprimé Emmanuel Guichet, directeur de la division IT Factory du groupe Total, lors d’une conférence:
« réaliser un projet de 18-24 mois pour concevoir les 20% de fonctionnalités manquantes n’est plus acceptable par la Direction Générale pour ce type d’application ».
Autre effet, inattendu il y a quelques années, le Cloud est vu maintenant comme un levier de croissance. Avec l’arrivée de nouveaux concurrents issus du monde du web, certaines entreprises ont été forcé à prendre des initiatives en dehors de leur business model habituel. Ceci a souvent nécessité la mise en place de nouvelles plateformes pour faire du Big Data ou s’interfacer avec des objets connectés (IoT) pour certains cas d’usages. Or ces innovations se font souvent en mode incrémental voir expérimental et ne justifient pas toujours les lourds investissements nécessaires au démarrage de ces projets. Il peut être pragmatique, comme l’a fait LeBonCoin.fr, d’externaliser ces briques applicatives afin d’adopter un paiement à l’usage pour mitiger ce risque.
Cette même stratégie permet de concevoir et de construire son architecture en mode Agile à moindre frais d’infrastructure sans avoir peur de tout remettre en cause. En fonction de la taille de votre structure, de vos compétences en interne et de la criticité de vos données, il vous restera ensuite de choisir les briques technologiques et le fournisseur Cloud appropriés.
Ces nouveaux entrants « disruptifs » ont également une particularité commune : ils ont tous des cycles de développements très courts ! Ils peuvent délivrer des nouvelles fonctionnalités en peu de temps à leurs utilisateurs finaux. Les entreprises traditionnelles se voient forcées d’abandonner leurs méthodes de gestion de projet classiques basées sur des cycles en V.
Elles doivent adopter des méthodes Agiles, Lean voire de revoir en profondeur leur organisation pour adopter une culture DevOps. AXA et la Société Générale, ont toutes les deux déclaré publiquement avoir entamé ces transformations importantes dans le but ultime de réduire leur « Time to Market ».
Les deux sociétés ont été contraintes pour des raisons réglementaires de s’appuyer dans un premier temps sur un Cloud Privé mais ont donné des indications de vouloir aussi s’appuyer sur du Cloud Public dans la mesure du possible. La Société Générale a indiqué avoir fait le choix d’utiliser des containers Docker pour faciliter la migration d’un Cloud à un autre et ainsi avoir un véritable Cloud hybride.
S’appuyer sur le Cloud a un effet bénéfique sur le budget opérationnel (OPEX) de ces entreprises. Cela leur a permis de rationaliser leur nombre de datacenters comme indiqué par la société minière et métallurgique Eramet.
Elles profitent de ces migrations pour revoir leur portfolio applicatif et décommissionner celles avec peu de valeur ajoutée comme le rapporte Thierry Favier, responsable informatique chez eSNCF.
Enfin, toutes celles venues témoigner au Salon ont entrepris de piloter la migration de leur SI Legacy vers le Cloud en tenant compte de deux critères majeurs : la réduction de coût et les risques opérationnels.
Le résultat est que pour toutes ces entreprises, s’appuyer sur du Cloud dans leur transformation digitale a été une évidence. Elles ont toutes défini en amont une stratégie de déploiement (Saas, PaaS, IaaS) propre à certains cas d’usages ou besoins fonctionnels. Que ce soit pour couvrir de nouveaux besoins, venir en appui de changement d’organisation et de culture ou pour réduire leur coût tout en se modernisant, elles n’ont pas hésité à franchir le pas !
Le Cloud est donc bien un tremplin vers la transformation digitale.
Pour fournir une vision d’ensemble du SI et de sa transformation, l’architecte doit faire émerger les principes du « vivre ensemble » partagés par l’ensemble des parties prenantes du SI.
Un SI construit sans vue d’ensemble c’est ça
Et les connexions entre applications ressemblent à ça
Construire ensemble
La cible du SI et ses paliers de transformations fournis par l’architecte d’entreprise sert à donner à chacun la vision d’ensemble dans laquelle il s’insère.
Lorsqu’une solution n’est pas compatible avec la direction donnée et les bases de la construction, elle peut avoir de grandes répercussions sur les autres, voire mettre l’ensemble de la construction en danger (ici la structure de l’immeuble a failli s’effondrer sous le poids supplémentaire).
Chacun a son point de vue sur la solution, et tout le monde a raison (de son point de vue évidemment)
Chacun imagine des solutions, même si celles-ci peuvent paraître en décalage avec l’idée qu’on s’en fait. Des dérogations peuvent être accordées tant qu’elle ne gêne pas l’ensemble de la construction l’architecte d’entreprise ou le difficile équilibre du vivre ensemble L’architecte d’entreprise ou le difficile équilibre du vivre ensemble discussion
Une fois que la cible est définie et partagée par tous, il faut alors effectivement définit les règles du vivre ensemble
L’architecte d’entreprise est là pour proposer des principes communs qui permettent de faire avancer le SI dans son ensemble. Il a pour but de faire communiquer les différentes composantes de l’entreprise et de trouver les solutions qui conviennent à tous, qui sont les plus pérennes et les plus proches des standards voulus par l’entreprise. Dans notre monde actuel, les connaissances sont fragmentées et la coopération entre toutes les parties est essentielle pour tirer le meilleur des nouvelles situations et des technologies.
L’architecture globale du SI doit permettre de laisser chacun libre d’aménager (ou pas !) son propre espace (l’intérieur de sa solution). Le but est alors que chaque solution puisse vivre selon son propre rythme en harmonie avec les autres et en garantissant un langage minimum commun pour se comprendre.
Peu importe la solution choisie pour le SI, la bonne solution est celle qui répond au problème. Elle doit être partagée par tous, construite suivant les règles de l’art et chacun doit pouvoir y trouver sa place.
Quelques grandes règles et principes suffisent pour construire ensemble un édifice solide. À tout moment, il doit être possible de justifier des principes qui nous ont amené à choisir cette solution. Ces principes peuvent (doivent) évoluer bien sûr. Ils sont là pour nous aider à se poser les (bonnes) questions. La gestion des dérogations à ces mêmes principes est un art subtil à manier avec précaution et à ne pas négliger !
La bonne architecture fournit la solution adaptée à un besoin en prenant en compte les différents paramètres de coûts, délais, qualité, esthétique, technique, évolutivité etc.
Les DSI pâtissent souvent de ne pas avoir une description claire de leur SI. Une description qu’ils puissent montrer aussi bien aux métiers pour déclencher les budgets et l’intérêt, qu’aux différents interlocuteurs (nouveaux entrants, sous-traitants, etc.). Elle permet d’expliquer le fonctionnement global du SI dans sa complexité, dans les différentes composantes majeures, dans les parties prenantes impliquées, etc. Et quand on parle de description, il ne s’agit ni de la liste des lignes budgétaires, ni de la liste des projets, ou autre. Nous parlons de la vraie description du fonctionnement du SI avec ses principales applications / domaines et les flux qui permettent de décrire un fonctionnement dynamique du SI.
Un de nos clients, une filiale d’un grand groupe bancaire nous a demandé récemment d’avoir le « poster » avec les principales applications et les flux, pour qu’il puisse comprendre et présenter le SI. Il était inquiet de ne pas savoir avec qui / quoi le SI était en interaction… Cela lui permet aussi de bien visualiser et de positionner ses enjeux en terme de transformation, d’investissements, etc.
Combien de DSI, malgré toutes leurs demandes et les missions de cartographie ne disposent toujours pas de la cartographie claire de leur SI ? Une cartographie qui leur permette de maîtriser ce qu’est leur patrimoine et leur « terrain de jeu ».
Combien de fois, les architectes sont revenus faire des dessins aux tableaux pour expliquer tel ou tel point, et au final, c’est toujours le même dessin qui est fait, mais personne ne capitalise dessus ? J’ai vu faire un architecte devenu un client, qui expliquait pendant plusieurs séances, le SI et sa transformation avec un dessin au tableau. Il rajoutait, modifiait des explications au fur et à mesure des échanges avec ses interlocuteurs. Le tableau devenait alors trop illisible et il refaisait son dessin sur un paper board, et c’était reparti pour un cycle. Nous lui avons fait le fonds de carte et maintenant, il raconte son histoire à partir de là en mettant régulièrement à jour ce dessin qui est devenu son « fonds de commerce ».
Cette démarche de description macro du SI doit être faite rapidement. Dans un esprit agile, les premières étapes doivent être celles qui apportent le plus de valeur ajoutée.
Ne pas finir une cartographie, ce n’est pas grave, à condition que l’on ait apporté le plus de valeur ajoutée dès le début.
Dans le cadre de nos interventions, notre démarche nous permet de répondre précisément et complètement à ses attentes et de fournir les vues pertinentes à la compréhension du SI. Une vue assez stable pour ne pas devoir être mise à jour à la vitesse des projets (qui se succèdent à un rythme effréné en ce moment) et qui permet de bien comprendre les grands enjeux du SI.
Définissons ensemble les vues qui vous manquent le plus et donc celles qui vous apporteront le plus de valeur. Nous allons commencer par celles-là et y mettre les moyens !
Vision cible du si dans un contexte mondial avec filiales, erp, industrie 4.0 et référentiels
Contexte
Un grand groupe industriel mondial possédant des dizaines de filiales est en pleine évolution de son SI sur plusieurs aspects : digital, référentiels, industrie 4.0, ERP, etc. Le groupe a besoin d’avoir de la visibilité sur son futur, la cible de son SI et les moyens d’y parvenir.
Solutions
Mettre en place un cadre de référence pour les métiers et poser une vision globale de l’entreprise à partir d’une Carte des capacités métiers
Poser une vision globale de l’évolution du SI à 5 ans et notamment le périmètre de l’ERP
Identifier les périmètres nécessitant des études complémentaires autour de l’ERP
Poser les scénarios d’évolution des référentiels SI
Cartographier l’ensemble des applications du SI et les principaux flux
Choisir un outil de cartographie et le déployer
Mettre en place la gouvernance de l’architecture d’entreprise : livrables, outils, comitologie
Bénéfices
Vue d’ensemble du SI et des évolutions prévues avec un partage au plus haut niveau de l’entreprise
Cartographie partagée de l’ensemble du SI
Vision cible des échanges du SI
Pérennisation de l’activité d’Architecture d’Entreprise
Les aurtes success stories qui peuvent vous intéresser
