物业管理系统技术方案软件架构.docx
《物业管理系统技术方案软件架构.docx》由会员分享，可在线阅读，更多相关《物业管理系统技术方案软件架构.docx（26页珍藏版）》请在冰豆网上搜索。
物业管理系统技术方案软件架构
物业管理信息服务系统
方案建议书
图目录
第1章建设原则
§1.1建设原则
§1.1.1信息沉淀原则
由于系统容量、运行效率等原因，收费系统不可能长久保存所有历史数据；而为了准确统计分析、预测住户及商户入住的实际情况，管理过程中所积累的历史数据却是收费信息产生的基础。
所以，实现操作数据与经营数据的分离：
收费系统视本身情况，周期地备份并清理历史数据；而后则必须将从生成系统中获得的基础数据进行重新组织、存储、管理、使用，沉淀、融合各个收费系统的操作型数据，形成面向统计分析应用的经营信息。
§1.1.2按照业务数据的本质特征组织数据的原则
市场环境变化的经常性导致市场应对策略的变化也是持续不断的，因此，对收费系统的要求也存在着变化。
为了保持系统的稳定性，收费信息的组织结构应该按照业务数据的本质特征进行设计，以适应市场经营对于经营信息要求的变化。
§1.1.3多粒度原则
统计分析型应用所需的经营信息不是来自于生产系统的最低粒度的数据，而是面向各种不同应用的不同粒度的综合数据，所以，为了方便灵活地使用收费信息，需要对来自收费功能产生的操作型数据进行不同程度的综合，形成多粒度数据，多粒度原则是经营信息组织的一个重要原则。
§1.1.4统一经营信息集中服务原则
按照业务数据的本质特征组织数据的原则生成收费信息数据仓库，使收费信息从具体的收费操作系统中独立出来，并采用规范的收费信息访问接口为各种统计分析应用系统提供统一、一致的收费信息数据源，避免了数据仓库的重复建设，降低了系统投资，而且还保证了对外提供收费信息的一致性和准确性。
§1.1.5标准化和规范化原则
本系统的建设首先要规范系统体系结构和软件体系结构；其次要规范收费信息数据仓库的信息模型；最后要规范收费信息的格式、内容及收费信息的传输方式。
§1.2技术原则
§1.2.1数据的可靠性
为保证物业收费信息服务子系统统计结果的真实可靠，从数据源获取的数据必须真实可靠，宁缺毋滥。
§1.2.2数据的完整性
为保证系统的统计的完整性，数据源提供的数据必须完整，原则上所有的数据属性都应该齐全，或至少对于目前不能获得的数据能有一个缺省值。
§1.2.3数据的一致性
数据的一致性对物业公司建立收费信息管理系统而言相当重要。
否则的话，可能会为一个相同的住户建立很多条记录，也完全有可能为两个不同的住户只建了一个记录。
这样，就可能会给一个住户发很多份相同的催缴通知或另一部分住户漏发了催缴通知。
这都是我们应该避免的，物业管理公司很可能会因为这些小小的漏洞而失去大量的应收款项。
原则上，物业收费信息服务子系统数据仓库是建立在统一的住户资料基础上。
也就是说，必须将各分管处提供客户编码和客户信息进行确认，将客户资料统一，保证数据的一致性。
§1.2.4数据的可用性
应该首先明确哪些数据是物业收费信息服务子系统使用者所关心的，又如何充分地加以利用。
为使系统能正确理解数据的意义，物业收费信息服务子系统数据仓库还必须提供完备的元信息，以保证数据的可用性。
§1.2.5数据的精确性
数据仓库系统提供的数据应该具有较高的精确性。
一般对于十进制数据，要求精确到小数点后两位，对于住房面积长应该精确到小数点后两位，对于描述性的文字原则上也应该有精准的含义。
§1.2.6数据的规范性
数据的规范性要求数据按照一定格式存储。
物业收费信息服务子系统数据仓库中包括客户资料、统计数据等大量的文本信息，如果这些庞大的文本信息不具有一定的规范性是很难进行查询和分析的。
§1.2.7数据的时效性
为分析历史记录和通过历史记录进行预收预测，原则上仓库数据应该提供现今的数据，以及10-15年或更持久的历史数据。
§1.2.8数据更新的及时性
为了随时保持物业收费信息服务子系统中数据的有效性和时效性，对数据进行及时更新非常必要。
更新周期应该考虑的因素包括：
各数据来源的保存周期、预测分析周期、各项业务服务的特点、硬件系统的存储性能等等。
综合上述各因素，为了给统计者提供及时而有效的统计支持，最好是能够每天定时进行更新，如果系统经常忙于响应各种查询，则可选择每周更新一次或两次。
一般说来，报表数据的更新时间<3分钟；数据抽取、转换、入库的时间应少于在线事务处理休息时间。
§1.2.9响应的及时性
响应的及时性是决定使用者对系统所提供的服务与支持是否满意的一个重要衡量指标。
能否做到“有求必应”是一个关键。
可能影响响应及时性的因素很多，包括查询的复杂度、系统处理能力、软硬件配置等。
一般说来，用户查询的响应时间应<15秒。
§1.2.10安全性
确切地讲，物业收费信息服务子系统是一个完整的管理流程，涉及物业管理公司的各级领导和收费人员及多个环节和部门。
因此，严格地限定各级使用者的访问权限和操作权限对于保证系统的正常运行非常重要。
§1.2.11易用性
在不影响领导正常思维方式的前提下，物业收费信息服务子系统应尽量提高系统的易用性和友好性。
§1.2.12统计结果的可理解性
统计结果的可理解性不仅是指在形式上给出直观、可视化的OLAP及数据挖掘分析结果，而且在内容上应该针对具体业务和服务给出各种方法的性能比较，给予决策者以充分选择的余地。
经常采用的形式是图示和列表的方法，如柱状图、饼状图、散点图、折线图等等。
§1.2.13扩展性和灵活性
系统使用者的需求和系统的规模可能会随着时间的推移而发生变化，物业收费信息服务子系统的扩展性是不容忽视的一个问题。
例如，系统应该具有一个可由使用者自定义的统计功能接口，以便使用者可灵活地实现报表内容和种类方面的扩展。
第2章整体的物业管理信息化规划建议
§2.1物业管理一体化规划方案
整个系统由来自与客户和市场的需求信息和反馈系统所驱动，通过客户服务层将各种类型信息的统一传达至业务处理层处理，处理结果再及时反馈回客户服务层。
其间涉及各种环节的协调、控制、信息的调度，通过后台强大的服务程序支持。
1、物业管理一体化规划方案的核心理念
如何通过新的信息技术使物业管理公司能够为用户提供优质高效的服务，如何使物业公司通过新的技术降低物业管理成本，提高经济效益，如何通过拓宽物业信息系统的范围，为物业公司带来更大的竞争力已经成为物业管理公司物业管理系统建设的首要问题。
因此，物业收费管理信息系统的建设必须以市场和客户服务为轴心，以方便客户为宗旨，优化重组业务流程，创新服务方式，强化监管能力，提高物业公司决策和管理水平。
通过各种方式提高服务质量，提高物业费用收入回收率为物业公司创造更好的社会效益和经济效益成为物业管理收费信息系统的核心理念。
二、物业管理一体化规划方案的基本概念
在上述核心理念的指导下，物业管理信息系统也随着其服务客体的职能体系变化而增加了新的内涵。
物业管理一体化解决方案是指基于现代计算机与通信技术，将物业管理工作进行电子化管理的综合信息系统。
具备客户服务、营销业务处理、监督和管理、决策支持等功能，是促进物业管理服务创新、管理创新和技术创新的基础和重要保证。
在整个解决方案中其各个组成部分既相对独立又紧密联系，在系统建设过程中既要对系统的整体结构进行宏观勾画，对各层次的功能进行细致描述外，还要注意各个层次之间的信息交互、信息共享的技术实现，最终使之成为有机协调的物业管理管理信息系统。
三、物业管理一体化规划方案的功能体系
在进行物业管理系统的进一步规划之前，不管首先建设的是整个解决方案中的哪一部分，都必须首先明确物业管理信息系统的整体体系结构以及各个层次的关系，这样，不仅更有利于当前系统的具体方案的实施，而且对以后不同系统之间的集成、整合和协调工作都有重要的指导意义。
a）客户服务层是整个物业管理信息系统对外的“窗口”，在与客户沟通并为其提供各种服务的同时，负责收集客户的物业需求信息；商务化扩展功能层主要通过电子化商务手段直接面向市场，其具体技术实现方式包括物业公司网站及电子商务系统建设，银电实时联网工程实施等。
b）营销业务层和数据处理中心建立在客户服务层之上，负责对客户服务层获取的业务信息和客户需求信息进行处理，并将处理结果反馈给客户服务层，其主要内容基本上是传统物业管理信息包含的业务处理系统如：
业务扩展、收费、维修等。
c）营销工作质量管理层根据营销决策支持层的信息，负责对客户服务层和营销业务层的工作质量和工作流程进行监督、管理和评估，并及时将有关信息反馈给管理决策支持层。
d）营销管理决策支持层通过对营销业务层、客户服务层、营销工作质量管理层等信息流的应用和分析，提供管理依据和决策支持。
将决策信息下达给营销工作质量管理层、营销业务层和客户服务层。
§2.2物业管理业务之间的内在逻辑
从物业公司内部的运营体系来看，以企业管理者的角度来划分，物业管理的业务逻辑过程划可分为如图四个层次：
图3－1物业管理业务逻辑层次关系图
1、客户服务层：
在客户服务层中，采集所有的物业需求，并进行服务分类，发送到业务处理层，以工作任务的形式，通知营销业务层、营销工作质量管理层、营销管理决策支持层各营销部门。
同时客户服务层不断受到营销业务处理层、营销工作质量层和营销管理决策支持层的业务办理信息，政策信息。
主动与客户取得联系，并保证所有的服务请求都有回复。
例如：
一般的商铺、停车、维修申请信息，将申请业务基础数据发送到营销业务处理层，将任务列表发送到工作质量监督管理层，业务在营销业务处理部门办理，管理部门可通过工作监控功能，监督业务办理过程，改进办理流程。
将用户的市场需求进行分析汇总后，信息传递到营销决策支持层，企业的管理人员即可进行市场分析。
2、营销业务层
是进行各种物业服务的事务处理层次，直接为客户服务层提供服务支持。
在营销业务层中，将采集所有的营销基础数据，并根据业务处理的类型，对数据进行加工。
按照营销决策支持层制定的营销政策和营销工作质量管理层制定的业务规范标准，业务人员直接到现场服务物业客户，或将信息发送到客户服务层，由小区物管处统一答复客户。
将业务处理的信息，进行加工汇总后，为营销工作质量管理层提供总体信息，并开发基础数据，提供给管理者随时查询实时信息。
3、营销工作质量管理层
获取营销业务层进行营销业务结论信息，并根据工作监控，管理的需要，随时查询、汇总营销业务基础信息。
也可以直接与客户服务层进行数据交流，如：
客户投诉的处理，商铺、车位申请流程的督办。
管理营销业务规范和制定标准工作流程，制定营销业务工作计划。
4、营销决策支持层
营销决策支持层，总体管理物业管理系统，将营销客户层的客户信息，市场需求信息、营销工作质量管理层的物业服务工作绩效信息、以及从营销业务层的基础数据中抽抽取的营销指标信息，进行综合加工，进行市场分析、客户分析、需求分析，并将制定的营销政策、业务管理原则、市场开发指导信息发布到各层次。
传统物业信息系统都是以处理业务为核心，决策支持这一层的处理稍显薄弱，（所以业务处理层中大量采集和处理信息只在本次业务处理周期内有用，当业务处理完毕之后，大部分数据就被闲置在数据库中），高层管理需要高度概括的、动态分析的、综合比较的数据，从而实现领导对企业的监督、控制和战略意义上的管理。
在物业管理进入激烈的竞争环境时，这一功能是关键的、必不可少的。
所以目前的系统的建设重点处理进一步提升业务处理机制外还加强了对管理支持。
第3章系统建议方案
§3.1系统运行模式选择
针对目前物业管理公司经营的现状和未来的系统架构设想。
我们将讨论并对比适合于该应用系统构建的信息系统模式。
§3.1.1全集中方式
全集中方式的物业管理管理信息系统，即指设立一个数据中心，各小区管理处不设立任何数据存储设备，所有人员使用同一套应用软件。
请参见下图。
图4－1集中方式网络结构图
其主要特点是：
1、系统建设初期投入较大；
2、对网络环境要求高，特别是公司本部与各小区物管处之间的网络链路要高速可靠，否则集中无从谈起；
3、硬件平台可伸缩能力好，我们建议系统初始建设阶段使用支持多CPU并行处理的小型机，在系统性能不够时可以升级到处理能力更高的小型机；
4、系统可靠性高，由于其配置较高，故可能在可靠性方面给予充分的考虑，可以增加冗余部件及采取其他的高可靠性技术；
5、系统的软件使用许可费用低，仅仅一套软件使用许可即可，而不必购买多套软件使用许可；
6、应用系统集中后，统一的版本控制和软件分发，系统管理人员可减少，有效地降低了人力成本，即降低了系统的运行维护成本；
7、基于统一的业务运行机制，新业务的扩展可控性提高，应用可靠性增强。
全集中方式的数据环境下，信息的交互更容易，业务处理和跨级业务受理容易实现。
8、系统容错及容灾方案得以实现，单一集中的应用系统要比分散的多应用处理系统的容错及容灾容易实现。
§3.1.2部分集中方式
根据物业管理公司本部及下属小区管理处地理位置的特点和属地化管理的特点，还有一种方案是采用部分集中的方式，实质就是分布式应用方案。
根据实际情况，可将各个管理处与物业管理公司本部建成相互独立或部分集中的数据中心和应用中心。
参见下图。
图4－2部分集中方式网络结构图
部分集中的方式，主要考虑系统网络整体承受能力和属地化管理的实际需求。
这种方式的采用，并不利于从本质上解决目前信息在小区管理处之间流转负责，业务交错的问题。
尽管将来在上系统时采用了统一的业务规范和数据规范，并且使用相同的业务系统，分布式处理的问题依然存在。
其主要特点：
1、降低对主干网络的要求，远程小区管理工处的业务，主要使用本地的网络资源；
2、硬件投资首期较小，但总计投资比较大；
3、数据资源本地化管理，能降低集中方式的实施风险和管理风险，但本地管理的风险增加，例如：
对本地系统管理人员要求提高。
4、和本地化的客户收费服务分中心、维修分中心等管理方式融合，能突出本地化的服务特点，灵活地制定服务策略。
5、从物业管理的整体来看，业务系统的规则定义复杂度提高，例如：
如何保持规范数据的一致性，当各地系统的规范编码需要修改时，如何进行？
跨级业务处理流程如何定义双向的数据流转次序等等？
6、数据的存储、系统的容灾、备份投资增加，各管理处都必须有相应的存储设备、备份设备、备份管理。
全物业公司级的容灾方案不易实现。
§3.2系统总体架构设计
为满足物业管理公司5-10年内的物业管理业务发展需求，系统至少支持3万——5万住房（商铺用户）的各种新业务的物业费计算、帐务处理、业务处理和统计分析需要，并达到财务部门所述各项技术指标，系统总体架构设计主要依据以下设计原则：
交易的即时性：
随时向物业管理公司各层次业务人员及客户提供准确的、及时的信息。
可靠性及可用性：
能够连续8小时×5天不间断工作。
伸缩性：
作为覆盖各级单位的方案，既是统一规划又是分步实施的过程，这就要求系统从硬件到软件有很好的可伸缩性，必要时能够通过增加服务器的方式来达到处理能力的增强。
良好的性能：
物业管理公司基层单位业务处理终端通过不同的方式使用系统进行业务处理、管理分析，这就要求系统架构的设计能够保证必要的性能指标得到满足。
高安全性：
从用户认证、授权等访问安全性和备份、容灾等数据安全性等多方面来保证系统整体拥有高安全性。
开放性：
选用业界公认的、通行的软件标准，保证软件有较强的标准化、开放性和较好的可升级性，并使核心收费软件易于与将来各个子系统及一些现有系统进行接口。
§3.2.1软件体系结构
针对物业管理公司物业管理信息系统的特点，结合统一规划、分步实施的项目实施策略，基于以下原则进行设计：
1、作为大规模的企业级应用系统，以长远发展的眼光进行整体规划；
2、高起点地建设系统，注重其稳定性、安全性、先进性和高效性，其中安全性和稳定性永远是第一位的；
3、根据物业管理系统分布和各主要功能系统的应用模式，构建软件平台的层次，在横向和纵向上体现出高的可用性、可扩展性、可伸缩性和负载平衡能力；
4、由面向组件思想开发的应用功能组件是物业管理系统的主体，系统软件平台要对其形成便于管理、便于维护的运行环境，并保证对外各种接口的规范性和标准化。
我们认为，物业管理系统数据量大，数据处理方式多样（包含不同类型的搜索、事务处理、计算逻辑，单次处理针对的数据容量大或小），性能上要得到保证，就需要软件平台的结构能够确保为物业管理系统的信息和服务提供可用、可伸缩、快捷及高效的访问。
软件平台建设要解决的问题就是必须将等待时间和访问瓶颈降至最低程度，并最充分地利用构成基础结构的软硬件。
我们的解决方案是通过选择业界领先的联机事务处理（OLTP）中间件标准，在保证可扩展性和可升级能力的情况下，结合为物业管理公司物业管理系统开发的应用功能组件，将数据库端连接数、网络并发访问量控制在可接受的范围内。
将来可以通过多个应用服务器在各管理处间的合理布署，实现物理距离和访问量的优化，并且多个应用服务器软件实例在同一台机器或多台机器间的配置可以实现负载平衡和群集方式的高可用性。
多层架构物业收费系统软件体系结构示意图如下：
图4－3物业管理公司物业管理系统软件体系结构示意图
总体上来说，这是一个符合J2EE标准的多层体系结构，如图所示，软件体系体现为多个层次，分别是：
界面表现层、Web应用层、业务逻辑层、数据持久化层。
界面表现层直接面向系统使用者，运行于客户端计算机的浏览器上，通过HTML、Javascript实现。
因为界面表现层使用浏览器作为应用的容器，这种技术结构也称为B/S结构。
这种界面表现层具备如下优点：
◆实现客户端零安装，容易保证应用系统功能的一致性，也增加了系统的可维护性
◆自然具备WEB应用界面上的优点，界面美观、形态灵活、易于维护
◆便于不同应用基于界面层进行集成
Web应用层处于界面表现层的后面，一方面，由于浏览器客户端本身不带有任何业务应用程序，这一层需要为浏览器完成应用界面的创建工作；另一方面，这一层需要接收界面表现层的处理请求，调用业务逻辑层完成系统的业务逻辑。
这一层应用的主要技术形态是Servlet，Jsp。
业务逻辑层处于WEB应用层的后面，通过JavaBean（一般是EJB）封装应用系统的业务逻辑功能，完成Web应用层的调用请求。
通过把业务逻辑单独封装在这一层次中，使应用系统性能上具备高度的伸缩性，使应用系统业务逻辑独立于界面表现存在，使应用系统具备高度的开放性。
数据持久化层处于业务逻辑层的后面，持久化保存应用系统的业务数据，这一层一般通过大型关系数据库来实现。
经过多年发展，随着面向对象技术和J2EE标准的逐步成熟，这种多层结构的技术体系已经具备了高度的实用性，在应用开发、部署、运行各个方面，在如上各个技术层面上都具备了非常成熟的产品，能够充分保证系统开发的便捷，部署的灵活，运行的稳定，并已经产生了大量成功的应用案例，非常适合作为大型企业应用的技术架构。
§3.2.2硬件体系结构
硬件体系结构主要来配合应用总体规则及软件体系结构的需要，在这里，我们重点提出基于硬件的可伸缩性的方案建议：
图4－4可伸缩的主机系统部署方案
如图所示，主机系统主要用于部署数据库服务器、业务应用服务器、Web应用服
务器等，以响应来自客户端的访问请求。
主机系统的这些功用正是系统软件体系结构所要求的，可以根据情况将几种功用的服务器部署在同一主机（集群）中，或分层次地让它有多种部署方式。
根据系统运行后的业务交易情况，从物业管理公司到各管理处每一层次都可根据性能要求，通过增加同构的主机系统来增强系统的整体处理能力，分担中心的处理压力和网络传输的压力。
§3.3应用软件业务设计总体策略
从第3.2小节物业管理业务之间的内在逻辑分析，我们了解到物业管理公司在物业管理过程中，所有的管理对象只有一个——那就是“房屋客户”，物业管理信息系统就是帮助物业管理企业管理“房屋客户”的信息化平台和工具。
在物业管理公司物业管理信息系统中，按照以下三条原则进行业务系统的设计：
1、只要是物业管理公司管理的客户，都有全公司统一的用房客户档案信息规范，各业务部门按照权限操作专业数据，共享其他部门提供的信息。
2、以用房客户为业务处理的核心，所有业务处理围绕客户需求开展，业务功能组成和物业管理公司具体的岗位设置不直接相关，通过建立对应关系将业务功能发布到所有的操作人员；
3、业务处理过程跨越物业管理公司各级单位、跨越专业的流转，通过统一的工作流控制管理，各专业之间的数据交换通过数据流交互完成。
§3.3.1收费业务的核心管理对象——用房客户
§3.3.1.1统一规范的用房客户档案
系统将建立物业管理公司统一的编码规范，对“用房客户”及其相关属性进行标准统一，为用房客户建立一个唯一标识号。
“用房客户”首次进入系统时，启动入住业务流程，开始根据编码规范，为用户建立相关属性数据，参与流程各环节的专业部门，按照操作权限，将工作过程中形成的用户属性数据（例如：
房源信息、面积信息及收费计量信息等等）与用户的唯一标识建立起对应关系。
专业数据围绕“客户资源”展开，数据入口唯一，各物管专业数据保持一致，高度共享；
由于采用了全公司统一的用户标识方式和编码规范，各专业、各级单位对用户客户的操作有一致的工作语言，并且有相同的用户标识方式，只需按照管理规范约定的业务处理权限，对本部门、本专业的工作过程进行处理，即可共享用户信息，共同形成入住客户的初始档案。
§3.3.1.2稳定、可配置、可扩展的用户档案
由于系统的核心管理对象是“用房客户”，各专业业务开展均围绕基于“用户档案”的用房客户需求进行，用户档案本身的稳定性和灵活性，将直接关系到系统是否稳定并且能适应业务的变化，能适应不用管理层次、不同专业人员的需求。
我们可以用下图来表达整个系统的数据规划。
图4－7业务数据规划示意图
在图第1层和第2层，是物业管理对象用房客户的档案，基于用户核心档案，按照系统的数据编码规范，各专业基础数据与用户核心档案建立对应关系，共同组成用户档案。
在对用房客户的业务需求进行管理时，各项工作由专业部门根据本专业的管理指标对各项业务处理进行相应的监控和考核，处理过程产生的过程监控数据、流程控制数据以及用户在物业网络中的所有活动的记录，会构成用户档案的动态信息。
各专业部门可以根据本专业管理客户的角度，建立自己的数据逻辑，例如维修检查部门从房源角度对用户进行管理，物业费管理部门从应收物业费角度对用户进行管理，安保管理部门从用户的安保、停车角度对用户进行管理。
专业部门按照各部门的客户管理指标体系，形成多样的数据逻辑单元，对各类数据逻辑单元的操作组合即构成了各部门的业务功能模块。
§3.3.2以客户为核心、多角度专业化管理
物业管理公司已经从传统的“基于管理费收缴”的服务供应、资源销售企业逐步转为“基于客户需求”的服务创新供应、资源整合销售企业。
目前物业管理公司各管理处在物业管理中大量的注意力已逐渐转移到：
如何改善与客户的关系，为特定客户提供关怀服务解决方案，如何在现有资源条件下提供最吸引客户的资源使用方案（需求侧管理），保持最大的固有资源消费群体，开拓物业特色服务销售市场。
在目前物业管理公司各职能处所、各管理处使用的手工信息管理方法中，要执行以用房客户需求为基础的营销方案或者能适应将来部分开放的物管服务市场的营销方案是非常困难的，因为一个标准不一、条块分割、缺乏弹性的手工操作方法无法处理随着这种方案而来的改变，本次项目将实施的一个新的、单元化的、以主干为基础的物业管理管理信息系统，将使之适应未来物业管理的变化和物业管理市场的变化。
捷讯技术提供的的物业管理信息系统解决方案，全面采用“以客户为核心”的设计思想。
系统中的业务流程设计、数据流转控制、外派现场工作任务管理、营销管理监控、物业费现金流控制都源于客户各种类型的服务请求。
系统从设计上不受限于物业管理公司
升级会员 