环球时讯新闻 2021-06-09

基于报表需求的框架性梳理与模块化建设

文|帆软数据应用研究院郑承龙

前言

企业信息化建设的关键目标就是通过数据流转，实现业务过程数字化，进而辅助决策层做出有利于企业经营的决策，使企业效益最大化。而在这个过程中，业务过程数字化是IT人员和业务人员的共创阶段，同时实践表明，IT与业务的天然壁垒是大多数企业信息化过程中的一座大山。

本文探究业务过程数字化中，针对各业务部门提交的可视化需求，IT人员如何进行框架性梳理和模块化建设。

我们以一个实际例子来分享整个建设思路：某服装企业在搭建信息化平台过程中，想要构建业务分析体系，但收集上来的业务需求是一篮子业务报表，并且横跨各个业务主题——零售、商品、会员、财务、渠道等。并且对于这些摆在两者之间的需求，每个人都说不上来该怎么去协同处理，此时业务和IT的想法大致是：

IT：业务人员懂得怎么做数据分析，他们提什么需求我就给他们实现，里面有不清楚逻辑的地方找他们问清楚就行了；

业务：你们把我每次提的取数需求快点推送出来就好了，我也不知道自己有什么需求啊，你非要我提，那就给你一些我常做的表，你们自己看怎么弄吧。

针对这种情况，我们提出框架性梳理和模块化建设两大步去解决这个问题。简单来讲，框架性梳理是将报表需求进行分拣合并，模块化建设则是做主题域划分和完善。

框架性梳理

框架性梳理又细分为两个步骤，类型划分和报表合并。类型划分面向的是所有的报表，不区分业务主题，这一点是为了方便后面做跨主题报表合并（从业务提需求的逻辑中也可以发现，不是所有的报表需求都需要逐一开发），我们把报表类型分为三类：推送报表，查询报表和分析报表。

推送报表

顾名思义，推送类报表主要是一些固定时间、固定样式、固定场景下使用、且需要定时发送的报告，比如门店日报、营运周报、品牌月报等，举个例子，营运周报往常处理的方式是每周一早上，业务人员整理上周的经营数据（数据由IT人员按照固定需求抽数，发邮件给对应的业务人员），在上午把所有需要的数据按照会议要求进行整合，邮件发送给参会人员，供其在下午开会的时候使用。我们把这种类型的报表，按照日、周、月等时间维度进行归类，形成推送报表主题。

图1 推送报表主题

在图1中可以看到，我们除了将报表需求中的推送类报表按照使用周期分类摘选出来，同时也对报表所属的主题进行了前置标签设定，这种命名处理方式可以方便我们在后期进行报表图书馆建设维护时节省大量精力。

同时，通过归类，我们可以找到实现相似功能的报表并进行合并，统一规范。比如各品牌CR周报、营运日报的规范统一，这样我们就可以构建完善的企业推送类报表体系。

查询报表

查询报表主要提供业务人员做业务运营所用的数据，比如常见的进销存报表、商品销售报表等。举个例子，商品销售报表，传统的商品销售报表是业务人员根据分析内容提出取数需求，IT人员根据需求提供对应的Excel数据，然后业务人员用这张Excel数据表去做各种维度的数据整合、透视，再进行运营分析，比如品牌报账、商品畅滞销等。我们把整个流程简化描述为三个阶段——数据获取、数据整合、数据分析，但是整个流程走下来我们却发现业务人员的绝大多数时间都花在了数据获取（30%）和数据整合（40%）上，真正用来做数据分析的时间很少。

图2 查询报表

那么针对这种类型的报表，我们首先根据业务主题的不同，做不同主题域的划分，并在各自的主题域下面构建维度完整的明细数据查询页面，按照金字塔结构，设计业务链条，实现从发现、追踪到定位问题的管理链路。举个例子，比如上面的商品销售报表，我们可以做如下的层级设计：

图3.1 商品销售分析一级

第一层，从整体层面概览商品销售情况，这里我们展现的是季节、系列、大类三个不同维度的数据呈现，涵盖我们关心的各大指标，目的是从总体层面去做商品经营情况统筹。

图3.2 商品销售分析二级

第二层，当在一级分析页面发现问题或者想要更细查看数据时，可以点击蓝色字体钻取到二级页面进行查看。比如在商品销售分析一级页面，我们发现大类商品中上装的折扣率低于平均折扣率，我们可以直接钻取到大类下面的各小类，进一步看各小类的商品销售折扣情况。

图3.3 商品销售分析三级

那么同理，第三层则是定位到了具体小类里面的每一个款的销售情况，这里不做赘述。

