管理信息系统实施成功三大因素依次为：人、数据、技术，也许有些人不完全认同，但是数据的重要性是大家不可否认的。

1. 数据管理的组织机构的建立

为了更好的进行软件系统的数据管理，应该从组织机构角度来做考虑，建立单独的组织机构来管理数据相关工作，或者在实施小组里面专人总负责。

软件开发商和客户核心的业务骨干一起制定数据规范，客户提供符合规范的业务数据，只有符合规范的数据才能进入系统。

2. 数据管理的原则

强调客户和软件开发商的2方项目组成员做到“不能有‘我以为’的思想”，一旦有如此思想，很容易陷入闭门造车，项目需求很容易走样，因为客户à所有的客户，也是在‘我以为’。项目组要想做到控制住需求，一定要抛开自己的设想。所以任何一个项目组成员，第一句话告诉他，不要有“我以为”的想法。把’我以为’变成’客户认为’(好是客户和软件提供商一致认为)，这才是重要的。

呵呵，这又回到了项目管理上。我在这里实际上只是想从数据管理这个更具体的角度来阐述问题。

3. 数据入口的单一性

同一数据必须一次、一处进入系统，保证其准确性，及时性和完整性和入口的单一性。管理控制一体化是系统的目的，如果一个数据在多个地方存储，很容易造成数据的不一致。

4. 数据副本管理/数据版本管理

虽然上面提到了数据存储的单一性，但是有些时候也需要存储副本数据。存储这些副本数据的目的是为了在使用数据副本的地方不受到数据源的变化的影响。

例如：数据1在业务A进入系统，业务B使用到了数据1，但是为了避免在业务B使用了数据1后，业务A又把数据1的修改影响到业务B，那需要业务B在使用数据1时候保存副本。

比如：城市拆迁资源计划系统(http://www.netsky-tech.com/)的拆迁合同在使用房源业务录入的房源房屋面积信息时，使用了副本机制，在合同使用房屋面积时候，把面积信息存储下来，当合同构筑完成时候，如果相应的房屋面积信息发生了变动，用另外的业务来处理这个数据变动的相应处理（比如，使用房源的差价款合同来处理）。

有朋友建议用配置管理系统，把数据版本机制引入了业务数据里面.做过J2EE的项目，都知道很多地方可以通过配置来进行管理。其实这个思想延伸到数据库模型的设计时候，体现出来了业务数据的配置管理的思想的使用。
我们其实也有是用这个思想，但是主要体现在 在基于数据表级别上用数据级别+历史编号 来识别有效的数据。1个很简单的例子：

一个员工的姓名原来 是aa， 后来改委bb，可以通过历史编号 找到原来 的信息是bb通过数据级别识别现在的有效数据是aa，我们把数据版本控制更多的是采用’数据级别’加’历史编号’另外还加上了一个’生效日期’， ‘截止日期’这2个时间戳另外，实际软件系统的历史业务数据进入系统比较烦，可能需要使用版本管理机制来处理才行得通。

5.建立数据等级制度

软件项目实施中业务规则经常会陷入一个两难的境地，如果业务规则加强，很多数据数据达不到规范化的要求，无法入机；如果放宽控制，很多垃圾数据进入了，大家都明白一个道理，对于软件系统，垃圾数据进去，肯定是垃圾数据出来，统计查询结果肯定是这样的。

可以建立数据的等级制度，制定数据进入系统的低要求。达到低要求才能进入系统，比如：

业务A，需要数据a1，数据a2，，数据a3， 数据4。我们可以制定进入系统的关于业务A的条件是必须要有数据a1，a2才可以进入系统（也是低要求），如果提供的业务数据同时有数据a1，数据a2， ，数据a3，那是更高一级的数据（第二级数据），如果业务数据在满足第二级数据的基础上，提供了数据4，那是第三级数据。

如果用过J2EE平台的同行理解起来比较容易，这实际上是JMS基于主题的消息管理思想用于软件系统一个具体例子而已，这里不过是强调的是用于管理数据的信任等级而已。

其实很多软件项目开始制定的的数据规范，一般到后来都执行不下去，主要是太理想化了，也许只有到系统真正用起来了，系统数据的信任等级才能上去。所以我觉得应该在系统开始时候把数据分等级，不同的等级，业务给与适当不同的处理，这样也便于后期的业务进行查询统计分析或者数据挖掘。

这种思想实际上是将数据可以信任的程度进行分类；而一般的软件系统是把数据定义为两类，可以进入系统，不可以进入系统；我在这里设想的是，从数据可以信任的角度出发，分成多种类别，使用了一个小数来描述信任程度，而不是一个二值逻辑变量来描述；这样从建立软件系统整体模型的时候，把数据信任管理纳入考虑之内，在进一步作业务分析，决策支持或者数据挖掘时候是比较有好处的；当然进一步延伸可能需要从OLTP/OLAP混合建模来考虑，不过真要到那个高度，可能项目范围扩大了很多，具体怎样操作，还要看项目具体情形。