Organizations assume risks in the normal conduct of doing business. These risks represent potential damaging events that might produce losses. Controls or safeguards are installed to reduce these risks. If controls are insufficient, the organization is overexposed and is likely to suffer losses or operate at a less efficient level than competitors. ERP application customers, other users, and control-oriented personnel, such as auditors, frequently want to verify that processing is correct.

Advertisement

In any IT environment presents unique vulnerabilities and threats to an organization. Vulnerability is a weakness or a flaw in an IT-based system that may be exploited by a threat that can cause destruction or by misuse of the system’s assets or resources. Threats can be environmental (e.g., fire, water damage, earthquakes, hurricanes, etc.) or people- oriented (e.g., errors, omissions, intentional acts of violence, fraud, etc.). When a threat materializes and takes advantage of a system’s vulnerabilities, a damaging event causes a loss. The risks of damaging events cannot be totally eliminated, but the use of controls can reduce such risks to an acceptable level.

If you are business owner or a controller of businesses who implement ERP system; measuring, assessing, controlling and eliminating those risks are on your list. 

 

Risk Analyses

A risk analysis of an organization’s ERP systems, their existing controls, and their vulnerabilities results in the loss potential for the system, with an estimated likelihood of occurrence. This loss potential in damages must be represented in terms of dollar value.

A risk analysis of an ERP system performs two important functions:

  1. Searches out an ERP system’s vulnerabilities and the probabilities of threats materializing to exploit these vulnerabilities.
  2. Calculates the damage or loss to its assets that could be produced by the resulting damaging events.

 

A third component, to recommend controls or safeguards that would reduce the damages or loss to an acceptable level (through the use of a cost/benefit analysis), might also be added. An ERP system environment’s vulnerabilities and set of threats should be assessed to arrive at some estimate of possible damaging events. Such an assessment would also review the strengths of existing controls.

A vulnerability assessment is conducted as part of a risk analysis. The vulnerability assessment is a major assessment of the adequacy of an ERP’s system. Organizations must first identify vulnerabilities and threats; and then determine whether controls are adequate to reduce the resulting risks to an acceptable level. If not, it will be necessary to correct and guard against threats.

 

Risks In An ERP Environment

The risks in an ERP environment include both those present in a manual processing environment and those that are unique or increased in an ERP environment. The use of ERP systems clearly introduces additional risks into the system environment. These additional risks include problems associated with:

  1. Improper use of technology.
  2. Inability to control technology.
  3. Inability to translate user needs into technical requirements.
  4. Illogical processing.
  5. Inability to react quickly (to stop processing).
  6. Cascading of errors.
  7. Repetition of errors.
  8. Incorrect entry of data.
  9. Concentration of data.
  10. Inability to substantiate processing.

 

Each of these risks is discussed individually below, including many of the conditions that cause the risks to occur.

 

Improper Use of Technology

Information technology provides systems analysts and programmers with a variety of processing capabilities. This technology must be matched to the user’s needs in order to best meet those needs. A mismatch of technology and needs can result in an unnecessary expenditure of organizational resources.

One of the more common misuses of technology is the introduction of new technology prior to the clear establishment of its need. For example: many organizations introduce database technology without clearly establishing the need for that technology. Experience has shown that the early users of a new technology frequently consume large amounts of resources learning to use that new technology.

The conditions that lead to the improper use of technology include:

  1. Premature user of new hardware technology.
  2. Early user of new software technology.
  3. Minimal planning for the installation of new hardware and software technology.
  4. Systems analyst/programmer improperly skilled in the use of technology.

 

Inability to Control Technology

IT personnel spend most of their effort on the problems associated with the implementation of new technology. Numerous studies imply that there is often too little time left to develop and install technological controls. As a result, resources are expended to correct technological problems.

Controls are needed over the technological environment. These controls ensure that the proper version of the proper program is in production at the right time; that the proper files are mounted; and that the operators perform the proper instructions. Adequate procedures must be developed to prevent, detect, and correct problems in the operating environment. The proper data must be maintained and retrievable when needed.

