What if SAP made toasters …
The manual to run the toaster would be approximately 10,000 pages long. The toaster would come with 2,500 switches which would all have to be set in an exact pattern and in a precise sequence in order to toast specific kinds of bread. Each pattern would be established by SAP’s experts as the Best Practices method of toasting that kind of bread. It would take a team of basis and functional contractors about 1 year to configure the toaster in the best manner, and then another 6 months to test it. In the mean time, your entire family would need to attend extensive training classes on how to use the new toaster. In order to support end users and consultants, MIT would establish a list-serv for people to post questions and answers regarding toaster set-up and operation. Of course, the online help would randomly pop up in German. But once it was running, you’d get the best toast in the world. By unknown author.

• Les prix, remises, majorations, taxes, provisions devront être calculés suivant des règles imaginées par les responsables marketing ou directeurs des ventes qui se sont succédé aux manettes de la politique tarifaire de l’entreprise. Règles  réinterprétées au fil du temps en fonction de leur perception par le(s) marché(s), ce qui se traduit communément par un empilement d’exceptions et de cas particuliers.
• Les produits vendus devront ensuite être expédiés à partir d’un site de stockage. Rien de plus simple … si ce n’était les caractéristiques propres au produit, boite de conserve ou wagon de métro; les particularités de chaque entrepôt, les techniques de prélèvement, d’emballage, de marquage; les modes de gestion du transport; et cerise sur le pudding, les documents de livraison, de transport et d’export formatés en fonction du pointillisme propre à chaque douane à passer.
• La facture sera dans certains contextes un outil de communication, ce qui se traduit généralement par une mise en forme pointue souvent peu compatible avec la ‘richesse’ des éléments de prix décrits plus haut. Dans certains pays cette facture n’aura de valeur probante qu’après avoir transité par un système tiers agréé d’authentification. Elle se déversera enfin dans le système financier selon un mille-feuilles de règles aptes à satisfaire comptables et contrôleurs de gestion.
• Tout ceci se déroule dans un monde où les outils de communication sont multiples. Les commandes seront intégrées à partir d’un fichier Excel, de messages EDI, d’un site de vente en ligne ou de caisses sur les points de ventes. Tous les intervenants de la chaine logistique échangeront également afin de planifier, ordonner, confirmer, informer. De la même manière les factures remonteront les flux ayant donné lieu aux commandes et alimenteront des systèmes tiers … ou pas, BW par exemple.

Il ne s’agit là que d’un pale échantillon destiné au lecteur peu habitué au monde de l’entreprise … française, oui la France est à classer dans la catégorie des pays du sud, en opposition à ceux du nord réputés faire simple et efficace.

Oui SAP est complexe parce qu’enrichi depuis 30 ans par les milliers de développeurs de Walldorf et des SAP Labs afin de coller aux besoins et aux modes des époques traversées, afin d’intégrer en standard des domaines d’activités de plus en plus nombreux. Cette complexité est essentiellement due à la richesse du produit, si la base technique subit des révolutions, seules des évolutions altèrent l’interface de paramétrage ou d’administration.

L’apprentissage de SAP, que ce soit au niveau utilisateur, consultant ou administrateur s’apparente à l’étude d’une langue étrangère. Les débuts sont toujours un brin difficiles, puis vient une certaine aisance et ce n’est que plus tard que l’on prend conscience des  ressources quasi infinies disponibles sous la souris. La documentation n’étant qu’une frêle bouée, c’est la curiosité et la ténacité qui permettront de rester à flot.

Par exemple, pour paramétrer une fonctionnalité un brin complexe on peut être amené à :

• Suivre le cours de paramétrage correspondant afin de maîtriser le concept, effectuer des exercices pratiques et dans le meilleur des cas bénéficier de quelques astuces de la part du formateur. Pour information, une simple lecture du support de cours ne présente aucun intérêt si elle n’est pas associée à des exercices de paramétrage.
• Lire la documentation de paramétrage disponible dans l’IMG ou sur le site help.sap.com. Il s’agit le plus souvent de définitions, parfois très sommaires, souvent sans intérêt.
• Lire les notes de consulting disponibles à l’adresse service.sap.com/support. C’est la source d’information la plus intéressante où il est possible de trouver toutes les étapes du paramétrage de certaines fonctions. Cela malgré une présentation en mode texte un peu vieillotte, ne comportant donc pas d’images d’écrans.
• Actionner frénétiquement la touche F4 : le paramétrage SAP consistant à cocher, ou décocher, des cases, celles-ci sont parfois assorties d’un message d’aide très utile … mais trop souvent rattachées à un texte sommaire qui n’est d’aucun secours.
• Interpréter les messages d’erreur plus ou moins explicites rencontrés lors de l’implémentation.
• Effectuer une recherche dans le wiki SAP … très très pauvre sur SD par exemple. Les consultants SAP ne sont pas partageurs !
• Passer en debug pour comprendre le fonctionnement du système sans s’appuyer sur la documentation du code trop souvent en allemand.

