软件成本由几块组成
把成本拆开之前,先明确拆的目的。不是为了做一个精确的账,而是为了看清哪一块会随规模变化。有上限的支出和没上限的支出,在决策里的分量完全不同。分块的意义就在这里,不在数字算得多准。
六块分别是订阅费、搭建成本、维护成本、纠错成本、学习成本、机会成本。前一块是花钱,其余五块主要花时间,偶尔也花一点钱。时间的价格容易被当成零,一旦换算成钱,排序往往会变。
订阅费的特点是固定且有上限。不管铺十条还是一千条,周期费用不变,也不会因为出错而增加。它是最容易比价的一块,也是最不适合作为唯一依据的一块,因为它不反映工作量。
搭建成本集中在启用初期。把栏位对一遍、把模板调通、把第一批商品试跑出来,这些动作都有耗时,而且不能跳过。这段投入的意义是把后面的重复动作固化下来,所以它更像是投资而不是消耗。
维护成本是长期的小额支出,规则一改就要跟着调。它的特点是频率不高但持续不断,单次不多,累计起来可观。多数人对维护成本的估算偏低,原因就是它每次只占半天一天,不容易被记住。
纠错成本是返工和整改带来的花费。铺出去之后发现字段错了、类目落错了、图片有问题,都要回头一条条处理。这块成本最明显的特点是它和铺货量正相关,铺得越多,潜在的返工面就铺得越开。
学习成本和机会成本最容易漏掉。学习成本是人和系统互相熟悉的耗时,机会成本是被占用的那段时间原本可以拿去做的事。这两块不产生任何账单,却实实在在吃掉了店铺本就不多的可用精力。
把六块列在一张纸上之后,通常会看到一件事,就是能算成钱的那几块其实不占主要位置。占主要位置的是那些用时间计量的,而时间在哪里花掉,平时并不容易记住。列这张纸的意义是让看不见的部分显形。
六块的划分不必强求统一,各家可以按自己的习惯来。有的店铺习惯把维护和纠错合成一块叫调整成本,只要前后口径一致,合并也可以。重要的是这个划分在整个观察期内保持不变,否则不同时期的数据没法比较。
有一个容易被漏掉的块是数据整理的耗材时间。为了让软件能处理,商品资料要先整理成固定格式,这一步往往比想象中长。它可以归到搭建成本里,也可以单列,但不要两边都不归。
六块之间还会互相转换。搭建做得好,维护会少一些;规则写得清,纠错会少一些。前期的投入能换后期的支出下降,这种转换关系是分块之后才看得出来的,也是分块本身的价值。
六块之间还有一个区别值得单独说,就是哪几块可以通过一次投入降下来。搭建和学习属于一次投入,做完就固化;维护和纠错属于持续支出,做得好也只能压低而不能归零。看清这个区别,就知道该把力气往哪边放。
还有一类成本常被划到别处去,就是判断被挤压之后带来的损失。维护和纠错占用了时间,判断环节被压缩,结果就是选品的质量下降。这部分损失不会出现在任何一份成本表上,但它确实存在,而且是几块成本共同作用的结果。

