Dynamics Nav

Le meilleur ERP


La solution idéale

pour votre entreprise


Le meilleur choix

pour votre réussite


Nav

Microsoft Dynamics Nav

Dans le contexte des technologies de l’information, l’implémentation d’un ERP englobe tous les processus après-vente impliqués dans le bon fonctionnement d’un élément dans son environnement, y compris l’analyse des besoins, l’installation, la configuration, la personnalisation, l’exécution, le test, l’intégration des systèmes, la formation des utilisateurs, la livraison et l’application d’éventuelles modifications.

Pour qu’une implémentation fonctionne, de nombreuses tâches doivent être effectuées successivement dans différents services. Les entreprises s’efforcent d’utiliser des méthodes éprouvées et de faire appel à des professionnels pour les aider à implémenter un système ERP. Cependant, de nombreux processus d’implémentation échouent par manque de planification appropriée en début de projet, en raison de ressources inadaptées ou de problèmes imprévus.

L’entreprise doit élaborer un plan pour suivre le statut de l’implémentation avec, souvent, un calendrier axé sur la réalisation d’objectifs définis à différentes étapes du processus.

Les principaux acteurs impliqués dans le processus d’implémentation se rencontrent régulièrement pour discuter de l’évolution du projet, partager leurs questionnements et, au besoin, revoir les processus et les procédures.

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

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

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

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

1.  Phase de diagnostic :

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

 

Processus de diagnostic

Processus de diagnostic

 

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

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

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

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

La phase de diagnostic comprend les activités suivantes :

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

1.1  Préparation du diagnostic :

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

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

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

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

a). Examen des besoins et des processus :

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

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

b). Évaluation de la mise à niveau :

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

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

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

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

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

d). Évaluation de l’architecture :

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

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

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

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

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

f). Preuve de concept (POC):

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

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

g). Étude d’opportunité :

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

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

1.3. Génération de la proposition :

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

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

1.4 Contrat de services et de licence final :

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

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

1.5 Mobilisation du projet :

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

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

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

1.6 Livrables clés de la phase de diagnostic :

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

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

 

Livrables clés de la phase de diagnostic

Livrables clés de la phase de diagnostic

 

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

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

 

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

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

2. Phase d’analyse :

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

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

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

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

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

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

 

2.1 Planification du projet :

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

Cette activité comprend les tâches suivantes :

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

2.2 Gestion des risques et des problèmes :

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

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

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

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

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

2.3 Gestion des communications :

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

La gestion des communications comprend les activités suivantes :

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

Elle donne lieu à trois livrables clés :

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

2.4 Gestion de proposition :

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

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

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

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

2.5 Gestion des ressources :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.8 Examiner les besoins métiers :

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

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

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

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

2.9 Exécuter l’analyse des écarts :

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

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

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

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

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

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

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

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

Les principaux jalons de la phase sont :

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

2.11. Les livrables de la phase d’analyse :

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

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

 

3. Phase de conception :

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

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

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

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

3.1 Planification du projet :

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

La planification de projet inclut les tâches suivantes :

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

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

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

3.2 Gestion de proposition :

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

Cette activité comprend les tâches suivantes :

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

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

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

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

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

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

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

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

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

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

Cette activité donne lieu à un seul livrable :

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

3.5 Créer le document de conception technique :

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

 Créer le document de conception technique :

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

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

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

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

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

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

  • Créer le document de conception de la solution

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

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

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

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

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

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

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

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

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

Cette activité comprend les deux tâches suivantes :

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

Cette activité donne lieu à un seul livrable :

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

3.9 Objectifs et jalons de la phase de conception :

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

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

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

Les principaux jalons de la phase de conception sont :

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

3.10. Livrables de la phase de conception :

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

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

4. Phase de développement :

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

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

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

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

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

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

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

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

Cette activité donne lieu à plusieurs livrables:

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

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

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

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

4.3 Commencer le développement du code personnalisé :

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

Cette activité comprend les tâches suivantes :

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

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

4.4 Effectuer le test unitaire et le test des fonctions :

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

Cette activité comprend les tâches suivantes :

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

Cette activité ne donne lieu à aucun document livrable.

4.5 Exécuter le test des processus :

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

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

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

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

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

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

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

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

4.7 Transférer les environnements hors production :

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

Les principales taches de cette étape sont les suivantes :

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

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

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

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

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

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

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

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

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

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

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

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

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

Transfert des environnements hors production terminé.

4.10 Livrables de la phase de développement :

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

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

 

5. Phase de déploiement :

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

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

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

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

5.1. Planifier le projet :

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

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

Les tâches concernées sont les suivantes :

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

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

5.2. Former les utilisateurs finaux :

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

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

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

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

5.3. Assurer la mise en service :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mise en service du système.

5.6. Livrables de la phase de déploiement :

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

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

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

 

6. Phase d’exploitation :

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

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

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

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

6.1. Planifier le projet :

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

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

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

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

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

6.2. Assurer le support à la mise en service :

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

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

Cette activité comprend les tâches suivantes :

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

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

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

6.3. Transférer la solution au support :

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

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

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

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

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

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

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

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

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

Les tâches concernées sont les suivantes :

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

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

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

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

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

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

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

Les principaux jalons de la phase d’exploitation sont :

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

6.7. Livrables de la phase d’exploitation :

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

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

7. Préparation d’Agile :

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

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

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

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

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

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

7.1. Examen des besoins et analyse des écarts :

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

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

 

Diagramme du processus de préparation d’agile

Diagramme du processus de préparation d’agile

 

7.2. Définir le Backlog de solution :

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

7.3. La création du Backlog de solution :

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

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

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

 

Exemple Backlog de solution

Exemple Backlog de solution

 

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

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

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

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

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

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

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

 

Processus de définition du Backlog de solution

Processus de définition du Backlog de solution

8. Exécution d’Agile :

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

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

8.1. Cycles de Sprint de 30 jours :

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

 

Exécution de projet Agile dans Sure Step

Exécution de projet Agile dans Sure Step

 

8.2. Sprint Backlog :

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

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

8.3. Cycles de Sprint journalier :

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

 

Sprint

Sprint

 

8.4. Réunion quotidienne du cycle Sprint :

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

8.5. Développement quotidien :

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

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

 

Processus développement dans Scrum

Processus développement dans Scrum

8.6. Examen technique de Sprint :

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

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

8.7. Sprint Post Mortem :

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

 

Sprint Post Mortem

Sprint Post Mortem

 

8.8. Test de la solution :

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

8.9. Déploiement de la solution :

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

 

Phases projet de type Agile

Phases projet de type Agile

Conclusion :

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

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

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

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

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

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

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 :

 

Modèle de la méthodologie Sure Step

Modèle de la méthodologie Sure Step

 

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.

Client Sure Step

Client Sure Step

 

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.

 

Activités, Taches Et Sous-Taches Dans L’arborescence Sure Step

Activités, Taches Et Sous-Taches Dans L’arborescence Sure Step

 

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.

 

Vue référence et documents de Sure Step Client

