Accueil
 > Rapports de TEC > Blogue de TEC > Si vous modifiez un produit d'application?

Si vous modifiez un produit d'application?

Écrit par : Olin Thompson
Date de publication : juillet 18 2013

Si vous modifiez un produit d'application?

Ce serait bien si off-the-shelf produits d'application seraient satisfaire tous les besoins d'affaires de chaque entreprise. Cependant, que ce soit SCM, ERP, CRM, BI ou toute autre catégorie de produits d'application, ce n'est pas la façon dont il est. De nombreuses entreprises constatent que certains besoins ne sont pas satisfaits, ils ne peuvent pas vivre avec une version plain vanilla du produit. Si c'est votre cas, vous devez modifier le paquet pour répondre à ces besoins? Est-ce la douleur vaut le gain?

Qu'est-ce qu'une modification? Une modification est un code écrit pour obtenir une application d'exécuter différemment de ce que le vendeur destiné. Il peut faire face à l'écriture de code dans les programmes livrés par le vendeur ou il peut s'agir de code externe à ces programmes. Parfois, les modifications comprennent l'ajout de nouveaux champs à la base de données.

Do "cosmétique modifications" count? Ce sont les modifications apportées aux écrans, des rapports ou des flux de travail qui n'ont pas d'impact de la logique ou de la base du produit. Si ces changements cosmétiques signifier que vous avez à faire un peu de travail à refaire ou de tester les changements cosmétiques lorsqu'une nouvelle version arrive, les mêmes problèmes se posent - ils comptent comme des modifications

.

modifications doivent être évités

Commençons la discussion par une idée fondamentale: modifications doivent être évités. Modifications signifient que le soutien du fournisseur peut être plus difficile, voire sans valeur. Modifications signifie que l'acceptation de nouvelles versions du fournisseur sera plus difficile, tant en termes de temps et de coût. Modifications signifient que le système est plus sujette aux erreurs. Modifications signifient que le coût à long terme de la propriété sera plus élevé. Les modifications doivent être évités.

regardant modifications en termes financiers se penche sur une question de responsabilité. Ce n'est pas le type de responsabilité qui se termine sur le bilan de l'entreprise. Toutefois, il s'agit d'une responsabilité qui est tout aussi vrai. Temps et d'argent devront être passé à l'avenir pour une décision de la modification apportée aujourd'hui. Définir l'ampleur de la responsabilité va être et de penser d'elle comme si elle était sur le bilan permet à la direction dans ces décisions importantes.

nombreuses implémentations commencent par une politique absolue aucune modification! C'est très bien si elle peut être respecté. Cependant, ce sont une petite minorité de toutes les implémentations. La politique absolue finit à quelques exceptions près. Le résultat de la politique absolue est toujours très positif, il minimise le nombre et la complexité de ces modifications qui ne finissent par être fait.

Le pourquoi des modifications

Alors, pourquoi une entreprise d'envisager de modifier un produit d'application? La réponse est que, parfois, il doit l'être. Mais pourquoi il doit être n'est pas noir et blanc. Qu'est-ce qu'un "must-have" pour une entreprise serait même pas être envisagée dans un autre. Quels sont les différents types de besoins qui peuvent résulter d'une décision visant à modifier et comment peut-on les hiérarchiser?

Quelques processus d'affaires ou conventions sont pratiques de l'industrie. Ces processus ou conventions sont la conduite des affaires dans ce secteur et ne pas avoir la capacité de suivre les signifierait ne pas être capable de faire des affaires. Ces processus d'affaires ou conventions sont essentiels à la mission.

Si vous vous trouvez face à ce type de problème, il est possible que vous n'avez pas sélectionné le produit de l'application droite. Si le «focus» d'un fournisseur sur votre type d'industrie est quelque chose au-delà d'un site Web ou une brochure, ils doivent fournir des fonctionnalités standards qui traitent de la pratique de l'industrie. Mais si vous trouvez que votre produit d'application sélectionné ne répond pas à vos besoins spécifiques de l'industrie - une modification est plus que justifiée, il est impératif. Ce type de modification doit être effectuée avant l'application peut être mise en œuvre.

autre cause de la nécessité d'une modification, c'est quand il ya un processus d'affaires unique pour votre entreprise, et donc pas assuré par le produit de l'application. Dans ce cas, vous devez tenir compte de l'importance de ce processus unique est à votre entreprise.

Si le processus vous donne un avantage stratégique, il peut être intéressant de la douleur de la modification de préserver l'avantage. Ce n'est pas une décision de bas niveau: il traite de la stratégie concurrentielle. La valeur de l'avantage compétitif par rapport au coût à long terme de la modification doit être évaluée. Certains de ces processus sont essentiels à la mission et de servir avantages essentiels sur le marché. Habituellement, ce type de modification doit être effectuée avant l'application peut être mise en œuvre.

Si un processus est "juste la façon dont nous le faisons», alors la valeur peut être remise en question. La plupart des dossiers de demande sont des combinaisons de meilleures pratiques acquises en travaillant avec de nombreuses entreprises différentes. Il est rare que le procédé unique pour une entreprise d'être vraiment plus précieux que ceux disponibles dans le dossier de demande standard. Souvent, ces types de situations deviennent plus difficiles à déterminer. Certains utilisateurs puissant ou groupe d'utilisateurs insiste sur le fait que la modification est nécessaire. Une approche réussie pour traiter de cette question n'est pas de dire «non», mais de dire «plus tard».

Une stratégie qui met en œuvre le produit standard et reporte toutes les modifications non critiques pour une période de quelques mois après la date de mise en entraîne beaucoup d'entre eux "juste la façon dont nous le faisons" modifications tomber l' liste. Les utilisateurs commencent à utiliser les outils disponibles dans le package standard et après quelques mois d'utilisation, ce qui était important pour eux auront changé. Si, après quelques mois d'utilisation, existent encore à ces exigences, peut-être qu'ils sont essentiels à l'entreprise.

le comment des modifications

Une fois qu'une décision est prise de modifier une trousse de demande, comment elle est entreprise peut avoir un impact majeur sur le coût à long terme de la propriété du package modifié. Il ya de bons, mauvais et laid approches.

une bonne approche : Autant que possible, les modifications devraient avoir lieu extérieur au code ou base de données du fournisseur. L'utilisation des exits utilisateur, de l'API, etc ou la mise en œuvre des programmes de pré ou de post-traitement d'isoler l'impact de la modification. En utilisant les champs de base de données fournis par le vendeur (champs définis par l'utilisateur) ou tag-along fichiers peut également être considéré modifications extérieures. Quand une nouvelle version arrive, les modifications externes doivent encore être testés, mais le coût et le risque est relativement faible. En termes de modifications, si elles doivent exister, cette approche est une bonne chose.

une mauvaise approche : Si l'approche externe s'avère impraticable, alors quelque chose doit être fait dans le code ou base de données du fournisseur. Si la modification est limitée à l'ajout d'un bloc de code pour le programme du fournisseur, de l'effort en acceptant une nouvelle version devient l'un des ajoutant le code de la nouvelle version et les tests. Ajout d'un bloc de code n'est pas bon, il est mauvais, mais il est parfois inévitable.

Une approche laid : Le laid du monde de la modification est effectivement en train de changer le code ou les fichiers du fournisseur. En général, les produits d'application sont très complexes. Ils doivent répondre aux besoins de nombreuses entreprises différentes et ont donc logique complexe pour déterminer comment un programme fonctionnera dans une entreprise ou une mise en œuvre spécifique.

Ce que l'on programme fait et comment il le fait, peut influer sur la façon dont les autres programmes de travail. Cette complexité conduit à un risque élevé dans les modifications apportées au code. Quand une nouvelle version arrive, réappliquer les modifications peuvent nécessiter une analyse complète de ce que le vendeur a fait au programme. Cela peut signifier une nouvelle façon de modifier le code pour obtenir le même résultat. Cela signifie que les tests très vaste, non seulement pour le programme en question, mais aussi pour l'ensemble du système. Changer le code du fournisseur est laid.

Résumé - Avoir les yeux ouverts

sont des modifications mauvais? La réponse est oui. Sont modifications justifiées, la réponse est parfois. Le processus de décision doit se concentrer sur les avantages commerciaux par rapport au passif à long terme de faire la modification. Une politique absolue de pas de modifications est un point de départ qui travaillent, mais les besoins de l'entreprise créent souvent des exceptions à cette règle. Faire des exceptions avec les yeux ouverts. Ouvert aux besoins de l'entreprise et d'ouvrir le coût à long terme de la propriété.

propos de l'auteur

Olin Thompson un directeur de Process ERP Partners. Il possède plus de 25 années d'expérience en tant que cadre dans l'industrie du logiciel avec le dernier 17 dans l'industrie des processus liés ERP, SCP, et les segments connexes e-business. Olin a été appelé «le Père des processus ERP." Il est un auteur et un conférencier fréquemment primé sur des sujets d'acquisition d'une valeur de l'ERP, SCP, e-commerce et de l'impact de la technologie sur l'industrie.

Il peut être contacté à Olin@ProcessERP.com.

 
comments powered by Disqus


©2014 Technology Evaluation Centers Inc. All rights reserved.