Accueil
 > Rapports de TEC > Blogue de TEC > Où est dirigé ERP (ou mieux, Où devrait-il être dirigé)? ...

Où est dirigé ERP (ou mieux, Où devrait-il être dirigé)? Partie 2: L'architecture du produit et Web-Basing

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

Where Is ERP Headed
(ou mieux, Où devrait-il être dirigé)?

Partie 2: l'architecture du produit et Web-Basing PJ Jakovljevic - 20 Avril 2001

Résumé

Un système typique ERP offre désormais une large couverture fonctionnelle approchant les capacités best-of-breed, extensions verticales de l'industrie; une architecture robuste technique, la formation, la documentation, la mise en œuvre et des outils de conception de processus, l'amélioration des produits, le soutien global et une longue liste de logiciels, de services et de partenaires technologiques. Même s'il n'est pas un système-in-a-box encore, l'écart entre les fonctionnalités souhaitées et réelles se rétrécit chaque jour.

éditeurs d'ERP, d'autre part, ne font pas si bien, peut-être parce qu'ils ont été occupés à développer, acquérir, ou de regroupement de nouvelles fonctionnalités ainsi que leurs paquets vont au-delà des domaines traditionnels de la finance, des matériaux et la planification la gestion et les ressources humaines.

Les visions de l'ERP

des utilisateurs évoluent de tactique à stratégique, et les utilisateurs ne sont plus disposés à choisir entre l'intégration et la fonction. Au cours des deux prochaines années, ERP sera redéfinie comme une plate-forme pour permettre à l'e-business dans le monde.

conséquent, les utilisateurs doivent être conscients des tendances dans le marché de l'ERP afin qu'ils puissent prendre en compte tous les facteurs nécessaires lors d'une sélection de logiciels ERP: la fonctionnalité du produit, les exigences technologiques des produits, la stratégie d'entreprise du fournisseur, et le fournisseur viabilité de l'entreprise.

Cette partie explique comment un système ERP flexible et agile a besoin d'une architecture adaptable et la facilité d'intégration aux applications 3rd-party est devenu un argument de vente clé pour les éditeurs d'ERP. Aussi avec un Internet-seul système ERP en place, les mises à niveau de logiciels côté client deviennent les applications inutiles, basés sur navigateur simplifient considérablement la formation et attachant ensemble des endroits éloignés d'une entreprise devient plus simple aussi. Pour ce faire, d'une manière appropriée, les éditeurs d'ERP doivent repenser complètement leurs applications pour un environnement e-business true, ce qui nécessite des ressources et un engagement.

propos de cette Note

Ceci est une note de quatre parties, dont chaque partie couvrant deux des huit tendances que nous avons identifiées. Chaque partie contient des liens vers les parties précédentes. Les tendances couverts dans chaque partie sont les suivants:

Partie 1:
  • ERP Functional Portée Expansion
  • Davantage l'accent vertical
Partie 2 :
  • Flexibilité, l'agilité et l'interopérabilité Activé par une architecture adaptable
  • Web-Baser des ERP Systems |
Partie 3:
  • Fourniture d'éléments e-Répertoire d'entreprises
  • Shakeout Mid-Market
Partie 4:
  • Avent de Application Hosting Services
  • Nouvelle tarification modèles

3 - flexibilité, l'agilité et l'interopérabilité Activé par une architecture adaptable

Le rythme rapide du commerce mondial met aujourd'hui un ensemble unique de défis sur les entreprises qui cherchent à améliorer et à automatiser leurs opérations, et en même temps, reste prête à s'adapter rapidement aux changements. Avec une concurrence accrue, la déréglementation, la mondialisation et des fusions et d'acquisitions, les acheteurs se rendent compte de plus en plus que l'architecture joue un rôle clé dans la rapidité avec laquelle les fournisseurs peuvent mettre en œuvre, maintenir, développer / adapter et d'intégrer leurs produits. Le produit l'architecture va faire beaucoup plus que simplement fournir la fonctionnalité, l'interface utilisateur, et le support de plate-forme. Il va déterminer si un produit va durer, si elle va évoluer pour un grand nombre d'utilisateurs, et si elle sera en mesure d'intégrer les nouvelles technologies, le tout afin d'accommoder l'augmentation des besoins de l'utilisateur.

Une architecture adaptable est le plus petit dénominateur commun pour un système ERP flexible et agile. Bien qu'une composante - base l'architecture n'est pas une obligation explicite pour les ERP flexibilité, les applications à base de composants offrent généralement une plus grande flexibilité que leurs homologues monolithiques. D'autres conditions préalables à la flexibilité sera l'abstraction de la complexité technique (qui se manifeste par l'utilisation d'outils intuitifs, le SIDA ou assistants qui guident les utilisateurs dans un ensemble de mesures pour parvenir à un résultat final souhaité), la messagerie intelligente et architectures de workflow et une interface intuitive, facile à utiliser l'interface utilisateur.

