现金贷产品的实现与设计思路详解

第一篇：现金贷产品的实现与设计思路详解

现金贷产品实现与设计思路解析

现金贷产品的本质是信用贷，其产品定位为小额、高息，面向低信用质量的用户群体。单客放款额度低，但是用户申请门槛同样降低；坏账率高，但是提高年化总利息费用。最终，放款总额仍得以保障，而使得利息收入覆盖坏账，实现总体盈利。

一、用户操作

需要借款的用户，通过账户注册、选择借款方案与提交个人数据，即可完成借款申请流程。在这一系列的流程步骤中，不同平台基于各自不同的风控体系，所需用户提交的个人相关数据也略有差异。通常可细分为如下信息内容： 账户注册：手机号短信验证。

借款方案：基于不同期限与金额的方案选择。通常，借款期限越短，费率越高。实名认证：基于真实姓名、身份证号的输入验证。此外，也可补充要求上传身份证或手持身份证照片。如果要求更严格一些，则可仅允许用户实时拍摄的完成身份照片的获取，以保证用户身边携带有身份证。

收款银行信息：接收放款的用户银行账号信息，最好进行有效性验证，匹配用户的姓名、手机号与银行卡的真实一致性。

手机运营商服务密码校验：对用户在用手机号的服务密码验证，实质为获取用户近期的有效通话记录数据。通常，需要用户进行二次验证码的确认与输入，部分仅需一次验证。

电商数据的获取：需要用户输入个人的电商账户与密码，实质为获取用户近期的有效网购记录与收货地址。目前，有对淘宝和京东的电商数据进行爬取。联系人：提交1~3位联系人，输入其姓名与手机联系方式。结合三方征信平台，可辨识出提供的联系方式是否为小号等。

社保与公积金记录：通过用户输入社保与公积金账户与密码的方式，爬取获取用户近期的有效缴费记录。

学籍信息：通过用户在学信上的账户与密码，爬取用户的学籍信息，与用户的身份信息进行匹配。

职场社交数据：对脉脉与领英等职场社交平台的账户与密码验证，以获取用户已认证的相关职场社交信息。

央行征信数据：大平台拥有对接央行征信数据的能力，但其他平台更多的是通过引导用户获取个人征信报告的方式，导入与解析用户的征信数据。需要用户注册央行征信系统的账户，并申请校验码。

本地通讯录数据：获取访问手机本地通讯录的权限，获取用户手机联系人与通话记录的数据。

地理信息：当前操作的GPS地理信息，需用户允许产品进行获取。

上述内容大致可分为三类：

用户现金贷账号，注册手机号与借款方案申请。

用户信息输入项，从用户的实名信息、通讯信息、电商数据到征信数据等，需要用户通过自有账户与密码提供的方式获得。而用户输入信息的多与少，与现金贷平台对用户的放款金额和费率的高与低，成正比。通常而言，由于现金贷单笔500元、1000元、2000元等常规小额放款金额，并不会让用户进行大量的信息输入。其中，必要输入项仅为实名身份信息，其余均可为可选补充项。系统自动获取信息，本地通讯录与地理信息，仅需用户在提示弹窗中同意授权，即可在后台完成信息的收集。

二、流程阶段

现金贷产品有效的产生业务的用户，其用户单次生命周期可分为：“借款申请”、“借款审核”与“放款还款”这3个主要的阶段。

借款申请：对应到本文第一部分的用户信息提交内容，而除了用户前端的操作部分以外，根据用户提交唯一识别性数据内容，系统后台可请求该用户的三方征信数据。

借款审核：现金贷产品没有绝对的裸放，“借款审核”便是运行自有风控体系的环节。有的平台，采取系统实时自动审核的方式进行处理；也的则采取全人工的方式，此类通常会结合客服的电话回访或对联系人的确认环节一并完成；还有的，则可结合申请时间段进行灵活设置，譬如白天系统自动处理，晚上则转入第二天的人工审核。总而言之，借款审核是根据自有一系列的规则运算，得出该用户的此笔借款申请是审核通过、审核拒绝，还是人工审核处理。放款还款：通过审核的用户借款申请将进入放款环节，利用三方支付平台的实时代扣借口即可实现，快则10分钟内用户即可收到放款资金。而主动还款则需要用户重新登录到产品之中，以支付方式完成还款。自动还款功能则在用户的配合设置下，可通过三方支付的代扣接口实现。

对于这三个阶段，产品的侧重重点也各有不同。“借款申请”重点在前端体验，需要明确进行步骤与步骤之间指引与交互，做好信息的提示与输入。“借款审核”核心在于后台的系统处理，基于已获取数据的解析，与自有的风控规则进行匹配判断，后台的借款记录与风控规则的触发是工作重心。而“放款还款”的侧重便是在资金通道上，做好与三方支付的对接，辅助做好短信信息内容的推送等。

三、风控

现金贷的风控需要现金贷的产品特色与定位相匹配，即轻度风控的策略。现金贷的风控核心在于判别用户的还款意愿，而非用户的还款能力。而防骗贷的专业集体行为则是风控的重点目标。

整个风控体系通常由两部分构成，一个是对接三方征信数据的反馈结果，另一个则是自定义的一些风控限制性条件。

三方征信作为外部源，需要现金贷平台将其已验证的用户个人信息内容，如手机号与身份证号信息进行传输。然后，三方征信利用自己的大数据优势，将此用户的全面信息进行反馈，并给出评测分与建议结果（通过、拒绝或模糊）。基于反馈回来的数据结果，现金贷自有的信息可进行二次的风控规则判断，例如达到三方征信平台评测分X以上的用户，拒绝其借款申请；或者可更深入到子类别的数据维度进行判断。

