首页 > > > Integrating ERP, CRM, Supply Chain Mgt., and Sm…

Integrating ERP, CRM, Supply Chain Mgt., and Smart Materials 8.pdf

Integrating ERP, CRM, Supply Ch…

上传者: gushici 2012-02-25 评分1 评论0 下载15 收藏10 阅读量420 暂无简介 简介 举报

简介:本文档为《Integrating ERP, CRM, Supply Chain Mgt., and Smart Materials 8pdf》,可适用于生产运营领域,主题内容包含ChapterImplementingSuccessiveReleasesofERPSystemsThesoftwareindustryisreno符等。

119 Chapter 7 Implementing Successive Releases of ERP Systems The software industry is renowned for using non-standard terminology in describing its wares. Therefore, it is necessary to define the terms that will be used as well as establish the difference between a new version , major upgrade , or minor upgrade of a programming product. Quite often, for commercial reasons, these terms are used interchangeably. If a new release of off-the-shelf software, such as ERP or CRM, represents only a minor upgrade, this will typically involve correction of errors, bug fixes, removal of patches, or weeding out some of the inefficiencies. By contrast, a major upgrade will typically involve novel functions. It may also account for regulatory changes regarding financial reporting and other requirements. While each vendor tends to use its own terminology, the way to bet is that a major release sees to it that any successive version of an ERP system (or any other type of commodity software) will tend to be significantly different than its predecessor. The core product itself is affected and, quite often, this impacts on the user organization all the way from system skills to central memory and other technical requirements. Both the aims and problems associated with new releases can be better appreciated through a quick look at the history of ERP software. When in the late 1980s/early 1990s, ERP hit the market, its different vendors concentrated their efforts on capturing as much of market share as possible by steadily enlarging the scope of their offerings — and through this strategy, their customer base. ERP was not invented overnight. One of its predecessors was MRP II, originally designed to manage a production facility’s customer orders, sched- uling plans, and inventories. The need to integrate the sales book with in- process goods and inventory data came as a logical next step. This was a AU1076/frame/ch07 Page 119 Saturday, April 21, 2001 12:47 AM 2001 by CRC Press LLC 120 Integrating ERP, CRM, Supply Chain Management, and Smart Materials new release. As seen in Chapter 1, other releases took care of accounting routines, financial information, and human resource planning. The need for steady innovation can be appreciated by the fact that while most of the 1990s witnessed booming ERP sales, by 1998 the market slowed down with revenues from selling new software licenses declining. One reason was that client companies needed to solve their Year 2000 (Y2K) problems. Another reason was that the ERP market itself started becoming saturated. By adding new functionality to commodity software, successive releases are often instrumental in breaking through the saturation barrier. This, however, might lead to complexities on the implementation side as well as the lack of skills in solving them. One of these complexities is the so-called multi-site enterprise resource planning applications, where at each site there are different choices due to different criteria for evaluating the alternatives and proceeding with a valid solution (see Chapter 6). New releases are also necessary to match the requirements posed by advancing technology. An example is the need to incorporate into the package support for the Product Markup Language (PML), which is an extension of the Extensible Markup Language (XML) — itself a development of the Web’s HTML. 1 PML is discussed in Chapter 7.6; its functionality serves in handling smart materials, as it is on its way to becoming the standard language for describing physical objects. Smart materials is the theme of Section II. 7.1 Distributed Processing Increases the Challenge of Implementing New Releases Implementing a new release was somewhat simpler when computer processing was centralized in huge hospital-looking buildings, with large internal glass windows to permit visitors to see the marvels of a machine with attendants wearing long white robes. While it had many other defects, particularly in downgrading efficiency and reliability, this concentration of data processing somehow simplified the change of a release. But in the 1950s and 1960s, new releases were scarce. Today, it is different in many ways; the pace of releases and upgrades has accelerated while in the same user organization there may be multiple sites, and some of these IT sites are largely independent of the others. Therefore, a significant amount of coordination is necessary. Sometimes, release changes at one site limit the available choices or affect the performance of the system at another site. User organizations are therefore well-advised to plan multi-site ERP and CRM implementations very thoroughly. They should do so before committing themselves to a given commodity software solution and its suc- cessive releases. The main handicaps in implementing successive ERP releases concern background technical reasons, ranging from heterogeneous hardware plat- forms and OS/DBMS choices at user organization premises, to limited skill for keeping the system up-to-date at each site. Even if in the past years or months, AU1076/frame/ch07 Page 120 Saturday, April 21, 2001 12:47 AM 2001 by CRC Press LLC Implementing Successive Releases of ERP Systems 121 the problems of heterogeneity of platforms and basic software were tempo- rarily solved, they resurface with a new release, leaving companies to perceive migration as difficult, time-consuming, and costly. New releases of commodity programming products, whether basic software or applications, are in fact a double-edged sword. One reason why the migration process takes so long to execute is the attention that needs to be paid to each existing heterogeneous platform. Another reason is wanting coordination and the traditional policy of many IT shops to move at slow pace. Indeed, the latter reason, more than any other, sees to it that some migrations to a new release receive bad reviews. Whether one is talking about ERP, CRM, or any other programming product, multi-site coordination is the keyword. Keep in mind that many ERP-supported business functions are increasingly executed simultaneously, interactively, and in real-time. This requires business and systems staff to work in close collab- oration with both the vendor and the different implementation sites, and to address all types of implementation issues in a rigorous way, including problems surfacing in one site but not in others. People who have, on a number of occasions, gone through the experience of implementing new releases are commenting that, in their judgment, some of the complexities in ERP software releases emanate from the highly gener- alized nature of the off-the-shelf applications and from the fact that user organizations move to personalize these routines. This sees to it that diversity and therefore complexity increases, the more so if instead of a parametric customization, the user company alters some of the software. Good systems sense suggests that such alteration should not be made. Off-the-shelf software should be used as is , subject only to parametric customization, and the latter should take place only if such a facility is available by the vendor. To help in evaluating the wisdom of adopting a new release, Exhibit 7.1 suggests a selection procedure for off-the-shelf programming products. Typi- cally, a company has a list of top-ten functions it would like to see supported in a more efficient way than the one currently available. These come first in the evaluation. They are followed by key performance criteria. The ERP package, whose most recent upgrade is mapped in terms of effectiveness in the radar chart, was installed at five major sites of the EPSILON company (a ficticious name, but a real entity). Each site, identified I to V, tested the aftermath of the upgrade and came up with a rating reflected in Exhibit 7.1. As the reader can appreciate, these ratings were diverse. At sites IV and V, for example, the cost of installing the new release hardly broke even with expected benefits. The question was therefore posed: should EPSILON install this new release or forego its benefits? The change of a release has significant costs associated with it. These should be justified by an increase in functionality and performance. Notice that this method is also applicable in the original selection of an ERP package and not only in evaluation of adopting successive releases. In AU1076/frame/ch07 Page 121 Saturday, April 21, 2001 12:47 AM 2001 by CRC Press LLC 122 Integrating ERP, CRM, Supply Chain Management, and Smart Materials original selection, the cost/benefit comparison will be against the current method. Management should appreciate that migration between successive releases of ERP software is often a challenge. Even if one of the aims of new releases is that of improving business processes, one should have evidence that the upgrade is indeed benefiting the organization. Such evidence is obtained by pinpointing important business processes for which measurable results can be obtained. By being careful with regard to cost-effectiveness, users can influence ERP vendors to add more functionality or to improve the efficiency of their releases. At the same time, vendors should be keen to test projected upgrades with user organizations. It is appropriate that the evolution of ERP solutions is influenced by changing market conditions, but there is a whole list of criteria to be observed, including better service-oriented approaches. Even if many organizations do not migrate the moment a new version becomes available, in the longer run they are motivated to adopt the new release for technical reasons and business opportunities. At the level of user organization, not only does the current application’s complexity need to be evaluated through benchmarks addressing the new release, along with expected benefits at each site, but future requirements must also be taken into account, given the evolution of demand for products and services. For cost/benefit reasons, it is my policy to track the cost of the initial installation of an ERP system and of its subsequent releases. This can be done through a simple chart similar to the one presented in Exhibit 7.2. Functionality and performance criteria of the new release should be established by the company already implementing the programming product. Exhibit 7.1 A Radar Chart for Evaluating Five Different Sites of ERP Packages and Their Upgrades, Based on Four Factors AU1076/frame/ch07 Page 122 Saturday, April 21, 2001 12:47 AM 2001 by CRC Press LLC Implementing Successive Releases of ERP Systems 123 What the vendor says may be indicative, but it is not the bible. Both criteria and benchmarks should be the company’s own. It should as well be appreciated that an open architecture (see Chapter 6) presents better opportunities for an evolutionary process that is easy to implement and assists in establishing a business differentiation. Not only does an open architecture ease the original integration task of commodity ERP software, but it also, other things being equal, simplifies the installation and operation of new releases. Notice as well that with practically every new release, ERP, CRM, and other programming products can be configured through conceptual models linked with the repository of the system currently in use. That is why, to a very significant extent, rigid concepts customary with mainframe solutions are no longer welcome. What is needed is flexible targeting concepts that fit well with new releases and parametric customizing techniques. The use of modeling tools can help in migration to a new release because they can assist in functional definition and in setting performance criteria. The existence of a development database makes it possible to have detailed documentation both at the business and technical levels. It also provides a good linkage to further upgrades. I insist on these issues because the problem of upgrading is scheduled to become even more pronounced in the coming years because a significant number of ERP and CRM application users are moving out of their current monolithic releases to take advantage of new functionality as it becomes Exhibit 7.2 Characteristic Features of Commodity Software Should be Analyzed Prior to Its Selection, and the Same Is True of Subsequent Releases AU1076/frame/ch07 Page 123 Saturday, April 21, 2001 12:47 AM 2001 by CRC Press LLC 124 Integrating ERP, CRM, Supply Chain Management, and Smart Materials available. While one is not obliged to adopt them, new releases are part of the natural evolution of ERP applications and aim to incorporate Internet enabling techniques that drive the requirements for continuous integration of new routines. They also help in substituting aged in-house legacy applications, which should have been weeded out 10 or 20 years ago. 7.2 Metadata and Metaknowledge: An Upgrade No Company Should Forego No technology, no new product, and no upgrade is worth anything if it does not deliver value. Value is created either by linking technology to marketing through innovative, more efficient products and services, or by increasing internal performance and therefore swamping costs. At the junction of these two organizational breakthroughs lies the concept of meta . Meta is a level above another more basic level, and therefore it is strong in semantic content. Exhibit 7.3 provides two examples: the one from banking, the other from inventory management. The amount of money written on a check is the lower information level. Date and place of issue is meta to it. Still higher up is the control level, which delimits date of validity and maximum acceptable amount. Metadata is important in many activities. Inventory management is another example. Metadata to raw inventory levels includes a directory of inventory locations, minimum and maximum per item, and level of confidence for automatic reordering. This is important for marketing and for optimization. Such metalevels are specific to the item; hence, so much can be gained if, as will be seen in Section II, each item is able to: Automatically identify itself Transmit its ID and position to other entities Making the grand statement that technology has the potential to significantly improve productivity and bring benefits beyond present-day practices means Exhibit 7.3 The Concept of Metadata Is Not Well-Understood, Yet It Is Fundamental to Modern Computer Applications AU1076/frame/ch07 Page 124 Saturday, April 21, 2001 12:47 AM 2001 by CRC Press LLC Implementing Successive Releases of ERP Systems 125 that one can obtain tangible results from its implementation. Metalevels allow one to fine-tune inventory planning and control. How this connects to services provided by smart materials is explained in Chapters 8 to 11. These two examples — checks and inventory level — assist in explaining that metadata is data about data . As such, it is critical for the effective management of data resources and also for defining the best structures to be adopted in connection with logical and physical databases. ERP and CRM software should be strong in metadata support, but usually it is not. Therefore, one should not miss the opportunity to implement a new release using metadata. A different way of looking at this subject is that the focal point of databases is their organization, utility, and service in a marketplace that is steadily becoming more competitive and more demanding. The contribution to one’s database should be a major criterion in the selection and use of ERP and CRM programming products. Emphasis must be placed on applications that exploit knowledge-enriched database solutions — and this means the able handling of metadata and metaknowledge. Technically speaking, metaknowledge contrasts with object knowledge . Object knowledge is basic level. For example, typical logic programming is an expression of object knowledge. In contrast, in a way comparable to what was just explained about metadata, metaknowledge is of a higher level, which includes generalizations and constraints. Metaknowledge — that is, knowledge about knowledge — is essentially constraint-type knowledge. The notion of constraints is very important because it controls the inference processing mechanism in humans and machines. In practical implementation terms, metaknowledge can be instrumental in the transformation of behavioral views, procedural and other patterns, and operational frameworks. Knowledge management systems need both metadata and metaknowledge. This is true whether one is talking about computer-based artifacts or about manual handling. Currently, there are no efficient solutions for manually handled information; therefore, a computer-based advanced metalevel functionality is most welcome. Data traditionally stored in databases may only represent 10 percent of the information assets of a company. The remainder is usually stored nondigitally as documents, faxes, paper files, drawings, or photos. The challenge is how to use metaknowledge in connec- tion with the latter. The answer is to classify this type of information in a way that end-users can access as part of a global resource (see Chapters 10 and 11 on classification). This being done, further duties can be assigned to a knowledge management system. Knowledge mapping extends metadata con- cepts to classifying and retrieving nondigitized information. Exhibit 7.4 explains this interaction between higher and lower levels by introducing the concept of macroscopic and microscopic views. The metalayer is based on macroscopic knowledge, which is conceptual and might even be fuzzy. The microscopic level consists of detail, with elementary data types that can be recombined. The two are linked by inheritance , which is dynamic, instantaneous, and perishable. AU1076/frame/ch07 Page 125 Saturday, April 21, 2001 12:47 AM 2001 by CRC Press LLC 126 Integrating ERP, CRM, Supply Chain Management, and Smart Materials Readers familiar with object-oriented databases 2 and object programming will recognize that this is the reference underpinning this discussion. It is preferable that ERP and CRM programming products be object-oriented. If the programming product being used is not, and its vendor brings out an object version, then one should do what it takes to implement it. Both ERP and CRM functionality can benefit from metalevels, above the level of detail that constitutes the object of this examination. Supported by the metalevel, a macroscopic view would allow one to focus on component parts (through zooming) and to examine the integrative view of detailed elements. In principle: Microscopic knowledge is focused on one domain in which there is little or no contradiction. An example is the handling of a specific financial product, such as letters of credit. The specialist’s microscopic knowledge is important not only to ensure the proper debits and credits, but also to calculate the risk being taken by the bank — and therefore the product’s pricing. Microscopic knowledge is often considered “obvious” to people with experience in a given limited domain. Although microscopic knowledge typically addresses a narrow field, there are several difficulties in data and knowledge acquisition. Also, while there is only one or at most very few established patterns in connection with microscopic knowl- edge, there exist at times less than realistic approaches to


  • 名称/格式
  • 评分
  • 下载次数
  • 资料大小
  • 上传时间





/ 0
所需积分:1 立即下载