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.

 

 

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.

 

 

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.

 

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.

 

 

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.

 

 

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.

 

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.

 

 

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.

 

 

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.

 

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.

 

 

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.

 

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.

Chaque implémentation de Dynamics NAV est complètement différente d’une autre. La raison en est parce que chaque entreprise, quelle que soit la similitude de l’industrie, est géré différemment. La société qui va utiliser le logiciel ERP (généralement appelé le client) est différente, les exigences sont différentes, la portée est différente et même l’équipe qui l’implémente pourrait être différente. Cela apporte beaucoup d’incertitude dans le processus d’implémentation et est la raison principale pour laquelle une méthodologie doit être utilisée.

La méthodologie n’est pas seulement applicable au développement et à la mise en place, mais aussi pour d’autres raisons telles que la manière de facturé un projet ou de transférer les connaissances pour le service d’assistance à la fin du projet par l’équipe du projet.

1. Présentation Microsoft Dynamics Sure Step :

Sure Step est une méthodologie d’implémentation de projet informatiques mis en place par Microsoft afin de structurer au maximum la gestion d’un projet de la phase de diagnostic à la phase de maintenance en s’appuyant sur les meilleures pratiques de l’industrie. Elle permet de fournir une implémentation de Microsoft Dynamics prévisible, respectant les délais et le budget.

Microsoft Dynamics Sure Step repose sur des concepts de gestion de projet éprouvés et des outils simple à utiliser permettant ainsi de garantir le succès de l’intégration des solutions Microsoft Dynamics ERP et CRM. Sure Step est une méthodologie de mise en œuvre complète qui fournit des instructions et des conseils, une bibliothèque de gestion de projet, des outils et des modèles qu’on peut utiliser pour mettre en place des produits Microsoft Dynamics en toute sûreté. Elle est conçue pour nous aider à mieux répondre aux attentes des clients tout en aidant à réduire leur coût total. Sure Step peut être utilisée dans les projets englobant des besoins de toute envergure, qu’ils soient importants, moyens ou modestes, de bout en bout, ainsi que pour les projets adaptés à l’utilisation d’un processus de développement de type Agile. La méthodologie offre des conseils relatifs à la mise en œuvre et à la mise à niveau des projets, ainsi que sur les offres d’optimisation et d’accélérateurs de décision. Des conseils relatifs sont également inclus pour les solutions intersectorielles et verticales.
La méthodologie Microsoft Sure Step est adaptée à tous types de projets car elle peut être modulée en fonction des besoins rencontrés. Ainsi elle garantit la réussite de toute implémentation grâce à sa flexibilité qui permet de s’adapter à la taille et à la structure de chaque projet.

Microsoft Dynamics Sure Step concerne toutes les phases d’un projet d’implémentation, de la vente par la phase diagnostics à l’exploitation, en passant par l’analyse, la conception, le développement et le déploiement. Dynamics Sure Step fournit également des recommandations sur l’optimisation et la mise à niveau d’un déploiement Microsoft Dynamics existant.

La méthodologie Sure Step est évolutive, elle peut être utilisée pour des projets d’implémentation destinés à des entreprises de toute taille. Elle prend en charge tous les produits spécifiques Microsoft Dynamics et les solutions métiers ou verticales particulières.

Microsoft Dynamics Sure Step aide également à gérer et réduire les risques liés aux projets d’implémentation. L’ensemble clairement défini de processus et de livrables, les tâches de gestion des risques aident à limiter les risques dans les projets.

Sure Step fournit des contenus spécifiques aux suites de solution ERP et CRM de Microsoft Dynamics, elle est basé sur sept concepts clés :

• Phases du projet
• Offres d’accélérateur de décision
• Types de projet
• Processus de phase croisée
• Offres d’optimisation
• Bibliothèque de gestion de projet
• Rôles (consultant et client)

Le diagramme suivant présente le modèle de la méthodologie Sure Step et ces sept concepts clés :

 

 

La Sure Step Méthodologie inclut six phases : phase diagnostic, analyse, conception, développement, déploiement et exploitation. Les phases allant de l’analyse à l’exploitation représentent les cinq étapes importantes d’un projet d’implémentation. La phase diagnostic constitue une phase de pré-implémentation, la phase d’exploitation comprend de plus des activités post-implémentation, dans le cas où elle étend la durée de vie du projet au-delà de l’implémentation, jusqu’au stade du support technique. Chaque phase de Microsoft Dynamics Sure Step consiste en un ensemble d’activités et de tâches spécifiques. Le résultat du travail réalisé dans une activité est généralement documenté dans un livrable qui fournit des recommandations et des conseils pour les étapes ultérieures du projet d’implémentation.

Les accélérateurs de décision Sure Step constituent une aide précieuse pour traiter rapidement les préoccupations et questions courantes des clients concernant les solutions Microsoft Dynamics.

Microsoft Dynamics Sure Step propose cinq types de projets : Standard, Entreprise, Rapide, Agile et Mise à niveau.

Chaque processus de phase croisée est un groupe d’activités associées qui concernent plusieurs phases d’implémentation dans un projet de type spécifique.

Les offres d’optimisation sont utilisées pour procéder à des analyses approfondies et indépendantes des projets via des approches à la fois proactives et rétrospectives.

La bibliothèque de gestion de projet fournit des informations détaillées sur les activités type menées dans le cadre de la gestion du projet.

Sure Step identifie et fournit des recommandations pour les intervenants côté consultant et côté client impliqués dans des phases, activités et tâches spécifiques d’un projet d’implémentation.

 

2. Le Client Sure Step :

C’est une application de bureau utilisé comme une grande boite à outils, son contenu fournit en outre des schémas, recommandations reconnues, des modèles exploitables à différentes phases et des conseils détaillés sur les rôles s’illustrant lors des diverses activités et en offrant les meilleures pratiques éprouvées. Ces outils, modèles et les meilleures pratiques du contenu de la méthodologie contribuent à améliorer la qualité et, par là même, le succès des implémentations.

Le modèle Microsoft Dynamics Sure Step se présente au sein d’un outil client qui inclut des vues Référence et Documents de la méthodologie. On utilise la vue référence Pour parcourir les phases, les processus et les activités du modèle. La vue Documents propose aux utilisateurs une vue centrée autour des documents de la méthodologie Microsoft Dynamics Sure Step dans toutes les phases.

 

2.1 Arborescence :

L’arborescence du volet de navigation de Microsoft Dynamics Sure Step client contient les nœuds suivants :

