1. 1 | P a g e
Bulletin de la technologie de l’information
Les Raisons d’Echecs des Progiciels de Gestion
Intégrée et le Besoin de Refaire les Projets
d’Implémentation des Systèmes
Dion K. Hamilton, MBA, CISA
Vue d’Ensemble
Tout au long de ma carrière, j’ai eu l'occasion de travailler sur
de nombreux projets de développement de systèmes et
d’initiatives de mise en œuvre. Cette carrière s’étend sur plus
de vingt ans et dans diverses fonctions. Tout d'abord, j’ai été
exposé à mon premier développement de systèmes et projet
de mise en œuvre au cours de mon premier poste d’auditeur
interne pour une société aérospatiale; et, plus récemment pour
une institution financière mondiale en qualité de consultant en
gouvernance, risques et conformité (GRC).
Cet article est ainsi écrit à partir de l'observation d'un auditeur
interne et d’un consultant en GRC et de son expérience
cumulée. En conséquence, le champ d'application porte sur les
dix principales raisons pour lesquelles les implémentations ERP
échouent (basé sur mon expérience professionnelle) et, plus
important, ce qui peut être fait pour les corriger. L'objectif de
cet article est de présenter un autre point de vue à considérer
lors de votre prochain projet de mise en œuvre de systèmes et
la logique de notre approche recommandée. Je vais vous
donner des exemples précis d'échecs ERP dont j’ai été témoin
au cours de ma carrière, mais les entreprises resteront
anonymes pour protéger les innocents.
Introduction aux implémentations ERP
Avant 1990, la plupart des systèmes mis en œuvre étaient
composés de modules séparés comme la comptabilité
financière, les ressources humaines, les achats, l'entrepôt et les
systèmes logistiques au sein d'une même entreprise. Puis, au
début des années 1990, nous avons vu l'émergence des
nouvelles technologies de logiciels de gestion intégrée
d'entreprise et qui ont consolidé les fonctions stratégiques, de
conformité / réglementation, opérationnelles et financières /
de production de rapports dans un système unique,
harmonisée. Ces nouveaux systèmes de planification des
ressources d'entreprise ou ERP (Entreprise Ressources
Planning ou Progiciels de Gestion Intégrée) comme on les
appelle se compose des applications commerciales / modules
suivants: (1) Comptabilité; (2) chaine d'achat; (3) Production &
Distribution; (4) Gestion de la Relation Client ; (5) Ressources
humaines; et (6) performance et gouvernance d'entreprise. En
outre, nous avons également vu l'émergence de technologies
transformatrices (par exemple Business Intelligence, e-
Commerce, et des Applications de gestion d’Actifs) qui ont été
intégrées avec les modules à base commerciale pour améliorer
les capacités des systèmes ERP.
Risques et Défis des ERP
Vue d’Ensemble des Risques et Défis des ERP
Les mises en œuvre ERP sont très stratégiques par nature, mais
pourtant toujours considérés comme des initiatives à haut
risque en raison de la complexité du développement de
logiciels et des nombreuses variables à prendre en compte.
Les risques et les défis associés à ces projets sont nombreux,
mais nous allons aborder les plus importants (Le Top 10 des
risques) qui, à mon avis est très complet.
D. K. Hamilton
20 Mars 2015, Volume 2015-04-001
Ce document est une traduction de la version originale éditée en anglais. Merci de bien vouloir tolérer les imperfections et/ou nous faire des propositions d’amélioration de la traduction.

2. 2 | P a g e
Nos expériences professionnelles collectives indiquent que
même s’il y a beaucoup de facteurs opérationnels qui
conduisent les organisations à mettre en œuvre des systèmes
ERP, de nombreux pièges sont inévitables si une diligence
raisonnable et une planification initiale n’ont pas lieu. Les
questions qui reviennent le plus souvent sont:
 Pourquoi les initiatives de mise en œuvre des ERP
échouent?
 Pourquoi de nombreuses mises en œuvre des ERP
