Dynamics Nav

Le meilleur ERP


La solution idéale

pour votre entreprise


Le meilleur choix

pour votre réussite


Dans Microsoft Dynamics Sure Step, chaque phase comprend des activités, la plupart des activités sont constituées de tâches, elles-mêmes parfois constituées de tâches subordonnées. Lorsque les utilisateurs effectuent ces activités et ces tâches, ils obtiennent, en fin de phase, un ensemble de livrables documentés fournissant les informations requises pour mener à bien les phases ultérieures.

Dans Sure Step, chaque phase commence par l’activité de planification qui lui est propre. Cette activité est constituée des tâches et des livrables nécessaires pour planifier le travail à effectuer au cours de la phase en question. Les tâches de planification comprennent :

  • Consultation des livrables provenant de la phase précédente
  • Détermination des ressources
  • Planification des activités de la phase
  • Désignation des responsables de l’approbation pour les décisions prises pendant la phase

Microsoft Dynamics Sure Step se compose de six phases principales qui définissent la structure d’un projet d’implémentation :

1.  Phase de diagnostic :

Le diagnostic constitue une phase de pré-implémentation, l’objectif de la phase de diagnostic est de collecter suffisamment d’informations afin de définir le périmètre général du projet et présenter au client une proposition ferme pour les phases suivantes du projet d’implémentation. Généralement, les activités de la phase de diagnostic permettent de gagner la confiance du client en ce qui concerne la validité de la solution proposée avant le lancement de l’implémentation.

 

Processus de diagnostic

Processus de diagnostic

 

Pendant les activités de diagnostic générales, l’équipe projet peut déterminer si une analyse détaillée des processus métiers est nécessaire, ou bien qu’une preuve de concept pour la solution ou qu’une évaluation de l’infrastructure du client est souhaitable. Dans de tels cas, la phase de diagnostic Sure Step prévoit des offres d’accélérateur de décision pour aider le client lors du processus à positionner et à sélectionner le produit le plus apte à répondre à ses besoins.

Si les activités d’analyse détaillée ne sont pas effectuées pendant la phase de diagnostic, elles doivent généralement être menées à bien pendant la phase d’analyse.

Il est également indispensable à ce stade de créer un plan de projet préliminaire et une estimation budgétaire qui servira de guide pour la suite du projet d’implémentation.

En fonction des résultats de la phase de diagnostic et de l’acceptation ou du refus de la proposition de projet par le client, les étapes suivantes consisteront, éventuellement, à passer directement à un projet d’implémentation. En cas de rejet de la proposition par le client, On peut soit réévaluer la proposition, soit clôturer le projet.

La phase de diagnostic comprend les activités suivantes :

  • Préparation du diagnostic
  • Offres d’accélérateur de décision
  • Génération de la proposition
  • Contrat de services et de licence final
  • Mobilisation du projet

1.1  Préparation du diagnostic :

Cette activité consiste essentiellement à recueillir les informations qui permettront de définir les qualifications requises pour le projet et d’identifier les ressources adaptées ou les manques de qualification. Une fois que le client a accepté la proposition d’implémentation, On se base  sur les informations recueillies pour choisir les membres de l’équipe projet et les former aux besoins du projet. Cette activité comprend les tâches suivantes :

  • Passer en revue la demande d’information, la demande de proposition ou la demande de devis
  • Passer en revue les besoins supplémentaires identifiés lors des réunions et discussions avec le client (Compréhension de la situation et des besoins du client)
  • Identifier les besoins en informations supplémentaires
  • Rassembler et/ou synthétiser la documentation pertinente
  • Définir les compétences nécessaires et identifier les ressources appropriées (Affectation et préparation de l’équipe projet)

1.2  Offres d’accélérateur de décision facultatives :

La phase de diagnostic comprend des ensembles définis de services appelés Accélérateurs de décision. Ces services incluent un processus de vérification préalable pour déterminer la bonne décision à prendre pour répondre aux besoins métiers et adapter ces besoins à une solution Microsoft Dynamics.
Microsoft Dynamics Sure Step fournit sept offres d’accélérateur de décision :

a). Examen des besoins et des processus :

L’objectif de cet accélérateur est d’identifier les processus métiers au sein du périmètre du projet. Les résultats de cette analyse permettent de choisir une solution qui prendra en charge les besoins métiers et les processus du client. Il comprend les tâches suivantes :

  1. Lancement du projet avec le commanditaire et les experts techniques.
  2. Définition de tous les besoins métiers du client (et listes de souhaits) pour le nouveau système.
  3. Analyse des processus métiers existants (tels qu’ils existent chez le client) et documentation des processus futurs avec le nouveau système.
  4. Analyse de toutes les spécifications techniques supplémentaires ou des stratégies appliquées aux systèmes d’information/technologies de l’information (SI/TI) définies par le  client.
  5. Génération et livraison de rapports sur les besoins et l’examen des processus.

b). Évaluation de la mise à niveau :

C’est une offre qui permet d’évaluer les améliorations, les risques et la complexité de la mise à niveau envisagée du système. Les tâches clés de cette activité sont les suivantes :

  1. Évaluer la configuration globale et la personnalisation de l’implémentation existante.
  2. Évaluer les interfaces qui ont été configurées dans le cadre de l’implémentation existante.
  3. Évaluer la configuration de l’infrastructure et de l’architecture existantes.
  4. Définir les nouvelles fonctionnalités souhaitées dans le système mis à niveau.
  5. Définir les nouvelles interfaces souhaitées dans le système mis à niveau.

c). Analyse des écarts et l’ébauche de solution :

L’objectif de cet accélérateur est d’identifier les écarts entre les besoins du client et les fonctionnalités applicatives. Cette analyse fournit les éléments requis pour identifier la solution qui permettra de combler ces écarts. Dans le cadre de cette activité, un rapport d’estimation du degré d’adéquation et d’analyse des écarts et des solutions est produit pour décrie la façon dont le produit Microsoft Dynamics doit être utilisé pour répondre aux besoins du client. Cette activité comprend les tâches suivantes :

  1. Lancement du projet avec le commanditaire et les experts techniques.
  2. Analyse des conclusions tirées dans le cadre de l’accélérateur de décision pour l’examen
    des besoins et des processus.
  3. Réunion avec les décideurs pour déterminer le périmètre du projet.
  4. Organisation d’ateliers d’analyse des écarts.
  5. Création d’une fiche d’analyse des écarts.
  6. Création d’un rapport d’ébauche de solution.
  7. Analyse de la fiche d’analyse des écarts et du rapport d’ébauche de solution avec le commanditaire.

d). Évaluation de l’architecture :

L’objectif de cet accélérateur est d’expliquer au client quelle est l’infrastructure requise pour prendre en charge la solution Microsoft Dynamics choisie. L’évaluation de l’architecture donne lieu à un rapport qui détaille l’infrastructure et les spécifications matérielles requises. Cette activité consiste à évaluer l’infrastructure existante et à définir les besoins en la matière pour la solution proposée. Cette activité comprend les tâches suivantes :

  1. Organiser des réunions avec le client afin de comprendre, les besoins métiers, la façon dont Microsoft Dynamics prend en ces besoins.
  2. Analyser les données clés.
  3. Élaborer des recommandations formelles concernant l’infrastructure de déploiement en production et la configuration matérielle.
  4. Passer en revue les recommandations avec le client et intégrer les commentaires.

e). Évaluation du périmètre :

L’objectif de cet accélérateur est d’évaluer de façon approfondie les besoins du client afin de définir de façon détaillée le périmètre et planifier les coûts et les besoins en ressources pour la solution Microsoft Dynamics. L’évaluation du périmètre donne lieu à un rapport détaillé qui formule des recommandations globales pour la suite du projet. Ce rapport détaille les coûts d’implémentation, les ressources nécessaires, les tâches, l’organisation, les répartitions des rôles et d’autres éléments. Les tâches clés de cette activité sont les suivantes :

  1. Analyser les besoins du client et les écarts pour avoir une idée du périmètre du projet
  2. Analyser les résultats obtenus grâce aux évaluations effectuées dans le cadre d’autres accélérateurs de décision.
  3. Analyser les contraintes inhérentes aux processus afin de comprendre la logique des activités exécutées.
  4. Analyser les contraintes imposées à l’approche de l’implémentation de Microsoft Dynamics.

f). Preuve de concept (POC):

