The Information System:THE MANUAL PROCESS MODEL

THE MANUAL PROCESS MODEL

The manual process model is the oldest and most traditional form of accounting systems. Manual systems constitute the physical events, resources, and personnel that characterize many business processes. This includes such tasks as order-taking, warehousing materials, manufacturing goods for sale, shipping goods to customers, and placing orders with vendors. Traditionally, this model also includes the physical task of record keeping. Often, manual record keeping is used to teach the principles of accounting to business stu- dents. However, this approach is simply a training aid. Manual records are never used in practice today.

Nevertheless, there is merit in studying the manual process model before mastering computer-based systems. First, learning manual systems helps establish an important link between the AIS course and other  accounting courses. The AIS course is often the only accounting course in which students see where data originate, how they are collected, and how and where information is used to support day-to-day operations. By examining information flows, key tasks, and the use of traditional accounting records in transaction processing, the students’ bookkeeping focus is transformed into a business processes perspective.

Second, the logic of a business process is more easily understood when it is not shrouded by technology. The information needed to trigger and support events such as selling, warehousing, and shipping is funda- mental and independent of the technology that underlies the information system. For example, a shipping notice informing the billing process that a product has been shipped serves this purpose whether it is produced and processed manually or digitally. Once students understand what tasks need to be performed, they are better equipped to explore different and better ways of performing these tasks through technology.

Finally, manual procedures facilitate understanding internal control activities, including segregation of functions, supervision, independent verification, audit trails, and access controls. Because human nature lies at the heart of many internal control issues, we should not overlook the importance of this aspect of the information system.

THE FLAT-FILE MODEL

The flat-file approach is most often associated with so-called legacy systems. These are large mainframe systems that were implemented in the late 1960s through the 1980s. Organizations today still use these systems extensively. Eventually, modern database management systems will replace them, but in the meantime accountants must continue to deal with legacy system technologies.

The flat-file model describes an environment in which individual data files are not related to other  files. End users in this environment own their data files rather than share them with other users. Thus, stand-alone applications rather than integrated systems perform data processing.

When multiple users need the same data for different purposes, they must obtain separate data sets  structured to their specific needs. Figure 1-12 illustrates how customer sales data might be presented to three different users in a durable goods retailing organization. The accounting function needs customer sales data organized by account number and structured to show outstanding balances. This is used for customer billing, AR maintenance, and financial statement preparation. Marketing needs customer sales history data organized by demographic keys. They use this for targeting new product promotions and for selling product upgrades. The product services group needs customer sales data organized by products and structured to show scheduled service dates. Such information is used for making after-sales contacts with customers to schedule preventive maintenance and to solicit sales of service agreements.

The data redundancy demonstrated in this example contributes to three significant problems in the  flat-file environment: data storage, data updating, and currency of information. These and other problems associated with flat files are discussed in the following sections.

Data Storage

An efficient information system captures and stores data only once and makes this single source available to all users who need it. In the flat-file environment, this is not possible. To meet the private data needs of users, organizations must incur the costs of both multiple collection and multiple storage procedures. Some commonly used data may be duplicated dozens, hundreds, or even thousands of times.

Data Updating

Organizations have a great deal of data stored in files that require periodic updating to reflect changes. For example, a change to a customer’s name or address must be reflected in the appropriate master files. When users keep separate files, all changes must be made separately for each user. This adds significantly to the task and the cost of data management.

Currency of Information

In contrast to the problem of performing multiple updates is the problem of failing to update all the user files affected by a change in status. If update information is not properly disseminated, the change will not be reflected in some users’ data, resulting in decisions based on outdated information.

Dependency

Another problem with the flat-file approach is the user’s inability to obtain additional information as his or her needs change. This problem is called task-data dependency. The user’s information set is con- strained by the data that he or she possesses and controls. Users act independently rather than as members of a user community. In such an environment, it is very difficult to establish a mechanism for the formal sharing of data. Therefore, new information needs tend to be satisfied by procuring new data files. This takes time, inhibits performance, adds to data redundancy, and drives data management costs even higher.

Flat Files Limit Data Integration

