0% ont trouvé ce document utile (0 vote)
Analyse des écarts
Télécharger au format docx, pdf ou txt
Télécharger au format docx, pdf ou txt
Télécharger au format docx, pdf ou txt
/ 4
Un écart signifie de petites fissures.
Dans le monde SAP ou dans le monde des technologies de
l'information, l'analyse des écarts est l'étude des différences entre deux systèmes d'information ou
applications différents (ex : un système existant ou hérité avec un client et le nouveau est SAP),
souvent dans le but de déterminer comment passer d'un état à un nouvel état. On parle parfois
d’écart comme de « l’espace entre là où nous sommes et là où nous voulons être ».
L’analyse des écarts est entreprise comme moyen de combler cet espace. L'analyse des écarts
réels prend du temps et joue un rôle essentiel dans l'étape du plan d'entreprise [processus tel quel].
Une analyse approfondie des écarts permettra d'identifier les écarts entre le fonctionnement de
l'entreprise et ses besoins par rapport à ce que le package ne peut pas faire. Pour chaque écart, il y
aura l'un des trois résultats qui devront être enregistrés et mis en œuvre,
1. Le GAP doit être comblé et des logiciels personnalisés peuvent être développés
2. Le GAP doit être comblé mais le logiciel ne peut pas être écrit, une solution de contournement est
donc nécessaire
3. Il n’est pas nécessaire de fermer le GAP.
Un point qui mérite d’être mentionné ici est que parfois les gens confondent les sorties utilisateur et
l’analyse des écarts. Les sorties utilisateur sont des passerelles standard fournies par SAP pour
quitter le code standard et nous pouvons écrire notre propre code à l'aide d'ABAP Workbench, ce
n'est pas une nouvelle fonctionnalité que nous essayons de créer dans SAP mais c'est une légère
amélioration dans le même code.
L'analyse des écarts est le point de départ de la réalisation et une fois le plan directeur de
l'entreprise terminé, nous devons trouver la réalisation du système SAP pour les besoins du client et
il y aura certains écarts par rapport à l'adéquation du système. Ces lacunes peuvent être comblées
soit par une réingénierie des processus métier pour s'adapter à SAP, soit par l'utilisation de sorties
USER en cas de petits écarts ou d'améliorations complètes à l'aide d'ABAP pour s'adapter au
système SAP.
Les écarts peuvent différer d’une entreprise à l’autre. Le plus souvent, cependant, les fonctionnalités
manquantes sont spécifiques à un secteur.
Exemples :
1. MGM Studios et Lycos ont déjà travaillé avec SAP pour développer respectivement ses nouvelles
fonctionnalités de gestion de la propriété intellectuelle et de gestion de la publicité médiatique.
2. Une entreprise leader dans le domaine des produits de soins bucco-dentaires souhaitait
promouvoir des produits gratuits sous la forme « Achetez-en un et recevez 2 produits différents
gratuitement »
Dans les données de base client, l'exigence client nécessite un numéro de client
hérité qui peut être résolu avec la sortie utilisateur.
Dans la commande client, nous avons besoin du numéro de téléphone du client. Nous pouvons
utiliser la sortie
utilisateur si
le client souhaite un nouveau
champ dans la base client, comme la caserne de pompiers la plus proche.
L'analyse GAP est réalisée au stade du Blue Print. L'objectif est
de comprendre ce qui peut être fait avec le SAP standard et comment
le client souhaite réellement qu'un scénario particulier soit
traité.
Il s’agit de comprendre l’écart entre les scénarios réels et
requis.
La différence entre le travail convenu et le travail terminé
est l’analyse des écarts.
Par exemple : pour combler cette lacune, nous utilisons les améliorations, ces
améliorations divisées en sorties, telles que les sorties utilisateur, les sorties de champ
, les sorties d'écran et les sorties de menu. Ces améliorations sont utilisées pour mettre
à jour le programme standard dans ses
transactions commerciales respectives, utilisées comme passerelle pour répondre
aux exigences du client.
Mise en œuvre du projet
En fait, cela dépend de divers facteurs, tels que :
1. combien de modules ils souhaitent implémenter.
2. Taille de l'équipe.
3. Structure organisationnelle (volume de données)
4. Système hérité
5. Complexité des affaires, etc.
Il n’existe pas de règle absolue selon laquelle chaque projet doit être achevé dans un délai précis.
En fonction des facteurs ci-dessus, la durée peut varier entre 6 et 18 mois environ. (Dans certains
cas exceptionnels, elle peut être inférieure à 6 mois ou supérieure à 18 mois).
Habituellement, il est divisé en phases :
1. Préparation du projet : l'équipe du projet, l'infrastructure, le logiciel, le comité de pilotage, etc.
seront identifiés dans cette phase.
2. Business Blue Print : Réingénierie des processus métier et validation du BBP.
3. Réalisation : Analyse des écarts et réalisation des efforts possibles de personnalisation et de
développement
4. Préparation finale et mise en service : développement et configuration
5. Support post-mise en service : Support après la mise en service
Vous attribuerez des périodes de temps spécifiques à chacune de ces phases et fixerez des jalons
en conséquence.
ou cela pourrait même être comme :
Début du projet
Analyse
Conception
Gel de la conception / Approbation du client
Construction
Essai
Mise en œuvre
Fin du projet
Cadre de gestion de projet
Fermer la publication
Entraînement
Gestion du changement
Consultez les liens suivants pour plus d’informations :
http://en.wikipedia.org/wiki/SAP_Implementation
http://www.sapfans.com/sapfans/asap/be_01_e.htm
Il existe différentes versions d’implémentations de projets.
1. Mise en œuvre du modèle - sans grande personnalisation - basée sur un modèle de déploiement
prédéfini
2. Déploiement personnalisé
3. Accélérer le déploiement
4. Améliorations d'une implémentation existante
5. Récupération du projet
Le cycle de vie du projet comprend [1] la charte du projet,[2] la portée,[3] la planification,[4]
l'exécution,[5] le contrôle et [6] la clôture.
La charte vous indique l'objectif du projet, par exemple, éliminer un processus de transmission
coûteux en mettant en œuvre l'EDI.
La portée indique tout ce que vous ferez dans le cadre du projet. Dans SAP, il s'agit d'une
impression bleue.
Planification : Ici, vous planifiez les dépenses d'investissement - budgétisation d'investissement,
dépenses, revenus, ressources et autres éléments qui entrent dans le projet.
projectExecution : Exécution réelle des activités planifiées
Contrôle : Ici, vous orientez le projet vers les objectifs prévus : analyse des écarts, réduction des
coûts, ingénierie de la valeur, budget, normes, suivi rapide, crash, allocation des ressources, etc.,
etc., tous trouvent ici un rôle. Ici, le temps, le coût et les autres ressources sont contrôlés afin de
terminer le projet à temps et dans les limites des coûts de base.
Les tests sont également présents ici : tests unitaires, tests d'intégration, UAT...
Clôture : La signature du projet a lieu ici.
Dans l'environnement de support, le « projet » couvrira a] la gestion des incidents, b] la gestion des
problèmes, c] la gestion des changements, d] la gestion de la configuration, e] la gestion des
versions et f] le service d'assistance.
Taille de l'équipe
L’équipe SAP dépend de l’entreprise concernée avec laquelle vous travaillez.
En termes génériques pour un partenaire de mise en œuvre, par exemple : IBM, PWC TCS,
etc.
L'équipe est composée d'un chef de projet et d'un développeur commercial.
Dans l'équipe, il peut y avoir 1 à 2 consultants pour chaque module (SD, MM, PP, PM, etc.)
avec 1 ou 2 ABAP er et une personne BASIS.
Dans les paies des clients, il peut y avoir 1 à 1 consultant pour chaque
module en fonction des besoins.
Donc, généralement, il y a 3 équipes.
1. Les membres de l’activité principale du client2
. Le consultant en paie de l'entreprise pour la mise en œuvre avant et après et le support3
. Les partenaires de mise en œuvre (équipe de projet)