Accueil
 > Rapports de TEC > Blogue de TEC > Pour mettre à niveau, ou pas mettre à niveau: ce n'est pa...

Pour mettre à niveau, ou pas mettre à niveau: ce n'est pas la question, mais comment le mise à niveau

Écrit par : Predrag Jakovljevic
Date de publication : juillet 18 2013

Une entreprise acquiert un logiciel pour résoudre un problème commercial ou de gagner un avantage concurrentiel avantage. Une solution globale est le plus souvent considéré, afin d'éviter le "réinventer la roue" syndrome, et de tirer parti de l'expérience et de l'expertise des autres. Une solution suppose que le paquet fournisseur de logiciels tenir au courant des toutes dernières améliorations technologiques dans les systèmes d'exploitation et le matériel, et veiller à ce que les tendances actuelles de l'industrie sont reflétés et pris en charge par le package. Cependant, une entreprise n'obtient pas ces avantages grâce à l'osmose, la télépathie, ou l'imposition des mains. Ces prestations sont sous la forme de versions de logiciels, service packs et des correctifs. Une société qui choisit de ne pas déployer ces offres des fournisseurs peut se trouver sur une île de l'isolement du logiciel, ou dans une friche non pris en charge. Cette note de recherche se penche sur le processus de pensée qui va généralement dans la décision de mettre à niveau, de ne pas mettre à jour ou à sauter par-dessus les nouvelles versions.

Avant d'entrer dans la discussion de mise à niveau, certains termes doivent être définis. Comme illustré dans la hiérarchie pyramidale de mise à niveau, une nouvelle version offre généralement de nouvelles fonctionnalités (telles que des composants Web-enabled, radio identification de fréquence support [RFID] ou de l'architecture orientée services [SOA]), fournit de nouveaux éléments de données et la saisie des données (comme dans pedigrees de drogue ou de sensibilisation bio-terrorisme), ou tire profit de la technologie matérielle et logicielle (par exemple, les serveurs lames, ou le système d'exploitation Linux). Typiquement, une nouvelle version, il faudra pilotes et des tests, formation des utilisateurs, et la conversion des données. Un service pack, en revanche, est conçu pour corriger certains bugs présents dans le logiciel du fournisseur. En tant que tel, de nouveaux éléments de données ne sont pas introduits, et des tests approfondis devraient pas être tenus. Avouons-le: le vendeur est censé être corriger les problèmes existants, ne pas introduire de nouvelles. Un patch est une solution plus localisée ou mise à niveau, et comme service packs, devrait être transparent pour la communauté des utilisateurs. Une pyramide est une figure appropriée pour représenter la hiérarchie de mise à niveau, car les nouvelles versions peuvent inclure des services packs et patches antérieurs, et de même, les service packs peuvent inclure des correctifs. Notre discussion portera sur les nouvelles versions et les service packs, des correctifs sont inclus dans le dernier parapluie.

attentes réglage préalable

étant du côté du gestionnaire de projet de la table et qui représentent en général la technologie de l'information (IT) factions, l'utilisateur n'est pas suffisamment préparé pour les nouvelles versions. la planification des ressources Enterprise (ERP) des projets de mise en œuvre peuvent durer de neuf à douze mois. Vous connaissez sans doute des projets qui ont eu lieu depuis des années. Au cours du projet, de nombreux utilisateurs font double emploi. Tout en subissant la formation, la saisie des données et la création de tableaux, et le pilotage du nouveau logiciel, les utilisateurs doivent encore accomplir leur normale 9 heures à 17 heures responsabilités. Mais ils effectuent ce travail parce qu'on leur a dit que le logiciel ERP peut fournir un avantage concurrentiel, attirer de nouveaux clients, augmenter la taille des commandes, réduire les inefficacités de fabrication, accélérer les livraisons, et ainsi de suite. Nous avons tous "bu la même Kool-Aid" et acheté dans cette ligne de pensée.

Le problème est que, même si au milieu d'un projet ERP neuf mois, de nouvelles versions sont roule hors les postes de travail des développeurs. Donc, juste quand vous pensiez qu'il était sûr de revenir à votre travail normal, on vous dit de se préparer pour la nouvelle version. Trop souvent, les utilisateurs sont amenés à croire que la mise en œuvre est un événement ponctuel. Rien ne pourrait être plus éloigné de la vérité. Un projet ERP n'est jamais totalement achevée.

La communauté des utilisateurs doit être fait pour comprendre cette réalité de la vie. Bien que cela ne mettra pas immédiatement sourires sur leurs visages, à moins qu'ils ne se sentent pas trompés. Si dit assez souvent par les dirigeants de l'entreprise droite, au fil du temps les utilisateurs acceptent le fait, peut-être à contrecœur. Certaines organisations créent encore plus petits sous-ensembles de l'équipe de mise en œuvre qui restent en place pour gérer les nouvelles versions. Assurez-vous de ces nouvelles charges de personnel sont fidèlement reflétées dans le processus de justification des coûts.

Mise à niveau Justification

La réponse la plus évidente à ce dilemme de mise à niveau est que si vous ' avez déjà payé pour la nouvelle version, pourquoi ne pas l'utiliser? Vous faites le calcul. Logiciel ERP vente conservatrice pour 250.000 $ est livré avec une étiquette de prix annuelle de maintenance de 50.000 $ à 60.000 $. Si vous ne mettez pas à jour, vous pouvez être jeter l'argent par les fenêtres du logiciel. Maintenant, penchons-nous sur quelques considérations moins évidentes.

Service Packs

La décision d'appliquer des service packs devrait être assez simple si vous avez choisi un fournisseur de logiciels avec une programme d'assurance de qualité. Les Service Packs sont destinés à résoudre les problèmes de logiciels en modifiant le code. En tant que tel, les tests devraient être minimes, et la formation peut même ne pas être nécessaire. La clé de défauts ou de singe seulement possible dans ce processus de réflexion est de savoir si le colis a été fortement modifiée ou améliorée.

Dans le cas d'améliorations, vous devez d'abord déterminer si le Service Pack impact des améliorations. Deuxièmement, vous devez moderniser les améliorations sur le service pack. L'essai doit plus être considéré comme minime. Les tests doivent veiller à ce que les améliorations fonctionne comme prévu, et qu'ils ne nient pas le groupe de correctifs de service. Une règle d'or: pour chaque service pack, budget de 20 pour cent du coût initial de la mise en valeur pour la modernisation. Donc, pour une amélioration qui a été installé pour 50.000 $ (et en supposant que quatre paquets de services sont délivrés au cours de l'année, pas une vitesse de libération déraisonnable pour certains fournisseurs), vous cherchez à un coût de $ 40,000. Ce chiffre ne tient pas compte du temps des employés de l'entreprise impliqués dans les tests. Alors que les premiers dirigeants (PDG), comme pour répondre aux besoins de leurs utilisateurs et apporter la bête de logiciel en ligne, beaucoup ne parviennent pas à prévoir les répercussions futures.

