Identifier des composants de solution

Effectué

Au cours du processus de détection, certaines idées de solutions doivent commencer à devenir claires. Cette unité explique comment identifier les composants de solution qui pourraient constituer la solution proposée pour le client. Comme il s’agit toujours de la phase de prévente du projet, votre objectif est d’illustrer pour le client à quoi ressemblera la solution proposée après sa création, puis d’expliquer comment la solution atteindra ses objectifs. C’est aussi le bon moment pour commencer à réfléchir à une feuille de route produit et à la façon dont les composants seront implémentés pour offrir une valeur rapide pendant les itérations.

Mapper les besoins à la fonctionnalité

Vous devriez avoir saisi les besoins clés du client pendant vos réunions. Pour identifier les composants, vous devez réfléchir à ces besoins de manière globale et les faire correspondre aux applications Dynamics 365 existantes, à une application Microsoft Power Platform personnalisée ou, dans certains cas, au développement personnalisé. Pour les projets plus vastes, vous devrez peut-être mapper vers plusieurs applications ou les trois catégories.

Tous les projets ne démarrent pas depuis le début ; beaucoup ont des systèmes existants en place et améliorent ou s’intègrent simplement à ce qui existe déjà. Par exemple, un client peut disposer de Dynamics 365 Customer Service et ajouter des fonctionnalités d’Omnicanal pour répondre à un besoin spécifié.

Certains besoins peuvent se mapper à plusieurs applications. Vous constaterez peut-être que l’aspect des ventes se mappe à Dynamics 365 Sales, le suivi des commissions et le paiement étant des améliorations de leur application Dynamics 365 Finance existante.

Soyez prudent lorsque vous mappez ou proposez que le client remplace ou ajoute une autre application qui duplique quelque chose dont il dispose déjà. Vous pourriez aider le client pour cette raison, ce qui est acceptable. Cependant, si le client dispose déjà d’un ERP non Microsoft et que vous lui avez proposé d’ajouter Dynamics 365 Finance, car cela facilite le déploiement de votre solution, votre proposition ne sera pas bien reçue.

Pour les composants clés de la solution, nous vous recommandons de mettre en surbrillance les scénarios où les fonctionnalités prêtes à l’emploi seront utilisées et où des aspects personnalisés sont requis. Par exemple, vous devez mettre en surbrillance si vous utilisiez des fonctionnalités de vente standard pour tout sauf un configurateur de produit. Ensuite, pour le configurateur de produit, vous devriez mettre en surbrillance la solution proposée, par exemple, avoir une Power App personnalisée intégrée à l’application, voire offrir une solution de configurateur tiers.

Expliquer des idées complexes à l’aide de l’imagerie

Vous pouvez créer un diagramme/une image d’une seule page qui décrit la solution d’une manière plus facile à comprendre. Incluez les différentes personnes qui interagissent avec le système afin de montrer clairement comment la solution sera utilisée par différentes personnes. Évitez d’ajouter trop de détails, ce qui peut rendre votre diagramme/image difficile à comprendre et pourrait compliquer vos idées de manière excessive. Si vous gardez votre illustration concise et soignée, elle deviendra le point de référence pour les discussions futures et vous distinguera de la concurrence. Lorsque davantage de détails sont nécessaires, vous pouvez créer des diagrammes associés axés sur certains domaines.

Image d’un exemple assez complexe de diagramme de solution.

Modélisation des données

La modélisation formelle des données intervient dans le cadre de la conception de la solution et généralement après la conclusion d’un contrat. Cependant, pendant la phase de prévente, une conceptualisation de modélisation de données globale est effectuée en permanence pour identifier les gros volumes de données et leur emplacement. Si une preuve de concept est créée, cet effort est souvent utilisé pour prototyper ce qui est présenté au client. Ces informations sur le modèle de données sont également transférées dans le processus de conception pour relancer le processus de réflexion sur la modélisation des données. Pensez à partager un modèle de données résumé et détaillé. Le modèle détaillé sera utilisé par ceux qui conçoivent et créent le système. Le modèle de résumé est partagé avec les parties prenantes devant comprendre la solution, mais ne nécessitant pas de détails spécifiques.