现金贷平台的自有风控体系，则重要基于防集中性与防欺诈性的考量。集中性，可对于申请IP、区域的申请金额上限、申请时间段、身份证号段进行一系列的限制性控制。欺诈性，则是可利用重力仪、设备信息等数据进行判别，对用户所提交的联系人与通讯录数据进行黑名单匹配处理等。

在这一系列的规则校验过程中，区分出哪些是必要条件，哪些是辅助可选条件。先运行现金贷产品的本地必要规则，将初步符合条件的记录再进行三方征信数据请求，以提高数据处理与征信成本的代价。而风控系统完善到后期，将单个借款订单申请的审核上升到用户的总授信额度之上，可以灵活地处理一些非必要数据缺失的其他可选替换校验方案，并能够定义不同数据的有效时间性。

总体来看，现金贷产品并不建议在单个用户身份投入太大的征信支出。现金贷小额分散的产品定位策略，便是其最大的风控措施。

四、运营推广

现金贷产品通常一上线，什么推广都没做，当天就很有可能直接流入数千的新增用户。每个行业的背后都有产业链条，新上线的现金贷便是一个新开的“口子”。不少微信群、QQ群、贴吧、论坛，其主题便是各类借贷攻略、下款测评，不少群主和淘宝卖家便是其中组织者，他们以信息服务进行收费，有的甚至专业组织集团撸款。只要在这个圈子里，有人亲测下款成功，新上线的现金贷产品也会立即被推广到各群组之中。

对于这部分用户群体是否为现金贷的主要目标用户群体的问题，从业务逻辑上来看，如此高额的利息承担，注定了是信用质量最底层的一批用户群体，优质必然优先选择利息成本较低的借贷品种。在这些用户之中，多头循环借贷的比重可能占了绝大部分。而风控要过滤的是职业骗贷的行为，即虚拟的集中借款申请，如果是真实有效的用户借款申请，其又不在黑名单之中，无不良逾期记录（还款意愿），其借贷行为非不可控（借贷次数），则原则上是可以通过借款审核的。

所以，现金贷的用户群体是一批特殊的、部分被组织的用户。早期的运营策略，以最低的代价让这个圈子内的人知晓有此产品上线即可，方式可以只要是论坛中一两篇软文、群中的发声提示，就能激起这个产业链的传播链条„„

后续，产品功能方面配合运营推广可以推出“邀请好友”的功能模块，但其核心在于邀请的激励机制，真实普通借款用户的激励点在于“提额”与“免息”奖励，而“群主”等意见领袖的激励点则是“现金”。此外，常规的运营推广是渠道合作，通常以CPS方式进行，具体的代价成本与渠道的质量和现金贷的借款申请通过率相关。

五、催收

现金贷给出的单一时间段的用户可借款金额并不高。所以，其逾期通常便是一两千金额的逾期。由于金额较低，即便发生了坏账，催收方式仍将停留在电话层面的催收，基本不可能采取实地催收，甚至是法院起诉的方式。

基于此催收特点，在用户借款申请过程中，收集的用户通话记录与通讯录联系方式等，便是未来进行电话催收的措施保障。

对于用户个人，在还款到期日前及当日，现金贷平台可进行还款提示短信的推送；而在逾期发生之后，可在固定的时间点进行催收短信的推送。此外，则是人工客服对该用户的电话催收。如果这些并无作用，则系统将利用用户所提供数据进行催收，对其常用联系人、单位联系方式进行人工或系统的短信与电话催收。到了这一阶段，便是借助系统的批量式信息轰炸。

产生的坏账数据与用户黑名单，从各家现金贷平台的利益驱动性来看，其并无动力将其数据上传与共享到外部平台，除非是基于黑名单数据交换的考虑。因为在一家平台中的借款金额，可以用另一家平台的放款金额进行填充，不分享逾期记录也是为用户未来可以拆借填坑留下余地。

博采网络---现金贷研发部 资料整理：祝经理 ***

第二篇：现金贷催收业务流程

现金贷催收业务流程

催收业务流程图借款人催收系统支付公司催收员放款成功还款日生产代扣清单扣款报盘进入下期还款是足额扣款否回盘结果结束生成催收任务自动分案获取任务使用催收工具无有无承诺有发起代扣请求

第三篇：现金贷CPS合作协议

XXX与XXX CPS合作协议

甲方： 乙方：

为促进双方业务的健康发展，甲、乙双方本着“平等互利、共同发展、优势互补”的原则，经友好协商达成本合作协议。双方承诺恪守本协议的各项条款。第一条 合作事项

1.乙方接受甲方委托，向甲方推介通过乙方渠道申请指定产品融资借款的借款申请人名单（以下简称“借款申请人”），就其与甲方或甲方合作的贷款方之间可能发生的融资借款业务（以下简称“融资借款”）提供业务信息推荐、站内推广、信息收集等相关方面的服务，配合甲方开展相应业务。

2.乙方为甲方推广业务的渠道为乙方所经营的网站/App/微信公众号。

第二条 甲方的权利和义务

1.甲方应保证其有合法资质从事融资借款业务的相关咨询与服务。

2.甲方应向乙方明确甲方或甲方合作的贷款方所提供的融资借款产品（以下简称“产品”）及其借款申请人的标准，并及时向乙方更新相关信息。

3.甲方应确保向乙方提供的产品及申请条件符合甲方所在机构的官方描述。如有不符，乙方有权在告知甲方后依据甲方所在机构的官方描述进行修改。

