Tag Archives: ERP

l’acte de la signature manuelle reste important sur les projets !

22 avr

importance des signatures formelles sur les projets

En lisant l’article de Tim In gram-Smith sur PMHUT, j’ai essayé de comparer son vécu avec ses clients externes à mon expérience ur des projets informatiques internes à l’entreprise.

En fait, je dois reconnaître que notre position de collègues entre informaticiens et représentants métiers/business en lieu et place d’une relation client-fournisseur entre deux entreprises change quelque peu la donne mais pas autant que l’on pourrait le penser de prime abord.

En fait, les projets les plus réussis sur lesquels j’ai travaillé avaient des objectifs très clairs, documentés par écrit et un engagement fort du management.

sign offCe fut par exemple le cas lors de l’implémentation d’un progiciel de gestion intégré (Enterprise Resource Planning – ERP) au niveau mondial en 18 mois dans une grande multinationale. Le directeur du programme (dont je dirigeais le PMO) s’est assuré de cette clarté d’objectifs en les documentant et les faisant signer par le comité exécutif du programme et par son sponsor, le directeur financier de l’entreprise.

Cette initialisation du programme fut critique à notre réussite: Elle nous a donné un périmètre clair, des objectifs agréés et mesurables, des moyens définis et approuvés tant pour les ressources internes qu’externes, et des engagements forts de support au changement du top management.

Ce programme de déploiement d’ERP comportait également un large volet optimisation et unification des processus et réorganisations des fonctions centrales, régionales et pays de la finance. Tous les processus financiers redéfinis par l’équipe projet furent signés manuellement par les responsables métiers de l’entreprise (contrôleurs financiers des pays, des régions et centraux; responsables de la comptabilité, de la facturation, des achats…).

Une signature manuelle reflète à mon avis un engagement bien plus fort qu’un courrier électronique d’approbation.

Businesswoman Reading a WhitepaperPersonnellement, avant de signer manuellement un document, je le lis de manière très attentive. Il arrive même souvent que je demande une vérification à un expert du domaine en question de mon équipe pour les aspects techniques ou business. Mon sentiment reste qu’une signature manuelle a plus de valeur qu’une approbation électronique. Je réalise qu’il s’agit très certainement d’une perception erronée puisque de nos jours de simples SMS peuvent être pris en compte devant un tribunal, mais je ne suis certainement pas le seul à être victime de cette perception. Et, la perception EST la réalité à laquelle le chef de projet doit souvent faire face. Cela changera-t-il avec les générations Y ou millénium nées avec Internet et les communications mobiles ?

Comme Tim le mentionne dans son article, les tentations sont nombreuses de démarrer sans signatures formelles.

Nous les expérimentons également sur les projets internes, notamment l’excuse des délais imposés, la pression du management et des collègues, et la peur de laisser des employés inoccupés:

1. les délais imposés sont toujours de mauvaises raisons !

deadline“Toute proposition de solution qui ne peut être prête pour le 1er janvier ne nous intéresse pas!”. J’ai été témoin, et même partie prenante je le reconnais maintenant, de nombreuses décisions de choix de projets ou de solutions techniques basées sur des critères de disponibilité prévisionnelle. Certains composants auraient mieux répondu aux besoins business mais semblaient prendre trop de temps. En informatique, un exemple typique est d’essayer à tout prix de réutiliser une application développée dans un service pour un but précis dans d’autres circonstances et pour d’autres objectifs. “Cette application marche bien en Europe, il n’y a pas de raison pour qu’elle ne marche pas en Asie où nous commercialisation les mêmes produits…”. En effet, cela paraît logique et séduisant: moins de développement et de tests, disponibilité des compétences, rapidité d’obtention de la solution…

Hélas, le temps d’adaptation de la solution au nouveau contexte est trop souvent sous estimé et, de plus, l’adéquation de la solution aux besoins de ses futurs utilisateurs largement surestimée avec une prise en compte limitée des contextes, marchés, et cultures différentes. Il en résulte souvent une insatisfaction des nouveaux utilisateurs, ou des délais de mise en service proches au final des autres solutions qui auraient pu être choisies sans ce focus initial sur les délais.

2. la pression du management et des collègues même bien intentionnée est souvent mauvaise conseillère.

douleurLà aussi, même si ces pressions partent de convictions sincères des personnes de supporter la “bonne solution”, elles sont souvent le résultat de vues partielles de la situation ou des objectifs complets du projet.