Nouveautés

La décision de mettre en œuvre une nouvelle version d'un paquet est beaucoup plus complexe, en raison des coûts élevés et une plus timeline. Dans une large mesure, de nouvelles versions doivent être traitées comme de nouvelles implémentations, pour inclure la conversion des données, mise à l'essai, test intégré, et l'acceptation de l'utilisateur. Sauf si il ya des changements importants en termes de fonctionnalités, le comme c'est , être , et l'analyse de l'écart de phases devraient pas être tenus. Après avoir navigué à travers la courbe d'apprentissage une fois, les utilisateurs doivent avoir besoin de moins de formation que dans la mise en œuvre initiale.

Ceci étant dit, à l'extrémité supérieure, la mise en œuvre d'une nouvelle version devrait être budgétisé à 50 pour cent de la projet initial. Si des améliorations majeures ont été apportées au logiciel de base, l'estimation pourrait augmenter à 70 pour cent ou plus, comme toutes les améliorations doivent être modernisés pour la nouvelle version et testé.

nouvelles versions, cependant, ne sont pas comme les nouveaux modèles de voitures, où vous voulez être le premier sur le bloc d'en avoir un. Sauf s'il ya une nécessité impérieuse pour la fonctionnalité ou à moins que le vendeur s'est engagé à une amélioration majeure dans le cadre du contrat de vente, la plupart des entreprises restent un communiqué derrière. Personne ne veut être à la pointe de la technologie ou de devenir un sujet de test pour les nouvelles fonctionnalités. Une bonne règle de base pour les entreprises qui souhaitent déployer la version actuelle est d'attendre après le premier service pack du logiciel est délivré. Même après une nouvelle version est disponible, les tests de fournisseur continue. Bien que n'étant pas présentant un haut degré de confiance dans les développeurs de logiciels, ce plan d'action est basé sur l'état de développement de logiciels et la ruée du fournisseur typique sur le marché.

