信息系统之造桥与修路(关于迭代、BPR以及其他)    

    一位经常往来于杭州与温州之间的朋友说，“坐在车上，不用看交通标识牌，也不用计算时间，只要留意一下上桥与下桥的感觉，就知道是不是已经到温州境内了”。为什么呢？他说，“温州桥和路之间总有2-3厘米的落差，发现有频繁的颠簸，就可以断定到温州了”。他说的是实话，不过，如果我们认为这是造桥和筑路的单位工作衔接方面没有到位所形成的，那实在是冤枉了。究其根本是温州的地质条件决定的，这是典型的丘陵地区，看上去平的地方其实早先是滩涂湿地，路基很软。造桥的时候都会打桩，筑路一般不用打桩，新的公路修好之后，原本路桥之间没有落差的，时间长了，受原始规律支配，自然也就有了落差。但就工程而言，据说现在就是筑路，也开始考虑打桩了，显然这个代价是相当大的，多说一句，即便有落差了，用几包水泥做“补丁”，或许能弥补这样的落差，有人这样建议过，后来没有什么结果，这是另外一个面上的问题了。

 

由于桥和路的原始地基是不一样的，我们本来希望它们能够统一成平坦路途，但是最终的结果往往还是决定于原始的地基。这个情形引起了我对信息系统的一些思考，在信息系统中，就许多应用而言，也存在着路和桥一样的情况，所不同的是，它有鲜明的时间与空间的关系，同时，系统中的“路”和“桥”还有互相转化的可能。在最近几年的实际工作中，我对此体会深刻。

 

 

   民间版的路桥哲学

通常情况下，修路的成本要比修桥的成本低，现在越来越多的亦桥亦路的高架桥啊、立交桥啊另当别论。我们默认的是，路在陆地，桥则在水面之上。对于路的追求我们自然是希望保持平坦顺畅，而桥，单就交通的需要来看，我们是希望它尽量地少。局限于许多条件，很多时候不得不要修桥，修了桥之后，一方面我们会习惯的将桥当作路，比如数十公里长的杭州湾大桥，常常是默认它为海上之路的，另外一个方面，有往往希望它能被新的路替代了，历史变迁所留下的许多带桥字样的地名已经帮我们说明了这一点。

在信息系统中造桥往往是为了筑路，而道路拓宽之类又常常以造桥的方式来进行。这或许是我比较局限的个人项目体验，但是似乎存在着一定的普遍道理。

 

2007年，我们在为公司的供应链管理项目进行业务建模的时候，就包装物的产品化做了许多探索。图中所显示的三个阶段，分别处于2008年以前、2008-2009、2010之后。就技术条件来说，业务建模的核心工作--产品结构设计是完全可以做到网络产品化阶段的，也就是说，可以直接做成通过很少的产品属性，但是可以很精确地表达出产品在各个工序（知识生产性质的工序与物质生产性质的工序都包含）的模式。这样做起来技术负担不大，但是我们采取了“造桥”的方式，增加了技术负担，由于产品为系统的核心基础资料，它的变更将引起整体构架上的变更，项目风险显著增大，之所以如此决策，主要是考虑到业务发展的进程需要一个艰辛的语言统一过程。信息化在业务进化的不同阶段发挥不同的作用，在个别产品化阶段，就是工具，在普通产品化阶段，它其实是BPR的载体，是促进规范的一个过程，而在网络产品化阶段则是一个完全蝶化的过程，是引领业务变革的巨大引擎。

项目在2008年10月13日全部上线之后，直到2009年底2010年初这个时间里面，信息系统所起的作用与其说是业务财务一体化的多功能发力于企业管理，还不如说是为下一代的系统做测试，做demo，做基础资料。事实上从上线到2009年3月份，客户的产品已经丰富到一个惊人的数量级，这是一个结构化的将隐性的行业规则呈现的过程，信息化如果只停留在这个层面上谋求对业务的支撑，显然是相当短视的，虽然，相比以前，已经为业务带来一个崭新的改善。

 

 

 

 

                   图一：“路桥哲学”在系统迭代中的实例

 

 

当然我们不会满足于此，就这个行业的发展趋势来说，必须做到产品网络化的程度,唯有到此境地，才能实现全局急速而又稳健扩张的战略意图。

这个看上去显得很冗余的过程，其实是一个基于新业务逻辑的“中介核”-产品内在规律的认识过程。我们苏北有一句俗语叫做“两场芝麻一场打”，这个过程既满足了眼下管理升级与业务持续发展的需要，也为未来的战略实现铺了底。消耗了比较多的技术资源，目的却不是希望这个模块长期的用下去，不是被动的，而是主动的安排，这样的安排有可能为未来带来比较大的战略纵深。

 

 深圳时代华信科技有限公司CEO万小青在2009年第二期的《软件世界》上有一篇文章《需求持续演化，技术实现如何如影相随》，我对其中的一段文字感同身受！

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

 

 

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

 

 

 

 

桥和路迭代互济前行

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

   

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

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

 

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

本文转自    王甲佳   51CTO博客，原文链接:http://blog.51cto.com/secajia/416401