• Microsoft Dynamics Sure Step
• Phase de diagnostic – Activités et accélérateurs de décision
• Types de projets et phases d’implémentation
• Offres d’optimisation
• Bibliothèque de gestion de projet
• Rôles
• Ressources supplémentaires

Le client Sure Step fournit des recommandations sur la gestion des projets d’implémentation et les tâches fonctionnelles et techniques qui constituent l’essentiel du processus d’implémentation de Microsoft Dynamics.

Les composants les plus utiles de Sure Step sont les outils et les vaste ensemble de modèles Microsoft Office fournis pour créer les livrables lors de d’implémentation.

Ce client fournit également de nombreux schémas illustrant chacune des étapes du processus d’implémentation et permet de parcourir la méthodologie pour afficher des informations spécifiques sur les différentes tâches d’implémentation.

 

2.2 Filtres :

Microsoft Dynamics Sure Step prend en charge tous les produits Microsoft Dynamics. Pour gérer cette souplesse, des filtres vous permettent de configurer la méthodologie Microsoft Dynamics Sure Step afin qu’elle corresponde aux besoins de projets d’implémentation spécifiques.

Microsoft Dynamics Sure Step fournit les filtres suivants :

• Solution : utilisez ce filtre pour afficher des conseils généraux sur un produit ou des recommandations particulières sur une solution verticale ou horizontale.
• Product : il permet d’afficher le contenu général ainsi que le contenu correspondant au produit Microsoft Dynamics sélectionné.
• Project Type : utilisez ce filtre pour afficher le contenu relatif à un des types de projets spécifiques : standard, entreprise, rapide, mise à niveau ou agile.

 

2.3 Activités, tâches et sous-tâches :

Les activités et les tâches qui composent chaque phase de la méthodologie sont organisées selon une structure hiérarchique.

Le premier niveau immédiatement sous une phase est appelé activité. Chaque activité est elle–même décomposée en tâches, qui constituent le deuxième niveau de la hiérarchie. Certaines tâches sont divisées en sous-tâches qui constituent le troisième et le dernier niveau de la hiérarchie.  Chacun de ces niveaux est associé à une page d’activité standard. L’illustration suivante donne un exemple de cette hiérarchie à trois niveaux.

 

 

2.4 Structure des pages d’activité :

Chaque page d’activité, de tâches et sous-tâches est constituée des sections suivantes :

• Tools, Templates and Links : les pages d’activité affichent les modèles correspondant aux activités dans cette section. Il peut s’agir de modèles principaux (qui constituent la base du projet) ou de modelés d’exemple (qui illustrent l’utilisation du modèle dans une entreprise fictive).
• Objectif : décrit le but de la phase, activité ou tâche décrite sur la page d’activité.
• Description : définit l’activité et la façon de réaliser l’activité ou la tâche.
• Préalables : identifie les conditions qui doivent être remplies ou les livrables préalables au démarrage de l’activité. Microsoft Dynamics Sure Step définissant une approche systématique de l’implémentation, le produit d’une phase, activité ou tâche peut être utilisé dans la partie suivante du processus. Une condition a posteriori d’une activité peut aussi être la condition a priori de la suivante. C’est également le cas pour les phases. La réussite d’une phase est la condition préalable au démarrage de la phase suivante.
• Diagrammes : les diagrammes Visio apparaissent sur les pages d’introduction, d’activité et de nombreuses pages de tâches. Ils illustrent la méthodologie et permettent d’y naviguer.
• Rôles : identifie qui est impliqué dans l’activité en tant que propriétaire ou participant principal/secondaire.

2.5 Diagrammes de processus Visio :

Les pages d’introduction de chaque phase et activité (niveau 1) contiennent un diagramme Visio représentant le déroulement de cette phase ou activité dans un organigramme. Le diagramme Visio d’une phase représente les activités de cette phase ainsi que la logique de ses arborescences décisionnelles. Les éléments du diagramme contiennent un lien hypertexte qui renvoie vers la page correspondante de l’activité ou de la tâche.

2.6 Ressources supplémentaires :

On utilise le nœud Ressources supplémentaires dans l’arborescence pour accéder aux ressources de la méthodologie. Ce nœud comprend les composants suivants :

• Flux d’informations du document des besoins fonctionnels au document de la conception : ce diagramme détaille le flux d’informations du document des besoins fonctionnels au document de conception de la solution.
• Sure Step – Alignement SDM : Ce schéma montre le mappage entre Microsoft Dynamics Sure Step et sa gamme de services offerts et les méthodologies Microsoft Services Delivery Methodology (SDM), Microsoft Solutions Framework (MSF) et autres méthodes connexes.

• Travaux conceptuels sur site/hors site, sur les différentes phases d’implémentation : Ce schéma montre la répartition conceptuelle du travail à effectuer entre les ressources sur site et celles hors site, pour le développement d’une solution Microsoft Dynamics à l’aide de Microsoft Dynamics Sure Step.

• Informations d’orientation destinées aux partenaires et aux clients sur la sélection du type de projet : Ce document fournit des informations d’orientation pour déterminer le type de projet à choisir.

• Liens vers des ressources supplémentaires : Cela fournit des liens vers des ressources supplémentaires sur la Méthodologie Microsoft Dynamics Sure Step.

• Document d’orientation de projet de comptabilité de gestion de l’environnement : Ce document fournit des conseils sur la compatibilité de gestion de l’environnement pour que les partenaires puissent déterminer si leur projet doit respecter les meilleures pratiques.

• Ressources spécifiques aux produits : Cette section contient un nœud pour chaque produit Microsoft Dynamics. Chaque nœud répertorie des liens vers les ressources spécifiques du produit qui sont référencées dans Microsoft Dynamics Sure Step.

• Glossaire : Ce nœud contient une liste de définitions des termes fréquemment utilisés dans une implémentation.

• Modèles Sure Step : Cette section fournit des modèles de documents pour la création de documents personnalisés reprenant l’aspect et la convivialité standard des documents Microsoft Dynamics Sure Step.

2.7 Navigation dans Microsoft Dynamics Sure Step client :

Microsoft Dynamics Sure Step Client permet d’afficher et de parcourir la méthodologie et les ressources de deux façons :

Vue Référence : cette vue permet aux utilisateurs de parcourir la méthodologie. Ses principales fonctionnalités sont les suivantes :

Filtres Solution, Project Type et Product : utilisez les filtres Solution, Project Type et Product pour affiner le contenu affiché.

