Nous vendons des trous, pas des perceuses !

J’ai rencontré une expression intéressante récemment. Un vendeur de logiciels a parlé de la livraison de l’intégralité de la solution à son client. « Nous ne vendons pas d’exercices. Nous vendons des trous », a-t-il dit. Il s’agit d’une excellente analogique. De nombreuses personnes (que j’ai incluses) sont passées au magasin de matériel et à la fenêtre encadrées dans le service des outils d’alimentation tout en se demandant à quel projet je peux penser et qui justifierait l’achat de cet excellent outil d’alimentation. Toutefois, l’application de cette logique est aussi logique 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 doit chercher un exercice, sauf si le problème qu’il souhaite résoudre consiste à faire un vide, personne ne doit chercher des logiciels d’entreprise, sauf s’il résout un problème. Maintenant, si vous avez un problème que le déploiement de logiciels d’entreprise corrigera, la prochaine chose à faire est que ce que vous achetez fournit la solution dont vous avez besoin. Ce n’est souvent pas seulement l’achat du logiciel.

Le déploiement d’un système d’entreprise est un défi complexe, de sorte que le paiement en vaut la peine. Dans le monde actuel des équipes de projet globales, l’une des choses les plus courantes consiste à diviser l’effort considérable d’un déploiement de système d’entreprise. Bien que cela puisse nous donner un niveau d’échelle dans l’utilisation d’équipes hautement formées dans leur aspect du projet, il risque également de ne pas oublier certains aspects du projet de manière hautement risquée. Ce risque est composé, plus les différentes équipes sont déconnectées physiquement et organisationnelles.

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. « Enterprise », dans ce contexte, signifie tout projet qui aura un impact sur le fonctionnement de l’ensemble de l’organisation. Je vais dire que cela est vrai pour n’importe quelle organisation. Les implémentations éligibles en tant qu’implémentations d’entreprise ne sont pas seulement le nombre d’utilisateurs, mais l’impact qu’ils ont. Ainsi, la mise à jour de notre logiciel antivirus du fournisseur A au fournisseur B ne serait probablement pas éligible. L’implémentation du logiciel de planification de projet sur le bureau pour un petit nombre d’utilisateurs n’est probablement pas éligible. La centralisation de notre gestion de projet et l’utilisation d’un système de gestion de projets d’entreprise centralisée seraient probablement éligibles.

Bon, 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, tels que Microsoft Project Server, mais ces éléments sont communs à presque n’importe quelle implémentation de système d’entreprise.

Bits et octets

Tout d’abord, nous allons aborder les blocs de construction les plus fondamentaux des logiciels : l’architecture technique. Ces jours-ci, nous devons diviser notre réflexion en fonction de notre décision d’aller avec un déploiement local ou un abonnement dans le cloud. Je vais laisser la question de choisir la meilleure condition dans quelles conditions pour un autre jour, mais voici quelques éléments de base de ce que nous devons penser dans chaque catégorie.

Si nous allons avec une installation sur site, 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 requis ? Avons-nous besoin de serveurs d’applications, de serveurs de sécurité et de serveurs web ? Qu’en est-il de l’équilibrage de charge, de la récupération d’urgence et des sauvegardes ? Avons-nous besoin de serveurs de sauvegarde à froid ou à chaud ? Whew! Mais nous n’avons pas terminé ! 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 de sécurité, d’application et de base de données existantes ? Qu’en est-il de la prise en charge des navigateurs, des versions de navigateur et des appareils mobiles ? Une fois que toutes ces questions ont été posées, nous devons gérer les problèmes d’installation, de test et de production, puis l’état et la surveillance du système une fois le système opérationnel.

Si nous allons avec une implémentation d’abonnement dans le cloud, nous avons toujours des questions à répondre, même s’il peut s’agit de questions très différentes. Quel service en ligne utilisons-nous ? Allons-nous avec une installation dédiée ou un service multi-clients ? Qu’en est-il de la sécurité ? Pouvons-nous intégrer notre propre authentification ? Comment gérer la récupération d’urgence avec le service d’abonnement ? Où se trouvent les données physiquement ? Cela présente-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 récupérer nos données et comment pouvons-nous nous connecter avec des bases de données internes sortantes ou d’autres services SaaS (Software as a Service) externes pour intégrer des fonctionnalités ?