4.甲方应按本协议或双方后续具体约定，及时与借款申请人就融资借款事宜进行联系。

5.甲方或甲方合作的贷款方对借款申请人的借款申请有完全的选择权和审批决定权。

6.甲方应每月向乙方反馈借款申请的审批结果及进度更新情况。如果有特殊情况不能及时提供的应提前通知乙方。

7.甲方对不符合甲方要求的借款申请予以否决的，可以视情形向乙方反馈拒绝原因，以利于乙方在筛选客户中改进。

8.由于甲方或甲方合作的贷款方的审批结果或放款事宜与借款申请人产生的任何争议，乙方无过错的（乙方过错包括不限于第三条第2款、第6款列举的内容），应由甲方与借款申请人协商解决。

9.如甲方或甲方合作的贷款方需调整融资借款产品的种类、申请条件等内容，应提前七个工作日通知乙方，以便乙方进行更新。

第三条 乙方的权利和义务

--

1.乙方应保证其有合法资质从事本协议内所述的相关业务。

2.乙方向甲方导流的借款申请人资料完全基于借款申请人自愿填写，乙方不得暗示、诱导、配合借款申请人提供虚假资料。

3.乙方不会参与及影响甲方的审批工作。因借款申请人未能按时归还甲方融资借款或与甲方就业务发生争议且乙方无过错的（乙方过错包括不限于第三条第2款、第6款列举的内容），由甲方自负风险和费用解决，与乙方无关。4.乙方同意：

（1）如经乙方推荐的借款申请人同时通过其他渠道向甲方提交贷款申请，甲方将会以提交时间较早的为准；

（2）如乙方推荐的借款申请人转向申请未经甲乙双方约定推广的甲方其他产品并成功放款的，该客户不计入乙方推荐申请人名单。

5.乙方不得利用因本协议向甲方提供服务之便，将甲方在本协议项下向乙方提供的资源用于从事业务推广代理或客户推介以外的活动。

6.乙方只可以甲方合作机构的名义开展业务营销，不得自称为甲方，且不得擅自代表甲方向客户做出任何承诺，不得误导宣传甲方产品，不得有损甲方商誉。7.乙方应及时更新甲方提供的产品及借款申请人的标准。因未及时更新上述信息导致的甲方及借款申请人的争议、损失等，由乙方负责处理并承担赔偿责任。

第四条 服务费:

1.甲乙双方约定，采用下列方式支付服务费：

乙方提供客户经甲方审核通过并放款后,甲方按放款金额的%一次性向乙方支付服务费用。

如客户复贷并经甲方审核通过放款，复贷服务费说明如下：

2.服务费用按月结算，每个自然月第5个工作日之前甲方书面通知乙方上月费用。乙方按照双方确认的金额向甲方开具等额的、合法合规的、符合甲方要求的增值税专用发票，甲方于收到乙方开具的发票后10个工作日内支付给乙方。甲乙双方自行承担按照税法规定的各自税费。

如乙方延迟、拒绝提供增值税发票或开具虚假、非乙方抬头的增值税发票的，甲方有权延迟、拒绝支付服务费，该行为将被视为乙方违约并应承担违约责任。

3.乙方推荐的借款申请人为甲方现有客户并以借新还旧方式提取贷款的，其计算服务费的批核金额减半。

4.乙方推荐的借款申请人（包括联名申请人）如曾经从其他渠道向甲方申请贷款而申请结果为“取消”，且甲方已经明确告知或者有证据证明乙方明确知悉该等“取消”结果的，从取消日起计算至乙方推荐申请日未满60天的，不计算服务费。5.乙方推荐的借款申请人（包括联名申请人）如曾经从其他渠道向甲方申请贷款而申请结果为“被拒绝”，且甲方已经明确告知或者有证据证明乙方明确知悉该等“被拒绝”结果的，从被拒绝日起计算至乙方推荐申请日未满180天的，不计算服务费。

6.乙方指定用以接受甲方费用的银行账户如下：

开户名： 开户行： 开户行账号：

7.在双方协商一致的情况下，可以根据推荐业务量、推荐成功率等因素，对推广服务费用标准进行调整。

第五条 保密条款

1.甲方只能将乙方提供的借款申请人信息用于其自身相关产品，不得向第三方（根据法律规定、司法机关及监管机构要求的除外）披露借款申请人的任何信息。但与甲方同属于同一控股股东的关联公司，以及与甲方关联公司合作的贷款方，不属于此处受限制的第三方。

2.本协议任何一方对在合作过程中所获知的对方未公开的合作信息和商业秘密均负有保密义务，除法律另有规定外，未经对方书面许可，任何一方不得将其泄露给第三方，也不得用于在本合作项目之外的任何用途，否则应承担违约责任并赔偿损失。3.本条约定的保密义务在本协议终止或提前解除后仍持续具有约束力。

第六条 协议期限

1.本协议自双方签字盖章之日起生效，至年月日终止，本协议终止不影响甲方向乙方结算服务费用及风险金（如有）。

2.甲乙双方中任何一方对合作效果不满意，可与对方就本协议方案进行商讨，如双方未达成一致，经甲方通知停止合作后，该合同会自动终止。但在该等终止之前各方在本协议项下应履行之义务（包括付款义务和结清服务费的义务等）应继续履行。本协议终止后并不影响任何一方在本协议终止前已享有的任何权利。

3.本协议有效期届满前30天，如双方中任何一方均未以书面形式提出终止合作，本协-3

议自有效期届满日的次日起自动延续1年。

