Machine à café

Une vision partagée de l’objectif

, , , ,

Prise en charge de projets à la machine à café

Le DSI d’une société est à la machine à café de l’entreprise. Le responsable logistique arrive à son tour.

Machine à café

Machine à café

Le responsable logistique : « Salut ! Ca tombe bien que tu sois là, il fallait que je te vois.

La direction logistique a décidé d’appliquer une stratégie de magasin interne à l’entrepôt sur son process de picking pour regrouper les produits a forte rotation et réduire les déplacements. Pour les commandes relatives à d’autres produits, ils veulent procéder à du picking en commandes groupées.

Est-ce possible de ton côté de faire le nécessaire au niveau informatique pour que ces changements soient faits au plus vite ? »

Le DSI : « Salut ! Passer à du picking en commande groupées ? Ca devrait pas être grand chose à faire puisque dans l’ERP les processus sont déjà organisés pour une gestion en picking. Cette semaine ca ne sera pas possible car on doit livrer un dossier pour les Finances, mais on devrait pouvoir s’en occuper la semaine prochaine. »

Le responsable logistique : « Super ! Je compte sur toi pour que cela soit opérationnel fin de semaine prochaine. »

Toute ressemblance avec des personnes ou situations …

Bien entendu, les personnages et les situations de ce récit étant purement fictifs, toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite.  ;-)

Avec un peu de recul sur la scène, nous nous demandons ce que le DSI va bien pouvoir fournir comme livrable au responsable logistique dans deux semaines…

Les interrogations ou déductions que la scène soulèvent :

1) Le DSI doit probablement être un expert es-logistique puisqu’il n’a posé aucune question complémentaire à son interlocuteur.

2) Le DSI doit avoir une parfaite connaissance de la modélisation des processus Logistique dans l’ERP pour évaluer de manière mentale la complexité des modifications induites par la demande du service Logistique.

3) Le DSI doit suivre de près le projet Finances et est optimiste sur la Qualité de la réalisation car à l’en croire, dès le lendemain de la livraison au service Finances, l’équipe sera totalement disponible pour passer au sujet Logistique.

4) Le DSI doit avoir une visibilité très claire et précise du PMO IT puisqu’il est capable d’évaluer les charges et capacité de son équipe pour s’engager sur un planning de mise en oeuvre

5) Tout laisse penser que le DSI n’a entendu et pris en compte que la dernière partie de la demande, mais le responsable logistique lui fait confiance sur sa capacité à fournir une réponse sur tout le périmètre visiblement.

6) Le responsable logistique conclue, à partir de spéculations, que la livraison est annoncée pour la semaine prochaine.

7) Le DSI doit repartir de la machine à café fier et satisfait d’avoir démontré son professionnalisme avec des réponses spontanées et de bénéficier ainsi du respect et de la confiance du responsable logistique.

etc, etc

Avec un peu de recul sur la scène, celle-ci est-elle vraiment très éloignée de la réalité « terrain » des projets ?

Là ou l’intérêt des deux parties serait d’avoir une vision partagée de l’objectif pour en garantir l’atteinte, ces dernières se contentent d’une cible floue entourée de déductions implicites non validées.

L’absence d’une vision partagée de l’objectif est l’une des causes principales des difficultés rencontrées dans les projets puisque dès le départ, les moyens à associer à l’atteinte de l’objectif sont erronés.

De plus, avec une simple vue « de la partie émergée de l’iceberg », les chances de livrer un produit en adéquation avec le besoin sont donc très faibles.

Par contre les impacts de « service après-vente » eux sont colossaux puisque qu’il faudra bien finir par aligner le projet technique avec les attentes fonctionnelles… coûte que coûte, dans l’effort et l’urgence, en surcharge de tous les autres projets en cours.

Comment inverser ces habitudes et amener les deux parties à une vision partagée de l’objectif ?

Dans un processus normalisé, c’est au maître d’ouvrage de formaliser et rédiger son besoin au sein d’un cahier des charges.

Or cette étape essentielle de formalisation est trop souvent négligée et les cahiers des charges, lorsqu’ils existent, sont réduits à une ou quelques pages A4 rédigées sur un coin de table.

Ce document étant indispensable au services ETUDES et PMO de la DSI pour évaluer sereinement le périmètre du projet, définir les processus de réalisation, budgets, durées, impacts et risques pour garantir l’atteinte de l’objectif, nous recommandons que  la rédaction du cahier des charges soit fait par la DSI à partir de ce qu’elle a cru comprendre de l’expression du besoin par le Métier.

La fiche Projet