rentent en deçà des attentes?
Selon les récentes statistiques des ERP, 60 pour cent des ERP
échoue. Qu'est qui constitue exactement cet échec?
GLOBAL RISQ définit les échecs ERP selon:
1. Les Objectifs Stratégiques— le non-respect du Retour sur
Investissement déclaré, le coût total de propriété des actifs
informatiques ou d'autres paramètres?
2. Les Objectifs de conformité/Réglementation— incapacité
à fournir une plate-forme de reporting centralisé/
réglementaire et un référentiel de données et de
conformité qui répond aux exigences de conformité et de
réglementation.
3. Les Objectifs Opérationnels—la configuration du système
ne parvient pas à satisfaire aux exigences de conception du
système; Système tel que conçu ne fonctionne pas; ou les
coûts du système dépassant le budget du projet; ou la
chronologie de mise en œuvre du système va au-delà de
l'échéancier du projet.
4. Les Objectifs Financiers/Reporting— incapacité à classer et
enregistrer les transactions financières et / ou à faciliter
l'information financière complète et exacte.
En outre, une enquête récente a fourni les statistiques
suivantes sur les échecs des ERP:
Le tableau suivant présente nos "Top Dix" raisons pourquoi les
projets ERP ne parviennent pas à atteindre les objectifs
stratégiques, opérationnels, de conformité / réglementation,
et de reporting financiers:
1. attentes irréalistes — J’ai observé de nombreux échecs de
gestion ERP, grâce à des attentes irréalistes qui ont été
établies pour le projet. Dans plusieurs situations, les
Catégorie
Statistique
Résultats
Statistiques
Coûts moyens de mise en œuvre $7.3 Million
Calendrier d'exécution moyen 16.6 Mois
Le dépassement de calendrier du
projet
53%
Le dépassement de budget du
projet
59%
L'incapacité d'atteindre le ROI 56%
1 Attentes irréalistes
2 2. Manque de parrainage (Adhésion) de la
Direction
3 Le dépassement du Budget planifié du projet
4 La Gestion Inadéquate du changement
organisationnel
5 Mauvaise Gestion du Projet
6 La Mauvaise Collecte de l’information (Exigences
et attentes) du Système
7 Non implication des principales parties prenantes
8 Echec dans la redéfinition des processus métiers
9 La configuration du système n’est pas conforme
aux exigences
10 Formation inadéquate
Top 10 des raisons ERP réalisations échouent