Cette documentation imparfaite explique quelques unes des spécificités propres à SAP :

• La difficulté pour un consultant à couvrir son périmètre fonctionnel avec un niveau d’expertise suffisant. L’écart de performance est énorme entre celui qui a déjà implémenté une fonctionnalité et celui qui la découvre.
• Le recours au re-développement d’une fonction standard, connue ou inconnue des parties prenantes, ce qui permet de faire l’économie de la maîtrise du standard SAP, d’être au plus près du besoin exprimé par le client, le tout au détriment de la fiabilité et de la maintenabilité.

La question qui se pose inévitablement est la suivante : cette sous-documentation fait-elle partie d’une stratégie destinée à limiter l’expertise aux sociétés partenaires ? C’est le bruit qui courrait il y a quelques années, mais je n’en suis pas convaincu. Ce logiciel tentaculaire voit son périmètre étiré de tous côtés par l’évolution du marché IT. Le marketing suit, ou anticipe le marché, et les développeurs SAP suivent à marche forcée les annonces marketing. C’est la routine d’un business moderne. Que devient la documentation dans tout ça ? ce n’est pas un argument de vente, ni un frein à la vente de licences … c’est la cinquième roue de la Mercedes !

Dans un environnement SAP, la plupart des Reprises de données et Modifications en masse peuvent être effectuées en 3 étapes :

• Extraction des données avec ABAP Query vers un fichier Excel, à condition bien sur que le système source soit SAP
• Validation, enrichissement des données du fichier Excel par les utilisateurs
• Intégration du fichier Excel avec LSMW

Avantages de la méthode :

• Apprentissage d’ABAP Query, un outil très puissant pouvant embarquer du code ABAP, peu consommateur de ressources s’il est bien utilisé. Des requêtes bien construites seront toujours très appréciées par les utilisateurs
• Apprentissage de LSMW, un outil très riche pouvant également embarquer du code ABAP, idéal pour la reprise de données ou les modifications en masse

La conséquence de structures organisationnelles SD mal définies est la démultiplication inutile des Domaines commerciaux, un Domaine commercial étant une combinaison Organisation commerciale / Canal de distribution / Secteur d’activité. Le paramétrage SD, effectué pour l’essentiel par Domaine commercial, sera complexifié et les Données de base Client, Article, Conditions de prix, etc démultipliées. Lorsque l’on sait que le bon fonctionnement d’un système SAP est fortement dépendant d’une gestion rigoureuse des Données de base alors que les sociétés utilisatrices répugnent à affecter des ressources à la gestion de ces Données de base. Un des objectifs dans un projet SAP doit être de limiter autant que possible le volume de Données de base à gérer.

Une erreur courante consiste à définir Organisations commerciales et Canaux de distribution en fonction des besoins en reporting du moment. Par son impact sur le Paramétrage et les Données de base, ce choix aura des conséquences désastreuses lorsqu’il sera nécessaire de modifier les axes d’analyse,

Le customizing offre deux possibilités de limiter le volume de données de base relatif aux structures organisationnelles (Définir des Canaux de distribution communs & Définir des Secteurs d’activités communs) mais cela s’avère souvent insuffisant. Il n’est en effet pas possible de définir un Canal de distribution commun pour les Données client mais pas pour les Données articles, ou inversement.

Par conséquent, ma politique personnelle en début de projet est de ne pas aborder les structures organisationnelles SD. Les premiers ateliers se déroulent sur la base d’une Organisation commerciale par Société, combinée à un seul Canal de distribution et un seul Secteur d’activité, si du business inter-sociétés est probable on pourra dès le début du projet prévoir un Canal de distribution interco. Une bonne partie du maquettage qui s’en suit peut s’effectuer dans cet environnement simplifié. Ce sont ensuite uniquement des contraintes techniques incontournables qui contribueront à démultiplier les Domaines commerciaux : nécessité de gérer des données de base client et/ou article différentes pour chaque Canal de distribution, contraintes de paramétrage, autorisations.

Cette approche se base également sur une constatation très simple : il est beaucoup plus facile de dédoubler un Domaine commercial, même tardivement en fin de projet, que de dédoubler 12 Domaines commerciaux sur lesquels s’appuient paramétrages, routines et user-exits.