仅靠直接损失会低估真实情况
合规审查、SLA 赔偿、客户流失和补救人力成本,很少会体现在简单的“营收 × 小时数”计算中——隐性税的存在,正是为了在不需要逐项单独建模的情况下代表这些成本。
分步演算
本网站每个页面背后,都是同样的四个步骤。
以本站自身的默认示例进行演算:850 套系统、每系统小时 180 美元的营收影响、3.5 小时的平均修复时间(MTTR)、每年 14 起事故,以及 99.9% 的 SLA 目标。
步骤 1 —— 年度停机小时数
MTTR × 事故发生频率 = 3.5 小时 × 14 起事故 = 每年 49 小时停机时间。这是在引入任何金额之前的原始风险敞口。
步骤 2 —— 直接损失
受影响系统数 × 每系统小时营收影响 × 年度停机小时数 = 850 × 180 美元 × 49 = 7,497,000 美元。这是财务团队会立即确认的成本——系统停机期间损失的营收或生产力。
步骤 3 —— SLA 预算与违约
每年 8,760 小时 ×(100% − SLA 目标)= 8,760 × 0.1% = 在 99.9% 目标下允许的 8.76 小时。年度停机小时数(49)减去该预算,剩下超出预算 40.24 小时——这一数值决定了下方隐性成本乘数会变得多严重。
步骤 4 —— 隐性停机税
这是按风险加权计算出的直接损失百分比,起始值为 18%,并随着 SLA 超支程度和事故发生频率的增加而上升,上限为直接损失的 72%。在本示例中,违约程度已严重到触及上限:7,497,000 美元 × 72% = 5,397,840 美元。
年度总成本
直接损失 + 隐性停机税 = 7,497,000 美元 + 5,397,840 美元 = 12,894,840 美元——这正是这组输入组合在计算器上今天得出的数字。
为何这样设计
隐性税不是凑数——它才是关键所在。
大多数停机计算器只算到直接损失为止。而本工具不会止步于此,因为在预算讨论中,真正能改变决策者想法的往往不是直接损失这个数字。
乘数会随您自身的具体风险而变化
一个 SLA 预算控制得当的团队,隐性税会接近 18% 的下限。而一个长期超支的团队,隐性税则会向 72% 的上限攀升——这正体现了风险是会复合累积的,而不是保持平稳不变。
每一项输入都可由您自行质疑和调整
受影响系统数、营收影响、MTTR、事故频率和 SLA 目标,在每个计算器页面上都可编辑——公式本身是固定且透明的,但输入数据应始终来自您自己的运营数据,而不是本页面用于示例说明的默认值。
常见问题
关于这套公式的解答。
当有人想要为这套模型的假设进行辩护或提出质疑时,常会问到以下问题。
为什么隐性税上限设定为 72%?
这个上限可以防止模型在极端输入下产生无限扩大的乘数——它代表了在这套公式内置的定性严重程度分级下,将间接成本归因于单一停机模式时,可信的上限水平。
为什么事故频率会影响隐性税,而不仅仅是直接成本?
频繁发生的事故会加剧组织疲劳,比孤立事件更快消磨客户耐心,并增加利益相关方审查将成本升级到超出直接停机范围之外的可能性——这被计入一个独立于 SLA 违约压力之外的、适度的附加压力项。
我能否通过在纸面上提高 SLA 目标来降低隐性税?
不能——SLA 预算是根据您的目标推导出来的,并会与您实际的停机小时数进行比较。在不降低 MTTR 或事故频率的情况下提高目标,只会增加您的违约程度,而不会减少。关于这一确切情形的完整演算示例,请参阅情景规划。
本站所有计算器使用的都是同一套公式吗?
是的——本站每一个成本细分页面、行业页面以及通用计算器,运行的都是完全相同的公式;只有默认输入值会根据各自的场景有所不同。
轮到您了