Meilleurs voeux

Toute l’équipe vous souhaite une très belle année 2018.
Que cette nouvelle année vous apporte santé, bonheur et prospérité.
Nous vous remercions pour cette magnifique année 2017 et,
nous continuerons, en 2018, de contribuer à vos succès au côté de vos équipes.

_

Architectures de la transformation digitale

La transformation digitale est évoquée partout, dans tous les posts, dans toutes les offres, partout foisonnent les articles pour expliquer que l’usine du futur est l’enjeu de l’industrie, que la transformation digitale se niche dans toutes les activités de l’entreprise et que les technologies sont aujourd’hui disponibles pour tout type d’innovation.
On peut se demander s’il n’y a pas confusion entre moyens et objectifs.

Nous pensons que la transformation digitale doit s’inscrire sous un angle un peu plus pragmatique :

  • Quel est l’enjeu business et le modèle économique justifiant d’un besoin de transformation ?
  • Comment mon système d’information peut-il absorber facilement une accélération digitale ?
  • Quel modèle de service permettant à mes équipes d’instancier cette transformation ?

La question fondatrice sera traitée dans un article ultérieur : Le modèle économique de la transformation digitale. Retenons simplement qu’un projet de transformation ne repose pas sur un besoin technologique mais sur un enjeu business pour l’entreprise. Le système d’information doit apporter les moyens nécessaires et suffisants pour faciliter cette transformation.

Nous allons partir sur un cas fictif démontrant l’intérêt d’intégrer dans son organisation et son système d’information quelques basiques permettant cette transformation. Pour cela, il nous faut un cas d’étude que je vais vous présenter brièvement et que nous amenderons au fil des articles.

Nous avons retenu deux sociétés en phase de fusion dans notre exemple :

La société ClouDigit

Elle est leader de son marché dans la fabrication et la commercialisation de clou.
Elle s’appuie sur :

  • Un réseau de 200 magasins s’adressant aux professionnels et aux particuliers ;
  • Une cellule « grands comptes» adressant les clients B2B ;
  • Un entrepôt spécialisé :
    • Dans la préparation et l’envoi des commandes des clients du service « grands comptes » ;
    • Le réassortiment des stocks des magasins.

Cette entreprise n’a pour l’instant pas de site e-commerce mais uniquement un site institutionnel. Les relations « grands comptes » se font via une passerelle EDI.
Son système d’information est composé de 4 briques applicatives distinctes :

  • Un ERP du marché : centralisation des ordres, facturation, gestion client, compta ;
  • Un OMS (Order management system) développé en interne : workflow de fabrication, préparation de livraison, livraison, réapprovisionnement, stocks ;
  • Une solution BI du marché : suite BI, d’analyse statistiques ;
  • Un ETL open source.

Pour faire communiquer ces 4 briques les magasins de la société ClouDigit disposent :

  • De caisses enregistreuses « intelligentes » permettant de mettre à jour leurs stocks directement sur le système central ;
  • D’un Extranet permettant la mise à jour manuelle des stocks et des demandes de réapprovisionnement ;
  • D’un fax.

Schématiquement son organisation IT peut être résumée ainsi :

 

La société Clou.net

Cette structure est leader de la commercialisation de clou sur internet.
Bien que son site permette aux professionnels d’acheter des clous, son business modèle est majoritairement composé de la commercialision auprès des particuliers (B2C).
Elle s’appuie sur :

  • Un site web actif et bien référencé ;
  • Une base client et des campagnes marketing opérationnelles ;
  • Une structure de livraison de 4 personnes ;

Son système d’information est composé de 5 briques applicatives distinctes :

  • Un site web ;
  • Un ERP open source ;
  • Un gestionnaire de campagne marketing ;
  • Une application mobile sécurisée et dédiée à la structure de livraison :
    – Information et suivi des commandes à préparer ;
    – Envoi de sms au client quand la commande est en cours de transit (lien tracking de livraison) ;
    – Inventaire des stocks et émission automatique des demandes de réapprovisionnement auprès des fournisseurs.
  • Un ETL open source, pour faire communiquer les quatre autres briques.

Schématiquement son organisation IT peut être résumée ainsi :

 

