Nous vendons des trous, pas des perceuses !

Je suis tombé sur une expression intéressante récemment. Un vendeur de logiciels parlait de livrer l’intégralité de la solution à son client. « Nous ne vendons pas de forets. Nous vendons des trous », a-t-il dit. C’est une excellente analogie. Beaucoup de gens (moi inclus) sont allés à la quincaillerie et la vitrine dans le département des outils électriques tout en se demandant quel projet je pourrais peut-être penser de qui justifierait l’achat de ce grand outil de puissance. Mais l’application de cette logique a autant de sens dans le monde du do-it-yourself que dans les systèmes logiciels d’entreprise.

Si vous n’avez pas de problème, vous n’avez pas besoin d’une solution.

Tout comme personne ne devrait aller à la recherche d’une foreuse à moins que le problème qu’ils aimeraient résoudre est de faire un trou, personne ne devrait aller à la recherche de logiciels d’entreprise à moins qu’il ne résolve un problème. Maintenant, si vous rencontrez un problème de déploiement de logiciels d’entreprise, la prochaine chose à faire est que ce que vous achetez vous fournira la solution dont vous avez besoin. C’est souvent beaucoup plus que l’achat du logiciel.

Le déploiement d’un système d’entreprise est un défi complexe. Le gain doit donc en valoir la peine. Dans le monde actuel des équipes de projet mondiales, l’une des choses les plus courantes à faire est de partager l’énorme effort de déploiement d’un système d’entreprise. Bien que cela puisse nous donner des économies d’échelle en utilisant des équipes hautement formées dans leur aspect du projet, cela présente également le risque de négliger des aspects du projet de manière très risquée. Ce risque est aggravé plus les différentes équipes sont déconnectées physiquement et sur le plan organisationnel.

Examinons les éléments les plus courants d’un projet de systèmes d’entreprise.

Qu’est-ce qu’une entreprise ?

Tout d’abord, qu’est-ce que je veux dire par entreprise? Je vais prendre une définition qui devrait fonctionner pour presque tout le monde. « Entreprise », dans ce contexte, désigne tout projet qui aura un impact sur le fonctionnement de l’ensemble de l’organisation. Je dirai que c’est vrai pour n’importe quelle organisation. Les implémentations qui sont qualifiées d’implémentations d’entreprise ne concernent pas seulement le nombre d’utilisateurs, mais aussi l’impact qu’elles ont. Par conséquent, la mise à jour de notre logiciel d’analyse antivirus du fournisseur A au fournisseur B ne serait probablement pas éligible. L’implémentation d’un logiciel de planification de projet sur le bureau pour une poignée d’utilisateurs n’est probablement pas éligible. La centralisation de notre gestion de projet et l’utilisation d’un système de gestion de projet d’entreprise centralisé seraient probablement éligibles.

Donc, s’il s’agit d’un projet d’entreprise, quels sont les éléments les plus courants d’un déploiement d’un système d’entreprise ? Dans nos bureaux, l’expérience la plus courante consiste à déployer des systèmes de feuille de temps d’entreprise, tels que notre propre TimeControl, ou des systèmes de gestion de projets d’entreprise, comme Microsoft Project Server, mais ces éléments seront communs à presque toutes les implémentations de système d’entreprise.

Bits et octets

Commençons par aborder les composants les plus fondamentaux du logiciel : l’architecture technique. De nos jours, nous devons diviser notre réflexion en fonction de notre décision d’utiliser un déploiement local ou un abonnement dans le cloud. Je vais laisser les merveilles de choisir laquelle de ces conditions est le mieux dans quelles conditions pour un autre jour, mais voici quelques-unes des bases de ce que nous aurons à penser dans chaque catégorie.

