Managing the Systems Development Life Cycle:The Accountant’s Role in Managing the SDLC.

By -

The Accountant’s Role in Managing the SDLC

The SDLC process is of interest to accountants for two reasons. First, the creation of an information system represents a significant financial transaction that consumes both financial and human resources. Systems development is like any manufacturing process that produces a complex product through a series of stages. Such transactions must be planned, authorized, scheduled, accounted for, and controlled. Accountants are as concerned with the integrity of this process as they are with any manufacturing process that has financial resource implications.

The second, and more pressing, concern for accountants is with the products that emerge from the SDLC. The quality of accounting information systems rests directly on the SDLC activities that produce them. These systems are used to deliver accounting information to internal and external users. The accountant’s responsibility is to ensure that the systems apply proper accounting conventions and rules and possess adequate controls. Therefore, accountants are concerned with the quality of the process that produces accounting information systems. For example, a sales order system produced by a defective SDLC may suffer from serious control weaknesses that introduce errors into databases and, ultimately, the financial statements.

HOW ARE ACCOUNTANTS INVOLVED WITH SDLC?

Accountants are involved in systems development in three ways. First, accountants are users. All systems that process financial transactions impact the accounting function in some way. Like all users, accountants must provide a clear picture of their problems and needs to the systems professional. For example, accountants must specify accounting techniques to be used; internal control requirements, such as audit trails; and special algorithms, such as depreciation models.

Second, accountants participate in systems development as members of the development team. Their involvement often extends beyond the development of strictly accounting information systems applications. Systems that do not process financial transactions may still draw on accounting data. The accountant may be consulted to provide advice or to determine if the proposed system constitutes an internal control risk.

Third, accountants are involved in systems development as auditors. Accounting information systems must be auditable. Some computer audit techniques require special features that must be designed into the system. The auditor/accountant has a stake in such systems and must be involved early in their design.

THE ACCOUNTANT’S ROLE IN SYSTEMS STRATEGY

Auditors routinely review the organization’s systems strategy. History has shown that careful systems planning is a cost-effective activity in reducing the risk of creating unneeded, unwanted, inefficient, and ineffective systems. Both internal and external auditors have vested interests in this outcome.

THE ACCOUNTANT’S ROLE IN CONCEPTUAL DESIGN

The accountant plays an important role in the conceptual design of the system. He or she must recognize control implications of each alternative design and ensure that accounting conventions and legal requirements are understood. These issues need not be specified in detail at this point, but they should be recognized as items to be addressed during the construct phase of the system. Furthermore, the auditability of a system depends in part on its design characteristics. Some computer auditing techniques require systems to be designed with built-in audit features. Such features require resources and need to be considered at conceptual design.

THE ACCOUNTANT’S ROLE IN SYSTEMS SELECTION

The economic feasibility of proposed systems is of primary concern to accountants. Specifically, the accountant should ensure that:

• Only escapable costs are used in calculations of cost-savings benefits.

• Reasonable interest rates are used in measuring present values of cash flows.

• One-time and recurring costs are completely and accurately reported.

• Realistic useful lives are used in comparing competing projects.

• Intangible benefits are assigned reasonable financial values.

Errors, omissions, and misrepresentations in the accounting for such items can distort the analysis and result in a suboptimal decision.

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

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However
Read more