The “Who’s On First” comedy routine by Abbot and Costello is a classic that I’m sure everybody is aware of. What’s not such a comedy is that situations like this happen in Corporate America all the time. Where it becomes a tragedy, is in compliance.

Like a lot of other things, nice-to-haves become musts when compliance comes into the picture, and accountability is no exception. If an auditor shows up on your users’ doorstep looking for who’s responsible for a failed control, and your user starts the “Who’s on First” routine, things could get very ugly.

In looking through numerous advisories and best practices on compliance, accountability is one of those things that seems to always emerge. The reasons should be pretty obvious. If nobody’s steering the boat, then the boat’s probably out of control.

Let’s talk about some design architectures that can support your users’ need for demonstrating accountability.

Organizational Breakdown Structures

We’ve all seen org charts, and I’m sure you are familiar with your company’s organizational structure. You may even have the organizational structure modeled somehow in your company’s ERP and / or Human Resource Management system.

What’s important to highlight, is that the same people in your organization can be organized for different purposes, creating alternate organizational breakdown charts. Take a project for example. For the life of a project, you may have a project manager that has team leads, who each have team members. Also reporting to the project manager may be a project coordinator, communications manager, risk manager, and / or change acceptance manager. This is the project organization.

Closer to the compliance home front, your company should have an organization built around its processes. You could have a process manager that has process owners, process auditors, and contingent response team leads. Moving up the chain from process manager could be process group managers, and global process managers.

So, process organizational breakdown structures support the objectives of the processes, however the intelligent enterprise that has compliance as a strategic objective, will have a compliance organizational breakdown structure.  To ensure compliance, there will be a host of roles involved which could include; legal professionals, finance professionals, process analysts, auditors, program officials – and yes IT support people.

Organizing all these people to ensure compliance success is beyond the scope of this article, however what is extremely relevant to you, is how your data system is going to support this.
Communicating Involvement

The practice of business process management gives us a good framework to model involvement which you may have already heard of. It’s called RACI, and it stands for:

• Responsible – The person who will perform the actual action
• Accountable – The person who will get fired if something goes wrong
• Consultant – The “expert” with all the answers, but none of the responsibility
• Informed – The people who have to know what’s going on, but don’t actually do anything

Of course, I’m a little tongue-in-cheek here ( there’s a big surprise ), but you get the point.
To put things in context, let’s take a compliance process of control. The control is a reconciliation control, and we’re controlling for the risk of inexperienced people accidentally posting the wrong numbers.

There could be more than one person responsible for the process, and in our example there is. There are two finance analysts that will independently do the reconciliation. This is a very intelligent way to organize the control, and will greatly reduce the risk.

There should only be one person accountable for the reconciliation process. More than one can introduce finger pointing. That said, there could ( and should ) be multiple levels of accountability. This is where things really start taking the shape of a traditional org chart. In our example, we’ll have a finance manager who’s accountable for the process, and will be called the process control owner, and he reports to a process control group owner.

Of course nothing happens without expertise, so we have a few consultants in the mix here also. There is a much higher probability that there will be multiple people in this category, than that of the responsible category. Consultants can be external consultants ( the priceless variety ), or internal consultants ( legal, finance, etc. ). To illustrate a point, we’ll have the process control owner and the process control group owner as consultants as well.

Finally, we have the “informed” group. I really love these guys. These are the people that just “have” to know what’s going on. Actually this is a legitimate category, and there are legitimate reasons to be in this category, but based on my experience, the number of people that sign up for this group of involvement is usually way overboard. We still need to model for it however, so here we go.

Modeling the Compliance Organization

So how do we pull this all together?

I really like the star schema architecture for this problem – with a little twist. I think you have a number of dimensions going on here:

• TIME. Don’t forget about time because we need change history in the fact table.
• FUNCTIONAL PROCESS. This is the process that we’re trying to control ( i.e. subledger posting ).
• CONTROL PROCESS. This is the process for controlling the functional process ( i.e. reconciliation).
• EMPLOYEE OWNER. This is my organizationally correct way of saying human resource.
• INVOLVEMENT. This is a static dimension that contains the RACI involvement categories discussed above.

This could be a factless fact ( a fact with no metrics ) which is fine. The sole purpose of the fact is to organize all the dimensions together. Here are some other points to consider:

• Downstream from your ERP or Human Resources management system. Do not try to replicate your employee database here. You run the risk of inconsistency, and could create a maintenance nightmare.
• All dimensions MUST be Type 2 slowly changing dimensions. This should be a hard fast rule for any star schema related to compliance.
• If you’re process is broken down into process groups you could expand the FUNCTIONAL_PROCESS dimension. You could keep it flat, or snowflake. I would prefer keeping it flat. Of course, the same goes for the CONTROL_PROCESS dimension.
• Don’t model levels of accountability into this. If your process has process groups, and you have process group owners in your organization, resist the urge to connect dimension to dimension. This will create a mess. We’ll handle accountability in just a second.
• Theoretically the FUNCTIONAL_PROCESS could be in the CONTROL_PROCESS hierarchy. Don’t model it this way – keep the functional process as its own dimension. As you evolve in your design, you may start to get a many to many relationship between the functional processes and the control processes. You want to keep the flexibility of design here.

So this should handle everything but the levels of accountability, so this is the twist. As noted above, don’t try to model this in the star schema – model this off in its own normalized area. You can use a self referencing table ( i.e. unfold the organization with a COMPUTE BY statement ), but I don’t like these for practical reasons. I think it’s better to just build a flat table with 5 or 7 layers of accountability, and just maintain it there. Make sure you have a one to one link with your dimension, so when asked to produce your hierarchy for accountability, you can drive from any control process.

Accountability is a critical component to your organization’s compliance structure, and they need your help in the design and implementation of systems to support these requirements. A compliance organizational breakdown structure is how your company organizes for compliance success. You can use the RACI model to model involvement, and a star schema architecture to put all the pieces together. Talk to your program manager today about drafting a project charter to get this initiative started.