4.甲乙双方确认以下地址为接收前述终止协议通知的送达地址：

甲方地址： 乙方地址：

任何一方按以上对方送达地址以特快专递或者挂号信方式邮寄，对方签收或寄出后三日（以先发生之日为准），即视为送达。若一方送达地址发生变更，应及时书面通知对方。否则上述地址(或原地址)仍视为真实有效地址。

第七条 违约责任

1.任何一方违反本协议的任何条款、不履行应尽之义务或者履行义务不符合本协议之约定的，则应被视为违反了其在本协议项下之义务。守约方有权发出书面通知要求违约方于收到书面通知之日起三日内纠正其违约行为。违约方逾期不纠正或无法纠正的，守约方有权立即解除本协议，并要求违约方赔偿守约方因违约行为而遭致的全部损失。

2.若任何一方因另一方故意或重大过失（以下简称“过错方”）而遭受到借款申请人或任何第三方的索赔，由过错方承担由此而产生的全部责任，包括向该一方补偿由此而产生的损失。

3.如甲方迟延付款，则每逾期一天，应按应付服务费的0.05%向乙方支付违约金。延迟交付给乙方造成其它损失的，甲方还应承担赔偿责任。

第八条 反商业贿赂条款

1.甲乙双方都理解并愿意严格遵守中华人民共和国反商业贿赂的法律规定，双方都理解任何形式的贿赂和贪渎行为都将触犯法律，并将受到法律的严惩。2.甲方或乙方均不得向对方或对方经办人或其他相关人员索要、收受、提供、给予协议约定外的任何利益，包括但不限于明扣、暗扣、现金、购物卡、实物、有价证券、旅游或其他非物质性利益等，但如该等利益属于行业惯例或通常做法，则须在协议中明示。

3.如因一方或一方经办人违反上述之规定，给对方造成损失的，应承担损害赔偿责任。

4.本条所称“其他相关人员”是指甲乙方经办人以外的与协议有直接或间接利益关系的人员，包括但不仅限于协议经办人的亲友。

第九条 其他

1.甲乙双方在本协议项下的所有权利义务，未经对方书面同意,不可转让于第三方。2.其他未尽事宜，依据我国法律法规、有关规章及甲方相关规定办理。协议履行中发生争议的，双方应协商解决。协商不成的，可向甲方所在地有管辖权的人民法院提起诉讼。在诉讼期间，本协议中不涉及争议部分的条款，仍须履行。本协议适用中国法律。

3.本协议正本一式贰份，甲、乙双方各执壹份，具有同等法律效力。

4.本协议的附件、补充协议（若有）为本协议的组成部分，与本协议具有同等法律5.-5

[签字页]

甲方 :(公章)

乙方

姓名

：

:

（公章）；

： 姓名 ：

签署日期 签署日期

第四篇：医院科研教学管理的设计思路与实现

医院科研教学管理的设计思路与实现

医院是医疗、教学、科研、预防四位一体的事业单位。医院的信息系统本应该根据这四项基本任务，建立两大平台，即医疗平台和管理平台。全面覆盖医教研防四项基本任务。而科研、教学平台是管理平台中的重要组成部分。但是，由于种种原因，到目前为止，多数医院的信息系统仅仅只搭建了医疗平台。管理平台的建设，还没有引起足够的重视。随着医院计算机应用水平的提高，管理平台的滞后的矛盾逐步尖锐起来。尽快建设科研教学管理平台，利用计算机技术全面管理人员、科研、教学工作中的各种事务，是很急迫的任务，是医院信息系统拓展的组成部分，也是强化医院内部管理的重要途径。

一、医院科教管理平台建设的现状

近年来，我们在推广应用《医院技术档案管理系统》、《医院科研管理系统》、《医院临床教学管理系统》和《医院继续教育管理系统》的实践中，与国内200多家医院进行了不同程度的沟通。发现许多医院的信息系统发展极不平衡。主要体现在医疗平台逐步强大，而管理平台越来越滞后。决策人员可以方便地掌握每一个病人的信息，却不能掌握员工的信息。许多医院还没有把科研教学的计算机管理列入议程。经分析，其主要影响因素有以下四个方面。一是投入不足，信息系统建设缺少正常的投资渠道。在当前大环境下，医疗工作承担了创收任务，而其他三项工作则放在了节支的范畴。与医疗工作相比，教育、科研、预防都有不同程度地削弱。二是认识不足，没有确立以人为本的管理理念，对人的管理和对事务的管理仍然满足于粗旷的定性管理，没有发挥计算机的管理功能。三是没有从全院的层面，统筹考虑计算机网络的应用。职能科室基本上仍然处于单机阶段。逐步形成了许多信息孤岛。一些医院甚至会有十几个人员数据库，相互又不能沟通，极易造成紊乱。一些事务被重复管理，另外一些事务却没有部门管理，到了晋升、评审等急需提供数据的时刻，谁也拿不出有说服力的数据。四是还没有适合我国国情的、全面管理人员、教学、科研的平台级的应用软件系统。这些影响因素如果不尽快排除，建设医院科研教学管理平台就成了空话。

二、科研教学平台的体系结构

科研教学是全院的工作。科研教学平台是全院共同使用的工作平台。医院科研教学管理平台的建设，一定要从全局出发，统筹规划。