Vue référence et documents de Sure Step Client

 

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.

 

Onglets Sure Step Client

Onglets Sure Step Client

 

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.

 

Processus de phase croisée

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.

 

Phase croisée de gestion des programmes

Phase croisée de gestion des programmes

 

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.

 

Offres d’optimisation

 

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.

 

Bibliothèque de gestion de projet

Bibliothèque de gestion de projet

 

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.

 

Processus de gestion de projet

Processus de gestion de projet

 

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 :

Rôles de consultant et client

Rôles de consultant et client

 

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.

 

Roles Microsoft Dynamics Sure Step

Rôles Microsoft Dynamics Sure Step

 

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.

 

Cycle Sure Step en cascade

Cycle Sure Step en cascade

 

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

 

Types de projet

Types de projet

 

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.

 

Projet de type rapide

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 :

 

Les activités d’un projet de type rapide

Les 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.

 

Les activités d’un projet de type standard

Les activités d’un projet de type standard

 

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

Les activités d’un projet de type standard

Les 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
Projet de type entreprise

Projet de type entreprise

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 :

Les activités d’un projet de type entreprise

Les 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.

 

Projet de type mise à niveau

Projet de type mise à niveau

 

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 :

Les activités d’un projet de type mise à niveau

Les 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.

 

Principe de fonctionnement Agile

Principe de fonctionnement Agile

 

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.

 

Les 4 valeurs de l'Agilité

Les 4 valeurs de l’Agilité

 

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.

 

Les contraintes du projet Waterfall & Agile

Les contraintes du projet Waterfall & Agile

 

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.

 

Visibilité, risque et valeur projet Waterfall & Agile

Visibilité, risque et valeur projet Waterfall & Agile

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.

 

Le taux de réussite des projets en Waterfall & Agile

Le taux de réussite des projets en Waterfall & Agile

 

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

Principales différences entre Agile et Waterfall

Principales différences entre Agile et Waterfall

 

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.

 

Processus Scrum

Processus 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 :

 

Les activités d’un projet agile

Les activités d’un projet 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é :

 

Critères de choix d’un type projet Sure Step

Critères de choix d’un type projet Sure Step

 

Du point de vue d’un développeur, NAV 2017 comprend presque 4 700 objets standards potentiellement personnalisables plus l’environnement de développement intégré (les outils de développement C/SIDE), qui nous permet de modifier des objets existants et créer de nouveaux.

Pour cela la compréhension des objets de base disponibles dans Microsoft Dynamics NAV est primordiale.
Strictement parlant, NAV 2017 n’est pas un système orienté objet mais il est basé sur des objets, il est composé de sept types d’objets différents.

Un vrais système orienté objet permettrait la définition et la création de nouveaux types d’objets, tandis que NAV ne permet que la création et la modification d’instances des sept types prédéfinis d’objets. Les sept types d’objets sont :

 

Objet Description
Table Les tables définissent la structure de données et contiennent les enregistrements de données

La table est le type d’objet le plus important, car la plupart des types d’objets en dépendent des tables.

Page Permet aux utilisateurs de visualiser, ajouter, modifier ou supprimer des enregistrements dans une table.
Report Imprime ou affiche un aperçu des données d’une base de données Microsoft Dynamics NAV. Les objets de type rapport peuvent également servir à traiter de grandes quantités de données (mettre à jour des données) avec ou sans affichage de données.
Codeunit Les unités de code sont des conteneurs pour le code de programmation appelés à partir d’autres objets pour exécuter une tâche spécifique. Ils sont toujours structurés dans des segments de code appelés fonctions.
Query Requête: Les requêtes permettent d’extraire des données d’une ou plusieurs tables, de faire des calculs et de sortir sous la forme d’une nouvelle structure de données. Ils peuvent produire des données directement vers Excel et XML.
XMLport Importe ou exporte des données vers ou à partir d’une base de données Microsoft Dynamics NAV, en format XML ou texte longueur variable ou fixe.
MenuSuite Les MenuSuites contiennent des entrées de menu qui se réfèrent à d’autres types d’objets. Sont différents des autres objets. Les menus ne peuvent contenir aucun code ou logique. Les entrées de MenuSuite s’affichent dans la page Départements dans le volet de navigation uniquement dans le client Windows. Dans les clients Web, Tablet et Mobile, ils sont utilisés pour prendre en charge les fonctions de recherche.

Les sept types d’objets de Navision

1. L’environnement de développement intégré C/SIDE :

NAV 2017 comprend un vaste ensemble d’outils de développement de logiciels. Les outils de développement NAV sont accessibles via C/SIDE qui s’exécute dans un environnement de développement client.

Cet environnement et ces outils complémentaires sont habituellement appelés collectivement
C/SIDE. Le C/SIDE comprend un compilateur C/AL. Toute programmation NAV utilise C/AL. Aucun développement NAV ne peut être effectué sans utiliser C/SIDE, mais d’autres outils sont utilisés pour compléter le code C/AL (comme Visual Studio, .NET, COM contrôles et OCX entre autres).

Le C/SIDE est appelé Concepteur d’objets dans NAV. Il est accessible via un raccourci séparé qui est installé dans le cadre d’une installation typique du système complet. Lorsque nous ouvrons le Concepteur d’objets, nous voyons l’écran suivant:

 

Environnement de développement intégré C/SIDE

Environnement de développement intégré C/SIDE

 

Limiter les développeurs à ces sept types d’objets rend le développement plus rapide et plus efficace. Le plus grand bénéfice de cette limitation est la stabilité.

2. Concepteur d’objets :

Le développement dans Microsoft Dynamics NAV 2017 est effectué à l’aide de l’environnement de développement C/SIDE. Cet environnement comprend des outils pour le développement d’applications, la mise à niveau des données, la synchronisation de schéma, création et l’ouverture de la base de données et l’administration des licences. L’outil de développement central est le concepteur d’objets. Il se compose de sept concepteurs d’objets pour la conception des différents types d’objets de l’application Microsoft Dynamics NAV. Par exemple, les tables sont créées en utilisant le Concepteur de table; Les pages sont créées à l’aide du Concepteur de page, etc.
Le concepteur d’objets fournit l’accès à tous les objets de l’application Microsoft Dynamics NAV.

2.1 Concepteur de table :

 

Concepteur de table

Concepteur de table

 

2.2 Concepteur de page :

 

Concepteur de page

Concepteur de page

 

2.3 Concepteur de Rapport :

 

Concepteur de Rapport

Concepteur de Rapport

 

2.4 Concepteur unité de code :

 

Concepteur unité de code

Concepteur unité de code

 

2.5 Concepteur de requête :

 

Concepteur de requête

Concepteur de requête

 

2.6 Concepteur de XMLport :

 

Concepteur de XMLport

Concepteur de XMLport

 

2.7 Concepteur des Menus :

 

Concepteur de XMLport

Concepteur de XMLport

 

