重温ERP的生产计划部分,通常把生产流程划分为连续型生产、重复性生产、基于库存的生产、基于订单的装配和基于订单的设计,尽管不是很严格的定义,却也不失为一种好的归类。
联想起管理软件的生产问题,较之IT技术的飞速发展,其生产率并没有显著的提升。企业对信息化的渴求与管理软件实施与服务成本的居高不下,是目前这个市场最为突出的矛盾。也许也可以对管理软件的生产问题先归归类,以便更好地分析问题的症结所在。
一、标准产品模式
搞一个产品到处买,是最为理想的方式。数据库、Office等软件就是这样成就了Oracle、Microsoft。在企业应用领域,CAD、办公OA等也可以在一定程度上做到标准化。但最突出的是财务软件,用友、金蝶已成为一个经典范例。
当然,管理领域是如此复杂,差异化是如此丰富,这种标准产品模式已经是可遇不可求了。
二、完全项目模式
国内很多中小软件公司都是靠这种方式生存的。没有什么产品积累,搞一大帮开发人员,从零开始为用户定制开发企业应用。对用户而言,这个可是最彻底的量体裁衣。
但这并非说明用户的业务就真的这么特殊,软件开发商也并非自觉地地专注于一个细分的市场。就国内而言,这种情况是管理软件的起步阶段,低水平建设的标志。实际上,考虑到IT人员的高流动频率,此类软件开发商大多处于低水平重复的恶性循环,也不大可能为客户提供高质量的产品和服务。
以上二种方式实际上是二个极端,一个完全标准化,一个完全定制化。在管理软件市场的起步阶段,这二种方式占据主流的位置。随着市场的逐步成熟,这二种方式也逐步被边缘化了。预计今后只有在特定的细分市场,这二种方式才会被继续采用。
三、二次开发模式
一个完全项目模式的开发商,在多个案例中可以归纳出项目的许多共性,于是一种产品原型便提炼了出来。在这个基础上,再给客户作定制开发,开发效率无疑会大幅提升。这种二次开发模式于是便成为管理软件的主流开发模式。
过去搞标准产品的开发商,如用友、金蝶,在向ERP进军的过程中,也纷纷采用这种通用模式。往往是先通过完全项目模式搞点积累,然后采用二次开发模式迅速打开市场。
四、参数配置模式
如果每个客户项目都需要派大批软件工程师进行二次开发,对于一个管理软件供应商而言,这种人力成本依然很高。具有丰富业务积累的供应商便需要考虑,如果事先把各种业务需求都预制在产品中,通过参数开关,实现对客户的个性化配置,这样便可以大大节省二次开发的成本。
当然,做到这一点,需要很大的投入。首先是,需要以丰富的业务积累为前提;其次,产品研发的难度很大,需要强有力的研发力量。
所以,目前也只有SAP在这方面做得较好。Oracle虽然也可以进行大量配置来个性化,但许多时候,还是要进行二次开发。用友和金蝶就更逊一些了。
二次开发和参数配置是目前的主流模式。管理软件商大都同时采用这二种方式来提供解决方案。而且,一个趋势是,随着产品研发的不断深入,大多强化业务积累和配置,减少二次开发的工作量。
但就SAP而言,虽然把参数配置模式发挥到及至,但其产品的复杂性和高昂的实施和维护成本,已经令客户不堪重负。解决方案的敏捷性便成了一个突出的问题。
五、构件装配模式
构件装配的思想显然是受制造业的启迪。这个思想已经提出很久了,构件技术也有了很大的发展。现有的管理软件产品,无疑也大量使用了构件技术。但是,很难说,时下的那种管理软件采用了构件装配模式。
以Delphi这种工具为代表的事件驱动开发,把构件技术首先用在表示层,大大提升了桌面应用的开发效率。EJB把构件技术成功地推广到中间服务层,充分体现了构件技术的威力。但这些技术型构件的积累,主要是对软件开发的效率有很大提升,关管理软件什么事?管理软件更关注业务的敏捷性。
于是,构件平台出现了。不仅是积累各种技术性构件,更主要的是积累丰富的业务构件,以实现对管理软件的快速装配。这种平台,目前在一些行业应用中得到了初步的展示。但是,它似乎更多地是同二次开发模式竞争。
实际上,正如我在以前的随笔里倡导的商业对象的去对象化,业务构件的积累则是典型的商业对象的对象化,其困难我以前的随笔已有说明。
六、模型驱动模式
这个思想也很早就出现了。只是那时多用一个技术术语:代码生成器。也就是说,通过图示表达自动生成程序应用。如今的技术有了很大发展,这个思路也就有了大展身手的舞台。OMG搞的受到IBM等大企业推崇的MDA,就是如今正热门的模型驱动模式。
模型驱动的基本思想是,把复杂的业务描述为一个平台无关的模型,再自动转换为软件代码,生成应用。这个思路可以说直指参数配置模式。无需研发成本高昂、复杂庞大、包罗万象的可以进行强大配置的ERP产品,完全可以根据业务变化随时快速生成一个新的应用,能更好地适应业务的敏捷性。KCOM 商业工程企业应用平台就是这方面的一个代表性的产品。
以上,大致列出了6种管理软件的生产模式。如果非要给出一个演化序列,大致可以说,标准产品模式和完全项目模式为第一代,二次开发模式和参数配置模式为第二代,构件装配和模型驱动为第三代。目前的管理软件生产模式以第二代为主,但已经开始逐步向第三代演化了。
我个人的看法是,第三代模式将会以模型驱动为主导,构件装配将会隐退致幕后。这并不是说,构件技术被淘汰了。而是说,构件始终是技术构件。所谓业务构件,也仍然是程序代码段,积累再多,也不能有效应对业务敏捷变化。不如直接从业务模型自动生成应用来得快捷。
联想起管理软件的生产问题,较之IT技术的飞速发展,其生产率并没有显著的提升。企业对信息化的渴求与管理软件实施与服务成本的居高不下,是目前这个市场最为突出的矛盾。也许也可以对管理软件的生产问题先归归类,以便更好地分析问题的症结所在。
一、标准产品模式
搞一个产品到处买,是最为理想的方式。数据库、Office等软件就是这样成就了Oracle、Microsoft。在企业应用领域,CAD、办公OA等也可以在一定程度上做到标准化。但最突出的是财务软件,用友、金蝶已成为一个经典范例。
当然,管理领域是如此复杂,差异化是如此丰富,这种标准产品模式已经是可遇不可求了。
二、完全项目模式
国内很多中小软件公司都是靠这种方式生存的。没有什么产品积累,搞一大帮开发人员,从零开始为用户定制开发企业应用。对用户而言,这个可是最彻底的量体裁衣。
但这并非说明用户的业务就真的这么特殊,软件开发商也并非自觉地地专注于一个细分的市场。就国内而言,这种情况是管理软件的起步阶段,低水平建设的标志。实际上,考虑到IT人员的高流动频率,此类软件开发商大多处于低水平重复的恶性循环,也不大可能为客户提供高质量的产品和服务。
以上二种方式实际上是二个极端,一个完全标准化,一个完全定制化。在管理软件市场的起步阶段,这二种方式占据主流的位置。随着市场的逐步成熟,这二种方式也逐步被边缘化了。预计今后只有在特定的细分市场,这二种方式才会被继续采用。
三、二次开发模式
一个完全项目模式的开发商,在多个案例中可以归纳出项目的许多共性,于是一种产品原型便提炼了出来。在这个基础上,再给客户作定制开发,开发效率无疑会大幅提升。这种二次开发模式于是便成为管理软件的主流开发模式。
过去搞标准产品的开发商,如用友、金蝶,在向ERP进军的过程中,也纷纷采用这种通用模式。往往是先通过完全项目模式搞点积累,然后采用二次开发模式迅速打开市场。
四、参数配置模式
如果每个客户项目都需要派大批软件工程师进行二次开发,对于一个管理软件供应商而言,这种人力成本依然很高。具有丰富业务积累的供应商便需要考虑,如果事先把各种业务需求都预制在产品中,通过参数开关,实现对客户的个性化配置,这样便可以大大节省二次开发的成本。
当然,做到这一点,需要很大的投入。首先是,需要以丰富的业务积累为前提;其次,产品研发的难度很大,需要强有力的研发力量。
所以,目前也只有SAP在这方面做得较好。Oracle虽然也可以进行大量配置来个性化,但许多时候,还是要进行二次开发。用友和金蝶就更逊一些了。
二次开发和参数配置是目前的主流模式。管理软件商大都同时采用这二种方式来提供解决方案。而且,一个趋势是,随着产品研发的不断深入,大多强化业务积累和配置,减少二次开发的工作量。
但就SAP而言,虽然把参数配置模式发挥到及至,但其产品的复杂性和高昂的实施和维护成本,已经令客户不堪重负。解决方案的敏捷性便成了一个突出的问题。
五、构件装配模式
构件装配的思想显然是受制造业的启迪。这个思想已经提出很久了,构件技术也有了很大的发展。现有的管理软件产品,无疑也大量使用了构件技术。但是,很难说,时下的那种管理软件采用了构件装配模式。
以Delphi这种工具为代表的事件驱动开发,把构件技术首先用在表示层,大大提升了桌面应用的开发效率。EJB把构件技术成功地推广到中间服务层,充分体现了构件技术的威力。但这些技术型构件的积累,主要是对软件开发的效率有很大提升,关管理软件什么事?管理软件更关注业务的敏捷性。
于是,构件平台出现了。不仅是积累各种技术性构件,更主要的是积累丰富的业务构件,以实现对管理软件的快速装配。这种平台,目前在一些行业应用中得到了初步的展示。但是,它似乎更多地是同二次开发模式竞争。
实际上,正如我在以前的随笔里倡导的商业对象的去对象化,业务构件的积累则是典型的商业对象的对象化,其困难我以前的随笔已有说明。
六、模型驱动模式
这个思想也很早就出现了。只是那时多用一个技术术语:代码生成器。也就是说,通过图示表达自动生成程序应用。如今的技术有了很大发展,这个思路也就有了大展身手的舞台。OMG搞的受到IBM等大企业推崇的MDA,就是如今正热门的模型驱动模式。
模型驱动的基本思想是,把复杂的业务描述为一个平台无关的模型,再自动转换为软件代码,生成应用。这个思路可以说直指参数配置模式。无需研发成本高昂、复杂庞大、包罗万象的可以进行强大配置的ERP产品,完全可以根据业务变化随时快速生成一个新的应用,能更好地适应业务的敏捷性。KCOM 商业工程企业应用平台就是这方面的一个代表性的产品。
以上,大致列出了6种管理软件的生产模式。如果非要给出一个演化序列,大致可以说,标准产品模式和完全项目模式为第一代,二次开发模式和参数配置模式为第二代,构件装配和模型驱动为第三代。目前的管理软件生产模式以第二代为主,但已经开始逐步向第三代演化了。
我个人的看法是,第三代模式将会以模型驱动为主导,构件装配将会隐退致幕后。这并不是说,构件技术被淘汰了。而是说,构件始终是技术构件。所谓业务构件,也仍然是程序代码段,积累再多,也不能有效应对业务敏捷变化。不如直接从业务模型自动生成应用来得快捷。