Phase 5 : Process Improvement

Comme on a pu le voir lors de cette tentative d’implémenter un processus, le recours au BPM Lifecycle n’est en rien garant qu’un processus soit facile à implémenter et que toutes les options choisies durant cette tentative soient les bonnes. En revanche, de BPM Lifecycle, de par sa nature itérative, permet d’intégrer l’expérience de chaque itération pour améliorer le processus par la suite. Dans ce travail, son recours permettra d’évaluer les enjeux d’une telle implémentation et de définir ce qui peut être amélioré et comment. A cette fin, les principaux éléments qui se sont avérés critiques sont ici mentionnés et pourront servir à une prochaine itération du processus.

5.5.1 ENVOI DES DONNÉES PAR L’ERP

Afin de rendre le processus pleinement fonctionnel et optimal en termes de fonctionnement, il est essentiel que la transition entre l’ERP et le BPMS se fasse de manière automatique.

Pour cela, il faudra configurer l’ERP et le BPMS pour que la décision d’envoyer des montres, lorsqu’elle concerne des montres à exporter aboutisse à l’envoi des données pour les lignes de commandes désignées.

Les données concernant cet export sont en grande majorité présentes dans l’ERP, comme la Figure 29 en atteste avec notamment la présence des HS Code sur la facture. Il faut ici remarquer que l’intégration des informations douanières sur la facture ne servent pas qu’au processus d’export, mais rendent aussi possible l’importation dans les marchés cible. Cela implique que ces informations devront figurer dans l’ERP afin de soutenir la totalité du processus d’export. Il conviendra donc dans un premier temps de renseigner les objets

« articles » et « client » de l’ERP de manière optimale. Le BPMS pourrait ensuite jouer un rôle important dans le contrôle de la validité de ces informations avant leur envoi à la douane. C’est notamment ce qui sera expliqué au point 5.5.2.

5.5.2 UTILISATION DE FICHIERS XML DANS LE BPMS

Dans sa version actuelle, le prototype se base sur des variables indépendantes les unes des autres à titre d’input de données du processus d’import. Si ce format brut et non structuré pourrait être ce qu’un ERP serait à même de fournir comme données d’input à un cas d’export, il est à noter que la communication entre le web service et le BPMS s’effectue à l’aide de fichiers XML qui sont définis à l’aide de XML Schemas. Cette forme devrait être utilisée afin de réaliser les interfaces de contrôle avant l’envoi des données. Les XML Schemas stipulant la forme des variables, leur optionalité et d’éventuels liens avec d’autres variables. Pour cela, le BPMS devra être à même de reconnaître le XML Schema Goods Declaration, ce qui n’est pas le cas actuellement.

Partie pratique : Application du BPM Lifecycle dans une PME 72 Dans sa forme actuelle, le connecteur du BPMS qui accède à e-dec nécessite qu’il faille placer chaque variable dans l’enveloppe SOAP. Or il existe une extension payante qui va rendre possible la gestion des fichiers XML et qui permette une configuration nettement plus simple des variables, comme il est possible de le voir à la Figure 38.

FIGURE 38: INTERFACE DE CONNEXION WEB SERVICE PAYANTE DE BONITA (BONITASOFT, 2011)

De plus, ce module permet aussi de gérer le retour d’information sous la forme de fichier XML, ce qui aurait permis un meilleur retour des informations.

5.5.3 GESTION DES RÉPONSES DE DÉCLARATION PAR LE BPMS

Un des intérêts d’un service comme e-dec est, comme cela a été illustré à la Figure 28, sa capacité à pouvoir automatiquement déceler des erreurs dans la déclaration de douane et à communiquer avec le déclarant. Or, le système du déclarant doit être à même de gérer cela par le biais d’interfaces qui prennent en charge les différentes réponses, c’est-à-dire soit un fichier à corriger, soit la consultation de la déclaration acceptée. Ces interfaces doivent elles aussi se baser sur des XML Schema pour être générées. Elles pourront se baser sur l’interface de contrôle des données à la sortie de l’ERP au niveau de leur layout et de leur

Partie pratique : Application du BPM Lifecycle dans une PME 73 implémentation tout en intégrant les spécificités dues à la communication avec le web service e-dec.

5.5.4 DÉFINITION DES RÔLES AUTOUR DU PROCESSUS DANS LA PERSPECTIVE D’UNE IMPLÉMENTATION

Lors de cette première itération, il n’a pas été considéré que plusieurs personnes allaient participer à l’exécution du processus. Or si on veut que celui-ci se passe selon un optimum, il va falloir définir des responsabilités plus claires que ce n’est le cas actuellement. Par exemple, les données transmises à e-dec depuis l’ERP devront toujours être à jour. Cette responsabilité devra-t-être clairement assignée à quelqu’un dans l’entreprise afin d’éviter que des informations incomplètes sortent de l’ERP. De plus, le recours au BPMS va demander aux personnes de l’organisation de s’habituer à de nouvelles interfaces et à une nouvelle manière de travailler. Il faudra à la fois offrir la formation nécessaire aux utilisateurs et gérer le changement et toutes les réticences qu’il peut occasionner. De plus, cette implémentation devra se faire avec la conviction et le soutien inconditionnel de la hiérarchie.

5.5.5 GESTION DES RESSOURCES

Tout projet informatique est soumis à un impératif budgétaire. Afin de rendre possible l’intégration de e-dec dans le SI de l’entreprise, il va être nécessaire de procéder à des investissements qui n’ont pas eu lieu dans cette première itération du BPM Lifecycle. Il faudra en effet soit investir dans la solution Bonita pour la rendre utilisable selon les exigences fournies par le web service e-dec en investissant dans des modules et du conseil, soit utiliser une solution propriétaire qui soit à même de garantir que l’implémentation fonctionne sans bug technique. Ce n’est donc qu’en fonction d’un budget donné qu’une prochaine itération pourrait avoir lieu. Ce budget permettrait alors d’évaluer si les solutions libres retenues pour ce travail sont à même de concurrencer les solutions propriétaires en termes de rapport qualité/prix.

Conclusion 74

6 C ONCLUSION

Comme cela a été démontré dans ce travail par le biais des questions de recherche qui ont été traitées tout le long du travail, les approches SOA et BPM permettent aux dirigeants de gérer des problématiques qui sont centrales dans toute organisation : la pérennité du système d’information et le lien entre processus et création de valeur. Maîtriser les outils conceptuels de SOA et BPM contribue indéniablement à une prise de décision stratégique qui offre des avantages concurrentiels. L’approche SOA va en effet permettre au système d’information de pouvoir développer des nouvelles fonctionnalités qui puissent être les plus proches possibles des besoins de l’organisation. Quant à la gestion des processus offerte par BPM, elle va être à même de toujours relier les activités réalisées dans l’entreprise au but final de création de valeur et de mettre sur pied une philosophie d’amélioration continue.

En ayant pour objectif l’implémentation d’un processus d’export utilisant un web service issu d’une SOA, ce travail a pu évaluer en pratique la collaboration des deux paradigmes. Il a ainsi été possible d’étudier et d’interagir avec les interfaces du web service e-dec, lui-même basé sur une SOA. Cette interaction s’est faite dans le cadre d’une méthodologie dédiée aux processus : le BPM Lifecycle.

Cette démarche a nécessité une intégration des services passant par des outils BMPS et avec l’utilisation du langage de modélisation et d’exécution BPMN 2.0. Ces outils se sont avérés d’une très grande efficacité lorsqu’il a fallu identifier les fonctions cibles des acteurs faisant l’objet de l’intégration, modéliser les processus, les documenter. Au travers du modèle BPMM, le degré de maîtrise des processus a pu être situé et des objectifs ont pu être placés. Il a aussi été possible, en vertu de la qualité du BPMN 2.0 de garder le même modèle entre la phase de modélisation et d’exécution.

Les principaux problèmes qui sont apparus lors de ce travail sont liés au recours à un BPMS.

Les solutions en libre accès dans le domaine des BPMS se sont avérées inadéquates pour implémenter un web service utilisant SOAP et WSDL. Ces lacunes auraient dû être relevées plus tôt dans ce travail, notamment en évaluant la prise en charge des web services à la partie 4.5.2. Les tentatives sur différents outils réalisées dans ce travail se sont soldées par la mise sur pied d’un prototype non fonctionnel. Cela démontre que la gestion des processus et leur intégration nécessite à la fois un investissement en ressources et une réflexion organisationnelle et infrastructurelle. Un excellent degré de réflexion sur les processus ne suffira pas à implémenter ceux-ci. Il faut disposer d’outils qui soient fonctionnels et qui permettent d’interagir avec les web services sur des interfaces standardisées qui supportent les standards WS*. Ces propriétés sont essentielles pour tirer profit des web services et afin de rendre possible l’agilité promise par la rencontre entre SOA et BPM.

Conclusion 75 Pour s’assurer que la PME puisse disposer d’une solution d’export qui soit viable à l’avenir et ceci grâce aux prochaines itérations du BPM Lifecycle, il faudra prendre une décision au niveau de l’orchestration des processus. Soit celle-ci devra être laissée à l’ERP actuel et les processus soutenus seront ceux qui feront l’objet de développement par l’éditeur et la communauté open source qui le soutient, ou alors la PME pourra faire le choix d’investir dans une solution BPM qui soit conforme aux spécificités techniques du service e-dec. Dans les deux cas de figure, ce travail pourra servir de base pour réaliser soit un module qui permette la collaboration directe entre l’ERP et le web service e-dec, soit pour intégrer dans la PME une politique de gestion des processus qui soit basée sur un BPMS. Cette dernière option sera sans doute la plus intéressante pour l’entreprise si elle entend profiter de toute la puissance des outils de BPM. Il lui serait alors possible de pouvoir adapter son SI aux processus de manière optimale. Pas uniquement pour des cas concernant l’export, mais pour tous les processus de l’entreprise.

Pour réaliser cette vision, il faudrait traiter des points laissés ouverts par ce travail. Il faudrait tout d’abord commencer par une étude approfondie de l’offre faite aux PME pour intégrer de tels systèmes, tant au niveau de la solution logicielle - et de l’architecture qu’elle implique - qu’au niveau de la formation des utilisateurs. Car comme ce travail l’a montré, l’explication des concepts théoriques n’est en rien garante qu’une solution BPMS fonctionne sans difficultés techniques. Si les concepts sont nécessaires ne serait-ce qu’à la formulation des besoins qui motivent le choix d’un BPMS, un lien contractuel avec un fournisseur de solution sera une garantie importante pour que les processus puissent s’exécuter.

Un autre point laissé ouvert par ce travail concerne la collaboration entre le management de l’entreprise et les personnes responsables des processus. Il sera nécessaire que le management puisse, en ayant consulté ce travail, se faire une idée précise sur les approches BPM et SOA et qu’il leur attribue des ressources et des buts qui cadrent avec la stratégie de l’organisation. Pour cela les objectifs des itérations suivantes de BPM Lifecycle devront impérativement être définis à l’aide de métriques quantifiables. Car même si le langage de modélisation de BPMN 2.0 facilite la communication entre les différents acteurs impliqués dans la gestion des processus, c’est bien l’adéquation avec les objectifs fixés qui va être garante que le BPM et SOA soient des approches pertinentes et qui permettent à l’organisation de créer de la valeur.

Bibliographie 76