Effixens a assisté hier aux Trophées des Achats 2015

Hier soir nous avons pu assister à la traditionnelle soirée des Trophées des achats.

Les dernières éditions nous avaient parus un peu ternes et convenues. La soirée d’hier soir a été plus animée.

On retiendra surtout une vraie avancée dans l’ère de la collaboration et l’innovation fournisseur. En effet, et ce quelque soit les catégories récompensées, beaucoup de dossiers présentaient des innovations issues de la collaboration entre service achats, fournisseurs et prescripteurs. Une mention spéciale à la société SEB qui a réussi une collaboration tripartite dans le domaine du marketing qui est bien souvent l’une des chasses gardées où les achats ont du mal à s’imposer.

L’autre grande tendance est l’apport du web dans l’évolution de notre métier.

Hier aussi on a parlé de collaboration et d’innovation.

Mention spéciale à la dynamique équipe très féminine de l’Oréal.

 

Effixens était présent à Nantes pour la journée consacrée aux Enjeux de la Supply Chain

 

Plus d’une centaine de personnes représentant des entreprises de l’ouest de la France étaient réunies jeudi dernier à Nantes pour cette journée dont le thème était

« Les Enjeux de performance de la Supply Chain et des Réseaux Logistiques collaboratifs »

Une première partie de la journée a été consacrée à des exposés sur des retours d’expérience de grands groupes tels Alstom et Airbus mais également de société comme Gruau, Henaff..

Une  expérience de mutualisation a tout particulièrement retenu mon attention. Celle du  GIE de mutualisation logistique mis en place à l’initiative de Henaff dans l’ouest Cornouaille

Quelques bonnes pratiques sont ressorties de cette journée d’échange

  1. C’est un domaine d’excellence. Il faut déjà être très bon en logistique avant de se lancer dans ce genre de projet.
  2. C’est un projet stratégique d’alliance d entreprise à entreprise qui doit se baser sur la confiance, la réciprocité, le long terme.
  3. Ne pas confondre supply chain étendu et supply chain collaborative
  4. Chaque  type de marché a des natures de collaboration différentes
  5. Plus les flux sont internationaux plus ils vont imposer de la collaboration

Concernant les outils les bonnes pratiques auxquelles nous croyons chez Effixens ont été soulignés en particulier cette recommandation : Il faut coller impérativement au standard de l’outil. Le reste doit être fait extra système.

supply chain nantes

La journée s’est terminée par un excellent exposé de Kevin Crowston

Retour sur la soirée de présentation du livre blanc CDAF des SI Achats

Hier soir j’ai pu assister comme 500 autres personnes (acheteurs, mais aussi financier et DSI) à ce qui nous avait été annoncé comme « la grande soirée des SI achats »

Nous attendions une restitution objective et sans langue de bois d’une véritable étude sur l’état de l’art des SI achats en France….

Premier étonnement : 6 éditeurs seulement présents. Il en manque et non des moindres… ou sont-ils ? Ont-ils refusés de payer pour figurer dans l’étude ? Nous nous contenterons donc d’un décryptage de ces 6 éditeurs :

  • Ariba
  • Bravo solution
  • Coupa
  • Ivalua
  • My procurement
  • Synertrade

Heureusement page 18 du livre blanc qui nous a été remis on découvre une palette plus importante d’éditeurs mais il en manque encore beaucoup…

Seconde déception : Les clients témoins. Encore une fois que des très grands comptes. Personnellement j’aimerais que ces grandes messes des achats laissent aussi un peu la parole à des entreprises de tailles intermédiaires. Les clients représentés :

  • Carrefour
  • BPCE
  • Sanofi
  • RATP

La soirée (un peu longue à mon goût et manquant d’interactivité) était partagée en deux grandes parties.

Dans la première partie la parole a été donnée aux quatre clients représentés sur scène, dans la seconde partie c’était le tour des éditeurs.

Côté client même si cela n’a pas été souligné sur quatre représentés, deux ont fait le choix du module e-procurement de leur ERP pour gérer le processus « procure-to-pay » et tous ont souligné dans les critères importants la connectivité entre le SI achats et l’ERP.

Peu mis en avant également le procure-to-pay ne couvre chez la plupart que les achats « indirects ».

Dans les facteurs clés de réussite on a pu noter que le fait d’avoir été accompagné pour mener une phase d’avant-projet (4 à 5 mois) étaient un des critères importants de réussite. Cette phase permet de définir un plan directeur court, moyen et long terme mais aussi de préparer la conduite du changement en donnant la parole aux futurs utilisateurs.

L’autre recommandation à retenir est de « restez sur le standard produit » quitte à travailler avec l’éditeur sur l’évolution de son standard. Ceci est devenu un prérequis puisque tous ces produits sont maintenant en mode SaaS.

