虾皮成本归集最后落成哪一份表

成本归集最后落成哪一份表，先想清楚

先想清楚这份表是给谁看的，这是定容器的第一步。给自己看的表可以带很多过程列，给经营看的表只能留下结论。同一批数据做两张不同用途的表很正常，但两张表的结论必须能对上。对不上的时候，通常是对经营那张表做了额外的简化，而这一层简化没有被任何人记录下来。

表的用途决定它要多细。用来查问题的表必须细到单笔，用来做决策的表只需要细到类。很多团队只做后一张，遇到问题时再翻原始记录，翻的时候往往已经过了能追责的那段窗口。两张都留一份，日常维护的成本其实并不高，真正贵的是临时回头重建。

容器定下来之后，接着要定它的时间边界。一张表覆盖哪一段、什么时候封账，必须在动手做表之前说定。封账之后还改数，会让所有引用过它的人拿到不同版本的结果。版本一乱，讨论就失去了共同的基础，剩下的只能靠各人印象去补。

表的最小单位要跟业务的提问习惯合得上。如果业务习惯问这个商品的成本是多少，表就该细到商品这一层。如果业务只问这个月花了多少，表做到类就够用。单位比问法细，是白白浪费；比问法粗，是彻底无效。无效的表填得再整齐，也不会有人愿意翻开第二遍。

要留出一定的冗余列，方便以后加维度。一列批次、一列站点、一列币种，现在不用，以后想按这三样拆的时候就不用重建整张表。冗余列的成本只是存储和一点填写时间，重建一张已经用了几年的旧表，代价要高出一个量级，还得回头补历史。

表的命名规则要能自己说明内容，不要把时间、口径、粒度这些信息藏在某一个人的记忆里。用文件名把三个要素直接写出来，别人接手时不用再去问。这一点在人员流动的时候价值最大，在自己半年后回头看的时候也一样有用，不必依赖当时随手留下的注释。

成本表的行数是会持续增长的，设计时要考虑一年以后的规模。现在几千行，一年后可能是几十万行。一开始就按会变大的方式去组织结构，比后来临时拆表要省事。拆表不只是把数据分开，还要把所有引用过它的公式和脚本一起改掉，改漏一处就会长期错下去。

表格的列排列要固定下来，不要让每个人按自己的习惯排。排列换来换去，复制粘贴的时候最容易串列。串列的错误很隐蔽，因为数字看起来都是正常的量级，只有跟来源逐条核对才会露出来，而那时候往往已经过去了一整个账期。

如果一份表同时被几个角色填，要划清每个人负责哪几列。划线之后，责任才有落点。所有人都能改所有列的表格，最后的结果通常是没有任何一行经得起核对。划线不必很细，但每一列都要有一个人名，这个人名不能是部门名。

表要能被人看出哪里是原始数据、哪里是加工结果。混在一起的时候，改一个原始值会连带影响一大片，而没有人知道影响到了哪里。分成两片之后，改动的作用范围就清楚了。这一点在数据量大、经手人多的时候尤其要紧，一次误改可能要花好几天才能理清。

要有一个明确的封账时点，并且把这个时点提前告诉所有相关的人。临时封账会让一部分单据被挡在外面，挡在外面的部分只能落到下一个周期。落下去之后，相邻两个月的数就都不干净，而两个月的数都不干净时，任何横向比较都失去意义。

表的版本要留档，至少留最近三个月的。有人拿着上个月的表来问问题时，能立刻找出那个版本对应的口径。找不到旧版本，讨论就会变成各说各话，最后靠职位高低来定，而不是靠数字本身去定。留档这件事的成本接近零，缺了它的代价却常常是一整轮沟通。

如果同一份数据要出两种语言或者两种币种，尽量在一张表里做两列，不要做两个文件。两个文件一定会分叉，分叉之后没有人能说清哪一份是准的。两列放在一起，对比的时候还能顺手发现换算错，也能让看表的人知道两个数本来就不是同一个东西。

表里要显式标出哪些数是估算、哪些是实际。混在一起，估算会被当成实际用，误差就被固化下来了。显式标出之后，估算的项还可以在下一期被替换成实际数。替换的过程本身也是一次自查，能顺带发现当时估得离谱的那几项，并且把规律记下来。

最后要接受一点，没有哪一张表能同时满足所有用途。给财务的表、给经营的表、给自己查问题的表，本来就应该长得不一样。目标是让它们彼此可追，而不是让它们长得一样。追求一模一样的最后结果，通常是一张表把所有人的需求都满足得不太好。