订阅费只是第一块,后面五块往往不写在账单上
订阅费之外的开销
搭建成本可以按天数来估。从决定启用那一天算起,到第一批商品顺利铺出去为止,中间一共花了多少个工作日。这个天数乘上负责人的日均时间成本,得到的就是搭建成本的大致量级。
学习成本按人来估算。同一个人从完全不会到能独立跑完一批,中间经历的全部学习时间都要算进去。如果店铺里有两个人会用到这个环节,学习成本就要按两份来算,不能只算那个先学会、然后教别人的人。
机会成本不需要精确。做法是看这段时间本来最可能用来做什么,是选品还是谈供应链,然后粗估一个产出量级。目的不是算清楚,而是在比较两种方式时提醒自己,时间不是免费的。
搭建成本里最容易低估的是试错那一部分。第一次调模板往往要来回改好几遍才能跑通,这些来回本身也算成本。按天数估算的时候,把这些来回改的时间算进去,得出的数字才比较接近实际。
学习成本的分布不均。第一个人学会要花较多时间,后面的人学会往往快一些,因为可以问。但人员一换,这部分成本就会重复发生一次。按人估算时要考虑流动的可能,不能按一次性投入来算。
机会成本在两种情况下会明显上升。一是同时做多个渠道的阶段,注意力被切得很碎;二是旺季,本来每一小时都能带来产出。这两种情况下把时间花在维护和纠错上,代价比平时高。
这几块加起来才是真实开销。只看订阅费会得出一个偏低的结论,因为被忽略的那几块在总成本里往往占了大头。把六块列在同一张纸上看,排序通常和直觉给出的顺序不一样,这个反差本身就很说明问题。
搭建成本还有一个特点,就是它容易被当成一次性支出而忽略后续的重复。换一次做法、重新对一次栏位,搭建的动作就要重来一遍。如果一年里做过两三次调整,搭建成本就不能只按一次算。
学习成本在小团队里占比可能更高。人少的时候,一个人要同时负责判断、整理和操作,学习新流程的时间只能从其他工作里挤。这部分挤压的痛感比大团队更明显,虽然实际耗时的总数可能更短。
机会成本的一个具体参照是选品。被占用的那段时间如果不花在维护和纠错上,最可能拿去看款或者谈供应链。这两件事任何一个做深一点,带来的差别往往比把操作流程调顺更大。这个对照能帮人判断优先级。
把这几块按季度记一次,比按年记一次有用。月度波动大,容易被某一次集中调整带偏;季度能看到趋势,又不至于太粗。记的内容不需要多,六块各自一个量级就够,关键是同一套口径连续记几期。

