La personnalisation, ou l’installation « custom » peuvent interférer avec la planification horaire du projet et les budgets, alors qu’elle rend les destinataires heureux.

Un gestionnaire de projet en charge d’une mission d’implantation aura tôt ou tard à se demander : Comment peser les contraintes de temps ainsi que le budget alloué au projet contre les bénéfices que procure une implantation personnalisée d’une solution d’affaires intégrée. Selon une étude menée par EDUCAUSE Center for Applied Research (ECAR) , on constate que le degré de personnalisation d’un progiciel détermine directement la probabilité de succès même du projet.

Moins que le projet sous-tend vers le cadre « custom », plus que ce dernier aura de chance de respecter l’échéancier prévu et le budget alloué. Dans l’étude offerte par EDUCAUSE, on remarque que les destinataires du changement, qui composent le bassin d’employés, sont plus réceptifs à une paramétrisation complète du système. Le chargé de projet doit ultimement trancher entre minimiser la personnalisation du progiciel ou maximiser les chances de réussite de l’investissement. Qu’advient-il de la satisfaction à long terme de la communauté d’usagers?

Facteurs mitigeant

Deux optiques existent permettant de réduire les effets pervers d’une implémentation tendant trop vers la surpersonnalisation : l’existence des PGI prochaine-génération et la maitrise des fonctionnalités du progiciel.

1. Les PGI nouvelles-génération

Avec l’avènement des progiciels de gestion intégrée modernes, les entreprises se permettent d’être plus originales dans leurs exigences. Pourquoi ne pas saupoudrer plus d’Oréo sur votre glace à la vanille tant qu’à y être?

Les nouveaux ERP sont régis par des ensembles de règles; ces règles définissent dans la grande majorité du temps les données spécifiques de l’entreprise : les limites, l’information-propriétaire, les paramètres spécifiques au secteur d’exploitation, etc. Ces informations alimentent le PGI au travers de tables et de champs d’information que seuls certains individus, les principaux usagers, sont autorisés à accéder.

Dans le passé, les informations contenues dans un progiciel de gestion intégrée étaient codées directement dans les nombreux programmes qui composaient littéralement le logiciel. De par cette manière de fonctionner, la lourdeur des lignes de code était considérable et demandait un travail constant de l’équipe technologique à chaque fois qu’une mise à jour était nécessaire  ou qu’une nouvelle version devait être installée.

Par ailleurs, lorsque les données étaient changées, il fallait compiler à nouveau tous les programmes et recréer tous les liens entre eux. Cette panoplie d’activités qu’engendre une simple modification au système obligea la mise hors fonction du système, coûtant tant monétairement qu’humainement à l’entreprise. En effet, il fallait mobiliser un nombre élevé de ressources humaines.

La technologie ERP a maturé au travers du temps rendant l’utilisation des tables une  nécessité opérationnelle. Les utilisateurs peuvent dorénavant saisir les paramètres qui déterminent les règles d’affaires de l’entreprise. L’utilisation des tables de saisie permet une plus grande flexibilité ce qui aurait pour effet de réduire, possiblement, le besoin de personnaliser le progiciel.

À suivre…

Pourquoi, soudainement, cet assouplissement?

Avec des résultats décevants à son troisième trimestre d’activité, le PDG de l’entreprise, Leo Apotheker, affirma son désir de rétablir la balance entre le fournisseur et le revendeur :

« Despite the continued tough spending environment, we are pleased to see further progress in the evolution of our volume business as a result of smaller deals…We are driving more multiyear agreements, where customers buy and consume software over many periods…

“We have the benefit of many years of experience in facilitating the purchase of our software in this manner, including the success we had in signing multiyear, Global Enterprise Agreements with our largest customers. We have now started to leverage this approach with a bigger group of customers.”

“Customers want greater flexibility and to phase-in their software use. We’ve seen this trend from the start and are leading the adjustment…Our Global Enterprise Agreements with companies like BMW, Colgate, Exxon, and Hitachi are examples of the kind of relationships we are crafting with our bluechip customers base-we are now also entering the same type of strategic, multiyear relationships with a larger group of customers.

