Gilbert Grenié, consultant expert SAP, nous livre ses recommandations en matière de mise en place d'un système SAP.
Il incite à évaluer, anticiper et éviter les problèmes de performance. Ceci, durant les différentes phases du développement du projet et par conséquent une fois que le système sera complètement opérationnel.
Ces recommandations sont regroupées en fonction des causes possibles de problèmes.

Recommandations sur la stratégie métier

Bien que la stratégie métier devienne une sorte de cadre de référence pour la conception de la solution, il est d’une importance capitale d’évaluer l’impact des changements futurs de la réglementation et de l’organisation de l’entreprise sur le modèle adopté.
Les choix sur le modèle de données et les processus ne doivent pas être faits pour répondre aux conditions actuelles mais doivent être assez flexibles pour prendre en compte les changements des dix prochaines années, durée de vie probable du système.
Une analyse d’impact au niveau stratégique doit donc être menée avec les responsables métiers avant de prendre des décisions techniques sur la conception du système.

Recommandations sur la conception

La plupart des problèmes de performance en phase opérationnelle viennent des erreurs de conception et des développements non optimisés.
Les recommandations suivantes ont pour but d’anticiper et d’éviter les problèmes en appliquant les best practices dans les premières phases du développement.
Les deux éléments qui contribuent à l’atteinte de cet objectif sont :

• l’utilisation des standards de conception et de développement
• les tests intensifs.

On pourra se fixer les règles de conduite suivantes :

• choisir le modèle de données qui convient le mieux à la stratégie métier et à la structure organisationnelle de l’entreprise.
  Les modèles multi-systèmes auront moins de problèmes de performance mais des coûts de développement et de maintenance plus élevés.
• créer une équipe d’experts pour évaluer les alternatives.
  Cette équipe doit inclure des experts de SAP et du fournisseur du système de base de données lorsque cela se révèle nécessaire.
• toujours utiliser des processus et des transactions standards lorsque c’est possible.
• les développements spécifiques doivent être réduits au strict minimum indispensable pour se conformer aux exigences fonctionnelles.
• si les développements spécifiques se révèlent indispensables, isoler les accès aux données du code « fonctionnel » en réalisant une couche d’accès aux données préparée par des experts en base de données qui prendront en compte les problèmes de performance.
• élaborer des règles de développement et des procédures de contrôle qualité pour vérifier les développements sous l’angle de la performance.
• concevoir une stratégie de migration à partir du système existant très tôt dans le projet et évaluer la quantité de données à charger dans le système.
  Ce processus ne doit pas être exécuté lorsque cela devient urgent et doit être testé et optimisé à l’avance pour éviter les goulots d’étranglements qui peuvent compromettre la mise en production du système.
• concevoir un environnement de test complet qui représente les conditions normales de fonctionnement du système avec assez de données pour simuler les pics de charge, et qui peut être réinitialisé après que les tests sont réalisés.

Recommandations sur les technologies

La performance du système intégré devrait être évaluée tôt dans le projet en faisant plusieurs tests de montée en charge avec des simulations de scénarios réels opérationnels et ceci d’autant plus lorsque les transactions « critiques » sont envoyées en phase de test et d’intégration.
Le problème principal réside dans la capacité à créer un environnement de tests dans lequel les bonnes conclusions peuvent être formulées sur le comportement du système en phase de production.
L’erreur qui consiste à vouloir dimensionner les capacités des processeurs et de stockage par une simple extrapolation est très courante.
Pour répondre aux besoins de performance, il faudra :

• sélectionner un fournisseur de matériel en fonction des politiques d’entreprise et une infrastructure technique disponible. Les architectures 2-tiers et 3-tiers sont utilisées dans la mise en œuvre de gros systèmes.
• impliquer les experts des fournisseurs de matériel et de systèmes de base de données avec les experts SAP dans la définition et le dimensionnement du système.
• si cela se révèle indispensable, créer une équipe projet pour faire un réel test de performance aussi proche que possible de la réalité.

Recommandations sur l’organisation de l’équipe projet

En fonction des ressources allouées et de l’organisation de l’équipe projet il faudra :

• sélectionner un intégrateur ayant de l’expérience sur la mise en œuvre de SAP.
  Notamment, la connaissance interne de SAP est nécessaire pour éviter des problèmes de performance.
• sélectionner la bonne équipe intervenante avec un bon niveau d’expérience et de certification.
  Au minimum, 50% des consultants devraient avoir un niveau « senior ».
• inclure des personnes « métier » dans l’équipe et faciliter les circuits de décision.
  Il faut être en mesure de résoudre les problèmes de performance en étant capable d’adapter les fonctions et les processus notamment lorsque le nombre de spécifiques est important.
• mettre en place un groupe technique avec des experts SAP séparés des équipes fonctionnelles, et reportant directement au chef de projet.
  Ce groupe sera responsable de l’infrastructure technique, de la gestion de la configuration et des environnements, du contrôle qualité et des tests de performance des modules fonctionnels (audit technique).
• s’il est nécessaire, créer un projet spécifique pour mettre en œuvre et exécuter les tests de performance reproduisant les scénarios réels. Cette équipe peut être composée d’experts de l’entreprise, du fournisseur des matériels et logiciels, de l’intégrateur et de SAP.
• réaliser des revues périodiques du projet et de la performance par un auditeur externe.
  SAP et quelques cabinets spécialisés offrent ce type de services.

Recommandations sur l'environnement

Il paraît souhaitable d'installer au minimum 4 environnements différents avec les ressources adéquates pour chacun d’entre eux :

• un environnement de développement pour le codage, le paramétrage et les tests unitaires des modules fonctionnels,
• un environnement d’intégration et de tests du système, des processus métier et des interfaces,
• un environnement de tests de performance pour effectuer des tests de performance en masse à certaines étapes du projet,
• un environnement de production :
  - définir les procédures pour passer d’un environnement à un autre,
  - sélectionner quel environnement sera utilisé pour la formation et faire attention à la performance de ce système : ne pas oublier que la première impression des utilisateurs sur le système se fait pendant cette phase de formation.

Recommandations en phase opérationnelle

Une fois le système en production, les problèmes de performance sont plus difficiles à résoudre, donc un monitoring permanent sur le comportement du système est nécessaire pour anticiper des problèmes potentiels et les résoudre avant qu’ils aient un impact sur l’activité métier.
Les recommandations suivantes aideront à identifier et à anticiper les risques potentiels :

• maintenir une équipe technique pour surveiller la performance du système de manière périodique,
• réaliser des audits techniques de performance du système par un expert externe,
• surveiller la dégradation de la base de données par une revue des statistiques d’utilisation (temps d’accès, latence, dimension des tables, niveau d’indexation des tables…),
• planifier des restructurations périodiques des tables,
• élaborer des plans de continuité de service pour les sauvegardes et les restaurations.

 
 
D'après Gilbert Grenié, directeur associé, spécialiste centre de compétences SAP chez ASK Conseil.