完整的科研教学平台应包括数据库服务器，网络，客户端工作站、Internet接入方案和网上教育及学分授发的控制设备。应建立专用的数据库服务器。经授权的联网计算机，可以访问该服务器。服务器可放置在信息中心的机房内，也可放置在机关的某个位置。服务器的物理安全性能（防毒、防黑、防侵入），应由计算机中心负责维护，数据库的安全性（备份、恢复），应由医院指定专人负责维护。近年来，随着Internet应用的发展，医院办公已经不能离开Internet环境。平台内的学分管理、远程教育和网上学习等子系统，本身就需要使用Internet环境。因此，建立安全的Internet接入方案也是搭建科研教学管理平台的组成部分。可以采用有效的措施，使该系统与医疗管理平台进行必要的连通和割断，但为此单独建立一套网络是不可取的。另外，在较大的医院，在人事处、科研处、教育处、医务处、护理部等部门内部建立小型局域网，只能当作是过渡期间的权宜之计，不能继续鼓励这种做法。随着管理的深入，这种互相不连接的小网络，容易给管理带来紊乱。

三、科教管理平台管理的范畴

科教管理平台的要管理医院科研、教学工作中涉及到的人员、事务和过程。也就是说，科研教学平台管理了一个由人员、事务和时间构成的三维空间。但是，当前的网络和计算机环境，还不能象安全监控系统那样，把科研教学中是所有事务都记录在案。即使能够达到，这也不是管理。管理则必须从这个三维空间中，择取一些点来进行管理。也就是择取某些有代表意义的事务进行管理。这也是计算机管理的切入点。由这些点组成了三条线，既时间线、人员线和事务线。如果以人员作为主线，可以追踪出人员在不同时期所参与的各种事务。如果以事务为主线，可以追踪到各个事务的过程和所涉及的人员。如果以时间为主线，就可以追踪出人员和事务在不同时期的状态。医院的各种统计数据，都是对某条线的取值。这样的系统，不是面向报表来设计的，而是面向各个职能科室的日常工作的，但却能为任何报表提供数据。

从提高办公效率，降低管理成本角度来看，科教管理平台首先要对医院各职能科室的日常工作给以充分的支持。职能科室是在完成自己承担的任务的同时，即利用了平台，又维护了平台，还积累了数据。而不是为了平台的完整而录入数据。根据我国医院的实际情况，科教管理平台至少要涵盖到人事处、医务处、护理部、科研处、教育处、院办和党办等职能处室。至少要管理以下37项具体事务，即课题管理、成果管理、专利管理、论文管理、著作管理、进修管理、培训管理、个人出席学术会议管理、新技术新疗法应用管理、学术职务管理、奖惩管理、技术考核管理、个人履历管理、个人证件管理、带教管理、青年医生临床轮转管理、青年医生医德医风管理、青年医生阶段总结管理、本院学术讲座管理、承办主办学术活动管理、外来进修人员管理、继续教育管理、学历教育管理、学分IC卡管理、师资力量管理、教学计划管理、课程与课管理、学籍管理、教学津贴管理、教学经费管理、科研教学仪器设备管理、论文推荐管理、注册医师管理、注册护士管理、支边医师管理、支农医师管理、基层锻炼管理等等。这37项事务中，有些事务本身还可再分解为多个事务。以课题管理为例，还可以细分为基本信息、参研人员、获奖情况、预算、经费、过程等。试想如此如此繁杂的事务，如果没有一个好的平台，要管理好这些事务是很难办到的。换句话说，如果没有把这些事务管理得井井有条，没有处理好每一个细节，加强医院管理也就成了空话。从另外一个角度来看，如此繁杂的事务，如果没有一个平台级的系统同一协调，也很容易造成紊乱。

四、科教管理平台的设计思路

科教管理平台的目标，是为医院科研教学工作实现全面计算机管理提供综合解决方案。让医院各个职能科室在统一的平台上共享全院数据，处理日常事务。从而提高办公效率，节省管理成本，提高管理水平。在系统设计思路上，我们认真考虑以下几个方面。

㈠、以人员为主线，建立人员基本信息和分项信息 医院管理要以人为本，科研教学管理平台也应该以人员为主线。科教管理平台应管理全体员工而不是其中的一部分。与普通的企事业单位不同的是，人员的信息分散在医院的很多职能科室内而不仅是人事管理部门。比如，人员的进修、培训、会议、论文、著作、课题、成果、专利等信息可能在科研管理部门。继教、学分、带教、授课等信息在教育管理部门。医疗技术人员的准入信息，支边、支农、基层锻炼信息，技术人员持证上岗信息等可能在医务处，护理人员的注册、培训、进修、带教、讲学等信息可能在护理部。除此之外，医院往往还运行了一些专业系统，如离退休人员管理、党务管理、团务管理、纪检管理等等，他们都是从总体中选择了一个子集以及某些具体的事务进行管理。科研管理平台应该将这些分散存在、各家维护的信息整合在一起，保证一个医院只有一份人员基本信息（One Hospital One Empoyee Table，OHOE）。分散在各职能科室的、与人员相关的信息，可看作是人员的分项信息，如科研课题、成果、论文、著作、注册医师等等。分项信息与基本信息之间必须建立牢固的联系。分项信息是一个可无限扩展的空间。根据目前管理的精度来看，三级医院大约需要40多项，二级别医院大约需要20多项。它本身具备很大的伸缩性。㈡、以日常事务管理为切入点，全面支持职能科室的日常工作