Vous n’en a pas encore ? Lorsque nous parlons d’un système d’entreprise, ces questions et bien plus sont à l’ordre du jour. Si nous déorientons cette partie de notre projet vers notre équipe technique hautement entraînée, il se peut qu’elle commence à la penser comme l’étendue de l’ensemble du projet, lorsqu’il s’agit simplement de la construction de notre exercice, pas encore de la construction du trous dont nous avons besoin.

Configurez-moi !

En plus de faire fonctionner notre système, il existe également l’application des fonctionnalités de ce système à nos problèmes spécifiques. J’ai vu des déploiements Project Server où le client met Project Server en service, puis réalise 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 rapport unique. 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 entreprises qui ont le problème d’entreprise réel les « résultats » dont ils ont besoin. J’ai déjà parlé de cela dans d’autres écritures afin de ne pas l’écrire ici, mais les résultats doivent finalement être des décisions d’entreprise. Pour prendre ces décisions, de quels rapports, quelles analyses et, en fin de compte, quelles sont les entrées de données dont j’ai besoin ? Nous travaillons de la partie droite de l’écran vers la gauche et nous nous retrouveons avec une liste de tous les blocs de construction dont nous avons 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 avons besoin pour cet aspect du projet sont une combinaison d’analyste d’entreprise et d’expert système, et il est courant que ces personnes soient très qualifiées dans les fonctionnalités du système déployé, mais qu’elles ne sont pas aussi qualifiées dans l’architecture technique. Cela rend assez courant le fait d’avoir des équipes déconnectées pour deux éléments critiques du système. Moins ces deux groupes communiquent, plus nous allons probablement être confrontés à des défis ultérieurement.

Il s’agit d’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 changez de concurrent, les processus changent. En fait, si vous ne souhaitez pas que vos processus changent, il est tout à fait possible que vous n’avez pas de problème qui doit être résolu, et voici un autre défi. Lorsque la routine quotidienne d’une personne change, elle provoque des problèmes. Je ne veux pas dire une partie du temps. Dans mon expérience, l’expérience à ce moment du changement est une donnée. Cela est vrai même lorsque la modification du processus entraîne un meilleur processus ! Il est donc essentiel de réfléchir à la façon dont les processus vont changer et de travailler avec les personnes qui seront affectées pour la réussite du projet. Toutefois, les experts qui sont essentiels à la conception de cette modification dans le processus sont probablement les mêmes personnes qui seront affectées par ce changement, ce qui peut être un aspect difficile de l’implémentation. En règle générale, un animateur compétent et expérimenté travaille avec les experts internes pour guider le changement de processus qui est devenu possible avec l’implémentation du nouveau système. Dans notre ligne de travail, nous voyons ce défi en tout temps. « Toutefois, les responsables de projet doivent d’abord approuver les feuilles de temps », nous indique un nouveau client TimeControl. « C’est notre processus. » Lorsque nous expliquons que les approbations matricielles peuvent permettre aux responsables de projets d’approuver leurs feuilles de temps dans le cadre d’un processus plus large et plus efficace, nous nous faisons du mal . 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 charge et qu’elles font partie intégrante de la façon dont le processus va changer.

Par exemple, les personnes du processus ne sont probablement pas les personnes de configuration ou les personnes techniques, mais si cette équipe n’est pas planifiée, tout notre travail dur 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

« Nous allons donc avoir besoin d’une formation ? » est malheureusement une question qui est souvent posée en dernier. Certaines formations peuvent passer par les modifications du processus, car cette partie du projet nécessite une discussion pratique, mais qu’en est-il du guide utilisateur réel sur le fonctionnement pas à pas du nouveau système ? À un moment, la formation était considérée comme un élément essentiel des déploiements de logiciels et les clients devait réserver environ 20 % du budget total. Toutefois, avec les modifications apportées aux coûts logiciels et à la vitesse d’installation, ces 20 % sont progressivement devenus de moins en moins coûteux. Si nous payons 20 dollars 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 me dire qu’elle ne va pas trop loin. Il existe de nombreuses options d’abonnement en ligne pour la formation, mais aucune de ces options ne prendra en compte la solution exacte que vous avez conçue.