C/AL est le langage de programmation utilisé dans l’environnement de développement de Microsoft Dynamics NAV, et l’environnement de développement s’appelle C/SIDE. C/AL est un langage de programmation spécifique à la base de données et il est principalement utilisé pour récupérer, insérer et modifier les enregistrements dans la base de données NAV. C/AL est étendu à partir du langage PASCAL et le compilateur C/AL original a été écrit par Michael Nielsen.

Lors de la modification de l’application NAV conformément aux exigences, le développeur ne modifie pas les fichiers exécutables (.exe), mais les « Objets« .

La base de données Dynamics NAV contient des définitions de chaque objet et chaque objet contient une logique métier pour exécuter l’application ERP.

 

3. Granules de conception d’objets :

3.1 Table Designer :

Ce granule permet aux utilisateurs de modifier n’importe quel objet de table existant pour lequel ils possèdent une autorisation (exception faite du code des tables). Il inclut en outre 10 objets (numérotés de 50 000 à 50 009) leur permettant de créer de nouvelles tables.

3.2 Report Designer :

Le granule Report Designer vous permet de modifier des rapports pour lesquels vous possédez une autorisation, y compris le code C/AL de ces objets (exception faite des objets mettant à jour des tables protégées en écriture). D’autre part, ce granule vous permet de créer 100 nouveaux objets rapports (numérotés de 50 000 à 50 099). Le granule Report Designer permet également d’accéder au Navigation Pane Designer, avec lequel il est possible de créer de nouvelles options de menu. Ce granule donne également accès à l’utilisation de Debugger et Code Coverage.

3.3 Page Designer :

Le granule Page Designer vous permet de modifier les pages pour lesquels vous disposez d’une autorisation. D’autre part, ce granule vous permet de créer 100 nouveaux objets pages (numérotés de 50 000 à 50 099). Le granule Page Designer n’inclut pas l’accès aux codes C/AL des pages. Le granule Page Designer donne également accès au Navigation Pane Designer, de façon à créer de nouvelles options de menu.

3.4 XML Port Designer :

Ce granule permet aux utilisateurs de modifier n’importe quel objet port XML existant pour lequel ils possèdent une autorisation, y compris le code C/AL des ports XML. Il inclut en outre 100 nouveaux objets ports XML (numérotés de 50 000 à 50 009) leur permettant de créer de nouveaux ports XML. Le granule XML Port Designer donne également accès au Navigation Pane Designer, qui permet de créer de nouvelles options de menu.

3.5 Query Designer :

Le granule Query Designer vous permet de modifier les requêtes pour lesquels vous disposez d’une autorisation. D’autre part, ce granule vous permet de créer 100 nouveaux objets requêtes (numérotés de 50 000 à 50 099). Le granule Query Designer n’inclut pas l’accès aux codes C/AL des requêtes.

3.6 Application Builder :

Avec ce granule, les utilisateurs peuvent modifier tout objet Codeunit existant dans le système, ainsi que le code des objets de tables, formulaires et ports XML pour lesquels ils possèdent une autorisation (exception faite des objets mettant à jour des tables protégées). Les utilisateurs reçoivent en outre 100 objets Codeunit (numérotés de 50 000 à 50 099) leur permettant de créer de nouveaux codeunits. Ce granule requiert Page Designer, Report Designer, Table Designer, et XML Port Designer. Il confère également les autorisations nécessaires pour importer et exporter des objets de texte. Toutefois, il n’est utilisable que sur les objets pour lesquels vous avez une autorisation.

3.7 Solution Developer :

Ce granule permet aux utilisateurs de modifier tous les objets pour lesquels ils possèdent une autorisation, y compris ceux mettant à jour les tables protégées. Ce granule requiert Application Builder.

Le terme « tables protégées » s’applique aux tables qui ne peuvent être écrites qu’avec des objets associés à des autorisations spéciales. Ces tables sont généralement les livres comptables et registres, ainsi que certains historiques. Les objets qui sont associés à une autorisation de mise à jour de ces tables (routines de comptabilisation et routines d’ajustement) ne peuvent être créés ou modifiés que par des utilisateurs ayant le granule Solution Developer à leur disposition.

4. Débogueur :

Microsoft a introduit un nouveau débogueur à partir de la version Dynamics NAV 2013. Le but du débogueur est de permettre aux IT d’identifier facilement le problème auquel un utilisateur spécifique est confronté lors de l’utilisation du logiciel, en utilisant le débogueur du code C/AL dans le client Windows RTC et les points d’arrêt conditionnels.

Par définition, le débogage est un processus méthodique de recherche et de réduction du nombre de bogues dans une application. Normalement, la première étape du débogage est de tenter de reproduire le problème. À certaines occasions, la saisie du programme peut être simplifiée pour faciliter le débogage. Ensuite, l’outil de débogage est utilisé pour examiner les statistiques du programme (valeurs des variables, les piles d’appel, etc.) pour suivre l’origine du (des) problème (s) et, enfin, le réparer. C’est une bonne technique pour comprendre comment une application fonctionne. Vous pouvez simplement ouvrir l’objet concerné, lire le code écrit et suivre ses instructions.

 

Débogueur de NAV 2017

Débogueur de NAV 2017

 

Conclusion

Afin de comprendre dans quel but utiliser un système ERP, il est important de disposer, dans un premier temps, de connaissances générales sur cet ERP. Tout utilisateur de Microsoft Dynamics NAV doit savoir comment naviguer dans le Tableau de bord, les volets de navigation et les différentes fenêtres. Il doit également maîtriser les fonctions de base permettant de traiter les données. Une fois ces connaissances préalables acquises, il peut alors utiliser les différentes fonctionnalités offertes par le programme.

Microsoft Dynamics NAV peut être déployé sur site ou dans le Cloud. Chaque utilisateur accède à la solution via une interface qui dépend de sa fonction dans l’entreprise, via son poste de travail, un navigateur ou via une application native pour mobile (smartphone ou tablette).

Les clients Microsoft Dynamics NAV suivants interagissent avec la base de données Microsoft Dynamics NAV via Microsoft Dynamics NAV Server:

  • Client Windows Microsoft Dynamics NAV
  • Client Web Microsoft Dynamics NAV
  • Client Microsoft Dynamics NAV Tablet
  • Client Microsoft Dynamics NAV Phone

Continuer la lecture

L’architecture 3-tiers, aussi appelé Client/serveur 2éme génération vise à séparer trois couches logicielles au sein d’une même application, à modéliser et à présenter cette application comme un empilement de trois couches dont le rôle est clairement défini :

  1. La couche présentation des données : correspondant à l’affichage et les traitements locaux, la restitution sur le poste de travail, le dialogue avec l’utilisateur.
  2. La couche traitement métier : correspondant à la mise en œuvre de l’ensemble des règles de gestion et de la logique applicative, c’est à ce niveau que se trouvent toutes les règles de gestion, et toute l’intelligence de la démarche. pris en charge par le service applicatif ou le middleware.
  3. La couche d’accès aux données : correspondant aux données qui sont destinées à être conservées, cette couche est prise en charge par serveur de base de données (SGBD)

 

 

Architecture 3-tiers

Architecture 3-tiers

 

