杭州某品牌管理有限公司主营大牌化妆品的进口运营销售,业务覆盖天猫国际、京东国际、抖音、拼多多、得物等多个平台。

2024年,庄总担任企业业务负责人。上任初期,面对多平台、多业务线的经营情况,他希望先通过数据全面了解企业现状。于是,庄总购入九数云,从经营分析开始了企业的数字化建设。

初期,庄总主要借助九数云搭建销售、利润、库存等经营看板,将分散的业务数据集中起来,通过数据了解企业经营情况,为日常管理和经营决策提供依据。
随着使用深入,企业对数据分析的需求逐渐增加,底层数据分散、口径不一致等问题也开始显现。于是,庄总进一步推动数据底层的重构,将不同平台、不同系统的数据统一起来,重新梳理利润、库存等核心数据,逐步建立企业自己的数据底座。
当数据底座逐步完善后,企业开始进一步探索数据在业务端的应用:除了用于经营分析,还能否与实际业务流程结合?
由此,企业进入了新的数据应用阶段。九数云中的数据开始进一步延展至飞书协作、财务开单、费用对账、平台结算、业务自动化等场景,数据也从单纯的分析结果,逐步进入业务执行过程。
这一次,效果直接体现在了经营帐上:
我们跟着庄总的数字化探索,看看企业进入3.0之后,数据又是如何真正用起来的。
完成 2.0 的数据底座建设后,企业已经基本解决了数据分散、口径不一致等问题。数据经过统一整理,能够稳定支撑经营看板和日常决策。
但当数据真正沉淀下来之后,庄总开始思考另一个问题:这些数据除了用来看,还能不能直接参与业务?一旦往业务端走,企业就发现,业务本身对数据的运算要求,远比“做看板”复杂:
过去货品进度主要依靠人工传递。一个货品出现问题,物流、渠道、采购之间需要层层沟通,信息在传递过程中容易失真。
看板能够及时发现问题,但发现之后还需要人工跟进,数据和业务执行之间仍然隔着一层。
这意味着,对账已经不是简单汇总数据,而是要对海量明细进行持续、准确的逐单核算。
平台技术服务费涉及扣减、返还等多种情况,财务虽然掌握大致规则,但具体计算逻辑并不完全明确。
为了厘清规则,企业需要回到底层订单数据中逐笔比对,将平台实际结算结果与订单、费用明细进行交叉验证,再从大量数据中反推出平台的计算逻辑。
三个场景背后,其实是同一个问题:数据已经能够支撑“看”和“分析”,但还没有真正进入业务执行。

问题明确之后,企业没有再把数据停留在看板和分析层,而是开始进一步延展九数云中的数据应用,将数据与飞书协作、财务开单、费用对账、平台结算等业务场景结合,让数据不再只是经营分析的结果,而是直接参与业务判断、计算和执行;形成了4大场景的解决方案
看板解决了"看见",但业务需要的是"执行"。
企业利用九数云的数据回填功能,将汇总后的结果自动回填到飞书表格 —— 每一条数据记录,就成为一个沟通主题。
过去
一个品分配到哪个仓,要靠各环节对接人口头传递,信息越传越走样。
现在
所有关于这个货品的沟通都沉淀在这条飞书数据的评论区里,@对应人员、记录处理结论,无论哪个部门介入,看到的都是同一份上下文,彻底避免"人传人、逐渐模糊"的问题。

过去
采购、销售计划的跟进主要依靠人工沟通和反复确认,计划达成情况、异常原因等信息分散在不同人的沟通记录中,业务人员很难围绕同一条数据持续跟进。
现在
采购、销售计划数据从九数云自动流入飞书表格,达成情况、异常原因和处理进度都直接沉淀在对应的数据记录中,相关人员可以围绕同一条记录进行评论、跟进和协作。
在此基础上,庄总还针对采购提醒设计了一套“冷静期”机制:
这样一来,提醒不再是每天机械推送,而是只在问题真正需要处理时再次出现。对于700多个普通商品,也能持续获得接近“核心SKU”级别的关注。

看板能告诉企业“赚了多少”,但到了结算和费用环节,真正需要的是逐单算清楚。
企业利用九数云的本地宝、数据对比等功能,实现百万级账单的精细化核算。面对不同平台、不同费用类型的账单,企业可以先将分散的数据统一汇总,再按照实际业务规则建立核算口径,与平台最终结算结果逐单比对。
平台百亿补贴需要经过平台财务审核后才能结算,实际到账金额可能不准确,也可能迟迟不结算。
企业想核对这笔账,首先就要面对75万条账单,而且数据还分散在多份文件中,普通Excel已经难以处理,只能选择相信平台。
企业通过九数云本地宝自动合并多份账单,再按照“一个商品ID、一个规则、一个价格”建立预估补贴规则,与实际到账金额逐单比对。
每月的自动核算,让成规模的差异自动被识别,再一单单与平台方核对。单月能追回1-5w的差额,既减少了企业资金损失,也让利润预估更加准确。

