Quel est le problème avec le logiciel d'application? Changements d'affaires, logiciel doit changer avec l'entreprise.

  • Écrit par : Olin Thompson
  • Date de publication : Juillet 18 2013



<

Premise

changements d'affaires   constamment dans de petits moyens et grands. Il est rare de trouver un produit d'application   qui peut changer une fois qu'il est mis en œuvre. Cet écart est une réalité qui conduit à l'insatisfaction   et l'application étant un frein à l'entreprise. Cette lacune, l'absence de l'   capacité de changer, coûte à l'entreprise chèrement. Le logiciel doit être l'agent   de changement, pas l'ennemi du changement.

changement   Arrive

  sont de plus en plus prendre de nouveaux modèles d'entreprise et des processus métier comme un   façon continue à déjouer la concurrence. Ces entreprises ont constaté que   il ya un conflit inhérent entre la fluidité et l'agilité avec laquelle ils   vouloir faire fonctionner leurs entreprises et de la rigidité et de contrôle avec laquelle les systèmes de   fonctionner. Cette incompatibilité entre les entreprises agiles et les systèmes statiques a   entravé les efforts pour changer l'entreprise efficacement et rapidement pour capitaliser   sur les opportunités d'affaires. Si une société est agressif dans son adoption de   changement ou conservateur, le changement est inévitable et permanente.

il existe un écart entre   le changement nécessaire par l'entreprise et la capacité de l'architecture d'entreprise   à recevoir, ou de faciliter ces changements.

Quel est le coût   associée à cette lacune? Les coûts de ne pas être en mesure de changer sont réels, mais   difficile à calculer. Combien ça coûte une société où la satisfaction du client   érode? Quels sont les coûts lorsque la société ne peut pas répondre aux pressions de la concurrence?   Quel est le coût des solutions de contournement manuel ou semi-manuel en termes de temps, le manque   de l'intégration, de responsabilisation, qualité, etc? Quel est le coût du service informatique   et IT direction étant considérée comme un obstacle au déplacement de l'entreprise vers l'avant?   Ces coûts sont réels et importants.

les efforts de l'industrie du logiciel à s'adapter aux changements

Le besoin de changement   n'est pas nouveau pour l'industrie du logiciel. L'ennemi du changement a toujours été le coût,   temps et de qualité; ces obstacles vont se poursuivre. Des tentatives ont été faites dans   le passé pour surmonter ces obstacles dans les limites pratiques de la technologie   disponibles à l'époque.

L'état actuel   du marché est celui des applications «standard configurables". L'hypothèse est que   applications logicielles standard peuvent apporter les meilleures pratiques pour une entreprise et être   fait suffisamment souple pour s'adapter à la majorité des entreprises sans significatif   modification. Grâce à l'utilisation des tables et des commutateurs complexes, le logiciel pourrait   être pré-configuré pour traiter un grand nombre de pré-déterminés, les options «flexibles».   Mais en vérité, la flexibilité est seulement de choisir parmi une liste d'exister, prédéterminé   options. Si l'option souhaitée n'existe pas, il n'y a pas une réelle flexibilité   disponible. Si une décision est prise sur laquelle des options est le meilleur, et que la décision   doit être modifiée à l'avenir, que la flexibilité est souvent inexistante.

Cependant, cette approche   est venu avec des coûts très lourds en termes de la complexité croissante des logiciels   code, qui a conduit à la qualité irrégulière, mise en œuvre complète des délais, et   difficultés à changer le logiciel une fois mis en œuvre. La question de la flexibilité   a été résolu pour une mise en œuvre initiale, mais l'innovation des entreprises en cours était   non prise en charge. Les modèles de logiciels et d'outils de mise en œuvre rapides ont contribué à résoudre   le problème des longues implémentations en raison de tables et de commutateurs complexes, mais   ils n'ont rien fait pour résoudre le problème sous-jacent de devenir inflexible après   mise en oeuvre.

Un objectif clé   d'applications «standard configurables" était d'éliminer la nécessité d'apporter des modifications.   Bien que cela ait été le but déclaré de nombreuses entreprises, les statistiques prouvent   qu'il n'est pas, en effet, comment la majorité des entreprises sont en cours d'exécution. Un Octobre   Enquête de 2002 sur Pulse par ERP Toolbox (http://ERP.ITtoolbox.com)   a révélé que 42,16% des clients planification des ressources d'entreprise (ERP) avait modifié   leurs systèmes "beaucoup". La vérité sur l'application logicielle standard   est que très peu d'entreprises fonctionnent vraiment comme des produits standards.

Aujourd'hui, la capacité   pour les systèmes d'application pour soutenir l'entreprise à rester compétitive en général   consiste à travailler autour du système et d'attendre la prochaine version, ou la mise en œuvre   un système redondant qui prend le dessus sur le système ERP de base. Cela laisse entreprises   un désavantage concurrentiel parce qu'ils sont constamment souffrant soit   le coût d'opportunité de ne pas changer l'entreprise, ou le coût opérationnel de   travailler autour du système, et souvent une combinaison des deux. En outre, le noyau   objectifs de l'installation d'un système ERP en premier lieu (meilleures pratiques, l'intégration,   etc) sont contestées au fil du temps.