Le Scénario

La société ClouDigit rachète le site clou.net

Le comité de direction prend les premières décisions suivantes :

A court terme

  • Supprimer la structure logistique de clou.net pour basculer la préparation et la livraison des commandes sur l’entrepôt ClouDigit ;
  • Généraliser l’usage de l’application mobile clou.net à la logistique client de ClouDigit ;
  • Les ventes du site clou.net devront pouvoir être analysées avec une solution BI ;
  • Le site web doit pouvoir proposer aux internautes un retrait boutique dans les 2 heures si les stocks de la boutique la plus proche le permettent.

A moyen terme

  • Utiliser la solution Marketing de « Clou.net » pour faire des campagnes marketing auprès des clients « grands comptes » de ClouDigit et idéalement des clients boutiques ;
  • Offrir aux clients « grands comptes » de ClouDigit  un accès sur clou.net pour pouvoir acheter directement sans intervention auprès du service « grands comptes » (Attention à l’encours client cependant) ;
  • Proposer aux clients du service « entreprise » un retrait boutique ;
  • Permettre l’utilisation des fonctionnalités « Inventaires » de l’apps clou.net pour les magasins.

A long terme

  • N’avoir qu’un seul ERP dans l’entreprise.

Nous faisons le choix de traiter dans un premier temps le sujet des architectures pouvant supporter ce type de transformation.
Vous pourrez, au travers des prochains articles identifier les modèles et méthodes permettant de supporter la transition d’un SI vers un autre.

LA méthode ?

Agile, cycle en V, altern, PMBOK, Prince2, ISO, ITIL, CMMi, Escm, Cobit…

Un constat : toutes sont valables et ont démontré leur performance. Le choix doit donc répondre non pas à la « popularité » de telle ou telle méthode. Il répond plutôt aux véritables besoins du projet, du chef de projet et de l’entreprise.
En quoi la solution retenue va-t-elle permettre à l’entreprise d’obtenir des services aux meilleurs niveaux de qualité ? Dans les délais et dans le budget ? Comment va-t-elle permettre au Chef de Projet de tenir ses engagements vis-à-vis de son comité de pilotage et de manager son équipe ?
En quoi, va-t-elle permettre au projet d’être réalisé dans la cible attendue en traitant les écarts et contrôlant les risques ?
Pour répondre à tout cela, la méthodologie doit posséder 3 qualités : adéquation, adhésion, atteinte du résultat.

Adéquation, Adhésion, Atteinte de résultat

Adéquation car cela reste un outil dont l’objectif est de délivrer un projet ou un service dans des délais, des coûts et un niveau de qualité prédéfinis.
Il faut donc savoir s’il s’agit de fournir un projet ou un service. Un projet est une fabrication unitaire dans un processus (idéalement) industriel. Alors qu’un service est une fabrication continue basée sur des automatismes industriels. Cette première dichotomie réalisée, il faut aussi replacer le projet ou le service au bon niveau de complexité et en connaître les enjeux. Quelle valeur va-t-on associer au produit fini ou au service ?Quel usage en fera-t-on et pour qui ?
Il faut noter ici l’évidence pour chacun de ne pas penser un seul instant appréhender de la même façon la fabrication de mouchoir en papier et celle d’un satellite. Et pourtant… n’a-t-on pas déjà vu des méthodologies d’une complexité lunaire pour déployer 200 postes de travail ?
Et des projets de refonte complet de l’entreprise décrit sur quelques pages… sur un coin de nappe ? Le choix sera donc là pour assurer la nécessaire adéquation entre la complexité et les enjeux du dossier.

Ce choix se fera sans se tromper de cible

Il n’y a pas de méthode pour les projets simples ou peu coûteux et une autre pour les projets complexes ou des services stratégiques. Une méthode est adaptée quand elle permet de décrire correctement les activités à produire, de suivre les activités et d’en piloter les risques. Elle doit porter en elle les moyens de la simplifier ou de la modifier pour s’adapter à l’équipe qui va l’utiliser.