Les spécifications fonctionnelles sont alors formalisées au sein d’un document de référence : la fiche projet disponible en téléchargement.

Ce document est issu du framework méthodologique Ankaa Engineering et défini dans la phase « Initiative » pour le sujet « Scope »

Ce document, associé à la gestion de projet, est complété au fur et à mesure de l’avancement et contient l’ensemble des données (directes ou sous forme de liens) liées à la vie du projet. L’ensemble des acteurs du projet y ont accès.

Bien entendu, à l’étape d’expression du besoin, seul le chapitre OBJECTIF, PERIMETRE ET NATURE DU PROJET seront complétés par le chef de projet fonctionnel de la DSI et soumis à relecture auprès de l’émetteur de la demande Métier.

Après quelques aller-retours inévitables, l’émetteur confirmera que le besoin a parfaitement été entendu et compris et que les deux parties MOA et MOE ont enfin une vision partagée de l’objectif.

Le fait que la fiche projet intègre la formalisation d’une vision partagée de l’objectif va d’une part faciliter la recette du projet.

Enfin et surtout, la fiche va surtout protéger le chef de projet et son équipe des incontournables demandes d’ajouts ou adaptations en cours de réalisation, les fameuses intervention de la MOA « pendant que tu es dessus, cela serait bien d’ajouter… »,  dans lesquels le sous-entendu à entendre est « puisque cela ne nous coûte rien ».

Durant les phases de réalisation, grâce à la fiche projet, chaque demande hors scope initial formalisé, fait l’objet d’une analyse d’impact et demande une révision (selon les cas) des paramètres budget et délai du projet.

Le versionning du projet est dans tous les cas facilité.

Une fois l’objectif clarifié, la fiche projet sera alors reprise par le service Etude de la DSI qui définira dans un second temps les moyens matériels et humains à affecter à l’atteinte de l’objectif, la durée de réalisation, la gestion des risques associés à la réalisation, et évaluera le coût total de possession (TCO) associé au projet.

Avec ce rapport d’étude en main, le demandeur n’aura plus qu’à aller négocier auprès de la direction générale ou financière les moyens  nécessaires à la réalisation de son projet métier…car effectivement, petit rappel s’il en est besoin, c’est bien dans le périmètre de la MOA de garantir le sponsoring des projets.

/par

Why Test Automation Is Important for Agile Data Teams: An Interview with Cher Fox

, ,

Josiah Renaudin: Welcome back to another TechWell interview. Today I’m joined by Cher Fox, of Fox Consulting. She’ll be leading a session at this year’s STARWEST about test automation for data-centric applications.

Cher, thank you very much for joining us. First, could you tell us a bit about your experience in the industry?

Cher Fox: I have over thirty years of experience in the information technology industry, including twenty years of partnering with clients on their data-centric development projects as an independent consultant. My experience has evolved from data analysis, help desk support, network infrastructure, programming, software development, testing, technical writing, and training to business analysis, business intelligence architecture, data modeling/mapping/ETL, data warehouse design/development, and process improvement.

Josiah Renaudin: Why do you think so few data-centric testing tools are targeted to data-related development and testing?

Cher Fox: Data-related development is proprietary per industry and product. With so many different development languages and methodologies, it is very challenging to develop a specific tool to meet so many needs. The few tools that exist reside embedded in a suite that includes design, development, and testing specific to the suite’s workflow.

Josiah Renaudin: Is there an ideal ratio between manual and automated testing, or does it entirely depend on the type of team or project being worked on?

Cher Fox: The ideal ratio between manual and automated testing would completely depend upon the team and project being worked. The development methodology would factor in heavily here, test or behavior driven development would lead to a much higher ratio of automated testing. A team’s maturity, skill set, and project management style would also contribute to the ratio of manual versus automated testing.

Josiah Renaudin: Can you succeed in our modern, agile software era without any test automation?

Cher Fox: Surely a project can succeed without any test automation, but not at the fast pace of today’s modern, agile era. Smaller increments of developed product demand automated testing for the most optimal speed of delivery and regression testing safety.

Josiah Renaudin: Have you worked with a lot of more traditional testers who are nervous that they’re going to be phased out as the industry continues to evolve?

Cher Fox: Any smart resource in any industry should be paying attention to their industry’s evolution and pacing their growth and development appropriately to remain marketable and competitive.

Josiah Renaudin: Why aren’t agile data teams automating their tests as much as they should? What are some general steps they can take today to head toward smart automation?

Cher Fox: This session will explore many reasons why agile data team aren’t automating their tests. Attendees will leave with suggested areas to explore and improve upon within their internal environment before looking to external resources to implement automated testing.

