Est-ce qu’une DSI doit répondre à un besoin métier avec un développement spécifique ou bien par l’acquisition d’un progiciel ? Cette question revient souvent dans l’identification des alternatives de choix de solutions en amont des projets. J’avais, il y a quelques années posé cette question à Guy Lapassat, lors d’une conférence qu’il avait donnée à l’IAE Paris. En résumé, sa réponse était qu’il s’agissait d’un choix tactique.
Ne considérons que les cas où la question se pose de manière équilibrée, à l’exception des projets de BPR ou de refonte globale qui, en général, pour des raisons stratégiques donnent lieu à la mise en place de progiciels de gestion intégrée.
Avantage au progiciel ?
A priori, l’option progiciel présente les avantages suivants :
- Une rapidité de mise en oeuvre due à des spécifications par écarts, plutôt que des spécifications complètes, et à un paramétrage versus du développement,…
- Un processus qui reflète l’état de l’art et que l’on peut étendre
Pourtant les projets de progiciels buttent souvent sur les écueils suivants :
- Le Métier ne parvient pas à s’adapter au processus du progiciel ou demande trop de développements spécifiques
- L’architecture n’est pas adaptée et requiert un effort d’intégration conséquent
- Les Fournisseurs ne développent pas d’offres adaptées
La réalité vraie
Dans les faits, on constate que le développement spécifique est une option encore largement choisie.
En effet, certaines sociétés ont bâti leur succès sur des développements spécifiques desquels elles ont tiré un avantage concurrentiel important, telle Amazon vis à vis de son concurrent d’alors Barnes & Nobles. A l’époque, l’offre de progiciels CRM n’était pas suffisament souple pour évoluer avec la réactivité requise au rythme d’Amazon.
Cependant, mener à bien un développement spécifique nécessite de maintenir au sein d’une entreprise des compétences sur une ou plusieurs architectures techniques. C’est souvent hors de portée de PME qui entreprennent des développements très localisés peu industrialisables.
D’autres sociétés ont échoué à mettre en oeuvre des Progiciels, ou bien les ont mis en oeuvre dans des conditions d’utilisation difficiles en supportant des coûts importants. En effet, leurs divisions métier fortement attachées aux usages locaux ne parvenaient pas à se mouler dans des processus plus communs, alors qu’elles étaient bien souvent à l’origine du choix de la solution.
Les échecs des projets de progiciels ne sont pas uniquement dus à la résistance au changement des utilisateurs. Souvent, il y a inadéquation entre l’architecture du SI de l’entreprise et l’architecture du progiciel, ce dernier préférant un mode boite noire qui offre une étanchéité technique. Dans ce mode, l’intégration par les données est fréquemment préférée à l’intégration par les fonctions.
S’ensuit que l’effort de développement d’interfaces, qui accroît souvent les redondances des contrôles, augmente exponentiellement avec le nombre d’interfaces. Dans un SI dont l’architecture est basée sur une intégration par les données, fonctionnant en flux poussés, les coûts d’intégration d’un progiciel orienté front-office sont nécessairement élevés (Dans un tel contexte, certains progiciels faits de manière intelligente tirent leur épingle du jeu en back-office).
Les fournisseurs enfin se focalisent sur les fonctions métier offertes par leurs progiciels, mais pas assez sur l’architecture. A côté des grands éditeurs qui se concentrent de plus en plus, les éditeurs petits et moyens offrent souvent la déclinaison de leur offre sur une seule architecture. Certaines offres d’éditeurs de solution pour PME ont été acquises par des grands groupes dans des environnements de SI mal adaptés.
Enfin, lorsque l’existant est un développement spécifique ou un progiciel bien intégré dans le SI, ils constituent une inertie très forte au changement, et ajoute à l’option développement spécifique.
En conclusion
De mon point de vue, la réponse à l’alternative, développement spécifique ou progiciel, est davantage du niveau stratégique que du niveau tactique.
La culture des divisions métier doit évoluer afin d’intégrer plus facilement les contraintes d’utilisation des progiciels.
La DSI peut soutenir cette évolution en déclinant une offre de services à l’utilisateur et au poste de travail, tels une structuration des intranets et du help desk, qui favorise cette adaptation.
Le développement et la gestion de la relation entre DSI et éditeurs est stratégique, elle doit être entretenue sur le plan des fonctions offertes et sur le plan de l’architecture. En effet, les DSI ne peuvent se passer d’être de véritables partenaires des métiers, au moment du choix comme sur l’ensemble de la démarche d’analyse des besoins. Car les métiers sont souvent la cible des éditeurs, et certains choix, comme des solutions Saas, se font sans la DSI, alors qu’il nécessitent un effort d’intégration.
L’infrastructure d’intégration doit être adaptées au développement et à la maintenance d’une multiplicité d’interfaces. Ceci ne requiert pas seulement de mettre en place un outil d’échange performant, mais également de faire évoluer l’architecture des applications en évitant la redondance des contrôles.
Enfin, l’exploitation des progiciels, même externalisée demande à l’entreprise un savoir faire relatif à la gestion du service rendu et au pilotage du fournisseur.
C’est par le développement d’une démarche stratégique coordonnée, au niveau fonctionnel, architectural et technique que l’entreprise répondra en connaissance de cause à l’alternative et bénéficera réellement des avantages attendus lorsqu’elle optera pour le progiciel.
Powered by ScribeFire.