编者按
走过信息系统从无到有的阶段后，在“十四五”期间，信息化工作以业务和信息化深度融合为焦点，关注重点从建设好转到使用好。如何从建完发展到可用，进而从可用发展到好用，是值得重点攻克的问题，也是难点问题。现实实践看，工作重点模糊，创新思路乏力，责权不清晰，组织协调难，资金缺保障，是目前很多信息系统在运行阶段面临的境况，阻碍了已建信息系统效益的发挥。
在《信息系统运行效益提升路径研究》一文中，畅享网研究咨询中心分析政府、教育、企业集团等信息系统运行现状及成功失败案例，总结可行路径。信息系统运营提升涉及面很广，支撑和保障层面的硬件网络设施、工具软件产品、安全设施保障、技术团队建设等不列入本文探讨的范围。不同行业具有业务特点和管理特色，不同组织层级关注问题不尽相同，本文针对大型组织，提供一般性观点，实施时可结合本单位实际情况，选取部分举措，设计针对性方案。
本文包括五个部分，分别是：问题及路径分析；优化运营体系；创新合同类型；整合扩展应用；做强公共支撑能力。将分三期分享，本期分享第三部分以及第四部分的“整合信息门户”、“改造扩建系统”。
因所探索主题比较前沿，研究团队视野水平所限，本文难免以偏概全，存在认知盲区，欢迎批评指正，在后续更新时补正。
4332字 | 8分钟阅读
目录
一、问题及路径分析
（一）现状分析
（二）工作难点
（三）主要路径
二、优化运营体系
（一）运营工作常态化
（二）利益相关人沟通
（三）统筹服务商组合
三、创新合同类型
（一）工程交易管理要点
（二）运维运营模式
（三）改造扩建模式
（四）租赁模式
四、整合扩展应用
（一）整合信息门户
（二）改造扩建系统
（三）增强多终端服务
（四）优化用户体验
五、做强公共支撑能力
（一）身份和权限管理
（二）数据管理能力
（三）开发运维能力
（四）公共能力运营
三、创新合同类型
在信息系统运营阶段，用户单位和服务单位交易的内容是专业服务，而不是标准产品，应该采用适合服务交易的合同类型，核心是降低沟通成本，使得甲乙方把关注重点转移到用户服务上，而不是甲乙方责任划分上。
（一）工程交易管理要点
信息化工程交易，需重点关注发包模式、合同类型、交易机制和供应商选择。
发包模式方面，设计-招标-施工模式中设计和施工由两个服务商完成，优势是管理方法成熟，用单位容易掌控设计和设计变更，有利于合同管理和风险管理，劣势是管理和协调较复杂，设计和施工容易互相推诿。工程总承包则由一个服务商总承包设计和施工，通常采用总价合同，但允许价格变更，也允许某些部分采用单价合同，承包商承担了大部分责任和风险，优势是可以提高可实施性，投资和工期有实质保障，劣势是用户单位无法参与设计单位选择，对最终设计和细节的控制能力降低。如果总承包商也负责运营，优势是可以优化项目的全生命周期成本，保障项目长期质量的可靠性，但责任范围的界定容易引起较多争议，招标过程也比较长。选择总包商应该选择专业化总包公司，具有总包管理经验、分包商选择、垫付账款等专业性实力保障。
合同类型方面，总价合同和单价合同是基于价格的合同，实际成本加固定费用合同、实际成本加百分比合同、目标价格激励合同、限定最高激励合同是基于成本的合同，在造价评估时应慎重评估不同合同类型的特点，在维护用户方利益的同时，保障服务商和服务人员利益，提高其工作积极性。交易机制方面，一般包括招标机制、工程担保机制、工程保险机制等。
现行招标机制和实际操作中，选择服务商一般是根据综合实力和已有案例，更适合采购标准软硬件产品的模式，而不是对服务团队能力的评估选择，这对信息系统运营效果是很不利的。软件开发能力和服务能力不具有规模化复制的网络效应，在市场上是稀缺资源，采用交易市场标准采购模式难以选择优秀服务商。
在投资资金总额总体不变或不大幅增加的情况下，将资金比重从建设阶段向运行阶段倾斜，将毕其功于一役的建设心态转为长期伴随式发展的运营心态，将费用由运维费用发展到运营费用，将采购产品转变为采购人力服务，认同服务的价值，提高服务的人月费率，采用分周期付款、长期合作的商务机制，引入信息化合同新形态，为信息系统运营的品质提供保障。
（二）运维运营模式
随着信息系统对业务覆盖度增加，处于运维期的系统越来越多。根据管理，信息化项目软件运维费用应包括软件运维中所有直接成本、间接成本和毛利润。在日常实践中，主要根据工作量进行造价评估，辅以类比法，或以建设期功能点为基数开展造价评估，根据建设费用一定比例测算运维费用。对于系统功能相对稳定的系统，这种运维费用机制是可行的。
随着数字化转型的推进，信息化系统是业务创新、技术应用和运营服务的综合体，经常由业务部门负责，运营服务商在提供软件开发、系统优化提升等技术服务的同时，要花费大量精力用于业务沟通协调、日常客户服务、数据采集加工等运营管理工作，这是运维费用中没有包括的工作内容，运营类项目造价评估方法应该考虑这类工作量，根据工作量开展造价评估，评估思路是先将运营内容按照不同岗位分类，再评估各岗位的工作量、薪资、社会保险金及合理利润，得出运营服务费用。
（三）改造扩建模式
因需求变更或使用中出现的系统性问题，对原有系统进行针对性改造，或在原有系统框架基础上对系统进行升级，使系统能够顺利接纳新功能或运行更流畅，这是改造类需求。改造类任务的造价评估，需要根据项目实际情况，对国家标准的功能点法进行针对性调整和优化，特别是调整重用程度，根据重用程度给以规模调整因子。
在原有信息系统框架的基础上，根据建设规划新增信息化建设需求，新建相关功能模块，这是扩建类需求，与改造类需求的主要区别为是否对原有系统进行改造或升级。扩建类任务的造价评估，需要明确新建功能与原有功能是否属于同一系统，如果不是，则作为新建软件开发项目，根据国家标准中的功能点法进行造价评估。如果新建功能与原有功能属于同一系统，则要考虑重用程度调整。
（四）租赁模式
租赁模式由服务商投资、建设、运维，用户与服务商签订长期合作协议，按用量、时间、效果等付费。从租赁类项目的运行方式上看，其与建设类项目在项目范围上是一样的，区别在于费用支付方式，建设类项目一般按项目阶段付费，租赁类项目一般按周期付费。
融资类是针对网络设施软件、混合型解决方案、人力服务等，将工程建设管理转化为服务购买，强化成果导向和轻资产管理，改变用户为主体的建设、拥有并运维的模式。如区域中多个校园采用融资类模式，联合租赁网络设施。
云计算服务因其标准化、规模经济效应、安全性等，逐渐成为大型机构管理者的普遍常识。购买云服务使得用户与厂商的合作关系的焦点从项目建设转移到用户体验和使用效益，提高系统开发效率，避免重复投入，对用户与供应商关系的构建有较大的正面推进作用。
四、整合扩展应用
在系统运行阶段，从业务部门角度看，有部分业务尚无信息系统覆盖，很多已有系统的功能针对性、功能深度、用户体验度等与业务期望有较大距离，在相关部门及下属单位的使用率、覆盖度参差不齐，面临比较普遍的不联通、片段化、不一致、利用难等数据问题，在关键时刻无法满足业务要求，使得信息化投资效益满意度低。
（一）整合信息门户
在大型企事业单位，用户人均使用系统和功能点数量较多，人找系统、人找账号、人找信息成为常态。采取措施，使得用户使用率提高、访问量增加，有助于倒推相关功能完善、数据准确，具有重要意义。
以移动门户、电脑门户、自助端等为抓手，充分利用现有技术和资源积累，采用联通的思路，整合用户、应用、数据、界面，实现人的集成、界面集成、业务集成、消息集成、应用集成、流程集成，优化待办、消息、提醒、新闻订阅等功能，结合用户行为习惯和工作需要，根据用户的不同角色为用户推荐个性化板块、功能及服务，提供千人千面的一站式信息资源访问入口，打造个性化工作空间。
建设多级门户，更有效地提供功能和信息。单位门户包括资讯、办事、数据等，自动集成各类系统中已满足统一身份认证系统集成的应用或服务，并以用户使用为中心进行展现。按照部门需要设计特定部门门户，将共性门户中集成的各种应用或服务按特定的维度和内容集成在部门门户中，实现部门通知、相关制度、事项目录和负责人、工作任务、部门入口以及会议通知、费用报销、行政资源申请、工作日报等。业务门户是按照业务领域设计的特定业务门户，聚合与该业务相关的应用、数据等。个人门户聚合个人有权限的服务内容，根据用户不同角色提供个性化的功能及服务，如统一待办、统一消息、个人数据中心、个人证照、使用记录等。
为用户提供个性化服务，减少用户寻找信息的时间。实现多终端适配、分级管理、新闻服务、知识服务、消息通知、搜索、推荐、服务评价等。在碎片化、移动化时代，系统向个人提醒消息，信息找人，而不是人找信息，对用户非常重要。消息中心包括各类审批，支持多种消息渠道和消息队列，汇集内部系统、移动终端、短信、邮件等消息。通过统一接口接收来自各个系统的消息和通知，如待处理事件提醒、邮件通知、日程提醒等，按不同系统分类展现，提醒用户。用户在终端中看到消息通知，可以处理消息并可批量操作，也可点击后进入目标系统。根据点击量排序以图标形式和图片形式等展现热门服务，以及最近使用、身份相关应用等个性化应用。查看各种实时的单位资讯，如新闻动态、通知公告、规章制度、活动信息、资源信息等，不同资讯分级授权人员发布，设置所查看的资讯服务类别，自动推送资讯。
按部门、服务对象、服务类型等形式展现线下线上功能事项目录，具体页面展现基本信息、功能指南、服务说明、相关问答以及通知通告，并关联具体功能的办理时限，可设定通知范围。发布订阅机制，解耦应用系统，实现个性化推送、个性化配置、统一授权、关键指标和报表。采用分级门户、分级授权管理的机制，通过配置实现分级门户界面，根据需要定制不同的分级门户显示内容。通过配置实现新增门户、常见门户内容配置等，用户自定义和配置其关心的应用系统，系统自动展现用户最近使用的应用。
（二）改造扩建系统
以主要业务部门为主，以挖掘项目目标和问题根源为主要手段，关注主要矛盾的解决，评估改造扩建需求的必要性。需要梳理业务场景，设计闭环的流程和数据机制，完善制度建设，为系统建设和运行提供基础保障。对业务个性化程度高的领域，采用定制开发，或在产品化的行业方案基础上，做定制修改。对标准化工具，采用购买产品模式。以降低组织的沟通成本为原则，处理好统一建设运维和专业化建设运维的关系，处理好规范化和个性化的关系。
本级及上下级系统数量多、应用深度、应用范围、应用健康度层次不齐，不可能短时间更换很多系统，下级单位很多业务细节不是本级管理的范围，这是较长时间所处的现状。业务要求最急迫、业务部门最积极、现有应用质量差的领域，作为改造扩展的重点。系统改造扩建的规划设计，应处理好与已有信息系统的关系、与下级单位系统的关系。下级单位一般希望保留自建系统自主权，上级单位应该明确数据要求、流程节点规则要求，以满足管理要求为目标，而不是一刀切大一统信息系统为目标。下级单位无法要求上级改变系统管理要求，因此本级设计的系统要具有灵活性，可与上级系统对接，将上级数据本地化，能方便地向上传单位传输数据和事项。
以精简集成为原则，减少系统复杂度，降低成本，以满足业务需要为目标，采用融合思路，改造现有系统，对接上下级及相关单位数据和流程，新建所需功能，开发数据应用。上下级单位间技术上采用平台模式，管理上统分结合，上级或者统一平台，或者统一标准并明确要求，下属单位分别建设。已经有平台和应用且使用情况良好的，继续使用，没有建设或已建但使用状况差的，在公共支撑平台上做新应用开发，这种融合模式好处是技术规范统一，管理协调简化，应用效果统一。已有功能改造，系统间联通，已有数据同步，新数据采集，多组织间事项审批和备案处理。可以基于公共支撑平台开发，也可以把满足公共支撑平台技术和要求的现有系统进行接入，公共支撑平台应产出数据接口服务供其他系统写入和查询。不重叠的业务将数据通过接口传入，重叠业务可将产生的业务数据通过接口传给公共支撑平台。
把用户、项目、人员、资产、收入等公共主数据库建设作为重要任务，从源头完善主数据，推动数据在上下级单位的汇聚共享，提供标准一致、质量稳定、服务决策、查询便捷、内容丰富的数据。不同系统间通过接口、公共数据库、数据库对接等进行数据联通。满足信息安全制度的约束，实现不同网络间、网络层级间数据和应用访问。应用对业务的覆盖度高、对基层单位覆盖度高到一定水平时，数据治理和数据仓库应用才有必要性和可行性。否则，成本太高，很少出效果。
京公网安备 11010602030059号