Maintenance continue

Pas de discussion sur la mise à niveau vers une nouvelle version ne serait pas complet sans une mention de l'entretien continu et les frais connexes. Songez que, pour des raisons valables, votre entreprise passe continuellement sur la mise en œuvre de nouvelles versions. Vous devez vous demander: «Pourquoi rester à l'entretien?" Les entreprises devraient débattre de cette question chaque fois qu'une décision est prise de ne pas mettre en œuvre une nouvelle version, même après plusieurs packs de services sont délivrés. Pour les grandes entreprises avec des ressources informatiques adéquats, l'accès au code source et des connaissances dans l'utilisation des outils de développement, une réponse logique serait de laisser tomber l'entretien. Gardez à l'esprit que, même avec ces avantages, des questions telles que langues quatrième génération de systèmes et de technologies de base de données peuvent présenter des obstacles à un objectif d'autosuffisance.

petites et moyennes entreprises (PME) n'ont généralement pas de ces avantages. En outre, les PME sont souvent racontées par les vendeurs de paquets qu'ils n'ont pas besoin de personnel IT («Nous serons à votre personnel informatique"). En supposant que les PME rester sur le droit chemin indiqué par le vendeur, cela peut être vrai. Mais cette allégeance exige le paiement annuel d'entretien et de soutien. Par conséquent, partir entretien peut être une décision beaucoup plus déchirante pour les PME. Ignorant le fait que la nouvelle fonctionnalité sera peu probable, la gestion de l'environnement technologique pourrait être une préoccupation encore plus grande. Alors que certaines PME peuvent regarder une licence de maintenance comme une police d'assurance, une vision plus réaliste peut-être de le voir comme une garantie. Une police d'assurance peut vous donner de l'argent pour votre douleur et la souffrance. Une garantie comprend les pièces et main d'oeuvre à partir d'une source bien informée. Sans garantie, vous devez soit constamment négocier un temps et beaucoup de matériel avec le fournisseur du logiciel, ou de trouver une troisième sortie de la partie. En fonction de la popularité de votre colis, cette dernière option pourrait être extrêmement difficile.

Raison pour sauter par-dessus de presse

Les entreprises peuvent reporter la mise en œuvre d'une nouvelle version d'un progiciel ERP si aucune nouvelle fonctionnalité perçue est fournie. Cette retenue peut passer par plusieurs versions. Par exemple, une entreprise peut encore être sur la version 1.0 quand la version 4.0 (trois communiqués supprimés) devient disponible. Une pratique courante et contractuelles entre les éditeurs de logiciels est de soutenir la version actuelle et la version précédente. Pour notre exemple, la société, la version 1.0 n'est plus supporté. Ce qui aggrave encore le problème est que notre société hypothétique est probablement encore payer la pension alimentaire, mais pas en profiter.

sauter presse peut être un Catch-22 . Les entreprises pensent que en sautant un communiqué, ils sont eux-mêmes le temps, le coût et l'aggravation d'un projet de mise en œuvre d'épargne. Ce n'est probablement pas le cas. Comme indiqué plus haut, les nouvelles versions incluent de nouveaux éléments de données et de nouvelles fonctionnalités. Une entreprise devra exécuter les routines de conversion pour passer de la version 1.0 à la version 2.0, à partir de la version 2.0 à la version 3.0, et ainsi de suite. Les emplois doivent mettre en place, testés et fonctionnent. Il n'y a pas de gain de temps ici. Une nouvelle fonctionnalité n'a pas encore été mis à l'essai, testées et vérifiées. Lorsque poids variable (viande de volaille et des prix, par exemple, en poids réel, pas la taille du conteneur) a été introduit pour l'industrie alimentaire, de nombreux fournisseurs en œuvre cette fonctionnalité dans les phases dans leur précipitation sur le marché. La première phase (probablement dans la version 2.0 pour notre exemple) était de capturer poids variable comme nouvel élément de données. La deuxième phase (version 3.0) a été d'intégrer poids variable dans les routines de comptabilisation des coûts pour le matériel de production. La phase-version finale 4.0 était d'incorporer les maillons de la chaîne d'approvisionnement. Dans notre exemple de l'industrie alimentaire, il serait extrêmement prudent de vérifier l'exactitude des poids variable dans chaque version, car forte dépendance et des décisions de prévision seraient placés sur cette nouvelle fonctionnalité. Encore une fois, il n'y a pas de gain de temps ici. Des arguments similaires pourraient être faites pour les améliorations et les changements technologiques.

Sûrement certaines phases, notamment la formation, peuvent être éliminés ou considérablement réduits. Cependant, une entreprise se concentrera main-d'œuvre importante pendant une période prolongée de temps en traitant simultanément avec plusieurs versions. Il ya peut-être des facteurs accablants, comme le développement de nouveaux produits ou des programmes de marketing de pointe, qui n'entrent pas dans les limites d'un progiciel ERP. Ces facteurs peuvent nécessiter un retard dans la mise en œuvre d'une nouvelle version. Cependant, renoncer à ces facteurs, les compromis proposés en sautant les nouvelles versions ne justifient pas cette approche tactique.

conclusions et recommandations

Au moment d'entreprendre l'achat et la mise en œuvre de solutions globales échelle de l'entreprise, le projet va bien au-delà de la date de go-live. Même si la mise en œuvre initiale prend neuf mois, une entreprise doit s'engager pour le personnel et les plans de projet d'étirement plusieurs années dans le futur.

En supposant que des améliorations sont inexistantes ou mineures, des service packs devraient être traitées comme ils sont libérés. Les entreprises doivent être en mesure d'installer les service packs avec des tests minimaux et la formation des utilisateurs. Les Service Packs doivent résoudre les problèmes, pas en créer de nouveaux. Si ce n'est pas le cas, les entreprises devraient sérieusement envisager ce que les frais de maintenance annuels sont pour, et une réunion à cœur ouvert avec leurs fournisseurs de logiciels. Si des améliorations sont importantes, ils pourraient vouloir remettre en question leur choix de progiciel. En outre, le degré de difficulté et le temps de mise en œuvre des Service Packs dans ce scénario sera plus étroitement aligné sur celui des nouvelles versions.

De par leur nature et leur portée, une mise en œuvre d'une nouvelle version comporte un projet plus complexe, le calendrier, et l'utilisation des ressources que le Service Pack. Compte tenu de l'absence de conditions commerciales concurrentes et convaincante, de nouvelles versions doivent être budgétisés pour pas plus d'une par an. Si la rapidité des nouvelles versions est supérieure à une fois par an, le groupe d'utilisateurs a besoin de rencontrer et de remédier à cette situation avec le fournisseur du logiciel. Les entreprises ne devraient pas être un état continuel de mise en œuvre, même si ils ont formé une équipe de projet à cet effet. Si la nouvelle fonctionnalité est bien emballé, de nouvelles versions peuvent être programmées à des intervalles de dix-huit mois avec l'accord du groupe d'utilisateurs.

Comme cela a été discuté, en sautant et en combinant rejets peuvent pas livrer les avantages escomptés. Essentiellement, le gain de temps peut ne pas être significative. En outre, un projet visant à accueillir plusieurs versions aura un plus grand degré de difficulté. Ce fait est illustré dans le tableau ci-dessous.

Gestion des applications d'entreprise et les nouvelles versions correspondantes n'ya pas de «marcher dans le parc." Il suffit de mettre en œuvre de nouvelles versions est une pièce complexe et de longue haleine de la portée des responsabilités d'un département IT. De nombreux départements informatiques ne sont pas dotés de cette étendue, et d'oublier de budget et gère pour elle dans l'avenir. En conséquence, les entreprises prennent un regard fort à l'externalisation nouvelle gestion des versions ERP afin qu'ils puissent se recentrer leurs efforts sur des initiatives d'accroissement des recettes.

