Meilleures pratiques pour les systèmes d’entreprise : livre blanc

Ce livre blanc fait partie de notre collection « Depuis les tranchées ». Il décrit les meilleures pratiques opérationnelles pour les systèmes d’entreprise en général (notamment Microsoft Project Server). Il fait observer que, bien que les systèmes d’entreprise s’efforcent de fournir une interface simple au niveau de l’utilisateur, l’infrastructure et les technologies requises pour fournir celle-ci sont souvent très complexes. Ce livre blanc décrit ensuite de quelle façon ce niveau de complexité implique que vous utilisiez certaines meilleures pratiques pour maintenir un haut degré de fiabilité dans votre système d’entreprise.

Pour télécharger la version Word de ce livre blanc, voir Meilleures pratiques pour la gestion d’entreprise.

Pour consulter d’autres livres blancs, voir les livres blancs « Depuis les tranchées ».

Meilleures pratiques pour le gestion d’entreprise

J’écris principalement sur les systèmes de gestion de feuilles de temps ou de projets d’entreprise. La phase de déploiement dont je parle le plus souvent dans le cas de tels systèmes est celle de la sélection ou de la configuration (perspective stratégique). Cet article a davantage trait aux pratiques opérationnelles et ne s’applique pas uniquement aux systèmes de gestion des feuilles de temps ou des projets d’entreprise comme Microsoft Project Server. Il a trait aux systèmes d’entreprise en général, bien que cet aspect est probablement applicable à la plupart des déploiements Project Server.

Lorsque nous rencontrons des systèmes Project Server déjà déployés ou que nous échangeons avec des clients existants, nous posons souvent des questions sur les modalités de déploiement et de support du système et de son environnement par l’organisation. Lorsque nous nous sommes lancés dans ce domaine d’activité, il s’agissait de simples conversations car le logiciel de gestion de projets installé serait toujours limité au PC de l’utilisateur final, et la maintenance du système assurée localement. De nos jours, c’est rarement le cas. Les systèmes d’entreprise sont simples au niveau de l’interface ou de l’affichage qui permet généralement aux utilisateurs d’accéder aux fonctionnalités via un navigateur web, dans ce qui ressemble à une page web quelconque. Ces systèmes sont aussi simples en façade qu’ils sont complexes à l’intérieur. La technologie requise pour l’affichage de cette interface inclut certainement plusieurs couches, dépend de plusieurs sources pour la technologie et l’infrastructure et (comme si cela ne suffisait pas) est probablement mise à jour tout le temps.

Il y a toutefois certaines meilleures pratiques pour maintenir un haut degré de fiabilité dans votre système d’entreprise.

Trouvez un propriétaire

En réalité, il doit y avoir deux propriétaire. En effet, n’importe quel système d’entreprise efficace a un propriétaire d’entreprise et un propriétaire technique. Si le propriétaire d’entreprise est un cadre du service TI et que le système d’entreprise concerne essentiellement ce service, les deux propriétaires peuvent être la même personne. Cela implique donc deux étapes :

Trouvez un propriétaire d’entreprise

Cette personne doit être membre du personnel d’encadrement ou des instances dirigeantes et présenter un intérêt direct pour les résultats du système de gestion de projets. Les avantages que le système doit offrir ou les défis qu’il doit surmonter devront être les avantages et les défis qui affectent directement cette personne. Il ne peut pas s’agir d’un comité ou de plusieurs personnes.

La responsabilité doit se trouver ailleurs et cela implique presque toujours une seule personne. Cette personne peut aussi être le sponsor exécutif pour l’implémentation du système. Souvent le sponsor exécutif n’est pas le propriétaire d’entreprise ultime d’un système d’entreprise.

Même une fois que le projet de déploiement est terminé, le propriétaire d’entreprise possédera toujours le système et, s’il ne devait plus en avoir besoin, un autre propriétaire d’entreprise doit être identifié et s’engager auprès du système, ou le système doit être mis hors service.

Trouvez un propriétaire technique

