Résumé en Français








télécharger 0.73 Mb.
titreRésumé en Français
page9/21
date de publication08.07.2017
taille0.73 Mb.
typeRésumé
ar.21-bal.com > loi > Résumé
1   ...   5   6   7   8   9   10   11   12   ...   21

Recommandations

Pour la construction


Il existe deux facteurs de réussite pour un « RFP » :

  • Poser les bonnes questions : Décrire de façon claire et juste, les besoins réels de l’entreprise.

  • Les poser aux bonnes personnes : Ne pas limiter la consultation à 2 ou 3 fournisseurs, élargir cette liste, publier le « RFP » sur Internet et dans la presse le cas échéant (formulaire F1).


Plus la liste des fournisseurs consultés est grande, plus le travail de dépouillement sera difficile, et moins les fournisseurs seront motivés pour répondre. L’objectif de la ``grille`` est justement de faciliter ce travail, pour celui qui appelle et pour ceux qui répondent.

La course aux standards


La recherche de solutions qui respectent un certain nombre de normes va permettre :

  • D’assurer la compatibilité avec les équipements existants.

  • D’assurer la compatibilité avec des équipements futurs.

  • C’est à dire, d’augmenter la pérennité de la solution.


La difficulté est de déterminer ces normes. Il est relativement aisé de vérifier la compatibilité avec l’existant, et cela doit être une condition du « RFP ». Par contre pour le futur, il est nécessaire de comparer les normes proposées avec le marché.

La notion de normalisation suit des directives techniques établies ou validées par un organisme de normalisation. (voir en annexe : Organismes de normalisation)

La notion de ``standard`` ne suit qu’une seule et unique loi, celle du marché. (Avec ou sans normes associées).

Le choix d’une solution pérenne ne passe pas nécessairement par le choix de celle qui supporte le plus de normes. L’analyse de la validité ou de l’utilité des normes annoncées peut nécessiter le recours à une expertise externe. Toutefois la grille de réponse de ce « RFP » propose une alternative, en demandant une liste d’autres industriels ou éditeurs du marché qui supportent les normes annoncées. Il est possible de demander en complément la liste des produits disponibles sur lesur leds marché qui sont inter opérables avec les normes annoncées, mais ceci est à réserver pour les aspects techniques les plus sensibles.

(voir en annexe Concept de Standards et de normalisations)

Exemple, voici deux demandes presque ``identiques`` :

  1. Des « switch » (commutateurs) Ethernet réseaux qui supportent de façon optimale des micro-ordinateurs XYZ sous protocoles IP et Microsoft®, avec cartes réseaux 3COM® 3c90x et 3c90xB, ainsi que des « IP-phones » Cisco® 7960+ (Switch intégré) avec alimentation électrique fournie par le câblage UTP (paire torsadée RJ45). Le câble existant est dérivé d’une catégorie 5 mais seulement sur 4 conducteurs (au lieu des 8 habituels). Veuillez fournir la liste des normes supportées par la solution proposée.

  2. Des « Switch » Ethernet compatibles avec les normes IEEE 802.3u-1995 (100BaseT) et IEEE 801.3af.

La (1) est plus longue et semble moins professionnelle, mais elle est aussi beaucoup plus sûre et plus ouverte, c’est celle que je recommande vivement. Dans cet exemple, la norme 801.3af qui alimente électriquement des périphériques Ethernet ne fonctionne que sur 8 fils. (la solution propriétaire Cisco fonctionne sur 4 fils, mais Cisco supporte aussi le standard IEEE 801.3af, ce qui peut prêter à confusion)

L’indépendance technologique (cas des logiciels libres « Open source ») ?


Pour les solutions professionnelles, la plupart des « RFP » réclament des réponses avec des logiciels basées sur des standards ou références du marché, par exemple : Microsoft®. Je salue et félicite sincèrement Bill Gates et sa compagnie pour les logiciels et travaux réalisés, et surtout pour l’ingéniosité de ses équipes du Marketting. Je recommande régulièrement des solutions de Microsoft. Toutefois, émettre un « RFP » en imposant une solution Microsoft est à mon avis une véritable hérésie. Un ‘client’ ne veut pas une solution Microsoft, il souhaite en général une solution :

  • Qui réponde à ses besoins techniques,

  • pérenne dans le temps,

  • exploitable facilement par ses équipes existantes,

  • compatible avec les applications existantes et envisagées.