Elles sont aussi teintées de considérations plus terre à terre de disponibilité des compétences requises pour chaque solution, de luttes de pouvoir interne, de désir de développement de nouvelles compétences dans son département, d’affectation des ressources au niveau global du portefeuille de projets ou de l’entreprise.

On ne peut les ignorer, mais elles ne doivent pas obscurcir notre vision et nous éloigner des critères agréés de choix de la meilleure solution pour votre projet.

3. la volonté d’utiliser à tout prix les ressources disponibles.
Image courtesy of suphakit73 / FreeDigitalPhotos.net

Image courtesy of suphakit73 / FreeDigitalPhotos.net

Autre élément que Tim mentionne dans son article et qui est très important: Le sentiment de devoir à tout prix utiliser les ressources disponibles et non affectées qui est très fort et assez légitime du point de vue du management de l’entreprise.

Mais, du point de vue du projet:

  • Ces ressources ont-elles les compétences requises?
  • Sinon, combien de temps faudra-t-il passer à les former et cela est-il même faisable?
  • Si elles sont disponibles et ont les compétences, est-ce une raison suffisante pour démarrer sans approbation formelle du projet?
SMPP

Partenaire de DantotsuPM

Mon expérience est mitigée.

En fait, si une confiance réciproque et forte existe entre business et informatique, on peut démarrer des projets de tailles réduites, des prototypages, ou du développement incrémental en boucle rapide sans signature formelle.

Mais, sur de gros projets informatiques, cela vaut le coup de sécuriser les approbations de toutes les parties avant de démarrer sous peine de devoir défaire puis refaire (si l’on en a encore les moyens) ce qui aurait été produit avec un manque d’alignement sur les objectifs.

Comme le disait l’un des consultants senior avec lequel j’ai eu la chance de travailler :

“Si vous ne prenez pas le temps maintenant de bien faire les choses,

dites moi quand vous prendrez le temps de les refaire !

Car, n’ayez aucun doute, il vous faudra les refaire.”

February 25 – Lausanne – Deliver eBusiness Project within Healthcare

23 jan

PMI Switzerland

A PMI Switzerland event starting at 6:00 PM with Frédéric Briguet, an experienced eBusiness visionary. After 19 years of successful implementations within media, FMCG, software and health-care industry, he is currently helping big organizations and start-ups to generate revenue and demand with disruptive business model leveraging new technologies.

Frederic Briguet

Frederic Briguet

The implementation of eBusiness platform encompasses the development of eCommerce solutions, hosting infrastructure and the execution of digital solutions.

This requires specific skills, methodology and competences.

Even though eBusiness is still not well understood, an effective customer facing side of the solution, "web-face" forces traditional project management methodologies to integrate new steps and new tools in order to capture customer experiences: customer map, customer journey, stakeholders map, customer design, user experience…

This is already a challenge compared to a straightforward implementation of an ERP module or a commercial BI application. A challenge that can bring additional complexity, but still manageable!

Now, on top of it, what happens if you add a highly regulated environment ? Suddenly, everything becomes even more complex, more stringent, time and money consuming. This is an ecosystem that requires pragmatism and trade offs in order to do things right without losing control.

Bringing agility in this endeavor becomes like squaring the circle.

Register

Les principales leçons apprises dans les déploiements d’ERP par Jean-Louis Tomas

16 déc

Nouveau billet "Partage d’expérience" sur le site de Jean-Louis. Article intégral ici.

L’auteur y aborde successivement les leçons apprises lors de déploiement d’ERPs pour l’entreprise, le management, les utilisateurs, les informaticiens, et la méthode.

Campana & Schott

Partenaire de DantotsuPM

En voici un extrait:

"Les leçons apprises pour l’entreprise
  • Jean Louis Tomas

    Jean-Louis Tomas

    Le déploiement d’un ERP est un projet d’entreprise. Ainsi, les objectifs, les bénéfices, le retour sur investissement et les métriques sont au niveau de l’entreprise, non au niveau d’un département, d’un groupe d’individus ou d’un individu.

  • Identifier les meilleurs experts métiers dans chacun des domaines opérationnels et les assigner officiellement au projet.
  • Permettre une grande disponibilité des membres des équipes de mise en œuvre, quitte à compenser leur absence dans les unités opérationnelles par des ressources et/ou des solutions temporaires.
  • Favoriser, encourager et promouvoir le travail en groupe et un réel esprit d’équipe entre utilisateurs, consultants et informaticiens ; c’est une condition de succès sine qua non.
  • Saisir l’opportunité unique de l’arrivée de l’ERP pour stimuler et procéder à une révision ou à une refonte partielle ou totale des processus métiers actuels.
  • Sans une démarche authentique, éclairée et structurée de conduite des changements réelle, l’entreprise n’atteindra jamais les objectifs fixés et ne réalisera pas la totalité du retour sur investissement attendu.
  • Une perte de productivité significative suivra inéluctablement la mise en production. Le retour à un niveau de performance acceptable prendra plusieurs mois."
Méta Projets Management

Partenaire de DantotsuPM

17 Septembre – Microsoft Project webcast series – Connect ERP Systems with Microsoft Project

8 sept

Microsoft Project

Partenaire de DantotsuPM

Ready to learn how Microsoft Project can help you get more out of your projects? The new Project offers flexible service or on-premises solutions for project portfolio management and everyday work, enabling you to effectively execute winning projects and achieve strategic priorities. Now’s the time to register, attend our free Project webcast series, and find out more about Project 2013.

All webcasts will begin at 1:30 pm EST / 10:30 am PST and will run for 90 minutes.

September 17, 2013 Connect ERP Systems with Microsoft Project
Add to calendar
Stefan Haffner,
Campana & Schott
Campana & Schott

Partenaire de DantotsuPM

les 6 étapes de mise en place des instances décisionnelles pour un déploiement d’ERP par Jean-Louis Tomas

27 août

SI AntipolisERP – Mettez en place les instances décisionnelles

Jean Louis Tomas

Jean-Louis Tomas

1- Mobilisez vos directions générale et métiers
2- Instituez un comité de pilotage
3- Constituez les équipes de mise en œuvre
4- Impliquez vos directions générale et métiers
5- Surveillez l’efficacité du comité de pilotage
6- Installez le bureau exécutif

Lisez le billet en détail

SMPP

Partenaire de DantotsuPM

comment manager les problèmes sur votre projet

6 mar

Managing Your Project Issues

http://pm-foundations.com/2012/03/20/pm-foundations-managing-your-project-issues/ par Steve Hart

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Pour moi le plus ennuyeux et parfois le truc le plus perturbateur dans le projet est le management des problèmes. Les problèmes en cours distraient les membres de l’équipe du travail à réaliser et ralentissent souvent la progression nécessaire pour atteindre les jalons du projet. Au pire, davantage de temps peut être passé à parler des problèmes qu’à exécuter le travail de projet. Si le taux d’ouverture des problèmes dépasse celui de leur clôture, le projet peut être écrasé sous ces problèmes. Les projets sont paralysés par des problèmes projet quand les membres de l’équipe ne peuvent plus compléter leurs tâches et livrables parce qu’ils attendent la résolution de certains problèmes projet.

L’accumulation significative de  problèmes est généralement due à un manque de focus ou d’urgence de l’équipe projet à fermer les problèmes ouverts. Dans certaines cas, l’équipe peut ne pas avoir l’autorité pour prendre les actions ou les décisions requises pour clore des questions. Dans le cas, les problèmes qui restent ouverts créent des "bagages" de plus en plus lourds à trimbaler pour l’équipe et créent finalement des blocages ou des risques pour le projet.

J’espère que ce billet vous fera réfléchir à comment percevoir quand les problèmes commencent à avoir un impact négatif sur votre projet et ce que vous pouvez faire pour les ramener sous contrôle. Les problèmes ne sont pas une mauvaise chose, tant que vous pouvez les manager et non l’inverse.

Campana & Schott

Partenaire de DantotsuPM

Comment les problèmes écrasent-ils les projets ?