‘These partnerships provide customers with the flexibility and strategic relationships they want, and SAP benefits from a more stable source of recurring revenue. In practice, for example, this means that payment of a five year license agreement will be paid in increments over those five years rather than requiring up-front capital expense all at once.’

‘Through the Global Enterprise Agreement model we have gained the experience on how customers want to buy and consume software based on building a long-term strategic road map over several years. We are now taking this concept, with some adjustments to take into account differentiated market needs, to our next 580 largest customers. We expect this to open up tremendous opportunities for growth.’

On ne niera pas que la nouvelle direction qu’a prise SAP est un autre pas dans la bonne voie. SAP innove dans des temps incertains, et a le courage de remettre en doute ses manières de fonctionner, des manières qui ont toujours bien fonctionné, mais qui demeurent peu pertinentes pour la situation économique actuelle. SAP, une compagnie reconnue pour sa rigidité, s’assouplit aux tendances économiques tout en gagnant un peu de cette fameuse élasticité voire flexibilité caractéristique des plus petites entreprises. À quand l’attaque d’Oracle?

La réputation d’un enterprise resource planning n’est plus à prouver : réduction des coûts, augmentation de la visibilité des technologies de l’information, abolition du fonctionnement en silos au sein de l’entreprise en général, gestion de l’information en temps réel, possibilité de prises de décisions éclairées et rapides supportées l’intelligence en affaires et les entrepôts de données, etc. Les avantages sont multiples et viennent accompagnés d’une étiquette de prix parfois salée.

Les spécialistes en TI s’entendent à l’unanime que la sélection et l’adoption d’un pgi représentent un défi de taille risqué tant financièrement que culturellement. On s’entend que par culturellement, on implique la culture habitant et animant les employés de l’entreprise en question. La planification est une étape stratégique qui doit être discutée avant même le début de la phase d’implantation. Encore aujourd’hui, les gestionnaires et les directeurs en technologies de l’information négligent cette étape cruciale ou l’escamotent totalement. L’adoption d’un progiciel de gestion intégrée risque inévitablement de bouleverser les destinataires : remaniement des processus d’affaires en fonction de ce que propose le PGI ou la personnalisation de ce dernier pour refléter la réalité visée par l’acheteur, comportement réfractaire des employés face à l’adoption d’une nouvelle méthodologie.

3 importantes étapes sont à noter: l’étude d’opportunité, l’appel d’offres et les démonstrations.

Étape 1 : Étude d’opportunité

C’est à cette étape que l’entreprise et ses conseillers doivent définir 3 éléments bien précis: les critères de mise en oeuvre, le budget alloué au projet, et l’échéancier du projet. On tient pour acquis que vous sachiez ce qu’est une étude d’opportunité en vous résumant les grandes lignes : détermination des objectifs et établissement des priorités d’affaires. Chaque département a ses propres règles d’affaires; l’étude d’opportunité permettra aux dirigeants d’établir l’urgence et la pondération des efforts dirigés vers ces départements lors du choix du progiciel de gestion intégrée. Pour vous lancer sur une piste de réflexion, on considère les questions suivantes également lors de cette étude : la langue utilisée dans l’organisation et celle utilisée dans les bureaux d’outre-mer, la grandeur de votre organisation, allez-vous vous adapter en fonction des best practices suggérés par le PGI ou vous utiliserez les votre, les principes comptables généralement reconnus, les chartes de taxation spécifique au lieu d’exploitation, etc.

Durant cette étape, les destinataires doivent être consultés; c’est également à ce stade qu’on doit définir les critères à retenir, les indicateurs de performance,et le plan de communication. Prévoyez en temps normal 4 à 6 semaines d’efforts. Il est primordial d’établir un lien de communication régulier et constant avec la haute direction tout au long de l’exercice afin de garder la pression sur le projet tout en faisant avançant ce dernier.

Étape 2 : Appel d’offres