L’objectif de cet accélérateur est de démontrer comment les produits Microsoft Dynamics peuvent répondre à des besoins globaux spécifiques. Les domaines spécifiques et les besoins globaux sont partiellement configurés lors de la preuve de concept afin de s’assurer qu’ils sont réalisables. Au cours de cette activité. Cette activité comprend les tâches suivantes :

  1. Examiner les résultats de l’analyse des écarts et de l’ébauche de solution.
  2. Définir les besoins fonctionnels à configurer et le niveau de configuration à atteindre pour répondre à la preuve de concept.
  3. Définir les besoins non fonctionnels ou autres spécifications techniques à aborder dans le cadre de la preuve de concept.
  4. Définir les processus clés à configurer.
  5. Définir les critères d’acceptation clés en vue de s’assurer que les objectifs de la preuve de concept seront atteints.
  6. Rassembler des données et mettre à jour l’analyse des écarts et l’ébauche d’une solution, le cas échéant.

g). Étude d’opportunité :

L’accélérateur de décision pour l’étude d’opportunité a pour but de fournir une évaluation détaillée des avantages directs et indirects qu’une implémentation de Microsoft Dynamics offrira au client et de projeter le retour sur investissement attendu de l’implémentation. L’étude d’opportunité donne lieu à un rapport détaillant le retour sur investissement, le coût total de possession, les délais de récupération attendus pour l’implémentation et une fiche de modélisation du retour sur investissement. Les tâches clés de cette activité sont les suivantes :

  1. Examiner les résultats des offres de services Sure Step terminées.
  2. Rencontrer le commanditaire du projet pour confirmer le périmètre de l’étude
    d’opportunité.
  3. Collecter des données auprès des experts et des décideurs de l’entreprise.
  4. Collecter des données sectorielles et d’évaluation.
  5. Alimenter l’outil de retour sur investissement afin de générer les estimations pertinentes.
  6. Générer et calibrer le rapport d’étude d’opportunité.
  7. Obtenir l’adhésion de l’expert à l’égard du rapport d’étude d’opportunité.
  8. Calibrer le rapport global avec le commanditaire.
  9. Obtenir l’approbation et l’acceptation du commanditaire.

1.3. Génération de la proposition :

La génération de la proposition a pour but de récapituler et réorganiser les informations collectées au cours des activités précédentes. La documentation globale du projet est préparée au cours de cette activité. Il faut documenter la façon dont le périmètre a été délimité ainsi que toutes les activités précédentes portant sur l’accord. Cette activité comprend les tâches suivantes :

  • Synthétiser le périmètre global en fonction des exigences identifiées, définies et expliquées lors des activités antérieures de diagnostic. Cette synthèse décrira de façon générale les processus métiers, les besoins fonctionnels et non fonctionnels ainsi que les exigences en matière d’intégration et d’interface.
  • Créer la charte initiale du projet comprenant les informations collectées au cours de la première tâche.
  • Évaluer une approche d’implémentation adéquate (standard, entreprise, rapide, mise à niveau majeure ou mise à niveau rapide) et préparer des recommandations et des hypothèses.
  • En fonction de l’évaluation, développer le plan de projet global de l’implémentation.
  • Évaluer les compétences requises et les rôles proposés, les responsabilités et un modèle global de gouvernance de projet.
  • Réaliser une évaluation initiale des risques et tenter d’identifier et de décrire une mesure d’atténuation pour chaque risque.
  • Évaluer le temps requis pour exécuter l’implémentation, y compris toutes les dépendances détenues par le client et qui échappent au contrôle direct du projet.

1.4 Contrat de services et de licence final :

Le contrat de licence et de services final est élaboré au cours de plusieurs phases du projet. Lors de la phase de diagnostic, cette activité a pour but de documenter le périmètre global de l’implémentation et d’obtenir l’accord du client. Elle donne lieu à deux livrables clés :

  • L’énoncé des travaux, qui détaille le périmètre de l’implémentation.
  • La proposition d’estimation de budget qui détaille les composants de coût.

1.5 Mobilisation du projet :

Les activités de mobilisation de projet permettent à l’équipe de comprendre clairement les facteurs décisifs du projet et les indicateurs clés qui seront utilisés pour mesurer l’implémentation.

Les activités clés de cette tâche sont les suivantes :

  • Atelier de lancement interne formel incluant les activités suivantes :
  • Présentation des membres de l’équipe
  • Examen détaillé de l’énoncé des travaux
  • Examen de la proposition et de la méthodologie d’implémentation convenue
  • Examen et attribution des rôles
  • Identification des besoins en formation et acceptation de l’agenda
  • Examen et analyse du modèle de gouvernance du projet
  • Discussion de la mission et des objectifs du client, des motivations à l’origine de l’implémentation et de tout autre facteur de réussite clé
  • Discussion et documentation des risques, contraintes et hypothèses connus du projet
  • Examen des conditions de satisfaction définies par le client.

1.6 Livrables clés de la phase de diagnostic :

Le travail effectué au cours de la phase de diagnostic permet de produire plusieurs livrables clés qui jouent un rôle important pour les phases ultérieures du processus d’implémentation.

Le tableau suivant recense quelques livrables clés créés au cours des activités de la phase de diagnostic.

 

Livrables clés de la phase de diagnostic

Livrables clés de la phase de diagnostic

 

La phase de diagnostic conduit à un contrat entre le client et l’intégrateur pour acheter et implémenter Dynamics NAV. Le client devrait examiner attentivement le contrat en utilisant les informations précédentes afin de s’assurer que les éléments du contrat répondent à ces exigences.

Une fois que le client signe le contrat, l’implémentation commence et le client peut s’attendre à une mise en place très formelle, structurée et bien documentée.

 

Offres d’accélérateur de décision

Offres d’accélérateur de décision

2. Phase d’analyse :

La phase d’analyse représente le début officiel du projet d’implémentation. Les activités de la phase d’analyse permettent d’identifier les décisions que le client devra prendre pour orienter l’implémentation. Cette phase repose sur les activités de la phase de diagnostic et implique :

  1. L’examen des processus métiers existants du client pour développer les processus futurs (projection d’état) ;
  2. La détermination et la documentation des besoins fonctionnels pour la solution dans le document des besoins fonctionnels ;
  3. La description des processus métiers améliorés ;
  4. La description des modifications nécessaires pour que le système prenne en charge les futurs processus métiers ;
  5. L’acceptation par le client du document des besoins fonctionnels finalisé et documenté.

Le travail d’analyse dans cette phase est bien plus approfondi que l’analyse générale effectuée dans la phase de diagnostic. À l’issue de cette phase, les clients auront une vision précise de l’implémentation de Microsoft Dynamics proposée, notamment du coût du projet, des livrables et des différentes étapes.

Les activités propres à la phase d’analyse sont personnalisées en fonction du type de projet. Certaines des activités clés de la phase d’analyse sont décrites dans cette section. Les activités suivantes s’inscrivent dans la phase d’analyse :

  • Planification du projet
  • Gestion des risques et des problèmes
  • Gestion des communications
  • Gestion de la proposition
  • Gestion des ressources
  • Gestion de la qualité
  • Identification des besoins en formation des utilisateurs clés
  • Analyse détaillée des processus métiers
  • Examen des besoins métiers (FRD) et documentation des écarts
  • Création de l’environnement Sandbox et de l’environnement de formation
  • Identification des besoins en intégration et en interface
  • Identification des besoins en matière de migration des données

Chaque activité est typique d’un projet de type Entreprise et Standard, à l’exception des activités de gestion des risques et des problèmes, de gestion des communications, de gestion de la proposition, de gestion des ressources et de gestion de la qualité, qui sont des activités menées exclusivement dans le cadre d’un projet de type Entreprise.

 

2.1 Planification du projet :

L’activité de planification du projet a pour but de finaliser la charte du projet et le plan du projet. Les sessions de planification du projet se déroulent généralement conjointement avec le client.

Cette activité comprend les tâches suivantes :

  • Organiser la réunion de lancement avec la direction et les sessions de planification du projet.
  • Finaliser la charte du projet.
  • Finaliser la structure de répartition du travail du projet.
  • Finaliser le plan de projet.
  • S’assurer que le client a examiné et approuvé les livrables.

2.2 Gestion des risques et des problèmes :

L’objectif de la gestion des risques est de comprendre les risques potentiels inhérents à un projet et définir les actions permettant de les mitiger. La gestion des problèmes est le processus qui consiste à suivre et documenter les problèmes depuis leur identification jusqu’à leur résolution.

La gestion des problèmes revêt des aspects importants, notamment :

  • Les problèmes doivent être gérés de façon proactive. Les problèmes non résolus dans les délais impartis ont un impact encore plus négatif sur le projet.
  • Il faut assurer le support nécessaire pour résoudre les problèmes en veillant à ce que les membres de l’équipe et les décideurs appropriés soient au courant de tout problème et de ses conséquences possibles s’il reste irrésolu.
  • Les problèmes peuvent avoir un impact sur les exigences juridiques et contractuelles.
  • Les problèmes sérieux peuvent avoir un impact sur le périmètre du projet, la chronologie et le budget.

L’activité de gestion des risques et des problèmes donne lieu aux livrables suivants :

  • Registre des risques
  • Liste des problèmes
  • Plan de projet mis à jour