The flat-file approach is a single-view model. Files are structured, formatted, and arranged to suit the specific needs of the owner or primary user of the data. Such structuring, however, may exclude data attributes that are useful to other users, thus preventing successful integration of data across the organization. For example, because the accounting function is the primary user of accounting data, these data are often captured, formatted, and stored to accommodate financial reporting and generally accepted accounting principles. This structure, however, may be useless to the organization’s other (nonaccounting) users of accounting data (GAAP), such as the marketing, finance, production, and engineering functions. These users are presented with three options: (1) do not use accounting data to support decisions; (2) manipulate and massage the existing data structure to suit their unique needs; or (3) obtain additional private sets of the data and incur the costs and operational problems associated with data redundancy.

In spite of these inherent limitations, many large organizations still use flat files for their general ledger and other financial systems. Most members of the data processing community assumed that the end of the century would see the end of legacy systems. Instead, corporate America invested billions of dollars making these systems year-2000 (Y2K) compliant. Legacy systems continue to exist because they add value for their users, and they will not be replaced until they cease to add value. Students who may have to work with these systems in practice should be aware of their key features.

THE DATABASE MODEL

An organization can overcome the problems associated with flat files by implementing the database model to data management. Figure 1-13 illustrates how this approach centralizes the organization’s data into a common database that is shared by other users. With the organization’s data in a central location, all users have access to the data they need to achieve their respective objectives. Access to the data resource is controlled by a database management system (DBMS). The DBMS is a special software sys- tem that is programmed to know which data elements each user is authorized to access. The user’s pro- gram sends requests for data to the DBMS, which validates and authorizes access to the database in accordance with the user’s level of authority. If the user requests data that he or she is not authorized to access, the request is denied. Clearly, the organization’s procedures for assigning user authority are an important control issue for auditors to consider.

The most striking difference between the database model and the flat-file model is the pooling of data into a common database that all organizational users share. With access to the full domain of entity data, changes

in user information needs can be satisfied without obtaining additional private data sets. Users are constrained only by the limitations of the data available to the entity and the legitimacy of their need to access it. Through data sharing, the following traditional problems associated with the flat-file approach may be overcome:

Elimination of data redundancy. Each data element is stored only once, thereby eliminating data redundancy and reducing data collection and storage costs. For example, customer data exist only once, but is shared by accounting, marketing, and product services users. To accomplish this, the data are stored in a generic format that supports multiple users.

Single update. Because each data element exists in only one place, it requires only a single update procedure. This reduces the time and cost of keeping the database current.

Current values. A single change to a database attribute is automatically made available to all users of the attribute. For example, a customer address change is immediately reflected in the marketing and product services views when the billing clerk enters it.

Flat-file and early database systems are called traditional systems. Within this context, the term traditional means that the organization’s information systems applications (its programs) function independently of each other rather than as an integrated whole. Early database management systems were designed to interface directly with existing flat-file programs. Thus, when an organization replaced its flat files with a database, it did not have to spend millions of dollars rewriting its existing programs. Indeed, early database applications performed essentially the same independent functions as their flat-file counterparts.

Another factor that limited integration was the structured database models of the era. These models were inflexible and did not permit the degree of data sharing that is found in modern database systems. Whereas some degree of integration was achieved with this type of database, the primary and immediate advantage to the organization was the reduction in data redundancy.

True integration, however, would not be possible until the arrival of the relational database model. This flexible database approach permits the design of integrated systems applications capable of support- ing the information needs of multiple users from a common set of integrated database tables. We should note, however, that the relational database model merely permits integration to occur; integration is not guaranteed. Poor systems design can occur under any model. In fact, most organizations today that employ a relational database run applications that are traditional in design and do not make full use of relational technology. The two remaining models to be discussed (REA and ERP) employ relational data- base technology more effectively.

THE REA MODEL

REA is an accounting framework for modeling an organization’s critical resources, events, and agents (REA) and the relationships between them. Once specified, both accounting and nonaccounting data about these phenomena can be identified, captured, and stored in a relational database. From this repository, user views can be constructed that meet the needs of all users in the organization. The availability of multiple views allows flexible use of transaction data and permits the development of AIS that promote, rather than inhibit, integration.

