企业管理的底层逻辑篇1
关键词：成本预算；信息系统；B/S；三层架构
1技术应用分析
在软件体系架构设计中，分层式体系架构最为常见，也是最重要的一种结构[1]。微软公司推荐的分层式体系架构一般分为三层[2]，依次为数据访问层（DaL）、业务逻辑层（BLL）、表示层（pRL），这样有利于系统的开发、维护、部署和扩展。如图1所示。
B/S系统三层架构是一种松散耦合结构[3]，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。
数据访问层：也被称作持久层，主要负责数据库的访问，即实现对数据表的Select，insert，Update，Delete的操作。数据访问层使得业务逻辑脱离了与具体数据库的依赖，使得整个数据访问层利于数据库迁移。
业务逻辑层：是整个系统的核心，它与整个系统的业务（领域）有关。它包含了整个系统的核心业务。业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。
表示层：是系统的Ui部分，负责使用者与整个系统之间的交互。在这一层中，理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码，仅与界面元素有关。
2系统设计
本系统的核心是成本预算管理，需要建立成本考核指标，逐级汇总各级单位部门成本支出情况，经审核确定整体预算。我们针对整个管理系统所要完成的目的，作出基本工作流程设计，如图2所示。
预算编制是成本预算管理信息系统的核心功能之一，负责进行年度预算的编制及相关的数据字典维护。经过对成本项目上报形式的分类，实现了对各项成本的分级管理，灵活、有效的控制主要成本的编制、运行过程，使得主要的成本支出项目不仅仅体现在数额，还能与实际生产联系起来，便于预算控制、领导决策。
预算控制负责对成整理本支出情况进行跟踪、控制，采集并记录实际生产经营过程中的成本支出数据，记录每笔业务的结算数据，为财务人员提供汇总、考核、分析的数据依据；对于生产经营过程中的某些业务，根据成本预算的实际消耗情况，对超支的成本项目进行预警，采取相应的措施进行控制、处理。
成本分析模块根据系统设计好的相关表格计算生成分析用报表，然后主管会计根据成本分析报表进行成本分析。
成本考核主要涉及生产任务执行情况、成本使用情况、管理效率等多方面指标，其数据来源于所有管理流程。
系统管理负责维护单位组织结构、系统功能模块、注册用户、岗位权限、电子印章等信息；负责管理资产设备、成本科目等基本数据字典。
3系统实现
系统后台使用oracle数据库进行数据存储管理，使用JaVa作为开发语言，采用B/S三层架构，划分出清晰的数据访问层、业务逻辑层以及表示层，层与层之间尽量实现弱耦合，降低它们之间的依赖关系。整个系统共划分成如表1所示项目进行编程实现。
数据访问层采用了“面向接口”的编程思想，并应用了工厂模式策略，首先以iDaL抽象出数据访问逻辑，脱离了与具体数据库的依赖。通过DaLFactory作为数据访问层对象的工厂，专门管理DaL对象的创建，便于业务逻辑层访问，使得业务逻辑层的访问模糊了底层数据库的类型，便于数据库的迁移。iDaL支持oracle数据库的oracleDaL具体实现，即oracleDaL模块实现了iDaL模块的接口，其包含的逻辑是对数据库的Select，insert，Update和Delete操作。同时iDaL为其他类型数据库如SQLServer、DB2预留了接口。model模块提供了数据访问层的数据对象，只包含了数据实体对象，并不包含任何的业务逻辑方法。
系统业务逻辑层的核心是BLL模块，它包含了成本预算系统的核心业务。在业务逻辑层中，不能直接访问数据库，而是通过数据访问层的iDaL来完成业务逻辑层与数据访问层的通信，并达到访问数据库的目的。在业务逻辑层中，涉及到数据访问层中数据对象的调用，采用了多态原理定义了抽象的接口类型，然后利用工厂对象的工厂方法创建具体的数据对象。为了适应业务扩展与需求变更，在业务逻辑层建立一个专门的接口模块iBLL，用以定义业务对象的接口。通过“依赖注入”方式，解除与具体领域对象类的依赖，使得表示层仅依赖于业务逻辑层的接口程序集以及工厂模块。通过引入接口模块iBLL，解除了与具体模块BLL的依赖关系，为与表示层的通信提供了弱依赖的基础。
表示层的实现全部在web包下，通过引入接口模块iBLL工厂模块BLLFactory，解除了与具体模块BLL的强依赖关系。
4测试
根据实际的系统使用场景制定本次测试的性能目标：对胜采集团成本预算管理系统在30分钟内完成2000次用户系统登录，选择对系统预算控制测试，最后退出系统，在对系统的业务操作过程中页面的响应时间小于3秒，并且服务器的CpU与内存使用率不超过75%。
我们从并发数、响应时间、每秒点击数、业务成功率、系统资源、等几个方面对系统的性能加以测试分析，测试步骤如图3所示：
根据测试结果，本系统的性能达到了预期的目标，最新的测试结果记录表如表2所示：
5结束语
企业管理的底层逻辑篇2
在目前大量流行的管理类书籍中，中国致公出社出版的《管理管理者》是一本西方原汁原味的关于管理教练技术的著作，它的关键词是“领导力”，其副标题——“为什么管理活该被抛弃”，则用一个近乎悖论的形式提醒我们思考：“如果实施了领导力，那么现在的管理工作应该是什么样的?”本书从奥巴马竞选小组开始谈起，一个没有经理，没有等级区分的团队最后大获成功的奥秘在哪里?作者指出被采访者不约而同地谈的三个要素分别是：共同的愿景、共同的定位、共同的价值观。作者因此提出了a型企业和β型企业的区分。α型企业是指建立在传统的等级制或科层制基础上的企业，在该企业中，处于金字塔顶层的管理者是唯一决策者，其他层级的管理者和处于底层的执行者通常都必须按照所获得的信息开展行动并反馈行动信息；D型企业是建立在现代的扁平式或网络式组织架构上的企业，在该企业中，每一个管理者和执行者都是决策者，都要对产品质量、客户和企业负责，都有权获得必需的信息并据此进行决策，每个人都有着共同的价值目标和愿景，自动自发，彼此协作完成工作，而管理者在这种情形下通常扮演的是“教练”角色。
本书提供了一整套彻底的管理新思维和行之有效的实施方法，以期唤醒组织作为一个整体，共同为企业的现实和可持续发展负责的使命感，实现企业从α型到β型的转变。作者精通心理学和神经科学，他设计的一套逻辑系统是：沟通优化——个人优化——团队优化一一企业优化。沟通，尤为重要，既是管理的开端，又是一个团队奔着愿景有效运转的基本保障。这部分是该著论述最为深入的一部分，体现了这本书推广管理教练技术的普及特征。
本书的核心理念体现在本书第三章“翻倍领导力”。让领导力翻倍的武器一是逻辑层次，一是情绪领导力。本书揭示出，无论是个人还是企业都有一个逻辑层次，当我们遇到问题的时候，我们要先认清楚这个问题是在什么逻辑层次上。就问题谈问题，很难解决问题，一不小心还会陷入问题而难以自拔，本书告诉我们：一个问题的彻底解决，需要在更高的层次上寻找答案。情绪领导力，也是一个新概念，作者提出必须把情绪纳入管理范畴。无论什么情况下，人是根本的根本，是创意之源。无论是管理者还是所属员工，首先是个人的独立的人，无论生活还是工作，都不可能不带有个人的情绪。哈佛大学教授迈克尔·波特认为，“最伟大的管理者是那些善于管理情绪的人。”但我们过去的管理理念过于强调理性，谈控制情绪，这在理论上固然不错，但实施起来困难重重，甚至适得其反。
《管理管理者》提出：情绪是我们认识价值观的有效渠道，他是一种完全现实的存在，情绪领导力是管理者最为关键的基本素质。价值虽然抽象，但在心理学层面是个现实。英国学者伦布朗认为，情绪是“人类所有活动背后最直接的动力”。价值观在逻辑层次中处于较高的层位，价值决定一个人具有的能力，而且还有很多东西隐藏其后。伤害价值观的代价是惨重的。作者提出：第一步，你不仅要和下属沟通他的价值观，还要不停地给他讲解你自己的价值观；第二步，以一种合作的态度与跟你有共同价值观或者相近价值观的人发展出一种团队的价值观；第三步，把价值观传递到企业的各个角落，各级管理者按照价值观工作。价值观是可以培育的。作者所举的正面例证就是施密茨博士本人对冰岛克伊普辛银行做价值驱动管理的培训，最终使得该银行成功渡过2008年金融危机。作者因此得出结论说：管理者其实就是一个推销员，如果你想推销自己的想法，说服员工、激发员工，就要从员工自己的价值上去说服。企业价值观不是软件，而是硬件，它能让人有驱动力，能够被激励。管理者!必须知道能否达成员工的价值观，能否同时关照客户的价值。本书提供的第二个案例是星巴克如何三次渡过金融危机，并以爆炸性速度发展的故事。
作者施密茨博士既是理论家也是企业实践者，接受他培训的知名企业包括戴姆勒、宝马公司、西门子公司、大众公司、微软公司等，所以《管理管理者》融入了作者自身的大量经验和培训实绩。因为《管理管理者》是中国致公出版社直接国际组稿的，为了得到这些第一手的案例，出版社首先要求作者，作者又特地取得这些公司授权。所以本书提供的管理方案具有很强的实用性。瑞士企业管理中心、瑞士国际商学院院长C.Soutte推荐本书说：“《管理管理者》是一本具体的、明白易懂的、激励人心的行动指南，指明了管理中的新思想和新行为。”Ramco系统欧洲区总裁e.Kangeldi推荐说：“在流行的领导力书籍中，这本书让人们看到了真正的曙光。如果我必须要向一位没有充足的时间阅读更多书籍的高级管理者推荐一本书的话，《管理管理者》将是首选。新发现一旦被提出和估量，沃尔夫冈·施密茨总是站在最前沿。”
企业管理的底层逻辑篇3
企业业务逻辑主要是客户订单驱动的，根据生产计划(订单加预测)来确定所需的物料和能力，并且时间受客户交货期和产品结构特征的约束，即根据客户交货期和产品结构特征来反推并动态配置资源。资源配置是受时间约束的，如果物料和能力在可用量和时间上能满货期的需要，则体现了即时生产(Jit)和敏捷制造的思想。市场和订单变化及内部资源配置的水平影响计划的准确性。如果资源在某一时间点上不能满足需要，或订单及市场变化导致计划的变更及资源的重新配置，企业就必须根据变化来配置资源。订单变化包含量的增减变化和时间变化，这些变化都影响企业资源的配置。供应订单的变化和内部计划水平也影响资源的配置，业务的结构性调整和商业模式的变化在更大程度上影响企业业务逻辑和资源配置。
作为业务逻辑的一部分，业务流程是在功能确定的组织结构中，能够实现业务目标和策略、相互连接的过程和活动集合。
业务流程不仅要体现在业务逻辑中，也要体现在软件逻辑中。在信息系统开发和设计过程中，业务逻辑决定软件逻辑，软件逻辑反映业务逻辑。
软件逻辑泛指软件能实现的业务运作模式与操作流程，包括软件的功能架构、工作流及用户界面等。软件的逻辑有两种：一种是完全定制的软件，虽然也有一些平台化的模块，但真正的软件逻辑是需要结合企业的业务逻辑重新设计并开发的；另一种则是成熟的产品，像一些eRp软件，本身带有成熟的软件逻辑，包括不同行业的业务模式、业务流程和用户视图等。软件逻辑是软件系统的命脉，也是软件承载业务的具体表现形式。eRp核心逻辑包括mRp逻辑和apS逻辑。
许多eRp系统将mRp逻辑作为协调供应链活动的主要动力源。mRp采用倒推无限排程，通过物料清单展开制品的需求，并生成生产计划。mRp逻辑有两个重要假设：无能力约束和无物料约束。即mRp逻辑假设生产订单可以按截止日期完工，而不考虑资源能力，生产订单开工日期可以在不考虑物料可用量的情况下确定。在一些eRp系统中，mRp逻辑计算变动提前期和作业的截止日期，这考虑了可用的能力。mRp逻辑还支持基于定额的排程，这种排程考虑变动提前期。mRp逻辑，特别是考虑变动提前期和排程计算的mRp逻辑，为多数情况下的供应链同步化构建了一个简单又全面的模型。
apS即高级计划与排程，是一种基于供应链管理和约束理论的先进计划与排程工具，包含了大量的数学模型、优化及模拟技术，其功能优势在于实时实现基于约束的重计划与报警功能。在计划与排程的过程中，apS将企业内外的资源与能力约束都囊括在考虑范围之内，用复杂的智能化运算法则，进行常驻内存计算。apS逻辑代表了传统mRp逻辑排程思想的重大改变。apS应用资源和物料约束进行有限排程，为每一资源生成详细的生产计划，apS将排程结果上传到eRp系统，用来协调采购活动和做出交货承诺。apS逻辑包括资源能力模型、详细的工艺路线信息、物料清单和有限排程规则。apS逻辑通过基于能力和物料约束的有限排程，使供应链活动同步。
企业管理的底层逻辑篇4
关键词：销售管理系统；.net三层架构；SQLServer2008数据库
中图分类号：tp391文献标识码：a文章编号：1009-3044（2013）24-5563-04
对于大部分企业而言销售是企业收入的主要来源，为了在日益剧烈的市场竞争中生存下来，企业必须提高销售管理管理的效率，保证企业收入来源的增加。销售部门在供应链中联系企业与外部的市场，主要职能是把企业生产出来的产品或提供的服务提供给为客户，从而实现把企业投入生产的资金转化为主营业务收入并获取利润，是企业能够生存与发展下去的动力源泉，从而实现企业的社会价值。为了管理销售相关的数据，实现销售与企业生产、财务数据的同步，销售管理系统的开发势在必行。作为eRp系统的一个子系统，针对一个饮料生产企业的销售管理需求，该文设计了一个基于.net三层架构的销售管理系统，该系统使用VisualStudio2008开发，数据库采用SQLServer2008。
1应用理论
.net三层架构中系统由表示层、业务逻辑层和数据访问层组成，采用三层架构的系统中层与层之间的耦合度比较低，对某一层的业务或代码的改动对其他层的影响很小，使得系统的开发和后期维护变得更容易。具体的三层架构的分层结构图，如图1所示[1]。
1）表示层：表示层是系统的用户界面，表示层中不包含业务逻辑代码，只是负责把系统的数据展示给用户，将用户的请求传递给业务逻辑层。在表示层中系统的界面可以根据用户的使用习惯进行修改而不影响业务逻辑的运行。
2）业务逻辑层：主要是实现具体的业务逻辑操作。业务逻辑层从表示层中接收到用户输入的信息和操作请求，根据不同的操作请求调用数据访问层的操作，从而实现用户的请求。在各种信息管理系统中，业务需求在业务逻辑层中得到实现，它不会因为系统前台界面的变动而改变。例如系统从C/S架构改为B/S架构后只是系统前台的表示层改变了，系统的业务逻辑层还是保持原来的不用修改。
3）数据访问层：数据访问层处于整个系统的最底层，负责完成数据的增删查改，同时管理并响应业务逻辑层的数据请求。系统更改了存储数据的数据库系统后只需要对数据访问层进行相应的修改就可以正常运行，不影响业务逻辑层的代码。
2系统设计
2.1系统功能设计
根据销售管理的实际需求，销售管理系统的主要功能模块设定有基础数据管理、销售价格管理、销售订单管理、销售收发货管理[2][3]。其主要功能模块如图2所示。
1）基础数据管理。基础数据管理主要维护系统运行所必须的一些数据，包括客户资料维护、销售员维护、销售类型维护和发货方式维护。
2）销售价格管理。产品报价管理和客户折扣管理是销售价格管理的两大功能。其中，报价管理是企业根据报价规则对每一个销售订单进行报价，报价规则可以根据产品、客户地区、客户等级、销售数量、产品组合进行灵活配置；客户折扣管理则是在报价规则生产的产品报价的基础上，企业根据与客户的谈判给予额外的折扣优惠。
3）销售订单管理。该模块根据业务员与客户确定的销售信息录入销售订单，一般包含了订单编号、客户名称、客户联系电话、收货地址、发货方式、结算方式、销售产品明细等信息。销售负责人根据产品库存情况和客户信用等级确认产品报价，审核销售订单。其中，订单制定、审批、跟踪是销售管理模块的核心功能。而订单跟踪则是订单的业务员对订单的发货情况和收款情况进行跟踪，确保按时把产品送到客户手中，不失信于客户，同时保证订单按时收款。
4）收发货管理。销售发货管理是仓管部门根据发货单对货物进行分拣装车，在规定的时间能把产品送到用户手上，并在客户收货后将发货情况转给财务部门做帐。对某些需要退换货的产品进行重新入库，发新产品给客户，通知财务部门进行相应的收退款。
2.2数据库设计
销售管理系统作为一个信息管理系统，系统所有的数据信息都要存储到数据库中，使用SQLServer2008的SQLServermanagementStudio工具，以超级数据库管理员sa登录，新建一个数据库，数据库名称为Salemanager，主要包括8张表：客户信息表（Xitong_KeHu）、销售物品表（Xitong_wupin）、报价表（XiaoShou_BaoJia）、订单表（XiaoShou_DingDan）、订单明细表（XiaoShou_DingDanmingXi）、退货表（XiaoShou_tuiHuo）、退货明细表（XiaoShou_tuiHuomingXi）、销售统计表（XiaoShou_tongJi）。
根据数据表的联系和完整性约束，定义相应的主、外键，以保证数据的一致性[4]。
2.3界面设计
本系统设计了如下用户界面：
用户登录界面为系统用户登录时选择用户部门，输入正确的用户名和密码后点击登录系统；
主界面分两部分，左边通过树状控件列出用户可以操作的权限，右边作为子窗体的容器，在用户点击左边的操作后弹出相应的操作界面；
另几个界面：产品管理界面、客户管理界面、订单管理界面、退货管理界面用到了工具栏、DataGridView控件、按钮等控件，主要实现对某一项销售信息的新增、修改、审核、作废、导出等功能[5]。其中订单管理和订单新增界面如图3，4所示。
3系统三层架构的实现
3.1实体类的实现
本系统使用实体类在三层之间传递数据。建立一个实体层（models）在各层之间传递数据，并在各层中添加引用。本系统中，数据库Salemanager的8张表分别转换为Xitong_KeHu、Xitong_wupin、XiaoShou_BaoJia等8个实体类[6]。下面仅以Xitong_KeHu实体类的实现作为说明：
3.2数据库访问层的实现
为了便于代码的共享，创建数据库通用操作类（DBHelper.cs）完成数据库的通用操作。该类定义了连接数据库的参数，根据需要自动创建数据库连接，主要方法有执行有参数、无参数的SQL语句以及完成各种功能的存储过程等，代码如下：
DBLibrary.SQLHelper.connectString="server=127.0.0.1；database=Salemanager；uid=sa；pwd=demo；"；//定义数据库连接字符串
同时和数据库中的8个表对应创建相应的8个数据访问类，仅以客户管理数据访问类为例说明类中包含的方法：
KeHu_Select（）：查询所有客户信息；
KeHuXinXi_Select（intKeHuiD）：根据iD提取客户信息
KeHu_Delete（intKeHuiD）：删除被选中的客户；
KeHu_insert（model.Xitong_KeHumyKeHu）：新增客户；
KeHu_Update（model.Xitong_KeHumyKeHu）：修改选中的客户；
KeHuBianHaoweiYipanDuan（stringKeHuBianHao）：客户编号唯一性判断；
KeHuZhangmu_Select（intKeHuiD，Datetimebegin，Datetimeend）：返回一个客户账目记录查询的结果集。
3.3业务逻辑层的实现
本系统在业务逻辑层也相应创建了8个业务逻辑类。业务逻辑层负责销售业务的实现，实现步骤如下：
1）在类中引用需要使用的的数据访问层和实体层的命名空间；
2）实例化实体对象并赋值；
3）实现业务逻辑，在这一过程中根据需要调用数据访问层的功能。
3.4表示层数据绑定的实现
根据三层架构的思想界面层只能直接调用业务逻辑层，不能调用数据访问层。编写代码时得首先引用命名空间Sale.models和Sale.BLL，展示数据时调用相应的业务逻辑层类的方法来完成数据的提取，最后把提取到的数据表作为数据源绑定到相应的数据库控件中。
4结束语
本文介绍了.net三层架构，并着重介绍了基于.net三层架构的销售管理系统的设计与实现，该系统为企业管理者提供销售方面及时而准确的信息，并且可以对销售管理效率方面提供控制，最终使企业在市场竞争中获得最大的经济效益。
参考文献：
[1]高扬.基于.net平台的三层架构软件框架的设计与实现[J].计算机技术与发展，2011（2）：77-80.
[2]祝留华.中小企业销售管理系统的设计与实现[D].成都：电子科技大学，2011.
[3]陈翠娟.基于UmL的销售管理系统的分析与设计[J].电脑与电信，2012（10）：47-50.
[4]赵延红.基于.net三层架构的文档管理系统的研究与实现[J].电脑编程技巧与维护，2011（8）：78-79.
企业管理的底层逻辑篇5
[关键词]网络环境客户信息数据流图
一、前言
随着电子计算机和通信技术的发展，人类已经逐渐地进入信息化社会。在市场经济的大环境下，越来越多的人士逐渐认识到用计算机技术进行各类管理、交流的便捷。本文针对客户关系管理系统（CustomerRelationshipmanagement,CRm）中客户信息管理为突破口，重点讨论如何采用信息化手段，建立一个企业各业务部门共享客户信息的工作平台，对客户信息进行快速获取、规范管理、科学统计和实时查询，从而使企业可以更好地满足客户需求并降低运营成本，达到留住现有客户和发掘潜在客户并提高企业盈利能力的目的。
二、客户信息管理系统业务建模
通过对国内某企业的调研结果分析，业务流程图如图1所示，企业的业务部为其它部门提供客户资料、销售资料、联系人资料。客户部收集其资料并及时将资料整理，建立数据库。系统管理人员进行系统数据的维护，及时对客户的问题进行解决，同时进行原有客户的查询，以了解新老客户，为使其成为终生客户打好坚实的基础。
三、系统的分析与设计
1.总体结构设计
客户信息管理系统软件体系采用标准的C/S体系架构，分四层，功能如下：
(1)用户界面层：采用基于客户端组件形式，用户需要数据交互时通过调用服务器端专用接口进行访问，保证后台数据的安全性。
(2)业务逻辑层：业务逻辑层是系统的核心。客户信息管理整合和记录企业各部门所接触的客户资料进行统一管理。包括客户基本信息、客户联系人信息、项目信息、供应商信息和服务反馈信息等；客户关系管理是一种旨在改善企业与客户之间关系的新型管理机制。包括销售管理，行动管理，财务管理，产品管理等；系统管理则是由系统管理员进行用户的添加，修改、删除操作及权限和日志等的管理。
3)aDo数据访问层：aDo层是建立在数据库之上，应用程序通过该控件访问数据库。数据访问层一般封存数据库的选择、添加、更新和删除等操作，同时还为业务逻辑层提供访问数据库的接口。
(4)数据存储层：是系统最底层，数据库存储客户信息相关的数据，主要是通过aDo数据访问层的接口为业务逻辑层提供数据服务。
2.数据流程图
客户信息管理系统可抽象为一个加工系统，操作人员从业务部拿来大量的客户资料和业务资料，通过该系统最终给业务部提供企业业务报表和客户资料，为企业下一步的计划、决策提供强有力的依据。其数据流程图如图2所示：
四、系统实现与典型界面
本文以VB和SQLServer2000为开发工具，并以aDo(activeDataobjects)作为应用程序和oLe-DB连接的桥梁，实现了客户信息管理系统的开发，其典型界面如下：
五、结束语
本文针对客户信息的特点和目前企业应用中的实际问题，提出了网络环境下客户信息数字化管理方法。通过客户信息管理系统的调研、分析设计和开发，构建了客户信息网络化管理平台，为企业信息化过程中实施CRm创造了一定的条件。目前已经在VB的iDe下开发了该平台的原型，并正在国内某企业测试和实施。后期的主要工作为扩充和完善客户信息管理平台，并将灰色理论、遗传算法等融入到客户聚类分析和满意度评估中。
参考文献：
[1]王健聪:客户关系管理与企业竞争力发展[J].沿海企业与科技，2006，(11）:20～21
企业管理的底层逻辑篇6
企业管理遵循的是人性和欲望的逻辑，华为能一路披荆斩棘屹立行业之巅，就是因为团队既能激发欲望，也能控制欲望。
我们经常听到一种说法，叫做无欲则刚，我想这个说法，第一，违背人性，第二，无欲者很难做到所谓刚强、有力量。欲望其实是中性的，很大程度上，欲望是企业、组织、社会进步的一种动力。
从心理学的角度分析，知识型劳动者的欲望可以被分为五个层面：
第一层面：物质的饥饿感
绝大多数人、甚至可以说每个人都有最基础层面的对物质的诉求，员工加入到企业，最直接、最朴素的诉求就是财富的自由度。企业、组织能不能给员工提供相对的物质满足，实际上是企业人力资源最基础的部分。
第二层面：安全感
这是人类与生俱来的一种本能性需求，人的一生多数都处于一种不安全状态，越是杰出人物、领袖人物，内心不安全感越强烈。华为正是因为拥有充满了危机意识的优秀管理者，又拥有十几万内心有强大不安全感的人，大家抱团取暖，共同面对充满了风险、未知、恐惧的世界，才有了华为的“胜则举杯相庆、败则拼死相救”的文化。
第三层面：成长的愿望与野心
越是智力层面高的人，领袖欲望、野心的张力越强大。怎么能够把这些人人要出人头地，人人要做领袖，人人想拥有权力的人凝聚在一起？公司的价值评价和价值分配体系至关重要。当这些人的权力，跟他的欲望、雄心、野心相称的时候，他自然愿意在这样一个平台去发挥自己的才能，发挥自己的智慧。组织说到底就是要张扬队伍中每个人的雄心，同时又要遏制过度的野心，张扬雄心、遏制野心是所有管理者每时每刻都要面对的问题。
第四层面：成就感
被社会认可，被大众认可的欲望等等。华为成功有各种各样的因素，其中重要因素之一就是两个字――共享，共享发展的财富成果，同时也分享安全感，分享权力，分享成就感。把钱分好，把权分好，把名分好，这是相当重要的。
做老板的人，一定要把最基本的东西想明白。第一，财富这个东西越散越多，第二，权力、名声都是你的追随者赋予你的，假使哪一天你的追随者抛弃你，你的权力，你的所谓成就感，你的所谓聚光灯下的那些形象，乃至于财富，都会烟消云散，乃至于灰飞烟灭。
企业管理的底层逻辑篇7
企业社会责任指标体系是指企业为反映和衡量企业整体、内部组织和员工个人，管理企业运营对利益相关方和自然环境影响的效果和效率而设置的标准体系。
企业社会责任指标体系试图通过一系列指标来对企业履行社会责任的过程和结果目标进行分解和细化，用以反映和评价组织与员工实现目标的过程与效果。当前，尽管实践中已经有不少国内外一流企业构建了自己的社会责任指标体系，但是大多数企业采取的都是“经验式”方法，它们按照自己所熟悉的某种方式来构建社会责任指标体系。然而，对于某一具体企业来说，构建社会责任指标体系的一般性思考逻辑是什么，可以从哪些角度来搭建企业社会责任指标体系的基本框架，仍然是目前让企业管理者和社会责任推进工作者感到无比困惑的难题。
五大维度构建企业社会
责任指标体系框架模型
对于某一企业来说，构建社会责任指标体系首先需要明确各级指标的选择与设计应遵循什么样的逻辑框架。而按照通常的方法，企业社会责任指标体系构建会遵循从一级指标――中间层级指标――末级指标的构建思路。这样，企业构建社会责任指标体系就需要先行确定一级指标的逻辑框架――中间层级指标的逻辑框架――末级指标的逻辑框架。按照企业构建社会责任指标体系的工作部署需要，总结国内外一流企业的已有实践，企业构建社会责任指标体系通常可以采取如下图的五维逻辑框架模型。
从一级指标来看，逻辑框架构建可以依据纬度的不同而分为四类：第一类是按照利益相关方纬度，将一级指标划分为投资者责任、客户责任、员工责任、商业伙伴责任等；第二类是按照责任内容纬度，将一级指标划分为经济、社会、环境、法律、慈善等责任，具体包括的指标依据不同内容结构模型而有所差别；第三类是按照指标功能纬度，将一级指标划分为社会责任管理指标、社会责任沟通指标和社会责任考核指标等；第四类是按照组织层级纬度，将一级指标划分为企业整体社会责任指标、部门社会责任指标和岗位社会责任指标等。
从中间层级指标来看，逻辑框架构建可以采用套用模式，即某一中间层级指标可以采用前几级指标尚没有使用的纬度，比如：如果某一企业社会责任指标体系的一级指标按照组织层级划分为整体社会责任指标、部门社会责任指标和岗位社会责任指标，那么其二级指标就可以按照利益相关方纬度、内容纬度和功能纬度三种方法进行划分，假如采用功能纬度，那么其三级指标就可以按照利益相关方纬度和内容纬度两种方法进行划分，假如采用利益相关方纬度，那么其四级指标就可以按照内容纬度进行划分。
企业社会责任指标体系构建的五维逻辑框架模型
从末级指标来看，要全面衡量企业履行社会责任表现，既要衡量企业履行社会责任的结果绩效，也要衡量企业履行社会责任的过程绩效，同时还要衡量企业的相关社会责任制度建设情况。因此，企业设计和选择社会责任具体指标时，必须根据作用属性这一纬度进行全面考虑，衡量指标既要包括履行社会责任的结果性指标，还应包括过程性指标以及制度保障性指标。
对于某一具体企业而言，上述每一层级的指标逻辑框架选择并没有统一的要求，而应该根据企业建立社会责任指标的目标予以确定，同时还要考虑与企业管理信息系统、统计体系等已有管理体系的兼容和匹配。
利益相关方纬度：确立共同责任和特定责任
企业对每一类利益相关方应当承担什么责任是由多方面因素决定的，包括依赖于利益相关方的权力和期望，以及企业自身特点。其中，利益相关方的权利是使用各种资源使某事件发生或确保获得一个需要的结果的能力。利益相关方期望是在利益相关方权力基础上产生的利益期望，这些期望可能构成了企业对各利益相关方应当承担的社会责任的重要内容。尽管如此，企业在根据利益相关方期望确定履行社会责任内容时，还应该将行业性质、所有制、经营属性等企业自身特点作为重要依据。
进一步分析来看，企业对利益相关方应该履行的责任可以分为两类：一类是企业要对所有利益相关方所承担的共同责任，包括实现企业的核心社会功能、遵循企业发展普遍规律、激发利益相关方价值创造潜能和把握经济全球化机遇等四个方面；另一类是企业要针对利益相关方的独有特点，对不同利益相关方要承担不同的特定责任。对于每一类利益相关方的特定责任可以细分为必须履行的法律责任、应该履行的道德责任、自愿履行的合作共赢责任和自愿履行的激发价值创造潜能责任等四个方面。
责任内容纬度：四大模型皆可确定内容框架
企业社会责任指标体系的每一层级指标都可以采用责任内容纬度划分的逻辑框架进行设计。根据不同学者对企业履行社会责任应包含内容的不同，比较有代表性的企业社会责任内容模型包括“同心圆”模型、“金字塔”模型、“三重底线”模型和“维恩图”模型等。对于某一企业来说，可以既按照这些模型确定指标体系的内容框架，也可以借鉴这些模型建立反映企业自身特点的指标体系内容框架。
功能纬度：确立沟通、管理、考核指标
企业社会责任指标体系构建的另一种思路是根据构建目的进行分类设计，即按照指标体系应该发挥的功能纬度进行设计。对于企业来说，构建社会责任指标体系的目的就是要发挥指标体系的沟通功能、管理功能和考核功能，以实现与利益相关方更加有效地沟通，营造更加浓厚的履责氛围，推进企业全员、全面、全过程、全方位地履行社会责任。
根据以上的构建目的，企业社会责任指标体系就可以根据功能纬度划分为社会责任沟通指标、社会责任管理指标、社会责任考核指标。对于沟通功能来说，企业应按照与利益相关方沟通的需要，探索建立一套包括员工沟通指标、用户沟通指标、政府沟通指标、伙伴沟通指标、社区沟通指标等在内的逻辑清晰、科学合理的企业社会责任指标体系，并把它作为企业与各关键利益相关方沟通的最为重要的信息载体。对于管理功能来说，企业应将需要实现的社会责任目标通过指标分解的方式层层分解到各部门、各业务单元和各岗位，成为部门、业务单元和员工社会责任目标的重要组成部分，从而使得不同层级的管理者和员工都明确自己履行社会责任的详细内容和应该达到的目标，推进企业对履行社会责任的精细化管理。为此，企业应通过社会责任指标体系的这种层层分解，形成一套企业社会责任管理指标体系。对于考核功能来说，企业应根据切实保障各层级履行社会责任的需要，建立包括各岗位社会责任考核指标、各部门社会责任考核指标和各业务单元社会责任考核指标在内的企业社会责任考核指标体系。
组织层级纬度：确立整体、部门、岗位指标
按照钱德勒的观点，拥有不同的部门是现代公司的一个重要特征。而且，从现代公司的发展实践来看，层级制是几乎所有公司采取的组织结构模式。对于现代公司的不同层级来说，由于它们所拥有的权利范围和承担的责任范围不同，因此它们所关注的利益相关方范畴、责任内容是不一样的。对于现代公司每一层级来说，要保证自身更好地履行社会责任、更加有效地评价自身履行社会责任表现，就有必要针对性地建立社会责任指标体系，即针对每一层级建立相应的社会责任指标体系。这样，根据现代公司组织层级的不同，企业社会责任指标体系就可一般性地划分为：企业整体社会责任指标、部门社会责任指标以及岗位社会责任指标。
其中，企业整体社会责任指标，是全面反映企业履行社会责任的过程和结果的有效性和绩效。部门社会责任指标是反映企业各部门履行社会责任的过程和结果的有效性和绩效。部门所负责的社会责任指标，既包括企业整体社会责任指标的分解指标，也包括本部门为加强社会责任工作而设置的特定指标。岗位社会责任指标是反映企业各岗位每一位员工履行社会责任的过程和结果的有效性和绩效。岗位社会责任指标，是员工所负责的企业、部门社会责任指标的岗位分解指标。
作用属性纬度：确立结果性、过程性和制度保障性指标
对于任何企业来说，要真正将履行社会责任的理念和要求融入到企业实践中并产生预期的效果，就必须通过制度化形式明确各层级的工作标准和行为规范，并对各层级执行这些标准和规范的过程进行监控，以确保企业各层级履行社会责任过程的有效性和可控性。唯有健全的制度标准和规范的行为过程才可能保证良好的履责绩效结果。因此，无论是加强管理需要还是出于考核需要，企业社会责任绩效衡量都必然要对履责的结果绩效、过程表现和制度建设情况进行全面的衡量。这就要求企业社会责任指标体系必须全面包括结果性指标、过程性指标和制度保障性指标。
从另外一个角度来看，对于所有利益相关方而言，他们不但希望了解企业履行社会责任的结果绩效如何，而且非常关注企业履行社会责任的过程是否满足要求。与此同时，他们还想确定企业当前所表现出来的社会责任结果绩效是偶然因素导致的，还是由于一系列制度因素所引起的。从这个意义上来说，企业为了实现与利益相关方的有效沟通，也应该确保社会责任指标体系全面涵盖结果性指标、过程性指标和制度保障性指标。
企业管理的底层逻辑篇8
关键词：Soa；webservice；教务管理系统
中图分类号：tp315文献标识码：a文章编号：1009-3044(2008)34-1941-01
educationaladministrationmanagementSystemBasedonService-orientedarchitecture
JiHeng
(taizhounormalCollege,taizhou225300,China)
abstract:thepaperintroducesthebasicconceptofSoa,inviewofthecurrentdecentralizedcollegesanduniversitiesinthedevelopmentofinformationtechnology,madethedesignideasofeducationaladministrationmanagementsystembasedonservice-orientedarchitecture,provideareferenceprogramforthediversifieddevelopmentofcollegesanduniversities.
Keywords:Soa;webservice;educationaladministrationmanagementsystem
1Soa与webService
1.1Soa介绍
Soa（Service―orientedarchitecture）是一种面向服务的架构，它将应用程序的不同功能单元称为服务，通过这些服务之间定义良好的接口和契约联系起来。
Soa着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务[1]。Soa的发展打破了传统应用软件开发的模式，实现了将软件依据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。应用程序不同功能单元的接口采用中立的方式进行定义，独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种各样的系统中的服务可以一种统一和通用的方式进行交互[2]。
1.2webservice
webservice涵盖了Http、Soap、wSDL、UDDi等技术规范，在内网和外网上通过标准的协议和信息格式和访问应用服务。利用webservice的松散捆绑集合形式，能够快速开发、发现、和动态的绑定应用服务。
由此，基于webservice的Soa有助于企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。服务的提供者是创建服务的实体，它通过服务注册器服务合约，服务请求者通过查询服务注册器找到感兴趣的服务后向服务注册器发出的请求，如图1所示。
2基于Soa架构的教务管理系统模型构建
2.1需求概述
高校规模迅速扩大，校区分散所带来的一系列管理问题正严重制约着高校的发展，不同校区由于历史原因所使用的管理软件各不相同，而不同系统之间的交互问题则是迫切需要解决的问题。基于Soa架构的教务管理系统可以很好的解决系统间交互冲突问题，从而提升院校教学管理效率，提升不同校区间的发展潜力。
2.2基于Soa架构的系统架构方案
在基于Soa架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件组合构建起来的。因此，基于Soa的架构也一定是从企业的具体需求开始构建的。高校教务管理主要涉及到教务管理部门、学生和教师等，其主要功能为实现学生管理、教学计划管理、成绩管理等应用，其系统架构如图2所示。
（下转第1959页）
（上接第1941页）
2.3基于webservice的系统逻辑架构
教务管理系统webservice架构采用J2ee三层结构：数据表现层、业务逻辑层和数据层。
数据表现层是为教师、学生和管理人员提供应用服务的图形界面，有助于用户理解和高效的定位应用服务，如窗体服务、报表服务、页面服务和文件服务等。
业务逻辑层位于数据表现层和数据层之间，为实现教务管理系统的业务逻辑专门提供了一个明确的层次，在这个层次封装了与系统关联的应用模型，并把用户表示层和数据库代码分开。业务逻辑层提供客户应用程序和数据服务之间的联系，主要功能是执行应用策略和封装应用模式，并将封装的模式呈现给客户应用程序，如登录与身份认证、数据查询、数据导入/导出、数据统计分析和数据加解密等。
数据层位于三层模式中最底层，它用来定义、维护、访问和更新数据并管理和满足应用服务对数据的请求。
三层结构系统通过层与层之间分离的功能提供了更好的性能。这种应用结构使得业务逻辑层能从数据表示层分离出，变成一个明确的专业层，从而提高了系统的可维护性[3]。
3基于Soa架构的教务管理系统实现
教务管理系统包括以下子部分：管理控制与数据处理、数据采集与信息和系统管理。管理控制和数据处理子系统涵盖了教学计划、课表安排、教材管理、学籍管理、成绩管理等子系统；数据采集与信息子系统以公共服务为主；系统管理子系统包含数据库加密、数据导入/导出、门户更新等子系统。
每一个子系统可利用webServices提供统一的接口标准，在Soa下实现信息的构建、解析和传输，从而实现系统间的数据交换[4]。
JaVa具有跨平台的优越性，而J2ee的weB服务可方便构建能够访问现有业务流程的Soa系统，因此可使用J2ee技术开发基于Soa的教务管理系统。
4结束语
Soa架构中可通过拆分与组合各种核心模块，做到有针对性的构建满足不同需求的Soa应用系统。基于Soa构架的教务管理系统可实现学校自上而下整体的紧密结合，既杜绝了重复开发的高成本，又提高了教学管理效率。
参考文献：
[1]叶宇风.基于Soa的企业应用集成研究[J].微电子学与计算机,2006,23(5):211-213.
[2]叶钰,应时,李伟斋,等.面向服务体系结构及其系统构建设计[J].计算机应用研究,2005,22(2):32-34.
企业管理的底层逻辑篇9
关键词：多层体系结构；J2ee；mVC；Struts
Doi：10.16640/ki.37-1222/t.2017.04.184
0引言
针对传统的客户机/服务器体系结构的种种缺点，计算机科学家提出了三层或多层分布式系统模型[1]。随着不断改进和发展，多层分布式系统逐渐形成了三种具有代表性的主流技术，即CoRBa、Com/DCom和J2ee（Java2platformenterpriseedition）。J2ee为搭建具有可伸缩性、灵活性、易维护性的分布式系统提供了良好的整套机制。
1多层体系结构模型
三层架构就是将整个系统业务应用划分为三个层次，即：客户层、业务逻辑层、数据访问层。业务逻辑层又可由多个子层组成，具体要看系统的复杂程度。这样就形成了多层分布式体系结构，分布性可以体现在软件上，也可以是硬件，具体模型如图1所示。
多层体系结构模型将表示和业务处理分开，缩减了客户端的规模，又将相关业务和资源分开，降低了服务器的负载，避免了服务器的性能缺陷对整个系统性能的影响。这种在多个服务器上分布应用程序处理的多层可变结构比二层体系结构的伸缩性和扩展性有了很大加强。同时多层体系结构解决了客户机/服务器结构的维护成本问题，改善客户机/服务器结构延展性问题。客户机/服务器结构支持的用户人数有一定限额，这种结构限制了internet/intranet及电子商务的发展。
2J2ee多层模型
为实现企业级分布式应用，J2ee定义了丰富的技术标准、符合标准的开发工具和api为开发企业级应用提供技术支持，这些技术涵盖数据库访问、分布式通信和安全等。
2.1J2ee多层模型介绍
J2ee是一个基于Java的适合服务器端的、结合了Javaenterpriseapi的完整的企业级应用系统开发平台或中间件体系结构，它通过提供一组应用组件和运行时环境来构造可伸缩的企业应用。典型的J2ee结构的应用程序包括四层：客户层、表示逻辑层、业务逻辑层和数据访问层，如图2所示[2]。
客户端层用来实现企业级应用系统的操作界面和显示层。表示逻辑层由web服务器和web组件组成。web组件包括JSp页面和servlets。表示逻辑层也可以包括一些JavaBeans，这一层主要用来处理客户请求，调用相应的逻辑模块，并把结果以动态网页的形式返回到客户端。业务逻辑层也叫ejb层或应用层，由ejb服务器和ejb组件组成，用来实现企业级信息系统的业务逻辑，这是企业级应用的核心。ejb要运行在容器中，容器解决了底层的问题，如事务处理、状态管理、多线程、安全管理、资源池等。表示逻辑层和业务逻辑层也可以合称中间层。数据访问层处理企业系统软件，包括企业基础系统、数据库系统及其它遗留的系统。
2.2J2ee核心技术
在J2ee中，开发者可以用来实现多层结构的核心技术应该包括Servlets、eJB、JDBC、JnDi、JavaRmi等[3]。
JavaServlet是一项服务器端技术，它接收来自web浏览器的Http请求并返回Http响应。首先，请求被提交给Servlet引擎，然后Servlet引擎执行适当的Servlet，访问响应对象，并向客户端返回一个响应。
ejb定义了如何编写服务器端m件，并为服务器端组件和管理这些组件的应用服务器之间提供了标准协议，开发者可以利用这些组件象搭积木一样建立自己的分布式应用程序。ejb并不是一个单独的文件，它由一些类、接口、描述文件和其它一些资源文件组成。ejb组件有三种类型：会话Bean、实体Bean、消息驱动Bean。会话Bean用于管理实体Bean和其它会话Bean的交互、访问资源，通常代表客户机执行任务。实体Bean用于表示数据库中的数据，向JDBC或其它一些后端api经常访问的数据提供了一个面向对象的接口。消息驱动Bean响应JmS消息。
JDBC是Java程序与数据库通信的标准api，使Java开发者能够用纯Javaapi编写数据库应用程序。和oDBC一样，JDBC为开发人员隐藏了不同数据库的不同特性。另外，由于JDBC建立在Java的基础上，因此还提供了数据库存取的平立性。
JnDi是Java对对象名字和目录服务的“中央注册表”，管理着对构建分布式应用程序所需的核心组件的引用。当创建访问远程对象的应用程序时，JnDi以查找返回该对象地址的方式提供对该对象的引用。应用程序首先在webLogicServer部署中需要的对象，而webLogicServer服务将返回应用程序访问该对象时所需要的一切属性。
远程方法调用（Remotemethodinvocation，Rmi）大大增强了Java开发分布式应用的能力，支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝调用。Rmi目前使用Java远程消息交换协议JRmp进行通信，JRmp是专为Java调用远程对象制定的协议。因此，JavaRmi具有Java的“writeonce，Runanywhere”的优点，用JavaRmi开发的应用系统可以部署在任何支持Java运行环境的平台上。但由于JRmp是专为Java对象制定的，因此，Rmi对于用非Java语言开发的应用系统支持不足，不能与用非Java语言编写的对象进行通信，其实也可以把它看作是RpC的Java版本。
3mVC在J2ee中的应用
J2ee能使遵从这个规定的开发者得到行业的广泛支持，使企业级应用的开发变得简单、快速。然而在实际的开发过程中，设计者往往忽略了Java语言面向对象的特性，模糊了web系统三层之间的界限，从而使整个系统貌似神离，不能获得预期地优越的性能。这就要对J2ee开发模式的理论进行探讨，目前最流行的就是mVC（model/View/Controller）设计模式，structs、spring、hibernate、JSF等则是实现mVC模式最流行的框架方案[4]。
设计模式就是软件人员在面向对象软件设计中经多次验证的成功解的记录与提炼，是在特定上下文情形下解决一般设计问题的类和相互通信对象的描述，是针对问题和解的抽象，是对一系列具有共性的问题的完整的解决方案。设计模式有效地避免了设计损害了系统的复用性，是可复用面向对象软件的基础。mVC是一个强大的模型，基于功能清楚地分开了代码，修改在某一层上的应用程序不会影响到其它层。代码分布到多个逻辑层和物理层执行，每一层对应于一个特定的应用程序功能，它们之间使用定义明确的、可判定的方式进行通信。通过响应用户和程序输入，在层与层之间传递信号和数据来完成应用程序的功能。
mVC设计模式具有设计清晰、易于扩展、运用可分布的特点，因此在构建web应用中具有显著的优势。mVC可适用于多用户的、可扩展的、可维护的、具有很高交互性的系统，如电子商务平台、CRm系统和eRp系统等。mVC可以很好的表达用户与系统的交互，可以很方便的用多个视图来显示多种数据，从而可以使系统能方便的支持其它新的客户端类型，如pDa、wap等。mVC的另一个好处就是将开发团队依照专业技术方向分开。这样，GUi设计专家可以在视图层工作，负责具体功能开发的领域专家在控制层工作，数据库专家在模型层工作。这种明确分工可有效提高开发团队所有成员的效率，从而提高整个开发团队的生产能力。
mVC在J2ee下开发已经成为了开发的主流模式。目前实现mVC模式比较好的框架有structs、spring、hibernate、JSF等。这些框架都提供了很好的层次分隔功能，其中Struts技术是构建J2ee分布式程序的最流行框架方案。
Struts的开发模型分model1和model2两种。model1模式在进行快速和小规模的应用开发时是具有非常大的优势，但是从工程化的角度考虑，它也有一些不足之处，主要在于不方便应用扩展，以及不利于应用系统业务的复用。大型web应用必须采用不同的model2设计模式。model2是基于mVC模式的框架，"model"代表的是应用的业务逻辑（通过JavaBean、ejb组件实现），"View"是应用的表示层（由JSp页面产生），"Controller"是提供应用的处理过程控制（一般是Servlet）。这种设计模型把应用逻辑、处理过程和显示逻辑分成不同的组件实现，这些组件可以进行交互和复用。model2具有组件化的优点，从而更有利于大规模系统的开发和管理。Struts是一组相互f作的类、Servlet和JSp标记，它们组成一个可复用的model2设计。这个定义表示Struts是一个框架，而不是一个库。但Struts也包含了丰富的标记库和独立于该框架工作的实用程序类库。Struts利用taglib获得可重用代码和抽象Java代码，利用actionServlet配合Struts-config.xml实现对整个系统的导航。Struts增强了开发人员对系统的整体把握，提高了系统的可维护性和可扩充性。
4结束语
J2ee为搭建多层分布式系统提供了良好的整套机制，包括了J2ee的相关实现技术和应用开发的一般过程。通过多个具体项目的应用研究，开发者可以逐步完善该体系结构，逐步积累各层次的组件，直至最后建立J2ee业务组件库，从而达到提高研发分布式系统的能力、效率和规范软件的研发过程。
参考文献：
[1]梁维海.三层体系结构无关性的研究及实现[D].四川：成都理工大学，2004：1-4.
[2]闫|，郭D.基于eclipse开发环境的J2ee编程技术[J].河北：唐山职业技术学院学报，2008，6（04）：45-46.
[3]王仕超.基于JaVa的mVC模型框架研究[D].江苏：南京理工大学，2003：11-16.
企业管理的底层逻辑篇10
【关键词】能力视图智能管道eR模型
doi：10.3969/j.issn.1006-1010.2015.10.000中图分类号：tp3文献标识码：a文章编号：1006-1010（2015）10-0000-00
[abstract]accordingtotheissuethattelecommunicationsenterpriseonlyprovidesbottomlayerintelligentpipelinecapabilityatpresent，amethodtobuildunifiedenterprisecapabilityviewwasproposed.Fromthreeaspectsoftheclassificationofintelligentpipelinecapacity，enterprisecapabilityviewmodelingandoperation，thespecificcontentofenterprisecapabilityviewwaselaboratedtoprovideausefulreferencetotheapplicationofintelligentpipelinebasedonenterprisecapabilityview.
[Keywords]capabilityviewintelligentpipelineentity-relationship（eR）model
1引言
面对互联网企业ott应用和虚拟运营商的崛起，当前电信运营商从传统的“语音+短信+增值业务”转变为“语音+应用+流量”的业务模式，电信的核心战略转向基于智能管道模式的流量经营，智能管道的范围也进一步明确为应包括Ct+it，因此有必要构建企业级统一的能力视图，在此基础上快速引入第三方合作伙伴进行二次开发，利用合作伙伴的渠道、客户资源快速扩大智能管道的用户半径。
2企业能力视图的构建
企业能力视图的构建过程可以归纳为对外提供能力的组件化和内部专业能力的服务化：内部服务的构建是通过自外而内、自顶向下的分析，将现有对外提供的策略服务功能点逐层细分，直到最后一级可以复用的原子服务；外部能力的封装是通过原子能力自底向上逐层组装，分析出可以重用的能力及常用的业务组件（带流程的能力），以统一能力视图的方式对外提供业务组件及关键信息描述、典型案例。
2.1企业能力的分类
从智能管道角度可以初步将企业现有的能力做如下分类，方便合作伙伴快速检索：
（1）查询类：可以进一步细分为余额查询、欠费查询、套餐使用量查询、账单查询、详单查询、缴费查询、信用查询、用户信息类查询、积分查询、套餐信息类查询、服务信息类查询、终端查询、销售类信息查询和信息类查询。
（2）业务受理类：业务订单受理、费用受理（一次性费用批价、销账、返销等）、业务受理（流量包订购、续费、宽带提速、功能产品受理）、信控授信（挂失、解挂、停/复机、授予/回收信用度），以及接入控制受理业务校验类：资料合法性校验（身份证校验、卡资源预占校验、号码预占校验、欠费校验、用户状态校验）、业务受理校验（手机用户受理流量包校验、续费校验、宽带临时提速校验、功能产品受理校验）。
（3）充值支付类：传统金融机构联网代收类、商充值、卡充值类、用户现金支付、积分兑换、小额支付。
（4）接入控制类：时段接入控制、地域接入控制、业务接入控制。
（5）宽带智能提速：提速请求接受及解析能力、用户状态校验能力、用户策略校验能力、策略规则处理能力、提速查询能力（带宽查询、用户信息查询、用户提速签约查询、提速申请能力）。
（6）流量控制类：总量控制、定向流量控制、特定时段控制、无线上网速率控制（智能提速、智能降速）。
（7）定位类：位置查询（点、面、轨迹）、位置受理（位置范围、位置生命周期、位置可告警时段）、位置提醒（实时提醒、延时提醒）、提速指令生成能力、提速指令下发能力、提速后费用控制能力。
（8）其他类型。
2.2企业能力视图的定位
企业能力视图的角色包括如下：
（1）合作伙伴：可以方便调阅、申请、启用现有电信对外开放的“能力目录”，并快速转换为自己的应用部署、上线。
（2）运营商管理人员：可以进行各类能力的使用效益风险分析，一点管控“能力资产”。
（3）运营商开发、维护人员：关注原子服务视图层。可以进行各类服务增加、删除、更改，并希望内部更新尽可能减少对外部的使用影响。
基于上述考虑，企业能力视图的分层结构如图1所示：
2.3企业能力视图的实体模型
能力视图对外以业务组件为合作伙伴接入点，一个业务组件可以是一个业务能力或者多个常用业务能力的组合，合作伙伴只需要关注业务组件，无需关注底层原子服务的实现细节。企业能力视图的eR模型如图2所示：
（1）关键实体定义
应用与业务组件关系实体：描述第三方合作伙伴与企业能力视图中业务组件的对应关系；
业务组件实体：业务组件信息实体主要是提供给外部用户的业务组件信息列实体，包含一个或多个能力，是合作伙伴的界面视图；
组件成员实体：记录业务组件和各能力对应的组装关系；
能力信息实体：主要用于一个功能域内的固有服务封装，并北向支持业务组件；
能力对应服务实体：记录能力对服务的封装关系；
服务信息实体：记录各个系统、网元提供的对外服务信息。
（2）实体之间的组装调用关系
业务组件与能力、能力与服务之间有串行逻辑调用关系、并行逻辑调用关系、选择分支逻辑调用关系、一一对应逻辑调用关系，具体如下：
串行逻辑关系
一个能力需要依次执行多个服务来完成。能力将前一个能力处理的结果作为下一个能力的入参，最后将处理后的结果封装统一返回给外部系统。
并行逻辑关系
能力与服务的关系为并行逻辑关系，一个能力需要同时执行多个服务来完成。能力将多个服务返回的结果整合处理后统一返回给外部系统。
选择分支逻辑关系
能力与服务的关系为选择分支逻辑关系，一个能力需要先执行一个原子服务，再以这个原子服务的返回值作为判断，判断下一个执行能力为哪个原子能力，最后将第二次执行的结果整合后统一返回给外部系统。
一一对应逻辑关系
能力与服务的关系为一一对应关系，一个能力需要执行一个服务来完成。能力将返回的结果直接封装处理后统一返回给外部系统。
3企业能力视图的运营
3.1企业能力视图的验证
电信对合作伙伴-华悦公司提供积分兑换流量业务组件，对应的应用场景是：当电信用户流量使用超出套餐免费流量阀值后，pCC（policyControlandCharging，策略控制和计费）（由策略与计费规则功能pCRF、策略与计费执行功能pCeF、用户属性存储器SpR组成的策略控制体系）会定位用户所处的位置，华悦公司再根据位置信息推荐用户去华悦最近的门店兑换电信积分，赢得免费流量后，电信对用户上网速率智能提速。此应用可实现合作伙伴的客户引流和用户服务感知提升的双赢效果。
对应的能力服务视图关键信息验证如图3所示：
（1）业务组件：提供给外部用户就近用积分兑换流量、智能提速功能。
（2）业务组件和能力之间的关系：该组件由智能提速能力、套餐余量查询能力、积分兑换能力、位置定位能力组成。其中，智能提速能力（该能力须与华悦公司的营业时间保持一致，在每日晚上22点至上午8点限制使用）分别对应it域的套餐余量查询服务、分组域的智能提速服务和恢复服务，位置定位能力对应分组域的位置定位服务，积分兑换能力（该能力涉及到数据更新，需要在每月1日限制使用）对应it域的积分兑换服务。
（3）能力信息：上述4个能力的属性均包含网络类型，安全级别为高，生命周期属性为无限制（不同能力的生命周期限制在具体的实例层上落地）。
（4）原子服务信息：智能提速服务由分组域pCC提供，套餐阀值查询类服务由it域短信提醒系统提供，位置定位服务由分组域的定位系统提供，积分兑换服务由it域的CRm（CustomerRelationmanagement，客户关系管理）系统提供。
3.2企业能力视图的信息安全
合作伙伴只有通过信息安全审核后才能调用企业能力视图，信息安全审核的要素包括如下：
（1）合作伙伴接入平台描述
项目背景、建设原因、建设依据；
功能描述；
应用场景。
（2）系统结构及安全措施
主机部署方式，网络结构；
接口部署；
应用的部署情况；
应用、主机/数据库账号使用情况；
系统安全措施；
应用日志审计功能。
（3）数据提供及安全分级
描述合作伙伴需从运营商提取哪些数据，数据的安全等级；
向第三方系统提供数据说明。
（4）接入认证方案
与第三方系统对接；
与运营商系统对接；
用户访问。
（5）数据应用方式及范围
向用户展现数据时，采用脱敏处理方式；
从运营商取得的数据是否传送给第三方系统、是否自己存储、存储保存期限；
对于本地存储的敏感数据是否加密存放、采用何种加密方式。
（6）相关合同/协议约束
约定数据范围和用途；
约定数据是否可以提供给第三方；
提供给第三方的清单和使用约定；
约定数据存储内容、存储期限；
约定数据脱敏要求。
3.3企业能力视图的监控
企业能力视图的监控应该包括以下内容：
（1）各业务平台（北向接口）使用企业能力视图监控
各平台使用企业能力视图的业务量监控
针对单位时间调用量达到指定值的进行实时监控提醒，以便对各业务调用能有相对精确的判断；能够对于攻击系统的外部网元进行精准控制，以免冲击系统。
各业务平台调用异常监控（北向接口）
若各业务平台调用企业能力视图的异常量达到指定值（根据错误码进行统计监控），则进行相关的告警提醒，以准确地把控调用异常情况。
（2）企业能力视图和域内各网元交互（南向接口）监控
企业能力视图和域内各网元的长连接监控
针对长连接交互的接口，需要实时监控连接情况，出现异常则进行监控告警。
企业能力视图和域内各网元的短连接监控
制定定时探明短连接服务的任务，定时发送测试消息给相关网元，确保短连接业务调用正常；对于异常调用，则进行监控告警。
对企业能力视图和域内各网元的交互异常监控
根据约定错误码进行统计监控，达到异常情况则进行告警提醒。
（3）企业能力视图内部处理监控
企业能力视图异常监控
针对企业能力视图的各应用程序进行监控，确保企业能力视图的可用性。
4结束语
通过建立企业能力视图，可以将分组域、电路域、it域对外提供的策略能力进行统一识别、表述、管理，屏蔽了底层实施细节。一方面，平滑实现了Ct（网络、平台）、it（系统）的虚拟化和逻辑上的集中控制；另一方面，运营商还可以参照合作伙伴调用企业能力的QoS级别、安全接入等级和流量，并制定相应的收费标准，充分提升企业资源利用效益。
参考文献：
[1]韦乐平.SDn的战略性思考[J].电信科学，2015（1）：1-6.
[2]中国电信北京研究院.中国电信智能管道2.0总体技术方案[Z].2013.
[3]3GpptR36.814V9.0.0.Furtheradvancementsfore-UtRaphysicallayeraspects（Release9）[S].2010.
[4]3GpptS36.101V10.4.0.e-UtRaUserequipment（Ue）radiotransmissionandreception（Release10）[S].2011.
[5]3GpptS36.104V10.4.0.e-UtRaBaseStation（BS）radiotransmissionandreception（Release10）[S].2011.
[6]卢捍华，王亚石，闵丽娟，等.基于nGoSS的oSS/BSS框架[J].电信科学，2009（10）：57-62.
[7]段勇，朱源.业务服务管理在中国电信it运营支撑中的应用研究[J].电信科学，2009（9）：43-45.
[8]胡虹.业务能力封装支撑方式初探[J].电信科学，2010（1）：76-80.
[9]江金龙，周献中，孙勇成，等.基于UmL和petri网的层次建模分析方法[J].系统仿真学报，2006（2）：290-293.
[10]冒益海，韩卫光.基于petri网的柔性制造系统作业调度研究与实现[J].小型微型计算机系统，2010（5）：1001-1005.
[11]张国印，刘铭，姚爱红，等.基于扩展petri网的系统建模及形式化验证方法[J].计算机应用研究，2010（12）：4587-4590.
作者简介