On suggère de choisir 7 à 8 fournisseurs technologiques qui peuvent répondre aux critères ciblés lors de l’étude d’opportunité. On prendra en considération les contraintes de temps pour le projet, les contraintes budgétaires ainsi que les priorités de l’entreprise. Les fournisseurs ne manquent pas dans le domaine des progiciels de gestion intégrée; gardez donc en tête que plusieurs d’entre eux désisteront le processus d’appels d’offres faute de temps et d’intérêt, voilà pourquoi, il vaut mieux en choisir plus que moins.

Le monde de l’ERP est vaste. On peut facilement se perdre devant la panoplie d’options. La rigueur et la précision de l’étude  d’opportunité  deviennent essentielles. Cette étape durera environ 2 à 3 semaines puisqu’il faut rédiger l’offre d’appel et permettre aux fournisseurs suffisamment de temps pour élaborer leur proposition. On doit se réserver du temps pour analyser les offres puisque certaines offres se ressemblent, mais comprennent différents éléments. On constate que l’expérience de l’équipe de gestion de projet joue un rôle critique dans l’analyse des offres.

Étape 3 : Démonstrations

À cette étape, l’entreprise fournit des données aux fournisseurs afin que ces derniers puissent effectuer des démonstrations de leurs systèmes question d’évaluer le fit et les résultats. On remettra un script aux fournisseurs technologiques un script contenant des  données en sorte que la démonstration suive les critères définis dans le cadre de l’étude d’opportunité. Ces démarches ont pour but de s’assurer que le client reconnaisse ses processus d’affaires dans la démonstration d’un système dont il ne connait point.

Question d’être juste envers tous les soumissionnaires, l’équipe de projet devrait préparer des questions pour les fournisseurs qui seront posées lors de la démonstration; on demeure donc objectif à tous les fournisseurs, sans aucune exception. On prévoit environ un mois à un mois et demi pour cette étape ce qui laisserait le temps aux démonstrations d’être complétées et d’être évaluées. Normalement, les présentations durent 1 à une journée et demie.

Étape 4 : Fin?

Non, pas tout de suite. Il faut encore négocier les ententes, définir le plan de projet en détail, conclure les ententes entre le fournisseur de services et le fournisseur technologiques.

Après des efforts soutenus échelonnés sur près de deux années, les professeurs du Service de l’enseignement des technologies de l’information à HEC Montréal ont présenté l’avant-première de « Passionnate about IT » hier, mercredi 21 octobre 2009 à 18 h sur les prémisses de HEC Montréal. Les hôtes de la soirée étaient les professeurs Pierre-Marjorique Léger et Ann-Frances Cameron; ces derniers ont convié les étudiants du B.A.A, de la M.Sc. et des anciens en T.I. à assister à cette superbe présentation. Comme se plaît à dire M. Léger, il avait hâte d’entamer sa nouvelle carrière dans le domaine des arts à titre d’acteur tout en partageant sa passion des progiciels de gestion intégrée avec les étudiants en technologies de l’information.

Ayant pour objectif de démystifier la profession d’analyste d’affaires que confère directement ou indirectement le baccalauréat en technologies de l’information de l’École, l’événement s’est voulu être une superbe occasion pour réseauter avec le corps professoral, les étudiants et les professionnels ayant gradués des HEC. C’était un de ces événements qu’il fallait à tout prix assister, peu importe notre horaire de temps, des conditions des routes, il fallait y être. Des retrouvailles, des nouveaux contacts, des discussions épicées, il y en avait pour tous les goûts. On réalise rapidement à quel point le monde universitaire est si riche en connaissances, en vécus, en histoires, et en amitiés.

Sur ce, je partage avec vous la vidéo présentée à l’avant-première.

La simulation débutait à 8 h 30. Nul besoin de vous cacher que les étudiants étaient tendus et anxieux à se demander si leurs stratégies et acquis pourraient s’appliquer à la simulation du 16 octobre 2009. Traités aux petits oignons, les étudiants étaient approvisionnés en énergie et en conseils durant tout le long de la simulation. La visite surprise du professeur Gilbert Babin à notre local fut certainement un des points culminants de la journée. L’arrivée des sandwiches était un autre tournant de la journée.

Pas juste une question de chance

