报表重构的需求一直在
项目组又排了一些报表重构的需求，原因是业务觉得有很多报表没有人在用。
这是最近遇到的一个例子。
报表的开发始于两年以前，目的是帮助不同的业务角色和管理者通过掌握和了解数据，知道业务上发生了什么事情，从而对业务运作提供支持，对管理决策提供支撑。
报表开发工作启动之后，重构工作很快也开始了，两年来，随着报表数量的不断增加，修改的需求也一直在，所以报表重构经常占据着工作的优先级，但与之形成鲜明对比的是，报表的用户却在减少，有些报表甚至没有访问量。
这虽然只是一个例子，但这种场景在很多企业都存在，报表数量很多，但用户却很少，或者说报表虽然很多，但真正有效使用报表的人并不多。
用起来的原因有一些共通之处，用不起来的原因不一而足
访谈两边，各有收获。
有些报表，一直被高频有效的使用，沟通下来，原因有许多相似之处，比如操作简单，用户体验好，比如省时省力，信息准确，比如灵活通用，容易上手，比如领导要求，周周考核。
与之形成对比的，有些报表被“束之高阁”，分析下来，原因各异，归纳一下，比较靠前的原因有这么几类：
01 业务的动态与报表开发的静态之间存在着不一致
这个不一致可能体现在速度上，也可能体现在管理思路上。
许多企业，业务很动态，开展业务的方式也灵活多变，比如流程变了，结构调整了，考核指标重新设计了，这些变化可能天天都在发生，但是报表则相对静态，报表开发如果没有及时捕捉到这种变化，或者报表变化的速度没有赶得上业务变化的速度，对业务来讲，报表提供的信息也就不那么直接和有效了，渐渐地，业务会形成一套临时解决方案，不再依赖报表，也很少查看和访问报表，时间一长，两者也就脱钩了。
还有一种情况，业务虽然照常，但业务人员在变化，如果对新员工的培训没到位，新人可能不知道如何使用报表，也就没有使用报表的积极性。
除此之外，有的企业还会存在管理标准和业务流程各异的场景，如果分属不同的部门，报表的开发和管理能分开会好一些，但很多时候，即使同一条业务线，同一个部门，同样的操作，也会因人而异，因事而异，个例较多，共性很少，无论是管理办法还是业务流程，都没有实现统一。
如此，通过报表满足同类需求就很难，报表开发出来，往往满足了一方，便会失去另一方的用户，因此同一张报表的用户也不会很多。
02 开发报表的人和使用报表的人之间存在着知识和经验的壁垒
大部分企业的报表开发，依赖于两个团队的紧密合作，业务团队是使用方，提需求和修改意见，同时也负责验收，数据团队（或者IT团队）负责开发报表，同时也会基于修改意见对报表进行重构和维护。
为了将需求变成可使用的报表，业务团队通常会出需求对接人，负责一个或几个部门的需求收集，同时把收集来的需求沟通给开发团队，开发团队会配置不同的角色，BA（需求分析师）、DA（数据分析师）、DE（数据工程师）等角色来对接、理解并开发需求。
但，问题仍然存在。
一方面，如上一段提过的，因为业务的动态性和管理思路的不统一，需求的个性化差异很大，业务人员在作为业务代表或者对接人收集和理解需求时，很难提炼出共性和标准，也很难成为其他业务人员诉求上的代言人，所以需求在被理解和传递的过程中会出现偏差。
另一方面，开发团队虽然有角色分工，但毕竟缺少业务的全流程体验，自然而然的，在理解业务的流程和逻辑上会加入自己的想法和认知，因此，最后开发出来的报表离真实诉求又多了一层偏差。
简单来讲，开发报表的人不使用报表，使用报表的人不实现报表，这里面的偏差既来自于专业和分工导致的知识壁垒，也来自于对管理方法理解和认知上的不一致。
03 数据不准确导致的报表可信度低
报表能不能给业务人员和管理者提供洞见和支持，在很大程度上还取决于数据是不是准确、可靠，数据能不能还原企业真实的经营状态，所以数据质量是一个很关键的问题。
通常来讲，能够在经营和管理层面提供支撑的报表所依赖的数据大都来自多个应用系统（领域模块），比如财务、生产、销售等，理想情况下，各个领域的数据质量都很高，当把各个领域的数据汇聚到一起，建立各种联系和映射，形成跨域、多角度、综合的数据展示和分析时，其结果也是可靠的。
但现实往往不是如此，大部分的数据源系统产生的数据质量并不高，这会导致数据汇集之后的清洗和治理工作很复杂、成本很高，但效果也不一定理想，这就如同用不洁净的水做饭，很难保证食物的安全和口感。
所以，当报表不能还原真实的现状，也无法给使用者提供信赖和安全时，使用者也会变少。
总的来看，大部分企业面临的问题不是无报表可用，而是报表太多，没有人使用，或者想用但不知道如何使用。
也因此，报表满足不了业务的诉求，对管理也提供不了支撑。
总要做点什么？
如何将报表当成资产进行开发和管理，如何盘活这些资产，有一些方法或许可以尝试：
01 管理先行，报表支撑
明确管理本身和工具的关系。
报表是业务和管理的信息化展示形式，反映和展示业务和管理的各种流程，对数据做整合分析帮助企业优化决策、提高工作效率。
所以，企业的报表本质上是支撑企业的业务和管理的工具，当管理到位时，报表是得力的工具，当管理没有到位，报表的价值也就很难体现出来。
因此，让报表真正发挥作用，首先要做的是梳理业务、梳理管理，统一经营思路和管理办法，当管理范畴内的事情理顺了，报表的开发目标也就清晰了。
02 给报表一个自我解释的身份
很多写代码的人都有类似的体验，代码注释很重要，给自己看，方便回忆，给他人看，协同工作，注释是对代码的解释和说明，本质目的是为了增强程序的可读性与可解释性。
报表亦是如此，也需要一个自我解释的身份，如果这个解释能包含几个内容，为什么开发这个报表（why），什么时候（when）开发的，给谁使用（who），它实现了啥（what），如何使用（how），有了这些信息，无论是使用报表的人还是维护报表的人，都会对报表多一层理解。
即使业务在未来的演进中存在不确定性，即使业务和IT侧都出现人员变动，通过这些记录了解了报表的前世今生，也就不难设计出一个适应变化的未来场景。
03 在开发者和使用者之间架起一座桥
确切地说，这是一座通过人来衔接的沟通桥梁。
它不是虚拟的，而是真实存在的，比如打破现有团队的边界，派驻业务人员进入开发团队，在很多企业，这种角色叫做BPIT（Business partner in IT），或者派驻IT人员进入业务团队（ITBP: IT as Business partner），无论怎样流动，这些跨团队派驻的角色会成为新团队的一份子，真实获得工作的体验，这些经验结合自己的专业，会变成贯通业务和技术的认知，最后的结果是，让业务被理解，让想法可落地。
04 多沟通，培训使用者
项目管理的那些实践仍然适用，而且要更频繁的使用起来。
开发团队和业务部门多沟通，获得真实诉求、及时验证开发结果获得反馈；开发团队内部要多沟通，确保大家对需求和报表开发的理解是一致的，提高工作效率，减少合作过程中出现的信息偏差。
组织用户的培训、答疑，及时捕捉用户的使用习惯，避免用户因为“不会使用”的原因而流失。
05 开展“案例教学”实践
多年的报表开发，总会有一些特殊的案例，那些使用率最高的，最能贴近业务诉求的，或者与之相反的，最少有人问津的，重构次数最多的，等等，这些具有某些标签特点的报表，其被开发的背后都有故事。
通过复盘的方式，挖掘这些故事，找出原因，总结经验和教训，这些结果会是报表开发重要的的经验积累。
06 重视数据治理
大部分的企业都经历过先发展后治理的阶段，企业的数据亦是如此。
在快速开展信息化建设的阶段，企业通常会建议一堆系统，却往往会忽视源系统的数据质量，当意识到数据质量已经阻碍了企业从数据里获取价值时，从提升数据质量的角度对应用系统产生影响已经变得很难，所以数据治理的议题会被提出来。
但这种集中的、滞后的数据治理周期长、投入高、效果也不见得理想，所以数据治理不是最优解，却是不得不做但又非常重要的选择。
当然，数据治理一旦发挥效用，不仅仅会提升报表的有效性，也能提高数据分析、数据洞察、智能应用等基于数据的服务价值。
总结一下，因为业务在变化，所以报表的重构是正常且顺应趋势的结果，但报表能否支撑管理，不在于报表的数量有多少，而在于报表能否被有效使用，解决报表的使用性问题，首先要从业务问题入手，其次才是技术问题。