3. 3 | P a g e
attentes irréalistes étaient un calendrier de mise en œuvre
extrêmement agressif. Un autre échec mémorable qui
était due à des attentes irréalistes s’est produit alors que
j’étais auditeur interne pour une entreprise moyenne de
distribution, qui mettait en place un nouveau système ERP.
Le calendrier de déploiement de la mise en œuvre a été
estimé à l'aide d'un plan très agressif de 15 mois pour
toutes les filiales. Le test du système ERP a commencé par
les petites filiales (env. 6 millions de dollars de recettes
annuelles) et finirait par les plus grandes filiales, 100
millions de dollars d'opérations par année. À un certain
moment au cours de l'essai avec la plus petite filiale, le
calendrier de déploiement a été révisé et la plus grande
filiale a été ramenée à la deuxième position sur le
calendrier de déploiement. La décision de la direction a été
prise, quoique des problèmes importants de configuration
aient été identifiés pendant l'essai pilote avec la petite
filiale de la société. En conséquence, et comme vous
pouvez l'imaginer, les problèmes de configuration ont été
amplifiés lors de la mise en œuvre avec la plus grande
filiale et a abouti à des problèmes d'évaluation. La filiale a
finalement été vendue et il a été établi que la raison du
réaménagement du calendrier de déploiement était due à
une transaction de vente en attente. Inutile de dire que la
transaction de vente contenait de nombreuses
éventualités en raison des problèmes d'évaluation
financière et il a fallu plusieurs années pour que la
transaction de vente soit finalisée.
2. Manque de parrainage (Adhésion) de la Direction — ceci
est un élément clé des grandes initiatives stratégiques, y
compris les mises en œuvre des ERP. Plusieurs fois, le
manque de soutien de la Direction devient le talon
d'Achille de nombreux projets ERP. Sur la base de mon
expérience avec les ERP à grande échelle, parfois la
perception est que la mise en œuvre des systèmes est un
"projet de technologie» qui relève de la compétence du
département informatique. Un exemple notable de cela
était la mise en œuvre par un grand intégrateur de
systèmes du PeopleSoft (acquis par la suite par Oracle). J’ai
travaillé sur ce projet après l’échec de la mise en œuvre,
qui a été attribuée à une faible configuration du système
et aux problèmes de formation. À la suite de l'échec de
l'ERP, l'entreprise n'a pas pu obtenir les soldes précis des
comptes financiers, ce qui a conduit à des problèmes
périodique d'information financière (reporting). Nous
avons également appris, tout en travaillant sur le projet
que la mise en œuvre des systèmes internes n'a pas reçu
le parrainage (l’adhésion) du directoire de l'organisation
en raison de la mentalité que «nous sommes intégrateurs
de systèmes" et le projet a été dirigé par des consultants
d'intégration de systèmes qui ne travaillaient pas sur les
missions facturables de conseil. Enfin, il y avait une
formation insuffisante sur le nouveau système par les
employés (consultants). Voir le point 10 pour de plus
amples informations sur les questions de formation.
3. Le dépassement du Budget planifié du projet —ceci est un
risque récurrent pour de nombreux projets ERP. Mon
expérience professionnelle, qui consistait à servir comme
auditeur de liaison avec le Comité directeur des ERP pour
plusieurs départements d'audit interne, a indiqué que de
nombreux projets ERP n’avaient pas une transparence
totale. En conséquence, de nombreux fournisseurs de
systèmes ERP seraient tentés "d’émettre la facture". Dans
le cas de ces intégrateurs spécifiques d’ERP, ils n’avaient
aucune expérience précédente avec les nuances de
contrats gouvernementaux et les règlements complexes
qui existent au sein de cette industrie. Ainsi, il y avait de
nombreux problèmes de conception du système et il y
avait des dépassements de coûts sur le projet. Un cas
classique du «manque de transparence» a eu lieu pour un
grand prestataire du gouvernement où j’ai travaillé en tant
qu'auditeur interne. Le coût total de la mise en œuvre de
l'ERP était d'environ 54 millions de dollars USD, tandis que
le montant prévu au budget original était environ 25
Million de dollars USD. Curieusement, quelques années
plus tard, l'entreprise a mis au rebut l'ancien système et l'a
remplacé avec le SAP.
4. La Gestion Inadéquate du changement organisationnel—
l'un des éléments clés des initiatives stratégiques est de
gérer à l’échelle de l'entreprise le changement
organisationnel qu'une telle initiative nécessite. Les
Implémentations de système ERP sont beaucoup plus des
projets stratégiques de développement d’entreprise que
de simples projets IT. En conséquence, le prochain projet
ERP que je tiens à souligner était pour un grand intégrateur
de systèmes à l’échelle mondiale. Et en qualité
d’intégrateur mondial de systèmes, cette société a décidé
de s’appuyer sur les ressources internes pour concevoir le
système plutôt que d'utiliser un fournisseur ERP externe.
Cette implémentation a souffert de plusieurs erreurs
majeures, dont l'une était l'échec de refaire leurs
processus métiers en fonction des capacités du système
ERP SAP R/3. Ainsi donc, ils ont conçu le système pour
répondre aux anciens processus métiers, quoiqu’il y ait eu
des limites inhérentes au système. Il faut retenir la
subdivision des contrats du gouvernement. Pour ceux
d'entre vous qui travaillez avec des contrats en général,
savent qu'il y a plusieurs types de contrats, y compris les
contrats à prix fixe, les contrats à coût majoré, les contrats
dépendant du temps et du matériel, pour n’en citer que
quelques-uns. Le module d'application nommées cProjects
de SAP a été conçu pour fournir un seul type de facture,
qui a ainsi créé des difficultés dans la génération de