事务是一个具体的活动。职能科室的日常工作，主要是对日常事务做出某些处理。用计算机来管理事务，其结果可能是增加或减少了一些记录，或是改变了某个属性的值，或是记录下来某种变更发生的时间和地点等。以调资为例，最终的结果是改变了部分员工的工资值。如果管理平台足够强大，这项事务可以在瞬间完成。科教平台就是要为医院各个科室，尤其是承担管理任务的职能科室，提供日常办公的软件环境，当管理人员处理某些事务时，平台向他们提供足够的信息和方便的处理手段。许多日常事务的处理过程都涉及到人员分项信息的改变，也就是说，人员分项信息就是伴随着日常事务的改变而得到了更新和维护。把需要管理的事务有机地组合在一起，就形成了不同职能科室的专用系统。㈢、合理分工，保证信息的完整性

目前，我们将与科研教学工作相关的事务，按照医院现有的分工，组织为技术档案系统、科研管理系统、临床教学系统、继续教育系统，住院医师标准化培训管理系统等。科研管理系统是科研处的专用系统，继续教育管理系统是教育管理部门的专用系统。而技术档案管理系统则不同，又根据各个职能科室的管理范围进行了划分。在医务处看到的技术档案系统，显示全院的医生和医疗技术人员和相关的分项信息。在护理部的技术档案中，只显示全院的护理人员和相关的分项信息。党委、团委、离退办、纪检等部门也能够看到自己需要管理的人员。只有人事处和院领导看到的是全院人员和全部分项信息。这种分工是不仅是管理的需要，也是保证系统数据完整的需要。有些医院曾经建立了强大的人事管理系统，系统也曾经想管理人员的各个分项信息。但是，由于人事部门本身没有承担这些管理职能，信息的原产地不在人事部门，相应的信息始终不能进入计算机内。分项信息应该在信息原产地进入计算机内。进入计算机内的信息就成为共享的数据，但是，它的维护权仍然划归原始录入部门。需要特别强调的是，人员基本信息最好由人事部门维护。

㈣、信息整合，避免信息孤岛

科研教学管理平台是一个整体。最理想的情况是在医院局域网上运行，全院使用同一个数据源。但是，多年来，医院已经运行了许多专用的系统，如何对现有的信息进行整合，消除信息孤岛，是我们面临的挑战。信息整合是搭建科研教学平台的组成部分。整合的核心是人员信息。只有全院使用一份人员信息，才能从根本上消除信息孤岛。系统要在充分继承原有数据的基础上，改造原有数据，使其成为全院共享数据的组成部分。

五、科教管理平台的实现

在以上设计思路的指导下，经过多方协作，于2006年3月，我们在Windows网络环境下，实现了医院科研教学管理平台。目前已经在国内多家医院投入运行。实现过程中，我们特别注重以下几个方面。㈠、数据库设计

数据库系统必须采用支持并发事务的网络数据库。我们选择了MS SQL Server 2000及其后续产品。人员基本信息单独建表，人员的每一个分项信息都建立相应的数据表。分项信息一方面与人员基本信息建立固定联系，一方面与各个具体事务建立固定联系。例如，一个员工可能参加过很多课题，人员与课题组成主从关系。而一个课题又有很多参研人员，课题与参研人员也是主从关系。我们用类似的方法将所有事务与人员进行了关联，充分利用了关系型数据库固有的特点。为支持人员的分类别管理，我们建立的大量的视图。另外，由于人员的分项信息带有不确定性，我们建立了扩展标准并设计了模板数据，可根据用户的需要不断扩展。㈡、模块化设计，按需要组装

科研教学管理平台采用了混合结构编程。各职能科室使用的子系统，采用C/S结构。向院领导或医院网站提供的查询信息，采用B/S结构。

我们以人员基本信息和分项信息为主线，设计了《技术档案管理系统》，统一界面，在各职能科室的子系统中只显示了不同的视图。技术档案具有继承性、封装性和多态性。继承性就是全院各科室看到的人员，都来自同一个数据表。封装性是根据各职能科室的分工，向不同科室提供不同的人员分项信息。而多态性是不同的管理部门只能看到本部门管理的人员和这些人员的分项信息。

对上述的37个具体事务的管理，我们尽量使其模块化。每个事务本身可以做为一个独立运行的程序存在，也可以根据医院的实际分工，有机地组装在面向职能科室的子系统内。例如，在科研处使用的《科研管理系统》中，我们组装了课题管理、成果管理、专利管理、论文管理、著作管理、科研教学仪器设备管理、承办主办学术活动管理等模块。在教育处使用的《临床教学管理系统》中，组装了师资力量管理、教学计划管理、课程与课管理、学籍管理、教学津贴管理、教学经费管理等模块。这些模块是医院科研教学管理平台上的原材料，还可以根据医院的实际，组装成各种各样的专用系统。㈢、绩效考核的实现

绩效考核是医院落实目标管理的需要，也是对平台积存数据的深层次挖掘。为充分利用数据，定量考核科室或人员的绩效，我们择取了课题、成果、论文、著作、专利、进修、培训、带教、学术会议、新技术应用、学分等11项事务纳入个人和科室的绩效考核。提供了核定考核单元、圈定考核范围、修订考核策略、审核11项考核内容等工具，最终可以对技术人员和科室进行科研教学绩效进行定量评定。评定结果以总分、平均分和指标完成度三种方式体现。该系统是建立在科研教学管理平台之上的智能决策系统，只有在系统良好运行的前提下，才能发挥出它的智能决策作用，同时，该系统也有效地检验了科研教学平台的完整性和实用行。㈣、信息遗漏的控制