Evidemment, la réponse à ces critères semble souvent s’imposer et il est tentant de l’introduire dans le « RFP ». Toutefois, il est important de maintenir un esprit d’ouverture et de laisser le fournisseur tirer ses propres conclusions sur la base des indications et conditions introduites dans le « RFP ».

Voici un autre exemple dans un contexte différent. Une solution du supervision intégrée de réseaux basée sur des grands standards du marché (HP Openview, Tivoli, Infovista, etc.) semblera le meilleur choix. Mais même au sein de grandes entreprises, les connaissances nécessaires au maintien et au développement de cette solution reposeront sur un (très) petit nombre de personnes. Les fonctions utilisées représentent généralement 20% des capacités du progiciel. En cas de perte (départs) des compétences nécessaires, il sera fastidieux et coûteux de retrouver et de reconstruire les aptitudes nécessaires. Mettre en place une solution maison beaucoup moins ambitieuse, basée sur un assemblage de solutions « open source » (« Freeware ») présente exactement les mêmes risques. Par contre les économies d’acquisition et d’exploitation peuvent être du simple au triple (ou plus, mais pas à fonctionnalités égales).

A contrario, la tentation de mettre en place des ``bricolages`` maison, basés sur des logiciels non coûteux, peut aboutir à des surprises sur les coûts de mise en service, et aussi parfois sur des déceptions quant à la qualité des services rendus.

En conclusion, peu importe si le logiciel est libre ou payant. Ce qui importe, c’est de maîtriser les investissements réalisés, les bénéfices escomptés (financiers et non financiers) et de disposer des compétences nécessaires pour l’exploiter correctement (internes ou externes).

Je recommande d’ouvrir ce « RFP » aux entreprises SSLL ou SS2L (Sociétés de services en logiciels libres).

Les logiciels libres ont au moins l’avantage de ne pas nécessiter la demande contractuelle d’un dépôt des codes sources en cabinet notarié. (voir en annexe Répertoire utile pour un RFP)

Sous-traitance (« Outsourcing »)


L’organisation du « RFP » est indépendante de la volonté ou non de mettre en place une sous-traitance partielle ou complète. Il est important de pouvoir aussi comparer une solution « outsourcing » avec une solution « in sourcing ».

Toutefois je recommande aux PME de toujours envisager la sous-traitance pour les activités très spécialisées qui sont trop éloignées du métier corps de l’entreprise, mais pas à n’importe quel prix, ni dans n’importe quelles conditions.

  • Ce « RFP » va systématiquement réclamer le chiffrage pour l’exploitation en sous-traitance des solutions proposées, tout en laissant la liberté au mandant de ne pas la retenir.

L’objectif est d’éviter une sous-évaluation de l’ « OPEX » par l’émetteur.

Pénalités


Ce « RFP » ne prévoit pas de réclamer des pénalités en cas de retards ou autres. Le mandant (rédacteur du RFP) peut en solliciter, mais je recommande de ne pas en exiger, à moins d’être certain d’une prolifération des offres. Un cadre est prévu dans le « RFP » pour permettre aux soumissionnaires de proposer des pénalités de retard. Ceci permet de disposer d’un critère supplémentaire quant au sérieux des propositions.

  • Sans pénalités significatives, toute offre qui garantit des délais ou des niveaux de performances ne peut pas être considérée comme sérieuse, y compris provenant de maisons ou sociétés prestigieuses.

Recommandations pour le dépouillement

Organisation


Les 2 derniers onglets du « RFP » (qui ont été masqués avant l’émission), comprennent un exemple de grille récapitulative. Il suffit de consolider cet onglet et ceux des autres réponses dans un document Excel unique, pour constituer le récapitulatif d’évaluation.

La construction de la grille récapitulative est la première étape du dépouillement. Cette grille peut contenir des informations subjectives et servira de référence pour la comparaison des offres.

La partie spécifique à un fournisseur peut lui être communiquée (éventuellement épurée des critères subjectifs) pour lui permettre de vérifier l’absence d’erreur (dans son offre ou dans la grille). Mais je recommande vivement d’éviter de transmettre l’ensemble de la grille avant la clôture de l’appel d’offre. La plupart des directions marketing des soumissionnaires non retenus seront très désireuses de connaître leur positionnement, c’est un service à leur rendre qui pourra compenser leur travail (et leur déception).

Je sollicite de la part des utilisateurs éventuels de cette grille, qu’ils m’envoient leur RFP et la grille récapitulative, afin de publier ces résultats sur Internet, et le cas échéant compléter ou modifier le modèle. (ITrfp@kotte.net)

Sélection