On s’attachera donc à choisir une méthode adaptée au type de « production ». Unitaire, en lot, continue ou de masse, et à la cible du produit : utilitaire, de confort ou stratégique avec le niveau de retour sur investissement attendu. La méthode devra retenir notre attention dans sa capacité à se « simplifier » dans toutes les phases le nécessitant comme à se durcir là où se situe les risques ou enjeux majeurs du projet ou du service. Ici, nous serions en droit d’exiger une matrice d’aide au choix en fonction des critères ci-dessus. Et ce serait possible, s’il ne fallait tenir compte du deuxième paramètre : l’adhésion de l’équipe.

L’adhésion de l’équipe

En parlant d’équipe, sujet majeur chez Tribe IT, on parle de l’équipe en charge de l’opération. On parle donc de toutes les parties prenantes ayant pour objectif commun de faire aboutir ce projet ou service : les utilisateurs, les différents fournisseurs, le comité de pilotage et le chef de projet.
Il peut sembler tout à fait pertinent de déployer l’infogérance complète des serveurs et postes de travail d’une entreprise, dans le plus complet respect du référentiel ITIL. En veillant à s’appuyer sur un centre de services respectant les standards ISO27001 tout en garantissant un accueil utilisateur reposant sur la certification NF345.
Sauf si personne ne sait comment doivent être déployés ces services pour atteindre les niveaux de conformités décrits, qui en est réellement responsable et surtout quel est le véritable objectif à atteindre ? Est-ce parce que le centre de services d’un fournisseur (interne ou externe) est lui-même certifié ISOxxx ou NFyyy que le service à produire le sera ? Ou que le produit livré aura le niveau de qualité attendu ? Le fournisseur va vous apporter un gage de fiabilité de sa production, de respect des bonnes pratiques et la conformité à un référentiel normatif. Cela ne veut pas dire que votre projet atteindra naturellement l’objectif de l’entreprise.

La méthode ne va pas définir le résultat

Ce point est important dans le choix d’un référentiel comme d’une méthode de gestion : la méthode ne va pas définir le résultat. Malheureusement, la norme ou la méthode n’en garantira pas plus que l’équipe produira le résultat. Surtout si celle-ci confond finalement l’objectif de la méthode (appliquer/produire conformément à un référentiel structuré) avec ce qui est le seul enjeu d’un projet ou d’un service. Atteindre les objectifs de l’entreprise.
Ce manque de compréhension de l’équipe entraînant finalement souvent l’absence d’adhésion au projet. Problème qui sera aggravé par l’imposition d’une méthode ou d’un référentiel. Surtout si in fine, elle est elle-même mal comprise ou utilisée par les membres de l’équipe.

C’est pourquoi nous pensons qu’une étape est indispensable à la fois dans le choix de la méthode pour un projet et au plus tard au lancement du projet. Etape qui consiste à s’assurer de la complète compréhension par l’ensemble des acteurs à la fois des enjeux du projet pour l’entreprise. Et dans un second temps comment les activités et processus du projet vont permettre de répondre à ces enjeux.

Cette phase de « contrôle » doit servir de lieu pour définir concrètement et objectivement pour chacun les principes suivants :

  • Quel est l’objectif du projet pour l’Entreprise ?
  • Quels sont les bénéfices attendus ?
  • Comment seront mesurés ces bénéfices ?
  • Comment le projet/le service va-t-il être construit ?
  • Comment va-t-on mesurer chaque étape et s’assurer que l’objectif est atteint ?
  • Quelles sont les formules de calculs des KPIs ?
  • Quelles sont les critères utilisateurs d’acceptation du service délivré ou du projet ?
  • Quels sont les critères de risques et les modes de traitements de ces risques ?

Ces points, non exhaustifs, sont directement issus de la méthode retenue, elle-même choisie en fonction du projet et de l’équipe qui va réaliser le projet. Finalement, l’objectif est tout simplement que chaque acteur du projet puisse remplir son rôle et comprendre celui des autres acteurs du projet. Un acteur éclairé est certainement plus performant qu’un acteur obligé de subir sa mission. Et c’est certainement l’enjeu principal de cette phase d’adhésion. Adhésion et adéquation font ressortir 2 éléments importants :

  • Il n’y a pas de méthode adaptée à toutes les situations
  • Il n’y a pas de méthode adaptée à toutes les équipes

