“一个商业软件的应用生命周期应该少于18个月”，是完全基于业务逻辑演化的频率而提出了，虽然在数字上类似于IT硬件上CPU更新的摩尔定律，但是在管理软件上为什么会是这样的一个周期？......发现在系统上线或者一个业务模式在事实上确定后，通常在第九个月进入震荡期，当然这个时间间隔在2000年之前通常为2年。所谓震荡就是业务逻辑与业务过程不够匹配，有太多的异常需要处理了。然后又进入一个相对的平稳期，但是这个时期经常有小幅度的调整，在过了一年之后到了大约第15个月的时候，一个更大规模的震荡又开始了。这个时候企业的运营系统一般都会捉襟见肘，通常会以升级的方式来平衡两者关系，事实上是打补丁，而补丁与之前的架构是没有血缘关系的，问题也就趋于严重。这个时候必须衍生出第二代的业务逻辑来，好似一些动物的蜕变，这个时候已经不是技术方面的问题。从技术构造成本来说，这个时候重新构造可能更合算。

    这个可以成为软件“摩尔定律”的初步认知，恰好与我所理解的这种冗余相呼应。上线的软件或者应用，在某种意义上成了新一轮业务流程重组的驱动器，而不是应用的终结，我们都主动的将它们应用于实践。对相对成熟的应用进行主动放弃，在新的业务逻辑中继承与发扬老业务过程中的战略，从而使得企业赢得一个蜕变与进化的比较从容的时间差。

    桥和路迭代互济前行
    我们非常清楚，信息系统的构造不是一劳永逸的，如何实现随需而变？上面的讨论已经基本明确了一个重要的指导原则，就是需要做好“桥”与“路”的衔接，同时确定“桥”是手段，“路”是目的，在手段上我们或许要投入几倍于目的的资源，这恰是虚实之策略。。

    一般来说只有上了第二级台阶，才可以上第三节台阶，虽然第三节台阶很好构造，也能迈上去，但是硬上，可能会带来“硬着陆”的痛苦，对事业有不利影响。

    回顾一下我们在一期项目中，引入了虚拟产品的概念，将之前完全个性化的通过订单的参数对产品进行描述，变更为在商务确认之前进行虚拟产品构造，商务关系建立之后，直接选取虚拟产品进行少量的参数设置后即可安排供应与生产计划。这是一个重大变革，为了有效保障项目实施效果，系统设计时，有意对虚拟产品的唯一性没有作出限制，这样可以满足没有经过严格规范的虚拟产品也能正常的下订单。这个设计就是“桥”的设计，它消耗的技术资源确实比正常的“路”要多。我们通过半年多的基础资料维护工作，将98%的虚拟产品都罗列进了系统，然后在这个基础上再去做“紧箍咒”的工作，一个客户有200多种虚拟产品，通常会压缩到40-80种。这个变革过程已经设计在系统里面了，这个过程在2009年的4、5月间将全面启动，那将是全面缔造一个新的业务过程的过程。

    前面提到，在“桥”的阶段，软件既是业务之应用，也是BPR的工具，这其实是作为“桥”的真正价值。通过软件自己来做BPR工作，系统本身具有BPR的功能。由于核心业务过程是基于同一流程展开的，这些局部甚至全局BPR的工作就比较简单，综合的实施成本必将显著降低。业务逻辑的延续性和业务过程进化的延续性将不是问题，组织变革的风险将得到有效控制，这恰是众多成长型企业所需要的。