4. 4 | P a g e
factures clients. En outre, de nombreux clients avaient
aussi des formats de facturation, qui étaient décrits dans
leurs contrats avec cette société. Ainsi donc, le système
était incapable de générer des factures pour tous ces types
de contrats et aussi pour cette myriade de préférences de
facturation des clients. Par conséquent, les processus
manuels de facturation ont été développés et mis en
œuvre afin de soumettre des factures aux clients pendant
la phase de d’expérimentation. Cela nous a conduits à une
situation de gestion inadéquate et non-transparente du
projet, ce qui fut une anomalie dont a souffert également
le projet.
5. Mauvaise Gestion du Projet—l'incapacité à gérer les
projets ERP sans apporter une transparence totale au
niveau des activités connexes de gestion de projet, aux
clients, aux mandants, et aux autres parties prenantes du
projet constitue une autre raison pour les échecs des ERP.
Le succès ou l'échec de la plupart des projets ERP dépend
de l'efficacité opérationnelle et de la rentabilité des
activités de gestion de projet. Entre autres, les facteurs
clés qui impactent la gestion de projet sont:
 Les Paramètres (Exigences) du système — Est ce
que les paramètres du système sont bien définis?
Est-ce que tout le personnel et les intervenants
clés de l'organisation ont été consultés lors de
l’établissement des paramètres du système?
 La Gestion des Risques du Projet — Y a-t-il
suffisamment de rigueur définie autour de
l'identification et la gestion des risques du projet?
 La Gestion des Fournisseurs — S’il y a une tierce
partie prenante, le fournisseur ERP, dans la
gestion de la mise en œuvre globale, alors dans
quelle proportion va-t-il "conduire les
opérations"? Comment vous rassurez-vous que le
calendrier et le budget du projet restent stables?
 Le Calendrier d'Exécution du Projet — Est-ce que
le calendrier de projet est réaliste? Ou est-ce qu’il
est trop agressif?
 Le Budget du Projet — Est-ce que le budget du
projet est réaliste? Comment vous rassurez-vous
que le projet est achevé dans les contraintes
budgétaires établies?
Voici donc quelques considérations qui doivent être
incluses dans la gestion du projet. Toutes ces
considérations doivent être soigneusement identifiées et
sélectionnées lors de la planification initiale du projet. Sur
la base de nos expériences cumulées d’auditeurs et
consultants GRC, nous sommes arrivés à la conclusion que
les activités de gestion des risques entourant le projet
constituent un élément clé à prendre en compte. Cela est
particulièrement vrai quand il y a un fournisseur d'ERP
impliqué. En exemple d’illustration, si la diligence
raisonnable de bien définir les besoins de l'entreprise à
l'avance est insuffisante, il se traduira par des
répercussions sur la fin du projet. Le projet peut prendre
du retard et / ou dépasser le budget pour résoudre des
problèmes. De même, si un tiers fournisseur est impliqué
dans la mise en œuvre, nous devons avoir à l’esprit que les
consultants sont dans l'entreprise pour faire du profit, il est
donc dans leur intérêt si les projets dépassent le calendrier
et le budget, avec pour seule répercussion la modification
de contrat incluant un financement supplémentaire
entrainant les dépassements de coûts. Par conséquent, un
tiers fournisseur présente un risque monumental aux
projets ERP. Pour conclure, tous les échecs des ERP
peuvent être attribués en partie ou totalement à la gestion
globale ou mauvaise gestion du projet.
6. La Mauvaise Collecte de l’information (Exigences et
attentes) du Système—J’ai observé dans de nombreuses
mises en œuvre où les exigences du système n’ont pas été
complètement et correctement définies, ce qui a abouti à
des échecs de degrés différents dès lors que le système a
été mis en exploitation. Plusieurs problèmes liés aux
exigences étaient gérables, tandis que d'autres ont eu des
conséquences désastreuses. Les cas sont trop nombreux
pour être mentionnés, donc je ne vais pas tous les traiter
ici dans cet article. Je voudrais cependant souligner que le
succès de l'implémentation des ERP dépend fortement de
la qualité des intrants du système. Si les exigences ne sont
pas en effet correctement définis, alors les résultats sont
ce que nous appelons affectueusement dans le monde de
la finance et de la comptabilité G.I.G.O. (Garbage In =
Garbage Out).
7. Non implication des principales parties prenantes — le
succès général des projets ERP est subordonnée à la
participation d’un échantillon représentatif des
intervenants impliqués dans le projet. Notre expérience
enseigne que la cause principale est soit la mauvaise
combinaison du personnel ou la restriction de l'équipe du
projet à un certain niveau dans l'organisation. Nous allons
aborder la première cause, qui est la mauvaise
combinaison du personnel affecté au comité de pilotage
du projet. La mise en œuvre des systèmes ERP par la
société de distribution dont j’ai fait allusion plus haut
représente un bon exemple de ce type de contraste. Le
comité de pilotage du projet se composait de personnel
des finances et de la comptabilité du siège social et des
gens de plusieurs filiales sélectionnés au niveau des
finances et de la comptabilité. Ainsi, lorsque le système a
été mis en exploitation, les erreurs de configuration qui
ont résulté ont été attribuées au fait que le système soit

