IT治理的理论网上一搜就可以找到一大把。从事IT工作的人员，是否遇到下列的情况：
早期IT系统的设计缺乏IT审计制约，不乏内部IT人员利用系统漏洞作案的事例。随着公司治理水平工作的推进，以及大公司集中化管理水平的提高，道德风险大为降低，但这是一把双刃剑——将风险分散的模式变成了需要直面承担的集中风险。怎样降低风险集中后的IT故障及事故，这个问题也给IT管理提出了更高要求。
基于上述原因，IT部门作为公司内部的乙方，自然而然地坐在了风口浪尖上。技术工具必定是工具，它不可能完全替代人，而公司业务的电子化也是按照人在日常工作的业务流程、管理理念经过提炼后固化在系统中而实现的。有什么样的需求就催生什么样的系统，需求控制也是信息系统建设过程中的关键点。行业的实践表明，IT部门包办了大多数工作，甚至若干需求的提出也是由IT部门去全权控制，但是随着越来越多的公司创新业务的出现，使IT部门已经无法也不可能像过去一样越俎代庖地完成“交钥匙工程”。
做好IT治理，公司应建立技术部门和业务部门之间有效的沟通协调机制，制定IT 应用贯穿需求分析、立项决策、系统建设、系统验收和上线运行等阶段完整的工作制度与工作流程，通过IT 应用实现公司的经营目标。这一条实际上就是要求公司需要明确IT建设与运行等各个阶段中技术和业务的责权划分问题。
随着集中化业务推进的提速，与之相配套的各项集中管理措施跟进相对滞后，主要体现在协同工作上因为权责等不明确，使得管理绩效达不到理想的效果。主要体现在：
缺乏业务规划
1．由于业务创新的提速，通过时间目标控制而采用时间“倒逼”的方式提出对新系统建设的要求。由于业务部门没有充足的业务需求梳理时间，一些时候只能从信息系统中去直接获取需求，如果出现“水土不服”，最后归结于IT部门提供的系统“不好用”；
2．缺乏考虑各业务关联关系的全面性，使得各个业务部门没有足够时间去梳理业务流程的变化，间或转移为仅要求IT部门通过改造信息系统来适应这种变化，而回避业务流程的变化；
3．由于未留足信息系统建设或变更所需要的足够的时间，使得系统建设的全过程得不到逐一地完成，留下来一些合规风险和系统的风险隐患；
4．由于缺乏有效的IT规划，在管理部门推出新业务时“临时抱佛脚”，因而也制约了业务的发展。
业务与技术权责缺乏明确界定
新业务或业务变更原则上应由业务部门发起，一旦这个过程一启动，很多时候就演变为技术部门的交钥匙工程了。由于系统关联度越来越高，使得技术部门在这样的过程中从参与者更多的时候变成了资源的协调者和系统建设工作的组织者。
由于电子化程度提高，很多的人工操作现在都固化在系统中由系统自动完成。因此，人们在意识形态里就认为拿来就可用，即使需要修改也只是技术部门的事情，在很大程度上影响了系统建设的进度和质量。IT部门在系统建设或变更的过程中，它应该扮演什么样的角色？
问题还有不少。

首次发表：华安信达 信息安全IT运维管理社区

:)

IT部门是需求的协助者，还是组织者？
我觉得斑竹，还没写完啊，期待下文1

支持原创！