不管多么强大的系统，如果遗漏了数据，或采集的数据不够准确，系统就不可能发挥应有的作用。为避免数据遗漏，我们涉及了三个控制点。一是费用报销点。许多事务涉及版面费、进修费、差旅费等费用管理。为此，我们设计了大量的费用审批单，如果管理部门将这些审批单作为费用支出的依据，就能够有效地避免数据遗漏。费用审批信息还可以同步传送到财务部门，便于财务对费用的控制。二是与学分关联。学分已经成为继续教育结果的评判指标，许多事务涉及到学分的授予，这些事务如果没有录入，就不能获得学分，这样也可以避免一部分数据遗漏。三是绩效考核，如果该进入计算机的内容没有及时进入或者没有正确进入，相应科室的绩效考核分数会受到影响，这为避免数据漏提供了监督机制。

五、科研教学管理平台建设存在的问题和研究方向 科研教学平台建设，是一个伴随着医院管理逐步深化而出现的新生事物。任何新生事物的成长过程都是困难的。这些困难主要反映在以下几个方面。

首先，在医院是否应该建设科研教学平台的问题上，并没有形成共识。在信息化时代，医院仍然采用粗旷型管理是没有出路的。但是，如何从粗旷管理过渡到集约型管理，却有很多模糊认识。当国内医院普遍建立了医疗费用管理平台以后，向病人提供详尽的费用清单才成为现实。区域性医疗保险的实施才有了基础。我们可以借助医疗费用管理平台，统一医疗收费价格，进行单病种管理和医疗成本核算。如果没有这个平台，这些管理理念不可能实现。同样，如果没有一个管理平台来全面掌握医院所有人员和关键事务的情况，那么，对人对事的管理不能说是到位。我们期望医疗行政管理部门和医院决策层人士对此给以足够的重视。

其次，科研教学管理平台是医院的基础工程。应该由院领导通盘考虑，分步实施。如果由各职能科室牵头，很难保证系统的完整性。实践证明，先实现各个职能科室的计算机管理，再把各个科室用网络串联起来，并不等于管理平台。信息高速公路并不是信息小道的合并。

第三，管理平台建立以后，对管理层的计算机应用提出了新的要求。一旦投入运行后，数据库内逐渐增加大量数据，这些数据就是医院各种管理要素的原始仓库。应用人员如果能够活用这些数据，将给管理带来极大的方便。目前，结构化查询语言（SQL）已经成为工业标准，也是打开知识仓库的钥匙，医院管理人员应该掌握这个工具，提高计算机应用水平，促进医院管理。

科研教学管理平台还存在很大的优化空间。平台的总体目标、投资额度、组建方式、管理范畴、管理粒度和实际应用等具体问题，在国内还缺少深入的研究和实践。医院的规模不同，关注点不同，平台建设的重点也有很大区别。软件系统还需要在更多医院进行磨合，才能更加成熟。我们还期望卫生行政管理部门进行适度干预，提高医院管理层对管理平台的重视程度，的降低平台推广应用的难度。

第五篇：劳保用品管理系统的设计思路与实现2009

基于WEB的物资管理系统设计思路与实现

撰写人：李庆洋

审核人：马向玉

单位：第七油矿

二○一二年四月

【摘要】

物资是物质资料的简称，一般说来，它包括全部生产资料和生活资料。在油田企业中，物资管理主要指生产过程中消耗的原料、材料、燃料、辅助材料、工具和设备等，对企业生产经营活动所需各种物资的采购、验收、供应、发放、存储等一系列管理的总称。物资管理是企业管理的重要组成部分，是企业组织生产、获得经济效益的基础。现代企业的物资管理正朝着电子化、信息化、精细化的方向发展。随着企业物资品种和样式的增多，手工管理物资已不再适应企业的需要。逐步实现物资的精细管理（计算机管理）是必然的出路。结合一年来开发、使用的经验，本文深入探讨了物资管理信息系统的设计思路、实现方法和应用。

【主题词】物资管理计算机管理物资管理信息系统

近年来，随着企业改革的逐步深入，企业内部的许多日常事务实现了计算机管理。用计算机管理物资的各项事务，取代手工管理是必然的趋势。为了使矿级对小队各部门的物资管理更加简单化，精细化，也为了使小队申报物资更加方便快捷，本文针对我矿物资的计算机管理进行深入讨论，公布自己的设计思路和实现方法以抛砖引玉。

1物资管理系统的需求分析

1.1劳动保护用品的发放标准及发放管理是劳动保护制度的组成部分。多年来，劳动保护制度在保障职工安全和健康、促进企业发展等方面发挥了积极的作用。近年来，随着企业改革的深化，劳动条件、工种岗位、保护方式方法等都发生了很大变化。劳保用品的品种、发放标准以及管理方法都有待改进。使用一套统一的软件系统，全面管理劳保用品相关的各种实务，是企业深化改革的需要。也是降低劳动强度，减少管理成本，提高管理精度的需要。

1.2 劳保用品管理系统信息的主要来源，是各基层单位的《个人劳保用品发放卡片》。该卡片依据《劳动保护用品发放标准》登记了每个职工应该发放的品种和发放频度。而《劳动保护用品发放标准》是由大庆油田有限责任公司依据各工种的作业条件来制定的。假设某基层单位有50个职工，分别属于10个工种，涉及到的劳保用品的品种有82种，每个品种有1-10个型号，要准确计算出应该在何时将何种型号的劳保用品发放给哪些职工，其可变化因素的总和约为41万个。手工管理条件下，实现劳保用品的精确管理是一件很难做到的事情。利用计

算机技术实现劳保用品的精确管理是本系统的基本任务。完全取代手工管理是系统的目标。