Pour les systèmes de niveau entreprise, le fait d’avoir un technicien disponible est insuffisant. N’oubliez pas que les systèmes d’entreprise dépendent de nombreuses couches de technologie. Le propriétaire technique doit être un responsable ou un cadre du service TI suffisamment expérimenté pour pouvoir interagir immédiatement avec les propriétaires de ces autres couches de technologie. Ceci peut inclure les cadres supérieurs propriétaires de la base de données SQL Server (serveur de base de données sur lequel SQL Server est installé), le ou les serveurs d’applications sur lesquels Project Server est installé, la mise en réseau, le serveur web ou la batterie de serveurs, la connexion Internet, le pare-feu, Active Directory et les serveurs Exchange, les serveurs ou systèmes de sécurité, et l’image du système d’exploitation au niveau du client. Un cadre supérieur doit pouvoir représenter ce système d’entreprise auprès des responsables qui contrôlent les autres aspects de l’environnement.

Trouvez l’objectif

Assurez-vous que Project Server a) a un objectif et b) remplit sa fonction. Cela vous paraît être une évidence ? Ce n’en est pas une. Trop souvent les systèmes d’entreprise sont acquis pour une mauvaise raison, et il incombe à un membre du service TI d’identifier l’application concrète du système. La personne validant l’application professionnelle du système d’entreprise doit être le propriétaire d’entreprise, même si d’autres personnes peuvent être impliquées dans ce processus. Je pose toujours à ces personnes une question que j’utilise depuis des années : « Quelle décision professionnelle ne pouvez pas prendre ou pouvez-vous prendre difficilement actuellement, et pour laquelle le déploiement de ce système pourra aider ? ». Une fois le besoin professionnel (je ne parle pas ici de fonctionnalité souhaitée) est défini, assurez-vous que le système d’entreprise couvre effectivement ce besoin. Je rencontre un grand nombre de personnes ayant défini une liste de fonctions, mais présentant un faible niveau de compréhension de ce qu’elles tentent de réaliser avec celles-ci.

À mesure que l’organisation évolue, veillez à ce que le propriétaire d’entreprise en revienne à ce concept de base. Le déploiement seul d’un système d’entreprise comme Project Server peut modifier de façon fondamentale l’entreprise dans laquelle il est déployé. Il n’est donc pas surprenant de trouver que les exigences de l’organisation en relation avec un système peuvent changer.

Il est courant de se retrouver plusieurs années après l’adoption et le déploiement de Project Server dans l’impossibilité de trouver une personne capable de décrire son importance pour l’organisation. Le système est utilisé. Il n’avance qu’en raison de l’effet d’inertie, mais l’objectif a été perdu et les dirigeants qui l’utilisent au quotidien ne savent pas en identifier les avantages.

Intégrez le système à votre architecture d’entreprise

Il y a plusieurs années, j’ai rendu visite avec l’un de nos techniciens à un client contrarié sur le site de son entreprise. L’instance de Project Server qu’il avait installée lui-même était à l’origine de divers problèmes. Pendant cette visite, nous avons demandé à interroger plusieurs techniciens employés, afin d’identifier les différentes couches du système. Quel n’a pas été notre étonnement lorsque nous sommes arrivés à la couche de la base de données. Au lieu d’être un des serveurs de base de données standard de l’organisation, la version de SQL Server sur laquelle le système était installé se trouvait sur le PC d’un utilisateur final. À chaque redémarrage, mise hors tension de l’ordinateur ou installation d’un programme, la base de données devenait indisponible. Cela affectait plusieurs centaines d’utilisateurs finaux.

Il s’agissait d’une organisation de grande taille, aussi les serveurs d’entreprise ou l’infrastructure utile étaient bel et bien disponibles. Dans ce cas spécifique, le problème a été facilement résolu. C’était toutefois une bonne leçon. Le système que vous déployez est-il intégré à l’infrastructure d’entreprise existante pour laquelle l’organisation a éventuellement déployé des efforts importants pour assurer la stabilité, la fiabilité et la sécurité ?

Sauvegardez le système

Je sais ce que vous vous dites. Cela vous paraît idiot, n’est-ce pas ? Étonnamment et malheureusement, cela ne l’est pas. La sauvegarde des systèmes d’entreprise est notoirement complexe, car elle peut dépendre de plusieurs aspects du système à sauvegarder en même temps. Il y a les données de base évidemment, mais aussi les métadonnées et les données de configuration de l’implémentation. Il est par ailleurs possible que les données liées à des systèmes auxiliaires devant éventuellement reproduire le système fassent partie du même schéma de sauvegarde. Lorsqu’on pense à Project Server, il faut envisager la sauvegarde de la ou des bases de données de projet, mais également de la base de données SharePoint Server. Dans les versions de Project Server antérieures à 2010, il faut éventuellement sauvegarder le modèle global. Même maintenant il peut y avoir des éléments des modèles qui se trouvent sur des PC individuels.

