The Sarbanes-Oxley Act nudged mobile operator and network provider T-Mobile UK, a division of Deutsche Telekom's T-Mobile International subsidiary, toward a startling revelation.

"We realized that we effectively handed out 5,500 keys to our front door, and we didn't know how they were being used," says T-Mobile UK's Hertfordshire, England-based Shelly Sethi. Sethi's title -- SAP NetWeaver and security manager -- sounds less balanced than his background; he's a former finance manager and an Associate Chartered Accountant (ACA), which is the equivalent of a CPA in England and Wales.

The front-door keys he's referring to are the access rights any company with an ERP system grants employees to enable them to conduct specific transactions in the system. The use of those access rights should be carefully monitored and managed, but that frequently doesn't happen at most companies that use an ERP system. That lack of oversight allows segregation of duties (SoD) violations to flourish.

A common SoD violation, for example, occurs when an employee who is allowed to approve an invoice in the ERP system is also allowed to use the system to pay the invoice. That ability, or access, is commonly grouped into "roles." Access controls establish which employees can have certain roles to perform specified transactions within the system. A company can maintain airtight controls around the manual invoice and payment processes that occur before and after process data is entered into the ERP system, but that discipline is undermined if the same controls do not govern the way in which employees use the system. This issue formed the basis of Sethi's business case when he proposed a new way to identify and eliminate SoD and access-control problems at T-Mobile UK.

T-Mobile is hardly alone. The vast majority of ERP-equipped organizations can expect to uncover tens of thousands to hundreds of thousands of SoD violations when they pop the hood of their financial systems. A hefty portion of those breaches can derail regulatory compliance efforts and create even larger risks.

Now, a high-risk SoD violation does not necessarily mean that any fraudulent activity exists or that manual errors will occur. Rather, SoD violations indicate that both problems can occur. SoD violations frequently result from workarounds. They occur when system users circumvent standard roles in the system, usually in favor of quicker, but riskier, ways to pay a vendor, correct an invoice, order materials or perform some other transaction in their process area.

Sethi's initiative, which has since been adopted by other T-Mobile International subsidiaries (and is currently being considered by Deutsche Telekom itself), sought to strengthen regulatory compliance and improve business processes by reducing those workarounds. The approach that his team devised requires a blend of technology, people and processes that befits Sethi's hybrid finance-IT background.

Making a Better ERP Sandwich

"A lot of companies don't realize how big their ERP system is and how embedded it is in the processes and controls they have," says Sethi. "They tend to ignore the system or to view it as a hindrance. I've seen many other companies procrastinate addressing access controls and segregation of duties issues for years."

Sethi and T-Mobile UK have addressed access controls and SoD violations since the company implemented its SAP ERP system in 2001. However, Sethi and his team believed there had to be a better way to monitor and manage access controls within the ERP system.

The organization, like many others, relied on external auditors to perform manual ERP audits, often in conjunction with annual audits. The auditors did not provide a specific number of SoD violations. Instead, they manually investigated portions of the ERP system's usage, and then described the issues in a report that T-Mobile, like most other companies, used as a guide to correct problems in those areas.

However, since the total number of violations could not be accurately quantified via manual audits, the information that the different audits produced ran afoul of one of T-Mobile's guiding principles -- to produce a single version of the truth.

"We would throw a great deal of expense at a manual SAP audit, and then drive the violations down," Sethi explains. "But, over time, the issues would rebound."

Sethi tracked that rebound effect, along with the cost of each ERP audit, over a two-year period and drew a clear conclusion. "Being an accountant, it appeared that the most logical way forward was to look for an automated solution," he says.

83,000 Problems To Solve

Sethi's realization coincided with his parent company's push to comply, by year-end 2005, with the Sarbanes-Oxley Act as a foreign registrant. Although T-Mobile UK already complied with numerous U.K. regulatory requirements, including some that required monitoring of ERP access controls, Sarbanes Section 404's internal control requirements served as the final catalyst for what Sethi calls his company's GRC (governance, risk and compliance) initiative.