SAP, le plus grand   fournisseur d'applications d'entreprise packagées, a annoncé la formation de leur   nouveau personnalisée Organisation Development Services (CDAS) lors de leur récente   Conférence utilisateurs européenne en Septembre 2002. La mission officielle de cette organisation   est de répondre aux besoins de personnalisation de ses plus gros clients. Il semble, en effet,   que même les plus grands clients utilisant des logiciels à partir du plus grand fournisseur requièrent   personnalisation.

Les "aucune modification"   hypothèse est l'un des plus fondamentaux réalisés par les entreprises sur leur entreprise   applications. La plupart des fournisseurs de l'entreprise croyaient l'hypothèse "sans modifications"   quand ils architecturés leurs produits. Cette hypothèse est fondamentalement faux.

Que devons-nous?

La prochaine génération   de l'architecture d'entreprise doit permettre le changement de l'entreprise à adopter sur un   base à la demande que l'entreprise évolue. Comme nous le disions dans Quoi   Le problème avec le logiciel d'application? C'est l'économie architecture d'entreprise   doit fournir le coût, le temps et les caractéristiques de qualité pour faire changer une pratique   choix pour l'entreprise.

class="articleText">

    Les entreprises     Changement de     Modification     Modifications
Abaissez le       sanctions en cas de modifications Aujourd'hui, l'       sanctions en cas de modification sont si élevés que les entreprises éprouvent des difficultés à       justifier tout mais les changements les plus importants. Avec la chute du coût,       temps, et les pénalités de qualité, il devient de plus en plus pratique pour le système       de répondre aux besoins de l'entreprise.
offrent une flexibilité       pour les options non initialement conçu par le vendeur       besoin de meilleures pratiques, mais ils doivent aussi «notre pratique» et la       capacité à répondre aux besoins des clients et d'autres. Si le vendeur a       ne se construit pas dans l'option, la société devrait être toujours être en mesure de fournir       la fonction requise.
sur       demande Le changement       processus devrait être rapide et indolore. Le délai entre la nécessité et la solution       doit être minimisé.
Fournir possible       petites modifications ainsi que de grandes       projets sont souvent très volumineux, mais pour être réactif, le système doit être       économiquement changé pour les petites et grandes exigences.
contrôlée       processus de changement Le changement       processus doit être un processus contrôlé solide avec construit dans la gestion et       qualité.
Fournir l'       visualisation de l'utilisateur de l'entreprise et l'évaluation des éventuelles modifications Aider l'       utilisateur de l'entreprise à comprendre ce que le système va ressembler et comment elle       fonctionner après le changement pour éviter les surprises, la reprise, et à la poursuite utilisateur       acceptation.
Évaluer et       localiser l'effort de changement Le plein impact       de toute modification doit être connue à l'avance. Cela inclut l'impact sur l'       système et le coût et le temps requis pour effectuer le changement. Ces informations       augmentera le processus de gestion et d'éviter les surprises
continuellement       maintenir la version "tel qu'il est installé» du système Tout changement       devrait être reflété dans le «système global», y compris la documentation,       manuels de l'utilisateur, le texte d'aide, etc
durable       améliorations de produits       devrait être maintenable à l'avenir pour évoluer avec les besoins de l'entreprise       et les progrès réalisés par le vendeur.
Intégrer       l'acceptation de nouvelles versions des fournisseurs avec des modifications nouvelles versions       du fournisseur viendra et toute modification doit être facilement ré-évalué       et une nouvelle demande le cas échéant à la fois réaliste, le coût et la qualité.

Résumé

changement se produit.   Il sera toujours continuer à se produire. Un système devrait être une aide à l'évolution de la   entreprise, pas un obstacle à surmonter telle qu'elle est aujourd'hui. L'architecture d'entreprise Future   devrait accepter et aider à la réalité que les changements d'affaires et des logiciels doit   changer avec l'entreprise.

propos de l'   Auteur

Olin   Thompson est un dirigeant de processus ERP Partners. Il a plus de vingt-cinq   ans d'expérience en tant que cadre dans l'industrie du logiciel. Thompson   a été appelé «le Père des processus ERP." Il est un auteur fréquentes et un   primé conférencier sur des sujets d'acquisition d'une valeur de l'ERP, SCP, e-commerce,   et l'impact de la technologie sur l'industrie.

Il   peut être atteint à Olin@ProcessERP.com.   

 
comments powered by Disqus