Josiah Renaudin: How can teams use tools they already have to automate data-centric apps?

Cher Fox: This session will explore and demonstrate how teams can use their existing tools to begin automating the testing of their data-centric applications. Attendees will leave with a framework to use tools they may already have to get started.

Josiah Renaudin: More than anything, what central message would you like to leave with those who attend your session?

Cher Fox: Many attendees will come to the session with the idea that the lack of an automated testing tool is the roadblock to their environment’s successful test automation implementation. While this is a contributing factor, there are many other items to consider and address before implementing test automation. Attendees will leave this session with areas to review in their agile environment in preparation to implement test automation. They will also leave with a framework to build using their existing tools once they are ready to begin.

Cher FoxCher Fox (@TheDatanista) brings thirty years of experience as a solution architect, developer, tester, and analyst for business intelligence, data warehouse, and software development industries. Her experience includes more than twenty-five years of training corporate users on IT applications and business processes. A board member for the Colorado Chapter of TDWI (The Data Warehouse Institute), Cher is active in the SQL community, collaborating at local SQL Saturdays, SQL Server and Power BI user groups, PASS Summits, and BA conferences. Cher enjoys sharing her expertise via local, national, and international speaking engagements. Reach Cher at cfox@FoxConsulting.co, Fox Consulting, and at LinkedIn.

By AgileConnection Source : http://ift.tt/2fwGEk9

/par

Open Data : bientôt un « administrateur des données » dans chaque ministère ?

, ,

 

Si certains ministères se sont officiellement dotés d’un « administrateur des données », cette nouvelle fonction demeure encore très hétérogène et surtout informelle. L’Administrateur général des données, Henri Verdier, entend ainsi demander au Premier ministre d’instaurer un réseau plus clairement défini.

Ils sont parfois appelés « superviseur général des données », « administratrice des données » ou « administrateur général des données »… Ces agents de l’État exercent leurs fonctions de manière bien souvent informelle, et dans certains cas en complément à d’autres missions. Mais tous ont un point en commun : ils servent de relais, au sein des ministères ou directions auxquels ils appartiennent, à l’Administrateur général des données, Henri Verdier.

Avec pour objectif de participer à une meilleure ouverture des données que leurs administrations respectives détiennent, ainsi qu’à une plus grande valorisation de celles-ci. Cela peut aller de l’emblématique ouverture du code source du logiciel de calcul de l’impôt sur le revenu à d’autres projets de réutilisation plus concrets pour le grand public, à l’image du futur portail relatif aux données de transport « transport.data.gouv.fr ».

Un réseau qui se constitue progressivement

By Next INpact – Actualités Source : http://ift.tt/2fvmHKv

/par

Piloter un projet metier avec une communication efficiente

Ou la nécessité d’imposer un rythme et de donner du feed-back

Contexte

Pour un groupe français de l’aéronautique, leader mondial de son secteur, et pourtant… il a fallu récupérer un projet voué à l’échec ; projet dédié à la construction d’une plateforme pluridisciplinaire regroupant les métiers des Achats-Qualité-Technique-Performance Fournisseurs.

Le motif de cette situation… un problème de relations humaines, de communication et de cadrage de ce projet métier. Démarré il y a un (1) an, le projet bloquait depuis six (6) mois. Des tensions naissaient entre les équipes dans la vie de tous les jours. A l’origine, le projet avait révélé un réel engouement de la part des équipes pluridisciplinaires concernées. Le statu quo du projet minait donc l’ambiance générale de travail.

Actions

Une fois repris en main, c’est-à-dire :

  • des réunions d’avancement rythmées à la semaine ;
  • des actions clairement définies, attribuées à chacun et limitées dans le temps ;
  • une redescente régulière de l’information effectuée par le Chef de projet et sur les différents sujets du projet ;
  • un retour d’avancement régulier et communiqué plus largement, vers les équipes transverses notamment, afin de lever les freins puis de temporiser les esprits ;
  • une présence, un soutien, une disponibilité assurée par le Chef de projet envers l’équipe projet ;

… le projet fut remis sur les rails en un mois et demi (1,5) (4 COPRJ et quelques actions parallèles, entrecoupées d’autres activités liées la fonction initiale du Chef de projet).

Résultat

Le « GO » pour la mise en place (dixit la phase de Démarrage lors d’un projet SI) a été prononcé. Le Chef de projet a transmis le relais à la maîtrise d’œuvre, en maintenant une surveillance d’adéquation à ce que validé fonctionnellement et prototypé techniquement. Un (1) mois plus tard le plateau était construit et les équipes pluridisciplinaires installées.