账单上看得见的那一块,比重通常不是最大的那一块
维护成本怎么估
维护包含的动作其实很具体。栏位名改了一次要跟着调、类目结构变了要重新对、检查规则发现漏项要补、模板文件更新了要重新试跑。这几类动作都能归到维护里,也都能被数出来。
维护成本高的原因在于它打断其他工作。一次调整可能只花半天,但这半天是从别的安排里挪出来的。挪动的代价在于被中断的那件事要重新进入状态,而重新进入状态的时间常常不被计入维护账上。
维护频率和类目数量有关。只做一个类目的店铺,规则变化少,维护动作也稀。做四五个类目的店铺,每一类都可能有自己的属性要求,维护次数通常和类目数量一起往上走,很少只增加一两成。
维护成本和铺货量关系不大。这一点和纠错成本不同,纠错随条数上升,维护更多和变化频率挂钩。所以规模大时纠错是主要压力,变化频繁时维护是主要压力,这两股压力要分开看,处理办法也不一样。
容易被忽略的是维护里的隐性部分。每次调整之后要重新验证一遍,确认改动没有引起新的问题。这一步本身耗时不多,但省略掉的话,问题会在下一批铺货的时候集中冒出来,那时的处理代价要高得多。
维护记录的价值在于积累。记下每一次为什么改、改了什么、大概花了多久。半年之后回头翻,会发现改动集中在某两三类规则上。这说明那几类规则本身就不稳定,值得单独拿出来重新设计一次。
维护成本很难压到零。只要平台规则在变、店铺做法在调,维护就会持续发生。合理的目标是把维护从被动应付改成定期安排,让它变得可以被预期,而不是随时插进来打乱原有的节奏。
维护有一个容易被误解的地方,就是它看起来是技术活,其实大部分是确认活。改完之后要确认改动生效、确认没有影响其他栏位、确认新批次跑出来的结果是正常的。这些确认动作占了维护时间里的多数。
维护的时间最好固定安排。把它的时点排进每周的固定位置,比如每周固定半天处理调整。排进日程之后,它不再随时打断别的安排,也不容易被无限期推迟。推迟的后果是问题积累到一次爆发。
维护记录里最有用的不是花了多久,而是为什么改。写下触发这次调整的具体现象,比如某类目新增了必填属性、某批次的标题被驳回。半年之后这些记录能直接回答一个问题:变化主要集中在哪几处。
维护成本可以按类目分开记。做多个类目的店铺,把每次调整归到具体类目名下,几个季度之后能看出哪一类最不稳定。不稳定的那一类要么是属性规则复杂,要么是你在这一类上的经验还不够,两种情况都值得单独安排时间。
维护里有一类动作是可以避免的,就是同一个调整因为没记清楚而做了第二遍。这类重复多发生在换人或隔了很久之后。把每次调整写进同一份记录并标上日期,重复动作的比例通常会降下来。
| 成本块 | 发生时机 | 估算口径 | 怎么记录 | |||||
|---|---|---|---|---|---|---|---|---|
| 订 | 阅 | 费 | ||||||
| 按 | 周 | 期 | 固 | 定 | 发 | 生 | ||
| 周 | 期 | 费 | 用 | 乘 | 使 | 用 | 周 | 期 |
| 账 | 单 | 直 | 接 | 取 | 数 |
纠错成本怎么估
纠错成本的估算有一个关键前提,就是先有返工记录。没有记录的时候,人只能凭印象,而印象里记住的通常是最近那几次,不是总量。所以估这块的第一步不是算,而是先把返工的条数记下来。
记法可以简单到一行。这一批铺了多少条,事后发现要改的有多少条,分别是哪一类问题。三类信息记够,返工比例就能算出来。比例比单纯的条数更有意义,因为它可以和不同批次比较。
返工单条的耗时差别很大。改一个字段可能就是几十秒,落错类目要重新走一遍归类,图片有问题可能要重新做一张图。估算时按问题类型分别给一个平均时长,比给一个统一值更贴近实际。
纠错成本还有一个放大效应容易被忽略。铺出去之后改动,改动本身会影响链接已经积累的表现。改得越频繁,链接的状态越不稳定。这部分损失很难直接算钱,但它是真实发生的。
按批次估比按总量估好用。同一批铺出去的商品,往往是用同一套规则生成的。如果这一批里返工比例偏高,说明这套规则有问题,改动它比逐条修更值得。按批次估能直接指向问题所在。
纠错成本在早期会显得很高。刚上手的时候规则还不成熟,返工比例偏高是正常的。规则慢慢补齐之后,比例会逐渐下去。判断的重点不是比例高不高,而是它在几个批次之间有没有在往下走。
一类特殊情况是纠错找不到根因。同一条链接改了三次还在出问题,说明问题不在这一条链接上,而在生成它的那条规则里。遇到这种情况要停下来查规则,继续逐条修只会把成本一直堆在同一处。
纠错里有一部分成本来自沟通。发现问题的和负责改的如果不是同一个人,中间要说清是哪一条、哪个字段、改成什么。这些沟通时间分散,容易被忽略,但它实际上是纠错成本的一部分。
纠错的顺序值得排一排。同一批里要改的条目,先改影响面大的,比如类目和价格,再改影响面小的,比如描述里的一个词。顺序排对能减少重复劳动,因为前一处改了可能影响后一处的判断。
纠错之后要能验证。改完不能只看这一条对不对,还要看它有没有把别的地方带歪。验证方式可以简单,对照几个必查项过一遍即可。省掉验证这一步,问题会在下一批以另一种形式再出现一次。
纠错的成本还和整改的时机有关。刚铺出去就发现,改动影响小;铺了一两周才回头改,链接已经积累了一点表现,改动带来的波动更明显。分批铺并且在每批之后留出检查时间,本质上就是在把纠错时机提前。
什么情况下不划算
判断不划算不看总金额,看边际。新增一批铺货带来的收益,和新增的维护加纠错成本比。如果后者上升得更快,说明已经过了合适的量级。这个判断不需要精确数字,看两个量的走向就够。
返工比例上升是其中最直接的一个信号。同样一套做法,上一批返工的占比是多少,这一批又是多少。比例持续走高,说明现有的规则覆盖不住当前的商品结构,继续往上加量只会把问题一起放大。
维护动作变密是第二个信号。原来一个月调一两次,现在一周要调两三次。频率上去说明场景变复杂了,规则来不及跟上。这时候继续增加铺货量,等于在规则还没稳的地方猛踩油门。
第三个信号是人工时间被挤占。判断环节本来是每天最优先的事,现在常常因为处理维护和返工被推到晚上。判断被挤压之后,铺出去的东西质量又会下降,返工又增加,形成往上转的循环。
还有一种是量小但成本高的情况。铺货量本来就不大,维护和纠错却占掉了不少时间。这种通常是做法太重,用一套复杂的规则去处理一个很小的量。这时候简化做法比继续优化更合适。
不划算不等于要换工具。多数情况下把量收一收、把规则补一补就能缓解。更换工具会引入新的搭建成本和学习成本,如果问题的根源在量级和规则上,换完之后同样的问题还会再出现一次。
判断要不要调整,有个可操作的做法:把这一段的成本按六块记三个月,看哪一块在涨。涨得最快的那一块决定先动哪里。没有这份记录,讨论很容易停留在感觉上,谁也说服不了谁。
量小的时候,很多人会觉得软件不划算,于是回头做手工。这个判断要看清楚是哪一块不划算。如果是订阅费在小的量上占比太高,那是量级问题;如果是维护和纠错占得太多,那是规则问题,换回手工一样会遇上。
还有一类情况是量不小但品种特别杂。每个类目都有自己的属性要求,规则很难统一,维护频率会一直居高不下。这种情况下合理的做法是按类目分批处理,而不是继续用一套规则去覆盖全部。
旺季和淡季的成本结构不一样。旺季量上来,纠错成本的总量放大得更快;淡季量下去,维护这类固定投入的占比变高。分开看这两个时期的数字,比看全年平均更能反映真实情况。
不划算这个判断要留出观察期。刚换做法或者刚上量的头一两批,数字通常不太好看,因为还在磨合。用这段时间的数字下结论容易误判,一般跑过三批之后再看趋势,得出的结论才站得住。
还有一种是看起来不划算实际划算的情况。返工比例在上升,但单条链接的收益也在上升,两者抵消之后整体还是正的。这时候需要看的是两者相抵之后的净结果,而不是只盯住返工这一个数字。

