Numérisation du groupe d’applications métier

Pour numériser de manière holistique une grande organisation comme la Digital Transformation Platform (DTP) de Microsoft, nous devons automatiser les quatre aspects du numérique Boucle de rétroaction.

• Transformer les produits pour améliorer nos offres, par exemple en publiant des notes de version sur les prochains livrables vague de lancement.
• Interagir avec les clients et les partenaires pour stimuler la croissance de l’entreprise, par exemple en engageant les clients et en recueillant les commentaires et les Idées des clients.
• Donner à nos propres collaborateurs les moyens d’améliorer les performances de notre organisation.
• Optimiser les opérations commerciales pour obtenir une meilleure efficacité, par exemple en automatisant les évaluations commerciales.

Voici un exemple d’applications développées sur le Centre de réussite ; faire de la boucle de rétroaction numérique une réalité dans notre organisation.

Flux de travail et personas

Pour numériser les quatre aspects de la boucle de rétroaction, nous divisons nos applications en différents flux de travail. Chaque flux de travail est axé sur un personnage spécifique, comme le montre l’image suivante.

L’image suivante montre comment 35 applications sont modélisées dans ces cinq flux de travail.

Cinq flux de travail répertoriés, chacun avec des applications métier. Liste des plateformes et principes fondamentaux – Qualité des données, schéma, convivialité, etc. Liste Livesite et Ops – Surveillance et télémétrie, Support, Déploiement et test, Mises à niveau de maintenance.

Les applications ajoutent des données dans Microsoft Dataverse, en utilisant les données partagées par d’autres applications pour améliorer l’expérience de l’application grâce à l’automatisation et à l’intelligence. Les données peuvent également être utilisées pour fournir des scénarios de réduction des coûts sur la façon dont les données sont utilisées par diverses applications.

Scénario de développement de produit

1. Microsoft s’engage et interagit avec le client. Il existe de nombreuses applications dans le flux de travail Clients et partenaires, par exemple, l’engagement client, l’engagement des dirigeants, les applications FastTrack et Power CAT. Chacun d’eux est axé sur un personnage spécifique.
2. Microsoft recueille les commentaires des clients. Il existe de nombreuses applications dans les flux de travail Clients et partenaires et Communauté, par exemple, Ideas, Pulse et Heartbeat (pour FastTrack).
3. Regroupez et hiérarchisez les commentaires et les demandes en utilisant l’application de commentaires Fusion/One dans le flux de travail ProductOps.
4. Implémentez les commentaires et les demandes sur les fonctionnalités en utilisant des applications de planification de produits dans le flux de travail ProductOps.
5. Annoncez le plan aux clients en utilisant l’application de plan de version dans les revues exécutives du flux de travail ProductOps. Ceci est automatisé à l’aide du portail de base, qui fait partie du flux de travail BusinessOps.

Scénario de capacité de prise en charge

1. Un client crée une demande de support. Cela se fait avec la partie D4M du flux de travail DevOps.
2. Un ingénieur examine le cas pour prévenir de futurs cas. Cela se fait avec l’application d’évaluation des incidents, qui fait partie du flux de travail DevOps.
3. L’équipe produit planifie le travail à effectuer. Cela se fait avec l’application de planification de produit dans le flux de travail Product Ops.
4. Fermez la boucle avec les clients confrontés au problème en utilisant des applications dans le flux de travail Clients et partenaires.
5. Fermez la boucle avec les clients ayant envoyé le commentaire en utilisant des applications dans le flux de travail Clients et partenaires.

Modèle de co-développement Centre de réussite

L’enjeu du modèle de co-développement est de permettre à chacun de co-développer, à grande échelle, et de ne pas perturber les autres applications. Pour rendre cela évolutif, nous divisons le problème par flux de travail. Pour chacun des cinq flux de travail axés sur le développement d’applications, nous nommons des responsables de flux de travail. Leur travail consiste à s’assurer que toutes les applications de ce flux de travail respectent le processus de gouvernance et, en outre, obtiennent le bon support de la part de l’équipe Centre de réussite.

Chaque fois que des modifications majeures sont demandées pour une application, celle-ci doit suivre les cinq étapes suivantes pour entrer en production.

1. Alignement de l’Étendue : examinez l’expérience utilisateur de haut niveau et les modifications apportées au schéma.
2. Mettre à jour Microsoft Azure DevOps : ajoutez des fonctionnalités et des récits utilisateur, et mettez-les à jour avec les modifications de schéma.
3. Approbation du partenaire : courrier d’approbation envoyé aux parties prenantes concernées.
4. Approbation du prospect du flux de travail : approbation des modifications par les responsables du flux de travail.
5. Changements déployés : PR examine et vérifie les changements de schéma et les éléments de travail.

Parce que nous avons environ 35 applications fonctionnant sur la plateforme, il n’est pas évolutif pour nous d’examiner tous les changements. Quelques changements, par exemple, ajouter une icône pour un tableau personnalisé ou modifier le tri dans une vue personnalisée pour une table personnalisée, peut n’affecter aucune autre application, et celles-ci sont marquées comme de petite étendue ; il est facultatif pour les équipes de l’application de les examiner avec l’équipe Centre de réussite. Notre objectif principal est d’évaluer tout changement associé aux tables.