2.3 Gestion des communications :

La gestion des communications a pour but d’organiser les besoins en communication de l’équipe projet et de tous les acteurs impliqués afin de garantir que les informations du projet sont exactes et fournies en temps voulu.

La gestion des communications comprend les activités suivantes :

  • Détermination du plan de communication.
  • Examen et approbation du plan de communication.
  • Préparation du lancement du projet.
  • Lancement du projet (interne).
  • Lancement du projet (client).
  • Création de rapports sur la réalisation du projet.
  • Création de rapports d’état du projet.

Elle donne lieu à trois livrables clés :

  • Plan de communication
  • Création de rapports sur la réalisation du projet
  • Création de rapports d’état du projet

2.4 Gestion de proposition :

La gestion de la proposition vise à contrôler le périmètre du projet. Au cours de la phase d’analyse, les modifications apportées au périmètre du projet sont documentées, analysées et approuvées dans le cadre de l’activité de gestion de la proposition. Cette activité comprend les tâches suivantes :

  • Création d’un plan de contrôle des modifications.
  • Examen et approbation du plan de contrôle des modifications.
  • Gestion des demandes de modification.
  • Examen et approbation des demandes de modification.

L’activité de gestion de proposition donne lieu à deux livrables :

  • Plan de contrôle des modifications
  • Plan de projet à jour

2.5 Gestion des ressources :

La gestion des ressources vise à définir, organiser et gérer toutes les ressources du projet. C’est-à-dire les personnes qui travaillent sur le projet et les objets physiques utilisés et consommés à mesure que le projet avance. La gestion des ressources comprend les activités suivantes :

  • Demande et attribution de ressources pour l’équipe projet.
  • Attribution et perfectionnement des compétences de l’équipe.
  • Identification des équipements, des installations et des ressources matérielles.
  • Gestion des ressources du projet.

2.6 Identification des besoins en formation des utilisateurs clés :

L’identification des besoins en formation a pour but de déterminer les formations nécessaires pour les membres de l’équipe projet et les utilisateurs clés. Au cours de cette activité, une feuille de route des formations techniques et fonctionnelles est préparée pour les membres de l’équipe projet et les utilisateurs clés. Cette activité comprend les tâches suivantes :

  • Définition des formations pour les utilisateurs clés.
  • Définition de la logistique de la formation.

Le livrable de cette activité consiste en un plan de formation pour l’équipe du projet et les utilisateur clé définissant le périmètre de formation, les rôles et les responsabilités des membres de l’équipe et la logistique nécessaire pour mettre en place ces sessions de formation. Le plan de formation vise à atteindre les objectifs suivants :

  • Identifier les utilisateurs clés et évaluer leur niveau de connaissances et leurs compétences dans le secteur d’activité qu’ils représenteront dans l’équipe d’implémentation.
  • Définir le type de formation requise pour chaque secteur d’activité.

2.7 Analyse détaillée des processus métiers :

Les processus d’analyse détaillée des processus métiers visent à déterminer et définir les processus métiers futurs et à identifier les fonctionnalités spécifiques de Microsoft Dynamics qui seront utilisées. Idéalement, cette activité prévoit un atelier pour chaque secteur d’activité réunissant les utilisateurs clés du secteur du client. Chaque atelier effectue les activités suivantes :

  • Examiner les modèles de processus et les utiliser comme base pour documenter les processus métiers futurs.
  • Identifier les modifications à apporter aux processus métiers existants du client.
  • Identifier les fonctions principales qui exécuteront les différentes activités.

Le processus consistant à analyser dans le détail les processus métiers donne généralement lieu à un schéma détaillé pour chaque processus métier.

L’activité d’analyse détaillée des processus métier donne lieu à un seul livrable :

Le rapport de présentation des processus métiers, décrivant dans le détail :

  • Les processus métiers
  • Les écarts et les solutions associées
  • Les interfaces du processus métier
  • Tous les écarts au niveau des interfaces.

2.8 Examiner les besoins métiers :

L’objectif de cet examen est d’identifier et de documenter les besoins métiers du client. Il comprend deux activités :

  • L’atelier sur les besoins métiers
  • La documentation des besoins fonctionnels du projet.

L’objectif de l’atelier sur les besoins métiers est d’identifier et de documenter tous les besoins fonctionnels nécessaires à l’implémentation de la solution. Cette activité est nécessaire pour identifier  les besoins métiers fonctionnels du client en ce qui concerne la solution proposée. Il faut définir et documenter la façon dont la solution répond à chaque besoin métier.

Les résultats de l’atelier sur les besoins métiers sont analysés et les processus métier et les informations collectées au cours de cette activité sont utilisés pour créer le document des besoins fonctionnels. Ce document constitue le principal livrable de cette activité et est nécessaire pour élaborer la fiche d’analyse des écarts.

2.9 Exécuter l’analyse des écarts :

L’objectif de cette analyse est d’identifier et de documenter les écarts entre les besoins du client et la solution métier. L’équipe projet doit résoudre les écarts ou proposer une solution de contournement pour les écarts documentés. Cette activité comprend les étapes suivantes :

  • Passer en revue les besoins du client afin de déterminer les besoins intégrés au système et les écarts au niveau des fonctionnalités de la solution métier.
  • Documenter les besoins intégrés au système, y compris les fonctionnalités standard et celles qui nécessitent une configuration.
  • Documenter les écarts entre les besoins du client et la solution métier.
  • Analyser les écarts et identifier des solutions ou contourner le problème.
  • Documenter les résolutions et les solutions de contournement.

L’analyse détaillée des écarts tient compte de la priorité définie par le client pour chaque besoin métier. Cette activité donne lieu à un livrable :

  • La matrice d’analyse des écarts. Dans ce document, chaque besoin métier est identifié comme un écart ou comme étant intégré au système.

2.10. Objectifs et jalons de la phase d’analyse :

La phase d’analyse marque le début de l’implémentation du projet et comprend les activités requises pour planifier et lancer efficacement le projet dans son ensemble.

Les principaux objectifs à remplir au cours de la phase sont les suivants :

  • La finalisation et l’approbation de la charte du projet,
  • La finalisation et l’approbation du plan du projet,
  • La finalisation du plan de contrôle des modifications,
  • L’organisation des réunions de lancement du projet avec les responsables et l’équipe projet,
  • La rédaction des documents des besoins fonctionnels et l’approbation de ces besoins,
  • L’exécution et la documentation de l’analyse des écarts et l’approbation de la fiche correspondante.

Les principaux jalons de la phase sont :

  • Réunion officielle de lancement du projet.
  • Approbation par le client de la charte du projet, du plan de projet et du plan de contrôle des modifications.
  • Approbation par le client du document des besoins fonctionnels et de la fiche d’analyse des écarts.
  • Définition de l’infrastructure et de l’environnement.

2.11. Les livrables de la phase d’analyse :

Les livrables de la phase d’analyse comprennent généralement les éléments suivants :

  • Lancement du projet
  • Charte du projet
  • Plan de projet
  • Registre des risques et des problèmes
  • Plan de contrôle des modifications
  • Plan de communication
  • Plan de formation
  • Workflows des processus métiers après projection d’état
  • Document des besoins fonctionnels
  • Matrice d’analyse des écarts
  • Normes de développement
  • Normes de qualité et de test (plan de test)
  • Document du périmètre de l’infrastructure
  • Document de conception de l’infrastructure
  • Besoins en intégration et en interfaces
  • Besoins en matière de migration des données.

 

3. Phase de conception :

Cette phase consiste à définir la conception de l’implémentation générale de Microsoft Dynamics, en s’appuyant sur les livrables créés lors de l’analyse. Elle consiste également à concevoir des solutions de personnalisation, d’intégration et de migration des données spécifiques, visant à répondre aux besoins métiers identifiés lors de la phase d’analyse.

Les principaux livrables de cette phase sont une spécification de conception générale et une spécification détaillée de la conception technique, toutes deux en adéquation avec les décisions générales prises au cours des phases précédentes. Ces spécifications de conception orienteront les activités de développement durant la phase suivante.

Les activités propres à la phase de conception sont personnalisées en fonction du type de projet. Les activités suivantes s’inscrivent dans la phase de conception :

  • Planifier le projet
  • Gérer la proposition
  • Documenter les configurations dans le document de conception fonctionnelle des adéquations
  • Créer la conception de la personnalisation dans le document de conception fonctionnelle des écarts
  • Créer les documents de conception technique pour chacun des écarts
  • Créer le document de conception de la solution
  • Concevoir les composants d’intégration et d’interface
  • Commencer la conception de la migration des données.

3.1 Planification du projet :

Les activités de planification de projet consistent à analyser et à suivre l’avancement du projet par rapport au plan de projet et à effectuer les ajustements nécessaires pour maintenir le projet en conformité avec le plan.