Entre temps, les équipes transverses et les Interlocuteurs du projet avaient retrouvé le sourire. La motivation était revenue et l’ambiance de travail s’était améliorée.

Leadership

Leçon à retenir

  • Instaurer, au sein de l’équipe projet, un relationnel fondé sur l’écoute, l’équité, la transparence, la réactivité.
  • S’attacher à donner le même niveau d’information à tous, et surveiller que chacun de l’équipe projet se situe au même niveau d’information.
  • Donner de l’information et des feed-back jusqu’aux équipes transverses au projet. Ca a l’intérêt de rassurer et de rendre palpable le projet, et par conséquent de s’accompagner de « porteurs au projet ».
  • Autant que possible… Nommer à la tête de vos projets (projets métiers tout particulièrement, au vu des contextes inhérents) une personne à la communication efficiente, qui s’inscrit dans le partage et la conciliation, ouverte d’esprit, créative, adaptable, dégageant éthique et conviction voire de la passion… un Leader !

 

Sandrine
Consultante Ankaa Engineering®
Professionnelle de 20 ans en Management de la fonction Achat et en Conseil organisationnel et de transformation, Sandrine a travaillé au sein d’environnements multiculturels, aux côtés d’équipes pluridisciplinaires.
Elle a exercé aussi bien auprès de grands Groupes que de PME-PMI, lui permettant ainsi d’approcher des problématiques différentes, des modes de fonctionnement hétérogènes, des circuits de décisions variés, des priorités et enjeux originaux.
Le parcours à dominante industrielle de Sandrine, lui a donné la possibilité de développer certaines compétences dont quelques-unes la distinguent ; telles qu’une double compétence métier, une bonne capacité d’adaptation, un fort sens du résultat et du service, une grande pratique de méthodes et outils métiers.
Ses domaines de prédilection :

  • Strategies achats – Optimisation de processus – Organisation – Methode
  • Sourcing, negociation, contractualisation
  • Pilotage de projets et changements – Evaluation sous KPI
  • Perimetres internationaux, Gestion simultanee, Management transverse
/par

A quand une gestion de projet transversale en entreprise ?

, ,

Lors de nos prestations en entreprise, nous constatons très régulièrement le même schéma d’organisation :

  • Le bureau d’étude à mis en place intra-muros une organisation de stockage et de partage des données
  • Le service informatique utilise des logiciels divers et variés pour le suivi de leurs déploiements
  • Tel ou tel service à formalisé ses processus, bien souvent sous la contrainte d’ISO
  • Chaque service gère son activité dans l’indifférence des modèles d’organisation des voisins
  • Les métiers regardent l’initiative de méthodologie du service IT comme s’ils n’étaient pas concernés
  • Etc, etc.

Et chacun travaille en silot !

Silots et gestion de projet transversale

La faute à qui ?

  • Probablement à la productivité à fournir qui fait que chacun avance « la tête dans le guidon »
  • Probablement aux métiers qui ne considèrent que trop rarement les impacts de leurs changements sur le monde qui les entourent
  • Probablement à la direction générale qui se concentre sur la stratégie commune au détriment de l’organisation commune

Alors à quand une gestion de projet transversale en entreprise ?

Très certainement lors de la création d’un « Bureau de gestion de projets » (PMO) général à l’entreprise.
Initiatives très marginales aujourd’hui, et pourtant tellement salvatrices de dysfonctionnements.
Imaginez un bureau fédérateur et garant d’une méthodologie transversale, avec qui plus est une visibilité sur les charges supportées par toutes les équipes !
Attention ! Pas d’amalgame avec les fonctions actuelles d’un service Qualité…on ne parle pas des mêmes objectifs.

Avec l’arrivée de l’informatique dans les années 70, sous le prétexte que cela faisait « ringuard », les informaticiens ont « virés » les panneau muraux avec leurs fiches cartonnées qui faisaient qu’à l’époque chaque manager savait qui faisait quoi quand.
Mais en face, aucune solution efficace n’a été proposée.
De fait, avec la perte de visibilité sur les capacités des équipes, le règne de la surcharge est apparu.
Le manager, sans outils de mesure, a alors tendance à surcharger ses équipes afin de se rassurer sur le fait de n’avoir personne payé à ne rien faire !

Ce qui provoque des effets de bord dévastateurs dans l’organisation de l’équipe, du service, de l’organisation de l’entreprise.

Alors à quand un PMO chez vous ?