Nous souhaitons savoir quand les équipes effectuent les types de changements suivants autour des tables :

• Création d’une nouvelle table : Souvent, les équipes d’application souhaitent créer leur propre table et travailler de manière indépendante avec les données. Mais si nous laissons cela se produire, plusieurs tables peuvent être créées pour le même travail, ce qui prête à confusion. Le rapprochement de ces tables prend beaucoup de temps et d’efforts, par rapport à demander aux équipes d’application d’adopter des tables déjà disponibles ou de modifier les tables actuelles pour répondre à leurs besoins et ceux de toutes les équipes d’applications.

• Modifications apportées à une table partagée : Elles sont de deux types :

  • Modification du schéma : cela nécessite alignement sur les applications qui utilisent déjà la table.
  • Modification des données (par exemple, la taxonomie) : Étant donné que les applications partagent les données de la table, il est nécessaire qu’une seule équipe gère ces données ou au moins crée des règles de gouvernance pour celles-ci.

Déploiement et site en direct

Centre de réussite suit un cycle de déploiement hebdomadaire où les composants Microsoft Dataverse sont examinés lors d’une réunion avec les partenaires et ensuite déployés dans un environnement de test tous les mercredis. Les équipes partenaires ont deux jours pour valider leurs applications et les modifications apportées aux solutions dans l’environnement de test. Après validation, nous obtenons l’approbation des équipes partenaires et déployons ces composants dans un environnement de production le lundi suivant.

Microsoft Power Platform nous permet également d’automatiser notre processus d’assistance, où les e-mails envoyés à l’alias de support sont suivis dans un système de tickets. Ces éléments sont examinés chaque semaine dans le cadre d’un examen du site en direct pour comprendre la santé du Centre de réussite et identifier les éléments de réparation et les tendances des requêtes des utilisateurs.

Pour surveiller la santé des composants, nous utilisons les éléments suivants :

• Un modèle de gestion du cycle de vie des applications (ALM), qui comprend les éléments suivants :
  • Environnement de développement (par application)
  • Environnement de test (environnement unique)
  • Environnement de test d’acceptation utilisateur (UAT) (environnement unique)
  • Environnement de production (environnement unique)
  • Environnement de validation de principe permettant aux équipes d’essayer leurs applications
• Les pipelines de build et de release sont gérés via Azure DevOps en utilisant Power Platform Build Tools.
• Les environnements de développement et de test sont actualisés chaque semaine de manière automatisée grâce à des builds hebdomadaires.
• Les tests automatisés sont exécutés dans des environnements de test et des environnements UAT. Cela permet d’assurer un co-développement plus fluide.
• Chaque application est une solution et est en passe de devenir un solution gérée.

Intégration de conformité et de sécurité

Une fois l’intégration de la sécurité et de la conformité terminée, il peut être utilisé par n’importe quelle application en développement. Cette intégration présente les caractéristiques suivantes :

• Un volume élevé de données en lecture seule : dans certains cas dans Centre de réussite, nous n’avons besoin de données qu’à des fins de référence, par exemple, les mesures quotidiennes, mensuelles et hebdomadaires des utilisateurs actifs pour un locataire. Ces données sont utilisées pour comprendre l’utilisation, mais jamais modifiées dans Centre de réussite. Nous utilisons des tables virtuelles pour restituer ces données, qui sont souvent volumineuses et en lecture seule.
• Un volume élevé de données en lecture-écriture : tandis que les flux Power Automate répondent à la plupart de nos besoins d’intégration, des fonctionnalités Azure avancées sont nécessaires dans certains scénarios, par exemple l’appel d’Azure Functions. Pour ceux-ci, nous utilisons Azure Logic Apps.
• Intégration simple : les flux sont largement utilisés pour créer des intégrations en plus de la logique métier dans notre organisation.
• Des rôles spécifiques sont créés pour honorer la sécurité.
• Nous organisons régulièrement des examens de conformité au niveau du Centre de réussite, car le Centre de réussite stocke de nombreuses informations sensibles.
• Les équipes d’application n’ont pas besoin d’effectuer des examens de conformité si elles utilisent des tables de données et des intégrations existantes.

Intégration à d’autres sources de données

Pour les applications professionnelles, nous avons souvent besoin de données provenant de diverses sources de données. Microsoft Dataverse fournit un excellent moyen d’intégrer d’autres sources de données en utilisant des tables virtuelles. Nous intégrons les types de sources de données suivants :

• Microsoft données sur les clients, les ventes et les partenaires (par exemple, Microsoft Expérience de vente, Services de cycle de vie, service clientèle)
• DevOps et facilité de maintenance (Azure DevOps et Gestion des incidents IcM, par exemple)
• Hiérarchie de l’organisation et profils d’utilisateurs (Microsoft Entra et Microsoft graphique)

Canaux de support et maintenance

Les canaux suivants permettent à n’importe quelle application d’être développée, prise en charge et maintenue :

• Wiki, conseils et heures de bureau hebdomadaires pour poser des questions
• Maintenance (alerte et surveillance) réalisée par une seule équipe (flux de travail Microsoft Power Platform)
• Tableau de bord de télémétrie pour suivre les mesures de performance et de santé