POC ou pas POC ? Payant ou non ? Dans la phase de sélection ou une fois le produit sélectionné ? Le débat est ouvert.

Tout d’abord pour les non-initiés qu’est-ce qu’un POC (Proof Of Concept) ? C’est le fait de faire une maquette qui permettra de valider que le produit répond bien au besoin. J’ai personnellement un avis très partagé sur le sujet (ce sera l’objet d’un prochain article de blog) En effet pour avoir été au cours de ma carrière des deux côtés (parfois du côté du couple intégrateur/éditeur, parfois du côté client) au cours de mes quelques dizaines de projets j’ai pu constater ceci :

  • Le POC a un coût (pour l’éditeur mais aussi pour le futur client), coût que dans tous les cas le client va payer,
  • J’aime à dire que « le diable se cache dans les détails », j’ai vu nombre de projets ou malgré un temps considérable passé en maquettage on découvrait des problèmes importants en cours de projet,
  • Les éditeurs sont rodés à ce genre d’exercice et savent souvent vous emmener là où ils veulent durant le POC.

Une alternative au POC, possible maintenant que les solutions sont en mode SaaS, est la mise à  disposition du produit pour le tester durant un temps déterminé (selon les modules concernés et vos souhaits cela peut prendre différentes formes, par exemple certains clients d’Effixens ont pu tester un module de e-sourcing et enchères sur un ou deux dossiers de consultation en réel et pas seulement en simulation).

Cela va vous permettre entre autre de vérifier que l’ergonomie facilite une prise en main rapide, sans formation (il me semble que c’est l’une des attentes exprimés), que le chargement de vos données est facile et vous laisser le temps nécessaire pour simuler vos processus.

Quelques conseils ont retenus mon attention car ces aspects passent souvent au second plan dans le processus de sélection : Intéressez-vous de près au support post projet, allez visiter les data centers et centre de help desk.

Les éditeurs avaient ensuite chacun quelques minutes pour présenter leur société puis une phase de questions réponses devaient permettre de mieux connaitre l’offre de nos amis éditeurs. Le débat est resté très général chacun s’exprimant à tour de rôle sans véritable débat ou échange avec les clients.

Si vous souhaitez mieux connaître ces solutions mais aussi celles des éditeurs non présents, je vous propose de vous référer à notre étude détaillée des solutions qui vous intéresseraient en nous contactant ici

Seule annonce de la soirée : Bravo solution  qui annonce couvrir désormais l’ensemble du processus « procure-to-pay » avec sa solution.

Mieux nous connaitre …. Effixens.fr.

Négliger son RACI, Une pelle pour creuser sa tombe (Fin)

Comme je le faisais remarquer dans l’article précédent, il faut que le RACI soit clair et détaillé. Ceci implique que le RACI doit s’attacher aux tâches et aux profils, et bien sûr au mode de réalisation du projet.

RACI et tâches

C’est finalement le travail le plus facile à faire. En général, un projet est organisé en phases successives (par exemple : « design, réalisation, test, mise en œuvre, support ») qui sont coordonnées (par exemple : « gestion de projet, coordination fonctionnelle, coordination technique »). En détaillant chaque phase et chaque module de coordination, on arrive à un niveau suffisant pour le RACI. Les deux écueils à éviter sont :

  • Un découpage trop macro (par exemple : « comité de pilotage »).
  • Un découpage trop micro (par exemple : « création de la version 1 du compte rendu de comité de pilotage », « envoi de la version 1 du compte rendu de comité de pilotage », « lecture du compte rendu de comité de pilotage », …).

Mais alors, comment savoir si on est à la bonne maille ou si on doit, soit regrouper, soit détailler ? C’est simple :

  • Si une tâche a plus d’un R ou d’un A, ou qu’on a une option pour l’un quelconque des rôles (par exemple : dans un cas il est C, dans un autre il n’est rien) c’est qu’elle doit être détaillée pour lever l’ambiguïté.
  • Si plusieurs tâches similaires en thème ou en fonctionnalité adressent les mêmes profils, et que ces profils ont les mêmes rôles quel que soit la tâche, ceci signifie qu’on peut grouper les tâches.

Un RACI est un outil vivant. Si de nouvelles tâches sont identifiées en projet, il faut penser à les inclure. Ceci peut poser un problème lorsque le RACI fait partie des éléments contractuels d’un projet. Il faut dans ce cas exiger que le nouveau RACI soit approuvé comme avenant contractuel et l’acter au niveau des organes de gestion du projet. Ce point n’est pas négociable.

