不动产交易登记行业信息化建设构架的探讨.docVIP

不动产交易登记行业信息化建设构架的探讨 　　探讨不动产登记行业信息化建设构架，应该先说核心业务那一层，因为任何行业的信息系统建设，首先需要的是核心业务，没有核心业务系统，就没法办理业务。我们的行业信息化涉及四类核心业务：房地产交易、不动产登记、不动产客体管理、档案管理。 　　这四类核心业务应该分别建设各自的业务系统，并且分清系统边界，系统间的交互通过接口来完成，而非通过耦合业务来完成。举个例子：客体的现状调查结果和权属登记结论存在差异的，我们不能因此拒绝受理新的登记，因为两者的业务是不相关的，登记依据的是登记簿的现势情况。信息可以互通，但业务不能耦合。 　　核心业务系统解决的是主干业务需求，应该设计得轻量化，目的是稳定。轻量是指这些系统的功能应该简洁，简洁到基本业务能够办理就够了。比如不动产登记这个核心系统，我们可以只设计一个登记簿的功能，最多加上“受审缮发”，这四类业务有明确规定的流程。搞机械设计的朋友们知道，机械原理越简单的东西，越不容易出现故障，越稳定。镰刀的故障率大大低于联合收割机，信息系统也是这样。 　　客体管理系统也是本行业的核心系统，需要独立于交易、登记系统建设。这在交易和登记职能分设的地区尤为突出，住建部门建一套楼盘表，登记部门再建一套楼盘表，这样会出现数据一致性的问题，而且也会增加维护楼盘的工作量。把权属调查、现状调查、客体备注信息，甚至是基础地理要素都放在客体管理系统里，交易、登记系统分别使用它，这样就能解决这个问题。 　　我们还需要一些基础手段来支撑核心业务，就是图1最下面那一层。 　　比如身份认证，它应该是一套通用的系统，不但可以为登记系统的面签提供身份认定服务，还可以为档案系统的依申请查询提供身份认证服务。这一层的信息系统其实是工具，为别的系统提供基础服务的工具。 　　核心业务系统解决的是“能办完”，但要“办得好”，则需要对办理行为和管理行为进行研究。我们在核心业务系统之外设计了一组关于“办事事务”的系统，这些系统都是为了提升用户体验，提升便捷化程度，改进管理效率，落实“放管服”精神。 　　这里面起码包含了三项内容： 　　第一项内容是办事资料的流转。无论一件事涉及到多少核心业务，办事资料应该整合为一套，这样才能实现一次性告知。对于一些办事人要求的进度查询来说，资料的流转信息要比核心业务流程信息更准确。比如：对于领件人来说，权证资料流转到发证前台这个物理位置的时间，要比登记系统缮证完成的时间更有意义。 　　第二项内容是办事事务服务。办事人的一个诉求，可能涉及到不同的核心业务，比如权证遗失后的补发，这需要权利情况证明，然后再进行登记。这是一件事情，但涉及到了登记和档案两项核心业务，有时还会加上房屋客体的数据纠正，就有三项核心业务，所以要提高办事人的体验，就必须兼顾它们。我们可以给一件办事诉求编制一个“事务号”，用它来挂接所有的核心业务，形成整件事的总线：办事人可以通过“事务号”了解整件事的导向，比如他的事项涉及到了档案、登记，甚至涉及到了公证、民政；经办人可以在事务号上记载各个环节的特殊情况，比如何时通知了办事人补齐资料，某办事人的登记案件能享受房交会期间的税费减免优惠，等等；管理者可以通过事务信息分析服务对象的行为辅助决策。 　　第三项内容是关于服务对象的。这需要先搞清楚信息的归属问题。我们这个行业有很多信息系统，那么这些信息是属于谁的？最开始的时候是属于政府的，办事人需要信息，要到政府来查，信息的提取是很麻烦的，可能还需要审批；后来提倡服务意识，政府转变观念，为办事人服务，方便地提供信息给办事人，但这时信息的归属还是政府的；将来我们应该把信息变成办事人自己的，事实上很多信息的确是办事人自己的，比如权利人，权利人本来就有房，那么房屋信息是属于他自己的，他需要这些信息的时候，登记机构只是配合查询，所以我们以前叫“房屋权利证明”，而现在叫“房屋信息查询结果”。我们建设服务对象系统，是为了把本来就属于他的信息进行归户，查询结果应该在登簿完成后就归户生成到权利人名下，这样就不会纠结于房屋在曾经某个时点的查询了。同理，房屋也应该归户在权利人名下，权利人可以通过信息手段进行房屋核验，信息系统只是配合他的操作，如果社会对房源核验信息不认同，可以向登记机构核实，登记机构进行确认，而不是让办事人跑来打证明。在明确服务对象时，针对自然人我们可以借助身份识别手段，针对机构可以联系税务、工商进行资质认证，这就是信息互通层面的工作了。 　　信息互通层是建立在?炔肯低秤胪獠咳肟谥?间的一系列系统，主要解决两个问题：一是数据是能够交互的，二是数据交互是安全的。关于数据交互的内容很好理解，就不多探讨了。 　　下面谈谈我们这个行业的入口。我们有三类入口：线下的，线上的，部门间共享的。 　　线下入口包括了交易