Les clés du succès de la sélection de système (3ème partie)

Lors de notre dernière publication nous étions parvenus à la rédaction finale de votre RFP ainsi que votre fichier de requis fonctionnels. Ne nous restait plus qu’à franchir l’ultime étape avant envoi : le choix de la longue liste de fournisseurs de solutions potentielles.

1)      Le nombre

A combien de fournisseurs dois-je envoyer mon RFP?

Selon les standards de l’industrie on envoie son RFP en moyenne à huit fournisseurs. Cette liste se doit d’être ni trop longue ni trop restrictive. Trop longue signifierait la non prise en compte de certains critères restrictifs de votre sélection de système. La correcte application de certains critères de sélection devrait automatiquement restreindre votre liste, de plus n’oubliez pas que l’analyse des réponses est coûteuse en temps et en argent.

Trop restreinte signifierait une vision tout de suite trop ciblée, vous risquez de vous fermer des portes trop tôt. Ensuite il faut prendre en compte qu’en général tous les fournisseurs ne répondront pas, vous risquez dans ce cas de vous retrouver avec une liste bien trop limitée de réponses et ne pas être en mesure de réaliser pleinement l’exercice de comparaison et d’évaluation.

2)      Les critères de sélection de la longue liste de fournisseurs de solutions potentielles

Bien noter ici que nous parlons de fournisseurs et non de solutions. Les solutions sont choisies sur la base de vos exigences fonctionnelles. Il s’agit de choisir votre fournisseur de solution c’est-à-dire celui qui prendra en charge l’implantation, la formation et peut-être le support de la solution post go-live.

  • La situation géographique : Quand c’est possible, privilégiez des fournisseurs dont l’adresse du siège social est à proximité du lieu principal d’implantation de la solution. Ceci limitera les frais de transports et permettra de contrôler le risque de perte des ressources qui pourraient être assignées à votre projet.
  • La taille de l’entreprise : L’envergure du fournisseur doit être proportionnelle aux nombres d’utilisateurs impactés par l’implantation. Typiquement ne pas prendre un fournisseur ayant seulement 10 employés pour gérer une implantation impactant 2000 utilisateurs et inversement n’optez pas pour un fournisseur ayant 40.000 employés pour une implantation touchant seulement 10 utilisateurs.
  • L’expérience du fournisseur dans votre secteur d’activité avec des entreprises de taille similaire à la vôtre : Il est évident qu’un fournisseur ayant des références dans votre secteur d’activité avec des entreprises de taille similaire à la vôtre est un accélérateur non négligeable. Vous pourrez être rapidement rassurez en passant un simple coup de téléphone aux clients référencés. De plus l’intégrateur sera en mesure de comprendre beaucoup plus rapidement les enjeux de votre compagnie.
  • Le type d’hébergement recherché :Les fournisseurs ne gèrent pas forcément tous les types d’hébergement : mode SaaS, hébergé ou « on premise ».
  • Éditeur de la solution ou simple fournisseur : Pour les petites solutions, il n’est pas rare que le fournisseur soit aussi l’éditeur de la solution. Ceci est une garantie de parfaite maîtrise de la solution mais en même temps cela signifie que vous êtes sur une solution de niche donc que vous avez opté pour une solution spécialisée qui potentiellement pourrait poser des problèmes d’évolutivité.
  • La langue de travail du fournisseur
  • Le support et la maintenance : Quel type de support offre le fournisseur?
  • Support technique (mise à jour de la solution, gestion des montées de version…)
  • Gestion des anomalies. Quel est le temps de réponse en fonction de la gravité des anomalies…
  • Gestion des demandes d’évolution
  • Support fonctionnel
  • La stratégie d’implantation : Le fournisseur réalise ou accompagne-t-il simplement la réalisation?
  • Stratégie de formation : Le fournisseur offre-t-il un service de formation? Sera-t-il en mesure de fournir le matériel de formation et le cas échéant assurer les formations?

Les clés du succès de la sélection de système (2ème partie)

Lors de notre précédent post, Les clés du succès de la sélection de système (1ère partie), nous avions évoqué les 1eres étapes clés pour la réussite d’un processus de sélection de système, l’importance du choix des parties prenantes, la compréhension claire à un niveau macro de l’activité de votre compagnie, de ses objectifs à moyen long terme ainsi que le comment la technologie supporte ces objectifs.

