Business is all about taking risks. But intelligent managers know how to manage risks, thus preventing accidental losses as well as other operational, financial, and strategic risks—including fraud.
To manage business risks by using technology, we must first understand and prioritize the risks a specific business faces, and then understand how IT can help that business. Then we can come to understand how those risks intersect with the IT systems a business might already have in place.
One risk within your business may stem from operating in an e-commerce environment. In that case, you want to know how IT is supporting the Web portal. Do people simply view a catalog, or do they order online and log back into your system later to view their order status? How does that portal tie in with your back-end systems and business data?
Or maybe you have multiple business units, several running on a top-tier enterprise resource planning (ERP) system like IFS Applications. But a Mexican unit is still running a homegrown application, passing its data to you in spreadsheets modified to reflect currency exchange. The manual processes involved in this data transfer and data alteration represent a business risk that could be mitigated by the built-in security features of an ERP system.
So, while technology might be designed to assist in risk management, that technology must still be configured and used intelligently to deliver this business benefit.
Indeed, intelligent use of an ERP system can not only help ensure compliance with legal requirements and accounting rules, but it can also help prevent fraud. An ERP application and its user permissions settings can prevent theft. Aggressive and intelligent use of an ERP system's safeguards can save time during auditing. Properly configuring an ERP application can help protect your company from fraud and costly corporate mistakes in a number of ways. Following are three practical approaches a business can take to protect its assets through its ERP system.
1. Use a top-down approach to identify risks.
Business risk management requires a top-down approach. Senior management often focuses its efforts on creating competitive advantages and might not see one in spending extra money on compliance. But even companies not immediately affected by regulations like the US Sarbanes-Oxley Act (SOX) and the Health Insurance Portability and Accountability Act (HIPAA) of 1996 can benefit from applying some of the principles required for compliance to their business. Efforts to comply with basic data security and risk prevention guidelines can even further reduce the risk of financial loss through administrative mistakes or fraud. The specific steps necessary to ensure compliance with these guidelines will differ from one company or business model to the next, but any company needs to pay attention to such basics as good financial statements, data security, privacy, and housing of key information—and how that information affects things like ensuring accurate financial reporting.
Part of this top-down approach involves identifying what information is key to your business. For a manufacturer, this data might consist of accounting, payroll, and health insurance information, plus things like physical plant assets and inventory. In contrast, a professional services environment is much simpler, with key information consisting of things like customer service and payroll data, with the only other real assets consisting of phones and perhaps leased office space.
Of course, this information comes from the heart of a business: its key business processes, or the mechanisms by which resources flow in and out of the company. When these processes differ, they prevent different risks. A company selling a small number of high-value products (industrial equipment, for instance) to a small number of customers faces a very different risk profile than a company selling hundreds of thousands of items to a large number of customers.
A company serving a smaller number of customers with very high-value products needs to make sure that only authorized people are able to set up new customers in their accounting systems. Consequently, the company must be careful to ensure that payment terms, credit limits, and other controls are set up properly.
However, the customer creation process will not be a critical control point for a company with a higher volume of customers and lower value per sale. It is important to understand your business flow and transaction volumes and the implications for relationships with your trading partners. An ERP system can be an excellent tool for formalizing processes for setting up new customers, and perhaps more importantly for setting up supplier relationships in your systems.
Surprisingly, many companies with powerful ERP packages in place circumvent those controls by using Microsoft Excel more than they say they do. Unmonitored use of Excel and other tools outside of an enterprise application may be of special concern during and after mergers and acquisitions. In a merger situation, a company must determine the maturity of the acquired company's IT tools and processes, and how best to integrate them into the existing systems. But at least during an interim period, the primary means of transferring information from the systems of the acquired company to its new parent may be unsecured spreadsheets.
Even without the challenges of mergers and acquisitions, a business might use outside tools like Hyperion as part of its reporting routines. Any time that tools outside an enterprise application are used, you need to ask how your data transfer methods can ensure completeness and accuracy in your business processes as data flows between two or three—or maybe more—separate and distinct systems. Using ad hoc tools like Excel—tools without a lot of built-in controls—means it's harder to guarantee data integrity. Taking measures to reduce alterations to your data outside of the ERP system makes a huge difference not only in preventing incorrect or fraudulent activity, but in streamlining your processes before an audit.
2. Harness the general user controls in your application.
Even when a company keeps 80 percent of its information in a top-tier ERP system and minimizes risks resulting from the use of ad hoc tools, it may not be familiar with the capabilities of its ERP system and how that system can be configured for risk management. Often, these capabilities are overlooked during implementation because risk management was not a main deliverable in the project proposal—and of course the company isn't anticipating an audit or attempted fraud. Because risk management can take a backseat to other deliverables, it's important for project managers and consultants to act as advocates and encourage people to consider three main risk management areas during ERP planning and implementation:
i) Prevent mistakes and fraud through role-based security. This is an ERP feature not everyone understands. You must ensure the right people are assigned to the right activities and prevented from engaging in the wrong activities. Generally, this requires a separation of powers, as you don't want to allow one person to complete every activity within a business cycle—whether that cycle is orders-to-cash or purchase-to-pay. For instance, if a single person can create a supplier, create a purchase order for that supplier, purchase the product, and cut and send a check, how do you ensure that person's cousin doesn't suddenly become a supplier? If that person also has access to inventory records, he or she could make an adjustment to inventory to hide the fact that a product from his or her imaginary supplier was never received. Physical inventory would never catch it, but the company would have paid for the imaginary product, and before the discrepancy is detected, the perpetrator could have inventory-adjusted it out. Some enterprise applications simplify identification and elimination of role-based security risks (see figure 1).
Figure 1. Segregation of duties analysis (provided by IFS North America).
Even some companies that attempt to segregate all the necessary functions to deliver role-based security still employ a financial clerk. This clerk can perform a number of tasks for accounts receivable, accounts payable, general ledger, and inventory adjustments. This violates a number of rules of financial segregation, despite the fact that the company is using a major ERP system designed to deliver financial segregation and role-based security, and in some cases separates those duties in other positions.
Correctly segregating duties to manage risk requires analysis of a company's key business cycles to identify which administrative roles need to be separate and distinct. This is not as simple as it sounds: in a small or midsized department, three people may have different roles in the company, but they are also each other's back-up. As each employee goes on vacation or takes sick leave, others assume the absent employee's duties, often with help from a system administrator. When the employee returns to the office, often there is not a process in place to remove the system permissions. Without diligent attention to assigning and managing these user permissions, before long, role-based security disintegrates.
Role-based security must be built into an application, defined and configured during implementation—and then maintained.
ii) Implement detective as well as preventive controls. Sometimes a company's administrative staff is too small to segregate roles with enough granularity to truly benefit from role-based security; or, it may operate in too complex a manner to make role-based security practical. But even when good preventive controls such as role-based security are in place, it is critical that a company can monitor employees' access to its business systems, and track what they do with that access.
Let's say that according to your role-based security schema, an individual can create customers in the system, but normally does not set up a whole customer record, leaving some of the work for others. It makes sense to monitor this individual on a monthly basis to track that key activity (see figure 2). Another way detective controls can be useful is if a double approval of check is required. The system may have to be altered when the president, for instance, is out of the office. But when the president returns, he or she can review a log to see what checks were cut in his or her absence.
Figure 2. Activity and event tracking (provided by IFS North America).
Detective controls can also be used to ensure that preventive role segregation controls are not being circumvented. You can do this by checking to see who is changing people's access in the system. Reviewing audit logs of permission changes is one way to maintain good segregation of duties.
Some activities, however, require timelier tracking and validation than permitted by reviewing log files. Fortunately, some ERP systems proactively send messages when specific events occur (see figure 3). For instance, perhaps your chief financial officer (CFO) wants to be automatically notified when anyone writes a check for over $10,000.00.
Figure 3. Functional area conflicts (provided by IFS North America).
The general awareness that the ERP system can create these alerts may serve to prevent some large-scale fraud. But there are cases when an employee knows of a limit and engages in fraudulent transactions under that limit. So, in addition to established limits that alert you to checks over $10,000.00, you could also create a control that notifies you if two or more transactions for over $9,000.00 or $8,000.00 occur in a defined period of time (for example, in 14 hours). Tracking an accumulation of minor events is a smart thing to do, as those minor events can combine to make a major one. But you may want to avoid broadcasting these incremental controls, or they could be rendered ineffective.
iii) Manage IT-driven risks. Apart from managing regular users, an ERP system should offer preventive and detective controls to thwart system administrators, database administrators, and programmers from making mistakes or engaging in conduct that could present financial risk to the company.
As is the case in identifying risk on the business-administrative side, managing risk on the IT side of an ERP package starts with an analysis of where business risk and IT intersect. This involves determining how the application's architecture supports the IT side. Situations should be avoided where a single person has access to the source code of the ERP application and the database it runs on. In such cases, an IT manager or system administrator can do more damage than a simple user of the system, and moreover may have the skill to conceal any illicit behavior during an audit. So it's important to use the ERP application's multitiered environment to segregate roles on the IT side, ensuring the database is secured on a separate server from the source code of the application.
Only the database administrator should have access to the database server, and someone else—like the ERP manager—should have access to the source code or the system itself. This ensures that the database administrator can change the raw data in the database, but not the application's source code; and that the ERP manager can change the source code of the application, but not the underlying data it's running on.
IT preventive and detective controls need to be closely intertwined. For instance, log files can track changes to tables made by the database administrator. But many times a database administrator is only given entry access, and can therefore enter but not change data in the application's underlying tables. If a database administrator is particularly astute, however, he or she could get into the log files that track changes to that database and alter them to hide various database transactions. That why it's important to consider using an ERP application's capacity to track when a database administrator is logged onto the server, and keep that information on yet another server to which the database administrator doesn't have access permissions (see figure 4). Consequently, in the event that there are unexplained inventory changes or other anomalies, you can compare the timing of those events with the administrator's activity in the system.
Figure 4. Table showing log-in times (provided by IFS North America).
Some ERP systems have migration utilities—a development environment that allows technical staff to identify new segments of code and move them into a quality assurance (QA) environment for testing. After testing, the code goes into a staging area or even directly into production. In order to allow rapid recovery, in case that new code does not perform as anticipated within the application, there is also typically a quick back-out capability that returns the system to its previous state.
It is important to consider an application's capabilities in tracking the activities of employees involved in change management and in moving code from a development environment to a live one. A system administrator could maliciously change the application's source code or even create a program that changes the source code by using a migration tool (built into many enterprise applications) to hide a piece of code that executes functions a single time. This may result in the one-time transfer of $100,000.00 to a specific bank account. After performing its function, the code could be programmed to expunge the resulting log file—and finding the exact cause of that anomalous transaction is impossible without reviewing millions of individual lines of code.
There are two ways to deal with these risks from both preventive and detective standpoints. Detective controls include good cataloging to track the production environment, and who enters what code into production. Preventive controls involve, again, segregation of roles. A programmer's access would be limited, for instance, to the QA environment, while the ability to move code into production would be reserved for a system administrator. Once duties are segregated logically, it is a simple matter of determining how the ERP application can facilitate that separation of duties.
3. Enjoy the efficiencies that come with automated risk management.
The old axiom is that people will work harder to keep someone from stealing $10.00 from them than they will work to make that $10.00 to begin with. And while risk management is primarily about preventing loss, there is a real upside to automating processes that prevent costly mistakes and fraud. Implementing automated risk management practices within your ERP environment can help you document risk management and compliance activities. This can deliver efficiencies that you will appreciate during an audit, or anytime you need to document the safeguards built into your business systems.
Many ERP preventive and detective functions are automation tools that expedite the compliance and documentation processes a business may face. Once an ERP event engine (like IFS Applications) is configured to test for various exceptions and send notifications when they occur, you can document and use that exception reporting system to your advantage during an audit. To pass an audit, controls must be baselined, which means testing the controls and saving the test information so you can show your auditor that credit limits have not changed—and if they had, you would have been notified. Moreover, your ERP application should allow you to keep audit logs of every transaction in the system, providing additional documentation and detective controls.
Conclusion
Risk management within an ERP environment starts with a thorough analysis of where the risks faced by your business intersect with the technology. Fortunately, a top-tier enterprise application typically facilitates risk management activities, including preventive and detective controls.
But the technology is of little use if risk management is not a priority during the implementation process. Analyzing business risk during this critical time, and configuring the application to manage those risks, can prevent accidental and deliberate loss down the road. Moreover, these same risk management measures, once put in place, can also help you document your processes, risk management, and regulatory compliance.
About the Author
Tom Schiesl, partner with Virchow, Krause & Company, LLP consulting practice, has been with the firm since 2003, and leads the Compliance Services Team. Prior to joining Virchow Krause, Schiesl led the enterprise technology solutions practices for the Milwaukee, Wisconsin (US) office of a global professional services firm. In addition, he was QA and release manager for a leading logistics management firm. He has significant consulting experience in complex project management, business intelligence (BI), ERP, and manufacturing across numerous industries.