Boutons Précédent et Suivant : utilisez ces boutons pour parcourir le contenu par des liens hypertexte, comme dans un navigateur Web.

Chemins de navigation : utilisez les chemins de navigation pour vérifier l’emplacement actuel et remonter rapidement dans la hiérarchie.

Sections de fenêtre réductibles : personnalisez la vue Reference en réduisant les fenêtres inutiles.

Vue Documents : cette vue permet aux utilisateurs d’afficher, de filtrer et d’ouvrir des documents de projet dans toutes les phases de la méthodologie. Ses principales fonctionnalités sont les suivantes :

Filtre des livrables : utilisez ce filtre pour afficher uniquement les livrables orientés client ou tous les livrables.

Localiser du contenu dans Sure Step : cliquez avec le bouton droit sur un document et choisissez cette option pour accéder à l’activité Microsoft Dynamics Sure Step correspondante.

Afficher les documents d’une seule phase : cliquez sur l’en-tête de colonne d’une phase particulière pour afficher uniquement les documents liés à cette phase.

 

 

2.8 Onglets :

Microsoft Dynamics Sure Step client inclut les onglets Sure Step Méthodologie, Projets, Ressources et Préférences. Utilisez chaque onglet pour effectuer une tâche particulière, comme :

• Sure Step Méthodologie : On utilise cet onglet pour parcourir Microsoft Dynamics Sure Step à l’aide des vues Reference ou Documents.
• Projets : On utilise cet onglet pour créer et gérer des projets. Un projet est une collection de documents Microsoft Dynamics Sure Step qui peuvent être modifiés et créés pour un type de projet et un produit Microsoft Dynamics spécifiques. Personnalisez chaque projet pour répondre aux besoins de chaque client.
• Ressources : On utilise cet onglet pour créer des liens vers des ressources utiles, telles que le Guide de l’utilisateur Microsoft Dynamics Sure Step. Cet onglet vous permet également de vérifier si des mises à jour pour Microsoft Dynamics Sure Step sont disponibles.
• Préférences : On utilise cet onglet pour spécifier des préférences de configuration, telles que l’emplacement de stockage des projets, un logo personnalisé pour les livrables et la page qui s’ouvre au démarrage de Microsoft Dynamics Sure Step.
• Recherche : On utilise cet onglet pour rechercher des documents les résultats affichés seront basés sur la recherche de tous les documents du projet qu’on a actuellement sélectionnés.

 

 

3. Notion de phase croisée :

Chaque phase croisée peut inclure plusieurs activités; Cependant, selon le type de projet, un processus en phase croisée peut ou non être utilisé. Par exemple, dans le type de projet rapide, les phases croisées personnalisation de code ou Intégration et Interfaces n’ont aucune activité déclenchée, car le type de projet rapide est pris en charge par la livraison des fonctionnalités standard de la solution.
Donc, un processus de phase croisée est un groupe d’activités associées qui concernent plusieurs phases d’implémentation dans un type de projet spécifique.

Pour chaque phase de Sure Step correspond neuf phases croisées ou flux de travail groupés en trois domaines : Organisation, Solution et Technologie, qui se déroulent à travers le cycle de vie du projet. Ces phases croisées sont utilisées pour grouper les activités de chaque phase de travail.

La méthodologie Microsoft Dynamics Sure Step comporte neuf processus de phase croisée regroupés en trois domaines.

Organisation : Les processus de phase croisée relatifs à l’entreprise incluent les aspects suivants:

• Gestion de programme.
• Formation.
• Analyse des processus métiers.

Solution : Les processus de phase croisée relatifs aux solutions incluent les aspects suivants :

• Besoins et configuration système.
• Développement du code système.
• Qualité et Test.

Technologie : Les processus de phase croisée relatifs à la technologie incluent les aspects suivants :

• Infrastructure technique.
• Intégration et Interfaces.
• Migration des données.

Chaque type de projet utilise différentes combinaisons de ces processus de phase croisée.

 

 

La figure ci-dessous représente le diagramme du processus de phase croisée de gestion des programmes pour un projet de type Standard.

 

 

4. Offres d’optimisation :

Microsoft Dynamics Sure Step propose sept offres d’optimisation permettant de procéder à des examens ou des analyses approfondies et indépendantes des projets d’implémentation via des approches à la fois proactives et rétrospectives. Des offres d’optimisation sont conçues pour aider à réduire les risques et améliorer la satisfaction du client dans le cas d’engagements mixtes complexes (implémentations complexes à large échelle, incluant des consultants de plusieurs partenaires). Elles sont destinées aux clients qui souhaitent l’avis d’un tiers indépendant. Ces offres d’optimisation comportent :

• Des conseils en matière de conception fonctionnelle afin d’évaluer la pertinence de la solution métier et commerciale pour la conception proposée;
• Des conseils en matière de conception technique afin d’évaluer la conception technique proposée pour les performances, l’évolutivité, l’intégration avec d’autres systèmes et des logiciels tiers
• Une gestion proactive de la qualité avec un accès à des spécialistes experts en technologie aux points de contrôle appropriés dans l’implémentation Sure Step afin de réduire les risques d’intégration sur toute la dynamique de technologies.

Les offres d’optimisation incluent actuellement sept points de contrôle de gestion de la qualité, une ou plusieurs d’entre elles peuvent s’appliquer à un engagement donné :

• Examen de l’architecture : examen de l’infrastructure et de l’architecture générale pour répondre aux besoins métiers du client.
• Examen de la conception: examen de la conception des personnalisations et de l’intégration des solutions Dynamics AX et CRM au sein des systèmes existants, sur la base de différents scénarios d’intégration.
• Examen de la personnalisation: examen du code personnalisé développé pour améliorer les performances, augmenter la stabilité, améliorer la sécurité et réduire les coûts de fonctionnement et de mise à niveau.
• Examen des performances : examen de l’impact des performances de la conception et du code sur la base des aides des outils, des méthodes et des meilleures pratiques.
• Examen de l’intégrité : identification proactive des problèmes et suggestions pour leur résolution.
• Examen de la mise à niveau: fournir des conseils aux clients et superviser la mise à niveau de leur implémentation actuelle de Microsoft Dynamics, en ce qui concerne la conception, la personnalisation, l’intégration, l’infrastructure physique et l’architecture.
• Gouvernance du projet et examen de la livraison : consiste à fournir aux clients des examens proactifs sur la gouvernance et la livraison du projet tout au long du projet d’implémentation de Microsoft Dynamics via des examens du cycle de vie (phase par phase) et des examens de fermeture du projet.

 

 