1.2 精确管理的内涵，在基层单位和上级主管部门之间有明确的区别。从基层单位来看，侧重于准确掌握职工劳保用品的发放信息，及时将劳保用品发放到应该发放的职工。而在上级主管部门，侧重于掌握以前的消耗情况和准确预测未来的需要量，及时筹措资金。由于使用期限的差异和周期性集中发放造成的“扎堆”现状，劳保用品的需要量会出现明显的大小年现象。准确预测资金需求格外重要。另外，上级主管部门要不断地修订劳保用品发放标准，系统应该为各种改变计算出投入量和节省量。

1.3《劳保用品发放标准》在一定范围内推行时，应该具有权威性，严肃性。不允许人为地放宽和削减。也不允许延迟或提前。因此，系统应该为新标准的建立、修订和实施提供强有力的支持。要方便上级主管部门及时准确地监察审计基层单位的管理情况。

1．4系统应安全，可靠。界面要直观，易懂。上下级数据交流要简单，方便，还要为今后的拓展留有足够的空间。劳保用品管理系统的设计思路

据以上需求，我们对劳保用品管理系统进行了总体设计。总体设计包括数据库设计、操作界面设计、关键算法设计和数据传递设计四部分组成。

2．1数据库设计

为适应我公司对数据库的要求，我们选择了oracle数据库。在数据库内的主要数据表是：部门字典、人员字典、工种字典、劳保用品字典、型号字典、劳保用品发放标准字典、各类上报数据表和各类汇总、统计表。上报数据库内主要由各类上报数据组成，这些数据在运行期间更新。

2．2 操作界面设计

操作界面严格遵循Windows标准。系统显示出清晰的层次结构，各窗口外观、布局、风格和操作方法基本相同。相关事务集中在一个主菜单下，一类事务集中在一个窗口，一项事务集中在一个页面，一个事务往往体现在一个按纽上。要考虑到基层单位操作人员的操作水平参差不齐，既要使初级操作人员根据说明准确操作该系统，又要向高级操作人员提供灵活的操作方法。所有的输出数据都要求

准确、直观，一目了然。

2．3关键算法设计

系统的关键算法是准确预测需求。从理论上讲，如果已知某个职工在以前的某个时间领取过某种劳保用品，又知道该种劳保用品规定的使用期限，就能够准确地计算出下次发放的时间。但实际情况远比理论上复杂得多。首先，劳保用品的使用期限按年计算，人们已经习惯了这种模糊计算模式。你不能要求由于使用了该软件，改变以前成熟的计算模式。因此，不能使用日期型数据描述发放时间和下次发放时间。其次，劳保用品的使用期差距太大，长者3年，短者1年。三是大多数基层单位在储存劳保用品时，只区分了品种，不区分型号。以胶鞋为例，36码的鞋和46码的鞋的物资编码是一个编码。既要预测胶鞋的需求量，还要预测各型号的需要量。四是预测期间应该由用户自己确定，预测品种由用户自己确定，预测人员范围由用户自己确定。五是预测结果必须按小队及大队等层次进行逐级汇总，用户期望既能按部门显示和打印，又能按品种显示和打印。只有详细理解预测中的难度，才能在设计初期充分做好准备。

2．4 数据传递设计

两类数据需要在基层单位和上级主管部门之间进行传递。一是上级主管修订下发的劳保用品发放标准。基层单位不仅要使用新标准更新旧标准。只有这样，才是准确、及时地执行了上级的指令。二是基层单位定期向上级主管部门上报的数据，包括发放情况，需求计划等。由于上级主管部门既要掌握全局的情况，又要监察各基层单位的执行情况，因此，必须保持各个基层单位各数据的独立性。劳保用品管理系统的实现、应用与不足

3.1 在以上设计思路指导下，我们于2009年5月首先在我矿计算机室单机进行试运行。系统数据库采用了Oracle，开发工具采用了Microsoft Visual Studio2005。网络版为两层Client/Server结构，服务器环境为Windows 2003，数据库引擎为MS ADO。

3.2在设计部门字典时，我们提供了方便的人员调转功能。在建立工种字典及劳保用品字典时，我们严格执行我公司目前现行的标准，并做了标准化、规范化处理。

3.3 试运行期间，操作人员很快掌握了使用方法。一旦完善了基础数据，系统就进入预定的运行轨道：系统能够自动计算个人劳保用品发放时间；辅助制定护品采购、定做和发放计划；能够统计汇总劳保用品采购、发放数量。能够上报劳保用品发放汇总情况和计划。

3.4存在的不足和今后研究方向

劳保用品完全可以实现精确管理，关键是提高认识和使用高效能的软件系统，还要从实践中认真的探索。该系统存在许多有待改进的地方。首先是建立基础数据时工作量较大。要使管理真正上一个台阶，这项艰苦工作是不能省略的；其次自动形成个人劳保卡片功能还未实现。

总之，劳保用品管理虽然不是事关生存和发展的大事，但也是关系到职工切身利益的事情。目前我矿机房硬件设施完全跟不上软件开发要求的最低配置，我们期望领导们给以应有的重视，优化我矿机房硬件设施。还期望各级用户积极反馈实用信息，多提意见，努力打造出我厂乃至公司最优秀的劳保用品管理系统。

参 考 文 献

1大庆油田有限责任公司 大庆油田有限责任公司关于印发《大庆油田有限责任公司员工个人劳动保护用品配备暂行标准》的通知 庆油发 [2005]65号 2005年9月27日吕伟臣 霍言 吕宝臣 《Visual C#2005 入门与提高》

3刘桂喜，胡晓辉 《福利劳保用品发放管理系统的设计与实现》 现代计算机 2002年第1期