Componentisation réfère à l'acte de la rupture grands systèmes ERP monolithiques en modules ou composants qui travailleraient ensemble individuels. Il s'agit de la réalisation pratique de la programmation orientée objet (POO). Conception de logiciels orientés objet et la programmation ont été développées pour améliorer la maintenabilité du logiciel et de simplifier la création d'interfaces graphiques avancées (GUI). L'orientation objet signifie que la conception, liens, etc, l'utilisation objets que leurs blocs de construction de base, qui est un changement radical de la conception traditionnelle «procédurale» et les méthodes de codage.

Une classe d'objets est une combinaison de données et la logique de traitement. Les données d'une classe peuvent correspondre à une table de base de données relationnelle, mais ce n'est pas nécessairement le cas. La logique de traitement entre les méthodes, qui sont similaires aux sous-routines ou des procédures. En maintenant la logique de traitement avec les données qu'il travaille avec, les programmeurs ont plus de facilité à trouver des pièces réutilisables. Par conséquent, les systèmes orientés objets peuvent être nettement plus petit et plus facile à entretenir que le code de procédure classique dans laquelle les procédures et les données sont séparés.

architecture basée sur des composants

En décomposant les grandes applications dans les composants, les fournisseurs sont en mesure de résoudre plus rapidement ou ajouter des fonctionnalités. Un composant peut être quelque chose d'aussi simple qu'une fiche fournisseur, ou un processus métier plus complexe ou de workflow. La composante des comptes créditeurs, par exemple, pourrait être améliorée sans avoir à toucher d'autres éléments financiers ou l'un des autres modules, tels que la planification ou la logistique. Et une fois que le fournisseur d'ERP a mis en place l'architecture de composants, il devient plus facile et plus sûr pour l'informatique de personnaliser les systèmes.

Componentisation s'avère cruciale pour permettre aux systèmes ERP pour soutenir l'activité e-business depuis les nouvelles fonctionnalités e-commerce sont fournis en tant que composants individuels. Componentisation aide également les fournisseurs étendre le système ERP central avec SCM, CRM, ERP et autres solutions adjacents.

intérêt dans componentization, cependant, a commencé longtemps avant de e-commerce. La perception à l'époque était que les applications ERP étaient trop gros et lourd, et qu'ils devaient être plus souples. Componentisation ne serait pas seulement le rendre plus facile pour les éditeurs d'ERP pour améliorer leurs solutions mais aussi rendre plus facile pour les clients de mettre à niveau le logiciel. Avec componentization, un client peut progressivement mettre à jour uniquement les composants sélectionnés sans avoir à installer la solution ERP complet, qui serait normalement entraîner un effort substantiel.

En résumé, l'architecture à base de composants est bénéfique pour les raisons suivantes:

  1. Il permet à un développeur de créer une application composite dans lequel généralement une interface utilisateur basée sur le Web accède à la fonctionnalité de l'application packagée.
  2. Il peut permettre l'intégration de message broker basé sur plusieurs paquets disparates ou les systèmes hérités.
  3. Il permet à un fournisseur de déployer de nouvelles versions de l'application dans un mode incrémental modulaire plutôt qu'en une seule fois.
  4. Il peut réduire considérablement le code de l'application totale.

Componentisation est donc nécessaire pour les fournisseurs de déplacer leurs systèmes ERP dans le e-business et de fournir d'autres capacités et donc la plupart des vendeurs insistent sur le fait qu'ils restent totalement engagés à lui, même si des progrès ont été modérés. La raison à cela réside dans le fait que componentization est extrêmement difficile à atteindre, même si l'engagement est solide. À quelques exceptions honorables, la plupart des fournisseurs de niveau 1 ont pour la plupart réussi à créer des composants propriétaires à gros grains, qui sont des modules fonctionnels simplement grands. D'autre part, IFS mène la meute des éditeurs d'ERP mid-market agiles plus qui ont entièrement ou dans une large mesure par composants de leurs produits.

