How is the term "compliance" defined and used at your site? Often, a lot of head shaking and furtive glances accompany the answer to this question because compliance and the need to supply services in support of compliance-requirements is still a pretty new thing. However, in many other cases - particularly at larger sites - IT managers think they know just what the answer is. For them the definition of what constitutes compliance is determined by looking at the set of existing service-level agreements (SLA) that IT had negotiated with its various groups of stakeholders.
After all, it should be a given that another groups' need to satisfy compliance requirements would have driven their decision-making when they executed an SLAs with your IT department. Right?
If you accept the line of reasoning - that people who frame SLAs do so with an eye towards compliance requirements, and that the SLA in your files therefore defines the services you must provide so that your company operates within industry or governmental guidelines - you may be right about half the time.
If you rely on the above line of reasoning, ask yourself each of the following questions:
- Does your firm employ a senior corporate officer (perhaps with the title of Compliance Officer) charged with monitoring your company's compliance programs?
- Did that compliance officer participate in defining the needs of the appropriate departments as they negotiated their SLAs with you
- Is the present set of SLAs current in terms of compliance issues, and are these documents effective when it comes to enabling your organization to proactively manage and mitigate relevant compliance risks as they apply to IT?
- When SLAs are renegotiated, is there a review of new organizational needs on both sides of the contract?
If your answer to any of the above was "no," you will likely face compliance-related issues in the future. If your company has no compliance officer, or if compliance issues have yet to filter down to the IT department, you are very likely to have a host of compliance problems headed in your direction.
On the other hand, if you answered "yes" to all of the above, you are still not out of the woods. Negotiating an SLA is something of an art as is, I suppose, almost any sort of negotiation. Many of us take pride in how well we negotiate.
That may not be such a good thing. Consider the following: When you negotiated your SLAs, did you play hardball? Could the result of that tough negotiation be that some compliance-related issues may have gotten lost in the process?
In most cases with which I am familiar, compliance issues are defined in terms of companies, not departments. If mistakes were made by either side of an SLA negotiation, and if the result is that a regulatory or other compliance requirement cannot be serviced adequately, it will be the company that will suffer.
It would seem then that a good rule to follow when IT enters into SLA negotiations with any stakeholder should be for both sides to remember that they are advocates and not adversaries, and that their advocacy extends to cover not just the good of their department but that of the company as a whole.
Of course, if you have no SLAs at all, compliance issues may be only the tip of the iceberg when the time comes to count your problems. If this is the case at your site, you probably need some guidance on SLAs and service-level management.
- 信息系统运维预算定额参考标准研究[04-09]
- 第2章 跨文化管理理论和实践[01-14]
- 16:什么是关键成功因素法(CSF)?[06-09]
- 24:eSCM-SP(服务提供商外包能力模型)有哪些…[06-10]
- 第4章 跨文化沟通[01-14]
- 治理评论第一期[01-20]
- 治理评论第二期[01-20]
- 治理评论第五期[01-20]
- 治理评论第三期[01-20]
- 治理评论第六期[01-20]
- 治理评论第四期[01-20]
- 太极凭什么中标12306? [09-26]
- 中国国际航空股份有限公司--书评[11-01]