可预见的那两块好算,随规模上升的那几块才是真正吃钱的地方
成本怎么摊到每篇上架
摊算的公式很朴素:这段时间六块成本的总和,除以这段时间铺出的条目数。得出的是平均每条链接上分摊到的成本。这个数不追求精确,它的用处是让不同量级下的做法变得可以互相比较。
摊算的分母要用实际铺出去并且还保留着的条数。铺出去之后又被下架的那些,不该计入分母,但它们产生的成本仍要计入分子。不这样处理的话,会得出一个偏低的单条成本,看上去好像特别划算。
分子里能算钱的部分直接算。订阅费取账单,其他几块按时间成本折算。折算用的时薪不必精确,用一个店铺自己认可的量级即可。关键是六块用同一套折算标准,这样比较才有意义。
摊算的结果要和单条链接带来的收益对照。单条收益可以用这个类目里一条普通链接某个周期的大致贡献作为参照。两者比较不是为了算出一个精确的投入产出比,而是看有没有量级上的失衡。
量级变化时这个数会明显变动。铺一百条的时候单条成本可能偏高,因为搭建和学习被摊在了很小的量上。铺到一千条,这两块被摊薄,但纠错可能开始抬头。找到单条成本相对低的那个区间,就是合适的量级。
摊算还有一个用法是比较两种做法。同一段时间、同样的量,一套全靠人工、一套软件加人工,各自把六块列出来摊到单条,结果往往出人意料。有的环节软件省下的时间,被维护和纠错又吃回去一部分。
这个数不要每月算。变了量级、换了做法、或者成本结构明显有变的时候算一次就够。频繁算会让它变成一种形式,反而分散注意力。它的价值在于偶尔做一次校准,而不是日常盯着。
摊算会暴露一个常被忽略的事实,就是早期的单条成本总是偏高的。刚启用的一段时间里,搭建和学习都摊在很小的量上,看起来很不划算。如果只在这个阶段看数字,很容易得出错误的结论。
摊算也不必只看平均数,可以看分布。同样铺一百条,其中返工的那些条单条成本高出很多。把返工的条单独看,就知道成本主要花在哪一部分商品上,也就能判断这一类商品是不是值得继续铺。
摊算的另一个用处是设定预警。给自己定一个单条成本的参照线,某个月算出来明显高出这条线,就去查是哪一块涨了。有了这条线,不需要每天都算,只在异常的时候看一次就够。
摊算的时候有一个细节要处理,就是同期发生的其他工作的影响。如果这段时间同时在谈供应链、同时在调整定价,那么被占用时间的一部分其实也要归到那些事上。分摊时按大致比例切一刀,比全部归到上架这一块更接近实际。
摊算的结果适合当成一个内部参照,不适合拿出去横向比较。不同店铺的成本口径不同,时薪标准不同,铺货结构也不同,跨店比出来的数字没有意义。它的作用是自己和自己比,看这一期和上一期的变化。