La mise en oeuvre d’un « Bureau de gestion de projets » (PMO) apporte une cohérence dans l’organisation.
Mais attention de ne pas vouloir être plus royaliste que le roi en espérant de son PMO une gestion de planning à l’heure et de l’ordonnancement de tâches !
Avec la mise en oeuvre d’un PMO, il faut considérer une démarche d’amélioration Qualité graduelle et progressive.
Dans l’entreprise, toute mise en oeuvre brutale ne s’inscrit pas dans la durée et l’accompagnement au changement prend toute son importance dans une mise en oeuvre à impact transversal.
On se doit de respecter la logique de DEMING…

/par

Pourquoi se tirer une balle dans le pied en faisant de la compression de planning ?

,

Combien de Project Manager travaillent sur le prévisionnel de leur projet en essayant de réduire au maximum le temps de réalisation ?

Mais fondamentalement :
– un bon PM se reconnait-il à ses capacités de présentation d’un prévisionnel record ?
– les constats opérés « dans la vraie vie » ne démontrent-ils pas un retard systématique des projets ?
– les retards n’engendrent-ils pas au final une dégradation de la qualité du livrable ?
– la non qualité d’un projet n’amène-t-elle pas une charge supplémentaire de « SAV » non budgétée /non planifiée ?

Alors pourquoi persister à vouloir compresser le planning prévisionnel ?

Par crainte d’une baisse de la sacro-sainte « productivité » ?

Et pourtant, quels sont les phénomènes constatés dans les projets trop comprimés ?
– sous couvert d’une méthodologie de gestion de projet, les plannings sont revus quasi-quotidiennement pour resynchroniser les ressources sur les dérives constatées
– communication inexistante, tout le monde à la « tête dans le guidon », ce qui amène à une désynchronisation des actions de l’équipe
– Plan d’Assurance Qualité réduit à « peau de chagrin », contrôles et tests « passés aux oubliettes »
– documentations, guides, compte rendus, documents de spécification passés « à la trappe »
– ressources qui « voient le mur arriver » et se démobilisent du projet
– ressources surchargées et donc qui arbitrent leurs travaux quotidiens en choisissant ce qu’elles « aiment faire » au détriment de ce qu’elles « devraient faire »
– tensions relationnelles, pertes de crédibilité, pression croissante
– délais de livraison non respectés, ou respectés au détriment de la qualité
– budgets « explosés »
– etc etc

Une grosse pagaille en fait !

Se tirer une balle dans le pied

Alors…
– pourquoi chercher la compression de planning maximale,
– pourquoi faire abstraction de l’indisponibilité des ressources,
– pourquoi être autant optimisme quant aux risques potentiels,

Un mixte de besoin de reconnaissance et d’incapacité « à dire non » justifie ce scénario.
« Le N+1 impose les délais, les budgets et exige une qualité maximale, on a pas le choix… »
Notre compétence professionnelle nous alerte bien sur le fait que c’est une mission impossible, vouée à l’échec dans le périmètre attendu, mais… on ne dit rien, on n’ose pas, on ne se permet pas.
Pire, afin d’obtenir du N+1 une reconnaissance de ses compétences, on va travailler sur l’organisation prévisionnelle du projet en respectant les contraintes imposées par son chef.
Ceci en minimisant les moyens matériels, en faisant abstraction des capacités réelles de ressources, et en réduisant la potentialité et l’impact des risques.

Dans tous les cas, « l’omission de réserves » vis-à-vis du N+1 amène à un transfert de responsabilité et le projet devient « notre bébé », notre « patate chaude ».

Compte tenu de ce qui a été évoqué précédemment, durant la réalisation, bien entendu le projet sera une catastrophe.
Alors que le PM cherche à obtenir reconnaissance et respect de sa compétence, il obtient l’effet inverse.
Nous serons évalués par notre N+1 sur notre incapacité à assumer nos engagements !

Pourquoi faire de la compression prévisionnelle et ne pas se donner les moyens de réussir ?

La VRAIE compétence d’un PM  n’est-elle pas
– d’opérer une gestion de risque efficace
– de communiquer, coordonner, reporter
– de respecter la Qualité, les budget et le délai annoncé
Bref, d’assurer dans les phases de réalisation du projet le respect du prévisionnel

Alors pourquoi se tirer une balle dans le pied en acceptant « sans réserves » les missions casse-cou ?
Pourquoi ne pas se donner les moyens d’améliorer ses chances d’obtenir la reconnaissance tant attendue en négociant des moyens cohérents ?

/par

Logiciels pour chef de projet