五个落点里最关键的是第二步和第三步的选择，前者决定精度，后者决定能不能被人一眼看明白。

按单、按类、按期，三种粒度不同

按单是把成本落到每一笔具体的交易上。它的好处是精度高，能回答这一单到底赚了多少。它的代价是工作量随订单数近乎线性增长，一个月几万单的时候，按单核算本身就是一项专职工作。所以是否按单核算，往往不取决于想不想，而取决于有没有人力长期顶住。

按类是把成本落到商品类目、品线或者供应商这一层。它的好处是能看出结构，知道哪一类在拖累整体。它的代价是看不到单笔的极端情况，某一个把成本吃光的商品会被整类平均掉。被平均掉的那一个，往往是这一整类里最值得先动手处理的那一个。

按期是把成本落在一个自然月或者一个结算周期上。它的好处是能直接跟在外的口径合上，跟报表一起看得明白。它的代价是失去了对商品的指向性，数字对得上，但说不清到底是谁贡献了这笔数，也说不清下个月该从哪里开始改。

三种粒度各有各的盲区，这不是设计缺陷而是它们本来的特性。按单看不见结构性趋势，按类看不见个别异常，按期看不见内部构成。选择用哪一种，取决于眼下要回答的问题是什么。问题变了而粒度没变，就会一直得到不太对的答案。

按单落表的前提是每一笔成本都能找到对应的交易。做不到这一点的时候，被迫按类或者按期落，属于被动的选择。被动选择的问题在于，你仍然以为自己在按单核算，实际上已经在用另一套粒度，而差额就悄悄留在中间没有人过问。

粒度不是一次选定就一劳永逸的东西，它会随着业务阶段变化。起步阶段单量少，按单做完全可行；规模上去之后，继续全量按单做就不经济了。这时候该做的是分层，而不是把精度一刀砍掉，砍掉之后想恢复要付出的代价比一开始就分层高得多。

分层的意思是大额按单、小额按类、固定开销按期。三层各有各的处理方式，合起来仍然要对得上总数。这种做法在实操里比全按单更容易长期维持，也比全按期更有解释力。关键是三层的边界写清楚，让经手的人不必每次再判断一遍某笔钱该进哪一层。

分层之后要有一个合并的规则，说明三层怎么汇总成一张总数表。规则不写清楚，三层各自算出来的加起来跟总数不一样，查起来又是一场麻烦。规则可以很简单，但必须写下来，写下来之后每一期都能照着复核一遍。

按类核算最难的是边界，也就是一个商品到底属于哪一类。同一个商品随季节换了用途，分类可能就该跟着变。分类一变，历史数据就不再可比。改分类的时候要同时保留一个不随分类变化的追踪编号，这样前后两段还能接得上。

按期核算最难的是跨期成本的处理，一笔钱正好发生在两个月之间。切分方式一旦定下来就要一直用，不能这个月切开、下个月整笔记。两种做法同时出现在同一张表上，趋势图立刻失去意义，而且看表的人很难判断到底是业务变了还是口径变了。

三种粒度的表要能相互对照，而不是各自独立。至少要做到按单汇总等于按类汇总，按类汇总等于按期汇总。三个总数对不上，说明有一处的成本被落了两遍或者漏了一遍。这一步校验花不了多少时间，但它能挡住大部分累积性的偏差。

对不上的时候不要急着调整总数，先找差额的来源。差额通常集中在几类特殊项上，比如跨期成本、共用的仓储开销、事后才到的调整。找到来源之后，规则改一次就能长期生效，比每个月手工抹平要省事得多，也留下得下痕迹。

粒度粗了不好查，细了不好看，中间的平衡点跟团队规模有关。三五个人做几十个商品的时候，按类其实已经相当细了；上百人的团队做上千个商品，按类反而太粗。同一套粒度标准套在不同规模的团队上，总会有一边觉得别扭，这种别扭不是谁做错了。

浅一层理解是把粒度当成精确度，深一层理解是把它当成回答问题的角度。同一批数据换一个粒度，看到的是完全不同的东西，而不是同一件事的粗糙版本。想清楚这一点，就不会再纠结到底哪一种粒度才是最正确的。