Modélisation du processus

Lors de la détection, vous devriez également avoir pris connaissance des processus clés du client. Lorsque vous proposez une solution, il est essentiel de pouvoir expliquer comment votre solution proposée accomplit ses processus métier clés.

Dans certains cas, votre processus proposé peut être similaire au processus client existant ; cependant, le plus souvent, il est différent. Au fur et à mesure que vous identifiez les composants de la solution, il est important de mettre en surbrillance les principales différences et de comprendre comment les changements de processus proposés permettent d’atteindre les objectifs identifiés, tels que la résolution des cas 20 % plus rapidement tout en tenant les clients plus informés.

Expérience utilisateur

Les clients se concentreront toujours sur l’expérience utilisateur. Lors de la détection, vous devez avoir saisi des détails, tels que si les utilisateurs sont toujours mobiles, parfois mobiles, jamais mobiles, ou d’autres besoins d’expérience utilisateur uniques. Lorsque vous identifiez les composants de la solution proposée, le mappage de ces besoins est important. Au besoin, ces composants doivent être démontrés avec une preuve de concept ou une maquette illustrant la solution que vous proposez.

Les maquettes conceptuelles peuvent inclure les éléments suivants :

  • Formulaires principaux

  • Tableaux de bord

  • Expérience mobile

  • Visualisations (par exemple, Power BI)

L’image suivante illustre un exemple de maquette conceptuelle et la forme réelle que vous obtenez à partir de celle-ci.

Exemple de maquette d’un formulaire avec des espaces réservés pour le texte et des regroupements de contrôles.

Exemple de formulaire réel que vous créeriez à partir de la maquette.

Intégrations

La plupart des solutions n’existent pas isolément et reposent sur des intégrations internes ou externes. Dans le cadre de l’identification des composants de la solution, vous devriez pouvoir mettre en surbrillance la façon dont ces intégrations seront traitées. Ce processus peut inclure la définition des outils ou services permettant de terminer les intégrations. Dans une solution à plusieurs systèmes, vous devez définir des limites claires là où un système se termine et un autre commence. Ces limites deviennent des « contrats » entre les responsables de leur création et de leur tenue à jour. Concentrez-vous sur ce qui se passe sur ces limites et essayez de définir clairement à qui revient la responsabilité de créer des interfaces et qui les consommeront. Cette clarification est particulièrement importante lorsque des fournisseurs tiers ou des équipes de développement internes sont impliqués.

Options de déploiement

Microsoft propose un modèle par abonnement de Microsoft Dynamics 365. Avec cette option, vous pouvez accéder à Dynamics 365 depuis le cloud, sans avoir à investir davantage dans les licences matérielles et logicielles de votre réseau informatique. Aucun déploiement local de l’application n’est nécessaire et vos utilisateurs peuvent accéder à Dynamics 365 à partir de plusieurs navigateurs. Cet accès peut être critique pour le personnel distant ou hors site qui a besoin d’un accès facile.

Cependant, Dynamics 365 Finance et Dynamics 365 Supply Chain Management (anciennement appelés Dynamics 365 Finance and Operations) peuvent également être déployés localement. Autrement dit, une organisation peut déployer les applications localement.

Pour les applications Dynamics 365 suivantes, vous devez utiliser Lifecycle Services pour le déploiement :

  • Dynamics 365 Finance

  • Dynamics 365 Supply Chain Management

  • Dynamics 365 Commerce

Pour les autres applications métier Dynamics 365 telles que celles de la liste suivante, vos principaux déploiements sont en ligne à l’aide d’un ensemble d’environnements de développement-test-production standard :

  • Dynamics 365 Sales

  • Dynamics 365 Customer Service

  • Dynamics 365 Customer Insights - Journeys

  • Dynamics 365 Field Service