Le nerf de la guerre dans la simulation d’aujourd’hui résidait dans l’analyse des données fournies par R/3. Encore beaucoup d’entreprises utilisent inefficacement les données mises à leur disposition pour prévoir et conduire leur marché respectif. Même avec des outils peu spécialisés comme Excel, les participants ont dû analyser et interpréter les données extraites à partir du simulateur pour challenger et compétitionner avec les autres équipes présentes.

Un simulateur de marché à revoir?

Très rapidement, les étudiants ont réalisé que le simulateur de marché n’était point parfait : sur un marché réel, il serait étonnant de pouvoir investir autant d’argent dans le poste marketing et de pouvoir augmenter continuellement les prix des produits au point qu’une boîte de fraises à 500g se liquidait au prix de 50 euros.

Appréciation de la simulation

Formés à titre d’analyste d’affaires, les étudiants au B.A.A en T.I sont privilégiés de pouvoir acquérir une expérience pratique avec le progiciel de gestion intégrée SAP R/3. Ce qui les démarque des candidats plus techniques tels les ingénieurs logiciels et les informaticiens, ce sont leurs connaissances des sciences comptables, de la finance, et de la logistique et de l’approvisionnement. Ces connaissances procurent des avantages concurrentiels non négligeables aux étudiants du B.A.A face à ceux du programme du Certificat selon le professeur Pierre-Marjorique Léger, responsable de la concentration Technologies de l’information à HEC Montréal.

Se contenter de la 2e position au classement final

Je tiens à féliciter tous les membres de l’équipe : Paul-Étienne, Henri, Marja, Marie, Hassan, Annie, Arnaud et Andrei pour leurs efforts soutenus et leur détermination exemplaire tout au long de la simulation; sans vous, la simulation n’aurait pas été aussi si plaisante.

Pressure off après 7 semaines

Depuis le 4 septembre 2009, les étudiants se surveillaient de près en vue de la fameuse journée de simulation. Les équipes se sont formées rapidement dès le début du cours. Des nouvelles rencontres ont eu lieu, des échanges de courriels ont été partagés entre nouveaux collègues; ce fut très stressant depuis le tout début. Personne ne voulait terminer dernier à cette journée qui a lieu qu’une fois l’année. Après la simulation, les participants étaient différents. Un air plus familier et plus amical s’affichait sur le visage de bon nombre d’étudiants en T.I à HEC Montréal. Le 5 à 7 qui s’était produit au Tabasco Bar a attiré plus d’une dizaine d’étudiants et a permis aux participants de se lier d’amitié. La simulation avait définitivement une facette humaine…une facette qui passe souvent inaperçue lorsqu’on est dans le feu de l’action.

erpsim-final-result-b-team

◄ Back

Next ►

Picture 1 of 2

• -Gartner 2001 : 50 %
• -Butler Group 2002 : 70 %
• -Selling Power, CSO Forum : 69.3 %
• -AMR Research 2005: 18%
• -AMR Research 2006: 31%
• -AMR Research 2007: 29%
• -Forrester Research 2009: 47%

Sachez que tout projet peut être ressaisi et converti en succès avec une solide équipe de gestion prête à identifier les causes ayant mené à l’échec. Selon Peter Sherpe, du Groupe Forrester Research, il faut se garder à l’esprit :

No matter how bad things look, the project can usually be turned around. If
you’re a manager running a salvage effort, you have a lot of things going for you.

• 1. Vous n’avez pas besoin de remédier à tous les problèmes du projet. Plusieurs facteurs ont contribué au déraillement de ce dernier. Ce ne sont pas tous les facteurs qui requièrent votre attention immédiate.
• 2. Vous obtiendrez le support des parties impliquées. Que ces derniers conduisent des analyses ou non, les clients ont une idée de ce qu’ils espèrent obtenir en termes de résultats sur leur investissement.
• 3. Vous pouvez réparer le projet en adoptant des outils de gestion simples. Utilisez des procédés et méthodologies de gestion de projets reconnus, adhérez aux échéanciers de manière religieuse, et définissez adéquatement la frontière de votre intervention.