有团队同时维护三套表，看起来很周全，实际上是三套数据各自维护、互不校验。三套表并存本身不是问题，问题在于没有一条规则把它们串起来。串起来之后，一套表里的错误会在另外两套上同时显出痕迹，排查的方向立刻就清楚了。

选粒度还有一个现实约束，就是操作它的人有没有能力长期维护。选一个谁都维护不了的粒度，前两个月还能勉强撑住，第三个月就会开始凑数。凑数的表比没有表更危险，因为它看起来像是有依据的，而所有依赖它的判断都会跟着偏。

越靠上的项目越适合按单去看，越靠下的项目越需要靠同期分摊，硬塞进单一粒度总会失真。

粒度不同结论差多少，举例就明白

拿一个具体的例子最容易说清楚。假设某个月有一批货，采购成本按件算下来每件二十块，整批的运费合计三千，仓储固定开销合计两千。按单看，每件要背上运费与仓储的一部分；按期看，这两千只是一行合计，看不出任何单件之间的差别。

按单落的时候，运费会按件数摊到每一单上，仓储会按存储天数摊下去。摊完之后，卖得快的那些单每件成本低，压货的那些单每件成本高。这个差别反映的是真实的经营差异，不是计算误差，也正是经营上最值得看的那部分信息。

按类落的时候，同一类商品的快慢会被平均掉。平均之后，整个类的单位成本看起来很正常，而里面压货的那几款被完全掩盖。掩盖掉的恰好是最需要被看见的那几款，它们的问题会一直存在到某个季度末才被偶然发现。

按期落的时候，所有的差异都被压成一行。月度的成本总额可能是准确的，但它已经不能告诉任何人该去处理哪一款商品。这个数字适合对外汇报，不适合用来决定下周把资源投向哪里，两者对数字的要求本来就不一样。

同一个月的经营动作，在三种粒度下会得到三种评价。按单看是某几款出了问题，按类看是这一类整体还行，按期看是这个月比上个月略好。三种说法都能从同一批数据里推出来，每一种都没有算错，差别只在于它们看的是不同层的东西。

这就是为什么讨论成本之前先要确认粒度。两个人在争论这个月成本是不是高了，一个在用按单的视角盯着爆款，一个在用按期的视角看着总额，他们讨论的其实不是同一件事。把粒度说清楚，这场讨论往往几分钟就能收口。

粒度对结论的影响在商品数量多的时候会被放大。一百个商品的时候，平均的影响还有限；一千个商品的时候，几个极端值可以把整类的结论直接翻过来。商品越多，越需要先分层再汇总，而不是把所有商品平铺在一张表里做一次平均。

反过来举一个例子。当所有的商品都处在差不多的状态时，三种粒度的结论会很接近。这种时候用什么粒度都行，省力的那一个反而是好选择。选择粒度要看数据的离散程度，不是一律往细里选，也不是一律贪图省事。

差异最容易被掩盖的地方是那些既不属于哪一款、金额又不小的项。共用仓储、客服人力、系统年费都属于这一类。它们在按单的体系里没有家，容易被随手丢进一个大类的合计里，而这一丢，往后所有的单品毛利都不再准确。

按单落表的时候，给这些共用项设一个专门的承接格，比把它们摊到商品上更诚实。摊到商品上会让每一款都带一点并不属于自己的成本，时间一长，没有任何一款的毛利是可信的，连表现突出的那一款也说不清自己是不是真的赚。

反过来，共用项如果永远不落地，就会出现另一种偏差，就是所有商品的毛利加起来高于真实的总毛利。差额一直悬在表外，看单品发现不了，看总数才看得出来。这种偏差会让人对整体过分乐观，等到现金流吃紧时才回头找原因。

两种偏差同时存在的时候，有人会以为是计算错了。其实计算过程没有错，是承接口径没有定。定好口径之后，两种偏差会同时收敛，表也就好看了。把口径写在表的备注里，下一期换人做也不会跑偏。

举例讲到这里能看出一个规律，就是粒度的选择本质上是在选择你想看见什么。想看见单笔的异常，就用按单；想看见结构，就用按类；想对上报表，就用按期。三种都需要，只是用在不同场合，没有必要在它们之间分出高下。

有一个常见的误判是以为粒度越细越专业。细到单笔之后，如果没有人真的去看那些明细，增加的工作量就只是纯粹的成本。专业的标志是粒度与用途匹配，而不是粒度本身有多小，这种误判在刚建账的团队里出现得最多。