La solution Dynamics NAV 2017 est disponible Online et en OnPremise. Cette architecture est spécifique à Dynamics NAV OnPremise (Localement – Sur place).

Microsoft Dynamics NAV 2017 a été conçu selon une architecture à 3-tiers. L’utilisation de cette architecture offre une évolutivité et une flexibilité. Cette architecture comprend les couches suivantes:

  1. Couche présentation ou client prise en charge par un client personnalisé appelé (RTC), client Web (PC ou Tablet), client mobile et d’autres types de clients supplémentaires (clients des services web, clients SharePoint).
  2. Couche service (intermédiaire) prise en charge par le serveur d’application NAV appelé NAS (NAV Application server)
  3. Couche de données et manipulation de données (DML) prise en charge par le serveur de gestion de base de données MS SQL Server

Le diagramme suivant illustre une installation simple avec plusieurs type de clients Microsoft Dynamics NAV (RTC, Web, Tablette et Mobile) qui se connecte à un seul serveur NAS (NAV Application Server), qui à son tour se connecte à un autre serveur de base de données MS SQL Server.

 

Architecture 3-tiers NAV 2017

Architecture 3-tiers NAV 2017

 

Le diagramme suivant illustre une architecture à quatre tiers (4-tiers) un client Web Microsoft Dynamics NAV ou un client Microsoft Dynamics NAV Tablet qui se connecte à un serveur Web
IIS qui se connectent à un seul serveur Microsoft Dynamics NAV Server qui à son tour se connecte à un autre serveur de base de données Microsoft SQL Server hébergent les composants de la base de données Microsoft Dynamics NAV.

 

 

Architecture 4-tiers NAV 2017

Architecture 4-tiers NAV 2017

 

Les bonnes pratiques (Best Practices) précise que chaque niveau doit être installé sur un serveur distinct, mais pour des raisons de développement ou de test, on peut les installer sur un seul serveur.

Pour NAV 2017, il faut avoir au moins SQL Server 2012 ou plus récent. Dans ce niveau de données est stocké toutes les données métier.

Services Web :

Avec les services Web, les données et la logique métier de Microsoft Dynamics NAV peut être partagé rapidement et facilement avec d’autres applications telles que Microsoft Office, Microsoft SharePoint, etc…
Certains des collaborateurs de l’entreprise doivent accéder aux données de NAV mais n’ont pas besoin d’avoir un accès complet. Les services Web leur permettent d’accéder aux données sans ouvrir Microsoft Dynamics NAV.

 

Niveau Service Web NAV

Niveau Service Web NAV

 

Microsoft Dynamics NAV est livrée avec un grand nombre de fonctionnalités qui permettent aux entreprises de déployer des processus métier et d’améliorer la productivité dans l’entreprise.

1.  Fonctionnalités Starter Pack :

 

 

1.1 Comptabilité générale de base :

Ce module inclut toutes les fonctionnalités élémentaires  nécessaires pour tenir une comptabilité générale, suivit des comptes et des journaux généraux, payer la TVA, éditer une feuille d’abonnement et les codes journaux. Ce module inclut également les fonctionnalités suivantes :

  • Fonctions pour des rapports internes et externes.
  • Services RapidStart pour Microsoft Dynamics NAV.
  • Approbations des documents ventes et achats.
  • Validation et rapports dans la devise par défaut de votre entreprise.
  • Validation et rapports dans une devise supplémentaire avec le module Devises multiples.
  • Capacité à exporter des données de n’importe quel formulaire vers Word ou Microsoft Excel avec des feuilles de style.
  • Capacité d’établir des liens vers des documents externes.
  • Deux langues – Anglais américain et une autre.
  • Définition de la stratégie d’archivage des documents achats et ventes.
  • Envoi en tâche de fond.

 

1.2 Immobilisations de base :

Gestion des immobilisations, par exemple les immeubles, les équipements, les machines. Gérez diverses transactions liées aux immobilisations : acquisitions, amortissements, dépréciation, appréciation et cession. Pour chaque immobilisation, On définit la méthode et les conditions utilisées pour calculer les amortissements. On peut définir un nombre illimité de méthodes et de conditions pour répondre aux exigences légales et pour des objectifs internes. Ce module est particulièrement bien adapté aux entreprises internationales qui utilisent différentes méthodes d’amortissement.

 

1.3 Comptabilité analytique :

La comptabilité analytique permet de contrôler efficacement les coûts dans l’entreprise en offrant une visibilité et une analyse des coûts prévisionnels et réels des opérations, des services, des produits et des projets. Elle synchronise les coûts avec la comptabilité générale puis ventile ces informations sur différents centres de coûts et des objets de coûts. Ce module inclut :

  • Transfert de coûts à partir du grand livre de la comptabilité générale.
  • Saisie et validation des allocations et des charges internes directement dans le journal des coûts du contrôle de gestion.
  • Définition à l’avance des règles d’allocation des coûts récurrents et exécution dans un traitement par lots.
  • Annulation des allocations.
  • Conversion des entrées des budgets de coûts en entrées réelles.

 

1.4 Échanges entre entreprises :

Gérez les comptes de plusieurs entreprises dans le même processus de validation. Les entreprises peuvent se situer dans la même base de données ou dans des bases de données Microsoft Dynamics NAV différentes. Vous pouvez aussi envoyer des documents aux entreprises partenaires. Les utilisateurs contrôlent le flux des documents via une fonctionnalité Envoyer / Recevoir, les transactions sont effectuées en tant que transactions dans la feuille Comptabilité ou via les effets à recevoir et à payer, ce qui permet l’utilisation de devises différentes et un rapprochement correct.

 

1.5 Budgets : 

Travaillez avec des budgets sur des comptes de la comptabilité générale. Après avoir créé un budget, vous pouvez imprimer la balance qui indique les écarts en pourcentage par rapport à ce budget. On peut travailler sur plusieurs budgets à la fois. Par exemple, un budget à 100% des objectifs, un autre à 90%, etc. Les budgets sont généralement définis par période pour les comptes concernés. Les budgets peuvent être importés ou exportés vers Excel pour qu’on puisse exploiter les possibilités de calcul d’Excel lors de la préparation de nos budgets.

 

1.6 Consolidation :
On peut consolider plusieurs entreprises dans Microsoft Dynamics NAV. Les informations peuvent provenir d’une ou de plusieurs bases de données Microsoft Dynamics NAV ou d’autres fichiers. Ce module nous permet d’importer et d’exporter des informations financières. Si les données sont obtenues de plusieurs solutions Microsoft Dynamics NAV, On doit utiliser ce module uniquement dans l’entreprise principale.

 

1.7 Prévision de trésorerie :

La prévision de trésorerie permet de prévoir comment les liquidités de l’entreprise, trésorerie et autres éléments évolueront dans le temps. Elle se compose de deux éléments : les entrées et sorties en trésorerie, l’argent qu’on peut recevoir et celui qu’on pense dépenser, ainsi que les liquidités dont on peut disposer. L’ensemble de ces éléments permet d’établir une prévision de trésorerie.

 