Vous pouvez également créer un environnement de test et lui faire réaliser une exécution de test, ce qui vous permet de faire fonctionner votre système en quelques jours plutôt qu’en quelques semaines ou mois. Vous n’avez plus à vous soucier de la maintenance continue du serveur ou des frais de licence. De plus, vous pouvez acheter vos licences utilisateur directement en ligne sans passer par un fournisseur, et vous pouvez ajouter plus d’utilisateurs en ligne selon vos besoins et à mesure que votre entreprise se développe.

Les applications de gestion Dynamics 365 offrent plusieurs types d’environnements. Le type d’environnement indique le but et détermine les caractéristiques de l’environnement :

  • Version d’évaluation : les environnements d’évaluation sont destinés à répondre aux besoins de test à court terme et sont automatiquement effacés après une courte période.

  • Bac à sable : il s’agit d’environnements hors production et lorsqu’ils sont associés à une instance de base de données Microsoft Dataverse, ils offrent des fonctionnalités telles que la réinitialisation.

  • Production : utilisé pour un travail permanent dans une organisation. Il peut être créé et détenu par un administrateur ou toute personne disposant d’une licence Power Apps.

  • Par défaut : environnement de production non personnalisé. Chaque abonné dispose d’un environnement par défaut créé automatiquement.

  • Développement : les environnements de développement sont créés par les utilisateurs avec la licence Offre Communauté. Ils sont réservés à l’usage exclusif du propriétaire. Le partage avec d’autres utilisateurs n’est pas possible dans ces environnements.

Microsoft Dynamics Lifecycle Services

Microsoft Dynamics Lifecycle Services vous aide à gérer le cycle de vie des applications de vos implémentations de Microsoft Dynamics 365 Finance et Microsoft Dynamics 365 Supply Chain Management. Lifecycle Services est un portail de collaboration basé sur Microsoft Azure qui fournit un environnement et un ensemble de services régulièrement mis à jour. Ce portail fournit un espace de travail collaboratif permettant aux clients et à leurs partenaires de gérer les projets Finance et Supply Chain Management. Lifecycle Services vous accompagne de la prévente à la phase d’implémentation et enfin à l’environnement de production dans le cloud ou localement. Grâce à des listes de contrôle et des outils, Lifecycle Services vous permet de gérer le projet, y compris en fournissant des méthodologies prédéfinies contribuant à l’implémentation.

Lifecycle Services prend en charge une plus grande prévisibilité, davantage de collaboration et une meilleure procédure structurelle pour l’administration de la gestion des applications. L’objectif de Lifecycle Services consiste à s’orienter vers des implémentations prévisibles, reproductibles et de qualité supérieure en simplifiant et en standardisant le processus d’implémentation.

Étapes suivantes

L’identification des composants clés de la solution vous aidera à déterminer vos prochaines étapes. Par exemple, vous pouvez déterminer vos prochaines étapes selon que vous avez des solutions prêtes pour une démonstration que vous devez adapter au client ou que vous générez une preuve de concept/prototype.

Le but de ce processus n’est pas de créer une conception détaillée de la solution complète. N’oubliez pas qu’il s’agit toujours de préventes ; vous souhaitez pouvoir raconter comment votre proposition répond aux besoins de votre client et a suffisamment identifié la solution. La mise en place de ces informations vous aide à déterminer la tarification à utiliser afin que vous puissiez aboutir à un contrat signé, puis procéder à la création de la solution.

Exercice : identifier les utilisations courantes parmi les équipes de banque Woodgrove

Passez en revue le profil client de banque Woodgrove, en particulier les équipes orientées client qui ont été décrites. Identifiez les thèmes communs dans les équipes. Déterminez si des équipes se chevauchent dans les fonctionnalités nécessaires. Évaluez si une équipe individuelle est si différente des autres qu’elle mérite une solution distincte.