企业每月需要处理100—200万条费用明细,一个订单往往对应多条费用,运费、关税、补贴等都有不同的计算规则。通过九数云,企业按照不同费用的计算规则建立预估模型,再与实际账单逐单比对,每月可以核对出几万的费用差异。
差异一旦被识别出来,还可以继续追溯具体原因。
这样,物流对账不只是把账单核对清楚,还能从每一笔差异里找到费用和业务上的问题。

当数据已经能够被稳定核算,企业进一步把这些结果送进业务流程。换句话说:数据不只是告诉人“应该怎么做”,而是可以直接推动后续动作。
某电商平台采用托管卖货模式,SKU数量多、价格变化快,人工很难持续盯住800个左右的商品。
企业在九数云中计算出准确的商品成本数据,再将数据接入自动竞价程序,把利润要求直接转化为竞价规则,让机器知道什么价格可以卖、什么价格不能卖:
目前,98%的竞价运维可以自动执行,让这个渠道利润率从2%提升至10%。

企业原有ERP承担着采购、销售、费用等业务单据的正式开立,但系统比较老,没有API,外部数据无法直接写入。
采购、销售、费用发生后,财务只能根据业务信息,在ERP里一张张查、一张张录。随着SKU和供应商越来越多,重复录单就成了很大的工作量。
企业用九数云 + 飞书把这段流程补起来:
这样,九数云负责数据,飞书负责协作,ERP负责业务单据,一键完成过去最繁琐的录单动作。
同样的思路还用在了分销业务上。企业把库存和在途数据通过货盘系统提供给淘宝分销客户,客户可以直接看到当前库存和预计到仓时间,新品在途期间也可以提前预售。


数据因此不再只是企业内部的分析结果,而开始成为连接企业内部系统、员工和外部合作伙伴的业务资源。
前面的场景解决了数据“能看、能算、能执行”的问题。但在实际业务中,还有一些规则并没有被明确下来,而是藏在藏在大量订单和费用数据里,依赖财务人员的经验进行判断。
企业进一步利用九数云的原生AI九思,从底层数据中发现规律,再把验证后的规则沉淀下来。
以平台技术服务费为例,涉及扣减、返还等多种情况,财务虽然知道大概规则,但具体怎么算并不完全清楚。
企业将订单明细、对账单明细、库存流水、售后单明细等数据交给九思,再结合业务时间、出账时间、发货时间、售后时间等信息进行交叉分析。
九思可以从大量订单中快速找到异常和规律,再由业务人员结合实际规则进行验证。比如
通过这样的分析,企业逐步把原本依赖财务经验的判断,变成了明确的数据规则。



与通用型AI工具不同,与通用型 AI 工具不同,九思不是分析完一次就结束,而是可以进一步把规则沉淀下来,继续用于后续数据。
比如做平台对账时,九思发现并验证了一套对账逻辑后,就可以进一步形成对应的逻辑模型,把不同的费用情况、退款情况等纳入判断。
后续新的账单数据进入后,九思就可以按照这套逻辑自动计算、比对,持续跑出异常订单,而不需要财务每次重新分析。
于是,整个过程就变成:数据进入 → 九思分析 → 发现并验证规则 → 九思沉淀监测模型→ 自动输出异常结果。
庄总对此评价:
“九思对数据的敏感度是高于我们财务人员的。它自己会总结规则,使用者如果本身就有一定的经验,很容易在九思找到‘惊喜’。”
规则发现是一次性的聪明,持续监测才是长在数据底座上的企业能力。

回顾过去,庄总的总结很朴素:
“正是因为在九数云做第一版搭建的时候,看到了九数云的价值,才想到如何构建更好的底层数据、做更多的价值扩展,才有了 2.0 数据治理的想法。”
当时沉淀的数据底座,如今正在 AI 时代被进一步放大。
模型可以越来越聪明,但只有建立在完整、准确、体系化的业务数据之上,AI 才真正有能力理解企业、调用数据并参与业务。
正如庄总所说:“数据化 → 自动化 → 智能化,没有数据底座的前提,后面两个东西很难形成闭环。”
这句话反过来也成立:凡是能形成闭环的企业,底层一定有一块早早啃下的数据底座。因为数据底座一旦建成,企业向前走的每一步,都不再是从零开始。
也许在不久的将来,我们还会再次与这家企业相约,见证它走向 4.0,也见证它在数字化与 AI 的浪潮中不断前行!