Le cahier des charges
Le cahier des charges, ou RFP (request for proposal) ou CCTP (cahier des clauses techniques particulières) va mal, et ce pour plusieurs raisons :
- côté client d’abord, d’abord parce qu’on voit encore des cahiers des charges qui ressemblent à la lettre au père Noël (je voudrais quelque chose de magique qui convienne parfaitement à mon contexte et à mes contraintes et surtout qui ne soit pas cher).
- côté prestataires ou vendeurs, il s’agit bien souvent de faire un copier/coller d’anciennes propositions en faisant attention à bien changer les noms des entreprises et des logos.
Seth Gottlieb a fait le même constat en précisant certaines dérives du processus de sélection via un RFP :
- un nivellement des propositions à l’identique lorsqu’on passe par un RFP, de vraies alternatives apparaissent rarement dans ce cadre.
- les éditeurs et les vendeurs passent plus de temps à qualifier les leads qu’à s’impliquer dans les réponses et dans le processus.
- les bons prestataires et les bons éditeurs sont trop occupés pour répondre à des RFP envoyés à la terre entière, du coup ce ne sont pas les meilleurs qui se présentent à l’appel.
- enfin, le RFP est un processus d’opposition ce qui n’est pas de bonne augure pour la collaboration qui doit nécessairement en découler.
J’en rajoute quelques autres pour le plaisir (mettez les vôtres en commentaire si vous voulez constituer un cahier des doléances) :
- Le RFP qui se prend pour un
catalogue de la Redoute
avec sa centaine de pages, si ce n’est plus. - Un processus de sélection qui n’est là que pour mettre en compétition et faire baisser les prix.
- Un processus qui demande un vrai livrable de cabinet de conseil :
répondez à mon appel d’offre et expliquez-moi tout dans votre réponse : méthodologie, retours d’expérience, l’état de l’art, etc.
(celui-là c’est mon préféré)
Je n’insiste par sur les particularités du processus dans le secteur public qui, pour des raisons louables d’impartialité est tellement contraignant qu’il en induit des processus en parallèle : l’officiel et le off.
Partant de ce constat, que je crois partagé aussi bien par les clients que par les prestataires ou éditeurs (vous me le direz en commentaire si ce n’est pas le cas), je voudrais voir ce que devient le cahier des charges et plus généralement le mode d’achat quand des solutions en mode SaaS entrent dans la danse.
Ces nouveaux acteurs apportent quelques différences notables :
- par définition, la solution SaaS existe et est disponible, elle n’a pas attendu le RFP. Donc c’est à prendre ou à laisser, car la solution SaaS ne va pas évoluer ou changer pour les demandes spécifiques de tel ou tel client.
- conséquence du précédent point, et comme je l’ai déjà indiqué : les forces de vente et d’avant vente des acteurs SaaS n’ont plus rien à voir avec les éditeurs traditionnels : entre une à dix personnes par pays tout au plus pour le SaaS, contre plusieurs dizaines voire centaines de personnes pour un éditeur classique.
- ensuite il faut rajouter une différence importante dans la culture web des acteurs SaaS et la culture Système d’Information des éditeurs.
Les premiers, surtout s’ils ont une offre de service qui s’adresse également aux particuliers, ont une culture de l’audience qui est adapté pour l’adoption par des milliers voire des millions d’utilisateurs. Ici chaque utilisateur doit être convaincu.
Les second ont une culture du lobbying car, dans l’entreprise, c’est quelques personnes qui prennent les décisions pour l’ensemble des employés.
Or, on commence à voir des dossiers pour lesquels les acteurs SaaS ainsi que les éditeurs classiques répondent en même temps. Et c’est là que l’on s’aperçoit de l’inadéquation du cahiers des charges, ou RFP, avec les offres SaaS.
D’abord dans le secteur public : le mode de passation des appels d’offre est presque toujours exclusivement fait pour l’achat de licences perpétuelles. Impossible par exemple d’avoir une solution facturée en fonction de la demande ou du nombre d’utilisateurs, ne serait que parce que le nombre d’utilisateur n’est pas connu avec précision ou parce qu’il faut prévoir exactement la consommation du service (donc aucune élasticité).
Des difficultés existent également dans le privé : le mode de la négociation et du lobbying induit par les RFP avantage les acteurs traditionnels, privant les entreprises de faire des choix de service en mode SaaS.
C’est à juste titre que le Gartner a évoqué le risque que les métiers traitent directement avec les vendeurs de SaaS, car pourquoi mettre la DSI dans boucle si ce n’est pour alourdir le processus ? Avec en plus le risque de se retrouver avec une solution d’éditeur qui sera certes compatible avec les exigences de la DSI mais qui sera en décalage avec les attentes des métiers, ne serait-ce qu’en terme de disponibilité.
Pour maîtriser l’adoption croissante par de petites équipes ou par des départements, la DSI devrait revoir ses modes d’appel d’offre et son processus de sélection en s’ouvrant à des modes de sélection qui mettent l’utilisateur au centre des préoccupations, notamment en mettant en avant une politique de beta testeur de solutions SaaS.
Car il faut être clair : si les salariés avaient un pouvoir de décision, jamais un SAP n’aurait connu la croissance qu’il a eu : il n’y a qu’à voir la tête des utilisateurs quand on leur dit qu’ils auront des écrans SAP …
Quel est l’intérêt, peut-on encore entendre, d’introduire une logique d’audience et d’attention pour des utilisateurs qui, par définition, sont payés pour exécuter des tâches avec les outils que l’entreprise met à leur disposition ?
L’intérêt est pourtant là : quelques personnes motivés et à l’aise avec l’outil de travail sont beaucoup productifs et ils apprécient plus leur travail. Même l’industrie traditionnelle sait çà, et oriente toute la conception de sa production, à l’image du « toyota way », autour du poste de travail.
Il serait peut-être temps que les processus d’achat et de consommation d’IT des entreprises évoluent afin de pouvoir bénéficier du changement de paradigme en cours.
Remarquez que j’ai surtout évoqué le cas du Software as a Service, mais vous pensez bien que la mise en oeuvre de méthodes agiles se heurte aux même difficultés.
Tous les freins sautent, bien sûr, si le mur arrive. Car toutes ces nouvelles façons d’acheter et de consommer de l’informatique se sont adaptées en arrivant après la catastrophe de certains projets, et plus généralement après le constat d’échec de certaines pratiques.
Je me pose donc la question : faut-il systématiquement passer par un échec pour essayer de nouvelles approches ?
Il faut également rajouter 2 modes de fonctionnement :
– au départ on demande à tout le monde de décrire la solution idéale et de lister toutes les fonctions qui pourraient être utiles. L’usine a gaz commence. La suite du projet n’est ensuite qu’une réduction du périmètre pour rendre la solution viable et faisable en moins de n années et dans le budget prévu au départ (même si ca peut déraper un peu …)
– l’approche Saas comme tu le fais remarquer c’est départ très rapide sur la solution (elle peut être Saas ou spécifique) et petit a petit on rajoute les fonctions pratiques. Les nécessaires étant la très vite.
Les 2 approches sont possibles selon les sujets mais c’st surtout la première qui est utilisée …
voici une petite fable sur le sujet : http://www.figer.com/Publications/robprinc.htm
[Reply]