The treasury team revamped the process, building a software application that has significantly reduced both the amount of time cash ops spends processing wire payments and the level of risk a treasury wire request generates. As a technology company, Microsoft may be more apt than other organizations to turn to software when solving business challenges. But treasury manager Avneesh Nath emphasizes that software was the last step in the improvement of Microsoft's wire request process. "The way we look at these things," he says, "is to have a vision of where we want to go, without worrying about whether the technology is available. You start with the vision, and then bridge the gap between the technology you have and the vision. No matter how many people may say you cannot do something, if you see a better way to do things, you should look for a way to pursue it without limiting yourself."

A better way to do things is exactly what the Supply Chain Management Group at Rochester, Minnesota-based Mayo Clinic saw when they evaluated business risks and segregation of duties across the function's 50 to 75 software systems. Security for each system was managed by that system's IT administrator, but no one was taking a broader view. Risk managers within the Supply Chain Management Group filled the gap, undertaking a major initiative to determine where the company's systems faced the most risk. They identified software most likely to experience problems, then discussed "what could go wrong" scenarios with experts on each of those systems. Next they analyzed the level of risk posed by specific employees, across systems. For those whose permissions in various systems posed a moderate to high risk, the project team discussed with management whether any of the individual's permissions could be removed. They also set up ongoing monitoring for some employees whose security settings retained risk.

Although the security of technology systems is usually considered a responsibility of IT, Erich Heneke, senior manager for supplier risk management, finance, audit, and controls within Mayo Clinic's Supply Chain Management Group, believes IT security settings need to fall within the purview of the risk management team. "If folks in risk management aren't doing anything around IT reviews, they're probably missing some really large risks," he says.

To catch risks both large and small, Dun & Bradstreet has a comprehensive enterprise risk management (ERM) program, which the company recently integrated with a "compliance liaison" program run by its legal department. The risk and audit team asked each direct report to the CEO to designate a risk leader who would spearhead risk management activities in his or her area of the business. They trained the risk leaders on ERM and gave them responsibility for conducting risk assessments within their function. They also established a process for escalating risks to the company's senior management.

"Companies need to be continually looking for gaps in accountability and driving ownership of risk management back to the business," says Martin Sciortino, chief enterprise risk and audit officer. "Assessing risks and raising them to the right people should just be part of everyone's daily work life."

Following are the stories of three teams that have navigated a sometimes-treacherous risk landscape and found success by stepping outside the box of what's typically expected of the treasury and risk management function.