La planification de projet inclut les tâches suivantes :

  • Mettre à jour le plan de projet en y répercutant toutes les modifications qui sont intervenues dans la chronologie du projet, les jalons et les ressources
  • Élaborer le plan de transfert des connaissances
  • Créer le plan de déploiement.

Ces tâches de planification de projet donnent lieu à deux livrables :

  • Le plan de transfert des connaissances, qui définit le processus de l’équipe projet pour remettre la solution client.
  • Le plan de déploiement, qui décrit la mise en place du système aux utilisateurs finaux.

3.2 Gestion de proposition :

Au cours de la phase de conception, la gestion de proposition a pour objectif de garantir que toutes les modifications intervenues dans le périmètre du projet sont analysées, documentées et approuvées par l’équipe projet et le client.

Cette activité comprend les tâches suivantes :

  • Gérer les demandes de modification ;
  • Examiner et approuver les demandes de modification.

L’activité de gestion de proposition donne lieu à deux livrables :

  • Demandes de modification approuvées ;
  • Plan de projet mis à jour.

3.3 Documenter les configurations dans le document FDD des adéquations :

Le document de conception fonctionnelle des adéquations a pour objectif de capturer les paramètres et les configurations nécessaires pour répondre aux besoins fonctionnels correspondants. Les paramètres et les configurations pertinents sont désignés par « adéquations » lors de l’analyse des écarts.

Au cours de cette activité, le consultant applicatif et l’utilisateur clé approprié commencent à documenter les paramètres et les configurations nécessaires aux fonctionnalités standards et aux solutions ISV de manière à répondre en tous points aux besoins métiers. Ces éléments sont documentés dans le document de conception fonctionnelle des adéquations.

Le document de conception fonctionnelle des adéquations est un livrable clé de la phase de conception, car il capture tous les paramètres et configurations nécessaires.

3.4 Créer la conception des configurations dans le document FDD des écarts :

Le document de conception fonctionnelle des écarts a pour objectif de documenter le développement du code personnalisé nécessaire pour combler les écarts en matière de besoins métiers identifiés au cours de la phase d’analyse des écarts. Cette activité comprend les tâches suivantes :

  • Le consultant applicatif travaille en étroite collaboration avec l’utilisateur clé approprié pour documenter les besoins métiers auxquels doit répondre le développement du code personnalisé.
  • Les pratiques et les règles métiers concernées par la conception du code personnalisé sont documentées.
  • Les besoins en code personnalisé sont documentés dans le document de conception fonctionnelle des écarts.

Cette activité donne lieu à un seul livrable :

  • Document de conception fonctionnelle des écarts (plusieurs documents de conception fonctionnelle peuvent être générés pour chacun des écarts correspondants).

3.5 Créer le document de conception technique :

Le document de conception technique a pour objectif de permettre aux développeurs de documenter les méthodes et le code qui seront générés pour remplir les besoins métiers correspondants. Le document de conception technique détaille chaque amélioration ou modification système figurant dans la solution proposée. Un document de conception technique est créé pour chaque document de conception fonctionnelle des écarts. Cette activité comprend les tâches suivantes :

 Créer le document de conception technique :

  • Documenter les composants spécifiques des couches interface utilisateur, métiers et données nécessaires à l’implémentation de chaque modification système proposée
  • Examiner la sécurité de la conception
  • Identifier d’autres besoins en matière de sécurité

L’activité Créer le document de conception technique donne lieu à une seule livrable :

  • Document de conception technique (plusieurs documents de conception technique peuvent être générés pour chacun des écarts correspondants).

3.6 Créer le document de conception de la solution :

Cette activité a pour objectif de documenter et de réunir tous les éléments de la conception de la solution dans un seul document complet. Le document de conception de la solution propose un résumé de la solution en décrivant le processus de la solution proposée, ainsi que les capacités activées par la solution.

Le document de conception de la solution est généré dans un langage métier, de manière à inclure les éléments du document des besoins fonctionnels, de l’analyse des écarts et des documents de conception fonctionnelle. La génération du document de conception de la solution commence au cours de cette phase et se termine au cours de la phase de développement. Cette activité inclut la tâche suivante :

  • Créer le document de conception de la solution

Le livrable que constitue le document de conception de la solution inclut tout ou partie des informations suivantes :

  • Origine de la société ;
  • Vision et périmètre du projet ;
  • Conception architecturale générale ;
  • Informations sur l’intégration ;
  • Conception de la migration des données ;
  • Besoins en matière de sécurité et d’audit ;
  • Besoins en matière de test ;
  • Besoins en formation.

3.7 Concevoir les composants d’intégration et d’interface :

Cette activité a pour objectif de concevoir les éléments d’intégration et d’interface de la solution. Les éléments de la conception sont capturés dans les documents de conception fonctionnelle des écarts et les documents de conception technique correspondants sont générés.

Pour parvenir à concevoir les composants d’intégration et d’interface de la solution, On doit effectuer les sous-activités suivantes :

  • Déterminer une méthode d’échange d’informations d’une interface à une autre qui réponde aux besoins notamment en matière de sécurité de la solution ;
  • Déterminer les ensembles de données et les modifications nécessaires pour optimiser l’échange d’informations ;
  • Déterminer les besoins opérationnels à remplir.

Les principaux livrables de cette activité sont les documents de conception technique qui correspondent à chaque élément de la conception de l’intégration et de l’interface.

3.8 Commencer la conception de la migration des données :

La tâche de conception de la migration des données a pour objectif de mapper les champs de données de sources existantes et de concevoir le processus de migration des données en identifiant les tâches de migration à effectuer. On doit également concevoir le processus de conversion des données réelles.

Cette activité comprend les deux tâches suivantes :

  • Évaluer la qualité des données sources et déterminer les besoins en matière de nettoyage des données ;
  • Mapper les données.

Cette activité donne lieu à un seul livrable :

  • Fiche sur le mappage des données et la migration des données.

3.9 Objectifs et jalons de la phase de conception :

Au cours de la phase de conception, les principaux livrables sont la spécification de la conception et la spécification de la conception technique. Ces spécifications fourniront les informations nécessaires à la phase de développement.

Les principaux objectifs à remplir au cours de la phase de conception sont :

  • formation de l’équipe centrale
  • spécifications de la conception fonctionnelle pour les éléments suivants :
  1. Solutions relatives aux écarts
  2. Intégration et interfaces
  3. Migration des données.
  • Documents de conception technique
  • Ébauche du document de conception de la solution.

Les principaux jalons de la phase de conception sont :

  • La formation de l’équipe centrale est terminée.
  • Le client accepte les spécifications de la conception.
  • Le client approuve les estimations des coûts et des délais du développement.

3.10. Livrables de la phase de conception :

Même si les livrables de la phase de conception peuvent varier légèrement d’un type de projet à un autre, ils comprennent généralement les éléments suivants :

  • Formation de l’équipe centrale
  • Documents de conception fonctionnelle des adéquations (configurations)
  • Documents de conception fonctionnelle des écarts (personnalisations)
    • Documents de conception fonctionnelle des besoins identifiés comme étant des écarts dans la solution standard
    • Documents de conception fonctionnelle des besoins en intégration et en interface
    • Documents de conception fonctionnelle des exigences en matière de migration des données.
  • Documents de conception technique
  • Scénarios de test des processus
  • Spécification de l’environnement hors production.

4. Phase de développement :

La phase de développement a pour objectif d’élaborer les personnalisations, les intégrations et les processus de migration des données définis dans les spécifications de la conception créées et approuvées au cours de la phase de conception et d’accomplir l’installation et la configuration de la solution standard et des solutions ISV. Les livrables de la phase de développement sont l’installation testée et terminée, les configurations, les personnalisations, les rapports, les intégrations et les programmes et processus de migration des données. Le fonctionnement de chaque composant développé au cours de cette phase est testé et vérifié, conformément aux besoins fonctionnels, aux spécifications de la conception et aux critères de test.

Les activités de développement, telles que les différentes fonctionnalités, les intégrations ou la migration des données, peuvent se poursuivre simultanément au cours de la phase de développement. Cela dépend de la taille et de la complexité du projet et du nombre de ressources disponibles pour travailler sur les différents composants.

La phase de développement comprend les tâches suivantes :

  • Créer la documentation de formation et d’autres documents ;
  • Effectuer la configuration système et l’installation des solutions ISV
  • Commencer le développement du code personnalisé
  • Effectuer le test unitaire et le test des fonctions (Entreprise)
  • Exécuter le test des processus et le test d’intégration
  • Transférer les environnements hors production
  • Commencer le développement de l’interface et de l’intégration.

Les activités propres à la phase de développement sont personnalisées en fonction du type de projet

4.1 Créer la documentation de formation et d’autres documents :