Si vos soldats, d’audacieux qu’ils étaient auparavant, de-viennent timides et craintifs, si chez eux la faiblesse a pris la place de la force, la bassesse, celle de la magnanimité, soyez sûr que leur cœur est gâté ; cherchez la cause de leur dépravation et tranchez-la jusqu’à la racine.

(Sun Tzu – L’Art de la guerre – Article 9 : De la distribution des moyens)

RACI et profils

Le RACI va jeter une lumière crue sur les rôles et responsabilités de chacun des acteurs du projet. A ce titre, on peut dire que c’est un outil clivant. Deux écueils menacent le RACI.

  • L’approche binaire : Les deux seuls profils qui apparaissent en colonne sont « Client » et « Fournisseur » sans plus de détail. En projet, chacun est donc libre de s’organiser comme bon lui semble dans son périmètre. On rencontre ce type de RACI assez fréquemment chez des éditeurs qui ont un RACI type pour la mise en œuvre de leurs solutions, ou des sociétés de service dans leurs propositions commerciales. Ceci est insuffisant pour l’exécution du projet. Deux options s’offrent dans ce cas :
    • Exiger un RACI plus précis : C’est la solution recommandée. Le client va mentionner clairement les différents rôles présents dans son organisation (en fournissant les fiches de poste associées le cas échéant), et le fournisseur va segmenter son équipe en rôles.
    • Faire du RACI un livrable de projet : cette solution est à éviter car elle est postérieure à la conclusion du contrat et peut s’avérer complexe à gérer. Je me souviens avoir vu un client ne pas valider le RACI après en plus de 60 versions en 4 mois !
  • L’approche nominative : C’est un travers qui se retrouve chez certains clients. Chaque personne est nommée en tant qu’individu. En général, une telle approche dénote soit une totale méconnaissance des rôles au sein de l’entreprise, soit une volonté de ne pas décider, soit une incapacité à aller au bout du processus. On a typiquement ceci dans des entreprises :
    • Qui se sont réorganisées mais qui pour des raisons « politiques » ont laissé telle ou telle personne conserver des responsabilités qu’elle ne devrait plus avoir (exemple : on a centralisé les achats de fournitures de bureau de l’entreprise sur une seule personne, mais Mme Machin conserve quand même les achats de fournitures de bureau pour son service parce qu’elle a l’oreille de la Direction et que personne n’a voulu lui ôter cette friandise après une énième jérémiade du type « on ne me fais plus confiance ! »).
    • Dans lesquelles les individualités sont fortes et les rivalités interpersonnelles aussi. Chacun a son pré carré dans lequel il fait tout en se comportant en « M. Le Comte ».

RACI et mode de réalisation du projet

C’est ici que l’exercice prend une complexité particulière et requiert à la fois de l’expérience et de la capacité d’abstraction. Deux modes existent : le forfait et la régie.

Rappelons au passage que le mode forfait n’est pas assimilable à une obligation de résultat, pas plus que la régie ne l’est à une obligation de moyens (ce sont des termes juridiques, bien souvent dévoyés, et dont l’intérêt majeur est de déterminer qui a la charge de la preuve d’une inexécution ou d’une mauvais exécution d’une obligation contractuelle).

Trêve de digression et sans entrer dans les détails, il est important de comprendre qu’une prestation au forfait entraîne une obligation de livrer « complet – conforme » la prestation décrite au prix décrit, dans le délai annoncé et en suivant le planning contractuel. Le prestataire est donc libre des moyens qu’il met en œuvre si tant est qu’il respecte son obligation. Le client participe activement pour les tâches qui lui sont dévolues en respectant le planning (par exemple : participer aux réunions et expliquer comment se déroulent les processus, fournir un fichier des articles …).
Dans le cadre de la prestation en régie, c’est le client qui joue le rôle du prestataire au forfait. Le prestataire en régie va fournir la capacité de travail avec une ou des ressources dont il est garant du bon niveau d’expertise.

Rappelons au passage que l’Homme de l’Art a un devoir général de conseil et d’alerte à l’égard de son client et ce quel que soit le mode choisi – forfait ou régie. Ce devoir peut aller jusqu’au refus d’exécution ou au retrait si les circonstances l’exigent.

Forfait ou régie, le mode influe peu sur les tâches elle-même (à l’exception notable du suivi des charges en j/H et coûts), mais l’impact est non négligeable sur les R et A (en potentiellement sur les C et I) au sein de chaque tâche. Il y a donc une véritable revue de cohérence à faire pour éviter que ne soient sous la responsabilité du prestataire ou du client soit des tâches qui n’ont rien à y faire dans ce mode d’exécution, soit des tâches qui sont affectées au mauvais profil.

