Integral Logistics Management — Operations Management and Supply Chain Management Within and Across Companies

9.2 Contents of ERP Software and SCM Software

Intended learning outcomes: Describe classical MRP II / ERP software. Present software for customer order production, for the process industry, for transcorporate planning & control in a supply chain, and for Customer Relationship Management (CRM). Differentiate between standard and company-specific software.

Every ERP or SCM software package has developed in a slightly different way. Some were designed for specific branches of industry, products, or production characteristics. The developers also learned their craft in a certain type of company environment, which shows in the features of the software.

9.2.1      Classical MRP II / ERP Software

Classical software was developed in mechanical engineering and automobile construction companies, with discrete manufacturing, batch production, and production with order repeti­tion as characteristic, and with high utilization of capacity as the entrepreneurial objective. Extension of this functionality resulted in what we now know as MRP II software or ERP software. This type of software essentially supports the concept described in Chapter 5.

The first package in this category was Copics from IBM. Other ex­amples are Manufac­tu­ring from Oracle, J.D. Edwards, Infor XA (in the past Mapics from IBM) and. The actual market leader is SAP, with its R/3, mySAP™ soft­ware and the follow-up products. Software houses like SAP offer a compre­hen­sive and integrated package that supports all the business proces­ses within a company. Figure contains an overview of the R/3 structure.

Fig.         SAP R/3 as a typical example of a classical, generally applicable ERP software package.

The abbreviations that designate the modules, which are oriented toward specific functions within a company, consist of two letters: SD for sales and distribution, MM for procurement and stochastic materials management, and PP for deterministic materials management, scheduling, and capacity manage­ment. The modules contain submodules for the three temporal ranges (long, medium, and short term) and for the individual tasks. The functional separation between MM and PP empha­sizes the distribution of users between trade and produc­tion. It also betrays the fact that R/3 started out as an MRP II package.

SAP developed R/3 with a view to covering and integrating every function within a company. The finance and accoun­ting functions have always been the driving force behind the development of ERP software, since detailed job-order costing requires efficient administration of all types of orders within the company. This simple aspect of corporate policy explains why the emphasis always has to be placed on certain areas when developing ERP software. The decision will ultimately depend on whether the finance function can be integrated, rather than on the quality of support provided for planning & control.

SAP R/3 can be customized to take account of different values for the features relating to planning & control described in Section 4.4. R/3 specialists configure the software by setting a large number of parameters. It is not enough just to have a knowledge of logistics, planning & control, and the actual company, which means that R/3 is rather suitable for medium-sized and large companies. Since the software was developed from the MRP II concept, the limitations of usability indicated in Figure also apply for this kind of ERP software.

The Lean/JIT concept and all the techniques for production with frequent order repetition are oriented toward the needs of manual organizations. In the best-case scenario, such organizations can manage without software altogether. ERP software can be introduced when the volume of data becomes too large, e.g., a package on a PC with a simplified master data management system. This will enable the number of Kanban cards to be calculated, for example. It could also be an ERP software package extended to include this type of function.

In contrast, the variant-oriented and processor-oriented concepts require adequate soft­ware, as discussed in the rest of this chapter. Together with the software for the MRP II concept, such concepts also provide fundamental typologies for ERP software for planning & control.

9.2.2      Software for Customer Order Production or the Variant-Oriented Concept

Software for customer order production and the variant-oriented concept, that is, for products according to (changing) customer specification or for product families with many variants, has been specially designed for and developed in conjunction with make-to-order producers. Often, bills of material are customer-specific or order-specific. Such companies need the variant-oriented concept for single-item production or nonrepetitive or “one-of-a-kind” production. The different techniques identified in Chapter 7 all place different requirements on the software and, in the most extreme situation, could even lead to different subtypes of ERP software for the variant-oriented concept. Equally, a package may only be suitable for one of the techniques within the variant-oriented concept.

