作者：Infosys制造业事业部 高级技术架构师 Michael Aston
我常常遇到这样的项目，其范围被限定于为现有的系统制造一个替代品。如今我想说的是，这些项目注定要失败。
出现这些项目的原因有很多。也许是企业无法支持现有产品，或者是企业试图将资源整合到更少的技术平台之上。有时是为了减少经常性成本，而有时则因为新技术的诱惑让人无法抵抗。无论诱发的因素是什么，它们对成功的阻碍是相同的。
首先，在这些项目中，用户并没有抱怨现有的系统。现有的系统就像一个老朋友，用户了解它的一切优点和缺点，而且使用起来得心应手。如果不把它视作技术的话，它就如同你最喜欢的扶手椅一样，也许有点破旧，坐垫也不怎么搭，但是有谁说要把它换掉的话，这个人就要倒霉了。
其次，现有的系统还是可以继续使用一段时间的。任何事物，只要存在的时间足够长，人们可以适应它的一切，因此替代品似乎就无用武之地了 [1]。就已建立的软件而言，业务流程会进行自我调整，以适应可用的工具，幷包容它们怪异的特性。
那这为什么又会带来灾难呢？因为，一方面，采用一个新的系统，必须要花费几个月的时间来为企业的这一改变做准备，对人员进行重新培训，制定过渡规划，实施系统锁定，并解决新系统发布后的初期问题，而另一方面，最后的结果并不见得要比现有的系统能好到哪去。
实话是实说吧，你甚至无需去更换现有系统。用户的业务流程及其需求，是依据现有系统的方法和特性而专门设计的。用户依据旧系统的局限性调整自己的方法如今已成为其业务流程的内在组成部分。由于用户习惯了旧系统的功能，因此具备旧系统的所有功能成为了用户对于新系统的硬性要求。唯一可以完全满足用户需求的系统就是当前他们正在使用的系统。
那么应该怎么办？回归根本，质疑各种假设，并不断地问“为什么？”。
“为什么要以这样的方式工作？”，“你想实现的是什么？”，“最根本的业务需求是什么？”
不要仅停留于此，而是要更加深入地挖掘：“如果这样做，会有什么后果？”，“如果不这样做，是否依然能实现业务目标？”。你需要一层层剥开现有流程的面纱，找到其原本的需求，也就是那些因长期适应现有系统而被掩盖住的需求。一旦你发现这些需求，你最终将超出客户的期望，提供比现有系统更好的系统。
这种思维模式可以应用于“替代品式”项目以外的其他方面。项目利益相关者会对某个需求的“内容”和“方式”产生混淆，这并不稀奇。你往往会被告知某个解决方案该如何工作，而不是这个解决方案应达到什么样的目标。每一个系统集成商都需要记住的是，客户并不总是正确的。在使用软件来解决业务问题方面，集成商才是专家。
每个系统和每个产品，自身都具有内在的方法来应对在其使用领域中常见的业务挑战。从长远来看，根据技术平台来调整业务流程可以增加成功实施的可能性，因为这样可以鼓励企业采用已经过产品厂商和客户群试用和测试的最佳实践。推行这种方法将不可避免地会遇到反对改变的阻力，因为一般情况下，人们都会认为当前的工作方式是正确的。
[1] 比如 QUERTY 键盘原本的目的是用来减慢打字速度（防止原始打字机上的字母的联动杆被卡住），但其现在仍然是所有英语国家实际上所采用的标准。