, ,
Référencement de solutions logicielles de planification, de tracking de bugs et de temps, de collaboration et de suivi de projet.
Diagramme de Gantt
Je sais… vous vous dites…y’a même pas d’évaluation fonctionnelle, ni de spécifications techniques d’environnement cible !
Nous comprenons largement votre déception mais…les évaluer toutes et établir des grilles comparatives se révélerait un travail de titan !
Alors pas de favoritisme, classement alphabétique établi à partir du nom d’usage du produit et lien vers le site éditeur pour tous !
A noter que si vous contribuez à nous adresser vos remarques, analyses, appréciations personnelles sur les produits que vous avez expérimentés, cela pourrait amorcer le travail et peut être nous donner l’envie d’avancer dans ce sens lors de longues soirées d’hiver… Merci à vous.
Liste mise à jour régulièrement.
Logiciels pour le chef de projet :
/par

Pourquoi avoir une démarche SAM (Software Asset Management) ?

, , ,

Qu’est-ce que la SAM (Software Asset Management) ?

Sam, Software Asset Management ou en français, Gestion des Actifs Logiciels est la démarche correspondant à gérer le cycle de vie des logiciels déployés sur l’ensemble du Système d’Information.

Depuis 2012 la Gestion des Actifs Logiciels est encadrée par la norme Iso 19770-1 définissant des niveaux de maturité et proposant des phases d’implémentation.

Pourquoi mettre en place une démarche SAM ?

– Parce que ne pas en avoir, expose l’entreprise ou la collectivité aux risques suivants :

o Risque financier : En cas de non-conformité constatée, l’entité devra acheter les licences pour son usage actuel voire son usage passé.

o Risque Juridique : Les articles L331-1 du code civil et l335-4 du code pénal fixent les pénalités encourues en cas de condamnation pouvant aller jusqu’à 300000€ d’amende et 3 ans d’emprisonnement.

o Risque d’image : Une entreprise condamnée pour une mauvaise utilisation des licences s’expose à ces deux risques en termes d’image :

 Mise en cause de son intégrité par ses clients.

 Mise en cause de son honnêteté par ses fournisseurs.

o Risque Technique

Trois risques techniques majeurs peuvent être identifiés :

 Cessation de fonctionnement d’un logiciel soumis à clé d’activation par période .

 Impossibilité d’avoir l’assistance technique de l’éditeur en cas de dysfonctionnement.

 Impossibilité de déployer des correctifs de sécurité face à une faille de sécurité découverte et publiée.

 SAM Software Asset Management

– Parce qu’avoir une vraie démarche SAM permet :

o De gagner du temps de disponibilité des équipes internes lors des audits des éditeurs ou de la BSA (Business Software Alliance).

o De démontrer aux éditeurs que les licences sont vraiment gérées et donc de réduire la fréquence des audits.

o De connaître parfaitement son parc logiciel et d’être :

 En position de force pour négocier avec les éditeurs ou les revendeurs lors des achats ou renouvellement de licences.

 Sûr de ne pas acheter des licences dont on n’a pas besoin lors de nouveaux  projets ou du renouvellement de son parc matériel (serveurs ou postes de travail).

 Sûr de ne pas détenir des licences non utilisées et donc payer pour rien.

o De ne pas s’exposer aux risques cités précédemment.

En conclusion :

– Mettre en place une démarche SAM fait économiser de l’argent à l’entreprise ou à la collectivité sur un des postes budgétaires très importants du système d’information (20 à 40% du budget total de l’IT).

– Ne pas mettre en place une démarche SAM coûte cher à  une entreprise et peut potentiellement lui coûter encore plus cher.

 

Patrick
Consultant Ankaa Engineering®
Spécialiste sénior de la gestion des actifs des système d’information.
Processus ITIL, accompagnement SAM, gestion des configurations et des changements, administration des incidents ou problèmes.

 

Sources :
– Guides des licences logicielles, Raphaël COCHE et Teddy MONIN, éditions ENI.
– ITIL V3, Guide to Software Asset Management
– Software Asset Management, CIGREF octobre 2012
– Norme Iso 19770-1 : http://www.boutique.afnor.org/norme/nf-iso-cei-19770-1/technologies-de-l-information-gestion-des-actifs-logiciels-partie-1-procedes-et-evaluation-progressive-de-la-conformite/article/806119/fa169141
– Business Software Alliance: http://www.bsa.org/?sc_lang=fr-FR
/par

Lean Office pour gagner en efficacité

,

La DSI d’un Grand Groupe industriel devait se réapproprier ses objectifs, renouveler ses compétences, revaloriser son image, récupérer une crédibilité et la confiance des métiers (les Clients internes et Fournisseurs externes).
Dans le cadre de cette démarche, je suis intervenue auprès de son équipe pour définir et mettre place une méthodologie en pilotage de projet et conduite du changement, puis en fournir les outils métiers.