Software for customer order production or the variant-oriented concept was mainly developed in Europe, particularly for small- and medium-sized companies (SME). This software includes PSIpenta from PSI, ProConcept from ProConcept SA, and, in the past, MAS90 from IBM, IPPS from NCR, and many niche products. Packages that are particularly suitable for product families with a wide range of variants include Infor LN (in the past Baan) as well as Expert/400 (which was developed by the author). There are also a number of industry-specific products, e.g., for window and furniture production. For bid processing of engineer-to-order products, the Leegoo Builder Software of EAS GmbH is well known.

Figure shows, by way of example, the PSIpenta software module for product families with a wide range of variants. It also provides an overview of the level of detail below that illustrated in Figure

Fig.         Typical software for customer order or variant-specific production: the PSIpenta modules.

Some of the modules, such as “Customer order archive,” “Create order package,” and “Network planning module,” suggest that the software is particularly suitable for customer order production. Within the order structure, the product that is ordered or offered may be greatly modified for a particular customer. One particular characteristic is the processing of “exotic” items that are only needed for a specific order and for which it can be said with certainty that there will be no order repetition. In this case, there is no need to store master data for the item or to allocate an item ID.

9.2.3      Software for the Process Industry or the Processor-Oriented Concept

The processor-oriented concept for the process or basic producer industries requires appropriate ERP software, that is, in which the emphasis is placed on mixing ratios and recipes, rather than on bills of material.

Software for the processor-oriented concept largely originates from the chemical, pharma­ceuticals, and food industries in the United States or Germany. It includes software such as Blending from Infor, Infor LX (in the past Bpics), Cimpro from Palomino Computer Solutions, Ross ERP from Apten, MFG-PRO from QAD and, in the past, Protean (once Prism from Marcam).

Figure shows typical modules that make up such software by way of example. The make up highlights the emphasis placed on resources and on the production model (processor-oriented production structures as described in Chapter 8).

Fig.         Software for the process industry: some typical modules.

Problems specific to the process industry that are covered include:

  • Different lots of a bought-in product have different characteristics and must thus be handled differently (e.g., production of tomato products: addition of sugar according to the sugar content of the tomatoes, use of different grades for different products).
  • The process industry often uses by-products, recycled products, or waste products. The traditional representation of product structures in the form of bills of material is not suitable for such cases.
  • Planning & control do not just apply to materials. They are of equal importance for capacity and production equipment (e.g., molds for manufacturing chocolate bars).

Electronic control boards (“Leitstand”) software packages are used for IT support of master production scheduling. These packages take account of the limited capacity typical of such industries and, by changing these limitations, allow reliable and appropriate production schedules to be created (constraint-based techniques).

9.2.4      Software for Transcorporate Planning & Control in a Supply Chain

The term SCM software or advanced planning and scheduling (APS) software is used to describe software that supports transcorporate planning & control.

SCM software has been available for several years. Developments are moving in three different directions:

  1. Electronic control boards (“Leitstand”) software supplemented with mod­ules for logistics and production networks. Software such as JDA solutions places (by the takeover of Manugistics) particular emphasis on distribution networks; that is, the distribution of end products produced by different companies via various sales channels (e.g., national companies).
  2. Conventional MRP II software or ERP software supplemented with company-specific or bought-in modules. These include APO (advanced planner and optimizer) from SAP or the equivalent products from PeopleSoft (by the takeover of Red Pepper). The “problem solver” software kernels from ILOG are often integrated for scheduling tasks. These modules work using constraint propagation techniques.
  3. Niche software specially designed for transcorporate planning & control.

Figure illustrates the concept and some of the tasks of SCM software.

Fig.         Concept and some of the tasks performed by SCM software.

The master and order data are still administered by the local planning & control software of the individual companies involved in the logistics and production network. The data are periodically downloaded by the SCM software. The network planning then takes place and the results are returned to the local software.

