7分钟案例分析 （1）：数据驱动内部财务审计

小提示：您能找到这篇{7分钟案例分析 （1）：数据驱动内部财务审计}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的7分钟案例分析 （1）：数据驱动内部财务审计内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

比起规模宏大的平台架构，笔者希望专注于项目本身，并记录这个项目的全生命周期，希望大家花7分钟，就能了解到一个项目的前世今生。

背景

我所在公司是本部在美国的跨国企业，经常会有很多关于内控方面的需求。最近笔者就接到了来自财务部门关于SOX compliance audit 的需求抖音代运营需要授权吗。

首先什么是SOX compliance audit – SOX原称Sarbanes Oxley Act，来源于美国联邦颁布的一套非常复杂法案，其中对企业影响最大的是每年要求出具一份内控报告来评估企业是否有足够的内控，同时需要核算时对这份报告进行背书。

在这个背景下， 笔者身为市场部门数据中台负责人，内控项目理所当然也就成为了我们团队需要重点关照的对象。这其中有一条业务线是关于与广告联盟的合作，基于不同的佣金模型，比如基于导流或者导流所产生的成交支付佣金。这条业务与超过13万个独立导购网站正在进行着合作并每年为公司创造上亿美金规模的利润。同时公司也需要支付千万美金的佣金费用。

痛点分析

今年财务团队对这笔费用准确性提出了质疑。 笔者公司有20+人的业务团队负责对接13万个合作伙伴，因为业务变化过快，费率模型过于复杂，并行操作过多，单单依靠业务团队维护一套正确的费率计算变成一个大难题。 实际上除了勉强能维护头部的顶级流量外（其实也是乱七八糟），大部分合作伙伴基本处于完全失去管理的状态。

当我们团队接手时，发现业务同学把所有的费率数据全部维护在谷歌文档，并且经常发生多人同时对这个文档进行修改。

提一句，这个现象在传统企业是一个非常普遍的现象，随之而来的就是导致了流程管理极为混乱，数据质量参差不齐，有限的人手导致数据遗失非常严重。更糟糕的是，我们团队在进一步分析后，发现理论支付的佣金数和实际支付差距高达40%。根据SOX法案，如此‘惊人’数据肯定无法顺利通过内控审核。

需求分析

笔者梳理了一下现有的业务的流程：

介绍一下这个第三方管理平台，它用来管理于公司合作的所有导购网站并核算佣金模型以及佣金支付。业务团队会直接在第三方的管理界面上调整对佣金模型进行配置，而数据团队定时将导购网站的交易数据分享至第三方平台，并通过佣金模型计算出我公司需要支付的佣金费用。

可以发现，最核心的费用计算全部依靠这个三方平台，而我们公司其实没有办法保证这个平台的计算准确性。那么一旦面临审查机构对我们的质讯时，这个问题就会凸现出来，目前由于大量人工的操作瓶颈， 所以没有办法对海量的模型进行把控，对每一比交易进行核对并对可疑交易进行预警。

所以这个项目需要的是构建一套并行的内部费用计算系统，实现高度监管的佣金审计自动化工作，帮助业务和财务部门高效监控费用支付并保证支付准确，并主动对有可疑的交易进行预警。

这个需求有两个难点：

（1）佣金模型结构化过于复杂，存在大量的定制化需求以及奖励触发条件。 这种业务在不同层面的切割会导致结构化后数据会有极大的膨胀。

下面举一个例子：导购网站A在手机品类上的佣金是1%，在首饰品类上成交总量10000美金以下佣金2%,超过部分5%，其余的所有的佣金为2%。

对于这个一个佣金模率，当在全品类（千种以上）上的时候费率展开多达上万条。(如下)

实际情况远远比这个佣金模型复杂的多，我们有130万个这样的合作伙伴，意味着即将要面临的是海量费率模型的全历史维护并进行准确的费用计算。

（2）对于主动预警需求的多样性上海凡圣科贸有限公司 邮

财务和业务团队为了保证高质量的引流，在各个方面都可能会添加预警，如交易数量不平，佣金金额不平，奖励条件触及不合理等。那么面对这些在未来很有可能需要大量开发的工作全网营销讲师，如何做到让用户可以以最小的成本，定制化监控和预警，在设计上给了我们一个很大的难题。接下来的产品设计就着重从这几个角度出发，进行实现。

产品设计

基于以上分析分析，我们提出了整体解决方案：

1. 和三方平台对接，落地佣金模型ODS层。
2. 开发语意引擎，自动消费佣金模型元数据并使用结构化引擎来读取费率模型，生成最细粒度的结构化费率数据。
3. 应用佣金模型，使用核心交易数据模拟实际支付费用，并与佣金结算数据进行对比，实现费用监控。
4. 预留多层级自动监控和定制化警报推送。
5. 开放结构化的佣金模型数据，为分析师和业务人员提供自主分析和查询。

上面的设计满足了以上的几个需求。 首先我们通过自动集成第三方的数据落地ODS层保证了数据的一致性，同时在本公司内部同步了一份可读的佣金模型。

在结构化引擎这一层， 我们将佣金模型进行扁平化展开后，对语义进行封装，保证了对以后对更多的佣金模型的横向可扩展性。最终将加工过的数据结构化落地， 并在我们的数据平台上进行开放，供SQL based 分析。

之后将数据进行BI层的搭建， 基于业务需求，对多个数据源进行聚合，通过OLAP（Kylin）进行数据聚合后，在我们内部的BI应用上进行展示。

过程中对异常数据，我们团队进行了在各个层级的检测，从ODS， 数仓， OLAP， 业务每一层都预留了数据检测的定制化服务，允许包括工程师，分析师以及业务同学，定制基于需求的异常监控和主动预警。

交付和资源配置

这个项目涉及到了跨团队合作，跨公司合作：

• 人员：跨部门合做，3名同学；
• 地点：美国&中国；
• 交付周期：3周。

价值定位

1. 这个项目实现了公司内部的佣金模型元数据的管理，避免人为原因导致缺失或错误佣金模型的情况。
2. 内部的审计和风控做到了有据可依
3. 主动的报警会避免一些错误支付的风险。
4. 产品也为业务团队提供了BI的解决方案，可视化每个导购网站的综合表现，以便更好的增加对头部导购网站的投入，最大化利润。

作者：Stanley；邮箱： pm_stanley@163.com

本文由 @Stanley于。，。

题图来自 unsplash，基于 CC0 协议