La résistance au changement se fera sentir que vous adoptez cette structure ou non, alors préparez-vous en conséquence. Faites-vous des alliés en ayant l’appui de la haute direction, et surtout, n’oubliez jamais de légitimer la nécessité de votre intervention.

Comment récupérer votre projet si ce dernier s'est avéré être un échec

◄ Back

Next ►

Picture 1 of 5

New research from CA, conducted by independent research company Loudhouse of 100 IT Directors across the UK and Ireland, reveals that poor visibility of IT project status and a lack of management control over them is costing the UK over a quarter of a billion pounds each year. A third of all projects implemented each year end up over budget with the typical over-spend between 10% and 20% of the original budget. The survey also highlighted the increased complexity of IT projects, with a typical company running 29 projects at any one time and an average IT budget of between £1m and £5m.

The primary reasons for the budget over-spend is as a result of poor forecasting (50%), project scope increasing during implementation (39%) and issues of interdependencies and conflicts between multiple projects (36%). This isn’t helped by the lack of visibility and control that CIOs have over their project portfolios – 40% of IT directors don’t have complete visibility over the initiatives they are running, so cannot see when projects are threatening to run over budget.

Presque tous les échecs d’un ERP ou les réussites peuvent être analysés en évaluant la tension entre les différents groupes d’acteurs impliqués dans le processus.

Du côté « Client »

Ce dernier veut s’assurer d’engager le minimum de ressource financière dans le processus au détriment d’une bonne relation d’affaires avec le revendeur technologique. Durant la phase de sélection du revendeur, il est important pour l’entreprise de bien cerner les capacités du revendeur à saisir ses besoins organisationnels tant sur les plans techniques, politiques et fonctionnels. L’achat d’un progiciel de gestion intégrée (PGI) doit être vu comme un investissement majeur, voire critique. À titre d’acheteur d’un PGI, l’entreprise doit se concentrer sur les besoins fonctionnels du système, la compatibilité avec l’organisation, le retour sur investissement, etc.

Du côté du « Revendeur technologique »

Les cabinets de consultants rêvent des projets de longue haleine parce que ces derniers leur permettent de charger de nombreuses heures facturables et de maximiser la vente des produits centrés sur les clients. Ces projets, comparables à des annuités, ne sont jamais bons pour les acheteurs. Lorsque les projets dépassent le temps prévu et les budgets alloués, il devient très profitable pour les firmes de consultation d’œuvrer de la sorte.

Du côté du « Fournisseur technologique »

Les vendeurs de PGI bonifient leurs revenus en tentant adroitement d’engager ses clients dans des contrats de maintenance et de support à long terme tout en facturant le plein prix sur les licences des logiciels. Les projets d’implantation qui se sont soldés par un échec ne rapportent aucun gain monétaire lié à la vente de licence aux vendeurs. La relation entre l’acheteur, le vendeur et le consultant s’étend normalement sur quelques années alors que le progiciel de gestion intégrée est initialement implanté, mis à jour par la suite, et finalement parfait au travers du temps. Le succès est quasi assuré lorsque les trois groupes d’acteurs sont alignés vers une attitude d’entraide  et de mutualisme. Malheureusement, même de nos jours, il s’avère particulièrement difficile de prédire ce que chaque partie désire réellement. Les implantations échouées sont souvent issues de l’arrogance, de l’inexpérience, et l’avarisme d’un ou plusieurs groupes d’acteurs tentant de prendre avantage des autres.

Mike Prisceno, V-P des Communications chez SAP, nous rappelle :

Truth be told, the vast majority of ERP implementations are very successful.

ERP implementations, or any major software deployments for that matter, involve transforming processes of the business. The most significant effort is not around the software itself — it’s around business process transformation, which can impact the organization as a whole.

Success comes only when all parties are aligned and working toward common objectives, since all parties share a common interest in project success. To ensure everyone is aligned and pulling in the same direction, strong executive sponsorship and project leadership must drive change management activities.

