Management des Projets 2.0 (PM2.0)

L'avènement du web 2.0 a bouleversé plusieurs pratiques et concepts dans le monde, on parle aujourd’hui de Marketing2.0, Économie 2.0 et même de Médecine 2.0. Ce phénomène n'a pas du tout épargné le management des projets et tous les professionnels de cette discipline ont dû remarquer les mutations qui s'y sont opérées ces dernières années. Ce phénomène a donné naissance au Project Management 2.0 (ou PM2.0) dont les différences avec le management des projets traditionnels se situent surtout au niveau des outils utilisés, la distribution de l'information et voire même dans le rôle du manager de projets.

Par le passé les organisations déployaient des environnements logiciels complexes et très coûteux pour prendre en charge les activités de gestion de projets. Certains éditeurs comme Microsoft ou Oracle se sont frottés les mains avec leurs outils (EPM de Micro$oft ou Primavera de Oracle). Les praticiens du PM2.0 utilisent des outils souples et souvent open-source disposant de fonctionnalités intéressantes pour rendre la pratique possible en les associant.

Les équipes projets dans le PM2.0 sont aussi souvent distribuées dans le monde  avec des écarts de fuseaux horaires qui peuvent être très importants, ce qui nécessite des modes de communications appropriés. Les réunions sont souvent effectuées en ligne utilisant des outils collaboratifs. La formule sacrée dans le processus de gestion des communications qui consiste à déterminer le nombre de chaines de communications entre N participants par N*(N-1)/2 n'est plus valable ici et les chaînes deviennent infinies. Le manager des projets traditionnel passe 90 % du temps dans la communication mais dans le PM2.0 tous les canaux sont ouverts et l'information est accessible à tous et en temps réel via des outils comme les blogs de projets et voire même les réseaux sociaux.


La structure distribuée des équipes et l'environnement collaboratif requiert aussi un changement dans le rôle même du manager des projets qui doit amplifier plus ses fonctions de facilitateur et leader qu'autre chose.

Enfin le manager des projets 2.0 est Agile, Il est donc Itératif, Incrémental et Adaptatif. Il prône les valeurs des méthodes agiles telles que l'esprit d'équipe, la collaboration et l'ouverture au changement. Il met le client (interne ou externe) au centre de tout et l'implique de façon continue. Il privilégie le résultat par rapport à la procédure.

                    Adamou Moussa PMP, ITILv3, CSSBB, Scrum Master


 

Passer la certification PMP...Challenges et Opportunités

La certification PMP délivrée par l'institut PMI (Project Management Institute, USA) est vue aujourd’hui comme l'accréditation la plus importante et la plus prisée en management des projets. On dénombre à environ 500.000 le nombre de gestionnaires de projets certifiés PMP dans le monde.
Étant certifié PMP je voudrais partager dans ce billet quelques challenges aux quels un candidat PMP pourrait faire face ainsi que les opportunités qui s'offrent aux détenteurs de cette certification.

D'abord il faut noter que pour passer la certification il faudra remplir certaines conditions d'éligibilité qui sont:

• Une expérience professionnelle justifiable en conduite de projet
•  Pour les titulaires d'un diplôme BAC+4 ou plus, il est exigé d'avoir 3 ans d'expérience professionnelle en conduite de projets, représentant 4500 heures de travail. 
• Pour les titulaires d'un diplôme secondaire (Bac +3)  il faut avoir 5 ans d'expérience professionnelle en conduite de projets, représentant 7500 heures de travail.
• Justifier de 35 heures de formation dans le domaine de la gestion de projets.