Executive leadership within T-Mobile UK's finance and IT functions approved Sethi's business case in August 2005. By January 2006, the company had selected Approva's BizRights tool, which Sethi describes as an "automated SAP authorization tool (ASAT)," and hired U.K.-based Consider Solutions to assist with implementation. The software scours the ERP system and its supporting documentation for access controls and SoD violations based on standards established by top public accounting firms.

The tool also divides the SoD violations into high, medium and low (or "informational") priority levels. For example, the ability of a single ERP user to post an invoice and then pay the vendor who submitted the invoice qualifies as a high-priority SoD violation. Similarly, the ability of a single user to change a purchase order after it has been authorized qualifies as a high-priority violation. On the other hand, the ability to change a purchase requisition after the purchase order has been finalized qualifies as a medium- or even low-priority violation because that change does not affect the accuracy of the actual payment to the vendor.

Sethi's team initially allocated nine months to implement the new software, identify SoD violations and then staff the teams necessary to analyze and eliminate the violations. Within two months, the tool was up and running -- and causing jaws to drop. "When we first ran the tool in March, I fell off my chair," Sethi recalls, "because I saw 83,000 SoD violations."

Shock Treatment

Sethi picked himself up in time to hear his company's financial director present a crystal-clear mandate: resolve all 83,000 SoD violations by September.

Sethi checked in with peers at the small group of other companies around the world that had implemented the same tool. His benchmarking proved heartening; other companies had uncovered hundreds of thousands of SoD violations on their first swipes. "I discovered that 83,000 is actually a fairly modest number," says Sethi. He also noticed that the companies with the largest number of SoD violations tended to be those that had implemented their ERP systems earlier than the companies with fewer violations. That makes sense; ERP implementations include end-user training (to varying degrees of effectiveness) which identifies standard ways of using the system and its controls. Over time, however, employee movement through promotions and turnover and other changes inside and outside the business affects how employees use the system. Had T-Mobile UK implemented its ERP system in, say, 1998, it could have been looking at 500,000 or more SoD violations.

T-Mobile UK's 83,000 SoD violations broke down along the following lines, according to the Approva tool: 32,000 high-priority violations, 42,000 medium-priority violations and 9,000 informational violations.

Addressing and eliminating those violations -- or understanding and, in some cases, choosing to accept them (as is the case for some informational violations) -- requires an analysis of system access. In other words: Which employees have the keys?

"If we could ensure that only valid key holders were using our system at any point in time, we could then look at how those employees are using the system," notes Sethi. "The end result would be that we could remove the violations and bring about better use of the system. Both of those steps would improve the strength of our end-to-end business processes." It would also assist the company's Sarbanes-Oxley compliance team with its Section 404 efforts.

SoD violations in hand, Sethi created teams consisting of a balanced mix of business and IT people representing each of the company's 10 major business processes. Each team was led by a process owner, and each team also contained a "gatekeeper" -- the IT employee responsible for granting access to the ERP system.

"We knew we would need interaction between [IT] and business," Sethi explains. "Each year, a bunch of people in [IT] decide who can have the key to our front door, where they can use the key and how they can use it. Yet they are not always in the best position to make those determinations."

That's the case at many companies, but it's a setup that Sethi views as less than ideal. An IT gatekeeper may not know, for example, that an HR employee should not use the finance key.

The teams scrutinized the SoD violations in their areas and evaluated the priority breakdown that the Approva tool produced. That analysis tracked fairly close to the tool's breakdown. The teams concluded that it would be better to create a community of gatekeepers within each business process area so that the gatekeepers could develop a better understanding of the ERP roles within their area.