通过这样的金字塔层级设计，我们将一个原来多sheet页、涉及各种复杂透视的商品销售报表，规范成为我们的一个查询报表，并且不需要IT人员每次都重新拉取数据，大大缩减我们IT和业务人员的取数整合时间，有更多的精力花在结果分析上面，同时提升了经营会议的效率。

分析报表

分析报表则是面向业务人员灵活的分析需求，这种需求不固定、变化快、并且偏向于业务人员自我分析能力的发掘，举个简单例子，会员部的业务人员临时想看一下这个月新增会员数的目标达成情况，通常的做法是给逻辑让IT人员拿数据，得到数据后看一下，发现问题再找IT人员拿进一步的数据去找问题，这种工作模式费时费力，并且十分不灵活。那么我们把这种看数据的需求固化成各个主题下面的分析场景，针对各个主题建立业务主题域（图4），涵盖各个主题的维度指标以及指标使用口径，业务人员可以根据自己的想法做各种的拖拽式分析，比如我们常见的售罄率分析（图5）。

图4 业务主题域

图5 售罄率自助分析

这种图表结合的形式，让业务人员能直观查看到哪些地区的售罄率低于平均售罄（图中警戒线），并点击该区域的柱形图，联动下方的明细数据表，查看该区域的销售情况，分析问题所在。

通过推送报表、主题报表和分析报表的框架性梳理，IT人员只需花费不到原来一半的时间来监控每周的推送调度任务、开发固化的查询报表和维护分析所用的业务包数据，而业务人员除了常规的运营分析之外，有更多的时间去做灵活自助分析。

模块化建设

基于报表需求的框架性梳理，解决的是面向业务层和IT层的降本增效。第二步的模块化建设，核心主要是面向决策层，解决企业管理人员看数据的问题，这块核心包含两个大的通用模块——PC端驾驶舱和移动端办公，分别以层级驾驶舱和移动办公两个场景来阐述。

层级驾驶舱

层级驾驶舱解决的主要是管理层从宏观数据把控，到具体各个职能中心业务运营数据把握的需求，以往领导对于企业经营的把握往往来自于业务整理的经营数据或者直观的财务数据，但是这种粒度和时效的数据呈现已经远远不能满足信息化当下的数据要求了，管理层希望能有渠道让他们能够即时触达想要查看的各个职能中心的数据，为此，我们将层级管理的理念放入到驾驶舱的设计中，通过层层钻取的方式，实现企业自上而下的管理。

图6 层级驾驶舱设计思路

比如上图层级管理驾驶舱设计，我们除了将领导关注的核心运营指标在经营管理驾驶舱中进行呈现外（出于客户数据的安全性考虑，此处不放具体页面，感兴趣的读者可以联系帆软官方），还提供了各大职能中心驾驶舱的触达通道，比如在我们在经营管理驾驶舱版面发现会员销售占比与去年同比下降，可以直接钻取到对应的会员模块查看会员销售情况。

移动办公

移动办公则是面向便捷式办公的场景，现在碰到的很多企业需求都是快速搭建移动端，但是移动端设计又缺乏方法，并且一张PC端大屏的数据想要在移动端界面上做完整呈现，要经历框架重构、信息层级优化两大步骤，并且实现简单直观、重点突出的呈现，而这无论是对IT人员还是业务人员，都是无法独立完成的任务。实际上移动端的设计理念和PC端的层级驾驶舱设计思路是大致类似的，那这里我们也提供一套基本的移动端设计框架供参考。

移动端框架梳理可以从两个维度来穿插进行，一个是从角色层面，一个是从组织模块层面，首先从人员层面可以按照职位的上下级关系做层级设计，比如总裁-总经理-各职能中心部长-区长-店长，职能中心里面又切分出各个职能板块，比如零售部、商品部、会员部等，那每一个部门里面又有相应的角色层级和业务模块，可按照之前人员层面的逻辑进行子版块的梳理，举例示意如下：

图7 角色工作台

在我们的角色工作台中可以看到，角色的移动端设计中我们将每个角色所关注的核心板块和核心场景梳理出来，具体的落地过程中我们还需要将每个场景内涉及到的指标输出成指标字典，涵盖维度、指标、计算逻辑和取数口径等信息。同时在角色工作台的设计中，权限的设计也是结合角色进行控制的，同一张模板，不同人进去看到的层级不同、内容不同，比如总裁进去看到的是总览页面，并能实现品牌-区域-门店粒度的钻取，而店长进去只能看到自己门店的经营数据。