Voici certains des indicateurs usuels que les problèmes pourraient commencer à écraser votre projet, ou au minimum en empêcher la progression.

  • surcharge de problèmesTrop – L’indication évidente de malaise est le nombre de problèmes en cours (ouverts), particulièrement si un nombre important est tagué "haute priorité". Quand il y a tant de problèmes que vous ne savez plus par où commencer pour les tenir sous contrôle, vous en avez probablement trop. Quand le nombre de problèmes devient significatif, vous commencez à voir que des processus comme "le triage" doivent être introduits pour identifier ceux qui "importent vraiment".
  • Ils passent de mains en mains – Certaines équipes projet ne semblent pas fermer les problèmes. Elles les réassignent seulement à quelqu’un qui doit mener une autre réunion pour discuter du problème. Une bonne façon d’identifier l’incapacité à fermer efficacement les problèmes est de regarder l’historique associé à ceux-ci. Quand les problèmes appartiennent à de multiples personnes et deviennent la source de multiples réunions, l’équipe ne se concentre probablement pas sur les bonnes actions nécessaires pour clore le sujet.
  • boomerangIls continuent à revenir – Un des aspects les plus ennuyeux du management des problèmes est quand des problèmes fermés sont ré-ouverts. Cela se produit si toutes les bonnes personnes n’ont pas été impliquées, ou les actions correctes n’ont pas été prises pour fermer le problème original. Quand cela arrive plusieurs fois sur un projet, je ne suis plus certain de si je suis davantage énervé par la personne qui ré-ouvre le problème, ou par la personne qui ne l’a pas fermé correctement en premier lieu.
  • Ils surgissent de nulle part – Souvent, un problème est soulevé qui fait vous vous demander, "je me demande pourquoi ceci n’a pas été remonté auparavant ?". Plus un problème potentiel est identifié tôt dans le cycle de vie de projet, plus facile et moins coûteux ce sera de le résoudre. Donc, plus les problèmes sont identifiés tard dans le projet, plus la résolution de problème devient perturbatrice. En tant que chef de projet, vous devez trouver le bon équilibre entre manager agressivement la résolution de problème et encourager les membres de l’équipe à les identifier. La dernière chose que vous voulez est de faire en sorte que des membres de l’équipe gardent pour eux des problèmes parce qu’ils pensent que ce sera vu comme "une mauvaise chose" de remonter un nouveau problème.

6 Astuces pour manager vos problèmes de projet

expérience personnelle de gestion des problèmes1. Capture – Ma première astuce est assez évidente. Assurez-vous que les problèmes soient bien capturés dès qu’ils sont identifiés. Cela signifie que des processus et outils doivent être établis en début de projet de permettre l’identification et le suivi des problèmes. De plus, il est important pour le chef de projet de créer un environnement où les personnes se sentent "confiantes" de soulever une question épineuse. Cela dit, j’encourage vraiment les membres de l’équipe à penser aux façons de résoudre le problème quand ils le remonte. Le vieil adage "si vous ne faites pas partie de la solution, vous faites partie du problème" décrit parfois certains membres de l’équipe.

2. Responsabilité – À mon avis l’élément le plus important pour efficacement manager les problèmes est d’avoir une unique personne qui se sente vraiment responsable de résoudre le problème. La meilleure allocation des problèmes est aux personnes qui ont quelque chose "en jeu" dans le résultat de la résolution du problème. Le problème devrait avoir un impact sur le composant ou le livrable du projet dont elles sont responsables.

action3. Action – Quand les membres de l’équipe fournissent des mises à jour sur des problèmes, le focus devrait être sur quelles actions ont été identifiées pour clore le problème. Je ne considère pas nécessairement un "nous avons prévu une réunion pour discuter de ce problème" comme étant une étape suivante très efficace. Une action plus appropriée est de se concentrer sur quelles décisions doivent être prises, analyse effectuée, ou prérequis définis pour déterminer comment progresser et résoudre le problème.

4. Mesure – Comme c’est le cas dans la plupart des processus de management de projet, il est important d’avoir mis en place une métrique appropriée pour manager les problèmes. Pour établir un fort niveau de focus et le sentiment d’urgence, je préfère mesurer et communiquer les problèmes prioritaires triés sous forme de nombres absolus (numéro 1, 2, 3…). Une métrique comme le nombre absolu et l’âge moyen est efficacement utilisée dans une analyse des tendances. De plus, il est important de suivre l’impact total des problèmes sur le projet. Cette métrique peut être suivie dans le processus de contrôle du changement.

fini5. Clôture – Assurez-vous que le processus de management de problème inclut une étape pour valider que le problème est bien fermé. Cette étape peut être aussi simple qu’une revue rapide des problèmes récemment fermés à vos réunions d’équipe principale. Il est important que les membres de l’équipe reconnaissent que les actions appropriées ont été prises pour résoudre le problème de façon permanente.

6. Temps mort – Si un problème, un groupe de problèmes, ou les problèmes dans leur ensemble écrasent vraiment votre projet, il est parfois approprié de l’accepter et de demander un temps mort. Cela se produit quand les problèmes font manquer au projet des jalons significatifs et que des actions correctives ne sont pas en place pour en formaliser l’impact et remettre le projet "en piste". Pendant ce temps mort, l’effort devrait être placé sur la résolution des problèmes à fort impact, la réduction du nombre total de problèmes, la formalisation de l’impact des problèmes et repositionnement des lignes  de base du plan de projet. Je recommande aussi un processus rapide de  leçons apprises pour identifier la source des problèmes et les ajustements requis pour empêcher que l’équipe projet ne se retrouve au même point dans une phase future du projet.

