反模式:非欧几里德恐惧


首页 » 知识库 » 此处
作者:Joannes Vermorel,2015 年 6 月

公司 IT 系统的纵深之处涌现出非欧几里德恐惧。凝视非欧几里德恐惧太久可能会导致永久失智。

类别:组织



问题:多年以来,这家公司建立了各种各样的系统。他们现在拥有 ERP、WMS(仓库管理系统)、CRM(客户关系管理)、 BI cube(商业智能)、电子商务平台等等。在实施所有这些系统时,还开发了内部组件,用于执行更专门的任务。随着时间的推移,IT 环境的复杂性锐增,因为每个新增的应用都需要与公司已实施的其他应用进行通信。每个部门都受到影响,但介于销售、采购、财务和生产之间的供应链所受影响最大。改变甚是缓慢,且几乎所有供应链计划都未能达到截止期限要求。没有人真正了解公司系统内部所发生的情况。

轶事证据:从一个仓库实地搬迁到附近另一个仓库可以在两周内完成。不过就软件而言,进行实际的 IT 迁移来整合新仓库需要6个月多的时间。

背景:早在很久以前,公司里的各个部门就开始使用自己的软件解决方案。由于整合欠佳,最后决定建立 ERP 系统来“统御一切”。尽管 ERP 系统得到了实施,但却无法跟上软件行业的快速变化。在供应链方面,则开发了 WMS(仓库管理系统)来提高生产力和可靠性;此举的效果相对而言较好。其他部门也做出了类似的举动,纷纷开发自己特定于领域的应用,此类应用比原始 ERP 更合适。不过,业务的变化速度前所未有的快,而今天,拥有更智能的供应链业务涉及到所有这些不同应用之间的无数互动。

提出的解决方案:每当出现新的挑战时,IT 系统便会调整到最低限度,来提供预期的结果。针对供应链用途,已经建立了与 CRM 的临时整合,来收集销售团队的意见,同时也与 BI tube 建立了另外一种特别集成,因为它是确保这些数据与财务使用的数据相一致的唯一途径。物流服务和供应商也需要进行自身的很多整合。因此,供应链团队学到了一点:IT 改变越大,相应计划就越是可能超出预算范围并且无法满足截止期限要求。因此,狭隘的渐进式改变现在比任何实质性演变都更受青睐。

得出的背景:与企业中各种 IT 交互的表示相比,东京地铁图看起来就简单多了。公司内部所有系统之间存在数百种错综复杂的依赖关系。IT环境的大局充其量也不过是极其模糊的。对于供应链,一直在不断努力获取所有相关信息,例如新产品、促销、“几乎”已成定居的采购订单、库存水平和缺货的历史记录等。对供应链运营的每次小幅修订(即通过利用额外信息来实施改进的过程)似乎永远在延续。数据输入不一致,系统不断失败,并且还存在异常,需要进行全面的手动管理。

诱惑力:公司已经明白了一点:IT 计划的规模越大,计划越是可能失败。因此,所有做法都逐渐朝规模更小、更集中的计划演变,此类计划既能管控预算和期限,又更容易推出。该公司正是通过这些小规模的计划实现了早期成功,只花费较小的预算便取得了积极成果。

为何导致失败:每次的渐进式改变都会推高所有进一步改变的成本和复杂度。由于该公司更青睐尽可能小的渐进式改变,所以一直欠缺对“大局”的关注。在某种程度上,就发生了“公地悲剧”,即个别利益(公司的不同部门)不符合公司整体利益。由于在发生改变后的很长一段时间方可看到负面效应,使得这个问题进一步加剧。虽然每次改变似乎都有利可图,但公司的“技术债”越积越多,随着时间的推移,短期利润随即转变为亏损。

解决问题的积极方式:从根本上说,实施渐进式改变是一种合理的方式。不过,每次改变的实施方式,应当确保后续的每次改变要变得更便宜或更简单;这两项特点实际上高度相关。这意味着每个计划都需要缴纳_公共税_,即不仅这个计划的主要目标必须得到实现,其次要目标(包括让接下来的改变更顺利地进行)也要实现。



示例:Contoso 是德国国内特定 B2C 领域的电子商务领导企业。该公司在二十一世纪初开始运营,当时在开发定制前端;所谓前端,即供人们在线购物的“应用”。该公司在早期时,几乎所有的 IT 需求都是通过不断增长的前端来解决。然而,管理供应商和采购订单对于这种定制应用而言太过了。因此,Contoso 决定投入中型市场 ERP,并将所有后台流程分流到这个 ERP 系统,其中包括大部分初生供应链做法。尽管库存水平在前端和 ERP 内部都暂时得到了管控,但经过证实,由于这很杂乱,所以 Contoso 最终设法从前端成功剥离了延伸得过长的责任。

ERP 虽然一开始发挥了它的功用,但随着公司的不断发展,尽管负责 ERP 开发的技术团队不遗余力,但 ERP 并未跟上该企业的所有要求。鉴于报告不充分,财务部门决定建立自己的 BI(商业智能)门户,而其他大多数部门也纷纷推出了类似的应用。供应链则推出了一系列 EDI 整合,来将采购订单发送给供应商,但将所有信息注入 ERP 却越来越令人沮丧,因为 ERP 可能无法捕捉到 Contoso 供应链运营的所有细枝末节。

随着 Contoso 成为国内领头羊,如今已经可以取用广泛的采购方案。在 Contoso 的早期成功中,起初发挥关键作用的当地德国经销商,现在则证实为越来越昂贵,而 Contoso 的竞争对手却在降低价格。客户愿意为在线购物“额外”支付的时代已经一去不复返。因此,Contoso 不得不逐渐将替代性的采购方案整合到其工作流中,通常选用更远距离的服务,有时甚至选择海外供应商的服务。经过几个月试图将多源逻辑融入 ERP 但却以失败告终的工作之后,供应链团队决定是时候创建自己的系统,从 ERP 中分离出去了。供应链团队选择采用先进的采购应用,但设置过程比预期的要长得多。新的解决方案没有毛病,但是与 ERP 的整合导致了一系列意想不到的难题。例如,在推出新解决方案三个月后,供应链团队意识到客户网站上显示的运输延误不是由 ERP 管理,而是由前端管理。因此,这些“显示的运输延误”在从前端流向 ERP,但却没有任何举措来提供逆向支持。因此,将修订后的运输延误(动态更新,根据供应商选择来提供产品)注入 ERP 不会对网站上显示的数字产生任何影响。 ERP 经过发展,已经变得相当复杂,由于 Contoso 的IT团队对内部开发的前端感到更加自如,因此供应链和 IT 团队共同决定采购解决方案将修订后的运输延误直接注入前端。

事实证明,这种方法稍显凌乱,原计划在 3 个月内部署该采购应用,但却花了整整 9 个月才“上线”。不过,这是一项很值得的投资,因为多种采购渠道实现了平均采购价格下降 15%,公司由此取得了长足的发展。