产品经理-7分钟案例分析(1)数据驱动内部财务审计SOXAudit
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
7分钟案例分析(1)数据驱动内部财务
审计SOXAudit
比起规模宏大的平台架构,笔者希望专注于项目本身,并记录这
个项目的全生命周期,希望大家花7分钟,就能了解到一个项目的前
世前世。
我所在公司是本部在美国的跨国企业,经常会有很多关于内控方
面的需求。
而前最近笔者就接到了来自财务部门关于SOXcomplianceaudit的需求。
首先什么是SOXcomplianceaudit–SOX原称SarbanesOxleyAct,
来源于美国联邦颁布的一套非常复杂法案,其中对企业影响最大的是
每年要求出具一份内控报告来评估企业是否有足够的内控,同时以后
需要核算时对这份报告成功进行背书。
在这个背景下,笔者身为市场部门数据中台负责人,内控项目理
所当然也就成为了我们团队需要重点关照的对象。
这其中有一条业务
是关于与广告联盟的合作,基于不同的佣金模型,比如基于导流或者
导流所产生的支付佣金。
这条业务与超过13万个独立导购网站正在进
行着合作并每年为公司创造亿美金规模的利润。
同时公司目前目标公
司也需要支付千万美金的佣金费用。
今年财务团队对上半年这笔费用准确性提出了质疑。
笔者公司有
20+人的业务团队负责对接13万个合作伙伴,因为业务发展变化过快,费率模型太复杂,并行操作过多,单单依靠业务团队维护一套正确的
费率计算变成一个大难题。
实际上除了勉强能维护的顶级流量外(其
实也是乱七八糟),大部分合作伙伴基本要素失去处于完全失去管理
的状态。
当我们团队接手时,发现业务同学把所有的费率数据全部维护在
雅虎文档,并且经常发生多人同时再次出现对这个文档成功进行修改。
提一句,这个现象在传统企业是一个非常总体而言的现象,随之而来的就是导致了流程管理极为混乱,数据质量参差不齐,较弱的人手导致数据遗失非常严重。
更糟糕的是,我们创业团队在进一步分析后,发现理论支付的佣金数和实际支付差距高达40%。
根据SOX法案,如此‘惊人’数据肯定无法顺利通过内控审核。
笔者梳理了一下现有的业务的流程:
介绍一下这个第三方管理平台,它用来管理于公司合作的所有导购网站并核算佣金模型以及佣金支付。
业务团队会直接在第三方的管理界面上调整对佣金模型进行,而数据团队定时将导购网站的交易数据分享至第三方平台,并通过佣金模型计算出我公司要支付的佣金佣金费用。
可以发现,最核心仰仗的费用计算全部依靠这个三方平台,而我们公司其实没有办法保证这个平台的准确性。
那么一旦面临审查机构对我们工商企业的质讯时,这个风险问题就会凸现出来,目前由于大量人工的操作瓶颈,所以没有办法对海量的模型进行把控,对每一比交易进行核对并对可疑交易进行预警。
所以这个项目需要的是构建一套并行的内部费用计算系统,实现组织工作高度监管的佣金审计电子计算机工作,帮助业务和财务部门高效监控费用支付并保证支付准确,并主动对有可疑的交易进行证券交易预警。
这个需求有两个难点:
(1)佣金数学模型结构化过于复杂,存在大量开发设计的定制化需求以及奖励触发条件。
这种业务在数据层面的切割会导致结构化后不同会有极大的膨胀。
下面举一个例子:导购网站A在手机品类上所的佣金是1%,在首饰品类上成交总量10000美金以下佣金2%,超过部分5%,其余的所有的佣金为2%。
对于这个一个佣金模率,当在全品类(千种以上)上的时候费率拉开序幕多达上万条。
(如下)
实际情况远远比这个佣金模型复杂的多,我们有130万个这样的合作伙伴,意味着即将要面临的是海量费率模型的全历史维护并需要进行准确的费用计算。
(2)天气预报对于主动气象需求的多样性
财务和业务金融业务团队为了保证高质量的引流,在各个方面都可能会几乎添加预警,如交易数量不平,佣金金额不平,奖励条件触及不合理等。
那么面对这些在未来很有可能需要大量开发的工作,如何做到让用户可以以最小的投资成本生产成本,整套化监控和预警,在设计上所给了我们一个很大的难题。
接下来的产品设计就着重从这几个角度出发,进行实现。
基于以上分析分析,我们提出了整体解决方案:
上面的设计满足以内了以上的几个需求。
首先我们通过自动集成第三方的数据落地ODS层有效保证了数据的一致性,同时在本公司内部同步了一份可读的佣金模型。
在结构化引擎这一层,我们将佣金模型展开扁平化展开后,对语义进行封装,保证了对以后对更多的佣金的横向可扩展性。
终究将加工过的数据结构化落地,并在我们的数据平台上电子商务平台展开开放,供SQLbased分析。
之后将数据进行BI层的搭建,基于业务需求,对多个数据源需要进行聚合,通过OLAP(Kylin)进行数据聚合后,在我们内部的BI应用上进行展示。
过程中对异常数据,我们团队进行了在各个位阶的检测,从ODS,数仓,OLAP,业务每一层都预留了数据检测的定制化服务,允许包括工程师,分析师以及业务发展同学,定制基于需求的异常监控和主动预警。
这个项目涉及到了跨团队合作,跨公司合作:。