Il y a des méthodes pour certains types de projets ou services et des méthodes facilement partageable au sein d’une équipe. La bonne adéquation de la méthode au projet/service comme à l’équipe devrait en assurer une bonne utilisation et fédération de l’équipe dans sa mise en œuvre.

En quoi la méthode va permettre d’assurer la dernière partie : atteindre les objectifs du projet ou du service ?

Atteindre les objectifs du projet ou du service : Cette dernière partie devrait découler des précédentes. En effet, nous avons choisis une méthode adaptée au projet et à ses objectifs, partagée par l’ensemble de l’équipe et en ayant pris soin d’intégrer l’ensemble des objectifs du projet pour l’entreprise. Chacun sait ce qu’il a à faire, comment et pour quel résultat attendu. Il ne manque plus qu’un élément que doit apporter la méthode. Comment piloter les variations, prendre des décisions et gérer l’impondérable ?

La méthode doit donc apporter les éléments pour assurer le suivi, le contrôle et le traitement de ces opérations. Elle doit permettre d’organiser la gouvernance du projet. Elle apportera donc les éléments pour assurer la gestion des écarts, les demandes d’évolutions comme le pilotage des risques.
En réalité, la méthode doit (re ?)donner la part réelle de responsabilité et de décision du Comité de Pilotage et permettre au Chef de Projet de gérer son projet et son équipe. Une méthode correctement adaptée, à laquelle adhère l’équipe, a besoin d’un Chef de Projet. Il a pour rôle d’assurer le partage des outils, du savoir et du déroulement du projet avec l’ensemble des parties prenantes : direction et équipe projet (utilisateurs, équipe interne, fournisseurs).

Une méthode maîtrisée 

De ce fait, la méthode idéale est aussi celle que le Chef de Projet maîtrise pleinement. C’est celle qu’il a acquis, adapté, utilisé, affiné selon ses propres expériences et sa compréhension du projet. C’est donc la méthode qu’il est en mesure de partager avec son équipe dans son sens le plus large : représentant utilisateur, équipe interne, fournisseurs internes, fournisseurs externes. Il peut formaliser les différents jalons, décrire les indicateurs de mesures, expliquer la façon de les calculer et comment ils seront représentatifs du bon avancement du projet. Il personnalise et adapte les outils de suivi, reporting et pilotages issus de la méthode. Il saura construire et valider les critères de réception. Il saura former son équipe à « sa » méthode et en assurer l’animation tout au long du projet. La bonne méthode permettra l’atteinte du résultat si le chef de projet atteint le premier objectif : faire adhérer l’équipe et adapter la méthode aux enjeux du projet.

Des outils facilitant l’atteinte des objectifs d’un projet

Les méthodes comme PBOK, DSDM Altern , Prince2 ou les référentiels ITIL font parties des outils facilitant adéquation, adhésion et atteinte des objectifs d’un projet. Ils ne sont pas la condition nécessaire à la réussite d’un projet. Cependant s’ils sont utilisés avec le bon niveau de communication, par la définition d’une terminologie commune et la maîtrise des relations entre les parties, alors ils constituent un levier de réussite d’un projet. La méthode est une fondation indispensable à la réussite du projet. Le Chef de Projet en est le référant, l’utilisateur et l’animateur.

Chez Tribe IT nous considérons que la méthode est un élément de « langage ». Le Chef de Projet est celui qui en assure la diffusion et l’adhésion auprès de l’équipe projet (utilisateurs, fournisseurs et comité de pilotage).

Chiffrer un projet

chiffrer un projet article Tribe IT Estimer les coûts d’un projet…

Il y a quelques années estimer les coûts d’un projet faisait l’objet de la plus grande attention des clients comme des fournisseurs. Les méthodes de chiffrage étaient discutées et partagées par les « experts » comme une science à part entière.