The REA model was proposed in 1982 as a theoretical model for accounting.3 Advances in database  technology have focused renewed attention on REA as a practical alternative to the classic accounting framework. The following summarizes the key elements of the REA models.

Resources

Economic resources are the assets of the organization. They are defined as objects that are both scarce and under the control of the enterprise. This definition departs from the traditional model because it does not include AR. An account receivable is an artifact record used simply to store and transmit data. Because it is  not an essential element of the system, it does not need to be included in the database. Instead, AR values are derived from the difference between sales to customers and the cash received in payment of sales.

Events

Economic events are phenomena that affect changes in resources. They can result from activities such as production, exchange, consumption, and distribution. Economic events are the critical information elements of the accounting system and should be captured in a highly detailed form to provide a rich database.

Agents

Economic agents are individuals and departments that participate in an economic event. They are parties both inside and outside the organization with discretionary power to use or dispose of economic resources. Examples of agents include sales clerks, production workers, shipping clerks, customers, and vendors.

The REA model requires that accounting phenomena be characterized in a manner consistent with the development of multiple user views. Business data must not be preformatted or artificially constrained and should reflect all relevant aspects of the underlying economic events. As such, REA procedures and databases are structured around events rather than accounting artifacts such as journals, ledgers, charts of accounts, and double-entry accounting. Under the REA model, business organizations prepare financial statements directly from the event database. The following sales and cash receipts events for a hypotheti- cal retailer can be used to illustrate the inherent differences between classic and REA accounting:

Sept. 1: Sold 5 units of product X 21 @ $30 per unit and 10 units of product Y33 @ $20 per unit to customer Smith (Total sale ¼ $350). The unit cost of the inventory is $16 and $12, respectively (Total CGS ¼ $200).

Sept. 30: Received $200 cash from customer Smith on account, check number 451.

In flat-file or non-REA database systems, the two events would be recorded in a set of classic accounts like those shown in Figure 1-14. This involves summarizing the events to accommodate the account structure. However, the details of the transactions are not captured under this approach. An REA accounting system would capture these transactions in a series of relational database tables that emphasize events rather than accounts. This is illustrated in Figure 1-15. Each table deals with a

separate aspect of the transaction. Data pertaining to the customer, the invoice, specific items sold, and so on can thus be captured for multiple uses and users. The tables of the database are linked via common attributes called primary keys (PK) and embedded foreign keys (FK) that permit integration. In contrast, the files in the traditional system are independent of each other and thus cannot accommodate such detailed data gathering. As a result, traditional systems must summarize event data at the loss of poten- tially important facts.

Traditional accounting records including journals, ledgers, and charts of accounts do not exist as physical files or tables under the REA model. For financial reporting purposes, views or images of traditional accounting records are constructed from the event tables. For example, the amount of Smith’s account re- ceivable balance is derived from [total sales (Quant sold * Sale price) less cash received (Amount) ¼ 350 - 200 ¼ 150]. If necessary or desired, journal entries and general ledger amounts can also be derived from these event tables. For example, the Cost-of-Goods-Sold control account balance is (Quant sold * Unit cost) summed for all transactions for the period.

REA is a conceptual model, not a physical system. Many of its tenets, however, are found within advanced database systems. The most notable application of REA philosophy is seen in the proliferation of ERP systems, which are discussed in the following section.

ENTERPRISE RESOURCE PLANNING SYSTEMS

Enterprise resource planning (ERP) is an information system model that enables an organization to automate and integrate its key business processes. ERP breaks down traditional functional barriers by facilitating data sharing, information flows, and the introduction of common business practices among all organizational users. The implementation of an ERP system can be a massive undertaking that can span several years. Because of the complexity and size of ERPs, few organizations are willing or able to com- mit the necessary financial and physical resources and incur the risk of developing an ERP system in- house. Hence, virtually all ERPs are commercial products. The recognized leaders in the market are SAP, Oracle, J.D. Edwards & Co., and PeopleSoft Inc.

ERP packages are sold to client organizations in modules that support standard processes. Some common ERP modules include:

Asset Management Financial Accounting Human Resources  Industry-Specific Solutions Plant Maintenance Production Planning Quality Management  Sales and Distribution Inventory Management  One of the problems with standardized modules is that they may not always meet the organization’s exact needs. For example, a textile manufacturer in India implemented an ERP package only to discover that extensive, unexpected, and expensive modifications had to be made to the system. The ERP would not allow the user to assign two different prices to the same bolt of cloth. The manufacturer charged one price for domestic consumption, but another (four times higher) for exported products. That particular ERP system, however, provided no way to assign two prices to the same item while maintaining an accurate inventory count.

Organizations that hope to successfully implement an ERP will need to modify their business processes to suit the ERP, modify the ERP to suit their business, or, more likely, modify both. Often, additional software applications need to be connected to the ERP to handle unique business functions, particularly industry-specific tasks. These applications, often called bolt-ons, are not always designed to communicate with ERP packages. The process of creating a harmonious whole can be quite complex and sometimes fails, resulting in significant losses to the organization. ERP packages are enormously expensive, but the savings in efficiencies should be significant. Organization management should exercise great care in deciding which, if any, ERP is best for them.

The evolution of information systems models outlined in this section provides a framework for much  of the material contained in this book. Chapters 2 through 8 deal with business processes, security, fraud, controls, and a variety of other issues related to traditional (manual, flat-file, and early database) systems. Chapters 9 through 12 examine advanced database systems, the REA model, ERP, and other emerging technologies.

The Role of the Accountant

The final section of this chapter deals with the accountant’s relationship to the information system. Accountants are primarily involved in three ways: as system users, designers, and auditors.

ACCOUNTANTS AS USERS

In most organizations, the accounting function is the single largest user of IT. All systems that process fi- nancial transactions impact the accounting function in some way. As end users, accountants must provide a clear picture of their needs to the professionals who design their systems. For example, the accountant must specify accounting rules and techniques to be used, internal control requirements, and special algo- rithms such as depreciation models. The accountant’s participation in systems development should be active rather than passive. The principal cause of design errors that result in system failure is the absence of user involvement.

ACCOUNTANTS AS SYSTEM DESIGNERS

An appreciation of the accountant’s responsibility for system design requires a historic perspective that predates the computer as a business information tool. Traditionally, accountants have been responsible for key aspects of the information system, including assessing the information needs of users, defining the content and format of output reports, specifying sources of data, selecting the appropriate accounting rules, and determining the controls necessary to preserve the integrity and efficiency of the information system.

These traditional systems were physical, observable, and unambiguous. The procedures for processing  information were manual, and the medium for transmitting and storing data was paper. With the arrival of the computer, computer programs replaced manual procedures, and paper records were stored digitally. The role accountants would play in this new era became the subject of much controversy. Lacking com- puter skills, accountants were generally uncertain about their status and unwilling to explore this emerging technology.

Many accountants relinquished their traditional responsibilities to the new generation of computer professionals who were emerging in their organizations. Computer programmers, often with no accounting or business training, assumed full responsibility for the design of AIS. As a result, many systems violated accounting principles and lacked necessary controls. Large system failures and computer frauds marked this period in accounting history. By the mid-1970s, in response to these problems, the accounting profes- sion began to reassess the accountant’s professional and legal responsibilities for computer-based systems.

Today, we recognize that the responsibility for systems design is divided between accountants and IT professionals as follows: the accounting function is responsible for the conceptual system, and the IT function is responsible for the physical system. To illustrate the distinction between conceptual and physical systems, consider the following example:

The credit department of a retail business requires information about delinquent accounts from the AR department. This information supports decisions made by the credit manager regarding the credit- worthiness of customers.

The design of the conceptual system involves specifying the criteria for identifying delinquent customers and the information that needs to be reported. The accountant determines the nature of the information required, its sources, its destination, and the accounting rules that need to be applied. The physical system is the medium and method for capturing and presenting the information. The computer professionals deter- mine the most economical and effective technology for accomplishing the task. Hence, systems design should be a collaborative effort. Because of the uniqueness of each system and the susceptibility of sys- tems to serious error and even fraud, the accountant’s involvement in systems design should be pervasive. In later chapters, we shall see that the active participation of accountants is critical to the system’s success.