5. 5 | P a g e
conçu à partir du seul point de vue des finances et de la
comptabilité. De même, la deuxième cause fondamentale
est l'exclusion du personnel opérationnel de l'équipe du
projet ERP. Notre expertise d'entretien et d'interaction
individuelle avec les personnes à tous les niveaux de
l’organisation indique que c’est généralement le personnel
de niveau opérationnel qui possède la connaissance
détaillée des processus métiers d'une organisation. Par
personnel opérationnel, je veux parler de spécialistes de la
comptabilité, de Spécialistes des ventes, de Spécialistes de
l'approvisionnement, de spécialistes IT et autres
personnels similaires au sein d'une organisation.
8. Echec dans la redéfinition des processus métiers — un
autre facteur contribuant à de nombreux échecs ERP peut
être attribué soit à la non amélioration ou à la non
redéfinition des processus métiers au cours des projets
ERP. Ces initiatives représentent une opportunité vitale
pour déterminer comment les processus métier existants
pourraient être améliorés ou, si nécessaire, tout à fait
reconçus. Surtout avec le taux des progrès technologiques
dans l'environnement des affaires d'aujourd'hui, de
nombreuses organisations devraient saisir l'occasion de
revoir les processus existants et de déterminer si elles
peuvent être améliorées. En exemple illustré, les tâches
manuelles, à fortes intensités de main-d'œuvre sont les
premières candidates à la redéfinition du processus en
mettant en place davantage de contrôles internes liés au
système, de flux automatiques de processus, et d'autres
améliorations pour les rendre plus efficaces sur le plan
opérationnel et rentables.
9. La configuration du système n’est pas conforme aux
exigences —c’est généralement le point d’achoppement,
comme on le dit. Une fois qu'un système est achevé et mis
en exploitation, qu’il fonctionne ou non; que la
configuration du système soit conforme à ses exigences
dans une bonne mesure ou non dépend de la façon dont
le système a été conçu et de la qualité des exigences du
système.
10. Formation inadéquate — les problèmes de formation liés
à la mise en œuvre de l’ERP PeopleSoft mentionné plus
haut au point 2 étaient en grande partie préventifs. Selon
l'ancien Responsable en charge des Opérations IT de
l'entreprise, «Il est difficile de tirer les générateurs de
revenus de la première ligne pour une formation de back-
office, en particulier dans une société où le personnel
opérationnel n’était pas bien estimé, et où il n'y avait pas
assez d'intérêt à lutter contre le blocage." Dans la foulée,
avec le lancement en Avril 2004, la société a subi des
problèmes internes dans les rapports comptables et
financiers qui l'ont empêchée de déposer ses états
financiers à temps pendant 18 mois. L'impact sur la société
est qu'il a engagé des honoraires d'audit exorbitants pour
résoudre le problème, qui a conduit à des difficultés de flux
de trésorerie et, finalement, à un dépôt de bilan qui
dissout l'unité d'exploitation implantée aux Etats Unis.
La méthodologie d’Implémentation ERP selon GLOBAL
RISQ
Introduction
Pourquoi la majorité des projets d’implémentation ERP ne
parvient pas à satisfaire les attentes? Si tel que les statistiques
suggèrent, plus de 50% des projets ERP ne répond pas aux
attentes, alors le processus ERP est extrêmement déficient. En
qualité de consultants chevronnés en gestion, nous nous
sommes sentis obligés de mener des recherches pour identifier
les causes profondes des échecs ERP. Ainsi, lors d'un projet
d’implémentation de SAP, nous avons eu le privilège d’avoir
accès au budget total du projet. À première vue, le coût total
du projet semblait raisonnable. Ensuite nous avons examiné la
façon dont les fonds étaient alloués à chaque phase du projet.
Ce que nous avons réalisé est que la majorité du financement
du projet était affectée à l'analyse/la conception du système et
les processus de tests du système (env. 70%). Il y avait peu
d'investissements dans l'analyse des besoins et peu ou pas
d'investissement reconnu dans les activités de planification.
Approche et Méthodologie ERM
Sur la base des résultats obtenus à partir de nos recherches,
nous avons décidé de nous concentrer nos efforts à la
redéfinition pour les projets ERP. Tout d'abord, nous avons
décidé de définir formellement la phase de planification pré-
projet et d'en faire une partie intégrante du processus de mise
en œuvre. Ensuite, nous avons mené des recherches
supplémentaires et avons déterminé que le niveau d'effort qui
est habituellement consenti à des projets ERP traditionnels
nécessitait une redéfinition également. Enfin, nous avons testé
notre méthode sur les travaux chez des clients.
ANALYSE DES
EXIGENCES
OU BESOINS
CONCEPTION
DU SYSTEME
TESTE DU
SYSTEME
LANCEMENT
DU SYSTEME
FORMATION
ET SUPPORT