Prenons quelques exemples :

  • Forfait de mise en œuvre d’une solution SAP par une équipe complète du prestataire
    • Signature du relevé des temps des consultants du prestataire par le client : IMPOSSIBLE.
    • Suivi de présence des consultants par le client : IMPOSSIBLE, doit être fait par le prestataire.
    • Paramétrage de la solution : Aucune action du client sur aucun des rôles RACI (sauf dérogation prévue au contrat), ce dernier ne peut que vérifier que le résultat du travail du prestataire sur la solution produit bien fonctionnellement le résultat attendu.
    • Validation des spécifications fonctionnelles : seul le client peut le faire.
  • Prestation de développement en régie d’une étiquette code-barres sur laquelle le prestataire fournit un développeur
    • Adaptation du paramétrage de la solution : Seulement si la ressource fournie par le prestataire est annoncée comme étant capable de de faire.
    • Modification d’autres formulaires ou coordination technique : IMPOSSIBLE, la ressource est dédiée à la fourniture de la prestation décrite.
    • Signature du relevé des temps du consultant du prestataire par le client : OBLIGATOIRE

Si vous n’êtes pas familier de l’exercice, le mieux est de vous faire accompagner en expertise par un cabinet de conseil comme Effixens.

Commencez par vous mettre au fait de tout ce qui concerne les ennemis ; sachez exactement tous les rapports qu’ils peuvent avoir, leurs liaisons et leurs intérêts réciproques ; n’épargnez pas les grandes sommes d’argent ; n’ayez pas plus de regret à celui que vous ferez passer chez l’étranger, soit pour vous faire des créatures, soit pour vous procurer des connaissances exactes, qu’à celui que vous emploierez pour la paie de ceux qui sont enrôlés sous vos étendards : plus vous dépenserez, plus vous gagnerez ; c’est un argent que vous placez pour en retirer un gros intérêt.

(Sun Tzu – L’Art de la guerre – Article 13 : De la concorde et de la discorde)

Avant de clore cette série d’articles, je voudrais évoquer le cas particulier des normes de développement.

Certains clients très experts disposent de ces normes qui décrivent la façon dont les développements doivent être conduits (exemple : pas de boucles imbriquées, pas de requête en « SELECT * » sur une base de données, cartouche normé …). Ces normes s’imposent au prestataire, que ce soit dans le cadre d’une prestation au forfait ou en régie. Ceci n’a pas d’impact en RACI pour une double raison :

  • Ce sont des exigences du client qui doivent être prises comme faisant partie de la spécification du besoin. Elles sont donc traitées comme le sont les spécifications.
  • l’Homme de l’Art dans le cadre de son devoir général de conseil et d’alerte à l’égard de son client doit proposer la solution la plus pertinente au meilleur coût. Si le respect de ces normes entraine une dégradation de la qualité du livrable final, ou si, par l’application de normes différentes ou plus récentes, le produit final est meilleur, il conviendra de le mentionner clairement dans les spécifications afin que le client puisse opter ou non pour le respect de la norme.

Voilà, cette série d’articles est désormais terminée. Il y aurait encore mille choses à dire mais vous voici désormais mieux armé.

Mieux nous connaitre …. Effixens.fr.

Négliger son RACI, Une pelle pour creuser sa tombe (2)

Comme je l’ai indiqué dans l’article précédent, les rôles A et R ne sont en rien liés directement aux concepts franco-français de maîtrise d’œuvre (MOE) et maîtrise d’ouvrage (MOA) … mais comme l’acronyme est anglo-saxon, il y a une certaine logique. On peut donc dire que le RACI va découler :

  • Du projet et de son organisation (ce qui est traité ici),
  • De la liste des tâches,
  • … Et bien sûr, du mode de réalisation.

RACI et projet

Le RACI s’insère dans l’ensemble contractuel du projet, c’est-à-dire liant directement plusieurs parties à la réalisation d’un objectif commun.

Prenons ici un exemple pour illustrer le propos.

La société [NUMBER1] veut mettre en place un portail de services à l’attention de ses clients. Après étude, elle a retenu:

  • Un éditeur de solution [PORTAIL],
  • Un prestataire [PREST] pour la mise en œuvre et les développements du portail,
  • Un hébergeur internet [HEBERG].

[PREST] a la possibilité de faire appel soit à ses ressources, soit à des ressources externes en sous-traitance ou en expertise (incluant [PORTAIL] … si nécessaire). En termes de RACI, on aura la conformation suivante :

RACI - Overview
Ce qui est vrai avec un prestataire externe … est tout aussi vrai avec un prestataire interne (c’est le cas des grands groupes dans lesquels les prestations informatiques sont déléguées soit à une filiale dédiée à l’IT, soit à une division spécialisée dans l’IT).

Pourquoi deux RACI différents ? Simplement parce que le client [NUMBER1] – dans le cas du schéma – n’a rien à voir dans les relations contractuelles entretenues par le prestataire [PREST] avec ses sous-traitants et experts.