Forts de toutes ces informations nous sommes maintenant en mesure de rédiger le RFP en nous appuyant sur la structure suivante :

1)      Présentation : Cette section introduit votre entreprise, ses objectifs, ses activités, sa structure organisationnelle, les interactions entre les différentes entités ainsi que les raisons du RFP.

2)      Etat actuel : Description de la situation actuelle de votre compagnie, les défis majeurs auxquels elle doit faire face dans son dialogue avec votre système d’information. Cette section comprend aussi le paysage applicatif actuel ainsi que le schéma d’architecture technique supportant l’ensemble de vos opérations. Etape cruciale car elle donne à comprendre aux fournisseurs potentiels de solution de façon quasi instantanée les points spécifiques auxquels ils devront s’attacher pour répondre au mieux à votre RFP.

3)      Solutions et services souhaités : Cette section décrit le système cible (Idéalement un schéma d’architecture fonctionnel) et à un haut niveau les requis classés par modules fonctionnels, la liste détaillée complète des requis fonctionnels étant fournie dans un fichier à part. Il est important de présenter ces requis en épousant au mieux la structure logique d’un ERP, cela rendra votre demande plus intelligible et plus aisément adressable par les fournisseurs.

4)      Instructions aux fournisseurs : Cette section fournit des instructions détaillées et vos attentes eues égard aux réponses des fournisseurs :

  • La date attendue pour la confirmation de la participation au processus de sélection
  • Jusqu’à quelle date seront-ils en droit de vous adresser des questions
  •  Format et processus à suivre pour adresser les questions
  • La date limite pour le retour des réponses
  • Le format attendu des réponses ainsi que leur contenu
  • A qui adresser les réponses

 

Vous êtes maintenant en possession de votre RFP ainsi que de votre fichier de requis fonctionnels prêts pour envoi. Il ne vous reste plus qu’à franchir une ultime étape, le choix de votre longue liste de fournisseurs. Ce point sera abordé lors de notre prochaine édition et vous verrez que là encore un certain nombre de standards devront être respectés pour vous garantir la complète réussite de votre processus de sélection de système.

Les clés du succès de la sélection de système (1ère partie)

La sélection de système est un processus long, complexe, douloureux et pouvant s’avérer extrêmement frustrant. Il n’est pas rare qu’au bout de plusieurs mois de travail un dirigeant d’entreprise ne soit toujours pas en mesure de prendre LA DÉCISION, de faire le choix qui impactera de façon durable et profonde le destin de son organisation. Nonobstant ce constat quelque peu alarmant mais malheureusement réaliste il existe des techniques, des méthodes permettant d’éviter cet écueil et de réussir pleinement son processus de sélection de système.

 

1)      Le choix des parties prenantes

Phase essentielle du processus car il sera déterminant pour le bon déroulement des opérations. A minima nous retrouverons ici :

Le sponsor faisant partie du top management, le Président, le CEO et/ou le CFO. Il aura pour mission de donner la direction du projet ainsi que ses fondements et motivations.

Les experts métier chaque fonction d’affaires sera représentée par un expert métier ayant une parfaite connaissance des processus d’affaires et des besoins en terme de soutien technologique

Le chef de projet interne bien souvent réservé à une ressource TI mais pouvant aussi provenir d’une fonction clé des opérations. Bon communicant ayant une très bonne connaissance des contraintes métier, il jouera le rôle de facilitateur ainsi que de leader de la conduite du changement d’un point de vue communicationnel.

Le leader du projet de software selection est un consultant externe expert en la matière. Le choix d’une ressource interne pour la réalisation de ce processus est l’une des raisons majeure des échecs dans le choix d’un système d’information. Les compagnies n’ont pas en interne l’expertise nécessaire pour parcourir toute seule ce processus. Cela demande une connaissance à 360° du marché, de la concurrence, des enjeux à moyen long terme, une expérience éprouvée dans divers secteurs d’activité. Le leader de projet sera le légataire d’une méthodologie éprouvée ainsi que le garant de la réussite du projet.

