Pourquoi un tel comportement ?
- Est-ce un travers de certains informaticiens responsables du projet, accordant exclusivement leur attention à l'aspect technique, et peu enclins à comprendre les besoins purement fonctionnels ?
- Est-ce sous la pression des éditeurs ?
Les opérations marketing des éditeurs sont justement jugées comme réussies dès lors que le produit promu devient un phénomène de mode. Ce qui d’ailleurs n’enlève rien aux qualités intrinsèques du produit, là n’est pas la question.
Simplement choisir l’outil avant d’identifier précisément le besoin et la démarche pour y répondre est une erreur aussi classique que dramatique.
Pourtant, ce sont les « utilisateurs » qui par principe connaissent bien « l’usage ». Ce sont eux qui « utiliseront » le produit et jugeront ainsi son « utilité ».
La bonne approche est donc de réaliser des enquêtes précises, non pas pour faire « comme si » on écoutait les utilisateurs tout en pensant à autre chose, mais bien pour « collecter » des informations primordiales sur l’usage et le besoin du point de vue du terrain.
La recherche du progrès ne peut se passer de ces indispensables informations pour définir la pertinence de « l’utilité » à réaliser.
Bien des utilisateurs des premiers ERP, et des suivants d’ailleurs, ont cru possible de totalement re-développer l’image de l’entreprise dans le progiciel d’ERP, à l’aide d’un outil de script pas vraiment conçu pour cela.
Ce sont des coûts et des coûts, des retards et des retards, pour parvenir à la fameuse usine à gaz et ses comportements erratiques, et donc inexplicables et insolvables. Pour éviter d’arriver à cette extrémité, il vaut mieux rechercher l’optimal entre les plus de l’entreprise et les plus de l’outil, c’est-à-dire consentir à des concessions
Mais encore faut-il que la direction souhaite vous épauler, et donc s’engager ! S'engager, c'est aussi prendre part à la responsabilité du projet.
Être responsable, c'est étymologiquement avoir à répondre des conséquences de ses actes, et notamment de ses échecs ! des conséquences de ses actes, et notamment des échecs !
Les compétences d’un bon chef de projet sont multiples. L’une de celle-ci concerne la parfaite maîtrise des méthodes de conduite de projet et des outils associés. L’usage d’une méthode parfaitement maîtrisée est absolument indispensable pour assurer un déroulement entre les ridelles du raisonnable.
Une deuxième compétence, celle qui fera de lui justement un bon chef de projet, c’est de ne pas non plus se transformer en rigoriste de l’usage de la méthode. Le bon chef de projet est doté de bon sens, et sait adapter ses outils aux besoins.
C’est aussi parce que trouver les bons indicateurs de performance exige un effort et une réflexion de fond pour remonter effectivement aux besoins stratégiques. Il est tellement plus facile de faire comme d’habitude sans se poser de questions.
Suivre un indicateur de performance, qui n’a rien à voir avec les objectifs stratégiques et donc la performance attendue, c’est équivalent à s’efforcer d’avancer en ramant sur le sable.
C’est d’ailleurs la principale cause de dépassement des budgets de constitution d’un Data Warehouse. Les coûts de nettoyage et de mise en forme des données dépassent systématiquement le budget prévu toujours trop étriqué. Le même problème est aujourd’hui amplifié avec le Big Data.
Qu’est-ce qu’un tera-octet ?
C’est à peu près 300 millions de pages A4 bien remplies de données. Imaginez-vous, avant de prendre une décision, de devoir chercher l'information essentielle au sein d'une telle pile de feuillets !
Il s’agit en effet de bien conduire le projet data warehouse, de soigner l’étape de modélisation des données, et d’organiser intelligemment la base de données.
Négliger cette phase du projet est une dérive connue de longue date de la structuration des data warehouse. Et ce ne sera pas les outils de modélisation, de recherche de corrélation ou de datamining qui viendront corriger vos erreurs de structure de la base de données.
Savoir qui fait quoi, et donc qui répond de quoi, est une étape fondamentale à tout projet, quel que soit son thème ou son envergure. Si on évite cette phase du projet, en cas de dérive, la chasse au coupable est alors ouverte. Voir notamment les sessions de « blamestorming » évoquées ici.
Réussir son échec en 10 leçons
Pour acheter ce livre :
Disponible aussi au format ebook : PDF ou ePub
Sujet : Expérience concrète d'instauration de la démocratie au sein d'une PME
ISBN : 9782959320422
Pages : 360 pages
Présentation détaillée du livre "la transformation démocratique de l'entreprise"
Les tableaux de bord du manager innovant
Une démarche en 7 étapes pour faciliter la prise de décision en équipe
Alain Fernandez
Éditeur : Eyrolles
Pages : 320 pages
Consultez la fiche technique »»»
Pour acheter ce livre :
Format ebook : PDF & ePub,
Format Kindle
2. Aide à la décision et tableau de bord Excel
3. DataMart l'entrepôt de données sectoriel