Les formateurs peuvent venir de l’extérieur ou peuvent être issus des parties de configuration ou de processus du projet, mais il s’agit souvent de personnes qui sont des spécialistes plutôt que des personnes qui ont réellement fait le travail d’implémentation. Ainsi, même si vous avez mis de côté le financement pour cette équipe (et j’espér que vous l’avez fait), vous devez vous assurer que ces personnes connaissent le système dans le but de former des personnes. J’ai vu des formateurs arriver pour Microsoft Project Server et leur avoir fait commencer à expliquer aux utilisateurs comment configurer des champs d’entreprise et configurer des pilotes d’entreprise dans l’analyse de portefeuille, uniquement pour que les utilisateurs donnent un regard vide, car leurs champs d’entreprise étaient déjà tous configurés et ils ne vont pas utiliser l’analyse de portefeuille dans leur déploiement initial. Vos formateurs savent-ils même le problème que ce déploiement particulier est censé résoudre ? Elles le doivent. Penser à la formation au début du projet lui donne le plus de chances de réussir. Les équipes techniques, de configuration et de processus peuvent mettre des données critiques de côté tout au long de leurs sections pour la formation qui sera finalement donnée. Cela implique l’implication précoce de l’équipe de formation.

Déploiement/acceptation/changement de culture

Si vous envisagez et mettez de côté les ressources nécessaires pour lancer ces équipes et que toutes ces équipes travaillent et communiquent ensemble dans le projet, le déploiement de votre nouveau système sera probablement beaucoup plus fluide que dans le cas contraire, mais ne sous-estimez pas la résistance au changement de culture. Il peut être essentiel d’avoir des clés disponibles au bon moment. En outre, tous ces membres d’équipe seront-ils en train de préparer leur projet et de passer à leur prochain projet ? Une grande partie des connaissances système seront errées dans ces personnes au moment du déploiement du projet. J’ai été particulièrement touché 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’un des problèmes que nous avons faits à l’utilisateur technique clé qui évaluait le logiciel au début du projet était « qui sera l’administrateur une fois le projet encapsulé ? » « Je le vais », a-t-il dit. Il a dit vrai à sa parole. Ses compétences et ses connaissances ont évolué au cours du déploiement de plusieurs mois, ce qui a été une grande réussite, et il reste toujours l’administrateur clé.

Habillage vers le haut

Il existe une centaines d’autres éléments à prendre en compte pour vous assurer que vos équipes communiquent et travaillent dans le cadre d’un objectif plus large, et nous n’en avons parlé que quelques-unes. Nous espérons qu’il vous fait déjà réfléchir à votre déploiement de système d’entreprise suivant. « Qu’en est-il de la documentation ? » vous pensez peut-être. « Qu’en est-il du support technique ? »

L’élément clé à retenir est le suivant : lorsque vous planifiez un déploiement de système d’entreprise, vous devez développer votre perspective pour inclure non seulement l’effort d’installation, mais également la fourniture de la solution terminée. Assurez-vous que le trous s’affiche à l’endroit où il doit se trouve dans la taille, la profondeur droite et l’angle droit.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de Hms, hms Software basé au Canada, un microsoft certified Partner. Il dispose d’un degré d’économie de Mc Galerie University et plus de 30 ans d’expérience dans l’automatisation des systèmes de contrôle de projet. Il est membre de longue date de l’Project Management Institute (PMI) et a contribué à la recherche des chapitres Du groupe d’utilisateurs du Microsoft Project (MPUG) de Contrôle d’ensemble. Les publications pour lesquelles Chris a écrit incluent Classement, Heavy Construction News, Computing Canada magazine et PMI’s PMNetwork, et il est régulièrement habitué à Project Times. Il enseigne la gestion avancée Project à l’Université Mc University et parle souvent dans les fonctions d’association de gestion de projet en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système de gestion du temps orienté projet TimeControl et est un partenaire Microsoft Project solution depuis 1995.

Chris Vandersluis peut être contacté par courrier électronique à l’adresse : chris.vandersluis@hms.ca

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