The Unsexy Keys to Data Analytics

Compliance officers need a strong data analytics capability for their programs to succeed, so today I want to talk about the nitty-gritty “infrastructure issues” you need to resolve with the rest of the enterprise if you want to get that capability where it needs to be. 

This has been on my mind since I moderated a webinar on data analytics last week. The single biggest subject of conversation was how you, the compliance function, can work with other teams in the enterprise to assure that they are generating useful data for you to analyze.

The central challenge is this. Your business operating units (in both the First and Second lines of defense) use various IT systems to run their business processes. Those IT systems generate data. The compliance team needs to capture and analyze that data so you can understand whether the First and Second lines are operating in a way that creates compliance risk.

This is not the same as using analytics on your own data, to study training completion rates, policy exception requests, internal reporting metrics or whatever. That analysis is useful, but it only helps you understand whether your compliance program is running efficiently.

Compliance officers also need to use data analytics in a more expansive way, to understand how the business may or may not be creating compliance risk. If you don’t do that level of analysis, then your compliance program isn’t working at a strategic level to steer the business toward better performance. Instead, your program is just going through the motions — and if your program then fails to identify some risk that explodes into an enforcement action, good luck explaining that mess to the board.

As one webinar speaker said: “Am I making proper use of all the information my company collects in the ordinary course of business that could lead to a risk insight — or, worse, could lead to an enforcement action if we don’t act intelligently on that information?”

Exactly the right question to ask.

The ‘Plumbing’ of Data Analytics

To succeed at that more strategic level, compliance officers need to understand and strengthen the three-way relationship that exists among you, the First and Second line business units, and the IT department managing the technology for the First and Second line units.

For example, say you work at a large enterprise. It almost certainly operates from a single ERP software system that provides various systems to the First and Second line, and the IT department manages that ERP system for everyone else. Part of the IT department’s job is to collect data from all those systems and preserve it in some master database somewhere. 

So one chore for compliance officers is simply to know who runs that master data management system for the business, and to build a close relationship with that person. “You need to figure out what’s in those records, what the data management team’s capabilities are, and what’s on their roadmap,” as one speaker said.

The ideal state is that you work with the business unit (sales, procurement, marketing, accounting, HR; whoever) to understand how their processes work, and which data the IT department captures as those processes run. Then you coordinate with the IT department to feed that data into the analytics programs you operate to monitor compliance risk.

You can see one possible tension here. You tell the business unit and IT, “This is the data I need to monitor this compliance risk.” They reply, “Sorry, we’re already swamped trying to make ends meet, and can’t reconfigure our systems just to make you happy.” Then they give you a hammer and point you toward a pile of sand.

So yet again, even though we’re talking about IT infrastructure and data analytics, we’re back to talking about the importance of compliance officers knowing the business and developing strong interpersonal relationships. As one webinar speaker put it, the compliance team needs to “establish a service mindset. If you can convince them that you’re adding value and helping them achieve their business goals, as opposed to sticking more dates or requirements into their process, that always helps.”

How might that work in practice? Say you work at a manufacturing concern. (This was an actual example offered by a webinar listener.) You might want to look at data such as safety statistics, workers comp claims and payments, overtime pay, and late shipments, to see whether those different sets of data all tell a coherent story. Maybe they don’t, which could suggest false data is going to your insurance provider as part of a fraud scheme. That would be a huge concern for the legal and finance teams and for the operations teams running the loading docks. 

So you, the compliance leader, need to work with the business operating units to match up your compliance risks with their operating risks; and then work with the IT team to assure that the units’ operating processes are configured to generate useful data to help the both of you address your distinct (but overlapping) concerns.

When Processes Change

So let’s say your enterprise achieves that common understanding. The operating units’ business processes are humming along nicely, churning out just the data you need. 

What about the risk of those operating units changing their business processes and throwing that carefully calibrated analytics process into chaos?

This is another plumbing issue in data analytics that needs careful attention. Your enterprise needs some sort of formal governance process for changing business processes and systems, so that when those changes happen your analytics concerns don’t go overlooked.

One example of this issue is Sarbanes-Oxley compliance. SOX compliance is all about strong internal controls for accurate financial reporting, but the threat of changing business processes exists here too: a business unit modifies one of its processes, and suddenly your internal controls no longer fit. Hence a formal change management process is very much part of SOX compliance. So if you, the ethics and compliance team, are looking for a blueprint to copy, your SOX compliance team likely has one. 

On the other hand, I worry that this issue will become more perilous in the future, because it’s getting easier and easier for businesses to change their processes. 

This is especially true for smaller, fast-growing companies, who don’t have heavy-duty ERP software governing their business processes. Startups will more often rely on cloud-based tech vendors, where the operating teams might switch from one vendor to another without alerting you. Or employees switch from one vendor to another without even telling their managers. Or the IT team might not be capturing useful data from those tech vendors; or are capturing the data, but not in a useful format.

That means you’ll need strong governance of business processes and change management, including employee training and a clear tone at the top about why change management is important. You, the compliance team, need to align your compliance risk concerns with management’s larger risk management objectives — a point we’ve made many times before on these pages. 

And all this is true before we even get to the sexy stuff like slick data visualizations, brilliant insights about control or policy flaws, or adopting artificial intelligence to run compliance analytics on autopilot.

Successful data analytics depends on the unsexy stuff of IT infrastructure, change management, and engaged corporate governance. That’s where you start.