The actual planning functions of SCM software are similar to those of traditional ERP and electronic control boards (“Leitstand”) software, supplement­ed with new modules that meet the typical needs of networks:

  • Supply chain network design to describe the logistics and production network
  • (Network) inventory planning for tasks like replenishment of the customer’s stocks by the supplier (VMI, vendor-managed inventory; CRP, continuous replenishment planning). To be able to do this, the supplier must have access to the customer’s inventory and order data (and the data of any customers downstream in the network).
  • Real-time customer service to be able to assess the fill rate of open orders with suppl­iers in advance. To be able to do this, the customer must have access to the supplier’s inventory and order data (and the data of any suppliers upstream in the network).

These concepts are still at the field trial stage, but the sales network software is likely to be implemented first. This is not surprising since the organizational concepts for sales networks are older than those for joint R&D and production. In this context, the author of [Nien04] presents an approach for designing SCM-Software that also considers aspects like robustness, tangibility, and efficiency.

9.2.5      Software for Customer Relationship Management (CRM)

Customer relationship management (CRM) is the collection and analysis of infor­ma­tion designed for marketing, sales, and service decision support (as contrasted to ERP informa­tion) to understand and support existing and potential customer needs (cf. [APIC16]).
CRM software is software that supports CRM.

CRM software development began in the 1980s, when companies first used computer-aided selling (CAS) software for rationalization of their distribution. The shift from this focus on rationalization to an emphasis on quality improve­ment of customer relationships required an extension to include marketing and services and led to today’s generation of software (e.g., Siebel from Oracle).

CRM software provides functionality in two areas:

  • The functions of operational CRM facilitate the business processes behind inter­actions with customers at the point of contact (“front office”). Tasks arising from the interaction processes and the required information are delivered to appropriate employees (“back office”) for processing, interfaces are provided for further appli­cations (word processing, e-mail client), and customer contacts are documented.
  • Analytical CRM solutions, on the other hand, analyze the data created on the operational side of CRM, particularly for purposes of customer analysis and segmentation of the customer base (for instance, identifying potential failures of customer retention) or to exploit cross- and up-selling potentials.