实操里比较稳的做法是先按期封账，再往下拆成类和单。按期的那一层负责对得上总数，往下拆的两层负责解释构成。次序反过来的话，很容易在细层里来回调整，最后总数反而没有人管，对外的数也跟着一起飘。

举完例子可以得到一个能带走的判断标准，就是看这份表的结论会不会因为粒度改变而改变。会改变，说明数据里有结构性差异，值得往下细看。不会改变，说明当前粒度已经够用，不必要为了细而细，把人力花在别处更划算。

最容易做错的，是只按整店算一笔账

只按整店算一笔账，是最省事的做法，也是最容易掩盖问题的做法。整店一个数，看起来干净，但它把做得好的和做得差的商品放在一起平均。平均之后，没有人能看出该往哪里使劲，也没有人需要为一款商品的亏损说清楚原因。

整店口径最常见的失效场景是新品。新品在上线的头两个月往往承担了较多的一次性开销，在整店口径里这些开销被摊薄到几乎看不见。于是新品看起来只是略微拖后腿，实际上它正在独自消化一笔不小的投入，而这笔投入本可以被单独看见并且单独评估。

反过来，成熟的爆款在整店口径里也会失真。它背着的是自己的采购和运费，但整店的固定开销被平均分摊之后，它看起来比真实情况更好。于是资源持续往它身上集中，而它其实已经过了最划算的阶段，追加投入的边际回报在下降。

整店口径还有一个隐患，就是不区分渠道。同一种商品在不同市场上的成本结构差别很大，混在一起算等于假设它们一样。假设它们一样的结果，就是两个市场里的表现都看不清，好的那一个得不到加强，差的那一个也得不到纠正。

只在整店层面看，还有时间上的错位。整店的口径通常按月，而商品的生命周期往往按季度甚至更长。按月看，一个正在起量的商品会被当成拖累；按季度看，它可能是最有潜力的那一款。周期的长度与商品的节奏没对上，得到的判断就会反过来说。

有人用整店口径来考核团队，这在客观上会鼓励大家做容易出数的动作。容易出数的动作通常是把成本推给下一期，或者把压力从自己这里挪到别的品类上去。考核口径不细，行为就会自然地往模糊的地方走，而模糊的地方最后都由整体来承担。

整店口径本身有它的用途，主要是跟在外的报表合得上。外部看的是整体，它对到单笔没有兴趣。整店这一层必须存在，问题在于把它当成分析事情的仅有入口。一旦成了仅有入口，所有的问题都只能被描述成这个月整体如何。

补救的办法不是废掉整店口径，而是在它下面加两层。一层按类，看清结构；一层按单，看清异常。三层都做，维护成本会增加，但发现问题的能力完全不同。增加的那部分成本，通常第一批被找出来的异常就能抵回来。

加层之后要重新定义什么叫做好。整店好而某一类差，是结构问题；整店好而某几单差，是个别问题。两类问题的处理方式不一样，混在一起看的后果是什么都不处理，或者把个别问题当成结构问题大动干戈。

判断整店口径有没有压住问题，有一个简单的自检办法。把整店的数据按类拆开，看各类的结论是不是一致。如果拆开之后结论方向完全相反，说明整店那一层确实压住了信息，而这种相反往往已经存在了好几个周期。

这个自检不需要复杂的工具，用现有的表按类做一次汇总就能完成。完成之后你会知道自己的整店数字是不是可信。不可信的时候，先别急着改流程，先把拆开的表建立起来。有了能对照的第二层，讨论才会从感觉回到数字上。

整店口径最危险的时刻是它连续几个月都很平稳。平稳意味着没有波动，而没有波动往往意味着内部的正负变化正好互相抵消。这种时候最该做的是一次拆解，而不是按照习惯去确认一句情况稳定。

还有一层容易被忽略的问题，是整店口径把时间段也压平了。一个月里有淡有旺，混在一起看不出节奏。拆到周维度之后，很多原来看不见的规律会浮出来，比如补货的时间点是不是每年都偏晚，或者某一段的退货是不是集中在同一个批次上。

拆到周维度之后要注意样本量变小。周维度的数字跳动本来就大，不能把任何一次跳动都当成趋势。判断趋势至少要连着看四周，单周的数字只用来发现异动，不用来下结论。把这两件事分开，拆细才不会被拆出来的噪音带跑。

