使用 SAP ERP 的冷门现状 | AI生成和翻译
这些观点是 SAP consultants、vendors 甚至许多 IT 部门不会公开讨论的，但它们反映了使用 SAP systems 的公司真实经历：
“SAP Often Creates More Problems Than It Solves”
许多实施最终增加了复杂性，而不是简化了运营。公司用一个需要专业知识才能运行的极其复杂的 platform 取代了相对简单的 legacy systems。在旧系统中只需几分钟就能完成的简单任务，在 SAP 中可能需要通过多个屏幕和 transaction codes。集成（Integration）的承诺有时仅仅意味着问题会波传到更多部门，而不是被控制在局部。
“You’re Locked Into an Expensive Ecosystem Forever”
一旦你实施了 SAP，切换到另一个系统的成本和风险就会变得高不可攀。你已经培训了数百或数千名员工，定制了 processes，集成了其他系统，并围绕 SAP 建立了 institutional knowledge。这种 vendor lock-in 意味着 SAP 基本上可以主导定价和条款。切换成本如此之高，以至于即便公司对产品不满，也会接受许多人认为过高的 maintenance fees。
“Most Companies Use Less Than 30% of What They Paid For”
组织购买了拥有数十个 modules 和数千项功能的全面 ERP systems，但最终只使用了其中一小部分 functionality。公司为复杂的 production planning 算法买单，却因为 Excel 更“容易”而继续使用 spreadsheets。他们购买了 advanced analytics 功能的 license，但由于学习曲线太陡峭而闲置。SAP 理论上能做到的与组织实际用途之间的差距是巨大的。
“SAP Implementations Fail More Often Than Anyone Admits”
官方叙事侧重于成功案例，但许多实施在经历过它们的组织内部被悄悄视为失败。项目严重超预算、耗时长于预期、被迫做出削弱业务目标的妥协、或在中途被部分放弃。即使是“成功”的实施，往往也只意味着系统在技术上可行，但用户满意度很低，预期的 benefits 从未实现。由于尴尬和不想承认资产减值（write-off），公司很少公开这些失败。
“The System Is Built for Accountants, Not for People Who Actually Do the Work”
SAP 的设计理念是将财务控制和 audit trails 置于一线员工的可操作性（usability）之上。与现代 consumer applications 相比，制造运营商、仓库管理人员和客户服务代表通常觉得 SAP 界面笨重且不符合直觉。系统强制执行与实际工作方式不匹配的死板 workflows，导致了 workarounds、shadow systems 和用户的挫败感。这款 enterprise software 感觉像是 90 年代设计的，因为从根本上说，它确实是。
“Consultants Have Perverse Incentives”
SAP consulting 利润极其丰厚，而 consultants 往往从复杂性而非简单性中获益。实施时间越长，billable hours 就越多。需要的 customization 越多，就越需要专业化的 expertise。一些 consultants 推荐的解决方案是为了确保客户产生持续依赖，而不是赋能客户的内部团队。整个咨询生态系统建立在 SAP 难以使用的基础上，这与客户利益（拥有一个易于管理的系统）并不一致。
“SAP Sells Based on Fear, Not Value”
许多公司选择 SAP 不是因为确信它是最佳解决方案，而是因为“没有人因为购买 SAP 而被炒鱿鱼”。当项目出错时，这是一个安全、可辩护的选择。大型组织购买 SAP 是因为竞争对手在使用它，分析师推荐它，而高管们不想成为那个选择了不同方案却导致失败的人。这种基于恐惧的决策导致了从一开始组织承诺（organizational commitment）就很薄弱的实施。
“Cloud Migration Is More About SAP’s Business Model Than Customer Benefit”
SAP 积极推动 S/4HANA Cloud 是源于他们对可预测的 recurring revenue 的渴望，而不一定是出于客户的最佳利益。许多拥有稳定、运行良好的 ECC systems 的公司正被迫按照符合 SAP 财务目标的时间表进行迁移。Cloud model 让 SAP 拥有更多控制权，使切换更难，并将 perpetual licenses 转化为持续的 subscription costs。对于许多组织来说，留在 on-premise 会更经济，但 SAP 正在使这条路径变得越来越没有吸引力。
“The Real Cost Is 3-5X the Initial Quote”
初始的 license 成本仅仅是个开始。实施服务的费用往往超过软件成本。随之而来的是持续的 maintenance（通常每年占 license 费用的 17-22%）、infrastructure、内部人员配备、培训、升级，以及在过渡和学习期间生产力下降的隐藏成本。一个报价 1000 万美元的项目，在五年内往往最终耗资 3000 万至 5000 万美元。这些真实的 total costs of ownership 很少会在前期被诚实地计算。
“SAP Benefits Large Corporations at the Expense of Smaller Suppliers”
企业级 SAP 实施往往将集成要求推给那些自身负担不起 SAP systems 的小型供应商和合作伙伴。他们被迫适应大公司由 SAP 驱动的 processes，有时甚至需要购买额外的软件或聘请 consultants，仅仅为了能与使用 SAP 的客户做生意。这在 supply chains 中造成了权力失衡，ERP system 成了企业支配的工具。
“Upgrades and Updates Are Nightmares”
与可以无缝更新的 consumer software 不同，SAP upgrades 是需要进行大量测试、customization 重做和培训的大型项目。公司往往会推迟升级多年，因为中断和成本非常巨大。这意味着他们在过时的版本上运行，缺少 security patches 和新功能，造成了随时间累积的 technical debt。持续改进的承诺变成了周期性动荡的现实。
“Best Practices Are Often Mediocre Practices”
SAP 宣传其标准 processes 中内置了“行业最佳实践（industry best practices）”，但这些通常是为了适用于许多公司而设计的妥协方案，而不是针对任何特定组织的最优方案。公司放弃了嵌入在其独特 processes 中的竞争优势，去顺应 SAP “一刀切”的方法。对于一家通用公司来说的“最佳实践”，对于你的具体情况来说可能显然不是最优的。
“The Skills Gap Creates Dependency”
SAP 需要如此专业的知识，以至于组织变得依赖于少数内部专家或外部 consultants。当关键人员离开时，institutional knowledge 也随之流失。复杂性意味着你无法轻易地进行 cross-train 或聘请通用的 IT 员工。当这些专家意识到自己无可替代时，就会产生风险和谈判筹码的问题。
“Integration Promises vs. Integration Reality”
虽然 SAP 吹嘘无缝集成，但将 SAP 连接到其他系统通常需要昂贵的 middleware、custom development 和持续维护。现实世界的 IT 领域包含数十个需要与 SAP 通信的应用，而让这些连接可靠地运行是一个永无止境的问题来源。数据同步问题、失败的 interfaces 和 integration bugs 消耗了巨大的 IT 资源。
Why These Ideas Are Unpopular
这些观点很少被公开表达，是因为多个利益群体都受益于维持这种积极的叙事。SAP 显然想卖出更多 licenses。Consultants 从实施和支持中获利。促成 SAP 的高管不想承认错误。花费多年时间实施它的 IT 部门需要证明这些投资的合理性。围绕 SAP 专业知识建立职业生涯的员工有动力强调其重要性。
尽管如此，每天仍有数百万人成功地使用 SAP systems 来运行业务，对于许多大型、复杂的组织来说，尽管存在这些缺点，SAP 仍然是一个理性的选择。问题不在于这些批评是否属实（许多在不同程度上是属实的），而在于对于你的具体情况，收益是否仍然大于成本。
冷门的事实是，像 SAP 这样的 ERP systems 代表了巨大的妥协。对于大型组织来说，它们往往是必要的妥协，但终究是妥协——在灵活性与控制力之间、在易用性与功能性之间、在创新与稳定性之间。诚实地承认这些权衡将有助于做出更好的决策并建立更现实的预期。