如果将现存的林林总总的ERP软件的开发模式分一下类，大致可以分为大规模定制开发、商业软件＋少量定制开发和介于两者之间的平台＋少量定制开发等三种开发模式。开发模式不同，其产品的特性不同，其实施方法也各异。下面笔者将对这三种开发模式进行对比和分析，希望有助于那些想上ERP的企业正确认识和选择ERP软件。
定制开发将逐步退出历史舞台
定制开发，过去曾是一种很有诱惑力的开发模式，随着行业的不断规范，各种行业软件的不断推出和国内外大型企业管理软件提供商的不断蚕食，定制开发这种小规模的开发模式正在逐步退出历史舞台，取而代之的是那些成熟产品和业务平台。
定制开发其业务范围是很有限的。一方面，定制开发只能是小规模的，一个几百万、上千万的项目要定制的话，开发出来的产品是否专业不说，单就开发这样一个系统所耗费的开发和实施时间，也非一般企业能承受。另一方面，定制开发对软件公司的综合实力特别是行业实力要求比较高。而事实上，很多软件公司没有专业的行业解决方案，常常是见单打单，很多时候只是企业业务的手工模拟，能够实现手工业务电子化就很不错了，又怎么能将ERP的先进管理理念和思想融入其中呢！
大规模定制开发带来的主要问题是，企业形成了庞大的IT队伍，公司在IT这个非核心领域投入过大，并且还在不断膨胀。下图反映了业务人员描述需求，IT人员进行开发的大规模定制模式的弊端， 虽然是一种漫画的方式，但却真实地反映了定制开发这种开发模式存在的如下一些问题：
1. 业务人员的描述IT人员理解得不准确。
2. 业务人员的描述本身不够严谨，随时间的变化或人员的变动会经常变更。
3. 系统的整体管理水平直接取决于业务人员的管理水平和思想。
4. 业务需求一旦变动，IT人员就得变动系统，IT人员的工作量会很大。
由于定制系统的灵活性差，开发周期长，行业业务理解不深刻，基本上是手工作业电子化等特点，定制开发无法将ERP管理软件的先进管理思想，如标准化、全面质量管理、供应链管理等思想融入其中，同时由于成熟软件产品的不断丰富和蚕食，定制开发必将逐步退出历史舞台。
平台模式将是主流
平台在2001年是炒得最热闹的一个概念，很多系统，有的甚至仅仅只是一个Excel做的几个宏文件，也有人要加上一个平台。我们究竟该如何理解平台？
平台的概念目前大体上有两种，一种是基于快速开发目的、提供一些辅助开发工具（如系统管理、组件等）的开发平台，这种平台是一个纯粹的技术平台，充其量是一个开发工具（如Delphi）的优化。只要有开发任务，所有的客户业务都需要重新开发（当然有些技术平台也包含了一些系统管理、组织权限等相对通用的东西）。
一般来说，技术平台具有如下缺点:
1．开发的工作量大，提供的功能有限。无论怎么完善和拓展也只是一个技术平台，所有的业务都要重来，无法形成行业解决方案。
2．使用困难。开发人员比较熟悉开发工具（如Delphi），但要熟悉一个技术平台需要很长的时间。一方面技术平台是某个公司特有，开发人员在没有使用该平台之前无从了解该技术平台的情况；另一方面，由于管理软件公司实力方面的缘故，不可能和那些市面上比较流行的开发工具如Delphi相比，特别是文档不全，开发人员的风格不统一，人员流动大。一个技术平台需要手把手地教，而且很多平台有开发人员自己的个性色彩，因此技术平台使用也是需要代价的。
3．无法形成行业积累和行业经验，复用度非常低。所有的客户业务知识都储存在程序员大脑中，无法实现共享，一旦程序员离开公司，所有的知识都被带走。另一方面，复用对一个软件公司来说却是至关重要的。
相比较而言，业务平台具有更多的优点：
1．业务平台是从技术平台上发展起来的，具有技术平台的快速二次开发、易于拓展的特点。
2．业务平台封装了企业所有掌握的客户业务，容易形成行业积累和行业解决方案，能够最大限度地实现知识的复用。
3．业务平台可以自我完善，不断丰富和发展。和技术平台相比，业务平台可以在实现技术上进行完善和升级，同时，随着公司业务的扩展和实施案例的增多，平台中不完善的地方将被完善，同时更多的客户业务将被扩展到技术平台中。随着业务平台的多次客户化应用，平台有机会变成行业软件产品（或准产品）。
当然，业务平台也有很多需要考虑和完善的。笔者以为，目前的业务平台主要有以下一些方面值得关注：
1．数据绑定问题。一方面是要支持不同的数据库，另一方面是数据的存储。业务数据是以数据库表（Table）的形式来表现还是以对象来表现，从长远来看，可能是以对象来表现。但用对象来表现技术怎么实现，效率怎么办？笔者参与开发的一个平台就是因为采用了完全面向对象的方式来绑定数据，导致系统效率极大的降低。
2．效率问题。由于业务平台不是针对具体的业务，因此，运算逻辑就会比较复杂，同时由于各业务组件是相互独立的（业务平台通常作为一个框架模式开发，控制权掌握在框架上，各业务组件必须独立，否则就不是一个平台了），各系统之间的连接也会影响到系统的效率。
3．业务逻辑的提取，这是很多技术平台无法向业务平台转化的关键。首先，我们要进行业务的抽取。笔者建议先按标准的ERP理论来提取，接下来请相关业务专家进行完善和业务逻辑具体化，必要时可以借助外部咨询公司的力量。最后在实践中检验。
成熟的ERP产品是信息化的基础
相对大规模定制开发和平台模式下的企业信息化建设而言，拥有一个相对成熟的产品具有得天独厚的优势。当然这个产品不一定是一个具体的、有形的东西。这个产品可能是解决方案，也可能是平台，也有可能是代理的产品。产品是谁的并不是关键，关键的是如果我们没有产品，拿什么来解决客户的问题呢？
成熟的ERP产品为咨询实施服务提供了成功的基础：
1．可以直接利用现成的信息技术产品来顺应企业飞速发展的需要。能不断跟上信息技术发展的步伐，充分体现利用最新技术的优势。
2．可以直接利用和借鉴商业软件中先进的管理思想、理念和行业经验。商业软件的实施，是一个从特殊到一般，从一般到特殊的过程。
3．充分利用优秀商业软件功能全面、灵活性强、适应性强的特点，适应企业的不断发展和变化。
4．实施周期短，业务系统实施以业务人员为核心，全力关注业务的改善，IT人员负责系统的技术架构。
5．不需要维护庞大的信息化队伍，项目总体投入少。
6．总体技术难度小。
在ERP软件的产品化过程中，有如下一些因素在阻碍其产品化：
1．认为产品一定是一个具体的、有形的东西。其实，ERP不仅是一套的信息系统，更是一个实实在在的改进管理的系统工程，是借助软件来表达先进的管理理念和管理思想的信息系统。因此，广义的ERP产品可以是解决方案，可以是IT规划，当然也可以是一个具体的产品，认定ERP一定是一个具体的产品其实是对ERP的不理解。
2．认为代理产品会失去核心业务。当笔者第一次听到有人说自己不应该做代理，那不是自己的产品时，笔者很震惊。著名的开放源代码ERP软件提供商Compiere公司就提出“零产品”的概念，他们的产品是什么？是高质量的、本地化的咨询实施服务，从这个角度来讲，我们可以认为Compiere公司的产品其实是一套方案。可见产品不是关键，关键的是实施，是我们的咨询能力；关键的是我们是否有实施能力，我们是否是客户认同的行业专家，是否我们能提出确确实实适合客户的解决方案。
3．关心技术胜过关心客户业务。很多客户认为一个软件产品的好坏主要取决于软件公司技术实力而很少关心软件公司对企业业务的了解程度。尽管这种情况随着行业的标准和客户的成熟而逐渐改变，但这种需求对软件公司的影响却是根深蒂固。软件公司为了迎合客户的需求，一味强调自己的技术，而技术人员由于对纯技术的“发烧”和性格上的内向倾向，使得软件公司往往关心技术胜过关心客户业务，这无论是对客户、对软件公司还是中国软件企业的发展都是非常不利的。笔者在和很多软件开发人员交谈中感受到，在这些开发人员眼中技术是第一位的，而事实上，信息化项目的实施软件充其量只占30%，更重要的是要研究企业的业务，形成自己的行业解决方案，更多关注项目的实施。
4．一味地炒概念。这种现象一度非常盛行，今天有ERP，明天就有ERPⅡ，后天就有RTE，名词一大堆，美其名曰搞创新。其实，与其炒作这个概念，倒不如踏踏实实地研究一下如何优化自己的产品，完善自己的方案，研究一下企业要怎样才能实现协同，怎样才能做到采购、生产、销售一体化，怎样才能实现与供应商、客户协同，发展企业的产业链。
|