12 December – Diegem (Belgium) – Election in Flanders 2012 and An ERP Case Study

1 déc

Online registration

PMI BelgiquePMI BELGIUM is pleased to invite you on 12 December to the chapter evening event:  "Project Management in the Public Sector." Election in Flanders 2012 and An ERP Case Study"

This event is an open chapter event. You can bring interested colleagues and friends with you.

Wednesday 12 November 2012 at Hewlett-Packard Belgium, Hermeslaan 1a, 1831 Diegem

AGENDA : 

18:00 Registration and Welcome
19:00 Opening words by the PMI President
19:15 Company presentation
19:30 “Election in Flanders 2012” by Gert Van den Brande
20:15 An ERP Case Study “ by Liliane Verreyen
21:00 Closing words
21:10 Reception

5 décembre – Montréal – MATINÉE PMI : Solution SAP, Innovation dans le domaine de l’aéronautique

26 nov

PMI Montréal vous propose une session le 5 décembre prochain au matin.

Dans le cadre du programme C-Series de Bombardier Aéronautique, le déploiement d’une solution d’affaires basée sur le module PLM (Product Lifecycle Management) de SAP s’est effectué avec brio. La gestion du projet a été confiée à R3D Conseil. La solution progressive déployée a déjà la notoriété d’être l’une des plus innovatrices dans le domaine de l’aéronautique.
Mesdames Danielle Coursol, PMP, de R3D Conseil, et Nadine Cuffel, de Bombardier Aéronautique, vous invitent à partager leur expérience de réalisation et de livraison de ce projet d’envergure. Elles vous proposent également d’expliquer en quoi ce déploiement est déterminant pour l’avancement des façons de faire pour cette industrie à la fine pointe des technologies de fabrication.

S’inscrire  et gagner 1 PDU

l’iceberg du retour sur investissement (ROI) des projets ERP selon Jean-Louis Tomas

30 oct

PM Network du mois dernier publiait ce résultat d’enquête:

bénéfices des ERPs

Or, justement, la semaine dernière, je croisais Jean-Louis Tomas à l’aéroport de Nice ( je me rendais à l’itSMF). Je connais Jean-Louis depuis de nombreuses années, du temps où je m’occupais comme lui de déploiements de grands projets de transformation de type ERP ou CRM.

Jean-Louis en a fait l’une de ses spécialités et il a publié plusieurs ouvrages sur le sujet tout en continuant à intervenir sur ce domaine et conseiller les plus grandes entreprises françaises et internationales sur ces projets de changement forts complexes.

Pendant cet échange, Jean-Louis a mentionné "L’iceberg du ROI" qui m’a bien sur interpellé et sur lequel il m’a gentiment envoyé ces quelques lignes que je partage ici avec vous.

Le ROI des projets ERP en question

  • Un Projet ERP est un Projet d’Entreprise
  • Le ROI est constitué de 7 composants
  1. La définition, la communication et le partage des objectifs de l’Entreprise
  2. L’effort de re-engineering des processus métiers
  3. L’évolution et l’alignement des organisations
  4. La redistribution des rôles et des responsabilités
  5. La requalification des circuits décisionnels
  6. La conduite des changements humains, processus et organisationnels
  7. Le produit ERP lui-même (la partie visible de l’iceberg !)

Pour en savoir davantage, consultez son site: http://www.si-antipolis.com/

Auto-évaluez gratuitement votre Projet ERP avec Jean-Louis Tomas et son outil gratuit

27 juin

Auto-évaluez gratuitement votre Projet ERP

Vous vous posez des questions sur votre Projet ERP ?  Jean-Louis vous propose de rechercher ensemble des réponses optimisées pour votre environnement à travers une approche radicale en 3 étapes :

  1. Évaluez vous-même en ligne, interactivement et gratuitement votre Projet ERP grâce à un outil indépendant des éditeurs et des intégrateurs : Auto-évaluez votre Projet ERP
  2. Définissez les actions correctives prioritaires grâce à 85 fiches pratiques recensant les meilleures pratiques collectées sur plusieurs centaines de Projets ERP : Maîtrisez votre Projet ERP
  3.  Mettez enfin en place les actions correctives personnalisées à votre propre environnement avec l’aide du Consultant, auteur de cet outil et de cette étude :  Organisez une session de travail

Jean-Louis se tient à votre disposition si vous aviez besoin d’un échange plus personnalisé sur vos problématiques spécifiques.

contacter Jean-Louis Tomas

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 125 autres abonnés

%d bloggers like this: