中标
宜昌市公安局运行维护服务协议定点结果公告
运行维护服务信息技术服务应用系统人力外包运维服务数据汇聚运维服务数据服务监测与维护业务系统系统功能优化升级数据对接接入数据清洗入库数据接口服务开发数据共享服务大数据应用平台运行监控服务应急响应服务性能调优服务安全管理服务技术支持服务搜索应用适配器文本挖掘工具大数据管理系统大数据运行监控平台云搜索大数据可视化分析平台电子白板电子档案资源应用配置工具企业通讯录公安网盘精神病人评估出租房巡检巡逻签到NFC身份证识别车辆查询数字电台PGIS采集人像识别现场勘验人像布控值勤津贴申报系统新办公自动化系统升级卡口数据交换平台卡口联网中台公车管理系统加班津贴申报系统大数据平台海贝数据库信息系统移动办公Java开发框架技术团队的管理协调沟通资源的调配服务实施服务报告提交质量管控实时对接移动警务平台数据标准管理数据质量检测数据资源监测驾驶员查询视频运维拖车处理PGIS展示报表中心售后服务人力资源应急保障系统优化设备维修相关数据启用防病毒软件数据备份病毒爆发处理风险评估应急计划灾难应急处理灾难恢复流程应急恢复流程永续运营计划影响分析现场支持指导设备运输灾难核实业务恢复方案启动系统加载状况使用灾难发生后会涉及的所有设备病毒处理病毒应急处理恢复计划的回顾和改进
金额
67万元
项目地址
湖北省
发布时间
2022/11/03
公告摘要
公告正文
宜昌市公安局运行维护服务协议定点结果公告
政府采购计划备案号:宜采计备[2022]XM2069号
订单号:FWJJ4205002200955523
采购总预算金额:¥710,600.00
本次成交金额:¥670,000.00
采购单位:宜昌市公安局
联系人:邓文
联系电话:18871592799
成交供应商:宜昌思睿笃行科技有限公司
成交日期:2022年11月03日
执行方式:竞价
成交内容:
采购方式:竞价
采购品目:信息技术服务
采购需求:请供应商按采购需求投标。
需求附件:宜昌市公安局应用系统人力外包运维服务采购文件_最终版__220921.doc宜昌市公安局应用系统人力外包运维服务采购文件_最终版__220921.doc
服务响应说明:完全响应
服务响应附件:宜昌市公安局应用系统人力外包运维服务响应文件.doc宜昌市公安局应用系统人力外包运维服务响应文件.doc
项目概况采购项目技术规格、参数及要求220921宜昌市公安局采购文件宜昌市公安局应用系统人力外包运维服务
整体要求详细技术参数及要求服务需求一览表项目清单及技术要求宜昌市公安局大数据建设过程中,汇集了大量数据,在后续的数据汇聚与数据服务方面,需要专职数据工程师保障数据交换服务的稳定性、鲜活性、实时性与对外服务的有效性;在软件平台运维方面,需要专职运维人员保障现有系统稳定运行,同时完成零散的、个性化、规模量不大的系统研发,同时需要专职客服人员来提供日常培训、问题咨询、技术支持等服务。
序号 | 名称 | 单位 | 数量 |
1 | 数据汇聚运维 | 项 | 1 |
2 | 数据服务运维 | 项 | 1 |
3 | 业务系统运维 | 项 | 1 |
4 | 系统功能优化升级 | 项 | 1 |
服务要求如用户方对运维人员的服务质量不满意(包括技术能力、服务态度等),有权通过书面形式提出撤换该运维人员的要求。参与本项目的运维人员在合同生效之日起必须固定下来,如需更换须保证替换人员的认证资质和从业经验不低于原有人员,并须提前一个月提交书面申请并经相关用户方签字同意。未经用户方同意不得随意更换。数据工程师要求熟悉市局大数据平台,精通海贝数据库相关技术,具备Oracle数据库经验。开发工程师要求熟悉市局信息系统开发架构,具备OA、移动办公等项目开发经验,熟悉Java开发框架,熟练操作Oracle、MySql数据库。在上述运维人员中指定一名担任本项目的项目经理,项目经理负责技术团队的管理、双方的协调沟通、资源的调配、服务实施的管理、服务报告提交和质量管控。针对本项目安排数据工程师1人,普通技术员2人,开发工程师2人,客服人员1人进行驻场运维1年,上述运维人员根据工作实际情况进行动态调配。
目前已开放40类计127个数据服务,其中通过接口提供服务的有83个,通过中间件提供的有33个,通过数据库提供的有10个,手工对接的1个;实时对接的有5个,每小时同步对接的有13个,每天同步对接的有14个,每周同步对接的有6个,每月对接同步的有2个,其他的根据业务需求随时调整同步周期。具体服务要求如下:数据服务运维要求目前公安大数据平台已汇聚对接151类数据资源,其中采用数据库对接的有99类,消息中间件对接的有39类,文件导入的有12类,接口对接的1类;交换频率方面,实时对接的有11类,按小时对接的有26类,按天同步对接的有85类,按周对接的有16类,不定期对接的有13类。具体运维要求如下(内容涉密,采购文件不提供具体资源名称,类别,数量等信息):数据汇聚运维要求
序号 | 运维内容 | 运维要求 |
1 | 数据汇聚标准制定 | 对各个来源渠道需要汇聚的数据,按照数据接入、治理等流程,制定对接双方统一的数据汇聚标准。 |
2 | 数据对接接入 | 利用数据导入工具或者开发数据接入程序,将各业务警种各业务系统、政府各部门、视频网、互联网社会面数据,实时或定时对接接入数据处理库,包括数据库接入、数据文件接入、消息中间件接入、接口接入等多种方式。 |
3 | 数据清洗入库 | 按照部标或省标,对接入的数据进行清洗、对标等处理,完成后对接大数据资源池。 |
4 | 数据汇聚监测、维护与保障 | 要求持续接入新数据的同时,对前期宜昌市公安局在大数据建设过程中已经汇聚的151类数据资源,利用人工和自动监测(ELK日志分析系统、Zabbix监测工具)等方式进行常态运维,确保数据汇聚实时、稳定、完整。对人工发现或用户反馈的数据汇聚中断、丢失、延时、异常等故障,运维人员须在故障发生后3小时内修复。每季度及时汇总、总结故障问题,向用户方提交运维报告。 |
序号 | 运维内容 | 运维要求 |
1 | 数据服务标准制定 | 针对大数据资源池内的数据,制定标准化的数据服务规范,确定所需的数据类型、数据字段、数据服务方式(包括数据共享服务和数据接口服务)。 |
2 | 数据接口服务开发 | 对各业务警种各部门提出的相关需求,按照数据服务标准,利用Mule做定制开发。 |
3 | 数据共享服务 | 对各业务警种各部门提出的相关需求,按照数据服务标准,通过开放Oracle数据库视图,Kafka、ActiveMQ消息中间件做数据共享。 |
4 | 数据服务监测与维护 | 要求持续开发新的数据服务的同时,对前期已经开放的40类数据服务,利用人工和自动监测(Zabbix监测工具)等方式进行常态运维,确保对各业务实战部门进行稳定地数据服务支撑。对人工发现或用户反馈的数据服务中断、数据异常等故障,运维人员须在故障发生后1小时内修复。每季度及时汇总、总结故障问题,向用户方提交运维报告。 |
附2:移动警务平台(钉钉)运维内容(其中序号为18-23/25-28/32-36/41的功能部署在内网)附1:大数据应用平台运维内容业务系统运维要求
序号 | 运维内容 | 运维要求 |
1 | 运行监控服务 | 利用自动化工具对数据库和应用系统等软件运行服务保证7*24小时不停机。对J2EE整体架构及应用程序、数据库进行运行监控和故障诊断,包括JVM的内存状况、线程信息、组件(包括JDBC层细致到SQL语句)执行级别信息及Java类、方法执行级别的响应时间和资源开销,能够对J2EE应用进行内存泄漏诊断和定位,通过更深入的监控和诊断,为应用优化提供第一手资料。 |
2 | 应急响应服务 | 针对运行监控、定期巡检发现的应用系统异常和故障,用户方反馈的系统问题,应及时响应,进行问题研判,确定故障等级,及时处理故障。在常态运维模式下,应保障工作日有值班人员驻守,发现问题在2小时内处理完成,最多不超过12小时。在应急运维模式下,比如重大安保、两会等节点,应安排核心运维人员在现场,实行24小时不间断运维服务,如期间发生系统长时间无法访问、关键模块报错无法操作、服务器宕机等事件,应作为运维事故。 |
3 | 性能调优服务 | 定期根据现有应用系统实际情况,或根据用户需求,安排开发工程师对系统程序交互界面、业务逻辑、系统Bug进行调优,保证应用稳定运行;数据库性能下降或空间不足时,安排数据工程师对数据库进行优化,对数据文件进行迁移或调整。 |
4 | 安全管理服务 | 制订完善的口令管理机制,周期性更改用户口令;针对用户方等级保护测评等报告暴露的问题,及用户方的要求进行安全整改。 |
5 | 技术支持服务 | 通过钉钉群、微信群、即时通讯工具、电话等方式,第一时间解答用户需求与问题,并记录存档,如是系统故障问题,同时上报运维人员,按照应急响应机制实施运维。根据用户需要,通过送教上门、会议交流等方式,对运维系统进行培训。 |
序号 | 功能模块 | 功能描述 |
1 | 搜索应用适配器 | 为支持云搜索,需要通过全文库数据抽取工具,将数据抽取写入全文库,全文库抽取工具采用searchAdapter。 |
2 | 文本挖掘工具 | 文本挖掘是以半结构或非结构的自然语言文本为对象,从大规模文本数据集中发现隐藏的、潜在的、新颖的和重要的规律的过程。其基本思想是从文本中提取适当的特征,将文本标示成计算机能够理解的形式,采用各种文本挖掘方法发现隐藏的知识模式,以用户可以理解和接收的形式输出,成为指导人们实现的有用的知识。本次系统采用文本CKM进行文本挖掘。 |
3 | 大数据管理系统 | 本次大数据管理软件采用同公安部云搜一样的Hybase数据库,Hybase(海贝)是融合检索引擎、MySQL多引擎机制、Hadoop/HDFS分布式并行计算和多副本机制、Facebook/Cassandra对等节点机制、关系数据库列存储机制、自然语言处理等先进技术,而设计的大数据管理系统。Hybase为各类大数据分析应用, 提供大数据高效管理和智能检索的平台支撑。 |
4 | 汇集库 | 通过抽取整合公安内外各类数据,包括公安内部数据、公安外部数据、互联网数据、非结构化数据等实体化数据库,形成汇集库。汇集库负责各类数据资源的汇聚、抽取、管理。主要采用oracle数据库进行存储和管理。 |
5 | 基础数据资源库 | 基础数据资源库在汇集库的基础上进行了数据的清洗、转换和加载等处理过程,同时按照五要素进行分类,形成基础数据资源库,基础数据资源库的存储架构采用oracle数据库集群方式存储。 |
6 | 专题应用资源库 | 专题服务层由一系列针对特定应用或者服务需求以及非结构化数据管理和服务需求而构建的专题库组成,主要解决存储性能、访问性能、访问方便性及安全性等问题。结构化数据专题库基于要素模型层构建,采用逻辑视图、物化视图、抽取整合等手段构建。专题服务层包括全文库、人员基础要素库、车辆轨迹库、要素库、人员轨迹库和通讯关系库。 |
7 | 数据标准管理 | 结合公安部数据资源服务平台的数据服务标准,遵循公安数据元标准规范,开展公安数据元的梳理、编制和推广应用工作,建立全局统一的数据标准化管理和应用工作机制。同时利用公安部标准管理系统的接口同步更新标准信息,汇集整理数据资源管理所需的标准规范信息,建立数据标准数据库。利用公安部标准管理系统的接口同步更新标准信息。从而有效支撑公安大数据资源的标准化采集、管理和共享服务,建立符合部、省、市三级兼容的标准规范体系。梳理国标、部标和本省定义的标准代码以及各业务信息系统需要使用的其它代码,建立字典代码实体数据库。具备字典代码定期同步功能。 |
8 | 数据整合管理 | 数据整合管理主要是将配置好的已经过授权的数据源进行数据抽取 ,根据设定的规则进行数据清洗转换,同时对数据整合过程可实现动态监控。从而满足大数据分析的要求。同时为确保该过程可维护、可监督、可控制、可管理,本次系统设计还包括数据资源管理和调度与管理。采用数据同步工具或ETL工具完成数据抽取、同步等整合工作,通过任务调度管理实现对整合工具的集中管理和执行。配置数据同步工具或ETL工具,实现数据库之间数据复制和自动同步。对于数据量较大、数据变化情况难以获取的数据资源,采用分析数据库日志的方式进行数据同步。对于数据量较小,数据变化明确的数据资源,采用ETL工具对数据资源进行定时比对并获取变化数据,实现数据同步。 建设数据整合任务调度功能模块,实现对整合工具的集中管理和控制。通过配置执行时间的方式,控制数据整合工具中数据整合任务的执行;自动恢复出现异常的整合任务,并对整合任务出现的错误进行报警;记录整合任务的审计日志。 |
9 | 数据质量检测 | 建设数据质量检测配置功能模块,支持数据质量监控模型的自定义配置,利用技术监测和业务逻辑校验,进行数据源头采集、传输、应用全流程的规范性、一致性、准确性检查,实现基于不同来源数据的逻辑校验和监测管理。通过配置可实现上线前检测、运行过程检测、运行结果检测。建设数据质量检测配置功能模块,支持数据质量监控模型的自定义配置,利用技术监测和业务逻辑校验,进行数据源头采集、传输、应用全流程的规范性、一致性、准确性检查,实现基于不同来源数据的逻辑校验和监测管理。 |
10 | 数据资源监测 | 建设数据资源监测功能,实现平台数据变化、数据库系统状态和数据整合及质量检测工具运行状态等方面的集中监测。平台应自动监测数据资源变化情况,对数据资源中各信息表的数据量、每日增量和变化趋势等数据进行自动汇总统计,通过图表、表格等多种方式进行展现。应自动监测平台数据库的相关索引、触发器状态及每类数据存储空间使用情况等数据库系统状态信息,使用图形化界面定时发布监测结果,对出现的异常状态实时报警。 |
11 | 数据资源注册 | 基础数据注册的主要作用,是方便地实现数据资源提供者在数据资源目录体系中按照规范要求注册基础数据。基础数据的注册信息包括基本信息、访问敏感等级、业务分类、更新频率、数据关联关系,数据项的引用标准、代码、日期格式、访问敏感等级等。通过规范化的资源注册采集元数据信息,包括数据的技术属性、业务属性、管理属性等等,可以为上层查询分析应用提供支持。基础数据注册包括数据库注册、数据表注册和数据项注册。 |
12 | 数据资源编目 | 按照“公安数据资源目录注册接口规范”,依据公安部信息共享目录要求,对数据资源名称、数据资源摘要、数据资源提供方、数据资源分类、数据资源共享属性、数据资源公开属性、数据资源标识符、元数据标识符、数据项描述等元数据信息进行明确,对已注册的基础数据按照业务、层级等进行编目、发布,形成数据资源目录。为建立数据资源目录,首先要对各部门提供的数据资源和信息交换服务进行分析,理清各类数据资源的结构和相互关系。为方便使用,采用规范的方法和技术,建立科学合理的数据分类体系,对数据资源和服务建立分类目录和索引。 |
13 | 数据元信息标注 | 建立以公安部数据元为核心的同义词库,自动关联平台中注册的所有数据项,以数据元——同义词——数据项——数据表——应用系统——业务警种逐层对照的方式展示数据资源。通过同义词关联等对应规则,对数据资源注册的数据项与数据元资源库进行关联,找到后将数据项与数据元进行一一对应,完成资源目录与数据元的统一,可通过数据元关联显示所有的数据资源: |
14 | 大数据运行监控平台 | 大数据运行监控平台提供对相关分布式节点的CPU、IO、内存等进行实时的监控,可以通过浏览器登录系统的管理台(默认端口5555)。打开管理台页面,首先需要进行用户身份验证,见下图。用户填写正确的用户名、密码和验证码以后,点击登录即可登录到系统管理台。 |
15 | 公安部云搜系统接口 | 提供公安部云搜系统接口,实现在电子档案、战法扩展界面实现云搜数据中人员基本信息、关系人信息、活动轨迹信息数据自动下载,作为本地资源库的补充。同时导入后的数据可自动建档和进行关联关系分析。 |
16 | 省信息资源服务平台接口 | 建设与省信息资源服务平台的接口,通过该接口可实现将获取到从省信息资源服务平台下载的数据包进行解析、格式转换、入库和关联关系展现,从而通过该接口实现与省信息资源服务平台数据联动。 |
17 | PGIS接口 | 通过与PGIS平台对接,实现点位展现、轨迹查询等功能。 |
18 | 云搜索 | 云搜索系统具备数据项、关键字的预设或自定义功能。支持按照“集中式”与“分布式”相结合的基本原则,整合关系型、NOSQL型、文件型等不同类型数据库和数据查询服务接口,全面实现本地实体数据和外单位共享数据的全网一键式综合查询、二次检索及关系信息展现。同时综合查询功能可根据本地汇集的数据情况及共享的数据接口开展设计开发。 |
19 | 大数据可视化分析平台 | 大数据可视化分析平台的展现方式包括关系图、时间轴、分析图表、列表等多种表达方式,为使用者提供全方位的信息展现方式。 |
20 | 电子白板 | 电子白板就是一个带有各种工具(包含战法引入、图片添加、文件添加等)的白板,类似现实世界中的白板一样,初始化界面是一张画布,用户可根据实际需求进行要素添加。 |
21 | 数据比对 | 按照平台预设或用户自定义的比对规则,实现平台汇集的数据集间交叉比对功能,并能实现用户自行上传数据与平台内数据资源的比对功能。有条件的地方,应通过模型配置工具实现数据比对模型的流程化设计,并具备比对方案的浏览、版本管理、导入导出、调度与过程监测等管理功能。对于集中存储的结构化数据,能使用关系型数据库处理的,通过关系型数据库技术进行比对;数据量级较大,关系型数据库难以处理的,使用内存数据库技术或NOSQL数据库技术进行处理。对于集中存储的非结构化数据,提供基于实时关键词的比对服务。对于异地存储的结构化数据,提供基于请求服务或资源服务总线的分布式数据比对服务;对于异地存储的非结构化数据,逐步探索利用分布式文件系统开展远程比对的数据服务方式。 |
22 | 分类统计 | 分类统计实现对各种结构化、半结构化、非结构化数据的分类统计分析服务,应生成全面的、多种形式的统计分析结果,并通过表格、柱形图、饼图、曲线图等多种方式进行反馈展现。应设计OpenAPI接口,提供其他应用系统对接访问。分类统计是在数据服务的基础上,结合公安机关对报表业务的实际需求,为公安用户提供的可以方便快捷的分析数据、灵活创建报表的报表工具。报表的制作过程完全是可视化操作,不需要编写程序。报表模板生成使用的数据逻辑模型是基于业务结构的,使报表的需求人员可以直接进行新的报表制作,减少了报表生产带来的问题和工作量,提高工作效率。界面报表设计工具支持各种复杂报表和统计图表的设计,支持多页表以及自动分页;生成的报表尺寸精确,打印精致;可自动转换成WORD、EXCEL、BMP图片等文档;界面支持无级缩放。 |
23 | 电子档案 | 人员电子档案是在人员关注信息的基础上依托“人员基础要素库”设计实现的,以“一人一档”的方式集中展现人员动态管理全过程档案信息的人员电子档案展现功能,做到关注人员的基础信息、动态轨迹信息、关系人信息及社会信息等所有信息的展示一目了然,清楚地反映了关注人员分析研判和关注管理的全过程,个人档案信息也可直接调用可视化绘图工具,将所有人员信息进行可视化展示。通讯号码电子档案是和挖掘判断人与人之间关系的重要信息,因此建立通讯号码电子档案便于清晰明了的展现和通讯关系的挖掘。车辆电子档案主要实现对各种车辆活动的动态管控,以“一物一档”的方式集中展现物品动态管理过程中的电子档案信息展现功能,让物品相关的基本信息、人员信息、动态轨迹信息、关联卡口信息、区域信息、案件信息等所有信息的展示一目了然,清楚地反映了物品分析研判和关注管理的全过程,达到“以车管人”的目的。公安行业历年发生的各种案件数量庞大,人为的查找各种案件之间关系,发现其中的有效关系,为民警办案提供强有力的办案、破案依据,难度较大,警务大数据平台利用大数据离线处理能力,对预测犯罪事件、犯罪热点地区和犯罪趋势具有很大的潜在优势,能够提高从各种情报中“大海捞针”的水平,通过提取人们行为的时空规律性和关联性,对犯罪行为发生前进行预警和事后分析排查。 |
24 | 人员综合时空分析 | 通过对人员活动轨迹按活动时间倒序的简要列表形式显示该人的各类实名活动信息,从而实现对人员的综合时空分析。 |
25 | 业务警种战法系统 | 除了上述专题应用外,业务警种战法工具系统可以让各警种民警构建自己的战法和实体门户,从而可以结合自己的业务,利用该平台可以充分利用的信息资源,从而达到实用化、实战化。该工具支持战法模型、组合战法模型、关系门户配置、数据比对等,均可以通过可视化的方式,进行在线的配置,能够支持多种数据架构,如Oracle、达梦数据库、Hadoop hbase、MongoDB等技术。配置好的战法,可以自己使用,也可以共享授权给其他人员。 |
26 | 资源应用配置工具 | 资源通用应用和资源专题应用,需要进行后台配置,来添加资源和配置展现方式,可以配置云搜索的资源和简项显示方式、设置主题模型、要素属性配置、统计图表配置和电子档案界面配置,通过在线配置,可以快速修改界面和展示效果,快速满足用户的业务需求。 |
序号 | 功能模块 | 功能描述 |
1 | 1个人信息 | |
2 | 1.1企业通讯录 | 查看人员详细资料,并对其发消息、打电话等 |
3 | 1.2工资 | 查看工资数额、名目、明细等 |
4 | 1.3公积金 | 查看公积金数额、名目、明细等 |
5 | 1.4医保 | 查看医保金数额、名目、明细等 |
6 | 1.5社保 | 查看社保金数额、名目、明细等 |
7 | 1.6资产 | 查看个人名下资产类型、动向等 |
8 | 1.7公安网盘 | 存储相关资料,用于日常工作 |
9 | 2警务文化 | |
10 | 2.1警务要闻 | 查看省、市内相关的要闻信息 |
11 | 2.2投票 | 发起话题、投票并展现 |
12 | 2.3学习园地 | 观看公安教学、实践等视频短片 |
13 | 2.4在线考试 | 通过后台考试管理模块将考试内容发布给指定民警 |
14 | 3警务工作 | |
15 | 3.1二级接处警 | 110接处警平台按派出所的管辖范围,将警情下发到民警手机上。 |
16 | 3.2警情审批 | 完成对警情定性的工作 |
17 | 3.3警情分布 | 利用可视化地图,将警情分布在地图上 |
18 | 3.4警情统计 | 对每日、每月出警情况进行统计通报 |
19 | 3.5重点人员核查 | 指挥中心通过移动警务的消息接口,将数据推送到指定的民警。 |
20 | 3.6社区重口评估 | 社区工作平台每月需要对重点人员进行评估,数据将被定期的推送到社区民警的手机上 |
21 | 3.7暂口核查 | 社区工作平台每月需要对暂住人员进行评估,数据将被定期的推送到社区民警的手机上,民警每月完成辖区内的暂住人员的评估工作。 |
22 | 3.8精神病人评估 | 社区工作平台每月需要对精神病人进行评估,数据将被定期的推送到社区民警的手机上 |
23 | 3.9出租房巡检 | 每月针对出租房进行核查登记,登记房主、租户等相关的文字信息以及照片信息 |
24 | 3.10巡逻签到 | 民警接到巡逻任务,到达指定位置后,对本次巡逻进行签到工作 |
25 | 3.11NFC身份证识别 | 读取身份证的加密字符串,上传到解密服务器进行字符串的解密工作,最终将结果返回 |
26 | 3.12人员查询 | 民警在内网移动端调用人员接口 |
27 | 3.13车辆查询 | 民警在内网移动端调用车辆接口 |
28 | 3.14驾驶员查询 | 民警在内网移动端根据车牌调用人员接口 |
29 | 3.15数字电台 | 收集记录登记电台号 |
30 | 3.16PGIS采集 | 利用PGIS采集业务数据 |
31 | 3.17全警三员 | 全警三员系统是采集线索的移动端应用 |
32 | 3.18人像识别 | 调用宜昌市接口,将与待查人员相近的人员姓名、身份证号码、性别等按相似度高低显示。 |
33 | 3.19现场勘验 | 民警在接到警情抵达现场后,完成保护相关事宜记录、见证人信息采集、勘验相关信息采集等,录入的数据实时反馈到指挥中心,最终进入了警综平台。 |
34 | 3.20人像布控 | 民警接收系统推送的在逃人员、精神病人员、嫌疑人员信息,信息内容包括目标人身份相关信息、数据库照片、摄像头拍摄照片地点、时间等。 |
35 | 3.21现场督察 | 警务督察部门民警通过该功能实时推送检查督导情况于移动警务平台上,推送内容包括:督察主题、时间、事项内容及相关图片等。 |
36 | 3.22群众议警 | 民警通过走访群众,深入群众,广泛收集群众对公安工作的意见和建议。 |
37 | 3.23视频运维 | 民警在日常工作中发现视频相关故障,可通过手机反馈故障详细信息,并推送给相关维护人员。维护人员在接收信息后进行故障处理。此时该信息的状态为处理中,直至故障解决后,信息状态变为已处理。 |
38 | 3.24履职尽责 | 民警在手机端填写工作计划(季度、半年、全年工作计划)完成情况,提交后该信息存入数据库,可由系统管理员查找调出。 |
39 | 3.25拖车处理 | 民警通过手机输入需要被拖车辆的信息、拖往单位及拖车原因等,信息将传到拖车单位,拖车单位进行后续拖车工作。 |
40 | 3.26一键求援 | 民警遇到特殊情况无法单独处理需要其他民警协助时,点击“一键求援”按键,求援信息将被发送给该民警所在部门的所有人,并显示该民警与接收求助信息民警之间的地理位置信息。 |
41 | 3.27网络舆情 | 领导在移动端即可完成舆情信息的研判工作,加快舆情信息的处置流程。 |
42 | 4审批 | |
43 | 4.1请假申请 | 民警在手机段提交请假申请 |
44 | 4.2用车申请 | 民警在手机段提交用车申请 |
45 | 4.3出差申请 | 民警在手机段提交出差申请 |
46 | 5后台管理 | |
47 | 5.1后台管理 | 后台管理,主要是提供给系统管理员,发布新闻、公告、学习园地、投票管理、考试管理 |
48 | 5.2权限管理 | 将权限相似的用户所拥有的权限进行分组,将用户加入该分组,用户就拥有该分组里面的权限。系统管理员为用户分配响应的角色,该用户就可一次性的获得多个可操作的权限。 |
49 | 5.3日志系统 | 记录用户在使用移动警务中的所有操作行为,记录的日志信息包括:操作者、操作类型、操作内容、操作结果、操作时间等,并能通过操作时间、操作者、操作类型等条件进行定向查询相关日志记录。 |
50 | 6系统间集成 | |
51 | 6.1与OA系统集成 | 利用 OA 系统的流程管理和标准库,同步人员、组织机构,工资、资产等信息到移动端 |
52 | 6.2与二级接处警系统集成 | 系统对接 |
53 | 6.3与警综系统集成 | 系统对接 |
54 | 6.4与合成指挥系统集成 | 系统对接 |
55 | 6.5与宜昌共享平台对接集成 | 系统对接 |
56 | 6.6与慧信即时通讯平台对接集成 | 系统对接 |
(1)值勤津贴申报系统附1:新办公自动化系统升级针对各警种实际业务需要,收集汇总研发需求,统一进行功能优化。系统功能优化升级要求附3:卡口数据交换平台卡口联网中台
序号 | 功能模块 | 功能描述 |
1 | 1 系统功能 | |
2 | 1.1设备管理 | 汇集各县市区的卡口基本信息,查看交警稽查对接,违法对接,过车信息等的跟踪功能。 |
3 | 1.2 PGIS展示 | 各县市区卡口PGIS地图展示。 |
4 | 1.3报表中心 | 按管理单位、平台厂商、各业务平台统计各县市区卡口基本情况。 |
5 | 1.4数据汇聚 | 汇聚各县市区及坝区的卡口过车信息。 |
6 | 2系统对接 | |
7 | 2.1与宜昌市公安交通集成指挥平台对接 | 实现卡口过车信息的稽查、违法信息的推送,坝区卡口过车信息推送。 |
8 | 2.2与车踪平台对接 | 实现卡口过车信息的图片解析及推送功能。 |
9 | 2.3与公安大数据平台对接 | 实现通过系统直接登录公安大数据平台。 |
序号 | 功能模块 | 功能描述 |
1 | 1系统功能 | |
2 | 1.1系统配置 | |
3 | 1.1.1一类、二类单位配置 | 一类、二类单位配置,系统设置一/二类单位配置入口,可根据不同政治要求来配置各单位所属于类型,便于后期参与津贴申报金额计算。 |
4 | 1.1.2管理员配置 | 各单位申报管理员配置,系统提示管理员展示页,并对未配置管理员的单位进行标红处理。管理员分为部门管理员和科室管理员,部门管理员为直属宜昌市公安局的单位(如:西陵区分局、法制支队、政治部……)、科室管理员为各部门的下级单位(如西陵区分局警令科、政治部机关党委……),若各部门或科室存在人员且未配置管理员,在津贴申报时此部门将无法申报。 |
5 | 1.1.3全年计划数 | 每年一月初生成各单位全年计划数,若部门为县级时,全年计划数=(部门总人数*全年值勤天数*50)+(部门总人数*全年值勤天数*40)、若部门为市局时,全年计划数=(部门总人数*全年值勤天数*40)+(部门总人数*全年值勤天数*30)。 |
6 | 1.1.4每月总天数和法定节假日、工作日配置 | 每月总天数、法定节假日、法定工作日配置,每年每一月月初将本年度每个月的总天数、每月节假日、每月工作日进行录入,数据录入后才可以启动津贴申报,若本年度天数基础数据未录入时,津贴将无法启动计数。 |
7 | 1.2考勤数据统计 | 津贴申报天数自动将考勤出差、病假、事假天数进行扣除。民警可从OA或钉钉上发起考勤申请,若申请类型为出差、病假、事假三类时,在流程结束时自己将民警所申请核准的天数记录到津贴申报考勤数据库中。若出差、病假、事假的申请开始时间—结束时间中,涵盖双休或法定节假日,系统自动核算减出,不参与本月总出勤天数计算。若申请开始时间—结束时间中涵盖跨月情况时,系统息动将所跨月份及天数进行拆分,并对每月考勤数据进行记录出津贴申报考勤数据库中。另,若出差人员存在多人,且多人出差天数不一样时,出差结束后由申请人对每位出差人员天数进行核实填写,填写的数据将自动记录到津贴申报考勤数据库。 |
8 | 1.3人员信息记录 | 津贴申报按民警财务所属机构进行汇总,按照“在哪上班在哪发起”为依据,将借调人员财务所属机构选择为目前所在工作单位。各单位管理员可在OA系统中“按人员”、“按财务”机构进行人员查询,具有管理员权限的人员,可对自己所管辖的单位人员进行调整,人员调整到位后,系统每晚自动将人员信息推送至津贴申报人员信息库进行保存。若本月津贴已启动后,再次对单位人员部门进行调整时,在本次申请中将不会生效。 |
9 | 1.4主动消息提醒 | 每月28号,系统自动对各津贴申报管理员发送短信及钉钉消息,提醒各管理员在申报前期对本单位人员及管理员进行核实检查,以防人员存在所属机构不对应或管理员未及时变更情况。 |
10 | 1.5值勤津贴启动 | 针对相关指定管理员,在OA系统中分配对津贴申报管理权限。由管理员添加津贴启动相关标题及文字说明、申报开始时间和结束时间,可选择是否给津贴各单位管理员发送启动短信提醒。启动成功后自动生成本次申报信息,点击可查看参与申报的单位及明细,也可实时掌控各单位是否发起审批或审批完成。 |
11 | 1.6津贴申报审核 | 津贴启动后,各部门和科室管理人员在OA待办区域将收到一条津贴申报文档,系统自动计算本月考勤信息并在页面显示,管理员可根据实际情况进行考勤天数调整,调整后原始数据依然保留;若存在长期生病或已经退休人员,管理员也可对此人进行“冻结”“解冻”操作,人员冻结后将不再参与本次津贴申报;考勤天调整完成后,管理员可对本单位人员一类天进行修改,系统自动计算二类天和金额。各单位在保存数据后,系统也将自动对一类天申报比例和总金额进行汇总计算;数据调整无误后可发起审批,科所队在发起审批后,可送达给所在领导审批、也可直接流程结束,领导审批时若对数据有质疑时,可直接点击“驳回”,数据驳回后由单位管理员将重新进行修改后再次发起审批。部门管理员可实时查看所管辖的下属单位申报情况及申报详情,若下属科所队申报比例超出或存在其它问题时,部门管理员可直接将单位申报信息进行驳回。部门汇总申报时,必须由下级单位全部申报结束后才可发起,若下级所有单位一类申报比例超出40%时,部门无法发起汇总审批,必须由部门管理员对有问题的单位进行驳回修改,一类申报比例小于或等于40%时,可正常发起审批,其中一类申报比例计算公式为:一类天总数/(单位人数*本月出勤天数),(如:单位A有10人,本月出勤天数为22天,申报一类总天数为100天,一类申报比例=100/(10*22),得出单位A一类申报比例为45.45%)。部门审批发起成功后,不可再次对下级单位进行驳回操作,发起审批后,由部门管理员送达给分局/支队领导审批,待领导审批通过后部门申报结束。市局管理员可实时查看全局所有单位(九县区除外)申报情况,并对有问题的分局/支队进行驳回操作。 |
12 | 1.7津贴申报停止 | 待申报时间结束后,由市局管理员点击申报停止,管理员点击申报停止后,对未申报结束的部门将不可再使用系统进行申报、也不可再对其它申报部门进行驳回操作。申报停止后,需由管理员选择发起市局审批,审批发起后,系统将自动生成市局与交警两条审核信息,分别送达到对应的管理员OA帐号,由市局与交警管理员按照流程选择送达领导审核,领导在审批时若对数据存在疑问,可点击查看对应部门和科室申报数据及金额。市局汇总审核通过后,系统自动给警保相关人员发送“送阅知”信息,提醒相关人员及时发放值勤津贴。 |
13 | 1.8申报数据统计 | 津贴申报停止后,由报表系统核算出各单位和人员的津贴详情,含工资卡号、一/二类天数、一/二类金额、考勤天数、发放金额及各数据汇总金额,财务人员可直接下载为Excel格式进行发放。 |
14 | 1.9数据归档处理 | 每月申报结束后,申报数据归档到Oracle库中,可供后期调出查看、各单位审核记录表单由OA系统保留,可供需要时调出查看和打印、统计汇总报表由报表系统进行归档存底,确保数据不丢失。 |
15 | 2系统对接 | |
16 | 2.1与OA系统对接 | 本系统与OA系统对接,实现内容审核、信息归档、人员管理、数据配置等。 |
17 | 2.2与移动警务平台对接 | 移动警务平台作为日常办公的移动端的延伸。本系统必须实现移动端的出差等申请、消息提醒及相关审批,部分功能的移动化办公。 |
18 | 2.3与报表系统对接 | 本系统与报表系统对接,实现各类数据报表的生成统计,EXCEL导出功能。 |
19 | 2.4与短信平台对接 | 本系统对接短信平台,实现短信提醒功能。 |
附2:大数据平台日志审计(3)公车管理系统(2)加班津贴申报系统
序号 | 功能模块 | 功能描述 |
1 | 1系统配置 | |
2 | 1.1管理员配置 | 各单位申报管理员配置,系统提示管理员展示页,并对未配置管理员的单位进行标红处理。管理员分为部门管理员和科室管理员,部门管理员为直属宜昌市公安局的单位(如:西陵区分局、法制支队、政治部……)、科室管理员为各部门的下级单位(如西陵区分局警令科、政治部机关党委……),若各部门或科室存在人员且未配置管理员,在津贴申报时此部门将无法申报。管理员配置分为:科室、部门、总管理员三级,每月津贴由总管理员发起。其中科室管理员可申报所在科室人员数据,部门管理员可对本部门下所有科室进行驳回重报,总管理员可管理全局所有部门。 |
3 | 1.2加班津贴计算公式 | 加班津贴按人均每月710元进行发放,金额控制以部门为单位,实现加班差异化(如:政治部总人数为20人,本季度加班总金额=20*710*3),部门申请金额不得超出季度总金额;若本季度加班金额申报后有结余时,可累计到下一季度,直止年底清零。 |
4 | 1.3每月总天数和法定节假日、工作日配置 | 每月总天数、法定节假日、法定工作日配置,每年每一月月初将本年度每个月的总天数、每月节假日、每月工作日进行录入,数据录入后才可以启动津贴申报,若本年度天数基础数据未录入时,津贴将无法启动计数。 |
5 | 2考勤数据统计 | 民警从OA或钉钉上发起加班申请,在流程结束时将民警所申请核准的天数记录到津贴申报考勤数据库中。若申请开始时间—结束时间中涵盖跨月情况时,系统自动将所跨月份及天数进行拆分,并对每月考勤数据进行记录出津贴申报考勤数据库中。 |
6 | 3人员信息记录 | 津贴申报按民警在OA中所属部门进行汇总,按照“在哪上班在哪发起”为依据,OA系统中所属部门为工作单位。各单位管理员可在OA系统“通讯录”中查询人员。若本月津贴已启动后发现人员所属部门错误时,可点击人员姓名,选择需要调整到的单位(对方单位未填报时方可调整)。 |
7 | 4加班津贴启动 | 针对津贴总管理员,在OA系统中分配对津贴申报管理权限。由管理员添加津贴启动相关标题及文字说明、申报开始时间和结束时间。启动成功后自动生成本次申报信息,点击可查看参与申报的单位及明细,也可实时掌控各单位是否发起审批或审批完成。 |
8 | 5津贴申报审核 | 津贴启动后,各部门和科室管理人员在OA待办事项里将收到一条津贴申报待办文件,系统自动计算本月加班信息并在页面显示,管理员可根据实际情况进行加班天数调整,调整后原始数据依然保留;若存在长期生病或已经退休人员,管理员也可对此人进行“冻结”“解冻”操作,人员冻结后将不再参与本次津贴申报;加班天数调整完成后,管理员可对本单位人员法定天和普通天进行修改,系统自动计算法定和普通金额。数据调整无误后可发起审批,科所队在发起审批后,可送达给所在领导审批、也可直接流程结束,领导审批时若对数据有质疑时,可直接点击“驳回”,数据驳回后由单位管理员重新进行修改后再次发起审批。部门管理员可实时查看所管辖的下属单位申报情况及申报详情,若下属科所队申报比例超出或存在其它问题时,部门管理员可直接将单位申报信息进行驳回。部门汇总申报时,必须由下级单位全部申报结束后才可发起,若下级所有单位申报金额超出本次申报总金额时,部门无法发起汇总审批,必须由部门管理员对有问题的单位进行驳回修改。部门审批发起成功后,不可再次对下级单位进行驳回操作,发起审批后,由部门管理员送达给分局/支队领导审批,待领导审批通过后部门申报结束。市局总管理员可实时查看全局所有单位(九县局除外)申报情况,并对有问题的分局/支队进行驳回操作。 |
9 | 6津贴申报停止 | 待申报时间结束后,由市局总管理员点击申报停止,总管理员点击申报停止后,未申报结束的部门将不可再使用系统进行申报、也不可再对其它申报部门进行驳回操作。申报停止后,需由总管理员选择发起市局审批,审批发起后,系统将自动生成市局与交警两条审核信息,分别送达到对应的管理员OA帐号,由市局与交警管理员按照流程选择送达领导审核,领导在审批时若对数据存在疑问,可点击查看对应部门和科室申报数据及金额。 |
10 | 7申报数据统计 | 津贴申报停止后,由报表系统核算出各单位和人员的津贴详情,含工资卡号、法定/普通天数、法定/普通金额、加班天数、发放金额及各数据汇总金额,财务人员可直接下载为Excel格式进行发放。 |
11 | 8数据归档处理 | 每月申报结束后不可再修改,各单位审核记录表单由OA系统保留,可供需要时调出查看和打印、统计汇总报表由报表系统进行归档存底,确保数据不丢失。 |
序号 | 功能模块 | 功能描述 |
1 | 1移动端功能需求 | |
2 | 1.1用车申请 | 实现移动端发起审批。明细包含但不限于:用车时间、返回时间、车型、车牌、出发地点、返回地点、司机、用车部门、用车事由。宜昌市中心城区内用车由各单位主要负责人审批,离开宜昌市中心城区由其分管局领导审批。 |
3 | 1.2维修申请 | 实现OA申报车辆维修申请,上报明细包含:时间、申请单位、车辆号牌、车型、已行驶公里数。故障原因、维修项目、预算金额、申请人、委修人、单位负责人审核、领导审批,手段可提供文字描述、拍照记录等。 |
4 | 2后台管理系统功能需求 | |
5 | 2.1车辆信息管理 | |
6 | 2.1.1车辆信息导入导出 | 系统提供导入现有车辆信息,支持Excel导入、导出。 |
7 | 2.1.2车辆信息维护 | 给各单位车辆管理员提供本单位车辆信息录入、修改、删除、查询等功能权限。维护信息包含:部门、机动车所有人、车牌号、车型、车架号、发动机号、注册日期、里程数、购置价格、使用性质、号牌类型。 |
8 | 2.1.3车辆明细统计 | 实现以部门、机动车所有人、车辆型号、车辆车型等条件,统计各单位现有车辆的 明细,统计内容包含但不限于:用车部门、机动车所有人、车牌号码、品牌型号、车型、车架号、发动机号、注册日期、已行驶公里数、排气量、购置价格、使用性质、号牌类型。 |
9 | 2.1.4车辆综合统计 | 根据单位部门、时间段、车辆类型、号牌种类等条件,统计各个局直单位的车辆情况。统计内容包含但不限于:各单位人数、派出所数、人车比、车辆总数、号牌种类统计(警车、民牌、未上牌各有多少数量)、车辆类型统计(小轿车、面包车、大客车、越野车、货车、其他类型车辆,共有多少辆)、车辆各年限车辆共有多少辆。并提供。 |
10 | 2.2用车申请管理 | |
11 | 2.2.1用车申请统计 | 用车审批结果同步到公安内网,可在本系统里体现审批明细,明细包含但不限于:用车时间、返回时间、车型、车牌、出发地点、返回地点、司机、用车部门、用车事由。 |
12 | 2.3车辆调度管理 | |
13 | 2.3.1车辆出入库记录 | 根据用车申请填报的用车时间(开始时间、结束时间),预测一份统计情况。统计内容包含但不限于:各单位在库车辆数量。若在库,可查看上次出库明细情况,明细将显示上次车辆申请内容:申请时间、驾驶人、使用时间段、事由、使用单位等信息。 |
14 | 2.3.2司机管理 | 提供驾驶人信息录入,可将驾驶员信息录入到该系统,并进行列表展示。每条驾驶员信息包含以下内容:姓名、身份证、隶属单位、联系电话、出勤次数、违章记录。其中违章记录通过公安内网大数据平台查询驾驶员的违章记录和扣分情况。可帮助在司机调配时进行参考。 |
15 | 2.3.3车辆违章管理 | 以单位/部门为单位,使用公安内网大数据平台对比,统计各单位车辆违章情况。 |
16 | 2.3.4车辆提醒管理 | 以单位/部门为单位,统计各单位待续保车辆总数、待保养车辆总数、即将报废车辆总数、待维修车辆总数、待处理违章车辆总数、待上牌车辆总数、待年审车辆总数。待处理的这些车辆,将定期、周期性的通过钉钉通知各单位管理员。 |
17 | 2.4维修保养管理 | |
18 | 2.4.1维修保养管理 | 各单位维修申请,包含以下内容:申请单位、申请时间、申请人、申请维修项目、实际维修项目、维修预算、实际费用。 |
19 | 2.4.2维修保养统计 | 统计各单位维修申请,包含以下内容:申请单位、申请时间、申请人、申请维修项目、实际维修项目、维修预算、实际费用。若实际维修项目与申请维修项目不一致,将通过颜色进行区分。并提供饼状图进行展示,点击饼状图可单独展示指定单位的维修申请统计。 |
20 | 2.5费用管理 | |
21 | 2.5.1日常费用管理 | 根据单位/部门,统计移动端发起的各项费用申请明细,日常费用(购置税、通行费、停车费、保险费、维修费、洗车费、装饰费、保养费)等各项费用的明细。并提供录入各项费用的界面,以保证非钉钉端审批的日常费用情况。 |
22 | 2.5.2燃油费用导入 | 统计移动端发起的燃油使用情况,并可以按照中国石化、中国石油的统计格式导入到系统进行统计。 |
23 | 2.5.3车辆费用统计 | 根据年度、季度、月份,统计各单位车辆在指定年度、季度、月份的费用汇总情况。 |
24 | 3现有系统改造和对接 | |
25 | 3.1OA用车申请审批改造 | 用车审批对接OA系统。使用钉钉发起审批,在市局办公自动化系统(OA)里进行审批,审批结果同步至车辆管理系统。 |
26 | 3.2大数据平台对接 | 对接大数据平台,统计各单位车辆违章情况。 |
27 | 4相关法律法规 | |
28 | 4.1公车管理办法 | 展示《宜昌市党政机关公务用车使用管理服务手册》内容,并定期更新公车使用的各项法律法规。 |
序号 | 功能模块 | 功能描述 |
1 | 数据汇聚 | 汇集警综平台,大数据平台,睿警务,睿社区,车踪平台,共享平台的系统日志信息。 |
2 | 个人统计 | 实现按月或按年,统计各个用户使用各业务平台的次数。 |
3 | 部门统计 | 实现按月或按年,统计各个部门使用各业务平台的次数。 |
4 | 局直单位统计 | 实现按月或按年,统计各分局使用各业务平台的次数。 |
5 | 派出所统计 | 实现按月或按年,统计各派出所使用各业务平台的次数。 |
6 | 日志反查 | 查看用户使用各业务平台的日志详情。 |
7 | 权限管理 | 实现各项统计功能的单独授权功能。 |
付款方式:在合同服务期满六个月后,五日内支付合同总金额的50%,余下金额服务期满后一次性付清。交货地点:宜昌市公安局。交货日期:合同签订之日起一年。商务要求
响应单位:宜昌思睿笃行科技有限公司件文应响宜昌市公安局应用系统人力外包运维服务
针对本项目安排数据工程师1人,普通技术员2人,开发工程师2人,客服人员1人进行驻场运维1年,上述运维人员根据工作实际情况进行动态调配。整体要求承诺服务内容宜昌市公安局大数据建设过程中,汇集了大量数据,在后续的数据汇聚与数据服务方面,需要专职数据工程师保障数据交换服务的稳定性、鲜活性、实时性与对外服务的有效性;在软件平台运维方面,需要专职运维人员保障现有系统稳定运行,同时完成零散的、个性化、规模量不大的系统研发,同时需要专职客服人员来提供日常培训、问题咨询、技术支持等服务。项目概况日期:2022年10月15日
数据汇聚运维服务服务要求承诺如用户方对运维人员的服务质量不满意(包括技术能力、服务态度等),有权通过书面形式提出撤换该运维人员的要求。参与本项目的运维人员在合同生效之日起必须固定下来,如需更换须保证替换人员的认证资质和从业经验不低于原有人员,并须提前一个月提交书面申请并经相关用户方签字同意。未经用户方同意不得随意更换。数据工程师要求熟悉市局大数据平台,精通海贝数据库相关技术,具备Oracle数据库经验。开发工程师要求熟悉市局信息系统开发架构,具备OA、移动办公等项目开发经验,熟悉Java开发框架,熟练操作Oracle、MySql数据库。在上述运维人员中指定一名担任本项目的项目经理,项目经理负责技术团队的管理、双方的协调沟通、资源的调配、服务实施的管理、服务报告提交和质量管控。
业务系统运维服务目前已开放40类计127个数据服务,其中通过接口提供服务的有83个,通过中间件提供的有33个,通过数据库提供的有10个,手工对接的1个;实时对接的有5个,每小时同步对接的有13个,每天同步对接的有14个,每周同步对接的有6个,每月对接同步的有2个,其他的根据业务需求随时调整同步周期。具体服务要求如下:数据服务运维服务目前公安大数据平台已汇聚对接151类数据资源,其中采用数据库对接的有99类,消息中间件对接的有39类,文件导入的有12类,接口对接的1类;交换频率方面,实时对接的有11类,按小时对接的有26类,按天同步对接的有85类,按周对接的有16类,不定期对接的有13类。具体运维要求如下(内容涉密,采购文件不提供具体资源名称,类别,数量等信息):
序号 | 运维内容 | 运维要求 |
1 | 数据汇聚标准制定 | 对各个来源渠道需要汇聚的数据,按照数据接入、治理等流程,制定对接双方统一的数据汇聚标准。 |
2 | 数据对接接入 | 利用数据导入工具或者开发数据接入程序,将各业务警种各业务系统、政府各部门、视频网、互联网社会面数据,实时或定时对接接入数据处理库,包括数据库接入、数据文件接入、消息中间件接入、接口接入等多种方式。 |
3 | 数据清洗入库 | 按照部标或省标,对接入的数据进行清洗、对标等处理,完成后对接大数据资源池。 |
4 | 数据汇聚监测、维护与保障 | 要求持续接入新数据的同时,对前期宜昌市公安局在大数据建设过程中已经汇聚的151类数据资源,利用人工和自动监测(ELK日志分析系统、Zabbix监测工具)等方式进行常态运维,确保数据汇聚实时、稳定、完整。对人工发现或用户反馈的数据汇聚中断、丢失、延时、异常等故障,运维人员须在故障发生后3小时内修复。每季度及时汇总、总结故障问题,向用户方提交运维报告。 |
序号 | 运维内容 | 运维要求 |
1 | 数据服务标准制定 | 针对大数据资源池内的数据,制定标准化的数据服务规范,确定所需的数据类型、数据字段、数据服务方式(包括数据共享服务和数据接口服务)。 |
2 | 数据接口服务开发 | 对各业务警种各部门提出的相关需求,按照数据服务标准,利用Mule做定制开发。 |
3 | 数据共享服务 | 对各业务警种各部门提出的相关需求,按照数据服务标准,通过开放Oracle数据库视图,Kafka、ActiveMQ消息中间件做数据共享。 |
4 | 数据服务监测与维护 | 要求持续开发新的数据服务的同时,对前期已经开放的40类数据服务,利用人工和自动监测(Zabbix监测工具)等方式进行常态运维,确保对各业务实战部门进行稳定地数据服务支撑。对人工发现或用户反馈的数据服务中断、数据异常等故障,运维人员须在故障发生后1小时内修复。每季度及时汇总、总结故障问题,向用户方提交运维报告。 |
序号 | 运维内容 | 运维要求 |
1 | 运行监控服务 | 利用自动化工具对数据库和应用系统等软件运行服务保证7*24小时不停机。对J2EE整体架构及应用程序、数据库进行运行监控和故障诊断,包括JVM的内存状况、线程信息、组件(包括JDBC层细致到SQL语句)执行级别信息及Java类、方法执行级别的响应时间和资源开销,能够对J2EE应用进行内存泄漏诊断和定位,通过更深入的监控和诊断,为应用优化提供第一手资料。 |
2 | 应急响应服务 | 针对运行监控、定期巡检发现的应用系统异常和故障,用户方反馈的系统问题,应及时响应,进行问题研判,确定故障等级,及时处理故障。在常态运维模式下,应保障工作日有值班人员驻守,发现问题在2小时内处理完成,最多不超过12小时。在应急运维模式下,比如重大安保、两会等节点,应安排核心运维人员在现场,实行24小时不间断运维服务,如期间发生系统长时间无法访问、关键模块报错无法操作、服务器宕机等事件,应作为运维事故。 |
3 | 性能调优服务 | 定期根据现有应用系统实际情况,或根据用户需求,安排开发工程师对系统程序交互界面、业务逻辑、系统Bug进行调优,保证应用稳定运行;数据库性能下降或空间不足时,安排数据工程师对数据库进行优化,对数据文件进行迁移或调整。 |
4 | 安全管理服务 | 制订完善的口令管理机制,周期性更改用户口令;针对用户方等级保护测评等报告暴露的问题,及用户方的要求进行安全整改。 |
5 | 技术支持服务 | 通过钉钉群、微信群、即时通讯工具、电话等方式,第一时间解答用户需求与问题,并记录存档,如是系统故障问题,同时上报运维人员,按照应急响应机制实施运维。根据用户需要,通过送教上门、会议交流等方式,对运维系统进行培训。 |
附3:卡口数据交换平台卡口联网中台附2:移动警务平台(钉钉)运维内容(其中序号为18-23/25-28/32-36/41的功能部署在内网)附1:大数据应用平台运维内容
序号 | 功能模块 | 功能描述 |
1 | 搜索应用适配器 | 为支持云搜索,需要通过全文库数据抽取工具,将数据抽取写入全文库,全文库抽取工具采用searchAdapter。 |
2 | 文本挖掘工具 | 文本挖掘是以半结构或非结构的自然语言文本为对象,从大规模文本数据集中发现隐藏的、潜在的、新颖的和重要的规律的过程。其基本思想是从文本中提取适当的特征,将文本标示成计算机能够理解的形式,采用各种文本挖掘方法发现隐藏的知识模式,以用户可以理解和接收的形式输出,成为指导人们实现的有用的知识。本次系统采用文本CKM进行文本挖掘。 |
3 | 大数据管理系统 | 本次大数据管理软件采用同公安部云搜一样的Hybase数据库,Hybase(海贝)是融合检索引擎、MySQL多引擎机制、Hadoop/HDFS分布式并行计算和多副本机制、Facebook/Cassandra对等节点机制、关系数据库列存储机制、自然语言处理等先进技术,而设计的大数据管理系统。Hybase为各类大数据分析应用, 提供大数据高效管理和智能检索的平台支撑。 |
4 | 汇集库 | 通过抽取整合公安内外各类数据,包括公安内部数据、公安外部数据、互联网数据、非结构化数据等实体化数据库,形成汇集库。汇集库负责各类数据资源的汇聚、抽取、管理。主要采用oracle数据库进行存储和管理。 |
5 | 基础数据资源库 | 基础数据资源库在汇集库的基础上进行了数据的清洗、转换和加载等处理过程,同时按照五要素进行分类,形成基础数据资源库,基础数据资源库的存储架构采用oracle数据库集群方式存储。 |
6 | 专题应用资源库 | 专题服务层由一系列针对特定应用或者服务需求以及非结构化数据管理和服务需求而构建的专题库组成,主要解决存储性能、访问性能、访问方便性及安全性等问题。结构化数据专题库基于要素模型层构建,采用逻辑视图、物化视图、抽取整合等手段构建。专题服务层包括全文库、人员基础要素库、车辆轨迹库、要素库、人员轨迹库和通讯关系库。 |
7 | 数据标准管理 | 结合公安部数据资源服务平台的数据服务标准,遵循公安数据元标准规范,开展公安数据元的梳理、编制和推广应用工作,建立全局统一的数据标准化管理和应用工作机制。同时利用公安部标准管理系统的接口同步更新标准信息,汇集整理数据资源管理所需的标准规范信息,建立数据标准数据库。利用公安部标准管理系统的接口同步更新标准信息。从而有效支撑公安大数据资源的标准化采集、管理和共享服务,建立符合部、省、市三级兼容的标准规范体系。梳理国标、部标和本省定义的标准代码以及各业务信息系统需要使用的其它代码,建立字典代码实体数据库。具备字典代码定期同步功能。 |
8 | 数据整合管理 | 数据整合管理主要是将配置好的已经过授权的数据源进行数据抽取 ,根据设定的规则进行数据清洗转换,同时对数据整合过程可实现动态监控。从而满足大数据分析的要求。同时为确保该过程可维护、可监督、可控制、可管理,本次系统设计还包括数据资源管理和调度与管理。采用数据同步工具或ETL工具完成数据抽取、同步等整合工作,通过任务调度管理实现对整合工具的集中管理和执行。配置数据同步工具或ETL工具,实现数据库之间数据复制和自动同步。对于数据量较大、数据变化情况难以获取的数据资源,采用分析数据库日志的方式进行数据同步。对于数据量较小,数据变化明确的数据资源,采用ETL工具对数据资源进行定时比对并获取变化数据,实现数据同步。 建设数据整合任务调度功能模块,实现对整合工具的集中管理和控制。通过配置执行时间的方式,控制数据整合工具中数据整合任务的执行;自动恢复出现异常的整合任务,并对整合任务出现的错误进行报警;记录整合任务的审计日志。 |
9 | 数据质量检测 | 建设数据质量检测配置功能模块,支持数据质量监控模型的自定义配置,利用技术监测和业务逻辑校验,进行数据源头采集、传输、应用全流程的规范性、一致性、准确性检查,实现基于不同来源数据的逻辑校验和监测管理。通过配置可实现上线前检测、运行过程检测、运行结果检测。建设数据质量检测配置功能模块,支持数据质量监控模型的自定义配置,利用技术监测和业务逻辑校验,进行数据源头采集、传输、应用全流程的规范性、一致性、准确性检查,实现基于不同来源数据的逻辑校验和监测管理。 |
10 | 数据资源监测 | 建设数据资源监测功能,实现平台数据变化、数据库系统状态和数据整合及质量检测工具运行状态等方面的集中监测。平台应自动监测数据资源变化情况,对数据资源中各信息表的数据量、每日增量和变化趋势等数据进行自动汇总统计,通过图表、表格等多种方式进行展现。应自动监测平台数据库的相关索引、触发器状态及每类数据存储空间使用情况等数据库系统状态信息,使用图形化界面定时发布监测结果,对出现的异常状态实时报警。 |
11 | 数据资源注册 | 基础数据注册的主要作用,是方便地实现数据资源提供者在数据资源目录体系中按照规范要求注册基础数据。基础数据的注册信息包括基本信息、访问敏感等级、业务分类、更新频率、数据关联关系,数据项的引用标准、代码、日期格式、访问敏感等级等。通过规范化的资源注册采集元数据信息,包括数据的技术属性、业务属性、管理属性等等,可以为上层查询分析应用提供支持。基础数据注册包括数据库注册、数据表注册和数据项注册。 |
12 | 数据资源编目 | 按照“公安数据资源目录注册接口规范”,依据公安部信息共享目录要求,对数据资源名称、数据资源摘要、数据资源提供方、数据资源分类、数据资源共享属性、数据资源公开属性、数据资源标识符、元数据标识符、数据项描述等元数据信息进行明确,对已注册的基础数据按照业务、层级等进行编目、发布,形成数据资源目录。为建立数据资源目录,首先要对各部门提供的数据资源和信息交换服务进行分析,理清各类数据资源的结构和相互关系。为方便使用,采用规范的方法和技术,建立科学合理的数据分类体系,对数据资源和服务建立分类目录和索引。 |
13 | 数据元信息标注 | 建立以公安部数据元为核心的同义词库,自动关联平台中注册的所有数据项,以数据元——同义词——数据项——数据表——应用系统——业务警种逐层对照的方式展示数据资源。通过同义词关联等对应规则,对数据资源注册的数据项与数据元资源库进行关联,找到后将数据项与数据元进行一一对应,完成资源目录与数据元的统一,可通过数据元关联显示所有的数据资源: |
14 | 大数据运行监控平台 | 大数据运行监控平台提供对相关分布式节点的CPU、IO、内存等进行实时的监控,可以通过浏览器登录系统的管理台(默认端口5555)。打开管理台页面,首先需要进行用户身份验证,见下图。用户填写正确的用户名、密码和验证码以后,点击登录即可登录到系统管理台。 |
15 | 公安部云搜系统接口 | 提供公安部云搜系统接口,实现在电子档案、战法扩展界面实现云搜数据中人员基本信息、关系人信息、活动轨迹信息数据自动下载,作为本地资源库的补充。同时导入后的数据可自动建档和进行关联关系分析。 |
16 | 省信息资源服务平台接口 | 建设与省信息资源服务平台的接口,通过该接口可实现将获取到从省信息资源服务平台下载的数据包进行解析、格式转换、入库和关联关系展现,从而通过该接口实现与省信息资源服务平台数据联动。 |
17 | PGIS接口 | 通过与PGIS平台对接,实现点位展现、轨迹查询等功能。 |
18 | 云搜索 | 云搜索系统具备数据项、关键字的预设或自定义功能。支持按照“集中式”与“分布式”相结合的基本原则,整合关系型、NOSQL型、文件型等不同类型数据库和数据查询服务接口,全面实现本地实体数据和外单位共享数据的全网一键式综合查询、二次检索及关系信息展现。同时综合查询功能可根据本地汇集的数据情况及共享的数据接口开展设计开发。 |
19 | 大数据可视化分析平台 | 大数据可视化分析平台的展现方式包括关系图、时间轴、分析图表、列表等多种表达方式,为使用者提供全方位的信息展现方式。 |
20 | 电子白板 | 电子白板就是一个带有各种工具(包含战法引入、图片添加、文件添加等)的白板,类似现实世界中的白板一样,初始化界面是一张画布,用户可根据实际需求进行要素添加。 |
21 | 数据比对 | 按照平台预设或用户自定义的比对规则,实现平台汇集的数据集间交叉比对功能,并能实现用户自行上传数据与平台内数据资源的比对功能。有条件的地方,应通过模型配置工具实现数据比对模型的流程化设计,并具备比对方案的浏览、版本管理、导入导出、调度与过程监测等管理功能。对于集中存储的结构化数据,能使用关系型数据库处理的,通过关系型数据库技术进行比对;数据量级较大,关系型数据库难以处理的,使用内存数据库技术或NOSQL数据库技术进行处理。对于集中存储的非结构化数据,提供基于实时关键词的比对服务。对于异地存储的结构化数据,提供基于请求服务或资源服务总线的分布式数据比对服务;对于异地存储的非结构化数据,逐步探索利用分布式文件系统开展远程比对的数据服务方式。 |
22 | 分类统计 | 分类统计实现对各种结构化、半结构化、非结构化数据的分类统计分析服务,应生成全面的、多种形式的统计分析结果,并通过表格、柱形图、饼图、曲线图等多种方式进行反馈展现。应设计OpenAPI接口,提供其他应用系统对接访问。分类统计是在数据服务的基础上,结合公安机关对报表业务的实际需求,为公安用户提供的可以方便快捷的分析数据、灵活创建报表的报表工具。报表的制作过程完全是可视化操作,不需要编写程序。报表模板生成使用的数据逻辑模型是基于业务结构的,使报表的需求人员可以直接进行新的报表制作,减少了报表生产带来的问题和工作量,提高工作效率。界面报表设计工具支持各种复杂报表和统计图表的设计,支持多页表以及自动分页;生成的报表尺寸精确,打印精致;可自动转换成WORD、EXCEL、BMP图片等文档;界面支持无级缩放。 |
23 | 电子档案 | 人员电子档案是在人员关注信息的基础上依托“人员基础要素库”设计实现的,以“一人一档”的方式集中展现人员动态管理全过程档案信息的人员电子档案展现功能,做到关注人员的基础信息、动态轨迹信息、关系人信息及社会信息等所有信息的展示一目了然,清楚地反映了关注人员分析研判和关注管理的全过程,个人档案信息也可直接调用可视化绘图工具,将所有人员信息进行可视化展示。通讯号码电子档案是和挖掘判断人与人之间关系的重要信息,因此建立通讯号码电子档案便于清晰明了的展现和通讯关系的挖掘。车辆电子档案主要实现对各种车辆活动的动态管控,以“一物一档”的方式集中展现物品动态管理过程中的电子档案信息展现功能,让物品相关的基本信息、人员信息、动态轨迹信息、关联卡口信息、区域信息、案件信息等所有信息的展示一目了然,清楚地反映了物品分析研判和关注管理的全过程,达到“以车管人”的目的。公安行业历年发生的各种案件数量庞大,人为的查找各种案件之间关系,发现其中的有效关系,为民警办案提供强有力的办案、破案依据,难度较大,警务大数据平台利用大数据离线处理能力,对预测犯罪事件、犯罪热点地区和犯罪趋势具有很大的潜在优势,能够提高从各种情报中“大海捞针”的水平,通过提取人们行为的时空规律性和关联性,对犯罪行为发生前进行预警和事后分析排查。 |
24 | 人员综合时空分析 | 通过对人员活动轨迹按活动时间倒序的简要列表形式显示该人的各类实名活动信息,从而实现对人员的综合时空分析。 |
25 | 业务警种战法系统 | 除了上述专题应用外,业务警种战法工具系统可以让各警种民警构建自己的战法和实体门户,从而可以结合自己的业务,利用该平台可以充分利用的信息资源,从而达到实用化、实战化。该工具支持战法模型、组合战法模型、关系门户配置、数据比对等,均可以通过可视化的方式,进行在线的配置,能够支持多种数据架构,如Oracle、达梦数据库、Hadoop hbase、MongoDB等技术。配置好的战法,可以自己使用,也可以共享授权给其他人员。 |
26 | 资源应用配置工具 | 资源通用应用和资源专题应用,需要进行后台配置,来添加资源和配置展现方式,可以配置云搜索的资源和简项显示方式、设置主题模型、要素属性配置、统计图表配置和电子档案界面配置,通过在线配置,可以快速修改界面和展示效果,快速满足用户的业务需求。 |
序号 | 功能模块 | 功能描述 |
1 | 1个人信息 | |
2 | 1.1企业通讯录 | 查看人员详细资料,并对其发消息、打电话等 |
3 | 1.2工资 | 查看工资数额、名目、明细等 |
4 | 1.3公积金 | 查看公积金数额、名目、明细等 |
5 | 1.4医保 | 查看医保金数额、名目、明细等 |
6 | 1.5社保 | 查看社保金数额、名目、明细等 |
7 | 1.6资产 | 查看个人名下资产类型、动向等 |
8 | 1.7公安网盘 | 存储相关资料,用于日常工作 |
9 | 2警务文化 | |
10 | 2.1警务要闻 | 查看省、市内相关的要闻信息 |
11 | 2.2投票 | 发起话题、投票并展现 |
12 | 2.3学习园地 | 观看公安教学、实践等视频短片 |
13 | 2.4在线考试 | 通过后台考试管理模块将考试内容发布给指定民警 |
14 | 3警务工作 | |
15 | 3.1二级接处警 | 110接处警平台按派出所的管辖范围,将警情下发到民警手机上。 |
16 | 3.2警情审批 | 完成对警情定性的工作 |
17 | 3.3警情分布 | 利用可视化地图,将警情分布在地图上 |
18 | 3.4警情统计 | 对每日、每月出警情况进行统计通报 |
19 | 3.5重点人员核查 | 指挥中心通过移动警务的消息接口,将数据推送到指定的民警。 |
20 | 3.6社区重口评估 | 社区工作平台每月需要对重点人员进行评估,数据将被定期的推送到社区民警的手机上 |
21 | 3.7暂口核查 | 社区工作平台每月需要对暂住人员进行评估,数据将被定期的推送到社区民警的手机上,民警每月完成辖区内的暂住人员的评估工作。 |
22 | 3.8精神病人评估 | 社区工作平台每月需要对精神病人进行评估,数据将被定期的推送到社区民警的手机上 |
23 | 3.9出租房巡检 | 每月针对出租房进行核查登记,登记房主、租户等相关的文字信息以及照片信息 |
24 | 3.10巡逻签到 | 民警接到巡逻任务,到达指定位置后,对本次巡逻进行签到工作 |
25 | 3.11NFC身份证识别 | 读取身份证的加密字符串,上传到解密服务器进行字符串的解密工作,最终将结果返回 |
26 | 3.12人员查询 | 民警在内网移动端调用人员接口 |
27 | 3.13车辆查询 | 民警在内网移动端调用车辆接口 |
28 | 3.14驾驶员查询 | 民警在内网移动端根据车牌调用人员接口 |
29 | 3.15数字电台 | 收集记录登记电台号 |
30 | 3.16PGIS采集 | 利用PGIS采集业务数据 |
31 | 3.17全警三员 | 全警三员系统是采集线索的移动端应用 |
32 | 3.18人像识别 | 调用宜昌市接口,将与待查人员相近的人员姓名、身份证号码、性别等按相似度高低显示。 |
33 | 3.19现场勘验 | 民警在接到警情抵达现场后,完成保护相关事宜记录、见证人信息采集、勘验相关信息采集等,录入的数据实时反馈到指挥中心,最终进入了警综平台。 |
34 | 3.20人像布控 | 民警接收系统推送的在逃人员、精神病人员、嫌疑人员信息,信息内容包括目标人身份相关信息、数据库照片、摄像头拍摄照片地点、时间等。 |
35 | 3.21现场督察 | 警务督察部门民警通过该功能实时推送检查督导情况于移动警务平台上,推送内容包括:督察主题、时间、事项内容及相关图片等。 |
36 | 3.22群众议警 | 民警通过走访群众,深入群众,广泛收集群众对公安工作的意见和建议。 |
37 | 3.23视频运维 | 民警在日常工作中发现视频相关故障,可通过手机反馈故障详细信息,并推送给相关维护人员。维护人员在接收信息后进行故障处理。此时该信息的状态为处理中,直至故障解决后,信息状态变为已处理。 |
38 | 3.24履职尽责 | 民警在手机端填写工作计划(季度、半年、全年工作计划)完成情况,提交后该信息存入数据库,可由系统管理员查找调出。 |
39 | 3.25拖车处理 | 民警通过手机输入需要被拖车辆的信息、拖往单位及拖车原因等,信息将传到拖车单位,拖车单位进行后续拖车工作。 |
40 | 3.26一键求援 | 民警遇到特殊情况无法单独处理需要其他民警协助时,点击“一键求援”按键,求援信息将被发送给该民警所在部门的所有人,并显示该民警与接收求助信息民警之间的地理位置信息。 |
41 | 3.27网络舆情 | 领导在移动端即可完成舆情信息的研判工作,加快舆情信息的处置流程。 |
42 | 4审批 | |
43 | 4.1请假申请 | 民警在手机段提交请假申请 |
44 | 4.2用车申请 | 民警在手机段提交用车申请 |
45 | 4.3出差申请 | 民警在手机段提交出差申请 |
46 | 5后台管理 | |
47 | 5.1后台管理 | 后台管理,主要是提供给系统管理员,发布新闻、公告、学习园地、投票管理、考试管理 |
48 | 5.2权限管理 | 将权限相似的用户所拥有的权限进行分组,将用户加入该分组,用户就拥有该分组里面的权限。系统管理员为用户分配响应的角色,该用户就可一次性的获得多个可操作的权限。 |
49 | 5.3日志系统 | 记录用户在使用移动警务中的所有操作行为,记录的日志信息包括:操作者、操作类型、操作内容、操作结果、操作时间等,并能通过操作时间、操作者、操作类型等条件进行定向查询相关日志记录。 |
50 | 6系统间集成 | |
51 | 6.1与OA系统集成 | 利用 OA 系统的流程管理和标准库,同步人员、组织机构,工资、资产等信息到移动端 |
52 | 6.2与二级接处警系统集成 | 系统对接 |
53 | 6.3与警综系统集成 | 系统对接 |
54 | 6.4与合成指挥系统集成 | 系统对接 |
55 | 6.5与宜昌共享平台对接集成 | 系统对接 |
56 | 6.6与慧信即时通讯平台对接集成 | 系统对接 |
序号 | 功能模块 | 功能描述 |
1 | 1 系统功能 | |
2 | 1.1设备管理 | 汇集各县市区的卡口基本信息,查看交警稽查对接,违法对接,过车信息等的跟踪功能。 |
3 | 1.2 PGIS展示 | 各县市区卡口PGIS地图展示。 |
4 | 1.3报表中心 | 按管理单位、平台厂商、各业务平台统计各县市区卡口基本情况。 |
5 | 1.4数据汇聚 | 汇聚各县市区及坝区的卡口过车信息。 |
6 | 2系统对接 | |
7 | 2.1与宜昌市公安交通集成指挥平台对接 | 实现卡口过车信息的稽查、违法信息的推送,坝区卡口过车信息推送。 |
8 | 2.2与车踪平台对接 | 实现卡口过车信息的图片解析及推送功能。 |
9 | 2.3与公安大数据平台对接 | 实现通过系统直接登录公安大数据平台。 |
(2)加班津贴申报系统(1)值勤津贴申报系统附1:新办公自动化系统升级针对各警种实际业务需要,收集汇总研发需求,统一进行功能优化。系统功能优化升级服务承诺
序号 | 功能模块 | 功能描述 |
1 | 1系统功能 | |
2 | 1.1系统配置 | |
3 | 1.1.1一类、二类单位配置 | 一类、二类单位配置,系统设置一/二类单位配置入口,可根据不同政治要求来配置各单位所属于类型,便于后期参与津贴申报金额计算。 |
4 | 1.1.2管理员配置 | 各单位申报管理员配置,系统提示管理员展示页,并对未配置管理员的单位进行标红处理。管理员分为部门管理员和科室管理员,部门管理员为直属宜昌市公安局的单位(如:西陵区分局、法制支队、政治部……)、科室管理员为各部门的下级单位(如西陵区分局警令科、政治部机关党委……),若各部门或科室存在人员且未配置管理员,在津贴申报时此部门将无法申报。 |
5 | 1.1.3全年计划数 | 每年一月初生成各单位全年计划数,若部门为县级时,全年计划数=(部门总人数*全年值勤天数*50)+(部门总人数*全年值勤天数*40)、若部门为市局时,全年计划数=(部门总人数*全年值勤天数*40)+(部门总人数*全年值勤天数*30)。 |
6 | 1.1.4每月总天数和法定节假日、工作日配置 | 每月总天数、法定节假日、法定工作日配置,每年每一月月初将本年度每个月的总天数、每月节假日、每月工作日进行录入,数据录入后才可以启动津贴申报,若本年度天数基础数据未录入时,津贴将无法启动计数。 |
7 | 1.2考勤数据统计 | 津贴申报天数自动将考勤出差、病假、事假天数进行扣除。民警可从OA或钉钉上发起考勤申请,若申请类型为出差、病假、事假三类时,在流程结束时自己将民警所申请核准的天数记录到津贴申报考勤数据库中。若出差、病假、事假的申请开始时间—结束时间中,涵盖双休或法定节假日,系统自动核算减出,不参与本月总出勤天数计算。若申请开始时间—结束时间中涵盖跨月情况时,系统息动将所跨月份及天数进行拆分,并对每月考勤数据进行记录出津贴申报考勤数据库中。另,若出差人员存在多人,且多人出差天数不一样时,出差结束后由申请人对每位出差人员天数进行核实填写,填写的数据将自动记录到津贴申报考勤数据库。 |
8 | 1.3人员信息记录 | 津贴申报按民警财务所属机构进行汇总,按照“在哪上班在哪发起”为依据,将借调人员财务所属机构选择为目前所在工作单位。各单位管理员可在OA系统中“按人员”、“按财务”机构进行人员查询,具有管理员权限的人员,可对自己所管辖的单位人员进行调整,人员调整到位后,系统每晚自动将人员信息推送至津贴申报人员信息库进行保存。若本月津贴已启动后,再次对单位人员部门进行调整时,在本次申请中将不会生效。 |
9 | 1.4主动消息提醒 | 每月28号,系统自动对各津贴申报管理员发送短信及钉钉消息,提醒各管理员在申报前期对本单位人员及管理员进行核实检查,以防人员存在所属机构不对应或管理员未及时变更情况。 |
10 | 1.5值勤津贴启动 | 针对相关指定管理员,在OA系统中分配对津贴申报管理权限。由管理员添加津贴启动相关标题及文字说明、申报开始时间和结束时间,可选择是否给津贴各单位管理员发送启动短信提醒。启动成功后自动生成本次申报信息,点击可查看参与申报的单位及明细,也可实时掌控各单位是否发起审批或审批完成。 |
11 | 1.6津贴申报审核 | 津贴启动后,各部门和科室管理人员在OA待办区域将收到一条津贴申报文档,系统自动计算本月考勤信息并在页面显示,管理员可根据实际情况进行考勤天数调整,调整后原始数据依然保留;若存在长期生病或已经退休人员,管理员也可对此人进行“冻结”“解冻”操作,人员冻结后将不再参与本次津贴申报;考勤天调整完成后,管理员可对本单位人员一类天进行修改,系统自动计算二类天和金额。各单位在保存数据后,系统也将自动对一类天申报比例和总金额进行汇总计算;数据调整无误后可发起审批,科所队在发起审批后,可送达给所在领导审批、也可直接流程结束,领导审批时若对数据有质疑时,可直接点击“驳回”,数据驳回后由单位管理员将重新进行修改后再次发起审批。部门管理员可实时查看所管辖的下属单位申报情况及申报详情,若下属科所队申报比例超出或存在其它问题时,部门管理员可直接将单位申报信息进行驳回。部门汇总申报时,必须由下级单位全部申报结束后才可发起,若下级所有单位一类申报比例超出40%时,部门无法发起汇总审批,必须由部门管理员对有问题的单位进行驳回修改,一类申报比例小于或等于40%时,可正常发起审批,其中一类申报比例计算公式为:一类天总数/(单位人数*本月出勤天数),(如:单位A有10人,本月出勤天数为22天,申报一类总天数为100天,一类申报比例=100/(10*22),得出单位A一类申报比例为45.45%)。部门审批发起成功后,不可再次对下级单位进行驳回操作,发起审批后,由部门管理员送达给分局/支队领导审批,待领导审批通过后部门申报结束。市局管理员可实时查看全局所有单位(九县区除外)申报情况,并对有问题的分局/支队进行驳回操作。 |
12 | 1.7津贴申报停止 | 待申报时间结束后,由市局管理员点击申报停止,管理员点击申报停止后,对未申报结束的部门将不可再使用系统进行申报、也不可再对其它申报部门进行驳回操作。申报停止后,需由管理员选择发起市局审批,审批发起后,系统将自动生成市局与交警两条审核信息,分别送达到对应的管理员OA帐号,由市局与交警管理员按照流程选择送达领导审核,领导在审批时若对数据存在疑问,可点击查看对应部门和科室申报数据及金额。市局汇总审核通过后,系统自动给警保相关人员发送“送阅知”信息,提醒相关人员及时发放值勤津贴。 |
13 | 1.8申报数据统计 | 津贴申报停止后,由报表系统核算出各单位和人员的津贴详情,含工资卡号、一/二类天数、一/二类金额、考勤天数、发放金额及各数据汇总金额,财务人员可直接下载为Excel格式进行发放。 |
14 | 1.9数据归档处理 | 每月申报结束后,申报数据归档到Oracle库中,可供后期调出查看、各单位审核记录表单由OA系统保留,可供需要时调出查看和打印、统计汇总报表由报表系统进行归档存底,确保数据不丢失。 |
15 | 2系统对接 | |
16 | 2.1与OA系统对接 | 本系统与OA系统对接,实现内容审核、信息归档、人员管理、数据配置等。 |
17 | 2.2与移动警务平台对接 | 移动警务平台作为日常办公的移动端的延伸。本系统必须实现移动端的出差等申请、消息提醒及相关审批,部分功能的移动化办公。 |
18 | 2.3与报表系统对接 | 本系统与报表系统对接,实现各类数据报表的生成统计,EXCEL导出功能。 |
19 | 2.4与短信平台对接 | 本系统对接短信平台,实现短信提醒功能。 |
序号 | 功能模块 | 功能描述 |
1 | 1系统配置 | |
2 | 1.1管理员配置 | 各单位申报管理员配置,系统提示管理员展示页,并对未配置管理员的单位进行标红处理。管理员分为部门管理员和科室管理员,部门管理员为直属宜昌市公安局的单位(如:西陵区分局、法制支队、政治部……)、科室管理员为各部门的下级单位(如西陵区分局警令科、政治部机关党委……),若各部门或科室存在人员且未配置管理员,在津贴申报时此部门将无法申报。管理员配置分为:科室、部门、总管理员三级,每月津贴由总管理员发起。其中科室管理员可申报所在科室人员数据,部门管理员可对本部门下所有科室进行驳回重报,总管理员可管理全局所有部门。 |
3 | 1.2加班津贴计算公式 | 加班津贴按人均每月710元进行发放,金额控制以部门为单位,实现加班差异化(如:政治部总人数为20人,本季度加班总金额=20*710*3),部门申请金额不得超出季度总金额;若本季度加班金额申报后有结余时,可累计到下一季度,直止年底清零。 |
4 | 1.3每月总天数和法定节假日、工作日配置 | 每月总天数、法定节假日、法定工作日配置,每年每一月月初将本年度每个月的总天数、每月节假日、每月工作日进行录入,数据录入后才可以启动津贴申报,若本年度天数基础数据未录入时,津贴将无法启动计数。 |
5 | 2考勤数据统计 | 民警从OA或钉钉上发起加班申请,在流程结束时将民警所申请核准的天数记录到津贴申报考勤数据库中。若申请开始时间—结束时间中涵盖跨月情况时,系统自动将所跨月份及天数进行拆分,并对每月考勤数据进行记录出津贴申报考勤数据库中。 |
6 | 3人员信息记录 | 津贴申报按民警在OA中所属部门进行汇总,按照“在哪上班在哪发起”为依据,OA系统中所属部门为工作单位。各单位管理员可在OA系统“通讯录”中查询人员。若本月津贴已启动后发现人员所属部门错误时,可点击人员姓名,选择需要调整到的单位(对方单位未填报时方可调整)。 |
7 | 4加班津贴启动 | 针对津贴总管理员,在OA系统中分配对津贴申报管理权限。由管理员添加津贴启动相关标题及文字说明、申报开始时间和结束时间。启动成功后自动生成本次申报信息,点击可查看参与申报的单位及明细,也可实时掌控各单位是否发起审批或审批完成。 |
8 | 5津贴申报审核 | 津贴启动后,各部门和科室管理人员在OA待办事项里将收到一条津贴申报待办文件,系统自动计算本月加班信息并在页面显示,管理员可根据实际情况进行加班天数调整,调整后原始数据依然保留;若存在长期生病或已经退休人员,管理员也可对此人进行“冻结”“解冻”操作,人员冻结后将不再参与本次津贴申报;加班天数调整完成后,管理员可对本单位人员法定天和普通天进行修改,系统自动计算法定和普通金额。数据调整无误后可发起审批,科所队在发起审批后,可送达给所在领导审批、也可直接流程结束,领导审批时若对数据有质疑时,可直接点击“驳回”,数据驳回后由单位管理员重新进行修改后再次发起审批。部门管理员可实时查看所管辖的下属单位申报情况及申报详情,若下属科所队申报比例超出或存在其它问题时,部门管理员可直接将单位申报信息进行驳回。部门汇总申报时,必须由下级单位全部申报结束后才可发起,若下级所有单位申报金额超出本次申报总金额时,部门无法发起汇总审批,必须由部门管理员对有问题的单位进行驳回修改。部门审批发起成功后,不可再次对下级单位进行驳回操作,发起审批后,由部门管理员送达给分局/支队领导审批,待领导审批通过后部门申报结束。市局总管理员可实时查看全局所有单位(九县局除外)申报情况,并对有问题的分局/支队进行驳回操作。 |
9 | 6津贴申报停止 | 待申报时间结束后,由市局总管理员点击申报停止,总管理员点击申报停止后,未申报结束的部门将不可再使用系统进行申报、也不可再对其它申报部门进行驳回操作。申报停止后,需由总管理员选择发起市局审批,审批发起后,系统将自动生成市局与交警两条审核信息,分别送达到对应的管理员OA帐号,由市局与交警管理员按照流程选择送达领导审核,领导在审批时若对数据存在疑问,可点击查看对应部门和科室申报数据及金额。 |
10 | 7申报数据统计 | 津贴申报停止后,由报表系统核算出各单位和人员的津贴详情,含工资卡号、法定/普通天数、法定/普通金额、加班天数、发放金额及各数据汇总金额,财务人员可直接下载为Excel格式进行发放。 |
11 | 8数据归档处理 | 每月申报结束后不可再修改,各单位审核记录表单由OA系统保留,可供需要时调出查看和打印、统计汇总报表由报表系统进行归档存底,确保数据不丢失。 |
交货日期:合同签订之日起一年。其他要求承诺附2:大数据平台日志审计(3)公车管理系统
序号 | 功能模块 | 功能描述 |
1 | 1移动端功能需求 | |
2 | 1.1用车申请 | 实现移动端发起审批。明细包含但不限于:用车时间、返回时间、车型、车牌、出发地点、返回地点、司机、用车部门、用车事由。宜昌市中心城区内用车由各单位主要负责人审批,离开宜昌市中心城区由其分管局领导审批。 |
3 | 1.2维修申请 | 实现OA申报车辆维修申请,上报明细包含:时间、申请单位、车辆号牌、车型、已行驶公里数。故障原因、维修项目、预算金额、申请人、委修人、单位负责人审核、领导审批,手段可提供文字描述、拍照记录等。 |
4 | 2后台管理系统功能需求 | |
5 | 2.1车辆信息管理 | |
6 | 2.1.1车辆信息导入导出 | 系统提供导入现有车辆信息,支持Excel导入、导出。 |
7 | 2.1.2车辆信息维护 | 给各单位车辆管理员提供本单位车辆信息录入、修改、删除、查询等功能权限。维护信息包含:部门、机动车所有人、车牌号、车型、车架号、发动机号、注册日期、里程数、购置价格、使用性质、号牌类型。 |
8 | 2.1.3车辆明细统计 | 实现以部门、机动车所有人、车辆型号、车辆车型等条件,统计各单位现有车辆的 明细,统计内容包含但不限于:用车部门、机动车所有人、车牌号码、品牌型号、车型、车架号、发动机号、注册日期、已行驶公里数、排气量、购置价格、使用性质、号牌类型。 |
9 | 2.1.4车辆综合统计 | 根据单位部门、时间段、车辆类型、号牌种类等条件,统计各个局直单位的车辆情况。统计内容包含但不限于:各单位人数、派出所数、人车比、车辆总数、号牌种类统计(警车、民牌、未上牌各有多少数量)、车辆类型统计(小轿车、面包车、大客车、越野车、货车、其他类型车辆,共有多少辆)、车辆各年限车辆共有多少辆。并提供。 |
10 | 2.2用车申请管理 | |
11 | 2.2.1用车申请统计 | 用车审批结果同步到公安内网,可在本系统里体现审批明细,明细包含但不限于:用车时间、返回时间、车型、车牌、出发地点、返回地点、司机、用车部门、用车事由。 |
12 | 2.3车辆调度管理 | |
13 | 2.3.1车辆出入库记录 | 根据用车申请填报的用车时间(开始时间、结束时间),预测一份统计情况。统计内容包含但不限于:各单位在库车辆数量。若在库,可查看上次出库明细情况,明细将显示上次车辆申请内容:申请时间、驾驶人、使用时间段、事由、使用单位等信息。 |
14 | 2.3.2司机管理 | 提供驾驶人信息录入,可将驾驶员信息录入到该系统,并进行列表展示。每条驾驶员信息包含以下内容:姓名、身份证、隶属单位、联系电话、出勤次数、违章记录。其中违章记录通过公安内网大数据平台查询驾驶员的违章记录和扣分情况。可帮助在司机调配时进行参考。 |
15 | 2.3.3车辆违章管理 | 以单位/部门为单位,使用公安内网大数据平台对比,统计各单位车辆违章情况。 |
16 | 2.3.4车辆提醒管理 | 以单位/部门为单位,统计各单位待续保车辆总数、待保养车辆总数、即将报废车辆总数、待维修车辆总数、待处理违章车辆总数、待上牌车辆总数、待年审车辆总数。待处理的这些车辆,将定期、周期性的通过钉钉通知各单位管理员。 |
17 | 2.4维修保养管理 | |
18 | 2.4.1维修保养管理 | 各单位维修申请,包含以下内容:申请单位、申请时间、申请人、申请维修项目、实际维修项目、维修预算、实际费用。 |
19 | 2.4.2维修保养统计 | 统计各单位维修申请,包含以下内容:申请单位、申请时间、申请人、申请维修项目、实际维修项目、维修预算、实际费用。若实际维修项目与申请维修项目不一致,将通过颜色进行区分。并提供饼状图进行展示,点击饼状图可单独展示指定单位的维修申请统计。 |
20 | 2.5费用管理 | |
21 | 2.5.1日常费用管理 | 根据单位/部门,统计移动端发起的各项费用申请明细,日常费用(购置税、通行费、停车费、保险费、维修费、洗车费、装饰费、保养费)等各项费用的明细。并提供录入各项费用的界面,以保证非钉钉端审批的日常费用情况。 |
22 | 2.5.2燃油费用导入 | 统计移动端发起的燃油使用情况,并可以按照中国石化、中国石油的统计格式导入到系统进行统计。 |
23 | 2.5.3车辆费用统计 | 根据年度、季度、月份,统计各单位车辆在指定年度、季度、月份的费用汇总情况。 |
24 | 3现有系统改造和对接 | |
25 | 3.1OA用车申请审批改造 | 用车审批对接OA系统。使用钉钉发起审批,在市局办公自动化系统(OA)里进行审批,审批结果同步至车辆管理系统。 |
26 | 3.2大数据平台对接 | 对接大数据平台,统计各单位车辆违章情况。 |
27 | 4相关法律法规 | |
28 | 4.1公车管理办法 | 展示《宜昌市党政机关公务用车使用管理服务手册》内容,并定期更新公车使用的各项法律法规。 |
序号 | 功能模块 | 功能描述 |
1 | 数据汇聚 | 汇集警综平台,大数据平台,睿警务,睿社区,车踪平台,共享平台的系统日志信息。 |
2 | 个人统计 | 实现按月或按年,统计各个用户使用各业务平台的次数。 |
3 | 部门统计 | 实现按月或按年,统计各个部门使用各业务平台的次数。 |
4 | 局直单位统计 | 实现按月或按年,统计各分局使用各业务平台的次数。 |
5 | 派出所统计 | 实现按月或按年,统计各派出所使用各业务平台的次数。 |
6 | 日志反查 | 查看用户使用各业务平台的日志详情。 |
7 | 权限管理 | 实现各项统计功能的单独授权功能。 |
我公司拥有完善的技术支持服务体系,能够为客户提供高质量、快捷的服务。我公司的售后服务和运行维护服务体系基于公司的质量保障体系和客户关系体系,采用多种服务渠道和方式,为客户提供完善的技术支持和售后服务。完善的服务体系服务体系运维服务体系及应急保障付款方式:在合同服务期满六个月后,五日内支付合同总金额的50%,余下金额服务期满后一次性付清。交货地点:宜昌市公安局。
长期实施信息化工程的过程中,公司建立了一套完整的服务质量保证体系:公司多年的信息化项目的实施、服务过程中,从实施过程中的技术支持到终验后的售后服务,从用户的需求响应到监理单位、相关承建单位的合作协调,总结提炼丰富实践经验,建立一套完善的服务质量保障管理体系。质量保障措施技术支持和售后服务组接到用户或现场工程师的请求后,及时将请求登记,即时响应,并转入相应的服务流程。同时,公司技术支持服务中心将定期向用户征求意见,征询用户对我公司技术支持服务的满意度,对我公司现场工程师和技术支持服务中心的工程师的“服务态度、业务水平、技术水平”等进行评价,以便不断提高我公司的服务质量。针对本次项目,公司将实行项目经理负责制,配备充足的工程技术人员,并指定专人负责具体的技术支持和售后服务工作。在要求实施技术支持和售后服务时,用户既可以与指定技术工程师联系,也可以直接与项目经理联系,保证及时与客户沟通,以最快的响应速度受理和解决用户所遇到的各种问题。丰富的人力资源
应急保障5)公司技术支持服务中心设立热线电话、邮件、即时通信等多项联系通报机制,保障系统故障通报顺畅,第一时间进行服务响应。4)公司对于具体的项目实行项目经理负责制,指定专人负责具体的技术支持和售后服务工作。在要求实施技术支持和售后服务时,用户既可以与指定技术工程师联系,也可以直接与项目经理联系。3)建立用户投诉机制,用户对我公司技术服务人员的服务不满意可以通过投诉热线电话反映,我公司会对每一个投诉进行记录并及时响应。2)针对具体项目建立独立、详细的客户档案。我们将为本次项目建立详细的分类客户档案,做到每一次系统优化、每一次系统升级、每一次设备维修都有记录。1)为了保证售后服务质量,我们建立了一系列服务规范,对每一个技术工程师定期进行服务规范教育,定期对技术工程师进行技术培训,以便售后服务工程师能够高效、高质的为用户提供服务。
2.决策机制2)以确保数据安全为原则;1)以确保应用系统正常使用为原则;1.应急处理原则应急保障工作原则为保证本项目系统稳定运行,针对各个实施阶段制定本应急预案。确保遭遇紧急事件时,相关人员应严格按照既定的应急预案,及时报告、妥善处置。
应急响应机制建立系统运行管理和检查监督制度,并在实际工作中对此进行完善。管理制度应急响应小组建设在项目建设单位的相关部门,各级应急响应单元分布建设在各个部门,共同组成一个分层次的、统一指挥的、协同工作的、一体化的预警与应急响应体系。应急响应小组由甲方、我公司、系统开发商、监理方、软硬件供应商等组成,各单位由领导挂帅,其他相关管理与技术人员共同组成。成立应急小组在系统运行过程中遭遇紧急事件时,立即向项目实施组报告;对一般性技术故障由工程实施组记录并协调处理后,再向领导小组报告;对重大故障,工程实施组应立即报告领导小组协调处理。
3.数据丢失或损坏:从数据备份服务器上提取数据,尽快恢复,保证系统在最短时间内能够正常运行;分析造成事故的原因,针对具体问题,采取相应安全措施。2.对简单故障,项目经理安排维护人员迅速排除故障,解决问题。如果需要更换设备,立即上报项目领导小组,尽快恢复系统运行。1.系统突发事故应由发现人通知项目经理,项目经理协调相关责任方立即检查故障,进行初步故障定位。如果应用系统出现比较严重的问题,对系统的正常运行造成较大的影响,需立即向我公司和项目领导小组报告。系统出现突发事故时可能采取的应急处理措施,如下:应急突然事故处理为科学应对网络与信息安全突发事件,建立健全信息安全应急响应机制,有效预防、及时控制和最大限度地消除信息安全各类突发事件的危害和影响,运行维护部门应制定应急预案,并且针对应急响应的各项知识、技术、技能进行培训,明确在应急系统中人员担任的角色,定期举行应急预案的演习。
5)病毒爆发事件处理完毕,将计算机重新接入网络。4)恢复系统和相关数据,检查数据的完整性。3)启用防病毒软件对系统进行杀毒处理,同时通过防病毒软件对其他计算机进行病毒扫描和清除工作。2)对该计算机的重要数据进行数据备份。1)立即切断感染病毒计算机与网络的连接。4.病毒爆发处理:系统一旦发现感染病毒,执行以下应急处理流程:
风险评估;制定应急计划灾难应急处理流程是对人为或自然灾害造成的涉及全局的一时难以恢复的破坏性事件的处理流程。主要包括以下内容:1)灾难应急处理流程具体细节如下:6)网络中断,所有网页无法显示时,检查计算机的“本地连接”是否处于禁止状态或者网线断开状态,如出现上述情况启用“本地连接”或者检查网线接触是否良好。
对驻地维护人员进行灾难恢复流程培训;应急恢复流程培训应急设备的维护技术恢复流程制定等。经营业务永续运营计划;关键业务影响分析;
提供现场支持和指导;约定时间内的设备运输;灾难核实及业务恢复方案启动;应急业务恢复模仿真正灾难发生后的设备配置和系统加载状况。使用灾难发生后会涉及的所有设备;
预防性病毒警告病毒处理流程建立病毒应急处理包括在病毒爆发前的预防性处理和病毒爆发后的紧急处理流程。具体流程包括以下内容:2)病毒应急处理流程业务恢复后,恢复计划的回顾和改进。设备在合同签订时间内的使用;
安全事件应急处理具体包括以下内容:3)安全事件应急处理流程后续报告与补救措施危害降低机制全网性升级与病毒查杀措施应急病毒防范与处理机制
补救与增强措施后续报告与处理机制事件解决缩小事件影响范围事件识别机制安全应急流程建立-建立安全基线
联系我们
上海总部:上海市浦东新区中科路1750号1幢张江科学之门模力社区606-607室
无锡分公司:无锡市新吴区江溪路77号北航投资(无锡)科创中心303室
邮 箱:bd@datauseful.com

给力助理小程序

给力讯息APP

给力商讯公众号
服务协议
版权所有©上海优司服信息科技有限公司 沪ICP备2022009382号 沪ICP备2022009382号-1

返回顶部