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

9.2.6 Standard Software or Company-Specific Software?

Intended learning outcomes: Explain various reasons why some companies still need company-specific software. Disclose aspects that should be taken into account when choosing between standard and company-specific software.

previous subsection
next section header

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.

previous subsection
next section header

Course section 9.1: Subsections and their intended learning outcomes

Written by

View all posts by: