社会组织的主要形式有如下几种：
企业明显的区别于其他组织方式，企业一般有销售、采购、库存、市场、人力、行政、研发生产等部门，这些部门为了完成公司的目标有不同的职责和业务流程。当企业使用软件工具来辅助运营公司时，软件商提供的软件产品则可称之为企业软件。企业通过软件来进行公司管理的过程叫企业的信息化。
维基百科中“企业软件”有如下定义：
企业级软件，也称企业软件（Enterprise software）或者企业级应用软件，指的是支持企业、事业单位或者政府等机构各项业务运作的软件系统。除了支持机构内部的协同工作之外，企业软件也支持企业与其供应商、业务伙伴和用户的协作与协调[1]。
企业级软件可以按功能划分为财务会计、ERP（企业资源规划）、CRM（客户关系管理）、SCM（供应链管理）、HRM（人力资源管理）、BI（商务智能）、CMS（内容管理系统）和企业通信工具等。也可以按行业划分为制造业、零售业、医药业等解决方案。
马汀·弗勒（Martin Fowler）在其《企业应用架构模式》一书中这样定义：企业级应用主要负责显示、操作和存储大量复杂数据，并对这些数据进行支持和自动化。
维基百科中有两点的观点与本文不同：
企业管理者一般对企业管理软件的期望是概括来说有如下几个：
编号
企业期望
说明
常用软件或者模块
1
营销
借助互联网进行品牌的宣传和推广，最终达成销售
CMS、企业门户网站、商城系统、微博、微信。典型的是企业通过网站或者而购买关键词把流量引入自己网站（商城），推广自己。
CRM管理系统，用来进行客户行为分析指导企业决策，CRM还可以进行客户二次营销。
特别说明的是,相对于如下几点，营销类软件是市场是需求最强的，原因有如下几点：
从技术上来说，营销类产品简单、通用性强；变化快，美工要求多；以网页形式展现。
2
提高效率
使用软件工具提高工作效率
使用专业工具一般有比较强的行业特性，比如广告公司用Photoshop，制造行业使用AutoCAD，建筑行业使用计价算量工具。计算机发展到现在，没有此类的软件工具，有些行业就没法工作。
本文强调的是与企业管理软件整体结合的工具，而不是纯粹的专业工具，比如电商ERP本身具有的批量打印快递单功能。
企业使用这些工具的目的本质是为了提高效率，不是为了管理。
3
管理
使用软件工具辅助自己企业内部管理
由于历史的原因，管理系统国内一般从两个角度来做，这一点的区分比较有趣而且非常重要：
class="1">1． 基于工作协同的思路，如OA系统、工作流系统、IM、项目管理系统等等，强调工作流程，这种角度与真实的业务更适应，更容易操作。
2． 基于数据的管理的思路，如财务会计、ERP、CRM、SCM、HR等等。
基于工作协同和基于数据管理是基于其倾向性而言的，不是说基于工作协同的就不基于数据管理，或者基于数据的就不基于工作协同。总的来说他们将来应该是不进行区分，目前市场上也有两种结合到一起的产品。
4
BI
使用信息系统的数据作为企业决策的依据
有时也称之为商业智能，基于大数据做的企业决策分析。容易理解，不再赘述.
对于一个人而言，欲望无限而其能力有限，这种主客体上的差距是其痛苦的根源；经济学的本质则是如何分配资源给有无限欲望的人类。同样,研发产能有限而客户软件需求无限则是管理软件的主要矛盾，这里有限产能指的是无法承担的成本或者无法完成的进度要求等。
虽然通过高级语言、面向对象、技术组件及平台、MRP、ERP等的发展，问题得到一定程度的解决，但是问题仍然存在。目前，一方面软件从业者通过技术方面的框架或者平台积累，另一方面也在管理理论方面有所积累（如MRP和ERP），解决了一些通用的问题，这叫管理软件的标准化。但是每个行业和每个客户都有自己个性化的要求，解决仍然困难，这种现象本文称之为客户化。所以，如何解决标准化和差异化是企业管理软件的核心问题。
本文尝试从企业的角度和技术的角度来对差异化进行考察。企业的角度是不同的企业主要在所处行业、企业规模、企业文化及企业制度三个方面有所不同，详细情况参见下表：
编号
内容
说明
其他说明
1
所处行业
金融、传媒、电信、石油、医疗、建筑施工等不同的企业所关注业务完全不同，这导致对软件的要求差别非常大
不同的行业体现在不同的流程，以及不同的行业概念上，行业的概念对应的是不同的业务字段和业务规则。
2
企业规模
一个跨国公司和一个30人的小公司，企业管理也是不一样，对软件的要求也有天壤之别。
不同的企业规模主要体现在组织机构以及业务流程上。
3
企业文化及企业制度
相同的企业，不同的管理者对企业不同的管理对软件的要求也不尽相同。
如果企业信息化程度比较低，则适合软件简单一些，较少的改变现有员工工作方式，通过渐进的方式实现信息化，如果企业领导是一个完美主义者，则信息化失败的几率大大增加。
另一方面，非软件从业人员肯定会错误的评估软件的复杂度和实施的难度，这是也导致软件不能成功的重要原因。
那么从技术角度来说，客户化的角度很多，下表按照由大到小的几次顺序介绍了常见的几种级别的客户化。
差异化
内容
常见解决方式
1
物理形态级别
是否基于互联网
是否支持跨国应用
等等
2
技术选型级别
一般要指定的操作系统、指定的开发语言、指定的数据库等
3
业务流程级别
任意新增流程或者改变现有流程
4
系统选项级别
一般在工具选项中来停用启用某些功能
此种方式比较常见，处理起来容易理解。但是其同其他级别的扩展很难通过插件的方式体现出来。
5
单据级别
新增加一张单据类型
6
字段级别
在现有业务对象上添加字段
在现有的字段上添加一些逻辑
7
界面级别
改变界面的布局和样式
上文已经得出结论客户化是企业软件的核心问题，这是从产品功能的角度来说的。如果从技术角度来说，客户化其实就是软件的复用和扩展，所以也可以说复用和扩展是企业软件的核心问题。下面是本关于复用和扩展的几个观点：
复用和扩展也可以看成是企业软件客户化的解决方法，但是因为这种方式理解起来比较简单，所以可以认为他是一种现象。如何进行复用和扩展的具体技术手段则是解决方法中需要重点关注的。
复用和扩展的文章和著作较多，本文不再展开赘述。
本人认为从事企业软件的技术从业者需要两个能力，分别是分析设计与技术架构，这两点应该囊括一个企业软件开发者的所有能力；很多软件公司研发一般分成两个部分产品研发部（或者项目开发部）和平台部也是这种分类的方法。分析设计和技术架构的能力对于一个技术人员来说这两种能力是一体的。
分析设计是针对客户指定的需求，通过分析建模大脑的思维，最终以技术化的语言表达出来，成果就是其设计文档或者代码/伪代码，设计成果的标准有三个：无歧义、不重复、无遗漏；这三个标准是针对于设计成果的读者的，因为读者不同，所以设计的成果可能会不同的，有一种说法叫设计是基于一种认同，与此意思是相近的。
分析设计一般针对于特定的问题，这些问题一般都是繁琐且复杂的，所以这些问题只有当事人关心，在软件技术社区中其他人员对其问题并不关心，所以一般分析设计的交流都是分析设计方法论的交流，比如UML就是一种分析设计的方法论，大家会一起讨论UML怎么用。本人把分析设计的过程总结为如下的一段话：
企业软件的分析与设计是针对需求定义的问题域进行树状结构的合理分解（本文称之为分而治之的方法），分而治之的目的（也是分析设计的目的）是找到最小粒度的代码单位，容易理解的代码就是最小粒度代码单位。
依据上面内容下可以得出且需要强调的如下几种观点：
1， 设计的思维方式或者设计结果（代码组织或者设计文档组织）和需求是一致的。也就是说在理解需求的情况下，如果有技术经验是很容易理解代码的，或者基于代码就可以容易的了解需求。如果设计组织和需求文档的思维方式的不一致，极有可能是需求的不合理或者设计的不合理。
2， 离开具体的需求就不存在设计，换言之离开具体的需求谈设计的好与坏是无意义的。
3， 不了解需求的评审是无意义的。
4， 设计分析过程是归纳的过程，体现的结果是层层展开的逻辑分树。只能是先具体后抽象的过程，这要求设计必须找到代码的最小逻辑单位，走遍所有的逻辑路径。
5， 代码的多与少不是设计好与坏的关键因素，基于需求是否进行合理的分解，是否找到了最小粒度的代码单位才是设计好与坏的最主要因素。
6， 设计是须有很强的代码经验。软件设计就是用程序语言描述问题域的过程，这和用进行文字创作有异曲同工之妙，他们都是人的思维通过语言的对别人的表达。
7， 分而治之逻辑树上每个节点都对应一个完整的概念，每个概念的命名是第一性和至关重要的（且和尽量和需求的叫法一致），他是设计和开发沟通的基础。设计的思维比需求的思维要细密，所以概念也会比需求多。概念的创建不要多也不要少。
8， 设计已经找到了最小粒度的代码单位，其走遍了所有问题域的逻辑路径，复用、扩展、重构等是水到渠成的，体现代码之美。
9， 基于可预见需求的扩展才是有意义的扩展，否则是过度设计。
10， 分而治之方法的设计是归纳的过程，是一个迭代（否定之否定）的螺旋式的过程（重构）。
分析设计是一种实用的方法论，也是一种形而上的美的艺术，因为其艺术性所以仁者见仁，智者见智，观点很难统一。本人会单开“分析设计”系列详细论述上文观点，此文不再赘述。
技术架构和分析设计的区别主要体现在下文的企业软件研发成熟度分析中（企业软件研发七阶段），技术架构主要做第四阶段即技术平台的工作，业务分析主要做业务平台的工作。这种区别是就其倾向性而言的，如果说这两种能力就是同一种能力也是能说得通的。
本文的所有系列则都是说都是技术架构，技术架构和分析设计相比，技术架构一般都涉及通用的技术点，所以有具体的可视化的成果，更容易被理解和认同。技术架构关心的问题有持久层、MVC、分布式、事务、序列化等等。从另外一个角度来说，技术架构是技术人员立足于若干需求场景所做的抽象工作的分析设计，所以技术架构也算是一种分析设计。
企业软件研发成熟度分析本人于2010年总结的国内企业软件七种软件研发的模式，这其中模式是由低到高的不同阶段，所以也可以称之为企业软件研发七阶段。
阶段
特征
达到的条件
1
硬编码
直接使用IDE提供的工具进行代码的编写，很少考虑使用第三方的组件，或者自己封装正规的组件。一切代码只要能实现客户需求即可，不愿意或不懂得多做一些从技术上有益于产品的工作。
2
部分组件
1，开始需找第三方的组件，包括界面控件、持久层、配置组件
2，自己写一些常用的组件
3，可能使用一些第三方工具，如PD等进行快速的代码生成
4，有初步的分层思想
3
系统框架
自己写或者使用第三方的组件，特点是框架的全面性，在每个主要的技术点都有系统框架的支撑
1，团队技术负责人对技术热爱，希望写出高质量的代码
1，会对比分析各种部署方式下的开发模式包括，会分析前段的各种展现方式（Silverlight/WinForm/WPF/HTML4/HTM5）,会分析分布式的各种组件（webservice/json/remoting/wcf/socket）,分析各种持久层框架，等等
2，熟悉常见的业务展现形式，从技术角度进行整理，包括单据、列表、报表、选项、工作流、等等
4
技术平台
(业务基础软件平台)
1，技术平台本身即为产品
2，在系统框架基础之上，提供友好稳定的工具维护框架下的元数据，并提供二次开发接口和工具。
3，提供基础业务功能，包括权限管理、组织机构管理、单据编码管理、枚举管理、选项管理、工作台界面等等
1，被动使用平台：业务本身复杂，不使用技术平台，导致研发成本太高
2，主动使用平台：技术负责人愿意在系统框架之上提供优良的开发工具让业务开发人员进行元数据的维护。
技术负责人愿意对实施人员，或者有二次开发能力的客户提供接口和平台开发工具
5
业务平台
1，在技术平台之上，业务按照领域对象为粒度，每个领域对象可以单独存在，可以和其他领域对象组合成新的的业务，可以扩展功能，可以二次开发覆盖原有的功能
2，在第一点的基础之上，可以基于流程调整领域对象的流程关系
1，领域的总体设计师期望做出结构优良的产品
2，产品经理对业务的分析抽象比较合理
6
软件生命周期管理
1，技术平台和业务平台是进行产品的研发，本阶段是为这两个阶段提供项目管理工具，此工具可以是自己研发的，也可以是继承第三方产品到自己的产品中。
2，功能包括源代码管理、需求管理、BUG管理、升级和补丁管理等
1，研发负责人愿意使用科学的管理手段进行项目管理
2，研发负责人愿意在自己的管理软件平台上扩展出项目管理的功能
7
软件生态环境
1，前六个阶段是在产品厂商的角度来看的，此节点是站在整个社会的角度来看的。
2，生态环境允许第三方开发人员和厂商在现有的业务平台上扩展业务功能。也允许在技术平台上构建自己的特殊的业务。典型的例子有Eclipse和淘宝电商平台。
3，产品厂商和第三方互惠互利，合作共赢共同达成一种生态圈。
1，技术团队、业务团队、销售团队三者目标都有志向，目标远大
2，产品真的能为客户带来价值，物美价廉
3，平台能为第三方的开发人员、销售人员带来利益
4，团队有卓越的业务能力和推广能力
企业业务基础软件平台，是这几年逐渐被认可的一种叫法，很多人叫技术平台或者平台，都不太准确。业务基础平台是上文“企业软件研发成熟度分析”第四个阶段，他是在一个语言（如.NET或者JAVA）平台基础之上做的一个可以快速最终产品的平台。下图介绍其同应用软件、软件开发平台、操作系统在概念上的区别：
企业业务基础平台本身对客户不产生直接价值，他对软件厂商有价值，可以帮助研发人员最低成本的构建面向最终客户的软件产品。
国外并没有业务基础软件平台的概念，这也算是中国特色，原因是中国客户化的要求太多了，导致软件商想办法提高软件自身的复用能力和实施能力。还有一个原因是国内的环境下，没有资源做更深的技术，所以大部分的精力都在做管理软件，自然的也就都在做业务基础平台。
本文认为企业基础业务平台是解决客户化的一个重要的方式，首先，平台本身提供了通用的基础功能如组织、权限、工作流等等，这些功能研发成本是很高的；其次，平台作为开发人员和实施人员的工具，从技术手段上可以在很大程度上不修改代码的情况下完成客户的一些个性需求；最后，平台本身也是一个框架，他完成了一些大量的基础性的技术工作，如分布式调用、持久化、并发、引用检查等功能，这些基础的技术工作，对技术的要求比较高。
有了企业基础业务平台，并不能解决所有客户化的需求，因为客户的需求是无限的，能解决客户化需求是有其范围的，这个范围是由平台设计人员的能力决定的，也就是说，平台设计人员的能力决定了解决客户化能力。
企业软件七阶段的第五阶段是企业业务平台，相对于业务平台来说，基础业务平台称之为技术平台是有一定道理的。业务平台是提供面向最终客户的解决管理业务的产品。一个有意思的话题是，从研发成本上考虑，技术平台和业务平台的研发投入比重都各占多少呢？答案是由技术平台的功能以及业务的客户化程度决定的，一般来说，客户化程度越低的产品，技术平台比例越高，最大的场景是，不需要业务开发代码，技术平台可直接配置满足客户需求的产品。本人所在的公司所研发的很正规的ERP产品和技术平台产品的代码量基本是对半。对于国内某些平台所声称的不需编写代码即开发产品是幼稚可笑的。
继续考察技术平台和业务平台的关系还可以得出结论，首先技术平台为业务平台提供框架和基础技术工作，这些工作不仅仅是减少了业务开发的工作量，更大的价值是，技术平台的框架和基础类库本身就是一个研发的规范，这比制定研发规范要实际和有效的多；另一方面，技术平台提供了工具，提高工作效率，进行工作纠错，让业务开发人员从乏味的基础工作中解脱出来，如业务人员做一张销售订单的表单界面，有平台工具的支持，一般需要20分钟，但是如果硬编码，可能需要1-3天。
本文特别感谢东莞许胜平的建议和校对工作。
相关文章
