Et bien pour faire simple, SAP Hana Express (en mai 2018), ça coince à l'installation (ça doit venir de moi et de mon système). J'ai demandé de l'aide à une amie dont l'entreprise utilise cet ERP. Résultat, ça ne marchera pas pour moi.
J'ai pu tester un module client de SAP sur l'un des postes de son entreprise (30mn environ), et là OUCH !... La seule raison qui fasse que ce monstre logiciel soit encore autant utilisé vient du fait que les clients ont été convaincus de ne pas changer avec des arguments assez tronqués :
_ cout de la migration des données pour un autre système (temps, argent, compétences, licences systèmes)
_ paresse des ingénieurs systèmes (oui, bon ça marche assez pour qu'on continue comme avant)
_ manque de compréhension de ce qu'est vraiment un ERP (juste une base de données avec modules de gestion et applis d'usage pré-fournies)
_ manque de connaissances de ce qu'est vraiment SAP (un ERP ancien, implanté comme une vieille maladie impossible a éradiquer, genre la grippe ou la carie dentaire)
_ sécurité et fiabilité de SAP dans le temps (surtout garantie en fait par la non connexion du système au réseau internet public, hors modules de consultation par exemple)
Mais l'argument le plus souvent avancé est : "Ce système a été développé par des experts, à l'aide d'un langage fiable et solide (COBOL), et nous avons nous aussi intégré à SAP son propre langage de script : ABAP ,...". Sauf que COBOL bien que solide à plus de 60 ans, développé dans le milieu des années 1950 comme langage objet, pour des systèmes de l'époque. Le suivi de COBOL s'est fait avec de plus en plus de problèmes, et seul le maintient d'une logique électronique simple permet à ce dinosaure de continuer a etre compilable sur les machines actuelles. Reste que le développement de logiciels avec COBOL est horrible. C'est comme faire usage du latin dans le commerce international, totalement inadapté.
Un ingénieur COBOL a fait la remarque que ce qui prend 600 lignes en COBOL n'en prend que 20 en JAVA, du fait de choix idiots fait lors du développement. Hors SAP est basé sur COBOL, par sur JAVA ou C# ou encore ADA (conçu pour les systèmes sensibles et à besoin de hauts niveaux de sécurité et fiabilité). Ce qui montre que SAP ne sera plus une bonne solution sauf si :
_ SAP doit etre entièrement réécrit avec un langage actuel (compilé de préférence, pas interprèté sinon cout système trop lourd)
_ une version de test doit etre disponible pour apprentissage (autrement le choix des étudiants se portera toujours vers le gratuit, comme Open Concerto par exemple, beaucoup plus souple et accessible)
_ les entreprises oublient le risque réel posé par un modèle monolithique contraint (en 2011 crise financière due à l'incompréhension des utilisateurs des systèmes de prévision bancaire utilisés, et emballement système, du à la complexité des systèmes). SAP a le meme problème,
trop lourd, trop ancien, inadapté à l'actuel (la 5G est en cours de développement et sera disponible dans moins de 3 ans, quand SAP correspond à la radio de Marconi).
Non, j'ai essayé SAP, et si ça marche encore, c'est un mauvais choix pour n'importe qui. Apprendre oui, utiliser au quotidien non. En plus un système fermé ne doit sa fiabilité qu'à l'absence d'accès à ses structures internes, pas à sas algorithmes. On le voit assez en cryptographie; plus le système est secret, plus il est cassé vite, et les dégats couteux.
0 |
0 |