5. Bibliothèque de gestion de projet :

La bibliothèque de gestion de projet fournit des informations détaillées sur les activités type menées dans le cadre de la gestion du projet.

Cette bibliothèque doit être considérée comme un guide pour un gestionnaire de projet en termes de fondamentaux de gestion de projet. Elle offre une vue d’ensemble et des conseils relatifs aux sujets suivants :

• Discipline de la gestion de projet.
• Processus de gestion de projet.
• Discipline de gestion du changement organisationnel.

Elle fournit aussi, des connaissances et des meilleures pratiques et est conçu pour être une source d’inspiration constante pour les chefs de projet qui cherchent à améliorer leurs compétences en gestion de projets en permanence.

 

 

5.1 Discipline de la gestion de projet :

Les disciplines de Microsoft Dynamics Sure Step répartissent les tâches de gestion de projet dans des domaines de connaissance spécifiques. Cette vue fournit des informations pratiques détaillées sur la manière d’effectuer les tâches de gestion de projet.

Les disciplines de gestion de projet sont les suivantes :

• Gestion des risques : permet de gérer les risques pour anticiper leur probabilité et leur impact sur les objectifs du projet, notamment en termes de coût, de délais et de qualité.
• Gestion du périmètre : permet de planifier et de gérer le périmètre du projet tout au long de son cycle de vie.
• Gestion des problèmes : permet de planifier et de gérer les problèmes qui apparaissent tout au long du projet.
• Gestion des délais et des coûts : permet d’établir, de contrôler et de gérer les délais et les coûts de sorte que le projet se termine dans les temps en respectant le budget alloué.
• Gestion des ressources : permet de planifier et de gérer l’ensemble des ressources humaines et matérielles.
• Gestion des communications : permet de planifier et de gérer la communication tout au long du projet.
• Gestion de la qualité : permet de maintenir un certain niveau de qualité (livrables du projet) et de performance pour répondre aux attentes du client.
• Gestion de l’approvisionnement : permet de gérer les achats de biens et de services pour répondre aux besoins du projet.
• Gestion des ventes : permet de planifier les activités de vente, de les adapter et de les coordonner avec les activités de diagnostic pour élaborer une proposition adaptée aux besoins du client.

 

5.2 Processus de gestion de projet :

Les processus de gestion de projet formulent des recommandations pour le lancement, la réalisation et la clôture d’un projet d’implémentation. Ces processus répartissent les tâches de chaque discipline de gestion de projet dans les groupes suivants :

• Lancement et planification du projet ;
• Réalisation et contrôle (suivi) du projet ;
• Clôture (fermeture) du projet.

Les processus de gestion de projet s’adaptent également aux phases de la méthodologie d’implémentation :

• Les tâches de lancement et de planification du projet se déroulent essentiellement au cours de la phase de diagnostic et au début de l’analyse.
• Les tâches permanentes de réalisation et de suivi du projet se déroulent lors des activités d’analyse, de conception et de développement, ainsi qu’au début des activités de déploiement.
• Les tâches de clôture du projet se déroulent au cours du déploiement.

Elles se poursuivent au cours de la phase d’exploitation et jusqu’à la fin du projet.  Cette adaptation a essentiellement pour avantage de désigner les tâches de gestion de projet à effectuer au cours des différentes étapes du projet d’implémentation. Comme chaque projet d’implémentation est unique, le chef de projet doit, en collaboration avec son équipe, déterminer les tâches du processus de gestion de projet à effectuer, ainsi que le niveau de détail nécessaire à la réalisation de chaque tâche.

 

 

5.3 Discipline de gestion du changement organisationnel :

La gestion du changement organisationnel (OCM) interagit avec le processus, les besoins, les commanditaires, les équipes élargies et les communautés d’utilisateurs finaux, de manière à garantir l’adoption de la solution. Cette discipline a pour objectif de proposer une ébauche de l’approche de la gestion des modifications du projet. Ces activités assurent la transformation nécessaire pour remplir les objectifs, la vision et la stratégie indiqués dans l’étude d’opportunité du client.

La gestion du changement organisationnel s’articule autour des cinq activités suivantes :

• Définir une stratégie de gestion du changement organisationnel : passe par plusieurs composants clés qui communiquent les objectifs et les activités de manière à garantir l’adoption des solutions.
• Adapter et mobiliser les responsables : définit un plan d’action à l’attention des dirigeants et des commanditaires de manière à garantir son application conformément au plan général de gestion des modifications.
• Engager les acteurs impliqués : fait en sorte que les acteurs impliqués du projet soit identifiés et engagés de manière proactive tout au long du cycle de vie du projet.
• Adapter l’organisation : fait en sorte que les acteurs impliqués du projet soit identifiés et engagés de manière proactive tout au long du cycle de vie du projet.
• Appliquer l’organisation : fait en sorte que la nouvelle solution soit déployée, les utilisateurs formés et les processus de prise en charge opérationnels.

Chaque activité passe par plusieurs composants de modifications clés qui reprennent la stratégie, la vision, les objectifs et les activités de manière à garantir l’adoption de la solution.

Cette approche OCM s’articule autour des quatre domaines suivants :

• Engagement auprès des acteurs impliqués et des responsables ;
• Mobilisation et adaptation organisationnelle ;
• Communication ;
• Formation.

Les disciplines de gestion des projets de type Agile incluent des domaines spécifiques tels que la gestion du périmètre.

Les activités des processus de phase croisée, dans le cadre de la gestion de programme, font également référence aux activités de ces disciplines.

 

6. Rôles (Consultant et Client) :

Microsoft Dynamics Sure Step est conçu pour aider tous les intervenants participant à un projet d’implémentation Microsoft Dynamics. Lors du déroulement d’un projet d’implémentation, le degré d’implication de chaque intervenant varie selon les phases du projet. Le chef de projet, lui, s’il est plus occupé lors des phases de début et de fin du projet, demeure impliqué de bout en bout dans le projet.

Outre les chefs de projet, les responsables d’engagement et d’équipe s’intéresseront principalement aux recommandations des phases de diagnostic et d’analyse de la méthodologie, et à la section Offres. Ils doivent cependant connaître également le contenu et les activités des phases de conception, de développement, de déploiement et d’exploitation car ils auront à gérer le travail effectué durant ces phases.