La simple sauvegarde ne suffit pas. Lorsque les systèmes changent ou sont mis à niveau, vous devez restaurer la base de données au moins une fois. Je me souviens il y a des années d’avoir rencontré un client que nous avions aidé dans la conception d’une stratégie de sauvegarde. Il arrête le serveur, retire le disque dur, place un autre disque dur, avant de nous dire « Vous voyez. Le disque dur vient de tomber en panne. Voici un disque dur formaté. Vous pouvez restaurer mon Project Server ? » J’ai été extrêmement déconcerté, parce que j’ai alors réalisé qu’il s’agissait d’une demande légitime. Plus j’y ai pensé, plus je me suis dit qu’il était choquant que personne n’ait jamais fait cette demande auparavant (ou depuis). Par conséquent, effectuez au moins une restauration. Nous avons finalement réussi à restaurer le système, mais n’avons pas pu rétablir un état aussi propre que celui anticipé. Par conséquent, nous avons du mettre à jour nos procédures de sauvegarde.

Environnement intermédiaire/de production

L’utilisation d’un environnement intermédiaire est essentiel pour n’importe quel système d’entreprise. Une fois le système en phase de production, vous devez essayer de nouvelles configurations, ajouter de nouvelles personnalisations, essayer de nouveaux rapports, liaisons, champs et autres changements. Il y aura des mises à jour et des mises à niveau. Toutes doivent être testées au préalable au sein d’un environnement intermédiaire ou de développement avant d’être appliquées aux utilisateurs dans l’environnement de production. Une simple mise à jour d’un navigateur ou d’une base de données peut dérégler des systèmes d’entreprise. Vous devez donc veiller à conserver et maintenir un environnement intermédiaire séparé de l’environnement de production. Dans cette ère des serveurs virtuels, c’est peut être plus facile que par le passé. Un environnement entier peut souvent être cloné à partir du système de production. Pour autant, en fonction des modalités de déploiement, c’est peut-être plus facile à dire qu’à faire. Rappelez-vous que bon nombre des différentes pièces du puzzle technologique peuvent être référencées, même si vous avez copié un serveur entier.

Surveillez encore et toujours

De nombreux aspects de la surveillance peuvent être utilisés pour surveiller un système d’entreprise. En premier lieu, vérifier la disponibilité de Project Server auprès des utilisateurs est critique. S’assurer que le personnel technique approprié est informé dès que possible au cas où il devient inaccessible est également essentiel. Heureusement, de nombreux outils permettent de s’assurer du fonctionnement et de la disponibilité du système. Ceux-ci peuvent envoyer automatiquement une notification au personnel technique même si les utilisateurs finaux n’ont pas encore remarqué le problème. D’autres aspects de la surveillance sont également importants. Il est recommandé de surveiller et consigner l’intégrité de l’application, notamment la quantité de mémoire utilisée, la quantité d’UC utilisée, les erreurs que le système a signalé même s’il est parvenu à récupérer seul, les redémarrages requis du serveur et l’intégrité des autres éléments pertinents de l’infrastructure technique. Par exemple, savoir que IIS rencontre des problèmes techniques peut être très important pour maintenir la disponibilité de votre application d’entreprise.

Même les modifications mineures sont des modifications

La technologie sur laquelle Project Server est basé évolue quotidiennement. Il est impossible d’éviter toutes ces modifications. Le système d’exploitation Windows Server reçoit généralement des mises à jour à intervalles de quelques jours, SQL Server peut recevoir des mises à jour à intervalles de quelques semaines. Les systèmes d’exploitation clients Windows individuels, leurs logiciels antivirus, les pare-feux, ainsi qu’Internet Explorer et ses compléments obtiennent des mises à jour régulièrement. N’importe quel élément de la chaîne entre les données et l’utilisateur final peut constituer un point de défaillance pour l’application. Vous devez donc créer une structure permettant de gérer les modifications apportées dans l’ensemble de la pile technologique.

Cela peut poser problème, car de nombreuses applications d’entreprise peuvent dépendre d’aspects similaires de la pile. Un client a par exemple mis à jour Project Server récemment pour finalement constater que l’ensemble de l’environnement SharePoint Server était arrêté. Il y avait eu une erreur dans la manière dont la mise à jour de Project Server/SharePoint Server avait été appliquée. S’il y avait des sauvegardes complètes et qu’aucune donnée n’était perdue, le processus de mise à niveau n’incluait toutefois pas de disposition de restauration instantanée. Les effets ont été dévastateurs puisqu’il a fallu des jours pour les inverser.