Si nous utilisons une installation locale, nous devons réfléchir au matériel que nous allons utiliser. Quelle est la configuration matérielle requise pour la mémoire et les processeurs ? Allons-nous utiliser des serveurs physiques ou virtuels ? Allons-nous utiliser des serveurs dédiés ou partagés ? Quels types de serveurs peuvent être nécessaires ? Aurons-nous besoin de serveurs d’applications, de serveurs de sécurité, de serveurs web ? Qu’en est-il de l’équilibrage de charge, de la récupération d’urgence et des sauvegardes ? Aurons-nous besoin de serveurs de sauvegarde froids ou chauds ? Ouf! Mais on n’a pas fini ! Qu’en est-il de la base de données ? Quelles sont les conditions requises ? Qu’en est-il de la prise en charge de nos architectures existantes de sécurité, d’application et de base de données ? Qu’en est-il de la prise en charge des navigateurs, des versions de navigateur et des appareils mobiles ? Une fois que nous avons répondu à toutes ces questions, nous devons gérer les problèmes liés aux environnements d’installation, de test et de production, puis à l’intégrité et à la surveillance du système une fois que le système est opérationnel.

Si nous allons utiliser une implémentation d’abonnement dans le cloud, nous avons toujours des questions à répondre, bien qu’elles puissent être très différentes. Quel service en ligne utilisons-nous ? Allons-nous avec une installation dédiée ou un service multilocataire ? Qu’en est-il de la sécurité ? Pouvons-nous intégrer avec notre propre authentification ? Comment gérons-nous la reprise d’activité avec le service d’abonnement ? Où se trouvent physiquement les données ? Cela pose-t-il des problèmes juridiques pour nous ? Qu’en est-il de la prise en charge de nos navigateurs internes et appareils mobiles ? Comment allons-nous extraire nos données et comment pouvons-nous nous connecter avec des bases de données internes ou d’autres services SaaS externes (Software as a Service) pour intégrer des fonctionnalités ?

À bout de souffle encore ? Lorsque nous parlons d’un système d’entreprise, ces questions et d’autres sont à l’ordre du jour. Si nous décalons cette partie de notre projet vers notre équipe technique hautement formée, elle pourrait commencer à considérer cela comme l’étendue de l’ensemble du projet, alors qu’il ne s’agit que de la construction de notre foret, pas encore de la fabrication du trou dont nous avons besoin.

Configurez-moi !

En plus de faire fonctionner notre système, il y a aussi l’application des fonctionnalités de ce système à nos problèmes spécifiques. J’ai vu des déploiements Project Server dans lesquels le client est opérationnel et je me rends compte qu’il n’a alloué aucun financement pour créer des flux de travail, apprendre à hiérarchiser son portefeuille de projets ou apprendre à créer un seul rapport. Tout comme Systems Analysis 101 de retour à l’université, nous commençons généralement cette partie de l’implémentation à l’extrême droite d’un tableau blanc, car nous demandons aux gens d’affaires qui ont le problème réel de l’entreprise quelles « sorties » ils auront besoin. J’ai déjà parlé de cela dans d’autres écrits, donc je ne vais pas l’élaborer ici, mais les résultats devraient finalement être des décisions commerciales. Pour prendre ces décisions, de quels rapports, analyses et, en fin de compte, quelles entrées de données ai-je besoin ? Nous travaillons à partir du côté droit de l’écran vers la gauche et nous nous trouvons avec une liste de tous les blocs de construction dont nous aurons besoin sous la forme d’éléments de données, de calculs analytiques, d’exportations et de rapports qui devront être configurés dans le système. Cet exercice de configuration peut prendre des semaines ou des mois en fonction de sa complexité.

Souvent, les types de ressources dont nous aurons besoin pour cet aspect du projet sont une combinaison d’analystes d’entreprise et d’experts système, et il est courant que ces personnes peuvent être hautement qualifiées dans les fonctionnalités du système déployé, mais qu’elles ne le sont pas aussi dans l’architecture technique. Cela rend très courant le fait d’avoir des équipes déconnectées pour deux éléments critiques du système. Moins ces deux groupes communiquent, plus il est probable que nous serons confrontés à des défis plus tard.