Other important success factors include defining a clear project plan from the beginning, to eliminate scope creep, which contributes to some failures. Software training and education are also important to a successful implementation. Another key point is the need to communicate internally, within the organization, helping employees understand why change is necessary and how the change impacts them. Finally, the project leadership team should be constructed to represent all parties involved in the implementation.

While challenges may exist, project leadership can mitigate risks with a strong plan that remains focused on the buyer’s goals and objectives.

En somme, une implantation réussie d’un progiciel de gestion intégrée survient lorsque la relation que partagent les trois groupes d’acteurs est alignée vers une mentalité d’entraide. Quoique parfois difficile à atteindre, cet objectif peut être accompli. Encore une fois, vous constaterez l’importance de légitimer un projet.

Tous ceux qui lisent ce blogue savent que la gestion de projets est un art qui s’apprend au travers du temps et de l’expérience, encore là, rien ne garantit une réussite sans embûche. Fait inusité, American Express a publié un billet récemment sur son blogue OPEN Forum qui résume succinctement pourquoi les projets échouent :

We have delusions of success. We take on more than we should, routinely exaggerating the benefits and discounting the costs. We over-scope, over-scale, and over-sell. At the same time, we under-estimate, under-resource, and under-plan.

Contributeur depuis peu sur OPEN Forum, Matthew E. May, auteur de In Pursuit of Elegance: Why the Best Ideas Have Something Missing, décrit ce que sont les 7 Lois sur la Gestion de Projets. Pour garder l’intégralité de son texte, je cite en anglais les postulats suivants :

1. -A major project is never completed on time, within budget, or with the original team, and it never does exactly what it was supposed to.

2. -Projects progress quickly until they become 85% complete. Then they remain 85% complete forever. Think of this as the Home Improvement Law.

3. -When things appear to be going well, you’ve overlooked something. When things can’t get worse, they will. (Murphy’s Law says, “If something can go wrong, it will”—this is a corollary).

4. -Project teams hate weekly progress reports because they so vividly manifest the lack of progress.

5. -A carelessly planned project will take three times longer to complete than expected. A carefully planned project will only take twice as long as expected. Also, ten estimators will estimate the same work in ten different ways. And one estimator will estimate ten different ways at ten different times.

6. -The greater the project’s technical complexity, the less you need a technician to manage it.

7. -If you have too few people on a project, they can’t solve the problems. If you have too many, they create more problems than they can solve.

Je pense que ces lois n’ont aucun lien avec la technologie ou même les technologies de l’information, puisque les échecs ne font presque jamais aucun sens. Pour mieux saisir le pourquoi de la chose, il faut porter son attention sur les dimensions de la collaboration, des relations et de la gestion.

Les projets échoués perdurent parce qu’il est plus simple de réparer les pépins techniques plutôt que d’être honnête avec l’équipe d’implantation, le projet, et ultimement soi-même.

Il y a de cela quelque temps, alors que j’étais encore sur les bancs des HEC Montréal, Céline Bareil, professeure au Service de l’enseignement du management, a partagé avec moi quelques un de ses nombreux secrets professionnels. L’un d’entre eux est l’humilité. À l’image de la professeure, je comprends mieux aujourd’hui le sens de son enseignement. La notion d’humilité évoque chez beaucoup de gens la vision d’une personne modeste, une personne ayant une faible estime de soi, une personne qui manque de confiance. Je suis de ceux qui s’opposent catégoriquement à ces définitions véhiculées par notre société.

Je pense que l’humilité relève de nombreuses qualités d’un leader à la fois humain et compétent. Souvent, on confond l’humilité avec la timidité. Faire preuve d’humilité n’est pas le geste de se draper dans une attitude de dénigrement de soi. Au contraire, faire preuve d’humilité c’est être fier de soi, de ce qu’on a accompli, de ses compétences sans toutefois user de l’arrogance. Je me plais à penser qu’une personne aux traits humbles peut être agressive dans sa quête du succès sans toutefois être arrogante.