Cette activité a pour objectif de faire en sorte que toute la documentation de formation, y compris les documents connexes (guides de l’utilisateur), soit prête à être livrée au client. Cette activité inclut la tâche suivante :

  • Créer la documentation de formation sur les processus pour les utilisateurs finaux, avec :
    • Explications sur les scénarios, les processus et les activités métiers.
    • Workflows et notifications.
    • Utilisation de scripts de test qui décrivent les interactions entre les utilisateurs et la solution, sous forme de séquence d’étapes simples.

Cette activité donne lieu à plusieurs livrables:

  • Documents de formation ;
  • Documentation sur Microsoft Dynamics et les logiciels ISV applicables ;
  • Guides de l’utilisateur ;
  • Procédures d’exploitation quotidiennes ;
  • Procédures de maintenance système.

4.2 Effectuer la configuration système et l’installation des solutions ISV :

Cette activité a pour objectif d’intégrer à la configuration système et à l’installation des solutions ISV les modifications consécutives à l’apparition de problèmes pendant la procédure de test.

Les problèmes qui entraînent des modifications de configuration sont souvent détectés pendant le test des fonctionnalités standard et des fonctionnalités ISV au moyen du test des fonctionnalités. Ces modifications sont documentées dans le cadre de la procédure de test et doivent être collectées, examinées et intégrées à tous les environnements.

4.3 Commencer le développement du code personnalisé :

Cette activité a pour objectif de lancer le développement du code personnalisé, en vue de combler les écarts entre les besoins du client et la solution en cours d’implémentation.

Cette activité comprend les tâches suivantes :

  • Développer la fonctionnalité ou l’intégration proposée dans le document de conception de la solution et le document de conception technique.
  • Assigner un développeur en chef, de manière à assurer la coordination et la communication entre des développeurs qui travaillent sur une même fonction.

Dette activité amène à l’activité Finaliser le développement du code personnalisé.

4.4 Effectuer le test unitaire et le test des fonctions :

Cette activité a pour objectif d’effectuer des tests pour déterminer si le code personnalisé développé répond aux critères définis et propose les fonctionnalités spécifiées dans le document des besoins fonctionnels, le document de conception fonctionnelle et le document de conception technique.

Cette activité comprend les tâches suivantes :

  • Effectuer le test unitaire (par le consultant développement) du code personnalisé pour déceler et résoudre des problèmes.
  • Effectuer le test des fonctions du code dans un environnement de production simulée (test).
  • Effectuer le test des fonctions avec le consultant applicatif/ fonctionnel, de manière à s’assurer que le code correspond à la conception fonctionnelle.

Cette activité ne donne lieu à aucun document livrable.

4.5 Exécuter le test des processus :

Le test des processus a pour objectif d’effectuer un test complet des processus métiers pour les fonctionnalités configurées de la solution conformément aux besoins en qualité et test créés au cours de la phase d’analyse. Le test des processus s’effectue en exécutant les scénarios automatisés de test des processus définis au cours de la phase de conception. Avant d’exécuter le test des processus, examinez, mettez à jour et finalisez les scénarios et les scripts de test des processus compilés au cours de la phase de conception, de sorte qu’ils correspondent au cadre de développement final. Un test qui associe les processus métiers de vente payable à la commande et d’avis de paiement en est un exemple.

Les fonctionnalités configurées et le code personnalisé développé pour la solution doivent être entièrement testés du point de vue des processus métiers. Telle est la finalité du test des processus.

Cette activité s’inscrit dans le cadre des processus de phase croisée suivants :

  • Besoins et configuration système
  • Développement du code personnalisé
  • Formation.

4.6 Exécuter le test d’intégration :

Cette activité a pour objectif de valider la prise en charge de l’intégration et des interfaces par les processus métiers du client. Le test d’intégration est effectué par l’utilisateur clé et le consultant applicatif qui exécute les scripts de test d’intégration pour les processus métiers de bout en bout.

La sécurité de l’application doit être activée lors de l’exécution de ce test dans un environnement de test, de manière à valider la configuration de sécurité de l’application. La validation de la sécurité de l’application est essentielle au maintien de la confiance du client dans l’équipe projet de consultants.

Ce test a pour objectif de s’assurer que tous les aspects de la solution, notamment tous les systèmes et les sous-systèmes qui interagissent ou s’interfacent avec les processus métiers du client, produisent les résultats escomptés. Le test d’intégration garantit également que l’introduction d’interfaces ou de modules de sécurité supplémentaires n’a pas d’effets négatifs sur le système préalablement validé.

4.7 Transférer les environnements hors production :

Cette activité a pour objectif de faire en sorte que les équipes de support technique du client soient prêtes à prendre en charge les environnements hors production. Les équipes de support technique du client doivent comprendre la solution, le support technique de base et les tâches opérationnelles nécessaires.

Les principales taches de cette étape sont les suivantes :

  • Créer un guide des activités détaillé. Ceci inclut, sans s’y limiter, les éléments suivants :
    • Vue d’ensemble de l’architecture de la solution.
    • Analyse des performances et objectifs de disponibilité de la solution.
    • Optimisation et réglage des performances.
    • Chemins de réaffectation.
    • Processus de sauvegarde et de restauration.
    • Processus de basculement et de reprise sur sinistre.
    • Analyse système et alerte.
    • Lecture complémentaire : liens vers la documentation spécifique au projet et sur la
      plateforme du produit.
    • Paramétrage utilisateur et configuration de l’accès.
  • Organiser une série d’ateliers de transfert avec les équipes de support technique, dans le but de présenter et de commenter le contenu des guides des activités.
  • Obtenir la signature du client acceptant les environnements.

Le principal livrable de cette tâche est un guide des activités axé sur les environnements hors production et destiné à aider les équipes du support technique dans leur exploitation et leur gestion quotidiennes de la solution.

4.8 Commencer le développement de l’interface et de l’intégration :

Cette activité a pour objectif de lancer le développement des composants d’intégration et d’interface à l’aide des mécanismes d’implémentation identifiés au cours de la phase de conception.

Les principales activités de cette tâche sont les suivantes :

  • Créer chaque composant d’intégration et d’interface. Le développement inclut les éléments suivants :
    • Eléments de données ;
    • Interface utilisateur ;
    • Logique du système sous-jacente.
  • Effectuer un test unitaire pour chaque composant d’intégration et d’interface ;
  • Assurer la coordination et la communication avec les autres développeurs qui travaillent sur la même fonctionnalité.

Le livrable de cette activité consiste à fournir des éléments pouvant servir à effectuer un test d’intégration, en partant du principe que des travaux complémentaires pourront s’avérer par la suite nécessaires pour terminer toutes les fonctionnalités ou pour prendre en charge les tâches de déploiement et d’exploitation.

4.9 Objectifs et jalons de la phase de développement :

La phase de développement a pour objectif de créer et de tester les composants système définis et approuvés au cours de la phase de conception.

Les principaux objectifs à remplir au cours de la phase de développement sont :

  • Finaliser la documentation et les guides de formation ;
  • Finaliser les processus métiers selon la projection d’état ;
  • Terminer la configuration du rôle de sécurité ;
  • Terminer l’installation et la configuration du système ;
  • Finaliser le document de conception de la solution ;
  • Terminer le développement du code personnalisé ;
  • Effectuer des tests : processus, acceptation des données et intégration.
  • Développer des scripts pour les tests d’acceptation par les utilisateurs et les tests de performances qui seront tous les deux exécutés au cours de la phase suivante ;
  • Transférer les environnements hors production.

Les principaux jalons pour suivre l’état d’avancement de la phase de développement sont :

  • Guides de formation terminés ;
  • Modèles de processus terminés ;
  • Installation et configuration système terminées ;
  • Développement terminé ;
  • Développement des scripts de test terminé ;

Transfert des environnements hors production terminé.

4.10 Livrables de la phase de développement :

Les livrables de la phase de développement comprennent généralement les éléments suivants :

  • Documentation/guides de formation ;
  • Modèles de processus finalisés ;
  • Configuration système finalisée ;
  • Développement du code personnalisé finalisé ;
  • Tests d’acceptation des données, des processus et d’intégration terminés ;
  • Scripts du test de performances et du test d’acceptation par les utilisateurs développés ;
  • Spécification de l’environnement de production générée ;
  • Développement du code d’intégration et d’interface finalisé ;
  • Développement du code de migration des données finalisé ;
  • Document de conception de la solution finalisé.

 

5. Phase de déploiement :