The conditions that result in uncontrolled technology include:

  1. Selection of vendor-offered system control capabilities by systems programmers without considering audit needs.
  2. Too many control trade-offs for operational efficiency.
  3. Inadequate restart/recovery procedures.
  4. Inadequate control over different versions of programs.
  5. Inadequate control over schedulers, system operators, tape librarians, print capabilities, and data transmission capabilities.
  6. Inadequate review of outputs.

 

Inability to Translate User Needs into Technical Requirements

One of the major failures of information technology has been a communication failure between users and technical personnel. In many organizations, users cannot adequately express their needs in terms that facilitate the implementation of ERP applications. And the technical people are often unable to appreciate the concerns and requirements of their users.

The risk associated with failure to satisfy user needs is complex. Exposures include:

  1. Failure to implement needs because users were unaware of technical capabilities.
  2. Improperly implemented needs because the technical personnel did not understand user requirements.
  3. Users accepting improperly implemented needs because they are unsure how to specify changes.
  4. Building of redundant manual systems to compensate for weaknesses in ERP applications.

 

Conditions that can lead to the inability to translate user needs into technical requirements include:

  1. Users without technical IT skills.
  2. Technical people without sufficient understanding of user requirements.
  3. User’s inability to specify requirements in sufficient detail.
  4. Multi-user systems with no user in charge of the system.

 

Illogical Processing

Illogical processing is the performance of an automated event that would be highly unlikely in a manual processing environment; for example, producing a payroll check for a clerical individual for over $1 million. This is possible in an automated system due to programming or hardware errors, but highly unlikely in a manual system.

ERP applications do not have the same human oversight as manual systems. In addition, fewer people have a good understanding of the processing logic of ERP applications. Thus, in some instances, illogical processing may not be readily recognizable.

Conditions that can result in illogical processing include:

  1. Failure to check for unusually large amounts on output documents.
  2. Fields that are either too small or too large, thereby impacting the completeness, accuracy, or efficiency of the data being processed.
  3. Failure to scan output documents.

 

Inability to React Quickly

ERP applications are valuable because they are able to satisfy user needs on a timely basis. Some of these needs are predetermined and reports are prepared on a regular basis to meet these needs. Other needs occur periodically and require special actions to satisfy. If the ERP application is unable to satisfy these special needs on a timely basis, redundant systems may be built for that purpose.

One of the measures of an ERP application’s success is the speed with which special requests can be satisfied. Some of the newer online database applications that include a query language can satisfy some requests within a very short time span. On the other hand, some of the older batch-oriented applications may take several days or weeks to satisfy a special request. In some instances, the structure of the application system is an inhibits satisfying requests. For example, if an auditor wants all of the supporting information for a supply requisition in a tape-batched system, the cost and difficulty of satisfying that request may be prohibitive. That requisition could be spread over many weeks of processing, due to back orders, returned shipments, and shipping errors.

The evidence supporting the transaction may be spread over many tape files and the cost of processing those files may be exorbitant. The conditions that make ERP applications unable to react quickly include:

  1. Computer time is unavailable to satisfy the request, or computer terminals/microcomputers are not readily accessible to users.
  2. The structure of the computer files is inconsistent with the information requested.
  3. General-purpose extract programs are not available to satisfy the desired request.
  4. The cost of processing exceeds the value of the information requested.

 

Cascading of Errors

Cascading of errors is the domino effect of errors throughout an application system. An error in one part of the program or application triggers a second yet unrelated error in another part of the application system. This second error may trigger a third error, and so on.

 

The cascading of error risk is frequently associated with making changes to application systems. A change is made and tested in the program in which the change occurs. However, some condition has been altered as a result of the change, which causes an error to occur in another part of the application system.

Cascading of errors can occur between applications. This risk intensifies as applications become more integrated. For example, a system that is accepting orders may be tied through a series of applications to a system that replenishes inventory based upon orders. Thus, an insignificant error in the order-entry program can “cascade” through a series of applications resulting in a very serious error in the inventory replenishment program.

The types of conditions that lead to cascading of errors include:

  1. Inadequately tested applications.
  2. Failure to communicate the type and date of changes being implemented.
  3. Limited testing of program changes.

 

