SAP RF : il est temps de passer aux alternatives d’un framework « So 2000 »

Une technologie éprouvée… mais vieillissante

Il est important de rappeler que la technologie sous-jacente au framework RF n’est autre qu’ITS Mobile, en service depuis la version 4.6c (qui date de 2001 tout de même !). Ce fut, certes, une avancée après des années de SAP Console.

Cyril Vernet, CTO de HRC Software

 SAP Console est l’ancêtre de la mobilité avec une interface en mode texte, développée à une époque (lointaine) où les terminaux mobiles tournaient majoritairement sous Windows CE, où les écrans tactiles n’étaient pas (ou peu) connus, où les terminaux étaient munis de clavier, où aucun end-user n’avait de smartphone et où la fonctionnalité ergonomique la plus avancée consistait à utiliser les touches fonctions du keyboard (les fameuses « Fn ») voire à changer les couleurs pour moderniser les écrans. Bref, un autre temps !

Il faut donc bien reconnaître qu’ITS a apporté un indéniable souffle de modernité et que les écrans ITS générés à partir d’écrans Dynpro permettaient de s’appuyer sur les compétences de développeurs ABAP.

Mais depuis, le monde a évolué. Les références des utilisateurs également. Et les possibilités offertes par l’évolution des technos (aussi bien hardware que software) ont généré de nouvelles possibilités.

Autant d’éléments qui nous incitent, en 2023, à faire d’autres choix, ne serait-ce qu’en termes d’ergonomie.

Une solution surannée qui a pourtant de multiples alternatives

« SAP n’émet aujourd’hui plus aucune contre-indication quant au choix d’une approche autre que celle du framework RF. »

À ce titre, il est d’ailleurs étonnant que l’éditeur allemand continue de préconiser le RF Framework alors qu’il fournit une galaxie d’applications dans de nombreuses technologies différentes (ITS, Fiori, MDK, SDK, API, Low Code, etc.).

Dans la même idée, dans son document « Strategy Paper », SAP ouvre également la voie à plusieurs autres options : Fiori Apps, développement sur la base d’API standard, solutions partenaires (SAP Store).

Libre donc aux clients de choisir en fonction de leurs enjeux, de leurs ambitions, de leur historique et/ou de leurs compétences. Quoi qu’il en soit, il est important de souligner que l’éditeur de Walldorf n’émet aujourd’hui plus aucune contre-indication quant au choix d’une approche autre que celle dudit framework.

Des limites de plus en plus pointées du doigt

Cela reste incontestable : tout terminal muni d’un navigateur Web a (et aura) la possibilité d’exécuter des transactions RF. C’est un fait. Néanmoins, une des limites (par rapport à une application native, voire hybride) réside dans son incapacité, par faute d’intégration, à exploiter tout le potentiel des appareils actuels (performances, hors ligne, intégration avancée de lecture de code à barres, etc.).

C’est bien là où le bât blesse si l’on convient que la lecture des codes à barres est, de nos jours, un élément crucial dans la gestion des entrepôts.

Toujours dans cette même idée, est-il besoin de rappeler qu’un des inconvénients des transactions RF réside dans le fait qu’il faut nécessairement avoir un champ de saisie sélectionné (focus), avant d’entamer une quelconque lecture de codes. Un détail qui n’en est pas un, et qui est source de bien trop d’erreurs.

Une version standard fiable… mais rarement satisfaisante

Si la solution RF standard peut être déployée rapidement, cette version basique a (et aura) généralement le plus grand mal à contenter ses clients.

De fait, elle nécessite – dans une très grande majorité des cas – plusieurs (et donc coûteux) jours de développement pour coller à des aspirations spécifiques. Avec, à la clé, un choix cornélien à faire : investir (certains diront : gaspiller) pour tenter d’améliorer une solution d’un autre âge, ou engager une réflexion plus pérenne ?

Au vu de la couverture fonctionnelle extrêmement large fournie par le standard, l’alternative consistant à développer « from scratch » sera très vite confrontée à des considérations budgétaires.

En revanche, envisager des solutions tierces « sur étagère » peut, dans bien des cas, s’avérer judicieux pour profiter à la fois d’un déploiement rapide, d’une solution robuste et éprouvée, et bénéficier d’une maintenance ad hoc.

Si nous devions donc résumer, nous pourrions conclure, un brin provocateurs, que le choix d’un investissement sur le framework RF peut se justifier « si et seulement si » vous utilisez encore des terminaux avec un écran non tactile, un clavier avec des (grosses) touches fonctions, et que vos collaborateurs n’ont jamais basculé sur smartphone (ou que vous êtes un grand nostalgique du « BlackBerry » et des années 2000).

Last but not least, budgéter des millions pour une migration vers S/4 (au nom de l’innovation, dixit SAP) et ne pas investir, en 2023, quelques milliers d’euros pour offrir aux utilisateurs terrain une suite d’applications mobiles à la hauteur des attentes du moment, relève d’un choix au mieux très largement discutable et contestable, au pire, coupable.