Une fois que ces conditions sont remplies le futur candidat pourrait demander à l'institut PMI une éligibilité à passer l'examen. Cela consiste à remplir un formulaire en ligne qu'on trouve sur le site www.pmi.org et le soumettre à la validation du PMI qui prendra un délai de 5 jours environ pour répondre. Le candidat pourrait être soumis à un audit de l'institut afin de vérifier toutes les informations fournies dans le dossier de demande d'éligibilité d'où il est important de disposer de pièces justificatives des formations et expériences indiquées dans le formulaire.
Lors que le candidat est déclaré éligible il recevra un message électronique avec le numéro d'éligibilité et devra donc payer les frais d'examens et planifier la date et le lieu de l'examen.
Tous les examens PMP se passent dans des centres spécialisés agréés par PROMETRIC.
L'examen dure 4 heures et comporte 200 questions sur l'ensemble des domaines et méthodes en relation avec le management de projets. Le score minimal est de 61 % de bonnes réponses sur les 175 questions notées (les 25 autres questions sont utilisées comme des questions test).
La certification valide les compétences et expériences du candidat à conduire un projet et se base sur le corpus des connaissances en management des projets (PMBok qui est à sa version 5 en ce moment où cet article est écrit) et le code d'éthique professionnelle édicté par l'institut PMI.
Le corpus des connaissance PMBok identifie cinq groupes de processus en management des projets à savoir le Démarrage, la Planification, l'Exécution, le Contrôle et Surveillance et enfin la Clôture.
Le corpus identifie aussi Dix domaines de compétences en management des projets qui sont:

• Le management de l'intégration
• Le management du contenu (ou périmètre)
• Le management des délais
• Le management des coûts
• Le management de la qualité
• Le management des ressources humaines
• Le management des communications (au pluriel)
• Le management des risques
• Le management des approvisionnements
• Le management des parties prenantes (Ce domaine est ajouté dans la 5ème édition du PMBOK).

Chaque domaine de connaissances comprend plusieurs processus disposant d'intrants (inputs), d'extrants (outputs ou livrables) , des techniques et des outils. Il y en a au total 47 processus.

La proportion de questions depuis septembre 2010 est comme suit pour les différents groupes de processus:

• démarrage : 13 % ;
• planification : 24 % ;
• exécution : 30 % ;
• contrôle et surveillance : 25 % ;
• clôture : 8 %.