(To access an archived version of the Treasury & Risk webcast in which this year's winners described their projects, click here.)

Embedded ERM

It is not uncommon for a company's internal audit team to gather risk information from employees, analyze the information, and develop a risk assessment that identifies risks to the company. "People tend to see ERM [enterprise risk management] as a requirement," says Walt Campbell, director of risk and audit services at Dun & Bradstreet. "Their attitude is often 'We have to do these updates because audit is asking for them,' rather than 'I'm doing this to make sure I achieve my performance goals.'"

But that type of environment doesn't reflect ERM best practices. That's why Dun & Bradstreet revamped risk management to drive accountability to individuals in every function and business unit across the company.

"Companies need to be continually looking for gaps in accountability and driving ownership of risk management back into the business," says Martin Sciortino, Dun & Bradstreet's chief enterprise risk and audit officer. "We recently saw an opportunity to partner with our legal team to leverage their 'compliance liaison' program by embedding our ERM framework into their program. We had just launched a new strategy and one area of focus was around the culture and becoming more open and collaborative, so the timing seemed right."

The first step in this undertaking was to engage the board of directors on the recommended approach for embedding ERM into the business. "Walt and I, along with a core team, presented our concept and plan," Sciortino says. "We had an in-depth conversation with the audit committee of our board. They embraced the idea and provided valuable input. Our CEO saw it as enabling the company's new strategy."

The second step was to ask each of the CEO's six direct reports to designate a "risk leader," a senior-level manager who would take responsibility for conducting risk assessments across the direct report's group, and for ensuring the risk assessments supported decision-making at both the group and enterprise level. The risk leaders would not be dedicated to ERM full-time. "We debated that," Sciortino says. "Ultimately, we decided that assessing risks and raising them to the right people should just be part of everyone's daily work life. We provided a list of qualifications and responsibilities for the risk leader position and encouraged the direct reports to select people whose jobs already naturally involved risk management."

At the same time, Sciortino and Campbell, along with a core working group, spearheaded the creation of a risk committee that would be responsible for prioritizing risks raised through the risk assessment process. The risk committee includes the company's chief compliance officer, chief accounting officer, chief security officer, and chief strategy officer, in addition to managers from key operational areas and members of the company's audit and compliance teams.

Next, Sciortino and Campbell, along with a core working group, organized a weeklong workshop to educate the risk leaders and their selected team members about risk management. "We made sure we had people there from all our operating areas, and from every geographic region where Dun & Bradstreet operates," Campbell says. "The idea was to educate the attendees so they could cascade information out to the larger organization."

The training sessions covered ERM tools and techniques, as well as details on specific types of risk. "We had modules on ERM taxonomy and on understanding, prioritizing, and then managing risk," Campbell says. "We went through a lot of the basics of an ERM program, aiming to give participants a thorough understanding of what ERM means so that they could see the practical value of it. We had our chief privacy officer come in and talk about privacy, to give people context about that type of risk. We had external experts provide an overview of other types of risks, and members of our audit committee provided their insights on risks, ERM governance, and the importance of this program. We alternated between specific risk awareness sessions and more technical instruction on ERM processes, group exercises, and interactive sessions. We mixed it up so that people didn't spend the week just sitting there listening to lectures." The company's CEO kicked off the weeklong session, and members of his team—such as the COO, CMO, CFO, and CLO—sat in on some of the sessions and shared their insights on evaluating risks.

"One thing we didn't plan for was that by the second half of the week people started figuring out that a problem they were facing might already have been confronted and solved by another group," Sciortino says. "Light bulbs started going off in that room, and we realized this was much bigger than compliance or risk. We were connecting people, which helped them understand not just which issues they were facing but why those things were issues and what were the different dimensions around each issue."

"We really facilitated connections between groups," Campbell adds. "For example, the sales organization might bring up a risk that is owned by our 'people' group but that impacts the sales team's ability to meet their objectives. These workshops were just another step in establishing an environment where different functions work together toward common objectives. Each of them may focus on operational activities in their own area, but now those activities are part of a coordinated effort toward managing a common risk. This is a value driver that may not have happened if we hadn't embarked on this project."

The workshops focused on the issues most relevant to risk management at Dun & Bradstreet, but risk leaders were not given a specific process to follow. "We didn't want to mandate how the different groups assessed their risks," Sciortino says. "There are different ways of gathering information, depending on the breadth and depth of your functional area. So we presented the risk leaders with a variety of options for leveraging our ERM framework, and we brainstormed how we could tailor it to fit their needs."

Sciortino and Campbell, along with a core group, worked with Dun & Bradstreet's marketing and communications teams to spread the word about the new approach to ERM. They created posters with the photos of the six risk leaders. "People could see, for example, who they should go to with a risk management issue in sales," Campbell says. "They could see, 'Oh, that's who Angela is.' We put the photos up on walls and on different websites around the company. We also had a big kickoff at corporate headquarters."

Throughout, the company's executives threw their support behind the project. The CEO attended the kickoff event. "From the beginning, our board, our CEO, and the CEO's direct reports all embraced this," Sciortino says. "Once you have them on board, everyone else starts seeing the benefits. The selling of this project didn't require as much heavy lifting as we expected."

This undertaking maintained the effectiveness of risk management at Dun & Bradstreet during a time of significant change. Each risk leader follows his or her own path for risk assessment. Periodically, he or she presents to the risk committee the risks that the assessment has uncovered, along with suggestions on ways to mitigate those risks. These presentations happen at least quarterly but can be much more frequent, depending on what is going on in the business.

"The risk committee looks at each exposure from different angles to understand whether there might be additional consequences that the risk leader didn't think of, such as legal or security implications," Sciortino says. The group determines which risks should be included in ERM reports to the executive team and the audit committee of the board. "The risk committee helps prioritize risks at an enterprise level, and ensures the risks are leveraged as input into processes such as our SEC reporting, our strategic initiatives, audit considerations, etc.," Campbell adds. "And it cascades information back to the operating teams about the company's enterprise-level risks."

Information in the risk assessments is in-depth and conversations about risk are commonplace at every level of the company. "Our sales organization may have a completely different twist on risk assessment than does our legal team," Campbell says. "But at the end of the day, everyone is bubbling up critical risks in a way that enables us to see common themes. As stewards of the enterprise-level process, the audit team has a lot more risk intelligence, which means we're better able to develop a more robust audit plan to address the company's most critical risks."

Reaction from the business units has been overwhelmingly positive, Campbell reports. "Our team members are proactively coming to us, asking us what's going on in risk management across the company."

"We've empowered the businesses," Sciortino concludes. "ERM gives them the chance to look at and respond to risks that might prevent them from achieving their objectives, and ERM can help them maximize opportunities. Risk management is not just a process handled by audit or the board; it's not someone else's problem. It's embedded in everyone's actions, enabling problem solving and achieving results. Risk management is living and breathing, and embedded in the business."

Efficiency Without Limits

The Microsoft treasury team initiates over 12,000 wire transfers representing over US$240 billion each year, to settle transactions related to corporate treasury activity, strategic business investments and acquisitions, tax payments, benefit payments, and payments for other goods and services.

Until recently, Microsoft employees could make those requests in one of two ways: They could complete a paper wire pack and deliver it to the cash operations team. Or they could fill in a wire request form, created in Microsoft InfoPath, and email it to cash ops.

Either way, the process was time- and labor-intensive for the cash operations team. Once a request came in, cash ops would check to ensure that both the requester and the designated approvers of the wire were Microsoft employees. They would also confirm that the wire amount was within each approver's "SAFE limit," the maximum transaction value that he or she is authorized to approve.

If a paper wire pack passed the control checks, cash ops would manually create a payment request in SAP and release it after two additional approvals. In contrast, InfoPath automatically routed wire requests to the designated approver via email, which streamlined the process when all the data was correct. But if, for example, the approver didn't have an appropriate SAFE limit, cash ops would have to route an already-approved transaction back to the requester to designate a new approver and essentially start over.

"The process was cumbersome," says Jamie Christel, treasury manager with Microsoft. "The paper wire requests would sit on people's desks, where they could potentially get lost. And the email requests would sometimes sit in people's inboxes. After a request was processed, we'd file the paper or the emails. When our auditors then needed to audit a specific transaction, we'd have to figure out who had the documentation and where it was filed." Moreover, Christel says, when the team came out with an update to the InfoPath form, the forms were not backward-compatible.

"There were too many manual activities wrapped into treasury wire requests," says Jayna Bundy, Microsoft's director of treasury operations. "Because of the number of wires we process annually, at those dollar amounts, we knew we had to find a better way to do this. We needed a tool that could potentially support wires across Microsoft globally. We have many senior-level folks who travel a lot, so we needed a tool that would enable wires to be requested or approved no matter where people were in the world."

The treasury team began to plan how to make the wire request process more efficient, while maintaining adequate controls. "It's crucial for us to make sure that we have all the backup documentation support for any payment request," Bundy says. "We have to be sure we don't fail a SOX [Sarbanes-Oxley] control, and we needed to become more efficient at managing the controls. We also looked at how we could make the end-to-end process even better. We decided that the ideal process would eliminate as many manual touch points as possible for the cash operations team."

To satisfy these needs, Microsoft Treasury developed a new Wire Request Tool (WRT). It has a Web-based user interface, so it's available to requesters and approvers anywhere in the world. Wire requesters enter information including the transaction amount, description, purpose, recipient, and currency, and they designate one or more approvers for the wire. At the same time, they upload supporting documentation.

The tool's validation functionality ensures that the form won't accept a wire request unless the right type of information is entered into each field. For example, if the date in the value date field is in the past, the requester will get a message that the data is not valid and must be corrected before the submission can continue. The WRT also automatically verifies against Microsoft's Active Directory that both requesters and approvers are Microsoft employees, and confirms that any approver has the appropriate SAFE limits, before accepting a request.

Once the WRT accepts a request after the input fields are validated, it immediately routes the request to the designated approver, who receives both an email and a push notification on his or her Windows phone. If more than one approver is named, the tool routes the request to each in sequence. "The only manual intervention we have now comes after the final approver gives approval," says Avneesh Nath, treasury manager.

"That's when the cash ops team reviews all the information that has been entered," he says. "There is still a chance the requester has entered some information that is not correct. It's also still possible that we could get a request for an A/P wire, and have it approved, even though treasury doesn't process A/P wires. So we make sure that all the information is correct, and then we determine which account the payment will be made from." Cash ops enters the appropriate account number, then uploads the wire payment into Microsoft's SAP ERP system. Once it's in SAP, the wire request requires a second stage of approvals, by two cash managers, to meet Microsoft's SOX controls.

Once the treasury team had designed the Wire Request Tool, they asked many of the company's business users and cash planners to test it. "They told us what was working and what wasn't," Christel says. "It was nice because by the time the tool went live, many of its users were already familiar with it."

Christel estimates that across requesters, approvers, and treasury staff, the WRT is saving between five and eight minutes per wire. That's 1,000 hours per year in time reclaimed for more value-added activities than chasing around documentation and approvals for wire requests. "If someone is sitting in a meeting and doesn't have a computer, they still get a push notification to their phone," Christel says. "They can quickly look at the wire and approve it. Our wire request initiators are spending a lot less time chasing their directors and managers for approvals."

The team continues to improve on the tool. In response to a suggestion from an end user, they added a "ping" functionality, which enables the requester to send a reminder message to the designated approver. They've also added functionality through which the tool can pull details on a routine payment from SAP to automatically populate the wire request, saving the cash operations team from having to fill in each field manually.

"Many treasury functions probably have the technology in-house today to build something similar to the Wire Request Tool," Bundy says. "Integration with the ERP system is a little more customized, but the workflow itself isn't complicated."

Adds Nath: "The way we look at these things is to have a vision of where we want to go, without worrying about whether the technology is available. You start with the vision, and then bridge the gap between the technology you have and the vision. No matter how many people may say you cannot do something or it's too difficult, if you see a better way to do things, you should look for a way to pursue it without limiting yourself."

Risk Management Icing on the Cake

User permissions in technology systems are generally thought of as a concern of the corporate IT function. But risk managers may be in a better position than IT to take a comprehensive view of the organization's overall security risks.

For risk managers willing to think outside the box, system security is an area ripe for increasing their team's value to the organization.

Consider a recent project at the Mayo Clinic, which consists of four large campuses, located in Rochester, Minnesota; Scottsdale, Arizona; Jacksonville, Florida; and Waycross, Georgia, as well as 20 smaller hospitals, mostly located in the Upper Midwest of the United States. The organization has a centralized IT function that handles its largest technology implementations, but other projects are managed by other divisions across the 24 locations.

"Each local site makes most of its own decisions about what systems it's going to use and how integrated it's going to be with the rest of Mayo," explains Erich Heneke, senior manager for supplier risk management, finance, audit, and controls within Mayo Clinic's Supply Chain Management Group. "Institutional-level projects go through a fairly centralized process, where they're funneled through a master queue managed by the corporate IT group. But many types of one-off IT projects take place within the operational divisions."

These decentralized projects result in decentralization of some IT security responsibilities as well. "At a 20,000-foot level, Mayo IT has accountability for security," Heneke says. "For example, they're responsible for external threats. But when you get down to the systems that support the operations of the organization, security functions are usually decentralized and tasked back to the business groups."

The Supply Chain Management Group is a case in point. "My group has about 600 people," Heneke says. "We push through billions and billions of dollars in accounts payable spend, contract dollars, and purchase orders annually. We use somewhere between 50 and 75 software systems, and we're responsible for managing security on almost all of those, except for our core ERP system. Even within our fairly small footprint at Mayo, security management is decentralized. We have a variety of administrators in different roles across our divisions, and then another dozen administrators manage various systems. Very few of these systems talk to one another, and there's no group tasked with looking at risks across all the systems."

Heneke and his team recognized that when no one takes a consolidated view of IT security, individuals might be able to circumvent segregation-of-duties controls. Scott Koenig, audit and controls analyst in Mayo's Supply Chain Management Group, provides an example: "A person could have an ability to add a vendor to the ERP system and create a P.O. In a separate system, they could have permission to approve payments to vendors that are in the ERP system. And within the banking system, they could have the ability to create a wire transfer for an approved payment. If you looked at each individual system, there'd be no conflict. But if you look at all of this individual's permissions together, you might see a chain by which they can put a vendor in, create and approve an invoice, maybe change the payer location, and then create a wire transfer."

Recognizing this risk, Heneke and Koenig spearheaded a project designed to take a high-level view of risk across systems. First they put together a complete list of systems that the Supply Chain Management Group was using, then determined the level of risk that each posed. "The majority of the systems we uncovered were out of scope for this project because there's not a tremendous amount of risk in them," Heneke says. "To start, we worked with Mayo's Internal Controls Evaluation Office, which is responsible for our voluntary Sarbanes-Oxley compliance. Everything they consider high-risk, we considered high-risk, but we also did a little more digging into some of our other systems to understand them better, and we found some of those should be in the scope of our project as well."

The team deemed about 12 systems to be high enough risk to be included in the project; most of those support the procure-to-pay process. "We had fairly deep conversations with subject matter experts in which we asked, 'If we are navigating around your group's systems, what are the things that could really go wrong with your processes internally?'" Heneke says. "'What are all the really bad things we could see and do in your systems? Could I divert items to be shipped to my house? Could I see patient data? Could I see credit card numbers?'"

After those conversations, the next step was to look at all the user roles within those systems and to score the level of risk posed by each role. This exercise brought to the surface additional 'what could go wrong' scenarios, tying them to individual roles and assumptions. In both steps, the team looked at business risks, such as access to employee data or access to banking information, as well as segregation-of-duties risks, such as ability to create a wire transfer, print paper checks, or alter the payee on a payment.

"Then we used a data mining tool to evaluate the risk posed by individual employees," Koenig says. "We looked at which roles they had in each system and assigned a score to the overall risk they posed to Mayo, considering what could go wrong with their different permissions across all the systems." The team generated a scorecard report which displays each employee's risk rating, and which the team can export into a spreadsheet.

"When we got it all fine-tuned, we determined where the cutoffs should be between high-risk, medium-risk, and low-risk," Koenig continues. "We met with each of the managers in procure-to-pay and explained the results, talking through the permissions of each of the people deemed to be risky. For some people, we discovered that the permissions weren't necessary for their daily work. In some cases, the individual might not even have realized they had those permissions. So for some of these, the manager determined that we should remove permissions and adjust the person's security settings."

For others, the manager was willing to accept the risk. "If risks remained after we had removed unnecessary permissions, we asked the director of the area to formally document his or her wishes," Heneke says. "The directors could have us put in place back-end monitoring controls to ensure we would know if a bad thing ever happened. The other alternative was for them to acknowledge that they understood the risk existed but they didn't think it would be worth the cost to monitor, so they chose for their business unit to assume the risk."

Koenig automated much of the data mining work, so the team expects to repeat the process annually. They are also reaching out to other groups within Mayo that might benefit from undertaking a similar project. "As systems contain more and more information, companies that don't get out ahead of that are going to see breaches from internal people who discovered opportunities for wrongdoing," Heneke says.

"If folks in the risk management space aren't doing anything around IT reviews, they're probably missing some really large risks," he adds. "They can get started by working to understand the company's different functions and segregation-of-duties policies. Then they can look at permissions in individual systems. If they can take the process further, as we've done here, that really puts the icing on the cake in terms of the risk side of the business."