Les consultants applicatifs, fonctionnels et techniques qui fournissent la solution doivent se concentrer principalement sur les phases de conception, de développement, de déploiement et d’exploitation. De même, les consultants applicatifs et fonctionnels seront fortement impliqués dans la phase d’analyse, lors de laquelle ils devront finaliser les livrables associés aux documents de conception.

Ces consultants doivent également se familiariser avec les offres proposées par Microsoft Dynamics Sure Step et peuvent donner leur avis en sélectionnant l’offre qui correspond le mieux aux besoins spécifiques d’un client.

Microsoft Dynamics Sure Step identifie et fournit des recommandations pour les rôles de consultant et de client impliqués dans des phases, activités et tâches spécifiques d’un projet d’implémentation.
Les principaux rôles pris en charge par Microsoft Dynamics Sure Step sont :

 

Dans certaines sociétés de consultants/clients, une même personne peut cumuler plusieurs rôles. C’est d’ailleurs souvent le cas dans les petites entreprises.

 

 

7. Types de projet d’implémentation Sure Step :

Les types de projet représentent différentes façons de mener à bien une implémentation. Microsoft Dynamics Sure Step propose cinq types de projets différents, chaque projet comprend un ensemble de phases définies, de phases croisées et d’offres d’optimisation qui représentent une approche normalisée pour l’implémentation des solutions Microsoft Dynamics.

La méthodologie Sure Step fournit deux approches d’implémentation distinctes, Waterfall et Agile que nous allons les définir dans les sections suivantes.

7.1.  Type de projet basé sur Waterfall :

7.1.1.  L’approche Waterfall :

La gestion de projet Waterfall ou traditionnelle en cascade se caractérise par des phases séquentielles de bout en bout, ce qui implique que les tâches sont interdépendantes des autres. Ainsi, une tâche A doit être commencée ou complétée pour que la tâche B puisse être entamée, fonctionnant un peu comme une ligne de production où il faut terminer chaque étape avant d’attaquer la suivante.

Cette approche se base donc sur deux idées fondamentales :

1. Une étape ne peut pas être débutée avant que la précédente ne soit achevée.
2. La modification d’une étape du projet a un impact important sur les étapes suivantes.

 

 

Il existe quatre types de projet Sure Step basés sur l’approche Waterfall et un seul type basé sur l’approche Agile.

 

 

7.1.2.  Projet de type Rapide :

Le projet de type Rapide conçu pour une implémentation accélérée, simple et rapide des fonctionnalités standards (Out-of-the-box), pour le quelle les besoins en termes de personnalisation sont réduits ou inexistants, mais une analyse approfondie est nécessaire pour s’assurer que le client sera en mesure de faire son travail après la conversion. Il est très important que les clients comprennent comment les fonctionnalités par défaut du logiciel fonctionneront pour leur entreprise.

Une Implémentations rapide est la plus simple des méthodes d’implémentation. Le concept fondamental d’une implémentation rapide est que le client accepte d’utiliser les fonctionnalités par défaut intégrées dans la solution. Les modifications sont minimes et peuvent être limitées à l’ajout de logo du client sur les documents.

Choisir une implémentation rapide lorsque les résultats des activités de diagnostic indiquent que les modifications sont très simples, voire inexistantes, et lorsque le risque de glissement du périmètre est faible. Ce scénario convient lorsque le client a l’intention de déployer uniquement les fonctionnalités standard.

Ce type de projet est généralement utilisé dans les projets d’implémentation lorsqu’une ou plusieurs des circonstances suivantes existent :

• Aucune fonctionnalité exclusive au client requise
• Peu ou pas de personnalisations souhaitées
• Personnalisations simples souhaitées
• Une seule solution ISV incluse
• Peu ou pas d’interfaces ou d’intégrations à des sources tiers nécessaires
• Peu ou pas de programmes de migration de données requis
• Mappage du workflow de processus métiers en dehors du périmètre d’implémentation

L’implémentation rapide comprend six phases :

Phase de diagnostic :

La première phase de diagnostic permet de sélectionner rapidement une solution répondant aux besoins du client, elle constitue une phase de pré-implémentation.

Phase d’analyse :

La deuxième phase de la méthodologie Sure Step, celle de l’analyse représente le début officiel de l’implémentation. Le travail d’analyse des processus métiers dans cette phase est bien plus approfondi que l’analyse générale effectuée dans la phase de diagnostic.

Phase de conception :

Cette phase consiste à 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.

Phase de développement :

Cette phase 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.

Phase de déploiement :

Les principaux objectifs de cette phase sont : la préparation de l’infrastructure, de l’environnement de l’application et des utilisateurs finaux à la transition vers le nouveau système opérationnel.

Phase d’exploitation :

Cette phase a pour objectif de clôturer et transmettre le projet au client et de garantir au client une assistance et un support technique et fonctionnelle au début de la période de mise en service du nouveau système.
Ce qui suit est une capture d’écran d’un projet de type rapide.

 

7.1.2.1  Le Service de migration de données Rapid Start :

Parmi les étapes les plus importantes dans une implémentation est la migration des données d’un ancien système vers un nouveau système.

Microsoft a développé un service d’Import/Export rapide appelée Rapid Start, en utilisant ce service, vous pouvez maintenant mapper les données de votre ancien système directement à Dynamics NAV.
Cela permettra d’éliminer la nécessité pour un développeur NAV d’écrire des processus d’importation personnalisés qui ne sont utilisées qu’une seule fois.

Le service Rapid Start permet à l’entreprise d’optimiser son investissement dans un système d’information grâce à un déploiement plus rapide, même sur des sites multiples. La facilité de prise en main de l’ERP Microsoft Dynamics NAV contribue également à la réduction des coûts. En cas de migration, l’importation de la base de données est réalisée très facilement.

Pour une migration de données dans un projet de type rapide vaut mieux utiliser Rapid Start car il est facile à utiliser et très rapide.

En raison de la nature d’une implémentation rapide, le déploiement est limitée aux quelques objets qui peuvent être personnalisés par le biais de développement. Cela devrait être une très courte liste des modifications, souvent limité à des logos sur les documents. Toutes les modifications doivent être soigneusement testées et approuvées. Les objets modifiés sont déplacés vers la base de données de Production, une fois qu’ils sont approuvés.

La formation est critique dans une implémentation rapide. Tous les employés qui utilisent le système doivent être soigneusement formés.

Ce qui suit est une capture d’écran, des phases et leurs activités d’un projet de type rapide :

 

7.1.2.2  Examen de passage :

