Ph BERGOUGNOUX :
Ingénieur D.P.E
Expert en Gestion de Projet Informatique et Systèmes d’information de l’Entreprise
37550 St AVERTIN
Tel/Fax: 02 47 28 58
19
Portable : 06 06
82 69 51
site professionel : http://www.enduser4gl.com
émail : mailto:bergou@club-internet.fr
Maj : 04/03/2004
PARMI MES EXPERIENCES
PROJETS :L’HISTOIRE VECUE D’UN
PROJET D’ENVERGURE avec la
SOCIETE XYZ
et « l’Editeur de
progiciel XXXFFFDD» (restons dans l’anonymat )
ou comment réussir un projet au sein de contextes humains , matèriels, produits, DIFFICILES,COMPLEXES et HOSTILES.
Vous trouverez une expérience de projet informatique – Mise en place d’un progiciel financier -:
négociations, formation, administration de projet,
méthodes...des hommes et leurs problèmes
Bonne lecture ...reste à votre disposition si vous souhaitez quelques informations supplémentaires..
Avant propos important :
Vous pouvez télécharger cette expèrience de projet mais Attention une utilisation PERSONNELLE de ce documen est admise, toute reproduction et diffusion à des fins commerciales ou autres sont formellement interdites
S O M M A I R E
Chapitre 1 : DEMARCHE COMMERCIALE et NEGOCIATION
1.1.1 - Le choix du progiciel :
1.1.2 - Le contexte « Le progiciel Financier» : bêta site, stratégie et média ::
1.1.3 - Le choix du prestataire pour la mise en oeuvre de la nouvelle solution :
1.2 La recherche d’un consultant :
.1.3 Contact, présentations et délibérations :
1.3.1 Contact : Décembre 19XX.
1.4.1- L’art de négocier et les difficultés rencontrées :
1.4.2 - les prérequis pour la suite de la mission :
Chapitre 2 : PREALABLE DE LA MISSION :LES CYCLES DE FORMATION.
2.2 Le découpage des sessions de formation :
- 2.3.1 Documentations standards :
- 2.3.2 Documentations personnalisées:
2.4 Les sessions de formation :
2.5 Le projet au sein des cycles de formation :
2.7 Validation du consultant :
Chapitre 3 : PRISE EN MAIN DU PROJET : FONCTIONS, METHODOLOGIE et LES PREMIERS CONSTATS.
3.1 Mes fonctions et mes responsabilités au sein du projet :
Les axes principaux de mes fonctions :
Les axes principaux de mes responsabilités :
Mon positionnement hiérarchique dans les équipes de projets :
3.2.1 Les fonctions et responsabilités des groupes du projet :
3.3 Présentation des équipes : Profil , nombre et motivations au projet.
3.4 Prise en main des équipes par projet :
- Quantifications et disponibilités des ressources par projet :
- Evaluation économique du projet « Le progiciel Financier »:
3.5 Appréhender les architectures :
- 3.5.1 Description de l’architecture générale;
- 3.5.2 Description d’une partie de l’architecture logicielle « »Le progiciel Financier» » :
3.5.3 - description de l’architecture technique.
3.6 L’environnement méthodologique du projet :
3.6.1 Contexte et problèmes rencontrés:
3.6.2 Discussions avec «L’ Editeur de progiciel Financier» :
3.6.3 Les nouvelles implications :Circuits et documentations :
3.7 Réévaluation du projet et des budgets.:
Chapitre 4 : PLANIFICATION, ANIMATION ET SUIVI D’AVANCEMENT.
4.1 Logistique et connaissances de la gestion de projet :
4.1.1 - L’expertise des bases et des outils de la gestion de projet :
4.1.2 - Mise en place d’une documentation appropriée :
4.2 Planification : l’art de maîtriser le macro-planning d’un projet informatique :
- L’ambiguïté : les projets au sein du projet principal:
4.3 Planification du projet « Le progiciel Financier» :
4.3.1 Découpage par module fonctionnel et par phase du Modèle en « V »:
4.3.2 Découpage par type de tâches:
4.4 Animation et suivi d’encadrement du projet :
4.5 Recadrages du projet, des budgets et des hommes :
- Recadrage du projet : Exercice de style ou comment annoncer le bilan de santé d’un projet ?
- Recadrage des hommes : Savoir communiquer et diriger:
Chapitre 5 : LES ANALYSES et LES MISES EN OEUVRE
5.1 Rappel du contexte de la solution « Le progiciel Financier» :
5.4 L’expertise fonctionnelle:
5.6.1 - les attendus d’une étude de l’existant.
5.6.2 - Visite sur le terrain : le véritable environnement du futur système;
5.7 Le planning des études détaillées:
5.8.1 Définition d’un ou une interview :
5.8.2 - Préparation de l’interview :
5.8.3 - Durée d’un interview :
5.8.4 - les règles à respecter :
5.8.5 - les interviews éclairs :
5.9 Les recherches de solutions adéquates :
5.9.1- adéquation entre les besoins des utilisateurs et le progiciel:
5.9.2 - détection des infaisabilités:
5.9.3 - l’emploi d’outils d’investigation sur la base de données : SQL
5.10 Mise en évidence des nouveaux dossiers:
5.11 Définition et formalisation des analyses détaillées:
5.11.1 :Rôle du consultant : L’apport de la démarche :
5.11.2 Rôle de l’utilisateur :
5.11.3 Les attendus d’un guide fonctionnel:
5.11.4 Les attendus d’un guide de procédure:
5.12 Modélisations et paramétrages:
5.12.2- les attendus d’un guide de paramétrage.
5.13 Les incidents survenus au cours des études détaillées:
5.15 Les attendus des guides organiques ou de réalisations:
5.15.1- Prise en charges des analyses organiques :
5.15.2- Constitution d’un dossier de réalisation:
5.16 Les attendus d’un dossier d’exploitation.. 85
5.17 Les mises en oeuvre: le respect du modèle en V.. 85
Chapitre 6 LA VIE D’UN PROJET
: DES PROBLEMES et DES HOMMES... 86
6.1 Les problèmes techniques du progiciel : les
incidents. 86
6.2 L’image d’une solution à travers des incidents
fréquents: 86
6.2.1 - Malgré les problèmes,
croire à la nouvelle solution: 86
6.2.2- Les demandes
d’améliorations : intégration au produit ou réalisations en spécifique ?. 86
6.3
Les problèmes techniques liés au S.G.D.B « informix « : 87
6.4 La qualité de développement du logiciel chez «L’
Editeur de progiciel Financier» :. 87
6.4.1- Explication du cycle de
résolution d’un incident : 87
6.4.2- Explication du cycle de
traitement d’une demande d’amélioration : 88
6.5 Les efforts de «L’ Editeur de progiciel
Financier» Etats-Unis : 88
6.6 Les tensions contractuelles: 88
Chapitre 7:
LES PREMIERS BILANS DU PROJET. 89
7.
1 Le projet à ce jour: 89
7.2 Les premiers bilans: 89
CONCLUSION.. 91
GLOSSAIRE ET CONVENTIONS UTILISEES. 92
Ph BERGOUGNOUX :
Ingénieur D.P.E
Expert en Gestion de Projet Informatique et Systèmes d’information de l’Entreprise
37550 St AVERTIN
Tel/Fax: 02 47 28 58
19
Portable : 06 06
82 69 51
site professionel : http://www.enduser4gl.com
émail : mailto:bergou@club-internet.fr
Les chapitres 1 et 2 ont pour objectif d’expliquer brièvement le contexte du projet, le pourquoi de ma venue et surtout sous quelles conditions.
Société XYZ a procédé à la refonte de son système informatique tant du point
de vue matériels et logiciels. Cette refonte touche la totalité des services administratifs et de productions de l’entreprise.
Plusieurs projets informatiques ont été ouverts pour construire un nouveau système d’information cohérent et à la mesure des attendus des services utilisateurs.
Le choix de la SOCIÉTÉ XYZ, à la vue de différentes prospections et réponses aux cahiers des charges, s’est orienté vers la
mise en place d’un progiciel couvrant une partie de son système financier et administratif.
Le progiciel retenu concerne la solution progicielle « »Le progiciel Financier» de «L’ Editeur de progiciel Financier», société américaine bien connue des grandes entreprises françaises pour ces logiciels « systèmes « et « de base de données relationnelles ».
Près d’une dizaine de modules du progiciel couvre la presque totalité des domaines financiers et administratifs d’une entreprise.
La conception de ce progiciel est toute récente, et , à la volonté de concurrencer les grands progiciels actuels tels que
Sap, Oracle et bien d’autres.
Ce progiciel est transposable sur plusieurs plates-formes matérielles supportant différentes bases de données.
Les différents modules du
progiciel à mettre en place sont :
1 - Une comptabilité intégrée (GL - General Ledger- );
2 - Une comptabilité d’engagement (FU - Fund- );
3 - La gestion des fournisseurs (AP - Account Payable- );
4 - La gestion des achats (PO - Purchase Order-);
5 - La gestion des stocks (IC - Inventory Control-).
Les Architectures
logicielles sont développées au chapitre 3.
Au sein de cette thèse, je développerai uniquement les projets et sous-projets dont j’ai la responsabilité. Ce sont les modules 3, 4, 5 et une partie des modules 1 et 2 cités ci-dessus.
Les axes principaux du choix de la solution progicielle ont été :
Des axes techniques :
- respect de la plate-forme système « Unix »;
- respect de la plate-forme matérielle «Sparc» de la société « Sun »;
- respect de la base de donnée relationnelle « Informix » retenue sur le site SOCIÉTÉ XYZ ;
Des axes fonctionnels :
-
Recherche d’une solution progicielle intégrée;
- Adéquation de la solution progicielle aux cahiers des charges.
D’après ces différents axes, deux éditeurs de logiciels ont été retenus :les sociétés « EDITEUR2» et « L’ Editeur de progiciel Financier» ».
La société EDITEUR2 n’avait pas finalisé, à l’époque, la portabilité de son progiciel sur le système d’exploitation « Unix » et encore moins avec le S. G. B. D « Informix ». Cependant à la vue de ce retard technologique, et pour l’obtention de ce contrat et de la référence du site, la société EDITEUR2 a proposé à la SOCIÉTÉ XYZ, d’installer gratuitement un gros ordinateur (mainframe). Celui-ci supportait la solution progicielle dans l’attente de la livraison définitive sous le système « Unix ».
A ces problématiques techniques de la proposition de la société EDITEUR2et des coûts estimés de la mise en oeuvre (100 à 120 millions de francs Franc ), la SOCIÉTÉ XYZ a préféré se diriger vers le deuxième éditeur : « L’ Editeur de progiciel Financier » et de sa nouvelle solution progicielle intégrée .
C’était la première fois que la société «L’ Editeur de progiciel Financier»:
- devançait contractuellement la société SAP;
- implantait la solution « »Le progiciel Financier»
D’où les contextes très stratégiques et médiatiques pour ce contrat vis-à-vis du site de la SOCIÉTÉ XYZ
Les négociations du
contrat ont porté sur les clauses
suivantes :
- « »L’ Editeur de progiciel Financier» » garantis la portabilité du progiciel vers le S. G. B. D « Informix » ;
- de la prise en charge totale en cas de graves anomalies techniques du produit étant déclaré officiellement « béta-site » ;
- de la responsabilité de l’ensemble du contrat d’assistance pour la mise en oeuvre du progiciel.
- de l’engagement en terme de délais et de l’obligation de résultat ;
- et d’autres aspects financiers en cas d’échec.( pénalités de retards etc..).
La structure de la division des progiciels applicatifs de « »L’Editeur» » ne comprend pas de cellule d’ingénieurs conseils susceptibles de mettre en place la solution progicielle. Cette division a pour objectif de se concentrer et de participer aux ventes du produit. Ce sont principalement des ingénieurs technico-commerciaux.
Concernant la demande contractuelle de la SOCIÉTÉ XYZ de l’obligation de « »L’ Editeur de progiciel Financier» » d’être responsable de l’assistance pour la mise en oeuvre, «L’ Editeur de progiciel Financier» a dû recourir à des prestataires extérieurs.
Une recherche en a bien eu lieu, et n’a donné d’autres le fait que certaines SSII se sont intéressées et postulées pour la mise en oeuvre du produit. Aucune d’entre elles n’avait suffisamment d’expérience sur le produit, et, des promesses de partenariat ont vu le jour...
La seule possibilité de «L’ Editeur de progiciel Financier» a été de se retourner vers sa filiale française et de ses partenaires.
Une SSII française « TOTO » a obtenu le contrat, dans des conditions que j’ignore, pour la totalité des mises en oeuvre du projet « »Le progiciel Financier».
Je ne peux me permettre de porter des jugements vis-à-vis de cette SSII, notre métier du conseil n’étant pas forcément très facile. Cependant les prestations des consultants de cette SSII n’ont pas convaincu la SOCIÉTÉ XYZ concernant les cycles de formation,les niveaux de connaissance de la gestion de projet et des conseils relatifs au produit.
Après trois mois de prestations effectuées par la SSII, le contrat d’assistance a été dénoncé sur ordre de la SOCIÉTÉ XYZ et une nouvelle recherche de prestataires a été entérinée..
Bien évidemment, les nouvelles exigences de Société XYZ -SOCIÉTÉ XYZ-se sont orientées selon les points sensibles détectés par l’échec de la société TOTO.
Par conséquent, le profil
recherché devait absolument posséder:
- des connaissances approfondies de la solution « »Le progiciel Financier» »;
- des expériences de projets d’envergure;
- d’être aguerri et rompu aux méthodes et à la conduite de projet.
J’ai été contacté par «L’ Editeur de progiciel Financier» France en décembre 19XX pour le projet SOCIÉTÉ XYZ.
Les raisons pour lesquelles je ne l’ai pas été précédemment m’ont été dites bien plus tard. A l’époque des premières recherches, j’accomplissais « aux Brasseries Kronenbourg » une importante mission de conseil, et d’autre part, il est encore délicat pour certaines personnes à la vue de missions dites « stratégiques » de baser la réussite d’un projet à travers l’unique responsabilité d’un indépendant en informatique.
Néanmoins, au point catastrophique où se trouvait le projet SOCIÉTÉ XYZ, toutes les solutions ont été étudiées. J’ai passé toutes les différentes étapes de sélection au même titre que les autres candidats pour obtenir cette mission.
Début décembre 19XX, j’ai rencontré «L’ Editeur de progiciel Financier» . Cette entrevue avait pour but de juger concrètement les compétences du futur chef de projet de la solution « »Le progiciel Financier» » et des modules de la gestion des fournisseurs, gestion des achats et gestion des stocks.
Lors de l’entretien avec le directeur du projet de « L’ Editeur de progiciel Financier» , celui-ci a voulu maîtriser mes compétences et j’ai dû répondre aux questions sur les thèmes suivants :
- Connaissances de la solution progicielle « Le progiciel Financier» 1.0 et 2.0»;
- Expertise de la gestion de projet ;
- Les mises en oeuvres réussies et les références à l’appui ;
- Les aspects de communication et relationnels au sein d’un projet.
La problématique de cet entretien a été de conforter mon interlocuteur sur mon expertise progiciel et de gestion de projet. Nous savions communément qu’aucun consultant européen n’avait l’expérience de cette nouvelle version 3.0.
Le résumé de cette présentation a été de définir :
- Rôle et fonctions du futur candidat (cités précédemment);
- Présentation de l’organigramme du projet;
- La direction de projet, les différents comités;
Nota : Ces deux derniers points sont traités au chapitre 3.2.1.
- La mise en évidence de l’obligation de réussir :
. le choix du candidat vis-à-vis de SOCIÉTÉ XYZ;
. l’importance médiatique et stratégique de ce projet.
«L’ Editeur de progiciel Financier» a procédé à une demande d’information sur mes références de projet et à contacter des utilisateurs et, de nouveau «L’ Editeur de progiciel Financier» France pour une dernière validation.
Après délibération, et après confirmation des références de projet, j’ai été choisi comme nouveau intervenant.
Les motifs de mon choix peuvent
être résumé de la manière suivante :
-
d’avoir été Consultant Senior au sein d’une société de Conseil;
- ma maîtrise des versions antérieures à « Le progiciel Financier» »;
- mon expertise en gestion de projet et en méthodologie;
- mon passé en gestion de production de dix ans m’ayant permis d’aborder les domaines fonctionnels de la gestion des achats et des stocks..
- mon adaptabilité et mes transferts de connaissances des anciennes versions vers la nouvelle.
Les problèmes posés par un consultant indépendant :
avantages :
Globalement, les avantages d’un consultant indépendant sont d’avoir un profil très efficace, caractérisé d’un véritable professionnalisme dans le domaine recherché, accompagné d’une entière disponibilité et motivation à la mission.
inconvénients :
L’un des inconvénients majeurs est la faiblesse juridique de ce statut.
L'image de ce statut est encore très mal perçue au sein de nombreuses directions informatiques et utilisatrices (à l’époque
les mentalités et marchés ayant évolués). Certains font émerger certaines questions :
Et bien d’autres questions sur la légitimité de ce statut (chomâge, âge etc...).
Dans ce cadre, j’ai eu la
confirmation de la mission.
Un seul candidat devait être présenté à la SOCIÉTÉ XYZ. Après la prise en main des derniers éléments concernant la SOCIÉTÉ XYZ, j’ai dû subir une nouvelle étape de validation de la part du client final.
Un rendez-vous a été fixé avec la direction informatique et le chef de projet utilisateur.
Résumé de cette réunion :
- Présentation du futur consultant ;
- Confrontations : les questions posées par la direction du projet de la SOCIÉTÉ XYZ concernant l’ensemble de mes compétences, de mes références. Mes réponses ont satisfait l’ensemble de mes interlocuteurs.
Lors de cette réunion, la validation de ma candidature a toute suite réorientée les sujets de cette réunion. Il fut possible d’aborder le projet :
- Rappel des échecs passés, mise en perspective des attendus du projet;
- Délais : les premières dates des formations et dates de démarrage des analyses.
-Le cadre contractuel :
Un contrat d’assistance a été établi entre «L’ Editeur de progiciel Financier» et la SOCIÉTÉ XYZ pour l’ensemble des modules à mettre en oeuvre. Ce contrat stipulait un nombre de jours de prestations par module.
Mon premier contrat a été un contrat au forfait pour la mise en place du premier module, Gestion des fournisseurs (Account Payable) comprenant un nombre de jours bien précis conduite de projet comprise. Ce contrat pouvait être interrompu à tout moment.
Discussions du nombre de jours étant donné qu’aucun historique n’existait sur l’implémentation du »Le progiciel Financier» ». Un simple planning avait été établi par le directeur de projet sur les bases d’exemples fournis par «L’ Editeur de progiciel Financier» Etats-Unis.
Il me paraissait délicat, voire dangereux, d’accepter ce contrat au forfait sans avoir averti par courrier, de mon manque de visibilité de cette nouvelle version et de son manque de vécu sans parler du précédent échec de la société TOTO.
De plus, j’ai tout de suite
compris à la vue du planning l’existence de graves lacunes :
- le peu de nombre de jours estimés aux analyses d étaillées;
- aucune estimation approximative des dossiers spécifiques;
- aucune méthode et assurance qualité préconisée;
- aucune tâche de pilotage concernant la gestion de projet;
- aucune tâche concernant les phases de recette, de test etc..;
Je reviendrai sur tous ces points au chapitre 3.
D’un commun accord, nous nous
sommes entendus de l’existence possible de futures extensions de contrat à
justifier point par point. (contrat d’assistance)
Mon premier challenge était une validation des cycles de formation par la SOCIÉTÉ XYZ du module fournisseur.
La formation s’est déroulée à la société XYZ en Mars 19XX et avait deux buts avoués :
- d’une part, la prise de connaissance des fonctionnalités du module;
- d’autre part, de juger le niveau de compétence du consultant.
- le poids psychologique :
Rappelons-nous l’échec à ce sujet de la société TOTO. Déjà évoqué au sein du chapitre précèdent, il était impératif de réussir ce premier cycle de formation afin de prouver mes compétences fonctionnelles et de chef de projet.
De plus, je vous rappelle :
- l’aspect contractuel pour la suite de la mission : Réussir cette formation.
- l’importance du choix du consultant de la part de «L’ Editeur de progiciel Financier» » vis-à-vis de la SOCIÉTÉ XYZ.
Il est évident que dans de tels contextes, la maîtrise de soi devient un facteur décisif et ceci, malgré le fait de posséder l’intégralité des compétences demandées.
J’ai dû investir personnellement, et en dehors de mon emploi du temps, dans une auto-formation concernant les modules fournisseurs ( -Account Payable-) et achats (- Purchase Order-). Possédant un AS400 modèle B10, et d’un commun accord avec « »L’Editeur» », j’ai pu obtenir un contrat à zéro franc de la solution « »Le progiciel Financier» ».
Après l’installation du produit, j’ai passé des soirées et week-ends entiers pendant près de trois mois à étudier ce nouveau progiciel.
D’après le planning prévu par «L’ Editeur de progiciel Financier» » et en respect des délais de mises en oeuvre, un découpage des sessions de formations a été défini comme suit :
Par domaine fonctionnel :
- Fournisseurs;
- Gestion des Achats;
- Gestion des stocks.
Les dates des cycles de formation :
- Mars 19XX : la gestion des fournisseurs (-Account Payable-);
- Juillet 19XX : la gestion des achats (-Purchase Order-);
- Mars 19XX : la gestion des stocks (-Inventory Control-).
Contractuellement, chaque cycle de formation a été une étape de validation pour la suite de la mission.
Comme je l’ai expliqué précédemment, il était essentiel de préparer la première session de formation et de survoler les autres modules fonctionnels afin d’avoir un aperçu général de l’ensemble de la solution.
Ma motivation était l’attrait de cette nouvelle mission, des effets médiatiques attendus par «L’ Editeur de progiciel Financier» et l’apprentissage de cette version « ‘«Le progiciel Financier».
J’ai reçu de la part de mon client «L’ Editeur de progiciel Financier» toutes les documentations de chaque module.
Par contre, les constats et mes actions ont été les suivants :
- les supports de cours existants en langue anglaise;
- les supports inexistants ou en cours d’élaboration: effectivement concernant la gestion des stocks, aucun support de cours existant.
Suite à l’insuffisance de la documentation livrée et aux impératifs contractuels, j’ai décidé d’investir dans une documentation personnalisée à chaque module. Cet investissement personnel, à la vue des trois mois impartis avant la première session de formation, se devait succinct et efficace. Effectivement , il m’était impossible de créer des cours de formation par manque de temps.
Donc, la directive principale entreprise à ce sujet ,a été de hiérarchiser les différents niveaux de connaissance et d’apprentissage des modules. J’ai créé mes propres outils d’éducation avec pour objectif d’obtenir une vision globale et synthétique du système, en passant aux événements et informations principaux les plus détaillés :
Une approche méthodique tout à fait personnelle :
La
vision globale et synthétique ou la photographie générale du système : « le diagramme à flèches ».
Fort peu employé en informatique de
gestion, et à l’inverse très connu dans le domaine de l’intelligence
artificielle, ce diagramme permet de juger toutes les actions et événements
liés aux entités principales du module fonctionnel. J’ai découvert ce diagramme
grâce à une lecture d’un tout premier dictionnaire informatique[1].-
Une approche méthodique standard
:
Il est important à l’heure actuelle de maîtriser au moins un AGL. J’ai travaillé avec différents logiciels et en autres « MEGA » et « ACM-Designor » dont le concept est la méthode « MERISE ».
La
visualisation de l’ensemble des domaines :
cerner le système : Le modèle conceptuel de communication. (MCC)
La
visualisation par domaine :
- cerner le domaine : Le modèle conceptuel de données.(MCD)
La
visualisation par processus défini :
- cerner les traitements principaux : Les modèles conceptuels de traitements.(MCT)
J’ai établi les différents modèles pour les fonctions les plus importantes du domaine étudié.
- La durée des sessions de formation :
- Mars 19XX la gestion des fournisseurs (-Account Payable-) :
7 jours de formation et le nombre a été 10 participants ;
- Juillet 19XX la gestion des achats (-Purchase Order-) :
10 jours de formation et le nombre a été 12 participants;
- Mars 19XX la gestion des stocks (-Inventory Control-) :
3 jours de formation et le nombre a été 10 participants;
-Les premiers contacts avec
l’équipe du projet :
Bons nombres de formation sont principalement assurées par des formateurs n’ayant aucun lien avec le projet. Ce sont des cycles standards établis par l’éditeur de logiciel lors d’une proposition commerciale.
Concernant le contexte particulier du projet de la SOCIÉTÉ XYZ expliqué au chapitre 1, le futur chef de projet devait affronter ces cycles de formations et prouver son professionnalisme à travers ces cycles.
Ce professionnalisme devait exprimer les connaissances du progiciel abordé, son sens de la pédagogie et sa maîtrise en terme de personne.
Les cycles de formation ont
permis une véritable confrontation entre les différents intervenants du projet.
Cette confrontation est
expliquée au paragraphe suivant.
- Expliquer succinctement la
future organisation et démarche du projet :
En tant que futur chef du projet du domaine, certaines questions ont été exprimées par les utilisateurs et les sociétés extérieures sur la conduite de projet proprement dite. J’ai conforté l’ensemble des intervenants par mes réponses.
Mon expérience des hommes et des projets m’ont affranchi de ces premiers obstacles et qui ont peut-être été néfastes à la société TOTO.
La pédagogie n’est pas quelque chose d’évident surtout lorsque l’on est habitué à des actions de terrain. Le principe d’un projet d’envergure se veut d’être long dans le temps, par conséquent difficile et délicat vis à vis des hommes.
Cette pédagogie se doit de donner une vue claire et concise d’un projet et des futurs thèmes qui seront implèmentés.
Je sais que cette pédagogie devra faire place demain à un esprit fédérateur et communicatif, avec ses aléas et ses turpitudes.
En tant que « consultant en informatique », il me parait nécessaire de participer à de tels cycles .
Ces cycles de formation donnent
la teneur du projet et des motivations des différents acteurs.
Ils permettent de détecter :
-
Les utilisateurs les plus pertinents pour la suite du projet;(Le savoir de
l’entreprise)
-
Les problématiques liées à l’entreprise ; (les problèmes liés aux hommes)
-
Les motivations des uns et des autres;(implication du Guide fonctionnel)
-
l’organisation des services (Guide de procédure..)...
-
Les futurs problèmes du projet.(Spécifications ).
Ce qu’il faut éviter pendant un cycle de formation :
Les pièges et les erreurs à ne pas
commettre, sont principalement, d’éviter de répondre à des problèmes liés
directement au futur projet (concept, modélisations ou hommes) . Même si ces
cycles de formation sont délivrés en interne du site client, il est impératif
de respecter cette règle d’or : se restreindre à délivrer une formation
standard attachée aux principes
généraux du progiciel, le but essentiel étant la compréhension du produit livré
et de ses fonctionnalités sans entrer dans le métier de l’entreprise.
- La transmission du savoir:
Cette transmission doit s’effectuer dans un cocktail de connaissances du produit mêlées à des expériences concrète de projet.C’est l’apport culturel ou comment l’expérience des projets et des domaines fonctionnels peuvent -être les garants d’une formation réussie.
Après la formation du premier module fournisseur (Account Payable), j’ai eu la validation de la SOCIÉTÉ XYZ du premier cycle de formation : le premier challenge réussi.
Les objectifs principaux de ce chapitre sont de décrire mes fonctions et mes responsabilités au sein du projet de la société XYZ tout en identifiant les rôles de chacun, leurs implications, les constats des méthodes existantes et à revoir du projet.
Mes fonctions dans le projet de la SOCIÉTÉ XYZ sont celles d’un véritable chef de projet informatique avec des attendus de management, d’expertise en gestion de projet, de méthodologie et des connaissances fonctionnelles et techniques associées aux progiciels . (voir les chapitres 3, 4 et 5). Elles ont déjà été abordées au titre du « chapitre 1 » lors des recherches d’un consultant de haut niveau et lors des aspects contractuels de la mission.
- Animation des sessions de formation des différents modules de la solution progicielle;
- Planification, encadrement et suivi d’avancement du projet du progiciel;
- Formalisation des besoins relevant de chaque domaine du progiciel;
- Conseils relatifs à l’élaboration des solutions requises par la mise en oeuvre;
- Modélisation et réalisation du paramétrage nécessaire à la mise en oeuvre des produits.
-
Participation aux différents comités utilisateurs ;
- Contrat d’assistance-
Mes responsabilités sont forcément à l’image des fonctions citées ci-dessus, accompagnées d’obligations contractuelles et de motivations liées à la réussite de ce projet.
Ces responsabilités et
motivations peuvent être résumées de la manière suivante :
- Elaborer les plannings en identifiant les aspects technologiques, les ressources humaines et les coûts.
- Piloter ces différents projets au travers d' actions et de décisions à fin de respecter les objectifs et les délais avec l'obtention de résultats satisfaisants ;
- Assembler le plus rapidement possible les différents composants logiciels qui doteront l'entreprise de systèmes performants et fiables répondant aux besoins des utilisateurs de la SOCIÉTÉ XYZ;
- Se faire reconnaître impérativement comme le protagoniste de la solution auprès des équipes pluridisciplinaires
- Réussir contractuellement et fonctionnellement là où d’autres ont échoué.
J’ai la direction des trois projets qui me sont confiés ayant pour interlocuteurs principaux tous les responsables et les chefs de services des différents domaines fonctionnels à mettre en oeuvre.
Chaque groupe de projet est
constitué :
- d’un chef de projet, expert du produit à mettre en place;
- d’un chef de projet, responsable du service de l’entreprise SOCIÉTÉ XYZ concerné par la mise en place;
- d’un adjoint au responsable de service;
- d’un correspondant informatique;
- d’un groupe de travail constitué de plusieurs utilisateurs.
Mes responsabilités des
hommes au sein de la direction des trois projets :
la gestion des fournisseurs (-Account Payable-) : 10 personnes;
la gestion des achats (-Purchase Order-) : 10 personnes;
la gestion des stocks (-Inventory Control-) : 8 personnes.
Nous retrouvons dans le chapitre 5, et, au delà de ces responsabilités des trois projets à mettre en oeuvre, mes nouvelles prises en charges suivantes :
- les analyses : des migrations, des dossiers spécifiques et des interfaces;
- suivi des avancements des développements spécifiques.
Le référentiel d’un projet est souvent employé en intégration des systèmes informatiques. L'intégration des systèmes en informatique consiste à "intégrer" des matériels et logiciels standards ou spécifiques, ayant pour objet de répondre à
l'ensemble des besoins des services opérationnels d'une entreprise.
L'intégration des systèmes définit les rôles prépondérants du maître d'ouvrage, promoteur du futur système, et du maître d'oeuvre, le bâtisseur, sans oublier les rôles importants des autres acteurs. (groupes applications, technique,
et des sous-traitants)
Le référentiel du projet de la
SOCIÉTÉ XYZ présente certaines lacunes telles que l’absence d’une direction
technique, d’une cellule contrôle qualité, des groupes de formation
utilisateur.....
c'est la direction financière et la
direction informatique de la SOCIÉTÉ XYZ.
Ces maîtres d'ouvrage :
Ils ont énoncé les objectifs de la solution, mettant tous les moyens « possibles » à disposition du maître pour faciliter toutes les interventions fonctionnelles et techniques nécessaires au futur système.Ils valident toutes les évaluations économiques et fonctionnelles des différents domaines du système investi par le maître d'oeuvre.Ce sont les promoteurs de nouveau système.
Ils réceptionnent et valident les livraisons effectuées par le maître d'oeuvre.
Concrètement, ces maîtres d'ouvrage sont constitués par les membres d'une direction générale. Son appellation est souvent "COMITE DIRECTEUR" ou "COMITE DE PILOTAGE (dit « COMPIL » par les équipes)
société XZY : son représentant est M.DUPONT1 ;
«L’ Editeur de progiciel Financier» représenté par M.DURAND1;
Leurs fonctions sont principalement de :
-
Savoir dialoguer et comprendre les objectifs émis par le maître d'ouvrage;
-
Savoir communiquer le message auprès
des équipes;
-
Avoir un esprit d'analyse et de synthèse;
-
Rigueur et sens de l'organisation dans la direction de projet.
société XZY:que nous appellerons M.DUPONT2 du service informatique;
«L’ Editeur de progiciel Financier» : M.DURAND2
leurs rôles et fonctions
principales sont de:
-
valider l'architecture logicielle sur les décisions appropriées et adéquates
aux besoins en base de données, temps-réel, mode différé etc....
-
rechercher une configuration du système: . maintenance des composants logiciels
spécifiques ou standards, en préconisant, au titre des logiciels standards,
l'exigibilité des futurs versions dites "ascendantes".
-
Validations des performances techniques en établissant des "bench
mark" sur des traitements particuliers.(problème de volumétrie...)
-
En liaison avec le groupe application,
M.DUPONT2 établira l'architecture technique du système en mettant en
relief les problèmes de
réseaux.(bases de données réparties etc...)
-
responsabilité de l'ensemble des documentations techniques des logiciels
spécifiques ou standards.
Par contre, les responsabilités du matériel sont du ressort de la SOCIÉTÉ XYZ :
. Valide les matériels en termes de réseaux;
. Recette et intègre les matériels;
. planifie les migrations;
. normalise les futurs traitements d'exploitation.
En plus de la relation maître d'ouvrage et maître d'oeuvre, un transfert de la connaissance s'effectuera par la délégation du maître d'ouvrage vers un chef de projet utilisateur accompagné de plusieurs utilisateurs d'un domaine fonctionnel localisé.
La direction du groupe d’application est sous mon entière responsabilité accompagnée par le chef de projet utilisateur..
Rôle et fonctions principales
du groupe application :
-
Il analyse l'ensemble des besoins et spécifications des utilisateurs.