1.8 Dimensions de base :

Ajoutez deux dimensions supplémentaires au grand livre et à n’importe quel livre de comptabilité dans Microsoft Dynamics NAV pour plus de flexibilité avec les outils analytiques. Nommez ces deux dimensions comme vous le souhaitez et assignez des codes de dimension à chaque transaction qui implique un compte du grand livre, un client, un fournisseur, une immobilisation, une ressource, un projet ou un article du stock. De plus, vous pouvez définir des valeurs de dimension par défaut et des règles sur ces valeurs pour tous les types de comptes (grand livre, client, fournisseur, article, etc.). Cela facilite l’ajout de dimensions à toutes les transactions. Ce module peut être utilisé dans des entreprises qui ont plusieurs projets, régions ou centres de profit. Vous pouvez aussi utiliser ce module pour :

  • Analyser finement des projets dans des entreprises dont les projets se répartissent sur plusieurs départements et fonctions.
  • Générer un état des opérations pour un compte véhicule de fonction, où chaque véhicule est défini comme un projet.
  • Établir un compte unique pour tous les véhicules de fonction avec la possibilité de produire un état détaillé par véhicule.
  • Imprimer la balance pour un département, pour un projet ou pour une combinaison des deux.

 

CRM

CRM

 

Gestion de projet

Gestion de projet

 

Gestion de la chaîne logistique

Gestion de la chaîne logistique

 

1.9 Clients de base :

Définir et mettre à jour la table clients. Valider les transactions des ventes et gérer les clients en utilisant des journaux généraux. Couplé avec devises multiples, ce module peut valider des transactions et gérer des clients dans des devises différentes d’un client à un autre. Le module Clients de base est intégré dans le module Comptabilité et Inventaire et est requis pour la configuration des autres modules Ventes et Clients. Le module Facturation des ventes est fréquemment utilisé avec ce module.

 

1.10 Gestion des commandes :

Gérez des devis, des commandes ouvertes et des commandes classiques. Dans le cas d’un bon de commande client, la quantité disponible est immédiatement ajustée dès que la quantité commandée est saisie. En revanche, si vous établissez une facture pro forma, les quantités en stocks ne sont pas modifiées tant que la facture n’est pas confirmée et transformée en commande. Utilisez le module Gestion des commandes pour :

  • Gérer des envois partiels.
  • Expédier et facturer séparément.
  • Facturer à l’avance.
  • Établir des devis et des commandes ouvertes. (Les devis et les commandes ouvertes n’affectent pas les stocks).

 

1.11 Gestion des retours :

Ce module permet de créer un bon de retour pour qu’un client puisse renvoyer un article endommagé ou ne correspondant pas à la commande. On peut Créer un avoir par retour ou regrouper plusieurs avoirs en une seule note de crédit. On peut aussi lier les bons de retour aux commandes de remplacement.

 

1.12 Ventes (facturation) :

On peut établir, valider et imprimer les factures clients et les notes de crédit vente. Ce module est intégré dans le module Comptabilité et Inventaire.

 

1.13 Fournisseurs de base :

On peut établir et gérer la table fournisseurs, valider les achats via des journaux et gérer les factures à payer. Ce module contient une table des fournisseurs et permet de gérer le journal des fournisseurs à partir du grand journal. Couplé avec devises multiples, ce module peut valider des transactions d’achats et prévoir des règlements dans des devises différentes d’un fournisseur à un autre. Ce module est toujours utilisé si la solution nécessite une table fournisseurs. Il est intégré dans le module Comptabilité et Inventaire et est requis pour la configuration des modules Achats et Effets à payer. Le module Facturation des achats est fréquemment utilisé avec ce module.

1.14 Gestion des achats :

Gérez des devis, des commandes ouvertes et des commandes classiques. Un bon de commande diffère d’une facture pro forma. Dans le cas d’un bon de commande, la quantité disponible est immédiatement ajustée dès que la quantité commandée est saisie. Dans le cas d’une facture pro forma, la quantité en stock ne change pas tant que la commande n’est pas confirmée. Utilisez ce module pour :

  • Gérer des réceptions partielles d’articles.
  • Gérer séparément les réceptions et les factures ; créer des factures pour paiement d’avance.
  • Utiliser des devis et des commandes ouvertes dans le processus d’achat. (Les devis et les commandes ouvertes n’affectent pas les stocks).

 

1.15 Livraisons directes :

Gérez des livraisons directes du fournisseur au client sans passer par votre entrepôt, tout en gardant trace de la commande. Le processus de livraison directe lie automatiquement le bon de commande client au bon de commande fournisseur et contrôle la séquence des validations.

1.16 Gestion des retours d’achats :

Créez un bon de retour d’achat pour rembourser votre propre entreprise d’articles défectueux ou endommagés. Les articles sont extraits du bon de retour d’achat. Vous pouvez éditer un retour partiel d’articles ou regrouper plusieurs retours dans une seule note de crédit et lier les bons de retour d’achat avec des commandes de remplacement.

 

1.17 Gestion des retours d’achats :

Créez un bon de retour d’achat pour rembourser votre propre entreprise d’articles défectueux ou endommagés. Les articles sont extraits du bon de retour d’achat. Vous pouvez éditer un retour partiel d’articles ou regrouper plusieurs retours dans une seule note de crédit et lier les bons de retour d’achat avec des commandes de remplacement.

 

1.18 Gestion des bons de commande :

Automatisez le processus de planification des approvisionnements en utilisant la feuille demande d’achat. Produisez des états de réassort avec commandes et transferts en fonction du stock actuel, des demandes futures, de la disponibilité, et en fonction d’autres paramètres comme les quantités minimales et maximales en stock et les quantités en réassort. Affichez une représentation graphique de la planification. L’utilisateur peut modifier le plan par simple glisser-déposer avant de l’exécuter.

Vous pouvez aussi utiliser la Planification commande – un outil simplifié de planification des approvisionnements qui vous permet de planifier les approvisionnements en fonction de chaque commande reçue, sans optimisation.

 

1.19 Inventaire de base :

Spécifiez les articles que vous avez en stock, leurs unités de mesure, la méthode de coût, le groupe dans l’inventaire, le coût par produit et d’autres propriétés. Effectuez des transactions telles que des ajustements positifs ou négatifs, des achats, des ventes, à partir des feuilles articles. Les enregistrements des quantités et des coûts des transactions validées sont enregistrés dans le livre d’inventaire qui sert à l’évaluation de la valeur du stock et à d’autres calculs de coûts.

Ce module est inclus dans le module Comptabilité. Les processus de validation proviennent des modules Ventes et effets à recevoir et Achats et effets à payer. Ce module est requis pour la configuration des autres modules d’inventaire.

 

RH, LANGUES ET AUTRES

RH, LANGUES ET AUTRES

 

Configuration et développement

Configuration et développement

 

2.  Fonctionnalités Extended Pack :

Inclus toutes les fonctionnalités du Starter Pack plus :

 

Fonctionnalités Extended Pack

Fonctionnalités Extended Pack