L’humilité est une métavertu puisqu’elle croise une multitude de principes : on peut déclarer sans aucun doute qu’il n’y a pas d’authenticité sans l’humilité. C’est simple lorsque vous y pensez : il y a toujours un temps dans la vie d’un leader où ce dernier sera dans une situation où il ne connaîtra pas toutes les réponses aux questions qui lui sont demandées. Admettre le fait qu’on ne connait pas la réponse à une question requiert une certaine humilité, tout comme reconnaître qu’on a besoin d’aide. Je partage avec vous un extrait qui me guide au quotidien, et qui définit par l’occasion même ma personne : « the sign of a gentleman is how he treats those who can be of absolutely no use to him ».

En lien avec la notion d’humilité, à la suite de la simulation ERPsim, nous étions arrivés en 10e place, soit en dernière position. Il faut se rappeler que même si ERPsim est jeu, il est difficile pour mon équipe et moi d’accepter cet échec que je peux qualifier de crève-cœur. Je n’ai jamais douté des compétences analytiques de mes collègues qui sont à la M. Sc. et au B.A.A, au contraire, c’était toujours avec considération et intérêt que je leur accordais une oreille attentive. Encore aujourd’hui, je me considère fortuné de pouvoir m’entourer de gens aussi passionnés qu’eux.

Mon équipe et moi avions adopté une stratégie axée sur la flexibilité et la réduction des lots. Ayant analysé les données fournies par R/3 au peigne fin au travers de tableaux dynamiques croisés dans Excel, nous avons constaté qu’il y avait une possibilité d’affaires sur le segment de la petite consommation. Ne voulant pas être impliqués avec les autres équipes dans une guerre de prix, nous avons décidé d’être honnêtes avec nous même, et de mettre en action notre stratège. Lors du premier quart d’activité, tout fonctionnait à merveille : les ventes étaient au rendez-vous comme prévu, la marge d’exploitation était au-delà des attentes, le ratio de rotation des stocks était bas, le rapport dépense marketing/revenu oscillait dans les barèmes préétablis; tout allait bien, quoi.

C’est au deuxième quart que les choses se sont gaffées. Nos ventes chutaient, le délai d’entreposage s’accentuait au jour le jour; nous perdions énormément d’argent. Le second quart de la simulation s’est rapidement dégénéré, et nous étions plongés dans une zone dangereuse, celle où les activités consomment plus de revenus que ce que l’on réussit à produire. Prise de panique, toute l’équipe a mentalement bloqué. Nous étions tous dépassés par le fait que notre stratégie pourtant si bien orchestrée ne convertissait plus les produits en ventes.

 « the sign of a gentleman is how he treats those who can be of absolutely no use to him »

Nul besoin de vous dire que cette expérience sera à jamais gravée dans nos cœurs et âmes. Étant donné que nous étions en dernière place, il était prévu que notre équipe soit démantelée pour permettre aux étudiants de bénéficier d’une nouvelle vision.

Je tiens à remercier tous les membres de la nouvelle équipe pour leur considération et surtout, leur compréhension dans cette acquisition-fusion sans quoi mon équipe et moi n’aurions jamais eu la chance de collaborer à nouveau dans le cadre de la simulation ERPsim. À vous messieurs, et madame,  je vous dis merci.

À la suite de la discussion que j’avais entretenue avec M. Roy, il était convenu comme quoi nous devrions nous rencontrer pour discuter de la différence dans nos stratégies. Cette rencontre sera bénéfique pour tous, et permettra à la nouvelle équipe de mieux saisir les capacités de leurs nouveaux membres.

En vue de la préparation pour l’examen intra, qui prendra les allures d’une simulation se déroulant sur une journée complète, ce 15 octobre 2009 à HEC Montréal, les étudiants dans le cours SAP ont droit à deux rondes de pratiques pour se familiariser avec l’utilisation des modules d’intelligence d’affaires, des processus d’extraction transformation et chargement dans les bases de données, et surtout pour parfaire leur stratège de communication.

