ETUDE PREALABLE

Phase EP.1 Analyse des besoins - Diagnostic

EP.1.1 Objectifs

 prendre connaissance de l'existant; le décrire

La valeur ajoutée de la prise de connaissance est de structurer progressivement le domaine selon une logique propre à être adaptée au processus basés sur le web: traitements, données, règles de gestion.

L'étude de l'existant doit toujours être limitée à l'essentiel. Elle ne peut être une description exhaustive de tous les détails de fonctionnement actuel. Il est cependant indispensable que l'analyse des besoins repose sur une connaissance suffisante de l'existant

 identifier tous les besoins

besoins de traitement

besoins en informations de gestion

besoins en informations marketing

 rassembler toute la documentation nécessaire pour une future étude détaillée

 permettre à tous les intervenants d'avoir une connaissance globale du domaine à traiter.

EP.1.2 Activités de réalisation

 Etude de l'existant et des besoins nouveaux :

Comme dans la phase d'observation du schéma directeur, mais le périmètre est limité au domaine de l'étude et celle-ci est plus approfondie.

 Compléter les études de marché

Identifier avec précision les niches client / produit et décrire:

• leur importance, en nombre d'individus ;
• leur potentiel d'achat global ;
• leur degré d'acceptation vis-à-vis de l'e-commerce ;
• leur potentiel d'achat par e-commerce ;
• finalement, leur potentiel de revenu e-commerce.

 Structurer logiquement & décrire

 Structurer l'information à publier (orienter l'analyse vers une présentation par pages)

identifier quels types d'informations doivent être publiés:

• décrire cette information :
• • uniquement des données structurée
  • uniquement du texte libre et des graphiques
  • combinaison de données structurée, de zones de textes et de graphiques
• localiser les sources cette information :
• • base de données existante / à créer / à modifier
  • autres données informatiques
  • pas d'origine informatique

Définir quelles informations doivent être gérées dans les bases de données de l'entreprise, (elles seront considérées comme des données d'entreprise), et quelle partie de l'information doit être traitée indépendamment.

 Structurer les traitements: découper le domaine en applications, systèmes et fonctions et les décrire

 sélectionner les cas représentatifs, normaux; ne pas tenir compte des exceptions à ce stade-ci de l'analyse

La sélection dépend du type d'objectif poursuivi: il y a une différence entre une procédure de masse parfois simplifiée à l'extrème (cas de la production et stockage de latex blanc dans une fabrique de peinture ou de l'achat et stockage de malt dans une brasserie), et les procédures normales, traitant des cas moins massifs mais plus nombreux. Malgré qu'elles traitent une part importante de l'activité, ces procédures de masse ne sont pas nécessairement représentatives de la façon dont il faut gérer les activités 'normales'.

  mettre l'accent sur les fonctions à assurer ("Que faut-il faire ?"), et non sur les procédures suivies actuellement ("Comment le fait-on ?")

La description des fonctions remplace avantageusement la description des traitements proprement dits à ce stade de l'analyse. En effet,

Les fonctions pourront être réalisées de plusieurs façons, par des procédures différentes

On a intérêt, dès le stade de la description de la situation existante, à s'élever au dessus des us & coutumes actuels pour dégager une solution nouvelle à un niveau d'abstraction plus élevé. Cette description sera plus susceptible d'évolution que sa version pratique.

Une description détaillée des traitements coûte cher et n'est souvent pas recommandée ni utile.

identifier et décrire les acteurs et les responsabilités.

identifier et décrire les traitements déjà informatisés

 Structurer les données:

identifier les blocs d'informations nécessaires (data store) et les entités principales

commencer la procédure de normalisation

 Structurer les règles de gestion:

p.ex. sous forme de table de décision

identifier les imprécisions, les contradictions, les questions.

 Compléter le schéma directeur

aller plus en détail

combler les lacunes éventuelles du schéma directeur

 Etablir l'inventaire précis des besoins

besoins de traitement

besoins d'informations marketing et de gestion

 Décrire les ressources disponibles

sites web, noms de domaine, services d'hébergement

sites informatiques, serveurs, réseaux, répartition des applications, interfaces

il peut être utile de détailler les possibilités techniques offertes par une nouvelle architecture dans le cadre de l'application à traiter.

 Conclusions:

Formuler un diagnostic précis sur le domaine.

Déterminer les nouvelles orientations de façon plus précise que le schéma directeur

EP.1.3 Activités de gestion de projet

 Proposer un plan d'action pour la phase suivante

EP.1.4 Activités d'assurance qualité

 Contrôle par relecture, simple ou croisée

 Facteurs clefs

identifier et prendre en compte toutes les sources d'information nécessaires

faire un brainstorming efficace pour imaginer l'évolution future.

 L'identification correcte des besoins est la base de l'assurance qualité des étapes suivantes.

l'inventaire des besoins identifiés durant cette phase servira de base de contrôle aux réalisations ultérieures; exprimer les besoins sous une forme systématique, réexploitable dans le contrôle de la qualité de la phase de conception.

veiller, au niveau des besoins en information de gestion, à identifier des rapports permettant un contrôle synthétique, global et croisé des diverses facettes de l'application. Ces outils serviront notamment aux tests durant les phases de réalisation et de lancement.

EP.1.5 Activités de clôture

  A l'issue de cette phase, on doit disposer de:

 inventaire complet de toute la documentation de référence

 description du système actuel

 inventaire systématique des besoins

besoins de traitement (opérationnel)

besoins en informations de gestion et marketing (contrôle et pilotage)

  A l'issue de cette phase, doivent être précisés:

 les objectifs du futur système

de préférence exprimés sous une forme objective et vérifiable.

par exemple :

• réduire les coûts du service clientèle de 30% en 24 mois;
• obtenir 25% du chiffre d'affaires par le canal e-commerce dans les 2 ans;
• retenir 10% des visiteurs en ligne comme clients réguliers

 les contraintes du futur système et de l'évolution

 un scénario du système cible

 un plan d'action (scénario d'évolution)

moyens: budgets, délais, disponibilités, groupes de travail...