C’est un processus

Il est impossible de déployer un nouveau système d’entreprise et de ne pas affecter les processus de l’organisation. Même si vous abandonnez un système d’entreprise centralisé et que vous passez à son concurrent, les processus changeront. En fait, si vous ne souhaitez pas que vos processus changent, il est tout à fait possible que vous n’ayez pas de problème qui doit être résolu, ce qui constitue un autre défi. Lorsque la routine quotidienne d’une personne change, cela provoque des énervements. Je ne veux pas dire une partie du temps. D’après mon expérience, l’énervement à ce moment du changement est une donnée. Cela est vrai même lorsque le changement de processus aboutira à un meilleur processus ! Il est donc essentiel de réfléchir à la façon dont les processus changeront et de travailler avec ceux qui seront affectés pour la réussite du projet. Toutefois, les experts qui sont essentiels à la conception de ce changement dans le processus sont probablement les mêmes personnes qui seront affectées par ce changement, de sorte que cela peut être un aspect difficile de la mise en œuvre. En règle générale, un animateur qualifié et expérimenté travaille avec les experts internes pour guider le changement de processus qui est devenu possible avec la mise en œuvre du nouveau système. Dans notre ligne de travail, nous voyons ce défi tout le temps. « Mais les responsables de projet doivent d’abord effectuer les approbations de feuille de temps », nous dit un nouveau client TimeControl. « C’est notre processus. » Quand nous expliquons que les approbations matricielles peuvent permettre aux gestionnaires de projet d’effectuer leurs approbations de feuille de temps dans le cadre d’un processus plus vaste et plus efficace, nous sommes contrariés; Pushback. À ce stade, l’un de nos employés les plus expérimentés travaille avec les personnes concernées pour s’assurer que leurs préoccupations sont prises en compte et qu’elles font partie intégrante de la façon dont le processus changera.

Par conséquent, les personnes du processus ne sont probablement pas les personnes de configuration ou les personnes techniques, mais si nous n’avons pas prévu cette équipe, tout notre travail acharné sur l’installation et la configuration ne sera probablement pas déployé. Cette équipe doit également faire partie de notre planification, incluse dans les communications et les décisions prises par les deux autres équipes.

Formation

« Alors, aurons-nous besoin de formation ? » est malheureusement une question qui est souvent posée en dernier. Certaines formations peuvent passer par les changements de processus, car cette partie du projet nécessite beaucoup de discussions pratiques, mais qu’en est-il du guide de l’utilisateur réel de la façon dont le nouveau système fonctionnera de façon plus détaillée? À un moment donné, la formation était considérée comme un élément essentiel des déploiements de logiciels et les clients s’attendaient à mettre de côté environ 20 % du budget total sur celui-ci. Mais, avec les changements dans les coûts des logiciels et la vitesse d’installation, progressivement, ce 20% est devenu de moins en moins d’argent. Si nous payons 20 $ par mois et par utilisateur pour un système, dois-je mettre de côté 4 $ par utilisateur pour la formation ? Je ne peux pas promettre que ça n’ira pas trop loin. Il existe de nombreuses options d’abonnement en ligne pour la formation, mais aucune de ces options ne prend en compte la solution exacte que vous avez conçue.