整店口径还有一个隐形代价，就是它让人不再去追问。一个数字能对上报表，看起来就完成任务了。追问的动力消失之后，归集工作会逐渐退化成一种填表动作，填得越来越快，对业务的解释力却越来越弱。

整店口径要不要保留，答案是保留，但要明确它的角色是校验而不是分析。它用来确认下面的层级加起来跟总数一致，而不是用来解释为什么。角色分清楚之后，粒度的选择就不再是一个需要反复争论的问题，而是按用途直接取用。

几份表摆开，各自能看出哪些东西

按单的表最能看出个别商品的问题。它把每一笔交易的成本都摊出来，哪一款在亏、亏在哪个环节，扫一眼就能看出大概。它的代价是读起来慢，量大的时候基本只能靠筛选去找，不太可能从头看到尾。

按类的表停在中间。它把商品并按品线或者按供应商合并，能看到结构和方向。当品线数量控制在二三十条以内时，它可以一屏看完，是可以每天顺路看一眼的那种表，不需要专门安排一段时间去读。

按期的表最适合用在对外沟通上。财务、税务、投资方关心的都是按期汇总的数。它不解释内部结构，但它提供的是一个可以被反复引用的基准。基准稳定，上下游之间的沟通成本就低，每次对账不必再从头解释一遍口径。

三份表加上一份总分校验表，构成一套基本的落账结构。校验表只做一件事，就是确认三种粒度的总数一致。它本身没有分析价值，但它决定另外三份表能不能被放心引用，少了它，前面三份谁都不敢当真用。

按单的表最怕漏项，因为漏一笔就会让某一单的毛利虚高。按类的表最怕分类混乱，因为分类一变历史就不可比。按期的表最怕跨期处理不一致，因为这个月切开下个月整记，趋势就废了，而且很难从图上看出是业务变了还是口径变了。

三份表的使用频率差别很大。按单的表通常只在有人提问时才打开，按类的表可能每周看一次，按期的表每月用一次。使用频率决定了每份表的维护精细度该到什么程度，不常用的那份没必要天天维护，常用的那份反倒值得多花点工序。

有人会想能不能只用一份表，把三种粒度做成三个页签。做法可以，但要注意三个页签必须从同一份底层数据来。各自录入的表格早晚会出现对不上的情况，而这种不一致往往要等到某次对外汇报时才被发现。

底层数据只有一份，是三份表能互相校验的前提。为了实现这一点，录入动作要尽量集中在最细的那一层。往上汇总比往下拆分容易得多，也可靠得多，操作的人也更容易理解自己在做什么样的一件事。

基础数据只有一份，是三份表能互相校验的前提。为了实现这一点，录入动作要尽量集中在最细的那一层。往上汇总比往下拆分容易得多，也可靠得多，操作的人也更容易理解自己在做什么样的一件事。集中录入还有一层好处，就是同一笔钱不会被两个人各记一遍。

按单的表还能反过来支持定价，因为它告诉你每一款的真实成本。定价的时候有了真实成本，就不用靠感觉去估一个缓冲。这是按单核算最直接的一处用处，也是很多团队愿意在明细上多花人力的原因。

把粒度留细一层，定价环节就多了一处立足点。知虾公开的定价计算一栏里，各项费用按站点并排列出，更新时间标在页面顶端那一行。它摆的是各站点当下的费用构成，不涉及你这一层的落表选择。拿它跟自己的按单表对照一遍，能看出自家的成本项有没有漏掉的类别。

三份表要给不同的人看。给采购看按单的，给运营负责人看按类的，给管理层看按期的。给错了对象，收到的反馈多半是这份表没什么用。不是表没用，是这份表的粒度跟看表人要回答的问题没对上。

交付的对象不同，同一份数就该换一层包法。知虾公开面的站点分析里，成交与费用结构按站点分组呈现，数据按日更新到前一交易日。这一栏给的是站点之间的横切面，落到哪一层表上仍然由你决定。包法选错了，收表的人只会觉得这堆数跟他没关系。

要注意的是规则只能触发复查，不能直接触发动作。成本数据反映的是已经发生的事，而动作发生在以后。把两者直接连起来，容易在数据滞后的那段时间里做出错误决定，尤其是那些成本入账本来就偏晚的项目。

三份表之间的差异本身也是信息。按单表上某几款很差、按类表上整体尚可，说明这个类里面的分布很不均衡。均衡的类不会出现这种反差，出现反差就说明有值得动手处理的地方，顺着这条线找比漫无目的地筛更省时间。

