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.
