对于数据来源的识别，一般需要有特定信息来记录数据的来源，特别是一些大型企业当然分支机构较多的公司企业政府，也应该这样来管理。在现实中稍微规模大一点的软件系统涉及到的组织机构都是比较大的，有很多还可能是松散的组织管理模式。在这类组织机构中，同样的业务数据可能很多部门都会是数据录入点和数据分析点，为此可以从数据采集/来源角度来描述数据本身。从当前项目利益来说，数据来源管理方便数据查询分类，长期来说可以建立起数据信任等级。
事实上，数据来源管理是数据信任管理的进一步延伸，是数据信任管理的前置条件。一个数据，可以是来自于A部门的也可能是来自于B部门的。为了方便统计查询和数据信任管理的加强，应该记录下数据的来源地。
具体操方式可以有以下几种：
1） 数据录入人员的工作人员编号，知道了数据录入人员的编号，就知道数据的来源地。
当然，实际工作种存在人员调动，替操作（1个人用另外一个人的身份进入系统数录入），这些都有可能需要考虑到，否则可能造成数据来源管理失效。
2）另外一种方式就是直接记录数据录入的部门编号。
这种方式弊端就是不能记录下数据的具体操作人员。
其它说明：如果系统中引入了工作流产品，数据来源这部分工作可以由工作流来担任。具体例子：在现实的软件系统中可能存在一个主数据库/数据中心，若干分数 据库/数据中心，系统在每过一定时间进行数据上传/下载，为了进行数据合并和控制数据的修改，应该每个分数据中心只能处理修改自己的数据，可以查询总数据 中心/其他分数据中心的数据。如果没有引入数据来源管理（数据属地管理）和数据版本的控制机制，不知道系统在作数据中心合并会怎样子？
1.数据项的分类编码
数据项的分类编码，实际上是数据项来源管理的一个具体延伸。数据项编码的目的就是更快更好的识别数据代表的业务意思。一个典型的例子就是ERP中的BOM表（基本物料清单）。
数据项的分类编码，不只是在系统模型建立上有指导意义，在进入系统的业务数据的规范化同样有指导意义。
数据项的业务编码和系统编码分离。业务编码很多时候只是为了识别业务数据的需要，很难保证业务数据的唯一性要求。而且业务编码可能会发生变动，有些单位的总体规划从调研到讨论制订、到项目审批通过，再到最终实施，常常几年过去了，需求发生变化，这种编码规则不发生变动几乎不可能。2000年我参与的一个企业软件系统，就一个产品编码规则2个月就发生了5次变动。从更长的时间范围内来说，应该考虑数据产生时期问题，不同时间阶段产生的业务数据，使用的业务规则不一样，数据编码这个层次很多时候很难识别 数据当时的业务环境。
以一个简单的例子来说明：
业务数据表的primary key系统应该是系统定义的，而数据项的业务编码只能作为索引或者备用键使用，这样就减少了数据业务编码规则的变动对系统影响减少到更小的程度。
2.算法的版本化
本来我打算在前面的基础上，再谈一下业务流程的管理设置问题，不过，现在工作流思想深入人心，我也就跳过了。我打算从数据的核心业务处理，算法处理角度来阐述。
其实在现实中的软件项目中，大家提到的较多的BPR,工作流这些东西，但是很少提到算法这个单词。当然，不可否认，很多软件项目，特别是电子政务/OA的 业务主要是体现在流程/文件上，算法这部分比较简单（当然，我这样说，有人可能不认可，暂且就不争论它了），就没有必要去强调算法的重要性了。
为了避免垃圾数据进入系统，垃圾数据出来，有必要对数据进行分类管理。正如前面提到的那样，对于进入系统的数据，进行信任等级划分，
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