Le principal livrable de la phase de déploiement est un système opérationnel. Les activités de cette phase ont pour objectif de préparer l’infrastructure, l’environnement de l’application et les utilisateurs finaux à la transition vers ce nouveau système. Elles comprennent les tâches suivantes :

  • Préparer les plans de mise en service et de test du système ;
  • Confirmer les plans de formation des utilisateurs finaux dans le cadre du plan de déploiement finalisé ;
  • Configurer les environnements de production et de test ;
  • Effectuer le test du système et le test de charge à l’aide d’un sous-ensemble des données du client ;
  • Préparer et mettre en œuvre la formation des utilisateurs finaux ;
  • Terminer la migration finale des données et la validation ;
  • Effectuer toutes les activités de mise en service pour lancer le nouveau système.

La phase de déploiement comprend les activités suivantes :

  • Planifier le projet ;
  • Former les utilisateurs finaux ;
  • Assurer la mise en service ;
  • Effectuer le test d’acceptation par les utilisateurs.

5.1. Planifier le projet :

Au cours de la phase de déploiement, les activités de planification du projet portent sur la finalisation du plan de déploiement. Celui-ci détaille les tâches essentielles à effectuer pour assurer la réussite du déploiement.

La planification de projet consiste également à tenir à jour la feuille de calcul financière du projet, à analyser et à suivre l’avancement du projet par rapport au plan de projet et à effectuer les ajustements nécessaires pour maintenir le projet en conformité avec le plan.

Les tâches concernées sont les suivantes :

  • Finaliser le plan de déploiement ;
  • Mettre à jour le plan de projet ;
  • Mettre à jour les documents financiers du projet.

Au cours de la phase de déploiement, l’activité de planification de projet ne donne lieu à aucun nouveau livrable, mais on doit mettre à jour les documents susmentionnés.

5.2. Former les utilisateurs finaux :

Cette activité a pour objectif de former les utilisateurs finaux avant la mise en service du projet.

Les différentes options de formation suivantes sont possibles pour cette activité :

  • Dispenser de courtes sessions dirigées, qui commencent par une présentation générale et se poursuivent par la description détaillée des tâches des utilisateurs finaux.
  • La formation peut être dispensée par :

Les formateurs du client qui ont assisté à la formation des formateurs, Microsoft, un prestataire en formation tiers.

5.3. Assurer la mise en service :

Cette activité a pour objectif d’effectuer les dernières tâches nécessaires au lancement de la solution ERP dans l’environnement de production du client.

En préparation à la mise en service, vérifiez que les tâches suivantes ont été effectuées :

  • Finaliser l’installation de la solution Microsoft Dynamics ;
  • Effectuer des sauvegardes de l’environnement de la solution, des fichiers d’installation et des bases de données de la solution ;
  • Mettre à jour les données financières.

L’activité de mise en service comprend les tâches suivantes :

  • Mise en service :
    • Vérifier l’adéquation du plan de maintenance des bases de données ;
    • Valider la fonctionnalité de réplication, le cas échéant ;
    • clôturer la comptabilité ;
    • terminer le paramétrage final.

Microsoft Dynamics Sure Step propose une liste de vérification de la mise en service qui est un guide utile pour cette activité qui permet d’obtenir la validation du déploiement par le client.

5.4. Effectuer le test d’acceptation par les utilisateurs :

Cette activité a pour objectif de tester entièrement l’installation et la configuration du système et d’obtenir la signature d’acceptation des utilisateurs. Cette activité consiste à tester de bout en bout la solution pour vérifier qu’elle répond bien aux besoins du client.

Cette activité de test comprend les tâches suivantes :

  • Effectuer de bout en bout le test du système ;
  • Evaluer les résultats du test du système ;
  • Effectuer un test de charge pour vérifier comment le système et l’infrastructure réagissent dans différentes situations ;
  • Obtenir la signature du système.

Le client peut toujours demander, y compris après la réussite du test d’acceptation par les utilisateurs, que des modifications soient apportées aux fonctionnalités, à la migration des données et au processus d’intégration. On doit évaluer les modifications demandées qui ne s’inscrivent pas dans le cadre de celles nécessaires pour répondre aux critères de validation préalablement établis.

5.5. Objectifs et jalons de la phase déploiement :

La phase de déploiement a pour objectif de réussir la transition vers la nouvelle solution. Les principaux objectifs à remplir au cours de la phase de déploiement sont :

  • Former les utilisateurs finaux ;
  • Effectuer le test d’acceptation par les utilisateurs ;
  • Assurer la mise en service.

Les principaux jalons pour suivre l’état d’avancement de la phase de déploiement sont :

  • Formation des formateurs terminée ;
  • Formation des utilisateurs finaux terminée ;
  • Test de performances terminé ;
  • Test d’acceptation par les utilisateurs terminé ;
  • Environnement de production prêt ;
  • Migration finale des données terminée ;
  • Obtention de l’acceptation pour l’intégralité du système ;

Mise en service du système.

5.6. Livrables de la phase de déploiement :

Les principaux livrables de la phase de déploiement incluent toutes les tâches nécessaires au déploiement de la nouvelle solution dans l’environnement de production, de sorte que le client puisse commencer à l’utiliser dans des processus métiers au quotidien.

Les livrables de la phase de déploiement comprennent généralement les éléments suivants :

  • Plan de déploiement ;
  • Formation des formateurs ;
  • Formation des utilisateurs finaux.

 

6. Phase d’exploitation :

La phase d’exploitation a pour objectif de garantir au client une assistance technique et fonctionnelle au début de la période de mise en service du nouveau système. Et d’effectuer des tâches visant à clôturer le projet. À la fin de cette phase, le projet sera transmis au client et un support technique permanent doit être assuré.

La phase d’exploitation comprend les activités principales suivantes :

  • Planifier le projet ;
  • Assurer le support à la mise en service ;
  • Transférer la solution au support ;
  • Vérifier les livrables par rapport à l’énoncé des travaux et aux modifications approuvées ;

Assurer l’optimisation et le réglage des performances.

6.1. Planifier le projet :

Cette activité a pour objectif de clôturer le projet une fois la mise en service effectuée et les dernières tâches du projet terminées.

Il faut s’assurer que les promesses ont été tenues et que le client est satisfait du résultat obtenu. Cette activité comprend les tâches suivantes :

  • Finaliser le plan de projet en retraçant avec précision la chronologie, les ressources et les jalons terminés ;
  • Effectuer les dernières activités nécessaires à la clôture du projet, parmi lesquelles :
    • Résoudre tous les points en attente avant, pendant et après la mise en service ;
    • Finaliser la documentation promise au client dans l’énoncé des travaux ;
    • Déterminer la nécessité d’une formation supplémentaire à l’attention des utilisateurs finaux et la mettre en œuvre, le cas échéant ;
    • Procéder au dernier transfert des connaissances au client ;
    • Documenter les retours d’expériences.
  • Finaliser la feuille de calcul financière du projet pour en restituer avec précision son état financier.

L’activité de planification de projet de la phase d’exploitation donne lieu aux quatre livrables clés suivants :

  • Rapport d’état du projet ;
  • Rapport de clôture du projet ;
  • Réunion de clôture du projet ;
  • Acceptation formelle du projet par le client.

6.2. Assurer le support à la mise en service :

Cette activité a pour objectif d’assurer au client un support technique supplémentaire lors de l’utilisation de la nouvelle solution.

Au cours de cette activité, le client apprend à utiliser la solution avec efficacité.

Cette activité comprend les tâches suivantes :

  • Former le client ;
  • Enregistrer, trier et gérer la résolution des problèmes signalés ;
  • Analyser le processus de résolution des problèmes.

L’équipe projet peut assurer le support à la mise en service de deux manières différentes :

  • Support technique sur site, avec présence d’un membre de l’équipe projet sur le site client pendant une durée convenue après la mise en service ;
  • Support technique à distance par courrier électronique, téléphone ou tout autre mode d’échange à distance.

6.3. Transférer la solution au support :

Cette activité a pour objectif de remettre officiellement la solution en opérant un transfert de l’équipe projet à l’équipe de support technique permanent.

Le système est prêt à recevoir la signature finale. Pendant ce temps, le client utilise la solution dans son activité quotidienne et son ancien système n’est plus exploité en parallèle. Les activités de clôture sont terminées, ainsi que le support à la mise en service.

La signature du décideur du client ou du commanditaire marque la fin du projet.

6.4. Vérifier les livrables par rapport à l’énoncé des travaux :

Cette activité a pour objectif d’effectuer une vérification finale en comparant les livrables du projet à l’énoncé des travaux. Cette activité est effectuée par l’équipe d’implémentation, les consultants et les clients une fois la mise en service effectuée. Elle comprend les tâches suivantes :

  • Organiser la réunion d’examen du projet. Il s’agit de passer en revue les points forts et les points faibles du projet et de documenter les problèmes du client.
  • Remettre le projet aux équipes de vente et de support technique.

À la fin de la vérification, les livrables du projet doivent être terminés et être prêts à être remis au client.

6.5. Assurer l’optimisation et le réglage des performances :