最后要提醒一点，表越做越多，维护成本会跟着往上涨。三份表是比较合适的数量，再多就需要有人专门去维护。专职之后，表就从工具变成了负担，反倒是少做一份更划算，把省下的人力用在读表上更划算。

三个动作上都强的成本最省事，只在一处强的成本必须提前决定它落在哪一层，不能两头都挂。

换粒度该怎么判断时机，看哪一处

换粒度不是凭感觉的事，它有一些能观察到的信号。最直接的一个是提问的方式变了。如果团队开始频繁问这一类商品怎么样，而现有表只到整店，说明粒度已经跟不上问题了。问题先变、表后变，是很自然的节奏，关键是别拖太久。

第二个信号是异常项被反复提起，但在现有表里找不到落点。同一个问题连续几个月被问，每次都只能给出一个大概的解释，说明表需要多出一层。问题反复出现不是某个人不认真，是容器本身没地方装它。

第三个信号是维护的时间明显变长。当每个月做表的时间从两天涨到五天，而数据量只增加了一点，多出来的时间通常花在了手工调整上。手工调整变多，说明现有粒度跟实际业务对不上，只能靠人力在中间硬拉平。

第四个信号是有商品长期无法归类。归类不进去的商品会被放进一个其他项里，其他项的占比逐渐变大。这个比例超过一定水平，说明分类体系需要重建，而不是继续往那个格子里塞东西，塞得越满越难拆。

第五个信号是对不上账的次数变多。粒度本身不会直接引起对不上，但粒度不匹配会引起反复的手工校正。校正的次数在往上走，就是在提示结构该调整了，而不是提示某个人需要更仔细一些。

校正次数是一个比金额更敏感的温度计。每次手工调整都记一笔原因，区分开是折算差异还是归属写错。次数往上走的月份，多半就是结构该重排的月份。知虾的多站点数据把各市场的费用构成按日更新到前一交易日，可以先拿来排除是不是口径层面的普遍偏移。

换粒度要避免一步换到底。从整店直接跳到按单，工作量会突然放大几倍，而且新表在第一期一定谈不上完美。比较稳的做法是先加中间那一层，跑顺之后再决定要不要继续往下走，每加一层都留一段适应时间。

换之前要先把旧表的最后一个周期完整做出来，作为一个基准。后续新表能不能延续旧表的结论，就用这个基准去比。没有基准的话，换完之后是好是坏说不清，很容易在争议里把新表又改回去。

换粒度还会影响考核指标的口径。指标跟着变，就会有人在换口径的当月受益或者吃亏。这种情况下要提前把过渡期的算法说清楚，把规则问题和技术问题分开谈，避免把一次结构调整变成一场关于个人得失的争论。

换粒度的收益通常不会立刻显现，要等两三个周期才能在表上看出差别。判断有没有效果，可以看一个指标，就是同样的问题需要几次追问才能给出答案。追问的次数在下降，说明粒度确实对上了，这比任何主观感受都更可靠。

有一种情况不该换粒度，就是问题其实出在数据质量上而不是粒度上。数据本身就漏，换成更细的粒度只会漏得更明显，并不能解决任何根本问题。这时候该修的是录入环节，不是表的形状，改形状只是把毛病放大了一遍。

区分的办法很简单，看漏掉的是分散的几笔还是一整段。分散的几笔是质量问题，一整段没有是粒度没覆盖到。两者混着一起改，会把一个简单问题搞复杂，也会让真正该动手的那一环一直没有人碰。

换粒度还有一个隐性成本，就是所有人的习惯要重新建立。习惯重建期间效率会下降，这个下降是正常的，不要在下降期又改一次规则。连续改两次，团队会对新规则本身失去信任，往后再推任何改动都会先被怀疑一遍。

新粒度上线之后要留一段观察期，观察期内不做考核。考核压力会让人绕过新规则回到老办法，而新规则一旦被绕过一次，之后就很难再立起来。观察期里要做的是记录问题，而不是评价人，两者混在一起就没人愿意提问题了。

判断换粒度是否成功的最终标准，是这份表能不能自己解释自己。不需要额外说明就能被读懂，说明结构对了。需要一个人站在旁边解释，说明还差一层或者多了一层，两种毛病都会让表在实际使用中慢慢被搁置。

