Petite synthèse à chaud des débats de la table ronde organisée par le GT RED (Groupe de Travail Règles, Evolutions & Déploiements) du France Payments Forum. Le thème « Bilan des API DSP2 » était d’actualité quelques semaines après le 14 septembre.
2 heures d’échanges fournis et directs (la règle avait été partagée : « on est là pour se dire les choses… ») entre :
2 banques : Alain BENEDETTI (BNP Paribas) et Dominique BEAUCHAMP (NATIXIS PAYMENT SOLUTIONS) et
2 TPP : Romain BIGNON (BUDGET INSIGHT) et Mathieu PERE (TINK),
animées par Ludovic VATHELOT (TREEZOR).
Emmanuel NOBLANC (SAB) avait démarré avec une KeyNote pour poser le contexte.
J’avais la charge de restituer une synthèse pour conclure…
Que retenir à chaud, à la fin des débats ?
A défaut d’une analyse posée, j’ai surtout retenu la différence de ton entre les échanges sur :
la DSP2 et les RTS, vécus par tous comme une contrainte, avec des choix pris dans un contexte et étendus abusivement (par exemple entre Agrégation et Initialisation) et générant des positions défensives
l’OpenBanking, avec l’illustration de cas d’usage et d’initiatives, avec un enthousiasme communicatif à l’ensemble de l’auditoire.
Pour commencer, il était utile de rappeler que TPP et ASPSP ont plus en commun que la DSP2 ne le laisse voir : les ASPSP sont aussi des TPP ! Chacun a d’ailleurs noté le caractère schizophrénique de cette double posture des ASPSP :
réticence du fait que les API réglementaires sont imposées sans rémunération
vs. initiatives des ASPSP dans l’initiation de paiement (pour illustration, les cas d’usage de Natixis Payments Solutions avec Foncia et System U).
Ceci dit, les acteurs ont largement souligné les difficultés rencontrées dans la mise en œuvre des RTS, avec un constat unanime de progrès significatifs depuis le 14 septembre, mais encore aucune utilisation opérationnelle significative des API déployées. Les obstacles sont multiples :
Problèmes techniques de stabilité, bien sûr
Complexité générée par l’hétérogénéité
Implémentations techniques différentes (malgré les travaux de standardisation menés autour de STET ou de Berlin Group),
Ecarts fonctionnels (divergences de vue sur le périmètre de la règlementation, sur les données requises, mais au-delà sur ce qui apparaît même comme des incohérences de la DSP2 : comment concilier l’esprit de la Directive d’étendre l’offre de service, notamment l’initiation de paiement marchands et la lecture stricte de présenter via API l’équivalent de son offre de Banque en Ligne),
Parcours clients variant de 2 à 7 étapes utilisateurs (avec la problématique de SCA), rassemblés dans une offre d’agrégation soulignant les différences de fluidité…
Exigence de continuité du service déjà déployé par les TPP, qui ne peuvent basculer sur les API qu’une fois atteint un niveau de fiabilité équivalent aux alternatives actuelles de Direct Access (Scraping, Reverse Engineering).
Et puis, l’illustration de différents parcours utilisateurs et la projection sur les cas d’usage nous ont projeté dans une autre dynamique d’échange, où l’on parlait de :
Expérience client,
Services à valeur ajoutée,
Valorisation de la donnée,
Différenciation et avantage concurrentiel,
Initiatives bilatérales entre banque et TPP,
Modèle économique gagnant-gagnant (la clé du sujet !)…
Le miroir était franchi
Oubliées les postures défensives et la vision strictement réglementaire
Bienvenue dans le monde concurrentiel, avec « les yeux qui brillent » à l’évocation du potentiel de l’initialisation de paiement (combiné à l’Instant Payment) pour offrir les nouveaux services à valeur ajoutée attendus par le marché (et au fondement de la Directive elle-même…).
Au final, c’est bien le consommateur qui validera les meilleures offres !
Il faudra donc encore du courage et de la ténacité pour atteindre la conformité à la DSP2, mais la perspective nous projette déjà plus loin, avec un nouvel élan !
But still, it’s a long way… Un chemin que notre Groupe de Travail au France Payments Forum poursuivra et auquel vous êtes invités à contribuer si vous le souhaitez.
A très bientôt pour un autre événement sur le même thème !
La location de matériel informatique représente un coût non négligeable pour les entreprises, mais ces dépenses ne sont pas toujours maîtrisées, malgré les processus de contrôle interne. En cause, un manque de communication et de rapprochement des suivis. Explications…
La location de matériel informatique coûte plusieurs milliards d’euros aux entreprises françaises chaque année. Suivie par les loueurs, la DSI, la comptabilité, les gestionnaires du parc et des stocks, … tout porte à croire que les coûts de location sont bien maîtrisés. En réalité, ces multiples suivis aboutissent à des résultats très différents, sans que personne dans l’entreprise n’ait vraiment conscience de la réalité.
La première étape du diagnostic, consiste tout d’abord à identifier les processus et les acteurs impliqués dans la gestion du matériel, et notamment du matériel loué.
Un écart potentiel entre les visions de l’Entreprise et la vision du Loueur
Visions de l’Entreprise
En pratique, la responsabilité de la gestion des matériels informatiques est souvent répartie sur plusieurs acteurs qui ont eux-mêmes des objectifs spécifiques.
De fait, la vision du contenu du parc diffère au sein même de la DSI. Les trois sources principales d’information sont : celle de la Gestion de Parc, celle des Equipes IT (réseau et/ou télédistribution), celle de la Finance…
Le service de Gestion de Parc assure un rôle de gestion des biens dans un outil spécialisé, définit des processus de mise à jour mais n’est généralement pas en charge de l’exécution des opérations. La fiabilité de la Gestion de Parc est donc tributaire de nombreux acteurs dont la rigueur conditionne la qualité de la Gestion de Parc.
Les Equipes IT ont une gestion très technique des équipements basée sur des outils et différentes bases qui permettent d’enregistrer les équipements. Les équipes Réseau et de télédistribution savent identifier les équipements connectés et les utilisateurs associés. Les mécanismes techniques d’inventaire et d’identification réseau permettent d’avoir des informations très précises sur les équipements connectés. Cependant, toutes les machines en « attente » : déconnectées, rangées dans des placards, cassées, prêtées ne peuvent être identifiées. De même, ces outils n’adressent pas les périphériques (souris, claviers, écrans, câbles), Bien entendu, les outils de collecte ne font aucune différence entre les machines louées et celles achetées.
Le contrôle de gestion de la DSI suit le coût des machines dans son budget. Il utilise parfois les outils du loueur et dispose de moyens limités pour contrôler la facturation du parc loué..
Au fil du temps, il y a donc distorsion entre les vues de la Gestion de Parc, des Equipes IT, du financier. Résultat : un écart d’au moins 20% entre les différentes visions constatées dans de nombreuses entreprises.
Vision du Loueur
De son côté, le loueur a une vision statique. Il suit tout ce qu’il a loué : les ordinateurs mais aussi les écrans et autres périphériques.
Sa gestion est totalement décorrélée du cycle de vie des équipements : il ne sait pas s’il y a des équipements cassés, des mobiles perdus ou des serveurs obsolètes inutilisés. D’une part, parce que l’ensemble du matériel loué, quel que soit son état, devra être payé jusqu’à la fin de la période de location initiale, d’autre part parce que le loueur n’a quasiment jamais les données nécessaires pour mettre à jour son suivi.
La fin de vie du matériel : trop tard pour constater les écarts de suivi
En fin de contrat, le loueur reçoit la liste du matériel à récupérer.
Ce matériel est préparé par l’Entreprise. Il est collecté tant bien que mal dans les différentes directions ou implantations qui souvent n’ont pas en charge la gestion de leur parc de machines.
Le matériel est récupéré par un transporteur, qui n’assure pas le contrôle. Il est stocké et il peut se passer plusieurs semaines avant que le loueur traite le matériel récupéré.
Ces multiples étapes nécessitent la mise en œuvre précise de processus souvent mal maîtrisés par les acteurs. Ainsi la gestion de parc n’est pas forcément informée des retours ou des matériels manquants.
Le loueur met à jour sa base, donc la vue financière, mais n’informe pas forcément l’équipe de gestion de parc des éventuels écarts.
Pour le loueur, les matériels non restitués continuent forcément à être loués.
Beaucoup d’entreprises continuent donc de payer ne sachant pas où est le matériel. Faute d’information, aucun contrat ne peut être clôturé, et peu d’entreprises utilisent à bon escient la clause de non-restitution.
Les multiples raisons des écarts
Une liste à la Prévert de « petites raisons » explique la dérive entre la réalité terrain et les informations des équipes qui assurent le suivi des matériels loués pendant la durée du contrat.
D’abord, l’informatique sait où sont les machines utilisées mais souvent peu d’analyses permettent de suivre les matériels obsolètes ; les ordinateurs remisés dans un placard, etc… L’urgence faisant loi, le smartphone cassé est remplacé au plus vite, et le vieux mobile est abandonné dans un tiroir.
Certaines machines sont récupérées par les collaborateurs. Il ne s’agit pas forcément de vol, mais d’équipement en double pour le travail à la maison. Même si le manager en est informé, il n’a généralement pas le réflexe de communiquer cette information au service de Gestion de Parc.
De plus, les DRH ou les managers ne savent pas que les postes sont loués et ils laissent parfois partir les collaborateurs avec leur portable ou leur tablette. Or, le matériel n’appartient pas à l’entreprise.
Pour toutes ces petites raisons, les équipements deviennent donc « invisibles » pour le Gestionnaire du Parc mais continuent à être bien réels pour le Loueur qui facture ses loyers.
Les mesures de suivi : d’abord plus de communication
La première chose est d’organiser la communication entre les services au sein de la DSI, mais aussi avec le management, la DRH… Tous doivent savoir que le matériel n’appartient pas à l’entreprise et qu’il ne peut être ni jeté, ni donné, ni vendu…. Le Loueur est le propriétaire
La mise en place d’outil de reporting (type tableau de bord), avec un rapprochement régulier entre les différentes sources d’information permet de déclencher des actions correctrices. A chaque mesure, l’entreprise réduira un peu plus les coûts du matériel informatique et de l’ensemble du parc informatique loué. La fonction de Gestionnaire de Parc est responsable de ce rapprochement. Il est, connu et reconnu, fera le lien entre la vision des utilisateurs, celles des différentes équipes (techniques, logistiques, comptables…) et les informations du loueur et suivra les plans d’actions.
Cependant il est difficile de sensibiliser tous les collaborateurs au fait que le matériel n’appartient pas à l’entreprise mais au loueur.
Il est donc important de prévoir dès la signature des contrats avec le Loueur, un taux de non-restitution pour réduire le coût d’éventuels matériels perdus à la fin de la période de location.
L’intérêt d’un contrat de location dépend entre autres de la capacité de l’Entreprise à gérer le cycle de vie de ses équipements (entrées, sorties, pertes, casses, ..) et du contenu de toutes les dispositions contractuelles associées (taux de non-restitution, type de matériel à restituer..).
Ecovadis confirme notre badge Gold cette année, avec la note de 69/100 qui nous positionne dans les 3% d’entreprises les mieux notées par Ecovadis.
Cette année encore, nous avons poursuivi nos actions sur l’ensemble des thématiques RSE (Environnement, Social, Sociétal, Ethique et Achats responsables), confirmant nos forces :
Mesure outillée de la satisfaction des collaborateurs
Mesure GDPR respectant les données des collaborateurs, clients, fournisseurs, …
Processus de recrutement transparent communiqué de manière claire et formelle aux candidats
Formation visant à développer les compétences
Mise en place de registres “matières” et “énergie”, afin d’identifier les actions pertinentes permettant de poursuivre la réduction de notre empreinte environnementale
Achat de nos ordinateurs, thé, café, cadeaux de fin d’année (miel issu de ruches parrainées par l’entreprise, coffrets gourmand bio, champagne bio, confitures Rebelle etc.), répondant à des critères environnementaux et sociaux
Étude approfondie de la performance sociale et des impacts sociétaux des organisations de travail “libérées” afin de développer davantage la performance globale de nos clients
Réduction drastique de notre utilisation du plastique (gobelets, couverts, …)
…
Confortés par ce résultat, nous nous attelons désormais à la définition du plan 2020 et nous sommes impatients de le partager avec vous.
Souvenez-vous ! Lors du dernier article, nous venions d’obtenir notre certification TOGAF et nous voulions voir comment appliquer ce framework dans la « vraie vie ». Nous avons donc mis en place Les capacités d’architecture (phase Préliminaire et phase A), et maintenant nous allons continuer en suivant la roue ADM (Architecture Development Method).
Nous allons donc parler dans cet article, de la définition des exigences propres à chaque niveau du Système d’Information (la couche métier, la couche applicative et la couche technique) et qui vont impacter le projet. Puis dans le prochain article, nous finirons avec leurs conséquences sur le design des solutions et comment fermer la roue.
La définition des exigences peut changer du tout au tout en fonction du domaine d’activité de votre entreprise / client. Culturellement, le domaine industriel a toujours été plus sensible à la rédaction des exigences que le domaine tertiaire. Vous imaginez bien que pour construire une centrale nucléaire, la liste des exigences est plus importante que pour construire une application de gestion de la solution client (CRM) car en cas de problème, les conséquences sont moins importantes.
Gestion des exigences ou le référentiel des exigences
La gestion des exigences doit permettre de s’assurer du bon suivi des exigences exprimées lors des différentes phases de la roue ADM mais également de s’assurer de leur cohérence. Pour cela, il faut 3 choses :
Un référentiel des exigences pour les stocker
Un processus de mise à jour
Un processus de revue pour la mise en cohérence des exigences.
TOGAF est un framework avec une approche « Test Driven Design ». C’est-à-dire que les exigences du système d’information ont pour but d’être testées. Il est donc primordial de bien les maîtriser de les prioriser, de connaître leur historique, de pouvoir les évaluer et de voir à la fin si le produit fini du projet y répond correctement.
Pour cela, il peut être intéressant d’outiller la gestion des exigences et de créer un référentiel. Si un outil existe déjà, utilisez-le, les plus connus sont IBM rational DOORS, Envision Requirements, JIRA ou autre. Dans le cas contraire un fichier Excel dont la gestion sera sous la responsabilité de l’architecte projet sera bien suffisant. De plus, les exigences seront gardées à la fin du projet et pourront être réutilisées lors du démarrage d’un nouveau cycle de la roue ADM. Il est alors préférable de nommer un responsable de l’administration de ce référentiel.
Maintenant que tout est prêt, nous pouvons continuer de parcourir la roue ADM et commencer à identifier les exigences auxquelles il va falloir répondre.
Phase B : Architecture métier ou comment solliciter son métier à bon escient ?
La phase B de la roue ADM doit permettre de décrire comment votre entreprise (ou le domaine métier impacté par votre projet) doit s’organiser pour atteindre les objectifs. Le travail va donc se concentrer sur la définition de la stratégie, sur la gouvernance, l’organisation métier et les informations clés des processus métier. Et comme lors des précédentes phases, le but est de ne pas surinvestir et de ne consommer que de la charge de travail avec une véritable valeur ajoutée.
La majorité du temps, les équipes d’architectes font partie de la DSI, les relations avec le métier peuvent donc être multiples :
Nous avons directement accès au métier et les impacts sur les processus sont faibles : La disponibilité du métier risque d’être faible car il a ses tâches récurrentes à effectuer (vente, gestion, comptabilité). Dans ce cas, il est nécessaire de lui prendre le moins de temps possible : traduire les enjeux métier, lister les processus et les « pain points ». Seuls quelques ateliers seront nécessaires pour collecter ces informations, il suffit ensuite d’en déduire les exigences métiers.
Nous avons directement accès au métier et les impacts sur le métier sont importants : dans ce cas, le métier doit se rendre disponible pour répondre au besoin. C’est généralement le cas préféré des architectes car cela permet de poser ses questions en toute liberté.
Nous devons passer par une MOA, qui est un intermédiaire avec le métier. L’avantage de cette relation est qu’une MOA est intégrée dans le projet et qu’elle se rendra disponible pour répondre aux besoins du projet. Le problème est que la MOA n’est pas forcément au courant des enjeux du métier, selon l’organisation mise en place entre la DSI et le métier.
Une fois que les exigences métiers sont identifiées et le référentiel mis à jour, nous pouvons passer aux exigences liées au système d’information.
Phase C : L’architecture du système informatique car même l’IT a ses propres exigences…
Les exigences du système d’informations se découpent en 2 catégories. Celles qui s’appliquent à l’intégralité du système d’information et celles qui s’appliquent au projet.
Les exigences qui s’appliquent à tout le SI sont souvent les plus faciles à appréhender pour les architectes : ce sont les exigences d’architecture que nous connaissons tous comme :
Un identifiant doit être unique et non interprétable.
Une fonction ne peut pas être implémentée plusieurs fois dans le SI…
La séparation des fonctions de production et de distribution,
Celles liées aux échanges (API, couche d’échange…),
Sur les sources de données (le terme de « Golden Source » est souvent utilisé),
Ou les réglementations comme sur la protection des données (Règlement Général sur la Protection des Données, ….).
Puis viennent toutes les exigences spécifiques au projet en lui-même comme celles liées à la confidentialité, l’intégrité, la disponibilité ou l’authentification / identification. La mise à niveau des exigences précédemment édictées par le métier est souvent négligée. Quand cette mise à niveau n’est pas faite (peu importe le formalisme), cela révèle souvent un manque de dialogue entre les équipes projet métier et IT. Cet effort est nécessaire car une partie de la valeur de l’architecte est justement de créer un pont entre ces deux mondes.
Phase D : Architecture technique
Dans les DSI importantes, des architectes dédiés ont généralement la charge de la partie technique. En effet, un architecte ne peut pas avoir le même niveau d’expertise sur toutes les couches du système d’information et la frontière se trouve historiquement à ce niveau. Dans les DSI plus petites, la césure entre les architectes techniques et les architectes fonctionnels est moins importante mais elle existe souvent malgré tout.
L’architecte technique doit avoir une bonne connaissance du catalogue des normes et standards de l’entreprise. Savoir quels sont les composants (technologies, logiciels…) à utiliser, où en est leur cycle de vie et les mettre en regard du projet. L’architecte se confronte également à la stratégie de la DSI et à sa politique fournisseurs notamment (quand elle existe).
Dans le cas de solutions hébergées en interne, l’architecte technique doit définir les exigences techniques qui permettent de dimensionner correctement l’infrastructure. Dans le cas de solutions Cloud ou d’application en SAAS, les exigences liées aux infrastructures n’ont plus de raison d’être, elles doivent être définies en termes de SLA (plus besoin de calculer le nombre de serveurs, car l’hébergeur est garant du dimensionnement). Dans ce dernier cas, s’occuper des interfaces est plus que nécessaire.
A la fin de cette phase, le référentiel d’architecture doit s’enrichir en précisant les composants à utiliser pour atteindre la cible désirée et la feuille de route provisoire avec les recommandations de mises en œuvre.
Conclusion
A ce niveau d’avancement, nous avons pu collecter et finaliser l’ensemble des exigences du projet. Nous avons également une vue assez claire d’où nous partons et où nous voulons aller, sauf que nous sommes encore dans un monde « sans contrainte ». Nous savons ce que nous voulons (ou ne voulons pas) mais il faut à présent se confronter au monde réel, fait de contraintes de planning, de budget, de disponibilités des ressources et donc sortir de cette tour d’ivoire où se sont parfois enfermés d’autres architectes avant vous. Les négociations et les arbitrages commencent et la valeur tangible apportées aux projets se mesure ici, comme nous le verrons dans le troisième et dernier article de cette série sur TOGAF In Real Life.
L’erreur la plus commune, quand on entreprend une démarche micro services, est de vouloir découper en micro-services !
Le concept de micro services existe désormais depuis une dizaine d’années. Netflix étant la première « grande entreprise » (si on pouvait la nommer ainsi à l’époque) à adopter une telle orientation.
Avec le recul, le plus gros problème des micro services repose sur le fait de les avoir appelés « micro ». En lisant sur Wikipedia, on retrouve sous le chapitre « Philosophie », la phrase suivante : « Les services sont petits, et conçus pour remplir une seule fonction ».
Rien de plus incorrect si on veut bien entamer une démarche micro services… Tout comme parler de nano services et macro services, pour analyser des mauvaises pratiques, comme font certains acteurs. Ce n’est pas une question de taille !
Les efforts doivent principalement se focaliser sur trois axes fondamentaux dans la réflexion sur le découpage :
SIMPLICITÉ : un micro-service doit être spécialisé. Il ne doit pas avoir une couverture fonctionnelle complexe, il doit effectuer un ensemble d’actions simples et ciblées. Ceci étant dit, nous ne devons pas non plus réduire un microservice à une simple fonction, dans l’objectif de “faire petit” : un microservice doit couvrir un ensemble fonctionnel cohérent.
ISOLATION : un microservice doit être isolé des autres. Le dysfonctionnement d’un microservice ne doit pas impacter les autres afin d’éviter l’effet domino.
INDÉPENDANCE : un microservice garantit son indépendance, il englobe tout ce qui lui est nécessaire pour son fonctionnement. Dans la décennie de la containérisation, tout a été mis en œuvre pour que le concept d’indépendance, associé aux microservices, devienne simple et intuitif. Un container de par sa nature est facilement associable à un microservice
A partir de ces considérations, quelle est la meilleure approche pour définir le périmètre de ses micro services ?
Partons du besoin primaire d’un SI : Traiter de la donnée ! Conjuguons ce besoin à une autre caractéristique des micro services : un micro service interagit avec une donnée qui lui est propre. Une solution simple se propose : réalisons un découpage par la donnée ! Le premier pas pour dessiner un découpage des microservices est de définir la structure de la donnée.
Prenons un exemple très simple : le triptyque CLIENT, PRODUIT et ORDRE.
Dans la logique que je viens d’expliquer, nous pouvons construire un Microservice sur chaque entité métier :
Ce qui permet à une application frontale de combiner les trois pour, par exemple, permettre à un site d’eCommerce, de :
passer un ordre
après avoir consulté la liste des produits
et avoir géré l’inscription d’un client
Cette démarche n’est certainement pas exhaustive. Chaque cas de figure nécessite une analyse à part entière, mais à notre sens c’est un bon point de départ pour une réflexion micro service.
Pour résumer, une bonne pratique de découpage en micro services est initiée par le découpage de la donnée, en entités métier.
Voici une vidéo créée par nos soins pour illustrer ces explications : ici
Conclusion
Essayer de faire « petit » n’est pas forcément le sujet sur lequel focaliser ses efforts… L’indépendance et l’isolation sont les clés d’une bonne démarche micro-services. Si un doute surgit, le mieux est de ne pas découper tant que les autres principes sont respectés.
Qui n’a jamais tremblé lorsque le post-it “Définir le Target Operating Model (TOM)”, alias Gouvernance, lui a été attribué ?
Il s’agit là d’une activité complexe mais pourtant au combien nécessaire pour l’efficacité et la pérennité d’une offre ou d’un service.
La Gouvernance IoT n’échappe pas à ce constat général, la difficulté en est même démultipliée :
l’IoT s’applique à une diversité de Métiers ayant chacun leurs particularités,
la chaîne IoT nécessaire à un cas d’usage métier est constituée de nombreux maillons technologiques (cf. notre article IoT Un Marché en pleine ébullition) répartis sur un large spectre de compétences.
Quelle part de responsabilité attribuer aux Métiers / à l’IT ? Comment définir une structure commune transverse à l’échelle de l’Entreprise ? Comment fédérer les initiatives locales pour les encadrer et démultiplier les bénéfices ? Quel RACI peut être mis en place ?
IoT, flagrant délit de franchissement de ligne, de l’Information Technology (IT) vers les Operational Technology (Métier)
Comme nous l’avons évoqué dans notre précédent article, les technologies IoT s’immiscent sur des cas d’usages purement métier assurés jusque là par des Operational Technology.
Les Métiers étaient et sont toujours les sachants sur :
Le contexte et les finalités du cas d’application,
Les contraintes environnementales applicables (vibration, climatique, form factor, interférence, …),
Les données pertinentes à récolter, et leurs fréquences,
Les traitements métiers à appliquer sur les données pour obtenir les informations nécessaires au cas d’usage ciblé.
L’IT apporte son expertise sur les différentes couches technologiques :
Les infrastructures à mettre en oeuvre,
Les objets connectés (ou composant) à utiliser,
Les plateformes qu’elles soient on-premise ou en mode PaaS / SaaS,
La connectivité (les protocoles réseaux adéquats…),
Les best practices et pattern d’intégration pour véhiculer, stocker et partager l’information,
La sécurité sur l’ensemble de la chaîne.
De facto, nous identifions rapidement les risques à adopter une Gouvernance portée de façon unilatérale par :
Le Métier : solution non pérenne technologiquement ou ne répondant pas aux standards de l’entreprise, solution propriétaire “vendor lock-in”, solution sous-dimensionnée, …
L’IT : une couverture fonctionnelle non adaptée aux besoins réels (trou dans la raquette VS Rolls-Royce), une solution trop rigide et peu évolutive au regard des transformations du métier, …
Il y a donc une vraie dualité Métier / IT à mettre en oeuvre au niveau de la Gouvernance.
Une Gouvernance mixte, N approches
Personne aujourd’hui ne saura en mesure de vous conseiller de procéder comme-ceci ou comme celà sans avoir sondé votre existant :
Quelle est le degré d’autonomie des entités opérationnelles ?
Les métiers disposent-ils de ressources IT propres ?
Est-ce que les directives IT sont centralisées ?
Les cas d’usages IoT sont-ils déjà bien ancrés en transverse dans l’entreprise ou bien largement isolés ? Est-ce qu’une équipe dispose d’une vision globale sur toutes les initiatives / tous les projets ?
Est-ce qu’il y a déjà des affinités à positionner telle entité sur le BUILD ou le RUN de tel ou tels maillons d’une chaîne IoT ?
Est-ce que quelqu’un dispose de la vision bout en bout entre le cas d’usage et les moyens IT à mettre en oeuvre pour le traiter ?
Comment renseigneriez-vous les quelques éléments ci-dessous ?
Néanmoins quelques modèles de gouvernance IoT émergent. Ci-dessous une illustration non-exhaustive :
Filière 1 : Miser sur un socle IoT transverse à l’entreprise
Le Groupe est un enabler pour les métiers :
Le Digital est en charge de la définition de la stratégie IoT Groupe,
Le département IT, est responsable de la mise en oeuvre des socles / plateformes IoT (horizontales), d’accompagner et de supporter les métiers dans leurs projets.
Les Métiers sont responsables de leurs projets IoT positionnés en verticaux.
Filière 2 : Miser sur l’agilité d’une Feature Team pour délivrer des solutions sur mesure
Les Métiers sont à l’origine des projets IoT,
Le département IT dédie des ressources à l’IoT dans ses différentes équipes (infrastructure, plateforme, réseaux, développement…). Ces ressources s’organisent généralement en Features Teams pour accompagner les projets métiers IoT avec le maximum de réactivité.
Et vous, vers quel modèle vous projetez-vous ?
Les victoires collectives sont les plus belles
La définition d’une Gouvernance est toujours complexe.
L’instruction d’un sujet IoT de bout en bout n’est pas une mince affaire. Cela requiert énormément de compétences technologiques (électronique, hardware, software, en passant par les télécoms…), tout en devant constamment s’assurer de l’adéquation avec la réalité terrain (contraintes mécaniques, etc.).
De là à dire que définir une Gouvernance IoT est impossible, il n’y a qu’un pas.
Métier et IT doivent travailler main dans la main, le fossé les séparant devant être définitivement comblé.
Adopter une démarche d’Open Innovation (ateliers d’idéation, fablabs, pizza teams…) permettra de casser les silos, de cadrer et d’affiner le “Qui fait Quoi ?” dans cet écosystème en constante évolution.
#Teasing : dans un prochain article nous vous parlerons des différentes stratégies, des positionnements possibles pour mettre sur le marché une Offre IoT.