Un examen de passage peut avoir lieu à la fin de chaque phase du cycle de vie du projet. Il représente un facteur de qualité du projet et un passage obligé conditionnant, à la fin de chaque phase, le passage à la phase suivante.

 

7.1.3.  Projet de type Standard :

Le projet de type standard est adapté aux implémentations mono sites ou aux implémentations multi sites lorsque chaque site est autonome. Les projets de type standard peuvent comporter des fonctionnalités spécifiques au client, des personnalisations complexes, des scénarios de migration des données compliqués et de nombreux utilisateurs.

Ce type de projet est généralement utilisé dans la plupart des implémentations de Dynamics NAV pour un prix d’implémentations fixe.

La méthodologie standard est souvent appelée méthode classique « Cascade« . Comme son nom l’indique, cette méthodologie suit un chemin bien défini et difficile à modifier. À mesure que l’eau se déplace sur une cascade, il commence au sommet et s’écoule dans un chemin prévisible vers le bas. La portée, la chronologie et le coût sont les facteurs qui contraignent le projet. À mesure que l’on change, cela a un effet sur les autres. Le périmètre fonctionnel est la force motrice d’un projet standard et est utilisé pour dériver le calendrier et le coût.

L’implémentation standard est adaptée à des projets nécessitant des modifications modérées à complexes, de grosses extensions fournis par des 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 est adapté lorsque l’une des conditions suivantes s’applique :

• Fonctionnalités spécifiques au client
• Personnalisations complexes
• Infrastructure complexe
• Intégrations ou interfaces spécifiques au client à des systèmes tiers
• Migration complexe des données
• Grand nombre d’utilisateurs
• Grande entreprise avec des besoins métiers uniques sur chaque site.

La prochaine capture d’écran est un projet de type standard dans Sure Step.

 

 

Ce qui suit est une capture d’écran, des phases et leurs activités d’un projet de type standard :

 

En général, la phase de diagnostic se termine avant le début du projet d’implémentation standard.
Le projet de type standard commence par la phase d’analyse et se poursuit avec les phases de conception, de développement, de déploiement et d’exploitation.

7.1.4.  Projet de type Entreprise :

C’est le plus détaillé de tous les types de projet Sure Step, il est adapté aux implémentations multi sites ou internationales, il est généralement utilisé dans les grandes organisations, où chaque site doit intégrer une solution principale. Les projets de type Entreprise peuvent comporter des fonctionnalités spécifiques au client, des personnalisations complexes, des scénarios de migration des données compliquées, de nombreux utilisateurs, ainsi que la conception et le développement d’interfaces personnalisées ou des intégrations à des sources tierces.

Ce type de projet est adapté lorsque l’une des conditions suivantes s’applique :

• Grande entreprise ou multinationale possédant plusieurs sites
• Solution commune entre tous les sites, avec des besoins métiers spécifiques à chaque site
• Fonctionnalités spécifiques au client
• Plusieurs solutions ISV (éditeurs de logiciels indépendants)
• Personnalisations complexes
• Infrastructure complexe
• Migration complexe des données
• Grand nombre d’utilisateurs
• Problèmes de performances de l’infrastructure
• Conception et développement pour le client des interfaces de données externes ou des intégrations à des sources tierces

Choisir un projet d’implémentation de type entreprise lorsque les clients ont des besoins métiers très complexes ou prévoient de vastes implémentations complexes à l’échelle de l’entreprise. Ces projets requièrent une analyse plus approfondie des écarts et/ou des adaptations avant les décisions finales sur la résolution de ces écarts et les modifications des fonctionnalités. Les activités de la phase de diagnostic engendrent également une planification plus approfondie qui aide le chef de projet et le client à définir la meilleure approche pour implémenter la solution.

Un projet d’implémentation de type entreprise comprend les étapes suivantes :

• Version principale
• Version du site
• Déploiement sur site

En général, la phase de diagnostic se termine avant le début du projet d’implémentation de type entreprise.
Le projet de type entreprise lance le début de la solution principale par la phase d’analyse et se poursuit avec les phases de conception et de développement. La solution principale (qui constitue la version principale) couvre les processus et besoins métiers qui sont communs à tous les sites clients. Les personnalisations qui sont propres à un site donné sont enregistrées dans la version du site correspondante. La version principale et la version du site correspondante sont implémentées pour chaque site.

Dans un projet d’implémentation de type entreprise, il est possible de créer différentes propositions de projet pour la version principale et les versions des sites avec les déploiements sur site.

Ce qui suit est une capture d’écran, des phases et leurs activités d’un projet de type Entreprise :

 

7.1.5.  Projet de type Mise à niveau :

Le projet de type mise à niveau est adapté à la gestion des mises à niveau vers les logiciels Microsoft Dynamics d’un client lorsqu’il est nécessaire d’incorporer d’autres besoins et personnalisations.
Il s’agit d’un type de projet spécialement conçu pour répondre aux projets de mise à niveau. Il différencie entre une mise à niveau technique et mises à niveau fonctionnelles. Une mise à niveau technique s’entend pour aller d’une solution existante à une nouvelle version de produit. Une mise à niveau fonctionnelle s’entend non seulement pour aller d’une solution existante à une nouvelle version de produit, mais également pour ajouter de nouvelles Fonctionnalités à la nouvelle version du produit.
Le type de projet mise à niveau permet de mettre à niveau une solution Microsoft Dynamics existante d’un client vers la dernière version, et éventuellement d’incorporer des configurations et des personnalisations supplémentaires dans un environnement Monosite ou Multisite. Il comprend deux approches :

• Mise à niveau technique : utilisée lorsqu’aucune nouvelle fonctionnalité et/ou personnalisation de produit n’est nécessaire.
• Mise à niveau fonctionnelle : utilisée lorsqu’une nouvelle fonctionnalité et/ou personnalisation de produit est requise.

 

 

La mise à niveau fonctionnelle s’appuie sur la mise à niveau technique.

Dans la première version de la solution, les fonctionnalités existantes sont traitées à l’aide de la mise à niveau technique. Dans la deuxième version, les nouvelles fonctionnalités sont ajoutées à l’aide d’un projet de type rapide, standard ou entreprise.

L’implémentation d’un projet de type mise à niveau commence par les activités de la phase de diagnostic. Il inclut des offres d’accélérateur de décision pour l’évaluation de la mise à niveau afin d’identifier plus facilement l’approche à suivre.

Ce qui suit est une capture d’écran, des phases et leurs activités d’un projet de type Mise à niveau :

Détail à ne pas négliger :