Comme les vendeurs ont commencé componentizing leurs suites logicielles, le paradigme appel de mises à jour gratuites est réévalué. S'éloignant de suites tout compris de logiciels, les fournisseurs de logiciels d'entreprise commencent à exiger des nouveaux frais de licence pour les nouveaux composants (ou fonctionnalités SOA) car ils sont développés. Comment ces éléments doivent être intégrés avec les suites logicielles existantes est de donner directeurs de l'information (DSI) plus de cheveux gris (du peu qu'ils ont à gauche). Beaucoup d'entreprises ne peuvent pas se permettre de passer à la version plus récente par composants des solutions logicielles des vendeurs, et s'ils le pouvaient, ils auraient à payer une nouvelle redevance pour leur difficulté. Cette transition peut forcer les entreprises à aller hors maintenance, via le raisonnement simple: «Pourquoi payer pour quelque chose que nous ne pouvons jamais avoir à utiliser?" Mais c'est une autre histoire pour un autre jour.

La ligne de fond est que la gestion des nouvelles versions et la mise en œuvre de logiciels échelle de l'entreprise doit être considérée lors de l'examen du justification de l'achat initial du logiciel coûtera. Cette considération ne sera pas nécessairement modifier votre décision de poursuivre une solution ERP, mais il va certainement modifier les calculs de retour sur investissement de (ROI) et de récupération ans.

Le tableau ci-dessous vous aide à évaluer le niveau d'effort requis selon le type de mise à niveau, et fournit un résumé global des cette note de recherche. Il reflète le temps nécessaire pour les améliorations de mise en conformité, puisque c'est directement proportionnelle à la difficulté et l'ampleur des améliorations. Le tel quel, à être, et les phases d'analyse des écarts devraient être achevés en revue les notes de version et ensuite prendre une décision si une analyse plus approfondie est nécessaire.

Les tâches d'exécution ont été attribués un degré d'activité faible, modéré ou élevé. Nous pouvons faire ces missions générales de l'effort:

  • faible activité nécessite une main-semaine ou moins d'effort.
  • nécessite une moitié de main-mois ou moins d'effort.
  • haute activité nécessite une main-d'œuvre mois ou plus d'effort.                 

Sur la base de ces travaux, à la fin faible pour une mise à jour du Service Pack dans un environnement peu ou pas amélioration, le projet peut être réalisé en un mois ou moins. En revanche, à l'extrémité supérieure, pour une nouvelle version dans une solution globale fortement renforcée, le projet peut prendre aussi longtemps que quatre mois. Mais n'oubliez pas que vous devez ajouter à l'effort de modernisation des améliorations, ce qui fait plus que doubler l'échéancier du projet. Utilisez ces estimations comme un guide pour effectuer un test raisonnable de votre projet.                     Enfin, certains d'entre vous diront peut-être que les concepts évoqués dans cette note de recherche est plus facile à dire qu'à faire. Nous sommes totalement d'accord. Toutefois, si vous définissez les attentes de la communauté des utilisateurs à l'avance, que l'implémentation d'un package échelle de l'entreprise n'est pas un "one et fait" du projet, et décrire clairement les pièges de ne pas appliquer ou de sauter les prochaines versions, vous pouvez vous trouver plus près de la cible souhaitée.

propos des auteurs

Joseph J. Strub possède une vaste expérience en tant que chef de projet senior et consultant pour la planification et l'exécution de projets ERP pour les systèmes de fabrication et de distribution, pour les grandes et moyennes entreprises dans les détail, de la nourriture et des boissons, des produits chimiques, et les consommateurs des produits emballés (CPG) les industries de process. Il a développé des programmes de marketing et de communication pour les organisations informatiques et consultés sur off-shore, l'externalisation des opportunités pour les entreprises multinationales. En outre, Strub a été consultant et auditeur des systèmes d'information avec PricewaterhouseCoopers , et un développement d'applications et le soutien gestionnaire pour plusieurs sociétés Fortune 100. Actuellement, Strub est un consultant indépendant. Il peut être contacté à JoeStrub@WriteTechnologyPlus.com.

Predrag Jakovljevic est un analyste principal de la technologie de Evaluation Centers ( TEC ), avec un accent sur le marché des applications d'entreprise. Il a près de vingt ans d'expérience dans l'industrie manufacturière, dont plusieurs années en tant qu'utilisateur de puissance de l'informatique / ERP et les applications connexes, ainsi que d'être un consultant / exécutant et analyste du marché. Il détient un baccalauréat en génie mécanique de l'Université de Belgrade (Serbie [l'ex-Yougoslavie]), et a également été certifié dans la production et la gestion des stocks (CPIM) et la gestion intégrée des ressources (CIRM) par APICS .

 
comments powered by Disqus


©2014 Technology Evaluation Centers Inc. All rights reserved.