6. 6 | P a g e
Nous appelons la phase de pré-planification « la phase de
définition du projet ». La redéfinition des phases ultérieures est
subordonnée au succès obtenu à partir de la phase de
définition du projet.
Niveau
d’effort
tranditionnel
SDLC
Phase
Niveau
d’effort de
GLOBAL RISQ
2% Definition du Projet 10%
5% Analyse des besoins 10%
40% Conception et analyse du
système
35%
30% Test du système 15%
15% Lancement du système 15%
8% Formation & Support 15%
Definition du Projet
La méthodologie ERP de GLOBAL RISQ est basée sur le principe
que les projets ERP peuvent être rendus plus efficaces sur le
plan opérationnel et rentable en insistant sur les activités
préliminaires du projet. Notre méthodologie ERP utilise la
méthodologie et l'approche AGILE des projets de
développement de systèmes. L'approche AGILE divise les
phases de mise en œuvre en unités distinctes qui sont conçues,
testées et approuvées avant de passer à l'unité suivante. La
première étape consiste à mettre en œuvre une phase formelle
de pré-planification, c’est « la phase de définition du projet »
pour mener à la fois une évaluation financière et technique du
projet. L'objectif principal de l'évaluation financière est d'aider
nos clients à valider les différentes hypothèses des coûts
financiers du projet.
Ensuite, nous procédons à une évaluation technique du
système existant pour déterminer l'Etat de l’environnement
futur dans le nouveau système. Le résultat des évaluations
financières et techniques fournit des informations
supplémentaires à nos clients permettant de définir le champ
d’application du projet en le rendant plus transparent. Notre
recherche indique que le niveau d'effort requis pour cette
phase est d'environ 10%, mais le processus de diligence
raisonnable accrue va réaliser des bénéfices dans les futures
phases du projet.
Analyse des besoins
L'analyse des besoins commence par l’utilisation des résultats
de l'analyse technique de l'ancien système et par la projection
des objectifs de l'état futur. Ainsi, nous collaborons avec les
utilisateurs de l'environnement actuel, les gestionnaires du
projet et les autres parties prenantes pour évaluer l'Etat actuel
du processus métier et l’état de l'environnement futur
souhaité. Les résultats documentés deviennent le modèle pour
la conception du système.
Conception du système
Le document de conception de projet de la phase d'analyse des
besoins devient la feuille de route de la conception du nouveau
système. Le plan est basé sur l'évaluation technique, l'outil de
validation financière, et le résultat de l'analyse des besoins. En
fin de compte, l'objectif est d'assurer l'alignement du système
ERP avec les objectifs d'affaires à l’échelle de l'entreprise.
Test du système et l’Implémentation (“Go-Live”)
Nous utilisons une approche fondée sur les risques pour
effectuer les tests du système en utilisant l’outil COTS (une
application). L'outil COTS facilite l'identification et l'essai des
fonctionnalités clés du système. L'effet cumulatif de notre
approche est que le test de la configuration du système conçu
est significativement réduit de 40% - 50% comparé à celui de
l'essai ERP traditionnel. Enfin, le système n’est pas mis en
exploitation jusqu'à ce que tous les tests du système soient
achevés et approuvés.
Formation
Nous recommandons à nos clients de réserver environ 15% du
budget du projet pour effectuer les tests du système. Le test
est crucial pour le système puisqu'il permet de valider la
conception et le fonctionnement du système. Le processus de
formation commence au début de la phase de conception du
système avec la définition des besoins; l'élaboration du plan de

