The Art of Control (part 2 of 3)

A Second Line of Defence

How can we avoid this?
By integrating the control process within the report itself. When designing or modifying a report, the controls are established. Why not execute them with the report itself and summarize the results? Inside the report, it is possible to identify very precise control criteria which can be used to make the report self-validating.

How do I know if my report is correct?
Because the report will tell me if any errors are present. By holding the control information in the report, you gain the ability to flag the report as having errors or potential issues. Additionally, since the report may well be restricted to a single entity, you can also show a detailed error message which might allow the user the option to correct the error themselves without having to get access to a specialist who can analyze the source of the reporting problem.

...but don't neglect your traditional controls.

The above mechanism should be a second line of defence and you should still use your traditional controls as a primary method. Maintaining these controls allows some feedback into the secondary controls and also on a very simple level, allows you to pre-inform users that reports will have errors because the control process is incomplete.

...and don't forget to control your control reports.

A simple, but commonly occurring, issue is that the control process fails because the controls reports themselves have errors. Applying the same logic inside the control reports themselves provides a higher degree of confidence that problems have been identified and handled.

Pros and Cons

Cons? The following points are listed as cons, but it is perhaps worthwhile challenging if this is truly the case.

· Longer time to market

Since more analysis is required, it will take longer to create the report although if reports are built from common blocks (like a dashboard) then the controls should already have been established and no re-work is required. But I think it is inherently dangerous to produce reports without, at least somewhere, an analysis of its dependencies, so the reality is that should have been spent anyway and the real issue is to avoid duplication of effort.

· Increased Maintenance

As the complexity of the report is increased so is the maintenance. Again, I'm not sure if this is a bad thing. Having to handle the consequences of a business process change or a data sourcing change actually becomes easier when it is clear which reports are impacted. Having to modify the control steps of the report serves to highlight any changes that might need to be factored into the report itself.

That said, even if you still consider the above to be cons, the pros leave little room for argument.


· Clear indication of report integrity

The simplest and clearest benefit is that once I have my report generated, I can have a high level of confidence in its accuracy and completeness.

· Easier analysis and resolution of problems

If there are issues on the report, I already have an indicator of where the problem lies and potentially what needs to be done to resolve it.

· Reports can be more safely generated by non-expert users

Even if you have no business knowledge, you can still safely generate the report because you have a warning that there is a problem and can re-route it to an expert in such cases.

· Report integrity details are not lost when the report is distributed

The person receiving the report is also directly aware as to whether a report is complete and accurate.

Next week the final part of my thoughts on the Art of Control!

Tags: report  control  check  defence  pros  cons  integration  integrity