Le modèle de données SAP CRM que j’avais publié sur le wiki.scn.sap n’étant plus disponible, je le remets à disposition ici :

De nombreuses publications traitent des outils de développement Low-code / No-code pour créer des applications mobiles, et cela nous a donné envie d’essayer. Nous voulions nous rendre compte par nous-mêmes de l’effort nécessaire à la création d’une application simple, utilisable par tous, et disponible à la fois sur les plateformes iOS et Android.

Concernant la plateforme de développement, nous avons inventorié de nombreux outils tels que : Adalo, Andromo, AppGyver, AppMachine, AppSheet, Appian, Appy Pie, Bildr, Bravo Studio, Bubble, Caspio, Clutch, Cronapp, Draftbit, Drapcode, FlutterFlow, etc. Parmi ces solutions, nous avons éliminé celles qui ne permettaient pas l’hébergement des données par le prestataire de notre choix, car nous ne voulions pas que le logiciel utilisé pour développer notre application serve aussi de stockage pour nos données – restées bien à l’abri en Suisse. Ensuite le prix et la pérennité de l’éditeur ont été les principaux critères de choix, mais nous avons également étudié les possibilités de formation en ligne, la documentation, le support gratuit, les forums ainsi que les contributions de « Citizen Developers ». Finalement notre choix s’est porté sur SAP AppGyver : non pas qu’il s’agisse du meilleur outil dans tous les domaines (Nicolas a préféré Bubble, et Martial Draftbit ou FlutterFlow), mais il cochait pas mal de cases, d’autant que Swiss Computing travaille dans l’écosystème SAP depuis des années…

Pour le stockage des données c’est Google Firestore qui a été retenu, ce qui nous a permis de découvrir la manipulation des enregistrements dans une base No SQL. Mais Xano a été un véritable coup de cœur pour les habitués de bases relationnelles que nous sommes.

Une fois le choix des outils effectué, nous nous sommes vite rendu compte que la création d’une application, même très simple, requiert de l’expertise à plusieurs niveaux :

• Base de données : pour modéliser les différents objets et générer des requêtes performantes.
• Sécurité : pour gérer l’enregistrement des utilisateurs, les validations par email, les autorisations sur chaque prêt, etc.
• Développement : pour manipuler les objets JSON et envoyer des notifications via les fonctions Firebase.
• Déploiement : pour rendre l’application disponible à la fois sur Android et iOS. Si nous avons pu constater que cette étape est relativement simple pour Android puisque l’application générée par AppGyver peut être importée sur la plateforme Google Play Console, ce n’est pas vraiment la même musique sur iOS !

En conclusion : étant nous-mêmes développeurs depuis plusieurs années, au départ nous pensions réaliser ce projet en quelques jours. Finalement il nous a fallu plusieurs semaines durant lesquelles nous avons beaucoup appris… ce qui nous laisse à penser que la propagande de certains éditeurs qui promettent de créer une application en quelques clics est assez loin de la réalité, à moins de sacrifier certains aspects comme la sécurité.

Contactez-nous pour en savoir plus !

Les demandes de prestations en ligne peuvent être de toutes natures (raccordement à un réseau, demande d’autorisation, de permis, de document, annonce d’incident, etc.). Ces demandes ne correspondent pas forcément à un objet SAP mais déclenchent des actions et souvent une facturation de prestation. C’est dans ce contexte que nous implémentons la demande de service comme point d’entrée des processus SAP.

La demande de service, initialement Service Request du CRM 7.0 est maintenant intégrée à S/4HANA. Créée par interface, elle nécessite une licence de transaction indirecte (c.f. Indirect Digital Access) mais les documents SAP subséquents, créés depuis ce point d’entrée, en sont dispensés.

La demande de service permet de regrouper les données récoltées et de suivre les actions jusqu’à sa clôture :

• Les données saisies sur le portail peuvent être répliquées ;
• Les sociétés et contacts du cas sont identifiés ;
• Des courriers peuvent être générés sur la base de modèles ;
• Une checklist permet de valider les étapes de traitement ;
• Les documents SAP subséquents peuvent être déclenchés, tels qu’une commande ou facture ;
• Les niveaux de services peuvent être vérifiés, le temps de travail saisi, etc.

La digitalisation des processus élimine les documents papiers et multiples e-mails. Notre réserve de travail est alors visible dans une liste de tâches. Les tâches sont représentées par une action sur un objet, par exemple, la validation sur une demande d’achat.

Contactez-nous pour en savoir plus !

Un modèle de données collaboratif grâce au cloud public

Les ERP actuels ont été conçus pour répondre aux besoins internes de l’entreprise, avec d’un côté des clients et de l’autre des fournisseurs. Une commande entre deux sociétés est gérée sur deux ERP, une commande d’achat sur le premier et de vente sur le second.

Une application native cloud est conçue globalement, son modèle est simplifié. Une commande est représentée par un seul objet qui relie les deux contractants.

Les objets se simplifient pour correspondre aux entités réelles

L’identification unique des personnes physiques et morales facilitera l’utilisation de services globaux. Les bases légales permettent maintenant aux administrations de digitaliser leurs services à la population. Les entreprises pourront bénéficier de nouvelles conditions-cadre, des services centraux et divers référentiels.

La simplification du processus d’achat/vente pourrait séduire rapidement les PME actives dans les services (et leurs fiduciaires). Une invitation à contracter sur une plateforme commune deviendrait virale.

Ce concept vous séduit, contactez-nous pour en savoir plus !