Un client d’une autre organisation avait mis à jour une autre application d’entreprise pour découvrir qu’elle impliquait la mise à niveau par tous les utilisateurs de la version de leur navigateur et que les autres applications d’entreprise déjà utilisées dans la société ne prenaient pas en charge la version la plus récente du navigateur. C’est l’illustration de l’expression « être pris entre le marteau et l’enclume ». Au final, il a du annuler la mise à niveau du système d’entreprise et attendre que les applications d’entreprise puissent utiliser une nouvelle mise à niveau du navigateur.

Il est parfois préférable de paraître intégré que de l’être vraiment

Les démonstrations donnent toujours l’impression que l’intégration est simple. Les données commencent ici et finissent ici. L’établissement d’une liaison entre des outils hautement flexibles tels que Project Server et d’autres systèmes d’entreprise (Finance, ERP, etc.) est suffisamment difficile, et nous recommandons que les deux systèmes soient en production et stables avant l’établissement des liaisons. Cependant, une fois qu’elles sont en cours d’application, il est encore plus important de surveiller les modifications apportées aux deux systèmes en veillant à s’assurer que la liaison sera toujours établie correctement.

Les mises à niveau d’un système peuvent impliquer la modification des données, la modification de la structure ou des exigences techniques différentes. Il peut également y avoir des nouveaux avantages et fonctionnalités possibles. Assurez-vous toutefois que la fonctionnalité de liaison existante est testée dans votre environnement intermédiaire avant son déploiement en production.

Documentez encore et toujours

Les personnes présentes lors de la sélection et du déploiement de Project Server ne garderont pas ces rôles indéfiniment. Si elles ont fait du bon travail, elles seront à même de gérer le prochain déploiement d’entreprise dont l’organisation a besoin. Il est donc essentiel de documenter les choix de configuration, les avantages anticipés, les attentes opérationnelles et les paramètres utilisés pour prendre ces décisions. Dans l’avenir, d’autres personnes examineront ce système et essaieront d’en comprendre les tenants et les aboutissants. Veillez à les y aider.

Les documents sur les systèmes d’entreprise doivent être des documents actualisés à chaque mise à niveau, chaque changement de propriétaire d’entreprise ou technique, ou chaque changement majeur dans la structure d’exploitation ou les besoins de l’entreprise.

Réfléchissez avant de sauter

Ce conseil avisé est généralement donné à une personne qui s’apprête à sauter dans un lac aux eaux troubles pour la première fois. Est-il profond ? Y a-t-il des rochers juste sous la surface ? En effet, les systèmes de gestion de projets d’entreprise comme Project Server peuvent permettre de regrouper des éléments de données complexes dans un emplacement centralisé au sein duquel la prise de décisions basées sur ces données peut être optimisée et les avantages de ces décisions peuvent apporter une différence importante à une organisation. Vous devez toutefois procéder aux tests qui s’imposent pour vous assurer que vous exploitez votre système d’entreprise d’une manière qui vous permet d’obtenir les avantages utiles sans exposer votre organisation aux coûts et aux risques qui peuvent rapidement anéantir la valeur de ces avantages.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de HMS Software. Basée à Montréal (Canada), l’entreprise est un partenaire Microsoft Certified Partner. Diplômé en sciences économiques de l’université McGill, Chris a plus de 30 ans d’expérience dans l’automatisation des systèmes de gestion de projets. Il est membre du Project Management Institute (PMI) depuis de nombreuses années et a participé à la création des chapitres du Microsoft Project Users Group (MPUG) pour Montréal, Toronto et Québec. Il a publié des articles dans Fortune, Heavy Construction News, Computing Canada et PMNetwork. Il tient également une chronique régulière pour Project Times. Il enseigne la gestion de projets avancée à l’université McGill et intervient souvent lors d’événements organisés par des associations de gestion de projets en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système d’horloge pour les projets TimeControl et est un partenaire Microsoft Project Solution Partner depuis 1995.

Vous pouvez contacter Chris Vandersluis à cette adresse : chris.vandersluis@hms.ca.

Pour consulter d’autres articles en lien avec la gestion des projets d’entreprise rédigés par Chris Vandersluis, rendez-vous sur le site EPM Guidance de HMS Software (http://www.epmguidance.com/?page_id=39).

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×