Fait à noter, j’ai réalisé que mon équipe et moi avions adopté une structure organisationnelle de type top down. Ce n’était pas vraiment ce que nous voulions, mais c’est la réalité avec laquelle nous devons composer présentement; à moins qu’on réussise à se décentrer de notre cadre de pensé habituel. Je vous explique : nous avons quatre membres dans l’équipe, et chacun des membres est affecté à une fonction critique. D’autant plus, à chaque fois qu’une décision doit être prise, chacun doit attendre l’approbation des autres membres. Cette validation demeure informelle, et semble rassurer les membres de l’équipe face à leurs décisions d’affaires.

Je stresse le facteur “assurance ” que crée le fait de valider l’information auprès de ses pairs. Dans un billet que j’ai posté dernièrement, je discutais de la mécanique des responsabilités que confère un travail Le système d’approbation adopté par la société tend à sectionner une entreprise en sous-processus, des processus avec des objectifs à atteindre. Si les résultats sont insatisfaisants, c’est la tête du dirigeant d’un département qu’on met sur un plateau d’acier. L’aspect de “l’accountability ” est plus présent que jamais.

Pourquoi valider? Je pense que les entreprises veulent s’assurer d’avoir quelqu’un à pointer du doigt lorsque les choses ne tournent pas rond. On se plait à dire que l’approbation engendre une confiance accrue, et une assurance de succès. Évalue-t-on les coûts engendrés par les processus d’approbation? Je ne suis pas le seul à remettre en doute ces idées puisque Michael Hammer, père de la réingénierie des processus d’affaires l’a déjà fait bien avant moi. Le fait de valider chaque action auprès d’autrui alourdit énormément le processus de gestion de l’entreprise. Un ERP a pour mission de fournir de l’information en temps réel à chaque employé. Ceci étant dit, si le contexte de l’entreprise ne permet pas un transfert de confiance aux employés, à quoi bon sert un ERP si un utilisateur doit toujours attendre l’approbation d’une décision alors que le marché roule continuellement. Cette description reflète en grande partie notre réalité lors de la pratique de simulation ERPsim.

On entend le terme “empower” régulièrement. Alors, pourquoi ne pas l’adopter. Pour pouvoir être compétitif, il faut agir et réagir en temps réel. À mon avis, une bureaucratie trop rigide tend à rendre une entreprise moins compétitive.

5e place sur 8 : Que s’est-il passé?

J’apprécie les bilans, et je crois qu’ils sont importants dans le développement d’un bon gestionnaire. Après avoir visionné la vidéo de notre simulation, certains points doivent être élevés: surproduction, coûts de stockage, manque de confiance, structure organisationnelle déficiente, facteurs de pressions externes et la réactivité du marché simulé. ERPsim est un puissant programme de simulation prenant en considération les informations des équipes participantes.

Lorsqu’une équipe décide d’injecter un pourcentage de son budget au poste marketing, il est inévitable que sa décision cause un déplacement des tendances de consommation chez les consommateurs. Jusqu’à quel point cette stratégie fonctionnera-t-elle? Le marché réagit à ces entrées, mais il ne faut pas se leurrer qu’il ne réagit pas si vite que ça. Lorsqu’on commence à injecter des budgets faramineux dans le marketing, on stimule la montée des tendances provisoires…des tendances qui ne perdurent point. Voyant qu’un produit se vend mieux qu’un autre, la majorité des équipes vont outiller leurs machines pour produire des nouveaux biens laissant complètement en arrière leurs plans initiaux de produire un produit spécifique.

Cette réactivité joue de nombreux tours; nous-mêmes avons été victimes. Leçon comprise, nous procéderons dorénavant à maintenir notre accent sur des produits que nous pensons être en demande et non de suivre les autres équipes. Nous devrons miser sur la production de quelques produits sélects et non d’une gamme complète. Le but du jeu n’étant pas de terminer premier, mais plutôt d’être capable d’expliquer comment nous avons utilisé SAP R/3 pour gérer notre entreprise.

La prochaine simulation de pratique est prévue pour vendredi 9 octobre 2009, nous avons soif d’une victoire. Its a serious learning game.

Équipe ERPsim: Marie, Marja, Andrei et Patrick

◄ Back

Next ►

Picture 1 of 4

Timer shot avec Canon PowerShot SD1000. Les yeux bridés: oui merci!