mise en œuvre d'une architecture entièrement basée sur des composants nécessite que les fournisseurs refonte complète de leurs applications, puis le réécrire en C + +, Java, ou un L4G à base de composants, et de l'exécuter sous le modèle d'objet composant (COM), Common Object Request courtier architecture (CORBA). NET (dans le futur) ou Enterprise JavaBeans (EJB). Certains fournisseurs qui avaient tenté cette approche ont connu une poignante, de temps et de ressources consommatrice, make-or-break transition. Nous croyons que moins de 45% des fournisseurs de systèmes ERP livrera une architecture entièrement basée sur des composants au cours des quatre prochaines années (70% de probabilité). Nous pensons également que les premiers fournisseurs qui livrent un véritable système ouvert et modulaire permettra de saisir la part du lion du marché de l'ERP non pénétré restant.

interfaces ouvertes et une meilleure intégration

Alors que les clients ERP peuvent ne pas être pleinement conscients des avantages de componentization encore, ils ont été embrassant les interfaces plus ouvertes et les capacités d'intégration améliorées que les vendeurs qu'ils fournissent, les capacités aussi destinés à l'effort de componentization.

Au cours des dernières années, les éditeurs d'ERP ont ouvert leurs modules étroitement imbriqués et créé des interfaces de programmation d'applications (API) pour se connecter à des systèmes best-of-breed 3rd-party. Fournisseurs de systèmes ERP offrent un large éventail de schémas d'intégration ouverts, y compris langage de balisage extensible (XML) de messagerie et connecteurs propriétaires ou des API ouvertes, depuis l'intégration facile aux applications 3rd-party est devenu un argument de vente clé pour eux.

SAP, par exemple, a créé plus de 1.000 interfaces de programmation d'applications d'entreprise (BAPI) pour une utilisation dans l'intégration de produits tiers avec le système ERP central ainsi que des applications de liaison activation (ALE) via des documents d'interchange (IDOC) , les formats de fichiers plats standard pour les échanges d'information commun. Cela nécessite des API ouvertes pour permettre l'intégration d'outils d'analyse tiers communication des données et ainsi que d'autres outils d'extension ERP mentionnés ci-dessus.

lieu du coûteux, risqué à plein componentization, la plupart des éditeurs d'ERP ont choisi une approche plus sûre. Ils utilisent des API à base de composants pour construire une «façade» pour leur application existante. Quand cela est fait correctement, ces API donnent accès programmatique aux objets métier communs (par exemple, un ordre, un partenaire d'affaires, un accouchement), qui sont mis en correspondance avec la fonctionnalité de l'application existante d'une manière que les utilisateurs de boucliers de la complexité du code sous-jacent. Toutefois, les API ne sont pas suffisantes. Pour combler la sémantique différentes et des processus d'affaires activés au sein de chaque demande participant dans un environnement ERP étendue, fournisseurs ou utilisateurs doit employer la technologie de courtier de messages (un outil de préférence 4GL spécifique qui peut facilement transformer et acheminer des données comme il se déplace entre les applications) .

répercussions de cette tendance