• Chaque phase du projet comprend un ensemble d’activités et de tâches spécifiques. Le résultat du travail réalisé dans une activité est généralement documenté dans un livrable qui fournit des recommandations et des conseils pour les étapes ultérieures du processus d’implémentation.
• Les activités et taches propres à chaque phase sont personnalisées en fonction du type de projet.

 

7.2.  Type de projet basé sur Agile :

7.2.1.  L’approche Agile :

Le principe de l’approche Agile est d’adopter une approche produit plutôt qu’une approche projet et de travailler par cycles courts avec des retours fréquents au commanditaire pour évaluer l’adéquation du produit à ses besoins. L’objectif est d’éviter l’un des écueils importants de la méthode Waterfall dans laquelle on peut passer un temps phénoménal à produire un cahier des charges pour réaliser par la suite que la différence de langage du commanditaire et du prestataire fait qu’il y a mécompréhension sur des éléments importants du produit à fournir.

Dans un modèle Agile on part d’une expression des besoins réduite à l’essentiel et on produit un prototype. On présente ce prototype au commanditaire afin de vérifier s’il correspond aux besoins, puis on raffine l’expression des besoins et on fait évoluer ou recommencer le prototype, qu’on représente au commanditaire. On cycle ainsi jusqu’à atteindre l’un des trois éléments suivants :

 1. La satisfaction totale du commanditaire

 2. La date limite de rendu du projet

 3. Le volume horaire maximal allouable à ce projet vu son coût.

L’approche Agile a montré son efficacité quant à la satisfaction du commanditaire et le gain de temps qu’elle permet d’obtenir, en évitant d’attendre un logiciel finalisé pour savoir si l’on a bien compris les besoins du commanditaire.

L’intérêt de la mise en place de la méthodologie agile est d’obtenir un retour client le plus tôt possible, afin de pouvoir s’adapter plus rapidement à ses attentes et besoins s’ils venaient à évoluer au cours du processus de mise en œuvre de la solution.

 

 

7.2.2. Les 4 valeurs de l’Agilité :

L’équipe : Les individus et leurs interactions avant les processus et les outils.

L’application : Des fonctionnalités opérationnelles avant la documentation.

La collaboration : Collaboration avec le client plutôt que contractualisation des relations.

L’acceptation du changement : Adaptation au changement plutôt que conformité aux plans.

 

 

7.2.3.  Les principes de l’Agilité :

• Focus sur la valeur livrée au client
• Livrer de la valeur tôt et fréquemment
• Prioriser les éléments de la solution sur base de leur valeur
• Livrer par incrément des éléments utilisables
• Le plan est subordonné à la valeur livré
• La priorité est de satisfaire le client par des livraisons rapides et continues de logiciel utile.
• Accepter le changement dans les exigences, même tard dans le cycle de vie, pour garantir la compétitivité du client.
• Client et développeurs doivent coopérer quotidiennement tout au long du projet.
• Élaborer des projets autour d’individus motivés. Leur procurer l’environnement et le support nécessaire et leur faire confiance pour réaliser le travail
• La méthode la plus efficace de communiquer des informations à une équipe et entre ses membres reste la conversation en face à face.
• Le fonctionnement de l’application est le premier indicateur d’avancement du projet.
• Régulièrement, l’équipe fait une réflexion sur les façons de
• devenir plus efficace, s’ajuste et modifie son comportement en conséquence.
• Les meilleures architectures, exigences et designs prennent naissance dans des équipes qui se gèrent elles-mêmes.
• Régulièrement, l’équipe fait une réflexion sur les façons de devenir plus efficace, s’ajuste et modifie son comportement en conséquence.
• Fixer les délais et les coûts, mais pas la portée.
• Itérations courtes à durées fixes pour donner de la visibilité au client.
• A chaque itération, une livraison.
• Seul le contenu de l’itération suivante est clairement défini.

La promesse de l’agilité est de produire le maximum de valeur possible. Selon la méthode traditionnelle, le cahier des charges est fixe, le coût et le délai étant variable.

En agilité, le budget et le délai sont fixes, les fonctionnalités étant variable, l’arbitrage de ce qui est à développer se base sur la valeur ajoutée. Ceci évite de développer des fonctionnalités inutiles ou à faible valeur.

 

 

Ci-dessous des diagrammes illustratifs montrant les différences entre les projets agiles et les projets en cascades en termes de visibilité, risque et valeur du projet.

 

D’après le rapport du Standish Group, le taux de réussite des projets en Waterfall reste faible à 14% en 2012, moins qu’en 2009 avec 32%.

Les projets considérés réussis sont ceux ayant respecté le budget, le périmètre fonctionnel et les délais prévus initialement.

 

 

Les principales différences entre Agile et Waterfall, comme indiqué dans le tableau suivant :

 

7.2.4.  Méthodologie Scrum :

Parmi les méthodologies Agile les plus répandues, nous trouvons les méthodes EVO, RAD, DSDM, ASD, FDD, Kanban, Scrum et XP Extreme Programming, mais on va se concentrer sur Scrum, car c’est la méthodologie Agile utilisé dans Dynamics Sure Step.

Scrum permet de pallier les problèmes de la méthode classique dite Waterfall et de s’adapter aux changements qui peuvent arriver au cours du projet, il est ainsi possible de modifier ou de donner plus de précision aux spécifications. Des ajustements peuvent être effectués régulièrement, notamment à la fin de chaque itération, appelée Sprint.

La méthode Scrum, qui tire son nom du terme anglais « Mêlée », en référence à la mêlée du rugby, met l’accent sur l’esprit d’équipe et sur le fait que tous les acteurs doivent avancer dans la même direction pour atteindre un même objectif. Scrum repose sur une intense collaboration de l’équipe qui se focalise sur une partie limitée et maîtrisable des fonctionnalités à réaliser.
Contrairement à la méthode classique dite en cascade qui se compose d’un chef de projet, un MOA et un MOE, l’équipe Scrum est répartie en 3 rôles :

• Le Product Owner : c’est le responsable du produit, il représente les clients et les utilisateurs en transcrivant leurs besoins, définit et priorise les demandes produit.
• Le Scrum Master : qui n’est pas le chef de projet mais il a pour charge de faciliter l’application de Scrum, sa mission est de tout mettre en œuvre pour que l’équipe travaille dans de bonnes conditions et se concentre sur l’objectif du projet. Il porte également une attention particulière au respect des différentes phases de Scrum.
• L’équipe Scrum : L’équipe se gère en toute autonomie et est en charge du développement du produit. Il n’y a pas de notion de hiérarchie, toutes les décisions sont prises ensemble. Elle regroupe les rôles habituellement nécessaires à un projet (architecte, concepteur, développeur, etc.).

