Le reporting AnaCredit sera prochainement obligatoire pour chaque institution de crédit d’un pays de la zone euro, cela inclut aussi leurs succursales quel que soit leur lieu d’implantation.
Ainsi, sont concernées :
Etablissement de crédit résident ainsi que leurs succursales étrangères hors zone euro
Les filiales d’établissement de crédits étrangers résidentes
Les succursales des établissements de crédit à condition que celles-ci soient résidentes dans un Etat membre de la zone euro
La déclaration s’effectuera auprès de la banque centrale nationale (BCN) compétente (qui ensuite va transmettre ces données à la Banque centrale européenne).
Par exemple, pour une succursale italienne d’une banque française, les données de la succursale devront être déclarées dans le reporting de l’entité juridique à la Banque de France mais aussi auprès de la Banque d’Italie dans le cadre du reporting de la succursale.
En conséquence, lorsque l’entité juridique et sa succursale étrangère résident dans la zone euro, cela représente une problématique pour les institutions :
Un « Double reporting » certain
Un risque de déphasage des deux déclarations tant du point de vue du nombre de données à fournir (95 données demandées par la BCE mais 79 données après mutualisation au minimum) que sur la qualité de la donnée (Définition différente dans le contenu de certains champs selon le pays. ex : calcul du Forborne)
Afin d’éviter ce « double reporting », la BCE prévoit des possibilités de contournement afin de minimiser ou supprimer cette charge pour des établissements de crédits internationaux :
La Banque Centrale nationale compétente de l’entité juridique pourrait décider de ne pas collecter, ou seulement une partie, des données listées dans le template 1 de l’entité juridique quand ces « instruments » sont détenues par la succursale.
La Banque centrale nationale compétente de la succursale peut décider de ne pas collecter, ou seulement une partie, des données listés dans le template 2 depuis la succursale.
Par ailleurs au niveau français, la Banque de France lance des actions de rationalisation : sur les collectes de succursales zone euro ou des suppressions de duplication entre les données BCBS 239 et AnaCredit (en cours).
D’autres évolutions AnaCrédit à suivre dans nos prochaines publications…
Aliados Conseils rejoint Rhapsodies Conseil pour consolider l’expertise Risk, Regulation & Compliance (2RC). La nouvelle entité sera co-animée par nos deux Seniors Managers Lionel Andreu et Patrick Rose, au sein du pôle Expertise Paiements et Risques.
« Dans le cadre de notre expansion et afin de répondre à la demande de nos clients, soumis à l’évolution croissante de la réglementation dans le secteur financier : BCBS239, Anacredit, IFRS9, FATCA/CRS, 4ème Directive TracFin…, l’arrivée d’Aliados Conseils, avec qui nous avions déjà une relation de partenariat, complète notre capacité d’intervention, de la veille réglementaire jusqu’aux procédures opérationnelles et à la production des reportings. » déclare Patrick Rose, Senior Manager de Rhapsodies Conseil.
« Le rapprochement et la fusion des équipes Aliados & Rhapsodies sur les thèmes majeurs du Risques et du Cash Management va permettre d’élargir notre offre auprès de nos clients et de proposer une diversité d’intervention à nos collaborateurs. Aliados était à la recherche d’un partenaire sérieux mais audacieux depuis plusieurs mois, avec l’équipe Rhapsodies nous sommes désormais parés pour faire face à une forte demande dans le domaine bancaire et des interventions de transformation des SI.» déclare Lionel Andreu, Fondateur d’Aliados Conseils.
« Le Rapprochement avec Aliados Conseils représente une étape importante dans notre stratégie de croissance et affirme notre position sur nos segments de marché. Par l’apport d’expertises complémentaires, ce rapprochement nous permet de proposer une offre complète autour des Risques, du Réglementaire et de la Conformité, laquelle améliore encore notre proposition de valeur pour procurer à nos clients compétences et capacités d’innovation dans ce domaine hautement stratégique à l’ère numérique. » déclare Olivier Barthélemy, Président de Rhapsodies Conseil
A propos d’Aliados Conseil Aliados Conseils est un cabinet de conseil spécialisé en Corporate Finance, Cash Management, Capital Market, Regulatory Reporting, Risk – Ratios. Basé à Paris, Aliados Conseils fournit aux directions financières et aux lignes métiers des établissements Private Banking, Middle Banks et Corporate internationaux, les compétences d’experts indispensables aux exigences réglementaires et commerciales.
A propos de Rhapsodies Conseil Rhapsodies Conseil, cabinet indépendant de conseil en management créé en 2006, accompagne les programmes de transformation stratégiques de ses clients et leur mise en œuvre opérationnelle dans 3 pôles d’expertise choisis :
Architecture & Transformation,
Expertise Paiements & Risques,
Sourcing & Performance Economique.
Forts de nos 80 collaborateurs et de notre large expérience, nous intervenons au quotidien auprès des Grands Comptes dans différents secteurs d’activité, banques, assurances, industrie, luxe…
Le service Cloud d’Amazon, AWS, a été victime récemment d’une panne majeure de son service de stockage simple nommé S3. Cette brique technique est très populaire et répandue pour implémenter des applications ou services hébergés chez AWS. Pour vous donner une idée de l’ampleur de son utilisation depuis son lancement en 2006, ce service permet aujourd’hui de stocker des dizaines de milliards d’objets. D’autres briques techniques chez Amazon peuvent s’appuyer sur ce stockage pour fonctionner comme le service Elastic Compute (EC2), Elastic Block Shop et Lambda. Cette panne de service a eu donc pour effet d’engendrer des perturbations majeures pour plusieurs applications hébergées chez AWS :
La messagerie instantanée Slack
Le service de stockage en ligne Box
Le service de livraison des pizzas Dominos
Les sites web communautaires Reddit et BuzzFeed
Heureusement la cause de l’incident a vite été repérée et corrigée par l’hébergeur. En revanche, elle a tout de même engendré des indisponibilités de plusieurs heures pour certaines de ces applications. Est-ce que les entreprises ayant pris la décision de faire appel à du Cloud Public doivent pour autant entrer en mode panique et rapatrier leurs applications et données chez eux ? La réponse est NON bien entendu. Amazon a rapidement communiqué que la nature de la panne du service S3 était due à une erreur humaine déclenchée par un employé ayant toutes les autorisations et qui aurait soumis une commande manuelle avec de mauvais paramètres. De plus, l’impact de la panne se limitait uniquement au « datacenter » de la région Virginie située sur la côte Est des Etats-Unis. Une telle erreur aurait pu donc se produire n’importe où, chez n’importe quel fournisseur d’hébergement y compris dans vos propres « datacenters ».
Cet incident nous rappelle seulement qu’il ne faut pas se fier uniquement à la résilience de la couche infrastructure Cloud, même chez le leader du marché, pour garantir une haute-disponibilité. Il est bon de rappeler ici que les engagements de service (SLA) pour la brique S3 ne sont que de 99,99%. Ceci signifie tout de même une indisponibilité potentielle de 87,5 heures pour une année ! Le fournisseur de service de vidéo en ligne Netflix est aussi hébergé chez AWS et il a pourtant été épargné par la panne du service S3. Une étude réalisée en interne en 2014 avait permis d’estimer une perte de 200 000$ de chiffre d’affaires pour une heure d’arrêt de la plateforme. Nous pouvons donc estimer qu’en 2017 le coût total d’une panne de 4 heures aurait pu leur coûter plus d’1 million de dollars. Ceci est sans compter l’impact négatif sur la réputation et image auprès de leurs usagers qu’une telle panne aurait pu occasionner . En tenant compte de ces besoins, les architectes techniques de Netflix ont conçu une architecture cloud résiliente basée sur plusieurs zones AWS. Ceci leur permet donc d’éviter toute perte de service en cas de panne ou incident et d’avoir un meilleur SLA que les 99,99% promis par le fournisseur.
L’impact financier de l’arrêt de votre application métier est probablement moindre que celui de Netflix. Vous n’avez peut-être pas non plus un fournisseur Cloud ayant plusieurs « datacenters » dans différentes régions comme peut l’offrir AWS. Pour autant déployer vos applications sur du Cloud Computing ne vous affranchit pas du tout des services d’un architecte technique, au contraire ! Celui-ci, s’il déroule une démarche prenant compte des besoins métiers et des exigences non fonctionnelles, saura vous proposer des scénarios d’architectures résilientes. L’architecture finale sera plus chère et complexe sans doute. Il ne faut pas oublier dans ce cas d’estimer l’impact et la probabilité d’une perte de service avant d’évaluer si ces coûts supplémentaires en valent la chandelle.
Sources d’information pour incident AWS S3 survenu en mars 2017 :
Déployer des applications Saas sur Cloud Public est devenu très populaire chez certaines Directions Métiers en France. Tout ceci pourrait être amené à changer avec la nouvelle directive Européenne (GDPR) sur la protection des données personnelles qui entrera en vigueur en 2018. En effet cette réglementation exige une très forte gouvernance des fournisseurs hébergeant ces données. Le risque de recevoir une pénalité de 4% de son chiffre d’affaire mondial en cas de non-conformité pourrait donc inciter certaines Entreprises à demander à leur DSI de reprendre l’initiative.
Ce n’est donc pas un hasard de calendrier si l’ANSSI (Agence Nationale de la sécurité des systèmes d’information) a créé conjointement avec son homologue allemand (BSI) un nouveau label nommé European Secure Cloud (ESCloud). Une première version du référentiel des exigences a été publiée en décembre 2016. Elles couvrent les aspects suivants :
Mener une politique de sécurité en regard d’analyse de risques. Celle-ci devant être faite périodiquement pour une même application.
Avoir un responsable de sécurité de l’information, un responsable de la donnée personnelle et un responsable de la sécurité physique de ses installations.
Avoir un plan de sensibilisation à la sécurité au niveau ressources humaines : charte éthique, formation, gestion et capitalisation de la connaissance.
Avoir une politique de contrôle et droits d’accès pour ses bâtiments et certaines zones plus sensibles.
Avoir une cartographie de son SI au niveau infrastructure à jour.
Encrypter les données sensibles et chiffrer les flux. Hacher les mots de passes pour ne pas qu’ils soient accessible en clair.
Avoir une politique de sécurité pour prévenir et surveiller les failles: journaux d’évènements horodatés, analyse du code source si possible, tests d’intrusion fréquents, …
Avoir une politique de gestion des incidents de sécurité y compris de manière préventive.
Avoir une convention et un respect des engagements avec les sous-traitants participants à la mise en œuvre du service.
Garantir une localisation, un traitement des données et une gestion des opérations du datacenter au sein de l’Union Européenne.
Autoriser un organisme certifié par l’ANSSI à venir l’auditer et vérifier le respect de ses exigences.
Pour ceux qui douteraient de l’importance d’avoir un fournisseur de confiance, voici quelques chiffres 1 :
81% des entreprises françaises se sont dit victimes d’une cyberattaque en 2015.
Se remettre d’une violation de sécurité coûte en moyenne 800 000€.
9 semaines sont nécessaires en moyenne pour corriger une faille de sécurité.
35% des incidents de sécurité auraient été généré (parfois malgré eux) par les collaborateurs de l’hébergeur de ces données.
La plupart de ces exigences étaient déjà incluses dans les principales normes de sécurité reconnues par le marché : ISO-27001, SOC1, SOC2, CSA-CSM. L’effort à fournir pour obtenir ce label (GDPR) est donc faible pour les fournisseurs qui avaient déjà obtenu les principales certifications. C’est cependant une bonne chose d’avoir créé un label Européen pour rassurer les entreprises du vieux continent. En effet, que veulent les Directions Générales et les DSI ? Avoir l’engagement que le fournisseur de l’hébergement pourra assurer la sécurité de leurs données et que celles-ci ne vont pas se retrouver aux mains d’un concurrent, d’un gouvernement étranger ou d’une organisation malveillante. Ces entreprises veulent maîtriser le droit d’accès à ces données et ont besoin de partenaires qui accepteront d’être transparents et de partager la responsabilité de conformité sur la protection des données.
Au moment où nous rédigeons ces lignes, seuls 3 fournisseurs de services cloud ont fait la demande du label. Cependant il est fort à parier que tous les principaux acteurs du marché tenteront à moyen terme de décrocher ce précieux Graal qui leur facilitera l’accès au marché des entreprises européennes. Les entreprises françaises utilisaient jusqu’à maintenant très peu le Cloud et principalement pour du stockage ou des services de messagerie en mode SaaS. La plupart d’entre elles mettaient en avant les risques liés à la sécurité comme frein à son utilisation. L’obtention de ce nouveau label Européen est donc un pas en avant pour permettre de gagner la confiance des décideurs.
Pour conclure, il est fort à parier que nous devrions observer une hausse de part de marché des offres IaaS et PaaS sur Cloud Privé et voir une baisse de celui sur Saas déployé sur Cloud Public. Les DSI n’ont plus d’autre choix que de reprendre le contrôle de ces environnements. La part de « Shadow IT » dans les entreprises devraient donc diminuer aussi significativement. Le risque de recevoir une pénalité de la CNIL étant trop grand en cas de non-conformité à la GDPR.
1 : D’après l’article « Cybersécurité : Cinq chiffres clés à connaître »
Je suis intervenu le 10 octobre dans une grande banque française à l’occasion de leur « Agile Day » annuel. On m’a demandé d’intervenir sur l’impact de la transformation agile sur le management.
Mon constat est que la transition managériale dans les grands programmes de transformation agile n’est pas efficace. Ce constat commence à être partagé et mes réflexions m’ont amené à identifier une approche différente de celle traditionnellement mise en œuvre.
Pour développer les Hommes, travaillez sur l’environnement en premier
Quand vous souhaitez amener une entreprise vers un leadership plus agile, il ne suffit pas de décréter qu’elles doivent devenir agiles. Il est nécessaire de rénover le système, qui dans la quasi-totalité des cas, n’est pas compatible en l’état.
Supprimer les silos entre les métiers, les équipes de développement et les équipes de production (approche que j’appelle BIZDEVOPS) est une première étape d’une transformation agile. Modifier les mécanismes contre-productifs, comme les systèmes d’objectifs orthogonaux entre DEV et PROD par exemple, devrait être l’étape suivante. On peut même imaginer une gouvernance d’entreprise basée sur une information transparente, fraîche et honnête, générant des prises de décisions décentralisées et efficaces.
Pour travailler sur le système, vous pouvez démarrer par :
identifier clairement et communiquer beaucoup sur la vision de l’entreprise : son but, sa raison d’être. Finalement, le rôle du dirigeant pourrait se résumer à cela : répéter encore et encore la raison d’être de l’entreprise. C’est d’ailleurs une constante dans les organisations « libérées » qui surperforment dans leurs domaines d’activité.
décentraliser les prises de décisions en donnant plus d’autonomie. Cela signifie en corollaire de garantir un accès transparent à l’information, de développer les compétences, de bâtir des interactions basées sur la confiance mutuelle et de donner le droit à l’erreur dans une approche « fail fast, learn fast ».
Former n’est pas assez
Une fois la prise de conscience et les modifications réalisées au niveau de l’organisation, accompagnez vos managers dans le changement nécessaire de posture. Car en modifiant l’organisation et les interactions entre les différentes parties prenantes, l’impact sur le manager est plus important qu’il ne pourrait y paraître. J’ai déjà rencontré des chefs de projets qui venaient se plaindre de l’agilité parce que leurs équipes parlaient désormais directement avec le Product Owner pour la priorisation des sujets, alors que c’était leur prérogative quelques mois plus tôt.
D’une approche où le manager est traditionnellement un sachant promu pour sa compétence technique (et pas forcément sa compétence en leadership !), nous évoluons vers une approche où le manager s’oriente plutôt vers une posture d’hôte (Host Leadership) ou de coach, avec comme objectif de faire émerger de nouveaux leaders dans son équipe.
Plutôt que d’envoyer les managers en formation pour leur apprendre des recettes qu’ils ne pourront/sauront pas appliquer dans la plupart des cas, préférez un accompagnement sur le terrain. La formation peut être envisagée comme un apport complémentaire si nécessaire et dans un second temps. Le coaching des équipes et des individus amène des résultats bien plus probants car les acquis sont ancrés dans le concret, et surtout, l’apport régulier du coach sécurise la montée en compétences opérationnelle. L’expérience du coach va aussi aider à gérer des situations délicates qui ne manqueront pas d’arriver, et également à identifier les ajustements nécessaires aux modifications réalisées sur le système, dans une approche d’amélioration continue.
En tant qu’architecte d’entreprise, l’agilité fait partie intégrante de ma vie et des projets depuis déjà quelques années. Mais qu’il est difficile de s’y retrouver dans tout ce qui est, ou se prétend, Agile. Alors comme tout bon architecte d’entreprise, j’ai commencé par faire un état des lieux : une cartographie.
Attention : ici je ne parlerai pas de technologies (chaque chose en son temps) mais bien de méthodes et d’approches.
Agilité, vaste monde !
L’agilité tout le monde en parle mais qui en fait vraiment ? De quelle agilité parle-t-on ? De méthodes Agile ? Plutôt que méthode, les termes utilisés sont plutôt culture, approche, mouvement ou courant Agile. L’agilité est mise à toutes les sauces : pour faire de l’innovation, de la gestion de projet, des modes de déploiement mais aussi pour le management d’entreprise.
Et l’agilité s’appuie sur des techniques plus anciennes comme le Lean, qui intègre Kanban et Kaizen.
Certains ont imaginé une carte de l’ensemble des pratiques Agile (voir ci-dessous) ressemblant au métro de Londres. J’avoue qu’avant j’étais un peu perdu, maintenant je suis complètement noyé !
Donc afin de simplifier et de présenter les pratiques d’un point de vue « Externe » à l’agilité, j’en propose une autre :
4 catégories pour s’y retrouver :
Le niveau entreprise : l’agilité a pour vocation de conquérir toute l’entreprise et de proposer de nouveaux modes de management
L’innovation : comment s’organiser pour trouver des solutions innovantes, des produits adaptés aux utilisateurs ?
Equipes et Projets : le Manifeste Agile et la méthode Scrum notamment rentrent dans cette catégorie, pour les projets de petite et moyenne taille. Utilisables par tous les projets mais surtout appliqués dans les projets IT à ce jour
Build et Opération: ensemble des méthodes et des techniques permettant d’implémenter dans le SI les produits délivrés par les projets
En parallèle, une catégorie « Techniques et Ateliers » est identifiée pour rassembler l’ensemble des techniques d’animations proposées dans le cadre de l’agilité et définir leur utilité.
Nous avons choisi de présenter ces 4 catégories dans un ordre qui part de l’innovation, puis des équipes et projets pour aller vers l’implémentation de leurs produits dans le SI en finissant par le déploiement de ces approches au niveau de l’entreprise.
L’innovation
Avec les nouvelles technologies et les nouveaux usages, sont apparues des techniques permettant de faire émerger l’innovation. Ces techniques mettent au centre de ces approches les utilisateurs des futures solutions et produits. Ces démarches sont souvent itératives et donc correspondent bien à la gestion des projets en agilité.
L’apport de ces démarches est de « se mettre à la place de ». Le concepteur de solution doit apprendre à penser comme la personne pour laquelle il doit bâtir une solution. Tous les concepteurs ou les MOA se sont plaints un jour que « le métier » ou « le client » ne savait pas exprimer son besoin. Le problème se résout de lui-même avec ces techniques. Basées sur les interactions avec les futurs utilisateurs, les personnes dont le métier est de concevoir peuvent comprendre voire anticiper leurs attentes.
L’innovation ne peut pas être encadrée ou commandée. Des principes d’innovation et les conditions pour créer de l’innovation peuvent être identifiées et donc mis en place rapidement pour sortir des anciens modes de conceptions de solution.
Méthodes et approches : Human-centered design, Design Thinking, Innovation game
Equipes et projets
Un changement de paradigme complet dans la manière de gérer les projets est apparu avec les approches Agile. SCRUM est la méthode de gestion de projet Agile la plus connue mais il en existe d’autres.
Cette approche a radicalement changé la manière de conduire des projets, le traditionnel « cycle en V », et de produire des résultats. On avance par itération, par incrément. Finis les effets tunnels. Les résultats sont rapidement concrétisés et il est possible de réagir au fur et à mesure.
Les projets en mode agile permettent d’adapter les produits au fur et à mesure de l’avancement du projet et de la réflexion.
Ces approches ont apporté de grands changements dans les méthodes de travail avec des réunions plus courtes mais plus fréquentes (tous les matins !), du management visuel, des capacités d’adaptation et d’auto-organisation qui sont à l’inverse des habitudes de management des anciens projets et de tous leurs travers.
Mais surtout ces approches ont entamé une révolution culturelle car elles font travailler ensemble de manière régulière et rapprochée des équipes, des spécialités qui ne se côtoyaient que peu ou rarement. Ces différents métiers ne se comprenaient pas ou mal. Les faire collaborer est toujours un challenge mais qui conduit à des résultats très concrets.
Méthodes et approches : Scrum, eXtreme Programming, Rapid Application Development, Domain Driven Design, Disciplined Agile Delivery, Dynamic systems development method (DSDM), Crystal Clear, le Manifeste Agile
Build et opération
Un des principes des projets en agilité est de pouvoir livrer régulièrement des incréments de valeur. Le but premier est de pouvoir tester ces incréments au fur et à mesure et de vérifier qu’ils satisfont l’utilisateur final. Dès lors, ces produits partiels (fonctionnels) peuvent être mis en production sans attendre la fin de l’ensemble des sprints.
Encore faut-il que le SI soit prêt à supporter ces mises en production régulières. Il est nécessaire de mettre en place des usines logicielles permettant de produire, tester, mettre en production et maintenir en fonctionnement les produits dans les meilleurs délais. Pas question d’attendre plusieurs semaines ou mois avant de mettre en production un produit prêt.
Les phases de validation, tests, recettes, peuvent être très consommatrices de temps. Elles doivent donc être anticipées et automatisées au maximum pour atteindre une vraie industrialisation. Les gains de temps et de qualité atteints grâce aux équipes et projets ne sont ainsi pas perdus dans les étapes de tests et de mise en production.
Les équipes IT ont mis en place des stratégies qui permettent, dès le début des projets, de prévoir ces futures étapes. Les tests sont identifiés dès le départ et sont automatisés. On parle d’intégration continue, de déploiement continu, de livraison continue.
Et une fois les produits en production, il faut les maintenir et les exploiter. L’approche DevOps (qu’on peut définir en quelques mots par l’agilité pour les opérationnels) devient de plus en plus utilisée aujourd’hui. Cette approche illustre bien le passage sans heurt de la conception des solutions vers leur mise en production et leur exploitation. Les équipes d’opération et de développement travaillent ensemble, et non plus en campant sur leurs positions respectives : « je n’ai pas les documents pour assurer la maintenance », dixit la maintenance, « je ne sais jamais quels documents ils veulent », dixit les développeurs.
Méthodes et approches : Le test-driven development (TDD), Behavior Driven Development (BDD), Continuous delivery, Continuous deployment, Mikado Method, devops
Le niveau entreprise
Faire travailler des équipes en mode agile suppose de la responsabilisation et de l’autogestion. Le reste de l’entreprise, et notamment le management, ne peut continuer à fonctionner comme avant au risque d’être contre-productif.
En agile, c’est l’équipe (via notamment le Product Owner) qui est responsable de son produit, le rôle du manager n’est plus alors de décider ce qui doit être fait.
Le manager change de rôle et c’est un vrai changement culturel. Les hiérarchies actuelles n’ont pas du tout été formées à ces approches. Le manager devient un facilitateur, celui qui met dans les bonnes conditions, c’est aussi un vrai relai d’information dans les 2 sens (vers l’équipe mais aussi vers le reste de l’entreprise).
Comme tout changement, il entraine des pertes de repère, de la résistance au changement et donc il doit être maitrisé et accompagné. Plusieurs méthodes, modèles et approches démontrent les bénéfices que l’on peut en tirer sans en nier les difficultés.
Méthodes et approches : Agilité à l’échelle (SAFe, LeSS, Spotify, Nexus), Management 3.0
Les ateliers
Un des principes fondateurs de l’agilité est la co-construction. A ce titre de nombreux types d’ateliers de travail existent. Ils ont pour but de faire réellement travailler ensemble les personnes au sein des équipes, de développer les « softskills » (compétences humaines) mais aussi produire des résultats : produits, plannings, études d’impacts etc. Le nombre d’ateliers et de variantes est infini, même si environ une quarantaine de techniques d’animation se détachent. Nous proposons un regroupement sur 8 thématiques :
Icebreaker : idéal pour se lancer quand les gens ne se connaissent pas ou peu.
Intelligence collective : démontrer la force de la collectivité mais aussi ses manières particulières de fonctionner
Planification (et volumétrie) : construire ensemble des plannings, faire des estimations
Définition de cible : vers où voulons nous aller ensemble, qu’est-ce qu’il est réaliste de proposer ?
Impacts et trajectoire : comment aller vers la cible, quels sont les impacts des changements proposés ?
Priorisation des travaux : décider ensemble de ce qui est prioritaire
Conception de produit : orienter vers l’innovation et la recherche de solutions
Team building : construire des équipes qui savent travailler ensemble et communiquer efficacement
Ces ateliers peuvent être utilisés individuellement mais surtout en combinaison pour atteindre encore plus rapidement et efficacement l‘effet recherché. La durée varie de 15mn à 3j.
Intenses et efficaces, ces ateliers permettent de débloquer des situations et de remettre du lien dans des équipes, de les remotiver pour leur travail : un icebreaker, puis un teambuilding avant de faire de l’innovation et de la priorisation. Le tout en une journée. L’équipe en ressort non seulement remotivée mais surtout avec des résultats concrets et directement utilisables dès le lendemain
Une fois ce paysage posé, l’agilité peut effectivement être identifiée un peu partout dans l’entreprise.
Les architectes d’entreprise en tant que garants de la vision d’ensemble du SI doivent accompagner ce mouvement et y prendre part. Plusieurs niveaux vont être abordés dans notre série « Architecture d’entreprise et Agilité » :
Chapitre 2 : détournement de valeur. Toutes les fausses ou contre-vérités entendues à propos « des projets Agile »
Chapitre 3 : comment l’architecte d’entreprise peut aider à concevoir et entretenir un « SI Agile »
Chapitre 4 : comment les architectes d’entreprise (mais aussi les autres) peuvent interagir avec les projets en agilité.
