Operational flexibility and regulatory compliance are not necessarily mutually exclusive terms.
Mountain View, Calif.-based Synopsys, a maker of semiconductor design software, reached that conclusion thanks to a Sarbanes-Oxley effort that blended new automation with traditional project management discipline throughout each of its 60 global offices.
When the $1 billion company launched its initial Sarbanes compliance effort in 2005, it certainly appeared as if its globally dispersed organizational structure, a common characteristic among growing midsize companies, might pose a compliance risk. Part of Synopsys's overall Sarbanes effort included an initiative that focused on a specific internal controls issue within its ERP system. This initiative provided benefits that stretched beyond regulatory compliance to strengthen overall risk management. The effort serves as an object lesson for midsize companies striving to master the wide world of regulatory compliance demands with a more efficient approach than that typically taken by larger companies.
"The challenge with segregation-of-duties (SoD) conflicts is that they are not an IT problem or a business problem," notes Deepak Mehrotra, Synopsys's SOX compliance manager. "These conflicts are problems that need to be addressed by three areas: IT, the compliance team, and business users."
Flexibility: A Two-Sided Coin
Synopsys's size and organizational model posed additional SoD challenges, but it also offered compliance and risk-management advantages.
The company's workforce operates from offices in Ireland, Canada, Japan, China, India, Korea, Taiwan, and a number of European countries. To monitor risk and overall corporate governance, Synopsys's internal audit department, which reports directly to the audit committee of the board of directors, operates in a similarly dispersed and flexible manner. The internal audit function regularly hires (or "cosources") a virtual team of auditing, risk management, and compliance experts from Big Four accounting firms and other consulting firms to staff up or down in accordance with specific governance, risk management, and compliance needs throughout the world.
The SOX compliance team, a unit created in the wake of Sarbanes that reports to the head of internal audit, employs a similar game plan. "Most of the projects we perform are fairly precise in scope," Mehrotra notes. "We may not need a full-time employee to work one year in Japan on a new privacy regulation, for example. That work may require several weeks rather than several months." In addition to sourcing from external firms, Mehrotra's group also borrows Synopsys employees from other areas of the company to conduct project work.
Mehrotra says that he has discovered that other growing, midsize, global enterprises are beginning to embrace a similar staffing approach. In addition to enabling the compliance team to flex in accordance with governance, risk, and compliance (GRC) demands, the approach also enables Mehrotra to tap a deeper and broader collection of GRC brainpower.
That intellectual energy was harvested during year-one Sarbanes compliance when Mehrotra and his team realized that the flexible nature of ERP usage -- particularly in smaller offices where individual employees needed to execute more tasks and use the ERP system to conduct more transactions -- produced potential SoD conflicts.
height="260" alt="" border="0" />
The Allure of Automation
Synopsys set out to address potential SoD conflicts rooted in its ERP software (an SAP system) earlier than most organizations. The majority of companies, including very large enterprises, that must comply with the Sarbanes-Oxley Act and Section 404's internal controls specifications have yet to sufficiently address the degree to which their ERP systems contain or enable potential Section 404 violations. And most companies that have made progress in this area began to do so in their year-two Sarbanes compliance efforts.
"A light bulb went on when we began our first year of [Sarbanes] planning," Mehrotra reports. His compliance team took inventory of the company's internal controls and came to a realization: Automated internal controls -- those that exist within the ERP system and other IT applications -- are generally easier to test, document, and monitor.
"We decided that if we could focus on application controls early on [in the Sarbanes compliance effort] and do a good job of testing those controls, we could reduce the number of manual controls we rely on," Mehrotra explains. "Doing so would help reduce the overall effort and cost of our year-end audits." It would also improve the efficiency and effectiveness of the ongoing Sarbanes compliance effort.
The approach made sense, but there was one problem. Actually, there were 100,000 potential problems.
For an ERP system's controls to work, both in accordance with Section 404 and in accordance with most corporate risk appetites, the system needs to be designed and used appropriately. While that sounds like a no-brainer in theory, in practice ERP systems hardly ever function as they are designed to function, for three reasons: First, system implementations and upgrades rarely are accompanied by the depth and breadth of end-user training that they require. Second, businesses -- and business users of ERP systems -- constantly change. And third, ERP systems are complex beasts; Synopsys's SAP system offers a menu of 50,000 different transactions.
End-users are given roles, which indicate the transactions they are allowed to perform in the system. Prior to its initial Sarbanes effort, Synopsys's IT department had configured more than 100 different ERP roles.
In theory, an end-user who is granted access to use the ERP system to pay a vendor should not be able to use the system to create a new vendor account. These two duties should be performed by different users; when they're not, an SoD conflict, or violation, exists. If an SoD conflict's potential material impact is large enough, it can throw a company out of Sarbanes-Oxley compliance. Regardless of their size, SoD conflicts also raise red flags to external auditors.
Synopsys's initial ERP examination in June 2005 identified some 100,000 potential SoD conflicts that needed to be reviewed within five months, before the company's first Section 404 deadline.
A Guessing Game No More
The potential conflicts were identified by new software, SAP's GRC tool, which Synopsys purchased and implemented after Mehrotra took a crack at developing his own solution. He developed a framework for examining potential SoD conflicts based on the areas of the company and of the ERP system where he thought they were most likely to occur and most likely to create Sarbanes-Oxley compliance issues.
"I discovered two things from developing all of those risk metrics on my own," Mehrotra reports. "First, I was never sure that my framework would be complete; I could have missed potential conflicts. Second, I did not know that I could convince my internal auditors that my framework was sufficiently complete."
So Mehrotra went shopping and settled on SAP GRC, which Synopsys implemented in less than one month in mid-2005. "The advantage of the tool is that I never had a debate with my bosses about how I came up with the information the tool produces," says Mehrotra. "Instead, our discussion began with whether or not specific risks [that the tool identifies] apply to our situation."
Equipped with management's buy-in and the SoD conflicts that the GRC tool identified, Mehrotra set up a meeting with all of the company's process owners and the head of IT, who is ultimately responsible for the ERP system's operation. Mehrotra presented a project plan that identified the conflicts; the deadline for resolving the issues (by year-end, to comply with the company's initial 404 deadline); the nature of the work; and the project teams that would execute the work.
Fourteen project teams were assembled to examine the SoD conflicts in the company's 18 business process areas (e.g., order-to-cash, procure-to-pay, etc.). Each project team consisted of a member of the SOX compliance team, process owners, and two IT members, one of whom was an expert in the functional or business process area and one of whom was a security specialist.
Each team's mission was straightforward:
1. Understand which of the SoD conflicts were valid;
2. Understand which conflicts were not valid, and then document the reason;
3. Identify and document valid conflicts that had mitigating controls in place; and
4. Take corrective actions on valid conflicts that did not have mitigating controls in place.
The corrective actions took different forms. Some conflicts were resolved by changing the way transaction codes and roles within the ERP system were designed. Others required changes in the business process the ERP transactions supported.
Mehrotra says that the company's collaborative culture and the teams' aggressive analysis and remediation efforts helped to resolve the conflicts quickly. All conflicts were eliminated before the company's Section 404 deadline, and the vast majority of the issues were eliminated within three months.
The cleanup effort redesigned more than 100 ERP roles and greatly simplified the combinations of transaction codes within those roles. Prior to the initiative, the number of transactions within basic ERP user roles hovered at roughly 16,000. By the end of the cleanup, the number of transactions within those basic roles had been reduced to 45, greatly simplifying the management and oversight of system access without hampering the flexibility that the far-flung workforce requires.
The process improvements that the project teams instituted included limiting the number of employees within the sales process who could create new customers and reducing the number of employees who could create new vendors in the procurement process. The number of employees who were able to process journal entries was also reduced, among many other process refinements.
The cleanup effort's benefits extend beyond Sarbanes-Oxley compliance. Through a series of meetings, Synopsys convinced external auditor KPMG to use the GRC tool, rather than the audit firm's own framework, to run tests of the ERP system during audits. Mehrotra credits the company's open communications with successfully influencing that discussion. "We told them exactly what problems we found, how we fixed the problems, what schedules we have, and how the system runs," he reports. "And then the auditors came in and did some testing and validation of their own [with the GRC tool] to get comfortable with it." KPMG's use of Synopsys's compliance software reduced duplicate work and helped contribute to a more efficient Section 404 auditing process.
The process through which the project teams analyzed, documented, and resolved the SoD conflicts also delivered more clarity to the company's overall risk management capabilities. "The cleanup phase helped to instill a new discipline in the company with regard to how we manage user access and authorization," Mehrotra adds. "Management now has a clearer picture of our potential risks -- and where we have controls in place to address those risks and where we don't. It's no longer a guessing game."
The initiative is also no longer a "compliance-team-only" game. Phase two of the initiative, which took effect throughout 2006, handed off responsibility for ongoing monitoring of SoD conflicts from the compliance team to the process owners themselves.
