|
|
Management |
Bien
négocier la qualité des logiciels |
Devant les défauts qui, selon les entreprises, entâchent les logiciels, examen des règles à suivre pour se prémunir et réduire les problèmes dès la négociation. (Mardi 27 août 2002) |
|
Les entreprises, ce n'est pas
nouveau, se plaignent (voir cet
article pour un exemple parmi d'autres), du niveau
de qualité des logiciels qu'elles utilisent, particulièrement
lorsqu'elles font l'acquisition de solutions intégrées,
pour lesquelles les attentes en la matière sont
encore plus fortes.
Comment se traduisent ces reproches ? Principalement en
matière de failles de sécurité, d'ampleur
des bogues, mais aussi et surtout du trop grand cloisonnement
des solutions de différents éditeurs, leur
faible interopérabilité du fait de l'absence
de standard.
A la décharge des vendeurs, beaucoup de problèmes
surgissent lorsqu'une entreprise tente de personnaliser
à l'excès, d'adapter finement à ses
besoins, un outil du marché (surtout quand il s'agit
d'une solution intégrée), mais il reste
néanmoins vrai que les erreurs des logiciels, quand
elles sont effectivement patentes, n'épargnent
pas les plus grands éditeurs (Microsoft, Oracle,
SAP ou Computer Associates, par exemple, selon étude
du magazine CIO sur l'année 2001) et de surcroît
donne le plus souvent lieu, aux dires des entreprises,
à des correctifs insatisfaisants.
Les
étapes de la négociation
Dans
un tel paysage, l'étape de négociation avec
l'éditeur, lors de l'achat d'une solution, s'avère
primordiale, et doit impliquer les DSI, qui parfois se
voient court-circuités par les éditeurs
au profit des directions générales.
En matière de négociation, qu'il s'agisse
d'une réduction importante sur le coût de
licence, de formation ou consulting gratuits, plusieurs
points doivent être pris en compte, et notamment
autour des quatres thématiques suivantes qui sont
autant d'étapes de la négociation.
1) Bien impliquer les acteurs de la négociation
Cela signifie tout d'abord réunir l'ensemble
des personnes qui pourront apporter des arguments utiles
dans la négociation, afin de former, assez en amont,
une équipe préparée. Ensuite, cela
implique d'inclure, outre l'entreprise concernée
et l'éditeur, les rôles des partenaires (intégrateurs,
consultants) dans le contrat d'achat.
2) Prendre en compte les spécificités
du projet
Evoqué plus haut, le problème d'une
trop grande exigence d'adaptation de l'outil aux besoins
fins de l'entreprise peut être anticipé en
précisant avec la plus grande clarté les
besoins. Par ailleurs, les coûts de maintenance
et de gestion doivent être également prévus,
qu'ils impliquent l'éditeur lui-même voire,
comme nous l'évoquons plus haut à propos
des phases conseil et intégration, un partenaire-tiers.
Le coût global inclut également des coûts
cachés issus de problèmes spécifiques,
que nous détaillons plus bas.
3) Tirer profit de sa position face à l'éditeur
Nous prendrons deux exemples: le premier consiste
à tirer profit, le cas échéant, de
la position sur le marché (et notamment sur le
secteur d'activité de l'entreprise) de l'éditeur.
Faire jouer la concurrence, même en exagérant
son importance, peut fonctionner si le vendeur tente de
pénétrer un nouveau marché et n'en
connaît pas encore parfaitement toutes les caractéristiques.
Le seconde exemple provient du constat, tenu notamment
par le Meta Group, du fait que les entreprises achètent
souvent, dans l'objectif de faire des économies,
des licences supplémentaires. Or, cela peut s'avérer
économiquement défavorable suivant l'habilité
de l'éditeur, qui trouve là une occasion
de prendre le jeu en main. Préférablement,
la négociation lors de l'achat d'un logiciel du
prix (fixé alors contractuellement) des achats
futurs (plan pluriannuel par exemple) de licences supplémentaires,
est potentiellement source de réduction de coût.
4) Prévoir les conséquences de problèmes
imprévus
Cette dernière thématique/étape
nous ramène au sujet de la qualité: le contrat
doit bien sûr mentionner quelles contreparties (financières
ou sous d'autres formes) l'entreprise recevra en cas de
non respect du Service Level Agreement, qui doit couvrir
une variété de points de qualité,
quelle est la durée du support de l'éditeur,
etc.
Plus spécifiques sont les points autour de l'utilisation
du logiciel liée à des changements dans
le système d'information (transfert sur d'autres
postes ou serveurs, par exemple) ou des besoins de sauvegarde
(copie de secours du logiciel): de tels usages occasionneront
peut-être des pénalités pour l'entreprise.
Encore une fois, mieux vaut prévoir avant.
Autre cas de figure pouvant figurer dans le contrat: la
faillite pure et simple de l'éditeur. Dans ce cas,
une clause peut par exemple assurer à l'entreprise
la main sur le code source du logiciel, afin qu'elle assure
elle-même, ou via un tiers, l'évolution
du produit.
D'une manière générale, la qualité
du logiciel (et la qualité du service associé)
ne peut se négocier efficacement que lorsque des
indicateurs précis de mesure de la qualité
ont été mis en place par l'entreprise, ceci
afin d'identifier les points à prendre particulièrement
en compte, mais aussi de fournir arguments et exemples,
lors de futures négociations.
|
|
|