Le standard SAP ne fournit pas de processus

En raison de la présence fréquente du mot "processus", un fort effet d'habitude s'est produit. Presque plus personne ne se soucie de la signification de ce terme pour les logiciels et leur utilisation. L'article suivant se concentre sur les processus de gestion et leur mise en œuvre ou leur prise en charge dans la norme SAP ERP.

Processus de réception des marchandises

L'un des processus commerciaux les plus en vue dans SAP ERP est le processus d'entrée de marchandises. Celui-ci se compose des étapes suivantes : une commande est déclenchée et créée sous forme de document dans SAP, la commande est envoyée au fournisseur, la marchandise est livrée, saisie et un document d'entrée de marchandises est créé dans SAP ERP.

Cet exemple montre toutes les caractéristiques essentielles d'un processus d'entreprise : le processus a un déroulement dans le temps, une direction - une progression qui est mesurable. Le processus a un état défini à chaque instant.

Il existe différents agents : ceux-ci peuvent travailler en série ou en parallèle. Chaque processus est accompagné d'un protocole et les états passés du processus doivent pouvoir être rétablis si nécessaire. Les documents SAP peuvent être inclus ou créés et les documents physiques (formulaires) sont inclus (par exemple, bon de livraison, commande).

Il existe un grand nombre d'autres processus commerciaux similaires qui sont généralement gérés par le SAP ERP. Citons par exemple : la réception des factures, la réception des réclamations, le processus de vente (demande du client - offre - commande) et l'inventaire.

En tant que processus de gestion, ces processus n'existent toutefois qu'au niveau organisationnel dans SAP ERP. Le standard SAP ne fournit que les documents entre lesquels les processus se déroulent. Lors de l'entrée de marchandises, ce sont par exemple le document de commande et le document article qui sont créés au cours du processus.

L'utilisateur est seul responsable du déroulement du processus. Les délais, l'avancement, l'état, les personnes impliquées, les documents doivent être gérés par l'utilisateur.

Il n'existe pas d'endroit central où l'utilisateur peut obtenir une vue d'ensemble des processus en cours. Le monitoring des processus prend du temps, est compliqué et n'est pas fiable, car une multitude de sources de données (documents) doivent être consultées pour l'évaluation.

Lors du déroulement des processus, les ruptures de médias sont fréquentes : La communication se fait par e-mail, par téléphone ou par des services de messages courts. Cette communication n'est pas documentée. Il est donc difficile de comprendre les décisions a posteriori. La norme SAP laisse ici manifestement - intentionnellement ou non - une lacune d'une ampleur étonnante.

Exigences de l'outil de gestion des processus

Si l'on veut créer un outil logiciel pour soutenir le traitement des processus commerciaux, il est préférable de faire abstraction des cas d'application spécifiques. Cela signifie que l'on considère par exemple les cas d'application "réception de factures" et "réception de marchandises" et que l'on essaie d'isoler les propriétés et exigences communes.

Processus objet de gestion : il s'est avéré judicieux de considérer le processus lui-même comme un objet de gestion. Cet objet de gestion doit posséder les propriétés 1-8 mentionnées dans l'introduction.

Durée d'exécution du processus : les processus peuvent être avancés manuellement, c'est-à-dire contrôlés par l'utilisateur dans une transaction de dialogue, mais ils peuvent également progresser automatiquement. Dans les processus commerciaux courants, les deux formes "d'avancement" sont fréquentes. Il en résulte qu'une sorte de "temps d'exécution du processus" est nécessaire pour faire avancer automatiquement les processus.

Monitoring versus cockpit : l'état et l'avancement du processus doivent pouvoir être surveillés. Pour cela, il faut une transaction de monitoring qui affiche tous les indicateurs essentiels et offre une vue sur les données détaillées du processus.

Si la transaction de monitoring permet en outre de contrôler le processus, c'est-à-dire de faire avancer le processus et de modifier les données du processus, nous parlons alors de cockpit du processus. D'un point de vue logiciel, le moniteur et le cockpit peuvent être la même transaction, autorisée différemment.

Architecture logicielle

Nous partons d'un développement en Abap OO, car le temps d'exécution d'Abap présente des avantages décisifs, comme nous le verrons plus tard.
Classe de gestionnaire : la base de tous les processus d'application est un processus abstrait sans rapport avec l'application. Celui-ci est implémenté comme une simple classe Abap-OO (classe de gestionnaire) avec quelques propriétés :

• La classe n'est pas finale
• La classe fournit sa propre persistance, c'est-à-dire qu'elle se lit et s'écrit dans la base de données.
• La classe fournit un mécanisme de verrouillage, de sorte qu'un seul modificateur est autorisé à la fois.
• La classe rédige son propre protocole
• La classe a une méthode de callback dédiée, qui est appelée par le temps d'exécution du processus pour les traitements "sombres

Toutes les classes spécifiques à l'application dérivent de cette classe de processus abstraite. Celles-ci étendent la persistance de la classe de base à leurs données d'application en écrasant les méthodes de persistance. Il existe éventuellement aussi des extensions fonctionnelles.

Durée d'exécution : la durée d'exécution du processus recherche dans une table de registre, au moment de l'exécution, la classe de handler qui appartient au processus concerné (par exemple, la classe de handler pour le processus de réception des marchandises). La classe de gestionnaire est instanciée au moment de l'exécution et sa méthode de rappel est appelée par l'exécution.

Ce concept de liaison tardive s'appuie sur le principe du Component Object Model (COM), établi par Microsoft dès 1992 et toujours utilisé aujourd'hui, par exemple dans le nouveau Windows 10 Runtime (WinRT). Ici aussi, une DLL (objet COM) n'est chargée qu'au moment de l'exécution via un GUID d'objet pour lequel le chemin d'accès au fichier de la DLL est enregistré dans le registre Windows. Le principe de la liaison tardive est particulièrement facile à mettre en œuvre dans Abap grâce au concept des classes globales.

Du point de vue d'Abap, le temps d'exécution n'est rien d'autre qu'un programme qui rassemble tous les processus non terminés et appelle en série leur méthode de rappel. Ce programme est exécuté périodiquement en arrière-plan et peut éventuellement être planifié plusieurs fois afin d'augmenter le débit. Les collisions sont résolues de manière performante grâce au mécanisme de blocage intégré.

Monitoring/Cockpit : le monitoring fournit à l'utilisateur toutes les informations nécessaires sur la progression, le nombre et l'état des processus. Le protocole de chaque processus devrait être visible depuis le moniteur de base. En outre, le moniteur de base devrait permettre le redémarrage et le débogage d'un processus individuel et remplit donc déjà quelques fonctions de cockpit.

Le monitoring est entièrement découplé de l'exécution et de la classe de gestionnaire. Il peut être implémenté dans n'importe quelle technique d'interface utilisateur (SAPGUI, WebDynpro, UI5, Windows). Du point de vue de la réutilisabilité, le SAPGUI est toutefois la technique d'interface utilisateur de choix, car c'est avec le SAPGUI qu'un concept MVC strict peut être mis en œuvre de la manière la plus rigoureuse.

Toute la logique de l'IU peut être très facilement transférée dans une classe de contrôleur réutilisable, globale ou locale. De ce point de vue, le SAPGUI est plus moderne que toutes les autres technologies UI.

Cockpit d'application : le cockpit d'application s'appuie sur le contenu du moniteur, mais offre en outre des vues sur les données d'application et met également à disposition des fonctions spécifiques à l'application. L'UI est une extension du moniteur de base.

Dans SAPGUI (également dans le cas du WebDynpro), la classe de contrôleur peut être dérivée de la classe de contrôleur du moniteur. Le cockpit "hérite" ainsi de toutes les fonctionnalités du moniteur de base sans effort supplémentaire. La mise en œuvre d'un cockpit peut ainsi être réalisée en très peu de temps.

Conclusion

Pour les entreprises, il peut être très intéressant de combler de cette manière la "lacune du processus". Les raisons sont nombreuses : par exemple, c'est le logiciel qui s'adapte au processus d'entreprise et non l'inverse.

Un point d'entrée central est créé du point de vue du processus, ce qui correspond souvent aussi au point de vue du service. Les temps d'exécution des processus sont réduits et mesurables, les erreurs sont entièrement consignées. Les processus deviennent transparents : le reporting peut être mis en œuvre comme une simple extension du monitoring.

Le degré élevé de réutilisation des composants logiciels existants permet d'optimiser les temps de mise en œuvre des projets. Le concept devient pérenne en s'adaptant aux nouvelles technologies d'interface utilisateur avec un minimum d'efforts. Enfin, il convient de noter que ce principe peut bien entendu être appliqué à des processus techniques tels que les migrations ou les mises à jour en masse asynchrones et parallèles.