Microsoft Dynamics NAV est exclusivement distribuée par des partenaires certifiés Microsoft Dynamics. Ces partenaires proposent des services d’organisation, d’implémentation, de personnalisation et de support afin d’adapter la solution aux besoins de chaque entreprise. Selon le mode de déploiement choisi, les clients peuvent payer leurs licences Microsoft Dynamics NAV en une fois ou par mensualités auprès d’un fournisseur de service.

 

1. Licence perpétuelle :

La licence perpétuelle Microsoft Dynamics NAV aide les PME en leur proposant un coût initial abordable, des outils d’implémentation rapide et des fonctionnalités intégrées. Avec une licence perpétuelle, le client bénéficie d’une solution ERP dont les fonctionnalités ne sont accessibles qu’aux utilisateurs sous licence.

 

Licence perpétuelle Dynamics Nav

Licence perpétuelle Dynamics Nav

 

Licence perpétuelle réel

Licence perpétuelle réel

 

2. Licence d’abonnement à un fournisseur de service :

La licence par abonnement auprès d’un fournisseur de service Microsoft Dynamics NAV réduit le coût initial et correspond à un abonnement par utilisateur et par mois. Ainsi, les PME commencent avec un coût initial faible tout en bénéficiant des fonctionnalités intégrées et des outils de démarrage rapide.

Sans oublié les licences qui peuvent être nécessaires telles que Microsoft SQL Server,  Windows Server, Microsoft Office. Ces licences ne font pas partie du Starter Pack. Tout logiciel supplémentaire doit avoir sa propre licence.

3. Modèles utilisateur :

Si un client a plus de trois utilisateurs qui accèdent à l’application en même temps (utilisateurs simultanés), il doit acquérir des licences utilisateur supplémentaires au-delà des trois premières licences d’utilisateur complet incluses dans Starter Pack.

L’accès à la solution Dynamics NAV est autorisé par licence utilisateur sur la base d’un utilisateur concurrent. Les licences utilisateur simultanées sont basées sur le nombre maximum d’utilisateurs pouvant accéder à la solution Microsoft Dynamics NAV simultanément. Les licences utilisateur simultanées peuvent être partagées entre plusieurs individus, la limitation étant le nombre de personnes pouvant accéder à la solution en même temps.

Contrairement aux licences utilisateur nommé, qui sont affectées en permanence à un individu, les licences utilisateurs simultanées sont attribuées temporairement à un utilisateur pour la durée de leur session active. Une fois que cet individu finit la session active, la licence devient disponible pour une autre personne.

Microsoft Dynamics NAV contient deux compteurs d’utilisateurs simultanés – un pour les utilisateurs complets et un autre pour les utilisateurs limités – afin de suivre le nombre d’utilisateurs connectés simultanément.

3.1 Utilisateur complet :

Les licences utilisateur complet offrent aux utilisateurs un accès complet d’écriture et de lecture à toutes les fonctionnalités de la solution sous licence par tous les modes d’accès, y compris le client Windows, le client Web et le client Microsoft SharePoint ou tout autre mode d’accès passant par l’API (y compris Services Web). Les licences utilisateur complet sont destinées aux utilisateurs nécessitant un accès illimité en lecture et en écriture. Tant que le nombre d’utilisateurs nécessitant un accès simultané à la solution ne dépasse pas le nombre de licences total acquis, ces utilisateurs sont correctement autorisés pour un accès complet en lecture et en écriture aux fonctionnalités complètes de la solution.

Utilisateur complet

Utilisateur complet

3.2 Utilisateur limité :

Les licences utilisateur limité obtiennent un accès limité à la Solution pour effectuer uniquement les tâches suivantes :

Accès en lecture à toute donnée contenue dans la solution Dynamics NAV et accès en écriture à un maximum de 3 objets table avec les exceptions suivantes :

Les utilisateurs limités ne sont pas autorisés à écrire directement ou indirectement dans les tables suivants : Ecriture comptable (N° 17), Ensemble d’autorisations (N° 2000000004), Autorisation (N° 2000000005) ou Contrôle d’accès (N° 2000000053); et les tables décrites dans le tableau « Tables inclus pour utilisateur limité » ne comptent pas pour les 3 objets table. L’écriture des transactions d’un Utilisateur limité sur une table temporaire, pour qu’un utilisateur avec accès complet la valide vers la table 17 est un exemple d’accès indirect en écriture à la table 17 qui n’est pas autorisé.

Les tables inclus dans la licence utilisateur limité permettent d’effectuer les tâches suivantes:

  1. Ventes : Créer un client avec les coordonnées pertinentes, en fonction d’un modèle ou à partir de zéro. Créer une opportunité pour une campagne existante, et la relier à des devis ou des commandes de vente.
  2. Devis : Créer un devis de vente pour un client existant ou un nouveau client. Envoyer un devis de vente par courrier électronique, l’envoyer pour approbation ou le convertir à une commande client.
  3. Commande : Créer une commande client pour un client existant ou un nouveau. Envoyer une commande client pour approbation.
  4. Achat : Créer un fournisseur avec les coordonnées pertinentes, en fonction d’un modèle ou à partir de zéro. Créer un bon de commande pour un fournisseur existant ou un nouveau fournisseur. Envoyer un bon de commande pour approbation.
  5. Autres tâches : Remplir une feuille de temps existante, effectuer la capture de document, rapport de dépenses en analysant une facture pour créer un document entrant.
  6. Centres de rôles : Utiliser les graphiques sur deux centres de rôle: Préparateur de commandes vente (pour les scénarios de vente) et Agent d’achat (pour les scénarios d’achat).

Toutefois, si un déploiement spécifique nécessite plus de 3 tables qui ne font pas partie des tables Inclus pour effectuer ces tâches, un utilisateur complet sera requis. Tout accès au-delà de ces limitations nécessite un accès utilisateur complet.

Lors de l’attribution des droits de sécurité aux utilisateurs, l’administrateur système les désignera chaque utilisateur comme utilisateur complet ou limité.

La liste suivante des tables ne comptent pas pour le maximum de trois tables autorisées pour les utilisateurs limités dans Microsoft Dynamics NAV.

 

