ITIL, SAP Solution Manager, ASAP et RunSAP

English Version : drapeau_uk.gif

Philippe MARQUE

SAP Solution Manager.jpg

ITIL Service Delivery.jpg

ITIL Service Support.jpg

PMBOK.jpg
La méthodologie ASAP par rapport à ITIL

Depuis 1999, la méthodologie ASAP structure les projets d’implémentation de SAP en 5 phases :

  1. la préparation du projet, avec la définition du planning et la réunion de lancement (Kick-off),
  2. la Business Blueprint, avec la définition des besoins,
  3. la réalisation, avec la construction de la solution et les tests d’intégration,
  4. la préparation de la mise en production, avec la formation des utilisateurs finaux et la bascule (le cut-over),
  5. le démarrage et le support, avec la mise en production et la prise en charge de la solution par le support.

ASAP est conforme aux bonnes pratiques de gestion de projet définies par le PMI (Project Management Institute) dans le guide PMBOK (Project Management Body of Knowledge). Mais ASAP ne permet pas de gérer l’après-démarrage comme le permet le modèle ITIL avec :

  • le centre de support,
  • la gestion des incidents,
  • la gestion des problèmes,
  • la gestion des changements.

SAP Solution Manager et la méthodologie RunSAP

Présentée en 2008, la nouvelle méthodologie RunSAP est une sorte de méthodologie ASAP pour mettre en place ou gérer un département informatique ou un Centre de Compétence, que SAP appelle désormais un Customer Center of Expertise.

RunSAP est constitué de Standards proposés par SAP Solution Manager 7.0. Chaque standard contient les bonnes pratiques et les explications sur les outils adéquats dans Solution Manager pour mener à bien chaque tâche :

  1. End-user support
    • la gestion des incidents (incident management),
  2. Change management
    • la gestion des demandes de modification (change request management),
    • la gestion des contrôles de modification (change control management),
    • la gestion des test (test management),
    • les montées de version (upgrade change).
  3. Application management
    • la documentation (solution documentation),
    • le support à distance (remote supportability),
    • la recherche de l’origine des problèmes (root cause analysis),
  4. Business process operations
    • la gestion des exceptions (exception handling),
    • la gestion des processus de gestion et des interfaces (business process and interface monitoring),
    • la gestion du volume des données (data volume management),
    • la gestion de la planification des jobs (job scheduling management),
    • la cohérence des transactions (transactional consistency),
    • l’intégrité des données (data integrity management),
  5. Technical operations
    • l’administration du système (system administration),
    • la surveillance du système (system monitoring),

SAP Solution Manager en pratique

Solution Manager peut être utilisé de plusieurs façons. Voici celles que j'ai rencontrées sur les projets auxquels j'ai participé :

  • Gestion documentaire

    • C'est par là que commencent beaucoup de clients : l'ensemble de la documentation des projets SAP est regroupée dans Solman. Pour un processus donné, on peut ainsi classer les documents selon leur usage : documentation générale du projet, spécifications fonctionnelles, scénarii de tests, ...

  • Gestion centralisée des autorisations (central user administration)

    • Solman permet de recenser tous les systèmes SAP de l'entreprise et de gérer de façon centralisée les autorisations des utilisateurs : la mise à jour d'un profil utilisateur sur Solman peut être répliquée sur plusieurs systèmes (développement, qualité, ...) via ALE.

  • Gestion des modifications

    • Une Enhancement Request (ER) est crée par un key-user ou un BPO (Business Process Owner).
    • En faisant évoluer les statut de l'ER, le centre de compétence (niveau 2 ou 3) est informé de la demande, fait une analyse et propose une solution accompagnée d'une estimation de coût pour la réalisation.
    • Une fois le chiffrage accepté, une ou plusieurs Change Request (CR) sont créées en référence à l'ER. Les CR permettent au consultants en charge de la réalisation de détailler les spécifications fonctionnelles.
    • La CR doit ensuite être approuvée, toujours via la gestion des statuts, par le Team Leader, estimée par le Development Manager, puis approuvée par l'Integration Manager.
    • Une CD est ensuite générée et prise en charge par un développeur.
    • Les tests sont ensuite effectués, la CD, la CR puis l'ER sont validées et mises en production.

  • Gestion des tests

    • L'équipe projet définit des Test Cases (scénarii de tests) pour valider un processus.
    Lors d'une release ou lors de la phase de test du projet, un Test Plan est créé. C'est une sorte de dossier qui va contenir tous les Test Cases devant être testés par les utilisateurs lors de la série de tests.
    A partir du Test Plan, on peut alors générer un ou plusieurs Test Package, sous-ensemble du test plan qui permet de regrouper fonctionnellement des tests cases ensemble (par exemple les tests cases PTP ou OTC). Le Test Package permet d'enregistrer les noms des utilisateurs qui exécutent les tests et également d'enregistrer les résultats de chaque Test Case.
    Le management du projet peut alors consulter et communiquer facilement les résultats de la phase de tests.

  • Recherche de l'origine des problèmes.

    • Si un processus se déroule un seul système (ECC par exemple), des transactions internes au système en question permettent de rechercher l'origine d'un problème de temps de réponses par exemple. Lorsque le processus se déroule sur plusieurs systèmes (Web, portail, réseau, ECC par exemple), il est plus difficile de rechercher l'origine du problème. Solution manager propose un outil pour celà.


Philippe MARQUE

Consultant SAP utilisant Solution Manager

Certifié ITIL Foundation