2)      Les interviews

Elles se divisent en deux grandes parties

1ère partie le niveau macro : Que faites-vous, qui êtes vous, où allez vous, quels moyens vous donnez vous pour vous y rendre?

Cette 1ère partie des interviews s’adresse essentiellement aux dirigeants de l’entreprise. Le consultant aura ici pour but de se représenter le core business de la compagnie. Que fait-elle? Depuis combien de temps existe-t-elle? Quels sont ses principaux challenges, quel est son chiffre d’affaires, sa stratégie de croissance à moyen long terme ainsi que les moyens que l’entreprise se donne pour atteindre ses objectifs. Son niveau de satisfaction à l’égard de la technologie en place. Dans quelle mesure la technologie sera-t-elle susceptible d’appuyer les objectifs de la compagnie.

A la fin de cet exercice le consultant aura une très bonne compréhension du as is aussi bien business que technologique à un niveau macro et saura où souhaite se rendre la compagnie ainsi que les moyens qu’elle se donne pour s’y rendre et bien évidemment la place qu’occupe la technologie dans cette stratégie de croissance ici énoncée.

2mee partie le niveau micro : Par fonction d’affaires nous allons visiter ici le détail des requis fonctionnels.

Les principales fonctions d’affaires sont les suivantes :

  • La technologie
  • La gestion des payables
  • La gestion des recevables
  • La gestion des actifs
  • La gestion de la relation client
  • Les finances
  • Le forecasting
  • La gestion des ressources humaines
  • La gestion de la fabrication
  • La gestion des commandes client
  • La gestion des achats
  • La gestion de l’entreposage et des stocks
  • La gestion de la distribution
  • La gestion du transport
  • La gestion de produit
  • La gestion de projet

 

Chaque fonction sera décomposée suivant une granularité plus fine dite de second niveau :

La technologie

  • Général
  • Sécurité
  • Hardware

La gestion des payables

  • Gestion des factures
  • Gestion des retours fournisseurs

La gestion des recevables

  • Facturation
  • Encaissements

La gestion de la fabrication

  • Gestion des procédés
  • Gestion de la qualité
  • Gestion des BOM

Pour enfin arriver à la granularité de niveau 3 représentant le requis fonctionnel à proprement parlé:

La technologie

o   Général

  • Modèle ASP/SaaS/de nuage
  • Code source est fourni lors de la vente (pour les personnalisations)
  • Capacités d’importation et d’exportation (archivage, systèmes externes)

o   Sécurité

  • Possibilité de menus contextuels selon le rôle de l’utilisateur
  • Accès sécurisé à distance
  • Possibilité d’ouvrir une session unique

La gestion des payables

o   Gestion des factures

  • Possibilité de visualiser les rapports sur les factures
  • Traitement de factures et de fournisseurs à payer sans pièces justificatives
  • Possibilité, après traitement, de modifier la distribution des comptes de facturation

o   Gestion des retours fournisseurs

  • Traitement du retour au fournisseur entièrement intégré à l’entreposage et à la fonction des comptes fournisseurs
  • Instructions spéciales pour les achats auprès d’un fournisseur
  • Prise en charge du processus d’approbation des bons de commande

La gestion des recevables

o   Facturation

  • Imputation automatique du paiement compte tenu de multiples factures
  • Entrée des paiements anticipés des clients
  • Inscription libre de notes liées aux factures

o   Encaissements

  • Bandes de maturité de comptes définies par l’utilisateur
  • Relevés définis par l’utilisateur et classés par ordre chronologique
  • Envoi automatique de factures à des agents de recouvrement internes ou à des agences de recouvrement externes

La gestion de la fabrication

o   Gestion des procédés

  • Conformité des procédés (ISO, SOX…)
  • Traitement des matières
  • Mesure de contrôle de la distribution

o   Gestion de la qualité

  • Suivi de la qualité par lot
  • Gestion des matériaux endommagés
  • Analyse des pannes

o   Gestion des BOM

  • Prise en charge de la suppression massive des composants d’un BOM
  • Prise en charge de produits de substitution ou remplacement au niveau des composants