N° Table Nom de la Table   N° Table Nom de la Table
18 Customer 5065 Interaction Log Entry
19 Cust. Invoice Disc. 5072 Campaign Entry
23 Vendor 5075 Logged Segment
24 Vendor Invoice Disc. 5078 Segment History
36 Sales Header 5080 To-do
37 Sales Line 5086 Cont. Duplicate Search String
38 Purchase Header 5092 Opportunity
39 Purchase Line 5093 Opportunity Entry
43 Purch. Comment Line 5106 Document Dimension Archive
44 Sales Comment Line 5107 Sales Header Archive
51 User Time Register 5108 Sales Line Archive
97 Comment Line 5109 Purchase Header Archive
130 Incoming Document 5110 Purchase Line Archive
133 Incoming Document Attachment 5123 Inter. Log Entry Comment Line
222 Ship-to Address 5125 Purch. Comment Line Archive
224 Order Address 5126 Sales Comment Line Archive
225 Post Code 5127 Deferral Header Archive
249 VAT Registration Log 5128 Deferral Line Archive
308 No. Series 5150 Integration Page
309 No. Series Line 5151 Integration Record
336 Tracking Specification 5199 Attendee
337 Reservation Entry 5200 Employee
348 Dimension 5201 Alternative Address
355 Dimension Ledger Entry 5203 Employee Qualifications
356 Journal Line Dimension 5205 Employee Relative
357 Document Dimension 5207 Employee Absence
358 Production Document Dimension 5214 Misc. Article Information
359 Posted Document Dimension 5648 FA Allocation Dimension
361 G/L Budget Dimension 5765 Warehouse Request
389 Service Contract Dimension 5766 Warehouse Activity Header
405 Change Log Entry 5772 Registered Whse. Activity Hdr.
454 Approval Entry 5773 Registered Whse. Activity Line
455 Approval Comment Line 5806 Contact Duplicate Search
480 Dimension Set Entry 5809 Item Charge Assignment (Sales)
481 Dimension Set Tree Node 5814 Inventory Period
487 Business Chart User Setup 6550 Whse. Item Tracking Line
760 Trailing Sales Orders Setup 7002 Sales Price
762 Account Schedules Chart Setup 7004 Sales Line Discount
763 Acc. Sched. Chart Setup Line 7012 Purchase Price
770 Analysis Report Chart Setup 7014 Purchase Line Discount
771 Analysis Report Chart Line 7135 Item Budget Dimension
869 Cash Flow Chart Setup 7310 Warehouse Journal Batch
900 Assembly Header 7311 Warehouse Journal Line
901 Assembly Line 7312 Warehouse Entry
904 Assemble-to-Order Link 7313 Warehouse Register
906 Assembly Comment Line 7318 Posted Whse. Receipt Header
950 Time Sheet Header 7319 Posted Whse. Receipt Line
951 Time Sheet Line 7320 Warehouse Shipment Header
952 Time Sheet Detail 7321 Warehouse Shipment Line
953 Time Sheet Comment Line 7322 Posted Whse. Shipment Header
954 Time Sheet Header Archive 7323 Posted Whse. Shipment Line
955 Time Sheet Line Archive 7324 Whse. Put-away Request

Liste des tables ne rentrant pas dans le maximum de 3 tables autorisées

 

Utilisateur limité

Utilisateur limité

 

4. Starter Pack :

S’adresse aux entreprises qui ont besoin des fonctionnalités de base. C’est le moyen le plus rapide et le plus abordable pour démarrer avec Microsoft Dynamics NAV 2016. Le Starter Pack propose les fonctionnalités de base en Finances, Distribution et Services professionnels, ainsi que trois licences Utilisateur complet. Les fonctionnalités de base du Starter Pack permettent :

  • Gestion financière (comptabilité générale et immobilisations).
  • Gestion des achats.
  • Gestion des ventes.
  • Gestion des stocks.
  • Gestion de projet.
  • Le Payement et la gestion les employés.
  • Gestion de la facturation.
  • Gestion de base de la relation client (CRM) pour gérer le suivi avec les clients et les fournisseurs, et offrir le plus haut niveau de service et de support.
  • Gestion de la chaîne logistique.
  • De nombreux rapports et analyses.

Le Starter Pack inclut de nombreux outils pour adapter la solution aux besoins du client et pour faciliter l’intégration via des services web. Pour beaucoup d’entreprises, cette licence est suffisante.

 

Starter Pack

Starter Pack

 

5. Extended Pack :

S’adresse aux entreprises en pleine expansion, de taille plus importante, qui recherche une solution évolutive équipée de nombreuses fonctionnalités. Si ces entreprises ont besoin de fonctionnalités supplémentaires, elles peuvent acquérir en option l’Extended Pack. L’Extended Pack ajoute aux modules Finances et Distribution les fonctionnalités suivantes :

  • Gestion de production.
  • Gestion de l’entrepôt.

Les trois premiers utilisateurs complets inclus dans le Starter Pack donnent accès à toutes les fonctionnalités. Ce pack inclut aussi des objets supplémentaires personnalisables.

 

Extended Pack

Extended Pack

 

Le Starter Pack est un prérequis indispensable pour l’Extended Pack. Après l’achat de l’Extended Pack, ses fonctionnalités sont accessibles à tous les utilisateurs actuels et futurs du client.

L’histoire de Navision a commencé en 1983 à Copenhague. Une entreprise de logiciels danoise PC&C a été fondée, en 1984 elle a publié une solution de comptabilité financière PCPLUS.

En 1987 a vu la première mise à jour de PCPLUS avec Navision 1.0 La différence par rapport à la version précédente était que le logiciel pourrait maintenant être utilisé comme une application client/ serveur via une connexion LAN. Le produit a souvent été appelé IBM Navigator ou Navigator au Danemark parce qu’il a été distribué via IBM Business Center.

 

Navision 1.0

Navision 1.0

 

Navision 3.0, successeur de Navision 1.0, est entré sur le marché en 1990. Le C/AL (Langage d’application) a été introduit avec cette version, basée sur le langage de développement PASCAL. Navision 3.0 était unique à l’époque. PC&C a changé son nom pour Navision Software A/S deux ans plus tard en 1992.

Navision A/S a présenté le premier logiciel ERP appelé Navision Financials 1.0 sur le marché en 1995 en étroite collaboration avec Microsoft. La version Navision Attain 3.10 a été lancée en 2002. La coopération avec les clients professionnels a été optimisée dans cette version. Navision devient Microsoft Navision.

 

Navision Financials

Navision Financials

 

Après plusieurs années de coopération réussie, Microsoft a acquis Navision Software A/S en 2002 et l’a intégré dans la division commerciale Microsoft Business Solutions. Les applications Navision ont été intégrées dans le portefeuille de produits avec les noms Microsoft Navision et Microsoft Axapta. Comme Navision Software A/S produit principalement des logiciels pour petites et moyennes entreprises, Microsoft a complété sa gamme de produits Business Solutions. L’ancien siège de Navision Software A/S à Vedbaek, au Danemark, est devenu le siège de l’EMEA (Europe, Moyen-Orient et Afrique) de Microsoft Business Solutions.

Microsoft a changé le nom de produit de ses solutions Navision en 2005. Axapta est devenu Microsoft Dynamics AX et Microsoft Navision est devenu Microsoft Dynamics NAV. Microsoft Dynamics NAV 5.0 a été publié en mars 2007. Cette version offrait des fonctionnalités globales de business intelligence, entre autres, et a soutenu la coopération entre les employés, les clients et les partenaires sur la base de la technologie SharePoint.

 

Dynamics NAV 5.0

Dynamics NAV 5.0

 

La version Microsoft Dynamics NAV 2009 a offert le Client RTC (Role Tailored Client) en plus du Client classique, permettant à l’utilisateur d’organiser le logiciel en fonction de son rôle dans l’entreprise.

