James Taylor's Decision Management« ETL and Decisioning | Main | Event-based analytics or event-based decisioning? »
August 03, 2006COBIT, SOX, compliance and business rules
I was recently reading "The Joy of SOX" (reviewed here) and it lead me to read up some on COBIT (Control Objectives for Information and related Technology - produced by the Information Systems Audit and Control Associationor ISACA). COBIT is "a generally applicable and accepted framework for good IT governance and control practices". As I was flicking through this I cam across one particular section. Under "Acquire and Implement" there is a "Manage changes" objective (for those of you following along in the spec this is AI6). This control objective talks about "the business requirement for IT of responding to business requirements in alignment with the business strategy, whilst reducing solution and service delivery defects and rework".
The section goes on to talk about how this means having change procedures, actually following them and measuring things like disruptions and emergency fixes. This is all well and good but it struck me that the details were predicated on all changes requiring IT to write code. Regular readers (Sandy and the other one) will know I don't buy this and that I work with customers who want to go further towards getting business users able to make changes for themselves (like egg for instance). This is not to say that I think you don't need good change control and release/version management when business users are making the change - you do - but that assuming that improving the process by which IT makes changes is only one way to increase agility while retaining control. If you take the approach, as COBIT does, that IT must make all changes to the system then the best you can do is that this process is managed, measured and constantly changed to reflect changing business realities. For me a REALLY mature organization would manage change but putting the people who understand and can best assess the impact of a given change in charge of making it. This means IT making IT changes and the business making business changes.
Don't aim too low.
Posted by jtaylor in
Business Agility
• Business Rules
• Compliance
|
Digg This|
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/559
Response from: bmoran
In talking about control frameworks like COBIT or COSO, people often ignore or pay less attention to the monitoring component of their controls. Companies are now integrating continuous monitoring as both a control and an automated control test. For more information check out this Forrester webcast: http://www.oversightsystems.com/knowledge/view_Controls_Automation_webcast.php
Webcast with Forrester Research: Controls Automation & Continuous Monitoring
Date: Tuesday, Sept. 26
Time: 1 p.m. EDT/10 a.m. PDT
Duration: 45 minutes ngoing
Sarbanes-Oxley compliance demands controls optimization and continuous monitoring. In the first years of internal control audits, companies labored to satisfy their auditors with manual controls that were costly to implement and then required intensive testing. Forrester Research analyst Paul Hamerman will lead a 45-minute discussion on how companies can take their SOX compliance programs to the next level with controls automation and continuous monitoring. Specifically, Paul will discuss:
* Risk-based controls (and how to implement them)
* Automating compliance processes
* The role of continuous monitoring as a control and control testing
* Business benefits from compliance
Posted by: bmoran at September 15, 2006 08:01 AM
I believe your concerns are valid in some ways, but I disgree with the 'write code' part of the clause. Where organizations have (high-end) systems in place that allow someone to define a business process and the 'upload' it to the system for execution (using something like a BPMN or 'Business Process Modelling Notation' diagram that describes workflow), it is desirable to give the responsibility to business analysts, in which case the 'Head of Development' in the AI6 RACI chart probably has a title within the organization something like 'Chief Business Analyst'.
There are only relatively few organizations that have installed such expensive infrastructure, (although the costs are coming down) and have given the business process owners and business analysts the training and responsibility to use such tools. As such tools become more widespread, you'll find information technologists only too happy to hand the problem over to business analysts!
But then, or now, whoever defines the rules to the system can be termed a 'developer'. You'll still need the same controls.
It's a bit like we changed from typing pools and key-punch-operators to people in the business using wordprocessors and doing their own data entry as the infrastructure became available: someone had to define the process for defining a document (e.g. 'run the spell checker before saving') and the processes required before releasing edited documents into the outside world. The business person is now functioning as a typist. Soon they will be functioning as a developer.
I think if you look at the headings for the roles in the RACI chart from this perspective, you'll have fewer concerns.
The problem is, as various studies have shown, 95% of bugs (give or take) in software released to production are due to incorrect or ambiguous specification. As the responsibility of 'coding' moves to the business, there'll be less opportunity for pointing-the-finger games, and everyone will be better off.
Posted by: David T. Bath at November 6, 2006 04:09 AM
Post a comment