A la fin de cette seconde partie d’interviews le consultant aura une vision détaillée des requis fonctionnels par fonction d’affaires. Il lui faudra maintenant affiner cette vision granulaire en articulant celle-ci aux business process clés de l’entreprise, ceci lui permettra de prioriser et de pondérer les requis par fonction d’affaires. Cette matrice de requis fonctionnels ainsi recueillie sera le corps du RFP (Request For Proposal) qui devra être envoyé aux fournisseurs de solutions.

Une vision détaillée de la structure du RFP ainsi que du choix des fournisseurs potentiels de solution sera l’objet de la seconde partie de notre post.

Travailler dans un environnement de système validé impacte-t-il le projet ?

L’industrie pharmaceutique est fortement réglementée à travers le monde; en particulier aux États-Unis, en Europe et au Canada. Dans cette industrie, tous systèmes informatiques validés ont un impact mesurable sur les projets. Ces règlementations visent à assurer que les systèmes utilisés sont supportés et ne mettent pas en péril la sécurité, l’efficacité, la pureté et la qualité des produits réglementés.

Vous trouverez dans ce billet, un aperçu des éléments venant s’ajouter à la gestion de projet dans un environnement de système validé en industrie pharmaceutique. La validation de systèmes informatisés met en œuvre une méthodologie réutilisable s’appuyant sur l’analyse des risques réglementaires, fonctionnels et informatiques.

Travailler dans un environnement de système validé ne doit pas être vu comme une contrainte mais plutôt un avantage précieux qui soutient la qualité de la performance et de la production. Le but ultime de tout projet dans un environnement validé est de réaliser et de maintenir la conformité, tout en assurant la performance et la fonctionnalité de ce système. Cette pratique fournit  la preuve que le système informatique fait ce qu’il est censé faire selon les spécifications du système et des procédures d’exploitation.

Dans ce type d’industrie, la phase de tests nécessite une exigence supplémentaire qui est généralement la preuve documentaire des résultats des tests répondants aux exigences de Bonne Pratique de Fabrication qui est un terme utilisé dans cette industrie et d’autres industries réglementées. À titre d’exemple, nous retrouvons dans les  processus qui sont soumis aux Bonnes Pratiques de Fabrication, l’étiquetage des marchandises reçues, les mouvements de stock et les lieux de stockage des stocks.

De plus, la phase de test exige que les activités de tests effectués assurent que toutes les exigences approuvées soient respectées, et que le système se comporte comme prévu aussi bien fonctionnellement que techniquement. Le processus peut se trouver alourdi sachant qu’une signature à l’encre est applicable à tout document qui doit être présenté aux organismes de réglementation.

Vous trouverez ci-dessous des éléments sur lesquels l’attention doit être portée dans ce type de projet :

  • Projet et validation : le plan de contrôle et d’’exécution des activités de validation doivent être documentés ainsi que leur coordination avec la phase de conception et de réalisation. Typiquement, cela comprendra la validation et le plan de test, le plan de qualité du projet et d’autres plans qui sont nécessaires pour gérer et contrôler le projet et la validation;
  • Les procédures : la validation doit être effectuée avec des procédures et des protocoles définis et documentés;
  • Gestion : Le statut de la validation de l’ensemble du système doit être évalué chaque fois qu’une modification lui est apportée, ainsi que toutes les activités de validation nécessaires préalablement définies;
  • Prévention des Défauts : la validation doit se concentrer sur la prévention de l’apparition de défauts dans le processus de développement du système;
  • Indépendance : Un examen indépendant de la documentation de validation du système informatique devrait être mené.

En bref, bien comprendre les éléments ci-dessus vous permettrons d’éviter d’éventuels retards ou points de blocage dus aux réglementations gouvernementales fortement présentes dans l’industrie pharmaceutique.

Comment déployer des processus de gestion de projet dans une organisation « opération »?

Dans le monde des PME, une emphase importante est mise au niveau des secteurs d’affaires.  À travers les années, ces compagnies deviennent très efficaces et optimisées au niveau de leur opération. Le fait d’avoir un focus important au niveau des opérations amène ces organisations à traiter habituellement les changements (projet) en mode opérationnel. L’un des problèmes que cette situation génère est qu’il est difficile de démarrer et de terminer des projets. Comme les priorités opérationnelles changent de façon quotidienne, les travaux qui devaient être faits sur un projet sont souvent tassés au détriment de la nouvelle urgence ou nouvelle demande de projet.