有上限的就是那笔订阅费,没有上限的是后面那几块
什么时候该换方式
换方式之前要先区分,问题在量级上还是在做法上。量级的问题表现为加了量之后各方面都紧张,减量就能缓解。做法的问题表现为量没变但返工一直高,减量也不见好转。两种情况动作完全不同。
量级问题的处理相对简单。把每批的条数收一收,把批与批之间的间隔拉长,让维护和整改有时间跟上。收量之后的直接效果是返工比例下降,单条成本回落,整体算下来反而比之前划算。
做法问题的处理要先定位。翻这段时间的返工记录,看问题集中在哪几类。多数情况下会集中在一到两类,比如类目归属或者属性缺项。把这两类的判断补上,返工比例会明显下来。
换工具放在最后考虑。更换会带来新的搭建成本和学习成本,这两块在最初一段时间会上升。如果原来的问题是规则没写好,换了之后新工具一样要面对同样的问题,等于把成本重付一遍。
有一类情况确实需要换,就是当前方式的上限已经顶到了。维护动作排不进日程、返工比例连续几个批次往上走、同时量还得继续往上加,这三条同时成立的时候,就不是优化能处理的了。
还有一类情况是方式本身太重。铺的量本来不大,却用了一套复杂的规则去支撑。这种时候要做的不是换一个更强的工具,而是换成更轻的做法,用一张表格加上少量检查就能覆盖住。
无论换不换,都要先留一份基线记录。现在的返工比例、维护频率、单条成本,各记一个数。不换的话用它对照优化效果,换的话用它对照新方式是否真的更省。没有基线,讨论就只能靠印象。
最后要接受一件事,就是任何一种方式都有它的合适区间。同一套做法在小量级上合适,在大量级上不一定合适,反过来也一样。定期看一眼自己处在哪个区间,比一次性选一个长期方案更实际。
换方式有个前提条件,就是当前方式的问题已经查清。没查清就换,等于把问题带过去。查清的标准是能说出问题是量级造成的还是规则造成的,以及换完之后这个原因会不会消失。
更换的过程本身也要算成本。切换期间两套做法可能并行一段时间,这段时间的工作量是叠加的。把这段过渡期算进去,很多更换在账面上就不再那么吸引人,这也正是它值得先算一算的原因。
换完之后要重新建一份基线。新方式跑过几批之后,重新记返工比例、维护频率和单条成本,和旧方式对照。对照不理想就说明没换对,这时候回头还有依据,而不是凭感觉再换一次。
换方式还有一个软性的条件,就是要有人愿意从头学一遍。换的收益要由具体的人去兑现,如果执行的人对新方式有抵触,效果往往出不来。把这件事提前沟通清楚,比事后解释更省事。
最后要看的是这段时间里判断和搬运两段的比例是否合理。如果时间几乎全被搬运和维护占满,判断只剩零头,那不管换不换工具,都要先把结构调回来。工具解决的是搬运效率,调整结构解决的是时间去哪了。