Repetition of Errors

In a manual processing environment, errors are made individually. Thus, a person might process one item correctly, make an error on the next, process the next twenty correctly, and then make another error.

In ERP systems, the rules are applied consistently. Thus, if the rules are correct, processing is always correct. But, if the rules are erroneous, processing will always be erroneous.

 

Errors can result from application programs, hardware failures, and failures in vendor-supplied software. For example, a wrong percentage may have been entered for tax deductions. Thus, every employee for that pay period will have the wrong amount deducted for tax purposes.

The conditions that cause repetition of errors include:

  1. Insufficient program testing.
  2. Inadequate checks on entry of master information.
  3. Failure to monitor the results of processing.

 

Incorrect Entry of Data

In ERP applications, there is a mechanical step required to convert input data into machine-readable format. In the process of conducting this task, errors can occur. Data that was properly prepared and authorized may be entered into ERP applications incorrectly.

Much of the data entered into batch-type systems is entered using a keyboard device. Some of these devices are keypunch machines and key-to-disk machines. The data originator manually transcribes the input information onto some type of form, and the form is given to a key operator to enter on computer media. During this keying process, errors can be made.

In the newer technology, data can be originated and entered at the same time. For example, order entry clerks receive orders by telephone and key them directly into computer memory. However, errors can still occur during this process.

Other methods of data entry include optical scanners, process control computers that monitor production machinery, automatic cash dispensers and point-of-sale equipment. However, these are all mechanical devices and thus subject to failure.

Conditions that can cause incorrect entry of data include:

  1. Human errors in keying data.
  2. Mechanical failure of hardware devices.
  3. Misinterpretation of characters or meaning of manually recorded input.
  4. Misunderstanding of data entry procedures.
  5. Inadequate data verification procedures.

 

Concentration of Data

ERP applications concentrate data in an easy-to-access format. In manual systems, data is voluminous and stored in many places. It is difficult for an unauthorized individual to spend much time browsing undetected through file cabinets or other manual storage areas.

With ERP media, unauthorized individuals can browse using computer programs. This may be difficult to detect without adequate safeguards. In addition, the data can be copied quickly without leaving any visible trail or destroying the original data. Thus, the owners of the data may not be aware that the data has been compromised.

Database technology increases the risk of data manipulation and compromise. The more data that is stored in a single place, the greater the value of that data to an unauthorized individual. For example, the information about an individual in the payroll application is restricted to current pay information. But, when that data is coupled with personnel history, not only current pay information, but also pay history, individual skills, years and progression of employment, and perhaps performance evaluation is available.

Concentration of data increases the problems of greater reliance on a single piece of data and reliance on a single file. If the data entered is erroneous, the more applications that rely on that piece of data, the greater the impact of the error. And the more applications that use the concentrated data, the greater the impact when that data is unavailable due to problems with the hardware or software used for processing it.

The conditions that can create problems due to the concentration of data in ERP applications include:

  1. Erroneous data and its impact on multiple users of that data.
  2. Impact of hardware and software failures that ordinarily make the data available to multiple users.
  3. Inadequate access controls enabling unauthorized access to data.
  4. Inefficient use of system for data storage and/or retrieval, which may impact response time or computer capacity.

 

Inability to Substantiate Processing

ERP applications should contain the capability to substantiate processing. This substantiation includes both the ability to reconstruct the processing of a single transaction and the ability to reconstruct control totals. ERP applications should be able to produce all of the source transactions that support a control total as well as substantiate that any source document is contained in a control total.

Application systems need to substantiate processing to correct errors and to prove that processing is correct. When errors occur, computer personnel need to pinpoint the cause so they can be corrected.

Conditions that may cause the inability to substantiate processing include:

  1. Evidence is not retained long enough.
  2. The evidence from intermediate processing is not retained.
  3. Evidence is not independently reviewed for quality assurance and/or data integrity.
  4. Outputs are not reviewed for quality by the users.
  5. The cost of substantiating processing exceeds the benefits derived from the process.