L’ERP sous forme de service

Complets, intégrés, efficaces. Telles devaient être, jusqu’ici, les caractéristiques des ERP -en somme, une «solution définitive» à l'informatisation de la gestion. Aujourd’hui, les ERP sortent de cette définition étroite et hégémonique; ils doivent s'intéresser à l'environnement informatique existant et, surtout, s'y connecter. Il faut dire que les domaines couverts se sont étendus, tout comme la notion d'entreprise.

En parallèle aux ERP, on voit toujours autant d'applications spécialisées, centrées sur le cœur de métier. Ces applications proviennent souvent d'éditeurs qui ont développé des solutions de niche et qui déploient tous leurs efforts pour les maintenir et les faire évoluer.


Le défi? Favoriser les moyens de faire communiquer ces applications avec les ERP plus généralistes. D'où la montée en puissance d'architectures favorisant l'intégration du système d’information d'une entreprise. Ce fut d’abord les techniques d'EAI (Enterprise Application Integration). Aujourd’hui, on parle davantage de SOA (Service Oriented Architecture).

Qui dit SOA dit réécriture complète. C'est une redéfinition majeure de la structure même des progiciels, qui doivent dorénavant relever un double défi: conserver l'intégration de leurs propres modules tout en accueillant sans discrimination les applications externes, déjà existantes ou à venir.

Les premières réalisations de ce type commencent à voir le jour. Mais le chemin sera encore long à parcourir avant de disposer d'applications modulaires capables de communiquer avec d'autres logiciels efficacement et en toute sécurité.

SAP Business Suite 7.0, destiné aux grands comptes, comporte une bibliothèque d'environ 1.600 services web, chargés d'exposer toute la logique applicative du progiciel, et non plus seulement ses fonctions centrales.

La démarche SOA prend une toute autre dimension quand elle est mise en œuvre pour la construction de nouveaux systèmes. Il pourrait bien s'agir d'une révolution permettant de concevoir un système d’information totalement ouvert et communiquant. C'est un concept sur lequel le monde des logiciels libres a eu une grande influence. Dans cet esprit, il s'agit pour chaque entreprise de maîtriser totalement ses applications, sans dépendre de tiers.

De fait, un métier s'appuie souvent sur plusieurs applications, qu'il devient donc nécessaire d'intégrer. La communication entre tiers amène à ouvrir les applications vers l'extérieur. La SOA permet de définir des interfaces machine-machine qui ont les mêmes possibilités que les interfaces homme-machine en terme de souplesse et de personnalisation. Plus la structure d'une application est modulaire, plus l'adoption d'une architecture SOA sera aisée.


Une fois mise en place, l'architecture SOA permet d'intégrer de nouveaux services dans le patrimoine applicatif. Cette intégration sera d'autant plus facile que le système d'information de l'entreprise est découpé en couches bien distinctes permettant de séparer les aspects techniques des aspects métiers, la partie transactionnelle de l'utilisation.
Modules, couches et applications doivent s'échanger des informations de manière industrialisée et se combiner en processus.

Une plate-forme comme AIA (Applications Integration Architecture) d'Oracle comporte des processus d'intégration packagés. Ce type d'outil peut prendre en charge à la fois des applications internes et des applications externes.

Modules, couches et applications doivent s'échanger des informations de manière industrialisée et se combiner en processus. L'approche SOA est donc indissociable de l'approche BPM (Business Process Management) pour la gestion des processus.

Discipline destinée à décrire et à documenter les processus métier de l'entreprise, le BPM aide aussi à modéliser les processus importants, à décrire les activités contenues dans les processus, à les faire exécuter par des moteurs et à orchestrer les processus de bout en bout. Il impose une vision transversale de l’activité de l'entreprise, diamétralement opposée à celle, en silos, des ERP. Et permet l'amélioration continue des processus.

De tous les processus? Pas sûr. Si le BPM est utile pour orchestrer des processus issus de diverses applications, certains métiers, comme l'automobile, ont des contraintes tellement fortes qu'il n'y a aucune souplesse, font remarquer certains éditeurs. Qui plus est, tout dépend de la cible. Dans une PME, le BPM ne génère que peu de valeur par rapport aux investissements qu’il imposerait…

Dans les grandes organisations, la question est parfois écartée en utilisant deux ERP. En somme, une standardisation à deux niveaux, avec une solution haut de gamme pour la maison mère et une version plus légère pour les filiales. On voit aussi que faute de pouvoir couvrir tous les besoins de l'entreprise, les ERP sont également associés à différentes applications «best of breed» ou des développements internes. Il n’y a pas d’incompatibilité.

De toute façon, les éditeurs d’ERP migrent progressivement vers le modèle SOA pour faciliter l'intégration d'applications «third party», réduire les coûts de maintenance et pérenniser le système d'information. Mais il faudra encore des années de réécriture et une standardisation plus aboutie pour parvenir à une intégration industrialisée et à des applications réorchestrables à souhait.

La vision monolithique et rigide de l'ERP ne correspond plus aux réalités et aux nécessités actuelles de changement et d'évolution perpétuels. S'il est impérieux pour les entreprises équipées d'un progiciel de faire de moins en moins de développements spécifiques, de réduire les délais d'implémentation et de mise en œuvre, il leur faut aussi une couverture fonctionnelle de plus en plus large et adaptable. 



L'ERP nouvelle génération ainsi conçu est modulaire et souple, organisé en unités fonctionnelles accessibles via le réseau; il met à profit la réutilisation et répond à une certaine qualité de service définie au préalable.



SOA s'appuie sur des services, qu'ils soient web ou non. Or un service applicatif se conçoit comme une entité à laquelle on fait appel pour rendre un service. Il peut s'agir de fournir le prochain numéro de commande ou de facture dans la séquence, d'envoyer un e-mail à un responsable concerné par l'action en cours ou d'effectuer un calcul.

Mais l'application n'a pas besoin de savoir à quel endroit est hébergé ce service, d'où il vient et ce qu'il devient par la suite. En d'autres termes, ce service devient virtuel, c'est-à-dire qu'on introduit une couche d'abstraction logicielle entre l'application et les services qu'elle utilise.

Cette forme de virtualisation correspond à un autre modèle, celui du SaaS (Software as a Service). En mode SaaS, c'est l'ERP dans son ensemble qui se conçoit comme un service. L'approche devient fonctionnelle: «Je veux passer une commande», «Je dois faire une facture» ou encore «Je vais faire ma note de frais». Peu importe ce qu'il en est de l'application, l'essentiel étant que le service soit rendu au moment où il faut.

Microsoft Dynamics publie l’ensemble des fonctionnalité (standard, verticales ou spécifiques) de l’ERP sous forme de Web Services, MSMQ ou Biztalk).

Considérées initialement comme indépendantes, les applications fournies en mode SaaS sont de plus en plus confrontées à des besoins d’intégration avec des applications existantes, installées sur le site du client.

Aujourd’hui, les applications SaaS sont souvent fournies à la demande d’un département, sans que le service informatique soit impliqué. Le problème de l’intégration intervient plus tard.

Dans Business ByDesign, SAP a privilégié les services web, ce qui permet à ses partenaires des développer des interfaces à la demande. Idem pour Oracle: des points de passage sont prévus pour s’interfacer. Mais en pratique, les services web sont loin d’avoir été adoptés par toutes les entreprises. Pour preuve, le nombre d'autres types de solutions pour développer des interfaces, en s'appuyant par exemple sur le bus Sonic et des serveurs ftp.

Qu’en est-il des implémentations d’ERP en mode SaaS? L’étude Markess International publiée en mai 2009 montre la préférence d’une mise en œuvre en mode SaaS fonction par fonction (comptabilité, finances, gestion des achats et gestion commerciale en priorité). Il est assez rare que l’entreprise implémente l’ERP complet en un seul projet.

Les premières expériences ont montré que le modèle du SaaS est viable: les clients installés vantent l'économie, l’évolutivité et la prédictibilité des coûts. Les PME, en particulier, mettent encore en avant les questions de sauvegarde (réalisation, contrôle et archivage), l'administration et la sécurisation des architectures systèmes et réseaux (accès distants, multi-sites, poste nomades, miroirs, back ups, protection électrique...) et l'optimisation des performances pour l'application ERP.

Certes, on est loin de la question des SOA et du BPM. Mais un projet en mode SaaS reste avant tout un projet informatique pour lequel il est primordial de faire le choix d'un produit et d'un service (intégration, assistance, formation, capacité de personnalisation pérenne...) en prenant le temps d'évaluer le niveau de réponse et de service apporté sur tous les besoins du client.

Une démarche SaaS consiste souvent à externaliser certains services, certaines fonctions de l'IT. Ce qui veut dire que SOA et SaaS s'exercent dans une sorte de continuum.

Aujourd'hui, une réflexion SOA «classique» implique que tout ou partie des services concernés résident à l'intérieur du pare feu, ce qui suppose que les processus métiers correspondants s'y prêtent. Dans une économie en réseau, ce n’est plus toujours possible. La plus-value d’une entreprise peut être la conception d’un produit, pas sa production -qui sera alors sous-traitée. Ce qui implique que l'ERP de production se trouve dans cette autre entreprise. Et qu’il faudra intégrer les données de production de ce partenaire avec le marketing et les ventes de l'entreprise conceptrice.

Bref, les deux approches -SOA et SaaS- sont l'expression du fait que les mêmes fonctionnalités peuvent être soit chez vous, soit à l'extérieur. Une approche SaaS suppose que le système d’information s'y prête… et donc, dans une large mesure, qu'une restructuration de type SOA soit intervenue au préalable.

Prenons l'exemple d'une solution CRM outsourcée. Dans la plupart des cas, la messagerie de l'entreprise reste en interne, ce qui se traduit souvent par une mauvaise intégration des contacts clients entre les deux systèmes. Ceci aura pour conséquence l'obligation de dupliquer les contacts entre les deux applications… au risque de se traduire par une lourdeur inutile, des incohérences entre les deux bases de référence et des réticences des utilisateurs à l'adoption de la solution. On en retiendra que l'intégration entre fonctions IT hébergées en interne et externe doit être pensée au départ. C’est clairement le défi du moment.