Préférer le ``mieux disant `` au ``moins disant`` !

Il faut également étudier les solutions qui dépassent le budget prévu. Celles qui correspondent au budget peuvent à terme se révéler moins économiques, si elles ne répondent pas aux besoins.

« Simple is beautiful » ! La solution la plus sophistiquée risque aussi d’être extrêmement contraignante.

(Voir en annexe :Coûts d’une solution)

``Le mieux est l’ennemi du bien``, c’est l’exemple d’Ethernet et de Token ring (voir en annexe Ethernet, force et faiblesse). Cet adage est particulièrement approprié pour les PME.

Logiciels ou solutions jeunes


La grille de réponse doit vous permettre d’identifier les produits jeunes. Ils souffriront généralement d’un manque de références (clients), mais cela ne veut pas dire qu’ils doivent être écartés d’emblée. Si l’application et son coût semblent bien adaptés aux besoins, alors il convient juste de négocier des conditions plus sécuritaires pour :

  • La pérennité

  • Réaliser un contrôle de la santé financière de l’entreprise.

  • « Software » : Obtenir le dépôt des sources chez un notaire ou similaire, cessibles sans frais en cas de faillite ou d’arrêt de maintenance de la solution applicative (disparition des développeurs).

  • Les défauts de jeunesse

  • Contrat de garanties avec fourniture des corrections des défauts (« Bugs ») gratuitement et dans des délais contractuellement raisonnables (sur une période de 6 mois à 2 ans).

  • Négocier la fourniture des mises à jour suivantes à des conditions avantageuses.

  • La compatibilité (avec votre environnement et vos besoins)

  • Réaliser une phase d’essai, en grandeur réduite ou réelle (quand cela est possible), généralement avec frais réduits, le plus souvent déductibles en cas de commande définitive.


Il faut bien entendu adapter les exemples de précautions ci-dessus en fonction des solutions concernées. Il est tout à fait possible d’obtenir des solutions jeunes qui présentent finalement moins de risques qu’une solution ancienne. Les ``vieilles`` entreprises aussi se font racheter ou déposent le bilan…

Expertise


Dans la mesure du possible les grilles de réponses annexes fourniront des indicateurs pour permette une sélection des offres. Toutefois il est recommandé de consulter des experts indépendants pour le dépouillement des offres.

Dans certains cas le dépouillement risque de mettre en balance deux produits ou deux technologies :

  • Utiliser des dossiers comparatifs existant sur le marché. (presse spécialisée, laboratoires)

  • Réaliser une maquette et tester les produits. (solution qui peut être onéreuse, il est possible de trouver des accords avec des laboratoires de tests, mais cela implique des délais)

  • Obtenir une mise en production conditionnelle. (comme pour une solution jeune, mais ceci nécessite de faire un choix sur une des solutions)


Ces recommandations peuvent être étendues aux solutions critiques pour l’entreprise, ou dont les besoins d’intégration ou d’adaptation seront importants.

  • Car une fois en place, il sera difficile ou impossible de revenir en arrière.

Chapitre 3
1   ...   5   6   7   8   9   10   11   12   ...   21

similaire:

Résumé en Français iconResumé Maya Husseini Ayoub [ francais]
«verre au chalumeau», animé par le Maestro italien Luccio Bubacco à Sars-Poteries (France)

Résumé en Français iconRésumé : Cette étude sur les processus de production urbaine du Val...

Résumé en Français iconRésumé : Noms communs et noms propres. Les points les plus importants...

Résumé en Français iconM aïa Grégoire Odile Thiévanaz Professeur de français langue étrangère...

Résumé en Français iconBeauté Prestige International (Groupe Shiseido)
«mètre d’argent» à l’Institut Français du Merchandising / Janus du Commerce à l’Institut Français du Design

Résumé en Français iconCours de français à Alliance française de Dnipropetrovsk, cours privés...

Résumé en Français iconLe français reconquiert l’Algérie
«C’est le paradoxe. On donne des visas à des trabendistes [trafiquants sur le marché noir, ndlr] et on les refuse à des types comme...

Résumé en Français iconProgramme de français : Le français et les langues anciennes
«Langues et cultures de l’Antiquité» et «Culture et création artistiques» en lien avec les langues anciennes et l’histoire»

Résumé en Français iconRésumé a partir des travaux portant sur l’image des points de vente,...
«information» des sites web, mais aussi la capacité des dimensions classiques du concept d’image des magasins à être appliquées aux...

Résumé en Français iconProgramme de français








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com