Que se passe-t-il si le client [NUMBER1] exige de connaître et approuver le recours à la sous-traitance par [PREST] ? En terme de RACI … rien. Le prestataire [PREST] est la seule partie au contrat et ses sous-traitants ne sont pas liés directement au client. Rappelons que le RACI s’attache à la fonction, pas à la personne. Si la ressource sous-traitée est une fonction, elle apparaît comme telle au RACI et considérée comme une ressource de [PREST] (transparent pour le client). En terme contractuel, c’est affaire de juristes (et donc hors de notre propos).

Que se passe-t-il si le client choisi un mode d’exécution en régie plutôt qu’une prestation au forfait ? Une fois de plus, en terme de RACI … rien. Rappelons le encore, le RACI s’attache aux fonctions et aux rôles et responsabilité au sein d’une organisation. Dans le cadre de la régie, ce qui change vraiment, c’est la façon de gérer le projet du côté du client.

En réalité, et nous le savons tous, si les fournisseurs font correctement leur travail (et ceci dès la proposition commerciale), il y aura pour chaque relation contractuelle un RACI propre … et c’est là que va se situer le problème.

RACI_Detail
Prenons ici l’exemple de l’hébergeur [HEBERG] et imaginons qu’il fournisse à son client [NUMBER1] une prestation de type cloud. Toute une partie de la relation contractuelle qui est liée à l’exploitation (une fois la solution mise en œuvre et livrée par le prestataire [PREST]) est hors du périmètre du projet. Toutefois, les obligations décrites dans le contrat peuvent aussi être une contrainte. En effet, il se peut que le contrat ne couvre pas la période de projet ou … qu’il la couvre avec des obligations particulières et un RACI précis.