CRM software supports all staff interactions with the customer in a number of ways (see Figure

  • CRM software provides a representation of all interactions between staff and custo­mer. Staff members are always informed about who is responsible for supporting a customer and whom they should inform about contacts with the customer.
  • CRM software supports staff in organizing, executing, and documenting customer contacts. These may be contacts with an individual customer (in person or by telephone, e-mail, or fax/letter), the sending of marketing content addressed to several customers, or a sales promotion event to which many customers are invited.
  • CRM also provides functions for product-related interactions, such as customer service inquiries or sales opportunities. The system captures the sales opportunities and the corresponding order success probability, allowing the company to forecast expected sales.

Fig.         CRM software representation of the objects and their interrelationships.

The data required by CRM software for the most part already exist in the company, but they are located within various applications:

  • Product-related data (such as customer orders) in ERP software or legacy systems
  • Customer addresses in personal information management (PIM) soft­ware — sometimes at decentralized workplaces; the PIM file may also document some of the interactions (appointments, e-mail)
  • Customer-related documents (such as bids, invoices, invitations) produced by word processing and sometimes administered by document management systems

When implementing CRM software, the challenge is to integrate all of the data and the available interfaces. It is important to evaluate whether the systems work together in a coherent and consistent way. Today, many of the complete CRM software systems are being replaced by applications that make use of a company’s existing PIM applications as the basis or by applications that are components of enterprise software packages. Portals, that is multiservice Web sites, can be used for this task.

9.2.6      Standard or Company-Specific Software?

Standard software is software designed to meet the needs of different companies. It is developed and sold by a specialist software house. Company-specific software is created for a specific company and thus precisely meets the needs of that company. It is either developed within the company or the work is commissioned from a software house.

Many companies had their own company-specific software by the end of the 1980s, since the standard packages, which were solely MRP II oriented, did not meet their needs. In time, more logistics packages with most of the required functionality became available on the market. It was also recognized that the cost of maintaining company-specific software is extremely high. As a result, there has been a massive trend toward the use of standard software over recent years, which has contributed to the success of SAP R/2 and R/3. Nevertheless, some companies still need company-specific software for various reasons:

  1. Unsuitable processes: When standard software is implemented compa­nies often find, particularly with respect to order processing, that they have to cut down processes forming part of their core processes and not just their antiquated legacy procedures. If core processes have to be adapted to conform to the “standard,” then the company is likely to lose its competitive edge. Then, the software must be examined to determine just how modular it is, that is, whether the data model and process model have interfaces that will allow a company-specific program to be integrated in place of the unsuitable module supplied with the standard software. That is, only some modules would then be company specific, rather than the entire package. Such changes are expensive, and often time consuming and difficult.
  2. Inadequate functionality: Certain object classes or attributes may be missing from or inappropriately defined in the data model. This means that additional classes or attributes must be added or existing ones changed to modify the function model to suit the desired functionality. Today, this type of change can usually be carried out by simply generating the code from a definition language.
  3. The user interface cannot be integrated into the company’s processes and way of working: For example, a variant generator of a well-known ERP-software was awk­ward to use and required IT-oriented thinking. In one case, careful reprogram­ming of the user interface provided the design engineers with a simple interface that works well in their language. They are now able to make use of the needed IT support as part of their job description. However, the need for a simpler process must be offset against the increased cost of adapting the user interface. Such changes are often not difficult to implement, but are “merely” time consuming and thus expensive.

There are two other aspects that should be taken into account when choosing between standard and company-specific software:

  • Risk of error: The number of man years invested in the production of company-specific software will be less than that required to produce standard software of the same scope. It is also likely that the former will contain more bugs than the latter. On the other hand, standard software is not always completely stable; new software releases often have to be installed in quick succession, even though most of the changes are not relevant to a particular company. This is usually regarded as an unnecessary expense. Poor standard software can contain more bugs than good company-specific programs.
  • Continuity: Here, again, it is not possible to give generally appli­cable ad­vice. The pros and cons must be considered in each case. Although the teams involved in developing company-specific software are gen­erally smaller, they also tend to be more committed to their program. Experience shows, however, that practically none of the companies that have produced ERP software packages have managed to issue a second generation of their successful package without going into liqui­dation or being taken over by another company. Both situations have direct consequences on the continuity of standard software packages.

To summarize, a standard software package can rarely be implemented without adaptation if the entire logistics task is taken into consideration. A commercial decision must be taken to set the priorities: will the benefits of greater user friendliness, greater transparency, and faster lead times for the data and control flow outweigh the longer implementation time and higher costs?

New basic technologies offer great potential for the development of both company-specific and standard software. The benefits of standard PC soft­ware, such as word processors, spread­sheets, project planning software, etc., can already be used to implement much of the functionality provided by ERP software. See also [MöMe96], for example. The Internet, the Java program­ming language, and a standard for a company’s objects (such as Corba) enable software modules from various sources to be linked to one another.

Course sections and their intended learning outcomes

  • Course 9 – ERP and SCM Software

    Intended learning outcomes: Describe software used for logistics purposes. Explain contents of logistics software packages. Disclose factors for successful implementation of logistics software.

  • 9.1 Software in the Area of ERP and SCM: An Introduction

    .Intended learning outcomes: Produce an overview on history and origin of ERP software. Disclose scope and range of ERP and SCM software.

  • 9.2 Contents of ERP Software and SCM Software

    Intended learning outcomes: Describe classical MRP II / ERP software. Present software for customer order production, for the process industry, for transcorporate planning & control in a supply chain, and for Customer Relationship Management (CRM). Differentiate between standard and company-specific software.

  • 9.3 Factors for Successful Implementation of ERP and SCM Software

    Intended learning outcomes: Explain possibilities and limitations of the IT support of planning & control. Disclose factors that influence individual acceptance and the range of implementation of ERP software.

Print Top Down Previous Next