Il s’agissait d’outiller les Chefs de projets de façon professionnelle (« best practice ») et complète.

J’ai mené une première phase d’observation de l’équipe de Chefs de projets, de ses modes de fonctionnement, de sa charge de travail, des périmètres de ses projets, du type de sujets traités par ses projets.

Ensuite, je me suis attachée à collecter et étudier l’éventuel existant, au vu de quelques échos reçus par certains Chefs de projets.
En effet, un grand Cabinet de la place avait fourni une base de 130 documents ; documents et guide diffusés en masse sur l’intranet de l’entreprise.
Ce référentiel non personnalisé, pensé sur une base « standard », sans accompagnement, n’a donc pas obtenu d’adhésion.
Contenant et contenu donnaient lieu à une certaine répulsion des équipes dans leur exploitation opérationnelle.

un régime administratif du framework méthodologique serait judicieux

Framework méthodologique

 

En troisième lieu, je me suis appuyée sur mes propres livrables, éprouvés par les pilotages de projets antérieurs. Cela représente une approche de type knowledge management.

Après une analyse réalisée sur ces trois phases, j’ai fait le choix de sélectionner certains de mes livrables en propre, car ils trouvaient leur place ainsi. Puis, j’ai amélioré d’autres documents de mon référentiel ou ceux issus de la livraison initiale du Cabinet.
L’ensemble fut adapté aux observations et attentes notées en première étape, puis mis à disposition accompagné d’un bref guide d’utilisation (1 slide). Les modèles de livrables ont été marqués de signalétiques ludiques, pour permettre une appropriation rapide et simple.

Le bénéfice tiré… les métiers ont pu exprimer leur besoin en systèmes d’informations corporate ou dédiés métier, d’une façon assez professionnelle pour permettre à la DSI de traiter correctement les demandes des Clients internes.
Les Chefs de projets ont rapidement pris possession des modèles pour les exploiter.

Lean Office et rendu assez pragmatique, qui a réduit le référentiel projet de 130 à 30 modèles de livrables.

L’optimisation de la démarche est apparue sous la forme de :

  • une préconisation d’axes d’améliorations, transmis à la DSI centrale sur les documents qu’elle détenait en termes de pilotage d’un projet et d’une conduite du changement.
  • un coaching des Chefs de projets, au comportement à adopter en cas de difficultés et dérives. Cette sensibilisation a fait l’objet d’un support sous la formalisation d’un guide, reprenant une approche Lean Office adaptée, et une liste de livrables structurée selon les étapes et phases d’un projet, suivie d’un Glossaire des signalétiques utilisées.

A retenir…

Dans le monde technique des « système d’information », il est recommandé de respecter les « standards » pour des raisons principalement de coûts et de maintenabilité.
Lorsqu’on aborde les processus et les modes de fonctionnement, il est nécessaire de répondre de façon personnalisée et pragmatique avec une touche de créativité.
Ainsi,

  • l’adhésion est plus facilement obtenue ;
  • il est plus aisé d’emmener tout le monde vers l’objectif ;
  • les gains sont réels ;
  • l’existant est optimisé.

Pour ce faire, le diagnostic « terrain » (en rappel au « Gemba » – méthode TPS) et préalable couvre une étape importante.

Copier-coller l’intégralité d’un framework méthodologique n’est pas gage d’efficacité.
Ecoute, adaptation et personnalisation : les composants d’une mission de conseil réussie…

 

Sandrine
Consultante Ankaa Engineering®
Professionnelle de 20 ans en Management de la fonction Achat et en Conseil organisationnel et de transformation, Sandrine a travaillé au sein d’environnements multiculturels, aux côtés d’équipes pluridisciplinaires.
Elle a exercé aussi bien auprès de grands Groupes que de PME-PMI, lui permettant ainsi d’approcher des problématiques différentes, des modes de fonctionnement hétérogènes, des circuits de décisions variés, des priorités et enjeux originaux.
Le parcours à dominante industrielle de Sandrine, lui a donné la possibilité de développer certaines compétences dont quelques-unes la distinguent ; telles qu’une double compétence métier, une bonne capacité d’adaptation, un fort sens du résultat et du service, une grande pratique de méthodes et outils métiers.
Ses domaines de prédilection :

  • Strategies achats – Optimisation de processus – Organisation – Methode
  • Sourcing, negociation, contractualisation
  • Pilotage de projets et changements – Evaluation sous KPI
  • Perimetres internationaux, Gestion simultanee, Management transverse
/par

Projets en retard = mauvaises évaluations de charge ?

