在所有的软件系统里面，最多的是信息管理系统；最难的，也是信息管理系统。
这里说的信息管理系统，远不止进销存、MIS、HIS、MRP、ERP 和 CRM， 凡是涉及到以数据和信息为内容的，对数据和信息进行管理、处理和展现的，都是我们所说的信息管理系统。
如何做好信息管理系统，是所有软件公司和软件人员最头痛的。最大的难度在于如何满足客户不断变化和发展的需求。事实上，这些需求在项目开始阶段，客户并不能给出完整和准确的阐述，加上软件公司软件人员对客户端的业务本身并不熟悉，那应对这种情况，该怎么去开发软件？
这篇文章是我给技术人员上的一堂课，也是我多年在应用软件开发的实践积累、研究和提炼。这堂课的学费可值一万元，能在这里分享给大家，当然是国总为大家买单啦。如果对这堂课无动于衷，或者听不懂，那国总这个一万元的学费就算白交了；如果这堂课听进去了，学员就赚了，这个值五万；如果这堂课不仅听进去了，而且还能理解和消化，那就值十万。如果能把这堂课运用起来，那就值五十万，甚至更多。
这堂课，我不会用传统的方法去讲什么需求、功能、界面，我会用一个全新的方法，告诉大家怎么去做好一个数据和信息的管理系统，这个方法就是“组织”。
关于证明
我们说一个发生在我们身边的例子。我们国家的深化改革，从政治、国防、经济、科技等领域，渗入到政府职能部门的管理简化。过去的我们可能随时都要去办理一堆证明，去证明你是你自己。现在这些事情已经逐渐在改观，我们需要办理的证明会越来越少。
我们先来看看这幅图
实际上，公安户籍的系统里保存了每家每户每人的户口信息；民政局记录了每个人的婚丧嫁娶信息；房管局保存了谁卖了什么房的信息；人事局也掌管着每个人的工作调动、调进调出的调令；出入境管理局给我们发放护照，记录着每个人的出入境情况。
那么为何要我们办这么多证明？只是因为没有信息共享吗？把这些信息合并在一起，不就是信息共享了吗？把这些数据从不同的存放地方，放到一起很简单，但是放到一起，又能怎么样呢？
回顾我们自己曾经做过的信息管理系统，所有的信息数据，不也都在我们自己设计的数据库里面吗？可是我们还是很难把软件做好。实际上并不是数据在哪里的问题，也不是信息能不能共享的问题。
信息系统的要素
要做好一个数据与信息管理系统（以下都称为管理系统），最重要的是要弄清楚，这个系统应该用什么方法去构建，而这个方法必须是科学有效的。
实际上，一个信息系统的构成，有五个要素：元素、组织、逻辑、模板、和蓝图。剩下就是三个具体的问题：如何去构建这些要素、如何处理要素之间的关系以及如何运用好这些要素。
元素
元素就是管理系统要处理的对象，很显然，就是我们的数据和信息。具体来说，可以是一个数据库里面的数据表（比如我们前面提到的户籍信息数据表、婚姻登记登记表），也可以是一些随时会产生的数据（比如出入境信息）。
对于元素，不用纠结它到底应该是什么，我们只需要明确两点：这些元素所在的和保存的位置（如某个数据库的某个表），或者是这些数据来自什么地方（比如，通过某个接口，通过某个数据推送，通过某个实时同步/异步的数据交换）。一句话，只要是管理系统需要涉及的，且需要去管理的东西，都是元素，关键还要明白这些数据是怎么触碰得到。
我们用一个公司人力资源管理的例子来说明这五个要素。
企业人力资源的管理，首先一定是要有公司员工的花名册，这实际上是一个数据库的表，我们给它起个名字，叫 “元素A －－ 职员信息表”。这个表，就是我们的一个元素。这个表中，有很多字段，比如：姓名、出生年月日、性别、入职时间、任职部门、职务、工资，还有一个在职状态（在职或者离职），当然也少不了填表的日期时间。这些我们称为这个元素的属性。
这是我们的第一个元素。这个元素，我们可以想象成这样的场景：我们印刷了厚厚一摞《职员信息表》，来一个新员工，我们就取一张，填一份。
那么，A－－职员信息表，就是管理系统的一个元素。这个元素，当然可以保存在关系数据库（MySQL）里面。关于数据库怎么建表等，这个应该是大家非常熟悉的，我们就不再这边讨论。
组织
所谓组织，就是按某个规则，把元素组织到一起。我们可以把组织理解为一个活页夹，这个活页夹需要有五个关键点：组织的名字、范围、条件、排序和逻辑。
我们可以看到这里的“组织”，就是把所有填好的员工信息表，按“年龄”分类放到这个活页夹里面。
这个组织的作用，就是方便我们快速掌握公司所有员工的信息表。因此，组织存在的目的，是为了解决我们某个特定的需求。
为了管理方便，我们需要设计另一个组织：
名字：公司管理层
范围：员工信息表
条件：职务 = 经理
排序：按年龄
逻辑：暂无
这个组织，是为了让我们更容易掌握公司管理层的基本情况。
以此类推，我们可以弄出来很多组织：
我们需要强调的是，元素被放到组织里面，是一种“影射”关系，简单说，张三的这张表，被放到某个组织的，只是一个复印件，原件还在原来的地方。而这个原件，可以被无限制地复印。
公司除了员工信息表外，还有很多，比如：
这个是好理解的。经过一段时间，我们已经收集到很多这样的信息。那问题来了：如果我们想知道员工张三各方面的情况，怎么办？如何去一览无余就知道呢？很显然，我们做不到。我们只能这样做：
我们的管理系统，通常都是这样做的。尽管我们的管理系统不缺乏所有的功能，但是看上去却是十分别扭。
我们可以在单个元素上建立组织，如《全部员工信息》、《2015年工作总结》、《去年体检报告》、《上一年度考核》、《最近三个月人员岗位调动》、《今年离职》，我们也可以在多个元素上建立组织，比如：
这个组织的五要素分别是：
名字：王五档案
范围：员工信息表、工作总结、部门鉴定、年度考核、体检报告、调令、离职通告
条件：姓名 = 王五
排序：职员信息表第一个，其他按填表日期
逻辑：暂无
我们当然也可以给张三和李四都建立各自的档案，这个很容易，因为只是条件不一样，其他的都一样。
我们可以看到，还是这个组织，只要条件改成 “姓名 = 张三”，肯定就是《张三档案》了。一个组织是很容易被重复 “引用”的，如果在引用时改变条件，就变成了另一个组织，但是无论条件怎么变化，这种组织的含义是相同的，只是内容不同。这类组织，我们称为 “同类组织”。
我们后面会讲到更多关于组织的内容。这里我们先说一个关于组织非常重要的概念：组织一旦形成（创建），组织里面的内容一定是确定且有限的。换句话说，假如某些信息我们是未知的，不确定的，我们是不能创建一个组织，把这些内容装进去，这个我们后面会解释为什么。比如，《王五档案》这个组织，一定是王五本人的档案；《张三档案》也只能有张三的信息，并且档案里面有多少内容一定是确定的，可以数得过来的，哪怕再多，也不会是无穷大。
假如我们把组织，对应成关系数据库的物理表，那么，组织实际上就是带有条件的多表视图，加上排序。如何创建视图，我们就不在这讨论了。
逻辑
组织一旦形成，我们是可以给组织创建逻辑的。假设我们有了《王五档案》这个组织。某一天，一纸 “调令” 把王五从行政部经理调去上海分公司，担任分公司总经理，工资也加了1000元。
首先，这张调令一旦出现，自然就放到《王五档案》这个组织里面（因为这个组织的范围就包括了调令）。这个时候问题来了，当调令出现，王五的 “部门” 和 “工资” 都发生了变化。假设还有一个组织涉及到王五，比如《行政部》。那么调令来了，会怎么样呢？正确的答案当然是：一旦调令来了，
①员工信息表，要重新填一张，部门和工资需要修改，其他不变；
②《行政部》这个组织里面，已经容不下王五了，她必须去《上海分公司》这个组织，如果这样组织有的话。
这里特别要注意的是，员工信息表，不是“修改”，而是“重新填”。原来的员工信息表，已经成为了历史，而历史是不能被篡改的，只能记住。
我们千万要注意，逻辑一定是组织里的逻辑。即便发出了一百张张三的调令，对王五也不会有半点影响，因为这个不是发生在《王五档案》里面的事情。现在不难理解，假如我们有 “调薪通知”，那么这个逻辑是，重新创建员工信息，工资=调薪通知.新工资。一个组织可以有多个逻辑并存。
逻辑有哪些特性呢？我们来总结一下：
①逻辑必须是某一个组织的逻辑，并且是以组织为基础，没有组织的逻辑是不存在的；
②一个组织里面，可以同时存在多个逻辑，他们都具有同样的优先级；
③逻辑的条件是元素，但结果可以是元素，但是也可以是别的；
那么，新的问题来了，现在有两个 “职员基本信息”，那我们应该怎么去标识和区分呢？这个实际上并不是难题，我们通过给这个元素增加一个属性就可以了，这个属性，用来说明“当前” 还是 “历史”。
我们还是用刚才王五的例子来说明。当 “调令” 来的时候，“职员基本信息” 出现了新老两个版本，但是这两个版本，都同时在《王五档案》这个组织里面。这个是合理的做法，因为档案本身就是要反映，王五在公司里面的每个变化和成长成熟过程。用一句专业术语，这是一个非常合理的 “准确和完整描述某个特定信息对象生命周期” 的方法。
说到这里，我们需要说一下关于 “组织” 的两个概念，叫Open和Close：这是两个动作，同时也是两个状态。
Open，就是组织的开始
从刚才的例子里面我们看到，我们要建立《王五档案》这个组织，少不了职员基本信息表，如果少了基本信息表，这个档案很显然就是一个严重不完整的档案。我们换个角度来说，假设我们设计了一个 “针对每个员工档案的组织”，那么，《王五档案》什么时候算有了呢？应该是何时我们填了第一个 “职员基本信息表” ，何时就可以宣告王五的档案这个组织就算是正式创建了。这个可以理解为，我们拿出来了一个新的文件夹，文件夹的封面我们写上《王五档案》，并把第一张填写好王五的职员基本信息放进去。
Close，就是组织的结束
假设我们收到一个王五的离职通告，这个时候，《王五档案》里面除了多一张离职通告以外，其实还多了一张新版本的职员基本信息表，这张表的在职状态就被改成了“离职”。从这时开始，《王五档案》就不会再有新的东西增加了。我们可以把王五的档案关闭，封存。也许这个档案需要传递给王五的下一个工作单位呢？这个时候，我们就可以Close《王五档案》。这个档案被关闭之后，如果人事部门再发出什么调薪通告调令之类的，那就是个笑话了。
我们总结一下，《王五档案》从填写好王五的职员基本信息表时候起 Open；而从出现王五的离职通告起 Close。这个也是组织逻辑的一项内容，我们称为 File Open / File Close 逻辑。
我们回顾之前说的一个组织《全部职员档案》。来了王五调令后，这个组织增加了一个王五的基本信息表；又来了王五离职通告，这个组织又增加了一个王五基本信息表。请注意，这三个表，有两个表是“历史”，只有一个是“当前”。而“当前”版本的基本信息表中，王五的状态，已经是“离职”。
为了避免人事部门乌龙，再给已经离职的王五调薪，实际上很简单，我们设计一个组织《在职员工》让他们用，别让他们去用《全部职员信息》， 这样就不会出错了：
名字：在职员工
范围：员工信息表
条件：在职状态 = 在职，版本=当前
排序：按填表日期
逻辑：暂无
到现在，我们有必要再强调和梳理逻辑这个概念。逻辑，是元素之间的相互关联和影响，并不是组织之间的关联和影响。比如，出现了王五的调令，就要重新填写（不是更新）王五的基本信息，这里的调令和基本信息，都是元素，他们可能是关系数据库中的物理表，也可能是啥别的。如果没有《王五档案》这个组织的存在，调令就只能是调令，信息表就是信息表。
刚才的例子里面，让我们清楚了“版本”这个概念。版本实际上是一个属性，说明是历史还是现在。我们当然也可以用其他方式来处理现在和历史的问题，比如，用 Revision（修改号），最大的号就是现在的。
我们可能又要面对新的问题。人力资源部门出台了新格式的职员基本信息表。这也许是信息管理系统最怕遇到的，但是又不得不遇到的问题。试试看，不用组织而要想能解决好这个问题，估计不太容易。
一旦“职员基本信息表” 出了新格式，该怎么办？其实很简单，我们重新印一摞新表，再把旧表收起来，下次填表的时候，就填新表。这个表，还是叫“职员基本信息表”，填好了，该放到哪个组织，还是放到哪个组织，之前咋办，现在还是咋办。
怎么在软件里面去实现，可以通过很多办法。如果是关系数据库，我们就设计新的表。仅仅需要去调整组织设计，把组织的范围进行修改，把范围扩大到新表， 其他的都不会变。大家要注意的是，一旦某个元素启用替代的新版本，原有的元素应该就不会再有新的信息实例产生，之前产生过的，有多少算多少，都是有限的。
到这里，我们应该理解信息系统要处理的信息对象，“过去”是元素，而 “现在”应该是组织。我们先讨论另一个组织的要素：
模板
所谓模板，就是元素或者组织的呈现形式。这里说的呈现，可以是读（看），也可以是写（填）。元素模板可以同时有读写模板，而组织只能有读模板。
这个看上去没有什么问题。简单的说，如果要根据某个元素去创建信息，我们需要设计一个样式。我们可以理解为，我们印出来的一摞表格的样子。
模板跟元素之间有何关系呢？刚才的图示只描述了一个简单的关系，一个数据表对应一个模板，这个当然没错。事实上，模板跟元素的关系是灵活的，并非必须一一对应。一个模板可以对应多个元素；一个元素也可以对应多个模板。这个的规划和设计，完全取决于实际的情况。
我们还是以职员基本信息表为例，我们当然可以逐项填写。但是，如果我们有身份证读卡器，就可以做成两个模板。
所以，模板可以是一个UI、表单，还可以是别的，也许是一个数据接口和处理接口的一段程序。这是一个元素对应多个模板的情况。
多个元素对应一个模板，也是经常会用到的。在我们需要手工输入信息的时候，我们可以设计一个模板，一次性输入。但是，在提交保存的时候，同时被保存到多个元素的信息实例。
元素与模板的对应，总的来说还是简单的。究竟是一对一也好，一对多、多对一也罢，这些我们都是熟悉的。而比较复杂的是模板与组织的关系。要说清楚这个问题，首先要理解一个非常重要的概念，就是 “组织与组织” 之间的关联。
我们一直在强调一个理念：信息管理系统所管理的信息对象，是组织，而不是元素，当然，组织可以是基于单个元素的组织。这样做的目的，是为了方便我们用一个灵活和统一的方法，对信息对象进行合理描述和展现。
在说明与组织的关系之前，我们还是要来澄清和加深理解几个概念：元素和元素实例，组织和组织实例。
元素实例来自于元素的设计，是一个具体化的元素，我们可以理解为是关系数据库某个表中一个具体的记录（如王五的基本信息）；组织的实例，也是来自于组织的设计，是一个具体化的组织（如王五档案），组织里面包含的是元素的实例，这些实例可能来自一个或多个元素设计。
我们还要牢记一个最重要的理念，就是改变我们以往对信息管理系统的做法。我们要关心的信息对象，不是元素实例，而是组织实例。即便是元素，我们也是把它装在一个组织里面。
我们还是以刚才的例子来说明组织与组织之间的关系。首先，我们构建一个组织，叫《在职员工》，这个组织来自 “职员基本信息”，里面的内容是当前所有在职的公司员工。
我们可以这样理解，这个组织里面，我们只选择了在职员工的名字和所在部门，并没有包括很多其他细节信息。
现在，我们可以感觉到，组织的设计并不是照葫芦画瓢，而是对元素进行提炼。这就是我们所说的 “摘要”。哦，我们恍然大悟，原来组织包含的信息，实际上是元素的摘要。这个摘要，我们称为 “组织项”。
我们再构建一个组织，叫《档案》，里面的实例，就是《张三档案》、《李四档案》和《王五档案》，我们在这个层次把内容展开。
这个组织，我们前面已经出现过很多次了，应该很熟悉了。这是一个包含多元素的组织。我们应该已经注意到这个组织里面包括的具体内容，实际上也是这些元素的摘要。每一个摘要，实际上是对应一个元素的实例。
我们现在做一个图，综合一下我们上面讲的内容。为了我们后面的叙述方便，我们不再去区分元素设计和元素实例，也不再区分组织设计和组织实例。
从这个图上我们可以看到组织与组织，组织与元素之间的关系。第一个关系是，一个组织的组织项，可以对应另一个组织；第二个关系是，一个组织的组织项，也可以对应于一个元素（实例）。
组织项实际上并不是一个新的概念，但是我们放在这个地方才引入，是因为到现在为止，我们已经理解了组织的含义，在这里我们只是把组织里面的内容，更加具体化了。其实，这是我们用来展现组织的一个模板。我们当然可以用其他的方式，比如，一股脑全部挨个儿都显示出来，但这其实是不合理和没有必要的。
通常，我们用组织项去展现组织的内容；而组织项，就是元素的摘要。
我们从头到尾始终没有去讲解怎么利用关系数据库去实现组织，这是因为完全没有这个必要。只要理解了，无论用什么方法，实现起来都不会是一个问题。
其实，任何信息管理系统是不复杂的，但在现实中，我们的软件设计人员感觉到复杂，使用的人更感觉到复杂，是因为我们没有采用恰当的方法来做，这样导致的结果，就是在滚雪球，越滚越大，越滚越不知道要去解决什么问题。
下期我们会用一个专业商务旅行服务公司的信息管理系统为案例，仔细说明我们应该怎样用组织的方式去实现一个非常复杂的业务系统。请继续关注“智物联”哦~