De l’analyse mathématique (algorithmique) du bon chiffrage, nous sommes passés à l’ère du bon « devis ». Celui qui s’approche de ce qu’on est prêt à payer pour le service ou le projet attendu. Cette « méthode » a pourtant ses limites et, pour certains projets complexes, l’utilisation de quelques fondamentaux aidera celui qui doit piloter un budget :

 

 

 

 

 

 

  1. Choisir une méthode de calcul que l’on comprend, que l’on sait utiliser et qui est adaptée au type de projet à estimer. Cela semble évident, mais « les sachants » étant devenues rares… Il vaut mieux une méthode « simple » mais parfaitement maîtrisée que des approximations donnant des hypothèses erronées.
  2. Considérer que l’équipe affectée au projet ne travaillera pas à plein temps sur le projet. Tenir compte des absences, maladies et formations, des réunions et des congés.
  3. Prendre en compte les absences des utilisateurs, fournisseurs et autres décideurs entraînant des écarts dans le planning de réalisation.
  4. Tenir compte d’un facteur de perte de productivité pour les ressources mutualisées ou affectées en temps partiel sur le projet (temps perdu entre deux projets/activités différentes).
  5. Décomposer le projet en activités autonomes (Work Breakdown Structure) et estimer indépendamment chaque activité.
  6. Intégrer la charge de management de projet pour chaque activité.
  7. Ne pas faire d’estimation globale des risques mais estimer les risques de chaque activité.
  8. Faire estimer certaines activités par un expert du domaine.
  9. Savoir que les experts ont tendance à faire des chiffrages optimistes.
  10. Intégrer une part de variation de périmètre et des besoins des utilisateurs.
  11. Ne pas oublier d’intégrer les activités de tests, recettes et support au déploiement.
  12. Identifier pour chaque activité les prérequis et hypothèses associés au budget estimé.
  13. Additionner les coûts de toutes les ressources pour une activité donnée.
  14. Intégrer pour chaque étape du projet les activités de communication et de conduite du changement.
  15. Comptabiliser tous les coûts : locaux, postes de travail, serveurs, stockage, licences, support éditeur, exploitation des environnements projet, frais de déplacements, animation et motivation des équipes, …
  16. En cas de sous-traitance de tout ou partie du projet à un fournisseur externe : évaluer la fiabilité de son propre chiffrage…

La méthode de chiffrage, il n’y a pas de méthode « incontournable ».

Certaines méthodes sont suffisamment élaborées pour intégrer à la fois des métriques de références et des paramètres comme les coûts connexes. D’autres reposent sur les fonctions ou les usages comme sur le découpage au plus fin des tâches. Enfin, certaines proposent même de mixer l’ensemble de ces paramètres.

Ceci étant, et compte tenu de l’absence de maîtrise ou de diffusion de toutes ces méthodes, il faut envisager de se focaliser sur les plus faciles à appréhender :

  • Méthode des points de fonctions et ses dérivés (micro-points de fonctions, use case point). Il s’agit des méthodes s’appuyant sur l’évaluation des grandes fonctions d’un projet, les liens entre fonctions/objets et leurs complexités ;
  • Estimation par Analogie : S’appuyer sur l’historique de projets similaires pour évaluer les coûts ;
  • Découpage WBS et chiffrage d’un expert pour chaque activité ;
  • Consulter des fournisseurs et estimer le coût du projet en se basant sur l’explication des fournisseurs et la compréhension des chiffrages de chacun ;
  • Méthode des 3 estimations : Utiliser l’une ou un mixte des méthodes précédentes pour faire estimer le projet selon 3 hypothèses : basse, moyenne et haute (ou pessimiste, normale et optimiste).

On notera, notamment grâce à la dernière, qu’une bonne pratique peut consister à mixer plusieurs d’entre elles. Notamment pour s’approcher plus rapidement de ce que sera le bon budget.
Même si les méthodes telles Use Case ou Point de fonctions ont largement évolué et peuvent intégrer tous les facteurs autres qu’humains dans le projet, un chiffrage efficace doit rendre visible tous les coûts. Il est donc préférable d’estimer d’une part l’effort humain et ensuite d’intégrer l’ensemble des coûts connexes au projet.
Le chiffrage d’un projet est donc aussi une application d’un ensemble de bonnes pratiques. Ne pas oublier parmi ces bonnes pratiques d’établir le WBS du projet qui garantit d’avoir une vision la plus exhaustive des activités à estimer.