The teams' primary objective was to eliminate high- and medium-risk SoD violations. That work involved taking back many keys, but also handing more out. For example, an A/P clerk with rights to accept invoices and pay vendors might lose the ability to pay vendors, while a different A/P clerk might gain the right to pay vendors. This was the process by which the duties were effectively segregated.

Many of the access control changes sparked heated responses; employees were initially reluctant to give up their workarounds. If an A/P employee previously relied on a quick call to IT, for example, to ask a colleague there to initiate a last-minute payment run, that A/P employee might be displeased that he or she could no longer make those last-minute calls.

"I've always argued that it's neither standard nor best practice for someone in [IT] to post a financial transaction," Sethi notes. "That should be done by the business. However, it happens at every company I've worked in during my career."

It no longer occurs at T-Mobile UK. "We took [the workarounds] away overnight, and we heard people scream," Sethi recalls. "I heard comments such as, 'If I can't do this, the company is going to go into receivership.' We had stand-up battles with people who were worried the whole business would crash. And now they're some of the strongest advocates of using the system in a standard and correct manner. That's the whole point of GRC."

The shock treatment worked effectively, and quickly. By May, the business-IT teams had eliminated the majority of high- and medium-priority SoD violations. By late July, nearly two months ahead of schedule, all of the violations had been corrected or, in the case of some informational violations, analyzed and accepted.

A New Breed of Process Insights

That accomplishment represents T-Mobile UK's initial GRC initiative, which eliminated SoD violations and, in doing so, supported overall regulatory compliance.

"Phase one of the project has been an enormous step forward in terms of control," reports T-Mobile UK's head of accounting, Tony Fitton. "We have gone from a largely uncontrolled systems environment to one where we have full control over access and can identify and prevent future issues before they happen."

There was another benefit as well. When T-Mobile UK's external auditors present concerns about SoD violations within the ERP system, the company can present hard evidence to support any issues it has with the auditor's recommendations. "We can now give them support when we say that [a violation] does not apply or is not a high priority," says Sethi. "The auditors can use this information, which is helping the audits become more focused."

The potential benefits of the initiative's second phase may be even greater. Fitton notes that the second phase will enable the company to "use the information that SAP can provide to us to improve the efficiency and effectiveness of our business processes."

Sethi and his team are using the tool to generate measures -- for instance, duplicate invoices, purchase orders with high gross-value line items and purchasing requisites that have been open for longer than three months -- that suggest process improvement and risk management needs throughout the areas of the business that use the ERP system.

For example, a recent run indicated that the system contained 308 duplicate invoices. That and similar measures "have raised many questions that the business wants answers to," says Sethi. "This approach generates a new breed of process insights. By increasing our visibility into audits of our ERP system, we have increased visibility into business processes while giving the business information it can act upon."

Even with the shock treatment, or perhaps because of it, the GRC initiative has created a new mindset surrounding the use and management of the ERP system among the workforce. "We now have a situation where everyone enjoys and relishes the way our ERP system is used," Sethi adds.

KEYS to Success Recognize the limitations of manual ERP audits. T-Mobile International saw that the volume of ERP-related SoD violations rose over time, despite investments in recent manual audits. Use Sarbanes-Oxley to drive the project. T-Mobile UK, which is part of T-Mobile International, used Sarbanes-Oxley requirements as part of the business case to justify its governance, risk and compliance (GRC) project. Buy technology and build processes. The company invested in what it calls an "automated SAP authorization tool" (from Approva), and then assembled teams. The teams prioritized the SoD violations that the tool churned out, and then developed methods for eliminating them. Cultivate buy-in through team composition. Each team, which represented an essential business process (such as procure-to-pay), comprised an equal mix of business and IT people. Each team included a process-owner leader and an IT "gatekeeper" responsible for granting ERP access. Go beyond compliance. Phase II of the initiative is designed to produce information -- through measures such as the number of duplicate invoices or the number of procurement requisites open for greater than three months -- that business managers can use to improve their ­processes and their use of the ERP system.