La méthode Scrum repose sur deux journaux ou « Backlog » :

• Backlog de produit : liste les fonctionnalités pour le produit qui sont estimées par l’équipe. Il est géré par le Product Owner mais partagé avec l’ensemble de l’équipe. Les fonctionnalités sont priorisées et associées à des critères d’acceptation qui permettent de déterminer si le besoin est couvert.
• Backlog de Sprint : liste l’ensemble des tâches nécessaires pour répondre à l’objectif du Sprint. C’est la propriété de l’équipe, cette dernière le met régulièrement à jour et choisit les tâches sur lesquelles elle souhaite travailler.

Un projet utilisant la méthodologie Scrum se base sur des itérations appelées Sprints qui se succèdent. Un sprint dure de 2 à 4 semaines. Chaque Sprint commence par une réunion de planification appelée « Sprint planning » (appelée aussi planning poker). C’est à l’issue de cette réunion, que l’équipe découvre l’objectif du Sprint et chaque besoin qui est décomposé en plusieurs tâches.

Durant un Sprint, des réunions quotidiennes appelées « Daily meeting » (ou Stand up) de moins de 15 mn permettent à chaque membre de prendre la parole et de faire le point sur ce qu’il a fait, ce qu’il compte faire et les difficultés rencontrées.

Pendant ce Sprint, l’équipe développe l’ensemble des besoins embarqués dans ce sprint en analysant, concevant, développant, testant et intégrant les fonctionnalités.

Chaque Sprint se termine par une revue du Sprint appelée « Démonstration » durant laquelle les besoins réalisés sont évalués par le Product Owner en présence du client qui valide ou pas le produit partiel et modifie par la suite le Backlog de produit.

Une réunion « Rétrospective » se fait généralement après la démonstration. Elle a pour but d’examiner ce qui a bien fonctionné, ce qui ne l’a pas été et ce qui peut être amélioré.

La méthode Scrum suit un processus itératif permettant d’obtenir un produit proche des besoins client en prenant en compte l’évolution de ces derniers et ainsi maximiser la valeur du produit livré.

Si au cours d’un Sprint, un problème survient, la responsabilité n’incombe pas à une seule personne mais elle est partagée entre le Product Owner, le Scrum Master et l’équipe Scrum.

 

 

Ce type d’approche contribue à une meilleure génération de valeur pour le compte de l’entreprise puisque les choix opérés portent sur des unités fonctionnelles plus petites, facilement compréhensibles et dont la valeur ajoutée est mieux ressentie et plus facilement évaluée.

7.2.5.  Le type de projet Agile :

Le projet de type Agile utilise un processus de développement itératif et incrémentiel permettant de créer une solution Microsoft Dynamics. Il comprend une série de phases de rush cycliques qui permettent au client de mieux maîtriser la solution car les besoins et les processus sont développés et affinés progressivement.

Le type de projet Agile est associé à un processus itératif et incrémental pour développer des solutions Microsoft Dynamics. Ce type de projet donne aux clients un plus grand 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 à un autre. Cela signifie qu’ils sont mieux placés pour répondre aux besoins de leurs entreprises à mesure que le développement de la solution progresse.

Ce type de projet peut être attrayant pour les clients, mais il présente son propre ensemble de risques et de problèmes potentiels qui doivent être soigneusement expliqués à un client avant d’entreprendre cette démarche de mise en œuvre. Ce type de projet requiert des indications claires du client et une gestion solide de l’équipe de mise en œuvre. La fréquence et l’intensité de la communication associée à un type de projet Agile sont généralement très élevées, ce qui se traduit par une solution qui reflète clairement les besoins du client. En outre, en raison de la nature dynamique de l’approche du projet, la documentation est réduite au minimum tout au long du projet et est livrée avec une approche à peine optimale lors de la conception des exigences.

Alors que les approches Waterfall de Sure Step ont des activités s’écoulant à travers les cinq phases, le type de projet Agile a des cycles de Sprint qui englobent les phases d’analyse, de conception et de développement. Le type de projet Agile comporte deux phases, déploiement et exploitation, à la fin des cycles de Sprint. Donc, dans ce contexte, le type de projet Agile dévie de l’approche Agile stricte, Il est conçu d’une approche mixte pour les déploiements ERP.

Le Type de projet Agile est généralement utilisé dans les projets d’implémentation lorsqu’une ou plusieurs des circonstances suivantes existent :

• Les exigences du client ne sont pas entièrement définies ou connues à l’avance.
• Le client exige que l’implémentation soit flexible et souple pour tenir compte de l’évolution des changements des priorités dans l’entreprise.
• Le client se focalise sur la livraison de la solution et il n’a pas besoin d’une documentation complète.
• Des fonctionnalités spécifiques au client sont nécessaires.
• Des personnalisations modérées à complexes sont requises.
• Des solutions des fournisseurs de logiciels indépendants (ISV) sont incluses.
• Une infrastructure simple à modérée est impliquée.
• Des intégrations spécifiques pour le client ou des interfaces avec des systèmes tiers sont nécessaires.
• Une migration de données simple à complexe est impliquée.
• Un nombre important d’utilisateurs utilisera la solution.

Le type de projet Agile regroupe ses activités dans les cycles Sprint. Les activités de cycle Sprint englobent l’analyse et la planification de la solution, la conception de la solution et le développement de la solution. À la suite du développement, le type de projet Agile s’appuie sur les phases de déploiement et d’exploitation de l’approche basée sur la cascade, afin de faciliter le déploiement de la solution de manière cohérente.

Critères de recommandation pour le type de projet agile :

Sure Step recommande le type de projet Agile pour les situations nécessitant ce qui suit:

• Fonctionnalités spécifiques.
• Des personnalisations modérées à complexes.
• Solution ISV incluse.
• Intégrations ou interfaces spécifiques au client à des systèmes tiers.
• Migration de données simple à complexe.
• Infrastructure simple à modérée.
• Nombre moyen d’utilisateurs.

Ce qui suit est une capture d’écran, des phases et leurs activités d’un projet de type Agile :

 

 

7.3  Critères de recommandation Microsoft pour la sélection d’un type de projet :

Le tableau suivant contient des directives pouvant être utilisées pour sélectionner le type de projet approprié :