À un moment dans le cycle de vie d’une PME, une transformation, parfois plus importante au niveau de certains processus, systèmes ou outils, est nécessaire.  Afin de réaliser ce type de changement, il est préférable d’instaurer des processus de gestion de projet.  Avoir une bonne pratique en gestion de projet permet de partir les projets sur une bonne base, d’en contrôler l’exécution et de gérer les risques.

Plus facile à dire qu’à faire, n’est-ce pas? Donc, la question à se poser : par quel bout commencer?

Dans un premier temps, il est important de bien comprendre le point de départ.  L’utilisation d’un modèle de maturité en gestion de projet peut être utile afin de comprendre la situation actuelle et la cible désirée.  L’évaluation des ressources humaines doit également être fait: avez-vous seulement des développeurs ou une répartition d’analystes? avez vous identifié vos potentiels gestionnaires de projet. Les profils nécessaires pour entamer ce virage peuvent être différents de ceux existants déjà sur place.  Des plans de formation et/ou certains changements dans l’équipe peuvent être nécessaires.

En fonction de l’urgence et du besoin, il est bon de faire une revue des projets/initiatives en cours et à venir afin de commencer la gestion des attentes des différentes parties prenantes. Une fois prêt à débuter la transition, débutez petit.  Identifiez un projet de taille moyenne qui permettra d’établir les bases de gestion de projet et de définir certains outils (tels que la carte de projet, l’outil de planification ou le suivi de projet).  Pour maximiser les chances de succès, assurez-vous d’identifier la bonne personne qui prendra le rôle de gestionnaire de projet. Une formation et un bon encadrement pourraient être nécessaires.  La gestion d’un projet pour une compagnie qui a un niveau de maturité faible en gestion de projet peut s’avérer complexe. N’hésitez pas à donner un bon encadrement au gestionnaire de projet sélectionné, car le succès de ce premier projet pourrait faire foi du support de la haute direction pour les projets future.

Afin d’augmenter les conditions gagnantes au succès du projet, l’ensemble de l’équipe élargi doit être en mesure de comprendre le langage et la méthodologie de gestion de projet.  Des séances de formation et un coaching peuvent permettre d’amener l’équipe à un bon niveau de compréhension et de communication.  La mise en place d’un comité de direction pour le projet, même s’il est de petite taille, est une bonne idée.  Celui-ci vous permettra d’augmenter l’engagement des lignes d’affaires sur le nouveau modèle de livraison de projet et vous permettra de faciliter la mobilisation de certaines ressources clés.

Finalement, beaucoup d’outils de gestion de projet sont disponibles. Si le niveau de maturité actuel est près de 0, assurez-vous de partir avec le minimum soit, une charte de projet (la portée), une planification minimale et un outil de suivi de l’avancement (le statut et les risques par exemple).  Les autres outils viendront avec l’augmentation de la maturité en gestion de projet de l’organisation.

La diversité culturelle sur les projets

Qu’entendons-nous par diversité culturelle sur un projet ? Entendons-nous la culture d’entreprise, la culture attachée à une langue, à un pays, une région ou encore entendons-nous la culture attachée à une fonction, à un niveau d’éducation, au niveau hiérarchique, à un rôle spécifique sur un projet ? La diversité culturelle est un terme plurivoque, multidimensionnel, polysémique. Il y a une frontière floue, ténue entre ce qui relève de la culture et ce qui relève de l’individu. Sans compter que même dans le cas d’une différence culturelle avérée il est difficile de connaître la source du différentiel.

Dans le cas des français et des Allemands, il nous serait aisé de penser que sur un projet, ces deux cultures entretiennent un rapport particulier à l’implicite et à l’explicite. Pour les uns l’implicite est interprété comme un manque de rigueur tandis que pour les autres l’explicite est le signe de la rigidité, du manque de souplesse. Mais il nous serait périlleux de généraliser à partir d’un cas particulier. Il peut s’avérer après une analyse plus approfondie que ce différentiel culturel n’est pas national, linguistique, mais seulement lié à un autre aspect du projet (la structure des compagnies concernées par exemple).

