Dans la majorité des cas la montée de version SAP est un projet technique. Cela nécessite de confier des chantiers plutôt bien maîtrisés aux principaux infogérants du marché. Il peut s’agir de migration du système d’exploitation ou de la base de données, de passage en 64 bits, de redéploiement du paysage système SAP (instances, environnements SAP et dimensionnement des serveurs selon l’approche SAPS préconisée par l’éditeur). Le projet de montée de version vers SAP ERP 6 s’inscrit alors dans un plan de transformation de l’architecture SAP qui, une fois modernisée et en ordre de marché, sera à même de supporter les évolutions planifiées.

Un but : contribuer à l’amélioration des niveaux de services

Une fois la montée de version réalisée (palier 1), les infogérants sont aussi à même d’accompagner les DSI dans la réalisation de leur plan stratégique autour de SAP (paliers suivants) : • alignement des ressources (CPU, RAM, mémoire disque) sur la montée en charge des utilisateurs SAP (projets de déploiement des solutions SAP – Capacity Planning), • lancement de nouveaux projets qui nécessitent une forte réactivité dans la mise en place de paysages et environnements SAP - parfois provisoires (projets de convergence de Core Model SAP, projet de séparation d’une instance SAP en plusieurs instances afin de coller au mieux au Modèle d’Entreprise,…..), • déploiement de nouveaux composants qui nécessitent la conception et le déploiement d’une architecture qui s’appuie sur la plate-forme Netweaver (exemple : Portail d’Entreprise, Business Intelligence, CRM, SAP XI…), • amélioration des processus opérationnels dans le domaine de la gestion des services qui contribuent à l’amélioration des niveaux de services (gestion des incidents/problèmes, gestion des mises en production, gestion des versions de(s) solution(s) SAP,…). Le choix d’un tel partenaire engage la DSI et l’Entreprise sur plusieurs années (des contrats entre 3 et 7 ans).

Le dossier de consultation, outil de sélection incontournable

Il convient donc de bâtir un dossier de consultation solide avec plusieurs grandes caractéristiques. Il y a deux approches pour choisir sa stratégie de consultation. Soit une consultation de type RFI ou « Request for Information » et, dans un premier temps, procéder à une sélection de prestataires au moyen d’un dossier de consultation allégé. Les candidats présélectionnés (short listés) recevront dans un deuxième temps le dossier de consultation final approfondi qui permettra de les départager. Le seconde approche consiste en une consultation de type RFP ou « Request for Purchase » : la consultation est large et réalisée au moyen d’un dossier de sélection complet et exhaustif dès le début du projet. Le dossier de consultation est l’outil de sélection incontournable qui sera annexé au contrat d’infogérance et qui doit, au minimum, inclure plusieurs parties : • Présentation du contexte et des enjeux du projet d’infogérance (objet de l’appel d’offre). Voici quelques exemples d’enjeux associés à un projet d’infogérance SAP : - supporter la croissance (montée en charge des utilisateurs), - améliorer les performances globales et de certaines transactions critiques, - être en mesure de spécialiser des instances par branche ou métier (scinder l’instance SAP en plusieurs instances), - limiter les impacts de tests de non régression sur la population des utilisateurs concernés (limitation des tests aux instances concernées), - avoir plus de souplesse et de flexibilité dans le déploiement et l’activation d’autres composants SAP (SAP BI, SAP PLM, SAP PORTAL), - avoir plus de souplesse dans la gestion des plans batch (meilleure répartition de la charge à travers plusieurs plans batch), - limiter les risques relatifs aux développements et à leur exploitation en production (limitation des risques aux mandants/ instances concernés), - réduire les coûts d’hébergement, d’exploitation/administration et améliorer les niveaux de service (libérer les équipes de tâches d’exploitation courantes et réorienter les efforts et compétences sur les projets à venir), - améliorer le plan de continuité des services SAP (mise en place d’un Plan de Secours). • Déroulement du projet de consultation (étapes, jalons, critères de choix, interlocuteurs,…). • Le contexte général et technique (organisation du CC SAP, architecture existante et contraintes techniques, liste des applications dans le périmètre d’infogérance, les données de volumétrie,….) à préciser aux candidats : - l’organisation du CC SAP (organigramme, fonctions & missions, effectif) - le noyau R/3 ou ECC (modules), les composants SAP déployés (BI, CRM, Solution Manager,…..) et les applications connexes dans le périmètre d’infogérance, - la liste des sites et les utilisateurs concernés (périmètre d’externalisation), - le paysage système SAP (instances et environnements SAP), - les plates-formes et configurations matérielles existantes, - la dimension réseau WAN, - les données de volumétrie (utilisateurs assidus / occasionnels, taille des bases de données de production, nombre d’interfaces entre SAP et les solutions non SAP, liste des traitements planifiés, la moyenne mensuelle des demandes de transport SAP,……) • Les prestations attendues et les niveaux de services associés : - le pilotage du contrat et le management des services (Service Management), - l’acquisition et la fourniture du matériel (incluant la maintenance), - l’hébergement, - l’exploitation SAP (ensemble des activités récurrentes assurant le fonctionnement des systèmes informatiques, comprenant les instances système, les systèmes applicatifs et le réseau local central), - l’administration SAP (ensemble des activités, récurrentes et en mode projet, contribuant à maintenir opérationnel l’environnement d’exploitation des systèmes informatiques comprenant les instances système, les systèmes applicatifs et le réseau local central ; les prestations d’administration mettent en place l’environnement nécessaire à l’exécution des prestations d’exploitation et apportent l’expertise nécessaire au maintien de la continuité de fonctionnement et des niveaux de performance, - le Plan de Secours ou « DRP » (Disaster Recovery Plan), - la gestion du réseau local central, - l’ensemble de prestations de type « pay per use » et/ou « On demand » (catalogue de prestations facturées à l’utilisation selon des unités d’œuvre à définir).

Des prestations formalisées dans un catalogue

Plusieurs prestations SAP de type « pay per use » et » On Demand » peuvent être incluse dans un appel d’offre infogérance SAP. Il s’agit de prestations formalisées dans un catalogue proposé au prestataire, qui sont activables sur demande et facturées à l’utilisation (exemple : mise à disposition d’une ligne de développement SAP sur x mois composée des environnements de DEV/Qualité, déploiement d’une instance SAP BI pour 200 utilisateurs, liste de travaux d’exploitation précisés avec des quantités sur une période donnée,…,…). Tout l’exercice consiste à rapprocher le plan stratégie SAP de prestations en découlant et pouvant être confiées au futur partenaire. Il convient de préciser les modalités d’activation de ces prestations et les délais associés (demande d’activation émise en comité de pilotage par exemple, délai de mise en service à partir de la réception de la demande,…)

Le prix des prestations est lié aux niveaux de service

Il faut aussi définir les niveaux de services attendus qui feront l’objet d’un suivi rigoureux tout au long de la vie du contrat : o Amplitude des services (24/24 7/7,….). o Performances (x% des transactions SAP < y secondes). o Le délai de remise en service du DRP (après activation du plan de secours enclenché par la cellule de crise – exemple : < 6 heures). o La quantité de données perdues « acceptable » lors de la remise en service (exemple : maximum de 2 heures de données saisies perdues entre l’arrêt du système et le redémarrage via le plan de secours). o Le taux de disponibilité des systèmes SAP (exemple : taux de 99,95%). o Le nombre maximum d’incidents, entraînant une indisponibilité complète du système, tolérés sur un mois. o La durée maximum d’indisponibilité liée à un incident en période courante. Le prix des prestations est étroitement lié aux niveaux de services souhaités. A titre d’exemple, une revue à la baisse de la durée maximum d’indisponibilité liée à un incident en période courante (2 heures au lieu de 30 mn initialement escompté) a réduit le coût du service de 48 euros /utilisateur/an (contrat d’infogérance – base 500 utilisateurs). Enfin, il convient de préciser la durée du contrat, le calendrier souhaité de mise en place des services ainsi que les principaux points à caractère contractuel qui seront repris et développés dans le contrat d’infogérance (pénalités, résiliation, réversibilité,…).

Le cadre de réponse : un outil indispensable pour le dépouillement des offres

Il est recommandé d’inviter vivement les soumissionnaires à répondre selon un cadre de réponse prédéfini qui permettra d’évaluer, comparer et classer les offres des candidats. Le cadre de réponse engage le soumissionnaire et il pourra aussi être annexé au contrat d’infogérance. Les réponses attendues sont à rapprocher des critères de choix qui auront été préalablement définis au lancement du projet. Dès lors, le cadre de réponse à un appel d’offre infogérance SAP doit inclure au minimum : • Une présentation de la société candidate (métiers et activités, données chiffrées, actionnariat & partenariats, prestations d’infogérances au catalogue, au moins 3 références dans des contextes clients similaires, présentation des sites d’infogérance et des niveaux de sécurité associés,…) • La présentation de la phase de mise en place des services (qui inclut parfois la transformation du paysage système SAP) • L’organisation et la coordination des modes projet et infogérance si le contexte de l’appel d’offre le nécessite (comment est organisé le prestataire qui doit à la fois délivrer et exploiter ?) • Les moyens et méthodes mis en œuvre par l’infogérant pour chacune des prestations (outils et pratiques, certifications du personnel à ITIL,….) avec un zoom particulier sur la gestion des incidents/problèmes et des mises en production • Le modèle de PQI standard (Plan Qualité Infogérance) • Les modèles de tableaux de bord et reporting qui attestent du bon suivi des prestations et niveaux de service associés • Un modèle de contrat d’infogérance (le contrat standard traduit souvent l’état d’esprit du prestataire…) • Un tableau de valorisation des prestations souhaitées qui permet d’avoir une bonne compréhension du prix de chaque prestation par tranche d’utilisateurs et par année du contrat si possible. PLANNING D’UN PROJET D’EXTERNALISATION

Agrandir l'image

Il convient de gérer la phase de sélection du partenaire infogérant comme un véritable projet qui nécessite : - la constitution d’une équipe projet (responsable du CC SAP, les principaux managers du CC SAP et un représentant des utilisateurs si possible) qui a pour mission d’exprimer les besoins, de dépouiller et classer les offres des candidats afin d’établir un dossier de choix qui permettra au comité de pilotage de décider, - l’élaboration d’un plan projet (planning, principaux jalons, livrables) - un comité de pilotage qui choisit l’infogérant sur la base du dossier de choix communiqué par l’équipe projet (comité de pilotage composé de représentant de la gouvernance du SI dont le DSI, le DG et/ou le Directeur Financier) - un suivi du projet au moyen d’une ressources « PMO » (bureau des projets) allouée au projet (planification et suivi du projet, animation du comité de notation, reporting,…) LE PLAN DE DÉPLOIEMENT STRATÉGIQUE

Agrandir l'image

Plan de déploiement des opportunités stratégiques de SAP ECC 6.0 dont certaines sont étroitement liées à la transformation du paysage système SAP. Voila quelques bonnes pratiques de gouvernance du SI appliquées à un projet d’infogérance : - Impliquer si possible un représentant métier afin de définir les objectifs métiers du projet d’externalisation et de les décliner en objectifs informatiques, - Aligner le projet d’infogérance sur le plan stratégique SAP (montée en charge des utilisateurs et projets à venir) - Bâtir un Business Case du projet (sur la durée du contrat) qui justifie la décision: o Investissement : coûts de mise service et de transformation du paysage système SAP (incluant le projet d’upgrade technique SAP lorsque il est réalisé par l’infogérant retenu), o Charges : coûts d’hébergement, d’exploitation et d’administration des systèmes, coût du réseau local central, coût du transfert / réversibilité en fin de contrat, o Détailler autant que possible le coût de chaque prestation souhaitée et trouver les bons ratios qui parleront au Comité de Pilotage (prix par utilisateur et par mois sur la durée du contrat,…) o Identifier et mettre en évidence les gains induits par le projet d’infogérance (en comparant le futur contrat à la situation existante) : - amélioration des niveaux de service, - réduction de la valeur du risque, - facilité à se synchroniser avec les manœuvres de l’entreprise (capacité de l’architecture à supporter les évolutions planifiées), - réorientation des ressources et compétences internes vers des tâches à plus forte valeur ajoutée, - Se focaliser sur les niveaux de service attendus (« le quoi ») et laisser le soin aux de soumissionnaires de proposer les solutions techniques alignées sur les niveaux de service souhaités (« le comment ») – cette démarche évite parfois des dérives inflationnistes…. - Inscrire le projet d’infogérance dans une démarche de gouvernance des services du CC SAP (fourniture de services performants au moyen de ressources informatiques maîtrisées) - Organiser la bonne gestion du contrat d’infogérance au moyen d’une comitologie et de processus de surveillance & mesure de la performance adaptés (comité technique, comité de pilotage et comité de crise et reporting des niveaux de service) LES 3 PILIERS DE LA GOUVERNANCE DU SYSTÈME D'INFORMATION SAP

Agrandir l'image

La bonne Gouvernance du SI SAP repose sur un cadre de référence décliné selon les 3 piliers que sont le management du programme SAP, la performance du centre de compétence SAP et l’alignement de la solution SAP sur les exigences métiers.