Pour passer l'examen il convient de maîtriser tous les processus avec leurs intrants, extrants, techniques et outils, ce qui nécessite une préparation ardue et consommatrice de temps.
Diverses méthodes de préparation à l'examen PMP existent dont la meilleure reste une classe interactive avec un modérateur expérimenté en management de projets et lui-même certifié PMP.
Cela donne la possibilité aux candidats de comprendre tous les enjeux de l'examen par des questions directes et les interactions entre différents candidats permettront non seulement d'échanger mais aussi de créer plus tard un réseau fiable de gestionnaires de projets. Il existe des simulateurs d'examens  qui permettent de s'exercer et d'adopter les bons réflexes de l'examen réel (mais ici il faut noter que certains ne sont pas conformes à l'examen PMP).

Il y a plusieurs avantages à disposer d'une accréditation PMP et on peut en citer certains (non exhaustifs) :

• Les titulaires PMP peuvent user du sigle PMP dans leurs communications officielles.
• La certification PMP démontre la capacité d'un chef de projet à conduire un projet de bout en bout car justifie la formation, les compétences et l'expérience requises.
• Dans certains pays et pour certains projets la certification PMP est une exigence pour prétendre à un poste de manager de projets
• Une étude montre que les managers de projets certifiés PMP sont payés 13% plus que leurs homologues non certifiés.

Si vous êtes en Afrique de l'Ouest et avez besoin de plus de renseignement ou envisagez de passer cette certification alors vous pouvez contacter le cabinet Smart'ISS (contact@smartiss.com) spécialisé en Management de projets et Maîtrise d'Ouvrage SI.

                                                  
 Adamou Moussa, PMP, ITILv3, CSSBB, Scrum Master

Intégration du SI avec les Plateformes de services chez les opérateurs telco : Impact sur la gestion de l'expérience client

Dans la gouvernance des opérateurs de télécommunication le Système d'Information est souvent composé des applications de Gestion de la relation client (CRM), Médiation, Facturation, ... et les plateformes de services à valeur ajoutée permettent quant à elles de fournir des services à valeur ajoutée (communément appelés SVA) aux clients comme la messagerie vocale, la radio/TV sur mobile etc.

Le client est au coeur de l'entreprise et la gestion de son expérience est une préoccupation principale dans l'architecture des services qui lui sont fournis.
Il n'est pas rare de trouver chez les opérateurs des services hébergés sur des plateformes autonomes n'ayant aucun lien avec les applications de gestion des clients. Il est ainsi évident que le parcours du client de bout en bout ne sera suivi de façon optimale.
Un des moyens d'améliorer l'expérience client sur les SVA, l'intégration avec le SI se présente comme un élément de réponse.

Pour mieux définir les points d'intégration disponibles entre le SI et les plateformes de services on peut se baser sur le parcours du client depuis l'activation du service jusqu'à sa résiliation.
Ainsi on pourrait avoir à créer des liens avec le SI lorsque:
- Le client souscrit au service,
- Le client modifie le niveau de service auquel il a souscrit,
- Le client demande du support sur le service,
- Le client résilie le service.

Pour les opérations de souscriptions et modifications de service le client passe par différents canaux comme le SMS, l'USSD, l'IVR, le Web et depuis quelques temps les applications mobiles. A ce niveau il faudra que l'information de souscription remonte au CRM pour mettre à jour le dossier du client. Cela permet de donner une vue exhaustive du client avec la liste des clients aux quels il a souscrit.
Concernant le support du client sur l'utilisation du service il est important que les outils de gestion de support client intègrent des rubriques pour les SVA pour permettre une meilleure gestion des requêtes / incidents clients et donner donner la vue aux chefs de produits sur les types de problèmes que les clients rencontrent souvent et la complexité de l'expérience client.
La désactivation du service interviendrait lorsque le client lui même décide de résilier le service ou lorsque celui-ci n'a pas les moyens de renouveler la souscription.
La désactivation devrait aussi intervenir lorsque l'opérateur décide de recycler les ressources allouées à certains clients  lorsque ceux deviennent inactifs. Dans ce cas il est indispensable de désactiver le service car si les ressources sont re-allouées à un autre client celui-ci pourrait avoir accès aux données du client précédent. Et dans le cas de certains services critiques comme le mobile money ou la sauvegarde de répertoire la violation d'accès à ces données pourrait poser des problèmes juridiques. L'opérateur doit donc inclure dans ses routines de recyclage la désactivation des SVA pour les clients recyclés.
Pour que toutes ces opérations puissent se passer de façon souple les fournisseurs de SVA doivent adapter leurs plateformes en les dotant d'interfaces ouvertes permettant une gestion déléguée des opérations client par les applications du SI.
Lorsque ces interfaces sont rendues disponibles les plateformes de services pourraient s'intégrer avec les applications du SI pour permettre une gestion fiable de l'expérience client sur les services à valeur ajoutée.

Cloud computing et Opportunités pour les DSI (africaines)

De nos jours la plupart des DSI sont confrontées à la problématique budgétaire. Les marges financières des entreprises ne permettent plus d'investir beaucoup dans l'informatique ni même de maintenir l'existant, et cela malgré la croissance des besoins dans le domaine.
Les informaticiens ne doivent plus se contenter de délivrer des résultats mais ils doivent le faire avec moins de moyens. Bref ils doivent être efficients !
Pour faire face à cette situation les DSI doivent de plus en plus faire appel au concept de cloud computing pour réduire de façon substantielle les dépenses IT.
En quoi consiste le cloud computing ? Quels sont ses différents modèles ? Quels avantages et quels inconvénients ? Quelle stratégie adopter ? Autant de questions auxquelles je vais essayer d'apporter des éléments de réponse dans ce billet.
Le Cloud computing ou Informatique en nuage consiste à utiliser à la demande des ressources informatiques mutualisées en libre service. Ces ressources peuvent être des serveurs d'application, de bases de données ou des applications, etc.
On distingue généralement trois modèles de cloud computing à savoir:

• Infrastructure as a Service (IaaS): Ce modèle consiste à utiliser à la demande les capacités de traitement et/ou de stockage d'une infrastructure hébergée en dehors de l'entreprise. Cela permet d'optimiser les ressources matérielles à acquérir ainsi que la consommation en énergie et en espace d'où une baisse importante des coûts liés à l'acquisition de serveurs (Capex) et ceux liés à leur exploitation (Opex). Ce modèle permet aussi d'améliorer considérablement le taux de disponibilité des équipements.
• Platform as a Service (PaaS): Ce modèle permet, en plus de l'infrastructure, d'utiliser de façon mutualisée à la demande et en libre service les frameworks de développement et autres middlewares comme les serveurs d'applications et de bases de données hébergées sur un site distant. Par exemple une entreprise qui dispose d'applications LAMP pourrait payer uniquement les frais d'accès à un éditeur PHP pour ses développeurs, un espace sur un serveur Apache et une base MySQL. Les informaticiens accèdent librement aux ressources leur permettant de développer leurs applications , les déployer et les exécuter. L'entreprise, en plus des avantages liés au modèle IaaS, économise sur les paiements de licences pour les middlewares et leurs coûts d'exploitation, réduit les interventions humaines et les délais de déploiement.
• Software as a Service (SaaS): En plus de l'infrastructure et des middelwares ce modèle permet d'utiliser une application distante et mutualisée à la demande et en libre service. Les utilisateurs accèdent aux applications et l'entreprise est facturée à l'usage. Par exemple une entreprise pourrait décider d'avoir son CRM en SaaS, ainsi elle paiera par exemple que pour le nombre de prospects, comptes et affaires créés. Il en ressort clairement une réduction importante des coûts fixes dans les budgets IT.

Le concept de cloud apporte certes des avantages énormes de scalabilité et d'optimisation de coûts mais il présente aussi quelques inconvénients qu'il faut prendre en considération. Il s'agit surtout de :

• La sécurité des données stockées dans le nuage.
• La localisation des données étant abstraite, cela pose quelques problèmes juridiques car certains pays interdisent le stockage à m'étranger des données liées à leurs citoyens.
• La qualité du service en cloud dépend beaucoup de la fiabilité du réseau (sécurité et bande passante). Ce qui est un frein important pour certains pays africains ayant une bande passante très limitée pour l'accès à Internet.

L'adoption du paradigme de cloud computing passe par le choix d'architectures standards. Il faut standardiser l'infrastructure à travers l'adoption des technologies de virtualisation. Il faut ensuite cartographier l'existant afin de déterminer les applications qui peuvent être "nuagisées" et celles qui ne peuvent pas l'être. Les critères pourraient être la consommation en ressource, l'architecture logicielle, la sécurité des données etc. Les applications les plus aptes à passer au cloud sont celles développées selon le modèle SOA.

Urbanisation du Système d'Information

L'urbanisation du Système d'information consiste à le faire évoluer pour l'aligner sur la stratégie et aux besoins métiers de l'entreprise suivant des règles d'architecture SI. Cette activité est aujourd'hui capitale pour disposer d'un SI créateur de valeur ajoutée et qui participe à l'exécution de la stratégie de l'entreprise. Globalement en quoi consiste le processus d'urbanisation ? Quels sont les outils qui le permettent ? Quels sont ses apports dans le management du SI ?
Voilà des questions aux quelles je vais essayer de répondre dans ce billet.

Le processus d'urbanisation passe par les étapes suivantes:

1. Modélisation de la stratégie et des besoins métiers de l'entreprise: A cette étape il faut répondre aux interrogations suivantes: Quels sont les besoins des métiers en matière de système d'information ? Quelle est la stratégie autour de la quelle l'entreprise cherche à développer son business ?
Ensuite il faut modéliser ces besoins et bien les spécifier.

2. Modélisation de l'existant SI: Ici il faut cartographier les 4 niveaux de l'architecture SI tels que préconisés à savoir
- L'architecture métier qui décrit les processus métiers de l'entreprise
- L'architecture fonctionnelle qui décrit les fonctions qui supportent les processus métiers décrits dans l'architecture métier
- L'architecture applicative qui donne les applications qui supportent les fonctions décrites précédemment
- Et enfin l'architecture technique qui décrit les infrastructures techniques qui supportent les applications.

Une fois muni de ces deux modélisations (Existant SI, enjeux et stratégie business) le vrai travail de l'urbaniste SI commence et cela consiste à:

3. Étudier la cible SI qui permettra de répondre aux enjeux business recueillis et modélisés tout en respectant les règles de l'état de l'art.
En partant de l'existant SI il faut définir la trajectoire à suivre (un ensemble de scénarii) pour arriver à la cible et évaluer les moyens humains et financiers permettant d'atteindre cette cible. Cette étape est sans doute la plus difficile mais aussi la plus passionnante car c'est à ce niveau que l'urbaniste exprime son génie et sa capacité à définir, planifier et évaluer un SI aligné sur les besoins métier.

Il faut noter que pour un besoin de cohérence du processus global il est important de valider à chaque étape les livrables. En effet il faut s'assurer de bien modéliser la stratégie de l'entreprise en la validant avec les métiers et s'assurer aussi de bien cartographier le SI existant en validant sa cartographie avec les experts informatiques.

Aussi pour mener à bien un projet d'urbanisation il est important de s'assurer que l'instance dirigeante de l'entreprise est convaincue de la nécessité d'un tel projet et des apports qu'il peut apporter à son SI. Il faut aussi avoir l'adhésion des équipes et leur forte implication dans le projet.
Sans ces pré requis un projet d'urbanisation court non seulement les risques de partir sur de mauvaises modélisations de la stratégie business et de l'existant SI mais aussi de proposer un plan d'urbanisation qui sera inapproprié et non partagé.

Dans cette ère nouvelle où l'alignement stratégique du Système d'information est indispensable à l'entreprise pour atteindre ses objectifs métiers l'urbanisation de ce dernier se présente comme un passage privilégié pour ne pas dire obligé.

Gouvernance des SI

Je préfère vous le dire tout de suite: Ce billet n'est pas un cours de gouvernance des systèmes d'information et n'a pas la prétention de l'être. Il s'agit plutôt d'idées amassées ici et là et mises en pratique pour certaines dans des contextes assez intéressants. Le management des systèmes d'information est une science vaste sur la quelle vous trouverez beaucoup de documentation car la recherche dans ce domaine est très active, ce qui démontre bien de l'importance du sujet.
La gouvernance est une composante très importante du management des systèmes d'information et a pour objectif principal de permettre au SI de créer de la valeur et dépasser la vieille conception du SI comme simple centre de coûts. On y retrouve généralement les thèmes suivants:
- L'alignement stratégique du SI avec les métiers
- L'organisation et la planification du SI
- L'évaluation des performances du SI
Je vais donner quelques commentaires sur les thèmes précédents.

** L'alignement stratégique du SI consiste à inscrire ce dernier dans une dynamique de déclinaison des objectifs de l'entreprise en objectifs informatiques. Le modèle d'Henderson et de Venkatraman décrit les différents types d'alignement qu'on peut trouver. Ce modèle décrit quatre stratégies qui décrivent le SI comme une exécution de la stratégie de l'entreprise, un potentiel technologique, un potentiel concurrentiel ou un centre de services. On peut aussi trouver dans une même organisation une combinaisons de ces stratégies. Par exemple chez un opérateur télécom on doit avoir les entités en charge de l'innovation comme un potentiel technologique et concurrentiel et les entités en charge des applications métiers seront vues comme une exécution de la stratégie de l'entreprise ou centre de services selon leur maturité.
** L'organisation et la planification du SI a trait aux différents outils permettant de pérenniser l'existant et de garantir l'évolutivité. Pour pérenniser l'existant il est important d'aborder une démarche d'urbanisation qui s'appuie sur une cartographie claire des différentes fonctions ainsi que les couloirs de passage (interfaces) entre ces fonctions. Planifier le SI consiste à avoir une vision de la direction à suivre à travers l'élaboration d'une roadmap c'est à dire un schéma directeur SI.
** Le pilotage du SI passe par la mesure des performances de celui-ci, performances qui se mesurent à travers des indicateurs clés. Le IT Scorecard est un outil de pilotage SI qui décrit cinq volets à savoir la contribution du SI au business, la maîtrise des coûts du SI, la performance des processus SI, la gestion des compétences pour une prise en compte du futur et l'orientation utilisateurs.

Évidemment d'autres thèmes existent sur le sujet de la gouvernance qui est un domaine très évolutif et j'espère que j'aurais le temps matériel d'aborder ces thèmes dans de futurs billets.

Le fossé technique-fonctionnel

Force est de constater qu'aujourd'hui de plus en plus de projets informatiques sur la production logicielle débouchent sur un chaos total caractérisé particulièrement par la non-satisfaction des utilisateurs finaux et des délais de réalisation sans cesse prolongés, Et ce en dépit d'une forte croissance des technologies de développement logiciel. Les frameworks de développement pullulent partout et il est même difficile de faire un choix. Il y a quelques années nos ainés utilisaient des outils/langages basiques comme basic, cobol, vb etc. mais produisaient des logiciels de grande qualité, c'est ce qui explique d'ailleurs l'entêtement de certaines entreprises à ne pas se débarrasser de leurs vieux logiciels sur écran console malgré la pauvreté des IHM. Elles se disent satisfaites de ces logiciels qu'elles trouvent bien adaptés à leurs besoins fonctionnels. Il faut dire que nos ainés étaient beaucoup plus préoccupés des aspects fonctionnels que nous. Ils passaient beaucoup de temps sur les sujets de réccueil de besoins, de spécifications et de modélisation que sur le développement. Aujourd'hui la tendance des équipes de production logicielle est plutôt vers la maîtrise des technologies plutôt que la maîtrises des méthodes de récceuil de besoins ou de modélisation. Les informaticiens d'aujourd'hui se sentent plus fiers de connaître les plateformes JEE, .Net ou PHP5 que de connaître les méthodes RUP, 2TUP. A mon humble avis c'est là où le bat blèsse, les équipes de production logicielle sont plus techniques que fonctionnelles et développent des logiciels à la pointe des technologies mais fonctionnellement inadaptés aux besoins des utilisateurs finaux. Le fossé technique-fonctionnel s'agrandit de plus en plus en faveur de la technique et ce au grand désarroi des consommateurs de logiciels.

SOA et BPM: Un couple presque parfait!

Une bonne gestion des processus métier contribue beaucoup dans l'accroissement des performances de l'entreprise en ce sens qu'elle permet de réduire énormément les pertes de temps et d'augmenter l'efficacité opérationnelle à travers l'élimination des tâches n'ayant aucune valeur ajoutée. Mieux encore, lorsque les processus sont bien cartographiés, automatisés et pilotés cela donne une visibilité claire sur les performances de l'entreprise et les points à améliorer. Pour ce faire la gestion des processus métier gagne à s'appuyer sur des outils et méthodes éprouvés. C'est ce qui explique l'orientation des éditeurs d'outils BPM vers l'adoption de langages standards de modélisation de procédures basés sur XML et l'utilisation des web services comme moyen d'interfaçage avec les système d'information d'entreprise. Les processus métiers utilisent de plus en plus les architectures orientées services (SOA).
En effet SOA est devenu la pierre angulaire de l'urbanisation des systèmes d'information au vu de son apport dans l'interopérabilité et l'intégration applicative; depuis que les web services XML connaissent un essor tel qu'ils s'imposent comme les fondamentaux d'une architecture pérenne. L'utilisation de ces architectures dans la gestion des processus métier apporte aux entreprises une grande souplesse dans l'interaction entre ceux-ci et le système d'information.
Par exemple un processus automatisé de gestion de notes de frais est beaucoup plus efficace lorsqu'il communique directement avec le système de gestion de paie. Nous pouvons imaginer aussi un processus dont les différents nœuds de traitement interagissent avec les éléments du SI, il est évident que pour des raisons de souplesse et de réutilisabilité ce processus est plus facilement optimisable si ses interfaces avec le SI sont basées sur des web services. La cerise sur le gateau serait que ce même processus puisse être ré-utilisé dans un autre processus simplement comme un service, eh bien cela est rendu possible grâce au langage BPEL4WS. En effet l'orchestration des processus métier grâce à BPEL est l'autre trait de charme qui a facilité et facilite encore le rapprochement de SOA et BPM qui donnent l'air d'être un couple presque parfait.

Histoire d'un Lancement de SI chez un Opérateur Fixe/Mobile/Internet

Le 21 Avril 2008 j'arrive chez un opérateur FMI durant son lancement from scatch en tant que chef de projet SI. Lors de mon entretien avec le DSI les objectifs qui m'étaient assignés consistaient d'abord à suivre la mise en place du SI, en faire la recette et gérer les anomalies et évolutions en relation avec un intégrateur. C'était une activité difficile d'autant plus que le SI était composé de sous-systèmes qui n'avaient jamais été intégrés ensemble d'où de fréquents problèmes d'interfaces. Ce SI était composé d'un CRM, d'un système de provisionning et d'activation, de deux plateformes de médiation (Active et Passive), d'un système de valorisation et de Billing. Tout ceci est classique pour un SI d'opérateur Telecom, seulement l'intégration avait été difficile.

Les vrais problèmes avaient commencé après les installations et paramétrages c'est à dire après le lancement, sur la gestion des bugs car il y en avait beaucoup. Plusieurs fonctionnalités importantes ne marchaient pas. On ne pouvait pas par exemple faire les opérations de changement de SIM ou même de MSISDN. En plus, une fois qu'un client a choisi une offre il ne pourra plus la changer car les changements d'offre n'étaient pas possibles ni en montée ni en descente de gamme. Ce SI était vraiment une catastrophe informatique. Lorsqu'on lance une opération il faut croiser les doigts pour qu'elle arrive à terme.

Vous comprenez bien que j'étais dans une situation difficile en face d'utilisateurs loin d'être satisfaits et d'un intégrateur peu réactif. Chaque jour nous découvrions de nouvelles anomalies et je les reportais via notre process de gestion d'anomalies. Je m'assurais que toutes les anomalies étaient tracées et prises en compte. Je passais des heures au téléphone avec le chef de projet MOE à décrire les anomalies et à négocier des dates de livraison de correctifs et/ou évolutions.

Quand j'ai la chance d'avoir une nouvelle livraison la recette sortait d'autres nouvelles anomalies, des régressions. Je passais des journées très stressantes à contourner les anomalies surtout concernant les opérations quotidiennes sur le CRM, le Bus, la médiation, etc. Et quand arrive la fin du mois il faut veiller des nuits entières pour corriger les factures, passer des journées entières pour les imprimer. Chaque cycle de facturation était un calvaire. Pour couronner le tout le GPRS/EDGE n'était pas facturé parce que l'interface entre le GGSN et la plateforme de médiation active n'était pas fonctionnelle. J’avais réuni une grosse équipe d'experts et on passait plusieurs heures de conférence téléphonique pour tenter de résoudre le problème. Il faut dire qu'avec ce SI chaque semaine j'avais une nouvelle livraison soit pour corriger des anomalies soit pour apporter une évolution pour permettre une fonctionnalité prévue dans le document d'architecture fonctionnelle mais qui n'a jamais marché. De livraison en livraison on était arrivé la trentième version du CRM pou avoir un minimum de confort dans l’usage. Mes clients internes avaient commencé à desserrer les mines, ils avaient de plus en plus confiance à ce SI et nous avons même été retenus pour un prix SI du groupe. Aujourd’hui je regarde ces temps passés sur ce SI avec beaucoup de fierté et de réjouissance. Depuis, je suis passé à autre chose: L'automatisation des processus métier et la gestion des projets de services à valeur ajoutee.

Gestion du relationnel pour les responsables Informatiques

Lorsqu'on se trouve en tête d'une cellule informatique la gestion du relationnel est très importante car elle influence en grande partie l'atteinte des objectifs de la cellule. Le responsable informatique est souvent en relation avec trois catégories de personnes en l'occurrence les clients internes de l'entreprise, les fournisseurs et ses propres collaborateurs.
Les clients internes attendent du service informatique que celui-ci l'aide dans l'atteinte des objectifs de l'entreprise en leur mettant à disposition des moyens de communication adéquats, des matériels et logiciels fonctionellement adaptés à leurs besoins et surtout un support technique réactif.
Le client interne tout comme le client externe a aussi ses caprices qu'il faut savoir gérer à travers une communication sereine et rassurante, des procédures claires et compréhensibles d'accès aux services informatiques. C'est dans l'objectif de satisfaire ses clients internes que le responsable informatique fait appel à des fournisseurs externes pour la fourniture de matériels, logiciels et services. Face à ces fournisseurs le R(S)I exprime ses besoins et garantit les plannings de livraison en gardant toujours à l'esprit un rapport qualité/prix intéressant. Pour ce faire il doit donc avoir de bonnes capacités de négociation et un bon réseau professionnel pour l'aider dans le choix.
Pour atteindre ses objectifs le R(S)I doit surtout s'appuyer sur ses collaborateurs. Pour la réussite de cette relation, le R(S)I doit se conduire en bon manager. La motivation des collaborateurs, leur adhésion au projet, leur responsabilisation ainsi qu'un climat de confiance mutuelle permettent au R(S)I d'assurer une bonne relation avec ses collaborateurs.
Le R(S)I étant un acteur important dans la réalisation des objectifs communs à toute l'entreprise, il est important qu'il aie un relationnel facile qui s'inscrive dans ce sens.