Il en va de même sur le sens de l’autonomie en Amérique du Nord et en France. On aurait tendance à penser qu’en France le poids hiérarchique est plus important qu’en Amérique du Nord et qu’ainsi c’est une culture qui valorise plus le respect de la hiérarchie que l’autonomie, celle-ci étant vue comme un manque de respect de la hiérarchie. Tandis qu’en Amérique du Nord on valorisera beaucoup plus l’autonomie, le leadership plutôt que le respect de la hiérarchie. Cette valorisation de l’autonomie en Amérique du Nord est interprétée négativement dans la culture française qui y voit plus une marque de l’individualisme de la société américaine. Là encore ce qui au premier abord pourrait être vu et interprété comme une différence culturelle nationale pourrait n’être au final qu’une différence culturelle d’entreprise.

Il est évident que dans une petite entreprise le poids de la hiérarchie est bien moins important que dans une grande entreprise. Enfin et là était mon point, toute cette diversité culturelle est tributaire de l’appréciation individuelle. Au-delà des différences culturelles qui sont toujours sujettes à interprétation, sur un projet ce qui compte le plus c’est la diversité des individus. Car contrairement au slogan des grandes entreprises qui sous le joug de la pression financière des actionnaires voudrait que toute ressource soit remplaçable j’aurais tendance à penser l’inverse, que chaque ressource est unique et apporte un point de vue particulier, singulier sur les projets et que ce point de vue est irremplaçable.

Par où commencer pour bien comprendre les différentes parties prenantes d’un projet?

Vous venez d’arriver sur un projet. Le directeur de projet vous remet une pile de documents afin de vous initier. Vous lisez. Vous essayez de démêler tous les acronymes, de comprendre les enjeux importants et qui sont les personnes impliquées. Concernant ce dernier point, voici quelques éléments à regarder plus attentivement afin de bien comprendre les différentes parties prenantes (« stakeholders ») sur votre projet:

 

1. Regardez les organigrammes

Demander à voir l’organigramme du projet. Ce document vous permettra de voir qui sont vos collègues et surtout à qui vous pourrez aller poser vos premières questions. Faites-vous expliquer les différentes boîtes au besoin. Prenez des notes. Par exemple, Jean-Paul travaille pour la compagnie depuis 20 ans. Il pourra vous être une mine d’or d’informations! De plus, regardez attentivement la structure du comité de pilotage (« steering committee »). Qui sont les joueurs décideurs? Finalement, n’hésitez pas à consulter les organigrammes de la « business » aussi. Après tout, votre projet aura fort probablement un impact sur eux. Portez une attention aux différentes lignes d’affaires, le nombre de paliers hiérarchiques, le nombre d’employés par groupes, etc. Les jeux de pouvoirs et politiques ont toujours une incidence sur un projet.

2. Faites votre propre analyse des parties prenantes détaillées

Afin d’avoir une compréhension plus exhaustive, il est recommandé de faire une analyse des parties prenantes. Le but de cette analyse est d’identifier tous les groupes (internes et externes) impliqués ou touchés par le changement. Une bonne gestion des parties prenantes est essentielle pour assurer l’adhésion au projet. De façon concrète, vous pouvez organiser une rencontre avec des joueurs clés de chacun des groupes. La rencontre devrait durer environ une heure pendant laquelle vous discuterez des caractéristiques propres au groupe: nombre d’employés, situation géographique, profil typique, nombre d’années d’expériences moyens, défis potentiels, préoccupations, etc. Vous pouvez aussi vous aider à l’aide de persona. Un persona est un visage « humain » que vous attribuez au groupe. Fouillez dans Google Image et prenez une photo type! Vous pouvez lui donner un nom exemple : Sam. Et chaque fois que vous parlerez de ce groupe ou rôle en particulier, vous utiliserez le nom de Sam avec sa photo. Cela aidera à personnaliser vos interventions et à humaniser vos activités.

En bref, bien comprendre les joueurs clés et les groupes impactés sur un projet vous permettra de non seulement gagner du temps, mais aussi de mieux cibler vos activités de gestion du changement et d’augmenter l’adhésion au projet.