消除IT部门与业务部门之间的隔阂

作者：Thomas C.Redman 编译：MTC数据质量管理

虽然在数据上的政策斗争到处都在进行，但是在IT部门与业务部门之间的争执往往会造成最大的破坏。IT部门与业务部门之间的关系经常因为各种原因变得紧张。这两个团体之间争执的代价也异常大，而且还会转移客户的视线、让决策折中甚至违背战略。我打算在本文中分享一种可以让IT部门和业务部门在数据质量问题上相互合作的模式。或许折中模式也可以应用在IT部门和业务部门的其他问题上。

数据之争：到底谁该对数据负责?

基于我的经验和与他人的交流，似乎大多数“数据之争”都起源于一些孤陋寡闻的讨论，这类讨论的议题常常是：“谁该对数据负责，是IT部门还是业务部门?”对大多数人来说，“最重要的数据存储在电脑里，因此应该是IT部门对数据负责”这一逻辑很有说服力，而且IT部门主管的“技术总监”头衔也让这一逻辑深入人心。但是，作为在信息化领域努力了多年的老手，自然会懂得这种逻辑有严重的缺陷。毫无疑问，这类事务的现状产生了一个现在广为人知的词汇：“GIGO—Garbage in,Garbage out(即垃圾进入，垃圾出去)”。

但是钟摆开始向另一个方向摆过去，最近几年，一些组织开始让数据质量成为业务部门的职责。这种转变让组织能够有一定提升，但这也引起了一些新的问题。

像大多数白热化的政治辩论话题一样，双方论点都有价值和优势。幸运的是，那些领导潮流的学派已经取得了珍贵的经验，并且发展了丰富的实践来引导这场争端的和解。

自源头起管理质量

或许我们从中学到的最重要的东西就是，数据质量必须从数据源头处开始控制。这种见地将争论引向多种路途：

①　 数据的值一般都是从业务部门产生的，所以业务部门必须对数据值的质量负责。因此，业务部门一定要对数据值的定义、管理、对数据值产生的流程进行提高这三方面负责。

②　 大多数组织都会从外部数据源接受海量的数据。最需要依赖这些数据的个人或者部门应该代表整个组织管理数据的提供者。

③　 存储数据的数据库和应用程序，自动化业务流程，让数据可以被消费者获取，这三者都是由IT部门开发、应用和维护的。保证这些系统的质量也理所当然是IT部门的职责。

④　 如今，大部分数据建模工作都是由IT部门主管的。所以，IT必然要为这些模型、相关数据字典以及业务规则等事务的质量负责(后面会提到更多的这类话题)。

⑤　 安全和隐私策略是业务部门的范畴。既然最恶名昭著的违例是由于信息技术的应用，那么要让那些策略付诸实施很很大程度上(虽然不是完全的)需要IT部门负责。

当然还有其他观点。许多组织似乎对模拟研究的质量越来越不满意。模型师似乎对技术问题很在行，但是却不太懂业务的细节。因此，数据建模的工作或许也应该让业务部门负责。

数据占据了独特的中间地带，在平息其他争议中起着意想不到的效果。例如，在部署所谓的企业系统时IT部门和业务部门双方之间存在巨大的分歧。IT部门开始创建这个系统，它可以保证将以前自制的系统联系起来，并且可以消除烟囱式系统的代价。他们还提出了自己的基层业务流程……..但是这些并没有很好的植入业务中去。但是这里面的第一个争端就是，业务流程，应该是业务部门的权限。除非业务部门掌握主管权，这个新的业务流程(可是说是原创的!)就会面临悲剧的命运。然而仅仅靠IT部门来引领其实施，或者是在新系统失败后让IT部门独担所有责任，是很不公平的。

为了将这个主题进一步扩展，先前将IT部门与业务部门之间称作“合伙人”在政策上是对的。“合伙人”是商务词典中被滥用的词汇之一。它需要行动，而不是空话;需要长时间坚持，而不是短时间激情，这样才能发展处合作的关系。当IT部门的人告诉业务部门的人说，想跟他们成为“合作伙伴”的时候，业务部门的人虽然点头同意，但是却心不在焉，这他们自己心里清楚。

IT部门如果将“成为对业务部门的可靠的供应者”作为目标会好一些。业务部门需要的是“在正确的时间正确的地点有正确的数据来达到服务客户，做出决策，制定计划的目的”。既然IT部门为业务部门的有效、高效的运行提供基础设施和应用软件，那么问“你需要什么样的基础设施和应用软件”几乎就是自然而然的了。可怜的业务部的人!要回答这个问题需要对远远在他理解范围之外的技术方面有一个很好的掌握。可以优化一下这个问题，改成：“你需要什么数据?在什么地方需要数据?你何时想要这些数据?我们可以解决怎样获得你需要的数据这个问题!”那么接下来，讨论就会向着健康的方向发展了。