换粒度的决定应该由用它的人来做，而不是由做表的人来做。做表的人倾向于把表做得更规整，用表的人只关心能不能回答问题。两个视角都需要，但决定权放在用表的那一侧，落出来的表才更容易被真正用起来。

按单看的解释力随时间掉得快，按期看的解释力一直在高位，两条线的距离就是这两种粒度各自的用处。

落表讲完，分摊口径往前一节看

这一篇讲的是结果落在哪里，没有讲成本是按什么基数分过去的。这两件事经常被混为一谈，但它们发生在不同的阶段。分摊是决定怎么分，落表是决定分完放在哪一层。次序上是先分后放，反过来做通常要返工，返工的时候还会带上一堆已经对外用过的数。

分完之后再决定放的位置，好处是可以按用途去选粒度。如果先定粒度再分摊，分摊的方法会被粒度限制住，很多本来可以用的分法就用不了了。权限被限制住之后，人往往不是换方法，而是干脆把这一类成本丢到一边不处理。

举个具体的次序。先按件或者按金额把共用开销分到各个商品上，再把分好的结果按品线合并成一张类表。这个次序下，分法和落点各自独立，想换其中一个不用动另一个，改动的影响范围小，复核起来也快。

反过来的做法是先建一张品线表，再把开销直接分到品线上。这种做法省了一步，但失去了分到商品的能力。以后想按商品看成本，就只能重新分一遍，而重新分的时候原来的判断依据往往已经找不到了。

所以落表这一层要尽量保留可以被继续拆开的信息。合并的时候保留一个原始编号，比只留一个名称要好。编号不随名称改变，长期看会更稳定，也不会因为某一次改名就让前后两段数据接不上。

分摊口径那一段要处理的是基数选择。按销售额、按件数、按重量、按占用天数，每一种都会把结果推向不同的方向。这一部分内容在下一节里展开，这里只交代它与落表之间的先后关系，以及中间那个接口该留什么。

两段之间要有一个接口，通常是一张明细底稿。底稿上带着每一个商品分到的成本，落表这一层拿到底稿之后再往上合并。有了这张底稿，换粒度的时候不用重新分摊，也不会因为换了一次表就丢掉原来的划分依据。

底稿的字段要一次设计到位，至少要包含商品编号、成本项、金额、期间、来源。少一个字段，以后想按那个维度分析就得回头补。补数据比一开始就留好字段要贵得多，而且补出来的历史数据往往带有推断成分，用起来需要格外小心。

底稿不需要给人看，它的作用是承接。正因为不需要给人看，它可以保留很多中间状态的列，也就不容易在传递中丢失信息。给人看的表越简洁越好，底稿则越完整越好，两者的取舍方向正好相反。

从底稿到最终表，中间可以有多层汇总，但每一层都要能被单独检查。只有一层最终表、没有中间层的做法，出错时找不到是哪一步出的问题，只能从头再走一遍，走的次数多了，做表的人也会开始害怕改动任何一处。

中间层的层数不宜过多，三层左右比较合适。层数太多，每一层都会引入一点误差，累积起来就说不清；层数太少，又失去了排查能力。分层数这件事应该按团队实际会去查看的层级来定，不必照着别人的做法直接搬。

两段的分工还有一点要说明，分摊解决的是公平问题，落表解决的是用途问题。分得公平不等于用得顺手，放得顺手也不等于分得合理。两个目标要分别去追，不要指望一张表同时把两件事都做得很到位。

有团队为了省事把两段合并，直接按品线分固定开销。这样做在品线数量少的时候没问题，品线一多就会出现同类商品之间成本差异过大的情况。差异过大时，任何基于品线的定价都会被扭曲，而这种扭曲在单个品线内部是看不出来的。

合并两段的另一个后果是失去了追溯能力。出了问题只能看到品线级别的数，看不到是哪一款贡献的。追溯能力一旦丢掉，要靠重新建立底稿才能找回来，而底稿需要历史数据，历史数据往往已经不在手边了。

所以在这件事情的次序上，建议是分摊在前、落表在后，中间留一张底稿。这个次序会多花一点初期工作量，但后面的灵活性完全不同。灵活性在成本核算里会不断被用到，尤其是在商品结构变化比较快的阶段。

落表这一段讲完，接下来该看的是分摊的基数怎么定。基数定得不合适，无论后面放得多整齐，结论都会偏，而且偏的方向很难从表上直接看出来。两段合起来，才是这份成本表能被信任的完整理由。

常见问题（FAQ）