Microsoft Dynamics Nav 2009 est toujours la solution standard dans de nombreuses petites et moyennes entreprises. Il est idéal pour les entreprises de 1 à 249 utilisateurs. Cependant, nous avons également eu des rapports sur les implémentations où il y avait plus de 249 utilisateurs. Microsoft Dynamics Nav couvre la gestion commerciale des unités organisationnelles dans une petite ou moyenne entreprise: gestion de données de base, gestion de matériaux (achats, entreposage, planification, évaluation), ventes (y compris CRM, marketing), production, service, gestion de projet, La gestion des ressources, la gestion des ressources humaines, la gestion financière et la comptabilité ainsi que le contrôle.

 

Microsoft Dynamics 2009

Microsoft Dynamics 2009

 

La version actuelle, publiée en octobre 2012, s’appelle Microsoft Dynamics NAV 2013. Le nom du produit se réfère à l’année de publication. Le travail sur mesure qui a été soutenu depuis 2009 continue d’être optimisé avec l’arrêt du Classique Client. Les nouveaux développements majeurs comprennent les options d’accès avancé avec l’introduction du client Web.

 

Microsoft Dynamics NAV 2013 R2

Microsoft Dynamics NAV 2013 R2

La version actuelle, publiée en octobre 2012, s’appelle Microsoft Dynamics NAV 2013 R2. Le nom du produit se réfère à l’année de publication. Le travail sur mesure qui a été soutenu depuis 2009 continue d’être optimisé avec l’arrêt du Classique Client. Les nouveaux développements majeurs comprennent les options d’accès avancé avec l’introduction du client Web.

En octobre 2014, Microsoft a lancé Dynamics NAV 2015. Les améliorations de cette version comportent le client de la tablette, les rapports de documents à l’aide de Microsoft Word, l’intégration de banque et plus encore.

Publiée le 5 octobre 2015, s’appelle Microsoft Dynamics NAV 2016. Beaucoup de nouvelles fonctionnalités ont été ajoutées, La version a introduit un nouvel éditeur de code, en remplacement de l’ancien, qui était plus ou moins inchangé depuis la sortie de la première version Windows de NAV. Le nouvel éditeur a introduit IntelliSense similaire à ce qui était connu dans la plupart des environnements de développement, tels que Visual Studio. Le client Web a été amélioré sur plus de 60 points. L’introduction d’une application universelle (Universal App), qui signifie, une seule application pour tous les appareils. Elle sert comme une application tablette (en mode tablette), une application de téléphone sur un téléphone. L’une des plus grandes nouveautés dans NAV 2016, basé sur la gestion des événements est la gestion des flux de travail (Workflow).

 

Microsoft Dynamics NAV 2016

Microsoft Dynamics NAV 2016

 

Les versions 2013 R2, NAV2015 et NAV2016 ont presque le même espace de travail (interface utilisateur) avec quelque modification mineure.

Les dernières versions de l’ERP Dynamics NAV est la version NAV2017, NAV2018 et Business Central elles intègres un ensemble de fonctionnalités orientés mobilité : Client Web, client Tablettes et Client Smartphones (sous Android, Apple iOS et Windows). L’interopérabilité des dernières versions de  Dynamics NAV avec la suite Office365 (et ses composants) sont également optimisées, tant au niveau de Word et Excel, que de SharePoint, Exchange ou Power BI.

 

Les différentes versions de NAV

Les différentes versions de NAV

 

Depuis la version NAV2013, la solution est disponible en mode souscription, c’est-à-dire en facturation à l’usage (tarif par mois et par utilisateur), permettant une plus grande flexibilité de la solution. Couplé à la solution d’hébergement Cloud Microsoft Azure, NAV2015, NAV2016,NAV2017,NAV2018 et Business Central sont ainsi disponibles en véritable mode SaaS (Software as a Service), avec une facturation à l’usage (par mois et par utilisateur) sans engagement.

La conception des dernières versions de Dynamics NAV permet aux utilisateurs de travaillé sur Azure. En opérant sur un ERP sur Azure, les utilisateurs peuvent s’attendre à des améliorations en termes de disponibilité et de fiabilité du système. De plus, comme Azure est accessible depuis n’importe où avec une connexion Internet, les utilisateurs peuvent collecter les informations dont ils ont besoin dans le monde entier et effectuer des analyses en temps réel.

 

Dynamics NAV sur Azure

Dynamics NAV sur Azure

L’interface utilisateur NAV est conçue pour être orientée rôle (également appelée Tableau de bord). Ce tableau de bord est le point central où se trouvent toutes les informations et les actions effectuées dans Microsoft Dynamics Nav. Il offre un aperçu rapide des tâches et des transactions liées à la fonction de l’utilisateur. Le tableau qui suit présente les différents boutons, liens et menus du Tableau de bord, lesquels permettent de naviguer dans Microsoft Dynamics NAV.

La navigation dans l’interface utilisateur est simple. Il suffit de cliquer sur une icône pour y accéder. Les options disponibles permettent d’entrer ou de mettre à jour des données, d’utiliser des filtres et d’accéder à d’autres transactions.

Microsoft Dynamics NAV fonctionne dans plusieurs langues. Cela signifie qu’une version localisée de Microsoft Dynamics NAV peut se présenter dans différentes langues. L’utilisateur peut modifier la langue utilisée et le changement prend effet immédiatement.

Si l’accès de l’utilisateur est effectué via le client Windows, le client Web, le client Tablet ou Smartphone, le Role Tailored Client (RTC) sera utilisé. Si l’accès de l’utilisateur est via SharePoint ou un autre client, le développeur aura plus de responsabilités pour s’assurer que l’interface de l’utilisateur est adaptée au rôle.

 

Rôle Directeur des ventes dans le RTC

Rôle Directeur des ventes dans le RTC

 

1. Personnalisation du Tableau de bord :

Le Tableau de bord est comparable à une page d’accueil personnelle dans Microsoft Dynamics NAV. Microsoft a conçu un certain nombre de tableaux de bord pour les utilisateurs qui exercent des fonctions différentes dans une entreprise. L’administrateur affecte un rôle puis personnalise le Tableau de bord afin de s’assurer qu’il contient les informations nécessaires correspondantes.
On peut ensuite apporter d’autres modifications afin d’adapter l’interface utilisateur à nos habitudes de travail. Changements possibles dans le Tableau de bord :

  • Personnalisation du volet de navigation
  • Personnalisation du volet Actions
  • Personnalisation du volet Récapitulatif
  • Ajout et suppression de volets
  • Personnalisation des organisateurs

 

Interface utilisateur RTC de NAV

Interface utilisateur RTC de NAV

 

Les éléments de l’interface utilisateur de NAV

 

Tout utilisateur de Microsoft Dynamics NAV doit savoir comment naviguer dans le Tableau de bord, les volets de navigation et les différentes fenêtres. Il doit également maîtriser les fonctions de base permettant de traiter les données. Une fois ces connaissances préalables acquises, il peut alors utiliser les fonctionnalités plus particulièrement liées aux opérations commerciales offertes par le système.