ACCOUNTANTS AS SYSTEM AUDITORS

Auditing is a form of independent attestation performed by an expert—the auditor—who expresses an opinion about the fairness of a company’s financial statements. Public confidence in the reliability of internally produced financial statements rests directly on their being validated by an independent expert auditor. This service is often referred to as the attest function. Auditors form their opinions based on a systematic process that will be explained in Chapter 15.

Both internal and external auditors conduct audits. External auditing is often called independent audit- ing because certified public accounting (CPA) firms that are independent of the client organization’s management perform them. External auditors represent the interests of third-party stakeholders in the or- ganization, such as stockholders, creditors, and government agencies.

External Auditing

Historically, the external accountant’s responsibility as a systems auditor was limited to the attest func- tion described previously. In recent years this role has been expanded by the broader concept of assurance. The Big Four public accounting firms have now renamed their traditional audit functions assurance services.

ASSURANCE. Assurance services are professional services, including the attest function, that are designed to improve the quality of information, both financial and nonfinancial, used by decision makers. For example, a client may contract assurance services to obtain an opinion as to the quality or marketability of a product. Alternatively, a client may need information about the efficiency of a production process or the effectiveness of their network security system. A gray area of overlap exists between assurance and consulting services, which auditors must avoid. They were once allowed to provide consulting services to audit clients. This is now prohibited under SOX legislation. These issues are discussed in later chapters.

IT AUDITING. IT auditing is usually performed as part of a broader financial audit. The organizational unit responsible for conducting IT audits may fall under the assurance services group or be independent. Typically they carry a name such as IT Risk Management, Information Systems Risk Management, or Global Risk Management. The IT auditor attests to the effectiveness of a client’s IT controls to establish their degree of compliance with prescribed standards. Because many of the modern organization’s internal controls are computerized, the IT audit may be a large portion of the overall audit. We examine IT controls, risks, and auditing issues in Chapters 15, 16, and 17.

Internal Auditing

Internal auditing is an appraisal function housed within the organization. Internal auditors perform a wide range of activities on behalf of the organization, including conducting financial statement audits, examining an operation’s compliance with organizational policies, reviewing the organization’s com- pliance with legal obligations, evaluating operational efficiency, detecting and pursuing fraud within the firm, and conducting IT audits. As you can see, the tasks that external and internal auditors perform are similar. The feature that most clearly distinguishes the two groups is their respective constituencies. External auditors represent third-party outsiders, whereas internal auditors represent the interests of management.

Summary

The first section of this chapter introduced basic systems concepts and presented a framework for distinguishing between accounting information systems and management information systems. This distinction is related to the types of transactions these systems process. AIS applications process financial trans- actions, and MIS applications process nonfinancial transactions. The section then presented a general model for accounting in- formation systems. The model is composed of four major tasks that exist in all AIS applications: data collection, data processing, database management, and information generation.

The second section examined the relationship between organizational structure and the information system. It  focused on functional segmentation as the predominant method of structuring a business and examined the functions of a typical manufacturing firm. The section presented two general methods of organizing the IT function: the centralized approach and the distributed approach.

The third section reviewed the evolution of AIS models. Each new model evolved because of the shortcomings and limitations of its predecessor. As new approaches evolved, however, the predecessor or legacy systems often remained in service. Thus, at any point in time, various generations of systems coexist across different organizations and even within a single enterprise. Five AIS models were examined.

The final section of this chapter examined three roles of accountants as (1) users of AIS, (2) designers of AIS, and (3) auditors of AIS. In most organizations, the accounting function is the single largest user of the AIS. The IT function is respon- sible for designing the physical system, and the accounting function is responsible for specifying the conceptual system.

Auditing is an independent attestation performed by the auditor, who expresses an opinion about the fairness of a company’s financial statements. Both external and internal auditors conduct IT audits. The IT auditor attests to the effectiveness of a client’s IT controls to establish their degree of compliance with prescribed standards.