7. 7 | P a g e
test pendant la phase de conception; et un mécanisme robuste
de formation au cours de la phase de test du système.
Conclusion
La transformation que l'organisation subit à partir de la mise en
œuvre des systèmes ERP est subordonnée à la bonne stratégie,
à la qualité du personnel du projet et à la qualité du processus
ERP. La reussite de la mise en oeuvre ERP permet aux
entreprises de profiter des avantages prévus qui améliorent
leur efficacité opérationnelle, réduit les coûts opérationnels, et
facilite une meilleure gestion de la prise de décision dans les
domaines suivants:
About the Author
Dion K. Hamilton est un gestionnaire financier avéré et un
professionnel de la gouvernance, des risques et de la conformité
des entreprises avec plus de vingt ans d'expérience dans les
domaines de l'audit interne, l'audit financier, la gestion des
risques, les contrôles internes, et d'autres disciplines comptables
et financières. En tant que consultant sur les questions de risque
pendant les dix dernières années, M. Hamilton a diversifié sa
vaste expérience par des mission de gouvernance, de risque et
de mise en conformité. En outre, Dion a une expérience
significative avec les implémentations de systèmes ERP, et des
missions de gestion des risques d'entreprise. Auparavant, M.
Hamilton a travaillé avec de grandes organisations comme
auditeur interne; et il a commencé sa carrière professionnelle
chez PriceWaterhouseCoopers. Dion est un Auditeur Certifié
des Systems d’ Information.
A propos de GLOBAL RISQ CONSULTING
GLOBAL RISQ CONSULTING est un cabinet de conseil en
gestion qui fournit des services : de conseils stratégiques en
risques, d’audit interne, de gestion financière, de technologie de
l'information et des solutions dynamiques de formation auprès
des services publics, des sociétés privées, et des organisations
non-gouvernementales. Notre personnel se compose de
professionnels expérimentés qui ont une expérience en cabinet
spécialisé de comptabilité, une expérience de conseil en gestion,
ou une expérience approfondie dans l’industrie de l’audit. Notre
philosophie de gestion est d'embaucher des professionnels et des
experts de haut niveau qui possèdent un minimum de dix ans
d'expérience professionnelle.
Pour plus d'informations, s’il vous plaît contacter,
Dion.Hamilton@globalrisq.com ou alternativement,
info@globalrisq.com.
Domaine Avantages
Conformité Référentiel de reporting centralisé
Opérationnel Gestion des opérations d'affaires intégré
Financière /
Rapports
Amélioration Analyse Financière &
Rapports
Outil de gestion stratégique DecisionStratégique