Malgré la préférence de l'utilisateur pour un seul vendeur, 'boutique one-stop », les produits logiciels par composants, des normes d'interopérabilité et de la technologie de l'Internet va conduire à moins de projets à grande échelle et un flux continu de petits. Facilité d'intégration aux applications 3rd-party est devenu un argument de vente clé pour les éditeurs d'ERP comme ainsi beaucoup d'entre eux vantent la fourniture de connecteurs vers / à partir de leurs systèmes et / ou la fourniture d'outils de développement d'intégration (par exemple, Forte ou Progress Software ). Toutefois, les utilisateurs doivent vigoureusement en question leurs fournisseurs d'applications d'entreprise potentiels ce qui suit:

  • Quelles sont les normes d'interopérabilité de l'industrie (par exemple, ouvrir des applications Groupe spécifications d'intégration (OAGIS), XML, etc) sont pris en charge?
  • Ce qu'ils fournissent interface flexible basée sur le message ou une intégration rigide à base de code?
  • Ce qu'ils fournissent des interfaces batch terme de base ou, interactifs connexions bidirectionnelles temps réel les plus avancées entre les applications?

4 - Web-Baser des systèmes ERP

Indiscutablement, l'une des tendances les plus importantes dans le marché de l'ERP est aujourd'hui l'avènement de l'e-business. Aucun secteur n'est pas affecté par les changements créés par le développement explosif de l'Internet, malgré le récent enthousiasme dégonflé et le sentiment négatif du marché en raison d'un effondrement des sociétés point-com, le ralentissement économique et la paralysie des valeurs technologiques. Comme la réalité de permettre transparente collaboration basée sur le Web entre les entreprises et leurs clients et fournisseurs devient de plus d'une réalité chaque jour, les applications ERP sont prêts à jouer un rôle central. Le concept de l'e-commerce n'est pas vraiment nouveau à l'ERP: échange de données informatisé (EDI) et le transfert électronique de fonds (TEF) ont été une partie d'applications ERP sous diverses formes depuis des années, et sont maintenant en train d'être redéfini (et donné une cure de jouvence en même temps) pour embrasser l'Internet et le Web.

Extension ERP à l'Internet découle de l'intention de nombreuses organisations IT de ne pas réinventer la roue dans leur ruée pour créer des applications e-commerce. En étendant le système ERP existant pour soutenir l'e-commerce, les organisations non seulement tirer parti de leur investissement dans la solution ERP, mais peut aussi accélérer le développement de leurs capacités de commerce électronique. Cependant, comme mentionné précédemment, les systèmes ERP sont révélés difficiles à modifier et à étendre.

barricade derrière complexe, des API propriétaires et basé sur, presque indéchiffrables schémas de bases de données relationnelles complexes, les systèmes ERP ne prennent pas facilement à l'e-commerce. Néanmoins, les responsables informatiques sont de trouver un ensemble croissant d'options pour non seulement étendre ces systèmes pour soutenir le Web et e-commerce, mais pour d'autres activités clés, comme aide à la décision. Sous-tendent les nouvelles options initiatives sont en cours pour briser les systèmes ERP en éléments séparés (componentization), ouvrez les bases de données de base et des interfaces d'applications propriétaires, et fournir des outils pour la personnalisation.

Les principaux éditeurs d'ERP ont essayé de la demande des utilisateurs pour obliger les capacités de commerce électronique dans leurs solutions ERP. La première étape dans la conquête du Web de l'ERP était de permettre l'accès au navigateur à travers un soutien pour le protocole HTTP, HTML et Java. Cette étape de l'ajout de la couche d'accès au Web sur les systèmes client / serveur existantes, est pratiquement achevée par la majorité des éditeurs d'ERP. C'est, cependant, qu'une solution à court terme, parce que tant la nature de l'interaction et le genre de désinvolture visite e-utilisateurs sont différents par rapport à traditionnel en interne puissance interactions du système des utilisateurs.

La prochaine étape, qui a commencé récemment, est d'étendre les applications ERP eux-mêmes sur le Web, où ils peuvent être consultés et gérés par des partenaires et des clients extérieurs. Ces applications Web sont hybrides en forme, rassemblant des éléments hérités propriétaires, interfaces basées sur un navigateur via un hôte centrées ou client / serveur, avec client léger. Le hic, c'est de mettre sur le Web des fonctionnalités avancées des systèmes ERP, mais divisé en composants et sans avoir besoin d'une couche supplémentaire de l'architecture. Certains fournisseurs ont également commencé à ajouter des crochets de mobilité dans leurs suites ainsi que des séances d'ERP peuvent être accessibles via des dispositifs sans fil.

Pour que les systèmes ERP traditionnels pour être prêt pour Internet, ils devront être:

  1. Entièrement navigateur activé.
  2. Repensé pour être accessible à tous les utilisateurs de l'entreprise, et pas seulement quelques-uns spécial.
  3. Repensé pour être disponible pour les clients et les fournisseurs.
  4. Repensé pour utiliser un langage standard de données d'échange, XML le plus probable, plutôt que des protocoles propriétaires.

répercussions de cette tendance

Avec un Internet-seul système ERP en place, les mises à niveau de logiciels côté client devenir applications inutiles, basés sur navigateur simplifient considérablement la formation et attachant ensemble des endroits éloignés d'une entreprise devient plus simple aussi. Pour ce faire, d'une manière appropriée, les éditeurs d'ERP doivent repenser complètement leurs applications pour un environnement e-business true, ce qui nécessite des ressources et un engagement. Certains fournisseurs ont reconnu la nécessité tôt, alors que la grande majorité attendit que la tendance était plus évidente et sont désormais engagés dans une course effrénée de rattrapage. Les derniers vendeurs sont confrontés à la possibilité de perdre des parts de marché.

Conclusion de la partie 2

Ceci conclut la partie 2 d'une note de quatre parties sur les tendances des applications ERP. Cette partie a couvert deux tendances: le défi éditeurs d'ERP visage dans le développement d'une architecture adaptable, flexible, agile, a permis à l'interopérabilité, ainsi Web-basing systèmes ERP.

Partie 1 couvre deux tendances:. ERP extension du périmètre fonctionnel et davantage l'accent vertical

partie 3 porte sur la fourniture de composants e-business et de dépoussiérage mid-market.

Partie 4 couvre l'avènement des services d'hébergement d'applications et de nouveaux modèles de tarification.

 
comments powered by Disqus

Recherches récentes :
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.