Construct, Deliver and Maintain Systems Project:Commercial Packages and Trends in Commercial Packages.

By -

Commercial Packages

Thus far we have examined system construction and delivery activities pertaining to in-house development. Not all systems are acquired in this fashion; the trend today is toward purchased software. Faced with many competing packages, each with unique features and attributes, management must choose the system and the vendor that best serves the needs of the organization. Making the optimal choice requires that this be an informed decision.

Before moving on to the next phase of the SDLC, we will examine the issues surrounding the purchase of commercial software. Our discussion will focus primarily on a technique that can help structure and evaluate the many intangible factors that complicate the process of selecting commercial software.

Trends in Commercial Packages

Four factors have stimulated the growth of the commercial software market: (1) the relatively low cost of general commercial software as compared to customized software; (2) the emergence of industry-specific vendors who target their software to the needs of particular types of businesses; (3) a growing demand from businesses that are too small to afford an in-house systems development staff; and (4) the trend to- ward downsizing of organizational units and the resulting move toward the distributed data processing environment, which has made the commercial software option more appealing to larger organizations.

Indeed, organizations that maintain their own in-house systems development staff will purchase commercial software when the nature of their need permits. Commercial software can be divided into a number of general groups, which are discussed in the following section.

Turnkey Systems

Turnkey systems are completely finished and tested systems that are ready for implementation. Often these are general-purpose systems or systems customized to a specific industry. Turnkey systems are usually sold only as compiled program modules, and users have limited ability to customize such systems to their specific needs. Some turnkey systems have software options that allow the user to customize input, output, and some processing through menu choices. Other turnkey system vendors will sell their custom- ers the source code if program changes are desired. For a fee, the user or the vendor can then reprogram the original source code to customize the system. Some examples of turnkey systems are described in the following section.

GENERAL ACCOUNTING SYSTEMS. General accounting systems are designed to serve a wide variety of user needs. By mass producing a standard system, the vendor is able to reduce the unit cost of these systems to a fraction of in-house development costs. Powerful systems of this sort can be obtained for under $2,000.

To provide as much flexibility as possible, general accounting systems are designed in modules. This allows users to purchase the modules that meet their specific needs. Typical modules include accounts payable, accounts receivable, payroll processing, inventory control, general ledger, financial reporting, and fixed asset.

SPECIAL-PURPOSE SYSTEMS. Some software vendors have targeted their systems to selected segments of the economy. For example, the medical field, the banking industry, and government agencies have unique accounting procedures, rules, and conventions that general-purpose accounting systems do not always accommodate. Software vendors have thus developed standardized systems to deal with industry-specific procedures.

OFFICE AUTOMATION SYSTEMS. Office automation is the use of computer systems to improve the productivity of office workers. Examples of office automation systems include word processing pack- ages, database management systems, spreadsheet programs, and desktop publishing systems.

Backbone Systems

As we learned in Chapter 1, backbone systems provide a basic system structure on which to build. Back- bone systems come with all the primary processing modules programmed. The vendor designs and pro- grams the user interface to suit the client’s needs. This approach can produce highly customized systems. But customizing a system is expensive and time-consuming. Many vendors thus employ object-oriented systems design, which takes advantage of reusable modules and thereby reduces the costs of tailoring the system to the user.

Vendor-Supported Systems

Vendor-supported systems are hybrids of custom systems and commercial software. Under this approach, the vendor develops (and maintains) custom systems for its clients. The systems themselves are custom products, but the systems development service is commercially provided. This option is popular in the health care and legal services industries. Because the vendor serves as the organization’s in-house systems development staff, the client organization must rely on the vendor to provide custom programming and on-site maintenance of systems. Much of each client’s system may be developed from scratch, but by using an object-oriented approach, vendors can produce common modules that can be reused in other client systems. This approach helps to reduce development costs charged to the client firms.

ERP Systems

Enterprise resource planning (ERP) systems are difficult to classify into a single category because they have characteristics of all of the previously discussed systems. They are prewritten systems, which in some cases are implemented as turnkey applications. On the other hand, they can be modified to meet user needs. An ERP may be installed as a backbone system that interfaces with other legacy systems, or it may constitute an entirely new system. Because of their complexity, ERP systems are most often vendor- supported packages that an outside service provider installs.

ADVANTAGES OF COMMERCIAL PACKAGES

Implementation Time

Custom systems often take a long time to develop. Months or even years may pass before a custom sys- tem can be developed through in-house procedures. Unless the organization successfully anticipates future information needs and schedules application development accordingly, it may experience long periods of unsatisfied need. On the other hand, small commercial software systems can be implemented almost immediately upon recognizing a need. The user does not need to wait. The implementation of a single module of larger systems such as PeopleSoft, SAP, or ORACLE-FIN, however, could take from several weeks to a few months. An entire ERP could take years, but this is still much quicker than in- house or outsourced development would take.

Cost

A single user must wholly absorb in-house development costs. However, because the cost of commercial software is spread across many users, the unit cost is reduced to a fraction of the cost of a system developed in-house.

Reliability

Most reputable commercial software packages are thoroughly tested before their release to the consumer market. Any system errors that were not discovered during testing that organizations likely uncover shortly after release are corrected. Although no system is certified as being free from errors, commercial software is less likely to have errors than an equivalent in-house system.

DISADVANTAGES OF COMMERCIAL PACKAGES

Independence

Purchasing a vendor-supported system makes the firm dependent on the vendor for maintenance. The user runs the risk that the vendor will cease to support the system or even go out of business. This is per- haps the greatest disadvantage of vendor-supported systems.

The Need for Customized Systems

The prime advantage of in-house development is the ability to produce applications to exact specifica- tions. This advantage also describes a disadvantage of commercial software. Sometimes, the user’s needs are unique and complex, and commercially available software is either too general or too inflexible.

Maintenance

Business information systems undergo frequent changes. If the user’s needs change, it may be difficult or even impossible to modify commercial software. On the other hand, in-house development provides users with proprietary applications that can be maintained.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

Nassi-Shneiderman charts

By -
Image
Nassi-Shneiderman charts 56.1 Purpose Nassi-Shneiderman charts were developed by Nassi and Shneiderman as an alternative to traditional logic flowcharts. Their intent was to provide a structured, hierarchical, graphical view of the flow of logic through a program, a routine, a module, or a process. Nassi-Shneiderman charts are used to document, plan, and design detailed program logic. 56.2 Strengths, weaknesses, and limitations A properly prepared Nassi-Shneiderman chart can illustrate the flow of logic through a module or routine at a glance. Nassi-Shneiderman charts are useful for describing or planning relatively small modules, routines, or processes. They can be used to clearly show nesting and recursion, and are easily converted to structured code. Nassi-Shneiderman charts should not be used for documenting complete programs or large routines. As a general rule, Nassi-Shneiderman charts should be limited to a single page with no more than 20 subdivisions. For larger rout...
Read more