Cette activité a pour objectif de mettre au point la solution dans le but d’obtenir des performances optimales et de planifier les capacités à mesure que les besoins d’infrastructure évoluent lors de l’exploitation de la solution.

Les tâches concernées sont les suivantes :

  • Une tâche d’optimisation des performances doit être prévue une fois la mise en service effectuée pour :
    • Vérifier la bonne implémentation des meilleures pratiques en matière de performances.
    • Analyser l’utilisation des ressources de tous les composants de la solution en charge de  production réelle. Cela permet d’identifier les goulots d’étranglement et de planifier les capacités pour étendre l’infrastructure, le cas échéant.
    • Fournir une ligne de référence pour les performances en vue des futures tâches d’optimisation.
  • Des tâches d’optimisation effectuée de manière proactive et régulière.

Les futures tâches d’optimisation doivent porter sur les modifications apportées aux performances de la solution. En règle générale, les tâches suivantes sont concernées :

  • Application de correctifs logiciels et de Service Packs (après le test dans un environnement adapté) ;
  • Mise à jour des statistiques de base de données, des indices et du format de disque pour les fichiers de données ;
  • Archivage d’anciennes données à partir de tables volumineuses ;
  • Examen du code pour les modifications personnalisées.

Chaque examen de l’optimisation des performances documente les performances avant et après l’examen en question, ainsi que les temps de réponse et l’utilisation des ressources de chaque composant.

6.6. Objectifs et jalons de la phase d’exploitation :

La phase d’exploitation a pour objectif de clôturer le projet et de transférer le support technique au client une fois l’implémentation effectuée. Les principaux objectifs à remplir au cours de la phase d’exploitation sont les suivants :

  • Clôturer le projet ;
  • Transférer la solution au client ;
  • Transférer au client les connaissances requises pour utiliser la solution.

Les principaux jalons de la phase d’exploitation sont :

  • Support à la mise en service terminé ;
  • Transfert de la solution au support terminé.

6.7. Livrables de la phase d’exploitation :

Les livrables de la phase d’exploitation sont liés à la clôture et à l’examen du projet. Les livrables de la phase d’exploitation comprennent généralement les éléments suivants :

  • Rapport de clôture du projet ;
  • Livrables du projet.

7. Préparation d’Agile :

Le type de projet Agile a été introduit dans la version 2010 de Sure Step, principalement pour faciliter le développement et le déploiement de la solution aux clients qui souhaitent utiliser Microsoft Dynamics comme une plate-forme et de personnaliser la solution à leurs besoins spécifiques. Pour ce faire, ces clients sont susceptibles d’évoluer leurs exigences au cours du processus de développement, nécessitant une approche souple et itérative de développement, C’est là que le type de projet Agile convient parfaitement.

Ce type est basé sur une approche itérative et incrémentale qu’on peut utiliser pour implémenter des solutions Microsoft Dynamics sur un seul site et qui nécessite des fonctionnalités spécifiques et des personnalisations modérées à complexes. Alors que les types de projet standard, rapide, entreprise et mise à niveau sont basés sur l’approche cascade, le type de projet Agile utilise l’approche du cycle de Sprint pour le déploiement de la solution. Le type de projet Agile donne aux clients plus de contrôle sur la solution finale car ils peuvent rapidement changer la direction du développement et de l’implémentation de la solution d’un cycle de Sprint à l’autre. Cela signifie que les clients sont mieux placés pour répondre aux besoins métier à mesure que le développement progresse.

L’implémentation Agile est adaptée aux projets nécessitant des modifications modérées à complexes, des extensions importantes fournies par un fournisseur de logiciels indépendant (ISV), des infrastructures simples à modérées, une migration de données simple à modérée et un nombre moyen d’utilisateurs. Ce type de projet maintient la formalité et la documentation au minimum tout en engageant le client et en produisant des résultats exceptionnels grâce à son style itératif et adaptatif. Les méthodologies Agiles sont itératives et incrémentales en mettant l’accent sur la livraison d’une solution fonctionnelle grâce à de plus petites parties de fonctionnalité sur une série de cycles de développement assez courts.

Lorsqu’on fournit de manière itérative de petits groupes de fonctionnalités, On va réduire le risque que le client ne reçoit finalement pas la solution la plus appropriée. Si la solution que nous livrons ne correspond pas complètement aux besoins, On peut facilement la réparer lors du prochain cycle de développement. Dans un environnement agile, les clients ont généralement plus d’influence sur la conception et le développement de la solution, et généralement une meilleure compréhension des exigences.

Le type de projet Agile commence par la préparation Agile et se poursuit avec l’exécution d’Agile. Ces deux étapes du projet Agile couvrent les trois phases d’un projet en cascade: analyse, conception et développement. Pendant l’exécution du projet, le projet Agile diffère considérablement des types de projet en cascade. Dans les types de projet en cascade, l’implémentation et la personnalisation sont prévues dans les phases de conception et de développement. Alors que dans l’approche Agile, les projets sont exécutés à travers une série de cycles de Sprint de 30 jours en une seule étape: l’exécution du projet.

Le type de projet Agile démarre avec un ensemble d’activités qui constituent la phase de préparation d’Agile. En commençant par une activité de lancement du projet, la préparation Agile aboutit à la réalisation de son objectif principal, la création du Backlog initiale de la solution. Ce Backlog représente le sous-ensemble initial des exigences pour la solution qui sera utilisé pour lancer le processus de développement dans la phase suivante.

7.1. Examen des besoins et analyse des écarts :

Les solutions Microsoft Dynamics ont parfois besoin de personnalisations pour répondre aux besoins des clients. Une implémentation Agile dans Dynamics Sure Step commence à partir d’une solution packagée et toute personnalisation ou intégration doit se rapporter à cette solution. Comparer les besoins des clients avec les fonctionnalités standards de la solution est donc très important dans une implémentation Agile comme dans une implémentation en cascade.

Le type de projet Agile comprend une analyse des écarts qui est exécuté de la même manière que dans les types de projet Sure Step en cascade. En fait, l’ensemble du processus pour capturer, documenter et comparer les exigences client avec la solution Microsoft Dynamics standard se déroule comme le processus de la phase d’analyse en cascade.

 

Diagramme du processus de préparation d’agile

Diagramme du processus de préparation d’agile

 

7.2. Définir le Backlog de solution :

Les types de projet Sure Step Agile et Waterfall partagent de nombreuses similitudes dans la façon dont les besoins sont collectés et les écarts analysés sont estimées. Cependant, la documentation clé de la phase préparation d’Agile diffère de celle de la phase d’analyse en cascade. Lorsque le FRD est le document clé livré de la phase d’analyse en cascade, le Backlog de solution est le livrable principal de la phase préparation d’Agile.

7.3. La création du Backlog de solution :

Les exigences recueillies lors de la préparation d’Agile sont listés dans un seul document Backlog de solution. Le Backlog de solution est un ensemble de fonctionnalités importantes pour le bon fonctionnement de l’activité du client. Le Backlog de solution est un ensemble dynamique de besoins qui évoluent tout au long du processus de développement afin de refléter continuellement les priorités métiers actuelles.
Il n’inclut généralement pas d’informations détaillées sur les exigences, car les détails des exigences sont clarifiés à l’aide des experts en la matière (SME – Subject matter expert) au sein de l’équipe, au cours de leur développement dans les cycles respectifs de Sprint.

Un numéro de publication spécifique et un numéro de version de cycle de Sprint sont attribués aux besoins métiers, afin de déterminer la priorité des besoins à implémentés.

Le contenu du Backlog de solution est déterminé par le responsable des décisions du client et les experts en la matière, ainsi que les gestionnaires de projet du client et du partenaire. Le BDM (Business decision maker) est responsable de la hiérarchisation des exigences dans le Backlog de solution.

 

Exemple Backlog de solution

Exemple Backlog de solution

 

7.4. Générer les estimations globales de développement :

L’équipe Agile attribue une estimation globale à chaque besoin lorsqu’elle crée le Backlog de solution. Cette estimation exprime l’effort attendu qui serait impliqué dans l’implémentation du besoin en fonction de la compréhension actuelle.

L’estimation est une estimation globale car le détail du besoin n’est pas encore découvert à ce stade.

Les estimations sont corrigées avec des facteurs d’ajustement pour accroître en plus l’estimation initiale. Ces estimations (corrigées) aident le décideur à prioriser ou regrouper les exigences dans les cycles de publication – release cycles.

7.5. Grouper les besoins métier dans des cycles de publication :

Les cycles de publication déterminent la séquence dans laquelle les exigences (besoins) sont développées et livrées au client. Il doit y avoir un minimum d’un cycle de publication (On peut utiliser plus). Le client peut définir autant de cycles de publication que nécessaire pour implémenter toutes les exigences souhaitées.

Si plusieurs cycles de publication sont définis, il convient de prendre soin de déterminer les dépendances entre les exigences dans chaque cycle de publication. Si une dépendance existe entre deux exigences, et qu’une exigence ne peut être délivrée jusqu’à ce qu’une autre soit livré, il faut s’assurer qu’elles sont programmées pour la livraison dans la séquence correcte afin d’éviter d’éventuels problèmes plus tard.
La figure, définition du Backlog de Solution, montre le processus de définition du Backlog de solution.

 

Processus de définition du Backlog de solution

Processus de définition du Backlog de solution

8. Exécution d’Agile :

La phase de préparation agile représente le début officiel de l’implémentation. Cette phase définit les activités nécessaires pour lancer et planifier efficacement l’ensemble du projet. L’exécution agile est un processus itératif de cycle de sprint. Les principaux objectifs de cette phase sont les suivants:

  • Finalisation et approbation de la charte du projet
  • Finalisation et approbation du plan de projet
  • Exécution de la réunion kickoff de l’équipe projet avec la direction
  • Établissement d’une stratégie d’intégration
  • Exécution et documentation de l’analyse détaillée des processus métiers
  • Exécution et documentation de l’analyse des écarts
  • Documentation et approbation des exigences fonctionnelles et non fonctionnelles
  • Définition et approbation du Backlog de la solution

8.1. Cycles de Sprint de 30 jours :

Le projet Agile exécute le projet grâce à une série de cycles de Sprint de 30 jours. Le concept Sprint est inspiré de Scrum et représente une unité de développement de base limitée à une durée spécifique. Le cycle de 30 jours est la durée maximale dans laquelle les exigences assignées au cycle de Sprint sont développées. Au cours de ce cycle de Sprint, les ressources des clients et des consultants travaillent en équipe pour concevoir et développer une solution Microsoft Dynamics répondant aux exigences sélectionnées du client. Les exigences sont clarifiées, conçues, implémentées et testées en vue de la livraison au client pour le test d’acceptation des utilisateurs.

 

Exécution de projet Agile dans Sure Step

Exécution de projet Agile dans Sure Step

 

8.2. Sprint Backlog :

Au cours de chaque cycle de Sprint, un sous-ensemble plus petit des exigences est prélevé du Backlog de solution vers le Sprint Backlog. Les exigences du cycle de Sprint sont copiées du Backlog de solution dans un nouveau Sprint Backlog en prévision de la réunion de planification de Sprint. Chaque exigence est divisée en tâches gérables plus petites, ne dépassant pas 16 heures de longs, est affectées aux développeurs.

Ceci est effectué par le gestionnaire de cycle de Sprint qui est responsable de l’exécution globale du cycle Sprint de 30 jours.

8.3. Cycles de Sprint journalier :

Dans le cycle de Sprint de 30 jours, un cycle de Sprint journalier des tâches est effectué par les membres de l’équipe de Sprint pour surveiller l’avancement et partager les connaissances, les informations, les risques et les dépendances les uns avec les autres lorsqu’ils exécutent des tâches de conception et de développement. Les Sprints quotidiens peuvent démarrer lorsque toutes les tâches sont créées et attribuées pour s’assurer qu’elles peuvent être finalisées dans le cycle Sprint de 30 jours.

 

Sprint

Sprint

 

8.4. Réunion quotidienne du cycle Sprint :

Chaque Sprint quotidien commence par une courte réunion quotidienne de cycle de Sprint où l’équipe de projet se rassemble et chaque membre de l’équipe partage ce qui a été réalisé depuis la dernière réunion, ce qui est prévu d’être réalisé avant la prochaine réunion, et quelles problèmes ont été identifiées qui empêche le bon déroulement des activités attribuées. L’objectif de ces réunions est de tenir tous les membres de l’équipe informés, et résoudre les problèmes dès le début et d’éliminer les problèmes majeurs rapidement. La réunion quotidienne du cycle de Sprint est également connue sous le nom de réunion stand-up.

8.5. Développement quotidien :

La fonctionnalité développée est combinée une fois par jour dans la compilation quotidienne qui est déployée dans l’environnement de test. Le processus de génération quotidienne regroupe tous les éléments complets du développement en un seul ensemble uniforme de configurations, de personnalisations et d’exécutables qui peuvent ensuite être déployés facilement dans n’importe quel environnement cible.

Chaque jour pendant un cycle de Sprint de 30 jours, le développement quotidien est déployé dans l’environnement de test. Dès qu’une exigence est développée, elle est immédiatement testée à l’aide d’un processus connu sous le nom de test de Sprint. Si des modifications sont identifiées lors des essais, elles peuvent être incluses dans le prochain cycle Sprint quotidien. Cependant, si elles ont un impact sur d’autres produits livrables, ces changements doivent être transmis au prochain cycle Sprint.

 

Processus développement dans Scrum

Processus développement dans Scrum

8.6. Examen technique de Sprint :

À la fin d’un cycle de Sprint, l’examen technique de Sprint est exécuté. Le client et l’équipe complètent une série d’étapes et le client approuve la fonctionnalité développée.

L’examen technique de Sprint permet au client et aux consultants de s’entendre sur ce qui doit être conservé, modifié et éliminé avant que le développement ne se poursuive dans le prochain cycle de Sprint de 30 jours.

8.7. Sprint Post Mortem :

Un Sprint post mortem est tenu de communiquer et de documenter chaque leçon apprise et de conclure formellement le cycle de Sprint. Au post-mortem, l’équipe discute de ses réussites, de ses échecs, de ses améliorations et de la manière dont les choses pourraient être différentes au cours du prochain cycle de Sprint. Il peut être comparé à Tollgate Review à la fin de chaque phase de cascade. Le post Mortem est la réunion de rétroaction à la fin d’un Sprint ou le rapport écrit de cette réunion.

 

Sprint Post Mortem

Sprint Post Mortem

 

8.8. Test de la solution :

Après le Sprint post mortem, l’équipe de développement exécute une activité de test de solution détaillée pour vérifier que les exigences du projet sont satisfaites et que la solution fonctionne comme prévu.

8.9. Déploiement de la solution :

Suite au test de la solution, le projet commence à ressembler au type de projet standard en cascade, à mesure que les activités de déploiement sont exécutées et que la solution est déployée en production.

 

Phases projet de type Agile

Phases projet de type Agile

Conclusion :

Microsoft Dynamics Sure Step fournit de nombreuses recommandations opérationnelles et stratégiques pour l’implémentation des produits Microsoft Dynamics. Elle propose des instructions et des conseils systématiques pour les projets d’implémentation de Microsoft Dynamics.
Elle fournit un contenu spécifique au produit, des meilleures pratiques, des outils et des modèles pour la prise en charge de tous les projets d’implémentation, à petite ou grande échelle.
Au niveau opérationnel, Microsoft Dynamics Sure Step comprend des activités à base de tâches qui constituent chacune des phases de la méthodologie. Les offres Microsoft Dynamics Sure Step sont disponibles sous la forme d’accélérateurs de décision (dans la phase de diagnostic) ou d’offres d’optimisation (dans les phases d’implémentation). Pour les projets d’implémentation, différentes méthodes peuvent être utilisées pour répondre aux besoins d’un projet. Pour les grands projets d’implémentation à l’échelle de l’entreprise, il est possible de combiner différents types de projets pour répondre à des exigences de déploiement complexe.

À tous les niveaux de Microsoft Dynamics Sure Step (sauf au niveau de la gestion du programme dans les scénarios de déploiement complexe) se trouvent les tâches, les outils, les modèles et les recommandations en matière de gestion de projet qui vous aideront à chaque étape d’un projet d’implémentation.

Microsoft Dynamics Sure Step est basé sur une plateforme cliente simple à utiliser et permet de créer facilement des projets personnalisables pour modifier Microsoft Dynamics Sure Step et l’adapter aux besoins métiers. L’utilisation de Microsoft Dynamics Sure Step aide également à minimiser et à gérer les risques liés aux projets d’implémentation.

Les phases de Microsoft Dynamics Sure Step définissent une approche systématique de l’implémentation de solutions Microsoft Dynamics.

Les livrables, qui résultent des tâches effectuées au cours d’une phase, fournissent les données nécessaires pour passer à l’étape suivante du processus d’implémentation. Le suivi et le recensement de tous les livrables issus de chaque phase restent la meilleure méthode d’apprentissage de la méthodologie d’implémentation. Cela permet d’obtenir rapidement une vue de l’ensemble des tâches effectuées dans un projet d’implémentation et d’en assurer le suivi.

Les offres prises en charge par la méthodologie Sure Step permettent de personnaliser cette méthodologie de plusieurs façons, afin de répondre aux besoins spécifiques du client. On peut également combiner et associer des phases d’implémentation pour mieux répondre aux besoins du client.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *