Développement spécifique ou bien progiciel ? Faites votre choix !

capirossi.org | Développement spécifique ou bien progiciel ? Faites votre choix !
Copyright Jérôme Capirossi [email protected]
http://capirossi.org/2008/01/developpement-specifique-ou-bien-progiciel-faites-votre-choix/
Développement spécifique ou bien progiciel ? Faites
votre choix !
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.
page 1 / 3
capirossi.org | Développement spécifique ou bien progiciel ? Faites votre choix !
Copyright Jérôme Capirossi [email protected]
http://capirossi.org/2008/01/developpement-specifique-ou-bien-progiciel-faites-votre-choix/
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.
page 2 / 3
capirossi.org | Développement spécifique ou bien progiciel ? Faites votre choix !
Copyright Jérôme Capirossi [email protected]
http://capirossi.org/2008/01/developpement-specifique-ou-bien-progiciel-faites-votre-choix/
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.
page 3 / 3