, ,

Et si les mauvaises évaluations de charge n’étaient pas la seule cause des projets en retard ???

Pour qui veut apprendre comment évaluer des charges d’un projet, les supports ne manquent pas : Méthodes des points de fonctions, COCOMO, RAD, DELPHI, STIMA, ARAMIS, ESI, PRT, etc…

On se retrouve dans certains cas rapidement confronté à des méthodes conçues par des mathématiciens en mal de reconnaissance…LOL

Il existe bien sûr des quotas moyens qui ressortent à l’usage, et  pour certains référentiels, la répartition des charges entre les étapes d’un projet se présente selon :

Etude de faisabilité : 15%
Etude détaillée : 25%
Conception : 45%
Mise en production : 15%

Ces rapports peuvent varier selon les projets bien sûr.
Certains projets seront plus consommateurs de temps d’étude et moins en réalisation par exemple.
La matrice n’est donc pas aussi simple.

Charge, durée, délai ?

La notion de charge est la quantité de travail à produire et elle se traduit en nombre de jours/homme dans le contexte de projet d’ingénierie.
Le nombre de ressources affectées à produire le travail attendu influera (ou pas) sur le temps de réalisation et fournira la notion de durée.
Quant au délai, il correspond lui à la date de fin de réalisation (ou de livraison) et est directement dépendant des disponibilités des ressources pour accomplir le travail attendu.

75% des projets dépassent le délai de 30%.

Et très souvent, trop souvent, la cause annoncée de ce retard est une mauvaise estimation des charges.

Après 28 années de recul en gestion de projet de tout type et toute taille, le constat que j’ai opéré est que les projets en retard le sont bien souvent pour une autre raison qu’une mauvaise évaluation de charge.

En effet, un temps certain est passé sur l’évaluation des charges par les équipes, les chefs de projet, la maîtrise d’ouvrage.
Les charges sont même très souvent à l’origine de négociations et de discussions.
Bref les charges retiennent toute l’attention qu’elles méritent.

Mais quid de la capacité des ressources ???

Là, je ne sais pas pourquoi, même dans les projets avec des équipes non dédiées, le raccourci d’une affectation de ressources à temps plein est très très très souvent pris.
Or dans la vraie vie, les membres d’une équipe sont très rarement mobilisés 100% de leur temps sur le projet.
Plein de tâches parasites viennent grignoter leur capacité d’affectation (autres projets, autres projets en retard, maintenance, support, études, vacances, etc).
Leur capacité d’affectation est inférieure à du temps plein, voir largement inférieure.

Petit rappel de calcul simple :
1 jour de charge attribué à une ressource affectée à 100% de son temps demandera 1 jour de durée pour être réalisé.
1 jour de charge attribué à une ressource affectée à 50% demandera 2 jours de durée
1 jour de charge attribué à une ressource affectée à 25% demandera… 4 jours de durée

L’impact de la disponibilité des ressources n’est pas neutre puisque les coefficients sont significatifs.
Un projet réalisé avec des ressources d’une disponibilité réelle de 25% mettra 4 fois de temps à être réalisé que ce qui a été imaginé sur la base d’une affectation temps plein !

Alors une charge de travail parfaitement estimée à l’aide de toute les méthodes scientifiques du monde ne garantira pas la maîtrise du délai (et donc des coûts associés) si l’on ne met pas en face des capacités très clairement évaluées elles aussi.

C’est juste une histoire de contenant et de contenu.

Le problème est :
– qu’avec l’arrivée de l’informatique, les panneaux muraux et les fiches cartonnées des chefs d’équipe d’antan ont disparus.
– que les PMO (bureaux de planification des travaux) sont plutôt rarissimes dans les organisations.
– que compte tenu des deux points précédents, personne ne sait plus qui fait quoi quand et que de fait la surcharge règne (le règne des surbookés ?).

La solution :
– évaluer au cas par cas des projets les capacités des équipes/ressources impactées pour mesurer le coefficient de disponibilité et identifier de manière réaliste les délais jouables.
– réinstaurer les fonctions de PMO au sein des équipes.
– responsabiliser les équipes sur leur propre gestion de disponibilité et donc les autoriser à négocier/refuser des missions et travaux lorsque ceux-ci sont en conflit avec leur capacité…Oups !

Oups ! car dans ce cas, on met les pieds dans le plat d’un changement culturel d’entreprise ou le système hiérarchique historique risque d’être bousculé avec tous les problèmes d’ego que cela peut induire pour l’équipe d’encadrement de l’organisation .

Management transverse…A grands maux, grands remèdes ?

/par