Chaque RACI individuel (ici …. 0.1, 0.2 et 0.3) peut interagir avec le RACI global (RACI #1). Si tel est le cas, il va donc falloir pour les tâches impactées soit ajuster les contrats, soit en tenir compte dans le RACI global.

Comme vous le voyez … il faut que le client [NUMBER1] connaisse très bien ses contrats (ou qu’il soit bien accompagné), et sache le cas échéant anticiper les besoins futurs ou ne pas se bloquer pour des évolutions futures.

On peut en déduire une fois de plus que ce qui est important dans le RACI est la notion de tâche accomplie (ce qui ne signifie pas ‘déléguée’) et pas la notion de MOE / MOA.

RACI et organisation de projet

Il faut garder à l’esprit qu’un projet est avant tout l’exécution de la relation client-fournisseur dans laquelle chacun doit tout faire pour que le projet soit livré complet, conforme, dans les délais et budgets impartis.

Le RACI a aussi pour but de garantir que chacun reste dans son rôle sur son périmètre de responsabilité. Détaillons et réduisons un peu le schéma du début.

RACI_Relation_Detail
Si on regarde de façon un peu plus macro le projet, on voit au premier coup d’œil que chacun est responsable de ses propres ressources, c’est-à-dire les ressources qu’il a directement mises au service du projet (dans certaines organisations plus complexes, il y a des chefs de projets techniques, infrastructure, métiers …. qui reportent tous au chef de projet principal).

Dans le cas qui nous intéresse, le chef de projet [PREST] est globalement responsable vis-à-vis du chef de projet client [NUMBER1] ce qui est cohérent puisque « R (= Responsible [for doing]): celui qui fait ».
Au niveau général, le chef de projet [NUMBER1] est comptable du résultat « A (= Accountable): celui qui rend des comptes » vis-à-vis de la société qui l’a mandaté pour ce projet.

La problématique de la délégation de faire

Attendre les ordres en toute circonstance, c’est comme informer un supérieur que vous voulez éteindre le feu : avant que l’ordre ne vous parvienne, les cendres sont déjà froides
(Sun Tzu – L’Art de la guerre – Article 3 : Des propositions de la victoire et de la défaite)

Comme j’ai eu l’occasion de le dire dans mon précédent billet, la délégation ne se conçoit pas sans contrôle efficient, et ceci est d’autant plus vrai pour celui qui est en position A.

Toute la difficulté réside dans la capacité à donner un niveau suffisant d’autonomie pour que le projet ne soit pas sclérosé par l’administration, tout en maintenant un niveau de contrôle satisfaisant.

Croire que ceci se fait uniquement sur la base d’un reporting … c’est se bercer d’illusions. Je sais à quel point les organisations sont friandes de reporting, mais il ne faut pas craindre d’affirmer encore et encore que seul l’échange verbal basé sur un questionnement pertinent et la capacité à ne laisser aucune zone d’ombre peut vraiment offrir ce niveau de contrôle. Il ne faut jamais hésiter à poser et poser encore les questions qui dérangent jusqu’à l’obtention d’une réponse satisfaisante.

Le RACI doit donc être suffisamment clair et détaillé pour que chacun comprenne ce qui est dans son périmètre d’action et c’est ce que nous verrons dans le prochain billet.

La suite … est ici.

Mieux nous connaître … Effixens.fr.

Nouvel accord de partenariat entre Effixens et Market Dojo

Effixens et Market Dojo signent un accord de partenariat afin de diffuser les offres cloud de l’éditeur anglais sur la France
Effixens renforce son offre de service autour des SI achats en signant un accord de distribution sur la France de l’ensemble des offres cloud de l’éditeur Market Dojo.

3 solutions sont disponibles

Market dojo une solution de e-Sourcing permettant de mener des opérations avec ou sans enchères

Catégorie Dojo une solution de catégorie management

Innovation dojo un portail d’échange avec les fournisseurs autour d’une recherche d’innovation

Anne Marie Guillemoteau présidente d’Effixens déclare «Nous recherchions initialement une offre pouvant s’adresser aux PME qui n’ont pas la capacité d’investir dans une solution e-Sourcing complexe et chère. Depuis un an et demi nous avons testé les solutions de Market Dojo. Cette offre s’adresse à la fois aux entreprises n’ayant ni le budget ni le temps de mener un projet classique mais également à des entreprises souhaitant tester l’utilisation d’un outil d’appel d’offres ou d’enchères ».

D’après Jean Michel Mabille co-fondateur d’Effixens « Ces solutions n’entrent pas en réellement concurrence avec les offres actuellement sur le marché. En effet ici pas de projet de mise en œuvre, pas de durée d’engagement mais en contrepartie des fonctionnalités bien déterminées dans une interface conviviale».

Market Dojo propose une offre souple permettant soit l’achat d’une ou plusieurs licences sur une durée d’engagement minimum d’un mois, soit des crédits permettant de mener une opération ponctuelle sur plusieurs mois.

Alun Rafique, co-fondateur de Market Dojo ajoute «Nous avons eu un fantastique succès sur le marché britannique et il est temps de commencer à déployer notre potentiel à l’étranger. Effixens est le meilleur partenaire pour nous aider à devenir incontournable sur le marché français».

Vous pouvez gratuitement tester l’application en vous inscrivant en ligne sans aucun engagement ou nous demander de vous organiser une démonstration personnalisée en nous contactant ici

Négliger son RACI, Une pelle pour creuser sa tombe (1)

Pour être intervenu « en pompier » sur des projets en crise, je suis à chaque fois surpris par la vacuité, le manque de précision ou l’inadéquation de la matrice des rôles et responsabilités (quand ce n’est pas son absence pure et simple) lorsque je fais un audit préalable au plan d’action. Faire un lien unique avec l’échec du projet est réducteur (une « catastrophe » est rarement l’effet d’une seule cause). Toutefois cette matrice reste une des pierres angulaires d’un projet. C’est la raison pour laquelle je vais l’aborder en détail, mais compte tenu du sujet, je vous propose de voir les différents aspects en plusieurs fois.
.

Revenons donc aux fondamentaux.

Qu’est-ce que la matrice des rôles et responsabilités ? Elle est plus connue par son acronyme anglo-saxon: RACI.

C’est donc un outil synthétique qui décrit le « qui fait quoi » au cours d’un projet (ou d’un ensemble de projets). Elle ne s’attache pas aux personnes dénommées (Pierre, Paul, Jacques) mais à la fonction dans l’organisation (Chef de projet, Responsable application, Responsable infrastructure…) qui est la structure pérenne d’un projet (les personnes passent, les organisations restent).

RACI_small

A quoi sert un RACI ? Le RACI est un des outils qui sécurise le déroulement d’un projet en indiquant à chaque acteur du projet le rôle exact qu’il occupe sur une tâche, une activité ou dans un processus donné. Il y a donc une notion de segmentation et de complétude, mais le RACI ne décrit jamais comment cette tâche, cette activité ou ce processus se déroule.

Vu sous cet angle ceci apparaît simple, mais il en est tout autrement. Le premier écueil est celui de la terminologie anglo-saxonne portée en français intelligible.

Que signifie RACI ?

Commençons déjà par ce qui est simple :

  • Vide. On l’oublie un peu facilement, mais une case d’une matrice RACI peut être vide et c’est tout à fait normal. Dans ce cas, aucune action n’est requise.
  • I (= Informed): Informé. J’aborderai plus loin la question de l’émetteur de l’information. toutefois, bien que la notion soit simple à comprendre il ne faut jamais oublier que  …. « Trop d’information tue l’information ».
Trop d'infomation tue l'information

Crédits photo – M. Jacques Darolles – Publié avec sa permission – Panneau d’Officier Mécanicien Navigant d’un Boeing 747-200

  • C (= Consulted): Consulté. Contrairement à l’informé, la personne consultée à l’obligation de réagir, c’est à dire de répondre à la consultation. Ceci ne signifie en rien qu’il doit toujours apporter une information additionnelle, et la réponse peut être « je n’ai pas de remarque à faire ». C’est donc un contributeur.

Le silence ne vaut jamais réponse à quelque niveau de la matrice que ce soit. Le silence est dangereux car l’interprétation fréquente qui en est faite est « le silence vaut approbation » … ce qui est faux et dangereux. Si la personne consultée ne répond pas, les causes peuvent être multiples (de l’absence de compréhension de la question auquel peut se greffer la crainte de demander, à la volonté délibérée de refuser de répondre pour ne pas manifester son opposition ou pour ne pas endosser une responsabilité). Comme disait la grand-mère de Madame le maire de Lille … « Quand c’est flou c’est qu’il y a un loup ».

 Ensuite viennent deux concepts plus difficile à appréhender:

  • R (= Responsible [for doing]): celui qui fait. Pourquoi n’ai-je pas utilisé le mot de « responsable » ? simplement parce que ce concept n’est pas celui qu’il faut mettre en lumière. Le R dans un projet est celui qui porte la responsabilité de faire le travail, c’est à dire celui qui le réalise.

 Cette personne est donc chargée de mener à bien l’ensemble des tâches avec les moyens qui lui sont dévolus. Si ces derniers ne sont pas suffisants (temps personnel ou capacités personnelles si elle est seule, quantité, qualité et disponibilité des ressources affectées si elle coordonne une équipe… ), elle doit prendre toutes les mesures utiles et nécessaires dans son périmètre de responsabilité. Si ces mesures excèdent ce périmètre de responsabilité, il devra y avoir une escalade afin que des mesures correctives soient prises par la hiérarchie.

Peut-on avoir plusieurs R ? Si on considère R comme responsable, on voit que la question n’a pas de sens car plusieurs responsables = pas de responsable. Vous voyez pourquoi j’ai centré R sur « celui qui est chargé de la réalisation ». Si on a plusieurs R sur une même activité, il faut segmenter cette dernière pour déterminer par tâche un périmètre unique de responsabilité.

  • A (= Accountable): celui qui rend des comptes. Le A dans un projet est celui qui porte la responsabilité d’approuver la conformité du résultat du travail effectué. Alors pourquoi ne pas l’avoir appelé « Approbateur » ou « Autorité » comme le suggère Wikipedia ? Simplement une fois de plus parce que ces termes sont trop réducteurs.

Finalement, on peut se dire que c’est génial d’être A, on attend sans rien faire et on sanctionne les R ….. faux et archi-faux !

Un A ne peut pas être passif car la délégation (de faire) ne se conçoit pas sans contrôle. Nous le verrons dans les prochains épisodes, mais le A est celui qui a la tâche la plus compliquée car sa tête est sur le billot, mais ce sont bien souvent les autres qui font que la hache tombe ou non. C’est ce qu’on appelle …. L’art du commandement.

Considérez qu’avec de nombreux calculs on peut remporter la victoire, redoutez leur insuffisance. Combien celui qui n’en fait point a peu de chances de gagner !

(Sun Tzu – L’Art de la guerre – Article 1 : de l’évaluation)

Peut-on avoir plusieurs A ? Au niveau le plus haut d’un projet ou d’un ensemble de projet, ceci n’est pas possible. Il y a une personne unique ou une entité qui est chargé au final d’approuver et de rendre des comptes pour l’ensemble. A des niveaux inférieurs, et si tant est qu’il y ait une segmentation claire des aires de responsabilité, c’est tout à fait possible, mais au niveau de l’activité (la ligne du tableau), il en va comme du R, il n’y aura qu’un seul A.

Peut-on cumuler A et R ? Cette conformation est tout à fait possible. C’est même la conformation normale de certaines activités de projet comme par exemple l’organisation d’un comité de suivi projet par le chef de projet.

Alors au final, qui va informer, A ou R ? Si vous avez compris le raisonnement, ce peut être aussi bien A que R, et c’est une question de contexte (sensibilité de la communication, contexte politique ou opérationnel, accord explicite entre A et R ….). On peut décider que lorsque l’information est opérationnelle / fonctionnelle, elle est plutôt du ressort de R et quand elle est organisationnelle / managériale, elle est plutôt du ressort de A. Une autre façon de voir serait de dire que l’information descendante (vers les opérationnels) est du ressort de R et l’information ascendante (vers la direction) du ressort de A. Dans tous les cas, l’information doit être univoque et concertée.

Je vois déjà poindre le nez des concepts de maîtrise d’oeuvre et maîtrise d’ouvrage …. et c’est donc la raison pour laquelle je vais au plus vite m’éloigner de ces notions très franco-françaises. Pourquoi ? Tout simplement parce que MOE et MOA ne sont pas assimilable à R et A. Ceci sera d’ailleurs traité dans le prochain billet.

La suite … est ici.

Mieux nous connaître … Effixens.fr.

Ubister retenue par SAP pour distribuer les solutions Ariba

Nouvelle étape dans le développement de la société Ubister. Le revendeur et installateur de solutions de gestion, en mode SaaS, vient d’être choisi par l’éditeur allemand SAP, leader du marché du cloud computing, pour distribuer ses solutions achats à destination des PME, développées par sa filiale Ariba.

« La confiance accordée par SAP et Ariba est une réelle reconnaissance du travail réalisé depuis plusieurs années par notre équipe de consultants, confirme Pierre Gueguen, P-dg d’Ubister. Cela témoigne de notre volonté de poser la première pierre d’un département SI Achats Cloud et d’accompagner, avec encore plus de proximité, nos clients dans leur stratégie d’outsourcing et de flexibilité au quotidien. »

Pour mener à bien cette stratégie, Ubister a noué un partenariat avec la société Effixens, spécialisée dans les systèmes d’informations achats. « Nous interviendrons sur la partie métiers aux côtés d’Ubister chargée du déploiement technique, précise Anne Marie Guillemoteau, directrice associée. La formation et l’accompagnement personnalisé des acheteurs qui vont utiliser le logiciel Ariba sont deux éléments essentiels de réussite. »

Monique Ventura-Delatour, chargée des ventes des solutions SAP/Ariba auprès du réseau des partenaires, confirme la volonté de l’éditeur allemand d’accompagner Ubister dans son processus de diversification.

« Nous partageons cette vision à long terme qui consiste à muter du statut de prestataires de solutions techniques vers les métiers du conseil et de l’expertise en continue. Elle prend tout son sens avec la richesse offerte par les fonctionnalités des solutions achats Ariba. »

Contact presse : laure.camus@ubister.fr – tél. : + 33 (0)2 96 24 54 25 – www.ubister.fr

A propos d’UBISTER :

Ubister a été fondée en 2010 par Pierre Gueguen et Nathalie Sarrey. La société est Partenaire Gold de SAP et n° 1 en France pour la mise en place de l’ERP proposé en mode SaaS, SAP Business ByDesign. Basée à Rostrenen (22), Ubister s’appuie sur quatre agences en région : Lorient (56), Valence (26), Rennes (35) et Paris (75).

A propos d’EFFIXENS :

Effixens est un cabinet de conseil spécialisé dans l’assistance à la mise en place des ERP et des outils SI métiers dans les domaines des achats et de la logistique. Basé à Laval (53) et Paris (75),il a été fondé en 2011 par Anne-Marie-Guillemoteau et Jean-Michel Mabille.

 

Les habitudes des voyageurs professionnels

Dans son édition du 29 septembre 2014, Fortune a publié une étude intéressante en coopération avec Travel+Leisure sous l’intitulé, « Business Travel Trend Report » qui devrait intéresser tout particulièrement les Travelex Managers.

Au delà des quelques tops habituels et du nombrilisme nord américain de certaines questions (par exemple 62% des personnes questionnées sont membres du TSA PreCheck), des tendances se dégagent.

D’une part, il y a les habitudes des voyageurs professionnels:

  • 71% ne voyagent qu’avec un bagage cabine
  • 40% ont recours au room service
  • 54% incluent dans leur voyage professionnel un voyage personnel (ils étendent la période et payent les frais personnels, mais utilisent le billet AR pro)

Autre tendance lourde, la montée en puissance de la connexion WiFi en vol, 33% l’ont déjà utilisé.

Enfin, il reste le palmarès des apps:

  • 53% utilisent Google Maps
  • 22% Kayak
  • 21% Expedia
  • 15% Skype (l’effet « Snowden » a-t-il joué ?)

mais on trouve aussi – et c’est assez logique pour des voyageurs professionnels:

  • Seatguru
  • Uber
  • Gateguru

Enfin dans les gros points noirs, on retrouve le trio classique:

  • L’absence de place pour les jambes
  • les retards
  • et presque à jeu égal, le service client inefficace, l’embarquement chaotique et le manque de place dans les compartiments à bagages.

Étonnamment, on ne trouve peu de choses sur  l’influence des programmes de fidélité hormis un classement qui est un peu étonnant.

Mieux nous connaître … Effixens.fr.