Les formateurs peuvent venir de l’extérieur ou peuvent provenir des parties de configuration ou de processus du projet, mais il s’agit souvent de spécialistes plutôt que de personnes qui ont réellement effectué le travail de mise en œuvre. Donc, même si vous avez mis de côté le financement de cette équipe (et j’espère que vous l’avez fait), vous devez quand même vous assurer que ces personnes savent ce que le système dans lequel ils forment les gens est réellement conçu pour faire. J’ai vu des formateurs arriver pour Microsoft Project Server et leur ai demandé de commencer à expliquer aux utilisateurs comment configurer des champs d’entreprise et configurer des pilotes métier dans l’analyse de portefeuille, mais pour que les utilisateurs donnent un regard vide, car leurs champs d’entreprise étaient déjà tous configurés et qu’ils n’utiliseraient pas l’analyse de portefeuille dans leur déploiement initial. Vos formateurs connaissent-ils même le problème que ce déploiement particulier est censé résoudre ? Ils devraient. Réfléchir à la formation au début du projet lui donne les plus grandes chances de succès. Les équipes techniques, de configuration et de processus peuvent mettre de côté les données critiques tout au long de leurs sections pour la formation qui sera finalement fournie. Cela signifie impliquer l’équipe d’entraînement tôt.

Déploiement/acceptation/changement de culture

Si vous pensiez vers l’avant et mettez de côté les ressources nécessaires pour lancer ces équipes et que toutes les équipes travaillent et communiquent ensemble dans le cadre du projet, le déploiement de votre nouveau système est susceptible d’aller beaucoup plus facilement qu’autrement, mais ne sous-estimez pas la résistance au changement de culture. Avoir des évangélistes clés disponibles au bon moment peut être essentiel. En outre, tous ces membres de l’équipe vont-ils faire leurs bagages et passer à leur prochain projet ? Il y aura beaucoup de connaissances système encapsulées dans ces personnes au moment du lancement du projet. J’ai été particulièrement impressionné par l’un de nos clients au début de l’année dernière. Il s’agissait du service informatique d’une grande organisation financière. L’une des préoccupations que nous avons soulevées à l’utilisateur technique clé qui évaluait le logiciel au début du projet était « qui sera l’administrateur une fois que vous aurez fini le projet ? » « Je le veux, a-t-il dit. Il était fidèle à sa parole. Ses compétences et ses connaissances ont évolué au cours du déploiement de plusieurs mois, qui a été un grand succès, et il reste toujours l’administrateur clé.

Conclusion

Il y a une centaine d’autres choses à prendre en compte pour s’assurer que vos équipes communiquent et travaillent dans le cadre d’un objectif plus large, et nous n’en avons parlé que quelques-uns. Espérons que cela vous fasse déjà réfléchir à votre prochain déploiement de système d’entreprise. « Qu’en est-il de la documentation ? », pensez-vous peut-être. « Qu’en est-il du support technique ? »

La chose essentielle à retenir est la suivante : lorsque vous planifiez un déploiement de système d’entreprise, vous devez étendre votre perspective pour inclure non seulement l’effort d’installation, mais également la livraison de la solution terminée. Assurez-vous que le trou s’affiche à l’endroit où il doit être juste dans la bonne taille, la bonne profondeur et l’angle droit.

À propos de l’auteur

Chris Vandersluis est le président et fondateur de HMS Software, basé à Montréal, au Canada, un partenaire certifié Microsoft. Il a un diplôme en économie de l’Université McGill et plus de 30 ans d’expérience dans l’automatisation des systèmes de contrôle de projet. Il est un membre de longue date du Project Management Institute (PMI) et a participé à la création des sections de Montréal, Toronto et Québec du Microsoft Project Users Group (MPUG). Les publications pour lesquelles Chris a écrit incluent Fortune, Heavy Construction News, le magazine Computing Canada et PMNetwork de PMI, et il est un chroniqueur régulier pour Project Times. Il enseigne la gestion avancée de projets à l’Université McGill et intervient souvent à des fonctions d’association de gestion de projets dans Amérique du Nord et partout dans le monde. HMS Software est l’éditeur du système de gestion du temps timecontrol orienté projet et est partenaire de solution Microsoft Project depuis 1995.

Chris Vandersluis peut être contacté par e-mail à l’adresse : chris.vandersluis@hms.ca

Si vous souhaitez lire d’autres articles relatifs à L’EPM de Chris Vandersluis, consultez le site d’aide sur l’EPM de HMS (https://www.epmguidance.com/?page_id=39).